Page MenuHomeFreeBSD

vm_map.c: plug several more places which might modify entry->offset
ClosedPublic

Authored by kib on Aug 15 2023, 8:52 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Mar 28, 3:23 AM
Unknown Object (File)
Thu, Mar 26, 1:09 AM
Unknown Object (File)
Tue, Mar 24, 1:30 PM
Unknown Object (File)
Tue, Mar 17, 10:28 PM
Unknown Object (File)
Jan 25 2026, 12:35 AM
Unknown Object (File)
Jan 24 2026, 8:34 PM
Unknown Object (File)
Jan 21 2026, 5:00 AM
Unknown Object (File)
Nov 18 2025, 3:55 AM
Subscribers

Diff Detail

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

Event Timeline

kib requested review of this revision.Aug 15 2023, 8:52 PM
sys/vm/vm_map.c
1418

Have you tested this change with INVARIANTS set?

It seems that if you don't change root->offset, then you'll have two elements overlap, and that will violate invariants.

sys/vm/vm_map.c
1418

Peter is doing the full test right now. offset is overloaded for stack gap entries, this is the main point of the change.

Are you saying that overloading entry->offset cannot work in principle?

sys/vm/vm_map.c
1418

No, I'm not saying that. I withdraw my question.

Where is the overloading of entry->offset documented?

sys/vm/vm_map.c
1418

The comment above the struct vm_map_entry definition in vm_map.h, and duplicated in vm_map_stack_locked() in the KERN_SUCCESS branch of the last if().

Does the second loop in vm_map_sync() also need a check for stack guards?

Does the second loop in vm_map_sync() also need a check for stack guards?

vm_object_reference()/dereference()/sync() all accept and do nothing if passed obj is NULL.

sys/vm/vm_map.c
1466

Do you need a check here?

sys/vm/vm_map.c
1466

I do not believe so because stack guards are not merge-able. I can add assert.

This revision is now accepted and ready to land.Aug 16 2023, 8:04 PM