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.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 1BB9AC49EA6 for ; Thu, 24 Jun 2021 03:10:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4EEEE6100A for ; Thu, 24 Jun 2021 03:10:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4EEEE6100A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1846A6B0073; Wed, 23 Jun 2021 23:10:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 135646B0075; Wed, 23 Jun 2021 23:10:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F179B8D0003; Wed, 23 Jun 2021 23:10:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0156.hostedemail.com [216.40.44.156]) by kanga.kvack.org (Postfix) with ESMTP id B14B86B0073 for ; Wed, 23 Jun 2021 23:10:48 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id CCA888249980 for ; Thu, 24 Jun 2021 03:10:48 +0000 (UTC) X-FDA: 78287140176.20.3FB9E76 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by imf20.hostedemail.com (Postfix) with ESMTP id 9146A366 for ; Thu, 24 Jun 2021 03:10:47 +0000 (UTC) Received: from dggemv711-chm.china.huawei.com (unknown [172.30.72.56]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4G9Q5R5tljz70gq; Thu, 24 Jun 2021 11:06:35 +0800 (CST) Received: from dggema756-chm.china.huawei.com (10.1.198.198) by dggemv711-chm.china.huawei.com (10.1.198.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Thu, 24 Jun 2021 11:10:43 +0800 Received: from [10.174.177.134] (10.174.177.134) by dggema756-chm.china.huawei.com (10.1.198.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Thu, 24 Jun 2021 11:10:42 +0800 Subject: Re: [BUG] arm64: an infinite loop in generic_perform_write() To: Mark Rutland CC: Andrew Morton , Stephen Rothwell , "Matthew Wilcox (Oracle)" , "Al Viro" , Randy Dunlap , "Catalin Marinas" , Will Deacon , Linux ARM , linux-mm , "open list" References: <20210623132223.GA96264@C02TD0UTHF1T.local> From: Chen Huang Message-ID: <1c635945-fb25-8871-7b34-f475f75b2caf@huawei.com> Date: Thu, 24 Jun 2021 11:10:41 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20210623132223.GA96264@C02TD0UTHF1T.local> Content-Type: text/plain; charset="gbk" X-Originating-IP: [10.174.177.134] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggema756-chm.china.huawei.com (10.1.198.198) X-CFilter-Loop: Reflected Authentication-Results: imf20.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=huawei.com; spf=pass (imf20.hostedemail.com: domain of chenhuang5@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=chenhuang5@huawei.com X-Rspamd-Server: rspam02 X-Stat-Signature: m99653f1zzu4rdpg3jrcrtchr4zt3m1b X-Rspamd-Queue-Id: 9146A366 X-HE-Tag: 1624504247-842444 Content-Transfer-Encoding: quoted-printable 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: =D4=DA 2021/6/23 21:22, Mark Rutland =D0=B4=B5=C0: > 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 perfor= m an write to a >> file, like that: >> >> device_addr =3D mmap(device_fd); >> write(file_fd, device_addr + unaligned_num, size); >=20 > 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 yo= u > have knowledge of the device), then pass the copy to a syscall? > I'm sorry for not describing the problem well. It's an uio device: static struct device_driver uio_dummy_driver =3D { .name =3D "uio_with_name", .bus =3D &platform_bus_type, .probe =3D drv_uio_with_name_probe, .remove =3D drv_uio_with_name_remove, }; static int drv_uio_with_name_probe(struct device *dev) { uio_with_name_info.mem[0].addr =3D 0xa0000000; uio_with_name_info.mem[0].memtype =3D UIO_MEM_PHYS; uio_with_name_info.mem[0].size =3D 0x1000; if (__uio_register_device(THIS_MODULE, dev, &uio_with_name_info)) { printk("__uio_register_device failed\n"); return -ENODEV; } printk("UIO init end.\n"); return 0; } In userspace, I perform such operation: fd =3D open("/tmp/test", O_RDWR | O_SYNC); access_address =3D (char *)mmap(NULL, uio_size, PROT_READ, MAP_SH= ARED, uio_fd, 0); ret =3D write(fd, access_address + 2, sizeof(long)); > 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. >=20 > 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 withou= t > knowledge of the device that we do not have. >=20 > Thanks, > Mark. >=20 >> =09 >> We found that the infinite loop happened in generic_perform_write func= tion: >> >> again: >> copied =3D copy_page_from_iter_atomic(); //copied =3D 0 >> status =3D ops->write_end(); //status =3D 0 >> if (status =3D=3D 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 th= e >> arm64 memory model spec said, when the address is not a multiple of th= e >> element size, the access is unaligned. Unaligned accesses are allowed = to >> addresses marked as Normal, but not to Device regions. An unaligned ac= cess >> to a Device region will trigger an exception (alignment fault). >> =09 >> 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 > . >=20