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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABeXuvqimxsa45ir-zpOQS_1M5buPaT3VMvigqo6oTUgMj0z8g@mail.gmail.com>
Date:   Sat, 28 Dec 2019 11:51:23 -0800
From:   Deepa Dinamani <deepa.kernel@...il.com>
To:     Christian Kujau <lists@...dbynature.de>
Cc:     Jeff Layton <jlayton@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Eric Biggers <ebiggers@...gle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Arnd Bergmann <arnd@...db.de>,
        Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] Re: filesystem being remounted supports timestamps until 2038

On Thu, Dec 26, 2019 at 5:54 PM Christian Kujau <lists@...dbynature.de> wrote:
>
> On Fri, 20 Dec 2019, Christian Kujau wrote:
> > I noticed the following messages in my dmesg:
> >
> >  xfs filesystem being remounted at /mnt/disk supports imestamps until 2038 (0x7fffffff)
> >
> > These messages get printed over and over again because /mnt/disk is
> > usually a read-only mount that is remounted (rw) a couple of times a day
> > for backup purposes.
> >
> > I see that these messages have been introduced with f8b92ba67c5d ("mount:
> > Add mount warning for impending timestamp expiry") resp. 0ecee6699064
> > ("fix use-after-free of mount in mnt_warn_timestamp_expiry()") and I was
> > wondering if there is any chance to either adjust this to pr_debug (but
> > then it would still show up in dmesg, right?) or to only warn once when
> > it's mounted, but not on re-mount?

The warnings only make sense when you mount the filesystem rw because
it is the updating of timestamps that fail.
We can discuss what the log level of such messages should be.
pr_warn() seems correct to me to serve the purpose of the feature.
And, warning at the site of remount as rw seems correct also rather
than at the site of mount.
Maybe checking if it was already a rw mount and only warning the first
time might alleviate your problem? Adding Arnd and Al to see if they
have any suggestions.

-Deepa

> I realize that "it's the holidays", but it'd be a shame if this gets
> forgotten :(
>
>
> # uptime; dmesg | grep -c 2038
>  14:45:15 up 6 days, 21:16,  1 user,  load average: 0.20, 0.22, 0.27
> 350
>
> Attached is a "fix" that changes pr_warn into pr_debug, but that's maybe
> not what was intended here.
>
>
> Thanks,
> Christian.
>
>
> commit c9a5338b4930cdf99073042de0717db43d7b75be
> Author: Christian Kujau <lists@...dbynature.de>
> Date:   Thu Dec 26 17:39:57 2019 -0800
>
>     Commit f8b92ba67c5d ("mount: Add mount warning for impending timestamp expiry") resp.
>     0ecee6699064 ("fix use-after-free of mount in mnt_warn_timestamp_expiry()") introduced
>     a pr_warn message and the following gets sent to dmesg on every remount:
>
>      [...] filesystem being remounted at /mnt supports timestamps until 2038 (0x7fffffff)
>
>     When file systems are remounted a couple of times per day (e.g. rw/ro for backup
>     purposes), dmesg gets flooded with these messages. Change pr_warn into pr_debug
>     to make it stop.
>
>     Signed-off-by: Christian Kujau <lists@...dbynature.de>
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index be601d3a8008..afc6a13e7316 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -2478,7 +2478,7 @@ static void mnt_warn_timestamp_expiry(struct path *mountpoint, struct vfsmount *
>
>                 time64_to_tm(sb->s_time_max, 0, &tm);
>
> -               pr_warn("%s filesystem being %s at %s supports timestamps until %04ld (0x%llx)\n",
> +               pr_debug("%s filesystem being %s at %s supports timestamps until %04ld (0x%llx)\n",
>                         sb->s_type->name,
>                         is_mounted(mnt) ? "remounted" : "mounted",
>                         mntpath,
>
>
>
> -- BOFH excuse #132:
>
> SCSI Chain overterminated

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ