kernel_thread() causes segfault

kernel_thread() causes segfault

[Shashank Khasare]

Hi,

I want to write a new syscall in which caller process would create kernel
thread which shares the process address space, file descriptor table,
parent pid etc.
The new kernel thread would be clone of current thread but it would never
execute any userspace code.

The kernel_thread() function with following arguments would be ideal to
achieve this task:
kernel_thread(some_function, some_args, CLONE_FS | CLONE_FILES |
CLONE_PARENT)

In latest kernels (v3.1x), this function causes segmentation fault in the
user process.
However same code works perfectly in older kernels (v2.6).

According to this link
<https://groups.google.com/forum/#%21searchin/linux.kernel/kernel_thread%28%29/linux.kernel/LPWuY2DMMuA/L2hv1x23YqQJ>,
and this code
<http://lxr.free-electrons.com/source/arch/x86/kernel/process_64.c?v=3.16#L177>
(call chain: kernel_thread -> do_fork -> copy_process -> copy_thread), it
looks like only the kernel thread can spawn another kernel thread. (I tried
to set PF_KTHREAD flag in current->flags before calling kernel_thread
function, but the system crashed.)

Is there any clean way of creating kernel thread that shares process
address space, file descriptor table, parent pid etc?


Thanks,
Shashank Khasare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160321/9a074fde/attachment.html 

kernel_thread() causes segfault

[Valdis.Kletnieks at vt.edu]

On Tue, 22 Mar 2016 16:51:44 +0530, Shashank Khasare said:

> These two threads share same address space, file descriptor tables, parent
> pid etc.
> Whenever user thread wants to make syscall, it would post the information
> about syscall number & arguments
> to syscall in common shared page. User thread would then wait till the
> results are posted on shared page.
> The kernel thread reads the syscall arguments from shared page and writes
> the results to shared page.
> User thread consumes the results and continues execution.
> Since the kernel thread and user thread can be scheduled on different cpu
> cores, and user thread is ideally never executing
> kernel code and vice versa, one can expect gain in instruction per cycle
> for application, since the cache pollution is reduced to
> some extent*.*

However, you're almost certainly going to lose those gained cycles in
the latency waiting for the kernel side to notice a newly posted syscall
(what are you going to do, poll?  How well does that work if you have
several hundred or thousands of processes running?) - and then you have
to have userspace wake up properly (hint - *it* can't spin and poll, because
if it's running, kernelspace can't be running to service its request).

Also, if the kernel and user threads are on different cores, you have the
potential of cache line ping-ponging....

There's a *reason* why a lot of academic papers don't make it into
production code....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160322/bc9d8e73/attachment.bin 

kernel_thread() causes segfault

[Manoj Nayak]

Process has files_struct and fs_struct in task_struct.

Two thread's  task_struct can point to same files_struct and fs_struct if
we do the changes through a new system call.

Please check the following URL.

http://lxr.free-electrons.com/source/kernel/fork.c#L993

Regards
Manoj Nayak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160322/687ef0ce/attachment.html 

kernel_thread() causes segfault

[Shashank Khasare]

I am trying to implement ideas mentioned in the following OSDI paper:
L. Soares and M. Stumm. FlexSC: flexible system call scheduling with
exception-less system calls. In Proc. OSDI, 2010.
http://www.cs.cmu.edu/~chensm/Big_Data_reading_group/papers/flexsc-osdi10.pdf

The paper propose a new mechanism for applications to make syscall.
The brief idea is to have two types of threads 1) User thread 2) Kernel
Thread.
These two threads share same address space, file descriptor tables, parent
pid etc.
Whenever user thread wants to make syscall, it would post the information
about syscall number & arguments
to syscall in common shared page. User thread would then wait till the
results are posted on shared page.
The kernel thread reads the syscall arguments from shared page and writes
the results to shared page.
User thread consumes the results and continues execution.
Since the kernel thread and user thread can be scheduled on different cpu
cores, and user thread is ideally never executing
kernel code and vice versa, one can expect gain in instruction per cycle
for application, since the cache pollution is reduced to
some extent*.*

So to implement this mechanism, it is important for the user and kernel
thread to share address space, fd tables etc.
kernel_thread() works fine with older kernels to achieve this task, but is
no longer an option.

Is there of any mechanism for sharing fd tables as well?
Please let me know.

Thanks a lot,
Shashank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160322/1bdf0577/attachment.html 

kernel_thread() causes segfault

[Manoj Nayak]

What is the usecase here ? Do we need to share the entire process address
space to a kernel thread ?

If address space sharing between userspace thread and kernel thread space
is the whole idea then we can mmap process address space and do
get_user_pages() to allocate physcial page and pin it.
kernel thread can do kmap() and  kumap() to use the pages from process
address space.

http://lxr.free-electrons.com/source/fs/aio.c?v=3.8#L99

Regards
Manoj Nayak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160322/e025e14b/attachment.html