From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D2FE72417DE; Mon, 11 May 2026 10:02:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778493732; cv=none; b=J3YBkBYrSQVE+XNO3JZmmh/54rggBZjZ3N7SqDk7t1zxzKx/pTVY1xSS/mwzj5X/0iBBT8RlIM0dWIVAhn1A4xVMT8S/9urqkF5kk85nObypd7gHxGcHbXcEEQBVjnRJa2qZICBeVaE1+Ehwzc3cl+HIA9NL8g+Od6VTQ76boaA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778493732; c=relaxed/simple; bh=3m5fpeO8TZCjV1O4lR8wYNwPEzRrH6JL6Z/PhnuTDv8=; h=From:To:Cc:In-Reply-To:References:Subject:Message-Id:Date: MIME-Version:Content-Type; b=JEEFB6WAJv1cRaqcwd3MCQKTfkOb9LAMgCEVTIizk18maA9Qu56BRqcz8dV14z6xWtr2ezhSNODI6Q6F4341ejaVEsOjLijQYGQvoxThzbEhg1/SKr9GO1rhuUC1CD4IiT5sYRTUc1mIRcTaBuRV/pfkBfmE+7mYwLDRJfXZmeI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AEhPIth/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AEhPIth/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3082CC2BCC9; Mon, 11 May 2026 10:02:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778493732; bh=3m5fpeO8TZCjV1O4lR8wYNwPEzRrH6JL6Z/PhnuTDv8=; h=From:To:Cc:In-Reply-To:References:Subject:Date:From; b=AEhPIth/fPR1HIHQ5YwRJh4WOqht86selW3buOMNfnp9vBGY1xE4xVIdYGm7M7prs hJJrYDDeZOVXTdKfT1TUc3xIIO6fG/7yPzxm9lFgM9LwDbckBWUb+19h51WVkJrB68 zoFE3Z7FqayjOqWzBDxtRCaQWCetfP5RfgjKEIyVyTwWkuxUuxWOlLhdl2h/k4Ln+S JY51Opzwz/TTJF7piiLjmgredWmOSSr9x+II9fofAic6qDLH+bGaH2zt5ZCfwthY01 VbVhdQuLUOaK8pglQGVQ4pkalxxOq2k4w2+7Csl9i6xeJQznBR8jUiIasRPlnBL6cr SY5iIz2QGtz7w== From: Leon Romanovsky To: jgg@ziepe.ca, Prathamesh Deshpande Cc: michaelgur@nvidia.com, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20260426132356.22264-1-prathameshdeshpande7@gmail.com> References: <20260426132356.22264-1-prathameshdeshpande7@gmail.com> Subject: Re: [PATCH v2] RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure Message-Id: <177849372983.2263318.7427571852742031816.b4-ty@kernel.org> Date: Mon, 11 May 2026 06:02:09 -0400 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: b4 0.15-dev-18f8f On Sun, 26 Apr 2026 14:23:41 +0100, Prathamesh Deshpande wrote: > mlx5r_umr_update_xlt() allocates and DMA maps an XLT buffer with > mlx5r_umr_create_xlt(). The buffer is released by the common cleanup path > through mlx5r_umr_unmap_free_xlt(). > > After mlx5_odp_populate_xlt() became fallible, its error path returned > directly and skipped that cleanup. This leaks the XLT DMA mapping and > buffer. If the emergency XLT page was used, it also leaves > xlt_emergency_page_mutex locked. > > [...] Applied, thanks! [1/1] RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure https://git.kernel.org/rdma/rdma/c/40d05a2e003357 Best regards, -- Leon Romanovsky