Re: [PATCH 01/14] sysfs: fix i_ino handling in sysfs

[Eric Sandeen <sandeen@sandeen.net>]

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