linux-kernel - Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

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: <20190523051916.GQ2422@oracle.com>
Date:   Thu, 23 May 2019 01:19:16 -0400
From:   Kris Van Hees <kris.van.hees@...cle.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Kris Van Hees <kris.van.hees@...cle.com>,
        Peter Zijlstra <peterz@...radead.org>, netdev@...r.kernel.org,
        bpf@...r.kernel.org, dtrace-devel@....oracle.com,
        linux-kernel@...r.kernel.org, rostedt@...dmis.org,
        mhiramat@...nel.org, acme@...nel.org, ast@...nel.org,
        daniel@...earbox.net
Subject: Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type
 implementation and sample use

On Wed, May 22, 2019 at 12:55:27PM -0700, Alexei Starovoitov wrote:
> On Wed, May 22, 2019 at 02:22:15PM -0400, Kris Van Hees wrote:
> > On Wed, May 22, 2019 at 04:25:32PM +0200, Peter Zijlstra wrote:
> > > On Tue, May 21, 2019 at 10:56:18AM -0700, Alexei Starovoitov wrote:
> > > 
> > > > and no changes are necessary in kernel/events/ring_buffer.c either.
> > > 
> > > Let me just NAK them on the principle that I don't see them in my inbox.
> > 
> > My apologies for failing to include you on the Cc for the patches.  That was
> > an oversight on my end and certainly not intentional.
> > 
> > > Let me further NAK it for adding all sorts of garbage to the code --
> > > we're not going to do gaps and stay_in_page nonsense.
> > 
> > Could you give some guidance in terms of an alternative?  The ring buffer code
> > provides both non-contiguous page allocation support and a vmalloc-based
> > allocation, and the vmalloc version certainly would avoid the entire gap and
> > page boundary stuff.  But since the allocator is chosen at build time based on
> > the arch capabilities, there is no way to select a specific memory allocator.
> > I'd be happy to use an alternative approach that allows direct writing into
> > the ring buffer.
> 
> You do not _need_ direct write from bpf prog.
> dtrace language doesn't mandate direct write.
> 'direct write into ring buffer form bpf prog' is an interesting idea and
> may be nice performance optimization, but in no way it's a blocker for dtrace scripts.
> Also it's far from clear that it actually brings performance benefits.
> Letting bpf progs write directly into ring buffer comes with
> a lot of corner cases. It's something to carefully analyze.

I agree that doing direct writes is something that can be deferred right now,
especially because there are more fundamental things to focus on.  Thank you
for your acknowledgement of the idea, and I certainly look forward to exploring
this further at a later time,

> I suggest to proceed with user space dtrace conversion to bpf
> without introducing kernel changes.