Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1605091 > unrolled thread

memory hotplug and force_remove

Back to article view | Back to linux.kernel

Contents

  memory hotplug and force_remove Michal Hocko <mhocko@kernel.org> - 2017-03-20 20:40 +0100
    Re: memory hotplug and force_remove "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-20 22:40 +0100
      Re: memory hotplug and force_remove joeyli <jlee@suse.com> - 2017-03-21 17:20 +0100

#1605091 — memory hotplug and force_remove

Hi Rafael,
we have been chasing the following BUG() triggering during the memory
hotremove (remove_memory):
	ret = walk_memory_range(PFN_DOWN(start), PFN_UP(start + size - 1), NULL,
				check_memblock_offlined_cb);
	if (ret)
		BUG();

and it took a while to learn that the issue is caused by
/sys/firmware/acpi/hotplug/force_remove being enabled. I was really
surprised to see such an option because at least for the memory hotplug
it cannot work at all. Memory hotplug fails when the memory is still
in use. Even if we do not BUG() here enforcing the hotplug operation
will lead to problematic behavior later like crash or a silent memory
corruption if the memory gets onlined back and reused by somebody else.

I am wondering what was the motivation for introducing this behavior and
whether there is a way to disallow it for memory hotplug. Or maybe drop
it completely. What would break in such a case?

Thanks!
-- 
Michal Hocko
SUSE Labs

[toc] | [next] | [standalone]

#1605137

On Monday, March 20, 2017 03:29:39 PM Michal Hocko wrote:
> Hi Rafael,

Hi,

> we have been chasing the following BUG() triggering during the memory
> hotremove (remove_memory):
> 	ret = walk_memory_range(PFN_DOWN(start), PFN_UP(start + size - 1), NULL,
> 				check_memblock_offlined_cb);
> 	if (ret)
> 		BUG();
> 
> and it took a while to learn that the issue is caused by
> /sys/firmware/acpi/hotplug/force_remove being enabled. I was really
> surprised to see such an option because at least for the memory hotplug
> it cannot work at all. Memory hotplug fails when the memory is still
> in use. Even if we do not BUG() here enforcing the hotplug operation
> will lead to problematic behavior later like crash or a silent memory
> corruption if the memory gets onlined back and reused by somebody else.
> 
> I am wondering what was the motivation for introducing this behavior and
> whether there is a way to disallow it for memory hotplug. Or maybe drop
> it completely. What would break in such a case?

Honestly, I don't remember from the top of my head and I haven't looked at
that code for several months.

I need some time to recall that.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1605770

On Mon, Mar 20, 2017 at 10:24:42PM +0100, Rafael J. Wysocki wrote:
> On Monday, March 20, 2017 03:29:39 PM Michal Hocko wrote:
> > Hi Rafael,
> 
> Hi,
> 
> > we have been chasing the following BUG() triggering during the memory
> > hotremove (remove_memory):
> > 	ret = walk_memory_range(PFN_DOWN(start), PFN_UP(start + size - 1), NULL,
> > 				check_memblock_offlined_cb);
> > 	if (ret)
> > 		BUG();
> > 
> > and it took a while to learn that the issue is caused by
> > /sys/firmware/acpi/hotplug/force_remove being enabled. I was really
> > surprised to see such an option because at least for the memory hotplug
> > it cannot work at all. Memory hotplug fails when the memory is still
> > in use. Even if we do not BUG() here enforcing the hotplug operation
> > will lead to problematic behavior later like crash or a silent memory
> > corruption if the memory gets onlined back and reused by somebody else.
> > 
> > I am wondering what was the motivation for introducing this behavior and
> > whether there is a way to disallow it for memory hotplug. Or maybe drop
> > it completely. What would break in such a case?
> 
> Honestly, I don't remember from the top of my head and I haven't looked at
> that code for several months.
> 
> I need some time to recall that.
>

IMHO. 
In the second pass offline in acpi_scan_try_to_offline(), when force_remove flag
enabled, it's still run offline on the parent device even there have any child
device offline failed. And it doesn't return the error from acpi_bus_offline() to
caller. 

	errdev = NULL;
	acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX, 
			    NULL, acpi_bus_offline, (void *)true,
			    (void **)&errdev);
	if (!errdev || acpi_force_hot_remove)                 
		acpi_bus_offline(handle, 0, (void *)true, 
				 (void **)&errdev);

In this situation, the parent device or any child device may not really
offline successfully. But acpi_scan_hot_remove, the caller doesn't know that.
Then it cause the later acpi_bus_trim() process failed.

acpi_bus_trim()
	-> handler->detach()
		-> acpi_memory_device_remove()
			-> remove_memory() -> BUG()  

because some memory doesn't really offline. 

Thanks a lot!
Joey Lee

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web