netdev - Re: [PATCH (net.git)] stmmac: fix and review whole driver locking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <540D47E5.7030005@st.com>
Date:	Mon, 8 Sep 2014 08:08:37 +0200
From:	Giuseppe CAVALLARO <peppe.cavallaro@...com>
To:	David Miller <davem@...emloft.net>
Cc:	<netdev@...r.kernel.org>, <bigeasy@...utronix.de>,
	<khoroshilov@...ras.ru>
Subject: Re: [PATCH (net.git)] stmmac: fix and review whole driver locking

On 9/5/2014 7:22 AM, David Miller wrote:
> From: Giuseppe Cavallaro <peppe.cavallaro@...com>
> Date: Tue, 2 Sep 2014 08:00:03 +0200
>
>> The patch reviews the tx lock removing it because the driver
>> claims the resource in NAPI context and, as designed, can run
>> w/o any own extra lock (so just netif_tx_lock).
>> This shows an impact on performances too.
>
> It's not that simple, you have to make some changes if you really
> want to allow these two threads of control to run asynchronously.
>
> Look at this comment from tg3_tx() in the tg3 driver for example:
>
> ====================
> 	tnapi->tx_cons = sw_idx;
>
> 	/* Need to make the tx_cons update visible to tg3_start_xmit()
> 	 * before checking for netif_queue_stopped().  Without the
> 	 * memory barrier, there is a small possibility that tg3_start_xmit()
> 	 * will miss it and cause the queue to be stopped forever.
> 	 */
> 	smp_mb();
>
> 	if (unlikely(netif_tx_queue_stopped(txq) &&
> ====================
>
> With the lock removed, these two code paths will operate and execute
> completely in parallel with eachother.  Therefore the updates of
> certain TX ring state variables will need to be strictly ordered.

Thanks David for your feedback.

I will take care about this note and analyze the code that in some
parts already forces some instruction to be ordered...maybe it could
cover the problem; indeed, I had not seen any issue when stressing the 
driver on SMP systems also when run more then one nuttcp/iperf/netperf 
instances  (supposing that my tests were ok to trigger the case).

I let you know and in case of news I rework the patch w/o w/ locks
for tx path. I will also do all the tests on my platforms before
sending.

peppe

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html