svn commit: r218966 - head/sys/vm

Bruce Cran bruce at cran.org.uk
Wed Feb 23 22:12:04 UTC 2011


On Thu, 2011-02-24 at 08:23 +1100, Bruce Evans wrote:

> The bug seems to have been overflow in this calculation.  `start' and
> `end' have type vm_offset_t and large style bugs (missing prefixes in
> their names) so they are hard to grep for.  When n is 32 bits int and
> PAGE_SIZE is 2**12, the assignment to n overflows at a difference of 8TB,
> but this probably can't happen (see above).  swap_bcnt still has type
> int; SWAP_META_PAGES is 1, 2, 4, 8 or 16; thus swp_bcount * SWAP_META_PAGES
> may overflow at 2**31/16 = 128 M.  If this doesn't overflow, but has its
> maximal value of about 128 M, then multiplying it by "int n" may overflow
> when n is just 32.  Then, if nothing has overflowed, division by
> object->size reduces to a relatively small count in pages.  object->size
> seems to have type vm_pindex_t which is 64 bits even on i386 (since it
> is associated with vm_ooffset_t and not vm_offset_t, and vm_ooffset_t
> must be 64 bits to support file of sizes >= 2GB although vm_pindex_t only
> needs to be more than 32 bits to support files of sizes >= 8 TB (with
> PAGE_SIZE = 2**12).  object->size has even larger bugs than `start' and
> `end', since it is more global.

I've attached a patch which changes 'n' to be of type vm_ooffset_t. I
think this should fix the overflow bug?

-- 
Bruce Cran
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vm.diff
Type: text/x-patch
Size: 341 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20110223/bf1e7251/vm.bin


More information about the svn-src-head mailing list