sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Move comments describing a problem out of the code and into the TODO list where it belongs.

Browse Source
This commit is contained in:
Gregory Nutt 2017-10-25 12:37:02 -06:00
parent c3ce23ba35
commit 5692e340ab
2 changed files with 36 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
TODO
View File

@ -1,4 +1,4 @@
NuttX TODO List (Last updated October 15, 2017)
NuttX TODO List (Last updated October 25, 2017)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This file summarizes known NuttX bugs, limitations, inconsistencies with
@ -19,7 +19,7 @@ nuttx/:
(8) Kernel/Protected Build
(3) C++ Support
(6) Binary loaders (binfmt/)
(16) Network (net/, drivers/net)
(17) Network (net/, drivers/net)
(4) USB (drivers/usbdev, drivers/usbhost)
(0) Other drivers (drivers/)
(12) Libraries (libc/, libm/)
@ -1322,6 +1322,40 @@ o Network (net/, drivers/net)
Status: Open
Priority: Medium
Title: TCP ISSUES WITH QUICK CLOSE
Description: This failure has been reported in the accept() logic:
- psock_tcp_accept() waits on net_lockedwait() below
- The accept operation completes, the socket is in the connected
state and psock_accept() is awakened. It cannot run,
however, because its priority is low and so it is blocked
from execution.
- In the mean time, the remote host sends a
packet which is presumeably caught in the read-ahead buffer.
- Then the remote host closes the socket. Nothing happens on
the target side because net_start_monitor() has not yet been
called.
- Then accept() finally runs, but not with a connected but
rather with a disconnected socket. This fails when it
attempts to start the network monitor on the disconnected
socket below.
- It is also impossible to read the buffered TCP data from a
disconnected socket. The TCP recvfrom() logic would also
need to permit reading buffered data from a disconnected
socket.
This problem was report when the target hosted an FTP server
and files were being accessed by FileZilla.
connect() most likely has this same issue.
A work-around might be to raise the priority of the thread
that calls accept().
Status: Open
Priority: Medium. I have never heard of this problem being reported
before, so I suspect it might not be so prevalent as the one
might expect.
o USB (drivers/usbdev, drivers/usbhost)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

23
net/tcp/tcp_connect.c
View File

@ -364,29 +364,6 @@ int psock_tcp_connect(FAR struct socket *psock,
/* Wait for either the connect to complete or for an error/timeout
* to occur. NOTES: net_lockedwait will also terminate if a signal
* is received.
*
* REVISIT: This failure has been reported:
* - psock_tcp_accept() waits on net_lockedwait() below
* - The accept operation completes, the socket is in the connected
* state and psock_accept() is awakened. It cannot run,
* however, because its priority is low and so it is blocked
* from execution.
* - In the mean time, the remote host sends a
* packet which is presumeably caught in the read-ahead buffer.
* - Then the remote host closes the socket. Nothing happens on
* the target side because net_start_monitor() has not yet been
* called.
* - Then accept() finally runs, but not with a connected but
* rather with a disconnected socket. This fails when it
* attempts to start the network monitor on the disconnected
* socket below.
* - It is also impossible to read the buffered TCP data from a
* disconnected socket. The TCP recvfrom() logic would also
* need to permit reading buffered data from a disconnected
* socket.
*
* A work-around is to raise the priority of the thread that calls
* accept().
*/
ret = net_lockedwait(&state.tc_sem);