From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 572695A026F for ; Wed, 15 Nov 2023 05:41:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1700023286; bh=8f6PCCuAqOeI9Xx1LnfGW5R9UBhFfFijJGMk1fWpYPg=; h=From:To:Cc:Subject:Date:From; b=hU54TEEEsK3NPGAvnP8bgDIeUKWTE3cjUgIGc19NrnuJD31OxBBWUDD56pJd9GQUn tYVIqbHnjc5MFbYkIW9lttsCUb/RVJj6eyigu4eeMOW8FpCDC6ieIiYChFs8zhr+Te Z0KVG1CC4n1M6rQT7UXKwxTZ+I7+88vF18SYnPKM= Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4SVVqV4BqYz4xFR; Wed, 15 Nov 2023 15:41:26 +1100 (AEDT) From: David Gibson To: Stefano Brivio , passt-dev@passt.top Subject: [PATCH] cppcheck,valgrind: Don't pass NULL to recv() with MSG_TRUNC Date: Wed, 15 Nov 2023 15:41:24 +1100 Message-ID: <20231115044124.1496698-1-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID-Hash: LTJNM3MRSWYBR4GRH4K6PU2DMGUPFO47 X-Message-ID-Hash: LTJNM3MRSWYBR4GRH4K6PU2DMGUPFO47 X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: David Gibson X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Usually, of course, it's invalid to pass a NULL buffer to recv(). However, it's acceptable when using MSG_TRUNC, because that suppresses actually writing to the buffer. So, we pass NULL in tcp_sock_consume(). Unfortunately, checker tools aren't always aware of that special case: we already have a suppression for cppcheck to cover this. valgrind-3.22.0 (present in Fedora 39) has a similar problem, generating a spurious warning here. We could generate another suppression for valgrind, however, it so happens that we already have tcp_buf_discard ready to hand. If we pass this instead of NULL it makes both cppcheck and valgrind happy. We're still using the MSG_TRUNC flag, the kernel doesn't actually have to copy data, so we should still have the performance benefits of it. Signed-off-by: David Gibson --- tcp.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/tcp.c b/tcp.c index cfcd40a..f51d27a 100644 --- a/tcp.c +++ b/tcp.c @@ -2106,8 +2106,13 @@ static int tcp_sock_consume(const struct tcp_tap_conn *conn, uint32_t ack_seq) if (SEQ_LE(ack_seq, conn->seq_ack_from_tap)) return 0; - /* cppcheck-suppress [nullPointer, unmatchedSuppression] */ - if (recv(conn->sock, NULL, ack_seq - conn->seq_ack_from_tap, + /* Since we're using MSG_TRUNC, it's allowed to pass NULL instead of a + * real buffer. However some checker tools (including at least some + * versions of cppcheck and valgrind) aren't aware of that special case. + * We so happen to have a convenient discard buffer, so we might as well + * pass it to avoid spurious complaints from those tools. + */ + if (recv(conn->sock, tcp_buf_discard, ack_seq - conn->seq_ack_from_tap, MSG_DONTWAIT | MSG_TRUNC) < 0) return -errno; -- 2.41.0