On Tue, Nov 06, 2018 at 08:02:58PM +0100, Ard Biesheuvel wrote:
> On 6 November 2018 at 12:37, Ard Biesheuvel wrote:
> > The new memory EFI reservation feature we introduced to allow memory
> > reservations to persist across kexec may trigger an unbounded number
> > of calls to
On 6 November 2018 at 12:37, Ard Biesheuvel wrote:
> The new memory EFI reservation feature we introduced to allow memory
> reservations to persist across kexec may trigger an unbounded number
> of calls to memblock_reserve(). The memblock subsystem can deal with
> this fine, but not before
Hi Ard,
On 06/11/18 11:37, Ard Biesheuvel wrote:
> This series addresses the kexec/kdump crash on arm64 system with many CPUs
> that was reported by Bhupesh.
>
> Patches #1 and #2 fix the actual crash. Patches #3 and #4 optimize the
> EFI persistent memreserve infrastructure so that fewer
On 6 November 2018 at 19:27, Marc Zyngier wrote:
> Hi Ard,
>
> On 06/11/18 11:37, Ard Biesheuvel wrote:
>> This series addresses the kexec/kdump crash on arm64 system with many CPUs
>> that was reported by Bhupesh.
>>
>> Patches #1 and #2 fix the actual crash. Patches #3 and #4 optimize the
>>
On 6 November 2018 at 22:34, Will Deacon wrote:
> Hi Ard,
>
> On Tue, Nov 06, 2018 at 12:37:28PM +0100, Ard Biesheuvel wrote:
>> This series addresses the kexec/kdump crash on arm64 system with many CPUs
>> that was reported by Bhupesh.
>>
>> Patches #1 and #2 fix the actual crash. Patches #3 and
On Tue, Nov 06, 2018 at 09:06:56PM +0100, Ard Biesheuvel wrote:
> On 6 November 2018 at 20:08, Russell King - ARM Linux
> wrote:
> > On Tue, Nov 06, 2018 at 08:02:58PM +0100, Ard Biesheuvel wrote:
> >> On 6 November 2018 at 12:37, Ard Biesheuvel
> >> wrote:
> >> > The new memory EFI reservation
On 6 November 2018 at 20:08, Russell King - ARM Linux
wrote:
> On Tue, Nov 06, 2018 at 08:02:58PM +0100, Ard Biesheuvel wrote:
>> On 6 November 2018 at 12:37, Ard Biesheuvel
>> wrote:
>> > The new memory EFI reservation feature we introduced to allow memory
>> > reservations to persist across
Hi Ard,
On Tue, Nov 06, 2018 at 12:37:28PM +0100, Ard Biesheuvel wrote:
> This series addresses the kexec/kdump crash on arm64 system with many CPUs
> that was reported by Bhupesh.
>
> Patches #1 and #2 fix the actual crash. Patches #3 and #4 optimize the
> EFI persistent memreserve
On Tue, Nov 06, 2018 at 10:39:47PM +0100, Ard Biesheuvel wrote:
> On 6 November 2018 at 22:34, Will Deacon wrote:
> > On Tue, Nov 06, 2018 at 12:37:28PM +0100, Ard Biesheuvel wrote:
> >> This series addresses the kexec/kdump crash on arm64 system with many CPUs
> >> that was reported by Bhupesh.
On Tue, Nov 06, 2018 at 12:37:29PM +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:
>
On Tue, 06 Nov 2018 19:01:51 +,
Ard Biesheuvel wrote:
>
> On 6 November 2018 at 19:27, Marc Zyngier wrote:
> > Hi Ard,
> >
> > On 06/11/18 11:37, Ard Biesheuvel wrote:
> >> This series addresses the kexec/kdump crash on arm64 system with many CPUs
> >> that was reported by Bhupesh.
> >>
>
This series addresses the kexec/kdump crash on arm64 system with many CPUs
that was reported by Bhupesh.
Patches #1 and #2 fix the actual crash. Patches #3 and #4 optimize the
EFI persistent memreserve infrastructure so that fewer memblock reservations
are required.
Ard Biesheuvel (4):
arm64:
The new memory EFI reservation feature we introduced to allow memory
reservations to persist across kexec may trigger an unbounded number
of calls to memblock_reserve(). The memblock subsystem can deal with
this fine, but not before memblock resizing is enabled, which we can
only do after
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:
__memcpy+0x110/0x180
memblock_add_range+0x134/0x2e8
memblock_reserve+0x70/0xb8
In preparation of updating efi_mem_reserve_persistent() to cause less
fragmentation when dealing with many persistent reservations, update
the struct definition and the code that handles it currently so it
can describe an arbitrary number of reservations using a single linked
list entry. The
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 kexec reboots,
every reservation
Remove -fdata-sections from the EFI stub build as this causes problems
for the ARM decompressor code.
Signed-off-by: Russell King
---
drivers/firmware/efi/libstub/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/libstub/Makefile
This series enables elimination of dead code from the kernel at link
time. The changes are mostly ARM specific, except for one change in
EFI as the EFI stub must not be compiled with -fdata-sections.
arch/arm/Kconfig | 1 +
arch/arm/boot/compressed/vmlinux.lds.S | 2 +-
On 6 November 2018 at 14:40, Russell King wrote:
> Remove -fdata-sections from the EFI stub build as this causes problems
> for the ARM decompressor code.
>
Just out of curiosity: what kind of problems?
In any case: it doesn't make sense to obsess about .data size
optimizations here, so
On Tue, Nov 06, 2018 at 03:11:18PM +0100, Ard Biesheuvel wrote:
> On 6 November 2018 at 14:40, Russell King wrote:
> > Remove -fdata-sections from the EFI stub build as this causes problems
> > for the ARM decompressor code.
> >
> Just out of curiosity: what kind of problems?
I'm afraid I don't
On 6 November 2018 at 15:21, Russell King - ARM Linux
wrote:
> On Tue, Nov 06, 2018 at 03:11:18PM +0100, Ard Biesheuvel wrote:
>> On 6 November 2018 at 14:40, Russell King wrote:
>> > Remove -fdata-sections from the EFI stub build as this causes problems
>> > for the ARM decompressor code.
>> >
On 6 November 2018 at 02:30, Will Deacon wrote:
> On Fri, Nov 02, 2018 at 02:44:10AM +0530, Bhupesh Sharma wrote:
>> With the latest EFI changes for memblock reservation across kdump
>> kernel from Ard (Commit 71e0940d52e107748b270213a01d3b1546657d74
>> ["efi: honour memory reservations passed
On Thu, Oct 25, 2018 at 09:40:51AM -0400, Masayoshi Mizuma wrote:
> My actual use case is for EFI boxes, however, I think it's better to useful
> for legacy BIOS as well because memory hot-plug affinity in SRAT and KASLR
> are available on legacy BIOS.
> Actually, we can create such environment in
On Mon, Oct 22, 2018 at 05:37:14PM +0800, Chao Fan wrote:
> Now, there are cmdline_find_option() and cmdline_find_option_bool() in
> cmdline.c. Sometimes, when detecting such as whether 'acpi=off' is
> in cmdline, we need to cmdline_find_option() first, then compare
> the argument. Now splite the
On Mon, Nov 5, 2018 at 1:52 PM Ard Biesheuvel wrote:
>
> On 24 October 2018 at 09:22, Sedat Dilek wrote:
> > On Tue, Oct 23, 2018 at 7:53 PM Nathan Chancellor
> > wrote:
> >>
> >> On Fri, Oct 12, 2018 at 06:03:49PM -0700, Nathan Chancellor wrote:
> >> > When building the kernel with Clang, some
On 11/06/18 at 01:10pm, Borislav Petkov wrote:
> > I have another idea to solve this issue. Adding a SRAT parsing code
> > to arch/x86/mm/kaslr.c. It is useful for both EFI and BIOS and
> > also we don't need a new kernel parameter...
> > Dose the idea make sense?
>
> The more automatic stuff we
On 6 November 2018 at 14:15, Sedat Dilek wrote:
> On Mon, Nov 5, 2018 at 1:52 PM Ard Biesheuvel
> wrote:
>>
>> On 24 October 2018 at 09:22, Sedat Dilek wrote:
>> > On Tue, Oct 23, 2018 at 7:53 PM Nathan Chancellor
>> > wrote:
>> >>
>> >> On Fri, Oct 12, 2018 at 06:03:49PM -0700, Nathan
On Thu, Oct 25, 2018 at 09:40:51AM -0400, Masayoshi Mizuma wrote:
> I have another idea to solve this issue. Adding a SRAT parsing code
> to arch/x86/mm/kaslr.c. It is useful for both EFI and BIOS and
> also we don't need a new kernel parameter...
> Dose the idea make sense?
Ok, having swapped
On Mon, Oct 22, 2018 at 05:37:15PM +0800, Chao Fan wrote:
> kstrtoull() lives in 'uncompressed' period, used to
> convert a string to an unsigned long long.
> Copy to 'compressed' so that we can use it to
> convert the memory address from sting to unsigned
sting?
> long long in 'compressed'
On Tue, Nov 06, 2018 at 07:45:19PM +0100, Borislav Petkov wrote:
> Ok, having swapped the whole thing back into my brain, forget what I
> said earlier today.
>
> Didn't we talk about passing info with setup_data to the later kernel
> stage? You even had a patch:
>
>
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 setup_data in legacy BIOS environment.
What is "legacy BIOS environment" and what does that have to do with
setup_data?
--
Regards/Gruss,
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 setup_data in legacy BIOS environment.
>
> What is "legacy BIOS environment"
On Tue, Nov 06, 2018 at 10:07:31PM +0800, Baoquan He wrote:
>On 11/06/18 at 01:10pm, Borislav Petkov wrote:
>> > I have another idea to solve this issue. Adding a SRAT parsing code
>> > to arch/x86/mm/kaslr.c. It is useful for both EFI and BIOS and
>> > also we don't need a new kernel parameter...
On Tue, Nov 06, 2018 at 01:22:53PM +0100, Borislav Petkov wrote:
>On Mon, Oct 22, 2018 at 05:37:14PM +0800, Chao Fan wrote:
>> Now, there are cmdline_find_option() and cmdline_find_option_bool() in
>> cmdline.c. Sometimes, when detecting such as whether 'acpi=off' is
>> in cmdline, we need to
On Tue, Nov 06, 2018 at 08:13:03PM +0100, Borislav Petkov wrote:
>On Mon, Oct 22, 2018 at 05:37:15PM +0800, Chao Fan wrote:
>> kstrtoull() lives in 'uncompressed' period, used to
>> convert a string to an unsigned long long.
>> Copy to 'compressed' so that we can use it to
>> convert the memory
35 matches
Mail list logo
