On Tue, 11 Oct 2005, Nick Piggin wrote:
> Alan Cox wrote:
> >
> > 32000 processes each with 2G mapped as zero pages appears to allow the
> > refcount to overflow ?
>
> That's right (though I count only 8192 required with 4K page size) -
> close to impossible on 32-bit architectures, though not so the 64-bit
> ones, which still use 32-bits for count and mapcount.
It needs 16GB of page table space to get the mapcount to go negative,
or if we refine the atomic_add_negative test, 32GB of page table space
to wrap (I'm assuming an 8-byte PAE page table entries for each unit
of mapcount, since we're well beyond the 4GB non-PAE limit).
Do we actually need to worry about i386 above 32GB in the x86_64 era?
> I was a bit worried about this too, but Hugh didn't think it was a
> really big a deal - I guess because the real solution for the refcount
> overflow on 64-bit is to expand the refcount type.
Yes, and I'm imagining some scheme of sharing _count and _mapcount in
a single atomic64, since we don't want to expand struct page for this.
Implement that shortly, unless we find a way to eliminate _mapcount
instead.
But Alan's overflow issue is not new, it's not brought on refcounting
the ZERO_PAGE: sys_remap_file_pages already allows a file page to be
mapped multiple times in single process, without the constriction of
needing lots of vm_area_struct space. ZERO_PAGE is just more obvious.
Hugh
-
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]
