linux-kernel - Re: [md-accel PATCH 16/19] dmaengine: driver for the iop32x, iop33x, and iop13xx raid engines

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] [day] [month] [year] [list]

Message-ID: <e9c3a7c20708301341r197fb401j17c07c733609c61a@mail.gmail.com>
Date:	Thu, 30 Aug 2007 13:41:18 -0700
From:	"Dan Williams" <dan.j.williams@...el.com>
To:	"saeed bishara" <saeed.bishara@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org,
	neilb@...e.de, "Nelson, Shannon" <shannon.nelson@...el.com>
Subject: Re: [md-accel PATCH 16/19] dmaengine: driver for the iop32x, iop33x, and iop13xx raid engines

On 8/30/07, saeed bishara <saeed.bishara@...il.com> wrote:
> you are right, I've another question regarding the function
> dma_wait_for_async_tx from async_tx.c, here is the body of the code:
>        /* poll through the dependency chain, return when tx is complete */
> 1.        do {
> 2.                 iter = tx;
> 3.                 while (iter->cookie == -EBUSY)
> 4.                         iter = iter->parent;
> 5.
> 6.                 status = dma_sync_wait(iter->chan, iter->cookie);
> 7.         } while (status == DMA_IN_PROGRESS || (iter != tx));
>
> assume that:
> - The interrupt capability is not provided.
> - Request A was sent to chan 0
> - Request B that depends on A is sent to chan 1
> - Request C that depends on B is send to chan 2.
> - Also, assume that when C is handled by async_tx_submit(), B is still
> not queued to the dmaengine (cookie equals to -EBUSY).
>
> In this case, dma_wait_for_async_tx will be called for C, now, it
> looks for me that the do while will loop forever, even when A gets
> completed. this is because the iter will point to B after line 4, thus
> the iter != tx (C) will always become true.
>
You are right.  There are no drivers in the tree that can hit this,
but it needs to be fixed up.

I'll submit the following change:

diff --git a/crypto/async_tx/async_tx.c b/crypto/async_tx/async_tx.c
index 0350071..bc18cbb 100644
--- a/crypto/async_tx/async_tx.c
+++ b/crypto/async_tx/async_tx.c
@@ -80,6 +80,7 @@ dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx)
 {
        enum dma_status status;
        struct dma_async_tx_descriptor *iter;
+       struct dma_async_tx_descriptor *parent;

        if (!tx)
                return DMA_SUCCESS;
@@ -87,8 +88,15 @@ dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx)
        /* poll through the dependency chain, return when tx is complete */
        do {
                iter = tx;
-               while (iter->cookie == -EBUSY)
-                       iter = iter->parent;
+
+               /* find the root of the unsubmitted dependency chain */
+               while (iter->cookie == -EBUSY) {
+                       parent = iter->parent;
+                       if (parent && parent->cookie == -EBUSY)
+                               iter = iter->parent;
+                       else
+                               break;
+               }

> saeed

Regards,
Dan
-
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/