Re: [BUG] 2038 warning is not printed with new mount API

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com