From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jack Wang Subject: Re: [PATCH 07/14] scsi_transport_srp: Add transport layer error handling Date: Mon, 24 Jun 2013 18:05:15 +0200 Message-ID: <51C86E3B.7000308@profitbricks.com> References: <51C84E39.80806@profitbricks.com> <51C86AB4.1000906@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51C86AB4.1000906-HInyCGIudOg@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Bart Van Assche Cc: Roland Dreier , David Dillow , Vu Pham , Sebastian Riemer , linux-rdma , linux-scsi , James Bottomley , Mike Christie List-Id: linux-rdma@vger.kernel.org On 06/24/2013 05:50 PM, Bart Van Assche wrote: > On 06/24/13 15:48, Jack Wang wrote: >>> I'm not sure it's possible to avoid such a race without introducing >>> a new mutex. How about something like the (untested) SCSI core patch >>> below, and invoking scsi_block_eh() and scsi_unblock_eh() around any >>> reconnect activity not initiated from the SCSI EH thread ? >>> >>> [PATCH] Add scsi_block_eh() and scsi_unblock_eh() >>> >> Hi Bart, >> >> The description doesn't match the code at all, do you mean try to >> serialize the reconnect activity with this new block_eh_mutex? > > In case it wasn't clear, the actual scsi_block_eh() and > scsi_unblock_eh() calls aren't present in the patch I posted, only their > implementation. As the patch title is "Add scsi_block_eh() and scsi_unblock_eh()", so I asked, thanks for explanation. > > P.S.: please fix your e-mail client such that it does not break e-mail > threading. There are no "In-Reply-To:" tags in the header of your e-mails. > Sorry for inconvenient, will fix it. Thanks, Jack > Thanks, > > Bart. -- 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