Stewart Smith stew...@linux.vnet.ibm.com wrote:
This fixes a bug where we would get two events from OPAL with DUMP_AVAIL
set (which is valid for OPAL to do) and in the second run of extract_dump()
we would fail to free the memory previously allocated for the dump
(leaking ~6MB+) as well as on the second dump_read_data() call OPAL
would not retrieve the dump, leaving us with a dump in linux that was
the correct size but all zeros.
Changes since v1: fixed typo
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Should we CC stable on this?
Mikey
---
arch/powerpc/platforms/powernv/opal-dump.c |8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/opal-dump.c
b/arch/powerpc/platforms/powernv/opal-dump.c
index 4447027..53c2675 100644
--- a/arch/powerpc/platforms/powernv/opal-dump.c
+++ b/arch/powerpc/platforms/powernv/opal-dump.c
@@ -238,6 +238,14 @@ static int extract_dump(void)
{
int rc;
+ /* We can get notified that a dump is available multiple times
+ * (dump_read_info clears the bit in the event from OPAL).
+ * But we should not re-read the dump from OPAL as we
+ * don't get the next dump until we've explicitly acked this one.
+ */
+ if (dump_avail)
+ return OPAL_SUCCESS;
+
/* Get dump ID, size */
rc = dump_read_info();
if (rc != OPAL_SUCCESS)
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
