On Fri, Apr 30, 2021 at 7:33 AM Jeff Layton <jlayton(a)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…
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