[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=MfpudtuwMEexJdWwhJ3sdbTn4fhpwQvGKOHSPE6+6k4jQ@mail.gmail.com>
Date: Tue, 20 Feb 2024 14:41:38 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Kent Gibson <warthog618@...il.com>, Linus Walleij <linus.walleij@...aro.org>,
linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
Luca Ceresoli <luca.ceresoli@...tlin.com>, Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH 0/2] gpio-cdev: Release IRQ used by gpio-cdev on gpio chip removal
On Tue, Feb 20, 2024 at 12:10 PM Herve Codina <herve.codina@...tlincom> 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.
>
> Best regards,
> Hervé Codina
>
> 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 | 8 +++++++-
> 2 files changed, 29 insertions(+), 12 deletions(-)
>
> --
> 2.43.0
>
Thanks for taking a stab at it. I saw this issue some time ago, tried
to fix it directly in interrupt procfs code[1], got yelled at by
Thomas Gleixner for 20 or so emails and eventually forgot about it.
Nice to see someone tackle it again.
Bart
[1] https://lore.kernel.org/lkml/20230814093621.23209-1-brgl@bgdev.pl/
Powered by blists - more mailing lists