[wylovelyi]

What

修正 Linux 协议栈收包章节中关于「硬件中断处理函数恢复中断」的时机描述。

Why

Closes #362 —— 原文在「硬件中断处理函数会做如下的事情」下列了：

• 接着，发起「软中断」，然后恢复刚才屏蔽的中断。

这与现代 Linux 的 NAPI（中断+轮询）机制不符。NAPI 下，硬件中断处理函数只做两件事：屏蔽该网卡中断 + 通过 napi_schedule() 调度软中断（NET_RX_SOFTIRQ），并不会立即恢复中断就返回。网卡的硬件中断会一直保持屏蔽，直到软中断上下文里的 NAPI poll 函数把 Ring Buffer 中的网络包轮询处理完、调用 napi_complete() 收尾后，才重新开启中断。

若硬中断一退出就恢复中断，软中断（下半部）可能还没被调度执行，下一个包就在几微秒内再次触发硬中断，打断正在排队/执行的软中断，CPU 退化为纯中断模式，甚至可能中断风暴、Ring Buffer 爆满。

权威佐证（多来源一致）：

• kernel-internals.org「Life of a Packet」：hard IRQ handler napi_schedule() + my_nic_mask_irq()（屏蔽中断）后返回；poll 函数末尾 napi_complete_done() 才 re-enable 中断。
• NAPI 实现解析（CSDN / tsight.io 等）：硬中断立即禁用网卡中断→调度 poll；当缓冲区为空（poll 完成）时才重新使能硬中断。
• mirror.xyz「NAPI works through Softirq」：Interrupt Handler 中 disable_device_interrupts() + napi_schedule()；Poll 函数末尾 napi_complete() + enable_device_interrupts()。

How

将 network/1_base/how_os_deal_network_package.md 中该 bullet 改为：硬中断处理函数不会立刻恢复中断，恢复动作发生在软中断 poll 完成（napi_complete）之后。仅改这一句，未改动其他内容、未触及图片或结构。

Verification

• 基线（main）：该 bullet 仅一句「发起软中断，然后恢复刚才屏蔽的中断」。
• 修正后：明确「不会在硬件中断处理函数里立刻恢复」，并补述 NAPI 下中断保持屏蔽直到 poll 完成才重新开启；diff 仅限该行（无整文件重写、无 CRLF 污染）。
• 竞争检索：search/issues?q=repo:xiaolincoder/CS-Base+type:pr+362 无伴生 PR（issue 0 评论、无 assignee、长期无人认领，现补修）。