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@xxxxxxxxxxxxxxxxxxx> 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
