linux-kernel - Re: [PATCH] PCI: Avoid work_on

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] [day] [month] [year] [list]

Message-Id: <DFFXIZR1AGTV.2WZ1G2JAU0HFQ@kernel.org>
Date: Sun, 04 Jan 2026 17:01:50 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Bjorn Helgaas" <helgaas@...nel.org>
Cc: "Jinhui Guo" <guojinhui.liam@...edance.com>,
 <alexander.h.duyck@...ux.intel.com>, "Bjorn Helgaas" <bhelgaas@...gle.com>,
 "Bart Van Assche" <bvanassche@....org>, "Dan Williams"
 <dan.j.williams@...el.com>, "Greg Kroah-Hartman"
 <gregkh@...uxfoundation.org>, <linux-kernel@...r.kernel.org>,
 <linux-pci@...r.kernel.org>, <stable@...r.kernel.org>, "Tejun Heo"
 <tj@...nel.org>, "Alexander Duyck" <alexanderduyck@...com>, "Rafael J.
 Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH] PCI: Avoid work_on_cpu() in async probe workers

On Wed Dec 31, 2025 at 5:55 PM CET, Bjorn Helgaas wrote:
> On Wed, Dec 31, 2025 at 03:51:05PM +0800, Jinhui Guo wrote:
>> Hi, Bjorn
>> 
>> Thank you for your time and kind reply.
>> 
>> As I see it, two scenarios should be borne in mind:
>> 
>> 1. Driver allowed to probe asynchronously
>>    The driver core schedules async workers via async_schedule_dev(),
>>    so pci_call_probe() needs no extra queue_work_node().
>> 
>> 2. Driver not allowed to probe asynchronously
>>    The driver core (__driver_attach() or __device_attach()) calls
>>    pci_call_probe() directly, without any async worker from
>>    async_schedule_dev(). NUMA-node awareness in pci_call_probe()
>>    is therefore still required.
>
> Good point, we need the NUMA awareness in both sync and async probe
> paths.
>
> But node affinity is orthogonal to the sync/async question, so it
> seems weird to deal with affinity in two separate places.

In general I agree, but implementation wise it might make a difference:

In the async path we ultimately use queue_work_node(), which may fall back to
default queue_work() behavior or explicitly picks the current CPU to queue work,
if we are on the corresponding NUMA node already.

In the sync path however - if we want to do something about NUMA affinity - we
probably want to queue work as well and wait for completion, but in the fallback
case always execute the code ourselves, i.e. do not queue any work at all.

> It also
> seems sub-optimal to have node affinity in the driver core async path
> but not the synchronous probe path.
>
> Maybe driver_probe_device() should do something about NUMA affinity?

driver_probe_device() might not be the best place, as it is the helper executed
from within the async path (work queue) and sync path (unless you have something
else in mind than what I mentioned above).

I think __device_attach() and __driver_attach() - probably through a common
helper - should handle NUMA affinity instead.