On Wed, Feb 16, 2022 at 09:00:09AM +0100, Sebastian Andrzej Siewior wrote:
> On 2022-02-15 11:43:22 [-0700], Nathan Chancellor wrote:
> > Commit 9983a9d577db ("locking/local_lock: Make the empty local_lock_*()
> > function a macro.") in the -tip tree converted the local_lock_*()
> > functions into macros, which causes a warning with clang with
> > CONFIG_PREEMPT_RT=n + CONFIG_DEBUG_LOCK_ALLOC=n:
> >
> > mm/page_alloc.c:131:40: error: variable 'pagesets' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
> > static DEFINE_PER_CPU(struct pagesets, pagesets) = {
> > ^
> > 1 error generated.
> >
> > Prior to that change, clang was not able to tell that pagesets was
> > unused in this configuration because it does not perform cross function
> > analysis in the frontend. After that change, it sees that the macros
> > just do a typecheck on the lock member of pagesets, which is evaluated
> > at compile time (so the variable is technically "used"), meaning the
> > variable is not needed in the final assembly, as the warning states.
> >
> > Mark the variable as __maybe_unused to make it clear to clang that this
> > is expected in this configuration so there is no more warning.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1593
> > Reported-by: "kernelci.org bot" <bot@xxxxxxxxxxxx>
> > Suggested-by: Nick Desaulniers <ndesaulniers@xxxxxxxxxx>
> > Signed-off-by: Nathan Chancellor <nathan@xxxxxxxxxx>
> > ---
> > mm/page_alloc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 7ff1efc84205..406f5d0c610f 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -128,7 +128,7 @@ static DEFINE_MUTEX(pcp_batch_high_lock);
> > struct pagesets {
> > local_lock_t lock;
> > };
> > -static DEFINE_PER_CPU(struct pagesets, pagesets) = {
> > +static DEFINE_PER_CPU(struct pagesets, pagesets) __maybe_unused = {
>
> No, I need to think of something else then for the local_lock thing. I
> haven't seen it with gcc. There is probably more than just this one.
As far as I am aware, this is a clang only warning.
