On Thu, 2018-11-08 at 19:05 +0100, Ard Biesheuvel wrote:
> Currently, efi_mem_reserve_persistent() may not be called from atomic
> context, since both the kmalloc() call and the memremap() call may
> sleep.
>
> The kmalloc() call is easy enough to fix, but the memremap() call
> needs to be moved
On Tue, Nov 6, 2018 at 6:16 AM Ard Biesheuvel wrote:
>
> On 6 November 2018 at 14:15, Sedat Dilek wrote:
> >
> > Thanks Ard.
> > This means efi-for-4.21 / efi-for-5.0?
> >
>
> Yes
Thanks for picking up this patch, Ard. Is there any way to get it into 4.20?
--
Thanks,
~Nick Desaulniers
On 8 November 2018 at 20:13, Bhupesh Sharma wrote:
> Hi Ard,
>
> On Wed, Nov 7, 2018 at 7:46 PM Ard Biesheuvel
> wrote:
>>
>> This series addresses the kexec/kdump crash on arm64 system with many CPUs
>> that was reported by Bhupesh.
>>
>> Patch #1 fixes the actual crash, but may result in
And +Cc: Catalin
On Fri, Nov 9, 2018 at 12:43 AM Bhupesh Sharma wrote:
>
> Hi Ard,
>
> On Wed, Nov 7, 2018 at 7:46 PM Ard Biesheuvel
> wrote:
> >
> > This series addresses the kexec/kdump crash on arm64 system with many CPUs
> > that was reported by Bhupesh.
> >
> > Patch #1 fixes the actual
Hi Ard,
On Wed, Nov 7, 2018 at 7:46 PM Ard Biesheuvel wrote:
>
> This series addresses the kexec/kdump crash on arm64 system with many CPUs
> that was reported by Bhupesh.
>
> Patch #1 fixes the actual crash, but may result in memblock_reserve() to
> fail. This is fixed in patch #4, where the
A couple of fixes for ef/arm issues that were introduced before the
merge window.
Ard Biesheuvel (2):
efi: arm: revert deferred unmap of early memmap mapping
efi/arm: libstub: pack FDT after populating it
drivers/firmware/efi/arm-init.c| 4
drivers/firmware/efi/arm-runtime.c | 2 +-
Commit 24d7c494ce46 ("efi/arm-stub: Round up FDT allocation to mapping
size") increased the allocation size for the FDT image created by the
stub to a fixed value of 2 MB, to simplify the former code that made
several attempts with increasing values for the size. This is reasonable
given that the
Commit 3ea86495aef2 ("efi/arm: preserve early mapping of UEFI memory
map longer for BGRT") deferred the unmap of the early mapping of the
UEFI to accommodate the ACPI BGRT code, which looks up the memory
type that backs the BGRT table to validate it against the requirements
of the UEFI spec.
Currently, efi_mem_reserve_persistent() may not be called from atomic
context, since both the kmalloc() call and the memremap() call may
sleep.
The kmalloc() call is easy enough to fix, but the memremap() call
needs to be moved into an init hook since we cannot control the
memory allocation
On Wed, Nov 07, 2018 at 03:16:06PM +0100, Ard Biesheuvel wrote:
> Bhupesh reports that having numerous memblock reservations at early
> boot may result in the following crash:
>
> Unable to handle kernel paging request at virtual address 80003ffe
> ...
> Call trace:
>
(+ Marc)
On 8 November 2018 at 18:22, Qian Cai wrote:
> Looks like more of an EFI issue where it called efi_mem_reserve_persistent().
>
>> Sent: Thursday, November 08, 2018 at 11:23 AM
>> From: "Qian Cai"
>> To: linux-ker...@vger.kernel.org
>> Cc: linux...@kvack.org
>> Subject: BUG: sleeping
Looks like more of an EFI issue where it called efi_mem_reserve_persistent().
> Sent: Thursday, November 08, 2018 at 11:23 AM
> From: "Qian Cai"
> To: linux-ker...@vger.kernel.org
> Cc: linux...@kvack.org
> Subject: BUG: sleeping function called from invalid context at mm/slab.h:421
>
> Just
On Tue, Nov 06, 2018 at 05:21:34PM -0500, Masayoshi Mizuma wrote:
> On Tue, Nov 06, 2018 at 09:45:11PM +0100, Borislav Petkov wrote:
> > On Tue, Nov 06, 2018 at 02:36:38PM -0500, Masayoshi Mizuma wrote:
> > > Yes, I think I can see what you are saying. However, I'm not sure how
> > > I use the
13 matches
Mail list logo
