public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <rpurdie@rpsys.net>
To: Russell King <rmk@arm.linux.org.uk>
Cc: Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: LED stuff - why bother with error handling
Date: Mon, 07 May 2007 11:00:45 +0100	[thread overview]
Message-ID: <1178532046.5864.14.camel@localhost.localdomain> (raw)
In-Reply-To: <20070506142329.GA21158@flint.arm.linux.org.uk>

On Sun, 2007-05-06 at 15:23 +0100, Russell King wrote:
> While reviewing 4359/2, I found the following issue.  Let's remove all
> the irrelevant lines of code to illustrate the problem.
> 
> void led_trigger_register_simple(const char *name, struct led_trigger **tp)
> {
>         struct led_trigger *trigger;
> 
>         trigger = kzalloc(sizeof(struct led_trigger), GFP_KERNEL);
> ...
>         *tp = trigger;
> }
> 
> void led_trigger_unregister(struct led_trigger *trigger)
> {
>         list_del(&trigger->next_trig);
> }
> 
> The thing to note is that led_trigger_register_simple() can fail but it's
> a void function.  There's a very good school of thought which says that
> functions which can fail should never have a return type of void.

The simple triggers are often tagged onto other subsystems and were
designed to be minimally invasive. Since they were ancillary, it was
left that they didn't return error codes. Taking the IDE trigger as an
example, the failure of the trigger should not cause the IDE subsystem
to fail, if should just skip over the LED registration. The alternative
is every simple trigger site has an error check and a printk which
seemed a bit pointless.

Note that you can still check whether it succeeded by looking at the
trigger pointer if you really need to - I've never seen a use case that
did though.

Moving to the problem you raised, I thought all the code paths a simple
trigger could end up on checked for NULL and/or were NULL safe. The
led_trigger_unregister_simple function has a missing NULL check which
I'll fix.

> If we want people to detect errors then we must *not* return values by
> reference.  It stops people thinking about "what if this returns a non-
> zero error value" or "what if it returns NULL?".  Adding __must_check
> gives extra persuasion to check the return value.
> 
> Can the LED trigger API be fixed please?

I agree the failure shouldn't be silent as it currently is and therefore
led_trigger_register_simple() should have some warning printks added so
the user can tell if it failed to register. I think they belong in the
core rather than at every call site though for the reasons I mention
above.

Regards,

Richard



      reply	other threads:[~2007-05-07 10:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-06 14:23 LED stuff - why bother with error handling Russell King
2007-05-07 10:00 ` Richard Purdie [this message]

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=1178532046.5864.14.camel@localhost.localdomain \
    --to=rpurdie@rpsys.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    /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