[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aa491cf5-ace4-1e2c-2f49-60f96b1e6da9@huawei.com>
Date: Mon, 26 Feb 2018 21:26:58 +0200
From: Igor Stoppa <igor.stoppa@...wei.com>
To: Matthew Wilcox <willy@...radead.org>
CC: J Freyensee <why2jjj.linux@...il.com>, <david@...morbit.com>,
<keescook@...omium.org>, <mhocko@...nel.org>, <labbott@...hat.com>,
<linux-security-module@...r.kernel.org>, <linux-mm@...ck.org>,
<linux-kernel@...r.kernel.org>, <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH 2/7] genalloc: selftest
On 26/02/18 21:12, Matthew Wilcox wrote:
[...]
> panic() halts the kernel
> BUG_ON() kills the thread
> WARN_ON() just prints messages
>
> Now, if we're at boot time and we're still executing code from the init
> thread, killing init is equivalent to halting the kernel.
>
> The question is, what is appropriate for test modules? I would say
> WARN_ON is not appropriate because people ignore warnings. BUG_ON is
> reasonable for development. panic() is probably not.
Ok, so I can leave WARN_ON() in the libraries, and keep the more
restrictive BUG_ON() for the self test, which is optional for both
genalloc and pmalloc.
> Also, calling BUG_ON while holding a lock is not a good idea; if anything
> needs to acquire that lock to shut down in a reasonable fashion, it's
> going to hang.
>
> And there's no need to do something like BUG_ON(!foo); foo->wibble = 1;
> Dereferencing a NULL pointer already produces a nice informative splat.
> In general, we assume other parts of the kernel are sane and if they pass
> us a NULL pool, it's no good returning -EINVAL, we may as well just oops
> and let somebody else debug it.
Great, that makes the code even simpler.
--
igor
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
