linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: benh@kernel.crashing.org
Cc: David Miller <davem@davemloft.net>,
	tony@bakeyournoodle.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Silence 'ignoring return value' warnings in drivers/video/aty/radeon_base.c
Date: Tue, 6 May 2008 18:20:06 -0700	[thread overview]
Message-ID: <20080506182006.4b4a3968.akpm@linux-foundation.org> (raw)
In-Reply-To: <1210121683.21644.194.camel@pasglop>

On Wed, 07 May 2008 10:54:43 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> 
> On Tue, 2008-05-06 at 14:43 -0700, David Miller wrote:
> > > So I rewrote the title to "drivers/video/aty/radeon_base.c: notify
> > user if
> > > sysfs_create_bin_file() failed".
> > > 
> > > And your fix looks appropriate - if sysfs_create_bin_file() fails we
> > will now get
> > > reports of this and we can find out what kernel bug caused this to
> > happen.
> > 
> > The last time someone "fixed" this warning in the radeon driver,
> > people lost their consoles.
> > 
> > Just giving a heads up...
> 
> I asked Tony to only warn. I still don't like it tho. As I (and paulus)
> have explained several times in the past, but I'm not going to veto the
> patch because I'm tired of that argument.
>  
> We have something like 99% of users of sysfs_create_file not supposed to
> fail right ?
> 
> So what we are effectively doing is adding -hundreds- of printk's all
> over the place (bloat bloat bloat) while instead we could have warned
> inside sysfs_create_file itself, and provided a __sysfs_create_file or
> sysfs_create_file_nowarn, or whatever you want to call it for the
> handful of users that actually want to explicitely deal with failures.
> 
> And it's the same for a whole bunch of those must check things. We are
> just adding bloat often for nothing useful.

You said "not useful".  But you're just wrong.

Look at the history of this.  A couple of years ago we were seeing a huge
number of mysterious crashes and warnings in and around sysfs and driver
code and we just didn't have a clue what was causing it, because those
crashes were happening long, long after the buggy code had done its work.

So I went in there and found a tremendous amount of code in driver core,
sysfs and in callers of both which was just ignoring error returns and
blundering on.

It was a comnplete undebuggable unmaintainable mess.  And the reason why it
was undebuggable was because the code was failing to detect errors *when
they occurred*.  So we (me, Cornelia, Greg, others) set about fixing all of
that.  And to support that effort we marked all the things which should be
checked with __must_check.

Now you come along and cherrypick a few callsites where you'd rather not
bother checking and assert that the entire effort was wrong-headed.  Well
sorry, no, it wasn't.  Sure, there's a little bit of undesirable fallout
but the whole thing had.  to.  be.  done.

> In some case, even harmful
> as we prevent entire modules from initializing due to what is often just
> a minor failure.

There is no such thing as a "minor failure".  Code either works as
designed or it doesn't.  If it doesn't work as designed then we cannot
state how serious the problem is until we've understood its causes.

If you have sysfs files which aren't needed then remove the damn things. 
If they _are_ needed then they should be available to all users of the
driver.

  reply	other threads:[~2008-05-07  1:21 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-24  4:34 [PATCH] Silence 'ignoring return value' warnings in drivers/video/aty/radeon_base.c Tony Breeds
2008-05-06 21:39 ` Andrew Morton
2008-05-06 21:43   ` David Miller
2008-05-06 21:56     ` Andrew Morton
2008-05-07  4:00       ` Arjan van de Ven
2008-05-07  4:12         ` Andrew Morton
2008-05-07  4:15           ` Arjan van de Ven
2008-05-07  4:20             ` Arjan van de Ven
2008-05-07  4:37               ` Benjamin Herrenschmidt
2008-05-07  4:23             ` Andrew Morton
2008-05-07  4:26               ` Andrew Morton
2008-05-07  4:41                 ` Arjan van de Ven
2008-05-07  4:37               ` Arjan van de Ven
2008-05-07  5:40           ` Paul Mackerras
2008-05-07  5:49             ` Benjamin Herrenschmidt
2008-05-07  0:54     ` Benjamin Herrenschmidt
2008-05-07  1:20       ` Andrew Morton [this message]
2008-05-07  4:33         ` Benjamin Herrenschmidt
2008-05-07  8:23           ` Cornelia Huck
2008-05-07 21:43             ` Benjamin Herrenschmidt
2008-05-08  7:34               ` Cornelia Huck
2008-05-08  7:49                 ` Benjamin Herrenschmidt
2008-05-08  8:36                   ` Cornelia Huck
2008-05-08 22:03                     ` Greg KH
2008-05-08 23:06                       ` Benjamin Herrenschmidt
2008-05-08 23:50                       ` Paul Mackerras
2008-05-09  0:02                         ` Harvey Harrison
2008-05-09  5:32                           ` Cornelia Huck
2008-05-09  5:33                           ` Cornelia Huck

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=20080506182006.4b4a3968.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony@bakeyournoodle.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).