Bug 7880 - modprobe: already_loaded function should not return true if the state of the module in /proc/modules is not 'Live'
Summary: modprobe: already_loaded function should not return true if the state of the ...
Status: RESOLVED FIXED
Alias: None
Product: Busybox
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: PC Linux
: P5 minor
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-11 05:26 UTC by Harish
Modified: 2015-02-13 15:49 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments
proposed patch (1.67 KB, patch)
2015-02-11 05:26 UTC, Harish
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Harish 2015-02-11 05:26:38 UTC
Created attachment 5870 [details]
proposed patch

already_loaded function should not return true if the state
of the module in /proc/modules is not 'Live'. Reason being,
Parallel module load request on SMP architecture might result in
failure or unexpected behaviour via modprobe. Added the check of
'Live' state in already_loaded function to handle the same.
Comment 1 Denys Vlasenko 2015-02-11 20:54:16 UTC
(In reply to comment #0)
> already_loaded function should not return true if the state
> of the module in /proc/modules is not 'Live'. Reason being,
> Parallel module load request on SMP architecture might result in
> failure or unexpected behaviour via modprobe. Added the check of
> 'Live' state in already_loaded function to handle the same.

The state can be Unloading, Loading, or Live.

The code which checks already_loaded() is this one:

        if (!is_remove && already_loaded(name)) {
                dbg1_error_msg("nothing to do for '%s'", name);
                return;
        }

I don't see why it would be better if we change "Loading" modules to be reported as !already_loaded(). If we do, then an attempt to load a module while it is already being loaded will be made (currently, we skip such concurrent loading). Is this better? Why?
Comment 2 Harish 2015-02-12 06:37:59 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > already_loaded function should not return true if the state
> > of the module in /proc/modules is not 'Live'. Reason being,
> > Parallel module load request on SMP architecture might result in
> > failure or unexpected behaviour via modprobe. Added the check of
> > 'Live' state in already_loaded function to handle the same.
> 
> The state can be Unloading, Loading, or Live.
> 
> The code which checks already_loaded() is this one:
> 
>         if (!is_remove && already_loaded(name)) {
>                 dbg1_error_msg("nothing to do for '%s'", name);
>                 return;
>         }
> 
> I don't see why it would be better if we change "Loading" modules to be
> reported as !already_loaded(). If we do, then an attempt to load a module while
> it is already being loaded will be made (currently, we skip such concurrent
> loading). Is this better? Why?

usecase:
two sd cards are being mounted in parallel at same time on dual core. example modules which are getting loaded is  nls_cp437. While one module is being loaded , it makes state in /proc/modules as 'coming' and then starts doing its module init function ( in our case - registering nls). meanwhile on other core , if modprobe returns that is has already been loaded, then it will continue and search for the nls list which is not yet finished from first module init.
This fails resulting in not mounting sd card.

In general - with this patch - 
an attempt to load a module while it is already being loaded will be made  as you mentioned. However since it is handled properly in  linux kernel (module.c file ) it will not make much difference.
Comment 3 Denys Vlasenko 2015-02-12 15:21:14 UTC
Thanks!
Fixed in git.
Comment 4 Harish 2015-02-13 05:21:14 UTC
(In reply to comment #3)
> Thanks!
> Fixed in git.

Nice fix - 

But one review comment - 

ret | 1; condition is wrong. 
it always returns true and already_loaded as success.


I wish my name was also there in <Signed-off> section !!
Comment 5 Harish 2015-02-13 15:49:54 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Thanks!
> > Fixed in git.
> 
> Nice fix - 
> 
> But one review comment - 
> 
> ret | 1; condition is wrong. 
> it always returns true and already_loaded as success.
> 
> 
> I wish my name was also there in <Signed-off> section !!



Yet again disappointed that my name is not present in signed-off section even for the review comment fix - 
http://git.busybox.net/busybox/commit/?id=402afe1cc69ea505c9bf82ffe06e51ffecf694df

Even the reviewer's name could have been included along the with the coders name.