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 129F6EB64DA for ; Wed, 14 Jun 2023 07:09:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242895AbjFNHJN (ORCPT ); Wed, 14 Jun 2023 03:09:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34694 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243206AbjFNHJM (ORCPT ); Wed, 14 Jun 2023 03:09:12 -0400 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6E43A1BD3; Wed, 14 Jun 2023 00:09:08 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-977cf86aae5so52808966b.0; Wed, 14 Jun 2023 00:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686726547; x=1689318547; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=JQ68G2T9sQKjPb+2pkANGWg3W2HeuEanoLaoohVC2mo=; b=K/CUsWp6tf8rMVWWwmL2Rxpb5lnD4znSw3ZLjYsCEf5ztUVzahW5PKWq2sexwsUbx6 rbBAFfB5M1PYwDVjrSfWc5WaJFUGQQmUQZlcxpHPaUr7NfLQ8OB7U4U3B90VngDBTI7+ WpXMf9UP76VxMmfJ1Yxxja9co+NEbVrLRSQruaAM6rWen8rNcXoeOciju5Qcq3UnAtTX AwxqHGVlRrhImBZ76j+vrHT18VAFUvt8bFTkwn2MwnFvYcdwLVq1LDxLK8veP/ATwFC9 QyK3H1QBMQMhqQpEFOXkTG6Q0w/gUeVDFilLRtLn2m2KklC69VyFHlXCPuQWdnk9L+xn 79dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686726547; x=1689318547; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JQ68G2T9sQKjPb+2pkANGWg3W2HeuEanoLaoohVC2mo=; b=baEn5B4/erawvorsyaifWTB0ok3azepMqTKGGmMP/H/b9VKSt9ga+EA+pPa1C2QDD0 kW8uk4x2HSm5GeKVPbrDFhTKE1Xgzi1Mi7mFkFSbSixulUlWbmJMrd1H0Bl2vCdfqMgF WRIA7KkNovvYe7OKj4VbOe2qsD6gpKrbuBVOxmdJWE/Ky98J5dJPOuVVSAYz0cfEZ2/E gCAHYG25qG9x2Fh3lu4J1eEqGzAR+x/ooVl/Q7vz1/MsfV9ZZLdfvRa8w7/kib+eqyGD 6Wx7HV4QMqIvc7WFw2HZYZYOG0kITizqmX0WKognWzxHl3HYt1mV5bdxJ6E2EHUA5Pm2 eQwg== X-Gm-Message-State: AC+VfDzoozGs4y/+e0yLv8MRPnpZhsfzioz80/ixkoq254LGzemrnnib lXGmbBO3+TTRYqw45gldKDc= X-Google-Smtp-Source: ACHHUZ75lXtTVkbsy75zZgLVfmZqSpIPIV68GNPDB1JimL+QNuFasY8bcAhE87hFZNwdR2nGRQpNjw== X-Received: by 2002:a17:907:168a:b0:982:3bae:afda with SMTP id hc10-20020a170907168a00b009823baeafdamr4073647ejc.45.1686726546545; Wed, 14 Jun 2023 00:09:06 -0700 (PDT) Received: from localhost ([185.220.101.84]) by smtp.gmail.com with ESMTPSA id rh15-20020a17090720ef00b00977d7bd9069sm7711888ejb.179.2023.06.14.00.09.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jun 2023 00:09:05 -0700 (PDT) Date: Wed, 14 Jun 2023 10:09:02 +0300 From: Maxim Mikityanskiy To: Jakub Kicinski Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com, pabeni@redhat.com, j.vosburgh@gmail.com, andy@greyhouse.net, rajur@chelsio.com, ayush.sawal@chelsio.com, dmichail@fungible.com, borisp@nvidia.com, saeedm@nvidia.com, leon@kernel.org, simon.horman@corigine.com, john.fastabend@gmail.com, anirudh.venkataramanan@intel.com, tariqt@nvidia.com, gal@nvidia.com, raeds@nvidia.com, liorna@nvidia.com, louis.peens@corigine.com, yinjun.zhang@corigine.com, na.wang@corigine.com, linux-rdma@vger.kernel.org, oss-drivers@corigine.com Subject: Re: [PATCH net-next] net: tls: make the offload check helper take skb not socket Message-ID: References: <20230613205006.1995873-1-kuba@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230613205006.1995873-1-kuba@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Tue, 13 Jun 2023 at 13:50:06 -0700, Jakub Kicinski wrote: > All callers of tls_is_sk_tx_device_offloaded() currently do > an equivalent of: > > if (skb->sk && tls_is_skb_tx_device_offloaded(skb->sk)) > > Have the helper accept skb and do the skb->sk check locally. > Two drivers have local static inlines with similar wrappers > already. > > While at it change the ifdef condition to TLS_DEVICE. > Only TLS_DEVICE selects SOCK_VALIDATE_XMIT, so the two are > equivalent. This makes removing the duplicated IS_ENABLED() > check in funeth more obviously correct. > > Signed-off-by: Jakub Kicinski Acked-by: Maxim Mikityanskiy Nice cleanup, thanks! [...] > diff --git a/include/net/tls.h b/include/net/tls.h > index b7d0f1e3058b..5e71dd3df8ca 100644 > --- a/include/net/tls.h > +++ b/include/net/tls.h > @@ -370,10 +370,12 @@ struct sk_buff * > tls_validate_xmit_skb_sw(struct sock *sk, struct net_device *dev, > struct sk_buff *skb); > > -static inline bool tls_is_sk_tx_device_offloaded(struct sock *sk) > +static inline bool tls_is_skb_tx_device_offloaded(const struct sk_buff *skb) > { > -#ifdef CONFIG_SOCK_VALIDATE_XMIT > - return sk_fullsock(sk) && > +#ifdef CONFIG_TLS_DEVICE > + struct sock *sk = skb->sk; > + > + return sk && sk_fullsock(sk) && > (smp_load_acquire(&sk->sk_validate_xmit_skb) == > &tls_validate_xmit_skb); > #else After this change, the only usage of CONFIG_SOCK_VALIDATE_XMIT remains in sk_validate_xmit_skb, which has #ifdef CONFIG_TLS_DEVICE inside #ifdef CONFIG_SOCK_VALIDATE_XMIT. If feels a little bit weird, given that both defines always have the same value, but maybe it's OK if we consider that more users can start using sk_validate_xmit_skb in the future.