re: panic in -current: "vp->v_iflag & VI_TEXT" failed: file "/usr/src/sys/kern/exec_subr.c", line 183

2022-03-08 Thread matthew green
matthew green writes:
> "J. Hannken-Illjes" writes:
> > 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.
>
> well, this ran until i ran out of file building the native gcc,
> it had been going for over an hour and was close to finishing.
>
> only one crash and not non crash, but this seems to help so far.
>
> i've cleaned the objdir and restarted, and i'll try again a couple
> more times when it's done.

this partial build completed, and 2 more since.

i say this fixes the problem.  thanks!


.mrg.


re: panic in -current: "vp->v_iflag & VI_TEXT" failed: file "/usr/src/sys/kern/exec_subr.c", line 183

2022-03-08 Thread matthew green
"J. Hannken-Illjes" writes:
> 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.

well, this ran until i ran out of file building the native gcc,
it had been going for over an hour and was close to finishing.

only one crash and not non crash, but this seems to help so far.

i've cleaned the objdir and restarted, and i'll try again a couple
more times when it's done.

thanks!


.mrg.


Re: panic in -current: "vp->v_iflag & VI_TEXT" failed: file "/usr/src/sys/kern/exec_subr.c", line 183

2022-03-08 Thread J. Hannken-Illjes
> On 8. Mar 2022, at 05:14, matthew green  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 - hann...@mailbox.org


vfs_node.c.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP