All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@poochiereds.net>
To: trond.myklebust@primarydata.com
Cc: linux-nfs@vger.kernel.org
Subject: [PATCH 0/8] nfs/sunrpc: fix flexfiles credential handling
Date: Thu, 14 Apr 2016 08:36:57 -0400	[thread overview]
Message-ID: <1460637425-1580-1-git-send-email-jeff.layton@primarydata.com> (raw)

The way that credentials are handled in the flexfiles client is
currently wrong. It only keeps one set of credentials per mirror object,
but those objects can be shared between read and rw layout segments
If the server hands out different credentials for read and rw layouts,
then you can end up in a situation where the client will end up issuing
writes with the wrong uid.

This is visible by simply mounting a server that does hand out different
creds for ro vs. rw layouts, opening the file for read, then opening it
for write, and then issuing a write. At that point, the DS write calls
will fail with EACCES. The client will then re-fetch the layout, but the
creds are not updated, so the writes still fail. The client is then
stuck at that point. This problem also means that the client is unable
to recover after a layout is fenced, since the creds are never updated.

This patchset cleans up some ugliness in how flexfiles rpc_creds are
handled, adds a place to keep ro and rw creds per mirror, and allows
those creds to be updated when a LAYOUTGET response contains different
ones.

We start with a few sunrpc patches that lay the groundwork to allow the
creds to be accessible via RCU and to fix up a current wart where we can
end up doing a GFP_KERNEL allocation while in a possible memory reclaim
scenario. The flexfiles code is then changed to allow the creds to be
swapped out as credential updates come in. The users of those creds then
ensure that they take references to them in case they are swapped out,
and put those references after the calls are dispatched.

Only lightly tested so far (cthon and fstests) but it does fix the
original problem.

Jeff Layton (7):
  sunrpc: allow generic_match to handle creds with NULL group_info ptr
  sunrpc: plumb gfp_t parm into crcreate operation
  sunrpc: add a get_rpccred_rcu inline
  nfs: don't call nfs4_ff_layout_prepare_ds from ff_layout_get_ds_cred
  nfs: have ff_layout_get_ds_cred take a reference to the cred
  nfs: get a reference to the credential in ff_layout_alloc_lseg
  nfs: have flexfiles mirror keep creds for both ro and rw layouts

Weston Andros Adamson (1):
  sunrpc: add rpc_lookup_generic_cred

 fs/nfs/flexfilelayout/flexfilelayout.c    | 59 ++++++++++++++++++-----
 fs/nfs/flexfilelayout/flexfilelayout.h    |  5 +-
 fs/nfs/flexfilelayout/flexfilelayoutdev.c | 78 +++++++++++--------------------
 include/linux/sunrpc/auth.h               | 23 ++++++++-
 net/sunrpc/auth.c                         |  4 +-
 net/sunrpc/auth_generic.c                 | 22 ++++++---
 net/sunrpc/auth_gss/auth_gss.c            |  6 +--
 net/sunrpc/auth_unix.c                    |  6 +--
 8 files changed, 122 insertions(+), 81 deletions(-)

-- 
2.5.5


             reply	other threads:[~2016-04-14 12:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-14 12:36 Jeff Layton [this message]
2016-04-14 12:36 ` [PATCH 1/8] sunrpc: allow generic_match to handle creds with NULL group_info ptr Jeff Layton
2016-04-14 12:36 ` [PATCH 2/8] sunrpc: plumb gfp_t parm into crcreate operation Jeff Layton
2016-04-14 12:37 ` [PATCH 3/8] sunrpc: add rpc_lookup_generic_cred Jeff Layton
2016-04-14 12:37 ` [PATCH 4/8] sunrpc: add a get_rpccred_rcu inline Jeff Layton
2016-04-14 12:37 ` [PATCH 5/8] nfs: don't call nfs4_ff_layout_prepare_ds from ff_layout_get_ds_cred Jeff Layton
2016-04-14 12:37 ` [PATCH 6/8] nfs: have ff_layout_get_ds_cred take a reference to the cred Jeff Layton
2016-04-14 14:29   ` Jeff Layton
2016-04-14 12:37 ` [PATCH 7/8] nfs: get a reference to the credential in ff_layout_alloc_lseg Jeff Layton
2016-04-14 12:37 ` [PATCH 8/8] nfs: have flexfiles mirror keep creds for both ro and rw layouts Jeff Layton

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=1460637425-1580-1-git-send-email-jeff.layton@primarydata.com \
    --to=jlayton@poochiereds.net \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@primarydata.com \
    /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.