linux-kernel - Re: [PATCH 2/2] tracing: Add support for critical section events

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+oo3JAA3OE_mx8RCb1YrTgfS2RdF8NN3UgtGa_9ASMOgWA@mail.gmail.com>
Date:   Tue, 5 Sep 2017 09:35:11 -0700
From:   Joel Fernandes <joelaf@...gle.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        LKML <linux-kernel@...r.kernel.org>, kernel-team@...roid.com,
        Ingo Molnar <mingo@...hat.com>,
        Byungchul Park <byungchul.park@....com>,
        Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH 2/2] tracing: Add support for critical section events

On Mon, Sep 4, 2017 at 11:52 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Mon, Sep 04, 2017 at 08:26:13PM -0700, Joel Fernandes wrote:
>
>> Apologies, I meant (without the "off"):
>>
>> subsystem: atomic_section
>> events:
>>   irqs_disable
>>   irqs_enable
>>   preempt_disable
>>   preempt_enable
>>
>> and additionally (similar to what my patch does):
>>   preemptirq_enable
>>   preemptirq_disable
>>
>
> What do you need the last for?

The last 2 events above behave as 'disable' means either preempt or
irq got disabled, and 'enable' means *both* preempt and irq are
enabled (after either one of them was disabled).

This has the advantage of not generating events when we're already in
an atomic section when using these events, for example acquiring spin
locks in an interrupt handler might increase the preempt count and
generate 'preempt_disable' events, but not preemptirq_disable events.
This has the effect of reducing the spam in the traces when all we
care about is being in an atomic section or not. These events happen a
lot so to conserve space in the trace buffer, the user may want to
just enable the latter 2 events. Does that sound Ok to you?

thanks,

- Joel