linux-kernel - Re: [PATCH 09/18] dmaengine/amba-pl08x: Schedule tasklet in case of error interrupt

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: <20110814082928.GD4986@n2100.arm.linux.org.uk>
Date:	Sun, 14 Aug 2011 09:29:28 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	"Koul, Vinod" <vinod.koul@...el.com>
Cc:	viresh kumar <viresh.kumar@...com>, Dan <dan.j.williams@...el.com>,
	viresh kumar <viresh.linux@...il.com>,
	"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
	Pratyush ANAND <pratyush.anand@...com>,
	Rajeev KUMAR <rajeev-dlh.kumar@...com>,
	Bhupesh SHARMA <bhupesh.sharma@...com>,
	Shiraz HASHIM <shiraz.hashim@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Vipin KUMAR <vipin.kumar@...com>,
	Armando VISCONTI <armando.visconti@...com>,
	Amit VIRDI <Amit.VIRDI@...com>,
	Vipul Kumar SAMAR <vipulkumar.samar@...com>,
	Deepak SIKRI <deepak.sikri@...com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 09/18] dmaengine/amba-pl08x: Schedule tasklet in case
	of error interrupt

On Thu, Aug 04, 2011 at 11:02:42AM +0530, Koul, Vinod wrote:
> On Thu, 2011-08-04 at 11:24 +0530, viresh kumar wrote:
> > On 08/04/2011 09:55 AM, Koul, Vinod wrote:
> > > Yes that's the whole point, today callback mechanism doesn't tell the
> > > _status_ of the transfer (which if we need change can be discussed as
> > > well), but to counter argue I have never been able to generate the error
> > > interrupt, are you able to do on your controller?
> > 
> > Yes, if we supply unaligned address, with access width as word, then it gives
> > error interrupt.
> > 
> > Regarding your point of updating callback for reporting errors,
> > I think it is required and should be a common issue.
> Okay till now no one has asked for it. We can add to callback arguments
> either a bool to indicate what is the transfer status or usual error
> code to also indicate what type of failure.
> I would prefer latter, if there is consensus on this, we can go thru
> with this approach, Dan your comments?

If we are concerned about unaligned addresses, then that's something which
should be checked for at prepare time, to avoid failing DMA transfers.  A
failed DMA transfer is potentially a data loss situation, one that we want
to avoid.

Consider for instance a UART driver using DMA for TX/RX.  We want to know
when we prepare the RX DMA whether the DMA engine is going to be able to
perform the requested transfer.  We don't want to know when characters
start coming in, because not only would we have to undo the DMA setup,
but we'd also need to ensure that we start reading the characters via PIO
as quickly as possible to avoid overruns.

So, what I'd say is if you receive an error interrupt, either the prep
code isn't robust enough - it's like a BUG() telling us that something
needs fixing.  So, I think printing a warning and stalling makes sense -
and hopefully we get a bug report to investigate the causes.
--
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/