Re: Fix for sys_munlock(2) with racct

From: Edward Tomasz Napierała <trasz_at_FreeBSD.org>
Date: Sun, 11 Aug 2013 18:59:36 +0200
Wiadomość napisana przez Alan Cox <alc_at_rice.edu> w dniu 30 lip 2013, o godz. 19:40:
> On Jul 21, 2013, at 2:50 PM, Jeremie Le Hen wrote:
>> 
>>> Also, a wired mapping can be destroyed by calling munmap(2) without
>>> first calling munlock(2), in which case, RACCT_MEMLOCK will be
>>> incorrect.
>> 
>> So I think the right way to tackle this is to handle racct in the vm
>> layer rather than at the syscall layer.
>> 
> 
> The VM system already maintains counters equivalent to RACCT_VMEM and RACCT_MEMLOCK.  They are "map->size" and "pmap_wired_count(map->pmap)".  Instead of maintaining duplicate counters, could the resource accounting framework be extended to support callbacks to obtain a value when it's actually needed?

That would be rather hard.  The way this works is that raccts are hierarchical, and every
time resource allocation is done, its respective counter needs to be propagated all the
way up.  If it hits a limit somewhere, the racct function returns error meaning the resource
allocation was denied.  In other words, racct wants to know when the counter changes.
Received on Sun Aug 11 2013 - 14:59:41 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:40 UTC