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

TODO

@@ -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)
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 

net/tcp/tcp_connect.c

@@ -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);