Re: [PATCH 01/13] kdbus: add documentation

[Daniel Mack]

Hi Andy,

On 01/29/2015 01:09 PM, Andy Lutomirski wrote:
> On Jan 29, 2015 6:42 AM, "Daniel Mack" <daniel@xxxxxxxxxx> wrote:

>> As we explained before, currently, D-Bus peers do collect the same
>> information already if they need to have them, but they have to do deal
>> with the inherit races in such cases. kdbus is closing the gap by
>> optionally providing the same information along with each message, if
>> requested.
> 
> In all these discussions, no one ever gave a decent example use case.
> If a process drops some privilege, it must close all fds it has that
> captured its old privilege.  This has nothing to do with kdbus.

kdbus does not implement any new concept here but sticks to what
SCM_CREDENTIALS does on SOL_SEQPACKET. An application can get a
file-descriptor from socket() or socketpair() and freely pass it around
between different tasks or threads, but messages will always have the
credentials attached that are valid at *send* time. SO_PEERCREDS,
however, still reports the connect-time credentials, and kdbus provides
exactly the same semantics and both ways of retrieving information.

> I agree that the design seems to have improved to a state of being at
> least decent,

One reason for that is your feedback. Thanks for that again!

> It's an optional feature that will get used, non-optionally, thousands
> of times on each boot, apparently.  Keep in mind that it's also a
> scalability problem because it takes locks.  If it ever gets used
> thousands of times per CPU on a big thousand-core machine, it's going
> to suck, and you'll have backed yourself into a corner.

That's right, but again - if an application wants to gather this kind of
information about tasks it interacts with, it can do so today by looking
at /proc or similar sources. Desktop machines do exactly that already,
and the kernel code executed in such cases very much resembles that in
metadata.c, and is certainly not cheaper. kdbus just makes such
information more accessible when requested. Which information is
collected is defined by bit-masks on both the sender and the receiver
connection, and most applications will effectively only use a very
limited set by default if they go through one of the more high-level
libraries.

Also, when metadata is collected, the code mostly takes temporary
references on objects like PIDs, namespaces etc. Which operation would
you consider particularly expensive?


Thanks again,
Daniel

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