Gitweb:     
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1227a74e2e0217a4ca155d1677bdbf5f69e32bed
Commit:     1227a74e2e0217a4ca155d1677bdbf5f69e32bed
Parent:     5d9c4a7de64d398604a978d267a6987f1f4025b7
Author:     Jeff Layton <[EMAIL PROTECTED]>
AuthorDate: Tue Feb 19 12:51:35 2008 -0500
Committer:  Trond Myklebust <[EMAIL PROTECTED]>
CommitDate: Wed Feb 20 13:32:43 2008 -0500

    NFS: flush signals before taking down callback thread
    
    Now that the reference counting on the callback thread is working as
    expected, it uncovers another problem.  Peter Staubach noticed while
    testing that patch on an older kernel that he would occasionally see
    this printk in rpc_register fire:
    
        "RPC: failed to contact portmap (errno -512).
    
    The NFSv4 callback thread is signaled by nfs_callback_down(), but never
    flushes that signal. All of the shutdown processing is done with that
    signal pending. This makes it fail the call to unregister the port with
    the portmapper.
    
    In actuality, this rpc_register call isn't necessary at all since the
    port isn't actually registered with the portmapper anymore. Regardless,
    there doesn't seem to be any reason to leave the signal pending while
    the thread is being shut down and flushing it should generally silence
    that printk.
    
    Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
    Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
---
 fs/nfs/callback.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/nfs/callback.c b/fs/nfs/callback.c
index ecc06c6..0d784f6 100644
--- a/fs/nfs/callback.c
+++ b/fs/nfs/callback.c
@@ -93,6 +93,7 @@ static void nfs_callback_svc(struct svc_rqst *rqstp)
                svc_process(rqstp);
        }
 
+       flush_signals(current);
        svc_exit_thread(rqstp);
        nfs_callback_info.pid = 0;
        complete(&nfs_callback_info.stopped);
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to