linux-kernel - RE: [RFC][PATCH v3 2/3] Skip spin_locks in panic case and add WARN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5C4C569E8A4B9B42A84A977CF070A35B2C57FFA38E@USINDEVS01.corp.hds.com>
Date:	Mon, 19 Dec 2011 18:37:03 -0500
From:	Seiji Aguchi <seiji.aguchi@....com>
To:	Don Zickus <dzickus@...hat.com>, "Luck, Tony" <tony.luck@...el.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Matthew Garrett <mjg@...hat.com>,
	Vivek Goyal <vgoyal@...hat.com>,
	"Chen, Gong" <gong.chen@...el.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"Brown, Len" <len.brown@...el.com>,
	"'ying.huang@...el.com'" <'ying.huang@...el.com'>,
	"'ak@...ux.intel.com'" <'ak@...ux.intel.com'>,
	"'hughd@...omium.org'" <'hughd@...omium.org'>,
	"'mingo@...e.hu'" <'mingo@...e.hu'>,
	"jmorris@...ei.org" <jmorris@...ei.org>,
	"a.p.zijlstra@...llo.nl" <a.p.zijlstra@...llo.nl>,
	"namhyung@...il.com" <namhyung@...il.com>,
	"dle-develop@...ts.sourceforge.net" 
	<dle-develop@...ts.sourceforge.net>,
	Satoru Moriya <satoru.moriya@....com>
Subject: RE: [RFC][PATCH v3 2/3] Skip spin_locks in panic case and add
 WARN_ON()

Hi,

Thank you for coordinating discussion.

>Hitachi's whole goal behind
>kmsg_dump is to record every possible reason for rebooting the machine for
>inspection on reboot, I think if I understood Seiji privately.

Exactly.

>Now we have a scenario (though rare), where kmsg_dump can fail to save a
>dump because someone already has the lock.
>Seiji, has does this failure impact kmsg_dump's goal?

When we use EFI-enabled system, we can avoid this failure because
,as you can see below(spec of EFI 2.3), kernel in NMI can call set_variable 
runtime service even if previous call is busy.

<snip>
  7.1 Runtime Services Rules and Restrictions
  7.1.1 Exception for Machine Check, INIT, and NMI.
   .
   .
   .
  If the OS determines that the Machine Check is non-recoverable, the OS level handler may 
  ignore the normal restrictions and may invoke the runtime services described in Table 31 even 
  in the case where a previous call was busy. The system firmware will honor the new runtime 
  service call(s) and the operation of the previous interrupted call is not guaranteed. 
  Any interrupted runtime functions will not be restarted.
  The INIT and NMI events follow the same restrictions.
<snip>

So, next steps we should take are as follows.

 - Fix efi_pstore so "efivars->lock" in efi_pstore_write() skips in panic path.

 - Fix smp_send_stop() (or introduce new function call) 
   so that kmsg_dump(KMSG_DUMP_PANIC) is always called in NMI.

   Currently, panicked cpu sends NMI to all cpus other than itself in smp_send_stop() (with Don's patch).
   My suggestion is that panicked cpu sends NMI to itself and then it calls kmsg_dump(KMSG_DUMP_PANIC) in NMI.

Seiji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/