From: Brian Norris <briannorris@chromium.org>
To: Petr Pavlu <petr.pavlu@suse.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Luis Chamberlain <mcgrof@kernel.org>,
Daniel Gomez <da.gomez@kernel.org>,
linux-pci@vger.kernel.org, David Gow <davidgow@google.com>,
Rae Moar <rmoar@google.com>,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-modules@vger.kernel.org,
Johannes Berg <johannes@sipsolutions.net>,
Sami Tolvanen <samitolvanen@google.com>,
Richard Weinberger <richard@nod.at>, Wei Liu <wei.liu@kernel.org>,
Brendan Higgins <brendan.higgins@linux.dev>,
kunit-dev@googlegroups.com,
Anton Ivanov <anton.ivanov@cambridgegreys.com>,
linux-um@lists.infradead.org
Subject: Re: [PATCH 1/4] PCI: Support FIXUP quirks in modules
Date: Tue, 23 Sep 2025 10:42:14 -0700 [thread overview]
Message-ID: <aNLb9g0AbBXZCJ4m@google.com> (raw)
In-Reply-To: <c84d6952-7977-47cd-8f09-6ea223217337@suse.com>
Hi Petr,
On Tue, Sep 23, 2025 at 02:55:34PM +0200, Petr Pavlu wrote:
> On 9/13/25 12:59 AM, Brian Norris wrote:
> > @@ -259,6 +315,12 @@ void pci_fixup_device(enum pci_fixup_pass pass, struct pci_dev *dev)
> > return;
> > }
> > pci_do_fixups(dev, start, end);
> > +
> > + struct pci_fixup_arg arg = {
> > + .dev = dev,
> > + .pass = pass,
> > + };
> > + module_for_each_mod(pci_module_fixup, &arg);
>
> The function module_for_each_mod() walks not only modules that are LIVE,
> but also those in the COMING and GOING states. This means that this code
> can potentially execute a PCI fixup from a module before its init
> function is invoked, and similarly, a fixup can be executed after the
> exit function has already run. Is this intentional?
Thanks for the callout. I didn't really give this part much thought
previously.
Per the comments, COMING means "Full formed, running module_init". I
believe that is a good thing, actually; specifically for controller
drivers, module_init() might be probing the controller and enumerating
child PCI devices to which we should apply these FIXUPs. That is a key
case to support.
GOING is not clearly defined in the header comments, but it seems like
it's a relatively narrow window between determining there are no module
refcounts (and transition to GOING) and starting to really tear it down
(transitioning to UNFORMED before any significant teardown).
module_exit() runs in the GOING phase.
I think it does not make sense to execute FIXUPs on a GOING module; I'll
make that change.
Re-quoting one piece:
> This means that this code
> can potentially execute a PCI fixup from a module before its init
> function is invoked,
IIUC, this part is not true? A module is put into COMING state before
its init function is invoked.
> > --- a/kernel/module/main.c
> > +++ b/kernel/module/main.c
> > @@ -2702,6 +2702,32 @@ static int find_module_sections(struct module *mod, struct load_info *info)
> > sizeof(*mod->kunit_init_suites),
> > &mod->num_kunit_init_suites);
> > #endif
> > +#ifdef CONFIG_PCI_QUIRKS
> > + mod->pci_fixup_early = section_objs(info, ".pci_fixup_early",
> > + sizeof(*mod->pci_fixup_early),
> > + &mod->pci_fixup_early_size);
> > + mod->pci_fixup_header = section_objs(info, ".pci_fixup_header",
> > + sizeof(*mod->pci_fixup_header),
> > + &mod->pci_fixup_header_size);
> > + mod->pci_fixup_final = section_objs(info, ".pci_fixup_final",
> > + sizeof(*mod->pci_fixup_final),
> > + &mod->pci_fixup_final_size);
> > + mod->pci_fixup_enable = section_objs(info, ".pci_fixup_enable",
> > + sizeof(*mod->pci_fixup_enable),
> > + &mod->pci_fixup_enable_size);
> > + mod->pci_fixup_resume = section_objs(info, ".pci_fixup_resume",
> > + sizeof(*mod->pci_fixup_resume),
> > + &mod->pci_fixup_resume_size);
> > + mod->pci_fixup_suspend = section_objs(info, ".pci_fixup_suspend",
> > + sizeof(*mod->pci_fixup_suspend),
> > + &mod->pci_fixup_suspend_size);
> > + mod->pci_fixup_resume_early = section_objs(info, ".pci_fixup_resume_early",
> > + sizeof(*mod->pci_fixup_resume_early),
> > + &mod->pci_fixup_resume_early_size);
> > + mod->pci_fixup_suspend_late = section_objs(info, ".pci_fixup_suspend_late",
> > + sizeof(*mod->pci_fixup_suspend_late),
> > + &mod->pci_fixup_suspend_late_size);
> > +#endif
> >
> > mod->extable = section_objs(info, "__ex_table",
> > sizeof(*mod->extable), &mod->num_exentries);
>
> Nit: I suggest writing the object_size argument passed to section_objs()
> here directly as "1" instead of using sizeof(*mod->pci_fixup_...) =
> sizeof(void). This makes the style consistent with the other code in
> find_module_sections().
Ack.
Thanks,
Brian
next prev parent reply other threads:[~2025-09-23 17:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-12 22:59 [PATCH 0/4] PCI: Add support and tests for FIXUP quirks in modules Brian Norris
2025-09-12 22:59 ` [PATCH 1/4] PCI: Support " Brian Norris
2025-09-15 6:33 ` Johannes Berg
2025-09-15 18:34 ` Brian Norris
2025-09-23 12:55 ` Petr Pavlu
2025-09-23 17:42 ` Brian Norris [this message]
2025-09-24 7:48 ` Petr Pavlu
2025-10-06 22:58 ` Brian Norris
2025-10-20 11:53 ` Petr Pavlu
2025-09-12 22:59 ` [PATCH 2/4] PCI: Add KUnit tests for FIXUP quirks Brian Norris
2025-09-15 8:06 ` Tzung-Bi Shih
2025-09-15 20:25 ` Brian Norris
2025-09-12 22:59 ` [PATCH 3/4] um: Select PCI_DOMAINS_GENERIC Brian Norris
2025-09-12 22:59 ` [PATCH 4/4] kunit: qemu_configs: Add PCI to arm, arm64 Brian Norris
2025-09-15 13:48 ` [PATCH 0/4] PCI: Add support and tests for FIXUP quirks in modules Christoph Hellwig
2025-09-15 18:41 ` Brian Norris
2025-09-22 18:13 ` Christoph Hellwig
2025-09-22 18:48 ` Brian Norris
2025-09-29 8:56 ` Christoph Hellwig
2025-09-23 16:20 ` Manivannan Sadhasivam
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=aNLb9g0AbBXZCJ4m@google.com \
--to=briannorris@chromium.org \
--cc=anton.ivanov@cambridgegreys.com \
--cc=bhelgaas@google.com \
--cc=brendan.higgins@linux.dev \
--cc=da.gomez@kernel.org \
--cc=davidgow@google.com \
--cc=johannes@sipsolutions.net \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=mcgrof@kernel.org \
--cc=petr.pavlu@suse.com \
--cc=richard@nod.at \
--cc=rmoar@google.com \
--cc=samitolvanen@google.com \
--cc=wei.liu@kernel.org \
/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).