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

Previous thread: [PATCH] [input] USB touchscreen by Vladimir Shebordaev on Thursday, September 6, 2007 - 6:14 pm. (1 message)

Next thread: [PATCH 0/3] core: fix build error when referencing arch specific structures by travis on Friday, September 7, 2007 - 12:09 am. (5 messages)
To: linux-kernel <linux-kernel@...>
Cc: David Brownell <david-b@...>
Date: Thursday, September 6, 2007 - 6:23 pm

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

To: Chuck Ebbert <cebbert@...>
Cc: linux-kernel <linux-kernel@...>, David Brownell <david-b@...>
Date: Saturday, September 15, 2007 - 3:44 am

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.

-

To: <cebbert@...>, <akpm@...>
Cc: <linux-kernel@...>
Date: Saturday, September 15, 2007 - 2:50 pm

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

-

To: David Brownell <david-b@...>
Cc: <cebbert@...>, <linux-kernel@...>
Date: Sunday, September 16, 2007 - 1:10 am

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

To: Andrew Morton <akpm@...>
Cc: <cebbert@...>, <linux-kernel@...>
Date: Wednesday, September 19, 2007 - 1:21 am

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;

-

Previous thread: [PATCH] [input] USB touchscreen by Vladimir Shebordaev on Thursday, September 6, 2007 - 6:14 pm. (1 message)

Next thread: [PATCH 0/3] core: fix build error when referencing arch specific structures by travis on Friday, September 7, 2007 - 12:09 am. (5 messages)