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] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120905.173023.2235590074897156746.davem@davemloft.net>
Date:	Wed, 05 Sep 2012 17:30:23 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	nicolas.ferre@...el.com
Cc:	netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	havard@...nnemoen.net, plagnioj@...osoft.com, jamie@...ieiles.com,
	linux-kernel@...r.kernel.org, patrice.vilchez@...el.com
Subject: Re: [PATCH 04/10] net/macb: Fix a race in macb_start_xmit()

From: Nicolas Ferre <nicolas.ferre@...el.com>
Date: Wed, 5 Sep 2012 10:19:11 +0200

> From: Havard Skinnemoen <havard@...nnemoen.net>
> 
> Fix a race in macb_start_xmit() where we unconditionally set the TSTART bit.
> If an underrun just happened (we do this with interrupts disabled, so it might
> not have been handled yet), the controller starts transmitting from the first
> entry in the ring, which is usually wrong.
> Restart the controller after error handling.
> 
> Signed-off-by: Havard Skinnemoen <havard@...nnemoen.net>
> [nicolas.ferre@...el.com: split patch in topics]
> Signed-off-by: Nicolas Ferre <nicolas.ferre@...el.com>

Accumulating special case code and checks into the hot path of TX packet
processing is extremely unwise.

Instead, when you handle the TX error conditions and reset the chip you
should first ensure that there are no flows of control in the transmit
function of your driver by using the appropriate locking et al. facilities.

For example, you can quiesce the transmit path by handling the chip error
interrupt as follows:

1) Disable chip interrupt generation.

2) Schedule a workqueue so you can process the reset outside of hard
   interrupt context.

3) In the workqueue function, disable NAPI and perform a
   netif_tx_disable() to guarentee there are no threads of
   execution trying to queue up packets for TX into the driver.

4) Perform your chip reset and whatever else is necessary.

5) Re-enable NAPI and TX.

Then you don't need any special checks in your xmit method at all.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ