[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.
Simon
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