netdev - Re: [PATCH 3/4] sfc: resolve tx multiqueue bug

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: <20080722.143313.147630363.davem@davemloft.net>
Date:	Tue, 22 Jul 2008 14:33:13 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jgarzik@...ox.com
Cc:	bhutchings@...arflare.com, netdev@...r.kernel.org,
	linux-net-drivers@...arflare.com
Subject: Re: [PATCH 3/4] sfc: resolve tx multiqueue bug

From: Jeff Garzik <jgarzik@...ox.com>
Date: Tue, 22 Jul 2008 17:29:59 -0400

> David Miller wrote:
> > From: Ben Hutchings <bhutchings@...arflare.com>
> > Date: Tue, 22 Jul 2008 19:41:19 +0100
> > 
> >> So long as a queue is only woken in response to TX completions, the current
> >> arrangement is fine.  However, sfc needs to tear down and restart hardware TX
> >> queues as part of some reconfiguration, self-test and recovery code, and I
> >> doubt it's the only such driver.
> > 
> > Mark the carrier off and packets will stop flowing to the driver.
> 
> Yep.
> 
> Though based on looking at a lot of existing driver code, I think this 
> is sometimes unclear to driver writers -- when to manage carrier 
> (netif_carrier_on/off) and when to manage queue flow 
> (netif_queue_start/stop/wake).

This is true.

My current plan is to fix up as many drivers as possible, and
assuming the reality that we can't expect to fix them all
by 2.6.27 we will remove the WARN_ON_ONCE from __netif_schedule()
right before 2.6.27-final then reinstate it for the 2.6.28
merge window.
--
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