Re: Working with user space file descriptor in kernel thread

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> I have created two sockets with socketpair() and one of them is put
> into kernel module through ioctl.  [...]  I am able to retrieve file
> descriptor from user mode descriptor (int user_sock) :
> file_fd = fd_getfile2(lewepe->l_proc, user_sock);

Minor terminological point: the term "file descriptor" is usually used
only to refer to an int such as is used by userland; your file_fd is
something else, probably a struct file * or a file_t * or some such.

> and consequently pointer to socket structure:
> struct socket* so = file_fd->f_undata.fd_so;

> My question is:
> Can I use such retrieved file_fd or struct socket* so in separate
> kernel thread ?

I see no reason why not - but that is not at all the same as "yes".  I
do not work with multiple threads often enough to feel confident of my
answer here.

> (Is not needed to call some kernel equivalent of dup() to duplicate
> retrieved file_fd or retrieved so to be able work in separate kernel
> thread ? Or to use copyin() on struct socket* to retrieve kernel copy of
> struct socket* ?
> Or something other ?)

As I understand it - which may be incorrect - all kernel threads exist
in the same kernel address space, so you don't need any of that.
Certainly in the kernels I've worked in you would not have anly such
issues.

Given what copyin() does, though, that in particular you do not need
for this.  copyin() is for copying from userland VM into kernel VM, and
the only part of this that even *exists* in userland is the int.

If you want to work in multiple threads at the same time, then you will
of course have locking issues.  Depending on kernel internals, you may
need to think about other locking as well; I know very little about any
of those.  In most cases, when I've been working in the kernel, I've
either just run giantlocked or depended on running uniprocessor.  (Even
uniprocessor kernels have _some_ locking issues, but they are greatly
reduced as compared to multiprocessor kernels.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B