[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1412165200-32141-1-git-send-email-matt@console-pimps.org>
Date: Wed, 1 Oct 2014 13:06:38 +0100
From: Matt Fleming <matt@...sole-pimps.org>
To: Ingo Molnar <mingo@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>
Cc: linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Leif Lindholm <leif.lindholm@...aro.org>,
Matthew Garrett <mjg59@...f.ucam.org>,
Matt Fleming <matt.fleming@...el.com>
Subject: [PATCH 0/2] efi: Remove conditional in_nmi() runtime locking
From: Matt Fleming <matt.fleming@...el.com>
These two patches should address the concerns raised by Ingo and Peter
in relation to the EFI pull request containing v3.18 material,
https://lkml.kernel.org/r/20140928202702.GB18635@console-pimps.org
We can drop the in_nmi() checks altogether and just provide normal
locking semantics if we introduce a non-blocking SetVariable() operation
for the particular case of writing pstore data to the EFI backend from
the kdump callback, which aborts in the contended case.
This is currently holding up merging of the v3.18 EFI patches, so please
be timely with comments, if any.
@Linaro guys, I don't think you'll actually care all that much about
these changes since the in_nmi() goo was for x86's benefit, but I'm
Cc'ing you anyway to make sure everything looks OK.
Matt Fleming (2):
efi: Provide a non-blocking SetVariable() operation
efi: Delete the in_nmi() conditional runtime locking
arch/x86/include/asm/efi.h | 2 --
drivers/firmware/efi/runtime-wrappers.c | 36 ++++++++++++++++---------
drivers/firmware/efi/vars.c | 47 +++++++++++++++++++++++++++++++++
include/linux/efi.h | 6 +++++
4 files changed, 76 insertions(+), 15 deletions(-)
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists