public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Neil Brown <neilb@suse.de>
Cc: linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net,
	Adrian Bunk <bunk@kernel.org>
Subject: Re: [PATCH 08/15] knfsd: spawn kernel thread to probe callback channel
Date: Mon, 27 Aug 2007 19:36:15 -0400	[thread overview]
Message-ID: <20070827233615.GP3118@fieldses.org> (raw)
In-Reply-To: <18131.23980.89642.364179@notabene.brown>

On Tue, Aug 28, 2007 at 09:26:36AM +1000, Neil Brown wrote:
> On Monday August 27, bfields@fieldses.org wrote:
> >  
> > +/* Reference counting, callback cleanup, etc., all look racy as heck.
> > + * And why is cb_set an atomic? */
> 
> Agreed.... so do we really want this code in mainline?  is the old
> code so bad that this is better?

The code in question is just moved, not rewritten, so those are
preexisting problems that I was just adding a whiny comment about in
hopes it would remind me some more patches were probably needed.
(Thanks for the reminder....)

>  - cb_set should not be atomic.
>  - This looks like a job for async-rpc rather than a kernel thread

The problem isn't the wait for the rpc itself, it's the creation of the
new cred that's needed in the gss case.  That could also be made
asynchronous, but as there's several other delicate changes in the
pipeline (keyring stuff, etc.), I'd rather not touch it for now.

>  - If you do use a thread, you at least want __module_get before
>    starting the thread, and module_put_and_exit to terminate the
>    thread.
>  - Can you just use 'cb_client' rather than cb_set?  If you move
>    rpc_create into the thread, you don't need to set cb_client until
>    the callback is successful.  Then add a 'cb_active' flag bit
>    so that you don't have two callbacks at the same time, and it
>    should be less racy..

Yep, probably so.

--b.

      reply	other threads:[~2007-08-27 23:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-27 20:22 nfs server patches for review J. Bruce Fields
2007-08-27 20:22 ` [PATCH 01/15] nfsd: tone down inaccurate dprintk J. Bruce Fields
2007-08-27 20:22   ` [PATCH 02/15] nfsd: remove unused cache_for_each macro J. Bruce Fields
2007-08-27 20:22     ` [PATCH 03/15] nfsd: fix horrible indentation in nfsd_setattr J. Bruce Fields
2007-08-27 20:22       ` [PATCH 04/15] knfsd: delete code made redundant by map_new_errors J. Bruce Fields
2007-08-27 20:22         ` [PATCH 05/15] knfsd: cleanup of nfsd4 cmp_* functions J. Bruce Fields
2007-08-27 20:22           ` [PATCH 06/15] knfsd: demote some printk()s to dprintk()s J. Bruce Fields
2007-08-27 20:22             ` [PATCH 07/15] knfsd: nfs4 name->id mapping not correctly parsing negative downcall J. Bruce Fields
2007-08-27 20:22               ` [PATCH 08/15] knfsd: spawn kernel thread to probe callback channel J. Bruce Fields
2007-08-27 20:22                 ` [PATCH 09/15] knfsd: move nfsv4 slab creation/destruction to module init/exit J. Bruce Fields
2007-08-27 20:22                   ` [PATCH 10/15] knfsd: Validate filehandle type in fsid_source J. Bruce Fields
2007-08-27 20:22                     ` [PATCH 11/15] knfsd: fix callback rpc cred J. Bruce Fields
2007-08-27 20:22                       ` [PATCH 12/15] nfsd warning fix J. Bruce Fields
2007-08-27 20:22                         ` [PATCH 13/15] knfsd: remove code duplication in nfsd4_setclientid() J. Bruce Fields
2007-08-27 20:22                           ` [PATCH 14/15] svcgss: move init code into separate function J. Bruce Fields
2007-08-27 20:22                             ` [PATCH 15/15] knfsd: 64 bit ino support for NFS server J. Bruce Fields
2007-08-27 23:26                 ` [PATCH 08/15] knfsd: spawn kernel thread to probe callback channel Neil Brown
2007-08-27 23:36                   ` J. Bruce Fields [this message]

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=20070827233615.GP3118@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=bunk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=nfs@lists.sourceforge.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox