Date: Thu, 12 Dec 2002 21:56:56 +0300 From: Yar Tikhiy <yar@freebsd.org> To: Nate Lawson <nate@root.org> Cc: freebsd-scsi@freebsd.org Subject: Re: {da,sa,...}open bug? Message-ID: <20021212215655.A92315@comp.chem.msu.su> In-Reply-To: <Pine.BSF.4.21.0212101320570.28346-100000@root.org>; from nate@root.org on Tue, Dec 10, 2002 at 01:23:59PM -0800 References: <20021210143954.B14989@comp.chem.msu.su> <Pine.BSF.4.21.0212101320570.28346-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 10, 2002 at 01:23:59PM -0800, Nate Lawson wrote: > 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. I see your point, but your scenario isn't exactly what would happen, to my mind. If periph weren't currently locked, the refcount would change as follows: 1. lock -- refcount +1, get lock 2. [open code runs], refcount >0 3. acquire -- refcount +1 4. unlock -- refcount -1 If periph were already locked by another thread, the following would happen: 1a. lock -- on entry refcount is already >0 since the other thread has called cam_periph_lock() and thus incremented refcount 1b. refcount gets +1 and becomes >=2 1c. this thread sleeps until the other unlocks periph, where refcount gets -1, but stays >0 since it was >1 before the decrement 1d. get lock 2. [open code runs], refcount > 0 3. acquire -- refcount gets +1 and becomes >1 4. unlock -- refcount gets -1, yet stays >0 As you may see, even if cam_periph_acquire() were called lately, right before cam_periph_unlock(), refcount would never drop below 1. -- Yar 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?20021212215655.A92315>