linux-kernel - Re: [PATCH v2 1/1] device property: Allow error pointer to be passed to fwnode APIs

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: <CAHp75Vd7QcujZKEtx2_PT-QxoAh7LAykkV3k_OOO5Q0tRQKrBA@mail.gmail.com>
Date:   Sat, 5 Mar 2022 23:46:46 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Nuno Sá <noname.nuno@...il.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Daniel Scally <djrscally@...il.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Nuno Sá <nuno.sa@...log.com>
Subject: Re: [PATCH v2 1/1] device property: Allow error pointer to be passed
 to fwnode APIs

On Sat, Mar 5, 2022 at 10:28 PM Nuno Sá <noname.nuno@...il.com> wrote:
>
> On Fri, 2022-03-04 at 19:32 +0200, Andy Shevchenko wrote:
> > Some of the fwnode APIs might return an error pointer instead of NULL
> > or valid fwnode handle. The result of such API call may be considered
> > optional and hence the test for it is usually done in a form of
> >
> >         fwnode = fwnode_find_reference(...);
> >         if (IS_ERR_OR_NULL(fwnode))
> >                 ...error handling...
> >
> > Nevertheless the resulting fwnode may have bumped reference count and
> > hence caller of the above API is obliged to call fwnode_handle_put().
> > Since fwnode may be not valid either as NULL or error pointer the
> > check
> > has to be performed there. This approach uglifies the code and adds
> > a point of making a mistake, i.e. forgetting about error point case.
> >
> > To prevent this allow error pointer to be passed to the fwnode APIs.

...

> >         ret = fwnode_call_int_op(fwnode, property_read_string_array,
> > propname,
> >                                  val, nval);
> > -       if (ret == -EINVAL && !IS_ERR_OR_NULL(fwnode) &&
> > -           !IS_ERR_OR_NULL(fwnode->secondary))
> > +       if (ret == -EINVAL && !IS_ERR_OR_NULL(fwnode->secondary))
> >                 ret = fwnode_call_int_op(fwnode->secondary,
> >                                          property_read_string_array,
>
> Isn't !IS_ERR_OR_NULL(fwnode->secondary)) redundant? AFAIU,
> fwnode_call_int_op() will already check the fwnode and only call the op
> if the pointer is valid...

It will shadow the error code, but it seems currently it's the same error code.
So, the question here is if we hide something important with that change.

I dunno what is the best approach here (esp. taking into account that
this is a fix), but ideally we should open code those macros to avoid
double test for fwnode being valid. Because it seems that validation
of fwnode and validation of the operation of the fwnode are orthogonal
and here we mix them. I made this way for the sake of easier
backporting and kicking off a discussion (as you already did). TL;DR:
I think the introduction of the macros was a controversial move, for
which I see pros and cons.


-- 
With Best Regards,
Andy Shevchenko