From: Jeff Layton <jlayton@kernel.org>
To: "Luís Henriques" <lhenriques@suse.de>
Cc: ceph-devel@vger.kernel.org, idryomov@gmail.com, xiubli@redhat.com
Subject: Re: [PATCH] ceph: shrink dcache when adding a key
Date: Mon, 28 Mar 2022 12:24:16 -0400 [thread overview]
Message-ID: <2956c9efb7c048ed0636034bedced4be282a118f.camel@kernel.org> (raw)
In-Reply-To: <87r16mqct7.fsf@brahms.olymp>
On Mon, 2022-03-28 at 17:09 +0100, Luís Henriques wrote:
> Jeff Layton <jlayton@kernel.org> writes:
>
> > Any extant dentries under a directory will be invalid once a key is
> > added to the directory. Prune any child dentries of the parent after
> > adding a key.
> >
> > Cc: Luís Henriques <lhenriques@suse.de>
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > fs/ceph/ioctl.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > This one is for the ceph+fscrypt series.
> >
> > Luis, this seems to fix 580 and 593 for me. 595 still fails with it, but
> > that one is more related to file contents.
> >
> > diff --git a/fs/ceph/ioctl.c b/fs/ceph/ioctl.c
> > index 9675ef3a6c47..12d5469c5df2 100644
> > --- a/fs/ceph/ioctl.c
> > +++ b/fs/ceph/ioctl.c
> > @@ -397,7 +397,10 @@ long ceph_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> > ret = vet_mds_for_fscrypt(file);
> > if (ret)
> > return ret;
> > - return fscrypt_ioctl_add_key(file, (void __user *)arg);
> > + ret = fscrypt_ioctl_add_key(file, (void __user *)arg);
> > + if (ret == 0)
> > + shrink_dcache_parent(file_dentry(file));
> > + return ret;
>
> OK, a problem with this is that we're using the big hammer: this ioctl is
> being executed on the filesystem root and not the directory you're
> expecting. This is because keys can used for more than one directory.
> So, the performance penalty with this fix is probably not acceptable.
>
file represents an open file description, so file_dentry should be
wherever its path terminates. So, I think this should end up getting run
on the correct dentry.
Oh, but looking at the fscrypt command line application, yeah it does
seem to open the root of the fs, so this would end up purging a lot more
dentries than intended.
Fair enough...I'll drop this one. We'll need to think of some other way
to fix this.
--
Jeff Layton <jlayton@kernel.org>
prev parent reply other threads:[~2022-03-28 16:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-28 13:32 [PATCH] ceph: shrink dcache when adding a key Jeff Layton
2022-03-28 16:09 ` Luís Henriques
2022-03-28 16:24 ` Jeff Layton [this message]
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=2956c9efb7c048ed0636034bedced4be282a118f.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=idryomov@gmail.com \
--cc=lhenriques@suse.de \
--cc=xiubli@redhat.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.