Linux PCI subsystem development
 help / color / mirror / Atom feed
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

  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