From: Patrick Donnelly <pdonnell@redhat.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: dev <dev@ceph.io>, Ceph Development <ceph-devel@vger.kernel.org>,
Luis Henriques <lhenriques@suse.com>,
Xiubo Li <xiubli@redhat.com>, Gregory Farnum <gfarnum@redhat.com>,
Douglas Fuller <dfuller@redhat.com>
Subject: Re: ceph-mds infrastructure for fscrypt
Date: Fri, 30 Apr 2021 07:45:56 -0700 [thread overview]
Message-ID: <CA+2bHPbxA+CBeWeSedVc+n_5ZqgUbqfmqqMOP-x8LBZHg2Ldww@mail.gmail.com> (raw)
In-Reply-To: <ce49bf7c10f86042a3b48d928f45ce186f0a427e.camel@redhat.com>
On Fri, Apr 30, 2021 at 7:33 AM Jeff Layton <jlayton@redhat.com> wrote:
> We specifically need this for directories and symlinks during pathwalks
> too. Eventually we may also want to encrypt certain data for other inode
> types as well (e.g. block/char devices). That's less critical though.
>
> The problem with fetching it after the inode is first instantiated is
> that we can end up recursing into a separate request while encoding a
> path. For instance, see this stack trace that Luis reported:
> https://lore.kernel.org/ceph-devel/53d5bebb28c1e0cd354a336a56bf103d5e3a6344.camel@kernel.org/T/#m0f7bbed6280623d761b8b4e70671ed568535d7fa
>
> While that implementation stored the context in an xattr, the problem
> isstill the same if you have to fetch the context in the middle of
> building a path. The best solution is just to always ensure it's
> available.
Got it. Splitting the struct makes sense then. The pin cap would be
suitable for the immutable encryption context (if truly
immutable?).Otherwise maybe the Axs cap?
--
Patrick Donnelly, Ph.D.
He / Him / His
Principal Software Engineer
Red Hat Sunnyvale, CA
GPG: 19F28A586F808C2402351B93C3301A3E258DD79D
next prev parent reply other threads:[~2021-04-30 14:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-22 18:18 ceph-mds infrastructure for fscrypt Jeff Layton
2021-04-23 11:46 ` Luis Henriques
2021-04-23 12:27 ` Jeff Layton
2021-04-29 23:46 ` Patrick Donnelly
2021-04-30 13:45 ` Jeff Layton
2021-04-30 14:20 ` Patrick Donnelly
2021-04-30 14:33 ` Jeff Layton
2021-04-30 14:45 ` Patrick Donnelly [this message]
2021-04-30 15:03 ` Jeff Layton
2021-05-01 1:03 ` Patrick Donnelly
2021-05-07 13:07 ` Jeff Layton
2021-05-07 17:15 ` Patrick Donnelly
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=CA+2bHPbxA+CBeWeSedVc+n_5ZqgUbqfmqqMOP-x8LBZHg2Ldww@mail.gmail.com \
--to=pdonnell@redhat.com \
--cc=ceph-devel@vger.kernel.org \
--cc=dev@ceph.io \
--cc=dfuller@redhat.com \
--cc=gfarnum@redhat.com \
--cc=jlayton@redhat.com \
--cc=lhenriques@suse.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).