Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp4808518rdb; Fri, 15 Sep 2023 12:58:35 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFPsB2sNr+w46l5VaagMVG9AmBkx/9Tpt5Eg6F6OsKOgnQM2l7KoOQa5VCBvUTANO6Fnqts X-Received: by 2002:a17:902:ec8b:b0:1bb:ac37:384b with SMTP id x11-20020a170902ec8b00b001bbac37384bmr2689951plg.6.1694807914922; Fri, 15 Sep 2023 12:58:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694807914; cv=none; d=google.com; s=arc-20160816; b=L2v2JBOszPfYxRO553exz9DsaQUo2NhF8i7LTlaKgQioJ6gxIfTDbVv5RM5wzR8MXN 7u7XzxDz0FpGvf62zaNDsoiNryph5MsbwMD8ikprnjpTbgpdl9UqMhRGXubWBVHBePVF dpZnBIUHUTtxBBw2RO2bzF5EGYdfzfnIlO2d7PsczTsKSO72Pxco9H4oUUW3u2FOcMBu hqXsOuDczqnfpjMfaB/C7MgBWD/DPKp1JhSgu4J0cdZ2duylCBoZeZ9gUPnQL3zFrgnP nK5XaZXaSWSL+/rPEv4MiPnjW7Ucv6fGD+j9b3FTxe19OKB/FjEoMLaJhlgTmBvO3FlB K4yA== 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:content-language:subject:user-agent:mime-version :date:message-id:sender:dkim-signature; bh=u/pB+M0aDtpWHsMhpYrzo00VPhkLWHr0lTc8MpzDk2M=; fh=aYBQJJkwjdoU5uQWzXoAKZGjq0xrZnzeu37kd0kGSkc=; b=AFmGzKHazdHw5c3LDUNxYu16hsqz00vXjCMTIK/8MIi7Q2RRsBpLe34uj9Ag0zc34s JnRosFOgqt9X+iF432Rbc0g/n1jvXHP19Ahq8Blanw/4bInRUIkglY6+BhfUOSVn4O4u rSw530fxonluxIt8tY8hzZpDUliBSzYTF9T2sGPPc0CfOr5DHqT1gGhq+m4JAKquW0Uw pnVZJKF1Ld4Z1sTGGtO7x+HGLIm0F5DcYHAW2p8/cWP+FloW7RBrjAL6WPI6biv43lZE nq7tzKyuJLDYOf/lL+19DiF2of8c28ku7jpZqG+7vZmtIBpo0EUruFfNwB5jQY6d2d5j SI5Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=lMh6QVSc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id l1-20020a170902f68100b001b69de1eae1si3952711plg.620.2023.09.15.12.58.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Sep 2023 12:58:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=lMh6QVSc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id E37548371D27; Fri, 15 Sep 2023 07:07:56 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235539AbjIOOH5 (ORCPT + 99 others); Fri, 15 Sep 2023 10:07:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43232 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235472AbjIOOH5 (ORCPT ); Fri, 15 Sep 2023 10:07:57 -0400 Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA9FF1FC9 for ; Fri, 15 Sep 2023 07:07:51 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id e9e14a558f8ab-34fcd1b9892so70195ab.3 for ; Fri, 15 Sep 2023 07:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694786871; x=1695391671; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=u/pB+M0aDtpWHsMhpYrzo00VPhkLWHr0lTc8MpzDk2M=; b=lMh6QVScN/CV6w1xwGwW8kJhqyWXUaKkrbjckyiJps/vRsR++DhjbYrNS1dQNv90wc 0pkLCcbB8LHv57/y98JYb9aF8na7pL31PBVTYBD/jMakMf6Ygoax8ekrflFAGegNOnav 2TgRFnNgq+7xg7WL61EBT7tl0fTMGBmCrPE6BuAWorSsZe5z1j1qNn7NLl8k5XGps1GS 4lBbYWrJTfD/zcKX54K9ztLpvHHy+yuH/bcCgAlSiA8s1pDvABZT0Ohv6+UPEgv1mopv tU4c5y2ClWWHaErgHWyjuYzS0cdM1KV+Cm57GjgpbP8hxQJ28Yb6GAJ2ttp5AviHw62F g/qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694786871; x=1695391671; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=u/pB+M0aDtpWHsMhpYrzo00VPhkLWHr0lTc8MpzDk2M=; b=VD7GJQesW7iynZ8lDYsHkxTkFPT+kyZiZLS5NuQvhBaFXdV36ei4AuQ3MuTyKAwxDY Y1wpZdw2UyjqmDJiFHz2VDFuhijGnqV1vdmX8w5CNi+eiS+2cVTbWhnxvPpWo7r2sGB1 SMTzyxWXaSF0fp/ByWfUIByvc9D730JLjuxxq+thqiFWH1rHmZ6Il5t3Oy9tXUw1KgF5 PxMN7porHDA9zXCVOmga5/90QNAQRsZkVSRmt8JDkl9IPh2LD+8P8xnLQpSxm+2NGT5o rjYRDG3C1ryICPcbDXQP34P6Cbp6IOcxEtMbDjqfPaAraWJT9EI4fYzt/foA8v1HtRx5 5teA== X-Gm-Message-State: AOJu0YyRSlo6He3qEBVftTLUTsEbHy+FVnNYAbALDmysB/ruFrWGY+80 8dCiQ6k+No6xWfD8/lqMknY= X-Received: by 2002:a05:6e02:c74:b0:34c:e6e6:80d5 with SMTP id f20-20020a056e020c7400b0034ce6e680d5mr1953714ilj.26.1694786870958; Fri, 15 Sep 2023 07:07:50 -0700 (PDT) Received: from ?IPV6:2600:1700:e321:62f0:329c:23ff:fee3:9d7c? ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id u15-20020a056e02080f00b00345d10ea524sm125643ilm.65.2023.09.15.07.07.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Sep 2023 07:07:50 -0700 (PDT) Sender: Guenter Roeck Message-ID: <644b77db-7214-88c3-7ba6-9c805a134e63@roeck-us.net> Date: Fri, 15 Sep 2023 07:07:48 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: [PATCH] LoongArch: Fix lockdep static memory detection Content-Language: en-US To: Helge Deller , Huacai Chen Cc: WANG Xuerui , loongarch@lists.linux.dev, Linus Torvalds , Geert Uytterhoeven , linux-kernel@vger.kernel.org References: <1160d063-8396-b126-15ca-a46807ec4258@gmx.de> From: Guenter Roeck In-Reply-To: <1160d063-8396-b126-15ca-a46807ec4258@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS 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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Fri, 15 Sep 2023 07:07:57 -0700 (PDT) Hi Helge, On 9/15/23 03:10, Helge Deller wrote: > On 9/15/23 11:23, Huacai Chen wrote: >> On Fri, Sep 15, 2023 at 4:16 PM Helge Deller wrote: >>> >>> On 9/15/23 05:22, Huacai Chen wrote: >>>> Hi Helge, >>>> >>>> On Wed, Sep 13, 2023 at 3:18 AM Helge Deller wrote: >>>>> >>>>> Since commit 0a6b58c5cd0d ("lockdep: fix static memory detection even >>>>> more") the lockdep code uses is_kernel_core_data(), is_kernel_rodata() >>>>> and init_section_contains() to verify if a lock is located inside a >>>>> kernel static data section. >>>>> >>>>> This change triggers a failure on LoongArch, for which the vmlinux.lds.S >>>>> script misses to put the locks (as part of in the .data.rel symbols) >>>>> into the Linux data section. >>>>> This patch fixes the lockdep problem by moving *(.data.rel*) symbols >>>>> into the kernel data section (from _sdata to _edata). >>>>> >>>>> Additionally, move other wrongly assigned symbols too: >>>>> - altinstructions into the _initdata section, >>> >>>> I think altinstructions cannot  be put into _initdata because it will >>>> be used by modules. >>> >>> No. >>> arch/loongarch/kernel/vmlinux.lds.S is used for the static parts of the kernel >>> and altinstructions are replaced before modules are loaded. >>> For altinstructions in modules the linker script scripts/module.lds.S is used. > >> OK, then what about .got/.plt? It seems arm64 also doesn't put them in >> the data section. > > arm64 seems to throw away all plt entries already at link time (and just keeps > the got.plt in the read-only data section). > It even checks at link time, that there are no plt entries in the binary: >         ASSERT(SIZEOF(.plt) == 0, "Unexpected run-time procedure linkages detected!") > > I don't know for loongarch, but if you need the plt entries for loongarch, it's > safest & best to put them into the read-only data section too, which is what my patch does. > Up to now, you have them completely outside of code & data sections. > > In the end you need to decide for your platform. My patch is a suggestion, which I think > is correct (untested by me, but Guenter replied he tested it). > But to fix the lockdep problem at minimum the move of the .data.rel section > is needed. > Just my $0.02 .. it might make sense to concentrate on the minimum to get the immediate problem fixed. Loongarch maintainers can then decide at their own pace if they want to apply any of the other changes you suggested. After all, unless I am missing something, those additional changes are not really needed in stable releases. Thanks, Guenter