From: Xishi Qiu <qiuxishi@huawei.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Reza Arbab <arbab@linux.vnet.ibm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
David Rientjes <rientjes@google.com>,
Yaowei Bai <baiyaowei@cmss.chinamobile.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Dan Williams <dan.j.williams@intel.com>,
David Vrabel <david.vrabel@citrix.com>,
Chen Yucong <slaoub@gmail.com>, Andrew Banman <abanman@sgi.com>,
Seth Jennings <sjenning@redhat.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] memory-hotplug: fix store_mem_state() return value
Date: Fri, 2 Sep 2016 09:34:23 +0800 [thread overview]
Message-ID: <57C8D71F.1080803@huawei.com> (raw)
In-Reply-To: <20160901133717.8d753013cfbb640dd28c2783@linux-foundation.org>
On 2016/9/2 4:37, Andrew Morton wrote:
> On Thu, 1 Sep 2016 10:29:37 -0500 Reza Arbab <arbab@linux.vnet.ibm.com> wrote:
>
>> If store_mem_state() is called to online memory which is already online,
>> it will return 1, the value it got from device_online().
>>
>> This is wrong because store_mem_state() is a device_attribute .store
>> function. Thus a non-negative return value represents input bytes read.
>>
>> Set the return value to -EINVAL in this case.
>>
>
> I actually made the mistake of reading this code.
>
> What the heck are the return value semantics of bus_type.online?
> Sometimes 0, sometimes 1 and apparently sometimes -Efoo values. What
> are these things trying to tell the caller and why is "1" ever useful
> and why doesn't anyone document anything. grr.
>
> And now I don't understand this patch. Because:
>
> static int memory_subsys_online(struct device *dev)
> {
> struct memory_block *mem = to_memory_block(dev);
> int ret;
>
> if (mem->state == MEM_ONLINE)
> return 0;
>
I think we will not execute here, it will return from device_online(),
because "if (dev->offline)" is false and return 1.
But the two return vaules are different if we do online-to-online.
memory_subsys_online() return 0, and device_online() return 1,
this is a little confusion.
When device_online() return 1, online_store() return 1 and store_mem_state()
return -EINVAL even without this patch, as Reza described in v2.
1. store_mem_state() called with buf="online"
2. device_online() returns 1 because device is already online
3. store_mem_state() returns 1
4. calling code interprets this as 1-byte buffer read
5. store_mem_state() called again with buf="nline"
6. store_mem_state() returns -EINVAL
Thanks,
Xishi Qiu
> Doesn't that "return 0" contradict the changelog?
>
> Also, is store_mem_state() the correct place to fix this? Instead,
> should memory_block_change_state() detect an attempt to online
> already-online memory and itself return -EINVAL, and permit that to be
> propagated back? Well, that depends on the bus_type.online rules which
> appear to be undocumented. What is the bus implementation supposed to
> do when a request is made to online an already-online device?
>
>
>
> .
>
--
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: Xishi Qiu <qiuxishi@huawei.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Reza Arbab <arbab@linux.vnet.ibm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
"Vitaly Kuznetsov" <vkuznets@redhat.com>,
David Rientjes <rientjes@google.com>,
"Yaowei Bai" <baiyaowei@cmss.chinamobile.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Dan Williams <dan.j.williams@intel.com>,
David Vrabel <david.vrabel@citrix.com>,
Chen Yucong <slaoub@gmail.com>, Andrew Banman <abanman@sgi.com>,
Seth Jennings <sjenning@redhat.com>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] memory-hotplug: fix store_mem_state() return value
Date: Fri, 2 Sep 2016 09:34:23 +0800 [thread overview]
Message-ID: <57C8D71F.1080803@huawei.com> (raw)
In-Reply-To: <20160901133717.8d753013cfbb640dd28c2783@linux-foundation.org>
On 2016/9/2 4:37, Andrew Morton wrote:
> On Thu, 1 Sep 2016 10:29:37 -0500 Reza Arbab <arbab@linux.vnet.ibm.com> wrote:
>
>> If store_mem_state() is called to online memory which is already online,
>> it will return 1, the value it got from device_online().
>>
>> This is wrong because store_mem_state() is a device_attribute .store
>> function. Thus a non-negative return value represents input bytes read.
>>
>> Set the return value to -EINVAL in this case.
>>
>
> I actually made the mistake of reading this code.
>
> What the heck are the return value semantics of bus_type.online?
> Sometimes 0, sometimes 1 and apparently sometimes -Efoo values. What
> are these things trying to tell the caller and why is "1" ever useful
> and why doesn't anyone document anything. grr.
>
> And now I don't understand this patch. Because:
>
> static int memory_subsys_online(struct device *dev)
> {
> struct memory_block *mem = to_memory_block(dev);
> int ret;
>
> if (mem->state == MEM_ONLINE)
> return 0;
>
I think we will not execute here, it will return from device_online(),
because "if (dev->offline)" is false and return 1.
But the two return vaules are different if we do online-to-online.
memory_subsys_online() return 0, and device_online() return 1,
this is a little confusion.
When device_online() return 1, online_store() return 1 and store_mem_state()
return -EINVAL even without this patch, as Reza described in v2.
1. store_mem_state() called with buf="online"
2. device_online() returns 1 because device is already online
3. store_mem_state() returns 1
4. calling code interprets this as 1-byte buffer read
5. store_mem_state() called again with buf="nline"
6. store_mem_state() returns -EINVAL
Thanks,
Xishi Qiu
> Doesn't that "return 0" contradict the changelog?
>
> Also, is store_mem_state() the correct place to fix this? Instead,
> should memory_block_change_state() detect an attempt to online
> already-online memory and itself return -EINVAL, and permit that to be
> propagated back? Well, that depends on the bus_type.online rules which
> appear to be undocumented. What is the bus implementation supposed to
> do when a request is made to online an already-online device?
>
>
>
> .
>
next prev parent reply other threads:[~2016-09-02 1:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-01 15:29 [PATCH v3] memory-hotplug: fix store_mem_state() return value Reza Arbab
2016-09-01 15:29 ` Reza Arbab
2016-09-01 20:37 ` Andrew Morton
2016-09-01 20:37 ` Andrew Morton
2016-09-01 21:45 ` Reza Arbab
2016-09-01 21:45 ` Reza Arbab
2016-09-02 1:34 ` Xishi Qiu [this message]
2016-09-02 1:34 ` Xishi Qiu
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=57C8D71F.1080803@huawei.com \
--to=qiuxishi@huawei.com \
--cc=abanman@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=arbab@linux.vnet.ibm.com \
--cc=baiyaowei@cmss.chinamobile.com \
--cc=dan.j.williams@intel.com \
--cc=david.vrabel@citrix.com \
--cc=gregkh@linuxfoundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=sjenning@redhat.com \
--cc=slaoub@gmail.com \
--cc=vbabka@suse.cz \
--cc=vkuznets@redhat.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.