From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
To: Greg KH <gregkh@linuxfoundation.org>, evgreen@chromium.org
Cc: arnd@arndb.de, linux-efi@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel@gpiccoli.net,
ardb@kernel.org, davidgow@google.com, jwerner@chromium.org,
Petr Mladek <pmladek@suse.com>
Subject: Re: [PATCH V3] firmware: google: Test spinlock on panic path to avoid lockups
Date: Thu, 1 Sep 2022 12:59:36 -0300 [thread overview]
Message-ID: <f89cd87c-7d1c-d8e6-ed95-6876f0201872@igalia.com> (raw)
In-Reply-To: <YxDVPqVkdgQbAIvY@kroah.com>
+ Petr, since this was extensively discussed in the original thread [0]
and maybe he can help with the argument.
[0]
https://lore.kernel.org/lkml/20220427224924.592546-1-gpiccoli@igalia.com/
On 01/09/2022 12:52, Greg KH wrote:
> [...]
>> + * 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?
How, if in this point only a single CPU (this one, executing the code)
is running?
Remember this is the panic path - before this point we disabled all
other CPUs, except this one executing the code. So, either the lock was
taken (and we bail), or it wasn't and it's safe to continue.
next prev parent reply other threads:[~2022-09-01 16:00 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
2022-09-01 15:59 ` Guilherme G. Piccoli [this message]
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=f89cd87c-7d1c-d8e6-ed95-6876f0201872@igalia.com \
--to=gpiccoli@igalia.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=davidgow@google.com \
--cc=evgreen@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=jwerner@chromium.org \
--cc=kernel@gpiccoli.net \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox