Subject: Re: [PATCH 09/14] resource limits: track highwater mark of locked memory

From: Topi Miettinen <[email-masked]>
Date: Fri, 15 Jul 2016 17:39:26 +0000

On 07/15/16 15:14, Oleg Nesterov wrote:
> On 07/15, Topi Miettinen wrote:
>>
>> Track maximum size of locked memory, to be able to configure
>> RLIMIT_MEMLOCK resource limits. The information is available
>> with taskstats and cgroupstats netlink socket.
> 
> So I personally still dislike the very idea of this series... but I won't
> argue if you convince maintainers.
> 
>> @@ -2020,6 +2020,10 @@ static int acct_stack_growth(struct vm_area_struct *vma, unsigned long size, uns
>>  		return -ENOMEM;
>>  
>>  	update_resource_highwatermark(RLIMIT_STACK, actual_size);
>> +	if (vma->vm_flags & VM_LOCKED)
>> +		update_resource_highwatermark(RLIMIT_MEMLOCK,
>> +					      (mm->locked_vm + grow) <<
>> +					      PAGE_SHIFT);
> 
> Btw this is not right. The same for the previous patch which tracks
> RLIMIT_STACK. The "current" task can debugger/etc.

acct_stack_growth() is called from expand_upwards() and
expand_downwards(). They call security_mmap_addr() and the various LSM
implementations also use current task in the checks. Are these also not
right?

> 
> Yes, yes, this just reminds that the whole rlimit logic in this path
> is broken but still...

I'd be happy to fix the logic with a separate prerequisite patch and
then use the right logic for this patch, but I'm not sure I know how.
Could you elaborate a bit?

-Topi

> Oleg.