All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herve Codina <herve.codina@bootlin.com>
To: Rob Herring <robh@kernel.org>
Cc: "Nuno Sá" <noname.nuno@gmail.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Frank Rowand" <frowand.list@gmail.com>,
	"Lizhi Hou" <lizhi.hou@amd.com>, "Max Zhen" <max.zhen@amd.com>,
	"Sonal Santan" <sonal.santan@amd.com>,
	"Stefano Stabellini" <stefano.stabellini@xilinx.com>,
	"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	"Allan Nielsen" <allan.nielsen@microchip.com>,
	"Horatiu Vultur" <horatiu.vultur@microchip.com>,
	"Steen Hegelund" <steen.hegelund@microchip.com>,
	"Luca Ceresoli" <luca.ceresoli@bootlin.com>,
	"Nuno Sa" <nuno.sa@analog.com>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	stable@vger.kernel.org, "Saravana Kannan" <saravanak@google.com>
Subject: Re: [PATCH v3 2/2] of: overlay: Synchronize of_overlay_remove() with the devlink removals
Date: Mon, 4 Mar 2024 17:49:33 +0100	[thread overview]
Message-ID: <20240304174933.7ad023f9@bootlin.com> (raw)
In-Reply-To: <20240304152202.GA222088-robh@kernel.org>

Hi Rob,

On Mon, 4 Mar 2024 09:22:02 -0600
Rob Herring <robh@kernel.org> wrote:

...

> > > @@ -853,6 +854,14 @@ static void free_overlay_changeset(struct
> > > overlay_changeset *ovcs)
> > >  {
> > >  	int i;
> > >  
> > > +	/*
> > > +	 * Wait for any ongoing device link removals before removing some of
> > > +	 * nodes. Drop the global lock while waiting
> > > +	 */
> > > +	mutex_unlock(&of_mutex);
> > > +	device_link_wait_removal();
> > > +	mutex_lock(&of_mutex);  
> > 
> > I'm still not convinced we need to drop the lock. What happens if someone else
> > grabs the lock while we are in device_link_wait_removal()? Can we guarantee that
> > we can't screw things badly?  
> 
> It is also just ugly because it's the callers of 
> free_overlay_changeset() that hold the lock and now we're releasing it 
> behind their back.
> 
> As device_link_wait_removal() is called before we touch anything, can't 
> it be called before we take the lock? And do we need to call it if 
> applying the overlay fails?
> 

Indeed, having device_link_wait_removal() is not needed when applying the
overlay fails.

I can call device_link_wait_removal() from the caller of_overlay_remove()
but not before the lock is taken.
We need to call it between __of_changeset_revert_notify() and
free_overlay_changeset() and so, the lock is taken.

This lead to the following sequence:
--- 8< ---
int of_overlay_remove(int *ovcs_id)
{
	...
	mutex_lock(&of_mutex);
	...

	ret = __of_changeset_revert_notify(&ovcs->cset);
	...

	ret_tmp = overlay_notify(ovcs, OF_OVERLAY_POST_REMOVE);
	...

	mutex_unlock(&of_mutex);
	device_link_wait_removal();
	mutex_lock(&of_mutex);

	free_overlay_changeset(ovcs);
	...
	mutex_unlock(&of_mutex);
	...
}
--- 8< ---

In this sequence, the question is:
Do we need to release the mutex lock while device_link_wait_removal() is
called ?

Best regards,
Hervé

-- 
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  parent reply	other threads:[~2024-03-04 16:49 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-29 10:52 [PATCH v3 0/2] Synchronize DT overlay removal with devlink removals Herve Codina
2024-02-29 10:52 ` [PATCH v3 1/2] driver core: Introduce device_link_wait_removal() Herve Codina
2024-02-29 11:16   ` Nuno Sá
2024-02-29 12:57     ` Rafael J. Wysocki
2024-02-29 13:01     ` Rafael J. Wysocki
2024-02-29 13:06       ` Nuno Sá
2024-02-29 13:10         ` Rafael J. Wysocki
2024-02-29 14:00           ` Herve Codina
2024-02-29 10:52 ` [PATCH v3 2/2] of: overlay: Synchronize of_overlay_remove() with the devlink removals Herve Codina
2024-02-29 11:18   ` Nuno Sá
2024-03-04 15:22     ` Rob Herring
2024-03-04 15:36       ` Nuno Sá
2024-03-04 16:49       ` Herve Codina [this message]
2024-03-05  6:47         ` Saravana Kannan
2024-03-05  7:36           ` Nuno Sá
2024-03-05 10:27             ` Herve Codina
2024-03-05 10:47               ` Nuno Sá
2024-03-06  2:59                 ` Saravana Kannan
2024-03-04 15:02 ` [PATCH v3 0/2] Synchronize DT overlay removal with " Rob Herring
2024-03-05  6:17   ` Saravana Kannan
2024-03-05  7:17     ` Nuno Sá

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240304174933.7ad023f9@bootlin.com \
    --to=herve.codina@bootlin.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=allan.nielsen@microchip.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=horatiu.vultur@microchip.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizhi.hou@amd.com \
    --cc=luca.ceresoli@bootlin.com \
    --cc=max.zhen@amd.com \
    --cc=noname.nuno@gmail.com \
    --cc=nuno.sa@analog.com \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=saravanak@google.com \
    --cc=sonal.santan@amd.com \
    --cc=stable@vger.kernel.org \
    --cc=steen.hegelund@microchip.com \
    --cc=stefano.stabellini@xilinx.com \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.