commit 376faec0f6faf74daa71b52fb57cff5214c2abf3 Author: Greg Kroah-Hartman Date: Fri Jan 7 15:08:43 2011 -0800 Linux 2.6.32.28 commit 76b04f23867fc0fa03affa4dfc528b89bf9fdb13 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: Greg Kroah-Hartman commit 6552df6df2fcfc281c64dea191fef144d5a188c5 Author: Vlad Yasevich Date: Thu May 6 00:56:07 2010 -0700 sctp: Fix a race between ICMP protocol unreachable and connect() commit 50b5d6ad63821cea324a5a7a19854d4de1a0a819 upstream. ICMP protocol unreachable handling completely disregarded the fact that the user may have locked the socket. It proceeded to destroy the association, even though the user may have held the lock and had a ref on the association. This resulted in the following: Attempt to release alive inet socket f6afcc00 ========================= [ BUG: held lock freed! ] ------------------------- somenu/2672 is freeing memory f6afcc00-f6afcfff, with a lock still held there! (sk_lock-AF_INET){+.+.+.}, at: [] sctp_connect+0x13/0x4c 1 lock held by somenu/2672: #0: (sk_lock-AF_INET){+.+.+.}, at: [] sctp_connect+0x13/0x4c stack backtrace: Pid: 2672, comm: somenu Not tainted 2.6.32-telco #55 Call Trace: [] ? printk+0xf/0x11 [] debug_check_no_locks_freed+0xce/0xff [] kmem_cache_free+0x21/0x66 [] __sk_free+0x9d/0xab [] sk_free+0x1c/0x1e [] sctp_association_put+0x32/0x89 [] __sctp_connect+0x36d/0x3f4 [] ? sctp_connect+0x13/0x4c [] ? autoremove_wake_function+0x0/0x33 [] sctp_connect+0x31/0x4c [] inet_dgram_connect+0x4b/0x55 [] sys_connect+0x54/0x71 [] ? lock_release_non_nested+0x88/0x239 [] ? might_fault+0x42/0x7c [] ? might_fault+0x42/0x7c [] sys_socketcall+0x6d/0x178 [] ? trace_hardirqs_on_thunk+0xc/0x10 [] syscall_call+0x7/0xb This was because the sctp_wait_for_connect() would aqcure the socket lock and then proceed to release the last reference count on the association, thus cause the fully destruction path to finish freeing the socket. The simplest solution is to start a very short timer in case the socket is owned by user. When the timer expires, we can do some verification and be able to do the release properly. Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dce52eace914029693bdc2ceed5c71d6690f67a4 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: Greg Kroah-Hartman commit 52cbcb0b0034941c3c05f5ac83d692f6ede79347 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: Greg Kroah-Hartman commit bb2896b1a7ea8e41bab1d5a58e4873051c618e3c Author: Daniel T Chen Date: Wed Mar 3 18:24:26 2010 -0500 ALSA: hda: Use LPIB for Dell Latitude 131L commit 9919c7619c52d01e89103bca405cc3d4a2b1ac31 upstream. BugLink: https://launchpad.net/bugs/530346 The OR has verified that position_fix=1 is necessary to work around errors on his machine. Reported-by: Tom Louwrier Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai commit a19e760f1664050e4bf31ad3af8a28c308e0ae72 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: Greg Kroah-Hartman commit 9e180aacc3563130dc34b725a6e595d46c1906f9 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: Greg Kroah-Hartman commit 815fc814077615de661c902b0dab82c3609373f1 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: Greg Kroah-Hartman commit e3220459813fb6395809bbdb12f87cace16e315f 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: Greg Kroah-Hartman commit 302ead99606224610d245f80fa7302ccf03ca20a 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: Greg Kroah-Hartman commit ce9153b9254caa40c17c7894a7eac90989520c13 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 Signed-off-by: Vitaly Kuznetsov Acked-by: Alan Stern CC: Matthew Dharm Signed-off-by: Greg Kroah-Hartman commit b881b35735ccfd8d1e4b13753e5b9683d55c2467 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 commit 14084f5b87b5eacc93a318876bc1d81202b9188f 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 commit 6c2cde9c2835cfd03daa039f3e9742aa17c3d0e5 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: Greg Kroah-Hartman commit 60a517cab5e8885d8873bfa3acc2a138fbb7fb9c Author: Krishna Kumar Date: Wed Dec 9 20:59:58 2009 +0000 net: release dst entry while cache-hot for GSO case too commit 068a2de57ddf4f472e32e7af868613c574ad1d88 upstream. Non-GSO code drops dst entry for performance reasons, but the same is missing for GSO code. Drop dst while cache-hot for GSO case too. Signed-off-by: Krishna Kumar Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Andrey Vagin Signed-off-by: Greg Kroah-Hartman commit 8edb98f38b17e10d64f87b0eafd2612597896a82 Author: Alexander Duyck Date: Tue Mar 23 18:35:18 2010 +0000 igb: only use vlan_gro_receive if vlans are registered commit 31b24b955c3ebbb6f3008a6374e61cf7c05a193c upstream. This change makes it so that vlan_gro_receive is only used if vlans have been registered to the adapter structure. Previously we were just sending all vlan tagged frames in via this function but this results in a null pointer dereference when vlans are not registered. [ This fixes bugzilla entry 15582 -Eric Dumazet] Signed-off-by: Alexander Duyck Signed-off-by: Jeff Kirsher Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit da53fa015ad6242ca95ee48c62feaf9cf1084bd2 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: Greg Kroah-Hartman commit 32aba3cf35c2fd0dde82d1acac9c76424f576c67 Author: Jiri Slaby Date: Tue Oct 19 11:29:55 2010 +0200 HID: hidraw: fix window in hidraw_release commit cb174681a9ececa6702f114b85bdf82144b6a5af upstream. [ Backport to .32.y by Antonio Ospite ] 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. Signed-off-by: Jiri Slaby Signed-off-by: Jiri Kosina Signed-off-by: Antonio Ospite Signed-off-by: Greg Kroah-Hartman commit ec955e326e90b693011f6429b4cc0a72fe795168 Author: Anton Blanchard Date: Tue Apr 6 21:42:38 2010 +1000 hvc_console: Fix race between hvc_close and hvc_remove, again commit 320718ee074acce5ffced6506cb51af1388942aa upstream. I don't claim to understand the tty layer, but it seems like hvc_open and hvc_close should be balanced in their kref reference counting. Right now we get a kref every call to hvc_open: if (hp->count++ > 0) { tty_kref_get(tty); <----- here spin_unlock_irqrestore(&hp->lock, flags); hvc_kick(); return 0; } /* else count == 0 */ tty->driver_data = hp; hp->tty = tty_kref_get(tty); <------ or here if hp->count was 0 But hvc_close has: tty_kref_get(tty); if (--hp->count == 0) { ... /* Put the ref obtained in hvc_open() */ tty_kref_put(tty); ... } tty_kref_put(tty); Since the outside kref get/put balance we only do a single kref_put when count reaches 0. The patch below changes things to call tty_kref_put once for every hvc_close call, and with that my machine boots fine. Signed-off-by: Anton Blanchard Acked-by: Amit Shah Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit ef5ce99dff0b45abd4563de36c0bc32ba00ae022 Author: Amit Shah Date: Fri Mar 12 11:53:15 2010 +0530 hvc_console: Fix race between hvc_close and hvc_remove commit e74d098c66543d0731de62eb747ccd5b636a6f4c upstream. Alan pointed out a race in the code where hvc_remove is invoked. The recent virtio_console work is the first user of hvc_remove(). Alan describes it thus: The hvc_console assumes that a close and remove call can't occur at the same time. In addition tty_hangup(tty) is problematic as tty_hangup is asynchronous itself.... So this can happen hvc_close hvc_remove hung up ? - no lock tty = hp->tty unlock lock hp->tty = NULL unlock notify del kref_put the hvc struct close completes tty is destroyed tty_hangup dead tty tty->ops will be NULL NULL->... This patch adds some tty krefs and also converts to using tty_vhangup(). Reported-by: Alan Cox Signed-off-by: Amit Shah CC: Alan Cox CC: linuxppc-dev@ozlabs.org CC: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit ef8a09c1bb359191583b131a3feb6d2b15d8e1a0 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: Greg Kroah-Hartman commit 38d63e89cdc06e5c8d3cca47932a9ada87ce48dd 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: Greg Kroah-Hartman commit 15b118dd1202875aa8e08e0506d53f56eeed84c1 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: Greg Kroah-Hartman commit 3e300d45b2802dfc7ba8ff7d02463857e718bc4f 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: Greg Kroah-Hartman commit ed215240d3a6a99573660e33e3034202368d025e 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: Greg Kroah-Hartman commit 43807eba1303b4b4606debd444f4fdc93ef560d7 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: Greg Kroah-Hartman commit 21f29a80fc8f7c399cb6f068ef01ec05a305ecfd 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: Greg Kroah-Hartman commit e1d55a0e3057b076a178af8438de1bda06ad3a2b Author: Andreas Herrmann Date: Thu Dec 16 21:29:37 2010 +0100 x86, amd: Fix panic on AMD CPU family 0x15 [The mainline kernel doesn't have this problem. Commit "(23588c3) x86, amd: Add support for CPUID topology extension of AMD CPUs" removed the family check. But 2.6.32.y needs to be fixed.] This CPU family check is not required -- existence of the NodeId MSR is indicated by a CPUID feature flag which is already checked in amd_fixup_dcm() -- and it needlessly prevents amd_fixup_dcm() to be called for newer AMD CPUs. In worst case this can lead to a panic in the scheduler code for AMD family 0x15 multi-node AMD CPUs. I just have a picture of VGA console output so I can't copy-and-paste it herein, but the call stack of such a panic looked like: do_divide_error ... find_busiest_group run_rebalance_domains ... apic_timer_interrupt ... cpu_idle The mainline kernel doesn't have this problem. Commit "(23588c3) x86, amd: Add support for CPUID topology extension of AMD CPUs" removed the family check. But 2.6.32.y needs to be fixed. Signed-off-by: Andreas Herrmann Signed-off-by: Greg Kroah-Hartman commit aeb109d32aa3286faffd4ac29e7649aac33194e3 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: Greg Kroah-Hartman commit 818b389b493752a3a1f4937c5a8d561c01452d16 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: Greg Kroah-Hartman commit c83f04f47266f1e13dfe0745c41286831d00c9ce 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: Greg Kroah-Hartman commit dda8b7b28fa749c7a815cc1a34188eb791b55c7d Author: Bob Moore Date: Sat Oct 23 01:36:40 2010 -0400 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: Greg Kroah-Hartman commit 012f9fdfd2965f573171f848d1aa46531cab7062 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: Greg Kroah-Hartman commit 4423917fd5ce23c4f78d34ea8cee3100f7361199 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: Greg Kroah-Hartman commit c756b7289be03cf4d8ee03e0300b418e65e3ff0d 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: Greg Kroah-Hartman commit e0d1e27d374c3248ff5b1da6dd052127216cd0da 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: Greg Kroah-Hartman commit e2e722ca8f05cf468f497bfb5387acca64633d0a 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: Greg Kroah-Hartman commit 7df3fe5e2fcac3f469c4a6d4c4a4c0f4c4020983 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: Greg Kroah-Hartman commit dd143426eaaadea159c8dd2d3c9ff5e9da94bcfd 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: Greg Kroah-Hartman commit 54cc1ed394a5fb6b6976597f0f0bc023e888f196 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: Greg Kroah-Hartman commit 22e20005d20239adc8c2ac2fb28db693602b470e 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: Greg Kroah-Hartman commit 4c3c55199aefa28fb657bd53d7b382fe464e33f5 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: Greg Kroah-Hartman commit 0a8eea5287cfd8bb464ae9d53bf51e2d2a677240 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: Greg Kroah-Hartman commit b17b3ee93479e6ae4977b559bbffd01892ba6360 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: Greg Kroah-Hartman commit f6ac0a1f3b89340257e9af095ae6f1135c9cc444 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: Greg Kroah-Hartman commit 9f68de59cbe6e5458d0b755ed0fc945fddfbc042 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: Greg Kroah-Hartman commit 326aa6201f5e61711e75979dc5022487a88fe548 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: Greg Kroah-Hartman commit 226917b0735f31cf5c704e07fdd590d99bbfae58 Author: H. Peter Anvin Date: Fri Dec 10 23:57:04 2010 -0500 x86, hotplug: Use mwait to offline a processor, fix the legacy case upstream ea53069231f9317062910d6e772cca4ce93de8c8 x86, hotplug: Use mwait to offline a processor, fix the legacy case Here included also some small follow-on patches to the same code: upstream a68e5c94f7d3dd64fef34dd5d97e365cae4bb42a x86, hotplug: Move WBINVD back outside the play_dead loop upstream ce5f68246bf2385d6174856708d0b746dc378f20 x86, hotplug: In the MWAIT case of play_dead, CLFLUSH the cache line https://bugzilla.kernel.org/show_bug.cgi?id=5471 Signed-off-by: H. Peter Anvin Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 6db0ed1582b1eae8b1120de4494cafc9635fdc3f Author: Ben Hutchings Date: Sat Dec 11 05:51:39 2010 +0000 TTY: Fix error return from tty_ldisc_open() The backported version of "TTY: ldisc, fix open flag handling" in 2.6.32.27 causes tty_ldisc_open() to return 0 on error. Fix that. Signed-off-by: Ben Hutchings Cc: Jiri Slaby Cc: Alan Cox Signed-off-by: Greg Kroah-Hartman