Tejun Heo wrote:
Inode number handling was incorrect in two ways.
1. sysfs uses the inode number allocated by new_inode() and never
hashes it. When reporting the inode number, it uses iunique() if
inode is inaccessible. This is incorrect because iunique() assumes
the inodes are hashed. This can cause duplicate inode numbers and
the condition is likely to happen because new_inode() and iunique()
use separate increasing static counters to scan for empty slot.
2. sysfs_dirent->s_dentry can go away anytime and can't be referenced
unless the caller knows the dentry is not and not going to be
deleted.
This patch makes sysfs report the pointer to sysfs_dirent as ino.
ino_t is always as big as or larger than unsigned long && sysfs_dirent
hierarchy is the internal representation of the sysfs tree, so it
makes sense and simple to implement.
what about 32-bit stats from 32-bit apps on 64-bit systems? This will
make 64-bit inode numbers commonplace in sysfs; will this cause
problems? it seems that if they get truncated to 32 bits the
possibility of duplicate inode nrs will come back...
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
