On 09.04.2020 13:53, Julia Lawall wrote:
> On Thu, 9 Apr 2020, Alexander Popov wrote:
>> virtual report
>>
>> @race exists@
>> expression E;
>> position stop_p;
>> position unlock_p;
>> position lock_p;
>> @@
>>
>> mutex_unlock@unlock_p(E)
>> ...
>
> It would be good to put when != mutex_lock(E) after the ... above. Your
> rule doesn't actually prevent the lock from being retaken.
Thanks Julia! I used this trick in the second version of the rule that I've just
sent.
>> kthread_stop@stop_p(...)
>> ...
>> mutex_lock@lock_p(E)
>>
>> @script:python@
>> stop_p << race.stop_p;
>> unlock_p << race.unlock_p;
>> lock_p << race.lock_p;
>> E << race.E;
>> @@
>>
>> coccilib.report.print_report(unlock_p[0], 'mutex_unlock(' + E + ') here')
>> coccilib.report.print_report(stop_p[0], 'kthread_stop here')
>> coccilib.report.print_report(lock_p[0], 'mutex_lock(' + E + ') here\n')
...
> Based on Jann's suggestion, it seem like it could be interesting to find
> these locking pauses, and then collect functions that are used in locks
> and in lock pauses. If a function is mostly used with locks held, then
> using it in a lock pause could be a sign of a bug. I will see if it turns
> up anything interesting.
Do you mean collecting the behaviour that happens between unlocking and locking
and then analysing it somehow?
Best regards,
Alexander
