On Mon 2022-03-07 11:25:30, Guilherme G. Piccoli wrote: > On 07/03/2022 11:04, bhe@xxxxxxxxxx wrote: > > [...] > > Ah, sorry, I even didn't notice that. That's awesome if we can make use > > of that. While I still have concerns: > > > > Thanks, nice that you liked the idea. > > > 1) about those we have decided to take out from panic notifier list and > > put before kdump, e.g the Hypver-V notifier, how will we do with it? Are > > we going to handle them as we have discussed? > > > > While implementing that I will think of something, but if > understood/remember correctly Hyper-V gonna be one of the first to run > in the first notifier list proposed by Petr - so we might still use > ordering by priority there, having Hyper-V being the first heh My understanding is that the problem is not a priority but an ordering against other operations. Namely, Hyper-V must be called even before crash dump. Some others before kmsg_dump(). And the rest only when the crash dump is not called at all. > > 2) Combing and settling priority for all existing panic notifier looks > > great, even though it will take some effort. How about the later newly > > added one? How can we guarantee that those new notifiers are getting > > appropriate priority to mark their order? Sometime we even don't know > > a new panic notifier is added since code change may be made in any > > component or driver. > > > > This is a great point! How to do it? One idea is to have a special > registering function for panic notifiers that checks for priority field > missing, and good documentation is a good idea as well, always. > > But if you / others have other suggestions, let me know - appreciate that. > Cheers, Honestly, I am not that keen about enforcing the priorities. It would make sense only when the ordering is really important. Then there should be some rules. It should be obvious why something has to be done earlier than something else.
