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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,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 828D1C49EA5 for ; Thu, 24 Jun 2021 13:22:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 101D8613CE for ; Thu, 24 Jun 2021 13:22:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 101D8613CE Authentication-Results: mail.kernel.org; dmarc=fail (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 E09016B0036; Thu, 24 Jun 2021 09:22:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DB9C66B005D; Thu, 24 Jun 2021 09:22:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C331D6B006C; Thu, 24 Jun 2021 09:22:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0119.hostedemail.com [216.40.44.119]) by kanga.kvack.org (Postfix) with ESMTP id 8F8656B0036 for ; Thu, 24 Jun 2021 09:22:35 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B38DC1810F5FC for ; Thu, 24 Jun 2021 13:22:35 +0000 (UTC) X-FDA: 78288681870.06.F812A4A Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf10.hostedemail.com (Postfix) with ESMTP id F23944202A14 for ; Thu, 24 Jun 2021 13:22:34 +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 1D710ED1; Thu, 24 Jun 2021 06:22:34 -0700 (PDT) Received: from [10.57.9.136] (unknown [10.57.9.136]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2BD2F3F718; Thu, 24 Jun 2021 06:22:32 -0700 (PDT) Subject: Re: [BUG] arm64: an infinite loop in generic_perform_write() To: Matthew Wilcox , Christoph Hellwig Cc: Chen Huang , Mark Rutland , Andrew Morton , Stephen Rothwell , Al Viro , Randy Dunlap , Catalin Marinas , Will Deacon , Linux ARM , linux-mm , open list References: <20210623132223.GA96264@C02TD0UTHF1T.local> <1c635945-fb25-8871-7b34-f475f75b2caf@huawei.com> From: Robin Murphy Message-ID: <27fbb8c1-2a65-738f-6bec-13f450395ab7@arm.com> Date: Thu, 24 Jun 2021 14:22:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Authentication-Results: imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of robin.murphy@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=robin.murphy@arm.com; dmarc=pass (policy=none) header.from=arm.com X-Stat-Signature: 9rx8y1oqifwodbrb5d8u3moaqza1o7yh X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: F23944202A14 X-HE-Tag: 1624540954-646666 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 2021-06-24 12:15, Matthew Wilcox wrote: > On Thu, Jun 24, 2021 at 08:04:07AM +0100, Christoph Hellwig wrote: >> On Thu, Jun 24, 2021 at 04:24:46AM +0100, Matthew Wilcox wrote: >>> On Thu, Jun 24, 2021 at 11:10:41AM +0800, Chen Huang wrote: >>>> In userspace, I perform such operation: >>>> >>>> fd = open("/tmp/test", O_RDWR | O_SYNC); >>>> access_address = (char *)mmap(NULL, uio_size, PROT_READ, MAP_SHARED, uio_fd, 0); >>>> ret = write(fd, access_address + 2, sizeof(long)); >>> >>> ... you know that accessing this at unaligned offsets isn't going to >>> work. It's completely meaningless. Why are you trying to do it? >> >> We still should not cause an infinite loop in kernel space due to a >> a userspace programmer error. > > They're running as root and they've mapped some device memory. We can't > save them from themself. Imagine if they'd done this to the NVMe BAR. FWIW I think the only way to make the kernel behaviour any more robust here would be to make the whole uaccess API more expressive, such that rather than simply saying "I only got this far" it could actually differentiate between stopping due to a fault which may be recoverable and worth retrying, and one which definitely isn't. Unless maybe there's the possibility to abandon a syscall and SIGBUS the process directly from the uaccess fixup path, but even to my limited knowledge that seems unlikely. (I'm not counting "cap the number of retries to a very large value to guarantee *eventual* failure" as robust, but I suppose it's a potential option too) Robin.