Re: [PATCH v2 0/2] gpio-cdev: Release IRQ used by gpio-cdev on gpio chip removal

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Tue, Feb 27, 2024 at 12:34 PM Herve Codina <herve.codina@xxxxxxxxxxx> wrote:
>
> Hi,
>
> When a gpio chip device is removed while some related gpio are used by
> the user-space (gpiomon for instance), the following warning can appear:
>   remove_proc_entry: removing non-empty directory 'irq/233', leaking at least 'gpiomon'
>   WARNING: CPU: 2 PID: 72 at fs/proc/generic.c:717 remove_proc_entry+0x190/0x19c
>   ...
>   Call trace:
>     remove_proc_entry+0x190/0x19c
>     unregister_irq_proc+0xd0/0x104
>     free_desc+0x4c/0xc4
>     irq_free_descs+0x6c/0x90
>     irq_dispose_mapping+0x104/0x14c
>     gpiochip_irqchip_remove+0xcc/0x1a4
>     gpiochip_remove+0x48/0x100
>   ...
>
> Indeed, even if the gpio removal is notified to the gpio-cdev, the
> IRQ used is not released when it should be.
>
> This series calls the gpio removal notifier sooner in the removal
> process in order to give a chance to a notifier function to release
> the IRQ before releasing the IRQ mapping and adds the needed
> operations to release the IRQ in the gpio cdev notifier function.
>
> Compared to the previous iteration:
>   https://lore.kernel.org/linux-kernel/20240220111019.133697-1-herve.codina@xxxxxxxxxxx/
> this v2 series set gdev->chip to NULL before calling gcdev_unregister().
>
> Also, this v2 series was rebased on top of for-next branch of the GPIO
> tree.
>
> Best regards,
> Hervé Codina
>
> Changes v1 -> v2:
>   - Patch 1
>     Set gdev->chip to NULL before calling gcdev_unregister()
>
>   - Patch 2
>     No changes
>
> Herve Codina (2):
>   gpiolib: call gcdev_unregister() sooner in the removal operations
>   gpiolib: cdev: release IRQs when the gpio chip device is removed
>
>  drivers/gpio/gpiolib-cdev.c | 33 ++++++++++++++++++++++-----------
>  drivers/gpio/gpiolib.c      |  6 +++++-
>  2 files changed, 27 insertions(+), 12 deletions(-)
>
> --
> 2.43.0
>

Sorry but this is just papering over the real issue. I'd say NAK for
now as I'd really prefer to get to the root of the problem and fix it
for all GPIO interrupt users.

Kent, Linus: what do you think?

Bart