From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9D4E243C043 for ; Tue, 20 Jan 2026 14:13:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768918415; cv=none; b=HyepAVuDN9toRv+LeF278rF7q8CR4wBFPQovwHpfuwM/vyFNxCFCAFb7XsKjjHc5f2k3iJmzVATEtLQtKcFZ78P86CC/EiaR7A4sEUPpmB4ag5DK45bjqyKIFbN7/qoIKTnUIWpVKcDRbM9InRNoBG2BG4Kly7h6QL3alorvOqM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768918415; c=relaxed/simple; bh=MTXAttGcmQV+gKT1VuxP3RbxteQV73dhqFSiu5vTsKw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GeYxAqC+rTTDLCGVj+gq9ECtFoqP5lCxnzaetYxYjB86jM+hVNna145SV+Le5ezB/Q8eP0TXGr+RC/SJpiXH6YNizEuTPHbv5EiIUIb4URtYVfV+tGhppXbuY//YdRClrsZptJ56ejMI8soV5qFarGJpXuEnPoySk85lR7xnKnc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=F6nRyobx; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="F6nRyobx" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768918412; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=o4YIZav5bzJmQLAgwNywWVFJIuBH5AeoqXsTBWn1nZk=; b=F6nRyobxxQ8YvcWxJKiDL0VR0iacWnJWXTrVL2kQW40sMKnf58/ifcxNcRLqEPi453oYOI JQ35hNkdm3pXOysiNhIejzA1m2sbSH943hhLJWymVT4Bc8fY7/BUCPNEAAX30VnCJT6nyb eEBsIRUWbpf/a+rFqafbcVOqHHCHOFg= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-596-6xVG9zOPNYuYeLSu5jLWEg-1; Tue, 20 Jan 2026 09:13:31 -0500 X-MC-Unique: 6xVG9zOPNYuYeLSu5jLWEg-1 X-Mimecast-MFC-AGG-ID: 6xVG9zOPNYuYeLSu5jLWEg_1768918410 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-4359064a1daso429226f8f.1 for ; Tue, 20 Jan 2026 06:13:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768918410; x=1769523210; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=o4YIZav5bzJmQLAgwNywWVFJIuBH5AeoqXsTBWn1nZk=; b=dlCbvM+jFkwdayYjoWB4HvibGW/QJLRHyza6GrikdFa1rmrWyzuwq7LdW36wSFxeui sC0msCR1LoNUI8QLLMv0AWD6nb86YoXYOI3d+O+QX+hl2P3B4KoLS25srgWvG+nvcIWB nOSJNWUzioqNjrRilXc+sAlQfpKL2UFusEuYMcsmsUHlFp0al0F65ITDVXIc2P6PdAj3 iAC+0fiXzZSz/5j94LaV9QF6z9HkN2HgYMgMIjbujEqTBcaZClKkLX/ddD1gKzR0s//H grHpnP7AfvoMb3mpgGB+7e7uCwxny3jo1wrK/vRlTzCSpGKR0DkH+DmWyaHieAlNJn6Z NzNw== X-Forwarded-Encrypted: i=1; AJvYcCXkW2aIrFdxDiSd1vMSHFxZuLKuf6gD6+yUMMyQaoS70LYjyBXZ0wfUWJpSWLo9Is5IfAxx@lists.linux.dev X-Gm-Message-State: AOJu0Ywh9okjU1q30+BStgHW9eCfk2GUnyPveNxEn1VtRyGOWzs5WGKB 2yqJYeucnY6PuLUzYXACdCFG5wAEwXAeKXx9VXgR0hSS5mrU/bOdV5dygyOj9DjAox8bs0ADys8 /5gA5bAQ0L8t51+JBI7qcbQz7LzKtxf+vbyOnpsWufItQv2Yu7w75HL0= X-Gm-Gg: AZuq6aKwhk2+seX63d8LalKihmWF7YIGh5PjhcGGKwv+gnRfUKZwRdLkIvmvJLm9KsD /1MyG9FuhrbGPiQjYfPWX4NBPavz4SZ48soVA6/X061IXrHn3KTavPb77fumd0tLYSa6r3ocB5E HvQS9sT+ld3/qRKQ2PXSdO7XiapGlLwLSjEP2/kiwpOw1vSo7RM3/55VlSWllh5nKdR9STzP7wI elzQ1+YJrlOyGIK3NZ0JZfw1d8lTm7VWA9nwpdDRu6tejGDH9nEF0c9qYzBi19TW71r0pMZNJ1t HkSvYU5q9iSG9eX6Ok97LAvOJjQrZ/qPYbr6MEsk6ajAP4aZF2aTaAyQUBUFyt0A5A1GGOwFjYn Ld1RhyFygJtwh X-Received: by 2002:a5d:5887:0:b0:432:8504:8d5b with SMTP id ffacd0b85a97d-43569bcb816mr18237058f8f.50.1768918409987; Tue, 20 Jan 2026 06:13:29 -0800 (PST) X-Received: by 2002:a5d:5887:0:b0:432:8504:8d5b with SMTP id ffacd0b85a97d-43569bcb816mr18236980f8f.50.1768918409485; Tue, 20 Jan 2026 06:13:29 -0800 (PST) Received: from [192.168.88.32] ([150.228.93.113]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43596b62700sm581337f8f.42.2026.01.20.06.13.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jan 2026 06:13:28 -0800 (PST) Message-ID: <71705484-46fc-469f-9357-07a076ee0e73@redhat.com> Date: Tue, 20 Jan 2026 15:13:22 +0100 Precedence: bulk X-Mailing-List: quic@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v7 08/16] quic: add path management To: Xin Long , network dev , quic@lists.linux.dev Cc: davem@davemloft.net, kuba@kernel.org, Eric Dumazet , Simon Horman , Stefan Metzmacher , Moritz Buhl , Tyler Fanelli , Pengtao He , Thomas Dreibholz , linux-cifs@vger.kernel.org, Steve French , Namjae Jeon , Paulo Alcantara , Tom Talpey , kernel-tls-handshake@lists.linux.dev, Chuck Lever , Jeff Layton , Steve Dickson , Hannes Reinecke , Alexander Aring , David Howells , Matthieu Baerts , John Ericson , Cong Wang , "D . Wythe" , Jason Baron , illiliti , Sabrina Dubroca , Marcelo Ricardo Leitner , Daniel Stenberg , Andy Gospodarek References: <3771dfc211626a9f0c603c90113e38f325ceb456.1768489876.git.lucien.xin@gmail.com> From: Paolo Abeni In-Reply-To: <3771dfc211626a9f0c603c90113e38f325ceb456.1768489876.git.lucien.xin@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Y5yBOuVmBvyWi04iYZQE5RkoH-mB_0Owgx9ByLhA_sA_1768918410 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/15/26 4:11 PM, Xin Long wrote: > @@ -0,0 +1,524 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* QUIC kernel implementation > + * (C) Copyright Red Hat Corp. 2023 > + * > + * This file is part of the QUIC kernel implementation > + * > + * Initialization/cleanup for QUIC protocol support. > + * > + * Written or modified by: > + * Xin Long > + */ > + > +#include > +#include > + > +#include "common.h" > +#include "family.h" > +#include "path.h" > + > +static int (*quic_path_rcv)(struct sock *sk, struct sk_buff *skb, u8 err); It's unclear why an indirect call is needed here. At least some explanation is needed in the commit message, possibly you could call directly a static function. > + > +static int quic_udp_rcv(struct sock *sk, struct sk_buff *skb) > +{ > + memset(skb->cb, 0, sizeof(skb->cb)); > + QUIC_SKB_CB(skb)->seqno = -1; > + QUIC_SKB_CB(skb)->time = quic_ktime_get_us(); > + > + skb_pull(skb, sizeof(struct udphdr)); > + skb_dst_force(skb); > + quic_path_rcv(sk, skb, 0); > + return 0; Why not: return quic_path_rcv(sk, skb, 0); ? > +static struct quic_udp_sock *quic_udp_sock_create(struct sock *sk, union quic_addr *a) > +{ > + struct udp_tunnel_sock_cfg tuncfg = {}; > + struct udp_port_cfg udp_conf = {}; > + struct net *net = sock_net(sk); > + struct quic_uhash_head *head; > + struct quic_udp_sock *us; > + struct socket *sock; > + > + us = kzalloc(sizeof(*us), GFP_KERNEL); > + if (!us) > + return NULL; > + > + quic_udp_conf_init(sk, &udp_conf, a); > + if (udp_sock_create(net, &udp_conf, &sock)) { > + pr_debug("%s: failed to create udp sock\n", __func__); > + kfree(us); > + return NULL; > + } > + > + tuncfg.encap_type = 1; > + tuncfg.encap_rcv = quic_udp_rcv; > + tuncfg.encap_err_lookup = quic_udp_err; > + setup_udp_tunnel_sock(net, sock, &tuncfg); > + > + refcount_set(&us->refcnt, 1); > + us->sk = sock->sk; > + memcpy(&us->addr, a, sizeof(*a)); > + us->bind_ifindex = sk->sk_bound_dev_if; > + > + head = quic_udp_sock_head(net, ntohs(a->v4.sin_port)); > + hlist_add_head(&us->node, &head->head); > + INIT_WORK(&us->work, quic_udp_sock_put_work); > + > + return us; > +} > + > +static bool quic_udp_sock_get(struct quic_udp_sock *us) > +{ > + return refcount_inc_not_zero(&us->refcnt); > +} > + > +static void quic_udp_sock_put(struct quic_udp_sock *us) > +{ > + if (refcount_dec_and_test(&us->refcnt)) > + queue_work(quic_wq, &us->work); Why using a workqueue here? AFAICS all the caller are in process context. Is that to break a possible deadlock due to nested mutex? Likely a comment on the refcount/locking scheme would help. /P