Page MenuHomeFreeBSD

Split out cwd/root/jail, cmask state from filedesc table
ClosedPublic

Authored by cem on Nov 1 2020, 3:54 AM.

Details

Summary

No functional change intended.

Tracking these structures separately for each proc enables future work to
correctly emulate clone(2) in linux(4).

Test Plan

This was inspired by D27016 / enables a better version of that change.

fdcopy_remapped / fdescfree_remapped are only used by CloudABI-exclusive
routines, so I did not bother to mirror those in this change, under the
assumption that CloudABI is dead.

Corresponding lsof patch: https://reviews.freebsd.org/P456

Diff Detail

Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 34713
Build 31771: arc lint + arc unit

Event Timeline

cem requested review of this revision.Nov 1 2020, 3:54 AM

Adapt userspace (kvm, procstat) to proc change.

struct pwddesc might be a better name, since it's essentially a wrapper for a struct pwd which allows multiple processes to share the same instance. I guess we can't "just" move the struct pwd reference directly into struct proc because struct pwd is updated using a copy-on-write scheme. OTOH, the motivation for that scheme seems to be to reduce filedesc lock contention, but in this diff we have a separate lock, so maybe some simplification is possible now.

This will have to be tested against LTP and rfork flag which keeps sharing what's currently fdp. Also this introduces a problem: what should happen when you mix rfork and the new flag in existing processes?

sys/kern/kern_descrip.c
4642

any need of this to be a zone? malloc is preferred due to shared buckets

sys/sys/filedesc.h
96

this should be a mutex if possible. shared locking does not buy much here

struct pwddesc might be a better name, since it's essentially a wrapper for a struct pwd which allows multiple processes to share the same instance.

Pwd and cmask, for whatever reason.

I guess we can't "just" move the struct pwd reference directly into struct proc because struct pwd is updated using a copy-on-write scheme. OTOH, the motivation for that scheme seems to be to reduce filedesc lock contention, but in this diff we have a separate lock, so maybe some simplification is possible now.

Yeah, it can’t just be CoW or there is no sharing.

In D27037#603739, @mjg wrote:

This will have to be tested against LTP and rfork flag which keeps sharing what's currently fdp.

Sure.

Also this introduces a problem: what should happen when you mix rfork and the new flag in existing processes?

What is the problem? The new flag cannot be accessed by rfork abi.

sys/sys/filedesc.h
96

This was the existing lock style from filedesc; I did not check if it can be restricted further yet. The macros help there.

  • Mechanically rename pathsdesc to pwddesc. No functional change.
cem marked an inline comment as done.
  • Convert pwddesc lock to mutex (required shuffling chroot_refuse_vdir_fds() lock order)
sys/kern/kern_descrip.c
4642

again why the zone. malloc should be fine. file is a zone because of NOFREE, filedesc0 because of size (1080 bytes) and pwd because of SMR.

sys/sys/filedesc.h
150

Now there is no use for slock/xlock distiction, this all should be unified on lock.

sys/kern/kern_descrip.c
4642

It doesn't matter either way.

sys/sys/filedesc.h
150

Sure, I will clean that up before committing. I wanted to make sure a mutex made sense here before discarding the distinction.

cem marked 2 inline comments as done.
  • uma -> malloc
  • drop shared lock macros

Any remaining objections?

This looks fine.

However, there is a nasty little problem: someoen(tm) will have to patch lsof to handle the change. You can do it with a version bump to compile-time detect. It can be found here: https://github.com/lsof-org/lsof ; you can mail ler@ to get the patch submitted.

patch lsof to handle the change

What we really need is to add a canonical interface for lsof to use

As far as I know the kernel already exports all the necessay bits. However, making lsof use them is quite a task.

Lsof appears to use libkvm on modern FreeBSD, but not libproc. So it needs the equivalent change to procstat_getfiles_kvm() and I think that's it.

cem edited the test plan for this revision. (Show Details)
sys/kern/kern_descrip.c
4124

given that pwd is copy on write and it gets refed above, this code can drop both fdp and pdp. instead you can just grab a ref to pwd and drop the pdp lock. then the relockign inside is eliminated.

sys/kern/kern_descrip.c
4124

some of the cleanup is applicable to stock head, i'll make the changes today

kib added inline comments.
sys/kern/vfs_syscalls.c
1143

So I just remembered that this and other similar places are not broken for mt process because rfork(RFCFDG | RFFDG) single-threads.

This revision is now accepted and ready to land.Nov 13 2020, 9:12 PM

Should have been automatically closed by rS367777, but wasn't for some reason.