All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Michal Suchanek <msuchanek@suse.de>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>, Jiri Olsa <jolsa@kernel.org>,
	Hritik Vijay <hritikxx8@gmail.com>,
	Linux-BPF <bpf@vger.kernel.org>,
	Linux-Net <netdev@vger.kernel.org>, Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH v2] mm/page_alloc: Work around a pahole limitation with zero-sized struct pagesets
Date: Thu, 27 May 2021 18:27:00 +0100	[thread overview]
Message-ID: <20210527172700.GH30378@techsingularity.net> (raw)
In-Reply-To: <CAEf4BzbW2i4Y-i3TXW7x42PqEpw5_nNeReSXS77m4GC3uqD3wg@mail.gmail.com>

On Thu, May 27, 2021 at 09:36:35AM -0700, Andrii Nakryiko wrote:
> On Thu, May 27, 2021 at 7:54 AM Mel Gorman <mgorman@techsingularity.net> 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.

-- 
Mel Gorman
SUSE Labs

  reply	other threads:[~2021-05-27 17:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27 12:02 [PATCH v2] mm/page_alloc: Work around a pahole limitation with zero-sized struct pagesets Mel Gorman
2021-05-27 14:37 ` Andrii Nakryiko
2021-05-27 14:37   ` Andrii Nakryiko
2021-05-27 14:54   ` Mel Gorman
2021-05-27 16:36     ` Andrii Nakryiko
2021-05-27 16:36       ` Andrii Nakryiko
2021-05-27 17:27       ` Mel Gorman [this message]
2021-05-27 22:25         ` Andrii Nakryiko
2021-05-27 22:25           ` Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210527172700.GH30378@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=acme@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=hch@infradead.org \
    --cc=hritikxx8@gmail.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=msuchanek@suse.de \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.