From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 892D2C4708F for ; Sun, 30 May 2021 03:10:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0D0B461104 for ; Sun, 30 May 2021 03:10:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0D0B461104 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 364B96B006C; Sat, 29 May 2021 23:10:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C59A6B006E; Sat, 29 May 2021 23:10:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 117C56B0070; Sat, 29 May 2021 23:10:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0146.hostedemail.com [216.40.44.146]) by kanga.kvack.org (Postfix) with ESMTP id B78376B006C for ; Sat, 29 May 2021 23:10:48 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 4A455181AEF32 for ; Sun, 30 May 2021 03:10:48 +0000 (UTC) X-FDA: 78196420176.14.61EA204 Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf06.hostedemail.com (Postfix) with ESMTP id 08D32C00CBD7 for ; Sun, 30 May 2021 03:10:37 +0000 (UTC) Received: by mail-yb1-f181.google.com with SMTP id n133so2799542ybf.6 for ; Sat, 29 May 2021 20:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FcKoFZ0P38MLC340jJCPwKlfNKBvKK6zzlbSELrWy48=; b=Tlf2hLmn/ijTjgjwMRyay3uRY5vr1QwsrIeFBVjrDVRcIXHt4FojGz2BCfsCKWAnuO +Vee/xlQf7nALXbvV8gW/0KLzSRSYvJp+h6F+QhQ/JaaEQk5zPc8r81Tcz+2nhiQLl21 zP3rBnX+icd8x+cFVHtdJccv1A8BXq5InvJfxYPGmAbTL5epQAvEfBcqZhIUIQpgSVSA Su4JttvANueSnMZZjFomcyi2SGkpbtJRZepcG/XdWonHLkcs45J/gvtZu1MzGr6Jlwf3 pSq2sWnUOwnry2uxXrhG7vBZM027BdbheW+uDoS5WWVx2q4Nm4RY6VT2j/A7lTpcyEa5 GAzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FcKoFZ0P38MLC340jJCPwKlfNKBvKK6zzlbSELrWy48=; b=fUfjJLBqUqw16YSGXllw1cQFynnZx0/n/mXPUSIMEgCaiVR09GDGBkjjLSgSpwPk/Z JcbwgZ2SRAE+aFFgyk9+AmF6/ieuQVEN3/dZ2cfxfabmmxHUmuLspl8v4NRPt2PhF2S2 Ccs7ppGjgd6SEDWrfvHSNS6TKJjiWcPc2J1lXWhUn0dHgztZZYYTY6DrYSZZpCr/tvRK t9QciB/IXtcI87K7MqGeNm6DBvl4l5NqZ7y9sdiKcoWeDwVx6t/P8bmqsPbYqbsEz3gG 7qU+t35kgXf6qaC7UUDWuKzXlKA0lD+z5IteJSVIMBKAea5oQeB265I1x7eqgnbXUags j32w== X-Gm-Message-State: AOAM532W2+iL3i/G54abWNc84RWpxNQEc+klWDE2noAtfV4Y315puQ88 Di0mmJQVp0Ik3fppvc1gChdxbWRvlngRlm90rjM= X-Google-Smtp-Source: ABdhPJxurv9vJ+f7Y6dgU2PL7HfRo6NQNymmA7TdAAmPf0Gbu5SH4MZOBeyUH96IwVmWirO8dVVokzMrXYqoJxdxXpk= X-Received: by 2002:a5b:f05:: with SMTP id x5mr22521804ybr.425.1622344247180; Sat, 29 May 2021 20:10:47 -0700 (PDT) MIME-Version: 1.0 References: <20210527171923.GG30378@techsingularity.net> <20210528074248.GI30378@techsingularity.net> In-Reply-To: <20210528074248.GI30378@techsingularity.net> From: Andrii Nakryiko Date: Sat, 29 May 2021 20:10:36 -0700 Message-ID: Subject: Re: [PATCH v3] mm/page_alloc: Require pahole v1.22 to cope with zero-sized struct pagesets To: Mel Gorman Cc: Andrew Morton , Christoph Hellwig , Arnaldo Carvalho de Melo , Michal Suchanek , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , LKML , Jiri Olsa , Hritik Vijay , Linux-BPF , Linux-Net , Linux-MM , clm@fb.com Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=Tlf2hLmn; spf=pass (imf06.hostedemail.com: domain of andriinakryiko@gmail.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=andriinakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 08D32C00CBD7 X-Stat-Signature: kz8w975oo7b76rwtmgo9h1jgm3bkt681 X-HE-Tag: 1622344237-38344 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, May 28, 2021 at 12:42 AM Mel Gorman wrote: > > On Thu, May 27, 2021 at 03:17:48PM -0700, Andrii Nakryiko wrote: > > > 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 get confused during > > > BTF generation with two separate variables occupying the same address. > > > > > > This patch adds a requirement for pahole 1.22 before setting > > > DEBUG_INFO_BTF. While pahole 1.22 does not exist yet, a fix is in the > > > pahole git tree as ("btf_encoder: fix and complete filtering out zero-sized > > > per-CPU variables"). > > > > > > Reported-by: Michal Suchanek > > > Reported-by: Hritik Vijay > > > Debugged-by: Andrii Nakryiko > > > Signed-off-by: Mel Gorman > > > --- > > > > I still think that v1 ([0]) is a more appropriate temporary solution > > until pahole 1.22 is released and widely packaged. Suddenly raising > > the minimum version to 1.22, which is not even released even, is a > > pretty big compatibility concern for all the users that rely on > > CONFIG_DEBUG_INFO_BTF. > > On the flip side, we have a situation where a build tool (pahole) has a > problem whereby correct code does not result in a working kernel. It's > not that dissimilar to preventing the kernel being built on an old > compiler. While I accept it's unfortunate, Christoph had a point where > introducing workarounds in the kernel could lead to a prolification of > workarounds for pahole or other reasons that are potentially tricky to > revert as long as distributions exist that do not ship with a sufficiently > reason package. > > > Just a few days ago pahole 1.16 worked fine and > > here we suddenly (and silently due to how Kconfig functions) raise > > that to a version that doesn't exist. That's going to break workflows > > for a lot of people. > > > > People do have a workaround though. For the system building the kernel, > they can patch pahole and revert the check so a bootable kernel can be > built. It's not convenient but it is manageable and pahole has until > 5.13 releases to release a v1.22. The downsides for the alternative -- > a non-booting kernel are much more severe. > > > I'm asking to have that ugly work-around to ensure sizeof(struct > > pagesets) > 0 as a temporary solution only. > > Another temporary solution is to locally build pahole and either revert > the check or fake the 1.22 release number with the self-built pahole. > Well, luckily it seems we anticipated issues like that and added --skip_encoding_btf_vars argument, which I completely forgot about and just accidentally came across reviewing Arnaldo's latest pahole patch. I think that one is a much better solution, as then it will impact only those that explicitly relies on availability of BTF for per-CPU variables, which is a subset of all possible uses for kernel BTF. Sent a patch ([0]), please take a look. [0] https://lore.kernel.org/linux-mm/20210530002536.3193829-1-andrii@kernel.org/T/#u > -- > Mel Gorman > SUSE Labs