On Sun, Aug 21, 2022 at 01:28:58PM +0200, Ingo Molnar wrote:
- Mel Gorman mgorman@suse.de wrote:
For the rest, I didn't see obvious recovery paths that would allow the system to run predictably. Any of them firing will have unpredictable consequences (e.g. move_queued_task firing would be fun if it was a per-cpu kthread). Depending on which warning triggers, the remaining life of the system may be very short but maybe long enough to be logged even if system locks up shortly afterwards.
Correct. I'd prefer to keep all these warnings 'simple' - i.e. no attempted recovery & control flow, unless we ever expect these to trigger.
I generally hope we never expect a warning to trigger until of course it does :P
I.e. instead of adding a 'goto' I'd prefer if we removed most of the ones you highlighted. But wanted to keep this first patch simple.
The only one I would push back on is claming cpupri_find_fitness() so it does not access outside the bounds of an array after a warning triggers.
For the rest, I've no strong objection to recovering given the nature of the BUGs you are converting. If any of them *did* trigger, it would be more important to fix the issue than recover the warning. So other than the out-of-bounds array access which I'd like to see clamped just in case;
Acked-by: Mel Gorman mgorman@suse.de