Re: Potential static analysis ideas

[Geert Uytterhoeven <geert@linux-m68k.org>]

Hi Arnd,

On Mon, Jul 26, 2021 at 10:52 AM Arnd Bergmann <arnd@arndb.de> wrote:
> 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.

And the clk API supports calling further clock ops with a NULL pointer,
which eases handling optional clocks.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds