lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 9 Nov 2016 12:35:23 -0800 From: Dan Williams <dan.j.williams@...el.com> To: John Garry <john.garry@...wei.com> Cc: "Martin K. Petersen" <martin.petersen@...cle.com>, jejb@...ux.vnet.ibm.com, linux-scsi <linux-scsi@...r.kernel.org>, john.garry2@...l.dcu.ie, linuxarm@...wei.com, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, lindar_liu@...sh.com, jinpu.wang@...fitbricks.com, Tejun Heo <tj@...nel.org> Subject: Re: [RFC PATCH] scsi: libsas: fix WARN on device removal On Wed, Nov 9, 2016 at 11:09 AM, Dan Williams <dan.j.williams@...el.com> wrote: > On Wed, Nov 9, 2016 at 9:36 AM, John Garry <john.garry@...wei.com> wrote: >> On 09/11/2016 12:28, John Garry wrote: >>> >>> On 03/11/2016 14:58, John Garry wrote: >>>> >>>> The following patch introduces an annoying WARN >>>> when a device is removed from the SAS topology: >>>> [SCSI] libsas: prevent domain rediscovery competing with ata error >>>> handling >>>> >>> >>> Are there any views on this patch? I would have thought that the parties >>> who use the drivers based on libsas would be interested in fixing this >>> bug. >>> >> >> I should have added the before and after logs earlier, so the issue is >> illustrated. Now attached. When a 24-port expander is unplugged we get >6k >> lines of WARN on the console, lasting >30 seconds. Not nice. >> > > I might be mistaken, but this patch seems functionally identical to > this attempt: > > http://marc.info/?l=linux-scsi&m=143459794823595&w=2 > > i.e. it moves the port destruction to the workqueue and still suffers > from the flutter problem: > > http://marc.info/?l=linux-scsi&m=143801026028006&w=2 > http://marc.info/?l=linux-scsi&m=143801971131073&w=2 > > Perhaps we instead need to quiet this warning? > > http://marc.info/?l=linux-scsi&m=143802229932175&w=2 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.
Powered by blists - more mailing lists