)]}'
{
  "commit": "ec0d215f9420564fc8286dcf93d2d068bb53a07e",
  "tree": "f28d77219b4983c5e8c042202d5e37a746f05e60",
  "parents": [
    "db43a282d3ec92ea45109c5551fff3dcc5afef02"
  ],
  "author": {
    "name": "Rainer Weikusat",
    "email": "rweikusat@mssgmbh.com",
    "time": "Fri Jun 27 19:34:18 2008 -0700"
  },
  "committer": {
    "name": "David S. Miller",
    "email": "davem@davemloft.net",
    "time": "Fri Jun 27 19:34:18 2008 -0700"
  },
  "message": "af_unix: fix \u0027poll for write\u0027/connected DGRAM sockets\n\nFor n:1 \u0027datagram connections\u0027 (eg /dev/log), the unix_dgram_sendmsg\nroutine implements a form of receiver-imposed flow control by\ncomparing the length of the receive queue of the \u0027peer socket\u0027 with\nthe max_ack_backlog value stored in the corresponding sock structure,\neither blocking the thread which caused the send-routine to be called\nor returning EAGAIN. This routine is used by both SOCK_DGRAM and\nSOCK_SEQPACKET sockets. The poll-implementation for these socket types\nis datagram_poll from core/datagram.c. A socket is deemed to be\nwriteable by this routine when the memory presently consumed by\ndatagrams owned by it is less than the configured socket send buffer\nsize. This is always wrong for PF_UNIX non-stream sockets connected to\nserver sockets dealing with (potentially) multiple clients if the\nabovementioned receive queue is currently considered to be full.\n\u0027poll\u0027 will then return, indicating that the socket is writeable, but\na subsequent write result in EAGAIN, effectively causing an (usual)\napplication to \u0027poll for writeability by repeated send request with\nO_NONBLOCK set\u0027 until it has consumed its time quantum.\n\nThe change below uses a suitably modified variant of the datagram_poll\nroutines for both type of PF_UNIX sockets, which tests if the\nrecv-queue of the peer a socket is connected to is presently\nconsidered to be \u0027full\u0027 as part of the \u0027is this socket\nwriteable\u0027-checking code. The socket being polled is additionally\nput onto the peer_wait wait queue associated with its peer, because the\nunix_dgram_recvmsg routine does a wake up on this queue after a\ndatagram was received and the \u0027other wakeup call\u0027 is done implicitly\nas part of skb destruction, meaning, a process blocked in poll\nbecause of a full peer receive queue could otherwise sleep forever\nif no datagram owned by its socket was already sitting on this queue.\nAmong this change is a small (inline) helper routine named\n\u0027unix_recvq_full\u0027, which consolidates the actual testing code (in three\ndifferent places) into a single location.\n\nSigned-off-by: Rainer Weikusat \u003crweikusat@mssgmbh.com\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "657835f227d342a2eadc4498c6076b7c435839ac",
      "old_mode": 33188,
      "old_path": "net/unix/af_unix.c",
      "new_id": "783317dacd3090f7d602b3c56e82859f3cc22a46",
      "new_mode": 33188,
      "new_path": "net/unix/af_unix.c"
    }
  ]
}