Syscall from Kernel Space

Syscall from Kernel Space

[Prasad]

Hi all,
	Is there a way using which i could invoke a syscall in the kernel 
space?  The syscall is to be run disguised as another process.  The actual 
situation is that I have a kernel thread running (a proxy for another 
existing but sleeping process) This thread should run syscalls on behalf 
of that process.
	Please so help me out!  Also send me some URLs where i could find 
related stuff.

Prasad.

-- 
Failure is not an option

Re: Syscall from Kernel Space

[Jeff Garzik]

On Thu, Feb 20, 2003 at 11:04:37PM +0530, Prasad wrote:
> 	Is there a way using which i could invoke a syscall in the kernel 
> space?  The syscall is to be run disguised as another process.  The actual 

Call sys_<syscall>.  Look at the kernel code for examples.

Note that typically you don't want to do this... and you _really_ don't
want to do this if the syscall is not one of the common file I/O
syscalls (read/write/open/close, etc.)

	Jeff

Re: Syscall from Kernel Space

[Prasad]

but what about masking the process.  An example is... I want to use the
mmap syscall. the kernel implementation uses current->mm, but what i want
to do is, the current macro or the get_current() function should give me
the task_struct of a process so that the effect of the syscall is seen on 
that process and not on the current kernel thread.

Prasad. 

On Thu, 20 Feb 2003, Jeff Garzik wrote:

> On Thu, Feb 20, 2003 at 11:04:37PM +0530, Prasad wrote:
> > 	Is there a way using which i could invoke a syscall in the kernel 
> > space?  The syscall is to be run disguised as another process.  The actual 
> 
> Call sys_<syscall>.  Look at the kernel code for examples.
> 
> Note that typically you don't want to do this... and you _really_ don't
> want to do this if the syscall is not one of the common file I/O
> syscalls (read/write/open/close, etc.)
> 
> 	Jeff

Re: Syscall from Kernel Space

[Andrea Arcangeli]

On Thu, Feb 20, 2003 at 12:40:43PM -0500, Jeff Garzik wrote:
> On Thu, Feb 20, 2003 at 11:04:37PM +0530, Prasad wrote:
> > 	Is there a way using which i could invoke a syscall in the kernel 
> > space?  The syscall is to be run disguised as another process.  The actual 
> 
> Call sys_<syscall>.  Look at the kernel code for examples.
> 
> Note that typically you don't want to do this... and you _really_ don't
> want to do this if the syscall is not one of the common file I/O
> syscalls (read/write/open/close, etc.)

you never want to do this, the only point of a syscall is to enter
kernel, if you're just in kernel you're wasting time in calling the
syscall (not to tell about the new non soft interrupt based syscall
instructions, btw this is also why I rejected the int 0x81 thing on
x86-64 for 64bit syscalls)

Andrea

Re: Syscall from Kernel Space

[Jeff Garzik]

On Thu, Feb 20, 2003 at 11:10:27PM +0100, Andrea Arcangeli wrote:
> On Thu, Feb 20, 2003 at 12:40:43PM -0500, Jeff Garzik wrote:
> > On Thu, Feb 20, 2003 at 11:04:37PM +0530, Prasad wrote:
> > > 	Is there a way using which i could invoke a syscall in the kernel 
> > > space?  The syscall is to be run disguised as another process.  The actual 
> > 
> > Call sys_<syscall>.  Look at the kernel code for examples.
> > 
> > Note that typically you don't want to do this... and you _really_ don't
> > want to do this if the syscall is not one of the common file I/O
> > syscalls (read/write/open/close, etc.)
> 
> you never want to do this, the only point of a syscall is to enter
> kernel, if you're just in kernel you're wasting time in calling the
> syscall (not to tell about the new non soft interrupt based syscall
> instructions, btw this is also why I rejected the int 0x81 thing on
> x86-64 for 64bit syscalls)

He is talking about directly calling the function behind the syscall,
not actually executing a syscall itself.

The kernel already does this in various places.  sys_read, sys_write,
open_filp, sys_close, and other functions are safe to call from kernel
code -- though this is discouraged.  init/do_mounts.c is a particularly
annoying case, and is a big reason why klibc needs to be merged.
syscalls should be made from userspace, not the kernel.

	Jeff

Re: Syscall from Kernel Space

[Andrea Arcangeli]

On Thu, Feb 20, 2003 at 05:17:30PM -0500, Jeff Garzik wrote:
> On Thu, Feb 20, 2003 at 11:10:27PM +0100, Andrea Arcangeli wrote:
> > On Thu, Feb 20, 2003 at 12:40:43PM -0500, Jeff Garzik wrote:
> > > On Thu, Feb 20, 2003 at 11:04:37PM +0530, Prasad wrote:
> > > > 	Is there a way using which i could invoke a syscall in the kernel 
> > > > space?  The syscall is to be run disguised as another process.  The actual 
> > > 
> > > Call sys_<syscall>.  Look at the kernel code for examples.
> > > 
> > > Note that typically you don't want to do this... and you _really_ don't
> > > want to do this if the syscall is not one of the common file I/O
> > > syscalls (read/write/open/close, etc.)
> > 
> > you never want to do this, the only point of a syscall is to enter
> > kernel, if you're just in kernel you're wasting time in calling the
> > syscall (not to tell about the new non soft interrupt based syscall
> > instructions, btw this is also why I rejected the int 0x81 thing on
> > x86-64 for 64bit syscalls)
> 
> He is talking about directly calling the function behind the syscall,
> not actually executing a syscall itself.

this is not what I understood from your previous discussion also given
you suggest not to do that when he can call sys_read/sys_write instead
because they're just exported etc.. I just wanted to add a better
"never".

> syscalls should be made from userspace, not the kernel.

This is what I tried to say.

Andrea

Remote execution of syscalls (was Re: Syscall from Kernel Space)

[Prasad]

I am sorry for not being clear... but i think its time to tell you where i 
needed it.  I, as a graduating project am working on a distributed 
computing system, a part of which is "transparent process migration in 
non-distributed environments".  In my system i would like to ship the 
syscalls back to the original node(where the process originated). so for 
that i have a kernel thread that takes the requests and is supposed to 
execute the syscalls on behalf of the process (I have the idle task 
structure existing on the originating node even after the process is 
migrated to the other node).   And the question is how do i do that.  The 
idea I had was to execute the functions behind the syscalls directly, but 
again, these functions use a lot of 'current'.  Could you help me out of 
this situation!
	An alternative was that if get_current was called I would check if
the 'current' points to my kernel thread and if i have a remote syscall
pending, then i would return a pointer to the particular process's
task_struct.  This I think is a work-around that should work.  Please do
comment on this too.

Prasad.

On Thu, 20 Feb 2003, Andrea Arcangeli wrote:
> > 
> > He is talking about directly calling the function behind the syscall,
> > not actually executing a syscall itself.
> 
> this is not what I understood from your previous discussion also given
> you suggest not to do that when he can call sys_read/sys_write instead
> because they're just exported etc.. I just wanted to add a better
> "never".
> 
> > syscalls should be made from userspace, not the kernel.
> 
> This is what I tried to say.
> 
> Andrea
> 

-- 
Failure is not an option

Re: Remote execution of syscalls (was Re: Syscall from Kernel Space)

[Livio Baldini Soares]

  Hello Prasad!
 
 [Caveat:  I am I  kernelnewbie, anything  I say  can and  probably is
wrong, anyway]

Prasad writes:
> 
> I am sorry for not being clear... but i think its time to tell you where i 
> needed it.  I, as a graduating project am working on a distributed 
> computing system, a part of which is "transparent process migration in 
> non-distributed environments".  In my system i would like to ship the 
> syscalls back to the original node(where the process originated). so for 
> that i have a kernel thread that takes the requests and is supposed to 
> execute the syscalls on behalf of the process (I have the idle task 
> structure existing on the originating node even after the process is 
> migrated to the other node).  And the question is how do i do that. 

  Hummm.. why  not use  the more "obvious"  solution which is  using a
user-level thread  instead of  a kernel thread?   Then you  could make
whatever syscall  you want as  a process. Seems  cleaner to me,  and I
can't see any  obvious disadvantages (of course, I  don't know exactly
what you're trying to do over there). 

  You could  have the kernel spawn  a regular user  process to receive
system  calls   from  the  external  node  everytime   you  migrate  a
process. Or maybe even better,  one simple daemon which is responsible
for receiving syscalls for all external processes. 

  Or I'm way off park? 

  best regards!

--  
  Livio <livio@ime.usp.br>

Re: Remote execution of syscalls (was Re: Syscall from Kernel Space)

[Prasad]

before anything else, thanx for the response, i was very much discouraged 
by the fact that i did not get any replies...

coming to whats happening...  lets see it this way... Theres a process (x)  
that is migrated to some other node. Now any syscall that the process (X)  
makes is to be shipped back to the originating node.  Say i have a user
thread (Y) running and receiving requests for syscall executions.  And now
if i execute a syscall, the syscall will be executed as of (Y) is 
executing it, but i want the syscall to run as if (X) is executing it!
The process (X) still exists on the originating system, but is idle.

Someone please help me out!

Prasad.

On Fri, 21 Feb 2003, Livio Baldini Soares wrote:
> Prasad writes:
> > 
> > I am sorry for not being clear... but i think its time to tell you where i 
> > needed it.  I, as a graduating project am working on a distributed 
> > computing system, a part of which is "transparent process migration in 
> > non-distributed environments".  In my system i would like to ship the 
> > syscalls back to the original node(where the process originated). so for 
> > that i have a kernel thread that takes the requests and is supposed to 
> > execute the syscalls on behalf of the process (I have the idle task 
> > structure existing on the originating node even after the process is 
> > migrated to the other node).  And the question is how do i do that. 
> 
>   Hummm.. why  not use  the more "obvious"  solution which is  using a
> user-level thread  instead of  a kernel thread?   Then you  could make
> whatever syscall  you want as  a process. Seems  cleaner to me,  and I
> can't see any  obvious disadvantages (of course, I  don't know exactly
> what you're trying to do over there). 
> 
>   You could  have the kernel spawn  a regular user  process to receive
> system  calls   from  the  external  node  everytime   you  migrate  a
> process. Or maybe even better,  one simple daemon which is responsible
> for receiving syscalls for all external processes. 
> 

-- 
Failure is not an option

Re: Remote execution of syscalls (was Re: Syscall from Kernel Space)

[Pavel Machek]

Hi!

> before anything else, thanx for the response, i was very much discouraged 
> by the fact that i did not get any replies...
> 
> coming to whats happening...  lets see it this way... Theres a process (x)  
> that is migrated to some other node. Now any syscall that the process (X)  
> makes is to be shipped back to the originating node.  Say i have a user
> thread (Y) running and receiving requests for syscall executions.  And now
> if i execute a syscall, the syscall will be executed as of (Y) is 
> executing it, but i want the syscall to run as if (X) is executing it!
> The process (X) still exists on the originating system, but is idle.

And problem with Y telling X (using pipe?) to execute syscall is? Also
take a look at OpenMosix.	
								Pavel				

> > > I am sorry for not being clear... but i think its time to tell you where i 
> > > needed it.  I, as a graduating project am working on a
			  ~~~~~~~~~~~~~~~~~~

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Remote execution of syscalls (was Re: Syscall from Kernel Space)

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.44.0302212321530.6139-100000@students.iiit.net>
By author:    Prasad <prasad_s@students.iiit.net>
In newsgroup: linux.dev.kernel
>
> 
> before anything else, thanx for the response, i was very much discouraged 
> by the fact that i did not get any replies...
> 
> coming to whats happening...  lets see it this way... Theres a process (x)  
> that is migrated to some other node. Now any syscall that the process (X)  
> makes is to be shipped back to the originating node.  Say i have a user
> thread (Y) running and receiving requests for syscall executions.  And now
> if i execute a syscall, the syscall will be executed as of (Y) is 
> executing it, but i want the syscall to run as if (X) is executing it!
> The process (X) still exists on the originating system, but is idle.
> 

Sounds like you should let the otherwise-idle process X be the thread
that waits for the connection and issues system calls.  This is
basically RPC.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: cris ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: Remote execution of syscalls (was Re: Syscall from Kernel Space)

[Prasad]

On 24 Feb 2003, H. Peter Anvin wrote:
> > 
> > coming to whats happening...  lets see it this way... Theres a process (x)  
> > that is migrated to some other node. Now any syscall that the process (X)  
> > makes is to be shipped back to the originating node.  Say i have a user
> > thread (Y) running and receiving requests for syscall executions.  And now
> > if i execute a syscall, the syscall will be executed as of (Y) is 
> > executing it, but i want the syscall to run as if (X) is executing it!
> > The process (X) still exists on the originating system, but is idle.
> > 
> 
> Sounds like you should let the otherwise-idle process X be the thread
> that waits for the connection and issues system calls.  This is
> basically RPC.
> 

but again... in this case i got to replace the loaded executable by one
that accepts the connections while maintaining the mmap, the open files.  
Can someone suggest me how this could be done... I am totally unaware of
stuff like this.

Prasad.

-- 
Failure is not an option