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. > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>