From owner-svn-src-head@FreeBSD.ORG Mon Dec 22 17:32:53 2008 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0632B1065677; Mon, 22 Dec 2008 17:32:53 +0000 (UTC) (envelope-from alc@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id E85928FC17; Mon, 22 Dec 2008 17:32:52 +0000 (UTC) (envelope-from alc@FreeBSD.org) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.3/8.14.3) with ESMTP id mBMHWqqP066915; Mon, 22 Dec 2008 17:32:52 GMT (envelope-from alc@svn.freebsd.org) Received: (from alc@localhost) by svn.freebsd.org (8.14.3/8.14.3/Submit) id mBMHWqRD066914; Mon, 22 Dec 2008 17:32:52 GMT (envelope-from alc@svn.freebsd.org) Message-Id: <200812221732.mBMHWqRD066914@svn.freebsd.org> From: Alan Cox Date: Mon, 22 Dec 2008 17:32:52 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: svn commit: r186397 - head/sys/security/mac X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 17:32:53 -0000 Author: alc Date: Mon Dec 22 17:32:52 2008 New Revision: 186397 URL: http://svn.freebsd.org/changeset/base/186397 Log: Make preparations for resurrecting shared/read locks on vm maps: mac_proc_vm_revoke_recurse() requests a read lock on the vm map at the start but does not handle failure by vm_map_lock_upgrade() when it seeks to modify the vm map. At present, this works because all lock request on a vm map are implemented as exclusive locks. Thus, vm_map_lock_upgrade() is a no-op that always reports success. However, that is about to change, and proc_vm_revoke_recurse() will require substantial modifications to handle vm_map_lock_upgrade() failures. For the time being, I am changing mac_proc_vm_revoke_recurse() to request a write lock on the vm map at the start. Approved by: rwatson MFC after: 3 months Modified: head/sys/security/mac/mac_process.c Modified: head/sys/security/mac/mac_process.c ============================================================================== --- head/sys/security/mac/mac_process.c Mon Dec 22 16:58:47 2008 (r186396) +++ head/sys/security/mac/mac_process.c Mon Dec 22 17:32:52 2008 (r186397) @@ -260,7 +260,7 @@ mac_proc_vm_revoke_recurse(struct thread if (!mac_mmap_revocation) return; - vm_map_lock_read(map); + vm_map_lock(map); for (vme = map->header.next; vme != &map->header; vme = vme->next) { if (vme->eflags & MAP_ENTRY_IS_SUB_MAP) { mac_proc_vm_revoke_recurse(td, cred, @@ -315,7 +315,6 @@ mac_proc_vm_revoke_recurse(struct thread prot2str(revokeperms), (u_long)vme->start, (long)(vme->end - vme->start), prot2str(vme->max_protection), prot2str(vme->protection)); - vm_map_lock_upgrade(map); /* * This is the really simple case: if a map has more * max_protection than is allowed, but it's not being @@ -369,10 +368,9 @@ mac_proc_vm_revoke_recurse(struct thread vme->protection & ~revokeperms); vm_map_simplify_entry(map, vme); } - vm_map_lock_downgrade(map); VFS_UNLOCK_GIANT(vfslocked); } - vm_map_unlock_read(map); + vm_map_unlock(map); } int