commit 744f2110ae5939ebb75b2a3dd57ec64708481f82 Author: Paul Gortmaker Date: Thu May 17 11:27:28 2012 -0400 Linux 2.6.34.12 Signed-off-by: Paul Gortmaker commit 187085210aa7f9202cf420b8a5719054e8d9ae17 Author: Jonathan Nieder Date: Tue Feb 28 15:31:35 2012 -0600 x86/PCI: do not tie MSI MS-7253 use_crs quirk to BIOS version commit a97f4f5e524bcd09a85ef0b8821a14d35e69335f upstream. Carlos was getting WARNING: at drivers/pci/pci.c:118 pci_ioremap_bar+0x24/0x52() when probing his sound card, and sound did not work. After adding pci=use_crs to the kernel command line, no more trouble. Ok, we can add a quirk. dmidecode output reveals that this is an MSI MS-7253, for which we already have a quirk, but the short-sighted author tied the quirk to a single BIOS version, making it not kick in on Carlos's machine with BIOS V1.2. If a later BIOS update makes it no longer necessary to look at the _CRS info it will still be harmless, so let's stop trying to guess which versions have and don't have accurate _CRS tables. Addresses https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5533 Also see . Reported-by: Carlos Luna Reviewed-by: Bjorn Helgaas Signed-off-by: Jonathan Nieder Signed-off-by: Jesse Barnes Signed-off-by: Paul Gortmaker commit 5e33501e2ecdc2db7bea5f6735fefb87ca1aaebc Author: Jonathan Nieder Date: Tue Feb 28 11:51:10 2012 -0700 x86/PCI: use host bridge _CRS info on MSI MS-7253 commit 8411371709610c826bf65684f886bfdfb5780ca1 upstream. In the spirit of commit 29cf7a30f8a0 ("x86/PCI: use host bridge _CRS info on ASUS M2V-MX SE"), this DMI quirk turns on "pci_use_crs" by default on a board that needs it. This fixes boot failures and oopses introduced in 3e3da00c01d0 ("x86/pci: AMD one chain system to use pci read out res"). The quirk is quite targetted (to a specific board and BIOS version) for two reasons: (1) to emphasize that this method of tackling the problem one quirk at a time is a little insane (2) to give BIOS vendors an opportunity to use simpler tables and allow us to return to generic behavior (whatever that happens to be) with a later BIOS update In other words, I am not at all happy with having quirks like this. But it is even worse for the kernel not to work out of the box on these machines, so... Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42619 Reported-by: Svante Signell Signed-off-by: Jonathan Nieder Signed-off-by: Bjorn Helgaas Signed-off-by: Jesse Barnes Signed-off-by: Paul Gortmaker commit 861743b9f32cdf4d3e4af10a2c4f13ad9001c9f2 Author: Dan Rosenberg Date: Fri Jan 20 14:34:27 2012 -0800 score: fix off-by-one index into syscall table commit c25a785d6647984505fa165b5cd84cfc9a95970b upstream. If the provided system call number is equal to __NR_syscalls, the current check will pass and a function pointer just after the system call table may be called, since sys_call_table is an array with total size __NR_syscalls. Whether or not this is a security bug depends on what the compiler puts immediately after the system call table. It's likely that this won't do anything bad because there is an additional NULL check on the syscall entry, but if there happens to be a non-NULL value immediately after the system call table, this may result in local privilege escalation. Signed-off-by: Dan Rosenberg Cc: Cc: Chen Liqin Cc: Lennox Wu Cc: Eugene Teo Cc: Arnd Bergmann Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit aac3f5904beea76bcd6da3e047586f4f3b0f0179 Author: Andres Salomon Date: Tue Nov 9 14:10:38 2010 -0800 tty: fix warning in synclink driver commit dc98d9650891661a20842a8eef9e76536046d897 upstream. During builds I see the following warning - CC [M] drivers/char/pcmcia/synclink_cs.o drivers/char/pcmcia/synclink_cs.c:2194: warning: ‘mgslpc_get_icount’ defined but not used The function is a callback meant to be assigned to get_icount (added during 0587102cf). Fix accordingly. Signed-off-by: Andres Salomon Acked-by: Alan Cox Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit d5bc8dade94aee3483960f4fa015b88d1764d982 Author: Alan Cox Date: Tue Oct 26 15:56:34 2010 +0100 nozomi: Fix warning from the previous TIOCGCOUNT changes commit 68e29655cc51761d60d5f27b2738816a5b13e415 upstream. Just remove a now unused variable Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit cf7ac236a8a97410d084ff15957b43449ae88d46 Author: Alan Cox Date: Thu Sep 16 18:21:52 2010 +0100 tty: icount changeover for other main devices commit 0587102cf9f427c185bfdeb2cef41e13ee0264b1 upstream. Again basically cut and paste Convert the main driver set to use the hooks for GICOUNT Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit ae64ec88e2f05594a92cdff0ee8f5b4582b2daf8 Author: Alan Cox Date: Thu Sep 16 18:21:24 2010 +0100 tty: Make tiocgicount a handler commit d281da7ff6f70efca0553c288bb883e8605b3862 upstream. Dan Rosenberg noted that various drivers return the struct with uncleared fields. Instead of spending forever trying to stomp all the drivers that get it wrong (and every new driver) do the job in one place. This first patch adds the needed operations and hooks them up, including the needed USB midlayer and serial core plumbing. Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 187979ee305a6ac1939daeb90e6446182f5e1617 Author: Carolyn Wyborny Date: Sat Jun 25 13:18:12 2011 +0000 igb: Fix lack of flush after register write and before delay commit 064b43304ed8ede8e13ff7b4338d09fd37bcffb1 upstream. Register writes followed by a delay are required to have a flush before the delay in order to commit the values to the register. Without the flush, the code following the delay may not function correctly. Reported-by: Tong Ho Reported-by: Guenter Roeck Signed-off-by: Carolyn Wyborny Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Paul Gortmaker commit 0b55eccde1145e8e2b31fe855cdba3987676beb8 Author: Miklos Szeredi Date: Wed Aug 24 10:20:17 2011 +0200 fuse: check size of FUSE_NOTIFY_INVAL_ENTRY message commit c2183d1e9b3f313dd8ba2b1b0197c8d9fb86a7ae upstream. FUSE_NOTIFY_INVAL_ENTRY didn't check the length of the write so the message processing could overrun and result in a "kernel BUG at fs/fuse/dev.c:629!" Reported-by: Han-Wen Nienhuys Signed-off-by: Miklos Szeredi Signed-off-by: Paul Gortmaker commit 1c0f1dabcdd6dd6d03e797e097b0bc061f419691 Author: Marcin Slusarz Date: Mon Aug 22 21:17:57 2011 +0000 drm/ttm: fix ttm_bo_add_ttm(user) failure path commit 7c4c3960dff109bc5db4c35da481c212dadb5eb5 upstream. ttm_tt_destroy kfrees passed object, so we need to nullify a reference to it. Signed-off-by: Marcin Slusarz Reviewed-by: Thomas Hellstrom Signed-off-by: Dave Airlie Signed-off-by: Paul Gortmaker commit ba837d47c5a6fff2a5184eecb270aee44e8f8cff Author: Jack Steiner Date: Fri Aug 5 09:09:00 2011 -0500 x86, UV: Remove UV delay in starting slave cpus commit 05e33fc20ea5e493a2a1e7f1d04f43cdf89f83ed upstream. Delete the 10 msec delay between the INIT and SIPI when starting slave cpus. I can find no requirement for this delay. BIOS also has similar code sequences without the delay. Removing the delay reduces boot time by 40 sec. Every bit helps. Signed-off-by: Jack Steiner Link: http://lkml.kernel.org/r/20110805140900.GA6774@sgi.com Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit 7fce11cc92960743baefbd224fc14613e4ed8d5a Author: H. Peter Anvin Date: Mon Aug 22 13:27:06 2011 -0700 x86-32, vdso: On system call restart after SYSENTER, use int $0x80 commit 7ca0758cdb7c241cb4e0490a8d95f0eb5b861daf upstream. When we enter a 32-bit system call via SYSENTER or SYSCALL, we shuffle the arguments to match the int $0x80 calling convention. This was probably a design mistake, but it's what it is now. This causes errors if the system call as to be restarted. For SYSENTER, we have to invoke the instruction from the vdso as the return address is hardcoded. Accordingly, we can simply replace the jump in the vdso with an int $0x80 instruction and use the slower entry point for a post-restart. Suggested-by: Linus Torvalds Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/r/CA%2B55aFztZ=r5wa0x26KJQxvZOaQq8s2v3u50wCyJcA-Sc4g8gQ@mail.gmail.com Signed-off-by: Paul Gortmaker commit 1c167cc569a11e733ebf431719a9b3d5721a516d Author: Hugh Dickins Date: Sat Dec 31 11:44:01 2011 -0800 futex: Fix uninterruptible loop due to gate_area commit e6780f7243eddb133cc20ec37fa69317c218b709 upstream. It was found (by Sasha) that if you use a futex located in the gate area we get stuck in an uninterruptible infinite loop, much like the ZERO_PAGE issue. While looking at this problem, PeterZ realized you'll get into similar trouble when hitting any install_special_pages() mapping. And are there still drivers setting up their own special mmaps without page->mapping, and without special VM or pte flags to make get_user_pages fail? In most cases, if page->mapping is NULL, we do not need to retry at all: Linus points out that even /proc/sys/vm/drop_caches poses no problem, because it ends up using remove_mapping(), which takes care not to interfere when the page reference count is raised. But there is still one case which does need a retry: if memory pressure called shmem_writepage in between get_user_pages_fast dropping page table lock and our acquiring page lock, then the page gets switched from filecache to swapcache (and ->mapping set to NULL) whatever the refcount. Fault it back in to get the page->mapping needed for key->shared.inode. Reported-by: Sasha Levin Signed-off-by: Hugh Dickins Signed-off-by: Linus Torvalds [PG: 2.6.34 variable is page, not page_head, since it doesn't have a5b338f2] Signed-off-by: Paul Gortmaker commit 80fe4269ca09149e523f68fb65872fee9989c3d6 Author: Shawn Bohrer Date: Thu Jun 30 11:21:32 2011 -0500 futex: Fix regression with read only mappings commit 9ea71503a8ed9184d2d0b8ccc4d269d05f7940ae upstream. commit 7485d0d3758e8e6491a5c9468114e74dc050785d (futexes: Remove rw parameter from get_futex_key()) in 2.6.33 fixed two problems: First, It prevented a loop when encountering a ZERO_PAGE. Second, it fixed RW MAP_PRIVATE futex operations by forcing the COW to occur by unconditionally performing a write access get_user_pages_fast() to get the page. The commit also introduced a user-mode regression in that it broke futex operations on read-only memory maps. For example, this breaks workloads that have one or more reader processes doing a FUTEX_WAIT on a futex within a read only shared file mapping, and a writer processes that has a writable mapping issuing the FUTEX_WAKE. This fixes the regression for valid futex operations on RO mappings by trying a RO get_user_pages_fast() when the RW get_user_pages_fast() fails. This change makes it necessary to also check for invalid use cases, such as anonymous RO mappings (which can never change) and the ZERO_PAGE which the commit referenced above was written to address. This patch does restore the original behavior with RO MAP_PRIVATE mappings, which have inherent user-mode usage problems and don't really make sense. With this patch performing a FUTEX_WAIT within a RO MAP_PRIVATE mapping will be successfully woken provided another process updates the region of the underlying mapped file. However, the mmap() man page states that for a MAP_PRIVATE mapping: It is unspecified whether changes made to the file after the mmap() call are visible in the mapped region. So user-mode users attempting to use futex operations on RO MAP_PRIVATE mappings are depending on unspecified behavior. Additionally a RO MAP_PRIVATE mapping could fail to wake up in the following case. Thread-A: call futex(FUTEX_WAIT, memory-region-A). get_futex_key() return inode based key. sleep on the key Thread-B: call mprotect(PROT_READ|PROT_WRITE, memory-region-A) Thread-B: write memory-region-A. COW happen. This process's memory-region-A become related to new COWed private (ie PageAnon=1) page. Thread-B: call futex(FUETX_WAKE, memory-region-A). get_futex_key() return mm based key. IOW, we fail to wake up Thread-A. Once again doing something like this is just silly and users who do something like this get what they deserve. While RO MAP_PRIVATE mappings are nonsensical, checking for a private mapping requires walking the vmas and was deemed too costly to avoid a userspace hang. This Patch is based on Peter Zijlstra's initial patch with modifications to only allow RO mappings for futex operations that need VERIFY_READ access. Reported-by: David Oliver Signed-off-by: Shawn Bohrer Acked-by: Peter Zijlstra Signed-off-by: Darren Hart Cc: KOSAKI Motohiro Cc: peterz@infradead.org Cc: eric.dumazet@gmail.com Cc: zvonler@rgmadvisors.com Cc: hughd@google.com Link: http://lkml.kernel.org/r/1309450892-30676-1-git-send-email-sbohrer@rgmadvisors.com Signed-off-by: Thomas Gleixner [PG: in 34, the variable is "page"; in original 9ea71503a it is page_head] Signed-off-by: Paul Gortmaker commit be4275ed5b3d92db920dc9ab2c1ab814df4fecc0 Author: Daniel T Chen Date: Sun Aug 14 22:43:01 2011 -0400 ALSA: ac97: Add HP Compaq dc5100 SFF(PT003AW) to Headphone Jack Sense whitelist commit eade7b281c9fc18401b989c77d5e5e660b25a3b7 upstream. BugLink: https://bugs.launchpad.net/bugs/826081 The original reporter needs 'Headphone Jack Sense' enabled to have audible audio, so add his PCI SSID to the whitelist. Reported-and-tested-by: Muhammad Khurram Khan Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit cccda14532dfd2a1bc5e33c38310abe333051ed1 Author: Daniel Mack Date: Sun Aug 14 11:31:16 2011 +0200 ALSA: snd_usb_caiaq: track submitted output urbs commit da6094ea7d3c2295473d8f5134279307255d6ebf upstream. The snd_usb_caiaq driver currently assumes that output urbs are serviced in time and doesn't track when and whether they are given back by the USB core. That usually works fine, but due to temporary limitations of the XHCI stack, we faced that urbs were submitted more than once with this approach. As it's no good practice to fire and forget urbs anyway, this patch introduces a proper bit mask to track which requests have been submitted and given back. That alone however doesn't make the driver work in case the host controller is broken and doesn't give back urbs at all, and the output stream will stop once all pre-allocated output urbs are consumed. But it does prevent crashes of the controller stack in such cases. See http://bugzilla.kernel.org/show_bug.cgi?id=40702 for more details. Signed-off-by: Daniel Mack Reported-and-tested-by: Matej Laitl Cc: Sarah Sharp Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 64876634aaf6e8c96f563377cc599852ec08cd88 Author: Jonathan Nieder Date: Fri Aug 5 18:58:38 2011 +0200 perf tools: do not look at ./config for configuration commit aba8d056078e47350d85b06a9cabd5afcc4b72ea upstream. In addition to /etc/perfconfig and $HOME/.perfconfig, perf looks for configuration in the file ./config, imitating git which looks at $GIT_DIR/config. If ./config is not a perf configuration file, it fails, or worse, treats it as a configuration file and changes behavior in some unexpected way. "config" is not an unusual name for a file to be lying around and perf does not have a private directory dedicated for its own use, so let's just stop looking for configuration in the cwd. Callers needing context-sensitive configuration can use the PERF_CONFIG environment variable. Requested-by: Christian Ohm Cc: 632923@bugs.debian.org Cc: Ben Hutchings Cc: Christian Ohm Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20110805165838.GA7237@elie.gateway.2wire.net Signed-off-by: Jonathan Nieder Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Paul Gortmaker commit ce155aef38b34229305e55e5690c281633a32e61 Author: Clemens Ladisch Date: Tue Jun 21 22:09:50 2011 +0200 mm: fix wrong vmap address calculations with odd NR_CPUS values commit f982f91516fa4cfd9d20518833cd04ad714585be upstream. Commit db64fe02258f ("mm: rewrite vmap layer") introduced code that does address calculations under the assumption that VMAP_BLOCK_SIZE is a power of two. However, this might not be true if CONFIG_NR_CPUS is not set to a power of two. Wrong vmap_block index/offset values could lead to memory corruption. However, this has never been observed in practice (or never been diagnosed correctly); what caught this was the BUG_ON in vb_alloc() that checks for inconsistent vmap_block indices. To fix this, ensure that VMAP_BLOCK_SIZE always is a power of two. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=31572 Reported-by: Pavel Kysilka Reported-by: Matias A. Fonzo Signed-off-by: Clemens Ladisch Signed-off-by: Stefan Richter Cc: Nick Piggin Cc: Jeremy Fitzhardinge Cc: Krzysztof Helt Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 014b2ceb4ba5dae43f3f3e007a6ea919ce6ea2ed Author: Daniel Mack Date: Fri Aug 5 13:49:52 2011 +0200 ALSA: snd-usb-caiaq: Correct offset fields of outbound iso_frame_desc commit 15439bde3af7ff88459ea2b5520b77312e958df2 upstream. This fixes faulty outbount packets in case the inbound packets received from the hardware are fragmented and contain bogus input iso frames. The bug has been there for ages, but for some strange reasons, it was only triggered by newer machines in 64bit mode. Signed-off-by: Daniel Mack Reported-and-tested-by: William Light Reported-by: Pedro Ribeiro Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit c22f94701e1e10a253e9e9b5f14e6d397dce9f53 Author: Julia Lawall Date: Tue Aug 9 11:10:56 2011 -0400 hwmon: (ibmaem) add missing kfree commit 66a89b2164e2d30661edbd1953eacf0594d8203a upstream. rs_resp is dynamically allocated in aem_read_sensor(), so it should be freed before exiting in every case. This collects the kfree and the return at the end of the function. Signed-off-by: Julia Lawall Signed-off-by: Guenter Roeck Signed-off-by: Paul Gortmaker commit 011449930966f7f203814020ae9f910af49282a6 Author: Chas Williams Date: Mon Aug 1 17:56:14 2011 -0700 atm: br2864: sent packets truncated in VC routed mode commit a08af810cdc29d2ca930e8a869d3d01744c392d8 upstream. Reported-by: Pascal Hambourg Signed-off-by: Chas Williams Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 3c3340a7ccf7ed974e32434fe251bf86472a8a7b Author: Vijay Chavan Date: Tue Aug 9 02:41:12 2011 +0530 USB: Serial: Added device ID for Qualcomm Modem in Sagemcom's HiLo3G commit e468561739fffb972d486b98f66c723936335136 upstream. A new device ID pair is added for Qualcomm Modem present in Sagemcom's HiLo3G module. Signed-off-by: Vijay Chavan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 8e38c1a6966ee3441bda0116db6881d0f78e2d42 Author: Nick Bowler Date: Wed Jul 13 11:40:09 2011 -0400 USB: usb-storage: unusual_devs entry for ARM V2M motherboard. commit a871e4f5519d8c52430052e1d340dd5710eb5ad6 upstream. Connecting the V2M to a Linux host results in a constant stream of errors spammed to the console, all of the form sd 1:0:0:0: ioctl_internal_command return code = 8070000 : Sense Key : 0x4 [current] : ASC=0x0 ASCQ=0x0 The errors appear to be otherwise harmless. Add an unusual_devs entry which eliminates all of the error messages. Signed-off-by: Nick Bowler Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman [PG: 2.6.34 uses US_ prefix, not USB_ prefix, change accordingly] Signed-off-by: Paul Gortmaker commit 2033b34e20cc32c182d2605a6eb8480e4b296be3 Author: Maxim Nikulin Date: Sat Jul 9 23:44:44 2011 +0700 USB: assign instead of equal in usbtmc.c commit 4f1a7a3e78037721496283ea3e87cfefc64d99c7 upstream. Assign operator instead of equality test in the usbtmc_ioctl_abort_bulk_in() function. Signed-off-by: Maxim A. Nikulin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 4d59426ba4b9697f69ef607b2a628b201cda204d Author: JiSheng Zhang Date: Sat Jul 16 11:04:19 2011 +0800 USB: xhci: fix OS want to own HC commit 6768458b17f9bf48a4c3a34e49b20344091b5f7e upstream. Software should set XHCI_HC_OS_OWNED bit to request ownership of xHC. This patch should be backported to kernels as far back as 2.6.31. Signed-off-by: JiSheng Zhang Signed-off-by: Sarah Sharp Signed-off-by: Paul Gortmaker commit 115a1e2450fe99918a39fe79cd2de79b4ad012e5 Author: Anton Blanchard Date: Tue Jul 26 18:15:03 2011 +0000 powerpc: pseries: Fix kexec on machines with more than 4TB of RAM commit bed9a31527af8ff3dfbad62a1a42815cef4baab7 upstream. On a box with 8TB of RAM the MMU hashtable is 64GB in size. That means we have 4G PTEs. pSeries_lpar_hptab_clear was using a signed int to store the index which will overflow at 2G. Signed-off-by: Anton Blanchard Acked-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Paul Gortmaker commit 669dd2167117e1e985ff51a22dce32b48f5009ba Author: Anton Blanchard Date: Mon Jul 25 20:47:07 2011 +0000 powerpc: Fix device tree claim code commit 966728dd88b4026ec58fee169ccceaeaf56ef120 upstream. I have a box that fails in OF during boot with: DEFAULT CATCH!, exception-handler=fff00400 at %SRR0: 49424d2c4c6f6768 %SRR1: 800000004000b002 ie "IBM,Logh". OF got corrupted with a device tree string. Looking at make_room and alloc_up, we claim the first chunk (1 MB) but we never claim any more. mem_end is always set to alloc_top which is the top of our available address space, guaranteeing we will never call alloc_up and claim more memory. Also alloc_up wasn't setting alloc_bottom to the bottom of the available address space. This doesn't help the box to boot, but we at least fail with an obvious error. We could relocate the device tree in a future patch. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Paul Gortmaker commit efc2db65dc132ef8626a96d3594bbebabb9f0b5a Author: Daniel Mack Date: Sat Aug 6 09:13:08 2011 +0200 ALSA: snd-usb-caiaq: Fix keymap for RigKontrol3 commit f4389489b5cbe60b3441869c68bb4afe760969c4 upstream. Signed-off-by: Daniel Mack Reported-by: Renato Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 1b9e5abe55f28d4b104d398347e680f2b040e0ca Author: Takashi Iwai Date: Mon Aug 8 12:24:46 2011 +0200 ALSA: timer - Fix Oops at closing slave timer commit 0584ffa548b6e59aceb027112f23a55f0133400e upstream. A slave-timer instance has no timer reference, and this results in NULL-dereference at stopping the timer, typically called at closing the device. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=40682 Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 41fc877e94ead29c23b76601f420e3a3315a9375 Author: David S. Miller Date: Wed Aug 3 20:50:44 2011 -0700 net: Compute protocol sequence numbers and fragment IDs using MD5. commit 6e5714eaf77d79ae1c8b47e3e040ff5411b717ec upstream. Computers have become a lot faster since we compromised on the partial MD4 hash which we use currently for performance reasons. MD5 is a much safer choice, and is inline with both RFC1948 and other ISS generators (OpenBSD, Solaris, etc.) Furthermore, only having 24-bits of the sequence number be truly unpredictable is a very serious limitation. So the periodic regeneration and 8-bit counter have been removed. We compute and use a full 32-bit sequence number. For ipv6, DCCP was found to use a 32-bit truncated initial sequence number (it needs 43-bits) and that is fixed here as well. Reported-by: Dan Kaminsky Tested-by: Willy Tarreau Signed-off-by: David S. Miller [PG: diffstat vs. 6e5714 differs, since no secure_ipv6_id to delete in 34] Signed-off-by: Paul Gortmaker commit 5b2354949698f8b39468889393ebaa495b6ca852 Author: David S. Miller Date: Wed Aug 3 19:45:10 2011 -0700 crypto: Move md5_transform to lib/md5.c commit bc0b96b54a21246e377122d54569eef71cec535f upstream. We are going to use this for TCP/IP sequence number and fragment ID generation. Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 8fc7676bfb45d55222aa5f663f113f723b9197b8 Author: Thomas Gleixner Date: Mon Dec 13 12:43:23 2010 +0100 x86: HPET: Chose a paranoid safe value for the ETIME check commit f1c18071ad70e2a78ab31fc26a18fcfa954a05c6 upstream. commit 995bd3bb5 (x86: Hpet: Avoid the comparator readback penalty) chose 8 HPET cycles as a safe value for the ETIME check, as we had the confirmation that the posted write to the comparator register is delayed by two HPET clock cycles on Intel chipsets which showed readback problems. After that patch hit mainline we got reports from machines with newer AMD chipsets which seem to have an even longer delay. See http://thread.gmane.org/gmane.linux.kernel/1054283 and http://thread.gmane.org/gmane.linux.kernel/1069458 for further information. Boris tried to come up with an ACPI based selection of the minimum HPET cycles, but this failed on a couple of test machines. And of course we did not get any useful information from the hardware folks. For now our only option is to chose a paranoid high and safe value for the minimum HPET cycles used by the ETIME check. Adjust the minimum ns value for the HPET clockevent accordingly. Reported-Bistected-and-Tested-by: Markus Trippelsdorf Signed-off-by: Thomas Gleixner LKML-Reference: Cc: Simon Kirby Cc: Borislav Petkov Cc: Andreas Herrmann Cc: John Stultz Signed-off-by: Paul Gortmaker commit 296da318f2e9457fa93267deabf02883770f6072 Author: Thomas Gleixner Date: Wed Sep 15 15:11:57 2010 +0200 x86: Hpet: Avoid the comparator readback penalty commit 995bd3bb5c78f3ff71339803c0b8337ed36d64fb upstream. Due to the overly intelligent design of HPETs, we need to workaround the problem that the compare value which we write is already behind the actual counter value at the point where the value hits the real compare register. This happens for two reasons: 1) We read out the counter, add the delta and write the result to the compare register. When a NMI or SMI hits between the read out and the write then the counter can be ahead of the event already 2) The write to the compare register is delayed by up to two HPET cycles in certain chipsets. We worked around this by reading back the compare register to make sure that the written value has hit the hardware. For certain ICH9+ chipsets this can require two readouts, as the first one can return the previous compare register value. That's bad performance wise for the normal case where the event is far enough in the future. As we already know that the write can be delayed by up to two cycles we can avoid the read back of the compare register completely if we make the decision whether the delta has elapsed already or not based on the following calculation: cmp = event - actual_count; If cmp is less than 8 HPET clock cycles, then we decide that the event has happened already and return -ETIME. That covers the above #1 and seconds). Signed-off-by: Thomas Gleixner Tested-by: Nix Tested-by: Artur Skawina Cc: Damien Wyart Tested-by: John Drescher Cc: Venkatesh Pallipadi Cc: Arjan van de Ven Cc: Andreas Herrmann Tested-by: Borislav Petkov Cc: Suresh Siddha LKML-Reference: [PG: diffstat differs from 995bd3bb since deleted comment was re-wrapped] Signed-off-by: Paul Gortmaker commit 385a7c219d5283f6d8884fa511e18bb23ac7e458 Author: Alasdair G Kergon Date: Tue Aug 2 12:32:01 2011 +0100 dm: fix idr leak on module removal commit d15b774c2920d55e3d58275c97fbe3adc3afde38 upstream. Destroy _minor_idr when unloading the core dm module. (Found by kmemleak.) Signed-off-by: Alasdair G Kergon Signed-off-by: Paul Gortmaker commit 87427757d68880e51cfd8ab45ae38b0e8f90ce78 Author: Mike Snitzer Date: Tue Aug 2 12:32:00 2011 +0100 dm mpath: fix potential NULL pointer in feature arg processing commit 286f367dad40beb3234a18c17391d03ba939a7f3 upstream. Avoid dereferencing a NULL pointer if the number of feature arguments supplied is fewer than indicated. Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Signed-off-by: Paul Gortmaker commit 49af9715585616b3a8eb12ac1da419ce1affae80 Author: Julia Lawall Date: Thu Jul 28 14:46:05 2011 +0200 ALSA: sound/core/pcm_compat.c: adjust array index commit ca9380fd68514c7bc952282c1b4fc70607e9fe43 upstream. Convert array index from the loop bound to the loop index. A simplified version of the semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression e1,e2,ar; @@ for(e1 = 0; e1 < e2; e1++) { <... ar[ - e2 + e1 ] ...> } // Signed-off-by: Julia Lawall Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 6499cb67e72099ac21ac91ee8e52184c22f31b50 Author: Vasiliy Kulikov Date: Fri Jun 24 16:08:38 2011 +0400 proc: restrict access to /proc/PID/io commit 1d1221f375c94ef961ba8574ac4f85c8870ddd51 upstream. /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. Signed-off-by: Vasiliy Kulikov Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 574aa6e1fe232a513708576342db58a4d11724d2 Author: Dan Rosenberg Date: Wed Jun 15 15:09:01 2011 -0700 alpha: fix several security issues commit 21c5977a836e399fc710ff2c5367845ed5c2527f upstream. 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. 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: Paul Gortmaker commit c29d4fb16638de318ac8158a3aa9c6440b32c034 Author: Jeff Layton Date: Mon Aug 23 11:38:04 2010 -0400 cifs: check for NULL session password commit 24e6cf92fde1f140d8eb0bf7cd24c2c78149b6b2 upstream. It's possible for a cifsSesInfo struct to have a NULL password, so we need to check for that prior to running strncmp on it. Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Paul Gortmaker commit 8154cce6e60779e8e09b79f692344f6d4a9bfd08 Author: Jeff Layton Date: Wed Aug 18 13:13:39 2010 -0400 cifs: fix NULL pointer dereference in cifs_find_smb_ses commit fc87a40677bbe0937e2ff0642c7e83c9a4813f3d upstream. cifs_find_smb_ses assumes that the vol->password field is a valid pointer, but that's only the case if a password was passed in via the options string. It's possible that one won't be if there is no mount helper on the box. Reported-by: diabel Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Paul Gortmaker commit 88720224330a655ab6268e20109b65b11cfd7f6a Author: Jeff Layton Date: Tue Jul 6 20:43:02 2010 -0400 cifs: clean up cifs_find_smb_ses (try #2) commit 4ff67b720c02c36e54d55b88c2931879b7db1cd2 upstream. This patch replaces the earlier patch by the same name. The only difference is that MAX_PASSWORD_SIZE has been increased to attempt to match the limits that windows enforces. Do a better job of matching sessions by authtype. Matching by username for a Kerberos session is incorrect, and anonymous sessions need special handling. Also, in the case where we do match by username, we also need to match by password. That ensures that someone else doesn't "borrow" an existing session without needing to know the password. Finally, passwords can be longer than 16 bytes. Bump MAX_PASSWORD_SIZE to 512 to match the size that the userspace mount helper allows. Signed-off-by: Jeff Layton Signed-off-by: Steve French [PG: origin vs. in 2.6.34; ses <-- pSesInfo, server <-- srvTcp ] Signed-off-by: Paul Gortmaker commit 6dde6e7d348ebdd0a42cf3ef6f2226eb1ac34aa8 Author: Anton Blanchard Date: Tue Jul 5 21:51:36 2011 +0000 powerpc/pseries/hvconsole: Fix dropped console output commit 51d33021425e1f905beb4208823146f2fb6517da upstream. 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 Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Paul Gortmaker commit 59721dbbb0e2160ca536036c0047c534e2692213 Author: Alan Stern Date: Tue Jul 19 14:01:23 2011 -0400 EHCI: fix direction handling for interrupt data toggles commit e04f5f7e423018bcec84c11af2058cdce87816f3 upstream. This patch (as1480) fixes a rather obscure bug in ehci-hcd. The qh_update() routine needs to know the number and direction of the endpoint corresponding to its QH argument. The number can be taken directly from the QH data structure, but the direction isn't stored there. The direction is taken instead from the first qTD linked to the QH. However, it turns out that for interrupt transfers, qh_update() gets called before the qTDs are linked to the QH. As a result, qh_update() computes a bogus direction value, which messes up the endpoint toggle handling. Under the right combination of circumstances this causes usb_reset_endpoint() not to work correctly, which causes packets to be dropped and communications to fail. Now, it's silly for the QH structure not to have direct access to all the descriptor information for the corresponding endpoint. Ultimately it may get a pointer to the usb_host_endpoint structure; for now, adding a copy of the direction flag solves the immediate problem. This allows the Spyder2 color-calibration system (a low-speed USB device that sends all its interrupt data packets with the toggle set to 0 and hance requires constant use of usb_reset_endpoint) to work when connected through a high-speed hub. Thanks to Graeme Gill for supplying the hardware that allowed me to track down this bug. Signed-off-by: Alan Stern Reported-by: Graeme Gill Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit a0862df158d944abe09c3d69703734e620d579b0 Author: Sergei Shtylyov Date: Wed Jul 6 23:19:38 2011 +0400 EHCI: only power off port if over-current is active commit 81463c1d707186adbbe534016cd1249edeab0dac upstream. 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 Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 893a36baacd2825a02d3b7e6135a73db1e469aea Author: J. Bruce Fields Date: Wed Jun 29 16:49:04 2011 -0400 svcrpc: fix list-corrupting race on nfsd shutdown commit ebc63e531cc6a457595dd110b07ac530eae788c3 upstream. 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: gnb@fmeh.org Reported-by: Ben Greear Tested-by: Ben Greear Signed-off-by: J. Bruce Fields Signed-off-by: Paul Gortmaker commit 6bc5888eb29b669d57522671b17f76b62296cbd7 Author: Jan Kara Date: Mon May 30 13:29:20 2011 +0200 ext3: Fix oops in ext3_try_to_allocate_with_rsv() commit ad95c5e9bc8b5885f94dce720137cac8fa8da4c9 upstream. Block allocation is called from two places: ext3_get_blocks_handle() and ext3_xattr_block_set(). These two callers are not necessarily synchronized because xattr code holds only xattr_sem and i_mutex, and ext3_get_blocks_handle() may hold only truncate_mutex when called from writepage() path. Block reservation code does not expect two concurrent allocations to happen to the same inode and thus assertions can be triggered or reservation structure corruption can occur. Fix the problem by taking truncate_mutex in xattr code to serialize allocations. CC: Sage Weil Reported-by: Fyodor Ustinov Signed-off-by: Jan Kara Signed-off-by: Paul Gortmaker commit 5a9c2bfb2d4c977b689b68c643a4081b634b7eed Author: Dan Rosenberg Date: Mon Jul 25 17:11:53 2011 -0700 xtensa: prevent arbitrary read in ptrace commit 0d0138ebe24b94065580bd2601f8bb7eb6152f56 upstream. 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 Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 53c91646f2661704ee95a0dd0a281ed543fd5fda Author: Stephen M. Cameron Date: Sat Jul 9 09:04:12 2011 +0200 cciss: do not attempt to read from a write-only register commit 07d0c38e7d84f911c72058a124c7f17b3c779a65 upstream. Most smartarrays will tolerate it, but some new ones don't. Signed-off-by: Stephen M. Cameron Note: this is a regression caused by commit 1ddd5049 Signed-off-by: Jens Axboe Signed-off-by: Paul Gortmaker commit 97e5da43d6e99e44d25bed0bbdbb3444914f72a5 Author: Chris Wright Date: Wed Jul 13 10:14:33 2011 -0700 PCI: ARI is a PCIe v2 feature commit 864d296cf948aef0fa32b81407541572583f7572 upstream. The function pci_enable_ari() may mistakenly set the downstream port of a v1 PCIe switch in ARI Forwarding mode. This is a PCIe v2 feature, and with an SR-IOV device on that switch port believing the switch above is ARI capable it may attempt to use functions 8-255, translating into invalid (non-zero) device numbers for that bus. This has been seen to cause Completion Timeouts and general misbehaviour including hangs and panics. Acked-by: Don Dutile Tested-by: Don Dutile Signed-off-by: Chris Wright Signed-off-by: Jesse Barnes Signed-off-by: Paul Gortmaker commit 9bc7025f0a36467b9eb015e0fe39c436f3583d26 Author: Michael Neuling Date: Mon Jul 4 20:40:10 2011 +0000 powerpc/kdump: Fix timeout in crash_kexec_wait_realmode commit 63f21a56f1cc0b800a4c00349c59448f82473d19 upstream. 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 Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Paul Gortmaker commit 5579bfb2223e0687edb01d51333ffe77e0c8d6be Author: Huang Ying Date: Thu Jul 14 09:34:37 2011 +0800 kexec, x86: Fix incorrect jump back address if not preserving context commit 050438ed5a05b25cdf287f5691e56a58c2606997 upstream. 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 Link: http://lkml.kernel.org/r/1310607277-25029-1-git-send-email-ying.huang@intel.com Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit 581be6e5946e9a11d50c3c4961683298fd8e0bfa Author: Dan Rosenberg Date: Mon Jul 11 14:08:23 2011 -0700 pmcraid: reject negative request size commit b5b515445f4f5a905c5dd27e6e682868ccd6c09d 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. First, the user can call pmcraid_chr_ioctl(), with a type PMCRAID_PASSTHROUGH_IOCTL. This calls through to pmcraid_ioctl_passthrough(). Next, 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. It looks like preventing this value from being negative in pmcraid_ioctl_passthrough() would be sufficient. Signed-off-by: Dan Rosenberg Signed-off-by: Andrew Morton Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit d11672253ad42930b5e318cbea3f1b42a8f27d9a Author: Douglas Gilbert Date: Thu Jun 9 00:27:07 2011 -0400 ses: requesting a fault indication commit 2a350cab9daf9a46322d83b091bb05cf54ccf6ab upstream. Noticed that when the sysfs interface of the SCSI SES driver was used to request a fault indication the LED flashed but the buzzer didn't sound. So it was doing what REQUEST IDENT (locate) should do. Changelog: - fix the setting of REQUEST FAULT for the device slot and array device slot elements in the enclosure control diagnostic page - note the potentially defective code that reads the FAULT SENSED and FAULT REQUESTED bits from the enclosure status diagnostic page The attached patch is against git/scsi-misc-2.6 Signed-off-by: Douglas Gilbert Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit e310da489bc878370c45e59492b4608d6ee2e8da Author: Werner Fink Date: Thu Jun 9 10:54:24 2011 +0530 Blacklist Traxdata CDR4120 and IOMEGA Zip drive to avoid lock ups. commit 82103978189e9731658cd32da5eb85ab7b8542b8 upstream. This patch resulted from the discussion at https://bugzilla.novell.com/show_bug.cgi?id=679277, https://bugzilla.novell.com/show_bug.cgi?id=681840 . Signed-off-by: Werner Fink Signed-off-by: Ankit Jain Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit 6fd084a711895af4da06146900939b00688f68bb Author: Rajkumar Manoharan Date: Thu Jul 7 23:33:39 2011 +0530 mac80211: Restart STA timers only on associated state commit 676b58c27475a9defccc025fea1cbd2b141ee539 upstream. 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. Signed-off-by: Rajkumar Manoharan Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit ac7def8f12f701e7abb06d6d43e260da63b87119 Author: Luben Tuikov Date: Tue Jul 26 23:10:48 2011 -0700 libsas: remove expander from dev list on error commit 5911e963d3718e306bcac387b83e259aa4228896 upstream. If expander discovery fails (sas_discover_expander()), remove the expander from the port device list (sas_ex_discover_expander()), before freeing it. Else the list is corrupted and, e.g., when we attempt to send SMP commands to other devices, the kernel oopses. Signed-off-by: Luben Tuikov Reviewed-by: Jack Wang Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit 8b28676fa63d66d6db418952f5ef9db42f40a2da Author: Guo-Fu Tseng Date: Wed Jul 20 16:57:36 2011 +0000 jme: Fix unmap error (Causing system freeze) commit 94c5b41b327e08de0ddf563237855f55080652a1 upstream. 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. :) Signed-off-by: Guo-Fu Tseng Acked-by: Chris Wright Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit ec1492939a5174027522d84c73a1cd4329fb62c4 Author: Igor Grinberg Date: Mon May 9 14:41:46 2011 +0300 ARM: pxa/cm-x300: fix V3020 RTC functionality commit 6c7b3ea52e345ab614edb91d3f0e9f3bb3713871 upstream. 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 Signed-off-by: Eric Miao Signed-off-by: Paul Gortmaker commit 71fd410bea0aa03a8a5d72a6c4b700f422a9af13 Author: Alan Stern Date: Fri Jul 15 17:22:15 2011 -0400 USB: OHCI: fix another regression for NVIDIA controllers commit 6ea12a04d295235ed67010a09fdea58c949e3eb0 upstream. 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 Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 704e985bd8becc288fa649ddcf82f9e8ff9e5eab Author: Vasiliy Kulikov Date: Sun Jun 26 12:56:22 2011 +0400 staging: comedi: fix infoleak to userspace commit 819cbb120eaec7e014e5abd029260db1ca8c5735 upstream. 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 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 4f552082fd15c9ae2cc5cf9f1307432933ffe02d Author: Wolfgang Denk Date: Tue Jul 19 11:25:38 2011 +0200 USB: serial: add IDs for WinChipHead USB->RS232 adapter commit 026dfaf18973404a01f488d6aa556a8c466e06a4 upstream. Add ID 4348:5523 for WinChipHead USB->RS 232 adapter with Prolifec PL2303 chipset Signed-off-by: Wolfgang Denk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit ae06aa35a74c7b65a50ce60b3c2db156dfd064e4 Author: Greg Kroah-Hartman Date: Mon May 17 10:33:41 2010 -0700 USB: pl2303.h: checkpatch cleanups commit 5d78fcb0caf219e2e6c8e486d7e31fec1333ac06 upstream. Minor whitespace cleanups to make checkpatch happy. Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit bfdada315d364403d0a3856b84bd6e0e55a715e0 Author: Daniel J Blueman Date: Fri May 13 09:04:59 2011 +0800 x86: Make Dell Latitude E5420 use reboot=pci commit b7798d28ec15d20fd34b70fa57eb13f0cf6d1ecd upstream. 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 Link: http://lkml.kernel.org/r/1305248699-2347-1-git-send-email-daniel.blueman@gmail.com Signed-off-by: H. Peter Anvin Signed-off-by: Paul Gortmaker commit 1f93e2c5d5153b6edbe99b6ed1f8a10c67b6cb77 Author: Tejun Heo Date: Wed May 25 13:19:39 2011 +0200 libata: fix unexpectedly frozen port after ata_eh_reset() commit 8c56cacc724c7650b893d43068fa66044aa29a61 upstream. To work around controllers which can't properly plug events while reset, ata_eh_reset() clears error states and ATA_PFLAG_EH_PENDING after reset but before RESET is marked done. As reset is the final recovery action and full verification of devices including onlineness and classfication match is done afterwards, this shouldn't lead to lost devices or missed hotplug events. Unfortunately, it forgot to thaw the port when clearing EH_PENDING, so if the condition happens after resetting an empty port, the port could be left frozen and EH will end without thawing it, making the port unresponsive to further hotplug events. Thaw if the port is frozen after clearing EH_PENDING. This problem is reported by Bruce Stenning in the following thread. http://thread.gmane.org/gmane.linux.kernel/1123265 stable: I think we should weather this patch a bit longer in -rcX before sending it to -stable. Please wait at least a month after this patch makes upstream. Thanks. -v2: Fixed spelling in the comment per Dave Howorth. Signed-off-by: Tejun Heo Reported-by: Bruce Stenning Cc: Dave Howorth Signed-off-by: Jeff Garzik Signed-off-by: Paul Gortmaker commit 07cb32b1937cb057821bf25a51e73f1b7cf68d00 Author: Jon Povey Date: Tue Jul 19 12:30:11 2011 +0900 davinci: DM365 EVM: fix video input mux bits commit 9daedd833a38edd90cf7baa1b1fcf61c3a0721e3 upstream. 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 Signed-off-by: Sekhar Nori Signed-off-by: Paul Gortmaker commit b43ee6df01cfb5b508921d84c88e57b535688f8f Author: stephen hemminger Date: Fri Jul 22 07:47:06 2011 +0000 bridge: send proper message_age in config BPDU commit 0c03150e7ea8f7fcd03cfef29385e0010b22ee92 upstream. A bridge topology with three systems: +------+ +------+ | A(2) |--| B(1) | +------+ +------+ \ / +------+ | C(3) | +------+ What is supposed to happen: * bridge with the lowest ID is elected root (for example: B) * C detects that A->C is higher cost path and puts in blocking state What happens. Bridge with lowest id (B) is elected correctly as root and things start out fine initially. But then config BPDU doesn't get transmitted from A -> C. Because of that the link from A-C is transistioned to the forwarding state. The root cause of this is that the configuration messages is generated with bogus message age, and dropped before sending. In the standardmessage_age is supposed to be: the time since the generation of the Configuration BPDU by the Root that instigated the generation of this Configuration BPDU. Reimplement this by recording the timestamp (age + jiffies) when recording config information. The old code incorrectly used the time elapsed on the ageing timer which was incorrect. See also: https://bugzilla.vyatta.com/show_bug.cgi?id=7164 Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit fd4eb5ed110c04d95e6f57dee0f6ebabfd4e20b0 Author: Pavel Herrmann Date: Sun Jul 17 18:39:19 2011 +0200 hwmon: (max1111) Fix race condition causing NULL pointer exception commit d3f684f2820a7f42acef68bea6622d9032127fb2 upstream. 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 Signed-off-by: Paul Gortmaker commit 2d89eba9cc7be4dfabe523067bff245632181536 Author: Mauro Carvalho Chehab Date: Sun Jul 17 00:24:37 2011 -0300 si4713-i2c: avoid potential buffer overflow on si4713 commit dc6b845044ccb7e9e6f3b7e71bd179b3cf0223b6 upstream. 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 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: Paul Gortmaker commit 6df3d28f699821fc6fe47ef7a6ace0e3eccc1790 Author: Ben Greear Date: Tue Jul 12 10:27:55 2011 -0700 SUNRPC: Fix use of static variable in rpcb_getport_async commit ec0dd267bf7d08cb30e321e45a75fd40edd7e528 upstream. 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 Signed-off-by: Trond Myklebust Signed-off-by: Paul Gortmaker commit 050dc70ca582d414cabcb24126cb5abac36b4f99 Author: Trond Myklebust Date: Wed Jul 6 19:58:23 2011 -0400 SUNRPC: Fix a race between work-queue and rpc_killall_tasks commit b55c59892e1f3b6c7d4b9ccffb4263e1486fb990 upstream. 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 Signed-off-by: Paul Gortmaker commit a86d1496657c8edd7049d4a302bcd5ed7f9d60db Author: Andy Adamson Date: Mon Jul 11 17:17:42 2011 -0400 NFSv4.1: update nfs4_fattr_bitmap_maxsz commit e5012d1f3861d18c7f3814e757c1c3ab3741dbcd upstream. Attribute IDs assigned in RFC 5661 now require three bitmaps. Fixes hitting a BUG_ON in xdr_shrink_bufhead when getting ACLs. Signed-off-by: Andy Adamson Signed-off-by: Trond Myklebust Signed-off-by: Paul Gortmaker commit 8edb0efda5f0c82a60b4380423007a2e776e4a65 Author: Hans Verkuil Date: Sun Jun 12 07:02:43 2011 -0300 bttv: fix s_tuner for radio commit a024c1a6b274e11596d124619e43c25560f64c01 upstream. Fix typo: g_tuner should have been s_tuner. Tested with a bttv card. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Paul Gortmaker commit b9e2bf7493ecf04dffacedbb073c8d2225f1ed14 Author: Hans Verkuil Date: Sun Jun 12 06:39:52 2011 -0300 pvrusb2: fix g/s_tuner support commit 50e9efd60b213ce43ad6979bfc18e25eec2d8413 upstream. 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 Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Paul Gortmaker commit 33463719360bd2d7d207a6b7a8a094dcb71c05f1 Author: Hans Verkuil Date: Sun Jun 12 06:36:41 2011 -0300 v4l2-ioctl.c: prefill tuner type for g_frequency and g/s_tuner commit 227690df75382e46a4f6ea1bbc5df855a674b47f upstream. 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. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Paul Gortmaker commit 67f0639f65b1109f25ad7a9827b392705582f7b3 Author: Mark Brown Date: Mon Jun 13 12:14:07 2011 +0100 ASoC: Fix Blackfin I2S _pointer() implementation return in bounds values commit e999dc50404d401150a5429b6459473a691fd1a0 upstream. The Blackfin DMA controller can report one frame beyond the end of the buffer in the wraparound case but ALSA requires that the pointer always be in the buffer. Do the wraparound to handle this. A similar bug is likely to apply to the other Blackfin PCM drivers but the code is less obvious to inspection and I don't have a user to test. Reported-by: Kieran O'Leary Acked-by: Liam Girdwood Signed-off-by: Mark Brown Signed-off-by: Paul Gortmaker commit 6fb7c40b505e5a2fd57164a7d5bd7f9e2a6a5ede 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 [PG: Some chunks dropped, since no ebdfed4dc5 in 34; came in at 2.6.37] Signed-off-by: Paul Gortmaker commit 60769501a86b57c45d08eb130f925aeab31c9132 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 commit 9cfaa8def1c795a512bc04f2aec333b03724ca2e upstream. 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: Paul Gortmaker commit 7bc5fbec9f565c9f0f567b6e95698f7ed8ea2de4 Author: Xufeng Zhang Date: Tue Jun 21 10:43:39 2011 +0000 ipv6/udp: Use the correct variable to determine non-blocking condition commit 32c90254ed4a0c698caa0794ebb4de63fcc69631 upstream. 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: Paul Gortmaker commit 020ad7b48dd828c8e281188b1dfd40d57b4c156e Author: Marcus Meissner Date: Wed Jun 1 21:05:22 2011 -0700 net/ipv4: Check for mistakenly passed in non-IPv4 address commit d0733d2e29b652b2e7b1438ececa732e4eed98eb upstream. 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: Paul Gortmaker commit 2c92bce21378239199838eb0c3471c8cb3a93dc1 Author: Eric Dumazet Date: Mon Jun 6 22:42:06 2011 -0700 af_packet: prevent information leak commit 13fcb7bd322164c67926ffe272846d4860196dc6 upstream. 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 CC: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 06007b7e2d2e96d1fa36cfd42db13eead3ae7f5d Author: Joe Perches Date: Sat May 21 07:48:40 2011 +0000 net: filter: Use WARN_RATELIMIT commit 6c4a5cb219520c7bc937ee186ca53f03733bd09f upstream. 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: Paul Gortmaker commit 16eb4dba5eaad731fb28605a4754b5f31603e39a Author: Joe Perches Date: Sat May 21 07:48:39 2011 +0000 bug.h: Add WARN_RATELIMIT commit b3eec79b0776e5340a3db75b34953977c7e5086e upstream. 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: Paul Gortmaker commit 17faeb6e7db6c98e235ec085c4157340e6aa5d4e 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 Reported-and-tested-by: Matthew Garrett Signed-off-by: Paul Gortmaker commit 561c6e2d14e0ac50eb1716b94fb297177d824478 Author: Rafael J. Wysocki Date: Sat Sep 11 20:58:27 2010 +0200 PM / Hibernate: Avoid hitting OOM during preallocation of memory commit 6715045ddc7472a22be5e49d4047d2d89b391f45 upstream. There is a problem in hibernate_preallocate_memory() that it calls preallocate_image_memory() with an argument that may be greater than the total number of available non-highmem memory pages. If that's the case, the OOM condition is guaranteed to trigger, which in turn can cause significant slowdown to occur during hibernation. To avoid that, make preallocate_image_memory() adjust its argument before calling preallocate_image_pages(), so that the total number of saveable non-highem pages left is not less than the minimum size of a hibernation image. Change hibernate_preallocate_memory() to try to allocate from highmem if the number of pages allocated by preallocate_image_memory() is too low. Modify free_unnecessary_pages() to take all possible memory allocation patterns into account. Reported-by: KOSAKI Motohiro Signed-off-by: Rafael J. Wysocki Tested-by: M. Vefa Bicakci Signed-off-by: Paul Gortmaker commit d034c6d3572a43f342e80d3f3af23a042e6e0d91 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: Paul Gortmaker commit 9d2c41fe469d005e19a1aa87f847614ae8663dcd 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: Paul Gortmaker commit 8f65813f473bf9dcd2fef064468fef7de84677b0 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: Paul Gortmaker commit b026f0c7a312ef36edb451d2b66c543b9488b4fd 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: Paul Gortmaker commit f3d5950607bccc215ce4db7d39168ef0a9034e41 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: Paul Gortmaker commit c33cbe9efc1390264244e123c9900823979b54de 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: Paul Gortmaker commit 586cfeb0949b95042a25a1f8ba0937ed8aba70bb 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: Paul Gortmaker commit 927b2d35f06f1c5d234a9392d0a18cee86da3790 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: Paul Gortmaker commit 470564b1d4c27fd2bafc421acf49718bfcf5ea5a 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: Paul Gortmaker commit b24a9d3db0f8d01f6c6088b2026f6739e5708ce1 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 Link: http://lkml.kernel.org/r/20110528112342.GA3068@joi.lan Signed-off-by: Thomas Gleixner Signed-off-by: Paul Gortmaker commit af99bfc79386bb0fec583ee393e27e4344d3b27f 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 [PG: use combo gpio_request+gpio_direction_output vs. gpio_request_one to avoid build failure, as per v2.6.32.47 commit 35b6863ce555c ] Signed-off-by: Paul Gortmaker commit f817de8b032d8a321a06c562b6d282bc554a1c3c 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: Paul Gortmaker commit 29cda4f91350a6a10e5d1150e81d9bb8c8c41f87 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: Paul Gortmaker commit 5dfe6135e56190f57aef4c40bbe1c27b62f7242d 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: Paul Gortmaker commit 668414492fae0b4604405f00986afa8f3258d5e1 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: Paul Gortmaker commit 2ae35134383c9241ac5ea299ada9b67f5cb30061 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: Paul Gortmaker commit cdbbca620214953b9f65838fe56ea8c367af8109 Author: Jiri Slaby Date: Sun Jun 5 14:16:16 2011 +0200 TTY: ldisc, do not close until there are readers commit 92f6fa09bd453ffe3351fa1f1377a1b7cfa911e6 upstream. We restored tty_ldisc_wait_idle in 100eeae2c5c (TTY: restore tty_ldisc_wait_idle). We used it in the ldisc changing path to fix the case where there are tasks in n_tty_read waiting for data and somebody tries to change ldisc. Similar to the case above, there may be also tasks waiting in n_tty_read while hangup is performed. As 65b770468e98 (tty-ldisc: turn ldisc user count into a proper refcount) removed the wait-until-idle from all paths, hangup path won't wait for them to disappear either now. So add it back even to the hangup path. There is a difference, we need uninterruptible sleep as there is obviously HUP signal pending. So tty_ldisc_wait_idle now sleeps without possibility to be interrupted. This is what original tty_ldisc_wait_idle did. After the wait idle reintroduction (100eeae2c5c), we have had interruptible sleeps for the ldisc changing path. But as there is a 5s timeout anyway, we don't allow it to be interrupted from now on. It's not worth the added complexity of deciding what kind of sleep we want. Before 65b770468e98 tty_ldisc_release was called also from tty_ldisc_release. It is called from tty_release, so I don't think we need to restore that one. This is nicely reproducible after constifying the timing when drivers/tty/n_tty.c is patched as follows ("TTY: ntty, add one more sanity check" patch is needed to actually see it explode): %% -1548,6 +1549,7 @@ static int n_tty_open(struct tty_struct *tty) /* These are ugly. Currently a malloc failure here can panic */ if (!tty->read_buf) { + msleep(100); tty->read_buf = kzalloc(N_TTY_BUF_SIZE, GFP_KERNEL); if (!tty->read_buf) return -ENOMEM; %% -1785,6 +1788,7 @@ do_it_again: break; } timeout = schedule_timeout(timeout); + msleep(20); continue; } __set_current_state(TASK_RUNNING); ===== With a process: ===== while (1) { int fd = open(argv[1], O_RDWR); read(fd, buf, sizeof(buf)); close(fd); } ===== and its child: ===== setsid(); while (1) { int fd = open(tty, O_RDWR|O_NOCTTY); ioctl(fd, TIOCSCTTY, 1); vhangup(); close(fd); usleep(100 * (10 + random() % 1000)); } ===== EOF ===== References: https://bugzilla.novell.com/show_bug.cgi?id=693374 References: https://bugzilla.novell.com/show_bug.cgi?id=694509 Signed-off-by: Jiri Slaby Cc: Alan Cox Cc: Linus Torvalds Signed-off-by: Greg Kroah-Hartman [PG: account for char --> tty file rename post 2.6.34] Signed-off-by: Paul Gortmaker commit 08c902fccd1753926095c863b01fb88bbec69f30 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: Paul Gortmaker commit 5cd58d69c1e8df75d70be60e8b77fdb2090102fb 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: Paul Gortmaker commit bf7356dc949e1f990a65423ce4ce3cce6f56f559 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: Paul Gortmaker commit 0395a92f7c90a13e087a1aefe501e865468a65e5 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: Paul Gortmaker commit cfd2c25155baf95e6e79466320838be17b07c542 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: Paul Gortmaker commit e9a34a2459723a4fed8282dd15964167bbbb6b62 Author: Ian Campbell Date: Wed Nov 9 08:53:09 2011 +0000 genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier commit 9bab0b7fbaceec47d32db51cd9e59c82fb071f5a upstream This adds a mechanism to resume selected IRQs during syscore_resume instead of dpm_resume_noirq. Under Xen we need to resume IRQs associated with IPIs early enough that the resched IPI is unmasked and we can therefore schedule ourselves out of the stop_machine where the suspend/resume takes place. This issue was introduced by 676dc3cf5bc3 "xen: Use IRQF_FORCE_RESUME". Back ported to 2.6.32 (which lacks syscore support) by calling the relavant resume function directly from sysdev_resume). v2: Fixed non-x86 build errors. Signed-off-by: Ian Campbell Cc: Rafael J. Wysocki Cc: Jeremy Fitzhardinge Cc: xen-devel Cc: Konrad Rzeszutek Wilk Link: http://lkml.kernel.org/r/1318713254.11016.52.camel@dagon.hellion.org.uk Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman [PG: this v2 backport taken from v2.6.32.49 stable, commit 5e87d8ee34e3] Signed-off-by: Paul Gortmaker commit ba5ebfb8d23f648cf0369233506a58b58ae0925e 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: Paul Gortmaker commit e1886da371325371ee3d6c4ec30cc389552646ff 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: Paul Gortmaker commit cafd708df3180406fbc0254d1777ddc19213d533 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: Paul Gortmaker commit f7895de92981a85eb53ab11c65d71e03d1d9c326 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: Paul Gortmaker commit 5e3f1a186427b89778ab123f29f5334e773f12eb 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: Paul Gortmaker commit 7c588af936365b67baae07bb46023bfcbd1e16ba 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: Paul Gortmaker commit edca0bf3bbff8dc94ac9a7b1e05d656167cebb15 Author: Johannes Weiner Date: Fri Oct 1 07:43:54 2010 +0000 xfs: properly account for reclaimed inodes commit 081003fff467ea0e727f66d5d435b4f473a789b3 upstream. When marking an inode reclaimable, a per-AG counter is increased, the inode is tagged reclaimable in its per-AG tree, and, when this is the first reclaimable inode in the AG, the AG entry in the per-mount tree is also tagged. When an inode is finally reclaimed, however, it is only deleted from the per-AG tree. Neither the counter is decreased, nor is the parent tree's AG entry untagged properly. Since the tags in the per-mount tree are not cleared, the inode shrinker iterates over all AGs that have had reclaimable inodes at one point in time. The counters on the other hand signal an increasing amount of slab objects to reclaim. Since "70e60ce xfs: convert inode shrinker to per-filesystem context" this is not a real issue anymore because the shrinker bails out after one iteration. But the problem was observable on a machine running v2.6.34, where the reclaimable work increased and each process going into direct reclaim eventually got stuck on the xfs inode shrinking path, trying to scan several million objects. Fix this by properly unwinding the reclaimable-state tracking of an inode when it is reclaimed. [PG: upstream has xfs_reclaim_inode in fs/xfs/linux-2.6/xfs_sync.c but in 34 baseline, it is xfs_ireclaim in fs/xfs/xfs_iget.c so drop the STATIC and add a prototype for it. ] Signed-off-by: Johannes Weiner Reviewed-by: Dave Chinner Signed-off-by: Alex Elder Signed-off-by: Paul Gortmaker commit 898f983bd1517922d7b9c06b856de51720fd253c Author: James Bottomley Date: Sun Apr 24 14:30:14 2011 -0500 pata_cm64x: fix boot crash on parisc commit 9281b16caac1276817b77033c5b8a1f5ca30102c upstream. The old IDE cmd64x checks the status of the CNTRL register to see if the ports are enabled before probing them. pata_cmd64x doesn't do this, which causes a HPMC on parisc when it tries to poke at the secondary port because apparently the BAR isn't wired up (and a non-responding piece of memory causes a HPMC). Fix this by porting the CNTRL register port detection logic from IDE cmd64x. In addition, following converns from Alan Cox, add a check to see if a mobility electronics bridge is the immediate parent and forgo the check if it is (prevents problems on hotplug controllers). Signed-off-by: James Bottomley Signed-off-by: Jeff Garzik Signed-off-by: Paul Gortmaker commit 52df3ade75b2359ec54db84769a36f1f2125dc52 Author: Namhyung Kim Date: Tue Jun 14 14:20:19 2011 +1000 md/raid5: fix FUA request handling in ops_run_io() commit b062962edb086011e94ec4d9eb3f6a6d814f2a8f upstream. Commit e9c7469bb4f5 ("md: implment REQ_FLUSH/FUA support") introduced R5_WantFUA flag and set rw to WRITE_FUA in that case. However remaining code still checks whether rw is exactly same as WRITE or not, so FUAed-write ends up with being treated as READ. Fix it. This bug has been present since 2.6.37 and the fix is suitable for any -stable kernel since then. It is not clear why this has not caused more problems. Cc: Tejun Heo Signed-off-by: Namhyung Kim Signed-off-by: NeilBrown Signed-off-by: Paul Gortmaker commit a356578add4be8d1209645f8ba60f235db1f6e12 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: Paul Gortmaker commit 6611502281d1f8d04cc2d79887b5d456c3c47b18 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: Paul Gortmaker commit d53072db239de81ccd71292cc08bdaf682814632 Author: Dave Jones Date: Sun Jun 12 16:35:28 2011 -0400 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: Paul Gortmaker commit d9dedaec02803e205adc5e29f07ccd9fc61295d9 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: Paul Gortmaker commit e3147ad318f8ce6f17d1b123d897f5184af923e0 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: Paul Gortmaker commit 0088681fe8d547744c80dd951afb7cd8fe3f30d5 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: Paul Gortmaker commit 0297e6d82c208572618fb831bd6cd06672408877 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: Paul Gortmaker commit c3ab0773d7c302f79183673a33f519f00c144679 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: Paul Gortmaker commit 768d9d126c2f2aa56398bf475161e86efbb0d13c 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: Paul Gortmaker commit fcd3023216796cf11036c4e9bf16cdca5de7da68 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: Paul Gortmaker commit fe2a00ca2f8f0a37cba64eaaab342538d277b6d0 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: Paul Gortmaker commit 7ff994588123df4c041e897e058e3504501cfa86 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 cc: stable@kernel.org Signed-off-by: Dave Airlie Signed-off-by: Paul Gortmaker commit 5377b39c6ffcd7e6541cdbc16ffd4ff278717738 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 cc: stable@kernel.org Signed-off-by: Keith Packard Signed-off-by: Paul Gortmaker commit 573289be5cd6084124341eee86c6494528e9825c 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 Link: http://lkml.kernel.org/r/1307398759.2497.966.camel@laptop Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit 064a930ea49c1c420c45f8b0db9b0609c5aa3047 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. [PG: 34 codebase does not have nl80211_start_sched_scan part] Signed-off-by: Luciano Coelho Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit d99563ef3f1ce4427a8360c8daba821c0840a7ec 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: Paul Gortmaker commit 411ddb158e3e9eb8c03994551d21c9a2d4f6652e 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: Paul Gortmaker commit 697b4f1473ddc06a0fb77d80281cf57f5fcf5b0a 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: Paul Gortmaker commit cf72dbd757c58e568df27c1d6b8c96e0642b8384 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: Paul Gortmaker commit 100e29252dea85662e164bc03e53e3e9a660afe1 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: Paul Gortmaker commit ca77a2e55e6b1226a70d1e983fc8488d4a99d68e 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: Paul Gortmaker commit 95fdbf513750aaf81c6ce6a9f4708215d050050f 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: Paul Gortmaker commit b2afb70cb500536461772b26ec3f99025369a4c9 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: --------------------------------- 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: Paul Gortmaker commit b5c7034dbdf8a0a5f32a4db9af3345d033b1bf49 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: Paul Gortmaker commit 1239f38ef01c3e1e83d188a9f264cf4404561f76 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: Paul Gortmaker commit ebf9694ee8ace425852c5118d1f9abc6185cbd4e 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: Paul Gortmaker commit 85ae833b7f1ec6591dbf18fecf45b7cec5b770f5 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: Paul Gortmaker commit 2941bb5699675d1f741ce5804e9d901d505a8128 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: Paul Gortmaker commit 9a715384cc524ae134bd3b2804cd31338d16bfe7 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: Paul Gortmaker commit e2a494065fafb1ed397ef55a230a54e4ecdf374a 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. cc: stable@kernel.org # .32.x through .39.x Signed-off-by: Tero Kristo Signed-off-by: Len Brown Signed-off-by: Paul Gortmaker commit 1e08fb3a81dd6c30140642657c60eca861a2400e 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: Paul Gortmaker commit 12484758f50f235fc6cd7469139503dbc89faa46 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: Paul Gortmaker commit 6e018cc8eb066bb2f315663e81631bd015d3f51e 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: Paul Gortmaker commit f17ea46721e423a04fa55ca694882852a64e264f 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: Paul Gortmaker commit cc9c798a1f821ca9778d3901ea749fb9f73fdc0e 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: Paul Gortmaker commit 6d9190455ff09e666dbf8f568e2974be92370e90 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: Paul Gortmaker commit e9f13bc2f4c78adf48aa88eba7ceedc3c4a02c96 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: Paul Gortmaker commit d390d7a906ee7ea3fceb96fd8e13a4403229d9fb 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: Paul Gortmaker commit 3ed3948164ed999e15d94e5aa4ed241e79b3342c 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: Paul Gortmaker commit ae04e9e018d6d9882c70529fc348b83973879fd7 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: Paul Gortmaker commit 1eb70aae09b8483cb68eaa65d599abdd62664e12 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: Paul Gortmaker commit 481ea61f36f09d16988e94a92a7d4c6adfaa5563 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: Paul Gortmaker commit 656784547e390cfdd148d66dd89352000e669421 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: Paul Gortmaker commit 6071be770720beec5d63cc5fa38dfd57b2126e8b 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: Paul Gortmaker commit 29d4a28edd45b4ebea5d7f04fd410a35d9c206b8 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: Paul Gortmaker commit e849e75ae3e75b9baeb0e55cd0d4b28563306394 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 commit c71625f16c95e8821962bff0238fc960ff559566 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: Paul Gortmaker commit 8a775c185c43cdea7c67a2fa84d29e693fac618e 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. Cc: 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 Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E Signed-off-by: Thomas Gleixner Signed-off-by: Paul Gortmaker commit 059b0f4d9d8a293d7e9c885bfc3f55781a656e30 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: Paul Gortmaker commit d98225120eba48ee9d6c9a79d0c35a82ea0de6ec 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: Paul Gortmaker commit 08437d771f90d0414fd5ee67ad02ae3eb89a4d81 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: Paul Gortmaker commit 365671b9c6d56cac4ef73b83e47e2d8f37de0b89 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: Paul Gortmaker commit a50c8878b5708c71a502ff5151371b6bfe040ae6 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: Paul Gortmaker commit bc4e172f975f34f77998b4bfc6bf4e864eea00e4 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: Paul Gortmaker commit c019be4b3fb7e9681be89ee18243049abf50859b 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: Paul Gortmaker commit 81670d15f4a3795d6645e7dd236e8e2fefe8e1d2 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: Paul Gortmaker commit d440d589a8b4f4ebe2b227268ab55b67a588aa2b 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 Link: http://lkml.kernel.org/r/1305210630-7136-1-git-send-email-jolsa@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit 4c10301761cd9f4aedfeb1c8001613da33783c77 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: Paul Gortmaker commit 6e00130536c6463adb06d5122093295ffe02c18f 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: Paul Gortmaker commit a41dafdf3382095c5160c9612bacda7b82e1292f 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: Paul Gortmaker commit 09f8447f642f2698692cb05076d73b2729830811 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: Paul Gortmaker commit 20ac721b10559dd888aade4d9b7da43a63e60bb4 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: Paul Gortmaker commit f8dccff375994b99f448841c75f5a180d45262c6 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: Paul Gortmaker commit f53308de9f3ddfff46671192f081751541498137 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: Paul Gortmaker commit 8a6e54faf593e6a7526e16fe56deb4a29d7d172e 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: Paul Gortmaker