From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2473C3E0090 for ; Mon, 3 Aug 2026 11:06:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785755212; cv=none; b=UyC2YVEONYLV/naNPFAi/7A7SCTq36NoCdaSkSbDks7nmdA5dDftBIJgeewtzNXFqGyQVRoAwHid7bw1YL1gDUmw8Oef1c2jIC0PCzIHnfCWikltmdP6QBpJzVU+1RSQx9qIRe79sEE0GX9+s7a1I7V2+gP/zEo7f5dFfOSDIQE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785755212; c=relaxed/simple; bh=tTPjiw6VhxC3Qdy5ZIjm5FJ7m4V0oG4rHEUs3ufyfA4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eiLuzumKf9NECHT21U7EfmBvi06/nHkx38yfRbeWJG+l/inBnVRe1YL/dba049uqmNN3i/fyOhrpnaANeEh6i8iZtijmHLaSiIsW/OSY+rZoVPZnoWN+JYNXJAe745WqzjT9wE2sKDpdWyFyiilxU3Gn5GWNAPsyxwyFCjOoNxw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=vOthG177; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="vOthG177" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=81qwzNTYWMH57csnsJHDHsY+d3QIwovJXwJEW52W2EY=; b=vOthG177CP1M/oT1M6SJZjIpzy g0Y6kG7i9eIzJVHzoV+I/pdo9uGUQiMTu3YTCAFDea1lbOUkBQrzfcKWEfQdex5mH0BuKqlcwG9X3 2KhPAvcAkFcZWpu5iQXaOa5dC2J+VbwxWtKUHYtNJN2OjUSdsH+x7RmsYwbveHj/TGJXXBaAzJX7i mDIoIJsde1UJmtLbG/OU7Uuez512H3sE44q8JC72i75AzEe0iNLui9lkP73ahxJIi9Cp3GDiuih8a pEgVO8L6hzGDR9qYafwlxXPL7iuVermx7D4nCTJVqujOvJgwO5OWmsl0Mg0/oU5So1WXMqfpcHu6c +8IKoh6Q==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1wqqV7-00CJcO-15; Mon, 03 Aug 2026 11:06:33 +0000 Date: Mon, 3 Aug 2026 04:06:28 -0700 From: Breno Leitao To: SJ Park Cc: Andrew Morton , Miaohe Lin , Naoya Horiguchi , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , david@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, kernel-team@meta.com Subject: Re: [PATCH] tools/mm: add hwpoison-panic tool Message-ID: References: <20260731-memory_failure_rewrite_test-v1-1-6aa8c6435693@debian.org> <20260801005822.85110-1-sj@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260801005822.85110-1-sj@kernel.org> X-Debian-User: leitao On Fri, Jul 31, 2026 at 05:58:22PM -0700, SJ Park wrote: > > This lives in tools/mm rather than selftests/mm because every successful > > run crashes the machine, which is not something to run from CI. > > If the purpose of the new program is testing, would it make more sense to put > it under tools/testing/ ? Sorry, this was discussed here: https://lore.kernel.org/all/f83d5b26-b369-489b-a305-1eb5ec6fccfb@kernel.org/ > Also, does this test really need to be end-to-end test that cause panic? How > about doing unit test of core functions, using tools like kunit? Or, > live-patching panic() to only print messages and return before running the > test? What I want covered is the wiring, not the individual functions: get_any_page() classifying a kernel-owned page as -ENOTRECOVERABLE, action_result() reaching panic_on_unrecoverable_mf(), and the box actually going down. Under kunit I would have to fabricate the page and stub panic(), so the parts that break would be the parts replaced by the harness. Unit tests for the classification helpers would be worth having on their own. They would not replace this one. > > BUILD_TARGETS=page-types slabinfo page_owner_sort page_owner_filter thp_swap_allocator_test > > +BUILD_TARGETS+=memory-failure/hwpoison-panic > > I was initially thought why not underscore but dash on the name? But, I > realize it is obviously too persoanl taste. Dash matches page-types.c in the same directory, I am happy using userscore if that is the rigth approach. > > > > diff --git a/tools/mm/memory-failure/hwpoison-panic.c b/tools/mm/memory-failure/hwpoison-panic.c > > new file mode 100644 > > index 0000000000000..b8076d86da15b > > --- /dev/null > > +++ b/tools/mm/memory-failure/hwpoison-panic.c > > @@ -0,0 +1,353 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * hwpoison-panic: verify vm.panic_on_unrecoverable_memory_failure by > > + * injecting a hwpoison error on a kernel-owned page and confirming the > > + * kernel panics. > > While reading the above explanation, I was expecting this program will directly > say me if the kernel panic-ed or not. But this only says if it was not > panic-ed iiuc? How about saying, like, "Trigger intentional kernel panic by > ..." ? You read it correctly, the program can only ever report the absence of a panic. I will reword the header along your suggestion for v2. > > + kind = parse_args(argc, argv, &force); > > + page_size = getpagesize(); > > + check_prereqs(force); > > Maybe check_prereqs() can be called before getpagesize()? Yes, nothing in check_prereqs() needs page_size. Moving it up in v2. Thanks for the review, --breno