On Fri, Apr 30, 2021 at 7:33 AM Jeff Layton <jlayton@xxxxxxxxxx> 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@xxxxxxxxxx/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 _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
