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 S1756087AbcBPVbj (ORCPT <rfc822;w@1wt.eu>);
	Tue, 16 Feb 2016 16:31:39 -0500
Received: from mga04.intel.com ([192.55.52.120]:35059 "EHLO mga04.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755140AbcBPVbi (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 16 Feb 2016 16:31:38 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.22,456,1449561600"; 
   d="scan'208";a="48969138"
Subject: Re: [PATCH v2] arm64: add alignment fault hanling
To: Linus Torvalds <torvalds@linux-foundation.org>,
        Will Deacon <will.deacon@arm.com>
References: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>
 <20160216103104.GC14509@arm.com> <56C300AD.8070505@arm.com>
 <20160216122153.GD19413@e104818-lin.cambridge.arm.com>
 <20160216160055.GH14509@arm.com> <20160216170408.GL14509@arm.com>
 <CA+55aFw-86k4gY46Et=e02HQQSxjUK2Jfz0SJz8tWtk5P8YZFA@mail.gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
        Robin Murphy <robin.murphy@arm.com>,
        EunTaik Lee <eun.taik.lee@samsung.com>,
        "vladimir.murzin@arm.com" <vladimir.murzin@arm.com>,
        "suzuki.poulose@arm.com" <suzuki.poulose@arm.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "salyzyn@android.com" <salyzyn@android.com>,
        "riandrews@android.com" <riandrews@android.com>,
        "james.morse@arm.com" <james.morse@arm.com>,
        "Dave.Martin@arm.com" <Dave.Martin@arm.com>,
        "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
        Peter Anvin <hpa@zytor.com>, Peter Zijlstra <peterz@infradead.org>
From: Arjan van de Ven <arjan@linux.intel.com>
Message-ID: <56C39538.6090009@linux.intel.com>
Date: Tue, 16 Feb 2016 13:31:36 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CA+55aFw-86k4gY46Et=e02HQQSxjUK2Jfz0SJz8tWtk5P8YZFA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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 2/16/2016 10:50 AM, Linus Torvalds wrote:
> On Tue, Feb 16, 2016 at 9:04 AM, Will Deacon <will.deacon@arm.com> wrote:
>> [replying to self and adding some x86 people]
>>
>> Background: Euntaik reports a problem where userspace has ended up with
>> a memory page mapped adjacent to an MMIO page (e.g. from /dev/mem or a
>> PCI memory bar from someplace in /sys). strncpy_from_user happens with
>> the word-at-a-time implementation, and we end up reading into the MMIO
>> page.

how does this work if the adjacent page is not accessible?
or has some other magic fault handler, or is on an NFS filesystem where
the server is rebooting?

isn't the general rule for such basic functions "don't touch memory unless you KNOW it is there"



> Of course, no actual real program will do that for mixing MMIO and
> non-MMIO, and so we might obviously add code to always add a guard
> page for the normal case when a specific address isn't asked for. So
> as a heuristic to make sure it doesn't happen by mistake it possibly
> makes sense.

but what happens to the read if the page isn't present?
or is execute-only or .. or ..