From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 4 09:50:47 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 1847E106564A for ; Thu, 4 Mar 2010 09:50:47 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 98D4C8FC21 for ; Thu, 4 Mar 2010 09:50:46 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so574882fge.13 for ; Thu, 04 Mar 2010 01:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=a9/RRelV86yoNY0oEr4DrFWAr1eKHwIUNsTkpvMB8+E=; b=Zso9Z2aNRqpyje2sK1Ozz3cPoCfX48f5EiXXM90csGfZDfosqMhaCXyubIOKZ0SbKP wk0yGX+WsPNXcYieuucNkt/6pviSKv1BsxypJjUrsqZcA5xZ9oADaPU/WX/fJAEeSPkh rssyhNA4Bv0wEuV8yir5b4ftFd3pRxXQK7Dr8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=xhJqeXT8lbUwVRg+AcVz9b/zbguZiELZetWTU8ZLlGpJDEwMxhhRHJn9FcQcxdD7gt DsmsRC2OPERa2FRBWnMzzO9Mo9LmDeUNLq7X5zF3FrUbAQTGWpXHRIFjOQXAL1Zfeogt AUTa4EeOCrF0ZQtCvY+Tp1pXoW7uxs9Zpw2U4= Received: by 10.87.2.15 with SMTP id e15mr2156688fgi.22.1267694420576; Thu, 04 Mar 2010 01:20:20 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm211369fxm.0.2010.03.04.01.20.19 (version=SSLv3 cipher=RC4-MD5); Thu, 04 Mar 2010 01:20:20 -0800 (PST) Sender: Alexander Motin Message-ID: <4B8F7B51.6050403@FreeBSD.org> Date: Thu, 04 Mar 2010 11:20:17 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Attilio Rao References: <1267417389.00224447.1267407002@10.7.7.3> <1267554183.00225132.1267543801@10.7.7.3> In-Reply-To: <1267554183.00225132.1267543801@10.7.7.3> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, "Justin T. Gibbs" , Matthew Jacob 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: Thu, 04 Mar 2010 09:50:47 -0000 Hi. Attilio Rao wrote: > 2010/3/1 Attilio Rao : >> I have a question that I've been unable to reply reading the code. >> Someone could point me to documentation explaining how the unit tailq >> (within a struct periph_driver) is supposed to be locked? >> I'm not sure how it is assured consistency of accesses to the list and >> more important how is ensured that the periphs composing it doesn't go >> away as I don't see any reference bump for objects inserted there. I am not sure that existing implementation is complete, but at least in some places it is protected by xpt_lock_buses(), which is wrapper for mtx_lock(&xsoftc.xpt_topo_lock). camperiphfree() called under the lock, same as many (all?) traverses. > I don't think the lists are protected at all so I made this simple > patch taking advantage by a global lock: > http://www.freebsd.org/~attilio/Sandvine/pdrv/pdrv_lock.diff > > The patch is simple enough but I just test-compiled it (will need some > time to run in a debugging kernel, hope to do tonight) and maybe you > can already give your opinions here. It is not obvious to me, how your new lock expected to interoperate with existing xpt_topo_lock. I have feeling that it duplicates one in some places. If you believe that second lock is needed there, then probably first one should be partially removed. But then we should be careful to not create LORs between them, as they are not natively nested. Changes in cam_xpt.c break splbreaknum meaning of temporary dropping xpt_topo_lock. I have doubts whether it is required now at all now, but leaving dead code it definitely not good. -- Alexander Motin