From: Greg KH <gregkh@linuxfoundation.org>
To: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Cc: arnd@arndb.de, evgreen@chromium.org, linux-efi@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel@gpiccoli.net,
ardb@kernel.org, davidgow@google.com, jwerner@chromium.org
Subject: Re: [PATCH V3] firmware: google: Test spinlock on panic path to avoid lockups
Date: Thu, 1 Sep 2022 17:52:30 +0200 [thread overview]
Message-ID: <YxDVPqVkdgQbAIvY@kroah.com> (raw)
In-Reply-To: <20220819155059.451674-1-gpiccoli@igalia.com>
On Fri, Aug 19, 2022 at 12:50:59PM -0300, Guilherme G. Piccoli wrote:
> Currently the gsmi driver registers a panic notifier as well as
> reboot and die notifiers. The callbacks registered are called in
> atomic and very limited context - for instance, panic disables
> preemption and local IRQs, also all secondary CPUs (not executing
> the panic path) are shutdown.
>
> With that said, taking a spinlock in this scenario is a dangerous
> invitation for lockup scenarios. So, fix that by checking if the
> spinlock is free to acquire in the panic notifier callback - if not,
> bail-out and avoid a potential hang.
>
> Fixes: 74c5b31c6618 ("driver: Google EFI SMI")
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: David Gow <davidgow@google.com>
> Cc: Julius Werner <jwerner@chromium.org>
> Reviewed-by: Evan Green <evgreen@chromium.org>
> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
> ---
>
>
> This is a re-submission of the patch - it was in a series [0], but
> Greg suggested me to resubmit individually in order it gets picked
> by the relevant maintainers, instead of asking them to merge
> individual patches from a series. Notice I've trimmed a bit the CC
> list, it was bigger due to the patch being in a series...
>
> This is truly the V3 of the patch, below is the diff between versions:
>
> V3:
> - added Evan's review tag - thanks!
>
> V2:
> - do not use spin_trylock anymore, to avoid messing with
> non-panic paths; now we just check the spinlock state in
> the panic notifier before taking it. Thanks Evan for the review!
>
> [0] https://lore.kernel.org/lkml/20220719195325.402745-4-gpiccoli@igalia.com/
>
>
> drivers/firmware/google/gsmi.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c
> index adaa492c3d2d..3ef5f3c0b4e4 100644
> --- a/drivers/firmware/google/gsmi.c
> +++ b/drivers/firmware/google/gsmi.c
> @@ -681,6 +681,14 @@ static struct notifier_block gsmi_die_notifier = {
> static int gsmi_panic_callback(struct notifier_block *nb,
> unsigned long reason, void *arg)
> {
> + /*
> + * Perform the lock check before effectively trying
> + * to acquire it on gsmi_shutdown_reason() to avoid
> + * potential lockups in atomic context.
> + */
> + if (spin_is_locked(&gsmi_dev.lock))
> + return NOTIFY_DONE;
> +
What happens if the lock is grabbed right after testing for it?
Shouldn't you use lockdep_assert_held() instead as the documentation
says to?
> gsmi_shutdown_reason(GSMI_SHUTDOWN_PANIC);
You are grabbing the lock way in this call, again, you have a window
where the check above would not have worked :(
I don't think this is fixing anything properly, sorry.
greg k-h
next prev parent reply other threads:[~2022-09-01 15:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-19 15:50 [PATCH V3] firmware: google: Test spinlock on panic path to avoid lockups Guilherme G. Piccoli
2022-09-01 15:52 ` Greg KH [this message]
2022-09-01 15:59 ` Guilherme G. Piccoli
2022-09-01 16:04 ` Greg KH
2022-09-01 16:24 ` Guilherme G. Piccoli
2022-09-01 16:44 ` Greg KH
2022-09-01 17:46 ` Guilherme G. Piccoli
2022-09-01 18:28 ` Greg KH
2022-09-01 18:46 ` Guilherme G. Piccoli
2022-09-01 18:59 ` Greg KH
2022-09-01 19:02 ` Guilherme G. Piccoli
2022-09-01 22:13 ` Andrew Morton
2022-09-06 17:09 ` Evan Green
2022-09-08 0:35 ` Guilherme G. Piccoli
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=YxDVPqVkdgQbAIvY@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=davidgow@google.com \
--cc=evgreen@chromium.org \
--cc=gpiccoli@igalia.com \
--cc=jwerner@chromium.org \
--cc=kernel@gpiccoli.net \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.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.