Re: panic: assertion: so->so_port == &curthread->td_msgport in tcp_input

[Sepherosa Ziehau <sepherosa@xxxxxxxxx>]

On Mon, Feb 21, 2011 at 10:11 AM, Sepherosa Ziehau <sepherosa@gmail.com> wrote:
> On Sun, Feb 20, 2011 at 5:44 AM, Peter Avalos <peter@theshell.com> wrote:
>> On Sat, Feb 19, 2011 at 11:03:50PM +0800, Sepherosa Ziehau wrote:
>>> > http://www.theshell.com/~pavalos/crash/ylem-crash6.tar.xz
>>>
>>> The crash seems to be truncated.  I tried on leaf and my own box,
>>> there are 2010 bytes missing.
>>>
>>
>> That's weird.  We'll I've re-tar'd (that's a sweet word) it, as well as
>> the other crashes I got:
>>
>> http://www.theshell.com/~pavalos/crash/
>>
>> ylem-crash[6-12].tar.xz
>
> Well, the crash6 looks strange in following way:
> 1) tcp_usr_listen seems to be called on a same inp twice
> 2) an "accepted" tcp socket is duplicated onto the wildcardhash and it
> seems to be linked into connhash too.  The socket is in FIN_WAIT_1
>
> crash6 is caused by 2), though 1) was problematic too
>
> I will add some assertion, so the panic could happen earlier

It turns out the 2) is caused by 1):
1] The application will call listen on the socket 2 times, so the old
code will create 2 inpcontainer which points to the same inp
2] During the application stop, the application closes the socket, but
only one inpcontainer is unlinked, so the second inpcontainer points
to a dangling inp
3] After the application starts again, one of the newly accepted
socket reuse the old listen socket's inp memory location
4] The dangling inp pointed by the inpcontainer now is the new valid
accepted socket, so an accepted socket appears "mysteriously" on the
wildcardhash, while in the crash, the accepted socket is on cpu0, the
lookup happens on cpu1
5] The inp lookup on the tcp_input will find wildcard inp, but it
prefers laddr and lport matching over only lport matching, so the
accepted socket is returned

I believe it is fixed by:
f7b29de575ce11c14e6363518ea4d28267cf3ccc

Best Regards,
sephe

-- 
Tomorrow Will Never Die