All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Kees Cook <keescook@chromium.org>
Cc: linux-kernel@vger.kernel.org, paulmck@kernel.org
Subject: Re: [PATCH] lkdtm/bugs: add test for hung smp_call_function_single()
Date: Tue, 23 Apr 2024 10:47:29 +0100	[thread overview]
Message-ID: <ZieDsZclwUpzcaeI@FVFF77S0Q05N> (raw)
In-Reply-To: <202404191434.5B051B5DC6@keescook>

On Fri, Apr 19, 2024 at 02:53:59PM -0700, Kees Cook wrote:
> On Fri, Apr 19, 2024 at 11:34:52AM +0100, Mark Rutland wrote:
> > The CONFIG_CSD_LOCK_WAIT_DEBUG option enables debugging of hung
> > smp_call_function*() calls (e.g. when the target CPU gets stuck within
> > the callback function). Testing this option requires triggering such
> > hangs.
> > 
> > This patch adds an lkdtm test with a hung smp_call_function_single()
> > callbac, which can be used to test CONFIG_CSD_LOCK_WAIT_DEBUG and NMI
> > backtraces (as CONFIG_CSD_LOCK_WAIT_DEBUG will attempt an NMI backtrace
> > of the hung target CPU).

[...]

> > I wrote this because I needed to guide someone through debugging a hung
> > smp_call_function() call, and I needed examples with/without an NMI
> > backtrace. It seems like it'd be useful for testing the CSD lockup
> > detector and NMI backtrace code in future.
> 
> Like the other lockup detector, I suspect we should skip it by default
> in the selftests? Something like this:
> 
> diff --git a/tools/testing/selftests/lkdtm/tests.txt b/tools/testing/selftests/lkdtm/tests.txt
> index 368973f05250..32baddc2c85d 100644
> --- a/tools/testing/selftests/lkdtm/tests.txt
> +++ b/tools/testing/selftests/lkdtm/tests.txt
> @@ -31,6 +31,7 @@ SLAB_FREE_CROSS
>  SLAB_FREE_PAGE
>  #SOFTLOCKUP Hangs the system
>  #HARDLOCKUP Hangs the system
> +#CSDLOCKUP Hangs the system
>  #SPINLOCKUP Hangs the system
>  #HUNG_TASK Hangs the system
>  EXEC_DATA

Ah, I wasn't ware of that file, yes.

> > I'm not sure about the CSDLOCKUP name, but everything else I tried
> > didn't seem great either:
> > 
> > * IPILOCKUP sounds like it's testing IPIs generally
> > * SMPCALLLOCKUP and similar look weirdly long
> > * SMP_CALL_LOCKUP and similar look different to {HARD,SOFT,SPIN}LOCKUP
> > 
> > ... and I'm happy to defer to Kees for the naming. ;)
> 
> It looks like it's only useful with CSD lockup detector? If that's true,
> sure, this name is fine.

I think it's also useful for testing other things (e.g. RCU stall detection),
so how about we go with SMP_CALL_LOCKUP, as that says what the test does rather
than what specifically it can be used to test?

Mark.

  reply	other threads:[~2024-04-23  9:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-19 10:34 [PATCH] lkdtm/bugs: add test for hung smp_call_function_single() Mark Rutland
2024-04-19 21:53 ` Kees Cook
2024-04-23  9:47   ` Mark Rutland [this message]
2024-04-23 17:21     ` Kees Cook
2024-04-24  2:10 ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZieDsZclwUpzcaeI@FVFF77S0Q05N \
    --to=mark.rutland@arm.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.