All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Tang Chen <tangchen@cn.fujitsu.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	Xishi Qiu <qiuxishi@huawei.com>,
	Sheng Yong <shengyong1@huawei.com>,
	David Rientjes <rientjes@google.com>,
	Zhu Guihua <zhugh.fnst@cn.fujitsu.com>,
	Dan Williams <dan.j.williams@intel.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Igor Mammedov <imammedo@redhat.com>
Subject: Re: [PATCH] memory-hotplug: don't BUG() in register_memory_resource()
Date: Mon, 21 Dec 2015 11:13:15 +0100	[thread overview]
Message-ID: <8737uwt8hw.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20151218145022.eae1e368c82f090900582fcc@linux-foundation.org> (Andrew Morton's message of "Fri, 18 Dec 2015 14:50:22 -0800")

Andrew Morton <akpm@linux-foundation.org> writes:

> On Fri, 18 Dec 2015 15:50:24 +0100 Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
>
>> Out of memory condition is not a bug and while we can't add new memory in
>> such case crashing the system seems wrong. Propagating the return value
>> from register_memory_resource() requires interface change.
>> 
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> +static int register_memory_resource(u64 start, u64 size,
>> +				    struct resource **resource)
>>  {
>>  	struct resource *res;
>>  	res = kzalloc(sizeof(struct resource), GFP_KERNEL);
>> -	BUG_ON(!res);
>> +	if (!res)
>> +		return -ENOMEM;
>>  
>>  	res->name = "System RAM";
>>  	res->start = start;
>> @@ -140,9 +142,10 @@ static struct resource *register_memory_resource(u64 start, u64 size)
>>  	if (request_resource(&iomem_resource, res) < 0) {
>>  		pr_debug("System RAM resource %pR cannot be added\n", res);
>>  		kfree(res);
>> -		res = NULL;
>> +		return -EEXIST;
>>  	}
>> -	return res;
>> +	*resource = res;
>> +	return 0;
>>  }
>
> Was there a reason for overwriting the request_resource() return
> value?
> Ordinarily it should be propagated back to callers.
>
> Please review.
>

This is a nice-to-have addition but it will break at least ACPI
memhotplug: request_resource() has the following:

conflict = request_resource_conflict(root, new);
return conflict ? -EBUSY : 0;

so we'll end up returning -EBUSY from register_memory_resource() and
add_memory(), at the same time acpi_memory_enable_device() counts on
-EEXIST:

result = add_memory(node, info->start_addr, info->length);

/*
* If the memory block has been used by the kernel, add_memory()
* returns -EEXIST. If add_memory() returns the other error, it
* means that this memory block is not used by the kernel.
*/
if (result && result != -EEXIST)
continue;

So I see 3 options here:
1) Keep the overwrite
2) Change the request_resource() return value to -EEXIST
3) Adapt all add_memory() call sites to -EBUSY.

Please let me know your preference.

> --- a/mm/memory_hotplug.c~memory-hotplug-dont-bug-in-register_memory_resource-fix
> +++ a/mm/memory_hotplug.c
> @@ -131,7 +131,9 @@ static int register_memory_resource(u64
>  				    struct resource **resource)
>  {
>  	struct resource *res;
> +	int ret = 0;
>  	res = kzalloc(sizeof(struct resource), GFP_KERNEL);
> +
>  	if (!res)
>  		return -ENOMEM;
>
> @@ -139,13 +141,14 @@ static int register_memory_resource(u64
>  	res->start = start;
>  	res->end = start + size - 1;
>  	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> -	if (request_resource(&iomem_resource, res) < 0) {
> +	ret = request_resource(&iomem_resource, res);
> +	if (ret < 0) {
>  		pr_debug("System RAM resource %pR cannot be added\n", res);
>  		kfree(res);
> -		return -EEXIST;
> +	} else {
> +		*resource = res;
>  	}
> -	*resource = res;
> -	return 0;
> +	return ret;
>  }
>
>  static void release_memory_resource(struct resource *res)
> _

-- 
  Vitaly

--
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: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Tang Chen <tangchen@cn.fujitsu.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	Xishi Qiu <qiuxishi@huawei.com>,
	Sheng Yong <shengyong1@huawei.com>,
	David Rientjes <rientjes@google.com>,
	Zhu Guihua <zhugh.fnst@cn.fujitsu.com>,
	Dan Williams <dan.j.williams@intel.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Igor Mammedov <imammedo@redhat.com>
Subject: Re: [PATCH] memory-hotplug: don't BUG() in register_memory_resource()
Date: Mon, 21 Dec 2015 11:13:15 +0100	[thread overview]
Message-ID: <8737uwt8hw.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20151218145022.eae1e368c82f090900582fcc@linux-foundation.org> (Andrew Morton's message of "Fri, 18 Dec 2015 14:50:22 -0800")

Andrew Morton <akpm@linux-foundation.org> writes:

> On Fri, 18 Dec 2015 15:50:24 +0100 Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
>
>> Out of memory condition is not a bug and while we can't add new memory in
>> such case crashing the system seems wrong. Propagating the return value
>> from register_memory_resource() requires interface change.
>> 
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> +static int register_memory_resource(u64 start, u64 size,
>> +				    struct resource **resource)
>>  {
>>  	struct resource *res;
>>  	res = kzalloc(sizeof(struct resource), GFP_KERNEL);
>> -	BUG_ON(!res);
>> +	if (!res)
>> +		return -ENOMEM;
>>  
>>  	res->name = "System RAM";
>>  	res->start = start;
>> @@ -140,9 +142,10 @@ static struct resource *register_memory_resource(u64 start, u64 size)
>>  	if (request_resource(&iomem_resource, res) < 0) {
>>  		pr_debug("System RAM resource %pR cannot be added\n", res);
>>  		kfree(res);
>> -		res = NULL;
>> +		return -EEXIST;
>>  	}
>> -	return res;
>> +	*resource = res;
>> +	return 0;
>>  }
>
> Was there a reason for overwriting the request_resource() return
> value?
> Ordinarily it should be propagated back to callers.
>
> Please review.
>

This is a nice-to-have addition but it will break at least ACPI
memhotplug: request_resource() has the following:

conflict = request_resource_conflict(root, new);
return conflict ? -EBUSY : 0;

so we'll end up returning -EBUSY from register_memory_resource() and
add_memory(), at the same time acpi_memory_enable_device() counts on
-EEXIST:

result = add_memory(node, info->start_addr, info->length);

/*
* If the memory block has been used by the kernel, add_memory()
* returns -EEXIST. If add_memory() returns the other error, it
* means that this memory block is not used by the kernel.
*/
if (result && result != -EEXIST)
continue;

So I see 3 options here:
1) Keep the overwrite
2) Change the request_resource() return value to -EEXIST
3) Adapt all add_memory() call sites to -EBUSY.

Please let me know your preference.

> --- a/mm/memory_hotplug.c~memory-hotplug-dont-bug-in-register_memory_resource-fix
> +++ a/mm/memory_hotplug.c
> @@ -131,7 +131,9 @@ static int register_memory_resource(u64
>  				    struct resource **resource)
>  {
>  	struct resource *res;
> +	int ret = 0;
>  	res = kzalloc(sizeof(struct resource), GFP_KERNEL);
> +
>  	if (!res)
>  		return -ENOMEM;
>
> @@ -139,13 +141,14 @@ static int register_memory_resource(u64
>  	res->start = start;
>  	res->end = start + size - 1;
>  	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> -	if (request_resource(&iomem_resource, res) < 0) {
> +	ret = request_resource(&iomem_resource, res);
> +	if (ret < 0) {
>  		pr_debug("System RAM resource %pR cannot be added\n", res);
>  		kfree(res);
> -		return -EEXIST;
> +	} else {
> +		*resource = res;
>  	}
> -	*resource = res;
> -	return 0;
> +	return ret;
>  }
>
>  static void release_memory_resource(struct resource *res)
> _

-- 
  Vitaly

  reply	other threads:[~2015-12-21 10:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-18 14:50 [PATCH] memory-hotplug: don't BUG() in register_memory_resource() Vitaly Kuznetsov
2015-12-18 14:50 ` Vitaly Kuznetsov
2015-12-18 16:33 ` Igor Mammedov
2015-12-18 16:33   ` Igor Mammedov
2015-12-18 22:50 ` Andrew Morton
2015-12-18 22:50   ` Andrew Morton
2015-12-21 10:13   ` Vitaly Kuznetsov [this message]
2015-12-21 10:13     ` Vitaly Kuznetsov
2015-12-21 23:06     ` Andrew Morton
2015-12-21 23:06       ` Andrew Morton
2015-12-22 21:56 ` David Rientjes
2015-12-22 21:56   ` David Rientjes

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=8737uwt8hw.fsf@vitty.brq.redhat.com \
    --to=vkuznets@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=david.vrabel@citrix.com \
    --cc=imammedo@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=qiuxishi@huawei.com \
    --cc=rientjes@google.com \
    --cc=shengyong1@huawei.com \
    --cc=tangchen@cn.fujitsu.com \
    --cc=zhugh.fnst@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.