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 9D7F2C48BC2 for ; Wed, 23 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 2174261075 for ; Wed, 23 Jun 2021 13:22:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2174261075 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 ECBA16B0011; Wed, 23 Jun 2021 09:22:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E7C066B0036; Wed, 23 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 D43F66B006C; Wed, 23 Jun 2021 09:22:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0039.hostedemail.com [216.40.44.39]) by kanga.kvack.org (Postfix) with ESMTP id 9AC296B0011 for ; Wed, 23 Jun 2021 09:22:35 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id CF1B8181AEF0B for ; Wed, 23 Jun 2021 13:22:35 +0000 (UTC) X-FDA: 78285053070.14.3C92769 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf30.hostedemail.com (Postfix) with ESMTP id 124C3E000689 for ; Wed, 23 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 0B9F5ED1; Wed, 23 Jun 2021 06:22:34 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.11.195]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6FD013F718; Wed, 23 Jun 2021 06:22:31 -0700 (PDT) Date: Wed, 23 Jun 2021 14:22:23 +0100 From: Mark Rutland To: Chen Huang Cc: Andrew Morton , Stephen Rothwell , "Matthew Wilcox (Oracle)" , Al Viro , Randy Dunlap , Catalin Marinas , Will Deacon , Linux ARM , linux-mm , open list Subject: Re: [BUG] arm64: an infinite loop in generic_perform_write() Message-ID: <20210623132223.GA96264@C02TD0UTHF1T.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf30.hostedemail.com; dkim=none; spf=pass (imf30.hostedemail.com: domain of mark.rutland@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=mark.rutland@arm.com; dmarc=pass (policy=none) header.from=arm.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 124C3E000689 X-Stat-Signature: 66dr5nw3dpwq1gspuxd3cbp7xj3jcxf5 X-HE-Tag: 1624454554-178632 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:39:31AM +0800, Chen Huang wrote: > When we access a device memory in userspace, then perform an unaligned write to a file. > For example, we register a uio device and mmap the device, then perform an write to a > file, like that: > > device_addr = mmap(device_fd); > write(file_fd, device_addr + unaligned_num, size); What exactly is this device, and why do you want the kernel to do a direct memcpy from MMIO? Why can't you copy that in userspace (where you have knowledge of the device), then pass the copy to a syscall? Ignoring the lockup below, this isn't going to work in general, since uaccess routines do not guarantee alignment, single-copy, access sizes, monotonically increasing addresses, etc. Any one of those can cause a device to raise an external abort which may or may not be synchronous. It does not make sense to tell the kernel to access this, since the kernel cannot know how to access it safely, and we can;t do that without knowledge of the device that we do not have. Thanks, Mark. > > We found that the infinite loop happened in generic_perform_write function: > > again: > copied = copy_page_from_iter_atomic(); //copied = 0 > status = ops->write_end(); //status = 0 > if (status == 0) > goto again; > > In copy_page_from_iter_atomic, the copyin() function finally call > __arch_copy_from_user which create an exception table entry for 'insn'. > Then when kernel handles the alignment_fault, it will not panic. As the > arm64 memory model spec said, when the address is not a multiple of the > element size, the access is unaligned. Unaligned accesses are allowed to > addresses marked as Normal, but not to Device regions. An unaligned access > to a Device region will trigger an exception (alignment fault). > > do_alignment_fault > do_bad_area > __do_kernel_fault > fixup_exception > > But that fixup cann't handle the unaligned copy, so the > copy_page_from_iter_atomic returns 0 and traps in loop. > > Reported-by: Chen Huang