Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4383753pxj; Tue, 25 May 2021 06:52:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwFr1z0Io4881yngC1Rtwav501cTu2KCr5SsO2XX7U3LcU1rHVIzVRHu0PqTDJoBfzFul1n X-Received: by 2002:a17:906:d7a8:: with SMTP id pk8mr29588336ejb.74.1621950765899; Tue, 25 May 2021 06:52:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621950765; cv=none; d=google.com; s=arc-20160816; b=HwLdugdRJyDAXReM7uJE33MmNfApsaW5kunlmm04HbWKeFVYLWHvMhLIp++C5h6bQQ hXqpI2tUGJ1ZCEtDY+TphDUg2yyykV/7j3H31ImatOUcxtplXhaNaZ9/QC/+IxeNe94i vi9ug9tVx1i+/3TqjXEM77Oggmbeubd0/IKewdtZF51YbcKl2bTlYMxakiFihIsLn3tO ctjLFgHMcpmOagLFueINmLD+PXMzdmY1r3c+k9nxuZDWzmLHn1/cMZnBZYWyqJHGQ1zV zPWEJPDGvZdMblQ7k3JDQA4mBjWz6cX2190UtmDiBtHZzePBodFPa8zZOj1Un8oSR+Am E/sQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=0/ivbFK07bnuJMy3q6u1Vzzhwh/DKyRWkox31JOT8Ho=; b=jPPx7TsrQYob+DiLYCE2adTVPqeE22lTs9u0328v3hWXJTD+mhgp1hf2L75zvVeHNZ vsAiNHqniQOItF0YYuNXZw0IbnAQBfQwD44uzHQGEN2RhSKUMJNr4dk9boENtikxxrYV RXcMOLH+hAOSlrdSDRv1KPKl1aEwVCVz5dt9aELFmlR+5uJIStAz11z7zgrld2IDkzpP tlAS2yHmJLvlIO92KgaX4Fc7U6WIUyymSd09HqaPInTNLwrKFkonr7LJNOS2wyL+b+F0 K4/cJmOkjlDMMZ8PoxzoCdsssl6AG/kYFbvKywQKcbTfYQqDVzd7CTuCaYYh0XKONyTE itTw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a22si16365425edv.404.2021.05.25.06.52.15; Tue, 25 May 2021 06:52:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233400AbhEYNwf (ORCPT + 99 others); Tue, 25 May 2021 09:52:35 -0400 Received: from outbound-smtp35.blacknight.com ([46.22.139.218]:56205 "EHLO outbound-smtp35.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233339AbhEYNwd (ORCPT ); Tue, 25 May 2021 09:52:33 -0400 Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp35.blacknight.com (Postfix) with ESMTPS id CBFF11B0E for ; Tue, 25 May 2021 14:51:02 +0100 (IST) Received: (qmail 3215 invoked from network); 25 May 2021 13:51:02 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.23.168]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 25 May 2021 13:51:02 -0000 Date: Tue, 25 May 2021 14:51:01 +0100 From: Mel Gorman To: Andrii Nakryiko Cc: Michal Such?nek , bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Networking , open list , Arnaldo Carvalho de Melo , Jiri Olsa , Hritik Vijay Subject: Re: BPF: failed module verification on linux-next Message-ID: <20210525135101.GT30378@techsingularity.net> References: <20210519141936.GV8544@kitsune.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 24, 2021 at 03:58:29PM -0700, Andrii Nakryiko wrote: > > It took me a while to reliably bisect this, but it clearly points to > > this commit: > > > > e481fac7d80b ("mm/page_alloc: convert per-cpu list protection to local_lock") > > > > One commit before it, 676535512684 ("mm/page_alloc: split per cpu page > > lists and zone stats -fix"), works just fine. > > > > I'll have to spend more time debugging what exactly is happening, but > > the immediate problem is two different definitions of numa_node > > per-cpu variable. They both are at the same offset within > > .data..percpu ELF section, they both have the same name, but one of > > them is marked as static and another as global. And one is int > > variable, while another is struct pagesets. I'll look some more > > tomorrow, but adding Jiri and Arnaldo for visibility. > > > > [110907] DATASEC '.data..percpu' size=178904 vlen=303 > > ... > > type_id=27753 offset=163976 size=4 (VAR 'numa_node') > > type_id=27754 offset=163976 size=4 (VAR 'numa_node') > > > > [27753] VAR 'numa_node' type_id=27556, linkage=static > > [27754] VAR 'numa_node' type_id=20, linkage=global > > > > [20] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED > > > > [27556] STRUCT 'pagesets' size=0 vlen=1 > > 'lock' type_id=507 bits_offset=0 > > > > [506] STRUCT '(anon)' size=0 vlen=0 > > [507] TYPEDEF 'local_lock_t' type_id=506 > > > > So also something weird about those zero-sized struct pagesets and > > local_lock_t inside it. > > Ok, so nothing weird about them. local_lock_t is designed to be > zero-sized unless CONFIG_DEBUG_LOCK_ALLOC is defined. > > But such zero-sized per-CPU variables are confusing pahole during BTF > generation, as now two different variables "occupy" the same address. > > Given this seems to be the first zero-sized per-CPU variable, I wonder > if it would be ok to make sure it's never zero-sized, while pahole > gets fixed and it's latest version gets widely packaged and > distributed. > > Mel, what do you think about something like below? Or maybe you can > advise some better solution? > Ouch, something like that may never go away. How about just this? diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 58426acf5983..dce2df33d823 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -338,6 +338,9 @@ config DEBUG_INFO_BTF config PAHOLE_HAS_SPLIT_BTF def_bool $(success, test `$(PAHOLE) --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/'` -ge "119") +config PAHOLE_HAS_ZEROSIZE_PERCPU_SUPPORT + def_bool $(success, test `$(PAHOLE) --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/'` -ge "122") + config DEBUG_INFO_BTF_MODULES def_bool y depends on DEBUG_INFO_BTF && MODULES && PAHOLE_HAS_SPLIT_BTF diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 1599985e0ee1..cb1f84848c99 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -124,6 +124,17 @@ static DEFINE_MUTEX(pcp_batch_high_lock); struct pagesets { local_lock_t lock; +#if defined(CONFIG_DEBUG_INFO_BTF) && \ + !defined(CONFIG_DEBUG_LOCK_ALLOC) && \ + !defined(CONFIG_PAHOLE_HAS_ZEROSIZE_PERCPU_SUPPORT) + /* + * pahole 1.21 and earlier gets confused by zero-sized per-CPU + * variables and produces invalid BTF. Ensure that + * sizeof(struct pagesets) != 0 for older versions of pahole. + */ + char __pahole_hack; + #warning "pahole too old to support zero-sized struct pagesets" +#endif }; static DEFINE_PER_CPU(struct pagesets, pagesets) = { .lock = INIT_LOCAL_LOCK(lock), diff --git a/scripts/rust-version.sh b/scripts/rust-version.sh old mode 100644 new mode 100755 -- Mel Gorman SUSE Labs