-----Message d'origine-----
 De : Paul Moore <paul(a)paul-moore.com>
 On Mon, Sep 6, 2021 at 2:41 AM LEROY Christophe
 <christophe.leroy(a)csgroup.eu> wrote:
 > Le 03/09/2021 à 19:06, Paul Moore a écrit :
 > > On Fri, Sep 3, 2021 at 11:48 AM Christophe Leroy
 > > <christophe.leroy(a)csgroup.eu> wrote:
 > >>
 > >> struct node defined in kernel/audit_tree.c conflicts with struct
 > >> node defined in include/linux/node.h
 > >>
 > >>            CC      kernel/audit_tree.o
 > >>          kernel/audit_tree.c:33:9: error: redefinition of 'struct
node'
 > >>             33 |  struct node {
 > >>                |         ^~~~
 > >>          In file included from ./include/linux/cpu.h:17,
 > >>                           from ./include/linux/static_call.h:102,
 > >>                           from ./arch/powerpc/include/asm/machdep.h:10,
 > >>                           from ./arch/powerpc/include/asm/archrandom.h:7,
 > >>                           from ./include/linux/random.h:121,
 > >>                           from ./include/linux/net.h:18,
 > >>                           from ./include/linux/skbuff.h:26,
 > >>                           from kernel/audit.h:11,
 > >>                           from kernel/audit_tree.c:2:
 > >>          ./include/linux/node.h:84:8: note: originally defined here
 > >>             84 | struct node {
 > >>                |        ^~~~
 > >>          make[2]: *** [kernel/audit_tree.o] Error 1
 > >>
 > >> Rename it audit_node.
 > >>
 > >> Signed-off-by: Christophe Leroy <christophe.leroy(a)csgroup.eu>
 > >> ---
 > >>   kernel/audit_tree.c | 20 ++++++++++----------
 > >>   1 file changed, 10 insertions(+), 10 deletions(-)
 > >
 > > That's interesting, I wonder why we didn't see this prior?  Also as
 > > an aside, there are evidently a good handful of symbols named
 > > "node".  In fact I don't see this now in the audit/stable-5.15
or
 > > Linus' tree as of a right now, both using an allyesconfig:
 > >
 > > % git show-ref HEAD
 > > a9c9a6f741cdaa2fa9ba24a790db8d07295761e3 refs/remotes/linus/HEAD %
 > > touch kernel/audit_tree.c % make C=1 kernel/
 > >   CALL    scripts/checksyscalls.sh
 > >   CALL    scripts/atomic/check-atomics.sh
 > >   DESCEND objtool
 > >   CHK     kernel/kheaders_data.tar.xz
 > >   CC      kernel/audit_tree.o
 > >   CHECK   kernel/audit_tree.c
 > >   AR      kernel/built-in.a
 > >
 > > What tree and config are you using where you see this error?
 > > Looking at your error, I'm guessing this is limited to ppc builds,
 > > and if I look at the arch/powerpc/include/asm/machdep.h file in
 > > Linus tree I don't see a static_call.h include so I'm guessing this
 > > is a -next tree for ppc?  Something else?
 > >
 > > Without knowing the context, is adding the static_call.h include in
 > > arch/powerpc/include/asm/machdep.h intentional or simply a bit of
 > > include file creep?
 >
 > struct machdep_calls in asm/machdep.h is full of function pointers and
 > I'm working on converting that to static_calls
 > (
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=260878
 > &state=*)
 >
 > So yes, adding static_call.h in asm/machdep.h is intentional and the
 > issue was detected by CI build test
 > (
http://kisskb.ellerman.id.au/kisskb/buildresult/14628100/)
 >
 > I submitted this change to you because for me it make sense to not
 > re-use globably defined struct names in local C files, and anybody may
 > encounter the problem as soon as linux/node.h gets included directly
 > or indirectly. But if you prefer I guess the fix may be merged through
 > powerpc tree as part of this series.
 Yes, this patch should go in via the audit tree, and while I don't have an
 objection to the patch, whenever I see a patch to fix an issue that is not visible in
 Linus' tree or the audit tree it raises some questions.  I usually hope to see those
 questions answered proactively in the cover letter and/or patch description but
 that wasn't the case here so you get to play a game of 20 questions.
 Speaking of which, I don't recall seeing an answer to the "where do these
 include file changes live?" question, is is the ppc -next tree, or are they still
 unmerged and just on the ppc list?
 
It is still an RFC in the ppc list.
Thanks
Christophe
CS Group - Document Interne