From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793801626; b=Tl38m7GCOuZiE9k6/VGEcjeG/2GkC9BudsCi++8h3wGRMNM3NNEB5fPkzr8dEVZfLPlD bPZTV7VHzcqqPyjBVJD+0dLr8WuP2LOYk137uG1NhvWEMNgzG70+LIkbbRn75XSKtsGxq ypHHJbIUyYQtntbh9AHXVnEvg03gPBCc+GRmdyCuCXoDc3SDuJ8fCh0myxBAntw8f7LO6 T95rZLwRgSTaBRGo73Uev66YE6bMxphM3KgG/7Ej5XNv9pqY5YF2kgxnqYt+UkPihSZSC sGjCWpivjB0aVxE2h+wX9ptPCErkDnnv67ZzJuXoCBfcuTmo4BXbxwmwm1DmVqo214g== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793801626; h=DMARC-Filter:DKIM-Signature:Received:X-MC-Unique: X-Mimecast-MFC-AGG-ID:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received: X-Received:Received:Message-ID:Date:MIME-Version:User-Agent:Subject: To:Cc:References:Content-Language:From:In-Reply-To:Content-Type: Content-Transfer-Encoding; bh=C39tlu6xlshMWq2hwsMtOj8GLZZ3XOveWxHL0ZGLUl8=; b=atx7/KO+pbt1VdQ9VgaGcjmbLc3QAu/PkSHwl4u2XR6A0DabVJWMphXNeN9qhKcfF6yT GG+0P79x5mJKFHkApDcDVFMxM9OxueJEopn4dWSNMtFoFnN89V0EfjXDuaymNQeB5DsqB 72i8kvNyHfbu7mjqA5SGwrlD6FT77Ye2Oglq4D+h4ODrmtPjCT71zfptOUxTVM+xTY7JM VpS1gyyhBH4ehjobpQvDNosR176Q4SPiVlZbYCbReCLkM79kZ2vZneLiyWp6/VJHDHZaz Vj2m6RjIoqkHIOjqQXx7UZeWFg69J0iz62boG3aMFkdXEFDJ/kvVBu4Ky8BQwd2X+MQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Evfek09f; dkim=pass header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=google header.b=mmqt+Q1j; arc=none smtp.remote-ip=170.10.133.124 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5FE97606EE93 for ; Wed, 4 Nov 2026 14:13:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 5FE97606EE93 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, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Evfek09f; dkim=pass (2048-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=google header.b=mmqt+Q1j DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1793801619; 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=C39tlu6xlshMWq2hwsMtOj8GLZZ3XOveWxHL0ZGLUl8=; b=Evfek09fxHUgg+q/tq4fvPAzJbHTYMQzd/yTceZKyIUBs0IljbGCq26EijJ4nCMUFe9Hc0 PaD8M9BQs4jFqElqKWuCwwN79TekM183O0cMpZUU4djmxXz2izt+CZrx4TNwPTDZjx9Vrq 6dFbKyDbYBJ9bmYM5tce8wgGIgqhups= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-386-JFd2Q905PkSxNdC-gfLRvw-1; Wed, 04 Nov 2026 09:13:38 -0500 X-MC-Unique: JFd2Q905PkSxNdC-gfLRvw-1 X-Mimecast-MFC-AGG-ID: JFd2Q905PkSxNdC-gfLRvw_1793801617 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-4902ce85f72so638562f8f.2 for ; Wed, 04 Nov 2026 06:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1793801617; x=1794406417; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=C39tlu6xlshMWq2hwsMtOj8GLZZ3XOveWxHL0ZGLUl8=; b=mmqt+Q1jLBJ5qfdX9Trw0Nt9nJEV2+9qd3k9y4/cbx+4mJlCsizDVidStqFpBHHdmv ZOhfM1LLFqA+wFzCyrlsE4MdyHYwBVVLrXrxbtOm28xzqn+oe/G3gytRxO6ql8cGL68m lvKUBEHIyO8vhWQjF/cnG2ChO4jATV0cLpbF5Gu33rwi1Fo8B/O+RaNXru+YJm6fkgcm WYqG0RGbNz4VoszIVQKkZA9RMejtfLHb8Y7EBEApw2eC5ZTuId8BO/JwKD8dy5NO+7OV 3QdMSwAb6ZEkxZd4+BNcg+llu4p+hVBSfT+V1xUJydBLPOblgixaVyyvCPbLKSUSE+8V zesg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793801617; x=1794406417; h=content-transfer-encoding:content-type: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:content-type; bh=C39tlu6xlshMWq2hwsMtOj8GLZZ3XOveWxHL0ZGLUl8=; b=zK2U0ZPc9EZcsbcPdWomdUDoJ+VW4BkialWGXnzTj3VB16aYBazG6zQbl7ATZG+0I4 PyYurV6g1B2GjBWhUk3hE+wezzVmsFNZ8p9LZWcY67t846UWiYT345IhkwF96gan8B3N LI0FjZKKDpRnSSu6Thp2YMJ7DMrfI45K28PuijpM0xJsGv9ce5sin0m7iqKp2INFbMgy P9GIMWziFOmtQmiKo1oSmvv6BRbohZXKG1c0DPMISh9F6v5jo0/2j3cRuZL76QfltvRk lOSqsah/lK5cpxhWviYdsuUR74sH2Njdq+yZEtP1rW2vMurM4UPBLvKZFHgecUt0T8FC 0TNg== X-Forwarded-Encrypted: i=1; AKwUvBxnKwdL+owl4jxSExo0WRScfmLRNI1+J86Q12Q7gis8xmO7C2p4/Y9LWR5jFbccZcB3AqGwlAlKy/RlaJg=@vger.kernel.org X-Gm-Message-State: APuU4Z+6zJ6RZdDoFugg2ig0nzh5VDTyxy2AucICeV3MgvfVLZGJWfQe beKRFsS5MozaWGay2rJFR8PQKATE8BeSjgq+3o3mydXx8W5+VZgyidL4yRpy4BzIp2r6LywxOGP X3EZ+2XQM1tftq2HdXGUlPXmln/+D7nAIpv+CQuLrZ8xLjKUAWwE9QcT4dXS385bwsA== X-Gm-Gg: AYBFou2U4F41Bo6xZVeUwDyu8gNGWJBSPqa3yxAEcNmiMKEMQDgGup8bv5t03hu9vdE uA2ng2fG6UmJxZ+1sfotRSoknlptIO1/VtuI+pyXSqwaU3aGiQ3Rzu2oulAlTGDROeTE4igbRnz a5q11ZehT/nEgfqB4ANlZkCagmrBvmMAs+HPFEoYHNafdjAXyGAGPW7LUhXw8qsStkB3dhK3Fou 3efFSdC6vlZrW/aSgzA5rkhB/DF0aMVR8ka4Dnh50/aYnykZ03nMxXUVgV1AfQZp8095VJmo1wL PhHm/Gew0Y7ukC7v7nK0sk/J0al/OqQ48V86fYQB2UQq8VSjI2o0ZK2ilz9r3R6ooHEE/5PPtpT ZUnJFsGX1nVNfOOrz64hNgtd6Od1E7WKJknZbAKIc7fbflGsj3kJrG02QmO4U7qx59JrFsPzAvm 1AIZbWMFKQtOVMcL9cIHIwQCMkZhSWfolEO9ysvUJD67c= X-Received: by 2002:a05:6000:2313:b0:488:7d08:edbc with SMTP id ffacd0b85a97d-48e6e30ba6fmr37096687f8f.24.1793801616573; Wed, 04 Nov 2026 06:13:36 -0800 (PST) X-Received: by 2002:a05:6000:2313:b0:488:7d08:edbc with SMTP id ffacd0b85a97d-48e6e30ba6fmr37096644f8f.24.1793801616114; Wed, 04 Nov 2026 06:13:36 -0800 (PST) Received: from [192.168.88.30] (ip231-128-192-82.pool-bba.aruba.it. [82.192.128.231]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48fe7189883sm4443181f8f.0.2026.11.04.06.13.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Nov 2026 06:13:35 -0800 (PST) Message-ID: Date: Wed, 4 Nov 2026 15:13:33 +0100 X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net v2] net/mlx5: macsec: free struct mlx5_fs_id after an RCU grace period To: Tariq Toukan , Cosmin Ratiu , "joasantonio108@gmail.com" , Mark Bloch , Saeed Mahameed , "leon@kernel.org" Cc: "andrew+netdev@lunn.ch" , "edumazet@kernel.org" , "davem@davemloft.net" , "linux-rdma@vger.kernel.org" , "sd@queasysnail.net" , "linux-kernel@vger.kernel.org" , "horms@kernel.org" , "kuba@kernel.org" , Boris Pismenny , "netdev@vger.kernel.org" References: <179313582625.87630.11382992904624255106@gmail.com> <94dfe8e7-5eaf-45be-94f5-7d2e2b38fdb2@nvidia.com> Content-Language: en-US From: Paolo Abeni In-Reply-To: <94dfe8e7-5eaf-45be-94f5-7d2e2b38fdb2@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/4/26 13:49, Tariq Toukan wrote: > On 04/11/2026 13:20, Cosmin Ratiu wrote: >> On Tue, 2026-10-27 at 18:17 -0300, Joas Antonio dos Santos wrote: >>> macsec_fs_id_del() removes a struct mlx5_fs_id from its rhashtable >>> with >>> rhashtable_remove_fast() and then frees it with kfree() right away. >>> >>> The TX (SCI) table is read locklessly from the transmit path: >>> mlx5e_macsec_handle_tx_skb() and mlx5e_macsec_tx_build_eseg() call >>> mlx5_macsec_fs_get_fs_id_from_hashtable(), which does >>> rhashtable_lookup() under rcu_read_lock() and then reads >>> mlx5_fs_id->id. A transmit that looked the entry up just before it >>> was >>> removed reads freed memory. >>> >>> Before commit d4ece08f4b1d ("net/mlx5: Maintain fs_id xarray per >>> MACsec >>> device inside macsec steering") the SCI table held struct >>> mlx5e_macsec_sa directly, and mlx5e_macsec_del_txsa() freed it with >>> kfree_rcu_mightsleep(). That commit moved the table into macsec_fs.c >>> with the new struct mlx5_fs_id, but frees it with a plain kfree(). >>> >>> Add an rcu_head to struct mlx5_fs_id and free it with kfree_rcu(). >>> >>> The same issue was flagged by the Sashiko AI review as a pre-existing >>> problem while reviewing the HW-GRO for PSP series. >>> >>> Fixes: d4ece08f4b1d ("net/mlx5: Maintain fs_id xarray per MACsec >>> device inside macsec steering") >>> Link: >>> https://lore.kernel.org/all/20260909065542.4B80D1F00ACA@smtp.kernel.org/ >>> Signed-off-by: Joas Antonio dos Santos >>> Assisted-by: Yaga Agent HackerSec Claude:claude-opus-5-5 >>> --- >>> v2: >>> - Drop the macsec.c hunk: the sc_xarray_element free was already >>> fixed >>>    by ad17ad50b8dc ("net: mlx5e: Fix use-after-free of the MACsec >>> xarray >>>    entry on RX SC deletion"). (Simon) >>> - Embed an rcu_head and use kfree_rcu() instead of >>>    kvfree_rcu_mightsleep(). (Simon) >>> - Fixes: now points at the commit that introduced the kfree(). >>> - v1: >>> https://lore.kernel.org/all/179285888829.90275.17386097105525068016@gmail.com/ >>> >>> Testing: compile-tested only (arm64, W=1, CONFIG_MLX5_MACSEC=y, no >>> new >>> warnings). I do not have >>> MACsec-capable ConnectX hardware, so this was not run on a device. >>> >>>   drivers/net/ethernet/mellanox/mlx5/core/lib/macsec_fs.c | 3 ++- >>>   1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/macsec_fs.c >>> b/drivers/net/ethernet/mellanox/mlx5/core/lib/macsec_fs.c >>> --- a/drivers/net/ethernet/mellanox/mlx5/core/lib/macsec_fs.c >>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/macsec_fs.c >>> @@ -94,6 +94,7 @@ struct mlx5_fs_id { >>>       refcount_t refcnt; >>>       sci_t sci; >>>       struct rhash_head hash; >>> +    struct rcu_head rcu; >>>   }; >>> >>>   struct mlx5_macsec_device { >>> @@ -684,7 +685,7 @@ static void macsec_fs_id_del(struct list_head >>> *macsec_devices_list, u32 fs_id, >>> >>>       xa_erase(fs_id_xa, fs_id); >>> >>> -    kfree(fs_id_found); >>> +    kfree_rcu(fs_id_found, rcu); >>> >>>       if (macsec_fs_is_macsec_device_empty(macsec_device)) { >>>           list_del(&macsec_device->macsec_devices_list_entry); >>> -- >>> 2.39.5 >> >> Thank you for the fix, it looks good. >> >> Reviewed-by: Cosmin Ratiu > > Acked-by: Tariq Toukan While I have your attention, there is another mlx patch pending: https://lore.kernel.org/all/20261028145805.54595-3-fourier.thomas@gmail.com/ /P