Date: Thu, 20 Jun 2002 15:44:13 +1000 From: Joshua Goodall <joshua@roughtrade.net> To: "Semen A. Ustimenko" <semenu@FreeBSD.org> Cc: Joseph Scott <joseph@randomnetworks.com>, Boris Popov <bp@butya.kz>, freebsd-fs@FreeBSD.org, jeff@FreeBSD.org Subject: Re: NULLFS PRs (Was: Re: UFS dotdot lookup deadlock) Message-ID: <20020620054413.GA82672@roughtrade.net> In-Reply-To: <20020620070637.P3227-100000@def.the.net> References: <20020614064339.K3828-100000@def.the.net> <20020620070637.P3227-100000@def.the.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Semen,
It's probably worth appending to 37270, then; my original diagnoses
confused the 1.51 bugs with the drain bugs during an investigation
of the LOOKUP_SHARED problems and clarity would be appreciated from
someone with more VFS clue than I can currently bring on board.
Regards
Joshua
On Thu, Jun 20, 2002 at 07:26:41AM +0700, Semen A. Ustimenko wrote:
> Hi!
>
> Sorry for not fully investigated reply. There is no other problem in UFS,
> than that it hides the problem because it allows recursive lock to happen
> instead of ``locking against myself'' panic.
>
> The kern/37270 problem is in NULLFS. Step-by-step:
>
> NULLFS disregard LK_DRAIN flag. This means that the vnode may be
> successfully vclean()ed while some process was just sitting in
> vrele()->VOP_LOCK()->null_lock()->lockmgr(vp->v_vnlock)
>
> The above is exactly what leads to deadlock reported in PR, because when
> the lockmgr() exits, the nullfs vnode is already destroyed! Even though
> VOP_INACTIVE() is called, it can't unload the shared v_vnlock :(
>
> If anybody have ideas about how to fix this, please do not hesitate to
> share, but I can prevent you, that as soon as you begin to honor the
> LK_DRAIN flag, you immediately hit the deadlock I reported some time
> before. (IMHO, you don't hit it cause you usually win the race, but
> LK_DRAIN is born to loose it)
>
> Bye!
>
> On Sat, 15 Jun 2002, Semen A. Ustimenko wrote:
>
> > Hi!
> >
> > On Thu, 13 Jun 2002, Joseph Scott wrote:
> >
> > > On Thu, 13 Jun 2002, Semen Ustimenko wrote:
> > >
> > > # semenu 2002/06/13 10:30:40 PDT
> > > #
> > > # Modified files:
> > > # sys/fs/nullfs null_vnops.c
> > > # Log:
> > > # Fix wrong locking in null_inactive and null_reclaim. This makes nullfs
> > > # relatively working back.
> > > #
> > > # Reviewed by: mckusick, bp
> > >
> > > Any chance that this fix addresses PR kern/38107 (Panic on
> > > nullfs) or kern/37270 (nullfs broken by locking changes)? Unfortunately I
> > > don't understand what's involved here. These were the only two PR that
> > > mentioned nullfs that looked like they might be related to this commit.
> > >
> > Partially...
> >
> > kern/37270: This patch fixes the bug introduced in r1.51, but not the
> > problem with SHARED_LOOKUP.
> >
> > kern/38107: The panic is because v_rdev get dereferenced. It's not quite
> > clear to me how to create shadow vnode for spec vnode, neither if it is
> > necessary at all.
> >
> > I've just verified your method to deadlock, and it worked nicely (I mean
> > deadlocked nicely :). Here is what I found:
> >
> > When looking up the DOTDOT, in vfs_cache_lookup(), we VOP_UNLOCK()
> > parent directory, this is quite right... But the directory remains locked,
> > because it was recursively locked! This leads to deadlock...
> >
> > UFS allows the vnodes to be recursively locked and it seems that
> > softupdates require this. UFS gurus?
> >
> > Bye!
> >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-fs" in the body of the message
> >
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-fs" in the body of the message
--
"Running makeworld fast is important to me. Anything longer than
5-10 minutes is too long, since it is not reasonable to check every
commit using makeworld if it takes longer."
- Bruce Evans, ultimate guardian of build stability.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020620054413.GA82672>