Re: Two fixes for 2.4.19-pre5-ac3

[Anton Altaparmakov]

At 21:23 07/04/02, Muli Ben-Yehuda wrote:
>On Sun, Apr 07, 2002 at 09:29:01PM +0100, Alan Cox wrote:
> > > hijacks syscall entries in the sys_call_table as well, because we
> > > want it to work as a module and not require patching the kernel. Our
> > > solution to the module unload race on syscall de-hijacking is simple,
> > > splitting the system call hijacking code into a single small module
> > > which once loaded cannot be unloaded.
> >
> > So your small module can export a function called
> >       patch_syscall(NR_foo, function);
> >
> > Now you can put the arch specific syscall patching code into your small
> > common module and its cleaner anyway ?
>
>Right, this module (syscall_hijack.o) currently has the interface:
>
>int hijack_syscall_before(int syscall_id, func_ptr func);
>int hijack_syscall_after(int syscall_id, func_ptr func);
>
>int release_syscall_before(int syscall_id);
>int release_syscall_after(int syscall_id);
>
>where 'before' and 'after' correspond to a hook which should run
>before the original system call is invoked (allowing it to specify
>that the original system call should not be executed) or after the
>original system call is invoked (allowing it access to its return
>value).
[snip]

So are you coping with someone hijacking YOU as well between calls to 
hijack_syscall_* and release_syscall_*? Or would that trash the caller chain?

 From your interface I would assume yes, but just making sure...

Anton