All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@osdl.org>, Ingo Molnar <mingo@elte.hu>
Subject: Re: random.c changes for sparse irq_desc are crap
Date: Wed, 31 Dec 2008 17:40:26 -0600	[thread overview]
Message-ID: <1230766826.19620.150.camel@calx> (raw)
In-Reply-To: <495BFB48.8080506@kernel.org>

On Wed, 2008-12-31 at 15:07 -0800, Yinghai Lu wrote:
> Matt Mackall wrote:
> > I just noticed you merged a change that pointlessly converts two
> > random.c functions into ugly random.h inlines without going through the
> > maintainer.
> > 
> > I also don't like the look of the newly-introduced sparse variants of
> > these functions. Failure to find an irq descriptor in
> > get_timer_rand_state is a BUG_ON should-never-happen sort of condition,
> > not something to silently ignore. Letting the code try to dereference
> > NULL is preferred here: we'll actually be able to find and fix the
> > broken driver that's throwing around meaningless irq vectors.
> > 
> > Throwing away the timer_state pointer in the set_timer_rand_state
> > function is similarly bogus in addition to being a memory leak.
> > 
> > Please fix this up.
> > 
> 
> want something like this?

Not quite.

First, please turn these back into normal functions in random.c.
Inlining functions is generally discouraged these days unless you have a
good reason and numbers to back it up.

Second, as I tried to explain above, BUG_ON(!desc) is doing very little
that the subsequent desc->timer_rand_state wouldn't already do
(generating a traceback). In cases where dereferencing NULL should never
happen, it's preferable to not add the extra check and just let the oops
happen. We'll still get a backtrace if anything ever goes wrong, but we
won't have wasted any code space or CPU cycles when it doesn't.

-- 
Mathematics is the supreme nostalgia of our time.


  reply	other threads:[~2008-12-31 23:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-31 18:29 random.c changes for sparse irq_desc are crap Matt Mackall
2008-12-31 23:07 ` Yinghai Lu
2008-12-31 23:40   ` Matt Mackall [this message]
2009-01-01  0:14     ` Yinghai Lu
2009-01-01  9:31       ` Matt Mackall
2009-01-02 15:59         ` Ingo Molnar
2009-01-03  8:06           ` [PATCH] sparseirq: move set/get_timer_rand_state back to .c Yinghai Lu

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=1230766826.19620.150.camel@calx \
    --to=mpm@selenic.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@osdl.org \
    --cc=yinghai@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.