lkml.org 
[lkml]   [2015]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: kdbus: to merge or not to merge?
From
Hi

On Tue, Aug 4, 2015 at 4:47 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> This is a bug in the proxy (which is already fixed).
>
> Should I expect to see it in Rawhide soon?

Use this workaround until it does:

$ DBUS_SYSTEM_BUS_ADDRESS="kernel:path=/sys/fs/kdbus/0-system/bus"
./your-binary

> Anyway, the broadcasts that I intended to exercise were
> KDBUS_ITEM_ID_REMOVE. Those appear to be broadcast to everyone,
> irrespective of "policy", so long as the "match" thingy allows it.

Matches are opt-in, not opt-out. Nobody will get this message unless
they opt in.

> The bloom filter thing won't help at all according to the docs: bloom
> filters don't apply to kernel-generated notifications.

Bloom filters apply to message payloads. Kernel notifications do not
carry a message payload. Message metadata can be filtered for
explicitly (without false-positives).

> So yes, as far as I can tell, kdbus really does track object lifetime
> by broadcasting every single destruction event to every single
> receiver (subject to caveats above) and pokes the data into every
> receiver's tmpfs space.

Broadcast reception is opt-in.

Thanks
David


\
 
 \ /
  Last update: 2015-08-05 09:41    [W:0.179 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site