Two identical entries for "rtc" in /proc/devices

Two identical entries for "rtc" in /proc/devices

[Chuck Ebbert]

# 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

kernel 2.6.22.6 on a Dell Precision 390:

# CONFIG_RTC is not set
# CONFIG_RTC_DEBUG is not set
CONFIG_GEN_RTC=y
CONFIG_GEN_RTC_X=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
CONFIG_RTC_DRV_CMOS=m
CONFIG_RTC_DRV_DS1307=m
CONFIG_RTC_DRV_DS1553=m
CONFIG_RTC_DRV_DS1672=m
CONFIG_RTC_DRV_DS1742=m
# CONFIG_RTC_DRV_EP93XX is not set
CONFIG_RTC_DRV_ISL1208=m
CONFIG_RTC_DRV_MAX6900=m
# CONFIG_RTC_DRV_M48T86 is not set
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
CONFIG_RTC_DRV_RS5C372=m
# CONFIG_RTC_DRV_SA1100 is not set
# CONFIG_RTC_DRV_TEST is not set
CONFIG_RTC_DRV_X1205=m
CONFIG_RTC_DRV_V3020=m

CONFIG_HPET_EMULATE_RTC=y

CONFIG_EFI_RTC=y

Re: Two identical entries for "rtc" in /proc/devices

[Andrew Morton]

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

Next -mm has

procfs-detect-duplicate-names.patch
procfs-detect-duplicate-names-fix.patch
procfs-detect-duplicate-names-fix-fix-2.patch

which will at least tell us who the second offender is.

I have a vague memory that this is due to selecting two different types of
rtc in config.  Perhaps a Kconfig fix is needed, dunno.

Re: Two identical entries for "rtc" in /proc/devices

[David Brownell]

> 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
>
> Next -mm has
>
> procfs-detect-duplicate-names.patch
> procfs-detect-duplicate-names-fix.patch
> procfs-detect-duplicate-names-fix-fix-2.patch
>
> which will at least tell us who the second offender is.

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

Re: Two identical entries for "rtc" in /proc/devices

[Andrew Morton]

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
> >
> > Next -mm has
> >
> > procfs-detect-duplicate-names.patch
> > procfs-detect-duplicate-names-fix.patch
> > procfs-detect-duplicate-names-fix-fix-2.patch
> >
> > which will at least tell us who the second offender is.
> 
> 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?

Re: Two identical entries for "rtc" in /proc/devices

[David Brownell]

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;