linux-kernel - RE: [PATCH 0/10] af_unix: add multicast and filtering features to AF

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]

Date:	Thu, 01 Mar 2012 13:50:37 +0100
From:	Rodrigo Moya <rodrigo.moya@...labora.co.uk>
To:	David Laight <David.Laight@...LAB.COM>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	David Miller <davem@...emloft.net>, javier@...labora.co.uk,
	lennart@...ttering.net, kay.sievers@...y.org,
	alban.crequy@...labora.co.uk, bart.cerneels@...labora.co.uk,
	sjoerd.simons@...labora.co.uk, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: RE: [PATCH 0/10] af_unix: add multicast and filtering features to
 AF_UNIX

On Thu, 2012-03-01 at 12:33 +0000, David Laight wrote:
> > > So, now we are trying a different approach. To create a new address
> > > family AF_MCAST. That way we can have more control over the
> semantics of
> > > the socket interface for that family.
> > > 
> > > We expect to have some patches in a few days and we will resend.
> > > 
> > > Does this makes more sense to you?
> > > 
> > 
> > Why adding an obscure set of IPC mechanism in network tree, and not
> > using (maybe extending) traditional IPC (Messages queues, semaphores,
> > Shared memory, pipes, futexes, ...).
> 
> If it isn't a totally silly suggestion, why not write a simple
> device driver that just does what you want?
> Which (I think) is named pipes with multiple readers.
> 
the main problem in D-Bus we are trying to solve is the context
switches, since right now, there is a daemon, which listens on a UNIX
socket, and all traffic in the bus goes through it, and then the daemon
has to route the messages it gets on that socket to the corresponding
place(s). So, every time someone sends a message to D-Bus, since all
traffic goes through the daemon, dbus-daemon gets waked-up, which is one
of the biggest bottlenecks we are trying to fix.

That's why we are thinking about using multicast with socket filters, so
that the daemon only gets traffic it cares about and thus is not waked
up and context switches don't happen when not needed.

Using message queues, AFAICS, we would have the same problem, as the
daemon would create the message queue and would get all traffic, right?

cheers

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