From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [RFC] fix our current target reap infrastructure. Date: Sun, 15 Dec 2013 19:33:29 -0800 Message-ID: <1387164809.2284.66.camel@dabdike.int.hansenpartnership.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit Return-path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:59854 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751998Ab3LPDdb (ORCPT ); Sun, 15 Dec 2013 22:33:31 -0500 In-Reply-To: Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Alan Stern Cc: Tejun Heo , Sarah Sharp , Hans de Goede , USB list , SCSI development list , USB Storage List , Greg Kroah-Hartman On Sun, 2013-12-15 at 21:49 -0500, Alan Stern wrote: > On Sun, 15 Dec 2013, James Bottomley wrote: > > > No, I was thinking of the two thread scan bug (i.e. two scan threads) > > not one scan and one remove, which is a bug in the old code. > > By the way, the existing code doesn't allow two threads to scan a > target at the same time. They would both have to hold the host's > scan_mutex. I thought of that, but it's dropped too early. That makes the race almost untriggerable because the racing thread starts way behind, but it's not theoretically impossible. > On the other hand, as far as I can see there's nothing to prevent two > threads from removing a device at the same time. But that wouldn't > cause any problems. Right. Thanks, James