Re: Fix for sys_munlock(2) with racct

Wiadomo=B6=E6 napisana przez Alan Cox <alc@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 RAC=
CT_MEMLOCK.  They are "map->size" and "pmap_wired_count(map->pmap)".  Inste=
ad of maintaining duplicate counters, could the resource accounting framewo=
rk be extended to support callbacks to obtain a value when it's actually ne=
eded?

That would be rather hard.  The way this works is that raccts are hierarchi=
cal, and every
time resource allocation is done, its respective counter needs to be propag=
ated all the
way up.  If it hits a limit somewhere, the racct function returns error mea=
ning the resource
allocation was denied.  In other words, racct wants to know when the counte=
r changes.

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"