From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 72ABBC433EF for ; Mon, 11 Jul 2022 13:10:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229879AbiGKNKS (ORCPT ); Mon, 11 Jul 2022 09:10:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229615AbiGKNKS (ORCPT ); Mon, 11 Jul 2022 09:10:18 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C5223246F for ; Mon, 11 Jul 2022 06:10:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id CCE88B80EE4 for ; Mon, 11 Jul 2022 13:10:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 7B28BC341C0; Mon, 11 Jul 2022 13:10:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657545012; bh=J/z+bl2RLtQHiekuPY3nkif7x6NnR1wDYUMUtdLi7C0=; h=Subject:From:Date:References:In-Reply-To:To:Cc:From; b=KZg8AaN7+VdXBEkWiIgvexLNzorCU6AJBVKhZjUnhUEOxtZCewhvjRT6bgnFf/nw8 1oMxGJqmDOpR6vLaUXDpPCLC4jkZfM9k3BoPXC7NBNvMWItgFSN2UxXinL3IpRENK5 lOagRIW4S6I+l/gfUinHx6iXCe2Z0Gpv4fwGn9nfqnDwR+d+1avXMCfaDB4X7xWdSG O1cD8WZ4JheBvKkR/ElSu00hiEBmNNWzFo/GWsKozZPqpSiZrH7whb8CrE/rt2GLtR jzBXaYF/uZJ9qKrw++5Ff6qAFRX5Nrg6OKpJVEGmNIgP7t/md/R3/5m2YQ1l8pCi47 G2tRYQw1WihIg== Received: from aws-us-west-2-korg-oddjob-1.ci.codeaurora.org (localhost.localdomain [127.0.0.1]) by aws-us-west-2-korg-oddjob-1.ci.codeaurora.org (Postfix) with ESMTP id 60AE8E45226; Mon, 11 Jul 2022 13:10:12 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [PATCH v5 net-next] net: Find dst with sk's xfrm policy not ctl_sk From: patchwork-bot+netdevbpf@kernel.org Message-Id: <165754501239.30308.12114903372158946352.git-patchwork-notify@kernel.org> Date: Mon, 11 Jul 2022 13:10:12 +0000 References: <20220707100139.3748417-1-ssewook@gmail.com> In-Reply-To: <20220707100139.3748417-1-ssewook@gmail.com> To: Sewook Seo Cc: sewookseo@google.com, netdev@vger.kernel.org, davem@davemloft.net, yoshfuji@linux-ipv6.org, dsahern@kernel.org, kuba@kernel.org, pabeni@redhat.com, maze@google.com, edumazet@google.com, steffen.klassert@secunet.com, seheele@google.com Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hello: This patch was applied to netdev/net-next.git (master) by David S. Miller : On Thu, 7 Jul 2022 10:01:39 +0000 you wrote: > From: sewookseo > > If we set XFRM security policy by calling setsockopt with option > IPV6_XFRM_POLICY, the policy will be stored in 'sock_policy' in 'sock' > struct. However tcp_v6_send_response doesn't look up dst_entry with the > actual socket but looks up with tcp control socket. This may cause a > problem that a RST packet is sent without ESP encryption & peer's TCP > socket can't receive it. > This patch will make the function look up dest_entry with actual socket, > if the socket has XFRM policy(sock_policy), so that the TCP response > packet via this function can be encrypted, & aligned on the encrypted > TCP socket. > > [...] Here is the summary with links: - [v5,net-next] net: Find dst with sk's xfrm policy not ctl_sk https://git.kernel.org/netdev/net-next/c/e22aa1486668 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html