Re: [PATCH] Separate target visibility from reaped state information

[Johannes Thumshirn <jthumshirn@suse.de>]

On Wed, Feb 03, 2016 at 11:38:16PM +0100, Sebastian Herbszt wrote:
> James Bottomley wrote:
> > On Mon, 2016-02-01 at 19:43 -0800, Bart Van Assche wrote:
> > > On 01/19/16 17:03, James Bottomley wrote:
> > > > On Tue, 2016-01-19 at 19:30 -0500, Martin K. Petersen wrote:
> > > > > > > > > > "Bart" == Bart Van Assche <bart.vanassche@sandisk.com>
> > > > > > > > > > writes:
> > > > > 
> > > > > Bart> Instead of representing the states "visible in sysfs" and
> > > > > "has
> > > > > Bart> been removed from the target list" by a single state
> > > > > variable,
> > > > > use
> > > > > Bart> two variables to represent this information.
> > > > > 
> > > > > James: Are you happy with the latest iteration of this? Should I
> > > > > queue
> > > > > it?
> > > > 
> > > > Well, I'm OK with the patch: it's a simple transformation of the
> > > > enumerated state to a two bit state.  What I can't see is how it
> > > > fixes
> > > > any soft lockup.
> > > > 
> > > > The only change from the current workflow is that the DEL
> > > > transition
> > > > (now the reaped flag) is done before the spin lock is dropped which
> > > > would fix a tiny window for two threads both trying to remove the
> > > > same
> > > > target, but there's nothing that could possibly fix an iterative
> > > > soft
> > > > lockup caused by restarting the loop, which is what the changelog
> > > > says.
> > > 
> > > Hello James,
> > > 
> > > scsi_remove_target() doesn't lock the scan_mutex which means that 
> > > concurrent SCSI scanning activity is not prohibited. Such scanning 
> > > activity can postpone the transition of the state of a SCSI target 
> > > into STARGET_DEL. I think if the scheduler decides to run the thread 
> > > that executes scsi_remove_target() on the same CPU as the scanning 
> > > code after the scanning code has obtained a reap ref and before the 
> > > scanning code has released the reap ref again that the soft lockup 
> > > can be triggered that has been reported by Sebastian Herbszt.
> > 
> > OK, I finally understand the scenario;  I'm not sure I understand how
> > we're getting concurrent scanning and removal from a simple rmmod ... I
> > take it this is insmod rmmod in a tight loop?
> 
> I am able to trigger the soft lockup with this test case run once:
> 
> modprobe lpfc
> run fio for 10 seconds
> rmmod lpfc
> 
> My test setup involves running qla2xxx in target mode (SCST) and
> lpfc as initiator on the same system with one exported volume.
> 
> Dick, how did you trigger the lockup?
> 
> Sebastian

Hi James, Bart, Martin

Have you already decided, which of the two patches you favour and when it'll
be included?

I have several customer reports that hit this lockup and I don't want to include
one of the patches from the list just to find out the other one's is used in
mainline.

Thanks in advance,
	Johannes

-- 
Johannes Thumshirn                                          Storage
jthumshirn@suse.de                                +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html