kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR

Kostik Belousov kostikbel at gmail.com
Wed Mar 18 06:10:03 PDT 2009


On Wed, Mar 18, 2009 at 09:59:14AM +0100, Attilio Rao wrote:
> 2009/3/14, Kostik Belousov <kostikbel at gmail.com>:
> > On Sat, Mar 14, 2009 at 11:21:35AM +0100, Peter Holm wrote:
> >  > On Sat, Mar 14, 2009 at 04:50:03AM +0000, Yoshihiro Ota wrote:
> >  > > The following reply was made to PR kern/132597; it has been noted by GNATS.
> >  > >
> >  > > From: Yoshihiro Ota <ota at j.email.ne.jp>
> >  > > To: bug-followup at FreeBSD.org
> >  > > Cc: bf2006a at yahoo.com
> >  > > Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while
> >  > >  interrupting a port build on tmpfs WRKDIR
> >  > > Date: Sat, 14 Mar 2009 00:42:58 -0400
> >  > >
> >  > >  Which ports were you compiling when panic happened?
> >  > >
> >  > >  Hiro
> >  >
> >  > The panic in this PR looks a lot like the one I reported to attilio@
> >  >
> >  > http://people.freebsd.org/~pho/stress/log/attilio022.txt
> >  >
> >  > It was just regular FS load that provoked it.
> >
> >
> > It seems to be quite clean what is going on there. In fact, there are
> >  two issues:
> >
> >  First is the usual problem of DOTDOT lookup that shall be fixed in style
> >  of vn_vget_ino() by busying mp before unlocking dvp.
> >
> >  Second one is the reason for the panic. The tmpfs vnode is unlocked, and
> >  then corresponding tmpfs _node_ is passed to the tmpfs_alloc_vp().
> >  Since the vnode may be reclaimed after the unlock, passed node might
> >  become freed. Then, the tmpfs_alloc_vp() would operate on the freed
> >  memory.
> 
> So I have a question.
> In the tmpfs_lookup() there is dvp with gets vhold() before to unlock
> the dvp vnode lock.
> That should not be enough to prevent recycling and freeing of the structure?

No. The only thing that prevents vnode reclaim is the vnode lock.
Both vhold and vref only prevent struct vnode * pointer from becoming
invalid, i.e. freeing vnode memory, and also keep vnode interlock and
lock functional. The difference between vhold and vref is that vref()
prevents non-forced unmounts from reclaiming such vnode.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090318/bf14780b/attachment.pgp


More information about the freebsd-fs mailing list