Re: Potential static analysis ideas

[Arnd Bergmann <arnd@arndb.de>]

On Mon, Jul 26, 2021 at 10:39 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Jul 26, 2021 at 10:21 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > e) either a valid pointer, NULL, or an error pointer
> > >
> > > The last pattern is seen with the various *get*_optional() functions.
> >
> > I would always consider those the exact bug that I meant with "because
> > everyone gets those wrong". I think the idea of the "optional" functions is
> > that you have two implementations b) and d) and pick one of them
> > at compile time. To the caller this means either an error pointer or
> > success, but checking for NULL is a bug in the caller, while conditionally
> > returning NULL or ERR_PTR() would be a bug in the interface.
>
> e) is not for optional kernel features, but for optional hardware
> functionality.  So it is not known at compile time, but depends on
> e.g. the DTB.  See e.g. devm_clk_get_optional().

Ah right, I forgot we had those as well. However, I suppose no amount
of annotation is going to help with those, as far as the checker is concerned,
I would just leave this as not annotated. At least with the clk API,
the callers are not able to dereference the pointer because the definition
of 'struct clk' is private to drivers/clk/clk.c.

        Arnd