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.071 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site