Re: semantics of rhashtable and sysvipc

[Davidlohr Bueso]

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().