From: Bjorn Helgaas <helgaas@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Krzysztof Wilczyński" <kw@linux.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Dan Williams" <dan.j.williams@intel.com>,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
"Kees Cook" <keescook@chromium.org>,
"Pali Rohár" <pali@kernel.org>,
"Oliver O'Halloran" <oohall@gmail.com>,
linux-pci@vger.kernel.org
Subject: Re: [PATCH v3 0/2] Allow deferred execution of iomem_get_mapping()
Date: Fri, 30 Jul 2021 14:50:13 -0500 [thread overview]
Message-ID: <20210730195013.GA1090988@bjorn-Precision-5520> (raw)
In-Reply-To: <YQOI0qdVK0dudSbx@kroah.com>
On Fri, Jul 30, 2021 at 07:06:26AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 29, 2021 at 11:32:33PM +0000, Krzysztof Wilczyński wrote:
> > Hello,
> >
> > At the moment, the dependency on iomem_get_mapping() that is currently
> > used in the pci_create_resource_files() and pci_create_legacy_files()
> > stops us from completely retiring the late_initcall() that is used to
> > invoke pci_sysfs_init() when creating sysfs object for PCI devices.
> >
> > This dependency on iomem_get_mapping() stops us from retiring the
> > late_initcall at the moment as when we convert dynamically added sysfs
> > objects, that are primarily added in the pci_create_resource_files() and
> > pci_create_legacy_files(), as these attributes are added before the VFS
> > completes its initialisation, and since most of the PCI devices are
> > typically enumerated in subsys_initcall this leads to a failure and an
> > Oops related to iomem_get_mapping() access.
> >
> > See relevant conversations:
> > https://lore.kernel.org/linux-pci/20210204165831.2703772-1-daniel.vetter@ffwll.ch/
> > https://lore.kernel.org/linux-pci/20210313215747.GA2394467@bjorn-Precision-5520/
> >
> > After some deliberation about the problem at hand, Dan Williams
> > suggested a solution to the problem, as per:
> > https://lore.kernel.org/linux-pci/CAPcyv4i0y_4cMGEpNVShLUyUk3nyWH203Ry3S87BqnDJE0Rmxg@mail.gmail.com/
> >
> > The idea is to defer execution of the iomem_get_mapping() to only when
> > the sysfs open callback is run, and thus removing the reliance of
> > fs_initcalls to complete before any other sub-system that uses the
> > iomem_get_mapping().
> >
> > Currently, the PCI sub-system will benefit the most from this change
> > allowing for it to complete the transition from dynamically created to
> > static sysfs objects.
> >
> > This series aims to take Dan Williams' idea through the finish line.
> >
> > Related to:
> > https://lore.kernel.org/linux-pci/20210527205845.GA1421476@bjorn-Precision-5520/
> > https://lore.kernel.org/linux-pci/20210507102706.7658-1-danijel.slivka@amd.com/
> > https://lore.kernel.org/linux-pci/20200716110423.xtfyb3n6tn5ixedh@pali/
> >
> > Krzysztof
> >
>
> No objection from me on these, Bjorn, mind if I take them through my
> driver core tree?
That'd be great!
Is your tree immutable? I'm hoping we can take advantage of this to
get rid of pci_sysfs_init(), which will fix a race that people seem to
be hitting frequently now [1]. I think Krzysztof is getting pretty
close.
[1] https://lore.kernel.org/r/m3eebg9puj.fsf@t19.piap.pl
next prev parent reply other threads:[~2021-07-30 19:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-29 23:32 [PATCH v3 0/2] Allow deferred execution of iomem_get_mapping() Krzysztof Wilczyński
2021-07-29 23:32 ` [PATCH v3 1/2] sysfs: Invoke iomem_get_mapping() from the sysfs open callback Krzysztof Wilczyński
2021-07-30 19:44 ` Bjorn Helgaas
2021-07-29 23:32 ` [PATCH v3 2/2] sysfs: Rename struct bin_attribute member to f_mapping Krzysztof Wilczyński
2021-07-30 19:45 ` Bjorn Helgaas
2021-07-30 5:06 ` [PATCH v3 0/2] Allow deferred execution of iomem_get_mapping() Greg Kroah-Hartman
2021-07-30 19:50 ` Bjorn Helgaas [this message]
2021-08-05 12:43 ` Greg Kroah-Hartman
2021-08-06 11:05 ` Greg Kroah-Hartman
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=20210730195013.GA1090988@bjorn-Precision-5520 \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=kw@linux.com \
--cc=linux-pci@vger.kernel.org \
--cc=oohall@gmail.com \
--cc=pali@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