lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090704.001245.208967004.anemo@mba.ocn.ne.jp>
Date:	Sat, 04 Jul 2009 00:12:45 +0900 (JST)
From:	Atsushi Nemoto <anemo@....ocn.ne.jp>
To:	nicolas.ferre@...el.com
Cc:	dan.j.williams@...el.com, maciej.sosnowski@...el.com,
	avictor.za@...il.com, linux-arm-kernel@...ts.arm.linux.org.uk,
	patrice.vilchez@...el.com, linux-kernel@...r.kernel.org,
	hskinnemoen@...el.com
Subject: Re: [PATCH 1/2 v2] dmaengine: at_hdmac: new driver for the Atmel
 AHB DMA Controller

On Wed, 01 Jul 2009 17:30:54 +0200, Nicolas Ferre <nicolas.ferre@...el.com> wrote:
> > Some of issues reported at that time could be applied on your driver
> > too.  With a quick look, the queue list management issue is a
> > candidate.  Here is an excerpt from the thread:
....
> 
> I try to replay the life of a descriptor chain in "queue" list:
> - it is queued by atc_tx_submit()
> - tasklet or atc_issue_pendig() will "advance_work" and so run
> atc_complete_all() at some point.
> - atc_complete_all() will issue an atc_dostart() on the first chain in
> queue list and move all to active_list
> - then all chains will be managed as active_list members:
>   - tasklet or atc_issue_pendig() will "advance_work"
>   - first member will be managed by chain_complete()
>   - next member will be started by dostart()
>   - and so on...
> - last chain in active_list will run complete_all() and may move again
> queued descriptors to active_list.
> 
> => non-first descriptor moved from queue to active_list will be
> proceeded by act_dostart() in atc_advance_work() function.

Oh yes.  I was wrong.  I missed act_dostart() in atc_advance_work().
Sorry for false warning.

> In this way of addressing descriptors, I try to keep descriptor chains
> as they are built by the prep_dma_memcpy function. I am not trying to
> rewrite the internal arrangement of a descriptor chain (not touching
> lli.dscr).
> It may be not optimal for the descriptor management speed but it tries
> to split problems in a kind of layered way (we build chains and then
> manage their flow in dma engine and associated lists).
> 
> I hope that there is no hole in this management as I am sure it is
> difficult to debug...
> I hope that my response is solid enough. Please do not hesitate to break
> my demonstration ;-).

Thank you for elaboration, I cannot find any hole now.  Indeed these
kind of problem is hard to debug.  Running dmatest with
threads_per_chan=N will catch such issues, hopefully :-)

---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ