linux-kernel - RE: [PATCH v7 0/8] Raid: enable talitos xor offload for improving performance

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: <BCB48C05FCE8BC4D9E61E841ECBE6DB70FC695@039-SN2MPN1-011.039d.mgd.msft.net>
Date:	Thu, 30 Aug 2012 06:20:05 +0000
From:	Liu Qiang-B32616 <B32616@...escale.com>
To:	Dan Williams <djbw@...com>
CC:	"vinod.koul@...el.com" <vinod.koul@...el.com>,
	"arnd@...db.de" <arnd@...db.de>,
	"herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
	"Ira W. Snyder" <iws@...o.caltech.edu>
Subject: RE: [PATCH v7 0/8] Raid: enable talitos xor offload for improving
 performance

> -----Original Message-----
> From: Dan Williams [mailto:djbw@...com]
> Sent: Wednesday, August 29, 2012 10:53 PM
> To: Liu Qiang-B32616
> Cc: vinod.koul@...el.com; arnd@...db.de; herbert@...dor.apana.org.au;
> gregkh@...uxfoundation.org; linuxppc-dev@...ts.ozlabs.org; linux-
> kernel@...r.kernel.org; linux-crypto@...r.kernel.org; Ira W. Snyder
> Subject: Re: [PATCH v7 0/8] Raid: enable talitos xor offload for
> improving performance
> 
> On Wed, 2012-08-29 at 11:15 +0000, Liu Qiang-B32616 wrote:
> > Hi Dan,
> >
> > Ping?
> > Can you apply these patches? Thanks.
> >
> 
> I'm working my way through them.
> 
> The first thing I notice is that xor_chan->desc_lock is taken
> inconsistently.  I.e. spin_lock_irqsave() in talitos_process_pending()
> and spin_lock_bh() everywhere else.  Have you run these patches with
> lockdep?
Thanks for your reply.
LOCKDEP is enabled as you suggested, there is not any info about "inconsistent lock state" displayed.
I don't know whether it's enough.

I'm confused about the attribute of DMA_INTERRUPT, my understanding is this interface is only used to trigger an interrupt (make sure all former operations are finished before switching to other channels), but fsl-dma will trigger an interrupt by "Programmed Error". I'm wondering whether other hardware are same with fsl-dma (the interrupt is a normal interrupt, but not an error) i.e. xscale-iop?
If other hardware also trigger an interrupt by an abnormal error, maybe my patch 2/8 should be reverted because it violates the rules of this attribute.

BTW, could you please reply in the patch if you have any comments. Thanks.

> 
> --
> Dan
> 
>