[lttng-dev] [PATCH lttng-tools v2] Change lttng_poll_wait behaviour of compat-poll to match compat-epoll

Mathieu Desnoyers mathieu.desnoyers at efficios.com
Mon Mar 25 11:56:11 EDT 2019


----- On Mar 25, 2019, at 11:10 AM, Jeremie Galarneau jeremie.galarneau at efficios.com wrote:

> On Fri, 22 Mar 2019 at 11:04, Mathieu Desnoyers
> <mathieu.desnoyers at efficios.com> wrote:
>>
>> ----- On Mar 21, 2019, at 4:25 PM, Jeremie Galarneau
>> jeremie.galarneau at efficios.com wrote:
>>
>> [...]
>> >> +               assert(idx < events->wait.nb_fd);
>> >
>> > Not needed. Using assert() is fine to highlight assumptions across
>> > interfaces/functions and/or catch catastrophic internal errors. Here,
>> > this would be a very local condition that seems to be already
>> > enforced.
>> >
>> > Reworking the 'for' condition to use 'i < events->wait.nb_fd' and
>> > breaking out early of the loop is also an option here.
>>
>> The reason for using assert() here is to ensure that there is no discrepancy
>> between the number of active poll fd in the set and the value returned by
>> poll indicating that same number of active fds.
>>
>> We'd need a kernel bug (or memory corruption) to have a mismatch, but I thought
>> having an assert in there would not hurt, since it might help diagnose issues
>> that cross user-kernel boundaries.
>>
>> Thoughts ?
> 
> Hi,
> 
> I understand the intent, but I don't feel these type of kernel tests/checks
> belong in the code.
> 
> However, if there is a specific concern that our use of poll() could highlight
> this type of bug (in the kernel or in the interactions with lttng-modules),
> we can add tests for that.

There is no specific concern. We can remove the assert.

Thanks,

Mathieu

> 
> Thanks,
> Jérémie
> 
>>
>> Mathieu
>>
>> --
>> Mathieu Desnoyers
>> EfficiOS Inc.
>> http://www.efficios.com
> 
> 
> --
> Jérémie Galarneau
> EfficiOS Inc.
> http://www.efficios.com

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com


More information about the lttng-dev mailing list