Re: Passing a socket fd from user mode to a kernel module
Re: Passing a socket fd from user mode to a kernel module
- Subject: Re: Passing a socket fd from user mode to a kernel module
- From: Terry Lambert <email@hidden>
- Date: Sat, 17 Jul 2010 15:11:00 -0700
On Jul 16, 2010, at 6:54 PM, Joe Lowe wrote:
> I have a file system kernel module that exposes a remote file system via a file system protocol over a socket. Creating/connecting the socket and performing initial authentication to the server is done in user mode. The socket is then handed to the kernel module via an ioctl to a control device.
>
> I have worked out what seem to be the correct kernel calls for this.
>
> converting the fd to a socket reference in the kernel module:
> file_socket
> sock_retain
> file_drop
>
> using the socket from a dedicated kernel thread:
> sock_send
> sock_receive
>
> cleanup:
> sock_shutdown
> sock_release
>
> The primary problem is that the sock_retain and sock_release kernel calls are private exports and are not defined in the public kernel headers. Without these calls the socket will get torn down when the user mode process exits or closes the fd.
>
> Am I missing something?
You could write most of the FS code itself in user space; this is typically what happens for e.g. WebDAVFS for FTPFS.
Alternately, you could take a reference on the proc in user space, which would block it from exiting in proc_refdrain() (someone here recently had a problem with this) until you did the proc_rele() on the reference. This would keep the socket around, and you would be, by proxy, using the processes socket.
If you can get the socket information out, however, then you don't need to do this, so long as you respect the user space process taking the socket away out from under you.
Another alternative is to have a control socket in user space, but have the connection socket set up and torn in kernel space. You could proxy the authentication conversation to user space by reading from the control and writing to the connection, and vice versa, until the conversation was complete, allowing the user space process to exit at that time (and tearing down the control socket).
In general, resource tracking is scoped on a per-process basis. While under the covers, it's possible that the implementation details are that the reference scoping is system wide, you generally cannot depend so heavily on the implementation details not changing that you would be able to take something like a socket from process to kernel reference scope, and be assured that this would be sustainable in future releases.
-- Terry _______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden