fix(vfs): adapt vfs probes for Linux 6.15+

[wangrong1069]

No description provided.

[sourcery-ai]

Sorry @wangrong1069, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[github-actions]

TAG Bot

TAG: 7.0.43
EXISTED: no
DISTRIBUTION: unstable

[deepin-ci-robot]

deepin pr auto review

你好！我是CodeGeeX。我已仔细审查了你提供的Git Diff。本次修改主要是为了适配 Linux 内核 6.15+ 及 7.0+ 版本的 VFS 探针（kretprobes）变更，重构了宏定义以减少重复代码，并修正了指针返回值的错误检查方式。

总体而言，修改思路清晰，代码复用性得到了提升。但在代码安全、逻辑准确性和代码规范方面，我有以下几点改进建议：

1. 代码安全与逻辑准确性

严重问题：IS_ERR 与 IS_ERR_VALUE 的误用
在 common_vfs_ret_ptr_ 函数中，将 IS_ERR_VALUE(regs_return_value(regs)) 改为了 IS_ERR((const void *)regs_return_value(regs))。这是一个危险的修改，建议改回或重新评估。

• 原因分析：在 Linux 内核中，regs_return_value(regs) 返回的是 unsigned long 类型。对于返回指针的函数（如 vfs_mkdir 在新内核中返回 struct dentry *），内核采用负数指针错误编码机制（即返回值在 MAX_ERRNO 范围内的负数被强制转换为指针）。
• IS_ERR_VALUE：专门用于检查 unsigned long 类型是否在错误范围内，它只检查数值是否在 MAX_ERRNO 范围内，不涉及指针语义，适用于 regs_return_value 的原始返回类型。
• IS_ERR：其内部实现是 IS_ERR_VALUE((unsigned long)(ptr))。将 unsigned long 强制转换为 const void * 再传给 IS_ERR，在大多数架构上虽然结果可能相同，但违背了内核 API 的语义。更严重的是，在某些严格内核配置或特定架构（如使用了指针认证 PAC 的 ARM 架构）上，将整数直接强转为指针并解引用或检查，可能会触发未定义行为或硬件异常。
• 改进建议：恢复使用 IS_ERR_VALUE(regs_return_value(regs))，或者使用更符合当前内核语义的写法：

  unsigned long ret = regs_return_value(regs);
  if (IS_ERR_VALUE(ret))
      goto fail;

2. 代码性能

common_vfs_ret_int_ 中的冗余判断

static int common_vfs_ret_int_(struct vfs_event **event, struct pt_regs *regs, int action)
{
    if (regs_return_value(regs))
        goto fail;
    // ...

• 分析：对于返回 int 的 VFS 函数（如 vfs_create, vfs_unlink 等），只要返回值非 0 就认为是失败（goto fail）。这意味着返回 -ENOMEM、-EEXIST 等负数错误码时，都会跳过事件记录。
• 性能影响：在 kretprobe 的返回处理中，如果仅仅因为返回了错误码就放弃事件，可能会导致高频的无效探测开销。通常文件监控类软件需要关注“尝试创建但失败”的事件。
• 改进建议：如果业务逻辑确实只关心成功的操作，当前写法没问题；但如果需要监控失败的尝试，建议去掉 if (regs_return_value(regs)) goto fail;，将错误码记录到 event 中并上报，由用户态决定如何处理。

3. 语法逻辑与健壮性

宏定义中的标识符命名冲突风险

#define DECL_VFS_KRP_EXT(fn, act, de_i, ret) ...
    return common_vfs_ret_##ret##_((struct vfs_event **)&(ri->data), regs, act);\

• 分析：宏通过 ##ret## 拼接函数名。目前 ret 传入的是 int 或 ptr，拼接后为 common_vfs_ret_int__ 和 common_vfs_ret_ptr__。如果未来有人不小心传入了包含非字母数字的宏变量，或者与现有函数名冲突，会导致难以理解的编译错误。
• 改进建议：当前的 int 和 ptr 是安全的，但建议在宏注释中明确说明 ret 参数的合法取值（如：ret 只能为 int 或 ptr），防止误用。

#if 版本分支的边界逻辑

#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 12, 0)
// ...
#elif LINUX_VERSION_CODE < KERNEL_VERSION(6, 15, 0)
// ...
#elif LINUX_VERSION_CODE < KERNEL_VERSION(6, 19, 0)
// ...
#else
// ...
#endif

• 分析：版本分支逻辑是正确的，但 #else 代表 >= 6.19 的所有未来版本。如果 Linux 8.0 再次修改了 VFS API，这段代码会静默地使用错误的参数偏移量去取 dentry，导致内核 OOPS 或内存越界。
• 改进建议：对于未来的版本，建议增加一个编译时的警告或错误提示，强制开发者确认：

  #elif LINUX_VERSION_CODE < KERNEL_VERSION(6, 19, 0)
  // ...
  #elif LINUX_VERSION_CODE >= KERNEL_VERSION(6, 19, 0) && LINUX_VERSION_CODE < KERNEL_VERSION(7, 0, 0)
  // 当前 6.19+ 的逻辑
  #else
  #error "Unsupported kernel version: VFS API may have changed. Please update the probes."
  #endif

  (注：根据你的 changelog，似乎 7.0 的 API 和 6.19 是一致的，如果确认 7.0+ 也是此 API，可以将条件写为 >= 6.19 并在注释中说明已适配 7.0)

4. 代码规范与质量

版权声明的年份跳跃

-// Copyright (C) 2021 UOS Technology Co., Ltd.
-// SPDX-FileCopyrightText: 2022 - 2023 UnionTech Software Technology Co., Ltd.
+// SPDX-FileCopyrightText: 2022 - 2026 UnionTech Software Technology Co., Ltd.

• 分析：删除了 2021 年的版权声明，并且将结束年份直接改为了 2026 年（当前是 2024 年）。虽然预填未来年份在某些公司规范中是允许的，但删除 2021 年的原始版权可能存在法律风险。
• 改进建议：保留原始版权年份，采用叠加方式：SPDX-FileCopyrightText: 2021 - 2026 UnionTech Software Technology Co., Ltd.，具体需遵循你们公司的法务规范。

宏定义的代码可读性
DECL_VFS_KRP_EXT 和 DECL_VFS_KRP 宏定义过长，且使用反斜杠换行，在 Diff 中阅读体验较差。

• 改进建议：可以考虑在宏内部使用 do { } while(0) 包裹，或者将其拆分为更小的宏（如分离 entry_handler 和 ret_handler 的定义），不过对于内核模块开发，当前的宏风格也是常见的，此条作为可选优化。

总结

最核心的修改点是 IS_ERR 的使用问题，强烈建议将其改回 IS_ERR_VALUE 以避免潜在的内核定址异常和语义错误。其余关于版本边界和错误码处理的建议，可以结合你们的实际业务需求进行酌情优化。

[wangrong1069]

CI 的 liblucene++ 版本未更新，忽略编译失败

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: lzwind, wangrong1069

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[wangrong1069]

/forcemerge

[deepin-bot]

This pr force merged! (status: unstable)

[deepin-bot]

TAG Bot

✅ Tag created successfully

📋 Tag Details

• Tag Name: 7.0.43
• Tag SHA: 802e8ed018ed94310b348e0597b197b239f1a025
• Commit SHA: 62c63032f7e9302264d6435d308cda8e04102b17
• Tag Message:

  Release deepin-anything 7.0.43
  
  

• Tagger:
  • Name: wangrong1069
• Distribution: unstable