From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S938506AbdD0QIg convert rfc822-to-8bit (ORCPT <rfc822;w@1wt.eu>);
        Thu, 27 Apr 2017 12:08:36 -0400
Received: from mail.kernel.org ([198.145.29.136]:54684 "EHLO mail.kernel.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S934276AbdD0QIa (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 27 Apr 2017 12:08:30 -0400
MIME-Version: 1.0
In-Reply-To: <EB68D870-9F1A-4884-9C43-327E26656930@vmware.com>
References: <cover.1492844372.git.luto@kernel.org> <791a644076fc3577ba7f7b7cafd643cc089baa7d.1492844372.git.luto@kernel.org>
 <F05A63B8-4070-4528-B8A1-DAA66EBF94D9@vmware.com> <EB68D870-9F1A-4884-9C43-327E26656930@vmware.com>
From: Andy Lutomirski <luto@kernel.org>
Date: Thu, 27 Apr 2017 09:08:03 -0700
X-Gmail-Original-Message-ID: <CALCETrUnuDkizRffWTCcNFCyxCd_LEtP58g_ysm+vuZJkvWLWQ@mail.gmail.com>
Message-ID: <CALCETrUnuDkizRffWTCcNFCyxCd_LEtP58g_ysm+vuZJkvWLWQ@mail.gmail.com>
Subject: Re: [PATCH v3 1/4] x86/vm86/32: Switch to flush_tlb_mm_range() in mark_screen_rdonly()
To: Nadav Amit <namit@vmware.com>, Stas Sergeev <stsp@list.ru>
Cc: Andy Lutomirski <luto@kernel.org>, "x86@kernel.org" <x86@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Borislav Petkov <bp@alien8.de>, Rik van Riel <riel@redhat.com>,
        Dave Hansen <dave.hansen@intel.com>, Michal Hocko <mhocko@suse.com>,
        Sasha Levin <sasha.levin@oracle.com>,
        Andrew Morton <akpm@linux-foundation.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Apr 26, 2017 at 5:02 PM, Nadav Amit <namit@vmware.com> wrote:
> 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" <namit@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" <luto@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 <riel@redhat.com>
>         Cc: Dave Hansen <dave.hansen@intel.com>
>         Cc: Nadav Amit <namit@vmware.com>
>         Cc: Michal Hocko <mhocko@suse.com>
>         Cc: Sasha Levin <sasha.levin@oracle.com>
>         Cc: Andrew Morton <akpm@linux-foundation.org>
>         Signed-off-by: Andy Lutomirski <luto@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);
>          }
>

Those should probably be pgd_none(), not pgd_none_or_clear_bad().

But this whole function is just garbage.  It mucks with page
protections without even looking up the VMA.  What happens if the
pages are file-backed?  How about chardevs?

I'd like to delete it.  Stas, do you know if there's any code at all
that uses VM86_SCREEN_BITMAP?  Some Googling didn't turn any up at
all.