From: Chris Leech [mailto:[email protected]]
Sent: Friday, March 10, 2006 6:29 PM
To:
Subject: [PATCH 2/8] [I/OAT] Driver for the Intel(R) I/OAT DMA engine
Adds a new ioatdma driver
Signed-off-by: Chris Leech <[email protected]>
---
drivers/dma/Kconfig | 9
drivers/dma/Makefile | 1
drivers/dma/ioatdma.c | 783
+++++++++++++++++++++++++++++++++++++++
drivers/dma/ioatdma.h | 127 ++++++
drivers/dma/ioatdma_hw.h | 52 +++
drivers/dma/ioatdma_io.h | 104 +++++
drivers/dma/ioatdma_registers.h | 128 ++++++
7 files changed, 1204 insertions(+), 0 deletions(-)
On Fri, Mar 10, 2006 at 06:29:46PM -0800, Leech, Christopher ([email protected]) wrote:
> From: Chris Leech [mailto:[email protected]]
> Sent: Friday, March 10, 2006 6:29 PM
> To:
> Subject: [PATCH 2/8] [I/OAT] Driver for the Intel(R) I/OAT DMA engine
>
>
> Adds a new ioatdma driver
enumerate_dma_channels() is still broken, if it can not fail add NOFAIL
gfp flag.
And you play tricky games with common_node/device_node of struct
dma_chan - one of that lists is never protected, while other is called
under RCU and other locks (btw, why does insertion use RCU and deletion
in dma_async_device_unregister() does not?).
struct ioat_dma_chan - is it somewhere freed?
--
Evgeniy Polyakov
Evgeniy Polyakov <[email protected]> wrote:
>
> On Fri, Mar 10, 2006 at 06:29:46PM -0800, Leech, Christopher ([email protected]) wrote:
> > From: Chris Leech [mailto:[email protected]]
> > Sent: Friday, March 10, 2006 6:29 PM
> > To:
> > Subject: [PATCH 2/8] [I/OAT] Driver for the Intel(R) I/OAT DMA engine
> >
> >
> > Adds a new ioatdma driver
>
> enumerate_dma_channels() is still broken, if it can not fail add NOFAIL
> gfp flag.
The __GFP_NOFAIL flag is there to mark lame-and-buggy-code which doesn't
know how to handle ENOMEM. I went through the kernel, found all the
retry-until-it-works loops and consolidated their behaviour in the page
allocator instead.
Really we should fix them all up. Adding new users of __GFP_NOFAIL
would not be good.