Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

skip using gcc brace groups for STMT_START/END #18984

Merged
merged 1 commit into from
Jul 15, 2021

Conversation

tonycoz
Copy link
Contributor

@tonycoz tonycoz commented Jul 15, 2021

This warns (and warns a lot) on clang, and since these are documented
to only work to make a single statement, so there's little value to
allowing them to work in an expression.

An alternative would be to disable GCC brace groups on clang, but
these are used extensively in DEBUGGING builds to add extra checks
in sv.h.

Fixes #18780

This warns (and warns a lot) on clang, and since these are documented
to only work to make a single statement, so there's little value to
allowing them to work in an expression.

An alternative would be to disable GCC brace groups on clang, but
these are used extensively in DEBUGGING builds to add extra checks
in sv.h.
@khwilliamson
Copy link
Contributor

This breaks Devel::PPPort at perl 5.13.0, and needs to be reverted or fixed before the next monthly development release.

The errors are:

'stderr' => [
'In file included from RealPPPort.xs:146:0:
',
'RealPPPort.xs: In function ‘XS_Devel__PPPort_eval_sv’:
',
'ppport.h:5867:25: error: expected expression before ‘do’
',
' # define STMT_START do
',
' ^
',
'ppport.h:8160:5: note: in expansion of macro ‘STMT_START’
',
' STMT_START { \
',
' ^
',
'ppport.h:8508:121: note: in expansion of macro ‘croak_sv’
',
' # define D_PPP_CROAK_IF_ERROR(cond) ({ SV _errsv; ((cond) && (_errsv = ERRSV) && (SvROK(_errsv) || SvTRUE(_errsv)) && (croak_sv(_errsv), 1)); })
',
' ^
',
'ppport.h:8533:113: note: in expansion of macro ‘D_PPP_CROAK_IF_ERROR’
',
' # define eval_sv(sv, flags) ({ I32 _flags = (flags); I32 ret = Perl_eval_sv(aTHX sv, (_flags & ~G_RETHROW)); D_PPP_CROAK_IF_ERROR(_flags & G_RETHROW); _ret; })
',
' ^
',
'RealPPPort.xs:802:21: note: in expansion of macro ‘eval_sv’
',
' i = eval_sv(sv, flags);
',
' ^
',
'In file included from /media/Tux/perls-t/lib/5.13.0/x86_64-linux-thread-multi-ld/CORE/perl.h:4934:0,
',
' from RealPPPort.xs:31:
',
'RealPPPort.xs: In function ‘XS_Devel__PPPort_eval_pv’:
',
'ppport.h:5867:25: error: expected expression before ‘do’
',
' # define STMT_START do
',
' ^
',
'/media/Tux/perls-t/lib/5.13.0/x86_64-linux-thread-multi-ld/CORE/pp.h:291:28: note: in definition of macro ‘PUSHs’
',
' #define PUSHs(s) (
++sp = (s))
',
' ^
',
'ppport.h:8160:5: note: in expansion of macro ‘STMT_START’
',
' STMT_START { \
',
' ^
',
'ppport.h:8508:121: note: in expansion of macro ‘croak_sv’
',
' # define D_PPP_CROAK_IF_ERROR(cond) ({ SV *_errsv; ((cond) && (_errsv = ERRSV) && (SvROK(_errsv) || SvTRUE(_errsv)) && (croak_sv(_errsv), 1)); })
',
' ^
',
'ppport.h:8544:78: note: in expansion of macro ‘D_PPP_CROAK_IF_ERROR’
',
' # define eval_pv(p, croak_on_error) ({ SV *sv = Perl_eval_pv(aTHX p, 0); D_PPP_CROAK_IF_ERROR(croak_on_error); _sv; })
',
' ^
',
'RealPPPort.xs:814:23: note: in expansion of macro ‘eval_pv’
',
' PUSHs(eval_pv(p, croak_on_error));
',
' ^
',
'make: *** [RealPPPort.o] Error 1
'

@khwilliamson
Copy link
Contributor

I did some more digging, and the reason is related to this:
commit 1400a53
Author: Nicholas Clark [email protected]
Date: Wed Sep 11 11:54:42 2013 +0200

 Eliminate the only use of VOIDFLAGS, as part of STMT_START in perl.h
 
 STMT_START has used VOIDFLAGS as part of its conditional compilation since it
 was added by commit 728e280303ae3d3b (March 1996). The code originally read:
 
    /* Now which other defined()s do we need here ??? */
 
 Since then it has been amended to avoid entering that definition for GCC
 on Solaris. Given that all current Solaris compilers are C89 conformant,
 VOIDFLAGS will always be true (actually 15), so the test is redundant.
 Even back in 1996, it's possible that VOIDFLAGS was always non-zero on
 SunOS, rendering the test obsolete from the start.
 
 Spotted by Brian Fraser, and extracted from a larger patch of his.

torvalds pushed a commit to torvalds/linux that referenced this pull request Apr 10, 2022
These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this pull request Apr 11, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
tuxedo-bot pushed a commit to tuxedocomputers/linux that referenced this pull request May 2, 2022
BugLink: https://bugs.launchpad.net/bugs/1969107

commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
(cherry picked from commit fbe722d48b8eee840015fc1657602f627ca875b7)
Signed-off-by: Paolo Pisati <[email protected]>
tuxedo-bot pushed a commit to tuxedocomputers/linux that referenced this pull request May 9, 2022
BugLink: https://bugs.launchpad.net/bugs/1969107

commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
(cherry picked from commit fbe722d48b8eee840015fc1657602f627ca875b7)
Signed-off-by: Paolo Pisati <[email protected]>
ZenkaBestia added a commit to NusantaraROM-Devices/kernel_xiaomi_lmi that referenced this pull request May 14, 2022
Squashed commit of the following:

commit 860d1d0d4b2dbf121af35fe6e55a4404db73e214
Merge: a4206df2a09e4 aaad8e56ca1e5
Author: ZenkaBestia <[email protected]>
Date:   Sat May 14 11:05:31 2022 +0000

    Merge tag 'v4.19.238' into 12-up

    This is the 4.19.238 stable release
    from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

    Conflicts:
    	block/bfq-iosched.c
    	drivers/irqchip/irq-gic-v3.c
    	drivers/irqchip/qcom-pdc.c
    	drivers/mmc/core/host.c
    	drivers/usb/host/xhci.c
    	drivers/usb/host/xhci.h
    	include/linux/pci.h

commit a4206df2a09e4b2446d5218437eddca97317f93d
Merge: 4952c26d5d2d3 a6e4a1818efa7
Author: ZenkaBestia <[email protected]>
Date:   Sat May 14 08:55:05 2022 +0000

    Merge tag 'v4.19.237' into 12-up

    This is the 4.19.237 stable release
    from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

    Signed-off-by: ZenkaBestia <[email protected]>

    Conflicts:
    	drivers/nfc/st21nfca/se.c

commit aaad8e56ca1e56fe34b5a33f30fb6f9279969020
Author: Greg Kroah-Hartman <[email protected]>
Date:   Fri Apr 15 14:15:08 2022 +0200

    Linux 4.19.238

    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Pavel Machek (CIP) <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Hulk Robot <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7faf003b58812c33e3b5315683e85d57b5ec4e3f
Author: Felix Kuehling <[email protected]>
Date:   Wed Apr 7 18:19:58 2021 -0400

    drm/amdkfd: Use drm_priv to pass VM from KFD to amdgpu

    commit b40a6ab2cf9213923bf8e821ce7fa7f6a0a26990 upstream.

    amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu needs the drm_priv to allow mmap
    to access the BO through the corresponding file descriptor. The VM can
    also be extracted from drm_priv, so drm_priv can replace the vm parameter
    in the kfd2kgd interface.

    Signed-off-by: Felix Kuehling <[email protected]>
    Reviewed-by: Philip Yang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    [ This is a partial cherry-pick of the commit. ]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f08fb393786d64a97a48bd038e68aec310c31297
Author: Bas Nieuwenhuizen <[email protected]>
Date:   Wed Jan 30 02:53:21 2019 +0100

    drm/amdgpu: Check if fd really is an amdgpu fd.

    commit 021830d24ba55a578f602979274965344c8e6284 upstream.

    Otherwise we interpret the file private data as drm & amdgpu data
    while it might not be, possibly allowing one to get memory corruption.

    Signed-off-by: Bas Nieuwenhuizen <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 00cdc297e219798a43bf55a8b1b1df6b6285c8e6
Author: Xin Long <[email protected]>
Date:   Mon Jun 22 16:40:29 2020 +0800

    xfrm: policy: match with both mark and mask on user interfaces

    commit 4f47e8ab6ab796b5380f74866fa5287aca4dcc58 upstream.

    In commit ed17b8d377ea ("xfrm: fix a warning in xfrm_policy_insert_list"),
    it would take 'priority' to make a policy unique, and allow duplicated
    policies with different 'priority' to be added, which is not expected
    by userland, as Tobias reported in strongswan.

    To fix this duplicated policies issue, and also fix the issue in
    commit ed17b8d377ea ("xfrm: fix a warning in xfrm_policy_insert_list"),
    when doing add/del/get/update on user interfaces, this patch is to change
    to look up a policy with both mark and mask by doing:

      mark.v == pol->mark.v && mark.m == pol->mark.m

    and leave the check:

      (mark & pol->mark.m) == pol->mark.v

    for tx/rx path only.

    As the userland expects an exact mark and mask match to manage policies.

    v1->v2:
      - make xfrm_policy_mark_match inline and fix the changelog as
        Tobias suggested.

    Fixes: 295fae568885 ("xfrm: Allow user space manipulation of SPD mark")
    Fixes: ed17b8d377ea ("xfrm: fix a warning in xfrm_policy_insert_list")
    Reported-by: Tobias Brunner <[email protected]>
    Tested-by: Tobias Brunner <[email protected]>
    Signed-off-by: Xin Long <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 86be2e7111e20b6b57850e9d203276c89af117da
Author: Tejun Heo <[email protected]>
Date:   Thu Apr 14 12:07:00 2022 +0300

    selftests: cgroup: Test open-time cgroup namespace usage for migration checks

    commit bf35a7879f1dfb0d050fe779168bcf25c7de66f5 upstream.

    When a task is writing to an fd opened by a different task, the perm check
    should use the cgroup namespace of the latter task. Add a test for it.

    Tested-by: Michal Koutný <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    [OP: backport to v4.19: adjust context, add wait.h and fcntl.h includes]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 81c22cf89126ae52e7751b0bb11e1c54e72c3a88
Author: Tejun Heo <[email protected]>
Date:   Thu Apr 14 12:06:59 2022 +0300

    selftests: cgroup: Test open-time credential usage for migration checks

    commit 613e040e4dc285367bff0f8f75ea59839bc10947 upstream.

    When a task is writing to an fd opened by a different task, the perm check
    should use the credentials of the latter task. Add a test for it.

    Tested-by: Michal Koutný <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    [OP: backport to v4.19: adjust context]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 135117aa4055e13cd7c47e61093b5f1a15901fb3
Author: Tejun Heo <[email protected]>
Date:   Thu Apr 14 12:06:58 2022 +0300

    selftests: cgroup: Make cg_create() use 0755 for permission instead of 0644

    commit b09c2baa56347ae65795350dfcc633dedb1c2970 upstream.

    0644 is an odd perm to create a cgroup which is a directory. Use the regular
    0755 instead. This is necessary for euid switching test case.

    Reviewed-by: Michal Koutný <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    [OP: backport to 4.19: adjust context]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 74ac12c718e7d3f7eb346ee90a4c9904a8b6b6d2
Author: Tejun Heo <[email protected]>
Date:   Thu Apr 14 12:06:57 2022 +0300

    cgroup: Use open-time cgroup namespace for process migration perm checks

    commit e57457641613fef0d147ede8bd6a3047df588b95 upstream.

    cgroup process migration permission checks are performed at write time as
    whether a given operation is allowed or not is dependent on the content of
    the write - the PID. This currently uses current's cgroup namespace which is
    a potential security weakness as it may allow scenarios where a less
    privileged process tricks a more privileged one into writing into a fd that
    it created.

    This patch makes cgroup remember the cgroup namespace at the time of open
    and uses it for migration permission checks instad of current's. Note that
    this only applies to cgroup2 as cgroup1 doesn't have namespace support.

    This also fixes a use-after-free bug on cgroupns reported in

     https://lore.kernel.org/r/[email protected]

    Note that backporting this fix also requires the preceding patch.

    Reported-by: "Eric W. Biederman" <[email protected]>
    Suggested-by: Linus Torvalds <[email protected]>
    Cc: Michal Koutný <[email protected]>
    Cc: Oleg Nesterov <[email protected]>
    Reviewed-by: Michal Koutný <[email protected]>
    Reported-by: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 5136f6365ce3 ("cgroup: implement "nsdelegate" mount option")
    Signed-off-by: Tejun Heo <[email protected]>
    [mkoutny: v5.10: duplicate ns check in procs/threads write handler, adjust context]
    Signed-off-by: Michal Koutný <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    [OP: backport to v4.19: drop changes to cgroup_attach_permissions() and
    cgroup_css_set_fork(), adjust cgroup_procs_write_permission() calls]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit de37e01dd20e3228b010fe5fbd3e205747481b96
Author: Tejun Heo <[email protected]>
Date:   Thu Apr 14 12:06:56 2022 +0300

    cgroup: Allocate cgroup_file_ctx for kernfs_open_file->priv

    commit 0d2b5955b36250a9428c832664f2079cbf723bec upstream.

    of->priv is currently used by each interface file implementation to store
    private information. This patch collects the current two private data usages
    into struct cgroup_file_ctx which is allocated and freed by the common path.
    This allows generic private data which applies to multiple files, which will
    be used to in the following patch.

    Note that cgroup_procs iterator is now embedded as procs.iter in the new
    cgroup_file_ctx so that it doesn't need to be allocated and freed
    separately.

    v2: union dropped from cgroup_file_ctx and the procs iterator is embedded in
        cgroup_file_ctx as suggested by Linus.

    v3: Michal pointed out that cgroup1's procs pidlist uses of->priv too.
        Converted. Didn't change to embedded allocation as cgroup1 pidlists get
        stored for caching.

    Signed-off-by: Tejun Heo <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Reviewed-by: Michal Koutný <[email protected]>
    [mkoutny: v5.10: modify cgroup.pressure handlers, adjust context]
    Signed-off-by: Michal Koutný <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    [OP: backport to v4.19: drop changes to cgroup_pressure_*() functions]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0bd407959f7d6671ba0617e2dbda3e89d8a0419f
Author: Tejun Heo <[email protected]>
Date:   Thu Apr 14 12:06:55 2022 +0300

    cgroup: Use open-time credentials for process migraton perm checks

    commit 1756d7994ad85c2479af6ae5a9750b92324685af upstream.

    cgroup process migration permission checks are performed at write time as
    whether a given operation is allowed or not is dependent on the content of
    the write - the PID. This currently uses current's credentials which is a
    potential security weakness as it may allow scenarios where a less
    privileged process tricks a more privileged one into writing into a fd that
    it created.

    This patch makes both cgroup2 and cgroup1 process migration interfaces to
    use the credentials saved at the time of open (file->f_cred) instead of
    current's.

    Reported-by: "Eric W. Biederman" <[email protected]>
    Suggested-by: Linus Torvalds <[email protected]>
    Fixes: 187fe84067bd ("cgroup: require write perm on common ancestor when moving processes on the default hierarchy")
    Reviewed-by: Michal Koutný <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    [OP: backport to v4.19: apply original __cgroup_procs_write() changes to
    cgroup_threads_write() and cgroup_procs_write()]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ff929e3abef16c409a9beef08bcc29ab940d0ce6
Author: Waiman Long <[email protected]>
Date:   Fri Apr 8 13:09:01 2022 -0700

    mm/sparsemem: fix 'mem_section' will never be NULL gcc 12 warning

    commit a431dbbc540532b7465eae4fc8b56a85a9fc7d17 upstream.

    The gcc 12 compiler reports a "'mem_section' will never be NULL" warning
    on the following code:

        static inline struct mem_section *__nr_to_section(unsigned long nr)
        {
        #ifdef CONFIG_SPARSEMEM_EXTREME
            if (!mem_section)
                    return NULL;
        #endif
            if (!mem_section[SECTION_NR_TO_ROOT(nr)])
                    return NULL;
           :

    It happens with CONFIG_SPARSEMEM_EXTREME off.  The mem_section definition
    is

        #ifdef CONFIG_SPARSEMEM_EXTREME
        extern struct mem_section **mem_section;
        #else
        extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT];
        #endif

    In the !CONFIG_SPARSEMEM_EXTREME case, mem_section is a static
    2-dimensional array and so the check "!mem_section[SECTION_NR_TO_ROOT(nr)]"
    doesn't make sense.

    Fix this warning by moving the "!mem_section[SECTION_NR_TO_ROOT(nr)]"
    check up inside the CONFIG_SPARSEMEM_EXTREME block and adding an
    explicit NR_SECTION_ROOTS check to make sure that there is no
    out-of-bound array access.

    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 3e347261a80b ("sparsemem extreme implementation")
    Signed-off-by: Waiman Long <[email protected]>
    Reported-by: Justin Forbes <[email protected]>
    Cc: "Kirill A . Shutemov" <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Rafael Aquini <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 634a959641b413bf831870cbf544443f6f47c141
Author: Fangrui Song <[email protected]>
Date:   Fri Feb 18 00:12:09 2022 -0800

    arm64: module: remove (NOLOAD) from linker script

    commit 4013e26670c590944abdab56c4fa797527b74325 upstream.

    On ELF, (NOLOAD) sets the section type to SHT_NOBITS[1]. It is conceptually
    inappropriate for .plt and .text.* sections which are always
    SHT_PROGBITS.

    In GNU ld, if PLT entries are needed, .plt will be SHT_PROGBITS anyway
    and (NOLOAD) will be essentially ignored. In ld.lld, since
    https://reviews.llvm.org/D118840 ("[ELF] Support (TYPE=<value>) to
    customize the output section type"), ld.lld will report a `section type
    mismatch` error. Just remove (NOLOAD) to fix the error.

    [1] https://lld.llvm.org/ELF/linker_script.html As of today, "The
    section should be marked as not loadable" on
    https://sourceware.org/binutils/docs/ld/Output-Section-Type.html is
    outdated for ELF.

    Tested-by: Nathan Chancellor <[email protected]>
    Reported-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Fangrui Song <[email protected]>
    Acked-by: Ard Biesheuvel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    [nathan: Fix conflicts due to lack of 596b0474d3d9]
    Signed-off-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7265c880004d30691ea3715ce0eaf6ef3ce5d445
Author: Peter Xu <[email protected]>
Date:   Tue Mar 22 14:42:15 2022 -0700

    mm: don't skip swap entry even if zap_details specified

    commit 5abfd71d936a8aefd9f9ccd299dea7a164a5d455 upstream.

    Patch series "mm: Rework zap ptes on swap entries", v5.

    Patch 1 should fix a long standing bug for zap_pte_range() on
    zap_details usage.  The risk is we could have some swap entries skipped
    while we should have zapped them.

    Migration entries are not the major concern because file backed memory
    always zap in the pattern that "first time without page lock, then
    re-zap with page lock" hence the 2nd zap will always make sure all
    migration entries are already recovered.

    However there can be issues with real swap entries got skipped
    errornoously.  There's a reproducer provided in commit message of patch
    1 for that.

    Patch 2-4 are cleanups that are based on patch 1.  After the whole
    patchset applied, we should have a very clean view of zap_pte_range().

    Only patch 1 needs to be backported to stable if necessary.

    This patch (of 4):

    The "details" pointer shouldn't be the token to decide whether we should
    skip swap entries.

    For example, when the callers specified details->zap_mapping==NULL, it
    means the user wants to zap all the pages (including COWed pages), then
    we need to look into swap entries because there can be private COWed
    pages that was swapped out.

    Skipping some swap entries when details is non-NULL may lead to wrongly
    leaving some of the swap entries while we should have zapped them.

    A reproducer of the problem:

    ===8<===
            #define _GNU_SOURCE         /* See feature_test_macros(7) */
            #include <stdio.h>
            #include <assert.h>
            #include <unistd.h>
            #include <sys/mman.h>
            #include <sys/types.h>

            int page_size;
            int shmem_fd;
            char *buffer;

            void main(void)
            {
                    int ret;
                    char val;

                    page_size = getpagesize();
                    shmem_fd = memfd_create("test", 0);
                    assert(shmem_fd >= 0);

                    ret = ftruncate(shmem_fd, page_size * 2);
                    assert(ret == 0);

                    buffer = mmap(NULL, page_size * 2, PROT_READ | PROT_WRITE,
                                    MAP_PRIVATE, shmem_fd, 0);
                    assert(buffer != MAP_FAILED);

                    /* Write private page, swap it out */
                    buffer[page_size] = 1;
                    madvise(buffer, page_size * 2, MADV_PAGEOUT);

                    /* This should drop private buffer[page_size] already */
                    ret = ftruncate(shmem_fd, page_size);
                    assert(ret == 0);
                    /* Recover the size */
                    ret = ftruncate(shmem_fd, page_size * 2);
                    assert(ret == 0);

                    /* Re-read the data, it should be all zero */
                    val = buffer[page_size];
                    if (val == 0)
                            printf("Good\n");
                    else
                            printf("BUG\n");
            }
    ===8<===

    We don't need to touch up the pmd path, because pmd never had a issue with
    swap entries.  For example, shmem pmd migration will always be split into
    pte level, and same to swapping on anonymous.

    Add another helper should_zap_cows() so that we can also check whether we
    should zap private mappings when there's no page pointer specified.

    This patch drops that trick, so we handle swap ptes coherently.  Meanwhile
    we should do the same check upon migration entry, hwpoison entry and
    genuine swap entries too.

    To be explicit, we should still remember to keep the private entries if
    even_cows==false, and always zap them when even_cows==true.

    The issue seems to exist starting from the initial commit of git.

    [[email protected]: comment tweaks]
      Link: https://lkml.kernel.org/r/[email protected]

    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Peter Xu <[email protected]>
    Reviewed-by: John Hubbard <[email protected]>
    Cc: David Hildenbrand <[email protected]>
    Cc: Hugh Dickins <[email protected]>
    Cc: Alistair Popple <[email protected]>
    Cc: Andrea Arcangeli <[email protected]>
    Cc: "Kirill A . Shutemov" <[email protected]>
    Cc: Matthew Wilcox <[email protected]>
    Cc: Vlastimil Babka <[email protected]>
    Cc: Yang Shi <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2ea1bc78fba954980873c2d05c3ea4707828ee0f
Author: Vinod Koul <[email protected]>
Date:   Thu Mar 10 10:13:20 2022 +0530

    dmaengine: Revert "dmaengine: shdma: Fix runtime PM imbalance on error"

    commit d143f939a95696d38ff800ada14402fa50ebbd6c upstream.

    This reverts commit 455896c53d5b ("dmaengine: shdma: Fix runtime PM
    imbalance on error") as the patch wrongly reduced the count on error and
    did not bail out. So drop the count by reverting the patch .

    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c3cd98867a9df56a78ddb8ae413df17df84d9998
Author: Arnaldo Carvalho de Melo <[email protected]>
Date:   Mon Apr 4 17:28:48 2022 -0300

    tools build: Use $(shell ) instead of `` to get embedded libperl's ccopts

    commit 541f695cbcb6932c22638b06e0cbe1d56177e2e9 upstream.

    Just like its done for ldopts and for both in tools/perf/Makefile.config.

    Using `` to initialize PERL_EMBED_CCOPTS somehow precludes using:

      $(filter-out SOMETHING_TO_FILTER,$(PERL_EMBED_CCOPTS))

    And we need to do it to allow for building with versions of clang where
    some gcc options selected by distros are not available.

    Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
    Cc: Adrian Hunter <[email protected]>
    Cc: Fangrui Song <[email protected]>
    Cc: Florian Fainelli <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: John Keeping <[email protected]>
    Cc: Leo Yan <[email protected]>
    Cc: Michael Petlan <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Nathan Chancellor <[email protected]>
    Cc: Nick Desaulniers <[email protected]>
    Link: http://lore.kernel.org/lkml/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1236257a91bafcd8dc3984c585e84a4986d95de7
Author: Arnaldo Carvalho de Melo <[email protected]>
Date:   Tue Apr 5 10:33:21 2022 -0300

    tools build: Filter out options and warnings not supported by clang

    commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

    These make the feature check fail when using clang, so remove them just
    like is done in tools/perf/Makefile.config to build perf itself.

    Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
    when building with clang is also necessary to avoid these warnings
    turned into errors (-Werror):

        CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
      In file included from util/scripting-engines/trace-event-perl.c:35:
      In file included from /usr/lib64/perl5/CORE/perl.h:4085:
      In file included from /usr/lib64/perl5/CORE/hv.h:659:
      In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
      In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
      /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
          ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                           ^~~~~~~~~~
      /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
      #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                    ^
      /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
          ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                      ^
      /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
          ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
          v ^= (v>>23);                       \
                                              ^
      /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
          ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      } STMT_END
        ^~~~~~~~
      /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
      #   define STMT_END     )
                              ^

    Please refer to the discussion on the Link: tag below, where Nathan
    clarifies the situation:

    <quote>
    acme> And then get to the problems at the end of this message, which seem
    acme> similar to the problem described here:
    acme>
    acme> From  Nathan Chancellor <>
    acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
    acme>
    acme> https://lkml.org/lkml/2020/9/1/135
    acme>
    acme> So perhaps in this case its better to disable that
    acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

    Yes, I think that is probably the best solution. As far as I can tell,
    at least in this file and context, the warning appears harmless, as the
    "create a GNU C statement expression from two different macros" is very
    much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
    The warning is fixed in upstream Perl by just avoiding creating GNU C
    statement expressions using STMT_START and STMT_END:

      https://github.com/Perl/perl5/issues/18780
      https://github.com/Perl/perl5/pull/18984

    If I am reading the source code correctly, an alternative to disabling
    the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
    seems like that might end up impacting more than just this site,
    according to the issue discussion above.
    </quote>

    Based-on-a-patch-by: Sedat Dilek <[email protected]>
    Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
    Cc: Adrian Hunter <[email protected]>
    Cc: Fangrui Song <[email protected]>
    Cc: Florian Fainelli <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: John Keeping <[email protected]>
    Cc: Leo Yan <[email protected]>
    Cc: Michael Petlan <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Nathan Chancellor <[email protected]>
    Cc: Nick Desaulniers <[email protected]>
    Link: http://lore.kernel.org/lkml/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c7daf1b4ad809692d5c26f33c02ed8a031066548
Author: Marc Zyngier <[email protected]>
Date:   Tue Mar 15 16:50:32 2022 +0000

    irqchip/gic-v3: Fix GICR_CTLR.RWP polling

    commit 0df6664531a12cdd8fc873f0cac0dcb40243d3e9 upstream.

    It turns out that our polling of RWP is totally wrong when checking
    for it in the redistributors, as we test the *distributor* bit index,
    whereas it is a different bit number in the RDs... Oopsie boo.

    This is embarassing. Not only because it is wrong, but also because
    it took *8 years* to notice the blunder...

    Just fix the damn thing.

    Fixes: 021f653791ad ("irqchip: gic-v3: Initial support for GICv3")
    Signed-off-by: Marc Zyngier <[email protected]>
    Cc: [email protected]
    Reviewed-by: Andre Przywara <[email protected]>
    Reviewed-by: Lorenzo Pieralisi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit cbe2c848042af25345fee541692b0baf61e7c049
Author: Xiaomeng Tong <[email protected]>
Date:   Sun Mar 27 13:57:33 2022 +0800

    perf: qcom_l2_pmu: fix an incorrect NULL check on list iterator

    commit 2012a9e279013933885983cbe0a5fe828052563b upstream.

    The bug is here:
    	return cluster;

    The list iterator value 'cluster' will *always* be set and non-NULL
    by list_for_each_entry(), so it is incorrect to assume that the
    iterator value will be NULL if the list is empty or no element
    is found.

    To fix the bug, return 'cluster' when found, otherwise return NULL.

    Cc: [email protected]
    Fixes: 21bdbb7102ed ("perf: add qcom l2 cache perf events driver")
    Signed-off-by: Xiaomeng Tong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 596c7efd69aae94f4b0e91172b075eb197958b99
Author: Christian Lamparter <[email protected]>
Date:   Sat Mar 19 21:11:02 2022 +0100

    ata: sata_dwc_460ex: Fix crash due to OOB write

    commit 7aa8104a554713b685db729e66511b93d989dd6a upstream.

    the driver uses libata's "tag" values from in various arrays.
    Since the mentioned patch bumped the ATA_TAG_INTERNAL to 32,
    the value of the SATA_DWC_QCMD_MAX needs to account for that.

    Otherwise ATA_TAG_INTERNAL usage cause similar crashes like
    this as reported by Tice Rex on the OpenWrt Forum and
    reproduced (with symbols) here:

    | BUG: Kernel NULL pointer dereference at 0x00000000
    | Faulting instruction address: 0xc03ed4b8
    | Oops: Kernel access of bad area, sig: 11 [#1]
    | BE PAGE_SIZE=4K PowerPC 44x Platform
    | CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0
    | NIP:  c03ed4b8 LR: c03d27e8 CTR: c03ed36c
    | REGS: cfa59950 TRAP: 0300   Not tainted  (5.4.163)
    | MSR:  00021000 <CE,ME>  CR: 42000222  XER: 00000000
    | DEAR: 00000000 ESR: 00000000
    | GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...]
    | [..]
    | NIP [c03ed4b8] sata_dwc_qc_issue+0x14c/0x254
    | LR [c03d27e8] ata_qc_issue+0x1c8/0x2dc
    | Call Trace:
    | [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (unreliable)
    | [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc
    | [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524
    | [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0
    | [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204
    | [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130
    | [...]

    This is because sata_dwc_dma_xfer_complete() NULLs the
    dma_pending's next neighbour "chan" (a *dma_chan struct) in
    this '32' case right here (line ~735):
    > hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE;

    Then the next time, a dma gets issued; dma_dwc_xfer_setup() passes
    the NULL'd hsdevp->chan to the dmaengine_slave_config() which then
    causes the crash.

    With this patch, SATA_DWC_QCMD_MAX is now set to ATA_MAX_QUEUE + 1.
    This avoids the OOB. But please note, there was a worthwhile discussion
    on what ATA_TAG_INTERNAL and ATA_MAX_QUEUE is. And why there should not
    be a "fake" 33 command-long queue size.

    Ideally, the dw driver should account for the ATA_TAG_INTERNAL.
    In Damien Le Moal's words: "... having looked at the driver, it
    is a bigger change than just faking a 33rd "tag" that is in fact
    not a command tag at all."

    Fixes: 28361c403683c ("libata: add extra internal command")
    Cc: [email protected] # 4.18+
    BugLink: https://github.com/openwrt/openwrt/issues/9505
    Signed-off-by: Christian Lamparter <[email protected]>
    Signed-off-by: Damien Le Moal <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e5b0d0a5515f82ce151d192e2c6304f3f143bb56
Author: Guo Ren <[email protected]>
Date:   Thu Apr 7 15:33:20 2022 +0800

    arm64: patch_text: Fixup last cpu should be master

    commit 31a099dbd91e69fcab55eef4be15ed7a8c984918 upstream.

    These patch_text implementations are using stop_machine_cpuslocked
    infrastructure with atomic cpu_count. The original idea: When the
    master CPU patch_text, the others should wait for it. But current
    implementation is using the first CPU as master, which couldn't
    guarantee the remaining CPUs are waiting. This patch changes the
    last CPU as the master to solve the potential risk.

    Fixes: ae16480785de ("arm64: introduce interfaces to hotpatch kernel and module code")
    Signed-off-by: Guo Ren <[email protected]>
    Signed-off-by: Guo Ren <[email protected]>
    Reviewed-by: Catalin Marinas <[email protected]>
    Reviewed-by: Masami Hiramatsu <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f3d97b22a708bf9e3f3ac2ba232bcefd0b0c136b
Author: Ethan Lien <[email protected]>
Date:   Mon Mar 7 18:00:04 2022 +0800

    btrfs: fix qgroup reserve overflow the qgroup limit

    commit b642b52d0b50f4d398cb4293f64992d0eed2e2ce upstream.

    We use extent_changeset->bytes_changed in qgroup_reserve_data() to record
    how many bytes we set for EXTENT_QGROUP_RESERVED state. Currently the
    bytes_changed is set as "unsigned int", and it will overflow if we try to
    fallocate a range larger than 4GiB. The result is we reserve less bytes
    and eventually break the qgroup limit.

    Unlike regular buffered/direct write, which we use one changeset for
    each ordered extent, which can never be larger than 256M.  For
    fallocate, we use one changeset for the whole range, thus it no longer
    respects the 256M per extent limit, and caused the problem.

    The following example test script reproduces the problem:

      $ cat qgroup-overflow.sh
      #!/bin/bash

      DEV=/dev/sdj
      MNT=/mnt/sdj

      mkfs.btrfs -f $DEV
      mount $DEV $MNT

      # Set qgroup limit to 2GiB.
      btrfs quota enable $MNT
      btrfs qgroup limit 2G $MNT

      # Try to fallocate a 3GiB file. This should fail.
      echo
      echo "Try to fallocate a 3GiB file..."
      fallocate -l 3G $MNT/3G.file

      # Try to fallocate a 5GiB file.
      echo
      echo "Try to fallocate a 5GiB file..."
      fallocate -l 5G $MNT/5G.file

      # See we break the qgroup limit.
      echo
      sync
      btrfs qgroup show -r $MNT

      umount $MNT

    When running the test:

      $ ./qgroup-overflow.sh
      (...)

      Try to fallocate a 3GiB file...
      fallocate: fallocate failed: Disk quota exceeded

      Try to fallocate a 5GiB file...

      qgroupid         rfer         excl     max_rfer
      --------         ----         ----     --------
      0/5           5.00GiB      5.00GiB      2.00GiB

    Since we have no control of how bytes_changed is used, it's better to
    set it to u64.

    CC: [email protected] # 4.14+
    Reviewed-by: Qu Wenruo <[email protected]>
    Signed-off-by: Ethan Lien <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit edc7b755e8fce10009ac85bb234a035557301bc4
Author: Pawan Gupta <[email protected]>
Date:   Mon Apr 4 17:35:45 2022 -0700

    x86/speculation: Restore speculation related MSRs during S3 resume

    commit e2a1256b17b16f9b9adf1b6fea56819e7b68e463 upstream.

    After resuming from suspend-to-RAM, the MSRs that control CPU's
    speculative execution behavior are not being restored on the boot CPU.

    These MSRs are used to mitigate speculative execution vulnerabilities.
    Not restoring them correctly may leave the CPU vulnerable.  Secondary
    CPU's MSRs are correctly being restored at S3 resume by
    identify_secondary_cpu().

    During S3 resume, restore these MSRs for boot CPU when restoring its
    processor state.

    Fixes: 772439717dbf ("x86/bugs/intel: Set proper CPU features and setup RDS")
    Reported-by: Neelima Krishnan <[email protected]>
    Signed-off-by: Pawan Gupta <[email protected]>
    Tested-by: Neelima Krishnan <[email protected]>
    Acked-by: Borislav Petkov <[email protected]>
    Reviewed-by: Dave Hansen <[email protected]>
    Cc: [email protected]
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 11d692cb6c006372139eb373d469940d7a9108e1
Author: Pawan Gupta <[email protected]>
Date:   Mon Apr 4 17:34:19 2022 -0700

    x86/pm: Save the MSR validity status at context setup

    commit 73924ec4d560257004d5b5116b22a3647661e364 upstream.

    The mechanism to save/restore MSRs during S3 suspend/resume checks for
    the MSR validity during suspend, and only restores the MSR if its a
    valid MSR.  This is not optimal, as an invalid MSR will unnecessarily
    throw an exception for every suspend cycle.  The more invalid MSRs,
    higher the impact will be.

    Check and save the MSR validity at setup.  This ensures that only valid
    MSRs that are guaranteed to not throw an exception will be attempted
    during suspend.

    Fixes: 7a9c2dd08ead ("x86/pm: Introduce quirk framework to save/restore extra MSR registers around suspend/resume")
    Suggested-by: Dave Hansen <[email protected]>
    Signed-off-by: Pawan Gupta <[email protected]>
    Reviewed-by: Dave Hansen <[email protected]>
    Acked-by: Borislav Petkov <[email protected]>
    Cc: [email protected]
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 39a32f3c06f6d68a530bf9612afa19f50f12e93d
Author: Miaohe Lin <[email protected]>
Date:   Fri Apr 8 13:09:07 2022 -0700

    mm/mempolicy: fix mpol_new leak in shared_policy_replace

    commit 4ad099559b00ac01c3726e5c95dc3108ef47d03e upstream.

    If mpol_new is allocated but not used in restart loop, mpol_new will be
    freed via mpol_put before returning to the caller.  But refcnt is not
    initialized yet, so mpol_put could not do the right things and might
    leak the unused mpol_new.  This would happen if mempolicy was updated on
    the shared shmem file while the sp->lock has been dropped during the
    memory allocation.

    This issue could be triggered easily with the below code snippet if
    there are many processes doing the below work at the same time:

      shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT);
      shm = shmat(shmid, 0, 0);
      loop many times {
        mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0);
        mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask,
              maxnode, 0);
      }

    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 42288fe366c4 ("mm: mempolicy: Convert shared_policy mutex to spinlock")
    Signed-off-by: Miaohe Lin <[email protected]>
    Acked-by: Michal Hocko <[email protected]>
    Cc: KOSAKI Motohiro <[email protected]>
    Cc: Mel Gorman <[email protected]>
    Cc: <[email protected]>	[3.8]
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e2c328c2a8f9de8b761bd4025b66c63120c55761
Author: Paolo Bonzini <[email protected]>
Date:   Fri Apr 8 13:09:04 2022 -0700

    mmmremap.c: avoid pointless invalidate_range_start/end on mremap(old_size=0)

    commit 01e67e04c28170c47700c2c226d732bbfedb1ad0 upstream.

    If an mremap() syscall with old_size=0 ends up in move_page_tables(), it
    will call invalidate_range_start()/invalidate_range_end() unnecessarily,
    i.e.  with an empty range.

    This causes a WARN in KVM's mmu_notifier.  In the past, empty ranges
    have been diagnosed to be off-by-one bugs, hence the WARNing.  Given the
    low (so far) number of unique reports, the benefits of detecting more
    buggy callers seem to outweigh the cost of having to fix cases such as
    this one, where userspace is doing something silly.  In this particular
    case, an early return from move_page_tables() is enough to fix the
    issue.

    Link: https://lkml.kernel.org/r/[email protected]
    Reported-by: [email protected]
    Signed-off-by: Paolo Bonzini <[email protected]>
    Cc: Sean Christopherson <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 024fc7e2ea7fa2221f8535f04afc337be8e19d3d
Author: Wolfram Sang <[email protected]>
Date:   Mon Apr 4 13:49:02 2022 +0200

    mmc: renesas_sdhi: don't overwrite TAP settings when HS400 tuning is complete

    commit 03e59b1e2f56245163b14c69e0a830c24b1a3a47 upstream.

    When HS400 tuning is complete and HS400 is going to be activated, we
    have to keep the current number of TAPs and should not overwrite them
    with a hardcoded value. This was probably a copy&paste mistake when
    upporting HS400 support from the BSP.

    Fixes: 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support")
    Reported-by: Yoshihiro Shimoda <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Reviewed-by: Yoshihiro Shimoda <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 26c432a730fa54b3baafb07a44e0c3248c470336
Author: Pali Rohár <[email protected]>
Date:   Fri Mar 18 15:14:41 2022 +0100

    Revert "mmc: sdhci-xenon: fix annoying 1.8V regulator warning"

    commit 7e2646ed47542123168d43916b84b954532e5386 upstream.

    This reverts commit bb32e1987bc55ce1db400faf47d85891da3c9b9f.

    Commit 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization")
    contains proper fix for the issue described in commit bb32e1987bc5 ("mmc:
    sdhci-xenon: fix annoying 1.8V regulator warning").

    Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable")
    Cc: [email protected] # 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization")
    Signed-off-by: Pali Rohár <[email protected]>
    Reviewed-by: Marek Behún <[email protected]>
    Reviewed-by: Marcin Wojtas <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 188fe6b26765edbad4055611c0f788b6870f4024
Author: Lv Yunlong <[email protected]>
Date:   Wed Apr 6 21:04:43 2022 +0200

    drbd: Fix five use after free bugs in get_initial_state

    [ Upstream commit aadb22ba2f656581b2f733deb3a467c48cc618f6 ]

    In get_initial_state, it calls notify_initial_state_done(skb,..) if
    cb->args[5]==1. If genlmsg_put() failed in notify_initial_state_done(),
    the skb will be freed by nlmsg_free(skb).
    Then get_initial_state will goto out and the freed skb will be used by
    return value skb->len, which is a uaf bug.

    What's worse, the same problem goes even further: skb can also be
    freed in the notify_*_state_change -> notify_*_state calls below.
    Thus 4 additional uaf bugs happened.

    My patch lets the problem callee functions: notify_initial_state_done
    and notify_*_state_change return an error code if errors happen.
    So that the error codes could be propagated and the uaf bugs can be avoid.

    v2 reports a compilation warning. This v3 fixed this warning and built
    successfully in my local environment with no additional warnings.
    v2: https://lore.kernel.org/patchwork/patch/1435218/

    Fixes: a29728463b254 ("drbd: Backport the "events2" command")
    Signed-off-by: Lv Yunlong <[email protected]>
    Reviewed-by: Christoph Böhmwalder <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit e4f970dabff6b39777be72818407892df0b84ce0
Author: Kamal Dasu <[email protected]>
Date:   Mon Mar 28 10:24:42 2022 -0400

    spi: bcm-qspi: fix MSPI only access with bcm_qspi_exec_mem_op()

    [ Upstream commit 2c7d1b281286c46049cd22b43435cecba560edde ]

    This fixes case where MSPI controller is used to access spi-nor
    flash and BSPI block is not present.

    Fixes: 5f195ee7d830 ("spi: bcm-qspi: Implement the spi_mem interface")
    Signed-off-by: Kamal Dasu <[email protected]>
    Acked-by: Florian Fainelli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 9648adb1b3ece55c657d3a4f52bfee663b710dfe
Author: Jamie Bainbridge <[email protected]>
Date:   Wed Apr 6 21:19:19 2022 +1000

    qede: confirm skb is allocated before using

    [ Upstream commit 4e910dbe36508654a896d5735b318c0b88172570 ]

    qede_build_skb() assumes build_skb() always works and goes straight
    to skb_reserve(). However, build_skb() can fail under memory pressure.
    This results in a kernel panic because the skb to reserve is NULL.

    Add a check in case build_skb() failed to allocate and return NULL.

    The NULL return is handled correctly in callers to qede_build_skb().

    Fixes: 8a8633978b842 ("qede: Add build_skb() support.")
    Signed-off-by: Jamie Bainbridge <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 864297ee30727ae6233f80296b7fc91442620b05
Author: Eric Dumazet <[email protected]>
Date:   Mon Apr 4 11:34:39 2022 -0700

    rxrpc: fix a race in rxrpc_exit_net()

    [ Upstream commit 1946014ca3b19be9e485e780e862c375c6f98bad ]

    Current code can lead to the following race:

    CPU0                                                 CPU1

    rxrpc_exit_net()
                                                         rxrpc_peer_keepalive_worker()
                                                           if (rxnet->live)

      rxnet->live = false;
      del_timer_sync(&rxnet->peer_keepalive_timer);

                                                                 timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay);

      cancel_work_sync(&rxnet->peer_keepalive_work);

    rxrpc_exit_net() exits while peer_keepalive_timer is still armed,
    leading to use-after-free.

    syzbot report was:

    ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0
    WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505
    Modules linked in:
    CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: netns cleanup_net
    RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505
    Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3
    RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082
    RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
    RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52
    RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
    R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0
    R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000
    FS:  0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     __debug_check_no_obj_freed lib/debugobjects.c:992 [inline]
     debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023
     kfree+0xd6/0x310 mm/slab.c:3809
     ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176
     ops_free_list net/core/net_namespace.c:174 [inline]
     cleanup_net+0x591/0xb00 net/core/net_namespace.c:598
     process_one_work+0x996/0x1610 kernel/workqueue.c:2289
     worker_thread+0x665/0x1080 kernel/workqueue.c:2436
     kthread+0x2e9/0x3a0 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298
     </TASK>

    Fixes: ace45bec6d77 ("rxrpc: Fix firewall route keepalive")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: David Howells <[email protected]>
    Cc: Marc Dionne <[email protected]>
    Cc: [email protected]
    Reported-by: syzbot <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 315ed6da7ff7fd8de8abda1b6dcbea3a4754522a
Author: Ilya Maximets <[email protected]>
Date:   Mon Apr 4 12:41:50 2022 +0200

    net: openvswitch: don't send internal clone attribute to the userspace.

    [ Upstream commit 3f2a3050b4a3e7f32fc0ea3c9b0183090ae00522 ]

    'OVS_CLONE_ATTR_EXEC' is an internal attribute that is used for
    performance optimization inside the kernel.  It's added by the kernel
    while parsing user-provided actions and should not be sent during the
    flow dump as it's not part of the uAPI.

    The issue doesn't cause any significant problems to the ovs-vswitchd
    process, because reported actions are not really used in the
    application lifecycle and only supposed to be shown to a human via
    ovs-dpctl flow dump.  However, the action list is still incorrect
    and causes the following error if the user wants to look at the
    datapath flows:

      # ovs-dpctl add-dp system@ovs-system
      # ovs-dpctl add-flow "<flow match>" "clone(ct(commit),0)"
      # ovs-dpctl dump-flows
      <flow match>, packets:0, bytes:0, used:never,
        actions:clone(bad length 4, expected -1 for: action0(01 00 00 00),
                      ct(commit),0)

    With the fix:

      # ovs-dpctl dump-flows
      <flow match>, packets:0, bytes:0, used:never,
        actions:clone(ct(commit),0)

    Additionally fixed an incorrect attribute name in the comment.

    Fixes: b233504033db ("openvswitch: kernel datapath clone action")
    Signed-off-by: Ilya Maximets <[email protected]>
    Acked-by: Aaron Conole <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 41624d7c0c3df71dee170c610744aaa5909327b8
Author: José Expósito <[email protected]>
Date:   Sat Jan 8 17:52:30 2022 +0100

    drm/imx: Fix memory leak in imx_pd_connector_get_modes

    [ Upstream commit bce81feb03a20fca7bbdd1c4af16b4e9d5c0e1d3 ]

    Avoid leaking the display mode variable if of_get_drm_display_mode
    fails.

    Fixes: 76ecd9c9fb24 ("drm/imx: parallel-display: check return code from of_get_drm_display_mode()")
    Addresses-Coverity-ID: 1443943 ("Resource leak")
    Signed-off-by: José Expósito <[email protected]>
    Signed-off-by: Philipp Zabel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit 08c9f9bc1c25523455f1dcbbeb189aff983ec9d1
Author: Chen-Yu Tsai <[email protected]>
Date:   Fri Apr 1 02:48:32 2022 +0800

    net: stmmac: Fix unset max_speed difference between DT and non-DT platforms

    [ Upstream commit c21cabb0fd0b54b8b54235fc1ecfe1195a23bcb2 ]

    In commit 9cbadf094d9d ("net: stmmac: support max-speed device tree
    property"), when DT platforms don't set "max-speed", max_speed is set to
    -1; for non-DT platforms, it stays the default 0.

    Prior to commit eeef2f6b9f6e ("net: stmmac: Start adding phylink support"),
    the check for a valid max_speed setting was to check if it was greater
    than zero. This commit got it right, but subsequent patches just checked
    for non-zero, which is incorrect for DT platforms.

    In commit 92c3807b9ac3 ("net: stmmac: convert to phylink_get_linkmodes()")
    the conversion switched completely to checking for non-zero value as a
    valid value, which caused 1000base-T to stop getting advertised by
    default.

    Instead of trying to fix all the checks, simply leave max_speed alone if
    DT property parsing fails.

    Fixes: 9cbadf094d9d ("net: stmmac: support max-speed device tree property")
    Fixes: 92c3807b9ac3 ("net: stmmac: convert to phylink_get_linkmodes()")
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Acked-by: Russell King (Oracle) <[email protected]>
    Reviewed-by: Srinivas Kandagatla <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit db863ab2baf058ed05c7b723612e3c40c9dd6885
Author: Christophe JAILLET <[email protected]>
Date:   Sat Mar 19 08:01:24 2022 +0100

    scsi: zorro7xx: Fix a resource leak in zorro7xx_remove_one()

    [ Upstream commit 16ed828b872d12ccba8f07bcc446ae89ba662f9c ]

    The error handling path of the probe releases a resource that is not freed
    in the remove function. In some cases, a ioremap() must be undone.

    Add the missing iounmap() call in the remove function.

    Link: https://lore.kernel.org/r/247066a3104d25f9a05de8b3270fc3c848763bcc.1647673264.git.christophe.jaillet@wanadoo.fr
    Fixes: 45804fbb00ee ("[SCSI] 53c700: Amiga Zorro NCR53c710 SCSI")
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 6b4c0149a56147b29169e07000d566162892722a
Author: Guilherme G. Piccoli <[email protected]>
Date:   Tue Mar 15 17:35:35 2022 -0300

    Drivers: hv: vmbus: Fix potential crash on module unload

    [ Upstream commit 792f232d57ff28bbd5f9c4abe0466b23d5879dc8 ]

    The vmbus driver relies on the panic notifier infrastructure to perform
    some operations when a panic event is detected. Since vmbus can be built
    as module, it is required that the driver handles both registering and
    unregistering such panic notifier callback.

    After commit 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
    though, the panic notifier registration is done unconditionally in the module
    initialization routine whereas the unregistering procedure is conditionally
    guarded and executes only if HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE capability
    is set.

    This patch fixes that by unconditionally unregistering the panic notifier
    in the module's exit routine as well.

    Fixes: 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
    Signed-off-by: Guilherme G. Piccoli <[email protected]>
    Reviewed-by: Michael Kelley <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wei Liu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit a17d93c9088c1b7d7ec42ce25573b93544e19616
Author: Dan Carpenter <[email protected]>
Date:   Wed Mar 16 11:41:48 2022 +0300

    drm/amdgpu: fix off by one in amdgpu_gfx_kiq_acquire()

    [ Upstream commit 1647b54ed55d4d48c7199d439f8834626576cbe9 ]

    This post-op should be a pre-op so that we do not pass -1 as the bit
    number to test_bit().  The current code will loop downwards from 63 to
    -1.  After changing to a pre-op, it loops from 63 to 0.

    Fixes: 71c37505e7ea ("drm/amdgpu/gfx: move more common KIQ code to amdgpu_gfx.c")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 7aa0c5197ea0fb2346f21f32ce67f9557da8dba8
Author: James Morse <[email protected]>
Date:   Fri Apr 8 18:22:32 2022 +0100

    KVM: arm64: Check arm64_get_bp_hardening_data() didn't return NULL

    Will reports that with CONFIG_EXPERT=y and CONFIG_HARDEN_BRANCH_PREDICTOR=n,
    the kernel dereferences a NULL pointer during boot:

    [    2.384444] Internal error: Oops: 96000004 [#1] PREEMPT SMP
    [    2.384461] pstate: 20400085 (nzCv daIf +PAN -UAO)
    [    2.384472] pc : cpu_hyp_reinit+0x114/0x30c
    [    2.384476] lr : cpu_hyp_reinit+0x80/0x30c

    [    2.384529] Call trace:
    [    2.384533]  cpu_hyp_reinit+0x114/0x30c
    [    2.384537]  _kvm_arch_hardware_enable+0x30/0x54
    [    2.384541]  flush_smp_call_function_queue+0xe4/0x154
    [    2.384544]  generic_smp_call_function_single_interrupt+0x10/0x18
    [    2.384549]  ipi_handler+0x170/0x2b0
    [    2.384555]  handle_percpu_devid_fasteoi_ipi+0x120/0x1cc
    [    2.384560]  __handle_domain_irq+0x9c/0xf4
    [    2.384563]  gic_handle_irq+0x6c/0xe4
    [    2.384566]  el1_irq+0xf0/0x1c0
    [    2.384570]  arch_cpu_idle+0x28/0x44
    [    2.384574]  do_idle+0x100/0x2a8
    [    2.384577]  cpu_startup_entry+0x20/0x24
    [    2.384581]  secondary_start_kernel+0x1b0/0x1cc
    [    2.384589] Code: b9469d08 7100011f 540003ad 52800208 (f9400108)
    [    2.384600] ---[ end trace 266d08dbf96ff143 ]---
    [    2.385171] Kernel panic - not syncing: Fatal exception in interrupt

    In this configuration arm64_get_bp_hardening_data() returns NULL.
    Add a check in kvm_get_hyp_vector().

    Cc: Will Deacon <[email protected]>
    Link: https://lore.kernel.org/linux-arm-kernel/20220408120041.GB27685@willie-the-truck/
    Fixes: a68912a3ae3 ("KVM: arm64: Add templates for BHB mitigation sequences")
    Cc: [email protected] # 4.19
    Signed-off-by: James Morse <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit ef521626ac9f7e3b20eeb52b64a4f85992702c54
Author: Mauricio Faria de Oliveira <[email protected]>
Date:   Thu Apr 7 16:14:30 2022 -0300

    mm: fix race between MADV_FREE reclaim and blkdev direct IO read

    commit 6c8e2a256915a223f6289f651d6b926cd7135c9e upstream.

    Problem:
    =======

    Userspace might read the zero-page instead of actual data from a direct IO
    read on a block device if the buffers have been called madvise(MADV_FREE)
    on earlier (this is discussed below) due to a race between page reclaim on
    MADV_FREE and blkdev direct IO read.

    - Race condition:
      ==============

    During page reclaim, the MADV_FREE page check in try_to_unmap_one() checks
    if the page is not dirty, then discards its rmap PTE(s) (vs.  remap back
    if the page is dirty).

    However, after try_to_unmap_one() returns to shrink_page_list(), it might
    keep the page _anyway_ if page_ref_freeze() fails (it expects exactly
    _one_ page reference, from the isolation for page reclaim).

    Well, blkdev_direct_IO() gets references for all pages, and on READ
    operations it only sets them dirty _later_.

    So, if MADV_FREE'd pages (i.e., not dirty) are used as buffers for direct
    IO read from block devices, and page reclaim happens during
    __blkdev_direct_IO[_simple]() exactly AFTER bio_iov_iter_get_pages()
    returns, but BEFORE the pages are set dirty, the situation happens.

    The direct IO read eventually completes.  Now, when userspace reads the
    buffers, the PTE is no longer there and the page fault handler
    do_anonymous_page() services that with the zero-page, NOT the data!

    A synthetic reproducer is provided.

    - Page faults:
      ===========

    If page reclaim happens BEFORE bio_iov_iter_get_pages() the issue doesn't
    happen, because that faults-in all pages as writeable, so
    do_anonymous_page() sets up a new page/rmap/PTE, and that is used by
    direct IO.  The userspace reads don't fault as the PTE is there (thus
    zero-page is not used/setup).

    But if page reclaim happens AFTER it / BEFORE setting pages dirty, the PTE
    is no longer there; the subsequent page faults can't help:

    The data-read from the block device probably won't generate faults due to
    DMA (no MMU) but even in the case it wouldn't use DMA, that happens on
    different virtual addresses (not user-mapped addresses) because `struct
    bio_vec` stores `struct page` to figure addresses out (which are different
    from user-mapped addresses) for the read.

    Thus userspace reads (to user-mapped addresses) still fault, then
    do_anonymous_page() gets another `struct page` that would address/ map to
    other memory than the `struct page` used by `struct bio_vec` for the read.
    (The original `struct page` is not available, since it wasn't freed, as
    page_ref_freeze() failed due to more page refs.  And even if it were
    available, its data cannot be trusted anymore.)

    Solution:
    ========

    One solution is to check for the expected page reference count in
    try_to_unmap_one().

    There should be one reference from the isolation (that is also checked in
    shrink_page_list() with page_ref_freeze()) plus one or more references
    from page mapping(s) (put in discard: label).  Further references mean
    that rmap/PTE cannot be unmapped/nuked.

    (Note: there might be more than one reference from mapping due to
    fork()/clone() without CLONE_VM, which use the same `struct page` for
    references, until the copy-on-write page gets copied.)

    So, additional page references (e.g., from direct IO read) now prevent the
    rmap/PTE from being unmapped/dropped; similarly to the page is not freed
    per shrink_page_list()/page_ref_freeze()).

    - Races and Barriers:
      ==================

    The new check in try_to_unmap_one() should be safe in races with
    bio_iov_iter_get_pages() in get_user_pages() fast and slow paths, as it's
    done under the PTE lock.

    The fast path doesn't take the lock, but it checks if the PTE has changed
    and if so, it drops the reference and leaves the page for the slow path
    (which does take that lock).

    The fast path requires synchronization w/ full memory barrier: it writes
    the page reference count first then it reads the PTE later, while
    try_to_unmap() writes PTE first then it reads page refcount.

    And a second barrier is needed, as the page dirty flag should not be read
    before the page reference count (as in __remove_mapping()).  (This can be
    a load memory barrier only; no writes are involved.)

    Call stack/comments:

    - try_to_unmap_one()
      - page_vma_mapped_walk()
        - map_pte()			# see pte_offset_map_lock():
            pte_offset_map()
            spin_lock()

      - ptep_get_and_clear()	# write PTE
      - smp_mb()			# (new barrier) GUP fast path
      - page_ref_count()		# (new check) read refcount

      - page_vma_mapped_walk_done()	# see pte_unmap_unlock():
          pte_unmap()
          spin_unlock()

    - bio_iov_iter_get_pages()
      - __bio_iov_iter_get_pages()
        - iov_iter_get_pages()
          - get_user_pages_fast()
            - internal_get_user_pages_fast()

              # fast path
              - lockless_pages_from_mm()
                - gup_{pgd,p4d,pud,pmd,pte}_range()
                    ptep = pte_offset_map()		# not _lock()
                    pte = ptep_get_lockless(ptep)

                    page = pte_page(pte)
                    try_grab_compound_head(page)	# inc refcount
                                                	# (RMW/barrier
                                                 	#  on success)

                    if (pte_val(pte) != pte_val(*ptep)) # read PTE
                            put_compound…
ZenkaBestia added a commit to NusantaraROM-Devices/kernel_xiaomi_lmi that referenced this pull request May 14, 2022
Squashed commit of the following:

commit 860d1d0d4b2dbf121af35fe6e55a4404db73e214
Merge: a4206df2a09e4 aaad8e56ca1e5
Author: ZenkaBestia <[email protected]>
Date:   Sat May 14 11:05:31 2022 +0000

    Merge tag 'v4.19.238' into 12-up

    This is the 4.19.238 stable release
    from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

    Conflicts:
    	block/bfq-iosched.c
    	drivers/irqchip/irq-gic-v3.c
    	drivers/irqchip/qcom-pdc.c
    	drivers/mmc/core/host.c
    	drivers/usb/host/xhci.c
    	drivers/usb/host/xhci.h
    	include/linux/pci.h

commit a4206df2a09e4b2446d5218437eddca97317f93d
Merge: 4952c26d5d2d3 a6e4a1818efa7
Author: ZenkaBestia <[email protected]>
Date:   Sat May 14 08:55:05 2022 +0000

    Merge tag 'v4.19.237' into 12-up

    This is the 4.19.237 stable release
    from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

    Signed-off-by: ZenkaBestia <[email protected]>

    Conflicts:
    	drivers/nfc/st21nfca/se.c

commit aaad8e56ca1e56fe34b5a33f30fb6f9279969020
Author: Greg Kroah-Hartman <[email protected]>
Date:   Fri Apr 15 14:15:08 2022 +0200

    Linux 4.19.238

    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Pavel Machek (CIP) <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Hulk Robot <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7faf003b58812c33e3b5315683e85d57b5ec4e3f
Author: Felix Kuehling <[email protected]>
Date:   Wed Apr 7 18:19:58 2021 -0400

    drm/amdkfd: Use drm_priv to pass VM from KFD to amdgpu

    commit b40a6ab2cf9213923bf8e821ce7fa7f6a0a26990 upstream.

    amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu needs the drm_priv to allow mmap
    to access the BO through the corresponding file descriptor. The VM can
    also be extracted from drm_priv, so drm_priv can replace the vm parameter
    in the kfd2kgd interface.

    Signed-off-by: Felix Kuehling <[email protected]>
    Reviewed-by: Philip Yang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    [ This is a partial cherry-pick of the commit. ]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f08fb393786d64a97a48bd038e68aec310c31297
Author: Bas Nieuwenhuizen <[email protected]>
Date:   Wed Jan 30 02:53:21 2019 +0100

    drm/amdgpu: Check if fd really is an amdgpu fd.

    commit 021830d24ba55a578f602979274965344c8e6284 upstream.

    Otherwise we interpret the file private data as drm & amdgpu data
    while it might not be, possibly allowing one to get memory corruption.

    Signed-off-by: Bas Nieuwenhuizen <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 00cdc297e219798a43bf55a8b1b1df6b6285c8e6
Author: Xin Long <[email protected]>
Date:   Mon Jun 22 16:40:29 2020 +0800

    xfrm: policy: match with both mark and mask on user interfaces

    commit 4f47e8ab6ab796b5380f74866fa5287aca4dcc58 upstream.

    In commit ed17b8d377ea ("xfrm: fix a warning in xfrm_policy_insert_list"),
    it would take 'priority' to make a policy unique, and allow duplicated
    policies with different 'priority' to be added, which is not expected
    by userland, as Tobias reported in strongswan.

    To fix this duplicated policies issue, and also fix the issue in
    commit ed17b8d377ea ("xfrm: fix a warning in xfrm_policy_insert_list"),
    when doing add/del/get/update on user interfaces, this patch is to change
    to look up a policy with both mark and mask by doing:

      mark.v == pol->mark.v && mark.m == pol->mark.m

    and leave the check:

      (mark & pol->mark.m) == pol->mark.v

    for tx/rx path only.

    As the userland expects an exact mark and mask match to manage policies.

    v1->v2:
      - make xfrm_policy_mark_match inline and fix the changelog as
        Tobias suggested.

    Fixes: 295fae568885 ("xfrm: Allow user space manipulation of SPD mark")
    Fixes: ed17b8d377ea ("xfrm: fix a warning in xfrm_policy_insert_list")
    Reported-by: Tobias Brunner <[email protected]>
    Tested-by: Tobias Brunner <[email protected]>
    Signed-off-by: Xin Long <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 86be2e7111e20b6b57850e9d203276c89af117da
Author: Tejun Heo <[email protected]>
Date:   Thu Apr 14 12:07:00 2022 +0300

    selftests: cgroup: Test open-time cgroup namespace usage for migration checks

    commit bf35a7879f1dfb0d050fe779168bcf25c7de66f5 upstream.

    When a task is writing to an fd opened by a different task, the perm check
    should use the cgroup namespace of the latter task. Add a test for it.

    Tested-by: Michal Koutný <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    [OP: backport to v4.19: adjust context, add wait.h and fcntl.h includes]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 81c22cf89126ae52e7751b0bb11e1c54e72c3a88
Author: Tejun Heo <[email protected]>
Date:   Thu Apr 14 12:06:59 2022 +0300

    selftests: cgroup: Test open-time credential usage for migration checks

    commit 613e040e4dc285367bff0f8f75ea59839bc10947 upstream.

    When a task is writing to an fd opened by a different task, the perm check
    should use the credentials of the latter task. Add a test for it.

    Tested-by: Michal Koutný <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    [OP: backport to v4.19: adjust context]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 135117aa4055e13cd7c47e61093b5f1a15901fb3
Author: Tejun Heo <[email protected]>
Date:   Thu Apr 14 12:06:58 2022 +0300

    selftests: cgroup: Make cg_create() use 0755 for permission instead of 0644

    commit b09c2baa56347ae65795350dfcc633dedb1c2970 upstream.

    0644 is an odd perm to create a cgroup which is a directory. Use the regular
    0755 instead. This is necessary for euid switching test case.

    Reviewed-by: Michal Koutný <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    [OP: backport to 4.19: adjust context]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 74ac12c718e7d3f7eb346ee90a4c9904a8b6b6d2
Author: Tejun Heo <[email protected]>
Date:   Thu Apr 14 12:06:57 2022 +0300

    cgroup: Use open-time cgroup namespace for process migration perm checks

    commit e57457641613fef0d147ede8bd6a3047df588b95 upstream.

    cgroup process migration permission checks are performed at write time as
    whether a given operation is allowed or not is dependent on the content of
    the write - the PID. This currently uses current's cgroup namespace which is
    a potential security weakness as it may allow scenarios where a less
    privileged process tricks a more privileged one into writing into a fd that
    it created.

    This patch makes cgroup remember the cgroup namespace at the time of open
    and uses it for migration permission checks instad of current's. Note that
    this only applies to cgroup2 as cgroup1 doesn't have namespace support.

    This also fixes a use-after-free bug on cgroupns reported in

     https://lore.kernel.org/r/[email protected]

    Note that backporting this fix also requires the preceding patch.

    Reported-by: "Eric W. Biederman" <[email protected]>
    Suggested-by: Linus Torvalds <[email protected]>
    Cc: Michal Koutný <[email protected]>
    Cc: Oleg Nesterov <[email protected]>
    Reviewed-by: Michal Koutný <[email protected]>
    Reported-by: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 5136f6365ce3 ("cgroup: implement "nsdelegate" mount option")
    Signed-off-by: Tejun Heo <[email protected]>
    [mkoutny: v5.10: duplicate ns check in procs/threads write handler, adjust context]
    Signed-off-by: Michal Koutný <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    [OP: backport to v4.19: drop changes to cgroup_attach_permissions() and
    cgroup_css_set_fork(), adjust cgroup_procs_write_permission() calls]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit de37e01dd20e3228b010fe5fbd3e205747481b96
Author: Tejun Heo <[email protected]>
Date:   Thu Apr 14 12:06:56 2022 +0300

    cgroup: Allocate cgroup_file_ctx for kernfs_open_file->priv

    commit 0d2b5955b36250a9428c832664f2079cbf723bec upstream.

    of->priv is currently used by each interface file implementation to store
    private information. This patch collects the current two private data usages
    into struct cgroup_file_ctx which is allocated and freed by the common path.
    This allows generic private data which applies to multiple files, which will
    be used to in the following patch.

    Note that cgroup_procs iterator is now embedded as procs.iter in the new
    cgroup_file_ctx so that it doesn't need to be allocated and freed
    separately.

    v2: union dropped from cgroup_file_ctx and the procs iterator is embedded in
        cgroup_file_ctx as suggested by Linus.

    v3: Michal pointed out that cgroup1's procs pidlist uses of->priv too.
        Converted. Didn't change to embedded allocation as cgroup1 pidlists get
        stored for caching.

    Signed-off-by: Tejun Heo <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Reviewed-by: Michal Koutný <[email protected]>
    [mkoutny: v5.10: modify cgroup.pressure handlers, adjust context]
    Signed-off-by: Michal Koutný <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    [OP: backport to v4.19: drop changes to cgroup_pressure_*() functions]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0bd407959f7d6671ba0617e2dbda3e89d8a0419f
Author: Tejun Heo <[email protected]>
Date:   Thu Apr 14 12:06:55 2022 +0300

    cgroup: Use open-time credentials for process migraton perm checks

    commit 1756d7994ad85c2479af6ae5a9750b92324685af upstream.

    cgroup process migration permission checks are performed at write time as
    whether a given operation is allowed or not is dependent on the content of
    the write - the PID. This currently uses current's credentials which is a
    potential security weakness as it may allow scenarios where a less
    privileged process tricks a more privileged one into writing into a fd that
    it created.

    This patch makes both cgroup2 and cgroup1 process migration interfaces to
    use the credentials saved at the time of open (file->f_cred) instead of
    current's.

    Reported-by: "Eric W. Biederman" <[email protected]>
    Suggested-by: Linus Torvalds <[email protected]>
    Fixes: 187fe84067bd ("cgroup: require write perm on common ancestor when moving processes on the default hierarchy")
    Reviewed-by: Michal Koutný <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    [OP: backport to v4.19: apply original __cgroup_procs_write() changes to
    cgroup_threads_write() and cgroup_procs_write()]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ff929e3abef16c409a9beef08bcc29ab940d0ce6
Author: Waiman Long <[email protected]>
Date:   Fri Apr 8 13:09:01 2022 -0700

    mm/sparsemem: fix 'mem_section' will never be NULL gcc 12 warning

    commit a431dbbc540532b7465eae4fc8b56a85a9fc7d17 upstream.

    The gcc 12 compiler reports a "'mem_section' will never be NULL" warning
    on the following code:

        static inline struct mem_section *__nr_to_section(unsigned long nr)
        {
        #ifdef CONFIG_SPARSEMEM_EXTREME
            if (!mem_section)
                    return NULL;
        #endif
            if (!mem_section[SECTION_NR_TO_ROOT(nr)])
                    return NULL;
           :

    It happens with CONFIG_SPARSEMEM_EXTREME off.  The mem_section definition
    is

        #ifdef CONFIG_SPARSEMEM_EXTREME
        extern struct mem_section **mem_section;
        #else
        extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT];
        #endif

    In the !CONFIG_SPARSEMEM_EXTREME case, mem_section is a static
    2-dimensional array and so the check "!mem_section[SECTION_NR_TO_ROOT(nr)]"
    doesn't make sense.

    Fix this warning by moving the "!mem_section[SECTION_NR_TO_ROOT(nr)]"
    check up inside the CONFIG_SPARSEMEM_EXTREME block and adding an
    explicit NR_SECTION_ROOTS check to make sure that there is no
    out-of-bound array access.

    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 3e347261a80b ("sparsemem extreme implementation")
    Signed-off-by: Waiman Long <[email protected]>
    Reported-by: Justin Forbes <[email protected]>
    Cc: "Kirill A . Shutemov" <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Rafael Aquini <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 634a959641b413bf831870cbf544443f6f47c141
Author: Fangrui Song <[email protected]>
Date:   Fri Feb 18 00:12:09 2022 -0800

    arm64: module: remove (NOLOAD) from linker script

    commit 4013e26670c590944abdab56c4fa797527b74325 upstream.

    On ELF, (NOLOAD) sets the section type to SHT_NOBITS[1]. It is conceptually
    inappropriate for .plt and .text.* sections which are always
    SHT_PROGBITS.

    In GNU ld, if PLT entries are needed, .plt will be SHT_PROGBITS anyway
    and (NOLOAD) will be essentially ignored. In ld.lld, since
    https://reviews.llvm.org/D118840 ("[ELF] Support (TYPE=<value>) to
    customize the output section type"), ld.lld will report a `section type
    mismatch` error. Just remove (NOLOAD) to fix the error.

    [1] https://lld.llvm.org/ELF/linker_script.html As of today, "The
    section should be marked as not loadable" on
    https://sourceware.org/binutils/docs/ld/Output-Section-Type.html is
    outdated for ELF.

    Tested-by: Nathan Chancellor <[email protected]>
    Reported-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Fangrui Song <[email protected]>
    Acked-by: Ard Biesheuvel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    [nathan: Fix conflicts due to lack of 596b0474d3d9]
    Signed-off-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7265c880004d30691ea3715ce0eaf6ef3ce5d445
Author: Peter Xu <[email protected]>
Date:   Tue Mar 22 14:42:15 2022 -0700

    mm: don't skip swap entry even if zap_details specified

    commit 5abfd71d936a8aefd9f9ccd299dea7a164a5d455 upstream.

    Patch series "mm: Rework zap ptes on swap entries", v5.

    Patch 1 should fix a long standing bug for zap_pte_range() on
    zap_details usage.  The risk is we could have some swap entries skipped
    while we should have zapped them.

    Migration entries are not the major concern because file backed memory
    always zap in the pattern that "first time without page lock, then
    re-zap with page lock" hence the 2nd zap will always make sure all
    migration entries are already recovered.

    However there can be issues with real swap entries got skipped
    errornoously.  There's a reproducer provided in commit message of patch
    1 for that.

    Patch 2-4 are cleanups that are based on patch 1.  After the whole
    patchset applied, we should have a very clean view of zap_pte_range().

    Only patch 1 needs to be backported to stable if necessary.

    This patch (of 4):

    The "details" pointer shouldn't be the token to decide whether we should
    skip swap entries.

    For example, when the callers specified details->zap_mapping==NULL, it
    means the user wants to zap all the pages (including COWed pages), then
    we need to look into swap entries because there can be private COWed
    pages that was swapped out.

    Skipping some swap entries when details is non-NULL may lead to wrongly
    leaving some of the swap entries while we should have zapped them.

    A reproducer of the problem:

    ===8<===
            #define _GNU_SOURCE         /* See feature_test_macros(7) */
            #include <stdio.h>
            #include <assert.h>
            #include <unistd.h>
            #include <sys/mman.h>
            #include <sys/types.h>

            int page_size;
            int shmem_fd;
            char *buffer;

            void main(void)
            {
                    int ret;
                    char val;

                    page_size = getpagesize();
                    shmem_fd = memfd_create("test", 0);
                    assert(shmem_fd >= 0);

                    ret = ftruncate(shmem_fd, page_size * 2);
                    assert(ret == 0);

                    buffer = mmap(NULL, page_size * 2, PROT_READ | PROT_WRITE,
                                    MAP_PRIVATE, shmem_fd, 0);
                    assert(buffer != MAP_FAILED);

                    /* Write private page, swap it out */
                    buffer[page_size] = 1;
                    madvise(buffer, page_size * 2, MADV_PAGEOUT);

                    /* This should drop private buffer[page_size] already */
                    ret = ftruncate(shmem_fd, page_size);
                    assert(ret == 0);
                    /* Recover the size */
                    ret = ftruncate(shmem_fd, page_size * 2);
                    assert(ret == 0);

                    /* Re-read the data, it should be all zero */
                    val = buffer[page_size];
                    if (val == 0)
                            printf("Good\n");
                    else
                            printf("BUG\n");
            }
    ===8<===

    We don't need to touch up the pmd path, because pmd never had a issue with
    swap entries.  For example, shmem pmd migration will always be split into
    pte level, and same to swapping on anonymous.

    Add another helper should_zap_cows() so that we can also check whether we
    should zap private mappings when there's no page pointer specified.

    This patch drops that trick, so we handle swap ptes coherently.  Meanwhile
    we should do the same check upon migration entry, hwpoison entry and
    genuine swap entries too.

    To be explicit, we should still remember to keep the private entries if
    even_cows==false, and always zap them when even_cows==true.

    The issue seems to exist starting from the initial commit of git.

    [[email protected]: comment tweaks]
      Link: https://lkml.kernel.org/r/[email protected]

    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Peter Xu <[email protected]>
    Reviewed-by: John Hubbard <[email protected]>
    Cc: David Hildenbrand <[email protected]>
    Cc: Hugh Dickins <[email protected]>
    Cc: Alistair Popple <[email protected]>
    Cc: Andrea Arcangeli <[email protected]>
    Cc: "Kirill A . Shutemov" <[email protected]>
    Cc: Matthew Wilcox <[email protected]>
    Cc: Vlastimil Babka <[email protected]>
    Cc: Yang Shi <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2ea1bc78fba954980873c2d05c3ea4707828ee0f
Author: Vinod Koul <[email protected]>
Date:   Thu Mar 10 10:13:20 2022 +0530

    dmaengine: Revert "dmaengine: shdma: Fix runtime PM imbalance on error"

    commit d143f939a95696d38ff800ada14402fa50ebbd6c upstream.

    This reverts commit 455896c53d5b ("dmaengine: shdma: Fix runtime PM
    imbalance on error") as the patch wrongly reduced the count on error and
    did not bail out. So drop the count by reverting the patch .

    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c3cd98867a9df56a78ddb8ae413df17df84d9998
Author: Arnaldo Carvalho de Melo <[email protected]>
Date:   Mon Apr 4 17:28:48 2022 -0300

    tools build: Use $(shell ) instead of `` to get embedded libperl's ccopts

    commit 541f695cbcb6932c22638b06e0cbe1d56177e2e9 upstream.

    Just like its done for ldopts and for both in tools/perf/Makefile.config.

    Using `` to initialize PERL_EMBED_CCOPTS somehow precludes using:

      $(filter-out SOMETHING_TO_FILTER,$(PERL_EMBED_CCOPTS))

    And we need to do it to allow for building with versions of clang where
    some gcc options selected by distros are not available.

    Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
    Cc: Adrian Hunter <[email protected]>
    Cc: Fangrui Song <[email protected]>
    Cc: Florian Fainelli <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: John Keeping <[email protected]>
    Cc: Leo Yan <[email protected]>
    Cc: Michael Petlan <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Nathan Chancellor <[email protected]>
    Cc: Nick Desaulniers <[email protected]>
    Link: http://lore.kernel.org/lkml/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1236257a91bafcd8dc3984c585e84a4986d95de7
Author: Arnaldo Carvalho de Melo <[email protected]>
Date:   Tue Apr 5 10:33:21 2022 -0300

    tools build: Filter out options and warnings not supported by clang

    commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

    These make the feature check fail when using clang, so remove them just
    like is done in tools/perf/Makefile.config to build perf itself.

    Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
    when building with clang is also necessary to avoid these warnings
    turned into errors (-Werror):

        CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
      In file included from util/scripting-engines/trace-event-perl.c:35:
      In file included from /usr/lib64/perl5/CORE/perl.h:4085:
      In file included from /usr/lib64/perl5/CORE/hv.h:659:
      In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
      In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
      /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
          ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                           ^~~~~~~~~~
      /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
      #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                    ^
      /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
          ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                      ^
      /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
          ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
          v ^= (v>>23);                       \
                                              ^
      /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
          ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      } STMT_END
        ^~~~~~~~
      /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
      #   define STMT_END     )
                              ^

    Please refer to the discussion on the Link: tag below, where Nathan
    clarifies the situation:

    <quote>
    acme> And then get to the problems at the end of this message, which seem
    acme> similar to the problem described here:
    acme>
    acme> From  Nathan Chancellor <>
    acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
    acme>
    acme> https://lkml.org/lkml/2020/9/1/135
    acme>
    acme> So perhaps in this case its better to disable that
    acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

    Yes, I think that is probably the best solution. As far as I can tell,
    at least in this file and context, the warning appears harmless, as the
    "create a GNU C statement expression from two different macros" is very
    much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
    The warning is fixed in upstream Perl by just avoiding creating GNU C
    statement expressions using STMT_START and STMT_END:

      https://github.com/Perl/perl5/issues/18780
      https://github.com/Perl/perl5/pull/18984

    If I am reading the source code correctly, an alternative to disabling
    the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
    seems like that might end up impacting more than just this site,
    according to the issue discussion above.
    </quote>

    Based-on-a-patch-by: Sedat Dilek <[email protected]>
    Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
    Cc: Adrian Hunter <[email protected]>
    Cc: Fangrui Song <[email protected]>
    Cc: Florian Fainelli <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: John Keeping <[email protected]>
    Cc: Leo Yan <[email protected]>
    Cc: Michael Petlan <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Nathan Chancellor <[email protected]>
    Cc: Nick Desaulniers <[email protected]>
    Link: http://lore.kernel.org/lkml/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c7daf1b4ad809692d5c26f33c02ed8a031066548
Author: Marc Zyngier <[email protected]>
Date:   Tue Mar 15 16:50:32 2022 +0000

    irqchip/gic-v3: Fix GICR_CTLR.RWP polling

    commit 0df6664531a12cdd8fc873f0cac0dcb40243d3e9 upstream.

    It turns out that our polling of RWP is totally wrong when checking
    for it in the redistributors, as we test the *distributor* bit index,
    whereas it is a different bit number in the RDs... Oopsie boo.

    This is embarassing. Not only because it is wrong, but also because
    it took *8 years* to notice the blunder...

    Just fix the damn thing.

    Fixes: 021f653791ad ("irqchip: gic-v3: Initial support for GICv3")
    Signed-off-by: Marc Zyngier <[email protected]>
    Cc: [email protected]
    Reviewed-by: Andre Przywara <[email protected]>
    Reviewed-by: Lorenzo Pieralisi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit cbe2c848042af25345fee541692b0baf61e7c049
Author: Xiaomeng Tong <[email protected]>
Date:   Sun Mar 27 13:57:33 2022 +0800

    perf: qcom_l2_pmu: fix an incorrect NULL check on list iterator

    commit 2012a9e279013933885983cbe0a5fe828052563b upstream.

    The bug is here:
    	return cluster;

    The list iterator value 'cluster' will *always* be set and non-NULL
    by list_for_each_entry(), so it is incorrect to assume that the
    iterator value will be NULL if the list is empty or no element
    is found.

    To fix the bug, return 'cluster' when found, otherwise return NULL.

    Cc: [email protected]
    Fixes: 21bdbb7102ed ("perf: add qcom l2 cache perf events driver")
    Signed-off-by: Xiaomeng Tong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 596c7efd69aae94f4b0e91172b075eb197958b99
Author: Christian Lamparter <[email protected]>
Date:   Sat Mar 19 21:11:02 2022 +0100

    ata: sata_dwc_460ex: Fix crash due to OOB write

    commit 7aa8104a554713b685db729e66511b93d989dd6a upstream.

    the driver uses libata's "tag" values from in various arrays.
    Since the mentioned patch bumped the ATA_TAG_INTERNAL to 32,
    the value of the SATA_DWC_QCMD_MAX needs to account for that.

    Otherwise ATA_TAG_INTERNAL usage cause similar crashes like
    this as reported by Tice Rex on the OpenWrt Forum and
    reproduced (with symbols) here:

    | BUG: Kernel NULL pointer dereference at 0x00000000
    | Faulting instruction address: 0xc03ed4b8
    | Oops: Kernel access of bad area, sig: 11 [#1]
    | BE PAGE_SIZE=4K PowerPC 44x Platform
    | CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0
    | NIP:  c03ed4b8 LR: c03d27e8 CTR: c03ed36c
    | REGS: cfa59950 TRAP: 0300   Not tainted  (5.4.163)
    | MSR:  00021000 <CE,ME>  CR: 42000222  XER: 00000000
    | DEAR: 00000000 ESR: 00000000
    | GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...]
    | [..]
    | NIP [c03ed4b8] sata_dwc_qc_issue+0x14c/0x254
    | LR [c03d27e8] ata_qc_issue+0x1c8/0x2dc
    | Call Trace:
    | [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (unreliable)
    | [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc
    | [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524
    | [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0
    | [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204
    | [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130
    | [...]

    This is because sata_dwc_dma_xfer_complete() NULLs the
    dma_pending's next neighbour "chan" (a *dma_chan struct) in
    this '32' case right here (line ~735):
    > hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE;

    Then the next time, a dma gets issued; dma_dwc_xfer_setup() passes
    the NULL'd hsdevp->chan to the dmaengine_slave_config() which then
    causes the crash.

    With this patch, SATA_DWC_QCMD_MAX is now set to ATA_MAX_QUEUE + 1.
    This avoids the OOB. But please note, there was a worthwhile discussion
    on what ATA_TAG_INTERNAL and ATA_MAX_QUEUE is. And why there should not
    be a "fake" 33 command-long queue size.

    Ideally, the dw driver should account for the ATA_TAG_INTERNAL.
    In Damien Le Moal's words: "... having looked at the driver, it
    is a bigger change than just faking a 33rd "tag" that is in fact
    not a command tag at all."

    Fixes: 28361c403683c ("libata: add extra internal command")
    Cc: [email protected] # 4.18+
    BugLink: https://github.com/openwrt/openwrt/issues/9505
    Signed-off-by: Christian Lamparter <[email protected]>
    Signed-off-by: Damien Le Moal <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e5b0d0a5515f82ce151d192e2c6304f3f143bb56
Author: Guo Ren <[email protected]>
Date:   Thu Apr 7 15:33:20 2022 +0800

    arm64: patch_text: Fixup last cpu should be master

    commit 31a099dbd91e69fcab55eef4be15ed7a8c984918 upstream.

    These patch_text implementations are using stop_machine_cpuslocked
    infrastructure with atomic cpu_count. The original idea: When the
    master CPU patch_text, the others should wait for it. But current
    implementation is using the first CPU as master, which couldn't
    guarantee the remaining CPUs are waiting. This patch changes the
    last CPU as the master to solve the potential risk.

    Fixes: ae16480785de ("arm64: introduce interfaces to hotpatch kernel and module code")
    Signed-off-by: Guo Ren <[email protected]>
    Signed-off-by: Guo Ren <[email protected]>
    Reviewed-by: Catalin Marinas <[email protected]>
    Reviewed-by: Masami Hiramatsu <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f3d97b22a708bf9e3f3ac2ba232bcefd0b0c136b
Author: Ethan Lien <[email protected]>
Date:   Mon Mar 7 18:00:04 2022 +0800

    btrfs: fix qgroup reserve overflow the qgroup limit

    commit b642b52d0b50f4d398cb4293f64992d0eed2e2ce upstream.

    We use extent_changeset->bytes_changed in qgroup_reserve_data() to record
    how many bytes we set for EXTENT_QGROUP_RESERVED state. Currently the
    bytes_changed is set as "unsigned int", and it will overflow if we try to
    fallocate a range larger than 4GiB. The result is we reserve less bytes
    and eventually break the qgroup limit.

    Unlike regular buffered/direct write, which we use one changeset for
    each ordered extent, which can never be larger than 256M.  For
    fallocate, we use one changeset for the whole range, thus it no longer
    respects the 256M per extent limit, and caused the problem.

    The following example test script reproduces the problem:

      $ cat qgroup-overflow.sh
      #!/bin/bash

      DEV=/dev/sdj
      MNT=/mnt/sdj

      mkfs.btrfs -f $DEV
      mount $DEV $MNT

      # Set qgroup limit to 2GiB.
      btrfs quota enable $MNT
      btrfs qgroup limit 2G $MNT

      # Try to fallocate a 3GiB file. This should fail.
      echo
      echo "Try to fallocate a 3GiB file..."
      fallocate -l 3G $MNT/3G.file

      # Try to fallocate a 5GiB file.
      echo
      echo "Try to fallocate a 5GiB file..."
      fallocate -l 5G $MNT/5G.file

      # See we break the qgroup limit.
      echo
      sync
      btrfs qgroup show -r $MNT

      umount $MNT

    When running the test:

      $ ./qgroup-overflow.sh
      (...)

      Try to fallocate a 3GiB file...
      fallocate: fallocate failed: Disk quota exceeded

      Try to fallocate a 5GiB file...

      qgroupid         rfer         excl     max_rfer
      --------         ----         ----     --------
      0/5           5.00GiB      5.00GiB      2.00GiB

    Since we have no control of how bytes_changed is used, it's better to
    set it to u64.

    CC: [email protected] # 4.14+
    Reviewed-by: Qu Wenruo <[email protected]>
    Signed-off-by: Ethan Lien <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit edc7b755e8fce10009ac85bb234a035557301bc4
Author: Pawan Gupta <[email protected]>
Date:   Mon Apr 4 17:35:45 2022 -0700

    x86/speculation: Restore speculation related MSRs during S3 resume

    commit e2a1256b17b16f9b9adf1b6fea56819e7b68e463 upstream.

    After resuming from suspend-to-RAM, the MSRs that control CPU's
    speculative execution behavior are not being restored on the boot CPU.

    These MSRs are used to mitigate speculative execution vulnerabilities.
    Not restoring them correctly may leave the CPU vulnerable.  Secondary
    CPU's MSRs are correctly being restored at S3 resume by
    identify_secondary_cpu().

    During S3 resume, restore these MSRs for boot CPU when restoring its
    processor state.

    Fixes: 772439717dbf ("x86/bugs/intel: Set proper CPU features and setup RDS")
    Reported-by: Neelima Krishnan <[email protected]>
    Signed-off-by: Pawan Gupta <[email protected]>
    Tested-by: Neelima Krishnan <[email protected]>
    Acked-by: Borislav Petkov <[email protected]>
    Reviewed-by: Dave Hansen <[email protected]>
    Cc: [email protected]
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 11d692cb6c006372139eb373d469940d7a9108e1
Author: Pawan Gupta <[email protected]>
Date:   Mon Apr 4 17:34:19 2022 -0700

    x86/pm: Save the MSR validity status at context setup

    commit 73924ec4d560257004d5b5116b22a3647661e364 upstream.

    The mechanism to save/restore MSRs during S3 suspend/resume checks for
    the MSR validity during suspend, and only restores the MSR if its a
    valid MSR.  This is not optimal, as an invalid MSR will unnecessarily
    throw an exception for every suspend cycle.  The more invalid MSRs,
    higher the impact will be.

    Check and save the MSR validity at setup.  This ensures that only valid
    MSRs that are guaranteed to not throw an exception will be attempted
    during suspend.

    Fixes: 7a9c2dd08ead ("x86/pm: Introduce quirk framework to save/restore extra MSR registers around suspend/resume")
    Suggested-by: Dave Hansen <[email protected]>
    Signed-off-by: Pawan Gupta <[email protected]>
    Reviewed-by: Dave Hansen <[email protected]>
    Acked-by: Borislav Petkov <[email protected]>
    Cc: [email protected]
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 39a32f3c06f6d68a530bf9612afa19f50f12e93d
Author: Miaohe Lin <[email protected]>
Date:   Fri Apr 8 13:09:07 2022 -0700

    mm/mempolicy: fix mpol_new leak in shared_policy_replace

    commit 4ad099559b00ac01c3726e5c95dc3108ef47d03e upstream.

    If mpol_new is allocated but not used in restart loop, mpol_new will be
    freed via mpol_put before returning to the caller.  But refcnt is not
    initialized yet, so mpol_put could not do the right things and might
    leak the unused mpol_new.  This would happen if mempolicy was updated on
    the shared shmem file while the sp->lock has been dropped during the
    memory allocation.

    This issue could be triggered easily with the below code snippet if
    there are many processes doing the below work at the same time:

      shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT);
      shm = shmat(shmid, 0, 0);
      loop many times {
        mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0);
        mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask,
              maxnode, 0);
      }

    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 42288fe366c4 ("mm: mempolicy: Convert shared_policy mutex to spinlock")
    Signed-off-by: Miaohe Lin <[email protected]>
    Acked-by: Michal Hocko <[email protected]>
    Cc: KOSAKI Motohiro <[email protected]>
    Cc: Mel Gorman <[email protected]>
    Cc: <[email protected]>	[3.8]
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e2c328c2a8f9de8b761bd4025b66c63120c55761
Author: Paolo Bonzini <[email protected]>
Date:   Fri Apr 8 13:09:04 2022 -0700

    mmmremap.c: avoid pointless invalidate_range_start/end on mremap(old_size=0)

    commit 01e67e04c28170c47700c2c226d732bbfedb1ad0 upstream.

    If an mremap() syscall with old_size=0 ends up in move_page_tables(), it
    will call invalidate_range_start()/invalidate_range_end() unnecessarily,
    i.e.  with an empty range.

    This causes a WARN in KVM's mmu_notifier.  In the past, empty ranges
    have been diagnosed to be off-by-one bugs, hence the WARNing.  Given the
    low (so far) number of unique reports, the benefits of detecting more
    buggy callers seem to outweigh the cost of having to fix cases such as
    this one, where userspace is doing something silly.  In this particular
    case, an early return from move_page_tables() is enough to fix the
    issue.

    Link: https://lkml.kernel.org/r/[email protected]
    Reported-by: [email protected]
    Signed-off-by: Paolo Bonzini <[email protected]>
    Cc: Sean Christopherson <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 024fc7e2ea7fa2221f8535f04afc337be8e19d3d
Author: Wolfram Sang <[email protected]>
Date:   Mon Apr 4 13:49:02 2022 +0200

    mmc: renesas_sdhi: don't overwrite TAP settings when HS400 tuning is complete

    commit 03e59b1e2f56245163b14c69e0a830c24b1a3a47 upstream.

    When HS400 tuning is complete and HS400 is going to be activated, we
    have to keep the current number of TAPs and should not overwrite them
    with a hardcoded value. This was probably a copy&paste mistake when
    upporting HS400 support from the BSP.

    Fixes: 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support")
    Reported-by: Yoshihiro Shimoda <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Reviewed-by: Yoshihiro Shimoda <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 26c432a730fa54b3baafb07a44e0c3248c470336
Author: Pali Rohár <[email protected]>
Date:   Fri Mar 18 15:14:41 2022 +0100

    Revert "mmc: sdhci-xenon: fix annoying 1.8V regulator warning"

    commit 7e2646ed47542123168d43916b84b954532e5386 upstream.

    This reverts commit bb32e1987bc55ce1db400faf47d85891da3c9b9f.

    Commit 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization")
    contains proper fix for the issue described in commit bb32e1987bc5 ("mmc:
    sdhci-xenon: fix annoying 1.8V regulator warning").

    Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable")
    Cc: [email protected] # 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization")
    Signed-off-by: Pali Rohár <[email protected]>
    Reviewed-by: Marek Behún <[email protected]>
    Reviewed-by: Marcin Wojtas <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 188fe6b26765edbad4055611c0f788b6870f4024
Author: Lv Yunlong <[email protected]>
Date:   Wed Apr 6 21:04:43 2022 +0200

    drbd: Fix five use after free bugs in get_initial_state

    [ Upstream commit aadb22ba2f656581b2f733deb3a467c48cc618f6 ]

    In get_initial_state, it calls notify_initial_state_done(skb,..) if
    cb->args[5]==1. If genlmsg_put() failed in notify_initial_state_done(),
    the skb will be freed by nlmsg_free(skb).
    Then get_initial_state will goto out and the freed skb will be used by
    return value skb->len, which is a uaf bug.

    What's worse, the same problem goes even further: skb can also be
    freed in the notify_*_state_change -> notify_*_state calls below.
    Thus 4 additional uaf bugs happened.

    My patch lets the problem callee functions: notify_initial_state_done
    and notify_*_state_change return an error code if errors happen.
    So that the error codes could be propagated and the uaf bugs can be avoid.

    v2 reports a compilation warning. This v3 fixed this warning and built
    successfully in my local environment with no additional warnings.
    v2: https://lore.kernel.org/patchwork/patch/1435218/

    Fixes: a29728463b254 ("drbd: Backport the "events2" command")
    Signed-off-by: Lv Yunlong <[email protected]>
    Reviewed-by: Christoph Böhmwalder <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit e4f970dabff6b39777be72818407892df0b84ce0
Author: Kamal Dasu <[email protected]>
Date:   Mon Mar 28 10:24:42 2022 -0400

    spi: bcm-qspi: fix MSPI only access with bcm_qspi_exec_mem_op()

    [ Upstream commit 2c7d1b281286c46049cd22b43435cecba560edde ]

    This fixes case where MSPI controller is used to access spi-nor
    flash and BSPI block is not present.

    Fixes: 5f195ee7d830 ("spi: bcm-qspi: Implement the spi_mem interface")
    Signed-off-by: Kamal Dasu <[email protected]>
    Acked-by: Florian Fainelli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 9648adb1b3ece55c657d3a4f52bfee663b710dfe
Author: Jamie Bainbridge <[email protected]>
Date:   Wed Apr 6 21:19:19 2022 +1000

    qede: confirm skb is allocated before using

    [ Upstream commit 4e910dbe36508654a896d5735b318c0b88172570 ]

    qede_build_skb() assumes build_skb() always works and goes straight
    to skb_reserve(). However, build_skb() can fail under memory pressure.
    This results in a kernel panic because the skb to reserve is NULL.

    Add a check in case build_skb() failed to allocate and return NULL.

    The NULL return is handled correctly in callers to qede_build_skb().

    Fixes: 8a8633978b842 ("qede: Add build_skb() support.")
    Signed-off-by: Jamie Bainbridge <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 864297ee30727ae6233f80296b7fc91442620b05
Author: Eric Dumazet <[email protected]>
Date:   Mon Apr 4 11:34:39 2022 -0700

    rxrpc: fix a race in rxrpc_exit_net()

    [ Upstream commit 1946014ca3b19be9e485e780e862c375c6f98bad ]

    Current code can lead to the following race:

    CPU0                                                 CPU1

    rxrpc_exit_net()
                                                         rxrpc_peer_keepalive_worker()
                                                           if (rxnet->live)

      rxnet->live = false;
      del_timer_sync(&rxnet->peer_keepalive_timer);

                                                                 timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay);

      cancel_work_sync(&rxnet->peer_keepalive_work);

    rxrpc_exit_net() exits while peer_keepalive_timer is still armed,
    leading to use-after-free.

    syzbot report was:

    ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0
    WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505
    Modules linked in:
    CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: netns cleanup_net
    RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505
    Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3
    RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082
    RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
    RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52
    RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
    R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0
    R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000
    FS:  0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     __debug_check_no_obj_freed lib/debugobjects.c:992 [inline]
     debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023
     kfree+0xd6/0x310 mm/slab.c:3809
     ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176
     ops_free_list net/core/net_namespace.c:174 [inline]
     cleanup_net+0x591/0xb00 net/core/net_namespace.c:598
     process_one_work+0x996/0x1610 kernel/workqueue.c:2289
     worker_thread+0x665/0x1080 kernel/workqueue.c:2436
     kthread+0x2e9/0x3a0 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298
     </TASK>

    Fixes: ace45bec6d77 ("rxrpc: Fix firewall route keepalive")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: David Howells <[email protected]>
    Cc: Marc Dionne <[email protected]>
    Cc: [email protected]
    Reported-by: syzbot <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 315ed6da7ff7fd8de8abda1b6dcbea3a4754522a
Author: Ilya Maximets <[email protected]>
Date:   Mon Apr 4 12:41:50 2022 +0200

    net: openvswitch: don't send internal clone attribute to the userspace.

    [ Upstream commit 3f2a3050b4a3e7f32fc0ea3c9b0183090ae00522 ]

    'OVS_CLONE_ATTR_EXEC' is an internal attribute that is used for
    performance optimization inside the kernel.  It's added by the kernel
    while parsing user-provided actions and should not be sent during the
    flow dump as it's not part of the uAPI.

    The issue doesn't cause any significant problems to the ovs-vswitchd
    process, because reported actions are not really used in the
    application lifecycle and only supposed to be shown to a human via
    ovs-dpctl flow dump.  However, the action list is still incorrect
    and causes the following error if the user wants to look at the
    datapath flows:

      # ovs-dpctl add-dp system@ovs-system
      # ovs-dpctl add-flow "<flow match>" "clone(ct(commit),0)"
      # ovs-dpctl dump-flows
      <flow match>, packets:0, bytes:0, used:never,
        actions:clone(bad length 4, expected -1 for: action0(01 00 00 00),
                      ct(commit),0)

    With the fix:

      # ovs-dpctl dump-flows
      <flow match>, packets:0, bytes:0, used:never,
        actions:clone(ct(commit),0)

    Additionally fixed an incorrect attribute name in the comment.

    Fixes: b233504033db ("openvswitch: kernel datapath clone action")
    Signed-off-by: Ilya Maximets <[email protected]>
    Acked-by: Aaron Conole <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 41624d7c0c3df71dee170c610744aaa5909327b8
Author: José Expósito <[email protected]>
Date:   Sat Jan 8 17:52:30 2022 +0100

    drm/imx: Fix memory leak in imx_pd_connector_get_modes

    [ Upstream commit bce81feb03a20fca7bbdd1c4af16b4e9d5c0e1d3 ]

    Avoid leaking the display mode variable if of_get_drm_display_mode
    fails.

    Fixes: 76ecd9c9fb24 ("drm/imx: parallel-display: check return code from of_get_drm_display_mode()")
    Addresses-Coverity-ID: 1443943 ("Resource leak")
    Signed-off-by: José Expósito <[email protected]>
    Signed-off-by: Philipp Zabel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit 08c9f9bc1c25523455f1dcbbeb189aff983ec9d1
Author: Chen-Yu Tsai <[email protected]>
Date:   Fri Apr 1 02:48:32 2022 +0800

    net: stmmac: Fix unset max_speed difference between DT and non-DT platforms

    [ Upstream commit c21cabb0fd0b54b8b54235fc1ecfe1195a23bcb2 ]

    In commit 9cbadf094d9d ("net: stmmac: support max-speed device tree
    property"), when DT platforms don't set "max-speed", max_speed is set to
    -1; for non-DT platforms, it stays the default 0.

    Prior to commit eeef2f6b9f6e ("net: stmmac: Start adding phylink support"),
    the check for a valid max_speed setting was to check if it was greater
    than zero. This commit got it right, but subsequent patches just checked
    for non-zero, which is incorrect for DT platforms.

    In commit 92c3807b9ac3 ("net: stmmac: convert to phylink_get_linkmodes()")
    the conversion switched completely to checking for non-zero value as a
    valid value, which caused 1000base-T to stop getting advertised by
    default.

    Instead of trying to fix all the checks, simply leave max_speed alone if
    DT property parsing fails.

    Fixes: 9cbadf094d9d ("net: stmmac: support max-speed device tree property")
    Fixes: 92c3807b9ac3 ("net: stmmac: convert to phylink_get_linkmodes()")
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Acked-by: Russell King (Oracle) <[email protected]>
    Reviewed-by: Srinivas Kandagatla <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit db863ab2baf058ed05c7b723612e3c40c9dd6885
Author: Christophe JAILLET <[email protected]>
Date:   Sat Mar 19 08:01:24 2022 +0100

    scsi: zorro7xx: Fix a resource leak in zorro7xx_remove_one()

    [ Upstream commit 16ed828b872d12ccba8f07bcc446ae89ba662f9c ]

    The error handling path of the probe releases a resource that is not freed
    in the remove function. In some cases, a ioremap() must be undone.

    Add the missing iounmap() call in the remove function.

    Link: https://lore.kernel.org/r/247066a3104d25f9a05de8b3270fc3c848763bcc.1647673264.git.christophe.jaillet@wanadoo.fr
    Fixes: 45804fbb00ee ("[SCSI] 53c700: Amiga Zorro NCR53c710 SCSI")
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 6b4c0149a56147b29169e07000d566162892722a
Author: Guilherme G. Piccoli <[email protected]>
Date:   Tue Mar 15 17:35:35 2022 -0300

    Drivers: hv: vmbus: Fix potential crash on module unload

    [ Upstream commit 792f232d57ff28bbd5f9c4abe0466b23d5879dc8 ]

    The vmbus driver relies on the panic notifier infrastructure to perform
    some operations when a panic event is detected. Since vmbus can be built
    as module, it is required that the driver handles both registering and
    unregistering such panic notifier callback.

    After commit 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
    though, the panic notifier registration is done unconditionally in the module
    initialization routine whereas the unregistering procedure is conditionally
    guarded and executes only if HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE capability
    is set.

    This patch fixes that by unconditionally unregistering the panic notifier
    in the module's exit routine as well.

    Fixes: 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
    Signed-off-by: Guilherme G. Piccoli <[email protected]>
    Reviewed-by: Michael Kelley <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wei Liu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit a17d93c9088c1b7d7ec42ce25573b93544e19616
Author: Dan Carpenter <[email protected]>
Date:   Wed Mar 16 11:41:48 2022 +0300

    drm/amdgpu: fix off by one in amdgpu_gfx_kiq_acquire()

    [ Upstream commit 1647b54ed55d4d48c7199d439f8834626576cbe9 ]

    This post-op should be a pre-op so that we do not pass -1 as the bit
    number to test_bit().  The current code will loop downwards from 63 to
    -1.  After changing to a pre-op, it loops from 63 to 0.

    Fixes: 71c37505e7ea ("drm/amdgpu/gfx: move more common KIQ code to amdgpu_gfx.c")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 7aa0c5197ea0fb2346f21f32ce67f9557da8dba8
Author: James Morse <[email protected]>
Date:   Fri Apr 8 18:22:32 2022 +0100

    KVM: arm64: Check arm64_get_bp_hardening_data() didn't return NULL

    Will reports that with CONFIG_EXPERT=y and CONFIG_HARDEN_BRANCH_PREDICTOR=n,
    the kernel dereferences a NULL pointer during boot:

    [    2.384444] Internal error: Oops: 96000004 [#1] PREEMPT SMP
    [    2.384461] pstate: 20400085 (nzCv daIf +PAN -UAO)
    [    2.384472] pc : cpu_hyp_reinit+0x114/0x30c
    [    2.384476] lr : cpu_hyp_reinit+0x80/0x30c

    [    2.384529] Call trace:
    [    2.384533]  cpu_hyp_reinit+0x114/0x30c
    [    2.384537]  _kvm_arch_hardware_enable+0x30/0x54
    [    2.384541]  flush_smp_call_function_queue+0xe4/0x154
    [    2.384544]  generic_smp_call_function_single_interrupt+0x10/0x18
    [    2.384549]  ipi_handler+0x170/0x2b0
    [    2.384555]  handle_percpu_devid_fasteoi_ipi+0x120/0x1cc
    [    2.384560]  __handle_domain_irq+0x9c/0xf4
    [    2.384563]  gic_handle_irq+0x6c/0xe4
    [    2.384566]  el1_irq+0xf0/0x1c0
    [    2.384570]  arch_cpu_idle+0x28/0x44
    [    2.384574]  do_idle+0x100/0x2a8
    [    2.384577]  cpu_startup_entry+0x20/0x24
    [    2.384581]  secondary_start_kernel+0x1b0/0x1cc
    [    2.384589] Code: b9469d08 7100011f 540003ad 52800208 (f9400108)
    [    2.384600] ---[ end trace 266d08dbf96ff143 ]---
    [    2.385171] Kernel panic - not syncing: Fatal exception in interrupt

    In this configuration arm64_get_bp_hardening_data() returns NULL.
    Add a check in kvm_get_hyp_vector().

    Cc: Will Deacon <[email protected]>
    Link: https://lore.kernel.org/linux-arm-kernel/20220408120041.GB27685@willie-the-truck/
    Fixes: a68912a3ae3 ("KVM: arm64: Add templates for BHB mitigation sequences")
    Cc: [email protected] # 4.19
    Signed-off-by: James Morse <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit ef521626ac9f7e3b20eeb52b64a4f85992702c54
Author: Mauricio Faria de Oliveira <[email protected]>
Date:   Thu Apr 7 16:14:30 2022 -0300

    mm: fix race between MADV_FREE reclaim and blkdev direct IO read

    commit 6c8e2a256915a223f6289f651d6b926cd7135c9e upstream.

    Problem:
    =======

    Userspace might read the zero-page instead of actual data from a direct IO
    read on a block device if the buffers have been called madvise(MADV_FREE)
    on earlier (this is discussed below) due to a race between page reclaim on
    MADV_FREE and blkdev direct IO read.

    - Race condition:
      ==============

    During page reclaim, the MADV_FREE page check in try_to_unmap_one() checks
    if the page is not dirty, then discards its rmap PTE(s) (vs.  remap back
    if the page is dirty).

    However, after try_to_unmap_one() returns to shrink_page_list(), it might
    keep the page _anyway_ if page_ref_freeze() fails (it expects exactly
    _one_ page reference, from the isolation for page reclaim).

    Well, blkdev_direct_IO() gets references for all pages, and on READ
    operations it only sets them dirty _later_.

    So, if MADV_FREE'd pages (i.e., not dirty) are used as buffers for direct
    IO read from block devices, and page reclaim happens during
    __blkdev_direct_IO[_simple]() exactly AFTER bio_iov_iter_get_pages()
    returns, but BEFORE the pages are set dirty, the situation happens.

    The direct IO read eventually completes.  Now, when userspace reads the
    buffers, the PTE is no longer there and the page fault handler
    do_anonymous_page() services that with the zero-page, NOT the data!

    A synthetic reproducer is provided.

    - Page faults:
      ===========

    If page reclaim happens BEFORE bio_iov_iter_get_pages() the issue doesn't
    happen, because that faults-in all pages as writeable, so
    do_anonymous_page() sets up a new page/rmap/PTE, and that is used by
    direct IO.  The userspace reads don't fault as the PTE is there (thus
    zero-page is not used/setup).

    But if page reclaim happens AFTER it / BEFORE setting pages dirty, the PTE
    is no longer there; the subsequent page faults can't help:

    The data-read from the block device probably won't generate faults due to
    DMA (no MMU) but even in the case it wouldn't use DMA, that happens on
    different virtual addresses (not user-mapped addresses) because `struct
    bio_vec` stores `struct page` to figure addresses out (which are different
    from user-mapped addresses) for the read.

    Thus userspace reads (to user-mapped addresses) still fault, then
    do_anonymous_page() gets another `struct page` that would address/ map to
    other memory than the `struct page` used by `struct bio_vec` for the read.
    (The original `struct page` is not available, since it wasn't freed, as
    page_ref_freeze() failed due to more page refs.  And even if it were
    available, its data cannot be trusted anymore.)

    Solution:
    ========

    One solution is to check for the expected page reference count in
    try_to_unmap_one().

    There should be one reference from the isolation (that is also checked in
    shrink_page_list() with page_ref_freeze()) plus one or more references
    from page mapping(s) (put in discard: label).  Further references mean
    that rmap/PTE cannot be unmapped/nuked.

    (Note: there might be more than one reference from mapping due to
    fork()/clone() without CLONE_VM, which use the same `struct page` for
    references, until the copy-on-write page gets copied.)

    So, additional page references (e.g., from direct IO read) now prevent the
    rmap/PTE from being unmapped/dropped; similarly to the page is not freed
    per shrink_page_list()/page_ref_freeze()).

    - Races and Barriers:
      ==================

    The new check in try_to_unmap_one() should be safe in races with
    bio_iov_iter_get_pages() in get_user_pages() fast and slow paths, as it's
    done under the PTE lock.

    The fast path doesn't take the lock, but it checks if the PTE has changed
    and if so, it drops the reference and leaves the page for the slow path
    (which does take that lock).

    The fast path requires synchronization w/ full memory barrier: it writes
    the page reference count first then it reads the PTE later, while
    try_to_unmap() writes PTE first then it reads page refcount.

    And a second barrier is needed, as the page dirty flag should not be read
    before the page reference count (as in __remove_mapping()).  (This can be
    a load memory barrier only; no writes are involved.)

    Call stack/comments:

    - try_to_unmap_one()
      - page_vma_mapped_walk()
        - map_pte()			# see pte_offset_map_lock():
            pte_offset_map()
            spin_lock()

      - ptep_get_and_clear()	# write PTE
      - smp_mb()			# (new barrier) GUP fast path
      - page_ref_count()		# (new check) read refcount

      - page_vma_mapped_walk_done()	# see pte_unmap_unlock():
          pte_unmap()
          spin_unlock()

    - bio_iov_iter_get_pages()
      - __bio_iov_iter_get_pages()
        - iov_iter_get_pages()
          - get_user_pages_fast()
            - internal_get_user_pages_fast()

              # fast path
              - lockless_pages_from_mm()
                - gup_{pgd,p4d,pud,pmd,pte}_range()
                    ptep = pte_offset_map()		# not _lock()
                    pte = ptep_get_lockless(ptep)

                    page = pte_page(pte)
                    try_grab_compound_head(page)	# inc refcount
                                                	# (RMW/barrier
                                                 	#  on success)

                    if (pte_val(pte) != pte_val(*ptep)) # read PTE
                         …
tuxedo-bot pushed a commit to tuxedocomputers/linux that referenced this pull request May 22, 2022
BugLink: https://bugs.launchpad.net/bugs/1969107

commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
(cherry picked from commit fbe722d48b8eee840015fc1657602f627ca875b7)
Signed-off-by: Paolo Pisati <[email protected]>
delphix-devops-bot pushed a commit to delphix/linux-kernel-generic that referenced this pull request Jun 10, 2022
BugLink: https://bugs.launchpad.net/bugs/1971497

commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
Signed-off-by: Stefan Bader <[email protected]>
mark-nicholson pushed a commit to mark-nicholson/linux-uek that referenced this pull request Jun 15, 2022
commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
(cherry picked from commit f0752ee5efdcd0890da73635c2c0bdb0d9161746)
Signed-off-by: Sherry Yang <[email protected]>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/linux-mvista that referenced this pull request Jul 1, 2022
Source: Kernel.org
MR: 119173
Type: Integration
Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.4.y
ChangeID: f0752ee5efdcd0890da73635c2c0bdb0d9161746
Description:

commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
it-is-a-robot pushed a commit to openeuler-mirror/kernel that referenced this pull request Jul 15, 2022
stable inclusion
from stable-v5.10.111
commit 75c8558d410f6cedc96f6f701f7ced1c8aced6fc
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5GL1Z

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=75c8558d410f6cedc96f6f701f7ced1c8aced6fc

--------------------------------

commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Zheng Zengkai <[email protected]>
Reviewed-by: Wei Li <[email protected]>
toufune pushed a commit to toufune/kernel_xiaomi_juice that referenced this pull request Jul 16, 2022
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
EmanuelCN pushed a commit to EmanuelCN/kernel_xiaomi_sm8250 that referenced this pull request Jul 16, 2022
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
it-is-a-robot pushed a commit to openeuler-mirror/kernel that referenced this pull request Jul 19, 2022
stable inclusion
from stable-v5.10.111
commit 75c8558d410f6cedc96f6f701f7ced1c8aced6fc
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5GL1Z

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=75c8558d410f6cedc96f6f701f7ced1c8aced6fc

--------------------------------

commit 41caff4 upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Zheng Zengkai <[email protected]>
Reviewed-by: Wei Li <[email protected]>
hellobbn pushed a commit to hellobbn/android_kernel_sony_sm8250 that referenced this pull request Jul 21, 2022
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
EmanuelCN pushed a commit to EmanuelCN/kernel_xiaomi_sm8250 that referenced this pull request Jul 22, 2022
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
EmanuelCN pushed a commit to EmanuelCN/kernel_xiaomi_sm8250 that referenced this pull request Jul 22, 2022
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
EmanuelCN pushed a commit to EmanuelCN/kernel_xiaomi_sm8250 that referenced this pull request Jul 23, 2022
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
EmanuelCN pushed a commit to EmanuelCN/kernel_xiaomi_sm8250 that referenced this pull request Jul 23, 2022
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
EmanuelCN pushed a commit to EmanuelCN/kernel_xiaomi_sm8250 that referenced this pull request Aug 17, 2022
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Blackmanx pushed a commit to Blackmanx/bigshot_kernel_realme_sm8250 that referenced this pull request Dec 21, 2022
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
kjanek pushed a commit to kjanek/kernel_xiaomi_jason that referenced this pull request Jan 20, 2023
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
kjanek pushed a commit to kjanek/kernel_xiaomi_jason that referenced this pull request Jan 20, 2023
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
bggRGjQaUbCoE pushed a commit to bggRGjQaUbCoE/android_kernel_samsung_sm8250-mohammad92 that referenced this pull request Apr 6, 2023
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
bggRGjQaUbCoE pushed a commit to bggRGjQaUbCoE/android_kernel_samsung_sm8250 that referenced this pull request Apr 16, 2023
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
intersectRaven pushed a commit to intersectRaven/rk356x-kernel that referenced this pull request Sep 16, 2023
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
intersectRaven pushed a commit to intersectRaven/rk356x-kernel that referenced this pull request Sep 16, 2023
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
intersectRaven pushed a commit to intersectRaven/rk356x-kernel that referenced this pull request Sep 16, 2023
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Dheeraj3031A pushed a commit to Dheeraj3031A/kernel_oplus_RMX3461 that referenced this pull request Mar 13, 2024
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
FakeShell pushed a commit to FuriLabs/linux-furiphone-krypton that referenced this pull request Aug 20, 2024
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
deflamingq pushed a commit to deflamingq/kernel_asus_sdm660 that referenced this pull request Nov 4, 2024
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
FakeShell pushed a commit to FuriLabs/linux-furiphone-krypton that referenced this pull request Dec 6, 2024
commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream.

These make the feature check fail when using clang, so remove them just
like is done in tools/perf/Makefile.config to build perf itself.

Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
when building with clang is also necessary to avoid these warnings
turned into errors (-Werror):

    CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  In file included from util/scripting-engines/trace-event-perl.c:35:
  In file included from /usr/lib64/perl5/CORE/perl.h:4085:
  In file included from /usr/lib64/perl5/CORE/hv.h:659:
  In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
  In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                       ^~~~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
  #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                  ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
      v ^= (v>>23);                       \
                                          ^
  /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
      ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
  } STMT_END
    ^~~~~~~~
  /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
  #   define STMT_END     )
                          ^

Please refer to the discussion on the Link: tag below, where Nathan
clarifies the situation:

<quote>
acme> And then get to the problems at the end of this message, which seem
acme> similar to the problem described here:
acme>
acme> From  Nathan Chancellor <>
acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
acme>
acme> https://lkml.org/lkml/2020/9/1/135
acme>
acme> So perhaps in this case its better to disable that
acme> -Werror,-Wcompound-token-split-by-macro when building with clang?

Yes, I think that is probably the best solution. As far as I can tell,
at least in this file and context, the warning appears harmless, as the
"create a GNU C statement expression from two different macros" is very
much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
The warning is fixed in upstream Perl by just avoiding creating GNU C
statement expressions using STMT_START and STMT_END:

  Perl/perl5#18780
  Perl/perl5#18984

If I am reading the source code correctly, an alternative to disabling
the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
seems like that might end up impacting more than just this site,
according to the issue discussion above.
</quote>

Based-on-a-patch-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # Debian/Selfmade LLVM-14 (x86-64)
Cc: Adrian Hunter <[email protected]>
Cc: Fangrui Song <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Keeping <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Michael Petlan <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

clang12: Using as compiler generates 30K warnings of -Wcompound-token-split-by-macro
3 participants