linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-fbdev-devel@lists.sourceforge.net,
	Jeff Garzik <jeff@garzik.org>,
	adaplas@gmail.com,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Andi Kleen <ak@suse.de>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [git patches] two warning fixes
Date: Wed, 18 Jul 2007 19:36:30 -0700	[thread overview]
Message-ID: <20070718193630.d57affb0.akpm@linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.0.999.0707181848060.27353@woody.linux-foundation.org>

On Wed, 18 Jul 2007 18:50:28 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:

> So yes, I think we should ignore return values when they have absolutely 
> zero interest level to us.

Look at the reason why the sysfs must_check's were adding in the first
place.

We had a long string of mysterious crashes coming out of the
sysfs/driver/bus/kobject code which appeared to be due to corrupted data
structures and which were believed to be caused by incorrect callers but we
didn't have any idea _which_ callers were incorrect because the crashes
happened long after the error had occurred.

On examination we saw that a very large amount of the driver core was
_internally_ failing to check callee return values and was just proceeding
as if things had succeeded.  Also, many (most) external callers were
failing to check or report upon callee failures as well.

So we were basically left blind without any way to identify where the bugs
were.  We ended up tightening up all of the driver core (largely guided by
the must_check warnings which it emitted) and many callers were fixed as
well.

Now, it could be that we should have (or can now) relax the requirements
upon the callers, but we should still still be told when something has
unexpectedly failed.  Maybe not as a general rule - more of a special-case
for these interfaces because we have such a long history of failures in
there and because of how the lack of error checking caused those failures
to be so hard to fix.

Which is why I proposed new void-returning wrappers which will warn for the
caller when something failed.  If we were to remove the __must_checks then
we'd lose much of our checking ability within the sysfs/driver core, as
well as from callers.

This stuff has got better, and hopefully Tejun's work will make it better
still.  But I don't think it is exactly bulletproof yet.


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

  parent reply	other threads:[~2007-07-19  2:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-18 23:55 [git patches] two warning fixes Jeff Garzik
2007-07-18 23:59 ` Andi Kleen
2007-07-19  0:05   ` Jeff Garzik
2007-07-19  1:19     ` Benjamin Herrenschmidt
2007-07-19  1:41       ` Andrew Morton
2007-07-19  1:50         ` Linus Torvalds
2007-07-19  2:05           ` Benjamin Herrenschmidt
2007-07-19  2:36           ` Andrew Morton [this message]
2007-07-19  1:37 ` Linus Torvalds
2007-07-19  2:32   ` Jeff Garzik
2007-07-19 13:40     ` Krzysztof Halasa
2007-07-19 18:04       ` Linus Torvalds
2007-07-19 18:20         ` Stephen Hemminger
2007-07-20 18:34         ` Krzysztof Halasa
2007-07-21  0:32           ` Benjamin Herrenschmidt
2007-07-22  4:03             ` Jeff Garzik
2007-07-22 21:29               ` Benjamin Herrenschmidt
2007-07-23  3:26         ` Kyle Moffett
2007-07-19 13:38   ` Krzysztof Halasa
2007-07-19 18:00     ` Linus Torvalds
2007-07-20 12:54       ` Tim Tassonis

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=20070718193630.d57affb0.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=adaplas@gmail.com \
    --cc=ak@suse.de \
    --cc=benh@kernel.crashing.org \
    --cc=jeff@garzik.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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).