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, 14 Jun 2011 18:03:00 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"Michal Nazarewicz" <mina86@...a86.com>
Cc:	"Marek Szyprowski" <m.szyprowski@...sung.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-media@...r.kernel.org, linux-mm@...ck.org,
	linaro-mm-sig@...ts.linaro.org,
	"'Kyungmin Park'" <kyungmin.park@...sung.com>,
	"'Andrew Morton'" <akpm@...ux-foundation.org>,
	"'KAMEZAWA Hiroyuki'" <kamezawa.hiroyu@...fujitsu.com>,
	"'Ankita Garg'" <ankita@...ibm.com>,
	"'Daniel Walker'" <dwalker@...eaurora.org>,
	"'Mel Gorman'" <mel@....ul.ie>,
	"'Jesse Barker'" <jesse.barker@...aro.org>
Subject: Re: [PATCH 08/10] mm: cma: Contiguous Memory Allocator added

On Tuesday 14 June 2011, Michal Nazarewicz wrote:
> On Tue, 14 Jun 2011 15:49:29 +0200, Arnd Bergmann <arnd@...db.de> wrote:
> > Please explain the exact requirements that lead you to defining multiple
> > contexts.
> 
> Some devices may have access only to some banks of memory.  Some devices
> may use different banks of memory for different purposes.

For all I know, that is something that is only true for a few very special
Samsung devices, and is completely unrelated of the need for contiguous
allocations, so this approach becomes pointless as soon as the next
generation of that chip grows an IOMMU, where we don't handle the special
bank attributes. Also, the way I understood the situation for the Samsung
SoC during the Budapest discussion, it's only a performance hack, not a
functional requirement, unless you count '1080p playback' as a functional
requirement.

Supporting contiguous allocation is a very useful goal and many people want
this, but supporting a crazy one-off hardware design with lots of generic
infrastructure is going a bit too far. If you can't be more specific than
'some devices may need this', I would suggest going forward without having
multiple regions:

* Remove the registration of specific addresses from the initial patch
  set (but keep the patch).
* Add a heuristic plus command-line override to automatically come up
  with a reasonable location+size for *one* CMA area in the system.
* Ship the patch to add support for multiple CMA areas with the BSP
  for the boards that need it (if any).
* Wait for someone on a non-Samsung SoC to run into the same problem,
  then have /them/ get the final patch in.

Even if you think you can convince enough people that having support
for distinct predefined regions is a good idea, I would recommend
splitting that out of the initial merge so we can have that discussion
separately from the other issues.

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