commit 056c71459d3acf9fefcb2dc67abeef10e649d508 Author: Greg Kroah-Hartman Date: Sat Oct 25 15:05:07 2008 -0700 Linux 2.6.27.4 commit 1b146f86965053c2496f9ce22c9e26a770930c66 Author: Mike Isely Date: Sun Oct 19 16:26:05 2008 -0300 V4L/DVB (9300): pvrusb2: Fix deadlock problem commit c82732a42896364296599b0f73f01c5e3fd781ae upstream Fix deadlock problem in 2.6.27 caused by new USB core behavior in response to a USB device reset request. With older kernels, the USB device reset was "in line"; the reset simply took place and the driver retained its association with the hardware. However now this reset triggers a disconnect, and worse still the disconnect callback happens in the context of the caller who asked for the device reset. This results in an attempt by the pvrusb2 driver to recursively take a mutex it already has, which deadlocks the driver's worker thread. (Even if the disconnect callback were to happen on a different thread we'd still have problems however - because while the driver should survive and correctly disconnect / reconnect, it will then trigger another device reset during the repeated initialization, which will then cause another disconect, etc, forever.) The fix here is simply to not attempt the device reset (it was of marginal value anyway). Signed-off-by: Mike Isely Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Mike Krufky Signed-off-by: Greg Kroah-Hartman commit daa0b0ad2666acdb331e6611ca790fd0dfe6a1b0 Author: Kenji Kaneshige Date: Fri Oct 24 02:50:03 2008 +0000 PCI hotplug: cpqphp: fix kernel NULL pointer dereference commit d2174c3c07adad88dd9ba37a731e0b00b746822a upstream The following patch fixes the regression in 2.6.27 that causes kernel NULL pointer dereference at cpqphp driver probe time. This patch should be backported to the .27 stable series. Seems to have been introduced by f46753c5e354b857b20ab8e0fe7b2579831dc369. The root cause of this problem seems that cpqphp driver calls pci_hp_register() wrongly. In current implementation, cpqphp driver passes 'ctrl->pci_dev->subordinate' as a second parameter for pci_hp_register(). But because hotplug slots and it's hotplug controller (exists as a pci funcion) are on the same bus, it should be 'ctrl->pci_dev->bus' instead. Tested-by: Ingo Molnar Signed-off-by: Kenji Kaneshige Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 3ee82b553d04d90948a41eef761302afcf3f1805 Author: Yanqing_Liu@Dell.com Date: Thu Oct 2 12:18:33 2008 -0500 SCSI: scsi_dh: add Dell product information into rdac device handler commit 650849d71ca05d55a1553fe42fb21af9dce5612b upstream. Add Dell Powervault storage arrays into device list of rdac device handler. Signed-off-by: Yanqing Liu Signed-off-by: James Bottomley Cc: shyam iyer Signed-off-by: Greg Kroah-Hartman commit a75aefa2c83b7eea2cced4d7ff70eb1d50e926df Author: Joe Korty Date: Thu Oct 23 18:14:25 2008 -0400 proc: fix vma display mismatch between /proc/pid/{maps,smaps} [ backport of 7c88db0cb589df980acfb2f73c3595a0653004ec to 2.7.27.3 by Joe Korty /tmp/smaps; diff /proc/1/maps /tmp/smaps 1 25d24 2 < 7fd7e23aa000-7fd7e23ac000 rw-p 7fd7e23aa000 00:00 0 3 28a28 4 > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] The bug has something to do with setting m->version before all the seq_printf's have been performed. show_map was doing this correctly, but show_smap was doing this in the middle of its seq_printf sequence. This patch arranges things so that the setting of m->version in show_smap is also done at the end of its seq_printf sequence. Testing: in addition to the above grep test, for each process I summed up the 'Rss' fields of /proc/pid/smaps and compared that to the 'VmRSS' field of /proc/pid/status. All matched except for Xorg (which has a /dev/mem mapping which Rss accounts for but VmRSS does not). This result gives us some confidence that neither /proc/pid/maps nor /proc/pid/smaps are any longer skipping or double-counting vmas. Signed-off-by: Joe Korty Cc: Matt Mackall Signed-off-by: Andrew Morton Signed-off-by: Alexey Dobriyan commit 3b987ac961486373f91191b14291b331fa546072 Author: Rafael J. Wysocki Date: Sat Sep 6 13:13:01 2008 +0200 ACPI suspend: Always use the 32-bit waking vector commit a6629105dd03d370fcb31e97bddf223fa4bb651e upstream. According to the ACPI specification 2.0c and later, the 64-bit waking vector should be cleared and the 32-bit waking vector should be used, unless we want the wake-up code to be called by the BIOS in Protected Mode. Moreover, some systems (for example HP dv5-1004nr) are known to fail to resume if the 64-bit waking vector is used. Therefore, modify the code to clear the 64-bit waking vector, for FACS version 1 or greater, and set the 32-bit one before suspend. http://bugzilla.kernel.org/show_bug.cgi?id=11368 Signed-off-by: Rafael J. Wysocki Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit a25e0acfb0217c3910151af3ae6b020fd0bad094 Author: Rafael J. Wysocki Date: Tue Oct 14 22:54:06 2008 +0200 ACPI suspend: Blacklist HP xw4600 Workstation for old code ordering commit 4fb507b6b764195bb7821cf2baa988f6eb677d30 upstream HP xw4600 Workstation is known to require the "old" (ie. compatible with ACPI 1.0) suspend code ordering, so blacklist it for this purpose. Signed-off-by: Rafael J. Wysocki Tested-by: John Brown Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 66036f5862883fcc9f7ff8550685a5a3de1a57e4 Author: Rafael J. Wysocki Date: Sat Oct 4 00:05:05 2008 +0200 ACPI Suspend: Enable ACPI during resume if SCI_EN is not set commit d0c71fe7ebc180f1b7bc7da1d39a07fc19eec768 upstream. On some machines, like for example MSI Wind U100, the BIOS doesn't enable ACPI before returning control to the OS, which sometimes causes resume to fail. This is against the ACPI specification, which clearly states that "When the platform is waking from an S1, S2 or S3 state, OSPM assumes the hardware is already in the ACPI mode and will not issue an ACPI_ENABLE", but it won't hurt to check the SCI_EN bit and enable ACPI during resume from S3 if this bit is not set. Fortunately, we already have acpi_enable() for that, so use it in the resume code path, before executing _BFS, in analogy with the resume-from-hibernation code path. NOTE: We aren't supposed to set SCI_EN directly, because it's owned by the hardware. Signed-off-by: Rafael J. Wysocki Acked-by: Pavel Machek Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 220d13c9015f53509245807f4e4d86e8d062a26d Author: Christian Borntraeger Date: Thu Oct 23 12:18:31 2008 +1100 hvc_console: Fix free_irq in spinlocked section commit eef2622a9fcfa964073333ea72c7c9cd20ad45e6 upstream hvc_console: Fix free_irq in spinlocked section commit 611e097d7707741a336a0677d9d69bec40f29f3d Author: Christian Borntraeger hvc_console: rework setup to replace irq functions with callbacks introduced a spinlock recursion problem. The notifier_del is called with a lock held, and in turns calls free_irq which then complains when manipulating procfs. This fixes it by moving the call to the notifier to outside of the locked section. Signed-off-by: Christian Borntraeger Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 07a96d7019701ce9e6be9bd975e4f9d021649a8f Author: Linus Torvalds Date: Sun Oct 19 10:32:20 2008 -0700 anon_vma_prepare: properly lock even newly allocated entries commit d9d332e0874f46b91d8ac4604b68ee42b8a7a2c6 upstream The anon_vma code is very subtle, and we end up doing optimistic lookups of anon_vmas under RCU in page_lock_anon_vma() with no locking. Other CPU's can also see the newly allocated entry immediately after we've exposed it by setting "vma->anon_vma" to the new value. We protect against the anon_vma being destroyed by having the SLAB marked as SLAB_DESTROY_BY_RCU, so the RCU lookup can depend on the allocation not being destroyed - but it might still be free'd and re-allocated here to a new vma. As a result, we should not do the anon_vma list ops on a newly allocated vma without proper locking. Acked-by: Nick Piggin Acked-by: Hugh Dickins Acked-by: Peter Zijlstra Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 373775331502999bcf0e37e8cb06488f65482939 Author: Patrick McHardy Date: Wed Oct 22 19:41:31 2008 +0200 netfilter: restore lost ifdef guarding defrag exception netfilter: restore lost #ifdef guarding defrag exception Upstream commit 38f7ac3eb: Nir Tzachar reported a warning when sending fragments over loopback with NAT: [ 6658.338121] WARNING: at net/ipv4/netfilter/nf_nat_standalone.c:89 nf_nat_fn+0x33/0x155() The reason is that defragmentation is skipped for already tracked connections. This is wrong in combination with NAT and ip_conntrack actually had some ifdefs to avoid this behaviour when NAT is compiled in. The entire "optimization" may seem a bit silly, for now simply restoring the lost #ifdef is the easiest solution until we can come up with something better. Signed-off-by: Patrick McHardy Signed-off-by: Greg Kroah-Hartman commit 2abb966556649d871174343386ad71b78e12a47a Author: Ilpo Järvinen Date: Wed Oct 22 19:41:29 2008 +0200 netfilter: snmp nat leaks memory in case of failure netfilter: snmp nat leaks memory in case of failure Upstream commit 311670f3e: Signed-off-by: Ilpo Jarvinen Signed-off-by: Patrick McHardy commit c903fcb8747d4b8c2af95e058877e106da23e82a Author: Alexey Dobriyan Date: Wed Oct 22 19:41:28 2008 +0200 netfilter: xt_iprange: fix range inversion match netfilter: xt_iprange: fix range inversion match Upstream commit 6def1eb48: Inverted IPv4 v1 and IPv6 v0 matches don't match anything since 2.6.25-rc1! Signed-off-by: Alexey Dobriyan Acked-by: Jan Engelhardt Signed-off-by: Patrick McHardy Signed-off-by: Greg Kroah-Hartman commit 382931f3e09030e7e4d7fcaee2ad3cdc1d396a14 Author: Eric Sandeen Date: Wed Oct 22 10:11:52 2008 -0500 ext[234]: Avoid printk floods in the face of directory corruption (CVE-2008-3528) This is a trivial backport of the following upstream commits: - bd39597cbd42a784105a04010100e27267481c67 (ext2) - cdbf6dba28e8e6268c8420857696309470009fd9 (ext3) - 9d9f177572d9e4eba0f2e18523b44f90dd51fe74 (ext4) This addresses CVE-2008-3528 ext[234]: Avoid printk floods in the face of directory corruption Note: some people thinks this represents a security bug, since it might make the system go away while it is printing a large number of console messages, especially if a serial console is involved. Hence, it has been assigned CVE-2008-3528, but it requires that the attacker either has physical access to your machine to insert a USB disk with a corrupted filesystem image (at which point why not just hit the power button), or is otherwise able to convince the system administrator to mount an arbitrary filesystem image (at which point why not just include a setuid shell or world-writable hard disk device file or some such). Me, I think they're just being silly. --tytso Signed-off-by: Eric Sandeen Signed-off-by: "Theodore Ts'o" Cc: linux-ext4@vger.kernel.org Cc: Eugene Teo Signed-off-by: Greg Kroah-Hartman commit 0f3da51e7046e2eb28992ba65c22d058f571356c Author: Jeff Layton Date: Thu Oct 23 18:05:02 2008 +0000 CIFS: fix saving of resume key before CIFSFindNext commit a364bc0b37f14ffd66c1f982af42990a9d77fa43 upstream We recently fixed the cifs readdir code so that it saves the resume key before calling CIFSFindNext. Unfortunately, this assumes that we have just done a CIFSFindFirst (or FindNext) and have resume info to save. This isn't necessarily the case. Fix the code to save resume info if we had to reinitiate the search, and after a FindNext. This fixes connectathon basic test6 against NetApp filers. Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 5880100d91db1337c6604bf704c08c3c3dd4bf13 Author: Andreas Herrmann Date: Thu Oct 23 17:35:28 2008 +0000 amd_iommu: fix nasty bug that caused ILLEGAL_DEVICE_TABLE_ENTRY errors commit f609891f428e1c20e270e7c350daf8c93cc459d7 upstream We are on 64-bit so better use u64 instead of u32 to deal with addresses: static void __init iommu_set_device_table(struct amd_iommu *iommu) { u64 entry; ... entry = virt_to_phys(amd_iommu_dev_table); ... (I am wondering why gcc 4.2.x did not warn about the assignment between u32 and unsigned long.) Cc: iommu@lists.linux-foundation.org Signed-off-by: Andreas Herrmann Signed-off-by: Joerg Roedel Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 1ea93b4aadc022277ddf92cf2aaa9ab00ca9a9b1 Author: Mikulas Patocka Date: Thu Oct 23 17:35:22 2008 +0000 dm snapshot: fix primary_pe race commit 7c5f78b9d7f21937e46c26db82976df4b459c95c upstream Fix a race condition with primary_pe ref_count handling. put_pending_exception runs under dm_snapshot->lock, it does atomic_dec_and_test on primary_pe->ref_count, and later does atomic_read primary_pe->ref_count. __origin_write does atomic_dec_and_test on primary_pe->ref_count without holding dm_snapshot->lock. This opens the following race condition: Assume two CPUs, CPU1 is executing put_pending_exception (and holding dm_snapshot->lock). CPU2 is executing __origin_write in parallel. primary_pe->ref_count == 2. CPU1: if (primary_pe && atomic_dec_and_test(&primary_pe->ref_count)) origin_bios = bio_list_get(&primary_pe->origin_bios); .. decrements primary_pe->ref_count to 1. Doesn't load origin_bios CPU2: if (first && atomic_dec_and_test(&primary_pe->ref_count)) { flush_bios(bio_list_get(&primary_pe->origin_bios)); free_pending_exception(primary_pe); /* If we got here, pe_queue is necessarily empty. */ return r; } .. decrements primary_pe->ref_count to 0, submits pending bios, frees primary_pe. CPU1: if (!primary_pe || primary_pe != pe) free_pending_exception(pe); .. this has no effect. if (primary_pe && !atomic_read(&primary_pe->ref_count)) free_pending_exception(primary_pe); .. sees ref_count == 0 (written by CPU 2), does double free !! This bug can happen only if someone is simultaneously writing to both the origin and the snapshot. If someone is writing only to the origin, __origin_write will submit kcopyd request after it decrements primary_pe->ref_count (so it can't happen that the finished copy races with primary_pe->ref_count decrementation). If someone is writing only to the snapshot, __origin_write isn't invoked at all and the race can't happen. The race happens when someone writes to the snapshot --- this creates pending_exception with primary_pe == NULL and starts copying. Then, someone writes to the same chunk in the snapshot, and __origin_write races with termination of already submitted request in pending_complete (that calls put_pending_exception). This race may be reason for bugs: http://bugzilla.kernel.org/show_bug.cgi?id=11636 https://bugzilla.redhat.com/show_bug.cgi?id=465825 The patch fixes the code to make sure that: 1. If atomic_dec_and_test(&primary_pe->ref_count) returns false, the process must no longer dereference primary_pe (because someone else may free it under us). 2. If atomic_dec_and_test(&primary_pe->ref_count) returns true, the process is responsible for freeing primary_pe. Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit c17e59af0d10fe9c5616109fab5ac879cad1cd61 Author: Kazuo Ito Date: Thu Oct 23 17:35:24 2008 +0000 dm kcopyd: avoid queue shuffle commit b673c3a8192e28f13e2050a4b82c1986be92cc15 upstream Write throughput to LVM snapshot origin volume is an order of magnitude slower than those to LV without snapshots or snapshot target volumes, especially in the case of sequential writes with O_SYNC on. The following patch originally written by Kevin Jamieson and Jan Blunck and slightly modified for the current RCs by myself tries to improve the performance by modifying the behaviour of kcopyd, so that it pushes back an I/O job to the head of the job queue instead of the tail as process_jobs() currently does when it has to wait for free pages. This way, write requests aren't shuffled to cause extra seeks. I tested the patch against 2.6.27-rc5 and got the following results. The test is a dd command writing to snapshot origin followed by fsync to the file just created/updated. A couple of filesystem benchmarks gave me similar results in case of sequential writes, while random writes didn't suffer much. dd if=/dev/zero of= bs=4096 count=... [conv=notrunc when updating] 1) linux 2.6.27-rc5 without the patch, write to snapshot origin, average throughput (MB/s) 10M 100M 1000M create,dd 511.46 610.72 11.81 create,dd+fsync 7.10 6.77 8.13 update,dd 431.63 917.41 12.75 update,dd+fsync 7.79 7.43 8.12 compared with write throughput to LV without any snapshots, all dd+fsync and 1000 MiB writes perform very poorly. 10M 100M 1000M create,dd 555.03 608.98 123.29 create,dd+fsync 114.27 72.78 76.65 update,dd 152.34 1267.27 124.04 update,dd+fsync 130.56 77.81 77.84 2) linux 2.6.27-rc5 with the patch, write to snapshot origin, average throughput (MB/s) 10M 100M 1000M create,dd 537.06 589.44 46.21 create,dd+fsync 31.63 29.19 29.23 update,dd 487.59 897.65 37.76 update,dd+fsync 34.12 30.07 26.85 Although still not on par with plain LV performance - cannot be avoided because it's copy on write anyway - this simple patch successfully improves throughtput of dd+fsync while not affecting the rest. Signed-off-by: Jan Blunck Signed-off-by: Kazuo Ito Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit 08177861a152254ba025b751559e592757e31475 Author: Alan Stern Date: Thu Oct 23 17:35:13 2008 +0000 USB: Speedtouch: add pre_reset and post_reset routines commit 8fc7aeab3851ed8c3ecf28901ca2c6f0400955c7 upstream This patch (as1150) fixes a problem in the speedtch driver. When it resets the modem during probe it will be unbound from the other interfaces it has claimed, because it doesn't define a pre_reset and a post_reset method. The patch defines "do-nothing" methods. This fixes Bugzilla #11767. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 837de9e1d92bb73408088f7b5849715d90925fee Author: Oliver Neukum Date: Thu Oct 23 17:35:09 2008 +0000 USB: fix memory leak in cdc-acm commit a496c64f1363ec4d67ebdc1e1f619ad6372a574c upstream This fixes a memory leak on disconnect in cdc-acm Thanks to 施金前 for finding it. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 1769c339cde4c1da819ee97513e9340413cef3c5 Author: Alan Stern Date: Thu Oct 23 17:35:07 2008 +0000 USB: don't rebind drivers after failed resume or reset commit 6c6409459a18a825ce12ecb003d5686af61f7a2f upstream This patch (as1152) may help prevent some problems associated with the new policy of unbinding drivers that don't support suspend/resume or pre_reset/post_reset. If for any reason the resume or reset fails, and the device is logically disconnected, there's no point in trying to rebind the driver. So the patch checks for success before carrying out the unbind/rebind. There was a report from one user that this fixed a problem he was experiencing, but the details never became fully clear. In any case, adding these tests can't hurt. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 8cece7795b1c359787261a150ac502b250c6699f Author: Oliver Neukum Date: Thu Oct 23 17:35:11 2008 +0000 USB: cdc-wdm: make module autoload work commit aa5380b904e7f896db0931320160bdea93e41f6a upstream this fixes an omission that led to no alias being computed for the cdc-wdm module. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 919e14cd03504d00e4ba13933ac229f7eca21444 Author: Miao Xie Date: Thu Oct 23 16:50:03 2008 +0000 sched: fix the wrong mask_len commit c851c8676bd7ae456e9b3af8e6bb2c434eddcc75 upstream If NR_CPUS isn't a multiple of 32, we get a truncated string of sched domains by catting /proc/schedstat. This is caused by the wrong mask_len. This patch fixes it. Signed-off-by: Miao Xie Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit bc79810633524ea09b77e3de3ba3f4a97f2152b7 Author: Rafael J. Wysocki Date: Mon Oct 20 21:30:19 2008 +0000 x86 ACPI: fix breakage of resume on 64-bit UP systems with SMP kernel commit 3038edabf48f01421c621cb77a712b446d3a5d67 upstream x86 ACPI: Fix breakage of resume on 64-bit UP systems with SMP kernel We are now using per CPU GDT tables in head_64.S and the original early_gdt_descr.address is invalidated after boot by setup_per_cpu_areas(). This breaks resume from suspend to RAM on x86_64 UP systems using SMP kernels, because this part of head_64.S is also executed during the resume and the invalid GDT address causes the system to crash. It doesn't break on 'true' SMP systems, because early_gdt_descr.address is modified every time native_cpu_up() runs. However, during resume it should point to the GDT of the boot CPU rather than to another CPU's GDT. For this reason, during suspend to RAM always make early_gdt_descr.address point to the boot CPU's GDT. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=11568, which is a regression from 2.6.26. Signed-off-by: Rafael J. Wysocki Acked-by: Pavel Machek Signed-off-by: Ingo Molnar Reported-and-tested-by: Andy Wettstein Signed-off-by: Greg Kroah-Hartman commit 204d439e5c39809d05f15b93cfabac1cbb99e1a7 Author: Benjamin Herrenschmidt Date: Mon Oct 20 16:50:07 2008 +0000 edac cell: fix incorrect edac_mode commit 3b274f44d2ca05f719fe39947b6a5293a2dbd8fd upstream The cell_edac driver is setting the edac_mode field of the csrow's to an incorrect value, causing the sysfs show routine for that field to go out of an array bound and Oopsing the kernel when used. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Doug Thompson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a2d18f62f58e8b5128c4ac7173ac15a8fa559b9c Author: David Brownell Date: Mon Oct 20 16:50:10 2008 +0000 gpiolib: fix oops in gpio_get_value_cansleep() commit 978ccaa8ea5d8c7bf6b676209f2fc126eae6355b upstream We can get the following oops from gpio_get_value_cansleep() when a GPIO controller doesn't provide a get() callback: Unable to handle kernel paging request for instruction fetch Faulting instruction address: 0x00000000 Oops: Kernel access of bad area, sig: 11 [#1] [...] NIP [00000000] 0x0 LR [c0182fb0] gpio_get_value_cansleep+0x40/0x50 Call Trace: [c7b79e80] [c0183f28] gpio_value_show+0x5c/0x94 [c7b79ea0] [c01a584c] dev_attr_show+0x30/0x7c [c7b79eb0] [c00d6b48] fill_read_buffer+0x68/0xe0 [c7b79ed0] [c00d6c54] sysfs_read_file+0x94/0xbc [c7b79ef0] [c008f24c] vfs_read+0xb4/0x16c [c7b79f10] [c008f580] sys_read+0x4c/0x90 [c7b79f40] [c0013a14] ret_from_syscall+0x0/0x38 It's OK to request the value of *any* GPIO; most GPIOs are bidirectional, so configuring them as outputs just enables an output driver and doesn't disable the input logic. So the problem is that gpio_get_value_cansleep() isn't making the same sanity check that gpio_get_value() does: making sure this GPIO isn't one of the atypical "no input logic" cases. Reported-by: Anton Vorontsov Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman