Date: Tue, 10 Dec 2002 13:23:59 -0800 (PST)
From: Nate Lawson <nate@root.org>
To: Yar Tikhiy <yar@freebsd.org>
Cc: freebsd-scsi@freebsd.org
Subject: Re: {da,sa,...}open bug?
Message-ID: <Pine.BSF.4.21.0212101320570.28346-100000@root.org>
In-Reply-To: <20021210143954.B14989@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Dec 2002, Yar Tikhiy wrote: > On Mon, Dec 09, 2002 at 01:52:23PM -0800, Nate Lawson wrote: > > This patch is bad since you need to move the acquire earlier, not > > later. By moving it to the end, you increase the window where another > > proc could release the periph and free it. > > Why, is the knowledge that cam_periph_lock() calls cam_periph_acquire() > first of all considered secret? :-) The idea behind my patch was > as follows: having called cam_periph_lock() ensures the periph won't > disappear while it's being opened; and if the open succeeds, another > reference to the periph is obtained so it won't go away until it's > closed, and the former reference is released, which is one of > cam_periph_unlock() effects. Here is what would happen with your patch: open() 1. lock -- refcount +1, get lock, refcount -1 2. [open code runs] 3. acquire -- refcount +1 All throughout step 2, periph could disappear if another proc calls release. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0212101320570.28346-100000>