From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.secunet.com (mx1.secunet.com [62.96.220.36]) (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 C04B33806B0 for ; Mon, 23 Mar 2026 08:35:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.96.220.36 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774254905; cv=none; b=iMgnFLSM00WGfpZB2cIlU6uNU7yaNzbo9+FoxN1/P0lX39aGiRYxrWhfi08ij+/y4JKvHmGaxLlkGAox1IMiuJ/HNg0X9H1ffd+O/0oijm5JQn76BuS6DSMZ40JMDSDrWbpqhERhy28vLxtHphWFn7EXHXUSoKa1mmWXfwWQOQs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774254905; c=relaxed/simple; bh=yPtdGhLOrf55caGvXqbLHyzWu0m/W7V1yckdskI4rSA=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nEdryjw+K0I+sBgj9eXCwfxFAxf0ECTtjHGuGrwJJs87tlqgF4M2usbF4vudT9pGiIuv31c1Gus2KCSeJztko9Ua6wKi0FH+A7oCfwtsh8vHEfnBv1UdwTSE2UmsZ/iSg+7xWgo4bGbympDxwzyhJDu5fCHdfGz+Cxka5liocYQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=secunet.com; spf=pass smtp.mailfrom=secunet.com; dkim=pass (2048-bit key) header.d=secunet.com header.i=@secunet.com header.b=r04lhs+z; arc=none smtp.client-ip=62.96.220.36 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=secunet.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=secunet.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=secunet.com header.i=@secunet.com header.b="r04lhs+z" Received: from localhost (localhost [127.0.0.1]) by mx1.secunet.com (Postfix) with ESMTP id F34D42068C; Mon, 23 Mar 2026 09:35:01 +0100 (CET) X-Virus-Scanned: by secunet Received: from mx1.secunet.com ([127.0.0.1]) by localhost (mx1.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuRUfOZYg9Fn; Mon, 23 Mar 2026 09:35:01 +0100 (CET) Received: from EXCH-01.secunet.de (rl1.secunet.de [10.32.0.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.secunet.com (Postfix) with ESMTPS id 66F7A20826; Mon, 23 Mar 2026 09:35:01 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.secunet.com 66F7A20826 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secunet.com; s=202301; t=1774254901; bh=F9CsMuVnJspOENv/ZDnvJaW4LuQ8CZjdXxkU6+EaCv4=; h=From:To:CC:Subject:Date:In-Reply-To:References:From; b=r04lhs+zD2P3BkhaIyxQ/pCTEM62DLLcjpmZXj5TLg/5P1RjSSTFgj139KyToQ2l+ i2DEPdRxNflM8A87IbZbFRTpuTXcfsgYH0cabUM740OPXkABEbif818E4E/dUvCZ0D CBa6Nk2jo5tgW1LQZ+Y+dt5pe2aA1loDrzqk7wKgaH3e8O8RvY7cJMVTpAH3fCwpwG RYc19C3WWF++8iEfo6GNjNs3F0ZzKauCtIP2fmDOtqs2zyrZrR50w+ukTNSBaWaXp1 3H8HILcyrfCKW2IbFxe87EsfABNpwzSOMCq3+MI+rJsvPNEf/fBnutPtxLSCQYgodx H7v5MWa6Gb5tQ== Received: from secunet.com (10.182.7.193) by EXCH-01.secunet.de (10.32.0.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 23 Mar 2026 09:35:00 +0100 Received: (nullmailer pid 2741806 invoked by uid 1000); Mon, 23 Mar 2026 08:34:49 -0000 From: Steffen Klassert To: David Miller , Jakub Kicinski CC: Herbert Xu , Steffen Klassert , Subject: [PATCH 03/20] xfrm: call xdo_dev_state_delete during state update Date: Mon, 23 Mar 2026 09:33:44 +0100 Message-ID: <20260323083440.2741292-4-steffen.klassert@secunet.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260323083440.2741292-1-steffen.klassert@secunet.com> References: <20260323083440.2741292-1-steffen.klassert@secunet.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: EXCH-03.secunet.de (10.32.0.183) To EXCH-01.secunet.de (10.32.0.171) From: Sabrina Dubroca When we update an SA, we construct a new state and call xdo_dev_state_add, but never insert it. The existing state is updated, then we immediately destroy the new state. Since we haven't added it, we don't go through the standard state delete code, and we're skipping removing it from the device (but xdo_dev_state_free will get called when we destroy the temporary state). This is similar to commit c5d4d7d83165 ("xfrm: Fix deletion of offloaded SAs on failure."). Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") Signed-off-by: Sabrina Dubroca Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert --- net/xfrm/xfrm_state.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c index 98b362d51836..a00c4fe1ab0c 100644 --- a/net/xfrm/xfrm_state.c +++ b/net/xfrm/xfrm_state.c @@ -2264,6 +2264,7 @@ int xfrm_state_update(struct xfrm_state *x) err = 0; x->km.state = XFRM_STATE_DEAD; + xfrm_dev_state_delete(x); __xfrm_state_put(x); } -- 2.43.0