Hi Dan, With https://patchwork.kernel.org/patch/3863711/ applied, the issue disappeared.
Thanks, Xuelin Shi -----Original Message----- From: dan.j.willi...@gmail.com [mailto:dan.j.willi...@gmail.com] On Behalf Of Dan Williams Sent: 2014年4月10日 12:02 To: Shi Xuelin-B29237 Cc: Koul, Vinod; dmaeng...@vger.kernel.org; linuxppc-dev Subject: Re: [PATCH v2] fix wrong usage of dmaengine_unmap_put in async_xxx On Thu, Mar 20, 2014 at 1:16 AM, <xuelin....@freescale.com> wrote: > From: Xuelin Shi <xuelin....@freescale.com> > > dmaengine_unmap_put does below two things: > a) unmap pages for srcs and dests > b) free unmap struct > > The unmap struct data is generated but only initialized while other > some dma contions are met, like dma alignment etc. > If the unmap data is not initialized, call dmaengine_unmap_put will > unmap some random data in unmap->addr[...] Actually, this should be fixed by your other patch: https://patchwork.kernel.org/patch/3863711/ Because the to_cnt, from_cnt, are properly initialized to zero. The only issue was that the unmap pool was not specified. Can you verify that the problem still exists with that patch applied? I'll mark it for -stable. > Also call dmaengine_get_unmap_data immediatally after generating tx is > not correct. Maybe the tx has not been finished by DMA hardware yet > but the srcs and dests are dma unmapped. I disagree. It is correct because the unmap data is reference counted. If the DMA hardware is still using the buffers then it must hold a reference on the unmap data. The dmaengine_put_unmap_data() instances your are removing are the ones that drop the initial reference count set in dmaengine_get_unmap_data(). _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
