On Wed, Jul 29, 2026 at 09:25:16AM +0200, David Hildenbrand (Arm) wrote: > On 7/29/26 00:07, Breno Leitao wrote: > > I have a draft of the selftest in C already and I will give it more bake > > time, and I will submit it until EOW. > > IMHO there is no need to rush this test here, we could merge it after the > main work. > > We neglected our selftests quite a bit in the past, and that is biting us now. > > That's why I push back hard now (sorry) against stuff that is different than > the > rest and not easy to maintain. > > I know, hwpoison-panic is a destructive test, but I really don't think we > should > just merge mostly unreviewed bash tests that will just bitrot. > > Which makes me wonder now: should this actually be a selftest? It's nothing > one > would just want to run in a CI. It will crash your machine. > > Maybe this should just be a tool in tools/mm? I really think so. So having a > nice C-level hwpoison-panic.c in tools/mm might be the way to go.
Agreed. In v6 [0] I actually removed the selftest entirely, since the value wasn't clear and it seemed like an ugly duckling. It seems tools/mm would be a good fit, and make a better home for this type of "test". Given more changes coming in memory failure (at least from my side [1][2]), I think it would be a good idea to create a subdirectory (tools/mm/memory-failure) and keep these semi-destructive tools in there. Is this the right direction? > So let's rather make this test well maintainable and have it properly reviewed > than rushing something suboptimal. Sounds good. I'll move this to tools/mm and resubmit. Given Andrew has removed the selftest from mm-unstable while keeping the rest of the series (which is fully reviewed and frictionless), so I'll focus on the test tool now and send it separately. Thanks for the discussion, --breno Link: https://lore.kernel.org/all/[email protected]/ [0] Link: https://lore.kernel.org/all/[email protected]/ [1] Link: https://lore.kernel.org/all/[email protected]/ [2]
