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 6AD84396D10 for ; Thu, 16 Apr 2026 11:00:28 +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=1776337229; cv=none; b=RL9kzbkRG/LqaShcvgEvZB1VATEi6XrseXDLut8aWQHtAOcPib0Z2cDBQoNiizzDCbN/xNzUDlOG46aQxSwXbmm0jXc7UpiYDhJAJTKEQoSeXj7D8g6F+mRf6CTeqFffwpXYTiMxXPxYJ5thuJt9zBv3bNt4JuZ7DHoTKS7aIJw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776337229; c=relaxed/simple; bh=uvgls/AWo0ZB2eaUcYzcRFg7uIPxau3CKDqtTkrxZGU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=tUT0NI3hZexxQGS3tWEjvDN3+5ZBAmeNpg0Ely9CeYhGkomAcJqrj/K4r0PcxfS3b32dHFJlCkXkts4Hc+mjJFKeXG2wt19+ugJ0+evPE8OI+h33vvcNb3Lx9dkV1gjuJ3BZL+k+8O/ZV5TR6X/Y1Rfb6N74dEPj3+SLrAtATMY= 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=aQnboQpr; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Ux7x48BZ; 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="aQnboQpr"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Ux7x48BZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776337227; 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=immR39HEnQITIkEYEn8WgdgXgd+QOcertjMezwfG0S0=; b=aQnboQprpKuFAwtXajdg4LKozsGu8B3fhyKS8eExHHa7d45DIsvTOYrsuB1Y7MkokOGxTG GS8uSGwgVhzIXbAPm3quRj5bt/IrIwYJVmhcL7YFz2N5oOL4QcFd2m1sxEOgDhve4CDAAB j+L7jiegiQAT6Xj4mYhbE3Ot5X+CXCA= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-271-YaGd_uUjMlqD3kfVurOsqA-1; Thu, 16 Apr 2026 07:00:26 -0400 X-MC-Unique: YaGd_uUjMlqD3kfVurOsqA-1 X-Mimecast-MFC-AGG-ID: YaGd_uUjMlqD3kfVurOsqA_1776337225 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4837bfcfe0dso71629785e9.1 for ; Thu, 16 Apr 2026 04:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1776337225; x=1776942025; darn=vger.kernel.org; h=content-transfer-encoding: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; bh=immR39HEnQITIkEYEn8WgdgXgd+QOcertjMezwfG0S0=; b=Ux7x48BZTWIjqrRtHBsxTAqmskx8Q/yX1Iu8qtii+WrTmQWV3Q4Oj5xaZbWWXhkPQV 5pzAjkelCEzpqgKnoSl2d7wQl0wNCSRtzsUiC7QwBkC1HfXxl70+OOfvlaTP6+zsRwxg 7YRGrO3Vuzg4JX7jd4UpMiMODPegom7b8avFT6BXf02nK/jzTFEhZeM2eMB4rxHF8Ch4 9bOj23SrNkwKBCbb8kz5SopNG1IyHWPUpBWdvllIVpLBHiNVhr47Tp0QFveYM0GjWmdQ mZ6jRUjjIvXxr+vqBRhETLOi3mHxW5LRZtNGWNxppH5YksA6QOjdEDnTVNbIbyyg0JEp aF3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776337225; x=1776942025; 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=immR39HEnQITIkEYEn8WgdgXgd+QOcertjMezwfG0S0=; b=RQscGns3nVBxj8Ocp8av+C9Y43+B59jsm9PGaBqOnJaaTgkTWI8TwkT91JUdlu5M88 HcK2kWKhmlVrgXpc8cK8rWA4cJHPcwAEJxfxfPoinT/1j9N1+3gCBMAUO1RXQqfZmRtV 8LG2r6PlFuLP2HwCk/5VvOB9kICzIp0kuZ4GAkBaXGPykpfGSyhRuFUfYXGA1oSUiH4K TTbWChosE9ma5FDZ8wLQtG/xOqsWbh0UvpQFgOEZwojiPm0K2FLQ7kGq9ZRIHN+sjaKQ Cw5oYft386wmLg//4FoZWBhv7GaRQHkA0K1MED5CaqIgGAxtcLWwe4/6pTXykby3WliR h2uA== X-Forwarded-Encrypted: i=1; AFNElJ//8pBerf6hQCCeJ+PAndKccYrkGsGOd8ARSjtFp8O7WhqgoIMYSVsPCxVGg8LZIZ9wyLM78u+rubUqesw=@vger.kernel.org X-Gm-Message-State: AOJu0Yzv2XCNSv143MEFry8p4kYAUH0SFY1q9FfYoLX5ntgvKzrI464Y +zjyxwp3BYC1GG0gzQIkH1dRxsFP/iLfJ2ynBR7zn3FIC4eJ25YvPqBHF5gQHN1amv3wVQDa5jE dZN5PzAqDNPI3rgyvVT6g2Xbmtk0dZ0nY132uhdgpMgAJN3HP4O0hTj5eFBU9mSsN7w== X-Gm-Gg: AeBDies+w9K8RfU3xE74EqIdna38dZBm1NSV0nKuvZEirmIwdWBDLqujAnYXaX6C9K2 sK1EEPCMApzyCOj2XZipp+EyRjjORnqpWv0Y3jwTm2VFYmfshITVoWXJVn3xMSPHxF38pU4lwd6 JGW+WZkDyE2/aVxOJgEga8hkJGHQOQxzj0xzBPNAwwpqKusXq7j7UFWLhMhgoy/9e0nRsrfP3CG A0yjF67/BjIk1lN9FDDETtVF80t2vhkdYAVgv7iJABlgL8nYo95V56iEt2VUMx18zBvnN1L0Z3K 6FbbkEaxOeWM4+YNG0/wNCjv1tWzSVppy9MxBM0Ly57bAAfA3dp9n0Bdm3iQlb6kZkpAWU/6h0m i072HxII8kjBI+LAhfw8QVY37JNUxDz2rDzYZPQ0WZNrY0Hj758DDra8lHnJrVQwAp+I= X-Received: by 2002:a05:600c:871a:b0:488:c683:be89 with SMTP id 5b1f17b1804b1-488d67f0b8fmr367583205e9.9.1776337225039; Thu, 16 Apr 2026 04:00:25 -0700 (PDT) X-Received: by 2002:a05:600c:871a:b0:488:c683:be89 with SMTP id 5b1f17b1804b1-488d67f0b8fmr367581755e9.9.1776337223973; Thu, 16 Apr 2026 04:00:23 -0700 (PDT) Received: from [192.168.88.32] ([150.228.93.122]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488f5821115sm46483195e9.8.2026.04.16.04.00.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Apr 2026 04:00:23 -0700 (PDT) Message-ID: <77503dd8-d882-4079-9dc8-f0cab89c0a7b@redhat.com> Date: Thu, 16 Apr 2026 13:00:21 +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 net V2 1/3] net/mlx5: SD: Serialize init/cleanup To: Tariq Toukan , Eric Dumazet , Jakub Kicinski , Andrew Lunn , "David S. Miller" Cc: Saeed Mahameed , Mark Bloch , Leon Romanovsky , Shay Drory , Simon Horman , Kees Cook , Parav Pandit , Patrisious Haddad , Gal Pressman , netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, Dragos Tatulea References: <20260413105323.186411-1-tariqt@nvidia.com> <20260413105323.186411-2-tariqt@nvidia.com> Content-Language: en-US From: Paolo Abeni In-Reply-To: <20260413105323.186411-2-tariqt@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/13/26 12:53 PM, Tariq Toukan wrote: > @@ -491,23 +508,35 @@ void mlx5_sd_cleanup(struct mlx5_core_dev *dev) > { > struct mlx5_sd *sd = mlx5_get_sd(dev); > struct mlx5_core_dev *primary, *pos; > + struct mlx5_sd *primary_sd = NULL; > int i; > > if (!sd) > return; > > + mlx5_devcom_comp_lock(sd->devcom); > if (!mlx5_devcom_comp_is_ready(sd->devcom)) > - goto out; > + goto out_unlock; > > primary = mlx5_sd_get_primary(dev); > + primary_sd = mlx5_get_sd(primary); > + > + if (primary_sd->state != MLX5_SD_STATE_UP) > + goto out_unlock; > + > mlx5_sd_for_each_secondary(i, primary, pos) > sd_cmd_unset_secondary(pos); > sd_cmd_unset_primary(primary); > debugfs_remove_recursive(sd->dfs); > > sd_info(primary, "group id %#x, uncombined\n", sd->group_id); > -out: > + primary_sd->state = MLX5_SD_STATE_DESTROYING; > +out_unlock: > + mlx5_devcom_comp_unlock(sd->devcom); > sd_unregister(dev); > + if (primary_sd) > + /* devcom isn't ready, reset the state */ > + primary_sd->state = MLX5_SD_STATE_DOWN; Sashiko says: --- Since primary_sd is only populated if devcom is ready, this condition will never trigger when devcom isn't ready, contrary to the comment. Instead, it triggers on the normal path after devcom is ready, immediately overwriting MLX5_SD_STATE_DESTROYING with MLX5_SD_STATE_DOWN outside the lock. Could this allow concurrent mlx5_sd_init() calls to see the down state and attempt hardware re-initialization while the group is still being torn down? Also, can this race and cause a use-after-free regression? During a concurrent Socket-Direct group teardown, the primary PF and secondary PF can execute mlx5_sd_cleanup() in parallel. If the primary PF completes its cleanup first, it will call sd_cleanup(primary) which calls kfree() on the sd structure, freeing the primary_sd memory. If the secondary PF is preempted just after releasing the devcom lock, it will resume, evaluate its local non-NULL primary_sd pointer, and locklessly write to primary_sd->state. Does this dereference the freed memory of the primary PF? ---