linux-kernel - Re: [PATCH] dmaengine: dma40: Add support to split up large elements

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:	Tue, 21 Dec 2010 12:02:26 -0800
From:	Dan Williams <dan.j.williams@...el.com>
To:	Linus Walleij <linus.ml.walleij@...il.com>
Cc:	Per Forlin <per.forlin@...ricsson.com>,
	linux-kernel@...r.kernel.org, Per Forlin <per.forlin@...aro.org>,
	Rabin VINCENT <rabin.vincent@...ricsson.com>
Subject: Re: [PATCH] dmaengine: dma40: Add support to split up large elements

On Tue, Dec 21, 2010 at 11:28 AM, Linus Walleij
<linus.ml.walleij@...il.com> wrote:
> 2010/12/21 Dan Williams <dan.j.williams@...el.com>:
>
>> If that is the case then the temporary fix for 2.6.37 is along the
>> lines of fixing up the clients to not submit such large requests.
>
> They don't, currently. We actually had some debate about this
> internally, because the only driver submitting something >64K-1
> was the MMCI driver (which is yet not in mainline) and yes, indeed
> the suggested solution was to amend the MMCI driver
> for the time being.
>
> I insisted on doing this fix anyway because I was under the
> impression that memcpy() is supposed to handle *any* size of
> request, is this the intention?

Yes, the api does not enforce a limit if a driver cannot handle a
given transaction size it can fail the prep.  To be useful the driver
at least needs to support PAGE_SIZE requests.

> Since its semantics are not documented as far as I can see I
> was maybe misguided in assuming that any size of buffer should
> be possible to pass in... :-(

No, you made the right call.  This is just a large change that I would
have a hard time justifying at this stage of the release process,
especially because mainline can't trigger it, even dmatest by default
cannot trigger it.  So I'll queue it up for the merge window.

If you want to send a patch that catches and reports this byte count
in case some out of tree user submits a large request that would be an
acceptable workaround for 37.  >64K support is a new feature for 38.

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