Terry Lambert wrote:
> The remmap is a better idea.  It
> might be wedged into the exiting mmap for a malloc of the
> same object with a larger size (e.g. remapping MAP_ANON
> memory with a larger size and a non-zero address implies a
> zero address, same pages, larger allocation, since mapping
> over an existing mapping makes no sense).

Actually, there are a lot of options for this.  The first
thing that mmap does is convert the len from a size_t into
an ssize_t -- from unsigned to signed -- and then checks the
sign bit, and disallows the request entirely.  If it fit the
profile, it could have the sign inverted, and the remmap
semantics, instead.

Similarly, there is a check for an fd != -1 in the MAP_ANON
case, that disallows it if it's not -1.  Any non -1 value
could be interpreted as special.

In addition, you could jam the remap semantics into the flags
(e.g. adding a "MAP_REMAP"), or into the prot flag, if the
flags bits were too "precious" (there're plenty available,

Validating that the existing mapping is present and anonymous
would be a case of looking it up.

Actually, vm_mmap uses NULL and 0 compares on a pointer
value interchangalby... style violation, that.

Probably, you would need to put the old size into the "fd"
field, if you wanted to be sure that it didn't accidently
do the wrong thing... it seems that differentiating one ANON
mapping region form one contuguous and following it is rather
difficult...  depending on the implementaiton of phkmalloc,
you might have to constrain the caller to even pages, if you
want it to be able to work without perhaps taking a combined
split region on a realloc of an alloc'ed area, and breaking
it.  You could get this information from the (noncontiguous)
metadata area, but it would not be general, and would still
need to be pushed into the kernel somehow.  Given that the
length is limited effectively to a signed int, even though the
man page lists it as a size_t (unsigned int), passing the old
size in the fd doesn't seem that abominable...

In the worst case of many consecutive reallocations, you
would probably want to check the region for the new mapping
to see if it was clear, and do a map add, rather than a remap
(technically), you would end uprotoring through three
adjacent mapping sets, otherwise (looking for the hole in the
map).  For a very big allocation, this means that for an N->N+1
allocation delta, N could never exceed 1/3 of the user process
address space after the process itself not including the realloc
in question, was subtracted out.. plus one page.  But that's
really a micro-optimization that won't be hit (until the first
time someone starts testing the speedup claims... 8-)).

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to