From: Bjorn Helgaas <helgaas@kernel.org>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: "Krzysztof Wilczyński" <kw@linux.com>,
"Rob Herring" <robh@kernel.org>,
"Mauro Carvalho Chehab" <mchehab+huawei@kernel.org>,
linux-pci@vger.kernel.org,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Binghui Wang" <wangbinghui@hisilicon.com>,
kernel@pengutronix.de, "Xiaowei Song" <songxiaowei@hisilicon.com>,
"Bjorn Helgaas" <bhelgaas@google.com>
Subject: Re: [PATCH 2/4] PCI: kirin: Don't put .remove callback in .exit.text section
Date: Tue, 3 Oct 2023 15:40:56 -0500 [thread overview]
Message-ID: <20231003204056.GA687507@bhelgaas> (raw)
In-Reply-To: <20231003202330.zsmqckgbk2wbhvos@pengutronix.de>
On Tue, Oct 03, 2023 at 10:23:30PM +0200, Uwe Kleine-König wrote:
> On Tue, Oct 03, 2023 at 12:15:24PM +0200, Uwe Kleine-König wrote:
> > On Mon, Oct 02, 2023 at 05:12:18PM -0500, Bjorn Helgaas wrote:
> > > On Sun, Oct 01, 2023 at 07:02:52PM +0200, Uwe Kleine-König wrote:
> > > > With CONFIG_PCIE_KIRIN=y and kirin_pcie_remove() marked with __exit, the
> > > > function is discarded from the driver. In this case a bound device can
> > > > still get unbound, e.g via sysfs. Then no cleanup code is run resulting
> > > > in resource leaks or worse.
> > >
> > > kirin_pcie_driver sets .suppress_bind_attrs = true.
> > >
> > > Doesn't that mean that we can't unbind a device via sysfs in this
> > > case?
> >
> > Oh indeed, that's something I missed.
> >
> > > I don't expect modpost to know about .suppress_bind_attrs, so maybe we
> > > should remove the __exit annotation even if it would be safe to keep
> > > it in this case. It's a tiny function anyway.
> >
> > the right thing to do then is something like:
> > https://lore.kernel.org/linux-rtc/20231002080529.2535610-7-u.kleine-koenig@pengutronix.de
> >
> > And then it would be consequent to also switch to
> > module_platform_driver_probe and move .probe to __init. Or drop
> > .suppress_bind_attrs and keep/put .probe() and .remove() in .text.
>
> The other three patches in this series don't suffer from this oversight
> and so are (from my POV) ready to go in.
Agreed. My first impression was that this would be v6.7 material, but
based on
https://lore.kernel.org/linux-kbuild/CAK7LNATyRg6Hc-fnTETERj-tdMFGaBDt0Fyhy9+jKCzAvzQ6Pg@mail.gmail.com/,
I guess that modpost change must be headed for v6.6?
And while I haven't seen problem reports, branching into the weeds
because of a sysfs "remove" would be a pretty bad outcome, so I can
see a case for v6.6 and stable tags as well. Is that your thought
process, too?
> If you tell me, which option you prefer for the kirin driver, I'll
> follow up with a matching patch. (If you don't know, my preference would
> be to drop .suppress_bind_attrs and move .probe() and .remove() to
> .text.)
I agree, dropping .suppress_bind_attrs would be desirable, although I
would hope for some kind of assurance that it's not there because of
an issue with removal or something.
Bjorn
next prev parent reply other threads:[~2023-10-03 20:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-01 17:02 [PATCH 0/4] pci: Fix some section mismatches Uwe Kleine-König
2023-10-01 17:02 ` Uwe Kleine-König
2023-10-01 17:02 ` [PATCH 1/4] PCI: exynos: Don't put .remove callback in .exit.text section Uwe Kleine-König
2023-10-01 17:02 ` Uwe Kleine-König
2023-10-02 1:38 ` Alim Akhtar
2023-10-02 1:38 ` Alim Akhtar
2023-10-01 17:02 ` [PATCH 2/4] PCI: kirin: " Uwe Kleine-König
2023-10-02 22:12 ` Bjorn Helgaas
2023-10-03 10:15 ` Uwe Kleine-König
2023-10-03 20:23 ` Uwe Kleine-König
2023-10-03 20:40 ` Bjorn Helgaas [this message]
2023-10-04 8:16 ` Uwe Kleine-König
2023-10-01 17:02 ` [PATCH 3/4] PCI: keystone: " Uwe Kleine-König
2023-10-01 17:02 ` [PATCH 4/4] PCI: keystone: Don't put .probe callback in .init.text section Uwe Kleine-König
2023-10-10 17:23 ` [PATCH 0/4] pci: Fix some section mismatches Bjorn Helgaas
2023-10-10 17:23 ` Bjorn Helgaas
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=20231003204056.GA687507@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=kernel@pengutronix.de \
--cc=kw@linux.com \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=robh@kernel.org \
--cc=songxiaowei@hisilicon.com \
--cc=u.kleine-koenig@pengutronix.de \
--cc=wangbinghui@hisilicon.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.