#1144613 linux-image-7.1.6+deb14-amd64: ext4 st_mtime and time() inconsistency

Package:
src:linux
Source:
src:linux
Submitter:
Vincent Lefevre
Date:
2026-08-19 17:11:02 UTC
Severity:
normal
#1144613#5
Date:
2026-08-17 00:39:20 UTC
From:
To:
With the Mutt MUA, after I quit the editor to compose a message
and ask to send the message, Mutt may complain (but rarely) that
the message was modified after I quit the editor. IIRC, this
actually occurred 3 times: the first time on June 3 with the
7.0.4+deb14-amd64 kernel and twice during this week-end with
the 7.1.6+deb14-amd64 kernel. I don't think that this has ever
occurred before June 3, during the many years of use of Mutt.

Mutt has code of the form

    if (stat(actx->idx[i]->content->filename, &st) != 0)
[stat error handling]
    if (actx->idx[i]->content->stamp < st.st_mtime)
[case "Attachment #%d modified. Update encoding for %s?"]

where actx->idx[i]->content->stamp is set after the editor has
terminated.

So it is expected that stamp is at least st.st_mtime.

The files are stored in /var/tmp, which is part of

/dev/mapper/qaa--vg-root on / type ext4 (rw,relatime,errors=remount-ro)
#1144613#10
Date:
2026-08-19 11:48:48 UTC
From:
To:
Here's a simple program to reproduce the issue. On my machine,
a difference is output many times every second (apparently,
when the clock is very close to an integer number of seconds).

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <sys/stat.h>

const char fname[] = "timetest.txt";

int main(void)
{
  while (1)
    {
      struct stat st;
      FILE *f;
      time_t t;

      f = fopen(fname, "w");
      if (f == NULL)
        exit(1);
      fclose(f);
      t = time(NULL);
      if (stat(fname, &st) != 0)
        exit(1);
      if (t < st.st_mtime)
        printf("%ld %ld\n", (long) t, (long) st.st_mtime);
    }
}
#1144613#15
Date:
2026-08-19 12:28:51 UTC
From:
To:
Control: retitle -1 linux-image-7.1.6+deb14-amd64: st_mtime and time() inconsistency
[...]

This also occurs in /dev/shm (tmpfs).

And I cannot reproduce this issue under Debian 13 (trixie) with
the 6.12.96+deb13-amd64 kernel.
#1144613#22
Date:
2026-08-19 13:50:16 UTC
From:
To:
Hi,
infrastructure for multigrain timestamps") and following in 6.13-rc1.

time(2) has only an accurancy in second, so the code might need to
use clock_gettime(2).

Regards,
Salvatore
#1144613#27
Date:
2026-08-19 14:22:53 UTC
From:
To:
The accuracy does not matter. This is a question of consistency.
If an event A occurs before an event B, one expects to have
time(A) <= time(B).
#1144613#32
Date:
2026-08-19 15:00:45 UTC
From:
To:
Probably not (or not entirely), as there is another issue not involving
the filesystem (see below).

Now, comparing time(NULL) and clock_gettime(CLOCK_REALTIME, &ts):

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main(void)
{
  while (1)
    {
      struct timespec ts;
      time_t t;

      clock_gettime(CLOCK_REALTIME, &ts);
      t = time(NULL);
      if (ts.tv_nsec < 0)
        exit(1);
      if (t < ts.tv_sec)
        printf("%ld %ld\n", (long) t, (long) ts.tv_sec);
    }
}

Since clock_gettime is called before time(NULL), one expects that
its time (including nanoseconds) is <= t, and since the number of
nanoseconds is non-negative (which is checked by the above code),
one should have ts.tv_sec <= t, i.e. the test t < ts.tv_sec should
be always false. But I get output at each second!
#1144613#37
Date:
2026-08-19 17:08:43 UTC
From:
To:
With the 6.12.96+deb13-amd64 kernel, I get the inconsistency
between time(NULL) and clock_gettime(CLOCK_REALTIME, ...),
and even with 6.1.0-52-amd64 (bookworm).

This could mean that this old issue propagated to the filesystem,
probably due to 4e40eff0b5737c.