Re: [PATCH v1 0/3] setfiles: control relabeling parallelism from the environment

On Tue, Aug 18, 2026 at 3:23 PM jboero <[email protected]> wrote:
>
> From: Johnny Boero <[email protected]>
>
> Hi,
>
> This is the patch for the RFE at
> https://github.com/SELinuxProject/selinux/issues/489, where a package
> upgrade on an 88 core machine spent hours in restorecon with 87 cores
> idle.  Stephen Smalley and Christian Göttsche both indicated on the
> issue that switching the default thread count to 0 would be acceptable;
> patch 2 does that, and patch 3 adds the environment variable the RFE
> originally asked for.
>
> Patches 2 and 3 are independent and either can be taken without the
> other.
>
> Patch 1 is a small fix noticed while touching the same code: "-T -1" is
> currently accepted by strtoull(3) and wraps around to SIZE_MAX threads
> instead of producing a usage error.
>
> Patch 2 changes the setfiles(8)/restorecon(8) default from 1 thread to 0,
> i.e. one thread per available CPU core.  Only the tools change; the
> selinux_restorecon_parallel(3) default is untouched, so library callers
> are unaffected.
>
> Patch 3 adds RESTORECON_THREADS, with the same meaning as -T, which takes
> precedence.  The motivation is reach: relabeling is driven from package
> scriptlets and init scripts that a user cannot edit.  On the Fedora 44
> system used for testing, 10 installed packages run restorecon from their
> scriptlets and none of them pass -T, so the environment is the only way
> to influence them without patching every spec file in the distribution.
> An invalid value warns and is ignored rather than being fatal, since the
> variable is inherited by every child process.
>
> Measured with a dry run relabel of /usr/share (~588k files) on an 88 core
> system:
>
>   -T 1 / RESTORECON_THREADS=1   ~24s, 99% CPU
>   default after this series     ~16s, ~1000% CPU
>
> The speedup here is bounded by the directory walk and the syscall mix of
> a dry run; a real relabel that writes contexts benefits more.
>
> Two things I would like feedback on:
>
> - Whether RESTORECON_THREADS is the right name, given the same binary is
>   also setfiles(8).

I think that is as good a name as any.

> - Whether an invalid value should warn and continue, as it does here, or
>   be fatal.

I think continuing is safer as you noted since this could be inherited
across multiple fork/exec's and
isn't part of the environment that is sanitized by libc. That said,
I'm not sure patch 3 is even
necessary once we take the first two.

>
> Note that this series does not reach libsemanage, which calls
> selinux_restorecon(3) single threaded on the policy store, or rpm's
> selinux plugin, which labels each file inline with lsetfilecon(3) and
> never goes through restorecon at all.  Both looked out of scope here.
>
> Johnny Boero (3):
>   policycoreutils/setfiles: reject invalid -T arguments
>   policycoreutils/setfiles: use all CPU cores by default
>   policycoreutils/setfiles: honor RESTORECON_THREADS
>
>  policycoreutils/setfiles/restorecon.8 | 19 +++++++++--
>  policycoreutils/setfiles/setfiles.8   | 20 +++++++++--
>  policycoreutils/setfiles/setfiles.c   | 48 ++++++++++++++++++++++++---
>  3 files changed, 79 insertions(+), 8 deletions(-)
>
> --
> 2.55.0
>