linux-kernel - Re: [PATCH v3 1/2] driver core: Introduce device_link_wait

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]

Message-ID: <20240229150019.07e6f7be@bootlin.com>
Date: Thu, 29 Feb 2024 15:00:19 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>, Nuno Sá
 <noname.nuno@...il.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Rob Herring
 <robh+dt@...nel.org>, Frank Rowand <frowand.list@...il.com>, Lizhi Hou
 <lizhi.hou@....com>, Max Zhen <max.zhen@....com>, Sonal Santan
 <sonal.santan@....com>, Stefano Stabellini <stefano.stabellini@...inx.com>,
 Jonathan Cameron <Jonathan.Cameron@...wei.com>,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, Allan Nielsen
 <allan.nielsen@...rochip.com>, Horatiu Vultur
 <horatiu.vultur@...rochip.com>, Steen Hegelund
 <steen.hegelund@...rochip.com>, Luca Ceresoli <luca.ceresoli@...tlin.com>,
 Nuno Sa <nuno.sa@...log.com>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>, stable@...r.kernel.org
Subject: Re: [PATCH v3 1/2] driver core: Introduce
 device_link_wait_removal()

Hi Rafael,

On Thu, 29 Feb 2024 14:10:58 +0100
"Rafael J. Wysocki" <rafael@...nel.org> wrote:

..

> > > > > +void device_link_wait_removal(void)
> > > > > +{
> > > > > +     /*
> > > > > +      * devlink removal jobs are queued in the dedicated work queue.
> > > > > +      * To be sure that all removal jobs are terminated, ensure that any
> > > > > +      * scheduled work has run to completion.
> > > > > +      */
> > > > > +     drain_workqueue(device_link_wq);
> > > > > +}  
> > > >
> > > > I'm still not convinced we can have a recursive call into devlinks removal
> > > > so I
> > > > do think flush_workqueue() is enough. I will defer to Saravana though...  
> > >
> > > AFAICS, the difference betwee flush_workqueue() and drain_workqueue()
> > > is the handling of the case when a given work item can queue up itself
> > > again.  This does not happen here.  
> >
> >
> > Yeah, that's also my understanding...  
> 
> Moreover, IIUC this is called after dropping the last reference to the
> device link in question and so after queuing up the link removal work.
> Because that work does not requeue itself, flush_workqueue() is
> sufficient to ensure that the removal work has been completed.
> 
> If anyone thinks that it may not be sufficient, please explain to me
> why you think so.  Otherwise, don't do stuff to prevent things you
> cannot explain.

I will move to flush_workqueue() in the next iteration.

Thanks for the review and the confirmation on this topic.

Best regards,
Hervé