All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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.