[PATCH] 2.4.20 /proc returns EINVAL when ENOENT is appropriate

[Mark Bellon]

The attached patch fixes a problem in /proc that was seen in 2.4.20 but 
seems applicable to 2.4.x. It is possible for a process to be scanning 
/proc for processes and to access a cached task_struct pointer (via the 
/proc list entry) even though the associated process is dying/dead - and 
the /proc list entry has not yet been removed. The /proc code detects 
this (via task PID equal to zero) and currently returns EINVAL which is 
confusing at best.

Since it is entirely possible for a /proc user to encounter ENOENT on 
lookup/traverse at any time this patch changes the returned status to 
ENOENT when the task PID is zero. Adding locking seemed like overkill.

mark

P.S.

One could argue that the EINVAL should really be ENOMEM in this case. 
Perhaps this should also be discussed?
Index: base.c
===================================================================
RCS file: /cvsdev/mvl-kernel/linux/fs/proc/base.c,v
retrieving revision 1.3.34.4.6.1
diff -a -u -r1.3.34.4.6.1 base.c
--- base.c	29 Oct 2003 05:09:35 -0000	1.3.34.4.6.1
+++ base.c	15 Dec 2003 20:00:12 -0000
@@ -882,22 +882,23 @@
 	struct task_struct *task = dir->u.proc_i.task;
 	struct pid_entry *p;
 
-	error = -ENOENT;
-	inode = NULL;
-
 	for (p = base_stuff; p->name; p++) {
 		if (p->len != dentry->d_name.len)
 			continue;
 		if (!memcmp(dentry->d_name.name, p->name, p->len))
 			break;
 	}
-	if (!p->name)
+
+	if (!p->name) {
+		error = -ENOENT;
 		goto out;
+	}
 
-	error = -EINVAL;
 	inode = proc_pid_make_inode(dir->i_sb, task, p->type);
-	if (!inode)
+	if (!inode) {
+		error = task->pid ? -EINVAL : -ENOENT;
 		goto out;
+	}
 
 	inode->i_mode = p->mode;
 	/*