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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 19 Jul 2022 09:51:33 -0400 From: Jeff Layton <jlayton@...nel.org> To: tytso@....edu, adilger.kernel@...ger.ca Cc: linux-ext4@...r.kernel.org, linux-fsdevel <linux-fsdevel@...r.kernel.org>, lczerner@...hat.com, Benjamin Coddington <bcodding@...hat.com> Subject: should we make "-o iversion" the default on ext4 ? Back in 2018, I did a patchset [1] to rework the inode->i_version counter handling to be much less expensive, particularly when no-one is querying for it. Testing at the time showed that the cost of enabling i_version on ext4 was close to 0 when nothing is querying it, but I stopped short of trying to make it the default at the time (mostly out of an abundance of caution). Since then, we still see a steady stream of cache-coherency problems with NFSv4 on ext4 when this option is disabled (e.g. [2]). Is it time to go ahead and make this option the default on ext4? I don't see a real downside to doing so, though I'm unclear on how we should approach this. Currently the option is twiddled using MS_I_VERSION flag, and it's unclear to me how we can reverse the sense of such a flag. Thoughts? [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4b7fd7d34de5765dece2dd08060d2e1f7be3b39 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=2107587 -- Jeff Layton <jlayton@...nel.org>
Powered by blists - more mailing lists