remap_pfn_range() is defined in mm/memory.c and as far as I
can tell, does _not_ cause total_vm or reserved_vm to be updated.
Is this right?
RLIMIT_AS is only checked against total_vm in mm/mmap.c in the function
may_expand_vm().
I think this means that a device driver can map pages into
a process and thus effectively increase address space of
a process above and beyond the limit set by RLIMIT_AS.
Am I reading the code correctly?
Earl
On 10/16/09 06:17, Earl Chew wrote:
> remap_pfn_range() is defined in mm/memory.c and as far as I
> can tell, does _not_ cause total_vm or reserved_vm to be updated.
>
> Is this right?
>
>
> RLIMIT_AS is only checked against total_vm in mm/mmap.c in the function
> may_expand_vm().
>
> I think this means that a device driver can map pages into
> a process and thus effectively increase address space of
> a process above and beyond the limit set by RLIMIT_AS.
I suspect this is justified because remap_pfn_range is generally
(always?) used to map device memory, and other memory which isn't
represented by struct pages, so it doesn't really count as real memory
usage.
J
Jeremy Fitzhardinge wrote:
>> I think this means that a device driver can map pages into
>> a process and thus effectively increase address space of
>> a process above and beyond the limit set by RLIMIT_AS.
>
> I suspect this is justified because remap_pfn_range is generally
> (always?) used to map device memory, and other memory which isn't
> represented by struct pages, so it doesn't really count as real memory
> usage.
Well, perhaps not always.
http://lkml.org/lkml/2008/12/3/453
http://www.scs.ch/~frey/linux/memorymap.html
While DMA related activity is the most obvious reason a driver
might want to allocate memory and inject it into userspace,
I could imagine other reasons (though not necessarily good ones)
where it is more efficient to simply copy data to/from a buffer
shared with a driver.
In both the scenarios outlined, this would be real memory
and not simply IO space.
As to whether it's even justified for IO space, I'm uncertain.
The reference material at http://www.opengroup.org is not crystal clear:
http://www.opengroup.org/onlinepubs/009695399/functions/getrlimit.html
> RLIMIT_AS
> This is the maximum size of a process' total available memory, in
> bytes. If this limit is exceeded, the malloc() and mmap() functions
> shall fail with errno set to [ENOMEM]. In addition, the automatic stack
> growth fails with the effects outlined above.
I think controlling the size of the address space of the process
is the intent (likely evidenced by the name RLIMIT_AS), but the
text only speaks of user space APIs malloc() and mmap(). The
text does hint that this should apply to other indirect
means of address space expansion by describing stack growth.
One could also regard memory injected by device drivers as mmap()
by other means.
Earl