Hello,
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?
Thanks,
Christian.
--
BOFH excuse #83:
Support staff hung over, send aspirin and come back LATER.
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?
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 <[email protected]>
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 <[email protected]>
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
On Thu, Dec 26, 2019 at 5:54 PM Christian Kujau <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
>
> 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
On Thu, Dec 26, 2019 at 5:54 PM Christian Kujau <[email protected]> wrote:
>
> 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.
How about just doing it once per mount?
IOW, if your issue is that you re-mount things read-only for backups
and then remount it rw again soon afterwards, but it's not actually
_unmounted_, maybe you could instead just add a flag to the 'struct
super_block' saying "this mount has been warned about already"?
That would seem to make sense regardless. No? Partoicularly since we
also don't want to warn multiple times just because the same thing
gets mounted in multiple places.
Of course, if you actually unmount and completely re-mount a
filesystem, then that would still warn multiple times, but at that
point I think it's reasonable to do.
Linus
On Sun, 29 Dec 2019, Linus Torvalds wrote:
> > 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.
>
> How about just doing it once per mount?
Yes, once per mount would work, and maybe not print a warning on remounts
at all.
Commit f8b92ba67c5d ("mount: Add mount warning for impending timestamp
expiry") introduced:
Mounted %s file system at %s supports timestamps until [...]
in mnt_warn_timestamp_expiry(), but then 0ecee6699064 ("fs/namespace.c:
fix use-after-free of mount in mnt_warn_timestamp_expiry") changed this to
%s filesystem being %s at %s supports timestamps until [...]
in order to fix a use-after-free.
> Of course, if you actually unmount and completely re-mount a
> filesystem, then that would still warn multiple times, but at that
> point I think it's reasonable to do.
Yes, of course. Umount/remount cycles should still issue a warning, but
"-o remount" should not, IMHO.
Thanks,
Christian.
--
BOFH excuse #108:
The air conditioning water supply pipe ruptured over the machine room
On Sat, 4 Jan 2020, Christian Kujau wrote:
> On Sun, 29 Dec 2019, Linus Torvalds wrote:
> > > 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.
> >
> > How about just doing it once per mount?
>
> Yes, once per mount would work, and maybe not print a warning on remounts
> at all.
Is there any chance that this can be revisited perhaps? This is still
flooding my dmesg just because I have that (curde?) mechanism in place to
remount the backup device after the hourly backup-run to read-only. Sure,
I could omit that ("Doc, it hurts when I do that", as Al would comment),
but that's really the only repeating message that gets triggered because
of this. 1067 messages in ~60 days of uptime :-|
Does the patch below make any sense, would that work?
Please reconsider,
Christian.
> Commit f8b92ba67c5d ("mount: Add mount warning for impending timestamp
> expiry") introduced:
>
> Mounted %s file system at %s supports timestamps until [...]
>
> in mnt_warn_timestamp_expiry(), but then 0ecee6699064 ("fs/namespace.c:
> fix use-after-free of mount in mnt_warn_timestamp_expiry") changed this to
>
> %s filesystem being %s at %s supports timestamps until [...]
>
> in order to fix a use-after-free.
>
> > Of course, if you actually unmount and completely re-mount a
> > filesystem, then that would still warn multiple times, but at that
> > point I think it's reasonable to do.
>
> Yes, of course. Umount/remount cycles should still issue a warning, but
> "-o remount" should not, IMHO.
>
> Thanks,
> Christian.
commit c9a5338b4930cdf99073042de0717db43d7b75be
Author: Christian Kujau <[email protected]>
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 <[email protected]>
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 #66:
bit bucket overflow
Hi,
On Tue, Jun 23, 2020 at 05:26:49PM -0700, Christian Kujau wrote:
> On Sat, 4 Jan 2020, Christian Kujau wrote:
> > On Sun, 29 Dec 2019, Linus Torvalds wrote:
> > > > 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.
> > >
> > > How about just doing it once per mount?
> >
> > Yes, once per mount would work, and maybe not print a warning on remounts
> > at all.
>
> Is there any chance that this can be revisited perhaps? This is still
> flooding my dmesg just because I have that (curde?) mechanism in place to
> remount the backup device after the hourly backup-run to read-only. Sure,
> I could omit that ("Doc, it hurts when I do that", as Al would comment),
> but that's really the only repeating message that gets triggered because
> of this. 1067 messages in ~60 days of uptime :-|
>
> Does the patch below make any sense, would that work?
>
> Please reconsider,
> Christian.
>
> > Commit f8b92ba67c5d ("mount: Add mount warning for impending timestamp
> > expiry") introduced:
> >
> > Mounted %s file system at %s supports timestamps until [...]
> >
> > in mnt_warn_timestamp_expiry(), but then 0ecee6699064 ("fs/namespace.c:
> > fix use-after-free of mount in mnt_warn_timestamp_expiry") changed this to
> >
> > %s filesystem being %s at %s supports timestamps until [...]
> >
> > in order to fix a use-after-free.
> >
> > > Of course, if you actually unmount and completely re-mount a
> > > filesystem, then that would still warn multiple times, but at that
> > > point I think it's reasonable to do.
> >
> > Yes, of course. Umount/remount cycles should still issue a warning, but
> > "-o remount" should not, IMHO.
> >
> > Thanks,
> > Christian.
>
> commit c9a5338b4930cdf99073042de0717db43d7b75be
> Author: Christian Kujau <[email protected]>
> 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 <[email protected]>
>
> 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,
This is somehow prompted by a recent update in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996876#46 .
The discussion on the above seems to have stalled, is this still
something worth persuing or should it be further ignored?
Regards,
Salvatore