On Fri, 2003-03-14 at 13:59, Eric Anholt wrote: > 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?
Gah, and the instant I hit 'send' I realize that things /do/ use mmap and mapbufs is only for agp/sg memory. I guess it'll be okay to keep drm_find_file_by_proc and grab authentication information from there; it shouldn't be too big of an issue. The unique identifier is the big problem and the fileops trick should work for that. However, is this going to get easier some day? Are there any plans to pass the struct file down to the drivers and have a void * in there for private data? Also, we need to be blocking SIGSTOP and such things while the lock is held so that people don't hang the X Server by suspending a client while it holds the lock. Does anyone know about how to do this? -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
