Comment 19 for bug 1989073

Hi Marius,

> What actually is the effect of the denial? Will qemu not use more than one CPU,
> or is it something less harmful?

Since the new interface is arch specific and new the code does fall back tot he old way.

  226 /* On some architectures it is possible to distinguish between configured
  227 and active cpus. */
  228 int
  229 __get_nprocs_conf (void)
  230 {
  231 int result = read_sysfs_file ("/sys/devices/system/cpu/possible");
  232 if (result != 0)
  233 return result;
  234
  235 /* Fall back to /proc/stat and sched_getaffinity. */
  236 return get_nprocs_fallback ();
  237 }

Due to that, even when denied it gets the right number (as it had before).

Once with and without isolation blocking access.

ubuntu@k2:/tmp$ ./testsysconf
_SC_NPROCESSORS_CONF 3

ubuntu@k2:/tmp$ sudo aa-exec -p test -- ./testsysconf
_SC_NPROCESSORS_CONF 3

It only has a real difference on systems where the new code was needed in the first place.
Those are usually rather massive systems which start at lower cpu counts but might hot-plug them later - on those with the denial falling back you'd only get a lower than the real potential max number.
The code that hits this in your case is libnuma on initialization, unless you are very deep into numa control on very huge systems using cpu hotplug you won't see any effect.