Closed sourabhjains closed 2 months ago
Any review/comments on this PR?
won't this match: TEST=="/sys/kernel/fadump/hotplug_ready" break the rule for kernels that don't have that sysfs file yet?
I tried the above test case and things were working. However, what you suggested below is a much cleaner way of handling this case. I will update the patch.
I'm not an udev expert, but I think the way to do this is prepend a new rule to the existing one like this: TEST=="/sys/kernel/fadump/hotplug_ready", PROGRAM="/bin/cat /sys/kernel/fadump/hotplug_ready", RESULT=="1", GOTO="kdump_end"
Thanks for reviewing the patch.
@jiribohac I updated the patch based on your suggestion. Let me know if you have comments or suggestions on the latest change.
@jiribohac Any review/comments for this PR?
Would you like me to provide some test results to push this PR forward?
Merged, thanks!
Thanks @jiribohac for accepting the patch.
Currently, fadump is re-registered on memory add/remove events. However, with the introduction of the kernel commit c6c5b14dac0d ("powerpc: make fadump resilient with memory add/remove events"), elfcorehdr creation is moved to the second kernel. This makes fadump re-registration on memory add/remove events unnecessary.
To indicate to userspace that the kernel is hotplug ready for the fadump case, a new sysfs entry, /sys/kernel/fadump/hotplug_ready, is introduced. If the hotplug_ready sysfs is set to 1, then there is no need to re-register fadump.
No impact for kernels without /sys/kernel/fadump/hotplug_ready sysfs node.
Relevant kernel commit links: