OSDN Git Service

apparmor: Use a memory pool instead per-CPU caches
authorSebastian Andrzej Siewior <bigeasy@linutronix.de>
Fri, 3 May 2019 14:12:21 +0000 (16:12 +0200)
committerJohn Johansen <john.johansen@canonical.com>
Thu, 20 Jun 2019 17:33:31 +0000 (10:33 -0700)
commitdf323337e507a0009d3db1ea25948d4c7f320d62
treebc8c3f6707fcf31a22f2eaa19eca5838fb87517e
parentbf1d2ee7bc6215dd92427625a4c707227457a5db
apparmor: Use a memory pool instead per-CPU caches

The get_buffers() macro may provide one or two buffers to the caller.
Those buffers are pre-allocated on init for each CPU. By default it
allocates
2* 2 * MAX_PATH * POSSIBLE_CPU

which equals 64KiB on a system with 4 CPUs or 1MiB with 64 CPUs and so
on.

Replace the per-CPU buffers with a common memory pool which is shared
across all CPUs. The pool grows on demand and never shrinks. The pool
starts with two (UP) or four (SMP) elements. By using this pool it is
possible to request a buffer and keeping preemption enabled which avoids
the hack in profile_transition().

It has been pointed out by Tetsuo Handa that GFP_KERNEL allocations for
small amount of memory do not fail. In order not to have an endless
retry, __GFP_RETRY_MAYFAIL is passed (so the memory allocation is not
repeated until success) and retried once hoping that in the meantime a
buffer has been returned to the pool. Since now NULL is possible all
allocation paths check the buffer pointer and return -ENOMEM on failure.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: John Johansen <john.johansen@canonical.com>
security/apparmor/domain.c
security/apparmor/file.c
security/apparmor/include/path.h
security/apparmor/lsm.c
security/apparmor/mount.c