From owner-freebsd-hackers Fri Mar 14 14: 5:23 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A78E37B401 for ; Fri, 14 Mar 2003 14:05:22 -0800 (PST) Received: from sunfire.lclark.edu (lclark.edu [149.175.1.5]) by mx1.FreeBSD.org (Postfix) with SMTP id 4217743FA3 for ; Fri, 14 Mar 2003 14:05:21 -0800 (PST) (envelope-from eta@lclark.edu) Received: from [149.175.30.191] ([149.175.30.191]) by sunfire.lclark.edu (SAVSMTP 3.0.1.45) with SMTP id M2003031414051919767 for ; Fri, 14 Mar 2003 14:05:19 -0800 Subject: Re: per-open device private data, mmap From: Eric Anholt To: freebsd-hackers@FreeBSD.ORG In-Reply-To: <1047679166.622.23.camel@leguin> References: <1047679166.622.23.camel@leguin> Content-Type: text/plain Organization: Message-Id: <1047679748.622.30.camel@leguin> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 14 Mar 2003 14:09:08 -0800 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 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