From owner-freebsd-scsi Tue Dec 10 13:24: 0 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 603C837B401 for ; Tue, 10 Dec 2002 13:23:59 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 8C7A743E4A for ; Tue, 10 Dec 2002 13:23:58 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 28483 invoked by uid 1000); 10 Dec 2002 21:23:59 -0000 Date: Tue, 10 Dec 2002 13:23:59 -0800 (PST) From: Nate Lawson To: Yar Tikhiy Cc: freebsd-scsi@freebsd.org Subject: Re: {da,sa,...}open bug? In-Reply-To: <20021210143954.B14989@comp.chem.msu.su> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 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