> The explanation is great. but In my opinion, I still insist that
> a WARN_ON() is necessary. What do you think, Tony and Don?

I disagree - a WARN_ON() would clutter the log with a stack trace of
dubious usefulness - possibly displacing something earlier in the
console log from being saved to pstore.

I'm about 80% sold on the idea of moving the call below smp_send_stop().
It does make life simpler for pstore (though not completely pain free,
ignoring locks is safe only in as far as we know that other cpus aren't
actually trying to modify things - there is still some problem if the
other cpu had a device or data structure in some special state when
smp_send_stop() interrupted it). The 20% of me that isn't buying this
still has worries that smp_send_stop() might fail in one of several ways:
1) Fails to actually stop one or more other cpus (this is similar to our
current situation where other cpus may interfere with us saving kmsg in
pstore).
2) Causes another fault, thus recursively entering the panic path.
3) Hangs - causing us to miss saving to pstore.

I don't know what can be done to resolve this - it is hard to make a
100% convincing argument about the execution of any code in the panic
path.

-Tony
���{.n�+�������+%�����ݶ��w��{.n�+����{��G�����{ay�ʇڙ�,j��f���h��������z_�(�階�ݢj"���m������G������?����&���~��iO��z��v�^�m����������?�I�