Re: [PATCH] sector_t overflow in block layer

Hi!

> > Why isn't that just a 
> > 
> > 	if (unlikely(sector != (sector_t)sector))
> > 
> > and that's it? What does this have to do with CONFIG_LBD or BITS_PER_LONG, 
> > or anything at all?
> > 
> > If the sector number fits in a sector_t, we're all good.
> 
> I think you missed that Andrewas said he is worried about 64-bit overflows 
> as well.  And you would not catch those with the sector != 

Can 64-bit really overflow? That's 16 000 Peta bytes, AFAICS. Does
anyone really have disk array over 100 Peta bytes? How much space does
Google have, for example?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/

---

• References:
  • [PATCH] sector_t overflow in block layer
    • From: Andreas Dilger <[email protected]>
  • Re: [PATCH] sector_t overflow in block layer
    • From: Linus Torvalds <[email protected]>
  • Re: [PATCH] sector_t overflow in block layer
    • From: Anton Altaparmakov <[email protected]>

• Prev by Date: Re: swapper: page allocation failure.
• Next by Date: Re: 2.6.17-rc2+ regression -- audio skipping
• Previous by thread: Re: [PATCH] sector_t overflow in block layer
• Next by thread: ptrace() - is kernel drop PT_PTRACED bit in task->ptrace?
• Index(es):
  • Date
  • Thread

[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]