All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolai Stange <nicstange@gmail.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Nicolai Stange <nicstange@gmail.com>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-efi@vger.kernel.org, Borislav Petkov <bp@alien8.de>,
	Dave Young <dyoung@redhat.com>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Peter Jones <pjones@redhat.com>, "Verma\,
	Vishal L" <vishal.l.verma@intel.com>,
	poros@redhat.com
Subject: Re: [PATCH 08/29] efi: Allow drivers to reserve boot services forever
Date: Wed, 04 Jan 2017 18:45:41 +0100	[thread overview]
Message-ID: <87y3yq3eii.fsf@gmail.com> (raw)
In-Reply-To: <CAA9_cmffnH0CH+3DaUW3ytVnRWbZCHa1VcAfWgwMCfbncN_QcA@mail.gmail.com> (Dan Williams's message of "Tue, 3 Jan 2017 18:48:43 -0800")

Dan Williams <dan.j.williams@intel.com> writes:

> This commit appears to cause a boot regression between v4.8 and v4.9.
>
> BUG: unable to handle kernel paging request at ffff8830281bf1c8
> IP: [<ffffffff81a21266>] __next_mem_range_rev+0x13a/0x1d6
> PGD 3193067 PUD 3196067 PTE 80000030281bf060
> Oops: 0000 1 SMP DEBUG_PAGEALLOC
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0+ #2
> task: ffffffff82011540 task.stack: ffffffff82000000
> RIP: 0010:[<ffffffff81a21266>] [<ffffffff81a21266>]
> __next_mem_range_rev+0x13a/0x1d6
> RSP: 0000:ffffffff82003dd8 EFLAGS: 00010202
> RAX: ffff8830281bf1e0 RBX: ffffffff82003e60 RCX: ffffffff82167490
> RDX: 0000000000000000 RSI: 00000000ffffffff RDI: 0000001840000000
> RBP: ffffffff82003e18 R08: ffffffff821674b0 R09: 000000000000008f
> R10: 000000000000008f R11: ffffffff82011cf0 R12: 0000000000000004
> R13: 0000003040000000 R14: 0000000000000000 R15: 0000000000000001
> FS: 0000000000000000(0000) GS:ffff8817e0800000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffff8830281bf1c8 CR3: 000000000200a000 CR4: 00000000007406f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> PKRU: 00000000
> Stack:
> ffffea0000001700 ffffffff82003e50 0000000000000000
> 00000000000010000000003040000000 ffffffff82003e58 0000000000000180
> ffffffffffffffc0
> ffffffff82003e98 ffffffff81a21395 ffffffff82003e58 0000000000000000
> Call Trace:
> [<ffffffff81a21395>] memblock_find_in_range_node+0x93/0x13a
> [<ffffffff8221e3b1>] memblock_alloc_range_nid+0x1b/0x3e
> [<ffffffff8221e5b9>] __memblock_alloc_base+0x15/0x17
> [<ffffffff8221e5cd>] memblock_alloc_base+0x12/0x2e
> [<ffffffff8221e5f4>] memblock_alloc+0xb/0xd
> [<ffffffff82208e22>] efi_free_boot_services+0x46/0x180
> [<ffffffff821e818b>] start_kernel+0x4a1/0x4cc
> [<ffffffff821e7ad8>] ? set_init_arg+0x55/0x55
> [<ffffffff821e7120>] ? early_idt_handler_array+0x120/0x120
> [<ffffffff821e75d6>] x86_64_start_reservations+0x2a/0x2c
> [<ffffffff821e7724>] x86_64_start_kernel+0x14c/0x16f
> Code: 18 44 89 38 41 8d 44 24 ff 49 c1 e1 20 4c 09 c8 48 89 03 e9 a0
> 00 00 00 4d 63 d1 4c 89 d0 48 c1 e0 05 49 03 40 18 45 85 c9 74 28 <48>
> 8b 50 e8 48 03 50 e0 49 83 cb ff 4d 3b 10 73 03 4c 8b 18 49 ^M
> RIP [<ffffffff81a21266>] __next_mem_range_rev+0x13a/0x1d6
>
> I also see that Petr may have run into it as well [1]? Petr is this
> the same signature you are seeing? Can you post a boot log with
> "efi=debug" on the kernel command line?
>
> It also fails on 4.10-rc2.  However, if I revert the following commits
> it boots fine:
>
> 4bc9f92e64c8 x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data
> 8e80632fb23f efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()
> 816e76129ed5 efi: Allow drivers to reserve boot services forever
>
> [1]: https://lkml.org/lkml/2016/12/21/197


Looks very similiar to a problem I've seen with DEBUG_PAGEALLOC=y.

Can you try whether this patch

  http://lkml.kernel.org/r/20161222102340.2689-1-nicstange@gmail.com

fixes it for you?

It makes efi_free_boot_services() not to call into the memblock
allocator -- it must not do that after mm_init().


Thanks,

Nicolai

WARNING: multiple messages have this Message-ID (diff)
From: Nicolai Stange <nicstange-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Nicolai Stange
	<nicstange-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Matt Fleming
	<matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>,
	Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	"H . Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>,
	Ard Biesheuvel
	<ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>,
	Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Leif Lindholm
	<leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Peter Jones <pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	"Verma,
	Vishal L"
	<vishal.l.verma-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	poros-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Subject: Re: [PATCH 08/29] efi: Allow drivers to reserve boot services forever
Date: Wed, 04 Jan 2017 18:45:41 +0100	[thread overview]
Message-ID: <87y3yq3eii.fsf@gmail.com> (raw)
In-Reply-To: <CAA9_cmffnH0CH+3DaUW3ytVnRWbZCHa1VcAfWgwMCfbncN_QcA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> (Dan Williams's message of "Tue, 3 Jan 2017 18:48:43 -0800")

Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> writes:

> This commit appears to cause a boot regression between v4.8 and v4.9.
>
> BUG: unable to handle kernel paging request at ffff8830281bf1c8
> IP: [<ffffffff81a21266>] __next_mem_range_rev+0x13a/0x1d6
> PGD 3193067 PUD 3196067 PTE 80000030281bf060
> Oops: 0000 1 SMP DEBUG_PAGEALLOC
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0+ #2
> task: ffffffff82011540 task.stack: ffffffff82000000
> RIP: 0010:[<ffffffff81a21266>] [<ffffffff81a21266>]
> __next_mem_range_rev+0x13a/0x1d6
> RSP: 0000:ffffffff82003dd8 EFLAGS: 00010202
> RAX: ffff8830281bf1e0 RBX: ffffffff82003e60 RCX: ffffffff82167490
> RDX: 0000000000000000 RSI: 00000000ffffffff RDI: 0000001840000000
> RBP: ffffffff82003e18 R08: ffffffff821674b0 R09: 000000000000008f
> R10: 000000000000008f R11: ffffffff82011cf0 R12: 0000000000000004
> R13: 0000003040000000 R14: 0000000000000000 R15: 0000000000000001
> FS: 0000000000000000(0000) GS:ffff8817e0800000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffff8830281bf1c8 CR3: 000000000200a000 CR4: 00000000007406f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> PKRU: 00000000
> Stack:
> ffffea0000001700 ffffffff82003e50 0000000000000000
> 00000000000010000000003040000000 ffffffff82003e58 0000000000000180
> ffffffffffffffc0
> ffffffff82003e98 ffffffff81a21395 ffffffff82003e58 0000000000000000
> Call Trace:
> [<ffffffff81a21395>] memblock_find_in_range_node+0x93/0x13a
> [<ffffffff8221e3b1>] memblock_alloc_range_nid+0x1b/0x3e
> [<ffffffff8221e5b9>] __memblock_alloc_base+0x15/0x17
> [<ffffffff8221e5cd>] memblock_alloc_base+0x12/0x2e
> [<ffffffff8221e5f4>] memblock_alloc+0xb/0xd
> [<ffffffff82208e22>] efi_free_boot_services+0x46/0x180
> [<ffffffff821e818b>] start_kernel+0x4a1/0x4cc
> [<ffffffff821e7ad8>] ? set_init_arg+0x55/0x55
> [<ffffffff821e7120>] ? early_idt_handler_array+0x120/0x120
> [<ffffffff821e75d6>] x86_64_start_reservations+0x2a/0x2c
> [<ffffffff821e7724>] x86_64_start_kernel+0x14c/0x16f
> Code: 18 44 89 38 41 8d 44 24 ff 49 c1 e1 20 4c 09 c8 48 89 03 e9 a0
> 00 00 00 4d 63 d1 4c 89 d0 48 c1 e0 05 49 03 40 18 45 85 c9 74 28 <48>
> 8b 50 e8 48 03 50 e0 49 83 cb ff 4d 3b 10 73 03 4c 8b 18 49 ^M
> RIP [<ffffffff81a21266>] __next_mem_range_rev+0x13a/0x1d6
>
> I also see that Petr may have run into it as well [1]? Petr is this
> the same signature you are seeing? Can you post a boot log with
> "efi=debug" on the kernel command line?
>
> It also fails on 4.10-rc2.  However, if I revert the following commits
> it boots fine:
>
> 4bc9f92e64c8 x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data
> 8e80632fb23f efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()
> 816e76129ed5 efi: Allow drivers to reserve boot services forever
>
> [1]: https://lkml.org/lkml/2016/12/21/197


Looks very similiar to a problem I've seen with DEBUG_PAGEALLOC=y.

Can you try whether this patch

  http://lkml.kernel.org/r/20161222102340.2689-1-nicstange-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

fixes it for you?

It makes efi_free_boot_services() not to call into the memblock
allocator -- it must not do that after mm_init().


Thanks,

Nicolai

  parent reply	other threads:[~2017-01-04 17:45 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-09 15:18 [GIT PULL 00/29] EFI changes for v4.9 Matt Fleming
2016-09-09 15:18 ` Matt Fleming
2016-09-09 15:18 ` [PATCH 01/29] x86/efi: Test for EFI_MEMMAP functionality when iterating EFI memmap Matt Fleming
2016-09-09 15:18 ` [PATCH 02/29] x86/efi: Consolidate region mapping logic Matt Fleming
2016-09-09 15:18   ` Matt Fleming
2016-09-09 15:18 ` [PATCH 03/29] efi: Refactor efi_memmap_init_early() into arch-neutral code Matt Fleming
2016-09-09 15:18 ` [PATCH 04/29] efi: Add efi_memmap_init_late() for permanent EFI memmap Matt Fleming
2016-09-09 15:18   ` Matt Fleming
2016-09-09 15:18 ` [PATCH 05/29] efi/fake_mem: Refactor main two code chunks into functions Matt Fleming
2016-09-09 15:18 ` [PATCH 06/29] efi: Split out EFI memory map functions into new file Matt Fleming
2016-09-09 15:18 ` [PATCH 07/29] efi: Add efi_memmap_install() for installing new EFI memory maps Matt Fleming
2016-09-09 15:18   ` Matt Fleming
2016-09-09 15:18 ` [PATCH 08/29] efi: Allow drivers to reserve boot services forever Matt Fleming
2017-01-04  2:48   ` Dan Williams
2017-01-04  5:28     ` Dave Young
2017-01-04  5:28       ` Dave Young
2017-01-04 14:25     ` Peter Jones
2017-01-04 14:25       ` Peter Jones
2017-01-04 17:45     ` Nicolai Stange [this message]
2017-01-04 17:45       ` Nicolai Stange
2017-01-04 18:40       ` Dan Williams
2016-09-09 15:18 ` [PATCH 09/29] efi/runtime-map: Use efi.memmap directly instead of a copy Matt Fleming
2016-09-09 15:18 ` [PATCH 10/29] efi/esrt: Use efi_mem_reserve() and avoid a kmalloc() Matt Fleming
2016-09-09 15:18   ` Matt Fleming
2016-09-09 15:18 ` [PATCH 11/29] x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data Matt Fleming
2016-09-09 15:18 ` [PATCH 12/29] efi/esrt: Use memremap not ioremap to access ESRT table in memory Matt Fleming
2016-09-09 15:18   ` Matt Fleming
2016-09-09 15:18 ` [PATCH 13/29] efi/arm*: esrt: Add missing call to efi_esrt_init() Matt Fleming
2016-09-09 15:18   ` Matt Fleming
2016-09-09 15:18 ` [PATCH 14/29] efi: Use a file local lock for efivars Matt Fleming
2016-09-09 15:18 ` [PATCH 15/29] efi: Don't use spinlocks for efi vars Matt Fleming
2016-09-09 15:18   ` Matt Fleming
2016-09-09 15:18 ` [PATCH 16/29] efi: Replace runtime services spinlock with semaphore Matt Fleming
2016-09-09 15:18 ` [PATCH 17/29] x86/efi: Initialize status to ensure garbage is not returned on small size Matt Fleming
2016-09-09 15:18 ` [PATCH 18/29] firmware-gsmi: Delete an unnecessary check before the function call "dma_pool_destroy" Matt Fleming
2016-09-09 15:18   ` Matt Fleming
2016-09-09 15:18 ` [PATCH 19/29] lib/ucs2_string: Speed up ucs2_utf8size() Matt Fleming
2016-09-09 15:18 ` [PATCH 20/29] x86/efi: Map in physical addresses in efi_map_region_fixed Matt Fleming
2016-09-09 15:18   ` Matt Fleming
2016-09-09 15:18 ` [PATCH 21/29] fs/efivarfs: Fix double kfree() in error path Matt Fleming
2016-09-09 15:18 ` [PATCH 22/29] x86/efi: Remove unused find_bits() function Matt Fleming
2016-09-09 15:18 ` [PATCH 23/29] efi/arm64: Add debugfs node to dump UEFI runtime page tables Matt Fleming
2016-09-09 15:18 ` [PATCH 24/29] x86/efi: Defer efi_esrt_init until after memblock_x86_fill Matt Fleming
2016-09-09 15:18   ` Matt Fleming
2016-09-09 15:18 ` [PATCH 25/29] efi: Add efi_test driver for exporting UEFI runtime service interfaces Matt Fleming
2016-09-09 15:18 ` [PATCH 26/29] efi/arm64: Treat regions with WT/WC set but WB cleared as memory Matt Fleming
2016-09-09 15:18   ` Matt Fleming
2016-09-09 15:18 ` [PATCH 27/29] x86/efi: Use kmalloc_array() in efi_call_phys_prolog() Matt Fleming
2016-09-09 15:18 ` [PATCH 28/29] x86/efi: Optimize away setup_gop32/64 if unused Matt Fleming
2016-09-09 15:18   ` Matt Fleming
2016-09-09 15:18 ` [PATCH 29/29] x86/efi: Allow invocation of arbitrary boot services Matt Fleming
2016-09-12 10:58 ` [GIT PULL 00/29] EFI changes for v4.9 Matt Fleming
2016-09-12 10:58   ` Matt Fleming
2016-09-12 11:42   ` Ingo Molnar
2016-09-12 11:42     ` Ingo Molnar
2016-09-13 18:32 ` Ingo Molnar
2016-09-13 18:32   ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y3yq3eii.fsf@gmail.com \
    --to=nicstange@gmail.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=dyoung@redhat.com \
    --cc=hpa@zytor.com \
    --cc=leif.lindholm@linaro.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@kernel.org \
    --cc=pjones@redhat.com \
    --cc=poros@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=vishal.l.verma@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.