On Tue, May 25, 2021 at 6:51 AM Mel Gorman [off-list ref] wrote:

quoted

On Mon, May 24, 2021 at 03:58:29PM -0700, Andrii Nakryiko wrote:

quoted

quoted

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@techsingularity.net (local)

quoted

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