Stephen Hemminger <[EMAIL PROTECTED]> writes: > On Fri, 28 Jan 2005 12:45:17 -0800 > "David S. Miller" <[EMAIL PROTECTED]> wrote: > >> On Fri, 28 Jan 2005 21:34:52 +0100 >> Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> wrote: >> >> > Attached the new patch following Arjan's recommendations. >> >> No SMP protection on the SBOX, better look into that. >> The locking you'll likely need to add will make this >> routine serialize many networking operations which is >> one thing we've been trying to avoid. >> > > per-cpu would be the way to go here.
I don't think so no - just doing per cpu counters you risk nearby duplicates, which can cause even easier data corruption (e.g. during ip fragment reassembly - it is already very weak and making it weaker is probably not a good idea) If you want SMP performance for ipids you can resurrect the old "cookie jar" approach I used in 2.4 time frame to get rid of inetpeers. The idea was that you have global state, and each CPU would regenerate some numbers from the state, then store them in a private "jar" and use them use, then look at the global state with locking again etc. This can be tuned on how big the jar is - the bigger the smaller the sequence space (risky for 16bit ipids), but the better the scalability. But before doing anything like this I would recommend that someone skilled in cryptography evaluates the security of these functions carefully and see if it actually has any advantages. I remember that Andrey S. broke some of the "cool" "secure" openbsd IDs easily some years ago. At least for ipids I'm utterly sceptical. 16bits are just hopeless. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
