netdev - Re: [PATCH net-next v2 0/4] sfc: add MCDI tracing

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: <555F420A.2040104@solarflare.com>
Date:	Fri, 22 May 2015 15:49:46 +0100
From:	Edward Cree <ecree@...arflare.com>
To:	David Miller <davem@...emloft.net>
CC:	<netdev@...r.kernel.org>, <linux-net-drivers@...arflare.com>
Subject: Re: [PATCH net-next v2 0/4] sfc: add MCDI tracing

On 21/05/15 23:52, David Miller wrote:
> All of this work to allocate the buffer, add messages to it, and dump it
> to some user obtainable location duplicates existing infrastructure in
> the kernel.
> Please do not do this, and instead use the kernel's existing tracing
> infrastructure to implement this.

The logging_buffer we allocate isn't there to store _messages_ for later
dumping, it's a work area for constructing a _single_ message, which is
then merely written to the system log with netif_info.  Thus, I don't see
how it would make much difference if we used (say) ftrace instead of
netif_info to ship the events to userspace.
The reason the buffer is long-lived is simply to avoid the overhead of
allocating and freeing it every MCDI call, since MCDIs are already known
to be serialised for other reasons.
Can you please further explain your objection and what you'd prefer us to
do?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html