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.
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/f836c9a4/attachment.pgp>
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
