linux-kernel - Re: [PATCH] reset: allow to pass NULL pointer to reset_control

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: <1462365283.3536.27.camel@pengutronix.de>
Date:	Wed, 04 May 2016 14:34:43 +0200
From:	Philipp Zabel <p.zabel@...gutronix.de>
To:	Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] reset: allow to pass NULL pointer to reset_control_put()

Am Mittwoch, den 04.05.2016, 20:34 +0900 schrieb Masahiro Yamada:
> Hi Arnd,
> 
> 2016-05-04 20:24 GMT+09:00 Arnd Bergmann <arnd@...db.de>:
> > On Wednesday 04 May 2016 20:17:51 Masahiro Yamada wrote:
> >> Currently, reset_control_put() just returns for error pointer,
> >> but not for NULL pointer.  This is not reasonable.
> >>
> >> Passing NULL pointer should be allowed as well to make failure path
> >> handling easier.
> >>
> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@...ionext.com>
> >> ---
> >>
> >>  drivers/reset/core.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/reset/core.c b/drivers/reset/core.c
> >> index 181b05d..7bb16d1 100644
> >> --- a/drivers/reset/core.c
> >> +++ b/drivers/reset/core.c
> >> @@ -288,7 +288,7 @@ EXPORT_SYMBOL_GPL(reset_control_get);
> >>
> >>  void reset_control_put(struct reset_control *rstc)
> >>  {
> >> -       if (IS_ERR(rstc))
> >> +       if (IS_ERR_OR_NULL(rstc))
> >>                 return;
> >>
> >>         module_put(rstc->rcdev->owner);
> >
> > Using IS_ERR_OR_NULL() normally indicates that there is something
> > wrong with the API, or with the caller.
> >
> > What exactly is the idea behind treating an error pointer as a valid
> > input to reset_control_put() here? Maybe it should just test for
> > NULL?

The idea was that you could do
	drvdata->rstc = reset_control_get(...)
in the probe() function and
	reset_control_put(drvdata->rstc)
in remove() without having to check for IS_ERR(drvdata->rstc) again.
I'm not convinced this is necessarily a good idea though. To simplify
the teardown path we already have  devm_reset_control_get().

> I thought about that a bit,
> but there might be some (not nice) drivers that rely on the current behavior.
> I did not want to break any boards with my patch.
> 
> So, should it be
> 
>           if (!rstc)
>                     return;
> or, perhaps
> 
>           if (!rstc || WARN_ON_ONCE(IS_ERR(rstc)))
>                     return;
> 
> ?

NULL is not a valid input to reset_control, reset_control_get(_optional)
should never return NULL.

I'd be in favor of turning this into

	if (WARN_ON(IS_ERR_OR_NULL(rstc)))
		return;

As far as I am aware, ehci-tegra is the only driver that currently makes
use of the IS_ERR(rstc) return in reset_control_put():

        struct reset_control *usb1_reset;

        usb1_reset = of_reset_control_get(phy_np, "usb");
        if (IS_ERR(usb1_reset)) {
		/* ... */
	} else {
                reset_control_assert(usb1_reset);
                udelay(1);
                reset_control_deassert(usb1_reset);
        }
        reset_control_put(usb1_reset);

That'd be trivial to fix.

regards
Philipp