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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 7BA59C4743C for ; Wed, 23 Jun 2021 13:24:32 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 508AF60FEB for ; Wed, 23 Jun 2021 13:24:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 508AF60FEB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tdvKDdJhbXw9VxaPYyYSfcu4WlCXNwsj0yQZZJ2+xoc=; b=FIqhRz4hRf+p+b 9WczPfl53zaniEzvWW2azA0LDRD3Tkcb1jLbpJ0eYYVJBPaYTupoO2W7owJufYUlB2mlHVhv+hvoD JTpJCyLImt7U68RSCKPVAPXdLp5BgmQSHr1MxLRA8yt8+IjVhBqE8X7iV+qvjho1NuMt20S2k1OsA tKj/Vr89AEw2dxaTvXgwMgZMn5WF/EH5fvTFJ1kO10zIeRm2/O7CNFEft9dMKcdg0WlUSI+VVtL9B SpFHt4i621jB2lmq/B+nLePGCSEJ0KOH8oM39nxaI9uGwcHmPLedXu9RbdU2FcQYSst5z+5NHqLvb MD2g1o2TB/YtLSzkhDoQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lw2q1-00Alwz-N3; Wed, 23 Jun 2021 13:22:41 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lw2px-00Alvp-R4 for linux-arm-kernel@lists.infradead.org; Wed, 23 Jun 2021 13:22:39 +0000 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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210623_062237_964668_CB84EBDF X-CRM114-Status: GOOD ( 19.94 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel