2008/7/9 Denys Vlasenko <[EMAIL PROTECTED]>:
> On Tuesday 08 July 2008 12:16, Vladimir Dronnikov wrote:
>> 3. not read -> become a master. open ".modules.dep.do-not-edit!!!" for
>> exclusive write. all other concurrent modprobes have to wait till the master
>> closes the file.
>
> This "exclusive write" stuff is notorious for breaking on
> non-local filesystems, NFS, etc... I prefer the scheme where
> atomicity is achieved by rename().
>
>> The spiky edges here are:
>> i) by definition it is mandatory locking that is needed to lock
>> ".modules.dep.do-not-edit!!!". That way concurrent modprobes just block in
>> open() and there's no need for ugly workarounds. Do we have mandatory
>> locking?
>
> We do. Sometimes :)
>
>> ii) string xreallocations. but you've introduced xrealloc_vector() which can
>> fit.
>>
>> I've been using my modprobe about a week.
>>
>> When modprove enters alias searching loop, it tries to generate
>> > new modprobe.dep.bb for the benefit of other mdprobes, since
>> > it is going to scan all modules anyway. It creates
>> > modprobe.dep.bb.new with O_EXCL. If that fails, other modprobe
>> > is already doing that, so just wait for it to disappear
>> > (other modprobe will rename it to modprobe.dep.bb)
>> > and use modprobe.dep.bb.
>>
>> O_EXCL is definitely not enough here. All 20 concurrents will generate the
>> full stuff and then the last spawned will win.
>
> Let me clarify: file is opened with O_CREAT + O_EXCL _before_
> modprobe starts expensive directory scan. If it fails with EEXIST,
> modprobe understands that it is the "second" one and it will _not_
> do the scan. It will wait for modprobe.dep.bb.new to "disappear"
> ("first" modprobe is expected to do the scan, write out
> modprobe.dep.bb.new and rename("modprobe.dep.bb.new", "modprobe.dep.bb")).
> At this moment "second" modprobe opens and reads modprobe.dep.bb.
>
> This way, only one modprobe will do the scan.
>
> It is semi-trivial to implement that in modprobe-small.c,
> I will try to find the time in next few days for that.Vladimir, can you try these two patches on top on current svn? In my limited testing they work. -- vda
9.patch
Description: Binary data
a.patch
Description: Binary data
_______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
