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 82E22C4743C for ; Wed, 23 Jun 2021 04:28:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 853E761360 for ; Wed, 23 Jun 2021 04:28:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 853E761360 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 3BE336B0011; Wed, 23 Jun 2021 00:28:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 36E0E6B0036; Wed, 23 Jun 2021 00:28:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 20F646B006C; Wed, 23 Jun 2021 00:28:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0071.hostedemail.com [216.40.44.71]) by kanga.kvack.org (Postfix) with ESMTP id DE2616B0011 for ; Wed, 23 Jun 2021 00:28:05 -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 21184EFEF for ; Wed, 23 Jun 2021 04:28:06 +0000 (UTC) X-FDA: 78283706172.17.6D2948A Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [142.44.231.140]) by imf08.hostedemail.com (Postfix) with ESMTP id B1A4F801912B for ; Wed, 23 Jun 2021 04:28:05 +0000 (UTC) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1lvuUD-00BPOp-9G; Wed, 23 Jun 2021 04:27:37 +0000 Date: Wed, 23 Jun 2021 04:27:37 +0000 From: Al Viro To: Xiaoming Ni Cc: Chen Huang , Andrew Morton , Stephen Rothwell , "Matthew Wilcox (Oracle)" , 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: References: <92fa298d-9d88-0ca4-40d9-13690dcd42f9@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92fa298d-9d88-0ca4-40d9-13690dcd42f9@huawei.com> Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=none; spf=none (imf08.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-Rspamd-Server: rspam02 X-Stat-Signature: 3yikwebgoqbqt55egs7io4g5ms81sb6u X-Rspamd-Queue-Id: B1A4F801912B X-HE-Tag: 1624422485-555675 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 11:24:54AM +0800, Xiaoming Ni wrote: > On 2021/6/23 10:50, Al Viro wrote: > > On Wed, Jun 23, 2021 at 10:39:31AM +0800, Chen Huang wrote: > > > > > 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. > > > > Looks like you need to fix your raw_copy_from_user(), then... > > . > > > > Exit loop when iov_iter_copy_from_user_atomic() returns 0. > This should solve the problem, too, and it's easier. It might be easier, but it's not going to work correctly. If the page gets evicted by memory pressure, you are going to get spurious short write. Besides, it's simply wrong - write(2) does *NOT* require an aligned source. It (and raw_copy_from_user()) should act the same way memcpy(3) does.