Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: [PATCH 0/3] Don't store cred in nfs_access_entry
From:   NeilBrown <neilb@suse.de>
To:     Trond Myklebust <trond.myklebust@hammerspace.com>,
        Anna Schumaker <anna.schumaker@netapp.com>
Cc:     linux-nfs@vger.kernel.org
Date:   Tue, 28 Sep 2021 09:47:57 +1000
Message-ID: <163278643081.17728.10586733395858659759.stgit@noble.brown>
User-Agent: StGit/0.23
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Precedence: bulk

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