On Wed, 23 May 2018, Linus Torvalds wrote:
On Wed, May 23, 2018 at 11:47 AM Davidlohr Bueso <dave@xxxxxxxxxxxx> wrote:
Note that even if the allocation was guaranteed, there are still param
validations
and rhashtable_init() can return -EINVAL.
So?
It's not going to happen, because you're not going to give garbage
parameters.
Maybe EINVAL could be replaced with WARN_ON(). That would grab the programmer's
attention.
Why would you add a BUG_ON() for something that cannot happen? You might as
well sprinkle them randomly in every damn place.
Not suggesting this. Before I started the thread, I was actually thinking of
ipc using ENOMEM only for rhashtable_init() filure considering the EINVAL case
will never happen.
And even if somebody screws up the parameters because they are being
stupid, then SO WHAT? rhashtable_init() won't initialize the pointers, and
we'll get a NULL pointer dereference.
And hey, we'll probably get it later during boot, once the system is
actually up and running, and that NULL pointer dereference might even get
logged in the system logs now because the machine booted successfully, and
mnaybe it will even get sent to a distro and debugged.
So at what point was there _any_ advantage in doing a BUG_ON() for a crazy
case?
For the record, I'm not arguing in favor of BUG_ON().
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
