From patchwork Mon Apr 3 21:34:18 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Safonov X-Patchwork-Id: 13198827 X-Patchwork-Delegate: kuba@kernel.org 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 B4BCAC77B62 for ; Mon, 3 Apr 2023 21:37:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233389AbjDCVhN (ORCPT ); Mon, 3 Apr 2023 17:37:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51730 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233645AbjDCVgQ (ORCPT ); Mon, 3 Apr 2023 17:36:16 -0400 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 92D4E40CC for ; Mon, 3 Apr 2023 14:34:55 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id i9so30794547wrp.3 for ; Mon, 03 Apr 2023 14:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=google; t=1680557693; 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=mTUCL8/BOTl0j0dN4r+g/wrVq5oby7gw608S+52UjfU=; b=OgoWScC8bSVXS/8uJA773z9GiscLJh7KvydewG7z3ejqKwyli2AiyojRczJpMX2Bwt /yZKqrd/QT5NtZuIjCMK5VduMp7RaVskZTGqxIhL34hENb0+NYYRVveZPGxA88mooLl3 9Oo6BNQDdHmhu8BehBgsPQ1isWKBXpT+tfe5mEMUtrIalXJLEC+7ZmMgzmoqycUNpkGe DhvDuUqbFSf7Y6XKXgSomXLmtMKJXw9dpp4c2VAkJLHe7uNa/z0k3Yqt6DCnrJl8Zyis 72dYV7kzsZD58pud2bqsC7jivsMcFXNTsdYyMJXEkeg+iy7qRDnWvcLcRC3ScLAo9IyZ Za0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680557693; 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=mTUCL8/BOTl0j0dN4r+g/wrVq5oby7gw608S+52UjfU=; b=zS9rZhdSuwDWzwUpKfCzDXZ4pqOyFrOnEfVqWLoNpCBQBNBf4TxoD3K4w9HMzjXARO e1QN9GA0KKtXCtZQHzGcvmf/1QzJI/KPHakUTY85DgS2ypDsoSyXpor5ajXoEVw1jpED dJrLJWKqFU9Y6cOXFpewJdIsrZt+ZJLBAiekPgICbvIwCsAGOgKAv3K7rL4qT1nrFrUX PSv/5586np1j0RooG6YP73ln0LIDN2kii4xBeJEHLGcPXFCv8mWdHaH28K9R5tTpb4ri ywuenFliABqjmC0hBs/7PIEBQyCuy4SHPTcE+mIm+3sRwKBDUlXV2kvQ/GiiUst9dKyv 48Yg== X-Gm-Message-State: AAQBX9elFDU7KaQwaNDvp0YP6CCAkoBVs+LJX3934KzjS6W4xzz28BTJ yQ4bhhbjAdfYM0Eh3VnREF+eew== X-Google-Smtp-Source: AKy350asvjUSCRjNLTa5bMJp97oz+HeVNIcyRdOMedtCYwLN7oUw0VBkA3DaI+mqHy6EfA2wjDZuGg== X-Received: by 2002:adf:e951:0:b0:2e4:b9a3:4419 with SMTP id m17-20020adfe951000000b002e4b9a34419mr10980235wrn.51.1680557693733; Mon, 03 Apr 2023 14:34:53 -0700 (PDT) Received: from Mindolluin.ire.aristanetworks.com ([217.173.96.166]) by smtp.gmail.com with ESMTPSA id o5-20020a5d4a85000000b002c3f9404c45sm10682740wrq.7.2023.04.03.14.34.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Apr 2023 14:34:53 -0700 (PDT) From: Dmitry Safonov To: linux-kernel@vger.kernel.org, David Ahern , Eric Dumazet , Paolo Abeni , Jakub Kicinski , "David S. Miller" Cc: Dmitry Safonov , Andy Lutomirski , Ard Biesheuvel , Bob Gilligan , Dan Carpenter , David Laight , Dmitry Safonov <0x7f454c46@gmail.com>, Eric Biggers , "Eric W. Biederman" , Francesco Ruggeri , Herbert Xu , Hideaki YOSHIFUJI , Ivan Delalande , Leonard Crestez , Salam Noureddine , netdev@vger.kernel.org, Francesco Ruggeri Subject: [PATCH v5 19/21] net/tcp: Allow asynchronous delete for TCP-AO keys (MKTs) Date: Mon, 3 Apr 2023 22:34:18 +0100 Message-Id: <20230403213420.1576559-20-dima@arista.com> X-Mailer: git-send-email 2.40.0 In-Reply-To: <20230403213420.1576559-1-dima@arista.com> References: <20230403213420.1576559-1-dima@arista.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org 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=5ms max=10ms mean=6.93904ms stddev=0.263421 > ok 34 Add a new key 16384 keys: min=1ms max=4ms mean=2.17751ms stddev=0.147564 > ok 35 Remove random-search 16384 keys: min=5ms max=10ms mean=6.50243ms stddev=0.254999 > ok 36 Remove async 16384 keys: min=0ms max=0ms mean=0.0296107ms stddev=0.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 --- 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 21242ba2d237..d9a4b9bb9872 100644 --- a/net/ipv4/tcp_ao.c +++ b/net/ipv4/tcp_ao.c @@ -1464,7 +1464,7 @@ static int tcp_ao_add_cmd(struct sock *sk, unsigned short int family, } 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) { @@ -1472,11 +1472,24 @@ static int tcp_ao_delete_key(struct sock *sk, struct tcp_ao_info *ao_info, hlist_del_rcu(&key->node); + /* 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) @@ -1546,6 +1559,8 @@ static int tcp_ao_del_cmd(struct sock *sk, unsigned short int family, if (!new_rnext) return -ENOENT; } + if (cmd.del_async && sk->sk_state != TCP_LISTEN) + return -EINVAL; if (family == AF_INET) { struct sockaddr_in *sin = (struct sockaddr_in *)&cmd.addr; @@ -1590,8 +1605,8 @@ static int tcp_ao_del_cmd(struct sock *sk, unsigned short int family, if (key == new_current || key == new_rnext) continue; - 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; }