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 S1754949AbdKASqd (ORCPT <rfc822;w@1wt.eu>);
        Wed, 1 Nov 2017 14:46:33 -0400
Received: from mga01.intel.com ([192.55.52.88]:57797 "EHLO mga01.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751428AbdKASqc (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 1 Nov 2017 14:46:32 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.44,330,1505804400"; 
   d="scan'208";a="144767527"
Subject: Re: [PATCH 00/23] KAISER: unmap most of the kernel from userspace
 page tables
To: Linus Torvalds <torvalds@linux-foundation.org>
References: <20171031223146.6B47C861@viggo.jf.intel.com>
 <CA+55aFzS8GZ7QHzMU-JsievHU5T9LBrFx2fRwkbCB8a_YAxmsw@mail.gmail.com>
 <9e45a167-3528-8f93-80bf-c333ae6acb71@linux.intel.com>
 <CA+55aFypdyt+3-JyD3U1da5EqznncxKZZKPGn4ykkD=4Q4rdvw@mail.gmail.com>
 <8bacac66-7d3e-b15d-a73b-92c55c0b1908@linux.intel.com>
 <CA+55aFxssHiO4f52UUCPXoxx+NOu5Epf6HhwsjUH8Ua+BP6Y=A@mail.gmail.com>
Cc: Andy Lutomirski <luto@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-mm <linux-mm@kvack.org>, Kees Cook <keescook@google.com>,
        Hugh Dickins <hughd@google.com>
From: Dave Hansen <dave.hansen@linux.intel.com>
Message-ID: <5005a38e-4dbf-d302-9a82-97c92d0f8f07@linux.intel.com>
Date: Wed, 1 Nov 2017 11:46:31 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CA+55aFxssHiO4f52UUCPXoxx+NOu5Epf6HhwsjUH8Ua+BP6Y=A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 11/01/2017 11:27 AM, Linus Torvalds wrote:
> So I'd like to see not just the comments about this, but I'd like to
> see the code itself actually making that very clear. Have *code* that
> verifies that nobody ever tries to use this on a user address (because
> that would *completely* screw up all coherency), but also I don't see
> why the code possibly looks up the old physical address in ther page
> table. Is there _any_ possible reason why you'd want to look up a page
> from an old page table? As far as I can tell, we should always know
> the physical page we are mapping a priori - we've never re-mapping
> random virtual addresses or a highmem page or anything like that.
> We're mapping the 1:1 kernel mapping only.

The vmalloc()'d stacks definitely need the page table walk.  That's yet
another thing that will get simpler once we stop needing to map the
process stacks.  I think there was also a need to do this for the fixmap
addresses for the GDT.

But, I'm totally with you on making this stuff less generic.