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]
Message-ID: <CAPM=9twrh8wVin=A1Zva3DD0iBmM-G8GjdSnzOD-b0=h4SVxyw@mail.gmail.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ