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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <21d7e9970808041522v63bc420o26ce6397ffab3870@mail.gmail.com>
Date:	Tue, 5 Aug 2008 08:22:11 +1000
From:	"Dave Airlie" <airlied@...il.com>
To:	"Keith Packard" <keithp@...thp.com>
Cc:	"Nick Piggin" <nickpiggin@...oo.com.au>,
	"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 Tue, Aug 5, 2008 at 7:58 AM, Keith Packard <keithp@...thp.com> wrote:
> 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.

We also have a need to create in-kernel objects for things like fbcon.
If we cannot
create these without doing a major dance around the vfs then it'll be
rather ugly.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/