Re: [PATCH 1/1] stp: rt: replace spin_lock with stp style lock and use STP_ALLOC_FLAGS

[yzhu1 <Yanjun.Zhu@windriver.com>]

Hi, David

Thanks for your comments.

I can not reproduce this problem. And my user can reproduce this problem 
ocassionly.
And I requested him to help me to make tests about your changes. But he 
refused.

So I made auto tests in systemtap after this patch is applied. And I can 
not find any
regressions about this patch.

Best Regards!
Zhu Yanjun

On 11/18/2015 12:45 AM, David Smith wrote:
> On 11/17/2015 02:09 AM, yzhu1 wrote:
>> From: Zhu Yanjun <yanjun.zhu@windriver.com>
>>
>> -rt mode spin lock lead to __might_sleep calltrace.
>> Replacing spin lock with stp type raw lock and
>> changing STP_ALLOC_SLEEP_FLAGS to STP_ALLOC_FLAGS solves the problem.
> I have the same comment I had before. The raw lock changes are fine, but
> I still don't believe the STP_ALLOC_SLEEP_FLAGS change is correct, at
> least not without some further explanation. In the call trace below,
> STP_ALLOC_SLEEP_FLAGS wasn't used from what I can tell.
>
> Did you get a chance to try running systemtap with your raw lock changes
> and the added might_sleep() call patch I sent you?
>
>> Call Trace:
>>   [<ffffffff818d83f1>] dump_stack+0x19/0x1b
>>   [<ffffffff81070e3f>] __might_sleep+0xef/0x160
>>   [<ffffffff818de710>] rt_spin_lock+0x20/0x50
>>   [<ffffffff81178699>] d_path+0x79/0x1a0
>>   [<ffffffffa0047be9>] __stp_get_mm_path.constprop.79+0x49/0x90 [stap_f5bb3e3c9b162aab5a51afc2375fe9cf_2073]
>>   [<ffffffffa004d01b>] __stp_utrace_attach_match_tsk.isra.53+0x7b/0x1b0 [stap_f5bb3e3c9b162aab5a51afc2375fe9cf_2073]
>>   [<ffffffffa004d18c>] __stp_utrace_task_finder_report_exec+0x3c/0x50 [stap_f5bb3e3c9b162aab5a51afc2375fe9cf_2073]
>>   [<ffffffffa0047b59>] utrace_report_exec+0xb9/0x100 [stap_f5bb3e3c9b162aab5a51afc2375fe9cf_2073]
>>   [<ffffffff811674b2>] search_binary_handler+0x332/0x380
>>   [<ffffffff81168d0c>] do_execve_common.isra.24+0x55c/0x640
>>   [<ffffffff81168e08>] do_execve+0x18/0x20
>>   [<ffffffff81169082>] SyS_execve+0x32/0x50
>>   [<ffffffff818e6979>] stub_execve+0x69/0xa0
>