netdev - Re: Extensible hashing and RCU

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]

Date:	Thu, 22 Feb 2007 03:07:55 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	medwards.linux@...il.com
Cc:	johnpol@....mipt.ru, dada1@...mosbay.com, akepner@....com,
	linux@...izon.com, netdev@...r.kernel.org, bcrl@...ck.org
Subject: Re: Extensible hashing and RCU

From: "Michael K. Edwards" <medwards.linux@...il.com>
Date: Thu, 22 Feb 2007 03:00:32 -0800

> Besides, RCUing a hash of any sort sounds like a nightmare, whereas
> something like a splay tree is reputed to be very straightforward to
> make "persistent" in the functional-programming sense.  I haven't
> coded that one myself but surely it's in the current edition of Knuth.

Knuth tends to be thorough, yet archaic. :-)

> You are much better off obtaining all per-flow state with a
> single data structure lookup.  It would be kind of nice if state for
> other layers like IPSec and NAT could live there too.

This is the eventual idea.

> By the way, are these flows unidirectional or bidirectional?

The entries created by Robert's TRASH are unidirectional, they have to
be because the path from remote to localhost is different than the
path from localhost to remote :-)

But we don't need to do a socket demux on packet output, we just
need a plain route (+ firewall, IPSEC, etc.) destination cache
entry for that.
-
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