Lucas De Marchi <lucas.de.marchi@xxxxxxxxx> writes:
> On Tue, Feb 17, 2015 at 10:56 AM, Harish Jenny K N
> <harish_kandiga@xxxxxxxxxx> wrote:
>> 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 starts creating sysfs files.
>> meanwhile on other core, modprobe might return saying the module
>> is KMOD_MODULE_BUILTIN, which might result in not mounting sd card.
>
> an {f,}init_module() call should not return until the sysfs files are
> created and if there is /sys/module/<module>/ there should be
> /sys/module/<module>/initstate unless the module is builtin.
>
> Rusty, was there any changes in this area in the kernel recently?
Not deliberately.
> Or is the creation of /sys/module/<module> and
> /sys/module/<module>/initstate not atomic?
No, it's not atomic :( That makes it unreliable (it seemed like a good
idea in 2006 I guess).
Here's what happens from a kernel side:
1) Module is marked UNFORMED.
2) Check there's no module by same name already. If there is, and it's
UNFORMED or COMING, we wait.
3) module is marked COMING
4) module parses arguments.
5) sysfs directory and attributes are created.
6) module's init is called.
7) module is marked LIVE.
So, the second init_module should be waiting.
I tested this by putting a sleep in the nls_cp437 init, and watching
what modprobe did. It works correctly.
You are checking initstate, and getting caught in the race:
783 14:33:14.170205 open("/sys/module/nls_cp437/initstate", O_RDONLY|O_LARGEFILE|O_CLOEXEC)
You should probably check initstate *after* loading fails. It's
possible that it's unloaded in the meantime, but the race is pretty
narrow and unloading is unusual.
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-modules" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
