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
| ||
|
Date: Thu, 20 Feb 2020 18:11:04 +0300 From: Konstantin Khlebnikov <khlebnikov@...dex-team.ru> To: "Theodore Y. Ts'o" <tytso@....edu> Cc: Andreas Dilger <adilger.kernel@...ger.ca>, linux-ext4@...r.kernel.org, Karel Zak <kzak@...hat.com>, Dmitry Monakhov <dmtrmonakhov@...dex-team.ru> Subject: Re: [PATCH] ext4: fix handling mount -o remount,nolazytime On 19/02/2020 19.22, Theodore Y. Ts'o wrote: > On Wed, Feb 19, 2020 at 12:19:52PM +0300, Konstantin Khlebnikov wrote: >> Tool "mount" from util-linux >= 2.27 knows about flag MS_LAZYTIME and >> handles options "lazytime" and "nolazytime" as fs-independent. >> >> For ext4 it works for enabling lazytime: mount(MS_REMOUNT | MS_LAZYTIME), >> but does not work for disabling: mount(MS_REMOUNT). >> >> Currently ext4 has performance issue in lazytime implementation caused by >> contention around inode_hash_lock in ext4_update_other_inodes_time(). >> >> Fortunately lazytime still could be disabled without unmounting by passing >> "nolazytime" as fs-specific mount option: mount(MS_REMOUNT, "nolazytime"). >> But modern versions of tool "mount" cannot do that. >> >> This patch fixes remount for modern tool and keeps backward compatibility. > > Actually, if you are using ancient versions of mount that don't know > about MS_LAZYTIME, then when you do something like mount -o > remount,usrquota /dev/sdb" with your patch, it will disable > MS_LAZYTIME, which would be a backwards incompatible change. > > So if we make this change, and there is someone who wants to use > lazytime on some ancient enterprise linux system which is still using > an old version of util-linux, and then take a kernel with this change, > then it will result in a change in the behavior they will see. The > good news is that RHEL 8 is using util-linux 2.32, but RHEL 7 is still > using util-linux 2.23. > > Lazytime is not enabled by default, so this issue is really only a > problem for someone which explicitly enables lazytime using a newer > version of util-linux, and then disables lazytime with a newer version > of util-linux. So the behaviour of a2fd66d069d8 ("ext4: set lazytime > on remount if MS_LAZYTIME is set by mount") was in fact an explicit > decision to do things in that way. > > So maybe we might want to change things, assuming that it's unlikely > users will try to be running new kernels on ancient distros. But I > really wouldn't want to add a Fixes tag, and I would want to make sure > this doesn't get backported to older kernels, since the change does > *not* keep backwards compatibility. > > Unfortunately, it's not possible to do this without breaking > compatibility for at least some systems. The question is whether or > not we think systems running util-linux less than 2.27 is something we > care about for new kernels. Times may have changed since > a2fd66d069d8. > > So I might be willing to take this patch (I invite comments from > others), but there will need to be a DO NOT BACKPORT warning in the > commit description. Usually all these options are saved in /etc/fstab and mount -o remount,... includes them into line passed into syscall. In this case remounting any other option will not disable lazytime. But there might be implementations of /bin/mount which doesn't do that. > > Cheers, > > - Ted >
Powered by blists - more mailing lists