Re: [GIT PULL] kdbus for 4.1-rc1

[Havoc Pennington]

On Fri, Apr 17, 2015 at 9:23 AM, Daniel Mack <daniel@xxxxxxxxxx> wrote:
>
> This can only happen with user-originated DBus signal messages. For
> unicast messages such as method calls, the sender will actually see
> -EXFULL, and no part of the message is transmitted, leaving neither side
> in a confused state.

Well - big asterisk, * no confused state IF the sender handles EXFULL
in a reasonable way.  Which it probably doesn't most of the time :-)
but as you say it's no worse than it ever was.

> But yes, for broadcast signal messages, we can't
> reject the sender because one single peer is out of buffer space, and we
> can't allow boundless allocations on the receiver either, so informing
> the other side is the best we can do.

If this was ever going to happen (if the limits weren't high), I do
think it would be better to disconnect or throttle/backpressure
somehow, instead of breaking semantics. But the trouble is figuring
out how to do that... I don't know how. So the alternative is to set
high limits.

I think you're fine, it obviously works OK with the current userspace
daemon that punts in a similar way, and unix has a long tradition of
limits like this plus applications sucking at handling the "limit
reached" errors. It'll all work out...

> Note that dbus-daemon just drops such signals silently. So with this
> counter we simply add a debug mechanism for now. There hasn't been a
> consensus on how to react to such errors on the application level. The
> easiest way is obviously to re-sync all your state with the peer (which
> could be as easy as calling ObjectManager.GetManagedObjects() or
> Properties.GetAll()).

It's not realistic to expect the bulk of apps to handle this thing.
Special system services such as pid 1, you probably have the expertise
and time to try to carefully restore all state. Regular old apps will
get confused in practice if limits are hit in practice, but people
will configure the limits such that they're only hit if there's some
pathology going on.

>> How to handle a send error depends a lot on what's being sent... but
>> if I were writing a general-purpose library wrapper, I'd be very
>> tempted to hide EXFULL behind an unbounded (or very-high-bounded)
>> userspace send buffer, which of course is what you were trying to
>> avoid, but I am skeptical that the average app will handle this error
>> sensibly.
>
> Actually, we see no real difference between constrained outgoing or
> incoming buffers. Even with a very-high-bounded send-buffer, you still
> need to deal with it running full.

What I'm saying is that there's a practical difference between limits
low enough to be hit in normal operation, and limits high enough that
someobody has to be evil/broken before you hit them. With the "throw
an error" setup, if you set the limits low enough to be hit in
practice, then userspace will be buggy and break - that's my
prediction at least.

It's not different from say the file descriptor limits. If you crank
down your allowed open descriptors such that a user session actually
hits the limit, pretty much the session isn't usable. That's all I'm
saying.

If you wanted to be able to configure the limits low, where they'd be
hit in practice, then I think you'd want to look at some solution
other than tossing these errors that people will fail to handle
correctly, even if that solution were complex and/or heuristic. If you
set the limits high, it doesn't really matter so you can KISS.

It's sort of an academic point ... tons of kernel features already
have this issue. So carry on, you're good. :-)

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