Bug #1153

rt remote free backtrace

Added by pavalos over 5 years ago. Updated about 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

rt remote free rt_cpuid 1, mycpuid 0
Trace beginning at frame 0xda6fbcd8
rtfree_remote(c0371380,1,0,da6fbd00,c023d118) at rtfree_remote+0x74
rtfree_remote(f5447ba0,0) at rtfree_remote+0x74
in_pcbdetach(db085900) at in_pcbdetach+0x82
in_pcbremwildcardhash_handler(f0bc3740,f0bc3740,0,da6fbd84,c024d097) at
in_pcbremwildcardhash_handler+0x30
netmsg_service(f0bc3740,1,0,c041d880,ff800000) at netmsg_service+0x44
tcpmsg_service_loop(0,0,0,0,0) at tcpmsg_service_loop+0x40
lwkt_exit() at lwkt_exit

If this isn't known, let me know and I'll panic it next time it happens.

--Peter

History

#1 Updated by sepherosa over 5 years ago

For a listen socket on tcp_input path, the listen socket's inp route
cache will be used to send RST, if it receives a TCP segment with
invalid flags combination. This may lead to this route entry remote
free.

Please test/review following patch:
http://leaf.dragonflybsd.org/~sephe/tcp_respond.diff

Best Regards,
sephe

#2 Updated by pavalos over 5 years ago

I noticed you only committed the tcp_subr.c part of this patch and not
the in_pcb.c. Was that intentional?

--Peter

#3 Updated by sepherosa over 5 years ago

Yep. The change in in_pcb.c shows the confidence that remote rt free
will not happen; nothing serious. But the rt remote free you showed
after I posted this patch indicated that we are not that ready yet :)

Best Regards,
sephe

#4 Updated by sepherosa about 5 years ago

Committed:
5a0e5b4389

Also available in: Atom PDF