lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 2 Mar 2024 09:57:17 +0100
From: Lukas Wunner <lukas@...ner.de>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Saurabh Sengar <ssengar@...ux.microsoft.com>, bhelgaas@...gle.com,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	alexander.stein@...tq-group.com, decui@...rosoft.com,
	Krzysztof Wilczy??ski <kwilczynski@...nel.org>
Subject: Re: [PATCH] PCI/sysfs: Fix race in pci sysfs creation

On Tue, Feb 06, 2024 at 04:07:15PM -0600, Bjorn Helgaas wrote:
> Krzysztof has done a ton of work to convert these files to static
> attributes, where the device model prevents most of these races:
> 
>   506140f9c06b ("PCI/sysfs: Convert "index", "acpi_index", "label" to static attributes")
>   d93f8399053d ("PCI/sysfs: Convert "vpd" to static attribute")
>   f42c35ea3b13 ("PCI/sysfs: Convert "reset" to static attribute")
>   527139d738d7 ("PCI/sysfs: Convert "rom" to static attribute")
>   e1d3f3268b0e ("PCI/sysfs: Convert "config" to static attribute")
> 
> and he even posted a series to do the same for the resource files:
> 
>   https://lore.kernel.org/linux-pci/20210910202623.2293708-1-kw@linux.com/
> 
> I can't remember why we didn't apply that at the time, and it no
> longer applies cleanly, but I think that's the direction we should go.

When I brought up resource sysfs files in October, Bjorn said:

    I think the reason pci_sysfs_init() exists in the first place is
    because those resources may be assigned after pci_device_add(), and
    (my memory is hazy here) it seems like changing the size of binary
    attributes is hard, which might fit with the
    pci_remove_resource_files() and pci_create_resource_files() in the
    resource##n##_resize_store() macro

    https://lore.kernel.org/all/20231019200110.GA1410324@bhelgaas/

I'm wondering in how far Krzysztof's above-mentioned patches
address the issue of late-appearing resources?

In the meantime I've learned of the existence of sysfs_update_group().
It would seem to me that if resources such as the ROM appear late,
we should just call sysfs_update_group() to make them show up in sysfs
(or correct the size of their sysfs files).

But that requires that we identify the places where resources
are unhidden.  Do we know where this happens?

Thanks,

Lukas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ