linux-kernel - Re: [RFC] trace: Add option for polling ring buffers

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: <YKVT+sQTgNpCR/Gt@casper.infradead.org>
Date:   Wed, 19 May 2021 19:07:54 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Nicolas Saenz Julienne <nsaenzju@...hat.com>
Cc:     rostedt@...dmis.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, mingo@...hat.com, corbet@....net,
        mtosatti@...hat.com
Subject: Re: [RFC] trace: Add option for polling ring buffers

On Wed, May 19, 2021 at 07:57:55PM +0200, Nicolas Saenz Julienne wrote:
> To minimize trace's effect on isolated CPUs. That is, CPUs were only a
> handful or a single, process are allowed to run. Introduce a new trace
> option: 'poll-rb'.

maybe this should take a parameter in ms (us?) saying how frequently
to poll?  it seems like a reasonable assumption that somebody running in
this kind of RT environment would be able to judge how often their
monitoring task needs to collect data.

> [1] The IPI, in this case, an irq_work, is needed since trace might run
> in NMI context. Which is not suitable for wake-ups.

could we also consider a try-wakeup which would not succeed if in NMI
context?  or are there situations where we only gather data in NMI
context, and so would never succeed in waking up?  if so, maybe
schedule the irq_work every 1000 failures to wake up.