linux-kernel - Re: [PATCH] tracing: always define trace_{irq,preempt}_{enable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJWu+oqFc7FyxP13K_N26HegW-7akzdV4Lm12DraqOYRyAZzkw@mail.gmail.com>
Date:   Thu, 19 Oct 2017 11:42:34 -0700
From:   Joel Fernandes <joelaf@...gle.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tracing: always define trace_{irq,preempt}_{enable_disable}

Hi,

On Thu, Oct 19, 2017 at 1:32 AM, Arnd Bergmann <arnd@...db.de> wrote:
> We get a build error in the irqsoff tracer in some configurations:
>
> kernel/trace/trace_irqsoff.c: In function 'trace_preempt_on':
> kernel/trace/trace_irqsoff.c:855:2: error: implicit declaration of function 'trace_preempt_enable_rcuidle'; did you mean 'trace_irq_enable_rcuidle'? [-Werror=implicit-function-declaration]
>   trace_preempt_enable_rcuidle(a0, a1);
>
> The problem is that trace_preempt_enable_rcuidle() has different
> definition based on multiple Kconfig symbols, but not all combinations
> have a valid definition.
>
> This changes the conditions so that we always get exactly one
> definition of each of the four tracing macros. I have not tried
> to verify that these definitions are sensible, but now we
> can build all randconfig combinations again.
>
> Fixes: d59158162e03 ("tracing: Add support for preempt and irq enable/disable events")
> Signed-off-by: Arnd Bergmann <arnd@...db.de>


Yes this build condition is possible. Thanks for finding it. I agree
with this patch, I will be simplifying this much more once I integrate
PROVE_LOCKING to use tracepoint probes but this is Ok with me for now.

Acked-by: Joel Fernandes <joelaf@...gle.com>

thanks!

- Joel

<snip>