Re: [PATCH V2 0/3] Fix EFI memory map leaks

On Wed, 5 Dec 2018 at 08:41, Ingo Molnar wrote: > > > * Sai Praneeth Prakhya wrote: > > > Presently, in EFI subsystem of kernel, every time kernel allocates memory > > for a > > new EFI memory map, it forgets to free the memory occupied by old EFI > > memory map. > > It does clear the mappings

Re: [PATCH V2 0/3] Fix EFI memory map leaks

* Sai Praneeth Prakhya wrote: > Presently, in EFI subsystem of kernel, every time kernel allocates memory for > a > new EFI memory map, it forgets to free the memory occupied by old EFI memory > map. > It does clear the mappings though (using efi_memmap_unmap()), but forgets to > free up the

Re: [PATCH V2 2/3] x86/efi: Fix EFI memory map leaks

* Sai Praneeth Prakhya wrote: > if (efi_enabled(EFI_MEMMAP)) { > + /* > + * efi_clean_memmap() uses memblock_phys_alloc() to allocate > + * memory for new EFI memmap and hence will work only after > + * e820__memblock_setup() > +

Re: [PATCH V2 1/3] efi: Introduce efi_memmap_free() and efi_memmap_unmap_and_free()

* Sai Praneeth Prakhya wrote: > +/** > + * efi_memmap_free - Free memory pointed by new_memmap.map > + * @new_memmap: Structure that describes EFI memory map. > + * > + * Memory is freed depending on the type of allocation performed. > + */ > +static void __init efi_memmap_free(struct

[PATCH V2 3/3] x86/efi: Use efi_memmap_() to create runtime EFI memory map

efi_map_regions() uses realloc_pages() to allocate memory for runtime EFI memory map (EFI memory map which contains only memory descriptors of type Runtime Code/Data and Boot Code/Data). Since efi_memmap_alloc() also does the same, use it instead of realloc_pages() and install the new EFI memory

[PATCH V2 1/3] efi: Introduce efi_memmap_free() and efi_memmap_unmap_and_free()

Presently, in EFI subsystem of kernel, every time kernel allocates memory for a new EFI memory map, it forgets to free the memory occupied by old EFI memory map. Hence, introduce efi_memmap_free() that frees up the memory occupied by an EFI memory map. Introduce __efi_memmap_unmap(), so that it

[PATCH V2 2/3] x86/efi: Fix EFI memory map leaks

Presently, in efi subsystem of kernel, every time kernel allocates memory for a new EFI memory map, it forgets to free the memory occupied by the existing EFI memory map. This could be fixed by unmapping and freeing the existing EFI memory map every time before installing a new EFI memory map.

[PATCH V2 0/3] Fix EFI memory map leaks

Presently, in EFI subsystem of kernel, every time kernel allocates memory for a new EFI memory map, it forgets to free the memory occupied by old EFI memory map. It does clear the mappings though (using efi_memmap_unmap()), but forgets to free up the memory. Also, there is another minor issue,

Re: [PATCH 1/2 v8] resource: add the new I/O resource descriptor 'IORES_DESC_RESERVED'

On 11/29/2018 09:37 PM, Dave Young wrote: > + more people > > On 11/29/18 at 04:09pm, Lianbo Jiang wrote: >> When doing kexec_file_load, the first kernel needs to pass the e820 >> reserved ranges to the second kernel. But kernel can not exactly >> match the e820 reserved ranges when walking

Re: [PATCH] pstore: Convert buf_lock to semaphore

On 2018-12-04 09:23:13 [-0800], Kees Cook wrote: > Okay, so, if kmsg_dump() uses rcu_read_lock(), that means efi-pstore > can _never_ sleep, and it's nothing to do with pstore internals. :( I > guess we just hard-code it, then? And efi-pstore should probably only > attach to pstore if it has a

Re: [PATCH] pstore: Convert buf_lock to semaphore

On Tue, Dec 4, 2018 at 7:41 AM Sebastian Andrzej Siewior wrote: > > On 2018-11-30 14:47:36 [-0800], Kees Cook wrote: > > diff --git a/drivers/firmware/efi/efi-pstore.c > > b/drivers/firmware/efi/efi-pstore.c > > index cfe87b465819..0f7d97917197 100644 > > --- a/drivers/firmware/efi/efi-pstore.c

Re: [PATCH] pstore: Convert buf_lock to semaphore

On Tue, Dec 4, 2018 at 7:41 AM Sebastian Andrzej Siewior wrote: > > On 2018-11-30 14:47:36 [-0800], Kees Cook wrote: > > diff --git a/drivers/firmware/efi/efi-pstore.c > > b/drivers/firmware/efi/efi-pstore.c > > index cfe87b465819..0f7d97917197 100644 > > --- a/drivers/firmware/efi/efi-pstore.c

Re: [PATCH] pstore: Convert buf_lock to semaphore

On 2018-11-30 14:47:36 [-0800], Kees Cook wrote: > diff --git a/drivers/firmware/efi/efi-pstore.c > b/drivers/firmware/efi/efi-pstore.c > index cfe87b465819..0f7d97917197 100644 > --- a/drivers/firmware/efi/efi-pstore.c > +++ b/drivers/firmware/efi/efi-pstore.c > @@ -259,8 +259,7 @@ static int

Re: [tip:x86/fpu] x86/fpu: Don't export __kernel_fpu_{begin,end}()

On 2018-12-03 23:08:41 [+0100], Borislav Petkov wrote: > On Mon, Dec 03, 2018 at 10:12:19PM +0100, Ard Biesheuvel wrote: > > > + * Using the FPU in hardirq is not allowed. > > > > According to the documentation in x86/kernel/fpu/core.c, this is not > > true. So which one is accurate? > > I think

[tip:x86/fpu] x86/fpu: Don't export __kernel_fpu_{begin,end}()

Commit-ID: 12209993e98c5fa1855c467f22a24e3d5b8be205 Gitweb: https://git.kernel.org/tip/12209993e98c5fa1855c467f22a24e3d5b8be205 Author: Sebastian Andrzej Siewior AuthorDate: Thu, 29 Nov 2018 16:02:10 +0100 Committer: Borislav Petkov CommitDate: Tue, 4 Dec 2018 12:37:28 +0100 x86/fpu:

Re: [tip:x86/fpu] x86/fpu: Don't export __kernel_fpu_{begin,end}()

On Mon, Dec 03, 2018 at 11:08:41PM +0100, Borislav Petkov wrote: > On Mon, Dec 03, 2018 at 10:12:19PM +0100, Ard Biesheuvel wrote: > > > + * Using the FPU in hardirq is not allowed. > > > > According to the documentation in x86/kernel/fpu/core.c, this is not > > true. So which one is accurate? >

[PATCH 4.9 49/50] efi/libstub: Make file I/O chunking x86-specific

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Ard Biesheuvel (commit b3879a4d3a31ef14265a52e8d941cf4b0f6627ae upstream) The ARM decompressor is finicky when it comes to uninitialized variables with local linkage, the reason being that it