linux-kernel - Re: kdbus: to merge or not to merge?

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: <CALCETrXcqOFedk8r-jHK-deRwfum29JHspALE6JUi2gzbo-dhg@mail.gmail.com>
Date:	Thu, 6 Aug 2015 08:21:58 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	David Herrmann <dh.herrmann@...il.com>
Cc:	Tom Gundersen <teg@...m.no>,
	"Kalle A. Sandstrom" <ksandstr@....fi>,
	Greg KH <gregkh@...uxfoundation.org>,
	Borislav Petkov <bp@...en8.de>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Havoc Pennington <havoc.pennington@...il.com>,
	Daniel Mack <daniel@...que.org>,
	Djalal Harouni <tixxdz@...ndz.org>, cee1 <fykcee1@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: kdbus: to merge or not to merge?

On Aug 6, 2015 1:04 AM, "David Herrmann" <dh.herrmann@...il.com> wrote:
> >          Given that all existing prototype userspace that I'm aware of
> > (systemd and its consumers) apparently opts in, I don't really care
> > that the feature is opt-in.
>
> This is just plain wrong. Out of the dozens of dbus applications, you
> found like 9 which are buggy? Two of them are already fixed, the
> maintainers of the other ones notified.
> I'd be interested where you got this notion that "all existing
> prototype userspace [...] opts in".
>

I would say instead that, out of one in-use kdbus library, I found one
that was buggy.  Maybe gdbus really does use kdbus already, but on
very brief inspection it looked like it didn't at least on my test VM.

>
> > Also, you haven't addressed the memory usage issues --
>
> ..because it doesn't change anything. If your IPC is message based and
> async, _someone_ needs to buffer. I don't see the difference between
> buffering locally on !EPOLLOUT or buffering in a shmem pool. In both
> cases, clients have control over the buffer size. If you disagree,
> please _elaborate_.

If the client buffers on !EPOLLOUT and has a monster buffer, then
that's the client's problem.

If every single program has a monster buffer, then it's everyone's
problem, and the size of the problem gets multiplied by the number of
programs.

Also, sensible clients that produce bulk data will throttle on
!EPOLLOUT rather than blindly buffering, but that's not an option when
the huge buffer is on the receiver's end.  Read up on "bufferbloat".

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