On 9/9/21 1:56 AM, David Hildenbrand wrote:
On 09.09.21 00:42, John Hubbard wrote:
On 9/7/21 2:56 AM, David Hildenbrand wrote:
...
If this can be handled gracefully, then I'd rather go with VM_WARN_ON.
Maybe even WARN_ON_ONCE?
I think either VM_BUG_ON() or VM_WARN_ON() -- compiling the runtime checks out -- should be good
enough.
I'd just go with VM_BUG_ON(), because anybody messing with __isolate_free_page() should clearly spot
that we expect the current handling. But no strong opinion.
If in doubt, WARN*() should be preferred over BUG*(). There's a pretty long
history of "don't kill the machine unless you have to" emails about this, let
me dig up one...OK, maybe not the best example, but the tip of the iceberg:
Please note the subtle difference between BUG_ON and VM_BUG_ON. We expect VM_BUG_ON to be compiled
out on any production system. So it's really only a mean to identify things that really shouldn't be
like that during debugging/testing.
Yes, but the end result is the same: it halts the system. It don't think it changes
the reasoning about BUG vs WARN very much.
Using WARN... instead of VM_BUG_ON is even worse for production systems. There are distros that set
panic_on_warn, essentially converting WARN... into BUG...
This is different than BUG: panic() *prints a backtrace*, and then reboots the system.
That is still awkward, but a little more debuggable.
thanks,
--
John Hubbard
NVIDIA
