From c92b506977c7764282b3e2db98fbf82b3b61bc54 Mon Sep 17 00:00:00 2001 From: Jeremie Le Hen Date: Mon, 22 Jul 2013 21:47:14 +0000 Subject: Fix a panic in the racct code when munlock(2) is called with incorrect values. 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 --- sys/vm/vm_mmap.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'sys/vm/vm_mmap.c') diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c index a5e67920cc53..b6145777b9b7 100644 --- a/sys/vm/vm_mmap.c +++ b/sys/vm/vm_mmap.c @@ -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 -- cgit v1.2.3