[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c9169edc-3144-fab1-d176-7a8b9b3e4366@marvell.com>
Date: Wed, 7 Dec 2016 14:18:19 +0100
From: Lino Sanfilippo <lsanfil@...vell.com>
To: Pavel Machek <pavel@....cz>,
Lino Sanfilippo <LinoSanfilippo@....de>
CC: Giuseppe CAVALLARO <peppe.cavallaro@...com>,
<alexandre.torgue@...com>, David Miller <davem@...emloft.net>,
<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Re: Re: stmmac ethernet in kernel 4.9-rc6: coalescing
related pauses.
Hi,
On 07.12.2016 13:31, Pavel Machek wrote:
> On Fri 2016-12-02 15:05:21, Lino Sanfilippo wrote:
>> Hi,
>>
>>
>>>
>>> There's nothing that protect stmmac_poll() from running concurently
>>> with stmmac_dma_interrupt(), right?
>>>
>>
>> could it be that there is also another issue concerned locking?:
>> The tx completion handler takes the xmit_lock in case that the
>> netif_queue is stopped. This is AFAICS unnecessary, since both
>> xmit and completion handler are already synchronized by the private
>> tx lock. But it is IMHO also dangerous:
>>
>> In the xmit handler we have the locking order
>> 1. xmit_lock
>> 2. private tx lock
>>
>> while in the completion handler its the reverse:
>>
>> 1. private tx lock
>> 2. xmit lock.
>>
>> Do I miss something?
>
> No, it seems you are right. Something like this?
>
> Hmm. And can priv->tx_lock be removed, as we already rely on
> netif_tx_lock?
>
David wanted indeed the private lock to be removed completely. See
this thread.
https://marc.info/?l=linux-netdev&m=148072001900620&w=2
If you can wait a bit, I already have patches prepared to fix this issue in both
drivers. I want to send them as soon as I am at home (a few hours).
Regards,
Lino
Powered by blists - more mailing lists