Page MenuHomeFreeBSD

amd64: fix physmap entry addition logic
ClosedPublic

Authored by vexeduxr on Jul 5 2025, 8:43 PM.
Tags
None
Referenced Files
F139156253: D51173.diff
Mon, Dec 8, 4:39 PM
Unknown Object (File)
Sat, Dec 6, 7:53 PM
Unknown Object (File)
Fri, Nov 28, 5:15 AM
Unknown Object (File)
Nov 5 2025, 3:15 AM
Unknown Object (File)
Nov 3 2025, 3:46 AM
Unknown Object (File)
Oct 30 2025, 1:06 AM
Unknown Object (File)
Oct 29 2025, 8:21 AM
Unknown Object (File)
Oct 25 2025, 8:42 PM
Subscribers

Details

Summary

Since physmap_idx points to the next slot, we should make sure both 'i'
and 'insert_idx' are less than physmap_idx, but never equal to it.

Also allow physmap_idx to reach PHYS_AVAIL_ENTRIES so the last slot can
be populated.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kib added inline comments.
sys/amd64/amd64/machdep.c
679

Then would it make sense to move this operation down even more, after the 'move' loop, so that i initialization does not need to '-2'?

This revision is now accepted and ready to land.Jul 6 2025, 1:23 PM
sys/amd64/amd64/machdep.c
679

Ah, yes it would.

Move physmap_idx addition further down

This revision now requires review to proceed.Jul 6 2025, 5:32 PM
This revision is now accepted and ready to land.Jul 6 2025, 5:49 PM
sys/amd64/amd64/machdep.c
673

This statement also needs an adjustment, otherwise when we hit the limit by adding the entry, we still move entries. It should be physmap_idx == PHYL_AVAIL_ENTRIES - 2 (right hand is const).

sys/amd64/amd64/machdep.c
673

I don't think I follow. if physmap_idx is PHYL_AVAIL_ENTRIES - 2, then we still have a free pair.

kib added inline comments.
sys/amd64/amd64/machdep.c
673

Right, sorry.

This revision was automatically updated to reflect the committed changes.