| Message ID | 1476722704-12839-1-git-send-email-clabbe.montjoie@gmail.com |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
(cc'ing Greg and Rob) Hello, On Mon, Oct 17, 2016 at 06:45:04PM +0200, Corentin Labbe wrote: > Enabling CONFIG_DEBUG_TEST_DRIVER_REMOVE under qemu give me a WARN() trace. > Waiting for the end of the ATA RESET seems to clean the issue. > But I am not sure if my solution and the way to solve it are correct. > > Regards > > ---8<--- > From b2d097130a9d67529075f6e3c3d9552ac5415d18 Mon Sep 17 00:00:00 2001 > From: Corentin Labbe <clabbe.montjoie@gmail.com> > Date: Mon, 17 Oct 2016 17:50:02 +0200 > Subject: [RFC PATCH] ata: piix: wait for end of asynchronous probing before > removing > > Under qemu I got the following trace with CONFIG_DEBUG_TEST_DRIVER_REMOVE > [ 1.092021] ata_piix 0000:00:01.1: version 2.13 > [ 1.093277] scsi host0: ata_piix > [ 1.093720] scsi host1: ata_piix > [ 1.094152] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc080 irq 14 > [ 1.094902] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc088 irq 15 > [ 1.252998] ------------[ cut here ]------------ > [ 1.253799] WARNING: CPU: 0 PID: 1 at drivers/ata/libata-core.c:6482 ata_host_detach+0x148/0x150 I don't think it's correct to try to remove the driver while async probing is in progress and we shouldn't work around it from individual drivers. I think we already have enough async barriers to prevents this under normal operation - there's full synchronization during boot before control gets passed to userland and module unloading does full async flushing too. What we should do, probably, is to make the debug code do full async flush before test unloading the driver. Thanks.
On Wed, Oct 19, 2016 at 12:28 PM, Tejun Heo <tj@kernel.org> wrote: > (cc'ing Greg and Rob) > > Hello, > > On Mon, Oct 17, 2016 at 06:45:04PM +0200, Corentin Labbe wrote: >> Enabling CONFIG_DEBUG_TEST_DRIVER_REMOVE under qemu give me a WARN() trace. >> Waiting for the end of the ATA RESET seems to clean the issue. >> But I am not sure if my solution and the way to solve it are correct. >> >> Regards >> >> ---8<--- >> From b2d097130a9d67529075f6e3c3d9552ac5415d18 Mon Sep 17 00:00:00 2001 >> From: Corentin Labbe <clabbe.montjoie@gmail.com> >> Date: Mon, 17 Oct 2016 17:50:02 +0200 >> Subject: [RFC PATCH] ata: piix: wait for end of asynchronous probing before >> removing >> >> Under qemu I got the following trace with CONFIG_DEBUG_TEST_DRIVER_REMOVE >> [ 1.092021] ata_piix 0000:00:01.1: version 2.13 >> [ 1.093277] scsi host0: ata_piix >> [ 1.093720] scsi host1: ata_piix >> [ 1.094152] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc080 irq 14 >> [ 1.094902] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc088 irq 15 >> [ 1.252998] ------------[ cut here ]------------ >> [ 1.253799] WARNING: CPU: 0 PID: 1 at drivers/ata/libata-core.c:6482 ata_host_detach+0x148/0x150 > > I don't think it's correct to try to remove the driver while async > probing is in progress and we shouldn't work around it from individual > drivers. I think we already have enough async barriers to prevents > this under normal operation - there's full synchronization during boot > before control gets passed to userland and module unloading does full > async flushing too. What we should do, probably, is to make the debug > code do full async flush before test unloading the driver. Seems like this is mixing async drv probe and async scsi scan and the problem is in the latter? I don't think async drv probe should have any problems. If a driver probe starts some async operation, then it seems to me that it is its responsibility to wait for completion in remove(). Rob -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, Rob. On Thu, Oct 27, 2016 at 01:55:19PM -0500, Rob Herring wrote: > Seems like this is mixing async drv probe and async scsi scan and the > problem is in the latter? I don't think async drv probe should have > any problems. If a driver probe starts some async operation, then it > seems to me that it is its responsibility to wait for completion in > remove(). I'm not sure about that. The async operation synchronization isn't per-driver or module. Both during boot and module operations, they're synchronized globally, which makes sense given its purpose and that's also why we don't see these brekages without this debug option. It doesn't make sense to me to add a whole new set of behaviors just for a debug option. Thanks.
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c index ffbe625..10633c3d 100644 --- a/drivers/ata/ata_piix.c +++ b/drivers/ata/ata_piix.c @@ -1764,6 +1764,16 @@ static void piix_remove_one(struct pci_dev *pdev) { struct ata_host *host = pci_get_drvdata(pdev); struct piix_host_priv *hpriv = host->private_data; + int i, timeout = 0; + + /* wait for async probe end */ + for (i = 0; i < host->n_ports; i++) { + while ((host->ports[i]->pflags & ATA_PFLAG_RESETTING) && + timeout < 100) { + msleep(20); + timeout++; + } + } pci_write_config_dword(pdev, PIIX_IOCFG, hpriv->saved_iocfg);