linux-kernel - Re: [PATCH] Export shmem_file_setup and shmem

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:	Mon, 04 Aug 2008 14:58:36 -0700
From:	Keith Packard <keithp@...thp.com>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	keithp@...thp.com, Christoph Hellwig <hch@...radead.org>,
	Eric Anholt <eric@...olt.net>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Export shmem_file_setup and shmem_getpage for DRM-GEM

On Mon, 2008-08-04 at 19:02 +1000, Nick Piggin wrote:

> > I suppose we could have user space allocate the shmem file (either via
> > tmpfs or sysv ipc). tmpfs suffers from the maxfd issue, while sysv ipc
> > runs up against the SHMMAX value.
> 
> This is how I'd suggested it work as well. I think a little bit
> more effort should be spent looking at making this work.

Well, I've spent a day thinking about using existing user-space APIs to
get at shmem files. While it's nice that we've discovered a
filesystem-independent mechanism to pin file pages, we haven't found
anything similar for creating the files. In particular, what I want is:

 1) Anonymous files backed by swap
 2) Freed when the last process using them exits
 3) That never appear in the file system
 4) Do not consume a low FD (yeah, I know, rewrite the desktop)

So, what I could do is

	char	template[] = "/dev/shm/drm-XXXXXX";
	int	fd;
	fd = mkstemp (template);
	unlink (template);
	ftruncate (fd, size)
	object = drm_create_an_object_for_a_file (fd);
	close (fd);

While I haven't written any code yet, this should work and will even be
compatible with my current user-space API. I have to create a DRM object
for the file in any case, and so I don't need to hold onto the fd.
Releasing the fd also eliminates any ulimit issues. 

The drm_create_an_object_for_a_file call could return another fd. But,
note that the original shmem fd has no real value to the application in
this case.

I can imagine other cases where mapping non-shmem files would make sense
though, in particular it's fairly easy to envision mapping an image file
to the GTT and having the graphics process decode and display it without
any additional copies. I think this demonstrates the potential utility
of the general file mapping operation.

But, I'd like to have you reconsider whether it makes sense for user
space to go through the above dance to create anonymous shared objects
when the kernel already supports precisely the desired semantics and
even exposes them to the ipc/shm implementation.

We'd offer two paths in DRM -- one that used an existing file and
created an object using that as backing store, and a second one that
created anonymous objects using shmem as backing store. Transient data
would use anonymous objects while applications could directly map
arbitrary file contents as well.

-- 
keith.packard@...el.com

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)