Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5049991pxj; Wed, 26 May 2021 01:20:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwpuduk+qhn17IZ25YeAcRytwbJMjAPfrhZBUkuF2qi5UHaSL+ZLn16VTTPu9jTYpJtC46k X-Received: by 2002:a50:eb08:: with SMTP id y8mr36391365edp.89.1622017230464; Wed, 26 May 2021 01:20:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622017230; cv=none; d=google.com; s=arc-20160816; b=PpYBRhZRCejzluc/zW5SJAEIrrU9b/oUpqWHkxHMHoIJy0dp5kGAfY7+GuWESr9AOH hWRBbzeLkEkv9Y2SDnra+an9UvSp/RJoW4ylCpAmqInFohpiUorv2iBlnZPvxOoLa0rb zT8GQckJWM16e9xSBtJHbZImWDFMhiSICMRinMWgxxHcTFHFkrQl9/I0j16oA9a1qMPc 71jAtalcmXFlyBm8+KHjf5dZVAPsr4GNo5Qc2YMyRuzr0cWNvbdTu222KhwJrOB+++ww +cRtNemD23VXOqdB/5vplZHo1EGXd+dauVgJeBCOujyFhjUiQqAl939oYc1jc41CVcr4 w0YA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:dkim-signature; bh=eE2fP+TWlAmJ/gnP75aIg5o6IkLWt2hvDOXfzvWSdZk=; b=l921Y72lIZZ0l+Wspz/U4pRcy5xMrqoQbj2l5NCBoP9Y2eWqUV6v+v6tedXWlF6XL8 +Jo6WIsTTk3ZL759IG8kimG2jm1xMiA39rRRs5lZkBRIlnB3/4/slHGgejy9nN+7HU54 XsgmvlmmiOlxjdhZZdJRJjocgq6MmVRIUnTdKyytk7HHVb5dXdweBCzHgzXk0lxELoMw h4fg/IwG2ykmvWNDMj7uG46NmVNo6MSh3pr5UxKxdbSS7XoozTB9o9N8lEVV/t1EkSXB IU5jczZ8X9FtzmVM9USS5LOEA9vhgxU2aJQnlMW/Yfx/kpVJeOT7UBL38yPaIcBqP72w fuvA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BfIHRC0o; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t11si11813998ejs.673.2021.05.26.01.20.05; Wed, 26 May 2021 01:20: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=@redhat.com header.s=mimecast20190719 header.b=BfIHRC0o; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232166AbhEZISa (ORCPT + 99 others); Wed, 26 May 2021 04:18:30 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:44326 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231960AbhEZIS3 (ORCPT ); Wed, 26 May 2021 04:18:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622017017; h=from:from: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=eE2fP+TWlAmJ/gnP75aIg5o6IkLWt2hvDOXfzvWSdZk=; b=BfIHRC0oi+PwWOBcWm8hX2lopehAS2XrAFC4ugpz8FO4WBSXqecUQBOvxv7m0YeAO0F87A 1wSXnwA9nXdBn/2aL75kipdmVqe24wG1SMiIU0KjYZXHaQRBuKKhcDuBwVws02NbR7nbYQ MZ4hDBH0C0x9qem5vj6Nc4W3tDHG3rM= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-9-5Mjz5R0gOTWIs6lH2Rs9IQ-1; Wed, 26 May 2021 04:16:56 -0400 X-MC-Unique: 5Mjz5R0gOTWIs6lH2Rs9IQ-1 Received: by mail-wm1-f69.google.com with SMTP id j6-20020a1c3c060000b029017f262ba319so117157wma.3 for ; Wed, 26 May 2021 01:16:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=eE2fP+TWlAmJ/gnP75aIg5o6IkLWt2hvDOXfzvWSdZk=; b=ryhVU9YVw91ITb63lVIfLHtI0spRCN6w+hBivy3lG2j0OQVaDzPY22UMLprKAe/fQt YI1StCnX0iE5a7s4Zp8bqB8NexyUtcFA98fcXCIrwR9t7Bz4CVD3OVZAAu8/iLo3HHwq uejt0LYUncDOM720XJ8jM/wCebrz1lxT7oPsyKz8z53XfFuYwjxtLfhHPoj56FrgWgYI QNCz9wwMK7LnMv+LUVTyQkiAt2O7NrZk9UQRHW/GDkVr+LsLhqIrUf/BxGFiejw0ItxT li4D9B8J410GQcHzz4dPcgufcUhQvEkBZaH8P2E03hcPxMWJ0a9jX+XHSpopssGHdfIY 0ICA== X-Gm-Message-State: AOAM5324E9mOx5TJ3ilnu1Uu6XAp+qJLTdJf8VZ2YDDHUXek1cw24FVI N6T/qs1FQ5nsI9HG7cFWGC6NO9/Mn1AMXX8az41Vibn9v4HFAwVb81rf8J2IKybpISf9jl/jOWk rC4XOjoWZIQgeU1w3Ha8y1lNd X-Received: by 2002:a1c:65c2:: with SMTP id z185mr2258142wmb.2.1622017014969; Wed, 26 May 2021 01:16:54 -0700 (PDT) X-Received: by 2002:a1c:65c2:: with SMTP id z185mr2258108wmb.2.1622017014711; Wed, 26 May 2021 01:16:54 -0700 (PDT) Received: from ?IPv6:2003:d8:2f38:2400:62f4:c5fa:ba13:ac32? (p200300d82f38240062f4c5faba13ac32.dip0.t-ipconnect.de. [2003:d8:2f38:2400:62f4:c5fa:ba13:ac32]) by smtp.gmail.com with ESMTPSA id 60sm1695777wrq.14.2021.05.26.01.16.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 May 2021 01:16:54 -0700 (PDT) Subject: Re: [PATCH] mm/page_alloc: Work around a pahole limitation with zero-sized struct pagesets To: Mel Gorman , Andrew Morton Cc: Andrii Nakryiko , Michal Suchanek , 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 References: <20210526080741.GW30378@techsingularity.net> From: David Hildenbrand Organization: Red Hat Message-ID: <1e0f727a-f9c4-4fc1-b4d2-c075df7a4600@redhat.com> Date: Wed, 26 May 2021 10:16:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <20210526080741.GW30378@techsingularity.net> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26.05.21 10:07, 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") > + > 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), > Looks sane to me. -- Thanks, David / dhildenb