commit f88df5ff96f5ea632aa2d193d2c9019aa4c728d9 Author: Greg Kroah-Hartman Date: Sun Oct 28 10:36:33 2012 -0700 Linux 3.4.16 commit f2a713d25e8b95e065c90af72f461e99427e20f8 Author: Brian Norris Date: Fri Jul 13 09:28:24 2012 -0700 mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver commit bf7a01bf7987b63b121d572b240c132ec44129c4 upstream. The NAND_CHIPOPTIONS_MSK has limited utility and is causing real bugs. It silently masks off at least one flag that might be set by the driver (NAND_NO_SUBPAGE_WRITE). This breaks the GPMI NAND driver and possibly others. Really, as long as driver writers exercise a small amount of care with NAND_* options, this mask is not necessary at all; it was only here to prevent certain options from accidentally being set by the driver. But the original thought turns out to be a bad idea occasionally. Thus, kill it. Note, this patch fixes some major gpmi-nand breakage. Signed-off-by: Brian Norris Tested-by: Huang Shijie Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 3ba595416b15151d2eaa12578c17cbfd64c06aec Author: David S. Miller Date: Wed Aug 15 00:37:29 2012 -0700 sparc64: Be less verbose during vmemmap population. [ Upstream commit 2856cc2e4d0852c3ddaae9dcb19cb9396512eb08 ] On a 2-node machine with 256GB of ram we get 512 lines of console output, which is just too much. This mimicks Yinghai Lu's x86 commit c2b91e2eec9678dbda274e906cc32ea8f711da3b (x86_64/mm: check and print vmemmap allocation continuous) except that we aren't ever going to get contiguous block pointers in between calls so just print when the virtual address or node changes. This decreases the output by an order of 16. Also demote this to KERN_DEBUG. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d37bcccee1b807af77b5c6767cb0df295f9dfbdb Author: Jiri Kosina Date: Wed Aug 1 21:10:51 2012 +0200 sparc64: do not clobber personality flags in sys_sparc64_personality() [ Upstream commit a27032eee8cb6e16516f13c8a9752e9d5d4cc430 ] There are multiple errors in how sys_sparc64_personality() handles personality flags stored in top three bytes. - directly comparing current->personality against PER_LINUX32 doesn't work in cases when any of the personality flags stored in the top three bytes are used. - directly forcefully setting personality to PER_LINUX32 or PER_LINUX discards any flags stored in the top three bytes Fix the first one by properly using personality() macro to compare only PER_MASK bytes. Fix the second one by setting only the bits that should be set, instead of overwriting the whole value. Signed-off-by: Jiri Kosina Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f603fa368be8342b2bee401ac6c815e6e34b3373 Author: David S. Miller Date: Tue Oct 16 13:05:25 2012 -0700 sparc64: Fix bit twiddling in sparc_pmu_enable_event(). [ Upstream commit e793d8c6740f8fe704fa216e95685f4d92c4c4b9 ] There was a serious disconnect in the logic happening in sparc_pmu_disable_event() vs. sparc_pmu_enable_event(). Event disable is implemented by programming a NOP event into the PCR. However, event enable was not reversing this operation. Instead, it was setting the User/Priv/Hypervisor trace enable bits. That's not sparc_pmu_enable_event()'s job, that's what sparc_pmu_enable() and sparc_pmu_disable() do . The intent of sparc_pmu_enable_event() is clear, since it first clear out the event type encoding field. So fix this by OR'ing in the event encoding rather than the trace enable bits. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 846514fcb8f4518aa88636542bb7aa8453faacb2 Author: David S. Miller Date: Sun Oct 14 17:59:40 2012 -0700 sparc64: Like x86 we should check current->mm during perf backtrace generation. [ Upstream commit 08280e6c4c2e8049ac61d9e8e3536ec1df629c0d ] If the MM is not active, only report the top-level PC. Do not try to access the address space. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 01afdbe150a888b20b24a427e010214530176cf5 Author: Al Viro Date: Wed Oct 10 17:25:00 2012 -0700 sparc64: fix ptrace interaction with force_successful_syscall_return() [ Upstream commit 55c2770e413e96871147b9406a9c41fe9bc5209c ] we want syscall_trace_leave() called on exit from any syscall; skipping its call in case we'd done force_successful_syscall_return() is broken... Signed-off-by: Al Viro Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dd2c50efa9941fe7393b5f490eeef68f18916211 Author: Eric Dumazet Date: Tue Oct 16 07:37:27 2012 +0000 ipv6: addrconf: fix /proc/net/if_inet6 [ Upstream commit 9f0d3c2781baa1102108e16efbe640dd74564a7c ] Commit 1d5783030a1 (ipv6/addrconf: speedup /proc/net/if_inet6 filling) added bugs hiding some devices from if_inet6 and breaking applications. "ip -6 addr" could still display all IPv6 addresses, while "ifconfig -a" couldnt. One way to reproduce the bug is by starting in a shell : unshare -n /bin/bash ifconfig lo up And in original net namespace, lo device disappeared from if_inet6 Reported-by: Jan Hinnerk Stosch Tested-by: Jan Hinnerk Stosch Signed-off-by: Eric Dumazet Cc: Mihai Maruseac Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 259c5a7fd824ebca122f04fc4202b88896f31d26 Author: Alexey Kuznetsov Date: Fri Oct 12 04:34:17 2012 +0000 tcp: resets are misrouted [ Upstream commit 4c67525849e0b7f4bd4fab2487ec9e43ea52ef29 ] After commit e2446eaa ("tcp_v4_send_reset: binding oif to iif in no sock case").. tcp resets are always lost, when routing is asymmetric. Yes, backing out that patch will result in misrouting of resets for dead connections which used interface binding when were alive, but we actually cannot do anything here. What's died that's died and correct handling normal unbound connections is obviously a priority. Comment to comment: > This has few benefits: > 1. tcp_v6_send_reset already did that. It was done to route resets for IPv6 link local addresses. It was a mistake to do so for global addresses. The patch fixes this as well. Actually, the problem appears to be even more serious than guaranteed loss of resets. As reported by Sergey Soloviev , those misrouted resets create a lot of arp traffic and huge amount of unresolved arp entires putting down to knees NAT firewalls which use asymmetric routing. Signed-off-by: Alexey Kuznetsov Signed-off-by: Greg Kroah-Hartman commit 04c592343f478826bf1e5d0d178bb295d848c428 Author: jeff.liu Date: Mon Oct 8 18:57:27 2012 +0000 RDS: fix rds-ping spinlock recursion [ Upstream commit 5175a5e76bbdf20a614fb47ce7a38f0f39e70226 ] This is the revised patch for fixing rds-ping spinlock recursion according to Venkat's suggestions. RDS ping/pong over TCP feature has been broken for years(2.6.39 to 3.6.0) since we have to set TCP cork and call kernel_sendmsg() between ping/pong which both need to lock "struct sock *sk". However, this lock has already been hold before rds_tcp_data_ready() callback is triggerred. As a result, we always facing spinlock resursion which would resulting in system panic. Given that RDS ping is only used to test the connectivity and not for serious performance measurements, we can queue the pong transmit to rds_wq as a delayed response. Reported-by: Dan Carpenter CC: Venkat Venkatsubra CC: David S. Miller CC: James Morris Signed-off-by: Jie Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2d2f242f248f19c4618bde9091d20416e2c9a1f6 Author: Florian Zumbiehl Date: Sun Oct 7 15:51:58 2012 +0000 vlan: don't deliver frames for unknown vlans to protocols [ Upstream commit 48cc32d38a52d0b68f91a171a8d00531edc6a46e ] 6a32e4f9dd9219261f8856f817e6655114cfec2f made the vlan code skip marking vlan-tagged frames for not locally configured vlans as PACKET_OTHERHOST if there was an rx_handler, as the rx_handler could cause the frame to be received on a different (virtual) vlan-capable interface where that vlan might be configured. As rx_handlers do not necessarily return RX_HANDLER_ANOTHER, this could cause frames for unknown vlans to be delivered to the protocol stack as if they had been received untagged. For example, if an ipv6 router advertisement that's tagged for a locally not configured vlan is received on an interface with macvlan interfaces attached, macvlan's rx_handler returns RX_HANDLER_PASS after delivering the frame to the macvlan interfaces, which caused it to be passed to the protocol stack, leading to ipv6 addresses for the announced prefix being configured even though those are completely unusable on the underlying interface. The fix moves marking as PACKET_OTHERHOST after the rx_handler so the rx_handler, if there is one, sees the frame unchanged, but afterwards, before the frame is delivered to the protocol stack, it gets marked whether there is an rx_handler or not. Signed-off-by: Florian Zumbiehl Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 14a547a85a7fa2b6473eaa73b83e2055b476a5dc Author: Graham Gower Date: Mon Oct 8 08:34:50 2012 +0000 skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard [ Upstream commit a2af139ff1cd85df586690ff626619ab1ee88b0a ] Marvell 88E8001 on an ASUS P5NSLI motherboard is unable to send/receive packets on a system with >4gb ram unless a 32bit DMA mask is used. This issue has been around for years and a fix was sent 3.5 years ago, but there was some debate as to whether it should instead be fixed as a PCI quirk. http://www.spinics.net/lists/netdev/msg88670.html However, 18 months later a similar workaround was introduced for another chipset exhibiting the same problem. http://www.spinics.net/lists/netdev/msg142287.html Signed-off-by: Graham Gower Signed-off-by: Jan Ceuleers Acked-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 742bd2b3cef97a6eea8168b8e356ca2f16b7f3eb Author: ramesh.nagappa@gmail.com Date: Fri Oct 5 19:10:15 2012 +0000 net: Fix skb_under_panic oops in neigh_resolve_output [ Upstream commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c ] The retry loop in neigh_resolve_output() and neigh_connected_output() call dev_hard_header() with out reseting the skb to network_header. This causes the retry to fail with skb_under_panic. The fix is to reset the network_header within the retry loop. Signed-off-by: Ramesh Nagappa Reviewed-by: Shawn Lu Reviewed-by: Robert Coulson Reviewed-by: Billie Alsup Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6114941a295ff186d29ab7462cce6a41a089c354 Author: Gao feng Date: Thu Oct 4 20:15:49 2012 +0000 infiniband: pass rdma_cm module to netlink_dump_start [ Upstream commit 809d5fc9bf6589276a12bd4fd611e4c7ff9940c3 ] set netlink_dump_control.module to avoid panic. Signed-off-by: Gao feng Cc: Roland Dreier Cc: Sean Hefty Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 70f7f1c70af637a23ca09ba1d2d7c966d1bd5990 Author: Gao feng Date: Thu Oct 4 20:15:48 2012 +0000 netlink: add reference of module in netlink_dump_start [ Upstream commit 6dc878a8ca39e93f70c42f3dd7260bde10c1e0f1 ] I get a panic when I use ss -a and rmmod inet_diag at the same time. It's because netlink_dump uses inet_diag_dump which belongs to module inet_diag. I search the codes and find many modules have the same problem. We need to add a reference to the module which the cb->dump belongs to. Thanks for all help from Stephen,Jan,Eric,Steffen and Pablo. Change From v3: change netlink_dump_start to inline,suggestion from Pablo and Eric. Change From v2: delete netlink_dump_done,and call module_put in netlink_dump and netlink_sock_destruct. Signed-off-by: Gao feng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f0dc514c8a0fd7ee7b1f6a3ccdae3b38e6ee1578 Author: Devin Heitmueller Date: Mon Aug 6 22:47:03 2012 -0300 media: au0828: fix case where STREAMOFF being called on stopped stream causes BUG() commit a595c1ce4c9d572cf53513570b9f1a263d7867f2 upstream. We weren't checking whether the resource was in use before calling res_free(), so applications which called STREAMOFF on a v4l2 device that wasn't already streaming would cause a BUG() to be hit (MythTV). Reported-by: Larry Finger Reported-by: Jay Harbeston Signed-off-by: Devin Heitmueller Signed-off-by: Mauro Carvalho Chehab commit bfbd61ec59fae6f633db1d139015c3dd81e453be Author: Felipe Balbi Date: Thu Oct 4 11:58:00 2012 +0300 usb: dwc3: gadget: fix 'endpoint always busy' bug commit 041d81f493d90c940ec41f0ec98bc7c4f2fba431 upstream. If a USB transfer has already been started, meaning we have already issued StartTransfer command to that particular endpoint, DWC3_EP_BUSY flag has also already been set. When we try to cancel this transfer which is already in controller's cache, we will not receive XferComplete event and we must clear DWC3_EP_BUSY in order to allow subsequent requests to be properly started. The best place to clear that flag is right after issuing DWC3_DEPCMD_ENDTRANSFER. Reported-by: Moiz Sonasath Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 8538f9c30a098c87bb806e80f43b2203a997a4d9 Author: Andrew Morton Date: Tue Oct 23 14:09:39 2012 -0700 amd64_edac:__amd64_set_scrub_rate(): avoid overindexing scrubrates[] commit 168bfeef7bba3f9784f7540b053e4ac72b769ce9 upstream. If none of the elements in scrubrates[] matches, this loop will cause __amd64_set_scrub_rate() to incorrectly use the n+1th element. As the function is designed to use the final scrubrates[] element in the case of no match, we can fix this bug by simply terminating the array search at the n-1th element. Boris: this code is fragile anyway, see here why: http://marc.info/?l=linux-kernel&m=135102834131236&w=2 It will be rewritten more robustly soonish. Reported-by: Denis Kirjanov Cc: Doug Thompson Signed-off-by: Andrew Morton Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 5a58f4890e681eadbb617cace87cfdac948c7edd Author: Hiro Sugawara Date: Thu Oct 18 08:35:10 2012 +0300 iommu/tegra: smmu: Fix deadly typo commit d0078e72314df2e5ede03f2102cddde06767c374 upstream. Fix a deadly typo in macro definition. Signed-off-by: Hiro Sugawara Signed-off-by: Hiroshi Doyu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 248ada294174583d918564de33bc5504311c69bb Author: Pritesh Raithatha Date: Wed Oct 17 17:09:36 2012 +0530 pinctrl: tegra: set low power mode bank width to 2 commit 154f3ebf53edcfbe28728452b4ab37a118581125 upstream. Signed-off-by: Pritesh Raithatha Acked-by: Stephen Warren Tested-by: Stephen Warren Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 409dcaefb5c287d68c36e2598154b979a67a9447 Author: Pritesh Raithatha Date: Wed Oct 17 11:51:37 2012 +0530 pinctrl: tegra: correct bank for pingroup and drv pingroup commit a03690e44468dcd3088f6600ab036d17bd2130ff upstream. Signed-off-by: Pritesh Raithatha Acked-by: Stephen Warren Tested-by: Stephen Warren Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 727fa37e405a71dc1c7208ea7352be55e0310eca Author: Tejun Heo Date: Thu Oct 18 17:52:07 2012 -0700 Revert "cgroup: Drop task_lock(parent) on cgroup_fork()" commit 9bb71308b8133d643648776243e4d5599b1c193d upstream. This reverts commit 7e381b0eb1e1a9805c37335562e8dc02e7d7848c. The commit incorrectly assumed that fork path always performed threadgroup_change_begin/end() and depended on that for synchronization against task exit and cgroup migration paths instead of explicitly grabbing task_lock(). threadgroup_change is not locked when forking a new process (as opposed to a new thread in the same process) and even if it were it wouldn't be effective as different processes use different threadgroup locks. Revert the incorrect optimization. Signed-off-by: Tejun Heo LKML-Reference: <20121008020000.GB2575@localhost> Acked-by: Li Zefan Bitterly-Acked-by: Frederic Weisbecker Signed-off-by: Greg Kroah-Hartman commit 5993bba302a1a6df9c73690a08346411ff7cd56e Author: Tejun Heo Date: Thu Oct 18 17:40:30 2012 -0700 Revert "cgroup: Remove task_lock() from cgroup_post_fork()" commit d87838321124061f6c935069d97f37010fa417e6 upstream. This reverts commit 7e3aa30ac8c904a706518b725c451bb486daaae9. The commit incorrectly assumed that fork path always performed threadgroup_change_begin/end() and depended on that for synchronization against task exit and cgroup migration paths instead of explicitly grabbing task_lock(). threadgroup_change is not locked when forking a new process (as opposed to a new thread in the same process) and even if it were it wouldn't be effective as different processes use different threadgroup locks. Revert the incorrect optimization. Signed-off-by: Tejun Heo LKML-Reference: <20121008020000.GB2575@localhost> Acked-by: Li Zefan Cc: Frederic Weisbecker Signed-off-by: Greg Kroah-Hartman commit 9a55fef20afb3d7362b0c9d19ba1e78dfe482d3d Author: Daisuke Nishimura Date: Thu Oct 4 16:37:16 2012 +0900 cgroup: notify_on_release may not be triggered in some cases commit 1f5320d5972aa50d3e8d2b227b636b370e608359 upstream. notify_on_release must be triggered when the last process in a cgroup is move to another. But if the first(and only) process in a cgroup is moved to another, notify_on_release is not triggered. # mkdir /cgroup/cpu/SRC # mkdir /cgroup/cpu/DST # # echo 1 >/cgroup/cpu/SRC/notify_on_release # echo 1 >/cgroup/cpu/DST/notify_on_release # # sleep 300 & [1] 8629 # # echo 8629 >/cgroup/cpu/SRC/tasks # echo 8629 >/cgroup/cpu/DST/tasks -> notify_on_release for /SRC must be triggered at this point, but it isn't. This is because put_css_set() is called before setting CGRP_RELEASABLE in cgroup_task_migrate(), and is a regression introduce by the commit:74a1166d(cgroups: make procs file writable), which was merged into v3.0. Acked-by: Li Zefan Cc: Ben Blum Signed-off-by: Daisuke Nishimura Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 9b1ca55bf3ff5fa1c3ff87bac9c7183bc421dc82 Author: Bjørn Mork Date: Thu Oct 18 17:14:17 2012 +0200 USB: option: add more ZTE devices commit 4b35f1c52943851b310afb09047bfe991ac8f5ae upstream. Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit f9353fb64e1cfb7a1218fbd610df1980a40b1c9b Author: Bjørn Mork Date: Thu Oct 18 17:19:53 2012 +0200 USB: option: blacklist net interface on ZTE devices commit 1452df6f1b7e396d89c2a1fdbdc0e0e839f97671 upstream. Based on information from the ZTE Windows drivers. Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit 045b361901efac992f4ffd773db7c32319ffe177 Author: Alexis R. Cortes Date: Wed Oct 17 14:09:12 2012 -0500 usb: host: xhci: New system added for Compliance Mode Patch on SN65LVPE502CP commit 470809741a28c3092279f4e1f3f432e534d46068 upstream. This minor change adds a new system to which the "Fix Compliance Mode on SN65LVPE502CP Hardware" patch has to be applied also. System added: Vendor: Hewlett-Packard. System Model: Z1 Signed-off-by: Alexis R. Cortes Acked-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit a5204466fa5da21c4431d391101439d7f5f2b828 Author: Nicolas Boullis Date: Tue Oct 16 00:06:23 2012 +0200 usb: acm: fix the computation of the number of data bits commit 301a29da6e891e7eb95c843af0ecdbe86d01f723 upstream. The current code assumes that CSIZE is 0000060, which appears to be wrong on some arches (such as powerpc). Signed-off-by: Nicolas Boullis Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit e83863d3e7ead8c66c1cabb53d95ebd3c7f1805e Author: Ming Lei Date: Tue Oct 16 21:21:21 2012 +0800 USB: cdc-acm: fix pipe type of write endpoint commit c5211187f7ff8e8dbff4ebf7c011ac4c0ffe319c upstream. If the write endpoint is interrupt type, usb_sndintpipe() should be passed to usb_fill_int_urb() instead of usb_sndbulkpipe(). Signed-off-by: Ming Lei Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit cf32a3a3e7b9a449e3b51bc8114d623d52fa9c5f Author: David Vrabel Date: Fri Oct 19 17:29:07 2012 +0100 xen/x86: don't corrupt %eip when returning from a signal handler commit a349e23d1cf746f8bdc603dcc61fae9ee4a695f6 upstream. In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event /and/ the process has a pending signal then %eip (and %eax) are corrupted when returning to the main process after handling the signal. The application may then crash with SIGSEGV or a SIGILL or it may have subtly incorrect behaviour (depending on what instruction it returned to). The occurs because handle_signal() is incorrectly thinking that there is a system call that needs to restarted so it adjusts %eip and %eax to re-execute the system call instruction (even though user space had not done a system call). If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK (-516) then handle_signal() only corrupted %eax (by setting it to -EINTR). This may cause the application to crash or have incorrect behaviour. handle_signal() assumes that regs->orig_ax >= 0 means a system call so any kernel entry point that is not for a system call must push a negative value for orig_ax. For example, for physical interrupts on bare metal the inverse of the vector is pushed and page_fault() sets regs->orig_ax to -1, overwriting the hardware provided error code. xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax instead of -1. Classic Xen kernels pushed %eax which works as %eax cannot be both non-negative and -RESTARTSYS (etc.), but using -1 is consistent with other non-system call entry points and avoids some of the tests in handle_signal(). There were similar bugs in xen_failsafe_callback() of both 32 and 64-bit guests. If the fault was corrected and the normal return path was used then 0 was incorrectly pushed as the value for orig_ax. Signed-off-by: David Vrabel Acked-by: Jan Beulich Acked-by: Ian Campbell Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit efd5fa0c1a1d1b46846ea6e8d1a783d0d8a6a721 Author: Jacob Shin Date: Thu Oct 20 16:15:26 2011 -0500 x86: Exclude E820_RESERVED regions and memory holes above 4 GB from direct mapping. commit 1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a upstream. On systems with very large memory (1 TB in our case), BIOS may report a reserved region or a hole in the E820 map, even above the 4 GB range. Exclude these from the direct mapping. [ hpa: this should be done not just for > 4 GB but for everything above the legacy region (1 MB), at the very least. That, however, turns out to require significant restructuring. That work is well underway, but is not suitable for rc/stable. ] Signed-off-by: Jacob Shin Link: http://lkml.kernel.org/r/1319145326-13902-1-git-send-email-jacob.shin@amd.com Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 3680030e9747dfa51fe9c1850361c29ae0ad20fe Author: Kees Cook Date: Fri Oct 19 18:45:53 2012 -0700 use clamp_t in UNAME26 fix commit 31fd84b95eb211d5db460a1dda85e004800a7b52 upstream. The min/max call needed to have explicit types on some architectures (e.g. mn10300). Use clamp_t instead to avoid the warning: kernel/sys.c: In function 'override_release': kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a cast [enabled by default] Reported-by: Fengguang Wu Signed-off-by: Kees Cook Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 643fde8ed4ea75f5d113803084806eff14d97454 Author: Kees Cook Date: Fri Oct 19 13:56:51 2012 -0700 kernel/sys.c: fix stack memory content leak via UNAME26 commit 2702b1526c7278c4d65d78de209a465d4de2885e upstream. Calling uname() with the UNAME26 personality set allows a leak of kernel stack contents. This fixes it by defensively calculating the length of copy_to_user() call, making the len argument unsigned, and initializing the stack buffer to zero (now technically unneeded, but hey, overkill). CVE-2012-0957 Reported-by: PaX Team Signed-off-by: Kees Cook Cc: Andi Kleen Cc: PaX Team Cc: Brad Spengler Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6eca486b8d28b1fe1d147cf55dfb8832099bb0a2 Author: Arnd Bergmann Date: Mon Apr 30 13:50:56 2012 +0000 pcmcia: sharpsl: don't discard sharpsl_pcmcia_ops commit fdc858a466b738d35d3492bc7cf77b1dac98bf7c upstream. The sharpsl_pcmcia_ops structure gets passed into sa11xx_drv_pcmcia_probe, where it gets accessed at run-time, unlike all other pcmcia drivers that pass their structures into platform_device_add_data, which makes a copy. This means the gcc warning is valid and the structure must not be marked as __initdata. Without this patch, building collie_defconfig results in: drivers/pcmcia/pxa2xx_sharpsl.c:22:31: fatal error: mach-pxa/hardware.h: No such file or directory compilation terminated. make[3]: *** [drivers/pcmcia/pxa2xx_sharpsl.o] Error 1 make[2]: *** [drivers/pcmcia] Error 2 make[1]: *** [drivers] Error 2 make: *** [sub-make] Error 2 Signed-off-by: Arnd Bergmann Cc: Dominik Brodowski Cc: Russell King Cc: Pavel Machek Cc: linux-pcmcia@lists.infradead.org Cc: Jochen Friedrich Signed-off-by: Greg Kroah-Hartman commit 9b62355a6daff8696ec7f7b1283b6a39650b9f14 Author: Trond Myklebust Date: Mon Oct 22 12:56:58 2012 -0400 SUNRPC: Fix a UDP transport regression commit f39c1bfb5a03e2d255451bff05be0d7255298fa4 and commit 84e28a307e376f271505af65a7b7e212dd6f61f4 upstream. Commit 43cedbf0e8dfb9c5610eb7985d5f21263e313802 (SUNRPC: Ensure that we grab the XPRT_LOCK before calling xprt_alloc_slot) is causing hangs in the case of NFS over UDP mounts. Since neither the UDP or the RDMA transport mechanism use dynamic slot allocation, we can skip grabbing the socket lock for those transports. Add a new rpc_xprt_op to allow switching between the TCP and UDP/RDMA case. Note that the NFSv4.1 back channel assigns the slot directly through rpc_run_bc_task, so we can ignore that case. Reported-by: Dick Streefland Signed-off-by: Bryan Schumaker Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit baecc6ef799c7ab9a5fc0ba29ee560a5c264f306 Author: Sasha Levin Date: Tue Jul 17 00:01:26 2012 +0200 SUNRPC: Prevent kernel stack corruption on long values of flush commit 212ba90696ab4884e2025b0b13726d67aadc2cd4 upstream. The buffer size in read_flush() is too small for the longest possible values for it. This can lead to a kernel stack corruption: [ 43.047329] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff833e64b4 [ 43.047329] [ 43.049030] Pid: 6015, comm: trinity-child18 Tainted: G W 3.5.0-rc7-next-20120716-sasha #221 [ 43.050038] Call Trace: [ 43.050435] [] panic+0xcd/0x1f4 [ 43.050931] [] ? read_flush.isra.7+0xe4/0x100 [ 43.051602] [] __stack_chk_fail+0x16/0x20 [ 43.052206] [] read_flush.isra.7+0xe4/0x100 [ 43.052951] [] ? read_flush_pipefs+0x30/0x30 [ 43.053594] [] read_flush_procfs+0x2c/0x30 [ 43.053596] [] proc_reg_read+0x9c/0xd0 [ 43.053596] [] ? proc_reg_write+0xd0/0xd0 [ 43.053596] [] do_loop_readv_writev+0x4b/0x90 [ 43.053596] [] do_readv_writev+0xf6/0x1d0 [ 43.053596] [] vfs_readv+0x3e/0x60 [ 43.053596] [] sys_readv+0x48/0xb0 [ 43.053596] [] system_call_fastpath+0x1a/0x1f Signed-off-by: Sasha Levin Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 1b91a891bc337ecec08dea5436be0bbb03fec12b Author: Heiko Carstens Date: Thu Oct 18 11:11:01 2012 +0200 s390: fix linker script for 31 bit builds commit c985cb37f1b39c2c8035af741a2a0b79f1fbaca7 upstream. Because of a change in the s390 arch backend of binutils (commit 23ecd77 "Pick the default arch depending on the target size" in binutils repo) 31 bit builds will fail since the linker would now try to create 64 bit binary output. Fix this by setting OUTPUT_ARCH to s390:31-bit instead of s390. Thanks to Andreas Krebbel for figuring out the issue. Fixes this build error: LD init/built-in.o s390x-4.7.2-ld: s390:31-bit architecture of input file `arch/s390/kernel/head.o' is incompatible with s390:64-bit output Cc: Andreas Krebbel Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit d641457de0939adaa140161127f2f72bcfe50b37 Author: Dan Carpenter Date: Wed Oct 10 10:18:35 2012 +0300 oprofile, x86: Fix wrapping bug in op_x86_get_ctrl() commit 44009105081b51417f311f4c3be0061870b6b8ed upstream. The "event" variable is a u16 so the shift will always wrap to zero making the line a no-op. Signed-off-by: Dan Carpenter Signed-off-by: Robert Richter Signed-off-by: Greg Kroah-Hartman commit 08eaf6a4ee82eb566c188f71b33f52e780fab57d Author: Trond Myklebust Date: Sat Oct 13 00:30:28 2012 -0400 NLM: nlm_lookup_file() may return NLMv4-specific error codes commit cd0b16c1c3cda12dbed1f8de8f1a9b0591990724 upstream. If the filehandle is stale, or open access is denied for some reason, nlm_fopen() may return one of the NLMv4-specific error codes nlm4_stale_fh or nlm4_failed. These get passed right through nlm_lookup_file(), and so when nlmsvc_retrieve_args() calls the latter, it needs to filter the result through the cast_status() machinery. Failure to do so, will trigger the BUG_ON() in encode_nlm_stat... Signed-off-by: Trond Myklebust Reported-by: Larry McVoy Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 75383fac9206c9dc57a5f153ffabcd5341ad0c28 Author: Chris Metcalf Date: Fri Oct 19 11:43:11 2012 -0400 arch/tile: avoid generating .eh_frame information in modules commit 627072b06c362bbe7dc256f618aaa63351f0cfe6 upstream. The tile tool chain uses the .eh_frame information for backtracing. The vmlinux build drops any .eh_frame sections at link time, but when present in kernel modules, it causes a module load failure due to the presence of unsupported pc-relative relocations. When compiling to use compiler feedback support, the compiler by default omits .eh_frame information, so we don't see this problem. But when not using feedback, we need to explicitly suppress the .eh_frame. Signed-off-by: Chris Metcalf Signed-off-by: Greg Kroah-Hartman commit d39bd2701f0f414aba1376ae61202b526ec7e128 Author: Michal Hocko Date: Wed Oct 10 11:51:09 2012 +0530 nohz: Fix idle ticks in cpu summary line of /proc/stat commit 7386cdbf2f57ea8cff3c9fde93f206e58b9fe13f upstream. Git commit 09a1d34f8535ecf9 "nohz: Make idle/iowait counter update conditional" introduced a bug in regard to cpu hotplug. The effect is that the number of idle ticks in the cpu summary line in /proc/stat is still counting ticks for offline cpus. Reproduction is easy, just start a workload that keeps all cpus busy, switch off one or more cpus and then watch the idle field in top. On a dual-core with one cpu 100% busy and one offline cpu you will get something like this: %Cpu(s): 48.7 us, 1.3 sy, 0.0 ni, 50.0 id, 0.0 wa, 0.0 hi, 0.0 si, %0.0 st The problem is that an offline cpu still has ts->idle_active == 1. To fix this we should make sure that the cpu is online when calling get_cpu_idle_time_us and get_cpu_iowait_time_us. [Srivatsa: Rebased to current mainline] Reported-by: Martin Schwidefsky Signed-off-by: Michal Hocko Reviewed-by: Srivatsa S. Bhat Signed-off-by: Srivatsa S. Bhat Link: http://lkml.kernel.org/r/20121010061820.8999.57245.stgit@srivatsabhat.in.ibm.com Cc: deepthi@linux.vnet.ibm.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 2807664df50419f56b596aa49da8a22102c0e0a3 Author: Lukas Czerner Date: Mon Oct 22 18:01:19 2012 -0400 ext4: Avoid underflow in ext4_trim_fs() commit 5de35e8d5c02d271c20e18337e01bc20e6ef472e upstream. Currently if len argument in ext4_trim_fs() is smaller than one block, the 'end' variable underflow. Avoid that by returning EINVAL if len is smaller than file system block. Also remove useless unlikely(). Signed-off-by: Lukas Czerner Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 4319fd00002630a761fa5559a086f11ed7623006 Author: Dmitry Monakhov Date: Wed Oct 10 01:04:58 2012 -0400 ext4: race-condition protection for ext4_convert_unwritten_extents_endio commit dee1f973ca341c266229faa5a1a5bb268bed3531 upstream. We assumed that at the time we call ext4_convert_unwritten_extents_endio() extent in question is fully inside [map.m_lblk, map->m_len] because it was already split during submission. But this may not be true due to a race between writeback vs fallocate. If extent in question is larger than requested we will split it again. Special precautions should being done if zeroout required because [map.m_lblk, map->m_len] already contains valid data. Signed-off-by: Dmitry Monakhov Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman