- 23 May, 2011 6 commits
-
-
Kleber Sacilotto de Souza authored
commit dcbe14b9 upstream. Currently EHEA reports to ethtool as supporting 10M, 100M, 1G and 10G and connected to FIBRE independent of the hardware configuration. However, when connected to FIBRE the only supported speed is 10G full-duplex, and the other speeds and modes are only supported when connected to twisted pair. Signed-off-by:
Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com> Acked-by:
Breno Leitao <leitao@linux.vnet.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
john stultz authored
Currently with 2.6.32-longterm, its possible for time() to occasionally return values one second earlier then the previous time() call. This happens because update_xtime_cache() does: xtime_cache = xtime; timespec_add_ns(&xtime_cache, nsec); Its possible that xtime is 1sec,999msecs, and nsecs is 1ms, resulting in a xtime_cache that is 2sec,0ms. get_seconds() (which is used by sys_time()) does not take the xtime_lock, which is ok as the xtime.tv_sec value is a long and can be atomically read safely. The problem occurs the next call to update_xtime_cache() if xtime has not increased: /* This sets xtime_cache back to 1sec, 999msec */ xtime_cache = xtime; /* get_seconds, calls here, and sees a 1second inconsistency */ timespec_add_ns(&xtime_cache, nsec); In order to resolve this, we could add locking to get_seconds(), but it needs to be lock free, as it is called from the machine check handler, opening a possible deadlock. So instead, this patch introduces an intermediate value for the calculations, so that we only assign xtime_cache once with the correct time, using ACCESS_ONCE to make sure the compiler doesn't optimize out any intermediate values. The xtime_cache manipulations were removed with 2.6.35, so that kernel and later do not need this change. In 2.6.33 and 2.6.34 the logarithmic accumulation should make it so xtime is updated each tick, so it is unlikely that two updates to xtime_cache could occur while the difference between xtime and xtime_cache crosses the second boundary. However, the paranoid might want to pull this into 2.6.33/34-longterm just to be sure. Thanks to Stephen for helping finally narrow down the root cause and many hours of help with testing and validation. Also thanks to Max, Andi, Eric and Paul for review of earlier attempts and helping clarify what is possible with regard to out of order execution. Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
John Stultz <johnstul@us.ibm.com> Signed-off-by:
-
Pavel Shilovsky authored
commit 4906e50b upstream. While password processing we can get out of options array bound if the next character after array is delimiter. The patch adds a check if we reach the end. Signed-off-by:
Pavel Shilovsky <piastry@etersoft.ru> Reviewed-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Dan Rosenberg authored
commit a2948659 upstream. A length of zero (after subtracting two for the type and len fields) for the DCCPO_{CHANGE,CONFIRM}_{L,R} options will cause an underflow due to the subtraction. The subsequent code may read past the end of the options value buffer when parsing. I'm unsure of what the consequences of this might be, but it's probably not good. Signed-off-by:
Dan Rosenberg <drosenberg@vsecurity.com> Acked-by:
Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by:
-
Timo Warns authored
commit fa039d5f upstream. Otherwise corrupted EFI partition tables can cause total confusion. Signed-off-by:
Timo Warns <warns@pre-sense.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Jeff Layton authored
commit fcda7f45 upstream. It's possible that when we go to decode the string area in the SESSION_SETUP response, that bytes_remaining will be 0. Decrementing it at that point will mean that it can go "negative" and wrap. Check for a bytes_remaining value of 0, and don't try to decode the string area if that's the case. Reported-and-Acked-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
- 09 May, 2011 34 commits
-
-
Greg Kroah-Hartman authored
-
James Bottomley authored
commit c055f5b2 upstream. The recent commit closing the race window in device teardown: commit 86cbfb56 Author: James Bottomley <James.Bottomley@suse.de> Date: Fri Apr 22 10:39:59 2011 -0500 [SCSI] put stricter guards on queue dead checks is causing a potential NULL deref in scsi_run_queue() because the q->queuedata may already be NULL by the time this function is called. Since we shouldn't be running a queue that is being torn down, simply add a NULL check in scsi_run_queue() to forestall this. Tested-by:
Jim Schutt <jaschut@sandia.gov> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
Oliver Hartkopp authored
commit 10022a6c upstream. v2: added space after 'if' according code style. We can get here with a NULL socket argument passed from userspace, so we need to handle it accordingly. Thanks to Dave Jones pointing at this issue in net/can/bcm.c Signed-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
-
Zachary Amsden authored
(backported from commit 28e4639a) If preempted after kvmclock values are updated, but before hardware virtualization is entered, the last tsc time as read by the guest is never set. It underflows the next time kvmclock is updated if there has not yet been a successful entry / exit into hardware virt. Fix this by simply setting last_tsc to the newly read tsc value so that any computed nsec advance of kvmclock is nulled. Signed-off-by:
Zachary Amsden <zamsden@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> BugLink: http://bugs.launchpad.net/bugs/714335Signed-off-by:
Serge E. Hallyn <serge.hallyn@canonical.com> Reviewed-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
-
Zachary Amsden authored
(backported from commit 1d5f066e) Kernel time, which advances in discrete steps may progress much slower than TSC. As a result, when kvmclock is adjusted to a new base, the apparent time to the guest, which runs at a much higher, nsec scaled rate based on the current TSC, may have already been observed to have a larger value (kernel_ns + scaled tsc) than the value to which we are setting it (kernel_ns + 0). We must instead compute the clock as potentially observed by the guest for kernel_ns to make sure it does not go backwards. Signed-off-by:
-
Zachary Amsden authored
(cherry-picked from commit 347bb444) The scale_delta function for shift / multiply with 31-bit precision moves to a common header so it can be used by both kernel and kvm module. Signed-off-by:
-
Stanislaw Gruszka authored
commit b2502698 upstream. Since commit a120e912 Author: Stanislaw Gruszka <sgruszka@redhat.com> Date: Fri Feb 19 15:47:33 2010 -0800 iwlwifi: sanity check before counting number of tfds can be free we use skb->data after calling ieee80211_tx_status_irqsafe(), which could free skb instantly. On current kernels I do not observe practical problems related with bug, but on 2.6.35.y it cause random system hangs when stressing wireless link. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Felipe Balbi authored
commit ec95d35a upstream. MUSB is a non-standard host implementation which can handle all speeds with the same core. We need to set has_tt flag after commit d199c96d (USB: prevent buggy hubs from crashing the USB stack) in order for MUSB HCD to continue working. Signed-off-by:
Felipe Balbi <balbi@ti.com> Cc: Alan Stern <stern@rowland.harvard.edu> Tested-by:
Michael Jones <michael.jones@matrix-vision.de> Tested-by:
Alexander Holler <holler@ahsoftware.de> Signed-off-by:
-
Tejun Heo authored
commit 729a6a30 upstream. ata_pio_sectors() expects buffer for each sector to be contained in a single page; otherwise, it ends up overrunning the first page. This is achieved by setting queue DMA alignment. If sector_size is smaller than PAGE_SIZE and all buffers are sector_size aligned, buffer for each sector is always contained in a single page. This wasn't applied to ATAPI devices but IDENTIFY_PACKET is executed as ATA_PROT_PIO and thus uses ata_pio_sectors(). Newer versions of udev issue IDENTIFY_PACKET with unaligned buffer triggering the problem and causing oops. This patch fixes the problem by setting sdev->sector_size to ATA_SECT_SIZE on ATATPI devices and always setting DMA alignment to sector_size. While at it, add a warning for the unlikely but still possible scenario where sector_size is larger than PAGE_SIZE, in which case the alignment wouldn't be enough. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
John Stanley <jpsinthemix@verizon.net> Tested-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
Jonathan Liu <net147@gmail.com> Signed-off-by:
-
Guennadi Liakhovetski authored
commit e476a5a4 upstream. Fix unbalanced call to sdio_release_host() on the error path. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Ben Hutchings authored
commit 46814e08 upstream. My conversion of tehuti to use request_firmware() was confused about the filename of the firmware blob. Change the driver to match the blob. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Andy Gospodarek <andy@greyhouse.net> Signed-off-by:
-
Bart Hartgers authored
commit a55ab496 upstream. When writing a disc on certain lite-on dvd-writers (also rebadged as optiarc/LG/...) connected to a vt6420, the ATAPI CDB ends up in the datastream and on the disc, causing silent corruption. Delaying between sending the CDB and starting DMA seems to prevent this. I do not know if there are burners that do not suffer from this, but the patch should be safe for those as well. There are many reports of this issue, but AFAICT no solution was found before. For example: http://lkml.indiana.edu/hypermail/linux/kernel/0802.3/0561.htmlSigned-off-by:
Bart Hartgers <bart.hartgers@gmail.com> Signed-off-by:
-
Ondrej Zary authored
commit 75f64dd5 upstream. HW crypto in rt2500usb does not seem to support keys with different ciphers, which breaks TKIP+AES mode. Fall back to software encryption to fix it. This should fix long-standing problems with rt2500usb and WPA, such as: http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=4&t=4834 https://bugzilla.redhat.com/show_bug.cgi?id=484888 Also tested that it does not break WEP, TKIP-only and AES-only modes. Signed-off-by:
Ondrej Zary <linux@rainbow-software.org> Acked-by:
Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by:
-
Ben Hutchings authored
commit 4d9ef89d upstream. The dts-installed variable is initialised using a wildcard path that will be expanded relative to the build directory. Use the existing variable dtstree to generate an absolute wildcard path that will work when building in a separate directory. Reported-by:
Gerhard Pircher <gerhard_pircher@gmx.net> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Rémi Denis-Courmont authored
[bwh: This is only applicable to 2.6.32. Phonet was fixed upstream to work with multiple net namespaces.] This should really fix the OOPS when doing: unshare(CLONE_NEWNET); exit(0); while the phonet module is loaded. Signed-off-by:
Rémi Denis-Courmont <remi.denis-courmont@nokia.com> Signed-off-by:
-
Ben Hutchings authored
commit ee9c5cfa upstream. niu_get_ethtool_tcam_all() assumes that its output buffer is the right size, and warns before returning if it is not. However, the output buffer size is under user control and ETHTOOL_GRXCLSRLALL is an unprivileged ethtool command. Therefore this is at least a local denial-of-service vulnerability. Change it to check before writing each entry and to return an error if the buffer is already full. Compile-tested only. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
-
FUJITA Tomonori authored
commit bb789d01 upstream. scsi_dma_map() returns -1 if an error occurred (zero means that the command has no data). So the following current code can't catch an error: sges_left = scsi_dma_map(scmd); if (!sges_left) { sdev_printk(KERN_ERR, scmd->device, "pci_map_sg" " failed: request for %d bytes!\n", scsi_bufflen(scmd)); return -ENOMEM; } Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by:
"Kashyap Desai" <Kashyap.Desai@lsi.com> Signed-off-by:
-
Ralf Baechle authored
commit 3b9c6c11 upstream. This only matters for ISA devices with a 24-bit DMA limit or for devices with a 32-bit DMA limit on systems with ZONE_DMA32 enabled. The latter currently only affects 32-bit PCI cards on Sibyte-based systems with more than 1GB RAM installed. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
James Chapman authored
commit c3259c8a upstream. This patch fixes UDP socket refcnt bugs in the pppol2tp driver. A bug can cause a kernel stack trace when a tunnel socket is closed. A way to reproduce the issue is to prepare the UDP socket for L2TP (by opening a tunnel pppol2tp socket) and then close it before any L2TP sessions are added to it. The sequence is Create UDP socket Create tunnel pppol2tp socket to prepare UDP socket for L2TP pppol2tp_connect: session_id=0, peer_session_id=0 L2TP SCCRP control frame received (tunnel_id==0) pppol2tp_recv_core: sock_hold() pppol2tp_recv_core: sock_put L2TP ZLB control frame received (tunnel_id=nnn) pppol2tp_recv_core: sock_hold() pppol2tp_recv_core: sock_put Close tunnel management socket pppol2tp_release: session_id=0, peer_session_id=0 Close UDP socket udp_lib_close: BUG The addition of sock_hold() in pppol2tp_connect() solves the problem. For data frames, two sock_put() calls were added to plug a refcnt leak per received data frame. The ref that is grabbed at the top of pppol2tp_recv_core() must always be released, but this wasn't done for accepted data frames or data frames discarded because of bad UDP checksums. This leak meant that any UDP socket that had passed L2TP data traffic (i.e. L2TP data frames, not just L2TP control frames) using pppol2tp would not be released by the kernel. WARNING: at include/net/sock.h:435 udp_lib_unhash+0x117/0x120() Pid: 1086, comm: openl2tpd Not tainted 2.6.33-rc1 #8 Call Trace: [<c119e9b7>] ? udp_lib_unhash+0x117/0x120 [<c101b871>] ? warn_slowpath_common+0x71/0xd0 [<c119e9b7>] ? udp_lib_unhash+0x117/0x120 [<c101b8e3>] ? warn_slowpath_null+0x13/0x20 [<c119e9b7>] ? udp_lib_unhash+0x117/0x120 [<c11598a7>] ? sk_common_release+0x17/0x90 [<c11a5e33>] ? inet_release+0x33/0x60 [<c11577b0>] ? sock_release+0x10/0x60 [<c115780f>] ? sock_close+0xf/0x30 [<c106e542>] ? __fput+0x52/0x150 [<c106b68e>] ? filp_close+0x3e/0x70 [<c101d2e2>] ? put_files_struct+0x62/0xb0 [<c101eaf7>] ? do_exit+0x5e7/0x650 [<c1081623>] ? mntput_no_expire+0x13/0x70 [<c106b68e>] ? filp_close+0x3e/0x70 [<c101eb8a>] ? do_group_exit+0x2a/0x70 [<c101ebe1>] ? sys_exit_group+0x11/0x20 [<c10029b0>] ? sysenter_do_call+0x12/0x26 Signed-off-by:
James Chapman <jchapman@katalix.com> Signed-off-by:
-
Romain Francoise authored
commit 2fdc1c80 upstream. When a network namespace is created (via CLONE_NEWNET), the loopback interface is automatically added to the new namespace, triggering a printk in ipv6_add_dev() if CONFIG_IPV6_PRIVACY is set. This is problematic for applications which use CLONE_NEWNET as part of a sandbox, like Chromium's suid sandbox or recent versions of vsftpd. On a busy machine, it can lead to thousands of useless "lo: Disabled Privacy Extensions" messages appearing in dmesg. It's easy enough to check the status of privacy extensions via the use_tempaddr sysctl, so just removing the printk seems like the most sensible solution. Signed-off-by:
Romain Francoise <romain@orebokech.com> Signed-off-by:
-
Jeff Mahoney authored
commit 25cca535 upstream. This patch removes D-Link DGE-550T PCI ID (1186:4000) from the ipg driver. The ipg driver is for IP2000-based cards and the DGE-550T is a DL2000-based card. The driver loads and works for a few moments, but once a real workload is applied it stops operating. The ipg driver claimed this ID since it was introduced in 2.6.24 and it's forced many users to blacklist it. The correct driver for this hardware is the dl2k driver, which has been claiming this PCI ID since the 2.4 days. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
-
David Woodhouse authored
commit 2d9e667e upstream. Certain revisions of this chipset appear to be broken. There is a shadow GTT which mirrors the real GTT but contains pre-translated physical addresses, for performance reasons. When a GTT update happens, the translations are done once and the resulting physical addresses written back to the shadow GTT. Except sometimes, the physical address is actually written back to the _real_ GTT, not the shadow GTT. Thus we start to see faults when that physical address is fed through translation again. Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
Edgar (gimli) Hucek authored
commit 99b9f758 upstream. This patch add support for the MacBookAir3,1 and MacBookAir3,2 to the hid driver. Signed-off-by:
Edgar (gimli) Hucek <gimli@dark-green.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Neil Horman authored
commit b3053251 upstream. Recently reported oops: kernel BUG at net/core/skbuff.c:813! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/virtual/net/bond0/broadcast CPU 8 Modules linked in: sit tunnel4 cpufreq_ondemand acpi_cpufreq freq_table bonding ipv6 dm_mirror dm_region_hash dm_log cdc_ether usbnet mii serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core bnx2 ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase scsi_transport_sas dm_mod [last unloaded: microcode] Modules linked in: sit tunnel4 cpufreq_ondemand acpi_cpufreq freq_table bonding ipv6 dm_mirror dm_region_hash dm_log cdc_ether usbnet mii serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core bnx2 ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase scsi_transport_sas dm_mod [last unloaded: microcode] Pid: 0, comm: swapper Not tainted 2.6.32-71.el6.x86_64 #1 BladeCenter HS22 -[7870AC1]- RIP: 0010:[<ffffffff81405b16>] [<ffffffff81405b16>] pskb_expand_head+0x36/0x1e0 RSP: 0018:ffff880028303b70 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff880c6458ec80 RCX: 0000000000000020 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880c6458ec80 RBP: ffff880028303bc0 R08: ffffffff818a6180 R09: ffff880c6458ed64 R10: ffff880c622b36c0 R11: 0000000000000400 R12: 0000000000000000 R13: 0000000000000180 R14: ffff880c622b3000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880028300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00000038653452a4 CR3: 0000000001001000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 0, threadinfo ffff8806649c2000, task ffff880c64f16ab0) Stack: ffff880028303bc0 ffffffff8104fff9 000000000000001c 0000000100000000 <0> ffff880000047d80 ffff880c6458ec80 000000000000001c ffff880c6223da00 <0> ffff880c622b3000 0000000000000000 ffff880028303c10 ffffffff81407f7a Call Trace: <IRQ> [<ffffffff8104fff9>] ? __wake_up_common+0x59/0x90 [<ffffffff81407f7a>] __pskb_pull_tail+0x2aa/0x360 [<ffffffffa0244530>] bond_arp_rcv+0x2c0/0x2e0 [bonding] [<ffffffff814a0857>] ? packet_rcv+0x377/0x440 [<ffffffff8140f21b>] netif_receive_skb+0x2db/0x670 [<ffffffff8140f788>] napi_skb_finish+0x58/0x70 [<ffffffff8140fc89>] napi_gro_receive+0x39/0x50 [<ffffffffa01286eb>] ixgbe_clean_rx_irq+0x35b/0x900 [ixgbe] [<ffffffffa01290f6>] ixgbe_clean_rxtx_many+0x136/0x240 [ixgbe] [<ffffffff8140fe53>] net_rx_action+0x103/0x210 [<ffffffff81073bd7>] __do_softirq+0xb7/0x1e0 [<ffffffff810d8740>] ? handle_IRQ_event+0x60/0x170 [<ffffffff810142cc>] call_softirq+0x1c/0x30 [<ffffffff81015f35>] do_softirq+0x65/0xa0 [<ffffffff810739d5>] irq_exit+0x85/0x90 [<ffffffff814cf915>] do_IRQ+0x75/0xf0 [<ffffffff81013ad3>] ret_from_intr+0x0/0x11 <EOI> [<ffffffff8101bc01>] ? mwait_idle+0x71/0xd0 [<ffffffff814cd80a>] ? atomic_notifier_call_chain+0x1a/0x20 [<ffffffff81011e96>] cpu_idle+0xb6/0x110 [<ffffffff814c17c8>] start_secondary+0x1fc/0x23f Resulted from bonding driver registering packet handlers via dev_add_pack and then trying to call pskb_may_pull. If another packet handler (like for AF_PACKET sockets) gets called first, the delivered skb will have a user count > 1, which causes pskb_may_pull to BUG halt when it does its skb_shared check. Fix this by calling skb_share_check prior to the may_pull call sites in the bonding driver to clone the skb when needed. Tested by myself and the reported successfully. Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: Jay Vosburgh <fubar@us.ibm.com> CC: "David S. Miller" <davem@davemloft.net> Signed-off-by:
Jay Vosburgh <fubar@us.ibm.com> Signed-off-by:
-
Edgar (gimli) Hucek authored
commit bd760e1e upstream. Add support for the MacBookAir3,1 and MacBookAir3,2 to the mbp-nvidia-bl driver. Signed-off-by:
Richard Purdie <rpurdie@linux.intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Peter Zijlstra authored
commit b433c3d4 upstream. Ilya reported that on a very slow machine he could reliably reproduce a race between forking init and kthreadd. We first fork init so that it obtains pid-1, however since the scheduler is already fully running at this point it can preempt and run the init thread before we spawn and set kthreadd_task. The init thread can then attempt spawning kthreads without kthreadd being present which results in an OOPS. Reported-by:
Ilya Loginov <isloginov@gmail.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Eric Dumazet authored
commit 9915672d upstream. Vegard Nossum found a unix socket OOM was possible, posting an exploit program. My analysis is we can eat all LOWMEM memory before unix_gc() being called from unix_release_sock(). Moreover, the thread blocked in unix_gc() can consume huge amount of time to perform cleanup because of huge working set. One way to handle this is to have a sensible limit on unix_tot_inflight, tested from wait_for_unix_gc() and to force a call to unix_gc() if this limit is hit. This solves the OOM and also reduce overall latencies, and should not slowdown normal workloads. Reported-by:
Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by:
-
Eric Dumazet authored
commit 25888e30 upstream. Its easy to eat all kernel memory and trigger NMI watchdog, using an exploit program that queues unix sockets on top of others. lkml ref : http://lkml.org/lkml/2010/11/25/8 This mechanism is used in applications, one choice we have is to have a recursion limit. Other limits might be needed as well (if we queue other types of files), since the passfd mechanism is currently limited by socket receive queue sizes only. Add a recursion_level to unix socket, allowing up to 4 levels. Each time we send an unix socket through sendfd mechanism, we copy its recursion level (plus one) to receiver. This recursion level is cleared when socket receive queue is emptied. Reported-by:
Марк Коренберг <socketpair@gmail.com> Signed-off-by:
-
Ben Hutchings authored
commit 6f88a440 upstream. Filesystem rebalancing (BTRFS_IOC_BALANCE) affects the entire filesystem and may run uninterruptibly for a long time. This does not seem to be something that an unprivileged user should be able to do. Reported-by:
Aron Xu <happyaron.xu@gmail.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com> Signed-off-by:
-
Jesse Brandeburg authored
commit e508be17 upstream. Several users report issues with 32-bit adapters when plugged into PCI slots in machines with >= 4GB ram. In particular AMD systems with HyperTransport to PCI bridges seem to trigger the issue, but it isn't limited to only them. This issue is not easily reproducible here, yet still continues to occur in the field. For e1000 on PCI devices, just disable DMA addresses over the 4GB boundary when in PCI (not PCI-X) mode, to prevent the issue from continuing to pop up. The performance impact for this is negligible. The code was refactored to move the init of the hw struct to its own function. This allows the init to be called very early in probe, which then allows using hw-> members for this fix. A slight refactor to the DMA mask code was done for minor correctness based on the instructions in DMA-API-HOWTO. Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Bruce Allan authored
commit 627c8a04 upstream. Reset the PHY before first accessing it. Doing so, ensure that the PHY is in a known good state before we read/write PHY registers. This fixes a driver probe failure. Signed-off-by:
Bruce Allan <bruce.w.allan@intel.com> Signed-off-by:
-
Oskar Schirmer authored
commit a7851ce7 upstream. cifs_root_iget allocates full_path through cifs_build_path_to_root, but fails to kfree it upon cifs_get_inode_info* failure. Make all failure exit paths traverse clean up handling at the end of the function. Signed-off-by:
Oskar Schirmer <oskar@scara.com> Signed-off-by:
Jesper Juhl <jj@chaosbits.net> Signed-off-by:
-
Mike Christie authored
commit 5738d444 upstream. blk_get_request sets the cmd_flags, so we should not and do not need to set them. If we did set them to a different value then it can cause a oops in the elevator code. Signed-off-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
-
Hannes Reinecke authored
commit 6c71dcb2 upstream. This patch fixes the request setup code for mode selects. I got the fixes from Hannes Reinecke while trying to hunt down some problems and merged it into one patch. I am sending it because Hannes is busy with other things. The patch fixes: - setting of the length for mode selects. - setting of the data direction for mode select 10. Signed-off-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
