[PATCH v2 0/6] regulator: core: locking fixes and cleanups

[PATCH v2 0/6] regulator: core: locking fixes and cleanups

[Michał Mirosław]

This series reduces regulator locking code complexity. The single fix is
more a cosmetic one as it applies to unexpected (WARN-generating) error
paths.

Michał Mirosław (6):
  regulator: core: simplify regulator_lock_nested()
  regulator: core: skip nesting lock for -EDEADLK
  regulator: core: simplify nested locking
  regulator: core: remove `goto`s from resolve_supply()
  regulator: core: propagate error out ouf regulator_lock_two()
  regulator: core: simplify lock_two()

 drivers/regulator/core.c | 110 +++++++++++++++------------------------
 1 file changed, 42 insertions(+), 68 deletions(-)

-- 
2.39.2

[PATCH 1/6] regulator: core: simplify regulator_lock_nested()

[Michał Mirosław]

`lock` is only false when the `rdev` is already locked and the owner is
`current`. In this case `ret` is always zero. By removing `lock`, we
thus remove `mutex_owner` write avoidance, but make the code flow more
understandable.

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
 drivers/regulator/core.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index d8e1caaf207e..215b721e5cd4 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -141,27 +141,19 @@ static bool regulator_ops_is_valid(struct regulator_dev *rdev, int ops)
 static inline int regulator_lock_nested(struct regulator_dev *rdev,
 					struct ww_acquire_ctx *ww_ctx)
 {
-	bool lock = false;
 	int ret = 0;
 
 	mutex_lock(&regulator_nesting_mutex);
 
 	if (!ww_mutex_trylock(&rdev->mutex, ww_ctx)) {
-		if (rdev->mutex_owner == current)
-			rdev->ref_cnt++;
-		else
-			lock = true;
-
-		if (lock) {
+		if (rdev->mutex_owner != current) {
 			mutex_unlock(&regulator_nesting_mutex);
 			ret = ww_mutex_lock(&rdev->mutex, ww_ctx);
 			mutex_lock(&regulator_nesting_mutex);
 		}
-	} else {
-		lock = true;
 	}
 
-	if (lock && ret != -EDEADLK) {
+	if (ret != -EDEADLK) {
 		rdev->ref_cnt++;
 		rdev->mutex_owner = current;
 	}
-- 
2.39.2

Re: [PATCH 1/6] regulator: core: simplify regulator_lock_nested()

[Doug Anderson]

Hi,

On Sat, Aug 19, 2023 at 3:46 PM Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
>
> `lock` is only false when the `rdev` is already locked and the owner is
> `current`. In this case `ret` is always zero. By removing `lock`, we
> thus remove `mutex_owner` write avoidance, but make the code flow more
> understandable.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
>  drivers/regulator/core.c | 12 ++----------
>  1 file changed, 2 insertions(+), 10 deletions(-)

Agreed that this looks to be equivalent and easier to understand.

Reviewed-by: Douglas Anderson <dianders@chromium.org>

[PATCH 2/6] regulator: core: skip nesting lock for -EDEADLK

[Michał Mirosław]

When ww_mutex_lock() returns -EDEADLK the nesting mutex-protected
section becomes a no-op. Return early and avoid the extra lock.

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
 drivers/regulator/core.c | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 215b721e5cd4..921c7039baa3 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -145,18 +145,17 @@ static inline int regulator_lock_nested(struct regulator_dev *rdev,
 
 	mutex_lock(&regulator_nesting_mutex);
 
-	if (!ww_mutex_trylock(&rdev->mutex, ww_ctx)) {
-		if (rdev->mutex_owner != current) {
-			mutex_unlock(&regulator_nesting_mutex);
-			ret = ww_mutex_lock(&rdev->mutex, ww_ctx);
-			mutex_lock(&regulator_nesting_mutex);
-		}
+	if (!ww_mutex_trylock(&rdev->mutex, ww_ctx) &&
+	    rdev->mutex_owner != current) {
+		mutex_unlock(&regulator_nesting_mutex);
+		ret = ww_mutex_lock(&rdev->mutex, ww_ctx);
+		if (ret == -EDEADLK)
+			return ret;
+		mutex_lock(&regulator_nesting_mutex);
 	}
 
-	if (ret != -EDEADLK) {
-		rdev->ref_cnt++;
-		rdev->mutex_owner = current;
-	}
+	rdev->ref_cnt++;
+	rdev->mutex_owner = current;
 
 	mutex_unlock(&regulator_nesting_mutex);
 
-- 
2.39.2

Re: [PATCH 2/6] regulator: core: skip nesting lock for -EDEADLK

[Doug Anderson]

Hi,

On Sat, Aug 19, 2023 at 3:46 PM Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
>
> When ww_mutex_lock() returns -EDEADLK the nesting mutex-protected
> section becomes a no-op. Return early and avoid the extra lock.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
>  drivers/regulator/core.c | 19 +++++++++----------
>  1 file changed, 9 insertions(+), 10 deletions(-)

Reviewed-by: Douglas Anderson <dianders@chromium.org>

[PATCH 3/6] regulator: core: simplify nested locking

[Michał Mirosław]

Simplify regulator locking by removing locking around locking.
rdev->ref check when unlocking is moved inside the critical section.

This patch depends on 12235da8c80a ("kernel/locking: Add context to
ww_mutex_trylock()").

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
 drivers/regulator/core.c | 19 +++++--------------
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 921c7039baa3..87e54b776a0f 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -34,7 +34,6 @@
 #include "internal.h"
 
 static DEFINE_WW_CLASS(regulator_ww_class);
-static DEFINE_MUTEX(regulator_nesting_mutex);
 static DEFINE_MUTEX(regulator_list_mutex);
 static LIST_HEAD(regulator_map_list);
 static LIST_HEAD(regulator_ena_gpio_list);
@@ -143,23 +142,18 @@ static inline int regulator_lock_nested(struct regulator_dev *rdev,
 {
 	int ret = 0;
 
-	mutex_lock(&regulator_nesting_mutex);
-
 	if (!ww_mutex_trylock(&rdev->mutex, ww_ctx) &&
-	    rdev->mutex_owner != current) {
-		mutex_unlock(&regulator_nesting_mutex);
+	    READ_ONCE(rdev->mutex_owner) != current) {
 		ret = ww_mutex_lock(&rdev->mutex, ww_ctx);
+
 		if (ret == -EDEADLK)
 			return ret;
-		mutex_lock(&regulator_nesting_mutex);
 	}
 
 	rdev->ref_cnt++;
 	rdev->mutex_owner = current;
 
-	mutex_unlock(&regulator_nesting_mutex);
-
-	return ret;
+	return 0;
 }
 
 /**
@@ -186,16 +180,13 @@ static void regulator_lock(struct regulator_dev *rdev)
  */
 static void regulator_unlock(struct regulator_dev *rdev)
 {
-	mutex_lock(&regulator_nesting_mutex);
+	if (WARN_ON_ONCE(rdev->ref_cnt <= 0))
+		return;
 
 	if (--rdev->ref_cnt == 0) {
 		rdev->mutex_owner = NULL;
 		ww_mutex_unlock(&rdev->mutex);
 	}
-
-	WARN_ON_ONCE(rdev->ref_cnt < 0);
-
-	mutex_unlock(&regulator_nesting_mutex);
 }
 
 /**
-- 
2.39.2

Re: [PATCH 3/6] regulator: core: simplify nested locking

[Doug Anderson]

Hi,

On Sat, Aug 19, 2023 at 3:46 PM Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
>
> Simplify regulator locking by removing locking around locking.
> rdev->ref check when unlocking is moved inside the critical section.
>
> This patch depends on 12235da8c80a ("kernel/locking: Add context to
> ww_mutex_trylock()").

nit: when I run checkpatch, it always wants me to put the word
"commit" before the git hash when I refer to a commit. ;-)


> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
>  drivers/regulator/core.c | 19 +++++--------------
>  1 file changed, 5 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 921c7039baa3..87e54b776a0f 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -34,7 +34,6 @@
>  #include "internal.h"
>
>  static DEFINE_WW_CLASS(regulator_ww_class);
> -static DEFINE_MUTEX(regulator_nesting_mutex);
>  static DEFINE_MUTEX(regulator_list_mutex);
>  static LIST_HEAD(regulator_map_list);
>  static LIST_HEAD(regulator_ena_gpio_list);
> @@ -143,23 +142,18 @@ static inline int regulator_lock_nested(struct regulator_dev *rdev,
>  {
>         int ret = 0;

nit: remove initialization of "ret" to 0 since changing "return ret"
to "return 0" below. Those changes belong in one of the previous
patch, too.


> -       mutex_lock(&regulator_nesting_mutex);
> -
>         if (!ww_mutex_trylock(&rdev->mutex, ww_ctx) &&
> -           rdev->mutex_owner != current) {
> -               mutex_unlock(&regulator_nesting_mutex);
> +           READ_ONCE(rdev->mutex_owner) != current) {
>                 ret = ww_mutex_lock(&rdev->mutex, ww_ctx);
> +
>                 if (ret == -EDEADLK)
>                         return ret;
> -               mutex_lock(&regulator_nesting_mutex);
>         }
>
>         rdev->ref_cnt++;
>         rdev->mutex_owner = current;
>
> -       mutex_unlock(&regulator_nesting_mutex);
> -
> -       return ret;
> +       return 0;
>  }
>
>  /**
> @@ -186,16 +180,13 @@ static void regulator_lock(struct regulator_dev *rdev)
>   */
>  static void regulator_unlock(struct regulator_dev *rdev)
>  {
> -       mutex_lock(&regulator_nesting_mutex);
> +       if (WARN_ON_ONCE(rdev->ref_cnt <= 0))
> +               return;
>
>         if (--rdev->ref_cnt == 0) {
>                 rdev->mutex_owner = NULL;
>                 ww_mutex_unlock(&rdev->mutex);
>         }
> -
> -       WARN_ON_ONCE(rdev->ref_cnt < 0);
> -
> -       mutex_unlock(&regulator_nesting_mutex);

I guess the "fix" you talked about in the cover letter is moving the
WARN_ON up? That could be done in patch #1 and marked as a "Fix",
right?

I'm not 100% sure why we needed the "regulator_nesting_mutex" to begin
with. I'm also not 100% sure why we depend on commit 12235da8c80a
("kernel/locking: Add context to ww_mutex_trylock()"). Could you add
something to the commit message to make this more obvious so I don't
need to work so hard to figure it out? ;-)

Re: [PATCH 3/6] regulator: core: simplify nested locking

[Michał Mirosław]

On Mon, Aug 21, 2023 at 09:50:32AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Sat, Aug 19, 2023 at 3:46 PM Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
> >
> > Simplify regulator locking by removing locking around locking.
> > rdev->ref check when unlocking is moved inside the critical section.
> >
> > This patch depends on 12235da8c80a ("kernel/locking: Add context to
> > ww_mutex_trylock()").
> 
> nit: when I run checkpatch, it always wants me to put the word
> "commit" before the git hash when I refer to a commit. ;-)

> > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > ---
> >  drivers/regulator/core.c | 19 +++++--------------
> >  1 file changed, 5 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > index 921c7039baa3..87e54b776a0f 100644
> > --- a/drivers/regulator/core.c
> > +++ b/drivers/regulator/core.c
> > @@ -34,7 +34,6 @@
> >  #include "internal.h"
> >
> >  static DEFINE_WW_CLASS(regulator_ww_class);
> > -static DEFINE_MUTEX(regulator_nesting_mutex);
> >  static DEFINE_MUTEX(regulator_list_mutex);
> >  static LIST_HEAD(regulator_map_list);
> >  static LIST_HEAD(regulator_ena_gpio_list);
> > @@ -143,23 +142,18 @@ static inline int regulator_lock_nested(struct regulator_dev *rdev,
> >  {
> >         int ret = 0;
> 
> nit: remove initialization of "ret" to 0 since changing "return ret"
> to "return 0" below. Those changes belong in one of the previous
> patch, too.

Will do.

> > -       mutex_lock(&regulator_nesting_mutex);
> > -
> >         if (!ww_mutex_trylock(&rdev->mutex, ww_ctx) &&
> > -           rdev->mutex_owner != current) {
> > -               mutex_unlock(&regulator_nesting_mutex);
> > +           READ_ONCE(rdev->mutex_owner) != current) {
> >                 ret = ww_mutex_lock(&rdev->mutex, ww_ctx);
> > +
> >                 if (ret == -EDEADLK)
> >                         return ret;
> > -               mutex_lock(&regulator_nesting_mutex);
> >         }
> >
> >         rdev->ref_cnt++;
> >         rdev->mutex_owner = current;
> >
> > -       mutex_unlock(&regulator_nesting_mutex);
> > -
> > -       return ret;
> > +       return 0;
> >  }
> >
> >  /**
> > @@ -186,16 +180,13 @@ static void regulator_lock(struct regulator_dev *rdev)
> >   */
> >  static void regulator_unlock(struct regulator_dev *rdev)
> >  {
> > -       mutex_lock(&regulator_nesting_mutex);
> > +       if (WARN_ON_ONCE(rdev->ref_cnt <= 0))
> > +               return;
> >
> >         if (--rdev->ref_cnt == 0) {
> >                 rdev->mutex_owner = NULL;
> >                 ww_mutex_unlock(&rdev->mutex);
> >         }
> > -
> > -       WARN_ON_ONCE(rdev->ref_cnt < 0);
> > -
> > -       mutex_unlock(&regulator_nesting_mutex);
> 
> I guess the "fix" you talked about in the cover letter is moving the
> WARN_ON up? That could be done in patch #1 and marked as a "Fix",
> right?

The fix is patch #5. (And has a Fixes line to mark it. :-)

Moving WARN_ON up is needed to keep it from touching ref_cnt outside of
the locked code (the regulator_nesting_mutex was protecting it before).

> I'm not 100% sure why we needed the "regulator_nesting_mutex" to begin
> with. I'm also not 100% sure why we depend on commit 12235da8c80a
> ("kernel/locking: Add context to ww_mutex_trylock()"). Could you add
> something to the commit message to make this more obvious so I don't
> need to work so hard to figure it out? ;-)

Commit 12235da8c80a is needed as it enables ww_mutex_trylock() to
correcly account the lock in ww_ctx if it was able to grab it.

Best Regards
Michał Mirosław

[PATCH 4/6] regulator: core: remove `goto`s from resolve_supply()

[Michał Mirosław]

Since 14a71d509ac8 ("Fix lockdep warning resolving supplies") the `out`
label is just `return ret;`. Inline it for easier reading.

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
 drivers/regulator/core.c | 29 +++++++++++------------------
 1 file changed, 11 insertions(+), 18 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 87e54b776a0f..de434d550937 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2053,11 +2053,9 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
 
 	r = regulator_dev_lookup(dev, rdev->supply_name);
 	if (IS_ERR(r)) {
-		ret = PTR_ERR(r);
-
 		/* Did the lookup explicitly defer for us? */
-		if (ret == -EPROBE_DEFER)
-			goto out;
+		if (PTR_ERR(r) == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
 
 		if (have_full_constraints()) {
 			r = dummy_regulator_rdev;
@@ -2065,18 +2063,15 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
 		} else {
 			dev_err(dev, "Failed to resolve %s-supply for %s\n",
 				rdev->supply_name, rdev->desc->name);
-			ret = -EPROBE_DEFER;
-			goto out;
+			return -EPROBE_DEFER;
 		}
 	}
 
 	if (r == rdev) {
 		dev_err(dev, "Supply for %s (%s) resolved to itself\n",
 			rdev->desc->name, rdev->supply_name);
-		if (!have_full_constraints()) {
-			ret = -EINVAL;
-			goto out;
-		}
+		if (!have_full_constraints())
+			return -EINVAL;
 		r = dummy_regulator_rdev;
 		get_device(&r->dev);
 	}
@@ -2090,8 +2085,7 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
 	if (r->dev.parent && r->dev.parent != rdev->dev.parent) {
 		if (!device_is_bound(r->dev.parent)) {
 			put_device(&r->dev);
-			ret = -EPROBE_DEFER;
-			goto out;
+			return -EPROBE_DEFER;
 		}
 	}
 
@@ -2099,7 +2093,7 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
 	ret = regulator_resolve_supply(r);
 	if (ret < 0) {
 		put_device(&r->dev);
-		goto out;
+		return ret;
 	}
 
 	/*
@@ -2113,14 +2107,14 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
 	if (rdev->supply) {
 		regulator_unlock_two(rdev, r, &ww_ctx);
 		put_device(&r->dev);
-		goto out;
+		return 0;
 	}
 
 	ret = set_supply(rdev, r);
 	if (ret < 0) {
 		regulator_unlock_two(rdev, r, &ww_ctx);
 		put_device(&r->dev);
-		goto out;
+		return ret;
 	}
 
 	regulator_unlock_two(rdev, r, &ww_ctx);
@@ -2135,12 +2129,11 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
 		if (ret < 0) {
 			_regulator_put(rdev->supply);
 			rdev->supply = NULL;
-			goto out;
+			return ret;
 		}
 	}
 
-out:
-	return ret;
+	return 0;
 }
 
 /* Internal regulator request function */
-- 
2.39.2

Re: [PATCH 4/6] regulator: core: remove `goto`s from resolve_supply()

[Doug Anderson]

Hi,

On Sat, Aug 19, 2023 at 3:46 PM Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
>
> Since 14a71d509ac8 ("Fix lockdep warning resolving supplies") the `out`
> label is just `return ret;`. Inline it for easier reading.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
>  drivers/regulator/core.c | 29 +++++++++++------------------
>  1 file changed, 11 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c

Please also remove the initialization of ret to 0 ("int ret = 0;") at
the start of the function. Then:

Reviewed-by: Douglas Anderson <dianders@chromium.org>

[PATCH 5/6] regulator: core: propagate error out ouf regulator_lock_two()

[Michał Mirosław]

Fix up error paths from regulator_lock_two(): although it should not
fail, returning with half-locked state after issuing a WARN() asks
for even more trouble.

Fixes: cba6cfdc7c3f ("regulator: core: Avoid lockdep reports when resolving supplies")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
 drivers/regulator/core.c | 29 ++++++++++++++++++-----------
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index de434d550937..d8c2277cea36 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -197,9 +197,9 @@ static void regulator_unlock(struct regulator_dev *rdev)
  *
  * Locks both rdevs using the regulator_ww_class.
  */
-static void regulator_lock_two(struct regulator_dev *rdev1,
-			       struct regulator_dev *rdev2,
-			       struct ww_acquire_ctx *ww_ctx)
+static int regulator_lock_two(struct regulator_dev *rdev1,
+			      struct regulator_dev *rdev2,
+			      struct ww_acquire_ctx *ww_ctx)
 {
 	struct regulator_dev *held, *contended;
 	int ret;
@@ -208,10 +208,13 @@ static void regulator_lock_two(struct regulator_dev *rdev1,
 
 	/* Try to just grab both of them */
 	ret = regulator_lock_nested(rdev1, ww_ctx);
-	WARN_ON(ret);
+	if (WARN_ON(ret))
+		goto exit;
 	ret = regulator_lock_nested(rdev2, ww_ctx);
-	if (ret != -EDEADLOCK) {
-		WARN_ON(ret);
+	if (!ret)
+		return 0;
+	if (WARN_ON(ret != -EDEADLOCK)) {
+		regulator_unlock(rdev1);
 		goto exit;
 	}
 
@@ -225,15 +228,15 @@ static void regulator_lock_two(struct regulator_dev *rdev1,
 		contended->mutex_owner = current;
 		swap(held, contended);
 		ret = regulator_lock_nested(contended, ww_ctx);
-
-		if (ret != -EDEADLOCK) {
-			WARN_ON(ret);
+		if (!ret)
+			return 0;
+		if (WARN_ON(ret != -EDEADLOCK))
 			break;
-		}
 	}
 
 exit:
 	ww_acquire_done(ww_ctx);
+	return ret;
 }
 
 /**
@@ -2101,7 +2104,11 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
 	 * between rdev->supply null check and setting rdev->supply in
 	 * set_supply() from concurrent tasks.
 	 */
-	regulator_lock_two(rdev, r, &ww_ctx);
+	ret = regulator_lock_two(rdev, r, &ww_ctx);
+	if (ret < 0) {
+		put_device(&r->dev);
+		return ret;
+	}
 
 	/* Supply just resolved by a concurrent task? */
 	if (rdev->supply) {
-- 
2.39.2

Re: [PATCH 5/6] regulator: core: propagate error out ouf regulator_lock_two()

[Doug Anderson]

Hi,

On Sat, Aug 19, 2023 at 3:46 PM Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
>
> Fix up error paths from regulator_lock_two(): although it should not
> fail, returning with half-locked state after issuing a WARN() asks
> for even more trouble.
>
> Fixes: cba6cfdc7c3f ("regulator: core: Avoid lockdep reports when resolving supplies")
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
>  drivers/regulator/core.c | 29 ++++++++++++++++++-----------
>  1 file changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index de434d550937..d8c2277cea36 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -197,9 +197,9 @@ static void regulator_unlock(struct regulator_dev *rdev)
>   *
>   * Locks both rdevs using the regulator_ww_class.
>   */
> -static void regulator_lock_two(struct regulator_dev *rdev1,
> -                              struct regulator_dev *rdev2,
> -                              struct ww_acquire_ctx *ww_ctx)
> +static int regulator_lock_two(struct regulator_dev *rdev1,
> +                             struct regulator_dev *rdev2,
> +                             struct ww_acquire_ctx *ww_ctx)

Please update the kerneldoc to talk about the return value.


>  {
>         struct regulator_dev *held, *contended;
>         int ret;
> @@ -208,10 +208,13 @@ static void regulator_lock_two(struct regulator_dev *rdev1,
>
>         /* Try to just grab both of them */
>         ret = regulator_lock_nested(rdev1, ww_ctx);
> -       WARN_ON(ret);
> +       if (WARN_ON(ret))
> +               goto exit;
>         ret = regulator_lock_nested(rdev2, ww_ctx);
> -       if (ret != -EDEADLOCK) {
> -               WARN_ON(ret);
> +       if (!ret)
> +               return 0;

Aren't you missing the "ww_acquire_done()" in this case? I know it's
optional, but nice to call it anyway...


> +       if (WARN_ON(ret != -EDEADLOCK)) {
> +               regulator_unlock(rdev1);
>                 goto exit;
>         }
>
> @@ -225,15 +228,15 @@ static void regulator_lock_two(struct regulator_dev *rdev1,
>                 contended->mutex_owner = current;
>                 swap(held, contended);
>                 ret = regulator_lock_nested(contended, ww_ctx);
> -
> -               if (ret != -EDEADLOCK) {
> -                       WARN_ON(ret);
> +               if (!ret)
> +                       return 0;

Aren't you missing the "ww_acquire_done()" in this case?


Overall, I guess I'm OK with this. I agree that we'd be in pretty bad
shape if we exited the routine and left one of the mutexes acquired,
which the old code could have done. However, at the same time these
error cases really shouldn't happen anyway. In that sense, I guess
they really should be BUG_ON(), but IIRC that's discouraged. Thus, I
think your patch is the right direction.


-Doug

[PATCH 6/6] regulator: core: simplify lock_two()

[Michał Mirosław]

Make regulator_lock_two() shorter by observing that we have only two
locks and when swapped earlier the retry code becomes identical to the
normal (optimistic) path.

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
 drivers/regulator/core.c | 28 ++++++++++------------------
 1 file changed, 10 insertions(+), 18 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index d8c2277cea36..9736507b62ff 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -201,37 +201,29 @@ static int regulator_lock_two(struct regulator_dev *rdev1,
 			      struct regulator_dev *rdev2,
 			      struct ww_acquire_ctx *ww_ctx)
 {
-	struct regulator_dev *held, *contended;
 	int ret;
 
 	ww_acquire_init(ww_ctx, &regulator_ww_class);
 
-	/* Try to just grab both of them */
 	ret = regulator_lock_nested(rdev1, ww_ctx);
 	if (WARN_ON(ret))
 		goto exit;
-	ret = regulator_lock_nested(rdev2, ww_ctx);
-	if (!ret)
-		return 0;
-	if (WARN_ON(ret != -EDEADLOCK)) {
-		regulator_unlock(rdev1);
-		goto exit;
-	}
 
-	held = rdev1;
-	contended = rdev2;
 	while (true) {
-		regulator_unlock(held);
-
-		ww_mutex_lock_slow(&contended->mutex, ww_ctx);
-		contended->ref_cnt++;
-		contended->mutex_owner = current;
-		swap(held, contended);
-		ret = regulator_lock_nested(contended, ww_ctx);
+		ret = regulator_lock_nested(rdev2, ww_ctx);
 		if (!ret)
 			return 0;
+
+		regulator_unlock(rdev1);
+
 		if (WARN_ON(ret != -EDEADLOCK))
 			break;
+
+		swap(rdev1, rdev2);
+
+		ww_mutex_lock_slow(&rdev1->mutex, ww_ctx);
+		rdev1->ref_cnt++;
+		rdev1->mutex_owner = current;
 	}
 
 exit:
-- 
2.39.2

Re: [PATCH 6/6] regulator: core: simplify lock_two()

[Doug Anderson]

Hi,

On Sat, Aug 19, 2023 at 3:46 PM Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
>
> Make regulator_lock_two() shorter by observing that we have only two
> locks and when swapped earlier the retry code becomes identical to the
> normal (optimistic) path.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
>  drivers/regulator/core.c | 28 ++++++++++------------------
>  1 file changed, 10 insertions(+), 18 deletions(-)

This is quite nearly a direct revert of commit 37473397b852
("regulator: core: Make regulator_lock_two() logic easier to follow"),
which was requested by Stephen in:

https://lore.kernel.org/r/CAE-0n53Eb1BeDPmjBycXUaQAF4ppiAM6UDWje_jiB9GAmR8MMw@mail.gmail.com

I don't personally have a strong opinion, but do prefer not to flip-flop. ;-)


-Doug

Re: [PATCH 6/6] regulator: core: simplify lock_two()

[Michał Mirosław]

On Mon, Aug 21, 2023 at 09:51:08AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Sat, Aug 19, 2023 at 3:46 PM Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
> >
> > Make regulator_lock_two() shorter by observing that we have only two
> > locks and when swapped earlier the retry code becomes identical to the
> > normal (optimistic) path.
> >
> > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > ---
> >  drivers/regulator/core.c | 28 ++++++++++------------------
> >  1 file changed, 10 insertions(+), 18 deletions(-)
> 
> This is quite nearly a direct revert of commit 37473397b852
> ("regulator: core: Make regulator_lock_two() logic easier to follow"),
> which was requested by Stephen in:
> 
> https://lore.kernel.org/r/CAE-0n53Eb1BeDPmjBycXUaQAF4ppiAM6UDWje_jiB9GAmR8MMw@mail.gmail.com
> 
> I don't personally have a strong opinion, but do prefer not to flip-flop. ;-)

Indeed they are quite similar. I did remove a bit more code than that,
though: in this case there is no early success return before the loop.

Instead of saying:

lock A
lock B
if ok return
if that failed, loop:
  unlock A
  lock B harder
  lock A
  if ok return
  swap A <-> B
  lock B

Now it's:

lock A
loop forever:
  lock B
  if ok, return
  unlock A
  swap them
  lock A harder

With the same condition 'A held' at the start of an iteration.

Best Regards
Michał Mirosław

Re: [PATCH 6/6] regulator: core: simplify lock_two()

[Stephen Boyd]

Quoting Michał Mirosław (2023-08-28 13:26:54)
> Indeed they are quite similar. I did remove a bit more code than that,
> though: in this case there is no early success return before the loop.
>
> Instead of saying:
>
> lock A
> lock B
> if ok return
> if that failed, loop:
>   unlock A
>   lock B harder
>   lock A
>   if ok return
>   swap A <-> B
>   lock B
>
> Now it's:
>
> lock A
> loop forever:
>   lock B
>   if ok, return
>   unlock A
>   swap them
>   lock A harder
>
> With the same condition 'A held' at the start of an iteration.
>

Removing duplicate code is great! I'm primarily concerned with
readability. The terms 'A' and 'B' doesn't make it easy for me. Can you
maintain the 'held' and 'contended' names for the variables?

That would be

 lock 'held'
 loop forever:
   lock 'contended'
   if ok, return
   unlock 'held'
   swap them
   lock 'held' harder

per the psuedo-code.

Re: [PATCH 6/6] regulator: core: simplify lock_two()

[Michał Mirosław]

On Tue, Aug 29, 2023 at 03:52:19PM -0500, Stephen Boyd wrote:
> Quoting Michał Mirosław (2023-08-28 13:26:54)
> > Indeed they are quite similar. I did remove a bit more code than that,
> > though: in this case there is no early success return before the loop.
> >
> > Instead of saying:
> >
> > lock A
> > lock B
> > if ok return
> > if that failed, loop:
> >   unlock A
> >   lock B harder
> >   lock A
> >   if ok return
> >   swap A <-> B
> >   lock B
> >
> > Now it's:
> >
> > lock A
> > loop forever:
> >   lock B
> >   if ok, return
> >   unlock A
> >   swap them
> >   lock A harder
> >
> > With the same condition 'A held' at the start of an iteration.
> >
> 
> Removing duplicate code is great! I'm primarily concerned with
> readability. The terms 'A' and 'B' doesn't make it easy for me. Can you
> maintain the 'held' and 'contended' names for the variables?
> 
> That would be
> 
> 1.  lock 'held'
> 2.  loop forever:
> 3.    lock 'contended'
> 4.    if ok, return
> 5.    unlock 'held'
> 6.    swap them
> 7.    lock 'held' harder

Doesn't this make it more confusing? The lock is 'held' only in lines
2-5 and looses this trait (but not the name) on the other lines.
'contended' is more problematic: the contended lock is called 'held'
before locking it at line 7.

The algorithm is basically: Take the locks in sequence. If that failed,
swap the order and try again.

Would a comment like the sentence above help with readability?

Or we could wrap the final lines of the iteration in a
'regulator_lock_contended()' to make it self-documenting?

Best Regards
Michał Mirosław

Re: [PATCH 6/6] regulator: core: simplify lock_two()

[Stephen Boyd]

Quoting Michał Mirosław (2023-08-29 14:25:46)
> On Tue, Aug 29, 2023 at 03:52:19PM -0500, Stephen Boyd wrote:
> > Quoting Michał Mirosław (2023-08-28 13:26:54)
> > > Indeed they are quite similar. I did remove a bit more code than that,
> > > though: in this case there is no early success return before the loop.
> > >
> > > Instead of saying:
> > >
> > > lock A
> > > lock B
> > > if ok return
> > > if that failed, loop:
> > >   unlock A
> > >   lock B harder
> > >   lock A
> > >   if ok return
> > >   swap A <-> B
> > >   lock B
> > >
> > > Now it's:
> > >
> > > lock A
> > > loop forever:
> > >   lock B
> > >   if ok, return
> > >   unlock A
> > >   swap them
> > >   lock A harder
> > >
> > > With the same condition 'A held' at the start of an iteration.
> > >
> >
> > Removing duplicate code is great! I'm primarily concerned with
> > readability. The terms 'A' and 'B' doesn't make it easy for me. Can you
> > maintain the 'held' and 'contended' names for the variables?
> >
> > That would be
> >
> > 1.  lock 'held'
> > 2.  loop forever:
> > 3.    lock 'contended'
> > 4.    if ok, return
> > 5.    unlock 'held'
> > 6.    swap them
> > 7.    lock 'held' harder
>
> Doesn't this make it more confusing? The lock is 'held' only in lines
> 2-5 and looses this trait (but not the name) on the other lines.
> 'contended' is more problematic: the contended lock is called 'held'
> before locking it at line 7.
>
> The algorithm is basically: Take the locks in sequence. If that failed,
> swap the order and try again.
>
> Would a comment like the sentence above help with readability?
>
> Or we could wrap the final lines of the iteration in a
> 'regulator_lock_contended()' to make it self-documenting?
>

Squash this in?

---8<---
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 9736507b62ff..39205cf00fb7 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -201,6 +201,7 @@ static int regulator_lock_two(struct regulator_dev *rdev1,
 			      struct regulator_dev *rdev2,
 			      struct ww_acquire_ctx *ww_ctx)
 {
+	struct regulator_dev *held, *contended;
 	int ret;

 	ww_acquire_init(ww_ctx, &regulator_ww_class);
@@ -208,22 +209,24 @@ static int regulator_lock_two(struct regulator_dev *rdev1,
 	ret = regulator_lock_nested(rdev1, ww_ctx);
 	if (WARN_ON(ret))
 		goto exit;
+	held = rdev1;
+	contended = rdev2;

 	while (true) {
-		ret = regulator_lock_nested(rdev2, ww_ctx);
+		ret = regulator_lock_nested(contended, ww_ctx);
 		if (!ret)
-			return 0;
+			break;

-		regulator_unlock(rdev1);
+		regulator_unlock(held);

 		if (WARN_ON(ret != -EDEADLOCK))
 			break;

-		swap(rdev1, rdev2);
+		ww_mutex_lock_slow(&contended->mutex, ww_ctx);
+		contended->ref_cnt++;
+		contended->mutex_owner = current;

-		ww_mutex_lock_slow(&rdev1->mutex, ww_ctx);
-		rdev1->ref_cnt++;
-		rdev1->mutex_owner = current;
+		swap(held, contended);
 	}

 exit:

Re: [PATCH 6/6] regulator: core: simplify lock_two()

[Michał Mirosław]

On Tue, Aug 29, 2023 at 05:57:31PM -0500, Stephen Boyd wrote:
> Quoting Michał Mirosław (2023-08-29 14:25:46)
> > On Tue, Aug 29, 2023 at 03:52:19PM -0500, Stephen Boyd wrote:
> > > Quoting Michał Mirosław (2023-08-28 13:26:54)
> > > > Indeed they are quite similar. I did remove a bit more code than that,
> > > > though: in this case there is no early success return before the loop.
> > > >
> > > > Instead of saying:
> > > >
> > > > lock A
> > > > lock B
> > > > if ok return
> > > > if that failed, loop:
> > > >   unlock A
> > > >   lock B harder
> > > >   lock A
> > > >   if ok return
> > > >   swap A <-> B
> > > >   lock B
> > > >
> > > > Now it's:
> > > >
> > > > lock A
> > > > loop forever:
> > > >   lock B
> > > >   if ok, return
> > > >   unlock A
> > > >   swap them
> > > >   lock A harder
> > > >
> > > > With the same condition 'A held' at the start of an iteration.
> > > >
> > >
> > > Removing duplicate code is great! I'm primarily concerned with
> > > readability. The terms 'A' and 'B' doesn't make it easy for me. Can you
> > > maintain the 'held' and 'contended' names for the variables?
> > >
> > > That would be
> > >
> > > 1.  lock 'held'
> > > 2.  loop forever:
> > > 3.    lock 'contended'
> > > 4.    if ok, return
> > > 5.    unlock 'held'
> > > 6.    swap them
> > > 7.    lock 'held' harder
> >
> > Doesn't this make it more confusing? The lock is 'held' only in lines
> > 2-5 and looses this trait (but not the name) on the other lines.
> > 'contended' is more problematic: the contended lock is called 'held'
> > before locking it at line 7.
> >
> > The algorithm is basically: Take the locks in sequence. If that failed,
> > swap the order and try again.
> >
> > Would a comment like the sentence above help with readability?
> >
> > Or we could wrap the final lines of the iteration in a
> > 'regulator_lock_contended()' to make it self-documenting?
> >
> 
> Squash this in?

I see that you prefer the held/contended intermediary names. I'd like to
understand why we differ in the perception of readability of this part
of code so that the change is needed? The algorithm is simple enough,
and it would work even if the locks weren't swapped for each iteration
(even if slower to finish). What is missing in the context of the
function's code? Are there some assumptions not easily visible?

BTW, I went on to add the regulator_lock_contended() to see how it
would look. I'll send a v2 with it so we can apply your proposal if
needed on top.

Best Regards,
Michał Mirosław

Re: [PATCH 6/6] regulator: core: simplify lock_two()

[Stephen Boyd]

Quoting Michał Mirosław (2023-08-30 10:25:22)
>
> I see that you prefer the held/contended intermediary names. I'd like to
> understand why we differ in the perception of readability of this part
> of code so that the change is needed? The algorithm is simple enough,
> and it would work even if the locks weren't swapped for each iteration
> (even if slower to finish).

The locks need to be swapped per the documentation above
ww_mutex_lock_slow(). This is how we ensure forward progress.

> What is missing in the context of the
> function's code? Are there some assumptions not easily visible?

Yes, there are assumptions that are harder to keep track of with the
names 'rdev1' and 'rdev2'. We have to make sure that we call
ww_mutex_lock_slow() on the contended mutex, not the one that we could
get first. I find it easier to keep track of which regulator is
contended and which regulator is held by having the local variable
names. It's not up to me though as I'm not the maintainer here.

>
> BTW, I went on to add the regulator_lock_contended() to see how it
> would look. I'll send a v2 with it so we can apply your proposal if
> needed on top.

Got it.