Re: [usb-storage] UAS hangs khubd on USB disconnect

[Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

Hi James,

On 12/13/2013 09:03 PM, James Bottomley wrote:
> On Fri, 2013-12-13 at 11:18 -0800, James Bottomley wrote:
>> On Fri, 2013-12-13 at 13:33 -0500, Tejun Heo wrote:
>>> Hello, guys.
>>>
>>> (cc'ing Greg)
>>>
>>> On Fri, Dec 13, 2013 at 01:19:36PM -0500, Alan Stern wrote:
>>>> On Fri, 13 Dec 2013, Sarah Sharp wrote:
>>>>
>>>>>> Given the way things work now, I suspect these warnings are truly
>>>>>> harmless.  We could simply get rid of the WARN in sysfs_remove_group
>>>>>>
>>>>>> The alternative is to call device_del for SCSI targets earlier on, such
>>>>>> as when their hosts are unregistered.  I don't know how James would
>>>>>> feel about this approach.  It would be difficult because targets use
>>>>>> their own reference counts instead of relying on the usual device
>>>>>> refcounting mechanism.
>>>>>
>>>>> Thanks for looking into this.  I think just getting rid of the WARN
>>>>> would be sufficient.  Can you make a patch for that?
>>>>
>>>> Easily.  The downside is that there would no longer be any warning
>>>> when someone tries to remove a wrong subdirectory by mistake.
>>>>
>>>>> The patch still won't help with the UAS issues with
>>>>> scsi_init_shared_tag_map though.
>>>>
>>>> I wasn't clear on the reason for that problem.  Does it also arise from
>>>> late device_del for scsi_target?  I could try to change the way that
>>>> works, if anybody (Hans?) would like to test it.
>>>
>>> While the recent sysfs changes made this issue more visible, Greg
>>> wants to make sure that devices are removed from leaf up in all cases
>>> and keep the warning to ensure that.  Would there be a way fix SCSI
>>> removal ordering?
>>
>> Could someone analyse the actual problem?  We're quite careful even on
>> host remove to iterate and remove all the devices, then targets, then
>> host (and allied transport objects).  Which removal is inverted?
>
> Actually, I think I have this figured out.  There's a thinko in one of
> the scsi_target_reap() cases.  The original (and still existing) problem
> with targets is that nothing creates them and nothing destroys them, so,
> while we could rely on the refcounting of the device model to preserve
> the actual target object, we had no idea when to remove it from
> visibility.  That was the job of the reap reference, to track
> visibility.  It looks like the reap on device last put is occurring too
> late.  I think we should reap immediately after doing the sdev
> device_del, so does this fix the warn on? (I'm not sure because no-one
> has actually posted a backtrace, but it sounds like this is the
> problem).

Thanks I'll give this patch a try. As for backtraces I've posted some
(partial) backtraces as well as reproduction instructions here:
http://www.spinics.net/lists/linux-scsi/msg70002.html

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html