linux-kernel - Re: [PATCH 3/3] have pipefs ensure i_ino uniqueness by calling iunique and hashing the inode

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] [day] [month] [year] [list]

Message-ID: <45BF5E68.4070000@redhat.com>
Date:	Tue, 30 Jan 2007 10:04:08 -0500
From:	Jeff Layton <jlayton@...hat.com>
To:	Eric Dumazet <dada1@...mosbay.com>
CC:	Kirill Korotaev <dev@...nvz.org>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] have pipefs ensure i_ino uniqueness by calling iunique
 and hashing the inode

Eric Dumazet wrote:
 >
 > For dentry name, we certainly could use "[address of inode]" instead
 > of "[inode number]" to get unicity, but do we care ?
 >
 > For st_ino values on pipefs and sockets, I doubt any user application would
 > care. I never had to fstat() a socket fd. Of course it's a file descriptor,
 > but all we really want to do with this kind of file descriptor is to call
 > socket API.
 >
 > And for some heavy loaded internet servers , the additional cost of
 > insert/delete a node in a machine shared tree could be a problem.
 >

Granted, I've never had to stat a pipe fd either, so maybe in the big scheme
of things, it's not that important. Still, I think we can probably do this
without a great deal of added complexity or performance impact.

If changing the stuff between the brackets in the dentry name to something
besides inode number is OK, then we can defer the assignment of the inode
number until it's actually needed. For pipefs calls, this means we can only
assign an inode number when a stat call is actually done. So anyone who needs
that info can get it, and anyone who doesn't care about it shouldn't be
greatly impacted by it.

I'll be following up this email with a couple of patches for comment...

-- Jeff

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