On 17/05/2022 10:11, Petr Mladek wrote: > [...] >> You mentioned 2 cases: >> >> (a) Same notifier_list used in different situations; >> >> (b) Same *notifier callback* used in different lists; >> >> Mine is case (b), right? Can you show me an example of case (a)? > > There are many examples of case (a): > > [... snip ...] > These all call the same list/chain in different situations. > The situation is distinguished by @val. > > >> You can see in the following patches (or grep the kernel) that people are using >> this identification parameter to determine which kind of OOPS trigger >> the callback to condition the execution of the function to specific >> cases. > > Could you please show me some existing code for case (b)? > I am not able to find any except in your patches. > Hi Petr, thanks for the examples - I agree with you. In the end, seems I'm kind of abusing the API. This id is used to distinguish different situations in which the callback is called, but in the same "realm"/notifier list. In my case I have different list calling the same callback and (ab-)using the id to make distinction. I can rework the patches using pointer comparison, it's fine =) So, I'll drop this patch in V2. > Anyway, the solution in 16th patch is bad, definitely. > hv_die_panic_notify_crash() uses "val" to disinguish > both: > > + "panic_notifier_list" vs "die_chain" > + die_val when callen via "die_chain" > > The API around "die_chain" API is not aware of enum panic_notifier_val > and the API using "panic_notifier_list" is not aware of enum die_val. > As I said, it is mixing apples and oranges and it is error prone. > OK, I'll re-work that patch - there's more there to be changed, that one is complex heheh Cheers!
