Merge ^/head r340427 through r340868.

fork: remove avoidable proc lock/unlock pair

We don't have to access the process after making it runnable, so there
is no need to hold it either.

Sponsored by: The FreeBSD Foundation

call racct_proc_ucred_changed() under the proc lock

The lock is required to ensure that the switch to the new credentials
and the transfer of the process's accounting data from the old
credentials t

call racct_proc_ucred_changed() under the proc lock

The lock is required to ensure that the switch to the new credentials
and the transfer of the process's accounting data from the old
credentials to the new ones is done atomically. Otherwise, some updates
may be applied to the new credentials and then additionally transferred
from the old credentials if the updates happen after proc_set_cred() and
before racct_proc_ucred_changed().

The problem is especially pronounced for RACCT_RSS because
- there is a strict accounting for this resource (it's reclaimable)
- it's updated asynchronously by the vm daemon
- it's updated by setting an absolute value instead of applying a delta

I had to remove a call to rctl_proc_ucred_changed() from
racct_proc_ucred_changed() and make all callers of latter call the
former as well. The reason is that rctl_proc_ucred_changed, as it is
implemented now, cannot be called while holding the proc lock, so the
lock is dropped after calling racct_proc_ucred_changed. Additionally,
I've added calls to crhold / crfree around the rctl call, because
without the proc lock there is no gurantee that the new credentials,
owned by the process, will stay stable. That does not eliminate a
possibility that the credentials passed to the rctl will get stale.
Ideally, rctl_proc_ucred_changed should be able to work under the proc
lock.

Many thanks to kib for pointing out the above problems.

PR: 222027
Discussed with: kib
No comment: trasz
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D15048

show more ...

sys/kern: adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone

sys/kern: adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

show more ...

Merge ^/head r313644 through r313895.

try to fix RACCT_RSS accounting

There could be a race between the vm daemon setting RACCT_RSS based on
the vm space and vmspace_exit (called from exit1) resetting RACCT_RSS to
zero. In that case we

try to fix RACCT_RSS accounting

There could be a race between the vm daemon setting RACCT_RSS based on
the vm space and vmspace_exit (called from exit1) resetting RACCT_RSS to
zero. In that case we can get a zombie process with non-zero RACCT_RSS.
If the process is jailed, that may break accounting for the jail.
There could be other consequences.

Fix this race in the vm daemon by updating RACCT_RSS only when a process
is in the normal state. Also, make accounting a little bit more
accurate by refreshing the page resident count after calling
vm_pageout_map_deactivate_pages().
Finally, add an assert that the RSS is zero when a process is reaped.

PR: 210315
Reviewed by: trasz
Differential Revision: https://reviews.freebsd.org/D9464

show more ...

MFhead@r313243

Merge ^/head r312309 through r312623.

Remove redundant KASSERT.

Get rid of rctl_lock; use racct_lock where appropriate. The fast paths
already required both of them, so having a separate rctl_lock didn't
buy us anything.

Reviewed by: mjg@
MFC after: 1 month
Spon

Get rid of rctl_lock; use racct_lock where appropriate. The fast paths
already required both of them, so having a separate rctl_lock didn't
buy us anything.

Reviewed by: mjg@
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D5914

show more ...

MFH

Sponsored by: The FreeBSD Foundation

Allocate RACCT/RCTL zones without UMA_ZONE_NOFREE; no idea why it was there
in the first place.

MFC after: 1 month
Sponsored by: The FreeBSD Foundation

Sort variable declarations.

MFC after: 1 month
Sponsored by: The FreeBSD Foundation

MFH

Sponsored by: The FreeBSD Foundation

Add four new RCTL resources - readbps, readiops, writebps and writeiops,
for limiting disk (actually filesystem) IO.

Note that in some cases these limits are not quite precise. It's ok,
as long as i

Add four new RCTL resources - readbps, readiops, writebps and writeiops,
for limiting disk (actually filesystem) IO.

Note that in some cases these limits are not quite precise. It's ok,
as long as it's within some reasonable bounds.

Testing - and review of the code, in particular the VFS and VM parts - is
very welcome.

MFC after: 1 month
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D5080

show more ...

MFH

Sponsored by: The FreeBSD Foundation

Use proper locking macros in RACCT in RCTL.

MFC after: 1 month
Sponsored by: The FreeBSD Foundation

MFH

Sponsored by: The FreeBSD Foundation

Fix mismerge.

MFC after: 1 month
Sponsored by: The FreeBSD Foundation

Drop the 'resource' argument to racct_decay(); it wouldn't make sense
to iterate separately for each resource.

MFC after: 1 month
Sponsored by: The FreeBSD Foundation

Call rctl_enforce() in all cases the resource usage goes up, even when called
from racct_*_force() functions. It makes the "log" and "devctl" actions work
in those cases.

MFC after: 1 month
Sponsor

Call rctl_enforce() in all cases the resource usage goes up, even when called
from racct_*_force() functions. It makes the "log" and "devctl" actions work
in those cases.

MFC after: 1 month
Sponsored by: The FreeBSD Foundation

show more ...

Reorder the functions; no functional changes.

MFC after: 1 month
Sponsored by: The FreeBSD Foundation

Reduce code duplication.

MFC after: 1 month
Sponsored by: The FreeBSD Foundation

Reduce code duplication. There should be no (intended) functional changes.

MFC after: 1 month
Sponsored by: The FreeBSD Foundation

Merge ^/head r295351 through r295543.