public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
To: linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Vivek Goyal <vgoyal@redhat.com>, Haren Myneni <hbabu@us.ibm.com>,
	kexec@lists.infradead.org
Subject: [PATCH 2/7] ia64, kexec: Make INIT safe while kdump/kexec
Date: Thu, 18 Jun 2009 15:48:04 +0900	[thread overview]
Message-ID: <4A39E324.8020202@jp.fujitsu.com> (raw)
In-Reply-To: <4A39E247.4030908@jp.fujitsu.com>

In panic situation, we may receive INIT while kernel transition,
i.e. from preparation of kdump to bootstrap of kdump kernel.
Since we initialize registers on leave from current kernel, no
longer monarch/slave handlers of current kernel in virtual mode are
called safely.  (In fact system goes hang as far as I confirmed)

How to Reproduce:

  Start kdump
    # echo c > /proc/sysrq-trigger
  Then assert INIT before kdump kernel boots

We can unregister these init handlers from SAL before jumping into
new kernel, however then the INIT will fallback to default behavior,
result in warmboot by SAL (according to the SAL specification) and
we cannot retrieve the crashdump.

Therefore this patch introduces a NOP init handler and register it
to SAL before leave from current kernel, to start kdump safely by
preventing INITs from entering virtual mode and resulting in warmboot.

On the other hand, in case of kexec that not for kdump, it also
has same problem with INIT while kernel transition.
This patch handles this case differently, because for kexec
unregistering handlers will be preferred than registering NOP
handler, since the situation "no handlers registered" is usual
state for kernel's entry.

Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Haren Myneni <hbabu@us.ibm.com>
Cc: kexec@lists.infradead.org
---
 arch/ia64/kernel/machine_kexec.c |   14 ++++++++++++++
 arch/ia64/kernel/mca_asm.S       |   20 ++++++++++++++++++++
 2 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
index 0823de1..d35fc39 100644
--- a/arch/ia64/kernel/machine_kexec.c
+++ b/arch/ia64/kernel/machine_kexec.c
@@ -24,6 +24,8 @@
 #include <asm/delay.h>
 #include <asm/meminit.h>
 #include <asm/processor.h>
+#include <asm/sal.h>
+#include <asm/mca.h>
 
 typedef NORET_TYPE void (*relocate_new_kernel_t)(
 					unsigned long indirection_page,
@@ -47,6 +49,8 @@ struct resource boot_param_res = {
         .flags = IORESOURCE_BUSY | IORESOURCE_MEM
 };
 
+/* In mca_asm.S */
+extern void ia64_os_init_on_kdump(void);
 
 /*
  * Do what every setup is needed on image and the
@@ -85,11 +89,21 @@ static void ia64_machine_kexec(struct unw_frame_info *info, void *arg)
 	void *pal_addr = efi_get_pal_addr();
 	unsigned long code_addr = (unsigned long)page_address(image->control_code_page);
 	int ii;
+	u64 fp, gp;
+	ia64_fptr_t *init_handler = (ia64_fptr_t *)ia64_os_init_on_kdump;
 
 	BUG_ON(!image);
 	if (image->type == KEXEC_TYPE_CRASH) {
 		crash_save_this_cpu();
 		current->thread.ksp = (__u64)info->sw - 16;
+
+		/* Register noop init handler */
+		fp = ia64_tpa(init_handler->fp);
+		gp = ia64_tpa(ia64_getreg(_IA64_REG_GP));
+		ia64_sal_set_vectors(SAL_VECTOR_OS_INIT, fp, gp, 0, fp, gp, 0);
+	} else {
+		/* Unregister init handlers of current kernel */
+		ia64_sal_set_vectors(SAL_VECTOR_OS_INIT, 0, 0, 0, 0, 0, 0);
 	}
 
 	/* Interrupts aren't acceptable while we reboot */
diff --git a/arch/ia64/kernel/mca_asm.S b/arch/ia64/kernel/mca_asm.S
index c6ee089..0594c54 100644
--- a/arch/ia64/kernel/mca_asm.S
+++ b/arch/ia64/kernel/mca_asm.S
@@ -40,6 +40,7 @@
 
 	.global ia64_do_tlb_purge
 	.global ia64_os_mca_dispatch
+	.global ia64_os_init_on_kdump
 	.global ia64_os_init_dispatch_monarch
 	.global ia64_os_init_dispatch_slave
 
@@ -299,6 +300,25 @@ END(ia64_os_mca_virtual_begin)
 //StartMain////////////////////////////////////////////////////////////////////
 
 //
+// NOP init handler for kdump.  In panic situation, we may receive INIT
+// while kernel transition.  Since we initialize registers on leave from
+// current kernel, no longer monarch/slave handlers of current kernel in
+// virtual mode are called safely.
+// We can unregister these init handlers from SAL, however then the INIT
+// will result in warmboot by SAL and we cannot retrieve the crashdump.
+// Therefore register this NOP function to SAL, to prevent entering virtual
+// mode and resulting warmboot by SAL.
+//
+ia64_os_init_on_kdump:
+	mov		r8=r0		// IA64_INIT_RESUME
+	mov             r9=r10		// SAL_GP
+	mov		r22=r17		// *minstate
+	;;
+	mov		r10=r0		// return to same context
+	mov		b0=r12		// SAL_CHECK return address
+	br		b0
+
+//
 // SAL to OS entry point for INIT on all processors.  This has been defined for
 // registration purposes with SAL as a part of ia64_mca_init.  Monarch and
 // slave INIT have identical processing, except for the value of the
-- 
1.6.0



  parent reply	other threads:[~2009-06-18  6:48 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-18  6:44 [PATCH 0/7] Patches for kdump vs. INIT Hidetoshi Seto
2009-06-18  6:46 ` [PATCH 1/7] ia64, kdump: Mask MCA/INIT on freezing cpus Hidetoshi Seto
2009-06-22 13:45   ` Robin Holt
2009-06-23  0:33     ` Hidetoshi Seto
2009-06-23  5:55       ` Robin Holt
2009-06-23  8:07         ` Hidetoshi Seto
2009-06-24 11:14           ` Robin Holt
2009-06-25  2:15             ` Hidetoshi Seto
2009-06-25  3:29               ` Robin Holt
2009-06-18  6:48 ` Hidetoshi Seto [this message]
2009-06-18  6:48 ` [PATCH 3/7] ia64, kexec: Unregister MCA handler before kexec Hidetoshi Seto
2009-06-18  6:49 ` [PATCH 4/7] ia64, kdump: Don't offline APs Hidetoshi Seto
2009-06-18  6:50 ` [PATCH 5/7] ia64, kdump: Mask INIT first in panic-kdump path Hidetoshi Seto
2009-06-18  6:51 ` [PATCH 6/7] ia64, kdump: Try INIT regardless of kdump_on_init Hidetoshi Seto
2009-06-18  6:53 ` [PATCH 7/7] ia64, kdump: Short path to freeze CPUs Hidetoshi Seto
2009-06-22  6:31 ` [PATCH 0/7] Patches for kdump vs. INIT Jay Lan
2009-06-22  7:16   ` Hidetoshi Seto
2009-07-09  7:02 ` [PATCH v2 " Hidetoshi Seto
2009-07-09  7:10   ` [PATCH v2 1/7] ia64, kdump: Mask MCA/INIT on frozen cpus Hidetoshi Seto
2009-07-09  7:11   ` [PATCH v2 2/7] ia64, kexec: Make INIT safe while transition to kdump/kexec kernel Hidetoshi Seto
2009-07-09  7:12   ` [PATCH v2 3/7] ia64, kexec: Unregister MCA handler before kexec Hidetoshi Seto
2009-07-09  7:14   ` [PATCH v2 4/7] ia64, kdump: Don't return APs to SAL from kdump Hidetoshi Seto
2009-07-09  7:15   ` [PATCH v2 5/7] ia64, kdump: Mask INIT first in panic-kdump path Hidetoshi Seto
2009-07-09  7:17   ` [PATCH v2 6/7] ia64, kdump: Try INIT regardless of kdump_on_init Hidetoshi Seto
2009-07-09  7:18   ` [PATCH v2 7/7] ia64, kdump: Short path to freeze CPUs Hidetoshi Seto

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=4A39E324.8020202@jp.fujitsu.com \
    --to=seto.hidetoshi@jp.fujitsu.com \
    --cc=hbabu@us.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox