Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

[John Garry <john.garry@huawei.com>]

On 11/11/2016 08:49, wangyijing wrote:
>>>> I have not seen the flutter issue. I am just trying to solve the horrible WARN dump.
>>>> However I do understand that there may be a issue related to how we queue the events; there was a recent attempt to fix this, but it came to nothing:
>>>> https://www.spinics.net/lists/linux-scsi/msg99991.html
>>>
>>> We found libsas hotplug several problems:
>>> 1. sysfs warning calltrace(like the case you found);
>>
>> Maybe you can then review my patch.
>
> I did it, I think your solution to fix the sysfs calltrace issue is ok, and what I worried about is we still need to fix
> the rest issues. So it's better if we could fix all issues one time.
>

@Maintainers, would you be willing to accept this patch as an interim 
fix for the dastardly WARN while we try to fix the flutter issue?

>>
>>> 2. hot-add and hot-remove work events may process out of order;
>>> 3. in some extreme cases, libsas may miss some events, if the same event is still pending in workqueue.
>>>
>>
>> Can you tell me how to recreate #2 and #3?
>
> Qilin Chen and Yousong He help me to reproduce it, I told them to reply this mail to tell you the test steps.
> Some tests we did is make sas phy link flutter, so hardware would post phy down and phy up events sequentially.
>
> 1. scsi host workqueue receive phy down and phy up events.                                             in process                 new added
> 2. sas_deform_port would post a new destruct event to scsi host workqueue, so things in workqueue like [phy down-----phy up -----destruct]
>
> So the phy down logic is separated by phy up, and it's not atomic, not safe, something unexpected would happen.
>
> For case 3, we make hardware burst post lots pair of phy up and phy down events, so if libsas is processing the phy up event, the next
> phy up event can not queue to scsi host workqueue again, it will lost, it's not we expect.
>
>>
>>> It's a complex issue, we posted two patches, try to fix these issues, but now few people are interested in it  :(
>>>
>>
>> IIRC, you sent as RFC and got a "reviewed-by" from Hannes, so I'm not sure what else you want. BTW, I thought that the changes were quite drastic.
>
> I agree, the changes seems something drastic. But I think current libsas hotplug framework has a big flaw.
>
>>
>> John
>>
>>>>
>>>>>
>>>>> Alternatively we need a mechanism to cancel in-flight port shutdown
>>>>> requests when we start re-attaching devices before queued port
>>>>> destruction events have run.
>>>>>
>>>>> .
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> linuxarm mailing list
>>>> linuxarm@huawei.com
>>>> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>>>>
>>>> .
>>>>
>>>
>>>
>>> .
>>>
>>
>>
>>
>> .
>>
>
>
> .
>