cvs commit: src/sys/kern uipc_socket2.c

Robert Watson rwatson at FreeBSD.org
Fri Jun 10 08:35:41 GMT 2005


rwatson     2005-06-10 08:35:40 UTC

  FreeBSD src repository

  Modified files:        (Branch: RELENG_5)
    sys/kern             uipc_socket2.c 
  Log:
  Merge uipc_socket2.c:1.146 from HEAD to RELENG_5:
  
    In the current world order, each socket has two mutexes: a mutex
    that protects socket and receive socket buffer state, and a second
    mutex to protect send socket buffer state.  In some places, the
    mutex shared between the socket and receive socket buffer will be
    acquired twice, once by each layer, resulting in some
    inconsistency, but providing the abstraction benefit of being able
    to more easily separate the two mutexes in the future if desired.
  
    When transitioning a socket to the SS_ISDISCONNECTING or
    SS_ISDISCONNECTED states, grab the socket/receive socket buffer lock
    once rather than grabbing it as the socket lock, modifying socket
    state, then grabbing a second time as the receive lock in order to
    modify the socket buffer state to indicate no further data can be
    read.  This change is believed to close a race between the change in
    socket state and the change in socket buffer state, which for a
    remotely initiated close on a UNIX domain socket, resulted in
    soreceive() returning ENOTCONN rather than an EOF condition.
  
    A similar race still exists in the case of send, however, and is
    harder to fix as the socket and send socket buffer mutexes are not
    the same, and we would like to avoid holding combinations of socket
    mutexes over sb_upcall until we've finished clarifying the locking
    protocol for upcalls.
  
    This change has the side affect of reducing the number of mutex
    operations to initiate disconnect or perform disconnect on a
    socket by two.
  
    PR:             78824
    Reported by:   Marc Olzheim <marcolz at stack.nl>
  
  Revision   Changes    Path
  1.137.2.7  +6 -13     src/sys/kern/uipc_socket2.c


More information about the cvs-src mailing list