[PATCH] pre-decoded wchan output

[PATCH] pre-decoded wchan output

[Robert Love]

Linus,

Attached patch implements a /proc/#/wchan which provides a pre-decoded
wchan via kallsyms.  I.e.,

	[15:05:06]rml@phantasy:~$ cat /proc/1228/wchan
	wait4

Which is damn cool to me and will let ps(1) grab wchan information
without having to parse System.map.  It also means procps will not need
System.map.

If CONFIG_KALLSYMS is enabled, /proc/#/wchan exists and exports the
pre-decoded symbol name.  The old wchan value in /proc/#/stat is
hard-coded to zero.

If CONFIG_KALLSYMS is not enabled, /proc/#/wchan does not exist to
conserve memory.  In that case, the old wchan field in /proc/#/stat will
export the usual wchan address.

This will not break procps, however the wchan field will be zero without
an updated version if CONFIG_KALLSYMS is set.  That is fine as 2.5
requires an updated procps anyhow.  If CONFIG_KALLSYMS is not set,
things are unchanged.

The procps patch is available at:

http://tech9.net/rml/procps/patches/procps-wchan-rml-2.0.10.20021011-1.patch

and ready for merging into procps CVS.

Patch is against current BK.  Please, apply.

	Robert Love

Implement /proc/#/wchan, a pre-decoded wchan

 Documentation/filesystems/proc.txt |    1 +
 fs/proc/array.c                    |   10 ++++++----
 fs/proc/base.c                     |   33 +++++++++++++++++++++++++++++++++
 3 files changed, 40 insertions(+), 4 deletions(-)

diff -urN linux-2.5.43/fs/proc/array.c linux/fs/proc/array.c
--- linux-2.5.43/fs/proc/array.c	2002-10-16 22:55:13.000000000 -0400
+++ linux/fs/proc/array.c	2002-10-16 23:26:19.000000000 -0400
@@ -298,7 +298,7 @@
 
 int proc_pid_stat(struct task_struct *task, char * buffer)
 {
-	unsigned long vsize, eip, esp, wchan;
+	unsigned long vsize, eip, esp;
 	long priority, nice;
 	int tty_pgrp = -1, tty_nr = 0;
 	sigset_t sigign, sigcatch;
@@ -331,8 +331,6 @@
 		up_read(&mm->mmap_sem);
 	}
 
-	wchan = get_wchan(task);
-
 	collect_sigign_sigcatch(task, &sigign, &sigcatch);
 
 	/* scale priority and nice values from timeslices to -20..20 */
@@ -384,7 +382,11 @@
 		task->blocked.sig[0] & 0x7fffffffUL,
 		sigign      .sig[0] & 0x7fffffffUL,
 		sigcatch    .sig[0] & 0x7fffffffUL,
-		wchan,
+#ifndef CONFIG_KALLSYMS
+		get_wchan(task),
+#else
+		0UL,
+#endif
 		task->nswap,
 		task->cnswap,
 		task->exit_signal,
diff -urN linux-2.5.43/fs/proc/base.c linux/fs/proc/base.c
--- linux-2.5.43/fs/proc/base.c	2002-10-15 23:28:25.000000000 -0400
+++ linux/fs/proc/base.c	2002-10-16 23:24:17.000000000 -0400
@@ -28,6 +28,7 @@
 #include <linux/namespace.h>
 #include <linux/mm.h>
 #include <linux/smp_lock.h>
+#include <linux/kallsyms.h>
 
 /*
  * For hysterical raisins we keep the same inumbers as in the old procfs.
@@ -54,6 +55,7 @@
 	PROC_PID_MAPS,
 	PROC_PID_CPU,
 	PROC_PID_MOUNTS,
+	PROC_PID_WCHAN,
 	PROC_PID_FD_DIR = 0x8000,	/* 0x8000-0xffff */
 };
 
@@ -81,6 +83,9 @@
   E(PROC_PID_ROOT,	"root",		S_IFLNK|S_IRWXUGO),
   E(PROC_PID_EXE,	"exe",		S_IFLNK|S_IRWXUGO),
   E(PROC_PID_MOUNTS,	"mounts",	S_IFREG|S_IRUGO),
+#ifdef CONFIG_KALLSYMS
+  E(PROC_PID_WCHAN,	"wchan",	S_IFREG|S_IRUGO),
+#endif
   {0,0,NULL,0}
 };
 #undef E
@@ -245,6 +250,28 @@
 	return res;
 }
 
+#ifdef CONFIG_KALLSYMS
+/*
+ * Provides a wchan file via kallsyms in a proper one-value-per-file format.
+ * Returns the resolved symbol.  If that fails, simply return the address.
+ */
+static int proc_pid_wchan(struct task_struct *task, char *buffer)
+{
+	const char *sym_name, *ignore;
+	unsigned long wchan, dummy;
+
+	wchan = get_wchan(task);
+
+	if (!kallsyms_address_to_symbol(wchan, &ignore, &dummy, &dummy,
+			&ignore, &dummy, &dummy, &sym_name,
+			&dummy, &dummy)) {
+		return sprintf(buffer, "%lu", wchan);
+	}
+
+	return sprintf(buffer, "%s", sym_name);
+}
+#endif
+
 /************************************************************************/
 /*                       Here the fs part begins                        */
 /************************************************************************/
@@ -1016,6 +1043,12 @@
 		case PROC_PID_MOUNTS:
 			inode->i_fop = &proc_mounts_operations;
 			break;
+#ifdef CONFIG_KALLSYMS
+		case PROC_PID_WCHAN:
+			inode->i_fop = &proc_info_file_operations;
+			ei->op.proc_read = proc_pid_wchan;
+			break;
+#endif
 		default:
 			printk("procfs: impossible type (%d)",p->type);
 			iput(inode);
diff -urN linux-2.5.43/Documentation/filesystems/proc.txt linux/Documentation/filesystems/proc.txt
--- linux-2.5.43/Documentation/filesystems/proc.txt	2002-10-15 23:27:48.000000000 -0400
+++ linux/Documentation/filesystems/proc.txt	2002-10-17 00:14:36.000000000 -0400
@@ -130,6 +130,7 @@
  stat    Process status                                 
  statm   Process memory status information              
  status  Process status in human readable form          
+ wchan   If CONFIG_KALLSYMS is set, a pre-decoded wchan
 ..............................................................................
 
 For example, to get the status information of a process, all you have to do is

Re: [PATCH] pre-decoded wchan output

[Christoph Hellwig]

On Thu, Oct 17, 2002 at 03:14:02PM -0400, Robert Love wrote:
> Linus,
> 
> Attached patch implements a /proc/#/wchan which provides a pre-decoded
> wchan via kallsyms.  I.e.,
> 
> 	[15:05:06]rml@phantasy:~$ cat /proc/1228/wchan
> 	wait4
> 
> Which is damn cool to me and will let ps(1) grab wchan information
> without having to parse System.map.  It also means procps will not need
> System.map.
> 
> If CONFIG_KALLSYMS is enabled, /proc/#/wchan exists and exports the
> pre-decoded symbol name.  The old wchan value in /proc/#/stat is
> hard-coded to zero.
> 
> If CONFIG_KALLSYMS is not enabled, /proc/#/wchan does not exist to
> conserve memory.  In that case, the old wchan field in /proc/#/stat will
> export the usual wchan address.
> 
> This will not break procps, however the wchan field will be zero without
> an updated version if CONFIG_KALLSYMS is set.  That is fine as 2.5
> requires an updated procps anyhow.  If CONFIG_KALLSYMS is not set,
> things are unchanged.

Can't you just left the old, nuerical one in even if CONFIG_KALLSYMS
ise set?  One ifdef less and far less surprises..

Re: [PATCH] pre-decoded wchan output

[Robert Love]

On Thu, 2002-10-17 at 15:58, Christoph Hellwig wrote:

> Can't you just left the old, nuerical one in even if CONFIG_KALLSYMS
> ise set?  One ifdef less and far less surprises..

But why?  Save the call to get_wchan()...

Ideally I would like to remove the field altogether but thats too much
breakage.

A value of zero in the field position is an indication the wchan file
exists, too.

The ifdefs there do not bother me.  I think its pretty clear why its
being done, although I could add a comment to the "0UL" value saying
"now in /proc/#/wchan" or whatever.

But, no, I do not agree.  No human can parse /proc/#/stats anyhow. 
Since procps needs to be updated for 3.0 anyhow, it will be fine.

	Robert Love

Re: [PATCH] pre-decoded wchan output

[David =?ISO-8859-1?Q?G=F3mez=22?= <david@pleyades.net>]

On Oct 17 at 03:14:02, Robert Love wrote:
> Which is damn cool to me and will let ps(1) grab wchan information
> without having to parse System.map.  It also means procps will not need
> System.map.

Hope this patch gets included in kernel 2.5 ;). I think is very nice to make
ps not to depend on System.map for resolving wchan. I'll give a try to your
patch right now.

-- 
David Gómez

"The question of whether computers can think is just like the question of
 whether submarines can swim." -- Edsger W. Dijkstra

Re: [PATCH] pre-decoded wchan output

[Pavel Machek]

Hi!

> > Can't you just left the old, nuerical one in even if CONFIG_KALLSYMS
> > ise set?  One ifdef less and far less surprises..
> 
> But why?  Save the call to get_wchan()...

Yes, and force users to update procps for no good reason. And "new"
procps will still need code to deal with get_wchan themselves... Plus
you loose information by killing get_wchan() -- two different wait
points in one function seems very possible to me.
								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: [PATCH] pre-decoded wchan output

[Robert Love]

On Mon, 2002-10-21 at 19:08, Pavel Machek wrote:

> Yes, and force users to update procps for no good reason. And "new"
> procps will still need code to deal with get_wchan themselves... Plus
> you loose information by killing get_wchan() -- two different wait
> points in one function seems very possible to me.

- users of 2.5 need a new procps but only wchan is "broken" and
  only if CONFIG_KALLSYMS is set anyhow

- I did not kill get_wchan, just do not use it in stat - in fact
  I use it in the new wchan approach, too

- its not an issue now because the updated patch (posted 5 days
  after this email you are replying to) keeps wchan.

So you got your way.  Look at the patch posted 22 Oct.  It is now in
2.5-mm.

	Robert Love