lkml.org 
[lkml]   [1998]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: pre-patch-2.1.107 breaks kmod
    Date
    On 26 Jun 1998 16:20:37 GMT, 
    cadams@ro.com (Chris Adams) wrote:
    >According to Linus Torvalds <torvalds@transmeta.com>:
    >>I'd welcome suggestions on which region to lock. It's nontrivial, but I
    >>bet there is some scheme that makes everybody happy..
    >
    >If insmod locked the module file from the time it opened it until it
    >exited, you would guarantee that only one copy of the module was being
    >loaded at one time.

    Aren't we missing something here? insmod is not the only thing that
    hits loaded modules, rmmod does as well. Consider the race

    insmod x.o
    insmod x.o rmmod x.o in parallel

    Using an flock scheme, the second insmod waits for the flock and holds
    until the first insmod completes. Then it checks if the module has
    been loaded while it was waiting, yes the module is there, return OK.
    In the meantime rmmod has deleted the module - Oops. Don't we need to
    serialise rmmod at a higher level as well as insmod?

    And before anybody suggests flocking in rmmod as well. rmmod has no
    inode to access, the module in storage has no reference back to where
    it was loaded from. You don't have to load from any particular object,
    you can even load a module under a completely different name. rmmod
    cannot definitively tell where a module was loaded from.

    The more I think about it, the more I think we need a mechanism that
    locks the entire module load/delete process at the top level. A global
    lock that single threads insmod and rmmod against all other loads or
    deletes. The mechanism "just" has to allow recursive module loads, and
    the problem is solved. The difficulty is identifying recursive loads
    as opposed to two separate loads trying to run in parallel. This
    approach also avoids the problem of file systems that do not support
    flock.


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu

    \
     
     \ /
      Last update: 2005-03-22 13:43    [W:0.021 / U:1.004 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site