On Sun, Aug 21, 2022 at 01:28:58PM +0200, Ingo Molnar wrote: > > * Mel Gorman <mgorman@xxxxxxx> 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@xxxxxxx> -- Mel Gorman SUSE Labs
