Q: Since when is a directory entry allowed to be duplicate?
A: Since Linux 2.6.14!
$ uname -r
2.6.14.3-bs2-mroute
The only sysfs-related change is the use of a custom DSDT, which is new to
this kernel.
$ ls -li /sys/devices/system/
totale 0
425 drwxr-xr-x 3 root root 0 7 dic 03:57 acpi
17 drwxr-xr-x 3 root root 0 7 dic 03:57 cpu
197 drwxr-xr-x 3 root root 0 7 dic 03:57 i8237
195 drwxr-xr-x 3 root root 0 7 dic 03:57 i8259
204 drwxr-xr-x 3 root root 0 7 dic 03:57 ioapic
242 drwxr-xr-x 3 root root 0 7 dic 03:57 irqrouter
202 drwxr-xr-x 3 root root 0 7 dic 03:57 lapic
421 drwxr-xr-x 3 root root 0 7 dic 03:57 lapic_nmi
199 drwxr-xr-x 3 root root 0 7 dic 03:57 machinecheck
193 drwxr-xr-x 3 root root 0 7 dic 03:57 timer
193 drwxr-xr-x 3 root root 0 7 dic 03:57 timer
$ ls -li /sys/devices/system/ -d
16 drwxr-xr-x 12 root root 0 7 dic 03:57 /sys/devices/system/
From the hard link count you can also verify (tested with find -noleaf, output
below) that
the duplicate "timer" dentry is not counted again in the hard link count.
(perfectly reproducible, it's not a race condition on "ls" time - and it
duplicates always the same dentry. I've not tested rebooting though).
lsmod output and .config attached. Additionally, "strace -v" output attached
(SysfsRootBugreport.bz2) - the relevant line is the getdents call
on /sys/devices/system:
getdents(3, {{d_ino=16, d_off=1, d_reclen=24, d_name="."} {d_ino=7, d_off=2,
d_reclen=24, d_name=".."} {d_ino=425, d_off=3, d_reclen=24, d_name="acpi"}
{d_ino=421, d_off=4, d_reclen=32, d_name="lapic_nmi"} {d_ino=242, d_off=5,
d_reclen=32, d_name="irqrouter"} {d_ino=204, d_off=6, d_reclen=32,
d_name="ioapic"} {d_ino=202, d_off=7, d_reclen=32, d_name="lapic"}
{d_ino=199, d_off=8, d_reclen=32, d_name="machinecheck"} {d_ino=197, d_off=9,
d_reclen=32, d_name="i8237"} {d_ino=195, d_off=10, d_reclen=32,
d_name="i8259"}
/*The dentry*/
{d_ino=193, d_off=11, d_reclen=32, d_name="timer"}
/*Again*/
{d_ino=193, d_off=12, d_reclen=32, d_name="timer"}
{d_ino=17, d_off=13, d_reclen=24, d_name="cpu"}}, 4096) = 384
I have not tested if this bug is new to this kernel.
Finally:
# find /sys/devices/system/ -noleaf
/sys/devices/system/
/sys/devices/system/acpi
/sys/devices/system/acpi/acpi0
/sys/devices/system/lapic_nmi
/sys/devices/system/lapic_nmi/lapic_nmi0
/sys/devices/system/irqrouter
/sys/devices/system/irqrouter/irqrouter0
/sys/devices/system/ioapic
/sys/devices/system/ioapic/ioapic0
/sys/devices/system/lapic
/sys/devices/system/lapic/lapic0
/sys/devices/system/machinecheck
/sys/devices/system/machinecheck/machinecheck0
/sys/devices/system/machinecheck/machinecheck0/check_interval
/sys/devices/system/machinecheck/machinecheck0/tolerant
/sys/devices/system/machinecheck/machinecheck0/bank4ctl
/sys/devices/system/machinecheck/machinecheck0/bank3ctl
/sys/devices/system/machinecheck/machinecheck0/bank2ctl
/sys/devices/system/machinecheck/machinecheck0/bank1ctl
/sys/devices/system/machinecheck/machinecheck0/bank0ctl
/sys/devices/system/i8237
/sys/devices/system/i8237/i82370
/sys/devices/system/i8259
/sys/devices/system/i8259/i82590
/sys/devices/system/timer
/sys/devices/system/timer
/sys/devices/system/cpu
/sys/devices/system/cpu/cpu0
/sys/devices/system/cpu/cpu0/cpufreq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
/sys/devices/system/cpu/cpu0/cpufreq/affected_cpus
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq
(and -noleaf is indeed needed, because otherwise find does not recurse inbto
cpu0/)
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
On Fri, Dec 09, 2005 at 06:48:41PM +0100, Blaisorblade wrote:
> Q: Since when is a directory entry allowed to be duplicate?
> A: Since Linux 2.6.14!
>
> $ uname -r
> 2.6.14.3-bs2-mroute
>
> The only sysfs-related change is the use of a custom DSDT, which is new to
> this kernel.
Known bug, fixed in the 2.6.15-rc kernel tree. It was a timer
registering with the same name in two places :(
And yes, we should have more sysfs checks for stuff like this, any
patches in this area would be greatly appreciated.
thanks,
greg k-h
On Friday 09 December 2005 18:55, Greg KH wrote:
> On Fri, Dec 09, 2005 at 06:48:41PM +0100, Blaisorblade wrote:
> > Q: Since when is a directory entry allowed to be duplicate?
> > A: Since Linux 2.6.14!
> >
> > $ uname -r
> > 2.6.14.3-bs2-mroute
> >
> > The only sysfs-related change is the use of a custom DSDT, which is new
> > to this kernel.
> Known bug, fixed in the 2.6.15-rc kernel tree. It was a timer
> registering with the same name in two places :(
Sorry for answering so late (my latency in checking "spam" false positives is
big) but shouldn't this have been backported to -stable? Also is this known
to cause hangs at unmount time (I experience them at times and they're not
network FSs-related) ?
> And yes, we should have more sysfs checks for stuff like this, any
> patches in this area would be greatly appreciated.
No idea about all kfoo stuff at the present moment^H^H^H year, sorry. Can't
help.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
On Fri, Dec 23, 2005 at 11:25:11PM +0100, Blaisorblade wrote:
> On Friday 09 December 2005 18:55, Greg KH wrote:
> > On Fri, Dec 09, 2005 at 06:48:41PM +0100, Blaisorblade wrote:
> > > Q: Since when is a directory entry allowed to be duplicate?
> > > A: Since Linux 2.6.14!
> > >
> > > $ uname -r
> > > 2.6.14.3-bs2-mroute
> > >
> > > The only sysfs-related change is the use of a custom DSDT, which is new
> > > to this kernel.
>
> > Known bug, fixed in the 2.6.15-rc kernel tree. It was a timer
> > registering with the same name in two places :(
>
> Sorry for answering so late (my latency in checking "spam" false positives is
> big) but shouldn't this have been backported to -stable?
It should, if someone sends the patch to do so to the stable@ email
address :)
> Also is this known to cause hangs at unmount time (I experience them
> at times and they're not network FSs-related) ?
Not that I have heard about, but you never know...
thanks,
greg k-h