Re: [GIT PULL] kdbus for 4.1-rc1

[One Thousand Gnomes]

> On top of that, I think that someone into resource management needs to
> seriously consider whether having a broadcast send do get_user_pages
> or the equivalent on pages supplied by untrusted recipients (plural!)
> is a good idea.

Oh but its so much fun if you pass pages belonging to a device driver, or
pass bits of a GEM object thereby keeping entire graphics textures
referenced 8)

The get_user_pages stuff looks like  simple case of premature
optimisation (or I suspect pessmimisation). If bulk data goes via
memfd/splice/socket point to point as it should (or via shared memory
objects) then you don't need all the page pinning and that begins to
simplify the code a lot. Copies of small messages are cheap if not free
on most processors. Its a memcpy into a simple refcounted buffer which
gets deleted when the refcount hits zero.

(I'd argue for also looking at stuff like GEM and the dma buffers for some
of the big stuff. As we move towards more and more accelerators again
being able to pass around handles between accelerator more and more
important)

We do need something for the multicast messaging. Whether that's
supporting AF_LOCAL, SOCK_RDP with multicast or something else (POSIX
message queue extensions ?). There's no real IP layer reliable ordered
multicast delivery system that is low latency and lightweight because
once it hits real networks it changes from a hard problem into a
seriously hard problem because of multicast implosions and the like.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/