From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: linuxppc-dev@ozlabs.org
Cc: Russell Currey <ruscur@russell.cc>,
Michael Neuling <michael.neuling@au1.ibm.com>
Subject: [RFC/PATCH] powerpc/eeh: Create PHB PEs after EEH is initialized
Date: Mon, 04 Sep 2017 16:36:22 +1000 [thread overview]
Message-ID: <1504506982.2250.21.camel@kernel.crashing.org> (raw)
Otherwise we end up not yet having computed the right
diag data size on powernv where EEH initialization
is delayed, thus causing memory corruption later on
when calling OPAL.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Russell, what do you think ? The end result is that the PEs
for the PHBs are created much later. I suppose that might cause
changes of behaviour if, for example, we hit EEH while probing
before we call eeh_init() again. Hopefully we have all the
appropriate NULL checks to deal with it though...
Another option would be to break up eeh_init() between calling
the backend init, which we would unconditionally do early (ie
removing the special powernv test) and a new eeh_create_pe()'s
which would explicitely be called by the backend at the "right"
time...
Without either fix, we are currently corrupting kernel memory
when hitting EEH on a PHB PE (fences for example).
If this ends up being the right approach, then we need a CC
stable as well.
arch/powerpc/kernel/eeh.c | 4 ++++
arch/powerpc/kernel/eeh_dev.c | 18 ------------------
2 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 63992b2d8e15..f27eecd5ec7f 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1018,6 +1018,10 @@ int eeh_init(void)
} else if ((ret = eeh_ops->init()))
return ret;
+ /* Initialize PHB PEs */
+ list_for_each_entry_safe(hose, tmp, &hose_list, list_node)
+ eeh_dev_phb_init_dynamic(hose);
+
/* Initialize EEH event */
ret = eeh_event_init();
if (ret)
diff --git a/arch/powerpc/kernel/eeh_dev.c b/arch/powerpc/kernel/eeh_dev.c
index d6b2ca70d14d..0820b73288c0 100644
--- a/arch/powerpc/kernel/eeh_dev.c
+++ b/arch/powerpc/kernel/eeh_dev.c
@@ -83,21 +83,3 @@ void eeh_dev_phb_init_dynamic(struct pci_controller *phb)
/* EEH PE for PHB */
eeh_phb_pe_create(phb);
}
-
-/**
- * eeh_dev_phb_init - Create EEH devices for devices included in existing PHBs
- *
- * Scan all the existing PHBs and create EEH devices for their OF
- * nodes and their children OF nodes
- */
-static int __init eeh_dev_phb_init(void)
-{
- struct pci_controller *phb, *tmp;
-
- list_for_each_entry_safe(phb, tmp, &hose_list, list_node)
- eeh_dev_phb_init_dynamic(phb);
-
- return 0;
-}
-
-core_initcall(eeh_dev_phb_init);
reply other threads:[~2017-09-04 6:36 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1504506982.2250.21.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=michael.neuling@au1.ibm.com \
--cc=ruscur@russell.cc \
/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.