> > 	Hmm, this will save us from searching.  Thanks.
> > 	Is there any use for this extra structure other than in tcp?
> > 	(I guess not)
> > 	If not, I'd point it from syn cache and tcpcb, since to add
> > 	pointer to struct socket the pointer must be of universal use.
>It seems to me that when you close a listen socket, you want all of
>its related SYN cache entries to go away, tho (please sanity-check me
>here; I haven't had any coffee yet this morning :-).  So, in your original
>patch, you set sc_so = NULL, but I think you really want to remove the
>entry altogether!

	(correct me I'm wrong, I'm not really a tcp guy)

	Under the current behavior, I agree.
	Even if we keep dangling syn cache entries after closing listening
	socket, it buys us nothing at all.  This is because in{,6}_pcblookup
	will fail in early stage of tcp_input(), so dangling syn cache
	entries will never be looked up.

	However, current behavior is different from the behavior we had
	prior to syn cache.  Prior to syn cache, sonewconn() is called right
	after SYN is received (TCP/IP illustrated p931), so, once SYN is
	received listening socket is free to go away while accepted socket
	will persist.  If we want to go back to old behavior for some reason
	(of course with protection against syn flood attack), we should not
	remove syn cache entries.  Instead, we need some trick in tcp_close(),
	to preserve listening socket somehow, until all syn cache entries
	go away (no new syn cache entry should be generated, though).
	I'm not really sure which behavior is desirable.

>In the presence of many SYN cache entries, this could be expensive, tho.
>Maybe the SYN hash could be replaced with a per-listen socket queue of
>syn_cache_entry's?  I mean, we *already* have the listen socket when we
>do this lookup...

	I agree, but I'm not completely sure.  Per-listen socket queue
	needs to be hash table, not simple linked list (linear search on
	per-listen socket queue can be more expensive than current syn hash
	lookup).  Having small hash tables for each of the listenig sockets
	may eat more memory in kernel space.
	It really depends on distribution of syn packets, and its src/dst
	address pair...

itojun