On 8/15/22 07:41, Mel Gorman 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.
Hi Mel, Are you basically saying, "WARN_ON*() seems acceptable in mm/, because we can at least get the problem logged before it locks up, probably"? Or are you implying that we should instead introduce and use some new PANIC_ON() or VM_PANIC_ON() set of macros that would allow proper "log then reboot" behavior? thanks, -- John Hubbard NVIDIA
