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]
Date:   Tue, 16 Aug 2022 10:01:38 -0700
From:   Hao Luo <haoluo@...gle.com>
To:     David Vernet <void@...ifault.com>
Cc:     bpf@...r.kernel.org, ast@...nel.org, daniel@...earbox.net,
        andrii@...nel.org, john.fastabend@...il.com, martin.lau@...ux.dev,
        song@...nel.org, yhs@...com, kpsingh@...nel.org, sdf@...gle.com,
        jolsa@...nel.org, tj@...nel.org, joannelkoong@...il.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] bpf: Add user-space-publisher ringbuffer map type

On Tue, Aug 16, 2022 at 8:10 AM David Vernet <void@...ifault.com> wrote:
>
> On Mon, Aug 15, 2022 at 02:13:13PM -0700, Hao Luo wrote:
> > >
> > > Iters allow userspace to kick the kernel, but IMO they're meant to enable
> > > data extraction from the kernel, and dumping kernel data into user-space.
> >
> > Not necessarily extracting data and dumping data. It could be used to
> > do operations on a set of objects, the operation could be
> > notification. Iterating and notifying are orthogonal IMHO.
> >
> > > What I'm proposing is a more generalizable way of driving logic in the
> > > kernel from user-space.
> > > Does that make sense? Looking forward to hearing your thoughts.
> >
> > Yes, sort of. I see the difference between iter and the proposed
> > interface. But I am not clear about the motivation of a new APis for
> > kicking callbacks from userspace. I guess maybe it will become clear,
> > when you publish a concerte RFC of that interface and integrates with
> > your userspace publisher.
>
> Fair enough -- let me remove this from the cover letter in future
> versions of the patch-set. To your point, there's probably little to be
> gained in debating the merits of adding such APIs until there's a
> concrete use-case.
>

Yep, sounds good. I don't mean to debate :) I would like to help. If
we could build on top of existing infra and make improvements, IMHO it
would be easier to maintain. Anyway, I'm looking forward to your
proposed APIs.

> Thanks,
> David

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ