Makefile | 2 arch/x86/kernel/cpu/cpufreq/pcc-cpufreq.c | 2 drivers/char/virtio_console.c | 8 +++ drivers/hid/hid-mosart.c | 4 + drivers/media/dvb/dvb-usb/dib0700_devices.c | 21 +++++++++- drivers/media/dvb/frontends/dib7000m.c | 19 +++++++++ drivers/media/dvb/frontends/dib7000m.h | 15 +++++++ drivers/media/video/cx23885/cx23885-i2c.c | 8 --- drivers/media/video/cx25840/cx25840-core.c | 3 - drivers/media/video/ivtv/ivtv-irq.c | 58 ++++++++++++++++++++++++---- drivers/misc/bmp085.c | 1 drivers/net/forcedeth.c | 2 drivers/net/ixgbe/ixgbe_main.c | 4 + drivers/net/r8169.c | 42 +++++++++++++++----- drivers/net/wireless/ath/ath9k/ath9k.h | 3 - drivers/net/wireless/ath/ath9k/init.c | 4 - drivers/net/wireless/ath/ath9k/main.c | 4 - drivers/s390/char/keyboard.c | 3 - fs/nfs/nfs4proc.c | 44 ++++++++++++++++++++- fs/nfs/nfs4xdr.c | 3 - fs/nfsd/nfs4xdr.c | 4 - include/keys/rxrpc-type.h | 1 include/linux/netdevice.h | 3 + kernel/cpuset.c | 7 ++- kernel/sched_rt.c | 14 ++++-- mm/mremap.c | 4 - net/core/dev.c | 12 ++++- net/ipv4/ip_gre.c | 1 net/ipv4/ipip.c | 1 net/ipv4/netfilter/arpt_mangle.c | 6 +- net/ipv6/ip6_tunnel.c | 1 net/ipv6/sit.c | 2 net/netfilter/ipvs/ip_vs_ctl.c | 4 - net/netfilter/nf_log.c | 4 + sound/pci/hda/patch_cirrus.c | 2 sound/pci/hda/patch_realtek.c | 7 --- sound/soc/codecs/wm9081.c | 5 ++ 37 files changed, 256 insertions(+), 72 deletions(-)
New commits: commit 97b197f07d15dbcd53328e75754e2f947814c733 Author: Greg Kroah-Hartman <[email protected]> Date: Mon Mar 14 14:19:26 2011 -0700 Linux 2.6.37.4 commit a0c904c51dc195c90d22180529bab221b3644df2 Author: stephen hemminger <[email protected]> Date: Thu Mar 10 11:43:19 2011 +0000 ip6ip6: autoload ip6 tunnel commit 6dfbd87a20a737641ef228230c77f4262434fa24 upstream ip6ip6: autoload ip6 tunnel Add necessary alias to autoload ip6ip6 tunnel module. Signed-off-by: Stephen Hemminger <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c5729162963b013f0e26b834b7d89b040178219e Author: Olivier Grenie <[email protected]> Date: Fri Jan 14 13:58:59 2011 -0300 DiB7000M: add pid filtering commit e192a7cf0effe7680264a5bc35c0ad1bdcdc921c upstream. This patch adds the pid filtering for the dib7000M demod. It also corrects the pid filtering for the dib7700 based board. It should prevent an oops, when using dib7700p based board. References: https://bugzilla.novell.com/show_bug.cgi?idd4807 Signed-off-by: Olivier Grenie <[email protected]> Signed-off-by: Patrick Boettcher <[email protected]> Tested-by: Pavel SKARKA <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e53b53dd4c61cbdefa897743060d662ac33e1595 Author: Sven Barth <[email protected]> Date: Sun Feb 13 22:09:43 2011 -0300 cx25840: fix probing of cx2583x chips commit 1e6406b8f0dc1ae7d7c39c9e1ac6ca78e016ebfb upstream. Fix the probing of cx2583x chips, because two controls were clustered that are not created for these chips. This regression was introduced in 2.6.36. Signed-off-by: Sven Barth <[email protected]> Signed-off-by: Andy Walls <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c06dc644fc8af9dda13e4e7ed1178e9e9bf02438 Author: Andy Walls <[email protected]> Date: Sun Feb 13 21:52:50 2011 -0300 cx23885: Revert "Check for slave nack on all transactions" commit 67914b5c400d6c213f9e56d7547a2038ab5c06f4 upstream. This reverts commit 44835f197bf1e3f57464f23dfb239fef06cf89be. With the CX23885 hardware I2C master, checking for I2C slave ACK/NAK is not valid when the I2C_EXTEND or I2C_NOSTOP bits are set. Revert the commit that checks for I2C slave ACK/NAK on all transactions, so that XC5000 tuners work with the CX23885 again. Thanks go to Mark Zimmerman for reporting and bisecting this problem. Bisected-by: Mark Zimmerman <[email protected]> Reported-by: Mark Zimmerman <[email protected]> Signed-off-by: Andy Walls <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0ab29c52f9efdd645d565f8be3915183819a6c3e Author: Michael <[email protected]> Date: Sat Feb 26 01:56:34 2011 -0300 ivtv: Fix corrective action taken upon DMA ERR interrupt to avoid hang commit d213ad08362909ab50fbd6568fcc9fd568268d29 upstream. After upgrading the kernel from stock Ubuntu 7.10 to 10.04, with no hardware changes, I started getting the dreaded DMA TIMEOUT errors, followed by inability to encode until the machine was rebooted. I came across a post from Andy in March (http://www.gossamer-threads.com/lists/ivtv/users/40943#40943) where he speculates that perhaps the corrective actions being taken after a DMA ERROR are not sufficient to recover the situation. After some testing I suspect that this is indeed the case, and that in fact the corrective action may be what hangs the card's DMA engine, rather than the original error. Specifically these DMA ERROR IRQs seem to present with two different values in the IVTV_REG_DMASTATUS register: 0x11 and 0x13. The current corrective action is to clear that status register back to 0x01 or 0x03, and then issue the next DMA request. In the case of a 0x13 this seems to result in a minor glitch in the encoded stream due to the failed transfer that was not retried, but otherwise things continue OK. In the case of a 0x11 the card's DMA write engine is never heard from again, and a DMA TIMEOUT follows shortly after. 0x11 is the killer. I suspect that the two cases need to be handled differently. The difference is in bit 1 (0x02), which is set when the error is about to be successfully recovered, and clear when things are about to go bad. Bit 1 of DMASTATUS is described differently in different places either as a positive "write finished", or an inverted "write busy". If we take the first definition, then when an error arises with state 0x11, it means that the write did not complete. It makes sense to start a new transfer, as in the current code. But if we take the second definition, then 0x11 means "an error but the write engine is still busy". Trying to feed it a new transfer in this situation might not be a good idea. As an experiment, I added code to ignore the DMA ERROR IRQ if DMASTATUS is 0x11. I.e., don't start a new transfer, don't clear our flags, etc. The hope was that the card would complete the transfer and issue a ENC DMA COMPLETE, either successfully or with an error condition there. However the card still hung. The only remaining corrective action being taken with a 0x11 status was then the write back to the status register to clear the error, i.e. DMASTATUS = DMASTATUS & ~3. This would have the effect of clearing the error bit 4, while leaving the lower bits indicating DMA write busy. Strangely enough, removing this write to the status register solved the problem! If the DMA ERROR IRQ with DMASTATUS=0x11 is completely ignored, with no corrective action at all, then the card will complete the transfer and issue a new IRQ. If the status register is written to when it has the value 0x11, then the DMA engine hangs. Perhaps it's illegal to write to DMASTATUS while the read or write busy bit is set? At any rate, it appears that the current corrective action is indeed making things worse rather than better. I put together a patch that modifies ivtv_irq_dma_err to do the following: - Don't write back to IVTV_REG_DMASTATUS. - If write-busy is asserted, leave the card alone. Just extend the timeout slightly. - If write-busy is de-asserted, retry the current transfer. This has completely fixed my DMA TIMEOUT woes. DMA ERR events still occur, but now they seem to be correctly handled. 0x11 events no longer hang the card, and 0x13 events no longer result in a glitch in the stream, as the failed transfer is retried. I'm happy. I've inlined the patch below in case it is of interest. As described above, I have a theory about why it works (based on a different interpretation of bit 1 of DMASTATUS), but I can't guarantee that my theory is correct. There may be another explanation, or it may be a fluke. Maybe ignoring that IRQ entirely would be equally effective? Maybe the status register read/writeback sequence is race condition if the card changes it in the mean time? Also as I am using a PVR-150 only, I have not been able to test it on other cards, which may be especially relevant for 350s that support concurrent decoding. Hopefully the patch does not break the DMA READ path. Mike [[email protected]: Modified patch to add a verbose comment, make minor brace reformats, and clear the error flags in the IVTV_REG_DMASTATUS iff both read and write DMA were not in progress. Mike's conjecture about a race condition with the writeback is correct; it can confuse the DMA engine.] [Comment and analysis from the ML post by Michael <[email protected]>] Signed-off-by: Andy Walls <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4065ec0806f8ba8ade4d8f01b44aed040aff8622 Author: Balbir Singh <[email protected]> Date: Thu Mar 3 17:04:35 2011 +0530 sched: Fix sched rt group scheduling when hierachy is enabled commit 0c3b9168017cbad2c4af3dd65ec93fe646eeaa62 upstream. The current sched rt code is broken when it comes to hierarchical scheduling, this patch fixes two problems 1. It adds redundant enqueuing (harmless) when it finds a queue has tasks enqueued, but it has no run time and it is not throttled. 2. The most important change is in sched_rt_rq_enqueue/dequeue. The code just picks the rt_rq belonging to the current cpu on which the period timer runs, the patch fixes it, so that the correct rt_se is enqueued/dequeued. Tested with a simple hierarchy /c/d, c and d assigned similar runtimes of 50,000 and a while 1 loop runs within "d". Both c and d get throttled, without the patch, the task just stops running and never runs (depends on where the sched_rt b/w timer runs). With the patch, the task is throttled and runs as expected. [ bharata, suggestions on how to pick the rt_se belong to the rt_rq and correct cpu ] Signed-off-by: Balbir Singh <[email protected]> Acked-by: Bharata B Rao <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> LKML-Reference: <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit fea891e387dbd48bbe13d5a588059e879eaa8dfe Author: Ivan Vecera <[email protected]> Date: Tue Feb 15 02:08:39 2011 +0000 drivers/net: Call netif_carrier_off at the end of the probe commit 0d672e9f8ac320c6d1ea9103db6df7f99ea20361 upstream. Without calling of netif_carrier_off at the end of the probe the operstate is unknown when the device is initially opened. By default the carrier is on so when the device is opened and netif_carrier_on is called the link watch event is not fired and operstate remains zero (unknown). This patch fixes this behavior in forcedeth and r8169. Signed-off-by: Ivan Vecera <[email protected]> Acked-by: Francois Romieu <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 30b7cb312baeab0504e4ba1bc5b324abf7afcf68 Author: Francois Romieu <[email protected]> Date: Thu Feb 3 17:27:52 2011 +0100 r8169: prevent RxFIFO induced loops in the irq handler. commit f60ac8e7ab7cbb413a0131d5665b053f9f386526 upstream. While the RxFIFO interruption is masked for most 8168, nothing prevents it to appear in the irq status word. This is no excuse to crash. Signed-off-by: Francois Romieu <[email protected]> Cc: Ivan Vecera <[email protected]> Cc: Hayes <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit be70b4e2c60c2d7e03c3193cadd1cb9eddb5e4bc Author: Francois Romieu <[email protected]> Date: Thu Feb 3 12:02:36 2011 +0100 r8169: RxFIFO overflow oddities with 8168 chipsets. commit 1519e57fe81c14bb8fa4855579f19264d1ef63b4 upstream. Some experiment-based action to prevent my 8168 chipsets locking-up hard in the irq handler under load (pktgen ~1Mpps). Apparently a reset is not always mandatory (is it at all ?). - RTL_GIGA_MAC_VER_12 - RTL_GIGA_MAC_VER_25 Missed ~55% packets. Note: - this is an old SiS 965L motherboard - the 8168 chipset emits (lots of) control frames towards the sender - RTL_GIGA_MAC_VER_26 The chipset does not go into a frenzy of mac control pause when it crashes yet but it can still be crashed. It needs more work. Signed-off-by: Francois Romieu <[email protected]> Cc: Ivan Vecera <[email protected]> Cc: Hayes <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit cb1f3fd3ba182cd514e2b72487a5f84932e6a03b Author: Ivan Vecera <[email protected]> Date: Thu Jan 27 12:24:11 2011 +0100 r8169: use RxFIFO overflow workaround for 8168c chipset. commit b5ba6d12bdac21bc0620a5089e0f24e362645efd upstream. I found that one of the 8168c chipsets (concretely XID 1c4000c0) starts generating RxFIFO overflow errors. The result is an infinite loop in interrupt handler as the RxFIFOOver is handled only for ...MAC_VER_11. With the workaround everything goes fine. Signed-off-by: Ivan Vecera <[email protected]> Acked-by: Francois Romieu <[email protected]> Cc: Hayes <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 1d328fe937351b9e7bea486e162d6a77bacb3b52 Author: Pablo Neira Ayuso <[email protected]> Date: Tue Feb 1 16:03:46 2011 +0100 netfilter: arpt_mangle: fix return values of checkentry commit 9d0db8b6b1da9e3d4c696ef29449700c58d589db upstream. In 135367b "netfilter: xtables: change xt_target.checkentry return type", the type returned by checkentry was changed from boolean to int, but the return values where not adjusted. arptables: Input/output error This broke arptables with the mangle target since it returns true under success, which is interpreted by xtables as >0, thus returning EIO. Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Patrick McHardy <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 8767008a7160188deb1e653d5dcaa630b16234b9 Author: Vasiliy Kulikov <[email protected]> Date: Wed Mar 2 00:33:13 2011 +0300 net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules commit 8909c9ad8ff03611c9c96c9a92656213e4bb495b upstream. Since a8f80e8ff94ecba629542d9b4b5f5a8ee3eb565c any process with CAP_NET_ADMIN may load any module from /lib/modules/. This doesn't mean that CAP_NET_ADMIN is a superset of CAP_SYS_MODULE as modules are limited to /lib/modules/**. However, CAP_NET_ADMIN capability shouldn't allow anybody load any module not related to networking. This patch restricts an ability of autoloading modules to netdev modules with explicit aliases. This fixes CVE-2011-1019. Arnd Bergmann suggested to leave untouched the old pre-v2.6.32 behavior of loading netdev modules by name (without any prefix) for processes with CAP_SYS_MODULE to maintain the compatibility with network scripts that use autoloading netdev modules by aliases like "eth0", "wlan0". Currently there are only three users of the feature in the upstream kernel: ipip, ip_gre and sit. root@albatros:~# capsh --drop=$(seq -s, 0 11),$(seq -s, 13 34) -- root@albatros:~# grep Cap /proc/$$/status CapInh: 0000000000000000 CapPrm: fffffff800001000 CapEff: fffffff800001000 CapBnd: fffffff800001000 root@albatros:~# modprobe xfs FATAL: Error inserting xfs (/lib/modules/2.6.38-rc6-00001-g2bf4ca3/kernel/fs/xfs/xfs.ko): Operation not permitted root@albatros:~# lsmod | grep xfs root@albatros:~# ifconfig xfs xfs: error fetching interface information: Device not found root@albatros:~# lsmod | grep xfs root@albatros:~# lsmod | grep sit root@albatros:~# ifconfig sit sit: error fetching interface information: Device not found root@albatros:~# lsmod | grep sit root@albatros:~# ifconfig sit0 sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 root@albatros:~# lsmod | grep sit sit 10457 0 tunnel4 2957 1 sit For CAP_SYS_MODULE module loading is still relaxed: root@albatros:~# grep Cap /proc/$$/status CapInh: 0000000000000000 CapPrm: ffffffffffffffff CapEff: ffffffffffffffff CapBnd: ffffffffffffffff root@albatros:~# ifconfig xfs xfs: error fetching interface information: Device not found root@albatros:~# lsmod | grep xfs xfs 745319 0 Reference: https://lkml.org/lkml/2011/2/24/203 Signed-off-by: Vasiliy Kulikov <[email protected]> Signed-off-by: Michael Tokarev <[email protected]> Acked-by: David S. Miller <[email protected]> Acked-by: Kees Cook <[email protected]> Signed-off-by: James Morris <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 46d5660d9466b2adb89e87a221f095b17d69d943 Author: Julian Anastasov <[email protected]> Date: Tue Feb 22 10:40:25 2011 +0200 ipvs: fix dst_lock locking on dest update commit ff75f40f44ae9b79d520bf32a05d35af74a805c0 upstream. Fix dst_lock usage in __ip_vs_update_dest. We need _bh locking because destination is updated in user context. Can cause lockups on frequent destination updates. Problem reported by Simon Kirby. Bug was introduced in 2.6.37 from the "ipvs: changes for local real server" change. Signed-off-by: Julian Anastasov <[email protected]> Signed-off-by: Hans Schillstrom <[email protected]> Signed-off-by: Simon Horman <[email protected]> Cc: Simon Kirby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 73c2a0d93eb479373c14717a3e9bd0ce7b31e2e2 Author: Chuck Lever <[email protected]> Date: Fri Jan 28 12:41:05 2011 -0500 NFS: NFSv4 readdir loses entries commit d1205f87bbb8040c1408bbd9e0a720310b2b0b9b upstream. On recent 2.6.38-rc kernels, connectathon basic test 6 fails on NFSv4 mounts of OpenSolaris with something like: > ./test6: readdir > ./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.12' dir entry, pass 0 > ./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.82' dir entry, pass 0 > ./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.164' dir entry, pass 0 > ./test6: (/mnt/klimt/matisse.test) Test failed with 3 errors > basic tests failed > Tests failed, leaving /mnt/klimt mounted > [cel@matisse cthon04]$ I narrowed the problem down to nfs4_decode_dirent() reporting that the decode buffer had overflowed while decoding the entries for those missing files. verify_attr_len() assumes both it's pointer arguments reside on the same page. When these arguments point to locations on two different pages, verify_attr_len() can report false errors. This can happen now that a large NFSv4 readdir result can span pages. We have reasonably good checking in nfs4_decode_dirent() anyway, so it should be safe to simply remove the extra checking. At a guess, this was introduced by commit 6650239a, "NFS: Don't use vm_map_ram() in readdir". Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 1eac7b1dbe578f029927f821633bdac1e786fa66 Author: Benjamin Tissoires <[email protected]> Date: Tue Dec 14 11:38:18 2010 +0100 HID: hid-mosart: ignore buttons report commit ad6d42670279da8f33f633f8a96a67cd7ef3b1da upstream. This commit allows the device to be recognized as a touchscreen, and not a touchpad by xf86-input-evdev. The device has 2 modes. The first one is an emulation of a touchscreen by sending left and right button, and the second mode is the one used in dual-touch (sending trackingID, touch and else). That's why there is a hid report containing left and right buttons (9000001 and 9000002). The point is that xorg relies on these fields to determine if it's a touchpad or a touchscreen. Clearing the report (return -1) makes xorg detecting it out of the box as a quite pleasant (dual)touchscreen. Signed-off-by: Benjamin Tissoires <[email protected]> Acked-by: Chase Douglas <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Cc: James Sharam <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b3d26c5dbee6a6a088221017b817ed34e445da6e Author: roel <[email protected]> Date: Tue Mar 8 22:32:26 2011 +0100 nfsd: wrong index used in inner loop commit 3ec07aa9522e3d5e9d5ede7bef946756e623a0a0 upstream. Index i was already used in the outer loop Signed-off-by: Roel Kluin <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit ace8f4534de7aa5c42b66751832e57eb4cdab7b5 Author: Naga Chumbalkar <[email protected]> Date: Wed Mar 9 14:02:49 2011 +0000 pcc-cpufreq: don't load driver if get_freq fails during init. commit 1f858ef2fbabdc5e645644010a31a40c32e397c9 upstream. Return 0 on failure. This will cause the initialization of the driver to fail and prevent the driver from loading if the BIOS cannot handle the PCC interface command to "get frequency". Otherwise, the driver will load and display a very high value like "4294967274" (which is actually -EINVAL) for frequency: # cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq 4294967274 Signed-off-by: Naga Chumbalkar <[email protected]> Signed-off-by: Dave Jones <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2110938fd67a059ae99b030c74997cfb142c4d6b Author: Jan Engelhardt <[email protected]> Date: Wed Mar 2 12:10:13 2011 +0100 netfilter: nf_log: avoid oops in (un)bind with invalid nfproto values commit 9ef0298a8e5730d9a46d640014c727f3b4152870 upstream. Like many other places, we have to check that the array index is within allowed limits, or otherwise, a kernel oops and other nastiness can ensue when we access memory beyond the end of the array. [ 5954.115381] BUG: unable to handle kernel paging request at 0000004000000000 [ 5954.120014] IP: __find_logger+0x6f/0xa0 [ 5954.123979] nf_log_bind_pf+0x2b/0x70 [ 5954.123979] nfulnl_recv_config+0xc0/0x4a0 [nfnetlink_log] [ 5954.123979] nfnetlink_rcv_msg+0x12c/0x1b0 [nfnetlink] ... The problem goes back to v2.6.30-rc1~1372~1342~31 where nf_log_bind was decoupled from nf_log_register. Reported-by: Miguel Di Ciurcio Filho <[email protected]>, via irc.freenode.net/#netfilter Signed-off-by: Jan Engelhardt <[email protected]> Signed-off-by: Patrick McHardy <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit dae781690ffa8c152cbdcdfaec404e53f7425535 Author: Hugh Dickins <[email protected]> Date: Wed Feb 23 21:39:49 2011 -0800 mm: fix possible cause of a page_mapped BUG commit a3e8cc643d22d2c8ed36b9be7d9c9ca21efcf7f7 upstream. Robert Swiecki reported a BUG_ON(page_mapped) from a fuzzer, punching a hole with madvise(,, MADV_REMOVE). That path is under mutex, and cannot be explained by lack of serialization in unmap_mapping_range(). Reviewing the code, I found one place where vm_truncate_count handling should have been updated, when I switched at the last minute from one way of managing the restart_addr to another: mremap move changes the virtual addresses, so it ought to adjust the restart_addr. But rather than exporting the notion of restart_addr from memory.c, or converting to restart_pgoff throughout, simply reset vm_truncate_count to 0 to force a rescan if mremap move races with preempted truncation. We have no confirmation that this fixes Robert's BUG, but it is a fix that's worth making anyway. Signed-off-by: Hugh Dickins <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Cc: Kerin Millar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 1e405a0b1b2beaf98da098e0a6711d243f5136ff Author: Don Skidmore <[email protected]> Date: Tue Jan 18 22:53:47 2011 +0000 ixgbe: fix for 82599 erratum on Header Splitting commit a124339ad28389093ed15eca990d39c51c5736cc upstream. We have found a hardware erratum on 82599 hardware that can lead to unpredictable behavior when Header Splitting mode is enabled. So we are no longer enabling this feature on affected hardware. Please see the 82599 Specification Update for more information. Signed-off-by: Don Skidmore <[email protected]> Tested-by: Stephen Ko <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4ae96ec5efcee1c3a5d6665e714d2e7add9533ea Author: Mohammed Shafi Shajakhan <[email protected]> Date: Fri Mar 4 23:00:30 2011 +0100 ath9k: Fix ath9k prevents CPU to enter C3 states This is a backport of upstream commit 0f5cd45960173ba5b36727decbb4a241cbd35ef9. The DMA latency issue is observed only in Intel pinetrail platforms but in the driver we had a default PM-QOS value of 55. This caused unnecessary power consumption and battery drain in other platforms. Remove the pm-qos thing in the driver code and address the throughput issue in Intel pinetrail platfroms in user space using any one of the scripts in below links: http://www.kernel.org/pub/linux/kernel/people/mcgrof/scripts/cpudmalatency.c http://johannes.sipsolutions.net/files/netlatency.c.txt More details can be found in the following bugzilla link: https://bugzilla.kernel.org/show_bug.cgi?id'532 Signed-off-by: Thomas Bächler <[email protected]> Acked-by: Mohammed Shafi Shajakhan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 5f7d5448e9d9b8f7edd354289a4acc0852a7178d Author: Anton Blanchard <[email protected]> Date: Mon Feb 28 03:27:53 2011 +0000 RxRPC: Fix v1 keys commit f009918a1c1bbf8607b8aab3959876913a30193a upstream. commit 339412841d7 (RxRPC: Allow key payloads to be passed in XDR form) broke klog for me. I notice the v1 key struct had a kif_version field added: -struct rxkad_key { - u16 security_index; /* RxRPC header security index */ - u16 ticket_len; /* length of ticket[] */ - u32 expiry; /* time at which expires */ - u32 kvno; /* key version number */ - u8 session_key[8]; /* DES session key */ - u8 ticket[0]; /* the encrypted ticket */ -}; +struct rxrpc_key_data_v1 { + u32 kif_version; /* 1 */ + u16 security_index; + u16 ticket_length; + u32 expiry; /* time_t */ + u32 kvno; + u8 session_key[8]; + u8 ticket[0]; +}; However the code in rxrpc_instantiate strips it away: data += sizeof(kver); datalen -= sizeof(kver); Removing kif_version fixes my problem. Signed-off-by: Anton Blanchard <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4ff51e31281b8628f6d2e16770e1f047efa34713 Author: Neil Horman <[email protected]> Date: Fri Mar 4 19:26:03 2011 -0500 nfs4: Ensure that ACL pages sent over NFS were not allocated from the slab (v3) commit e9e3d724e2145f5039b423c290ce2b2c3d8f94bc upstream. The "bad_page()" page allocator sanity check was reported recently (call chain as follows): bad_page+0x69/0x91 free_hot_cold_page+0x81/0x144 skb_release_data+0x5f/0x98 __kfree_skb+0x11/0x1a tcp_ack+0x6a3/0x1868 tcp_rcv_established+0x7a6/0x8b9 tcp_v4_do_rcv+0x2a/0x2fa tcp_v4_rcv+0x9a2/0x9f6 do_timer+0x2df/0x52c ip_local_deliver+0x19d/0x263 ip_rcv+0x539/0x57c netif_receive_skb+0x470/0x49f :virtio_net:virtnet_poll+0x46b/0x5c5 net_rx_action+0xac/0x1b3 __do_softirq+0x89/0x133 call_softirq+0x1c/0x28 do_softirq+0x2c/0x7d do_IRQ+0xec/0xf5 default_idle+0x0/0x50 ret_from_intr+0x0/0xa default_idle+0x29/0x50 cpu_idle+0x95/0xb8 start_kernel+0x220/0x225 _sinittext+0x22f/0x236 It occurs because an skb with a fraglist was freed from the tcp retransmit queue when it was acked, but a page on that fraglist had PG_Slab set (indicating it was allocated from the Slab allocator (which means the free path above can't safely free it via put_page. We tracked this back to an nfsv4 setacl operation, in which the nfs code attempted to fill convert the passed in buffer to an array of pages in __nfs4_proc_set_acl, which gets used by the skb->frags list in xs_sendpages. __nfs4_proc_set_acl just converts each page in the buffer to a page struct via virt_to_page, but the vfs allocates the buffer via kmalloc, meaning the PG_slab bit is set. We can't create a buffer with kmalloc and free it later in the tcp ack path with put_page, so we need to either: 1) ensure that when we create the list of pages, no page struct has PG_Slab set or 2) not use a page list to send this data Given that these buffers can be multiple pages and arbitrarily sized, I think (1) is the right way to go. I've written the below patch to allocate a page from the buddy allocator directly and copy the data over to it. This ensures that we have a put_page free-able page for every entry that winds up on an skb frag list, so it can be safely freed when the frame is acked. We do a put page on each entry after the rpc_call_sync call so as to drop our own reference count to the page, leaving only the ref count taken by tcp_sendpages. This way the data will be properly freed when the ack comes in Successfully tested by myself to solve the above oops. Note, as this is the result of a setacl operation that exceeded a page of data, I think this amounts to a local DOS triggerable by an uprivlidged user, so I'm CCing security on this as well. Signed-off-by: Neil Horman <[email protected]> CC: Trond Myklebust <[email protected]> CC: Jeff Layton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c2cd42c5dc289a5d5421b219cbaf6f8c8300e7af Author: Axel Lin <[email protected]> Date: Fri Mar 4 17:36:22 2011 -0800 drivers/misc/bmp085.c: add MODULE_DEVICE_TABLE commit 97e419a082461f8a3a0818834eb88ad41219a1da upstream. The device table is required to load modules based on modaliases. Signed-off-by: Axel Lin <[email protected]> Cc: Shubhrajyoti D <[email protected]> Cc: Christoph Mair <[email protected]> Cc: Jonathan Cameron <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 6ba0ed9b729362c07f757f4fe0f4db2e1edf0a56 Author: Takashi Iwai <[email protected]> Date: Thu Mar 3 14:54:19 2011 +0100 ALSA: hda - Don't set to D3 in Cirrus errata init verbs commit 38c07641905c0db58e800ea974cd9158717c6610 upstream. The errata init verbs for CS42xx codecs contain the verbs to set the power-state of SPDIF nodes to D3, which seem to break the SPDIF output on some MacBooks. Since this is executed during the power-up initialization, we shouldn't turn them down there. Reported-by: Arun Raghavan <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 6b01a69dd7e4dd65bbb4654167b6c88cb8461bdb Author: David Henningsson <[email protected]> Date: Mon Feb 28 15:58:07 2011 +0100 ALSA: HDA: Realtek: Fixup jack detection to input subsystem commit f0ce27996217d06207c8bfda1b1bbec2fbab48c6 upstream. This patch fixes an error in the jack detection reporting, causing the jack detection sometimes not to be reported correctly to the input subsystem. It should apply to several Realtek codecs. Signed-off-by: David Henningsson <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 39ebd87f25cc84d03f95379fa353bd9c385e76fa Author: Mark Brown <[email protected]> Date: Tue Mar 1 20:05:23 2011 +0000 ASoC: Fix WM9081 platform data initialisation commit 3ee845acba58549578d03a46ed307c0a56c7f777 upstream. It went AWOL in the multi-component conversion. Signed-off-by: Mark Brown <[email protected]> Acked-by: Liam Girdwood <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4a160e5fe42a7f670ae90890e1d26be72ec3751b Author: Dan Carpenter <[email protected]> Date: Thu Mar 3 17:56:06 2011 +0100 keyboard: integer underflow bug commit b652277b09d3d030cb074cc6a98ba80b34244c03 upstream. The "ct" variable should be an unsigned int. Both struct kbdiacrs ->kb_cnt and struct kbd_data ->accent_table_size are unsigned ints. Making it signed causes a problem in KBDIACRUC because the user could set the signed bit and cause a buffer overflow. Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 310f5e480c6facfdf9ee9e6952e490eebd3d8d55 Author: Amit Shah <[email protected]> Date: Fri Mar 4 14:04:33 2011 +1030 virtio: console: Don't access vqs if device was unplugged commit d7a62cd0332115d4c7c4689abea0d889a30d8349 upstream. If a virtio-console device gets unplugged while a port is open, a subsequent close() call on the port accesses vqs to free up buffers. This can lead to a crash. The buffers are already freed up as a result of the call to unplug_ports() from virtcons_remove(). The fix is to simply not access vq information if port->portdev is NULL. Reported-by: juzhang <[email protected]> Signed-off-by: Amit Shah <[email protected]> Signed-off-by: Rusty Russell <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 381d256c50541d46b505b9da5c3e405fe603d886 Author: Li Zefan <[email protected]> Date: Fri Mar 4 17:36:21 2011 -0800 cpuset: add a missing unlock in cpuset_write_resmask() commit b75f38d659e6fc747eda64cb72f3920e29dd44a4 upstream. Don't forget to release cgroup_mutex if alloc_trial_cpuset() fails. [[email protected]: avoid multiple return points] Signed-off-by: Li Zefan <[email protected]> Cc: Paul Menage <[email protected]> Acked-by: David Rientjes <[email protected]> Cc: Miao Xie <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hb197f07d15dbcd53328e75754e2f947814c733 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h c904c51dc195c90d22180529bab221b3644df2 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hÅ729162963b013f0e26b834b7d89b040178219e http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hå3b53dd4c61cbdefa897743060d662ac33e1595 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hÀ6dc644fc8af9dda13e4e7ed1178e9e9bf02438 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h b29c52f9efdd645d565f8be3915183819a6c3e http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h@65ec0806f8ba8ade4d8f01b44aed040aff8622 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hþa891e387dbd48bbe13d5a588059e879eaa8dfe http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h0b7cb312baeab0504e4ba1bc5b324abf7afcf68 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h¾70b4e2c60c2d7e03c3193cadd1cb9eddb5e4bc http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hË1f3fd3ba182cd514e2b72487a5f84932e6a03b http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h 328fe937351b9e7bea486e162d6a77bacb3b52 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h67008a7160188deb1e653d5dcaa630b16234b9 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hFd5660d9466b2adb89e87a221f095b17d69d943 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hsc2a0d93eb479373c14717a3e9bd0ce7b31e2e2 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h ac7b1dbe578f029927f821633bdac1e786fa66 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h³d26c5dbee6a6a088221017b817ed34e445da6e http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h¬e8f4534de7aa5c42b66751832e57eb4cdab7b5 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h!10938fd67a059ae99b030c74997cfb142c4d6b http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hÚe781690ffa8c152cbdcdfaec404e53f7425535 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h 405a0b1b2beaf98da098e0a6711d243f5136ff http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hJe96ec5efcee1c3a5d6665e714d2e7add9533ea http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h_7d5448e9d9b8f7edd354289a4acc0852a7178d http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hOf51e31281b8628f6d2e16770e1f047efa34713 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hÂcd42c5dc289a5d5421b219cbaf6f8c8300e7af http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hka0ed9b729362c07f757f4fe0f4db2e1edf0a56 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hk01a69dd7e4dd65bbb4654167b6c88cb8461bdb http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h9ebd87f25cc84d03f95379fa353bd9c385e76fa http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hJ160e5fe42a7f670ae90890e1d26be72ec3751b http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h10f5e480c6facfdf9ee9e6952e490eebd3d8d55 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h81d256c50541d46b505b9da5c3e405fe603d886
_______________________________________________ svn mailing list [email protected] http://mailman.vyatta.com/mailman/listinfo/svn
