On 08/18/2016 09:05 AM, Feng Gao wrote:
On Thu, Aug 18, 2016 at 10:11 PM, Philp Prindeville
<philipp@xxxxxxxxxxxxxxxxxxxxx> 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 done? Is the 2nd flow running at a higher
>priority or with interrupts disabled?
There is no preemption happened. It is caused by wrong route policy by l2tp.
For example, the cpu0 get the spinlock of channel1, then the channel1
is selected again after route. As a result, cpu0 tries to get the same
spinlock again.
The call flow is like this.
ppp_write->ppp_channel_push->start_xmit->select inappropriate route
.... -> dev_hard_start_xmit->ppp_start_xmit->ppp_xmit_process->
ppp_push. Now ppp_push tries to get the same spinlock which is held
in ppp_channel_push.
Regards
Feng
If we're detecting (through the fact that the lock has already been
acquired) that the wrong route is being applied, why don't we just punt
the packet instead?
-Philip
--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
