On Mon, Dec 02, 2024 at 12:55:13PM +0100, Christian Brauner wrote: > On Sun, Dec 01, 2024 at 10:57:59PM -0500, Jon DeVree wrote: > > When using the old mount API, the linux kernel displays a warning for > > filesystems that lack support for timestamps after 2038. This same > > warning does not display when using the new mount API > > (fsopen/fsconfig/fsmount) > > > > util-linux 2.39 and higher use the new mount API when available which > > means the warning is effectively invisible for distributions with the > > newer util-linux. > > > > I noticed this after upgrading a box from Debian Bookworm to Trixie, but > > its also reproducible with stock upstream kernels. > > > > From a box running a vanilla 6.1 kernel: > > > > With util-linux 2.38.1 (old mount API) > > [11526.615241] loop0: detected capacity change from 0 to 6291456 > > [11526.618049] XFS (loop0): Mounting V5 Filesystem > > [11526.621376] XFS (loop0): Ending clean mount > > [11526.621600] xfs filesystem being mounted at /mnt supports timestamps until 2038 (0x7fffffff) > > [11530.275460] XFS (loop0): Unmounting Filesystem > > > > With util-linux 2.39.4 (new mount API) > > [11544.063381] loop0: detected capacity change from 0 to 6291456 > > [11544.066295] XFS (loop0): Mounting V5 Filesystem > > [11544.069596] XFS (loop0): Ending clean mount > > [11545.527687] XFS (loop0): Unmounting Filesystem > > > > With util-linux 2.40.2 (new mount API) > > [11550.718647] loop0: detected capacity change from 0 to 6291456 > > [11550.722105] XFS (loop0): Mounting V5 Filesystem > > [11550.725297] XFS (loop0): Ending clean mount > > [11552.009042] XFS (loop0): Unmounting Filesystem > > > > All of them were mounting the same filesystem image that was created > > with: mkfs.xfs -m bigtime=0 > > With the new mount api the placement of the warning isn't clear: > > - If we warn at superblock creation time aka > fsconfig(FSCONFIG_CMD_CREATE) time but it's misleading because neither > a mount nor a mountpoint do exist. Hence, the format of the warning > has to be different. > > - If we warn at fsmount() time a mount exists but the > mountpoint isn't known yet as the mount is detached. This again means > the format of the warning has to be different. > > - If we warn at move_mount() we know the mount and the mountpoint. So > the format of the warning could be kept. > > But there are considerable downsides: > > * The fs_context isn't available to move_mount() > which means we cannot log this into the fscontext as well as into > dmesg which is annoying because it's likely that userspace wants to > see that message in the fscontext log as well. > > * Once fsmount() has been called it is possible for > userspace to interact with the filesystem (open and create > files etc.). > > If userspace holds on to to the detached mount, i.e., never calls > move_mount(), the warning would never be seen. > > * We'd have to differentiate between adding the first mount for a > given filesystems and bind-mounts. > > IMHO, the best place to log a warning is either at fsmount() time or at > superblock creation time It has to be done either during or after the ->fill_super() call where the filesystems read their superblocks from disk and set up the VFS superblock timestamp limits. Some of use filesystem developers wanted this timestamp warning to be implemented in each filesystem ->fill_super method for this reason - on-disk format information/warnings should be located with the code that sets up the filesystem state from the on-disk information. > but then the format of the warning will have to > be slightly, changed. Yes please! This was the other main objection to a generic VFS timestamp warning - inconsistent mount time log message formats. Filesytsems have their own message formats with consistent identifiers, and that's really what we should be using here. > We could change it to: > [11526.621600] xfs filesystem supports timestamps until 2038 (0x7ffffff Nope, now we have -zero- idea what filesystem emitted that warning when multiple filesystem are being mounted concurrently. i.e. it should be formatted exactly as xfs_notice(mp, ....) would format it: [11526.618049] XFS (loop0): Mounting V5 Filesystem [11526.621376] XFS (loop0): Ending clean mount [11526.621600] XFS (loop0): Filesystem supports timestamps until 2038 [11530.275460] XFS (loop0): Unmounting Filesystem We really -do not care- what the mount point is - it only needs to be emitted once, and should be emitted at the same time and format as all the other on-disk format feature messages that the filesystem emits from ->fill_super context. > libmount will log additional information about the mount to figure out > what filesystem caused this warning to be logged. No. That does not work when all you have to debug a crash is the dmesg log output and a stack trace. We have no idea what filesystem that log message belongs to. This is a real problem - just look at a typical syzbot failure trace. Which of the multiple filesystems it has mounted at any given time triggered that message? -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
