[PATCH -fixes 1/2] riscv: Move early dtb mapping into the fixmap region

[Conor Dooley]

On Wed, Mar 29, 2023 at 09:36:00AM +0200, Alexandre Ghiti wrote:
> On 3/27/23 12:37, Conor Dooley wrote:
> > On Thu, Mar 23, 2023 at 05:33:46PM +0100, Alexandre Ghiti wrote:

> The fix is not wrong, it is just incomplete: it fixes the issue with the
> not-existing-anymore address but introduces the problem with the possible
> allocations in the reserved regions (which you explained clearly below,
> thanks).

Which to me, makes it wrong ;) It's my own patch I'm dumping on so I
think I am best qualified to do that!

> > It would be good to mention that specifically I think, say:
> > 
> > 	riscv establishes 2 virtual mappings:
> > 
> > 	- early_pg_dir maps the kernel which allows to discover the system
> > 	  memory
> > 	- swapper_pg_dir installs the final mapping (linear mapping included)
> > 
> > 	We used to map the dtb in early_pg_dir using DTB_EARLY_BASE_VA, and this
> > 	mapping was not carried over in swapper_pg_dir. This caused problems
> > 	for reserved memory, as early_init_fdt_scan_reserved_mem() initialised
> > 	reserved_mem variables with addresses that lie in the early_pg_dir dtb
> > 	mapping. When those addresses are reused with swapper_pg_dir, this
> > 	mapping does not exist and then we trap.
> > 	The previous "fix" was incorrect as early_init_fdt_scan_reserved_mem()
> > 	must be called before swapper_pg_dir is set up otherwise we could
> > 	allocate in reserved memory defined in the dtb.
> > 
> > 	Move the dtb mapping in the fixmap region which is established in
> > 	early_pg_dir and handed over to swapper_pg_dir.
> > 
> > You need this one too:
> > Fixes: 922b0375fc93 ("riscv: Fix memblock reservation for device tree blob")
> 
> Not sure this commit is related to this fix and it's hard to find *one*
> culprit: TBH I only mentioned this one as otherwise I think the right commit
> is commit 8f3a2b4a96dc ("RISC-V: Move DT mapping outof fixmap") but that's a
> long time ago and the patch won't apply easily, not sure what to do here.

Yeah, it's hard to say.. I think the one I mentioned above should be
mentioned though, because that's what (I think) introduced the bug that
I was fixing in my commit, so if this patch is replacing my fix (which
it is) then I think it should have a super-set of the Fixes: tags in my
one.

> > Thanks for working on this,
> 
> 
> You're welcome, that was fun!

Sounds like masochism to me! ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20230329/f7860fc6/attachment.sig>