All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: cebbert@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: Two identical entries for "rtc" in /proc/devices
Date: Tue, 18 Sep 2007 22:21:14 -0700	[thread overview]
Message-ID: <200709182221.14751.david-b@pacbell.net> (raw)
In-Reply-To: <20070915221015.02aad5ea.akpm@linux-foundation.org>

On Saturday 15 September 2007, Andrew Morton wrote:
> On Sat, 15 Sep 2007 11:50:21 -0700 David Brownell <david-b@pacbell.net> wrote:
> 
> > > On Thu, 06 Sep 2007 18:23:22 -0400 Chuck Ebbert <cebbert@redhat.com> wrote:
> > >
> > > > # ls -li
> > > > total 0
> > > > 4026532007 -r--r--r-- 1 root root 0 Sep  6 18:18 nvram
> > > > 4026532067 -r--r--r-- 1 root root 0 Sep  6 18:18 rtc
> > > > 4026532067 -r--r--r-- 1 root root 0 Sep  6 18:18 rtc
> > > > 4026532056 -rw-r--r-- 1 root root 0 Sep  6 18:18 snd-page-alloc
> > >
> > > ...
> > 
> > Semes pretty clear that this must be procfs itself...
> > when a filesystem sees a name in a directory, it should
> > refuse to make another file with the same name.  And it
> > should *never* reuse inode numbers...
>
> ...
>
> procfs can reject the attempt to create the file, but the bottom line
> is that two different callsites are trying to create the same file.  One
> of those callsites needs fixing?

Both of those call sites have code to handle procfs rejecting
the file creation; nothing to fix.  And anyway, there's no way
this is a *caller* bug!

The missing step seems to be that proc_register() doesn't bother
to check whether there's already an entry for that file.  Which
is what the appended *UNTESTED* patch does (it compiles though).

- Dave

--- g26.orig/fs/proc/generic.c	2007-09-18 22:08:44.000000000 -0700
+++ g26/fs/proc/generic.c	2007-09-18 22:14:07.000000000 -0700
@@ -521,10 +521,11 @@ static const struct inode_operations pro
 	.setattr	= proc_notify_change,
 };
 
-static int proc_register(struct proc_dir_entry * dir, struct proc_dir_entry * dp)
+static int proc_register(struct proc_dir_entry *dir, struct proc_dir_entry *dp)
 {
 	unsigned int i;
-	
+	struct proc_dir_entry *de;
+
 	i = get_inode_number();
 	if (i == 0)
 		return -EAGAIN;
@@ -547,6 +548,16 @@ static int proc_register(struct proc_dir
 	}
 
 	spin_lock(&proc_subdir_lock);
+
+	for (de = dir->subdir; de ; de = de->next) {
+		if (de->namelen != dp->namelen)
+			continue;
+		if (!memcmp(de->name, dp->name, de->namelen)) {
+			spin_unlock(&proc_subdir_lock);
+			return -EEXIST;
+		}
+	}
+
 	dp->next = dir->subdir;
 	dp->parent = dir;
 	dir->subdir = dp;


      reply	other threads:[~2007-09-19  5:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-06 22:23 Two identical entries for "rtc" in /proc/devices Chuck Ebbert
2007-09-15  7:44 ` Andrew Morton
2007-09-15 18:50   ` David Brownell
2007-09-16  5:10     ` Andrew Morton
2007-09-19  5:21       ` David Brownell [this message]

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=200709182221.14751.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=akpm@linux-foundation.org \
    --cc=cebbert@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.