[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPa8GCD2m9R8YWY2FhO=LOMvCHhC6T=iFdn2YmpLxjO96_B4Ew@mail.gmail.com>
Date: Wed, 2 May 2012 09:18:58 +1000
From: Nick Piggin <npiggin@...il.com>
To: David Rientjes <rientjes@...gle.com>
Cc: Minchan Kim <minchan@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, kamezawa.hiroyu@...fujitsu.com,
kosaki.motohiro@...il.com, Neil Brown <neilb@...e.de>,
Artem Bityutskiy <dedekind1@...il.com>,
David Woodhouse <dwmw2@...radead.org>,
"Theodore Ts'o" <tytso@....edu>,
Adrian Hunter <adrian.hunter@...el.com>,
Steven Whitehouse <swhiteho@...hat.com>,
"David S. Miller" <davem@...emloft.net>,
James Morris <jmorris@...ei.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Sage Weil <sage@...dream.net>
Subject: Re: [RFC] vmalloc: add warning in __vmalloc
On 2 May 2012 06:22, David Rientjes <rientjes@...gle.com> wrote:
> On Tue, 1 May 2012, Nick Piggin wrote:
>
>> > I disagree with this approach since it's going to violently spam an
>> > innocent kernel user's log with no ratelimiting and for a situation that
>> > actually may not be problematic.
>>
>> With WARN_ON_ONCE, it should be good.
>>
>
> To catch a single instance of this per-boot, sure. I've never seen us add
> WARN_ON_ONCE()'s where we have concrete examples of kernel code that will
> trigger it, though. Not sure why spamming the kernel log and getting
> users to think something is wrong and report the bug when it's possible to
> audit the code and make a report to the subsystem maintainer.
Because it needs to be an ongoing thing, which is caught as soon as the
developer writes some code, rather than continually audited for and fixed
up after the fact. There is not a good way to enforce this at compile time.
The existing callers do need to be fixed too, of course.
--
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