Messages in this thread | | | Date | Fri, 27 Apr 2007 08:32:45 -0700 | From | Greg KH <> | Subject | Re: [PATCH 01/14] sysfs: fix i_ino handling in sysfs |
| |
On Fri, Apr 27, 2007 at 10:29:46AM -0500, Eric Sandeen wrote: > 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...
Yes, this turned out to be a problem as the ppc people found out :)
Tejun had some follow-on patches fixing this issue up.
thanks,
greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |