On Thu, Oct 16, 2014 at 12:23 PM, John Baldwin j...@freebsd.org wrote:
I looked at the other trace and I don't think it disagrees with my previous
theory. I do have more KTR patches to log when we spin on locks which would
really confirm this, but I haven't tested those fully on HEAD yet.
Thanks! This has tons more info. I'll have a read.
---
Sent from my phone, sorry about the typos.
On 17 Oct 2014, at 18:27, Luigi Rizzo ri...@iet.unipi.it wrote:
On Fri, Oct 17, 2014 at 9:55 AM, Matthew P. Grosvenor
matthew.grosve...@cl.cam.ac.uk wrote:
Hi all,
I’m trying
On Friday, October 17, 2014 11:32:13 PM Jason Wolfe wrote:
Producing 10G of random traffic against a server with this assertion
added took about 2 hours to panic, so if it turns out we need anything
further it should be pretty quick.
#4 list
2816 * timer and remember to
On Friday, October 17, 2014 11:43:26 PM Adrian Chadd wrote:
Hm, is this the bug that was just fixed in -HEAD?
I saw this similar bug on -HEAD with lots of quick connections and
reused ports. It ended up deferencing a NULL tcp timer pointer from
the inpcb. Is that what the code in your tree
Like I said before, it is not per RFC. It is trivial to derive solicited
node multicast address from the target IP, so If someone were to launch a
flood attack to poison cache entry for X host by sending Address resolution
request for all other local hosts in the network, with NS's source IP=X's
