Re: Size of pointers in sys_call_table?

Re: Size of pointers in sys_call_table?

[Andi Kleen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> > The layout of the sys_call_table is totally architecture dependant.  The
> > question to ask here is why do you need to use it?  Modifying it to hook
> > into syscalls is frowned upon.
> 
> And potentially unsafe (think about caching, and non atomic writes on
> some platforms)

It is ATM impossible to make a module that patches sys_call_table safe against
module unload races. The only way is to put a stub into the main kernel
that manages the module counters and calls a separate hook (i.e. as done 
by nfsd's syscall) 

[Introducing quiescent states in module unloading would probably fix that,
as it has been discussed for a long time now, but I lost hope that it'll ever
get implemented in the main kernel]

Other than that on some weird architectures like IA64 it can get quite 
complicated to patch the syscall table.

-Andi

Re: Size of pointers in sys_call_table?

[Keith Owens]

On 28 Aug 2001 18:54:06 +0200, 
Andi Kleen <ak@suse.de> wrote:
>[Introducing quiescent states in module unloading would probably fix that,
>as it has been discussed for a long time now, but I lost hope that it'll ever
>get implemented in the main kernel]

It will, in 2.5.

Size of pointers in sys_call_table?

[Harald Barth]

Most linux kernel ports export the sys_call_table symbol to be used in
modules. I have not succeeded how to automatially figure out the size
of a syscall pointer without inspecting the assembler for the
architecture in question. Examples are mips and sparc64. Have I
missed a syscall_t type available or shouldn't there be one?

Harald.

Re: Size of pointers in sys_call_table?

[Brian Gerst]

Harald Barth wrote:
> 
> Most linux kernel ports export the sys_call_table symbol to be used in
> modules. I have not succeeded how to automatially figure out the size
> of a syscall pointer without inspecting the assembler for the
> architecture in question. Examples are mips and sparc64. Have I
> missed a syscall_t type available or shouldn't there be one?
> 
> Harald.

The layout of the sys_call_table is totally architecture dependant.  The
question to ask here is why do you need to use it?  Modifying it to hook
into syscalls is frowned upon.

--

				Brian Gerst

Re: Size of pointers in sys_call_table?

[Harald Barth]

> The layout of the sys_call_table is totally architecture dependant.  The
> question to ask here is why do you need to use it?  Modifying it to hook
> into syscalls is frowned upon.

I want to set the "frowning upon" aside just for the moment and point
to the fact that the symbol actually is exported and in consequence
should be described by some data type. The data type may be "totally
architecture dependant".

I can join the frowning upon if we extend it to be about the export
of the sys_call_table in the first place, but there are no other means
to populate a syscall from a module, or have I missed something?

The different AFS implementations have used this for years.

Harald.

Re: Size of pointers in sys_call_table?

[Alan Cox]

> The layout of the sys_call_table is totally architecture dependant.  The
> question to ask here is why do you need to use it?  Modifying it to hook
> into syscalls is frowned upon.

And potentially unsafe (think about caching, and non atomic writes on
some platforms)

Re: Size of pointers in sys_call_table?

[Keith Owens]

On Tue, 28 Aug 2001 17:17:24 +0100 (BST), 
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> The layout of the sys_call_table is totally architecture dependant.  The
>> question to ask here is why do you need to use it?  Modifying it to hook
>> into syscalls is frowned upon.
>
>And potentially unsafe (think about caching, and non atomic writes on
>some platforms)

Not forgetting architectures like PPC64 and IA64 that require a
different function pointer format when syscall code is in a module.  A
simple replacement of a pointer in the syscall table will not work on
those architectures.

Re: Size of pointers in sys_call_table?

[Ralf Baechle]

On Tue, Aug 28, 2001 at 05:17:24PM +0100, Alan Cox wrote:

> > The layout of the sys_call_table is totally architecture dependant.  The
> > question to ask here is why do you need to use it?  Modifying it to hook
> > into syscalls is frowned upon.
> 
> And potentially unsafe (think about caching, and non atomic writes on
> some platforms)

Breakage practically guaranteed on MIPS systems where additional information
beyond the pointer is associated with a syscall entry point.  Breakage also
guaranteed on ccNUMA systems that run per-node copies of the kernel.

  Ralf