From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 30 14:34:23 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58ACF1065674 for ; Tue, 30 Mar 2010 14:34:23 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 2ADEF8FC23 for ; Tue, 30 Mar 2010 14:34:22 +0000 (UTC) Received: from [192.168.0.102] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o2UEYM9G029253 for ; Tue, 30 Mar 2010 06:34:22 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4BB20BF0.3090605@feral.com> Date: Tue, 30 Mar 2010 07:34:24 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <3bbf2fe11002281655i61a5f0a0if3f381ad0c4a1ef8@mail.gmail.com> <3bbf2fe11003031547kd5f7314t3d83b2bde06c1c2f@mail.gmail.com> <4B8EF990.5030407@feral.com> <3bbf2fe11003031607wa3727b5ke89bc2a909d4d6a6@mail.gmail.com> <4B901419.8060800@feral.com> <3bbf2fe11003041737p30690522ya81e1b8f4bd6bbf9@mail.gmail.com> <3bbf2fe11003120601y3c403a1ct50f9fc6c1f0903bf@mail.gmail.com> <4B9A91DA.7030107@FreeBSD.org> <3bbf2fe11003200523t60895bfv1fa73d04e58a7838@mail.gmail.com> <4BA5C746.7060203@FreeBSD.org> <3bbf2fe11003300725vdb1e4ddrf112778ca2bbbc20@mail.gmail.com> In-Reply-To: <3bbf2fe11003300725vdb1e4ddrf112778ca2bbbc20@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.67.166.1]); Tue, 30 Mar 2010 06:34:22 -0800 (PST) Subject: Re: How is supposed to be protected the units list? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 14:34:23 -0000 I was distracted yesterday so didn't finish my testing. There are still lots of issues that can occur. I'm still forming some thoughts on this, but part of the problem is that there are things going on with a periph that make this difficult. Pieces of it can change or be changed- even under a lock- but the code surrounding the lock isn't aware that it can change *between* the lock. For example, I think that cam_periph alloc can have two different arrivals of something which could be for the same periph can end up with two different periph structures on the list with different unit numbers that point to the same bus. It doesn't matter that there were locks to provide some stability because the locks were dropped in between. > The lock recursion is going to happen because of the necessary > refcount acquisition as Matt pointed out? > Or there is another recursion? > In the former case, the global lock will help because you may just > acquire it, refcount the periph, cache them and run lockless. > You can't do this with xpt_lock_bus because of the recursion in > cam_periph_acquire. > > So we want to live this unprotected and just live with this bug? > > Attilio > > >