[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZnRV_fE8QViZG66o@matsya>
Date: Thu, 20 Jun 2024 21:47:01 +0530
From: Vinod Koul <vkoul@...nel.org>
To: Frank Li <Frank.li@....com>
Cc: Jie Hai <haijie1@...wei.com>, Paul Walmsley <paul.walmsley@...ive.com>,
Samuel Holland <samuel.holland@...ive.com>,
Li Zetao <lizetao1@...wei.com>, Guanhua Gao <guanhua.gao@....com>,
"open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" <dmaengine@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>,
"open list:FREESCALE eDMA DRIVER" <imx@...ts.linux.dev>,
"open list:SIFIVE DRIVERS" <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH v2] dmaegine: virt-dma : Fix multi-user with vchan
On 20-06-24, 10:38, Frank Li wrote:
> On Thu, Jun 20, 2024 at 10:53:53AM +0800, Jie Hai wrote:
> > List desc_allocated was introduced for the case of a transfer
> > submitted multiple times. But elegating descriptors on the list
> > causes other problems.
> >
> > For example, in the multi-thread scenario, which tasks are
> > continuously created and submitted by each thread. If one of
> > the threads calls dmaengine_terminate_all, for dirvers using
> > vchan_get_all_descriptors, all descriptors will be freed. If
> > there's another thread submitting a transfer A by
> > vchan_tx_submit, the following results may be generated:
> > 1. desc A is freeing -> visit wrong address of node prep/next.
> > 2. desc A is freed -> visit invalid address of A.
> >
> > In the above case, calltrace is generated and the system is
> > suspended. This can be tested by dmatest.
>
> What's test steps to reproduce this problem?
I think I have asked in past (dont recall if that was this or some other
one), hopefully will get to hear on this one..
PS: Good hygiene to trim replies
--
~Vinod
Powered by blists - more mailing lists