All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wen Congyang <wencongyang@gmail.com>
To: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>,
	isimatu.yasuaki@jp.fujitsu.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [RFC PATCH] memory-hotplug: Add memblock_state notifier
Date: Mon, 23 Jul 2012 20:13:34 +0800	[thread overview]
Message-ID: <500D3FEE.2050109@gmail.com> (raw)
In-Reply-To: <20120723110610.GB18801@dhcp-192-168-178-175.profitbricks.localdomain>

At 2012/7/23 19:06, Vasilis Liaskovitis Wrote:
> Hi,
>
> On Mon, Jul 23, 2012 at 05:08:04PM +0800, Wen Congyang wrote:
>>> +static int memblock_state_notifier_nb(struct notifier_block *nb, unsigned long
>>> +		val, void *v)
>>> +{
>>> +	struct memory_notify *arg = (struct memory_notify *)v;
>>> +	struct memory_block *mem = NULL;
>>> +	struct mem_section *ms;
>>> +	unsigned long section_nr;
>>> +
>>> +	section_nr = pfn_to_section_nr(arg->start_pfn);
>>> +	ms = __nr_to_section(section_nr);
>>> +	mem = find_memory_block(ms);
>>> +	if (!mem)
>>> +		goto out;
>>
>> we may offline more than one memory block.
>>
> thanks, you are right.
>
>>> +
>>> +	switch (val) {
>>> +	case MEM_GOING_OFFLINE:
>>> +	case MEM_OFFLINE:
>>> +	case MEM_GOING_ONLINE:
>>> +	case MEM_ONLINE:
>>> +	case MEM_CANCEL_ONLINE:
>>> +	case MEM_CANCEL_OFFLINE:
>>> +		mem->state = val;
>>
>> mem->state is protected by the lock mem->state_mutex, so if you want to
>> update the state, you must lock mem->state_mutex. But you cannot lock it
>> here, because it may cause deadlock:
>>
>> acpi_memhotplug                           sysfs interface
>> ===============================================================================
>>                                            memory_block_change_state()
>>                                                lock mem->state_mutex
>>                                                memory_block_action()
>> offline_pages()
>>      lock_memory_hotplug()
>>                                                    offline_memory()
>>                                                        lock_memory_hotplug() // block
>>      memory_notify()
>>          memblock_state_notifier_nb()
>> ===============================================================================
>
> good point. Maybe if memory_hotplug_lock and state_mutex locks are acquired in
> the same order in the 2 code paths, this could be avoided.

Yes, I am trying to fix another 2 problems(also based on ishimatsu's 
patchset):
1. offline_memory() will fail if part of the memory is onlined and part 
of the memory
    is offlined.
2. notify the userspace if the memory block's status is changed

I guess this problem can be fixed together.

Thanks
Wen Congyang

>
>> I'm writing another patch to fix it.
>
> ok, I 'll test.
> thanks,
>
> - Vasilis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

WARNING: multiple messages have this Message-ID (diff)
From: Wen Congyang <wencongyang@gmail.com>
To: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>,
	isimatu.yasuaki@jp.fujitsu.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [RFC PATCH] memory-hotplug: Add memblock_state notifier
Date: Mon, 23 Jul 2012 20:13:34 +0800	[thread overview]
Message-ID: <500D3FEE.2050109@gmail.com> (raw)
In-Reply-To: <20120723110610.GB18801@dhcp-192-168-178-175.profitbricks.localdomain>

At 2012/7/23 19:06, Vasilis Liaskovitis Wrote:
> Hi,
>
> On Mon, Jul 23, 2012 at 05:08:04PM +0800, Wen Congyang wrote:
>>> +static int memblock_state_notifier_nb(struct notifier_block *nb, unsigned long
>>> +		val, void *v)
>>> +{
>>> +	struct memory_notify *arg = (struct memory_notify *)v;
>>> +	struct memory_block *mem = NULL;
>>> +	struct mem_section *ms;
>>> +	unsigned long section_nr;
>>> +
>>> +	section_nr = pfn_to_section_nr(arg->start_pfn);
>>> +	ms = __nr_to_section(section_nr);
>>> +	mem = find_memory_block(ms);
>>> +	if (!mem)
>>> +		goto out;
>>
>> we may offline more than one memory block.
>>
> thanks, you are right.
>
>>> +
>>> +	switch (val) {
>>> +	case MEM_GOING_OFFLINE:
>>> +	case MEM_OFFLINE:
>>> +	case MEM_GOING_ONLINE:
>>> +	case MEM_ONLINE:
>>> +	case MEM_CANCEL_ONLINE:
>>> +	case MEM_CANCEL_OFFLINE:
>>> +		mem->state = val;
>>
>> mem->state is protected by the lock mem->state_mutex, so if you want to
>> update the state, you must lock mem->state_mutex. But you cannot lock it
>> here, because it may cause deadlock:
>>
>> acpi_memhotplug                           sysfs interface
>> ===============================================================================
>>                                            memory_block_change_state()
>>                                                lock mem->state_mutex
>>                                                memory_block_action()
>> offline_pages()
>>      lock_memory_hotplug()
>>                                                    offline_memory()
>>                                                        lock_memory_hotplug() // block
>>      memory_notify()
>>          memblock_state_notifier_nb()
>> ===============================================================================
>
> good point. Maybe if memory_hotplug_lock and state_mutex locks are acquired in
> the same order in the 2 code paths, this could be avoided.

Yes, I am trying to fix another 2 problems(also based on ishimatsu's 
patchset):
1. offline_memory() will fail if part of the memory is onlined and part 
of the memory
    is offlined.
2. notify the userspace if the memory block's status is changed

I guess this problem can be fixed together.

Thanks
Wen Congyang

>
>> I'm writing another patch to fix it.
>
> ok, I 'll test.
> thanks,
>
> - Vasilis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
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:[~2012-07-23 12:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-20 11:18 [RFC PATCH] memory-hotplug: Add memblock_state notifier Vasilis Liaskovitis
2012-07-20 11:18 ` Vasilis Liaskovitis
2012-07-23  9:08 ` Wen Congyang
2012-07-23  9:08   ` Wen Congyang
2012-07-23 11:06   ` Vasilis Liaskovitis
2012-07-23 11:06     ` Vasilis Liaskovitis
2012-07-23 12:13     ` Wen Congyang [this message]
2012-07-23 12:13       ` Wen Congyang

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=500D3FEE.2050109@gmail.com \
    --to=wencongyang@gmail.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=vasilis.liaskovitis@profitbricks.com \
    --cc=wency@cn.fujitsu.com \
    /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.