On Wed, 21 Jul 1999, Matthew Dillon wrote: > > The VM_PROT_OVERRIDE_WRITE flag is only used for user-wired pages, so > it does not effect 'normal' page handling. Look carefully at the
> vm_fault() code (vm/vm_fault.c line 212), that lookup only occurs > with VM_PROT_OVERRIDE_WRITE set if the normal lookup fails and the > user has wired the page. > > So if a normal lookup fails and this is a user-wired page, we try > the lookup again with VM_PROT_OVERRIDE_WRITE, presumably to handle > a faked copy-on-write fault for the debugger. This results in the > following: > > First, we temporarily increase the protections to make the page *appear* > writeable. Note: only 'appear' writeable, not actually be writeable. > > if (fault_type & VM_PROT_OVERRIDE_WRITE) > prot = entry->max_protection; > else > prot = entry->protection; To allow a debugger to write TEXT area of a program, the max_protection field must be set to include VM_PROT_WRITE by the loader. Am I right? > *wired = (entry->wired_count != 0); > if (*wired) > prot = fault_type = entry->protection; > > I'm pretty sure this piece is simply reverting the mess that the > copy-on-write stuff does for the debugger. entry->protection is what > we normally want to use. Since mlock(2) is used by user, these make sense to me. Both vm_fault_wire() and vm_fault_user_wire() have non-zero wired_count of the related map entry before calling vm_fault(). This is done by their caller vm_map_pageable() and vm_map_user_pageable(). Since you are talking about user wiring case, so for the kernel wiring case, the above code should prevent any further fault on the page after this simulated one. Therefore, a kernel-wired page will never cause protection-violation faults, while a user-wired page can, as said on the man pages of mlock(2). Since mlock(2) is used by user, these make sense to me. Thanks for your response. -Zhihui To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
