----- "Dave Anderson" <anderson@xxxxxxxxxx> wrote: > ----- "Jeffrey Hagen" <Jeffrey.Hagen@xxxxxxxxxxxx> wrote: > > > Paranoia is usually a good thing in this industry and you know this code > > far better that I do... > > > > For the older kernels that don't have cpu_present_map, if they still > > have the x8664_pda structure, the code my patch changes shouldn't get > > executed. It's the deprecation of the x8664_pda structure (between > > SLES10 and SLES11 in our case) that exposes this issue. > > True... > > > > > The setting of the other CPU's to offline (IPI REBOOT_VECTOR) is done in > > native_smp_send_stop [arch/x86/kernel/smp.c] called by panic(). Note > > that the SLES11 version of the 2.6.32 kernel allows calling > > crash_kexec() after calling atomic_notifer_call_chain() in panic(). > > Ah-ha! That makes sense -- I was under the impression that all of the > other distros would follow upstream with crash_kexec() being called > before, and therefore preventing, the subsequent smp_send_stop() call. > > So given that this would happen whenever panic() gets called directly > in a SLES kernel, is the SLES version of the crash utility patched to do > something similar to your patch? > > Petr? > > > The flow during an oops or keyboard induced crash does not use this same > > code. In this case crash_kexec() is called by oops_end() which is > > called by die(). > > OK, I'm going to give your patch a run-through with ~150 or so x86_64 > dumpfiles I've kept as examples over the years, and see if anything > interesting happens. Hi Jeff, Nothing interest happened -- so unless I hear anything to the contrary from the SUSE maintainers, I'm queueing your patch for the next release. Thanks, Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility