* [PATCH -next 0/2] fix two bugs when trying rmmod sata_fsl @ 2021-11-19 4:11 Baokun Li 2021-11-19 4:11 ` [PATCH -next 1/2] sata_fsl: fix UAF in sata_fsl_port_stop when " Baokun Li 2021-11-19 4:11 ` [PATCH -next 2/2] sata_fsl: fix warning in remove_proc_entry " Baokun Li 0 siblings, 2 replies; 11+ messages in thread From: Baokun Li @ 2021-11-19 4:11 UTC (permalink / raw) To: damien.lemoal, axboe, tj, linux-ide, linux-kernel Cc: yebin10, libaokun1, yukuai3 Baokun Li (2): sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl sata_fsl: fix warning in remove_proc_entry when rmmod sata_fsl drivers/ata/sata_fsl.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) -- 2.31.1 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH -next 1/2] sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl 2021-11-19 4:11 [PATCH -next 0/2] fix two bugs when trying rmmod sata_fsl Baokun Li @ 2021-11-19 4:11 ` Baokun Li 2021-11-19 4:11 ` [PATCH -next 2/2] sata_fsl: fix warning in remove_proc_entry " Baokun Li 1 sibling, 0 replies; 11+ messages in thread From: Baokun Li @ 2021-11-19 4:11 UTC (permalink / raw) To: damien.lemoal, axboe, tj, linux-ide, linux-kernel Cc: yebin10, libaokun1, yukuai3, Hulk Robot When the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux, a bug is reported: ================================================================== BUG: Unable to handle kernel data access on read at 0x80000800805b502c Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0000000000388a4] .ioread32+0x4/0x20 LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl] Call Trace: .free_irq+0x1c/0x4e0 (unreliable) .ata_host_stop+0x74/0xd0 [libata] .release_nodes+0x330/0x3f0 .device_release_driver_internal+0x178/0x2c0 .driver_detach+0x64/0xd0 .bus_remove_driver+0x70/0xf0 .driver_unregister+0x38/0x80 .platform_driver_unregister+0x14/0x30 .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] .__se_sys_delete_module+0x1ec/0x2d0 .system_call_exception+0xfc/0x1f0 system_call_common+0xf8/0x200 ================================================================== The triggering of the BUG is shown in the following stack: driver_detach device_release_driver_internal __device_release_driver drv->remove(dev) --> platform_drv_remove/platform_remove drv->remove(dev) --> sata_fsl_remove iounmap(host_priv->hcr_base); <---- unmap kfree(host_priv); <---- free devres_release_all release_nodes dr->node.release(dev, dr->data) --> ata_host_stop ap->ops->port_stop(ap) --> sata_fsl_port_stop ioread32(hcr_base + HCONTROL) <---- UAF host->ops->host_stop(host) The iounmap(host_priv->hcr_base) and kfree(host_priv) commands should not be executed in drv->remove. These commands should be executed in host_stop after port_stop. Therefore, we move these commands to the new function sata_fsl_host_stop and bind the new function to host_stop by referring to achi. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Baokun Li <libaokun1@huawei.com> --- drivers/ata/sata_fsl.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index e5838b23c9e0..30759fd1c3a2 100644 --- a/drivers/ata/sata_fsl.c +++ b/drivers/ata/sata_fsl.c @@ -1430,12 +1430,25 @@ static struct ata_port_operations sata_fsl_ops = { .pmp_detach = sata_fsl_pmp_detach, }; +static void sata_fsl_host_stop(struct ata_host *host) +{ + struct sata_fsl_host_priv *host_priv = host->private_data; + + iounmap(host_priv->hcr_base); + kfree(host_priv); +} + +static struct ata_port_operations sata_fsl_platform_ops = { + .inherits = &sata_fsl_ops, + .host_stop = sata_fsl_host_stop, +}; + static const struct ata_port_info sata_fsl_port_info[] = { { .flags = SATA_FSL_HOST_FLAGS, .pio_mask = ATA_PIO4, .udma_mask = ATA_UDMA6, - .port_ops = &sata_fsl_ops, + .port_ops = &sata_fsl_platform_ops, }, }; @@ -1558,8 +1571,6 @@ static int sata_fsl_remove(struct platform_device *ofdev) ata_host_detach(host); irq_dispose_mapping(host_priv->irq); - iounmap(host_priv->hcr_base); - kfree(host_priv); return 0; } -- 2.31.1 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH -next 2/2] sata_fsl: fix warning in remove_proc_entry when rmmod sata_fsl 2021-11-19 4:11 [PATCH -next 0/2] fix two bugs when trying rmmod sata_fsl Baokun Li 2021-11-19 4:11 ` [PATCH -next 1/2] sata_fsl: fix UAF in sata_fsl_port_stop when " Baokun Li @ 2021-11-19 4:11 ` Baokun Li 2021-11-19 15:43 ` Sergei Shtylyov 2021-11-19 22:18 ` Damien Le Moal 1 sibling, 2 replies; 11+ messages in thread From: Baokun Li @ 2021-11-19 4:11 UTC (permalink / raw) To: damien.lemoal, axboe, tj, linux-ide, linux-kernel Cc: yebin10, libaokun1, yukuai3, Hulk Robot Trying to remove the fsl-sata module in the PPC64 GNU/Linux leads to the following warning: ------------[ cut here ]------------ remove_proc_entry: removing non-empty directory 'irq/69', leaking at least 'fsl-sata[ff0221000.sata]' WARNING: CPU: 3 PID: 1048 at fs/proc/generic.c:722 .remove_proc_entry+0x20c/0x220 IRQMASK: 0 NIP [c00000000033826c] .remove_proc_entry+0x20c/0x220 LR [c000000000338268] .remove_proc_entry+0x208/0x220 Call Trace: .remove_proc_entry+0x208/0x220 (unreliable) .unregister_irq_proc+0x104/0x140 .free_desc+0x44/0xb0 .irq_free_descs+0x9c/0xf0 .irq_dispose_mapping+0x64/0xa0 .sata_fsl_remove+0x58/0xa0 [sata_fsl] .platform_drv_remove+0x40/0x90 .device_release_driver_internal+0x160/0x2c0 .driver_detach+0x64/0xd0 .bus_remove_driver+0x70/0xf0 .driver_unregister+0x38/0x80 .platform_driver_unregister+0x14/0x30 .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] ---[ end trace 0ea876d4076908f5 ]--- The driver creates the mapping by calling irq_of_parse_and_map(), so it also has to dispose the mapping. But the easy way out is to simply use platform_get_irq() instead of irq_of_parse_map(). In this case the mapping is not managed by the device but by the of core, so the device has not to dispose the mapping. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Baokun Li <libaokun1@huawei.com> --- drivers/ata/sata_fsl.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index 30759fd1c3a2..011daac4a14e 100644 --- a/drivers/ata/sata_fsl.c +++ b/drivers/ata/sata_fsl.c @@ -1493,7 +1493,7 @@ static int sata_fsl_probe(struct platform_device *ofdev) host_priv->ssr_base = ssr_base; host_priv->csr_base = csr_base; - irq = irq_of_parse_and_map(ofdev->dev.of_node, 0); + irq = platform_get_irq(ofdev, 0); if (!irq) { dev_err(&ofdev->dev, "invalid irq from platform\n"); goto error_exit_with_cleanup; @@ -1570,8 +1570,6 @@ static int sata_fsl_remove(struct platform_device *ofdev) ata_host_detach(host); - irq_dispose_mapping(host_priv->irq); - return 0; } -- 2.31.1 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH -next 2/2] sata_fsl: fix warning in remove_proc_entry when rmmod sata_fsl 2021-11-19 4:11 ` [PATCH -next 2/2] sata_fsl: fix warning in remove_proc_entry " Baokun Li @ 2021-11-19 15:43 ` Sergei Shtylyov 2021-11-20 2:16 ` libaokun (A) ` (2 more replies) 2021-11-19 22:18 ` Damien Le Moal 1 sibling, 3 replies; 11+ messages in thread From: Sergei Shtylyov @ 2021-11-19 15:43 UTC (permalink / raw) To: Baokun Li, damien.lemoal, axboe, tj, linux-ide, linux-kernel Cc: yebin10, yukuai3, Hulk Robot Hello! On 19.11.2021 7:11, Baokun Li wrote: > Trying to remove the fsl-sata module in the PPC64 GNU/Linux > leads to the following warning: > ------------[ cut here ]------------ > remove_proc_entry: removing non-empty directory 'irq/69', > leaking at least 'fsl-sata[ff0221000.sata]' > WARNING: CPU: 3 PID: 1048 at fs/proc/generic.c:722 > .remove_proc_entry+0x20c/0x220 > IRQMASK: 0 > NIP [c00000000033826c] .remove_proc_entry+0x20c/0x220 > LR [c000000000338268] .remove_proc_entry+0x208/0x220 > Call Trace: > .remove_proc_entry+0x208/0x220 (unreliable) > .unregister_irq_proc+0x104/0x140 > .free_desc+0x44/0xb0 > .irq_free_descs+0x9c/0xf0 > .irq_dispose_mapping+0x64/0xa0 > .sata_fsl_remove+0x58/0xa0 [sata_fsl] > .platform_drv_remove+0x40/0x90 > .device_release_driver_internal+0x160/0x2c0 > .driver_detach+0x64/0xd0 > .bus_remove_driver+0x70/0xf0 > .driver_unregister+0x38/0x80 > .platform_driver_unregister+0x14/0x30 > .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] > ---[ end trace 0ea876d4076908f5 ]--- > > The driver creates the mapping by calling irq_of_parse_and_map(), > so it also has to dispose the mapping. But the easy way out is to > simply use platform_get_irq() instead of irq_of_parse_map(). Not that easy. :-) > In this case the mapping is not managed by the device but by > the of core, so the device has not to dispose the mapping. > > Reported-by: Hulk Robot <hulkci@huawei.com> > Signed-off-by: Baokun Li <libaokun1@huawei.com> > --- > drivers/ata/sata_fsl.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c > index 30759fd1c3a2..011daac4a14e 100644 > --- a/drivers/ata/sata_fsl.c > +++ b/drivers/ata/sata_fsl.c > @@ -1493,7 +1493,7 @@ static int sata_fsl_probe(struct platform_device *ofdev) > host_priv->ssr_base = ssr_base; > host_priv->csr_base = csr_base; > > - irq = irq_of_parse_and_map(ofdev->dev.of_node, 0); > + irq = platform_get_irq(ofdev, 0); > if (!irq) { if (irq < 0) { platform_get_irq() returns negative error codes, not 0 on failure. [...] MBR, Sergey ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH -next 2/2] sata_fsl: fix warning in remove_proc_entry when rmmod sata_fsl 2021-11-19 15:43 ` Sergei Shtylyov @ 2021-11-20 2:16 ` libaokun (A) 2021-11-20 2:18 ` libaokun (A) 2021-11-20 6:08 ` Damien Le Moal 2 siblings, 0 replies; 11+ messages in thread From: libaokun (A) @ 2021-11-20 2:16 UTC (permalink / raw) To: Sergei Shtylyov, damien.lemoal, axboe, tj, linux-ide, linux-kernel Cc: yebin10, yukuai3, Hulk Robot 在 2021/11/19 23:43, Sergei Shtylyov 写道: > Hello! > > On 19.11.2021 7:11, Baokun Li wrote: > >> Trying to remove the fsl-sata module in the PPC64 GNU/Linux >> leads to the following warning: >> ------------[ cut here ]------------ >> remove_proc_entry: removing non-empty directory 'irq/69', >> leaking at least 'fsl-sata[ff0221000.sata]' >> WARNING: CPU: 3 PID: 1048 at fs/proc/generic.c:722 >> .remove_proc_entry+0x20c/0x220 >> IRQMASK: 0 >> NIP [c00000000033826c] .remove_proc_entry+0x20c/0x220 >> LR [c000000000338268] .remove_proc_entry+0x208/0x220 >> Call Trace: >> .remove_proc_entry+0x208/0x220 (unreliable) >> .unregister_irq_proc+0x104/0x140 >> .free_desc+0x44/0xb0 >> .irq_free_descs+0x9c/0xf0 >> .irq_dispose_mapping+0x64/0xa0 >> .sata_fsl_remove+0x58/0xa0 [sata_fsl] >> .platform_drv_remove+0x40/0x90 >> .device_release_driver_internal+0x160/0x2c0 >> .driver_detach+0x64/0xd0 >> .bus_remove_driver+0x70/0xf0 >> .driver_unregister+0x38/0x80 >> .platform_driver_unregister+0x14/0x30 >> .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] >> ---[ end trace 0ea876d4076908f5 ]--- >> >> The driver creates the mapping by calling irq_of_parse_and_map(), >> so it also has to dispose the mapping. But the easy way out is to >> simply use platform_get_irq() instead of irq_of_parse_map(). > > Not that easy. :-) > >> In this case the mapping is not managed by the device but by >> the of core, so the device has not to dispose the mapping. >> >> Reported-by: Hulk Robot <hulkci@huawei.com> >> Signed-off-by: Baokun Li <libaokun1@huawei.com> >> --- >> drivers/ata/sata_fsl.c | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c >> index 30759fd1c3a2..011daac4a14e 100644 >> --- a/drivers/ata/sata_fsl.c >> +++ b/drivers/ata/sata_fsl.c >> @@ -1493,7 +1493,7 @@ static int sata_fsl_probe(struct >> platform_device *ofdev) >> host_priv->ssr_base = ssr_base; >> host_priv->csr_base = csr_base; >> - irq = irq_of_parse_and_map(ofdev->dev.of_node, 0); >> + irq = platform_get_irq(ofdev, 0); >> if (!irq) { > > if (irq < 0) { > > platform_get_irq() returns negative error codes, not 0 on failure. > > [...] > > MBR, Sergey > . I didn't notice the change in this return value, and the test didn't cover the error branch. Thank you very much for your correction. I'm about to send a patch v2 with the changes suggested by you. -- With Best Regards, Baokun Li . ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH -next 2/2] sata_fsl: fix warning in remove_proc_entry when rmmod sata_fsl 2021-11-19 15:43 ` Sergei Shtylyov 2021-11-20 2:16 ` libaokun (A) @ 2021-11-20 2:18 ` libaokun (A) 2021-11-20 6:08 ` Damien Le Moal 2 siblings, 0 replies; 11+ messages in thread From: libaokun (A) @ 2021-11-20 2:18 UTC (permalink / raw) To: Sergei Shtylyov, damien.lemoal, axboe, tj, linux-ide, linux-kernel Cc: yebin10, yukuai3, Hulk Robot 在 2021/11/19 23:43, Sergei Shtylyov 写道: > Hello! > > On 19.11.2021 7:11, Baokun Li wrote: > >> Trying to remove the fsl-sata module in the PPC64 GNU/Linux >> leads to the following warning: >> ------------[ cut here ]------------ >> remove_proc_entry: removing non-empty directory 'irq/69', >> leaking at least 'fsl-sata[ff0221000.sata]' >> WARNING: CPU: 3 PID: 1048 at fs/proc/generic.c:722 >> .remove_proc_entry+0x20c/0x220 >> IRQMASK: 0 >> NIP [c00000000033826c] .remove_proc_entry+0x20c/0x220 >> LR [c000000000338268] .remove_proc_entry+0x208/0x220 >> Call Trace: >> .remove_proc_entry+0x208/0x220 (unreliable) >> .unregister_irq_proc+0x104/0x140 >> .free_desc+0x44/0xb0 >> .irq_free_descs+0x9c/0xf0 >> .irq_dispose_mapping+0x64/0xa0 >> .sata_fsl_remove+0x58/0xa0 [sata_fsl] >> .platform_drv_remove+0x40/0x90 >> .device_release_driver_internal+0x160/0x2c0 >> .driver_detach+0x64/0xd0 >> .bus_remove_driver+0x70/0xf0 >> .driver_unregister+0x38/0x80 >> .platform_driver_unregister+0x14/0x30 >> .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] >> ---[ end trace 0ea876d4076908f5 ]--- >> >> The driver creates the mapping by calling irq_of_parse_and_map(), >> so it also has to dispose the mapping. But the easy way out is to >> simply use platform_get_irq() instead of irq_of_parse_map(). > > Not that easy. :-) > >> In this case the mapping is not managed by the device but by >> the of core, so the device has not to dispose the mapping. >> >> Reported-by: Hulk Robot <hulkci@huawei.com> >> Signed-off-by: Baokun Li <libaokun1@huawei.com> >> --- >> drivers/ata/sata_fsl.c | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c >> index 30759fd1c3a2..011daac4a14e 100644 >> --- a/drivers/ata/sata_fsl.c >> +++ b/drivers/ata/sata_fsl.c >> @@ -1493,7 +1493,7 @@ static int sata_fsl_probe(struct >> platform_device *ofdev) >> host_priv->ssr_base = ssr_base; >> host_priv->csr_base = csr_base; >> - irq = irq_of_parse_and_map(ofdev->dev.of_node, 0); >> + irq = platform_get_irq(ofdev, 0); >> if (!irq) { > > if (irq < 0) { > > platform_get_irq() returns negative error codes, not 0 on failure. > > [...] > > MBR, Sergey > . I didn't notice the change in this return value, and the test didn't cover the error branch. Thank you very much for your advice. I'm about to send a patch v2 with the changes suggested by you. -- With Best Regards, Baokun Li . ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH -next 2/2] sata_fsl: fix warning in remove_proc_entry when rmmod sata_fsl 2021-11-19 15:43 ` Sergei Shtylyov 2021-11-20 2:16 ` libaokun (A) 2021-11-20 2:18 ` libaokun (A) @ 2021-11-20 6:08 ` Damien Le Moal 2021-11-20 9:51 ` Sergei Shtylyov 2 siblings, 1 reply; 11+ messages in thread From: Damien Le Moal @ 2021-11-20 6:08 UTC (permalink / raw) To: Sergei Shtylyov, Baokun Li, axboe, tj, linux-ide, linux-kernel Cc: yebin10, yukuai3, Hulk Robot On 11/20/21 00:43, Sergei Shtylyov wrote: >> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c >> index 30759fd1c3a2..011daac4a14e 100644 >> --- a/drivers/ata/sata_fsl.c >> +++ b/drivers/ata/sata_fsl.c >> @@ -1493,7 +1493,7 @@ static int sata_fsl_probe(struct platform_device *ofdev) >> host_priv->ssr_base = ssr_base; >> host_priv->csr_base = csr_base; >> >> - irq = irq_of_parse_and_map(ofdev->dev.of_node, 0); >> + irq = platform_get_irq(ofdev, 0); >> if (!irq) { > > if (irq < 0) { > > platform_get_irq() returns negative error codes, not 0 on failure. Sergei, By the way, the kdoc comment for platform_get_irq() says: "Return: non-zero IRQ number on success, negative error number on failure." But irq 0 is valid, isn't it ? So shouldn't this be changed to something like: "Return: IRQ number on success, negative error number on failure." -- Damien Le Moal Western Digital Research ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH -next 2/2] sata_fsl: fix warning in remove_proc_entry when rmmod sata_fsl 2021-11-20 6:08 ` Damien Le Moal @ 2021-11-20 9:51 ` Sergei Shtylyov 2021-11-21 23:24 ` Damien Le Moal 0 siblings, 1 reply; 11+ messages in thread From: Sergei Shtylyov @ 2021-11-20 9:51 UTC (permalink / raw) To: Damien Le Moal, Baokun Li, axboe, tj, linux-ide, linux-kernel Cc: yebin10, yukuai3, Hulk Robot On 20.11.2021 9:08, Damien Le Moal wrote: > On 11/20/21 00:43, Sergei Shtylyov wrote: >>> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c >>> index 30759fd1c3a2..011daac4a14e 100644 >>> --- a/drivers/ata/sata_fsl.c >>> +++ b/drivers/ata/sata_fsl.c >>> @@ -1493,7 +1493,7 @@ static int sata_fsl_probe(struct platform_device *ofdev) >>> host_priv->ssr_base = ssr_base; >>> host_priv->csr_base = csr_base; >>> >>> - irq = irq_of_parse_and_map(ofdev->dev.of_node, 0); >>> + irq = platform_get_irq(ofdev, 0); >>> if (!irq) { >> >> if (irq < 0) { >> >> platform_get_irq() returns negative error codes, not 0 on failure. > > Sergei, > > By the way, the kdoc comment for platform_get_irq() says: > > "Return: non-zero IRQ number on success, negative error number on failure." > > But irq 0 is valid, isn't it ? So shouldn't this be changed to something > like: > > "Return: IRQ number on success, negative error number on failure." No, it's not valid (the current code WARN()s about it) and won't be returned anymore after my patch [1] gets applied. [1] https://marc.info/?l=linux-kernel&m=163623041902285 MBR, Sergei ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH -next 2/2] sata_fsl: fix warning in remove_proc_entry when rmmod sata_fsl 2021-11-20 9:51 ` Sergei Shtylyov @ 2021-11-21 23:24 ` Damien Le Moal 0 siblings, 0 replies; 11+ messages in thread From: Damien Le Moal @ 2021-11-21 23:24 UTC (permalink / raw) To: Sergei Shtylyov, Baokun Li, axboe, tj, linux-ide, linux-kernel Cc: yebin10, yukuai3, Hulk Robot On 2021/11/20 18:51, Sergei Shtylyov wrote: > On 20.11.2021 9:08, Damien Le Moal wrote: >> On 11/20/21 00:43, Sergei Shtylyov wrote: >>>> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c >>>> index 30759fd1c3a2..011daac4a14e 100644 >>>> --- a/drivers/ata/sata_fsl.c >>>> +++ b/drivers/ata/sata_fsl.c >>>> @@ -1493,7 +1493,7 @@ static int sata_fsl_probe(struct platform_device *ofdev) >>>> host_priv->ssr_base = ssr_base; >>>> host_priv->csr_base = csr_base; >>>> >>>> - irq = irq_of_parse_and_map(ofdev->dev.of_node, 0); >>>> + irq = platform_get_irq(ofdev, 0); >>>> if (!irq) { >>> >>> if (irq < 0) { >>> >>> platform_get_irq() returns negative error codes, not 0 on failure. >> >> Sergei, >> >> By the way, the kdoc comment for platform_get_irq() says: >> >> "Return: non-zero IRQ number on success, negative error number on failure." >> >> But irq 0 is valid, isn't it ? So shouldn't this be changed to something >> like: >> >> "Return: IRQ number on success, negative error number on failure." > > No, it's not valid (the current code WARN()s about it) and won't be > returned anymore after my patch [1] gets applied. > > [1] https://marc.info/?l=linux-kernel&m=163623041902285 OK. Got it. Thanks. > > MBR, Sergei > -- Damien Le Moal Western Digital Research ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH -next 2/2] sata_fsl: fix warning in remove_proc_entry when rmmod sata_fsl 2021-11-19 4:11 ` [PATCH -next 2/2] sata_fsl: fix warning in remove_proc_entry " Baokun Li 2021-11-19 15:43 ` Sergei Shtylyov @ 2021-11-19 22:18 ` Damien Le Moal 2021-11-20 2:22 ` libaokun (A) 1 sibling, 1 reply; 11+ messages in thread From: Damien Le Moal @ 2021-11-19 22:18 UTC (permalink / raw) To: Baokun Li, axboe, tj, linux-ide, linux-kernel Cc: yebin10, yukuai3, Hulk Robot On 11/19/21 13:11, Baokun Li wrote: > Trying to remove the fsl-sata module in the PPC64 GNU/Linux > leads to the following warning: > ------------[ cut here ]------------ > remove_proc_entry: removing non-empty directory 'irq/69', > leaking at least 'fsl-sata[ff0221000.sata]' > WARNING: CPU: 3 PID: 1048 at fs/proc/generic.c:722 > .remove_proc_entry+0x20c/0x220 > IRQMASK: 0 > NIP [c00000000033826c] .remove_proc_entry+0x20c/0x220 > LR [c000000000338268] .remove_proc_entry+0x208/0x220 > Call Trace: > .remove_proc_entry+0x208/0x220 (unreliable) > .unregister_irq_proc+0x104/0x140 > .free_desc+0x44/0xb0 > .irq_free_descs+0x9c/0xf0 > .irq_dispose_mapping+0x64/0xa0 > .sata_fsl_remove+0x58/0xa0 [sata_fsl] > .platform_drv_remove+0x40/0x90 > .device_release_driver_internal+0x160/0x2c0 > .driver_detach+0x64/0xd0 > .bus_remove_driver+0x70/0xf0 > .driver_unregister+0x38/0x80 > .platform_driver_unregister+0x14/0x30 > .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] > ---[ end trace 0ea876d4076908f5 ]--- > > The driver creates the mapping by calling irq_of_parse_and_map(), > so it also has to dispose the mapping. But the easy way out is to > simply use platform_get_irq() instead of irq_of_parse_map(). > > In this case the mapping is not managed by the device but by > the of core, so the device has not to dispose the mapping. > > Reported-by: Hulk Robot <hulkci@huawei.com> > Signed-off-by: Baokun Li <libaokun1@huawei.com> > --- > drivers/ata/sata_fsl.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c > index 30759fd1c3a2..011daac4a14e 100644 > --- a/drivers/ata/sata_fsl.c > +++ b/drivers/ata/sata_fsl.c > @@ -1493,7 +1493,7 @@ static int sata_fsl_probe(struct platform_device *ofdev) > host_priv->ssr_base = ssr_base; > host_priv->csr_base = csr_base; > > - irq = irq_of_parse_and_map(ofdev->dev.of_node, 0); > + irq = platform_get_irq(ofdev, 0); > if (!irq) { Please see the kdoc comment for platform_get_irq() in drivers/base/platform.c. The error check must be "if (irq < 0)". Can you send a V2 with that fixed and tested ? > dev_err(&ofdev->dev, "invalid irq from platform\n"); > goto error_exit_with_cleanup; > @@ -1570,8 +1570,6 @@ static int sata_fsl_remove(struct platform_device *ofdev) > > ata_host_detach(host); > > - irq_dispose_mapping(host_priv->irq); > - > return 0; > } > > -- Damien Le Moal Western Digital Research ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH -next 2/2] sata_fsl: fix warning in remove_proc_entry when rmmod sata_fsl 2021-11-19 22:18 ` Damien Le Moal @ 2021-11-20 2:22 ` libaokun (A) 0 siblings, 0 replies; 11+ messages in thread From: libaokun (A) @ 2021-11-20 2:22 UTC (permalink / raw) To: Damien Le Moal, axboe, tj, linux-ide, linux-kernel Cc: yebin10, yukuai3, Hulk Robot 在 2021/11/20 6:18, Damien Le Moal 写道: > On 11/19/21 13:11, Baokun Li wrote: >> Trying to remove the fsl-sata module in the PPC64 GNU/Linux >> leads to the following warning: >> ------------[ cut here ]------------ >> remove_proc_entry: removing non-empty directory 'irq/69', >> leaking at least 'fsl-sata[ff0221000.sata]' >> WARNING: CPU: 3 PID: 1048 at fs/proc/generic.c:722 >> .remove_proc_entry+0x20c/0x220 >> IRQMASK: 0 >> NIP [c00000000033826c] .remove_proc_entry+0x20c/0x220 >> LR [c000000000338268] .remove_proc_entry+0x208/0x220 >> Call Trace: >> .remove_proc_entry+0x208/0x220 (unreliable) >> .unregister_irq_proc+0x104/0x140 >> .free_desc+0x44/0xb0 >> .irq_free_descs+0x9c/0xf0 >> .irq_dispose_mapping+0x64/0xa0 >> .sata_fsl_remove+0x58/0xa0 [sata_fsl] >> .platform_drv_remove+0x40/0x90 >> .device_release_driver_internal+0x160/0x2c0 >> .driver_detach+0x64/0xd0 >> .bus_remove_driver+0x70/0xf0 >> .driver_unregister+0x38/0x80 >> .platform_driver_unregister+0x14/0x30 >> .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] >> ---[ end trace 0ea876d4076908f5 ]--- >> >> The driver creates the mapping by calling irq_of_parse_and_map(), >> so it also has to dispose the mapping. But the easy way out is to >> simply use platform_get_irq() instead of irq_of_parse_map(). >> >> In this case the mapping is not managed by the device but by >> the of core, so the device has not to dispose the mapping. >> >> Reported-by: Hulk Robot <hulkci@huawei.com> >> Signed-off-by: Baokun Li <libaokun1@huawei.com> >> --- >> drivers/ata/sata_fsl.c | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c >> index 30759fd1c3a2..011daac4a14e 100644 >> --- a/drivers/ata/sata_fsl.c >> +++ b/drivers/ata/sata_fsl.c >> @@ -1493,7 +1493,7 @@ static int sata_fsl_probe(struct platform_device *ofdev) >> host_priv->ssr_base = ssr_base; >> host_priv->csr_base = csr_base; >> >> - irq = irq_of_parse_and_map(ofdev->dev.of_node, 0); >> + irq = platform_get_irq(ofdev, 0); >> if (!irq) { > Please see the kdoc comment for platform_get_irq() in > drivers/base/platform.c. The error check must be "if (irq < 0)". > > Can you send a V2 with that fixed and tested ? > >> dev_err(&ofdev->dev, "invalid irq from platform\n"); >> goto error_exit_with_cleanup; >> @@ -1570,8 +1570,6 @@ static int sata_fsl_remove(struct platform_device *ofdev) >> >> ata_host_detach(host); >> >> - irq_dispose_mapping(host_priv->irq); >> - >> return 0; >> } >> >> > I didn't notice the change in this return value, and the test didn't cover the error branch. Thank you very much for your advice. I'm about to send a patch v2 with the changes suggested by you. -- With Best Regards, Baokun Li . ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-11-21 23:24 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-11-19 4:11 [PATCH -next 0/2] fix two bugs when trying rmmod sata_fsl Baokun Li 2021-11-19 4:11 ` [PATCH -next 1/2] sata_fsl: fix UAF in sata_fsl_port_stop when " Baokun Li 2021-11-19 4:11 ` [PATCH -next 2/2] sata_fsl: fix warning in remove_proc_entry " Baokun Li 2021-11-19 15:43 ` Sergei Shtylyov 2021-11-20 2:16 ` libaokun (A) 2021-11-20 2:18 ` libaokun (A) 2021-11-20 6:08 ` Damien Le Moal 2021-11-20 9:51 ` Sergei Shtylyov 2021-11-21 23:24 ` Damien Le Moal 2021-11-19 22:18 ` Damien Le Moal 2021-11-20 2:22 ` libaokun (A)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).