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 5C889C43217 for ; Thu, 3 Nov 2022 16:54:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231823AbiKCQyA (ORCPT ); Thu, 3 Nov 2022 12:54:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53254 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230333AbiKCQxr (ORCPT ); Thu, 3 Nov 2022 12:53:47 -0400 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 59BB2E17 for ; Thu, 3 Nov 2022 09:53:46 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id i5-20020a1c3b05000000b003cf47dcd316so3774451wma.4 for ; Thu, 03 Nov 2022 09:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=m2fOM7m78o4CAWPlVEeyBmVxnJecOkxduoPEfpTUoqM=; b=ioyOWN5wxkmdtgjrMU3HQuhRDXkmiVR2jfdYdiPdAnya20uE3ZzziwurTdTTtg2Q6H iK/iS1Ot0fAysBd1TEf9EyG7mDQXAO2YZc5lRILOJt8cLan9JrGk6ya8oYOGOgusQ8H/ zByXf+gh2qNuq8mRpCdZD3XGBca153700LHJ09ENaBUy6iy1ECWDKkiE9WqE7hhpZWzH XbUJwGi/fq33ykisGTsxa7fpakEQWZIiK5mQtxw8NrKvdsRar7/FCXCLzZQ/BYt44D3s 1uHglvTJ4BH9mhlMJHsfKlLiUaSlLKQZQ1rd5BZk44TZn3ZchVu8OrrjaElXHf/v4wsc x0Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=m2fOM7m78o4CAWPlVEeyBmVxnJecOkxduoPEfpTUoqM=; b=SBRq45gNGBYQCUkh0Czmc3DXf1gzWG7HLzRmwcl3fMiJ3o7OLubMQ6H6zqcBxSZsl9 8kb15F6HXZNnhE22Dr/Q2Vif40tyX9GLAY1Yg2cT4i5HWNWHKuU9MGSG6mjlPP++xOVq d+jDMokZV5Sg5G+Puzz8zbXrODSp1LZD6OGK/O859aS5XyBlefFvIhoNjfqymEpDvomW PiYWmijU/+J4MiRZC7dSz523AedeJKBFLjahXr4AJqWOsWtzy5OQqRTCIeHQicFnDrYq ffRsYybN789cZVoQE/CYR2l/pEZHQZJ3CELzLDyL314T9Tp6XuIA1eHR6ekLTn676uKN hsoA== X-Gm-Message-State: ACrzQf2dGpgjT5QvVeespjDB9Lk9mvjUaU+oOdabmIMEteAtXgyy6wXn zH4eg/Yr7j5oAspH9RZ6kg3g8w== X-Google-Smtp-Source: AMsMyM7/xaxHvv8sFAacrmC3C9kRoiHF/tQFY79ULG42XLdzn/0slDP53+/D8kN4hBRc1mIuFfg0Gw== X-Received: by 2002:a05:600c:3d18:b0:3cf:4c1e:5812 with SMTP id bh24-20020a05600c3d1800b003cf4c1e5812mr30145636wmb.192.1667494424902; Thu, 03 Nov 2022 09:53:44 -0700 (PDT) Received: from [10.83.37.24] ([217.173.96.166]) by smtp.gmail.com with ESMTPSA id n18-20020a05600c465200b003b497138093sm256033wmo.47.2022.11.03.09.53.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Nov 2022 09:53:44 -0700 (PDT) Message-ID: Date: Thu, 3 Nov 2022 16:53:38 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3 Subject: Re: [PATCH 2/2] net/tcp: Disable TCP-MD5 static key on tcp_md5sig_info destruction Content-Language: en-US To: Eric Dumazet Cc: linux-kernel@vger.kernel.org, David Ahern , Bob Gilligan , "David S. Miller" , Dmitry Safonov <0x7f454c46@gmail.com>, Francesco Ruggeri , Hideaki YOSHIFUJI , Jakub Kicinski , Paolo Abeni , Salam Noureddine , netdev@vger.kernel.org References: <20221102211350.625011-1-dima@arista.com> <20221102211350.625011-3-dima@arista.com> From: Dmitry Safonov In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/2/22 21:25, Eric Dumazet wrote: > On Wed, Nov 2, 2022 at 2:14 PM Dmitry Safonov wrote: [..] >> @@ -337,11 +338,13 @@ EXPORT_SYMBOL(tcp_time_wait); >> void tcp_twsk_destructor(struct sock *sk) >> { >> #ifdef CONFIG_TCP_MD5SIG >> - if (static_branch_unlikely(&tcp_md5_needed)) { >> + if (static_branch_unlikely(&tcp_md5_needed.key)) { >> struct tcp_timewait_sock *twsk = tcp_twsk(sk); >> >> - if (twsk->tw_md5_key) >> + if (twsk->tw_md5_key) { > > Orthogonal to this patch, but I wonder why we do not clear > twsk->tw_md5_key before kfree_rcu() > > It seems a lookup could catch the invalid pointer. > >> kfree_rcu(twsk->tw_md5_key, rcu); >> + static_branch_slow_dec_deferred(&tcp_md5_needed); >> + } >> } I looked into that, it seems tcp_twsk_destructor() is called from inet_twsk_free(), which is either called from: 1. inet_twsk_put(), protected by tw->tw_refcnt 2. sock_gen_put(), protected by the same sk->sk_refcnt So, in result, if I understand correctly, lookups should fail on ref counter check. Maybe I'm missing something, but clearing here seems not necessary? I can add rcu_assign_pointer() just in case the destruction path changes in v2 if you think it's worth it :-) Thanks, Dmitry