And besides, it looks as if the code was meant to flush the entire
TLB in some cases (e.g., if pgd_none_or_clear_bad() is true).
On 4/26/17, 4:56 PM, "Nadav Amit" <na...@vmware.com> wrote:
It may be benign, but I don’t think that flushing the TLB without
holding the ptl or the mmap_sem (for no apparent reason) is a good
practice.
On 4/22/17, 12:01 AM, "Andy Lutomirski" <l...@kernel.org> wrote:
mark_screen_rdonly() is the last remaining caller of flush_tlb().
flush_tlb_mm_range() is potentially faster and isn't obsolete.
Compile-tested only because I don't know whether software that uses
this mechanism even exists.
Cc: Rik van Riel <r...@redhat.com>
Cc: Dave Hansen <dave.han...@intel.com>
Cc: Nadav Amit <na...@vmware.com>
Cc: Michal Hocko <mho...@suse.com>
Cc: Sasha Levin <sasha.le...@oracle.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Signed-off-by: Andy Lutomirski <l...@kernel.org>
---
arch/x86/kernel/vm86_32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index 23ee89ce59a9..3eda76b3c835 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -193,7 +193,7 @@ static void mark_screen_rdonly(struct mm_struct *mm)
pte_unmap_unlock(pte, ptl);
out:
up_write(&mm->mmap_sem);
- flush_tlb();
+ flush_tlb_mm_range(mm, 0xA0000, 0xA0000 + 32*PAGE_SIZE, 0UL);
}
--
2.9.3
