Hi Hiren,
On 26/09/15 00:46, hiren panchasara wrote:
> On 09/25/15 at 09:42P, John Baldwin wrote:
>> On Thursday, September 24, 2015 02:13:24 PM Julien Charbon wrote:
>>> So the issue is:
>>>
>>> - tcp_close() is called for some reasons with an inp in INP_TIMEWAIT
>>> state and sets the INP_DR
Hi John,
On 25/09/15 18:42, John Baldwin wrote:
> On Thursday, September 24, 2015 02:13:24 PM Julien Charbon wrote:
>> So the issue is:
>>
>> - tcp_close() is called for some reasons with an inp in INP_TIMEWAIT
>> state and sets the INP_DROPPED flag,
>> - tcp_detach() is called when the last
On 09/25/15 at 09:42P, John Baldwin wrote:
> On Thursday, September 24, 2015 02:13:24 PM Julien Charbon wrote:
> > So the issue is:
> >
> > - tcp_close() is called for some reasons with an inp in INP_TIMEWAIT
> > state and sets the INP_DROPPED flag,
> > - tcp_detach() is called when the last re
On Thursday, September 24, 2015 02:13:24 PM Julien Charbon wrote:
> So the issue is:
>
> - tcp_close() is called for some reasons with an inp in INP_TIMEWAIT
> state and sets the INP_DROPPED flag,
> - tcp_detach() is called when the last reference on socket is dropped
>
> then now in_pcbfree(
Hi -net,
On 23/09/15 16:47, Julien Charbon wrote:
> Thanks to Palle, I got access to the kernel dump. And the results is
> more interesting than expected: Thus somehow the kernel reaches a state
> in tcp_detach() where:
>
> INP_TIMEWAIT && INP_DROPPED && tp != NULL
>
> In details:
>
> -
