linux-kernel - Re: [PATCH] dma: omap-dma: add support for pause of non-cyclic transfers

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:	Fri, 7 Aug 2015 19:32:30 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Peter Hurley <peter@...leysoftware.com>
Cc:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Peter Ujfalusi <peter.ujfalusi@...com>,
	Vinod Koul <vinod.koul@...el.com>,
	Dan Williams <dan.j.williams@...el.com>,
	dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
	nsekhar@...com, linux-omap@...r.kernel.org,
	linux-serial@...r.kernel.org, john.ogness@...utronix.de,
	Greg KH <gregkh@...uxfoundation.org>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Subject: Re: [PATCH] dma: omap-dma: add support for pause of non-cyclic
 transfers

On Fri, Aug 07, 2015 at 02:21:59PM -0400, Peter Hurley wrote:
> [ + Heikki ]
> 
> On 08/07/2015 12:33 PM, Russell King - ARM Linux wrote:
> > What you have is a race condition in the code you a responsible for
> > maintaining, caused by poorly implemented code.  Fix it, rather than
> > whinging about drivers outside of your subsystem having never implemented
> > _optional_ things that you choose to merge broken code which relied upon
> > it _without_ checking that the operation succeeded.
> > 
> > It is _entirely_ your code which is wrong here.
> > 
> > I will wait for that to be fixed before acking the omap-dma change since
> > you obviously need something to test with.
> 
> I'm not sure to what you're referring here.
> 
> A WARNing fixes nothing.

The warning can wait.

> If you mean some patch, as yet unwritten, that handles the dma cases when
> dmaengine_pause() is unimplemented without data loss, ok, but please confirm
> that's what you mean.

But the regression needs fixing.

> However, at some point one must look at the api and wonder if the separation
> of concern has been drawn in the right place.

It _is_ in the right place.  dmaengine_pause() always has been permitted
to fail.  It's the responsibility of the user of this API to _check_ the
return code to find out whether it had the desired effect.  Not checking
the return code is a bug in the caller's code.

If that wasn't the case, dmaengine_pause() would have a void return type.
It doesn't.  It has an 'int' to allow failure, or to allow non-
implementation for cases where the underlying hardware can't pause the
channel without causing data loss.

What would you think is better: an API which silently loses data, or
one which refuses to stop the transfer and reports an error code back
to the caller.

You seem to be arguing for the former, and as such, there's no way I
can take you seriously.

In any case, Greg has now commented on the patch adding the feature,
basically refusing it for stable tree inclusion.  So the matter is
settled: omap-dma isn't going to get the pause feature added in stable
trees any time soon.  So a different solution now needs to be found,
which is what I've been saying all along...

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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/