[uml-devel] Segmentation fault with kernel thread in UML-2.6.7 TT mode

[uml-devel] Segmentation fault with kernel thread in UML-2.6.7 TT mode

[Alex LIU]

Hi,all:

I just modified the kernel thread function in UML 2.6.7 tt mode. I want the kernel thread go to the user space after finished the kernel function rather than exit. It's just like a system call return or a return from fork...

But now the problem is that there will be segmentation fault just before the kernel thread go to the user space. After tracing I found when the segmentation fault occur, in handle_page_fault function, (!(vma->vm_flags & VM_GROWSDOWN)) is true and the err is -14. What's the meaning of such value?

I modified the new_thread_handler function with regarding to finish_fork_handler function. (also add pt_regs as a parameter of the kernel thread function)
My modified new_thread_handler function is following:
-------------------------------------------------------
static void new_thread_handler(int sig)
{
        unsigned long disable;
        int (*fn)(void *);
        void *arg;
        struct pt_regs *regs;
                                                                                                                             
        fn = current->thread.request.u.thread.proc;
        arg = current->thread.request.u.thread.arg;
                                                                                                                             
        regs = &current->thread.regs;
                                                                                                                             
        UPT_SC(&current->thread.regs.regs) = (void *) (&sig + 1);
        disable = (1 << (SIGVTALRM - 1)) | (1 << (SIGALRM - 1)) |
                (1 << (SIGIO - 1)) | (1 << (SIGPROF - 1));
        SC_SIGMASK(UPT_SC(&current->thread.regs.regs)) &= ~disable;                                                                                                                             
                                                                       
        suspend_new_thread(current->thread.mode.tt.switch_pipe[0]);
                                                                                                                             
        force_flush_all();
        if(current->thread.prev_sched != NULL)
                schedule_tail(current->thread.prev_sched);
        current->thread.prev_sched = NULL;
                                                                                                                             
        init_new_thread_signals(1);
        enable_timer();
                                                                                                                             
        change_sig(SIGVTALRM, 1);
        local_irq_enable();
        if(current->mm != current->parent->mm)
                protect_memory(uml_reserved, high_physmem - uml_reserved, 1,
                               1, 0, 1);
        task_protections((unsigned long) current_thread);
                                                                                                                             
                                                                                                                             
        free_page(current->thread.temp_stack);
        set_cmdline("(bproc kernel thread)");
                                                                                                                             
        change_sig(SIGUSR1, 1);
        change_sig(SIGPROF, 1);
                                                                                                                             
        if(!run_kernel_thread(fn, regs, arg, &current->thread.exec_buf)){
                local_irq_disable();
                change_sig(SIGUSR1, 0);
                set_user_mode(current);
        }
                                                                                                                             
        /* XXX No set_user_mode here because a newly execed process will
         * immediately segfault on its non-existent IP, coming straight back
         * to the signal handler, which will call set_user_mode on its way
         * out.  This should probably change since it's confusing.
         */
}
----------------------------------------------
For convenience,I also attached the original UML functions:

void finish_fork_handler(int sig)
{
        UPT_SC(&current->thread.regs.regs) = (void *) (&sig + 1);
        suspend_new_thread(current->thread.mode.tt.switch_pipe[0]);
                                                                                                                             
        force_flush_all();
        if(current->thread.prev_sched != NULL)
                schedule_tail(current->thread.prev_sched);
        current->thread.prev_sched = NULL;
                                                                                                                             
        enable_timer();
        change_sig(SIGVTALRM, 1);
        local_irq_enable();
        if(current->mm != current->parent->mm)
                protect_memory(uml_reserved, high_physmem - uml_reserved, 1,
                               1, 0, 1);
        task_protections((unsigned long) current_thread);
                                                                                                                             
        free_page(current->thread.temp_stack);
        local_irq_disable();
        change_sig(SIGUSR1, 0);
        set_user_mode(current);
}

static void new_thread_handler(int sig)
{
        unsigned long disable;
        int (*fn)(void *);
        void *arg;
                                                                                                                             
        fn = current->thread.request.u.thread.proc;
        arg = current->thread.request.u.thread.arg;
                                                                                                                             
        UPT_SC(&current->thread.regs.regs) = (void *) (&sig + 1);
        disable = (1 << (SIGVTALRM - 1)) | (1 << (SIGALRM - 1)) |
                (1 << (SIGIO - 1)) | (1 << (SIGPROF - 1));
        SC_SIGMASK(UPT_SC(&current->thread.regs.regs)) &= ~disable;
                                                                                                                             
        suspend_new_thread(current->thread.mode.tt.switch_pipe[0]);
                                                                                                                             
        force_flush_all();
        if(current->thread.prev_sched != NULL)
                schedule_tail(current->thread.prev_sched);
        current->thread.prev_sched = NULL;
                                                                                                                             
        init_new_thread_signals(1);
        enable_timer();
        free_page(current->thread.temp_stack);
        set_cmdline("(kernel thread)");
                                                                                                                             
        change_sig(SIGUSR1, 1);
        change_sig(SIGVTALRM, 1);
        change_sig(SIGPROF, 1);
        local_irq_enable();
        if(!run_kernel_thread(fn, arg, &current->thread.exec_buf))
                do_exit(0);
                                                                                                                             
        /* XXX No set_user_mode here because a newly execed process will
         * immediately segfault on its non-existent IP, coming straight back
         * to the signal handler, which will call set_user_mode on its way
         * out.  This should probably change since it's confusing.
         */
}
------------------------------------------------
I also modified the copy_thread_tt function and create the sigcontext for the kernel thread just like fork:
------------------------------------------------
         sc_to_sc(UPT_SC(&p->thread.regs.regs),
                UPT_SC(&current->thread.regs.regs));
         SC_SET_SYSCALL_RETURN(UPT_SC(&p->thread.regs.regs), 0);
         if(sp != 0) SC_SP(UPT_SC(&p->thread.regs.regs)) = sp;
------------------------------------------------

Any ideas? 
Thanks a lot!

Alex



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op�k
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Segmentation fault with kernel thread in UML-2.6.7 TT mode

[Blaisorblade]

On Friday 15 July 2005 11:59, Alex LIU wrote:
> Hi,all:

> I just modified the kernel thread function in UML 2.6.7 tt mode. I want the
> kernel thread go to the user space after finished the kernel function
> rather than exit. It's just like a system call return or a return from
> fork...
Hmm, but where's the caller to return? In most cases it won't exist.

I don't understand what's your purpose, and the behaviour you'd want to 
reproduce. Sorry, but *which* userspace should it go to? What you're 
modifying is the execution path of kernel_thread. Now, let's take a call to 
kernel_thread from the initial thread, before init is executed, or a similar 
situation (ksoftirqd and such things must surely be kernel_thread'ed from 
somewhere). Where should it continue? Neither in kernel code because it's now 
hidden (or it should be, anyhow this isn't supposed to work), nor in 
userspace code because no one has been specified.

Now, surely, there are cases where a userspace context will exist. For 
instance, modprobe <some module spawning a kernel thread in initialization>, 
or mount ext3/reiserfs fs. In both cases, the kernel code will spawn a kernel 
thread; but the userspace caller will already have continued with the system 
call return code when the kernel thread exits (or, probably, the caller will 
have died).

> But now the problem is that there will be segmentation fault just before
> the kernel thread go to the user space. After tracing I found when the
> segmentation fault occur, in handle_page_fault function, (!(vma->vm_flags &
> VM_GROWSDOWN)) is true and the err is -14. What's the meaning of such
> value?

Look up in errno headers (/usr/include/asm/errno.h and dependencies). It's 
EFAULT, which makes sense. No userspace program, so no mapping to use and no 
registers to execute.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

RE: [uml-devel] Segmentation fault with kernel thread in UML-2.6.7 TT mode

[Alex LIU]

On 16 July 2005, Blaisorblade wrote:

> Hmm, but where's the caller to return? In most cases it won't exist. I 
> don't understand what's your purpose, and the behaviour you'd want to 
> reproduce. Sorry, but *which* userspace should it go to? What you're 
> modifying is the execution path of kernel_thread.

In fact I want to port Bproc to UML. Now Bproc is based on i386. And a part of the main work Bproc does is about the kernel thread...Bproc create a new kernel thread function with the name bproc_kernel_thread in i386 and let the Bproc kernel thread go to the user space rather than exit. Bproc will call the new kernel thread function while other i386 programs still call the original i386 kernel thread function kernel_thread.

The reason why Bproc create it's own bproc_kernel_thread function is below:
------------------------------------------------------
Bproc provides the process migration facilities for processes running in a cluster. The administrator can control all the cluster processes on the master node(or front end) locally. The place holders in the master's process tree are called ghost processes. There is one ghost for every remote process. Ghost processes are lightweight kernel thread.

In i386, the child process created by kernel_thread cannot become a normal user process again.  Not easily in any case.  
In Bproc, if a process migrates back to the front end, the ghost process must effectively becomes a normal process again.  Then the ghost thread will have to 'return' to user space. 

Normally, a process is running in user space, does a syscall, some kernel code runs and it returns back to user space.  In the Bproc case where a process moves back onto its ghost.  The ghost has to be able to get back to user space.  Bproc implemented that by allowing the ghost thread function to return.

If the process moved off the front end the stack will contain something like syscall(move) ghost_thread.  If the ghost was created by forking on the slave node, the stack won't have the syscall on it. 
It'll just have ghost_thread.  bproc_kernel_thread adds that bit of stack stuff so that the ghost_thread_function looks like it was called from syscall.

Another important difference is that it passes a pointer to struct pt_regs so that the ghost thread can setup registers for the user space process.  The pt_regs are placed on the stack so that the syscall return code will find them and restore them.
-----------------------------------------------------

The Bproc's own kernel thread function(for i386) is below:

---------------------------------------------
/*
 * 1 - it does not force a CLONE_VM on you
 * 2 - it simulates syscall entry on the child by setting
 *     aside room for a struct pt_regs.  A pointer to this is
 *     the first argument to the child.  This way, the child can
 *     fill in the regs and "return" to user space if it wants to.
 */
                                                                                                                             
/*
 * This gets run with %ebx containing the
 * function to call, and %edx containing
 * the "args".
 */
void bproc_kernel_thread_helper(void);
__asm__(
".align 4\n"
"bproc_kernel_thread_helper:\n"
                                                                                                                             
/* Move our stack pointer so that we have a struct pt_regs on the
 * stack and nothing else.
 *
 * 8132 = 8k (stack size) - 60 (struct pt_regs size)
 */
"    movl  %esp, %eax                            \n"
"    andl $-"__stringify(THREAD_SIZE)",   %eax   \n"
"    addl $"__stringify(THREAD_SIZE)"-60, %eax   \n"
"    movl  %eax, %esp                            \n"
                                                                                                                             
"    pushl %edx             \n" /* arg2 = user pointer */
"    pushl %eax             \n" /* arg1 = pointer to regs */
"    call *%ebx             \n" /* call func */
"    addl  $8, %esp         \n" /* pop args */

"    movl  %esp, %ebx       \n" /* Store EAX to return to user space */
"    movl  %eax, 0x18(%ebx) \n" /* Set EAX to return to process */
                                                                                                                             
/* syscall_exit requires thread_info pointer in ebp */
"    movl  %esp, %ebp                            \n"
"    andl $-"__stringify(THREAD_SIZE)", %ebp     \n"
"    jmp syscall_exit                            \n"
);
                                                                                                                             
/*
 * Create a kernel thread
 */
int bproc_kernel_thread(int (*fn)(struct pt_regs *, void *),
                        void * arg, unsigned long flags)
{
        struct pt_regs regs;
                                                                                                                             
        memset(&regs, 0, sizeof(regs));
                                                                                                                             
        regs.ebx = (unsigned long) fn;
        regs.edx = (unsigned long) arg;
        regs.ecx = flags;
                                                                                                                             
        regs.xds = __USER_DS;
        regs.xes = __USER_DS;
        regs.orig_eax = -1;
        regs.eip = (unsigned long) bproc_kernel_thread_helper;
        regs.xcs = __KERNEL_CS;
        regs.eflags = 0x286;
                                                                                                                             
        /* Ok, create the new process.. */
        return do_fork(flags, 0, &regs, 0, NULL, NULL);
}
-------------------------------------------------

> Now, let's take a call to
> kernel_thread from the initial thread, before init is executed, or a similar 
> situation (ksoftirqd and such things must surely be kernel_thread'ed from 
> somewhere). Where should it continue? Neither in kernel code because it's now 
> hidden (or it should be, anyhow this isn't supposed to work), nor in 
> userspace code because no one has been specified.

> Now, surely, there are cases where a userspace context will exist. For
> instance, modprobe <some module spawning a kernel thread in initialization>, 
> or mount ext3/reiserfs fs. In both cases, the kernel code will spawn a kernel 
> thread; but the userspace caller will already have continued with the system 
> call return code when the kernel thread exits (or, probably, the caller will 
> have died).

Sorry, I don't want to substitude the original UML kernel_thread function. I just create a new one with the name bproc_kenel_thread, which will be called by Bproc in UML just like Bproc in i386. So UML programs which will call kernel thread still call the original UML kernel thread. Sorry for my unclear words...

I know in UML tt mode, process fork/clone and kernel thread are handled differently. In copy_thread_tt, I found process forking will call fork_tramp and finish_fork_handler while kernel thread will call new_thread_proc and new_thread_handler. 

In UML, I think the forked child process will also return to user space like in i386 ret_from_fork. So I used finish_fork_handler for reference and modified new_thread_handler to create the bproc_new_thread_handler. My purpose is that in bproc_new_thread_handler the new created kernel thread will return to the user space rather than exit. 

In UML,I found in finish_fork_handler, set_user_mode is called at last. I think it's purpose is to let the new forked process go to the user space like ret_from_fork in i386. So I add the set_user_mode in bproc_new_thread_handler after run_kernel_thread to let the kernel thread also go to the user space. I Also create the sigcontext for the bproc kernel thread like forking in copy_thread_tt.

But currently there is the segmentation fault problem as I mentioned in my last mail. Any ideas? Thanks a lot!

Alex




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op�k
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Segmentation fault with kernel thread in UML-2.6.7 TT mode

[Jeff Dike]

On Sun, Jul 17, 2005 at 03:52:46PM +0800, Alex LIU wrote:
> In fact I want to port Bproc to UML. Now Bproc is based on i386. And
> a part of the main work Bproc does is about the kernel thread...Bproc
> create a new kernel thread function with the name bproc_kernel_thread
> in i386 and let the Bproc kernel thread go to the user space rather
> than exit. 

What does it run when it enters userspace?  The only other thing I can
think of which does this is the kernel thread that turns into init,
which it does by calling exec.

> In UML,I found in finish_fork_handler, set_user_mode is called at
> last. I think it's purpose is to let the new forked process go to
> the user space like ret_from_fork in i386. 

If you look at its implementation, you'll see that it is very tt-mode 
specific, and thus can't do something as basic as re-entering
userspace in a generic way.

If you are entering userspace, you need for there to be something
there to enter.

				Jeff


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Segmentation fault with kernel thread in UML-2.6.7 TT mode

[Blaisorblade]

On Sunday 17 July 2005 09:52, Alex LIU wrote:
> On 16 July 2005, Blaisorblade wrote:
> > Hmm, but where's the caller to return? In most cases it won't exist. I
> > don't understand what's your purpose, and the behaviour you'd want to
> > reproduce. Sorry, but *which* userspace should it go to? What you're
> > modifying is the execution path of kernel_thread.

> The reason why Bproc create it's own bproc_kernel_thread function is below:
> ------------------------------------------------------
...
> -----------------------------------------------------
Ok, that is done on BPROC_MOVE, right?
> The Bproc's own kernel thread function(for i386) is below:
>
> ---------------------------------------------
> /*
>  * 1 - it does not force a CLONE_VM on you
>  * 2 - it simulates syscall entry on the child by setting
>  *     aside room for a struct pt_regs.  A pointer to this is
>  *     the first argument to the child.  This way, the child can
>  *     fill in the regs and "return" to user space if it wants to.
>  */
>
> /*
>  * This gets run with %ebx containing the
>  * function to call, and %edx containing
>  * the "args".
>  */
> void bproc_kernel_thread_helper(void);
> __asm__(
> ".align 4\n"
> "bproc_kernel_thread_helper:\n"
>
> /* Move our stack pointer so that we have a struct pt_regs on the
>  * stack and nothing else.
>  *
>  * 8132 = 8k (stack size) - 60 (struct pt_regs size)
>  */
> "    movl  %esp, %eax                            \n"
> "    andl $-"__stringify(THREAD_SIZE)",   %eax   \n"
> "    addl $"__stringify(THREAD_SIZE)"-60, %eax   \n"
> "    movl  %eax, %esp                            \n"
>
> "    pushl %edx             \n" /* arg2 = user pointer */
> "    pushl %eax             \n" /* arg1 = pointer to regs */
> "    call *%ebx             \n" /* call func */
> "    addl  $8, %esp         \n" /* pop args */
>
> "    movl  %esp, %ebx       \n" /* Store EAX to return to user space */
> "    movl  %eax, 0x18(%ebx) \n" /* Set EAX to return to process */
>
> /* syscall_exit requires thread_info pointer in ebp */
> "    movl  %esp, %ebp                            \n"
> "    andl $-"__stringify(THREAD_SIZE)", %ebp     \n"
> "    jmp syscall_exit                            \n"
Note here syscall_exit takes the place of ret_from_fork.
>
> /*
>  * Create a kernel thread
>  */
> int bproc_kernel_thread(int (*fn)(struct pt_regs *, void *),
>                         void * arg, unsigned long flags)
> {
>         struct pt_regs regs;
>
>         memset(&regs, 0, sizeof(regs));
>
>         regs.ebx = (unsigned long) fn;
>         regs.edx = (unsigned long) arg;
>         regs.ecx = flags;
>
>         regs.xds = __USER_DS;
>         regs.xes = __USER_DS;
>         regs.orig_eax = -1;
>         regs.eip = (unsigned long) bproc_kernel_thread_helper;
>         regs.xcs = __KERNEL_CS;
>         regs.eflags = 0x286;
You should also decode the reason for eflags being 0x286 - that seems a 
strange hack.
>         /* Ok, create the new process.. */
>         return do_fork(flags, 0, &regs, 0, NULL, NULL);
> }
> -------------------------------------------------

> I know in UML tt mode, process fork/clone and kernel thread are handled
> differently. In copy_thread_tt, I found process forking will call
> fork_tramp and finish_fork_handler while kernel thread will call
> new_thread_proc and new_thread_handler.

> In UML, I think the forked child process will also return to user space
> like in i386 ret_from_fork.
More or less... remember UML is like a debugger, since it's using ptrace, so 
you don't have kernel and userspace on the "same stack" directly. Actually, 
the kernel code for syscalls is run inside a signal handler (for SIGUSR2) in 
the traced process, so you end up with a similar situation. An important 
difference is that on i386 the kernel part of the stack is *identical*, you 
must only change the EAX register (which contains the return value). While on 
UML the kernel stack contents are completely different.

> So I used finish_fork_handler for reference and 
> modified new_thread_handler to create the bproc_new_thread_handler.

> My 
> purpose is that in bproc_new_thread_handler the new created kernel thread
> will return to the user space rather than exit.

> In UML,I found in finish_fork_handler, set_user_mode is called at last. I
> think it's purpose is to let the new forked process go to the user space
> like ret_from_fork in i386.
Yes and no, and no for your purpose, you should be careful. Look at the code 
in set_user_mode and at OP_TRACE_ON implementation in tracer() (and 
do_proc_op()). When the executed code is the userspace one, the tracing 
thread (which always runs tracer()) must nullify syscalls and handle them in 
UML, while on kernel code it must let them go, so tracer has two different 
operating modes, and chooses between them based on the value of the "tracing" 
variable. set_user_mode() causes it to change. Stop. So  it's not enough.

Then, the finish_fork_handler code (which is the SIGUSR1 handler) returns, and 
then the UML code (which is in SIGUSR2 handler, since it is syscall execution 
code) returns to the userspace stack. Since the userspace stack is identical 
for both threads, and only EAX differs, things work. But you don't have a 
userspace stack, unless you have already setup it!

Bproc probably marks the page as missing and handles the faults, and you could 
do the same.

I think that there's no problem for the kernel stack, it is a different one 
like on i386 (see the call to 
init_new_thread_stack->set_sigstack->...->sigaltstack()).


> So I add the set_user_mode in 
> bproc_new_thread_handler after run_kernel_thread to let the kernel thread
> also go to the user space.

> I Also create the sigcontext for the bproc 
> kernel thread like forking in copy_thread_tt.
It should be rather unlike the source, since the registers you are copying 
should not be taken from another process, but from the data Bproc got from 
the network. Otherwise yes, it's correct...
But (I assume your email is misleading) this should be done after return, 
right?

Actually, however, I think it may be simpler to implement that more like how 
"exec" is handled, than how "fork" is handled, at least for UML specific 
details. Yes, this has a performance cost, and the problems may lay 
elsewhere.

> But currently there is the segmentation fault problem as I mentioned in my
> last mail.
In particular: since it's testing VMA_GROWSDOWN, it means that the only VMA 
(which is the kernel recorded image of a mmap() call, either explicitly done, 
or auto-done by ELF startup code) which it found covers a range *above* the 
fault address, and that the VMA is not a "stack-like" one (the stack VMA 
expands down automatically as needed. This can mean two things:
* either the address is a stack one and the VMA was not set up correctly (but 
that wouldn't be likely your code's fault) or
* more likely, the mappings haven't been setup correctly.

And -14 is -EFAULT (as you can easily check).
> Any ideas? Thanks a lot! 
Surely there's something wrong in the userspace setup. I mean, you must alter 
registers of the userspace thread (done in copy_thread_tt), and its memory 
mappings, to create a process image to return to.

Also, this probably involves creating a userspace context; for instance, a 
kernel thread has current->mm == NULL, and Bproc surely handles that somehow.
> Alex

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel