Received-SPF: pass (google.com: domain of linux-kernel+bounces-88005-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240227113426.253232-1-herve.codina@bootlin.com>
 <CAMRc=MeSMTnPUYGyJir4fc=6=Gnw_MVP9wfEKMQ6Ck33FYCrRA@mail.gmail.com> <CACRpkdZbGUd-u3ZcmmK1POSEq8z9J1aDhbGPAbcR6guKuEpEFQ@mail.gmail.com>
In-Reply-To: <CACRpkdZbGUd-u3ZcmmK1POSEq8z9J1aDhbGPAbcR6guKuEpEFQ@mail.gmail.com>
From: Bartosz Golaszewski <brgl@bgdev.pl>
Date: Fri, 1 Mar 2024 08:21:09 +0100
Message-ID: <CAMRc=MeqiYZv3ViHRKKUsXTqG5Pc8Ev2jUcN=A4VuX3RU7dDtw@mail.gmail.com>
Subject: Re: [PATCH v2 0/2] gpio-cdev: Release IRQ used by gpio-cdev on gpio
 chip removal
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Herve Codina <herve.codina@bootlin.com>, Kent Gibson <warthog618@gmail.com>, 
	Saravana Kannan <saravanak@google.com>, linux-gpio@vger.kernel.org, 
	linux-kernel@vger.kernel.org, Luca Ceresoli <luca.ceresoli@bootlin.com>, 
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 29, 2024 at 3:09=E2=80=AFPM Linus Walleij <linus.walleij@linaro=
org> wrote:
>
> On Tue, Feb 27, 2024 at 8:31=E2=80=AFPM Bartosz Golaszewski <brgl@bgdev.p=
l> wrote:
> > On Tue, Feb 27, 2024 at 12:34=E2=80=AFPM Herve Codina <herve.codina@boo=
tlin.com> wrote:
>
> > > Herve Codina (2):
> > >   gpiolib: call gcdev_unregister() sooner in the removal operations
> > >   gpiolib: cdev: release IRQs when the gpio chip device is removed
> (...)
> > 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?
>
> I'm not sure. What does "all GPIO interrupt users" mean in this context?
>
> If you mean "also the kernel-internal" (such as some random driver
> having performed gpiod_to_irq() and requested it or, taken it from a
> phandle in the device tree) then I think these are slightly semantically
> different.
>

Yes I mean both in-kernel and user-space consumers.

> The big difference is that users of the cdev are *expected* to *crash*
> sometimes, releasing the file handle and then this cleanup needs to
> happen. Also cdev is more likely to be used for hotplugged/unplugged
> GPIOs.
>
> The kernel-internal users are *not* expected to crash, but to clean up
> their usage the right way. Also they are predominantly if not exclusively
> used for fixed GPIOs such as those on an SoC that do not hot-unplug
> and go away randomly.
>
> Use case 1: you run gpio-mon on a random GPIO with IRQ on a board.
> It is using a SoC-native GPIO. Suddenly gpio-mon crashes because
> of OOM or whatever and releases the filehandle on the way down.
> What to do?
>
> Use case 2: you plug in a USB dongle with GPIOs on. Start gpio-mon
> on one of the pins. Unplug the dongle. Then it is fair that the cdev clea=
ns
> up the irq, because I don't see any way that a kernel driver would
> request any of these GPIOs (but I'm more uncertain here).
>
> I just think it is necessary to think about the big picture here.
>

Agreed and the big picture - just like with the reason behind the SRCU
rework - is the fact that even static GPIO chips defined in ACPI or DT
can be unbound. Unless you want to make the decision that we
arbitrarily suppress_bind_attrs for all GPIO chips which I don't think
you do.

I have shown in the discussion under the previous iteration that a
static GPIO chip defined in DT that is also marked as an
interrupt-controller may have interrupts requested directly from its
irq domain bypassing the .to_irq() callback. As long as this GPIO chip
may be unbound (and we do not restrict this) it means the splat
mentioned here can be triggered from user-space with a simple rmmod
because a requested irq does not increase the module reference count
nor do device links seem to work for interrupts not associated with a
struct device explicitly.

I DO want to fix it, don't get me wrong. I don't want to just leave it
like this, especially since we've made so much progress with
hotpluggability recently. I just don't believe this is the right fix,
I will try to come up with a solution that addresses the issue
globally.

Bart

> Yours,
> Linus Walleij

[1] https://lore.kernel.org/lkml/CAMRc=3DMf5fRWoOMsJ41vzvE=3D-vp3wi-Obw=3Dj=
5fBk3DuQaZNQP2Q@mail.gmail.com/