Add a sysctl to fetch virtual address space layout info
ClosedPublic
Actions

Authored by markj on Dec 31 2021, 3:14 PM.

Details

Reviewers

Commits

rG6393594b0362: copyin tests: Use the KERN_PROC_VM_LAYOUT sysctl to fetch layout info
rG3ce04aca49e9: proc: Add a sysctl to fetch virtual address space layout info

Summary

Use it to implement some logic in the kern_copyin test (rather than
assuming that PS_STRINGS is fixed by the ABI).

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 43660
Build 40548: arc lint + arc unit

Event Timeline

markj created this revision.Dec 31 2021, 3:14 PM

Herald added a subscriber: imp. · View Herald TranscriptDec 31 2021, 3:14 PM

markj requested review of this revision.Dec 31 2021, 3:14 PM

Harbormaster completed remote builds in B43660: Diff 100788.Dec 31 2021, 3:14 PM

markj mentioned this in D33702: libc: Let elf_aux_info() handle AT_KPRELOAD.Dec 31 2021, 3:14 PM

kib added inline comments.Dec 31 2021, 5:17 PM

sys/sys/user.h
605	I think it would be useful to pack all the information from struct vm_map and struct vmspace, which is potentially useful to userspace, into this kinfo. For instance, all non-kernel flags from vm_map->flags, event though they are available by proccontrol, could be usefully reported there. All vm_Xsize and vm_Xaddr should be exported as well. I think it is debatable but worth considering anon_loc and vm_stkgap (the later depends on the outcome of the stackgap rework, to be discussed in other place).

Please bump __FreeBSD_version for this change.

I have a use case for qemu-user for this, and am quite keen on knowing the whole address space, not just kvm_max_user_address (though that would be useful). Linux exports a set of ranges that are mapped that is used to find a 'hole' big enough for the guest.

hmmm, I could do the stuff I need in qemu w/o a version bump and it would likely be better in case this is MFC'd

In D33708#762020, @imp wrote:

Please bump __FreeBSD_version for this change.

I have a use case for qemu-user for this, and am quite keen on knowing the whole address space, not just kvm_max_user_address (though that would be useful). Linux exports a set of ranges that are mapped that is used to find a 'hole' big enough for the guest.

Isn't this already available via KERN_PROC_VMMAP? What information do you need, exactly?

In D33708#762054, @markj wrote:

In D33708#762020, @imp wrote:

Please bump __FreeBSD_version for this change.

I have a use case for qemu-user for this, and am quite keen on knowing the whole address space, not just kvm_max_user_address (though that would be useful). Linux exports a set of ranges that are mapped that is used to find a 'hole' big enough for the guest.

Isn't this already available via KERN_PROC_VMMAP? What information do you need, exactly?

I'll have to look at that. I think that may be what I need.

Export more fields.

Harbormaster completed remote builds in B43904: Diff 101420.Jan 13 2022, 4:42 PM

What about exporting pmap pm_stats as well?

sys/kern/kern_proc.c
3234	Why not do vm_map_min()/max() instead? sv_*user are only templates, and e.g. map_at_zero changes vm_map_min().
3243	I do not like the tie of the kernel-internal flags to the sysctl output, it moves them into ABI. IMO it should be the dedicated flags, translated.

In D33708#766133, @kib wrote:

What about exporting pmap pm_stats as well?

It seems rather orthogonal to the purpose of this sysctl, which exposes static information. The resident count can be obtained already in kinfo_proc.

sys/kern/kern_proc.c
3260	I copied the handling of 32-bit procs from sysctl_kern_proc_sigfastblk(), but this munging is ugly. Perhaps the compat32 fields should be defined as uint64_t instead, or the native kinfo_vm_layout definition should use uint64_t everywhere.