[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.019 / U:33.976 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site