commit 4af3051b26124834deea42b25a2543c5034031f1 Author: Paul Gortmaker Date: Sun Apr 17 16:16:27 2011 -0400 Linux 2.6.34.9 commit 6a6c24b6917692f826525ca5cb550f98982e39e8 Author: Ben Hutchings Date: Tue Sep 7 04:35:19 2010 +0000 niu: Fix kernel buffer overflow for ETHTOOL_GRXCLSRLALL commit ee9c5cfad29c8a13199962614b9b16f1c4137ac9 upstream. niu_get_ethtool_tcam_all() assumes that its output buffer is the right size, and warns before returning if it is not. However, the output buffer size is under user control and ETHTOOL_GRXCLSRLALL is an unprivileged ethtool command. Therefore this is at least a local denial-of-service vulnerability. Change it to check before writing each entry and to return an error if the buffer is already full. Compile-tested only. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 40b77a71b25fd1ec84fdc3abc2f928a872884b10 Author: Roland Dreier Date: Mon Mar 28 14:13:35 2011 -0700 Relax si_code check in rt_sigqueueinfo and rt_tgsigqueueinfo commit 243b422af9ea9af4ead07a8ad54c90d4f9b6081a upstream. Commit da48524eb206 ("Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from spoofing the signal code") made the check on si_code too strict. There are several legitimate places where glibc wants to queue a negative si_code different from SI_QUEUE: - This was first noticed with glibc's aio implementation, which wants to queue a signal with si_code SI_ASYNCIO; the current kernel causes glibc's tst-aio4 test to fail because rt_sigqueueinfo() fails with EPERM. - Further examination of the glibc source shows that getaddrinfo_a() wants to use SI_ASYNCNL (which the kernel does not even define). The timer_create() fallback code wants to queue signals with SI_TIMER. As suggested by Oleg Nesterov , loosen the check to forbid only the problematic SI_TKILL case. Reported-by: Klaus Dittrich Acked-by: Julien Tinnes Signed-off-by: Roland Dreier Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 9eab773eb3eda5d8336a8f0ac68c5e1faa5f88d5 Author: Julien Tinnes Date: Fri Mar 18 15:05:21 2011 -0700 Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from spoofing the signal code commit da48524eb20662618854bb3df2db01fc65f3070c upstream. Userland should be able to trust the pid and uid of the sender of a signal if the si_code is SI_TKILL. Unfortunately, the kernel has historically allowed sigqueueinfo() to send any si_code at all (as long as it was negative - to distinguish it from kernel-generated signals like SIGILL etc), so it could spoof a SI_TKILL with incorrect siginfo values. Happily, it looks like glibc has always set si_code to the appropriate SI_QUEUE, so there are probably no actual user code that ever uses anything but the appropriate SI_QUEUE flag. So just tighten the check for si_code (we used to allow any negative value), and add a (one-time) warning in case there are binaries out there that might depend on using other si_code values. Signed-off-by: Julien Tinnes Acked-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit c95610ef5cf44dcef45434ca6de0832aa9b02708 Author: Takashi Iwai Date: Mon Feb 14 22:45:59 2011 +0100 ALSA: caiaq - Fix possible string-buffer overflow commit eaae55dac6b64c0616046436b294e69fc5311581 upstream Use strlcpy() to assure not to overflow the string array sizes by too long USB device name string. Reported-by: Rafa Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 7eab63eb262398e1e3b94dee3cc7f96b9ca92abe Author: Xiaotian Feng Date: Mon Nov 29 10:03:55 2010 +0100 block: check for proper length of iov entries earlier in blk_rq_map_user_iov() commit 5478755616ae2ef1ce144dded589b62b2a50d575 upstream. commit 9284bcf checks for proper length of iov entries in blk_rq_map_user_iov(). But if the map is unaligned, kernel will break out the loop without checking for the proper length. So we need to check the proper length before the unalign check. Signed-off-by: Xiaotian Feng Signed-off-by: Jens Axboe Signed-off-by: Paul Gortmaker commit 799c3ec501854be3d6be56c1db5452e2e8371ef4 Author: Dan Rosenberg Date: Fri Oct 1 11:51:47 2010 +0000 sctp: Fix out-of-bounds reading in sctp_asoc_get_hmac() commit 51e97a12bef19b7e43199fc153cf9bd5f2140362 upstream The sctp_asoc_get_hmac() function iterates through a peer's hmac_ids array and attempts to ensure that only a supported hmac entry is returned. The current code fails to do this properly - if the last id in the array is out of range (greater than SCTP_AUTH_HMAC_ID_MAX), the id integer remains set after exiting the loop, and the address of an out-of-bounds entry will be returned and subsequently used in the parent function, causing potentially ugly memory corruption. This patch resets the id integer to 0 on encountering an invalid id so that NULL will be returned after finishing the loop if no valid ids are found. Signed-off-by: Dan Rosenberg Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit eef557db3e67f4897c21423d4f2d41392458aa9c Author: Li Zefan Date: Thu Mar 11 14:08:10 2010 -0800 sunrpc/cache: fix module refcnt leak in a failure path commit a5990ea1254cd186b38744507aeec3136a0c1c95 upstream Don't forget to release the module refcnt if seq_open() returns failure. Signed-off-by: Li Zefan Cc: J. Bruce Fields Cc: Neil Brown Cc: Trond Myklebust Signed-off-by: Andrew Morton Signed-off-by: J. Bruce Fields Signed-off-by: Paul Gortmaker commit c81ac5970095a62139f4904e638c304b220e76e5 Author: Guenter Roeck Date: Fri Jan 21 09:42:17 2011 +0100 hwmon: (w83627ehf) Fix max_output and step_output readings [extraction from commit da2e025590cf7038440132d4bbc967a579b11112 upstream] The value of max_output and step_output registers isn't read from the respective registers. As a result, zero values are returned to the user through the respective sysfs attributes, instead of the actual fan control settings. The problem is fixed by updating the fan max output and fan step output information from data in registers. Signed-off-by: Guenter Roeck Signed-off-by: Jean Delvare Signed-off-by: Paul Gortmaker commit 595e0399c0ab27188f4067e44274662fbe3aa4ce Author: stephen hemminger Date: Thu Mar 10 11:43:19 2011 +0000 ip6ip6: autoload ip6 tunnel commit 6dfbd87a20a737641ef228230c77f4262434fa24 upstream. Add necessary alias to autoload ip6ip6 tunnel module. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 5724b2c2e3703ca7f540f5c584453c157acc36dd Author: Vasiliy Kulikov 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 [PG: in 2.6.34, the bare MODULE_ALIAS for ipip/tunl0 and ip_gre/gre0 didn't exist, but this adds the limited scope MODULE_ALIAS_NETDEV ones] Signed-off-by: Vasiliy Kulikov Signed-off-by: Michael Tokarev Acked-by: David S. Miller Acked-by: Kees Cook Signed-off-by: James Morris Signed-off-by: Paul Gortmaker commit 4507b718182f5f0e8fbd52fd29f4acbf3acb68f8 Author: Dave Airlie Date: Thu Feb 24 08:35:06 2011 +1000 drm: fix unsigned vs signed comparison issue in modeset ctl ioctl. commit 1922756124ddd53846877416d92ba4a802bc658f upstream. This fixes CVE-2011-1013. Reported-by: Matthiew Herrb (OpenBSD X.org team) Signed-off-by: Dave Airlie Signed-off-by: Paul Gortmaker commit 1ccf475f3f27eed4a82e1d79ef5d5984ebaf94a6 Author: David S. Miller Date: Wed Feb 9 21:48:36 2011 -0800 x25: Do not reference freed memory. commit 96642d42f076101ba98866363d908cab706d156c upstream. In x25_link_free(), we destroy 'nb' before dereferencing 'nb->dev'. Don't do this, because 'nb' might be freed by then. Reported-by: Randy Dunlap Tested-by: Randy Dunlap Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 352247f7d619d947d6f6ce05e18216a4fede2a7c Author: Dan Carpenter Date: Fri Jan 7 16:41:54 2011 -0300 av7110: check for negative array offset commit cb26a24ee9706473f31d34cc259f4dcf45cd0644 upstream info->num comes from the user. It's type int. If the user passes in a negative value that would cause memory corruption. Signed-off-by: Dan Carpenter Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Paul Gortmaker commit a330b207090a5698c308937291a728e3e884d3ea Author: NeilBrown Date: Wed Jan 12 09:03:35 2011 +1100 md: fix regression with re-adding devices to arrays with no metadata commit bf572541ab44240163eaa2d486b06f306a31d45a upstream. Commit 1a855a0606 (2.6.37-rc4) fixed a problem where devices were re-added when they shouldn't be but caused a regression in a less common case that means sometimes devices cannot be re-added when they should be. In particular, when re-adding a device to an array without metadata we should always access the device, but after the above commit we didn't. This patch sets the In_sync flag in that case so that the re-add succeeds. This patch is suitable for any -stable kernel to which 1a855a0606 was applied. Signed-off-by: NeilBrown Signed-off-by: Paul Gortmaker commit ebc34eb7134b13d6a886f185e6ffd4535e7da220 Author: Oleg Nesterov Date: Fri Nov 5 16:53:42 2010 +0100 posix-cpu-timers: workaround to suppress the problems with mt exec commit e0a70217107e6f9844628120412cb27bb4cea194 upstream. posix-cpu-timers.c correctly assumes that the dying process does posix_cpu_timers_exit_group() and removes all !CPUCLOCK_PERTHREAD timers from signal->cpu_timers list. But, it also assumes that timer->it.cpu.task is always the group leader, and thus the dead ->task means the dead thread group. This is obviously not true after de_thread() changes the leader. After that almost every posix_cpu_timer_ method has problems. It is not simple to fix this bug correctly. First of all, I think that timer->it.cpu should use struct pid instead of task_struct. Also, the locking should be reworked completely. In particular, tasklist_lock should not be used at all. This all needs a lot of nontrivial and hard-to-test changes. Change __exit_signal() to do posix_cpu_timers_exit_group() when the old leader dies during exec. This is not the fix, just the temporary hack to hide the problem for 2.6.37 and stable. IOW, this is obviously wrong but this is what we currently have anyway: cpu timers do not work after mt exec. In theory this change adds another race. The exiting leader can detach the timers which were attached to the new leader. However, the window between de_thread() and release_task() is small, we can pretend that sys_timer_create() was called before de_thread(). Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit f241075f7a2ab1a766583ed83202728a17d0d93e Author: Martin K. Petersen Date: Wed Dec 1 19:41:49 2010 +0100 block: Deprecate QUEUE_FLAG_CLUSTER and use queue_limits instead commit e692cb668fdd5a712c6ed2a2d6f2a36ee83997b4 upstream. When stacking devices, a request_queue is not always available. This forced us to have a no_cluster flag in the queue_limits that could be used as a carrier until the request_queue had been set up for a metadevice. There were several problems with that approach. First of all it was up to the stacking device to remember to set queue flag after stacking had completed. Also, the queue flag and the queue limits had to be kept in sync at all times. We got that wrong, which could lead to us issuing commands that went beyond the max scatterlist limit set by the driver. The proper fix is to avoid having two flags for tracking the same thing. We deprecate QUEUE_FLAG_CLUSTER and use the queue limit directly in the block layer merging functions. The queue_limit 'no_cluster' is turned into 'cluster' to avoid double negatives and to ease stacking. Clustering defaults to being enabled as before. The queue flag logic is removed from the stacking function, and explicitly setting the cluster flag is no longer necessary in DM and MD. Reported-by: Ed Lin Signed-off-by: Martin K. Petersen Acked-by: Mike Snitzer Signed-off-by: Jens Axboe Signed-off-by: Paul Gortmaker commit 5f4dff37cccdf85243f50e877af7090afe186931 Author: Daniel T Chen Date: Tue Dec 28 17:20:02 2010 -0500 ALSA: hda: Use LPIB quirk for Dell Inspiron m101z/1120 commit e03fa055bc126e536c7f65862e08a9b143138ea9 upstream. Sjoerd Simons reports that, without using position_fix=1, recording experiences overruns. Work around that by applying the LPIB quirk for his hardware. Reported-and-tested-by: Sjoerd Simons Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit cd67d1519ad905f4df99d72faa124617cb62c039 Author: Mimi Zohar Date: Mon Jan 3 14:59:10 2011 -0800 ima: fix add LSM rule bug commit 867c20265459d30a01b021a9c1e81fb4c5832aa9 upstream. If security_filter_rule_init() doesn't return a rule, then not everything is as fine as the return code implies. This bug only occurs when the LSM (eg. SELinux) is disabled at runtime. Adding an empty LSM rule causes ima_match_rules() to always succeed, ignoring any remaining rules. default IMA TCB policy: # PROC_SUPER_MAGIC dont_measure fsmagic=0x9fa0 # SYSFS_MAGIC dont_measure fsmagic=0x62656572 # DEBUGFS_MAGIC dont_measure fsmagic=0x64626720 # TMPFS_MAGIC dont_measure fsmagic=0x01021994 # SECURITYFS_MAGIC dont_measure fsmagic=0x73636673 < LSM specific rule > dont_measure obj_type=var_log_t measure func=BPRM_CHECK measure func=FILE_MMAP mask=MAY_EXEC measure func=FILE_CHECK mask=MAY_READ uid=0 Thus without the patch, with the boot parameters 'tcb selinux=0', adding the above 'dont_measure obj_type=var_log_t' rule to the default IMA TCB measurement policy, would result in nothing being measured. The patch prevents the default TCB policy from being replaced. Signed-off-by: Mimi Zohar Cc: James Morris Acked-by: Serge Hallyn Cc: David Safford Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 2ed78fb1ecfda3f4fa0fd858bde5384738ba8f6e Author: Saeed Bishara Date: Tue Dec 21 16:53:39 2010 +0200 mv_xor: fix race in tasklet function commit 8333f65ef094e47020cd01452b4637e7daf5a77f upstream. use mv_xor_slot_cleanup() instead of __mv_xor_slot_cleanup() as the former function aquires the spin lock that needed to protect the drivers data. Signed-off-by: Saeed Bishara Signed-off-by: Dan Williams Signed-off-by: Paul Gortmaker commit 7eba652201dd791aa124afb1cabba6d4cc780072 Author: Dan Rosenberg Date: Sat Dec 25 16:23:40 2010 -0500 sound: Prevent buffer overflow in OSS load_mixer_volumes commit d81a12bc29ae4038770e05dce4ab7f26fd5880fb upstream. The load_mixer_volumes() function, which can be triggered by unprivileged users via the SOUND_MIXER_SETLEVELS ioctl, is vulnerable to a buffer overflow. Because the provided "name" argument isn't guaranteed to be NULL terminated at the expected 32 bytes, it's possible to overflow past the end of the last element in the mixer_vols array. Further exploitation can result in an arbitrary kernel write (via subsequent calls to load_mixer_volumes()) leading to privilege escalation, or arbitrary kernel reads via get_mixer_levels(). In addition, the strcmp() may leak bytes beyond the mixer_vols array. Signed-off-by: Dan Rosenberg Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 19038636ecc62e79a089155d8576bcfce6dc0ab3 Author: Eduardo Costa Date: Tue Dec 14 14:37:59 2010 -0600 p54usb: New USB ID for Gemtek WUBI-100GW commit 56e6417b49132d4f56e9f2241d31942b90b46315 upstream. This USB ID is for the WUBI-100GW 802.11g Wireless LAN USB Device that uses p54usb. Signed-off-by: Larry Finger Signed-off-by: Eduardo Costa Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit 37985bf9544667461d6f3d8b197ce5addfb7d6ec Author: Christian Lamparter Date: Sat Dec 11 12:19:48 2010 +0100 p54usb: add 5 more USBIDs commit 16cad7fba037b34ca32cc0adac65bc089d969fb8 upstream. This patch adds five more USBIDs to the table. Source: http://www.linuxant.com/pipermail/driverloader/2005q3/002307.html http://wireless.kernel.org/en/users/Drivers/p54/devices (by M. Davis) Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit c711dfdcfb13f351e1ea8de70c9b3660100444c7 Author: Vitaly Kuznetsov Date: Tue Dec 14 10:16:49 2010 -0500 USB: usb-storage: unusual_devs entry for the Samsung YP-CP3 commit d73a9b3001f29271c2e9f2a806b05a431c5d9591 upstream. Add an unusual_devs entry for the Samsung YP-CP3 MP4 player. User was getting the following errors in dmesg: usb 2-6: reset high speed USB device using ehci_hcd and address 2 usb 2-6: reset high speed USB device using ehci_hcd and address 2 usb 2-6: reset high speed USB device using ehci_hcd and address 2 usb 2-6: USB disconnect, address 2 sd 3:0:0:0: [sdb] Assuming drive cache: write through sdb:<2>ldm_validate_partition_table(): Disk read failed. Dev sdb: unable to read RDB block 0 unable to read partition table [PG: change USB_ --> US_ to match 2.6.34.x naming conventions] Signed-off-by: Vitaly Kuznetsov Acked-by: Alan Stern CC: Matthew Dharm Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 4b5066c58b8847c708cb1149003d1ffa1a2df271 Author: Florian Faber Date: Wed Dec 1 10:11:08 2010 +0100 USB: ftdi_sio: Add D.O.Tec PID commit 5363cdc3c5da9bd431552cf5989ab481596f0c6d upstream. Add FTDI PID to identify D.O.Tec devices correctly. Signed-off-by: Florian Faber Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 7f645009fd2a21495f283f9ec30ad602af64348c Author: Thomas Sailer Date: Tue Dec 14 16:04:05 2010 +0100 USB: misc: uss720.c: add another vendor/product ID commit ecc1624a2fff45780959efbcb73ace18fdb3c58d upstream. Fabio Battaglia report that he has another cable that works with this driver, so this patch adds its vendor/product ID. Signed-off-by: Thomas Sailer Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit caec9eda838b05b01c56b2cd6a89161e8b57ffd8 Author: Tavis Ormandy Date: Thu Dec 9 15:29:42 2010 +0100 install_special_mapping skips security_file_mmap check. commit 462e635e5b73ba9a4c03913b77138cd57ce4b050 upstream. The install_special_mapping routine (used, for example, to setup the vdso) skips the security check before insert_vm_struct, allowing a local attacker to bypass the mmap_min_addr security restriction by limiting the available pages for special mappings. bprm_mm_init() also skips the check, and although I don't think this can be used to bypass any restrictions, I don't see any reason not to have the security check. $ uname -m x86_64 $ cat /proc/sys/vm/mmap_min_addr 65536 $ cat install_special_mapping.s section .bss resb BSS_SIZE section .text global _start _start: mov eax, __NR_pause int 0x80 $ nasm -D__NR_pause=29 -DBSS_SIZE=0xfffed000 -f elf -o install_special_mapping.o install_special_mapping.s $ ld -m elf_i386 -Ttext=0x10000 -Tbss=0x11000 -o install_special_mapping install_special_mapping.o $ ./install_special_mapping & [1] 14303 $ cat /proc/14303/maps 0000f000-00010000 r-xp 00000000 00:00 0 [vdso] 00010000-00011000 r-xp 00001000 00:19 2453665 /home/taviso/install_special_mapping 00011000-ffffe000 rwxp 00000000 00:00 0 [stack] It's worth noting that Red Hat are shipping with mmap_min_addr set to 4096. Signed-off-by: Tavis Ormandy Acked-by: Kees Cook Acked-by: Robert Swiecki [ Changed to not drop the error code - akpm ] Reviewed-by: James Morris Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 3ed5538cbde188c9f5592a1852b238b7670b0d08 Author: Krishna Gudipati Date: Fri May 21 14:39:45 2010 -0700 bfa: fix system crash when reading sysfs fc_host statistics commit 7873ca4e4401f0ecd8868bf1543113467e6bae61 upstream. The port data structure related to fc_host statistics collection is not initialized. This causes system crash when reading the fc_host statistics. The fix is to initialize port structure during driver attach. Signed-off-by: Krishna Gudipati Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit e4f51ee7c6f1a43f91cec2b364eb6a30fa66fdb0 Author: Jiri Slaby Date: Tue Oct 19 11:29:55 2010 +0200 HID: hidraw: fix window in hidraw_release commit cb174681a9ececa6702f114b85bdf82144b6a5af upstream. There is a window between hidraw_table check and its dereference. In that window, the device may be unplugged and removed form the system and we will then dereference NULL. Lock that place properly so that either we get NULL and jump out or we can work with real pointer. [PG: slightly/trivially reworked for backport to 34] Signed-off-by: Jiri Slaby Signed-off-by: Jiri Kosina Signed-off-by: Paul Gortmaker commit c34b86ec30033021cab40e6326e21ffdd2af1f4b Author: Suresh Siddha Date: Mon Dec 6 12:26:30 2010 -0800 x86, vt-d: Quirk for masking vtd spec errors to platform error handling logic commit 254e42006c893f45bca48f313536fcba12206418 upstream. On platforms with Intel 7500 chipset, there were some reports of system hang/NMI's during kexec/kdump in the presence of interrupt-remapping enabled. During kdump, there is a window where the devices might be still using old kernel's interrupt information, while the kdump kernel is coming up. This can cause vt-d faults as the interrupt configuration from the old kernel map to null IRTE entries in the new kernel etc. (with out interrupt-remapping enabled, we still have the same issue but in this case we will see benign spurious interrupt hit the new kernel). Based on platform config settings, these platforms seem to generate NMI/SMI when a vt-d fault happens and there were reports that the resulting SMI causes the system to hang. Fix it by masking vt-d spec defined errors to platform error reporting logic. VT-d spec related errors are already handled by the VT-d OS code, so need to report the same error through other channels. Signed-off-by: Suresh Siddha LKML-Reference: <1291667190.2675.8.camel@sbsiddha-MOBL3.sc.intel.com> Reported-by: Max Asbock Reported-and-tested-by: Takao Indoh Acked-by: Chris Wright Acked-by: Kenji Kaneshige Signed-off-by: H. Peter Anvin Signed-off-by: Paul Gortmaker commit 18e3a04ee0c226ca101f1eebe172eebb062a760c Author: Kenji Kaneshige Date: Wed Dec 1 09:40:32 2010 -0800 x86, vt-d: Fix the vt-d fault handling irq migration in the x2apic mode commit 086e8ced65d9bcc4a8e8f1cd39b09640f2883f90 upstream. In x2apic mode, we need to set the upper address register of the fault handling interrupt register of the vt-d hardware. Without this irq migration of the vt-d fault handling interrupt is broken. Signed-off-by: Kenji Kaneshige LKML-Reference: <1291225233.2648.39.camel@sbsiddha-MOBL3> Signed-off-by: Suresh Siddha Acked-by: Chris Wright Tested-by: Takao Indoh Signed-off-by: H. Peter Anvin Signed-off-by: Paul Gortmaker commit 8b98fee00f591defb9f9d2f6b57f3902d5f83821 Author: Suresh Siddha Date: Tue Nov 30 22:22:29 2010 -0800 x86, vt-d: Handle previous faults after enabling fault handling commit 7f99d946e71e71d484b7543b49e990508e70d0c0 upstream. Fault handling is getting enabled after enabling the interrupt-remapping (as the success of interrupt-remapping can affect the apic mode and hence the fault handling mode). Hence there can potentially be some faults between the window of enabling interrupt-remapping in the vt-d and the fault-handling of the vt-d units. Handle any previous faults after enabling the vt-d fault handling. For v2.6.38 cleanup, need to check if we can remove the dmar_fault() in the enable_intr_remapping() and see if we can enable fault handling along with enabling intr-remapping. Signed-off-by: Suresh Siddha LKML-Reference: <20101201062244.630417138@intel.com> Acked-by: Chris Wright Signed-off-by: H. Peter Anvin Signed-off-by: Paul Gortmaker commit 825b35ab8425bbc397ae6927d9b31823388cf440 Author: Kenji Kaneshige Date: Tue Nov 30 22:22:28 2010 -0800 x86: Enable the intr-remap fault handling after local APIC setup commit 7f7fbf45c6b748074546f7f16b9488ca71de99c1 upstream. Interrupt-remapping gets enabled very early in the boot, as it determines the apic mode that the processor can use. And the current code enables the vt-d fault handling before the setup_local_APIC(). And hence the APIC LDR registers and data structure in the memory may not be initialized. So the vt-d fault handling in logical xapic/x2apic modes were broken. Fix this by enabling the vt-d fault handling in the end_local_APIC_setup() A cleaner fix of enabling fault handling while enabling intr-remapping will be addressed for v2.6.38. [ Enabling intr-remapping determines the usage of x2apic mode and the apic mode determines the fault-handling configuration. ] Signed-off-by: Kenji Kaneshige LKML-Reference: <20101201062244.541996375@intel.com> Signed-off-by: Suresh Siddha Acked-by: Chris Wright Signed-off-by: H. Peter Anvin Signed-off-by: Paul Gortmaker commit 744f6b09cec703e9935c2a4813f1311233db1e19 Author: H. Peter Anvin Date: Mon Dec 13 16:01:38 2010 -0800 x86, gcc-4.6: Use gcc -m options when building vdso commit de2a8cf98ecdde25231d6c5e7901e2cffaf32af9 upstream. The vdso Makefile passes linker-style -m options not to the linker but to gcc. This happens to work with earlier gcc, but fails with gcc 4.6. Pass gcc-style -m options, instead. Note: all currently supported versions of gcc supports -m32, so there is no reason to conditionalize it any more. Reported-by: H. J. Lu Signed-off-by: H. Peter Anvin LKML-Reference: Signed-off-by: Paul Gortmaker commit ae621e2431fa476dcbe1daf1d9d278085b0e95e3 Author: Slava Pestov Date: Wed Nov 24 15:13:16 2010 -0800 tracing: Fix panic when lseek() called on "trace" opened for writing commit 364829b1263b44aa60383824e4c1289d83d78ca7 upstream. The file_ops struct for the "trace" special file defined llseek as seq_lseek(). However, if the file was opened for writing only, seq_open() was not called, and the seek would dereference a null pointer, file->private_data. This patch introduces a new wrapper for seq_lseek() which checks if the file descriptor is opened for reading first. If not, it does nothing. Signed-off-by: Slava Pestov LKML-Reference: <1290640396-24179-1-git-send-email-slavapestov@google.com> Signed-off-by: Steven Rostedt Signed-off-by: Paul Gortmaker commit 3b1c91ceeaa02ca5fac9312eed959253297a01b7 Author: NeilBrown Date: Thu Dec 9 16:36:28 2010 +1100 md: fix bug with re-adding of partially recovered device. commit 1a855a0606653d2d82506281e2c686bacb4b2f45 upstream. With v0.90 metadata, a hot-spare does not become a full member of the array until recovery is complete. So if we re-add such a device to the array, we know that all of it is as up-to-date as the event count would suggest, and so it a bitmap-based recovery is possible. However with v1.x metadata, the hot-spare immediately becomes a full member of the array, but it record how much of the device has been recovered. If the array is stopped and re-assembled recovery starts from this point. When such a device is hot-added to an array we currently lose the 'how much is recovered' information and incorrectly included it as a full in-sync member (after bitmap-based fixup). This is wrong and unsafe and could corrupt data. So be more careful about setting saved_raid_disk - which is what guides the re-adding of devices back into an array. The new code matches the code in slot_store which does a similar thing, which is encouraging. This is suitable for any -stable kernel. Reported-by: "Dailey, Nate" Signed-off-by: NeilBrown Signed-off-by: Paul Gortmaker commit 51ec1aaccf4887cd27eb183caf28e0dadcdc135b Author: David Kilroy Date: Sun Dec 5 15:45:58 2010 +0000 orinoco: clear countermeasure setting on commit commit ba34fcee476d11e7c9df95932787a22a96ff6e68 upstream. ... and interface up. In these situations, you are usually trying to connect to a new AP, so keeping TKIP countermeasures active is confusing. This is already how the driver behaves (inadvertently). However, querying SIOCGIWAUTH may tell userspace that countermeasures are active when they aren't. Clear the setting so that the reporting matches what the driver has done.. Signed-off by: David Kilroy Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit 553120266ee11698190b87aea5424f624b5af62a Author: David Kilroy Date: Sun Dec 5 15:43:55 2010 +0000 orinoco: fix TKIP countermeasure behaviour commit 0a54917c3fc295cb61f3fb52373c173fd3b69f48 upstream. Enable the port when disabling countermeasures, and disable it on enabling countermeasures. This bug causes the response of the system to certain attacks to be ineffective. It also prevents wpa_supplicant from getting scan results, as wpa_supplicant disables countermeasures on startup - preventing the hardware from scanning. wpa_supplicant works with ap_mode=2 despite this bug because the commit handler re-enables the port. The log tends to look like: State: DISCONNECTED -> SCANNING Starting AP scan for wildcard SSID Scan requested (ret=0) - scan timeout 5 seconds EAPOL: disable timer tick EAPOL: Supplicant port status: Unauthorized Scan timeout - try to get results Failed to get scan results Failed to get scan results - try scanning again Setting scan request: 1 sec 0 usec Starting AP scan for wildcard SSID Scan requested (ret=-1) - scan timeout 5 seconds Failed to initiate AP scan. Reported by: Giacomo Comes Signed-off by: David Kilroy Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit 5d58e3d7b5706db97da40c19a10c9cec41074190 Author: Alexey Starikovskiy Date: Thu Dec 9 17:07:54 2010 -0500 ACPI: EC: Add another dmi match entry for MSI hardware commit a5dc4f898c2a0f66e2cefada6c687db82ba2fcbc upstream. http://bugzilla.kernel.org/show_bug.cgi?id=15418 Signed-off-by: Alexey Starikovskiy Signed-off-by: Len Brown Signed-off-by: Paul Gortmaker commit 4137755a3ba6d01de063293b68a9b4419adb8cfd Author: Bob Moore Date: Sat Oct 23 01:36:40 2010 -0400 Subject: [PATCH] ACPICA: Fix Scope() op in module level code commit 8df3fc981dc12d9fdcaef4100a2193b605024d7a upstream. Some Panasonic Toughbooks create nodes in module level code. Module level code is the executable AML code outside of control method, for example, below AML code creates a node \_SB.PCI0.GFX0.DD02.CUBL If (\_OSI ("Windows 2006")) { Scope (\_SB.PCI0.GFX0.DD02) { Name (CUBL, Ones) ... } } Scope() op does not actually create a new object, it refers to an existing object(\_SB.PCI0.GFX0.DD02 in above example). However, for Scope(), we want to indeed open a new scope, so the child nodes(CUBL in above example) can be created correctly under it. https://bugzilla.kernel.org/show_bug.cgi?id=19462 Signed-off-by: Bob Moore Signed-off-by: Lin Ming Signed-off-by: Len Brown Signed-off-by: Paul Gortmaker commit e3dc1fabddcbc9a4d3fabb74671d521e68da2206 Author: Takashi Iwai Date: Fri Dec 10 00:16:39 2010 +0100 PM / Hibernate: Fix PM_POST_* notification with user-space suspend commit 1497dd1d29c6a53fcd3c80f7ac8d0e0239e7389e upstream. The user-space hibernation sends a wrong notification after the image restoration because of thinko for the file flag check. RDONLY corresponds to hibernation and WRONLY to restoration, confusingly. Signed-off-by: Takashi Iwai Signed-off-by: Rafael J. Wysocki Signed-off-by: Paul Gortmaker commit 430ed48fcb365a7cc37da414c284930f217a609b Author: Dan Carpenter Date: Wed Oct 13 09:13:12 2010 +0000 IB/uverbs: Handle large number of entries in poll CQ commit 7182afea8d1afd432a17c18162cc3fd441d0da93 upstream. In ib_uverbs_poll_cq() code there is a potential integer overflow if userspace passes in a large cmd.ne. The calls to kmalloc() would allocate smaller buffers than intended, leading to memory corruption. There iss also an information leak if resp wasn't all used. Unprivileged userspace may call this function, although only if an RDMA device that uses this function is present. Fix this by copying CQ entries one at a time, which avoids the allocation entirely, and also by moving this copying into a function that makes sure to initialize all memory copied to userspace. Special thanks to Jason Gunthorpe for his help and advice. Signed-off-by: Dan Carpenter [ Monkey around with things a bit to avoid bad code generation by gcc when designated initializers are used. - Roland ] Signed-off-by: Roland Dreier Signed-off-by: Paul Gortmaker commit a89d724d8e8c61146c3bc03564e7a70c0e3c0bb2 Author: Borislav Petkov Date: Mon Dec 6 16:20:25 2010 +0100 amd64_edac: Fix interleaving check commit e726f3c368e7c1919a7166ec09c5705759f1a69d upstream. When matching error address to the range contained by one memory node, we're in valid range when node interleaving 1. is disabled, or 2. enabled and when the address bits we interleave on match the interleave selector on this node (see the "Node Interleaving" section in the BKDG for an enlightening example). Thus, when we early-exit, we need to reverse the compound logic statement properly. Signed-off-by: Borislav Petkov Signed-off-by: Paul Gortmaker commit a17cb3a023a04e88b0e97fa282efa56ccf81a30f Author: Gabriele Gorla Date: Wed Dec 8 16:27:22 2010 +0100 hwmon: (adm1026) Fix setting fan_div commit 52bc9802ce849d0d287cc5fe76d06b0daa3986ca upstream. Prevent setting fan_div from stomping on other fans that share the same I2C register. Signed-off-by: Gabriele Gorla Signed-off-by: Jean Delvare Signed-off-by: Paul Gortmaker commit 65b35399d24e70a59f3200749c5190584d586731 Author: Gabriele Gorla Date: Wed Dec 8 16:27:22 2010 +0100 hwmon: (adm1026) Allow 1 as a valid divider value commit 8b0f1840a46449e1946fc88860ef3ec8d6b1c2c7 upstream. Allow 1 as a valid div value as specified in the ADM1026 datasheet. Signed-off-by: Gabriele Gorla Signed-off-by: Jean Delvare Signed-off-by: Paul Gortmaker commit 5fb592d3df35de794c8fcad3d0f8c6320301b516 Author: NeilBrown Date: Tue Nov 16 16:55:19 2010 +1100 sunrpc: prevent use-after-free on clearing XPT_BUSY commit ed2849d3ecfa339435818eeff28f6c3424300cec upstream. When an xprt is created, it has a refcount of 1, and XPT_BUSY is set. The refcount is *not* owned by the thread that created the xprt (as is clear from the fact that creators never put the reference). Rather, it is owned by the absence of XPT_DEAD. Once XPT_DEAD is set, (And XPT_BUSY is clear) that initial reference is dropped and the xprt can be freed. So when a creator clears XPT_BUSY it is dropping its only reference and so must not touch the xprt again. However svc_recv, after calling ->xpo_accept (and so getting an XPT_BUSY reference on a new xprt), calls svc_xprt_recieved. This clears XPT_BUSY and then svc_xprt_enqueue - this last without owning a reference. This is dangerous and has been seen to leave svc_xprt_enqueue working with an xprt containing garbage. So we need to hold an extra counted reference over that call to svc_xprt_received. For safety, any time we clear XPT_BUSY and then use the xprt again, we first get a reference, and the put it again afterwards. Note that svc_close_all does not need this extra protection as there are no threads running, and the final free can only be called asynchronously from such a thread. Signed-off-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Paul Gortmaker commit c0430f6fd2c0c2a7fa794df1d041752f9bb938ef Author: Sergey Vlasov Date: Sun Nov 28 21:04:05 2010 +0000 NFS: Fix fcntl F_GETLK not reporting some conflicts commit 21ac19d484a8ffb66f64487846c8d53afef04d2b upstream. The commit 129a84de2347002f09721cda3155ccfd19fade40 (locks: fix F_GETLK regression (failure to find conflicts)) fixed the posix_test_lock() function by itself, however, its usage in NFS changed by the commit 9d6a8c5c213e34c475e72b245a8eb709258e968c (locks: give posix_test_lock same interface as ->lock) remained broken - subsequent NFS-specific locking code received F_UNLCK instead of the user-specified lock type. To fix the problem, fl->fl_type needs to be saved before the posix_test_lock() call and restored if no local conflicts were reported. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=23892 Tested-by: Alexander Morozov Signed-off-by: Sergey Vlasov Signed-off-by: Trond Myklebust Signed-off-by: Paul Gortmaker commit 85f936885acc911d44cca888dcf313a0aa5adfa1 Author: Neil Brown Date: Thu Dec 2 11:14:30 2010 +1100 nfsd: Fix possible BUG_ON firing in set_change_info commit c1ac3ffcd0bc7e9617f62be8c7043d53ab84deac upstream. If vfs_getattr in fill_post_wcc returns an error, we don't set fh_post_change. For NFSv4, this can result in set_change_info triggering a BUG_ON. i.e. fh_post_saved being zero isn't really a bug. So: - instead of BUGging when fh_post_saved is zero, just clear ->atomic. - if vfs_getattr fails in fill_post_wcc, take a copy of i_ctime anyway. This will be used i seg_change_info, but not overly trusted. - While we are there, remove the pointless 'if' statements in set_change_info. There is no harm setting all the values. Signed-off-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Paul Gortmaker commit c438fc212dd9fb27a8fd2c34e179bee6c0b33fc0 Author: Chuck Lever Date: Fri Dec 10 12:31:14 2010 -0500 NFS: Fix panic after nfs_umount() commit 5b362ac3799ff4225c40935500f520cad4d7ed66 upstream. After a few unsuccessful NFS mount attempts in which the client and server cannot agree on an authentication flavor both support, the client panics. nfs_umount() is invoked in the kernel in this case. Turns out nfs_umount()'s UMNT RPC invocation causes the RPC client to write off the end of the rpc_clnt's iostat array. This is because the mount client's nrprocs field is initialized with the count of defined procedures (two: MNT and UMNT), rather than the size of the client's proc array (four). The fix is to use the same initialization technique used by most other upper layer clients in the kernel. Introduced by commit 0b524123, which failed to update nrprocs when support was added for UMNT in the kernel. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=24302 BugLink: http://bugs.launchpad.net/bugs/683938 Reported-by: Stefan Bader Tested-by: Stefan Bader Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Paul Gortmaker commit ea9f5e5405fac791c3e1cde11e6254b3c1481fde Author: Heiko Carstens Date: Wed Dec 1 10:11:09 2010 +0100 nohz: Fix get_next_timer_interrupt() vs cpu hotplug commit dbd87b5af055a0cc9bba17795c9a2b0d17795389 upstream. This fixes a bug as seen on 2.6.32 based kernels where timers got enqueued on offline cpus. If a cpu goes offline it might still have pending timers. These will be migrated during CPU_DEAD handling after the cpu is offline. However while the cpu is going offline it will schedule the idle task which will then call tick_nohz_stop_sched_tick(). That function in turn will call get_next_timer_intterupt() to figure out if the tick of the cpu can be stopped or not. If it turns out that the next tick is just one jiffy off (delta_jiffies == 1) tick_nohz_stop_sched_tick() incorrectly assumes that the tick should not stop and takes an early exit and thus it won't update the load balancer cpu. Just afterwards the cpu will be killed and the load balancer cpu could be the offline cpu. On 2.6.32 based kernel get_nohz_load_balancer() gets called to decide on which cpu a timer should be enqueued (see __mod_timer()). Which leads to the possibility that timers get enqueued on an offline cpu. These will never expire and can cause a system hang. This has been observed 2.6.32 kernels. On current kernels __mod_timer() uses get_nohz_timer_target() which doesn't have that problem. However there might be other problems because of the too early exit tick_nohz_stop_sched_tick() in case a cpu goes offline. The easiest and probably safest fix seems to be to let get_next_timer_interrupt() just lie and let it say there isn't any pending timer if the current cpu is offline. I also thought of moving migrate_[hr]timers() from CPU_DEAD to CPU_DYING, but seeing that there already have been fixes at least in the hrtimer code in this area I'm afraid that this could add new subtle bugs. Signed-off-by: Heiko Carstens Signed-off-by: Peter Zijlstra LKML-Reference: <20101201091109.GA8984@osiris.boeblingen.de.ibm.com> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit fbf23913c63625504579db05abe6a2c2f3c7e66a Author: Heiko Carstens Date: Fri Nov 26 13:00:59 2010 +0100 nohz: Fix printk_needs_cpu() return value on offline cpus commit 61ab25447ad6334a74e32f60efb135a3467223f8 upstream. This patch fixes a hang observed with 2.6.32 kernels where timers got enqueued on offline cpus. printk_needs_cpu() may return 1 if called on offline cpus. When a cpu gets offlined it schedules the idle process which, before killing its own cpu, will call tick_nohz_stop_sched_tick(). That function in turn will call printk_needs_cpu() in order to check if the local tick can be disabled. On offline cpus this function should naturally return 0 since regardless if the tick gets disabled or not the cpu will be dead short after. That is besides the fact that __cpu_disable() should already have made sure that no interrupts on the offlined cpu will be delivered anyway. In this case it prevents tick_nohz_stop_sched_tick() to call select_nohz_load_balancer(). No idea if that really is a problem. However what made me debug this is that on 2.6.32 the function get_nohz_load_balancer() is used within __mod_timer() to select a cpu on which a timer gets enqueued. If printk_needs_cpu() returns 1 then the nohz_load_balancer cpu doesn't get updated when a cpu gets offlined. It may contain the cpu number of an offline cpu. In turn timers get enqueued on an offline cpu and not very surprisingly they never expire and cause system hangs. This has been observed 2.6.32 kernels. On current kernels __mod_timer() uses get_nohz_timer_target() which doesn't have that problem. However there might be other problems because of the too early exit tick_nohz_stop_sched_tick() in case a cpu goes offline. Easiest way to fix this is just to test if the current cpu is offline and call printk_tick() directly which clears the condition. Alternatively I tried a cpu hotplug notifier which would clear the condition, however between calling the notifier function and printk_needs_cpu() something could have called printk() again and the problem is back again. This seems to be the safest fix. Signed-off-by: Heiko Carstens Signed-off-by: Peter Zijlstra LKML-Reference: <20101126120235.406766476@de.ibm.com> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit a32672df11f51f7eef63df6aa8622926de957364 Author: Alex Deucher Date: Wed Dec 8 19:09:42 2010 -0500 drm/kms: remove spaces from connector names (v2) commit e76116ca9671e2e5239054a40303b94feab585ad upstream. Grub doesn't parse spaces in parameters correctly, so this makes it impossible to force video= parameters for kms on the grub kernel command line. v2: shorten the names to make them easier to type. Reported-by: Sergej Pupykin Cc: Sergej Pupykin Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Paul Gortmaker commit 4b21c4950e737b07d44f7e4b1a36fc273061dd28 Author: Daniel T Chen Date: Thu Dec 2 22:45:45 2010 -0500 ALSA: hda: Use model=lg quirk for LG P1 Express to enable playback and capture commit 77c4d5cdb81d25a45fbdfb84dd3348121219a072 upstream. BugLink: https://launchpad.net/bugs/595482 The original reporter states that audible playback from the internal speaker is inaudible despite the hardware being properly detected. To work around this symptom, he uses the model=lg quirk to properly enable both playback, capture, and jack sense. Another user corroborates this workaround on separate hardware. Add this PCI SSID to the quirk table to enable it for further LG P1 Expresses. Reported-and-tested-by: Philip Peitsch Tested-by: nikhov Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 957b2c8e401086e35c36b1265bb5beaa28cd7d26 Author: Miklos Szeredi Date: Tue Nov 30 16:39:27 2010 +0100 fuse: fix ioctl when server is 32bit commit d9d318d39dd5cb686660504a3565aac453709ccc upstream. If a 32bit CUSE server is run on 64bit this results in EIO being returned to the caller. The reason is that FUSE_IOCTL_RETRY reply was defined to use 'struct iovec', which is different on 32bit and 64bit archs. Work around this by looking at the size of the reply to determine which struct was used. This is only needed if CONFIG_COMPAT is defined. A more permanent fix for the interface will be to use the same struct on both 32bit and 64bit. Reported-by: "ccmail111" Signed-off-by: Miklos Szeredi CC: Tejun Heo Signed-off-by: Paul Gortmaker commit 25d2a723132370d2320784bb53ca87453ec40cca Author: Miklos Szeredi Date: Tue Nov 30 16:39:27 2010 +0100 fuse: verify ioctl retries commit 7572777eef78ebdee1ecb7c258c0ef94d35bad16 upstream. Verify that the total length of the iovec returned in FUSE_IOCTL_RETRY doesn't overflow iov_length(). Signed-off-by: Miklos Szeredi CC: Tejun Heo Signed-off-by: Paul Gortmaker commit ae30941bd05ecd8cf3719480ad7031f729d82735 Author: H. Peter Anvin Date: Mon Sep 20 13:04:45 2010 -0700 x86, hotplug: In the MWAIT case of play_dead, CLFLUSH the cache line commit ce5f68246bf2385d6174856708d0b746dc378f20 upstream. When we're using MWAIT for play_dead, explicitly CLFLUSH the cache line before executing MONITOR. This is a potential workaround for the Xeon 7400 erratum AAI65 after having a spurious wakeup and returning around the loop. "Potential" here because it is not certain that that erratum could actually trigger; however, the CLFLUSH should be harmless. Signed-off-by: H. Peter Anvin Acked-by: Venkatesh Pallipadi Cc: Asit Mallick Cc: Arjan van de Ven Cc: Len Brown Signed-off-by: Paul Gortmaker commit 1e2585671a2fcd5746fe4768c0a557fcfd4b2d8a Author: H. Peter Anvin Date: Fri Sep 17 17:06:46 2010 -0700 x86, hotplug: Move WBINVD back outside the play_dead loop commit a68e5c94f7d3dd64fef34dd5d97e365cae4bb42a upstream. On processors with hyperthreading, when only one thread is offlined the other thread can cause a spurious wakeup on the idled thread. We do not want to re-WBINVD when that happens. Ideally, we should simply skip WBINVD unless we're the last thread on a particular core to shut down, but there might be similar issues elsewhere in the system. Thus, revert to previous behavior of only WBINVD outside the loop. Partly as a result, remove the mb()'s around it: they are not necessary since wbinvd() is a serializing instruction, but they were intended to make sure the compiler didn't do any funny loop optimizations. Reported-by: Asit Mallick Signed-off-by: H. Peter Anvin Cc: Arjan van de Ven Cc: Len Brown Cc: Venkatesh Pallipadi Cc: Peter Zijlstra LKML-Reference: Signed-off-by: Paul Gortmaker commit b181d8a4ad837e7d73f17100f9e65e75ae14d1eb Author: H. Peter Anvin Date: Fri Sep 17 15:39:11 2010 -0700 x86, hotplug: Use mwait to offline a processor, fix the legacy case commit ea53069231f9317062910d6e772cca4ce93de8c8 upstream. The code in native_play_dead() has a number of problems: 1. We should use MWAIT when available, to put ourselves into a deeper sleep state. 2. We use the existence of CLFLUSH to determine if WBINVD is safe, but that is totally bogus -- WBINVD is 486+, whereas CLFLUSH is a much later addition. 3. We should do WBINVD inside the loop, just in case of something like setting an A bit on page tables. Pointed out by Arjan van de Ven. This code is based in part of a previous patch by Venki Pallipadi, but unlike that patch this one keeps all the detection code local instead of pre-caching a bunch of information. We're shutting down the CPU; there is absolutely no hurry. This patch moves all the code to C and deletes the global wbinvd_halt() which is broken anyway. Originally-by: Venkatesh Pallipadi Signed-off-by: H. Peter Anvin Reviewed-by: Arjan van de Ven Cc: Len Brown Cc: Venkatesh Pallipadi Cc: Peter Zijlstra LKML-Reference: <20090522232230.162239000@intel.com> Signed-off-by: Paul Gortmaker commit 2f3a80a5e10b4988875c45035ee203d7dcf2bddb Author: H. Peter Anvin Date: Fri Sep 17 15:36:40 2010 -0700 x86, mwait: Move mwait constants to a common header file commit bc83cccc761953f878088cdfa682de0970b5561f upstream. We have MWAIT constants spread across three different .c files, for no good reason. Move them all into a common header file. [PG: required for cherry pick of ce5f68246b - to avoid dup. mwait fields in smpboot.c; drop intel_idle.c chunk, as 34 doesnt have it] Signed-off-by: H. Peter Anvin Reviewed-by: Arjan van de Ven Cc: Len Brown LKML-Reference: Signed-off-by: Paul Gortmaker commit e021335d8200fc22bde145d192fdcb04467f2d65 Author: Apollon Oikonomopoulos Date: Tue Dec 7 09:43:30 2010 +0000 x25: decrement netdev reference counts on unload commit 171995e5d82dcc92bea37a7d2a2ecc21068a0f19 upstream x25 does not decrement the network device reference counts on module unload. Thus unregistering any pre-existing interface after unloading the x25 module hangs and results in unregister_netdevice: waiting for tap0 to become free. Usage count = 1 This patch decrements the reference counts of all interfaces in x25_link_free, the way it is already done in x25_link_device_down for NETDEV_DOWN events. Signed-off-by: Apollon Oikonomopoulos Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit e2d5d2b57b92b386e4867d575c20f9fdc16bcbbc Author: Changli Gao Date: Sat Dec 4 14:09:08 2010 +0000 ifb: goto resched directly if error happens and dp->tq isn't empty commit 75c1c82566f23dd539fb7ccbf57a1caa7ba82628 upstream If we break the loop when there are still skbs in tq and no skb in rq, the skbs will be left in txq until new skbs are enqueued into rq. In rare cases, no new skb is queued, then these skbs will stay in rq forever. After this patch, if tq isn't empty when we break the loop, we goto resched directly. Signed-off-by: Changli Gao Signed-off-by: Jamal Hadi Salim Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 7742df2151c0a78b58f710bbbc2de61616821dd6 Author: David S. Miller Date: Wed Dec 8 18:42:23 2010 -0800 econet: Fix crash in aun_incoming(). commit 4e085e76cbe558b79b54cbab772f61185879bc64 upstream Unconditional use of skb->dev won't work here, try to fetch the econet device via skb_dst()->dev instead. Suggested by Eric Dumazet. Reported-by: Nelson Elhage Tested-by: Nelson Elhage Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit d4fb962614d39a25d88d99b8090ef6c15b23fa90 Author: Nelson Elhage Date: Wed Dec 8 10:13:55 2010 -0800 econet: Do the correct cleanup after an unprivileged SIOCSIFADDR. commit 0c62fc6dd02c8d793c75ae76a9b6881fc36388ad upstream We need to drop the mutex and do a dev_put, so set an error code and break like the other paths, instead of returning directly. Signed-off-by: Nelson Elhage Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit d89f6fc68da8ca411226e24d762826f0fff99007 Author: Eric Dumazet Date: Mon Dec 6 09:29:43 2010 -0800 filter: fix sk_filter rcu handling commit 46bcf14f44d8f31ecfdc8b6708ec15a3b33316d9 upstream Pavel Emelyanov tried to fix a race between sk_filter_(de|at)tach and sk_clone() in commit 47e958eac280c263397 Problem is we can have several clones sharing a common sk_filter, and these clones might want to sk_filter_attach() their own filters at the same time, and can overwrite old_filter->rcu, corrupting RCU queues. We can not use filter->rcu without being sure no other thread could do the same thing. Switch code to a more conventional ref-counting technique : Do the atomic decrement immediately and queue one rcu call back when last reference is released. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit a17efe35c72c510d8acf4da81aa5e2233b860281 Author: Hillf Danton Date: Fri Dec 10 18:54:11 2010 +0000 bonding: Fix slave selection bug. commit af3e5bd5f650163c2e12297f572910a1af1b8236 upstream The returned slave is incorrect, if the net device under check is not charged yet by the master. Signed-off-by: Hillf Danton Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 4beaa7e56f75121da2acd9bbc3b9b115db0323d5 Author: Joe Jin Date: Mon Dec 6 03:00:59 2010 +0000 driver/net/benet: fix be_cmd_multicast_set() memcpy bug commit 408cc293c29ada769ae772420a39961320da1854 upstream Regarding benet be_cmd_multicast_set() function, now using netdev_for_each_mc_addr() helper for mac address copy, but when copying to req->mac[] did not increase of the index. Cc: Sathya Perla Cc: Subbu Seetharaman Cc: Sarveshwar Bandi Cc: Ajit Khaparde Signed-off-by: Joe Jin Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 9812927a368cf5e7be0d060405ad45a17922db05 Author: Vasiliy Kulikov Date: Wed Nov 10 12:09:10 2010 -0800 net: packet: fix information leak to userland commit 67286640f638f5ad41a946b9a3dc75327950248f upstream packet_getname_spkt() doesn't initialize all members of sa_data field of sockaddr struct if strlen(dev->name) < 13. This structure is then copied to userland. It leads to leaking of contents of kernel stack memory. We have to fully fill sa_data with strncpy() instead of strlcpy(). The same with packet_getname(): it doesn't initialize sll_pkttype field of sockaddr_ll. Set it to zero. Signed-off-by: Vasiliy Kulikov Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit b900981f8676c3c7081fb4df0114eceecdfb5960 Author: Eric Dumazet Date: Thu Nov 25 04:11:39 2010 +0000 af_unix: limit recursion level commit 25888e30319f8896fc656fc68643e6a078263060 upstream Its easy to eat all kernel memory and trigger NMI watchdog, using an exploit program that queues unix sockets on top of others. lkml ref : http://lkml.org/lkml/2010/11/25/8 This mechanism is used in applications, one choice we have is to have a recursion limit. Other limits might be needed as well (if we queue other types of files), since the passfd mechanism is currently limited by socket receive queue sizes only. Add a recursion_level to unix socket, allowing up to 4 levels. Each time we send an unix socket through sendfd mechanism, we copy its recursion level (plus one) to receiver. This recursion level is cleared when socket receive queue is emptied. [PG: slight modifications required due to absense of 7361c36c5 in 34] Reported-by: Марк Коренберг Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit b6f39362df3880841fde0efc345a4f15fcbf9200 Author: Eric Dumazet Date: Wed Nov 24 09:15:27 2010 -0800 af_unix: limit unix_tot_inflight commit 9915672d41273f5b77f1b3c29b391ffb7732b84b upstream Vegard Nossum found a unix socket OOM was possible, posting an exploit program. My analysis is we can eat all LOWMEM memory before unix_gc() being called from unix_release_sock(). Moreover, the thread blocked in unix_gc() can consume huge amount of time to perform cleanup because of huge working set. One way to handle this is to have a sensible limit on unix_tot_inflight, tested from wait_for_unix_gc() and to force a call to unix_gc() if this limit is hit. This solves the OOM and also reduce overall latencies, and should not slowdown normal workloads. Reported-by: Vegard Nossum Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 5a37b428f0f71ab5554a639fba7bf9b6e2fb56e1 Author: Eric Dumazet Date: Tue Dec 7 12:03:55 2010 +0000 tcp: avoid a possible divide by zero commit ad9f4f50fe9288bbe65b7dfd76d8820afac6a24c upstream sysctl_tcp_tso_win_divisor might be set to zero while one cpu runs in tcp_tso_should_defer(). Make sure we dont allow a divide by zero by reading sysctl_tcp_tso_win_divisor exactly once. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 9436887e4dd873e46337048a48d17aa413cfc83a Author: Nandita Dukkipati Date: Fri Dec 3 13:33:44 2010 +0000 tcp: Bug fix in initialization of receive window. commit b1afde60f2b9ee8444fba4e012dc99a3b28d224d upstream The bug has to do with boundary checks on the initial receive window. If the initial receive window falls between init_cwnd and the receive window specified by the user, the initial window is incorrectly brought down to init_cwnd. The correct behavior is to allow it to remain unchanged. Signed-off-by: Nandita Dukkipati Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 8b95a0a46853086fad423fc1ede3c81b28f90000 Author: David S. Miller Date: Wed Nov 24 11:47:22 2010 -0800 tcp: Make TCP_MAXSEG minimum more correct. commit c39508d6f118308355468314ff414644115a07f3 upstream Use TCP_MIN_MSS instead of constant 64. Reported-by: Min Zhang Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 1315b700e593535a1a5ede8ea77859a155c0a3b2 Author: David S. Miller Date: Wed Nov 10 21:35:37 2010 -0800 tcp: Increase TCP_MAXSEG socket option minimum. commit 7a1abd08d52fdeddb3e9a5a33f2f15cc6a5674d2 upstream As noted by Steve Chen, since commit f5fff5dc8a7a3f395b0525c02ba92c95d42b7390 ("tcp: advertise MSS requested by user") we can end up with a situation where tcp_select_initial_window() does a divide by a zero (or even negative) mss value. The problem is that sometimes we effectively subtract TCPOLEN_TSTAMP_ALIGNED and/or TCPOLEN_MD5SIG_ALIGNED from the mss. Fix this by increasing the minimum from 8 to 64. Reported-by: Steve Chen Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 7be07193f5663cd1a4657062c47c07282fbc3f3b Author: David S. Miller Date: Fri Nov 12 13:35:00 2010 -0800 tcp: Don't change unlocked socket state in tcp_v4_err(). commit 8f49c2703b33519aaaccc63f571b465b9d2b3a2d upstream Alexey Kuznetsov noticed a regression introduced by commit f1ecd5d9e7366609d640ff4040304ea197fbc618 ("Revert Backoff [v3]: Revert RTO on ICMP destination unreachable") The RTO and timer modification code added to tcp_v4_err() doesn't check sock_owned_by_user(), which if true means we don't have exclusive access to the socket and therefore cannot modify it's critical state. Just skip this new code block if sock_owned_by_user() is true and eliminate the now superfluous sock_owned_by_user() code block contained within. Reported-by: Alexey Kuznetsov Signed-off-by: David S. Miller CC: Damian Lukowski Acked-by: Eric Dumazet Signed-off-by: Paul Gortmaker commit 0130382485c1330f40a8f5090f1ea70c6baa20e6 Author: Oleg Nesterov Date: Thu Apr 14 20:19:36 2011 +0200 exec: make argv/envp memory visible to oom-killer commit 3c77f845722158206a7209c45ccddc264d19319c upstream. Brad Spengler published a local memory-allocation DoS that evades the OOM-killer (though not the virtual memory RLIMIT): http://www.grsecurity.net/~spender/64bit_dos.c execve()->copy_strings() can allocate a lot of memory, but this is not visible to oom-killer, nobody can see the nascent bprm->mm and take it into account. With this patch get_arg_page() increments current's MM_ANONPAGES counter every time we allocate the new page for argv/envp. When do_execve() succeds or fails, we change this counter back. Technically this is not 100% correct, we can't know if the new page is swapped out and turn MM_ANONPAGES into MM_SWAPENTS, but I don't think this really matters and everything becomes correct once exec changes ->mm or fails. Compared to upstream: before 2.6.36 kernel, oom-killer's badness() takes mm->total_vm into account and nothing else. So acct_arg_size() has to play with this counter too. Reported-by: Brad Spengler Reviewed-and-discussed-by: KOSAKI Motohiro Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 9e7e10466fee07044f7357055eb203642647ec39 Author: David S. Miller Date: Wed Nov 10 10:38:24 2010 -0800 filter: make sure filters dont read uninitialized memory commit 57fe93b374a6b8711995c2d466c502af9f3a08bb upstream There is a possibility malicious users can get limited information about uninitialized stack mem array. Even if sk_run_filter() result is bound to packet length (0 .. 65535), we could imagine this can be used by hostile user. Initializing mem[] array, like Dan Rosenberg suggested in his patch is expensive since most filters dont even use this array. Its hard to make the filter validation in sk_chk_filter(), because of the jumps. This might be done later. In this patch, I use a bitmap (a single long var) so that only filters using mem[] loads/stores pay the price of added security checks. For other filters, additional cost is a single instruction. [ Since we access fentry->k a lot now, cache it in a local variable and mark filter entry pointer as const. -DaveM ] Reported-by: Dan Rosenberg Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 3bdf85c28cb158e4369145edf9893e29f3f256b0 Author: Dave Jones Date: Sat Nov 13 00:58:54 2010 -0500 ACPI: debugfs custom_method open to non-root commit ed3aada1bf34c5a9e98af167f125f8a740fc726a upstream Currently we have: --w--w--w-. 1 root root 0 2010-11-11 14:56 /sys/kernel/debug/acpi/custom_method which is just crazy. Change this to --w-------. [PG: back in 2.6.34, the file was called debug.c, not debugfs.c] Signed-off-by: Dave Jones Signed-off-by: Len Brown Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 41823d702430b1bdd671b55699b0d4bab806b4af Author: Phil Blundell Date: Wed Nov 24 11:51:47 2010 -0800 econet: fix CVE-2010-3848 commit a27e13d370415add3487949c60810e36069a23a6 upstream Don't declare variable sized array of iovecs on the stack since this could cause stack overflow if msg->msgiovlen is large. Instead, coalesce the user-supplied data into a new buffer and use a single iovec for it. Signed-off-by: Phil Blundell Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit c076522aa8a8ab5d20994a8b71749c40c623ad2e Author: Jiri Slaby Date: Mon Nov 29 10:16:53 2010 +0100 TTY: don't allow reopen when ldisc is changing commit e2efafbf139d2bfdfe96f2901f03189fecd172e4 upstream There are many WARNINGs like the following reported nowadays: WARNING: at drivers/tty/tty_io.c:1331 tty_open+0x2a2/0x49a() Hardware name: Latitude E6500 Modules linked in: Pid: 1207, comm: plymouthd Not tainted 2.6.37-rc3-mmotm1123 #3 Call Trace: [] warn_slowpath_common+0x80/0x98 [] warn_slowpath_null+0x15/0x17 [] tty_open+0x2a2/0x49a [] chrdev_open+0x11d/0x146 ... This means tty_reopen is called without TTY_LDISC set. For further considerations, note tty_lock is held in tty_open. TTY_LDISC is cleared in: 1) __tty_hangup from tty_ldisc_hangup to tty_ldisc_enable. During this section tty_lock is held. However tty_lock is temporarily dropped in the middle of the function by tty_ldisc_hangup. 2) tty_release via tty_ldisc_release till the end of tty existence. If tty->count <= 1, tty_lock is taken, TTY_CLOSING bit set and then tty_ldisc_release called. tty_reopen checks TTY_CLOSING before checking TTY_LDISC. 3) tty_set_ldisc from tty_ldisc_halt to tty_ldisc_enable. We: * take tty_lock, set TTY_LDISC_CHANGING, put tty_lock * call tty_ldisc_halt (clear TTY_LDISC), tty_lock is _not_ held * do some other work * take tty_lock, call tty_ldisc_enable (set TTY_LDISC), put tty_lock I cannot see how 2) can be a problem, as there I see no race. OTOH, 1) and 3) can happen without problems. This patch the case 3) by checking TTY_LDISC_CHANGING along with TTY_CLOSING in tty_reopen. 1) will be fixed in the following patch. Nicely reproducible with two processes: while (1) { fd = open("/dev/ttyS1", O_RDWR); if (fd < 0) { warn("open"); continue; } close(fd); } -------- while (1) { fd = open("/dev/ttyS1", O_RDWR); ld1 = 0; ld2 = 2; while (1) { ioctl(fd, TIOCSETD, &ld1); ioctl(fd, TIOCSETD, &ld2); } close(fd); } Signed-off-by: Jiri Slaby Reported-by: Cc: Kyle McMartin Cc: Alan Cox Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 42dcdc4ac56d745136a4a89b29f2c7a540fcd92a Author: Dan Rosenberg Date: Mon Sep 27 12:30:28 2010 -0400 Fix pktcdvd ioctl dev_minor range check commit 252a52aa4fa22a668f019e55b3aac3ff71ec1c29 upstream The PKT_CTRL_CMD_STATUS device ioctl retrieves a pointer to a pktcdvd_device from the global pkt_devs array. The index into this array is provided directly by the user and is a signed integer, so the comparison to ensure that it falls within the bounds of this array will fail when provided with a negative index. This can be used to read arbitrary kernel memory or cause a crash due to an invalid pointer dereference. This can be exploited by users with permission to open /dev/pktcdvd/control (on many distributions, this is readable by group "cdrom"). Signed-off-by: Dan Rosenberg [ Rather than add a cast, just make the function take the right type -Linus ] Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit fcbd591a63a37b0ba0144509a44a78a0078e4661 Author: Eric Dumazet Date: Mon Aug 16 20:04:22 2010 +0000 net sched: fix some kernel memory leaks commit 1c40be12f7d8ca1d387510d39787b12e512a7ce8 upstream. We leak at least 32bits of kernel memory to user land in tc dump, because we dont init all fields (capab ?) of the dumped structure. Use C99 initializers so that holes and non explicit fields are zeroed. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 49cb80e6c90e171d0e80666cba269d3d96bb7ace Author: Changli Gao Date: Tue Jun 29 23:07:09 2010 +0000 act_nat: use stack variable commit 504f85c9d05f7c605306e808f0d835fe11bfd18d upstream. act_nat: use stack variable structure tc_nat isn't too big for stack, so we can put it in stack. Signed-off-by: Changli Gao Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 0621058e58daed18f169c1cc1cd4306cf39b4fff Author: Heiko Carstens Date: Thu Nov 25 09:52:45 2010 +0100 nmi: fix clock comparator revalidation commit e8129c642155616d9e2160a75f103e127c8c3708 upstream. On each machine check all registers are revalidated. The save area for the clock comparator however only contains the upper most seven bytes of the former contents, if valid. Therefore the machine check handler uses a store clock instruction to get the current time and writes that to the clock comparator register which in turn will generate an immediate timer interrupt. However within the lowcore the expected time of the next timer interrupt is stored. If the interrupt happens before that time the handler won't be called. In turn the clock comparator won't be reprogrammed and therefore the interrupt condition stays pending which causes an interrupt loop until the expected time is reached. On NOHZ machines this can result in unresponsive machines since the time of the next expected interrupted can be a couple of days in the future. To fix this just revalidate the clock comparator register with the expected value. In addition the special handling for udelay must be changed as well. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Paul Gortmaker commit d3b379e224e2218c815c5ad3da9a6f8f108bbd0c Author: David S. Miller Date: Thu Oct 28 11:41:55 2010 -0700 net: Limit socket I/O iovec total length to INT_MAX. commit 8acfe468b0384e834a303f08ebc4953d72fb690a upstream. This helps protect us from overflow issues down in the individual protocol sendmsg/recvmsg handlers. Once we hit INT_MAX we truncate out the rest of the iovec by setting the iov_len members to zero. This works because: 1) For SOCK_STREAM and SOCK_SEQPACKET sockets, partial writes are allowed and the application will just continue with another write to send the rest of the data. 2) For datagram oriented sockets, where there must be a one-to-one correspondance between write() calls and packets on the wire, INT_MAX is going to be far larger than the packet size limit the protocol is going to check for and signal with -EMSGSIZE. Based upon a patch by Linus Torvalds. Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 9f1dd99a0eb80d2c1e93682c766bcddbdf42f30f Author: Linus Torvalds Date: Sat Oct 30 16:43:10 2010 -0700 net: Truncate recvfrom and sendto length to INT_MAX. commit 253eacc070b114c2ec1f81b067d2fed7305467b0 upstream. Signed-off-by: Linus Torvalds Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 97d39ebaca2fd0c694b9695daef218b9c1af5971 Author: Dan Rosenberg Date: Wed Nov 17 06:37:16 2010 +0000 rds: Integer overflow in RDS cmsg handling commit 218854af84038d828a32f061858b1902ed2beec6 upstream. In rds_cmsg_rdma_args(), the user-provided args->nr_local value is restricted to less than UINT_MAX. This seems to need a tighter upper bound, since the calculation of total iov_size can overflow, resulting in a small sock_kmalloc() allocation. This would probably just result in walking off the heap and crashing when calling rds_rdma_pages() with a high count value. If it somehow doesn't crash here, then memory corruption could occur soon after. Signed-off-by: Dan Rosenberg Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 623da35398c12085a237fc985613c7fe2b0a5a1a Author: Phil Blundell Date: Wed Nov 24 11:49:53 2010 -0800 econet: fix CVE-2010-3850 commit 16c41745c7b92a243d0874f534c1655196c64b74 upstream. Add missing check for capable(CAP_NET_ADMIN) in SIOCSIFADDR operation. Signed-off-by: Phil Blundell Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 4b26a9cc1ed74cb87c24830de097aebb08234b81 Author: Phil Blundell Date: Wed Nov 24 11:49:19 2010 -0800 econet: disallow NULL remote addr for sendmsg(), fixes CVE-2010-3849 commit fa0e846494792e722d817b9d3d625a4ef4896c96 upstream. Later parts of econet_sendmsg() rely on saddr != NULL, so return early with EINVAL if NULL was passed otherwise an oops may occur. Signed-off-by: Phil Blundell Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit fd28362adbeb2681b01d3d4268689344dcd9dceb Author: H. Peter Anvin Date: Wed Aug 18 11:42:23 2010 -0700 x86-32: Fix dummy trampoline-related inline stubs commit 8848a91068c018bc91f597038a0f41462a0f88a4 upstream. Fix dummy inline stubs for trampoline-related functions when no trampolines exist (until we get rid of the no-trampoline case entirely.) Signed-off-by: H. Peter Anvin Cc: Joerg Roedel Cc: Borislav Petkov LKML-Reference: <4C6C294D.3030404@zytor.com> Signed-off-by: Paul Gortmaker commit f377cfb2ca75d76246b57fcd34375d27af88667e Author: Hugh Dickins Date: Tue Aug 24 22:44:12 2010 -0700 x86, mm: Fix CONFIG_VMSPLIT_1G and 2G_OPT trampoline commit b7d460897739e02f186425b7276e3fdb1595cea7 upstream. rc2 kernel crashes when booting second cpu on this CONFIG_VMSPLIT_2G_OPT laptop: whereas cloning from kernel to low mappings pgd range does need to limit by both KERNEL_PGD_PTRS and KERNEL_PGD_BOUNDARY, cloning kernel pgd range itself must not be limited by the smaller KERNEL_PGD_BOUNDARY. Signed-off-by: Hugh Dickins LKML-Reference: Signed-off-by: H. Peter Anvin Signed-off-by: Paul Gortmaker commit 2f7c1a711119518a21feb2d077c8015e9f32875d Author: Joerg Roedel Date: Mon Aug 16 14:38:33 2010 +0200 x86-32: Separate 1:1 pagetables from swapper_pg_dir commit fd89a137924e0710078c3ae855e7cec1c43cb845 upstream. This patch fixes machine crashes which occur when heavily exercising the CPU hotplug codepaths on a 32-bit kernel. These crashes are caused by AMD Erratum 383 and result in a fatal machine check exception. Here's the scenario: 1. On 32-bit, the swapper_pg_dir page table is used as the initial page table for booting a secondary CPU. 2. To make this work, swapper_pg_dir needs a direct mapping of physical memory in it (the low mappings). By adding those low, large page (2M) mappings (PAE kernel), we create the necessary conditions for Erratum 383 to occur. 3. Other CPUs which do not participate in the off- and onlining game may use swapper_pg_dir while the low mappings are present (when leave_mm is called). For all steps below, the CPU referred to is a CPU that is using swapper_pg_dir, and not the CPU which is being onlined. 4. The presence of the low mappings in swapper_pg_dir can result in TLB entries for addresses below __PAGE_OFFSET to be established speculatively. These TLB entries are marked global and large. 5. When the CPU with such TLB entry switches to another page table, this TLB entry remains because it is global. 6. The process then generates an access to an address covered by the above TLB entry but there is a permission mismatch - the TLB entry covers a large global page not accessible to userspace. 7. Due to this permission mismatch a new 4kb, user TLB entry gets established. Further, Erratum 383 provides for a small window of time where both TLB entries are present. This results in an uncorrectable machine check exception signalling a TLB multimatch which panics the machine. There are two ways to fix this issue: 1. Always do a global TLB flush when a new cr3 is loaded and the old page table was swapper_pg_dir. I consider this a hack hard to understand and with performance implications 2. Do not use swapper_pg_dir to boot secondary CPUs like 64-bit does. This patch implements solution 2. It introduces a trampoline_pg_dir which has the same layout as swapper_pg_dir with low_mappings. This page table is used as the initial page table of the booting CPU. Later in the bringup process, it switches to swapper_pg_dir and does a global TLB flush. This fixes the crashes in our test cases. -v2: switch to swapper_pg_dir right after entering start_secondary() so that we are able to access percpu data which might not be mapped in the trampoline page table. Signed-off-by: Joerg Roedel LKML-Reference: <20100816123833.GB28147@aftab> Signed-off-by: Borislav Petkov Signed-off-by: H. Peter Anvin Signed-off-by: Paul Gortmaker commit fa4385dfdcfb30aa2a93ea35d68979d2c78d7e5f Author: Herbert Xu Date: Thu Nov 4 14:38:39 2010 -0400 crypto: padlock - Fix AES-CBC handling on odd-block-sized input commit c054a076a1bd4731820a9c4d638b13d5c9bf5935 upstream. On certain VIA chipsets AES-CBC requires the input/output to be a multiple of 64 bytes. We had a workaround for this but it was buggy as it sent the whole input for processing when it is meant to only send the initial number of blocks which makes the rest a multiple of 64 bytes. As expected this causes memory corruption whenever the workaround kicks in. Reported-by: Phil Sutter Signed-off-by: Herbert Xu Signed-off-by: Paul Gortmaker commit 2333ff6098f465c9a8a23af44b53bcc45aa90bf6 Author: Dan Rosenberg Date: Fri Nov 12 12:44:42 2010 -0800 x25: Prevent crashing when parsing bad X.25 facilities commit 5ef41308f94dcbb3b7afc56cdef1c2ba53fa5d2f upstream. Now with improved comma support. On parsing malformed X.25 facilities, decrementing the remaining length may cause it to underflow. Since the length is an unsigned integer, this will result in the loop continuing until the kernel crashes. This patch adds checks to ensure decrementing the remaining length does not cause it to wrap around. Signed-off-by: Dan Rosenberg Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit ce174c35c6ca467935bc7048a546ae4bcc5c6de3 Author: Dan Rosenberg Date: Wed Sep 15 18:44:22 2010 -0300 V4L/DVB: ivtvfb: prevent reading uninitialized stack memory commit 405707985594169cfd0b1d97d29fcb4b4c6f2ac9 upstream. The FBIOGET_VBLANK device ioctl allows unprivileged users to read 16 bytes of uninitialized stack memory, because the "reserved" member of the fb_vblank struct declared on the stack is not altered or zeroed before being copied back to the user. This patch takes care of it. Signed-off-by: Dan Rosenberg Signed-off-by: Andy Walls Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Paul Gortmaker commit e226660a5b5ec4831d128e229272872085d1bd6a Author: Oliver Hartkopp Date: Wed Nov 10 12:10:30 2010 +0000 can-bcm: fix minor heap overflow commit 0597d1b99fcfc2c0eada09a698f85ed413d4ba84 upstream. On 64-bit platforms the ASCII representation of a pointer may be up to 17 bytes long. This patch increases the length of the buffer accordingly. http://marc.info/?l=linux-netdev&m=128872251418192&w=2 Reported-by: Dan Rosenberg Signed-off-by: Oliver Hartkopp CC: Linus Torvalds Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 5b388f9cf72176888b5a17064177876c4651c814 Author: andrew hendry Date: Wed Nov 3 12:54:53 2010 +0000 memory corruption in X.25 facilities parsing commit a6331d6f9a4298173b413cf99a40cc86a9d92c37 upstream. Signed-of-by: Andrew Hendry Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 938507f1938e3e5f36488772498f866343882e6f Author: Dmitry Torokhov Date: Thu Nov 4 09:12:44 2010 -0700 Input: i8042 - add Sony VAIO VPCZ122GX to nomux list [Note that the mainline will not have this particular fix but rather will blacklist entire VAIO line based off DMI board name. For stable I am being a bit more cautious and blacklist one particular product.] Trying to query/activate active multiplexing mode on this VAIO makes both keyboard and touchpad inoperable. Futher kernels will blacklist entire VAIO line, however here we blacklist just one particular model. [PG: mainline commit for blacklist is 73b14484fb686252aaf4aac4fa65b4] Reported-by: Jesse Barnes Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit aafde09f5b1e7bed6084dd590a544fbf0d360b88 Author: Luke Macken Date: Wed Sep 22 13:05:04 2010 -0700 efifb: support the EFI framebuffer on more Apple hardware commit a5757c2a474a15f87e5baa9a4caacc31cde2bae6 upstream. Enable the EFI framebuffer on 14 more Macs, including the iMac11,1 iMac10,1 iMac8,1 Macmini3,1 Macmini4,1 MacBook5,1 MacBook6,1 MacBook7,1 MacBookPro2,2 MacBookPro5,2 MacBookPro5,3 MacBookPro6,1 MacBookPro6,2 and MacBookPro7,1 Information gathered from various user submissions. https://bugzilla.redhat.com/show_bug.cgi?id=528232 http://ubuntuforums.org/showthread.php?t=1557326 [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Luke Macken Signed-off-by: Peter Jones Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 6868d427a8b9de316d824033559213c946e403fb Author: Jack Steiner Date: Fri Sep 10 10:08:08 2010 -0500 x86, UV: Fix initialization of max_pnode commit 36ac4b987bea9a95217e1af552252f275ca7fc44 upstream. Fix calculation of "max_pnode" for systems where the the highest blade has neither cpus or memory. (And, yes, although rare this does occur). Signed-off-by: Jack Steiner LKML-Reference: <20100910150808.GA19802@sgi.com> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit 56e79d65d610565fe9cbb113f11c0850b85e7455 Author: Jack Steiner Date: Wed Mar 17 10:40:38 2010 -0500 x86, UV: Delete unneeded boot messages commit 2acebe9ecb2b77876e87a1480729cfb2db4570dd upstream. SGI:UV: Delete extra boot messages that describe the system topology. These messages are no longer useful. Signed-off-by: Jack Steiner LKML-Reference: <20100317154038.GA29346@sgi.com> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit bf582727bbe00adccddd88395e4ed1d798a400e4 Author: David S. Miller Date: Tue Sep 21 22:30:13 2010 -0700 sparc: Prevent no-handler signal syscall restart recursion. commit c27852597829128a9c9d96d79ec454a83c6b0da5 upstream. Explicitly clear the "in-syscall" bit when we have no signal handler and back up the program counters to back up the system call. Reported-by: Al Viro Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit f718b62da4cc813188a96bb93710ccc7db992f74 Author: David S. Miller Date: Tue Sep 21 21:41:12 2010 -0700 sparc: Don't mask signal when we can't setup signal frame. commit 392c21802ee3aa85cee0e703105f797a8a7b9416 upstream. Don't invoke the signal handler tracehook in that situation either. Reported-by: Al Viro Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit c8fb04190f52f4b1f8b7bd790f03bb084e5df963 Author: David S. Miller Date: Mon Sep 20 23:24:52 2010 -0700 sparc64: Fix race in signal instruction flushing. commit 05c5e7698bdc54b3079a3517d86077f49ebcc788 upstream. If another cpu does a very wide munmap() on the signal frame area, it can tear down the page table hierarchy from underneath us. Borrow an idea from the 64-bit fault path's get_user_insn(), and disable cross call interrupts during the page table traversal to lock them in place while we operate. Reported-by: Al Viro Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 9b8796a9ce81ddc365946858d85a7656e66b0e59 Author: Eric Dumazet Date: Thu Oct 7 12:59:29 2010 -0700 sysctl: fix min/max handling in __do_proc_doulongvec_minmax() commit 27b3d80a7b6adcf069b5e869e4efcc3a79f88a91 upstream. When proc_doulongvec_minmax() is used with an array of longs, and no min/max check requested (.extra1 or .extra2 being NULL), we dereference a NULL pointer for the second element of the array. Noticed while doing some changes in network stack for the "16TB problem" Fix is to not change min & max pointers in __do_proc_doulongvec_minmax(), so that all elements of the vector share an unique min/max limit, like proc_dointvec_minmax(). [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Eric Dumazet Cc: "Eric W. Biederman" Cc: Americo Wang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit ba6929c72ac7d900504d9c355b2e84fe27533198 Author: Eric Dumazet Date: Fri Oct 15 14:34:12 2010 -0700 sysctl: min/max bounds are optional commit a9febbb4bd1302b6f01aa1203b0a804e4e5c9e25 upstream sysctl check complains with a WARN() when proc_doulongvec_minmax() or proc_doulongvec_ms_jiffies_minmax() are used by a vector of longs (with more than one element), with no min or max value specified. This is unexpected, given we had a bug on this min/max handling :) Reported-by: Jiri Slaby Signed-off-by: Eric Dumazet Cc: "Eric W. Biederman" Cc: David Miller Acked-by: WANG Cong Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 50b4a7338439c0ded1c6fbce328a2c24e673b590 Author: Eric Dumazet Date: Tue Nov 9 23:24:26 2010 +0000 net: avoid limits overflow commit 8d987e5c75107ca7515fa19e857cfa24aab6ec8f upstream. Robin Holt tried to boot a 16TB machine and found some limits were reached : sysctl_tcp_mem[2], sysctl_udp_mem[2] We can switch infrastructure to use long "instead" of "int", now atomic_long_t primitives are available for free. Signed-off-by: Eric Dumazet Reported-by: Robin Holt Reviewed-by: Robin Holt Signed-off-by: Andrew Morton Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 53565f12d7d9a0e5a56eade6d4df7d6fa77ffe3f Author: Jarek Poplawski Date: Tue Oct 19 00:06:36 2010 +0000 gianfar: Fix crashes on RX path (Was Re: [Bugme-new] [Bug 19692] New: linux-2.6.36-rc5 crash with gianfar ethernet at full line rate traffic) commit cd0ea2419544cfc4ccbf8ee0087d0d9f109852d2 upstream. The rx_recycle queue is global per device but can be accesed by many napi handlers at the same time, so it needs full skb_queue primitives (with locking). Otherwise, various crashes caused by broken skbs are possible. This patch resolves, at least partly, bugzilla bug 19692. (Because of some doubts that there could be still something around which is hard to reproduce my proposal is to leave this bug opened for a month.) Fixes commit: 0fd56bb5be6455d0d42241e65aed057244665e5e ("gianfar: Add support for skb recycling") Reported-by: emin ak Tested-by: emin ak Signed-off-by: Jarek Poplawski CC: Andy Fleming Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 6a52e23cf94bcc21b7834f966ddd2b0323cdb9b6 Author: Antonio Ospite Date: Tue Oct 5 17:20:17 2010 +0200 HID: hidraw, fix a NULL pointer dereference in hidraw_write commit e42dee9a99a3ecd32b5c027e8f7411fb5bc11eb6 upstream. BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 IP: [] hidraw_write+0x3b/0x116 [hid] [...] This is reproducible by disconnecting the device while userspace writes to dev node in a loop and doesn't check return values in order to exit the loop. [PG: slightly/trivially reworked for backport to 34] Signed-off-by: Antonio Ospite Signed-off-by: Jiri Kosina Signed-off-by: Paul Gortmaker commit 24977195f50960222eb9ad2982e6cd252ff9f63f Author: Antonio Ospite Date: Tue Oct 5 17:20:16 2010 +0200 HID: hidraw, fix a NULL pointer dereference in hidraw_ioctl commit d20d5ffab92f00188f360c44c791a5ffb988247c upstream. BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 IP: [] hidraw_ioctl+0xfc/0x32c [hid] [...] This is reproducible by disconnecting the device while userspace does ioctl in a loop and doesn't check return values in order to exit the loop. [PG: slightly/trivially reworked for backport to 34] Signed-off-by: Antonio Ospite Signed-off-by: Jiri Kosina Signed-off-by: Paul Gortmaker commit 0ab884d56d480246b098925c2e2586612822610c Author: Jeff Mahoney Date: Tue Aug 31 13:21:42 2010 +0000 net sched: fix kernel leak in act_police commit 0f04cfd098fb81fded74e78ea1a1b86cc6c6c31e upstream. While reviewing commit 1c40be12f7d8ca1d387510d39787b12e512a7ce8, I audited other users of tc_action_ops->dump for information leaks. That commit covered almost all of them but act_police still had a leak. opt.limit and opt.capab aren't zeroed out before the structure is passed out. This patch uses the C99 initializers to zero everything unused out. Signed-off-by: Jeff Mahoney Acked-by: Jeff Mahoney Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit fbdb37fe888f26f6ed6684a8c604f9e03a5f8836 Author: Larry Finger Date: Sat Nov 13 13:01:56 2010 -0600 staging: rtl8187se: Change panic to warn when RF switch turned off commit f36d83a8cb7224f45fdfa1129a616dff56479a09 upstream. This driver issues a kernel panic over conditions that do not justify such drastic action. Change these to log entries with a stack dump. This patch fixes the system crash reported in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674285. Signed-off-by: Larry Finger Reported-and-Tested-by: Robie Basik Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit ee7e6d00b8c287434465491d6a9f913ec9683885 Author: Greg Kroah-Hartman Date: Thu Nov 18 11:21:04 2010 -0800 Staging: frontier: fix up my fixup for some sysfs attribute permissions commit 2a767fda5d0d8dcff465724dfad6ee131489b3f2 upstream. They should be writable by root, not readable. Doh, stupid me with the wrong flags. Reported-by: Jonathan Cameron Cc: David Taht Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit d17382393cf88f5cd1c85c7f95795a8a163bbc3e Author: Greg Kroah-Hartman Date: Tue Nov 16 11:18:33 2010 -0800 Staging: frontier: fix up some sysfs attribute permissions commit 3bad28ec006ad6ab2bca4e5103860b75391e3c9d upstream. They should not be writable by any user Reported-by: Linus Torvalds Cc: David Taht Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit dbdcbc0faa3fcc25d524533ae65ecc8697e7549c Author: James Jones Date: Wed Nov 24 00:21:37 2010 +0100 ARM: 6482/2: Fix find_next_zero_bit and related assembly commit 0e91ec0c06d2cd15071a6021c94840a50e6671aa upstream. The find_next_bit, find_first_bit, find_next_zero_bit and find_first_zero_bit functions were not properly clamping to the maxbit argument at the bit level. They were instead only checking maxbit at the byte level. To fix this, add a compare and a conditional move instruction to the end of the common bit-within-the- byte code used by all the functions and be sure not to clobber the maxbit argument before it is used. Reviewed-by: Nicolas Pitre Tested-by: Stephen Warren Signed-off-by: James Jones Signed-off-by: Russell King Signed-off-by: Paul Gortmaker commit f7e8a96d362336ff05044477571d0f1e804c5e71 Author: Will Deacon Date: Fri Nov 19 13:18:31 2010 +0100 ARM: 6489/1: thumb2: fix incorrect optimisation in usracc commit 1142b71d85894dcff1466dd6c871ea3c89e0352c upstream. Commit 8b592783 added a Thumb-2 variant of usracc which, when it is called with \rept=2, calls usraccoff once with an offset of 0 and secondly with a hard-coded offset of 4 in order to avoid incrementing the pointer again. If \inc != 4 then we will store the data to the wrong offset from \ptr. Luckily, the only caller that passes \rept=2 to this function is __clear_user so we haven't been actively corrupting user data. This patch fixes usracc to pass \inc instead of #4 to usraccoff when it is called a second time. Reported-by: Tony Thompson Acked-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Paul Gortmaker commit 3ba00fdcf9e90198f160a45eb22e552d8932b137 Author: Pekka Enberg Date: Mon Nov 8 21:29:07 2010 +0200 perf_events: Fix perf_counter_mmap() hook in mprotect() commit 63bfd7384b119409685a17d5c58f0b56e5dc03da upstream. As pointed out by Linus, commit dab5855 ("perf_counter: Add mmap event hooks to mprotect()") is fundamentally wrong as mprotect_fixup() can free 'vma' due to merging. Fix the problem by moving perf_event_mmap() hook to mprotect_fixup(). Note: there's another successful return path from mprotect_fixup() if old flags equal to new flags. We don't, however, need to call perf_event_mmap() there because 'perf' already knows the VMA is executable. Reported-by: Dave Jones Analyzed-by: Linus Torvalds Cc: Ingo Molnar Reviewed-by: Peter Zijlstra Signed-off-by: Pekka Enberg Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 9e6858e507d3dca37d55af263b90d794807c1a05 Author: Dan Rosenberg Date: Tue Nov 23 11:02:13 2010 +0000 DECnet: don't leak uninitialized stack byte commit 3c6f27bf33052ea6ba9d82369fb460726fb779c0 upstream. A single uninitialized padding byte is leaked to userspace. Signed-off-by: Dan Rosenberg Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit e96a9a1244b61425055e8f498a1db40eb5924ac4 Author: Steven J. Magnani Date: Wed Nov 24 12:56:54 2010 -0800 nommu: yield CPU while disposing VM commit 04c3496152394d17e3bc2316f9731ee3e8a026bc upstream. Depending on processor speed, page size, and the amount of memory a process is allowed to amass, cleanup of a large VM may freeze the system for many seconds. This can result in a watchdog timeout. Make sure other tasks receive some service when cleaning up large VMs. Signed-off-by: Steven J. Magnani Cc: Greg Ungerer Reviewed-by: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 5c0f71147d9b5623db9353002605c9c648870e8d Author: Uwe Kleine-König Date: Wed Nov 24 12:57:14 2010 -0800 backlight: grab ops_lock before testing bd->ops commit d1d73578e053b981c3611e5a211534290d24a5eb upstream. According to the comment describing ops_lock in the definition of struct backlight_device and when comparing with other functions in backlight.c the mutex must be hold when checking ops to be non-NULL. Fixes a problem added by c835ee7f4154992e6 ("backlight: Add suspend/resume support to the backlight core") in Jan 2009. Signed-off-by: Uwe Kleine-König Acked-by: Richard Purdie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 1c215bfe11bc1837af11df453a4fa586dafad56b Author: Will Newton Date: Wed Nov 24 12:56:55 2010 -0800 uml: disable winch irq before freeing handler data commit 69e83dad5207f8f03c9699e57e1febb114383cb8 upstream. Disable the winch irq early to make sure we don't take an interrupt part way through the freeing of the handler data, resulting in a crash on shutdown: winch_interrupt : read failed, errno = 9 fd 13 is losing SIGWINCH support ------------[ cut here ]------------ WARNING: at lib/list_debug.c:48 list_del+0xc6/0x100() list_del corruption, next is LIST_POISON1 (00100100) 082578c8: [<081fd77f>] dump_stack+0x22/0x24 082578e0: [<0807a18a>] warn_slowpath_common+0x5a/0x80 08257908: [<0807a23e>] warn_slowpath_fmt+0x2e/0x30 08257920: [<08172196>] list_del+0xc6/0x100 08257940: [<08060244>] free_winch+0x14/0x80 08257958: [<080606fb>] winch_interrupt+0xdb/0xe0 08257978: [<080a65b5>] handle_IRQ_event+0x35/0xe0 08257998: [<080a8717>] handle_edge_irq+0xb7/0x170 082579bc: [<08059bc4>] do_IRQ+0x34/0x50 082579d4: [<08059e1b>] sigio_handler+0x5b/0x80 082579ec: [<0806a374>] sig_handler_common+0x44/0xb0 08257a68: [<0806a538>] sig_handler+0x38/0x50 08257a78: [<0806a77c>] handle_signal+0x5c/0xa0 08257a9c: [<0806be28>] hard_handler+0x18/0x20 08257aac: [<00c14400>] 0xc14400 Signed-off-by: Will Newton Acked-by: WANG Cong Cc: Jeff Dike Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit ab1c9b9db0831464307f130ba0fd13a27c852e4f Author: Nelson Elhage Date: Thu Dec 2 14:31:21 2010 -0800 do_exit(): make sure that we run with get_fs() == USER_DS commit 33dd94ae1ccbfb7bf0fb6c692bc3d1c4269e6177 upstream. If a user manages to trigger an oops with fs set to KERNEL_DS, fs is not otherwise reset before do_exit(). do_exit may later (via mm_release in fork.c) do a put_user to a user-controlled address, potentially allowing a user to leverage an oops into a controlled write into kernel memory. This is only triggerable in the presence of another bug, but this potentially turns a lot of DoS bugs into privilege escalations, so it's worth fixing. I have proof-of-concept code which uses this bug along with CVE-2010-3849 to write a zero to an arbitrary kernel address, so I've tested that this is not theoretical. A more logical place to put this fix might be when we know an oops has occurred, before we call do_exit(), but that would involve changing every architecture, in multiple places. Let's just stick it in do_exit instead. [akpm@linux-foundation.org: update code comment] Signed-off-by: Nelson Elhage Cc: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 53b7be4374faeec200429b429f35238858ae4d09 Author: Ken Sumrall Date: Wed Nov 24 12:57:00 2010 -0800 fuse: fix attributes after open(O_TRUNC) commit a0822c55779d9319939eac69f00bb729ea9d23da upstream. The attribute cache for a file was not being cleared when a file is opened with O_TRUNC. If the filesystem's open operation truncates the file ("atomic_o_trunc" feature flag is set) then the kernel should invalidate the cached st_mtime and st_ctime attributes. Also i_size should be explicitly be set to zero as it is used sometimes without refreshing the cache. Signed-off-by: Ken Sumrall Cc: Anfei Cc: "Anand V. Avati" Signed-off-by: Miklos Szeredi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 2b5b4eda6132079ec9f5c623115239b62bedb9c4 Author: Zhang Rui Date: Tue Oct 12 09:09:37 2010 +0800 acpi-cpufreq: fix a memleak when unloading driver commit dab5fff14df2cd16eb1ad4c02e83915e1063fece upstream. We didn't free per_cpu(acfreq_data, cpu)->freq_table when acpi_freq driver is unloaded. Resulting in the following messages in /sys/kernel/debug/kmemleak: unreferenced object 0xf6450e80 (size 64): comm "modprobe", pid 1066, jiffies 4294677317 (age 19290.453s) hex dump (first 32 bytes): 00 00 00 00 e8 a2 24 00 01 00 00 00 00 9f 24 00 ......$.......$. 02 00 00 00 00 6a 18 00 03 00 00 00 00 35 0c 00 .....j.......5.. backtrace: [] kmemleak_alloc+0x27/0x50 [] __kmalloc+0xcf/0x110 [] acpi_cpufreq_cpu_init+0x1ee/0x4e4 [acpi_cpufreq] [] cpufreq_add_dev+0x142/0x3a0 [] sysdev_driver_register+0x97/0x110 [] cpufreq_register_driver+0x86/0x140 [] 0xf9dad080 [] do_one_initcall+0x30/0x160 [] sys_init_module+0x99/0x1e0 [] sysenter_do_call+0x12/0x26 [] 0xffffffff https://bugzilla.kernel.org/show_bug.cgi?id=15807#c21 Tested-by: Toralf Forster Signed-off-by: Zhang Rui Signed-off-by: Len Brown Signed-off-by: Paul Gortmaker commit 9556f1d2528a9be0a7ddeb6e9b631f4be639a166 Author: Jacques Viviers Date: Wed Nov 24 11:56:38 2010 +0200 USB: serial: ftdi_sio: Vardaan USB RS422/485 converter PID added commit 6fdbad8021151a9e93af8159a6232c8f26415c09 upstream. Add the PID for the Vardaan Enterprises VEUSB422R3 USB to RS422/485 converter. It uses the same chip as the FTDI_8U232AM_PID 0x6001. This should also work with the stable branches for: 2.6.31, 2.6.32, 2.6.33, 2.6.34, 2.6.35, 2.6.36 Signed-off-by: Jacques Viviers Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 1af1da5d3fb7e614cc7d21a0a1b2e596c1c7bc64 Author: Michael Stuermer Date: Thu Nov 18 00:45:43 2010 +0100 USB: ftdi_sio: Add ID for RT Systems USB-29B radio cable commit 28942bb6a9dd4e2ed793675e515cfb8297ed355b upstream. Another variant of the RT Systems programming cable for ham radios. Signed-off-by: Michael Stuermer Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 917ff6e9529a2655c6fcf38ef735ac80edcd94f4 Author: Greg Kroah-Hartman Date: Mon Nov 15 11:36:44 2010 -0800 USB: misc: usbsevseg: fix up some sysfs attribute permissions commit e24d7ace4e822debcb78386bf279c9aba4d7fbd1 upstream. They should not be writable by any user. Reported-by: Linus Torvalds Cc: Harrison Metzger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 6685028b13b9617167970644624d52b95df57b78 Author: Greg Kroah-Hartman Date: Mon Nov 15 11:34:26 2010 -0800 USB: misc: trancevibrator: fix up a sysfs attribute permission commit d489a4b3926bad571d404ca6508f6744b9602776 upstream. It should not be writable by any user. Reported-by: Linus Torvalds Cc: Sam Hocevar Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit a3718d29339e891b5ddfca3acb6f8d3aa38792e1 Author: Johan Hovold Date: Sun Sep 12 16:31:45 2010 +0200 USB: ftdi_sio: revert "USB: ftdi_sio: fix DTR/RTS line modes" commit 677aeafe19e88c282af74564048243ccabb1c590 upstream. This reverts commit 6a1a82df91fa0eb1cc76069a9efe5714d087eccd. RTS and DTR should not be modified based on CRTSCTS when calling set_termios. Modem control lines are raised at port open by the tty layer and should stay raised regardless of whether hardware flow control is enabled or not. This is in conformance with the way serial ports work today and many applications depend on this behaviour to be able to talk to hardware implementing hardware flow control (without the applications actually using it). Hardware which expects different behaviour on these lines can always use TIOCMSET/TIOCMBI[SC] after port open to change them. Reported-by: Daniel Mack Reported-by: Dave Mielke Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 36e62fc72e1669ac05cda7f0fa2193bbf26681af Author: Greg Kroah-Hartman Date: Mon Nov 15 11:35:49 2010 -0800 USB: misc: usbled: fix up some sysfs attribute permissions commit 48f115470e68d443436b76b22dad63ffbffd6b97 upstream. They should not be writable by any user. Reported-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 2977e5adadb4519dc068091fd61c7886ae55b1d7 Author: Greg Kroah-Hartman Date: Mon Nov 15 11:32:38 2010 -0800 USB: misc: cypress_cy7c63: fix up some sysfs attribute permissions commit c990600d340641150f7270470a64bd99a5c0b225 upstream. They should not be writable by any user. Reported-by: Linus Torvalds Cc: Oliver Bock Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit c93d26853c804903ac4bbd74669fa0cd50abc803 Author: Greg Kroah-Hartman Date: Mon Nov 15 11:11:45 2010 -0800 USB: atm: ueagle-atm: fix up some permissions on the sysfs files commit e502ac5e1eca99d7dc3f12b2a6780ccbca674858 upstream. Some of the sysfs files had the incorrect permissions. Some didn't make sense at all (writable for a file that you could not write to?) Reported-by: Linus Torvalds Cc: Matthieu Castet Cc: Stanislaw Gruszka Cc: Damien Bergamini Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 33456d137b95852e2767f85eb62c1aa41e25d42d Author: Greg Kroah-Hartman Date: Mon Nov 15 11:17:52 2010 -0800 USB: storage: sierra_ms: fix sysfs file attribute commit d9624e75f6ad94d8a0718c1fafa89186d271a78c upstream. A non-writable sysfs file shouldn't have writable attributes. Reported-by: Linus Torvalds Cc: Kevin Lloyd Cc: Matthew Dharm Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit fe4a5186944e1cc7e9a6a13b2975aa47612a36a3 Author: Alan Stern Date: Tue Nov 16 10:57:37 2010 -0500 USB: EHCI: fix obscure race in ehci_endpoint_disable commit 02e2c51ba3e80acde600721ea784c3ef84da5ea1 upstream. This patch (as1435) fixes an obscure and unlikely race in ehci-hcd. When an async URB is unlinked, the corresponding QH is removed from the async list. If the QH's endpoint is then disabled while the URB is being given back, ehci_endpoint_disable() won't find the QH on the async list, causing it to believe that the QH has been lost. This will lead to a memory leak at best and quite possibly to an oops. The solution is to trust usbcore not to lose track of endpoints. If the QH isn't on the async list then it doesn't need to be taken off the list, but the driver should still wait for the QH to become IDLE before disabling it. In theory this fixes Bugzilla #20182. In fact the race is so rare that it's not possible to tell whether the bug is still present. However, adding delays and making other changes to force the race seems to show that the patch works. Signed-off-by: Alan Stern Reported-by: Stefan Richter CC: David Brownell Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit c7e02fd6a1b3a53c80c23cf14968c8c482742ae9 Author: Vasiliy Kulikov Date: Sat Nov 6 17:41:28 2010 +0300 usb: core: fix information leak to userland commit 886ccd4520064408ce5876cfe00554ce52ecf4a7 upstream. Structure usbdevfs_connectinfo is copied to userland with padding byted after "slow" field uninitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by: Vasiliy Kulikov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit b2af2ddc6b97968a2ef18161ee0c0681fc0df559 Author: Vasiliy Kulikov Date: Sat Nov 6 17:41:31 2010 +0300 usb: misc: iowarrior: fix information leak to userland commit eca67aaeebd6e5d22b0d991af1dd0424dc703bfb upstream. Structure iowarrior_info is copied to userland with padding byted between "serial" and "revision" fields uninitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by: Vasiliy Kulikov Acked-by: Kees Cook Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 0eea165a9835343972dcd47b1078da0f7b140d0f Author: Vasiliy Kulikov Date: Sat Nov 6 17:41:35 2010 +0300 usb: misc: sisusbvga: fix information leak to userland commit 5dc92cf1d0b4b0debbd2e333b83f9746c103533d upstream. Structure sisusb_info is copied to userland with "sisusb_reserved" field uninitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by: Vasiliy Kulikov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit a0df64eb273821e6fc9d7a3d3f516d60cb2cb6ac Author: ma rui Date: Mon Nov 1 11:32:18 2010 +0800 USB: option: fix when the driver is loaded incorrectly for some Huawei devices. commit 58c0d9d70109bd7e82bdb9517007311a48499960 upstream. When huawei datacard with PID 0x14AC is insterted into Linux system, the present kernel will load the "option" driver to all the interfaces. But actually, some interfaces run as other function and do not need "option" driver. In this path, we modify the id_tables, when the PID is 0x14ac ,VID is 0x12d1, Only when the interface's Class is 0xff,Subclass is 0xff, Pro is 0xff, it does need "option" driver. Signed-off-by: ma rui Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 8c812ba2f5895b757bd8a044f757980df73b9510 Author: Sebastien Bourdeauducq Date: Wed Nov 3 11:54:12 2010 +0100 USB: ftdi_sio: add device IDs for Milkymist One JTAG/serial commit 7fea0f714ffb3f303d4b66933af2df2f5584c9bf upstream. Add the USB IDs for the Milkymist One FTDI-based JTAG/serial adapter (http://projects.qi-hardware.com/index.php/p/mmone-jtag-serial-cable/) to the ftdi_sio driver and disable the first serial channel (used as JTAG from userspace). Signed-off-by: Sebastien Bourdeauducq Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit abedd04491b553241a1fdb61e708cc3b663dee83 Author: Peter Jones Date: Wed Sep 22 13:05:04 2010 -0700 efifb: check that the base address is plausible on pci systems commit 85a00d9bbfb4704fbf368944b1cb9fed8f1598c5 upstream. Some Apple machines have identical DMI data but different memory configurations for the video. Given that, check that the address in our table is actually within the range of a PCI BAR on a VGA device in the machine. This also fixes up the return value from set_system(), which has always been wrong, but never resulted in bad behavior since there's only ever been one matching entry in the dmi table. The patch 1) stops people's machines from crashing when we get their display wrong, which seems to be unfortunately inevitable, 2) allows us to support identical dmi data with differing video memory configurations This also adds me as the efifb maintainer, since I've effectively been acting as such for quite some time. Signed-off-by: Peter Jones Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 91cf12616cdaa14d06631b634222b8d0cab7f340 Author: Darrick J. Wong Date: Tue Nov 16 09:13:41 2010 -0800 PCI: fix offset check for sysfs mmapped files commit 8c05cd08a7504b855c265263e84af61aabafa329 upstream. I just loaded 2.6.37-rc2 on my machines, and I noticed that X no longer starts. Running an strace of the X server shows that it's doing this: open("/sys/bus/pci/devices/0000:07:00.0/resource0", O_RDWR) = 10 mmap(NULL, 16777216, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = -1 EINVAL (Invalid argument) This code seems to be asking for a shared read/write mapping of 16MB worth of BAR0 starting at file offset 0, and letting the kernel assign a starting address. Unfortunately, this -EINVAL causes X not to start. Looking into dmesg, there's a complaint like so: process "Xorg" tried to map 0x01000000 bytes at page 0x00000000 on 0000:07:00.0 BAR 0 (start 0x 96000000, size 0x 1000000) ...with the following code in pci_mmap_fits: pci_start = (mmap_api == PCI_MMAP_SYSFS) ? pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0; if (start >= pci_start && start < pci_start + size && start + nr <= pci_start + size) It looks like the logic here is set up such that when the mmap call comes via sysfs, the check in pci_mmap_fits wants vma->vm_pgoff to be between the resource's start and end address, and the end of the vma to be no farther than the end. However, the sysfs PCI resource files always start at offset zero, which means that this test always fails for programs that mmap the sysfs files. Given the comment in the original commit 3b519e4ea618b6943a82931630872907f9ac2c2b, I _think_ the old procfs files require that the file offset be equal to the resource's base address when mmapping. I think what we want here is for pci_start to be 0 when mmap_api == PCI_MMAP_PROCFS. The following patch makes that change, after which the Matrox and Mach64 X drivers work again. Acked-by: Martin Wilck Signed-off-by: Darrick J. Wong Signed-off-by: Jesse Barnes Signed-off-by: Paul Gortmaker commit ee9bfe120e59458158f592ab0bfbe814ff9a47ee Author: Randy Dunlap Date: Sat Nov 13 08:44:33 2010 -0800 PCI: sysfs: fix printk warnings commit e25cd062b16ed1d41a157aec5a108abd6ff2e9f9 upstream. Cast pci_resource_start() and pci_resource_len() to u64 for printk. drivers/pci/pci-sysfs.c:753: warning: format '%16Lx' expects type 'long long unsigned int', but argument 9 has type 'resource_size_t' drivers/pci/pci-sysfs.c:753: warning: format '%16Lx' expects type 'long long unsigned int', but argument 10 has type 'resource_size_t' Signed-off-by: Randy Dunlap Signed-off-by: Jesse Barnes Signed-off-by: Paul Gortmaker commit 4b743063a1fde0024a2e518e5d753e8dd7045212 Author: Martin Wilck Date: Wed Nov 10 11:03:21 2010 +0100 PCI: fix size checks for mmap() on /proc/bus/pci files commit 3b519e4ea618b6943a82931630872907f9ac2c2b upstream. The checks for valid mmaps of PCI resources made through /proc/bus/pci files that were introduced in 9eff02e2042f96fb2aedd02e032eca1c5333d767 have several problems: 1. mmap() calls on /proc/bus/pci files are made with real file offsets > 0, whereas under /sys/bus/pci/devices, the start of the resource corresponds to offset 0. This may lead to false negatives in pci_mmap_fits(), which implicitly assumes the /sys/bus/pci/devices layout. 2. The loop in proc_bus_pci_mmap doesn't skip empty resouces. This leads to false positives, because pci_mmap_fits() doesn't treat empty resources correctly (the calculated size is 1 << (8*sizeof(resource_size_t)-PAGE_SHIFT) in this case!). 3. If a user maps resources with BAR > 0, pci_mmap_fits will emit bogus WARNINGS for the first resources that don't fit until the correct one is found. On many controllers the first 2-4 BARs are used, and the others are empty. In this case, an mmap attempt will first fail on the non-empty BARs (including the "right" BAR because of 1.) and emit bogus WARNINGS because of 3., and finally succeed on the first empty BAR because of 2. This is certainly not the intended behaviour. This patch addresses all 3 issues. Updated with an enum type for the additional parameter for pci_mmap_fits(). Signed-off-by: Martin Wilck Signed-off-by: Jesse Barnes Signed-off-by: Paul Gortmaker commit b8d823c716dceeb1a6b4c6b6883a4f61a5f429df Author: Tejun Heo Date: Mon Nov 1 11:39:19 2010 +0100 libata: fix NULL sdev dereference race in atapi_qc_complete() commit 2a5f07b5ec098edc69e05fdd2f35d3fbb1235723 upstream. SCSI commands may be issued between __scsi_add_device() and dev->sdev assignment, so it's unsafe for ata_qc_complete() to dereference dev->sdev->locked without checking whether it's NULL or not. Fix it. Signed-off-by: Tejun Heo Signed-off-by: Jeff Garzik Signed-off-by: Paul Gortmaker commit f3c6760b8b22b57b965cc3e1e39a3514fa9d500b Author: Francisco Jerez Date: Tue Sep 21 02:15:15 2010 +0200 drm/ttm: Clear the ghost cpu_writers flag on ttm_buffer_object_transfer. commit 0fbecd400dd0a82d465b3086f209681e8c54cb0f upstream. It makes sense for a BO to move after a process has requested exclusive RW access on it (e.g. because the BO used to be located in unmappable VRAM and we intercepted the CPU access from the fault handler). If we let the ghost object inherit cpu_writers from the original object, ttm_bo_release_list() will raise a kernel BUG when the ghost object is destroyed. This can be reproduced with the nouveau driver on nv5x. Reported-by: Marcin Slusarz Reviewed-by: Jerome Glisse Tested-by: Marcin Slusarz Signed-off-by: Francisco Jerez Signed-off-by: Dave Airlie Signed-off-by: Paul Gortmaker commit eee7ce0336dc2e1b9fe2fe3d02a0f34f16ec9902 Author: Jens Axboe Date: Wed Nov 10 14:36:25 2010 +0100 bio: take care not overflow page count when mapping/copying user data commit cb4644cac4a2797afc847e6c92736664d4b0ea34 upstream. If the iovec is being set up in a way that causes uaddr + PAGE_SIZE to overflow, we could end up attempting to map a huge number of pages. Check for this invalid input type. Reported-by: Dan Rosenberg Signed-off-by: Jens Axboe Signed-off-by: Paul Gortmaker commit 75eb775b43734d713ff22eebd05c6e156820b12f Author: Dave Hansen Date: Thu Nov 11 14:05:15 2010 -0800 mm/vfs: revalidate page->mapping in do_generic_file_read() commit 8d056cb965b8fb7c53c564abf28b1962d1061cd3 upstream. 70 hours into some stress tests of a 2.6.32-based enterprise kernel, we ran into a NULL dereference in here: int block_is_partially_uptodate(struct page *page, read_descriptor_t *desc, unsigned long from) { ----> struct inode *inode = page->mapping->host; It looks like page->mapping was the culprit. (xmon trace is below). After closer examination, I realized that do_generic_file_read() does a find_get_page(), and eventually locks the page before calling block_is_partially_uptodate(). However, it doesn't revalidate the page->mapping after the page is locked. So, there's a small window between the find_get_page() and ->is_partially_uptodate() where the page could get truncated and page->mapping cleared. We _have_ a reference, so it can't get reclaimed, but it certainly can be truncated. I think the correct thing is to check page->mapping after the trylock_page(), and jump out if it got truncated. This patch has been running in the test environment for a month or so now, and we have not seen this bug pop up again. xmon info: 1f:mon> e cpu 0x1f: Vector: 300 (Data Access) at [c0000002ae36f770] pc: c0000000001e7a6c: .block_is_partially_uptodate+0xc/0x100 lr: c000000000142944: .generic_file_aio_read+0x1e4/0x770 sp: c0000002ae36f9f0 msr: 8000000000009032 dar: 0 dsisr: 40000000 current = 0xc000000378f99e30 paca = 0xc000000000f66300 pid = 21946, comm = bash 1f:mon> r R00 = 0025c0500000006d R16 = 0000000000000000 R01 = c0000002ae36f9f0 R17 = c000000362cd3af0 R02 = c000000000e8cd80 R18 = ffffffffffffffff R03 = c0000000031d0f88 R19 = 0000000000000001 R04 = c0000002ae36fa68 R20 = c0000003bb97b8a0 R05 = 0000000000000000 R21 = c0000002ae36fa68 R06 = 0000000000000000 R22 = 0000000000000000 R07 = 0000000000000001 R23 = c0000002ae36fbb0 R08 = 0000000000000002 R24 = 0000000000000000 R09 = 0000000000000000 R25 = c000000362cd3a80 R10 = 0000000000000000 R26 = 0000000000000002 R11 = c0000000001e7b60 R27 = 0000000000000000 R12 = 0000000042000484 R28 = 0000000000000001 R13 = c000000000f66300 R29 = c0000003bb97b9b8 R14 = 0000000000000001 R30 = c000000000e28a08 R15 = 000000000000ffff R31 = c0000000031d0f88 pc = c0000000001e7a6c .block_is_partially_uptodate+0xc/0x100 lr = c000000000142944 .generic_file_aio_read+0x1e4/0x770 msr = 8000000000009032 cr = 22000488 ctr = c0000000001e7a60 xer = 0000000020000000 trap = 300 dar = 0000000000000000 dsisr = 40000000 1f:mon> t [link register ] c000000000142944 .generic_file_aio_read+0x1e4/0x770 [c0000002ae36f9f0] c000000000142a14 .generic_file_aio_read+0x2b4/0x770 (unreliable) [c0000002ae36fb40] c0000000001b03e4 .do_sync_read+0xd4/0x160 [c0000002ae36fce0] c0000000001b153c .vfs_read+0xec/0x1f0 [c0000002ae36fd80] c0000000001b1768 .SyS_read+0x58/0xb0 [c0000002ae36fe30] c00000000000852c syscall_exit+0x0/0x40 --- Exception: c00 (System Call) at 00000080a840bc54 SP (fffca15df30) is in userspace 1f:mon> di c0000000001e7a6c c0000000001e7a6c e9290000 ld r9,0(r9) c0000000001e7a70 418200c0 beq c0000000001e7b30 # .block_is_partially_uptodate+0xd0/0x100 c0000000001e7a74 e9440008 ld r10,8(r4) c0000000001e7a78 78a80020 clrldi r8,r5,32 c0000000001e7a7c 3c000001 lis r0,1 c0000000001e7a80 812900a8 lwz r9,168(r9) c0000000001e7a84 39600001 li r11,1 c0000000001e7a88 7c080050 subf r0,r8,r0 c0000000001e7a8c 7f805040 cmplw cr7,r0,r10 c0000000001e7a90 7d6b4830 slw r11,r11,r9 c0000000001e7a94 796b0020 clrldi r11,r11,32 c0000000001e7a98 419d00a8 bgt cr7,c0000000001e7b40 # .block_is_partially_uptodate+0xe0/0x100 c0000000001e7a9c 7fa55840 cmpld cr7,r5,r11 c0000000001e7aa0 7d004214 add r8,r0,r8 c0000000001e7aa4 79080020 clrldi r8,r8,32 c0000000001e7aa8 419c0078 blt cr7,c0000000001e7b20 # .block_is_partially_uptodate+0xc0/0x100 Signed-off-by: Dave Hansen Reviewed-by: Minchan Kim Reviewed-by: Johannes Weiner Acked-by: Rik van Riel Cc: Cc: Cc: Christoph Hellwig Cc: Al Viro Cc: Minchan Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit dc290f0271eb1f4e9d98fe68da9603e2ed32e4bc Author: Ken Chen Date: Thu Nov 11 14:05:16 2010 -0800 latencytop: fix per task accumulator commit 38715258aa2e8cd94bd4aafadc544e5104efd551 upstream. Per task latencytop accumulator prematurely terminates due to erroneous placement of latency_record_count. It should be incremented whenever a new record is allocated instead of increment on every latencytop event. Also fix search iterator to only search known record events instead of blindly searching all pre-allocated space. Signed-off-by: Ken Chen Reviewed-by: Arjan van de Ven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 51c1a2aa438732cef932168e413f6e46aa5dff22 Author: Eric Dumazet Date: Thu Oct 28 12:34:21 2010 +0200 netfilter: nf_conntrack: allow nf_ct_alloc_hashtable() to get highmem pages commit 6b1686a71e3158d3c5f125260effce171cc7852b upstream. commit ea781f197d6a8 (use SLAB_DESTROY_BY_RCU and get rid of call_rcu()) did a mistake in __vmalloc() call in nf_ct_alloc_hashtable(). I forgot to add __GFP_HIGHMEM, so pages were taken from LOWMEM only. Signed-off-by: Eric Dumazet Signed-off-by: Patrick McHardy Signed-off-by: Paul Gortmaker commit 043c1fe830eee50ae3f7f31c90bbb1e52cb23c53 Author: Daniel T Chen Date: Wed Dec 1 19:16:07 2010 -0500 ALSA: hda: Use "alienware" model quirk for another SSID commit 0defe09ca70daccdc83abd9c3c24cd89ae6a1141 upstream. BugLink: https://launchpad.net/bugs/683695 The original reporter states that headphone jacks do not appear to work. Upon inspecting his codec dump, and upon further testing, it is confirmed that the "alienware" model quirk is correct. Reported-and-tested-by: Cody Thierauf Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 3a815fb9fc6d8d6192a8be3e2cb2cab7a36ac4e6 Author: David Henningsson Date: Wed Nov 24 14:17:47 2010 +0100 ALSA: HDA: Add an extra DAC for Realtek ALC887-VD commit cc1c452e509aefc28f7ad2deed75bc69d4f915f7 upstream. The patch enables ALC887-VD to use the DAC at nid 0x26, which makes it possible to use this DAC for e g Headphone volume. Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit fdc8a53dd17057112e35c96338a030c406af33b8 Author: Daniel T Chen Date: Mon Nov 1 01:14:51 2010 -0400 ALSA: ac97: Apply quirk for Dell Latitude D610 binding Master and Headphone controls commit 0613a59456980161d0cd468bae6c63d772743102 upstream. BugLink: https://launchpad.net/bugs/669279 The original reporter states: "The Master mixer does not change the volume from the headphone output (which is affected by the headphone mixer). Instead it only seems to control the on-board speaker volume. This confuses PulseAudio greatly as the Master channel is merged into the volume mix." Fix this symptom by applying the hp_only quirk for the reporter's SSID. The fix is applicable to all stable kernels. Reported-and-tested-by: Ben Gamari Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 55b3b58713f2152ac92d8bb108a9561ac47f74bf Author: Clemens Ladisch Date: Mon Oct 25 11:42:20 2010 +0200 firewire: ohci: fix race in AR split packet handling commit a1f805e5e73a8fe166b71c6592d3837df0cd5e2e upstream. When handling an AR buffer that has been completely filled, we assumed that its descriptor will not be read by the controller and can be overwritten. However, when the last received packet happens to end at the end of the buffer, the controller might not yet have moved on to the next buffer and might read the branch address later. If we overwrite and free the page before that, the DMA context will either go dead because of an invalid Z value, or go off into some random memory. To fix this, ensure that the descriptor does not get overwritten by using only the actual buffer instead of the entire page for reassembling the split packet. Furthermore, to avoid freeing the page too early, move on to the next buffer only when some data in it guarantees that the controller has moved on. This should eliminate the remaining firewire-net problems. Signed-off-by: Clemens Ladisch Tested-by: Maxim Levitsky Signed-off-by: Stefan Richter Signed-off-by: Paul Gortmaker commit 449125b54a5e5e8d11c7a2265544889214171d2f Author: Clemens Ladisch Date: Mon Oct 25 11:41:53 2010 +0200 firewire: ohci: fix buffer overflow in AR split packet handling commit 85f7ffd5d2b320f73912b15fe8cef34bae297daf upstream. When the controller had to split a received asynchronous packet into two buffers, the driver tries to reassemble it by copying both parts into the first page. However, if size + rest > PAGE_SIZE, i.e., if the yet unhandled packets before the split packet, the split packet itself, and any received packets after the split packet are together larger than one page, then the memory after the first page would get overwritten. To fix this, do not try to copy the data of all unhandled packets at once, but copy the possibly needed data every time when handling a packet. This gets rid of most of the infamous crashes and data corruptions when using firewire-net. Signed-off-by: Clemens Ladisch Tested-by: Maxim Levitsky Signed-off-by: Stefan Richter (cast PAGE_SIZE to size_t) Signed-off-by: Paul Gortmaker commit 3bbe1867dd5d6ca159a447874cadc7cbef19251e Author: Avi Kivity Date: Thu Nov 11 12:37:26 2010 +0200 KVM: VMX: Fix host userspace gsbase corruption commit c8770e7ba63bb5dd8fe5f9d251275a8fa717fb78 upstream. We now use load_gs_index() to load gs safely; unfortunately this also changes MSR_KERNEL_GS_BASE, which we managed separately. This resulted in confusion and breakage running 32-bit host userspace on a 64-bit kernel. Fix by - saving guest MSR_KERNEL_GS_BASE before we we reload the host's gs - doing the host save/load unconditionally, instead of only when in guest long mode Things can be cleaned up further, but this is the minmal fix for now. Signed-off-by: Avi Kivity Signed-off-by: Marcelo Tosatti Signed-off-by: Paul Gortmaker commit eba62cf05ef4fc1780a582ce37a04900e0d40e00 Author: Vasiliy Kulikov Date: Sat Oct 30 22:54:47 2010 +0400 KVM: x86: fix information leak to userland commit 97e69aa62f8b5d338d6cff49be09e37cc1262838 upstream. Structures kvm_vcpu_events, kvm_debugregs, kvm_pit_state2 and kvm_clock_data are copied to userland with some padding and reserved fields unitialized. It leads to leaking of contents of kernel stack memory. We have to initialize them to zero. In patch v1 Jan Kiszka suggested to fill reserved fields with zeros instead of memset'ting the whole struct. It makes sense as these fields are explicitly marked as padding. No more fields need zeroing. [PG: 34 doesn't have the dbgregs section to be memset, so drop that bit] KVM-Stable-Tag. Signed-off-by: Vasiliy Kulikov Signed-off-by: Marcelo Tosatti Signed-off-by: Paul Gortmaker commit f85a085baa8957d490a1b843dec763c048c94a64 Author: Jiri Slaby Date: Thu Nov 25 00:27:54 2010 +0100 TTY: ldisc, fix open flag handling commit 7f90cfc505d613f4faf096e0d84ffe99208057d9 upstream. When a concrete ldisc open fails in tty_ldisc_open, we forget to clear TTY_LDISC_OPEN. This causes a false warning on the next ldisc open: WARNING: at drivers/char/tty_ldisc.c:445 tty_ldisc_open+0x26/0x38() Hardware name: System Product Name Modules linked in: ... Pid: 5251, comm: a.out Tainted: G W 2.6.32-5-686 #1 Call Trace: [] ? warn_slowpath_common+0x5e/0x8a [] ? warn_slowpath_null+0xa/0xc [] ? tty_ldisc_open+0x26/0x38 [] ? tty_set_ldisc+0x218/0x304 ... So clear the bit when failing... Introduced in c65c9bc3efa (tty: rewrite the ldisc locking) back in 2.6.31-rc1. Signed-off-by: Jiri Slaby Cc: Alan Cox Reported-by: Sergey Lapin Tested-by: Sergey Lapin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 3bddf9fc784ff937f80d475c6b5211560848fa5f Author: Philippe Rétornaz Date: Wed Oct 27 17:13:21 2010 +0200 tty_ldisc: Fix BUG() on hangup commit 1c95ba1e1de7edffc0c4e275e147f1a9eb1f81ae upstream. A kernel BUG when bluetooth rfcomm connection drop while the associated serial port is open is sometime triggered. It seems that the line discipline can disappear between the tty_ldisc_put and tty_ldisc_get. This patch fall back to the N_TTY line discipline if the previous discipline is not available anymore. Signed-off-by: Philippe Retornaz Acked-by: Alan Cox Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 01a9caf12c3c76f99c33590f7716fcbe8415becb Author: Jiri Slaby Date: Sun Oct 31 23:17:51 2010 +0100 TTY: restore tty_ldisc_wait_idle commit 100eeae2c5ce23b4db93ff320ee330ef1d740151 upstream. It was removed in 65b770468e98 (tty-ldisc: turn ldisc user count into a proper refcount), but we need to wait for last user to quit the ldisc before we close it in tty_set_ldisc. Otherwise weird things start to happen. There might be processes waiting in tty_read->n_tty_read on tty->read_wait for input to appear and at that moment, a change of ldisc is fatal. n_tty_close is called, it frees read_buf and the waiting process is still in the middle of reading and goes nuts after it is woken. Previously we prevented close to happen when others are in ldisc ops by tty_ldisc_wait_idle in tty_set_ldisc. But the commit above removed that. So revoke the change and test whether there is 1 user (=we), and allow the close then. We can do that without ldisc/tty locks, because nobody else can open the device due to TTY_LDISC_CHANGING bit set, so we in fact wait for everybody to leave. I don't understand why tty_ldisc_lock would be needed either when the counter is an atomic variable, so this is a lockless tty_ldisc_wait_idle. On the other hand, if we fail to wait (timeout or signal), we have to reenable the halted ldiscs, so we take ldisc lock and reuse the setup path at the end of tty_set_ldisc. Signed-off-by: Jiri Slaby Acked-by: Linus Torvalds Tested-by: Sebastian Andrzej Siewior Signed-off-by: Andi Kleen LKML-Reference: <20101031104136.GA511@Chamillionaire.breakpoint.cc> LKML-Reference: <1287669539-22644-1-git-send-email-jslaby@suse.cz> Cc: Alan Cox Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit ff8af4e56069b2294277cb1645395098752a40b2 Author: Jiri Olsa Date: Mon Nov 8 19:01:47 2010 +0100 tty: prevent DOS in the flush_to_ldisc commit e045fec48970df84647a47930fcf7a22ff7229c0 upstream. There's a small window inside the flush_to_ldisc function, where the tty is unlocked and calling ldisc's receive_buf function. If in this window new buffer is added to the tty, the processing might never leave the flush_to_ldisc function. This scenario will hog the cpu, causing other tty processing starving, and making it impossible to interface the computer via tty. I was able to exploit this via pty interface by sending only control characters to the master input, causing the flush_to_ldisc to be scheduled, but never actually generate any output. To reproduce, please run multiple instances of following code. - SNIP #define _XOPEN_SOURCE #include #include #include #include #include int main(int argc, char **argv) { int i, slave, master = getpt(); char buf[8192]; sprintf(buf, "%s", ptsname(master)); grantpt(master); unlockpt(master); slave = open(buf, O_RDWR); if (slave < 0) { perror("open slave failed"); return 1; } for(i = 0; i < sizeof(buf); i++) buf[i] = rand() % 32; while(1) { write(master, buf, sizeof(buf)); } return 0; } - SNIP The attached patch (based on -next tree) fixes this by checking on the tty buffer tail. Once it's reached, the current work is rescheduled and another could run. Signed-off-by: Jiri Olsa Acked-by: Alan Cox Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 10d8e072cf0655a20d24a5d78296834fb0985d41 Author: Justin Maggard Date: Wed Nov 24 16:36:17 2010 +1100 md: fix return value of rdev_size_change() commit c26a44ed1e552aaa1d4ceb71842002d235fe98d7 upstream. When trying to grow an array by enlarging component devices, rdev_size_store() expects the return value of rdev_size_change() to be in sectors, but the actual value is returned in KBs. This functionality was broken by commit dd8ac336c13fd8afdb082ebacb1cddd5cf727889 so this patch is suitable for any kernel since 2.6.30. Signed-off-by: Justin Maggard Signed-off-by: NeilBrown Signed-off-by: Paul Gortmaker commit 85cd9d72b4fa3b77533b16ce55e49147ba7d3ace Author: NeilBrown Date: Wed Nov 24 16:39:46 2010 +1100 md/raid1: really fix recovery looping when single good device fails. commit 8f9e0ee38f75d4740daa9e42c8af628d33d19a02 upstream. Commit 4044ba58dd15cb01797c4fd034f39ef4a75f7cc3 supposedly fixed a problem where if a raid1 with just one good device gets a read-error during recovery, the recovery would abort and immediately restart in an infinite loop. However it depended on raid1_remove_disk removing the spare device from the array. But that does not happen in this case. So add a test so that in the 'recovery_disabled' case, the device will be removed. This suitable for any kernel since 2.6.29 which is when recovery_disabled was introduced. Reported-by: Sebastian Färber Signed-off-by: NeilBrown Signed-off-by: Paul Gortmaker commit 926f9465de9ac6f73efb570206c96d9d16b535f8 Author: Tyler Hicks Date: Thu Sep 23 02:35:04 2010 -0500 eCryptfs: Clear LOOKUP_OPEN flag when creating lower file commit 2e21b3f124eceb6ab5a07c8a061adce14ac94e14 upstream. eCryptfs was passing the LOOKUP_OPEN flag through to the lower file system, even though ecryptfs_create() doesn't support the flag. A valid filp for the lower filesystem could be returned in the nameidata if the lower file system's create() function supported LOOKUP_OPEN, possibly resulting in unencrypted writes to the lower file. However, this is only a potential problem in filesystems (FUSE, NFS, CIFS, CEPH, 9p) that eCryptfs isn't known to support today. https://bugs.launchpad.net/ecryptfs/+bug/641703 Reported-by: Kevin Buhr Signed-off-by: Tyler Hicks Signed-off-by: Paul Gortmaker commit bc8740957d581415f10aff74a6ebf08d908cf670 Author: Florian Tobias Schandinat Date: Wed Sep 22 02:33:52 2010 +0000 viafb: use proper register for colour when doing fill ops commit efd4f6398dc92b5bf392670df862f42a19f34cf2 upstream. The colour was written to a wrong register for fillrect operations. This sometimes caused empty console space (for example after 'clear') to have a different colour than desired. Fix this by writing to the correct register. Many thanks to Daniel Drake and Jon Nettleton for pointing out this issue and pointing me in the right direction for the fix. Fixes http://dev.laptop.org/ticket/9323 Signed-off-by: Florian Tobias Schandinat Cc: Joseph Chan Cc: Daniel Drake Cc: Jon Nettleton Signed-off-by: Paul Gortmaker commit 0320c0e8b3bb0c2d41e174d5fcd758af13a54b71 Author: Graham Gower Date: Wed Oct 27 15:33:00 2010 -0700 drivers/char/vt_ioctl.c: fix VT_OPENQRY error value commit 1e0ad2881d50becaeea70ec696a80afeadf944d2 upstream. When all VT's are in use, VT_OPENQRY casts -1 to unsigned char before returning it to userspace as an int. VT255 is not the next available console. Signed-off-by: Graham Gower Cc: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit c7cbd0f7e7e282a97ac91d7466a0cd579199ddcd Author: Ben Hutchings Date: Fri Oct 22 04:38:26 2010 +0000 net: NETIF_F_HW_CSUM does not imply FCoE CRC offload commit 66c68bcc489fadd4f5e8839e966e3a366e50d1d5 upstream. NETIF_F_HW_CSUM indicates the ability to update an TCP/IP-style 16-bit checksum with the checksum of an arbitrary part of the packet data, whereas the FCoE CRC is something entirely different. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit cdae69720bf88450fabc93f1e2ded4a8e53b8dd4 Author: Dan Rosenberg Date: Thu Sep 30 15:15:31 2010 -0700 sys_semctl: fix kernel stack leakage commit 982f7c2b2e6a28f8f266e075d92e19c0dd4c6e56 upstream. The semctl syscall has several code paths that lead to the leakage of uninitialized kernel stack memory (namely the IPC_INFO, SEM_INFO, IPC_STAT, and SEM_STAT commands) during the use of the older, obsolete version of the semid_ds struct. The copy_semid_to_user() function declares a semid_ds struct on the stack and copies it back to the user without initializing or zeroing the "sem_base", "sem_pending", "sem_pending_last", and "undo" pointers, allowing the leakage of 16 bytes of kernel stack memory. The code is still reachable on 32-bit systems - when calling semctl() newer glibc's automatically OR the IPC command with the IPC_64 flag, but invoking the syscall directly allows users to use the older versions of the struct. Signed-off-by: Dan Rosenberg Cc: Manfred Spraul Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 3a0d44ddfa469f86c16c8daf005a372b19ea1f9e Author: Vasiliy Kulikov Date: Sat Oct 30 18:22:49 2010 +0400 ipc: shm: fix information leak to userland commit 3af54c9bd9e6f14f896aac1bb0e8405ae0bc7a44 upstream. The shmid_ds structure is copied to userland with shm_unused{,2,3} fields unitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by: Vasiliy Kulikov Acked-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 5819449cad881107f3fd52025b7a0f5134ab1c85 Author: Dan Rosenberg Date: Wed Oct 27 15:34:17 2010 -0700 ipc: initialize structure memory to zero for compat functions commit 03145beb455cf5c20a761e8451e30b8a74ba58d9 upstream. This takes care of leaking uninitialized kernel stack memory to userspace from non-zeroed fields in structs in compat ipc functions. Signed-off-by: Dan Rosenberg Cc: Manfred Spraul Cc: Arnd Bergmann Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 546b259bef0d2618f2a466a1a7e5678f245f3024 Author: Jeremy Fitzhardinge Date: Mon Nov 29 14:16:53 2010 -0800 xen: don't bother to stop other cpus on shutdown/reboot commit 31e323cca9d5c8afd372976c35a5d46192f540d1 upstream. Xen will shoot all the VCPUs when we do a shutdown hypercall, so there's no need to do it manually. In any case it will fail because all the IPI irqs have been pulled down by this point, so the cross-CPU calls will simply hang forever. Until change 76fac077db6b34e2c6383a7b4f3f4f7b7d06d8ce the function calls were not synchronously waited for, so this wasn't apparent. However after that change the calls became synchronous leading to a hang on shutdown on multi-VCPU guests. Signed-off-by: Jeremy Fitzhardinge Cc: Alok Kataria Signed-off-by: Paul Gortmaker commit f5d2e41b3187a6327a4414d6e90c3abd591b3338 Author: Ian Campbell Date: Fri Oct 8 16:59:12 2010 +0100 xen: ensure that all event channels start off bound to VCPU 0 commit b0097adeec27e30223c989561ab0f7aa60d1fe93 upstream. All event channels startbound to VCPU 0 so ensure that cpu_evtchn_mask is initialised to reflect this. Otherwise there is a race after registering an event channel but before the affinity is explicitly set where the event channel can be delivered. If this happens then the event channel remains pending in the L1 (evtchn_pending) array but is cleared in L2 (evtchn_pending_sel), this means the event channel cannot be reraised until another event channel happens to trigger the same L2 entry on that VCPU. sizeof(cpu_evtchn_mask(0))==sizeof(unsigned long*) which is not correct, and causes only the first 32 or 64 event channels (depending on architecture) to be initially bound to VCPU0. Use sizeof(struct cpu_evtchn_s) instead. Signed-off-by: Ian Campbell Cc: Jeremy Fitzhardinge Signed-off-by: Paul Gortmaker commit 9aaa25f7a5370fb7b7a22751bf2f0597873f294e Author: Robin@sgi.com Date: Wed Nov 24 12:56:59 2010 -0800 sgi-xpc: XPC fails to discover partitions with all nasids above 128 commit c22c7aeff69796f46ae0fcec141538e28f50b24e upstream. UV hardware defines 256 memory protection regions versus the baseline 64 with increasing size for the SN2 ia64. This was overlooked when XPC was modified to accomodate both UV and SN2. Without this patch, a user could reconfigure their existing system and suddenly disable cross-partition communications with no indication of what has gone wrong. It also prevents larger configurations from using cross-partition communication. Signed-off-by: Robin Holt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 23f0f34ecaa0d562efdd01aa686fcecb2d7c0895 Author: Daniel Klaffenbach Date: Fri Nov 19 21:25:21 2010 -0600 ssb: b43-pci-bridge: Add new vendor for BCM4318 commit 1d8638d4038eb8709edc80e37a0bbb77253d86e9 upstream. Add new vendor for Broadcom 4318. Signed-off-by: Daniel Klaffenbach Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit a2ce4c7adab188c103bc16b98f49bd4a39363c13 Author: KAMEZAWA Hiroyuki Date: Tue Oct 26 14:22:08 2010 -0700 mm: fix is_mem_section_removable() page_order BUG_ON check commit 572438f9b52236bd8938b1647cc15e027d27ef55 upstream. page_order() is called by memory hotplug's user interface to check the section is removable or not. (is_mem_section_removable()) It calls page_order() withoug holding zone->lock. So, even if the caller does if (PageBuddy(page)) ret = page_order(page) ... The caller may hit BUG_ON(). For fixing this, there are 2 choices. 1. add zone->lock. 2. remove BUG_ON(). is_mem_section_removable() is used for some "advice" and doesn't need to be 100% accurate. This is_removable() can be called via user program.. We don't want to take this important lock for long by user's request. So, this patch removes BUG_ON(). Signed-off-by: KAMEZAWA Hiroyuki Acked-by: Wu Fengguang Acked-by: Michal Hocko Acked-by: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 59f0dd162547c16a1c9d71aa7cbfee76946b5c69 Author: KAMEZAWA Hiroyuki Date: Tue Oct 26 14:21:10 2010 -0700 mm: fix return value of scan_lru_pages in memory unplug commit f8f72ad5396987e05a42cf7eff826fb2a15ff148 upstream. scan_lru_pages returns pfn. So, it's type should be "unsigned long" not "int". Note: I guess this has been work until now because memory hotplug tester's machine has not very big memory.... physical address < 32bit << PAGE_SHIFT. Reported-by: KOSAKI Motohiro Signed-off-by: KAMEZAWA Hiroyuki Reviewed-by: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit fda7ec6e6ad2dd5783180cf5ffdd3d2837155aa5 Author: Jean Delvare Date: Thu Oct 28 20:31:50 2010 +0200 hwmon: (lm85) Fix ADT7468 frequency table commit fa7a5797e57d2ed71f9a6fb44f0ae42c2d7b74b7 upstream. The ADT7468 uses the same frequency table as the ADT7463. Signed-off-by: Jean Delvare Cc: Darrick J. Wong Acked-by: Guenter Roeck Signed-off-by: Paul Gortmaker commit 145b1684903c60ec5a43247ea06b6fd6dd25a76e Author: Eric Dumazet Date: Wed Oct 27 19:33:43 2010 +0200 numa: fix slab_node(MPOL_BIND) commit 800416f799e0723635ac2d720ad4449917a1481c upstream. When a node contains only HighMem memory, slab_node(MPOL_BIND) dereferences a NULL pointer. [ This code seems to go back all the way to commit 19770b32609b: "mm: filter based on a nodemask as well as a gfp_mask". Which was back in April 2008, and it got merged into 2.6.26. - Linus ] Signed-off-by: Eric Dumazet Cc: Mel Gorman Cc: Christoph Lameter Cc: Lee Schermerhorn Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit e0f3b803d74277677697bdf5b5e4c28766cfbc93 Author: Richard Weinberger Date: Tue Oct 26 14:21:13 2010 -0700 um: fix global timer issue when using CONFIG_NO_HZ commit 482db6df1746c4fa7d64a2441d4cb2610249c679 upstream. This fixes a issue which was introduced by fe2cc53e ("uml: track and make up lost ticks"). timeval_to_ns() returns long long and not int. Due to that UML's timer did not work properlt and caused timer freezes. Signed-off-by: Richard Weinberger Acked-by: Pekka Enberg Cc: Jeff Dike Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit ba9a34697b3fa012d29e51eb61bee160d2d55a4b Author: Richard Weinberger Date: Tue Oct 26 14:21:16 2010 -0700 um: remove PAGE_SIZE alignment in linker script causing kernel segfault. commit 6915e04f8847bea16d0890f559694ad8eedd026c upstream. The linker script cleanup that I did in commit 5d150a97f93 ("um: Clean up linker script using standard macros.") (2.6.32) accidentally introduced an ALIGN(PAGE_SIZE) when converting to use INIT_TEXT_SECTION; Richard Weinberger reported that this causes the kernel to segfault with CONFIG_STATIC_LINK=y. I'm not certain why this extra alignment is a problem, but it seems likely it is because previously __init_begin = _stext = _text = _sinittext and with the extra ALIGN(PAGE_SIZE), _sinittext becomes different from the rest. So there is likely a bug here where something is assuming that _sinittext is the same as one of those other symbols. But reverting the accidental change fixes the regression, so it seems worth committing that now. Signed-off-by: Tim Abbott Reported-by: Richard Weinberger Cc: Jeff Dike Tested by: Antoine Martin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 87005f9d0c7fa2c9c7a7ea7bc4b25c57d723de07 Author: Masanori ITOH Date: Tue Oct 26 14:21:20 2010 -0700 percpu: fix list_head init bug in __percpu_counter_init() commit 8474b591faf3bb0a1e08a60d21d6baac498f15e4 upstream. WARNING: at lib/list_debug.c:26 __list_add+0x3f/0x81() Hardware name: Express5800/B120a [N8400-085] list_add corruption. next->prev should be prev (ffffffff81a7ea00), but was dead000000200200. (next=ffff88080b872d58). Modules linked in: aoe ipt_MASQUERADE iptable_nat nf_nat autofs4 sunrpc bridge 8021q garp stp llc ipv6 cpufreq_ondemand acpi_cpufreq freq_table dm_round_robin dm_multipath kvm_intel kvm uinput lpfc scsi_transport_fc igb ioatdma scsi_tgt i2c_i801 i2c_core dca iTCO_wdt iTCO_vendor_support pcspkr shpchp megaraid_sas [last unloaded: aoe] Pid: 54, comm: events/3 Tainted: G W 2.6.34-vanilla1 #1 Call Trace: [] warn_slowpath_common+0x7c/0x94 [] warn_slowpath_fmt+0x41/0x43 [] __list_add+0x3f/0x81 [] __percpu_counter_init+0x59/0x6b [] bdi_init+0x118/0x17e [] blk_alloc_queue_node+0x79/0x143 [] blk_alloc_queue+0x11/0x13 [] aoeblk_gdalloc+0x8e/0x1c9 [aoe] [] aoecmd_sleepwork+0x25/0xa8 [aoe] [] worker_thread+0x1a9/0x237 [] ? aoecmd_sleepwork+0x0/0xa8 [aoe] [] ? autoremove_wake_function+0x0/0x39 [] ? worker_thread+0x0/0x237 [] kthread+0x7f/0x87 [] kernel_thread_helper+0x4/0x10 [] ? kthread+0x0/0x87 [] ? kernel_thread_helper+0x0/0x10 It's because there is no initialization code for a list_head contained in the struct backing_dev_info under CONFIG_HOTPLUG_CPU, and the bug comes up when block device drivers calling blk_alloc_queue() are used. In case of me, I got them by using aoe. Signed-off-by: Masanori Itoh Cc: Tejun Heo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 0c1eb7f6268985829019b8b12b4022ea2ffaf9cb Author: Richard A. Smith Date: Sat Sep 25 19:19:26 2010 +0100 olpc_battery: Fix endian neutral breakage for s16 values commit 7cfbb29466633e6ecdc14f76a693c8478c2b22af upstream. When the driver was updated to be endian neutral (8e9c7716c) the signed part of the s16 values was lost. This is because be16_to_cpu() returns an unsigned value. This patch casts the values back to a s16 number prior to the the implicit cast up to an int. Signed-off-by: Richard A. Smith Signed-off-by: Daniel Drake Signed-off-by: Anton Vorontsov Signed-off-by: Paul Gortmaker commit c04aca21602d0e28f475e3ad5a87abe52ef1754d Author: Jiri Slaby Date: Tue Oct 26 14:22:11 2010 -0700 hpet: unmap unused I/O space commit a56d5318716d120e040294bb258901ba89fb9c90 upstream. When the initialization code in hpet finds a memory resource and does not find an IRQ, it does not unmap the memory resource previously mapped. There are buggy BIOSes which report resources exactly like this and what is worse the memory region bases point to normal RAM. This normally would not matter since the space is not touched. But when PAT is turned on, ioremap causes the page to be uncached and sets this bit in page->flags. Then when the page is about to be used by the allocator, it is reported as: BUG: Bad page state in process md5sum pfn:3ed00 page:ffffea0000dbd800 count:0 mapcount:0 mapping:(null) index:0x0 page flags: 0x20000001000000(uncached) Pid: 7956, comm: md5sum Not tainted 2.6.34-12-desktop #1 Call Trace: [] bad_page+0xb1/0x100 [] prep_new_page+0x1a5/0x1c0 [] get_page_from_freelist+0x3a1/0x640 [] __alloc_pages_nodemask+0x10f/0x6b0 ... In this particular case: 1) HPET returns 3ed00000 as memory region base, but it is not in reserved ranges reported by the BIOS (excerpt): BIOS-e820: 0000000000100000 - 00000000af6cf000 (usable) BIOS-e820: 00000000af6cf000 - 00000000afdcf000 (reserved) 2) there is no IRQ resource reported by HPET method. On the other hand, the Intel HPET specs (1.0a) says (3.2.5.1): _CRS ( // Report 1K of memory consumed by this Timer Block memory range consumed // Optional: only used if BIOS allocates Interrupts [1] IRQs consumed ) [1] For case where Timer Block is configured to consume IRQ0/IRQ8 AND Legacy 8254/Legacy RTC hardware still exists, the device objects associated with 8254 & RTC devices should not report IRQ0/IRQ8 as "consumed resources". So in theory we should check whether if it is the case and use those interrupts instead. Anyway the address reported by the BIOS here is bogus, so non-presence of IRQ doesn't mean the "optional" part in point 2). Since I got no reply previously, fix this by simply unmapping the space when IRQ is not found and memory region was mapped previously. It would be probably more safe to walk the resources again and unmap appropriately depending on type. But as we now use only ioremap for both 2 memory resource types, it is not necessarily needed right now. Addresses https://bugzilla.novell.com/show_bug.cgi?id=629908 Reported-by: Olaf Hering Signed-off-by: Jiri Slaby Acked-by: Clemens Ladisch Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 37afea012a4862959cfc45ecfbc861d12882bb2e Author: Clemens Ladisch Date: Tue Oct 26 14:22:13 2010 -0700 hpet: fix unwanted interrupt due to stale irq status bit commit 96e9694df446d1154ec2f4fdba8908588b9cba38 upstream. Jaswinder Singh Rajput wrote: > By executing Documentation/timers/hpet_example.c > > for polling, I requested for 3 iterations but it seems iteration work > for only 2 as first expired time is always very small. > > # ./hpet_example poll /dev/hpet 10 3 > -hpet: executing poll > hpet_poll: info.hi_flags 0x0 > hpet_poll: expired time = 0x13 > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 > hpet_poll: expired time = 0x1868c > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 > hpet_poll: expired time = 0x18645 > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 Clearing the HPET interrupt enable bit disables interrupt generation but does not disable the timer, so the interrupt status bit will still be set when the timer elapses. If another interrupt arrives before the timer has been correctly programmed (due to some other device on the same interrupt line, or CONFIG_DEBUG_SHIRQ), this results in an extra unwanted interrupt event because the status bit is likely to be set from comparator matches that happened before the device was opened. Therefore, we have to ensure that the interrupt status bit is and stays cleared until we actually program the timer. Signed-off-by: Clemens Ladisch Reported-by: Jaswinder Singh Rajput Cc: Ingo Molnar Cc: Thomas Gleixner Cc: john stultz Cc: Bob Picco Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit bebd5cbf902c9e2408bc01131e59f1b43f43164d Author: Greg Kroah-Hartman Date: Thu Nov 18 11:21:04 2010 -0800 Staging: line6: fix up my fixup for some sysfs attribute permissions commit a3a972a053010bfd61c13cfa4ce688d4eebd9a19 upstream They should be writable by root, not readable. Doh, stupid me with the wrong flags. [PG: 34 doesn't have the DEVICE_ATTR chunk in pcm.c so drop that chunk] Reported-by: Jonathan Cameron Cc: Markus Grabner Cc: Mariusz Kozlowski Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 2b210ce58826b02072c294a4cd4a8ed522773a5a Author: Greg Kroah-Hartman Date: Tue Nov 16 11:23:33 2010 -0800 Staging: line6: fix up some sysfs attribute permissions commit 2018845b6a169f75341f8e68ad1089cb6697cf24 upstream They should not be writable by any user [PG: 34 doesn't have the DEVICE_ATTR chunk in pcm.c so drop that chunk] Reported-by: Linus Torvalds Cc: Markus Grabner Cc: Mariusz Kozlowski Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 81080da1fe907c5ae770d9a5ac42e03d97307995 Author: Greg Kroah-Hartman Date: Thu Nov 18 11:21:04 2010 -0800 Staging: asus_oled: fix up my fixup for some sysfs attribute permissions commit 515b4987ccd097cdf5416530b05fdf9e01afe95a upstream. They should be writable by root, not readable. Doh, stupid me with the wrong flags. Reported-by: Jonathan Cameron Cc: Jakub Schmidtke Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 98c003d98f3433da47f8e07f091d39d849cb68f5 Author: Greg Kroah-Hartman Date: Tue Nov 16 11:17:01 2010 -0800 Staging: asus_oled: fix up some sysfs attribute permissions commit 590b0b9754bd8928926bae7194b6da7ead9bda3b upstream. They should not be writable by any user Reported-by: Linus Torvalds Cc: Jakub Schmidtke Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 5fdf1fe64e1713adaccb5c9e7151a1ff3fda2db1 Author: Kees Cook Date: Thu Oct 7 10:03:48 2010 +0000 net: clear heap allocation for ETHTOOL_GRXCLSRLALL commit ae6df5f96a51818d6376da5307d773baeece4014 upstream. Calling ETHTOOL_GRXCLSRLALL with a large rule_cnt will allocate kernel heap without clearing it. For the one driver (niu) that implements it, it will leave the unused portion of heap unchanged and copy the full contents back to userspace. Signed-off-by: Kees Cook Acked-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 7f455daeb1a1c97fc94669af41def9386e426c6f Author: Thomas Backlund Date: Thu Oct 21 13:19:10 2010 +0300 microblaze: Fix build with make 3.82 commit b843e4ec01991a386a9e0e9030703524446e03da upstream. When running make headers_install_all on x86_64 and make 3.82 I hit this: arch/microblaze/Makefile:80: *** mixed implicit and normal rules. Stop. make: *** [headers_install_all] Error 2 So split the rules to satisfy make 3.82. Signed-off-by: Thomas Backlund Signed-off-by: Michal Simek Signed-off-by: Paul Gortmaker commit 06b5b28644d92e9de4658d98d9e0aaa6599f029d Author: Nobuhiro Iwamatsu Date: Sun Oct 24 18:16:57 2010 +0200 i2c-pca-platform: Change device name of request_irq commit 323584436db0cb05286425d4dfd9516fce88487f upstream. i2c->adap.name shouldn't be used in request_irq. Instead the driver name "i2c-pca-platform" should be used. Signed-off-by: Nobuhiro Iwamatsu Acked-by: Wolfram Sang Signed-off-by: Jean Delvare Signed-off-by: Paul Gortmaker commit 8e802130e66784de2f787f65210ae17a16aa2333 Author: Samuel Ortiz Date: Wed Oct 6 01:03:12 2010 +0200 irda: Fix heap memory corruption in iriap.c commit 37f9fc452d138dfc4da2ee1ce5ae85094efc3606 upstream. While parsing the GetValuebyClass command frame, we could potentially write passed the skb->data pointer. Reported-by: Ilja Van Sprundel Signed-off-by: Samuel Ortiz Signed-off-by: Paul Gortmaker commit 7cd4f61e763274397f2ccf147a4b3ae2056fca99 Author: Samuel Ortiz Date: Mon Oct 11 01:17:56 2010 +0200 irda: Fix parameter extraction stack overflow commit efc463eb508798da4243625b08c7396462cabf9f upstream. Reported-by: Ilja Van Sprundel Signed-off-by: Samuel Ortiz Signed-off-by: Paul Gortmaker commit 6e00c36efee7e04e297b257b5c5c5291cac18f1c Author: Guo-Fu Tseng Date: Mon Oct 18 14:10:40 2010 +0000 jme: Fix PHY power-off error commit c8a8684d5cfb0f110a962c93586630c0bf91ebc1 upstream. Adding phy_on in opposition to phy_off. Signed-off-by: Guo-Fu Tseng Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 7e7a8e1a621e843c4fa0c4aaeea10cbb771ce725 Author: Jens Axboe Date: Fri Oct 29 08:10:18 2010 -0600 block: check for proper length of iov entries in blk_rq_map_user_iov() commit 9284bcf4e335e5f18a8bc7b26461c33ab60d0689 upstream. Ensure that we pass down properly validated iov segments before calling into the mapping or copy functions. Reported-by: Dan Rosenberg Signed-off-by: Jens Axboe Signed-off-by: Paul Gortmaker commit 261426797bf22722259535b172fdea558eaa5387 Author: Jens Axboe Date: Fri Oct 29 11:31:42 2010 -0600 block: take care not to overflow when calculating total iov length commit 9f864c80913467312c7b8690e41fb5ebd1b50e92 upstream. Reported-by: Dan Rosenberg Signed-off-by: Jens Axboe Signed-off-by: Paul Gortmaker commit c0c525ff5cd13e0fc9ae8381e0bc051451b63e3e Author: Jens Axboe Date: Fri Oct 29 11:46:56 2010 -0600 block: limit vec count in bio_kmalloc() and bio_alloc_map_data() commit f3f63c1c28bc861a931fac283b5bc3585efb8967 upstream. Reported-by: Dan Rosenberg Signed-off-by: Jens Axboe Signed-off-by: Paul Gortmaker commit 83b91b90a917b3b32b144374174172a3c2eb450b Author: Martin K. Petersen Date: Wed Oct 13 21:18:03 2010 +0200 block: Ensure physical block size is unsigned int commit 892b6f90db81cccb723d5d92f4fddc2d68b206e1 upstream. Physical block size was declared unsigned int to accomodate the maximum size reported by READ CAPACITY(16). Make sure we use the right type in the related functions. Signed-off-by: Martin K. Petersen Acked-by: Mike Snitzer Signed-off-by: Jens Axboe Signed-off-by: Paul Gortmaker commit d31804aaf4b2e6f182f64d9706cf4d52e3350229 Author: Eric Dumazet Date: Wed Sep 8 05:08:44 2010 +0000 udp: add rehash on connect() commit 719f835853a92f6090258114a72ffe41f09155cd upstream commit 30fff923 introduced in linux-2.6.33 (udp: bind() optimisation) added a secondary hash on UDP, hashed on (local addr, local port). Problem is that following sequence : fd = socket(...) connect(fd, &remote, ...) not only selects remote end point (address and port), but also sets local address, while UDP stack stored in secondary hash table the socket while its local address was INADDR_ANY (or ipv6 equivalent) Sequence is : - autobind() : choose a random local port, insert socket in hash tables [while local address is INADDR_ANY] - connect() : set remote address and port, change local address to IP given by a route lookup. When an incoming UDP frame comes, if more than 10 sockets are found in primary hash table, we switch to secondary table, and fail to find socket because its local address changed. One solution to this problem is to rehash datagram socket if needed. We add a new rehash(struct socket *) method in "struct proto", and implement this method for UDP v4 & v6, using a common helper. This rehashing only takes care of secondary hash table, since primary hash (based on local port only) is not changed. Reported-by: Krzysztof Piotr Oledzki Signed-off-by: Eric Dumazet Tested-by: Krzysztof Piotr Oledzki Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 17f7778809d4485ad1fecf0cf4dc1300aa853188 Author: Alexander Shishkin Date: Thu Jun 3 20:53:43 2010 +1000 crypto: testmgr - add an option to disable cryptoalgos' self-tests commit 0b767f96164b2b27488e3daa722ff16e89d49314 upstream. By default, CONFIG_CRYPTO_MANAGER_TESTS will be enabled and thus self-tests will still run, but it is now possible to disable them to gain some time during bootup. Signed-off-by: Alexander Shishkin Signed-off-by: Herbert Xu Signed-off-by: Paul Gortmaker commit 2a87e7338c6f836a88da9b1c3ca568b87df5dfa6 Author: Philipp Reisner Date: Tue Jun 29 17:35:34 2010 +0200 drbd: Initialize all members of sync_conf to their defaults [Bugz 315] commit 85f4cc17a62c3ac9edeaf120cdae7261df458053 upstream. [PG: remove fields volume, interval, throttle, hold_off; not in 34] Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg Signed-off-by: Jens Axboe Signed-off-by: Paul Gortmaker commit 0068c623f6fd0630176e224bf929dff4852b5580 Author: Al Viro Date: Mon Aug 9 12:05:43 2010 -0400 Fix sget() race with failing mount commit 7a4dec53897ecd3367efb1e12fe8a4edc47dc0e9 upstream. If sget() finds a matching superblock being set up, it'll grab an active reference to it and grab s_umount. That's fine - we'll wait for completion of foofs_get_sb() that way. However, if said foofs_get_sb() fails we'll end up holding the halfway-created superblock. deactivate_locked_super() called by foofs_get_sb() will just unlock the sucker since we are holding another active reference to it. What we need is a way to tell if superblock has been successfully set up. Unfortunately, neither ->s_root nor the check for MS_ACTIVE quite fit. Cheap and easy way, suitable for backport: new flag set by the (only) caller of ->get_sb(). If that flag isn't present by the time sget() grabbed s_umount on preexisting superblock it has found, it's seeing a stillborn and should just bury it with deactivate_locked_super() (and repeat the search). Longer term we want to set that flag in ->get_sb() instances (and check for it to distinguish between "sget() found us a live sb" and "sget() has allocated an sb, we need to set it up" in there, instead of checking ->s_root as we do now). Signed-off-by: Al Viro Signed-off-by: Paul Gortmaker commit 84c3758d0d4ce1b0f0eea55b1b20a4e9a0a6a792 Author: Dan Williams Date: Fri Jul 23 15:47:56 2010 -0700 ioat2: catch and recover from broken vtd configurations v6 commit 556ab45f9a775bfa4762bacc0a4afb5b44b067bc upstream. On some platforms (MacPro3,1) the BIOS assigns the ioatdma device to the incorrect iommu causing faults when the driver initializes. Add a quirk to catch this misconfiguration and try falling back to untranslated operation (which works in the MacPro3,1 case). Assuming there are other platforms with misconfigured iommus teach the ioatdma driver to treat initialization failures as non-fatal (just fail the driver load and emit a warning instead of triggering a BUG_ON). This can be classified as a boot regression since 2.6.32 on affected platforms since the ioatdma module did not autoload prior to that kernel. [PG: 34 has no WARN_TAINT_ONCE, use WARN_ONCE instead] Acked-by: David Woodhouse Reported-by: Chris Li Tested-by: Chris Li Signed-off-by: Dan Williams Signed-off-by: Paul Gortmaker commit 98604bb6bbb27ef5ec27e46f9a6155635a05e856 Author: Jeff Kirsher Date: Sun Aug 8 16:02:31 2010 +0000 e100/e1000*/igb*/ixgb*: Add missing read memory barrier commit 2d0bb1c1f4524befe9f0fcf0d0cd3081a451223f upstream. Based on patches from Sonny Rao and Milton Miller... Combined the patches to fix up clean_tx_irq and clean_rx_irq. The PowerPC architecture does not require loads to independent bytes to be ordered without adding an explicit barrier. In ixgbe_clean_rx_irq we load the status bit then load the packet data. With packet split disabled if these loads go out of order we get a stale packet, but we will notice the bad sequence numbers and drop it. The problem occurs with packet split enabled where the TCP/IP header and data are in different descriptors. If the reads go out of order we may have data that doesn't match the TCP/IP header. Since we use hardware checksumming this bad data is never verified and it makes it all the way to the application. This bug was found during stress testing and adding this barrier has been shown to fix it. The bug can manifest as a data integrity issue (bad payload data) or as a BUG in skb_pull(). This was a nasty bug to hunt down, if people agree with the fix I think it's a candidate for stable. Previously Submitted to e1000-devel only for ixgbe http://marc.info/?l=e1000-devel&m=126593062701537&w=3 We've now seen this problem hit with other device drivers (e1000e mostly) So I'm resubmitting with fixes for other Intel Device Drivers with similar issues. CC: Milton Miller CC: Anton Blanchard CC: Sonny Rao Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 5b6ed42f7347cc8d8abcb647fd34f35bd0818843 Author: NeilBrown Date: Sun Aug 8 21:18:03 2010 +1000 md: fix another deadlock with removing sysfs attributes. commit bb4f1e9d0e2ef93de8e36ca0f5f26625fcd70b7d upstream. Move the deletion of sysfs attributes from reconfig_mutex to open_mutex didn't really help as a process can try to take open_mutex while holding reconfig_mutex, so the same deadlock can happen, just requiring one more process to be involved in the chain. I looks like I cannot easily use locking to wait for the sysfs deletion to complete, so don't. The only things that we cannot do while the deletions are still pending is other things which can change the sysfs namespace: run, takeover, stop. Each of these can fail with -EBUSY. So set a flag while doing a sysfs deletion, and fail run, takeover, stop if that flag is set. This is suitable for 2.6.35.x Signed-off-by: NeilBrown Signed-off-by: Paul Gortmaker commit d5cee63afcee9c14c47b7c5e0962abf2caf8d8c5 Author: Lytochkin Boris Date: Mon Jul 26 10:02:26 2010 +0400 serial: add support for OX16PCI958 card commit e847003f00d5eca3e3b3a6a1199f82b51293faf6 upstream. Signed-off-by: Lytochkin Boris Tested-by: Lytochkin Boris Signed-off-by: Alexander Beregalov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit b549001b9fd18185a05c345a4804c5e24518ce26 Author: Chris Wilson Date: Fri Jul 9 08:45:04 2010 +0100 drm/i915: Unset cursor if out-of-bounds upon mode change (v4) commit cda4b7d3a5b1dcbc0d8e7bad52134347798e9047 upstream. The docs warn that to position the cursor such that no part of it is visible on the pipe is an undefined operation. Avoid such circumstances upon changing the mode, or at any other time, by unsetting the cursor if it moves out of bounds. "For normal high resolution display modes, the cursor must have at least a single pixel positioned over the active screen.” (p143, p148 of the hardware registers docs). Fixes: Bug 24748 - [965G] Graphics crashes when resolution is changed with KMS enabled https://bugs.freedesktop.org/show_bug.cgi?id=24748 v2: Only update the cursor registers if they change. v3: Fix the unsigned comparision of x,y against width,height. v4: Always set CUR.BASE or else the cursor may become corrupt. Signed-off-by: Chris Wilson Reported-by: Christian Eggers Cc: Christopher James Halse Rogers Signed-off-by: Eric Anholt Signed-off-by: Paul Gortmaker commit 560b011ec7e83125dca7f8051d8df19b0e4aee4b Author: Alex Deucher Date: Mon Aug 2 12:13:46 2010 -0400 drm/radeon/kms: handle the case of no active displays properly in the bandwidth code commit e06b14ee91a2ddefc9a67443a6cd8ee0fa800115 upstream. Logic was: if (mode0 && mode1) else if (mode0) else Should be: if (mode0 && mode1) else if (mode0) else if (mode1) Otherwise we may end up calculating the priority regs with unitialized values. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=16492 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Paul Gortmaker commit fbeb7b139b2ff0a249dbb816f9efa6bb80927ef2 Author: Michel Dänzer Date: Thu Jul 8 12:43:28 2010 +1000 drm/radeon: fall back to GTT if bo creation/validation in VRAM fails. commit e376573f7267390f4e1bdc552564b6fb913bce76 upstream. This fixes a problem where on low VRAM cards we'd run out of space for validation. [airlied: Tested on my M7, Thinkpad T42, compiz works with no problems.] Signed-off-by: Michel Dänzer Signed-off-by: Dave Airlie Signed-off-by: Paul Gortmaker commit 67f14263a5cf005b0f84aa520e921fed079b15d7 Author: David Howells Date: Wed Aug 4 16:59:14 2010 +0100 CRED: Fix RCU warning due to previous patch fixing __task_cred()'s checks commit 694f690d27dadccc8cb9d90532e76593b61fe098 upstream. Commit 8f92054e7ca1 ("CRED: Fix __task_cred()'s lockdep check and banner comment") fixed the lockdep checks on __task_cred(). This has shown up a place in the signalling code where a lock should be held - namely that check_kill_permission() requires its callers to hold the RCU lock. Fix group_send_sig_info() to get the RCU read lock around its call to check_kill_permission(). Without this patch, the following warning can occur: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- kernel/signal.c:660 invoked rcu_dereference_check() without protection! ... Reported-by: Tetsuo Handa Signed-off-by: David Howells Acked-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 07a30e8ffd9aaed5247278c2864cc0e45e393ee3 Author: Felix Fietkau Date: Sun Jul 11 12:48:39 2010 +0200 ath9k_hw: fix antenna diversity on AR9285 commit 601e0cb165e65dc185b31fe7ebd2c0169ea47306 upstream. On AR9285, the antenna switch configuration register uses more than just 16 bits. Because of an arbitrary mask applied to the EEPROM value that stores this configuration, diversity was broken in some cases, leading to a significant degradation in signal strength. Fix this by changing the callback to return a 32 bit value and remove the arbitrary mask. [PG: drop ar9003_eeprom.c change; v2.6.34 doesn't have it yet] Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit 88fe50e62b5327f0ab16aace289015cbb94982bd Author: Felix Fietkau Date: Fri Jun 25 01:26:16 2010 +0200 ath9k: fix retry count for A-MPDU rate control status reports commit 78c4653a2274479547e259e1f416d2b3d04c42a8 upstream. The 'bf_retries' field of the ath_buf structure was used for both software retries (AMPDU subframes) and hardware retries (legacy frames). This led to a wrong retry count being reported for the A-MPDU rate control stats. This patch changes the code to no longer use bf_retries for reporting retry counts, but instead always using the real on-chip retry count from the ath_tx_status. Additionally, if the first subframe of an A-MPDU was not acked, the tx status report is submitted along with the first acked subframe, which may not contain the correct rates in the tx info. This is easily corrected by saving the tx rate info before looping over subframes, and then copying it back once the A-MPDU status report is submitted. In my tests this change improves throughput visibly. [PG: 34 doesnt have ts as an alias for ds->ds_txstat, so change accordingly] Signed-off-by: Felix Fietkau Reported-by: Björn Smedman Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker