Fix for sys_munlock(2) with racct

[Edward Tomasz Napierała]

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.