From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 74008C54FC9 for ; Tue, 21 Apr 2020 16:45:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CBB63206A1 for ; Tue, 21 Apr 2020 16:45:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CBB63206A1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3813F8E0005; Tue, 21 Apr 2020 12:45:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 332208E0003; Tue, 21 Apr 2020 12:45:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FA108E0005; Tue, 21 Apr 2020 12:45:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id 0352C8E0003 for ; Tue, 21 Apr 2020 12:45:48 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A3783180AD82F for ; Tue, 21 Apr 2020 16:45:48 +0000 (UTC) X-FDA: 76732438776.26.heart13_4fc60d4d4a935 X-HE-Tag: heart13_4fc60d4d4a935 X-Filterd-Recvd-Size: 2909 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Tue, 21 Apr 2020 16:45:48 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 141481FB; Tue, 21 Apr 2020 09:45:47 -0700 (PDT) Received: from gaia (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7EE323F73D; Tue, 21 Apr 2020 09:45:45 -0700 (PDT) Date: Tue, 21 Apr 2020 17:45:43 +0100 From: Catalin Marinas To: Al Viro Cc: linux-arm-kernel@lists.infradead.org, Will Deacon , Vincenzo Frascino , Szabolcs Nagy , Richard Earnshaw , Kevin Brodsky , Andrey Konovalov , Peter Collingbourne , linux-mm@kvack.org, linux-arch@vger.kernel.org Subject: Re: [PATCH v3 20/23] fs: Allow copy_mount_options() to access user-space in a single pass Message-ID: <20200421164543.GC12076@gaia> References: <20200421142603.3894-1-catalin.marinas@arm.com> <20200421142603.3894-21-catalin.marinas@arm.com> <20200421152948.GC23230@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200421152948.GC23230@ZenIV.linux.org.uk> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Apr 21, 2020 at 04:29:48PM +0100, Al Viro wrote: > On Tue, Apr 21, 2020 at 03:26:00PM +0100, Catalin Marinas wrote: > > While this function is not on a critical path, the single-pass behaviour > > is required for arm64 MTE (memory tagging) support where a uaccess can > > trigger intra-page faults (tag not matching). With the current > > implementation, if this happens during the first page, the function will > > return -EFAULT. > > Details, please. With the arm64 MTE support (memory tagging extensions, see [1] for the full series), bits 56..59 of a pointer (the tag) are checked against the corresponding tag/colour set in memory (on a 16-byte granule). When copy_mount_options() gets such tagged user pointer, it attempts to read 4K even though the user buffer is smaller. The user would only guarantee the same matching tag for the data it masses to mount(), not the whole 4K or to the end of a page. The side effect is that the first copy_from_user() could still fault after reading some bytes but before reaching the end of the page. Prior to commit 12efec560274 ("saner copy_mount_options()"), this code had a fallback to byte-by-byte copying. I thought I'd not revert this commit as the copy_mount_options() now looks cleaner. [1] https://lore.kernel.org/linux-arm-kernel/20200421142603.3894-1-catalin.marinas@arm.com/ -- Catalin