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

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

[Jon DeVree]

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

If play games with seccomp to hide the new mount APIs from util-linux,
it will fall back to the old mount API and the warning prints again.
-- 
Jon
Doge Wrangler
X(7): A program for managing terminal windows. See also screen(1) and tmux(1).

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

[Christian Brauner]

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 but then the format of the warning will have to
be slightly, changed. We could change it to:

[11526.621600] xfs filesystem supports timestamps until 2038 (0x7ffffff

libmount will log additional information about the mount to figure out
what filesystem caused this warning to be logged.

Would that work for you?

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

[Jon DeVree]

On Mon, Dec 02, 2024 at 12:55:13 +0100, Christian Brauner wrote:
> IMHO, the best place to log a warning is either at fsmount() time or at
> superblock creation time but then the format of the warning will have to
> be slightly, changed. We could change it to:
> 
> [11526.621600] xfs filesystem supports timestamps until 2038 (0x7ffffff
> 
> libmount will log additional information about the mount to figure out
> what filesystem caused this warning to be logged.
>

Maybe it could log the device node instead of the mount point? Then the
messages from both APIs could remain consistent. One is probably as good
as the other and the other mount related log messages all seem to be
using the device node:

[   39.379071] EXT4-fs (sda3): mounted filesystem with ordered data mode. Quota mode: none.
[   39.574146] XFS (sda4): Mounting V5 Filesystem

I assume that info is available at this point because the filesystems
are able to use it in their log messages, but I could be wrong.

>
> Would that work for you?
>

I don't really have a preference for how its fixed. I reported it
because I happened to notice it go missing after a system upgrade.

I did my best to make a small suggestion despite a lack of expertise in
this area.

-- 
Jon
Doge Wrangler
X(7): A program for managing terminal windows. See also screen(1) and tmux(1).

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

[Dave Chinner]

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

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

[Christian Brauner]

On Tue, Dec 03, 2024 at 04:12:45PM +1100, Dave Chinner wrote:
> 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.

I don't mind moving this into individual fill_super() methods for the
new mount api.

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

[Karel Zak]

On Mon, Dec 02, 2024 at 12:55:13PM GMT, Christian Brauner wrote:
> libmount will log additional information about the mount to figure out
> what filesystem caused this warning to be logged.

I will improve the functionality of mount(8) by adding extra messages,
including information when the --verbose option is used and warnings
by default. However, I do not think the kernel should rely on this.

The kernel log is valuable for post-analysis and archiving, and there
is no reason to modify the logging in the new API.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com