Stephen Hemminger wrote:
The bug is in r8139too.c driver. It calls flush_scheduled_work
with RTNL mutex held, so any other work using it will get stuck.
It looks like a fairly common problem, as tg3 has the same issue
(though it seems someone tried to hack around one particular case):
static int tg3_close(struct net_device *dev)
{
struct tg3 *tp = netdev_priv(dev);
/* Calling flush_scheduled_work() may deadlock because
* linkwatch_event() may be on the workqueue and it will try to get
* the rtnl_lock which we are holding.
*/
while (tp->tg3_flags & TG3_FLAG_IN_RESET_TASK)
msleep(1);
netif_stop_queue(dev);
e1000 appears clean, at least, but there are a lot of other
drivers that are calling that method (I didn't check to see
if they might be holding rtnl when called.)
Thanks,
Ben
Has this been fixed in later releases?
No but a different race (with device removal) has been fixed.
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
