Received-SPF: pass (google.com: domain of linux-kernel+bounces-85273-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Wed, 28 Feb 2024 15:37:30 +0000
From: Conor Dooley <conor@kernel.org>
To: Samuel Holland <samuel.holland@sifive.com>
Cc: Conor Dooley <conor.dooley@microchip.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] riscv: Fix loading 64-bit NOMMU kernels past the
 start of RAM
Message-ID: <20240228-cavity-aground-d1e8072a2c0d@spud>
References: <20240227003630.3634533-1-samuel.holland@sifive.com>
 <20240227003630.3634533-3-samuel.holland@sifive.com>
 <20240227-unfitting-rectangle-cd0f23a4f3f1@wendy>
 <9673cbe7-41ec-4261-9be8-fc5191ade56c@sifive.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="29t4/8GEDLrsNf/T"
Content-Disposition: inline
In-Reply-To: <9673cbe7-41ec-4261-9be8-fc5191ade56c@sifive.com>


--29t4/8GEDLrsNf/T
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 27, 2024 at 01:22:12PM -0600, Samuel Holland wrote:
> Hi Conor,
>=20
> On 2024-02-27 6:18 AM, Conor Dooley wrote:
> > On Mon, Feb 26, 2024 at 04:34:47PM -0800, Samuel Holland wrote:
> >> commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear
> >> mapping") added logic to allow using RAM below the kernel load address.
> >> However, this does not work for NOMMU, where PAGE_OFFSET is fixed to t=
he
> >> kernel load address. Since that range of memory corresponds to PFNs
> >> below ARCH_PFN_OFFSET, mm initialization runs off the beginning of
> >> mem_map and corrupts adjacent kernel memory. Fix this by restoring the
> >> previous behavior for NOMMU kernels.
> >>
> >> Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapp=
ing")
> >=20
> > This commit was a year ago, why has nobody reported this as being an
> > issue before?
>=20
> I can think of a few reasons:
> 1) NOMMU users are likely to be using RV32, which is not affected.
> 2) Before patch 4 of this series, NOMMU implied M-mode, so there was noth=
ing in
> the way to prevent loading Linux at the very beginning of RAM. (U-Boot/SPL
> relocates itself to the end of RAM, so it would not cause a problem.)
> 3) Platforms where RAM does not begin at exactly 0x80000000 would be affe=
cted,
> there are several workarounds: change the start of RAM (for soft cores), =
change
> PAGE_OFFSET, or change the memory ranges in the devicetree to exclude any=
thing
> below PAGE_OFFSET.
>=20
> It's possible that nobody was affected, but it's still technically a regr=
ession
> (a hypothetical platform with RAM from 0x40000000 to 0xc0000000 would cra=
sh
> instead of only being able to use half its RAM), so I thought it still de=
served
> the Fixes: tag.

Right, thanks for explaining.

Cheers,
Conor.

--29t4/8GEDLrsNf/T
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZd9TOgAKCRB4tDGHoIJi
0vk6AP0TSxofF/mXzet5PRaY+C3fUEgn0adwntRDThmt24rOkwD9Gvlsb3xwmGcN
f0hJY0qds2ScDTzQXUVTxVY6hE0krQ0=
=oZgb
-----END PGP SIGNATURE-----

--29t4/8GEDLrsNf/T--