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]

Message-Id: <1217814896.23437.420.camel@koto.keithp.com>
Date:	Sun, 03 Aug 2008 18:54:56 -0700
From:	Keith Packard <keithp@...thp.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	keithp@...thp.com, Eric Anholt <eric@...olt.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Export shmem_file_setup and shmem_getpage for DRM-GEM

On Fri, 2008-08-01 at 16:50 -0400, Christoph Hellwig wrote:

> Nope.  Let the userspace protion create a file in shmfs instead of
> adding fugly kernel interfaces hdiing this fact.

shmem_file_setup is already public, just not exposed to kernel modules.
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.

The other interface we use, shmem_getpage, doesn't seem supported
through existing interfaces though. I don't want to map the file into
any address space, I just need a pointer to the physical pages which
underlie it. I'll take those pages and hand them to the graphics engine.
shmem_getpage performs precisely the operation needed here.

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

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