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: Thomas Klausner <wiz%NetBSD.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not
	supported. Stop.
Date: Tue, 10 Sep 2024 23:56:36 +0000

 > Date: Tue, 10 Sep 2024 20:58:38 +0200
 > From: Thomas Klausner <wiz%NetBSD.org@localhost>
 > 
 > On Tue, Sep 10, 2024 at 04:04:58PM +0000, Taylor R Campbell wrote:
 > > One path that crossed my mind is a race in readdir by multiple threads
 > > or processes on the same file object, which might have been fixed by
 > > <https://mail-index.netbsd.org/source-changes/2023/04/22/msg144249.html>
 > > (which has not been pulled up to netbsd-9), but I doubt that's
 > > happening here.
 > 
 > To clarify - I saw this yesterday in wip/emacs-git:
 > 
 > gmake[3]: *** readdir .: Invalid argument.  Stop.
 > gmake[3]: *** Waiting for unfinished jobs....
 > gmake[3]: Leaving directory '/scratch/wip/emacs-git/work/emacs/leim'
 > 
 > on 10.99.12/amd64 from Aug 28, so it's not fixed in HEAD yet.
 
 Great, that rules out that hypothesis!
 
 It looks like emacs28 is a candidate for a reproducer.  How frequently
 does this reproduce?  Can you run `gmake -jN clean && gmake -jN' in a
 loop in the build tree to trigger it (for whatever N is appropriate)?
 
 Might be worth running this concurrently:
 
 dtrace -n '
 	fbt::VOP_SEEK:entry {
 		self->vp = arg0;
 		self->oldoff = arg1;
 		self->newoff = arg2;
 	}
 	fbt::VOP_SEEK:return /arg1 == 22/ {
 		printf("vp=%p oldoff=%d newoff=%d", self->vp,
 		    self->oldoff, self->newoff);
 		print(*(struct vnode_impl *)self->vp);
 		@[stack()] = count();
 	}
 	fbt::VOP_SEEK:return {
 		self->vp = self->oldoff = self->newoff = 0
 	}
 '
 
 and hit ^C when it reproduces to get the stack trace output (which
 will probably just show sys_lseek -> vn_seek -> VOP_SEEK, but let's
 make sure it's not also nested in layerfs or something).
 
 > I'm not using nfs in this setup, but a standard 'mksandbox' chroot.
 > 
 > tmpfs on /archive/sandboxes/client1 type tmpfs (local)
 > [...]
 
 I don't see / or /scratch in your list of mounted file systems --
 what's the file system that /scratch/wip/emacs-git/work/emacs/leim
 lives on?  Is this chrooted in /archive/sandboxes/client1 so the
 answer is tmpfs?