lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <87zfwo2ats.fsf@mailhost.krisman.be> Date: Mon, 29 Jan 2024 16:34:07 -0300 From: Gabriel Krisman Bertazi <krisman@...e.de> To: Eric Biggers <ebiggers@...nel.org> Cc: viro@...iv.linux.org.uk, jaegeuk@...nel.org, tytso@....edu, linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net, linux-fsdevel@...r.kernel.org, amir73il@...il.com Subject: Re: [PATCH v3 04/10] fscrypt: Drop d_revalidate once the key is added Eric Biggers <ebiggers@...nel.org> writes: > On Thu, Jan 25, 2024 at 05:20:56PM -0300, Gabriel Krisman Bertazi wrote: >> Eric Biggers <ebiggers@...nel.org> writes: >> >> > On Fri, Jan 19, 2024 at 03:47:36PM -0300, Gabriel Krisman Bertazi wrote: >> >> /* >> >> * When d_splice_alias() moves a directory's no-key alias to its plaintext alias >> >> * as a result of the encryption key being added, DCACHE_NOKEY_NAME must be >> >> * cleared. Note that we don't have to support arbitrary moves of this flag >> >> * because fscrypt doesn't allow no-key names to be the source or target of a >> >> * rename(). >> >> */ >> >> static inline void fscrypt_handle_d_move(struct dentry *dentry) >> >> { >> >> dentry->d_flags &= ~DCACHE_NOKEY_NAME; >> >> + >> >> + /* >> >> + * Save the d_revalidate call cost during VFS operations. We >> >> + * can do it because, when the key is available, the dentry >> >> + * can't go stale and the key won't go away without eviction. >> >> + */ >> >> + if (dentry->d_op && dentry->d_op->d_revalidate == fscrypt_d_revalidate) >> >> + dentry->d_flags &= ~DCACHE_OP_REVALIDATE; >> >> } >> > >> > Is there any way to optimize this further for the case where fscrypt is not >> > being used? This is called unconditionally from d_move(). I've generally been >> > trying to avoid things like this where the fscrypt support slows things down for >> > everyone even when they're not using the feature. >> >> The problem would be figuring out whether the filesystem has fscrypt >> enabled. I think we can rely on sb->s_cop always being set: >> >> if (sb->s_cop) >> fscrypt_handle_d_move(dentry); >> >> What do you think? > > That's better, I just wonder if there's an even better way. Do you need to do > this for dentries that don't have DCACHE_NOKEY_NAME set? If not, it would be > more efficient to test for DCACHE_NOKEY_NAME before clearing the flags. I like that. We don't need it for dentries without DCACHE_NOKEY_NAME, because those dentries have the d_revalidate disabled at lookup-time. I raced my v4 with your comment, but I'll spin a v5 folding in this suggestion shortly. -- Gabriel Krisman Bertazi
Powered by blists - more mailing lists