Date: Mon, 28 Jun 2010 18:12:43 +0000 (UTC) From: Konstantin Belousov <kib@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r209580 - head/sys/kern Message-ID: <201006281812.o5SIChMc079185@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: kib Date: Mon Jun 28 18:12:42 2010 New Revision: 209580 URL: http://svn.freebsd.org/changeset/base/209580 Log: Despite system call deregistration drains the threads executing System V shm syscalls, and initial check for the number of allocated segments in the module deinitialization code, the following might happen: after the check for active segment, while waiting for threads to leave some other syscall, shmget(2) is called. Then, we can end up with the shared segment that cannot be detached since sysvshm module is unloaded. Prevent the leak by rechecking and disclaiming a reference to the vm object owned by sysvshm module, that might have grown during the drain. Tested by: pho Reviewed by: jhb MFC after: 1 month Modified: head/sys/kern/sysv_shm.c Modified: head/sys/kern/sysv_shm.c ============================================================================== --- head/sys/kern/sysv_shm.c Mon Jun 28 18:06:46 2010 (r209579) +++ head/sys/kern/sysv_shm.c Mon Jun 28 18:12:42 2010 (r209580) @@ -919,10 +919,18 @@ shmunload() #endif syscall_helper_unregister(shm_syscalls); + for (i = 0; i < shmalloced; i++) { #ifdef MAC - for (i = 0; i < shmalloced; i++) mac_sysvshm_destroy(&shmsegs[i]); #endif + /* + * Objects might be still mapped into the processes + * address spaces. Actual free would happen on the + * last mapping destruction. + */ + if (shmsegs[i].u.shm_perm.mode != SHMSEG_FREE) + vm_object_deallocate(shmsegs[i].object); + } free(shmsegs, M_SHM); shmexit_hook = NULL; shmfork_hook = NULL;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201006281812.o5SIChMc079185>