linux-kernel - Re: [PATCH 01/14] sysfs: fix i

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070427153245.GA10999@suse.de>
Date:	Fri, 27 Apr 2007 08:32:45 -0700
From:	Greg KH <gregkh@...e.de>
To:	Eric Sandeen <sandeen@...deen.net>
Cc:	Tejun Heo <htejun@...il.com>, maneesh@...ibm.com,
	dmitry.torokhov@...il.com, cornelia.huck@...ibm.com,
	oneukum@...e.de, rpurdie@...ys.net, James.Bottomley@...elEye.com,
	stern@...land.harvard.edu, linux-kernel@...r.kernel.org
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/