Hi Dietmar!

On 15-Aug 12:59, Dietmar Eggemann wrote:

On 08/15/2018 12:54 PM, Patrick Bellasi wrote:

quoted

On 15-Aug 11:37, Dietmar Eggemann wrote:

quoted

On 08/14/2018 06:49 PM, Patrick Bellasi wrote:

[...]

quoted

quoted

If this is only for testing/debugging, I would suggest a simple one line
BUG_ON()

These are (eventually) considered as recoverable errors... thus,
AFAIK, using BUG_ON is overkilling and discouraged:
  https://elixir.bootlin.com/linux/latest/source/include/asm-generic/bug.h#L42

Not sure about that. If this refcounting is out of sync, that's indicating a
serious issue here for me which should be fixed.

Well, refconting seems quite ok to me, we always inc/dec under RQ
locking and it's a per-CPU variable.

The warning is there to report issues on further testing as well as to
be safe with respect to possible future modifications of the code.

quoted

quoted

You find CONFIG_SCHED_DEBUG=y in production kernels as well.

AFAIK, that setting is discouraged for production kernels...
Moreover, it's still better to WARN sometimes on a production kernel
the crash the device, isnt't it?

IMHO, if this is something which should not happen at all, a BUG_ON() is the
right thing to do here.

I don't agree on that. I agree it should not happen but since it's a
recoverable error it think we should not panic.

There are really few BUG_ON() in core.c and they are all for much more
serious issues than a (eventually) broken refcount.

IMHO instead an (unlikely) inconsistent refcont for an "optional
optimization" on "frequency selection" is not such a critical
failure worth a device crash.

And you get the call stack to investigate why it hit.

We can always add a stack dump if we notice the warning.

But, since we do not agree on that point, I would say we should better
wait for what the maintainers prefers.

Best,
Patrick

-- 
#include <best/regards.h>

Patrick Bellasi