commit 51c9aee295b9e79a8311036847a20a704f2c7994 Author: Greg Kroah-Hartman Date: Sun Mar 4 09:49:44 2012 -0800 Linux 2.6.32.58 commit bf698b519721739568a34f7b301c2c7c51683d8e Author: Tetsuo Handa Date: Wed Feb 29 12:24:56 2012 +0530 PM / Sleep: Fix read_unlock_usermodehelper() call. [ Upstream commit e4c89a508f4385a0cd8681c2749a2cd2fa476e40 ] Commit b298d289 "PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()" added read_unlock_usermodehelper() but read_unlock_usermodehelper() is called without read_lock_usermodehelper() when kmalloc() failed. Signed-off-by: Tetsuo Handa Acked-by: Srivatsa S. Bhat Signed-off-by: Rafael J. Wysocki Signed-off-by: Srivatsa S. Bhat Signed-off-by: Greg Kroah-Hartman commit 0707a9cd9c31b1d831c459469387943978292ff4 Author: Srivatsa S. Bhat Date: Wed Feb 29 12:24:01 2012 +0530 PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled() [ Upstream commit b298d289c79211508f11cb50749b0d1d54eb244a ] Commit a144c6a (PM: Print a warning if firmware is requested when tasks are frozen) introduced usermodehelper_is_disabled() to warn and exit immediately if firmware is requested when usermodehelpers are disabled. However, it is racy. Consider the following scenario, currently used in drivers/base/firmware_class.c: ... if (usermodehelper_is_disabled()) goto out; /* Do actual work */ ... out: return err; Nothing prevents someone from disabling usermodehelpers just after the check in the 'if' condition, which means that it is quite possible to try doing the "actual work" with usermodehelpers disabled, leading to undesirable consequences. In particular, this race condition in _request_firmware() causes task freezing failures whenever suspend/hibernation is in progress because, it wrongly waits to get the firmware/microcode image from userspace when actually the usermodehelpers are disabled or userspace has been frozen. Some of the example scenarios that cause freezing failures due to this race are those that depend on userspace via request_firmware(), such as x86 microcode module initialization and microcode image reload. Previous discussions about this issue can be found at: http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591 This patch adds proper synchronization to fix this issue. It is to be noted that this patchset fixes the freezing failures but doesn't remove the warnings. IOW, it does not attempt to add explicit synchronization to x86 microcode driver to avoid requesting microcode image at inopportune moments. Because, the warnings were introduced to highlight such cases, in the first place. And we need not silence the warnings, since we take care of the *real* problem (freezing failure) and hence, after that, the warnings are pretty harmless anyway. Signed-off-by: Srivatsa S. Bhat Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 11dcbf06d8a58dbf13ca3098bc2a02660a341a8d Author: Linus Torvalds Date: Wed Feb 29 12:23:20 2012 +0530 firmware loader: allow builtin firmware load even if usermodehelper is disabled [ Upstream commit caca9510ff4e5d842c0589110243d60927836222 ] In commit a144c6a6c924 ("PM: Print a warning if firmware is requested when tasks are frozen") we not only printed a warning if somebody tried to load the firmware when tasks are frozen - we also failed the load. But that check was done before the check for built-in firmware, and then when we disallowed usermode helpers during bootup (commit 288d5abec831: "Boot up with usermodehelper disabled"), that actually means that built-in modules can no longer load their firmware even if the firmware is built in too. Which used to work, and some people depended on it for the R100 driver. So move the test for usermodehelper_is_disabled() down, to after checking the built-in firmware. This should fix: https://bugzilla.kernel.org/show_bug.cgi?id=40952 Reported-by: James Cloos Bisected-by: Elimar Riesebieter Cc: Michel Dänzer Cc: Rafael Wysocki Cc: Valdis Kletnieks Signed-off-by: Linus Torvalds Signed-off-by: Srivatsa S. Bhat Signed-off-by: Greg Kroah-Hartman commit 4e5c29cfbc26e6ebb93c54d1652f41d90d6a8843 Author: Rafael J. Wysocki Date: Wed Feb 29 12:22:41 2012 +0530 PM: Print a warning if firmware is requested when tasks are frozen [ Upstream commit a144c6a6c924aa1da04dd77fb84b89927354fdff ] Some drivers erroneously use request_firmware() from their ->resume() (or ->thaw(), or ->restore()) callbacks, which is not going to work unless the firmware has been built in. This causes system resume to stall until the firmware-loading timeout expires, which makes users think that the resume has failed and reboot their machines unnecessarily. For this reason, make _request_firmware() print a warning and return immediately with error code if it has been called when tasks are frozen and it's impossible to start any new usermode helpers. Signed-off-by: Rafael J. Wysocki Acked-by: Greg Kroah-Hartman Reviewed-by: Valdis Kletnieks Signed-off-by: Srivatsa S. Bhat Signed-off-by: Greg Kroah-Hartman commit 7fce3f2db5913f1fe1fbd4fddd4d3af274098006 Author: Heiko Carstens Date: Mon Feb 27 10:01:52 2012 +0100 compat: fix compile breakage on s390 commit 048cd4e51d24ebf7f3552226d03c769d6ad91658 upstream. The new is_compat_task() define for the !COMPAT case in include/linux/compat.h conflicts with a similar define in arch/s390/include/asm/compat.h. This is the minimal patch which fixes the build issues. Signed-off-by: Heiko Carstens Signed-off-by: Linus Torvalds Cc: Jonathan Nieder Signed-off-by: Greg Kroah-Hartman commit 25d10dda10aa6684c0a48c93a97a85181d53add9 Author: Linus Torvalds Date: Sun Feb 26 09:44:55 2012 -0800 Fix autofs compile without CONFIG_COMPAT commit 3c761ea05a8900a907f32b628611873f6bef24b2 upstream. The autofs compat handling fix caused a compile failure when CONFIG_COMPAT isn't defined. Instead of adding random #ifdef'fery in autofs, let's just make the compat helpers earlier to use: without CONFIG_COMPAT, is_compat_task() just hardcodes to zero. We could probably do something similar for a number of other cases where we have #ifdef's in code, but this is the low-hanging fruit. Reported-and-tested-by: Andreas Schwab Signed-off-by: Linus Torvalds Cc: Jonathan Nieder Signed-off-by: Greg Kroah-Hartman commit 82e43e2a64739caf323ac98641e1250c3808c300 Author: Ian Kent Date: Wed Feb 22 20:45:44 2012 +0800 autofs: work around unhappy compat problem on x86-64 commit a32744d4abae24572eff7269bc17895c41bd0085 upstream. When the autofs protocol version 5 packet type was added in commit 5c0a32fc2cd0 ("autofs4: add new packet type for v5 communications"), it obvously tried quite hard to be word-size agnostic, and uses explicitly sized fields that are all correctly aligned. However, with the final "char name[NAME_MAX+1]" array at the end, the actual size of the structure ends up being not very well defined: because the struct isn't marked 'packed', doing a "sizeof()" on it will align the size of the struct up to the biggest alignment of the members it has. And despite all the members being the same, the alignment of them is different: a "__u64" has 4-byte alignment on x86-32, but native 8-byte alignment on x86-64. And while 'NAME_MAX+1' ends up being a nice round number (256), the name[] array starts out a 4-byte aligned. End result: the "packed" size of the structure is 300 bytes: 4-byte, but not 8-byte aligned. As a result, despite all the fields being in the same place on all architectures, sizeof() will round up that size to 304 bytes on architectures that have 8-byte alignment for u64. Note that this is *not* a problem for 32-bit compat mode on POWER, since there __u64 is 8-byte aligned even in 32-bit mode. But on x86, 32-bit and 64-bit alignment is different for 64-bit entities, and as a result the structure that has exactly the same layout has different sizes. So on x86-64, but no other architecture, we will just subtract 4 from the size of the structure when running in a compat task. That way we will write the properly sized packet that user mode expects. Not pretty. Sadly, this very subtle, and unnecessary, size difference has been encoded in user space that wants to read packets of *exactly* the right size, and will refuse to touch anything else. Reported-and-tested-by: Thomas Meyer Signed-off-by: Ian Kent Signed-off-by: Linus Torvalds Cc: Jonathan Nieder Signed-off-by: Greg Kroah-Hartman commit 3e9d6c33830beee43dc1b94bdbff41109455fa58 Author: Dan Carpenter Date: Mon Feb 6 10:20:45 2012 +0100 cdrom: use copy_to_user() without the underscores commit 822bfa51ce44f2c63c300fdb76dc99c4d5a5ca9f upstream. "nframes" comes from the user and "nframes * CD_FRAMESIZE_RAW" can wrap on 32 bit systems. That would have been ok if we used the same wrapped value for the copy, but we use a shifted value. We should just use the checked version of copy_to_user() because it's not going to make a difference to the speed. Signed-off-by: Dan Carpenter Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d298243d8b3e63554553a729aec6b9e1502ce00d Author: Tyler Hicks Date: Fri Apr 29 16:26:27 2011 -0500 eCryptfs: Clear i_nlink in rmdir commit 07850552b92b3637fa56767b5e460b4238014447 upstream. eCryptfs wasn't clearing the eCryptfs inode's i_nlink after a successful vfs_rmdir() on the lower directory. This resulted in the inode evict and destroy paths to be missed. https://bugs.launchpad.net/ecryptfs/+bug/723518 Signed-off-by: Tyler Hicks Signed-off-by: Colin King Signed-off-by: Tim Gardner Signed-off-by: Greg Kroah-Hartman commit 12a9959bcc17eca2567447abfab2ca7f7ebac594 Author: Tyler Hicks Date: Tue Apr 12 11:21:36 2011 -0500 eCryptfs: Remove extra d_delete in ecryptfs_rmdir commit 35ffa948b2f7bdf79e488cd496232935d095087a upstream. vfs_rmdir() already calls d_delete() on the lower dentry. That was being duplicated in ecryptfs_rmdir() and caused a NULL pointer dereference when NFSv3 was the lower filesystem. BugLink: http://bugs.launchpad.net/bugs/723518 Signed-off-by: Tyler Hicks Signed-off-by: Colin King Signed-off-by: Tim Gardner Signed-off-by: Greg Kroah-Hartman commit 3c9b2dad7e98a942c6bca63bb95b66c0b3c9d0fd Author: Tyler Hicks Date: Wed Oct 14 16:18:27 2009 -0500 eCryptfs: Use notify_change for truncating lower inodes commit 5f3ef64f4da1c587cdcfaaac72311225b7df094c upstream. When truncating inodes in the lower filesystem, eCryptfs directly invoked vmtruncate(). As Christoph Hellwig pointed out, vmtruncate() is a filesystem helper function, but filesystems may need to do more than just a call to vmtruncate(). This patch moves the lower inode truncation out of ecryptfs_truncate() and renames the function to truncate_upper(). truncate_upper() updates an iattr for the lower inode to indicate if the lower inode needs to be truncated upon return. ecryptfs_setattr() then calls notify_change(), using the updated iattr for the lower inode, to complete the truncation. For eCryptfs functions needing to truncate, ecryptfs_truncate() is reintroduced as a simple way to truncate the upper inode to a specified size and then truncate the lower inode accordingly. https://bugs.launchpad.net/bugs/451368 Reported-by: Christoph Hellwig Acked-by: Dustin Kirkland Cc: ecryptfs-devel@lists.launchpad.net Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Tyler Hicks Signed-off-by: Colin Ian King Signed-off-by: Tim Gardner Signed-off-by: Greg Kroah-Hartman commit 1bf5d0a4b23b3c1d54d9f993cf2be16cce387b99 Author: Janne Grunau Date: Thu Feb 2 13:35:21 2012 -0300 hdpvr: fix race conditon during start of streaming commit afa159538af61f1a65d48927f4e949fe514fb4fc upstream. status has to be set to STREAMING before the streaming worker is queued. hdpvr_transmit_buffers() will exit immediately otherwise. Reported-by: Joerg Desch Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 5027714da2c8288d7ea39309bf66020a2e14a5d5 Author: Sarah Sharp Date: Mon Feb 13 14:42:11 2012 -0800 xhci: Fix encoding for HS bulk/control NAK rate. commit 340a3504fd39dad753ba908fb6f894ee81fc3ae2 upstream. The xHCI 0.96 spec says that HS bulk and control endpoint NAK rate must be encoded as an exponent of two number of microframes. The endpoint descriptor has the NAK rate encoded in number of microframes. We were just copying the value from the endpoint descriptor into the endpoint context interval field, which was not correct. This lead to the VIA host rejecting the add of a bulk OUT endpoint from any USB 2.0 mass storage device. The fix is to use the correct encoding. Refactor the code to convert number of frames to an exponential number of microframes, and make sure we convert the number of microframes in HS bulk and control endpoints to an exponent. This should be back ported to kernels as old as 2.6.31, that contain the commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in xhci_get_endpoint_interval" Signed-off-by: Sarah Sharp Tested-by: Felipe Contreras Suggested-by: Andiry Xu Signed-off-by: Greg Kroah-Hartman commit addf2e1999cc01c2d4c46a70aba505f9504c8719 Author: Sarah Sharp Date: Tue Feb 7 15:11:46 2012 -0800 USB: Fix handoff when BIOS disables host PCI device. commit cab928ee1f221c9cc48d6615070fefe2e444384a upstream. On some systems with an Intel Panther Point xHCI host controller, the BIOS disables the xHCI PCI device during boot, and switches the xHCI ports over to EHCI. This allows the BIOS to access USB devices without having xHCI support. The downside is that the xHCI BIOS handoff mechanism will fail because memory mapped I/O is not enabled for the disabled PCI device. Jesse Barnes says this is expected behavior. The PCI core will enable BARs before quirks run, but it will leave it in an undefined state, and it may not have memory mapped I/O enabled. Make the generic USB quirk handler call pci_enable_device() to re-enable MMIO, and call pci_disable_device() once the host-specific BIOS handoff is finished. This will balance the ref counts in the PCI core. When the PCI probe function is called, usb_hcd_pci_probe() will call pci_enable_device() again. This should be back ported to kernels as old as 2.6.31. That was the first kernel with xHCI support, and no one has complained about BIOS handoffs failing due to memory mapped I/O being disabled on other hosts (EHCI, UHCI, or OHCI). Signed-off-by: Sarah Sharp Acked-by: Oliver Neukum Cc: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit c807095470574a9aa1ef0b2bac9593aaf13837a9 Author: Bruno Thomsen Date: Tue Feb 21 23:41:37 2012 +0100 USB: Added Kamstrup VID/PIDs to cp210x serial driver. commit c6c1e4491dc8d1ed2509fa6aacffa7f34614fc38 upstream. Signed-off-by: Bruno Thomsen Signed-off-by: Greg Kroah-Hartman commit fc218b7c8f1eb6d160f833f23d4e43124e2354fd Author: Rabin Vincent Date: Wed Feb 15 16:01:42 2012 +0100 ARM: 7325/1: fix v7 boot with lockdep enabled commit 8e43a905dd574f54c5715d978318290ceafbe275 upstream. Bootup with lockdep enabled has been broken on v7 since b46c0f74657d ("ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR"). This is because v7_setup (which is called very early during boot) calls v7_flush_dcache_all, and the save_and_disable_irqs added by that patch ends up attempting to call into lockdep C code (trace_hardirqs_off()) when we are in no position to execute it (no stack, MMU off). Fix this by using a notrace variant of save_and_disable_irqs. The code already uses the notrace variant of restore_irqs. Reviewed-by: Nicolas Pitre Acked-by: Stephen Boyd Cc: Catalin Marinas Signed-off-by: Rabin Vincent Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 0e003003b65a7ab6af8575e34f999cdd1df57ff1 Author: Stephen Boyd Date: Tue Feb 7 19:42:07 2012 +0100 ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR commit b46c0f74657d1fe1c1b0c1452631cc38a9e6987f upstream. armv7's flush_cache_all() flushes caches via set/way. To determine the cache attributes (line size, number of sets, etc.) the assembly first writes the CSSELR register to select a cache level and then reads the CCSIDR register. The CSSELR register is banked per-cpu and is used to determine which cache level CCSIDR reads. If the task is migrated between when the CSSELR is written and the CCSIDR is read the CCSIDR value may be for an unexpected cache level (for example L1 instead of L2) and incorrect cache flushing could occur. Disable interrupts across the write and read so that the correct cache attributes are read and used for the cache flushing routine. We disable interrupts instead of disabling preemption because the critical section is only 3 instructions and we want to call v7_dcache_flush_all from __v7_setup which doesn't have a full kernel stack with a struct thread_info. This fixes a problem we see in scm_call() when flush_cache_all() is called from preemptible context and sometimes the L2 cache is not properly flushed out. Signed-off-by: Stephen Boyd Acked-by: Catalin Marinas Reviewed-by: Nicolas Pitre Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 95964a5eb5071a17bfb6b196417749407a5254f0 Author: adam radford Date: Thu Dec 10 11:53:31 2009 -0800 SCSI: 3w-9xxx fix bug in sgl loading commit 53ca353594a254e6bd45ccf2d405aa31bcbb7091 upstream. This small patch fixes a bug in the 3w-9xxx driver where it would load an invalid sgl address in the ioctl path even if request length was zero. Signed-off-by: Adam Radford Signed-off-by: James Bottomley Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit cce3ac26c143a639332fc92f8d0105e2e9f2256c Author: Andy Whitcroft Date: Wed Feb 16 04:49:59 2011 +0000 ecryptfs: read on a directory should return EISDIR if not supported commit 323ef68faf1bbd9b1e66aea268fd09d358d7e8ab upstream. read() calls against a file descriptor connected to a directory are incorrectly returning EINVAL rather than EISDIR: [EISDIR] [XSI] [Option Start] The fildes argument refers to a directory and the implementation does not allow the directory to be read using read() or pread(). The readdir() function should be used instead. [Option End] This occurs because we do not have a .read operation defined for ecryptfs directories. Connect this up to generic_read_dir(). BugLink: http://bugs.launchpad.net/bugs/719691 Signed-off-by: Andy Whitcroft Signed-off-by: Tyler Hicks commit 2e1a2aa9a9969836243d634dfbf1631e7e63f53e Author: Alex Deucher Date: Mon Feb 13 16:36:34 2012 -0500 drm/radeon/kms: fix MSI re-arm on rv370+ commit b7f5b7dec3d539a84734f2bcb7e53fbb1532a40b upstream. MSI_REARM_EN register is a write only trigger register. There is no need RMW when re-arming. May fix: https://bugs.freedesktop.org/show_bug.cgi?id=41668 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit ca24f59e757dda99b2544b908d3ec67e09167c91 Author: Alexey Dobriyan Date: Sat Jan 14 21:44:49 2012 +0300 crypto: sha512 - use standard ror64() commit f2ea0f5f04c97b48c88edccba52b0682fbe45087 upstream. Use standard ror64() instead of hand-written. There is no standard ror64, so create it. The difference is shift value being "unsigned int" instead of uint64_t (for which there is no reason). gcc starts to emit native ROR instructions which it doesn't do for some reason currently. This should make the code faster. Patch survives in-tree crypto test and ping flood with hmac(sha512) on. Signed-off-by: Alexey Dobriyan Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 98886b542b96243a07623139075be7193eca2ea2 Author: John Johansen Date: Wed Feb 15 14:14:06 2012 -0700 Add mount option to check uid of device being mounted = expect uid, CVE-2011-1833 (backported from commit 764355487ea220fdc2faf128d577d7f679b91f97) Close a TOCTOU race for mounts done via ecryptfs-mount-private. The mount source (device) can be raced when the ownership test is done in userspace. Provide Ecryptfs a means to force the uid check at mount time. BugLink: http://bugs.launchpad.net/bugs/732628 Signed-off-by: John Johansen Signed-off-by: Tyler Hicks Signed-off-by: Tim Gardner Signed-off-by: Greg Kroah-Hartman commit c07661f26a360e6b29c246786a15b5ee1a0235f3 Author: Al Viro Date: Wed Feb 15 14:10:52 2012 -0700 Ban ecryptfs over ecryptfs (cherry picked from commit 4403158ba295c8e36f6736b1bb12d0f7e1923dac) This is a seriously simplified patch from Eric Sandeen; copy of rationale follows: === mounting stacked ecryptfs on ecryptfs has been shown to lead to bugs in testing. For crypto info in xattr, there is no mechanism for handling this at all, and for normal file headers, we run into other trouble: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [] ecryptfs_d_revalidate+0x43/0xa0 [ecryptfs] ... There doesn't seem to be any good usecase for this, so I'd suggest just disallowing the configuration. Based on a patch originally, I believe, from Mike Halcrow. === Signed-off-by: Al Viro Signed-off-by: Tim Gardner Signed-off-by: Greg Kroah-Hartman commit 462808d8e21fcfa8e731d0cddd469d1ba92ac575 Author: Tyler Hicks Date: Wed Feb 15 11:32:31 2012 -0700 eCryptfs: Remove mmap from directory operations backported from 38e3eaeedcac75360af8a92e7b66956ec4f334e5 Adrian reported that mkfontscale didn't work inside of eCryptfs mounts. Strace revealed the following: open("./", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC) open("./fonts.scale", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 getdents(3, /* 80 entries */, 32768) = 2304 open("./.", O_RDONLY) = 5 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 fstat64(5, {st_mode=S_IFDIR|0755, st_size=16384, ...}) = 0 mmap2(NULL, 16384, PROT_READ, MAP_PRIVATE, 5, 0) = 0xb7fcf000 close(5) = 0 --- SIGBUS (Bus error) @ 0 (0) --- +++ killed by SIGBUS +++ The mmap2() on a directory was successful, resulting in a SIGBUS signal later. This patch removes mmap() from the list of possible ecryptfs_dir_fops so that mmap() isn't possible on eCryptfs directory files. http://bugs.launchpad.net/bugs/400443 Reported-by: Adrian C. Signed-off-by: Tyler Hicks Signed-off-by: Colin Ian King Signed-off-by: Tim Gardner Signed-off-by: Greg Kroah-Hartman commit e200edb226a0357d554039c4ff1847c6c03724c7 Author: Herbert Xu Date: Sun Feb 5 15:09:28 2012 +1100 crypto: sha512 - Avoid stack bloat on i386 commit 3a92d687c8015860a19213e3c102cad6b722f83c upstream. Unfortunately in reducing W from 80 to 16 we ended up unrolling the loop twice. As gcc has issues dealing with 64-bit ops on i386 this means that we end up using even more stack space (>1K). This patch solves the W reduction by moving LOAD_OP/BLEND_OP into the loop itself, thus avoiding the need to duplicate it. While the stack space still isn't great (>0.5K) it is at least in the same ball park as the amount of stack used for our C sha1 implementation. Note that this patch basically reverts to the original code so the diff looks bigger than it really is. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 3e15b23883776bb8c42bd5e5ee6e439ab4bd60df Author: Herbert Xu Date: Thu Jan 26 15:03:16 2012 +1100 crypto: sha512 - Use binary and instead of modulus commit 58d7d18b5268febb8b1391c6dffc8e2aaa751fcd upstream. The previous patch used the modulus operator over a power of 2 unnecessarily which may produce suboptimal binary code. This patch changes changes them to binary ands instead. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 7422fb39e4b06b7f375a088c5bad8b0134f5a3a0 Author: Nikolaus Schulz Date: Wed Feb 8 18:56:08 2012 +0100 hwmon: (f75375s) Fix automatic pwm mode setting for F75373 & F75375 commit 09e87e5c4f9af656af2a8a3afc03487c5d9287c3 upstream. In order to enable temperature mode aka automatic mode for the F75373 and F75375 chips, the two FANx_MODE bits in the fan configuration register need be set to 01, not 10. Signed-off-by: Nikolaus Schulz Signed-off-by: Greg Kroah-Hartman commit 3a86cda406c00df3a1c207ba26406847d8e53bba Author: OGAWA Hirofumi Date: Mon May 24 14:33:11 2010 -0700 printk_ratelimited(): fix uninitialized spinlock commit d8521fcc5e0ad3e79bbc4231bb20a6cdc2b50164 upstream. ratelimit_state initialization of printk_ratelimited() seems broken. This fixes it by using DEFINE_RATELIMIT_STATE() to initialize spinlock properly. Signed-off-by: OGAWA Hirofumi Cc: Joe Perches Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Sven-Haegar Koch Signed-off-by: Greg Kroah-Hartman commit 3aee4081eee4987bbf2dd00c7267a8b2ea7386a0 Author: Yong Zhang Date: Tue Apr 6 14:35:02 2010 -0700 kernel.h: fix wrong usage of __ratelimit() commit bb1dc0bacb8ddd7ba6a5906c678a5a5a110cf695 upstream. When __ratelimit() returns 1 this means that we can go ahead. Signed-off-by: Yong Zhang Cc: Ingo Molnar Cc: Joe Perches Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d5101f5e6df8e31cd58a393aacb6280a55b8787b Author: Eliad Peller Date: Wed Feb 1 18:48:09 2012 +0200 mac80211: timeout a single frame in the rx reorder buffer commit 07ae2dfcf4f7143ce191c6436da1c33f179af0d6 upstream. The current code checks for stored_mpdu_num > 1, causing the reorder_timer to be triggered indefinitely, but the frame is never timed-out (until the next packet is received) Signed-off-by: Eliad Peller Acked-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit e871c96c42ff9c08d856a757c0176f9381ac67cd Author: Dan Carpenter Date: Fri Feb 10 09:03:58 2012 +0100 relay: prevent integer overflow in relay_open() commit f6302f1bcd75a042df69866d98b8d775a668f8f1 upstream. "subbuf_size" and "n_subbufs" come from the user and they need to be capped to prevent an integer overflow. Signed-off-by: Dan Carpenter Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 210e889ab890de2eceb8b650093618937d9c1c45 Author: Wu Fengguang Date: Mon Jan 9 11:53:50 2012 -0600 lib: proportion: lower PROP_MAX_SHIFT to 32 on 64-bit kernel commit 3310225dfc71a35a2cc9340c15c0e08b14b3c754 upstream. PROP_MAX_SHIFT should be set to <=32 on 64-bit box. This fixes two bugs in the below lines of bdi_dirty_limit(): bdi_dirty *= numerator; do_div(bdi_dirty, denominator); 1) divide error: do_div() only uses the lower 32 bit of the denominator, which may trimmed to be 0 when PROP_MAX_SHIFT > 32. 2) overflow: (bdi_dirty * numerator) could easily overflow if numerator used up to 48 bits, leaving only 16 bits to bdi_dirty Cc: Peter Zijlstra Reported-by: Ilya Tumaykin Tested-by: Ilya Tumaykin Signed-off-by: Wu Fengguang Signed-off-by: Greg Kroah-Hartman commit 5fe6345243aba30d20772c8f04cce098c6752425 Author: Nikolaus Schulz Date: Wed Feb 8 18:56:10 2012 +0100 hwmon: (f75375s) Fix bit shifting in f75375_write16 commit eb2f255b2d360df3f500042a2258dcf2fcbe89a2 upstream. In order to extract the high byte of the 16-bit word, shift the word to the right, not to the left. Signed-off-by: Nikolaus Schulz Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 0f896131dfc21ce0f4baad21db7672eaf6a183d2 Author: Daniel Vetter Date: Wed Feb 8 16:42:52 2012 +0100 drm/i915: no lvds quirk for AOpen MP45 commit e57b6886f555ab57f40a01713304e2053efe51ec upstream. According to a bug report, it doesn't have one. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44263 Acked-by: Chris Wilson Signed-Off-by: Daniel Vetter Signed-off-by: Keith Packard Signed-off-by: Greg Kroah-Hartman