Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
From:   Kees Cook <keescook@chromium.org>
To:     linux-kernel@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>
Cc:     Kees Cook <keescook@chromium.org>, dianders@chromium.org,
        sumit.garg@linaro.org, swboyd@chromium.org
Subject: Re: [PATCH v2] lkdtm/bugs: add test for panic() with stuck secondary CPUs
Date:   Fri, 22 Sep 2023 20:54:18 -0700
Message-Id: <169544125511.3844201.2326680356367331620.b4-ty@chromium.org>
In-Reply-To: <20230921161634.4063233-1-mark.rutland@arm.com>
References: <20230921161634.4063233-1-mark.rutland@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Thu, 21 Sep 2023 17:16:34 +0100, Mark Rutland wrote:
> Upon a panic() the kernel will use either smp_send_stop() or
> crash_smp_send_stop() to attempt to stop secondary CPUs via an IPI,
> which may or may not be an NMI. Generally it's preferable that this is an
> NMI so that CPUs can be stopped in as many situations as possible, but
> it's not always possible to provide an NMI, and there are cases where
> CPUs may be unable to handle the NMI regardless.
> 
> [...]

I added a line to tests.tst and applied this to for-next/hardening, thanks!

[1/1] lkdtm/bugs: add test for panic() with stuck secondary CPUs
      https://git.kernel.org/kees/c/5fb07db970cf

Take care,

-- 
Kees Cook