commit 8fd62c82872a5a721c9fb0071ca0f7a49c1732e4 Author: Greg Kroah-Hartman Date: Thu Apr 21 14:34:46 2011 -0700 Linux 2.6.38.4 commit 50038a29ee9d62aba6e66109d0b9c235bc0e31e2 Author: Eric Dumazet Date: Thu Apr 14 05:55:37 2011 +0000 ip: ip_options_compile() resilient to NULL skb route commit c65353daf137dd41f3ede3baf62d561fca076228 upstream. Scot Doyle demonstrated ip_options_compile() could be called with an skb without an attached route, using a setup involving a bridge, netfilter, and forged IP packets. Let's make ip_options_compile() and ip_options_rcv_srr() a bit more robust, instead of changing bridge/netfilter code. With help from Hiroaki SHIMODA. Reported-by: Scot Doyle Tested-by: Scot Doyle Signed-off-by: Eric Dumazet Cc: Stephen Hemminger Acked-by: Hiroaki SHIMODA Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6935b2f7905bc973676cec541c1ebbbd3bd5692f Author: Eric Dumazet Date: Tue Apr 12 13:39:14 2011 -0700 bridge: reset IPCB in br_parse_ip_options commit f8e9881c2aef1e982e5abc25c046820cd0b7cf64 upstream. Commit 462fb2af9788a82 (bridge : Sanitize skb before it enters the IP stack), missed one IPCB init before calling ip_options_compile() Thanks to Scot Doyle for his tests and bug reports. Reported-by: Scot Doyle Signed-off-by: Eric Dumazet Cc: Hiroaki SHIMODA Acked-by: Bandan Das Acked-by: Stephen Hemminger Cc: Jan Lübbe Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2226d5bb341cae0c736aad18ec24e1dfb625272d Author: Kyle McMartin Date: Mon Jan 24 11:13:04 2011 -0500 perf tool: Fix gcc 4.6.0 issues commit fb7d0b3cefb80a105f7fd26bbc62e0cbf9192822 upstream. GCC 4.6.0 in Fedora rawhide turned up some compile errors in tools/perf due to the -Werror=unused-but-set-variable flag. I've gone through and annotated some of the assignments that had side effects (ie: return value from a function) with the __used annotation, and in some cases, just removed unused code. In a few cases, we were assigning something useful, but not using it in later parts of the function. kyle@dreadnought:~/src% gcc --version gcc (GCC) 4.6.0 20110122 (Red Hat 4.6.0-0.3) Cc: Ingo Molnar LKML-Reference: <20110124161304.GK27353@bombadil.infradead.org> Signed-off-by: Kyle McMartin [ committer note: Fixed up the annotation fixes, as that code moved recently ] Signed-off-by: Arnaldo Carvalho de Melo [Backported to 2.6.38.2 by deleting unused but set variables] Signed-off-by: Thomas Meyer Signed-off-by: Greg Kroah-Hartman commit 2951119b25479349af6ebf1bfa3111bee3c29896 Author: Gustavo F. Padovan Date: Wed Mar 16 15:36:29 2011 -0300 Bluetooth: Fix HCI_RESET command synchronization commit f630cf0d5434e3923e1b8226ffa2753ead6b0ce5 upstream. We can't send new commands before a cmd_complete for the HCI_RESET command shows up. Reported-by: Mikko Vinni Reported-by: Justin P. Mattock Reported-by: Ed Tomlinson Signed-off-by: Gustavo F. Padovan Tested-by: Justin P. Mattock Tested-by: Mikko Vinni Tested-by: Ed Tomlinson commit dedac5a7b2df0bade917238934c6c7c645280137 Author: Michel Dänzer Date: Thu Apr 7 16:17:47 2011 +0200 radeon: Fix KMS CP writeback on big endian machines. commit dc66b325f161bb651493c7d96ad44876b629cf6a upstream. This is necessary even with PCI(e) GART, and it makes writeback work even with AGP on my PowerBook. Might still be unreliable with older revisions of UniNorth and other AGP bridges though. Signed-off-by: Michel Dänzer Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 8e458f117e43e960bfeb1f8703d643adb8de31bb Author: Matthew Wilcox Date: Tue Sep 28 00:57:32 2010 -0400 USB: Fix unplug of device with active streams commit b214f191d95ba4b5a35aebd69cd129cf7e3b1884 upstream. If I unplug a device while the UAS driver is loaded, I get an oops in usb_free_streams(). This is because usb_unbind_interface() calls usb_disable_interface() which calls usb_disable_endpoint() which sets ep_out and ep_in to NULL. Then the UAS driver calls usb_pipe_endpoint() which returns a NULL pointer and passes an array of NULL pointers to usb_free_streams(). I think the correct fix for this is to check for the NULL pointer in usb_free_streams() rather than making the driver check for this situation. My original patch for this checked for dev->state == USB_STATE_NOTATTACHED, but the call to usb_disable_interface() is conditional, so not all drivers would want this check. Note from Sarah Sharp: This patch does avoid a potential dereference, but the real fix (which will be implemented later) is to set the .soft_unbind flag in the usb_driver structure for the UAS driver, and all drivers that allocate streams. The driver should free any streams when it is unbound from the interface. This avoids leaking stream rings in the xHCI driver when usb_disable_interface() is called. This should be queued for stable trees back to 2.6.35. Signed-off-by: Matthew Wilcox Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 994133a056515517a16bfac485e9741188a71912 Author: Dmitry Torokhov Date: Tue Apr 12 23:06:28 2011 -0700 USB: xhci - also free streams when resetting devices commit 2dea75d96ade3c7cd2bfe73f99c7b3291dc3d03a upstream. Currently, when resetting a device, xHCI driver disables all but one endpoints and frees their rings, but leaves alone any streams that might have been allocated. Later, when users try to free allocated streams, we oops in xhci_setup_no_streams_ep_input_ctx() because ep->ring is NULL. Let's free not only rings but also stream data as well, so that calling free_streams() on a device that was reset will be safe. This should be queued for stable trees back to 2.6.35. Reviewed-by: Micah Elizabeth Scott Signed-off-by: Dmitry Torokhov Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit b9d75083e022102b4f24dd0f8ebaa14ab4568bbf Author: Dmitry Torokhov Date: Wed Mar 23 22:41:23 2011 -0700 USB: xhci - fix math in xhci_get_endpoint_interval() commit dfa49c4ad120a784ef1ff0717168aa79f55a483a upstream. When parsing exponent-expressed intervals we subtract 1 from the value and then expect it to match with original + 1, which is highly unlikely, and we end with frequent spew: usb 3-4: ep 0x83 - rounding interval to 512 microframes Also, parsing interval for fullspeed isochronous endpoints was incorrect - according to USB spec they use exponent-based intervals (but xHCI spec claims frame-based intervals). I trust USB spec more, especially since USB core agrees with it. This should be queued for stable kernels back to 2.6.31. Reviewed-by: Micah Elizabeth Scott Signed-off-by: Dmitry Torokhov Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 879d2ccad7347a306adaf8bf90c4146d91a4ea7e Author: Dmitry Torokhov Date: Sun Mar 20 02:15:17 2011 -0700 USB: xhci - fix unsafe macro definitions commit 5a6c2f3ff039154872ce597952f8b8900ea0d732 upstream. Macro arguments used in expressions need to be enclosed in parenthesis to avoid unpleasant surprises. This should be queued for kernels back to 2.6.31 Signed-off-by: Dmitry Torokhov Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 9b53284b310075ecc40e70187383e2af268e4078 Author: Dmitry Torokhov Date: Fri Mar 18 21:29:01 2011 -0700 USB: fix formatting of SuperSpeed endpoints in /proc/bus/usb/devices commit 2868a2b1ba8f9c7f6c4170519ebb6c62934df70e upstream. Isochronous and interrupt SuperSpeed endpoints use the same mechanisms for decoding bInterval values as HighSpeed ones so adjust the code accordingly. Also bandwidth reservation for SuperSpeed matches highspeed, not low/full speed. Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 05cf278c7141fd2a4373e62161416e85aeb688bc Author: Alan Stern Date: Tue Apr 5 13:36:15 2011 -0400 USB: EHCI: unlink unused QHs when the controller is stopped commit 94ae4976e253757e9b03a44d27d41b20f1829d80 upstream. This patch (as1458) fixes a problem affecting ultra-reliable systems: When hardware failover of an EHCI controller occurs, the data structures do not get released correctly. This is because the routine responsible for removing unused QHs from the async schedule assumes the controller is running properly (the frame counter is used in determining how long the QH has been idle) -- but when a failover causes the controller to be electronically disconnected from the PCI bus, obviously it stops running. The solution is simple: Allow scan_async() to remove a QH from the async schedule if it has been idle for long enough _or_ if the controller is stopped. Signed-off-by: Alan Stern Reported-and-Tested-by: Dan Duval Signed-off-by: Greg Kroah-Hartman commit c0cc35919317b579b23514c1385f246f348852ad Author: Steven Hardy Date: Mon Apr 4 18:02:25 2011 +0100 usb: qcserial add missing errorpath kfrees commit cb62d65f966146a39fdde548cb474dacf1d00fa5 upstream. There are two -ENODEV error paths in qcprobe where the allocated private data is not freed, this patch adds the two missing kfrees to avoid leaking memory on the error path Signed-off-by: Steven Hardy Signed-off-by: Greg Kroah-Hartman commit 4f377dfbba0ff6d83fcf9f4939d51ca54b8d4485 Author: Steven Hardy Date: Mon Apr 4 17:59:55 2011 +0100 usb: qcserial avoid pointing to freed memory commit 99ab3f9e4eaec35fd2d7159c31b71f17f7e613e3 upstream. Rework the qcprobe logic such that serial->private is not set when qcprobe exits with -ENODEV, otherwise serial->private will point to freed memory on -ENODEV Signed-off-by: Steven Hardy Signed-off-by: Greg Kroah-Hartman commit a14f54520a7a50f1d591d848c65955eb0feb993b Author: Steven Hardy Date: Mon Apr 4 17:57:37 2011 +0100 usb: Fix qcserial memory leak on rmmod commit 10c9ab15d6aee153968d150c05b3ee3df89673de upstream. qcprobe function allocates serial->private but this is never freed, this patch adds a new function qc_release() which frees serial->private, after calling usb_wwan_release Signed-off-by: Steven Hardy Signed-off-by: Greg Kroah-Hartman commit fae123f8208d7d56b35c0c8e9a299e052f62dfcc Author: Eric B Munson Date: Fri Apr 15 08:12:30 2011 +0000 powerpc/perf_event: Skip updating kernel counters if register value shrinks commit 86c74ab317c1ef4d37325e0d7ca8a01a796b0bd7 upstream. Because of speculative event roll back, it is possible for some event coutners to decrease between reads on POWER7. This causes a problem with the way that counters are updated. Delta calues are calculated in a 64 bit value and the top 32 bits are masked. If the register value has decreased, this leaves us with a very large positive value added to the kernel counters. This patch protects against this by skipping the update if the delta would be negative. This can lead to a lack of precision in the coutner values, but from my testing the value is typcially fewer than 10 samples at a time. Signed-off-by: Eric B Munson Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 4efa7d8da6914e9cce94f405649e407ffa20a04e Author: Anton Blanchard Date: Thu Apr 7 21:44:21 2011 +0000 powerpc: Fix oops if scan_dispatch_log is called too early commit 84ffae55af79d7b8834fd0c08d0d1ebf2c77f91e upstream. We currently enable interrupts before the dispatch log for the boot cpu is setup. If a timer interrupt comes in early enough we oops in scan_dispatch_log: Unable to handle kernel paging request for data at address 0x00000010 ... .scan_dispatch_log+0xb0/0x170 .account_system_vtime+0xa0/0x220 .irq_enter+0x88/0xc0 .do_IRQ+0x48/0x230 The patch below adds a check to scan_dispatch_log to ensure the dispatch log has been allocated. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit a506a5b9282e4b944ed314d2b30ce387c44ff9fe Author: Linus Torvalds Date: Mon Apr 18 10:36:54 2011 -0700 proc: do proper range check on readdir offset commit d8bdc59f215e62098bc5b4256fd9928bf27053a1 upstream. Rather than pass in some random truncated offset to the pid-related functions, check that the offset is in range up-front. This is just cleanup, the previous commit fixed the real problem. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c8b265db1e63fdb296ec2721f5c1473c44bc4dc5 Author: Linus Torvalds Date: Mon Apr 18 10:35:30 2011 -0700 next_pidmap: fix overflow condition commit c78193e9c7bcbf25b8237ad0dec82f805c4ea69b upstream. next_pidmap() just quietly accepted whatever 'last' pid that was passed in, which is not all that safe when one of the users is /proc. Admittedly the proc code should do some sanity checking on the range (and that will be the next commit), but that doesn't mean that the helper functions should just do that pidmap pointer arithmetic without checking the range of its arguments. So clamp 'last' to PID_MAX_LIMIT. The fact that we then do "last+1" doesn't really matter, the for-loop does check against the end of the pidmap array properly (it's only the actual pointer arithmetic overflow case we need to worry about, and going one bit beyond isn't going to overflow). [ Use PID_MAX_LIMIT rather than pid_max as per Eric Biederman ] Reported-by: Tavis Ormandy Analyzed-by: Robert Święcki Cc: Eric W. Biederman Cc: Pavel Emelyanov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit dd8eece9b71a865b6f223c2f84058788870cd655 Author: Marius B. Kotsbak Date: Tue Mar 22 00:01:53 2011 +0100 USB: option: Added support for Samsung GT-B3730/GT-B3710 LTE USB modem. commit 80f9df3e0093ad9f1eeefd2ff7fd27daaa518d25 upstream. Bind only modem AT command endpoint to option. Signed-off-by: Marius B. Kotsbak Signed-off-by: Greg Kroah-Hartman commit 4fcb66124aab60e3913dc4f6dfb0a09ad0b4786d Author: Paul Friedrich Date: Fri Mar 18 11:13:55 2011 +0100 USB: ftdi_sio: add ids for Hameg HO720 and HO730 commit c53c2fab40cf16e13af66f40bfd27200cda98d2f upstream. usb serial: ftdi_sio: add two missing USB ID's for Hameg interfaces HO720 and HO730 Signed-off-by: Greg Kroah-Hartman commit f2de099d01761aefb37022adc686772fbf2a8ae8 Author: Johan Hovold Date: Fri Apr 8 17:38:22 2011 +0200 USB: ftdi_sio: add PID for OCT DK201 docking station commit 11a31d84129dc3133417d626643d714c9df5317e upstream. Add PID 0x0103 for serial port of the OCT DK201 docking station. Reported-by: Jan Hoogenraad Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit e4cd0daa1f8735f2263dadca3882c2ffa224b06c Author: Christian Simon Date: Mon Mar 28 21:54:47 2011 +0200 USB: ftdi_sio: Added IDs for CTI USB Serial Devices commit 5a9443f08c83c294c5c806a689c1184b27cb26b3 upstream. I added new ProdutIds for two devices from CTI GmbH Leipzig. Signed-off-by: Christian Simon Signed-off-by: Greg Kroah-Hartman commit faaf43f0c4af76458d0f82fe6aa6735a40e4aa4d Author: Felipe Balbi Date: Tue Mar 22 11:31:37 2011 +0200 usb: musb: temporarily make it bool commit 7a180e70cfc56e131bfe4796773df2acfc7d4180 upstream. Due to the recent changes to musb's glue layers, we can't compile musb-hdrc as a module - compilation will break due to undefined symbol musb_debug. In order to fix that, we need a big re-work of the debug support on the MUSB driver. Because that would mean a lot of new code coming into the -rc series, it's best to defer that to next merge window and for now just disable module support for MUSB. Once we get the refactor of the debugging support done, we can simply revert this patch and things will go back to normal again. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 510edc2527fd3d25b6119d980dddff7213868b19 Author: Jiri Kosina Date: Thu Apr 14 15:22:09 2011 -0700 brk: COMPAT_BRK: fix detection of randomized brk commit 4471a675dfc7ca676c165079e91c712b09dc9ce4 upstream. 5520e89 ("brk: fix min_brk lower bound computation for COMPAT_BRK") tried to get the whole logic of brk randomization for legacy (libc5-based) applications finally right. It turns out that the way to detect whether brk has actually been randomized in the end or not introduced by that patch still doesn't work for those binaries, as reported by Geert: : /sbin/init from my old m68k ramdisk exists prematurely. : : Before the patch: : : | brk(0x80005c8e) = 0x80006000 : : After the patch: : : | brk(0x80005c8e) = 0x80005c8e : : Old libc5 considers brk() to have failed if the return value is not : identical to the requested value. I don't like it, but currently see no better option than a bit flag in task_struct to catch the CONFIG_COMPAT_BRK && randomize_va_space == 2 case. Signed-off-by: Jiri Kosina Tested-by: Geert Uytterhoeven Reported-by: Geert Uytterhoeven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 411999731208babec42c9d17f931a8d87586b05f Author: KOSAKI Motohiro Date: Thu Apr 14 15:22:12 2011 -0700 vmscan: all_unreclaimable() use zone->all_unreclaimable as a name commit 929bea7c714220fc76ce3f75bef9056477c28e74 upstream. all_unreclaimable check in direct reclaim has been introduced at 2.6.19 by following commit. 2006 Sep 25; commit 408d8544; oom: use unreclaimable info And it went through strange history. firstly, following commit broke the logic unintentionally. 2008 Apr 29; commit a41f24ea; page allocator: smarter retry of costly-order allocations Two years later, I've found obvious meaningless code fragment and restored original intention by following commit. 2010 Jun 04; commit bb21c7ce; vmscan: fix do_try_to_free_pages() return value when priority==0 But, the logic didn't works when 32bit highmem system goes hibernation and Minchan slightly changed the algorithm and fixed it . 2010 Sep 22: commit d1908362: vmscan: check all_unreclaimable in direct reclaim path But, recently, Andrey Vagin found the new corner case. Look, struct zone { .. int all_unreclaimable; .. unsigned long pages_scanned; .. } zone->all_unreclaimable and zone->pages_scanned are neigher atomic variables nor protected by lock. Therefore zones can become a state of zone->page_scanned=0 and zone->all_unreclaimable=1. In this case, current all_unreclaimable() return false even though zone->all_unreclaimabe=1. This resulted in the kernel hanging up when executing a loop of the form 1. fork 2. mmap 3. touch memory 4. read memory 5. munmmap as described in http://www.gossamer-threads.com/lists/linux/kernel/1348725#1348725 Is this ignorable minor issue? No. Unfortunately, x86 has very small dma zone and it become zone->all_unreclamble=1 easily. and if it become all_unreclaimable=1, it never restore all_unreclaimable=0. Why? if all_unreclaimable=1, vmscan only try DEF_PRIORITY reclaim and a-few-lru-pages>>DEF_PRIORITY always makes 0. that mean no page scan at all! Eventually, oom-killer never works on such systems. That said, we can't use zone->pages_scanned for this purpose. This patch restore all_unreclaimable() use zone->all_unreclaimable as old. and in addition, to add oom_killer_disabled check to avoid reintroduce the issue of commit d1908362 ("vmscan: check all_unreclaimable in direct reclaim path"). Reported-by: Andrey Vagin Signed-off-by: KOSAKI Motohiro Cc: Nick Piggin Reviewed-by: Minchan Kim Reviewed-by: KAMEZAWA Hiroyuki Acked-by: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 97c5a1c2d96e5dffe7e0c93cd0f5a50038c8e9e3 Author: Ken Chen Date: Fri Apr 8 12:20:16 2011 -0700 sched: Fix erroneous all_pinned logic commit b30aef17f71cf9e24b10c11cbb5e5f0ebe8a85ab upstream. The scheduler load balancer has specific code to deal with cases of unbalanced system due to lots of unmovable tasks (for example because of hard CPU affinity). In those situation, it excludes the busiest CPU that has pinned tasks for load balance consideration such that it can perform second 2nd load balance pass on the rest of the system. This all works as designed if there is only one cgroup in the system. However, when we have multiple cgroups, this logic has false positives and triggers multiple load balance passes despite there are actually no pinned tasks at all. The reason it has false positives is that the all pinned logic is deep in the lowest function of can_migrate_task() and is too low level: load_balance_fair() iterates each task group and calls balance_tasks() to migrate target load. Along the way, balance_tasks() will also set a all_pinned variable. Given that task-groups are iterated, this all_pinned variable is essentially the status of last group in the scanning process. Task group can have number of reasons that no load being migrated, none due to cpu affinity. However, this status bit is being propagated back up to the higher level load_balance(), which incorrectly think that no tasks were moved. It kick off the all pinned logic and start multiple passes attempt to move load onto puller CPU. To fix this, move the all_pinned aggregation up at the iterator level. This ensures that the status is aggregated over all task-groups, not just last one in the list. Signed-off-by: Ken Chen Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/BANLkTi=ernzNawaR5tJZEsV_QVnfxqXmsQ@mail.gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2ff9ca5e095881fc9a5e3e86e5821ff0ad84724b Author: Mike Frysinger Date: Fri Mar 18 04:26:24 2011 -0400 RTC: add missing "return 0" in new alarm func for rtc-bfin.c commit 8c122b96866580c99e44f3f07ac93a993d964ec3 upstream. The new bfin_rtc_alarm_irq_enable function forgot to add a "return 0" to the end leading to the build warning: drivers/rtc/rtc-bfin.c: In function 'bfin_rtc_alarm_irq_enable': drivers/rtc/rtc-bfin.c:253: warning: control reaches end of non-void function CC: Thomas Gleixner CC: Alessandro Zummo Signed-off-by: Mike Frysinger Signed-off-by: John Stultz Signed-off-by: Greg Kroah-Hartman commit 93be96977dd8ef5bee7cf746e699d03627496e23 Author: Alex Deucher Date: Sun Apr 17 10:20:19 2011 +0200 i2c-algo-bit: Call pre/post_xfer for bit_test commit d3b3e15da14ded61c9654db05863b04a2435f4cc upstream. Apparently some distros set i2c-algo-bit.bit_test to 1 by default. In some cases this causes i2c_bit_add_bus to fail and prevents the i2c bus from being added. In the radeon case, we fail to add the ddc i2c buses which prevents the driver from being able to detect attached monitors. The i2c bus works fine even if bit_test fails. This is likely due to gpio switching that is required and handled in the pre/post_xfer hooks, so call the pre/post_xfer hooks in the bit test as well. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=36221 Signed-off-by: Alex Deucher Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit c421122f3dea5b5c42133f67a8084e6c0793a35c Author: Will Deacon Date: Tue Apr 5 13:57:53 2011 +0100 ARM: 6864/1: hw_breakpoint: clear DBGVCR out of reset commit e89c0d7090c54d7b11b9b091e495a1ae345dd3ff upstream. The DBGVCR, used for configuring vector catch debug events, is UNKNOWN out of reset on ARMv7. When enabling monitor mode, this must be zeroed to avoid UNPREDICTABLE behaviour. This patch adds the zeroing code to the debug reset path. Reported-by: Stepan Moskovchenko Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 0b76f8fcb3f302aaf18c65337a472b32d8a74b67 Author: Tim Chen Date: Fri Apr 15 11:39:29 2011 -0700 vfs: Fix absolute RCU path walk failures due to uninitialized seq number commit c1530019e311c91d14b24d8e74d233152d806e45 upstream. During RCU walk in path_lookupat and path_openat, the rcu lookup frequently failed if looking up an absolute path, because when root directory was looked up, seq number was not properly set in nameidata. We dropped out of RCU walk in nameidata_drop_rcu due to mismatch in directory entry's seq number. We reverted to slow path walk that need to take references. With the following patch, I saw a 50% increase in an exim mail server benchmark throughput on a 4-socket Nehalem-EX system. Signed-off-by: Tim Chen Reviewed-by: Andi Kleen Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 669479155adaf2c0e21934ef1911c9e583d10f5e Author: Joerg Roedel Date: Fri Apr 15 14:47:40 2011 +0200 x86, amd: Disable GartTlbWlkErr when BIOS forgets it commit 5bbc097d890409d8eff4e3f1d26f11a9d6b7c07e upstream. This patch disables GartTlbWlk errors on AMD Fam10h CPUs if the BIOS forgets to do is (or is just too old). Letting these errors enabled can cause a sync-flood on the CPU causing a reboot. The AMD BKDG recommends disabling GART TLB Wlk Error completely. This patch is the fix for https://bugzilla.kernel.org/show_bug.cgi?id=33012 on my machine. Signed-off-by: Joerg Roedel Link: http://lkml.kernel.org/r/20110415131152.GJ18463@8bytes.org Tested-by: Alexandre Demers Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit d7b7f0c401303dd7eafcff11752fe74d3b75c766 Author: Boris Ostrovsky Date: Tue Mar 15 12:13:44 2011 -0400 x86, AMD: Set ARAT feature on AMD processors commit b87cf80af3ba4b4c008b4face3c68d604e1715c6 upstream. Support for Always Running APIC timer (ARAT) was introduced in commit db954b5898dd3ef3ef93f4144158ea8f97deb058. This feature allows us to avoid switching timers from LAPIC to something else (e.g. HPET) and go into timer broadcasts when entering deep C-states. AMD processors don't provide a CPUID bit for that feature but they also keep APIC timers running in deep C-states (except for cases when the processor is affected by erratum 400). Therefore we should set ARAT feature bit on AMD CPUs. Tested-by: Borislav Petkov Acked-by: Andreas Herrmann Acked-by: Mark Langsdorf Acked-by: Thomas Gleixner Signed-off-by: Boris Ostrovsky LKML-Reference: <1300205624-4813-1-git-send-email-ostr@amd64.org> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 78caa50ce2c5d8ccf9547978aa74e1ba5de08b00 Author: Artem Bityutskiy Date: Wed Apr 13 10:31:52 2011 +0300 UBIFS: fix oops when R/O file-system is fsync'ed commit 78530bf7f2559b317c04991b52217c1608d5a58d upstream. This patch fixes severe UBIFS bug: UBIFS oopses when we 'fsync()' an file on R/O-mounter file-system. We (the UBIFS authors) incorrectly thought that VFS would not propagate 'fsync()' down to the file-system if it is read-only, but this is not the case. It is easy to exploit this bug using the following simple perl script: use strict; use File::Sync qw(fsync sync); die "File path is not specified" if not defined $ARGV[0]; my $path = $ARGV[0]; open FILE, "<", "$path" or die "Cannot open $path: $!"; fsync(\*FILE) or die "cannot fsync $path: $!"; close FILE or die "Cannot close $path: $!"; Thanks to Reuben Dowle for reporting about this issue. Signed-off-by: Artem Bityutskiy Reported-by: Reuben Dowle Signed-off-by: Greg Kroah-Hartman commit 800f0cbf5b425df719f1905f9eff71b44dc244ab Author: Randy Dunlap Date: Thu Apr 14 15:22:07 2011 -0700 MAINTAINERS: update STABLE BRANCH info commit d00ebeac5f24f290636f7a895dafc124b2930a08 upstream. Drop Chris Wright from STABLE maintainers. He hasn't done STABLE release work for quite some time. Signed-off-by: Randy Dunlap Acked-by: Chris Wright Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9bf82fb0f4eb4035fae7c5436364e7b8b8b81e17 Author: KOSAKI Motohiro Date: Thu Apr 14 15:22:13 2011 -0700 oom-kill: remove boost_dying_task_prio() commit 341aea2bc48bf652777fb015cc2b3dfa9a451817 upstream. This is an almost-revert of commit 93b43fa ("oom: give the dying task a higher priority"). That commit dramatically improved oom killer logic when a fork-bomb occurs. But I've found that it has nasty corner case. Now cpu cgroup has strange default RT runtime. It's 0! That said, if a process under cpu cgroup promote RT scheduling class, the process never run at all. If an admin inserts a !RT process into a cpu cgroup by setting rtruntime=0, usually it runs perfectly because a !RT task isn't affected by the rtruntime knob. But if it promotes an RT task via an explicit setscheduler() syscall or an OOM, the task can't run at all. In short, the oom killer doesn't work at all if admins are using cpu cgroup and don't touch the rtruntime knob. Eventually, kernel may hang up when oom kill occur. I and the original author Luis agreed to disable this logic. Signed-off-by: KOSAKI Motohiro Acked-by: Luis Claudio R. Goncalves Acked-by: KAMEZAWA Hiroyuki Reviewed-by: Minchan Kim Acked-by: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2fa669669e7646c45037b3d9a2bb9cc9a0c7f928 Author: Bob Liu Date: Thu Apr 14 15:22:20 2011 -0700 ramfs: fix memleak on no-mmu arch commit b836aec53e2bce71de1d5415313380688c851477 upstream. On no-mmu arch, there is a memleak during shmem test. The cause of this memleak is ramfs_nommu_expand_for_mapping() added page refcount to 2 which makes iput() can't free that pages. The simple test file is like this: int main(void) { int i; key_t k = ftok("/etc", 42); for ( i=0; i<100; ++i) { int id = shmget(k, 10000, 0644|IPC_CREAT); if (id == -1) { printf("shmget error\n"); } if(shmctl(id, IPC_RMID, NULL ) == -1) { printf("shm rm error\n"); return -1; } } printf("run ok...\n"); return 0; } And the result: root:/> free total used free shared buffers Mem: 60320 17912 42408 0 0 -/+ buffers: 17912 42408 root:/> shmem run ok... root:/> free total used free shared buffers Mem: 60320 19096 41224 0 0 -/+ buffers: 19096 41224 root:/> shmem run ok... root:/> free total used free shared buffers Mem: 60320 20296 40024 0 0 -/+ buffers: 20296 40024 ... After this patch the test result is:(no memleak anymore) root:/> free total used free shared buffers Mem: 60320 16668 43652 0 0 -/+ buffers: 16668 43652 root:/> shmem run ok... root:/> free total used free shared buffers Mem: 60320 16668 43652 0 0 -/+ buffers: 16668 43652 Signed-off-by: Bob Liu Acked-by: Hugh Dickins Signed-off-by: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6f517d4325c1c1da7ec91b6cfd58c67a72c3b421 Author: Ben Hutchings Date: Thu Apr 14 15:22:21 2011 -0700 mm/thp: use conventional format for boolean attributes commit e27e6151b154ff6e5e8162efa291bc60196d29ea upstream. The conventional format for boolean attributes in sysfs is numeric ("0" or "1" followed by new-line). Any boolean attribute can then be read and written using a generic function. Using the strings "yes [no]", "[yes] no" (read), "yes" and "no" (write) will frustrate this. [akpm@linux-foundation.org: use kstrtoul()] [akpm@linux-foundation.org: test_bit() doesn't return 1/0, per Neil] Signed-off-by: Ben Hutchings Cc: Andrea Arcangeli Cc: Mel Gorman Cc: Johannes Weiner Cc: Rik van Riel Cc: Hugh Dickins Tested-by: David Rientjes Cc: NeilBrown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 280a1c38c907ab1e2617bdcef66de6bc70897253 Author: Alexey Dobriyan Date: Tue Mar 22 16:34:40 2011 -0700 kstrto*: converting strings to integers done (hopefully) right commit 33ee3b2e2eb9b4b6c64dcf9ed66e2ac3124e748c upstream. 1. simple_strto*() do not contain overflow checks and crufty, libc way to indicate failure. 2. strict_strto*() also do not have overflow checks but the name and comments pretend they do. 3. Both families have only "long long" and "long" variants, but users want strtou8() 4. Both "simple" and "strict" prefixes are wrong: Simple doesn't exactly say what's so simple, strict should not exist because conversion should be strict by default. The solution is to use "k" prefix and add convertors for more types. Enter kstrtoull() kstrtoll() kstrtoul() kstrtol() kstrtouint() kstrtoint() kstrtou64() kstrtos64() kstrtou32() kstrtos32() kstrtou16() kstrtos16() kstrtou8() kstrtos8() Include runtime testsuite (somewhat incomplete) as well. strict_strto*() become deprecated, stubbed to kstrto*() and eventually will be removed altogether. Use kstrto*() in code today! Note: on some archs _kstrtoul() and _kstrtol() are left in tree, even if they'll be unused at runtime. This is temporarily solution, because I don't want to hardcode list of archs where these functions aren't needed. Current solution with sizeof() and __alignof__ at least always works. Signed-off-by: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit db06752c7f64c445aeae2ae520a48c35e78789ed Author: Darren Hart Date: Thu Apr 14 15:41:57 2011 -0700 futex: Set FLAGS_HAS_TIMEOUT during futex_wait restart setup commit 0cd9c6494ee5c19aef085152bc37f3a4e774a9e1 upstream. The FLAGS_HAS_TIMEOUT flag was not getting set, causing the restart_block to restart futex_wait() without a timeout after a signal. Commit b41277dc7a18ee332d in 2.6.38 introduced the regression by accidentally removing the the FLAGS_HAS_TIMEOUT assignment from futex_wait() during the setup of the restart block. Restore the originaly behavior. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=32922 Reported-by: Tim Smith Reported-by: Torsten Hilbrich Signed-off-by: Darren Hart Signed-off-by: Eric Dumazet Cc: Peter Zijlstra Cc: John Kacur Link: http://lkml.kernel.org/r/%3Cdaac0eb3af607f72b9a4d3126b2ba8fb5ed3b883.1302820917.git.dvhart%40linux.intel.com%3E Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 5b00f4b47e31f38c965143036b37f3b436083fc2 Author: David S. Miller Date: Sat Feb 26 23:40:02 2011 -0800 sparc64: Fix build errors with gcc-4.6.0 [ Upstream commit c6fee0810df4e0f4cf9c4834d2569ca01c02cffc ] Most of the warnings emitted (we fail arch/sparc file builds with -Werror) were legitimate but harmless, however one case (n2_pcr_write) was a genuine bug. Based almost entirely upon a patch by Sam Ravnborg. Reported-by: Dennis Gilmore Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 790dcd55449886058b77e6c49fa8b3834568a8ed Author: Tkhai Kirill Date: Thu Mar 31 00:52:38 2011 -0700 sparc32: Pass task_struct to schedule_tail() in ret_from_fork [ Upstream commit 47c7c97a93a5b8f719093dbf83555090b3b8228b ] We have to pass task_struct of previous process to function schedule_tail(). Currently in ret_from_fork previous thread_info is passed: switch_to: mov %g6, %g3 /* previous thread_info in g6 */ ret_from_fork: call schedule_tail mov %g3, %o0 /* previous thread_info is passed */ void schedule_tail(struct task_struct *prev); Signed-off-by: Tkhai Kirill Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 247a80437d061450c5e9f371547aef4e34baec16 Author: David S. Miller Date: Wed Mar 9 13:00:47 2011 -0800 sparc32: Fix might-be-used-uninitialized warning in do_sparc_fault(). [ Upstream commit c816be7b5f24585baa9eba1f2413935f771d6ad6 ] When we try to handle vmalloc faults, we can take a code path which uses "code" before we actually set it. Amusingly gcc-3.3 notices this yet gcc-4.x does not. Reported-by: Bob Breuer Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 26a92fe2e4418a73b554c9e335840d424a2a4136 Author: Ben Hutchings Date: Wed Mar 9 12:54:27 2011 -0800 sparc: Fix .size directive for do_int_load [ Upstream commit 35043c428f1fcb92feb5792f5878a8852ee00771 ] gas used to accept (and ignore?) .size directives which referred to undefined symbols, as this does. In binutils 2.21 these are treated as errors. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5f1c356a3fadc0c19922d660da723b79bcc9aad7 Author: Herbert Xu Date: Fri Mar 18 05:27:28 2011 +0000 bridge: Reset IPCB when entering IP stack on NF_FORWARD [ Upstream commit 6b1e960fdbd75dcd9bcc3ba5ff8898ff1ad30b6e ] Whenever we enter the IP stack proper from bridge netfilter we need to ensure that the skb is in a form the IP stack expects it to be in. The entry point on NF_FORWARD did not meet the requirements of the IP stack, therefore leading to potential crashes/panics. This patch fixes the problem. Signed-off-by: Herbert Xu Acked-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 01b7e60bf848901c3a95794c90888e4e33ab751f Author: Eric Dumazet Date: Fri Mar 18 00:27:27 2011 +0000 vlan: should take into account needed_headroom [ Upstream commit d870bfb9d366c5d466c0f5419a4ec95a3f71ea8a ] Commit c95b819ad7 (gre: Use needed_headroom) made gre use needed_headroom instead of hard_header_len This uncover a bug in vlan code. We should make sure vlan devices take into account their real_dev->needed_headroom or we risk a crash in ipgre_header(), because we dont have enough room to push IP header in skb. Reported-by: Diddi Oscarsson Signed-off-by: Eric Dumazet Cc: Patrick McHardy Cc: Herbert Xu Acked-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e5a1f3787f4b43e828de2818faa6a0f658b87a63 Author: Steffen Klassert Date: Tue Mar 15 21:12:49 2011 +0000 xfrm: Refcount destination entry on xfrm_lookup [ Upstream commit fbd5060875d25f7764fd1c3d35b83a8ed1d88d7b ] We return a destination entry without refcount if a socket policy is found in xfrm_lookup. This triggers a warning on a negative refcount when freeeing this dst entry. So take a refcount in this case to fix it. This refcount was forgotten when xfrm changed to cache bundles instead of policies for outgoing flows. Signed-off-by: Steffen Klassert Acked-by: Timo Teräs Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit edc45d1e743b8b5a9366b7cafb53c80f4267fe1f Author: Yuchung Cheng Date: Mon Mar 14 10:57:03 2011 +0000 tcp: avoid cwnd moderation in undo [ Upstream commit 67d4120a1793138bc9f4a6eb61d0fc5298ed97e0 ] In the current undo logic, cwnd is moderated after it was restored to the value prior entering fast-recovery. It was moderated first in tcp_try_undo_recovery then again in tcp_complete_cwr. Since the undo indicates recovery was false, these moderations are not necessary. If the undo is triggered when most of the outstanding data have been acknowledged, the (restored) cwnd is falsely pulled down to a small value. This patch removes these cwnd moderations if cwnd is undone a) during fast-recovery b) by receiving DSACKs past fast-recovery Signed-off-by: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a83f2b584b54a123c408692eb19e0c97022be607 Author: David S. Miller Date: Wed Mar 30 17:51:36 2011 -0700 sctp: Pass __GFP_NOWARN to hash table allocation attempts. [ Upstream commit a84b50ceb7d640437d0dc28a2bef0d0de054de89 ] Like DCCP and other similar pieces of code, there are mechanisms here to try allocating smaller hash tables if the allocation fails. So pass in __GFP_NOWARN like the others do instead of emitting a scary message. Reported-by: Dave Jones Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 215f7206f540704ead83838eacef25ec13b763fb Author: Ulrich Weber Date: Wed Apr 6 14:04:49 2011 -0700 pppoe: drop PPPOX_ZOMBIEs in pppoe_flush_dev [ Upstream commit ae07b0b221b6ab2edf9e3abd518aec6cd3f1ba66 ] otherwise we loop forever if a PPPoE socket was set to PPPOX_ZOMBIE state by a PADT message when the ethernet device is going down afterwards. Signed-off-by: Ulrich Weber Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5d0fad1c60f42b4578ddbfd2ec54216f2f2155fc Author: Dan Siemon Date: Tue Mar 15 13:56:07 2011 +0000 net_sched: fix ip_tos2prio [ Upstream commit 4a2b9c3756077c05dd8666e458a751d2248b61b6 ] ECN support incorrectly maps ECN BESTEFFORT packets to TC_PRIO_FILLER (1) instead of TC_PRIO_BESTEFFORT (0) This means ECN enabled flows are placed in pfifo_fast/prio low priority band, giving ECN enabled flows [ECT(0) and CE codepoints] higher drop probabilities. This is rather unfortunate, given we would like ECN being more widely used. Ref : http://www.coverfire.com/archives/2011/03/13/pfifo_fast-and-ecn/ Signed-off-by: Dan Siemon Signed-off-by: Eric Dumazet Cc: Dave Täht Cc: Jonathan Morton Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 03700d4553b9401fa37c7d942bf7b58d6565fe21 Author: Eric W. Biederman Date: Mon Mar 21 18:23:34 2011 -0700 net ipv6: Fix duplicate /proc/sys/net/ipv6/neigh directory entries. [ Upstream commit 9d2a8fa96a44ba242de3a6f56acaef7a40a97b97 ] When I was fixing issues with unregisgtering tables under /proc/sys/net/ipv6/neigh by adding a mount point it appears I missed a critical ordering issue, in the ipv6 initialization. I had not realized that ipv6_sysctl_register is called at the very end of the ipv6 initialization and in particular after we call neigh_sysctl_register from ndisc_init. "neigh" needs to be initialized in ipv6_static_sysctl_register which is the first ipv6 table to initialized, and definitely before ndisc_init. This removes the weirdness of duplicate tables while still providing a "neigh" mount point which prevents races in sysctl unregistering. This was initially reported at https://bugzilla.kernel.org/show_bug.cgi?id=31232 Reported-by: sunkan@zappa.cx Signed-off-by: Eric W. Biederman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8f25b03628eee69953d729c09eb5d47e2dde6f28 Author: James Chapman Date: Mon Mar 21 18:10:25 2011 -0700 l2tp: fix possible oops on l2tp_eth module unload [ Upstream commit 8aa525a9340da4227797a06221ca08399006635f ] A struct used in the l2tp_eth driver for registering network namespace ops was incorrectly marked as __net_initdata, leading to oops when module unloaded. BUG: unable to handle kernel paging request at ffffffffa00ec098 IP: [] ops_exit_list+0x7/0x4b PGD 142d067 PUD 1431063 PMD 195da8067 PTE 0 Oops: 0000 [#1] SMP last sysfs file: /sys/module/l2tp_eth/refcnt Call Trace: [] ? unregister_pernet_operations+0x32/0x93 [] ? unregister_pernet_device+0x2b/0x38 [] ? sys_delete_module+0x1b8/0x222 [] ? do_munmap+0x254/0x318 [] ? page_fault+0x25/0x30 [] ? system_call_fastpath+0x16/0x1b Signed-off-by: James Chapman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 36063b029e5168c421666b9cd56dcd425ebbab4c Author: Alex Dubov Date: Wed Mar 16 17:57:13 2011 +0000 gianfar: Fall back to software tcp/udp checksum on older controllers [ Upstream commit 4363c2fddb1399b728ef21ee8101c148a311ea45 ] As specified by errata eTSEC49 of MPC8548 and errata eTSEC12 of MPC83xx, older revisions of gianfar controllers will be unable to calculate a TCP/UDP packet checksum for some alignments of the appropriate FCB. This patch checks for FCB alignment on such controllers and falls back to software checksumming if the alignment is known to be bad. Signed-off-by: Alex Dubov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 152f99e6e48538e4c4dc71a72d35888413b5ee92 Author: Eric Dumazet Date: Wed Mar 30 16:57:46 2011 -0700 fib: add rtnl locking in ip_fib_net_exit [ Upstream commit e2666f84958adb3a034b98e99699b55705117e01 ] Daniel J Blueman reported a lockdep splat in trie_firstleaf(), caused by RTNL being not locked before a call to fib_table_flush() Reported-by: Daniel J Blueman Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3e2b22819cdd86f0ad7fa61165d15e018ee96ad9 Author: Linus Lüssing Date: Tue Mar 22 11:40:32 2011 +0000 bridge: Fix possibly wrong MLD queries' ethernet source address [ Upstream commit a7bff75b087e7a355838a32efe61707cfa73c194 ] The ipv6_dev_get_saddr() is currently called with an uninitialized destination address. Although in tests it usually seemed to nevertheless always fetch the right source address, there seems to be a possible race condition. Therefore this commit changes this, first setting the destination address and only after that fetching the source address. Reported-by: Jan Beulich Signed-off-by: Linus Lüssing Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9ab7481b393d49efad749608fcbbceb90c9c5b07 Author: Peter Zijlstra Date: Thu Mar 31 10:29:26 2011 +0200 perf: Fix task context scheduling commit ab711fe08297de1485fff0a366e6db8828cafd6a upstream. Jiri reported: | | - once an event is created by sys_perf_event_open, task context | is created and it stays even if the event is closed, until the | task is finished ... thats what I see in code and I assume it's | correct | | - when the task opens event, perf_sched_events jump label is | incremented and following callbacks are started from scheduler | | __perf_event_task_sched_in | __perf_event_task_sched_out | | These callback *in/out set/unset cpuctx->task_ctx value to the | task context. | | - close is called on event on CPU 0: | - the task is scheduled on CPU 0 | - __perf_event_task_sched_in is called | - cpuctx->task_ctx is set | - perf_sched_events jump label is decremented and == 0 | - __perf_event_task_sched_out is not called | - cpuctx->task_ctx on CPU 0 stays set | | - exit is called on CPU 1: | - the task is scheduled on CPU 1 | - perf_event_exit_task is called | - task_ctx_sched_out unsets cpuctx->task_ctx on CPU 1 | - put_ctx destroys the context | | - another call of perf_rotate_context on CPU 0 will use invalid | task_ctx pointer, and eventualy panic. | Cure this the simplest possibly way by partially reverting the jump_label optimization for the sched_out case. Reported-and-tested-by: Jiri Olsa Signed-off-by: Peter Zijlstra Cc: Oleg Nesterov LKML-Reference: <1301520405.4859.213.camel@twins> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 8eb83708d2595c06de19d5a304eaf984ab7d31f0 Author: Artem Bityutskiy Date: Tue Mar 29 09:45:21 2011 +0300 UBIFS: fix assertion warnings commit c88ac00c5af70c2a0741da14b22cdcf8507ddd92 upstream. This patch fixes UBIFS assertion warnings like: UBIFS assert failed in ubifs_leb_unmap at 135 (pid 29365) Pid: 29365, comm: integck Tainted: G I 2.6.37-ubi-2.6+ #34 Call Trace: [] ubifs_lpt_init+0x95e/0x9ee [ubifs] [] ubifs_remount_fs+0x2c7/0x762 [ubifs] [] do_remount_sb+0xb6/0x101 [] ? do_mount+0x191/0x78e [] do_mount+0x258/0x78e [] ? alloc_pages_current+0xa2/0xc5 [] sys_mount+0x83/0xbd [] system_call_fastpath+0x16/0x1b They happen when we re-mount from R/O mode to R/W mode. While re-mounting, we write to the media, but we still have the c->ro_mount flag set. The fix is very simple - just clear the flag before starting re-mounting R/W. These warnings are caused by the following commit: 2ef13294d29bcfb306e0d360f1b97f37b647b0c0 For -stable guys: this bug was introduced in 2.6.38, this is materieal for 2.6.38-stable. Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit c2961b693a892ddc79c1548af50e92124f48cd1c Author: Linus Torvalds Date: Tue Apr 12 14:15:51 2011 -0700 vm: fix mlock() on stack guard page commit 95042f9eb78a8d9a17455e2ef263f2f310ecef15 upstream. Commit 53a7706d5ed8 ("mlock: do not hold mmap_sem for extended periods of time") changed mlock() to care about the exact number of pages that __get_user_pages() had brought it. Before, it would only care about errors. And that doesn't work, because we also handled one page specially in __mlock_vma_pages_range(), namely the stack guard page. So when that case was handled, the number of pages that the function returned was off by one. In particular, it could be zero, and then the caller would end up not making any progress at all. Rather than try to fix up that off-by-one error for the mlock case specially, this just moves the logic to handle the stack guard page into__get_user_pages() itself, thus making all the counts come out right automatically. Reported-by: Robert Święcki Cc: Hugh Dickins Cc: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f57e91ef4769159b5dd5c697afcf6cca22db46f5 Author: Jeff Mahoney Date: Thu Feb 24 17:23:09 2011 -0500 mca.c: Fix cast from integer to pointer warning commit c1d036c4d1cb00b7e8473a2ad0a78f13e13a8183 upstream. ia64_mca_cpu_init has a void *data local variable that is assigned the value from either __get_free_pages() or mca_bootmem(). The problem is that __get_free_pages returns an unsigned long and mca_bootmem, via alloc_bootmem(), returns a void *. format_mca_init_stack takes the void *, and it's also used with __pa(), but that casts it to long anyway. This results in the following build warning: arch/ia64/kernel/mca.c:1898: warning: assignment makes pointer from integer without a cast Cast the return of __get_free_pages to a void * to avoid the warning. Signed-off-by: Jeff Mahoney Signed-off-by: Tony Luck Signed-off-by: Greg Kroah-Hartman commit 98cf27b486964537b26a515ab91cb233d416e300 Author: Jeff Mahoney Date: Thu Feb 24 15:33:24 2011 -0500 tioca: Fix assignment from incompatible pointer warnings commit b4a6b3436531f6c5256e6d60d388c3c28ff1a0e9 upstream. The prototype for sn_pci_provider->{dma_map,dma_map_consistent} expects an unsigned long instead of a u64. Signed-off-by: Jeff Mahoney Signed-off-by: Tony Luck Signed-off-by: Greg Kroah-Hartman commit 3577818dd12f2908a6bdeb6283080d995f08f569 Author: Jan Beulich Date: Tue Mar 1 14:28:02 2011 +0000 x86: Fix a bogus unwind annotation in lib/semaphore_32.S commit e938c287ea8d977e079f07464ac69923412663ce upstream. 'simple' would have required specifying current frame address and return address location manually, but that's obviously not the case (and not necessary) here. Signed-off-by: Jan Beulich LKML-Reference: <4D6D1082020000780003454C@vpn.id2.novell.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 7795defc92b6977fbd4335f76a97ad087b02d953 Author: Jiri Slaby Date: Sun Mar 13 06:54:31 2011 +0000 NET: cdc-phonet, handle empty phonet header commit 468c3f924f043cad7a04f4f4d5224a2c9bc886c1 upstream. Currently, for N 5800 XM I get: cdc_phonet: probe of 1-6:1.10 failed with error -22 It's because phonet_header is empty. Extra altsetting looks like there: E 05 24 00 01 10 03 24 ab 05 24 06 0a 0b 04 24 fd .$....$..$....$. E 00 . I don't see the header used anywhere so just check if the phonet descriptor is there, not the structure itself. Signed-off-by: Jiri Slaby Cc: Rémi Denis-Courmont Cc: David S. Miller Acked-by: Rémi Denis-Courmont Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 58541cc27531727f7120683a7cb123ee3ada4bd4 Author: Takashi Iwai Date: Mon Mar 28 12:05:31 2011 +0200 ALSA: hda - Fix pin-config of Gigabyte mobo commit c6b358748e19ce7e230b0926ac42696bc485a562 upstream. Use pin-fix instead of the static quirk for Gigabyte mobos 1458:a002. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=677256 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 27a2ce012061fc1b12754136e2f64e060e01c904 Author: Vasiliy Kulikov Date: Fri Feb 4 15:24:19 2011 +0300 UBIFS: restrict world-writable debugfs files commit 8c559d30b4e59cf6994215ada1fe744928f494bf upstream. Don't allow everybody to dump sensitive information about filesystems. Signed-off-by: Vasiliy Kulikov Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 86d3c0e94b7cc32bd6ee638771fea5bf4360c039 Author: Vasiliy Kulikov Date: Fri Feb 4 09:23:33 2011 -0300 video: sn9c102: world-wirtable sysfs files commit 14ddc3188d50855ae2a419a6aced995e2834e5d4 upstream. Don't allow everybody to change video settings. Signed-off-by: Vasiliy Kulikov Acked-by: Mauro Carvalho Chehab Acked-by: Luca Risolia Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 3b76dafa88d04ea91e9b16a4cd7489977d60602b Author: Jeff Layton Date: Sat Apr 2 07:34:30 2011 -0400 cifs: wrap received signature check in srv_mutex commit 157c249114508aa71daa308a426e15d81a4eed00 upstream. While testing my patchset to fix asynchronous writes, I hit a bunch of signature problems when testing with signing on. The problem seems to be that signature checks on receive can be running at the same time as a process that is sending, or even that multiple receives can be checking signatures at the same time, clobbering the same data structures. While we're at it, clean up the comments over cifs_calculate_signature and add a note that the srv_mutex should be held when calling this function. This patch seems to fix the problems for me, but I'm not clear on whether it's the best approach. If it is, then this should probably go to stable too. Cc: Shirish Pargaonkar Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 591c80b5a9a9331a9b2a6d1b7d9b97d3445107c9 Author: Jeff Layton Date: Fri Mar 25 16:25:57 2011 -0400 cifs: set ra_pages in backing_dev_info commit 2b6c26a0a62cc0bab0ad487533d5581d7c293fef upstream. Commit 522440ed made cifs set backing_dev_info on the mapping attached to new inodes. This change caused a fairly significant read performance regression, as cifs started doing page-sized reads exclusively. By virtue of the fact that they're allocated as part of cifs_sb_info by kzalloc, the ra_pages on cifs BDIs get set to 0, which prevents any readahead. This forces the normal read codepaths to use readpage instead of readpages causing a four-fold increase in the number of read calls with the default rsize. Fix it by setting ra_pages in the BDI to the same value as that in the default_backing_dev_info. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=31662 Reported-and-Tested-by: Till Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 7cb41edf395b70a6e48162382c5577967ce92bbf Author: Jeff Layton Date: Tue Apr 5 16:23:47 2011 -0700 cifs: check for private_data before trying to put it commit 7797069305d13252fd66cf722aa8f2cbeb3c95cd upstream. cifs_close doesn't check that the filp->private_data is non-NULL before trying to put it. That can cause an oops in certain error conditions that can occur on open or lookup before the private_data is set. Reported-by: Ben Greear Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 1bd6bcd950ab6bd208a4748ff593d612a21b4284 Author: Jeff Layton Date: Mon Mar 14 13:48:08 2011 -0400 cifs: always do is_path_accessible check in cifs_mount commit 70945643722ffeac779d2529a348f99567fa5c33 upstream. Currently, we skip doing the is_path_accessible check in cifs_mount if there is no prefixpath. I have a report of at least one server however that allows a TREE_CONNECT to a share that has a DFS referral at its root. The reporter in this case was using a UNC that had no prefixpath, so the is_path_accessible check was not triggered and the box later hit a BUG() because we were chasing a DFS referral on the root dentry for the mount. This patch fixes this by removing the check for a zero-length prefixpath. That should make the is_path_accessible check be done in this situation and should allow the client to chase the DFS referral at mount time instead. Reported-and-Tested-by: Yogesh Sharma Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 9b659653fa4b6fc626ba31f82c7cb57e6bdd6089 Author: Alex Deucher Date: Tue Apr 12 13:33:27 2011 -0400 drm/radeon/kms: fix suspend on rv530 asics commit 71e16bfbd2b1c63d4d97cc5059694c9346aee340 upstream. Apparently only rv515 asics need the workaround added in f24d86f1a49505cdea56728b853a5d0a3f8e3d11 (drm/radeon/kms: fix resume regression for some r5xx laptops). Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=34709 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 5ce1071c2390f8a27569bf9b41f8038ded424dff Author: Alex Deucher Date: Thu Apr 7 10:31:25 2011 -0400 drm/radeon/kms: pll tweaks for rv6xx commit 9bb09fa1b5b07459279301ac6220d575f307597b upstream. Prefer minm over maxp. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=35994 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 833923adc70f9493f0860ffff7e326612c1ff513 Author: Linus Torvalds Date: Wed Apr 13 08:07:28 2011 -0700 vm: fix vm_pgoff wrap in stack expansion commit a626ca6a656450e9f4df91d0dda238fff23285f4 upstream. Commit 982134ba6261 ("mm: avoid wrapping vm_pgoff in mremap()") fixed the case of a expanding mapping causing vm_pgoff wrapping when you used mremap. But there was another case where we expand mappings hiding in plain sight: the automatic stack expansion. This fixes that case too. This one also found by Robert Święcki, using his nasty system call fuzzer tool. Good job. Reported-and-tested-by: Robert Święcki Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman