[PATCH 1/2] apparmor: Use a memory pool instead per-CPU caches

[Tetsuo Handa]

On 2019/05/02 22:47, Sebastian Andrzej Siewior wrote:
> On 2019-05-02 22:17:35 [+0900], Tetsuo Handa wrote:
>> There is 'The "too small to fail" memory-allocation rule'
>> ( https://lwn.net/Articles/627419/ ) where GFP_KERNEL allocation for
>> size <= 32768 bytes never fails unless current thread was killed by
>> the OOM killer. This means that kmalloc() in
>>
>> +char *aa_get_buffer(void)
>> +{
>> +	union aa_buffer *aa_buf;
>> +
>> +try_again:
>> +	spin_lock(&aa_buffers_lock);
>> +	if (!list_empty(&aa_global_buffers)) {
>> +		aa_buf = list_first_entry(&aa_global_buffers, union aa_buffer,
>> +					  list);
>> +		list_del(&aa_buf->list);
>> +		spin_unlock(&aa_buffers_lock);
>> +		return &aa_buf->buffer[0];
>> +	}
>> +	spin_unlock(&aa_buffers_lock);
>> +
>> +	aa_buf = kmalloc(aa_g_path_max, GFP_KERNEL);
>> +	if (WARN_ON_ONCE(!aa_buf))
>> +		goto try_again;
>> +	return &aa_buf->buffer[0];
>> +}
>>
>> can't return NULL unless current thread was killed by the OOM killer
>> if aa_g_path_max <= 32768. On the other hand, if aa_g_path_max > 32768,
>> this allocation can easily fail, and retrying forever is very bad.
> 
> as I pointed out in the other email, it shouldn't retry forever because
> we should have something in the pool which will be returned.
> 

The point of 'The "too small to fail" memory-allocation rule' is that kmalloc(GFP_KERNEL)
can't return NULL after current thread once reached kmalloc(GFP_KERNEL). That is, current
thread loops forever inside __alloc_pages_nodemask() unless killed by the OOM killer.
If you want to use aa_get_buffer() as if a memory pool, you need to specify __GFP_NORETRY
(or __GFP_RETRY_MAYFAIL).



>>> @@ -1399,6 +1404,7 @@ static int param_set_aauint(const char *val, const struct kernel_param *kp)
>>>  		return -EPERM;
>>>  
>>>  	error = param_set_uint(val, kp);
>>> +	aa_g_path_max = min_t(uint32_t, aa_g_path_max, sizeof(union aa_buffer));
>>
>> I think that this will guarantee that aa_g_path_max <= sizeof(struct list_head)
>> which is too small to succeed. :-(
> 
> Ach right, this should have been max instead of min. Btw: are there any
> sane upper/lower limits while at it?

Although PATH_MAX is a limit which can be passed as a string argument to syscalls,
there is no limit for a pathname calculated by d_path() etc. The pathname can grow
until memory allocation for dentry cache fails after OOM-killer killed almost all
userspace processes.

But for pathname based access control, returning an error to userspace due to memory
allocation failure for d_path() etc. might result in unexpected termination of that
process. Therefore, you don't want to give up easily.