linux-kernel - Re: kdbus: add documentation

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: <87zjb8txgo.fsf@mid.deneb.enyo.de>
Date:	Sun, 30 Nov 2014 18:22:31 +0100
From:	Florian Weimer <fw@...eb.enyo.de>
To:	David Herrmann <dh.herrmann@...il.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Jiri Kosina <jkosina@...e.cz>,
	Linux API <linux-api@...r.kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: kdbus: add documentation

* David Herrmann:

> poll(2) and friends cannot return data for changed descriptors. I
> think a single trap for each KDBUS_CMD_MSG_RECV is acceptable. If this
> turns out to be a bottleneck, we can provide bulk-operations in the
> future. Anyway, I don't see how a _shared_ pool would change any of
> this?

I responded to Andy's messages because it seemed to be about
generalizing the pool functionality.

>> kernel could also queue the data for one specific recipient,
>> addressing the same issue that SO_REUSEPORT tries to solve (on poll
>> notification, the kernel does not know which recipient will eventually
>> retrieve the data, so it has to notify and wake up all of them).
>
> We already queue data only for the addressed recipients. We *do* know
> all recipients of a message at poll-notification time. We only wake up
> recipients that actually got a message queued.

Exactly, but poll on, say, UDP sockets, does not work this way.  What
I'm trying to say is that this functionality is interesting for much
more than kdbus.

> Not sure how this is related to SO_REUSEPORT. Can you elaborate on
> your optimizations?

Without something like SO_REUSEPORT, it is a bad idea to have multiple
threads polling the same socket.  The semantics are such that the
kernel has to wake *all* the waiting threads, and one of them will
eventually pick up the datagram with a separate system call.  But the
kernel does not know which thread this will be.

With SO_REUSEPORT and a separately created socket for each polling
thread, the kernel will only signal one poll operation because it
assumes that any of the waiting threads will process the datagram, so
it's sufficient just to notify one of them.

kdbus behaves like the latter, but also saves the need to separately
obtain the datagram and related data from the kernel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/