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.129.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 2610B44CAD9 for ; Thu, 7 May 2026 17:08:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778173722; cv=none; b=SStZ9Bkn395gK0LQqgJxq/CKAewTj37/F5fsV7sr2ciEF+Z3t7SRNY0qkibrzOjECm5w1fbjFNoexN+DyZ4Xl9ZEQdNQ/twH4gOYRPcWHmtbB/wNz44Ty5XvrRR7SaGSVD2dfyduyDistlkJSHiPnYeQK+aNPYqlSdsFvpVgg1w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778173722; c=relaxed/simple; bh=k5L9T9HuspKLeaPcV4E6F4xntMBi1FakBcE91U1GjXc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=I50deE1UG17Ppv5dlKd3vfsIdp4ABiCsmLVZKpbinCwj0XHapKTsIV5bNPP5PGvqcfUX2yo9Rwct8c2uXZjPmeLyC/D5nMqtX9eh/GbvDp06oBsrMtGK9K9ZD36R+ozJXLDhUmwsOlWz6wJF3H/vKOWz1WXEBWUGGzTquczwAE0= 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=GT6z0Nt/; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=nXyFOwy8; arc=none smtp.client-ip=170.10.129.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="GT6z0Nt/"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="nXyFOwy8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778173720; 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=0g8BZOUIqwFMf5MczCTWS57/QZes3BdStmRaQBqy/OM=; b=GT6z0Nt/2SrkXA2FL7PpDkBWL6fviklKZm/vCGCGZdah3FZYaJ5ZzLr6Y919H673UOzUn+ d4gvs1KInL9EYo8bAjUdi4IMJyVQ8hgUlkhbCqlHcUoWz913FM8VCH5hseU/M8JdnT+zwh itBPt0YqaL77PxiSchTt57AMIdJDpLA= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-655-uWLoE2NLN6SbObqJxtaIyw-1; Thu, 07 May 2026 13:08:39 -0400 X-MC-Unique: uWLoE2NLN6SbObqJxtaIyw-1 X-Mimecast-MFC-AGG-ID: uWLoE2NLN6SbObqJxtaIyw_1778173718 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-48a7994e8ddso7756445e9.0 for ; Thu, 07 May 2026 10:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1778173718; x=1778778518; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=0g8BZOUIqwFMf5MczCTWS57/QZes3BdStmRaQBqy/OM=; b=nXyFOwy84ve88Pi4QwYHjAkySulT/EX7n0GL4dnT5tKloxDGxYrKRQmvUnMuqkw8Ft yimHLlJOGdLEh0qL9MiQJ1GevnDiC8T8TPwb4iitwfDJSEWxNSNraGhmHMVOJ+bn0P0h 3KM2pdv85lTsp3uO710cEpCyOn5pMD3p1hCbA8jstQNwYjp/xQeCxp4VFDyISTToSMpC 09r+oFxcAuVi/TVrUeDUaa7Cac7hbjuACPWzbEzctMe3Ci6/9aLjFZoUvwre74bPKgnG be1WZUZSlTOALLOHwzq7oj5+Fd5Vj5B1a6RiDSvwddgGvDKiCJOeflWOvg7G6InMlHmm h0KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778173718; x=1778778518; h=content-transfer-encoding:in-reply-to:content-language:from :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=0g8BZOUIqwFMf5MczCTWS57/QZes3BdStmRaQBqy/OM=; b=p6RGn4Fp6ktPQlPHj+ZCn9AmIFVkdY5yHIiFcp8ptFJM68jrORcRFQZEGt6JkLKb9w 2KdGG96Ghxnvxa0iulo5r0Ho6QgX45tAei3utty9ilFnsxf/AqfeD1Gj6ixE5GcieyeF vYqH2IgrOCeZuZan5XH4NIvixS9uSKO3Eqe+NTmsE6oM4qDfwVBfoHPA0pEgcBY+KZyh NX99L/HG/0GFY4OvdC9m5kxahW7mOP+nigcokEWhYbJFAg2qgKGi+tC24YsOMFIRjLR0 kL2i8zwCMRGtbj3CA8dCbZY6ToaJZz+TIm3xFEAYg1jw98GgCbXyHqhyQWuRmAtbUOW3 yKEA== X-Forwarded-Encrypted: i=1; AFNElJ8w+wGdlr2x9eu0lKBbeB0TLRyHTWgVYOh7x35zQrEKW7N5tbrdW0YmOGh2GX05pT2rqIza/98SipOC5+I=@vger.kernel.org X-Gm-Message-State: AOJu0YzxsCOy1WBM6L+D7QzajHolBW26vq/+hI0bfg4hYDvf1pp5ifNH JKlqxkJcPR0syAQ6/SA9KAuX1ZBSWWNgV/fCFCAkcuFOmsjeqQW5F++5SbsAXkecsVe8yagJCA5 YLJIJO6k00k4Gx/+Xa8DuQiQbJt7wi+K9roky/sc0pqGRmyKMcA2BXhj3ZzD5mQkPZg== X-Gm-Gg: AeBDieuHSdU0WPSNAVnMU3T2PWK3VOr16Zl3IKh0UiMCsGXelhMGSAqgeV2ugE841St wDOj5wE+fpXELegP75lxofdz3NYEAFKlE9Z2C4PCRfiMvz/JKK/opzhe7bNvTkcR3gWBGEPVqLD xX+/otoA40SE4TDJBRoYWJSNldMF9WYJMNsUFarfs2lITrTVjVnGiT3uw54vgd/yFMtXyg8gay8 f9P+b/5b4gYNVcMHbzA+66G1Q+jFhUMjKUB7JNPzI/AsDSBL/f0zOQozGzc/yFdTOBl2802rpq7 G9xDptIEg6ay8+CeExSxvH0tPAkKyuiNKIEfBFfVBoFnSLZzqJgGaVmOy7P9zwxCXWn9tonEnwM L6/gaaS/2t1QNO5Kd9zbc8+AGRT6XPPSDRK2ATZKR62S5byvjTzG/Cz4= X-Received: by 2002:a05:600c:8485:b0:48a:76a3:2b9b with SMTP id 5b1f17b1804b1-48e51f32811mr149911105e9.17.1778173716963; Thu, 07 May 2026 10:08:36 -0700 (PDT) X-Received: by 2002:a05:600c:8485:b0:48a:76a3:2b9b with SMTP id 5b1f17b1804b1-48e51f32811mr149910515e9.17.1778173716440; Thu, 07 May 2026 10:08:36 -0700 (PDT) Received: from [192.168.88.32] ([150.228.93.82]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45417bb92ebsm329213f8f.37.2026.05.07.10.08.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 May 2026 10:08:35 -0700 (PDT) Message-ID: Date: Thu, 7 May 2026 19:08:34 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mptcp: serialize subflow->closing with RX path To: Kalpan Jani , matttbe@kernel.org, martineau@kernel.org, mptcp@lists.linux.dev, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: shardul.b@mpiricsoftware.com, janak@mpiric.us, kalpanjani009@gmail.com, shardulsb08@gmail.com References: <20260507072802.612125-1-kalpan.jani@mpiricsoftware.com> From: Paolo Abeni Content-Language: en-US In-Reply-To: <20260507072802.612125-1-kalpan.jani@mpiricsoftware.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/7/26 9:28 AM, Kalpan Jani wrote: > There is a race between mptcp_data_ready() (RX path) and > mptcp_close_ssk() (teardown path) when accessing subflow->closing. > > Currently, mptcp_data_ready() checks subflow->closing before acquiring > mptcp_data_lock(), while mptcp_close_ssk() may concurrently set > subflow->closing and Are you sure this race can really happen? both the relevant part of __mptcp_close_ssk() and mptcp_data_ready() run under the ssk socket lock. > @@ -2653,9 +2673,12 @@ void mptcp_close_ssk(struct sock *sk, struct sock *ssk, > if (sk->sk_state == TCP_ESTABLISHED) > mptcp_event(MPTCP_EVENT_SUB_CLOSED, mptcp_sk(sk), ssk, GFP_KERNEL); > > - /* Remove any reference from the backlog to this ssk; backlog skbs consume > + /* Remove any reference from the backlog to this ssk. > + * Serialize cleanup with RX-side enqueue using mptcp_data_lock(). > + * Backlog skbs consume > * space in the msk receive queue, no need to touch sk->sk_rmem_alloc > */ > + mptcp_data_lock(sk); > list_for_each_entry(skb, &msk->backlog_list, list) { > if (skb->sk != ssk) > continue; The real problem is here: the backlog is currently traversed without the data lock (wrong: the mptcp_data_lock() protects backlog updates), while the ssk is still possibly open, unlocked and can keep receiving packets and adding them to the BL. A better solution would be something alike the following patch (completely untested): --- diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 718e910ff23f..68d97926cb81 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2550,6 +2550,21 @@ static void __mptcp_close_ssk(struct sock *sk, struct sock *ssk, lock_sock_nested(ssk, SINGLE_DEPTH_NESTING); subflow->closing = 1; + /* Remove any reference from the backlog to this ssk; backlog skbs consume + * space in the msk receive queue, no need to touch sk->sk_rmem_alloc + */ + if (flags & MPTCP_CF_PUSH) { + mptcp_data_lock(sk); + list_for_each_entry(skb, &msk->backlog_list, list) { + if (skb->sk != ssk) + continue; + + atomic_sub(skb->truesize, &skb->sk->sk_rmem_alloc); + skb->sk = NULL; + } + mptcp_data_unlock(sk); + } + /* Borrow the fwd allocated page left-over; fwd memory for the subflow * could be negative at this point, but will be reach zero soon - when * the data allocated using such fragment will be freed. @@ -2653,17 +2668,6 @@ void mptcp_close_ssk(struct sock *sk, struct sock *ssk, if (sk->sk_state == TCP_ESTABLISHED) mptcp_event(MPTCP_EVENT_SUB_CLOSED, mptcp_sk(sk), ssk, GFP_KERNEL); - /* Remove any reference from the backlog to this ssk; backlog skbs consume - * space in the msk receive queue, no need to touch sk->sk_rmem_alloc - */ - list_for_each_entry(skb, &msk->backlog_list, list) { - if (skb->sk != ssk) - continue; - - atomic_sub(skb->truesize, &skb->sk->sk_rmem_alloc); - skb->sk = NULL; - } - /* subflow aborted before reaching the fully_established status * attempt the creation of the next subflow */