linux-kernel - Re: [RFC][PATCH v4 -next 1/4] Move kmsg_dump(KMSG_DUMP_PANIC) below smp_send

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: <4F0D3A0B.4090709@linux.intel.com>
Date:	Wed, 11 Jan 2012 15:28:11 +0800
From:	Chen Gong <gong.chen@...ux.intel.com>
To:	Seiji Aguchi <seiji.aguchi@....com>
CC:	"Luck, Tony" <tony.luck@...el.com>,
	Don Zickus <dzickus@...hat.com>,
	"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 v4 -next 1/4] Move kmsg_dump(KMSG_DUMP_PANIC) below
 smp_send_stop()

于 2012/1/11 4:29, Seiji Aguchi 写道:
>
>> I agree with you. How about adding macros or something like WARN_ON(XX_ARCH) or
>> Kconfig to limit its scope?
>
> Thank you for giving me your idea.
> Your suggestions above will work for me because I'm a x86 user.
> If Tony agrees to it, I can update my patch.
>
> But, I'm hesitating to add WARN_ON() or change Kconfig only for specific arch
> because pstore aims for generic interface and this is related to its design.
> Also, ramoops is going to use pstore now. It doesn't depend on x86.
> I'm worried that ramoops users will complain about this change.
>
> So, I think a reasonable solution at this time is just adding some explanations
> about smp_send_stop() to documentation as follows.
>
> Users can use pstore with their own responsibility and ask developers
> if smp_send_stop() is reliable enough in panic situation on architecture they want to run.
>
> What do you think?
>
> ---
>   Documentation/ABI/testing/pstore |    8 ++++++++
>   1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/ABI/testing/pstore b/Documentation/ABI/testing/pstore
> index ff1df4e..5583729 100644
> --- a/Documentation/ABI/testing/pstore
> +++ b/Documentation/ABI/testing/pstore
> @@ -11,6 +11,14 @@ Description:	Generic interface to platform dependent persistent storage.
>   		of the console log is captured, but other interesting
>   		data can also be saved.
>
> +		In case of panic, pstore is invoked after smp_send_stop()
> +		,a function call stopping other cpus, so that we can get
> +		logs simpler and cleaner with just one running cpu.
> +
> +		As for x86, smp_send_stop() is reliable enough to work in
> +		panic situation. But we are not guaranteed that it works
> +		reliably on other architectures.
> +
>   		# mount -t pstore -o kmsg_bytes=8000 - /dev/pstore
>
>   		$ ls -l /dev/pstore

The explanation is great. but In my opinion, I still insist that
a WARN_ON() is necessary. What do you think, Tony and Don?
--
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/