Re: [PATCH] ppc32 implementation of ptep_set_access_flags

From: Linus Torvalds
Date: Wed May 26 2004 - 10:23:41 EST



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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/