[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aNJjZ9ouRSkkyyxU@2a01cb069018a810e4ede1071806178f.ipv6.abo.wanadoo.fr>
Date: Tue, 23 Sep 2025 11:07:51 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Waiman Long <llong@...hat.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Marco Crivellari <marco.crivellari@...e.com>,
Michal Hocko <mhocko@...e.com>,
Peter Zijlstra <peterz@...radead.org>, Tejun Heo <tj@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Vlastimil Babka <vbabka@...e.cz>, linux-pci@...r.kernel.org
Subject: Re: [PATCH 02/33] PCI: Protect against concurrent change of
housekeeping cpumask
Le Mon, Sep 22, 2025 at 05:51:39PM -0400, Waiman Long a écrit :
> On 9/18/25 10:00 AM, Frederic Weisbecker wrote:
> > No the point is that I need to keep the target selection
> > (housekeeping_cpumask() read) and the work queue within the same
> > RCU critical section so that things are synchronized that way:
> >
> > CPU 0 CPU 1
> > ----- -----
> > rcu_read_lock() housekeeping_update()
> > cpu = cpumask_any(housekeeping_cpumask(...)) housekeeping_cpumask &= ~val
> > queue_work_on(cpu, pci_probe_wq, work) synchronize_rcu()
> > rcu_read_unlock() flush_workqueue(pci_probe_wq)
> > flush_work(work)
> > And I can't include the whole work_on_cpu() within rcu_read_lock() because
> > flush_work() may sleep.
>
> Right, you are trying to avoid flush_work() within rcu_read_lock() critical
> section. It makes it easier to review if you mention that in the commit log.
Good point!
>
> >
> > Also now that you mention it, I need to create that pci_probe_wq and flush it :-)
>
> OK, another wq :-)
Yeah I know :-s
>
> Cheers,
> Longman
>
--
Frederic Weisbecker
SUSE Labs
Powered by blists - more mailing lists