Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1306256 > unrolled thread

Re: v4.4-rc8 based tip tree kernel hangs on boot.

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: v4.4-rc8 based tip tree kernel hangs on boot. Matt Fleming <matt@codeblueprint.co.uk> - 2016-01-11 15:10 +0100
    Re: v4.4-rc8 based tip tree kernel hangs on boot. Ingo Molnar <mingo@kernel.org> - 2016-01-11 16:20 +0100
      Re: v4.4-rc8 based tip tree kernel hangs on boot. Srikar Dronamraju <srikar@linux.vnet.ibm.com> - 2016-01-11 17:50 +0100
    Re: v4.4-rc8 based tip tree kernel hangs on boot. Ingo Molnar <mingo@kernel.org> - 2016-01-12 11:40 +0100
      Re: v4.4-rc8 based tip tree kernel hangs on boot. Matt Fleming <matt@codeblueprint.co.uk> - 2016-01-14 13:30 +0100
      Re: v4.4-rc8 based tip tree kernel hangs on boot. Srikar Dronamraju <srikar@linux.vnet.ibm.com> - 2016-01-15 17:30 +0100
        Re: v4.4-rc8 based tip tree kernel hangs on boot. Matt Fleming <matt@codeblueprint.co.uk> - 2016-01-15 23:30 +0100
          Re: v4.4-rc8 based tip tree kernel hangs on boot. Matt Fleming <matt@codeblueprint.co.uk> - 2016-01-18 16:50 +0100
            Re: v4.4-rc8 based tip tree kernel hangs on boot. Matt Fleming <matt@codeblueprint.co.uk> - 2016-01-19 16:50 +0100
              Re: v4.4-rc8 based tip tree kernel hangs on boot. Srikar Dronamraju <srikar@linux.vnet.ibm.com> - 2016-01-19 19:20 +0100

#1306256 — Re: v4.4-rc8 based tip tree kernel hangs on boot.

On Mon, 11 Jan, at 12:59:21AM, Srikar Dronamraju wrote:
> On a x86_64 machine, I see kernel v4.4-rc8 based tip tree hangs on boot.
> However v4.4-rc8 with the same config boots well on the same machine.
> 
> git bisect results are as follows
> 
> git bisect start
> # bad: [fc4e8fa9f80e0f099838f3a9997019de36d9a4ba] Merge branch 'WIP.x86/mm'
> git bisect bad fc4e8fa9f80e0f099838f3a9997019de36d9a4ba
> # good: [168309855a7d1e16db751e9c647119fe2d2dc878] Linux 4.4-rc8
> git bisect good 168309855a7d1e16db751e9c647119fe2d2dc878
> # good: [76e17c25ebc9f6619f9f8fd93f3905b0def8dc6f] Merge branch 'perf/core'
> git bisect good 76e17c25ebc9f6619f9f8fd93f3905b0def8dc6f
> # good: [e8998ce7e8ce42419d0c7bb08c105bd860eb3218] Merge branch 'timers/urgent'
> git bisect good e8998ce7e8ce42419d0c7bb08c105bd860eb3218
> # good: [af51cdabdbea5355ed388b8b3a7cf9bfc0864b9c] Merge branch 'x86/cpu'
> git bisect good af51cdabdbea5355ed388b8b3a7cf9bfc0864b9c
> # bad: [5852b88267adcc78722fc5d4f45751fb6e261bd2] Merge branch 'x86/urgent'
> git bisect bad 5852b88267adcc78722fc5d4f45751fb6e261bd2
> # bad: [c236714fd39fb26993af2d5fde9c3bfc32361323] Merge branch 'x86/fpu'
> git bisect bad c236714fd39fb26993af2d5fde9c3bfc32361323
> # bad: [ff3d0a12fb2dc123e2b46e9524ebf4e08de5c59c] Documentation/x86: Update EFI memory region description
> git bisect bad ff3d0a12fb2dc123e2b46e9524ebf4e08de5c59c
> # bad: [b61a76f8850d2979550abc42d7e09154ebb8d785] x86/efi: Map RAM into the identity page table for mixed mode
> git bisect bad b61a76f8850d2979550abc42d7e09154ebb8d785
> # bad: [edc3b9129cecd0f0857112136f5b8b1bc1d45918] x86/mm/pat: Ensure cpa->pfn only contains page frame numbers
> git bisect bad edc3b9129cecd0f0857112136f5b8b1bc1d45918
> # bad: [21cdb6b568435738cc0b303b2b3b82742396310c] x86/mm: Page align the '_end' symbol to avoid pfn conversion bugs
> git bisect bad 21cdb6b568435738cc0b303b2b3b82742396310c
> # first bad commit: [21cdb6b568435738cc0b303b2b3b82742396310c] x86/mm: Page align the '_end' symbol to avoid pfn conversion bugs
> 
> Not much info on the console, when the kernel hangs.
 
What info is there?

> Tried reverting Commit 21cdb6b56 "x86/mm: Page align the '_end'
> symbol to avoid pfn conversion bugs" but that doesnt help.

Odd. Could you try booting the tip/x86/efi branch instead? There's
only a handful of patches on that branch so it should be pretty easy
to narrow down the problematic change.

[toc] | [next] | [standalone]

#1306382

* Matt Fleming <matt@codeblueprint.co.uk> wrote:

> On Mon, 11 Jan, at 12:59:21AM, Srikar Dronamraju wrote:
> > On a x86_64 machine, I see kernel v4.4-rc8 based tip tree hangs on boot.
> > However v4.4-rc8 with the same config boots well on the same machine.
> > 
> > git bisect results are as follows
> > 
> > git bisect start
> > # bad: [fc4e8fa9f80e0f099838f3a9997019de36d9a4ba] Merge branch 'WIP.x86/mm'
> > git bisect bad fc4e8fa9f80e0f099838f3a9997019de36d9a4ba
> > # good: [168309855a7d1e16db751e9c647119fe2d2dc878] Linux 4.4-rc8
> > git bisect good 168309855a7d1e16db751e9c647119fe2d2dc878
> > # good: [76e17c25ebc9f6619f9f8fd93f3905b0def8dc6f] Merge branch 'perf/core'
> > git bisect good 76e17c25ebc9f6619f9f8fd93f3905b0def8dc6f
> > # good: [e8998ce7e8ce42419d0c7bb08c105bd860eb3218] Merge branch 'timers/urgent'
> > git bisect good e8998ce7e8ce42419d0c7bb08c105bd860eb3218
> > # good: [af51cdabdbea5355ed388b8b3a7cf9bfc0864b9c] Merge branch 'x86/cpu'
> > git bisect good af51cdabdbea5355ed388b8b3a7cf9bfc0864b9c
> > # bad: [5852b88267adcc78722fc5d4f45751fb6e261bd2] Merge branch 'x86/urgent'
> > git bisect bad 5852b88267adcc78722fc5d4f45751fb6e261bd2
> > # bad: [c236714fd39fb26993af2d5fde9c3bfc32361323] Merge branch 'x86/fpu'
> > git bisect bad c236714fd39fb26993af2d5fde9c3bfc32361323
> > # bad: [ff3d0a12fb2dc123e2b46e9524ebf4e08de5c59c] Documentation/x86: Update EFI memory region description
> > git bisect bad ff3d0a12fb2dc123e2b46e9524ebf4e08de5c59c
> > # bad: [b61a76f8850d2979550abc42d7e09154ebb8d785] x86/efi: Map RAM into the identity page table for mixed mode
> > git bisect bad b61a76f8850d2979550abc42d7e09154ebb8d785
> > # bad: [edc3b9129cecd0f0857112136f5b8b1bc1d45918] x86/mm/pat: Ensure cpa->pfn only contains page frame numbers
> > git bisect bad edc3b9129cecd0f0857112136f5b8b1bc1d45918
> > # bad: [21cdb6b568435738cc0b303b2b3b82742396310c] x86/mm: Page align the '_end' symbol to avoid pfn conversion bugs
> > git bisect bad 21cdb6b568435738cc0b303b2b3b82742396310c
> > # first bad commit: [21cdb6b568435738cc0b303b2b3b82742396310c] x86/mm: Page align the '_end' symbol to avoid pfn conversion bugs
> > 
> > Not much info on the console, when the kernel hangs.
>  
> What info is there?
> 
> > Tried reverting Commit 21cdb6b56 "x86/mm: Page align the '_end'
> > symbol to avoid pfn conversion bugs" but that doesnt help.
> 
> Odd. Could you try booting the tip/x86/efi branch instead? There's
> only a handful of patches on that branch so it should be pretty easy
> to narrow down the problematic change.

Yes, that would be nice, you can get it via:

  git checkout v4.4
  git pull git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/efi

Meanwhile I'm holding off on sending the pending EFI bits to Linus, conditional on 
the outcome of this regression report.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1306502

> >  
> > What info is there?
> > 

https://goo.gl/photos/1izrwCtAWj8aK7hi7
Unfortunately I am unable to get a text console. So this is all I see.


> > > Tried reverting Commit 21cdb6b56 "x86/mm: Page align the '_end'
> > > symbol to avoid pfn conversion bugs" but that doesnt help.
> > 
> > Odd. Could you try booting the tip/x86/efi branch instead? There's
> > only a handful of patches on that branch so it should be pretty easy
> > to narrow down the problematic change.
> 
> Yes, that would be nice, you can get it via:
> 

# git reset --hard tip/x86/efi
HEAD is now at e2c90dd x86/efi-bgrt: Replace early_memremap() with memremap()

Tried to boot with the above commit; but it doesnt boot.

-- 
Thanks and Regards
Srikar

>   git checkout v4.4
>   git pull git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/efi
> 
> Meanwhile I'm holding off on sending the pending EFI bits to Linus, conditional on 
> the outcome of this regression report.
> 
> Thanks,
> 
> 	Ingo
> 

-- 
Thanks and Regards
Srikar Dronamraju

[toc] | [prev] | [next] | [standalone]

#1307239

* Matt Fleming <matt@codeblueprint.co.uk> wrote:

> > Tried reverting Commit 21cdb6b56 "x86/mm: Page align the '_end'
> > symbol to avoid pfn conversion bugs" but that doesnt help.
> 
> Odd. Could you try booting the tip/x86/efi branch instead? There's
> only a handful of patches on that branch so it should be pretty easy
> to narrow down the problematic change.

So he already appears to have done that, when performing the bisection:

 # first bad commit: [21cdb6b568435738cc0b303b2b3b82742396310c] x86/mm: Page align the '_end' symbol to avoid pfn conversion bugs

commit 21cdb6b568 is part of tip:x86/efi:

 triton:~/tip> gll linus..x86/efi
 e2c90dd7e11e x86/efi-bgrt: Replace early_memremap() with memremap()
 98f91276900f Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/efi
 50a0cb565246 x86/efi-bgrt: Fix kernel panic when mapping BGRT data
 26d7f65fbd22 x86/efi: Preface all print statements with efi* tag
 3bb9eee61c64 doc: efi-stub.txt: Fix arm64 paths
 7f83773ced2f efi/esrt: Don't preformat name
 ff3d0a12fb2d Documentation/x86: Update EFI memory region description
 67a9108ed431 x86/efi: Build our own page table structures
 c9f2a9a65e48 x86/efi: Hoist page table switching code into efi_call_virt()
 b61a76f8850d x86/efi: Map RAM into the identity page table for mixed mode
 edc3b9129cec x86/mm/pat: Ensure cpa->pfn only contains page frame numbers
 21cdb6b56843 x86/mm: Page align the '_end' symbol to avoid pfn conversion bugs

it's the first commit in the branch in fact.

To double check, it would be nice to check that applying that commit to v4.4 
breaks the boot too:

  git checkout v4.4
  git cherry-pick 21cdb6b568

... but assuming the bisection is reliable, I'd say the evidence is pretty 
conclusive already.

Srikar, could you please send the good and bad System.map files, so that we see 
what the effects of the aligning were? The two interesting sha1's to test are:

  21cdb6b56843: first bad commit
  6ffeba960734: last good commit (parent commit of 21cdb6b56843)

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1309228

On Tue, 12 Jan, at 11:30:44AM, Ingo Molnar wrote:
> 
> Srikar, could you please send the good and bad System.map files, so that we see 
> what the effects of the aligning were? The two interesting sha1's to test are:
> 
>   21cdb6b56843: first bad commit
>   6ffeba960734: last good commit (parent commit of 21cdb6b56843)

Srikar any update here? This issue is holding up the merging of all
new EFI material for v4.5.

I was unable to reproduce your issue locally, what machine are you
running? From the hang picture it looks like some IBM machine, but if
you could provide more details that'd be useful.

[toc] | [prev] | [next] | [standalone]

#1310252

[Multipart message — attachments visible in raw view] — view raw

> 
> it's the first commit in the branch in fact.
> 
> To double check, it would be nice to check that applying that commit to v4.4 
> breaks the boot too:
> 
>   git checkout v4.4
>   git cherry-pick 21cdb6b568
> 

This actually boots. i.e cherry-pick 21cdb6b568 on top of v4.4 boots
well. Next I kept on adding cherry-picks from tip/x86/efi

git log --oneline tip/x86/efi looked like this 

e2c90dd x86/efi-bgrt: Replace early_memremap() with memremap()
98f9127 Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/efi
50a0cb5 x86/efi-bgrt: Fix kernel panic when mapping BGRT data
26d7f65 x86/efi: Preface all print statements with efi* tag
3bb9eee doc: efi-stub.txt: Fix arm64 paths
7f83773 efi/esrt: Don't preformat name
ff3d0a1 Documentation/x86: Update EFI memory region description
67a9108 x86/efi: Build our own page table structures
c9f2a9a x86/efi: Hoist page table switching code into efi_call_virt()
b61a76f x86/efi: Map RAM into the identity page table for mixed mode
edc3b91 x86/mm/pat: Ensure cpa->pfn only contains page frame numbers
21cdb6b x86/mm: Page align the '_end' symbol to avoid pfn conversion bugs


So when I cherry-pick 67a9108 "x86/efi: Build our own page table
structures", the built kernel stops booting.

i.e until until I cherry-pick c9f2a9a, the kernel boots.

I still have to verify why git bisect was failing to give the right
commit.

Attached the dmesg of a good kernel boot as requested by Matt.

--
Thanks and Regards
Srikar

> ... but assuming the bisection is reliable, I'd say the evidence is pretty 
> conclusive already.
> 
> Srikar, could you please send the good and bad System.map files, so that we see 
> what the effects of the aligning were? The two interesting sha1's to test are:
> 
>   21cdb6b56843: first bad commit
>   6ffeba960734: last good commit (parent commit of 21cdb6b56843)
> 
> Thanks,
> 
> 	Ingo
> 

-- 
Thanks and Regards
Srikar Dronamraju

[toc] | [prev] | [next] | [standalone]

#1310508

On Fri, 15 Jan, at 09:50:11PM, Srikar Dronamraju wrote:
> 
> So when I cherry-pick 67a9108 "x86/efi: Build our own page table
> structures", the built kernel stops booting.
 
Yeah, figures. At least that's less surprising that the linker script
change causing your machine to stop booting.

> i.e until until I cherry-pick c9f2a9a, the kernel boots.
> 
> I still have to verify why git bisect was failing to give the right
> commit.
> 
> Attached the dmesg of a good kernel boot as requested by Matt.

Can you confirm that CONFIG_DEBUG_WX isn't enabled in the .config you
used to test tip? Because the dmesg you attached shows that it is
enabled, but it wasn't enabled in the .config you attached in the
beginning of this thread.

Was it disabled when you tested commit 67a9108?

Could you try the following patch on top of commit c9f2a9a ("x86/efi:
Hoist page table switching code into efi_call_virt()")? Be sure to
enable CONFIG_EFI_PGT_DUMP and send me the output of dmesg.

---

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 347eeacb06a8..8fd9e637629a 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -136,6 +136,7 @@ extern void __init efi_memory_uc(u64 addr, unsigned long size);
 extern void __init efi_map_region(efi_memory_desc_t *md);
 extern void __init efi_map_region_fixed(efi_memory_desc_t *md);
 extern void efi_sync_low_kernel_mappings(void);
+extern int __init efi_alloc_page_tables(void);
 extern int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages);
 extern void __init efi_cleanup_page_tables(unsigned long pa_memmap, unsigned num_pages);
 extern void __init old_map_region(efi_memory_desc_t *md);
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index ad285404ea7f..8f778817ae9f 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -895,6 +895,12 @@ static void __init __efi_enter_virtual_mode(void)
 
 	efi.systab = NULL;
 
+	if (efi_alloc_page_tables()) {
+		pr_err("Failed to allocate EFI page tables\n");
+		clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
+		return;
+	}
+
 	efi_merge_regions();
 	new_memmap = efi_map_regions(&count, &pg_shift);
 	if (!new_memmap) {
diff --git a/arch/x86/platform/efi/efi_32.c b/arch/x86/platform/efi/efi_32.c
index ed5b67338294..58d669bc8250 100644
--- a/arch/x86/platform/efi/efi_32.c
+++ b/arch/x86/platform/efi/efi_32.c
@@ -38,6 +38,11 @@
  * say 0 - 3G.
  */
 
+int __init efi_alloc_page_tables(void)
+{
+	return 0;
+}
+
 void efi_sync_low_kernel_mappings(void) {}
 void __init efi_dump_pagetable(void) {}
 int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index b19cdac959b2..71121a9d06cf 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -40,6 +40,7 @@
 #include <asm/fixmap.h>
 #include <asm/realmode.h>
 #include <asm/time.h>
+#include <asm/pgalloc.h>
 
 /*
  * We allocate runtime services regions bottom-up, starting from -4G, i.e.
@@ -121,6 +122,41 @@ void __init efi_call_phys_epilog(pgd_t *save_pgd)
 	early_code_mapping_set_exec(0);
 }
 
+static pgd_t *efi_pgd;
+
+/*
+ * We need our own copy of the higher levels of the page tables
+ * because we want to avoid inserting EFI region mappings (EFI_VA_END
+ * to EFI_VA_START) into the standard kernel page tables. Everything
+ * else can be shared, see efi_sync_low_kernel_mappings().
+ */
+int __init efi_alloc_page_tables(void)
+{
+	pgd_t *pgd;
+	pud_t *pud;
+	gfp_t gfp_mask;
+
+	if (efi_enabled(EFI_OLD_MEMMAP))
+		return 0;
+
+	gfp_mask = GFP_KERNEL | __GFP_NOTRACK | __GFP_REPEAT | __GFP_ZERO;
+	efi_pgd = (pgd_t *)__get_free_page(gfp_mask);
+	if (!efi_pgd)
+		return -ENOMEM;
+
+	pgd = efi_pgd + pgd_index(EFI_VA_END);
+
+	pud = pud_alloc_one(NULL, 0);
+	if (!pud) {
+		free_page((unsigned long)efi_pgd);
+		return -ENOMEM;
+	}
+
+	pgd_populate(NULL, pgd, pud);
+
+	return 0;
+}
+
 /*
  * Add low kernel mappings for passing arguments to EFI functions.
  */
@@ -128,6 +164,9 @@ void efi_sync_low_kernel_mappings(void)
 {
 	unsigned num_pgds;
 	pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
+	unsigned num_entries;
+	pgd_t *pgd_k, *pgd_efi;
+	pud_t *pud_k, *pud_efi;
 
 	if (efi_enabled(EFI_OLD_MEMMAP))
 		return;
@@ -137,6 +176,46 @@ void efi_sync_low_kernel_mappings(void)
 	memcpy(pgd + pgd_index(PAGE_OFFSET),
 		init_mm.pgd + pgd_index(PAGE_OFFSET),
 		sizeof(pgd_t) * num_pgds);
+
+	/*
+	 * We can share all PGD entries apart from the one entry that
+	 * covers the EFI runtime mapping space.
+	 *
+	 * Make sure the EFI runtime region mappings are guaranteed to
+	 * only span a single PGD entry and that the entry also maps
+	 * other important kernel regions.
+	 */
+	BUILD_BUG_ON(pgd_index(EFI_VA_END) != pgd_index(MODULES_END));
+	BUILD_BUG_ON((EFI_VA_START & PGDIR_MASK) !=
+			(EFI_VA_END & PGDIR_MASK));
+
+	pgd_efi = efi_pgd + pgd_index(PAGE_OFFSET);
+	pgd_k = pgd_offset_k(PAGE_OFFSET);
+
+	num_entries = pgd_index(EFI_VA_END) - pgd_index(PAGE_OFFSET);
+	memcpy(pgd_efi, pgd_k, sizeof(pgd_t) * num_entries);
+
+	/*
+	 * We share all the PUD entries apart from those that map the
+	 * EFI regions. Copy around them.
+	 */
+	BUILD_BUG_ON((EFI_VA_START & ~PUD_MASK) != 0);
+	BUILD_BUG_ON((EFI_VA_END & ~PUD_MASK) != 0);
+
+	pgd_efi = efi_pgd + pgd_index(EFI_VA_END);
+	pud_efi = pud_offset(pgd_efi, 0);
+
+	pgd_k = pgd_offset_k(EFI_VA_END);
+	pud_k = pud_offset(pgd_k, 0);
+
+	num_entries = pud_index(EFI_VA_END);
+	memcpy(pud_efi, pud_k, sizeof(pud_t) * num_entries);
+
+	pud_efi = pud_offset(pgd_efi, EFI_VA_START);
+	pud_k = pud_offset(pgd_k, EFI_VA_START);
+
+	num_entries = PTRS_PER_PUD - pud_index(EFI_VA_START);
+	memcpy(pud_efi, pud_k, sizeof(pud_t) * num_entries);
 }
 
 int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
@@ -337,6 +416,7 @@ void __init efi_dump_pagetable(void)
 	pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
 
 	ptdump_walk_pgd_level(NULL, pgd);
+	ptdump_walk_pgd_level(NULL, efi_pgd);
 #endif
 }
 

[toc] | [prev] | [next] | [standalone]

#1311624

On Sun, 17 Jan, at 11:02:48PM, Srikar Dronamraju wrote:
> 
> Unfortunately even with your below patch on top of c9f2a9a ("x86/efi:
> Hoist page table switching code into efi_call_virt()" also fails to boot
> with and without CONFIG_DEBUG_WX=y. I have added CONFIG_EFI_PGT_DUMP.

What about if you comment out the call to efi_dump_pagetable()? What
if you return early from efi_sync_low_kernel_mappings(), e.g.

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 71121a9d06cf..e1f8ebb88f84 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -177,6 +177,8 @@ void efi_sync_low_kernel_mappings(void)
 		init_mm.pgd + pgd_index(PAGE_OFFSET),
 		sizeof(pgd_t) * num_pgds);
 
+	return;
+
 	/*
 	 * We can share all PGD entries apart from the one entry that
 	 * covers the EFI runtime mapping space.

Do either of those modifications make your kernel boot when you apply
the patch I sent on Friday? If so, which one? I'm struggling to find
hardware that's similar enough to reproduce this.

[toc] | [prev] | [next] | [standalone]

#1312341

On Tue, 19 Jan, at 04:17:15PM, Srikar Dronamraju wrote:
> * Matt Fleming <matt@codeblueprint.co.uk> [2016-01-18 15:40:01]:
> 
> > On Sun, 17 Jan, at 11:02:48PM, Srikar Dronamraju wrote:
> > > 
> > > Unfortunately even with your below patch on top of c9f2a9a ("x86/efi:
> > > Hoist page table switching code into efi_call_virt()" also fails to boot
> > > with and without CONFIG_DEBUG_WX=y. I have added CONFIG_EFI_PGT_DUMP.
> > 
> > What about if you comment out the call to efi_dump_pagetable()? What
> > if you return early from efi_sync_low_kernel_mappings(), e.g.
> 
> This doesnt help but ....
> 
> > 
> > diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
> > index 71121a9d06cf..e1f8ebb88f84 100644
> > --- a/arch/x86/platform/efi/efi_64.c
> > +++ b/arch/x86/platform/efi/efi_64.c
> > @@ -177,6 +177,8 @@ void efi_sync_low_kernel_mappings(void)
> >  		init_mm.pgd + pgd_index(PAGE_OFFSET),
> >  		sizeof(pgd_t) * num_pgds);
> > 
> > +	return;
> > +
> 
> This alone makes it boot. dmesg below
> 
> i.e git checkout tip/x86/efi
> +
> git am <your patch> + <the above fixlet>
> 

OK could you add efi=debug to your kernel cmdline and try this patch
instead of the one that returns early from
efi_sync_low_kernel_mappings()?

I also pushed out all the changes to the following branch if that's
easier to pull and build,

  https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=bug/efi/srikar

I have no idea why any of these entries would be empty, but this is
the only thing I can imagine could go wrong with this code,

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 71121a9d06cf..9b610aa17683 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -192,6 +192,9 @@ void efi_sync_low_kernel_mappings(void)
 	pgd_efi = efi_pgd + pgd_index(PAGE_OFFSET);
 	pgd_k = pgd_offset_k(PAGE_OFFSET);
 
+	if (WARN_ON_ONCE(pgd_none(*pgd_efi) || pgd_none(*pgd_k)))
+		return;
+
 	num_entries = pgd_index(EFI_VA_END) - pgd_index(PAGE_OFFSET);
 	memcpy(pgd_efi, pgd_k, sizeof(pgd_t) * num_entries);
 
@@ -203,17 +206,26 @@ void efi_sync_low_kernel_mappings(void)
 	BUILD_BUG_ON((EFI_VA_END & ~PUD_MASK) != 0);
 
 	pgd_efi = efi_pgd + pgd_index(EFI_VA_END);
-	pud_efi = pud_offset(pgd_efi, 0);
-
 	pgd_k = pgd_offset_k(EFI_VA_END);
+
+	if (WARN_ON_ONCE(pgd_none(*pgd_efi) || pgd_none(*pgd_k)))
+		return;
+
+	pud_efi = pud_offset(pgd_efi, 0);
 	pud_k = pud_offset(pgd_k, 0);
 
+	if (WARN_ON_ONCE(pud_none(*pud_efi) || pud_none(*pud_k)))
+		return;
+
 	num_entries = pud_index(EFI_VA_END);
 	memcpy(pud_efi, pud_k, sizeof(pud_t) * num_entries);
 
 	pud_efi = pud_offset(pgd_efi, EFI_VA_START);
 	pud_k = pud_offset(pgd_k, EFI_VA_START);
 
+	if (WARN_ON_ONCE(pud_none(*pud_efi) || pud_none(*pud_k)))
+		return;
+
 	num_entries = PTRS_PER_PUD - pud_index(EFI_VA_START);
 	memcpy(pud_efi, pud_k, sizeof(pud_t) * num_entries);
 }

[toc] | [prev] | [next] | [standalone]

#1312428

> 
> OK could you add efi=debug to your kernel cmdline and try this patch
> instead of the one that returns early from
> efi_sync_low_kernel_mappings()?
> 
> I also pushed out all the changes to the following branch if that's
> easier to pull and build,
> 
>   https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=bug/efi/srikar

Thanks,  This kernel again goes back to the previous state i.e I cant
boot with this changes applied.

-- 
Thanks and Regards
Srikar Dronamraju

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web