linux-kernel - Re: [PATCH 1/2] dmadevices: dma_sync

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]

Date:	Tue, 18 Jun 2013 18:13:28 -0700
From:	Dan Williams <djbw@...com>
To:	Jon Mason <jon.mason@...el.com>
Cc:	Vinod Koul <vinod.koul@...el.com>,
	Dave Jiang <dave.jiang@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] dmadevices: dma_sync_wait undefined

On Tue, Jun 18, 2013 at 5:46 PM, Jon Mason <jon.mason@...el.com> wrote:
> dma_sync_wait is declared regardless of whether CONFIG_DMA_ENGINE is
> enabled, but calling the function without CONFIG_DMA_ENGINE enabled
> results in the following gcc error.
> ERROR: "dma_sync_wait" [drivers/ntb/ntb.ko] undefined!
>
> To get around this, declare dma_sync_wait as an inline function if
> CONFIG_DMA_ENGINE is undefined.
>
> Signed-off-by: Jon Mason <jon.mason@...el.com>
> Acked-by: Dave Jiang <dave.jiang@...el.com>
> ---
>  include/linux/dmaengine.h |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 96d3e4a..e3652ac 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -963,8 +963,8 @@ dma_set_tx_state(struct dma_tx_state *st, dma_cookie_t last, dma_cookie_t used,
>         }
>  }
>
> -enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
>  #ifdef CONFIG_DMA_ENGINE
> +enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
>  enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
>  void dma_issue_pending_all(void);
>  struct dma_chan *__dma_request_channel(const dma_cap_mask_t *mask,
> @@ -972,6 +972,10 @@ struct dma_chan *__dma_request_channel(const dma_cap_mask_t *mask,
>  struct dma_chan *dma_request_slave_channel(struct device *dev, const char *name);
>  void dma_release_channel(struct dma_chan *chan);
>  #else
> +static inline enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie)
> +{
> +       return DMA_SUCCESS;
> +}

Seems like something we should fix, but why is this not an indication
that the code calling this is missing a "depends on DMA_ENGINE".

On second look dma_sync_wait is a use as last resort hack that
probably should not escape its internal use in dmaengine.c.  The other
escape in drivers/media/platform/timblogiw.c already looks problematic
by having a live cpu spin immediately following a sleeping wait,
obviously something event based was wanted.  What's the use case in
NTB?

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