Re: ixgbe(4) spin lock held too long
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 restart (more output or
> persist).
> 2817 * If there is more data to be acked, restart
> retransmit
> 2818 * timer, using current (possibly backed-off) value.
> 2819 */
> 2820if (th->th_ack == tp->snd_max) {
> 2821tcp_timer_activate(tp, TT_REXMT, 0);
> 2822needoutput = 1;
> 2823} else if (!tcp_timer_active(tp, TT_PERSIST))
> 2824tcp_timer_activate(tp, TT_REXMT,
> tp->t_rxtcur);
Bah, this is just a bug in my assertion. Rather than having a separate
tcp_timer_deactivate() routine, a delta of 0 passed to tcp_timer_activate()
means "stop the timer". My assertions were incorrect and need to exclude the
stop case. Here is an updated patch (or you can just fix yours locally):
Index: tcp_timer.c
===
--- tcp_timer.c (revision 273219)
+++ tcp_timer.c (working copy)
@@ -869,10 +869,16 @@ tcp_timer_activate(struct tcpcb *tp, int timer_typ
case TT_REXMT:
t_callout = &tp->t_timers->tt_rexmt;
f_callout = tcp_timer_rexmt;
+ if (callout_active(&tp->t_timers->tt_persist) &&
+ delta != 0)
+ panic("scheduling retransmit with persist
active");
break;
case TT_PERSIST:
t_callout = &tp->t_timers->tt_persist;
f_callout = tcp_timer_persist;
+ if (callout_active(&tp->t_timers->tt_rexmt) &&
+ delta != 0)
+ panic("scheduling persist with retransmit
active");
break;
case TT_KEEP:
t_callout = &tp->t_timers->tt_keep;
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ixgbe(4) spin lock held too long
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 is doing? This is not a NULL tcp timer pointer. Instead, the retransmit timer is being armed while the persist timer is still armed. -- John Baldwin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 stacks responds to all node link local multicast NS
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 IP and with source link layer info=attacker's MAC, computing sol node multicast for each target will make it only slightly costly, so I am not sure if security could be of concern here. The other concern is if it can be a compliance issue given the NS packet format described by the RFC. Also the comment in the code suggests what RFC says but the check is more liberal. Also why it is different for DAD NS vs Neighbor resolution NS. On Friday, October 17, 2014, Hiroki Sato wrote: > prabhakar lakhera > wrote > in >: > > pr> This probably is more of a compliance issue (or may be not as the NS > pr> receipt section of RFC 4861 http://tools.ietf.org/html/rfc4861#page-62 > does > pr> not talk about it). > pr> > pr> The neighbor solicitation message format says this: > pr> > pr> http://tools.ietf.org/html/rfc4861#page-22 > pr> > pr> > pr> Destination Address > pr> Either the solicited-node multicast address > pr> corresponding to the target address, or the target > pr> address. > pr> > pr> > pr> Is it safe to assume that this is a MUST? > pr> If yes, nd6_ns_input right now only checks if the destination is a > pr> multicast or not (the check is more strict for DAD NS packets) and > pr> therefore allows all node link local multicast address resolution NS > pr> packets and process them completely (creates neighbor cache, responds > pr> with NA etc). > > What is the problem when accepting NS messages to ff02::1? > > -- Hiroki > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
