[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1608311722080.24833@chino.kir.corp.google.com>
Date: Wed, 31 Aug 2016 17:28:26 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Reza Arbab <arbab@...ux.vnet.ibm.com>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Vlastimil Babka <vbabka@...e.cz>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Yaowei Bai <baiyaowei@...s.chinamobile.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Dan Williams <dan.j.williams@...el.com>,
Xishi Qiu <qiuxishi@...wei.com>,
David Vrabel <david.vrabel@...rix.com>,
Chen Yucong <slaoub@...il.com>,
Andrew Banman <abanman@....com>,
Seth Jennings <sjenning@...hat.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH v2] memory-hotplug: fix store_mem_state() return
value
On Wed, 31 Aug 2016, Reza Arbab wrote:
> > Nope, the return value of changing state from online to online was
> > established almost 11 years ago in commit 3947be1969a9.
>
> Fair enough. So if online-to-online is -EINVAL,
online-to-online for state is -EINVAL, it has been since 2005.
> 1. Shouldn't 'echo 1 > online' then also return -EINVAL?
>
No, it's a different tunable. There's no requirement that two different
tunables that do a similar thing have the same return values: the former
existed long before device_online() and still exists for backwards
compatibility.
> 2. store_mem_state() still needs a tweak, right? It was only returning -EINVAL
> by accident, due to the convoluted sequence I listed in the patch.
>
Yes, absolutely. It returning -EINVAL for "nline" is what is accidently
preserving it's backwards compatibility :) Note that device_online()
returns 1 if already online and memory_subsys_online() returns 0 if online
in this case. So we want store_mem_state() to return -EINVAL if
device_online() returns non-zero (this was in my first email).
Powered by blists - more mailing lists