linux-kernel - Re: [GIT PULL] kdbus for 4.1-rc1

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: <CAEntwhE-Pv3fRVgZV2EDro45W8XfUZ8fCbA0jaUEUh=OJYwPBw@mail.gmail.com>
Date:	Tue, 28 Apr 2015 16:25:31 -0400
From:	Havoc Pennington <hp@...ox.com>
To:	"Theodore Ts'o" <tytso@....edu>, Havoc Pennington <hp@...ox.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	Lukasz Skalski <l.skalski@...sung.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.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-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

On Tue, Apr 28, 2015 at 1:18 PM, Theodore Ts'o <tytso@....edu> wrote:
> So the question is if one of the justifications for moving the daemon
> into kernel space is that it's performance is crap, then I think it is
> useful to determine whether a fully optimized userspace daemon would
> be good enough.
>

Yeah. I don't know how you answer that, because the answer is probably
"it would be good enough for some things and not for other things." It
depends on whether an app is sending enough data to be too slow, and
it depends on the hardware, right.

What I think we might know: the userspace:kernel time-to-send ratio
should always be around 2:1, if both of them are
similarly-implemented, because the userspace version has about 2x the
work to do.

The actual wall-clock time of course depends on the hardware and
what's being sent.

If there was a deviation from 2:1 in a benchmark, it might be because
of implementation issues - so for example libdbus+dbus-daemon might be
3:1 or 5:1 to sd-dbus+kdbus, because sd-dbus isn't as bloated as
libdbus, say. That isn't telling you anything about kernel vs.
userspace architecture, the extra ratio above 2:1 is only telling you
about userspace implementation quality.

For purposes of deciding what to put in kernel - the differences
between dbus client implementations (sd-dbus, libdbus, gdbus, etc.)
seem like irrelevant noise to me.

Re: the slippery slope to LDAP in the kernel - my questions would be
things like 1) what are non-performance reasons to have dbus in the
kernel, such as early boot or security considerations; 2) does LDAP in
kernel give these kind of 2:1 gains; 3) is there a simpler way to get
the 2:1 gain for dbus...

Others can answer those better than I can.

I _would_ say that dbus is more "generic" than something like LDAP;
dbus is specific to the use-case of coordinating processes on a single
machine, but it isn't specific to any particular application, and it's
been used for lots of different applications. On my laptop, which is a
pretty normal fedora 21 as far as I know:

$ rpm -q --whatrequires 'libdbus-1.so.3()(64bit)' | wc -l
113

this omits anyone using a different binding, it's only libdbus users.

> I find dbus to be extremely hard to debug when my desktop starts doing
> things I don't want it to do.  The fact that it might be flinging around hundreds
> of thousands of messages, and that this is something we want to encourage,

This particular argument doesn't resonate with me ... if dbus is hard
to debug, it's not as if "ad hoc application-specific sidechannel
somebody cooked up" is going to be easier.

People aren't usually making up data to send around just because they
can. If they need to send an audio stream, and dbus is too slow,
they'll send it another ad hoc way, but it ultimately has to get sent.
Same for most data, it is the size it is and it needs to go where it
needs to go, for some what-the-user-wants-to-do kind of reason.

If apps have to, they say "I'm sorry Dave I can't do that - you can't
software-decode 4K video on your 300mhz ARM" - of course.

Havoc
--
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/