linux-ext4 - Re: riscv32 EXT4 splat, 6.8 regression?

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20240417200617.2f54bc7b@namcao>
Date: Wed, 17 Apr 2024 20:06:17 +0200
From: Nam Cao <namcao@...utronix.de>
To: "Theodore Ts'o" <tytso@....edu>
Cc: Mike Rapoport <rppt@...nel.org>, Matthew Wilcox <willy@...radead.org>,
 Björn Töpel <bjorn@...nel.org>, Christian Brauner
 <brauner@...nel.org>, Andreas Dilger <adilger@...ger.ca>, Al Viro
 <viro@...iv.linux.org.uk>, linux-fsdevel <linux-fsdevel@...r.kernel.org>,
 Jan Kara <jack@...e.cz>, Linux Kernel Mailing List
 <linux-kernel@...r.kernel.org>, linux-riscv@...ts.infradead.org, Ext4
 Developers List <linux-ext4@...r.kernel.org>, Conor Dooley
 <conor@...nel.org>, Anders Roxell <anders.roxell@...aro.org>, Alexandre
 Ghiti <alex@...ti.fr>
Subject: Re: riscv32 EXT4 splat, 6.8 regression?

On 2024-04-17 Theodore Ts'o wrote:
> On Wed, Apr 17, 2024 at 12:36:39AM +0200, Nam Cao wrote:
> > 
> > However, I am confused about one thing: doesn't this make one page of
> > physical memory inaccessible?  
> 
> So are these riscv32 systems really having multiple terabytes of
> memory?  Why is this page in the physical memory map in the first
> place?

It's 32 bit, so it doesn't take much to fill up the entire address space.

Here's the memory layout from kernel boot log:

[    0.000000] Virtual kernel memory layout:
[    0.000000]       fixmap : 0x9c800000 - 0x9d000000   (8192 kB)
[    0.000000]       pci io : 0x9d000000 - 0x9e000000   (  16 MB)
[    0.000000]      vmemmap : 0x9e000000 - 0xa0000000   (  32 MB)
[    0.000000]      vmalloc : 0xa0000000 - 0xc0000000   ( 512 MB)
[    0.000000]       lowmem : 0xc0000000 - 0x00000000   (1024 MB)

Note that lowmem occupies the last 1GB, including ERR_PTR (the last
address wraps to zero)

Best regards,
Nam