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 Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A8D02C43334 for ; Mon, 20 Jun 2022 09:11:38 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4LRP610RWxz3cdB for ; Mon, 20 Jun 2022 19:11:37 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=arm.com (client-ip=217.140.110.172; helo=foss.arm.com; envelope-from=mark.rutland@arm.com; receiver=) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lists.ozlabs.org (Postfix) with ESMTP id 4LRP5T1fxQz304r for ; Mon, 20 Jun 2022 19:11:06 +1000 (AEST) 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 BF0A1113E; Mon, 20 Jun 2022 02:10:33 -0700 (PDT) Received: from FVFF77S0Q05N (unknown [10.57.70.167]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2B72B3F7D7; Mon, 20 Jun 2022 02:10:30 -0700 (PDT) Date: Mon, 20 Jun 2022 10:10:23 +0100 From: Mark Rutland To: Tong Tiangen Subject: Re: [PATCH -next v5 2/8] arm64: extable: make uaaccess helper use extable type EX_TYPE_UACCESS_ERR_ZERO Message-ID: References: <20220528065056.1034168-1-tongtiangen@huawei.com> <20220528065056.1034168-3-tongtiangen@huawei.com> <4371a7c9-8766-9fee-2558-e6f43f06ad19@huawei.com> <0da734f3-5743-3df3-3f90-d92e5bd585ce@huawei.com> <684f0362-6e58-753d-32e1-112c6ffe6d12@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <684f0362-6e58-753d-32e1-112c6ffe6d12@huawei.com> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kefeng Wang , Dave Hansen , linux-mm@kvack.org, Paul Mackerras , Guohanjun , Will Deacon , "H . Peter Anvin" , x86@kernel.org, Ingo Molnar , Catalin Marinas , Xie XiuQi , Borislav Petkov , Alexander Viro , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Robin Murphy , linux-kernel@vger.kernel.org, James Morse , Andrew Morton , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Jun 20, 2022 at 10:59:12AM +0800, Tong Tiangen wrote: > 在 2022/6/18 20:40, Mark Rutland 写道: > > On Sat, Jun 18, 2022 at 04:42:06PM +0800, Tong Tiangen wrote: > > > > > > diff --git a/arch/arm64/include/asm/asm-extable.h > > > > > > b/arch/arm64/include/asm/asm-extable.h > > > > > > index 56ebe183e78b..9c94ac1f082c 100644 > > > > > > --- a/arch/arm64/include/asm/asm-extable.h > > > > > > +++ b/arch/arm64/include/asm/asm-extable.h > > > > > > @@ -28,6 +28,14 @@ > > > > > >       __ASM_EXTABLE_RAW(\insn, \fixup, EX_TYPE_FIXUP, 0) > > > > > >       .endm > > > > > > +/* > > > > > > + * Create an exception table entry for uaccess `insn`, which > > > > > > will branch to `fixup` > > > > > > + * when an unhandled fault is taken. > > > > > > + * ex->data = ~0 means both reg_err and reg_zero is set to wzr(x31). > > > > > > + */ > > > > > > +    .macro          _asm_extable_uaccess, insn, fixup > > > > > > +    __ASM_EXTABLE_RAW(\insn, \fixup, EX_TYPE_UACCESS_ERR_ZERO, ~0) > > > > > > +    .endm > > > > > > > > > > I'm not too keen on using `~0` here, since that also sets other bits > > > > > in the > > > > > data field, and its somewhat opaque. > > > > > > > > > > How painful is it to generate the data fields as with the C version > > > > > of this > > > > > macro, so that we can pass in wzr explciitly for the two sub-fields? > > > > > > > > > > Other than that, this looks good to me. > > > > > > > > > > Thanks, > > > > > Mark. > > > > > > > > ok, will fix next version. > > > > > > > > Thanks, > > > > Tong. > > > > > > I tried to using data filelds as with C version, but here assembly code we > > > can not using operator such as << and |, if we use lsl and orr instructions, > > > the gpr will be occupied. > > > > > > So how about using 0x3ff directly here? it means err register and zero > > > register both set to x31. > > > > I had a go at implementing this, and it seems simple enough. Please see: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/extable/asm-uaccess > > > > I made the following modifications, and the other parts are based on your > implementation: > > arch/arm64/include/asm/asm-extable.h > [...] > .macro _asm_extable_uaccess, insn, fixup > _ASM_EXTABLE_UACCESS(\insn, \fixup) > .endm > [...] I also made this same change locally when testing, and building with GCC 11.1.0 or LLVM 14.0.0 I am not seeing any problem when building, and the result is as expected: | [mark@lakrids:~/src/linux]% usekorg 11.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- defconfig | *** Default configuration is based on 'defconfig' | # | # No change to .config | # | [mark@lakrids:~/src/linux]% usekorg 11.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- -j50 arch/arm64/lib/ | CALL scripts/atomic/check-atomics.sh | CC arch/arm64/kernel/asm-offsets.s | CALL scripts/checksyscalls.sh | AS arch/arm64/kernel/vdso/note.o | AS arch/arm64/kernel/vdso/sigreturn.o | LD arch/arm64/kernel/vdso/vdso.so.dbg | VDSOSYM include/generated/vdso-offsets.h | OBJCOPY arch/arm64/kernel/vdso/vdso.so | make[2]: Nothing to be done for 'arch/arm64/lib/'. | AS arch/arm64/lib/clear_page.o | AS arch/arm64/lib/clear_user.o | AS arch/arm64/lib/copy_from_user.o | AS arch/arm64/lib/copy_page.o | AS arch/arm64/lib/copy_to_user.o | CC arch/arm64/lib/csum.o | CC arch/arm64/lib/delay.o | AS arch/arm64/lib/memchr.o | AS arch/arm64/lib/memcmp.o | AS arch/arm64/lib/memcpy.o | AS arch/arm64/lib/memset.o | AS arch/arm64/lib/strchr.o | AS arch/arm64/lib/strcmp.o | AS arch/arm64/lib/strlen.o | AS arch/arm64/lib/strncmp.o | AS arch/arm64/lib/strnlen.o | AS arch/arm64/lib/strrchr.o | AS arch/arm64/lib/tishift.o | AS arch/arm64/lib/crc32.o | AS arch/arm64/lib/mte.o | CC [M] arch/arm64/lib/xor-neon.o | AR arch/arm64/lib/built-in.a | AR arch/arm64/lib/lib.a | [mark@lakrids:~/src/linux]% usekorg 12.1.0 aarch64-linux-objdump -j __ex_table -D arch/arm64/lib/clear_user.o | | arch/arm64/lib/clear_user.o: file format elf64-littleaarch64 | | | Disassembly of section __ex_table: | | 0000000000000000 <__ex_table>: | ... | 8: 03ff0003 .inst 0x03ff0003 ; undefined | ... | 14: 03ff0003 .inst 0x03ff0003 ; undefined | ... | 20: 03ff0003 .inst 0x03ff0003 ; undefined | ... | 2c: 03ff0003 .inst 0x03ff0003 ; undefined | ... | 38: 03ff0003 .inst 0x03ff0003 ; undefined | ... | 44: 03ff0003 .inst 0x03ff0003 ; undefined > The following errors are reported during compilation: > [...] > arch/arm64/lib/clear_user.S:45: Error: invalid operands (*ABS* and *UND* > sections) for `<<' > [...] As above, I'm not seeing this. This suggests that the EX_DATA_REG() macro is going wrong somehow. Assuming the operand types correspond to the LHS and RHS of the expression, this would mean the GPR number is defined, but the REG value is not, and I can't currently see how that can happen. > "<<" is invalid operands in assembly, is there something wrong with me? At the moment I can only assume there is a local problem. I'd suspect a typo somewhere, but maybe you have a toolchain which behaves differently? Thanks, Mark. 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 85537C43334 for ; Mon, 20 Jun 2022 09:11:48 +0000 (UTC) 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=6DcBQBb07MoPVs+zFAwK8E8rfFGAb4vjb7H/EIN1jw0=; b=KJPS+heCaKcCoK 30MyeGrgEwtfsAOTqfCV3txshYDayAb0n+HrH5KD3CV9L3AQ0QwTmdRxq96gZRwODNAdEzGCFcTF4 ENYqRjW9zIbQVXxByceU4zys5qfe8M44t64DMwB8X8jtBtRTWTV6IQdySlSh8IlPMO9DS5ckMVJkf Ih2IiRzIDs1e4Z+LxmiHVZkAowZhfNuvPWUeXN8ZET0DKsykIXFizeIk39fvkKwcY7rK6E3Km8AGh S1oRfWZUFahAw2KMFpi6sQyfFLMXbuIUSLmi5LQi1lxEFZ/2maxY79rPbf1SBveSAYF2X9OeGD68O oZkk3rL5k9Ue4L9tfEWg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o3DQi-00H4ML-K7; Mon, 20 Jun 2022 09:10:44 +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 1o3DQc-00H4K6-MI for linux-arm-kernel@lists.infradead.org; Mon, 20 Jun 2022 09:10:42 +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 BF0A1113E; Mon, 20 Jun 2022 02:10:33 -0700 (PDT) Received: from FVFF77S0Q05N (unknown [10.57.70.167]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2B72B3F7D7; Mon, 20 Jun 2022 02:10:30 -0700 (PDT) Date: Mon, 20 Jun 2022 10:10:23 +0100 From: Mark Rutland To: Tong Tiangen Cc: James Morse , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Robin Murphy , Dave Hansen , Catalin Marinas , Will Deacon , Alexander Viro , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , x86@kernel.org, "H . Peter Anvin" , linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Kefeng Wang , Xie XiuQi , Guohanjun Subject: Re: [PATCH -next v5 2/8] arm64: extable: make uaaccess helper use extable type EX_TYPE_UACCESS_ERR_ZERO Message-ID: References: <20220528065056.1034168-1-tongtiangen@huawei.com> <20220528065056.1034168-3-tongtiangen@huawei.com> <4371a7c9-8766-9fee-2558-e6f43f06ad19@huawei.com> <0da734f3-5743-3df3-3f90-d92e5bd585ce@huawei.com> <684f0362-6e58-753d-32e1-112c6ffe6d12@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <684f0362-6e58-753d-32e1-112c6ffe6d12@huawei.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220620_021038_864031_1A50028B X-CRM114-Status: GOOD ( 37.08 ) 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="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gTW9uLCBKdW4gMjAsIDIwMjIgYXQgMTA6NTk6MTJBTSArMDgwMCwgVG9uZyBUaWFuZ2VuIHdy b3RlOgo+IOWcqCAyMDIyLzYvMTggMjA6NDAsIE1hcmsgUnV0bGFuZCDlhpnpgZM6Cj4gPiBPbiBT YXQsIEp1biAxOCwgMjAyMiBhdCAwNDo0MjowNlBNICswODAwLCBUb25nIFRpYW5nZW4gd3JvdGU6 Cj4gPiA+ID4gPiA+IGRpZmYgLS1naXQgYS9hcmNoL2FybTY0L2luY2x1ZGUvYXNtL2FzbS1leHRh YmxlLmgKPiA+ID4gPiA+ID4gYi9hcmNoL2FybTY0L2luY2x1ZGUvYXNtL2FzbS1leHRhYmxlLmgK PiA+ID4gPiA+ID4gaW5kZXggNTZlYmUxODNlNzhiLi45Yzk0YWMxZjA4MmMgMTAwNjQ0Cj4gPiA+ ID4gPiA+IC0tLSBhL2FyY2gvYXJtNjQvaW5jbHVkZS9hc20vYXNtLWV4dGFibGUuaAo+ID4gPiA+ ID4gPiArKysgYi9hcmNoL2FybTY0L2luY2x1ZGUvYXNtL2FzbS1leHRhYmxlLmgKPiA+ID4gPiA+ ID4gQEAgLTI4LDYgKzI4LDE0IEBACj4gPiA+ID4gPiA+ICDCoMKgwqDCoMKgIF9fQVNNX0VYVEFC TEVfUkFXKFxpbnNuLCBcZml4dXAsIEVYX1RZUEVfRklYVVAsIDApCj4gPiA+ID4gPiA+ICDCoMKg wqDCoMKgIC5lbmRtCj4gPiA+ID4gPiA+ICsvKgo+ID4gPiA+ID4gPiArICogQ3JlYXRlIGFuIGV4 Y2VwdGlvbiB0YWJsZSBlbnRyeSBmb3IgdWFjY2VzcyBgaW5zbmAsIHdoaWNoCj4gPiA+ID4gPiA+ IHdpbGwgYnJhbmNoIHRvIGBmaXh1cGAKPiA+ID4gPiA+ID4gKyAqIHdoZW4gYW4gdW5oYW5kbGVk IGZhdWx0IGlzIHRha2VuLgo+ID4gPiA+ID4gPiArICogZXgtPmRhdGEgPSB+MCBtZWFucyBib3Ro IHJlZ19lcnIgYW5kIHJlZ196ZXJvIGlzIHNldCB0byB3enIoeDMxKS4KPiA+ID4gPiA+ID4gKyAq Lwo+ID4gPiA+ID4gPiArwqDCoMKgIC5tYWNyb8KgwqDCoMKgwqDCoMKgwqDCoCBfYXNtX2V4dGFi bGVfdWFjY2VzcywgaW5zbiwgZml4dXAKPiA+ID4gPiA+ID4gK8KgwqDCoCBfX0FTTV9FWFRBQkxF X1JBVyhcaW5zbiwgXGZpeHVwLCBFWF9UWVBFX1VBQ0NFU1NfRVJSX1pFUk8sIH4wKQo+ID4gPiA+ ID4gPiArwqDCoMKgIC5lbmRtCj4gPiA+ID4gPiAKPiA+ID4gPiA+IEknbSBub3QgdG9vIGtlZW4g b24gdXNpbmcgYH4wYCBoZXJlLCBzaW5jZSB0aGF0IGFsc28gc2V0cyBvdGhlciBiaXRzCj4gPiA+ ID4gPiBpbiB0aGUKPiA+ID4gPiA+IGRhdGEgZmllbGQsIGFuZCBpdHMgc29tZXdoYXQgb3BhcXVl Lgo+ID4gPiA+ID4gCj4gPiA+ID4gPiBIb3cgcGFpbmZ1bCBpcyBpdCB0byBnZW5lcmF0ZSB0aGUg ZGF0YSBmaWVsZHMgYXMgd2l0aCB0aGUgQyB2ZXJzaW9uCj4gPiA+ID4gPiBvZiB0aGlzCj4gPiA+ ID4gPiBtYWNybywgc28gdGhhdCB3ZSBjYW4gcGFzcyBpbiB3enIgZXhwbGNpaXRseSBmb3IgdGhl IHR3byBzdWItZmllbGRzPwo+ID4gPiA+ID4gCj4gPiA+ID4gPiBPdGhlciB0aGFuIHRoYXQsIHRo aXMgbG9va3MgZ29vZCB0byBtZS4KPiA+ID4gPiA+IAo+ID4gPiA+ID4gVGhhbmtzLAo+ID4gPiA+ ID4gTWFyay4KPiA+ID4gPiAKPiA+ID4gPiBvaywgd2lsbCBmaXggbmV4dCB2ZXJzaW9uLgo+ID4g PiA+IAo+ID4gPiA+IFRoYW5rcywKPiA+ID4gPiBUb25nLgo+ID4gPiAKPiA+ID4gSSB0cmllZCB0 byB1c2luZyBkYXRhIGZpbGVsZHMgYXMgd2l0aCBDIHZlcnNpb24sIGJ1dCBoZXJlIGFzc2VtYmx5 IGNvZGUgd2UKPiA+ID4gY2FuIG5vdCB1c2luZyBvcGVyYXRvciBzdWNoIGFzIDw8IGFuZCB8LCBp ZiB3ZSB1c2UgbHNsIGFuZCBvcnIgaW5zdHJ1Y3Rpb25zLAo+ID4gPiB0aGUgZ3ByIHdpbGwgYmUg b2NjdXBpZWQuCj4gPiA+IAo+ID4gPiBTbyBob3cgYWJvdXQgdXNpbmcgMHgzZmYgZGlyZWN0bHkg aGVyZT8gaXQgbWVhbnMgZXJyIHJlZ2lzdGVyIGFuZCB6ZXJvCj4gPiA+IHJlZ2lzdGVyIGJvdGgg c2V0IHRvIHgzMS4KPiA+IAo+ID4gSSBoYWQgYSBnbyBhdCBpbXBsZW1lbnRpbmcgdGhpcywgYW5k IGl0IHNlZW1zIHNpbXBsZSBlbm91Z2guIFBsZWFzZSBzZWU6Cj4gPiAKPiA+ICAgIGh0dHBzOi8v Z2l0Lmtlcm5lbC5vcmcvcHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L21hcmsvbGludXguZ2l0L2xv Zy8/aD1hcm02NC9leHRhYmxlL2FzbS11YWNjZXNzCj4gPiAKPiAKPiBJIG1hZGUgdGhlIGZvbGxv d2luZyBtb2RpZmljYXRpb25zLCBhbmQgdGhlIG90aGVyIHBhcnRzIGFyZSBiYXNlZCBvbiB5b3Vy Cj4gaW1wbGVtZW50YXRpb246Cj4gCj4gYXJjaC9hcm02NC9pbmNsdWRlL2FzbS9hc20tZXh0YWJs ZS5oCj4gWy4uLl0KPiAubWFjcm8gICAgICAgICAgX2FzbV9leHRhYmxlX3VhY2Nlc3MsIGluc24s IGZpeHVwCj4gX0FTTV9FWFRBQkxFX1VBQ0NFU1MoXGluc24sIFxmaXh1cCkKPiAuZW5kbQo+IFsu Li5dCgpJIGFsc28gbWFkZSB0aGlzIHNhbWUgY2hhbmdlIGxvY2FsbHkgd2hlbiB0ZXN0aW5nLCBh bmQgYnVpbGRpbmcgd2l0aCBHQ0MgMTEuMS4wCm9yIExMVk0gMTQuMC4wIEkgYW0gbm90IHNlZWlu ZyBhbnkgcHJvYmxlbSB3aGVuIGJ1aWxkaW5nLCBhbmQgdGhlIHJlc3VsdCBpcyBhcwpleHBlY3Rl ZDoKCnwgW21hcmtAbGFrcmlkczp+L3NyYy9saW51eF0lIHVzZWtvcmcgMTEuMS4wIG1ha2UgQVJD SD1hcm02NCBDUk9TU19DT01QSUxFPWFhcmNoNjQtbGludXgtIGRlZmNvbmZpZwp8ICoqKiBEZWZh dWx0IGNvbmZpZ3VyYXRpb24gaXMgYmFzZWQgb24gJ2RlZmNvbmZpZycKfCAjCnwgIyBObyBjaGFu Z2UgdG8gLmNvbmZpZwp8ICMKfCBbbWFya0BsYWtyaWRzOn4vc3JjL2xpbnV4XSUgdXNla29yZyAx MS4xLjAgbWFrZSBBUkNIPWFybTY0IENST1NTX0NPTVBJTEU9YWFyY2g2NC1saW51eC0gLWo1MCBh cmNoL2FybTY0L2xpYi8KfCAgIENBTEwgICAgc2NyaXB0cy9hdG9taWMvY2hlY2stYXRvbWljcy5z aAp8ICAgQ0MgICAgICBhcmNoL2FybTY0L2tlcm5lbC9hc20tb2Zmc2V0cy5zCnwgICBDQUxMICAg IHNjcmlwdHMvY2hlY2tzeXNjYWxscy5zaAp8ICAgQVMgICAgICBhcmNoL2FybTY0L2tlcm5lbC92 ZHNvL25vdGUubwp8ICAgQVMgICAgICBhcmNoL2FybTY0L2tlcm5lbC92ZHNvL3NpZ3JldHVybi5v CnwgICBMRCAgICAgIGFyY2gvYXJtNjQva2VybmVsL3Zkc28vdmRzby5zby5kYmcKfCAgIFZEU09T WU0gaW5jbHVkZS9nZW5lcmF0ZWQvdmRzby1vZmZzZXRzLmgKfCAgIE9CSkNPUFkgYXJjaC9hcm02 NC9rZXJuZWwvdmRzby92ZHNvLnNvCnwgbWFrZVsyXTogTm90aGluZyB0byBiZSBkb25lIGZvciAn YXJjaC9hcm02NC9saWIvJy4KfCAgIEFTICAgICAgYXJjaC9hcm02NC9saWIvY2xlYXJfcGFnZS5v CnwgICBBUyAgICAgIGFyY2gvYXJtNjQvbGliL2NsZWFyX3VzZXIubwp8ICAgQVMgICAgICBhcmNo L2FybTY0L2xpYi9jb3B5X2Zyb21fdXNlci5vCnwgICBBUyAgICAgIGFyY2gvYXJtNjQvbGliL2Nv cHlfcGFnZS5vCnwgICBBUyAgICAgIGFyY2gvYXJtNjQvbGliL2NvcHlfdG9fdXNlci5vCnwgICBD QyAgICAgIGFyY2gvYXJtNjQvbGliL2NzdW0ubwp8ICAgQ0MgICAgICBhcmNoL2FybTY0L2xpYi9k ZWxheS5vCnwgICBBUyAgICAgIGFyY2gvYXJtNjQvbGliL21lbWNoci5vCnwgICBBUyAgICAgIGFy Y2gvYXJtNjQvbGliL21lbWNtcC5vCnwgICBBUyAgICAgIGFyY2gvYXJtNjQvbGliL21lbWNweS5v CnwgICBBUyAgICAgIGFyY2gvYXJtNjQvbGliL21lbXNldC5vCnwgICBBUyAgICAgIGFyY2gvYXJt NjQvbGliL3N0cmNoci5vCnwgICBBUyAgICAgIGFyY2gvYXJtNjQvbGliL3N0cmNtcC5vCnwgICBB UyAgICAgIGFyY2gvYXJtNjQvbGliL3N0cmxlbi5vCnwgICBBUyAgICAgIGFyY2gvYXJtNjQvbGli L3N0cm5jbXAubwp8ICAgQVMgICAgICBhcmNoL2FybTY0L2xpYi9zdHJubGVuLm8KfCAgIEFTICAg ICAgYXJjaC9hcm02NC9saWIvc3RycmNoci5vCnwgICBBUyAgICAgIGFyY2gvYXJtNjQvbGliL3Rp c2hpZnQubwp8ICAgQVMgICAgICBhcmNoL2FybTY0L2xpYi9jcmMzMi5vCnwgICBBUyAgICAgIGFy Y2gvYXJtNjQvbGliL210ZS5vCnwgICBDQyBbTV0gIGFyY2gvYXJtNjQvbGliL3hvci1uZW9uLm8K fCAgIEFSICAgICAgYXJjaC9hcm02NC9saWIvYnVpbHQtaW4uYQp8ICAgQVIgICAgICBhcmNoL2Fy bTY0L2xpYi9saWIuYQp8IFttYXJrQGxha3JpZHM6fi9zcmMvbGludXhdJSB1c2Vrb3JnIDEyLjEu MCBhYXJjaDY0LWxpbnV4LW9iamR1bXAgLWogX19leF90YWJsZSAtRCBhcmNoL2FybTY0L2xpYi9j bGVhcl91c2VyLm8KfCAKfCBhcmNoL2FybTY0L2xpYi9jbGVhcl91c2VyLm86ICAgICBmaWxlIGZv cm1hdCBlbGY2NC1saXR0bGVhYXJjaDY0CnwgCnwgCnwgRGlzYXNzZW1ibHkgb2Ygc2VjdGlvbiBf X2V4X3RhYmxlOgp8IAp8IDAwMDAwMDAwMDAwMDAwMDAgPF9fZXhfdGFibGU+Ogp8ICAgICAgICAg Li4uCnwgICAgODogICAwM2ZmMDAwMyAgICAgICAgLmluc3QgICAweDAzZmYwMDAzIDsgdW5kZWZp bmVkCnwgICAgICAgICAuLi4KfCAgIDE0OiAgIDAzZmYwMDAzICAgICAgICAuaW5zdCAgIDB4MDNm ZjAwMDMgOyB1bmRlZmluZWQKfCAgICAgICAgIC4uLgp8ICAgMjA6ICAgMDNmZjAwMDMgICAgICAg IC5pbnN0ICAgMHgwM2ZmMDAwMyA7IHVuZGVmaW5lZAp8ICAgICAgICAgLi4uCnwgICAyYzogICAw M2ZmMDAwMyAgICAgICAgLmluc3QgICAweDAzZmYwMDAzIDsgdW5kZWZpbmVkCnwgICAgICAgICAu Li4KfCAgIDM4OiAgIDAzZmYwMDAzICAgICAgICAuaW5zdCAgIDB4MDNmZjAwMDMgOyB1bmRlZmlu ZWQKfCAgICAgICAgIC4uLgp8ICAgNDQ6ICAgMDNmZjAwMDMgICAgICAgIC5pbnN0ICAgMHgwM2Zm MDAwMyA7IHVuZGVmaW5lZAoKPiBUaGUgZm9sbG93aW5nIGVycm9ycyBhcmUgcmVwb3J0ZWQgZHVy aW5nIGNvbXBpbGF0aW9uOgo+IFsuLi5dCj4gYXJjaC9hcm02NC9saWIvY2xlYXJfdXNlci5TOjQ1 OiBFcnJvcjogaW52YWxpZCBvcGVyYW5kcyAoKkFCUyogYW5kICpVTkQqCj4gc2VjdGlvbnMpIGZv ciBgPDwnCj4gWy4uLl0KCkFzIGFib3ZlLCBJJ20gbm90IHNlZWluZyB0aGlzLgoKVGhpcyBzdWdn ZXN0cyB0aGF0IHRoZSBFWF9EQVRBX1JFRygpIG1hY3JvIGlzIGdvaW5nIHdyb25nIHNvbWVob3cu IEFzc3VtaW5nIHRoZQpvcGVyYW5kIHR5cGVzIGNvcnJlc3BvbmQgdG8gdGhlIExIUyBhbmQgUkhT IG9mIHRoZSBleHByZXNzaW9uLCB0aGlzIHdvdWxkIG1lYW4KdGhlIEdQUiBudW1iZXIgaXMgZGVm aW5lZCwgYnV0IHRoZSBSRUcgdmFsdWUgaXMgbm90LCBhbmQgSSBjYW4ndCBjdXJyZW50bHkgc2Vl CmhvdyB0aGF0IGNhbiBoYXBwZW4uCgo+ICI8PCIgaXMgaW52YWxpZCBvcGVyYW5kcyBpbiBhc3Nl bWJseSwgaXMgdGhlcmUgc29tZXRoaW5nIHdyb25nIHdpdGggbWU/CgpBdCB0aGUgbW9tZW50IEkg Y2FuIG9ubHkgYXNzdW1lIHRoZXJlIGlzIGEgbG9jYWwgcHJvYmxlbS4gSSdkIHN1c3BlY3QgYSB0 eXBvCnNvbWV3aGVyZSwgYnV0IG1heWJlIHlvdSBoYXZlIGEgdG9vbGNoYWluIHdoaWNoIGJlaGF2 ZXMgZGlmZmVyZW50bHk/CgpUaGFua3MsCk1hcmsuCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51 eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5v cmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg== 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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70947CCA479 for ; Mon, 20 Jun 2022 09:10:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 07D266B0083; Mon, 20 Jun 2022 05:10:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 02B406B0085; Mon, 20 Jun 2022 05:10:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E35F48E0005; Mon, 20 Jun 2022 05:10:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D0BCE6B0083 for ; Mon, 20 Jun 2022 05:10:36 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id A04B260C9F for ; Mon, 20 Jun 2022 09:10:36 +0000 (UTC) X-FDA: 79598043672.28.166258A Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf04.hostedemail.com (Postfix) with ESMTP id B904F4009E for ; Mon, 20 Jun 2022 09:10: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 BF0A1113E; Mon, 20 Jun 2022 02:10:33 -0700 (PDT) Received: from FVFF77S0Q05N (unknown [10.57.70.167]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2B72B3F7D7; Mon, 20 Jun 2022 02:10:30 -0700 (PDT) Date: Mon, 20 Jun 2022 10:10:23 +0100 From: Mark Rutland To: Tong Tiangen Cc: James Morse , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Robin Murphy , Dave Hansen , Catalin Marinas , Will Deacon , Alexander Viro , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , x86@kernel.org, "H . Peter Anvin" , linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Kefeng Wang , Xie XiuQi , Guohanjun Subject: Re: [PATCH -next v5 2/8] arm64: extable: make uaaccess helper use extable type EX_TYPE_UACCESS_ERR_ZERO Message-ID: References: <20220528065056.1034168-1-tongtiangen@huawei.com> <20220528065056.1034168-3-tongtiangen@huawei.com> <4371a7c9-8766-9fee-2558-e6f43f06ad19@huawei.com> <0da734f3-5743-3df3-3f90-d92e5bd585ce@huawei.com> <684f0362-6e58-753d-32e1-112c6ffe6d12@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <684f0362-6e58-753d-32e1-112c6ffe6d12@huawei.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655716235; a=rsa-sha256; cv=none; b=ydrL/KBiDpzvpB0AbNXXCJWLAe2NCA51b97pdLzGRDsafei596qCHyxHbg7QkPam54JfEL bzqEROedUC34fR61X2qB8T2FM/NFjJz8b+IxBaZlenoeXubT9HVCb2Qa6ZZ7osgZJkdj1j /NizOmioVxCCrYCn405pUYNMJib+uo4= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; spf=pass (imf04.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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655716235; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LsdSrajL39exqNVQu5D+IQxGLTgSbYHj0zKZGjATkqY=; b=trsE/sv7nwuJoM6DOdZTuQRw/Ce1wzExPeGogFkd99eomfnozQf8uBKUFx16HS73r76A6F NXUk2q5ELIl2V90tiULcacGOukc5cKzguYkoVEPIowB8WnNlp3ksmgkHOUXvQoL56NFLGl vHzOnUHdWT9q5AFMBPYeIJXmDcbU+4o= Authentication-Results: imf04.hostedemail.com; dkim=none; spf=pass (imf04.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-Rspam-User: X-Stat-Signature: uyhgc9suqfj51hu71x9y6o4zxc73ixx7 X-Rspamd-Queue-Id: B904F4009E X-Rspamd-Server: rspam08 X-HE-Tag: 1655716234-133581 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 Mon, Jun 20, 2022 at 10:59:12AM +0800, Tong Tiangen wrote: > 在 2022/6/18 20:40, Mark Rutland 写道: > > On Sat, Jun 18, 2022 at 04:42:06PM +0800, Tong Tiangen wrote: > > > > > > diff --git a/arch/arm64/include/asm/asm-extable.h > > > > > > b/arch/arm64/include/asm/asm-extable.h > > > > > > index 56ebe183e78b..9c94ac1f082c 100644 > > > > > > --- a/arch/arm64/include/asm/asm-extable.h > > > > > > +++ b/arch/arm64/include/asm/asm-extable.h > > > > > > @@ -28,6 +28,14 @@ > > > > > >       __ASM_EXTABLE_RAW(\insn, \fixup, EX_TYPE_FIXUP, 0) > > > > > >       .endm > > > > > > +/* > > > > > > + * Create an exception table entry for uaccess `insn`, which > > > > > > will branch to `fixup` > > > > > > + * when an unhandled fault is taken. > > > > > > + * ex->data = ~0 means both reg_err and reg_zero is set to wzr(x31). > > > > > > + */ > > > > > > +    .macro          _asm_extable_uaccess, insn, fixup > > > > > > +    __ASM_EXTABLE_RAW(\insn, \fixup, EX_TYPE_UACCESS_ERR_ZERO, ~0) > > > > > > +    .endm > > > > > > > > > > I'm not too keen on using `~0` here, since that also sets other bits > > > > > in the > > > > > data field, and its somewhat opaque. > > > > > > > > > > How painful is it to generate the data fields as with the C version > > > > > of this > > > > > macro, so that we can pass in wzr explciitly for the two sub-fields? > > > > > > > > > > Other than that, this looks good to me. > > > > > > > > > > Thanks, > > > > > Mark. > > > > > > > > ok, will fix next version. > > > > > > > > Thanks, > > > > Tong. > > > > > > I tried to using data filelds as with C version, but here assembly code we > > > can not using operator such as << and |, if we use lsl and orr instructions, > > > the gpr will be occupied. > > > > > > So how about using 0x3ff directly here? it means err register and zero > > > register both set to x31. > > > > I had a go at implementing this, and it seems simple enough. Please see: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/extable/asm-uaccess > > > > I made the following modifications, and the other parts are based on your > implementation: > > arch/arm64/include/asm/asm-extable.h > [...] > .macro _asm_extable_uaccess, insn, fixup > _ASM_EXTABLE_UACCESS(\insn, \fixup) > .endm > [...] I also made this same change locally when testing, and building with GCC 11.1.0 or LLVM 14.0.0 I am not seeing any problem when building, and the result is as expected: | [mark@lakrids:~/src/linux]% usekorg 11.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- defconfig | *** Default configuration is based on 'defconfig' | # | # No change to .config | # | [mark@lakrids:~/src/linux]% usekorg 11.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- -j50 arch/arm64/lib/ | CALL scripts/atomic/check-atomics.sh | CC arch/arm64/kernel/asm-offsets.s | CALL scripts/checksyscalls.sh | AS arch/arm64/kernel/vdso/note.o | AS arch/arm64/kernel/vdso/sigreturn.o | LD arch/arm64/kernel/vdso/vdso.so.dbg | VDSOSYM include/generated/vdso-offsets.h | OBJCOPY arch/arm64/kernel/vdso/vdso.so | make[2]: Nothing to be done for 'arch/arm64/lib/'. | AS arch/arm64/lib/clear_page.o | AS arch/arm64/lib/clear_user.o | AS arch/arm64/lib/copy_from_user.o | AS arch/arm64/lib/copy_page.o | AS arch/arm64/lib/copy_to_user.o | CC arch/arm64/lib/csum.o | CC arch/arm64/lib/delay.o | AS arch/arm64/lib/memchr.o | AS arch/arm64/lib/memcmp.o | AS arch/arm64/lib/memcpy.o | AS arch/arm64/lib/memset.o | AS arch/arm64/lib/strchr.o | AS arch/arm64/lib/strcmp.o | AS arch/arm64/lib/strlen.o | AS arch/arm64/lib/strncmp.o | AS arch/arm64/lib/strnlen.o | AS arch/arm64/lib/strrchr.o | AS arch/arm64/lib/tishift.o | AS arch/arm64/lib/crc32.o | AS arch/arm64/lib/mte.o | CC [M] arch/arm64/lib/xor-neon.o | AR arch/arm64/lib/built-in.a | AR arch/arm64/lib/lib.a | [mark@lakrids:~/src/linux]% usekorg 12.1.0 aarch64-linux-objdump -j __ex_table -D arch/arm64/lib/clear_user.o | | arch/arm64/lib/clear_user.o: file format elf64-littleaarch64 | | | Disassembly of section __ex_table: | | 0000000000000000 <__ex_table>: | ... | 8: 03ff0003 .inst 0x03ff0003 ; undefined | ... | 14: 03ff0003 .inst 0x03ff0003 ; undefined | ... | 20: 03ff0003 .inst 0x03ff0003 ; undefined | ... | 2c: 03ff0003 .inst 0x03ff0003 ; undefined | ... | 38: 03ff0003 .inst 0x03ff0003 ; undefined | ... | 44: 03ff0003 .inst 0x03ff0003 ; undefined > The following errors are reported during compilation: > [...] > arch/arm64/lib/clear_user.S:45: Error: invalid operands (*ABS* and *UND* > sections) for `<<' > [...] As above, I'm not seeing this. This suggests that the EX_DATA_REG() macro is going wrong somehow. Assuming the operand types correspond to the LHS and RHS of the expression, this would mean the GPR number is defined, but the REG value is not, and I can't currently see how that can happen. > "<<" is invalid operands in assembly, is there something wrong with me? At the moment I can only assume there is a local problem. I'd suspect a typo somewhere, but maybe you have a toolchain which behaves differently? Thanks, Mark.