From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 01/12] scsi_transport_srp: Introduce srp_wait_for_queuecommand() Date: Thu, 30 Apr 2015 10:25:16 -0700 Message-ID: <20150430172516.GA19200@infradead.org> References: <5541EE21.3050809@sandisk.com> <5541EE4A.30803@sandisk.com> <20150430093719.GA23486@infradead.org> <5542034D.5010300@sandisk.com> <554204D7.9050204@dev.mellanox.co.il> <55420AEA.10108@sandisk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <55420AEA.10108-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Bart Van Assche Cc: Sagi Grimberg , Christoph Hellwig , Doug Ledford , James Bottomley , Sagi Grimberg , Sebastian Parschauer , linux-rdma , "linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-scsi@vger.kernel.org On Thu, Apr 30, 2015 at 12:58:50PM +0200, Bart Van Assche wrote: > The only callers in upstream code of scsi_target_block() and > scsi_target_unblock() I am aware of are the FC, iSCSI and SRP transport > layers and the drivers that use these transport layers. As far as I can see > both functions are always called from thread context and without holding any > spinlocks. A possible alternative to what I proposed in my previous e-mail > could be to provide a new function that waits for active queuecommand() > calls and that has to be called explicitly. A separate helper sounds fine for now, although I suspect we'll eventually migrate the call to it into scsi_target_block(). -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html