Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp994403pxj; Thu, 27 May 2021 17:17:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzFu21SUBg2AvPITfs/TH6N88KDJzGiQMe2z3aKVLtczgP71VgvK6+NedutQns3INl5TpDf X-Received: by 2002:a05:6402:1d2c:: with SMTP id dh12mr7106882edb.237.1622161051447; Thu, 27 May 2021 17:17:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622161051; cv=none; d=google.com; s=arc-20160816; b=QQyYB22VawtE9u/Rd+Np4QaHx5TI1KZCDfzLGa8CuCTl6Cm9qlOaT201++CZg7u9jy m8NT7vKEbUjl+LAiS/fJdwS51LRhPa7ugU/N7ZPlQGgCGz9cI4fNw34GB43Q4RZbhnzt Rk5RhJ6dCeTIahrkjgAj/2cBHzEddrPk7tba3MEJIcQdDm+Dx5BwTYanQ8JNeK8HwqaD ep2EZ+YRWciDV+o+idkKlaLD156CZ4Eeh+mB+xxE0mFYVo5T8KH4FoLQTPWxPN8Bq3cU W0i/E45aTPBeQYkeNSZWZdvF3APgJvw4ippMxJyzFqBrMxxmOhewfa3qGmqZGQu72Z+A wJKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=7uOtvAQxo11BZ9qV4iscB9IwPVfNGrEjy6zxUfl9fAQ=; b=AD+fXvgN2RsAO5VdIiJQwCuiNEKm9oA62qLAq/ER6ebXBpkRi4sVW5Xg8Uih+Iw4aN eIkr3M0vkhXQxjnz0iNJi7glcfLIls8KmrE0CqN1bkAUgBzqH8geQM/ZE08hBEHyjYQR WfbCiOun10tFpsypj3vrt3AVWc4/rNSuVnhxMRulxYEmYksfKpJHBOcqGm9DWCneE/9t v3bETMthJicpDLAjQsC43xoyUzqbFI0vYXny1Ez/+N22PI/Sy/3miLs1/M4RdtY/lXF+ Umbn+GveOqvaw2BtnMgQyeqMNBk7PNHdmR1WB/iMUmGHDq8eoLG9vUImBy7PSvvrTae8 HeYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=M7JkcsTV; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w10si4240321ejv.754.2021.05.27.17.17.05; Thu, 27 May 2021 17:17:31 -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=@gmail.com header.s=20161025 header.b=M7JkcsTV; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236382AbhE0W06 (ORCPT + 99 others); Thu, 27 May 2021 18:26:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234318AbhE0W05 (ORCPT ); Thu, 27 May 2021 18:26:57 -0400 Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF9B7C061574; Thu, 27 May 2021 15:25:22 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id w1so2887224ybt.1; Thu, 27 May 2021 15:25:22 -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=7uOtvAQxo11BZ9qV4iscB9IwPVfNGrEjy6zxUfl9fAQ=; b=M7JkcsTVF7/siykqcbEhtevruKBCIx0gc9z1xs99OMOplvieDhCOZuwzx0RpQZTYIq UdXGrfOLSslfU37BlHTfJeyq8vgNte94vccbZMEenubMID/jVp3kpFORE+K0rG7pqLXM j15VIecE4NbOv5xDy39wDbM9a5uoqMa0KMwx2ZOA1n5C5KWBp62jWBGnuj5u3HxnHVvm ROrskkYmFIU+kZ4W1a5fSzSitr4+5XDhq/mJAS8WZUsUIAil9OBjAiAbBnKAZX9+8Hlc PrvJAjfCJQ8gG5LHi5V84ME3YToHskuuGR+6JI2aDxQuiFT3qjO40XsCfQUDBhZFUJru wqjA== 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=7uOtvAQxo11BZ9qV4iscB9IwPVfNGrEjy6zxUfl9fAQ=; b=sjahlqWxEiQuoMNE+1N84vYQHSIsVy4ofpUbjXSrag13Yw6Gazb6nZhytPPovl20iF YPZ1tahNdNmxpYwc9iUQOO/nFgup5ZdmavHhcZ8QRcUPNlXRQz8rKu1zFC133MoY4WnY IO86fSLegA9fuHxVFgGxkW2fIueRI7Q9r7PKtM4jfg8CG5kof8lUW21rb1575RyWfhEZ X6AEYKS/vSYDrf86s/o357h3vNaCmj1NdQ4XyMmV2c6er4KTJ5IiLyRq0+4DWcl1wo1z XkW6oLbVB54/fxpT2xxmLGkIYcjX8h3GHqQbfhmOfzGM3WOTjZyVvbvLZC94/qnIPQZn QisA== X-Gm-Message-State: AOAM5320ZhuK7hljPEUJM7AgNGcB1qH6PTUxGjX+T6iA+DpQCa91U/ss M+eogZTNaLRA3xVj44jJBL+lXvIq8u+WPgEBSyw= X-Received: by 2002:a25:3357:: with SMTP id z84mr7803181ybz.260.1622154322177; Thu, 27 May 2021 15:25:22 -0700 (PDT) MIME-Version: 1.0 References: <20210527120251.GC30378@techsingularity.net> <20210527145441.GE30378@techsingularity.net> <20210527172700.GH30378@techsingularity.net> In-Reply-To: <20210527172700.GH30378@techsingularity.net> From: Andrii Nakryiko Date: Thu, 27 May 2021 15:25:10 -0700 Message-ID: Subject: Re: [PATCH v2] mm/page_alloc: Work around a pahole limitation with zero-sized struct pagesets To: Mel Gorman , Masahiro Yamada 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 27, 2021 at 10:27 AM Mel Gorman wrote: > > On Thu, May 27, 2021 at 09:36:35AM -0700, Andrii Nakryiko wrote: > > On Thu, May 27, 2021 at 7:54 AM Mel Gorman wrote: > > > > > > On Thu, May 27, 2021 at 07:37:05AM -0700, Andrii Nakryiko wrote: > > > > > This patch checks for older versions of pahole and only allows > > > > > DEBUG_INFO_BTF_MODULES if pahole supports zero-sized per-cpu structures. > > > > > DEBUG_INFO_BTF is still allowed as a KVM boot test passed with pahole > > > > > > > > Unfortunately this won't work. The problem is that vmlinux BTF is > > > > corrupted, which results in module BTFs to be rejected as well, as > > > > they depend on it. > > > > > > > > But vmlinux BTF corruption makes BPF subsystem completely unusable. So > > > > even though kernel boots, nothing BPF-related works. So we'd need to > > > > add dependency for DEBUG_INFO_BTF on pahole 1.22+. > > > > > > > > > > While bpf usage would be broken, the kernel will boot and the effect > > > should be transparent to any kernel build based on "make oldconfig". > > > > I think if DEBUG_INFO_BTF=y has no chance of generating valid vmlinux > > BTF it has to be forced out. So if we are doing this at all, we should > > do it for CONFIG_DEBUG_INFO_BTF, not CONFIG_DEBUG_INFO_BTF_MODULES. > > CONFIG_DEBUG_INFO_BTF_MODULES will follow automatically. > > > > Ok, I sent a version that prevents DEBUG_INFO_BTF being set unless > pahole is at least 1.22. > > > > CONFIG_DEBUG_INFO_BTF defaults N so if that is forced out, it will be > > > easily missed by a distribution kernel maintainer. > > > > We actually had previous discussions on forcing build failure in cases > > when CONFIG_DEBUG_INFO_BTF=y can't be satisfied, but no one followed > > up. > > It is weird how it is handled. DEBUG_INFO_BTF can be set and then fail to > build vmlinux because pahole is too old. With DEBUG_INFO_BTF now requiring > at least 1.22, the other version checks for 1.16 and 1.19 are redundant > and could be cleaned up. > > > I'll look into this and will try to change the behavior. It's > > caused too much confusion previously and now with changes like this we > > are going to waste even more people's time. > > > > Thanks. So I've tried to change that, but I'm not sure that's possible with the current Kconfig system. I tried to use $(error-if), but it happens too early, at the text pre-processing stage, before the value of CONFIG_DEBUG_INFO_BTF is known, so it's impossible to express something like this: $(error_if,CONFIG_DEBUG_INFO_BTF=y && PAHOLE_VERSION < 116,Pahole is tool old) Masahiro, is it possible to somehow express the condition that if CONFIG_DEBUG_INFO_BTF=y is selected, but some external dependency (pahole version in this case) is too old, then fail the build immediately? Currently we fail at the very end of vmlinux linking step, which is very late. Alternatively, it was proposed to just add an extra dependency (like, "depends PAHOLE_IS_116_OR_NEWER"), but that will silently unselect CONFIG_DEBUG_INFO_BTF if the condition is not satisfied, so it's even more confusing to users. Any suggestions on how to proceed with something like that? Thanks! > > -- > Mel Gorman > SUSE Labs