今天的头条落在相机链路上：Maxim GMSL2/3 的加解串器驱动被整体重写成一套框架， 23 帖、到 v18、一次覆盖 13 款芯片。另一条在内存管理——struct folio 准备和 struct page 分家， mm 里 25 个文件对 folio->page 的旧引用先被清空。
🎬 今日导读
/ section 头条 GMSL2/3 加解串器重写成一套框架：串行器与解串器各一层，13 款芯片共用
头条 struct folio 要与 struct page 分家：mm 里 25 个文件的 &folio->page 先被清空
media camss 加 Kaanapali 到 v17；i.MX952 ISI 到 v4 补 RAW14 与对齐；ov08x40 报「每帧只来第一行」
DRM msm DP 的 MST 支持到 v7（35 帖）；StarFive JH7110 显示子系统到 v5，顺带抽出 Rockchip 共用的 HDMI PHY
mm hugetlb folio 的 swap 支持出 RFC；NeilBrown 为目录锁大改铺路，nfs/afs/cifs/fuse/cephfs 各自让路
net GRO 的 frag_list 包被标记为 DODGY；IPv4 在 connected socket 上用零 IPID
PCI vfio 要把 PCI 错误恢复状态上报给用户态（RFC v2，16 帖）
fs netfs 用 bio_vec 数组链替掉 folio_queue（v13）；Rust 的 fd table 拆除被 Al Viro 连追多轮
机制 INTERNAL pad flag、VFS 目录锁的前夜、memdescs、ptr_eq()
📊 板块活跃度
/ column
数据截至 09-30 06:23 北京，近 24h 各板块真实计数：net 550 · DRM 362 · mm 286 · fs 178 · media 149 · PCI 136 · Rust 104 · block 58 · arch 30 · LSM 22 · rt 21 · virtio 3。 量最大的仍是 net，但今天真正值得花时间的是 media —— 那条 GMSL 系列是一次完整的框架化重写， 不是小修小补。
💡 今日头条
/ sectionGMSL2/3 的加解串器驱动被整体重写：23 帖搭出一套链路框架，一次覆盖 13 款芯片
现状 GMSL 链路是成对使用的——摄像头端的串行器把并行信号并成一路高速串行， SoC 端的解串器再把它还原成 MIPI CSI-2 输出。上游目前有 max96712（还在 staging）、 max96714、max96717 几个驱动，但每个各写各的，覆盖的功能都很窄。
痛点 GMSL 是「一对芯片 + 一条链路」的组合题，难点不在寄存器，而在链路两端怎么协商： VC（虚拟通道）怎么映射、stream id 怎么分配、走 tunnel 模式还是 pixel 模式、 pixel 模式下要不要把两个像素 pack 进一个数据单元、两端 BPP 不同时怎么补 padding。 这些现在要么靠设备树写死，要么根本没实现；芯片一多就是成片的重复代码。
方案 把串行器和解串器各抽出一层框架（15/23、16/23 两帖），芯片驱动只填差异。框架里做了： Streams API（多 link、多 PHY 之间的路由配置）、get_frame_desc / get_mbus_config、 给串行器加 I2C ATR 做地址翻译、GMSL3 与 GMSL2 6Gbps/3Gbps 的自动链路协商、 VC 自动重映射（优先保持原 VC，好给 tunnel 模式留出可能）、tunnel/pixel 模式自动选、 double mode 与 data padding 自动配。合计支持 10 款解串器（含 GMSL3 的 MAX96792A）+ 3 款串行器。
为什么 作者自己说明了取舍：按礼貌应该去扩展现有驱动，但现有驱动支持的功能太少， 扩完实际上等于全部重写——所以干脆新写一套，同系列里把旧驱动删掉 （staging 里的 MAX96712、以及 MAX96714 一并移除）。另一个容易被忽略的前提： 这套东西依赖 media controller 的「内部 pad」概念，所以 01/23 先给 UAPI 加了
MEDIA_PAD_FL_INTERNAL。 效益 对下游厂商，一条 GMSL 链路从「给每对芯片写一份胶水」变成「选框架 + 填芯片差异」； 对做车载 / 工业相机的人，上游终于有了 GMSL 的公共答案而不是各家私货。
下一步 已经是 v18，说明评审大致收敛在细节上。系列注记里有一条人事变化： 原共同作者 Cosmin 已离开 ADI，因为本版改动不大，他的 sign-off 与 tag 按原样保留。
一句话点评 这是本期唯一直接落在「GMSL2 相机链路」上的机制级改动，它的框架分层就是上游对这类链路的官方做法， 值得逐帖读一遍。
🔗 原文
struct folio 准备和 struct page 分家：mm 里 25 个文件的 &folio->page 先被清空
现状 内核用
struct page 描述单个物理页，用 struct folio 描述「一组连续、被当作一个单位管理的页」。为了省一次转换，现在的 struct folio 里 直接内嵌了一个 struct page（就是 folio->page）， 而且 folio 的地址恰好等于它 head page 在 vmemmap 里的地址——这两个事实在很多代码里被当成前提在用。 痛点 只要 folio 还内嵌 page、地址还和 vmemmap 绑定，folio 就没法被动态分配。 这正是 memdescs 计划（把 folio 与 page 彻底拆开）必须先搬走的两块地基。
方案 这一版不碰结构体，只做清理：把 mm/*.c 里剩下的
&folio->page 引用 （分布在 25 个文件）改成不依赖内嵌 page 的写法，只留 mm/debug.c 里三行不动—— 那里要读的 page_type 必须来自活着的 struct page，没有替代写法。 为什么 先把引用清干净、再动结构体，是为了让「结构体变更」那一版的影响面尽可能小： 如果两件事同时做，出问题时分不清是替换写错了还是结构本身变了。
效益 memdescs 这条路又往前挪了一格。对写驱动的普通开发者没有立即可见的变化， 但它决定了未来 folio 怎么被分配。
下一步 系列基于 Andrew Morton mm 树的 mm-unstable 分支，已经在 x86_64 KVM 下带着 THP / hugetlbfs / HUGETLB_PAGE_OPTIMIZE_VMEMMAP / CMA / KSM / userfaultfd / memory-failure 这一堆配置 build 过并启动过。
一句话点评 「先清引用、再换结构」是内核做大规模结构变更的标准节奏，这一条同时也是一个值得记住的推进套路。
🔗 原文
📰 media 摄像头
/ column★ camss 加 Kaanapali 到 v17：CSID 与 VFE 两代 IP 一起补上
定位 Qualcomm 的 camera 子系统驱动（camss），新增 Kaanapali 平台支持—— 属于 SoC 侧 CSI-2 收端那一层。
做法 11 帖里把 CSID 与 VFE 两代 IP（Gen4）以及 CSIPHY v2.4.0 的「两阶段」初始化都补上， 连 TPG（测试图样发生器）v2.4.0 与 arm64 设备树（CCI 控制器、CAMSS 与 CSIPHY 节点、 相机 MCLK pinctrl）一并带来。
效益或下一步 v17 是目前讨论最充分的一版，新平台的相机链路在这条线上已经就绪。
和你相关 如果你在跟 CSI-2 收端驱动，这版新增的看点是 CSIPHY 的「两阶段」上电顺序—— 它决定了多 PHY 配置下链路能不能锁上。
🔗 原文
★ i.MX952 的 ISI 到 v4：RAW14 与对齐问题是这版重点
定位 NXP i.MX8 的图像传感接口（ISI）驱动，加 i.MX952 支持。
做法 11 帖：重排 SoC 数据表、给格式枚举加 mbus_code 过滤、把输出格式掩码扩到 7 位、 新增 RAW14 输出，并处理 i.MX95 上 RAW 输出的 MSB/LSB 对齐与运行期 workaround。
效益或下一步 RAW10/12/14 的对齐处理是这版的核心，也是 sensor 到 ISP 之间最常见的对不上原因之一。
和你相关 RAW 输出的对齐（MSB-aligned 还是 LSB-aligned）如果两边理解不一致， 表现就是整幅图偏色或过曝，而寄存器看起来全对——这正是这类补丁在收的坑。
🔗 原文
★ ov08x40 的「每帧只来第一行」：一份没有补丁的 bug 报告
定位 位置在 sensor 驱动 + Intel IPU7 收端这条链路上，是一份纯粹的 bug report，暂时没有补丁。
做法 Dell XPS 14 上，ov08x40 用 2-lane / 1928x1088 / 1500Mbps 这一组参数时， 每帧只收到第一行；换别的模式正常。
效益或下一步 「只有某个参数组合不工作」通常指向 lane 数 / link frequency 与实际不匹配， 或者收端的 settle 参数没跟着这组速率调整。
和你相关 这类报告比补丁更值得读——它是真实硬件给出的症状，而且是相机 bring-up 里最难查的那一类： 参数组合里只有一组坏。
🔗 原文
📰 DRM 显示
/ column★ msm DP 补 MST 到 v7：35 帖把「一路流」的前提拆掉
定位 Qualcomm 显示子系统里的 DP 控制器驱动。MST（多流传输）是 DP 里结构最复杂的一块—— 一根线带多个显示器，控制器要为每个显示器维护一套独立状态。
做法 35 帖。给每个 panel 引入 stream_id、把寄存器访问全部改成 stream-aware、 把 link 级操作与流级操作分离（新增 link_ready）、DPU 侧按 stream 分配编码器、 新增 dp_mst_drm 模块承接 connector 与拓扑回调；还顺手改了共享层 drm_bridge_connector，让 IRQ_HPD 在状态没变时不要触发 hotplug。
效益或下一步 改到 v7 已经触及 drm_bridge_connector 这种共享代码，说明评审走到了「影响面」阶段， 不再是驱动内部自娱自乐。
和你相关 MST 的实现是「单实例驱动改造成多实例驱动」的教科书案例： 所有原本是一个变量的状态都要变成 per-stream 结构，漏一个就是错乱。
🔗 原文
★ StarFive JH7110 显示子系统到 v5：顺带抽出 Rockchip 也在用的 HDMI PHY
定位 RISC-V 板子（VisionFive 2 那一类）的整条显示链路：VOUT → DC8200 控制器 → Innosilicon HDMI。
做法 21 帖。核心是把 inno-hdmi 通用化：probe 从 bind 里拆出来、寄存器映射允许来自父节点、 PHY 配置表变成可选、加 mode_valid / disable 平台回调、时钟源可选择； 然后把 Rockchip 那版 inno-hdmi 也改成复用同一套 Innosilicon PHY 公共代码。
效益或下一步 两家共用的 IP 被抽成公共层，重复实现少了一份。
和你相关 「把两个厂商共用的 IP 抽成公共代码」和头条 GMSL 那条是同一个思路： 先承认重复，再决定在哪一层收敛。
🔗 原文
★ 一个头文件重构引发的构建回归：7 个驱动补 include
定位 drm_panel.h 的重构把
devm_drm_of_get_bridge() 的声明搬了家， 但部分调用方没有一起改 include，某些配置下直接编译不过。 做法 v2 的 7 帖把 imx/lcdc、verisilicon、dw-mipi-dsi、dw-mipi-dsi2、vc4 的 dpi/dsi、 renesas shmobile 全部补上正确的头文件。
效益或下一步 修复保持最小，只补 include，不动逻辑。
和你相关 如果你最近 rebase 到 -next 上编译报
devm_drm_of_get_bridge 隐式声明， 就是这条。 🔗 原文
📰 mm 内存管理
/ column★ hugetlb folio 也想被 swap：RFC 六帖试探这条路
定位 hugetlb 与 swap 在内核里长期是两套机制——hugetlb 页被排除在通用的回收与换出路径之外。
做法 RFC 6 帖，提出让 hugetlb folio 走 swap 路径。
效益或下一步 还在 RFC 阶段，是探索性的；但方向明确——把 hugetlb 接进通用的换出机制。
和你相关 hugetlb 与常规页的机制分家是历史遗留，任何「合流」的尝试都会牵动大量假设， 这也是它至今没做的重要原因。
🔗 原文
★ NeilBrown 给目录锁大改铺路：先从「不要抱着 i_rwsem 调 d_alloc_parallel()」开始
定位 VFS 层的目录锁。中期目标是把
d_alloc_parallel() 的上锁位置 抬到 i_rwsem 之上，让它能在不持有 i_rwsem 的情况下运行。 做法 本系列是「多个文件系统各自的一小改」（nfs、afs、cifs、fuse、cephfs 的系列单独发）。 对维护者的两条要求：不能在持有 i_rwsem 时调 d_alloc_parallel() （改用 d_alloc_trylock() / d_duplicate()，或者先放锁再取）； 不能在操作进行中 d_drop()，否则 unlocked 的 d_alloc_parallel() 会造出同名 dentry。
效益或下一步 这类「先说清约束、再逐个子系统让路」的推进方式，是锁改造能落地的前提。
和你相关 如果你在跟任何文件系统的 dentry 生命周期代码，这两条约束就是接下来会被反复引用的规则。
🔗 原文
★ DAMON 与 virtio-balloon，被 DeepSeek 的 DSec 论文点了名
定位 一条 [FYI] 帖引出的跨域讨论，参与者包括 DAMON 维护者与 DeepSeek 的工程师。
做法 DeepSeek 的工程师在 mm 列表上回应：DAMON 与 virtio-balloon 的空闲页上报 对他们的负载很有用；同时说明他们对 virtio-pmem 的顾虑—— 把 I/O 放到 page fault 路径上会带来性能取舍，另外大镜像的 struct page 开销也不小。 目前只在「中等大小、频繁使用的只读镜像」上开 virtio-pmem。
效益或下一步 DAMON 维护者 SJ Park 回复确认：这正是当初做这套东西的动机之一。
和你相关 这是少见的「工业界负载直接反馈到内核列表」的现场，而且来自国内团队—— 比读论文摘要更能看清这些机制实际被怎么用。
🔗 原文
📰 net 网络
/ column★ GRO 合并出来的包「不可全信」：新增一个 DODGY 标记
定位 GRO（收包合并）在 frag_list 模式下会把多个 skb 串成一条链。 当链里某个元素的长度超过 gso_size，下游按 GSO 规则切包就可能切错边界。
做法 检测到这种情况，就把这个包标记为
SKB_GSO_DODGY。 效益或下一步 让软件 GSO / 转发路径知道这个包的合并结果不可全信，避免按错误边界切分。
和你相关 DODGY 是内核里已有的「这个 skb 不可信」约定，这次是把一个之前没被覆盖的 GRO 路径接进同一套契约。
🔗 原文
★ connected socket 上的原子数据报：IP ID 直接写 0
定位 IPv4 的 IP ID 字段在分片重组与去重里有语义；但对 connected socket 上的 原子数据报（DF=1、不允许分片）来说，它其实没有意义。
做法 这类报文统一使用 IP ID = 0。
效益或下一步 省掉一次原子操作，同时让报文更符合规范——RFC 6864 认可这种用法。
和你相关 典型的「含义已经消失但代码还在维护」的字段，收掉它对抓包分析也更友好： IP ID 为 0 本身就是「这条不重要」的信号。
🔗 原文
★ ice 网卡驱动本轮到货：10 帖走 pull request
定位 Intel 有线网卡驱动（ice）的例行更新，以 net-next 的 pull request 形式提交。
做法 10 帖打包，由维护者统一收口。
效益或下一步 这类批量更新能看出维护者树当前正在收什么，也是网卡驱动改动的主要入口。
和你相关 看 pull request 比看单条补丁更省时间——它是维护者已经筛过一遍的结果。
🔗 原文
📰 PCI
/ column★ vfio 要把 PCI 错误恢复的状态告诉用户态：RFC v2 十六帖
定位 vfio 把物理 PCI 设备直通给虚拟机时，设备出错（AER）之后的恢复路径 一直没有完整暴露给用户态——虚拟机只看到设备「不见了」。
做法 RFC v2 共 16 帖，处理 PCI error recovery，并把设备状态上报给 userspace。
效益或下一步 还在 RFC 阶段，对做设备直通与虚拟化的人来说是长期缺口的补课。
和你相关 「错误恢复该怎么跨过直通边界」是 vfio 反复讨论的老问题： 恢复流程在内核侧，但决定要不要恢复的往往是虚拟机里的驱动。
🔗 原文
★ dw-rockchip 打开 INTx affinity
定位 Rockchip 的 DesignWare PCIe 控制器驱动，中断路径这一层。
做法 开启 INTx 的 affinity 支持。
效益或下一步 老式的 INTx 中断也能被绑定到指定 CPU，不再全压在一个核上。
和你相关 RK3588 上挂 PCIe 设备时，如果设备走的是 INTx 而不是 MSI，中断分布会直接影响吞吐。
🔗 原文
★ SMMUv3 补上运行时与系统休眠支持：v11，十六帖
定位 SMMUv3 是 arm64 上做 DMA 地址翻译的那一层，它的状态直接决定设备能不能继续访问内存。
做法 16 帖实现 Runtime / System Sleep 两组 ops。
效益或下一步 系统进休眠时 SMMU 的上下文要能正确保存与恢复，这是 SoC 进低功耗态的前提。
和你相关 IOMMU 的挂起恢复一旦不完整，症状通常是休眠唤醒后设备 DMA 直接打飞—— 而这类 bug 只在特定电源状态下出现。
🔗 原文
📰 fs 文件系统
/ column★ netfs 用 bio_vec 数组链替掉 folio_queue：到 v13
定位 netfs 是网络文件系统的通用读路径，iov_iter 是内核里描述「一段一段缓冲区」的迭代器抽象。 两者交界处目前用的是专用的 folio_queue 结构。
做法 v13，10 帖，改用一个由 bio_vec 数组组成的链来替代 folio_queue。
效益或下一步 把网络文件系统的页管理收敛回通用的 bio_vec 表示，少一层专用结构要维护。
和你相关 这类「专用结构回退到通用抽象」的重构，判断标准通常是： 专用结构带来的收益还值不值得它多出来的维护成本。
🔗 原文
★ Rust 的 fd table 拆除：Al Viro 亲自盯了几轮
定位 Rust 抽象里的 file 层：文件描述符表被拆除的过程中， 文件相关的 API 该怎么处理生命周期。
做法 v2 帖在列表上被讨论得很细，Al Viro 参与了多轮往返。
效益或下一步 fd table 拆除期间的并发窗口，正是最容易出 use-after-free 的地方。
和你相关 Rust 抽象最难的部分从来不是语法，而是「C 侧那些没写下来的生命周期约定」—— 这条线程就是把这个约定逐条问出来的过程。
🔗 原文
📰 virtio
/ column★ virtio-blk 的 inline encryption：从 8 月底更到 v5，占了 virtio-dev 近期的大半
定位 virtio 的块设备。inline encryption 指的是把加密请求下沉到 host / 设备侧完成， 而不是在 guest 里用软件加密。
做法 v5、2 帖。抓取的 virtio-dev 最近 20 条里，这条系列占了 14 条， 从 08-28 一路更到 09-29。
效益或下一步 数据在离开 guest 之前就被加密，是云上磁盘加密的常见诉求。
和你相关 virtio-dev 是低频列表，一条系列占到近期流量的七成， 说明这个特性在虚拟化存储里是被真实需要的。
🔗 原文
📰 block
/ column★ NVMe 的原子性不止一种：RFC 提议 Multiple Atomicity Mode
定位 NVMe 的原子写语义。传统上设备只声明一个「原子写单元」的粒度， 上层要么依赖它、要么自己加软件保证。
做法 RFC 2 帖：block 层新增
BLK_FEAT_ATOMIC_WRITE_MULTI， NVMe 侧启用多种原子性模式。 效益或下一步 对数据库这类依赖原子写的负载，可以按需要选择不同等级的保障。
和你相关 「原子写粒度」是存储栈里少数几个一旦定死就很难改的假设，动它必然牵动上层文件系统。
🔗 原文
📰 Rust
/ column★ Rust 的转换派生宏到 v6：把 From 的穷尽性支持补齐
定位 Rust for Linux 的宏层——为 From / TryFrom 提供派生宏。
做法 v6，10 帖，在派生宏之外补上「穷尽的 From」支持，并加了对应的 doctest。
效益或下一步 Rust 抽象里大量手写的转换 impl 样板可以省掉。
和你相关 Rust for Linux 的推进有两条腿：内核 API 绑定，和让写绑定这件事本身更省力。 这个系列属于后者。
🔗 原文
更多动态
○ media: i2c: Add Omnivision ov05c10 sensor driver（Sakari Ailus 提交的新 sensor 驱动） 〔09-29 20:18〕
○ media: mali-c55: Fix IRQ lifetime and wake handling（IRQ 生命周期与唤醒处理） 〔09-29 20:02〕
○ media: rockchip: rga: fix rotation on rev0 hardware（v3） 〔09-29 17:41〕
○ accel/amdxdna: Add support for AIE2 revision 9 〔09-30 02:15〕
○ drm/tyr: add VM and BO ioctl support（v3，新驱动继续补 ioctl） 〔09-29 10:16〕
○ gpu/buddy: fix missing split-undo on allocation-search exhaustion 〔09-29 18:54〕
○ PCI/MSI: Clear msi_desc::irq in the legacy teardown path 〔09-29 19:10〕
○ ublk: use global index for reported zones 〔09-29 15:00〕
更多动态
○ Cleanup and Refactor TI-SCI driver（22 帖重构） 〔09-30 04:18〕
○ sched/fair: Take slice protection into account when arming HRTICK 〔09-30 03:47〕
○ cpu/hotplug: use cpu_enabled_mask for SMT bringup（RFC） 〔09-30 03:41〕
○ Hyper-V: root VM iommu kernel only driver（V2） 〔09-30 06:36〕
○ net: stmmac: Disable checksum insertion for XDP frame TX 〔09-29 20:30〕
○ net: bcmasp: fix lost TX wakeup race with lockless queue API（v2） 〔09-30 04:34〕
○ fuse: propagate SB_POSIXACL to submounts 〔09-29 17:48〕
○ rust: io: Fix Region::drop releasing nested resources from the wrong parent 〔09-30 01:46〕
📌 机制雷达：4 条跨域大改动
/ section INTERNAL pad flag 给 V4L2 的 pad 加一个「内部 sink pad」标志，用作 [GS]_ROUTING 的流起点； 同时禁止对内部 pad 建 link、禁止 source pad 带这个标志。 它是 GMSL 那套框架的前置依赖——UAPI 先动，驱动才能跟上。 原文
VFS 目录锁的前夜 把 d_alloc_parallel() 的上锁位置抬到 i_rwsem 之上。 这一条今天以「多个文件系统各自让路」的形式出现（nfs / afs / cifs / fuse / cephfs 各自成系列）， 属于先改约束、再改实现的典型打法。 原文
memdescs 让 struct folio 不再内嵌 struct page、地址也不再等于 vmemmap 里的 head page。 今天这一步只是清引用（25 个文件），但它是结构体本身变更的前置动作。 原文
ptr_eq() hazptr 系列给编译器一个显式表达「这两个指针相等」的手段， 用来保住地址依赖（address dependency）不被优化掉——RCU 类代码的经典雷区。 线程里能看到 Linus 的参与（回复挂在 CAHk- 的 message-id 下）。 原文
📖 本期概念速查
/ section 串行器 / 解串器（serializer / deserializer） GMSL、FPD-Link 这类车载与工业相机链路是成对使用的：串行器在摄像头端 把并行信号并成一路高速串行，解串器在 SoC 端还原成 MIPI CSI-2 输出。 本期头条的 MAX96717 / MAX9295A 是串行器，MAX96712 / MAX9296A 是解串器。
tunnel 模式 / pixel 模式 GMSL 解串器把收到的数据转成 CSI-2 时有两条路： tunnel 是原样透传（要求虚拟通道号不变）， pixel 是解出像素再重新打包（可以做 VC 重映射、double mode、padding）。 后者更灵活但多一次处理，所以框架会自动判断能不能走前者。
VC（Virtual Channel） MIPI CSI-2 在一条物理链路上用虚拟通道号区分不同数据流（比如多个摄像头）。 上游有多个源要汇到同一个 CSI-2 输出时，VC 号必须保持唯一——这正是框架要做自动重映射的原因。
I2C ATR（Address Translation） GMSL 链路里 SoC 侧通过 I2C 访问远端芯片。若解串器不支持按链路做 I2C 通道屏蔽， 就没法用常规 mux 选路——只能改用地址翻译：在 probe 时把远端芯片的地址改掉。
struct folio 与 memdescs folio 描述「一组连续、被当作一个单位管理的页」。memdescs 是把它与 struct page 彻底拆开的长期计划：不再内嵌、地址也不再相等，从而允许 folio 被动态分配。
d_alloc_parallel() 与 i_rwsem d_alloc_parallel() 负责在目录里查找或创建一个 dentry，i_rwsem 是 inode 层的读写信号量。 目前前者经常在后者的保护下调，VFS 想把这两者的关系解开——本期 mm 那条就是在铺路。
SKB_GSO_DODGY skb 上的一个标记，含义是「这个包的合并/分段信息不可全信，下游别按它推断边界」。 本期 net 那条把 frag_list 形式的 GRO 也接进了这个契约。
inline encryption 把加密下沉到设备侧完成（而非在 guest 或主机 CPU 上做软件加密）， 本期出现在 virtio-blk 的提案里，是云上磁盘加密的常见做法。
如果对你有用，点个赞，或转给做相机的朋友。
数据来源：lore.kernel.org（全内核 13 列表）· 北京时间