netdev - Re: ixgbe: [RFC] [PATCH] Fix return of invalid txq

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: <20100115.004305.73783675.davem@davemloft.net>
Date:	Fri, 15 Jan 2010 00:43:05 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	krkumar2@...ibm.com
Cc:	netdev@...r.kernel.org, jeffrey.t.kirsher@...el.com
Subject: Re: ixgbe: [RFC] [PATCH] Fix return of invalid txq

From: Krishna Kumar <krkumar2@...ibm.com>
Date: Fri, 15 Jan 2010 11:01:17 +0530

> A developer had complained of getting lots of warnings:
> 
> "eth16 selects TX queue 98, but real number of TX queues is 64"
> 
> http://www.mail-archive.com/e1000-devel@lists.sourceforge.net/msg02200.html
> 
> As there was no follow up on that bug, I am submitting this
> patch assuming that the other return points will not return
> invalid txq's, and also that this fixes the bug (not tested).
> 
> Signed-off-by: Krishna Kumar <krkumar2@...ibm.com>

Guys I'm really sick of seeing this bug.  Stop assuming that the
platform has limitations that platforms you happen to work on have.

NR_CPUS can be 4096, so you must assume everywhere that
smp_processor_id() can return just about any number.

Modulo the damn thing, or similar.

Don't use tables or crap like that.  We do like Krishna's scheme
in net/core/dev.c:skb_tx_hash(), and that's what we should do
here too.

Krishna's patch is therefore correct, and I don't want to hear
anything about "tables", unless you're going to add "tables"
to net/core/dev.c :-)

--
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