All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
To: DX Cui <rijcos@gmail.com>, linux-mm@kvack.org
Cc: Matt Tolentino <matthew.e.tolentino@intel.com>,
	Dave Hansen <haveblue@us.ibm.com>, Andrew Morton <akpm@osdl.org>,
	Linus Torvalds <torvalds@osdl.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: memory hot-add: the kernel can notify udev daemon before creating the sys file state?
Date: Wed, 28 May 2014 15:32:41 -0500	[thread overview]
Message-ID: <538647E9.9020408@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAJm7N85kM7h_=ovhxutbh_rR1tukDSKcfjFA4zPWKuVtqUH0eg@mail.gmail.com>

On 05/25/2014 10:41 AM, DX Cui wrote:
> On Fri, May 23, 2014 at 8:27 PM, DX Cui <rijcos@gmail.com> wrote:
>> Hi all,
>> I think I found out the root cause: when memory hotplug was introduced in 2005:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3947be1969a9ce455ec30f60ef51efb10e4323d1
>> there was a race condition in:
>>
>> + static int add_memory_block(unsigned long node_id, struct
>> mem_section *section,
>> + unsigned long state, int phys_device)
>> +{
>> ...
>> + ret = register_memory(mem, section, NULL);
>> + if (!ret)
>> +        ret = mem_create_simple_file(mem, phys_index);
>> + if (!ret)
>> +        ret = mem_create_simple_file(mem, state);
>>
>> Here, first, add_memory_block() invokes register_memory() ->
>> sysdev_register() -> sysdev_add()->
>> kobject_uevent(&sysdev->kobj, KOBJ_ADD) to notify udev daemon, then
>> invokes mem_create_simple_file(). If the current execution is preempted
>> between the 2 steps, the issue I reported in the previous mail can happen.
>>
>> Luckily a commit in 2013 has fixed this issue undesignedly:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=96b2c0fc8e74a615888e2bedfe55b439aa4695e1
>>
>> It looks the new "register_memory() --> ... -> device_add()" path has the
>> correct order for sysfs creation and notification udev.
>>

Correct. that patch does fix this issue, though that was not the primary reason
for doing the patch. Always nice when a patch has unintended positive side affects.
 
>> It would be great if you can confirm my analysis. :-)
> 
> Any comments?
> I think we need to backport the patch
> 96b2c0fc8e74a615888e2bedfe55b439aa4695e1 to <=3.9 stable kernels.
> 

Although I have seen any issues because of this issue I agree that the fix
should be backported. Best to get rid of a known race condition before it
jumps up and bites us.

-Nathan

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2014-05-28 20:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-23  9:46 memory hot-add: the kernel can notify udev daemon before creating the sys file state? DX Cui
2014-05-23 12:27 ` DX Cui
2014-05-25 15:41   ` DX Cui
2014-05-28 20:32     ` Nathan Fontenot [this message]
2014-05-28 20:47   ` Dave Hansen
2014-05-29  8:48     ` DX Cui

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=538647E9.9020408@linux.vnet.ibm.com \
    --to=nfont@linux.vnet.ibm.com \
    --cc=akpm@osdl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=haveblue@us.ibm.com \
    --cc=linux-mm@kvack.org \
    --cc=matthew.e.tolentino@intel.com \
    --cc=rijcos@gmail.com \
    --cc=torvalds@osdl.org \
    /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.