Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1421251 > unrolled thread

[RFC 00/18] Present useful limits to user

Back to article view | Back to linux.kernel

Contents

  [RFC 00/18] Present useful limits to user Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 21:50 +0200
    [RFC 16/18] limits: track RLIMIT_NICE actual max Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 21:50 +0200
    [RFC 03/18] memcontrol: present maximum used memory also for cgroup-v2 Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 21:50 +0200
      Re: [RFC 03/18] memcontrol: present maximum used memory also for  cgroup-v2 Michal Hocko <mhocko@kernel.org> - 2016-06-14 09:10 +0200
        Re: [RFC 03/18] memcontrol: present maximum used memory also for  cgroup-v2 Topi Miettinen <toiwoton@gmail.com> - 2016-06-14 17:50 +0200
          Re: [RFC 03/18] memcontrol: present maximum used memory also for  cgroup-v2 Johannes Weiner <hannes@cmpxchg.org> - 2016-06-14 18:10 +0200
            Re: [RFC 03/18] memcontrol: present maximum used memory also for  cgroup-v2 Topi Miettinen <toiwoton@gmail.com> - 2016-06-14 19:20 +0200
              Re: [RFC 03/18] memcontrol: present maximum used memory also for  cgroup-v2 Michal Hocko <mhocko@kernel.org> - 2016-06-16 12:30 +0200
    [RFC 02/18] cgroup_pids: track maximum pids Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 21:50 +0200
      Re: [RFC 02/18] cgroup_pids: track maximum pids Tejun Heo <tj@kernel.org> - 2016-06-13 23:20 +0200
        Re: [RFC 02/18] cgroup_pids: track maximum pids Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 23:30 +0200
          Re: [RFC 02/18] cgroup_pids: track maximum pids Tejun Heo <tj@kernel.org> - 2016-06-13 23:40 +0200
            Re: [RFC 02/18] cgroup_pids: track maximum pids Topi Miettinen <toiwoton@gmail.com> - 2016-06-14 00:00 +0200
              Re: [RFC 02/18] cgroup_pids: track maximum pids Tejun Heo <tj@kernel.org> - 2016-06-14 00:10 +0200
    [RFC 01/18] capabilities: track actually used capabilities Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 21:50 +0200
      Re: [RFC 01/18] capabilities: track actually used capabilities Andy Lutomirski <luto@amacapital.net> - 2016-06-13 22:40 +0200
        Re: [RFC 01/18] capabilities: track actually used capabilities Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 22:50 +0200
          Re: [RFC 01/18] capabilities: track actually used capabilities Andy Lutomirski <luto@amacapital.net> - 2016-06-13 23:20 +0200
            Re: [RFC 01/18] capabilities: track actually used capabilities Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 23:50 +0200
    [RFC 18/18] proc: present VM_LOCKED memory in /proc/self/maps Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 21:50 +0200
      Re: [RFC 18/18] proc: present VM_LOCKED memory in /proc/self/maps Kees Cook <kees@outflux.net> - 2016-06-13 23:00 +0200
        Re: [RFC 18/18] proc: present VM_LOCKED memory in /proc/self/maps Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 23:00 +0200
    [RFC 14/18] limits: track RLIMIT_SIGPENDING actual max Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 21:50 +0200
      Re: [RFC 14/18] limits: track RLIMIT_SIGPENDING actual max Oleg Nesterov <oleg@redhat.com> - 2016-06-14 17:00 +0200
        Re: [RFC 14/18] limits: track RLIMIT_SIGPENDING actual max Topi Miettinen <toiwoton@gmail.com> - 2016-06-14 18:00 +0200
    [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 21:50 +0200
      Re: [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max Andy Lutomirski <luto@kernel.org> - 2016-06-13 22:50 +0200
        Re: [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 23:20 +0200
          Re: [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max Andy Lutomirski <luto@amacapital.net> - 2016-06-13 23:20 +0200
            Re: [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max Topi Miettinen <toiwoton@gmail.com> - 2016-06-14 17:30 +0200
    [RFC 15/18] limits: track RLIMIT_MSGQUEUE actual max Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 21:50 +0200
      Re: [RFC 15/18] limits: track RLIMIT_MSGQUEUE actual max Doug Ledford <dledford@redhat.com> - 2016-06-17 22:00 +0200
    [RFC 06/18] limits: present RLIMIT_CPU and RLIMIT_RTTIMER current status Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 21:50 +0200
      Re: [RFC 06/18] limits: present RLIMIT_CPU and RLIMIT_RTTIMER current status Alexey Dobriyan <adobriyan@gmail.com> - 2016-06-14 11:20 +0200
    [RFC 11/18] limits: track and present RLIMIT_NPROC actual max Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 21:50 +0200
      Re: [RFC 11/18] limits: track and present RLIMIT_NPROC actual max Jann Horn <jann@thejh.net> - 2016-06-14 00:30 +0200
        Re: [RFC 11/18] limits: track and present RLIMIT_NPROC actual max Topi Miettinen <toiwoton@gmail.com> - 2016-06-14 17:50 +0200
          Re: [RFC 11/18] limits: track and present RLIMIT_NPROC actual max Jann Horn <jann@thejh.net> - 2016-06-15 01:20 +0200
    [RFC 17/18] limits: track RLIMIT_RTPRIO actual max Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 21:50 +0200
    [RFC 04/18] device_cgroup: track and present accessed devices Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 21:50 +0200
      Re: [RFC 04/18] device_cgroup: track and present accessed devices "Serge E. Hallyn" <serge@hallyn.com> - 2016-06-17 17:30 +0200
    [RFC 10/18] limits: track RLIMIT_STACK actual max Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 21:50 +0200
    [RFC 08/18] limits: track RLIMIT_DATA actual max Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 21:50 +0200
    [RFC 13/18] limits: track RLIMIT_AS actual max Topi Miettinen <toiwoton@gmail.com> - 2016-06-13 21:50 +0200
    Re: [RFC 00/18] Present useful limits to user Konstantin Khlebnikov <koct9i@gmail.com> - 2016-06-14 21:10 +0200
      Re: [RFC 00/18] Present useful limits to user Topi Miettinen <toiwoton@gmail.com> - 2016-06-14 21:50 +0200
      Re: [RFC 00/18] Present useful limits to user "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-06-15 16:50 +0200
        Re: [RFC 00/18] Present useful limits to user Konstantin Khlebnikov <koct9i@gmail.com> - 2016-06-18 16:50 +0200
          Re: [RFC 00/18] Present useful limits to user Topi Miettinen <toiwoton@gmail.com> - 2016-06-19 08:40 +0200
          Re: [RFC 00/18] Present useful limits to user "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-06-20 19:50 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#1425220 — Re: [RFC 04/18] device_cgroup: track and present accessed devices

Quoting Topi Miettinen (toiwoton@gmail.com):
> Track what devices are accessed and present them cgroup devices.accessed.
> 
> Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
> ---
>  security/device_cgroup.c | 70 +++++++++++++++++++++++++++++++++++++++++-------
>  1 file changed, 60 insertions(+), 10 deletions(-)
> 
> diff --git a/security/device_cgroup.c b/security/device_cgroup.c
> index 03c1652..45aa730 100644
> --- a/security/device_cgroup.c
> +++ b/security/device_cgroup.c
> @@ -48,6 +48,7 @@ struct dev_exception_item {
>  struct dev_cgroup {
>  	struct cgroup_subsys_state css;
>  	struct list_head exceptions;
> +	struct list_head accessed;
>  	enum devcg_behavior behavior;
>  };
>  
> @@ -90,7 +91,7 @@ free_and_exit:
>  /*
>   * called under devcgroup_mutex
>   */
> -static int dev_exception_add(struct dev_cgroup *dev_cgroup,
> +static int dev_exception_add(struct list_head *exceptions,
>  			     struct dev_exception_item *ex)

If you're going to re-use this function for the accessed list, then it
should be renamed, bc as it is it's misleading.

It also should be restructured.  The add-exceptions case was rare, so
doing kmemdup before checking for duplicates was ok.  But for the
accessed list I think we want to check for duplicates before we kmemdup.

>  {
>  	struct dev_exception_item *excopy, *walk;
> @@ -101,7 +102,7 @@ static int dev_exception_add(struct dev_cgroup *dev_cgroup,
>  	if (!excopy)
>  		return -ENOMEM;
>  
> -	list_for_each_entry(walk, &dev_cgroup->exceptions, list) {
> +	list_for_each_entry(walk, exceptions, list) {
>  		if (walk->type != ex->type)
>  			continue;
>  		if (walk->major != ex->major)
> @@ -115,7 +116,7 @@ static int dev_exception_add(struct dev_cgroup *dev_cgroup,
>  	}
>  
>  	if (excopy != NULL)
> -		list_add_tail_rcu(&excopy->list, &dev_cgroup->exceptions);
> +		list_add_tail_rcu(&excopy->list, exceptions);
>  	return 0;
>  }
>  
> @@ -155,6 +156,16 @@ static void __dev_exception_clean(struct dev_cgroup *dev_cgroup)
>  	}
>  }
>  
> +static void dev_accessed_clean(struct dev_cgroup *dev_cgroup)
> +{
> +	struct dev_exception_item *ex, *tmp;
> +
> +	list_for_each_entry_safe(ex, tmp, &dev_cgroup->accessed, list) {
> +		list_del_rcu(&ex->list);
> +		kfree_rcu(ex, rcu);
> +	}
> +}
> +
>  /**
>   * dev_exception_clean - frees all entries of the exception list
>   * @dev_cgroup: dev_cgroup with the exception list to be cleaned
> @@ -221,6 +232,7 @@ devcgroup_css_alloc(struct cgroup_subsys_state *parent_css)
>  	if (!dev_cgroup)
>  		return ERR_PTR(-ENOMEM);
>  	INIT_LIST_HEAD(&dev_cgroup->exceptions);
> +	INIT_LIST_HEAD(&dev_cgroup->accessed);
>  	dev_cgroup->behavior = DEVCG_DEFAULT_NONE;
>  
>  	return &dev_cgroup->css;
> @@ -231,6 +243,7 @@ static void devcgroup_css_free(struct cgroup_subsys_state *css)
>  	struct dev_cgroup *dev_cgroup = css_to_devcgroup(css);
>  
>  	__dev_exception_clean(dev_cgroup);
> +	dev_accessed_clean(dev_cgroup);
>  	kfree(dev_cgroup);
>  }
>  
> @@ -272,9 +285,9 @@ static void set_majmin(char *str, unsigned m)
>  		sprintf(str, "%u", m);
>  }
>  
> -static int devcgroup_seq_show(struct seq_file *m, void *v)
> +static int devcgroup_seq_show_list(struct seq_file *m, struct dev_cgroup *devcgroup,
> +				   struct list_head *exceptions, bool allow)
>  {
> -	struct dev_cgroup *devcgroup = css_to_devcgroup(seq_css(m));
>  	struct dev_exception_item *ex;
>  	char maj[MAJMINLEN], min[MAJMINLEN], acc[ACCLEN];
>  
> @@ -285,14 +298,14 @@ static int devcgroup_seq_show(struct seq_file *m, void *v)
>  	 * - List the exceptions in case the default policy is to deny
>  	 * This way, the file remains as a "whitelist of devices"
>  	 */
> -	if (devcgroup->behavior == DEVCG_DEFAULT_ALLOW) {
> +	if (allow) {
>  		set_access(acc, ACC_MASK);
>  		set_majmin(maj, ~0);
>  		set_majmin(min, ~0);
>  		seq_printf(m, "%c %s:%s %s\n", type_to_char(DEV_ALL),
>  			   maj, min, acc);
>  	} else {
> -		list_for_each_entry_rcu(ex, &devcgroup->exceptions, list) {
> +		list_for_each_entry_rcu(ex, exceptions, list) {
>  			set_access(acc, ex->access);
>  			set_majmin(maj, ex->major);
>  			set_majmin(min, ex->minor);
> @@ -305,6 +318,36 @@ static int devcgroup_seq_show(struct seq_file *m, void *v)
>  	return 0;
>  }
>  
> +static int devcgroup_seq_show(struct seq_file *m, void *v)
> +{
> +	struct dev_cgroup *devcgroup = css_to_devcgroup(seq_css(m));
> +
> +	return devcgroup_seq_show_list(m, devcgroup, &devcgroup->exceptions,
> +				       devcgroup->behavior == DEVCG_DEFAULT_ALLOW);
> +}
> +
> +static int devcgroup_seq_show_accessed(struct seq_file *m, void *v)
> +{
> +	struct dev_cgroup *devcgroup = css_to_devcgroup(seq_css(m));
> +
> +	return devcgroup_seq_show_list(m, devcgroup, &devcgroup->accessed, false);
> +}
> +
> +static void devcgroup_add_accessed(struct dev_cgroup *dev_cgroup, short type,
> +				   u32 major, u32 minor, short access)
> +{
> +	struct dev_exception_item ex;
> +
> +	ex.type = type;
> +	ex.major = major;
> +	ex.minor = minor;
> +	ex.access = access;
> +
> +	mutex_lock(&devcgroup_mutex);
> +	dev_exception_add(&dev_cgroup->accessed, &ex);
> +	mutex_unlock(&devcgroup_mutex);
> +}
> +
>  /**
>   * match_exception	- iterates the exception list trying to find a complete match
>   * @exceptions: list of exceptions
> @@ -566,7 +609,7 @@ static int propagate_exception(struct dev_cgroup *devcg_root,
>  		 */
>  		if (devcg_root->behavior == DEVCG_DEFAULT_ALLOW &&
>  		    devcg->behavior == DEVCG_DEFAULT_ALLOW) {
> -			rc = dev_exception_add(devcg, ex);
> +			rc = dev_exception_add(&devcg->exceptions, ex);
>  			if (rc)
>  				break;
>  		} else {
> @@ -736,7 +779,7 @@ static int devcgroup_update_access(struct dev_cgroup *devcgroup,
>  
>  		if (!parent_has_perm(devcgroup, &ex))
>  			return -EPERM;
> -		rc = dev_exception_add(devcgroup, &ex);
> +		rc = dev_exception_add(&devcgroup->exceptions, &ex);
>  		break;
>  	case DEVCG_DENY:
>  		/*
> @@ -747,7 +790,7 @@ static int devcgroup_update_access(struct dev_cgroup *devcgroup,
>  		if (devcgroup->behavior == DEVCG_DEFAULT_DENY)
>  			dev_exception_rm(devcgroup, &ex);
>  		else
> -			rc = dev_exception_add(devcgroup, &ex);
> +			rc = dev_exception_add(&devcgroup->exceptions, &ex);
>  
>  		if (rc)
>  			break;
> @@ -788,6 +831,11 @@ static struct cftype dev_cgroup_files[] = {
>  		.seq_show = devcgroup_seq_show,
>  		.private = DEVCG_LIST,
>  	},
> +	{
> +		.name = "accessed",
> +		.seq_show = devcgroup_seq_show_accessed,
> +		.private = DEVCG_LIST,
> +	},
>  	{ }	/* terminate */
>  };
>  
> @@ -830,6 +878,8 @@ static int __devcgroup_check_permission(short type, u32 major, u32 minor,
>  	if (!rc)
>  		return -EPERM;
>  
> +	devcgroup_add_accessed(dev_cgroup, type, major, minor, access);
> +
>  	return 0;
>  }
>  
> -- 
> 2.8.1

[toc] | [prev] | [next] | [standalone]

#1421268 — [RFC 10/18] limits: track RLIMIT_STACK actual max

Track maximum stack size, presented in /proc/self/limits.

Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
 mm/mmap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/mmap.c b/mm/mmap.c
index 61867de..0963e7f 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2019,6 +2019,8 @@ static int acct_stack_growth(struct vm_area_struct *vma, unsigned long size, uns
 	if (security_vm_enough_memory_mm(mm, grow))
 		return -ENOMEM;
 
+	bump_rlimit(RLIMIT_STACK, actual_size);
+
 	return 0;
 }
 
-- 
2.8.1

[toc] | [prev] | [next] | [standalone]

#1421269 — [RFC 08/18] limits: track RLIMIT_DATA actual max

Track maximum size of data VM, presented in /proc/self/limits.

Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
 arch/x86/ia32/ia32_aout.c | 1 +
 fs/binfmt_aout.c          | 1 +
 fs/binfmt_flat.c          | 1 +
 kernel/sys.c              | 2 ++
 mm/mmap.c                 | 6 +++++-
 5 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
index cb26f18..8a7d502 100644
--- a/arch/x86/ia32/ia32_aout.c
+++ b/arch/x86/ia32/ia32_aout.c
@@ -398,6 +398,7 @@ beyond_if:
 	regs->r8 = regs->r9 = regs->r10 = regs->r11 =
 	regs->r12 = regs->r13 = regs->r14 = regs->r15 = 0;
 	set_fs(USER_DS);
+	bump_limit(RLIMIT_DATA, ex.a_data + ex.a_bss);
 	return 0;
 }
 
diff --git a/fs/binfmt_aout.c b/fs/binfmt_aout.c
index ae1b540..86c6548 100644
--- a/fs/binfmt_aout.c
+++ b/fs/binfmt_aout.c
@@ -330,6 +330,7 @@ beyond_if:
 	regs->gp = ex.a_gpvalue;
 #endif
 	start_thread(regs, ex.a_entry, current->mm->start_stack);
+	bump_limit(RLIMIT_DATA, ex.a_data + ex.a_bss);
 	return 0;
 }
 
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index caf9e39..e309dad 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -792,6 +792,7 @@ static int load_flat_file(struct linux_binprm * bprm,
 			libinfo->lib_list[id].start_brk) +	/* start brk */
 			stack_len);
 
+	bump_limit(RLIMIT_DATA, data_len + bss_len);
 	return 0;
 err:
 	return ret;
diff --git a/kernel/sys.c b/kernel/sys.c
index 89d5be4..6629f6f 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1896,6 +1896,8 @@ static int prctl_set_mm_map(int opt, const void __user *addr, unsigned long data
 	if (prctl_map.auxv_size)
 		memcpy(mm->saved_auxv, user_auxv, sizeof(user_auxv));
 
+	bump_limit(RLIMIT_DATA, mm->end_data - mm->start_data);
+
 	up_write(&mm->mmap_sem);
 	return 0;
 }
diff --git a/mm/mmap.c b/mm/mmap.c
index de2c176..61867de 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -228,6 +228,8 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)
 		goto out;
 
 set_brk:
+	bump_rlimit(RLIMIT_DATA, (brk - mm->start_brk) +
+		    (mm->end_data - mm->start_data));
 	mm->brk = brk;
 	populate = newbrk > oldbrk && (mm->def_flags & VM_LOCKED) != 0;
 	up_write(&mm->mmap_sem);
@@ -2924,8 +2926,10 @@ void vm_stat_account(struct mm_struct *mm, vm_flags_t flags, long npages)
 		mm->exec_vm += npages;
 	else if (is_stack_mapping(flags))
 		mm->stack_vm += npages;
-	else if (is_data_mapping(flags))
+	else if (is_data_mapping(flags)) {
 		mm->data_vm += npages;
+		bump_rlimit(RLIMIT_DATA, mm->data_vm << PAGE_SHIFT);
+	}
 }
 
 static int special_mapping_fault(struct vm_area_struct *vma,
-- 
2.8.1

[toc] | [prev] | [next] | [standalone]

#1421270 — [RFC 13/18] limits: track RLIMIT_AS actual max

Track maximum size of address space, presented in /proc/self/limits.

Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
 mm/mmap.c   | 4 ++++
 mm/mremap.c | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/mm/mmap.c b/mm/mmap.c
index 4e683dd..4876c21 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2706,6 +2706,9 @@ static int do_brk(unsigned long addr, unsigned long len)
 out:
 	perf_event_mmap(vma);
 	mm->total_vm += len >> PAGE_SHIFT;
+
+	bump_rlimit(RLIMIT_AS, mm->total_vm << PAGE_SHIFT);
+
 	mm->data_vm += len >> PAGE_SHIFT;
 	if (flags & VM_LOCKED)
 		mm->locked_vm += (len >> PAGE_SHIFT);
@@ -2926,6 +2929,7 @@ bool may_expand_vm(struct mm_struct *mm, vm_flags_t flags, unsigned long npages)
 void vm_stat_account(struct mm_struct *mm, vm_flags_t flags, long npages)
 {
 	mm->total_vm += npages;
+	bump_rlimit(RLIMIT_AS, mm->total_vm << PAGE_SHIFT);
 
 	if (is_exec_mapping(flags))
 		mm->exec_vm += npages;
diff --git a/mm/mremap.c b/mm/mremap.c
index ade3e13..6be3c01 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -397,6 +397,9 @@ static struct vm_area_struct *vma_to_resize(unsigned long addr,
 	if (vma->vm_flags & VM_LOCKED)
 		bump_rlimit(RLIMIT_MEMLOCK, (mm->locked_vm << PAGE_SHIFT) +
 			    new_len - old_len);
+	bump_rlimit(RLIMIT_AS, (mm->total_vm << PAGE_SHIFT) +
+		    new_len - old_len);
+
 	return vma;
 }
 
-- 
2.8.1

[toc] | [prev] | [next] | [standalone]

#1422238

I don't like the idea of this patchset.

All limitations are context dependent and that context changes rapidly.
You'll never dump enough information for predicting future errors or
investigating reson of errors in past. You could try to reproduce all
kernel logic but model always will be aproximate.

If you want to track origin of failures in user space applications when it hits
some limit you should track errors. For example rlimits and other limitation
subsystems could provide resonable amount of tracepoints which could
tell what exactly happened before error. If you need highwater of some
values you could track it in userspace, or maybe tracing subsystem could
provide postpocessing for tracepoint parameters. Anyway, systemtap and
other monsters can do this right now.

On Mon, Jun 13, 2016 at 10:44 PM, Topi Miettinen <toiwoton@gmail.com> wrote:
> Hello,
>
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find out
> useful values for the limits, except blind trial and error.
>
> This patch series attempts to fix that by giving at least a nice starting
> point from the actual maximum values. I looked where each limit is checked
> and added a call to limit bump nearby.
>
>
> Capabilities
> [RFC 01/18] capabilities: track actually used capabilities
>
> Currently, there is no way to know which capabilities are actually used. Even
> the source code is only implicit, in-depth knowledge of each capability must
> be used when analyzing a program to judge which capabilities the program will
> exercise.
>
> Cgroups
> [RFC 02/18] cgroup_pids: track maximum pids
> [RFC 03/18] memcontrol: present maximum used memory also for
> [RFC 04/18] device_cgroup: track and present accessed devices
>
> For tasks and memory cgroup limits the situation is somewhat better as the
> current tasks and memory status can be easily seen with ps(1). However, any
> transient tasks or temporary higher memory use might slip from the view.
> Device use may be seen with advanced MAC tools, like TOMOYO, but there is no
> universal method. Program sources typically give no useful indication about
> memory use or how many tasks there could be.
>
> Resource limits
> [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max
> [RFC 06/18] limits: present RLIMIT_CPU and RLIMIT_RTTIMER current
> [RFC 07/18] limits: track RLIMIT_FSIZE actual max
> [RFC 08/18] limits: track RLIMIT_DATA actual max
> [RFC 09/18] limits: track RLIMIT_CORE actual max
> [RFC 10/18] limits: track RLIMIT_STACK actual max
> [RFC 11/18] limits: track and present RLIMIT_NPROC actual max
> [RFC 12/18] limits: track RLIMIT_MEMLOCK actual max
> [RFC 13/18] limits: track RLIMIT_AS actual max
> [RFC 14/18] limits: track RLIMIT_SIGPENDING actual max
> [RFC 15/18] limits: track RLIMIT_MSGQUEUE actual max
> [RFC 16/18] limits: track RLIMIT_NICE actual max
> [RFC 17/18] limits: track RLIMIT_RTPRIO actual max
> [RFC 18/18] proc: present VM_LOCKED memory in /proc/self/maps
>
> Current number of files and current VM usage (data pages, address space size)
> could be calculated from available /proc files. Again, any temporarily higher
> values could be easily missed. For many limits, there is no way to see what
> is the current situation and source code is mostly useless.
>
> As a side note, the resouce limits seem to be in bad shape. For example,
> RLIMIT_MEMLOCK is used incoherently and I think VM statistics can miss
> some changes. Adding RLIMIT_CODE could be useful.
>
> The current maximum values for the resource limits are now shown in
> /proc/task/limits. If this is deemed too confusing for the existing
> programs which rely on the exact format, I can change that to a new file.
>
>
> Finally, the patches work in my testing but I have probably missed finer
> lock/RCU details.
>
> -Topi
>

[toc] | [prev] | [next] | [standalone]

#1422257

On 06/14/16 19:03, Konstantin Khlebnikov wrote:
> I don't like the idea of this patchset.
> 
> All limitations are context dependent and that context changes rapidly.
> You'll never dump enough information for predicting future errors or
> investigating reson of errors in past. You could try to reproduce all
> kernel logic but model always will be aproximate.
> 

But that is true regardless of how the starting point for the limits was
determined. There will be always a possibility of setting too tight
limits which may work for a couple of test runs but which could also
eventually fail. The opposite is also possible, to use too loose limits
which are not effective. That's the way with limits in any case.

> If you want to track origin of failures in user space applications when it hits
> some limit you should track errors. For example rlimits and other limitation
> subsystems could provide resonable amount of tracepoints which could
> tell what exactly happened before error. If you need highwater of some
> values you could track it in userspace, or maybe tracing subsystem could
> provide postpocessing for tracepoint parameters. Anyway, systemtap and
> other monsters can do this right now.
> 

Those tools could help improving the starting point. But how could they
give exact value for that?

With this patch set, the user can just look at files in /proc and simply
copy the values to a config file as a starting point. What would be the
work flow with the tracepoint approach?

> On Mon, Jun 13, 2016 at 10:44 PM, Topi Miettinen <toiwoton@gmail.com> wrote:
>> Hello,
>>
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find out
>> useful values for the limits, except blind trial and error.
>>
>> This patch series attempts to fix that by giving at least a nice starting
>> point from the actual maximum values. I looked where each limit is checked
>> and added a call to limit bump nearby.
>>
>>
>> Capabilities
>> [RFC 01/18] capabilities: track actually used capabilities
>>
>> Currently, there is no way to know which capabilities are actually used. Even
>> the source code is only implicit, in-depth knowledge of each capability must
>> be used when analyzing a program to judge which capabilities the program will
>> exercise.
>>
>> Cgroups
>> [RFC 02/18] cgroup_pids: track maximum pids
>> [RFC 03/18] memcontrol: present maximum used memory also for
>> [RFC 04/18] device_cgroup: track and present accessed devices
>>
>> For tasks and memory cgroup limits the situation is somewhat better as the
>> current tasks and memory status can be easily seen with ps(1). However, any
>> transient tasks or temporary higher memory use might slip from the view.
>> Device use may be seen with advanced MAC tools, like TOMOYO, but there is no
>> universal method. Program sources typically give no useful indication about
>> memory use or how many tasks there could be.
>>
>> Resource limits
>> [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max
>> [RFC 06/18] limits: present RLIMIT_CPU and RLIMIT_RTTIMER current
>> [RFC 07/18] limits: track RLIMIT_FSIZE actual max
>> [RFC 08/18] limits: track RLIMIT_DATA actual max
>> [RFC 09/18] limits: track RLIMIT_CORE actual max
>> [RFC 10/18] limits: track RLIMIT_STACK actual max
>> [RFC 11/18] limits: track and present RLIMIT_NPROC actual max
>> [RFC 12/18] limits: track RLIMIT_MEMLOCK actual max
>> [RFC 13/18] limits: track RLIMIT_AS actual max
>> [RFC 14/18] limits: track RLIMIT_SIGPENDING actual max
>> [RFC 15/18] limits: track RLIMIT_MSGQUEUE actual max
>> [RFC 16/18] limits: track RLIMIT_NICE actual max
>> [RFC 17/18] limits: track RLIMIT_RTPRIO actual max
>> [RFC 18/18] proc: present VM_LOCKED memory in /proc/self/maps
>>
>> Current number of files and current VM usage (data pages, address space size)
>> could be calculated from available /proc files. Again, any temporarily higher
>> values could be easily missed. For many limits, there is no way to see what
>> is the current situation and source code is mostly useless.
>>
>> As a side note, the resouce limits seem to be in bad shape. For example,
>> RLIMIT_MEMLOCK is used incoherently and I think VM statistics can miss
>> some changes. Adding RLIMIT_CODE could be useful.
>>
>> The current maximum values for the resource limits are now shown in
>> /proc/task/limits. If this is deemed too confusing for the existing
>> programs which rely on the exact format, I can change that to a new file.
>>
>>
>> Finally, the patches work in my testing but I have probably missed finer
>> lock/RCU details.
>>
>> -Topi
>>

[toc] | [prev] | [next] | [standalone]

#1423103

On 2016-06-14 15:03, Konstantin Khlebnikov wrote:
> I don't like the idea of this patchset.
>
> All limitations are context dependent and that context changes rapidly.
> You'll never dump enough information for predicting future errors or
> investigating reson of errors in past. You could try to reproduce all
> kernel logic but model always will be aproximate.
It's still better than what we have now, and there is one particular use 
for the cgroup stuff that I find intriguing, you can create a cgroup, 
populate it, set no limits, and then run a simulated workload against it 
and see how it reacts.  This in general will probably provide a better 
starting point for what to actually set the limits to than just making 
an arbitrary guess.  Certain applications in particular come to mind 
which will just hang when they can't start a new thread or process 
(Dropbox is particularly guilty of this).  In such cases, setting the 
limit too low doesn't result in a crash, it results in the program just 
not appearing to work yet still running otherwise normally.

In general, I could see the rlimit stuff being in the same situation, 
it's not for figuring out why something failed (good software will tell 
you somewhere), but figuring out limits so it doesn't fail but still is 
reasonably contained.  A lot of things that seem at face value like they 
shouldn't need specific exceptions to limits do.  Most normal users 
probably wouldn't guess that acpid needs a RLIMIT_NPROC count of at 
least 4 or more to work with the default rules.  Similarly, there's 
probably not many normal users who know that the Dropbox daemon spawns 
an insanely large thread pool and preallocates significant amounts of 
memory and will just hang if either of these fail.  By having a way to 
get running max counts of resource usage, it makes it easier for people 
to know what the minimum limit they need to put on something is.
> If you want to track origin of failures in user space applications when it hits
> some limit you should track errors. For example rlimits and other limitation
> subsystems could provide resonable amount of tracepoints which could
> tell what exactly happened before error. If you need highwater of some
> values you could track it in userspace, or maybe tracing subsystem could
> provide postpocessing for tracepoint parameters. Anyway, systemtap and
> other monsters can do this right now.
Userspace tracking of some things just isn't practical.  Take 
RLIMIT_NPROC for example.  There's not really any reliable way to track 
this from userspace without modifying the process which is being 
tracked, which is not a user friendly way of doing things, and in some 
cases is functionally impossible for an end user to do.
>
> On Mon, Jun 13, 2016 at 10:44 PM, Topi Miettinen <toiwoton@gmail.com> wrote:
>> Hello,
>>
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find out
>> useful values for the limits, except blind trial and error.
>>
>> This patch series attempts to fix that by giving at least a nice starting
>> point from the actual maximum values. I looked where each limit is checked
>> and added a call to limit bump nearby.
>>
>>
>> Capabilities
>> [RFC 01/18] capabilities: track actually used capabilities
>>
>> Currently, there is no way to know which capabilities are actually used. Even
>> the source code is only implicit, in-depth knowledge of each capability must
>> be used when analyzing a program to judge which capabilities the program will
>> exercise.
>>
>> Cgroups
>> [RFC 02/18] cgroup_pids: track maximum pids
>> [RFC 03/18] memcontrol: present maximum used memory also for
>> [RFC 04/18] device_cgroup: track and present accessed devices
>>
>> For tasks and memory cgroup limits the situation is somewhat better as the
>> current tasks and memory status can be easily seen with ps(1). However, any
>> transient tasks or temporary higher memory use might slip from the view.
>> Device use may be seen with advanced MAC tools, like TOMOYO, but there is no
>> universal method. Program sources typically give no useful indication about
>> memory use or how many tasks there could be.
>>
>> Resource limits
>> [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max
>> [RFC 06/18] limits: present RLIMIT_CPU and RLIMIT_RTTIMER current
>> [RFC 07/18] limits: track RLIMIT_FSIZE actual max
>> [RFC 08/18] limits: track RLIMIT_DATA actual max
>> [RFC 09/18] limits: track RLIMIT_CORE actual max
>> [RFC 10/18] limits: track RLIMIT_STACK actual max
>> [RFC 11/18] limits: track and present RLIMIT_NPROC actual max
>> [RFC 12/18] limits: track RLIMIT_MEMLOCK actual max
>> [RFC 13/18] limits: track RLIMIT_AS actual max
>> [RFC 14/18] limits: track RLIMIT_SIGPENDING actual max
>> [RFC 15/18] limits: track RLIMIT_MSGQUEUE actual max
>> [RFC 16/18] limits: track RLIMIT_NICE actual max
>> [RFC 17/18] limits: track RLIMIT_RTPRIO actual max
>> [RFC 18/18] proc: present VM_LOCKED memory in /proc/self/maps
>>
>> Current number of files and current VM usage (data pages, address space size)
>> could be calculated from available /proc files. Again, any temporarily higher
>> values could be easily missed. For many limits, there is no way to see what
>> is the current situation and source code is mostly useless.
>>
>> As a side note, the resouce limits seem to be in bad shape. For example,
>> RLIMIT_MEMLOCK is used incoherently and I think VM statistics can miss
>> some changes. Adding RLIMIT_CODE could be useful.
>>
>> The current maximum values for the resource limits are now shown in
>> /proc/task/limits. If this is deemed too confusing for the existing
>> programs which rely on the exact format, I can change that to a new file.
>>
>>
>> Finally, the patches work in my testing but I have probably missed finer
>> lock/RCU details.
>>
>> -Topi
>>

[toc] | [prev] | [next] | [standalone]

#1425735

On Wed, Jun 15, 2016 at 5:47 PM, Austin S. Hemmelgarn
<ahferroin7@gmail.com> wrote:
> On 2016-06-14 15:03, Konstantin Khlebnikov wrote:
>>
>> I don't like the idea of this patchset.
>>
>> All limitations are context dependent and that context changes rapidly.
>> You'll never dump enough information for predicting future errors or
>> investigating reson of errors in past. You could try to reproduce all
>> kernel logic but model always will be aproximate.
>
> It's still better than what we have now, and there is one particular use for
> the cgroup stuff that I find intriguing, you can create a cgroup, populate
> it, set no limits, and then run a simulated workload against it and see how
> it reacts.  This in general will probably provide a better starting point
> for what to actually set the limits to than just making an arbitrary guess.
> Certain applications in particular come to mind which will just hang when
> they can't start a new thread or process (Dropbox is particularly guilty of
> this).  In such cases, setting the limit too low doesn't result in a crash,
> it results in the program just not appearing to work yet still running
> otherwise normally.
>
> In general, I could see the rlimit stuff being in the same situation, it's
> not for figuring out why something failed (good software will tell you
> somewhere), but figuring out limits so it doesn't fail but still is
> reasonably contained.  A lot of things that seem at face value like they
> shouldn't need specific exceptions to limits do.  Most normal users probably
> wouldn't guess that acpid needs a RLIMIT_NPROC count of at least 4 or more
> to work with the default rules.  Similarly, there's probably not many normal
> users who know that the Dropbox daemon spawns an insanely large thread pool
> and preallocates significant amounts of memory and will just hang if either
> of these fail.  By having a way to get running max counts of resource usage,
> it makes it easier for people to know what the minimum limit they need to
> put on something is.

Rlimits work only if resource usage could be estimated apriori.
They allows app limit itself to prevent failures is something goes wrong.

Rlimits are useless for controlling resource destribition: just use
cgroups for that.

>>
>> If you want to track origin of failures in user space applications when it
>> hits
>> some limit you should track errors. For example rlimits and other
>> limitation
>> subsystems could provide resonable amount of tracepoints which could
>> tell what exactly happened before error. If you need highwater of some
>> values you could track it in userspace, or maybe tracing subsystem could
>> provide postpocessing for tracepoint parameters. Anyway, systemtap and
>> other monsters can do this right now.
>
> Userspace tracking of some things just isn't practical.  Take RLIMIT_NPROC
> for example.  There's not really any reliable way to track this from
> userspace without modifying the process which is being tracked, which is not
> a user friendly way of doing things, and in some cases is functionally
> impossible for an end user to do.

You cannot get reliable upper bound for nr-proc from black box observations.
Highwater mark is very racy - tiny timing shifts can change it drammaticaly.

>
>>
>> On Mon, Jun 13, 2016 at 10:44 PM, Topi Miettinen <toiwoton@gmail.com>
>> wrote:
>>>
>>> Hello,
>>>
>>> There are many basic ways to control processes, including capabilities,
>>> cgroups and resource limits. However, there are far fewer ways to find
>>> out
>>> useful values for the limits, except blind trial and error.
>>>
>>> This patch series attempts to fix that by giving at least a nice starting
>>> point from the actual maximum values. I looked where each limit is
>>> checked
>>> and added a call to limit bump nearby.
>>>
>>>
>>> Capabilities
>>> [RFC 01/18] capabilities: track actually used capabilities
>>>
>>> Currently, there is no way to know which capabilities are actually used.
>>> Even
>>> the source code is only implicit, in-depth knowledge of each capability
>>> must
>>> be used when analyzing a program to judge which capabilities the program
>>> will
>>> exercise.
>>>
>>> Cgroups
>>> [RFC 02/18] cgroup_pids: track maximum pids
>>> [RFC 03/18] memcontrol: present maximum used memory also for
>>> [RFC 04/18] device_cgroup: track and present accessed devices
>>>
>>> For tasks and memory cgroup limits the situation is somewhat better as
>>> the
>>> current tasks and memory status can be easily seen with ps(1). However,
>>> any
>>> transient tasks or temporary higher memory use might slip from the view.
>>> Device use may be seen with advanced MAC tools, like TOMOYO, but there is
>>> no
>>> universal method. Program sources typically give no useful indication
>>> about
>>> memory use or how many tasks there could be.
>>>
>>> Resource limits
>>> [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max
>>> [RFC 06/18] limits: present RLIMIT_CPU and RLIMIT_RTTIMER current
>>> [RFC 07/18] limits: track RLIMIT_FSIZE actual max
>>> [RFC 08/18] limits: track RLIMIT_DATA actual max
>>> [RFC 09/18] limits: track RLIMIT_CORE actual max
>>> [RFC 10/18] limits: track RLIMIT_STACK actual max
>>> [RFC 11/18] limits: track and present RLIMIT_NPROC actual max
>>> [RFC 12/18] limits: track RLIMIT_MEMLOCK actual max
>>> [RFC 13/18] limits: track RLIMIT_AS actual max
>>> [RFC 14/18] limits: track RLIMIT_SIGPENDING actual max
>>> [RFC 15/18] limits: track RLIMIT_MSGQUEUE actual max
>>> [RFC 16/18] limits: track RLIMIT_NICE actual max
>>> [RFC 17/18] limits: track RLIMIT_RTPRIO actual max
>>> [RFC 18/18] proc: present VM_LOCKED memory in /proc/self/maps
>>>
>>> Current number of files and current VM usage (data pages, address space
>>> size)
>>> could be calculated from available /proc files. Again, any temporarily
>>> higher
>>> values could be easily missed. For many limits, there is no way to see
>>> what
>>> is the current situation and source code is mostly useless.
>>>
>>> As a side note, the resouce limits seem to be in bad shape. For example,
>>> RLIMIT_MEMLOCK is used incoherently and I think VM statistics can miss
>>> some changes. Adding RLIMIT_CODE could be useful.
>>>
>>> The current maximum values for the resource limits are now shown in
>>> /proc/task/limits. If this is deemed too confusing for the existing
>>> programs which rely on the exact format, I can change that to a new file.
>>>
>>>
>>> Finally, the patches work in my testing but I have probably missed finer
>>> lock/RCU details.
>>>
>>> -Topi
>>>
>

[toc] | [prev] | [next] | [standalone]

#1425939

On 06/18/16 14:45, Konstantin Khlebnikov wrote:
> On Wed, Jun 15, 2016 at 5:47 PM, Austin S. Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>> On 2016-06-14 15:03, Konstantin Khlebnikov wrote:
>>>
>>> I don't like the idea of this patchset.
>>>
>>> All limitations are context dependent and that context changes rapidly.
>>> You'll never dump enough information for predicting future errors or
>>> investigating reson of errors in past. You could try to reproduce all
>>> kernel logic but model always will be aproximate.
>>
>> It's still better than what we have now, and there is one particular use for
>> the cgroup stuff that I find intriguing, you can create a cgroup, populate
>> it, set no limits, and then run a simulated workload against it and see how
>> it reacts.  This in general will probably provide a better starting point
>> for what to actually set the limits to than just making an arbitrary guess.
>> Certain applications in particular come to mind which will just hang when
>> they can't start a new thread or process (Dropbox is particularly guilty of
>> this).  In such cases, setting the limit too low doesn't result in a crash,
>> it results in the program just not appearing to work yet still running
>> otherwise normally.
>>
>> In general, I could see the rlimit stuff being in the same situation, it's
>> not for figuring out why something failed (good software will tell you
>> somewhere), but figuring out limits so it doesn't fail but still is
>> reasonably contained.  A lot of things that seem at face value like they
>> shouldn't need specific exceptions to limits do.  Most normal users probably
>> wouldn't guess that acpid needs a RLIMIT_NPROC count of at least 4 or more
>> to work with the default rules.  Similarly, there's probably not many normal
>> users who know that the Dropbox daemon spawns an insanely large thread pool
>> and preallocates significant amounts of memory and will just hang if either
>> of these fail.  By having a way to get running max counts of resource usage,
>> it makes it easier for people to know what the minimum limit they need to
>> put on something is.
> 
> Rlimits work only if resource usage could be estimated apriori.

Now there's no way to estimate resource usage except analyzing source
code and even that does give any estimate for memory limits. With the
patches there's an easy way. Another way could be trial and error with
binary search. Any way, even those estimates can be too small.

Perhaps the problem is that the limiting mechanisms are too discrete,
either everything is OK or system calls fail (or the process is killed),
there's no throttling in between. Also, the applications could in some
cases tolerate the failures better.

> They allows app limit itself to prevent failures is something goes wrong.
> 

The application is not in any better position to estimate the limits.
Typically the limits are set elsewhere.

> Rlimits are useless for controlling resource destribition: just use
> cgroups for that.
> 

There are no direct cgroup equivalents for most rlimits. I think the
memory rlimits also make more sense per task. But otherwise cgroup
approach would be more flexible and adding further cgroups doesn't look
very difficult.

>>>
>>> If you want to track origin of failures in user space applications when it
>>> hits
>>> some limit you should track errors. For example rlimits and other
>>> limitation
>>> subsystems could provide resonable amount of tracepoints which could
>>> tell what exactly happened before error. If you need highwater of some
>>> values you could track it in userspace, or maybe tracing subsystem could
>>> provide postpocessing for tracepoint parameters. Anyway, systemtap and
>>> other monsters can do this right now.
>>
>> Userspace tracking of some things just isn't practical.  Take RLIMIT_NPROC
>> for example.  There's not really any reliable way to track this from
>> userspace without modifying the process which is being tracked, which is not
>> a user friendly way of doing things, and in some cases is functionally
>> impossible for an end user to do.
> 
> You cannot get reliable upper bound for nr-proc from black box observations.
> Highwater mark is very racy - tiny timing shifts can change it drammaticaly.
> 

The estimates are imperfect, but does this make the highwater mark
tracking any less valuable? How would you make the less imperfect
estimate with tracepoints?

>>
>>>
>>> On Mon, Jun 13, 2016 at 10:44 PM, Topi Miettinen <toiwoton@gmail.com>
>>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> There are many basic ways to control processes, including capabilities,
>>>> cgroups and resource limits. However, there are far fewer ways to find
>>>> out
>>>> useful values for the limits, except blind trial and error.
>>>>
>>>> This patch series attempts to fix that by giving at least a nice starting
>>>> point from the actual maximum values. I looked where each limit is
>>>> checked
>>>> and added a call to limit bump nearby.
>>>>
>>>>
>>>> Capabilities
>>>> [RFC 01/18] capabilities: track actually used capabilities
>>>>
>>>> Currently, there is no way to know which capabilities are actually used.
>>>> Even
>>>> the source code is only implicit, in-depth knowledge of each capability
>>>> must
>>>> be used when analyzing a program to judge which capabilities the program
>>>> will
>>>> exercise.
>>>>
>>>> Cgroups
>>>> [RFC 02/18] cgroup_pids: track maximum pids
>>>> [RFC 03/18] memcontrol: present maximum used memory also for
>>>> [RFC 04/18] device_cgroup: track and present accessed devices
>>>>
>>>> For tasks and memory cgroup limits the situation is somewhat better as
>>>> the
>>>> current tasks and memory status can be easily seen with ps(1). However,
>>>> any
>>>> transient tasks or temporary higher memory use might slip from the view.
>>>> Device use may be seen with advanced MAC tools, like TOMOYO, but there is
>>>> no
>>>> universal method. Program sources typically give no useful indication
>>>> about
>>>> memory use or how many tasks there could be.
>>>>
>>>> Resource limits
>>>> [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max
>>>> [RFC 06/18] limits: present RLIMIT_CPU and RLIMIT_RTTIMER current
>>>> [RFC 07/18] limits: track RLIMIT_FSIZE actual max
>>>> [RFC 08/18] limits: track RLIMIT_DATA actual max
>>>> [RFC 09/18] limits: track RLIMIT_CORE actual max
>>>> [RFC 10/18] limits: track RLIMIT_STACK actual max
>>>> [RFC 11/18] limits: track and present RLIMIT_NPROC actual max
>>>> [RFC 12/18] limits: track RLIMIT_MEMLOCK actual max
>>>> [RFC 13/18] limits: track RLIMIT_AS actual max
>>>> [RFC 14/18] limits: track RLIMIT_SIGPENDING actual max
>>>> [RFC 15/18] limits: track RLIMIT_MSGQUEUE actual max
>>>> [RFC 16/18] limits: track RLIMIT_NICE actual max
>>>> [RFC 17/18] limits: track RLIMIT_RTPRIO actual max
>>>> [RFC 18/18] proc: present VM_LOCKED memory in /proc/self/maps
>>>>
>>>> Current number of files and current VM usage (data pages, address space
>>>> size)
>>>> could be calculated from available /proc files. Again, any temporarily
>>>> higher
>>>> values could be easily missed. For many limits, there is no way to see
>>>> what
>>>> is the current situation and source code is mostly useless.
>>>>
>>>> As a side note, the resouce limits seem to be in bad shape. For example,
>>>> RLIMIT_MEMLOCK is used incoherently and I think VM statistics can miss
>>>> some changes. Adding RLIMIT_CODE could be useful.
>>>>
>>>> The current maximum values for the resource limits are now shown in
>>>> /proc/task/limits. If this is deemed too confusing for the existing
>>>> programs which rely on the exact format, I can change that to a new file.
>>>>
>>>>
>>>> Finally, the patches work in my testing but I have probably missed finer
>>>> lock/RCU details.
>>>>
>>>> -Topi
>>>>
>>

[toc] | [prev] | [next] | [standalone]

#1426861

On 2016-06-18 10:45, Konstantin Khlebnikov wrote:
> On Wed, Jun 15, 2016 at 5:47 PM, Austin S. Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>> On 2016-06-14 15:03, Konstantin Khlebnikov wrote:
>>>
>>> I don't like the idea of this patchset.
>>>
>>> All limitations are context dependent and that context changes rapidly.
>>> You'll never dump enough information for predicting future errors or
>>> investigating reson of errors in past. You could try to reproduce all
>>> kernel logic but model always will be aproximate.
>>
>> It's still better than what we have now, and there is one particular use for
>> the cgroup stuff that I find intriguing, you can create a cgroup, populate
>> it, set no limits, and then run a simulated workload against it and see how
>> it reacts.  This in general will probably provide a better starting point
>> for what to actually set the limits to than just making an arbitrary guess.
>> Certain applications in particular come to mind which will just hang when
>> they can't start a new thread or process (Dropbox is particularly guilty of
>> this).  In such cases, setting the limit too low doesn't result in a crash,
>> it results in the program just not appearing to work yet still running
>> otherwise normally.
>>
>> In general, I could see the rlimit stuff being in the same situation, it's
>> not for figuring out why something failed (good software will tell you
>> somewhere), but figuring out limits so it doesn't fail but still is
>> reasonably contained.  A lot of things that seem at face value like they
>> shouldn't need specific exceptions to limits do.  Most normal users probably
>> wouldn't guess that acpid needs a RLIMIT_NPROC count of at least 4 or more
>> to work with the default rules.  Similarly, there's probably not many normal
>> users who know that the Dropbox daemon spawns an insanely large thread pool
>> and preallocates significant amounts of memory and will just hang if either
>> of these fail.  By having a way to get running max counts of resource usage,
>> it makes it easier for people to know what the minimum limit they need to
>> put on something is.
>
> Rlimits work only if resource usage could be estimated apriori.
> They allows app limit itself to prevent failures is something goes wrong.
And yet many apps allow the _user_ to specify rlimits.  Avahi has the 
option for the user to set every single rlimit, ntpd (the reference 
implementation) lets the user configure MEMLOCK, and quite a few other 
daemons I've seen that are very widely used allow similar manual 
configuration of limits.  Most of these are network service daemons, 
which _can't_ reasonably limit themselves, because they can't know what 
type of workload they'll run against.
>
> Rlimits are useless for controlling resource destribition: just use
> cgroups for that.
The only rlimit that has a cgroup specifically for managing it is NPROC. 
  There's a bunch of memory ones that can't be individually controlled 
in the memcg.  MEMLOCK is actually pretty widely used from what I've 
seen, but there is no way to control it at all with cgroups right now. 
NOFILE, LOCKS, FSIZE, and CORE all deal with the filesystem and have no 
cgroup that controls such resources (the only two that might be useful 
this way are NOFILE and LOCKS, but I doubt that those will get in, 
because they technically tie in with the kernel memory accounting in 
memcg).  NICE and RTPRIO are nonsensical in a cgroup context, although I 
don't think I've ever talked to anyone who actually uses them.  CPU and 
RTTIME have no equivalent in cgroups, but could in theory be tacked onto 
the cpu controller, but they haven't been and until that happens, people 
still have to use them instead of cgroups.
>
>>>
>>> If you want to track origin of failures in user space applications when it
>>> hits
>>> some limit you should track errors. For example rlimits and other
>>> limitation
>>> subsystems could provide resonable amount of tracepoints which could
>>> tell what exactly happened before error. If you need highwater of some
>>> values you could track it in userspace, or maybe tracing subsystem could
>>> provide postpocessing for tracepoint parameters. Anyway, systemtap and
>>> other monsters can do this right now.
>>
>> Userspace tracking of some things just isn't practical.  Take RLIMIT_NPROC
>> for example.  There's not really any reliable way to track this from
>> userspace without modifying the process which is being tracked, which is not
>> a user friendly way of doing things, and in some cases is functionally
>> impossible for an end user to do.
>
> You cannot get reliable upper bound for nr-proc from black box observations.
> Highwater mark is very racy - tiny timing shifts can change it drammaticaly.
You can't get a perfectly reliable upper bound for any type of resource 
usage with just black box observations, period.  You also can't do so 
with tracing without some significant secondary work either for _exactly 
the same reason_.  The thing to remember though is that in a majority of 
cases, what most people need is simply a reasonable estimate which is 
guaranteed to not be below the actual usage.  They don't care exactly 
how many processes application Y uses at most, they just care that it 
uses fewer than some reasonable limit under normal usage.  To go back to 
the NPROC example, most people want to be able to set a limit that will 
catch things if they start to get out of hand, but absolutely have to 
estimate high because almost nothing handles a fork failure gracefully 
without completely shutting down.  In such a situation, it doesn't 
matter if it's a bit racy, as long as they have some reasonable lower 
bound to base the estimate off of and the specifics of it not being 100% 
reliable are properly documented.
>
>>
>>>
>>> On Mon, Jun 13, 2016 at 10:44 PM, Topi Miettinen <toiwoton@gmail.com>
>>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> There are many basic ways to control processes, including capabilities,
>>>> cgroups and resource limits. However, there are far fewer ways to find
>>>> out
>>>> useful values for the limits, except blind trial and error.
>>>>
>>>> This patch series attempts to fix that by giving at least a nice starting
>>>> point from the actual maximum values. I looked where each limit is
>>>> checked
>>>> and added a call to limit bump nearby.
>>>>
>>>>
>>>> Capabilities
>>>> [RFC 01/18] capabilities: track actually used capabilities
>>>>
>>>> Currently, there is no way to know which capabilities are actually used.
>>>> Even
>>>> the source code is only implicit, in-depth knowledge of each capability
>>>> must
>>>> be used when analyzing a program to judge which capabilities the program
>>>> will
>>>> exercise.
>>>>
>>>> Cgroups
>>>> [RFC 02/18] cgroup_pids: track maximum pids
>>>> [RFC 03/18] memcontrol: present maximum used memory also for
>>>> [RFC 04/18] device_cgroup: track and present accessed devices
>>>>
>>>> For tasks and memory cgroup limits the situation is somewhat better as
>>>> the
>>>> current tasks and memory status can be easily seen with ps(1). However,
>>>> any
>>>> transient tasks or temporary higher memory use might slip from the view.
>>>> Device use may be seen with advanced MAC tools, like TOMOYO, but there is
>>>> no
>>>> universal method. Program sources typically give no useful indication
>>>> about
>>>> memory use or how many tasks there could be.
>>>>
>>>> Resource limits
>>>> [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max
>>>> [RFC 06/18] limits: present RLIMIT_CPU and RLIMIT_RTTIMER current
>>>> [RFC 07/18] limits: track RLIMIT_FSIZE actual max
>>>> [RFC 08/18] limits: track RLIMIT_DATA actual max
>>>> [RFC 09/18] limits: track RLIMIT_CORE actual max
>>>> [RFC 10/18] limits: track RLIMIT_STACK actual max
>>>> [RFC 11/18] limits: track and present RLIMIT_NPROC actual max
>>>> [RFC 12/18] limits: track RLIMIT_MEMLOCK actual max
>>>> [RFC 13/18] limits: track RLIMIT_AS actual max
>>>> [RFC 14/18] limits: track RLIMIT_SIGPENDING actual max
>>>> [RFC 15/18] limits: track RLIMIT_MSGQUEUE actual max
>>>> [RFC 16/18] limits: track RLIMIT_NICE actual max
>>>> [RFC 17/18] limits: track RLIMIT_RTPRIO actual max
>>>> [RFC 18/18] proc: present VM_LOCKED memory in /proc/self/maps
>>>>
>>>> Current number of files and current VM usage (data pages, address space
>>>> size)
>>>> could be calculated from available /proc files. Again, any temporarily
>>>> higher
>>>> values could be easily missed. For many limits, there is no way to see
>>>> what
>>>> is the current situation and source code is mostly useless.
>>>>
>>>> As a side note, the resouce limits seem to be in bad shape. For example,
>>>> RLIMIT_MEMLOCK is used incoherently and I think VM statistics can miss
>>>> some changes. Adding RLIMIT_CODE could be useful.
>>>>
>>>> The current maximum values for the resource limits are now shown in
>>>> /proc/task/limits. If this is deemed too confusing for the existing
>>>> programs which rely on the exact format, I can change that to a new file.
>>>>
>>>>
>>>> Finally, the patches work in my testing but I have probably missed finer
>>>> lock/RCU details.
>>>>
>>>> -Topi
>>>>
>>

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web