Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 09 Jan 2009 20:23:10 -0500
From:      Joe Marcus Clarke <marcus@FreeBSD.org>
To:        Garrett Cooper <yanefbsd@gmail.com>
Cc:        freebsd-current@FreeBSD.org, Richard Todd <rmtodd@ichotolot.servalan.com>
Subject:   Re: Recent changes to pseudofs causing panics -- leaking a vnode lock?
Message-ID:  <1231550590.56664.21.camel@shumai.marcuscom.com>
In-Reply-To: <7d6fde3d0901091707u7e2ee080l75d8567a4093144d@mail.gmail.com>
References:  <20090109004853.GA34384@ichotolot.servalan.com> <1231541342.56664.19.camel@shumai.marcuscom.com> <7d6fde3d0901091707u7e2ee080l75d8567a4093144d@mail.gmail.com>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
On Fri, 2009-01-09 at 17:07 -0800, Garrett Cooper wrote:
> On Fri, Jan 9, 2009 at 2:49 PM, Joe Marcus Clarke <marcus@freebsd.org> wrote:
> > On Thu, 2009-01-08 at 18:48 -0600, Richard Todd wrote:
> >> I've noticed that ever since updating to a kernel after the recent changes
> >> to the pseudofs code late last month, that I've occasionally gotten the
> >> following sort of panic:
> >>
> >> System call readlink returning with the following locks held:
> >> exclusive lockmgr pseudofs (pseudofs) r = 0 (0xffffff00ba581cc8) locked @ /usr/src/sys/fs/pseudofs/pseudofs_vncache.c:193
> >> panic: witness_warn
> >>
> >> The line in question is the one I marked by an arrow in this chunk of the
> >> pfs_vncache_alloc code:
> >>         if ((pn->pn_flags & PFS_PROCDEP) != 0)
> >>                 (*vpp)->v_vflag |= VV_PROCDEP;
> >>         pvd->pvd_vnode = *vpp;
> >>         VN_LOCK_AREC(*vpp);
> >>         vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY); <==== this lock here
> >>         error = insmntque(*vpp, mp);
> >>
> >> So somehow, a vnode is getting locked here and not getting unlocked.
> >> I suspect the code in the retry2: loop later, simply because that's
> >> the code that got added in the late December commits, but I'm not
> >> clear on how exactly.  I've tried littering the code with extra
> >> printfs to try to clarify what's going on, but alas, I'm still not
> >> really sure what's going on.  I do have a good coredump that I can get
> >> info out of, if someone can suggest to me what would be useful things
> >> to dump.  Anyway, here's the patch for the debugging printfs I added,
> >> and the console messages produced by those printfs from the most
> >> recent coredump/panic.  The console msgs do seem to indicate some sort
> >> of race condition going on, though, as they seem to show two or more processes
> >> simultaneously hitting the pseudofs code and hitting my debugging print
> >> statements (alas, making the console log rather a confused mess.)
> >
> > I believe I have fixed this in HEAD.  Kib gave his review and approval,
> > and the fix really should prevent this hang.  Please report back if you
> > still see the problem.
> >
> > Joe
> 
> Joe,
>     When did you do this commit / what's the SVN revision #?

$FreeBSD: head/sys/fs/pseudofs/pseudofs_vncache.c 186981 2009-01-09
22:06:48Z marcus $

Joe

-- 
Joe Marcus Clarke
FreeBSD GNOME Team      ::      gnome@FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome

[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEABECAAYFAkln+H0ACgkQb2iPiv4Uz4c3WgCgjKUq+jrxwm2JwAJLyRKqft02
K4wAoJh0N3Z4GFSYzTP0hQ8VpMyADYvy
=S1zJ
-----END PGP SIGNATURE-----
help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1231550590.56664.21.camel>