Re: [PATCH] make last_inode counter in new_inode 32-bit on kernels that offer x86 compatability

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jörn Engel wrote:
> On Mon, 6 November 2006 14:50:58 -0600, Eric Sandeen wrote:
>>> While you're at it, how about making last_ino per-sb instead of
>>> system-wide?  ino collisions after a wrap are just as bad as inos
>>> beyond 32bit.  And this should be a fairly simple method to reduce the
>>> risk.
>> Using a global counter for multiple filesystems should actually -reduce-
>> the chance of a collision on the same filesystem, since after you wrap the
>> recycled number may go to a different filesystem.
> 
> You're missing something.  The chance for a collision _per wrap_ is
> reduced, as you said.  But the number of wraps goes up.  Overall and
> for large numbers, the two effects compensate each other.

Well, one concern is an intentional exploit.  In which case "longer
time" and "shorter time" don't matter -so- much.  If it can happen at
all, it's bad, period.

OTOH if one filesystem (say, pipes) can wrap the numbers very quickly,
while other spaces are otherwise more immune, then having it global puts
everything using it at a bit more risk.

*shrug* I dunno, it's probably not worth arguing this point, it needs to
be fixed properly in any case. :)

-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux