public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: linux-kernel@vger.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
	Marc Zyngier <maz@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH 2/2] genirq: proc: fix a procfs entry leak
Date: Mon, 28 Aug 2023 14:41:14 +0200	[thread overview]
Message-ID: <87o7ir8hlh.ffs@tglx> (raw)
In-Reply-To: <CAMRc=MfB=sMEmK02Y6SaG1T4PFZW2OD+box7NNoDY3KM1AchLA@mail.gmail.com>

On Mon, Aug 28 2023 at 12:06, Bartosz Golaszewski wrote:
> On Sat, Aug 26, 2023 at 5:08 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>>
>> How do you address this with slapping some NULL checks around? The only
>> way to clean this up is invoking free_irq().
>>
>
> This is not what I meant, let me rephrase the question:
>
> Is there any reason why whatever operations irq_free() performs could
> not be done by the irqchip when it knows it will be destroyed with
> irqs still in use? And then any new management operation that would be
> called by the now orphaned user would just bail out? Maybe not, I'm
> asking this question because I don't know and it's not obvious from
> the code.

The irqchip can do nothing and it is not directly involved in freeing
the interrupt descriptor. The entity, which allocated the interrupt
descriptors is responsible for that. That's in most modern cases the
interrupt domain.

It might be possible to free the actions in a teardown operation, but
that needs a lot of thoughts vs. concurrency and life time rules. A
simple 'let's invoke free_irq()' does not cut it.

>> The proper solution to this is to take a reference count on the module
>> which provides the interrupt chip and allocates the interrupt domain.
>> The core code has a mechanism for that. See request/free_irq().
>
> I guess you're referring to irq_alloc_descs()? Anyway, here's a
> real-life example: we have the hid-cp2112 module which drives a
> GPIO-and-I2C-expander-on-a-USB-stick. I plug it in and have a driver
> that requests one of its GPIOs as interrupt. Now I unplug it. How has
> taking the reference to the hid-cp2112 module protected me from
> freeing an irq domain with interrupts in use?

request_irq() does not care which module request the interrupt. It
always takes a refcount on irq_desc::owner. That points to the module
which created the interrupt domain and/or allocated the descriptors.

IOW, this needs a mechanism to store the module which creates the
interrupt domain somewhere in the domain itself and use it when
allocating interrupt descriptors. So in your case this would take a
refcount on the GPIO module.

Thanks,

        tglx

  reply	other threads:[~2023-08-28 12:42 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-14  9:36 [PATCH 0/2] genirq: don't leak handler procfs entries Bartosz Golaszewski
2023-08-14  9:36 ` [PATCH 1/2] genirq: proc: drop unused argument from unregister_handler_proc() Bartosz Golaszewski
2023-08-14  9:36 ` [PATCH 2/2] genirq: proc: fix a procfs entry leak Bartosz Golaszewski
2023-08-24 20:12   ` Thomas Gleixner
2023-08-25  7:36     ` brgl
2023-08-25  8:11       ` Thomas Gleixner
2023-08-25 11:01         ` Bartosz Golaszewski
2023-08-25 14:58           ` Thomas Gleixner
2023-08-25 17:08           ` Thomas Gleixner
2023-08-25 20:07             ` Bartosz Golaszewski
2023-08-26 15:08               ` Thomas Gleixner
2023-08-28 10:06                 ` Bartosz Golaszewski
2023-08-28 12:41                   ` Thomas Gleixner [this message]
2023-08-28 19:03                     ` Bartosz Golaszewski
2023-08-28 21:44                       ` Thomas Gleixner
2023-08-29  6:26                         ` Bartosz Golaszewski
2023-08-29  9:11                           ` Thomas Gleixner
2023-08-29 12:24                             ` Bartosz Golaszewski
2023-08-29 20:18                               ` Greg Kroah-Hartman
2023-08-29 22:29                               ` Thomas Gleixner
2023-09-06 14:54                                 ` Bartosz Golaszewski
2023-09-12 18:16                                   ` Thomas Gleixner
2023-09-15 19:50                                     ` Bartosz Golaszewski
2023-11-13 20:53                                       ` Bartosz Golaszewski
2023-11-14 12:27                                         ` Greg Kroah-Hartman
2023-11-14 13:25                                         ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o7ir8hlh.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=brgl@bgdev.pl \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox