Page MenuHomeFreeBSD

amd64: fix physmap entry addition logic
ClosedPublic

Authored by vexeduxr on Jul 5 2025, 8:43 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Apr 6, 9:28 AM
Unknown Object (File)
Mon, Apr 6, 3:58 AM
Unknown Object (File)
Thu, Apr 2, 1:38 PM
Unknown Object (File)
Thu, Apr 2, 4:48 AM
Unknown Object (File)
Mon, Mar 23, 9:09 PM
Unknown Object (File)
Sun, Mar 15, 4:16 AM
Unknown Object (File)
Sat, Mar 14, 7:35 PM
Unknown Object (File)
Mar 8 2026, 6:30 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.