Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
commit ae7859181482fcfe38d9352bd0932fa45456bdd0 Author: Greg Kroah-Hartman <[email protected]> Date: Fri Apr 5 10:18:27 2013 -0700 Linux 3.0.72 commit f6cab49c7b11abf9595b1bf9b6ff73931c832e2e Author: Veaceslav Falico <[email protected]> Date: Tue Apr 2 05:15:16 2013 +0000 bonding: get netdev_rx_handler_unregister out of locks [ Upstream commit fcd99434fb5c137274d2e15dd2a6a7455f0f29ff ] Now that netdev_rx_handler_unregister contains synchronize_net(), we need to call it outside of bond->lock, cause it might sleep. Also, remove the already unneded synchronize_net(). Signed-off-by: Veaceslav Falico <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 31f516f1f359bed25b6f6ebe5752326145303b3c Author: Joerg Roedel <[email protected]> Date: Tue Mar 26 22:48:23 2013 +0100 iommu/amd: Make sure dma_ops are set for hotplug devices commit c2a2876e863356b092967ea62bebdb4dd663af80 upstream. There is a bug introduced with commit 27c2127 that causes devices which are hot unplugged and then hot-replugged to not have per-device dma_ops set. This causes these devices to not function correctly. Fixed with this patch. Reported-by: Andreas Degert <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 5229aee5b9a28ac7b1c12ae988e1c8a49b217123 Author: Steve Glendinning <[email protected]> Date: Thu Mar 28 02:34:41 2013 +0000 smsc75xx: fix jumbo frame support [ Upstream commit 4c51e53689569398d656e631c17308d9b8e84650 ] This patch enables RX of jumbo frames for LAN7500. Previously the driver would transmit jumbo frames succesfully but would drop received jumbo frames (incrementing the interface errors count). With this patch applied the device can succesfully receive jumbo frames up to MTU 9000 (9014 bytes on the wire including ethernet header). Signed-off-by: Steve Glendinning <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3beceaf660dffbe11f5a5606ea379666eb9eaad0 Author: Veaceslav Falico <[email protected]> Date: Mon Mar 25 22:26:21 2013 +0000 pch_gbe: fix ip_summed checksum reporting on rx [ Upstream commit 76a0e68129d7d24eb995a6871ab47081bbfa0acc ] skb->ip_summed should be CHECKSUM_UNNECESSARY when the driver reports that checksums were correct and CHECKSUM_NONE in any other case. They're currently placed vice versa, which breaks the forwarding scenario. Fix it by placing them as described above. Signed-off-by: Veaceslav Falico <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit cb241ae254e1f4ee9a9f07e4a452b12cd674fffc Author: Eric Dumazet <[email protected]> Date: Fri Mar 29 03:01:22 2013 +0000 net: add a synchronize_net() in netdev_rx_handler_unregister() [ Upstream commit 00cfec37484761a44a3b6f4675a54caa618210ae ] commit 35d48903e97819 (bonding: fix rx_handler locking) added a race in bonding driver, reported by Steven Rostedt who did a very good diagnosis : <quoting Steven> I'm currently debugging a crash in an old 3.0-rt kernel that one of our customers is seeing. The bug happens with a stress test that loads and unloads the bonding module in a loop (I don't know all the details as I'm not the one that is directly interacting with the customer). But the bug looks to be something that may still be present and possibly present in mainline too. It will just be much harder to trigger it in mainline. In -rt, interrupts are threads, and can schedule in and out just like any other thread. Note, mainline now supports interrupt threads so this may be easily reproducible in mainline as well. I don't have the ability to tell the customer to try mainline or other kernels, so my hands are somewhat tied to what I can do. But according to a core dump, I tracked down that the eth irq thread crashed in bond_handle_frame() here: slave = bond_slave_get_rcu(skb->dev); bond = slave->bond; <--- BUG the slave returned was NULL and accessing slave->bond caused a NULL pointer dereference. Looking at the code that unregisters the handler: void netdev_rx_handler_unregister(struct net_device *dev) { ASSERT_RTNL(); RCU_INIT_POINTER(dev->rx_handler, NULL); RCU_INIT_POINTER(dev->rx_handler_data, NULL); } Which is basically: dev->rx_handler = NULL; dev->rx_handler_data = NULL; And looking at __netif_receive_skb() we have: rx_handler = rcu_dereference(skb->dev->rx_handler); if (rx_handler) { if (pt_prev) { ret = deliver_skb(skb, pt_prev, orig_dev); pt_prev = NULL; } switch (rx_handler(&skb)) { My question to all of you is, what stops this interrupt from happening while the bonding module is unloading? What happens if the interrupt triggers and we have this: CPU0 CPU1 ---- ---- rx_handler = skb->dev->rx_handler netdev_rx_handler_unregister() { dev->rx_handler = NULL; dev->rx_handler_data = NULL; rx_handler() bond_handle_frame() { slave = skb->dev->rx_handler; bond = slave->bond; <-- NULL pointer dereference!!! What protection am I missing in the bond release handler that would prevent the above from happening? </quoting Steven> We can fix bug this in two ways. First is adding a test in bond_handle_frame() and others to check if rx_handler_data is NULL. A second way is adding a synchronize_net() in netdev_rx_handler_unregister() to make sure that a rcu protected reader has the guarantee to see a non NULL rx_handler_data. The second way is better as it avoids an extra test in fast path. Reported-by: Steven Rostedt <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Cc: Jiri Pirko <[email protected]> Cc: Paul E. McKenney <[email protected]> Acked-by: Steven Rostedt <[email protected]> Reviewed-by: Paul E. McKenney <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3d2479580b8832251ab98dff289a88647e2d73bf Author: [email protected] <[email protected]> Date: Fri Mar 29 05:27:36 2013 +0000 ks8851: Fix interpretation of rxlen field. [ Upstream commit 14bc435ea54cb888409efb54fc6b76c13ef530e9 ] According to the Datasheet (page 52): 15-12 Reserved 11-0 RXBC Receive Byte Count This field indicates the present received frame byte size. The code has a bug: rxh = ks8851_rdreg32(ks, KS_RXFHSR); rxstat = rxh & 0xffff; rxlen = rxh >> 16; // BUG!!! 0xFFF mask should be applied Signed-off-by: Max Nekludov <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 79f0840fe9b4b304df53d24034744b6759352e17 Author: Hong Zhiguo <[email protected]> Date: Tue Mar 26 01:52:45 2013 +0800 ipv6: fix bad free of addrconf_init_net [ Upstream commit a79ca223e029aa4f09abb337accf1812c900a800 ] Signed-off-by: Hong Zhiguo <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit be409987531f89307e1cb281ff104209a085a5d7 Author: Mugunthan V N <[email protected]> Date: Thu Mar 28 18:10:50 2013 +0000 atl1e: drop pci-msi support because of packet corruption [ Upstream commit 188ab1b105c96656f6bcfb49d0d8bb1b1936b632 ] Usage of pci-msi results in corrupted dma packet transfers to the host. Reported-by: rebelyouth <[email protected]> Cc: Huang, Xiong <[email protected]> Tested-by: Christian Sünkenberg <[email protected]> Signed-off-by: Hannes Frederic Sowa <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 85d17d2226b60776d55260f8bf5c5db972136e72 Author: Mugunthan V N <[email protected]> Date: Wed Mar 27 04:42:00 2013 +0000 drivers: net: ethernet: davinci_emac: use netif_wake_queue() while restarting tx queue To restart tx queue use netif_wake_queue() intead of netif_start_queue() so that net schedule will restart transmission immediately which will increase network performance while doing huge data transfers. Reported-by: Dan Franke <[email protected]> Suggested-by: Sriramakrishnan A G <[email protected]> Signed-off-by: Mugunthan V N <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 5a37b9a3f61eced85a8398250f2fc89dbfdf1a10 Author: Eric Dumazet <[email protected]> Date: Wed Mar 27 18:28:41 2013 +0000 aoe: reserve enough headroom on skbs [ Upstream commit 91c5746425aed8f7188a351f1224a26aa232e4b3 ] Some network drivers use a non default hard_header_len Transmitted skb should take into account dev->hard_header_len, or risk crashes or expensive reallocations. In the case of aoe, lets reserve MAX_HEADER bytes. David reported a crash in defxx driver, solved by this patch. Reported-by: David Oostdyk <[email protected]> Tested-by: David Oostdyk <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Cc: Ed Cashin <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 92a33e58656098d3dbf538b3c1c86e6fcfbccb6c Author: Paul Moore <[email protected]> Date: Mon Mar 25 03:18:33 2013 +0000 unix: fix a race condition in unix_release() [ Upstream commit ded34e0fe8fe8c2d595bfa30626654e4b87621e0 ] As reported by Jan, and others over the past few years, there is a race condition caused by unix_release setting the sock->sk pointer to NULL before properly marking the socket as dead/orphaned. This can cause a problem with the LSM hook security_unix_may_send() if there is another socket attempting to write to this partially released socket in between when sock->sk is set to NULL and it is marked as dead/orphaned. This patch fixes this by only setting sock->sk to NULL after the socket has been marked as dead; I also take the opportunity to make unix_release_sock() a void function as it only ever returned 0/success. Dave, I think this one should go on the -stable pile. Special thanks to Jan for coming up with a reproducer for this problem. Reported-by: Jan Stancek <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0cbf0cbd285ef39202743ecfd62b4fe2dcdc81fd Author: Masatake YAMATO <[email protected]> Date: Mon Apr 1 14:50:40 2013 -0400 thermal: shorten too long mcast group name [ Upstream commits 73214f5d9f33b79918b1f7babddd5c8af28dd23d and f1e79e208076ffe7bad97158275f1c572c04f5c7, the latter adds an assertion to genetlink to prevent this from happening again in the future. ] The original name is too long. Signed-off-by: Masatake YAMATO <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9829fe9806e22d7a822f4c947cc432c8d1774b54 Author: Cong Wang <[email protected]> Date: Fri Mar 22 19:14:07 2013 +0000 8021q: fix a potential use-after-free [ Upstream commit 4a7df340ed1bac190c124c1601bfc10cde9fb4fb ] vlan_vid_del() could possibly free ->vlan_info after a RCU grace period, however, we may still refer to the freed memory area by 'grp' pointer. Found by code inspection. This patch moves vlan_vid_del() as behind as possible. Signed-off-by: Cong Wang <[email protected]> Cc: Patrick McHardy <[email protected]> Cc: "David S. Miller" <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 01326198867ce1ab1bb26acb48de7b06eab571fe Author: Yuchung Cheng <[email protected]> Date: Sun Mar 24 10:42:25 2013 +0000 tcp: undo spurious timeout after SACK reneging [ Upstream commit 7ebe183c6d444ef5587d803b64a1f4734b18c564 ] On SACK reneging the sender immediately retransmits and forces a timeout but disables Eifel (undo). If the (buggy) receiver does not drop any packet this can trigger a false slow-start retransmit storm driven by the ACKs of the original packets. This can be detected with undo and TCP timestamps. Signed-off-by: Yuchung Cheng <[email protected]> Acked-by: Neal Cardwell <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 06551316b51c5f140c29748011c37057cb7ba932 Author: Eric Dumazet <[email protected]> Date: Thu Mar 21 17:36:09 2013 +0000 tcp: preserve ACK clocking in TSO [ Upstream commit f4541d60a449afd40448b06496dcd510f505928e ] A long standing problem with TSO is the fact that tcp_tso_should_defer() rearms the deferred timer, while it should not. Current code leads to following bad bursty behavior : 20:11:24.484333 IP A > B: . 297161:316921(19760) ack 1 win 119 20:11:24.484337 IP B > A: . ack 263721 win 1117 20:11:24.485086 IP B > A: . ack 265241 win 1117 20:11:24.485925 IP B > A: . ack 266761 win 1117 20:11:24.486759 IP B > A: . ack 268281 win 1117 20:11:24.487594 IP B > A: . ack 269801 win 1117 20:11:24.488430 IP B > A: . ack 271321 win 1117 20:11:24.489267 IP B > A: . ack 272841 win 1117 20:11:24.490104 IP B > A: . ack 274361 win 1117 20:11:24.490939 IP B > A: . ack 275881 win 1117 20:11:24.491775 IP B > A: . ack 277401 win 1117 20:11:24.491784 IP A > B: . 316921:332881(15960) ack 1 win 119 20:11:24.492620 IP B > A: . ack 278921 win 1117 20:11:24.493448 IP B > A: . ack 280441 win 1117 20:11:24.494286 IP B > A: . ack 281961 win 1117 20:11:24.495122 IP B > A: . ack 283481 win 1117 20:11:24.495958 IP B > A: . ack 285001 win 1117 20:11:24.496791 IP B > A: . ack 286521 win 1117 20:11:24.497628 IP B > A: . ack 288041 win 1117 20:11:24.498459 IP B > A: . ack 289561 win 1117 20:11:24.499296 IP B > A: . ack 291081 win 1117 20:11:24.500133 IP B > A: . ack 292601 win 1117 20:11:24.500970 IP B > A: . ack 294121 win 1117 20:11:24.501388 IP B > A: . ack 295641 win 1117 20:11:24.501398 IP A > B: . 332881:351881(19000) ack 1 win 119 While the expected behavior is more like : 20:19:49.259620 IP A > B: . 197601:202161(4560) ack 1 win 119 20:19:49.260446 IP B > A: . ack 154281 win 1212 20:19:49.261282 IP B > A: . ack 155801 win 1212 20:19:49.262125 IP B > A: . ack 157321 win 1212 20:19:49.262136 IP A > B: . 202161:206721(4560) ack 1 win 119 20:19:49.262958 IP B > A: . ack 158841 win 1212 20:19:49.263795 IP B > A: . ack 160361 win 1212 20:19:49.264628 IP B > A: . ack 161881 win 1212 20:19:49.264637 IP A > B: . 206721:211281(4560) ack 1 win 119 20:19:49.265465 IP B > A: . ack 163401 win 1212 20:19:49.265886 IP B > A: . ack 164921 win 1212 20:19:49.266722 IP B > A: . ack 166441 win 1212 20:19:49.266732 IP A > B: . 211281:215841(4560) ack 1 win 119 20:19:49.267559 IP B > A: . ack 167961 win 1212 20:19:49.268394 IP B > A: . ack 169481 win 1212 20:19:49.269232 IP B > A: . ack 171001 win 1212 20:19:49.269241 IP A > B: . 215841:221161(5320) ack 1 win 119 Signed-off-by: Eric Dumazet <[email protected]> Cc: Yuchung Cheng <[email protected]> Cc: Van Jacobson <[email protected]> Cc: Neal Cardwell <[email protected]> Cc: Nandita Dukkipati <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 40e954e2b1e8f84eb1e0eb7af49bf4b9baa8a0ac Author: Mirko Lindner <[email protected]> Date: Tue Mar 26 06:38:42 2013 +0000 sky2: Threshold for Pause Packet is set wrong [ Upstream commit 74f9f42c1c1650e74fb464f76644c9041f996851 ] The sky2 driver sets the Rx Upper Threshold for Pause Packet generation to a wrong value which leads to only 2kB of RAM remaining space. This can lead to Rx overflow errors even with activated flow-control. Fix: We should increase the value to 8192/8 Signed-off-by: Mirko Lindner <[email protected]> Acked-by: Stephen Hemminger <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0b1a48cbcca9aa5aeed944c88c3d2b7c745d6f37 Author: Mirko Lindner <[email protected]> Date: Tue Mar 26 06:38:35 2013 +0000 sky2: Receive Overflows not counted [ Upstream commit 9cfe8b156c21cf340b3a10ecb3022fbbc1c39185 ] The sky2 driver doesn't count the Receive Overflows because the MAC interrupt for this event is not set in the MAC's interrupt mask. The MAC's interrupt mask is set only for Transmit FIFO Underruns. Fix: The correct setting should be (GM_IS_TX_FF_UR | GM_IS_RX_FF_OR) Otherwise the Receive Overflow event will not generate any interrupt. The Receive Overflow interrupt is handled correctly Signed-off-by: Mirko Lindner <[email protected]> Acked-by: Stephen Hemminger <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 396db58dbf922549ccc9c4c779419d9163da3224 Author: Steven Rostedt (Red Hat) <[email protected]> Date: Thu Mar 14 15:03:53 2013 -0400 tracing: Prevent buffer overwrite disabled for latency tracers commit 613f04a0f51e6e68ac6fe571ab79da3c0a5eb4da upstream. The latency tracers require the buffers to be in overwrite mode, otherwise they get screwed up. Force the buffers to stay in overwrite mode when latency tracers are enabled. Added a flag_changed() method to the tracer structure to allow the tracers to see what flags are being changed, and also be able to prevent the change from happing. [Backported for 3.4-stable. Re-added current_trace NULL checks; removed allocated_snapshot field; adapted to tracing_trace_options_write without trace_set_options.] Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Lingzhu Xiang <[email protected]> Reviewed-by: CAI Qian <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b9736c0eed0bfe68c89a269c89c3483d39ea1c83 Author: Steven Rostedt (Red Hat) <[email protected]> Date: Thu Mar 14 13:50:56 2013 -0400 tracing: Protect tracer flags with trace_types_lock commit 69d34da2984c95b33ea21518227e1f9470f11d95 upstream. Seems that the tracer flags have never been protected from synchronous writes. Luckily, admins don't usually modify the tracing flags via two different tasks. But if scripts were to be used to modify them, then they could get corrupted. Move the trace_types_lock that protects against tracers changing to also protect the flags being set. [Backported for 3.4, 3.0-stable. Moved return to after unlock.] Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Lingzhu Xiang <[email protected]> Reviewed-by: CAI Qian <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 503f4bdcc078e7abee273a85ce322de81b18a224 Author: Theodore Ts'o <[email protected]> Date: Mon Mar 11 23:39:59 2013 -0400 ext4: use atomic64_t for the per-flexbg free_clusters count commit 90ba983f6889e65a3b506b30dc606aa9d1d46cd2 upstream. A user who was using a 8TB+ file system and with a very large flexbg size (> 65536) could cause the atomic_t used in the struct flex_groups to overflow. This was detected by PaX security patchset: http://forums.grsecurity.net/viewtopic.php?f=3&t=3289&p=12551#p12551 This bug was introduced in commit 9f24e4208f7e, so it's been around since 2.6.30. :-( Fix this by using an atomic64_t for struct orlav_stats's free_clusters. [Backported for 3.0-stable. Renamed free_clusters back to free_blocks; fixed a few more atomic_read's of free_blocks left in 3.0.] Signed-off-by: "Theodore Ts'o" <[email protected]> Reviewed-by: Lukas Czerner <[email protected]> Signed-off-by: Lingzhu Xiang <[email protected]> Reviewed-by: CAI Qian <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 7fb54baf47818c2a76999ff907e2cecf25b98218 Author: Matt Fleming <[email protected]> Date: Thu Mar 7 11:59:14 2013 +0000 efivars: Handle duplicate names from get_next_variable() commit e971318bbed610e28bb3fde9d548e6aaf0a6b02e upstream. Some firmware exhibits a bug where the same VariableName and VendorGuid values are returned on multiple invocations of GetNextVariableName(). See, https://bugzilla.kernel.org/show_bug.cgi?id=47631 As a consequence of such a bug, Andre reports hitting the following WARN_ON() in the sysfs code after updating the BIOS on his, "Gigabyte Technology Co., Ltd. To be filled by O.E.M./Z77X-UD3H, BIOS F19e 11/21/2012)" machine, [ 0.581554] EFI Variables Facility v0.08 2004-May-17 [ 0.584914] ------------[ cut here ]------------ [ 0.585639] WARNING: at /home/andre/linux/fs/sysfs/dir.c:536 sysfs_add_one+0xd4/0x100() [ 0.586381] Hardware name: To be filled by O.E.M. [ 0.587123] sysfs: cannot create duplicate filename '/firmware/efi/vars/SbAslBufferPtrVar-01f33c25-764d-43ea-aeea-6b5a41f3f3e8' [ 0.588694] Modules linked in: [ 0.589484] Pid: 1, comm: swapper/0 Not tainted 3.8.0+ #7 [ 0.590280] Call Trace: [ 0.591066] [<ffffffff81208954>] ? sysfs_add_one+0xd4/0x100 [ 0.591861] [<ffffffff810587bf>] warn_slowpath_common+0x7f/0xc0 [ 0.592650] [<ffffffff810588bc>] warn_slowpath_fmt+0x4c/0x50 [ 0.593429] [<ffffffff8134dd85>] ? strlcat+0x65/0x80 [ 0.594203] [<ffffffff81208954>] sysfs_add_one+0xd4/0x100 [ 0.594979] [<ffffffff81208b78>] create_dir+0x78/0xd0 [ 0.595753] [<ffffffff81208ec6>] sysfs_create_dir+0x86/0xe0 [ 0.596532] [<ffffffff81347e4c>] kobject_add_internal+0x9c/0x220 [ 0.597310] [<ffffffff81348307>] kobject_init_and_add+0x67/0x90 [ 0.598083] [<ffffffff81584a71>] ? efivar_create_sysfs_entry+0x61/0x1c0 [ 0.598859] [<ffffffff81584b2b>] efivar_create_sysfs_entry+0x11b/0x1c0 [ 0.599631] [<ffffffff8158517e>] register_efivars+0xde/0x420 [ 0.600395] [<ffffffff81d430a7>] ? edd_init+0x2f5/0x2f5 [ 0.601150] [<ffffffff81d4315f>] efivars_init+0xb8/0x104 [ 0.601903] [<ffffffff8100215a>] do_one_initcall+0x12a/0x180 [ 0.602659] [<ffffffff81d05d80>] kernel_init_freeable+0x13e/0x1c6 [ 0.603418] [<ffffffff81d05586>] ? loglevel+0x31/0x31 [ 0.604183] [<ffffffff816a6530>] ? rest_init+0x80/0x80 [ 0.604936] [<ffffffff816a653e>] kernel_init+0xe/0xf0 [ 0.605681] [<ffffffff816ce7ec>] ret_from_fork+0x7c/0xb0 [ 0.606414] [<ffffffff816a6530>] ? rest_init+0x80/0x80 [ 0.607143] ---[ end trace 1609741ab737eb29 ]--- There's not much we can do to work around and keep traversing the variable list once we hit this firmware bug. Our only solution is to terminate the loop because, as Lingzhu reports, some machines get stuck when they encounter duplicate names, > I had an IBM System x3100 M4 and x3850 X5 on which kernel would > get stuck in infinite loop creating duplicate sysfs files because, > for some reason, there are several duplicate boot entries in nvram > getting GetNextVariableName into a circle of iteration (with > period > 2). Also disable the workqueue, as efivar_update_sysfs_entries() uses GetNextVariableName() to figure out which variables have been created since the last iteration. That algorithm isn't going to work if GetNextVariableName() returns duplicates. Note that we don't disable EFI variable creation completely on the affected machines, it's just that any pstore dump-* files won't appear in sysfs until the next boot. [Backported for 3.0-stable. Removed code related to pstore workqueue but pulled in helper function variable_is_present from a93bc0c; Moved the definition of __efivars to the top for being referenced in variable_is_present.] Reported-by: Andre Heider <[email protected]> Reported-by: Lingzhu Xiang <[email protected]> Tested-by: Lingzhu Xiang <[email protected]> Cc: Seiji Aguchi <[email protected]> Signed-off-by: Matt Fleming <[email protected]> Signed-off-by: Lingzhu Xiang <[email protected]> Reviewed-by: CAI Qian <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c2ff0153d27b39d87c1ff5f575c4ca7b52f33381 Author: Matt Fleming <[email protected]> Date: Fri Mar 1 14:49:12 2013 +0000 efivars: explicitly calculate length of VariableName commit ec50bd32f1672d38ddce10fb1841cbfda89cfe9a upstream. It's not wise to assume VariableNameSize represents the length of VariableName, as not all firmware updates VariableNameSize in the same way (some don't update it at all if EFI_SUCCESS is returned). There are even implementations out there that update VariableNameSize with values that are both larger than the string returned in VariableName and smaller than the buffer passed to GetNextVariableName(), which resulted in the following bug report from Michael Schroeder, > On HP z220 system (firmware version 1.54), some EFI variables are > incorrectly named : > > ls -d /sys/firmware/efi/vars/*8be4d* | grep -v -- -8be returns > /sys/firmware/efi/vars/dbxDefault-pport8be4df61-93ca-11d2-aa0d-00e098032b8c > /sys/firmware/efi/vars/KEKDefault-pport8be4df61-93ca-11d2-aa0d-00e098032b8c > /sys/firmware/efi/vars/SecureBoot-pport8be4df61-93ca-11d2-aa0d-00e098032b8c > /sys/firmware/efi/vars/SetupMode-Information8be4df61-93ca-11d2-aa0d-00e098032b8c The issue here is that because we blindly use VariableNameSize without verifying its value, we can potentially read garbage values from the buffer containing VariableName if VariableNameSize is larger than the length of VariableName. Since VariableName is a string, we can calculate its size by searching for the terminating NULL character. [Backported for 3.8-stable. Removed workqueue code added in a93bc0c 3.9-rc1.] Reported-by: Frederic Crozat <[email protected]> Cc: Matthew Garrett <[email protected]> Cc: Josh Boyer <[email protected]> Cc: Michael Schroeder <[email protected]> Cc: Lee, Chun-Yi <[email protected]> Cc: Lingzhu Xiang <[email protected]> Cc: Seiji Aguchi <[email protected]> Signed-off-by: Matt Fleming <[email protected]> Signed-off-by: Lingzhu Xiang <[email protected]> Reviewed-by: CAI Qian <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 22b2f9aaf4d832e4eef1b8a437e64db5f2f147d1 Author: Ville Syrjälä <[email protected]> Date: Fri Feb 22 16:53:38 2013 +0200 drm/i915: Don't clobber crtc->fb when queue_flip fails commit 4a35f83b2b7c6aae3fc0d1c4554fdc99dc33ad07 upstream. Restore crtc->fb to the old framebuffer if queue_flip fails. While at it, kill the pointless intel_fb temp variable. v2: Update crtc->fb before queue_flip and restore it back after a failure. [Backported for 3.0-stable. Adjusted context. Please cherry-pick commit 7317c75e66fce0c9f82fbe6f72f7e5256b315422 upstream before this patch as it provides necessary context and fixes a panic.] Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Reported-and-Tested-by: Mika Kuoppala <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Lingzhu Xiang <[email protected]> Reviewed-by: CAI Qian <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 08b2dce495f36f35e2759446a0ed94c66a05a0c5 Author: Jesse Barnes <[email protected]> Date: Mon Aug 29 09:45:28 2011 -0700 drm/i915: don't set unpin_work if vblank_get fails commit 7317c75e66fce0c9f82fbe6f72f7e5256b315422 upstream. This fixes a race where we may try to finish a page flip and decrement the refcount even if our vblank_get failed and we ended up with a spurious flip pending interrupt. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=34211. Signed-off-by: Jesse Barnes <[email protected]> Signed-off-by: Keith Packard <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 7e36f505caf7882b6cc89ecedcd7f26749ef917a Author: J. Bruce Fields <[email protected]> Date: Tue Mar 26 14:11:13 2013 -0400 nfsd4: reject "negative" acl lengths commit 64a817cfbded8674f345d1117b117f942a351a69 upstream. Since we only enforce an upper bound, not a lower bound, a "negative" length can get through here. The symptom seen was a warning when we attempt to a kmalloc with an excessive size. Reported-by: Toralf Förster <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 582b4c3dc62284aec367a3f4f74ce8101303e9c4 Author: Anatol Pomozov <[email protected]> Date: Mon Apr 1 09:47:56 2013 -0700 loop: prevent bdev freeing while device in use commit c1681bf8a7b1b98edee8b862a42c19c4e53205fd upstream. struct block_device lifecycle is defined by its inode (see fs/block_dev.c) - block_device allocated first time we access /dev/loopXX and deallocated on bdev_destroy_inode. When we create the device "losetup /dev/loopXX afile" we want that block_device stay alive until we destroy the loop device with "losetup -d". But because we do not hold /dev/loopXX inode its counter goes 0, and inode/bdev can be destroyed at any moment. Usually it happens at memory pressure or when user drops inode cache (like in the test below). When later in loop_clr_fd() we want to use bdev we have use-after-free error with following stack: BUG: unable to handle kernel NULL pointer dereference at 0000000000000280 bd_set_size+0x10/0xa0 loop_clr_fd+0x1f8/0x420 [loop] lo_ioctl+0x200/0x7e0 [loop] lo_compat_ioctl+0x47/0xe0 [loop] compat_blkdev_ioctl+0x341/0x1290 do_filp_open+0x42/0xa0 compat_sys_ioctl+0xc1/0xf20 do_sys_open+0x16e/0x1d0 sysenter_dispatch+0x7/0x1a To prevent use-after-free we need to grab the device in loop_set_fd() and put it later in loop_clr_fd(). The issue is reprodusible on current Linus head and v3.3. Here is the test: dd if=/dev/zero of=loop.file bs=1M count=1 while [ true ]; do losetup /dev/loop0 loop.file echo 2 > /proc/sys/vm/drop_caches losetup -d /dev/loop0 done [ Doing bdgrab/bput in loop_set_fd/loop_clr_fd is safe, because every time we call loop_set_fd() we check that loop_device->lo_state is Lo_unbound and set it to Lo_bound If somebody will try to set_fd again it will get EBUSY. And if we try to loop_clr_fd() on unbound loop device we'll get ENXIO. loop_set_fd/loop_clr_fd (and any other loop ioctl) is called under loop_device->lo_ctl_mutex. ] Signed-off-by: Anatol Pomozov <[email protected]> Cc: Al Viro <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 956fc762ae9fb5f8cf6cd456f508ad431a4653b7 Author: Petr Matousek <[email protected]> Date: Tue Mar 19 12:36:59 2013 +0100 KVM: x86: invalid opcode oops on SET_SREGS with OSXSAVE bit set (CVE-2012-4461) commit 6d1068b3a98519247d8ba4ec85cd40ac136dbdf9 upstream. On hosts without the XSAVE support unprivileged local user can trigger oops similar to the one below by setting X86_CR4_OSXSAVE bit in guest cr4 register using KVM_SET_SREGS ioctl and later issuing KVM_RUN ioctl. invalid opcode: 0000 [#2] SMP Modules linked in: tun ip6table_filter ip6_tables ebtable_nat ebtables ... Pid: 24935, comm: zoog_kvm_monito Tainted: G D 3.2.0-3-686-pae EIP: 0060:[<f8b9550c>] EFLAGS: 00210246 CPU: 0 EIP is at kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm] EAX: 00000001 EBX: 000f387e ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: ef5a0060 ESP: d7c63e70 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process zoog_kvm_monito (pid: 24935, ti=d7c62000 task=ed84a0c0 task.ti=d7c62000) Stack: 00000001 f70a1200 f8b940a9 ef5a0060 00000000 00200202 f8769009 00000000 ef5a0060 000f387e eda5c020 8722f9c8 00015bae 00000000 ed84a0c0 ed84a0c0 c12bf02d 0000ae80 ef7f8740 fffffffb f359b740 ef5a0060 f8b85dc1 0000ae80 Call Trace: [<f8b940a9>] ? kvm_arch_vcpu_ioctl_set_sregs+0x2fe/0x308 [kvm] ... [<c12bfb44>] ? syscall_call+0x7/0xb Code: 89 e8 e8 14 ee ff ff ba 00 00 04 00 89 e8 e8 98 48 ff ff 85 c0 74 1e 83 7d 48 00 75 18 8b 85 08 07 00 00 31 c9 8b 95 0c 07 00 00 <0f> 01 d1 c7 45 48 01 00 00 00 c7 45 1c 01 00 00 00 0f ae f0 89 EIP: [<f8b9550c>] kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm] SS:ESP 0068:d7c63e70 QEMU first retrieves the supported features via KVM_GET_SUPPORTED_CPUID and then sets them later. So guest's X86_FEATURE_XSAVE should be masked out on hosts without X86_FEATURE_XSAVE, making kvm_set_cr4 with X86_CR4_OSXSAVE fail. Userspaces that allow specifying guest cpuid with X86_FEATURE_XSAVE even on hosts that do not support it, might be susceptible to this attack from inside the guest as well. Allow setting X86_CR4_OSXSAVE bit only if host has XSAVE support. Signed-off-by: Petr Matousek <[email protected]> Signed-off-by: Marcelo Tosatti <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit d9e61dba0c73294e9e6761f290dce2049f06bfac Author: Jiang Liu <[email protected]> Date: Tue Mar 19 12:36:58 2013 +0100 mm/hotplug: correctly add new zone to all other nodes' zone lists commit 08dff7b7d629807dbb1f398c68dd9cd58dd657a1 upstream. When online_pages() is called to add new memory to an empty zone, it rebuilds all zone lists by calling build_all_zonelists(). But there's a bug which prevents the new zone to be added to other nodes' zone lists. online_pages() { build_all_zonelists() ..... node_set_state(zone_to_nid(zone), N_HIGH_MEMORY) } Here the node of the zone is put into N_HIGH_MEMORY state after calling build_all_zonelists(), but build_all_zonelists() only adds zones from nodes in N_HIGH_MEMORY state to the fallback zone lists. build_all_zonelists() ->__build_all_zonelists() ->build_zonelists() ->find_next_best_node() ->for_each_node_state(n, N_HIGH_MEMORY) So memory in the new zone will never be used by other nodes, and it may cause strange behavor when system is under memory pressure. So put node into N_HIGH_MEMORY state before calling build_all_zonelists(). Signed-off-by: Jianguo Wu <[email protected]> Signed-off-by: Jiang Liu <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Minchan Kim <[email protected]> Cc: Rusty Russell <[email protected]> Cc: Yinghai Lu <[email protected]> Cc: Tony Luck <[email protected]> Cc: KAMEZAWA Hiroyuki <[email protected]> Cc: KOSAKI Motohiro <[email protected]> Cc: David Rientjes <[email protected]> Cc: Keping Chen <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 16df76518569ae25da4c3750ad4bab65ef2aa900 Author: Avi Kivity <[email protected]> Date: Tue Mar 19 12:36:57 2013 +0100 KVM: Fix buffer overflow in kvm_set_irq() commit f2ebd422f71cda9c791f76f85d2ca102ae34a1ed upstream. kvm_set_irq() has an internal buffer of three irq routing entries, allowing connecting a GSI to three IRQ chips or on MSI. However setup_routing_entry() does not properly enforce this, allowing three irqchip routes followed by an MSI route to overflow the buffer. Fix by ensuring that an MSI entry is added to an empty list. Signed-off-by: Avi Kivity <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit d1cc80b94858666cc48467e8e166ccf389551b5d Author: Jason Wang <[email protected]> Date: Tue Mar 19 12:36:56 2013 +0100 macvtap: zerocopy: validate vectors before building skb commit b92946e2919134ebe2a4083e4302236295ea2a73 upstream. There're several reasons that the vectors need to be validated: - Return error when caller provides vectors whose num is greater than UIO_MAXIOV. - Linearize part of skb when userspace provides vectors grater than MAX_SKB_FRAGS. - Return error when userspace provides vectors whose total length may exceed - MAX_SKB_FRAGS * PAGE_SIZE. Signed-off-by: Jason Wang <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Benjamin Poirier <[email protected]> [patch reduced to the 3rd reason only for 3.0] Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 8868daebc1b6240d07d5c6428f8bc8631b2bed42 Author: Avi Kivity <[email protected]> Date: Tue Mar 19 12:36:55 2013 +0100 KVM: Ensure all vcpus are consistent with in-kernel irqchip settings commit 3e515705a1f46beb1c942bb8043c16f8ac7b1e9e upstream. If some vcpus are created before KVM_CREATE_IRQCHIP, then irqchip_in_kernel() and vcpu->arch.apic will be inconsistent, leading to potential NULL pointer dereferences. Fix by: - ensuring that no vcpus are installed when KVM_CREATE_IRQCHIP is called - ensuring that a vcpu has an apic if it is installed after KVM_CREATE_IRQCHIP This is somewhat long winded because vcpu->arch.apic is created without kvm->lock held. Based on earlier patch by Michael Ellerman. Signed-off-by: Michael Ellerman <[email protected]> Signed-off-by: Avi Kivity <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2c34b4ae8f8228e1ec083be0333426eca4a31357 Author: Chuck Lever <[email protected]> Date: Tue Mar 19 12:36:54 2013 +0100 NFS: nfs_getaclargs.acl_len is a size_t commit 56d08fef2369d5ca9ad2e1fc697f5379fd8af751 upstream. Squelch compiler warnings: fs/nfs/nfs4proc.c: In function ‘__nfs4_get_acl_uncached’: fs/nfs/nfs4proc.c:3811:14: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] fs/nfs/nfs4proc.c:3818:15: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] Introduced by commit bf118a34 "NFSv4: include bitmap in nfsv4 get acl data", Dec 7, 2011. Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 01b140abad66f022ff6dff7cc1307b07281035fa Author: Trond Myklebust <[email protected]> Date: Tue Mar 19 12:36:53 2013 +0100 NFSv4: Fix an Oops in the NFSv4 getacl code commit 331818f1c468a24e581aedcbe52af799366a9dfe upstream. Commit bf118a342f10dafe44b14451a1392c3254629a1f (NFSv4: include bitmap in nfsv4 get acl data) introduces the 'acl_scratch' page for the case where we may need to decode multi-page data. However it fails to take into account the fact that the variable may be NULL (for the case where we're not doing multi-page decode), and it also attaches it to the encoding xdr_stream rather than the decoding one. The immediate result is an Oops in nfs4_xdr_enc_getacl due to the call to page_address() with a NULL page pointer. Signed-off-by: Trond Myklebust <[email protected]> Cc: Andy Adamson <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c938c22b48302eeb9a6f3cc83f223f37d98ba6f7 Author: Andy Adamson <[email protected]> Date: Tue Mar 19 12:36:52 2013 +0100 NFSv4: include bitmap in nfsv4 get acl data commit bf118a342f10dafe44b14451a1392c3254629a1f upstream. The NFSv4 bitmap size is unbounded: a server can return an arbitrary sized bitmap in an FATTR4_WORD0_ACL request. Replace using the nfs4_fattr_bitmap_maxsz as a guess to the maximum bitmask returned by a server with the inclusion of the bitmap (xdr length plus bitmasks) and the acl data xdr length to the (cached) acl page data. This is a general solution to commit e5012d1f "NFSv4.1: update nfs4_fattr_bitmap_maxsz" and fixes hitting a BUG_ON in xdr_shrink_bufhead when getting ACLs. Fix a bug in decode_getacl that returned -EINVAL on ACLs > page when getxattr was called with a NULL buffer, preventing ACL > PAGE_SIZE from being retrieved. Signed-off-by: Andy Adamson <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0072625c351588b8fde9e6f46fb60ba2e521fb47 Author: Jan Kiszka <[email protected]> Date: Tue Mar 19 12:36:51 2013 +0100 KVM: x86: Prevent starting PIT timers in the absence of irqchip support commit 0924ab2cfa98b1ece26c033d696651fd62896c69 upstream. User space may create the PIT and forgets about setting up the irqchips. In that case, firing PIT IRQs will crash the host: BUG: unable to handle kernel NULL pointer dereference at 0000000000000128 IP: [<ffffffffa10f6280>] kvm_set_irq+0x30/0x170 [kvm] ... Call Trace: [<ffffffffa11228c1>] pit_do_work+0x51/0xd0 [kvm] [<ffffffff81071431>] process_one_work+0x111/0x4d0 [<ffffffff81071bb2>] worker_thread+0x152/0x340 [<ffffffff81075c8e>] kthread+0x7e/0x90 [<ffffffff815a4474>] kernel_thread_helper+0x4/0x10 Prevent this by checking the irqchip mode before starting a timer. We can't deny creating the PIT if the irqchips aren't set up yet as current user land expects this order to work. Signed-off-by: Jan Kiszka <[email protected]> Signed-off-by: Marcelo Tosatti <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2e8e2c7847cc17a8135ad17869f5ba37207e2f89 Author: Sven Eckelmann <[email protected]> Date: Tue Mar 19 12:36:50 2013 +0100 batman-adv: Only write requested number of byte to user buffer commit b5a1eeef04cc7859f34dec9b72ea1b28e4aba07c upstream. Don't write more than the requested number of bytes of an batman-adv icmp packet to the userspace buffer. Otherwise unrelated userspace memory might get overridden by the kernel. Signed-off-by: Sven Eckelmann <[email protected]> Signed-off-by: Marek Lindner <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 19c0a0f3f768551fc708ebc9b2345e5dcc248d3a Author: Paul Kot <[email protected]> Date: Tue Mar 19 12:36:49 2013 +0100 batman-adv: bat_socket_read missing checks commit c00b6856fc642b234895cfabd15b289e76726430 upstream. Writing a icmp_packet_rr and then reading icmp_packet can lead to kernel memory corruption, if __user *buf is just below TASK_SIZE. Signed-off-by: Paul Kot <[email protected]> [[email protected]: made it checkpatch clean] Signed-off-by: Sven Eckelmann <[email protected]> Signed-off-by: Marek Lindner <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 7f3ea0c12493c9ff38a13a89bcf08846b50c1f1c Author: Matthew Daley <[email protected]> Date: Tue Mar 19 12:36:48 2013 +0100 x25: Handle undersized/fragmented skbs commit cb101ed2c3c7c0224d16953fe77bfb9d6c2cb9df upstream. There are multiple locations in the X.25 packet layer where a skb is assumed to be of at least a certain size and that all its data is currently available at skb->data. These assumptions are not checked, hence buffer overreads may occur. Use pskb_may_pull to check these minimal size assumptions and ensure that data is available at skb->data when necessary, as well as use skb_copy_bits where needed. Signed-off-by: Matthew Daley <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Andrew Hendry <[email protected]> Acked-by: Andrew Hendry <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 21f9f5219401be3815db41e60072a53dadf828b6 Author: Matthew Daley <[email protected]> Date: Tue Mar 19 12:36:47 2013 +0100 x25: Validate incoming call user data lengths commit c7fd0d48bde943e228e9c28ce971a22d6a1744c4 upstream. X.25 call user data is being copied in its entirety from incoming messages without consideration to the size of the destination buffers, leading to possible buffer overflows. Validate incoming call user data lengths before these copies are performed. It appears this issue was noticed some time ago, however nothing seemed to come of it: see http://www.spinics.net/lists/linux-x25/msg00043.html and commit 8db09f26f912f7c90c764806e804b558da520d4f. Signed-off-by: Matthew Daley <[email protected]> Acked-by: Eric Dumazet <[email protected]> Tested-by: Andrew Hendry <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit d104388ff9bdb5ec76d5337cd94f9ed4bbf73fbc Author: Jan Kiszka <[email protected]> Date: Tue Mar 19 12:36:46 2013 +0100 KVM: Clean up error handling during VCPU creation commit d780592b99d7d8a5ff905f6bacca519d4a342c76 upstream. So far kvm_arch_vcpu_setup is responsible for freeing the vcpu struct if it fails. Move this confusing resonsibility back into the hands of kvm_vm_ioctl_create_vcpu. Only kvm_arch_vcpu_setup of x86 is affected, all other archs cannot fail. Signed-off-by: Jan Kiszka <[email protected]> Signed-off-by: Avi Kivity <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 8c7028941242372574880e513207abdbe486c3e5 Author: Josef Bacik <[email protected]> Date: Tue Mar 26 15:31:45 2013 -0400 Btrfs: limit the global reserve to 512mb commit fdf30d1c1b386e1b73116cc7e0fb14e962b763b0 upstream. A user reported a problem where he was getting early ENOSPC with hundreds of gigs of free data space and 6 gigs of free metadata space. This is because the global block reserve was taking up the entire free metadata space. This is ridiculous, we have infrastructure in place to throttle if we start using too much of the global reserve, so instead of letting it get this huge just limit it to 512mb so that users can still get work done. This allowed the user to complete his rsync without issues. Thanks Reported-and-tested-by: Stefan Priebe <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 98b3faa6da804a4cbb5aa205fac0933585d49444 Author: Vivek Gautam <[email protected]> Date: Thu Mar 21 12:06:48 2013 +0530 usb: xhci: Fix TRB transfer length macro used for Event TRB. commit 1c11a172cb30492f5f6a82c6e118fdcd9946c34f upstream. Use proper macro while extracting TRB transfer length from Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23) for the same, and use it instead of TRB_LEN (bits 0:16) in case of event TRBs. This patch should be backported to kernels as old as 2.6.31, that contain the commit b10de142119a676552df3f0d2e3a9d647036c26a "USB: xhci: Bulk transfer support". This patch will have issues applying to older kernels. Signed-off-by: Vivek gautam <[email protected]> Signed-off-by: Sarah Sharp <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c7eff9734960f1730b0373b2635e8e055592c318 Author: Kees Cook <[email protected]> Date: Wed Mar 20 05:19:24 2013 +0000 net/irda: add missing error path release_sock call commit 896ee0eee6261e30c3623be931c3f621428947df upstream. This makes sure that release_sock is called for all error conditions in irda_getsockopt. Signed-off-by: Kees Cook <[email protected]> Reported-by: Brad Spengler <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b9f1f48ce20a1b923429c216669d03b5a900a8cf Author: Bing Zhao <[email protected]> Date: Fri Mar 15 18:47:07 2013 -0700 mwifiex: cancel cmd timer and free curr_cmd in shutdown process commit 084c7189acb3f969c855536166042e27f5dd703f upstream. curr_cmd points to the command that is in processing or waiting for its command response from firmware. If the function shutdown happens to occur at this time we should cancel the cmd timer and put the command back to free queue. Tested-by: Marco Cesarano <[email protected]> Signed-off-by: Bing Zhao <[email protected]> Signed-off-by: John W. Linville <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 8cc034e4c1b7901787bbf72908bc584c055b5e09 Author: Al Viro <[email protected]> Date: Tue Mar 26 20:30:17 2013 -0400 vt: synchronize_rcu() under spinlock is not nice... commit e8cd81693bbbb15db57d3c9aa7dd90eda4842874 upstream. vcs_poll_data_free() calls unregister_vt_notifier(), which calls atomic_notifier_chain_unregister(), which calls synchronize_rcu(). Do it *after* we'd dropped ->f_lock. Signed-off-by: Al Viro <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 19c85a53434ec90c1c6d6b0717e1eb37c5f2f84d Author: Konstantin Holoborodko <[email protected]> Date: Fri Mar 29 00:06:13 2013 +0900 usb: ftdi_sio: Add support for Mitsubishi FX-USB-AW/-BD commit 482b0b5d82bd916cc0c55a2abf65bdc69023b843 upstream. It enhances the driver for FTDI-based USB serial adapters to recognize Mitsubishi Electric Corp. USB/RS422 Converters as FT232BM chips and support them. https://search.meau.com/?q=FX-USB-AW Signed-off-by: Konstantin Holoborodko <[email protected]> Tested-by: Konstantin Holoborodko <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 460c49749ae56b5f49454ad0ce0066f80a14c385 Author: Jan Beulich <[email protected]> Date: Mon Mar 11 09:39:55 2013 +0000 xen-blkback: fix dispatch_rw_block_io() error path commit 0e5e098ac22dae38f957e951b70d3cf73beff0f7 upstream. Commit 7708992 ("xen/blkback: Seperate the bio allocation and the bio submission") consolidated the pendcnt updates to just a single write, neglecting the fact that the error path relied on it getting set to 1 up front (such that the decrement in __end_block_io_op() would actually drop the count to zero, triggering the necessary cleanup actions). Also remove a misleading and a stale (after said commit) comment. Signed-off-by: Jan Beulich <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 1c9c0901afba44cf1353505b72e146e7f87a54b6 Author: Iestyn C. Elfick <[email protected]> Date: Wed Mar 20 14:02:31 2013 -0500 b43: A fix for DMA transmission sequence errors commit b251412db99ccd4495ce372fec7daee27bf06923 upstream. Intermittently, b43 will report "Out of order TX status report on DMA ring". When this happens, the driver must be reset before communication can resume. The cause of the problem is believed to be an error in the closed-source firmware; however, all versions of the firmware are affected. This change uses the observation that the expected status is always 2 less than the observed value, and supplies a fake status report to skip one header/data pair. Not all devices suffer from this problem, but it can occur several times per second under heavy load. As each occurence kills the unmodified driver, this patch makes if possible for the affected devices to function. The patch logs only the first instance of the reset operation to prevent spamming the logs. Tested-by: Chris Vine <[email protected]> Signed-off-by: Larry Finger <[email protected]> Signed-off-by: John W. Linville <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b76c1eabd474cd44937fc60a26be2b926a366e55 Author: Ming Lei <[email protected]> Date: Wed Mar 20 23:25:25 2013 +0800 sysfs: handle failure path correctly for readdir() commit e5110f411d2ee35bf8d202ccca2e89c633060dca upstream. In case of 'if (filp->f_pos == 0 or 1)' of sysfs_readdir(), the failure from filldir() isn't handled, and the reference counter of the sysfs_dirent object pointed by filp->private_data will be released without clearing filp->private_data, so use after free bug will be triggered later. This patch returns immeadiately under the situation for fixing the bug, and it is reasonable to return from readdir() when filldir() fails. Reported-by: Dave Jones <[email protected]> Tested-by: Sasha Levin <[email protected]> Signed-off-by: Ming Lei <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit f366c8f271888f48e15cc7c0ab70f184c220c8a4 Author: Ming Lei <[email protected]> Date: Wed Mar 20 23:25:24 2013 +0800 sysfs: fix race between readdir and lseek commit 991f76f837bf22c5bb07261cfd86525a0a96650c upstream. While readdir() is running, lseek() may set filp->f_pos as zero, then may leave filp->private_data pointing to one sysfs_dirent object without holding its reference counter, so the sysfs_dirent object may be used after free in next readdir(). This patch holds inode->i_mutex to avoid the problem since the lock is always held in readdir path. Reported-by: Dave Jones <[email protected]> Tested-by: Sasha Levin <[email protected]> Signed-off-by: Ming Lei <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3d8c163a2ecea7dd6c2c9efd68b6348ef0248733 Author: Ian Abbott <[email protected]> Date: Fri Mar 22 15:16:29 2013 +0000 staging: comedi: s626: fix continuous acquisition commit e4317ce877a31dbb9d96375391c1c4ad2210d637 upstream. For the s626 driver, there is a bug in the handling of asynchronous commands on the AI subdevice when the stop source is `TRIG_NONE`. The command should run continuously until cancelled, but the interrupt handler stops the command running after the first scan. The command set-up function `s626_ai_cmd()` contains this code: switch (cmd->stop_src) { case TRIG_COUNT: /* data arrives as one packet */ devpriv->ai_sample_count = cmd->stop_arg; devpriv->ai_continous = 0; break; case TRIG_NONE: /* continous acquisition */ devpriv->ai_continous = 1; devpriv->ai_sample_count = 0; break; } The interrupt handler `s626_irq_handler()` contains this code: if (!(devpriv->ai_continous)) devpriv->ai_sample_count--; if (devpriv->ai_sample_count <= 0) { devpriv->ai_cmd_running = 0; /* ... */ } So `devpriv->ai_sample_count` is only decremented for the `TRIG_COUNT` case, but `devpriv->ai_cmd_running` is set to 0 (and the command stopped) regardless. Fix this in `s626_ai_cmd()` by setting `devpriv->ai_sample_count = 1` for the `TRIG_NONE` case. The interrupt handler will not decrement it so it will remain greater than 0 and the check for stopping the acquisition will fail. Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9a0f79c84c9966f19cb44e1c37344faf30ed5e22 Author: Ming Lei <[email protected]> Date: Mon Mar 18 23:45:11 2013 +0800 Bluetooth: Add support for Dell[QCA 0cf3:817a] commit ebaf5795ef57a70a042ea259448a465024e2821d upstream. Add support for the AR9462 chip T: Bus=03 Lev=01 Prnt=01 Port=08 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=817a Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Ming Lei <[email protected]> Cc: Gustavo Padovan <[email protected]> Signed-off-by: Gustavo Padovan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 54f0a27d68535e728a0d7780cc809d97895ce3f9 Author: Ming Lei <[email protected]> Date: Fri Mar 15 11:00:39 2013 +0800 Bluetooth: Add support for Dell[QCA 0cf3:0036] commit d66629c1325399cf080ba8b2fb086c10e5439cdd upstream. Add support for the AR9462 chip T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=0036 Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Ming Lei <[email protected]> Cc: Gustavo Padovan <[email protected]> Signed-off-by: Gustavo Padovan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3d422b3c8954fa7228c4606b2af1e5c46783c566 Author: Vinicius Costa Gomes <[email protected]> Date: Wed Mar 13 19:46:20 2013 -0300 Bluetooth: Fix not closing SCO sockets in the BT_CONNECT2 state commit eb20ff9c91ddcb2d55c1849a87d3db85af5e88a9 upstream. With deferred setup for SCO, it is possible that userspace closes the socket when it is in the BT_CONNECT2 state, after the Connect Request is received but before the Accept Synchonous Connection is sent. If this happens the following crash was observed, when the connection is terminated: [ +0.000003] hci_sync_conn_complete_evt: hci0 status 0x10 [ +0.000005] sco_connect_cfm: hcon ffff88003d1bd800 bdaddr 40:98:4e:32:d7:39 status 16 [ +0.000003] sco_conn_del: hcon ffff88003d1bd800 conn ffff88003cc8e300, err 110 [ +0.000015] BUG: unable to handle kernel NULL pointer dereference at 0000000000000199 [ +0.000906] IP: [<ffffffff810620dd>] __lock_acquire+0xed/0xe82 [ +0.000000] PGD 3d21f067 PUD 3d291067 PMD 0 [ +0.000000] Oops: 0002 [#1] SMP [ +0.000000] Modules linked in: rfcomm bnep btusb bluetooth [ +0.000000] CPU 0 [ +0.000000] Pid: 1481, comm: kworker/u:2H Not tainted 3.9.0-rc1-25019-gad82cdd #1 Bochs Bochs [ +0.000000] RIP: 0010:[<ffffffff810620dd>] [<ffffffff810620dd>] __lock_acquire+0xed/0xe82 [ +0.000000] RSP: 0018:ffff88003c3c19d8 EFLAGS: 00010002 [ +0.000000] RAX: 0000000000000001 RBX: 0000000000000246 RCX: 0000000000000000 [ +0.000000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88003d1be868 [ +0.000000] RBP: ffff88003c3c1a98 R08: 0000000000000002 R09: 0000000000000000 [ +0.000000] R10: ffff88003d1be868 R11: ffff88003e20b000 R12: 0000000000000002 [ +0.000000] R13: ffff88003aaa8000 R14: 000000000000006e R15: ffff88003d1be850 [ +0.000000] FS: 0000000000000000(0000) GS:ffff88003e200000(0000) knlGS:0000000000000000 [ +0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ +0.000000] CR2: 0000000000000199 CR3: 000000003c1cb000 CR4: 00000000000006b0 [ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ +0.000000] Process kworker/u:2H (pid: 1481, threadinfo ffff88003c3c0000, task ffff88003aaa8000) [ +0.000000] Stack: [ +0.000000] ffffffff81b16342 0000000000000000 0000000000000000 ffff88003d1be868 [ +0.000000] …
- Loading branch information
1 parent
6f58de4
commit 0b0a151