From: Toshi Kani <toshi.kani@hp.com> To: Dave Hansen <dave.hansen@intel.com> Cc: Dave Hansen <dave@sr71.net>, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org, isimatu.yasuaki@jp.fujitsu.com, tangchen@cn.fujitsu.com, vasilis.liaskovitis@profitbricks.com Subject: Re: [PATCH] mm/hotplug, x86: Disable ARCH_MEMORY_PROBE by default Date: Thu, 18 Jul 2013 15:38:16 -0600 [thread overview] Message-ID: <1374183496.24916.170.camel@misato.fc.hp.com> (raw) In-Reply-To: <51E85016.2090403@intel.com> On Thu, 2013-07-18 at 13:29 -0700, Dave Hansen wrote: > On 07/18/2013 01:10 PM, Toshi Kani wrote: > > On Thu, 2013-07-18 at 11:34 -0700, Dave Hansen wrote: > > I do not think so. Using echo command to write a value to /dev/sda is > > not how it is instructed to use in the document. I am not saying that > > we need to protect from a privileged user doing something crazy. > > If the document is the issue, then let's fix the document. I will clarify the document as well. > >> All that I'm asking is that you either leave it the way it is, or make a > >> Kconfig menu entry for it. > >> > >> But, really, what's the problem that you're solving? Has this caused > >> you issues somehow? It's been there for, what, 10 years? Surely it's > >> part of the ABI. > > > > The problem is that the probe interface is documented as one of the > > steps that may be necessary for memory hotplug. A typical user may or > > may not know if his/her platform generates a hotplug notification to the > > kernel to decide if this step is necessary. > > A typical user will never see any of this stuff. It's buried deep under > the covers. Users will need to use sysfs "memoryX/online" interface to online hot-added memory, which is located in the same directory as "probe". The name "probe" is also misleading that one would expect it checks if a given memory address is present on the system. > > If the user performs this > > step on x86, it will likely mess up the system. Since we do not need it > > on x86, a prudent approach to protect such user is to disable or remove > > the interface on x86 and document it accordingly. We have not seen this > > issue yet because we do not have many platforms that support memory > > hotplug today. Once memory hotplug support in KVM gets merged into the > > mainline, anyone can start using this feature on their systems. At that > > time, their choice of a stable kernel may be 3.12.x. This interface has > > been there for while, but we need to fix it before the memory hotplug > > feature becomes available for everyone. > > It sounds like you're arguing that anyone using memory hotplug on x86 > might be confused by the probe file. There's been a lot of hardware out > there that's supported memory hotplug for many, many years. I've never > heard a complaint about it in practice. Are KVM users more apt to be > confused than folks running on bare-metal? :) I know ia64 (which Kconfig does not have this option) and powerpc (which this interface is required, but I believe it is well-automated by LPAR mgmt tools) platforms support memory hotplug for many years, but I did not know it is also the case with x86 platforms. The fact that ia64 does not have this interface makes me wonder why we enabled it on x86. > > Does it make sense? I understand that you are using this interface for > > your testing. If I make a Kconfig menu entry, are you OK to disable > > this option by default? > > I kinda wish you wouldn't mess with it. But, sure, put it in the memory > debugging, and make sure it stays enabled on powerpc by default. I understand and I appreciate your flexibility. Since it is defined in x86/Kconfig, the prompt will be under "Processor type and features". Yes, it stays enabled on powerpc as I won't touch powerpc/Kconfig. > Another method would be to just change the default permissions of the > file on x86 instead of disabling it completely: > > # chmod u-w /sys/devices/system/memory/probe > # echo x > /sys/devices/system/memory/probe > bash: /sys/devices/system/memory/probe: Permission denied > > That way folks can re-chmod it if they *really* want it back (me), and > they can still use it for testing. That's an interesting idea, but I'd prefer not to introduce #ifdef to the common code for this. Thanks, -Toshi
WARNING: multiple messages have this Message-ID (diff)
From: Toshi Kani <toshi.kani@hp.com> To: Dave Hansen <dave.hansen@intel.com> Cc: Dave Hansen <dave@sr71.net>, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org, isimatu.yasuaki@jp.fujitsu.com, tangchen@cn.fujitsu.com, vasilis.liaskovitis@profitbricks.com Subject: Re: [PATCH] mm/hotplug, x86: Disable ARCH_MEMORY_PROBE by default Date: Thu, 18 Jul 2013 15:38:16 -0600 [thread overview] Message-ID: <1374183496.24916.170.camel@misato.fc.hp.com> (raw) In-Reply-To: <51E85016.2090403@intel.com> On Thu, 2013-07-18 at 13:29 -0700, Dave Hansen wrote: > On 07/18/2013 01:10 PM, Toshi Kani wrote: > > On Thu, 2013-07-18 at 11:34 -0700, Dave Hansen wrote: > > I do not think so. Using echo command to write a value to /dev/sda is > > not how it is instructed to use in the document. I am not saying that > > we need to protect from a privileged user doing something crazy. > > If the document is the issue, then let's fix the document. I will clarify the document as well. > >> All that I'm asking is that you either leave it the way it is, or make a > >> Kconfig menu entry for it. > >> > >> But, really, what's the problem that you're solving? Has this caused > >> you issues somehow? It's been there for, what, 10 years? Surely it's > >> part of the ABI. > > > > The problem is that the probe interface is documented as one of the > > steps that may be necessary for memory hotplug. A typical user may or > > may not know if his/her platform generates a hotplug notification to the > > kernel to decide if this step is necessary. > > A typical user will never see any of this stuff. It's buried deep under > the covers. Users will need to use sysfs "memoryX/online" interface to online hot-added memory, which is located in the same directory as "probe". The name "probe" is also misleading that one would expect it checks if a given memory address is present on the system. > > If the user performs this > > step on x86, it will likely mess up the system. Since we do not need it > > on x86, a prudent approach to protect such user is to disable or remove > > the interface on x86 and document it accordingly. We have not seen this > > issue yet because we do not have many platforms that support memory > > hotplug today. Once memory hotplug support in KVM gets merged into the > > mainline, anyone can start using this feature on their systems. At that > > time, their choice of a stable kernel may be 3.12.x. This interface has > > been there for while, but we need to fix it before the memory hotplug > > feature becomes available for everyone. > > It sounds like you're arguing that anyone using memory hotplug on x86 > might be confused by the probe file. There's been a lot of hardware out > there that's supported memory hotplug for many, many years. I've never > heard a complaint about it in practice. Are KVM users more apt to be > confused than folks running on bare-metal? :) I know ia64 (which Kconfig does not have this option) and powerpc (which this interface is required, but I believe it is well-automated by LPAR mgmt tools) platforms support memory hotplug for many years, but I did not know it is also the case with x86 platforms. The fact that ia64 does not have this interface makes me wonder why we enabled it on x86. > > Does it make sense? I understand that you are using this interface for > > your testing. If I make a Kconfig menu entry, are you OK to disable > > this option by default? > > I kinda wish you wouldn't mess with it. But, sure, put it in the memory > debugging, and make sure it stays enabled on powerpc by default. I understand and I appreciate your flexibility. Since it is defined in x86/Kconfig, the prompt will be under "Processor type and features". Yes, it stays enabled on powerpc as I won't touch powerpc/Kconfig. > Another method would be to just change the default permissions of the > file on x86 instead of disabling it completely: > > # chmod u-w /sys/devices/system/memory/probe > # echo x > /sys/devices/system/memory/probe > bash: /sys/devices/system/memory/probe: Permission denied > > That way folks can re-chmod it if they *really* want it back (me), and > they can still use it for testing. That's an interesting idea, but I'd prefer not to introduce #ifdef to the common code for this. Thanks, -Toshi -- 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>
next prev parent reply other threads:[~2013-07-18 21:39 UTC|newest] Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-17 21:45 [PATCH] mm/hotplug, x86: Disable ARCH_MEMORY_PROBE by default Toshi Kani 2013-07-17 21:45 ` Toshi Kani 2013-07-17 23:22 ` KOSAKI Motohiro 2013-07-17 23:22 ` KOSAKI Motohiro 2013-07-17 23:29 ` Toshi Kani 2013-07-17 23:29 ` Toshi Kani 2013-07-17 23:33 ` KOSAKI Motohiro 2013-07-17 23:33 ` KOSAKI Motohiro 2013-07-17 23:51 ` Toshi Kani 2013-07-17 23:51 ` Toshi Kani 2013-07-18 0:24 ` KOSAKI Motohiro 2013-07-18 0:24 ` KOSAKI Motohiro 2013-07-18 0:30 ` Toshi Kani 2013-07-18 0:30 ` Toshi Kani 2013-07-19 17:56 ` Toshi Kani 2013-07-19 17:56 ` Toshi Kani 2013-07-18 1:48 ` Yasuaki Ishimatsu 2013-07-18 16:02 ` Toshi Kani 2013-07-18 16:02 ` Toshi Kani 2013-07-18 15:27 ` Dave Hansen 2013-07-18 15:27 ` Dave Hansen 2013-07-18 16:26 ` Toshi Kani 2013-07-18 16:26 ` Toshi Kani 2013-07-18 18:34 ` Dave Hansen 2013-07-18 18:34 ` Dave Hansen 2013-07-18 20:10 ` Toshi Kani 2013-07-18 20:10 ` Toshi Kani 2013-07-18 20:29 ` Dave Hansen 2013-07-18 20:29 ` Dave Hansen 2013-07-18 21:38 ` Toshi Kani [this message] 2013-07-18 21:38 ` Toshi Kani
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=1374183496.24916.170.camel@misato.fc.hp.com \ --to=toshi.kani@hp.com \ --cc=akpm@linux-foundation.org \ --cc=dave.hansen@intel.com \ --cc=dave@sr71.net \ --cc=isimatu.yasuaki@jp.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=tangchen@cn.fujitsu.com \ --cc=vasilis.liaskovitis@profitbricks.com \ --cc=x86@kernel.org \ /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: linkBe 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.