commit 675f7660ffb0e1880011f6b3c4f9ac241491e3cd Author: Andi Kleen Date: Mon Aug 1 13:56:51 2011 -0700 release 2.6.35.14 Signed-off-by: Andi Kleen commit ef0c3e7d6e082b7f3cf41546525c84f4477a76d3 Author: Fernando Luis Vázquez Cao Date: Mon Jun 13 15:06:58 2011 +0000 IGMP snooping: set mrouters_only flag for IPv6 traffic [ upstream commit fc2af6c73fc9449cd5894a36bb76b8f8c0e49fd8 ] properly Upon reception of a MGM report packet the kernel sets the mrouters_only flag in a skb that is a clone of the original skb, which means that the bridge loses track of MGM packets (cb buffers are tied to a specific skb and not shared) and it ends up forwading join requests to the bridge interface. This can cause unexpected membership timeouts and intermitent/permanent loss of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]: A snooping switch should forward IGMP Membership Reports only to those ports where multicast routers are attached. [...] Sending membership reports to other hosts can result, for IGMPv1 and IGMPv2, in unintentionally preventing a host from joining a specific multicast group. Signed-off-by: Fernando Luis Vazquez Cao Signed-off-by: David S. Miller Signed-off-by: Andi Kleen commit 8904f07a1b5683c4363b225cb376f2bd1435246f Author: Fernando Luis Vázquez Cao Date: Mon Jun 13 15:04:43 2011 +0000 IGMP snooping: set mrouters_only flag for IPv4 traffic [ upstream commit 62b2bcb49cca72f6d3f39f831127a6ab315a475d ] properly Upon reception of a IGMP/IGMPv2 membership report the kernel sets the mrouters_only flag in a skb that may be a clone of the original skb, which means that sometimes the bridge loses track of membership report packets (cb buffers are tied to a specific skb and not shared) and it ends up forwading join requests to the bridge interface. This can cause unexpected membership timeouts and intermitent/permanent loss of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]: A snooping switch should forward IGMP Membership Reports only to those ports where multicast routers are attached. [...] Sending membership reports to other hosts can result, for IGMPv1 and IGMPv2, in unintentionally preventing a host from joining a specific multicast group. Signed-off-by: Fernando Luis Vazquez Cao Tested-by: Hayato Kakuta Signed-off-by: David S. Miller Signed-off-by: Andi Kleen commit ea626c8fccc5b119bf1d398d99e7ecad4bfc95e2 Author: Thomas Graf Date: Fri Sep 3 03:04:20 2010 +0000 ipv6: add special mode forwarding=2 to send RS while [ upstream commit c3bccac2fa76f1619dfe4fb7b9bee69de7f066d8 ] configured as router Similar to accepting router advertisement, the IPv6 stack does not send router solicitations if forwarding is enabled. This patch enables this behavior to be overruled by setting forwarding to the special value 2. Signed-off-by: Thomas Graf Signed-off-by: David S. Miller Signed-off-by: Andi Kleen commit 22950d253543188b3e6488a0dbd5cad9eb71bef7 Author: Suresh Siddha Date: Thu Jun 23 11:19:26 2011 -0700 x86, mtrr: lock stop machine during MTRR rendezvous sequence [ upstream commit 6d3321e8e2b3bf6a5892e2ef673c7bf536e3f904 ] MTRR rendezvous sequence using stop_one_cpu_nowait() can potentially happen in parallel with another system wide rendezvous using stop_machine(). This can lead to deadlock (The order in which works are queued can be different on different cpu's. Some cpu's will be running the first rendezvous handler and others will be running the second rendezvous handler. Each set waiting for the other set to join for the system wide rendezvous, leading to a deadlock). MTRR rendezvous sequence is not implemented using stop_machine() as this gets called both from the process context aswell as the cpu online paths (where the cpu has not come online and the interrupts are disabled etc). stop_machine() works with only online cpus. For now, take the stop_machine mutex in the MTRR rendezvous sequence that gets called from an online cpu (here we are in the process context and can potentially sleep while taking the mutex). And the MTRR rendezvous that gets triggered during cpu online doesn't need to take this stop_machine lock (as the stop_machine() already ensures that there is no cpu hotplug going on in parallel by doing get_online_cpus()) TBD: Pursue a cleaner solution of extending the stop_machine() infrastructure to handle the case where the calling cpu is still not online and use this for MTRR rendezvous sequence. fixes: https://bugzilla.novell.com/show_bug.cgi?id=672008 Reported-by: Vadim Kotelnikov Signed-off-by: Suresh Siddha Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/20110623182056.807230326@sbsiddha-MOBL3.sc.intel.com Cc: stable@kernel.org # 2.6.35+, backport a week or two after this gets more testing in mainline Signed-off-by: H. Peter Anvin commit 552fe3d630bed45d7b75c76d12b61e458b587de0 Author: Ralf Baechle Date: Mon Jun 27 14:26:56 2011 +0100 SERIAL: SC26xx: Fix link error. [ upstream commit f2eb3cdf14457fccb14ae8c4d7d7cee088cd3957 ] Kconfig allows enabling console support for the SC26xx driver even when it's configured as a module resulting in a: ERROR: "uart_console_device" [drivers/tty/serial/sc26xx.ko] undefined! modpost error since the driver was merged in eea63e0e8a60d00485b47fb6e75d9aa2566b989b [SC26XX: New serial driver for SC2681 uarts] in 2.6.25. Fixed by only allowing console support to be enabled if the driver is builtin. Signed-off-by: Ralf Baechle Cc: linux-serial@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: stable Acked-by: Alan Cox Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 507e949027b3dc00f56a1c91b88c2d899e9eaea0 Author: Mark Brown Date: Fri Jul 1 17:24:46 2011 -0700 ASoC: Ensure we delay long enough for WM8994 FLL to lock [ upstream commit 8e9ddf811ba021506d2316fcfe619faa0ab3f567 ] when starting This delay is very conservative. Signed-off-by: Mark Brown Acked-by: Liam Girdwood Cc: stable@kernel.org Signed-off-by: Andi Kleen commit 64779cb190a6ba7a03b658cd0584cef74fb9c208 Author: Will Deacon Date: Fri Jul 1 14:38:12 2011 +0100 ARM: 6989/1: perf: do not start the PMU when no events are [ upstream commit f4f38430c94c38187db73a2cf3892cc8b12a2713 ] present armpmu_enable can be called in situations where no events are present (for example, from the event rotation tick after a profiled task has exited). In this case, we currently start the PMU anyway which may leave it active inevitably without any events being monitored. This patch adds a simple check to the enabling code so that we avoid starting the PMU when no events are present. Cc: Reported-by: Ashwin Chaugle Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Andi Kleen commit 225686544fb9af569ea70a46e11fe130c6da5bd2 Author: K. Y. Srinivasan Date: Thu Jun 16 13:16:37 2011 -0700 Staging: hv: netvsc: Fix a bug in accounting transmit slots [ upstream commit 9079ce691255792009c446d8c3382507b8d38635 ] The transmit slots were manipulated without proper locking. Fix this bug by making the variable tracking the transmit slots atomic. This patch should be ported to prior stable kernels 2.6.32 and later. Signed-off-by: K. Y. Srinivasan Signed-off-by: Haiyang Zhang Signed-off-by: Hank Janssen Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 8df2d5870c76436e31a68ee141636f6555f9c789 Author: Vasiliy Kulikov Date: Sun Jun 26 12:56:22 2011 +0400 staging: comedi: fix infoleak to userspace [ upstream commit 819cbb120eaec7e014e5abd029260db1ca8c5735 ] driver_name and board_name are pointers to strings, not buffers of size COMEDI_NAMELEN. Copying COMEDI_NAMELEN bytes of a string containing less than COMEDI_NAMELEN-1 bytes would leak some unrelated bytes. Signed-off-by: Vasiliy Kulikov Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 1566cd03b690efb4d9997294cda9d0ac53ab3816 Author: Larry Finger Date: Sat Jun 18 22:34:34 2011 -0500 staging: r8192e_pci: Handle duplicate PCI ID 0x10ec:0x8192 [ upstream commit 1c50bf7e415cf6ce9545dbecc2ac0d89d3916c53 ] conflict with rtl8192se There are two devices with PCI ID 0x10ec:0x8192, namely RTL8192E and RTL8192SE. The method of distinguishing them is by the revision ID at offset 0x8 of the PCI configuration space. If the value is 0x10, then the device uses rtl8192se for a driver. Signed-off-by: Larry Finger Cc: Stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 08b751d515c0f2745b3e3c6bc7ca5a3f2747fe28 Author: Joerg Roedel Date: Wed Jul 6 17:14:44 2011 +0200 iommu/amd: Don't use MSI address range for DMA addresses [ upstream commit 17f5b569e09cfa3488eaa663cbf9feada2e789f5 ] Reserve the MSI address range in the address allocator so that MSI addresses are not handed out as dma handles. Cc: stable@kernel.org Signed-off-by: Joerg Roedel Signed-off-by: Andi Kleen commit dd4e598f13dd3e9c871034dd22ace5977fa4c37a Author: Paul Parsons Date: Sun May 8 01:54:33 2011 +0000 ARM: pxa: fix PGSR register address calculation [ upstream commit beb0c9b056b1c23d2029b46a425362e9ccbeba01 ] The file mfp-pxa2xx.c defines a macro, PGSR(), which translates a gpio bank number to a PGSR register address. The function pxa2xx_mfp_suspend() erroneously passed in a gpio number instead of a gpio bank number. Signed-off-by: Paul Parsons Cc: stable@kernel.org Signed-off-by: Eric Miao Signed-off-by: Andi Kleen commit 788ae7963e9b103697d23a773dc1449533bf2e79 Author: Steven Rostedt Date: Tue Jul 5 14:32:51 2011 -0400 tracing: Have "enable" file use refcounts like the "filter" [ upstream commit 40ee4dffff061399eb9358e0c8fcfbaf8de4c8fe ] file The "enable" file for the event system can be removed when a module is unloaded and the event system only has events from that module. As the event system nr_events count goes to zero, it may be freed if its ref_count is also set to zero. Like the "filter" file, the "enable" file may be opened by a task and referenced later, after a module has been unloaded and the events for that event system have been removed. Although the "filter" file referenced the event system structure, the "enable" file only references a pointer to the event system name. Since the name is freed when the event system is removed, it is possible that an access to the "enable" file may reference a freed pointer. Update the "enable" file to use the subsystem_open() routine that the "filter" file uses, to keep a reference to the event system structure while the "enable" file is opened. Cc: Reported-by: Johannes Berg Signed-off-by: Steven Rostedt Signed-off-by: Andi Kleen commit eabdd90b949f20ce315896b5bdd985a571d1bd77 Author: Steven Rostedt Date: Tue Jul 5 11:36:06 2011 -0400 tracing: Fix bug when reading system filters on module [ upstream commit e9dbfae53eeb9fc3d4bb7da3df87fa9875f5da02 ] removal The event system is freed when its nr_events is set to zero. This happens when a module created an event system and then later the module is removed. Modules may share systems, so the system is allocated when it is created and freed when the modules are unloaded and all the events under the system are removed (nr_events set to zero). The problem arises when a task opened the "filter" file for the system. If the module is unloaded and it removed the last event for that system, the system structure is freed. If the task that opened the filter file accesses the "filter" file after the system has been freed, the system will access an invalid pointer. By adding a ref_count, and using it to keep track of what is using the event system, we can free it after all users are finished with the event system. Cc: Reported-by: Johannes Berg Signed-off-by: Steven Rostedt Signed-off-by: Andi Kleen commit c7f88b2668a1fe87d6b0497081c03653c44ee80f Author: Kuninori Morimoto Date: Wed Jul 6 17:58:56 2011 -0700 ASoC: ak4642: fixup snd_soc_update_bits mask for PW_MGMT2 [ upstream commit bd7fdbcaa2d06d446577fd3c9b81847b04469e01 ] mask didn't cover update-data Signed-off-by: Kuninori Morimoto Acked-by: Liam Girdwood Signed-off-by: Mark Brown Cc: stable@kernel.org Signed-off-by: Andi Kleen commit 0b2e05879a5f73f75fb41d39b73ee35220d9a362 Author: Johannes Berg Date: Thu Jul 7 18:24:54 2011 +0200 mac80211: fix TKIP replay vulnerability [ upstream commit 34459512ffa7236c849466e3bd604801389734e1 ] Unlike CCMP, the presence or absence of the QoS field doesn't change the encryption, only the TID is used. When no QoS field is present, zero is used as the TID value. This means that it is possible for an attacker to take a QoS packet with TID 0 and replay it as a non-QoS packet. Unfortunately, mac80211 uses different IVs for checking the validity of the packet's TKIP IV when it checks TID 0 and when it checks non-QoS packets. This means it is vulnerable to this replay attack. To fix this, use the same replay counter for TID 0 and non-QoS packets by overriding the rx->queue value to 0 if it is 16 (non-QoS). This is a minimal fix for now. I caused this issue in commit 1411f9b531f0a910cd1c85a337737c1e6ffbae6a Author: Johannes Berg Date: Thu Jul 10 10:11:02 2008 +0200 mac80211: fix RX sequence number check while fixing a sequence number issue (there, a separate counter needs to be used). [AK: This was a non trivial backport. Johannes, John, please double check] Cc: stable@kernel.org Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Andi Kleen commit 362a03ca4747dbbb67758e54df3d2fff6936e984 Author: Hans Verkuil Date: Sun Jun 12 06:36:41 2011 -0300 v4l2-ioctl.c: prefill tuner type for g_frequency and [ upstream commit 227690df75382e46a4f6ea1bbc5df855a674b47f ] g/s_tuner The subdevs are supposed to receive a valid tuner type for the g_frequency and g/s_tuner subdev ops. Some drivers do this, others don't. So prefill this in v4l2-ioctl.c based on whether the device node from which this is called is a radio node or not. The spec does not require applications to fill in the type, and if they leave it at 0 then the 'check_mode' call in tuner-core.c will return an error and the ioctl does nothing. Cc: stable@kernel.org Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Andi Kleen commit f452581990ad01497dfefb023102d7dc49cbe75a Author: Hans Verkuil Date: Sun Jun 12 06:39:52 2011 -0300 pvrusb2: fix g/s_tuner support [ upstream commit 50e9efd60b213ce43ad6979bfc18e25eec2d8413 ] The tuner-core subdev requires that the type field of v4l2_tuner is filled in correctly. This is done in v4l2-ioctl.c, but pvrusb2 doesn't use that yet, so we have to do it manually based on whether the current input is radio or not. Tested with my pvrusb2. Signed-off-by: Hans Verkuil Acked-by: Mike Isely Cc: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Andi Kleen commit 3db400fabd1f22b4bb4187142d0eb33efceff85a Author: Hans Verkuil Date: Sun Jun 12 07:02:43 2011 -0300 bttv: fix s_tuner for radio [ upstream commit a024c1a6b274e11596d124619e43c25560f64c01 ] Fix typo: g_tuner should have been s_tuner. Tested with a bttv card. Cc: stable@kernel.org Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Andi Kleen commit 056f681640dc0ca20276dc15f7cbbc31b8641a1d Author: Trond Myklebust Date: Wed Jul 6 19:58:23 2011 -0400 SUNRPC: Fix a race between work-queue and rpc_killall_tasks [ upstream commit b55c59892e1f3b6c7d4b9ccffb4263e1486fb990 ] Since rpc_killall_tasks may modify the rpc_task's tk_action field without any locking, we need to be careful when dereferencing it. Reported-by: Ben Greear Tested-by: Ben Greear Signed-off-by: Trond Myklebust Cc: stable@kernel.org Signed-off-by: Andi Kleen commit 0e7d89101d9f1ab17f4123659bb796d7e4f7bcb8 Author: Ajay Kumar Gupta Date: Fri Jul 8 15:06:13 2011 +0530 usb: musb: restore INDEX register in resume path [ upstream commit 3c5fec75e121b21a2eb35e5a6b44291509abba6f ] Restoring the missing INDEX register value in musb_restore_context(). Without this suspend resume functionality is broken with offmode enabled. Cc: stable@kernel.org Acked-by: Anand Gadiyar Signed-off-by: Ajay Kumar Gupta Signed-off-by: Felipe Balbi Signed-off-by: Andi Kleen commit 693560d364dc64efed3da660b62948368132754a Author: Rajkumar Manoharan Date: Thu Jul 7 23:33:39 2011 +0530 mac80211: Restart STA timers only on associated state [ upstream commit 676b58c27475a9defccc025fea1cbd2b141ee539 ] A panic was observed when the device is failed to resume properly, and there are no running interfaces. ieee80211_reconfig tries to restart STA timers on unassociated state. Cc: stable@kernel.org Signed-off-by: Rajkumar Manoharan Signed-off-by: John W. Linville Signed-off-by: Andi Kleen commit 81da73dccac71cbbd5949f87a7cacf2925f01e44 Author: Sergei Shtylyov Date: Wed Jul 6 23:19:38 2011 +0400 EHCI: only power off port if over-current is active [ upstream commit 81463c1d707186adbbe534016cd1249edeab0dac ] MAX4967 USB power supply chip we use on our boards signals over-current when power is not enabled; once it's enabled, over-current signal returns to normal. That unfortunately caused the endless stream of "over-current change on port" messages. The EHCI root hub code reacts on every over-current signal change with powering off the port -- such change event is generated the moment the port power is enabled, so once enabled the power is immediately cut off. I think we should only cut off power when we're seeing the active over-current signal, so I'm adding such check to that code. I also think that the fact that we've cut off the port power should be reflected in the result of GetPortStatus request immediately, hence I'm adding a PORTSCn register readback after write... Signed-off-by: Sergei Shtylyov Cc: stable@kernel.org Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 8f8d6bc6ec9510a3bd8d97e011c7dc6008a7355d Author: Bob Liu Date: Fri Jul 8 15:39:46 2011 -0700 mm/nommu.c: fix remap_pfn_range() [ upstream commit 8f3b1327aa454bc8283e96bca7669c3c88b83f79 ] remap_pfn_range() means map physical address pfn<vm_start = pfn << PAGE_SHIFT which is wrong acroding the original meaning of this function. And some driver developer using remap_pfn_range() with correct parameter will get unexpected result because vm_start is changed. It should be implementd like addr = pfn << PAGE_SHIFT but which is meanless on nommu arch, this patch just make it simply return. Parameter name and setting of vma->vm_flags also be fixed. Signed-off-by: Bob Liu Cc: Geert Uytterhoeven Cc: David Howells Acked-by: Greg Ungerer Cc: Mike Frysinger Cc: Bob Liu Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Andi Kleen commit 723df54958132696b5d203b6d8b9c914744983c2 Author: Stefan Richter Date: Sun Jul 10 00:23:03 2011 +0200 firewire: ohci: do not bind to Pinnacle cards, avert panic [ upstream commit 7f7e37115a8b6724f26d0637a04e1d35e3c59717 ] When firewire-ohci is bound to a Pinnacle MovieBoard, eventually a "Register access failure" is logged and an interrupt storm or a kernel panic happens. https://bugzilla.kernel.org/show_bug.cgi?id=36622 Until this is sorted out (if that is going to succeed at all), let's just prevent firewire-ohci from touching these devices. Signed-off-by: Stefan Richter Cc: Signed-off-by: Andi Kleen commit 16b9eeed2a368c85e42c680d7a25fee50c3ad828 Author: Igor Grinberg Date: Mon May 9 14:41:46 2011 +0300 ARM: pxa/cm-x300: fix V3020 RTC functionality [ upstream commit 6c7b3ea52e345ab614edb91d3f0e9f3bb3713871 ] While in sleep mode the CS# and other V3020 RTC GPIOs must be driven high, otherwise V3020 RTC fails to keep the right time in sleep mode. Signed-off-by: Igor Grinberg Cc: stable@kernel.org Signed-off-by: Eric Miao Signed-off-by: Andi Kleen commit 37f7a29f540ffaee81648ab757da701a7a8b3dcc Author: Ben Greear Date: Tue Jul 12 10:27:55 2011 -0700 SUNRPC: Fix use of static variable in rpcb_getport_async [ upstream commit ec0dd267bf7d08cb30e321e45a75fd40edd7e528 ] Because struct rpcbind_args *map was declared static, if two threads entered this method at the same time, the values assigned to map could be sent two two differen tasks. This could cause all sorts of problems, include use-after-free and double-free of memory. Fix this by removing the static declaration so that the map pointer is on the stack. Signed-off-by: Ben Greear Cc: stable@kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Andi Kleen commit fb20c39467bbc0610039152704b8500f3539d666 Author: Len Brown Date: Thu Jul 14 00:53:24 2011 -0400 x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIAS [ upstream commit abe48b108247e9b90b4c6739662a2e5c765ed114 ] Since 2.6.36 (23016bf0d25), Linux prints the existence of "epb" in /proc/cpuinfo, Since 2.6.38 (d5532ee7b40), the x86_energy_perf_policy(8) utility has been available in-tree to update MSR_IA32_ENERGY_PERF_BIAS. However, the typical BIOS fails to initialize the MSR, presumably because this is handled by high-volume shrink-wrap operating systems... Linux distros, on the other hand, do not yet invoke x86_energy_perf_policy(8). As a result, WSM-EP, SNB, and later hardware from Intel will run in its default hardware power-on state (performance), which assumes that users care for performance at all costs and not for energy efficiency. While that is fine for performance benchmarks, the hardware's intended default operating point is "normal" mode... Initialize the MSR to the "normal" by default during kernel boot. x86_energy_perf_policy(8) is available to change the default after boot, should the user have a different preference. Signed-off-by: Len Brown Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107140051020.18606@x980 Acked-by: Rafael J. Wysocki Signed-off-by: H. Peter Anvin Cc: commit ec43b20a4e00cccdf8705b60e3ddef95349fff6b Author: Venkatesh Pallipadi Date: Thu Jun 3 23:22:28 2010 -0400 x86: Look for IA32_ENERGY_PERF_BIAS support [ upstream commit 23016bf0 ] The new IA32_ENERGY_PERF_BIAS MSR allows system software to give hardware a hint whether OS policy favors more power saving, or more performance. This allows the OS to have some influence on internal hardware power/performance tradeoffs where the OS has previously had no influence. The support for this feature is indicated by CPUID.06H.ECX.bit3, as documented in the Intel Architectures Software Developer's Manual. This patch discovers support of this feature and displays it as "epb" in /proc/cpuinfo. Signed-off-by: Venkatesh Pallipadi Signed-off-by: Andi Kleen LKML-Reference: Signed-off-by: Len Brown Signed-off-by: H. Peter Anvin commit ccbe5280c9adf5955c0baeff57e8a549a27ebf46 Author: J. Bruce Fields Date: Wed Jun 29 16:49:04 2011 -0400 svcrpc: fix list-corrupting race on nfsd shutdown [ upstream commit ebc63e531cc6a457595dd110b07ac530eae788c3 ] After commit 3262c816a3d7fb1eaabce633caa317887ed549ae "[PATCH] knfsd: split svc_serv into pools", svc_delete_xprt (then svc_delete_socket) no longer removed its xpt_ready (then sk_ready) field from whatever list it was on, noting that there was no point since the whole list was about to be destroyed anyway. That was mostly true, but forgot that a few svc_xprt_enqueue()'s might still be hanging around playing with the about-to-be-destroyed list, and could get themselves into trouble writing to freed memory if we left this xprt on the list after freeing it. (This is actually functionally identical to a patch made first by Ben Greear, but with more comments.) Cc: stable@kernel.org Cc: gnb@fmeh.org Reported-by: Ben Greear Tested-by: Ben Greear Signed-off-by: J. Bruce Fields Signed-off-by: Andi Kleen commit 5392dda6e2b429cdf8d72dcbe36481372e1caa14 Author: Stefan Richter Date: Sat Jul 9 16:42:26 2011 +0200 firewire: cdev: return -ENOTTY for unimplemented ioctls, not [ upstream commit d873d794235efa590ab3c94d5ee22bb1fab19ac4 ] -EINVAL On Jun 27 Linus Torvalds wrote: > The correct error code for "I don't understand this ioctl" is ENOTTY. > The naming may be odd, but you should think of that error value as a > "unrecognized ioctl number, you're feeding me random numbers that I > don't understand and I assume for historical reasons that you tried to > do some tty operation on me". [...] > The EINVAL thing goes way back, and is a disaster. It predates Linux > itself, as far as I can tell. You'll find lots of man-pages that have > this line in it: > > EINVAL Request or argp is not valid. > > and it shows up in POSIX etc. And sadly, it generally shows up > _before_ the line that says > > ENOTTY The specified request does not apply to the kind of object > that the descriptor d references. > > so a lot of people get to the EINVAL, and never even notice the ENOTTY. [...] > At least glibc (and hopefully other C libraries) use a _string_ that > makes much more sense: strerror(ENOTTY) is "Inappropriate ioctl for > device" So let's correct this in the ABI while it is still young, relative to distributor adoption. Side note: We return -ENOTTY not only on _IOC_TYPE or _IOC_NR mismatch, but also on _IOC_SIZE mismatch. An ioctl with an unsupported size of argument structure can be seen as an unsupported version of that ioctl. Signed-off-by: Stefan Richter Cc: Signed-off-by: Andi Kleen commit c20974dfa539046b0cec0af14a2d707c39f33b2a Author: Stefan Richter Date: Sat Jul 9 16:43:22 2011 +0200 firewire: cdev: prevent race between first get_info ioctl [ upstream commit 93b37905f70083d6143f5f4dba0a45cc64379a62 ] and bus reset event queuing Between open(2) of a /dev/fw* and the first FW_CDEV_IOC_GET_INFO ioctl(2) on it, the kernel already queues FW_CDEV_EVENT_BUS_RESET events to be read(2) by the client. The get_info ioctl is practically always issued right away after open, hence this condition only occurs if the client opens during a bus reset, especially during a rapid series of bus resets. The problem with this condition is twofold: - These bus reset events carry the (as yet undocumented) @closure value of 0. But it is not the kernel's place to choose closures; they are privat to the client. E.g., this 0 value forced from the kernel makes it unsafe for clients to dereference it as a pointer to a closure object without NULL pointer check. - It is impossible for clients to determine the relative order of bus reset events from get_info ioctl(2) versus those from read(2), except in one way: By comparison of closure values. Again, such a procedure imposes complexity on clients and reduces freedom in use of the bus reset closure. So, change the ABI to suppress queuing of bus reset events before the first FW_CDEV_IOC_GET_INFO ioctl was issued by the client. Note, this ABI change cannot be version-controlled. The kernel cannot distinguish old from new clients before the first FW_CDEV_IOC_GET_INFO ioctl. We will try to back-merge this change into currently maintained stable/ longterm series, and we only document the new behaviour. The old behavior is now considered a kernel bug, which it basically is. Signed-off-by: Stefan Richter Cc: Signed-off-by: Andi Kleen commit 5464598561256330d2a14d9616921deb97b69103 Author: Alan Stern Date: Fri Jul 15 17:22:15 2011 -0400 USB: OHCI: fix another regression for NVIDIA controllers [ upstream commit 6ea12a04d295235ed67010a09fdea58c949e3eb0 ] The NVIDIA series of OHCI controllers continues to be troublesome. A few people using the MCP67 chipset have reported that even with the most recent kernels, the OHCI controller fails to handle new connections and spams the system log with "unable to enumerate USB port" messages. This is different from the other problems previously reported for NVIDIA OHCI controllers, although it is probably related. It turns out that the MCP67 controller does not like to be kept in the RESET state very long. After only a few seconds, it decides not to work any more. This patch (as1479) changes the PCI initialization quirk code so that NVIDIA controllers are switched into the SUSPEND state after 50 ms of RESET. With no interrupts enabled and all the downstream devices reset, and thus unable to send wakeup requests, this should be perfectly safe (even for non-NVIDIA hardware). The removal code in ohci-hcd hasn't been changed; it will still leave the controller in the RESET state. As a result, if someone unloads ohci-hcd and then reloads it, the controller won't work again until the system is rebooted. If anybody complains about this, the removal code can be updated similarly. This fixes Bugzilla #22052. Tested-by: Larry Finger Cc: stable Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 9c1f7a93bff756565bcb4e1b992541cb776f24d2 Author: Luca Tettamanti Date: Sun Jul 17 18:39:18 2011 +0200 hwmon: (asus_atk0110) Fix memory leak [ upstream commit 0b8e77f12cb6bfe2e5a67f2cdc8c7af23abc4ccf ] The object returned by atk_gitm is dynamically allocated and must be freed. Signed-off-by: Luca Tettamanti Signed-off-by: Jean Delvare Cc: stable@kernel.org Signed-off-by: Andi Kleen commit 57090d5ee1e6ecfd74ecdc376d1246ff53aabd03 Author: Pavel Herrmann Date: Sun Jul 17 18:39:19 2011 +0200 hwmon: (max1111) Fix race condition causing NULL pointer [ upstream commit d3f684f2820a7f42acef68bea6622d9032127fb2 ] exception spi_sync call uses its spi_message parameter to keep completion information, using a drvdata structure is not thread-safe. Use a mutex to prevent multiple access to shared driver data. Signed-off-by: Pavel Herrmann Acked-by: Russell King Acked-by: Pavel Machek Acked-by: Marek Vasut Acked-by: Cyril Hrubis Tested-by: Stanislav Brabec Signed-off-by: Jean Delvare Cc: stable@kernel.org Signed-off-by: Andi Kleen commit f537ef79e7eca73f3d8161411d8da63fe346f7cc Author: Mauro Carvalho Chehab Date: Sun Jul 17 00:24:37 2011 -0300 si4713-i2c: avoid potential buffer overflow on si4713 [ upstream commit dc6b845044ccb7e9e6f3b7e71bd179b3cf0223b6 ] MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit While compiling it with Fedora 15, I noticed this issue: inlined from ‘si4713_write_econtrol_string’ at drivers/media/radio/si4713-i2c.c:1065:24: arch/x86/include/asm/uaccess_32.h:211:26: error: call to ‘copy_from_user_overflow’ declared with attribute error: copy_from_user() buffer size is not provably correct Cc: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab Acked-by: Sakari Ailus Acked-by: Eduardo Valentin Reviewed-by: Eugene Teo Signed-off-by: Linus Torvalds Signed-off-by: Andi Kleen commit 5d9a9233b7fe68dc51ee41a4d35798cfee682444 Author: Michael Neuling Date: Mon Jul 4 20:40:10 2011 +0000 powerpc/kdump: Fix timeout in crash_kexec_wait_realmode [ upstream commit 63f21a56f1cc0b800a4c00349c59448f82473d19 ] The existing code it pretty ugly. How about we clean it up even more like this? From: Anton Blanchard We check for timeout expiry in the outer loop, but we also need to check it in the inner loop or we can lock up forever waiting for a CPU to hit real mode. Signed-off-by: Anton Blanchard Signed-off-by: Michael Neuling Cc: Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Andi Kleen commit bf807eef020a66ee0597cd7996cf6d8bfb06945d Author: Hendrik Brueckner Date: Tue Jul 5 21:50:18 2011 +0000 hvc_console: Improve tty/console put_chars handling [ upstream commit 8c2381af0d3ef62a681dac5a141b6dabb27bf2e1 ] Currently, the hvc_console_print() function drops console output if the hvc backend's put_chars() returns 0. This patch changes this behavior to allow a retry through returning -EAGAIN. This change also affects the hvc_push() function. Both functions are changed to handle -EAGAIN and to retry the put_chars() operation. If a hvc backend returns -EAGAIN, the retry handling differs: - hvc_console_print() spins to write the complete console output. - hvc_push() behaves the same way as for returning 0. Now hvc backends can indirectly control the way how console output is handled through the hvc console layer. Signed-off-by: Hendrik Brueckner Acked-by: Anton Blanchard Cc: Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Andi Kleen commit bf7b6215667dd484edf6aa03b764927afc6a6c76 Author: Anton Blanchard Date: Tue Jul 5 21:51:36 2011 +0000 powerpc/pseries/hvconsole: Fix dropped console output [ upstream commit 51d33021425e1f905beb4208823146f2fb6517da ] Return -EAGAIN when we get H_BUSY back from the hypervisor. This makes the hvc console driver retry, avoiding dropped printks. Signed-off-by: Anton Blanchard Cc: Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Andi Kleen commit 5671ba64a10a8150de56a8131cf0084381ca79ba Author: Jon Povey Date: Tue Jul 19 12:30:11 2011 +0900 davinci: DM365 EVM: fix video input mux bits [ upstream commit 9daedd833a38edd90cf7baa1b1fcf61c3a0721e3 ] Video input mux settings for tvp7002 and imager inputs were swapped. Comment was correct. Tested on EVM with tvp7002 input. Signed-off-by: Jon Povey Acked-by: Manjunath Hadli Cc: stable@kernel.org Signed-off-by: Sekhar Nori Signed-off-by: Andi Kleen commit 07979fe35895ea6e415cbb3c5551835b2df6bf51 Author: Wolfgang Denk Date: Tue Jul 19 11:25:38 2011 +0200 USB: serial: add IDs for WinChipHead USB->RS232 adapter [ upstream commit 026dfaf18973404a01f488d6aa556a8c466e06a4 ] Add ID 4348:5523 for WinChipHead USB->RS 232 adapter with Prolifec PL2303 chipset Signed-off-by: Wolfgang Denk Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 16c6bf2102869f5d3afeaf26b0c14aeb1db7bcb7 Author: Huang Ying Date: Thu Jul 14 09:34:37 2011 +0800 kexec, x86: Fix incorrect jump back address if not [ upstream commit 050438ed5a05b25cdf287f5691e56a58c2606997 ] preserving context In kexec jump support, jump back address passed to the kexeced kernel via function calling ABI, that is, the function call return address is the jump back entry. Furthermore, jump back entry == 0 should be used to signal that the jump back or preserve context is not enabled in the original kernel. But in the current implementation the stack position used for function call return address is not cleared context preservation is disabled. The patch fixes this bug. Reported-and-tested-by: Yin Kangkai Signed-off-by: Huang Ying Cc: Eric W. Biederman Cc: Vivek Goyal Cc: Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1310607277-25029-1-git-send-email-ying.huang@intel.com Signed-off-by: Ingo Molnar commit 68a7b5709fe88c2ed64ff7e0d088ff4b85703169 Author: Andi Kleen Date: Mon Aug 1 13:55:00 2011 -0700 Drop -Werror in perf Drop -Werror in perf Makefile. This fixes the build with gcc 4.5.x Not in mainline. Signed-off-by: Andi Kleen commit 6d872508383434ffb576d1d44e19c96c59cd064f Author: Manoj Iyer Date: Mon Jul 11 16:28:35 2011 -0500 mmc: Added quirks for Ricoh 1180:e823 lower base clock [ upstream commit 15bed0f2fa8e1d7db201692532c210a7823d2d21 ] frequency Ricoh 1180:e823 does not recognize certain types of SD/MMC cards, as reported at http://launchpad.net/bugs/773524. Lowering the SD base clock frequency from 200Mhz to 50Mhz fixes this issue. This solution was suggest by Koji Matsumuro, Ricoh Company, Ltd. This change has no negative performance effect on standard SD cards, though it's quite possible that there will be one on UHS-1 cards. Signed-off-by: Manoj Iyer Tested-by: Daniel Manrique Cc: Koji Matsumuro Cc: Acked-by: Jesse Barnes Signed-off-by: Chris Ball Signed-off-by: Andi Kleen commit afd392409785398ec6b3b2e3ac7c8510aff02ae3 Author: Manoj Iyer Date: Thu May 26 11:19:05 2011 -0500 mmc: Add PCI fixup quirks for Ricoh 1180:e823 reader [ upstream commit be98ca652faa6468916a9b7608befff215a8ca70 ] Signed-off-by: Manoj Iyer Cc: Signed-off-by: Chris Ball Signed-off-by: Andi Kleen commit 300896911157016b30ea6f2de8705b675441e76a Author: James Bottomley Date: Thu Jul 7 15:45:40 2011 -0500 fix crash in scsi_dispatch_cmd() [ upstream commit bfe159a51203c15d23cb3158fffdc25ec4b4dda1 ] USB surprise removal of sr is triggering an oops in scsi_dispatch_command(). What seems to be happening is that USB is hanging on to a queue reference until the last close of the upper device, so the crash is caused by surprise remove of a mounted CD followed by attempted unmount. The problem is that USB doesn't issue its final commands as part of the SCSI teardown path, but on last close when the block queue is long gone. The long term fix is probably to make sr do the teardown in the same way as sd (so remove all the lower bits on ejection, but keep the upper disk alive until last close of user space). However, the current oops can be simply fixed by not allowing any commands to be sent to a dead queue. Cc: stable@kernel.org Signed-off-by: James Bottomley Signed-off-by: Andi Kleen commit 1cbddbe0d078aa1dd9445ee421caaceec90ef914 Author: Guo-Fu Tseng Date: Wed Jul 20 16:57:36 2011 +0000 jme: Fix unmap error (Causing system freeze) [ upstream commit 94c5b41b327e08de0ddf563237855f55080652a1 ] This patch add the missing dma_unmap(). Which solved the critical issue of system freeze on heavy load. Michal Miroslaw's rejected patch: [PATCH v2 10/46] net: jme: convert to generic DMA API Pointed out the issue also, thank you Michal. But the fix was incorrect. It would unmap needed address when low memory. Got lots of feedback from End user and Gentoo Bugzilla. https://bugs.gentoo.org/show_bug.cgi?id=373109 Thank you all. :) Cc: stable@kernel.org Signed-off-by: Guo-Fu Tseng Acked-by: Chris Wright Signed-off-by: David S. Miller Signed-off-by: Andi Kleen commit ef652fd1d50af7236399055d621051aafffd1789 Author: Manfred Spraul Date: Mon Jul 25 17:11:47 2011 -0700 ipc/sem.c: fix race with concurrent semtimedop() timeouts [ upstream commit d694ad62bf539dbb20a0899ac2a954555f9e4a83 ] and IPC_RMID If a semaphore array is removed and in parallel a sleeping task is woken up (signal or timeout, does not matter), then the woken up task does not wait until wake_up_sem_queue_do() is completed. This will cause crashes, because wake_up_sem_queue_do() will read from a stale pointer. The fix is simple: Regardless of anything, always call get_queue_result(). This function waits until wake_up_sem_queue_do() has finished it's task. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=27142 Reported-by: Yuriy Yevtukhov Reported-by: Harald Laabs Signed-off-by: Manfred Spraul Acked-by: Eric Dumazet Cc: [2.6.35+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Andi Kleen commit ef8b14b4fd36fbf79a7823b5741fa901755ee62d Author: Dan Rosenberg Date: Mon Jul 25 17:11:53 2011 -0700 xtensa: prevent arbitrary read in ptrace [ upstream commit 0d0138ebe24b94065580bd2601f8bb7eb6152f56 ] Prevent an arbitrary kernel read. Check the user pointer with access_ok() before copying data in. [akpm@linux-foundation.org: s/EIO/EFAULT/] Signed-off-by: Dan Rosenberg Cc: Christian Zankel Cc: Oleg Nesterov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Andi Kleen commit 6b1ffd2fa340aca8687ec0d1795c0be19f72a29c Author: Peter Zijlstra Date: Mon Jul 25 17:11:57 2011 -0700 mm/backing-dev.c: reset bdi min_ratio in bdi_unregister() [ upstream commit ccb6108f5b0b541d3eb332c3a73e645c0f84278e ] Vito said: : The system has many usb disks coming and going day to day, with their : respective bdi's having min_ratio set to 1 when inserted. It works for : some time until eventually min_ratio can no longer be set, even when the : active set of bdi's seen in /sys/class/bdi/*/min_ratio doesn't add up to : anywhere near 100. : : This then leads to an unrelated starvation problem caused by write-heavy : fuse mounts being used atop the usb disks, a problem the min_ratio setting : at the underlying devices bdi effectively prevents. Fix this leakage by resetting the bdi min_ratio when unregistering the BDI. Signed-off-by: Peter Zijlstra Reported-by: Vito Caputo Cc: Wu Fengguang Cc: Miklos Szeredi Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Andi Kleen commit 444442d989e4b1fe12527ffa0d94d582177194da Author: Benjamin Herrenschmidt Date: Mon Jul 25 17:12:32 2011 -0700 mm/futex: fix futex writes on archs with SW tracking of [ upstream commit 2efaca927f5cd7ecd0f1554b8f9b6a9a2c329c03 ] dirty & young I haven't reproduced it myself but the fail scenario is that on such machines (notably ARM and some embedded powerpc), if you manage to hit that futex path on a writable page whose dirty bit has gone from the PTE, you'll livelock inside the kernel from what I can tell. It will go in a loop of trying the atomic access, failing, trying gup to "fix it up", getting succcess from gup, go back to the atomic access, failing again because dirty wasn't fixed etc... So I think you essentially hang in the kernel. The scenario is probably rare'ish because affected architecture are embedded and tend to not swap much (if at all) so we probably rarely hit the case where dirty is missing or young is missing, but I think Shan has a piece of SW that can reliably reproduce it using a shared writable mapping & fork or something like that. On archs who use SW tracking of dirty & young, a page without dirty is effectively mapped read-only and a page without young unaccessible in the PTE. Additionally, some architectures might lazily flush the TLB when relaxing write protection (by doing only a local flush), and expect a fault to invalidate the stale entry if it's still present on another processor. The futex code assumes that if the "in_atomic()" access -EFAULT's, it can "fix it up" by causing get_user_pages() which would then be equivalent to taking the fault. However that isn't the case. get_user_pages() will not call handle_mm_fault() in the case where the PTE seems to have the right permissions, regardless of the dirty and young state. It will eventually update those bits ... in the struct page, but not in the PTE. Additionally, it will not handle the lazy TLB flushing that can be required by some architectures in the fault case. Basically, gup is the wrong interface for the job. The patch provides a more appropriate one which boils down to just calling handle_mm_fault() since what we are trying to do is simulate a real page fault. The futex code currently attempts to write to user memory within a pagefault disabled section, and if that fails, tries to fix it up using get_user_pages(). This doesn't work on archs where the dirty and young bits are maintained by software, since they will gate access permission in the TLB, and will not be updated by gup(). In addition, there's an expectation on some archs that a spurious write fault triggers a local TLB flush, and that is missing from the picture as well. I decided that adding those "features" to gup() would be too much for this already too complex function, and instead added a new simpler fixup_user_fault() which is essentially a wrapper around handle_mm_fault() which the futex code can call. [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: fix some nits Darren saw, fiddle comment layout] Signed-off-by: Benjamin Herrenschmidt Reported-by: Shan Hai Tested-by: Shan Hai Cc: David Laight Acked-by: Peter Zijlstra Cc: Darren Hart Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Andi Kleen commit 76a1fd83341756986f8c317109aff4ac3d27ba97 Author: H. Peter Anvin Date: Thu Jul 21 11:22:21 2011 -0700 x86: Make Dell Latitude E6420 use reboot=pci [ upstream commit a536877e77f73ea22d12d94a019fedd9671b6acd ] Yet another variant of the Dell Latitude series which requires reboot=pci. From the E5420 bug report by Daniel J Blueman: > The E6420 is affected also (same platform, different casing and > features), which provides an external confirmation of the issue; I can > submit a patch for that later or include it if you prefer: > http://linux.koolsolutions.com/2009/08/04/howto-fix-linux-hangfreeze-during-reboots-and-restarts/ Reported-by: Daniel J Blueman Signed-off-by: H. Peter Anvin Cc: Signed-off-by: Andi Kleen commit d05d43cd875bb21f94fd39d814e05d6ac3e8baa8 Author: Daniel J Blueman Date: Fri May 13 09:04:59 2011 +0800 x86: Make Dell Latitude E5420 use reboot=pci [ upstream commit b7798d28ec15d20fd34b70fa57eb13f0cf6d1ecd ] Rebooting on the Dell E5420 often hangs with the keyboard or ACPI methods, but is reliable via the PCI method. [ hpa: this was deferred because we believed for a long time that the recent reshuffling of the boot priorities in commit 660e34cebf0a11d54f2d5dd8838607452355f321 fixed this platform. Unfortunately that turned out to be incorrect. ] Signed-off-by: Daniel J Blueman Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1305248699-2347-1-git-send-email-daniel.blueman@gmail.com Signed-off-by: H. Peter Anvin Cc: commit 5c118168c852e64bc273ad62b63b773cd58a4efc Author: Dan Rosenberg Date: Wed Jun 15 15:09:01 2011 -0700 alpha: fix several security issues [ upstream commit 21c5977a836e399fc710ff2c5367845ed5c2527f ] Fix several security issues in Alpha-specific syscalls. Untested, but mostly trivial. 1. Signedness issue in osf_getdomainname allows copying out-of-bounds kernel memory to userland. 2. Signedness issue in osf_sysinfo allows copying large amounts of kernel memory to userland. 3. Typo (?) in osf_getsysinfo bounds minimum instead of maximum copy size, allowing copying large amounts of kernel memory to userland. 4. Usage of user pointer in osf_wait4 while under KERNEL_DS allows privilege escalation via writing return value of sys_wait4 to kernel memory. Said to fix CVE-2011-2208 to CVE-2011-2211 Signed-off-by: Dan Rosenberg Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: Matt Turner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Andi Kleen commit 658a3f90a819379393ff18d97a28b55ae8ed6328 Author: Vasiliy Kulikov Date: Fri Jun 24 16:08:38 2011 +0400 proc: restrict access to /proc/PID/io [ upstream commit 1d1221f375c94ef961ba8574ac4f85c8870ddd51 ] /proc/PID/io may be used for gathering private information. E.g. for openssh and vsftpd daemons wchars/rchars may be used to learn the precise password length. Restrict it to processes being able to ptrace the target process. ptrace_may_access() is needed to prevent keeping open file descriptor of "io" file, executing setuid binary and gathering io information of the setuid'ed process. Said to be CVE-2011-2495 Signed-off-by: Vasiliy Kulikov Signed-off-by: Linus Torvalds Signed-off-by: Andi Kleen commit 2d32f62fbbad8f663c26df23242113ef9464f790 Author: Miklos Szeredi Date: Wed Feb 23 13:49:47 2011 +0100 mm: prevent concurrent unmap_mapping_range() on the same inode commit 2aa15890f3c191326678f1bd68af61ec6b8753ec upstream. Michael Leun reported that running parallel opens on a fuse filesystem can trigger a "kernel BUG at mm/truncate.c:475" Gurudas Pai reported the same bug on NFS. The reason is, unmap_mapping_range() is not prepared for more than one concurrent invocation per inode. For example: thread1: going through a big range, stops in the middle of a vma and stores the restart address in vm_truncate_count. thread2: comes in with a small (e.g. single page) unmap request on the same vma, somewhere before restart_address, finds that the vma was already unmapped up to the restart address and happily returns without doing anything. Another scenario would be two big unmap requests, both having to restart the unmapping and each one setting vm_truncate_count to its own value. This could go on forever without any of them being able to finish. Truncate and hole punching already serialize with i_mutex. Other callers of unmap_mapping_range() do not, and it's difficult to get i_mutex protection for all callers. In particular ->d_revalidate(), which calls invalidate_inode_pages2_range() in fuse, may be called with or without i_mutex. This patch adds a new mutex to 'struct address_space' to prevent running multiple concurrent unmap_mapping_range() on the same mapping. [ We'll hopefully get rid of all this with the upcoming mm preemptibility series by Peter Zijlstra, the "mm: Remove i_mmap_mutex lockbreak" patch in particular. But that is for 2.6.39 ] Signed-off-by: Miklos Szeredi Reported-by: Michael Leun Reported-by: Gurudas Pai Tested-by: Gurudas Pai Acked-by: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit cc51d661483c95a61b5385e70e56af019059bde8 Author: Xufeng Zhang Date: Tue Jun 21 10:43:40 2011 +0000 udp/recvmsg: Clear MSG_TRUNC flag when starting over for a new packet [ Upstream commit 9cfaa8def1c795a512bc04f2aec333b03724ca2e ] Consider this scenario: When the size of the first received udp packet is bigger than the receive buffer, MSG_TRUNC bit is set in msg->msg_flags. However, if checksum error happens and this is a blocking socket, it will goto try_again loop to receive the next packet. But if the size of the next udp packet is smaller than receive buffer, MSG_TRUNC flag should not be set, but because MSG_TRUNC bit is not cleared in msg->msg_flags before receive the next packet, MSG_TRUNC is still set, which is wrong. Fix this problem by clearing MSG_TRUNC flag when starting over for a new packet. Signed-off-by: Xufeng Zhang Signed-off-by: Paul Gortmaker Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit f5e8deec38218b6c2c20b546dd7727640d68d8f5 Author: Xufeng Zhang Date: Tue Jun 21 10:43:39 2011 +0000 ipv6/udp: Use the correct variable to determine non-blocking condition [ Upstream commit 32c90254ed4a0c698caa0794ebb4de63fcc69631 ] udpv6_recvmsg() function is not using the correct variable to determine whether or not the socket is in non-blocking operation, this will lead to unexpected behavior when a UDP checksum error occurs. Consider a non-blocking udp receive scenario: when udpv6_recvmsg() is called by sock_common_recvmsg(), MSG_DONTWAIT bit of flags variable in udpv6_recvmsg() is cleared by "flags & ~MSG_DONTWAIT" in this call: err = sk->sk_prot->recvmsg(iocb, sk, msg, size, flags & MSG_DONTWAIT, flags & ~MSG_DONTWAIT, &addr_len); i.e. with udpv6_recvmsg() getting these values: int noblock = flags & MSG_DONTWAIT int flags = flags & ~MSG_DONTWAIT So, when udp checksum error occurs, the execution will go to csum_copy_err, and then the problem happens: csum_copy_err: ............... if (flags & MSG_DONTWAIT) return -EAGAIN; goto try_again; ............... But it will always go to try_again as MSG_DONTWAIT has been cleared from flags at call time -- only noblock contains the original value of MSG_DONTWAIT, so the test should be: if (noblock) return -EAGAIN; This is also consistent with what the ipv4/udp code does. Signed-off-by: Xufeng Zhang Signed-off-by: Paul Gortmaker Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 22cc5e3a5ba4c4dd731082e05cddfcab0bc456b4 Author: Marcus Meissner Date: Wed Jun 1 21:05:22 2011 -0700 net/ipv4: Check for mistakenly passed in non-IPv4 address [ Upstream commit d0733d2e29b652b2e7b1438ececa732e4eed98eb ] Check against mistakenly passing in IPv6 addresses (which would result in an INADDR_ANY bind) or similar incompatible sockaddrs. Signed-off-by: Marcus Meissner Cc: Reinhard Max Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 10f5dd7bd3448dd1234d0fee65c73048d244592c Author: Eric Dumazet Date: Mon Jun 6 22:42:06 2011 -0700 af_packet: prevent information leak [ Upstream commit 13fcb7bd322164c67926ffe272846d4860196dc6 ] In 2.6.27, commit 393e52e33c6c2 (packet: deliver VLAN TCI to userspace) added a small information leak. Add padding field and make sure its zeroed before copy to user. Signed-off-by: Eric Dumazet Signed-off-by: Andi Kleen CC: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7666ff7ed41d95540caa91717aad005578230a85 Author: Joe Perches Date: Sat May 21 07:48:40 2011 +0000 net: filter: Use WARN_RATELIMIT [ Upstream commit 6c4a5cb219520c7bc937ee186ca53f03733bd09f ] A mis-configured filter can spam the logs with lots of stack traces. Rate-limit the warnings and add printout of the bogus filter information. Original-patch-by: Ben Greear Signed-off-by: Joe Perches Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit ca62683d3b5f66f89e8b85ff2329cb1794d6c04c Author: Joe Perches Date: Sat May 21 07:48:39 2011 +0000 bug.h: Add WARN_RATELIMIT [ Upstream commit b3eec79b0776e5340a3db75b34953977c7e5086e ] Add a generic mechanism to ratelimit WARN(foo, fmt, ...) messages using a hidden per call site static struct ratelimit_state. Also add an __WARN_RATELIMIT variant to be able to use a specific struct ratelimit_state. Signed-off-by: Joe Perches Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit ccbd3ac7d060cbed807e2c46239149af716fb666 Author: Rafael J. Wysocki Date: Wed Jul 6 20:15:23 2011 +0200 PM / Hibernate: Fix free_unnecessary_pages() commit 4d4cf23cdde2f8f9324f5684a7f349e182039529 upstream. There is a bug in free_unnecessary_pages() that causes it to attempt to free too many pages in some cases, which triggers the BUG_ON() in memory_bm_clear_bit() for copy_bm. Namely, if count_data_pages() is initially greater than alloc_normal, we get to_free_normal equal to 0 and "save" greater from 0. In that case, if the sum of "save" and count_highmem_pages() is greater than alloc_highmem, we subtract a positive number from to_free_normal. Hence, since to_free_normal was 0 before the subtraction and is an unsigned int, the result is converted to a huge positive number that is used as the number of pages to free. Fix this bug by checking if to_free_normal is actually greater than or equal to the number we're going to subtract from it. Signed-off-by: Rafael J. Wysocki Signed-off-by: Andi Kleen Reported-and-tested-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit e892e8ae5702bff1eb6a7ba53d1daa7c9acdc88a Author: Eric Dumazet Date: Fri Jun 17 16:25:39 2011 -0400 inet_diag: fix inet_diag_bc_audit() [ Upstream commit eeb1497277d6b1a0a34ed36b97e18f2bd7d6de0d ] A malicious user or buggy application can inject code and trigger an infinite loop in inet_diag_bc_audit() Also make sure each instruction is aligned on 4 bytes boundary, to avoid unaligned accesses. Reported-by: Dan Rosenberg Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 8391972fad7fa9ecce49fe70872ca7e3817361b9 Author: Roland McGrath Date: Tue Oct 26 14:22:19 2010 -0700 uml: fix CONFIG_STATIC_LINK=y build failure with newer glibc commit aa5fb4dbfd121296ca97c68cf90043a7ea97579d upstream. With glibc 2.11 or later that was built with --enable-multi-arch, the UML link fails with undefined references to __rel_iplt_start and similar symbols. In recent binutils, the default linker script defines these symbols (see ld --verbose). Fix the UML linker scripts to match the new defaults for these sections. Signed-off-by: Roland McGrath Cc: Jeff Dike Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 90e554dbd8bf75807d34126330ec20a36b3c56db Author: Alan Stern Date: Wed Jun 15 16:29:16 2011 -0400 USB: don't let the hub driver prevent system sleep commit cbb330045e5df8f665ac60227ff898421fc8fb92 upstream. This patch (as1465) continues implementation of the policy that errors during suspend or hibernation should not prevent the system from going to sleep. In this case, failure to turn on the Suspend feature for a hub port shouldn't be reported as an error. There are situations where this does actually occur (such as when the device plugged into that port was disconnected in the recent past), and it turns out to be harmless. There's no reason for it to prevent a system sleep. Also, don't allow the hub driver to fail a system suspend if the downstream ports aren't all suspended. This is also harmless (and should never happen, given the change mentioned above); printing a warning message in the kernel log is all we really need to do. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 118c3b3aebbd814bc68c81da3d5de76408a377ad Author: Alan Stern Date: Wed Jun 15 16:27:43 2011 -0400 USB: don't let errors prevent system sleep commit 0af212ba8f123c2eba151af7726c34a50b127962 upstream. This patch (as1464) implements the recommended policy that most errors during suspend or hibernation should not prevent the system from going to sleep. In particular, failure to suspend a USB driver or a USB device should not prevent the sleep from succeeding: Failure to suspend a device won't matter, because the device will automatically go into suspend mode when the USB bus stops carrying packets. (This might be less true for USB-3.0 devices, but let's not worry about them now.) Failure of a driver to suspend might lead to trouble later on when the system wakes up, but it isn't sufficient reason to prevent the system from going to sleep. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit ed5ba3843ac94bee8cd5681ab13645dfc65d3b40 Author: Vasiliy Kulikov Date: Mon Jun 27 16:18:11 2011 -0700 taskstats: don't allow duplicate entries in listener mode commit 26c4caea9d697043cc5a458b96411b86d7f6babd upstream. Currently a single process may register exit handlers unlimited times. It may lead to a bloated listeners chain and very slow process terminations. Eg after 10KK sent TASKSTATS_CMD_ATTR_REGISTER_CPUMASKs ~300 Mb of kernel memory is stolen for the handlers chain and "time id" shows 2-7 seconds instead of normal 0.003. It makes it possible to exhaust all kernel memory and to eat much of CPU time by triggerring numerous exits on a single CPU. The patch limits the number of times a single process may register itself on a single CPU to one. One little issue is kept unfixed - as taskstats_exit() is called before exit_files() in do_exit(), the orphaned listener entry (if it was not explicitly deregistered) is kept until the next someone's exit() and implicit deregistration in send_cpu_listeners(). So, if a process registered itself as a listener exits and the next spawned process gets the same pid, it would inherit taskstats attributes. Signed-off-by: Vasiliy Kulikov Cc: Balbir Singh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 95cb3f2eefee6dd22468318a0d986598f6e9827d Author: Arnd Bergmann Date: Fri Jul 1 17:30:00 2011 -0700 6pack,mkiss: fix lock inconsistency commit 6e4e2f811bade330126d4029c88c831784a7efd9 upstream. Lockdep found a locking inconsistency in the mkiss_close function: > kernel: [ INFO: inconsistent lock state ] > kernel: 2.6.39.1 #3 > kernel: --------------------------------- > kernel: inconsistent {IN-SOFTIRQ-R} -> {SOFTIRQ-ON-W} usage. > kernel: ax25ipd/2813 [HC0[0]:SC0[0]:HE1:SE1] takes: > kernel: (disc_data_lock){+++?.-}, at: [] mkiss_close+0x1b/0x90 [mkiss] > kernel: {IN-SOFTIRQ-R} state was registered at: The message hints that disc_data_lock is aquired with softirqs disabled, but does not itself disable softirqs, which can in rare circumstances lead to a deadlock. The same problem is present in the 6pack driver, this patch fixes both by using write_lock_bh instead of write_lock. Reported-by: Bernard F6BVP Tested-by: Bernard F6BVP Signed-off-by: Arnd Bergmann Acked-by: Ralf Baechle Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 0d1ae88bf82c77ded2bf12c6e23d3cd7364bb1b4 Author: Trond Myklebust Date: Fri Jun 17 10:14:59 2011 -0400 SUNRPC: Ensure the RPC client only quits on fatal signals commit 5afa9133cfe67f1bfead6049a9640c9262a7101c upstream. Fix a couple of instances where we were exiting the RPC client on arbitrary signals. We should only do so on fatal signals. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 04bf190d9339a6cd5adef1a4b789517ff9838fdb Author: NeilBrown Date: Tue Jun 28 16:59:42 2011 +1000 md: avoid endless recovery loop when waiting for fail device to complete. commit 4274215d24633df7302069e51426659d4759c5ed upstream. If a device fails in a way that causes pending request to take a while to complete, md will not be able to immediately remove it from the array in remove_and_add_spares. It will then incorrectly look like a spare device and md will try to recover it even though it is failed. This leads to a recovery process starting and instantly aborting over and over again. We should check if the device is faulty before considering it to be a spare. This will avoid trying to start a recovery that cannot proceed. This bug was introduced in 2.6.26 so that patch is suitable for any kernel since then. Reported-by: Jim Paradis Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit c2f5b713e6efa93d5af22f6a7a807850023a608b Author: Jean Delvare Date: Wed Jun 29 11:36:10 2011 +0200 i2c-taos-evm: Fix log messages commit 9b640f2e154268cb516efcaf9c434f2e73c6783e upstream. * Print all error and information messages even when debugging is disabled. * Don't use adapter device to log messages before it is ready. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 3cc36915ad70bb028e8b4f748ed4a4e99834e3c0 Author: Shaohua Li Date: Mon Jun 27 09:03:47 2011 +0200 cfq-iosched: fix a rcu warning commit 3181faa85bda3dc3f5e630a1846526c9caaa38e3 upstream. I got a rcu warnning at boot. the ioc->ioc_data is rcu_deferenced, but doesn't hold rcu_read_lock. Signed-off-by: Shaohua Li Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit cf4ca69d46d49eb6fd8803f6618dd60184892835 Author: Jens Axboe Date: Sun Jun 5 06:01:13 2011 +0200 cfq-iosched: fix locking around ioc->ioc_data assignment commit ab4bd22d3cce6977dc039664cc2d052e3147d662 upstream. Since we are modifying this RCU pointer, we need to hold the lock protecting it around it. This fixes a potential reuse and double free of a cfq io_context structure. The bug has been in CFQ for a long time, it hit very few people but those it did hit seemed to see it a lot. Tracked in RH bugzilla here: https://bugzilla.redhat.com/show_bug.cgi?id=577968 Credit goes to Paul Bolle for figuring out that the issue was around the one-hit ioc->ioc_data cache. Thanks to his hard work the issue is now fixed. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit df9ceceff3742d28c59093c6c60b3ef1359fdf96 Author: Marcin Slusarz Date: Sat May 28 13:23:42 2011 +0200 debugobjects: Fix boot crash when kmemleak and debugobjects enabled commit 161b6ae0e067e421b20bb35caf66bdb405c929ac upstream. Order of initialization look like this: ... debugobjects kmemleak ...(lots of other subsystems)... workqueues (through early initcall) ... debugobjects use schedule_work for batch freeing of its data and kmemleak heavily use debugobjects, so when it comes to freeing and workqueues were not initialized yet, kernel crashes: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] __queue_work+0x29/0x41a [] queue_work_on+0x16/0x1d [] queue_work+0x29/0x55 [] schedule_work+0x13/0x15 [] free_object+0x90/0x95 [] debug_check_no_obj_freed+0x187/0x1d3 [] ? _raw_spin_unlock_irqrestore+0x30/0x4d [] ? free_object_rcu+0x68/0x6d [] kmem_cache_free+0x64/0x12c [] free_object_rcu+0x68/0x6d [] __rcu_process_callbacks+0x1b6/0x2d9 ... because system_wq is NULL. Fix it by checking if workqueues susbystem was initialized before using. Signed-off-by: Marcin Slusarz Cc: Catalin Marinas Cc: Tejun Heo Cc: Dipankar Sarma Cc: Paul E. McKenney Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/20110528112342.GA3068@joi.lan Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 92a311bf2271b5883e0370f2dee49b5a17f3ee66 Author: Florian Fainelli Date: Wed Jun 15 19:15:23 2011 +0200 watchdog: mtx1-wdt: request gpio before using it commit 9b19d40aa3ebaf1078779da10555da2ab8512422 upstream. Otherwise, the gpiolib autorequest feature will produce a WARN_ON(): WARNING: at drivers/gpio/gpiolib.c:101 0x8020ec6c() autorequest GPIO-215 [...] Signed-off-by: Florian Fainelli Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 611fc8078efc615210716abdb7410530ed6616e9 Author: Sjoerd Simons Date: Tue May 24 12:22:03 2011 -0300 uvcvideo: Remove buffers from the queues when freeing commit 8ca2c80b170c47eeb55f0c2a0f2b8edf85f35d49 upstream. When freeing memory for the video buffers also remove them from the irq & main queues. This fixes an oops when doing the following: open ("/dev/video", ..) VIDIOC_REQBUFS VIDIOC_QBUF VIDIOC_REQBUFS close () As the second VIDIOC_REQBUFS will cause the list entries of the buffers to be cleared while they still hang around on the main and irc queues Signed-off-by: Sjoerd Simons Acked-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit f425cb1dce09680c9790ef49c0aa3f2803f53b64 Author: Rafael Aquini Date: Wed Jun 15 15:08:39 2011 -0700 mm: fix negative commitlimit when gigantic hugepages are allocated commit b0320c7b7d1ac1bd5c2d9dff3258524ab39bad32 upstream. When 1GB hugepages are allocated on a system, free(1) reports less available memory than what really is installed in the box. Also, if the total size of hugepages allocated on a system is over half of the total memory size, CommitLimit becomes a negative number. The problem is that gigantic hugepages (order > MAX_ORDER) can only be allocated at boot with bootmem, thus its frames are not accounted to 'totalram_pages'. However, they are accounted to hugetlb_total_pages() What happens to turn CommitLimit into a negative number is this calculation, in fs/proc/meminfo.c: allowed = ((totalram_pages - hugetlb_total_pages()) * sysctl_overcommit_ratio / 100) + total_swap_pages; A similar calculation occurs in __vm_enough_memory() in mm/mmap.c. Also, every vm statistic which depends on 'totalram_pages' will render confusing values, as if system were 'missing' some part of its memory. Impact of this bug: When gigantic hugepages are allocated and sysctl_overcommit_memory == OVERCOMMIT_NEVER. In a such situation, __vm_enough_memory() goes through the mentioned 'allowed' calculation and might end up mistakenly returning -ENOMEM, thus forcing the system to start reclaiming pages earlier than it would be ususal, and this could cause detrimental impact to overall system's performance, depending on the workload. Besides the aforementioned scenario, I can only think of this causing annoyances with memory reports from /proc/meminfo and free(1). [akpm@linux-foundation.org: standardize comment layout] Reported-by: Russ Anderson Signed-off-by: Rafael Aquini Acked-by: Russ Anderson Cc: Andrea Arcangeli Cc: Christoph Lameter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 15f13f94ff3e34b02615c339ba77d1b79ba83054 Author: Eugene A. Shatokhin Date: Tue Jun 28 23:04:51 2011 -0400 ath5k: fix memory leak when fewer than N_PD_CURVES are in use commit a0b8de350be458b33248e48b2174d9af8a4c4798 upstream. We would free the proper number of curves, but in the wrong slots, due to a missing level of indirection through the pdgain_idx table. It's simpler just to try to free all four slots, so do that. Signed-off-by: Bob Copeland Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 50a771dfdad39b55910eb18c08c8a789b1281a59 Author: Michal Kubecek Date: Sat Jun 18 20:34:01 2011 +0200 PM: Free memory bitmaps if opening /dev/snapshot fails commit 8440f4b19494467883f8541b7aa28c7bbf6ac92b upstream. When opening /dev/snapshot device, snapshot_open() creates memory bitmaps which are freed in snapshot_release(). But if any of the callbacks called by pm_notifier_call_chain() returns NOTIFY_BAD, open() fails, snapshot_release() is never called and bitmaps are not freed. Next attempt to open /dev/snapshot then triggers BUG_ON() check in create_basic_memory_bitmaps(). This happens e.g. when vmwatchdog module is active on s390x. Signed-off-by: Michal Kubecek Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit fe2a1e38b67ce3138ed85fc7c55a044f0da4d560 Author: Sarah Sharp Date: Sun Jun 5 23:10:04 2011 -0700 xhci: Reject double add of active endpoints. commit fa75ac379e63c2864e9049b5e8615e40f65c1e70 upstream. While trying to switch a UAS device from the BOT configuration to the UAS configuration via the bConfigurationValue file, Tanya ran into an issue in the USB core. usb_disable_device() sets entries in udev->ep_out and udev->ep_out to NULL, but doesn't call into the xHCI bandwidth management functions to remove the BOT configuration endpoints from the xHCI host's internal structures. The USB core would then attempt to add endpoints for the UAS configuration, and some of the endpoints had the same address as endpoints in the BOT configuration. The xHCI driver blindly added the endpoints again, but the xHCI host controller rejected the Configure Endpoint command because active endpoints were added without being dropped. Make the xHCI driver reject calls to xhci_add_endpoint() that attempt to add active endpoints without first calling xhci_drop_endpoint(). This should be backported to kernels as old as 2.6.31. Signed-off-by: Sarah Sharp Reported-by: Tanya Brokhman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit b679fa56258fbe656e5b2f9803fc9918bb703df3 Author: Thomas Gleixner Date: Thu Jun 16 16:22:08 2011 +0200 clocksource: Make watchdog robust vs. interruption commit b5199515c25cca622495eb9c6a8a1d275e775088 upstream. The clocksource watchdog code is interruptible and it has been observed that this can trigger false positives which disable the TSC. The reason is that an interrupt storm or a long running interrupt handler between the read of the watchdog source and the read of the TSC brings the two far enough apart that the delta is larger than the unstable treshold. Move both reads into a short interrupt disabled region to avoid that. Reported-and-tested-by: Vernon Mauery Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit e80440bb851ed3378b9855dd2bc9a3763eef48f1 Author: Stefano Stabellini Date: Fri Jun 3 09:51:34 2011 +0000 xen: partially revert "xen: set max_pfn_mapped to the last pfn mapped" commit a91d92875ee94e4703fd017ccaadb48cfb344994 upstream. We only need to set max_pfn_mapped to the last pfn mapped on x86_64 to make sure that cleanup_highmap doesn't remove important mappings at _end. We don't need to do this on x86_32 because cleanup_highmap is not called on x86_32. Besides lowering max_pfn_mapped on x86_32 has the unwanted side effect of limiting the amount of memory available for the 1:1 kernel pagetable allocation. This patch reverts the x86_32 part of the original patch. Signed-off-by: Stefano Stabellini Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit a67f6f3794586c33e430d8a8e61d0548d33a3abe Author: Andrea Arcangeli Date: Thu Jun 16 12:56:19 2011 -0700 migrate: don't account swapcache as shmem commit 99a15e21d96f6857dafab1e5167e5e8183215c9c upstream. swapcache will reach the below code path in migrate_page_move_mapping, and swapcache is accounted as NR_FILE_PAGES but it's not accounted as NR_SHMEM. Hugh pointed out we must use PageSwapCache instead of comparing mapping to &swapper_space, to avoid build failure with CONFIG_SWAP=n. Signed-off-by: Andrea Arcangeli Acked-by: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit a5c70c5bbd56baea711ddd0dfe3e617d0ba20e6f Author: Hugh Dickins Date: Wed Jun 15 15:08:58 2011 -0700 ksm: fix NULL pointer dereference in scan_get_next_rmap_item() commit 2b472611a32a72f4a118c069c2d62a1a3f087afd upstream. Andrea Righi reported a case where an exiting task can race against ksmd::scan_get_next_rmap_item (http://lkml.org/lkml/2011/6/1/742) easily triggering a NULL pointer dereference in ksmd. ksm_scan.mm_slot == &ksm_mm_head with only one registered mm CPU 1 (__ksm_exit) CPU 2 (scan_get_next_rmap_item) list_empty() is false lock slot == &ksm_mm_head list_del(slot->mm_list) (list now empty) unlock lock slot = list_entry(slot->mm_list.next) (list is empty, so slot is still ksm_mm_head) unlock slot->mm == NULL ... Oops Close this race by revalidating that the new slot is not simply the list head again. Andrea's test case: #include #include #include #include #define BUFSIZE getpagesize() int main(int argc, char **argv) { void *ptr; if (posix_memalign(&ptr, getpagesize(), BUFSIZE) < 0) { perror("posix_memalign"); exit(1); } if (madvise(ptr, BUFSIZE, MADV_MERGEABLE) < 0) { perror("madvise"); exit(1); } *(char *)NULL = 0; return 0; } Reported-by: Andrea Righi Tested-by: Andrea Righi Cc: Andrea Arcangeli Signed-off-by: Hugh Dickins Signed-off-by: Chris Wright Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit e97ee080621da3c7c393a6f44118e930949e2f9e Author: Kasper Pedersen Date: Wed Oct 20 15:55:15 2010 -0700 time: Compensate for rounding on odd-frequency clocksources commit a386b5af8edda1c742ce9f77891e112eefffc005 upstream. When the clocksource is not a multiple of HZ, the clock will be off. For acpi_pm, HZ=1000 the error is 127.111 ppm: The rounding of cycle_interval ends up generating a false error term in ntp_error accumulation since xtime_interval is not exactly 1/HZ. So, we subtract out the error caused by the rounding. This has been visible since 2.6.32-rc2 commit a092ff0f90cae22b2ac8028ecd2c6f6c1a9e4601 time: Implement logarithmic time accumulation That commit raised NTP_INTERVAL_FREQ and exposed the rounding error. testing tool: http://n1.taur.dk/permanent/testpmt.c Also tested with ntpd and a frequency counter. Signed-off-by: Kasper Pedersen Acked-by: john stultz Cc: John Kacur Cc: Clark Williams Cc: Martin Schwidefsky Signed-off-by: Andrew Morton Signed-off-by: Thomas Gleixner Signed-off-by: Will Tisdale Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 4bd6e30b48fb0c03f9546b711dc86a42fd606aa1 Author: Thomas Gleixner Date: Sat Feb 5 20:08:59 2011 +0000 xen: Use IRQF_FORCE_RESUME commit 676dc3cf5bc36a9e129a3ad8fe3bd7b2ebf20f5d upstream. Mark the IRQF_NO_SUSPEND interrupts IRQF_FORCE_RESUME and remove the extra walk through the interrupt descriptors. Signed-off-by: Thomas Gleixner Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Stefan Bader Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit c2bce5c31e51c5a5852d4c6c84c5cec4f69539e6 Author: Thomas Gleixner Date: Fri Feb 4 13:19:20 2011 +0100 genirq: Add IRQF_FORCE_RESUME commit dc5f219e88294b93009eef946251251ffffb6d60 upstream. Xen needs to reenable interrupts which are marked IRQF_NO_SUSPEND in the resume path. Add a flag to force the reenabling in the resume code. Tested-and-acked-by: Ian Campbell Signed-off-by: Thomas Gleixner Signed-off-by: Stefan Bader Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 5394cc86a6009e16ca706de9bd05049deedab4b2 Author: Ian Campbell Date: Mon Nov 1 16:30:09 2010 +0000 xen: events: do not unmask event channels on resume commit 6903591f314b8947d0e362bda7715e90eb9df75e upstream. The IRQ core code will take care of disabling and reenabling interrupts over suspend resume automatically, therefore we do not need to do this in the Xen event channel code. The only exception is those event channels marked IRQF_NO_SUSPEND which the IRQ core ignores. We must unmask these ourselves, taking care to obey the current IRQ_DISABLED status. Failure check for IRQ_DISABLED leads to enabling polled only event channels, such as that associated with the pv spinlocks, which must never be enabled: [ 21.970432] ------------[ cut here ]------------ [ 21.970432] kernel BUG at arch/x86/xen/spinlock.c:343! [ 21.970432] invalid opcode: 0000 [#1] SMP [ 21.970432] last sysfs file: /sys/devices/virtual/net/lo/operstate [ 21.970432] Modules linked in: [ 21.970432] [ 21.970432] Pid: 0, comm: swapper Not tainted (2.6.32.24-x86_32p-xen-01034-g787c727 #34) [ 21.970432] EIP: 0061:[] EFLAGS: 00010046 CPU: 3 [ 21.970432] EIP is at dummy_handler+0x3/0x7 [ 21.970432] EAX: 0000021c EBX: dfc16880 ECX: 0000001a EDX: 00000000 [ 21.970432] ESI: dfc02c00 EDI: 00000001 EBP: dfc47e10 ESP: dfc47e10 [ 21.970432] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069 [ 21.970432] Process swapper (pid: 0, ti=dfc46000 task=dfc39440 task.ti=dfc46000) [ 21.970432] Stack: [ 21.970432] dfc47e30 c10a39f0 0000021c 00000000 00000000 dfc16880 0000021c 00000001 [ 21.970432] <0> dfc47e40 c10a4f08 0000021c 00000000 dfc47e78 c12240a7 c1839284 c1839284 [ 21.970432] <0> 00000200 00000000 00000000 f5720000 c1f3d028 c1f3d02c 00000180 dfc47e90 [ 21.970432] Call Trace: [ 21.970432] [] ? handle_IRQ_event+0x5f/0x122 [ 21.970432] [] ? handle_percpu_irq+0x2f/0x55 [ 21.970432] [] ? __xen_evtchn_do_upcall+0xdb/0x15f [ 21.970432] [] ? xen_evtchn_do_upcall+0x20/0x30 [ 21.970432] [] ? xen_do_upcall+0x7/0xc [ 21.970432] [] ? apic_reg_read+0xd3/0x22d [ 21.970432] [] ? hypercall_page+0x227/0x1005 [ 21.970432] [] ? xen_force_evtchn_callback+0xf/0x14 [ 21.970432] [] ? check_events+0x8/0xc [ 21.970432] [] ? xen_irq_enable_direct_end+0x0/0x1 [ 21.970432] [] ? finish_task_switch+0x62/0xba [ 21.970432] [] ? schedule+0x808/0x89d [ 21.970432] [] ? hrtimer_start_expires+0x1a/0x22 [ 21.970432] [] ? tick_nohz_restart_sched_tick+0x15a/0x162 [ 21.970432] [] ? cpu_idle+0x6d/0x6f [ 21.970432] [] ? cpu_bringup_and_idle+0xd/0xf [ 21.970432] Code: 5d 0f 95 c0 0f b6 c0 c3 55 66 83 78 02 00 89 e5 5d 0f 95 \ c0 0f b6 c0 c3 55 b2 01 86 10 31 c0 84 d2 89 e5 0f 94 c0 5d c3 55 89 e5 <0f> 0b \ eb fe 55 80 3d 4c ce 84 c1 00 89 e5 57 56 89 c6 53 74 15 [ 21.970432] EIP: [] dummy_handler+0x3/0x7 SS:ESP 0069:dfc47e10 [ 21.970432] ---[ end trace c0b71f7e12cf3011 ]--- Signed-off-by: Ian Campbell Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Stefan Bader Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 68b05c3c9f020650fbb69984eefe780bfec80a69 Author: Fernando Luis Vazquez Cao Date: Tue May 10 10:00:21 2011 +0200 netfilter: IPv6: fix DSCP mangle code commit 1ed2f73d90fb49bcf5704aee7e9084adb882bfc5 upstream. The mask indicates the bits one wants to zero out, so it needs to be inverted before applying to the original TOS field. Signed-off-by: Fernando Luis Vazquez Cao Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 5ee8f122be3b022ebbfa365c124d541dab5bebbd Author: Fernando Luis Vazquez Cao Date: Tue May 10 09:55:44 2011 +0200 netfilter: IPv6: initialize TOS field in REJECT target module commit 4319cc0cf5bb894b7368008cdf6dd20eb8868018 upstream. The IPv6 header is not zeroed out in alloc_skb so we must initialize it properly unless we want to see IPv6 packets with random TOS fields floating around. The current implementation resets the flow label but this could be changed if deemed necessary. We stumbled upon this issue when trying to apply a mangle rule to the RST packet generated by the REJECT target module. Signed-off-by: Fernando Luis Vazquez Cao Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 51f5cfcb1c84031b2fe4b134ae85c36de4b451c8 Author: Mathias Krause Date: Thu Jun 9 20:05:18 2011 +0200 exec: delay address limit change until point of no return commit dac853ae89043f1b7752875300faf614de43c74b upstream. Unconditionally changing the address limit to USER_DS and not restoring it to its old value in the error path is wrong because it prevents us using kernel memory on repeated calls to this function. This, in fact, breaks the fallback of hard coded paths to the init program from being ever successful if the first candidate fails to load. With this patch applied switching to USER_DS is delayed until the point of no return is reached which makes it possible to have a multi-arch rootfs with one arch specific init binary for each of the (hard coded) probed paths. Since the address limit is already set to USER_DS when start_thread() will be invoked, this redundancy can be safely removed. Signed-off-by: Mathias Krause Cc: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit f5404e8ba2873b04e010c6cd2750ce8058736386 Author: Namhyung Kim Date: Mon Jun 13 14:48:22 2011 +0900 md/raid5: fix raid5_set_bi_hw_segments commit 9b2dc8b665932a8e681a7ab3237f60475e75e161 upstream. The @bio->bi_phys_segments consists of active stripes count in the lower 16 bits and processed stripes count in the upper 16 bits. So logical-OR operator should be bitwise one. This bug has been present since 2.6.27 and the fix is suitable for any -stable kernel since then. Fortunately the bad code is only used on error paths and is relatively unlikely to be hit. Signed-off-by: Namhyung Kim Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 8a3c154695b81f55ae4f38b46b86a9db6af73cbc Author: Namhyung Kim Date: Thu Jun 9 11:42:54 2011 +1000 md: check ->hot_remove_disk when removing disk commit 01393f3d5836b7d62e925e6f4658a7eb22b83a11 upstream. Check pers->hot_remove_disk instead of pers->hot_add_disk in slot_store() during disk removal. The linear personality only has ->hot_add_disk and no ->hot_remove_disk, so that removing disk in the array resulted to following kernel bug: $ sudo mdadm --create /dev/md0 --level=linear --raid-devices=4 /dev/loop[0-3] $ echo none | sudo tee /sys/block/md0/md/dev-loop2/slot BUG: unable to handle kernel NULL pointer dereference at (null) IP: [< (null)>] (null) PGD c9f5d067 PUD 8575a067 PMD 0 Oops: 0010 [#1] SMP CPU 2 Modules linked in: linear loop bridge stp llc kvm_intel kvm asus_atk0110 sr_mod cdrom sg Pid: 10450, comm: tee Not tainted 3.0.0-rc1-leonard+ #173 System manufacturer System Product Name/P5G41TD-M PRO RIP: 0010:[<0000000000000000>] [< (null)>] (null) RSP: 0018:ffff880085757df0 EFLAGS: 00010282 RAX: ffffffffa00168e0 RBX: ffff8800d1431800 RCX: 000000000000006e RDX: 0000000000000001 RSI: 0000000000000002 RDI: ffff88008543c000 RBP: ffff880085757e48 R08: 0000000000000002 R09: 000000000000000a R10: 0000000000000000 R11: ffff88008543c2e0 R12: 00000000ffffffff R13: ffff8800b4641000 R14: 0000000000000005 R15: 0000000000000000 FS: 00007fe8c9e05700(0000) GS:ffff88011fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 00000000b4502000 CR4: 00000000000406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process tee (pid: 10450, threadinfo ffff880085756000, task ffff8800c9f08000) Stack: ffffffff8138496a ffff8800b4641000 ffff88008543c268 0000000000000000 ffff8800b4641000 ffff88008543c000 ffff8800d1431868 ffffffff81a78a90 ffff8800b4641000 ffff88008543c000 ffff8800d1431800 ffff880085757e98 Call Trace: [] ? slot_store+0xaa/0x265 [] rdev_attr_store+0x89/0xa8 [] sysfs_write_file+0x108/0x144 [] vfs_write+0xb1/0x10d [] ? trace_hardirqs_on_caller+0x111/0x135 [] sys_write+0x4d/0x77 [] system_call_fastpath+0x16/0x1b Code: Bad RIP value. RIP [< (null)>] (null) RSP CR2: 0000000000000000 ---[ end trace ba5fc64319a826fb ]--- Signed-off-by: Namhyung Kim Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit bfac194346ce63ac8a7cec0842a4e65d22f9d708 Author: Dave Jones Date: Sun Jun 12 16:35:28 2011 -0400 CPUFREQ: Remove cpufreq_stats sysfs entries on module unload. commit 13f067537f34456443f61c950cd6dc37d1d5f3ee upstream. cpufreq_stats leaves behind its sysfs entries, which causes a panic when something stumbled across them. (Discovered by unloading cpufreq_stats while powertop was loaded). Signed-off-by: Dave Jones Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 1a280f789149283526c9e0975bfd36cc70605921 Author: Robert Richter Date: Tue May 31 12:35:41 2011 +0200 oprofile, dcookies: Fix possible circular locking dependency commit fe47ae7f53e179d2ef6771024feb000cbb86640f upstream. The lockdep warning below detects a possible A->B/B->A locking dependency of mm->mmap_sem and dcookie_mutex. The order in sync_buffer() is mm->mmap_sem/dcookie_mutex, while in sys_lookup_dcookie() it is vice versa. Fixing it in sys_lookup_dcookie() by unlocking dcookie_mutex before copy_to_user(). oprofiled/4432 is trying to acquire lock: (&mm->mmap_sem){++++++}, at: [] might_fault+0x53/0xa3 but task is already holding lock: (dcookie_mutex){+.+.+.}, at: [] sys_lookup_dcookie+0x45/0x149 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (dcookie_mutex){+.+.+.}: [] lock_acquire+0xf8/0x11e [] mutex_lock_nested+0x63/0x309 [] get_dcookie+0x30/0x144 [] sync_buffer+0x196/0x3ec [oprofile] [] task_exit_notify+0x16/0x1a [oprofile] [] notifier_call_chain+0x37/0x63 [] __blocking_notifier_call_chain+0x50/0x67 [] blocking_notifier_call_chain+0x14/0x16 [] profile_task_exit+0x1a/0x1c [] do_exit+0x2a/0x6fc [] do_group_exit+0x83/0xae [] sys_exit_group+0x17/0x1b [] system_call_fastpath+0x16/0x1b -> #0 (&mm->mmap_sem){++++++}: [] __lock_acquire+0x1085/0x1711 [] lock_acquire+0xf8/0x11e [] might_fault+0x80/0xa3 [] sys_lookup_dcookie+0x104/0x149 [] system_call_fastpath+0x16/0x1b other info that might help us debug this: 1 lock held by oprofiled/4432: #0: (dcookie_mutex){+.+.+.}, at: [] sys_lookup_dcookie+0x45/0x149 stack backtrace: Pid: 4432, comm: oprofiled Not tainted 2.6.39-00008-ge5a450d #9 Call Trace: [] print_circular_bug+0xae/0xbc [] __lock_acquire+0x1085/0x1711 [] ? get_parent_ip+0x11/0x42 [] ? might_fault+0x53/0xa3 [] lock_acquire+0xf8/0x11e [] ? might_fault+0x53/0xa3 [] ? path_put+0x22/0x27 [] might_fault+0x80/0xa3 [] ? might_fault+0x53/0xa3 [] sys_lookup_dcookie+0x104/0x149 [] system_call_fastpath+0x16/0x1b References: https://bugzilla.kernel.org/show_bug.cgi?id=13809 Signed-off-by: Robert Richter Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit bd6b163efb2bb3bb53391778900bfab0877b4647 Author: Daniel T Chen Date: Mon Jun 6 18:55:34 2011 -0400 ALSA: hda: Fix quirk for Dell Inspiron 910 commit 0a1896b27b030529ec770aefd790544a1bdb7d5a upstream. BugLink: https://launchpad.net/bugs/792712 The original reporter states that sound from the internal speakers is inaudible until using the model=auto quirk. This symptom is due to an existing quirk mask for 0x102802b* that uses the model=dell quirk. To limit the possible regressions, leave the existing quirk mask but add a higher priority specific mask for the reporter's PCI SSID. Reported-and-tested-by: rodni hipp Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 4cd73ed3097d109d6724e7d475b5e4becdb63bde Author: Dmitry Torokhov Date: Tue May 31 14:37:23 2011 -0700 USB: xhci - fix interval calculation for FS isoc endpoints commit cd3c18ba2fac14b34d03cae111f215009735ea06 upstream. Full-speed isoc endpoints specify interval in exponent based form in frames, not microframes, so we need to adjust accordingly. NEC xHCI host controllers will return an error code of 0x11 if a full speed isochronous endpoint is added with the Interval field set to something less than 3 (2^3 = 8 microframes, or one frame). It is impossible for a full speed device to have an interval smaller than one frame. This was always an issue in the xHCI driver, but commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in xhci_get_endpoint_interval()" removed the clamping of the minimum value in the Interval field, which revealed this bug. This needs to be backported to stable kernels back to 2.6.31. Reported-by: Matt Evans Signed-off-by: Dmitry Torokhov Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit da619d59095a05bb75792f7133fe53dfaee34df1 Author: Steffen Sledz Date: Tue Jun 7 14:01:56 2011 +0200 USB: serial: add another 4N-GALAXY.DE PID to ftdi_sio driver commit a26d31cef06f43a76327c21235e75450869df2b8 upstream. E.g. newer CAN 2.0 A/B <=> USB 2.0 converters report idProduct=f3c2. Signed-off-by: Steffen Sledz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 98f5adc2ba1389a46cdf0037deb823a672656626 Author: Libor Pechacek Date: Fri May 20 14:53:25 2011 +0200 USB: core: Tolerate protocol stall during hub and port status read commit 3824c1ddaf744be44b170a335332b9d6afe79254 upstream. Protocol stall should not be fatal while reading port or hub status as it is transient state. Currently hub EP0 STALL during port status read results in failed device enumeration. This has been observed with ST-Ericsson (formerly Philips) USB 2.0 Hub (04cc:1521) after connecting keyboard. Signed-off-by: Libor Pechacek Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 1533b3eed5c2f38caa7a813163ff1f27264077bb Author: Toby Gray Date: Mon Jun 6 14:52:48 2011 +0100 USB: cdc-acm: Adding second ACM channel support for Nokia E7 and C7 commit 4061fde2fa80f40cb27114f60500d38d0afcf350 upstream. This adds the Nokia E7 and C7 to the list of devices in cdc-acm, allowing the secondary ACM channel on the device to be exposed. Without this patch the ACM driver won't claim this secondary channel as it's marked as having a vendor-specific protocol. Signed-off-by: Toby Gray Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 5d8e9bd2745ac9212f5a899471f46bfed2749d42 Author: Joerg Roedel Date: Mon Jun 6 16:04:02 2011 +0200 x86/amd-iommu: Fix 3 possible endless loops commit 0de66d5b35ee148455e268b2782873204ffdef4b upstream. The driver contains several loops counting on an u16 value where the exit-condition is checked against variables that can have values up to 0xffff. In this case the loops will never exit. This patch fixed 3 such loops. Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit ab0cc25a4b0367227df10f18c98db96af2db1dc0 Author: Dan Carpenter Date: Fri Jun 3 07:45:28 2011 +0300 xen: off by one errors in multicalls.c commit f124c6ae59e193705c9ddac57684d50006d710e6 upstream. b->args[] has MC_ARGS elements, so the comparison here should be ">=" instead of ">". Otherwise we read past the end of the array one space. Signed-off-by: Dan Carpenter Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit ff7cb9c3fe433028969fe28b5a542a0477b252b3 Author: OGAWA Hirofumi Date: Tue May 31 19:38:07 2011 +0900 fat: Fix corrupt inode flags when remove ATTR_SYS flag commit 1adffbae22332bb558c2a29de19d9aca391869f6 upstream. We are clearly missing '~' in fat_ioctl_set_attributes(). Reported-by: Dmitry Dmitriev Signed-off-by: OGAWA Hirofumi Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit ce63e3f96077c6979c9e1e31c5c3abef8c3d9dd9 Author: Daniel Haid Date: Wed Jun 8 20:04:45 2011 +1000 drm/radeon/kms: fix for radeon on systems >4GB without hardware iommu commit 62fff811d73095bd95579d72f558f03c78f7914a upstream. On my x86_64 system with >4GB of ram and swiotlb instead of a hardware iommu (because I have a VIA chipset), the call to pci_set_dma_mask (see below) with 40bits returns an error. But it seems that the radeon driver is designed to have need_dma32 = true exactly if pci_set_dma_mask is called with 32 bits and false if it is called with 40 bits. I have read somewhere that the default are 32 bits. So if the call fails I suppose that need_dma32 should be set to true. And indeed the patch fixes the problem I have had before and which I had described here: http://choon.net/forum/read.php?21,106131,115940 Acked-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 80f7f2adfc263a1d9ffcf8435c6bef49f56b2392 Author: Hans de Goede Date: Sat Jun 4 15:39:21 2011 +0200 drm/i915: Add a no lvds quirk for the Asus EeeBox PC EB1007 commit 6a574b5b9b186e28abd3e571dfd1700c5220b510 upstream. I found this while figuring out why gnome-shell would not run on my Asus EeeBox PC EB1007. As a standalone "pc" this device cleary does not have an internal panel, yet it claims it does. Add a quirk to fix this. Signed-off-by: Hans de Goede Reviewed-by: Keith Packard Signed-off-by: Keith Packard Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit d30a7fe49d445fcaf58e1fac46de3f931f37a81d Author: Peter Zijlstra Date: Mon Jun 6 12:32:43 2011 +0200 lockdep: Fix lock_is_held() on recursion commit f2513cde93f0957d5dc6c09bc24b0cccd27d8e1d upstream. The main lock_is_held() user is lockdep_assert_held(), avoid false assertions in lockdep_off() sections by unconditionally reporting the lock is taken. [ the reason this is important is a lockdep_assert_held() in ttwu() which triggers a warning under lockdep_off() as in printk() which can trigger another wakeup and lock up due to spinlock recursion, as reported and heroically debugged by Arne Jansen ] Reported-and-tested-by: Arne Jansen Signed-off-by: Peter Zijlstra Cc: Linus Torvalds Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1307398759.2497.966.camel@laptop Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 0fc485b9d3424421d751d9631ea850a8a6c4cae0 Author: Luciano Coelho Date: Thu May 19 00:43:38 2011 +0300 nl80211: fix check for valid SSID size in scan operations commit 208c72f4fe44fe09577e7975ba0e7fa0278f3d03 upstream. In both trigger_scan and sched_scan operations, we were checking for the SSID length before assigning the value correctly. Since the memory was just kzalloc'ed, the check was always failing and SSID with over 32 characters were allowed to go through. This was causing a buffer overflow when copying the actual SSID to the proper place. This bug has been there since 2.6.29-rc4. Signed-off-by: Luciano Coelho Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit e9ca82ad156fc553d935d3e11b63b377c87f92e7 Author: Jordan_Hargrave@Dell.com Date: Mon May 9 15:24:55 2011 -0500 PCI: Set PCIE maxpayload for card during hotplug insertion commit e522a7126c7c144a1dd14c6f217ac31e71082b1d upstream. The following patch sets the MaxPayload setting to match the parent reading when inserting a PCIE card into a hotplug slot. On our system, the upstream bridge is set to 256, but when inserting a card, the card setting defaults to 128. As soon as I/O is performed to the card it starts receiving errors since the payload size is too small. Reviewed-by: Kenji Kaneshige Signed-off-by: Jordan Hargrave Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 03e5ad56ab9cd164f7363a26a56c16c11c3ba758 Author: Hugh Dickins Date: Sun Jun 5 22:03:13 2011 -0700 mm: fix ENOSPC returned by handle_mm_fault() commit e0dcd8a05be438b3d2e49ef61441ea3a463663f8 upstream. Al Viro observes that in the hugetlb case, handle_mm_fault() may return a value of the kind ENOSPC when its caller is expecting a value of the kind VM_FAULT_SIGBUS: fix alloc_huge_page()'s failure returns. Signed-off-by: Hugh Dickins Acked-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit d4df7c4751eefc0130f4f8bdf396a4ea16876dd4 Author: James Bottomley Date: Wed May 25 15:52:14 2011 -0500 Fix oops caused by queue refcounting failure commit e73e079bf128d68284efedeba1fbbc18d78610f9 upstream. In certain circumstances, we can get an oops from a torn down device. Most notably this is from CD roms trying to call scsi_ioctl. The root cause of the problem is the fact that after scsi_remove_device() has been called, the queue is fully torn down. This is actually wrong since the queue can be used until the sdev release function is called. Therefore, we add an extra reference to the queue which is released in sdev->release, so the queue always exists. Reported-by: Parag Warudkar Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit f253441b14e828b6cb0c8d030d3985738730e5fd Author: Jens Axboe Date: Fri May 27 07:44:43 2011 +0200 block: export blk_{get,put}_queue() commit d86e0e83b32bc84600adb0b6ea1fce389b266682 upstream. We need them in SCSI to fix a bug, but currently they are not exported to modules. Export them. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 26d4cb6db4636d5d53d22500abb4be201b8fb8e5 Author: Namhyung Kim Date: Sat May 28 14:44:46 2011 +0200 nbd: limit module parameters to a sane value commit 3b2710824e00d238554c13b5add347e6c701ab1a upstream. The 'max_part' parameter controls the number of maximum partition a nbd device can have. However if a user specifies very large value it would exceed the limitation of device minor number and can cause a kernel oops (or, at least, produce invalid device nodes in some cases). In addition, specifying large 'nbds_max' value causes same problem for the same reason. On my desktop, following command results to the kernel bug: $ sudo modprobe nbd max_part=100000 kernel BUG at /media/Linux_Data/project/linux/fs/sysfs/group.c:65! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/virtual/block/nbd4/range CPU 1 Modules linked in: nbd(+) bridge stp llc kvm_intel kvm asus_atk0110 sg sr_mod cdrom Pid: 2522, comm: modprobe Tainted: G W 2.6.39-leonard+ #159 System manufacturer System Product Name/P5G41TD-M PRO RIP: 0010:[] [] internal_create_group+0x2f/0x166 RSP: 0018:ffff8801009f1de8 EFLAGS: 00010246 RAX: 00000000ffffffef RBX: ffff880103920478 RCX: 00000000000a7bd3 RDX: ffffffff81a2dbe0 RSI: 0000000000000000 RDI: ffff880103920478 RBP: ffff8801009f1e38 R08: ffff880103920468 R09: ffff880103920478 R10: ffff8801009f1de8 R11: ffff88011eccbb68 R12: ffffffff81a2dbe0 R13: ffff880103920468 R14: 0000000000000000 R15: ffff880103920400 FS: 00007f3c49de9700(0000) GS:ffff88011f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f3b7fe7c000 CR3: 00000000cd58d000 CR4: 00000000000406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process modprobe (pid: 2522, threadinfo ffff8801009f0000, task ffff8801009a93a0) Stack: ffff8801009f1e58 ffffffff812e8f6e ffff8801009f1e58 ffffffff812e7a80 ffff880000000010 ffff880103920400 ffff8801002fd0c0 ffff880103920468 0000000000000011 ffff880103920400 ffff8801009f1e48 ffffffff8115ab6a Call Trace: [] ? device_add+0x4f1/0x5e4 [] ? dev_set_name+0x41/0x43 [] sysfs_create_group+0x13/0x15 [] blk_trace_init_sysfs+0x14/0x16 [] blk_register_queue+0x4c/0xfd [] add_disk+0xe4/0x29c [] nbd_init+0x2ab/0x30d [nbd] [] ? 0xffffffffa007dfff [] do_one_initcall+0x7f/0x13e [] sys_init_module+0xa1/0x1e3 [] system_call_fastpath+0x16/0x1b Code: 41 57 41 56 41 55 41 54 53 48 83 ec 28 0f 1f 44 00 00 48 89 fb 41 89 f6 49 89 d4 48 85 ff 74 0b 85 f6 75 0b 48 83 7f 30 00 75 14 <0f> 0b eb fe b9 ea ff ff ff 48 83 7f 30 00 0f 84 09 01 00 00 49 RIP [] internal_create_group+0x2f/0x166 RSP ---[ end trace 753285ffbf72c57c ]--- Signed-off-by: Namhyung Kim Cc: Laurent Vivier Cc: Paul Clements Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 26543e37c91d678a14a2fcc6795f26f240bcad82 Author: Artem Bityutskiy Date: Tue May 31 08:40:40 2011 +0300 UBIFS: fix memory leak on error path commit 812eb258311f89bcd664a34a620f249d54a2cd83 upstream. UBIFS leaks memory on error path in 'ubifs_jnl_update()' in case of write failure because it forgets to free the 'struct ubifs_dent_node *dent' object. Although the object is small, the alignment can make it large - e.g., 2KiB if the min. I/O unit is 2KiB. Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 6093240b06916ca21216bb4728f79b264fd08e30 Author: Artem Bityutskiy Date: Tue May 31 07:03:21 2011 +0300 UBIFS: fix shrinker object count reports commit cf610bf4199770420629d3bc273494bd27ad6c1d upstream. Sometimes VM asks the shrinker to return amount of objects it can shrink, and we return the ubifs_clean_zn_cnt in that case. However, it is possible that this counter is negative for a short period of time, due to the way UBIFS TNC code updates it. And I can observe the following warnings sometimes: shrink_slab: ubifs_shrinker+0x0/0x2b7 [ubifs] negative objects to delete nr=-8541616642706119788 This patch makes sure UBIFS never returns negative count of objects. Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 6f0a1a45a8ed6c59710605fc763a5d3515a4324a Author: Tian, Kevin Date: Thu May 12 10:56:08 2011 +0800 xen mmu: fix a race window causing leave_mm BUG() commit 7899891c7d161752f29abcc9bc0a9c6c3a3af26c upstream. There's a race window in xen_drop_mm_ref, where remote cpu may exit dirty bitmap between the check on this cpu and the point where remote cpu handles drop request. So in drop_other_mm_ref we need check whether TLB state is still lazy before calling into leave_mm. This bug is rarely observed in earlier kernel, but exaggerated by the commit 831d52bc153971b70e64eccfbed2b232394f22f8 ("x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm") which clears bitmap after changing the TLB state. the call trace is as below: Signed-off-by: Andi Kleen --------------------------------- kernel BUG at arch/x86/mm/tlb.c:61! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/system/xen_memory/xen_memory0/info/current_kb CPU 1 Modules linked in: 8021q garp xen_netback xen_blkback blktap blkback_pagemap nbd bridge stp llc autofs4 ipmi_devintf ipmi_si ipmi_msghandler lockd sunrpc bonding ipv6 xenfs dm_multipath video output sbs sbshc parport_pc lp parport ses enclosure snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device serio_raw bnx2 snd_pcm_oss snd_mixer_oss snd_pcm snd_timer iTCO_wdt snd soundcore snd_page_alloc i2c_i801 iTCO_vendor_support i2c_core pcs pkr pata_acpi ata_generic ata_piix shpchp mptsas mptscsih mptbase [last unloaded: freq_table] Pid: 25581, comm: khelper Not tainted 2.6.32.36fixxen #1 Tecal RH2285 RIP: e030:[] [] leave_mm+0x15/0x46 RSP: e02b:ffff88002805be48 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88015f8e2da0 RDX: ffff88002805be78 RSI: 0000000000000000 RDI: 0000000000000001 RBP: ffff88002805be48 R08: ffff88009d662000 R09: dead000000200200 R10: dead000000100100 R11: ffffffff814472b2 R12: ffff88009bfc1880 R13: ffff880028063020 R14: 00000000000004f6 R15: 0000000000000000 FS: 00007f62362d66e0(0000) GS:ffff880028058000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000003aabc11909 CR3: 000000009b8ca000 CR4: 0000000000002660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000 00 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process khelper (pid: 25581, threadinfo ffff88007691e000, task ffff88009b92db40) Stack: ffff88002805be68 ffffffff8100e4ae 0000000000000001 ffff88009d733b88 <0> ffff88002805be98 ffffffff81087224 ffff88002805be78 ffff88002805be78 <0> ffff88015f808360 00000000000004f6 ffff88002805bea8 ffffffff81010108 Call Trace: [] drop_other_mm_ref+0x2a/0x53 [] generic_smp_call_function_single_interrupt+0xd8/0xfc [] xen_call_function_single_interrupt+0x13/0x28 [] handle_IRQ_event+0x66/0x120 [] handle_percpu_irq+0x41/0x6e [] __xen_evtchn_do_upcall+0x1ab/0x27d [] xen_evtchn_do_upcall+0x33/0x46 [] xen_do_hyper visor_callback+0x1e/0x30 [] ? _spin_unlock_irqrestore+0x15/0x17 [] ? xen_restore_fl_direct_end+0x0/0x1 [] ? flush_old_exec+0x3ac/0x500 [] ? load_elf_binary+0x0/0x17ef [] ? load_elf_binary+0x0/0x17ef [] ? load_elf_binary+0x398/0x17ef [] ? need_resched+0x23/0x2d [] ? process_measurement+0xc0/0xd7 [] ? load_elf_binary+0x0/0x17ef [] ? search_binary_handler+0xc8/0x255 [] ? do_execve+0x1c3/0x29e [] ? sys_execve+0x43/0x5d [] ? __call_usermodehelper+0x0/0x6f [] ? kernel_execve+0x68/0xd0 [] ? __call_usermodehelper+0x0/0x6f [] ? xen_restore_fl_direct_end+0x0/0x1 [] ? ____call_usermodehelper+0x113/0x11e [] ? child_rip+0xa/0x20 [] ? __call_usermodehelper+0x0/0x6f [] ? int_ret_from_sys_call+0x7/0x1b [] ? retint_restore_args+0x5/0x6 [] ? child_rip+0x0/0x20 Code: 41 5e 41 5f c9 c3 55 48 89 e5 0f 1f 44 00 00 e8 17 ff ff ff c9 c3 55 48 89 e5 0f 1f 44 00 00 65 8b 04 25 c8 55 01 00 ff c8 75 04 <0f> 0b eb fe 65 48 8b 34 25 c0 55 01 00 48 81 c6 b8 02 00 00 e8 RIP [] leave_mm+0x15/0x46 RSP ---[ end trace ce9cee6832a9c503 ]--- Tested-by: Maoxiaoyun Signed-off-by: Kevin Tian [v1: Fleshed out the git description a bit] Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 1c13a3d138b39388108ce6b5b610117da42e0ce2 Author: Hemant Pedanekar Date: Tue Apr 5 12:32:50 2011 +0530 PCI: Add quirk for setting valid class for TI816X Endpoint commit 63c4408074cbcc070ac17fc10e524800eb9bd0b0 upstream. TI816X (common name for DM816x/C6A816x/AM389x family) devices configured to boot as PCIe Endpoint have class code = 0. This makes kernel PCI bus code to skip allocating BARs to these devices resulting into following type of error when trying to enable them: "Device 0000:01:00.0 not available because of resource collisions" The device cannot be operated because of the above issue. This patch adds a ID specific (TI VENDOR ID and 816X DEVICE ID based) 'early' fixup quirk to replace class code with PCI_CLASS_MULTIMEDIA_VIDEO as class. Signed-off-by: Hemant Pedanekar Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit fa895d1e6b22dae5808052facfe11f83fed070ff Author: Trond Myklebust Date: Fri Mar 18 20:21:23 2011 -0400 SUNRPC: Deal with the lack of a SYN_SENT sk->sk_state_change callback... commit fe19a96b10032035a35779f42ad59e35d6dd8ffd upstream. The TCP connection state code depends on the state_change() callback being called when the SYN_SENT state is set. However the networking layer doesn't actually call us back in that case. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 0432b8c1ca35b185997de324b643ac83d554b02c Author: Namhyung Kim Date: Thu May 26 21:06:50 2011 +0200 brd: handle on-demand devices correctly commit af46566885a373b0a526932484cd8fef8de7b598 upstream. When finding or allocating a ram disk device, brd_probe() did not take partition numbers into account so that it can result to a different device. Consider following example (I set CONFIG_BLK_DEV_RAM_COUNT=4 for simplicity) : $ sudo modprobe brd max_part=15 $ ls -l /dev/ram* brw-rw---- 1 root disk 1, 0 2011-05-25 15:41 /dev/ram0 brw-rw---- 1 root disk 1, 16 2011-05-25 15:41 /dev/ram1 brw-rw---- 1 root disk 1, 32 2011-05-25 15:41 /dev/ram2 brw-rw---- 1 root disk 1, 48 2011-05-25 15:41 /dev/ram3 $ sudo mknod /dev/ram4 b 1 64 $ sudo dd if=/dev/zero of=/dev/ram4 bs=4k count=256 256+0 records in 256+0 records out 1048576 bytes (1.0 MB) copied, 0.00215578 s, 486 MB/s namhyung@leonhard:linux$ ls -l /dev/ram* brw-rw---- 1 root disk 1, 0 2011-05-25 15:41 /dev/ram0 brw-rw---- 1 root disk 1, 16 2011-05-25 15:41 /dev/ram1 brw-rw---- 1 root disk 1, 32 2011-05-25 15:41 /dev/ram2 brw-rw---- 1 root disk 1, 48 2011-05-25 15:41 /dev/ram3 brw-r--r-- 1 root root 1, 64 2011-05-25 15:45 /dev/ram4 brw-rw---- 1 root disk 1, 1024 2011-05-25 15:44 /dev/ram64 After this patch, /dev/ram4 - instead of /dev/ram64 - was accessed correctly. In addition, 'range' passed to blk_register_region() should include all range of dev_t that RAMDISK_MAJOR can address. It does not need to be limited by partition numbers unless 'rd_nr' param was specified. Signed-off-by: Namhyung Kim Cc: Laurent Vivier Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit b10337297efbda0eb8ca5f1da53648677791ebb2 Author: Namhyung Kim Date: Thu May 26 21:06:50 2011 +0200 brd: limit 'max_part' module param to DISK_MAX_PARTS commit 315980c8688c4b06713c1a5fe9d64cdf8ab57a72 upstream. The 'max_part' parameter controls the number of maximum partition a brd device can have. However if a user specifies very large value it would exceed the limitation of device minor number and can cause a kernel panic (or, at least, produce invalid device nodes in some cases). On my desktop system, following command kills the kernel. On qemu, it triggers similar oops but the kernel was alive: $ sudo modprobe brd max_part=100000 BUG: unable to handle kernel NULL pointer dereference at 0000000000000058 IP: [] sysfs_create_dir+0x2d/0xae PGD 7af1067 PUD 7b19067 PMD 0 Oops: 0000 [#1] SMP last sysfs file: CPU 0 Modules linked in: brd(+) Pid: 44, comm: insmod Tainted: G W 2.6.39-qemu+ #158 Bochs Bochs RIP: 0010:[] [] sysfs_create_dir+0x2d/0xae RSP: 0018:ffff880007b15d78 EFLAGS: 00000286 RAX: ffff880007b05478 RBX: ffff880007a52760 RCX: ffff880007b15dc8 RDX: ffff880007a4f900 RSI: ffff880007b15e48 RDI: ffff880007a52760 RBP: ffff880007b15da8 R08: 0000000000000002 R09: 0000000000000000 R10: ffff880007b15e48 R11: ffff880007b05478 R12: 0000000000000000 R13: ffff880007b05478 R14: 0000000000400920 R15: 0000000000000063 FS: 0000000002160880(0063) GS:ffff880007c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000058 CR3: 0000000007b1c000 CR4: 00000000000006b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000 Process insmod (pid: 44, threadinfo ffff880007b14000, task ffff880007acb980) Stack: ffff880007b15dc8 ffff880007b05478 ffff880007b15da8 00000000fffffffe ffff880007a52760 ffff880007b05478 ffff880007b15de8 ffffffff81143c0a 0000000000400920 ffff880007a52760 ffff880007b05478 0000000000000000 Call Trace: [] kobject_add_internal+0xdf/0x1a0 [] kobject_add_varg+0x41/0x50 [] kobject_add+0x64/0x66 [] blk_register_queue+0x5f/0xb8 [] add_disk+0xdf/0x289 [] brd_init+0xdf/0x1aa [brd] [] ? 0xffffffffa0003fff [] ? 0xffffffffa0003fff [] do_one_initcall+0x7a/0x12e [] sys_init_module+0x9c/0x1dc [] system_call_fastpath+0x16/0x1b Code: 89 e5 41 55 41 54 53 48 89 fb 48 83 ec 18 48 85 ff 75 04 0f 0b eb fe 48 8b 47 18 49 c7 c4 70 1e 4d 81 48 85 c0 74 04 4c 8b 60 30 8b 44 24 58 45 31 ed 0f b6 c4 85 c0 74 0d 48 8b 43 28 48 89 RIP [] sysfs_create_dir+0x2d/0xae RSP CR2: 0000000000000058 ---[ end trace aebb1175ce1f6739 ]--- Signed-off-by: Namhyung Kim Cc: Laurent Vivier Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 46fcbe707a5c02e357434409635c759e43d2a665 Author: Dan Williams Date: Fri May 27 04:51:54 2011 +0000 atm: expose ATM device index in sysfs commit e7a46b4d0839c2a3aa2e0ae0b145f293f6738498 upstream. It's currently exposed only through /proc which, besides requiring screen-scraping, doesn't allow userspace to distinguish between two identical ATM adapters with different ATM indexes. The ATM device index is required when using PPPoATM on a system with multiple ATM adapters. Signed-off-by: Dan Williams Reviewed-by: Eric Dumazet Tested-by: David Woodhouse Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 1e293bba2a05ab9b38d696c467de02b3b2b45331 Author: Milan Broz Date: Sun May 29 13:02:52 2011 +0100 dm table: reject devices without request fns commit f4808ca99a203f20b4475601748e44b25a65bdec upstream. This patch adds a check that a block device has a request function defined before it is used. Otherwise, misconfiguration can cause an oops. Because we are allowing devices with zero size e.g. an offline multipath device as in commit 2cd54d9bedb79a97f014e86c0da393416b264eb3 ("dm: allow offline devices") there needs to be an additional check to ensure devices are initialised. Some block devices, like a loop device without a backing file, exist but have no request function. Reproducer is trivial: dm-mirror on unbound loop device (no backing file on loop devices) dmsetup create x --table "0 8 mirror core 2 8 sync 2 /dev/loop0 0 /dev/loop1 0" and mirror resync will immediatelly cause OOps. BUG: unable to handle kernel NULL pointer dereference at (null) ? generic_make_request+0x2bd/0x590 ? kmem_cache_alloc+0xad/0x190 submit_bio+0x53/0xe0 ? bio_add_page+0x3b/0x50 dispatch_io+0x1ca/0x210 [dm_mod] ? read_callback+0x0/0xd0 [dm_mirror] dm_io+0xbb/0x290 [dm_mod] do_mirror+0x1e0/0x748 [dm_mirror] Signed-off-by: Milan Broz Reported-by: Zdenek Kabelac Acked-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 857053c1d4fcba46f8fdfcbc4926c1e70757d4a5 Author: Tero Kristo Date: Thu Feb 24 17:19:23 2011 +0200 cpuidle: menu: fixed wrapping timers at 4.294 seconds commit 7467571f4480b273007517b26297c07154c73924 upstream. Cpuidle menu governor is using u32 as a temporary datatype for storing nanosecond values which wrap around at 4.294 seconds. This causes errors in predicted sleep times resulting in higher than should be C state selection and increased power consumption. This also breaks cpuidle state residency statistics. Signed-off-by: Tero Kristo Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 500c1e95d2e4a846025091c8cabee761578fc6cc Author: Luca Tettamanti Date: Wed May 25 20:43:31 2011 +0200 i8k: Avoid lahf in 64-bit code commit bc1f419c76a2d6450413ce4349f4e4a07be011d5 upstream. i8k uses lahf to read the flag register in 64-bit code; early x86-64 CPUs, however, lack this instruction and we get an invalid opcode exception at runtime. Use pushf to load the flag register into the stack instead. Signed-off-by: Luca Tettamanti Reported-by: Jeff Rickman Tested-by: Jeff Rickman Tested-by: Harry G McGavran Jr Cc: Massimo Dal Zotto Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 5b67e307f5e085be7594117b77e61432c13c9c96 Author: Artem Bityutskiy Date: Fri May 6 17:08:56 2011 +0300 UBIFS: fix a rare memory leak in ro to rw remounting path commit eaeee242c531cd4b0a4a46e8b5dd7ef504380c42 upstream. When re-mounting from R/O mode to R/W mode and the LEB count in the superblock is not up-to date, because for the underlying UBI volume became larger, we re-write the superblock. We allocate RAM for these purposes, but never free it. So this is a memory leak, although very rare one. Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit e06b5bf516bfcc0f55d0577b14261fee1824c646 Author: Tyler Hicks Date: Tue May 17 00:50:33 2011 -0500 eCryptfs: Allow 2 scatterlist entries for encrypted filenames commit 8d08dab786ad5cc2aca2bf870de370144b78c85a upstream. The buffers allocated while encrypting and decrypting long filenames can sometimes straddle two pages. In this situation, virt_to_scatterlist() will return -ENOMEM, causing the operation to fail and the user will get scary error messages in their logs: kernel: ecryptfs_write_tag_70_packet: Internal error whilst attempting to convert filename memory to scatterlist; expected rc = 1; got rc = [-12]. block_aligned_filename_size = [272] kernel: ecryptfs_encrypt_filename: Error attempting to generate tag 70 packet; rc = [-12] kernel: ecryptfs_encrypt_and_encode_filename: Error attempting to encrypt filename; rc = [-12] kernel: ecryptfs_lookup: Error attempting to encrypt and encode filename; rc = [-12] The solution is to allow up to 2 scatterlist entries to be used. Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 117c0bc1b8a17622e4f93a744ba492b5da9d9fee Author: Christian Lamparter Date: Fri May 13 21:47:23 2011 +0200 p54usb: add zoom 4410 usbid commit 9368a9a2378ab721f82f59430a135b4ce4ff5109 upstream. Reported-by: Mark Davis Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 4e79c3eb206ca9d851e3eacbbbfc5b38aff5583a Author: Alan Stern Date: Mon May 16 12:15:19 2011 -0400 OHCI: fix regression caused by nVidia shutdown workaround commit 2b7aaf503d56216b847c8265421d2a7d9b42df3e upstream. This patch (as1463) fixes a regression caused by commit 3df7169e73fc1d71a39cffeacc969f6840cdf52b (OHCI: work around for nVidia shutdown problem). The original problem encountered by people using NVIDIA chipsets was that USB devices were not turning off when the system shut down. For example, the LED on an optical mouse would remain on, draining a laptop's battery. The problem was caused by a bug in the chipset; an OHCI controller in the Reset state would continue to drive a bus reset signal even after system shutdown. The workaround was to put the controllers into the Suspend state instead. It turns out that later NVIDIA chipsets do not suffer from this bug. Instead some have the opposite bug: If a system is shut down while an OHCI controller is in the Suspend state, USB devices remain powered! On other systems, shutting down with a Suspended controller causes the system to reboot immediately. Thus, working around the original bug on some machines exposes other bugs on other machines. The best solution seems to be to limit the workaround to OHCI controllers with a low-numbered PCI product ID. I don't know exactly at what point NVIDIA changed their chipsets; the value used here is a guess. So far it was worked out okay for all the people who have tested it. This fixes Bugzilla #35032. Signed-off-by: Alan Stern Tested-by: Andre "Osku" Schmidt Tested-by: Yury Siamashka Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 545e0ed639e969e5c02921fab5733f7c95693cb3 Author: Alan Stern Date: Fri Sep 10 16:37:05 2010 -0400 OHCI: work around for nVidia shutdown problem [ upstream commit 5f528de0ef9b3e092e276d95930830b847b33dc4 ] MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit commit 3df7169e73fc1d71a39cffeacc969f6840cdf52b upstream. This patch (as1417) fixes a problem affecting some (or all) nVidia chipsets. When the computer is shut down, the OHCI controllers continue to power the USB buses and evidently they drive a Reset signal out all their ports. This prevents attached devices from going to low power. Mouse LEDs stay on, for example, which is disconcerting for users and a drain on laptop batteries. The fix involves leaving each OHCI controller in the OPERATIONAL state during system shutdown rather than putting it in the RESET state. Although this nominally means the controller is running, in fact it's not doing very much since all the schedules are all disabled. However there is ongoing DMA to the Host Controller Communications Area, so the patch also disables the bus-master capability of all PCI USB controllers after the shutdown routine runs. The fix is applied only to nVidia-based PCI OHCI controllers, so it shouldn't cause problems on systems using other hardware. As an added safety measure, in case the kernel encounters one of these running controllers during boot, the patch changes quirk_usb_handoff_ohci() (which runs early on during PCI discovery) to reset the controller before anything bad can happen. Reported-by: Pali Rohár Signed-off-by: Alan Stern Signed-off-by: Andi Kleen CC: David Brownell Tested-by: Pali Rohár Signed-off-by: Greg Kroah-Hartman commit 9a355f7cab321c8f700d367b5b663a7364c6e19f Author: Sarah Sharp Date: Fri May 13 13:10:01 2011 -0700 xhci: Fix full speed bInterval encoding. commit b513d44751bfb609a3c20463f764c8ce822d63e9 upstream. Dmitry's patch dfa49c4ad120a784ef1ff0717168aa79f55a483a USB: xhci - fix math in xhci_get_endpoint_interval() introduced a bug. The USB 2.0 spec says that full speed isochronous endpoints' bInterval must be decoded as an exponent to a power of two (e.g. interval = 2^(bInterval - 1)). Full speed interrupt endpoints, on the other hand, don't use exponents, and the interval in frames is encoded straight into bInterval. Dmitry's patch was supposed to fix up the full speed isochronous to parse bInterval as an exponent, but instead it changed the *interrupt* endpoint bInterval decoding. The isochronous endpoint encoding was the same. This caused full speed devices with interrupt endpoints (including mice, hubs, and USB to ethernet devices) to fail under NEC 0.96 xHCI host controllers: [ 100.909818] xhci_hcd 0000:06:00.0: add ep 0x83, slot id 1, new drop flags = 0x0, new add flags = 0x99, new slot info = 0x38100000 [ 100.909821] xhci_hcd 0000:06:00.0: xhci_check_bandwidth called for udev ffff88011f0ea000 ... [ 100.910187] xhci_hcd 0000:06:00.0: ERROR: unexpected command completion code 0x11. [ 100.910190] xhci_hcd 0000:06:00.0: xhci_reset_bandwidth called for udev ffff88011f0ea000 When the interrupt endpoint was added and a Configure Endpoint command was issued to the host, the host controller would return a very odd error message (0x11 means "Slot Not Enabled", which isn't true because the slot was enabled). Probably the host controller was getting very confused with the bad encoding. Signed-off-by: Sarah Sharp Cc: Dmitry Torokhov Reported-by: Thomas Lindroth Tested-by: Thomas Lindroth Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit d4ffbbb11ad59a922ea546eda88316a3511890fe Author: Felipe Balbi Date: Fri May 13 16:53:48 2011 +0300 usb: gadget: rndis: don't test against req->length commit 472b91274a6c6857877b5caddb875dcb5ecdfcb8 upstream. composite.c always sets req->length to zero and expects function driver's setup handlers to return the amount of bytes to be used on req->length. If we test against req->length w_length will always be greater than req->length thus making us always stall that particular SEND_ENCAPSULATED_COMMAND request. Tested against a Windows XP SP3. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 207e1f6a999784bc8e7047f4ae9f72c73d48a9b2 Author: Jean-Christophe PLAGNIOL-VILLARD Date: Fri May 13 17:03:02 2011 +0200 usb/gadget: at91sam9g20 fix end point max packet size commit bf1f0a05d472e33dda8e5e69525be1584cdbd03a upstream. on 9g20 they are the same as the 9260 Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD Acked-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 4f94d4382c06a24196673a2e408dd257ac0ffbb4 Author: Hermann Kneissel Date: Fri Apr 29 08:58:43 2011 +0200 USB: gamin_gps: Fix for data transfer problems in native mode commit b4026c4584cd70858d4d3450abfb1cd0714d4f32 upstream. This patch fixes a problem where data received from the gps is sometimes transferred incompletely to the serial port. If used in native mode now all data received via the bulk queue will be forwarded to the serial port. Signed-off-by: Hermann Kneissel Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit e2835a5f7f667338aca34a7fada6f7c24423574b Author: Benedek László Date: Wed Apr 20 03:22:21 2011 +0200 USB: serial: ftdi_sio: adding support for TavIR STK500 commit 37909fe588c9e09ab57cd267e98678a17ceda64a upstream. Adding support for the TavIR STK500 (id 0403:FA33) Atmel AVR programmer device based on FTDI FT232RL. Signed-off-by: Benedek László Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 48e9e30804a4a52ef85f5f31abeafe12178c67a6 Author: Elizabeth Jennifer Myers Date: Sat Apr 16 14:49:51 2011 -0400 USB: moto_modem: Add USB identifier for the Motorola VE240. commit 3938a0b32dc12229e76735679b37095bc2bc1578 upstream. Tested on my phone, the ttyUSB device is created and is fully functional. Signed-off-by: Elizabeth Jennifer Myers Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 5bb5bf5a45b7c442459ab71f069c28215ae5a201 Author: Craig Shelley Date: Sun Mar 20 13:51:13 2011 +0000 USB: CP210x Add 4 Device IDs for AC-Services Devices commit 4eff0b40a7174896b860312910e0db51f2dcc567 upstream. This patch adds 4 device IDs for CP2102 based devices manufactured by AC-Services. See http://www.ac-services.eu for further info. Signed-off-by: Craig Shelley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit dfba2b9005ebcc9eea048dc4e7d29156747b1987 Author: Namhyung Kim Date: Tue May 24 16:48:55 2011 +0200 loop: handle on-demand devices correctly commit a1c15c59feee36267c43142a41152fbf7402afb6 upstream. When finding or allocating a loop device, loop_probe() did not take partition numbers into account so that it can result to a different device. Consider following example: $ sudo modprobe loop max_part=15 $ ls -l /dev/loop* brw-rw---- 1 root disk 7, 0 2011-05-24 22:16 /dev/loop0 brw-rw---- 1 root disk 7, 16 2011-05-24 22:16 /dev/loop1 brw-rw---- 1 root disk 7, 32 2011-05-24 22:16 /dev/loop2 brw-rw---- 1 root disk 7, 48 2011-05-24 22:16 /dev/loop3 brw-rw---- 1 root disk 7, 64 2011-05-24 22:16 /dev/loop4 brw-rw---- 1 root disk 7, 80 2011-05-24 22:16 /dev/loop5 brw-rw---- 1 root disk 7, 96 2011-05-24 22:16 /dev/loop6 brw-rw---- 1 root disk 7, 112 2011-05-24 22:16 /dev/loop7 $ sudo mknod /dev/loop8 b 7 128 $ sudo losetup /dev/loop8 ~/temp/disk-with-3-parts.img $ sudo losetup -a /dev/loop128: [0805]:278201 (/home/namhyung/temp/disk-with-3-parts.img) $ ls -l /dev/loop* brw-rw---- 1 root disk 7, 0 2011-05-24 22:16 /dev/loop0 brw-rw---- 1 root disk 7, 16 2011-05-24 22:16 /dev/loop1 brw-rw---- 1 root disk 7, 2048 2011-05-24 22:18 /dev/loop128 brw-rw---- 1 root disk 7, 2049 2011-05-24 22:18 /dev/loop128p1 brw-rw---- 1 root disk 7, 2050 2011-05-24 22:18 /dev/loop128p2 brw-rw---- 1 root disk 7, 2051 2011-05-24 22:18 /dev/loop128p3 brw-rw---- 1 root disk 7, 32 2011-05-24 22:16 /dev/loop2 brw-rw---- 1 root disk 7, 48 2011-05-24 22:16 /dev/loop3 brw-rw---- 1 root disk 7, 64 2011-05-24 22:16 /dev/loop4 brw-rw---- 1 root disk 7, 80 2011-05-24 22:16 /dev/loop5 brw-rw---- 1 root disk 7, 96 2011-05-24 22:16 /dev/loop6 brw-rw---- 1 root disk 7, 112 2011-05-24 22:16 /dev/loop7 brw-r--r-- 1 root root 7, 128 2011-05-24 22:17 /dev/loop8 After this patch, /dev/loop8 - instead of /dev/loop128 - was accessed correctly. In addition, 'range' passed to blk_register_region() should include all range of dev_t that LOOP_MAJOR can address. It does not need to be limited by partition numbers unless 'max_loop' param was specified. Signed-off-by: Namhyung Kim Cc: Laurent Vivier Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit fb3085bac19be01477364db550c4b9d4c0e13077 Author: Namhyung Kim Date: Tue May 24 16:48:54 2011 +0200 loop: limit 'max_part' module param to DISK_MAX_PARTS commit 78f4bb367fd147a0e7e3998ba6e47109999d8814 upstream. The 'max_part' parameter controls the number of maximum partition a loop block device can have. However if a user specifies very large value it would exceed the limitation of device minor number and can cause a kernel panic (or, at least, produce invalid device nodes in some cases). On my desktop system, following command kills the kernel. On qemu, it triggers similar oops but the kernel was alive: $ sudo modprobe loop max_part0000 ------------[ cut here ]------------ kernel BUG at /media/Linux_Data/project/linux/fs/sysfs/group.c:65! invalid opcode: 0000 [#1] SMP last sysfs file: CPU 0 Modules linked in: loop(+) Pid: 43, comm: insmod Tainted: G W 2.6.39-qemu+ #155 Bochs Bochs RIP: 0010:[] [] internal_create_group= +0x2a/0x170 RSP: 0018:ffff880007b3fde8 EFLAGS: 00000246 RAX: 00000000ffffffef RBX: ffff880007b3d878 RCX: 00000000000007b4 RDX: ffffffff8152da50 RSI: 0000000000000000 RDI: ffff880007b3d878 RBP: ffff880007b3fe38 R08: ffff880007b3fde8 R09: 0000000000000000 R10: ffff88000783b4a8 R11: ffff880007b3d878 R12: ffffffff8152da50 R13: ffff880007b3d868 R14: 0000000000000000 R15: ffff880007b3d800 FS: 0000000002137880(0063) GS:ffff880007c00000(0000) knlGS:00000000000000= 00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000422680 CR3: 0000000007b50000 CR4: 00000000000006b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000 Process insmod (pid: 43, threadinfo ffff880007b3e000, task ffff880007afb9c= 0) Stack: ffff880007b3fe58 ffffffff811e66dd ffff880007b3fe58 ffffffff811e570b 0000000000000010 ffff880007b3d800 ffff880007a7b390 ffff880007b3d868 0000000000400920 ffff880007b3d800 ffff880007b3fe48 ffffffff8113cfc8 Call Trace: [] ? device_add+0x4bc/0x5af [] ? dev_set_name+0x3c/0x3e [] sysfs_create_group+0xe/0x12 [] blk_trace_init_sysfs+0x14/0x16 [] blk_register_queue+0x47/0xf7 [] add_disk+0xdf/0x290 [] loop_init+0xeb/0x1b8 [loop] [] ? 0xffffffffa0005fff [] do_one_initcall+0x7a/0x12e [] sys_init_module+0x9c/0x1e0 [] system_call_fastpath+0x16/0x1b Code: c3 55 48 89 e5 41 57 41 56 41 89 f6 41 55 41 54 49 89 d4 53 48 89 fb= 48 83 ec 28 48 85 ff 74 0b 85 f6 75 0b 48 83 7f 30 00 75 14 <0f> 0b eb fe = 48 83 7f 30 00 b9 ea ff ff ff 0f 84 18 01 00 00 49 RIP [] internal_create_group+0x2a/0x170 RSP ---[ end trace a123eb592043acad ]--- Signed-off-by: Namhyung Kim Cc: Laurent Vivier Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit bb590ef04557a915fe6bd2818c23ed9cd46c5f2f Author: Andrew Barry Date: Tue May 24 17:12:52 2011 -0700 mm/page_alloc.c: prevent unending loop in __alloc_pages_slowpath() commit cfa54a0fcfc1017c6f122b6f21aaba36daa07f71 upstream. I believe I found a problem in __alloc_pages_slowpath, which allows a process to get stuck endlessly looping, even when lots of memory is available. Running an I/O and memory intensive stress-test I see a 0-order page allocation with __GFP_IO and __GFP_WAIT, running on a system with very little free memory. Right about the same time that the stress-test gets killed by the OOM-killer, the utility trying to allocate memory gets stuck in __alloc_pages_slowpath even though most of the systems memory was freed by the oom-kill of the stress-test. The utility ends up looping from the rebalance label down through the wait_iff_congested continiously. Because order=0, __alloc_pages_direct_compact skips the call to get_page_from_freelist. Because all of the reclaimable memory on the system has already been reclaimed, __alloc_pages_direct_reclaim skips the call to get_page_from_freelist. Since there is no __GFP_FS flag, the block with __alloc_pages_may_oom is skipped. The loop hits the wait_iff_congested, then jumps back to rebalance without ever trying to get_page_from_freelist. This loop repeats infinitely. The test case is pretty pathological. Running a mix of I/O stress-tests that do a lot of fork() and consume all of the system memory, I can pretty reliably hit this on 600 nodes, in about 12 hours. 32GB/node. Signed-off-by: Andrew Barry Signed-off-by: Minchan Kim Reviewed-by: Rik van Riel Acked-by: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit c7f49dc31ed8d10c288e034a82e1214f2c0c63c2 Author: Mark Brown Date: Sun May 15 12:18:38 2011 -0700 ASoC: Add some missing volume update bit sets for wm_hubs devices commit fb5af53d421d80725172427e9076f6e889603df6 upstream. Signed-off-by: Mark Brown Acked-by: Liam Girdwood Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 349419f96bd74bf077d6eb4ee5e4b9dd0902ab47 Author: Mark Brown Date: Sat May 14 17:21:28 2011 -0700 ASoC: Ensure output PGA is enabled for line outputs in wm_hubs commit d0b48af6c2b887354d0893e598d92911ce52620e upstream. Also fix a left/right typo while we're at it. Signed-off-by: Mark Brown Acked-by: Liam Girdwood Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 9657a2cc096762b77ba5743b15bf0c2a6cb829c1 Author: David Henningsson Date: Mon May 16 12:09:29 2011 +0200 ALSA: HDA: Use one dmic only for Dell Studio 1558 commit e033ebfb399227e01686260ac271029011bc6b47 upstream. There are no signs of a dmic at node 0x0b, so the user is left with an additional internal mic which does not exist. This commit removes that non-existing mic. BugLink: http://bugs.launchpad.net/bugs/731706 Reported-by: James Page Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 081104261c084dee58518bcbbd23e95910e3fbe3 Author: Milton Miller Date: Thu May 12 04:13:54 2011 -0500 seqlock: Don't smp_rmb in seqlock reader spin loop commit 5db1256a5131d3b133946fa02ac9770a784e6eb2 upstream. Move the smp_rmb after cpu_relax loop in read_seqlock and add ACCESS_ONCE to make sure the test and return are consistent. A multi-threaded core in the lab didn't like the update from 2.6.35 to 2.6.36, to the point it would hang during boot when multiple threads were active. Bisection showed af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867 (clockevents: Remove the per cpu tick skew) as the culprit and it is supported with stack traces showing xtime_lock waits including tick_do_update_jiffies64 and/or update_vsyscall. Experimentation showed the combination of cpu_relax and smp_rmb was significantly slowing the progress of other threads sharing the core, and this patch is effective in avoiding the hang. A theory is the rmb is affecting the whole core while the cpu_relax is causing a resource rebalance flush, together they cause an interfernce cadance that is unbroken when the seqlock reader has interrupts disabled. At first I was confused why the refactor in 3c22cd5709e8143444a6d08682a87f4c57902df3 (kernel: optimise seqlock) didn't affect this patch application, but after some study that affected seqcount not seqlock. The new seqcount was not factored back into the seqlock. I defer that the future. While the removal of the timer interrupt offset created contention for the xtime lock while a cpu does the additonal work to update the system clock, the seqlock implementation with the tight rmb spin loop goes back much further, and is just waiting for the right trigger. Signed-off-by: Milton Miller Cc: Cc: Linus Torvalds Cc: Andi Kleen Cc: Nick Piggin Cc: Benjamin Herrenschmidt Cc: Anton Blanchard Cc: Paul McKenney Acked-by: Eric Dumazet Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 60bdd71df9c36e1e1710155fded924e93347a9d2 Author: Timo Warns Date: Thu May 19 09:24:17 2011 +0200 Fix for buffer overflow in ldm_frag_add not sufficient commit cae13fe4cc3f24820ffb990c09110626837e85d4 upstream. As Ben Hutchings discovered [1], the patch for CVE-2011-1017 (buffer overflow in ldm_frag_add) is not sufficient. The original patch in commit c340b1d64000 ("fs/partitions/ldm.c: fix oops caused by corrupted partition table") does not consider that, for subsequent fragments, previously allocated memory is used. [1] http://lkml.org/lkml/2011/5/6/407 Reported-by: Ben Hutchings Signed-off-by: Timo Warns Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit c8648b4c2b720f21cba4040e47ce8dbc6e93ef8f Author: David Chang Date: Thu May 12 18:31:11 2011 +0800 staging: usbip: fix wrong endian conversion commit cacd18a8476ce145ca5dcd46dc5b75585fd1289c upstream. Fix number_of_packets wrong endian conversion in function correct_endian_ret_submit() Signed-off-by: David Chang Acked-by: Arjan Mels Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 738b2bfd83a0bc74f14ca52e7e0fc87be8996176 Author: Frederic Weisbecker Date: Fri May 20 02:09:54 2011 +0200 rcu: Fix unpaired rcu_irq_enter() from locking selftests commit ba9f207c9f82115aba4ce04b22e0081af0ae300f upstream. HARDIRQ_ENTER() maps to irq_enter() which calls rcu_irq_enter(). But HARDIRQ_EXIT() maps to __irq_exit() which doesn't call rcu_irq_exit(). So for every locking selftest that simulates hardirq disabled, we create an imbalance in the rcu extended quiescent state internal state. As a result, after the first missing rcu_irq_exit(), subsequent irqs won't exit dyntick-idle mode after leaving the interrupt handler. This means that RCU won't see the affected CPU as being in an extended quiescent state, resulting in long grace-period delays (as in grace periods extending for hours). To fix this, just use __irq_enter() to simulate the hardirq context. This is sufficient for the locking selftests as we don't need to exit any extended quiescent state or perform any check that irqs normally do when they wake up from idle. As a side effect, this patch makes it possible to restore "rcu: Decrease memory-barrier usage based on semi-formal proof", which eventually helped finding this bug. Reported-and-tested-by: Yinghai Lu Signed-off-by: Frederic Weisbecker Cc: Paul E. McKenney Cc: Ingo Molnar Cc: Peter Zijlstra Signed-off-by: Paul E. McKenney Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit b399e568ca3b163bdaeb121e0f3d735fb21d1f5b Author: Roedel, Joerg Date: Thu May 19 11:13:39 2011 +0200 x86, amd: Use _safe() msr access for GartTlbWlk disable code commit d47cc0db8fd6011de2248df505fc34990b7451bf upstream. The workaround for Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=33012 introduced a read and a write to the MC4 mask msr. Unfortunatly this MSR is not emulated by the KVM hypervisor so that the kernel will get a #GP and crashes when applying this workaround when running inside KVM. This issue was reported as: https://bugzilla.kernel.org/show_bug.cgi?id=35132 and is fixed with this patch. The change just let the kernel ignore any #GP it gets while accessing this MSR by using the _safe msr access methods. Reported-by: Török Edwin Signed-off-by: Joerg Roedel Cc: Rafael J. Wysocki Cc: Maciej Rutecki Cc: Avi Kivity Cc: Andrew Morton Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 6dcd6090760630cfcc8016b1c0382c1c50d42810 Author: Boris Ostrovsky Date: Thu May 26 11:19:52 2011 -0400 x86, amd: Do not enable ARAT feature on AMD processors below family 0x12 commit e9cdd343a5e42c43bcda01e609fa23089e026470 upstream. Commit b87cf80af3ba4b4c008b4face3c68d604e1715c6 added support for ARAT (Always Running APIC timer) on AMD processors that are not affected by erratum 400. This erratum is present on certain processor families and prevents APIC timer from waking up the CPU when it is in a deep C state, including C1E state. Determining whether a processor is affected by this erratum may have some corner cases and handling these cases is somewhat complicated. In the interest of simplicity we won't claim ARAT support on processor families below 0x12 and will go back to broadcasting timer when going idle. Signed-off-by: Boris Ostrovsky Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1306423192-19774-1-git-send-email-ostr@amd64.org Tested-by: Boris Petkov Cc: Hans Rosenfeld Cc: Andreas Herrmann Cc: Chuck Ebbert Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 7d5fdc4f5641f5e3046a4f4c614157b08e6ce53c Author: Samuel Thibault Date: Wed May 18 17:06:05 2011 +0200 Fix Ultrastor asm snippet commit fad4dab5e44e10acf6b0235e469cb8e773b58e31 upstream. Commit 1292500b replaced "=m" (*field) : "1" (*field) with "=m" (*field) : with comment "The following patch fixes it by using the '+' operator on the (*field) operand, marking it as read-write to gcc." '+' was actually forgotten. This really puts it. Signed-off-by: Samuel Thibault Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 6d6bb6e9897f3c4443da0498e8d4622de85a26f2 Author: Yang Ruirui Date: Sat Apr 16 19:17:48 2011 -0400 ext4: release page cache in ext4_mb_load_buddy error path commit 26626f1172fb4f3f323239a6a5cf4e082643fa46 upstream. Add missing page_cache_release in the error path of ext4_mb_load_buddy Signed-off-by: Yang Ruirui Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit a33dc63a996b979dcdf1574752f67d1844aad91b Author: Ted Ts'o Date: Sat Apr 30 13:17:11 2011 -0400 jbd: fix fsync() tid wraparound bug commit d9b01934d56a96d9f4ae2d6204d4ea78a36f5f36 upstream. If an application program does not make any changes to the indirect blocks or extent tree, i_datasync_tid will not get updated. If there are enough commits (i.e., 2**31) such that tid_geq()'s calculations wrap, and there isn't a currently active transaction at the time of the fdatasync() call, this can end up triggering a BUG_ON in fs/jbd/commit.c: J_ASSERT(journal->j_running_transaction != NULL); It's pretty rare that this can happen, since it requires the use of fdatasync() plus *very* frequent and excessive use of fsync(). But with the right workload, it can. We fix this by replacing the use of tid_geq() with an equality test, since there's only one valid transaction id that is valid for us to start: namely, the currently running transaction (if it exists). Reported-by: Martin_Zielinski@McAfee.com Signed-off-by: "Theodore Ts'o" Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 9907f140638ef8492c3ecd35db8d2f6b28f5c781 Author: Jan Kara Date: Thu May 5 13:59:35 2011 +0200 jbd: Fix forever sleeping process in do_get_write_access() commit 2842bb20eed2e25cde5114298edc62c8883a1d9a upstream. In do_get_write_access() we wait on BH_Unshadow bit for buffer to get from shadow state. The waking code in journal_commit_transaction() has a bug because it does not issue a memory barrier after the buffer is moved from the shadow state and before wake_up_bit() is called. Thus a waitqueue check can happen before the buffer is actually moved from the shadow state and waiting process may never be woken. Fix the problem by issuing proper barrier. Reported-by: Tao Ma Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 94f69b03006a2119db2e7f1f6db453fe58e530b8 Author: Jan Kara Date: Wed Apr 27 18:20:44 2011 +0200 ext3: Fix fs corruption when make_indexed_dir() fails commit 86c4f6d85595cd7da635dc6985d27bfa43b1ae10 upstream. When make_indexed_dir() fails (e.g. because of ENOSPC) after it has allocated block for index tree root, we did not properly mark all changed buffers dirty. This lead to only some of these buffers being written out and thus effectively corrupting the directory. Fix the issue by marking all changed data dirty even in the error failure case. Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit b6403b5b5e39a36afb98dba3901844f34586b391 Author: Jiri Olsa Date: Thu May 12 16:30:30 2011 +0200 x86, 64-bit: Fix copy_[to/from]_user() checks for the userspace address limit commit 26afb7c661080ae3f1f13ddf7f0c58c4f931c22b upstream. As reported in BZ #30352: https://bugzilla.kernel.org/show_bug.cgi?id=30352 there's a kernel bug related to reading the last allowed page on x86_64. The _copy_to_user() and _copy_from_user() functions use the following check for address limit: if (buf + size >= limit) fail(); while it should be more permissive: if (buf + size > limit) fail(); That's because the size represents the number of bytes being read/write from/to buf address AND including the buf address. So the copy function will actually never touch the limit address even if "buf + size == limit". Following program fails to use the last page as buffer due to the wrong limit check: #include #include #include #define PAGE_SIZE (4096) #define LAST_PAGE ((void*)(0x7fffffffe000)) int main() { int fds[2], err; void * ptr = mmap(LAST_PAGE, PAGE_SIZE, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE | MAP_FIXED, -1, 0); assert(ptr == LAST_PAGE); err = socketpair(AF_LOCAL, SOCK_STREAM, 0, fds); assert(err == 0); err = send(fds[0], ptr, PAGE_SIZE, 0); perror("send"); assert(err == PAGE_SIZE); err = recv(fds[1], ptr, PAGE_SIZE, MSG_WAITALL); perror("recv"); assert(err == PAGE_SIZE); return 0; } The other place checking the addr limit is the access_ok() function, which is working properly. There's just a misleading comment for the __range_not_ok() macro - which this patch fixes as well. The last page of the user-space address range is a guard page and Brian Gerst observed that the guard page itself due to an erratum on K8 cpus (#121 Sequential Execution Across Non-Canonical Boundary Causes Processor Hang). However, the test code is using the last valid page before the guard page. The bug is that the last byte before the guard page can't be read because of the off-by-one error. The guard page is left in place. This bug would normally not show up because the last page is part of the process stack and never accessed via syscalls. Signed-off-by: Jiri Olsa Acked-by: Brian Gerst Acked-by: Linus Torvalds Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1305210630-7136-1-git-send-email-jolsa@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 4613fee87c204e79ebd9c1c269c53ee3c9204451 Author: Felix Radensky Date: Mon Apr 25 01:57:12 2011 +0300 mtd: mtdconcat: fix NAND OOB write commit 431e1ecabddcd7cbba237182ddf431771f98bb4c upstream. Currently mtdconcat is broken for NAND. An attemtpt to create JFFS2 filesystem on concatenation of several NAND devices fails with OOB write errors. This patch fixes that problem. Signed-off-by: Felix Radensky Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 0871ccb857a76c76be1e4c8b3d1dfdd7f3e91fe7 Author: James Bottomley Date: Wed May 18 16:20:10 2011 +0200 block: add proper state guards to __elv_next_request commit 0a58e077eb600d1efd7e54ad9926a75a39d7f8ae upstream. blk_cleanup_queue() calls elevator_exit() and after this, we can't touch the elevator without oopsing. __elv_next_request() must check for this state because in the refcounted queue model, we can still call it after blk_cleanup_queue() has been called. This was reported as causing an oops attributable to scsi. Signed-off-by: James Bottomley Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 4ede8259d84a843e2adc0ce69523015608a5f271 Author: Eric B Munson Date: Mon May 23 04:22:40 2011 +0000 powerpc/oprofile: Handle events that raise an exception without overflowing commit ad5d5292f16c6c1d7d3e257c4c7407594286b97e upstream. Commit 0837e3242c73566fc1c0196b4ec61779c25ffc93 fixes a situation on POWER7 where events can roll back if a specualtive event doesn't actually complete. This can raise a performance monitor exception. We need to catch this to ensure that we reset the PMC. In all cases the PMC will be less than 256 cycles from overflow. This patch lifts Anton's fix for the problem in perf and applies it to oprofile as well. Signed-off-by: Eric B Munson Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 9c9f2de51e46be3011a100b4b401a6f17d220776 Author: Milton Miller Date: Tue May 10 19:28:33 2011 +0000 powerpc/kexec: Fix memory corruption from unallocated slaves commit 3d2cea732d68aa270c360f55d8669820ebce188a upstream. Commit 1fc711f7ffb01089efc58042cfdbac8573d1b59a (powerpc/kexec: Fix race in kexec shutdown) moved the write to signal the cpu had exited the kernel from before the transition to real mode in kexec_smp_wait to kexec_wait. Unfornately it missed that kexec_wait is used both by cpus leaving the kernel and by secondary slave cpus that were not allocated a paca for what ever reason -- they could be beyond nr_cpus or not described in the current device tree for whatever reason (for example, kexec-load was not refreshed after a cpu hotplug operation). Cpus coming through that path they will write to paca[NR_CPUS] which is beyond the space allocated for the paca data and overwrite memory not allocated to pacas but very likely still real mode accessable). Move the write back to kexec_smp_wait, which is used only by cpus that found their paca, but after the transition to real mode. Signed-off-by: Milton Miller Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit c4e60bd6930b93a13432f53dfb70e65d8fef58d2 Author: steven finney Date: Mon May 2 11:29:17 2011 -0700 Fix memory leak in cpufreq_stat commit 98586ed8b8878e10691203687e89a42fa3355300 upstream. When a CPU is taken offline in an SMP system, cpufreq_remove_dev() nulls out the per-cpu policy before cpufreq_stats_free_table() can make use of it. cpufreq_stats_free_table() then skips the call to sysfs_remove_group(), leaving about 100 bytes of sysfs-related memory unclaimed each time a CPU-removal occurs. Break up cpu_stats_free_table into sysfs and table portions, and call the sysfs portion early. Signed-off-by: Steven Finney Signed-off-by: Dave Jones Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit f8c02e3305bdf8656219da21fde9f0b8b31c0508 Author: Jacob Shin Date: Wed Apr 27 13:32:11 2011 -0500 CPU hotplug, re-create sysfs directory and symlinks commit 27ecddc2a9f99ce4ac9a59a0acd77f7100b6d034 upstream. When we discover CPUs that are affected by each other's frequency/voltage transitions, the first CPU gets a sysfs directory created, and rest of the siblings get symlinks. Currently, when we hotplug off only the first CPU, all of the symlinks and the sysfs directory gets removed. Even though rest of the siblings are still online and functional, they are orphaned, and no longer governed by cpufreq. This patch, given the above scenario, creates a sysfs directory for the first sibling and symlinks for the rest of the siblings. Please note the recursive call, it was rather too ugly to roll it out. And the removal of redundant NULL setting (it is already taken care of near the top of the function). Signed-off-by: Jacob Shin Acked-by: Mark Langsdorf Reviewed-by: Thomas Renninger Signed-off-by: Dave Jones Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 465e9df58b3007510231e030db6f622f4a46a6ac Author: Catalin Marinas Date: Wed Apr 27 16:44:26 2011 +0100 kmemleak: Do not return a pointer to an object that kmemleak did not get commit 52c3ce4ec5601ee383a14f1485f6bac7b278896e upstream. The kmemleak_seq_next() function tries to get an object (and increment its use count) before returning it. If it could not get the last object during list traversal (because it may have been freed), the function should return NULL rather than a pointer to such object that it did not get. Signed-off-by: Catalin Marinas Reported-by: Phil Carmody Acked-by: Phil Carmody Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 6ea4870f102c97460c57cc9ae32d8e17a277baef Author: Steven Rostedt Date: Fri Apr 29 22:35:33 2011 -0400 ftrace: Only update the function code on write to filter files commit 058e297d34a404caaa5ed277de15698d8dc43000 upstream. If function tracing is enabled, a read of the filter files will cause the call to stop_machine to update the function trace sites. It should only call stop_machine on write. Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 297cd2138dad33c4bec7902e833a637351232422 Author: Ben Hutchings Date: Tue May 17 01:48:14 2011 +0100 netxen: Remove references to unified firmware file Commit c23a103f0d9c2560c6839ed366feebec4cd5e556 wrongly introduced references to the unified firmware file "phanfw.bin", which is not supported by netxen in 2.6.32. The driver reports this filename when loading firmware from flash, and includes a MODULE_FIRMWARE hint for the filename even though it will never use it. Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 728b8bcaf8c31db1af214c999b38672b4144cf96 Author: Thomas Jarosch Date: Mon May 16 06:28:15 2011 +0000 vmxnet3: Fix inconsistent LRO state after initialization commit ebde6f8acba92abfc203585198a54f47e83e2cd0 upstream. During initialization of vmxnet3, the state of LRO gets out of sync with netdev->features. This leads to very poor TCP performance in a IP forwarding setup and is hitting many VMware users. Simplified call sequence: 1. vmxnet3_declare_features() initializes "adapter->lro" to true. 2. The kernel automatically disables LRO if IP forwarding is enabled, so vmxnet3_set_flags() gets called. This also updates netdev->features. 3. Now vmxnet3_setup_driver_shared() is called. "adapter->lro" is still set to true and LRO gets enabled again, even though netdev->features shows it's disabled. Fix it by updating "adapter->lro", too. The private vmxnet3 adapter flags are scheduled for removal in net-next, see commit a0d2730c9571aeba793cb5d3009094ee1d8fda35 "net: vmxnet3: convert to hw_features". Patch applies to 2.6.37 / 2.6.38 and 2.6.39-rc6. Please CC: comments. Signed-off-by: Thomas Jarosch Acked-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 6451865d838216814412405879b6906271b50199 Author: Bjørn Mork Date: Wed Jan 19 10:01:14 2011 +0100 megaraid_sas: Sanity check user supplied length before passing it to dma_alloc_coherent() commit 98cb7e4413d189cd2b54daf993a4667d9788c0bb upstream. The ioc->sgl[i].iov_len value is supplied by the ioctl caller, and can be zero in some cases. Assume that's valid and continue without error. Fixes (multiple individual reports of the same problem for quite a while): http://marc.info/?l=linux-ide&m=128941801715301 http://bugs.debian.org/604627 http://www.mail-archive.com/linux-poweredge@dell.com/msg02575.html megasas: Failed to alloc kernel SGL buffer for IOCTL and [ 69.162538] ------------[ cut here ]------------ [ 69.162806] kernel BUG at /build/buildd/linux-2.6.32/lib/swiotlb.c:368! [ 69.163134] invalid opcode: 0000 [#1] SMP [ 69.163570] last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map [ 69.163975] CPU 0 [ 69.164227] Modules linked in: fbcon tileblit font bitblit softcursor vga16fb vgastate ioatdma radeon ttm drm_kms_helper shpchp drm i2c_algo_bit lp parport floppy pata_jmicron megaraid_sas igb dca [ 69.167419] Pid: 1206, comm: smartctl Tainted: G W 2.6.32-25-server #45-Ubuntu X8DTN [ 69.167843] RIP: 0010:[] [] map_single+0x255/0x260 [ 69.168370] RSP: 0018:ffff88081c0ebc58 EFLAGS: 00010246 [ 69.168655] RAX: 000000000003bffc RBX: 00000000ffffffff RCX: 0000000000000002 [ 69.169000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88001dffe000 [ 69.169346] RBP: ffff88081c0ebcb8 R08: 0000000000000000 R09: ffff880000030840 [ 69.169691] R10: 0000000000100000 R11: 0000000000000000 R12: 0000000000000000 [ 69.170036] R13: 00000000ffffffff R14: 0000000000000001 R15: 0000000000200000 [ 69.170382] FS: 00007fb8de189720(0000) GS:ffff88001de00000(0000) knlGS:0000000000000000 [ 69.170794] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 69.171094] CR2: 00007fb8dd59237c CR3: 000000081a790000 CR4: 00000000000006f0 [ 69.171439] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 69.171784] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 69.172130] Process smartctl (pid: 1206, threadinfo ffff88081c0ea000, task ffff88081a760000) [ 69.194513] Stack: [ 69.205788] 0000000000000034 00000002817e3390 0000000000000000 ffff88081c0ebe00 [ 69.217739] <0> 0000000000000000 000000000003bffc 0000000000000000 0000000000000000 [ 69.241250] <0> 0000000000000000 00000000ffffffff ffff88081c5b4080 ffff88081c0ebe00 [ 69.277310] Call Trace: [ 69.289278] [] swiotlb_alloc_coherent+0xec/0x130 [ 69.301118] [] x86_swiotlb_alloc_coherent+0x61/0x70 [ 69.313045] [] megasas_mgmt_fw_ioctl+0x1ae/0x690 [megaraid_sas] [ 69.336399] [] megasas_mgmt_ioctl_fw+0x198/0x240 [megaraid_sas] [ 69.359346] [] megasas_mgmt_ioctl+0x35/0x50 [megaraid_sas] [ 69.370902] [] vfs_ioctl+0x22/0xa0 [ 69.382322] [] ? alloc_fd+0x10a/0x150 [ 69.393622] [] do_vfs_ioctl+0x81/0x410 [ 69.404696] [] ? do_page_fault+0x153/0x3b0 [ 69.415761] [] sys_ioctl+0x81/0xa0 [ 69.426640] [] system_call_fastpath+0x16/0x1b [ 69.437491] Code: fe ff ff 48 8b 3d 74 38 76 00 41 bf 00 00 20 00 e8 51 f5 d7 ff 83 e0 ff 48 05 ff 07 00 00 48 c1 e8 0b 48 89 45 c8 e9 13 fe ff ff <0f> 0b eb fe 0f 1f 80 00 00 00 00 55 48 89 e5 48 83 ec 20 4c 89 [ 69.478216] RIP [] map_single+0x255/0x260 [ 69.489668] RSP [ 69.500975] ---[ end trace 6a2181b634e2abc7 ]--- Reported-by: Bokhan Artem Signed-off-by: Andi Kleen Reported by: Marc-Christian Petersen Signed-off-by: Bjørn Mork Cc: Michael Benz Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 1528a22557dde6a0d5aaf7a174a09c45fc3f968f Author: Julia Lawall Date: Fri May 13 15:52:09 2011 +0200 x86, mce, AMD: Fix leaving freed data in a list commit d9a5ac9ef306eb5cc874f285185a15c303c50009 upstream. b may be added to a list, but is not removed before being freed in the case of an error. This is done in the corresponding deallocation function, so the code here has been changed to follow that. The sematic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression E,E1,E2; identifier l; @@ *list_add(&E->l,E1); ... when != E1 when != list_del(&E->l) when != list_del_init(&E->l) when != E = E2 *kfree(E);// Signed-off-by: Julia Lawall Cc: Borislav Petkov Cc: Robert Richter Cc: Yinghai Lu Cc: Andreas Herrmann Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1305294731-12127-1-git-send-email-julia@diku.dk Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 532c8c080814b714c2becae8f877b28c0fcf06f6 Author: Youquan Song Date: Fri Apr 22 00:22:43 2011 +0800 x86, apic: Fix spurious error interrupts triggering on all non-boot APs commit e503f9e4b092e2349a9477a333543de8f3c7f5d9 upstream. This patch fixes a bug reported by a customer, who found that many unreasonable error interrupts reported on all non-boot CPUs (APs) during the system boot stage. According to Chapter 10 of Intel Software Developer Manual Volume 3A, Local APIC may signal an illegal vector error when an LVT entry is set as an illegal vector value (0~15) under FIXED delivery mode (bits 8-11 is 0), regardless of whether the mask bit is set or an interrupt actually happen. These errors are seen as error interrupts. The initial value of thermal LVT entries on all APs always reads 0x10000 because APs are woken up by BSP issuing INIT-SIPI-SIPI sequence to them and LVT registers are reset to 0s except for the mask bits which are set to 1s when APs receive INIT IPI. When the BIOS takes over the thermal throttling interrupt, the LVT thermal deliver mode should be SMI and it is required from the kernel to keep AP's LVT thermal monitoring register programmed as such as well. This issue happens when BIOS does not take over thermal throttling interrupt, AP's LVT thermal monitor register will be restored to 0x10000 which means vector 0 and fixed deliver mode, so all APs will signal illegal vector error interrupts. This patch check if interrupt delivery mode is not fixed mode before restoring AP's LVT thermal monitor register. Signed-off-by: Youquan Song Acked-by: Suresh Siddha Acked-by: Yong Wang Cc: hpa@linux.intel.com Cc: joe@perches.com Cc: jbaron@redhat.com Cc: trenn@suse.de Cc: kent.liu@intel.com Cc: chaohong.guo@intel.com Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1303402963-17738-1-git-send-email-youquan.song@intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 3b4e9894a65820b8b3588199a54dfde64e705bfb Author: Thomas Gleixner Date: Mon May 16 11:07:48 2011 +0200 tick: Clear broadcast active bit when switching to oneshot commit 07f4beb0b5bbfaf36a64aa00d59e670ec578a95a upstream. The first cpu which switches from periodic to oneshot mode switches also the broadcast device into oneshot mode. The broadcast device serves as a backup for per cpu timers which stop in deeper C-states. To avoid starvation of the cpus which might be in idle and depend on broadcast mode it marks the other cpus as broadcast active and sets the brodcast expiry value of those cpus to the next tick. The oneshot mode broadcast bit for the other cpus is sticky and gets only cleared when those cpus exit idle. If a cpu was not idle while the bit got set in consequence the bit prevents that the broadcast device is armed on behalf of that cpu when it enters idle for the first time after it switched to oneshot mode. In most cases that goes unnoticed as one of the other cpus has usually a timer pending which keeps the broadcast device armed with a short timeout. Now if the only cpu which has a short timer active has the bit set then the broadcast device will not be armed on behalf of that cpu and will fire way after the expected timer expiry. In the case of Christians bug report it took ~145 seconds which is about half of the wrap around time of HPET (the limit for that device) due to the fact that all other cpus had no timers armed which expired before the 145 seconds timeframe. The solution is simply to clear the broadcast active bit unconditionally when a cpu switches to oneshot mode after the first cpu switched the broadcast device over. It's not idle at that point otherwise it would not be executing that code. [ I fundamentally hate that broadcast crap. Why the heck thought some folks that when going into deep idle it's a brilliant concept to switch off the last device which brings the cpu back from that state? ] Thanks to Christian for providing all the valuable debug information! Reported-and-tested-by: Christian Hoffmann Cc: John Stultz Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/%3Calpine.LFD.2.02.1105161105170.3078%40ionos%3E Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 5284561b0290f09e1c6c99a18b4bc6f39b5ca4d1 Author: john stultz Date: Wed May 4 18:16:50 2011 -0700 clocksource: Install completely before selecting commit e05b2efb82596905ebfe88e8612ee81dec9b6592 upstream. Christian Hoffmann reported that the command line clocksource override with acpi_pm timer fails: Kernel command line: clocksource=acpi_pm hpet clockevent registered Switching to clocksource hpet Override clocksource acpi_pm is not HRT compatible. Cannot switch while in HRT/NOHZ mode. The watchdog code is what enables CLOCK_SOURCE_VALID_FOR_HRES, but we actually end up selecting the clocksource before we enqueue it into the watchdog list, so that's why we see the warning and fail to switch to acpi_pm timer as requested. That's particularly bad when we want to debug timekeeping related problems in early boot. Put the selection call last. Reported-by: Christian Hoffmann Signed-off-by: John Stultz Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/%3C1304558210.2943.24.camel%40work-vm%3E Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit b9c582a117a0d590b7a174760b662d25761692d4 Author: Borislav Petkov Date: Tue May 17 14:55:19 2011 +0200 x86, AMD: Fix ARAT feature setting again commit 14fb57dccb6e1defe9f89a66f548fcb24c374c1d upstream. Trying to enable the local APIC timer on early K8 revisions uncovers a number of other issues with it, in conjunction with the C1E enter path on AMD. Fixing those causes much more churn and troubles than the benefit of using that timer brings so don't enable it on K8 at all, falling back to the original functionality the kernel had wrt to that. Reported-and-bisected-by: Nick Bowler Cc: Boris Ostrovsky Cc: Andreas Herrmann Cc: Greg Kroah-Hartman Cc: Hans Rosenfeld Cc: Nick Bowler Cc: Joerg-Volker-Peetz Signed-off-by: Borislav Petkov Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1305636919-31165-3-git-send-email-bp@amd64.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e68fd06bd319088e3fbeb40be74cdd444242cfd6 Author: Jeff Layton Date: Tue May 17 06:40:30 2011 -0400 cifs: add fallback in is_path_accessible for old servers commit 221d1d797202984cb874e3ed9f1388593d34ee22 upstream. The is_path_accessible check uses a QPathInfo call, which isn't supported by ancient win9x era servers. Fall back to an older SMBQueryInfo call if it fails with the magic error codes. Reported-and-Tested-by: Sandro Bonazzola Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 2dcdb613c69f16e6c22b05010a92c104b8a8deee Author: Geert Uytterhoeven Date: Thu May 12 09:11:38 2011 +0000 zorro8390: Fix regression caused during net_device_ops conversion commit cf7e032fc87d59c475df26c4d40bf45d401b2adb upstream. Changeset b6114794a1c394534659f4a17420e48cf23aa922 ("zorro8390: convert to net_device_ops") broke zorro8390 by adding 8390.o to the link. That meant that lib8390.c was included twice, once in zorro8390.c and once in 8390.c, subject to different macros. This patch reverts that by avoiding the wrappers in 8390.c. Fix based on commits 217cbfa856dc1cbc2890781626c4032d9e3ec59f ("mac8390: fix regression caused during net_device_ops conversion") and 4e0168fa4842e27795a75b205a510f25b62181d9 ("mac8390: fix build with NET_POLL_CONTROLLER"). Reported-by: Christian T. Steigies Suggested-by: Finn Thain Signed-off-by: Geert Uytterhoeven Tested-by: Christian T. Steigies Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 57ad6fccb924ec7fdb6aa88aa41ebc76da76fa74 Author: Paul Fox Date: Mon May 9 10:40:42 2011 +0100 libertas: fix cmdpendingq locking commit 2ae1b8b35faba31a59b153cbad07f9c15de99740 upstream. We occasionally see list corruption using libertas. While we haven't been able to diagnose this precisely, we have spotted a possible cause: cmdpendingq is generally modified with driver_lock held. However, there are a couple of points where this is not the case. Fix up those operations to execute under the lock, it seems like the correct thing to do and will hopefully improve the situation. Signed-off-by: Paul Fox Signed-off-by: Daniel Drake Acked-by: Dan Williams Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 02b5e373b2f4a28762cb6ff908b9b726bb17c844 Author: Geert Uytterhoeven Date: Thu May 12 09:11:39 2011 +0000 hydra: Fix regression caused during net_device_ops conversion commit 0b25e0157dfa236a0629c16c8ad6f222f633f682 upstream. Changeset 5618f0d1193d6b051da9b59b0e32ad24397f06a4 ("hydra: convert to net_device_ops") broke hydra by adding 8390.o to the link. That meant that lib8390.c was included twice, once in hydra.c and once in 8390.c, subject to different macros. This patch reverts that by avoiding the wrappers in 8390.c. Fix based on commits 217cbfa856dc1cbc2890781626c4032d9e3ec59f ("mac8390: fix regression caused during net_device_ops conversion") and 4e0168fa4842e27795a75b205a510f25b62181d9 ("mac8390: fix build with NET_POLL_CONTROLLER"). Signed-off-by: Geert Uytterhoeven Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit f6f5ac3edfdc5b1f5595d0216b1ac6cc5448024c Author: Geert Uytterhoeven Date: Thu May 12 09:11:40 2011 +0000 ne-h8300: Fix regression caused during net_device_ops conversion commit 2592a7354092afd304a8c067319b15ab1e441e35 upstream. Changeset dcd39c90290297f6e6ed8a04bb20da7ac2b043c5 ("ne-h8300: convert to net_device_ops") broke ne-h8300 by adding 8390.o to the link. That meant that lib8390.c was included twice, once in ne-h8300.c and once in 8390.c, subject to different macros. This patch reverts that by avoiding the wrappers in 8390.c. Fix based on commits 217cbfa856dc1cbc2890781626c4032d9e3ec59f ("mac8390: fix regression caused during net_device_ops conversion") and 4e0168fa4842e27795a75b205a510f25b62181d9 ("mac8390: fix build with NET_POLL_CONTROLLER"). Signed-off-by: Geert Uytterhoeven Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 8eca68a77b9403beca2abebee81737c3fe423407 Author: Matvejchikov Ilya Date: Fri May 6 06:23:09 2011 +0000 NET: slip, fix ldisc->open retval commit 057bef938896e6266ae24ec4266d24792d27c29a upstream. TTY layer expects 0 if the ldisc->open operation succeeded. Signed-off-by : Matvejchikov Ilya Acked-by: Oliver Hartkopp Acked-by: Alan Cox Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 63fa187cc0f6c581f69ee056e8b2b043d6f84ce5 Author: Kleber Sacilotto de Souza Date: Wed May 4 13:05:11 2011 +0000 ehea: fix wrongly reported speed and port commit dcbe14b91a920657ff3a9ba0efb7c5b5562f956a upstream. Currently EHEA reports to ethtool as supporting 10M, 100M, 1G and 10G and connected to FIBRE independent of the hardware configuration. However, when connected to FIBRE the only supported speed is 10G full-duplex, and the other speeds and modes are only supported when connected to twisted pair. Signed-off-by: Kleber Sacilotto de Souza Acked-by: Breno Leitao Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit f3b60ef4bcc7b233a816df5fded90e1ba99d47d6 Author: Pavel Shilovsky Date: Thu Apr 14 22:00:56 2011 +0400 CIFS: Fix memory over bound bug in cifs_parse_mount_options commit 4906e50b37e6f6c264e7ee4237343eb2b7f8d16d upstream. While password processing we can get out of options array bound if the next character after array is delimiter. The patch adds a check if we reach the end. Signed-off-by: Pavel Shilovsky Reviewed-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 92f9dab23e4e424f28c6aca43cd2611b0b301965 Author: Dan Rosenberg Date: Fri May 6 03:27:18 2011 +0000 dccp: handle invalid feature options length commit a294865978b701e4d0d90135672749531b9a900d upstream. A length of zero (after subtracting two for the type and len fields) for the DCCPO_{CHANGE,CONFIRM}_{L,R} options will cause an underflow due to the subtraction. The subsequent code may read past the end of the options value buffer when parsing. I'm unsure of what the consequences of this might be, but it's probably not good. Signed-off-by: Dan Rosenberg Acked-by: Gerrit Renker Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 9f5a8a5d1018c56e5d74db644d739e1be72e6f88 Author: Timo Warns Date: Fri May 6 13:47:35 2011 +0200 Validate size of EFI GUID partition entries. commit fa039d5f6b126fbd65eefa05db2f67e44df8f121 upstream. Otherwise corrupted EFI partition tables can cause total confusion. Signed-off-by: Timo Warns Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 43a36aea9fdbae025023cc500a74d498f380ec87 Author: Jeff Layton Date: Wed Apr 27 13:25:51 2011 -0400 cifs: check for bytes_remaining going to zero in CIFS_SessSetup commit fcda7f4578bbf9717444ca6da8a421d21489d078 upstream. It's possible that when we go to decode the string area in the SESSION_SETUP response, that bytes_remaining will be 0. Decrementing it at that point will mean that it can go "negative" and wrap. Check for a bytes_remaining value of 0, and don't try to decode the string area if that's the case. Reported-and-Acked-by: David Howells Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 9f6340c7bfc445ec0c8c620d79a4cea4a8fe654d Author: James Bottomley Date: Sun May 1 09:42:07 2011 -0500 fix oops in scsi_run_queue() commit c055f5b2614b4f758ae6cc86733f31fa4c2c5844 upstream. The recent commit closing the race window in device teardown: commit 86cbfb5607d4b81b1a993ff689bbd2addd5d3a9b Author: James Bottomley Date: Fri Apr 22 10:39:59 2011 -0500 [SCSI] put stricter guards on queue dead checks is causing a potential NULL deref in scsi_run_queue() because the q->queuedata may already be NULL by the time this function is called. Since we shouldn't be running a queue that is being torn down, simply add a NULL check in scsi_run_queue() to forestall this. Tested-by: Jim Schutt Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit da4e8b8ed55d397cfca5fa4656e7e71e7ba3d688 Author: Oliver Hartkopp Date: Wed Apr 20 01:57:15 2011 +0000 can: add missing socket check in can/raw release commit 10022a6c66e199d8f61d9044543f38785713cbbd upstream. v2: added space after 'if' according code style. We can get here with a NULL socket argument passed from userspace, so we need to handle it accordingly. Thanks to Dave Jones pointing at this issue in net/can/bcm.c Signed-off-by: Oliver Hartkopp Signed-off-by: David S. Miller Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit c966ef96919386c22f9491272473efbc671b38fb Author: Felipe Balbi Date: Thu Feb 24 10:36:53 2011 +0200 usb: musb: core: set has_tt flag commit ec95d35a6bd0047f05fe8a21e6c52f8bb418da55 upstream. MUSB is a non-standard host implementation which can handle all speeds with the same core. We need to set has_tt flag after commit d199c96d41d80a567493e12b8e96ea056a1350c1 (USB: prevent buggy hubs from crashing the USB stack) in order for MUSB HCD to continue working. Signed-off-by: Felipe Balbi Cc: Alan Stern Tested-by: Michael Jones Tested-by: Alexander Holler Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 2f557bafe399f7e4c70e985eb1a864fabcd74c75 Author: Tejun Heo Date: Thu Jan 20 13:59:06 2011 +0100 libata: set queue DMA alignment to sector size for ATAPI too commit 729a6a300e628a48cf12bac93a964a535e83cd1d upstream. ata_pio_sectors() expects buffer for each sector to be contained in a single page; otherwise, it ends up overrunning the first page. This is achieved by setting queue DMA alignment. If sector_size is smaller than PAGE_SIZE and all buffers are sector_size aligned, buffer for each sector is always contained in a single page. This wasn't applied to ATAPI devices but IDENTIFY_PACKET is executed as ATA_PROT_PIO and thus uses ata_pio_sectors(). Newer versions of udev issue IDENTIFY_PACKET with unaligned buffer triggering the problem and causing oops. This patch fixes the problem by setting sdev->sector_size to ATA_SECT_SIZE on ATATPI devices and always setting DMA alignment to sector_size. While at it, add a warning for the unlikely but still possible scenario where sector_size is larger than PAGE_SIZE, in which case the alignment wouldn't be enough. Signed-off-by: Tejun Heo Reported-by: John Stanley Tested-by: John Stanley Signed-off-by: Jeff Garzik Signed-off-by: Jonathan Liu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 15d611d312597932f012f923a98871e7d1ba576c Author: Ondrej Zary Date: Wed Jun 23 12:57:15 2010 +0200 rt2500usb: fallback to SW encryption for TKIP+AES commit 75f64dd54a185150ebfc45e99351c890d4a2252f upstream. HW crypto in rt2500usb does not seem to support keys with different ciphers, which breaks TKIP+AES mode. Fall back to software encryption to fix it. This should fix long-standing problems with rt2500usb and WPA, such as: http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=4&t=4834 https://bugzilla.redhat.com/show_bug.cgi?id=484888 Also tested that it does not break WEP, TKIP-only and AES-only modes. Signed-off-by: Ondrej Zary Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville Signed-off-by: Andi Kleen [bwh: Adjust context for 2.6.32] Signed-off-by: Greg Kroah-Hartman commit b234a8154e569f4cf63320e3acb5fee737a34b71 Author: Ben Hutchings Date: Sat Jan 8 14:24:01 2011 +0000 powerpc/boot/dts: Install dts from the right directory commit 4d9ef89dee13e964ea8b064d82ff55cf36209237 upstream. The dts-installed variable is initialised using a wildcard path that will be expanded relative to the build directory. Use the existing variable dtstree to generate an absolute wildcard path that will work when building in a separate directory. Reported-by: Gerhard Pircher Signed-off-by: Ben Hutchings Tested-by: Gerhard Pircher [against 2.6.32] Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit d58f50ab3cb89696982deeae32ef9e0eab96f787 Author: Rémi Denis-Courmont Date: Mon Oct 25 10:43:32 2010 +0300 Phonet: device notifier only runs on initial namespace [bwh: This is only applicable to 2.6.32. Phonet was fixed upstream to work with multiple net namespaces.] This should really fix the OOPS when doing: unshare(CLONE_NEWNET); exit(0); while the phonet module is loaded. Signed-off-by: Rémi Denis-Courmont Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 6f40d761f0210858e4adbadd33b55020d291ef76 Author: Ben Hutchings Date: Tue Sep 7 04:35:19 2010 +0000 niu: Fix kernel buffer overflow for ETHTOOL_GRXCLSRLALL commit ee9c5cfad29c8a13199962614b9b16f1c4137ac9 upstream. niu_get_ethtool_tcam_all() assumes that its output buffer is the right size, and warns before returning if it is not. However, the output buffer size is under user control and ETHTOOL_GRXCLSRLALL is an unprivileged ethtool command. Therefore this is at least a local denial-of-service vulnerability. Change it to check before writing each entry and to return an error if the buffer is already full. Compile-tested only. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Andi Kleen [Adjusted to apply to 2.6.32 by dann frazier ] Signed-off-by: Greg Kroah-Hartman commit 04c735c129a5a86c6edd61743b4fb8fc6cbecfa7 Author: Ralf Baechle Date: Thu Sep 2 23:22:23 2010 +0200 MIPS: DMA: Fix computation of DMA flags from device's coherent_dma_mask. commit 3b9c6c11f519718d618f5d7c9508daf78b207f6f upstream. This only matters for ISA devices with a 24-bit DMA limit or for devices with a 32-bit DMA limit on systems with ZONE_DMA32 enabled. The latter currently only affects 32-bit PCI cards on Sibyte-based systems with more than 1GB RAM installed. Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 879ed2486c8465ab8bd7b1bfd6f901e5589dbc16 Author: Romain Francoise Date: Mon Jan 17 07:59:18 2011 +0000 ipv6: Silence privacy extensions initialization commit 2fdc1c8093255f9da877d7b9ce3f46c2098377dc upstream. When a network namespace is created (via CLONE_NEWNET), the loopback interface is automatically added to the new namespace, triggering a printk in ipv6_add_dev() if CONFIG_IPV6_PRIVACY is set. This is problematic for applications which use CLONE_NEWNET as part of a sandbox, like Chromium's suid sandbox or recent versions of vsftpd. On a busy machine, it can lead to thousands of useless "lo: Disabled Privacy Extensions" messages appearing in dmesg. It's easy enough to check the status of privacy extensions via the use_tempaddr sysctl, so just removing the printk seems like the most sensible solution. Signed-off-by: Romain Francoise Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 7b4fd0fff48eb5cd76bcf05e181e5f5187e77722 Author: Edgar (gimli) Hucek Date: Wed Nov 3 10:36:18 2010 -0400 HID: add MacBookAir 3,1 and 3,2 support commit 99b9f758bbc904f22faffcf4d83205f4a5e7bc0c upstream. This patch add support for the MacBookAir3,1 and MacBookAir3,2 to the hid driver. Signed-off-by: Edgar (gimli) Hucek Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit d6864e9351e5031d5d98a47983f8846ade515082 Author: Neil Horman Date: Thu Jan 20 09:02:31 2011 +0000 bonding: Ensure that we unshare skbs prior to calling pskb_may_pull commit b30532515f0a62bfe17207ab00883dd262497006 upstream. Recently reported oops: kernel BUG at net/core/skbuff.c:813! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/virtual/net/bond0/broadcast CPU 8 Modules linked in: sit tunnel4 cpufreq_ondemand acpi_cpufreq freq_table bonding ipv6 dm_mirror dm_region_hash dm_log cdc_ether usbnet mii serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core bnx2 ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase scsi_transport_sas dm_mod [last unloaded: microcode] Modules linked in: sit tunnel4 cpufreq_ondemand acpi_cpufreq freq_table bonding ipv6 dm_mirror dm_region_hash dm_log cdc_ether usbnet mii serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core bnx2 ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase scsi_transport_sas dm_mod [last unloaded: microcode] Pid: 0, comm: swapper Not tainted 2.6.32-71.el6.x86_64 #1 BladeCenter HS22 -[7870AC1]- RIP: 0010:[] [] pskb_expand_head+0x36/0x1e0 RSP: 0018:ffff880028303b70 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff880c6458ec80 RCX: 0000000000000020 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880c6458ec80 RBP: ffff880028303bc0 R08: ffffffff818a6180 R09: ffff880c6458ed64 R10: ffff880c622b36c0 R11: 0000000000000400 R12: 0000000000000000 R13: 0000000000000180 R14: ffff880c622b3000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880028300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00000038653452a4 CR3: 0000000001001000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 0, threadinfo ffff8806649c2000, task ffff880c64f16ab0) Stack: ffff880028303bc0 ffffffff8104fff9 000000000000001c 0000000100000000 <0> ffff880000047d80 ffff880c6458ec80 000000000000001c ffff880c6223da00 <0> ffff880c622b3000 0000000000000000 ffff880028303c10 ffffffff81407f7a Call Trace: [] ? __wake_up_common+0x59/0x90 [] __pskb_pull_tail+0x2aa/0x360 [] bond_arp_rcv+0x2c0/0x2e0 [bonding] [] ? packet_rcv+0x377/0x440 [] netif_receive_skb+0x2db/0x670 [] napi_skb_finish+0x58/0x70 [] napi_gro_receive+0x39/0x50 [] ixgbe_clean_rx_irq+0x35b/0x900 [ixgbe] [] ixgbe_clean_rxtx_many+0x136/0x240 [ixgbe] [] net_rx_action+0x103/0x210 [] __do_softirq+0xb7/0x1e0 [] ? handle_IRQ_event+0x60/0x170 [] call_softirq+0x1c/0x30 [] do_softirq+0x65/0xa0 [] irq_exit+0x85/0x90 [] do_IRQ+0x75/0xf0 [] ret_from_intr+0x0/0x11 [] ? mwait_idle+0x71/0xd0 [] ? atomic_notifier_call_chain+0x1a/0x20 [] cpu_idle+0xb6/0x110 [] start_secondary+0x1fc/0x23f Resulted from bonding driver registering packet handlers via dev_add_pack and then trying to call pskb_may_pull. If another packet handler (like for AF_PACKET sockets) gets called first, the delivered skb will have a user count > 1, which causes pskb_may_pull to BUG halt when it does its skb_shared check. Fix this by calling skb_share_check prior to the may_pull call sites in the bonding driver to clone the skb when needed. Tested by myself and the reported successfully. Signed-off-by: Neil Horman Signed-off-by: Andi Kleen CC: Andy Gospodarek CC: Jay Vosburgh CC: "David S. Miller" Signed-off-by: Jay Vosburgh Signed-off-by: Andy Gospodarek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b930a41af4954ca009974a46fb7c91a8f974750d Author: Edgar (gimli) Hucek Date: Thu Nov 11 14:05:30 2010 -0800 backlight: MacBookAir3,1(3,2) mbp-nvidia-bl support commit bd760e1e5b34351e0705705e5163cb89c1316d71 upstream. Add support for the MacBookAir3,1 and MacBookAir3,2 to the mbp-nvidia-bl driver. Signed-off-by: Edgar (gimli) Hucek Acked-by: Richard Purdie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit c5e74595507c13d213d716475d9c9fa061cd263c Author: Ben Hutchings Date: Wed Dec 29 14:55:03 2010 +0000 btrfs: Require CAP_SYS_ADMIN for filesystem rebalance commit 6f88a4403def422bd8e276ddf6863d6ac71435d2 upstream. Filesystem rebalancing (BTRFS_IOC_BALANCE) affects the entire filesystem and may run uninterruptibly for a long time. This does not seem to be something that an unprivileged user should be able to do. Reported-by: Aron Xu Signed-off-by: Ben Hutchings Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 445c6e0512acac0280f7c34ee756c51ed5b099cd Author: Rezwanul Kabir Date: Wed Jun 23 12:02:43 2010 -0500 dell-laptop: Add another Dell laptop family to the DMI whitelist commit 410d44c74cf9942e3055d5b7d73953fac8efbacb upstream. This is to support Precision M4500 and others. Signed-off-by: Rezwanul Kabir Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit d7f29871274f6898ad4a75af91c329e8889cddfd Author: Edgar (gimli) Hucek Date: Thu Nov 4 08:04:33 2010 +0100 Bluetooth: Add MacBookAir3,1(2) support commit 3e3ede7dda2d77d2cbec608e663b6a6ace501bfc upstream. Adding the new MacBookAir3,1(2) to btusb. Output without the patch and btusb loaded : T: Bus=03 Lev=02 Prnt=03 Port=02 Cnt=01 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=05ac ProdID=821b Rev= 0.34 S: Manufacturer=Apple Inc. S: Product=Bluetooth USB Host Controller C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) 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=(none) 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=(none) 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=(none) 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=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 32 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 32 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 64 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 64 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 64 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 64 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Output with the patch and btusb loaded : T: Bus=03 Lev=02 Prnt=03 Port=02 Cnt=01 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=05ac ProdID=821b Rev= 0.34 S: Manufacturer=Apple Inc. S: Product=Bluetooth USB Host Controller C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) 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= 32 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 32 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= 64 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 64 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= 64 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 64 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Signed-off-by: Edgar (gimli) Hucek Acked-by: Marcel Holtmann Signed-off-by: Gustavo F. Padovan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 2c2f8644ed699331316b5479f570c4b99e813064 Author: Nobuhiro Iwamatsu Date: Fri Aug 20 16:24:07 2010 +0900 Bluetooth: Add support Bluetooth controller of MacbookPro 7,1 commit 3cd01976e702ccaffb907727caff4f8789353599 upstream. Bluetooth controller of MacbookPro 7,1 does not work. Because Device Class of these controllers was set 255 (Vendor Sepecific Class). T: Bus=04 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=05ac ProdID=8213 Rev=01.86 S: Manufacturer=Apple Inc. S: Product=Bluetooth USB Host Controller S: SerialNumber=5C5948C81B99 C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none) Signed-off-by: Nobuhiro Iwamatsu Acked-by: Marcel Holtmann Signed-off-by: Gustavo F. Padovan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit ee272756b11915f4711da8ba0b79f7ae1c127666 Author: Nobuhiro Iwamatsu Date: Fri Aug 20 16:24:06 2010 +0900 Bluetooth: Add support Bluetooth controller of MacbookPro 6,2 commit 9c047157a20521cd525527947b13b950d168d2e6 upstream. Bluetooth controller of MacbookPro 6,2 does not work. Because Device Class of these controllers was set 255 (Vendor Sepecific Class). T: Bus=01 Lev=03 Prnt=03 Port=02 Cnt=03 Dev#= 8 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=05ac ProdID=8218 Rev=00.22 S: Manufacturer=Apple Inc. S: Product=Bluetooth USB Host Controller C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Signed-off-by: Nobuhiro Iwamatsu Acked-by: Marcel Holtmann Signed-off-by: Gustavo F. Padovan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 23046c654496911b478402ae7cd0909f64c3f712 Author: Bruce Rogers Date: Thu Feb 10 11:03:31 2011 -0800 virtio_net: Add schedule check to napi_enable call commit 3e9d08ec0a68f6faf718d5a7e050fe5ca0ba004f upstream. Under harsh testing conditions, including low memory, the guest would stop receiving packets. With this patch applied we no longer see any problems in the driver while performing these tests for extended periods of time. Make sure napi is scheduled subsequent to each napi_enable. Signed-off-by: Bruce Rogers Signed-off-by: Olaf Kirch Signed-off-by: Rusty Russell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen [bwh: Adjust for 2.6.32] Signed-off-by: Greg Kroah-Hartman commit abf99a8ea6970057d8d7ca93ac1629fe55b65162 Author: Edgar (gimli) Hucek Date: Wed Nov 3 08:14:10 2010 +0100 ALSA: hda - MacBookAir3,1(3,2) alsa support commit 87232dd49aeb6b7d1af291edca8bd129a82ef4b5 upstream. This patch add support for the MacBookAir3,1 and MacBookAir3,2 to the alsa sound system. Signed-off-by: Edgar (gimli) Hucek Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit eb918d171083f46813b93c9dd458f98c14189fdf Author: Takashi Iwai Date: Mon Oct 11 14:46:35 2010 +0200 ALSA: hda - Add model=mbp55 entry for MacBookPro 7,1 commit f46119b73425df9d1e05c5d5e909a993d95b0218 upstream. Reference: Novell bnc#645066 https://bugzilla.novell.com/show_bug.cgi?id=645066 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 119954a2394575debafc7c0c4071363fc9076cb5 Author: Vince Weaver Date: Wed Sep 22 17:31:37 2010 -0400 ALSA: hda - MacBookPro 5,3 line-in support commit 4e7d7c6018567fa03f387d06602d4145c75ebbe0 upstream. I've found the following patch is necessary to enable line-in on my MacBookPro 5,3 machine. With the patch applied I've successfully recorded audio from the line-in jack. This is based on the existing 5,5 support. Signed-off-by: Vince Weaver Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 64c2138f28bf463cad14d5772c4fce45557e2319 Author: Ben Hutchings Date: Sun Sep 12 02:41:47 2010 +0100 ALSA: emux: Add trivial compat ioctl handler commit a254dba37c5a372fc8b44ba29509ba052d4e859d upstream. Reported-by: Carmen Cru Signed-off-by: Ben Hutchings Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 16d34d5899c57d0f1a1916cdde3a017d497c57db Author: Edgar Hucek Date: Tue Nov 9 15:15:01 2010 +0000 hwmon: (applesmc) Add MacBookAir3,1(3,2) support commit 132af03233b493101a53010383b5abb5b9ff1e51 upstream. This patch add support for the MacBookAir3,1 and MacBookAir3,2 to the applesmc driver. [rydberg@euromail.se: minor cleanup] Signed-off-by: Edgar Hucek Signed-off-by: Henrik Rydberg Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 6a469c129ce3fd551dfb9a2f99e4a1785add9b8b Author: Linus Torvalds Date: Wed Mar 16 08:04:07 2011 -0700 Increase OSF partition limit from 8 to 18 commit 34d211a2d5df4984a35b18d8ccacbe1d10abb067 upstream. It turns out that while a maximum of 8 partitions may be what people "should" have had, you can actually fit up to 18 entries(*) in a sector. And some people clearly were taking advantage of that, like Michael Cree, who had ten partitions on one of his OSF disks. (*) The OSF partition data starts at byte offset 64 in the first sector, and the array of 16-byte partition entries start at offset 148 in the on-disk partition structure. Reported-by: Michael Cree Cc: stable@kernel.org (v2.6.38) Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 5b1157fecf0ced4dd3c447866c332a6d9f9979ec Author: Timo Warns Date: Mon Mar 14 14:59:33 2011 +0100 Fix corrupted OSF partition table parsing commit 1eafbfeb7bdf59cfe173304c76188f3fd5f1fd05 upstream. The kernel automatically evaluates partition tables of storage devices. The code for evaluating OSF partitions contains a bug that leaks data from kernel heap memory to userspace for certain corrupted OSF partitions. In more detail: for (i = 0 ; i < le16_to_cpu(label->d_npartitions); i++, partition++) { iterates from 0 to d_npartitions - 1, where d_npartitions is read from the partition table without validation and partition is a pointer to an array of at most 8 d_partitions. Add the proper and obvious validation. Signed-off-by: Timo Warns Cc: stable@kernel.org Signed-off-by: Andi Kleen [ Changed the patch trivially to not repeat the whole le16_to_cpu() thing, and to use an explicit constant for the magic value '8' ] Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 36a01162f9a6d45d87ffe118f72ec9bc9853acdf Author: Jovi Zhang Date: Wed Mar 2 23:19:37 2011 +0000 nfs: fix compilation warning commit 43b7c3f051dea504afccc39bcb56d8e26c2e0b77 upstream. this commit fix compilation warning as following: linux-2.6/fs/nfs/nfs4proc.c:3265: warning: comparison of distinct pointer types lacks a cast Signed-off-by: Jovi Zhang Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 96f19d2bbf2bd7405cde6de18378276267015c04 Author: Neil Horman Date: Fri Mar 4 19:26:03 2011 -0500 nfs4: Ensure that ACL pages sent over NFS were not allocated from the slab (v3) commit e9e3d724e2145f5039b423c290ce2b2c3d8f94bc upstream. The "bad_page()" page allocator sanity check was reported recently (call chain as follows): bad_page+0x69/0x91 free_hot_cold_page+0x81/0x144 skb_release_data+0x5f/0x98 __kfree_skb+0x11/0x1a tcp_ack+0x6a3/0x1868 tcp_rcv_established+0x7a6/0x8b9 tcp_v4_do_rcv+0x2a/0x2fa tcp_v4_rcv+0x9a2/0x9f6 do_timer+0x2df/0x52c ip_local_deliver+0x19d/0x263 ip_rcv+0x539/0x57c netif_receive_skb+0x470/0x49f :virtio_net:virtnet_poll+0x46b/0x5c5 net_rx_action+0xac/0x1b3 __do_softirq+0x89/0x133 call_softirq+0x1c/0x28 do_softirq+0x2c/0x7d do_IRQ+0xec/0xf5 default_idle+0x0/0x50 ret_from_intr+0x0/0xa default_idle+0x29/0x50 cpu_idle+0x95/0xb8 start_kernel+0x220/0x225 _sinittext+0x22f/0x236 It occurs because an skb with a fraglist was freed from the tcp retransmit queue when it was acked, but a page on that fraglist had PG_Slab set (indicating it was allocated from the Slab allocator (which means the free path above can't safely free it via put_page. We tracked this back to an nfsv4 setacl operation, in which the nfs code attempted to fill convert the passed in buffer to an array of pages in __nfs4_proc_set_acl, which gets used by the skb->frags list in xs_sendpages. __nfs4_proc_set_acl just converts each page in the buffer to a page struct via virt_to_page, but the vfs allocates the buffer via kmalloc, meaning the PG_slab bit is set. We can't create a buffer with kmalloc and free it later in the tcp ack path with put_page, so we need to either: 1) ensure that when we create the list of pages, no page struct has PG_Slab set or 2) not use a page list to send this data Given that these buffers can be multiple pages and arbitrarily sized, I think (1) is the right way to go. I've written the below patch to allocate a page from the buddy allocator directly and copy the data over to it. This ensures that we have a put_page free-able page for every entry that winds up on an skb frag list, so it can be safely freed when the frame is acked. We do a put page on each entry after the rpc_call_sync call so as to drop our own reference count to the page, leaving only the ref count taken by tcp_sendpages. This way the data will be properly freed when the ack comes in Successfully tested by myself to solve the above oops. Note, as this is the result of a setacl operation that exceeded a page of data, I think this amounts to a local DOS triggerable by an uprivlidged user, so I'm CCing security on this as well. Signed-off-by: Neil Horman Signed-off-by: Andi Kleen CC: Trond Myklebust CC: security@kernel.org CC: Jeff Layton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cfdbc9ddef0d0f3d7b4423af1f243d17643f6c3f Author: Andy Chittenden Date: Tue Aug 10 10:19:53 2010 -0400 SUNRPC: fix NFS client over TCP hangs due to packet loss (Bug 16494) commit 669502ff31d7dba1849aec7ee2450a3c61f57d39 upstream. When reusing a TCP connection, ensure that it's aborted if a previous shutdown attempt has been made on that connection so that the RPC over TCP recovery mechanism succeeds. Signed-off-by: Andy Chittenden Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit d757e9ae3da24bf77e41d76fefcc3e07581f1834 Author: Alan Stern Date: Mon Sep 13 14:43:25 2010 -0400 USB: teach "devices" file about Wireless and SuperSpeed USB commit 834e2312e7a384877a876b0d34dffc3046c96bcb upstream. USB: teach "devices" file about Wireless and SuperSpeed USB The /sys/kernel/debug/usb/devices file doesn't know about Wireless or SuperSpeed USB. This patch (as1416b) teaches it, and updates the Documentation/usb/proc_sub_info.txt file accordingly. Signed-off-by: Alan Stern Signed-off-by: Andi Kleen CC: David Vrabel CC: Sarah Sharp Signed-off-by: Greg Kroah-Hartman [Julien Blache: The original commit also added the correct speed for USB_SPEED_WIRELESS, I removed it as it's not supported in 2.6.32.] Signed-off-by: Greg Kroah-Hartman commit f67e667fdbefbfaad3eb37c2d0a8ca9d74b34300 Author: Ben Hutchings Date: Tue May 25 04:25:57 2010 +0100 Staging: rtl8192su: Fix procfs code for interfaces not named wlan0 commit 41a38d9e632f7c9ec5ad8fc627567d97f4302c4a upstream. The current code creates directories in procfs named after interfaces, but doesn't handle renaming. This can result in name collisions and consequent WARNINGs. It also means that the interface name cannot reliably be used to remove the directory - in fact the current code doesn't even try, and always uses "wlan0"! Since the name of a proc_dir_entry is embedded in it, use that when removing it. Add a netdev notifier to catch interface renaming, and remove and re-add the directory at this point. Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit fcf7b1d0968525a94e174b8fb50f0f81e130efe1 Author: Ben Hutchings Date: Tue May 25 04:20:30 2010 +0100 Staging: rtl8192su: Clean up in case of an error in module initialisation commit 9a3dfa0555130952517b9a9c3918729495aa709a upstream. Currently various resources may be leaked in case of an error. Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 794680366c045e368ecbec6f1729745b4f5b00ad Author: Éric Piel Date: Thu Aug 5 23:51:49 2010 -0700 Input: elantech - discard the first 2 positions on some firmwares commit 7f29f17b57255b6395046805a98bc663ded63fb8 upstream. According to the Dell/Ubuntu driver, what was previously observed as "jumpy cursor" corresponds to the hardware sending incorrect data for the first two reports of a one touch finger. So let's use the same workaround as in the other driver. Also, detect another firmware version with the same behaviour, as in the other driver. Signed-off-by: Éric Piel Signed-off-by: Dmitry Torokhov Signed-off-by: Andi Kleen [bwh: Adjust for 2.6.32] [ak: adjust for 2.6.35] Signed-off-by: Greg Kroah-Hartman commit fa2d122182a496f3e43aaa595ed972341beff80a Author: Timo Warns Date: Thu Apr 14 15:21:56 2011 -0700 fs/partitions/ldm.c: fix oops caused by corrupted partition table commit c340b1d640001c8c9ecff74f68fd90422ae2448a upstream. The kernel automatically evaluates partition tables of storage devices. The code for evaluating LDM partitions (in fs/partitions/ldm.c) contains a bug that causes a kernel oops on certain corrupted LDM partitions. A kernel subsystem seems to crash, because, after the oops, the kernel no longer recognizes newly connected storage devices. The patch validates the value of vblk_size. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Timo Warns Cc: Eugene Teo Cc: Harvey Harrison Cc: Richard Russon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 25b405bacb846370a9af427662594eabfb72803b Author: Dave Jones Date: Tue Apr 19 20:36:59 2011 -0700 can: Add missing socket check in can/bcm release. commit c6914a6f261aca0c9f715f883a353ae7ff51fe83 upstream. We can get here with a NULL socket argument passed from userspace, so we need to handle it accordingly. Signed-off-by: Dave Jones Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 18c76472ce00748c2d53ff46f3a70537b632f304 Author: Sachin Prabhu Date: Wed Apr 20 13:09:35 2011 +0100 Open with O_CREAT flag set fails to open existing files on non writable directories commit 1574dff8996ab1ed92c09012f8038b5566fce313 upstream. An open on a NFS4 share using the O_CREAT flag on an existing file for which we have permissions to open but contained in a directory with no write permissions will fail with EACCES. A tcpdump shows that the client had set the open mode to UNCHECKED which indicates that the file should be created if it doesn't exist and encountering an existing flag is not an error. Since in this case the file exists and can be opened by the user, the NFS server is wrong in attempting to check create permissions on the parent directory. The patch adds a conditional statement to check for create permissions only if the file doesn't exist. Signed-off-by: Sachin S. Prabhu Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 00b450cca3cfa0495203f171e787d5c629cbaeac Author: Dan Rosenberg Date: Fri Apr 29 15:48:07 2011 +0100 ARM: 6891/1: prevent heap corruption in OABI semtimedop commit 0f22072ab50cac7983f9660d33974b45184da4f9 upstream. When CONFIG_OABI_COMPAT is set, the wrapper for semtimedop does not bound the nsops argument. A sufficiently large value will cause an integer overflow in allocation size, followed by copying too much data into the allocated buffer. Fix this by restricting nsops to SEMOPM. Untested. Signed-off-by: Dan Rosenberg Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit d282c26a7de21ea3b4df913be7a89035553ed846 Author: Alan Stern Date: Mon May 2 14:21:44 2011 -0400 USB: fix regression in usbip by setting has_tt flag commit cee6a262550f53a13acfefbc1e3e5ff35c96182c upstream. This patch (as1460) fixes a regression in the usbip driver caused by the new check for Transaction Translators in USB-2 hubs. The root hub registered by vhci_hcd needs to have the has_tt flag set, because it can connect to low- and full-speed devices as well as high-speed devices. Signed-off-by: Alan Stern Signed-off-by: Andi Kleen Reported-and-tested-by: Nikola Ciprich Signed-off-by: Greg Kroah-Hartman commit 882041535c8d3244c46bcca0f2109ac514e74dd5 Author: Chris Ball Date: Wed Apr 27 17:35:31 2011 -0400 mmc: sdhci: Check mrq != NULL in sdhci_tasklet_finish commit 0c9c99a765321104cc5f9c97f949382a9ba4927e upstream. It seems that under certain circumstances the sdhci_tasklet_finish() call can be entered with mrq set to NULL, causing the system to crash with a NULL pointer de-reference. Seen on S3C6410 system. Based on a patch by Dimitris Papastamos. Reported-by: Dimitris Papastamos Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 5c8e95fea6c5c922ecdfde9d41f460dcc2e797e4 Author: Ben Dooks Date: Wed Apr 27 14:24:19 2011 +0100 mmc: sdhci: Check mrq->cmd in sdhci_tasklet_finish commit b7b4d3426d2b5ecab21578eb20d8e456a1aace8f upstream. It seems that under certain circumstances that the sdhci_tasklet_finish() call can be entered with mrq->cmd set to NULL, causing the system to crash with a NULL pointer de-reference. Unable to handle kernel NULL pointer dereference at virtual address 00000000 PC is at sdhci_tasklet_finish+0x34/0xe8 LR is at sdhci_tasklet_finish+0x24/0xe8 Seen on S3C6410 system. Signed-off-by: Ben Dooks Signed-off-by: Mark Brown Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 725296955c01285787cdfbaf813298626c9c09ee Author: Chris Ball Date: Tue Mar 29 00:46:12 2011 -0400 mmc: sdhci-pci: Fix error case in sdhci_pci_probe_slot() commit 9fdcdbb0d84922e7ccda2f717a04ea62629f7e18 upstream. If pci_ioremap_bar() fails during probe, we "goto release;" and free the host, but then we return 0 -- which tells sdhci_pci_probe() that the probe succeeded. Since we think the probe succeeded, when we unload sdhci we'll go to sdhci_pci_remove_slot() and it will try to dereference slot->host, which is now NULL because we freed it in the error path earlier. The patch simply sets ret appropriately, so that sdhci_pci_probe() will detect the failure immediately and bail out. Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 4f1ca069a7660ba29ca9bcc126539982a804b38f Author: James Bottomley Date: Fri Apr 22 10:39:59 2011 -0500 put stricter guards on queue dead checks commit 86cbfb5607d4b81b1a993ff689bbd2addd5d3a9b upstream. SCSI uses request_queue->queuedata == NULL as a signal that the queue is dying. We set this state in the sdev release function. However, this allows a small window where we release the last reference but haven't quite got to this stage yet and so something will try to take a reference in scsi_request_fn and oops. It's very rare, but we had a report here, so we're pushing this as a bug fix The actual fix is to set request_queue->queuedata to NULL in scsi_remove_device() before we drop the reference. This causes correct automatic rejects from scsi_request_fn as people who hold additional references try to submit work and prevents anything from getting a new reference to the sdev that way. Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 7d9cdcaaa0cc1e45614863d097b727519c723d81 Author: Dan Rosenberg Date: Tue Apr 5 13:27:31 2011 -0400 pmcraid: reject negative request size commit 5f6279da3760ce48f478f2856aacebe0c59a39f3 upstream. There's a code path in pmcraid that can be reached via device ioctl that causes all sorts of ugliness, including heap corruption or triggering the OOM killer due to consecutive allocation of large numbers of pages. Not especially relevant from a security perspective, since users must have CAP_SYS_ADMIN to open the character device. First, the user can call pmcraid_chr_ioctl() with a type PMCRAID_PASSTHROUGH_IOCTL. A pmcraid_passthrough_ioctl_buffer is copied in, and the request_size variable is set to buffer->ioarcb.data_transfer_length, which is an arbitrary 32-bit signed value provided by the user. If a negative value is provided here, bad things can happen. For example, pmcraid_build_passthrough_ioadls() is called with this request_size, which immediately calls pmcraid_alloc_sglist() with a negative size. The resulting math on allocating a scatter list can result in an overflow in the kzalloc() call (if num_elem is 0, the sglist will be smaller than expected), or if num_elem is unexpectedly large the subsequent loop will call alloc_pages() repeatedly, a high number of pages will be allocated and the OOM killer might be invoked. Prevent this value from being negative in pmcraid_ioctl_passthrough(). Signed-off-by: Dan Rosenberg Cc: Anil Ravindranath Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 5920c3712db2d05f820426fbf1123fd00e2d1e0d Author: Igor Mammedov Date: Mon Apr 18 10:17:17 2011 -0700 Input: xen-kbdfront - fix mouse getting stuck after save/restore commit c36b58e8a9112017c2bcc322cc98e71241814303 upstream. Mouse gets "stuck" after restore of PV guest but buttons are in working condition. If driver has been configured for ABS coordinates at start it will get XENKBD_TYPE_POS events and then suddenly after restore it'll start getting XENKBD_TYPE_MOTION events, that will be dropped later and they won't get into user-space. Regression was introduced by hunk 5 and 6 of 5ea5254aa0ad269cfbd2875c973ef25ab5b5e9db ("Input: xen-kbdfront - advertise either absolute or relative coordinates"). Driver on restore should ask xen for request-abs-pointer again if it is available. So restore parts that did it before 5ea5254. Acked-by: Olaf Hering Signed-off-by: Igor Mammedov Signed-off-by: Andi Kleen [v1: Expanded the commit description] Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Dmitry Torokhov commit 67d456fdeff3f5ee21ea788b0ce1800eba0db5cb Author: Trond Myklebust Date: Fri Apr 15 17:34:18 2011 -0400 NFSv4.1: Ensure state manager thread dies on last umount commit 47c2199b6eb5fbe38ddb844db7cdbd914d304f9c upstream. Currently, the state manager may continue to try recovering state forever even after the last filesystem to reference that nfs_client has umounted. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 86b7b580a603f3ecd18e3b19e5d9dc2eb7c458dc Author: Jeff Layton Date: Wed Apr 27 11:49:09 2011 -0400 nfs: don't lose MS_SYNCHRONOUS on remount of noac mount commit 26c4c170731f00008f4317a2888a0a07ac99d90d upstream. On a remount, the VFS layer will clear the MS_SYNCHRONOUS bit on the assumption that the flags on the mount syscall will have it set if the remounted fs is supposed to keep it. In the case of "noac" though, MS_SYNCHRONOUS is implied. A remount of such a mount will lose the MS_SYNCHRONOUS flag since "sync" isn't part of the mount options. Reported-by: Max Matveev Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 3703f45f5bc34dae097b135bfcd0448d73848a3c Author: Michael Schmitz Date: Tue Apr 26 14:51:53 2011 +1200 m68k/mm: Set all online nodes in N_NORMAL_MEMORY commit 4aac0b4815ba592052758f4b468f253d383dc9d6 upstream. For m68k, N_NORMAL_MEMORY represents all nodes that have present memory since it does not support HIGHMEM. This patch sets the bit at the time node_present_pages has been set by free_area_init_node. At the time the node is brought online, the node state would have to be done unconditionally since information about present memory has not yet been recorded. If N_NORMAL_MEMORY is not accurate, slub may encounter errors since it uses this nodemask to setup per-cache kmem_cache_node data structures. This pach is an alternative to the one proposed by David Rientjes attempting to set node state immediately when bringing the node online. Signed-off-by: Michael Schmitz Tested-by: Thorsten Glaser Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 42e4c1f34c0d1a2fdfb0b829ec9645daf16dcd7a Author: Patrick Boettcher Date: Sun Apr 3 12:40:24 2011 -0300 FLEXCOP-PCI: fix __xlate_proc_name-warning for flexcop-pci commit b934c20de1398d4a82d2ecfeb588a214a910f13f upstream. This patch fixes the warning about bad names for sys-fs and other kernel-things. The flexcop-pci driver was using '/'-characters in it, which is not good. This has been fixed in several attempts by several people, but obviously never made it into the kernel. Signed-off-by: Patrick Boettcher Cc: Steffen Barszus Cc: Boris Cuber Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 42d14d10679e6baebdb67cc1484af8bb037bd441 Author: David Rientjes Date: Wed Apr 20 19:27:13 2011 -0700 set memory ranges in N_NORMAL_MEMORY when onlined commit d9b41e0b54fd7e164daf1e9c539c1070398aa02e upstream. When a DISCONTIGMEM memory range is brought online as a NUMA node, it also needs to have its bet set in N_NORMAL_MEMORY. This is necessary for generic kernel code that utilizes N_NORMAL_MEMORY as a subset of N_ONLINE for memory savings. These types of hacks can hopefully be removed once DISCONTIGMEM is either removed or abstracted away from CONFIG_NUMA. Fixes a panic in the slub code which only initializes structures for N_NORMAL_MEMORY to save memory: Backtrace: [<000000004021c938>] add_partial+0x28/0x98 [<000000004021faa0>] __slab_free+0x1d0/0x1d8 [<000000004021fd04>] kmem_cache_free+0xc4/0x128 [<000000004033bf9c>] ida_get_new_above+0x21c/0x2c0 [<00000000402a8980>] sysfs_new_dirent+0xd0/0x238 [<00000000402a974c>] create_dir+0x5c/0x168 [<00000000402a9ab0>] sysfs_create_dir+0x98/0x128 [<000000004033d6c4>] kobject_add_internal+0x114/0x258 [<000000004033d9ac>] kobject_add_varg+0x7c/0xa0 [<000000004033df20>] kobject_add+0x50/0x90 [<000000004033dfb4>] kobject_create_and_add+0x54/0xc8 [<00000000407862a0>] cgroup_init+0x138/0x1f0 [<000000004077ce50>] start_kernel+0x5a0/0x840 [<000000004011fa3c>] start_parisc+0xa4/0xb8 [<00000000404bb034>] packet_ioctl+0x16c/0x208 [<000000004049ac30>] ip_mroute_setsockopt+0x260/0xf20 Signed-off-by: David Rientjes Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit 3f14204734d5cb567edbc6e90885a5d6cae21ad0 Author: Dan Rosenberg Date: Tue Apr 5 12:45:59 2011 -0400 mpt2sas: prevent heap overflows and unchecked reads [ upstream commit a1f74ae82d133ebb2aabb19d181944b4e83e9960 ] At two points in handling device ioctls via /dev/mpt2ctl, user-supplied length values are used to copy data from userspace into heap buffers without bounds checking, allowing controllable heap corruption and subsequently privilege escalation. Additionally, user-supplied values are used to determine the size of a copy_to_user() as well as the offset into the buffer to be read, with no bounds checking, allowing users to read arbitrary kernel memory. Signed-off-by: Dan Rosenberg Cc: stable@kernel.org Acked-by: Eric Moore Signed-off-by: James Bottomley Signed-off-by: Andi Kleen commit fff22ebf8262a288e4541d69fd959d9f2d8e4cc7 Author: Thomas Graf Date: Fri Sep 3 02:59:14 2010 +0000 ipv6: add special mode accept_ra=2 to accept RA while configured as router [ upstream commit 65e9b62d4503849b10bedfc29bff0473760cc597 ] The current IPv6 behavior is to not accept router advertisements while forwarding, i.e. configured as router. This does make sense, a router is typically not supposed to be auto configured. However there are exceptions and we should allow the current behavior to be overwritten. Therefore this patch enables the user to overrule the "if forwarding enabled then don't listen to RAs" rule by setting accept_ra to the special value of 2. An alternative would be to ignore the forwarding switch alltogether and solely accept RAs based on the value of accept_ra. However, I found that if not intended, accepting RAs as a router can lead to strange unwanted behavior therefore we it seems wise to only do so if the user explicitely asks for this behavior. Signed-off-by: Thomas Graf Signed-off-by: David S. Miller Signed-off-by: Andi Kleen commit 057192c2e12ff9a7d7f168913025106cf6ccbd8c Author: Jiri Slaby Date: Tue Feb 15 15:55:07 2011 +0100 USB: serial/usb_wwan, fix tty NULL dereference [ upstream commit 38237fd2be9421c104f84cc35665097bdce89013 ] tty_port_tty_get may return without any problems NULL. Handle this case and do not oops in usb_wwan_indat_callback by dereferencing it. The oops: Unable to handle kernel paging request for data at address 0x000000d8 Faulting instruction address: 0xc0175b3c Oops: Kernel access of bad area, sig: 11 [#1] PowerPC 40x Platform last sysfs file: /sys/devices/pci0000:00/0000:00:00.0/0000:01:00.0/0000:02:09.2/usb1/idVendor Modules linked in: NIP: c0175b3c LR: c0175e7c CTR: c0215c90 REGS: c77f7d50 TRAP: 0300 Not tainted (2.6.37-rc5) MSR: 00021030 CR: 88482028 XER: 2000005f DEAR: 000000d8, ESR: 00000000 TASK = c7141b90[1149] 'wvdial' THREAD: c2750000 GPR00: 00021030 c77f7e00 c7141b90 00000000 0000000e 00000000 0000000e c0410680 GPR08: c683db00 00000000 00000001 c03c81f8 88482028 10073ef4 ffffffb9 ffffff94 GPR16: 00000000 fde036c0 00200200 00100100 00000001 ffffff8d c34fabcc 00000000 GPR24: c71120d4 00000000 00000000 0000000e 00021030 00000000 00000000 0000000e NIP [c0175b3c] tty_buffer_request_room+0x2c/0x194 LR [c0175e7c] tty_insert_flip_string_fixed_flag+0x3c/0xb0 Call Trace: [c77f7e00] [00000003] 0x3 (unreliable) [c77f7e30] [c0175e7c] tty_insert_flip_string_fixed_flag+0x3c/0xb0 [c77f7e60] [c0215df4] usb_wwan_indat_callback+0x164/0x170 ... References: https://bugzilla.kernel.org/show_bug.cgi?id=24582 Cc: Amit Shah Cc: baoyb Signed-off-by: Jiri Slaby Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen commit f6f0a6fc894aad0108952e957d4e79241d4c6cab Author: Jim Bos Date: Mon Nov 15 21:22:37 2010 +0100 Fix gcc 4.5.1 miscompiling drivers/char/i8k.c (again) [ upstream commit 22d3243de86bc92d874abb7c5b185d5c47aba323 ] The fix in commit 6b4e81db2552 ("i8k: Tell gcc that *regs gets clobbered") to work around the gcc miscompiling i8k.c to add "+m (*regs)" caused register pressure problems and a build failure. Changing the 'asm' statement to 'asm volatile' instead should prevent that and works around the gcc bug as well, so we can remove the "+m". [ Background on the gcc bug: a memory clobber fails to mark the function the asm resides in as non-pure (aka "__attribute__((const))"), so if the function does nothing else that triggers the non-pure logic, gcc will think that that function has no side effects at all. As a result, callers will be mis-compiled. Adding the "+m" made gcc see that it's not a pure function, and so does "asm volatile". The problem was never really the need to mark "*regs" as changed, since the memory clobber did that part - the problem was just a bug in the gcc "pure" function analysis - Linus ] Signed-off-by: Jim Bos Acked-by: Jakub Jelinek Cc: Andi Kleen Cc: Andreas Schwab Signed-off-by: Linus Torvalds Signed-off-by: Andi Kleen commit e58c04b185972bebd832a9716a037aa1c5fab745 Author: Jim Bos Date: Sat Nov 13 12:13:53 2010 +0100 i8k: Tell gcc that *regs gets clobbered [ upstream commit 6b4e81db2552bad04100e7d5ddeed7e848f53b48 ] More recent GCC caused the i8k driver to stop working, on Slackware compiler was upgraded from gcc-4.4.4 to gcc-4.5.1 after which it didn't work anymore, meaning the driver didn't load or gave total nonsensical output. As it turned out the asm(..) statement forgot to mention it modifies the *regs variable. Credits to Andi Kleen and Andreas Schwab for providing the fix. Signed-off-by: Jim Bos Cc: Andi Kleen Cc: Andreas Schwab Signed-off-by: Linus Torvalds Signed-off-by: Andi Kleen commit ce8b71ac8d2d454629ba04bd64bfd1a2fbe1d06c Author: Vasiliy Kulikov Date: Thu Apr 14 20:55:19 2011 +0400 agp: fix OOM and buffer overflow [ upstream commit b522f02184b413955f3bc952e3776ce41edc6355 ] page_count is copied from userspace. agp_allocate_memory() tries to check whether this number is too big, but doesn't take into account the wrap case. Also agp_create_user_memory() doesn't check whether alloc_size is calculated from num_agp_pages variable without overflow. This may lead to allocation of too small buffer with following buffer overflow. Another problem in agp code is not addressed in the patch - kernel memory exhaustion (AGPIOC_RESERVE and AGPIOC_ALLOCATE ioctls). It is not checked whether requested pid is a pid of the caller (no check in agpioc_reserve_wrap()). Each allocation is limited to 16KB, though, there is no per-process limit. This might lead to OOM situation, which is not even solved in case of the caller death by OOM killer - the memory is allocated for another (faked) process. Signed-off-by: Vasiliy Kulikov Signed-off-by: Dave Airlie Signed-off-by: Andi Kleen commit 7f482d63e27696707ac00eb838ed9379f89957b8 Author: Vasiliy Kulikov Date: Thu Apr 14 20:55:16 2011 +0400 agp: fix arbitrary kernel memory writes [ upstream commit 194b3da873fd334ef183806db751473512af29ce ] pg_start is copied from userspace on AGPIOC_BIND and AGPIOC_UNBIND ioctl cmds of agp_ioctl() and passed to agpioc_bind_wrap(). As said in the comment, (pg_start + mem->page_count) may wrap in case of AGPIOC_BIND, and it is not checked at all in case of AGPIOC_UNBIND. As a result, user with sufficient privileges (usually "video" group) may generate either local DoS or privilege escalation. Signed-off-by: Vasiliy Kulikov Signed-off-by: Dave Airlie Signed-off-by: Andi Kleen commit 399f9eb9c628914fe5f1acef5bb2dd736227597c Author: Mauro Carvalho Chehab Date: Mon Dec 27 08:27:05 2010 -0300 Remove the old V4L1 v4lgrab.c file [ upstream commit 55fe25b418640fad04190103274841b2c907bacd ] This example file uses the old V4L1 API. It also doesn't use libv4l. So, it is completely obsolete. A good example already exists at v4l-utils (v4l2grab.c): http://git.linuxtv.org/v4l-utils.git [AK: included in 2.6.35 because v4lgrab doesn't build without the host's linux/videodev.h] Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Andi Kleen commit 27752f2920dcbaae3a13a3caac8db94d9a9e427a Author: Andi Kleen Date: Mon Aug 1 13:54:41 2011 -0700 maintainer Add Andi Kleen as 2.6.35 longterm maintainer From: Andi Kleen People complained about me not being in the MAINTAINERS file. So fix that. Signed-off-by: Andi Kleen commit eaea8f19f079912b532fc85a3182f134f962b1f2 Author: Michal Marek Date: Mon May 2 12:51:15 2011 +0200 kbuild: Fix passing -Wno-* options to gcc 4.4+ [ upstream commit 8417da6f2128008c431c7d130af6cd3d9079922e ] Starting with 4.4, gcc will happily accept -Wno- in the cc-option test and complain later when compiling a file that has some other warning. This rather unexpected behavior is intentional as per http://gcc.gnu.org/PR28322, so work around it by testing for support of the opposite option (without the no-). Introduce a new Makefile function cc-disable-warning that does this and update two uses of cc-option in the toplevel Makefile. Reported-and-tested-by: Stephen Rothwell Signed-off-by: Michal Marek Signed-off-by: Andi Kleen commit d247496cd6a6a936cee3e1b1a28ea5139515e156 Author: Dave Jones Date: Thu Apr 21 17:28:13 2011 -0400 kbuild: Disable -Wunused-but-set-variable for gcc 4.6.0 [ upstream commit af0e5d565d2fffcd97d1e2d89669d627cc04e8b8 ] Disable the new -Wunused-but-set-variable that was added in gcc 4.6.0 It produces more false positives than useful warnings. This can still be enabled using W=1 [AK: dropped W=1 support in backport] Signed-off-by: Dave Jones Acked-by: Sam Ravnborg Tested-by: Sam Ravnborg Signed-off-by: Michal Marek Signed-off-by: Andi Kleen