linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  reply	other threads:[~2023-10-03 20:41 UTC|newest]

Thread overview: 12+ 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 ` [PATCH 1/4] PCI: exynos: Don't put .remove callback in .exit.text section Uwe Kleine-König
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

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).