[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Race condition with lwIP-1.3.2 in PXELINUX-4.10-pre16+

From: Simon Goldschmidt
Subject: Re: [lwip-users] Race condition with lwIP-1.3.2 in PXELINUX-4.10-pre16+ on VMware/KVM platforms
Date: Thu, 13 Oct 2011 09:20:42 +0200

After having a look at your sources, it seems like you call the lwIP input 
functions from ISR context while at the same time using the sequential APIs and 
the tcpip_thread. This results in race conditions.

I think you would have to mainly change the undiif_input() function:
- call tcpip_input() instead of ethernet_input() (if netif->flags has 
NETIF_FLAG_ETHARP set, tcpip_input() calls ethernet_input())
- call tcpip_input() instead of ip_input() (if netif->flags does not have 
NETIF_FLAG_ETHARP set, tcpip_input() cals ip_input())

Although netif->input() is not used, you shouuld pass tcpip_input instead of 
ip_input to netif_add() (just in case someone changes the code to use 
netif->input, it should be correct).

Hope that helps.


Gene Cumm <address@hidden> wrote:
> For the past several months, Syslinux has been trying to integrate lwIP
> into
> PXELINUX.  At the moment, there appears to be a bug of some sort when
> using
> VMware platforms or some KVM platforms.  Over the last few weeks, I've
> been
> working with hpa and trying to add additional debug checks to trace the
> program flow.  I've noticed that it is able to send a TCP segment but then
> switches to receive the incoming segment before being added to unacked by
> the output thread.  RTT from SYN to SYN/ACK is 0.023 ms per Wireshark on
> the
> host.  The output thread does eventually return but doesn't do so in time
> before the socket is reset.
> Examining top-of-git, I don't see anything that would change this behavior
> and I have attempted to integrate this version in my copy for now to
> hopefully make it easier to work with lwIP.  I see at least three possible
> solutions:
> 1) Don't allow the interface driver to switch threads.
> 2) tcp_process() should handle the condition of the packet being in
> unsent.
> 3) Allow the output thread to wrap up a packet, queuing it into unacked,
> before tcp_process() searches unacked.
> Any suggestions?
> --Gene
> ps. I am subscibed to this list.

NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!               
Jetzt informieren: http://www.gmx.net/de/go/freephone

reply via email to

[Prev in Thread] Current Thread [Next in Thread]