buglwIP - A Lightweight TCP/IP stack - Bugs: bug #44032, LWIP_NETCONN_FULLDUPLEX: select...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #44032: LWIP_NETCONN_FULLDUPLEX: select might work on invalid/reused socket

Submitted by:  Simon Goldschmidt <goldsimon>
Submitted on:  Sat 17 Jan 2015 08:18:08 PM UTC  
 
Category: sockets/netconnSeverity: 2 - Minor
Item Group: Feature RequestStatus: Fixed
Privacy: PublicAssigned to: Simon Goldschmidt <goldsimon>
Open/Closed: ClosedPlanned Release: None
lwIP version: git head

(Jump to the original submission Jump to the original submission)

Fri 24 Feb 2017 08:39:03 PM UTC, comment #8:

Fixed in these 4 commits:

http://git.savannah.gnu.org/cgit/lwip.git/commit/?id=a38e937dd6a32952cc016ae621368d5e85729cc9
http://git.savannah.gnu.org/cgit/lwip.git/commit/?id=f4d13d52d3ea074d5c173a305aace29aacf37e6c
http://git.savannah.gnu.org/cgit/lwip.git/commit/?id=8bb43e7388e300aaa74bc9f061f7f79cb295523f
http://git.savannah.gnu.org/cgit/lwip.git/commit/?id=6786c9f14382535cd27a6944167ab88b31ff3e92

by adding sock->fd_used to indicate a thread holds a reference on a socket (and freeing is delayed until all threads are done with a socket).

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Thu 16 Feb 2017 09:00:44 PM UTC, comment #7:

Working on a reused socket can also happen on close-while-write/read (for LWIP_NETCONN_FULLDUPLEX), so we might need a more generic approach to this:

Every function holding a reference to a socket (via get_socket()) should prevent this socket being reused until it returns.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Thu 09 Feb 2017 07:41:59 PM UTC, comment #6:

Fixed by not allowing to reallocate a socket that has "select_waiting != 0".

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Mon 23 Mar 2015 07:40:48 PM UTC, comment #5:

Thanks for the explanation Simon. I'm not opposed to having select() return EBADF or something similar when an FD gets closed. Just want to make sure we are adhering to the POSIX FD behaviors :)

Joel Cunningham <jcunningham>
Project Member
Tue 17 Mar 2015 07:27:36 PM UTC, comment #4:

Joel, I understand what you mean. However, this bug is not about improving anything in the "FDs are an array index" thing. It is about not breaking this just because someone happens to call close() on a socket where select() is running. I don't think this should cause problems.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Mon 16 Mar 2015 09:50:24 PM UTC, comment #3:

Maybe I missed the mailing list discussion of LWIP_NETCONN_FULLDUPLEX, but is that allowing multiple threads to operate on the same socket?

Even if we address the LwIP restriction of multiple threads using the same socket, there is still the long standing limitation of FDs when implemented as a simple index (restriction applies on *nix).

If you have two threads, one blocking on socket A and the other thread issues a close(A), and then a call to socket() (which returns A), now the second thread is operating on the new instance of socket A without ever knowing it was closed.

It is my understanding that best practices for FD programming involves avoiding closing a FD from a different thread than is using the FD (due to this ambiguous FD instance problem). The select use case seems to be a violation of that best practice.

Joel Cunningham <jcunningham>
Project Member
Mon 16 Mar 2015 09:26:29 PM UTC, comment #2:

Well, this bug report is for the new very experimental code supporting full duplex sockets only. But in that context, it is valid.

I've changed the summary to reflect this.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Mon 16 Mar 2015 09:03:27 PM UTC, comment #1:

The use case of a blocking on a socket in select() while another thread issues a close() on that socket seems to violate LwIP's multi-threading requirements (a socket can only be used by a single thread)

Should this be closed?

Joel Cunningham <jcunningham>
Project Member
Sat 17 Jan 2015 08:18:08 PM UTC, original submission:

When a socket gets closed and reused from another thread while select is waiting on it, 'select_waiting--' can be executed on this socket although it's not the socket where 'select_waiting++' was executed before (this mainly depends on the priorities of the threads using sockets).

To circumvent this, we could either not completely free sockets where select is waiting or add a global 'sockalloc' counter, stored per socket, which select could used to detect newly allocated sockets.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jcunningham (Posted a comment)
  • -unavailable- added by goldsimon (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 24 Feb 2017 08:39:03 PM UTCgoldsimonItem GroupNone=>Feature Request
      StatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Thu 16 Feb 2017 09:00:44 PM UTCgoldsimonStatusFixed=>None
      Open/ClosedClosed=>Open
    Thu 09 Feb 2017 07:41:59 PM UTCgoldsimonStatusNone=>Fixed
      Assigned toNone=>goldsimon
      Open/ClosedOpen=>Closed
    Mon 16 Mar 2015 09:26:29 PM UTCgoldsimonSummaryselect might work on invalid/reused socket=>LWIP_NETCONN_FULLDUPLEX: select might work on invalid/reused socket
    Wed 04 Mar 2015 07:05:13 PM UTCgoldsimonSeverity3 - Normal=>2 - Minor

    Back to the top


    Powered by Savane 3.1-cleanup1