linux-kernel - Re: [PATCH 1/2] m68k: nommu: register start of the memory with memblock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 30 Jun 2020 00:03:08 +1000
From:   Greg Ungerer <gerg@...ux-m68k.org>
To:     Mike Rapoport <rppt@...nel.org>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org,
        Mike Rapoport <rppt@...ux.ibm.com>
Subject: Re: [PATCH 1/2] m68k: nommu: register start of the memory with
 memblock

Hi Mike,

On 29/6/20 2:14 pm, Mike Rapoport wrote:
> On Mon, Jun 29, 2020 at 11:10:16AM +1000, Greg Ungerer wrote:
>> On 17/6/20 10:33 pm, Greg Ungerer wrote:
>>> On 17/6/20 4:53 pm, Mike Rapoport wrote:
>>>> From: Mike Rapoport <rppt@...ux.ibm.com>
>>>>
>>>> The m68k nommu setup code didn't register the beginning of the physical
>>>> memory with memblock because it was anyway occupied by the kernel. However,
>>>> commit fa3354e4ea39 ("mm: free_area_init: use maximal zone PFNs rather than
>>>> zone sizes") changed zones initialization to use memblock.memory to detect
>>>> the zone extents and this caused inconsistency between zone PFNs and the
>>>> actual PFNs:
>>>>
>>>> BUG: Bad page state in process swapper  pfn:20165
>>>> page:41fe0ca0 refcount:0 mapcount:1 mapping:00000000 index:0x0 flags: 0x0()
>>>> raw: 00000000 00000100 00000122 00000000 00000000 00000000 00000000 00000000
>>>> page dumped because: nonzero mapcount
>>>> CPU: 0 PID: 1 Comm: swapper Not tainted 5.8.0-rc1-00001-g3a38f8a60c65-dirty #1
>>>> Stack from 404c9ebc:
>>>>           404c9ebc 4029ab28 4029ab28 40088470 41fe0ca0 40299e21 40299df1 404ba2a4
>>>>           00020165 00000000 41fd2c10 402c7ba0 41fd2c04 40088504 41fe0ca0 40299e21
>>>>           00000000 40088a12 41fe0ca0 41fe0ca4 0000020a 00000000 00000001 402ca000
>>>>           00000000 41fe0ca0 41fd2c10 41fd2c10 00000000 00000000 402b2388 00000001
>>>>           400a0934 40091056 404c9f44 404c9f44 40088db4 402c7ba0 00000001 41fd2c04
>>>>           41fe0ca0 41fd2000 41fe0ca0 40089e02 4026ecf4 40089e4e 41fe0ca0 ffffffff
>>>> Call Trace:
>>>>           [<40088470>] 0x40088470
>>>>    [<40088504>] 0x40088504
>>>>    [<40088a12>] 0x40088a12
>>>>    [<402ca000>] 0x402ca000
>>>>    [<400a0934>] 0x400a0934
>>>>
>>>> Adjust the memory registration with memblock to include the beginning of
>>>> the physical memory and make sure that the area occupied by the kernel is
>>>> marked as reserved.
>>>>
>>>> Signed-off-by: Mike Rapoport <rppt@...ux.ibm.com>
>>>
>>> Acked-by: Greg Ungerer <gerg@...ux-m68k.org>
>>
>> What path do you anticipate this taking into mainline?
>> I see it is still broken in 5.8-rc3.
> 
> I thought it will go through m68k tree.

Ok, no worries, I will push them through.
I have pushed into the for-next and for-linus branches of the m68knommu
git tree to get the ball rolling.

Regards
Greg



>>>> ---
>>>>    arch/m68k/kernel/setup_no.c | 3 ++-
>>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
>>>> index e779b19e0193..f66f4b1d062e 100644
>>>> --- a/arch/m68k/kernel/setup_no.c
>>>> +++ b/arch/m68k/kernel/setup_no.c
>>>> @@ -138,7 +138,8 @@ void __init setup_arch(char **cmdline_p)
>>>>        pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ",
>>>>             __bss_stop, memory_start, memory_start, memory_end);
>>>> -    memblock_add(memory_start, memory_end - memory_start);
>>>> +    memblock_add(_rambase, memory_end - _rambase);
>>>> +    memblock_reserve(_rambase, memory_start - _rambase);
>>>>        /* Keep a copy of command line */
>>>>        *cmdline_p = &command_line[0];
>>>>
>