--- /dev/null
+From b1d4b390ea4bb480e65974ce522a04022608a8df Mon Sep 17 00:00:00 2001
+From: Jean Delvare <khali@linux-fr.org>
+Date: Tue, 4 May 2010 11:09:28 +0200
+Subject: i2c: Fix probing of FSC hardware monitoring chips
+
+From: Jean Delvare <khali@linux-fr.org>
+
+commit b1d4b390ea4bb480e65974ce522a04022608a8df upstream.
+
+Some FSC hardware monitoring chips (Syleus at least) doesn't like
+quick writes we typically use to probe for I2C chips. Use a regular
+byte read instead for the address they live at (0x73). These are the
+only known chips living at this address on PC systems.
+
+For clarity, this fix should not be needed for kernels 2.6.30 and
+later, as we started instantiating the hwmon devices explicitly based
+on DMI data. Still, this fix is valuable in the following two cases:
+* Support for recent FSC chips on older kernels. The DMI-based device
+ instantiation is more difficult to backport than the device support
+ itself.
+* Case where the DMI-based device instantiation fails, whatever the
+ reason. We fall back to probing in that case, so it should work.
+
+This fixes kernel bug #15634:
+https://bugzilla.kernel.org/show_bug.cgi?id=15634
+
+Signed-off-by: Jean Delvare <khali@linux-fr.org>
+Acked-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+
+---
+ drivers/i2c/i2c-core.c | 24 +++++++++++++++++-------
+ 1 file changed, 17 insertions(+), 7 deletions(-)
+
+--- a/drivers/i2c/i2c-core.c
++++ b/drivers/i2c/i2c-core.c
+@@ -1269,14 +1269,24 @@ static int i2c_detect_address(struct i2c
+
+ /* Make sure there is something at this address, unless forced */
+ if (kind < 0) {
+- if (i2c_smbus_xfer(adapter, addr, 0, 0, 0,
+- I2C_SMBUS_QUICK, NULL) < 0)
+- return 0;
++ if (addr == 0x73 && (adapter->class & I2C_CLASS_HWMON)) {
++ /* Special probe for FSC hwmon chips */
++ union i2c_smbus_data dummy;
+
+- /* prevent 24RF08 corruption */
+- if ((addr & ~0x0f) == 0x50)
+- i2c_smbus_xfer(adapter, addr, 0, 0, 0,
+- I2C_SMBUS_QUICK, NULL);
++ if (i2c_smbus_xfer(adapter, addr, 0, I2C_SMBUS_READ, 0,
++ I2C_SMBUS_BYTE_DATA, &dummy) < 0)
++ return 0;
++ } else {
++ if (i2c_smbus_xfer(adapter, addr, 0, I2C_SMBUS_WRITE, 0,
++ I2C_SMBUS_QUICK, NULL) < 0)
++ return 0;
++
++ /* Prevent 24RF08 corruption */
++ if ((addr & ~0x0f) == 0x50)
++ i2c_smbus_xfer(adapter, addr, 0,
++ I2C_SMBUS_WRITE, 0,
++ I2C_SMBUS_QUICK, NULL);
++ }
+ }
+
+ /* Finally call the custom detection function */
+++ /dev/null
-From 03449cd9eaa4fa3a7faa4a59474bafe2e90bd143 Mon Sep 17 00:00:00 2001
-From: David Howells <dhowells@redhat.com>
-Date: Tue, 27 Apr 2010 13:13:08 -0700
-Subject: keys: the request_key() syscall should link an existing key to the dest keyring
-
-From: David Howells <dhowells@redhat.com>
-
-commit 03449cd9eaa4fa3a7faa4a59474bafe2e90bd143 upstream.
-
-The request_key() system call and request_key_and_link() should make a
-link from an existing key to the destination keyring (if supplied), not
-just from a new key to the destination keyring.
-
-This can be tested by:
-
- ring=`keyctl newring fred @s`
- keyctl request2 user debug:a a
- keyctl request user debug:a $ring
- keyctl list $ring
-
-If it says:
-
- keyring is empty
-
-then it didn't work. If it shows something like:
-
- 1 key in keyring:
- 1070462727: --alswrv 0 0 user: debug:a
-
-then it did.
-
-request_key() system call is meant to recursively search all your keyrings for
-the key you desire, and, optionally, if it doesn't exist, call out to userspace
-to create one for you.
-
-If request_key() finds or creates a key, it should, optionally, create a link
-to that key from the destination keyring specified.
-
-Therefore, if, after a successful call to request_key() with a desination
-keyring specified, you see the destination keyring empty, the code didn't work
-correctly.
-
-If you see the found key in the keyring, then it did - which is what the patch
-is required for.
-
-Signed-off-by: David Howells <dhowells@redhat.com>
-Cc: James Morris <jmorris@namei.org>
-Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
----
- security/keys/request_key.c | 9 ++++++++-
- 1 file changed, 8 insertions(+), 1 deletion(-)
-
---- a/security/keys/request_key.c
-+++ b/security/keys/request_key.c
-@@ -316,8 +316,10 @@ static int construct_alloc_key(struct ke
-
- key_already_present:
- mutex_unlock(&key_construction_mutex);
-- if (dest_keyring)
-+ if (dest_keyring) {
-+ __key_link(dest_keyring, key_ref_to_ptr(key_ref));
- up_write(&dest_keyring->sem);
-+ }
- mutex_unlock(&user->cons_lock);
- key_put(key);
- *_key = key = key_ref_to_ptr(key_ref);
-@@ -396,6 +398,11 @@ struct key *request_key_and_link(struct
-
- if (!IS_ERR(key_ref)) {
- key = key_ref_to_ptr(key_ref);
-+ if (dest_keyring) {
-+ construct_get_dest_keyring(&dest_keyring);
-+ key_link(dest_keyring, key);
-+ key_put(dest_keyring);
-+ }
- } else if (PTR_ERR(key_ref) != -EAGAIN) {
- key = ERR_CAST(key_ref);
- } else {
--- /dev/null
+From d9e80b7de91db05c1c4d2e5ebbfd70b3b3ba0e0f Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@ZenIV.linux.org.uk>
+Date: Thu, 29 Apr 2010 03:10:43 +0100
+Subject: nfs d_revalidate() is too trigger-happy with d_drop()
+
+From: Al Viro <viro@ZenIV.linux.org.uk>
+
+commit d9e80b7de91db05c1c4d2e5ebbfd70b3b3ba0e0f upstream.
+
+If dentry found stale happens to be a root of disconnected tree, we
+can't d_drop() it; its d_hash is actually part of s_anon and d_drop()
+would simply hide it from shrink_dcache_for_umount(), leading to
+all sorts of fun, including busy inodes on umount and oopsen after
+that.
+
+Bug had been there since at least 2006 (commit c636eb already has it),
+so it's definitely -stable fodder.
+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/nfs/dir.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/nfs/dir.c
++++ b/fs/nfs/dir.c
+@@ -826,6 +826,8 @@ out_zap_parent:
+ /* If we have submounts, don't unhash ! */
+ if (have_submounts(dentry))
+ goto out_valid;
++ if (dentry->d_flags & DCACHE_DISCONNECTED)
++ goto out_valid;
+ shrink_dcache_parent(dentry);
+ }
+ d_drop(dentry);
--- /dev/null
+From 356e76b855bdbfd8d1c5e75bcf0c6bf0dfe83496 Mon Sep 17 00:00:00 2001
+From: Chuck Lever <chuck.lever@oracle.com>
+Date: Thu, 22 Apr 2010 15:35:56 -0400
+Subject: NFS: rsize and wsize settings ignored on v4 mounts
+
+From: Chuck Lever <chuck.lever@oracle.com>
+
+commit 356e76b855bdbfd8d1c5e75bcf0c6bf0dfe83496 upstream.
+
+NFSv4 mounts ignore the rsize and wsize mount options, and always use
+the default transfer size for both. This seems to be because all
+NFSv4 mounts are now cloned, and the cloning logic doesn't copy the
+rsize and wsize settings from the parent nfs_server.
+
+I tested Fedora's 2.6.32.11-99 and it seems to have this problem as
+well, so I'm guessing that .33, .32, and perhaps older kernels have
+this issue as well.
+
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/nfs/client.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/nfs/client.c
++++ b/fs/nfs/client.c
+@@ -826,6 +826,8 @@ out_error:
+ static void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source)
+ {
+ target->flags = source->flags;
++ target->rsize = source->rsize;
++ target->wsize = source->wsize;
+ target->acregmin = source->acregmin;
+ target->acregmax = source->acregmax;
+ target->acdirmin = source->acdirmin;
megaraid_sas-fix-for-32bit-apps.patch
trace-fix-inappropriate-substraction-on-tracing_pages_allocated-in-trace_free_page.patch
clockevent-prevent-dead-lock-on-clockevents_lock.patch
-keys-the-request_key-syscall-should-link-an-existing-key-to-the-dest-keyring.patch
nfsd4-bug-in-read_buf.patch
usb-fix-testing-the-wrong-variable-in-fs_create_by_name.patch
+nfs-d_revalidate-is-too-trigger-happy-with-d_drop.patch
+nfs-rsize-and-wsize-settings-ignored-on-v4-mounts.patch
+i2c-fix-probing-of-fsc-hardware-monitoring-chips.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
