Page MenuHomeFreeBSD

riscv: Handle four-level page tables in various pmap traversal routines
ClosedPublic

Authored by markj on Feb 14 2022, 10:31 PM.
Tags
None
Referenced Files
Unknown Object (File)
Apr 7 2024, 11:28 PM
Unknown Object (File)
Mar 29 2024, 4:10 PM
Unknown Object (File)
Jan 14 2024, 7:40 AM
Unknown Object (File)
Dec 20 2023, 3:36 AM
Unknown Object (File)
Nov 30 2023, 3:56 AM
Unknown Object (File)
Nov 30 2023, 3:56 AM
Unknown Object (File)
Nov 30 2023, 3:52 AM
Unknown Object (File)
Nov 30 2023, 3:36 AM
Subscribers

Diff Detail

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

Event Timeline

This revision is now accepted and ready to land.Feb 15 2022, 12:14 AM

I think pmap_change_attr_locked needs changing otherwise you'll fault rather than return EINVAL for bogus VAs that aren't covered by an L0 entry? The function doesn't currently do anything other than exist for LKPI and do a no-op walk in order to give back the right errors.

I think pmap_change_attr_locked needs changing otherwise you'll fault rather than return EINVAL for bogus VAs that aren't covered by an L0 entry? The function doesn't currently do anything other than exist for LKPI and do a no-op walk in order to give back the right errors.

Hmm, I don't see why we'd fault - pmap_l1() will return NULL in that case (see D34276) and pmap_change_attr_locked() handles that by returning EINVAL.

I think pmap_change_attr_locked needs changing otherwise you'll fault rather than return EINVAL for bogus VAs that aren't covered by an L0 entry? The function doesn't currently do anything other than exist for LKPI and do a no-op walk in order to give back the right errors.

Hmm, I don't see why we'd fault - pmap_l1() will return NULL in that case (see D34276) and pmap_change_attr_locked() handles that by returning EINVAL.

Hm, indeed, misremembered how those work. I guess you only need to do the walk explicitly if you care about distinguishing !V from !RX, i.e. if you expect to have L0 leaves, which we don't.