Re: [PATCH] pstore: Convert buf_lock to semaphore

2018-11-30 Thread Kees Cook
On Fri, Nov 30, 2018 at 2:52 PM Arnd Bergmann wrote: > > On Fri, Nov 30, 2018 at 11:48 PM Kees Cook wrote: > > > > Instead of running with interrupts disabled, use a semaphore. This should > > make it easier for backends that may need to sleep (e.g. EFI) when > > performing a write: > > > >

Re: [PATCH] pstore: Convert buf_lock to semaphore

2018-11-30 Thread Arnd Bergmann
On Fri, Nov 30, 2018 at 11:48 PM Kees Cook wrote: > > Instead of running with interrupts disabled, use a semaphore. This should > make it easier for backends that may need to sleep (e.g. EFI) when > performing a write: > > |BUG: sleeping function called from invalid context at >

[PATCH] pstore: Convert buf_lock to semaphore

2018-11-30 Thread Kees Cook
Instead of running with interrupts disabled, use a semaphore. This should make it easier for backends that may need to sleep (e.g. EFI) when performing a write: |BUG: sleeping function called from invalid context at kernel/sched/completion.c:99 |in_atomic(): 1, irqs_disabled(): 1, pid: 2236,

Re: EFI-pstore, sleeping from back context after fault

2018-11-30 Thread Kees Cook
On Fri, Nov 30, 2018 at 1:20 PM Kees Cook wrote: > > On Fri, Nov 30, 2018 at 3:43 AM Sebastian Andrzej Siewior > wrote: > > > > On 2018-11-29 13:43:58 [-0800], Kees Cook wrote: > > > On Mon, Nov 26, 2018 at 9:04 AM Sebastian Andrzej Siewior > > > wrote: > > > This bug got handled by Jann Horn,

Re: EFI-pstore, sleeping from back context after fault

2018-11-30 Thread Kees Cook
On Fri, Nov 30, 2018 at 3:43 AM Sebastian Andrzej Siewior wrote: > > On 2018-11-29 13:43:58 [-0800], Kees Cook wrote: > > On Mon, Nov 26, 2018 at 9:04 AM Sebastian Andrzej Siewior > > wrote: > > This bug got handled by Jann Horn, yes? (I remember seeing a related > > thread go by...) > >

RE: [GIT PULL 00/11] EFI updates

2018-11-30 Thread Prakhya, Sai Praneeth
> On Thu, 29 Nov 2018 at 19:27, Prakhya, Sai Praneeth > wrote: > > > > Hi Ard, > > > > While building from next branch of efi tree, I noticed the below warning. > > Could > you please check the same on your side? > > > > CC lib/list_debug.o > > drivers/firmware/efi/efi.c: In function

Re: [GIT PULL 00/11] EFI updates

2018-11-30 Thread Ard Biesheuvel
On Thu, 29 Nov 2018 at 19:27, Prakhya, Sai Praneeth wrote: > > Hi Ard, > > While building from next branch of efi tree, I noticed the below warning. > Could you please check the same on your side? > > CC lib/list_debug.o > drivers/firmware/efi/efi.c: In function

Re: EFI-pstore, sleeping from back context after fault

2018-11-30 Thread Sebastian Andrzej Siewior
On 2018-11-29 13:43:58 [-0800], Kees Cook wrote: > On Mon, Nov 26, 2018 at 9:04 AM Sebastian Andrzej Siewior > wrote: > This bug got handled by Jann Horn, yes? (I remember seeing a related > thread go by...) Correct, fix sits in the tip tree. Nevertheless it was useful to spot the other thing.

Re: [PATCH] efi/fdt: More cleanups

2018-11-30 Thread Ingo Molnar
* Ard Biesheuvel wrote: > On Fri, 30 Nov 2018 at 08:57, Ingo Molnar wrote: > > > > > > * Ard Biesheuvel wrote: > > > > > From: Julien Thierry > > > > > > Closing bracket seems to end a for statement when it is actually ending > > > the contained if. Add some brackets to have clear

Re: [PATCH 10/11] efi: reduce the amount of memblock reservations for persistent allocations

2018-11-30 Thread Ard Biesheuvel
On Fri, 30 Nov 2018 at 09:38, Ingo Molnar wrote: > > > * Ard Biesheuvel wrote: > > > The current implementation of efi_mem_reserve_persistent() is rather > > naive, in the sense that for each invocation, it creates a separate > > linked list entry to describe the reservation. Since the linked

Re: [PATCH 10/11] efi: reduce the amount of memblock reservations for persistent allocations

2018-11-30 Thread Ingo Molnar
* Ard Biesheuvel wrote: > The current implementation of efi_mem_reserve_persistent() is rather > naive, in the sense that for each invocation, it creates a separate > linked list entry to describe the reservation. Since the linked list > entries themselves need to persist across subsequent

Re: [PATCH 08/11] firmware: efi: add NULL pointer checks in efivars api functions

2018-11-30 Thread Ard Biesheuvel
On Fri, 30 Nov 2018 at 09:12, Ingo Molnar wrote: > > > * Ard Biesheuvel wrote: > > > From: Arend van Spriel > > > > Since commit: > > > >ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from > > EFI variables") > > This commit ID is not upstream AFAICS. Which

Re: [PATCH 01/11] x86/efi: Allocate e820 buffer before calling efi_exit_boot_service

2018-11-30 Thread Ingo Molnar
* Ard Biesheuvel wrote: > On Fri, 30 Nov 2018 at 08:29, Ingo Molnar wrote: > > > > > > * Ard Biesheuvel wrote: > > > > > From: Eric Snowberg > > > > > > Commit d64934019f6c ("x86/efi: Use efi_exit_boot_services()") > > > introduced a regression on systems with large memory maps > > >

Re: [PATCH 11/11] efi/x86: earlyprintk - Fix infinite loop on some screen widths

2018-11-30 Thread Ard Biesheuvel
On Fri, 30 Nov 2018 at 09:05, Ingo Molnar wrote: > > > * Ard Biesheuvel wrote: > > > From: YiFei Zhu > > > > An affected screen resolution is 1366 x 768, which width is not > > divisible by 8, the default font width. On such screens, when longer > > lines are earlyprintk'ed,

Re: [PATCH] efi/fdt: More cleanups

2018-11-30 Thread Ard Biesheuvel
On Fri, 30 Nov 2018 at 08:57, Ingo Molnar wrote: > > > * Ard Biesheuvel wrote: > > > From: Julien Thierry > > > > Closing bracket seems to end a for statement when it is actually ending > > the contained if. Add some brackets to have clear delimitation of each > > scope. > > > > No functional

Re: [PATCH 01/11] x86/efi: Allocate e820 buffer before calling efi_exit_boot_service

2018-11-30 Thread Ard Biesheuvel
On Fri, 30 Nov 2018 at 08:29, Ingo Molnar wrote: > > > * Ard Biesheuvel wrote: > > > From: Eric Snowberg > > > > Commit d64934019f6c ("x86/efi: Use efi_exit_boot_services()") > > introduced a regression on systems with large memory maps > > causing them to hang on boot. The first "goto get_map"

Re: [PATCH 08/11] firmware: efi: add NULL pointer checks in efivars api functions

2018-11-30 Thread Ingo Molnar
* Ard Biesheuvel wrote: > From: Arend van Spriel > > Since commit: > >ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from > EFI variables") This commit ID is not upstream AFAICS. Which tree is it from? Mentioning non-upstream sha1's is discouraged in

Re: [PATCH 11/11] efi/x86: earlyprintk - Fix infinite loop on some screen widths

2018-11-30 Thread Ingo Molnar
* Ard Biesheuvel wrote: > From: YiFei Zhu > > An affected screen resolution is 1366 x 768, which width is not > divisible by 8, the default font width. On such screens, when longer > lines are earlyprintk'ed, overflow-to-next-line can never trigger, > due to the left-most x-coordinate of the