linux-kernel - Re: [PATCH] mm: Export symbols unmapped_area() & unmapped_area

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:	Thu, 17 Mar 2016 15:46:35 +0000
From:	Olu Ogunbowale <olu.ogunbowale@...tec.com>
To:	Jerome Glisse <j.glisse@...il.com>
CC:	<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Michel Lespinasse <walken@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>,
	Hugh Dickins <hughd@...gle.com>,
	Russell King <linux@....linux.org.uk>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	"David S. Miller" <davem@...emloft.net>,
	Chris Metcalf <cmetcalf@...era.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Jackson DSouza <Jackson.DSouza@...tec.com>
Subject: Re: [PATCH] mm: Export symbols unmapped_area() &
 unmapped_area_topdown()

On Thu, Mar 17, 2016 at 03:37:16PM +0100, Jerome Glisse wrote:
> What other driver do for non-buffer region is have the userspace side
> of the device driver mmap the device driver file and use vma range you
> get from that for those non-buffer region. On cpu access you can either
> chose to fault or to return a dummy page. With that trick no need to
> change kernel.

Yes, this approach works for some designs however arbitrary VMA ranges 
for non-buffer regions is not a feature of all mobile gpu designs for 
performance, power, and area (PPA) reasons.

> Note that i do not see how you can solve the issue of your GPU having
> less bits then the cpu. For instance, lets assume that you have 46bits
> for the GPU while the CPU have 48bits. Now an application start and do
> bunch of allocation that end up above (1 << 46), then same application
> load your driver and start using some API that allow to transparently
> use previously allocated memory -> fails.

Yes, you are correct however for mobile SoC(s) though current top-end 
specifications have 4GB/8GB of installed ram so the usable SVM range is 
upper bound by this giving a fixed base hence the need for driver control
of VMA range.

> Unless you are in scheme were all allocation must go through some
> special allocator but i thought this was not the case for HSA. I know
> lower level of OpenCL allows that.

Subsets of both specifications allows for restricted implementation AFAIK,
this proposed changes are for HSA and OpenCL up to phase 2, where all SVM
allocations go via special user mode allocator.

Regards,
Olu