From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5F0E7282F22 for ; Fri, 20 Mar 2026 19:42:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774035750; cv=none; b=ni62Rsb57v9bIJTw7T/UswPFWKvtpQpdRFPqL6oDXpk97FnNz0zoiyWvnbL2np4frPGdaxVt14OfWu5uzpFpv2ScOPr9tMTprgOmf/+tt72CBiI+ucMA8zqMH7NtNFNmh+okZnIk+Hp9YpXeFM2yvi7E63FcbWT2cMvlHxEPP9s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774035750; c=relaxed/simple; bh=/lgrBaf4Lu3BSJzE5WFisPoWxzCA+1LAaAJ4lkMWWY0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LcaRBcCVq/5rn5tqb64BoMPrZs510+AaxTlvZSneDNNhWGsyCfXpmKwU6ocTqioHUaoSGDqUR4FGz9HI8+VC5aSXksN8cNVIxfEvvm4EZieojb2iXt2iqseIs/GRBfj8BjLIt4GyQd7BUNkD/YRh0Avm9XA1ML6dNUkzQMOqS9A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U9HVPIHV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="U9HVPIHV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 597F4C4CEF7; Fri, 20 Mar 2026 19:42:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774035750; bh=/lgrBaf4Lu3BSJzE5WFisPoWxzCA+1LAaAJ4lkMWWY0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=U9HVPIHVL7LzsCHeLvM0C7u6qH4sU6KNGLw5qUDfnjogm4hHGaG1lH6xOGOJ8ejOz ouh3VH3tjxUtYjt0oV2zCxqJMJ3xJgXUd7yzXtrAQ4DkMr4QBX8/FplPch3stDba14 jPFBzJn0X5+a9W6uIV9wgnJaV39i/xZ3MQOyGqzHyy5aBKQyd2F8lZqgZXUR3HWPOd HSbMttKB+KOsxQ7JFxNd2XUtLD4fySPrbyLv+Tjf+/hc4T0Ldrly8bCPux6DrMraLL 0UNrcs42GyYoZK17feRlfBnYXPzB5B0fIxbmhaJwAA5T4fdxefFsulQHHWdLDjGixA qDzUG5okmTILA== From: Simon Horman To: rjethwani@purestorage.com Cc: Simon Horman , edumazet@google.com, kuba@kernel.org, mbloch@nvidia.com, john.fastabend@gmail.com, netdev@vger.kernel.org, davem@davemloft.net, sd@queasysnail.net, pabeni@redhat.com, saeedm@nvidia.com, borisp@nvidia.com, tariqt@nvidia.com, leon@kernel.org Subject: Re: [PATCH v8 5/6] tls: add hardware offload key update support Date: Fri, 20 Mar 2026 19:42:24 +0000 Message-ID: <20260320194224.175550-1-horms@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260319213323.235559-6-rjethwani@purestorage.com> References: <20260319213323.235559-6-rjethwani@purestorage.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This is an AI-generated review of your patch. The human sending this email has considered the AI review valid, or at least plausible. For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html --- tls: add hardware offload key update support Add TLS KeyUpdate (rekey) support for hardware offload connections. When hardware rekey fails, the connection gracefully degrades to software encryption/decryption while maintaining TLS_HW configuration. Tested on Mellanox ConnectX-6 Dx (Crypto Enabled) with multiple TLS 1.3 key update cycles. > tls: add hardware offload key update support > > Add TLS KeyUpdate (rekey) support for hardware offload connections. > > When hardware rekey fails, the connection gracefully degrades to > software encryption/decryption while maintaining TLS_HW configuration. This commit message claims the connection "gracefully degrades to software encryption/decryption" when hardware rekey fails. However, the implementation appears inconsistent with this description. Looking at the actual code behavior in net/tls/tls_main.c: > @@ -711,64 +713,68 @@ static int do_tls_setsockopt_conf(struct sock *sk, sockptr_t optval, > } > > if (tx) { [ ... ] > + } else if (update && ctx->tx_conf == TLS_HW) { > + /* HW rekey failed - return the actual error. > + * Cannot fall back to SW for an existing HW connection. > + */ > goto err_crypto_info; When hardware rekey fails on an existing TLS_HW TX connection, the code returns an error rather than degrading to software mode. The same pattern appears for RX: [ ... ] > + } else if (update && ctx->rx_conf == TLS_HW) { > + /* HW rekey failed - return the actual error. > + * Cannot fall back to SW for an existing HW connection. > + */ > goto err_crypto_info; The comments explicitly state "Cannot fall back to SW for an existing HW connection." This contradicts the commit message's claim of graceful degradation. Could the commit message be updated to accurately describe the error handling behavior? This inconsistency was noted by Sabrina Dubroca during review of v7, and remains in v8: https://lore.kernel.org/netdev/aZxm8hSrVMkEIc2O@krikkit/ Additionally, the commit message style may be worth reviewing. Sabrina suggested looking through git log for net/ to match the typical commit message format used in the networking subsystem.