netdev - bonding: should rlb rx_hashtbl be reimplemented?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120227174609.GC816@midget.suse.cz>
Date:	Mon, 27 Feb 2012 18:46:09 +0100
From:	Jiri Bohac <jbohac@...e.cz>
To:	Jiri Bohac <jbohac@...e.cz>
Cc:	Jay Vosburgh <fubar@...ibm.com>,
	Andy Gospodarek <andy@...yhouse.net>, netdev@...r.kernel.org
Subject: bonding: should rlb rx_hashtbl be reimplemented?

On Mon, Feb 27, 2012 at 06:34:00PM +0100, Jiri Bohac wrote:
> [1]: ... unless it is replaced with another value that happens to
> have the same hash -- rx_hashtbl is not a proper hash table. In
> case of a collision, the old entry is replaced by the new one.

Unrelated to this patch:

I believe that with the current implementation, if one needs to
communicate with two hosts with colliding IP addresses, RLB can't
work properly unless you renumber your network (and it will
generate an ARP storm as a side effect!).

Has anyone thought of replacing this strange hash table
implementation with a proper hash table, with colliding entries
in linked lists, some garbage collection when the hash grows too
large (configurable hash table size), etc?

Also, once the code is reworked, it could easily be made to work with
IPv6/ND in additiopn to IPv4/ARP.

I am willing to give this a try -- any thoughts?

-- 
Jiri Bohac <jbohac@...e.cz>
SUSE Labs, SUSE CZ

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