Date: Thu, 14 Oct 2004 11:43:16 +0000 (UTC) From: Robert Watson <rwatson@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern uipc_socket.c Message-ID: <200410141143.i9EBhG0H095461@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
rwatson 2004-10-14 11:43:16 UTC FreeBSD src repository Modified files: (Branch: RELENG_5) sys/kern uipc_socket.c Log: Merge uipc_socket.c:1.213 from HEAD to RELENG_5: date: 2004/10/11 08:11:26; author: rwatson; state: Exp; lines: +19 -5 Rework sofree() logic to take into account a possible race with accept(). Sockets in the listen queues have reference counts of 0, so if the protocol decides to disconnect the pcb and try to free the socket, this triggered a race with accept() wherein accept() would bump the reference count before sofree() had removed the socket from the listen queues, resulting in a panic in sofree() when it discovered it was freeing a referenced socket. This might happen if a RST came in prior to accept() on a TCP connection. The fix is two-fold: to expand the coverage of the accept mutex earlier in sofree() to prevent accept() from grabbing the socket after the "is it really safe to free" tests, and to expand the logic of the "is it really safe to free" tests to check that the refcount is still 0 (i.e., we didn't race). RELENG_5 candidate. Much discussion with and work by: green Reported by: Marc UBM Bocklet <ubm at u-boot-man dot de> Reported by: Vlad <marchenko at gmail dot com> Note that this fix is not yet confirmed by submitters to correct the specific symptom they are seeing, but does correct a known problem. Approved by: re (scottl) Revision Changes Path 1.208.2.3 +19 -5 src/sys/kern/uipc_socket.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410141143.i9EBhG0H095461>