All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ni zhan Chen <nizhan.chen@gmail.com>
To: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	wency@cn.fujitsu.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, rientjes@google.com,
	liuj97@gmail.com, len.brown@intel.com, benh@kernel.crashing.org,
	paulus@samba.org, minchan.kim@gmail.com,
	akpm@linux-foundation.org
Subject: Re: [PATCH 1/4] memory-hotplug: add memory_block_release
Date: Fri, 28 Sep 2012 14:04:23 +0800	[thread overview]
Message-ID: <50653DE7.70702@gmail.com> (raw)
In-Reply-To: <50651D65.5080400@jp.fujitsu.com>

On 09/28/2012 11:45 AM, Yasuaki Ishimatsu wrote:
> Hi Kosaki-san,
>
> 2012/09/28 10:35, KOSAKI Motohiro wrote:
>> On Thu, Sep 27, 2012 at 8:24 PM, Yasuaki Ishimatsu
>> <isimatu.yasuaki@jp.fujitsu.com> wrote:
>>> Hi Chen,
>>>
>>>
>>> 2012/09/27 19:20, Ni zhan Chen wrote:
>>>>
>>>> Hi Congyang,
>>>>
>>>> 2012/9/27 <wency@cn.fujitsu.com>
>>>>
>>>>> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>>>>
>>>>> When calling remove_memory_block(), the function shows following 
>>>>> message
>>>>> at
>>>>> device_release().
>>>>>
>>>>> Device 'memory528' does not have a release() function, it is 
>>>>> broken and
>>>>> must
>>>>> be fixed.
>>>>>
>>>>
>>>> What's the difference between the patch and original implemetation?
>>>
>>>
>>> The implementation is for removing a memory_block. So the purpose is
>>> same as original one. But original code is bad manner. 
>>> kobject_cleanup()
>>> is called by remove_memory_block() at last. But release function for
>>> releasing memory_block is not registered. As a result, the kernel 
>>> message
>>> is shown. IMHO, memory_block should be release by the releae function.
>>
>> but your patch introduced use after free bug, if i understand correctly.
>> See unregister_memory() function. After your patch, kobject_put() call
>> release_memory_block() and kfree(). and then device_unregister() will
>> touch freed memory.
>

this patch is similiar to [RFC v9 PATCH 10/21] memory-hotplug: add 
memory_block_release, they handle the same issue, can these two patches 
be fold to one?

> It is not correct. The kobject_put() is prepared against 
> find_memory_block()
> in remove_memory_block() since kobject->kref is incremented in it.
> So release_memory_block() is called by device_unregister() correctly 
> as follows:
>
> [ 1014.589008] Pid: 126, comm: kworker/0:2 Not tainted 
> 3.6.0-rc3-enable-memory-hotremove-and-root-bridge #3
> [ 1014.702437] Call Trace:
> [ 1014.731684]  [<ffffffff8144d096>] release_memory_block+0x16/0x30
> [ 1014.803581]  [<ffffffff81438587>] device_release+0x27/0xa0
> [ 1014.869312]  [<ffffffff8133e962>] kobject_cleanup+0x82/0x1b0
> [ 1014.937062]  [<ffffffff8133ea9d>] kobject_release+0xd/0x10
> [ 1015.002718]  [<ffffffff8133e7ec>] kobject_put+0x2c/0x60
> [ 1015.065271]  [<ffffffff81438107>] put_device+0x17/0x20
> [ 1015.126794]  [<ffffffff8143918a>] device_unregister+0x2a/0x60
> [ 1015.195578]  [<ffffffff8144d55b>] remove_memory_block+0xbb/0xf0
> [ 1015.266434]  [<ffffffff8144d5af>] unregister_memory_section+0x1f/0x30
> [ 1015.343532]  [<ffffffff811c0a58>] __remove_section+0x68/0x110
> [ 1015.412318]  [<ffffffff811c0be7>] __remove_pages+0xe7/0x120
> [ 1015.479021]  [<ffffffff81653d8c>] arch_remove_memory+0x2c/0x80
> [ 1015.548845]  [<ffffffff8165497b>] remove_memory+0x6b/0xd0
> [ 1015.613474]  [<ffffffff813d946c>] 
> acpi_memory_device_remove_memory+0x48/0x73
> [ 1015.697834]  [<ffffffff813d94c2>] acpi_memory_device_remove+0x2b/0x44
> [ 1015.774922]  [<ffffffff813a61e4>] acpi_device_remove+0x90/0xb2
> [ 1015.844796]  [<ffffffff8143c2fc>] __device_release_driver+0x7c/0xf0
> [ 1015.919814]  [<ffffffff8143c47f>] device_release_driver+0x2f/0x50
> [ 1015.992753]  [<ffffffff813a70dc>] acpi_bus_remove+0x32/0x6d
> [ 1016.059462]  [<ffffffff813a71a8>] acpi_bus_trim+0x91/0x102
> [ 1016.125128]  [<ffffffff813a72a1>] 
> acpi_bus_hot_remove_device+0x88/0x16b
> [ 1016.204295]  [<ffffffff813a2e57>] acpi_os_execute_deferred+0x27/0x34
> [ 1016.280350]  [<ffffffff81090599>] process_one_work+0x219/0x680
> [ 1016.350173]  [<ffffffff81090538>] ? process_one_work+0x1b8/0x680
> [ 1016.422072]  [<ffffffff813a2e30>] ? 
> acpi_os_wait_events_complete+0x23/0x23
> [ 1016.504357]  [<ffffffff810923ce>] worker_thread+0x12e/0x320
> [ 1016.571064]  [<ffffffff810922a0>] ? manage_workers+0x110/0x110
> [ 1016.640886]  [<ffffffff810983a6>] kthread+0xc6/0xd0
> [ 1016.699290]  [<ffffffff8167b144>] kernel_thread_helper+0x4/0x10
> [ 1016.770149]  [<ffffffff81670bb0>] ? retint_restore_args+0x13/0x13
> [ 1016.843165]  [<ffffffff810982e0>] ? __init_kthread_worker+0x70/0x70
> [ 1016.918200]  [<ffffffff8167b140>] ? gs_change+0x13/0x13
>
> Thanks,
> Yasuaki Ishimatsu
>
>>
>> static void
>> unregister_memory(struct memory_block *memory)
>> {
>>     BUG_ON(memory->dev.bus != &memory_subsys);
>>
>>     /* drop the ref. we got in remove_memory_block() */
>>     kobject_put(&memory->dev.kobj);
>>     device_unregister(&memory->dev);
>> }
>>
>
>
>

--
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>

WARNING: multiple messages have this Message-ID (diff)
From: Ni zhan Chen <nizhan.chen@gmail.com>
To: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	wency@cn.fujitsu.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, rientjes@google.com,
	liuj97@gmail.com, len.brown@intel.com, benh@kernel.crashing.org,
	paulus@samba.org, minchan.kim@gmail.com,
	akpm@linux-foundation.org
Subject: Re: [PATCH 1/4] memory-hotplug: add memory_block_release
Date: Fri, 28 Sep 2012 14:04:23 +0800	[thread overview]
Message-ID: <50653DE7.70702@gmail.com> (raw)
In-Reply-To: <50651D65.5080400@jp.fujitsu.com>

On 09/28/2012 11:45 AM, Yasuaki Ishimatsu wrote:
> Hi Kosaki-san,
>
> 2012/09/28 10:35, KOSAKI Motohiro wrote:
>> On Thu, Sep 27, 2012 at 8:24 PM, Yasuaki Ishimatsu
>> <isimatu.yasuaki@jp.fujitsu.com> wrote:
>>> Hi Chen,
>>>
>>>
>>> 2012/09/27 19:20, Ni zhan Chen wrote:
>>>>
>>>> Hi Congyang,
>>>>
>>>> 2012/9/27 <wency@cn.fujitsu.com>
>>>>
>>>>> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>>>>
>>>>> When calling remove_memory_block(), the function shows following 
>>>>> message
>>>>> at
>>>>> device_release().
>>>>>
>>>>> Device 'memory528' does not have a release() function, it is 
>>>>> broken and
>>>>> must
>>>>> be fixed.
>>>>>
>>>>
>>>> What's the difference between the patch and original implemetation?
>>>
>>>
>>> The implementation is for removing a memory_block. So the purpose is
>>> same as original one. But original code is bad manner. 
>>> kobject_cleanup()
>>> is called by remove_memory_block() at last. But release function for
>>> releasing memory_block is not registered. As a result, the kernel 
>>> message
>>> is shown. IMHO, memory_block should be release by the releae function.
>>
>> but your patch introduced use after free bug, if i understand correctly.
>> See unregister_memory() function. After your patch, kobject_put() call
>> release_memory_block() and kfree(). and then device_unregister() will
>> touch freed memory.
>

this patch is similiar to [RFC v9 PATCH 10/21] memory-hotplug: add 
memory_block_release, they handle the same issue, can these two patches 
be fold to one?

> It is not correct. The kobject_put() is prepared against 
> find_memory_block()
> in remove_memory_block() since kobject->kref is incremented in it.
> So release_memory_block() is called by device_unregister() correctly 
> as follows:
>
> [ 1014.589008] Pid: 126, comm: kworker/0:2 Not tainted 
> 3.6.0-rc3-enable-memory-hotremove-and-root-bridge #3
> [ 1014.702437] Call Trace:
> [ 1014.731684]  [<ffffffff8144d096>] release_memory_block+0x16/0x30
> [ 1014.803581]  [<ffffffff81438587>] device_release+0x27/0xa0
> [ 1014.869312]  [<ffffffff8133e962>] kobject_cleanup+0x82/0x1b0
> [ 1014.937062]  [<ffffffff8133ea9d>] kobject_release+0xd/0x10
> [ 1015.002718]  [<ffffffff8133e7ec>] kobject_put+0x2c/0x60
> [ 1015.065271]  [<ffffffff81438107>] put_device+0x17/0x20
> [ 1015.126794]  [<ffffffff8143918a>] device_unregister+0x2a/0x60
> [ 1015.195578]  [<ffffffff8144d55b>] remove_memory_block+0xbb/0xf0
> [ 1015.266434]  [<ffffffff8144d5af>] unregister_memory_section+0x1f/0x30
> [ 1015.343532]  [<ffffffff811c0a58>] __remove_section+0x68/0x110
> [ 1015.412318]  [<ffffffff811c0be7>] __remove_pages+0xe7/0x120
> [ 1015.479021]  [<ffffffff81653d8c>] arch_remove_memory+0x2c/0x80
> [ 1015.548845]  [<ffffffff8165497b>] remove_memory+0x6b/0xd0
> [ 1015.613474]  [<ffffffff813d946c>] 
> acpi_memory_device_remove_memory+0x48/0x73
> [ 1015.697834]  [<ffffffff813d94c2>] acpi_memory_device_remove+0x2b/0x44
> [ 1015.774922]  [<ffffffff813a61e4>] acpi_device_remove+0x90/0xb2
> [ 1015.844796]  [<ffffffff8143c2fc>] __device_release_driver+0x7c/0xf0
> [ 1015.919814]  [<ffffffff8143c47f>] device_release_driver+0x2f/0x50
> [ 1015.992753]  [<ffffffff813a70dc>] acpi_bus_remove+0x32/0x6d
> [ 1016.059462]  [<ffffffff813a71a8>] acpi_bus_trim+0x91/0x102
> [ 1016.125128]  [<ffffffff813a72a1>] 
> acpi_bus_hot_remove_device+0x88/0x16b
> [ 1016.204295]  [<ffffffff813a2e57>] acpi_os_execute_deferred+0x27/0x34
> [ 1016.280350]  [<ffffffff81090599>] process_one_work+0x219/0x680
> [ 1016.350173]  [<ffffffff81090538>] ? process_one_work+0x1b8/0x680
> [ 1016.422072]  [<ffffffff813a2e30>] ? 
> acpi_os_wait_events_complete+0x23/0x23
> [ 1016.504357]  [<ffffffff810923ce>] worker_thread+0x12e/0x320
> [ 1016.571064]  [<ffffffff810922a0>] ? manage_workers+0x110/0x110
> [ 1016.640886]  [<ffffffff810983a6>] kthread+0xc6/0xd0
> [ 1016.699290]  [<ffffffff8167b144>] kernel_thread_helper+0x4/0x10
> [ 1016.770149]  [<ffffffff81670bb0>] ? retint_restore_args+0x13/0x13
> [ 1016.843165]  [<ffffffff810982e0>] ? __init_kthread_worker+0x70/0x70
> [ 1016.918200]  [<ffffffff8167b140>] ? gs_change+0x13/0x13
>
> Thanks,
> Yasuaki Ishimatsu
>
>>
>> static void
>> unregister_memory(struct memory_block *memory)
>> {
>>     BUG_ON(memory->dev.bus != &memory_subsys);
>>
>>     /* drop the ref. we got in remove_memory_block() */
>>     kobject_put(&memory->dev.kobj);
>>     device_unregister(&memory->dev);
>> }
>>
>
>
>


  reply	other threads:[~2012-09-28  6:04 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-27  5:45 [PATCH 0/4] bugfix for memory hotplug wency
2012-09-27  5:45 ` wency
2012-09-27  5:45 ` [PATCH 1/4] memory-hotplug: add memory_block_release wency
2012-09-27  5:45   ` wency
2012-09-27 10:20   ` Ni zhan Chen
2012-09-28  0:24     ` Yasuaki Ishimatsu
2012-09-28  0:24       ` Yasuaki Ishimatsu
2012-09-28  1:35       ` KOSAKI Motohiro
2012-09-28  1:35         ` KOSAKI Motohiro
2012-09-28  3:45         ` Yasuaki Ishimatsu
2012-09-28  3:45           ` Yasuaki Ishimatsu
2012-09-28  6:04           ` Ni zhan Chen [this message]
2012-09-28  6:04             ` Ni zhan Chen
2012-09-28  6:11             ` Yasuaki Ishimatsu
2012-09-28  6:11               ` Yasuaki Ishimatsu
2012-09-28  6:14           ` Ni zhan Chen
2012-09-28  6:14             ` Ni zhan Chen
2012-09-28 22:30           ` KOSAKI Motohiro
2012-09-28 22:30             ` KOSAKI Motohiro
2012-09-27 20:11   ` KOSAKI Motohiro
2012-09-27 20:11     ` KOSAKI Motohiro
2012-09-27  5:45 ` [PATCH 2/4] memory-hotplug: add node_device_release wency
2012-09-27  5:45   ` wency
2012-09-27 10:38   ` Ni zhan Chen
2012-09-27 10:38     ` Ni zhan Chen
2012-09-27 20:13   ` KOSAKI Motohiro
2012-09-27 20:13     ` KOSAKI Motohiro
2012-09-28  0:07     ` Yasuaki Ishimatsu
2012-09-28  0:07       ` Yasuaki Ishimatsu
2012-09-28  1:13       ` KOSAKI Motohiro
2012-09-28  1:13         ` KOSAKI Motohiro
2012-09-28  1:30         ` Yasuaki Ishimatsu
2012-09-28  1:30           ` Yasuaki Ishimatsu
2012-09-28  1:37           ` KOSAKI Motohiro
2012-09-28  1:37             ` KOSAKI Motohiro
2012-09-28  9:55             ` Yasuaki Ishimatsu
2012-09-28  9:55               ` Yasuaki Ishimatsu
2012-09-28 22:19               ` KOSAKI Motohiro
2012-09-28 22:19                 ` KOSAKI Motohiro
2012-10-01  6:54                 ` Yasuaki Ishimatsu
2012-10-01  6:54                   ` Yasuaki Ishimatsu
2012-10-01 18:12                   ` KOSAKI Motohiro
2012-10-01 18:12                     ` KOSAKI Motohiro
2012-10-05  1:00                     ` Yasuaki Ishimatsu
2012-10-05  1:00                       ` Yasuaki Ishimatsu
2012-10-05 18:39                       ` KOSAKI Motohiro
2012-10-05 18:39                         ` KOSAKI Motohiro
2012-09-27  5:45 ` [PATCH 3/4] memory-hotplug: clear hwpoisoned flag when onlining pages wency
2012-09-27  5:45   ` wency
2012-09-27 12:27   ` Ni zhan Chen
2012-09-27 12:27     ` Ni zhan Chen
2012-09-27 20:17   ` KOSAKI Motohiro
2012-09-27 20:17     ` KOSAKI Motohiro
2012-09-28  1:53     ` Wen Congyang
2012-09-28  1:53       ` Wen Congyang
2012-09-27  5:45 ` [PATCH 4/4] memory-hotplug: auto offline page_cgroup when onlining memory block failed wency
2012-09-27  5:45   ` wency
2012-09-27 12:44   ` Ni zhan Chen
2012-09-27 12:44     ` Ni zhan Chen
2012-09-27 20:19   ` KOSAKI Motohiro
2012-09-27 20:19     ` KOSAKI Motohiro
2012-09-27 21:18 ` [PATCH 0/4] bugfix for memory hotplug Andrew Morton
2012-09-27 21:18   ` Andrew Morton
2012-09-29  2:31 ` Ni zhan Chen
2012-09-29  2:31   ` Ni zhan Chen

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=50653DE7.70702@gmail.com \
    --to=nizhan.chen@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liuj97@gmail.com \
    --cc=minchan.kim@gmail.com \
    --cc=paulus@samba.org \
    --cc=rientjes@google.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.