From: Dan Carpenter <dan.carpenter@oracle.com>
To: "Frank Schäfer" <fschaefer.oss@googlemail.com>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>,
linux-media@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch] [media] em28xx-input: NULL dereference on error
Date: Thu, 25 Sep 2014 17:49:11 +0300 [thread overview]
Message-ID: <20140925144911.GK5865@mwanda> (raw)
In-Reply-To: <542421DF.9060000@googlemail.com>
On Thu, Sep 25, 2014 at 04:08:31PM +0200, Frank Schäfer wrote:
> > ir = kzalloc(sizeof(*ir), GFP_KERNEL);
> > + if (!ir)
> > + return -ENOMEM;
> > rc = rc_allocate_device();
> > - if (!ir || !rc)
> > + if (!rc)
> > goto error;
> >
> > /* record handles to ourself */
> I would prefer to fix it where the actual problem is located.
> Can you send an updated version that changes the code to do
>
> ...
> error:
> if (ir)
> kfree(ir->i2c_client);
> ...
>
> This makes the code less prone to future error handling changes.
This kind of bug is called a "One Err Bug" because they are part of
an anti-pattern of bad error handling where there is only one label. It
was ok at the time it was written but it was fragile and broke when the
code changed.
One Err Bugs are very common kind of bug. I just reported a similar bug
this morning. https://lkml.org/lkml/2014/9/25/91 In that case we freed
some sysfs files which were not allocated.
My view is that error handling code should not have if statements unless
there is an if statement in the allocation code. This is way more
readable.
Another way that people deal with these kinds of errors if they don't
like to return directly is they add an "out:" label.
out:
return ret;
I hate "out" labels for how vague the name is but I also hate do-nothing
gotos generally. When you're reading the code you assume that the goto
does something but the name gives you no clue what it does so you have
to interrupt what you are doing and scroll down to the bottom of the
function and it doesn't do anything. It just returns. By this point
you have forgotten where you were but it was somewhere reading in the
middle of the function.
Terrible terrible terrible. Etc. You have touched a sore spot and
triggered a rant. :P
regards,
dan carpenter
next prev parent reply other threads:[~2014-09-25 14:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-25 11:39 [patch] [media] em28xx-input: NULL dereference on error Dan Carpenter
2014-09-25 14:08 ` Frank Schäfer
2014-09-25 14:49 ` Dan Carpenter [this message]
2014-09-25 17:50 ` Frank Schäfer
2014-09-25 15:37 ` Julia Lawall
2014-09-25 16:28 ` Mauro Carvalho Chehab
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=20140925144911.GK5865@mwanda \
--to=dan.carpenter@oracle.com \
--cc=fschaefer.oss@googlemail.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.chehab@samsung.com \
/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 NNTP newsgroup(s).