Re: The disappearing sys_call_table export.

[Terje Malmedal <terje.malmedal@usit.uio.no>]

[Jesse Pollard]
> On Thursday 08 May 2003 10:29, Terje Malmedal wrote:
>> [Christoph Hellwig]
>> 
>> >> The only problem I can see is that different modules overloading the
>> >> same function needs to be unloaded in the correct order. Is this the
>> >> only reason for removing it, or am I missing something?
>> >
>> > it's racy - and it doesn't work on half of the arches added over the
>> > last years.
>> 
>> Would you be so kind as to explain exactly what is racy? Just
>> asserting that it is does not help me understand anything.

> Look at this:

> [1]int init_module(void)
> [2]{
> [3]  orig_fsync=sys_call_table[SYS_fsync];
> [4]  sys_call_table[SYS_fsync]=hacked_fsync;
> [5]  return 0;
> [6]}

> Unless there is a LOCK on sys_call_table[SYS_fsync] another CPU could
> replace the pointer between lines 3 and 4. At that point line 4 would
> destroy the existing entry.. or destroy it when the original is restored,
> and would NOT be restoring the one insterted.

Yes, that's actually part of what I meant with my first quoted
paragraph above. Did not come out that way, sorry.

I can see one problem on unload, if the memory used by the module is
freed while another CPU is executing the module code, but it should be
easy enough to protect against with a lock. 

Assuming that loads are unloads are manually serialized in the
correct order are there any other problems?

-- 
 - Terje
malmedal@usit.uio.no