Skip to content

Day70 - Notifier Chain

Overview

Today I learned the Linux kernel notifier chain framework, which provides a generic event notification mechanism for communication between kernel subsystems.

Unlike completion or wait queues, notifier chains are designed for one-to-many event propagation. A subsystem can publish an event without knowing which modules are interested in receiving it.

Topics covered:

  • notifier_block
  • blocking notifier chain
  • atomic notifier chain
  • callback registration
  • callback unregistration
  • notifier priority ordering
  • NOTIFY_STOP propagation control
  • event payload delivery
  • dynamic subscriber management

Lab Summary

Lab1 - Basic Blocking Notifier

Implemented a basic blocking notifier chain.

Learned:

  • BLOCKING_NOTIFIER_HEAD()
  • blocking_notifier_chain_register()
  • blocking_notifier_chain_unregister()
  • blocking_notifier_call_chain()

Verified:

  • callback registration
  • callback execution
  • callback unregistration

Lab2 - Priority Ordering

Added notifier priorities.

Verified:

  • higher priority callbacks execute first
  • execution order is determined by priority
  • execution order is not determined by registration order

Example:

CLIENT-B priority=100
CLIENT-C priority=50
CLIENT-A priority=0

Execution order:

CLIENT-B
CLIENT-C
CLIENT-A

Lab3 - NOTIFY_STOP

Tested event propagation control.

Verified:

return NOTIFY_STOP;

stops execution of the remaining callbacks.

Example:

CLIENT-B
CLIENT-C

CLIENT-A is not executed.

Lab4 - Event Payload

Implemented event payload delivery using:

void *data

Created:

struct demo_event_data

Verified:

  • publisher passes event context
  • callbacks receive identical event data
  • notifier chain supports event-specific payloads

Lab5 - Blocking and Atomic Notifier

Implemented:

BLOCKING_NOTIFIER_HEAD()
ATOMIC_NOTIFIER_HEAD()

Verified:

  • blocking notifier registration
  • atomic notifier registration
  • event delivery through both chains

Observed:

in_interrupt=0
preempt_count=0

when called from module_init().

Key understanding:

Atomic notifier does not imply execution inside interrupt context.

Instead:

Atomic notifier callbacks must be safe when called from atomic context.

Lab6 - Dynamic Unregister

Verified runtime removal of subscribers.

Initial chain:

B -> C -> A

After removing C:

B -> A

After removing B:

A

Confirmed:

  • notifier chains behave like callback linked lists
  • unregister immediately removes callbacks from future event delivery

Key Concepts Learned

Notifier Chain

A generic kernel event notification framework.

Provides:

One publisher
Multiple subscribers

without tight coupling.

notifier_block

Represents a callback registration entry.

Contains:

  • callback function
  • priority
  • next pointer

Notifier chains internally maintain linked lists of notifier blocks.

Event Propagation

Publisher:

blocking_notifier_call_chain(...)

Subscribers:

callback(...)

Event information is delivered through:

unsigned long action
void *data

Priority Ordering

Callbacks are executed according to:

Higher priority first

rather than registration order.

NOTIFY_STOP

Allows a callback to stop further event propagation.

Useful when:

  • event is fully handled
  • remaining subscribers should not execute

Blocking vs Atomic Notifier

Blocking notifier:

Sleep allowed
Process context

Atomic notifier:

Sleep not allowed
Atomic-safe callback required

Atomic notifier does not guarantee execution in interrupt context.

Comparison with Previous Topics

Completion

One-to-one synchronization

Used to wait for an operation to finish.

Wait Queue

Condition-based waiting

Used for sleep and wakeup synchronization.

Workqueue

Deferred work execution

Used to move work into process context.

Notifier Chain

One-to-many event notification

Used for event propagation between subsystems.

Takeaways

Notifier chains provide a flexible event broadcast mechanism inside the Linux kernel.

The framework decouples publishers and subscribers while supporting:

  • callback priorities
  • event payloads
  • propagation control
  • dynamic registration and removal

This mechanism is widely used by:

  • CPUFreq
  • Power Management
  • Reboot Notifier
  • Network Subsystems
  • USB Subsystems

and serves as a foundation for many kernel event propagation paths.

Next Steps

Day71:

  • Linux Driver Model Fundamentals
  • Device
  • Driver
  • Bus
  • Matching Process
  • Driver Registration Flow