All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@hammerspace.com>
To: "neilb@suse.de" <neilb@suse.de>,
	"anna.schumaker@netapp.com" <anna.schumaker@netapp.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 0/3] Don't store cred in nfs_access_entry
Date: Tue, 16 Nov 2021 20:57:33 +0000	[thread overview]
Message-ID: <1b6b267598c8fcf5f50b6a118d88cf7ea938d076.camel@hammerspace.com> (raw)
In-Reply-To: <163709576284.13692.2252149084412844753@noble.neil.brown.name>

On Wed, 2021-11-17 at 07:49 +1100, NeilBrown wrote:
> 
> Hi Trond/Anna,
>  have you had a chance to look at these patches?
> 

Oh crap... I did see those patches, and intended to pick them up for
this last merge window, but somehow forgot to move them into my
'testing' branch.

Anna, can you please queue them up for the next merge window?

Apologies
  Trond

> Thanks,
> NeilBrown
> 
> On Tue, 28 Sep 2021, NeilBrown wrote:
> > It turns out that storing a counted ref to 'struct cred' in
> > nfs_access_entry wasn't a good choice.
> > 'struct cred' contains counted references to 'struct key', and
> > users
> > have a quota on how many keys they can have.  Keeping a cred in a
> > cache
> > imposes on that quota.
> > 
> > The nfs access cache can keep a large number of entries, and keep
> > them
> > indefinitely.  This can cause a user to go over-quota.
> > 
> > This series removes the 'struct cred *' from nfs_access_entry and
> > instead stores the uid, gid, and a pointer to the group info.
> > This makes the nfs_access_entry 64 bits larger.
> > 
> > Thanks,
> > NeilBrown
> > 
> > ---
> > 
> > NeilBrown (3):
> >       NFS: change nfs_access_get_cached to only report the mask
> >       NFS: pass cred explicitly for access tests
> >       NFS: don't store 'struct cred *' in struct nfs_access_entry
> > 
> > 
> >  fs/nfs/dir.c            | 63 ++++++++++++++++++++++++++++++++++---
> > ----
> >  fs/nfs/nfs3proc.c       |  5 ++--
> >  fs/nfs/nfs4proc.c       | 13 +++++----
> >  include/linux/nfs_fs.h  |  6 ++--
> >  include/linux/nfs_xdr.h |  2 +-
> >  5 files changed, 67 insertions(+), 22 deletions(-)
> > 
> > --
> > Signature
> > 
> > 

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com



  reply	other threads:[~2021-11-16 20:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-27 23:47 [PATCH 0/3] Don't store cred in nfs_access_entry NeilBrown
2021-09-27 23:47 ` [PATCH 3/3] NFS: don't store 'struct cred *' in struct nfs_access_entry NeilBrown
2021-09-27 23:47 ` [PATCH 1/3] NFS: change nfs_access_get_cached to only report the mask NeilBrown
2021-09-27 23:47 ` [PATCH 2/3] NFS: pass cred explicitly for access tests NeilBrown
2021-11-16 20:49 ` [PATCH 0/3] Don't store cred in nfs_access_entry NeilBrown
2021-11-16 20:57   ` Trond Myklebust [this message]
2021-11-16 21:03     ` NeilBrown
2021-11-16 21:35     ` Anna Schumaker

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=1b6b267598c8fcf5f50b6a118d88cf7ea938d076.camel@hammerspace.com \
    --to=trondmy@hammerspace.com \
    --cc=anna.schumaker@netapp.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.