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: <e9c3a7c20803111455g354741f0sff7d4fc0172dc65e@mail.gmail.com>
Date:	Tue, 11 Mar 2008 14:55:28 -0700
From:	"Dan Williams" <dan.j.williams@...el.com>
To:	"Zhang Wei" <wei.zhang@...escale.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] Add device_prep_dma_interrupt support to fsldma.c

On Mon, Mar 10, 2008 at 8:25 PM, Zhang Wei <wei.zhang@...escale.com> wrote:
> This is a bug that I assigned DMA_INTERRUPT capability to fsldma
>  but missing device_prep_dma_interrupt function. For a bug in
>  dmaengine.c the driver passed BUG_ON() checking. The patch fixes it.
>
>  Signed-off-by: Zhang Wei <wei.zhang@...escale.com>
>  ---
>   drivers/dma/fsldma.c |   27 +++++++++++++++++++++++++++
>   1 files changed, 27 insertions(+), 0 deletions(-)
>
>  diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
>  index 5dfedf3..5428f81 100644
>  --- a/drivers/dma/fsldma.c
>  +++ b/drivers/dma/fsldma.c
>  @@ -406,6 +406,32 @@ static void fsl_dma_free_chan_resources(struct dma_chan *chan)
>         dma_pool_destroy(fsl_chan->desc_pool);
>   }
>
>  +static struct dma_async_tx_descriptor *fsl_dma_prep_interrupt(
>  +                                               struct dma_chan *chan)
>  +{
>  +       struct fsl_dma_chan *fsl_chan;
>  +       struct fsl_desc_sw *new;
>  +
>  +       if (!chan)
>  +               return NULL;
>  +
>  +       fsl_chan = to_fsl_chan(chan);
>  +
>  +       new = fsl_dma_alloc_descriptor(fsl_chan);
>  +       if (!new) {
>  +               dev_err(fsl_chan->dev, "No free memory for link descriptor\n");
>  +               return NULL;
>  +       }
>  +
>  +       new->async_tx.cookie = -EBUSY;
>  +       new->async_tx.ack = 0;
>  +
>  +       /* Set End-of-link to the last link descriptor of new list*/
>  +       set_ld_eol(fsl_chan, new);

Question, is 'set_ld_eol' safe to call on descriptors that may not be
the last in the list?  For example what about the following sequence:

/* prepare two descriptors */
tx1 = fsl_dma_prep_interrupt(chan);
tx2 = fsl_dma_prep_memcpy(chan);

/* submit out of order */
tx2->tx_submit(tx2);
tx1->tx_submit(tx1);

This is only a concern if you plan to support channel switching at
some point.  For example, switching from a memcpy channel to an xor
channel.

Thanks,
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ