- madvise
The sysadmin gently encourages the use of THP, but it is only
enabled when explicitly requested by the application.
And this "user mode" or "manual mode", where applications self-manage
which parts of userspace they want to enroll.
Both madvise() and unprivileged prctl() should work here as well,
IMO. There is no policy or security difference between them, it's just
about granularity and usability.
- never
The sysadmin discourages the use of THP, and "its use is only permitted
with explicit approval" .
This one I don't quite agree with, and IMO conflicts with what David
is saying as well.
"never" so far means "no thps, no exceptions". We've had serious THP
issues in the past, where our workaround until we sorted out the issue
for affected customers was to force-disable THPs on that system during boot.
Right, that reflects the current behavior. What we aim to enhance is
by adding the requirement that "its use is only permitted with
explicit approval."
I think you're conflating a safety issue with a security issue.
David is saying there can be cases where the kernel is broken, and
"never" is a production escape hatch to disable the feature until a
kernel upgrade for the fix is possible. In such a case, it doesn't
make sense to override this decision based on any sort of workload
policy, privileged or not.
The way I understand you is that you want enrollment (and/or
self-management) only for blessed applications. Because you don't
generally trust workloads in the wild enough to switch the global
default away from "never", given the semantics of always/madvise.