Linux 内核问题报告完整指南从复现验证、二分定位到向维护者提交有效 Bug 报告【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux导读向 Linux 内核开发者提交一份能被重视、采纳并最终修复的问题报告远比向普通开源项目报 Bug 复杂——内核采用邮件驱动的开发流程、没有统一的中枢 Bug 追踪器且绝大多数报告需要通过邮件发送给特定的维护者与公开邮件列表。本文以 Linux 内核官方文档 Documentation/admin-guide/reporting-issues.rst 为主体系统讲解TL;DR 速查流程、逐步报告指南、参考章节与附录四大部分并结合仓库中的 scripts/get_maintainer.pl、scripts/decode_stacktrace.sh、tools/debugging/kernel-chktaint 等真实工具与 MAINTAINERS 文件给出可落地的操作细节。读完本文你将掌握如何判断一个现象是否值得上报、如何定位正确的收件人、如何用 vanilla 内核复现、如何解码 Oops/Panic、如何进行回归二分bisection以及报告发出后应承担哪些后续职责。一、TL;DR向内核维护者报告问题的速查流程如果时间紧迫可以先走一遍官方给出的精简流程它按场景分为三条路径场景一stable/longterm 系列内的回归例如从 5.10.4 升级到 5.10.5 后出问题且该版本线仍在维护在 LKML 邮件列表存档与 Linux stable 邮件列表存档中搜索是否有匹配的报告有则加入讨论不要重复发新报告安装该版本线的最新正式版本vanilla 内核若问题依旧向 stable 邮件列表stablevger.kernel.org发送报告并抄送回归列表regressionslists.linux.dev理想情况下再抄送相关子系统的维护者及其邮件列表。场景二其他所有情况尽最大努力猜测问题可能出在内核的哪个部分查阅 MAINTAINERS 文件了解该部分开发者期望以何种方式接收反馈绝大多数情况是通过邮件并抄送公开邮件列表检查目标地点的存档同时搜索 LKML 与互联网是否有匹配报告没有则安装最新的 mainline 内核若问题在 mainline 上存在发送报告。场景三mainline 已修复但你希望 stable/longterm 系列也能解决安装对应版本线的最新正式版本若问题仍存在在 mainline 中搜索修复该问题的提交检查是否已在安排向后移植backport或是否已决定放弃移植若两者皆无向处理该提交的开发者询问移植的可能性。通用注意事项按上述流程安装和测试内核时务必使用vanilla 内核即未打补丁、未使用附加模块的内核并确保内核构建和运行在健康的环境中、问题发生前内核未被污染tainted。如果同时面临多个内核问题必须分开单独报告。报告中应包含所有与问题相关的信息如所用内核版本与发行版。若是回归请抄送回归列表regressionslists.linux.dev并尽量通过二分定位出引入问题的提交成功后附上其 commit-id并抄送该提交签名链sign-off-by chain上的所有人。报告发出后要积极响应后续提问并定期用新版本重测、随后发送状态更新。二、逐步报告指南完整流程TL;DR 面向熟悉自由/开源软件FLOSS项目问题报告的老手。对于其余所有人官方提供了更详细、采用逐步推进方式的指南。它比 TL;DR 多覆盖了几个方面且顺序略有不同目的是让你尽早发现看起来像内核问题的故障其实是由其他因素引起的避免投入的时间最终白费。2.1 准备阶段第一步确认你使用的是不是上游 Linux 内核如果你面对的问题来自硬件或软件厂商提供的内核预装系统、发行版内核绝大多数情况下应该停止阅读本文档转而向你的厂商报告除非你愿意自己安装最新版 Linux 内核。原因在于几乎所有设备预装的内核和多数发行版内核都离 kernel.org 官方内核相当遥远——要么年代久远要么被大幅修改常常两者兼有。这些问题可能在几个月甚至几年前就已被上游修复也可能正是厂商的改动所致。当然也有例外如果发行版只对基于较新版本的内核做了小改动例如 Debian Sid、Fedora Rawhide 提供的 mainline 内核部分开发者愿意受理Arch Linux、常规 Fedora 发行版、openSUSE Tumbleweed 这类只做轻微修改的稳定内核有时也能被接受。但官方仍建议以 mainline 内核为准。第二步第一轮搜索既有报告在开始投入前先用搜索引擎做粗略检索再搜索 LKML 邮件列表存档。如果找到匹配报告直接加入讨论而不是新开报告。搜索时注意技巧不要一次使用过多关键词分别尝试带与不带驱动名、受影响硬件组件名的搜索精确品牌名如 ASUS Red Devil Radeon RX 5700 XT Gaming OC往往过于具体不如使用型号系列Radeon 5700/5000与主芯片代号Navi/Navi10可加或不加厂商名 AMD结果过多时可将时间范围限制在过去一个月或一年。另外也值得搜索 bugzilla.kernel.org但要注意多数子系统并不在 bugzilla 受理报告详见后文开发者可能根本不知道这个 ticket 的存在。第三步判断是否属于高优先级问题Linus Torvalds 与内核核心开发者希望以下三类问题尽快修复它们在报告流程中需要特殊处理回归regression某个应用或实际用法在旧内核上运行正常在使用相似配置编译的更新内核上却变差或完全失效。详见 Documentation/admin-guide/reporting-regressions.rst该文档还介绍了如何把问题加入被跟踪的回归列表以防遗漏安全问题是否构成安全问题由你自行判断建议先阅读 Documentation/process/security-bugs.rst严重问题内核损坏了正在处理的数据、损坏了运行其上的硬件、突然以错误消息停机kernel panic或毫无征兆地停机。注意区分panic内核自行停机的致命错误与Oops可恢复错误内核仍继续运行。第四步确保运行环境健康看似内核问题的问题有时源于构建或运行环境应尽量排除构建内核时使用经过验证的工具链编译器或 binutils 的 Bug 可能导致内核行为异常确保 CPU、内存、主板运行在设计规格内遇到疑似内核问题时停止降压或超频排除故障硬件——坏内存会表现为大量看似内核问题的问题处理文件系统问题时先用fsck检查文件系统是否损坏处理回归时确认是否还有其他软件与内核同时更新、硬件是否恰好损坏、BIOS 是否被改动——这些都可能制造出看似内核回归的假象。第五步做好应急准备创建一份全新备份并备好系统修复/重装以及恢复备份所需的全部工具。第六步确保内核不被增强如果系统通过 DKMS、akmods 等机制在内核安装或首次启动时自动构建附加内核模块报告被忽略或拒绝的风险会大增。应禁用这些机制、移除它们已安装的模块然后重启。注意这类机制常在安装 Nvidia 闭源驱动、VirtualBox 等需要内核模块支持的软件时被静默启用你可能需要卸载相应软件包来彻底清除第三方内核模块。第七步检查 taint污染标志内核在发生可能导致看似无关的后续错误的事件时会给自己打上 taint 标志你面临的问题可能就是这样的后续错误。在运行中的系统上很容易检查cat /proc/sys/kernel/tainted返回0表示未污染。某些场景下无法读取该文件因此内核在报告内部问题kernel bug、可恢复错误kernel Oops或停机前kernel panic时也会顺带打印 taint 状态在错误信息顶部附近寻找以CPU:开头的行行尾若为Not tainted则未污染若看到Tainted:后跟若干字母则表示已污染。如果内核已污染查阅 Documentation/admin-guide/tainted-kernels.rst 找出原因并尽量消除。常见原因有三发生了内核 Oops可恢复错误导致内核自我污染。检查日志中如下片段Oops: 0000 [#1] SMP#1表示启动后的第一个 Oops此后的任何问题都可能是它的后续问题。先消除首个 Oops 的原因再复现有时重启即可有时需要改配置后重启系统加载了第三方内核模块如 Nvidia 闭源驱动、VirtualBox内核加载外部来源模块时会自我污染。临时卸载这些软件及其模块后重启内核加载了 staging 树中的模块代码质量尚未达到正式标准的区域。若问题正出在该模块上tainted 是可以接受的但要确保该模块是唯一污染源若问题在无关区域重启后用内核参数foo.blacklist1将 foo 换成模块名临时阻止该模块加载。第八步记录复现方法粗略写下如何复现问题。若同时有多个问题为每个问题单独记录并确保它们各自能在全新启动的系统上独立复现——因为每个问题都要单独向开发者报告除非它们紧密耦合。另外只发生过一次的问题往往不值得报告可能是宇宙射线引起的比特翻转尽量先复现确认。第九步判断是否为 stable/longterm 版本线内的回归如果你面对的是 stable 或 longterm 版本线内部的回归例如从 5.10.4 升级到 5.10.5 后出问题从 5.9.15 切换到 5.10.5 不算开发者极其迫切地希望尽快知晓——这类回归影响面可能很大因此有专门的精简流程见本文 2.2 节。第十步确定问题归属与正确的报告地点定位疑似引发问题的驱动或子系统查明其开发者期望的接收方式。注意绝大多数情况不是 bugzilla.kernel.org而是通过邮件发送给维护者并抄送公开邮件列表。阅读 MAINTAINERS 文件的详细方法见下文参考章节熟练用户也可使用 scripts/get_maintainer.pl 脚本自动查找收件人。第十一步在目标 bug 追踪器或邮件列表存档中彻底搜索现在你知道该去哪里报告了再认真搜索一遍既有报告详细方法见参考章节。官方提醒这一步值得花 3060 分钟甚至更多时间能为你和他人省下大量麻烦。2.2 主流程第十二步安装全新内核用于测试除非你已在运行最新的 mainline 内核否则为报告流程安装一个。有些情况下用最新 stable 内核测试与报告也可接受合并窗口期间甚至可能是最佳选择但该阶段暂停几天往往更好。无论选择哪个版本理想情况下使用 vanilla 构建。无视这些建议会大幅增加报告被拒收或无视的风险。第十三步再次检查 taint 标志确保刚安装的内核在运行时不会自我污染。如果会绝大多数情况下必须在报告前消除污染原因。第十四步用新内核复现问题若问题在新内核上已不存在可考虑改用该版本线并放弃报告但其他用户可能仍受其困扰只要 kernel.org 的 stable/longterm 版本及其衍生厂商内核尚未修复。若你希望这些问题版本线解决参见仅出现在较老内核版本线中的问题一节。第十五步优化复现描述寻找最直接的复现路径保证细节完整的同时尽量简短易读。这个过程中你多半对问题有了新认识建议再次搜索是否有可加入的既有报告。第十六步解码失败信息当故障涉及 panic、Oops、warning 或 BUG 时考虑解码内核日志以定位触发错误的源码行。前提是配置内核时启用了CONFIG_DEBUG_INFO与CONFIG_KALLSYMS。解码使用源码树中的 scripts/decode_stacktrace.sh# 自己编译的内核 sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh ./linux-5.10.5/vmlinux # 发行版打包的 vanilla 内核需安装对应调试符号包 sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh \ /usr/lib/debug/lib/modules/5.10.10-4.1.x86_64/vmlinux /usr/src/kernels/5.10.10-4.1.x86_64/脚本处理如下格式的日志行显示出错时内核正在执行代码的地址[ 68.387301] RIP: 0010:test_module_init0x5/0xffa [test_module]解码后变为[ 68.387301] RIP: 0010:test_module_init (/home/username/linux-5.10.5/test-module/test-module.c:16) test_module即执行代码由test-module.c第 16 行构建而来。脚本同样会解码Call trace段中的地址并展示出错代码段的汇编输出。若无法完成解码直接在报告中说明原因即可开发者会视需要指导你。注意这只是解码内核栈回溯的多种方式之一。第十七步回归问题的特殊处理回归是王牌——Linus 坚持内核永不退步引入回归的改动往往会被迅速回退前提是必须找到肇事提交而通常这要由报告者自己完成。定位过程叫bisection二分详见 Documentation/admin-guide/bug-bisect.rst。流程通常需要构建约 1020 个内核映像、逐一复现借助二分查找最终定位到引入回归的那一个提交。找到后用其标题、完整 commit-id 与前 12 位短 commit-id 搜索网络看看是否已有相关报告。如果你实在无法或不愿做完整二分至少确定回归由哪个 mainline 大版本引入例如从 5.5.15 切到 5.8.4 出问题就依次测试 5.6、5.7、5.8找出首次出现的版本。除非是在 stable/longterm 内核中找回归否则避免测试三段式版本号5.6.12、5.7.8否则结果难以解读。另注意只有新旧内核用相似配置构建可用make olddefconfig实现详见 Documentation/admin-guide/reporting-regressions.rst才构成回归。第十八步撰写并发送报告报告最关键的部分是标题/主题、第一句话和第一段——开发者邮件很多往往只花几秒扫一眼就决定是否深入。因此先写详细正文再回头打磨开头。每份报告都应包含新装的 vanilla 内核上问题如何发生附上你优化过的逐步复现说明cat /proc/version的输出内核版本号与编译器发行版信息hostnamectl | grep Operating SystemCPU 与操作系统架构uname -mi若是回归且做了二分给出肇事提交的主题与 commit-id。多数情况下还应提供构建内核用的 .config 配置文件dmesg输出确认以Linux version 5.8-1 (foobarexample.com) (gcc (GCC) 10.2.1...)开头否则早启动阶段的重要消息已被丢弃此时改用journalctl -b 0 -k或重启复现后立即执行dmesg。这两个文件很大不要直接粘贴进邮件。上传到可长期公开访问的位置个人网站、公开粘贴服务、专门为此建的 bugzilla ticket并在报告中附链接或者先搁置之后在回复自己邮件的单独回信中补发。视情况可补充的信息warning/Oops/panic 的原文无法复制粘贴时用 netconsole 抓取或拍照硬件信息显卡厂商/型号/芯片、笔记本精确型号Dell XPS 13 太含糊要加 9380、7390 这类确切型号相关软件版本模块加载问题报 kmod/systemd/udev 版本DRM 问题报 libdrm/Mesa 版本与 Wayland 合成器或 X-Server 及驱动文件系统问题报 e2fsprogs、btrfs-progs、xfsprogs 等版本内核侧信息lspci -nn、必要时sudo lspci -vvv以及/proc/cpuinfo、/proc/ioports、/proc/iomem、/proc/modules、/proc/scsi/scsi等内容。报告头部结构先写详细描述段落在其上方加一段正常长度的概述段落描述问题与影响若影响大量用户务必提及再上方加一句话摘要最后给一个更短的描述性标题。全部完成后按 MAINTAINERS 文件的指示发送或提交。高优先级问题的特殊处理严重问题标题与首段要凸显严重性回归主题以[REGRESSION]开头二分成功则用肇事提交的标题作为主题第二部分并附 commit-id二分失败则写明最新正常版本如 5.7与最早出问题的版本如 5.8-rc1。发送时抄送回归列表regressionslists.linux.dev若提交到网页追踪器则提交后把报告内联转发勿用附件到回归列表顶部注明 ticket URL。二分成功时把肇事提交的作者与 sign-off-by 链上所有人加入收件人安全问题先评估公开披露细节是否会在短期内危及其他用户。若无风险按常规流程报告。若有风险MAINTAINERS 指示邮件报告的不要抄送任何公开邮件列表指示提交 bug 追踪器的将 ticket 标记为 private/security若追踪器不支持保密改为向维护者发送私密邮件。两种情况都要把报告发给 MAINTAINERS 中 security contact 一节列出的地址。第十九步报告发出后的职责理想情况极少出现是开发者立刻定位问题并修复。多数情况下你的工作才刚刚开始。通用建议始终公开回复bug 追踪器中的问题就在追踪器里回复邮件报告一律使用全部回复包括补充数据时去发件箱对自己原报告点全部回复保持邮件线程完整让所有参与者始终在循环中。仅两种例外有人要求你私下发送内容含敏感信息需保密此时可在 ticket/邮件中注明你已私下发送先自行研究再提问被要求使用陌生工具或打补丁测试时先搜索互联网或向朋友/社区求助保持耐心内核开发者分散在全球各地一般需要 15 个工作日响应有时更长合并窗口、出差、假期。高优先级问题例外最多等一周紧急时两天就应发友好提醒主动测试每个新 mainline 版本发布首个预发布版rc1时都去验证问题是否已修复并在 ticket 或回复邮件中汇报结果抄送此前参与讨论的所有人。偶尔用 rc3、rc5、正式版复测也很好但只在有实质变化或本来就要发消息时汇报。收到质询与测试请求时核对对象快速搜索确认回复者身份避免被带偏同时确认报告是否到达了正确的人数据质询尽快提供被要求的附加信息拖延几个工作日很可能丢失对方的关注测试请求及时但认真测试诊断补丁或候选修复别搞混——常见错误是以为补丁已应用其实没有。当事情毫无进展时先等两最好三周再发友好提醒在回复原邮件的邮件开头询问还需要什么完整引用原报告TOFU 方式在此场景是正确做法提醒后等三周。仍无实质反应先自我反思是否找错了人报告是否冒犯或令人困惑请一两位熟悉 FLOSS 报告的朋友评审若确有问题可重写后作为第二份改进版报告发送并附上首份报告的链接报告本身无误可发第二封提醒邮件好时机是某新内核版本 rc1 发布后因为你反正要重测并汇报一周无反应再联系更高级别的维护者做好失望的准备维护者只对高优先级问题负有义务可能回复谢谢报告但我眼下有更重要的事不要绝望Linux 是自由软件你仍然可以自救——联合其他受影响者组成团队共同撰写新报告说明受影响人数一起缩小根因或定位肇事提交团队中若有会编程的人甚至能直接写修复。2.3 stable/longterm 版本线内回归的精简流程适用于从 5.10.4 升级到 5.10.5 出问题这类场景确认版本线仍在维护查看 kernel.org 首页确认该版本线的最新版本没有被标注[EOL]。多数版本线只维护约三个月每年选一条维护至少两年常为六年的 longterm 线若首页列出两条 stable 线较旧那条大概率即将 EOL应优先考虑迁移搜索 stable 邮件列表存档lore.kernel.org/stable有无匹配报告有则加入讨论修复已完成并即将应用的情况除外用最新版本复现安装该版本线最新的 vanilla 内核确认未被污染且问题仍存在。若最初是在厂商内核上发现问题的还需用最后一个已知正常的 vanilla 版本验证例如从 5.10.4-vendor.42 升到 5.10.5-vendor.43 出问题则测试 vanilla 5.10.4 是否也坏——若 5.10.4 就坏则不构成上游回归回到主指南流程发送简要报告向 stable 列表stablevger.kernel.org发送简短报告并抄送回归列表regressionslists.linux.dev怀疑特定子系统时抄送其维护者与列表。写明首个出问题的版本与最后正常工作的版本。若时间允许用 vanilla 内核手动粗略二分出引入问题的确切版本如 5.10.5 → 5.10.7 → 5.10.8/5.10.6在报告中说明5.10.9 仍坏。报告发出后可能被要求做正式二分以精确定位肇事提交。2.4 仅出现在较老内核版本线中的问题适用于mainline 无法复现但希望仍在维护的 stable/longterm 系列或基于它们定期重基的厂商内核修复心理准备修复可能太大或风险太高而无法向后移植你可能得忍受问题或切换到更新版本除非自己打补丁执行公共准备步骤确认版本线仍受支持、搜索 stable 邮件列表、用最新版本验证即上文 2.3 的前三步搜索代码历史与既有讨论在内核 Git 仓库中查找 mainline 中修复该问题的提交本地克隆可用git log --greppattern搜索。若提交消息末尾带有如下stable 标签Cc: stablevger.kernel.org # 5.4说明开发者已确认该修复可安全移植到 5.4 及以后版本线通常两周内会被应用。若找不到修复或标签缺失再搜索相关邮件列表讨论注意修复可能被认为风险太高而不适合移植若完全没人考虑过移植加入最新讨论询问是否在计划中寻求建议以上都不奏效时向疑似根因子系统的维护者发送邮件征询建议抄送该子系统邮件列表与 stable 列表stablevger.kernel.org。三、参考章节各步骤的深入说明参考章节面向步骤指南之外还有疑问的用户对每一步给出更完整的背景与原理。3.1 通用忠告内核开发者清楚向内核报 Bug 比其他 FLOSS 项目更复杂部分源于内核的邮件驱动开发流程和内核主要由驱动组成的特点部分源于改进此事需要多领域投入而一直无人牵头与厂商的保修/支持合同不赋予你向上游内核开发者索取修复的权利此类诉求应走厂商支持渠道初次向 FLOSS 项目报问题者可先浏览How to ask good questions、How To Ask Questions The Smart Way、How to Report Bugs Effectively等经典指南。3.2 确认使用上游内核详解内核开发者不愿处理在当下代码上根本不会发生的问题报告——那是所有人时间的浪费尤其浪费你的。设备预装内核与发行版内核往往年代久远或被深度修改两者常常兼具极不适合上游报告。多数情况下应转向厂商如果厂商无法处理或你不愿等可自行安装最新内核后续步骤会指导如何操作并排除其他可能原因。当然你也可以无视建议直接上报老内核/深度修改内核的问题——报告常被拒绝或无视但总比不报强有时会间接推动问题最终被修复。3.3 第一轮搜索既有报告详解报告别人已经提过的问题是所有人时间的浪费尤其浪费你的。先用搜索引擎再搜 LKML 存档。注意搜索技巧关键词组合、时间范围限制、用他人视角换词、避免过多关键词、区分品牌名与型号线/芯片代号。找到既有报告就加入讨论——即使修复已在最后阶段开发者也可能正在寻找能提供补充信息或测试补丁的人。也可以搜索 bugzilla.kernel.org但要意识到多数子系统的开发者并不看那里。3.4 高优先级问题详解三种类型回归、安全问题、严重问题。回归的判断标准是旧内核正常、用相似配置编译的新内核变差或失效更详细的说明见 Documentation/admin-guide/reporting-regressions.rst安全问题详见 Documentation/process/security-bugs.rst严重问题指完全不可接受的事件——损坏数据、损坏硬件、内核 panic 或无征兆停机。注意 panic致命内核停止与 Oops可恢复内核继续运行的区别。3.5 健康环境详解构建环境用可靠工具链硬件运行在设计规格内停降压/超频排除坏内存等故障硬件文件系统问题先fsck回归场景排除内核之外同时变化的因素并行更新的软件、恰好损坏的硬件、BIOS 变更。3.6 应急准备详解你即将摆弄操作系统最关键的部件请先备份、备好修复/重装/恢复工具。3.7 禁用内核增强机制详解DKMS、akmods 之类会在安装或首次启动新内核时自动构建附加模块。这些机制常伴随 Nvidia 闭源驱动、VirtualBox 等软件静默安装你可能毫不知情。卸载相关软件包与已装模块然后重启。任何对内核的增强都会显著提高报告被拒收或无视的风险。3.8 taint 标志详解内核在发生可能导致看似无关后续错误的事件时自我标记。taint 状态可在 Oops/BUG/Panic 消息顶部以CPU:开头的行中看到Not tainted或Tainted:后跟字母。也可用 tools/debugging/kernel-chktaint 脚本解码/proc/sys/kernel/tainted的数值# 若发行版未打包该脚本可从内核源码获取后直接运行 sh kernel-chktaint解码脚本输出示例Kernel is Tainted for following reasons: * Proprietary module was loaded (#0) * Kernel issued warning (#9) * Externally-built (out-of-tree) module was loaded (#12) Raw taint value as int/string: 4609/P W O 也可用一段 shell 快速检查各比特位$ for i in $(seq 20); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)($i-1)1));donetaint 数值是一个位域。结合仓库源码内核在 include/linux/panic.h 中定义了这些位如TAINT_PROPRIETARY_MODULE为位 0、TAINT_WARN为位 9、TAINT_OOT_MODULE为位 12完整位表见 Documentation/admin-guide/tainted-kernels.rst位 0 专有模块G/P、位 1 强制加载F、位 2 超规格系统S、位 3 强制卸载R、位 4 机器检查异常M、位 5 坏页引用B、位 6 用户空间请求U、位 7 内核近期死亡/OopsD、位 8 用户覆盖 ACPI 表A、位 9 内核告警W、位 10 staging 驱动C、位 11 固件缺陷规避I、位 12 外部构建模块O、位 13 未签名模块E、位 14 软锁L、位 15 内核被 live patchK、位 16 发行版自定义辅助污染X、位 17 结构随机化插件构建T、位 18 内核内测试运行N、位 19 用户空间对 fwctl 的变更调试操作J。消除污染源后注意taint 状态不会因消除原因而自动清除例如卸载专有模块后仍保持污染因为内核认为自身已不可信。3.9 记录复现方法详解多个问题必须分开报告可能由不同开发者处理混在一起难以拆解除非强烈耦合。可快速复现是后续多版本测试的前提。只发生一次的问题可能是宇宙射线导致的比特翻转尽量先复现有经验的用户能区分一次性的硬件错误与罕见但可复现的内核问题时可不理会此建议。3.10 stable/longterm 内回归详解这类回归比 mainline 回归更不受欢迎影响面可能很大开发者希望尽快知晓因此有精简流程。注意从 5.9.15 切到 5.10.5 这类跨版本线切换不算。3.11 确定报告地点详解内核很大多数开发者只熟悉极小一部分有人只关心某个 WiFi 驱动。内核缺乏中枢 bug 追踪器你必须自己找到正确的地点和方式。如何阅读 MAINTAINERS 文件以笔记本 WiFi 更新内核后异常为例。先用lspci -k查看 PCI/PCIe 设备及驱动它的内核模块[usersomething ~]$ lspci -k [...] 3a:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32) Subsystem: Bigfoot Networks, Inc. Device 1535 Kernel driver in use: ath10k_pci Kernel modules: ath10k_pci [...]USB 或其他内部总线上的设备此法无效可查看 WiFi 管理器或ip link输出找到接口名如wlp58s0再定位驱动模块[usersomething ~]$ realpath --relative-to/sys/module/ /sys/class/net/wlp58s0/device/driver/module ath10k_pci拿到驱动/子系统名后在 MAINTAINERS 中搜索。注意驱动名如 ath10k_pci往往太具体搜不到可尝试缩短或变形会看到类似条目QUALCOMM ATHEROS ATH10K WIRELESS DRIVER Mail: A. Some Human shumanexample.com Mailing list: ath10klists.infradead.org Status: Supported Files: drivers/net/wireless/ath/ath10k/在源码树根目录的 MAINTAINERS 文件中这些字段以缩写形式出现M:维护者邮件、L:邮件列表、S:状态等文件顶部附近的小节会解释全部缩写——这一点已在本仓库 MAINTAINERS 文件中得到验证例如M:/L:/S:组合状态值包括Maintained、Supported、Odd Fixes等。先看S:状态理想为Supported或MaintainedObsolete表示正在被新方案替代Odd Fixes表示有人偶尔修复Orphan表示无人维护只能忍受、自己修或找志愿者。再看有无B:bug 追踪器行——多数小节没有因为内核开发完全由邮件驱动只有极少数子系统用追踪器其中又只有部分依赖 bugzilla.kernel.org。多数情况下你要找M:与L:行报告要发往这些地址。发送邮件报告时务必把 LKMLlinux-kernelvger.kernel.org加入抄送——两个列表都不能省略LKML 是让所有报告汇集一处的关键。用脚本找维护者手头有内核源码的人可用 scripts/get_maintainer.pl作者 Joe Perches基于 checkpatch.pl 演化而来见脚本头部注释。对编译为模块的驱动可用 modinfo 定位源码路径$ modinfo ath10k_pci | grep filename | sed s!/lib/modules/.*/kernel/!!; s!filename:!!; s!\.ko\(\|\.xz\)!! drivers/net/wireless/ath/ath10k/ath10k_pci.ko然后传给脚本$ ./scripts/get_maintainer.pl -f drivers/net/wireless/ath/ath10k* Some Human shumanexample.com (supporter:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER) Another S. Human asomehumanexample.com (maintainer:NETWORKING DRIVERS) ath10klists.infradead.org (open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER) linux-wirelessvger.kernel.org (open list:NETWORKING DRIVERS (WIRELESS)) netdevvger.kernel.org (open list:NETWORKING DRIVERS) linux-kernelvger.kernel.org (open list)不要发给所有人只发给被标记为supporter:的维护者抄送最具体的代码邮件列表以及 LKML。上例即发给Some Human shumanexample.com抄送ath10klists.infradead.org与linux-kernelvger.kernel.org。若用 git 克隆的源码可加--git参数让脚本从提交历史中找出近期处理过该代码的人但结果要谨慎使用——很少改动的区域老旧驱动常被树级清理的开发者顺手修改那些人并不关心该驱动。3.12 第二轮搜索既有报告详解现在你知道报告该去哪里了。邮件列表的存档多在 lore.kernel.org但部分列表托管在别处例如例中的 ath10k 列表用搜索引擎加site:限制如site:lists.infradead.org/pipermail/ath10k/即可限定范围。此步值得花 3060 分钟能节省大量后续麻烦。3.13 安装全新内核测试详解最新上游通常指安装 mainline 内核最新 stable 可选但多数情况应避免longterm/LTS 内核在此阶段不合适。如何选择版本忽略 kernel.org 首页的黄色Latest release大按钮看下方表格。顶部 mainline 行通常指向预发布版如5.8-rc2这正是要用的版本——所有修复必须先进入 mainline。rc 开发内核相当可靠而且你按指示做了备份对吧。约每九到十周中有两周mainline 会指向正式发布版如 5.7此时考虑暂停报告流程直到下一个 rc15.8-rc1出现——因为开发周期正处于两周的合并窗口大量改动含所有侵入性改动在此期间合入使用 mainline 风险略高开发者也很忙而且窗口中某个改动可能恰好修复了你的问题。等不及的高优先级问题可改用 git 获取最新 mainline 或用最新 stable。合并窗口之外尽量避免用最新 stable修复必须先进 mainline 才能被向后移植且某些修复因风险太大不会被移植。longterm/LTS 内核距当前代码太远不适合本阶段。如何获取新内核预编译内核最快最安全但多数发行版/附加仓库的内核由修改过的源码构建非 vanilla。热门发行版可找到提供最新 mainline/stable vanilla 内核包的仓库——确认描述中写明 vanilla或接近且包不早于一周新 mainline/stable 至少每周发布一次。注意预编译内核可能缺少解码 panic/Oops 所需的调试符号若计划解码自己编译更合适git熟悉 git 的开发者/老手直接从 kernel.org 官方开发仓库获取最新源码通常比最新 mainline 预发布版稍新可靠性相当合并窗口中段除外常规方式不熟悉 git 的人从 kernel.org 下载源码 tarball。如何构建本文档不赘述新手上路可跟随建议使用make localmodconfig——它读取当前内核配置并针对你的系统调整不提升内核质量但能加快编译。处理 panic/Oops/warning/BUG 时务必启用CONFIG_KALLSYMS并同时启用CONFIG_DEBUG_KERNEL与CONFIG_DEBUG_INFO后者是关键但以前者为前提它会显著增加存储占用但能让你日后精确定位触发问题的代码行。始终保留问题记录——发一份未解码的报告也比不报强。3.14 再次检查 taint详解见 3.8 节。报告前几乎必须消除刚安装内核的污染原因。3.15 用新内核复现详解见 2.2 主流程第十四步。3.16 优化复现描述详解见 2.2 主流程第十五步核心是细节完整 尽量简短 基于新认知再次搜索。3.17 解码失败信息详解见 2.2 主流程第十六步。脚本源码位于 scripts/decode_stacktrace.sh作者 Sasha LevinGPL-2.0支持-R解码返回地址、自动探测 llvm-cxxfilt/cfilt 等 demangler。解码不了就跳过并在报告中说明开发者会帮你这只是解码栈回溯的途径之一。3.18 回归的特殊处理详解见 2.2 主流程第十七步。补充要点寻找肇事提交后用其主题、完整 commit-id 与前 12 位短 commit-id 搜索网络以发现既有报告二分需要一定知识储备与大量投入但强烈推荐自己做——维护者往往没时间或没有复现环境定位肇事者通常是报告者的责任。3.19 撰写并发送报告详解见 2.2 主流程第十八步。补充三个文档前言中链接的提问指南已覆盖大部分写法本文只强调内核特有要素报告中最关键的是头部务必最后打磨。3.20 报告发出后的职责详解见 2.2 主流程第十九步。补充要点开发者通常 15 个工作日响应合并窗口、出差、会议、假期都会延迟高优先级问题最多等一周紧急两天即可发友好提醒。若对是否算回归等存在分歧在邮件列表公开提出并征求公开或私下回复必要时升级到更高层维护者WiFi 驱动场景即无线维护者全都不行且事态严重时才考虑惊动 Linus Torvalds。主动测试节奏每个新版本 rc1 必测并汇报rc3/rc5/正式版按需测。若长期无实质进展按两周→三周→再评估的节奏发提醒最终可联系更高级维护者也要接受没有义务修复的现实。最后自由软件的精神意味着你永远可以自救——联合受影响的其他人共同定位根因甚至写出修复。四、附录为什么向内核报 Bug 相对困难内核开发者清楚向内核报 Bug 比其他自由/开源项目更难原因深植于内核本质、Linux 开发模式与世界的使用方式发行版内核大多完全不适合上游报 Bug过时的代码库、修改与附加组件导致的问题要么上游早已修复要么上游从未发生过。内核改动的影响远比其他软件严重因此许多内核开发者期待基于新鲜、几乎未修改源码构建的内核的报告Bug 常只在特殊环境中出现Linux 主要由驱动组成、使用方式万千开发者往往没有匹配环境必须依赖报告者协助隔离原因与测试修复内核有数百位维护者但全才极为罕见功能与驱动太多多数开发者对自己代码的上层/下层知之甚少对其他领域更不了解缺乏中枢 bug 追踪器导致难以找到报告地点连部分内核开发者都不喜欢这一点但现状如此stable/longterm 内核主要由专职 stable 团队维护他们只处理 stable/longterm 系列内的回归例如报告 6.1.2 的问题时团队总会先问 mainline 是否受影响——若 6.1 就存在或最新 mainline如 6.2-rc3也出现他们会转给最懂代码的常规开发者开发者有权只关注最新 mainline6.0 的 Bug 在 6.1 已发布时可能遭冷遇6.1.5/6.1.6 的报告也可能被推给 stable 团队那可能是系列内回归有时根本没有可求助的人硬件文档缺失逆向工程驱动、原厂商放弃后被业余开发者接手的驱动或维护者离去后无人接手代码只要有用就留在内核中。上述诸多方面本可改善许多内核开发者心知肚明也乐见有人或机构将改善内核问题报告体验作为使命。五、总结一份高质量内核问题报告的关键清单用 vanilla 内核未打补丁、无附加模块、未污染取自 kernel.org 或官方 git 仓库在正确的版本上测试优先最新 mainline合并窗口期间可考虑暂停或用最新 stable找对收件人通过 MAINTAINERS 文件或 scripts/get_maintainer.pl可加--git定位维护者与最具体的列表务必抄送 LKML回归另抄送 regressionslists.linux.devstable 内回归发 stablevger.kernel.org先搜索再报告LKML、lore.kernel.org 存档、子系统列表存档、互联网、bugzilla.kernel.org 各搜一轮找到就加入讨论排除环境因素健康工具链、无超频/降压、排除坏硬件、排除并行软件更新、fsck检查文件系统完整信息cat /proc/version、发行版、uname -mi、复现步骤、.config 与dmesg链接、必要时附lspci输出与 Oops/Panic 原文最好先用 scripts/decode_stacktrace.sh 解码回归必做二分方法见 Documentation/admin-guide/bug-bisect.rst成功后附肇事 commit-id 并抄送 sign-off-by 链报告后持续跟进公开回复、及时响应、按 rc1 节奏主动重测、必要时友好提醒。遵循以上流程你提交的报告被内核开发者认真对待并最终推动问题修复的概率将大幅提升。【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考