Re: [PATCH 1/1] ppp: Fix one deadlock issue of PPP when send frame

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
[off-list ref] wrote:

On 08/18/2016 09:05 AM, Feng Gao wrote:

quoted

On Thu, Aug 18, 2016 at 10:11 PM, Philp Prindeville
[off-list ref]  wrote:

quoted

quoted

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