From owner-freebsd-net@freebsd.org Thu Feb 18 20:40:44 2021 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 70D3754DC04 for ; Thu, 18 Feb 2021 20:40:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DhRRw2ZVyz3jkK for ; Thu, 18 Feb 2021 20:40:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 5687C54DAAE; Thu, 18 Feb 2021 20:40:44 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5651354DC02 for ; Thu, 18 Feb 2021 20:40:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DhRRw1xTgz3jWK for ; Thu, 18 Feb 2021 20:40:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 34D551EEB7 for ; Thu, 18 Feb 2021 20:40:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11IKeiHZ029402 for ; Thu, 18 Feb 2021 20:40:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11IKeiu2029401 for net@FreeBSD.org; Thu, 18 Feb 2021 20:40:44 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 253589] KCSAN race between tcp_do_segment and sbfree with vtnet Date: Thu, 18 Feb 2021 20:40:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jtl@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 20:40:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253589 Jonathan T. Looney changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jtl@freebsd.org --- Comment #2 from Jonathan T. Looney --- I can think more about this, but my initial thought is that this is probably both expected and acceptable within the context you have given. It appears that the two threads are doing these things: Thread 1: Running sbfree() to free an mbuf from a socket buffer. I am going= to surmise that this is an mbuf on the input socket buffer, and it has now been read by the application. This will decrease sb_ccc, which has the implicati= on of increasing the available space in the socket buffer. Thread 2: Running sbspace() to check on the amount of available space in a socket buffer. Because this is being called from tcp_do_segment(), I am goi= ng to surmise that this is being called from one of the two places which use sbspace() to determine the amount of data we can read from an input packet. (FWIW, even though the instruction points to the line which checks for SB_S= TOP, I assume that the actual conflict occurs on the next line of code which uses sb_ccc.) If I understand the code correctly, neither the socket nor socket buffer ca= n be freed as long as the TCP code holds a reference on the socket. And, if the = TCP code is calling tcp_do_segment(), it should be in a state where it still ha= s a reference on the socket. So, the only potential danger from the lack of synchronization is a stale read on the socket buffer values. In this particular case, I believe it is acceptable to have a stale read. T= CP advertises a receive window to its peer based on the latest information it = has about input socket buffer space. The peer should not exceed that receive window. Prior to Thread 1 modifying the sb_ccc value, the receive window wo= uld have been X. After Thread 1 modified the sb_ccc value, the receive window w= ould have been Y (where Y > X). Absent some corner cases (such as suddenly shrin= king the input buffer high water level), we should have most recently advertised= a receive window no larger than X. Therefore, whether Thread 2 reads sb_ccc before or after Thread 1 updates it, the peer should not have sent us so mu= ch data that it actually produces a functional difference. (And, if the peer d= id exceed our advertised receive window, our TCP stack is under no obligation = to accept that data.) So, for this usage within TCP, it seems to me that the locking should not m= ake a functional difference and the lack of locking for this particular read is probably a net gain. --=20 You are receiving this mail because: You are the assignee for the bug.=