From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Filesystem Development <linux-fsdevel@vger.kernel.org>
Subject: [GIT PULL] Please pull bugfixes for the NFS client
Date: Mon, 28 Mar 2011 09:04:33 +0200 [thread overview]
Message-ID: <1301295873.32186.1.camel@lade.trondhjem.org> (raw)
Hi Linus,
Please pull from the "bugfixes" branch of the repository at
git pull git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git bugfixes
This will update the following files through the appended changesets.
Cheers,
Trond
----
fs/nfs/namespace.c | 4 +++-
fs/nfs/pagelist.c | 4 ++--
fs/nfs/write.c | 13 +++----------
include/linux/nfs_page.h | 1 -
net/sunrpc/sched.c | 4 +++-
5 files changed, 11 insertions(+), 15 deletions(-)
commit a271c5a0dea418931b6a903ef85adc30ad4c54be
Author: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date: Sun Mar 27 17:48:57 2011 +0200
NFS: Ensure that rpc_release_resources_task() can be called twice.
BUG: atomic_dec_and_test(): -1: atomic counter underflow at:
Pid: 2827, comm: mount.nfs Not tainted 2.6.38 #1
Call Trace:
[<ffffffffa02223a0>] ? put_rpccred+0x44/0x14e [sunrpc]
[<ffffffffa021bbe9>] ? rpc_ping+0x4e/0x58 [sunrpc]
[<ffffffffa021c4a5>] ? rpc_create+0x481/0x4fc [sunrpc]
[<ffffffffa022298a>] ? rpcauth_lookup_credcache+0xab/0x22d [sunrpc]
[<ffffffffa028be8c>] ? nfs_create_rpc_client+0xa6/0xeb [nfs]
[<ffffffffa028c660>] ? nfs4_set_client+0xc2/0x1f9 [nfs]
[<ffffffffa028cd3c>] ? nfs4_create_server+0xf2/0x2a6 [nfs]
[<ffffffffa0295d07>] ? nfs4_remote_mount+0x4e/0x14a [nfs]
[<ffffffff810dd570>] ? vfs_kern_mount+0x6e/0x133
[<ffffffffa029605a>] ? nfs_do_root_mount+0x76/0x95 [nfs]
[<ffffffffa029643d>] ? nfs4_try_mount+0x56/0xaf [nfs]
[<ffffffffa0297434>] ? nfs_get_sb+0x435/0x73c [nfs]
[<ffffffff810dd59b>] ? vfs_kern_mount+0x99/0x133
[<ffffffff810dd693>] ? do_kern_mount+0x48/0xd8
[<ffffffff810f5b75>] ? do_mount+0x6da/0x741
[<ffffffff810f5c5f>] ? sys_mount+0x83/0xc0
[<ffffffff8100293b>] ? system_call_fastpath+0x16/0x1b
Well, so, I think this is real bug of nfs codes somewhere. With some
review, the code
rpc_call_sync()
rpc_run_task
rpc_execute()
__rpc_execute()
rpc_release_task()
rpc_release_resources_task()
put_rpccred() <= release cred
rpc_put_task
rpc_do_put_task()
rpc_release_resources_task()
put_rpccred() <= release cred again
seems to be release cred unintendedly.
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
commit a0e7e3cf7932d6c77de0dc79a40dbaeb8060b544
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Sat Mar 26 02:24:35 2011 -0400
NFS: Don't leak RPC clients in NFSv4 secinfo negotiation
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
commit 4d65c520fb4abed970069d18c119cfe85624f46d
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Fri Mar 25 14:15:11 2011 -0400
NFS: Fix a hang in the writeback path
Now that the inode scalability patches have been merged, it is no longer
safe to call igrab() under the inode->i_lock.
Now that we no longer call nfs_clear_request() until the nfs_page is
being freed, we know that we are always holding a reference to the
nfs_open_context, which again holds a reference to the path, and so
the inode cannot be freed until the last nfs_page has been removed
from the radix tree and freed.
We can therefore skip the igrab()/iput() altogether.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
next reply other threads:[~2011-03-28 7:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-28 7:04 Trond Myklebust [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-06-21 22:58 [GIT PULL] Please pull bugfixes for the NFS client Myklebust, Trond
2012-06-21 22:58 ` Myklebust, Trond
2012-06-14 16:00 Myklebust, Trond
2011-09-15 18:50 Trond Myklebust
2011-03-28 7:04 Trond Myklebust
2010-09-14 2:11 Trond Myklebust
2010-08-18 22:44 Trond Myklebust
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1301295873.32186.1.camel@lade.trondhjem.org \
--to=trond.myklebust@netapp.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.