[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240223101115.6bf7d570@bootlin.com>
Date: Fri, 23 Feb 2024 10:11:15 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: Saravana Kannan <saravanak@...gle.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J. Wysocki"
<rafael@...nel.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>, Thomas Petazzoni
<thomas.petazzoni@...tlin.com>, Android Kernel Team
<kernel-team@...roid.com>
Subject: Re: [PATCH 1/2] driver core: Introduce device_link_wait_removal()
Hi Saravana,
On Tue, 20 Feb 2024 16:31:13 -0800
Saravana Kannan <saravanak@...gle.com> 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(fw_devlink_wq);
>
> Is there a reason this needs to be drain_workqueu() instead of
> flush_workqueue(). Drain is a stronger guarantee than we need in this
> case. All we are trying to make sure is that all the device link
> remove work queued so far have completed.
I used drain_workqueue() because drain_workqueue() allows for jobs already
present in a workqueue to re-queue a job and drain_workqueue() will wait
also for this new job completion.
I think flush_workqueue() doesn't wait for this chain queueing.
In our case, my understanding was that device_link_release_fn() calls
put_device() for the consumer and the supplier.
If refcounts reaches zero, devlink_dev_release() can be called again
and re-queue a job.
In device_link_wait_removal(), I don't want to break this kind of
recursive removal.
Maybe I missed something.
Should I still change to flush_workqueue() ?
Best regards,
Hervé
Powered by blists - more mailing lists