public inbox for linux-efi@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox