lkml.org 
[lkml]   [2007]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2007-04-27 17:39    [W:0.121 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site