[lkml]   [2003]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: The disappearing sys_call_table export.

[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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:35    [W:0.058 / U:0.216 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site