All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@redhat.com>
To: linux-nfs@vger.kernel.org
Cc: Jeff Layton <jlayton@redhat.com>, Neil Brown <neilb@suse.de>,
	"J. Bruce Fields" <bfields@redhat.com>
Subject: [PATCH 0/3] Fix use_ipaddr race
Date: Fri, 20 Apr 2012 18:46:15 -0400	[thread overview]
Message-ID: <1334961978-2843-1-git-send-email-bfields@redhat.com> (raw)

From: "J. Bruce Fields" <bfields@redhat.com>

We have a report of failed upcalls that occur when use_ipaddr is
toggled.  The problem appears to be that for example after turning on
use_ipaddr, the kernel may still see upcalls for clients such as "*".

The following patches (untested except to check that they compile...)
attempt to fix that by just letting nfsd_fh() accept either client type;
does anyone see a problem with that?


The current code actually attempts to avoid tihs problem by flushing
caches on a use_ipaddr change (see the cache_flush() call in
utils/mountd/auth.c:check_useipaddr().  But that doesn't work, because a
write to a cache/flush file doesn't actually provide useful guarantees
to the caller on return:

	- as far as I can tell, cache_clean leaves alone any entries
	  that were created in the current second.
	- cache_clean only removes entries from the cache, it doesn't
	  wait for them to actually be destroyed: so an in-progress nfsd
	  thread could still make an upcall using information from one
	  of the flushed entries.

These seem like bugs in their own right to me: a cache-flush operation
that actually guaranteed the entries were gone on return would be more
useful.  And I wonder whether this doesn't also cause exportfs bugs....

I'm not sure what to do about it, though.

I don't think the existing interface is really fixable, since fixing the
second problem above would (I think) require the cache/flush write to
wait on in-progress rpc's, but those in-progress rpc's could be waiting
on mountd, creating a deadlock.

A new interface shouldn't need to accept a time--every actual user just
wants to cache flushed now.

Maybe the first problem could be solved by replacing the time by a
counter incremented on each insert of a cache entry.

And the second could be fixed by waiting on in-progress rpc's.  That
might not help mountd, but it would help exportfs at least.

--b.

J. Bruce Fields (3):
  mountd: unconditionally resolve ip address
  mountd: helper function for export upcall's client matching
  mountd: ignore use_ipaddr and just try both client types

 utils/mountd/cache.c |   38 +++++++++++++++++++++++++-------------
 1 files changed, 25 insertions(+), 13 deletions(-)

-- 
1.7.7.6


             reply	other threads:[~2012-04-20 22:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-20 22:46 J. Bruce Fields [this message]
2012-04-20 22:46 ` [PATCH 1/3] mountd: unconditionally resolve ip address J. Bruce Fields
2012-04-20 22:46 ` [PATCH 2/3] mountd: helper function for export upcall's client matching J. Bruce Fields
2012-04-20 22:46 ` [PATCH 3/3] mountd: ignore use_ipaddr and just try both client types J. Bruce Fields
2012-04-23  1:04 ` [PATCH 0/3] Fix use_ipaddr race NeilBrown
2012-04-28 11:26   ` J. Bruce Fields
2012-04-28 11:28     ` [PATCH 1/3] mountd: parse ip address earlier J. Bruce Fields
2012-04-28 11:28     ` [PATCH 2/3] mountd: add trivial helpers for client-matching J. Bruce Fields
2012-04-28 11:28     ` [PATCH 3/3] mountd: prepend '?' to make use_ipaddr clients self-describing J. Bruce Fields
2012-04-28 11:47     ` [PATCH 0/3] Fix use_ipaddr race NeilBrown
2012-04-28 15:59       ` J. Bruce Fields
2012-05-02  1:41         ` J. Bruce Fields
2012-05-02  1:43           ` [PATCH 1/3] mountd: parse ip address earlier J. Bruce Fields
2012-05-02  1:43           ` [PATCH 2/3] mountd: add trivial helpers for client-matching J. Bruce Fields
2012-05-02  1:43           ` [PATCH 3/3] mountd: prepend '$' to make use_ipaddr clients self-describing J. Bruce Fields
2012-05-02  2:07             ` NeilBrown

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=1334961978-2843-1-git-send-email-bfields@redhat.com \
    --to=bfields@redhat.com \
    --cc=jlayton@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    /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.