Received-SPF: pass (google.com: domain of linux-kernel+bounces-89387-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::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>
 <CAMRc=MeqiYZv3ViHRKKUsXTqG5Pc8Ev2jUcN=A4VuX3RU7dDtw@mail.gmail.com> <CACRpkdYWDzu+VMQOYO_Sh1NM2ei=VRC-0df4teAZjirfrTB67A@mail.gmail.com>
In-Reply-To: <CACRpkdYWDzu+VMQOYO_Sh1NM2ei=VRC-0df4teAZjirfrTB67A@mail.gmail.com>
From: Bartosz Golaszewski <brgl@bgdev.pl>
Date: Sat, 2 Mar 2024 09:59:50 +0100
Message-ID: <CAMRc=MdLmU3uezKSg2d83HSZ3wYXFx68oGshx_yJyvJToN261Q@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 Fri, Mar 1, 2024 at 9:15=E2=80=AFPM Linus Walleij <linus.walleij@linaro.=
org> wrote:
>
> On Fri, Mar 1, 2024 at 8:21=E2=80=AFAM Bartosz Golaszewski <brgl@bgdev.pl=
> wrote:
>
> > 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.
>
> OK I trust you to come up with something better for sure!
>
> With regards to the ability to unbind/rebind drivers from sysfs, true.
> I have heard about that as a counterargument to many things.
>
> The problem is that I have never heard about a user unbinding/binding
> a driver from sysfs for anything but debugging a drivers ability to
> bind/unbind. Partly I feel that thing should just be moved
> to debugfs given the usecase and because it just looks like a way for
> attackers to provoke crashes given how some drivers look.
>
> Yours,
> Linus Walleij

That's not the only thing - device unbind can also be triggered by
removing the module providing the driver which is a completely normal
operation for user-space.

Bart