Page MenuHomeFreeBSD

amd64: fix physmap entry addition logic
ClosedPublic

Authored by vexeduxr on Jul 5 2025, 8:43 PM.
Tags
None
Referenced Files
F144372304: D51173.id158059.diff
Sun, Feb 8, 2:42 AM
F144365897: D51173.id158054.diff
Sun, Feb 8, 2:00 AM
Unknown Object (File)
Sat, Feb 7, 4:10 PM
Unknown Object (File)
Sat, Jan 31, 1:35 PM
Unknown Object (File)
Thu, Jan 29, 1:12 PM
Unknown Object (File)
Tue, Jan 13, 4:37 AM
Unknown Object (File)
Jan 1 2026, 1:12 AM
Unknown Object (File)
Dec 14 2025, 12:29 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.