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

[" Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/57145; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: matthew green <mrg%eterna23.net@localhost>
Cc: Andrew Cagney <andrew.cagney%gmail.com@localhost>,
	gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
Date: Mon, 2 Sep 2024 19:27:15 +0000

 > 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?