On 9/6/19 6:16 PM, Jan Kiszka wrote:
> On 06.09.19 18:09, Philippe Gerum wrote:
>> On 9/6/19 5:43 PM, Jan Kiszka wrote:
>>> On 06.09.19 16:52, Philippe Gerum via Xenomai wrote:
>>>> On 9/4/19 4:44 PM, Quirin Gylstorff via Xenomai wrote:
>>>>>
>>>>> I tested xenomai-next with xeno-test on 4.19.66+ amd64.
>>>>> This patch triggers a general protection fault during the execution of
>>>>> xeno-test. The log is attached.
>>>>>
>>>> Ok, I'll have a look. Thanks.
>>>>
>>>
>>> I've started to dig into this a bit already but got distracted multiple
>>> times. One thing I already found out: It's not a good idea to close the
>>> fd on unregister without also ensuring that it's no longer pending in
>>> rtdm_fd_cleanup_queue. But fixing that does not resolve the issue we see
>>> with the test case.
>>>
>>> Jan
>>>
>>
>> There is that stupid bug at least:
>>
>> diff --git a/kernel/cobalt/rtdm/device.c b/kernel/cobalt/rtdm/device.c
>> index ea72be15c..64767a3ef 100644
>> --- a/kernel/cobalt/rtdm/device.c
>> +++ b/kernel/cobalt/rtdm/device.c
>> @@ -548,6 +548,8 @@ void rtdm_dev_unregister(struct rtdm_device *dev)
>> xnlock_get_irqsave(&nklock, s);
>> for (;;) {
>> + if (list_empty(&dev->openfd_list))
>> + break;
>> fd = list_get_entry(&dev->openfd_list, struct rtdm_fd, next);
>> if (fd == NULL)
>> break;
>>
>
> Then you can also drop that NULL check - list_get_entry never returns NULL.
>
> I'll remove the commit from next so that you can send a v5.
>
This is only material for discussion illustrating a point, please do not
merge any of those snippets.
--
Philippe.
