Re: [Xenomai] Issue in __threadobj_unlock_sched (forge/mercury)

[Matthias Schneider <ma30002000@yahoo.de>]

----- Original Message -----

> From: Philippe Gerum <rpm@xenomai.org>
> To: Matthias Schneider <ma30002000@yahoo.de>; "xenomai@xenomai.org" <xenomai@xenomai.org>
> Cc: 
> Sent: Thursday, May 1, 2014 2:54 PM
> Subject: Re: [Xenomai] Issue in __threadobj_unlock_sched (forge/mercury)
> 
> On 05/01/2014 01:42 PM, Matthias Schneider wrote:
> 
>>  Hi all,
>> 
>>  it seems __threadobj_unlock_sched has a slight bug
>>  and does not reset the current->policy value.
>>  This leads to the old policy being restored, but
>>  no longer being available for the next
>>  __threadobj_lock_sched / __threadobj_unlock_sched
>>  call pair.
>> 
> 
> That would mean that the client code switches between different 
> scheduling policies while holding the scheduler lock?
> 
> -- 
> Philippe.
> 

Consider the following scenario:

a) threads may hold SCHED_RT, SCHED_RR or SCHED_OTHER while not in 
threadobj_lock_sched(). (see e.g. threadobj_set_priority).

b) threadobj_lock_sched() saves prio and policy and sets it to 
SCHED_RT/threadobj_lock_prio

c) threadobj_unlock_sched() will restore (correctly) previous 
settings, but not update the threadobj's policy

d) next time threadobj_lock_sched() is called, it will save prio 
and priority, howver policy will always be SCHED_RT (which is 
not the currently set policy before upgrading it)

e) threadobj_unlock_sched() will restore prio and incorrectly saved
policy, which is always SCHED_RT -> threads that originally had
SCHED_RR or SCHED_OTHER now have SCHED_RT


Changing prio while holding the scheduler lock should be handled 
fine due to :

threadobj_set_priority():
if (thobj->schedlock_depth > 0) {
  thobj->core.prio_unlocked = prio;
  thobj->core.policy_unlocked = prio ? SCHED_RT : SCHED_OTHER;
  threadobj_unlock(thobj);
  return 0;
 }

Matthias