Thread (12 messages) 12 messages, 4 authors, 2022-12-08

Re: [PATCH v3 5/5] lib/cpumask: reorganize cpumask_local_spread() logic

From: Peter Lafreniere <hidden>
Date: 2022-12-08 20:58:09
Also in: linux-crypto, linux-rdma, lkml

On Thu, Dec 08, 2022 at 08:17:22PM +0000, Peter Lafreniere wrote:
quoted
quoted
Now after moving all NUMA logic into sched_numa_find_nth_cpu(),
else-branch of cpumask_local_spread() is just a function call, and
we can simplify logic by using ternary operator.

While here, replace BUG() with WARN().
Why make this change? It's still as bad to hit the WARN_ON as it was before.
For example, because of this:

 > Greg, please don't do this
 >
 > > ChangeSet@1.614, 2002-09-05 08:33:20-07:00, greg@kroah.com
 > >   USB: storage driver: replace show_trace() with BUG()
 >
 > that BUG() thing is _way_ out of line, and has killed a few of my machines
 > several times for no good reason. It actively hurts debuggability, because
 > the machine is totally dead after it, and the whole and ONLY point of
 > BUG() messages is to help debugging and make it clear that we can't handle
 > something.
 >
 > In this case, we _can_ handle it, and we're much better off with a machine
 > that works and that you can look up the messages with than killing it.
 >
 > Rule of thumb: BUG() is only good for something that never happens and
 > that we really have no other option for (ie state is so corrupt that
 > continuing is deadly).
 >
 >            Linus
Fair enough. It's not like it'll be hit anyway. My concern was for if
any of the 23 callers get an invalid result. I guess that if that causes
a crash, then so be it. We have the warning to track down the cause.

Thanks for the explanation,
Peter Lafreniere [off-list ref]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help