linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Chuck Lever <chuck.lever@oracle.com>,
	Bryan Schumaker <bjschuma@netapp.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	SteveD@redhat.com
Subject: Re: [PATCH] nfs-utils: Add nfs.upcall for idmapper
Date: Thu, 30 Sep 2010 13:23:37 -0400	[thread overview]
Message-ID: <20100930172336.GA9385@fieldses.org> (raw)
In-Reply-To: <1285866437.14635.27.camel@heimdal.trondhjem.org>

On Thu, Sep 30, 2010 at 01:07:17PM -0400, Trond Myklebust wrote:
> On Thu, 2010-09-30 at 11:42 -0400, Chuck Lever wrote:
> > Finally, if at all possible, it would be better if the kernel could automatically recognize and use nfs.upcall rather than the legacy idmapping mechanism.  My experience with CONFIG options is that people will almost always choose the wrong setting no matter how many large neon arrows you add.  I know there are likely some technical challenges here.
> 
> I don't think that is easy to do. The keyring upcall mechanism will
> almost always succeed, no matter whether or not there is a handler for
> the type of key requested. Instead, it will result in a negative lookup.
> Unfortunately, seeing a negative key isn't sufficient to determine that
> no handler exists.

If we could just find out whether there's an executable at the right
path, that would be enough to catch most misconfigurations.  Would it be
hard to get back at least that much information?

I'm inclined to agree with Chuck that this is a likely trap for the
unwary....

--b.

  reply	other threads:[~2010-09-30 17:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-29 19:41 [PATCH] nfs-utils: Add nfs.upcall for idmapper Bryan Schumaker
2010-09-29 22:13 ` Trond Myklebust
2010-09-30 13:13   ` Bryan Schumaker
2010-09-30 15:42     ` Chuck Lever
2010-09-30 17:07       ` Trond Myklebust
2010-09-30 17:23         ` J. Bruce Fields [this message]
2010-09-30 17:39           ` Trond Myklebust
2010-09-30 17:30         ` Chuck Lever
2010-09-30 17:57           ` 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=20100930172336.GA9385@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=SteveD@redhat.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=bjschuma@netapp.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).