Re: semantics of rhashtable and sysvipc
From: Davidlohr Bueso <dave@stgolabs.net>
Date: 2018-05-23 19:08:41
Also in:
lkml
On Wed, 23 May 2018, Linus Torvalds wrote:
On Wed, May 23, 2018 at 11:47 AM Davidlohr Bueso [off-list ref] wrote:quoted
Note that even if the allocation was guaranteed, there are still paramvalidationsquoted
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().