Re: BPF: failed module verification on linux-next

[Mel Gorman]

> On Tue, May 25, 2021 at 6:51 AM Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, May 24, 2021 at 03:58:29PM -0700, Andrii Nakryiko wrote:
> > > > It took me a while to reliably bisect this, but it clearly points to
> > > > this commit:
> > > >
> > > > e481fac7d80b ("mm/page_alloc: convert per-cpu list protection to local_lock")
> > > > <SNIP>
> > >
> > > Ok, so nothing weird about them. local_lock_t is designed to be
> > > zero-sized unless CONFIG_DEBUG_LOCK_ALLOC is defined.
> > >
> > > But such zero-sized per-CPU variables are confusing pahole during BTF
> > > generation, as now two different variables "occupy" the same address.
> > >
> > > Given this seems to be the first zero-sized per-CPU variable, I wonder
> > > if it would be ok to make sure it's never zero-sized, while pahole
> > > gets fixed and it's latest version gets widely packaged and
> > > distributed.
> > >
> > > Mel, what do you think about something like below? Or maybe you can
> > > advise some better solution?
> > >
> >
> > Ouch, something like that may never go away. How about just this?
> 
> Yeah, that would work just fine, thanks! Would you like me to send a
> formal patch or you'd like to do it?
> 

Thanks Andrii for bisecting and debugging this, I used your analysis in
the changelog which I hope is ok. For future mailing list searches based
on the same bug, I sent a formal patch

https://lore.kernel.org/r/20210526080741.GW30378@xxxxxxxxxxxxxxxxxxx

> > diff --git a/scripts/rust-version.sh b/scripts/rust-version.sh
> > old mode 100644
> > new mode 100755
> 
> Probably didn't intend to include this?
> 

That was an oversight when applying Andrew's mmotm tree which missed
setting the permissions on rust-version.sh and broke build.

-- 
Mel Gorman
SUSE Labs