panic: tcp_output REXMT

[Edgar Fuß]

But I don't understand how it could cause a tcp_setpersist() panic.
If I
understand it properly, we can't have TCPT_REXMT and TCPT_PERSIST
armed
at the same time. Here the path comes from TCPT_PERSIST's handler so
it was armed. Nothing arms TCPT_PERSIST outside of tcp_setpersist(),
so TCPT_REXMT has been armed after TCPT_PERSIST was.
syn_cache_get() can arm TCPT_REXMT without checking TCPT_PERSIST.
I don't know if TCPT_PERSIST could have been armed before at this
point.
I couldn't find other places where TCPT_REXMT would be armed without
checking TCPT_PERSIST.

Without having enough time atm to look into this thoroughly just now:
It looks like tcp_timer_rexmt() can also (re-)arm the retransmit timer.
I'm easily confused by the fact that counter-intuitively,
TCP_TIMER_ISARMED() doesn't mean "the timer is running and going to
fire any moment", but "the timer has been armed in the past and not
disarmed since".

Would it be an option for you to try the patch (modified as yamt@
wrote) and check whether the panic persists?


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Edgar Fuß

But I don't understand how it could cause a tcp_setpersist() panic.
If I
understand it properly, we can't have TCPT_REXMT and TCPT_PERSIST
armed
at the same time. Here the path comes from TCPT_PERSIST's handler so
it was armed. Nothing arms TCPT_PERSIST outside of tcp_setpersist(),
so TCPT_REXMT has been armed after TCPT_PERSIST was.
syn_cache_get() can arm TCPT_REXMT without checking TCPT_PERSIST.
I don't know if TCPT_PERSIST could have been armed before at this
point.
I couldn't find other places where TCPT_REXMT would be armed without
checking TCPT_PERSIST.

It looks like tcp_timer_rexmt() can also (re-)arm the retransmit timer.

It does. But that's not and issue: if TCPT_REXMT fires it was armed, and
so TCPT_PERSIST should not be.

Post by Edgar Fuß
I'm easily confused by the fact that counter-intuitively,
TCP_TIMER_ISARMED() doesn't mean "the timer is running and going to
fire any moment", but "the timer has been armed in the past and not
disarmed since".
wrote) and check whether the panic persists?

Well, I see the panic only once every few months. I can't see how this
would fix it, and if it did, I think it would just hide the real bug.

[Edgar Fuß]

if TCPT_REXMT fires it was armed, and so TCPT_PERSIST should not be.

Yes, you're right. Save syn_cache_get(), of course.

Do you think it would help adding a field to the TCPCB remembering who was the last one to arm the retransmit timer and outputting that field in the REXMT panic?

I can't see how this would fix it

Right again. I must have overlooked something when I looked through the code last time. At least that explains why it's not panic'ing all the time despite the retransmit timer not being correctly disarmed.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Edgar Fuß

if TCPT_REXMT fires it was armed, and so TCPT_PERSIST should not be.

Yes, you're right. Save syn_cache_get(), of course.
Do you think it would help adding a field to the TCPCB remembering who was the last one to arm the retransmit timer and outputting that field in the REXMT panic?

Yes, it could. But I've no way to reproduce this panic reliably.