Skip site navigation (1)Skip section navigation (2)
Date:      14 Mar 2003 13:59:26 -0800
From:      Eric Anholt <eta@lclark.edu>
To:        freebsd-hackers@FreeBSD.org
Subject:   per-open device private data, mmap
Message-ID:  <1047679166.622.23.camel@leguin>

next in thread | raw e-mail | index | archive | help
To work properly, the DRM needs an area of memory per open of the device
which stores information on whether that fd is authenticated and also to
have a unique identifier for use in the lock.  Currently we use
drm_find_file_by_proc to get the private data and use the pid as the
unique identifier, but for example this causes problems if a fork occurs
(threaded linux programs).  This information is needed in the entry
points (open, close, ioctl). (read, write, and poll from the current
code are being stubbed out because they are unnecessary).

To do this, I'm working on following what dev/streams/streams.c does in
creating a new struct file and setting its own fileops and using the
f_data field for the pointer to the private data.  This looks pretty
good for open/close/ioctl, but there's a problem with mmap.  Currently
we use drm_find_file_by_proc in the mmap handler to see if that process
is authenticated, but there's no way from the mmap handler to get the
private data because the struct file * isn't passed in.  My initial
thought was to instead check the authentication in the DRM(mapbufs)
ioctl, where the vm_mmap is done by the X Server or clients.  The
problem with this is that a process could still do an mmap() on the fd
and avoid the authentication check.

What I'm wondering at this point is, is there any way to prevent the
mmap() from succeeding (nothing legitimate uses mmap -- it's all done
with the mapbufs ioctl), or a way to make it so from the device's mmap
handler I can detect whether mmap() or mapbufs made the mapping, or to
have different mmap handlers for those two vm_mmap callers.  What's the
best way to do this?

-- 
Eric Anholt                                eta@lclark.edu          
http://people.freebsd.org/~anholt/         anholt@FreeBSD.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1047679166.622.23.camel>