Date: Tue, 22 Sep 2015 20:43:03 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 201611] [patch] Add devfs_get_cdevpriv_from_file(9) Message-ID: <bug-201611-8-h2W1iA4S6Q@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-201611-8@https.bugs.freebsd.org/bugzilla/> References: <bug-201611-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201611 --- Comment #7 from John Baldwin <jhb@FreeBSD.org> --- It's a bit hackish to abuse another file descriptor to pass an unrelated resource. As you noted, now you have to have extra checks in place to know if the cdevpriv you are looking at is safe for you to examine. It's not clear to me how you can really do that safely (perhaps you can check the cdevsw pointer of the fd but that's pretty gross). I think my suggestion is more in line with the existing UNIX way of doing things in that you use file descriptors as handles on resources (the same way you would use a handle on Windows for these sorts of things). You can create whatever kind of file descriptor you want and it will be self-contained as it will have its assigned file ops which will always be correct (and thus not be subject to the race you mentioned previously) when passed across a UNIX domain socket. Having a file descriptor for a VM object is a fairly simple thing to do (it is how shm_open() is implemented in FreeBSD). I (and possibly Konstantin) can help with creating helper routines if needed (e.g. something like create_memobject_file() that takes a VM object and some flags (e.g. if it's read-only or not, supports changing size or not) and creates a new file descriptor in the current process that can be returned via a member in a structure from an ioctl, etc.). It is of course possible to define other file descriptor types if you need something besides just memory. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-201611-8-h2W1iA4S6Q>