Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp2965963iog; Mon, 20 Jun 2022 08:24:39 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uMKUQj6Ut0ZQ//vayVHX5ce832q2bWs+lXDqJbCLYlapTH/neyMcpPwsHP9REUeAW6f7ID X-Received: by 2002:a17:902:f68b:b0:163:f358:d4ad with SMTP id l11-20020a170902f68b00b00163f358d4admr24483005plg.23.1655738679589; Mon, 20 Jun 2022 08:24:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655738679; cv=none; d=google.com; s=arc-20160816; b=l7VwsggAqouxd1Be1r7nwBgdvZbZ7JVzwfRtAGEmFUDjjRniaZPqqZ/h9ZMtUSty8u yGD+ETJ/cI67KWgXLAez5KAdYlksBk3y05kr8UldLk4ei+AjfyUKSyW7pPSTaTtWoRKF YbxRRCvVC7rEbr+/H3u+xp85ygOpDqHPFXIG4yGus3+X/btmCBMPeqlOTXN1DGEQmDv1 n2y4eHDyZwLxx37VAKrZYxEn80irQCbjMmZFzCtDQjBOJ4zyW3oJke86L6itMOY5bWng FU4q0e960LhS47Z/VgfOHBVA+LHDZ+4cf4jVexOz8zyfaZ8Um6G59ffo3cKkjUa7d12V /XMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id; bh=RuOXVo8ph7W2IPyldQiyCrjHhvtu59kSdxavIEN64eI=; b=x6aAAlsFmO0gbswYurwmAJD21fdkCNvaMDnWjrY3v/WDdeLVhbhNRU9kFn98Abv/cL gKFNRBPRk0T4Fknt901rj71mjIA2a8ZeNPW7xU/H/AaYgF9+ip6gkndMffzl5VkBHnm3 RhBGXzSa3AJL5HphmOPZdciYSG/efBCcG91WaporvuZzuUvHLGEiqy5k5ab0PG+QAaHr 1GYGvSgr7AeYL2XKTBxCE7fsQqjEjr+iUqqlZtwgW1RfVFEiyyBJEXwE5ZmsXbX5G8iQ G+biwb26Idk82tSIaTciFihTkCTlgkIXY5KojO5INL0xZp/bkArkLgTdXqZTzqyli7mC yq1A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l73-20020a63914c000000b0040b8f790450si4035901pge.172.2022.06.20.08.24.27; Mon, 20 Jun 2022 08:24:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241394AbiFTO4M (ORCPT + 99 others); Mon, 20 Jun 2022 10:56:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53416 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241391AbiFTOzx (ORCPT ); Mon, 20 Jun 2022 10:55:53 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BF32924958 for ; Mon, 20 Jun 2022 07:14:24 -0700 (PDT) Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.54]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4LRWnv2SCKzkWbJ; Mon, 20 Jun 2022 22:13:07 +0800 (CST) Received: from kwepemm600017.china.huawei.com (7.193.23.234) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 20 Jun 2022 22:13:44 +0800 Received: from [10.174.179.234] (10.174.179.234) by kwepemm600017.china.huawei.com (7.193.23.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 20 Jun 2022 22:13:42 +0800 Message-ID: <908f4c14-b9cb-71f8-7a3c-7569f7c89033@huawei.com> Date: Mon, 20 Jun 2022 22:13:41 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH -next v5 2/8] arm64: extable: make uaaccess helper use extable type EX_TYPE_UACCESS_ERR_ZERO To: Mark Rutland 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 , , "H . Peter Anvin" , , , , , Kefeng Wang , Xie XiuQi , Guohanjun 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> From: Tong Tiangen In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.234] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemm600017.china.huawei.com (7.193.23.234) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2022/6/20 17:10, Mark Rutland 写道: > 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. > . Now I can compile success, both versions 9.4.0 and 11.2.0. I should have made a mistake. There is no problem using your implementation. I will send a new version these days. Thans, Tong.