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

[Attilio Rao]

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?

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein