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
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
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
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
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
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
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
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 <[email protected]>
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
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?]
Followup to: <[email protected]>
By author: Prasad <[email protected]>
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
--
<[email protected]> at work, <[email protected]> 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
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