[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100324211924.GH10659@random.random>
Date: Wed, 24 Mar 2010 22:19:24 +0100
From: Andrea Arcangeli <aarcange@...hat.com>
To: Jonathan Corbet <corbet@....net>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mel@....ul.ie>,
Christoph Lameter <cl@...ux-foundation.org>,
Adam Litke <agl@...ibm.com>, Avi Kivity <avi@...hat.com>,
David Rientjes <rientjes@...gle.com>,
Minchan Kim <minchan.kim@...il.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH 07/11] Memory compaction core
Hi Jonathan,
On Wed, Mar 24, 2010 at 02:59:46PM -0600, Jonathan Corbet wrote:
> On Wed, 24 Mar 2010 13:33:47 -0700
> Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> > > + VM_BUG_ON(cc == NULL);
> >
> > It's a bit strange to test this when we're about to oops anyway. The
> > oops will tell us the same thing.
>
> ...except that we've seen a fair number of null pointer dereference
> exploits that have told us something altogether different. Are we
> *sure* we don't want to test for null pointers...?
Examples? Maybe WARN_ON != oops, but VM_BUG_ON still an oops that is
and without serial console it would go lost too. I personally don't
see how it's needed. Plus those things are mostly for debug to check
for invariant condition, how long it takes to sort it out isn't very
relevant. So I'm on Andrew camp ;).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists