linux-kernel - making a COW mapping on the fly from existing vma

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-next>] [day] [month] [year] [list]

Date:	Sat, 16 Apr 2016 06:18:38 +1000
From:	Dave Airlie <airlied@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>,
	Linux Memory Management List <linux-mm@...ck.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>
Subject: making a COW mapping on the fly from existing vma

This was just a random thought process I was having last night, and
wondered if it was possible.

We have a scenario with OpenGL where certain APIs hand large amounts
of data from the user to the API and when you return from the API call
the user can then free/overwrite/do whatever they want with the data
they gave you, which pretty much means you have to straight away
process the data.

Now there have been attempts at threading the GL API, but one thing
they usually hit is they have to do a lot of unthreaded processing for
these scenarios, so I was wondering could we do some COW magic with
the data.

More than likely the data will be anonymous mappings though maybe some
filebacked, and my idea would be you'd in the main thread create a new
readonly VMA from the old pages and set the original mapping to do COW
on all of its pages. Then the thread would pick up the readonly VMA
mapping and do whatever background processing it wants while the main
thread continues happily on its way.

I'm not sure if anyone who's done glthread has thought around this, or
if the kernel APIs are in place to do something like this so I just
thought I'd throw it out there.

Dave.