- 20 May, 2012 40 commits
-
-
Chris Metcalf authored
commit a134d228 upstream. This passes siginfo and mcontext to tilegx32 signal handlers that don't have SA_SIGINFO set just as we have been doing for tilegx64. Signed-off-by:
Chris Metcalf <cmetcalf@tilera.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Russell King authored
commit 9b61a4d1 upstream. Reported-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Dan Williams authored
commit 4e6304b8 upstream. Needs to be tagged with FLAG_WWAN, which since it has generic descriptors, won't happen if we don't override the generic driver info. Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by:
Dan Williams <dcbw@redhat.com> Acked-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Ming Lei authored
commit 5b6e9bcd upstream. Commit 4231d47e(net/usbnet: avoid recursive locking in usbnet_stop()) fixes the recursive locking problem by releasing the skb queue lock before unlink, but may cause skb traversing races: - after URB is unlinked and the queue lock is released, the refered skb and skb->next may be moved to done queue, even be released - in skb_queue_walk_safe, the next skb is still obtained by next pointer of the last skb - so maybe trigger oops or other problems This patch extends the usage of entry->state to describe 'start_unlink' state, so always holding the queue(rx/tx) lock to change the state if the referd skb is in rx or tx queue because we need to know if the refered urb has been started unlinking in unlink_urbs. The other part of this patch is based on Huajun's patch: always traverse from head of the tx/rx queue to get skb which is to be unlinked but not been started unlinking. Signed-off-by:
Huajun Li <huajun.li.lee@gmail.com> Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Cc: Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Mark Brown authored
commit c7f5f238 upstream. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Takashi Iwai authored
commit b0791dda upstream. BIOS on some HP laptops don't set the speaker-pins as fixed but expose as jacks, and this confuses the driver as if these pins are jack-detectable. As a result, the machine doesn't get sounds from speakers because the driver prepares the power-map update via jack unsol events which never come up in reality. The bug was introduced in some time in 3.2 for enabling the power-mapping feature. This patch fixes the problem by replacing the check of the persistent power-map bits with a proper is_jack_detectable() call. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43240Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Alexander Clouter authored
commit 1ebfefcf upstream. Without CRYPTO_HASH being selected, mv_cesa has a lot of hooks into undefined exports. ---- MODPOST 81 modules Kernel: arch/arm/boot/Image is ready AS arch/arm/boot/compressed/head.o GZIP arch/arm/boot/compressed/piggy.gzip CC arch/arm/boot/compressed/misc.o CC arch/arm/boot/compressed/decompress.o ERROR: "crypto_ahash_type" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_shash_final" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_register_ahash" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_unregister_ahash" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_shash_update" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_shash_digest" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_shash_setkey" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_alloc_shash" [drivers/crypto/mv_cesa.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 make: *** Waiting for unfinished jobs.... ---- Signed-off-by:
Alexander Clouter <alex@digriz.org.uk> Signed-off-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Bernhard Kohl authored
commit edc318d9 upstream. This patch addresses a bug in a special case for target core SPC-2 RELEASE logic where the same physical client (eg: iSCSI InitiatorName) with differing iSCSI session identifiers (ISID) is allowed to incorrectly release the same client's SPC-2 reservation from the non reservation holding path. Note this bug is specific to iscsi-target w/ SPC-2 reservations, and with the default enforce_pr_isids=1 device attr setting in target-core controls if a InitiatorName + different ISID reservations are handled the same as a single iSCSI client entity. Signed-off-by:
Bernhard Kohl <bernhard.kohl@gmx.net> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Will Deacon authored
commit 998de4ac upstream. The vfp_enable function enables access to the VFP co-processor register space (cp10 and cp11) on the current CPU and must be called with preemption disabled. Unfortunately, the vfp_init late initcall does not disable preemption and can lead to an oops during boot if thread migration occurs at the wrong time and we end up attempting to access the FPSID on a CPU with VFP access disabled. This patch fixes the initcall to call vfp_enable from a non-preemptible context on each CPU and adds a BUG_ON(preemptible) to ensure that any similar problems are easily spotted in the future. Reported-by:
Hyungwoo Yang <hwoo.yang@gmail.com> Signed-off-by:
Hyungwoo Yang <hyungwooy@nvidia.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Arend van Spriel authored
commit 5e379203 upstream. The A-MPDU code checked against a retry limit, but it was using the wrong variable to do so. This patch fixes this to assure proper retry mechanism. This problem had a side-effect causing the mac80211 flush callback to remain waiting forever as well. That side effect has been fixed by commit by Stanislaw Gruszka: commit f96b08a7 Date: Tue Jan 17 12:38:50 2012 +0100 brcmsmac: fix tx queue flush infinite loop Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42576 Cc: Stanislaw Gruszka <sgruszka@redhat.com> Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by:
Alwin Beukers <alwin@broadcom.com> Signed-off-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Émeric Maschino authored
commit 65cc21b4 upstream. While debugging udev > 170 failure on Debian Wheezy (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648325), it appears that the issue was in fact due to missing accept4() in ia64. This patch simply adds accept4() to ia64. Signed-off-by:
Émeric Maschino <emeric.maschino@gmail.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Eric Sandeen authored
commit c1bb05a6 upstream. Processes hang forever on a sync-mounted ext2 file system that is mounted with the ext4 module (default in Fedora 16). I can reproduce this reliably by mounting an ext2 partition with "-o sync" and opening a new file an that partition with vim. vim will hang in "D" state forever. The same happens on ext4 without a journal. I am attaching a small patch here that solves this issue for me. In the sync mounted case without a journal, ext4_handle_dirty_metadata() may call sync_dirty_buffer(), which can't be called with buffer lock held. Also move mb_cache_entry_release inside lock to avoid race fixed previously by 8a2bfdcb ext[34]: EA block reference count racing fix Note too that ext2 fixed this same problem in 2006 with b2f49033 [PATCH] fix deadlock in ext2 Signed-off-by: Martin.Wilck@ts.fujitsu.com [sandeen@redhat.com: move mb_cache_entry_release before unlock, edit commit msg] Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Tomoya MORINAGA authored
commit 0f57e168 upstream. Currently, pch_spi_start_transfer failure is not anticipated. This patch adds the processing. Signed-off-by:
Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by:
Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
-
Tomoya MORINAGA authored
commit f258b44e upstream. This patch supports a spi mode setup and bit order setup by IO control. spi mode: mode 0 to mode 3 bit order: LSB first, MSB first Signed-off-by:
-
Tomoya MORINAGA authored
commit 7d05b3e8 upstream. Currently, when spi-topcliff-pch receives transmit request over 4KByte, this driver can't process correctly. This driver needs to divide the data into 4Kbyte unit. This patch fixes the issue. Signed-off-by:
-
Tomoya MORINAGA authored
commit ee2ece52 upstream. Signed-off-by:
-
Axel Lin authored
commit 7e3a70fb upstream. This bug was introduced by commit 54be5663 "gpio-ml-ioh: Support interrupt function" which adds a spinlock to struct ioh_gpio but never init the spinlock. Signed-off-by:
Axel Lin <axel.lin@gmail.com> Signed-off-by:
-
David S. Miller authored
[ Upstream commit a5a737e0 ] %g2 is meant to hold the CPUID number throughout this routine, since at the very beginning, and at the very end, we use %g2 to calculate indexes into per-cpu arrays. However we erroneously clobber it in order to hold the %cwp register value mid-stream. Fix this code to use %g3 for the %cwp read and related calulcations instead. Reported-by:
Meelis Roos <mroos@linux.ee> Signed-off-by:
-
Mike Snitzer authored
commit 510193a2 upstream. If the requested scsi_dh module is already loaded then skip request_module(). Multipath table loads can hang in an unnecessary __request_module. Reported-by:
Ben Marzinski <bmarzins@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
-
Sylwester Nawrocki authored
commit e985dbf7 upstream. When setting TRY crop on the sub-device the mutex was erroneously acquired rather than released on exit path. This bug is present in kernels starting from v3.2. Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Josh Cartwright authored
commit 226bb7df upstream. The locking policy is such that the erase_complete_block spinlock is nested within the alloc_sem mutex. This fixes a case in which the acquisition order was erroneously reversed. This issue was caught by the following lockdep splat: ======================================================= [ INFO: possible circular locking dependency detected ] 3.0.5 #1 ------------------------------------------------------- jffs2_gcd_mtd6/299 is trying to acquire lock: (&c->alloc_sem){+.+.+.}, at: [<c01f7714>] jffs2_garbage_collect_pass+0x314/0x890 but task is already holding lock: (&(&c->erase_completion_lock)->rlock){+.+...}, at: [<c01f7708>] jffs2_garbage_collect_pass+0x308/0x890 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&(&c->erase_completion_lock)->rlock){+.+...}: [<c008bec4>] validate_chain+0xe6c/0x10bc [<c008c660>] __lock_acquire+0x54c/0xba4 [<c008d240>] lock_acquire+0xa4/0x114 [<c046780c>] _raw_spin_lock+0x3c/0x4c [<c01f744c>] jffs2_garbage_collect_pass+0x4c/0x890 [<c01f937c>] jffs2_garbage_collect_thread+0x1b4/0x1cc [<c0071a68>] kthread+0x98/0xa0 [<c000f264>] kernel_thread_exit+0x0/0x8 -> #0 (&c->alloc_sem){+.+.+.}: [<c008ad2c>] print_circular_bug+0x70/0x2c4 [<c008c08c>] validate_chain+0x1034/0x10bc [<c008c660>] __lock_acquire+0x54c/0xba4 [<c008d240>] lock_acquire+0xa4/0x114 [<c0466628>] mutex_lock_nested+0x74/0x33c [<c01f7714>] jffs2_garbage_collect_pass+0x314/0x890 [<c01f937c>] jffs2_garbage_collect_thread+0x1b4/0x1cc [<c0071a68>] kthread+0x98/0xa0 [<c000f264>] kernel_thread_exit+0x0/0x8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&(&c->erase_completion_lock)->rlock); lock(&c->alloc_sem); lock(&(&c->erase_completion_lock)->rlock); lock(&c->alloc_sem); *** DEADLOCK *** 1 lock held by jffs2_gcd_mtd6/299: #0: (&(&c->erase_completion_lock)->rlock){+.+...}, at: [<c01f7708>] jffs2_garbage_collect_pass+0x308/0x890 stack backtrace: [<c00155dc>] (unwind_backtrace+0x0/0x100) from [<c0463dc0>] (dump_stack+0x20/0x24) [<c0463dc0>] (dump_stack+0x20/0x24) from [<c008ae84>] (print_circular_bug+0x1c8/0x2c4) [<c008ae84>] (print_circular_bug+0x1c8/0x2c4) from [<c008c08c>] (validate_chain+0x1034/0x10bc) [<c008c08c>] (validate_chain+0x1034/0x10bc) from [<c008c660>] (__lock_acquire+0x54c/0xba4) [<c008c660>] (__lock_acquire+0x54c/0xba4) from [<c008d240>] (lock_acquire+0xa4/0x114) [<c008d240>] (lock_acquire+0xa4/0x114) from [<c0466628>] (mutex_lock_nested+0x74/0x33c) [<c0466628>] (mutex_lock_nested+0x74/0x33c) from [<c01f7714>] (jffs2_garbage_collect_pass+0x314/0x890) [<c01f7714>] (jffs2_garbage_collect_pass+0x314/0x890) from [<c01f937c>] (jffs2_garbage_collect_thread+0x1b4/0x1cc) [<c01f937c>] (jffs2_garbage_collect_thread+0x1b4/0x1cc) from [<c0071a68>] (kthread+0x98/0xa0) [<c0071a68>] (kthread+0x98/0xa0) from [<c000f264>] (kernel_thread_exit+0x0/0x8) This was introduce in '81cfc9f1 jffs2: Fix serious write stall due to erase'. Signed-off-by:
Josh Cartwright <joshc@linux.com> Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Bjørn Mork authored
commit 6eddcb4c upstream. Some RNDIS devices include a bogus CDC Union descriptor pointing to non-existing interfaces. The RNDIS code is already prepared to handle devices without a CDC Union descriptor by hardwiring the driver to use interfaces 0 and 1, which is correct for the devices with the bogus descriptor as well. So we can reuse the existing workaround. Cc: Markus Kolb <linux-201011@tower-net.de> Cc: Iker Salmón San Millán <shaola@esdebian.org> Cc: Jonathan Nieder <jrnieder@gmail.com> Cc: Oliver Neukum <oliver@neukum.org> Cc: 655387@bugs.debian.org Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Luis Henriques authored
commit 9ef449c6 upstream. An early registration of an ISR was causing a crash to several users (for example, with the ite-cir driver: http://bugs.launchpad.net/bugs/972723). The reason was that IRQs were being triggered before a driver initialisation was completed. This patch fixes this by moving the invocation to request_irq() and to request_region() to a later stage on the driver probe function. Signed-off-by:
Luis Henriques <luis.henriques@canonical.com> Acked-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
-
Jonathan Corbet authored
commit 9967232f upstream. One of the OLPC changes lost a little in its translation to mainline, leading to build errors on the ARM architecture. Remove the offending line, and all will be well. Reported-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Nicholas Bellinger authored
commit cfebf8f4 upstream. This patch removes some potentially problematic legacy code within core_clear_initiator_node_from_tpg() that was originally intended to release left over se_lun_acl setup during dynamic NodeACL+MappedLUN generate when running with TPG demo-mode operation. Since we now only ever expect to allocate and release se_lun_acl from within target_core_fabric_configfs.c:target_fabric_make_mappedlun() and target_fabric_drop_mappedlun() context respectively, this code for demo-mode release is incorrect and needs to be removed. Cc: Christoph Hellwig <hch@lst.de> Cc: Andy Grover <agrover@redhat.com> Signed-off-by:
-
Jonathan Nieder authored
This is a shorter (and more appropriate for stable kernels) analog to the following upstream commit: commit 6926afd1 Author: Trond Myklebust <Trond.Myklebust@netapp.com> Date: Sat Jan 7 13:22:46 2012 -0500 NFSv4: Save the owner/group name string when doing open ...so that we can do the uid/gid mapping outside the asynchronous RPC context. This fixes a bug in the current NFSv4 atomic open code where the client isn't able to determine what the true uid/gid fields of the file are, (because the asynchronous nature of the OPEN call denies it the ability to do an upcall) and so fills them with default values, marking the inode as needing revalidation. Unfortunately, in some cases, the VFS will do some additional sanity checks on the file, and may override the server's decision to allow the open because it sees the wrong owner/group fields. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Without this patch, logging into two different machines with home directories mounted over NFS4 and then running "vim" and typing ":q" in each reliably produces the following error on the second machine: E137: Viminfo file is not writable: /users/system/rtheys/.viminfo This regression was introduced by 80e52ace ("NFSv4: Don't do idmapper upcalls for asynchronous RPC calls", merged during the 2.6.32 cycle) --- after the OPEN call, .viminfo has the default values for st_uid and st_gid (0xfffffffe) cached because we do not want to let rpciod wait for an idmapper upcall to fill them in. The fix used in mainline is to save the owner and group as strings and perform the upcall in _nfs4_proc_open outside the rpciod context, which takes about 600 lines. For stable, we can do something similar with a one-liner: make open check for the stale fields and make a (synchronous) GETATTR call to fill them when needed. Trond dictated the patch, I typed it in, and Rik tested it. Addresses http://bugs.debian.org/659111 and https://bugzilla.redhat.com/789298Reported-by:
Rik Theys <Rik.Theys@esat.kuleuven.be> Explained-by:
David Flyn <davidf@rd.bbc.co.uk> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Tested-by:
-
Srinivas Kandagatla authored
[ Upstream commit b3300146 ] This patch fixes Auto Power Saving configuration in ip101a_config_init which was broken as there is no phy register write followed after setting IP101A_APS_ON flag. This patch also fixes the return value of ip101a_config_init. Without this patch ip101a_config_init returns 2 which is not an error accroding to IS_ERR and the mac driver will continue accessing 2 as valid pointer to phy_dev resulting in memory fault. Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@st.com> Signed-off-by:
-
Jonathan Nieder authored
[Not needed upstream --- this bug is specific to 3.2.y.] Commit c6c44893, which removes the flag argument from brcms_b_mute, is not part of 3.2.y, and we forgot to adjust a new call accordingly when applying commit badc4f07 ("brcm80211: smac: resume transmit fifo upon receiving frames"). drivers/net/wireless/brcm80211/brcmsmac/main.c: In function 'brcms_c_recvctl': drivers/net/wireless/brcm80211/brcmsmac/main.c:7882:4: error: too few arguments to function 'brcms_b_mute' drivers/net/wireless/brcm80211/brcmsmac/main.c:2538:13: note: declared here Earlier build tests missed this because they didn't include this driver due to 'depends on BCMA=n'. Reported-by:
-
Eric Dumazet authored
[ Upstream commit b49960a0 ] tcp_adv_win_scale default value is 2, meaning we expect a good citizen skb to have skb->len / skb->truesize ratio of 75% (3/4) In 2.6 kernels we (mis)accounted for typical MSS=1460 frame : 1536 + 64 + 256 = 1856 'estimated truesize', and 1856 * 3/4 = 1392. So these skbs were considered as not bloated. With recent truesize fixes, a typical MSS=1460 frame truesize is now the more precise : 2048 + 256 = 2304. But 2304 * 3/4 = 1728. So these skb are not good citizen anymore, because 1460 < 1728 (GRO can escape this problem because it build skbs with a too low truesize.) This also means tcp advertises a too optimistic window for a given allocated rcvspace : When receiving frames, sk_rmem_alloc can hit sk_rcvbuf limit and we call tcp_prune_queue()/tcp_collapse() too often, especially when application is slow to drain its receive queue or in case of losses (netperf is fast, scp is slow). This is a major latency source. We should adjust the len/truesize ratio to 50% instead of 75% This patch : 1) changes tcp_adv_win_scale default to 1 instead of 2 2) increase tcp_rmem[2] limit from 4MB to 6MB to take into account better truesize tracking and to allow autotuning tcp receive window to reach same value than before. Note that same amount of kernel memory is consumed compared to 2.6 kernels. Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Neal Cardwell <ncardwell@google.com> Cc: Tom Herbert <therbert@google.com> Cc: Yuchung Cheng <ycheng@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
-
Yuchung Cheng authored
[ Upstream commit 1cebce36 ] When the cwnd reduction is done, ssthresh may be infinite if TCP enters CWR via ECN or F-RTO. If cwnd is not undone, i.e., undo_marker is set, tcp_complete_cwr() falsely set cwnd to the infinite ssthresh value. The correct operation is to keep cwnd intact because it has been updated in ECN or F-RTO. Signed-off-by:
Yuchung Cheng <ycheng@google.com> Acked-by:
-
Matt Carlson authored
[ Upstream commit f891ea16 ] When RSS is enabled, interrupt vector 0 does not receive any rx traffic. The rx producer index fields for vector 0's status block should be considered reserved in this case. This patch changes the code to respect these reserved fields, which avoids a kernel panic when these fields take on non-zero values. Signed-off-by:
Matt Carlson <mcarlson@broadcom.com> Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
-
Gerard Lledo authored
[ Upstream commit 5a8887d3 ] WakeOnLan was broken in this driver because gp->asleep_wol is a 1-bit bitfield and it was being assigned WAKE_MAGIC, which is (1 << 5). gp->asleep_wol remains 0 and the machine never wakes up. Fixed by casting gp->wake_on_lan to bool. Tested on an iBook G4. Signed-off-by:
Gerard Lledo <gerard.lledo@gmail.com> Signed-off-by:
-
stephen hemminger authored
[ Upstream commit e072b3fa ] Bug: The VLAN bit of the MAC RX Status Word is unreliable in several older supported chips. Sometimes the VLAN bit is not set for valid VLAN packets and also sometimes the VLAN bit is set for non-VLAN packets that came after a VLAN packet. This results in a receive length error when VLAN hardware tagging is enabled. Fix: Variation on original fix proposed by Mirko. The VLAN information is decoded in the status loop, and can be applied to the received SKB there. This eliminates the need for the separate tag field in the interface data structure. The tag has to be copied and cleared if packet is copied. This version checked out with vlan and normal traffic. Note: vlan_tx_tag_present should be renamed vlan_tag_present, but that is outside scope of this. Reported-by:
Mirko Lindner <mlindner@marvell.com> Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
stephen hemminger authored
[ Upstream commit 3f42941b ] When a small packet is received, the driver copies it to a new skb to allow reusing the full size Rx buffer. The copy was propogating the checksum offload but not the receive hash information. The bug is impact was mostly harmless and therefore not observed until reviewing this area of code. Signed-off-by:
-
Sasha Levin authored
[ Upstream commit 84768edb ] l2tp_ip_sendmsg could return without releasing socket lock, making it all the way to userspace, and generating the following warning: [ 130.891594] ================================================ [ 130.894569] [ BUG: lock held when returning to user space! ] [ 130.897257] 3.4.0-rc5-next-20120501-sasha #104 Tainted: G W [ 130.900336] ------------------------------------------------ [ 130.902996] trinity/8384 is leaving the kernel with locks still held! [ 130.906106] 1 lock held by trinity/8384: [ 130.907924] #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff82b9503f>] l2tp_ip_sendmsg+0x2f/0x550 Introduced by commit 2f16270f ("l2tp: Fix locking in l2tp_ip.c"). Signed-off-by:
Sasha Levin <levinsasha928@gmail.com> Acked-by:
-
Eric W. Biederman authored
[ Upstream commit 7d3d43da ] We already synthesize events in register_netdevice_notifier and synthesizing events in unregister_netdevice_notifier allows to us remove the need for special case cleanup code. This change should be safe as it adds no new cases for existing callers of unregiser_netdevice_notifier to handle. Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 116a0fc3 ] skb_checksum_help(skb) can return an error, we must free skb in this case. qdisc_drop(skb, sch) can also be feeded with a NULL skb (if skb_unshare() failed), so lets use this generic helper. Signed-off-by:
-
Ingo van Lil authored
[ Upstream commit 2a580949 ] The asix.c USB Ethernet driver avoids ending a tx transfer with a zero- length packet by appending a four-byte padding to transfers whose length is a multiple of maxpacket. However, the hard-coded 512 byte maxpacket length is valid for high-speed USB only; full-speed USB uses 64 byte packets. Signed-off-by:
Ingo van Lil <inguin@gmx.de> Signed-off-by:
-
Russ Anderson authored
commit 6bc2e853 upstream. Systems with 8 TBytes of memory or greater can hit a problem where only the the first 8 TB of memory shows up. This is due to "int i" being smaller than "unsigned long start_aligned", causing the high bits to be dropped. The fix is to change `i' to unsigned long to match start_aligned and end_aligned. Thanks to Jack Steiner for assistance tracking this down. Signed-off-by:
Russ Anderson <rja@sgi.com> Cc: Jack Steiner <steiner@sgi.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Tejun Heo <tj@kernel.org> Cc: David S. Miller <davem@davemloft.net> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Mike Galbraith authored
commit 5e2bf014 upstream. Fork() failure post namespace creation for a child cloned with CLONE_NEWPID leaks pid_namespace/mnt_cache due to proc being mounted during creation, but not unmounted during cleanup. Call pid_ns_release_proc() during cleanup. Signed-off-by:
Mike Galbraith <efault@gmx.de> Acked-by:
Oleg Nesterov <oleg@redhat.com> Reviewed-by:
-
