public inbox for ecos-bugs@sourceware.org help / color / mirror / Atom feed
From: bugzilla-daemon@ecoscentric.com To: ecos-bugs@ecos.sourceware.org Subject: [Bug 1000738] Redboot networking problem Date: Thu, 16 Apr 2009 15:12:00 -0000 [thread overview] Message-ID: <20090416151230.19CE53B40048@mail.ecoscentric.com> (raw) In-Reply-To: <bug-1000738-13@http.bugs.ecos.sourceware.org/> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000738 Andrew Lunn <andrew.lunn@ascom.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew.lunn@ascom.ch --- Comment #1 from Andrew Lunn <andrew.lunn@ascom.ch> 2009-04-16 16:12:27 --- There is a race condition with closing the socket and opening the next socket. The normal code path is: http_client.c opens the first socket and transfers data. Once finished it calls http_stream_close() which calls __tcp_abort(). __tcp_abort() starts a timer with a delay of 1ms. After that 1ms delay the function do_abort() is called which sends a TCP ACK and RST packet and then unlinks the socket structure from the linked list of sockets. The race happens because the socket structure is a member of the static singleton http_stream in http_client.c. What i think is happening is that after the http_stream_close(), you are starting a second http transfer, before the 1ms delay. This results in the http_stream->sock structure being added to the linked list for a "second time", messing up the list pointers, and so giving your endless loop. When you delay your next http transfer for a short while, bigger an 1ms, the socket gets removed from the list before it is added to the list and everybody is happy. How to solve this problem? _tcp_open has code like: // Send off the SYN packet to open the connection tcp_send(s, TCP_FLAG_SYN, 0); // Wait for connection to establish while (s->state != _ESTABLISHED) { if (s->state == _CLOSED) { diag_printf("TCP open - host closed connection\n"); return -1; } if (--timeout <= 0) { diag_printf("TCP open - connection timed out\n"); return -1; } MS_TICKS_DELAY(); __tcp_poll(); } return 0; Maybe abort needs something similar: void __tcp_abort(tcp_socket_t *s, unsigned long delay) { int timeout = 10; __timer_set(&abort_timer, delay, do_abort, s); while (s->state != _CLOSED) { if (--timeout <= 0) { diag_printf("TCP close - connection failed to close\n"); return; } MS_TICKS_DELAY(); __tcp_poll(); } } It also looks like there could be a second similar race condition when the connection breaks. The code calls __tcp_close(&s->sock) and returns. Maybe a call to __tcp_close_wait() is needed? -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
next prev parent reply other threads:[~2009-04-16 15:12 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-04-06 17:35 [Bug 1000738] New: " bugzilla-daemon 2009-04-16 15:12 ` bugzilla-daemon [this message] 2009-04-17 8:09 ` [Bug 1000738] " bugzilla-daemon 2009-04-17 8:11 ` bugzilla-daemon 2009-04-17 16:46 ` bugzilla-daemon 2009-04-17 16:57 ` bugzilla-daemon 2009-04-19 20:41 ` bugzilla-daemon 2009-04-20 11:02 ` bugzilla-daemon 2009-04-20 11:06 ` bugzilla-daemon 2009-04-20 11:19 ` bugzilla-daemon
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20090416151230.19CE53B40048@mail.ecoscentric.com \ --to=bugzilla-daemon@ecoscentric.com \ --cc=ecos-bugs@ecos.sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).