今天有两件事值得看完：一份 41 补丁的 RFC 把内核的用户身份从 32 位扩到 128 位， 让 Active Directory 的 objectGUID 直接成为文件属主；以及 RK3588 的 HDMI 连接器第一次有了完整的 BT.2020 色彩空间路径， KWin 的 HDR 开关因此有了上游基础。除此之外，zram 把压缩流与解压流拆开， 读取延迟的秒级尖峰被压到毫秒级。

封面 · 10月19日 · 内核身份升到 128 位

📊 板块活跃度

/ column
板块活跃度条形图 · 近 24h · 全 12 列表

数据截至 10-19 06:51 北京，近 24h 各板块真实计数：net 333 · mm 87 · DRM 85 · LSM 67 · fs 58 · media 25 · block 25 · PCI 19 · arch 14 · rt 10 · Rust 9 · virtio 0。net 的量仍由 pse-pd、CAN、XDP 测试与 xfrm 修复撑起，但今天真正动地基的 在 fs/cred：128 位身份与「同一用户」检查的收拢 同一天出现。virtio-dev 近 24h 静默。

💡 今日头条

/ section

用户 ID 不再只是 32 位：内核 RFC 把 UUID / GUID 变成一等身份

〔10-19 02:01 北京〕· [RFC PATCH 00/41] UUID and GUID user and group ids (*_r system calls)（Jan Koester）

现状 内核里的用户和组身份一直是 32 位数：kuid_t/kgid_t 包着一个 u32，凭据、文件属主、ACL、keyring、socket 对端、 信号发送者、procfs 与 audit 记录都以这个数字为中心。目录服务不是这样命名用户的—— Active Directory 用 128 位 objectGUID（以及 SID），LDAP 目录常用 entryUUID。
痛点 今天所有服务这类用户的系统（winbind、sssd、nfsidmap、ksmbd 的用户态）都要把 128 位 id 映射成 32 位：按区间、按哈希或本地数据库。映射在不同机器上不一致， 除非处处同样配置；映射可能碰撞；写到共享存储或备份里的属主还取决于哪台机器写的。
方案 Jan Koester 的 RFC 0/41 把 kuid_t/kgid_t 换成 tagged union（legacy 数字 / UUID / GUID），没有映射表，内核直接比较、哈希、 存储整个 id。新增 _r 系统调用家族（getuid_r、 setresuid_r、setgroups_r、fchownat_r 等）， 参数是 20 字节的 __kernel_uid_r_t；既有接口补上 STATX_UID_R、SO_PEERCRED_R、 SCM_CREDENTIALS_R、si_uid_r、 IPC_STAT_R、KEYCTL_CHOWN_R 与 POSIX ACL xattr v3。 文件系统必须声明 SB_I_UID_R 才能存这类属主：tmpfs、ramfs、devpts、 条件性的 overlayfs，以及带只读兼容 uid_r 特性（256 字节 inode）的 ext4； NFSv4 与 ksmbd 用文本或 SID 承载。
为什么 边界划得很清楚：UUID/GUID 只存在于初始 user namespace，不进入任何 uid_map/gid_map，在其他 namespace 里显示为 overflow id，子 namespace 的任何 capability 都不能对它们提权；idmapped mount 原样透传。经典系统调用保持 32 位语义， 遇到 UUID 用户返回 overflow id，跟 16 位调用处理 65535 以上的方式一致。 20 字节结构在所有 ABI 上布局相同，因此不需要 compat 入口。
效益 目录服务给出的 id 就是磁盘上的属主，也是每个凭据里的 id，不需要映射表。 作者给了测试：selftests 14/14，QEMU 启动测试 88/88，并在打过补丁的 libc、 e2fsprogs、OpenSSH、rsync、ksmbd/NFS 全套上验证 UUID 用户能 ssh 登录、 在 ext4 上拥有文件、访问 ksmbd 与 NFSv4 共享。
下一步 作者把三个问题留给评审：kuid_t 用 tagged union 是否可接受，还是把 128 位 id 放在 u32 kuid_t 旁边；20 个 _r 调用是否该合并成一个 setid_r(which, ...)；以及是否按子系统拆成 core/fs/net/ext4/nfsd 几批。系列基于 v7.3-rc7，系统调用号 473–492 只是占位。
一句话点评 这不是加一个特性，而是拆掉「uid 是 32 位」这个贯穿几十年的假设。能否合入取决于维护者对 kuid_t 布局与 ABI 扩张的容忍度，但它已经把「目录身份直接落到磁盘」这条路径完整走通了。

🔗 原文

RK3588 的 HDR 缺口：HDMI 连接器终于能声明 BT.2020

〔10-18 22:32 北京〕· [PATCH v4 0/7] drm: Add colorspace property support to the HDMI helpers（Jan Claußen）

现状 DRM 的 HDMI 连接器通过 drmm_connector_hdmi_init() 初始化， 负责向用户态暴露色彩空间与 HDR 相关属性。问题是这条 helper 路径一直没有创建 colorspace property。
痛点 用户态合成器需要这个 property 来声明 BT.2020。没有它，KWin 这类合成器 不会提供 HDR 选项——即使底层 HDMI 控制器和屏幕都支持。
方案 v4 七补丁让驱动声明自己支持哪些色彩空间，由 HDMI helper 统一创建 property， 并在值变化时强制一次 modeset；bridge connector 把支持列表传给 HDMI helper； rockchip 的 dw_hdmi_qp 转发平台数据里的支持列表，并从连接器的色彩空间设置 VOP2 的 color space，最后声明 BT.709 与 BT.2020。
为什么 v3 按 Maxime 的意见把处理搬进 HDMI helper，并改成「驱动声明」而不是 「向用户态暴露全部」；v4 按 Sashiko 的评审补上 VOP2 色彩空间， 让 YCbCr 输出使用匹配的转换矩阵。改动总量不大（8 个文件、+58/−5）， 因为这层抽象本来就在。
效益 作者在 Radxa Rock 5B（RK3588）+ LG OLED55B87LC 上、KDE Plasma 6.7.5 里 验证 BT.2020 RGB 可用；dw-hdmi-qp 是第一个用户。
下一步 目前只测了 BT.2020 RGB。更多色彩空间需要各驱动声明并补测试；对 RK3588 的 HDR 支持来说，这是上游第一次有完整路径。
一句话点评 这是 helper 建 property、bridge 传能力、VOP2 设矩阵的三层配合。单独看每一层都很小，合起来才是 HDR 从驱动到合成器的一条通路。

🔗 原文

📰 fs 文件系统

/ column

★ 「同一用户」的检查收进一个文件：12 处 uid_eq 不再各写各的

〔10-19 01:31〕· [PATCH 00/13] cred: gather the same uid checks between tasks in one place（Josef Bacik）

定位 内核里有十几处允许一个任务操作另一个任务的检查：kill()、SIGIO、 sched 系统调用、setpriority()、ioprio_set()、 prlimit()、ptrace、cgroup v1 迁移、resctrl、 KEYCTL_SESSION_TO_PARENT。每一处都手写几个 uid_eq()， 而且分六种口味：看 real/effective/saved 的哪些、euid 0 是否放行。
做法 Josef Bacik 的 13 补丁把它们收进 kernel/cred.c，提供 cred_ids_allow_signal、_sigio、_sched、 _control、_move、_ioprio 等 helper， 并附一张「哪条规则看哪些 id」的表；逐个转换调用点。唯一不是纯替换的是 fcntl F_SETOWN：它改为持有 cred 引用，而不是复制 uid/euid。
效益 行为按设计完全不变（这些语义已经是 ABI），附 KUnit 测试逐项对照原表达式； 作者还在 KASAN + lockdep 下跑了 64 种 real/effective/saved 组合、共 576 个结果， 前后一致。意义在于：当「同一用户」的定义要改时，只有一处需要改。
和你相关 和今天的 UUID RFC 是同一块地基的两面：身份类型要扩，权限判断就得先能审计。

🔗 原文

★ 文件直接绑定 dma-buf：direct I/O 不再逐命令做 DMA 映射

〔10-19 06:18〕· [RFC 0/4] fs: support dma-buf backed direct I/O（Nitesh Shetty）

定位 当前 direct I/O 的路径按命令做 DMA 映射：应用提交一次读写，块层与驱动 在每次 I/O 上建立映射。对已经在 dma-buf 里的 GPU/NPU 缓冲区，这是重复工作。
做法 应用把 dma-buf 注册到某个文件上，之后的读写直接变成 dma-buf backed bio； 系列建立在 Pavel Begunkov 的 dma-buf block 支持 v11 之上（已在 Jens Axboe 的 for-7.4/io_uring-dmabuf 分支排队），并在 block 层抽出 bdev_init_dma_buf_io_ctx()、拒绝未注册磁盘的 dma-buf bio， iomap 加 guard 与注册 helper，xfs 接上 direct I/O。
效益 对相机/GPU/NPU 的数据通路少一次映射与拷贝；接口还在 RFC 阶段。
和你相关 camera 链路里 dma-buf 是 sensor→ISP→GPU 的标准载体。这个方向一旦落地，零拷贝的边界会从「驱动内部」推到「文件 I/O」。

🔗 原文

📰 media 视频采集

/ column

★ Surface Pro 11 的 OV13858 上了设备树：ARM 笔记本相机补上 OF 路径

〔10-19 05:10〕· [PATCH v2 0/2] media: ov13858: device tree support for the Surface Pro 11 (Snapdragon)

定位 OV13858 是 OmniVision 的 13MP sensor。Surface Pro 11（Snapdragon X Elite， X1E80100）的后摄挂在 Qualcomm CAMSS 上，走四条 D-PHY lane；但现有驱动只有 控制与视频路径，没有 OF/endpoint 支持。
做法 两个补丁补 dt-bindings 与 OF endpoint 支持，v2 以 Sergey 的 runtime-PM 工作 （v4）为前提。作者在 Snapdragon 机型上跑了 20 次 open/stream/close， 每次都在 session 之间 runtime-suspend 并重新出流，另存了 3 帧完整 4224x3136 RAW10；Intel Surface Pro 11 上由 Sergey 测到 29.95 fps、v4l2-compliance 46/46。
效益 ARM 笔记本的相机 bring-up 多了一个可复用的 DT 与 PM 组合； Snapdragon 机型的 suspend/resume 尚未测试，作者明确不作承诺。
和你相关 GMSL2/CSI-2 sensor 的 bring-up 也是同一套骨架：DT endpoint、runtime-PM、用 compliance 与连续出流验证。

🔗 原文

★ 改 vblank 会顺手改掉曝光：imx415 用了过期的 vmax

〔10-18 20:54〕· [PATCH] media: i2c: imx415: Use target vblank to calculate vmax in s_ctrl

定位 V4L2 的 V4L2_CID_VBLANK 与 V4L2_CID_EXPOSURE 在 sensor 驱动里耦合：imx415 在设置 vblank 时先把新的 frame length 写进 IMX415_VMAX，再按 VMAX − exposure 更新快门寄存器。
做法 问题出在第二步：s_ctrl() 里 sensor->vblank->cur.val 还是旧的提交值，新值要等回调返回 0 才生效。补丁改用 sensor->vblank->val（本次正在应用的目标值）。
效益 改变帧率时曝光不再随 blanking 差值跳变；带 Fixes 与 stable 标签， 属于控制框架提交时序的典型 bug。
和你相关 调 sensor 时 vblank、曝光、帧率三者互相约束，这类「用错当前值/目标值」的错误很容易在长时间曝光或高帧率切换时暴露。

🔗 原文

📰 mm 内存管理

/ column

★ zram 拆开读流与写流：读延迟尖峰从 3 秒降到 6 毫秒

〔10-18 11:51〕· [PATCH v5 00/13] zram: redesign zcomp and rework backends（Sergey Senozhatsky）

定位 zcomp 是 zram 的压缩后端层。它长期把读（解压）和写（压缩）上下文放在同一套 per-CPU stream 里；在可抢占内核上，高优先级的 Reader 可以抢占正持有 stream 锁的 Writer，然后阻塞在同一把锁上——典型优先级反转。
做法 v5 十三补丁把压缩流拆成 per-CPU 的读流与写流（Barry Song）；无状态后端 引入共享解压流（Brian Geffon）；有状态后端（zstd、deflate）则在 Reader 被抢占时借用其他 CPU 的空闲独占解压上下文；另为跨 zsmalloc 对象的请求 分配 per-request bounce buffer。前半段还有一批压缩后端的内存与错误路径修复。
效益 独占 zstd 的后台读：IOPS 391k→1064k（2.7x），平均延迟 49.07→9.68 µs， 最大延迟 3.21 s→5.88 ms；共享 lz4：972k→1466k（+50.9%），最大延迟 2.20 s→6.44 ms。
和你相关 嵌入式设备大量用 zram 做 swap；换入路径的秒级尖峰会直接变成界面卡顿。

🔗 原文

📰 net 网络

/ column

★ stmmac 的 XDP 终于看到完整帧：多缓冲 RX 支持到 v8

〔10-19 01:07〕· [PATCH net-next v8 0/5] net: stmmac: introduce XDP rx multi-buff support

定位 stmmac 是 Synopsys DesignWare 的以太网 MAC，Rockchip 的 GMAC 也走这条驱动。 它的 XDP 路径原先只用第一个描述符构造 xdp_buff， 跨多个描述符的帧对 XDP 程序不可见。
做法 v8 重写 stmmac_rx()，用组成一帧的全部描述符构造 xdp_buff；修掉关闭/打开接口时的 rx_q 状态泄漏；新增非线性和 帧的 VLAN tag 剥离修复；AF_XDP zero-copy 尚不支持 multi-buff，改为直接丢弃 这类帧；同时补上 multi-buffer 帧在 XDP 模式下的既有 bug。
效益 XDP 程序能在分片/多缓冲帧上解析完整包，VLAN 解析不再错位；这是 v8， 说明该路径已经过多轮评审。
和你相关 RK3588 板卡的以太网就是 stmmac；如果板上有 XDP/转发程序，这个版本值得跟踪。

🔗 原文

📰 DRM / GPU

/ column

★ AMD 回退 vblank 合并：gfx1201 多显示器出现画面损坏

〔10-19 00:45〕· [PATCH 0/3] drm/amd/display: revert vupdate_no_lock vblank consolidation

定位 AMD display 最近把 vblank 处理合并到 vupdate_no_lock 路径， 本意是简化记账。
做法 gfx1201 多显示器上出现显示损坏，作者用三补丁回退这次合并。同日另有一条 7.3 回归报告：DCN32 在 120 Hz 下自 a637a140ab86 起出现单帧 扫描输出损坏。
效益 gfx1201 多显示器用户先恢复到可用状态；DCN32 的回归仍在定位。
和你相关 vblank/scanout 回归通常只命中特定 ASIC 与刷新率组合，revert 是维护者「先回滚再重做」的典型处理。

🔗 原文

📰 Rust

/ column

★ Rust for Linux 发出 7.4 pull request：zerocopy 更新撑大 diff

〔10-19 00:35〕· [GIT PULL] Rust for v7.4（Miguel Ojeda）

定位 7.4 合并窗口正在收尾，Rust for Linux 发出本周期的 pull request。
做法 pull 里 diff 最大的是 vendored zerocopy 库更新，但只是一个 机械导入的提交；所有提交已在 linux-next 待过两轮以上。Miguel 做了试合并， 并提示与 char-misc、DRM、Kbuild 会有轻量冲突及具体解决方式。
效益 Rust 子系统按既定节奏进 7.4；下游树可以提前按公布的解法处理冲突。
和你相关 合并窗口之后，日报的主线会从「发了什么」转向「进了什么」。

🔗 原文

更多动态

○ [PATCH net 00/10] net: pse-pd: assorted lifetime and error-path fixes 〔10-18 16:23〕

○ [PATCH net-next v2 0/6] net: mdio: add timestamped MDIO writes for PHY gettimex64 〔10-18 18:03〕

○ [PATCH net-next v2 0/3] TCP Prague preparation series 〔10-19 05:15〕

○ [PATCH 0/2] PCI: pciehp / thunderbolt: Fix resume with a slow Thunderbolt host link 〔10-19 00:40〕

○ [PATCH] PCI: Avoid bus reset on NVIDIA GB202 and GB203 GPUs 〔10-19 04:17〕

○ [PATCH v8 1/2] block: avoid long sync_blockdev() under disk->open_mutex during parallel close 〔10-18 23:27〕

○ [PATCH 6.6-rt 0/5] net: Backport backlog-NAPI threads to resolve PREEMPT_RT softirq warning 〔10-19 02:15〕

○ [PATCH v2 sched_ext/for-7.4] sched_ext: Queue the kick_sync wait from set_next_task_scx() 〔10-19 00:24〕

更多动态

○ [PATCH 0/4] namei: check for names that lost their mounts in every refwalk（讨论） 〔10-19 00:54〕

○ [BUG] KASAN: slab-out-of-bounds Read in copy_folio_from_iter_atomic 〔10-18 16:12〕

○ [PATCH] splice: avoid stale f_pos writeback on error 〔10-18 13:17〕

○ [PATCH v3 0/2] media: rcar-isp: fix core registration and IRQ lifetime 〔10-18 10:46〕

○ [PATCH] media: siano: fix oops in smsdvb_hotplug() due to race condition 〔10-18 13:44〕

○ [PATCH v2 0/3] sparc64: Randomize mmap base and PIE executables 〔10-18 20:27〕

○ [PATCH v5 0/9] Extend PKWM to support user-created wrapping keys 〔10-19 01:09〕

○ [PATCH] rust: cpufreq: fix undocumented_unsafe_blocks in PolicyCpu::from_cpu() 〔10-19 00:37〕

📌 机制雷达

/ section
128 位身份 kuid_t/kgid_t 从 u32 变成 tagged union，新增 20 个 _r 系统调用与一整套 _R 接口；文件系统用 SB_I_UID_R 声明能力，其余路径 fail closed。 原文
cred ids 12 处「同一用户」检查收进 kernel/cred.c，行为不变， 为将来修改「同一用户」的定义留出单一入口。 原文
dma-buf I/O 文件绑定 dma-buf 后，direct I/O 直接生成 dma-buf bio，接在 io_uring dma-buf block 支持 v11 之上。 原文
zcomp 重构 zram 把读写压缩流拆开，并为无状态/有状态后端分别引入共享解压流与跨 CPU 借用，目标是消掉 Reader/Writer 优先级反转。 原文
7.4 窗口 Rust for v7.4 已发出 pull request，合并窗口进入收尾；接下来日报的主线是 「哪些进了主线」。 原文

📖 本期概念速查

/ section
kuid_t / kgid_t 内核里的用户/组 id 类型，当前是包着 u32 的结构；本 RFC 想把它变成 legacy/UUID/GUID 的 tagged union。
UUID / GUID 128 位标识符。UUID 按 RFC 9562；GUID 是微软的字节序变体，常出现在 Active Directory 的 objectGUID 中。
_r 系统调用 与经典 getuid/setuid/chown 等并列的新家族，用 20 字节结构承载 128 位 id，所有 ABI 布局一致。
SB_I_UID_R 文件系统级标志，表示该文件系统能存 UUID/GUID 属主；没有它的文件系统在 chown 与创建文件时返回 EOVERFLOW。
colorspace property DRM 连接器的属性，用户态用它声明 BT.709/BT.2020 等色彩空间；HDMI helper 统一创建。
VOP2 Rockchip 的显示控制器；从连接器取色彩空间后，YCbCr 输出会使用匹配的转换矩阵。
dma-buf 跨设备共享缓冲区的内核对象，常用于 camera→ISP→GPU 的零拷贝链路。
XDP multi-buff 让 XDP 程序在由多个描述符组成的一帧上运行，而不是只看第一个缓冲。
AF_XDP zero-copy 把网卡收到的帧直接送进用户态 socket 内存区域；当前 stmmac 对 multi-buff 帧仍直接丢弃。
zcomp zram 的压缩后端抽象，管理压缩/解压上下文与 per-CPU stream。

如果对你有用，点个赞，或转给需要的朋友。

数据来源：lore.kernel.org（全内核 13 列表）· 北京时间