On Fri, 17 November 2006 06:50:37 -0700, Matthew Wilcox wrote:
> On Fri, Nov 17, 2006 at 08:43:00AM -0500, Jeff Layton wrote:
> > +/* convert an inode address into an unsigned int and xor it with a random value
> > + * determined at boot time */
> > +static inline unsigned int inode_to_uint (struct inode *inode)
> > +{
> > + return ((((unsigned long) (inode - (struct inode *) 0))
> > + ^ inode_xor_mask) & 0xffffffff);
> > +}
>
> Seems a little obfuscated. Why not simply:
>
> return ((unsigned long)inode ^ inode_xor_mask) & 0xffffffff;
Because that could give i_ino collisions with >4GiB memory. The
original would require something like 2PiB memory before the first
collision.
What I wonder, though, is how much code gcc generates for the pointer
arithmetic. Maybe something like
return (((unsigned long)inode >> INODE_SHIFT) ^ inode_xor_mask)
& 0xffffffff);
would be faster.
> > @@ -125,7 +135,6 @@ static struct inode *alloc_inode(struct
> > inode->i_size = 0;
> > inode->i_blocks = 0;
> > inode->i_bytes = 0;
> > - inode->i_generation = 0;
> > #ifdef CONFIG_QUOTA
> > memset(&inode->i_dquot, 0, sizeof(inode->i_dquot));
> > #endif
>
> It seems to me that filesystems with fake inodes could instead
> initialise i_generation to, say, jiffies. What do you think to that?
If you are talking about inode_init_once() here, I like the idea.
i_generation must be initialized somehow, even a 4-byte information
leak could be a problem. But the initialization should happen in the
rare event of allocating a slab page, not when reusing a deleted
inode.
Jeff, why do you increment i_generation in new_inode instead of here?
Jörn
--
...one more straw can't possibly matter...
-- Kirby Bakken
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
