From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 CF06A3BAD8B; Wed, 23 Sep 2026 14:15:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790172905; cv=none; b=Dc6zDNUFsaqn3Ewa0RJe7zFrnbGOU2YxcQoG/TTssezM4MTBmqmylOJ1jmuxE25Ij77kTt0lils0HCEbjdyB9aZtLM5AxHYDtX9yqyeqaQW0hLfxStVW4mT5EzKyKw0GdMRDk4wDzIESIFEyw45HoW5YZYMi6rUqn6qGj5TC4Q8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790172905; c=relaxed/simple; bh=tbrHrqFOBx3ueAgvn79LCHJCzrYb2vxewc2xSVzphiM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SCBk81LPsB02aM3tHCJahwbkfHwyRtvNZQEE317RgVC1C7429C2aQIrFNVOZTqFNxtfOy+eAJSd8g9Ts8rWKWHdDN8EVNVW3rc/NOmCL4HmQ8/t2DlYcTCsJklLPS3utnvxNYcIQoE5fhqtJW10IOByHx5+3D2no4SyHYASQq4A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=OGuDhcng; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="OGuDhcng" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB0F91F000FF; Wed, 23 Sep 2026 14:15:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1790172903; bh=lEKtvcK5cdCW/ENoZJc1amIFgG93EKHWMZ/5Iq5vOMU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=OGuDhcngzY270awjAXmGTXVperIH+8DW8xtk1GnDXbH562SP95FfXuqygU2Lm/To0 sF4f9PuE53DWSha/7qf2EnMhd5KWZgCR/J38X7ZDcHQJ1f8aQfaveEOvETVS/bMued sROFDehkG0OHJ1mqNIZQoREUgcoB4DWka6OhwATU= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Alex Bereza , Frank Li , Suraj Gupta , Vinod Koul , Sasha Levin Subject: [PATCH 7.2 095/438] dmaengine: xilinx_dma: Fix hardware buffer descriptor reuse order Date: Wed, 23 Sep 2026 16:01:56 +0200 Message-ID: <20260923140647.240815572@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260923140644.756254324@linuxfoundation.org> References: <20260923140644.756254324@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.2-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alex Bereza [ Upstream commit cee9c863ee68cb27d66745eb03f60e357f4f8ad2 ] xilinx_dma_alloc_chan_resources() builds a static ring of hardware buffer descriptors once and the driver uses this ring throughout the lifetime of a channel. This requires the allocation order of hardware buffer descriptors from chan->free_seg_list to stay in sync with the hardware buffer descriptor ring built at channel allocation time by returning oldest descriptors to chan->free_seg_list first. When chan->pending_list is not empty e.g. during xilinx_dma_terminate_all() the chan->free_seg_list and the order of the static hardware buffer descriptor ring get out of sync. Descriptors age in this order: pending -> active -> done. So freeing pending_list first returns the newest buffer descriptors to the chan->free_seg_list first and thus breaks the order required by the static hardware buffer descriptor ring. Then when the channel is reused, after a wrap around of the free_seg_list the DMA will find a hardware buffer descriptor with a length field that is still zeroed and stop with something like this: xilinx-vdma 86000000.dma: Channel 000000003a21d7b8 has errors 10, cdr 6de4c000 tdr 6de4c000 After this no more descriptors are completed and a consumer potentially blocks and waits forever. The only way to get out of this error state is to rebuild the static hardware buffer descriptor ring and the free_seg_list by releasing and re-acquiring the channel. Fix the order in which hardware buffer descriptors are returned to free_seg_list to ensure the mentioned requirement holds. Fixes: 23059408b6a3 ("dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario") Signed-off-by: Alex Bereza Reviewed-by: Frank Li Reviewed-by: Suraj Gupta Link: https://patch.msgid.link/20260817-fix-hw-buf-desc-reuse-v1-1-d79827a844c7@bereza.email Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin --- drivers/dma/xilinx/xilinx_dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c index 74ad80d6c5a5f..0e62e523d0ccd 100644 --- a/drivers/dma/xilinx/xilinx_dma.c +++ b/drivers/dma/xilinx/xilinx_dma.c @@ -920,9 +920,9 @@ static void xilinx_dma_free_descriptors(struct xilinx_dma_chan *chan) spin_lock_irqsave(&chan->lock, flags); - xilinx_dma_free_desc_list(chan, &chan->pending_list); xilinx_dma_free_desc_list(chan, &chan->done_list); xilinx_dma_free_desc_list(chan, &chan->active_list); + xilinx_dma_free_desc_list(chan, &chan->pending_list); spin_unlock_irqrestore(&chan->lock, flags); } -- 2.53.0