[PATCH v3] m68k: Fix memblock-related crashes

[PATCH v3] m68k: Fix memblock-related crashes

[Geert Uytterhoeven]

When running the kernel in Fast RAM on Atari:

    Ignoring memory chunk at 0x0:0xe00000 before the first chunk
    ...
    Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
    Oops: 00000000
    Modules linked in:
    PC: [<0069dbac>] free_all_bootmem+0x12c/0x186
    SR: 2714  SP: (ptrval)  a2: 005e3314
    d0: 00000000    d1: 0000000a    d2: 00000e00    d3: 00000000
    d4: 005e1fc0    d5: 0000001a    a0: 01000000    a1: 00000000
    Process swapper (pid: 0, task=(ptrval))
    Frame format=7 eff addr=00000736 ssw=0505 faddr=00000736
    wb 1 stat/addr/data: 0000 00000000 00000000
    wb 2 stat/addr/data: 0000 00000000 00000000
    wb 3 stat/addr/data: 0000 00000736 00000000
    push data: 00000000 00000000 00000000 00000000
    Stack from 005e1f84:
            00000000 0000000a 027d3260 006b5006 00000000 00000000 00000000 00000000
            0004f062 0003a220 0069e272 005e1ff8 0000054c 00000000 00e00000 00000000
            00000001 00693cd8 027d3260 0004f062 0003a220 00691be6 00000000 00000000
            00000000 00000000 00000000 00000000 006b5006 00000000 00690872
    Call Trace: [<0004f062>] printk+0x0/0x18
     [<0003a220>] parse_args+0x0/0x2d4
     [<0069e272>] memblock_virt_alloc_try_nid+0x0/0xa4
     [<00693cd8>] mem_init+0xa/0x5c
     [<0004f062>] printk+0x0/0x18
     [<0003a220>] parse_args+0x0/0x2d4
     [<00691be6>] start_kernel+0x1ca/0x462
     [<00690872>] _sinittext+0x872/0x11f8
    Code: 7a1a eaae 2270 6db0 0061 ef14 2f01 2f03 <96a9> 0736 2203 e589 d681 e78b d6a9 0732 2f03 2f40 0034 4eb9 0069 b8d0 260e 4fef
    Disabling lock debugging due to kernel taint
    Kernel panic - not syncing: Attempted to kill the idle task!

As the kernel must run in the memory chunk with the lowest address,
ST-RAM is ignored, and removed from the m68k_memory[] array.
However, it is not removed from memblock, causing a crash later.

More investigation shows that there are 3 places where memory chunks are
ignored, all after the calls to memblock_add() in m68k_parse_bootinfo(),
and thus causing crashes:
  1. On classic m68k CPUs with a MMU, paging_init() ignores all memory
     chunks below the first chunk, cfr. above,
  2. On Amigas equipped with a Zorro III bus, config_amiga() ignores all
     Zorro II memory,
  3. If CONFIG_SINGLE_MEMORY_CHUNK=y, m68k_parse_bootinfo() ignores all
     but the first memory chunk.

Fix this by moving the calls to memblock_add() from
m68k_parse_bootinfo() to paging_init(), after all ignored memory chunks
have been removed from m68k_memory[].

Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Fixes: 1008a11590b966b4 ("m68k: switch to MEMBLOCK + NO_BOOTMEM")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
As all 3 cases involve ignoring memory chunks, thus not requiring real
memory present in the ignored chunks, I managed to test all 3 cases on
my Amiga 4000 by using a memfile describing nonexistent memory in the
Zorro II or 32-bit address space, below system RAM.

Sun-3 must be broken before this fix, as it fills in m68k_memory[0] in
config_sun3(), i.e. after m68k_parse_bootinfo().
Sun-3 is not fixed by this fix, as it uses its own paging_init(), not
the one in motorola.c.
Fixing Sun-3 requires adding memblock_add()/memblock_reserve() calls to
the Sun-3 memory management code.

v3:
  - Move memblock_add() after memory block removal instead of sprinkling
    memblock_remove() all over the place,
  - Remove Suggested-by, Tested-by.

v2:
  - Add missing #include <linux/memblock.h>.
---
 arch/m68k/kernel/setup_mm.c | 2 --
 arch/m68k/mm/motorola.c     | 2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index a1a3eaeaf58c960d..ad0195cbe04255ea 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -164,8 +164,6 @@ static void __init m68k_parse_bootinfo(const struct bi_record *record)
 					be32_to_cpu(m->addr);
 				m68k_memory[m68k_num_memory].size =
 					be32_to_cpu(m->size);
-				memblock_add(m68k_memory[m68k_num_memory].addr,
-					     m68k_memory[m68k_num_memory].size);
 				m68k_num_memory++;
 			} else
 				pr_warn("%s: too many memory chunks\n",
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index 7497cf30bf1cd41b..3f3d0bf360910c0d 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -228,6 +228,7 @@ void __init paging_init(void)
 
 	min_addr = m68k_memory[0].addr;
 	max_addr = min_addr + m68k_memory[0].size;
+	memblock_add(m68k_memory[0].addr, m68k_memory[0].size);
 	for (i = 1; i < m68k_num_memory;) {
 		if (m68k_memory[i].addr < min_addr) {
 			printk("Ignoring memory chunk at 0x%lx:0x%lx before the first chunk\n",
@@ -238,6 +239,7 @@ void __init paging_init(void)
 				(m68k_num_memory - i) * sizeof(struct m68k_mem_info));
 			continue;
 		}
+		memblock_add(m68k_memory[i].addr, m68k_memory[i].size);
 		addr = m68k_memory[i].addr + m68k_memory[i].size;
 		if (addr > max_addr)
 			max_addr = addr;
-- 
2.17.1

Re: [PATCH v3] m68k: Fix memblock-related crashes

[Mike Rapoport]

On Fri, Dec 07, 2018 at 05:50:11PM +0100, Geert Uytterhoeven wrote:
> When running the kernel in Fast RAM on Atari:
> 
>     Ignoring memory chunk at 0x0:0xe00000 before the first chunk
>     ...
>     Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
>     Oops: 00000000
>     Modules linked in:
>     PC: [<0069dbac>] free_all_bootmem+0x12c/0x186
>     SR: 2714  SP: (ptrval)  a2: 005e3314
>     d0: 00000000    d1: 0000000a    d2: 00000e00    d3: 00000000
>     d4: 005e1fc0    d5: 0000001a    a0: 01000000    a1: 00000000
>     Process swapper (pid: 0, task=(ptrval))
>     Frame format=7 eff addr=00000736 ssw=0505 faddr=00000736
>     wb 1 stat/addr/data: 0000 00000000 00000000
>     wb 2 stat/addr/data: 0000 00000000 00000000
>     wb 3 stat/addr/data: 0000 00000736 00000000
>     push data: 00000000 00000000 00000000 00000000
>     Stack from 005e1f84:
>             00000000 0000000a 027d3260 006b5006 00000000 00000000 00000000 00000000
>             0004f062 0003a220 0069e272 005e1ff8 0000054c 00000000 00e00000 00000000
>             00000001 00693cd8 027d3260 0004f062 0003a220 00691be6 00000000 00000000
>             00000000 00000000 00000000 00000000 006b5006 00000000 00690872
>     Call Trace: [<0004f062>] printk+0x0/0x18
>      [<0003a220>] parse_args+0x0/0x2d4
>      [<0069e272>] memblock_virt_alloc_try_nid+0x0/0xa4
>      [<00693cd8>] mem_init+0xa/0x5c
>      [<0004f062>] printk+0x0/0x18
>      [<0003a220>] parse_args+0x0/0x2d4
>      [<00691be6>] start_kernel+0x1ca/0x462
>      [<00690872>] _sinittext+0x872/0x11f8
>     Code: 7a1a eaae 2270 6db0 0061 ef14 2f01 2f03 <96a9> 0736 2203 e589 d681 e78b d6a9 0732 2f03 2f40 0034 4eb9 0069 b8d0 260e 4fef
>     Disabling lock debugging due to kernel taint
>     Kernel panic - not syncing: Attempted to kill the idle task!
> 
> As the kernel must run in the memory chunk with the lowest address,
> ST-RAM is ignored, and removed from the m68k_memory[] array.
> However, it is not removed from memblock, causing a crash later.
> 
> More investigation shows that there are 3 places where memory chunks are
> ignored, all after the calls to memblock_add() in m68k_parse_bootinfo(),
> and thus causing crashes:
>   1. On classic m68k CPUs with a MMU, paging_init() ignores all memory
>      chunks below the first chunk, cfr. above,
>   2. On Amigas equipped with a Zorro III bus, config_amiga() ignores all
>      Zorro II memory,
>   3. If CONFIG_SINGLE_MEMORY_CHUNK=y, m68k_parse_bootinfo() ignores all
>      but the first memory chunk.
> 
> Fix this by moving the calls to memblock_add() from
> m68k_parse_bootinfo() to paging_init(), after all ignored memory chunks
> have been removed from m68k_memory[].
> 
> Reported-by: Andreas Schwab <schwab@linux-m68k.org>
> Fixes: 1008a11590b966b4 ("m68k: switch to MEMBLOCK + NO_BOOTMEM")
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> As all 3 cases involve ignoring memory chunks, thus not requiring real
> memory present in the ignored chunks, I managed to test all 3 cases on
> my Amiga 4000 by using a memfile describing nonexistent memory in the
> Zorro II or 32-bit address space, below system RAM.
> 
> Sun-3 must be broken before this fix, as it fills in m68k_memory[0] in
> config_sun3(), i.e. after m68k_parse_bootinfo().
> Sun-3 is not fixed by this fix, as it uses its own paging_init(), not
> the one in motorola.c.
> Fixing Sun-3 requires adding memblock_add()/memblock_reserve() calls to
> the Sun-3 memory management code.

I think that adding memblock_add() to config_sun3 would be sufficient,
something like the diff below. This will make memblock aware of the
available physical memory and it seems there no allocations in sun3 before
paging_init().

diff --git a/arch/m68k/sun3/config.c b/arch/m68k/sun3/config.c
index 542c440..9a5b9dd 100644
--- a/arch/m68k/sun3/config.c
+++ b/arch/m68k/sun3/config.c
@@ -150,6 +150,7 @@ void __init config_sun3(void)
 
 	m68k_num_memory=1;
         m68k_memory[0].size=*(romvec->pv_sun3mem);
+	memblock_add(memory_start, memory_end - memory_start);
 
 	sun3_bootmem_alloc(memory_start, memory_end);
 }
 
> v3:
>   - Move memblock_add() after memory block removal instead of sprinkling
>     memblock_remove() all over the place,
>   - Remove Suggested-by, Tested-by.
> 
> v2:
>   - Add missing #include <linux/memblock.h>.
> ---
>  arch/m68k/kernel/setup_mm.c | 2 --
>  arch/m68k/mm/motorola.c     | 2 ++
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
> index a1a3eaeaf58c960d..ad0195cbe04255ea 100644
> --- a/arch/m68k/kernel/setup_mm.c
> +++ b/arch/m68k/kernel/setup_mm.c
> @@ -164,8 +164,6 @@ static void __init m68k_parse_bootinfo(const struct bi_record *record)
>  					be32_to_cpu(m->addr);
>  				m68k_memory[m68k_num_memory].size =
>  					be32_to_cpu(m->size);
> -				memblock_add(m68k_memory[m68k_num_memory].addr,
> -					     m68k_memory[m68k_num_memory].size);
>  				m68k_num_memory++;
>  			} else
>  				pr_warn("%s: too many memory chunks\n",
> diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
> index 7497cf30bf1cd41b..3f3d0bf360910c0d 100644
> --- a/arch/m68k/mm/motorola.c
> +++ b/arch/m68k/mm/motorola.c
> @@ -228,6 +228,7 @@ void __init paging_init(void)
>  
>  	min_addr = m68k_memory[0].addr;
>  	max_addr = min_addr + m68k_memory[0].size;
> +	memblock_add(m68k_memory[0].addr, m68k_memory[0].size);
>  	for (i = 1; i < m68k_num_memory;) {
>  		if (m68k_memory[i].addr < min_addr) {
>  			printk("Ignoring memory chunk at 0x%lx:0x%lx before the first chunk\n",
> @@ -238,6 +239,7 @@ void __init paging_init(void)
>  				(m68k_num_memory - i) * sizeof(struct m68k_mem_info));
>  			continue;
>  		}
> +		memblock_add(m68k_memory[i].addr, m68k_memory[i].size);
>  		addr = m68k_memory[i].addr + m68k_memory[i].size;
>  		if (addr > max_addr)
>  			max_addr = addr;
> -- 
> 2.17.1
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH v3] m68k: Fix memblock-related crashes

[Geert Uytterhoeven]

Hi Mike,

On Fri, Dec 7, 2018 at 10:02 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> On Fri, Dec 07, 2018 at 05:50:11PM +0100, Geert Uytterhoeven wrote:
> > Sun-3 must be broken before this fix, as it fills in m68k_memory[0] in
> > config_sun3(), i.e. after m68k_parse_bootinfo().
> > Sun-3 is not fixed by this fix, as it uses its own paging_init(), not
> > the one in motorola.c.
> > Fixing Sun-3 requires adding memblock_add()/memblock_reserve() calls to
> > the Sun-3 memory management code.
>
> I think that adding memblock_add() to config_sun3 would be sufficient,
> something like the diff below. This will make memblock aware of the
> available physical memory and it seems there no allocations in sun3 before
> paging_init().
>
> diff --git a/arch/m68k/sun3/config.c b/arch/m68k/sun3/config.c
> index 542c440..9a5b9dd 100644
> --- a/arch/m68k/sun3/config.c
> +++ b/arch/m68k/sun3/config.c
> @@ -150,6 +150,7 @@ void __init config_sun3(void)
>
>         m68k_num_memory=1;
>          m68k_memory[0].size=*(romvec->pv_sun3mem);
> +       memblock_add(memory_start, memory_end - memory_start);
>
>         sun3_bootmem_alloc(memory_start, memory_end);
>  }

Thanks!

It doesn't need a memblock_reserve() for the kernel, as memory_start is
already adjusted for that, right?

Anyone who can test this is on Sun-3? Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v3] m68k: Fix memblock-related crashes

[John Paul Adrian Glaubitz]

Hi Geert!

On 12/8/18 11:51 AM, Geert Uytterhoeven wrote:
> Anyone who can test this is on Sun-3? Thanks!

Theoretically, I can. I have three Sun-3 boxes but I haven't set them
up for booting a kernel yet. If I manage to find a quick guide for
getting started, I might be able to fire up a test machine.

Could maybe someone build me a test kernel so I can just focus on setting
up the machine and its bootserver?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH v3] m68k: Fix memblock-related crashes

[Mike Rapoport]

On Sat, Dec 08, 2018 at 11:51:38AM +0100, Geert Uytterhoeven wrote:
> Hi Mike,
> 
> On Fri, Dec 7, 2018 at 10:02 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> > On Fri, Dec 07, 2018 at 05:50:11PM +0100, Geert Uytterhoeven wrote:
> > > Sun-3 must be broken before this fix, as it fills in m68k_memory[0] in
> > > config_sun3(), i.e. after m68k_parse_bootinfo().
> > > Sun-3 is not fixed by this fix, as it uses its own paging_init(), not
> > > the one in motorola.c.
> > > Fixing Sun-3 requires adding memblock_add()/memblock_reserve() calls to
> > > the Sun-3 memory management code.
> >
> > I think that adding memblock_add() to config_sun3 would be sufficient,
> > something like the diff below. This will make memblock aware of the
> > available physical memory and it seems there no allocations in sun3 before
> > paging_init().
> >
> > diff --git a/arch/m68k/sun3/config.c b/arch/m68k/sun3/config.c
> > index 542c440..9a5b9dd 100644
> > --- a/arch/m68k/sun3/config.c
> > +++ b/arch/m68k/sun3/config.c
> > @@ -150,6 +150,7 @@ void __init config_sun3(void)
> >
> >         m68k_num_memory=1;
> >          m68k_memory[0].size=*(romvec->pv_sun3mem);
> > +       memblock_add(memory_start, memory_end - memory_start);
> >
> >         sun3_bootmem_alloc(memory_start, memory_end);
> >  }
> 
> Thanks!
> 
> It doesn't need a memblock_reserve() for the kernel, as memory_start is
> already adjusted for that, right?

Yes, unless I've missed something.
 
> Anyone who can test this is on Sun-3? Thanks!
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH v3] m68k: Fix memblock-related crashes

[Geert Uytterhoeven]

Hi Andreas,

On Fri, Dec 7, 2018 at 5:50 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> When running the kernel in Fast RAM on Atari:
>
>     Ignoring memory chunk at 0x0:0xe00000 before the first chunk
>     ...
>     Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
>     Oops: 00000000
>     Modules linked in:
>     PC: [<0069dbac>] free_all_bootmem+0x12c/0x186
>     SR: 2714  SP: (ptrval)  a2: 005e3314
>     d0: 00000000    d1: 0000000a    d2: 00000e00    d3: 00000000
>     d4: 005e1fc0    d5: 0000001a    a0: 01000000    a1: 00000000
>     Process swapper (pid: 0, task=(ptrval))
>     Frame format=7 eff addr=00000736 ssw=0505 faddr=00000736
>     wb 1 stat/addr/data: 0000 00000000 00000000
>     wb 2 stat/addr/data: 0000 00000000 00000000
>     wb 3 stat/addr/data: 0000 00000736 00000000
>     push data: 00000000 00000000 00000000 00000000
>     Stack from 005e1f84:
>             00000000 0000000a 027d3260 006b5006 00000000 00000000 00000000 00000000
>             0004f062 0003a220 0069e272 005e1ff8 0000054c 00000000 00e00000 00000000
>             00000001 00693cd8 027d3260 0004f062 0003a220 00691be6 00000000 00000000
>             00000000 00000000 00000000 00000000 006b5006 00000000 00690872
>     Call Trace: [<0004f062>] printk+0x0/0x18
>      [<0003a220>] parse_args+0x0/0x2d4
>      [<0069e272>] memblock_virt_alloc_try_nid+0x0/0xa4
>      [<00693cd8>] mem_init+0xa/0x5c
>      [<0004f062>] printk+0x0/0x18
>      [<0003a220>] parse_args+0x0/0x2d4
>      [<00691be6>] start_kernel+0x1ca/0x462
>      [<00690872>] _sinittext+0x872/0x11f8
>     Code: 7a1a eaae 2270 6db0 0061 ef14 2f01 2f03 <96a9> 0736 2203 e589 d681 e78b d6a9 0732 2f03 2f40 0034 4eb9 0069 b8d0 260e 4fef
>     Disabling lock debugging due to kernel taint
>     Kernel panic - not syncing: Attempted to kill the idle task!
>
> As the kernel must run in the memory chunk with the lowest address,
> ST-RAM is ignored, and removed from the m68k_memory[] array.
> However, it is not removed from memblock, causing a crash later.
>
> More investigation shows that there are 3 places where memory chunks are
> ignored, all after the calls to memblock_add() in m68k_parse_bootinfo(),
> and thus causing crashes:
>   1. On classic m68k CPUs with a MMU, paging_init() ignores all memory
>      chunks below the first chunk, cfr. above,
>   2. On Amigas equipped with a Zorro III bus, config_amiga() ignores all
>      Zorro II memory,
>   3. If CONFIG_SINGLE_MEMORY_CHUNK=y, m68k_parse_bootinfo() ignores all
>      but the first memory chunk.
>
> Fix this by moving the calls to memblock_add() from
> m68k_parse_bootinfo() to paging_init(), after all ignored memory chunks
> have been removed from m68k_memory[].
>
> Reported-by: Andreas Schwab <schwab@linux-m68k.org>
> Fixes: 1008a11590b966b4 ("m68k: switch to MEMBLOCK + NO_BOOTMEM")
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

Does this patch fix your crash?

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v3] m68k: Fix memblock-related crashes

[Andreas Schwab]

I'm now getting this Oops:

[   65.390000] Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
[   65.390000] Oops: 00000000
[   65.390000] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat virtio_rng virtio_blk virtio_ring virtio xfs btrfs xor zlib_deflate raid6_pq libcrc32c reiserfs squashfs fuse dm_snapshot dm_bufio dm_mod binfmt_misc loop sg
[   65.390000] PC: [<00211544>] blk_throtl_bio+0x10e/0x592
[   65.390000] SR: 2700  SP: (ptrval)  a2: bf506dc0
[   65.390000] d0: 00000001    d1: 03ce63fb    d2: 00000000    d3: 00000016
[   65.390000] d4: ffffa45b    d5: 00000000    a0: 00000000    a1: 00000000
[   65.390000] Process mkswap (pid: 289, task=(ptrval))
[   65.390000] Frame format=7 eff addr=00000060 ssw=0505 faddr=00000060
[   65.390000] wb 1 stat/addr/data: 0000 00000000 00000000
[   65.390000] wb 2 stat/addr/data: 0000 00000000 00000000
[   65.390000] wb 3 stat/addr/data: 0000 00000060 0001dba1
[   65.390000] push data: 00000000 00000000 00000000 00000000
[   65.390000] Stack from bd1b7bdc:
[   65.390000]         00000008 00080000 ffffffff 00000002 ffffffff 00000006 bd6e0b40 bf596c18
[   65.390000]         00682988 bd1b7c78 006000c0 00000003 00000000 00000080 00000005 001f28e4
[   65.390000]         bf596c18 bf4f1800 bd6e0b40 00000008 00080000 00000000 00001000 000a1848
[   65.390000]         00000001 bd6e0b40 bf596c18 bd1b7e24 00080000 00000008 bf4f1800 bf596c18
[   65.390000]         bd1b7e24 bd1b7cec 00000001 bd1b7d3a 00095c52 0010ce96 000a1848 bd1b7cec
[   65.390000]         001f3ea8 bd6e0b40 00000008 00080000 00000000 bd6e0b40 027616cc bd1b7e24
[   65.390000] Call Trace: [<00080000>] check_ids+0x8/0x64
[   65.390000]  [<001f28e4>] generic_make_request_checks+0x3ca/0x4ee
[   65.390000]  [<00080000>] check_ids+0x8/0x64
[   65.390000]  [<00001000>] kernel_pg_dir+0x0/0x1000
[   65.390000]  [<000a1848>] __put_page+0x0/0x32
[   65.390000]  [<00080000>] check_ids+0x8/0x64
[   65.390000]  [<00095c52>] add_to_page_cache_lru+0x0/0xc4
[   65.390000]  [<0010ce96>] do_mpage_readpage+0x0/0x5cc
[   65.390000]  [<000a1848>] __put_page+0x0/0x32
[   65.390000]  [<001f3ea8>] generic_make_request+0x32/0x23c
[   65.390000]  [<00080000>] check_ids+0x8/0x64
[   65.390000]  [<001f417c>] submit_bio+0xca/0xfc
[   65.390000]  [<00095c52>] add_to_page_cache_lru+0x0/0xc4
[   65.390000]  [<0010ce96>] do_mpage_readpage+0x0/0x5cc
[   65.390000]  [<00095c52>] add_to_page_cache_lru+0x0/0xc4
[   65.390000]  [<0010ce96>] do_mpage_readpage+0x0/0x5cc
[   65.390000]  [<000a1848>] __put_page+0x0/0x32
[   65.390000]  [<0010ce8a>] mpage_bio_submit+0x2e/0x3a
[   65.390000]  [<0010d55a>] mpage_readpages+0xf8/0x108
[   65.390000]  [<00080000>] check_ids+0x8/0x64
[   65.390000]  [<00433256>] radix_tree_lookup+0x0/0x1a
[   65.390000]  [<0000bd6e>] rtc_ioctl+0x10c/0x2ae
[   65.390000]  [<00010100>] sixty_four+0x2/0x10
[   65.390000]  [<00001000>] kernel_pg_dir+0x0/0x1000
[   65.390000]  [<00107370>] blkdev_get_block+0x0/0x30
[   65.390000]  [<000a0eb4>] read_pages+0x3c/0xe6
[   65.390000]  [<00107370>] blkdev_get_block+0x0/0x30
[   65.390000]  [<0003ffff>] _sched_setscheduler+0x47/0x7e
[   65.390000]  [<00433256>] radix_tree_lookup+0x0/0x1a
[   65.390000]  [<0009cd42>] __alloc_pages_nodemask+0x0/0x86a
[   65.390000]  [<000a1188>] __do_page_cache_readahead+0x92/0x13e
[   65.390000]  [<000a10f6>] __do_page_cache_readahead+0x0/0x13e
[   65.390000]  [<000a1558>] force_page_cache_readahead+0x94/0xa2
[   65.390000]  [<000a1848>] __put_page+0x0/0x32
[   65.390000]  [<00096316>] unlock_page+0x0/0x2a
[   65.390000]  [<000970f4>] generic_file_buffered_read+0x11e/0x64a
[   65.390000]  [<000986f4>] generic_file_read_iter+0x100/0x132
[   65.390000]  [<000e0246>] __vfs_read+0x116/0x150
[   65.390000]  [<00020000>] _FP_CALL_TOP+0x9a46/0xd512
[   65.390000]  [<000e02dc>] vfs_read+0x5c/0xe4
[   65.390000]  [<000e0766>] ksys_read+0x42/0x8a
[   65.390000]  [<000e07c0>] sys_read+0x12/0x18
[   65.390000]  [<00002934>] syscall+0x8/0xc
[   65.390000]  [<0000c016>] bvme6000_gettimeoffset+0xaa/0xe2
[   65.390000] Code: 2d20 012a 2839 005f 5124 226b 0014 7001 <b0a9> 0060 6600 0210 4a29 0064 6700 0208 4a8b 6700 0294 2053 2068 0014 2028 002c

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH v3] m68k: Fix memblock-related crashes

[Andreas Schwab]

On Dez 13 2018, Andreas Schwab <schwab@linux-m68k.org> wrote:

> I'm now getting this Oops:
>
> [   65.390000] Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
> [   65.390000] Oops: 00000000
> [   65.390000] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat virtio_rng virtio_blk virtio_ring virtio xfs btrfs xor zlib_deflate raid6_pq libcrc32c reiserfs squashfs fuse dm_snapshot dm_bufio dm_mod binfmt_misc loop sg
> [   65.390000] PC: [<00211544>] blk_throtl_bio+0x10e/0x592

And the crash does not occur when I revert commit 1008a11590.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH v3] m68k: Fix memblock-related crashes

[Andreas Schwab]

On Dez 17 2018, Andreas Schwab <schwab@linux-m68k.org> wrote:

> On Dez 13 2018, Andreas Schwab <schwab@linux-m68k.org> wrote:
>
>> I'm now getting this Oops:
>>
>> [   65.390000] Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
>> [   65.390000] Oops: 00000000
>> [   65.390000] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat virtio_rng virtio_blk virtio_ring virtio xfs btrfs xor zlib_deflate raid6_pq libcrc32c reiserfs squashfs fuse dm_snapshot dm_bufio dm_mod binfmt_misc loop sg
>> [   65.390000] PC: [<00211544>] blk_throtl_bio+0x10e/0x592
>
> And the crash does not occur when I revert commit 1008a11590.

That is not true, so this is an unrelated bug.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH v3] m68k: Fix memblock-related crashes

[Geert Uytterhoeven]

Hi Andreas,

On Mon, Dec 17, 2018 at 8:34 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Dez 17 2018, Andreas Schwab <schwab@linux-m68k.org> wrote:
> > On Dez 13 2018, Andreas Schwab <schwab@linux-m68k.org> wrote:
> >> I'm now getting this Oops:
> >>
> >> [   65.390000] Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
> >> [   65.390000] Oops: 00000000
> >> [   65.390000] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat virtio_rng virtio_blk virtio_ring virtio xfs btrfs xor zlib_deflate raid6_pq libcrc32c reiserfs squashfs fuse dm_snapshot dm_bufio dm_mod binfmt_misc loop sg
> >> [   65.390000] PC: [<00211544>] blk_throtl_bio+0x10e/0x592
> >
> > And the crash does not occur when I revert commit 1008a11590.
>
> That is not true, so this is an unrelated bug.

Thank you.

So I'll queue my patch as a late fix for v4.20.
Sun-3 can be fixed when someone can test Mike's suggestion.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds