All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herve Codina <herve.codina@bootlin.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Adrian Ambrozewicz <aambrozewicz@nvidia.com>,
	Bartosz Golaszewski <brgl@kernel.org>,
	Linus Walleij <linusw@kernel.org>,
	Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>,
	Kent Gibson <warthog618@gmail.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jia Jia <physicalmtea@gmail.com>,
	linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v5 7/7] gpiolib: let the character device free its IRQs first on chip removal
Date: Tue, 3 Nov 2026 12:26:34 +0100	[thread overview]
Message-ID: <20261103122634.6badd16e@bootlin.com> (raw)
In-Reply-To: <aum82qe3S5W0FvK2@ashevche-desk.local>

Hi Andy, Adrian,

On Tue, 3 Nov 2026 12:52:10 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Tue, Nov 03, 2026 at 12:32:40PM +0200, Adrian Ambrozewicz wrote:
> > gpiochip_remove() force-frees the remaining IRQs, removes the irqchip,
> > and only then calls the device notifier on which the character device
> > frees its own IRQs. The character device can then free an IRQ it no
> > longer owns: after its mapping was disposed of and the number reused, or
> > from a release that races gpiod_free_irqs() and
> > gpiochip_irqchip_remove(). free_irq() then warns "Trying to free
> > already-free IRQ" or uses a disposed descriptor.
> > 
> > Call the notifier once the chip pointer is cleared and the SRCU grace
> > period has elapsed, when no ioctl can request IRQs any more, and free
> > the remaining IRQs after it. Have the release paths free their IRQs
> > before unregistering from the notifier, under the lock its callback
> > takes (config_mutex, or a new mutex for v1 line events). Herve Codina
> > first proposed calling the notifier earlier.
> > 
> > IRQs that in-kernel users leave requested are now freed after the chip
> > pointer is cleared, when gpiod_*() calls on the chip fail.
> > 
> > Reproduced with a test-only chip on the hierarchical irqchip: both races
> > warn in all 30 cycles; with this change, none does.  
> 
> > Link: https://lore.kernel.org/all/20240227113426.253232-1-herve.codina@bootlin.com/  
> 
> No. Either make it Closes tag (if appropriate) or add a reference like
> 
> Link: $URL [1]
> 
> and mention [1] in the text, otherwise it makes Linus T. grumpy. I think
> I already told that.
> 

IHMO, "Link:" instead of "Closes:" according to this reply in the series
pointed out [2].

[2]: https://lore.kernel.org/all/20240923150522.66b418d1@bootlin.com/

The history was:
 - [1] (the link in this patch) proposed a fix
 - It has been rejected and a improved one has been done [2]
 - [2] has been accepted and led to the commit ec8b6f55b981 ("gpio: free irqs
   that are still requested when the chip is being removed"). This commit
   is already mentioned as 'Fixes:" in this patch.

So, IMHO, in this patch:
  ...
  takes (config_mutex, or a new mutex for v1 line events). Herve Codina
  first proposed calling the notifier earlier [1].
  ...
  Link: https://lore.kernel.org/all/20240227113426.253232-1-herve.codina@bootlin.com/ [1]
  Fixes: ec8b6f55b981 ("gpio: free irqs that are still requested when the chip is being removed")
  ...

Best regards,
Hervé

  reply	other threads:[~2026-11-03 11:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 10:32 [PATCH v5 0/7] gpiolib: fix chip removal with lines still requested from user space Adrian Ambrozewicz
2026-11-03 10:32 ` [PATCH v5 1/7] gpiolib: wait for pending label frees before cleaning up desc_srcu Adrian Ambrozewicz
2026-11-03 10:48   ` Andy Shevchenko
2026-11-03 10:50     ` Andy Shevchenko
2026-11-03 10:32 ` [PATCH v5 2/7] gpiolib: free the label of lines released after their chip was removed Adrian Ambrozewicz
2026-11-03 10:32 ` [PATCH v5 3/7] gpiolib: cdev: do not free line IRQs again after the chip is removed Adrian Ambrozewicz
2026-11-03 10:32 ` [PATCH v5 4/7] gpiolib: cdev: don't sleep in the SRCU read section in read() Adrian Ambrozewicz
2026-11-03 10:32 ` [PATCH v5 5/7] gpiolib: cdev: don't leak the IRQ name when the chip is removed Adrian Ambrozewicz
2026-11-03 10:32 ` [PATCH v5 6/7] gpiolib: cdev: don't report a failed line read as an edge Adrian Ambrozewicz
2026-11-03 10:32 ` [PATCH v5 7/7] gpiolib: let the character device free its IRQs first on chip removal Adrian Ambrozewicz
2026-11-03 10:52   ` Andy Shevchenko
2026-11-03 11:26     ` Herve Codina [this message]
2026-11-03 11:35       ` Andy Shevchenko
2026-11-03 12:03   ` sashiko-bot
2026-11-04 14:00     ` Bartosz Golaszewski
2026-11-04 14:15       ` Adrian Ambrozewicz

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=20261103122634.6badd16e@bootlin.com \
    --to=herve.codina@bootlin.com \
    --cc=aambrozewicz@nvidia.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bartosz.golaszewski@oss.qualcomm.com \
    --cc=brgl@kernel.org \
    --cc=linusw@kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=physicalmtea@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=warthog618@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.