[2/4] The Wait Still Works in a NAPI Thread

Does the same shutdown wait still work when NAPI runs in a dedicated thread? I follow the entry and exit paths in Linux 7.3, including PREEMPT_RT, and consider the synchronization choices left to a driver author.

The ordinary receive-softirq path encloses the whole poll. But a dedicated NAPI thread has another entry point. I need to find its matching protection rather than assume the earlier explanation still applies.

Threads do not remove the protection

A dedicated NAPI thread takes another route:

napi_threaded_poll()
  napi_threaded_poll_loop()
    local_bh_disable()
      __napi_poll()
        driver poll, including its final enable
    local_bh_enable()

BH means bottom half, referring here to softirq-side processing. On a non-RT kernel, this BH-disabled region is covered by RCU synchronization.

With PREEMPT_RT, BH-disabled tasks can be preempted. That requires a different mechanism. In Linux 7.3, the RT implementation of __local_bh_disable_ip() explicitly calls rcu_read_lock() on the outermost entry from a preemptible context. The matching exit calls rcu_read_unlock(). Entry from an already non-preemptible context relies on that protection instead.

RCU tracks readers preempted inside an explicit read-side region. Switching to another task does not make the suspended poll disappear from the wait.

For RT receive processing through ksoftirqd, the enclosing ksoftirqd_run_begin() and ksoftirqd_run_end() provide the corresponding BH entry and exit. In the paths examined here, protection therefore extends through the interrupt enable. This is not a proof covering every other entry, such as userspace-driven busy polling.

The question the documentation leaves open

Does the NAPI guide require these two functions together? No. It warns against data-structure access after completion, yet its example unmasks interrupts afterward. It does not spell out how that unmask should synchronize with shutdown.

That leaves a boundary for driver authors and reviewers to examine. It does not prove that documentation gaps caused bugs, or that different synchronization methods are wrong.

I cover NAPI shutdown races in Getting Started with Linux Device Drivers, Volume 3. Reading beyond the suspicious line gave me something useful to pass to the next reader.

That line of synchronization had a purpose. How did other drivers handle shutdown? In Intel's igb, I found a flag check intended to prevent interrupts from being enabled while the device was down. But what if another CPU advanced shutdown just after that check? Next, I follow what happens in that gap.