From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Hannes Reinecke <hare@suse.de>,
Julia Lawall <julia.lawall@inria.fr>,
Arnd Bergmann <arnd@arndb.de>, NeilBrown <neilb@suse.de>,
Dan Carpenter <dan.carpenter@oracle.com>,
ksummit@lists.linux.dev
Subject: Re: Potential static analysis ideas
Date: Mon, 26 Jul 2021 21:31:23 +0300 [thread overview]
Message-ID: <YP7/eyqDcJR3L8V9@pendragon.ideasonboard.com> (raw)
In-Reply-To: <8ca1815230074c5ae31ec401ff533c0bf4baed92.camel@HansenPartnership.com>
Hi James,
On Mon, Jul 26, 2021 at 10:54:59AM -0700, James Bottomley wrote:
> On Mon, 2021-07-26 at 11:16 +0200, Geert Uytterhoeven wrote:
> > On Mon, Jul 26, 2021 at 11:08 AM Hannes Reinecke wrote:
> > > On 7/26/21 10:55 AM, Julia Lawall wrote:
> > > > On Mon, 26 Jul 2021, Arnd Bergmann wrote:
> > > > > On Mon, Jul 26, 2021 at 9:53 AM Geert Uytterhoeven wrote:
> > > > > > On Mon, Jul 26, 2021 at 9:26 AM Arnd Bergmann wrote:
> > > > > > > On Sun, Jul 25, 2021 at 1:45 AM NeilBrown wrote:
> > > > > > > > On Sun, 25 Jul 2021, Laurent Pinchart wrote:
> > > > > > > > > > To make it work well, you need to know if frob() and/or the current
> > > > > > > > > > function return an error code or not. While you can use some heuristics
> > > > > > > > > > (e.g. is there any return -Exxx), perhaps we can add an annotation to
> > > > > > > > > > indicate if a function returns an error code, or an error pointer?
> > > > > > > > >
> > > > > > > > > https://lore.kernel.org/linux-media/YNMvarFl%2FKU1pGCG@pendragon.ideasonboard.com/
> > > > > > > > >
> > > > > > > > > I think it would be useful, if not for the tools, at least for
> > > > > > > > > developers.
> > > > > > > >
> > > > > > > > Agreed. I added some code to smatch so that I could annotate pointers to
> > > > > > > > say if they are allowed to be NULL. The implementation isn't perfect,
> > > > > > > > but I love having that extra documentation about when I do or don't have
> > > > > > > > to check for NULL.
> > > > > > >
> > > > > > > I can think of four different annotations that limit what a pointer return from
> > > > > > > a function can be:
> > > > > > >
> > > > > > > a) either a valid pointer or NULL, but never an error pointer,
> > > > > > > b) either a valid pointer or an error pointer, but not NULL,
> > > > > > > c) always a valid pointer, never NULL or an error,
> > > > > > > d) always NULL, but callers are expected to check for error
> > > > > > > pointers.
> > > > > >
> > > > > > 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.
> > > >
> > > > I'm not sure to understand the "bug in the caller" part. Couldn't there
> > > > be two possible definitions of the called function, according to different
> > > > configuration options, and a single caller that calls both?
> > > >
> > > > Also, over 230 files contain functions that return both NULL and ERR_PTR.
> > > > A random example, chosen for conciseness, is the following from
> > > > fs/overlayfs/inode.c:
> > > >
> > > > struct inode *ovl_lookup_inode(struct super_block *sb, struct dentry *real,
> > > > bool is_upper)
> > > > {
> > > > struct inode *inode, *key = d_inode(real);
> > > >
> > > > inode = ilookup5(sb, (unsigned long) key, ovl_inode_test, key);
> > > > if (!inode)
> > > > return NULL;
> > > >
> > > > if (!ovl_verify_inode(inode, is_upper ? NULL : real,
> > > > is_upper ? real : NULL, false)) {
> > > > iput(inode);
> > > > return ERR_PTR(-ESTALE);
> > > > }
> > > >
> > > > return inode;
> > > > }
> > > >
> > > And that I would consider a coding error.
> > > If a function is able to return an error pointer it should _always_
> > > return an error pointer; here it would be trivial to return -ENXIO
> > > instead of NULL in the first condition.
> > >
> > > Not doing so is just sloppy programming IMO.
> >
> > In this case I agree.
>
> Actually, I don't think so ... we have NULL return all over the inode
> and dentry code. It's a legitimate return for "I couldn't find what
> you asked for" or in the dentry case "I have no current entry". The
> error returns are usually an explicit "there was some problem during
> the lookup".
It's a matter of semantics. From a technical point of view, both NULL or
a particular error code can mean "not found". What has been bothering me
for a long time, and keeps doing so, is the lack of standardization in
the semantics. Even within a subsystem, different semantics can be used,
and that's the source of bugs and overall pain for developers. I'm not
sure if complete standardization at the kernel level is possible, but
any step we can take in that direction would I believe be an
improvement. At the very least, we need a way for developers to easily
figure out what semantics a given function uses. Having to read the
source code, sometimes diving deep in call stacks, to find if a function
can return NULL, is too painful.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2021-07-26 18:31 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-23 19:10 Potential static analysis ideas Dan Carpenter
2021-07-24 13:33 ` Geert Uytterhoeven
2021-07-24 13:40 ` Julia Lawall
2021-07-24 14:08 ` Arnd Bergmann
2021-07-24 23:18 ` Laurent Pinchart
2021-07-24 23:45 ` NeilBrown
2021-07-26 7:25 ` Arnd Bergmann
2021-07-26 7:53 ` Geert Uytterhoeven
2021-07-26 8:20 ` Arnd Bergmann
2021-07-26 8:39 ` Geert Uytterhoeven
2021-07-26 8:52 ` Arnd Bergmann
2021-07-26 9:11 ` Geert Uytterhoeven
2021-07-26 8:55 ` Julia Lawall
2021-07-26 9:08 ` Hannes Reinecke
2021-07-26 9:16 ` Geert Uytterhoeven
2021-07-26 9:28 ` Julia Lawall
2021-07-26 9:35 ` Hannes Reinecke
2021-07-26 10:03 ` Julia Lawall
2021-07-26 17:54 ` James Bottomley
2021-07-26 18:16 ` Linus Torvalds
2021-07-26 21:53 ` NeilBrown
2021-07-26 18:31 ` Laurent Pinchart [this message]
2021-07-26 9:17 ` Dan Carpenter
2021-07-26 9:13 ` Dan Carpenter
2021-07-26 21:43 ` NeilBrown
2021-07-26 7:05 ` Dan Carpenter
2021-07-26 15:50 ` Paul E. McKenney
2021-07-27 9:38 ` Dan Carpenter
2021-07-27 9:50 ` Geert Uytterhoeven
2021-07-27 16:06 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YP7/eyqDcJR3L8V9@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=arnd@arndb.de \
--cc=dan.carpenter@oracle.com \
--cc=geert@linux-m68k.org \
--cc=hare@suse.de \
--cc=julia.lawall@inria.fr \
--cc=ksummit@lists.linux.dev \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).