linux-kernel - Re: Regression with v5.18-rc1 tag on STM32F7 and STM32H7 based boards

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: <30882dc7-c187-9d7c-726e-117a22dca4e9@foss.st.com>
Date:   Wed, 6 Apr 2022 08:20:35 +0200
From:   Patrice CHOTARD <patrice.chotard@...s.st.com>
To:     Hugh Dickins <hughd@...gle.com>
CC:     <mpatocka@...hat.com>, <lczerner@...hat.com>, <djwong@...nel.org>,
        <hch@....de>, <zkabelac@...hat.com>, <miklos@...redi.hu>,
        <bp@...e.de>, <akpm@...ux-foundation.org>,
        Alexandre TORGUE - foss <alexandre.torgue@...s.st.com>,
        Valentin CARON - foss <valentin.caron@...s.st.com>,
        <linux-stm32@...md-mailman.stormreply.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        <linux-fsdevel@...r.kernel.org>, <linux-mm@...ck.org>
Subject: Re: Regression with v5.18-rc1 tag on STM32F7 and STM32H7 based boards

Hi Hugh

On 4/5/22 21:59, Hugh Dickins wrote:
> On Tue, 5 Apr 2022, Patrice CHOTARD wrote:
>>
>> We found an issue with last kernel tag v5.18-rc1 on stm32f746-disco and 
>> stm32h743-disco boards (ARMV7-M SoCs).
>>
>> Kernel hangs when executing SetPageUptodate(ZERO_PAGE(0)); in mm/filemap.c.
>>
>> By reverting commit 56a8c8eb1eaf ("tmpfs: do not allocate pages on read"), 
>> kernel boots without any issue.
> 
> Sorry about that, thanks a lot for finding.
> 
> I see that arch/arm/configs/stm32_defconfig says CONFIG_MMU is not set:
> please confirm that is the case here.

Yes i confirm, CONFIG_MMU is not set.



> 
> Yes, it looks as if NOMMU platforms are liable to have a bogus (that's my
> reading, but it may be unfair) definition for ZERO_PAGE(vaddr), and I was
> walking on ice to touch it without regard for !CONFIG_MMU.
> 
> CONFIG_SHMEM depends on CONFIG_MMU, so that PageUptodate is only needed
> when CONFIG_MMU.
> 
> Easily fixed by an #ifdef CONFIG_MMU there in mm/filemap.c, but I'll hunt
> around (again) for a better place to do it - though I won't want to touch
> all the architectures for it.  I'll post later today.

I did a quick test on my side, and yes, adding #ifdef CONFIG_MMU around 
SetPageUptodate(ZERO_PAGE(0)); allows to boot the boards.

Thanks
Patrice
> 
> Hugh