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: <95a0d1dd-bcce-76c7-97b9-8374c9913321@google.com>
Date:   Tue, 5 Apr 2022 12:59:41 -0700 (PDT)
From:   Hugh Dickins <hughd@...gle.com>
To:     Patrice CHOTARD <patrice.chotard@...s.st.com>
cc:     hughd@...gle.com, 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

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, 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.

Hugh