From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1424573AbcFMW11 (ORCPT ); Mon, 13 Jun 2016 18:27:27 -0400 Received: from thejh.net ([37.221.195.125]:51151 "EHLO thejh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161386AbcFMW1Y (ORCPT ); Mon, 13 Jun 2016 18:27:24 -0400 Date: Tue, 14 Jun 2016 00:27:20 +0200 From: Jann Horn To: Topi Miettinen Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Andrew Morton , Kees Cook , Al Viro , Alexey Dobriyan , John Stultz , Janis Danisevskis , Calvin Owens , Tejun Heo , Michal Hocko , Oleg Nesterov , Vladimir Davydov , Andrea Arcangeli , Josh Triplett , "Eric W. Biederman" , Aleksa Sarai , Cyrill Gorcunov , Ben Segall , Mateusz Guzik Subject: Re: [RFC 11/18] limits: track and present RLIMIT_NPROC actual max Message-ID: <20160613222719.GA3397@pc.thejh.net> References: <1465847065-3577-1-git-send-email-toiwoton@gmail.com> <1465847065-3577-12-git-send-email-toiwoton@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <1465847065-3577-12-git-send-email-toiwoton@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 13, 2016 at 10:44:18PM +0300, Topi Miettinen wrote: > Track maximum number of processes per user and present it > in /proc/self/limits. >=20 > Signed-off-by: Topi Miettinen > --- > fs/proc/base.c | 4 ++++ > include/linux/sched.h | 1 + > kernel/fork.c | 5 +++++ > kernel/sys.c | 5 +++++ > 4 files changed, 15 insertions(+) >=20 > diff --git a/fs/proc/base.c b/fs/proc/base.c > index 1df4fc8..02576c6 100644 > --- a/fs/proc/base.c > +++ b/fs/proc/base.c > @@ -670,6 +670,10 @@ static int proc_pid_limits(struct seq_file *m, struc= t pid_namespace *ns, > seq_printf(m, "%-20lu\n", psecs); > } > break; > + case RLIMIT_NPROC: > + seq_printf(m, "%-20d\n", > + atomic_read(&task->real_cred->user->max_processes)); Don't you have to take an RCU read lock before dereferencing task->real_cre= d? And shouldn't this be done with __task_cred(task) instead of task->real_cre= d? > + break; > default: > seq_printf(m, "%-20lu\n", > task->signal->rlim_curmax[i]); > diff --git a/include/linux/sched.h b/include/linux/sched.h > index 0150380..feb9bb7 100644 > --- a/include/linux/sched.h > +++ b/include/linux/sched.h > @@ -838,6 +838,7 @@ static inline int signal_group_exit(const struct sign= al_struct *sig) > struct user_struct { > atomic_t __count; /* reference count */ > atomic_t processes; /* How many processes does this user have? */ > + atomic_t max_processes; /* How many processes has this user had at the = same time? */ > atomic_t sigpending; /* How many pending signals does this user have? */ > #ifdef CONFIG_INOTIFY_USER > atomic_t inotify_watches; /* How many inotify watches does this user ha= ve? */ > diff --git a/kernel/fork.c b/kernel/fork.c > index 5c2c355..667290f 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -1653,6 +1653,11 @@ static struct task_struct *copy_process(unsigned l= ong clone_flags, > trace_task_newtask(p, clone_flags); > uprobe_copy_process(p, clone_flags); > =20 > + if (atomic_read(&p->real_cred->user->max_processes) < > + atomic_read(&p->real_cred->user->processes)) > + atomic_set(&p->real_cred->user->max_processes, > + atomic_read(&p->real_cred->user->processes)); > + > return p; > =20 > bad_fork_cancel_cgroup: > diff --git a/kernel/sys.c b/kernel/sys.c > index 6629f6f..955cf21 100644 > --- a/kernel/sys.c > +++ b/kernel/sys.c > @@ -439,6 +439,11 @@ static int set_user(struct cred *new) > else > current->flags &=3D ~PF_NPROC_EXCEEDED; > =20 > + if (atomic_read(&new_user->max_processes) < > + atomic_read(&new_user->processes)) > + atomic_set(&new_user->max_processes, > + atomic_read(&new_user->processes)); > + Is this intentionally slightly racy? If so, it might be nice to have a comm= ent here that documents that. --KsGdsel6WgEHnImy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXXzNHAAoJED4KNFJOeCOotzYP/34oPfJdR0I1pD0G7YTYPbUg WNj4zvD6jt24/TJnrutfNc9+7qwTpOEW1LJ6IdCQeePMMESZ+MOT2XWwQ5KTiHjw epR95l6DBV8RirWKF28u6RVPLIRnXpAXGUcLcFDLB2y2XBVbRcLvGO2Vv+8PSFJ2 YuM8O39W7fkdZ/c0mB/nl+pwIKXOC6P2vZ2HcX2Vu1XAFFeK2rW+wjCA6W5MRECB BxkFw8XXbchq4a5yaF8caP6OSnWy/BYPtXM7YBnm2fJzxS3gpdSvKKNH7oIJSa03 VqYpSfYDpYg+GKd/LSeZDsT/smgEWMbpfoSrFXDB2dd5rh8Yff6Kkyf7HcOetA3X SSUyU5l23foOhauWg7Ka0N2H9Vfdvma7JZi59levE7CdDp+kAqemCN78tCJIUkFl rbvW+3AVXuIJ0+gKERJmJ97aYhN9Ued+GVFRkNjX3gX5XMTQSYcFXQoNohRJ2ReD Qun7Efksg2N5sZA71jVvHKUvAyCucTYpNCasFh9/Yzi8SJC2+0H5ZFSpb1ghjxsf vIRWuo+bzNNC30ZX+FS0WWZwoXwYca6mywG/xF7fvZR+vXngdhtEFhD7wKH5fxmd d0oxYvz+9Eis8hBPnuqy30BPMEusN877BtX1+gnpB+WPAtvb+hO1iM4YS6pK4qty WvHOrgXbMynDTUZpqhQ6 =nRqk -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy--