d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix a panic in the racct code when munlock(2) is called with incorrect values.

Browse Source 
The racct code in sys_munlock() assumed that the boundaries provided by the
userland were correct as long as vm_map_unwire() returned successfully.
However the latter contains its own logic and sometimes manages to do something
out of those boundaries, even if they are buggy.  This change makes the racct
code to use the accounting done by the vm layer, as it is done in other places
such as vm_mlock().

Despite fixing the panic, Alan Cox pointed that this code is still race-y
though: two simultaneous callers will produce incorrect values.

Reviewed by:	alc
MFC after:	7 days
This commit is contained in:
Jeremie Le Hen 2013-07-22 21:47:14 +00:00
parent 84afe24fd0
commit c92b506977
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/head/; revision=253554
1 changed files with 4 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
sys/vm/vm_mmap.c
View File

@ -1224,6 +1224,7 @@ sys_munlock(td, uap)
{
vm_offset_t addr, end, last, start;
vm_size_t size;
vm_map_t map;
int error;
error = priv_check(td, PRIV_VM_MUNLOCK);
@ -1241,7 +1242,9 @@ sys_munlock(td, uap)
#ifdef RACCT
if (error == KERN_SUCCESS) {
PROC_LOCK(td->td_proc);
racct_sub(td->td_proc, RACCT_MEMLOCK, ptoa(end - start));
map = &td->td_proc->p_vmspace->vm_map;
racct_set(td->td_proc, RACCT_MEMLOCK,
ptoa(pmap_wired_count(map->pmap)));
PROC_UNLOCK(td->td_proc);
}
#endif