On Thu, Aug 18, 2016 at 08:11:15AM -0600, Philp Prindeville wrote:
>
> It seems unlikely to me that this sort of locking problem hasn't existed
> elsewhere before and that an entirely new mechanism for handling it is
> needed... How are similar re-entrancy issues handled elsewhere?
>
Virtual devi
Hi Philip,
I answer your question inline.
On Thu, Aug 18, 2016 at 10:11 PM, Philp Prindeville
wrote:
> Feng,
>
> If the CPU can already be holding the lock, that implies re-entrancy.
> What's to stop the first flow of code which acquired the lock from releasing
> it again before the 2nd flow is
Hi Philp,
Yes. I am agree with you.
Just drop is better to support recursive lock.
I will send a new patch later.
Regards
Feng
On Fri, Aug 19, 2016 at 12:48 AM, Philp Prindeville
wrote:
>
>
> On 08/18/2016 09:05 AM, Feng Gao wrote:
>>
>> On Thu, Aug 18, 2016 at 10:11 PM, Philp Prindeville
>>
On 08/18/2016 09:05 AM, Feng Gao wrote:
On Thu, Aug 18, 2016 at 10:11 PM, Philp Prindeville
wrote:
>Feng,
>
>If the CPU can already be holding the lock, that implies re-entrancy.
>What's to stop the first flow of code which acquired the lock from releasing
>it again before the 2nd flow is do
Feng,
If the CPU can already be holding the lock, that implies re-entrancy.
What's to stop the first flow of code which acquired the lock from
releasing it again before the 2nd flow is done? Is the 2nd flow running
at a higher priority or with interrupts disabled?
It seems unlikely to me t
Hi Paul,
The v1 patch does not handle the recursive lock case. It could cause
unlock multiple times.
So I send the v2 patch as one update.
Best Regards
Feng
On Tue, Aug 16, 2016 at 7:05 PM, wrote:
> From: Gao Feng
>
> PPP channel holds one spinlock before send frame. But the skb may
> select
From: Gao Feng
PPP channel holds one spinlock before send frame. But the skb may
select the same PPP channel with wrong route policy. As a result,
the skb reaches the same channel path. It tries to get the same
spinlock which is held before. Bang, the deadlock comes out.
Now add one lock owner t
