On Tue, Mar 31, 2020 at 07:01:52AM +0000, Bryan Stenson wrote:
> yes, but for an unrelated issue (lots of learning in these isolated times).
>
> On Tue, Mar 31, 2020 at 7:00 AM Theo de Raadt <[email protected]> wrote:
> >
> > Were you really performing a ktrac of pflogd?
> >
> > Bryan Stenson <[email protected]> wrote:
> >
> > > ok...found the panic call here: sys/ufs/ufs/ufs_quota.c:451. From the
> > > comment in the code: "On filesystems with quotas enabled, it is an
> > > error for a file to change size and not to have a dquot structure
> > > associated with it."
> > >
> > > I do have quotas enabled on /home, but limits are only set for a
> > > single user (no groups). Otherwise, I don't think I'm doing anything
> > > crazy/out-of-the-ordinary. Clearly, the kernel got here, but I'm not
> > > sure how.
How did you start ktracing pflodg? Was it done as part of the
boot process? If so, quotaon(8) could miss the trace file vnode,
causing the panic.
The following diff might fix the bug. It makes sure that the trace file
vnode has non-zero v_writecount. This should prevent the kernel from
missing the vnode when turning on quotas (quotaon_vnode() skips vnodes
whose v_writecount is zero).
Index: kern/kern_ktrace.c
===================================================================
RCS file: src/sys/kern/kern_ktrace.c,v
retrieving revision 1.102
diff -u -p -r1.102 kern_ktrace.c
--- kern/kern_ktrace.c 23 Mar 2020 15:45:39 -0000 1.102
+++ kern/kern_ktrace.c 31 Mar 2020 15:41:41 -0000
@@ -83,6 +83,7 @@ ktrcleartrace(struct process *pr)
pr->ps_tracevp = NULL;
pr->ps_tracecred = NULL;
+ vp->v_writecount--;
vrele(vp);
crfree(cred);
}
@@ -109,6 +110,7 @@ ktrsettrace(struct process *pr, int facs
vref(newvp);
crhold(newcred);
+ newvp->v_writecount++;
oldvp = pr->ps_tracevp;
oldcred = pr->ps_tracecred;
