Re: schdule bug in 4.4.38-rt49

["xiaoqiang.zhao" <zhaoxiaoqiang007@gmail.com>]

在 2019/7/4 下午6:17, xiaoqiang.zhao 写道:
> Resend as plain-text to linux-rt-users list.
>
> 在 2019/7/4 下午1:50, xiaoqiang.zhao 写道:
>
> 在 2019/7/3 下午7:42, Sebastian Andrzej Siewior 写道:
>> On 2019-06-26 15:35:04 [+0800], xiaoqiang.zhao wrote:
>>> Hi, guys:
>> Hi,
>>
> Thanks for your reply ;-)
>
>>> 2) -> __schedule_bug ( leads to kernel pagefault exception, OOPS!!)
>>>
>>> Before schedule, we have call preempt_disable twice, this will 
>>> definitely
>>> bump preempt_count to 2 and
>>
>> something probably disabled preemption before that
>
> I feel this is not make sense.  In my opinion, the preempt_count must 
> be zero before we call 'schedule()',
>
> otherwise, in_atomic_preempt_off will return true and trigger the 
> __schedule_bug. If we have already
>
> disable_preempt, we may in atomic context and we should not call 
> schedule, right ?
>
>>> in_atomic_preempt_off will fail.
>>>
>>> I did not figure out:   WHY we call schedule inside 
>>> rt_spin_lock_slowlock
>>> and under what condition this call is correct ?
>> if the lock is acquired you schedule out and wait und it is available
>> again.
> got this.
>
>
>>

Finally, this issue is resolved by revert commit 
80127a39681bd68c959f0953f84a830cbd7c3b1c <locking/percpu-rwsem: Optimize 
readers and reduce global impact>.  This commit introduce a 
"preempt_disable()" call in "percpu_up_read" function and  can NOT 
coexist with 4.4.38-rt49 preempt-rt patch set

Hope this information may be useful to someone who encounter the same 
problem ;-)

Thanks Sebastian !