From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751503AbdGQOSr (ORCPT ); Mon, 17 Jul 2017 10:18:47 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:33000 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751303AbdGQOSp (ORCPT ); Mon, 17 Jul 2017 10:18:45 -0400 Date: Mon, 17 Jul 2017 16:18:40 +0200 From: "gregkh@linuxfoundation.org" To: Ard Biesheuvel Cc: "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Arnd Bergmann , Will Deacon , Mark Rutland Subject: Re: [PATCH v3] drivers/char: kmem: disable on arm64 Message-ID: <20170717141840.GA16198@kroah.com> References: <1497941940-2699-1-git-send-email-ard.biesheuvel@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 20, 2017 at 01:20:49PM +0200, Ard Biesheuvel wrote: > On 20 June 2017 at 08:59, Ard Biesheuvel wrote: > > As it turns out, arm64 deviates from other architectures in the way it > > maps the VMALLOC region: on most (all?) other architectures, it resides > > strictly above the kernel's direct mapping of DRAM, but on arm64, this > > is the other way around. For instance, for a 48-bit VA configuration, > > we have > > > > modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB) > > vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB) > > ... > > vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum) > > 0xffff7e0000000000 - 0xffff7e0003ff0000 ( 63 MB actual) > > memory : 0xffff800000000000 - 0xffff8000ffc00000 ( 4092 MB) > > > > This has mostly gone unnoticed until now, but it does appear that it > > breaks an assumption in the kcore > > s/kcore/kmem/ v4? :)