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

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.