linux-kernel - one or more brain cells staggering towards 64 bit inode numbers

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 for Android: free password hash cracker in your pocket

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

Message-ID: <AANLkTim_fmTFr3gPAXE9Q77nzKxreOHyU7JXamKfohxv@mail.gmail.com>
Date:	Wed, 20 Oct 2010 13:41:03 -0500
From:	David Nicol <davidnicol@...il.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: one or more brain cells staggering towards 64 bit inode numbers

fs.h contains, in part

struct inode {
	struct hlist_node	i_hash;
	struct list_head	i_list;		/* backing dev IO list */
	struct list_head	i_sb_list;
	struct list_head	i_dentry;
	unsigned long		i_ino;
	atomic_t		i_count;
	unsigned int		i_nlink;
	uid_t			i_uid;
	gid_t			i_gid;
	dev_t			i_rdev;
	unsigned int		i_blkbits;
	u64			i_version;
	loff_t			i_size;



how much chaos would ensue if the inode number would change to a u64?
Aside from, of course, having to recompile anything
file-system-related on a 32-bit system to use the resulting kernel?
Probably better to do an #ifdef based on sizeof that member and zig or
zag depending.



-- 
"In one instance, a rai being transported by canoe was accidentally
dropped and sunk to the sea floor. Although it was never seen again,
everyone agreed that the rai must still be there, so it continued to
be transacted as genuine currency" -- Wikipedia
--
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/