NetBSD/sys/uvm/uvm_fault.h

87 lines
3.1 KiB
C
Raw Normal View History

introduce a new UVM fault type, VM_FAULT_WIREMAX. this is different from VM_FAULT_WIRE in that when the pages being wired are faulted in, the simulated fault is at the maximum protection allowed for the mapping instead of the current protection. use this in uvm_map_pageable{,_all}() to fix the problem where writing via ptrace() to shared libraries that are also mapped with wired mappings in another process causes a diagnostic panic when the wired mapping is removed. this is a really obscure problem so it deserves some more explanation. ptrace() writing to another process ends up down in uvm_map_extract(), which for MAP_PRIVATE mappings (such as shared libraries) will cause the amap to be copied or created. then the amap is made shared (ie. the AMAP_SHARED flag is set) between the kernel and the ptrace()d process so that the kernel can modify pages in the amap and have the ptrace()d process see the changes. then when the page being modified is actually faulted on, the object pages (from the shared library vnode) is copied to a new anon page and inserted into the shared amap. to make all the processes sharing the amap actually see the new anon page instead of the vnode page that was there before, we need to invalidate all the pmap-level mappings of the vnode page in the pmaps of the processes sharing the amap, but we don't have a good way of doing this. the amap doesn't keep track of the vm_maps which map it. so all we can do at this point is to remove all the mappings of the page with pmap_page_protect(), but this has the unfortunate side-effect of removing wired mappings as well. removing wired mappings with pmap_page_protect() is a legitimate operation, it can happen when a file with a wired mapping is truncated. so the pmap has no way of knowing whether a request to remove a wired mapping is normal or when it's due to this weird situation. so the pmap has to remove the weird mapping. the process being ptrace()d goes away and life continues. then, much later when we go to unwire or remove the wired vm_map mapping, we discover that the pmap mapping has been removed when it should still be there, and we panic. so where did we go wrong? the problem is that we don't have any way to update just the pmap mappings that need to be updated in this scenario. we could invent a mechanism to do this, but that is much more complicated than this change and it doesn't seem like the right way to go in the long run either. the real underlying problem here is that wired pmap mappings just aren't a good concept. one of the original properties of the pmap design was supposed to be that all the information in the pmap could be thrown away at any time and the VM system could regenerate it all through fault processing, but wired pmap mappings don't allow that. a better design for UVM would not require wired pmap mappings, and Chuck C. and I are talking about this, but it won't be done anytime soon, so this change will do for now. this change has the effect of causing MAP_PRIVATE mappings to be copied to anonymous memory when they are mlock()d, so that uvm_fault() doesn't need to copy these pages later when called from ptrace(), thus avoiding the call to pmap_page_protect() and the panic that results from this when the mlock()d region is unlocked or freed. note that this change doesn't help the case where the wired mapping is MAP_SHARED. discussed at great length with Chuck Cranor. fixes PRs 10363, 12554, 12604, 13041, 13487, 14580 and 14853.
2002-01-01 01:34:39 +03:00
/* $NetBSD: uvm_fault.h,v 1.16 2001/12/31 22:34:39 chs Exp $ */
/*
*
* Copyright (c) 1997 Charles D. Cranor and Washington University.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by Charles D. Cranor and
* Washington University.
* 4. The name of the author may not be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
1998-02-07 14:07:38 +03:00
*
* from: Id: uvm_fault.h,v 1.1.2.2 1997/12/08 16:07:12 chuck Exp
*/
#ifndef _UVM_UVM_FAULT_H_
#define _UVM_UVM_FAULT_H_
/*
* fault types
*/
#define VM_FAULT_INVALID ((vm_fault_t) 0x0) /* invalid mapping */
#define VM_FAULT_PROTECT ((vm_fault_t) 0x1) /* protection */
#define VM_FAULT_WIRE ((vm_fault_t) 0x2) /* wire mapping */
introduce a new UVM fault type, VM_FAULT_WIREMAX. this is different from VM_FAULT_WIRE in that when the pages being wired are faulted in, the simulated fault is at the maximum protection allowed for the mapping instead of the current protection. use this in uvm_map_pageable{,_all}() to fix the problem where writing via ptrace() to shared libraries that are also mapped with wired mappings in another process causes a diagnostic panic when the wired mapping is removed. this is a really obscure problem so it deserves some more explanation. ptrace() writing to another process ends up down in uvm_map_extract(), which for MAP_PRIVATE mappings (such as shared libraries) will cause the amap to be copied or created. then the amap is made shared (ie. the AMAP_SHARED flag is set) between the kernel and the ptrace()d process so that the kernel can modify pages in the amap and have the ptrace()d process see the changes. then when the page being modified is actually faulted on, the object pages (from the shared library vnode) is copied to a new anon page and inserted into the shared amap. to make all the processes sharing the amap actually see the new anon page instead of the vnode page that was there before, we need to invalidate all the pmap-level mappings of the vnode page in the pmaps of the processes sharing the amap, but we don't have a good way of doing this. the amap doesn't keep track of the vm_maps which map it. so all we can do at this point is to remove all the mappings of the page with pmap_page_protect(), but this has the unfortunate side-effect of removing wired mappings as well. removing wired mappings with pmap_page_protect() is a legitimate operation, it can happen when a file with a wired mapping is truncated. so the pmap has no way of knowing whether a request to remove a wired mapping is normal or when it's due to this weird situation. so the pmap has to remove the weird mapping. the process being ptrace()d goes away and life continues. then, much later when we go to unwire or remove the wired vm_map mapping, we discover that the pmap mapping has been removed when it should still be there, and we panic. so where did we go wrong? the problem is that we don't have any way to update just the pmap mappings that need to be updated in this scenario. we could invent a mechanism to do this, but that is much more complicated than this change and it doesn't seem like the right way to go in the long run either. the real underlying problem here is that wired pmap mappings just aren't a good concept. one of the original properties of the pmap design was supposed to be that all the information in the pmap could be thrown away at any time and the VM system could regenerate it all through fault processing, but wired pmap mappings don't allow that. a better design for UVM would not require wired pmap mappings, and Chuck C. and I are talking about this, but it won't be done anytime soon, so this change will do for now. this change has the effect of causing MAP_PRIVATE mappings to be copied to anonymous memory when they are mlock()d, so that uvm_fault() doesn't need to copy these pages later when called from ptrace(), thus avoiding the call to pmap_page_protect() and the panic that results from this when the mlock()d region is unlocked or freed. note that this change doesn't help the case where the wired mapping is MAP_SHARED. discussed at great length with Chuck Cranor. fixes PRs 10363, 12554, 12604, 13041, 13487, 14580 and 14853.
2002-01-01 01:34:39 +03:00
#define VM_FAULT_WIREMAX ((vm_fault_t) 0x3) /* wire, allow maxprot */
/*
* fault data structures
*/
/*
* uvm_faultinfo: to load one of these fill in all orig_* fields and
* then call uvmfault_lookup on it.
*/
struct uvm_faultinfo {
struct vm_map *orig_map; /* IN: original map */
vaddr_t orig_rvaddr; /* IN: original rounded VA */
vsize_t orig_size; /* IN: original size of interest */
struct vm_map *map; /* map (could be a submap) */
unsigned int mapv; /* map's version number */
struct vm_map_entry *entry; /* map entry (from 'map') */
vsize_t size; /* size of interest */
};
#ifdef _KERNEL
/*
* fault prototypes
*/
int uvmfault_anonget __P((struct uvm_faultinfo *, struct vm_amap *,
struct vm_anon *));
introduce a new UVM fault type, VM_FAULT_WIREMAX. this is different from VM_FAULT_WIRE in that when the pages being wired are faulted in, the simulated fault is at the maximum protection allowed for the mapping instead of the current protection. use this in uvm_map_pageable{,_all}() to fix the problem where writing via ptrace() to shared libraries that are also mapped with wired mappings in another process causes a diagnostic panic when the wired mapping is removed. this is a really obscure problem so it deserves some more explanation. ptrace() writing to another process ends up down in uvm_map_extract(), which for MAP_PRIVATE mappings (such as shared libraries) will cause the amap to be copied or created. then the amap is made shared (ie. the AMAP_SHARED flag is set) between the kernel and the ptrace()d process so that the kernel can modify pages in the amap and have the ptrace()d process see the changes. then when the page being modified is actually faulted on, the object pages (from the shared library vnode) is copied to a new anon page and inserted into the shared amap. to make all the processes sharing the amap actually see the new anon page instead of the vnode page that was there before, we need to invalidate all the pmap-level mappings of the vnode page in the pmaps of the processes sharing the amap, but we don't have a good way of doing this. the amap doesn't keep track of the vm_maps which map it. so all we can do at this point is to remove all the mappings of the page with pmap_page_protect(), but this has the unfortunate side-effect of removing wired mappings as well. removing wired mappings with pmap_page_protect() is a legitimate operation, it can happen when a file with a wired mapping is truncated. so the pmap has no way of knowing whether a request to remove a wired mapping is normal or when it's due to this weird situation. so the pmap has to remove the weird mapping. the process being ptrace()d goes away and life continues. then, much later when we go to unwire or remove the wired vm_map mapping, we discover that the pmap mapping has been removed when it should still be there, and we panic. so where did we go wrong? the problem is that we don't have any way to update just the pmap mappings that need to be updated in this scenario. we could invent a mechanism to do this, but that is much more complicated than this change and it doesn't seem like the right way to go in the long run either. the real underlying problem here is that wired pmap mappings just aren't a good concept. one of the original properties of the pmap design was supposed to be that all the information in the pmap could be thrown away at any time and the VM system could regenerate it all through fault processing, but wired pmap mappings don't allow that. a better design for UVM would not require wired pmap mappings, and Chuck C. and I are talking about this, but it won't be done anytime soon, so this change will do for now. this change has the effect of causing MAP_PRIVATE mappings to be copied to anonymous memory when they are mlock()d, so that uvm_fault() doesn't need to copy these pages later when called from ptrace(), thus avoiding the call to pmap_page_protect() and the panic that results from this when the mlock()d region is unlocked or freed. note that this change doesn't help the case where the wired mapping is MAP_SHARED. discussed at great length with Chuck Cranor. fixes PRs 10363, 12554, 12604, 13041, 13487, 14580 and 14853.
2002-01-01 01:34:39 +03:00
int uvm_fault_wire __P((struct vm_map *, vaddr_t, vaddr_t, vm_fault_t,
vm_prot_t));
void uvm_fault_unwire __P((struct vm_map *, vaddr_t, vaddr_t));
void uvm_fault_unwire_locked __P((struct vm_map *, vaddr_t, vaddr_t));
#endif /* _KERNEL */
#endif /* _UVM_UVM_FAULT_H_ */