public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Bellon <mbellon@mvista.com>
To: linux-kernel@vger.kernel.org
Subject: [PATCH] 2.4.20 /proc returns EINVAL when ENOENT is appropriate
Date: Mon, 15 Dec 2003 14:07:55 -0700	[thread overview]
Message-ID: <3FDE22AB.8020806@mvista.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

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?

[-- Attachment #2: proc-patch --]
[-- Type: text/plain, Size: 855 bytes --]

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;
 	/*

                 reply	other threads:[~2003-12-15 21:08 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3FDE22AB.8020806@mvista.com \
    --to=mbellon@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox