kern/55370: Invalid modification/connection time with mount_null(8)

[triaxx%netbsd.org@localhost]

>Number:         55370
>Category:       kern
>Synopsis:       Invalid modification/connection time with mount_null(8)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jun 12 10:00:00 +0000 2020
>Originator:     Frederic Fauberteau
>Release:        NetBSD 9.99.64
>Organization:
>Environment:
	
	
System: NetBSD hydralisk.triaxx.org 9.99.64 NetBSD 9.99.64 (GENERIC) #0: Wed Jun  3 07:06:18 UTC 2020  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
Some files seem to have inconsistent modification time when they are created on null filesystem. The problem has been identified due to configuration/building errors for some pkgsrc packages built using pbulk in sandbox with PKGSRCDIR and WRKOBJDIR mounted as null filesystem.

Here is the example of fonts/unifont:

Part of src/Makefile:
--------------------------------------------------
LOCALBINDIR = ../bin

CPROGS = unibmp2hex unicoverage unidup unibdf2hex unibmpbump \
   unifont1per unifontpic unigencircles unigenwidth \
   unihex2bmp unihexgen unipagecount
   
all: $(CPROGS) bin

bin: bin-stamp

bin-stamp: $(CPROGS)
  install -m0755 -d $(LOCALBINDIR)
  install -m0755 $(CPROGS) $(LOCALBINDIR)
  \rm -f $(CPROGS)
  touch $@
--------------------------------------------------

I consider two working directories for WRKOBJDIR: /tmp/work and /tmp/null as a binding of /tmp/work using mount_null(8).
$ mkdir /tmp/work /tmp/null
# mount -t null /tmp/work /tmp/null

First, I configure fonts/unifont to /tmp/work using the pkgsrc framework and I manually run make to inspect the times of some files.
$ bmake WRKOBJDIR=/tmp/work configure
$ cd /tmp/work/fonts/unifont/work/unifont-13.0.02
$ /usr/pkg/bin/gmake
$ $ stat -f "st_atime=%a st_mtime=%m %N" src/bin-stamp bin/unibmp2hex                             
st_atime=1591954072 st_mtime=1591954072 src/bin-stamp
st_atime=1591954072 st_mtime=1591954072 bin/unibmp2hex

Using the debug option of gmake, I can inspect the prerequisites of target when I try to run 'make install':
$ /usr/pkg/bin/gmake -d > make.dump 2>&1

     Prerequisite '../bin/unibmp2hex' is older than target 'bin-stamp'.
     
Then, I configure fonts/unifont to /tmp/null (after cleaning the previous configuration) and I reproduce the same process.
$ bmake WRKOBJDIR=/tmp/null configure
$ cd /tmp/null/fonts/unifont/work/unifont-13.0.02
$ ktrace -di /usr/pkg/bin/gmake
$ stat -f "st_atime=%a st_mtime=%m %N" src/bin-stamp bin/unibmp2hex 
st_atime=1591954536 st_mtime=1591954536 src/bin-stamp
st_atime=1591954536 st_mtime=1591954541 bin/unibmp2hex

Now the value of st_mtime differs from the one of st_atime. It results in an unexpected behavior during the prerequisite analysis when running 'make install':
$ /usr/pkg/bin/gmake -d > make.dump 2>&1

     Prerequisite '../bin/unibmp2hex' is newer than target 'bin-stamp'.

When I inspect the trace produced by make (kdump -T | less), I can notice that the time of the last syscall that handles unibmp2hex is a time 1591954536:
 20569  20569 rm       1591954536.785814687 CALL  unlink(0x7f7fff63ddbe)
 20569  20569 rm       1591954536.785817137 NAMI  "unibmp2hex"

The modification time of 1591954541 for bin/unibmp2hex seems not to be due to make since the last line of the trace is prior:
 15647  15647 gmake    1591954537.052526140 CALL  exit(0)
>How-To-Repeat:
The problem is reproducible.
>Fix: