Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5059064pxj; Wed, 26 May 2021 01:37:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzgfJZLr7IdBus14beRGCzQmJyeNhVrhtacmW4KN/glz0c3m9AeEChqhE/8b/thyMooGF4M X-Received: by 2002:a17:906:b14f:: with SMTP id bt15mr33849812ejb.126.1622018250729; Wed, 26 May 2021 01:37:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622018250; cv=none; d=google.com; s=arc-20160816; b=LXb0WRwMpiQxgyrfudn8RRVIMKZe+FnckHvIQaEQ+wVDR9MDH9aeJGpxLRoRPdsoPM rq3t2oCKYx8Yf5JfZJyiDxn+e+Fu6rNk0w1iYpI3e6eij9xdg1h22eIkTUzEvZEsdKEV Gwt4/J4a8yGzffbBOJAlwi0fpI1HAT2EplYJB75irFJ/O0bZGMJjsWWPSJDgTa0/jabV H6N6egV3s5lmVT0HSBasvPKFqWil2XgSXwBUzuaTF1IiWZst4vSkTNSq0vCUvaWRPQuI +hEdCVteVqEF2OTIGIlMsIF26xTE1UBw6/OTLdpp1yTvq3FiFai0Caf1WpCZ08G/hhLO oQWw== 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 :dkim-signature:dkim-signature; bh=quXrDQlOSLz6Yv/UVqeWT5TzgHoxc/pLtloJUqFjj3I=; b=pFKjEZb/qQgFr6F+yDpCtsjZTh0IUFN/iB1zHDDF+0FWd24tBBPlNzOcqTutHOxvkA 5szMCniz+eWZDfXai/vpdRwHugGQdApF7hJWJc1LZLUnV6OJQq4YxTCOUwWreXmxcWID Nsns9GtpcBITfCKqkCHFd7HLyYJ10mFhS2XnqdfFYM4SzEp0zX/8KuIbRNskURgWbSNY HmhtCEXDidnPXITg4+Wi07R5mCm0TMXfrnCRJ8l4cquTb9wKSp7tuFmvlIng5UJ7Xzn4 wOVuTGRl+Xzjq4kUOe+l919KQcMV/RjYSLZPCaevEg+2nKywe38dK7UgBWt0sPL/wKMB V91w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=HRapTYjc; dkim=neutral (no key) header.i=@suse.de header.b=H6lfZmDy; 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 p4si8696927ejr.271.2021.05.26.01.37.05; Wed, 26 May 2021 01:37:30 -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; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=HRapTYjc; dkim=neutral (no key) header.i=@suse.de header.b=H6lfZmDy; 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 S233093AbhEZIfR (ORCPT + 99 others); Wed, 26 May 2021 04:35:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:59006 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232166AbhEZIfQ (ORCPT ); Wed, 26 May 2021 04:35:16 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1622018024; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=quXrDQlOSLz6Yv/UVqeWT5TzgHoxc/pLtloJUqFjj3I=; b=HRapTYjcWBejGMvNlWoR8Q9VWFnJiZAO8ATuXSK9dSBolvIgNgaAV2Br6sLsmf4YtOtLwR rv7G9Xx9XIil3L5B/Zh2LDhEAvQCoCsnq4yUxDR+5qvAZat1gjl8B+fQbCM5udhKgqwvL4 bqG1dEQopOJ/gMk0Eh/tFoR4wNH8KHo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1622018024; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=quXrDQlOSLz6Yv/UVqeWT5TzgHoxc/pLtloJUqFjj3I=; b=H6lfZmDynh9DNqZuySsYPsmWZqrrfbe3I8S14jAkeoUQ63Dgyn7moVjFhULePItqddlGDy WHDd6+aN9Tce6IAA== Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id ED2B5B124; Wed, 26 May 2021 08:33:43 +0000 (UTC) Date: Wed, 26 May 2021 10:33:42 +0200 From: Michal =?iso-8859-1?Q?Such=E1nek?= To: Mel Gorman , linux-kbuild@vger.kernel.org Cc: Andrew Morton , Andrii Nakryiko , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , open list , Arnaldo Carvalho de Melo , Jiri Olsa , Hritik Vijay , bpf , Linux-Net , Linux-MM , Masahiro Yamada Subject: Re: (BTF) [PATCH] mm/page_alloc: Work around a pahole limitation with zero-sized struct pagesets Message-ID: <20210526083342.GY8544@kitsune.suse.cz> References: <20210526080741.GW30378@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210526080741.GW30378@techsingularity.net> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 26, 2021 at 09:07:41AM +0100, Mel Gorman wrote: > Michal Suchanek reported the following problem with linux-next > > [ 0.000000] Linux version 5.13.0-rc2-next-20210519-1.g3455ff8-vanilla (geeko@buildhost) (gcc (SUSE Linux) 10.3.0, GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.36.1.20210326-3) #1 SMP Wed May 19 10:05:10 UTC 2021 (3455ff8) > [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.13.0-rc2-next-20210519-1.g3455ff8-vanilla root=UUID=ec42c33e-a2c2-4c61-afcc-93e9527 8f687 plymouth.enable=0 resume=/dev/disk/by-uuid/f1fe4560-a801-4faf-a638-834c407027c7 mitigations=auto earlyprintk initcall_debug nomodeset earlycon ignore_loglevel console=ttyS0,115200 > ... > [ 26.093364] calling tracing_set_default_clock+0x0/0x62 @ 1 > [ 26.098937] initcall tracing_set_default_clock+0x0/0x62 returned 0 after 0 usecs > [ 26.106330] calling acpi_gpio_handle_deferred_request_irqs+0x0/0x7c @ 1 > [ 26.113033] initcall acpi_gpio_handle_deferred_request_irqs+0x0/0x7c returned 0 after 3 usecs > [ 26.121559] calling clk_disable_unused+0x0/0x102 @ 1 > [ 26.126620] initcall clk_disable_unused+0x0/0x102 returned 0 after 0 usecs > [ 26.133491] calling regulator_init_complete+0x0/0x25 @ 1 > [ 26.138890] initcall regulator_init_complete+0x0/0x25 returned 0 after 0 usecs > [ 26.147816] Freeing unused decrypted memory: 2036K > [ 26.153682] Freeing unused kernel image (initmem) memory: 2308K > [ 26.165776] Write protecting the kernel read-only data: 26624k > [ 26.173067] Freeing unused kernel image (text/rodata gap) memory: 2036K > [ 26.180416] Freeing unused kernel image (rodata/data gap) memory: 1184K > [ 26.187031] Run /init as init process > [ 26.190693] with arguments: > [ 26.193661] /init > [ 26.195933] with environment: > [ 26.199079] HOME=/ > [ 26.201444] TERM=linux > [ 26.204152] BOOT_IMAGE=/boot/vmlinuz-5.13.0-rc2-next-20210519-1.g3455ff8-vanilla > [ 26.254154] BPF: type_id=35503 offset=178440 size=4 > [ 26.259125] BPF: > [ 26.261054] BPF:Invalid offset > [ 26.264119] BPF: > [ 26.264119] > [ 26.267437] failed to validate module [efivarfs] BTF: -22 > > Andrii Nakryiko bisected the problem to the commit "mm/page_alloc: convert > per-cpu list protection to local_lock" currently staged in mmotm. In his > own words > > 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 > > The patch in question introduces a zero-sized per-cpu struct and while > this is not wrong, versions of pahole prior to 1.22 (unreleased) get > confused during BTF generation with two separate variables occupying the > same address. > > This patch checks for older versions of pahole and forces struct pagesets > to be non-zero sized as a workaround when CONFIG_DEBUG_INFO_BTF is set. A > warning is omitted so that distributions can update pahole when 1.22 > is released. > > Reported-by: Michal Suchanek > Reported-by: Hritik Vijay > Debugged-by: Andrii Nakryiko > Signed-off-by: Mel Gorman > --- > lib/Kconfig.debug | 3 +++ > mm/page_alloc.c | 11 +++++++++++ > 2 files changed, 14 insertions(+) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index 678c13967580..f88a155b80a9 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -313,6 +313,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") > + This does not seem workable with dummy-tools. Do we even have dummy pahole? Thanks Michal > 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 ff8f706839ea..1d56d3de8e08 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),