From owner-freebsd-scsi Thu Dec 12 10:57: 9 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46CA837B401 for ; Thu, 12 Dec 2002 10:57:08 -0800 (PST) Received: from comp.chem.msu.su (comp-ext.chem.msu.su [158.250.32.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98E1943ED4 for ; Thu, 12 Dec 2002 10:57:06 -0800 (PST) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.3/8.12.3) with ESMTP id gBCIv0m2094362; Thu, 12 Dec 2002 21:57:00 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.3/8.12.3/Submit) id gBCIuu1r094361; Thu, 12 Dec 2002 21:56:56 +0300 (MSK) Date: Thu, 12 Dec 2002 21:56:56 +0300 From: Yar Tikhiy To: Nate Lawson Cc: freebsd-scsi@freebsd.org Subject: Re: {da,sa,...}open bug? Message-ID: <20021212215655.A92315@comp.chem.msu.su> References: <20021210143954.B14989@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nate@root.org on Tue, Dec 10, 2002 at 01:23:59PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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