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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 99B71C4743C for ; Wed, 23 Jun 2021 13:04:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 222BE61076 for ; Wed, 23 Jun 2021 13:04:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 222BE61076 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DD4626B0011; Wed, 23 Jun 2021 09:04:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DAABA6B0036; Wed, 23 Jun 2021 09:04:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C4B146B006C; Wed, 23 Jun 2021 09:04:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0160.hostedemail.com [216.40.44.160]) by kanga.kvack.org (Postfix) with ESMTP id 92CCA6B0011 for ; Wed, 23 Jun 2021 09:04:55 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D059019B3F for ; Wed, 23 Jun 2021 13:04:55 +0000 (UTC) X-FDA: 78285008550.17.728B75A Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [142.44.231.140]) by imf01.hostedemail.com (Postfix) with ESMTP id 602C45001700 for ; Wed, 23 Jun 2021 13:04:55 +0000 (UTC) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1lw2YR-00BX5y-SA; Wed, 23 Jun 2021 13:04:31 +0000 Date: Wed, 23 Jun 2021 13:04:31 +0000 From: Al Viro To: Catalin Marinas Cc: Xiaoming Ni , Chen Huang , Andrew Morton , Stephen Rothwell , "Matthew Wilcox (Oracle)" , Randy Dunlap , Will Deacon , Linux ARM , linux-mm , open list Subject: Re: [BUG] arm64: an infinite loop in generic_perform_write() Message-ID: References: <92fa298d-9d88-0ca4-40d9-13690dcd42f9@huawei.com> <20210623093220.GA3718@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210623093220.GA3718@arm.com> Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=none; spf=none (imf01.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 142.44.231.140) smtp.mailfrom=viro@ftp.linux.org.uk X-Stat-Signature: 69na6gswq51orkgngxe4k4ar6eyak3u7 X-Rspamd-Queue-Id: 602C45001700 X-Rspamd-Server: rspam06 X-HE-Tag: 1624453495-721706 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 Wed, Jun 23, 2021 at 10:32:21AM +0100, Catalin Marinas wrote: > On arm64, neither memcpy() nor raw_copy_from_user() are expected to work > on Device mappings, we have memcpy_fromio() for this but only for > ioremap(). There's no (easy) way to distinguish in the write() syscall > how the source buffer is mapped. generic_perform_write() does an > iov_iter_fault_in_readable() check but that's not sufficient and it also > breaks the cases where you can get intra-page faults (arm64 MTE or SPARC > ADI). I think in the general case it's racy anyway (another thread doing > an mprotect(PROT_NONE) after the readable check passed). > > So I think generic_perform_write() returning -EFAULT if copied == 0 > would make sense (well, unless it breaks other cases I'm not aware of). It does break the cases of source page eviction under memory pressure. That aside, why the hell is that memory allowed to be mmaped?