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

[yzhu1]

On 10/27/2015 05:28 AM, David Smith wrote:
> On 10/25/2015 10:19 PM, yzhu1 wrote:
>> Hi, David
>>
>> I do not have this backtrace. Because STP_ALLOC_SLEEP_FLAGS will cause
>> kmalloc sleep,
>> so I replaced it with STP_ALLOC_FLAGS.
> Evidently I'm not explaining myself well, I'll try again in more detail.
>
> We've got 2 sets of allocation flags in systemtap:
>
> STP_ALLOC_FLAGS: These are the default flags and allocations using this
> set of flags will not sleep.
>
> STP_ALLOC_SLEEP_FLAGS: These flags are only supposed to be used from
> contexts where it is safe to sleep (like begin probes).
>
> Here's the big question - on the realtime kernel, is it ever safe to sleep?
>
> If the answer to the previous question is "no", then your change is correct.
>
> If the answer to the previous question is "yes", then your change isn't
> correct. Instead, we need to look at uses of STP_ALLOC_SLEEP_FLAGS,
> because we're using the wrong set of flags somewhere. We're using
> STP_ALLOC_SLEEP_FLAGS in an allocation that should be using STP_ALLOC_FLAGS.
>
> I see 6 uses of STP_ALLOC_SLEEP_FLAGS in the systemtap source. If we
> can't get a backtrace, then I'll need you to change the 6 uses of
> STP_ALLOC_SLEEP_FLAGS to STP_ALLOC_FLAGS one at a time to figure out
> which use of STP_ALLOC_SLEEP_FLAGS isn't correct.
>
> Thanks for continuing to work this problem.
Hi, All

OK. I will do.

Zhu Yanjun
>
>
>> Zhu Yanjun
>>
>> On 10/23/2015 12:34 AM, David Smith wrote:
>>> On 10/22/2015 02:46 AM, Zhu Yanjun wrote:
>>>> -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.
>>> In general, this patch looks fine. However, I'm not too sure about the
>>> STP_ALLOC_SLEEP_FLAGS bit. Can show us a backtrace that happens with
>>> your spinlock changes but without the alloc flags changes or explain why
>>> the alloc flags change is necessary? It could be that we're using the
>>> wrong set of flags in the caller.
>>>
>>> Thanks.
>>>
>