All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harish Jenny Kandiga Nagaraj <harish_kandiga@mentor.com>
To: Rusty Russell <rusty@rustcorp.com.au>,
	Lucas De Marchi <lucas.de.marchi@gmail.com>
Cc: linux-modules <linux-modules@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] libkmod-module: Remove directory existence check for KMOD_MODULE_BUILTIN
Date: Wed, 18 Feb 2015 11:40:02 +0530	[thread overview]
Message-ID: <54E42CBA.5010007@mentor.com> (raw)
In-Reply-To: <874mqjuaky.fsf@rustcorp.com.au>


On Wednesday 18 February 2015 09:37 AM, Rusty Russell wrote:
> Lucas De Marchi <lucas.de.marchi@gmail.com> writes:
>> On Tue, Feb 17, 2015 at 10:56 AM, Harish Jenny K N
>> <harish_kandiga@mentor.com> 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.
These are the operations handled in kernel after syscall/init_module is called. Here is the list of operations which happen before point number 1)
0a) __request_module/try_then_request_module gets called from kernel.
0b) call_modprobe gets called which calls usermode modprobe to see if module is loaded.
0c) syscall init_module gets called from modprobe.
> 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.
Problem here is second init_module is not yet called. if it gets called , it is handled properly. Adding a sleep in nls_cp437 is handled properly.
We need to add sleep in module_add_modinfo_attrs ( module.c ) while creating sysfs files(sysfs_create_file) in order to reproduce the issue I mentioned.
>
> 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.
Did not get the point of checking initstate after loading fails. However we need to handle even unusual rare cases as well.
>
> Cheers,
> Rusty.

  reply	other threads:[~2015-02-18  6:10 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-17 12:56 [PATCH] libkmod-module: Remove directory existence check for KMOD_MODULE_BUILTIN Harish Jenny K N
2015-02-17 17:30 ` Lucas De Marchi
2015-02-18  4:07   ` Rusty Russell
2015-02-18  6:10     ` Harish Jenny Kandiga Nagaraj [this message]
2015-02-18 16:50     ` Lucas De Marchi
2015-02-18 22:40       ` Rusty Russell
2015-02-19  1:19         ` Lucas De Marchi
2015-02-19  2:25           ` greg KH
2015-02-19  3:46             ` Lucas De Marchi
2015-02-19  2:25           ` Rusty Russell
2015-02-19  3:34             ` Lucas De Marchi
2015-02-19  5:49           ` Harish Jenny Kandiga Nagaraj
2015-02-19 10:30             ` Lucas De Marchi
2015-02-19 10:30               ` Lucas De Marchi
2015-02-19 12:32               ` Harish Jenny Kandiga Nagaraj
2015-02-19 12:43                 ` Lucas De Marchi
2015-02-19 12:43                   ` Lucas De Marchi
2015-02-19 14:02                   ` Harish Jenny Kandiga Nagaraj
2015-02-19 14:35                     ` Harish Jenny Kandiga Nagaraj
2015-02-28 17:28                       ` Lucas De Marchi
2015-03-02  4:52                         ` Harish Jenny Kandiga Nagaraj
2015-02-19 12:33               ` Harish Jenny Kandiga Nagaraj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54E42CBA.5010007@mentor.com \
    --to=harish_kandiga@mentor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=lucas.de.marchi@gmail.com \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.