尽管Linux 7.1合并窗口已纳入许多引人注目的新特性与变更，但截至目前已有两项拉取请求因被Linus Torvalds拒绝而显得尤为突出，并附有他直击要害的评论。
被拒请求之一，主要是解决启用审计子系统时当代高核心数工作站/服务器处理器出现的性能衰退问题。审计框架在高核心数CPU上可能遭遇性能瓶颈，这正是Linux 7.1的一项拉取请求试图解决的问题。
Christian Brauner在描述他与Red Hat工程师Waiman Long提交的补丁时写道：
"避免审计上下文设置与重置路径中过度的dput/dget操作。当审计子系统启用时，它会频繁调用get_fs_pwd()获取对fs->pwd的引用，随后通过path_put()释放这些引用。当大量进程在同一工作目录频繁执行打开/关闭系统调用时，由于引用计数的持续变更，可能导致单个pwd目录项锁上的自旋锁激烈争用。与关闭审计子系统的情况相比，这会造成明显的性能衰退，在如今日益普及的多核系统上尤为突出。
我们通过新增一组fs_struct辅助函数来减少不必要的path_get()和path_put()调用，并修改审计代码以使用这些新辅助函数，从而避免此类由审计引发的性能衰退。"
尽管该补丁对于当前日益增长的高CPU核心数及下一代更高核心数CPU具有重要意义，但Linus Torvalds对其设计并不满意。他回应道：
"我非常不喜欢这个方案，至少会推迟合并它。
因为在我看来这完全走错了方向，像是个临时补丁。仅观察部分被修改的路径，比如copy_fs_struct函数中先通过
path_get(&fs->root);
增加根目录引用计数，紧接着下一行却是
get_fs_pwd_pool_locked(old, &fs->pwd);
以完全不同的方式复制pwd。
造成这种差异的唯一原因是审计代码对pwd和root进行了区别对待。
而这又源于审计代码本身的历史遗留问题与设计缺陷——它无法正确处理chroot环境。
pwd和root路径本质上是同一事物的两面，任何对它们进行如此差异化处理的代码都是*错误的*。
这个方案本质上是将审计模块的错误暴露给了非审计用户。
我对此极度反感。 …… [经过多轮方案推敲]
是的，以上论述非常粗略，我也没有亲自编写代码，可能听起来像疯子的胡言乱语。
我并未对此进行*深入*思考。只是看到这个补丁系列时感到一阵反胃，然后尝试思考'或许我们能换种方式解决'，上述内容就是可能方案的粗略草案。"
Brauner随后回应称，他同样不欣赏这段代码的设计，认为其确实像临时补丁，并已将其从拉取请求中移除。
另一项引发Linus强烈反感的早期Linux 7.1拉取请求涉及RCU代码。该请求提议新增BOOTPARAM_RCU_STALL_PANIC配置选项，旨在默认触发RCU停滞时的内核恐慌。编译时若启用该选项，可将Kernel.panic_on_rcu_stall系统控件的默认值设为在RCU CPU停滞时触发恐慌/重启。其设计初衷是针对高可用性系统，要求在检测到CPU停滞时能自动恢复，无需用户在启动时配置该系统控件。Torvalds对此回应道：
"否决。
见鬼，别再搞这些糟糕的设计了。
我已经强调过无数次：内核配置阶段可能是新手尝试自行编译内核时最大的痛点之一，我们*绝不应该用愚蠢的问题困扰用户*。
需要此功能的人完全可以通过系统控件或内核命令行参数实现，我们*绝不能因此恶化其他所有人的体验*。
我已移除这个令人反感的配置选项，并要明确告知各位：内核配置文件不是你们的私人游乐场——它们是我们鼓励*普通用户*参与内核开发的最直观接口，这些用户正是我们期望吸引来自行编译内核的群体。
所以各位：下次想要添加配置选项时，请深呼吸，审视那个配置文件，然后思考'或许我该先移除另一个无用选项'。
让我们致力于*改进*内核，而不是让它变得更糟。"
在后续讨论中还指出，通过"sysctl.Kernel.panic_on_rcu_stall=true"的启动参数形式，已能轻松实现相同的默认行为，完全可以在内核启动时以此形式设置系统控件默认值。
