From: Saurabh Singh Sengar <ssengar@linux.microsoft.com>
To: Alexander Stein <alexander.stein@ew.tq-group.com>
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, decui@microsoft.com
Subject: Re: [PATCH] PCI/sysfs: Fix race in pci sysfs creation
Date: Fri, 19 Jan 2024 22:41:56 -0800 [thread overview]
Message-ID: <20240120064156.GA3130@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> (raw)
In-Reply-To: <20240104053803.GA16954@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On Wed, Jan 03, 2024 at 09:38:03PM -0800, Saurabh Singh Sengar wrote:
> On Tue, Dec 12, 2023 at 12:28:05AM -0800, Saurabh Singh Sengar wrote:
> > On Tue, Dec 12, 2023 at 08:19:11AM +0100, Alexander Stein wrote:
> > > Hi Saurabh,
> > >
> > > thanks for the patch.
> > >
> > > Am Samstag, 9. Dezember 2023, 04:46:16 CET schrieb Saurabh Sengar:
> > > > Currently there is a race in calling pci_create_resource_files function
> > > > from two different therads, first therad is triggered by pci_sysfs_init
> > > > from the late initcall where as the second thread is initiated by
> > > > pci_bus_add_devices from the respective PCI drivers probe.
> > > >
> > > > The synchronization between these threads relies on the sysfs_initialized
> > > > flag. However, in pci_sysfs_init, sysfs_initialized is set right before
> > > > calling pci_create_resource_files which is wrong as it can create race
> > > > condition with pci_bus_add_devices threads. Fix this by setting
> > > > sysfs_initialized flag at the end of pci_sysfs_init and direecly call the
> > >
> > > Small typo here: direecly -> directly
> > >
> > > > pci_create_resource_files function from it.
> > > >
> > > > There can be an additional case where driver probe is so delayed that
> > > > pci_bus_add_devices is called after the sysfs is created by pci_sysfs_init.
> > > > In such cases, attempting to access already existing sysfs resources is
> > > > unnecessary. Fix this by adding a check for sysfs attributes and return
> > > > if they are already allocated.
> > > >
> > > > In both cases, the consequence will be the removal of sysfs resources that
> > > > were appropriately allocated by pci_sysfs_init following the warning below.
> > >
> > > I'm not sure if this is the way to go. Unfortunately I can't trigger this
> > > error on my imx6 platform at the moment (apparently timing is off).
> > > But reading [1] again, the most expressive way is that pci_bus_add_devices()
> > > needs to wait until pci_sysfs_init() has passed.
> >
> > (I correct my self a bit in my earlier reply)
> > The problem with waiting is that sysfs entries will be created by pci_sysfs_init
> > already and when pci_bus_add_devices try to create it will observe that the
> > entries are already existing and in such case PCI code will remove the sysfs
> > entries created by pci_sysfs_init. Resulting system will be having no sysfs
> > entries.
>
>
> Hi Alexander,
> Have you got time to check this ? Please let me know if you think there is any
> concern left with this patch.
Hi PCI Maintainers,
If there is no objection, can we take this patch in ?
Regards,
Saurabh
next prev parent reply other threads:[~2024-01-20 6:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-09 3:46 [PATCH] PCI/sysfs: Fix race in pci sysfs creation Saurabh Sengar
2023-12-12 7:19 ` Alexander Stein
2023-12-12 8:21 ` Saurabh Singh Sengar
2023-12-12 8:28 ` Saurabh Singh Sengar
2024-01-04 5:38 ` Saurabh Singh Sengar
2024-01-20 6:41 ` Saurabh Singh Sengar [this message]
2024-02-02 7:17 ` Saurabh Singh Sengar
2024-02-06 22:07 ` Bjorn Helgaas
2024-02-07 16:30 ` Saurabh Singh Sengar
2024-02-27 17:14 ` Saurabh Singh Sengar
2024-02-28 15:22 ` Bjorn Helgaas
2024-02-28 17:22 ` Krzysztof Wilczyński
2024-02-28 18:16 ` Saurabh Singh Sengar
2024-04-15 18:15 ` [EXTERNAL] " Saurabh Singh Sengar
2024-03-02 8:57 ` Lukas Wunner
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=20240120064156.GA3130@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net \
--to=ssengar@linux.microsoft.com \
--cc=alexander.stein@ew.tq-group.com \
--cc=bhelgaas@google.com \
--cc=decui@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.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 read-only IMAP folder(s) and NNTP newsgroup(s).