netdev - Re: [PATCH net 0/3] be2net fixes

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]

Date:	Thu, 5 Dec 2013 15:58:45 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	David Miller <davem@...emloft.net>
CC:	<Somnath.Kotur@...lex.Com>, <netdev@...r.kernel.org>
Subject: Re: [PATCH net 0/3] be2net fixes

On Thu, 2013-12-05 at 01:28 -0500, David Miller wrote:
> From: Somnath Kotur <Somnath.Kotur@...lex.Com>
> Date: Thu, 5 Dec 2013 06:24:10 +0000
> 
> >> This is absolutely not something an individual driver should decide to do,
> >> _EVERY_ driver has this issue.
> > 
> > OK, Understood, guess you want this to ideally be handled somewhere up in the stack/framework?
> 
> I think it's pointless to do at all.

It's not entirely pointless - if there is a lot of unwanted multicast
traffic the change to all-multicast can substantially increase CPU load
and the reason for this may not be obvious since there is no way to find
out the real state of the hardware filter (or even the real state of the
IFF_ALLMULTI flag).

The same may be true if an interface is automatically switched into
promiscuous mode, though switches can generally be assumed to filter
unicast traffic properly.

It seems like it would be useful to expose the real state of the
hardware filter to userland - just not through log messages.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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