From: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
To: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org
Subject: Re: [PATCH 4/4] efi: runtime-wrappers: run UEFI Runtime Services with interrupts enabled
Date: Thu, 26 Nov 2015 10:23:45 +0000 [thread overview]
Message-ID: <20151126102345.GD2765@codeblueprint.co.uk> (raw)
In-Reply-To: <1447940191-30705-5-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, 19 Nov, at 02:36:31PM, Ard Biesheuvel wrote:
> The UEFI spec allows Runtime Services to be invoked with interrupts
> enabled. The only reason we were disabling interrupts was to prevent
> recursive calls into the services on the same CPU, which will lead to
> deadlock. However, the only context where such invocations may occur
> legally is from efi-pstore via efivars, and that code has been updated
> to call a non-blocking alternative when invoked from a non-interruptible
> context.
>
> So instead, update the ordinary, blocking UEFI Runtime Services wrappers
> to execute with interrupts enabled.
Please document the justification for this change; why do you *need*
interrupts enabled as opposed to doing it because the spec allows it.
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> drivers/firmware/efi/runtime-wrappers.c | 88 +++++++++++---------
> 1 file changed, 49 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/firmware/efi/runtime-wrappers.c b/drivers/firmware/efi/runtime-wrappers.c
> index a624f7445d11..31e131f09530 100644
> --- a/drivers/firmware/efi/runtime-wrappers.c
> +++ b/drivers/firmware/efi/runtime-wrappers.c
> @@ -71,27 +71,29 @@ __weak DEFINE_SPINLOCK(rtc_lock);
>
> static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
> {
> - unsigned long flags;
> efi_status_t status;
>
> - spin_lock_irqsave(&rtc_lock, flags);
> + BUG_ON(in_irq());
> +
> + spin_lock(&rtc_lock);
> spin_lock(&efi_runtime_lock);
> status = efi_call_virt(get_time, tm, tc);
> spin_unlock(&efi_runtime_lock);
> - spin_unlock_irqrestore(&rtc_lock, flags);
> + spin_unlock(&rtc_lock);
> return status;
> }
This looks wrong. rtc_lock can be grabbed from IRQ context. Maybe now
is the time to rip out rtc_lock? It's __weak for arm64 anyway and x86
doesn't even use these functions. Though I notice that arm also has an
rtc_lock.
> static efi_status_t virt_efi_set_time(efi_time_t *tm)
> {
> - unsigned long flags;
> efi_status_t status;
>
> - spin_lock_irqsave(&rtc_lock, flags);
> + BUG_ON(in_irq());
> +
> + spin_lock(&rtc_lock);
The thing about using BUG_ON() here is that you get no LOCKDEP info if
you trigger it, nor any stack traces from the softlockup detector.
It's much better to leave spin_lock() alone to do its thing.
next prev parent reply other threads:[~2015-11-26 10:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-19 13:36 [PATCH 0/4] efi: run UEFI services with interrupts enabled Ard Biesheuvel
[not found] ` <1447940191-30705-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-11-19 13:36 ` [PATCH 1/4] efi: expose non-blocking set_variable() wrapper to efivars Ard Biesheuvel
[not found] ` <1447940191-30705-2-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-11-26 9:55 ` Matt Fleming
2015-11-19 13:36 ` [PATCH 2/4] efi: efivars: don't rely on blocking operations in non-blocking set_var() Ard Biesheuvel
[not found] ` <1447940191-30705-3-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-11-26 9:54 ` Matt Fleming
[not found] ` <20151126095441.GA2765-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-11-26 12:06 ` Ard Biesheuvel
[not found] ` <CAKv+Gu8XqP+MgT1vkC-CLkEZ=p+X2tA3fQuprUCRJ1UhrFz-rg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-11-27 21:18 ` Matt Fleming
[not found] ` <20151127211836.GB13918-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-11-30 11:12 ` Matt Fleming
2015-11-19 13:36 ` [PATCH 3/4] efi: runtime-wrappers: remove out of date comment regarding in_nmi() Ard Biesheuvel
[not found] ` <1447940191-30705-4-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-11-26 9:58 ` Matt Fleming
2015-11-19 13:36 ` [PATCH 4/4] efi: runtime-wrappers: run UEFI Runtime Services with interrupts enabled Ard Biesheuvel
[not found] ` <1447940191-30705-5-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-11-26 10:23 ` Matt Fleming [this message]
[not found] ` <20151126102345.GD2765-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-11-26 12:09 ` Ard Biesheuvel
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=20151126102345.GD2765@codeblueprint.co.uk \
--to=matt-mf/unelci9gs6ibeejttw/xrex20p6io@public.gmane.org \
--cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.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.