Hi Song, On Wed, 15 Apr 2026 15:01:37 +0800 [email protected] wrote:
> From: Song Chen <[email protected]> > > The current notifier chain implementation uses a single-linked list > (struct notifier_block *next), which only supports forward traversal > in priority order. This makes it difficult to handle cleanup/teardown > scenarios that require notifiers to be called in reverse priority order. What about introducing a new notification callback API that allows you to describe dependencies between callback functions? For example, when registering a callback, you could register a string as an ID and specify whether to call it before or after that ID, or you could register a comparison function that is called when adding to a list. (I prefer @name and @depends fields so that it can be easily maintained.) This would allow for better dependency building when adding to the list. > > A concrete example is the ordering dependency between ftrace and > livepatch during module load/unload. see the detail here [1]. If this only concerns notification callback issues with the ftrace and livepatch modules, it's far more robust to simply call the necessary processing directly when the modules load and unload, rather than registering notification callbacks externally. There are fprobe, kprobe and its trace-events, all of them are using ftrace as its fundation layer. In this case, I always needs to consider callback order when a module is unloaded. If ftrace is working as a part of module callbacks, it will conflict with fprobe/kprobe module callback. Of course we can reorder it with modifying its priority. But this is ugly, because when we introduce a new other feature which depends on another layer, we need to reorder the callback's priority number on the list. Based on the above, I don't think this can be resolved simply by changing the list of notification callbacks to a bidirectional list. Thank you, -- Masami Hiramatsu (Google) <[email protected]>
