Messages in this thread |  | | | Date | Wed, 26 May 2004 08:22:35 -0700 (PDT) | | From | Linus Torvalds <> | | Subject | Re: [PATCH] ppc32 implementation of ptep_set_access_flags |
| |
On Wed, 26 May 2004, Benjamin Herrenschmidt wrote: > > Here's the ppc32 implementation of ptep_set_access_flags:
Ok. I modified the way things are done a bit, to make it easier to keep architectures that haven't been updated yet in working order.
What I did was to basically split up the old "ptep_establish()" into a new "ptep_establish()" that is only used for COW, and your "ptep_update_accessed_bits()", which is used for the other cases.
I also left the default implementations in <asm-generic/pgtable.h> as exactly the same as the default implementation used to be for the old "ptep_establish()", so architectures that have not been updated to take advantage of the split should work the way they always did. Except s390, which now gets the default function for the accessed bits update (which should be at least pretty close to correct for s390 too, I think the problem for s390 was the COW-case).
The "new" rules (well, they aren't new, but now they are explicitly spelled out) for this thing are:
- ptep_establish(__vma, __address, __ptep, __entry)
Establish a new mapping: - flush the old one - update the page tables - inform the TLB about the new one
We hold the mm semaphore for reading and vma->vm_mm->page_table_lock.
Note: the old pte is known to not be writable, so we don't need to worry about dirty bits etc getting lost.
- ptep_set_access_flags(__vma, __address, __ptep, __entry, __dirty)
Largely same as above, but only sets the access flags (dirty, accessed, and writable). Furthermore, we know it always gets set to a "more permissive" setting, which allows most architectures to optimize this.
and right now they both just default to
set_pte(__ptep, __entry); flush_tlb_page(__vma, __address);
unless overridden by the architecture.
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |