linux-kernel - Re: [RFC PATCH 0/5] BLOG: per-task logging contexts with Ceph consumer

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: <20251027105403.2d020b8d@gandalf.local.home>
Date: Mon, 27 Oct 2025 10:54:03 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Alex Markuze <amarkuze@...hat.com>
Cc: ceph-devel@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, Liam.Howlett@...cle.com, akpm@...ux-foundation.org,
 bsegall@...gle.com, david@...hat.com, dietmar.eggemann@....com,
 idryomov@...il.com, mingo@...hat.com, juri.lelli@...hat.com,
 kees@...nel.org, lorenzo.stoakes@...cle.com, mgorman@...e.de,
 mhocko@...e.com, rppt@...nel.org, peterz@...radead.org, surenb@...gle.com,
 vschneid@...hat.com, vincent.guittot@...aro.org, vbabka@...e.cz,
 xiubli@...hat.com, Slava.Dubeyko@....com
Subject: Re: [RFC PATCH 0/5] BLOG: per-task logging contexts with Ceph
 consumer

On Sat, 25 Oct 2025 20:54:00 +0300
Alex Markuze <amarkuze@...hat.com> wrote:

> Please correct me if I am wrong, I was not aware that ftrace is used
> by any kernel component as the default unstructured logger.
> This is the point of BLog, having a low impact unstructured logger,
> it's not always possible or easy to provide a debug kernel where
> ftarce is both enabled and used for dumping logs.
> Having an always-on binary logger facilitates better debuggability.
> When anything happens, a client with BLog has the option to send a
> large log file with their report.
> An additional benefit is that each logging buffer is attached to the
> associated tasks and the whole module has its own separate cyclical
> log buffer.

This looks like a very specific solution trying to be a little more generic.

The more generic a solution becomes, the more "bloated" it becomes as well.
That's the nature of tracers and loggers. Ftrace was designed to be very
generic, and yes, it can be more bloated because of that. But it is also
designed to be tuned down to be a highly efficient tracer. One that can be
used in a production environment. Sure, if you enable every event, it will
cause a noticeable overhead, but ftrace is designed to surgically pick
which events should be enabled or not, keeping the overhead within the
noise.

Ftrace is more of an "infrastructure" than a tool. It provides access to
trace almost every function , but you can use that same code to implement
live kernel patching or BPF hooks to functions. The trace event and
tracepoints are part of ftrace, and are used for things other than tracing.

Perhaps it may be more suitable to make BLOG use the tracefs interface,
then to create an entirely new interface based on debugfs (which BTW, a lot
of production systems do not enable debugfs which is why ftrace uses its
own tracefs that does not depend on it).

-- Steve