Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Patch 2 of my fast lock series actually also contained an attempt to fix
>> a race I spotted in the code that atomically sets the claimed bit. I
>> forgot about this fact and even, worse, I only replace the original race
>> with another one.
>> So here comes a new attempt to fix the issue that the lock owner and/or
>> the claimed bit can change between trylock and the cmpxchg under nklock.
>> Please have a look and cross-check the logic.
>> The patch applies on top of vanilla SVN, so my series has to be rebased
>> and the fix has to be ported to native as well - where we just found it
>> in the field.
> Could you explain the race ?

We read the owner in pse51_mutex_trylock_internal. In
pse51_mutex_timedlock_internal under nklock, we check that old value for
the claimed bit. If the old value happened to have it set, we continue
happily without worries. But it may have been cleared meanwhile _before_
we entered the nklock.

I previously tried to fix this by re-reading the lock value, but then I
failed to account for the case that the value may have become NULL
meanwhile. The new version should cover both cases.


Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Xenomai-core mailing list

Reply via email to