Date: Sun, 11 Aug 2013 18:59:36 +0200 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= <trasz@FreeBSD.org> To: Alan Cox <alc@rice.edu> Cc: Jeremie Le Hen <jlh@FreeBSD.org>, Alan Cox <alc@FreeBSD.org>, freebsd-current@FreeBSD.org, Konstantin Belousov <kib@freebsd.org> Subject: Re: Fix for sys_munlock(2) with racct Message-ID: <F4779BEB-6F48-4A98-867C-DB40320F7865@FreeBSD.org> In-Reply-To: <EDF1EFE1-E9A9-44CF-8007-A642971572BE@rice.edu> References: <20130720112218.GD13628@caravan.chchile.org> <115EDC04-4B95-4FB5-9092-515188D8ADA7@rice.edu> <20130721215038.GE13628@caravan.chchile.org> <EDF1EFE1-E9A9-44CF-8007-A642971572BE@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Wiadomość 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 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F4779BEB-6F48-4A98-867C-DB40320F7865>