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
Index: swap_pager.c =================================================================== --- swap_pager.c (revision 218966) +++ swap_pager.c (working copy) @@ -2426,7 +2426,8 @@ vm_map_t map; vm_map_entry_t cur; vm_object_t object; - vm_offset_t count, n; + vm_ooffset_t n; + vm_offset_t count; map = &vmspace->vm_map; count = 0;
_______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
