[systemd-devel] possible message leak in bus->wqueue ?

[David Herrmann]

Hi

On Fri, Aug 7, 2015 at 12:07 PM, cee1 <fykcee1 at gmail.com> wrote:
> 2015-08-07 17:18 GMT+08:00 eshark <eshark77 at 163.com>:
>> Hi, all
>>       If  some message went into bus->wqueue, and  failed to run
>> ioctl(KDBUS_CMD_SEND) and returned  r < 0,
>> I found that this message will remain in the bus->wqueue.   If  the peer is
>> killed for some reason, this message will fail to be sent and remain in the
>> wqueu for ever.
>>
>> Because in  dispatch_wqueue() ,  when bus_write_message() return r <0,
>> dispatch_wqueue() will simply return this  "r " into the caller.
>> And the wqueue is invisible to user application, so user application also
>> cannot   remove this message to handle this error case.
>>
>>  I wonder whether this is a problem, and if yes,  should we remove this
>> message  in dispatch_wqueue() when  r < 0 ?
>
> I've the same question.
>
> E.g.
>
> dispatch_wqueue()
>     bus_write_message()
>         bus_kernel_write_message()
>
> """
> r = ioctl(bus->output_fd, KDBUS_CMD_SEND, &cmd);
> if (r < 0) {
>     ...
>     else if (errno == ENXIO || errno == ESRCH) {
>                         ...
>                         if (m->header->type == SD_BUS_MESSAGE_METHOD_CALL)
>                                 sd_bus_error_setf(&error,
> SD_BUS_ERROR_SERVICE_UNKNOWN, "Destination %s not known",
> m->destination);
>                         else {
>                                 log_debug("Could not deliver message
> to %s as destination is not known. Ignoring.", m->destination);
>                                 return 0;

This probably needs to be "return 1;". Lennart, any comments?

>                         }
> }
> """
>
> If A __returns__ a result to B, but B has already died (After sending
> a "method call" message):
>
> 1. It will return ENXIO or ESRCH, right?

It returns EBADSLT.

> 2. dispatch_wqueue(), bus_write_message()  and
> bus_kernel_write_message() returns 0
> 3. Next time dispatch_wqueue() called, it will retry, but never
> succeed - so, deadlocked?

Thanks
David