On 2013-01-06 14:55, Gilles Chanteperdrix wrote:
> On 01/06/2013 12:03 PM, Jan Kiszka wrote:
>
>> On 2013-01-06 11:55, Jan Kiszka wrote:
>>> On 2013-01-06 11:14, Philippe Gerum wrote:
>>>> On 01/03/2013 03:09 PM, Jan Kiszka wrote:
>>>>
>>>>> +static struct xnvfile_lock_ops vfile_stat_lockops = {
>>>>> + .get = xnintr_get_query_lock,
>>>>> + .put = xnintr_put_query_lock,
>>>>> +};
>>>>> +
>>>>> static struct xnvfile_snapshot stat_vfile = {
>>>>> .privsz = sizeof(struct vfile_stat_priv),
>>>>> .datasz = sizeof(struct vfile_stat_data),
>>>>> .tag = &nkpod_struct.threadlist_tag,
>>>>> .ops = &vfile_stat_ops,
>>>>> + .entry = { .lockops = &vfile_stat_lockops },
>>>>> };
>>>>
>>>> This would introduce a regression. stat_vfile's rewind/next handlers
>>>> compete with code altering the global thread queue which may run in
>>>> primary mode, such as xnpod_delete_thread() when deleting a kernel task.
>>>> So we can't use a linux lock to protect it.
>>>
>>> The Linux lock is held around this rewind loop (which is still in
>>> place), and it is not protecting anything thread related, just the
>>> appearance and disappearance of IRQs. I fail to see a conflict, and
>>> there are also no I-pipe/Xenomai warnings triggered with this pattern.
>>
>> Oh, now I see: The nklock is automatically taken if there are no
>> lockops. That needs to be done in the stat lockups as well, of course.
>> Will fix.
>
>
> The more I think about this, the more I find we should not be doing
> this. Xenomai 2.6.x is a stable branch, let us stop making such changes,
> this will allow us to start working on -forge. The warning is
> essentially a false-positive, I do not see any problem calling
> ipipe_virtualize_irq with the root domain stalled. We can skip it in the
> I-pipe core patches when compiling with CONFIG_IPIPE_LEGACY.
Well, we need to support 2.6 for quite a while here, so I'm interested
in fixing such regressions, also on instrumentations, without increasing
our local queue size. The next version will be less invasive than the
current one. Finally, fixing this issue revealed also other proc output
bugs.
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL:
<http://www.xenomai.org/pipermail/xenomai/attachments/20130106/10ffe864/attachment.pgp>
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
