DragonFlyBSD

I'm not sure this is the correct approach, but the attached patch
should fix this issue.

Joe

:I'm not sure this is the correct approach, but the attached patch
:should fix this issue.
:
:Joe
:...
:
:diff --git a/sys/dev/disk/vn/vn.c b/sys/dev/disk/vn/vn.c
:index 95bcf44..9f45281 100644
:--- a/sys/dev/disk/vn/vn.c
:+++ b/sys/dev/disk/vn/vn.c
:@ -697,7 +697,7 @ vnsetcred(struct vn_softc *vn, struct ucred *cred)
: * Set credits in our softc
: */
:
:- if (vn->sc_cred)
:+ if (vn->sc_cred && vn->sc_cred->cr_ref > 0)
: crfree(vn->sc_cred);
: vn->sc_cred = crdup(cred);

That can't be right.  If vn->sc_cred is set at all there must be a
    ref on it.  If there isn't something is leaking a crfree() without
    clearing it.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

On Fri, Jun 04, 2010 at 09:45:37PM -0700, Matthew Dillon wrote:

:I'm not sure this is the correct approach, but the attached patch
:should fix this issue.
:
:Joe
:...
:
:diff --git a/sys/dev/disk/vn/vn.c b/sys/dev/disk/vn/vn.c
:index 95bcf44..9f45281 100644
:--- a/sys/dev/disk/vn/vn.c
:+++ b/sys/dev/disk/vn/vn.c
:@ -697,7 +697,7 @ vnsetcred(struct vn_softc *vn, struct ucred *cred)
: * Set credits in our softc
: */
:
:- if (vn->sc_cred)
:+ if (vn->sc_cred && vn->sc_cred->cr_ref > 0)
: crfree(vn->sc_cred);
: vn->sc_cred = crdup(cred);

That can't be right. If vn->sc_cred is set at all there must be a
ref on it. If there isn't something is leaking a crfree() without
clearing it.

I've been looking at the backtrace and in frame 6 vn->sc_cred is 0x00
but cr in frame 5 is non-NULL and appears to be corrupted.

Joe

:> : * Set credits in our softc
:> : */
:> :
:> :- if (vn->sc_cred)
:> :+ if (vn->sc_cred && vn->sc_cred->cr_ref > 0)
:> : crfree(vn->sc_cred);
:> : vn->sc_cred = crdup(cred);
:>
:> That can't be right. If vn->sc_cred is set at all there must be a
:> ref on it. If there isn't something is leaking a crfree() without
:> clearing it.
:
:I've been looking at the backtrace and in frame 6 vn->sc_cred is 0x00
:but cr in frame 5 is non-NULL and appears to be corrupted.
:
:Joe

Check the rest of the vn structure and see if it is corrupted.  If
   it isn't then what is probably happening is some other subsystem
   (possibly part of the call path into vn, before it gets to vn) might
   be blowing up the credential.  It might not be VN's fault.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

On Sat, Jun 05, 2010 at 09:00:51AM -0700, Matthew Dillon wrote:

:> : * Set credits in our softc
:> : */
:> :
:> :- if (vn->sc_cred)
:> :+ if (vn->sc_cred && vn->sc_cred->cr_ref > 0)
:> : crfree(vn->sc_cred);
:> : vn->sc_cred = crdup(cred);
:>
:> That can't be right. If vn->sc_cred is set at all there must be a
:> ref on it. If there isn't something is leaking a crfree() without
:> clearing it.
:
:I've been looking at the backtrace and in frame 6 vn->sc_cred is 0x00
:but cr in frame 5 is non-NULL and appears to be corrupted.
:
:Joe

Check the rest of the vn structure and see if it is corrupted. If
it isn't then what is probably happening is some other subsystem
(possibly part of the call path into vn, before it gets to vn) might
be blowing up the credential. It might not be VN's fault.

The vn structure appears to NOT be corrupt. Seems like a race if
vn->sc_cred goes from NULL to non-NULL between frame 6 and 5. Could
this be related to my recent link_elf change (setting p to proc0 if p
is NULL)?

Joe

:The vn structure appears to NOT be corrupt. Seems like a race if
:vn->sc_cred goes from NULL to non-NULL between frame 6 and 5. Could
:this be related to my recent link_elf change (setting p to proc0 if p
:is NULL)?
:
:Joe

Hmm.  If devfs is racing access to that field then try changing the
    vnsetcred() code around a bit to this:

struct ucred *ocred
    ...

/*
 * Set credits in our softc
         */
        ocred = vn->sc_cred;
        vn->sc_cred = crdup(cred);
        if (ocred)
                crfree(ocred);

If the race is more involved then that (assuming it is a race), we
    may have to call crhold() and friends whenever we use vn->sc_cred.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

On Sat, Jun 05, 2010 at 12:26:47PM -0700, Matthew Dillon wrote:

:The vn structure appears to NOT be corrupt. Seems like a race if
:vn->sc_cred goes from NULL to non-NULL between frame 6 and 5. Could
:this be related to my recent link_elf change (setting p to proc0 if p
:is NULL)?
:
:Joe

Hmm. If devfs is racing access to that field then try changing the
vnsetcred() code around a bit to this:

struct ucred *ocred
...

/*

• Set credits in our softc
  */
  ocred = vn->sc_cred;
  vn->sc_cred = crdup(cred);
  if (ocred)
  crfree(ocred);

If the race is more involved then that (assuming it is a race), we
may have to call crhold() and friends whenever we use vn->sc_cred.

Sam,

Please try this patch. I was able to vnconfig a file following the
vkernel manpage without a panic. This isn't likely a long term
solution but will hopefully allow you to proceed with your GSoC work
in a vkernel. If you see this panic again let me know and I'll work
on implementing the crhold() et al. calls as Matt suggested.

Thanks,
Joe

On Sat, Jun 05, 2010 at 06:13:29PM -0400, Joe Talbott wrote:

Please try this patch. I was able to vnconfig a file following the
vkernel manpage without a panic. This isn't likely a long term
solution but will hopefully allow you to proceed with your GSoC work
in a vkernel. If you see this panic again let me know and I'll work
on implementing the crhold() et al. calls as Matt suggested.

Forgot to copy the patch to my mail server. This is the one I
intended to send.

Thanks,
Joe

Think this was entirely related to slightly out of sync kernel/modules.