Date: Sat, 3 Sep 2005 09:23:18 +0200 From: Suleiman Souhlal <ssouhlal@FreeBSD.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/fs/nullfs null_vnops.c Message-ID: <D8DF240D-9A97-467A-A125-2F1A75EBA9EA@FreeBSD.org> In-Reply-To: <20050902184655.C4631@10.0.0.1> References: <200509021549.j82Fnut9051619@repoman.freebsd.org> <20050902184655.C4631@10.0.0.1>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
On Sep 3, 2005, at 3:48 AM, Jeff Roberson wrote:
> I'm not sure that this is correct. The line:
> lockmgr(vnlock, LK_RELEASE, NULL, curthread);
>
> Should unlock the lower node which vput would have already
> unlocked. It must be done this way to properly adjust the vnlock ptr.
I'm not sure I understand what you're saying. After this commit, the
code is:
vnlock = vp->v_vnlock;
vp->v_vnlock = &vp->v_lock;
lockmgr(vp->v_vnlock, LK_EXCLUSIVE, NULL, curthread);
if (lowervp) {
vput(lowervp);
} else
lockmgr(vnlock, LK_RELEASE, NULL, curthread);
Which I believe unlocks things in the right order.
However, after discussing with kan@, we identified two races:
- There is a short time between changing the pointer and locking
vp->v_lock during which someone might steal the lock from us, so we
should hold the interlock during these two operations.
- Someone might be waiting on the lower vnode's lock, and when
it is released, he might think that he has the vnode. I am unsure how
this can be fixed.
--
Suleiman Souhlal | ssouhlal@vt.edu
The FreeBSD Project | ssouhlal@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D8DF240D-9A97-467A-A125-2F1A75EBA9EA>