> Date: Fri, 24 Dec 2010 17:17:51 -0500
> From: Ted Unangst <[email protected]>
>
> On Fri, Dec 24, 2010 at 5:14 PM, Ted Unangst <[email protected]> wrote:
> > Anyone who stores the limit in a signed int (or long). Do I know of
> > any such software? No. Am I willing to risk the possibility of such
> > existing to squeeze out a few more bytes? No.
You mean, in the kernel? There the limits are stored in rlim_t, which
is a 64-bit type on all our architectures. There is one comparison in
uvm_mmap.c that had me worried for a bit:
if (size >
(p->p_rlimit[RLIMIT_DATA].rlim_cur - ptoa(p->p_vmspace->vm_dused))) {
but this is safe since ptoa() casts to paddr_t, which is unsigned long.
There is also 'struct orlimit' in <sys/resource.h>, which is used for
BSD4.3 compat code in compat/common/kern_resource_43.c. But
RLIMIT_DATA isn't the only resource limit that can be set to 2GB or
beyond. So I'm happy to ignore that issue.
For userland, I have very little sympathy. If stuff doesn't run with
the limits cranked up all the way to 2GB, fix it, or crank the limit
down a tad bit.
> > I will happily set it to straight 2GB, or even higher if we don't care
> > about possible trouble, so long as everybody promises not to complain
> > if an issue is found. :)
>
> To phrase it another way, I was actually hoping that by avoiding the
> "what about overflow?" worries, we could move forward faster. If
> that's not a worry, great, I just didn't want to get tied down.
I don't think this is a worry. Wouldn't mind if somebody else takes a
look at this as well.
