Displaying 6 results from an estimated 6 matches for "kpte_clear_flush".
2007 Apr 18
2
pte_offset_map + lazy mmu
Is pte_offset_map allowed to happen within lazy mmu? I presume not,
because you definitely don't want the mapping pte update to be deferred.
Or, more specifically, is kunmap_atomic ever allowed within lazy mmu?
I'm looking at kpte_clear_flush; I've already got a patch which turns
this into a pv_op, along with a Xen implementation. But I think its
probably an excess pv_op for a relatively minor corner case. It seems
to me that it would be better to define kpte_clear_flush as:
#define kpte_clear_flush(ptep, vaddr) \
do...
2007 Apr 18
2
pte_offset_map + lazy mmu
Is pte_offset_map allowed to happen within lazy mmu? I presume not,
because you definitely don't want the mapping pte update to be deferred.
Or, more specifically, is kunmap_atomic ever allowed within lazy mmu?
I'm looking at kpte_clear_flush; I've already got a patch which turns
this into a pv_op, along with a Xen implementation. But I think its
probably an excess pv_op for a relatively minor corner case. It seems
to me that it would be better to define kpte_clear_flush as:
#define kpte_clear_flush(ptep, vaddr) \
do...
2007 Apr 18
0
[PATCH 5/9] 00mm6 kpte flush.patch
...ll try to access this pte
+ * without first remap it. Keeping stale mappings around is a bad idea
+ * also, in case the page changes cacheability attributes or becomes
+ * a protected page in a hypervisor.
*/
- pte_clear(&init_mm, vaddr, kmap_pte-idx);
- __flush_tlb_one(vaddr);
-#endif
+ kpte_clear_flush(kmap_pte-idx, vaddr);
dec_preempt_count();
preempt_check_resched();
@@ -94,7 +91,6 @@ void *kmap_atomic_pfn(unsigned long pfn,
idx = type + KM_TYPE_NR*smp_processor_id();
vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
set_pte(kmap_pte-idx, pfn_pte(pfn, kmap_prot));
- __flush_tlb_one(vaddr...
2020 Nov 03
45
[patch V3 00/37] mm/highmem: Preemptible variant of kmap_atomic & friends
Following up to the discussion in:
https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de
and the second version of this:
https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de
this series provides a preemptible variant of kmap_atomic & related
interfaces.
This is achieved by:
- Removing the RT dependency from migrate_disable/enable()
- Consolidating all
2020 Nov 03
45
[patch V3 00/37] mm/highmem: Preemptible variant of kmap_atomic & friends
Following up to the discussion in:
https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de
and the second version of this:
https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de
this series provides a preemptible variant of kmap_atomic & related
interfaces.
This is achieved by:
- Removing the RT dependency from migrate_disable/enable()
- Consolidating all
2020 Nov 03
45
[patch V3 00/37] mm/highmem: Preemptible variant of kmap_atomic & friends
Following up to the discussion in:
https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de
and the second version of this:
https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de
this series provides a preemptible variant of kmap_atomic & related
interfaces.
This is achieved by:
- Removing the RT dependency from migrate_disable/enable()
- Consolidating all