Re: [PATCH] meson: wire up USE_NSEC build knob

[Patrick Steinhardt <ps@pks.im>]

On Sun, Jun 21, 2026 at 01:49:34PM -0400, Jeff King wrote:
> On Sat, Jun 20, 2026 at 12:00:24PM -0400, D. Ben Knoble wrote:
> 
> > Autotools-style builds permit enabling USE_NSEC for cases where that's
> > desired; the equivalent knob is missing from meson-based builds.
> 
> Seems reasonable. This is not changing the defaults at all, but just
> bringing meson's options to parity with the Makefile.

I was originally wondering whether I should recommend that Meson can
auto-discover the availability of nanoseconds. But your below remarks
make me question that.

> I'm not still not sure if turning on USE_NSEC is a good idea. There's
> some discussion in Documentation/technical/racy-git.adoc:
> 
>   With `USE_NSEC`
>   compile-time option, `st_mtim.tv_nsec` and `st_ctim.tv_nsec`
>   members are also compared. On Linux, this is not enabled by default
>   because in-core timestamps can have finer granularity than
>   on-disk timestamps, resulting in meaningless changes when an
>   inode is evicted from the inode cache.  See commit 8ce13b0
>   of git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
>   ([PATCH] Sync in core time granularity with filesystems,
>   2005-01-04). This patch is included in kernel 2.6.11 and newer, but
>   only fixes the issue for file systems with exactly 1 ns or 1 s
>   resolution. Other file systems are still broken in current Linux
>   kernels (e.g. CEPH, CIFS, NTFS, UDF), see
>   https://lore.kernel.org/lkml/5577240D.7020309@gmail.com/
> 
> That's the most succinct description of the problem I've seen, but I
> have no idea how widely it still applies. Kernel 2.6.11 is quite old
> now, but I could believe that other filesystems (especially network
> ones) still exhibit the issue.
> 
> So I guess if we wanted to go further it would take some digging as to
> how each platform behaves, and then flipping the config.make.uname knob
> for ones where it can be argued that the behavior is always reasonable.

Yeah, it would be nice indeed to figure out whether these concerns still
apply. If they do, I would argue that it might even make sense to remove
the build option completely. It doesn't really make sense in my opinion
to have a build option that nobody uses and that is subtly broken when
enabled.

> But that's all outside the scope of your patch here.

Kind of, I guess. If we figure that this mechanism is still subtly broken
then I'd argue that it doesn't make sense to expose the option via
Meson.

Patrick