[PATCH 1/2] apparmor: Use a memory pool instead per-CPU caches
Sebastian Andrzej Siewior
bigeasy at linutronix.de
Tue Apr 30 14:47:25 UTC 2019
On 2019-04-28 16:56:59 [-0700], John Johansen wrote:
> So digging into why the history of the per cpu buffers in apparmor.
> We used to do buffer allocations via kmalloc and there were a few reasons
> for the switch
> * speed/lockless: speaks for it self, mediation is already slow enough
it is shared among all CPUs but it is a small/quick operation to
add/return a buffer.
> * some buffer allocations had to be done with GFP_ATOMIC, making them
> more likely to fail. Since we fail closed that means failure would
> block access. This actually became a serious problem in a couple
> places. Switching to per cpu buffers and blocking pre-empt was
> the solution.
GFP_KERNEL is allowed to use IO/SWAP and ATOMIC has emergency pools. The
new approach won't return a NULL pointer, simply spin to either allocate
new memory or get one which was just returned.
> * in heavy use cases we would see a lot of buffers being allocated
> and freed. Which resulted in locking slow downs and also buffer
> allocation failures. So having the buffers preallocated allowed us
> to bound this potential problem.
> This was all 6 years ago. Going to a mem pool certainly could help,
> reduce the memory foot print, and would definitely help with
> preempt/real time kernels.
> A big concern with this patchset is reverting back to GFP_KERNEL
> for everything. We definitely were getting failures due to allocations
> in atomic context. There have been lots of changes in the kernel over
> the last six years so it possible these cases don't exist anymore. I
> went through and built some kernels with this patchset and have run
> through some testing without tripping that problem but I don't think
> it has seen enough testing yet.
Do you want apply #1 now and #2 later? I audited the ATOMIC->KERNEL
changes manually and I didn't see any atomic context. It looked like the
only reason for ATOMIC was the preempt_disable() due to the memory pool.
More information about the Linux-security-module-archive