linux-kernel - Re: [PATCH 0/3] Highmem support for 32-bit RISC-V

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 4 May 2020 13:27:31 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     afzal mohammed <afzal.mohd.ma@...il.com>
Cc:     Russell King <linux@...linux.org.uk>,
        Alan Kao <alankao@...estech.com>,
        Eric Lin <tesheng@...estech.com>, Gary Guo <gary@...yguo.net>,
        alex@...ti.fr, David Abdurachmanov <david.abdurachmanov@...il.com>,
        Anup Patel <Anup.Patel@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Steven Price <steven.price@....com>, atish.patra@....com,
        yash.shah@...ive.com, Albert Ou <aou@...s.berkeley.edu>,
        Palmer Dabbelt <palmer@...belt.com>,
        Greentime Hu <green.hu@...il.com>, zong.li@...ive.com,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...e.de>,
        Logan Gunthorpe <logang@...tatee.com>,
        linux-riscv@...ts.infradead.org,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 0/3] Highmem support for 32-bit RISC-V

On Mon, May 4, 2020 at 11:10 AM afzal mohammed <afzal.mohd.ma@...il.com> wrote:
>
> [ +linux-arm-kernel
>
>   Context: This is regarding VMSPLIT_4G_4G support for 32-bit ARM as a
>   possible replacement to highmem. For that, initially, it is being
>   attempted to move static kernel mapping from lowmem to vmalloc space.
>
>   in next reply, i will remove everyone/list !ARM related ]
>
> Hi,
>
> On Sun, May 03, 2020 at 10:20:39PM +0200, Arnd Bergmann wrote:
>
> > Which SoC platform are you running this on? Just making
> > sure that this won't conflict with static mappings later.
>
> Versatile Express V2P-CA15 on qemu, qemu options include --smp 2 &
> 2GB memory.

Ok

> BTW, i could not convince myself why, except for DEBUG_LL, static io
> mappings are used.

I don't think vexpress uses it, but others have some 'struct map_desc'
instances mostly for historic reasons, e.g. to map some registers that
are needed at very early boot time, or from assembler files.

> > One problem I see immediately in arm_memblock_init()
>
> Earlier it went past arm_memblock_init(), issue was clearing the page
> tables from VMALLOC_START in devicemaps_init() thr' paging_init(),
> which was like cutting the sitting branch of the tree.
>
> Now it is crashing at debug_ll_io_init() of devicemap_init(), and
> printascii/earlycon was & is being used to debug :). Things are going
> wrong when it tries to create mapping for debug_ll. It looks like a
> conflict with static mapping, which you mentioned above, at the same
> time i am not seeing kernel static mapping in the same virtual
> address, need to dig deeper.
>
> Also tried removing DEBUG_LL, there is a deafening silence in the
> console ;)

I don't think there is any other mapping that would conflict with the
DEBUG_LL one, but you may be in a hole where the existing one
is not mapped. IIRC it first gets mapped in __create_page_tables()
in arch/arm/kernel/head.S, and later in debug_ll_io_init(), but if the
old page tables were just discarded, it won't work for a bit.

Using gdb to step through the code in qemu is often more reliable
than printing to the console, at least until you get to the point
when you have registered the real console.

> __virt_to_phys_nodebug() which does the actual work on __pa() invocation
> has been modifed to handle that case (ideas lifted from ARM64's
> implementation), though currently it is a hack as below (and applicable
> only for ARM_PATCH_PHYS_VIRT disabled case), other hacks being
> VMALLOC_OFFSET set to 0 and adjusting vmalloc size.
>
>         static inline phys_addr_t __virt_to_phys_nodebug(unsigned long x)
>         {
>                 phys_addr_t __x = (phys_addr_t)x;
>
>                 if (__x >= 0xf0000000)
>                         return __x - KIMAGE_OFFSET + PHYS_OFFSET;
>                 else
>                         return __x - PAGE_OFFSET + PHYS_OFFSET;
>         }

Ok, makes sense.

     Arnd