From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C71082E7F0A; Mon, 8 Jun 2026 10:14:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780913645; cv=none; b=AHDNxDXmcTzaqahXcjBOSAVlaiSqeWEDglFeduktchET6CZmhU1f3wm1JSVyBB9WwJnE1ZgTW2P4Ffq/xLJ9FYvqi7GS0Z9YUfgmEL78ViSvRrDqgHFJEGR7ZMfcUAxNLkMsx3YyrN6e67sgCE8TfVe244DgVkrnz7E+nOwQyQI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780913645; c=relaxed/simple; bh=14PKb+pOpqvay+ly6H71FW6oy9lPH/lGH1WLwWO4SAw=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=Vs7jJISirWxMSy433+d2gg/kA541RO7miz8rAKEzZg4ED864hD96SE1Qeur4r+2F/YBCNpweRuZILhD2d/Cr+ppbV+oUF38VwY+YJtxneAEBjjE8IEg45GL1mWMYaLrVmxTb6FJHc78vS9GOaeWvgam/RhS23EzbtWs9pIuHKSw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=c6i2/Eb9; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="c6i2/Eb9" Received: by linux.microsoft.com (Postfix, from userid 1231) id C646520B7166; Mon, 8 Jun 2026 03:13:47 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com C646520B7166 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1780913627; bh=siiZgZU3VC/xhvfvYivTsPp+vnhZSEEwa81CmEUhSyM=; h=From:To:Subject:Date:From; b=c6i2/Eb9TTdyx3xnYdUkhzxMXW5IVpgL5xRWLwBqMtEcHv6UG6FmVDlh93fRaSgs7 wCrN5FjSC93akX0IDNNNsUjR1q8AXJUi/Ss7H0K8RoJq1YiyZMaSl8RgEfzR05FHfV 4on5iMvp0huwCu51z4bnZuofwXDokC4rff0O1yGE= From: Aditya Garg To: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, longli@microsoft.com, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, shradhagupta@linux.microsoft.com, dipayanroy@linux.microsoft.com, ernis@linux.microsoft.com, kees@kernel.org, shacharr@microsoft.com, stephen@networkplumber.org, gargaditya@microsoft.com, gargaditya@linux.microsoft.com, ssengar@linux.microsoft.com, linux-hyperv@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH net v2 0/2] net: mana: fix error-path issues in queue setup Date: Mon, 8 Jun 2026 03:13:39 -0700 Message-ID: <20260608101345.2267320-1-gargaditya@linux.microsoft.com> X-Mailer: git-send-email 2.43.7 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Two error-path fixes in MANA queue setup, both surfaced during Sashiko AI review of a recently upstreamed patch series. Patch 1 initializes queue->id to INVALID_QUEUE_ID in mana_gd_create_mana_wq_cq() so that a CQ creation failure before the firmware id is assigned does not NULL gc->cq_table[0] and silently break whichever real CQ owns that slot. This mirrors the existing pattern in mana_gd_create_eq(). Patch 2 guards mana_destroy_txq()'s call to mana_destroy_wq_obj() with an INVALID_MANA_HANDLE check, mirroring mana_destroy_rxq(). Without it, TX setup failures lead to a firmware-rejected destroy of (u64)-1 and a spurious error in dmesg. Changes in v2: - Rebased onto net. Aditya Garg (2): net: mana: initialize gdma queue id to INVALID_QUEUE_ID net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check drivers/net/ethernet/microsoft/mana/gdma_main.c | 2 ++ drivers/net/ethernet/microsoft/mana/mana_en.c | 3 ++- 2 files changed, 4 insertions(+), 1 deletion(-) -- 2.43.0