On Sun, May 03, 2015 at 01:32:48PM +0200, intrigeri wrote: > I see xargs used for a few different purposes in > debian/lib/apparmor/functions: > > * when compiling the policy from scratch, e.g. on Live systems: > with -n1 -P, so that all CPU cores are used; in this case, simply > dropping xargs would imply a significant boot time increase for SMP > systems that have no cache. E.g. on my Tails/Jessie VM, the apparmor > service startup takes 13s with one single core, and 7s with two > cores (note that we've removed the $remote_fs dependency a while ago > in Tails/Jessie already). I'd rather avoid taking that performance > hit, and I can think of two potential solutions: > > - long-term: Live systems should ship a cached pre-compiled policy, > as is done for the Ubuntu phone. My understanding is that this > requires the ISO build system to run the exact same kernel as the > one shipped inside the ISO, which is quite impractical. > > - short-term: instead of "xargs -n1 -P", we could use busybox' > xargs; it doesn't support -P, so we need to manually compute the > optimal -n parameter (number of profiles / number of CPU cores). > > Thoughts, opinions, patches? :)
Having the parser handle its own parallelism has been on our backburner for a long time; calling the parser once per directory with profiles is the end goal, e.g. apparmor_parser --replace /etc/apparmor.d/ (This works now, just without DTRT parallelism.) The "exact same kernel" has been relaxed recently, either --match-string or --features-file or both ought to let a new-enough parser generate "correct" policy for a given target kernel using any other kernel. This could allow precompiling on the build hosts. > * when refreshing the policy cache: with -P only, so likely only one > apparmor_parser is run, and then dropping xargs shouldn't change > anything. > > * in clear_cache(), that's used by the init script's start action when > the policy was updated. Here, we could indeed call "rm $(...)" > instead, but then we would lose the benefits from the nice > "find -print0 | xargs -0" pattern. OTOH, the cache directories are > only writable by root, so in this case it should be safe to simply > use "rm $(...)". Recent gnu find supports -delete and avoids the fork()/exec() entirely. Thanks
signature.asc
Description: Digital signature