linux-kernel - Re: kernelci/staging-next bisection: sleep.login on rk3288-rock2-square #2286-staging

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]

Message-ID: <20210103134753.GC832698@linux.ibm.com>
Date:   Sun, 3 Jan 2021 15:47:53 +0200
From:   Mike Rapoport <rppt@...ux.ibm.com>
To:     Guillaume Tucker <guillaume.tucker@...labora.com>
Cc:     Andrea Arcangeli <aarcange@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        kernelci-results-staging@...ups.io,
        "kernelci-results@...ups.io" <kernelci-results@...ups.io>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Mike Rapoport <rppt@...nel.org>, Baoquan He <bhe@...hat.com>
Subject: Re: kernelci/staging-next bisection: sleep.login on
 rk3288-rock2-square #2286-staging

On Fri, Dec 18, 2020 at 09:59:26PM +0000, Guillaume Tucker wrote:
> On 13/12/2020 08:23, Mike Rapoport wrote:
> > Hi Guillaume,
> > 
> > On Fri, Dec 11, 2020 at 09:53:46PM +0000, Guillaume Tucker wrote:
> >> Hi Mike,
> >>
> 
> OK, sorry for the delay.  I've built a kernel and booted it as
> you requested, and also found that the issue was due to this
> memory area defined in arch/arm/boot/dts/rk3288.dtsi:
> 
>         reserved-memory {
>                 #address-cells = <2>;
>                 #size-cells = <2>;
>                 ranges;
> 
>                 /*
>                  * The rk3288 cannot use the memory area above 0xfe000000
>                  * for dma operations for some reason. While there is
>                  * probably a better solution available somewhere, we
>                  * haven't found it yet and while devices with 2GB of ram
>                  * are not affected, this issue prevents 4GB from booting.
>                  * So to make these devices at least bootable, block
>                  * this area for the time being until the real solution
>                  * is found.
>                  */
>                 dma-unusable@...00000 {
>                         reg = <0x0 0xfe000000 0x0 0x1000000>;
>                 };
>         };
> 
> So I've put a hack[1] on top of 950c37691925 to skip adding a
> node in memblock_enforce_memory_reserved_overlap() if the base
> address is 0xfe000000, which got the kernel booting.  Here's the
> console log:
> 
>   https://people.collabora.com/~gtucker/tmp/2966825.txt
> 
> and the full test job details, if this helps:
> 
>   https://lava.collabora.co.uk/scheduler/job/2966825
> 
> 
> I haven't really looked much further than that, but I'll be
> available on Monday to help run other tests if needed.

Sorry for the delay, I was mostly offline for the last three weeks.

Thanks for the logs, it seems that implicitly adding reserved regions to
memblock.memory wasn't that bright idea :)
 
> Thanks,
> Guillaume
> 
> [1] https://people.collabora.com/~gtucker/tmp/2966825.patch

-- 
Sincerely yours,
Mike.