On 3/9/21 7:14 PM, Georgi Djakov wrote: > Hi Vlastimil, > > Thanks for the comment! > > On 3/9/21 17:09, Vlastimil Babka wrote: >> On 3/9/21 2:47 PM, Georgi Djakov wrote: >>> Being able to stop the system immediately when a memory corruption >>> is detected is crucial to finding the source of it. This is very >>> useful when the memory can be inspected with kdump or other tools. >> >> Is this in some testing scenarios where you would also use e.g. panic_on_warn? >> We could hook to that. If not, we could introduce a new >> panic_on_memory_corruption that would apply also for debug_pagealloc and whatnot? > > I would prefer that we not tie it with panic_on_warn - there might be lots of > new code in multiple subsystems, so hitting some WARNing while testing is not > something unexpected. > > Introducing an additional panic_on_memory_corruption would work, but i noticed > that we already have slub_debug and thought to re-use that. But indeed, аdding > an option to panic in for example bad_page() sounds also useful, if that's what > you suggest. Yes, that would be another example. Also CCing Kees for input, as besides the "kdump ASAP for debugging" case, I can imagine security hardening folks could be interested in the "somebody might have just failed to pwn the kernel, better panic than let them continue" angle. But I'm naive wrt security, so it might be a stupid idea :) Vlastimil > Thanks, > Georgi
