On Tue, Nov 29, 2022 at 10:28:33PM -0800, Hugh Dickins wrote:
> On Mon, 28 Nov 2022, Nathan Chancellor wrote:
>
> > Portions of upstream commit a4055888629b ("mm/memcg: warning on !memcg
> > after readahead page charged") were backported as commit cfe575954ddd
> > ("mm: add VM_WARN_ON_ONCE_PAGE() macro"). Unfortunately, the backport
> > did not account for the lack of commit 33def8498fdd ("treewide: Convert
> > macro and uses of __section(foo) to __section("foo")") in kernels prior
> > to 5.10, resulting in the following orphan section warnings on PowerPC
> > clang builds with CONFIG_DEBUG_VM=y:
> >
> > powerpc64le-linux-gnu-ld: warning: orphan section `".data.once"' from `mm/huge_memory.o' being placed in section `".data.once"'
> > powerpc64le-linux-gnu-ld: warning: orphan section `".data.once"' from `mm/huge_memory.o' being placed in section `".data.once"'
> > powerpc64le-linux-gnu-ld: warning: orphan section `".data.once"' from `mm/huge_memory.o' being placed in section `".data.once"'
> >
> > This is a difference between how clang and gcc handle macro
> > stringification, which was resolved for the kernel by not stringifying
> > the argument to the __section() macro. Since that change was deemed not
> > suitable for the stable kernels by commit 59f89518f510 ("once: fix
> > section mismatch on clang builds"), do that same thing as that change
> > and remove the quotes from the argument to __section().
> >
> > Fixes: cfe575954ddd ("mm: add VM_WARN_ON_ONCE_PAGE() macro")
> > Signed-off-by: Nathan Chancellor <nathan@xxxxxxxxxx>
>
> Yes indeed: thanks Nathan, sorry about that.
>
> Acked-by: Hugh Dickins <hughd@xxxxxxxxxx>
No worries, it is a really subtle problem that I would not expect
someone doing normal backports to catch. Thanks for taking a look!
> > ---
> >
> > As far as I can tell, this should be applied to 5.4 and earlier. It
> > should apply cleanly but let me know if not.
>
> I think it should be good for 4.19 also, but I don't know what happens
> or would happen in 4.14 and 4.9 trees, since those have no other example
> of .data.once or ".data.once" (and I've lost what little I ever knew of
> that linker script stuff).
>
> Since we're not hearing complaints about those (or are you?), perhaps
> those trees are not clang-ready in other ways, and for gcc it all works
> out by itself: I'd be inclined to just leave them as is myself, if there
> are no reports of breakage; but you may know better, and prefer to remove
> the ' __section(".data.once")' from the 4.14 and 4.9 versions.
Those trees have very rudimentary clang support, they are far from
warning and issue clean in all configurations (even mainline has known
issues for some architectures, including powerpc). Since this
specifically requires CONFIG_DEBUG_VM to see, I am perfectly fine with
just applying it to 4.19 and 5.4.
Cheers,
Nathan
> >
> > include/linux/mmdebug.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/mmdebug.h b/include/linux/mmdebug.h
> > index 5d0767cb424a..4ed52879ce55 100644
> > --- a/include/linux/mmdebug.h
> > +++ b/include/linux/mmdebug.h
> > @@ -38,7 +38,7 @@ void dump_mm(const struct mm_struct *mm);
> > } \
> > } while (0)
> > #define VM_WARN_ON_ONCE_PAGE(cond, page) ({ \
> > - static bool __section(".data.once") __warned; \
> > + static bool __section(.data.once) __warned; \
> > int __ret_warn_once = !!(cond); \
> > \
> > if (unlikely(__ret_warn_once && !__warned)) { \
> >
> > base-commit: 4d2a309b5c28a2edc0900542d22fec3a5a22243b
> > --
> > 2.38.1
