netdev - Re: [PATCH v3 6/6] net: sh

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20120514.185034.399229364191924851.davem@davemloft.net>
Date:	Mon, 14 May 2012 18:50:34 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	yoshihiro.shimoda.uh@...esas.com
Cc:	netdev@...r.kernel.org, linux-sh@...r.kernel.org
Subject: Re: [PATCH v3 6/6] net: sh_eth: use NAPI

From: "Shimoda, Yoshihiro" <yoshihiro.shimoda.uh@...esas.com>
Date: Mon, 14 May 2012 15:47:24 +0900

> This patch modifies the driver to use NAPI.
> 
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>

I think your TX path is still extremely racey.

No locks are held here, so you tell me what happens if we execute:

> +	/* check txdesc */
> +	txfree_num = sh_eth_txfree(ndev);
> +	if (txfree_num)

and at this exact moment the queue was in fact already awake and
another thread of control transmits packets, and this action fills up
the TX queue and stops the queue.

>  		netif_wake_queue(ndev);

This will erroneously wake the queue and trigger the debugging
message in your TX function.

You need strict synchronization between your TX queueing and TX
liberation flows.  So that queue stop and wake are only performed
at the correct moment.

In fact, looking at how the mdp->lock is used in your TX routine, it
seems to protect absolutely against nothing.

Please read the TX flow of drivers/net/ethernet/broadcom/tg3.c to see
how to do this correctly, and lock free, in a NAPI driver.
--
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