On Fri, Nov 18, 2016 at 1:00 AM, John Garry <john.garry@xxxxxxxxxx> wrote: > On 18/11/2016 01:53, Dan Williams wrote: >> >> On Thu, Nov 17, 2016 at 7:23 AM, John Garry <john.garry@xxxxxxxxxx> wrote: >>> >>> 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? >> >> >> To me this adds a bug to quiet a benign, albeit noisy, warning. >> > > What is the bug which is being added? The bug where we queue a port teardown, but see a port formation event in the meantime. > And it's a very noisy warning, as in 6K lines on the console when an > expander is unplugged. Does something like this modulate the failure? diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c index 60b651bfaa01..11401e5c88ba 100644 --- a/drivers/scsi/scsi_transport_sas.c +++ b/drivers/scsi/scsi_transport_sas.c @@ -262,9 +262,10 @@ static void sas_bsg_remove(struct Scsi_Host *shost, struct sas_rphy *rphy { struct request_queue *q; - if (rphy) + if (rphy) { q = rphy->q; - else + rphy->q = NULL; + } else q = to_sas_host_attrs(shost)->q; if (!q) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
