commit f8ebcb2ebc49a9ce184d738ca8f9bd570ac634b1 Author: Greg Kroah-Hartman Date: Tue Dec 8 11:13:50 2009 -0800 Linux 2.6.31.7 commit b02f6a9593cbe0c3a9cf6052acf58c11980d6efd Author: Roel Kluin Date: Wed Nov 4 08:31:59 2009 -0800 isdn: hfc_usb: Fix read buffer overflow commit 286e633ef0ff5bb63c07b4516665da8004966fec upstream. Check whether index is within bounds before testing the element. Signed-off-by: Roel Kluin Cc: Karsten Keil Signed-off-by: Andrew Morton Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 548193715cb69952c6655f8800d81a8bfe2d8bc5 Author: Samuel Thibault Date: Wed Nov 25 22:28:20 2009 -0800 Input: keyboard - fix braille keyboard keysym generation commit 46a965462a1c568a7cd7dc338de4a0afa5ce61c5 upstream. Keysyms stored in key_map[] are not simply K() values, but U(K()) values, as can be seen in the KDSKBENT ioctl handler. The kernel-generated braille keysyms thus need a U() call too. Signed-off-by: Samuel Thibault Signed-off-by: Andrew Morton Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit c0d2a80576cde5ecb6d0e0e62f7145da53a64ebd Author: Peter Feuerer Date: Tue Nov 17 14:07:21 2009 -0800 acerhdf: return temperature in milidegree instead of degree commit 7005291706341a11c094f39a756a01c9e649e5f9 upstream. Return temperature in milidegree instead of degree, as sysfs-api requires the temperature in milidegree. Signed-off-by: Peter Feuerer Tested-by: Borislav Petkov Cc: Andreas Mohr Signed-off-by: Andrew Morton Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 77540b842ef4e6cc73e6c67c59fa884c27275a0f Author: Peter Feuerer Date: Fri Sep 18 12:41:07 2009 -0700 acerhdf: additional BIOS versions commit f944915187f53810130eb1c56985e27e3cbe4a6d upstream. Added BIOS versions: Acer: AOA110-v0.3307, AOA150-v0.3301, AOA150-v0.3307 Packard Bell: AOA150-v0.3105 Signed-off-by: Peter Feuerer Cc: Andreas Mohr Cc: Borislav Petkov Signed-off-by: Andrew Morton Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 0823e602ad9d28d54fa6346289ff13ae84ad2c34 Author: Kenji Kaneshige Date: Wed Oct 7 09:28:56 2009 -0700 PCI: Prevent AER driver from being loaded on non-root port PCIE devices commit 30fc24b5cbc55f9e6c686e2710cc812419bddc0c upstream. A bug was seen on boards using a PLX 8518 switch device which advertises AER on each of it's transparent bridges. The AER driver was loaded for each bridge and this driver tried to access the AER source ID register whenever an interrupt occured on the shared PCI INTX lines. The source ID register does not exist on non root port PCIE device's which advertise AER and trying to access this register causes a unsupported request error on the bridge. Thus, when the next interrupt occurs, another error is found and the non existent source ID register is accessed again, and so it goes on. The result is a spammed dmesg with unsupported request PCI express errors on the bridge device that the AER driver is loaded against. Reported-by: Malcolm Crossley Signed-off-by: Kenji Kaneshige Tested-by: Malcolm Crossley Signed-off-by: Jesse Barnes Cc: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 9509e37c579356f4e0c22f00eb7f2cb783a40c05 Author: Erik Andrén Date: Sat Oct 3 10:01:41 2009 -0300 V4L/DVB (13257): gspca - m5602-s5k4aa: Add vflip for Fujitsu Amilo Xi 2528 commit 81191f694cb507c49d3c7aa6238dcc0a83ad4001 upstream. Adds a vflip quirk for the Fujitsu Amilo Xi 2528. Thanks to Evgeny for the report. Signed-off-by: Erik Andrén Signed-off-by: Mauro Carvalho Chehab commit c7694e85ae85e7b0f2ab6784090e496734653bd3 Author: Erik Andrén Date: Sun Sep 27 10:20:21 2009 -0300 V4L/DVB (13256): gspca - m5602-s5k4aa: Add another MSI GX700 vflip quirk commit 2339a1887dab469bb4bae56aa7eca3a5e05ecde7 upstream. Adds another vflip quirk for the MSI GX700. Thanks to John Katzmaier for reporting. Signed-off-by: Erik Andrén Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c48bcef7d779aa1febac7050196e24052746a672 Author: Erik Andrén Date: Sun Sep 27 10:11:43 2009 -0300 V4L/DVB (13255): gspca - m5602-s5k4aa: Add vflip quirk for the Bruneinit laptop commit b6ef8836c1ff5199abd40cfba162052bc7e8af00 upstream. Adds a vflip quirk for the Bruneinit laptop. Thanks to Jörg for the report Signed-off-by: Erik Andrén Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit e689a0b49fc3ef10f50764bd7e523ae76f849a91 Author: Michal Simek Date: Tue Nov 24 10:22:41 2009 +0000 tty/of_serial: add missing ns16550a id commit 16173c7c2d79da7eb89b41acfdebd74b130f4339 upstream. Many boards have a bug-free ns16550 compatible serial port, which we should register as PORT_16550A. This introduces a new value "ns16550a" for the compatible property of of_serial to let a firmware choose that model instead of using the crippled PORT_16550 mode. Reported-by: Alon Ziv Signed-off-by: Michal Simek Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 321cb431c5027d83257d8fbfd957f9d90b469e74 Author: Clemens Ladisch Date: Wed Dec 2 08:16:55 2009 +0100 drm/fb: fix FBIOGET/PUT_VSCREENINFO pixel clock handling commit 5349ef3127c77075ff70b2014f17ae0fbcaaf199 upstream When the framebuffer driver does not publish detailed timing information for the current video mode, the correct value for the pixclock field is zero, not -1. Since pixclock is actually unsigned, the value -1 would be interpreted as 4294967295 picoseconds (i.e., about 4 milliseconds) by register_framebuffer() and userspace programs. This patch allows X.org's fbdev driver to work. Signed-off-by: Clemens Ladisch Tested-by: Paulius Zaleckas Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit e7ec863bb38f66855c128df211082a026a81212e Author: Peter Feuerer Date: Thu Aug 6 15:57:52 2009 -0700 acerhdf: fix fan control for AOA150 model commit ded0cdfc6a7673916b0878c32fa8ba566b4f8cdb upstream. - Apply Borislav Petkov's patch (convert the fancmd[] array to a real struct thus disambiguating command handling and making code more readable.) - Add BIOS product to BIOS table as AOA110 and AOA150 have different register values - Add force_product parameter to allow forcing different product - fix linker warning caused by "acerhdf_drv" not being named "acerhdf_driver" Signed-off-by: Peter Feuerer Cc: Andreas Mohr Acked-by: Borislav Petkov Signed-off-by: Andrew Morton Signed-off-by: Len Brown Cc: Adrian von Bidder Signed-off-by: Greg Kroah-Hartman commit 95c2fff142fd3d44ba55cd6b3d9758c3215b52ca Author: Jean Delvare Date: Thu Nov 26 09:22:33 2009 +0100 i2c: Fix userspace_device list corruption commit bbd2d9c9198c6efd449e9d395b3eaf2d03aa3bba upstream. Fix userspace_device list corruption. The corruption was caused by clients not being removed when adapters with such clients were themselves removed. Something like the following would trigger it (assuming i2c-stub gets adapter number 3): # modprobe i2c-stub chip_addr=0x50 # echo 24c08 0x50 > /sys/bus/i2c/devices/i2c-3/new_device # rmmod i2c-stub # modprobe i2c-stub chip_addr=0x50 # echo 24c08 0x50 > /sys/bus/i2c/devices/i2c-3/new_device For the records, the stack trace in the kernel logs look like this: kernel: WARNING: at lib/list_debug.c:30 __list_add+0x8b/0x90() kernel: Hardware name: (...) kernel: list_add corruption. prev->next should be next (c137fc84), but was (null). (prev=f57111b8). kernel: Modules linked in: (...) kernel: Pid: 4669, comm: bash Not tainted 2.6.32-rc8 #259 kernel: Call Trace: kernel: [] ? __list_add+0x8b/0x90 kernel: [] ? __list_add+0x8b/0x90 kernel: [] warn_slowpath_common+0x6c/0xc0 kernel: [] ? __list_add+0x8b/0x90 kernel: [] warn_slowpath_fmt+0x26/0x30 kernel: [] __list_add+0x8b/0x90 kernel: [] i2c_sysfs_new_device+0x1c5/0x250 kernel: [] ? might_fault+0x2e/0x80 kernel: [] ? i2c_sysfs_new_device+0x0/0x250 kernel: [] dev_attr_store+0x25/0x30 kernel: [] sysfs_write_file+0x9c/0xf0 kernel: [] vfs_write+0x9c/0x160 kernel: [] ? sysfs_write_file+0x0/0xf0 kernel: [] sys_write+0x3d/0x70 kernel: [] sysenter_do_call+0x12/0x36 Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit d02b2ced79e2a22b38d6a4fdc758d070ff807d2b Author: Nick Kossifidis Date: Mon Aug 10 03:27:59 2009 +0300 ath5k: Linear PCDAC code fixes commit d1cb0bdac180a4afdd3c001acb2618d2a62d9abe upstream. * Set correct xpd curve indices for high/low gain curves during rfbuffer setup on RF5112B with both calibration curves available. * Don't return zero min power when we have the same pcdac value twice because it breaks interpolation. Instead return the right x barrier as we do when we have equal power levels for 2 different pcdac values. Signed-off-by: Nick Kossifidis Acked-by: Bob Copeland Signed-off-by: John W. Linville Cc: Dan Williams Signed-off-by: Greg Kroah-Hartman commit d801d0a919fd2e54ad91626a0cb7d006a9c6de84 Author: Brandon Philips Date: Thu Oct 29 13:58:07 2009 +0000 sky2: set carrier off in probe commit 33cb7d33a1c36e07839d08a4d1a33bf6a0f70bba upstream. Before bringing up a sky2 interface up ethtool reports "Link detected: yes". Do as ixgbe does and netif_carrier_off() on probe(). Signed-off-by: Brandon Philips Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c089a8dcd8a99f8c6505a539d45a754a9f84c9dd Author: Chuck Ebbert Date: Tue Nov 3 10:32:03 2009 -0500 crypto: padlock-aes - Use the correct mask when checking whether copying is required commit e8edb3cbd7dd8acf6c748a02d06ec1d82c4124ea upstream. Masking with PAGE_SIZE is just wrong... Signed-off-by: Chuck Ebbert Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 4a72cdf3871e086db051c70ade06c0570ac4d5b5 Author: Michael Buesch Date: Wed Oct 28 22:08:13 2009 +0100 b43: Fix DMA TX bounce buffer copying commit 9a3f45116f5e08819136cd512fd7f6450ac22aa8 upstream. b43 allocates a bouncebuffer, if the supplied TX skb is in an invalid memory range for DMA. However, this is broken in that it fails to copy over some metadata to the new skb. This patch fixes three problems: * Failure to adjust the ieee80211_tx_info pointer to the new buffer. This results in a kmemcheck warning. * Failure to copy the skb cb, which contains ieee80211_tx_info, to the new skb. This results in breakage of various TX-status postprocessing (Rate control). * Failure to transfer the queue mapping. This results in the wrong queue being stopped on saturation and can result in queue overflow. Signed-off-by: Michael Buesch Tested-by: Christian Casteyde Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 380cf591fc6682b1297415c7e90c17e578f3bf44 Author: Jan Engelhardt Date: Fri Nov 6 18:08:32 2009 -0800 netfilter: xt_connlimit: fix regression caused by zero family value commit 539054a8fa5141c9a4e9ac6a86d249e3f2bdef45 upstream. Commit v2.6.28-rc1~717^2~109^2~2 was slightly incomplete; not all instances of par->match->family were changed to par->family. References: http://bugzilla.netfilter.org/show_bug.cgi?id=610 Signed-off-by: Jan Engelhardt Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 325786e848323cd6c3e658886448ceafda09bf86 Author: Jozsef Kadlecsik Date: Fri Nov 6 00:43:42 2009 -0800 netfilter: nf_nat: fix NAT issue in 2.6.30.4+ commit f9dd09c7f7199685601d75882447a6598be8a3e0 upstream. Vitezslav Samel discovered that since 2.6.30.4+ active FTP can not work over NAT. The "cause" of the problem was a fix of unacknowledged data detection with NAT (commit a3a9f79e361e864f0e9d75ebe2a0cb43d17c4272). However, actually, that fix uncovered a long standing bug in TCP conntrack: when NAT was enabled, we simply updated the max of the right edge of the segments we have seen (td_end), by the offset NAT produced with changing IP/port in the data. However, we did not update the other parameter (td_maxend) which is affected by the NAT offset. Thus that could drift away from the correct value and thus resulted breaking active FTP. The patch below fixes the issue by *not* updating the conntrack parameters from NAT, but instead taking into account the NAT offsets in conntrack in a consistent way. (Updating from NAT would be more harder and expensive because it'd need to re-calculate parameters we already calculated in conntrack.) Signed-off-by: Jozsef Kadlecsik Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 636addb566d468fe7159e678d4c0d195dc77707d Author: Zhenyu Wang Date: Tue Nov 10 03:10:22 2009 +0000 agp/intel: new host bridge support commit 9cf1e35cb025eaa52dde37df38e2750b6adb1620 upstream. Add new CPU host bridge id, needed for support Ironlake graphics device with it. No change for graphics device itself, so no need to update drm/i915. Signed-off-by: Zhenyu Wang Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman commit 38504256170312f5fe8c097e06ba291c39ee814d Author: Jean Delvare Date: Mon Nov 16 12:45:40 2009 +0100 hwmon: (adt7475) Cache limits for 60 seconds commit 56e35eeebed2dcb4e1a17ad119e039cf095854ac upstream. The comment says that limits are cached for 60 seconds but the code actually caches them for only 2 seconds. Align the code on the comment, as 60 seconds makes more sense. Signed-off-by: Jean Delvare Acked-by: Hans de Goede Cc: Jordan Crouse Signed-off-by: Greg Kroah-Hartman commit e3675ca0caa78b55d2c3d3bf5ef0e406c835cbd1 Author: Jean Delvare Date: Mon Nov 16 12:45:39 2009 +0100 hwmon: (adt7475) Fix temperature fault flags commit cf312e077662ec3a07529551ab6e885828ccfb1d upstream. The logic of temperature fault flags is wrong, it shows faults when there are none and vice versa. Fix it. I can't believe this has been broken since the driver was added, 8 months ago, basically breaking temp1 and temp3, and nobody ever complained. Signed-off-by: Jean Delvare Acked-by: Hans de Goede Cc: Jordan Crouse Signed-off-by: Greg Kroah-Hartman commit ee3989464a4c4896ec29f5b1c2aae840fab8b73d Author: Neil Brown Date: Mon Oct 26 08:59:17 2009 +0100 block: use after free bug in __blkdev_get commit 960cc0f4fef607baabc2232fbd7cce5368a9dcfd upstream. commit 0762b8bde9729f10f8e6249809660ff2ec3ad735 (from 14 months ago) introduced a use-after-free bug which has just recently started manifesting in my md testing. I tried git bisect to find out what caused the bug to start manifesting, and it could have been the recent change to blk_unregister_queue (48c0d4d4c04) but the results were inconclusive. This patch certainly fixes my symptoms and looks correct as the two calls are now in the same order as elsewhere in that function. Signed-off-by: NeilBrown Acked-by: Tejun Heo Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit bb969fdc8c7e7675266a3697ad93945428fd89d6 Author: Antti Kaijanmäki Date: Mon Nov 23 10:54:47 2009 -0800 hso: fix soft-lockup commit dcfcb256cc23c4436691b0fe677275306699d6a1 upstream. Fix soft-lockup in hso.c which is triggered on SMP machine when modem is removed while file descriptor(s) under /dev are still open: old version called kref_put() too early which resulted in destroying hso_serial and hso_device objects which were still used later on. Signed-off-by: Antti Kaijanmäki Signed-off-by: Andrew Morton Signed-off-by: David S. Miller commit 415cc7b7fe6fd663139da295d7bd2cde556345f0 Author: Paul Mackerras Date: Wed Oct 14 16:58:03 2009 +1100 perf_event: Adjust frequency and unthrottle for non-group-leader events commit 03541f8b69c058162e4cf9675ec9181e6a204d55 upstream. The loop in perf_ctx_adjust_freq checks the frequency of sampling event counters, and adjusts the event interval and unthrottles the event if required, and resets the interrupt count for the event. However, at present it only looks at group leaders. This means that a sampling event that is not a group leader will eventually get throttled, once its interrupt count reaches sysctl_perf_event_sample_rate/HZ --- and that is guaranteed to happen, if the event is active for long enough, since the interrupt count never gets reset. Once it is throttled it never gets unthrottled, so it basically just stops working at that point. This fixes it by making perf_ctx_adjust_freq use ctx->event_list rather than ctx->group_list. The existing spin_lock/spin_unlock around the loop makes it unnecessary to put rcu_read_lock/ rcu_read_unlock around the list_for_each_entry_rcu(). Reported-by: Mark W. Krentel Signed-off-by: Paul Mackerras Cc: Corey Ashford Cc: Peter Zijlstra LKML-Reference: <19157.26731.855609.165622@cargo.ozlabs.ibm.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2a959cfd1e6eff5ce71693bb6f7e753d71f5f088 Author: NeilBrown Date: Tue Dec 1 17:30:59 2009 +1100 md: revert incorrect fix for read error handling in raid1. commit d0e260782c3702a009645c3caa02e381dab8798b upstream. commit 4706b349f was a forward port of a fix that was needed for SLES10. But in fact it is not needed in mainline because the earlier commit dd00a99e7a fixes the same problem in a better way. Further, this commit introduces a bug in the way it interacts with the automatic read-error-correction. If, after a read error is successfully corrected, the same disk is chosen to re-read - the re-read won't be attempted but an error will be returned instead. After reverting that commit, there is the possibility that a read error on a read-only array (where read errors cannot be corrected as that requires a write) will repeatedly read the same device and continue to get an error. So in the "Array is readonly" case, fail the drive immediately on a read error. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit a5aeface580afa4d2daba4980cd26f53ed31787a Author: Helge Deller Date: Thu Dec 3 00:29:15 2009 +0100 modules: don't export section names of empty sections via sysfs commit 35dead4235e2b67da7275b4122fed37099c2f462 upstream. On the parisc architecture we face for each and every loaded kernel module this kernel "badness warning": sysfs: cannot create duplicate filename '/module/ac97_bus/sections/.text' Badness at fs/sysfs/dir.c:487 Reason for that is, that on parisc all kernel modules do have multiple .text sections due to the usage of the -ffunction-sections compiler flag which is needed to reach all jump targets on this platform. An objdump on such a kernel module gives: Sections: Idx Name Size VMA LMA File off Algn 0 .note.gnu.build-id 00000024 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .text 00000000 00000000 00000000 00000058 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .text.ac97_bus_match 0000001c 00000000 00000000 00000058 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 3 .text 00000000 00000000 00000000 000000d4 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE ... Since the .text sections are empty (size of 0 bytes) and won't be loaded by the kernel module loader anyway, I don't see a reason why such sections need to be listed under /sys/module//sections/ either. The attached patch does solve this issue by not exporting section names which are empty. This fixes bugzilla http://bugzilla.kernel.org/show_bug.cgi?id=14703 Signed-off-by: Helge Deller CC: rusty@rustcorp.com.au CC: akpm@linux-foundation.org CC: James.Bottomley@HansenPartnership.com CC: roland@redhat.com CC: dave@hiauly1.hia.nrc.ca Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 96433ac605f72599f99f1300f56a57316f10d532 Author: Rusty Russell Date: Tue Dec 1 14:56:44 2009 +1030 param: don't complain about unused module parameters. commit f066a4f6df68f03b565dfe867dde54dfeb26576e upstream. Jon confirms that recent modprobe will look in /proc/cmdline, so these cmdline options can still be used. See http://bugzilla.kernel.org/show_bug.cgi?id=14164 Reported-by: Adam Williamson Signed-off-by: Rusty Russell Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9530e63015d1627cb46a485f7e6b8ba83ec4dca7 Author: Daniel Mack Date: Tue Dec 1 18:17:18 2009 +0100 pxamci: call mmc_remove_host() before freeing resources commit 5d6b1edf8ccc4b7e4e77dff3fc80882833d6186e upstream. mmc_remove_host() will cause the mmc core to switch off the bus power by eventually calling pxamci_set_ios(). This function uses the regulator or the GPIO which have been freed already. This causes the following Oops on module unload. [ 49.519649] Unable to handle kernel paging request at virtual address 30303a70 [ 49.526878] pgd = c7084000 [ 49.529563] [30303a70] *pgd=00000000 [ 49.533136] Internal error: Oops: 5 [#1] [ 49.537025] last sysfs file: /sys/devices/platform/pxa27x-ohci/usb1/1-1/1-1:1.0/host0/target0:0:0/0:0:0:0/scsi_level [ 49.547471] Modules linked in: pxamci(-) eeti_ts [ 49.552061] CPU: 0 Not tainted (2.6.32-rc8 #322) [ 49.557001] PC is at regulator_is_enabled+0x3c/0xbc [ 49.561846] LR is at regulator_is_enabled+0x30/0xbc [ 49.566691] pc : [] lr : [] psr: 60000013 [ 49.566702] sp : c7083e70 ip : 30303a30 fp : 00000000 [ 49.578093] r10: c705e200 r9 : c7082000 r8 : c705e2e0 [ 49.583280] r7 : c7061340 r6 : c7061340 r5 : c7083e70 r4 : 00000000 [ 49.589759] r3 : c04dc434 r2 : c04dc434 r1 : c03eecea r0 : 00000047 [ 49.596241] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 49.603329] Control: 0000397f Table: a7084018 DAC: 00000015 [ 49.609031] Process rmmod (pid: 1101, stack limit = 0xc7082278) [ 49.614908] Stack: (0xc7083e70 to 0xc7084000) [ 49.619238] 3e60: c7082000 c703c4f8 c705ea00 c04f4074 [ 49.627366] 3e80: 00000000 c705e3a0 ffffffff c0247ddc c70361a0 00000000 c705e3a0 ffffffff [ 49.635499] 3ea0: c705e200 bf006400 c78c4f00 c705e200 c705e3a0 ffffffff c705e200 ffffffff [ 49.643633] 3ec0: c04d8ac8 c02476d0 ffffffff c0247c60 c705e200 c0248678 c705e200 c0249064 [ 49.651765] 3ee0: ffffffff bf006204 c04d8ad0 c04d8ad0 c04d8ac8 bf007490 00000880 c00440c4 [ 49.659898] 3f00: 0000b748 c01c5708 bf007490 c01c44c8 c04d8ac8 c04d8afc bf007490 c01c4570 [ 49.668031] 3f20: bf007490 bf00750c c04f4258 c01c37a4 00000000 bf00750c c7083f44 c007b014 [ 49.676162] 3f40: 4000d000 6d617870 08006963 00000001 00000000 c7085000 00000001 00000000 [ 49.684287] 3f60: 4000d000 c7083f8c 00000001 bea01a54 00005401 c7ab1400 c00440c4 00082000 [ 49.692420] 3f80: bf00750c 00000880 c7083f8c 00000000 4000cfa8 00000000 00000880 bea01cc8 [ 49.700552] 3fa0: 00000081 c0043f40 00000000 00000880 bea01cc8 00000880 00000006 00000000 [ 49.708677] 3fc0: 00000000 00000880 bea01cc8 00000081 00000097 0000cca4 0000b748 00000000 [ 49.716802] 3fe0: 4001a4f0 bea01cc0 00018bf4 4001a4fc 20000010 bea01cc8 a063e021 a063e421 [ 49.724958] [] (regulator_is_enabled+0x3c/0xbc) from [] (mmc_regulator_set_ocr+0x14/0xd8) [ 49.734836] [] (mmc_regulator_set_ocr+0x14/0xd8) from [] (pxamci_set_ios+0xd8/0x17c [pxamci]) [ 49.745044] [] (pxamci_set_ios+0xd8/0x17c [pxamci]) from [] (mmc_power_off+0x50/0x58) [ 49.754555] [] (mmc_power_off+0x50/0x58) from [] (mmc_detach_bus+0x68/0xc4) [ 49.763207] [] (mmc_detach_bus+0x68/0xc4) from [] (mmc_stop_host+0xd4/0x1bc) [ 49.771944] [] (mmc_stop_host+0xd4/0x1bc) from [] (mmc_remove_host+0xc/0x20) [ 49.780681] [] (mmc_remove_host+0xc/0x20) from [] (pxamci_remove+0xc8/0x174 [pxamci]) [ 49.790211] [] (pxamci_remove+0xc8/0x174 [pxamci]) from [] (platform_drv_remove+0x1c/0x24) [ 49.800164] [] (platform_drv_remove+0x1c/0x24) from [] (__device_release_driver+0x7c/0xc4) [ 49.810110] [] (__device_release_driver+0x7c/0xc4) from [] (driver_detach+0x60/0x8c) [ 49.819535] [] (driver_detach+0x60/0x8c) from [] (bus_remove_driver+0x90/0xcc) [ 49.828452] [] (bus_remove_driver+0x90/0xcc) from [] (sys_delete_module+0x1d8/0x254) [ 49.837891] [] (sys_delete_module+0x1d8/0x254) from [] (ret_fast_syscall+0x0/0x28) [ 49.847145] Code: eb06c53a e596c030 e1a0500d e59f106c (e59c0040) [ 49.853566] ---[ end trace b5fa66a00cea142f ]--- Signed-off-by: Daniel Mack Reported-by: Sven Neumann Cc: Pierre Ossman Cc: linux-mmc@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Eric Miao Signed-off-by: Greg Kroah-Hartman commit d9abf6e4f67279f0ea926e6beef7baa9661dce75 Author: Alan Cox Date: Wed Nov 18 14:12:58 2009 +0000 tty_port: handle the nonblocking open of a dead port corner case commit 8627b96dd80dca440d91fbb1ec733be25912d0dd upstream. Some drivers allow O_NDELAY of a dead port (eg for setserial to work). In that situation we must not try to raise the carrier. Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman commit 77d12b19a0fe01d9e81baae809903ec329f84a15 Author: Oliver Neukum Date: Fri Nov 27 15:17:59 2009 +0100 USB: work around for EHCI with quirky periodic schedules commit ee4ecb8ac63a5792bec448037d4b82ec4144f94b upstream. a quirky chipset needs periodic schedules to run for a minimum time before they can be disabled again. This enforces the requirement with a time stamp and a calculated delay Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 144096993162a13f165f21aa89d7d95603b25c78 Author: Eric W. Biederman Date: Tue Nov 17 19:10:48 2009 -0800 USB: ftdi_sio: Keep going when write errors are encountered. commit 0de6ab8b91f2e1e8e7fc66a8b5c5e8ca82ea16b7 upstream. The use of urb->actual_length to update tx_outstanding_bytes implicitly assumes that the number of bytes actually written is the same as the number of bytes we tried to write. On error that assumption is violated so just use transfer_buffer_length the number of bytes we intended to write to the device. If an error occurs we need to fall through and call usb_serial_port_softint to wake up processes waiting in tty_wait_until_sent. Signed-off-by: Eric W. Biederman Signed-off-by: Greg Kroah-Hartman commit 774430b67775145d69362ca807d5f25db019919e Author: Thomas Dahlmann Date: Tue Nov 17 14:18:27 2009 -0800 usb: amd5536udc: fixed shared interrupt bug and warning oops commit c5deb832d7a3f9618b09e6eeaa91a1a845c90c65 upstream. - fixed shared interrupt bug reported by Vadim Lobanov - fixed possible warning oops on driver unload when connected - prevent interrupt flood in PIO mode ("modprobe amd5536udc use_dma=0") when using gadget ether Signed-off-by: Thomas Dahlmann Cc: Robert Richter Cc: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 41e0b0605826e299a981e2da61e631efe171f4af Author: Sergei Shtylyov Date: Wed Nov 18 22:51:18 2009 +0300 USB: musb_gadget: fix STALL handling commit cea83241b3a84499c4f9b12f8288f787e7aa6383 upstream. The driver incorrectly cancels the mass-storage device CSW request (which leads to device reset) due to giving back URB at the head of endpoint's queue after sending each STALL handshake; stop doing that and start checking for the queue being non-empty before stalling an endpoint and disallowing stall in such case in musb_gadget_set_halt() like the other gadget drivers do. Moreover, the driver starts Rx request despite of the endpoint being halted -- fix this by moving the SendStall bit check from musb_g_rx() to rxstate(). And we also sometimes get into rxstate() with DMA still active after clearing an endpoint's halt (not clear why), so bail out in this case, similarly to what txstate() does... While at it, also do the following changes : - in musb_gadget_set_halt(), remove pointless Tx FIFO flushing (the driver does not allow stalling with non-empty Tx FIFO anyway); - in rxstate(), stop pointlessly zeroing the 'csr' variable; - in musb_gadget_set_halt(), move the 'done' label to a more proper place; - in musb_g_rx(), eliminate the 'done' label completely... Signed-off-by: Sergei Shtylyov Signed-off-by: Greg Kroah-Hartman commit 3d57f55a87be678c0e3a91842a3ca2ca4ffcdcaf Author: Alan Stern Date: Wed Nov 18 11:37:15 2009 -0500 USB: EHCI: don't send Clear-TT-Buffer following a STALL commit c2f6595fbdb408d3d6850cfae590c8fa93e27399 upstream. This patch (as1304) fixes a regression in ehci-hcd. Evidently some hubs don't handle Clear-TT-Buffer requests correctly, so we should avoid sending them when they don't appear to be absolutely necessary. The reported symptom is that output on a downstream audio device cuts out because the hub stops relaying isochronous packets. The patch prevents Clear-TT-Buffer requests from being sent following a STALL handshake. In theory a STALL indicates either that the downstream device sent a STALL or that no matching TT buffer could be found. In either case, the transfer is completed and the TT buffer does not remain busy, so it doesn't need to be cleared. Also, the patch fixes a minor flaw in the code that actually sends the Clear-TT-Buffer requests. Although the pipe direction isn't really used for control transfers, it should be a Send rather than a Receive. Signed-off-by: Alan Stern Reported-by: Javier Kohen CC: David Brownell Signed-off-by: Greg Kroah-Hartman commit 7eeea230e8e078b125436e796cf30b71098107b7 Author: Rusty Russell Date: Mon Nov 2 23:35:30 2009 -0800 speedstep-ich: fix error caused by 394122ab144dae4b276d74644a2f11c44a60ac5c commit 8dca15e40889e5d5e9655b03ba79c26200f760ce upstream. "[CPUFREQ] cpumask: avoid playing with cpus_allowed in speedstep-ich.c" changed the code to mistakenly pass the current cpu as the "processor" argument of speedstep_get_frequency(), whereas it should be the type of the processor. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14340 Based on a patch by Dave Mueller. Signed-off-by: Rusty Russell Acked-by: Dominik Brodowski Reported-by: Dave Mueller Signed-off-by: Andrew Morton Signed-off-by: Dave Jones Signed-off-by: Greg Kroah-Hartman commit be488339a245d9b235a47ad563b0719bcfd5928c Author: David Ford Date: Sun Nov 29 23:02:22 2009 -0800 ipv4: additional update of dev_net(dev) to struct *net in ip_fragment.c, NULL ptr OOPS commit bbf31bf18d34caa87dd01f08bf713635593697f2 upstream. ipv4 ip_frag_reasm(), fully replace 'dev_net(dev)' with 'net', defined previously patched into 2.6.29. Between 2.6.28.10 and 2.6.29, net/ipv4/ip_fragment.c was patched, changing from dev_net(dev) to container_of(...). Unfortunately the goto section (out_fail) on oversized packets inside ip_frag_reasm() didn't get touched up as well. Oversized IP packets cause a NULL pointer dereference and immediate hang. I discovered this running openvasd and my previous email on this is titled: NULL pointer dereference at 2.6.32-rc8:net/ipv4/ip_fragment.c:566 Signed-off-by: David Ford Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c3f57df2bda0d830179b776166df0a100da733ac Author: Michael Krufky Date: Wed Nov 4 14:23:57 2009 -0300 V4L/DVB (13314): saa7134: set ts_force_val for the Hauppauge WinTV HVR-1150 commit 22370ef5035f206283505409c9a64a595c5c7320 upstream. The Hauppauge WinTV HVR-1150 retail boards require the FORCE_TS_VALID bit to be set in order to function properly. This change will work on the early revisions on the board as well, but the final revision will not function without this change. Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit ed3876a4e0cfc5cfcbbc4b3419586a858ecf8b56 Author: Michael Krufky Date: Wed Nov 4 14:19:35 2009 -0300 V4L/DVB (13313): saa7134: add support for FORCE_TS_VALID mode for mpeg ts input commit 4007a672abd88091e3cced158ec491d41c0c454c upstream. When FORCE_TS_VALID mode is enabled, the saa713x will accept MPEG TS input without requiring TS_VALID set high. This is required for some new boards to function properly, due to the hardware design implementation. The configuration is toggled within the board setup configuration. Boards that do not have this bit set will function as before with no change. Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 3a1e1a6cc13c5de16afe95304b7984a71c912829 Author: Michael Krufky Date: Wed Oct 21 18:27:29 2009 -0300 V4L/DVB (13202): smsusb: add autodetection support for three additional Hauppauge USB IDs commit 78c948ab0cc44f9c8ae397d7d9d217bb498bfa2f upstream. Add support for three new Hauppauge Device USB IDs: 2040:b900 2040:b910 2040:c000 Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab commit b4b4c13e3bb21e3c5f193b395dbb9c1a1202f399 Author: Rusty Russell Date: Wed Dec 2 14:09:16 2009 +1030 sched: Fix isolcpus boot option commit bdddd2963c0264c56f18043f6fa829d3c1d3d1c0 upstream. Anton Blanchard wrote: > We allocate and zero cpu_isolated_map after the isolcpus > __setup option has run. This means cpu_isolated_map always > ends up empty and if CPUMASK_OFFSTACK is enabled we write to a > cpumask that hasn't been allocated. I introduced this regression in 49557e620339cb13 (sched: Fix boot crash by zalloc()ing most of the cpu masks). Use the bootmem allocator if they set isolcpus=, otherwise allocate and zero like normal. Reported-by: Anton Blanchard Signed-off-by: Rusty Russell Cc: peterz@infradead.org Cc: Linus Torvalds LKML-Reference: <200912021409.17013.rusty@rustcorp.com.au> Signed-off-by: Ingo Molnar Tested-by: Anton Blanchard Signed-off-by: Greg Kroah-Hartman commit 8526322d0f88031465b2235c9e18a9f242dd6669 Author: Rusty Russell Date: Mon Nov 2 20:37:20 2009 +1030 sched: Fix boot crash by zalloc()ing most of the cpu masks commit 49557e620339cb134127b5bfbcfecc06b77d0232 upstream. I got a boot crash when forcing cpumasks offstack on 32 bit, because find_new_ilb() returned 3 on my UP system (nohz.cpu_mask wasn't zeroed). AFAICT the others need to be zeroed too: only nohz.ilb_grp_nohz_mask is initialized before use. Signed-off-by: Rusty Russell Cc: Peter Zijlstra LKML-Reference: <200911022037.21282.rusty@rustcorp.com.au> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 3c6f31de43c672ece8bcdd8262efd57c14c20c8f Author: David S. Miller Date: Sun Nov 8 17:41:20 2009 -0800 sparc: Move of_set_property_mutex acquisition outside of devtree_lock grab. [ Upstream commit 1c9d80ddc60f8ac26344ec3db9830e5f8016c16d ] Otherwise we try to sleep with preemption disabled, etc. Noticed by Thomas Gleixner. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e5ac34fd383ddae70158d220e45a25ad97b02452 Author: Roel Kluin Date: Sun Nov 8 00:26:56 2009 -0800 sparc64: replace parentheses in pmul() [ Upstream commit 88b938e63e68fd35e603421f722be0f35dde1016 ] `>>' has a higher precedence than `?' so src2 evaluated to either 16 or 0 dependent on the bits set in rs2. Signed-off-by: Roel Kluin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f7f7ef6ecdc4626f6b8a6a43b2c5be0e0e0a1bc7 Author: Ben Hutchings Date: Wed Oct 28 03:43:49 2009 -0700 sfc: Set ip_summed correctly for page buffers passed to GRO [ Upstream commit 345056af41feeda506a8993474b9cbb2c66bc9fb ] Page buffers containing packets with an incorrect checksum or using a protocol not handled by hardware checksum offload were previously not passed to LRO. The conversion to GRO changed this, but did not set the ip_summed value accordingly. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 193fe66e59fd31d6046727d6fdb9a232ad4cbd46 Author: Jasper Spaans Date: Fri Oct 23 04:08:46 2009 +0000 bonding: Modify hash transmit policies to use the packet's source MAC address [ Upstream commit d3da68310a2cf934c2ea8a99a519d8b1ccca4c56 ] Modify bonding hash transmit policies to use the psource MAC address of the packet instead of the MAC address configured for the bonding device. The old sitation conflicts with the documentation. Signed-off-by: Jasper Spaans Acked-by: Eric Dumazet Signed-off-by: Jay Vosburgh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5213d268ccd71d4e294650d83161cd93cfb6a21e Author: Eric Dumazet Date: Sun Nov 15 20:50:00 2009 -0800 net: fix sk_forward_alloc corruption [ Upstream commit: 9d410c796067686b1e032d54ce475b7055537138 ] On UDP sockets, we must call skb_free_datagram() with socket locked, or risk sk_forward_alloc corruption. This requirement is not respected in SUNRPC. Add a convenient helper, skb_free_datagram_locked() and use it in SUNRPC Reported-by: Francis Moreau Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fb97d3d0b3bab856c9419e727d543e4497da24b9 Author: Jamal Hadi Salim Date: Sun Oct 11 04:21:38 2009 +0000 pkt_sched: pedit use proper struct [ Upstream commit 53f7e35f8b7fc2f5620a863ac613bcf3080cb6ba ] This probably deserves to go into -stable. Pedit will reject a policy that is large because it uses the wrong structure in the policy validation. This fixes it. Signed-off-by: Jamal Hadi Salim Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e09fa919760c2639c6e49d2132bfdc6202cfa5e6 Author: Ben Hutchings Date: Mon Oct 12 04:18:48 2009 -0700 acenic: Pass up error code from ace_load_firmware() [ Upstream commit 6c60e0c30c80fcd53e61701b7865a85283f8a341 ] If ace_load_firmware() fails, ace_init() cleans up but still returns 0, leading to an oops as seen in . It should pass the error code up. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f2f3a6990f1c7dd8bb8e14cc8026faaf2d9ade21 Author: Eric Dumazet Date: Fri Oct 9 04:43:40 2009 +0000 udp: Fix udp_poll() and ioctl() [ Upstream commit 85584672012ee0c3b7b8e033a1ecf7c11878e45f ] udp_poll() can in some circumstances drop frames with incorrect checksums. Problem is we now have to lock the socket while dropping frames, or risk sk_forward corruption. This bug is present since commit 95766fff6b9a78d1 ([UDP]: Add memory accounting.) While we are at it, we can correct ioctl(SIOCINQ) to also drop bad frames. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6a36e5969e91cd0c13ffc83e83a2b8a718efe862 Author: Nanhai Zou Date: Fri Nov 6 02:13:01 2009 +0000 drm/i915: Fix IRQ stall issue on Ironlake commit 2d109a845dd3074885db726892c629ab73dd0ed8 upstream. The master irq control in DE must be disabled before irq handling, and enable after the process. This fixes the irq stall issue on Ironlake. Signed-off-by: Nanhai Zou Signed-off-by: Zhenyu Wang Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman commit a75c6447907a732d612fd399e8765f661cca77a7 Author: Jesse Barnes Date: Thu Nov 5 10:12:54 2009 -0800 drm: work around EDIDs with bad htotal/vtotal values commit 7064fef56369c9e2c6e35ff6d6b4b63d42a859ce upstream. We did this on the userspace side, but we need a similar fix for the kernel. Fixes LP #460664. Signed-off-by: Jesse Barnes Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 2ca6ea590d90073119d1471c79cc6f0df28f4747 Author: Chris Wilson Date: Sun Nov 22 15:40:31 2009 +0000 drm/i915: Select CONFIG_SHMEM commit ca9ab10033d190c1ede85fdf456307bdfdabf079 upstream. The driver requires shmfs as the backing filesystem to handle the buffer objects, so ensure it is selected if the user chooses to build our driver. Fixes: Bug 14662 - Dell E5500 kernel panic with KMS http://bugzilla.kernel.org/show_bug.cgi?id=14662 The revealing nature of the panic is the NULL function pointer dereference in read_cache_page_async(). Signed-off-by: Chris Wilson Reported-and-tested-by: Mateusz Kaduk Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman commit 1519b64ba60656727f91962e65ca2ae667e81f8a Author: Jean-Francois Moine Date: Tue Sep 1 14:52:04 2009 -0300 V4L/DVB (12696): gspca - sonixj / sn9c102: Two drivers for 0c45:60fc and 0c45:613e. commit f077b0a64856c5b3bf346ae9fba8631c1fb210cf upstream. Let 0c45:60fc in sn9c102 and 0c45:613e in gspca-sonixj (sensor not supported). Signed-off-by: Jean-Francois Moine Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman commit 338d606407cbb3e80555a513347bdd2359f3c48a Author: Jean-Francois Moine Date: Sat Aug 29 07:11:58 2009 -0300 V4L/DVB (12691): gspca - sonixj: Don't use mdelay(). commit 1f78a976ce18bc98e8b509cee04c5b3756098614 upstream. Signed-off-by: Jean-Francois Moine Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman commit ab5b96818a7ad40cab085ce978040811fb857aa0 Author: Jean-Francois Moine Date: Tue Aug 25 06:14:54 2009 -0300 V4L/DVB (12501): gspca - sonixj: Do the ov7660 sensor work again. commit 47f7f6fb7949b6546baf4b6f26bf0ca075d12759 upstream. - bad sensor power - bad edge gain/threshold - set back the auto gain - light frequency filter inverted Signed-off-by: Jean-Francois Moine Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman commit 8e6666b224aeac899eccbf29020b1556b9f8f151 Author: Denis Loginov Date: Tue Jul 28 03:39:10 2009 -0300 V4L/DVB (12356): gspca - sonixj: Webcam 0c45:6148 added commit 6baefab531b22288be3b4ddef5671ea6469b09f8 upstream. Signed-off-by: Denis Loginov Signed-off-by: Jean-Francois Moine Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman commit 0c8953efd523d634df7a65e7e15f269af46bd384 Author: Jean-Francois Moine Date: Wed Jul 8 06:33:44 2009 -0300 V4L/DVB (12280): gspca - sonixj: Remove auto gain/wb/expo for the ov7660 sensor. commit d8f400efc1ef7b344e07590fb6b77431bc358ba0 upstream. Signed-off-by: Jean-Francois Moine Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman commit a2ddf6aff5cd6f0a6a00e226720900a473480278 Author: Hans Verkuil Date: Tue Sep 15 08:08:20 2009 -0300 V4L/DVB (12948): v4l1-compat: fix VIDIOC_G_STD handling commit 707ca1e30f087f9a6d144693dafc4b67880678c2 upstream. The VIDIOC_G_STD ioctl may not be present in the case of radio receivers. In that case G_STD will return an error. The v4l1-compat layer should not attempt to propagate that error to the caller, instead it should be ignored. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman commit 7087c84b4239187f0196a35dcc577aecf7eca77c Author: Hans Verkuil Date: Thu Nov 5 13:26:32 2009 -0300 V4L/DVB (13321): radio-gemtek-pci: fix double mutex_lock commit 3addbb8075c00e2a2408c192bd1002dead26b2aa upstream. Double mutexlock found by the Linux Driver Verification project and reported by Alexander Strakh. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman commit 975894c3493caf60061d228262107d2636863125 Author: Robert Lowery Date: Sun Nov 8 00:00:11 2009 -0300 V4L/DVB (13436): cxusb: Fix hang on DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) commit 0bc3518019f917a370935055f07698a4e9b3ea20 upstream. Address yet another regression introduced by the introduction of the zl10353 disable_i2c_gate field. djh - I unmangled the patch which apparently got screwed up in the user's email client. Signed-off-by: Robert Lowery Signed-off-by: Devin Heitmueller Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman commit 37ed9bf8e31377284ca719b823e6794386ee0d5b Author: Harald Welte Date: Tue Nov 24 16:53:00 2009 +0100 Enable ACPI PDC handshake for VIA/Centaur CPUs commit d77b81974521c82fa6fda38dfff1b491dcc62a32 upstream. In commit 0de51088e6a82bc8413d3ca9e28bbca2788b5b53, we introduced the use of acpi-cpufreq on VIA/Centaur CPU's by removing a vendor check for VENDOR_INTEL. However, as it turns out, at least the Nano CPU's also need the PDC (processor driver capabilities) handshake in order to activate the methods required for acpi-cpufreq. Since arch_acpi_processor_init_pdc() contains another vendor check for Intel, the PDC is not initialized on VIA CPU's. The resulting behavior of a current mainline kernel on such systems is: acpi-cpufreq loads and it indicates CPU frequency changes. However, the CPU stays at a single frequency This trivial patch ensures that init_intel_pdc() is called on Intel and VIA/Centaur CPU's alike. Signed-off-by: Harald Welte Signed-off-by: Dave Jones Signed-off-by: Greg Kroah-Hartman commit 57ce46ef790bc67038322ed59c26f6d8eed9ee61 Author: Roel Kluin Date: Fri Nov 20 19:48:23 2009 +0100 thinkpad-acpi: fix sign of ERESTARTSYS return commit 80a8d1228e90349b4514e8c925c061fa5cbcea75 upstream. The returned error should be negative Signed-off-by: Roel Kluin Acked-by: Henrique de Moraes Holschuh Signed-off-by: Andrew Morton Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 899da70ca5dc094f506e82c60ef09ce5bd09bb94 Author: Johannes Berg Date: Mon Nov 23 11:27:30 2009 +0100 rfkill: fix miscdev ops commit 45ba564d765d6165330e9bb14a197bdd348c114d upstream. The /dev/rfkill ops don't refer to the module, so it is possible to unload the module while file descriptors are open. Fix this oversight. Reported-by: Maxim Levitsky Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 8d0d5e22d59bfd6d58df4f4111bea6dd6b9f9920 Author: Larry Finger Date: Wed Jul 29 10:54:06 2009 -0500 b43: Work around mac80211 race condition commit 18c6951091eca7645005a71b556106cc99a6f4b1 upstream. As shown in http://thread.gmane.org/gmane.linux.kernel.wireless.general/36497, mac80211 has a bug that allows a call to the TX routine after the queues have been stopped. This situation will only occur under extreme stress. Although b43 does not crash when this condition occurs, it does generate a WARN_ON and also logs a queue overrun message. This patch recognizes b43 is not at fault and logs a message only when the most verbose debugging mode is enabled. In the unlikely event that the queue is not stopped when the DMA queue becomes full, then a warning is issued. During testing of this patch with one output stream running repeated tcpperf writes and a second running a flood ping, this routine was entered with the DMA ring stopped about once per hour. The condition where the DMA queue is full but the ring has not been stopped has never been seen by me. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Cc: Michael Buesch Signed-off-by: Greg Kroah-Hartman commit b62b52ae0de1bb97f8c9dfe4609270493d77c7c4 Author: Johannes Berg Date: Sun Nov 22 12:28:41 2009 +0100 mac80211: fix spurious delBA handling commit 827d42c9ac91ddd728e4f4a31fefb906ef2ceff7 upstream. Lennert Buytenhek noticed that delBA handling in mac80211 was broken and has remotely triggerable problems, some of which are due to some code shuffling I did that ended up changing the order in which things were done -- this was commit d75636ef9c1af224f1097941879d5a8db7cd04e5 Author: Johannes Berg Date: Tue Feb 10 21:25:53 2009 +0100 mac80211: RX aggregation: clean up stop session and other parts were already present in the original commit d92684e66091c0f0101819619b315b4bb8b5bcc5 Author: Ron Rindjunsky Date: Mon Jan 28 14:07:22 2008 +0200 mac80211: A-MPDU Tx add delBA from recipient support The first problem is that I moved a BUG_ON before various checks -- thereby making it possible to hit. As the comment indicates, the BUG_ON can be removed since the ampdu_action callback must already exist when the state is != IDLE. The second problem isn't easily exploitable but there's a race condition due to unconditionally setting the state to OPERATIONAL when a delBA frame is received, even when no aggregation session was ever initiated. All the drivers accept stopping the session even then, but that opens a race window where crashes could happen before the driver accepts it. Right now, a WARN_ON may happen with non-HT drivers, while the race opens only for HT drivers. For this case, there are two things necessary to fix it: 1) don't process spurious delBA frames, and be more careful about the session state; don't drop the lock 2) HT drivers need to be prepared to handle a session stop even before the session was really started -- this is true for all drivers (that support aggregation) but iwlwifi which can be fixed easily. The other HT drivers (ath9k and ar9170) are behaving properly already. Reported-by: Lennert Buytenhek Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit a9f5433f6f88aaad161d23a595a86b3d1ae739fb Author: Johannes Berg Date: Fri Nov 20 09:15:51 2009 +0100 mac80211: fix two remote exploits commit 4253119acf412fd686ef4bd8749b5a4d70ea3a51 upstream. Lennert Buytenhek noticed a remotely triggerable problem in mac80211, which is due to some code shuffling I did that ended up changing the order in which things were done -- this was in commit d75636ef9c1af224f1097941879d5a8db7cd04e5 Author: Johannes Berg Date: Tue Feb 10 21:25:53 2009 +0100 mac80211: RX aggregation: clean up stop session The problem is that the BUG_ON moved before the various checks, and as such can be triggered. As the comment indicates, the BUG_ON can be removed since the ampdu_action callback must already exist when the state is OPERATIONAL. A similar code path leads to a WARN_ON in ieee80211_stop_tx_ba_session, which can also be removed. Cc: Lennert Buytenhek Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 57ee10d0308f0ae7699fef496a5f9924a82b9903 Author: Anuj Aggarwal Date: Fri Nov 27 17:40:58 2009 +0530 ASoC: AIC23: Fixing infinite loop in resume path commit e9ff5eb2ae018fe2298c68746c873bf828c6b10e upstream. This patch fixes two issues: a) Infinite loop in resume function b) Writes to non-existing registers in resume function Signed-off-by: Anuj Aggarwal Acked-by: Liam Girdwood Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f624cb3a3de1c02ae8d7dd87cbe19c2aa376421d Author: Mark Brown Date: Mon Nov 23 13:11:53 2009 +0000 ASoC: Fix suspend with active audio streams commit 50b6bce59d154b5db137907a5c0ed45a4e7a3829 upstream. When we get a stream suspend event force the power down since otherwise the stream would remain marked as active. In future we'll probably want to make this stream-specific and add an interface to make the power down of other widgets optional in order to support leaving bypass paths active while suspending the processor. Reported-by: Joonyoung Shim Tested-by: Joonyoung Shim Acked-by: Liam Girdwood Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b79250a273007d1d7f3884c4bc50860c7910b347 Author: Csaba Henk Date: Fri Nov 27 19:30:14 2009 +0530 fuse: reject O_DIRECT flag also in fuse_create commit 1b7323965a8c6eee9dc4e345a7ae4bff1dc93149 upstream. The comment in fuse_open about O_DIRECT: "VFS checks this, but only _after_ ->open()" also holds for fuse_create, however, the same kind of check was missing there. As an impact of this bug, open(newfile, O_RDWR|O_CREAT|O_DIRECT) fails, but a stub newfile will remain if the fuse server handled the implied FUSE_CREATE request appropriately. Other impact: in the above situation ima_file_free() will complain to open/free imbalance if CONFIG_IMA is set. Signed-off-by: Csaba Henk Signed-off-by: Miklos Szeredi Cc: Harshavardhana Signed-off-by: Greg Kroah-Hartman commit aa7c7f8c1b47d415f3cca42f0a2aa22d8539860e Author: Trond Myklebust Date: Wed Nov 11 16:15:42 2009 +0900 NFSv4: Fix a cache validation bug which causes getcwd() to return ENOENT commit 96d25e532234bec1a1989e6e1baf702d43a78b0d upstream. Changeset a65318bf3afc93ce49227e849d213799b072c5fd (NFSv4: Simplify some cache consistency post-op GETATTRs) incorrectly changed the getattr bitmap for readdir(). This causes the readdir() function to fail to return a fileid/inode number, which again exposed a bug in the NFS readdir code that causes spurious ENOENT errors to appear in applications (see http://bugzilla.kernel.org/show_bug.cgi?id=14541). The immediate band aid is to revert the incorrect bitmap change, but more long term, we should change the NFS readdir code to cope with the fact that NFSv4 servers are not required to support fileids/inode numbers. Reported-by: Daniel J Blueman Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 8bc4be6e44a5b9931b9bf0b9b267e2264f71075d Author: Mimi Zohar Date: Wed Nov 18 16:16:06 2009 -0500 ima: replace GFP_KERNEL with GFP_NOFS commit c09c59e6a070d6af05f238f255aea268185273ef upstream. While running fsstress tests on the NFSv4 mounted ext3 and ext4 filesystem, the following call trace was generated on the nfs server machine. Replace GFP_KERNEL with GFP_NOFS in ima_iint_insert() to avoid a potential deadlock. ================================= [ INFO: inconsistent lock state ] 2.6.31-31.el6.x86_64 #1 --------------------------------- inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage. kswapd2/75 [HC0[0]:SC0[0]:HE1:SE1] takes: (jbd2_handle){+.+.?.}, at: [] jbd2_journal_start+0xfe/0x13f {RECLAIM_FS-ON-W} state was registered at: [] mark_held_locks+0x65/0x99 [] lockdep_trace_alloc+0xbd/0xf5 [] kmem_cache_alloc+0x40/0x185 [] ima_iint_insert+0x3d/0xf1 [] ima_inode_alloc+0x25/0x44 [] inode_init_always+0xec/0x271 [] alloc_inode+0x51/0xa1 [] new_inode+0x2e/0x94 [] ext4_new_inode+0xb8/0xdc9 [] ext4_create+0xcf/0x175 [] vfs_create+0x82/0xb8 [] do_filp_open+0x32c/0x9ee [] do_sys_open+0x6c/0x12c [] sys_open+0x2e/0x44 [] system_call_fastpath+0x16/0x1b [] 0xffffffffffffffff irq event stamp: 90371 hardirqs last enabled at (90371): [] kmem_cache_alloc+0xf0/0x185 hardirqs last disabled at (90370): [] kmem_cache_alloc+0x89/0x185 softirqs last enabled at (89492): [] __do_softirq+0x1bf/0x1eb softirqs last disabled at (89477): [] call_softirq+0x1c/0x30 other info that might help us debug this: 2 locks held by kswapd2/75: #0: (shrinker_rwsem){++++..}, at: [] shrink_slab+0x44/0x177 #1: (&type->s_umount_key#25){++++..}, at: [] Reported-by: Muni P. Beerakam Reported-by: Amit K. Arora Signed-off-by: Mimi Zohar Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 2b41cc435f74811a0fe4894b9d0a3e2e476cfa53 Author: Wey-Yi Guy Date: Wed Nov 25 11:03:48 2009 -0800 iwlwifi: Fix issue on file transfer stalled in HT mode commit d01032e4fd33110f9f3a085a36cb819c1dfc5827 upstream Turn on RTS/CTS for HT to prevent uCode TX fifo underrun This is fix for http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2103 Signed-off-by: Wey-Yi Guy Tested-by: Jiajia Zheng Signed-off-by: Reinette Chatre Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 5a68dad11fc3c75ba97113e5bbd431d20dd36786 Author: Wey-Yi Guy Date: Wed Nov 25 11:03:47 2009 -0800 iwlwifi: Use RTS/CTS as the preferred protection mechanism for 6000 series commit 73871f7181a1406c67e93c8c83f5edb26057a2a6 upstream When 802.11g was introduced, we had RTS/CTS and CTS-to-Self protection mechanisms. In an HT Beacon, HT stations use the "Operating Mode" field in the HT Information Element to determine whether or not to use protection. The Operating Mode field has 4 possible settings: 0-3: Mode 0: If all stations in the BSS are 20/40 MHz HT capable, or if the BSS is 20/40 MHz capable, or if all stations in the BSS are 20 MHz HT stations in a 20 MHz BSS Mode 1: used if there are non-HT stations or APs using the primary or secondary channels Mode 2: if only HT stations are associated in the BSS and at least one 20 MHz HT station is associated. Mode 3: used if one or more non-HT stations are associated in the BSS. When in operating modes 1 or 3, and the Use_Protection field is 1 in the Beacon's ERP IE, all HT transmissions must be protected using RTS/CTS or CTS-to-Self. By default, CTS-to-self is the preferred protection mechanism for less overhead and higher throughput; but using the full RTS/CTS will better protect the inner exchange from interference, especially in highly-congested environment. For 6000 series WIFI NIC, RTS/CTS protection mechanism is the recommended choice for HT traffic based on the HW design. Signed-off-by: Wey-Yi Guy Signed-off-by: Reinette Chatre Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit ee003b24971b5d4015f01eb5f90cb204ed42afb4 Author: Sarah Sharp Date: Wed Nov 4 11:22:19 2009 -0800 USB: xhci: Fix scratchpad deallocation. commit 5294bea40666db5c5d6c336b8e4e55d69fa576ca upstream. The scratchpad_free() function uses xhci->page_size to free some memory with pci_free_consistent(). However, the page_size is set to zero before the call, causing kernel oopses on driver unload. Call scratchpad_free() before setting xhci->page_size to zero. Signed-off-by: Sarah Sharp Acked-by: John Youn Signed-off-by: Greg Kroah-Hartman commit 03a3cf4a7ac175a511a4d9d89a6b2e9eefbb73fe Author: Sarah Sharp Date: Tue Nov 3 22:02:24 2009 -0800 USB: xhci: Fix TRB physical to virtual address translation. commit 2fa88daa6f299bfb83672c3b525d786ad03b4735 upstream. The trb_in_td() function in the xHCI driver is supposed to translate a physical transfer buffer request (TRB) into a virtual pointer to the ring segment that TRB is in. Unfortunately, a mistake in this function may cause endless loops as the driver searches through the linked list of ring segments over and over again. Fix a couple bugs that may lead to loops or bad output: 1. Bail out if we get a NULL pointer when translating the segment's private structure and the starting DMA address of the segment chunk. If this happens, we've been handed a starting TRB pointer from a different ring. 2. Make sure the function works when there's multiple segments in the ring. In the while loop to search through the ring segments, use the current segment variable (cur_seg), rather than the starting segment variable (start_seg) that is passed in. 3. Stop searching the ring if we've run through all the segments in the ring. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 4d10d9eb04a6fdbb9cd9579835f7006751e558d1 Author: Sarah Sharp Date: Tue Nov 3 22:02:22 2009 -0800 USB: xhci: Fix bug memory free after failed initialization. commit d94c05e33d9212ee67b8d4998f984cc71df8168b upstream. If the xHCI driver fails during the memory initialization, xhci->ir_set may not be a valid pointer. Check that it points to valid DMA'able memory before writing to that address during the memory freeing process. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit c859382e8e6c1347d0b34dc72b2c096b07113fd1 Author: Henry Gebhardt Date: Wed Nov 4 11:19:28 2009 +0100 USB: cdc_acm: Fix race condition when opening tty commit 18a77b5d237a67d2c621a46f5271a3b51da1b380 upstream. If acm_rx_tasklet() gets called before tty_port_block_til_ready() returns, then bulk IN urbs may not be sent. This fixes it. Signed-off-by: Henry Gebhardt Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 25838ae5be73ec1b27866b49961b50153bef9fd8 Author: Zhang Le Date: Wed Nov 4 23:22:59 2009 +0800 USB: option.c: add support for D-Link DWM-162-U5 commit ff854ce0b17161a86b5ae444c6cb0aa221720fab upstream. Add D-Link DWM-162-U5 device id 1e0e:ce16 into option driver. The device has 4 interfaces, of which 1 is handled by storage and the other 3 by option driver. The device appears first as CD-only 05c6:2100 device and must be switched to 1e0e:ce16 mode either by using "eject CD" or usb_modeswitch. The MessageContent for usb_modeswitch.conf is: "55534243e0c26a85000000000000061b000000020000000000000000000000" Signed-off-by: Zhang Le Signed-off-by: Greg Kroah-Hartman commit 5f1e43635144fd054218d3423ab4c86c2ea16755 Author: Alan Stern Date: Wed Nov 4 11:35:53 2009 -0500 USB: usbmon: fix bug in mon_buff_area_shrink commit fca94748c5136ff390eadc443871b82f1f77dcd6 upstream. This patch (as1299b) fixes a bug in an error-handling path of usbmon's binary interface. The storage area for URB data is divided into fixed-size blocks. If an URB's data can't be copied, the area reserved for it should be decreased to the size of the truncated information (rounded up to a block boundary). Rounding up the amount to be removed and subtracting it from the reserved size is definitely the wrong thing to do. Also, when the data for an isochronous URB can't be copied, we can still copy the isoc packet descriptors. In fact the current code does copy the descriptors, but then sets the capture length to 0 so they remain inaccessible. The capture length should be reduced to the length of the descriptors, not set to 0. Signed-off-by: Alan Stern Acked-by: Pete Zaitcev Signed-off-by: Greg Kroah-Hartman commit 49cb656ba98a71f5dbc0f7c5dd2b1e35d32e673d Author: Libin Yang Date: Wed Nov 4 14:55:18 2009 +0800 USB: ohci: quirk AMD prefetch for USB 1.1 ISO transfer commit a1f17a872bc7b1cb7efdd5486a2963e88a536e61 upstream. The following patch in the driver is required to avoid USB 1.1 device failures that may occur due to requests from USB OHCI controllers may be overwritten if the latency for any pending request by the USB controller is very long (in the range of milliseconds). Signed-off-by: Libin Yang Cc: David Brownell Cc: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 7fcbd9ff6078339a4aed470b2ddde43960291e98 Author: Alan Cox Date: Wed Oct 28 21:12:33 2009 +0100 tty: cp210x: Fix carrier handling commit d94c7bd4c1361cab58a21d530078c5673863dcc2 upstream. Original discussion: http://thread.gmane.org/gmane.linux.usb.general/23217/focus=23248 or http://marc.info/?l=linux-usb&m=125553790714133&w=2 9a68e39d4a701fb3be03cae9b462408664ebd205 broke carrier handling so that a cp210x setup which needed the carrier lines set up (non CLOCAL) which did not make a call which set the termios bits left the lines down even if CLOCAL was not asserted. Fix this not by reverting but by adding the proper dtr_rts and carrier_raised methods. This both sets the modem lines properly and also implements the correct blocking semantics for the port as required by POSIX. Signed-off-by: Alan Cox Reported-by: Karl Hiramoto Tested-by: Karl Hiramoto Signed-off-by: Greg Kroah-Hartman commit 8f34cea85b340d1057d9251e38d6b000898c659f Author: Alan Cox Date: Wed Oct 28 21:12:32 2009 +0100 tty_port: If we are opened non blocking we still need to raise the carrier commit 4175f3e31cc7157669aa66d46dc79de6ae0126ce upstream. Original discussion: http://thread.gmane.org/gmane.linux.usb.general/23217/focus=23248 or http://marc.info/?l=linux-usb&m=125553790714133&w=2 The tty_port code inherited a bug common to various drivers it was based upon. If the tty is opened O_NONBLOCK we do not wait for the carrier to be raised but we must still raise our modem lines if appropriate. (There is a second question here about whether we should do so if CLOCAL is set but that can wait) Signed-off-by: Alan Cox Reported-by: Karl Hiramoto Tested-by: Karl Hiramoto Signed-off-by: Greg Kroah-Hartman commit ffb83b9e7d0e935ccc665ed09f2f7273828c9cfb Author: Mel Gorman Date: Wed Nov 11 14:26:14 2009 -0800 page allocator: always wake kswapd when restarting an allocation attempt after direct reclaim failed commit cc4a6851466039a8a688c843962a05689059ff3b upstream. If a direct reclaim makes no forward progress, it considers whether it should go OOM or not. Whether OOM is triggered or not, it may retry the allocation afterwards. In times past, this would always wake kswapd as well but currently, kswapd is not woken up after direct reclaim fails. For order-0 allocations, this makes little difference but if there is a heavy mix of higher-order allocations that direct reclaim is failing for, it might mean that kswapd is not rewoken for higher orders as much as it did previously. This patch wakes up kswapd when an allocation is being retried after a direct reclaim failure. It would be expected that kswapd is already awake, but this has the effect of telling kswapd to reclaim at the higher order as well. Signed-off-by: Mel Gorman Reviewed-by: Christoph Lameter Reviewed-by: Pekka Enberg Reviewed-by: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 88b117ce4ae1a68c5be558c182b1bea1967cac73 Author: Mel Gorman Date: Wed Nov 11 14:26:17 2009 -0800 page allocator: Do not allow interrupts to use ALLOC_HARDER commit 9d0ed60fe9cd1fbf57f755cd27a23ae9114d7210 upstream. Commit 341ce06f69abfafa31b9468410a13dbd60e2b237 ("page allocator: calculate the alloc_flags for allocation only once") altered watermark logic slightly by allowing rt_tasks that are handling an interrupt to set ALLOC_HARDER. This patch brings the watermark logic more in line with 2.6.30. This change results in a reduction of the number high-order GFP_ATOMIC allocation failures reported. See http://www.gossamer-threads.com/lists/linux/kernel/1144153 [rientjes@google.com: Spotted the problem] Signed-off-by: Mel Gorman Reviewed-by: Pekka Enberg Reviewed-by: Rik van Riel Reviewed-by: KOSAKI Motohiro Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 280292d5ed25f6799d4f301dea43d1c0a3c6ad68 Author: Sukadev Bhattiprolu Date: Wed Nov 11 14:26:32 2009 -0800 pidns: fix a leak in /proc dentries and inodes with pid namespaces. commit 29f12ca32122db98481150be09d35bd72b68045e upstream. Daniel Lezcano reported a leak in 'struct pid' and 'struct pid_namespace' that is discussed in: http://lkml.org/lkml/2009/10/2/159. To summarize the thread, when container-init is terminated, it sets the PF_EXITING flag, zaps other processes in the container and waits to reap them. As a part of reaping, the container-init should flush any /proc dentries associated with the processes. But because the container-init is itself exiting and the following PF_EXITING check, the dentries are not flushed, resulting in leak in /proc inodes and dentries. This fix reverts the commit 7766755a2f249e7e0 ("Fix /proc dcache deadlock in do_exit") which introduced the check for PF_EXITING. At the time of the commit, shrink_dcache_parent() flushed dentries from other filesystems also and could have caused a deadlock which the commit fixed. But as pointed out by Eric Biederman, after commit 0feae5c47aabdde59, shrink_dcache_parent() no longer affects other filesystems. So reverting the commit is now safe. As pointed out by Jan Kara, the leak is not as critical since the unclaimed space will be reclaimed under memory pressure or by: echo 3 > /proc/sys/vm/drop_caches But since this check is no longer required, its best to remove it. Signed-off-by: Sukadev Bhattiprolu Reported-by: Daniel Lezcano Acked-by: Eric W. Biederman Acked-by: Jan Kara Cc: Andrea Arcangeli Cc: Serge Hallyn Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0c98d0c6dcfb9f3f8608053b41192731630b41cd Author: KAMEZAWA Hiroyuki Date: Wed Nov 11 14:26:26 2009 -0800 memcg: fix wrong pointer initialization at page migration when memcg is disabled. commit e00e431612c3a6e437a01f2129fd3843da0c982a upstream. Lee Schermerhorn reported that he saw bad pointer dereference in mem_cgroup_end_migration() when he disabled memcg by boot option. memcg's page migration logic works as mem_cgroup_prepare_migration(page, &ptr); do page migration mem_cgroup_end_migration(page, ptr); Now, ptr is not initialized in prepare_migration when memcg is disabled by boot option. This causes panic in end_migration. This patch fixes it. Reported-by: Lee Schermerhorn Cc: Balbir Singh Signed-off-by: KAMEZAWA Hiroyuki Reviewed-by: Daisuke Nishimura Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bd7d2351462306b3244c3572c48670c77aa21528 Author: Heiko Carstens Date: Wed Nov 11 14:26:34 2009 -0800 fs: add missing compat_ptr handling for FS_IOC_RESVSP ioctl commit 7779d7bed950a7fb1af4f540c2f82a6b81b65901 upstream. For FS_IOC_RESVSP and FS_IOC_RESVSP64 compat_sys_ioctl() uses its arg argument as a pointer to userspace. However it is missing a a call to compat_ptr() which will do a proper pointer conversion. This was introduced with 3e63cbb1 "fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls". Signed-off-by: Heiko Carstens Cc: Ankit Jain Acked-by: Christoph Hellwig Cc: Al Viro Acked-by: Arnd Bergmann Acked-by: David S. Miller Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4549526e54461f6be8b229703d3c9488da1eb131 Author: Scott Valentine Date: Wed Nov 11 14:26:49 2009 -0800 rtc: v3020: fix v3020_mmio_read_bit() commit bcb3a1676b87effbdeffe8da5c44f63433d158d9 upstream. v3020_mmio_read_bit() always returns 0 when left_shift > 7. v3020_mmio_read_bit()'s return type is (unsigned char). The code returns a value masked by (1 << left_shift) that is casted to the return type. If left_shift is larger than 7, the cast will always result in a 0 return value. The problem was discovered with left_shift = 16, and the included patch corrects the problem. The bug was introduced in the last (Apr 3 2009) commit of the file, kernel versions 2.6.30 and later. Cc: Alessandro Zummo Cc: Paul Gortmaker Cc: Raphael Assenat Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 073493a20768a109ed1e6e744a2fe88e8bbd2fab Author: Rodolfo Giometti Date: Wed Nov 11 14:26:52 2009 -0800 pps: locking scheme fix up for PPS_GETPARAMS commit cbf83cc5a29dba480cf1ba1c5e3417a0d4a31410 upstream. Userland programs may read/write PPS parameters at same time and these operations may corrupt PPS data. Signed-off-by: Rodolfo Giometti Tested-by: Reg Clemens Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f1d8f4d0822df5c5f06021d221658fe2ad25c0cb Author: Rodolfo Giometti Date: Wed Nov 11 14:26:54 2009 -0800 pps: events reporting fix up commit 276b282e904f690dc930f9bc946110651f297669 upstream. PPS events must be recorded according to PPS's mode settings. If a process asks for (i.e.) capture-assert events only, when the PPS client calls the pps_event() function to save the current PPS event, we should verify the event type and then discard unwanted ones. Also, without this patch userland processes waiting for a specific PPS event (assert or clear but not both) may be awakened at wrong time. Signed-off-by: Rodolfo Giometti Tested-by: William S. Brasher Tested-by: Reg Clemens Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 02caa6be73dbeacafbfa98ecaa39b1dab7d84eb6 Author: Thomas Gleixner Date: Mon Nov 2 13:01:56 2009 +0100 uids: Prevent tear down race commit b00bc0b237055b4c45816325ee14f0bd83e6f590 upstream. Ingo triggered the following warning: WARNING: at lib/debugobjects.c:255 debug_print_object+0x42/0x50() Hardware name: System Product Name ODEBUG: init active object type: timer_list Modules linked in: Pid: 2619, comm: dmesg Tainted: G W 2.6.32-rc5-tip+ #5298 Call Trace: [<81035443>] warn_slowpath_common+0x6a/0x81 [<8120e483>] ? debug_print_object+0x42/0x50 [<81035498>] warn_slowpath_fmt+0x29/0x2c [<8120e483>] debug_print_object+0x42/0x50 [<8120ec2a>] __debug_object_init+0x279/0x2d7 [<8120ecb3>] debug_object_init+0x13/0x18 [<810409d2>] init_timer_key+0x17/0x6f [<81041526>] free_uid+0x50/0x6c [<8104ed2d>] put_cred_rcu+0x61/0x72 [<81067fac>] rcu_do_batch+0x70/0x121 debugobjects warns about an enqueued timer being initialized. If CONFIG_USER_SCHED=y the user management code uses delayed work to remove the user from the hash table and tear down the sysfs objects. free_uid is called from RCU and initializes/schedules delayed work if the usage count of the user_struct is 0. The init/schedule happens outside of the uidhash_lock protected region which allows a concurrent caller of find_user() to reference the about to be destroyed user_struct w/o preventing the work from being scheduled. If the next free_uid call happens before the work timer expired then the active timer is initialized and the work scheduled again. The race was introduced in commit 5cb350ba (sched: group scheduling, sysfs tunables) and made more prominent by commit 3959214f (sched: delayed cleanup of user_struct) Move the init/schedule_delayed_work inside of the uidhash_lock protected region to prevent the race. Signed-off-by: Thomas Gleixner Acked-by: Dhaval Giani Cc: Paul E. McKenney Cc: Kay Sievers Signed-off-by: Greg Kroah-Hartman commit 7b9acdf264761c1a8fdd3696a04e3a47d3a44e23 Author: Mike Isely Date: Wed Sep 23 18:06:57 2009 -0300 V4L/DVB (13230): s2255drv: Don't conditionalize video buffer completion on waiting processes commit 1f95725755ab67f3198df3b5bf7517f926f310ca upstream. The s2255 driver had logic which aborted processing of a video frame if there was no process waiting on the video buffer in question. That simply doesn't work when the application is doing things in an asynchronous manner. If the application went to the trouble to queue the buffer in the first place, then the driver should always attempt to complete it - even if the application at that moment has its attention turned elsewhere. Applications which always blocked waiting for I/O on the capture device would not have been affected by this. Applications which *mostly* blocked waiting for I/O on the capture device probably only would have been somewhat affected (frame lossage, at a rate which goes up as the application blocks less). Applications which never blocked on the capture device (e.g. polling only) however would never have been able to receive any video frames, since in that case this "is anyone waiting on this?" check on the buffer never would have evalutated true. This patch just deletes that harmful check against the buffer's wait queue. Signed-off-by: Mike Isely Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman commit c43d7819934b796560ffc14371dcc69089d1fb81 Author: Martin Samek Date: Wed Sep 30 22:59:09 2009 -0300 V4L/DVB (13079): dib0700: fixed xc2028 firmware loading kernel oops commit 7646b9de26c54cf4bc9c446d7ada9f91ece31e0a upstream. Fixing kernel oops when driver attemps to load xc2028 firmware. Note by djh: the patch contribute by Martin is a port of a fix I made during the PCTV 340e development. It's a temporary workaround that fixes a regression (an OOPS condition) and the real fix should be in the code that manages the i2c master on the dib7000p. But this fix does address the immmediate regression and should be merged upstream until we do a cleaner fix. Signed-off-by: Martin Samek Signed-off-by: Devin Heitmueller Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman commit 27bff6b55ad0fe861530315bb75eb3401fa1b660 Author: Devin Heitmueller Date: Thu Oct 15 01:14:34 2009 -0300 V4L/DVB (13190): em28xx: fix panic that can occur when starting audio streaming commit 96fbf771d86a90ff006bc62ca4d4de6474b3de31 upstream. Because the counters were not reset when starting up streaming, they would be reused from the previous run. This can result in cases such that when the second instance of streaming starts up, the "cnt" variable in em28xx_audio_isocirq() can end up being negative, resulting in attempting to write to memory before the start of runtime->dma_area (as well as having a negative number of bytes to copy). Signed-off-by: Devin Heitmueller Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman commit 53017a39386cce1b7b6da3013176364424793115 Author: Michael Krufky Date: Sun Sep 27 14:05:12 2009 -0300 V4L/DVB (13107): tda18271: fix overflow in FM radio frequency calculation commit 4d8317876d5f53ef792e90f89d8f162d7bca5c81 upstream. Multiplication by 62500 causes an overflow in the 32 bit freq variable, which is later divided by 1000 when using FM radio. This patch prevents the overflow by scaling the frequency value correctly upfront. Thanks to Henk Vergonet for spotting the problem and providing a preliminary patch, which this changeset was based upon. Cc: Henk Vergonet Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 7e1209105d7bc831bc7aed3e07f780e8e75c0ad3 Author: Seth Barry Date: Sun Sep 27 16:42:29 2009 -0300 V4L/DVB (13109): tda18271: fix signedness issue in tda18271_rf_tracking_filters_init commit a57c1dcb93e43357ed3f666e5a2b5d5071dd3930 upstream. While having tda18271 module set with debug=17 (cal & info prints) and cal=0 (delay calibration process until first use) - I discovered that during the calibration process, if the frequency test for 69750000 returned a bcal of 0 (see tda18721-fe.c in tda18271_powerscan func) that the tuner wouldn't be able to pickup any of the frequencies in the range (all the other frequencies bands returned bcal=1). I spent some time going over the code and the NXP's tda18271 spec (ver.4 of it i think) and adding a lot of debug prints and walking/stepping through the calibration process. I found that when the powerscan fails to find a frequency, the rf calibration is not run and the default value is supposed to be used in its place (pulled from the RF_CAL_map table) - but something was getting goofed up there. Now, my c coding skills are very rusty, but i think root of the problem is a signedness issue with the math operation for calculating the rf_a1 and rf_a2 values in tda18271_rf_tracking_filters_init func, which results in values like 20648 for rf_a1 (when it should probably have a value like 0, or so slightly negative that it should be zero - this bad value for rf_a1 would in turn makes the approx calc within tda18271c2_rf_tracking_filters_correction go out of whack). The simplest solution i found was to explicitly convert the signedness of the denominator to avoid the implicit conversion. The values placed into the u32 rf_freq array should never exceed about 900mhz, so i think the s32 max value shouldn't be an issue in this case. I've tested it out a little, and even when i get a bcal=0 with the modified code, the default calibration value gets used, rf_a1 is zero, and the tuner seems to lock on the stream and mythtv seems to play it fine. Signed-off-by: Seth Barry Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 21b6d2edf649e48e884c0b1d6414982a5e3d070b Author: Mike Isely Date: Mon Sep 21 12:42:22 2009 -0300 V4L/DVB (13170): bttv: Fix reversed polarity error when switching video standard commit 2de26c0a4a218a351bb1970eeaddf2905b47ff13 upstream. The bttv driver function which handles switching of the video standard (set_tvnorm() in bttv-driver.c) includes a check which can optionally also reset the cropping configuration to a default value. It is "optional" based on a comparison of the cropcap parameters of the previous vs the newly requested video standard. The comparison is being done with a memcmp(), a function which only returns a true value if the comparison actually fails. This if-statement appears to have been written to assume wrong memcmp() semantics. That is, it was re-initializing the cropping configuration only if the new video standard did NOT have different cropcap values. That doesn't make any sense. One definitely should reset things if the cropcap parameters are different - if there's any comparison to made at all. The effect of this problem was that a transition from, say, PAL to NTSC would leave in place old cropping setup that made sense for the PAL geometry but not for NTSC. If the application doesn't care about cropping it also won't try to reset the cropping configuration, resulting in an improperly cropped video frame. In the case I was testing this actually caused black video frames to be displayed. Another interesting effect of this bug is that if one does something which does NOT change the video standard and this function is run, then the cropping setup gets reset anyway - again because of the backwards comparison. It turns out that just running anything which merely opens and closes the video device node (e.g. v4l-info) will cause this to happen. One can argue that simply opening the device node and not doing anything to it should not mess with any of its state - but because of this behavior, any TV app which does such things (e.g. xawtv) probably therefore doesn't see the problem. The solution is to fix the sense of the if-statement. It's easy to see how this mistake could have been made given how memcmp() works. The patch is therefore removal of a single "!" character from the if-statement in set_tvnorm in bttv-driver.c. Signed-off-by: Mike Isely Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman commit d6581525739470f4dfaadcb071011315ea2724d7 Author: Mike Isely Date: Mon Sep 21 12:09:08 2009 -0300 V4L/DVB (13169): bttv: Fix potential out-of-order field processing commit 66349b4e7ab3825dbfc167a5f0309792a587adb7 upstream. There is a subtle interaction in the bttv driver which can result in fields being repeatedly processed out of order. This is a problem specifically when running in V4L2_FIELD_ALTERNATE mode (probably the most common case). 1. The determination of which fields are associated with which buffers happens in videobuf, before the bttv driver gets a chance to queue the corresponding DMA. Thus by the point when the DMA is queued for a given buffer, the algorithm has to do the queuing based on the buffer's already assigned field type - not based on which field is "next" in the video stream. 2. The driver normally tries to queue both the top and bottom fields at the same time (see bttv_irq_next_video()). It tries to sort out top vs bottom by looking at the field type for the next 2 available buffers and assigning them appropriately. 3. However the bttv driver *always* actually processes the top field first. There's even an interrupt set aside for specifically recognizing when the top field has been processed so that it can be marked done even while the bottom field is still being DMAed. Given all of the above, if one gets into a situation where bttv_irq_next_video() gets entered when the first available buffer has been pre-associated as a bottom field, then the function is going to process the buffers out of order. That first available buffer will be put into the bottom field slot and the buffer after that will be put into the top field slot. Problem is, since the top field is always processed first by the driver, then that second buffer (the one after the first available buffer) will be the first one to be finished. Because of the strict fifo handling of all video buffers, then that top field won't be seen by the app until after the bottom field is also processed. Worse still, the app will get back the chronologically later bottom field first, *before* the top field is received. The buffer's timestamps will even be backwards. While not fatal to most TV apps, this behavior can subtlely degrade userspace deinterlacing (probably will cause jitter). That's probably why it has gone unnoticed. But it will also cause serious problems if the app in question discards all but the latest received buffer (a latency minimizing tactic) - causing one field to only ever be displayed since the other is now always late. Unfortunately once you get into this state, you're stuck this way - because having consumed two buffers, now the next time around the "first" available buffer will again be a bottom field and the same thing happens. How can we get into this state? In a perfect world, where there's always a few free buffers queued to the driver, it should be impossible. However if something disrupts streaming, e.g. if the userspace app can't queue free buffers fast enough for a moment due perhaps to a CPU scheduling glitch, then the driver can get momentarily starved and some number of fields will be dropped. That's OK. But if an odd number of fields get dropped, then that "first" available buffer might be the bottom field and now we're stuck... This patch fixes that problem by deliberately only setting up a single field for one frame if we don't get a top field as the first available buffer. By purposely skipping the other field, then we only handle a single buffer thus bringing things back into proper sync (i.e. top field first) for the next frame. To do this we just drop the few lines in bttv_irq_next_video() that attempt to set up the second buffer when that second buffer isn't for the bottom field. This is definitely a problem in when in V4L2_FIELD_ALTERNATE mode. In the other modes this change either has no effect or doesn't harm things any further anyway. Signed-off-by: Mike Isely Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman commit ee83348407722a76b2cabc6c6628c55876fd51e3 Author: Russell King Date: Wed Nov 18 18:03:19 2009 +0000 kmap: fix build errors with DEBUG_HIGHMEM enabled commit 4ff1fa278b0bd1b2dd3c42efc0cb86788ffe05d5 upstream. d451564 broke ARM by requiring KM_IRQ_PTE, KM_NMI and KM_NMI_PTE to always be defined. Solve this by providing invalid definitions for these constants, but only if CONFIG_DEBUG_HIGHMEM is enabled. Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 22e633d1ba54044a66de913d164987f1fa946eea Author: Becky Bruce Date: Mon Nov 23 12:28:53 2009 +0000 powerpc: Fix DEBUG_HIGHMEM build break from d4515646699 commit e8105903d78c81119754a42926951d9d17e191ba upstream. Code was added to mm/higmem.c that depends on several kmap types that powerpc does not support. We add dummy invalid definitions for KM_NMI, KM_NM_PTE, and KM_IRQ_PTE. According to list discussion, this fix should not be needed anymore starting with 2.6.33. The code is commented to this effect so hopefully we will remember to remove this. Signed-off-by: Becky Bruce Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 8eed84d8062c4b41ac9722b6d121ccdffb508d05 Author: Soeren Sandmann Date: Wed Oct 28 18:56:35 2009 +0100 highmem: Fix debug_kmap_atomic() to also handle KM_IRQ_PTE, KM_NMI, and KM_NMI_PTE commit d4515646699b6ad7b1a98ceb871296b957f3ef47 upstream. Previously calling debug_kmap_atomic() with these types would cause spurious warnings. (triggered by SysProf using perf events) Signed-off-by: Soeren Sandmann Pedersen Cc: Linus Torvalds Cc: a.p.zijlstra@chello.nl LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 52f9034cfc63fad0aa06eecb1fd943432b6dc9f1 Author: Soeren Sandmann Date: Wed Oct 28 18:55:36 2009 +0100 highmem: Fix race in debug_kmap_atomic() which could cause warn_count to underflow commit 5ebd4c22897dce65845807a9bd3a31cc4e142b53 upstream. debug_kmap_atomic() tries to prevent ever printing more than 10 warnings, but it does so by testing whether an unsigned integer is equal to 0. However, if the warning is caused by a nested IRQ, then this counter may underflow and the stream of warnings will never end. Fix that by using a signed integer instead. Signed-off-by: Soeren Sandmann Pedersen Cc: Linus Torvalds Cc: a.p.zijlstra@chello.nl LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 80bc5c1318442367dbcdccfa737ec952548088a3 Author: Clemens Ladisch Date: Wed Oct 21 09:11:43 2009 +0200 sound: rawmidi: fix MIDI device O_APPEND error handling commit b7fe750fcceda4fa6bef399b0e2812562728ea82 upstream. Commit 9a1b64caac82aa02cb74587ffc798e6f42c6170a in 2.6.30 broke the error handling code in rawmidi_open_priv(). If only the output substream of a RawMIDI device has been opened and if this device is then opened with O_RDWR | O_APPEND and if the initialization of the input substream fails (either because of low memory or because the device driver's open callback fails), then the runtime structure of the already open output substream will be freed and all following writes through the first handle will cause snd_rawmidi_write() to use the NULL runtime pointer. Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit dfe0b47c1e940dbe2f59133c08c485dee78668c5 Author: Clemens Ladisch Date: Wed Oct 21 09:09:38 2009 +0200 sound: rawmidi: fix double init when opening MIDI device with O_APPEND commit 8579d2d7779d7ff41ea2a0183015e0e5038f1043 upstream. Commit 9a1b64caac82aa02cb74587ffc798e6f42c6170a in 2.6.30 moved the substream initialization code to where it would be executed every time the substream is opened. This had the consequence that any further opening would drop and leak the data in the existing buffer, and that the device driver's open callback would be called multiple times, unexpectedly. Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1a65ef117b0bcb58f5e8b97dc477728e98d3a795 Author: Clemens Ladisch Date: Wed Oct 21 09:10:16 2009 +0200 sound: rawmidi: fix checking of O_APPEND when opening MIDI device commit 16fb109644b5644e42ececeff644514de6f4bd03 upstream. Commit 9a1b64caac82aa02cb74587ffc798e6f42c6170a in 2.6.30 dropped the check that a substream must already have been opened with O_APPEND to be able to open it a second time. This would make it possible for a substream to be switched to append mode, which would mean that non-atomic writes would fail unexpectedly. Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e38dcb2b06e60459054478d79e22ef179f8ae798 Author: Clemens Ladisch Date: Mon Jul 13 13:52:46 2009 +0200 sound: rawmidi: disable active-sensing-on-close by default commit 2d4b842014dc76a81abced47ef27177eedb9deba upstream. Sending an Active Sensing message when closing a port can interfere with the following data if the port is reopened and a note-on is sent before the device's timeout has elapsed. Therefore, it is better to disable this setting by default. Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai commit ea4cf642637ddf61ef992568ea3e960aaa9b609a Author: David Woodhouse Date: Mon Nov 30 09:06:40 2009 +0000 jffs2: Fix memory corruption in jffs2_read_inode_range() commit 199bc9ff5ca5e4b3bcaff8927b2983c65f34c263 upstream. In 2.6.23 kernel, commit a32ea1e1f925399e0d81ca3f7394a44a6dafa12c ("Fix read/truncate race") fixed a race in the generic code, and as a side effect, now do_generic_file_read() can ask us to readpage() past the i_size. This seems to be correctly handled by the block routines (e.g. block_read_full_page() fills the page with zeroes in case if somebody is trying to read past the last inode's block). JFFS2 doesn't handle this; it assumes that it won't be asked to read pages which don't exist -- and thus that there will be at least _one_ valid 'frag' on the page it's being asked to read. It will fill any holes with the following memset: memset(buf, 0, min(end, frag->ofs + frag->size) - offset); When the 'closest smaller match' returned by jffs2_lookup_node_frag() is actually on a previous page and ends before 'offset', that results in: memset(buf, 0, ); Hopefully, in most cases the corruption is fatal, and quickly causing random oopses, like this: root@10.0.0.4:~/ltp-fs-20090531# ./testcases/kernel/fs/ftest/ftest01 Unable to handle kernel paging request for data at address 0x00000008 Faulting instruction address: 0xc01cd980 Oops: Kernel access of bad area, sig: 11 [#1] [...] NIP [c01cd980] rb_insert_color+0x38/0x184 LR [c0043978] enqueue_hrtimer+0x88/0xc4 Call Trace: [c6c63b60] [c004f9a8] tick_sched_timer+0xa0/0xe4 (unreliable) [c6c63b80] [c0043978] enqueue_hrtimer+0x88/0xc4 [c6c63b90] [c0043a48] __run_hrtimer+0x94/0xbc [c6c63bb0] [c0044628] hrtimer_interrupt+0x140/0x2b8 [c6c63c10] [c000f8e8] timer_interrupt+0x13c/0x254 [c6c63c30] [c001352c] ret_from_except+0x0/0x14 --- Exception: 901 at memset+0x38/0x5c LR = jffs2_read_inode_range+0x144/0x17c [c6c63cf0] [00000000] (null) (unreliable) This patch fixes the issue, plus fixes all LTP tests on NAND/UBI with JFFS2 filesystem that were failing since 2.6.23 (seems like the bug above also broke the truncation). Reported-By: Anton Vorontsov Tested-By: Anton Vorontsov Signed-off-by: David Woodhouse Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2a2c59e64de72e390d427e165d937020c7f417fe Author: Russell King Date: Sun Nov 29 16:39:59 2009 +0000 ALSA: AACI: fix recording bug commit 8ee763b9c82c6ca0a59a7271ce4fa29d7baf5c09 upstream. pcm->r[1].slots is the double rate slot information, not the capture information. For capture, 'pcm' will already be the capture ac97 pcm structure. Signed-off-by: Russell King Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c20be9b482978de39a489dfc2e2a4ccb8ee9ea56 Author: Russell King Date: Sun Nov 29 16:39:52 2009 +0000 ALSA: AACI: fix AC97 multiple-open bug commit 4acd57c3de62374fe5bb52e5cd24538190f4eab2 upstream. Signed-off-by: Russell King Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b381ea627f10c081d4f45ce601463732bda0e765 Author: Daniel J Blueman Date: Sat Nov 14 18:20:04 2009 +0000 ALSA: hda - Dell Studio 1557 hd-audio quirk commit 8ef5837a47f73faee18fa7ce2f9a9eb7675be8de upstream. Add the Dell Studio 15 (model 1557, Core i7) laptop to the hd-audio quirk list, enabling audio. Signed-off-by: Daniel J Blueman Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 44cf344afe9976e27b64c2bac861f5d45009f3fc Author: Julian Anastasov Date: Fri Nov 6 23:44:53 2009 +0200 ALSA: usb-audio: fix combine_word problem commit f495088210c8b9e20791d995a8210170c68d2deb upstream. Fix combine_word problem where first octet is not read properly. The only affected place seems to be the INPUT_TERMINAL type. Before now, sound controls can be created with the output terminal's name which is a fallback mechanism used only for unknown input terminal types. For example, Line can wrongly appear as Speaker. After the change it should appear as Line. The side effect of this change can be that users can expect the wrong control name in their scripts or programs while now we return the correct one. Probably, these defines should use get_unaligned_le16 and friends. Signed-off-by: Julian Anastasov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 57a0aa351bff86bd529c8638a376cf0a18b60eae Author: NeilBrown Date: Fri Oct 16 15:55:32 2009 +1100 md/raid1/raid10: add a cond_resched commit 1d9d52416c0445019ccc1f0fddb9a227456eb61b upstream. During 'check' of a raid1 or raid10 it is possible for the management thread to spend a lot of time running 'memcmp' on blocks from different devices, so make sure the thread has a chance to schedule. raid5d already has a cond_resched (in process_stripe). Reported-By: Lee Howard Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 8a7963564a8288a2c98d1c924d09ac0697b8f92c Author: NeilBrown Date: Fri Nov 6 14:59:29 2009 +1100 md/raid5: make sure curr_sync_completes is uptodate when reshape starts commit 8dee7211467a56b7eb4e4359efb0aa4a72e1b6f3 upstream. This value is visible through sysfs and is used by mdadm when it manages a reshape (backing up data that is about to be rearranged). So it is important that it is always correct. Current it does not get updated properly when a reshape starts which can cause problems when assembling an array that is in the middle of being reshaped. This is suitable for 2.6.31.y stable kernels. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 98bc571940095198eec1e4b9af70bf9024b5f539 Author: NeilBrown Date: Fri Nov 6 14:59:27 2009 +1100 md: don't clear endpoint for resync when resync is interrupted. commit 24395a85d8efe6eee477ea35c73d045a8dd7a3a1 upstream. If a 'sync_max' has been set (via sysfs), it is wrong to clear it until a resync (or reshape or recovery ...) actually reached that point. So if a resync is interrupted (e.g. by device failure), leave 'resync_max' unchanged. This is particularly important for 'reshape' operations that do not change the size of the array. For such operations mdadm needs to monitor the reshape taking rolling backups of the section being reshaped. If resync_max gets cleared, the reshape can get ahead of mdadm and then the backups that mdadm creates are useless. This is suitable for 2.6.31.y stable kernels. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 146d0c086cc8b6d580cb08b6e8ad149f91c1e03d Author: Larry Finger Date: Wed Nov 4 00:00:25 2009 -0600 rtl8187: Fix kernel oops when device is removed when LEDS enabled commit 37b12dd2b07b4d7dc222a5f7f88b25cec532b2aa upstream. As reported by Rick Farina (sidhayn@gmail.com), removing the RTL8187 USB stick, or unloading the driver rtl8187 using rmmod will cause a kernel oops. There are at least two forms of the failure, (1) BUG: Scheduling while atomic, and (2) a fatal kernel page fault. This problem is reported in Bugzilla #14539. This problem does not occur for kernel 2.6.31, but does for 2.6.32-rc2, thus it is technically a regression; however, bisection did not locate any faulty patch. The fix was found by comparing the faulty code in rtl8187 with p54usb. My interpretation is that the handling of work queues in mac80211 changed enough to the LEDs to be unregistered before tasks on the work queues are cancelled. Previously, these actions could be done in either order. (Herton Ronaldo Krzesinski reports that the code is the same in 2.6.31, so this may be a candidate for 2.6.31.x. -- JWL) Signed-off-by: Larry Finger Reported-by: Rick Farina Tested-by: Rick Farina Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 174388981606378894ab74cae9467d5bbf0e5830 Author: Dave Jones Date: Mon Oct 19 19:55:13 2009 -0400 gdth: Prevent negative offsets in ioctl CVE-2009-3080 commit 690e744869f3262855b83b4fb59199cf142765b0 upstream. A negative offset could be used to index before the event buffer and lead to a security breach. Signed-off-by: Dave Jones Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 24fa7e7df85aae43e2ac0af24a56ca093a613460 Author: Steve French Date: Tue Nov 24 22:49:37 2009 +0000 CIFS: Duplicate data on appending to some Samba servers commit cea62343956c24452700c06cf028b72414c58a74 upstream. SMB writes are sent with a starting offset and length. When the server supports the newer SMB trans2 posix open (rather than using the SMB NTCreateX) a file can be opened with SMB_O_APPEND flag, and for that case Samba server assumes that the offset sent in SMBWriteX is unneeded since the write should go to the end of the file - which can cause problems if the write was cached (since the beginning part of a page could be written twice by the client mm). Jeff suggested that masking the flag on posix open on the client is easiest for the time being. Note that recent Samba server also had an unrelated problem with SMB NTCreateX and append (see samba bugzilla bug number 6898) which should not affect current Linux clients (unless cifs Unix Extensions are disabled). The cifs client did not send the O_APPEND flag on posix open before 2.6.29 so the fix is unneeded on early kernels. In the future, for the non-cached case (O_DIRECT, and forcedirectio mounts) it would be possible and useful to send O_APPEND on posix open (for Windows case: FILE_APPEND_DATA but not FILE_WRITE_DATA on SMB NTCreateX) but for cached writes although the vfs sets the offset to end of file it may fragment a write across pages - so we can't send O_APPEND on open (could result in sending part of a page twice). Reviewed-by: Shirish Pargaonkar Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 0fbad7ae3c0d00c5e5f5951b1de5ef536dec2a5e Author: Steve French Date: Tue Nov 24 22:17:59 2009 +0000 CIFS: fix oops in cifs_lookup during net boot commit 8e6c0332d5032aef2d3bc8f41771f999112c8c66 upstream. Fixes bugzilla.kernel.org bug number 14641 Lookup called during network boot (network root filesystem for diskless workstation) has case where nd is null in lookup. This patch fixes that in cifs_lookup. (Shirish noted that 2.6.30 and 2.6.31 stable need the same check) Signed-off-by: Shirish Pargaonkar Acked-by: Jeff Layton Tested-by: Vladimir Stavrinov Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit fb598664ca7b2b807380be5a526378b4877e5e0d Author: Suresh Jayaraman Date: Mon Nov 16 12:03:16 2009 +0530 cifs: clear server inode number flag while autodisabling commit f534dc994397560343be4a3223b9bbaa8e739e1f upstream. Fix the commit ec06aedd44 that intended to turn off querying for server inode numbers when server doesn't consistently support inode numbers. Presumably the commit didn't actually clear the CIFS_MOUNT_SERVER_INUM flag, perhaps a typo. Signed-off-by: Suresh Jayaraman Acked-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit ad4316779dc2ca73c3d2b11d0f13ff3d3b0fa100 Author: Jeff Layton Date: Fri Nov 6 14:18:29 2009 -0500 cifs: clean up handling when server doesn't consistently support inode numbers commit ec06aedd44541129840ed52e6165afa3796a27bf upstream. It's possible that a server will return a valid FileID when we query the FILE_INTERNAL_INFO for the root inode, but then zeroed out inode numbers when we do a FindFile with an infolevel of SMB_FIND_FILE_ID_FULL_DIR_INFO. In this situation turn off querying for server inode numbers, generate a warning for the user and just generate an inode number using iunique. Once we generate any inode number with iunique we can no longer use any server inode numbers or we risk collisions, so ensure that we don't do that in cifs_get_inode_info either. Reported-by: Timothy Normand Miller Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 6804b96f48a32bca16fee60212ad8e4b201bb99f Author: Jeff Layton Date: Fri Nov 6 14:18:49 2009 -0500 cifs: don't use CIFSGetSrvInodeNumber in is_path_accessible commit f475f6775465283494346663f201ad04810d2e8a upstream. Because it's lighter weight, CIFS tries to use CIFSGetSrvInodeNumber to verify the accessibility of the root inode and then falls back to doing a full QPathInfo if that fails with -EOPNOTSUPP. I have at least a report of a server that returns NT_STATUS_INTERNAL_ERROR rather than something that translates to EOPNOTSUPP. Rather than trying to be clever with that call, just have is_path_accessible do a normal QPathInfo. That call is widely supported and it shouldn't increase the overhead significantly. Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b88b724607b4e9472398c7b3ebc5f8cb3f1d98d6 Author: Ryusuke Konishi Date: Sat Nov 7 18:45:16 2009 +0900 nilfs2: fix kernel oops in error case of nilfs_ioctl_move_blocks commit 5399dd1fc8f5e812db931225ef5f67d89f3b1a56 upstream. This fixes a kernel oops reported by Markus Trippelsdorf in the email titled "[NILFS users] kernel Oops while running nilfs_cleanerd". The oops was caused by a bug of error path in nilfs_ioctl_move_blocks() function, which was inlined in nilfs_ioctl_clean_segments(). nilfs_ioctl_move_blocks checks duplication of blocks which will be moved in garbage collection. But, the check should have be done within nilfs_ioctl_move_inode_block() to prevent list corruption among buffers storing the target blocks. To fix the kernel oops, this moves forward the duplication check before the list insertion. I also tested this for stable trees [2.6.30, 2.6.31]. Reported-by: Markus Trippelsdorf Signed-off-by: Ryusuke Konishi Signed-off-by: Greg Kroah-Hartman