> On 8. Mar 2022, at 05:14, matthew green <mrg%eterna.com.au@localhost> wrote:
>
> that's this:
>
> 175 vmcmd_map_pagedvn(struct lwp *l, struct exec_vmcmd *cmd)
> 176 {
> [ ... ]
> 181 vm_prot_t prot, maxprot;
> 182
> 183 KASSERT(vp->v_iflag & VI_TEXT);
>
> christos said this happened to him on a 8c/16t 64GB machine, using
> build.sh -j40, and i was able reproduce it on a 6c/12th 64GB machine.
> my build only got as far as installing includes (so literally right
> after tools were built.) the longer pacic message is:
>
> panic: kernel diagnostic assertion "vp->v_iflag & VI_TEXT" failed: file "/usr/src/sys/kern/exec_subr.c", line 183
> cpu9: Begin traceback...
> vpanic() at netbsd:vpanic+0x156
> kern_assert() at netbsd:kern_assert+0x4b
> vmcmd_map_pagedvn() at netbsd:vmcmd_map_pagedvn+0x137
> execve_runproc() at netbsd:execve_runproc+0x394
> execve1() at netbsd:execve1+0x4f
> sys_execve() at netbsd:sys_execve+0x2a
> syscall() at netbsd:syscall+0x196
> --- syscall (number 59) ---
> netbsd:syscall+0x196:
>
> my panic is the same as christos' -- inside execve1(). i'm getting
> a crash dump now, so i can probably inspect this further, but i'm
> wondering if this is related to the changes to vnode/nfs locking
> changes that came around a week ago:
>
> https://mail-index.netbsd.org/source-changes/2022/02/28/msg137218.html
> https://mail-index.netbsd.org/source-changes/2022/02/28/msg137219.html
>
> i don't know when this broke. i only really started looking because
> christos said he saw this problem..
I'm now able to reproduce it here -- takes about six hours to trigger.
I suppose vrelel() lost a check for new references with my last changes,
currently testing the diff attached.
--
J. Hannken-Illjes - hannken%mailbox.org@localhost
Attachment:
vfs_node.c.diff
Description: Binary data
Attachment:
signature.asc
Description: Message signed with OpenPGP