[LTP] [PATCH] syscalls/utime03: relax the check for 1 second difference

[Jan Stancek]

On Thu, Feb 20, 2025 at 2:44 PM Jan Stancek <jstancek@redhat.com> wrote:
>
> On Thu, Feb 20, 2025 at 12:17 PM Cyril Hrubis <chrubis@suse.cz> wrote:
> >
> > Hi!
> > > The test is using tst_get_fs_timestamp() which is using REALTIME_COARSE
> > > clock, which is slightly less accurate. Back in 2022 we added extra log
> > > message to print also min and max time. In those rare instances where
> > > it fails this extra log shows it failed by one second difference.
> > >
> > > Relax the check a little. Tested on aarch64 VMs, where it's usually
> > > reproducible after couple hundred iterations.
> >
> > Aren't we just masking a kernel bug here? Back then we discussed this
> > with kernel devs and they told us that filesystems use REALTIME_COARSE
> > internally, so this shouldn't really fail.
>
> I see the failures resurfacing around 6.13-rc1.
> From commit 4e40eff0b573 ("fs: add infrastructure for multigrain timestamps")
> the comment on current_time() now says "Return FS time (possibly fine-grained)".

It is the series that adds multigrain timestamps. So we could make the maxtime
use REALTIME clock if "+1" second feels too broad.

>
> Maybe we hit a point where internals changed? I'll see if I can narrow
> it down further
> with bisect.
>
> >
> > What filesystem is this? Does it, by chance, use more granual
> > timestamps?
>
> I saw it fail on ext2, ext3 and xfs.
>
> >
> > --
> > Cyril Hrubis
> > chrubis@suse.cz
> >