On 07/15/16 15:14, Oleg Nesterov wrote:
On 07/15, Topi Miettinen wrote:
quoted
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.
quoted
@@ -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.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>