From: Vincent Sanders <vincent.sanders@collabora.co.uk>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Benjamin LaHaise <bcrl@kvack.org>,
David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: AF_BUS socket address family
Date: Mon, 2 Jul 2012 15:51:15 +0100 [thread overview]
Message-ID: <20120702145114.GD28593@mail.collabora.co.uk> (raw)
In-Reply-To: <20120630135240.41dbaacf@pyramind.ukuu.org.uk>
On Sat, Jun 30, 2012 at 01:52:40PM +0100, Alan Cox wrote:
> On Fri, 29 Jun 2012 20:13:50 -0400
> Benjamin LaHaise <bcrl@kvack.org> wrote:
>
> > On Sat, Jun 30, 2012 at 12:42:30AM +0100, Vincent Sanders wrote:
> > > The current users are suffering from the issues outlined in my
> > > introductory mail all the time. These issues are caused by emulating an
> > > IPC system over AF_UNIX in userspace.
> >
> > Nothing in your introductory statements indicate how your requirements
> > can't be met through a hybrid socket + shared memory solution. The IPC
> > facilities of the kernel are already quite rich, and sufficient for
> > building many kinds of complex systems. What's so different about DBus'
> > requirements?
>
> dbus wants to
> - multicast
> - pass file handles
> - never lose an event
> - be fast
> - have a security model
>
> The security model makes a shared memory hack impractical, the file
> handle passing means at least some of it needs to be AF_UNIX. The event
> loss handling/speed argue for putting it in kernel.
Thankyou for making this point more eloquently than I had previously
been able to.
>
> I'm not convinced AF_BUS entirely sorts this either. In particular the
> failure case dbus currently has to handle for not losing events allows it
> to identify who in a "group" has jammed the bus by not listening (eg by
> locking up). This information appears to be lost in the AF_BUS case and
> that's slightly catastrophic for error recovery.
>
The strategy the existing AF_UNIX D-Bus daemon implements is simply to
have huge queues and thus rarely encounters the situation. When It
does the bus daemon crafts an error message as a reply to the sender.
The AF_BUS solution is more direct in that the sender gets either
EAGAIN for a direct send or EPOLLOUT from poll. Whatever the response
the sender can use this information to implement a userspace policy
decision.
Your feedback sparked a discussion and we have considered this in more
depth and propose implementing a userspace policy of:
- sending a message to the bus master and let it "deal" with the
blocking client.
- The bus master might choose to isolate the offending client or
perhaps even cause a service restart etc.
The bus master is a privileged client and has state information
about the bus allowing an optimal decision. Though we intend to
add a socket option to query the queue lengths so it can make a
better decisions.
Regardless this is all userspace policy for the D-Bus client
library / bus master daemon which I believe addresses David Miller's
concerns about such decisions being made in userspace.
--
Best Regards
Vincent Sanders <vincent.sanders@collabora.co.uk>
next prev parent reply other threads:[~2012-07-02 14:51 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-29 16:45 AF_BUS socket address family Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 01/15] net: bus: Add " Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 02/15] net: bus: Add documentation for AF_BUS Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 03/15] net: bus: Add AF_BUS socket and address definitions Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 04/15] security: Add Linux Security Modules hook for AF_BUS sockets Vincent Sanders
2012-07-09 3:32 ` James Morris
2012-07-09 18:02 ` Paul Moore
2012-06-29 16:45 ` [PATCH net-next 05/15] security: selinux: Add AF_BUS socket SELinux hooks Vincent Sanders
2012-07-09 18:38 ` Paul Moore
2012-06-29 16:45 ` [PATCH net-next 06/15] netfilter: Add NFPROTO_BUS hook constant for AF_BUS socket family Vincent Sanders
2012-07-01 2:15 ` Jan Engelhardt
2012-06-29 16:45 ` [PATCH net-next 07/15] scm: allow AF_BUS sockets to send ancillary data Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 08/15] net: bus: Add implementation of Bus domain sockets Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 09/15] net: bus: Add garbage collector for AF_BUS sockets Vincent Sanders
2012-07-02 17:44 ` Ben Hutchings
2012-07-03 12:11 ` Alban Crequy
2012-06-29 16:45 ` [PATCH net-next 10/15] net: bus: Add the AF_BUS socket address family to KBuild Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 11/15] netlink: connector: implement cn_netlink_reply Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 12/15] netlink: connector: Add idx and val identifiers for netfilter D-Bus Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 13/15] netfilter: nfdbus: Add D-bus message parsing Vincent Sanders
2012-06-29 17:11 ` Pablo Neira Ayuso
2012-07-02 15:43 ` Javier Martinez Canillas
2012-07-04 17:30 ` Pablo Neira Ayuso
2012-07-05 17:54 ` Javier Martinez Canillas
2012-06-29 16:45 ` [PATCH net-next 14/15] netfilter: nfdbus: Add D-bus match rule implementation Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 15/15] netfilter: add netfilter D-Bus module Vincent Sanders
2012-06-29 18:16 ` AF_BUS socket address family Chris Friesen
2012-06-29 19:33 ` Ben Hutchings
2012-06-29 18:45 ` Casey Schaufler
2012-06-29 23:22 ` Vincent Sanders
2012-06-29 22:36 ` David Miller
2012-06-29 23:12 ` Vincent Sanders
2012-06-29 23:18 ` David Miller
2012-06-29 23:42 ` Vincent Sanders
2012-06-29 23:50 ` David Miller
2012-06-30 0:09 ` Vincent Sanders
2012-06-30 13:12 ` Alan Cox
2012-07-01 0:33 ` David Miller
2012-07-01 14:16 ` Alan Cox
2012-07-01 21:45 ` David Miller
2012-06-30 0:13 ` Benjamin LaHaise
2012-06-30 12:52 ` Alan Cox
2012-07-02 14:51 ` Vincent Sanders [this message]
2012-07-02 4:49 ` Chris Friesen
2012-07-05 21:06 ` Jan Engelhardt
2012-07-06 18:27 ` Chris Friesen
2012-06-30 20:41 ` Hans-Peter Jansen
2012-07-02 16:46 ` Alban Crequy
2012-07-05 7:59 ` Linus Walleij
2012-07-05 16:01 ` Daniel Walker
-- strict thread matches above, loose matches on Subject: below --
2012-07-02 15:18 Javier Martinez Canillas
2012-07-03 16:52 ` Chris Friesen
2012-07-03 17:18 ` Chris Friesen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120702145114.GD28593@mail.collabora.co.uk \
--to=vincent.sanders@collabora.co.uk \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bcrl@kvack.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).