[RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>How is this safe? What happens if there's a pstore access in process
>when you hit this codepath?

This will never happen because pstore_kmsg_dump_in_interrupt() is called after machine_crash_shutdown().

Panicked cpu sends NMI to all other cpus in machine_crash_shutdown() and they stop.


@@ -1081,6 +1083,7 @@ void crash_kexec(struct pt_regs *regs)
 			crash_setup_regs(&fixed_regs, regs);
 			crash_save_vmcoreinfo();
 			machine_crash_shutdown(&fixed_regs);
+			pstore_kmsg_dump_in_interrupt(KMSG_DUMP_KEXEC);

Seiji

>-----Original Message-----
>From: Matthew Garrett [mailto:mjg at redhat.com]
>Sent: Tuesday, July 19, 2011 2:35 PM
>To: Seiji Aguchi
>Cc: kexec at lists.infradead.org; linux-kernel at vger.kernel.org; linux-mtd at lists.infradead.org; Eric W. Biederman; Vivek
>Goyal; KOSAKI Motohiro; Americo Wang; tony.luck at intel.com; Andrew Morton; Jarod Wilson; hpa at zytor.com; dzickus at redhat.com;
>dle-develop at lists.sourceforge.net; Satoru Moriya
>Subject: Re: [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path
>
>On Tue, Jul 19, 2011 at 02:24:27PM -0400, Seiji Aguchi wrote:
>
>> -	mutex_lock(&psinfo->buf_mutex);
>> +	switch (reason) {
>> +	case KMSG_DUMP_KEXEC:
>> +		/* Skip if there is no driver or there is a driver calling
>> +		   pstore_register() */
>> +		if (!psinfo || !spin_trylock(&pstore_lock))
>> +			return;
>> +		break;
>> +	default:
>> +		mutex_lock(&psinfo->buf_mutex);
>
>How is this safe? What happens if there's a pstore access in process
>when you hit this codepath?
>
>--
>Matthew Garrett | mjg59 at srcf.ucam.org



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux