On 07/19/22 21:21, Richard W.M. Jones wrote: > On Fri, Jul 15, 2022 at 05:42:35PM -0400, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/SELinux_Parallel_Autorelabel >> >> This document represents a proposed Change. As part of the Changes >> process, proposals are publicly announced in order to receive >> community feedback. This proposal will only be implemented if approved >> by the Fedora Engineering Steering Committee. >> >> >> == Summary == >> After a system's SELinux mode is switched from disabled to enabled, or >> after an administrator runs `fixfiles onboot`, SELinux autorelabel >> will be run in parallel by default. >> >> == Owner == >> * Name: [[User:plautrba| Petr Lautrbach]] >> * Email: plautrba@xxxxxxxxxx >> >> >> == Detailed Description == >> SELinux tools `restorecon` and `fixfiles` recently gained the ability >> to relabel files in parallel using the `-T nthreads` option. This >> option is currently not used in the automatic relabel after reboot. >> When users want/need the parallel relabeling they have to specify the >> option explicitly (e.g. `fixfiles -T 0 onboot`). With this change `-T >> 0` (0 == use all available CPU cores) will be the default for >> `fixfiles onboot` and users will have to use `fixfiles -T 1 onboot` to >> force it to use only one thread. >> >> The rationale is that when autorelabel runs, there are no other >> resource-intensive processes running on the system, so it's fine (and >> actually better) to use all available parallelism to speed up the task >> and get to a fully booted system faster. >> >> >> == Benefit to Fedora == >> Faster reboot after switching back to an SELinux enabled system or >> when triggering autorelabel explicitly. > [...] >> == Upgrade/compatibility impact == >> >> >> == How To Test == >> # boot with SELinux disabled - add `selinux=0` to the kernel command line >> # reboot >> # store the time it took >> # run `fixfiles -T 1 onboot` >> # reboot >> # the latter reboot should take longer time > [...] > > I wonder if we can use this in virt tools & virt-v2v: > > https://github.com/libguestfs/libguestfs/blob/master/daemon/selinux-relabel.c > > We actually use setfiles instead of fixfiles. setfiles appears to > have no -T option unfortunately. Is there a reason why setfiles > doesn't have / need this option? Upstream setfiles(8) does support the parallelized operation. When I was working on the patches for RHBZ#1794518 (-> selinux commit range d108226d3fc6..2b6f7e969cf6), the selinux library exposed two APIs: - selinux_restorecon(3) - selinux_restorecon_parallel(3) Internally, both call selinux_restorecon_common(), just with a different thread count (open-coded "1", versus forwarding "nthreads", respectively). The setfiles(8) utility had already called the newer API since commit 93902fc8340f ("setfiles/restorecon: support parallel relabeling", 2021-11-23). This commit was going to be released in selinux-3.4; Fedora 35 currently ships libselinux-3.3-1.fc35.x86_64. The latest build in Koji for Fedora 36 is only libselinux-3.3-4.fc36, too. I think we could modify libguestfs to test "setfiles" for the "-T" option -- with setfiles_has_option() --, and if it's present, pass "-T 0". However, for that to be actually useful, we'd need to start up the appliance with multiple VCPUs -- using guestfs_set_smp(). ... Apparently, virt-customize already exposes an "--smp" option for that, so we might get away with modifying libguestfs only. Thanks Laszlo _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
