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: <20080313195431.GA1449@lixom.net>
Date:	Thu, 13 Mar 2008 14:54:31 -0500
From:	Olof Johansson <olof@...om.net>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	"Nelson, Shannon" <shannon.nelson@...el.com>,
	linux-kernel@...r.kernel.org, pasemi-linux@...abs.org,
	linuxppc-dev@...abs.org, hskinnemoen@...el.com
Subject: Re: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip
	DMAengine

On Tue, Mar 11, 2008 at 10:04:11AM -0700, Dan Williams wrote:

> I notice that the driver does not handle callbacks in its descriptor
> cleanup path.  This could be ok if your intent is only to support the
> net_dma style polled operations, but this will not work for the
> raid-offload async_tx case.  I think the solution is for async_tx to
> ignore channels without the DMA_INTERRUPT capability.

Good point, and correct - I have mostly been testing this with the
NET_DMA offload. async_tx doesn't make use of just memcpy, does it?

Also, how is DMA_INTERRUPT supposed to work? I see there's a separate
"prep_dma_interrupt" function, but that doesn't make sense to me. Don't
you want the interrupt associated with a specific transaction instead
of added as a separate (empty) transaction?

Once I add the descriptor to the ring, I can't change it to set the
interrupt request bit on it. I suppose I could just add a dummy descriptor
to the ring, but that doesn't seem quite right either.

> > +static void pasemi_dma_clean(struct pasemi_dma_chan *chan)
> > +{
> > +       int old, new, i;
> > +       unsigned long flags;
> > +       struct pasemi_dma_desc *desc;
> > +       spin_lock_irqsave(&chan->desc_lock, flags);
> 
> Is spin_lock_bh() insufficient here?
> 
> ...that's all that jumps out at the moment.

Can't do that if it's called both from the polling as well as the IRQ
context, it'd need to hold off irqs. I.e. once I add the DMA_INTERRUPT
support it will be needed.


-Olof

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