[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhRV06YHwy5cAAiRvOPUGQ9s1LkOdacMAJVzwykD8B_sgA@mail.gmail.com>
Date: Tue, 7 Sep 2021 11:34:31 -0400
From: Paul Moore <paul@...l-moore.com>
To: LEROY Christophe <christophe.leroy@...roup.eu>
Cc: Eric Paris <eparis@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-audit@...hat.com" <linux-audit@...hat.com>
Subject: Re: [PATCH] audit: Fix build failure by renaming struct node to
struct audit_node
On Mon, Sep 6, 2021 at 2:41 AM LEROY Christophe
<christophe.leroy@...roup.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@...roup.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@...roup.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?
--
paul moore
www.paul-moore.com
Powered by blists - more mailing lists