Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not supported. Stop.

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Mon, 02 Sep 2024 04:47:40 +1000
> from: matthew green <mrg%eterna23.net@localhost>
> 
> > Can you share your reproducer for this?  Maybe we can adapt it to an
> > atf test.
> 
> "use pkgsrc, see this failure every few weeks or so".

This is very mysterious.  I can't find any paths by which to explain
these results:

   1371   1371 gmake    CALL  open(0x499426,0x600004,0xf0)
   1371   1371 gmake    NAMI  "."
   1371   1371 gmake    RET   open 3
   1371   1371 gmake    CALL  __fstatvfs190(3,0xbfb066c0,2)
   1371   1371 gmake    RET   __fstatvfs190 0
   1371   1371 gmake    CALL  lseek(3,0,0,0,1)
   1371   1371 gmake    RET   lseek -1 errno 45 Operation not supported

Or:

   1487   1487 gmake    CALL  open(0xf7a426,0x600004,0xf0)
   1487   1487 gmake    NAMI  "."
   1487   1487 gmake    RET   open 3
   1487   1487 gmake    CALL  __fstatvfs190(3,0xbfb9c354,2)
   1487   1487 gmake    RET   __fstatvfs190 0
   1487   1487 gmake    CALL  lseek(3,0,0,0,1)
   1487   1487 gmake    RET   lseek 0
...
   1487   1487 gmake    CALL  lseek(3,0,0,0,1)
   1487   1487 gmake    RET   lseek -1 errno 22 Invalid argument

If I understand correctly, the funny ktrace output `lseek(3,0,0,0,1)'
means

	fd=3
	pad=0
	offlo=0
	offhi=0
	whence=1

or, in other words, it means the function call:

	lseek(/*fd*/3, /*off*/0, /*whence*/SEEK_CUR).

Somehow, that is returning EOPNOTSUPP or EINVAL.  But:

- sys_lseek can return EBADF, ESPIPE, or whatever .fo_seek returns.

- When fd 3 is the result of open("."), I think it is guaranteed that
  its underlying file's .fo_seek function is always vn_seek.  So it
  can return whatever vn_seek can return.

- vn_seek can return ESPIPE, whatever VOP_GETATTR returns, whatever
  VOP_SEEK returns, or EINVAL -- but EINVAL is only for values of
  whence other than SEEK_CUR/END/SET, so that can't be where EINVAL is
  coming from.

- ufs_getattr and tmpfs_getattr always unconditionally return 0.
  (nfs_getattr may fail, but mrg@ said this happens on ffs without any
  nfs involved.)

- VOP_SEEK is genfs_seek on essentially all file systems, and it only
  returns EINVAL if the new offset is negative, but this new offset is
  zero, so that can't be where EINVAL is coming from.  (Note: It does
  not return EINVAL if the new offset exceeds the current size.)

That exhausts all possible error codes I can find from lseek(2) on the
result of open(".") on ffs or tmpfs.

So where is EINVAL or EOPNOTSUPP coming from?