pre-decoded wchan output

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
@@ -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
@@ -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
@@ -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

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

Hi!

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?

- 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

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