Re: strange message before sending mail

Vincent Lefevre wrote in
 <[email protected]>:
 |On 2026-06-03 17:38:11 +0800, Kevin J. McCarthy wrote:
 |> On Wed, Jun 03, 2026 at 10:51:45AM +0200, Vincent Lefevre wrote:
 |>> On 2026-06-03 10:38:41 +0200, Vincent Lefevre wrote:
 |>>> (in sendlib.c), is it guaranteed that the filesystem uses the same
 |>>> clock as time()? This might not be the case because according to
 |>>> /usr/bin/stat, the filesystem here has a time resolution of less
 |>>> than 1 second while time() has a 1-second time resolution.
 |> 
 |> Better to let Greg KH or Alex chime in here.  I was under the impression
 |> that modern Linux has resolved clock synchronization issues across cores.
 |> 
 |> There may be a very rare issue with the actual "write" not making \
 |> it all the
 |> way to disk and setting mtime before mutt grabs time().
 ...
 |Something else... I don't remember what I did here. Usually, I save
 |the file with C-x C-s, then quit Emacs with C-x C-c. So there's about
 |a 1-second delay, which should be enough to avoid issues if there is
 |a tiny difference between different clocks or caches. But it is not
 |impossible that I did C-x C-c without saving first, so that Emacs asks
 |me whether I want to save the file, and in such an uncommon case, the
 |file save and the time() call from Mutt would occur at almost the same
 |time.
 |
 |Otherwise, since Mutt doesn't do a stat() in mutt_stamp_attachment(),
 |I'm wondering whether this could be an issue like
 |
 |  https://lists.openwall.net/linux-ext4/2022/05/11/15
 |
 |which I had 4 years ago on another machine: a file was actually
 |created about 30 seconds after the openat()+O_CREAT system call!

There are quite some bugs here and there, and kernel updates
happen quite often, so they come and go.  ??
Fwiw, because "birth time unknown", but in my power-supply.sh (via
udev or acpid) i set in "off" case

  vm.dirty_writeback_centisecs=3000 \
                vm.stat_interval=60

I currently, but luckily not with this monthly big update,
struggle a bit with a BTRFS NULL dereference kernel bug, that
noone seems to know about but me -- isn't that strange?  And that
is not the first such bug.  (Needless to say that noone responds
to bugzilla .. but i hope it is on the radar.)

(Luckily the Linux kernel seems to completely block the entire
system then .. ie anything "which needs the VFS / filesystem" is
blocked, so the damage is .. hopefully really zero.  It is fun,
you can do some things, "echo hello world" and such, switch tmux
windows, and all that.  But otherwise, death.
I mean, *that* is so unbelievable great, you know?  Just with this
week's laptop start for example i got a minute hang with only
partially usable keyboard and permanently unusable mouse, but
until Tuesday's laptop wakeup, with log entries like
    Jun  1 17:41:19 kent kernel: task:init            state:S stack:0     pid:1     ppid:0      flags:0x00000002
    Jun  1 17:41:19 kent kernel: Call Trace:
    Jun  1 17:41:19 kent kernel:  <TASK>
    Jun  1 17:41:19 kent kernel:  ? __schedule+0x226/0xeb0
    ...
    Jun  1 17:41:19 kent kernel:  ? __hrtimer_init+0xf0/0xf0
    Jun  1 17:41:19 kent kernel:  ? do_select+0x70d/0x9b0
    Jun  1 17:41:19 kent kernel:  ? __pollwait+0x100/0x100
    Jun  1 17:41:19 kent last message buffered 3 times

  for all kernel threads in fact in kernel log vs

    Jun  1 17:41:20 kent syslogd[517]: Kernel log buffer filling up too quick, or too small log buffer, adjust kernel CONFIG_LOG_BUF_SHIFT
    Jun  1 17:41:20 kent last message buffered 88 times
    Jun  1 17:41:21 kent /root/bin/syslog-notify.sh: rotate: /var/log/kernel
, quoting myself from another correspondence, but, you know, that
shit thing is usable and runs and there is no perceivable
problem!!  It just runs.  Booaah!!  That is grazy.)

But with the above bug i was left with zero sized tarballs from
download actions that happened over many, many seconds (beyond
default numbers, which are ..
  vm.dirty_writeback_centisecs = 500
  vm.stat_interval = 1
plus garbage git(1) (which concurrently acted iirc) tmp_ packs, so
.. anyway it seems a VFS / cache layer is a complex beast, and
likely even heavily contested etc, so .. whatever?

  https://bugzilla.kernel.org/show_bug.cgi?id=221305

Regarding ext4 it seems T'so is very prowd and happy of its unit
test, which surely was a tremendous work and pain to get right.


--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)