* Re: ["RFC PATCH" 2/2] powerpc/mm: Conslidate numa_enable check and min_common_depth check
From: Vaibhav Jain @ 2019-06-29 15:39 UTC (permalink / raw)
To: Aneesh Kumar K.V, npiggin, paulus, mpe; +Cc: Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20190629083629.29037-2-aneesh.kumar@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> Update min_common_depth = -1 if numa is disabled. This
> help us to avoid checking for both in different code paths.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/mm/numa.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index f6d68baeaa96..c84062a390cc 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -212,7 +212,7 @@ static int associativity_to_nid(const __be32 *associativity)
> {
> int nid = NUMA_NO_NODE;
>
> - if (min_common_depth == -1 || !numa_enabled)
> + if (min_common_depth == -1)
> goto out;
>
> if (of_read_number(associativity, 1) >= min_common_depth)
> @@ -625,6 +625,7 @@ static int __init parse_numa_properties(void)
>
> if (numa_enabled == 0) {
> printk(KERN_WARNING "NUMA disabled by user\n");
> + min_common_depth = -1;
> return -1;
> }
I would prefer updating the definition of variable 'min_common_depth' to
static int min_common_depth = -1;
This would handle the case where someone calls 'associativity_to_nid()' and
other functions that read 'min_common_depth' and get an invalid result
back. And also handle the case where kernel is booted with 'numa = off'.
Also the init value 'min_common_depth == 0' indicates that the
first word in "ibm,associativity" array represents the node-id which is
wrong. Instead its the length of the "ibm,associativity" array.
>
> @@ -747,7 +748,7 @@ void __init dump_numa_cpu_topology(void)
> unsigned int node;
> unsigned int cpu, count;
>
> - if (min_common_depth == -1 || !numa_enabled)
> + if (min_common_depth == -1)
> return;
>
> for_each_online_node(node) {
> @@ -812,7 +813,7 @@ static void __init find_possible_nodes(void)
> struct device_node *rtas;
> u32 numnodes, i;
>
> - if (min_common_depth <= 0 || !numa_enabled)
> + if (min_common_depth <= 0)
> return;
>
> rtas = of_find_node_by_path("/rtas");
> @@ -1014,7 +1015,7 @@ int hot_add_scn_to_nid(unsigned long scn_addr)
> struct device_node *memory = NULL;
> int nid;
>
> - if (!numa_enabled || (min_common_depth < 0))
> + if (min_common_depth < 0)
> return first_online_node;
>
> memory = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
> --
> 2.21.0
>
--
Vaibhav Jain <vaibhav@linux.ibm.com>
Linux Technology Center, IBM India Pvt. Ltd.
^ permalink raw reply
* Re: ["RFC PATCH" 2/2] powerpc/mm: Conslidate numa_enable check and min_common_depth check
From: Aneesh Kumar K.V @ 2019-06-29 15:54 UTC (permalink / raw)
To: Vaibhav Jain, npiggin, paulus, mpe; +Cc: linuxppc-dev
In-Reply-To: <87imsos8n5.fsf@vajain21.in.ibm.com>
On 6/29/19 9:09 PM, Vaibhav Jain wrote:
> "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
>
>> Update min_common_depth = -1 if numa is disabled. This
>> help us to avoid checking for both in different code paths.
>>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>> ---
>> arch/powerpc/mm/numa.c | 9 +++++----
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
>> index f6d68baeaa96..c84062a390cc 100644
>> --- a/arch/powerpc/mm/numa.c
>> +++ b/arch/powerpc/mm/numa.c
>> @@ -212,7 +212,7 @@ static int associativity_to_nid(const __be32 *associativity)
>> {
>> int nid = NUMA_NO_NODE;
>>
>> - if (min_common_depth == -1 || !numa_enabled)
>> + if (min_common_depth == -1)
>> goto out;
>>
>> if (of_read_number(associativity, 1) >= min_common_depth)
>> @@ -625,6 +625,7 @@ static int __init parse_numa_properties(void)
>>
>> if (numa_enabled == 0) {
>> printk(KERN_WARNING "NUMA disabled by user\n");
>> + min_common_depth = -1;
>> return -1;
>> }
>
> I would prefer updating the definition of variable 'min_common_depth' to
>
> static int min_common_depth = -1;
>
> This would handle the case where someone calls 'associativity_to_nid()' and
> other functions that read 'min_common_depth' and get an invalid result
> back. And also handle the case where kernel is booted with 'numa = off'.
>
Sure. As mentioned in another email, I am wondering whether all that
min_common_depth check should be if !numa_enabled. That makes it much
easy to read. I will respin once i get more clarity on
of_drconf_to_nid_single usage.
> Also the init value 'min_common_depth == 0' indicates that the
> first word in "ibm,associativity" array represents the node-id which is
> wrong. Instead its the length of the "ibm,associativity" array.
>
-aneesh
^ permalink raw reply
* [PATCH v4 0/3] powerpc/papr_scm: Workaround for failure of drc bind after kexec
From: Vaibhav Jain @ 2019-06-29 16:06 UTC (permalink / raw)
To: linuxppc-dev
Cc: Aneesh Kumar K . V, Oliver O'Halloran, Vaibhav Jain,
Laurent Dufour, David Gibson
Presently an error is returned in response to hcall H_SCM_BIND_MEM when a
new kernel boots on lpar via kexec. This prevents papr_scm from registering
drc memory regions with nvdimm. The error reported is of the form below:
"papr_scm ibm,persistent-memory:ibm,pmemory@44100002: bind err: -68"
On investigation it was revealed that phyp returns this error as previous
kernel did not completely release bindings for drc scm-memory blocks and
hence phyp rejected request for re-binding these block to lpar with error
H_OVERLAP. Also support for a new H_SCM_UNBIND_ALL is recently added which
is better suited for releasing all the bound scm-memory block from an lpar.
So leveraging new hcall H_SCM_UNBIND_ALL, we can workaround H_OVERLAP issue
during kexec by forcing an unbind of all drm scm-memory blocks and issuing
H_SCM_BIND_MEM to re-bind the drc scm-memory blocks to lpar. This sequence
will also be needed when a new kernel boot on lpar after previous kernel
panicked and it never got an opportunity to call H_SCM_UNBIND_MEM/ALL.
Hence this patch-set implements following changes to papr_scm module:
* Update hvcall.h to include opcodes for new hcall H_SCM_UNBIND_ALL.
* Update it to use H_SCM_UNBIND_ALL instead of H_SCM_UNBIND_MEM
* In case hcall H_SCM_BIND_MEM fails with error H_OVERLAP, force
H_SCM_UNBIND_ALL and retry the bind operation again.
With the patch-set applied re-bind of drc scm-memory to lpar succeeds after
a kexec to new kernel as illustrated below:
# Old kernel
$ sudo ndctl list -R
[
{
"dev":"region0",
<snip>
....
}
]
# kexec to new kernel
$ sudo kexec --initrd=... vmlinux
...
...
I'm in purgatory
...
papr_scm ibm,persistent-memory:ibm,pmemory@44100002: Un-binding and retrying
...
# New kernel
$ sudo ndctl list -R
[
{
"dev":"region0",
<snip>
....
}
]
---
Change-log:
v4:
* Updated the patch description of first patch in the series as suggested
by Mpe.
v3:
* Fixed a build warning reported by kbuild test robot.
* Updated the hcall opcode from latest papr-scm specification.
* Fixed a minor code comment & patch description as pointed out by Oliver.
v2:
* Addressed review comments from Oliver on v1 patchset.
Vaibhav Jain (3):
powerpc/pseries: Update SCM hcall op-codes in hvcall.h
powerpc/papr_scm: Update drc_pmem_unbind() to use H_SCM_UNBIND_ALL
powerpc/papr_scm: Force a scm-unbind if initial scm-bind fails
arch/powerpc/include/asm/hvcall.h | 11 ++++--
arch/powerpc/platforms/pseries/papr_scm.c | 44 ++++++++++++++++++-----
2 files changed, 44 insertions(+), 11 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH v4 1/3] powerpc/pseries: Update SCM hcall op-codes in hvcall.h
From: Vaibhav Jain @ 2019-06-29 16:06 UTC (permalink / raw)
To: linuxppc-dev
Cc: Aneesh Kumar K . V, Oliver O'Halloran, Vaibhav Jain,
Laurent Dufour, David Gibson
In-Reply-To: <20190629160610.23402-1-vaibhav@linux.ibm.com>
Update the hvcalls.h to include op-codes for new hcalls introduce to
manage SCM memory. Also update existing hcall definitions to reflect
current papr specification for SCM.
The removed hcall op-codes H_SCM_MEM_QUERY, H_SCM_BLOCK_CLEAR were
transient proposals and there support was never implemented by
Power-VM nor they were used anywhere in Linux kernel. Hence we don't
expect anyone to be impacted by this change.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
Change-log:
v4:
* Updated the patch description mentioned current status of removed
hcall opcodes. [Mpe]
v3:
* Added updated opcode for H_SCM_HEALTH [Oliver]
v2:
* None new patch in this series.
---
arch/powerpc/include/asm/hvcall.h | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index 463c63a9fcf1..11112023e327 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -302,9 +302,14 @@
#define H_SCM_UNBIND_MEM 0x3F0
#define H_SCM_QUERY_BLOCK_MEM_BINDING 0x3F4
#define H_SCM_QUERY_LOGICAL_MEM_BINDING 0x3F8
-#define H_SCM_MEM_QUERY 0x3FC
-#define H_SCM_BLOCK_CLEAR 0x400
-#define MAX_HCALL_OPCODE H_SCM_BLOCK_CLEAR
+#define H_SCM_UNBIND_ALL 0x3FC
+#define H_SCM_HEALTH 0x400
+#define H_SCM_PERFORMANCE_STATS 0x418
+#define MAX_HCALL_OPCODE H_SCM_PERFORMANCE_STATS
+
+/* Scope args for H_SCM_UNBIND_ALL */
+#define H_UNBIND_SCOPE_ALL (0x1)
+#define H_UNBIND_SCOPE_DRC (0x2)
/* H_VIOCTL functions */
#define H_GET_VIOA_DUMP_SIZE 0x01
--
2.21.0
^ permalink raw reply related
* [PATCH v4 2/3] powerpc/papr_scm: Update drc_pmem_unbind() to use H_SCM_UNBIND_ALL
From: Vaibhav Jain @ 2019-06-29 16:06 UTC (permalink / raw)
To: linuxppc-dev
Cc: Aneesh Kumar K . V, Oliver O'Halloran, Vaibhav Jain,
Laurent Dufour, David Gibson
In-Reply-To: <20190629160610.23402-1-vaibhav@linux.ibm.com>
The new hcall named H_SCM_UNBIND_ALL has been introduce that can
unbind all or specific scm memory assigned to an lpar. This is
more efficient than using H_SCM_UNBIND_MEM as currently we don't
support partial unbind of scm memory.
Hence this patch proposes following changes to drc_pmem_unbind():
* Update drc_pmem_unbind() to replace hcall H_SCM_UNBIND_MEM to
H_SCM_UNBIND_ALL.
* Update drc_pmem_unbind() to handles cases when PHYP asks the guest
kernel to wait for specific amount of time before retrying the
hcall via the 'LONG_BUSY' return value.
* Ensure appropriate error code is returned back from the function
in case of an error.
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
Change-log:
v4:
* None. Re-spinning the patchset.
v3:
* Fixed a build warning reported by kbuild-robot.
* Updated patch description to put emphasis on 'scm memory' instead of
'scm drc memory blocks' as for phyp there is a stark difference
between how drc are managed for scm memory v/s regular memory. [Oliver]
v2:
* Added a dev_dbg when unbind operation succeeds [Oliver]
* Changed type of variable 'rc' to int64_t [Oliver]
* Removed the code that was logging a warning in case bind operation
takes >1-seconds [Oliver]
* Spinned off changes to hvcall.h as a separate patch. [Oliver]
---
arch/powerpc/platforms/pseries/papr_scm.c | 29 +++++++++++++++++------
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index 96c53b23e58f..c01a03fd3ee7 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -11,6 +11,7 @@
#include <linux/sched.h>
#include <linux/libnvdimm.h>
#include <linux/platform_device.h>
+#include <linux/delay.h>
#include <asm/plpar_wrappers.h>
@@ -77,22 +78,36 @@ static int drc_pmem_bind(struct papr_scm_priv *p)
static int drc_pmem_unbind(struct papr_scm_priv *p)
{
unsigned long ret[PLPAR_HCALL_BUFSIZE];
- uint64_t rc, token;
+ uint64_t token = 0;
+ int64_t rc;
- token = 0;
+ dev_dbg(&p->pdev->dev, "unbind drc %x\n", p->drc_index);
- /* NB: unbind has the same retry requirements mentioned above */
+ /* NB: unbind has the same retry requirements as drc_pmem_bind() */
do {
- rc = plpar_hcall(H_SCM_UNBIND_MEM, ret, p->drc_index,
- p->bound_addr, p->blocks, token);
+
+ /* Unbind of all SCM resources associated with drcIndex */
+ rc = plpar_hcall(H_SCM_UNBIND_ALL, ret, H_UNBIND_SCOPE_DRC,
+ p->drc_index, token);
token = ret[0];
- cond_resched();
+
+ /* Check if we are stalled for some time */
+ if (H_IS_LONG_BUSY(rc)) {
+ msleep(get_longbusy_msecs(rc));
+ rc = H_BUSY;
+ } else if (rc == H_BUSY) {
+ cond_resched();
+ }
+
} while (rc == H_BUSY);
if (rc)
dev_err(&p->pdev->dev, "unbind error: %lld\n", rc);
+ else
+ dev_dbg(&p->pdev->dev, "unbind drc %x complete\n",
+ p->drc_index);
- return !!rc;
+ return rc == H_SUCCESS ? 0 : -ENXIO;
}
static int papr_scm_meta_get(struct papr_scm_priv *p,
--
2.21.0
^ permalink raw reply related
* [PATCH v4 3/3] powerpc/papr_scm: Force a scm-unbind if initial scm-bind fails
From: Vaibhav Jain @ 2019-06-29 16:06 UTC (permalink / raw)
To: linuxppc-dev
Cc: Aneesh Kumar K . V, Oliver O'Halloran, Vaibhav Jain,
Laurent Dufour, David Gibson
In-Reply-To: <20190629160610.23402-1-vaibhav@linux.ibm.com>
In some cases initial bind of scm memory for an lpar can fail if
previously it wasn't released using a scm-unbind hcall. This situation
can arise due to panic of the previous kernel or forced lpar
fadump. In such cases the H_SCM_BIND_MEM return a H_OVERLAP error.
To mitigate such cases the patch updates papr_scm_probe() to force a
call to drc_pmem_unbind() in case the initial bind of scm memory fails
with EBUSY error. In case scm-bind operation again fails after the
forced scm-unbind then we follow the existing error path. We also
update drc_pmem_bind() to handle the H_OVERLAP error returned by phyp
and indicate it as a EBUSY error back to the caller.
Suggested-by: "Oliver O'Halloran" <oohall@gmail.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
---
Change-log:
v4:
* None. Re-spinning the patchset.
v3:
* Minor update to a code comment. [Oliver]
v2:
* Moved the retry code from drc_pmem_bind() to papr_scm_probe()
[Oliver]
* Changed the type of variable 'rc' in drc_pmem_bind() to
int64_t. [Oliver]
---
arch/powerpc/platforms/pseries/papr_scm.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index c01a03fd3ee7..7c5e10c063a0 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -43,8 +43,9 @@ struct papr_scm_priv {
static int drc_pmem_bind(struct papr_scm_priv *p)
{
unsigned long ret[PLPAR_HCALL_BUFSIZE];
- uint64_t rc, token;
uint64_t saved = 0;
+ uint64_t token;
+ int64_t rc;
/*
* When the hypervisor cannot map all the requested memory in a single
@@ -64,6 +65,10 @@ static int drc_pmem_bind(struct papr_scm_priv *p)
} while (rc == H_BUSY);
if (rc) {
+ /* H_OVERLAP needs a separate error path */
+ if (rc == H_OVERLAP)
+ return -EBUSY;
+
dev_err(&p->pdev->dev, "bind err: %lld\n", rc);
return -ENXIO;
}
@@ -331,6 +336,14 @@ static int papr_scm_probe(struct platform_device *pdev)
/* request the hypervisor to bind this region to somewhere in memory */
rc = drc_pmem_bind(p);
+
+ /* If phyp says drc memory still bound then force unbound and retry */
+ if (rc == -EBUSY) {
+ dev_warn(&pdev->dev, "Retrying bind after unbinding\n");
+ drc_pmem_unbind(p);
+ rc = drc_pmem_bind(p);
+ }
+
if (rc)
goto err;
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v3 1/3] powerpc/pseries: Update SCM hcall op-codes in hvcall.h
From: Vaibhav Jain @ 2019-06-29 16:09 UTC (permalink / raw)
To: Michael Ellerman, Oliver O'Halloran
Cc: Aneesh Kumar K . V, Laurent Dufour, linuxppc-dev, David Gibson
In-Reply-To: <87a7e0k4rf.fsf@concordia.ellerman.id.au>
Thanks for reviewing this patch Mpe.
Michael Ellerman <mpe@ellerman.id.au> writes:
> "Oliver O'Halloran" <oohall@gmail.com> writes:
>> On Fri, Jun 28, 2019 at 1:39 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>>>
>>> Vaibhav Jain <vaibhav@linux.ibm.com> writes:
>>> > *snip*
>>>
>>> How can we be changing the meaning of HCALL numbers without breaking all
>>> existing usages?
>>
>> The changed one being changed here were never used by linux or
>> implemented by either hypervisor.
>
> OK. Please say so in the change log so that it's clear it's not a
> behaviour change.
I have respinned this patchset to v4 updating this patch's
description mentioning the hcall opcodes that are removed.
>
>>> Where are these hypervisor calls documented?
>>
>> In an internal spec from one the phyp guys. I have been complaining
>> about it not being open (or merged into PAPR at the very least), but
>> it doesn't look like there's been any movement there.
>
> Please send a patch for Documentation/powerpc/ describing the API for
> the hypercalls we're using.
Sure will send a separate patch documenting this.
> cheers
>
--
Vaibhav Jain <vaibhav@linux.ibm.com>
Linux Technology Center, IBM India Pvt. Ltd.
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.2-7 tag
From: pr-tracker-bot @ 2019-06-30 3:30 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Linus Torvalds, linux-kernel, npiggin
In-Reply-To: <871rzck26l.fsf@concordia.ellerman.id.au>
The pull request you sent on Sat, 29 Jun 2019 22:26:26 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.2-7
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/39132f746eceed6beecb16c7b79600fb54eb8b2b
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [PATCH] i2c: remove casting dma_alloc
From: Jochen Friedrich @ 2019-06-29 11:41 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Vasyl Gomonovych, linuxppc-dev, linux-i2c, linux-kernel
In-Reply-To: <20190629113424.GH1685@kunai>
[-- Attachment #1: Type: text/html, Size: 2214 bytes --]
^ permalink raw reply
* Re: [PATCH] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
From: Anshuman Khandual @ 2019-06-30 4:41 UTC (permalink / raw)
To: Guenter Roeck
Cc: Mark Rutland, Michal Hocko, linux-ia64, linux-sh, Peter Zijlstra,
James Hogan, Dave Hansen, Will Deacon, linux-mips, linux-mm,
Paul Mackerras, sparclinux, Stephen Rothwell, Yoshinori Sato, x86,
Russell King, Matthew Wilcox, Ingo Molnar, Catalin Marinas,
linux-snps-arc, Fenghua Yu, linux-s390, Andrey Konovalov,
Andy Lutomirski, Thomas Gleixner, linux-arm-kernel, Tony Luck,
Heiko Carstens, Vineet Gupta, linux-kernel, Ralf Baechle,
Paul Burton, Martin Schwidefsky, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20190629145009.GA28613@roeck-us.net>
Hello Guenter,
On 06/29/2019 08:20 PM, Guenter Roeck wrote:
> Hi,
>
> On Thu, Jun 13, 2019 at 03:37:24PM +0530, Anshuman Khandual wrote:
>> Architectures which support kprobes have very similar boilerplate around
>> calling kprobe_fault_handler(). Use a helper function in kprobes.h to unify
>> them, based on the x86 code.
>>
>> This changes the behaviour for other architectures when preemption is
>> enabled. Previously, they would have disabled preemption while calling the
>> kprobe handler. However, preemption would be disabled if this fault was
>> due to a kprobe, so we know the fault was not due to a kprobe handler and
>> can simply return failure.
>>
>> This behaviour was introduced in the commit a980c0ef9f6d ("x86/kprobes:
>> Refactor kprobes_fault() like kprobe_exceptions_notify()")
>>
>
> With this patch applied, parisc:allmodconfig images no longer build.
>
> In file included from arch/parisc/mm/fixmap.c:8:
> include/linux/kprobes.h: In function 'kprobe_page_fault':
> include/linux/kprobes.h:477:9: error:
> implicit declaration of function 'kprobe_fault_handler'; did you mean 'kprobe_page_fault'?
Yikes.. Arch parisc does not even define (unlike mips which did but never exported)
now required function kprobe_fault_handler() when CONFIG_KPROBES is enabled.
I believe rather than defining one stub version only for parsic it would be better
to have an weak symbol generic stub definition for kprobe_fault_handler() in file
include/linux/kprobes.h when CONFIG_KPROBES is enabled along side the other stub
definition when !CONFIG_KPROBES. But arch which wants to use kprobe_page_fault()
cannot use stub kprobe_fault_handler() definition and will have to provide one.
I will probably add a comment regarding this.
>
> Reverting the patch fixes the problem.
>
> Guenter
>
Thanks for reporting the problem.
^ permalink raw reply
* Re: [PATCH] powerpc/64: mark start_here_multiplatform as __ref
From: Michael Ellerman @ 2019-06-30 8:37 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Russell Currey
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <7b15f4a18ab2d9fb54559acbadf2cd83a7d147f7.1557469839.git.christophe.leroy@c-s.fr>
On Fri, 2019-05-10 at 06:31:28 UTC, Christophe Leroy wrote:
> Otherwise, the following warning is encountered:
>
> WARNING: vmlinux.o(.text+0x3dc6): Section mismatch in reference from the variable start_here_multiplatform to the function .init.text:.early_setup()
> The function start_here_multiplatform() references
> the function __init .early_setup().
> This is often because start_here_multiplatform lacks a __init
> annotation or the annotation of .early_setup is wrong.
>
> Fixes: 56c46bba9bbf ("powerpc/64: Fix booting large kernels with STRICT_KERNEL_RWX")
> Cc: Russell Currey <ruscur@russell.cc>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/9c4e4c90ec24652921e31e9551fcaedc26eec86d
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: avoid blocking in irq when queuing hotplug events
From: Michael Ellerman @ 2019-06-30 8:37 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev
In-Reply-To: <20190528232801.7413-1-nathanl@linux.ibm.com>
On Tue, 2019-05-28 at 23:28:01 UTC, Nathan Lynch wrote:
> A couple of bugs in queue_hotplug_event():
>
> 1. Unchecked kmalloc result which could lead to an oops.
> 2. Use of GFP_KERNEL allocations in interrupt context (this code's
> only caller is ras_hotplug_interrupt()).
>
> Use kmemdup to avoid open-coding the allocation+copy and check for
> failure; use GFP_ATOMIC for both allocations.
>
> Ultimately it probably would be better to avoid or reduce allocations
> in this path if possible.
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/348ea30f51fc63ce3c7fd7dba6043e8e3ee0ef34
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/64s: Fix misleading SPR and timebase information
From: Michael Ellerman @ 2019-06-30 8:37 UTC (permalink / raw)
To: Shaokun Zhang, linuxppc-dev; +Cc: Shaokun Zhang, Nicholas Piggin
In-Reply-To: <1559121711-24114-1-git-send-email-zhangshaokun@hisilicon.com>
On Wed, 2019-05-29 at 09:21:51 UTC, Shaokun Zhang wrote:
> pr_info shows SPR and timebase as a decimal value with a '0x'
> prefix, which is somewhat misleading.
>
> Fix it to print hexadecimal, as was intended.
>
> Fixes: 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C")
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/87997471c597d0594dc8c9346ecaafab83798cf3
cheers
^ permalink raw reply
* Re: [PATCH kernel] powerpc/pci/of: Fix OF flags parsing for 64bit BARs
From: Michael Ellerman @ 2019-06-30 8:37 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev
Cc: Shawn Anastasio, Alexey Kardashevskiy, Michael Roth, Sam Bobroff,
Oliver O'Halloran, David Gibson
In-Reply-To: <20190605033814.127962-1-aik@ozlabs.ru>
On Wed, 2019-06-05 at 03:38:14 UTC, Alexey Kardashevskiy wrote:
> When the firmware does PCI BAR resource allocation, it passes the assigned
> addresses and flags (prefetch/64bit/...) via the "reg" property of
> a PCI device device tree node so the kernel does not need to do
> resource allocation.
>
> The flags are stored in resource::flags - the lower byte stores
> PCI_BASE_ADDRESS_SPACE/etc bits and the other bytes are IORESOURCE_IO/etc.
> Some flags from PCI_BASE_ADDRESS_xxx and IORESOURCE_xxx are duplicated,
> such as PCI_BASE_ADDRESS_MEM_PREFETCH/PCI_BASE_ADDRESS_MEM_TYPE_64/etc.
> When parsing the "reg" property, we copy the prefetch flag but we skip
> on PCI_BASE_ADDRESS_MEM_TYPE_64 which leaves the flags out of sync.
>
> The missing IORESOURCE_MEM_64 flag comes into play under 2 conditions:
> 1. we remove PCI_PROBE_ONLY for pseries (by hacking pSeries_setup_arch()
> or by passing "/chosen/linux,pci-probe-only");
> 2. we request resource alignment (by passing pci=resource_alignment=
> via the kernel cmd line to request PAGE_SIZE alignment or defining
> ppc_md.pcibios_default_alignment which returns anything but 0). Note that
> the alignment requests are ignored if PCI_PROBE_ONLY is enabled.
>
> With 1) and 2), the generic PCI code in the kernel unconditionally
> decides to:
> - reassign the BARs in pci_specified_resource_alignment() (works fine)
> - write new BARs to the device - this fails for 64bit BARs as the generic
> code looks at IORESOURCE_MEM_64 (not set) and writes only lower 32bits
> of the BAR and leaves the upper 32bit unmodified which breaks BAR mapping
> in the hypervisor.
>
> This fixes the issue by copying the flag. This is useful if we want to
> enforce certain BAR alignment per platform as handling subpage sized BARs
> is proven to cause problems with hotplug (SLOF already aligns BARs to 64k).
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> Reviewed-by: Sam Bobroff <sbobroff@linux.ibm.com>
> Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
> Reviewed-by: Shawn Anastasio <shawn@anastas.io>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/df5be5be8735ef2ae80d5ae1f2453cd81a035c4b
cheers
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/64: __ioremap_at clean up in the error case
From: Michael Ellerman @ 2019-06-30 8:37 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20190610030818.17965-1-npiggin@gmail.com>
On Mon, 2019-06-10 at 03:08:16 UTC, Nicholas Piggin wrote:
> __ioremap_at error handling is wonky, it requires caller to clean up
> after it. Implement a helper that does the map and error cleanup and
> remove the requirement from the caller.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/a72808a7ec5d340417a91a81e5cabdaa50650f2e
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/perf: Use cpumask_last() to determine the designated cpu for nest/core units.
From: Michael Ellerman @ 2019-06-30 8:37 UTC (permalink / raw)
To: Anju T Sudhakar; +Cc: ego, anju, linuxppc-dev, maddy
In-Reply-To: <20190610063229.32560-1-anju@linux.vnet.ibm.com>
On Mon, 2019-06-10 at 06:32:29 UTC, Anju T Sudhakar wrote:
> Nest and core imc(In-memory Collection counters) assigns a particular
> cpu as the designated target for counter data collection.
> During system boot, the first online cpu in a chip gets assigned as
> the designated cpu for that chip(for nest-imc) and the first online cpu
> in a core gets assigned as the designated cpu for that core(for core-imc).
>
> If the designated cpu goes offline, the next online cpu from the same
> chip(for nest-imc)/core(for core-imc) is assigned as the next target,
> and the event context is migrated to the target cpu.
> Currently, cpumask_any_but() function is used to find the target cpu.
> Though this function is expected to return a `random` cpu, this always
> returns the next online cpu.
>
> If all cpus in a chip/core is offlined in a sequential manner, starting
> from the first cpu, the event migration has to happen for all the cpus
> which goes offline. Since the migration process involves a grace period,
> the total time taken to offline all the cpus will be significantly high.
>
> Example:
> In a system which has 2 sockets, with
> NUMA node0 CPU(s): 0-87
> NUMA node8 CPU(s): 88-175
>
> Time taken to offline cpu 88-175:
> real 2m56.099s
> user 0m0.191s
> sys 0m0.000s
>
> Use cpumask_last() to choose the target cpu, when the designated cpu
> goes online, so the migration will happen only when the last_cpu in the
> mask goes offline. This way the time taken to offline all cpus in a
> chip/core can be reduced.
>
> With the patch,
>
> Time taken to offline cpu 88-175:
> real 0m12.207s
> user 0m0.171s
> sys 0m0.000s
>
>
> Offlining all cpus in reverse order is also taken care because,
> cpumask_any_but() is used to find the designated cpu if the last cpu in
> the mask goes offline. Since cpumask_any_but() always return the first
> cpu in the mask, that becomes the designated cpu and migration will happen
> only when the first_cpu in the mask goes offline.
>
> Example:
> With the patch,
>
> Time taken to offline cpu from 175-88:
> real 0m9.330s
> user 0m0.110s
> sys 0m0.000s
>
> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
> Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/9c9f8fb71feed144973a70455e0a4ee3da57ed2a
cheers
^ permalink raw reply
* Re: [PATCH v2] cxl: no need to check return value of debugfs_create functions
From: Michael Ellerman @ 2019-06-30 8:37 UTC (permalink / raw)
To: Greg Kroah-Hartman, Frederic Barrat
Cc: linuxppc-dev, Andrew Donnellan, Arnd Bergmann
In-Reply-To: <20190612155418.GB22739@kroah.com>
On Wed, 2019-06-12 at 15:54:18 UTC, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Because there's no need to check, also make the return value of the
> local debugfs_create_io_x64() call void, as no one ever did anything
> with the return value (as they did not need to.)
>
> And make the cxl_debugfs_* calls return void as no one was even checking
> their return value at all.
>
> Cc: Frederic Barrat <fbarrat@linux.ibm.com>
> Cc: Andrew Donnellan <ajd@linux.ibm.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
> Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/1b7de1df997a57e3e144bdb31ceaee9c16d6d284
cheers
^ permalink raw reply
* Re: [PATCH v2] Powerpc/Watchpoint: Restore nvgprs while returning from exception
From: Michael Ellerman @ 2019-06-30 8:37 UTC (permalink / raw)
To: Ravi Bangoria
Cc: ravi.bangoria, mikey, aneesh.kumar, linux-kernel, npiggin, paulus,
mahesh, naveen.n.rao, linuxppc-dev
In-Reply-To: <20190613033014.17496-1-ravi.bangoria@linux.ibm.com>
On Thu, 2019-06-13 at 03:30:14 UTC, Ravi Bangoria wrote:
> Powerpc hw triggers watchpoint before executing the instruction. To
> make trigger-after-execute behavior, kernel emulates the instruction.
> If the instruction is 'load something into non-volatile register',
> exception handler should restore emulated register state while
> returning back, otherwise there will be register state corruption.
> Ex, Adding a watchpoint on a list can corrput the list:
>
> # cat /proc/kallsyms | grep kthread_create_list
> c00000000121c8b8 d kthread_create_list
>
> Add watchpoint on kthread_create_list->prev:
>
> # perf record -e mem:0xc00000000121c8c0
>
> Run some workload such that new kthread gets invoked. Ex, I just
> logged out from console:
>
> list_add corruption. next->prev should be prev (c000000001214e00), \
> but was c00000000121c8b8. (next=c00000000121c8b8).
> WARNING: CPU: 59 PID: 309 at lib/list_debug.c:25 __list_add_valid+0xb4/0xc0
> CPU: 59 PID: 309 Comm: kworker/59:0 Kdump: loaded Not tainted 5.1.0-rc7+ #69
> ...
> NIP __list_add_valid+0xb4/0xc0
> LR __list_add_valid+0xb0/0xc0
> Call Trace:
> __list_add_valid+0xb0/0xc0 (unreliable)
> __kthread_create_on_node+0xe0/0x260
> kthread_create_on_node+0x34/0x50
> create_worker+0xe8/0x260
> worker_thread+0x444/0x560
> kthread+0x160/0x1a0
> ret_from_kernel_thread+0x5c/0x70
>
> List corruption happened because it uses 'load into non-volatile
> register' instruction:
>
> Snippet from __kthread_create_on_node:
>
> c000000000136be8: addis r29,r2,-19
> c000000000136bec: ld r29,31424(r29)
> if (!__list_add_valid(new, prev, next))
> c000000000136bf0: mr r3,r30
> c000000000136bf4: mr r5,r28
> c000000000136bf8: mr r4,r29
> c000000000136bfc: bl c00000000059a2f8 <__list_add_valid+0x8>
>
> Register state from WARN_ON():
>
> GPR00: c00000000059a3a0 c000007ff23afb50 c000000001344e00 0000000000000075
> GPR04: 0000000000000000 0000000000000000 0000001852af8bc1 0000000000000000
> GPR08: 0000000000000001 0000000000000007 0000000000000006 00000000000004aa
> GPR12: 0000000000000000 c000007ffffeb080 c000000000137038 c000005ff62aaa00
> GPR16: 0000000000000000 0000000000000000 c000007fffbe7600 c000007fffbe7370
> GPR20: c000007fffbe7320 c000007fffbe7300 c000000001373a00 0000000000000000
> GPR24: fffffffffffffef7 c00000000012e320 c000007ff23afcb0 c000000000cb8628
> GPR28: c00000000121c8b8 c000000001214e00 c000007fef5b17e8 c000007fef5b17c0
>
> Watchpoint hit at 0xc000000000136bec.
>
> addis r29,r2,-19
> => r29 = 0xc000000001344e00 + (-19 << 16)
> => r29 = 0xc000000001214e00
>
> ld r29,31424(r29)
> => r29 = *(0xc000000001214e00 + 31424)
> => r29 = *(0xc00000000121c8c0)
>
> 0xc00000000121c8c0 is where we placed a watchpoint and thus this
> instruction was emulated by emulate_step. But because handle_dabr_fault
> did not restore emulated register state, r29 still contains stale
> value in above register state.
>
> Fixes: 5aae8a5370802 ("powerpc, hw_breakpoints: Implement hw_breakpoints for 64-bit server processors")
> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
> Cc: stable@vger.kernel.org # 2.6.36+
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/f474c28fbcbe42faca4eb415172c07d76adcb819
cheers
^ permalink raw reply
* Re: [PATCH] ps3: Use [] to denote a flexible array member
From: Michael Ellerman @ 2019-06-30 8:37 UTC (permalink / raw)
To: Geert Uytterhoeven, Geoff Levand, Benjamin Herrenschmidt,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel, Geert Uytterhoeven
In-Reply-To: <20190617090713.10532-1-geert+renesas@glider.be>
On Mon, 2019-06-17 at 09:07:13 UTC, Geert Uytterhoeven wrote:
> Flexible array members should be denoted using [] instead of [0], else
> gcc will not warn when they are no longer at the end of the structure.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/0b1be03f25bb4c92de6408da4de9361f4cb50ae3
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/mm/32s: fix condition that is always true
From: Michael Ellerman @ 2019-06-30 8:37 UTC (permalink / raw)
To: Andreas Schwab, Christophe Leroy
Cc: linuxppc-dev, Paul Mackerras, j.neuschaefer, linux-kernel
In-Reply-To: <87muif52lv.fsf_-_@igel.home>
On Mon, 2019-06-17 at 21:22:20 UTC, Andreas Schwab wrote:
> Move a misplaced paren that makes the condition always true.
>
> Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX")
> Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/46c2478af610efb3212b8b08f74389d69899ef70
cheers
^ permalink raw reply
* Re: [PATCH] selftests/powerpc: Fix earlyclobber in tm-vmxcopy
From: Michael Ellerman @ 2019-06-30 8:37 UTC (permalink / raw)
To: Gustavo Romero, linuxppc-dev; +Cc: mikey
In-Reply-To: <1560806698-26651-1-git-send-email-gromero@linux.vnet.ibm.com>
On Mon, 2019-06-17 at 21:24:58 UTC, Gustavo Romero wrote:
> In some cases, compiler can allocate the same register for operand 'res'
> and 'vecoutptr', resulting in segfault at 'stxvd2x 40,0,%[vecoutptr]'
> because base register will contain 1, yielding a false-positive.
>
> This is because output 'res' must be marked as an earlyclobber operand so
> it may not overlap an input operand ('vecoutptr').
>
> Signed-off-by: Gustavo Romero <gromero@linux.vnet.ibm.com>
> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8d0f1e05ab16c4bd628ddaefd20b94ffb36d799c
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/32s: fix suspend/resume when IBATs 4-7 are used
From: Michael Ellerman @ 2019-06-30 8:37 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Andreas Schwab
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <97f32bd4c45ce004550b3853474b3bc7e211ae0d.1560807643.git.christophe.leroy@c-s.fr>
On Mon, 2019-06-17 at 21:42:14 UTC, Christophe Leroy wrote:
> Previously, only IBAT1 and IBAT2 were used to map kernel linear mem.
> Since commit 63b2bc619565 ("powerpc/mm/32s: Use BATs for
> STRICT_KERNEL_RWX"), we may have all 8 BATs used for mapping
> kernel text. But the suspend/restore functions only save/restore
> BATs 0 to 3, and clears BATs 4 to 7.
>
> Make suspend and restore functions respectively save and reload
> the 8 BATs on CPUs having MMU_FTR_USE_HIGH_BATS feature.
>
> Reported-by: Andreas Schwab <schwab@linux-m68k.org>
> Cc: stable@vger.kernel.org
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6ecb78ef56e08d2119d337ae23cb951a640dc52d
cheers
^ permalink raw reply
* Re: [PATCH 2/3] KVM: PPC: Book3S HV: Signed extend decrementer value if not using large decr
From: Michael Ellerman @ 2019-06-30 8:37 UTC (permalink / raw)
To: Suraj Jitindar Singh, linuxppc-dev; +Cc: clg, kvm-ppc, sjitindarsingh
In-Reply-To: <20190620014651.7645-2-sjitindarsingh@gmail.com>
On Thu, 2019-06-20 at 01:46:50 UTC, Suraj Jitindar Singh wrote:
> On POWER9 the decrementer can operate in large decrementer mode where
> the decrementer is 56 bits and signed extended to 64 bits. When not
> operating in this mode the decrementer behaves as a 32 bit decrementer
> which is NOT signed extended (as on POWER8).
>
> Currently when reading a guest decrementer value we don't take into
> account whether the large decrementer is enabled or not, and this means
> the value will be incorrect when the guest is not using the large
> decrementer. Fix this by sign extending the value read when the guest
> isn't using the large decrementer.
>
> Fixes: 95a6432ce903 "KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests"
>
> Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
> Tested-by: Laurent Vivier <lvivier@redhat.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/869537709ebf1dc865e75c3fc97b23f8acf37c16
cheers
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S HV: Clear pending decr exceptions on nested guest entry
From: Michael Ellerman @ 2019-06-30 8:37 UTC (permalink / raw)
To: Suraj Jitindar Singh, linuxppc-dev; +Cc: clg, kvm-ppc, sjitindarsingh
In-Reply-To: <20190620014651.7645-3-sjitindarsingh@gmail.com>
On Thu, 2019-06-20 at 01:46:51 UTC, Suraj Jitindar Singh wrote:
> If we enter an L1 guest with a pending decrementer exception then this
> is cleared on guest exit if the guest has writtien a positive value into
> the decrementer (indicating that it handled the decrementer exception)
> since there is no other way to detect that the guest has handled the
> pending exception and that it should be dequeued. In the event that the
> L1 guest tries to run a nested (L2) guest immediately after this and the
> L2 guest decrementer is negative (which is loaded by L1 before making
> the H_ENTER_NESTED hcall), then the pending decrementer exception
> isn't cleared and the L2 entry is blocked since L1 has a pending
> exception, even though L1 may have already handled the exception and
> written a positive value for it's decrementer. This results in a loop of
> L1 trying to enter the L2 guest and L0 blocking the entry since L1 has
> an interrupt pending with the outcome being that L2 never gets to run
> and hangs.
>
> Fix this by clearing any pending decrementer exceptions when L1 makes
> the H_ENTER_NESTED hcall since it won't do this if it's decrementer has
> gone negative, and anyway it's decrementer has been communicated to L0
> in the hdec_expires field and L0 will return control to L1 when this
> goes negative by delivering an H_DECREMENTER exception.
>
> Fixes: 95a6432ce903 "KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests"
>
> Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
> Tested-by: Laurent Vivier <lvivier@redhat.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/3c25ab35fbc8526ac0c9b298e8a78e7ad7a55479
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/mm/nvdimm: Add an informative message if we fail to allocate altmap block
From: Oliver O'Halloran @ 2019-06-30 23:15 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Paul Mackerras, linuxppc-dev, Nicholas Piggin
In-Reply-To: <20190629073813.12973-1-aneesh.kumar@linux.ibm.com>
On Sat, Jun 29, 2019 at 5:39 PM Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> wrote:
>
> Allocation from altmap area can fail based on vmemmap page size used. Add kernel
> info message to indicate the failure. That allows the user to identify whether they
> are really using persistent memory reserved space for per-page metadata.
>
> The message looks like:
> [ 136.587212] altmap block allocation failed, falling back to system memory
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/mm/init_64.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
> index a4e17a979e45..57c0573650dc 100644
> --- a/arch/powerpc/mm/init_64.c
> +++ b/arch/powerpc/mm/init_64.c
> @@ -194,8 +194,12 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> * fail due to alignment issues when using 16MB hugepages, so
> * fall back to system memory if the altmap allocation fail.
> */
> - if (altmap)
> + if (altmap) {
> p = altmap_alloc_block_buf(page_size, altmap);
> + if (!p)
> + pr_info("altmap block allocation failed, " \
> + "falling back to system memory");
I think this is kind of misleading. If you're mapping a large amount
of memory you can have most of the vmemmap backing allocated from the
altmap and one extra block allocated from normal memory. E.g. If you
have 32MB of altmap space, one 16MB block will be allocated from the
altmap, but the 2nd 16MB block is probably unusable due to the
reserved pages at the start of the altmap. Maybe this should be a
pr_debug() so it's only printed along with the "vmemmap_populate ..."
message above?
Also, isn't kernel style to keep printf()s, even long ones, on one line?
Oliver
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox