From nobody Thu Dec 18 07:32:44 2025 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 3DD52C04A6A for ; Tue, 15 Aug 2023 19:16:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239905AbjHOTQZ (ORCPT ); Tue, 15 Aug 2023 15:16:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239918AbjHOTPk (ORCPT ); Tue, 15 Aug 2023 15:15:40 -0400 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6ADB1138 for ; Tue, 15 Aug 2023 12:15:38 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-3fe1e1142caso56465695e9.0 for ; Tue, 15 Aug 2023 12:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=google; t=1692126937; x=1692731737; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=TCicV2Aib3M68fPnrmFoMTYBXDUU3WrcaJEwS9KBGbs=; b=KSrZc8SeRtjynMirvrDP537XDedzJqAMIdl1WW0Cepu9/zr4LB/skrKzCktxWF5XaW WPhYvDhP+jk6+6BRd/iVNoJ0KvV5lcxaYonubOY31VzUCCqLRUhdMMkn8oa5Zq0R2lod Q/dwxyNGAbYPG+2niUaq5R2TC71kQAgFBhmhGPD4jUpMGM8AXO4roMO3BLve3u4vXogB l7BYnkN6dWbhHgb2h8On6WjVzbaKr+9L5qRl2whBYMtCjl5I/OqtqgaC/HKdZZGnS9KG jDiQG6Yh4EMlO5Ie0l/2b+Pxey8H5BjbIJ7VB6Db/rxy7+Ydlx0akGK0GwVxv0Oqsc32 WM1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692126937; x=1692731737; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TCicV2Aib3M68fPnrmFoMTYBXDUU3WrcaJEwS9KBGbs=; b=GKu1JeHNImO4wyYhHDKjsgOyeMrXJBaq5wqW4hT/HQZrjLT8FOFwsNeu1UZyWtpm+e ndLmvos0X0hfnlkbPnaUA7r0ol3Ef/o8/iAN9abYeIOgu1u7m8acUMm18MUflxtBqeo2 mUgcbT8cMfAq1INcfXRTqYW9hiyE7zfy/vqanCwcKEr3TvjazCWRQzJDXoQAp9FXmu6w WCDEOakg4Kw4CuM9ZjH12mS0RTsa8pKeshYVZCuG53BM/0PqTOwytqFlZ8kFjIKHg5sX cOqSvCFSgl0JKuUWag9RF6CAIRZth5ezV6CSW4NlQ0GcRJmkQ4gduzoXpwUWf2FK1nXV 56+w== X-Gm-Message-State: AOJu0YwxzBRVAOORK8LfQbVLxg7Y5kYgwOoqCi+bWD3EuhjistR1OHb1 2ItsWk8BgWV+7mn93KDGh1j9lA== X-Google-Smtp-Source: AGHT+IF7H9W7EnUie786nxeBQ2hdYK8tOO/6cYa85d4L1yr6T/BjFLUhxfUL3oarWO8EVLGMa1/5YQ== X-Received: by 2002:a05:600c:2909:b0:3fe:2b8c:9f00 with SMTP id i9-20020a05600c290900b003fe2b8c9f00mr10327588wmd.24.1692126936972; Tue, 15 Aug 2023 12:15:36 -0700 (PDT) Received: from Mindolluin.ire.aristanetworks.com ([217.173.96.166]) by smtp.gmail.com with ESMTPSA id q9-20020a1ce909000000b003fbbe41fd78sm18779737wmc.10.2023.08.15.12.15.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Aug 2023 12:15:36 -0700 (PDT) From: Dmitry Safonov To: David Ahern , Eric Dumazet , Paolo Abeni , Jakub Kicinski , "David S. Miller" Cc: linux-kernel@vger.kernel.org, Dmitry Safonov , Andy Lutomirski , Ard Biesheuvel , Bob Gilligan , Dan Carpenter , David Laight , Dmitry Safonov <0x7f454c46@gmail.com>, Donald Cassidy , Eric Biggers , "Eric W. Biederman" , Francesco Ruggeri , "Gaillardetz, Dominik" , Herbert Xu , Hideaki YOSHIFUJI , Ivan Delalande , Leonard Crestez , "Nassiri, Mohammad" , Salam Noureddine , Simon Horman , "Tetreault, Francois" , netdev@vger.kernel.org Subject: [PATCH v10 net-next 19/23] net/tcp: Allow asynchronous delete for TCP-AO keys (MKTs) Date: Tue, 15 Aug 2023 20:14:48 +0100 Message-ID: <20230815191455.1872316-20-dima@arista.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230815191455.1872316-1-dima@arista.com> References: <20230815191455.1872316-1-dima@arista.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Delete becomes very, very fast - almost free, but after setsockopt() syscall returns, the key is still alive until next RCU grace period. Which is fine for listen sockets as userspace needs to be aware of setsockopt(TCP_AO) and accept() race and resolve it with verification by getsockopt() after TCP connection was accepted. The benchmark results (on non-loaded box, worse with more RCU work pending): > ok 33 Worst case delete 16384 keys: min=3D5ms max=3D10ms mean=3D6.9= 3904ms stddev=3D0.263421 > ok 34 Add a new key 16384 keys: min=3D1ms max=3D4ms mean=3D2.17= 751ms stddev=3D0.147564 > ok 35 Remove random-search 16384 keys: min=3D5ms max=3D10ms mean=3D6.5= 0243ms stddev=3D0.254999 > ok 36 Remove async 16384 keys: min=3D0ms max=3D0ms mean=3D0.02= 96107ms stddev=3D0.0172078 Co-developed-by: Francesco Ruggeri Signed-off-by: Francesco Ruggeri Co-developed-by: Salam Noureddine Signed-off-by: Salam Noureddine Signed-off-by: Dmitry Safonov Acked-by: David Ahern --- include/uapi/linux/tcp.h | 3 ++- net/ipv4/tcp_ao.c | 21 ++++++++++++++++++--- 2 files changed, 20 insertions(+), 4 deletions(-) diff --git a/include/uapi/linux/tcp.h b/include/uapi/linux/tcp.h index 1109093bbb24..979ff960fddb 100644 --- a/include/uapi/linux/tcp.h +++ b/include/uapi/linux/tcp.h @@ -383,7 +383,8 @@ struct tcp_ao_del { /* setsockopt(TCP_AO_DEL_KEY) */ __s32 ifindex; /* L3 dev index for VRF */ __u32 set_current :1, /* corresponding ::current_key */ set_rnext :1, /* corresponding ::rnext */ - reserved :30; /* must be 0 */ + del_async :1, /* only valid for listen sockets */ + reserved :29; /* must be 0 */ __u16 reserved2; /* padding, must be 0 */ __u8 prefix; /* peer's address prefix */ __u8 sndid; /* SendID for outgoing segments */ diff --git a/net/ipv4/tcp_ao.c b/net/ipv4/tcp_ao.c index 19ca3b36aa5a..124e9489f202 100644 --- a/net/ipv4/tcp_ao.c +++ b/net/ipv4/tcp_ao.c @@ -1578,7 +1578,7 @@ static int tcp_ao_add_cmd(struct sock *sk, unsigned s= hort int family, } =20 static int tcp_ao_delete_key(struct sock *sk, struct tcp_ao_info *ao_info, - struct tcp_ao_key *key, + bool del_async, struct tcp_ao_key *key, struct tcp_ao_key *new_current, struct tcp_ao_key *new_rnext) { @@ -1586,11 +1586,24 @@ static int tcp_ao_delete_key(struct sock *sk, struc= t tcp_ao_info *ao_info, =20 hlist_del_rcu(&key->node); =20 + /* Support for async delete on listening sockets: as they don't + * need current_key/rnext_key maintaining, we don't need to check + * them and we can just free all resources in RCU fashion. + */ + if (del_async) { + atomic_sub(tcp_ao_sizeof_key(key), &sk->sk_omem_alloc); + call_rcu(&key->rcu, tcp_ao_key_free_rcu); + return 0; + } + /* At this moment another CPU could have looked this key up * while it was unlinked from the list. Wait for RCU grace period, * after which the key is off-list and can't be looked up again; * the rx path [just before RCU came] might have used it and set it * as current_key (very unlikely). + * Free the key with next RCU grace period (in case it was + * current_key before tcp_ao_current_rnext() might have + * changed it in forced-delete). */ synchronize_rcu(); if (new_current) @@ -1661,6 +1674,8 @@ static int tcp_ao_del_cmd(struct sock *sk, unsigned s= hort int family, if (!new_rnext) return -ENOENT; } + if (cmd.del_async && sk->sk_state !=3D TCP_LISTEN) + return -EINVAL; =20 if (family =3D=3D AF_INET) { struct sockaddr_in *sin =3D (struct sockaddr_in *)&cmd.addr; @@ -1708,8 +1723,8 @@ static int tcp_ao_del_cmd(struct sock *sk, unsigned s= hort int family, if (key =3D=3D new_current || key =3D=3D new_rnext) continue; =20 - return tcp_ao_delete_key(sk, ao_info, key, - new_current, new_rnext); + return tcp_ao_delete_key(sk, ao_info, cmd.del_async, key, + new_current, new_rnext); } return -ENOENT; } --=20 2.41.0