Re: [PATCH]: proc: export a processes resource limits via proc/
On Wed, Aug 22, 2007 at 09:40:37PM -0500, Matt Mackall wrote: > On Tue, Aug 21, 2007 at 11:56:11AM -0700, Andy Isaacson wrote: > > On Fri, Aug 17, 2007 at 12:45:47PM -0700, Andrew Morton wrote: > > > On Fri, 17 Aug 2007 06:59:18 -0400 > > > Neil Horman <[EMAIL PROTECTED]> wrote: > > > > Currently, there exists no method for a process to query the resource > > > > limits of another process. They can be inferred via some mechanisms > > > > but they cannot be explicitly determined. Given that this > > > > information can be usefull to know during the debugging of an > > > > application, I've written this patch which exports all of a > > > > processes limits via /proc//limits. > > > > > > I'm struggling with this a bit. Sure, it _might_ be handy on some > > > occasions to be able to get at this information. But I've never seen > > > anyone ask for it before, and it _is_ determinable by other means, if only > > > strace. > > > > I've wanted this information on multiple occasions in the past and was > > mystified that there was no way to determine it. And no, I don't feel > > that strace is an answer -- given a running process, how do I use strace > > to find out what its current ulimits are? > > You stop it and force it to execute rlimit(2) in its context, of > course! What could be simpler? > I would think reading a file in /proc would be simpler :), especially if you're in a position where attaching to the process through ptrace isnt feasible. For instance, if you were an application running as the result of a core dump when /proc/sys/kernel/core_pattern were a pipe, preforming your operation wouldn't be particularly possible. Likewise, if your a sysadmin and you want to check what your processes limits were, you could follow your method, but I would think you would much rather avoid needing to send several ptrace commands to your commands, interrupting its work if you didn't have to. > The reason we never see questions about this is because relatively few > people are using limits. Instead we see weekly questions about fork > bombs. > But we do see questions about this. I've had a few requests, and at least two more people have popped up on this thread supporting it. Regards Neil -- /*** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: proc: export a processes resource limits via proc/
On Tue, Aug 21, 2007 at 11:56:11AM -0700, Andy Isaacson wrote: > On Fri, Aug 17, 2007 at 12:45:47PM -0700, Andrew Morton wrote: > > On Fri, 17 Aug 2007 06:59:18 -0400 > > Neil Horman <[EMAIL PROTECTED]> wrote: > > > Currently, there exists no method for a process to query the resource > > > limits of another process. They can be inferred via some mechanisms > > > but they cannot be explicitly determined. Given that this > > > information can be usefull to know during the debugging of an > > > application, I've written this patch which exports all of a > > > processes limits via /proc//limits. > > > > I'm struggling with this a bit. Sure, it _might_ be handy on some > > occasions to be able to get at this information. But I've never seen > > anyone ask for it before, and it _is_ determinable by other means, if only > > strace. > > I've wanted this information on multiple occasions in the past and was > mystified that there was no way to determine it. And no, I don't feel > that strace is an answer -- given a running process, how do I use strace > to find out what its current ulimits are? You stop it and force it to execute rlimit(2) in its context, of course! What could be simpler? The reason we never see questions about this is because relatively few people are using limits. Instead we see weekly questions about fork bombs. Frankly, I'd rather see new syscalls to get and set limits on other processes in the same way we can set priorities, affinities, etc.. But there are a couple dragons lurking there.. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: proc: export a processes resource limits via proc/
On Fri, Aug 17, 2007 at 12:45:47PM -0700, Andrew Morton wrote: > On Fri, 17 Aug 2007 06:59:18 -0400 > Neil Horman <[EMAIL PROTECTED]> wrote: > > Currently, there exists no method for a process to query the resource > > limits of another process. They can be inferred via some mechanisms > > but they cannot be explicitly determined. Given that this > > information can be usefull to know during the debugging of an > > application, I've written this patch which exports all of a > > processes limits via /proc//limits. > > I'm struggling with this a bit. Sure, it _might_ be handy on some > occasions to be able to get at this information. But I've never seen > anyone ask for it before, and it _is_ determinable by other means, if only > strace. I've wanted this information on multiple occasions in the past and was mystified that there was no way to determine it. And no, I don't feel that strace is an answer -- given a running process, how do I use strace to find out what its current ulimits are? -andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: proc: export a processes resource limits via proc/
On Fri, Aug 17, 2007 at 12:45:47PM -0700, Andrew Morton wrote: > On Fri, 17 Aug 2007 06:59:18 -0400 > Neil Horman <[EMAIL PROTECTED]> wrote: > > > Currently, there exists no method for a process to query the resource > > limits of another process. They can be inferred via some mechanisms but > > they > > cannot be explicitly determined. Given that this information can be > > usefull to > > know during the debugging of an application, I've written this patch which > > exports all of a processes limits via /proc//limits. > > I'm struggling with this a bit. Sure, it _might_ be handy on some > occasions to be able to get at this information. But I've never seen > anyone ask for it before, and it _is_ determinable by other means, if only > strace. > > How do we justify adding yet more stuff to the kernel? Well, In the past yar and a half I've been asked for it twice. Granted thats not alot of demand, but neither is the code particularly invasive or complex. If your concerned about bloat, my first thought would be to add a compile time config option, which I'm certainly willing to add if the consensus is to do so, but honestly I thought this was small enough that it didnt' really need it. As previously mentioned though, the final say as to what is important enough to make it into the kernel is up to you and Linus. I think this is worthwhile, but if I'm in the minority on that, I'll certainly understand Thanks & Regards Neil -- /*** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: proc: export a processes resource limits via proc/
On Fri, 17 Aug 2007 12:45:47 PDT, Andrew Morton said: > On Fri, 17 Aug 2007 06:59:18 -0400 > Neil Horman <[EMAIL PROTECTED]> wrote: > > > Currently, there exists no method for a process to query the resource > > limits of another process. They can be inferred via some mechanisms but > > they > > cannot be explicitly determined. Given that this information can be > > usefull to > > know during the debugging of an application, I've written this patch which > > exports all of a processes limits via /proc//limits. > > I'm struggling with this a bit. Sure, it _might_ be handy on some > occasions to be able to get at this information. But I've never seen > anyone ask for it before, and it _is_ determinable by other means, if only > strace. Most of the times *I*'ve struggled with this, it's been a case of "this program forks that one that calls a PAM module that does this and then double-forks yadda yadda". So I know where Neil is coming from. > How do we justify adding yet more stuff to the kernel? I looked the code over, and *if* we want to do it, the code looks good. Making that final call is why they pay you and Linus the big bucks. :) pgp8r441xY3IJ.pgp Description: PGP signature
Re: [PATCH]: proc: export a processes resource limits via proc/
On Fri, 17 Aug 2007 06:59:18 -0400 Neil Horman <[EMAIL PROTECTED]> wrote: > Currently, there exists no method for a process to query the resource > limits of another process. They can be inferred via some mechanisms but they > cannot be explicitly determined. Given that this information can be usefull > to > know during the debugging of an application, I've written this patch which > exports all of a processes limits via /proc//limits. I'm struggling with this a bit. Sure, it _might_ be handy on some occasions to be able to get at this information. But I've never seen anyone ask for it before, and it _is_ determinable by other means, if only strace. How do we justify adding yet more stuff to the kernel? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: proc: export a processes resource limits via proc/
On Fri, Aug 17, 2007 at 04:09:26AM -0400, [EMAIL PROTECTED] wrote: > On Thu, 16 Aug 2007 08:35:38 EDT, Neil Horman said: > > Hey again- > > Andrew requested that I repost this cleanly, after running the patch > > through checkpatch. As requested here it is with the changelog. > > > > Currently, there exists no method for a process to query the resource > > limits of another process. They can be inferred via some mechanisms but > > they > > cannot be explicitly determined. Given that this information can be > > usefull > to > > know during the debugging of an application, I've written this patch which > > exports all of a processes limits via /proc//limits. > > > > Tested successfully by myself on x86 on top of 2.6.23-rc2-mm1. > > I had only one comment the first time around, and Neil addressed it. > > I've also tested on x86_64 23-rc2-mm1, and it works here too. I saw where > this > uses units of 'bytes' while the shell 'ulimit' uses 1024-byte units in some > places, but (a) this lists the units and (b) it's consistent with setrlimit(). > Testing with values >4G show it's 64-bit clean as well. > > One question: Is the units milliseconds, or seconds here: > > + [RLIMIT_CPU] = {"Max cpu time", "ms"}, > > Other than that, feel free to stick either/both of these on: > > Reviewed-By: Valdis Kletnieks <[EMAIL PROTECTED]> > Tested-By: Valdis Kletnieks <[EMAIL PROTECTED]> Oops, your right, Thanks. New patch Currently, there exists no method for a process to query the resource limits of another process. They can be inferred via some mechanisms but they cannot be explicitly determined. Given that this information can be usefull to know during the debugging of an application, I've written this patch which exports all of a processes limits via /proc//limits. Thanks Neil Signed-off-by: Neil Horman <[EMAIL PROTECTED]> base.c | 69 + 1 file changed, 69 insertions(+) commit 95e91e3102d7963e63d68969b8db5694b83a6684 Author: Neil Horman <[EMAIL PROTECTED]> Date: Thu Aug 16 08:25:59 2007 -0400 Readding proc_pid_limits patch with checkpatch.pl run diff --git a/fs/proc/base.c b/fs/proc/base.c index ed2b224..4fb34a5 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -74,6 +74,7 @@ #include #include #include +#include #include "internal.h" /* NOTE: @@ -323,6 +324,72 @@ static int proc_oom_score(struct task_struct *task, char *buffer) return sprintf(buffer, "%lu\n", points); } +struct limit_names { + char *name; + char *unit; +}; + +static const struct limit_names lnames[RLIM_NLIMITS] = { + [RLIMIT_CPU] = {"Max cpu time", "seconds"}, + [RLIMIT_FSIZE] = {"Max file size", "bytes"}, + [RLIMIT_DATA] = {"Max data size", "bytes"}, + [RLIMIT_STACK] = {"Max stack size", "bytes"}, + [RLIMIT_CORE] = {"Max core file size", "bytes"}, + [RLIMIT_RSS] = {"Max resident set", "bytes"}, + [RLIMIT_NPROC] = {"Max processes", "processes"}, + [RLIMIT_NOFILE] = {"Max open files", "files"}, + [RLIMIT_MEMLOCK] = {"Max locked memory", "bytes"}, + [RLIMIT_AS] = {"Max address space", "bytes"}, + [RLIMIT_LOCKS] = {"Max file locks", "locks"}, + [RLIMIT_SIGPENDING] = {"Max pending signals", "signals"}, + [RLIMIT_MSGQUEUE] = {"Max msgqueue size", "bytes"}, + [RLIMIT_NICE] = {"Max nice priority", NULL}, + [RLIMIT_RTPRIO] = {"Max realtime priority", NULL}, +}; + +/* Display limits for a process */ +static int proc_pid_limits(struct task_struct *task, char *buffer) +{ + unsigned int i; + int count = 0; + char *bufptr = buffer; + + struct rlimit rlim[RLIM_NLIMITS]; + + read_lock(&tasklist_lock); + memcpy(rlim, task->signal->rlim, sizeof(struct rlimit) * RLIM_NLIMITS); + read_unlock(&tasklist_lock); + + /* +* print the file header +*/ + count += sprintf(&bufptr[count], "%-25s %-20s %-20s %-10s\n", + "Limit", "Soft Limit", "Hard Limit", "Units"); + + for (i = 0; i < RLIM_NLIMITS; i++) { + if (rlim[i].rlim_cur == RLIM_INFINITY) + count += sprintf(&bufptr[count], "%-25s %-20s ", +lnames[i].name, "unlimited"); + else + count += sprintf(&bufptr[count], "%-25s %-20lu ", +lnames[i].name, rlim[i].rlim_cur); + + if (rlim[i].rlim_max == RLIM_INFINITY) + count += sprintf(&bufptr[count], "%-20s ", "unlimited"); + else + count += sprintf(&bufptr[count], "%-20lu ", +rlim[i].rlim_max); + + if (lnames[i].unit) + count += sprintf(&bufptr[count], "%-10s\n", +lnames[i].unit); + else +
Re: [PATCH]: proc: export a processes resource limits via proc/
On Thu, 16 Aug 2007 08:35:38 EDT, Neil Horman said: > Hey again- > Andrew requested that I repost this cleanly, after running the patch > through checkpatch. As requested here it is with the changelog. > > Currently, there exists no method for a process to query the resource > limits of another process. They can be inferred via some mechanisms but they > cannot be explicitly determined. Given that this information can be usefull to > know during the debugging of an application, I've written this patch which > exports all of a processes limits via /proc//limits. > > Tested successfully by myself on x86 on top of 2.6.23-rc2-mm1. I had only one comment the first time around, and Neil addressed it. I've also tested on x86_64 23-rc2-mm1, and it works here too. I saw where this uses units of 'bytes' while the shell 'ulimit' uses 1024-byte units in some places, but (a) this lists the units and (b) it's consistent with setrlimit(). Testing with values >4G show it's 64-bit clean as well. One question: Is the units milliseconds, or seconds here: + [RLIMIT_CPU] = {"Max cpu time", "ms"}, Other than that, feel free to stick either/both of these on: Reviewed-By: Valdis Kletnieks <[EMAIL PROTECTED]> Tested-By: Valdis Kletnieks <[EMAIL PROTECTED]> pgpqnQgPc3e9C.pgp Description: PGP signature
Re: [PATCH]: proc: export a processes resource limits via proc/
Hey again- Andrew requested that I repost this cleanly, after running the patch through checkpatch. As requested here it is with the changelog. Currently, there exists no method for a process to query the resource limits of another process. They can be inferred via some mechanisms but they cannot be explicitly determined. Given that this information can be usefull to know during the debugging of an application, I've written this patch which exports all of a processes limits via /proc//limits. Tested successfully by myself on x86 on top of 2.6.23-rc2-mm1. Thanks & Regards Neil Signed-off-by: Neil Horman <[EMAIL PROTECTED]> base.c | 69 + 1 file changed, 69 insertions(+) diff --git a/fs/proc/base.c b/fs/proc/base.c index ed2b224..4fb34a5 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -74,6 +74,7 @@ #include #include #include +#include #include "internal.h" /* NOTE: @@ -323,6 +324,72 @@ static int proc_oom_score(struct task_struct *task, char *buffer) return sprintf(buffer, "%lu\n", points); } +struct limit_names { + char *name; + char *unit; +}; + +static const struct limit_names lnames[RLIM_NLIMITS] = { + [RLIMIT_CPU] = {"Max cpu time", "ms"}, + [RLIMIT_FSIZE] = {"Max file size", "bytes"}, + [RLIMIT_DATA] = {"Max data size", "bytes"}, + [RLIMIT_STACK] = {"Max stack size", "bytes"}, + [RLIMIT_CORE] = {"Max core file size", "bytes"}, + [RLIMIT_RSS] = {"Max resident set", "bytes"}, + [RLIMIT_NPROC] = {"Max processes", "processes"}, + [RLIMIT_NOFILE] = {"Max open files", "files"}, + [RLIMIT_MEMLOCK] = {"Max locked memory", "bytes"}, + [RLIMIT_AS] = {"Max address space", "bytes"}, + [RLIMIT_LOCKS] = {"Max file locks", "locks"}, + [RLIMIT_SIGPENDING] = {"Max pending signals", "signals"}, + [RLIMIT_MSGQUEUE] = {"Max msgqueue size", "bytes"}, + [RLIMIT_NICE] = {"Max nice priority", NULL}, + [RLIMIT_RTPRIO] = {"Max realtime priority", NULL}, +}; + +/* Display limits for a process */ +static int proc_pid_limits(struct task_struct *task, char *buffer) +{ + unsigned int i; + int count = 0; + char *bufptr = buffer; + + struct rlimit rlim[RLIM_NLIMITS]; + + read_lock(&tasklist_lock); + memcpy(rlim, task->signal->rlim, sizeof(struct rlimit) * RLIM_NLIMITS); + read_unlock(&tasklist_lock); + + /* +* print the file header +*/ + count += sprintf(&bufptr[count], "%-25s %-20s %-20s %-10s\n", + "Limit", "Soft Limit", "Hard Limit", "Units"); + + for (i = 0; i < RLIM_NLIMITS; i++) { + if (rlim[i].rlim_cur == RLIM_INFINITY) + count += sprintf(&bufptr[count], "%-25s %-20s ", +lnames[i].name, "unlimited"); + else + count += sprintf(&bufptr[count], "%-25s %-20lu ", +lnames[i].name, rlim[i].rlim_cur); + + if (rlim[i].rlim_max == RLIM_INFINITY) + count += sprintf(&bufptr[count], "%-20s ", "unlimited"); + else + count += sprintf(&bufptr[count], "%-20lu ", +rlim[i].rlim_max); + + if (lnames[i].unit) + count += sprintf(&bufptr[count], "%-10s\n", +lnames[i].unit); + else + count += sprintf(&bufptr[count], "\n"); + } + + return count; +} + // /* Here the fs part begins*/ // @@ -2017,6 +2084,7 @@ static const struct pid_entry tgid_base_stuff[] = { INF("environ",S_IRUSR, pid_environ), INF("auxv", S_IRUSR, pid_auxv), INF("status", S_IRUGO, pid_status), + INF("limits", S_IRUSR, pid_limits), #ifdef CONFIG_SCHED_DEBUG REG("sched", S_IRUGO|S_IWUSR, pid_sched), #endif @@ -2310,6 +2378,7 @@ static const struct pid_entry tid_base_stuff[] = { INF("environ", S_IRUSR, pid_environ), INF("auxv", S_IRUSR, pid_auxv), INF("status",S_IRUGO, pid_status), + INF("limits",S_IRUSR, pid_limits), #ifdef CONFIG_SCHED_DEBUG REG("sched", S_IRUGO|S_IWUSR, pid_sched), #endif -- /*** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/major
Re: [PATCH]: proc: export a processes resource limits via proc/
On Tue, Aug 14, 2007 at 01:04:02AM +0400, Alexey Dobriyan wrote: > On Mon, Aug 13, 2007 at 04:11:30PM -0400, Neil Horman wrote: > > --- a/fs/proc/base.c > > +++ b/fs/proc/base.c > > @@ -323,6 +324,68 @@ static int proc_oom_score(struct task_struct *task, > > char *buffer) > > return sprintf(buffer, "%lu\n", points); > > } > > > > +struct limit_names { > > + char *name; > > + char *unit; > > +}; > > + > > +static const struct limit_names lnames[RLIM_NLIMITS] = { > > + [RLIMIT_CPU] = {"Max cpu time", "ms"}, > > + [RLIMIT_FSIZE] = {"Max file size", "bytes"}, > > + [RLIMIT_DATA] = {"Max data size", "bytes"}, > > + [RLIMIT_STACK] = {"Max stack size", "bytes"}, > > + [RLIMIT_CORE] = {"Max core file size", "bytes"}, > > + [RLIMIT_RSS] = {"Max resident set", "bytes"}, > > + [RLIMIT_NPROC] = {"Max processes", "processes"}, > > + [RLIMIT_NOFILE] = {"Max open files", "files"}, > > + [RLIMIT_MEMLOCK] = {"Max locked memory", "bytes"}, > > + [RLIMIT_AS] = {"Max address space", "bytes"}, > > + [RLIMIT_LOCKS] = {"Max file locks", "locks"}, > > + [RLIMIT_SIGPENDING] = {"Max pending signals", "signals"}, > > this and processes should be left empty methinks, because max signals is > in fact unitless. > not sure I agree with that. According to the man page, RLIMIT_SIGPENDING is counted in number of signals and RLIMIT_NPROC is counted as a number of processes. > > + [RLIMIT_MSGQUEUE] = {"Max msgqueue size", "bytes"}, > > + [RLIMIT_NICE] = {"Max nice priority", NULL}, > > + [RLIMIT_RTPRIO] = {"Max realtime priority", NULL}, > > +}; > > aha! trailing whitespace! > Fixed :) > > +static int proc_pid_limits(struct task_struct *task, char *buffer) > > +{ > > + unsigned int i; > > + int count = 0; > > + char *bufptr = buffer; > > + > > + struct rlimit rlim[RLIM_NLIMITS]; > > + > > + read_lock(&tasklist_lock); > > + memcpy(rlim, task->signal->rlim, (sizeof(struct rlimit) * > > RLIM_NLIMITS)); > > unneeded (, ) > I prefer to explicitly show order of operations, but I'm wierd that way, so I'll change it :) > > + read_unlock(&tasklist_lock); > > hmm, fork copies this under task lock of group leader and system calls > in sys.c too. What's up? > > I'm sure it will give you nonsensical output because of wrong locks but > I haven't checked. > I don't think so, I borrowed the code there from sys_getrlimit, which also reds task->signal->rlim (only for one element instead of the whole array, so if its broken here it should be broken there, but I don't see how. > FWIW, it survived ~1 hour of cat /proc/*/limits, mini fork bombs, LTP, > gdb testsuite and one sooper sikrit proggie. on core2 > Its survived for a few days for me (while true; do cat /proc/*/limits;done), with not noticible side effects (other than a slightly higher CPU load :)). New patch with the ()'s and whitespace fixed. Regards Neil Signed-off-by: Neil Horman <[EMAIL PROTECTED]> base.c | 65 + 1 file changed, 65 insertions(+) diff --git a/fs/proc/base.c b/fs/proc/base.c index ed2b224..b3ddf08 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -74,6 +74,7 @@ #include #include #include +#include #include "internal.h" /* NOTE: @@ -323,6 +324,68 @@ static int proc_oom_score(struct task_struct *task, char *buffer) return sprintf(buffer, "%lu\n", points); } +struct limit_names { + char *name; + char *unit; +}; + +static const struct limit_names lnames[RLIM_NLIMITS] = { + [RLIMIT_CPU] = {"Max cpu time", "ms"}, + [RLIMIT_FSIZE] = {"Max file size", "bytes"}, + [RLIMIT_DATA] = {"Max data size", "bytes"}, + [RLIMIT_STACK] = {"Max stack size", "bytes"}, + [RLIMIT_CORE] = {"Max core file size", "bytes"}, + [RLIMIT_RSS] = {"Max resident set", "bytes"}, + [RLIMIT_NPROC] = {"Max processes", "processes"}, + [RLIMIT_NOFILE] = {"Max open files", "files"}, + [RLIMIT_MEMLOCK] = {"Max locked memory", "bytes"}, + [RLIMIT_AS] = {"Max address space", "bytes"}, + [RLIMIT_LOCKS] = {"Max file locks", "locks"}, + [RLIMIT_SIGPENDING] = {"Max pending signals", "signals"}, + [RLIMIT_MSGQUEUE] = {"Max msgqueue size", "bytes"}, + [RLIMIT_NICE] = {"Max nice priority", NULL}, + [RLIMIT_RTPRIO] = {"Max realtime priority", NULL}, +}; + +/* Display limits for a process */ +static int proc_pid_limits(struct task_struct *task, char *buffer) +{ + unsigned int i; + int count = 0; + char *bufptr = buffer; + + struct rlimit rlim[RLIM_NLIMITS]; + + read_lock(&tasklist_lock); + memcpy(rlim, task->signal->rlim, sizeof(struct rlimit) * RLIM_NLIMITS); + read_unlock(&tasklist_lock); + + /* +* print the file header +*/ + count += sprintf(&bufptr[count], "%-25s %-20s %-20s %-10s\n", + "Limit","Soft Limit","Hard Limit","Units"); + + for (i=0; i < RLIM_NLIMITS; i++) { +
Re: [PATCH]: proc: export a processes resource limits via proc/
On Mon, Aug 13, 2007 at 04:11:30PM -0400, Neil Horman wrote: > --- a/fs/proc/base.c > +++ b/fs/proc/base.c > @@ -323,6 +324,68 @@ static int proc_oom_score(struct task_struct *task, char > *buffer) > return sprintf(buffer, "%lu\n", points); > } > > +struct limit_names { > + char *name; > + char *unit; > +}; > + > +static const struct limit_names lnames[RLIM_NLIMITS] = { > + [RLIMIT_CPU] = {"Max cpu time", "ms"}, > + [RLIMIT_FSIZE] = {"Max file size", "bytes"}, > + [RLIMIT_DATA] = {"Max data size", "bytes"}, > + [RLIMIT_STACK] = {"Max stack size", "bytes"}, > + [RLIMIT_CORE] = {"Max core file size", "bytes"}, > + [RLIMIT_RSS] = {"Max resident set", "bytes"}, > + [RLIMIT_NPROC] = {"Max processes", "processes"}, > + [RLIMIT_NOFILE] = {"Max open files", "files"}, > + [RLIMIT_MEMLOCK] = {"Max locked memory", "bytes"}, > + [RLIMIT_AS] = {"Max address space", "bytes"}, > + [RLIMIT_LOCKS] = {"Max file locks", "locks"}, > + [RLIMIT_SIGPENDING] = {"Max pending signals", "signals"}, this and processes should be left empty methinks, because max signals is in fact unitless. > + [RLIMIT_MSGQUEUE] = {"Max msgqueue size", "bytes"}, > + [RLIMIT_NICE] = {"Max nice priority", NULL}, > + [RLIMIT_RTPRIO] = {"Max realtime priority", NULL}, > +}; aha! trailing whitespace! > +static int proc_pid_limits(struct task_struct *task, char *buffer) > +{ > + unsigned int i; > + int count = 0; > + char *bufptr = buffer; > + > + struct rlimit rlim[RLIM_NLIMITS]; > + > + read_lock(&tasklist_lock); > + memcpy(rlim, task->signal->rlim, (sizeof(struct rlimit) * > RLIM_NLIMITS)); unneeded (, ) > + read_unlock(&tasklist_lock); hmm, fork copies this under task lock of group leader and system calls in sys.c too. What's up? I'm sure it will give you nonsensical output because of wrong locks but I haven't checked. FWIW, it survived ~1 hour of cat /proc/*/limits, mini fork bombs, LTP, gdb testsuite and one sooper sikrit proggie. on core2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: proc: export a processes resource limits via proc/
On Mon, Aug 13, 2007 at 09:25:45PM +0200, Ingo Oeser wrote: > Hi Neil, > > > +static struct limit_names lnames[RLIM_NLIMITS] = { > static const ... > > may be better here. > > Best Regards > > Ingo Oeser No, objections, thats all read only data anyway. New patch attached Regards Neil Signed-off-by: Neil Horman <[EMAIL PROTECTED]> base.c | 65 + 1 file changed, 65 insertions(+) diff --git a/fs/proc/base.c b/fs/proc/base.c index ed2b224..b3ddf08 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -74,6 +74,7 @@ #include #include #include +#include #include "internal.h" /* NOTE: @@ -323,6 +324,68 @@ static int proc_oom_score(struct task_struct *task, char *buffer) return sprintf(buffer, "%lu\n", points); } +struct limit_names { + char *name; + char *unit; +}; + +static const struct limit_names lnames[RLIM_NLIMITS] = { + [RLIMIT_CPU] = {"Max cpu time", "ms"}, + [RLIMIT_FSIZE] = {"Max file size", "bytes"}, + [RLIMIT_DATA] = {"Max data size", "bytes"}, + [RLIMIT_STACK] = {"Max stack size", "bytes"}, + [RLIMIT_CORE] = {"Max core file size", "bytes"}, + [RLIMIT_RSS] = {"Max resident set", "bytes"}, + [RLIMIT_NPROC] = {"Max processes", "processes"}, + [RLIMIT_NOFILE] = {"Max open files", "files"}, + [RLIMIT_MEMLOCK] = {"Max locked memory", "bytes"}, + [RLIMIT_AS] = {"Max address space", "bytes"}, + [RLIMIT_LOCKS] = {"Max file locks", "locks"}, + [RLIMIT_SIGPENDING] = {"Max pending signals", "signals"}, + [RLIMIT_MSGQUEUE] = {"Max msgqueue size", "bytes"}, + [RLIMIT_NICE] = {"Max nice priority", NULL}, + [RLIMIT_RTPRIO] = {"Max realtime priority", NULL}, +}; + +/* Display limits for a process */ +static int proc_pid_limits(struct task_struct *task, char *buffer) +{ + unsigned int i; + int count = 0; + char *bufptr = buffer; + + struct rlimit rlim[RLIM_NLIMITS]; + + read_lock(&tasklist_lock); + memcpy(rlim, task->signal->rlim, (sizeof(struct rlimit) * RLIM_NLIMITS)); + read_unlock(&tasklist_lock); + + /* +* print the file header +*/ + count += sprintf(&bufptr[count], "%-25s %-20s %-20s %-10s\n", + "Limit","Soft Limit","Hard Limit","Units"); + + for (i=0; i < RLIM_NLIMITS; i++) { + if (rlim[i].rlim_cur == RLIM_INFINITY) + count += sprintf(&bufptr[count], "%-25s %-20s ", lnames[i].name,"unlimited"); + else + count += sprintf(&bufptr[count], "%-25s %-20lu ", lnames[i].name, rlim[i].rlim_cur); + + if (rlim[i].rlim_max == RLIM_INFINITY) + count += sprintf(&bufptr[count], "%-20s ","unlimited"); + else + count += sprintf(&bufptr[count], "%-20lu ", rlim[i].rlim_max); + + if (lnames[i].unit) + count += sprintf(&bufptr[count],"%-10s\n", lnames[i].unit); + else + count += sprintf(&bufptr[count],"\n"); + } + + return count; +} + // /* Here the fs part begins*/ // @@ -2017,6 +2080,7 @@ static const struct pid_entry tgid_base_stuff[] = { INF("environ",S_IRUSR, pid_environ), INF("auxv", S_IRUSR, pid_auxv), INF("status", S_IRUGO, pid_status), + INF("limits", S_IRUSR, pid_limits), #ifdef CONFIG_SCHED_DEBUG REG("sched", S_IRUGO|S_IWUSR, pid_sched), #endif @@ -2310,6 +2374,7 @@ static const struct pid_entry tid_base_stuff[] = { INF("environ", S_IRUSR, pid_environ), INF("auxv", S_IRUSR, pid_auxv), INF("status",S_IRUGO, pid_status), + INF("limits",S_IRUSR, pid_limits), #ifdef CONFIG_SCHED_DEBUG REG("sched", S_IRUGO|S_IWUSR, pid_sched), #endif -- /*** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: proc: export a processes resource limits via proc/
Hi Neil, > +static struct limit_names lnames[RLIM_NLIMITS] = { static const ... may be better here. Best Regards Ingo Oeser - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: proc: export a processes resource limits via proc/
On Mon, Aug 13, 2007 at 12:47:38PM -0400, [EMAIL PROTECTED] wrote: > On Mon, 13 Aug 2007 10:00:44 EDT, Neil Horman said: > > Hey there- > > Currently, there exists no method for a process to query the resource > > limits of another process. They can be inferred via some mechanisms but > > they > > cannot be explicitly determined. Given that this information can be > > usefull to > > know during the debugging of an application, I've written this patch which > > exports all of a processes limits via /proc//limits. Tested > > successfully > > by myself on x86 on top of 2.6.23-rc2-mm1. > > > // > > /* Here the fs part begins*/ > > // > > @@ -2017,6 +2080,7 @@ static const struct pid_entry tgid_base_stuff[] = { > > INF("environ",S_IRUSR, pid_environ), > > INF("auxv", S_IRUSR, pid_auxv), > > INF("status", S_IRUGO, pid_status), > > + INF("limits", S_IRUGO, pid_limits), > > Any takers for S_IRUSR instead? Either that, or lay out the use case for > making it S_IRUGO. (I'm OK on it being world-visible *if* there's a good > and sane reason for it) > > > #ifdef CONFIG_SCHED_DEBUG > > REG("sched", S_IRUGO|S_IWUSR, pid_sched), > > #endif > > @@ -2310,6 +2374,7 @@ static const struct pid_entry tid_base_stuff[] = { > > INF("environ", S_IRUSR, pid_environ), > > INF("auxv", S_IRUSR, pid_auxv), > > INF("status",S_IRUGO, pid_status), > > + INF("limits",S_IRUGO, pid_limits), > > Here too. Given that making it S_IRUSR would still accomplish the goals that I set out for, I certainly have no objections. New patch attached with permissions changed. Regards Neil Signed-off-by: Neil Horman <[EMAIL PROTECTED]> base.c | 65 + 1 file changed, 65 insertions(+) diff --git a/fs/proc/base.c b/fs/proc/base.c index ed2b224..b3ddf08 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -74,6 +74,7 @@ #include #include #include +#include #include "internal.h" /* NOTE: @@ -323,6 +324,68 @@ static int proc_oom_score(struct task_struct *task, char *buffer) return sprintf(buffer, "%lu\n", points); } +struct limit_names { + char *name; + char *unit; +}; + +static struct limit_names lnames[RLIM_NLIMITS] = { + [RLIMIT_CPU] = {"Max cpu time", "ms"}, + [RLIMIT_FSIZE] = {"Max file size", "bytes"}, + [RLIMIT_DATA] = {"Max data size", "bytes"}, + [RLIMIT_STACK] = {"Max stack size", "bytes"}, + [RLIMIT_CORE] = {"Max core file size", "bytes"}, + [RLIMIT_RSS] = {"Max resident set", "bytes"}, + [RLIMIT_NPROC] = {"Max processes", "processes"}, + [RLIMIT_NOFILE] = {"Max open files", "files"}, + [RLIMIT_MEMLOCK] = {"Max locked memory", "bytes"}, + [RLIMIT_AS] = {"Max address space", "bytes"}, + [RLIMIT_LOCKS] = {"Max file locks", "locks"}, + [RLIMIT_SIGPENDING] = {"Max pending signals", "signals"}, + [RLIMIT_MSGQUEUE] = {"Max msgqueue size", "bytes"}, + [RLIMIT_NICE] = {"Max nice priority", NULL}, + [RLIMIT_RTPRIO] = {"Max realtime priority", NULL}, +}; + +/* Display limits for a process */ +static int proc_pid_limits(struct task_struct *task, char *buffer) +{ + unsigned int i; + int count = 0; + char *bufptr = buffer; + + struct rlimit rlim[RLIM_NLIMITS]; + + read_lock(&tasklist_lock); + memcpy(rlim, task->signal->rlim, (sizeof(struct rlimit) * RLIM_NLIMITS)); + read_unlock(&tasklist_lock); + + /* +* print the file header +*/ + count += sprintf(&bufptr[count], "%-25s %-20s %-20s %-10s\n", + "Limit","Soft Limit","Hard Limit","Units"); + + for (i=0; i < RLIM_NLIMITS; i++) { + if (rlim[i].rlim_cur == RLIM_INFINITY) + count += sprintf(&bufptr[count], "%-25s %-20s ", lnames[i].name,"unlimited"); + else + count += sprintf(&bufptr[count], "%-25s %-20lu ", lnames[i].name, rlim[i].rlim_cur); + + if (rlim[i].rlim_max == RLIM_INFINITY) + count += sprintf(&bufptr[count], "%-20s ","unlimited"); + else + count += sprintf(&bufptr[count], "%-20lu ", rlim[i].rlim_max); + + if (lnames[i].unit) + count += sprintf(&bufptr[count],"%-10s\n", lnames[i].unit); + else + count += sprintf(&bufptr[count],"\n"); + } + + return count; +} + // /* Here the fs part begins*/ // @@ -2017,6 +2080,7 @@ stati
Re: [PATCH]: proc: export a processes resource limits via proc/
On Mon, 13 Aug 2007 10:00:44 EDT, Neil Horman said: > Hey there- > Currently, there exists no method for a process to query the resource > limits of another process. They can be inferred via some mechanisms but they > cannot be explicitly determined. Given that this information can be usefull > to > know during the debugging of an application, I've written this patch which > exports all of a processes limits via /proc//limits. Tested successfully > by myself on x86 on top of 2.6.23-rc2-mm1. > // > /* Here the fs part begins*/ > // > @@ -2017,6 +2080,7 @@ static const struct pid_entry tgid_base_stuff[] = { > INF("environ",S_IRUSR, pid_environ), > INF("auxv", S_IRUSR, pid_auxv), > INF("status", S_IRUGO, pid_status), > + INF("limits", S_IRUGO, pid_limits), Any takers for S_IRUSR instead? Either that, or lay out the use case for making it S_IRUGO. (I'm OK on it being world-visible *if* there's a good and sane reason for it) > #ifdef CONFIG_SCHED_DEBUG > REG("sched", S_IRUGO|S_IWUSR, pid_sched), > #endif > @@ -2310,6 +2374,7 @@ static const struct pid_entry tid_base_stuff[] = { > INF("environ", S_IRUSR, pid_environ), > INF("auxv", S_IRUSR, pid_auxv), > INF("status",S_IRUGO, pid_status), > + INF("limits",S_IRUGO, pid_limits), Here too. pgp57bqEm55Ga.pgp Description: PGP signature
Re: [PATCH]: proc: export a processes resource limits via proc/
On Mon, 2007-08-13 at 10:00 -0400, Neil Horman wrote: > Hey there- > Currently, there exists no method for a process to query the resource > limits of another process. They can be inferred via some mechanisms but they > cannot be explicitly determined. Given that this information can be usefull > to > know during the debugging of an application, I've written this patch which > exports all of a processes limits via /proc//limits. Tested successfully > by myself on x86 on top of 2.6.23-rc2-mm1. since this information, by it's nature, is security sensitive, I would really really strongly suggest that you make this restricted to those processes that can ptrace the victim only... (which is basically "same user or root") Making this world readable is very much a bad thing to do - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH]: proc: export a processes resource limits via proc/
Hey there- Currently, there exists no method for a process to query the resource limits of another process. They can be inferred via some mechanisms but they cannot be explicitly determined. Given that this information can be usefull to know during the debugging of an application, I've written this patch which exports all of a processes limits via /proc//limits. Tested successfully by myself on x86 on top of 2.6.23-rc2-mm1. Thanks & Regards Neil Signed-off-by: Neil Horman <[EMAIL PROTECTED]> base.c | 65 + 1 file changed, 65 insertions(+) diff --git a/fs/proc/base.c b/fs/proc/base.c index ed2b224..b3ddf08 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -74,6 +74,7 @@ #include #include #include +#include #include "internal.h" /* NOTE: @@ -323,6 +324,68 @@ static int proc_oom_score(struct task_struct *task, char *buffer) return sprintf(buffer, "%lu\n", points); } +struct limit_names { + char *name; + char *unit; +}; + +static struct limit_names lnames[RLIM_NLIMITS] = { + [RLIMIT_CPU] = {"Max cpu time", "ms"}, + [RLIMIT_FSIZE] = {"Max file size", "bytes"}, + [RLIMIT_DATA] = {"Max data size", "bytes"}, + [RLIMIT_STACK] = {"Max stack size", "bytes"}, + [RLIMIT_CORE] = {"Max core file size", "bytes"}, + [RLIMIT_RSS] = {"Max resident set", "bytes"}, + [RLIMIT_NPROC] = {"Max processes", "processes"}, + [RLIMIT_NOFILE] = {"Max open files", "files"}, + [RLIMIT_MEMLOCK] = {"Max locked memory", "bytes"}, + [RLIMIT_AS] = {"Max address space", "bytes"}, + [RLIMIT_LOCKS] = {"Max file locks", "locks"}, + [RLIMIT_SIGPENDING] = {"Max pending signals", "signals"}, + [RLIMIT_MSGQUEUE] = {"Max msgqueue size", "bytes"}, + [RLIMIT_NICE] = {"Max nice priority", NULL}, + [RLIMIT_RTPRIO] = {"Max realtime priority", NULL}, +}; + +/* Display limits for a process */ +static int proc_pid_limits(struct task_struct *task, char *buffer) +{ + unsigned int i; + int count = 0; + char *bufptr = buffer; + + struct rlimit rlim[RLIM_NLIMITS]; + + read_lock(&tasklist_lock); + memcpy(rlim, task->signal->rlim, (sizeof(struct rlimit) * RLIM_NLIMITS)); + read_unlock(&tasklist_lock); + + /* +* print the file header +*/ + count += sprintf(&bufptr[count], "%-25s %-20s %-20s %-10s\n", + "Limit","Soft Limit","Hard Limit","Units"); + + for (i=0; i < RLIM_NLIMITS; i++) { + if (rlim[i].rlim_cur == RLIM_INFINITY) + count += sprintf(&bufptr[count], "%-25s %-20s ", lnames[i].name,"unlimited"); + else + count += sprintf(&bufptr[count], "%-25s %-20lu ", lnames[i].name, rlim[i].rlim_cur); + + if (rlim[i].rlim_max == RLIM_INFINITY) + count += sprintf(&bufptr[count], "%-20s ","unlimited"); + else + count += sprintf(&bufptr[count], "%-20lu ", rlim[i].rlim_max); + + if (lnames[i].unit) + count += sprintf(&bufptr[count],"%-10s\n", lnames[i].unit); + else + count += sprintf(&bufptr[count],"\n"); + } + + return count; +} + // /* Here the fs part begins*/ // @@ -2017,6 +2080,7 @@ static const struct pid_entry tgid_base_stuff[] = { INF("environ",S_IRUSR, pid_environ), INF("auxv", S_IRUSR, pid_auxv), INF("status", S_IRUGO, pid_status), + INF("limits", S_IRUGO, pid_limits), #ifdef CONFIG_SCHED_DEBUG REG("sched", S_IRUGO|S_IWUSR, pid_sched), #endif @@ -2310,6 +2374,7 @@ static const struct pid_entry tid_base_stuff[] = { INF("environ", S_IRUSR, pid_environ), INF("auxv", S_IRUSR, pid_auxv), INF("status",S_IRUGO, pid_status), + INF("limits",S_IRUGO, pid_limits), #ifdef CONFIG_SCHED_DEBUG REG("sched", S_IRUGO|S_IWUSR, pid_sched), #endif -- /*** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/