Development notes 开发说明 

Collection of various notes about development practices, how-to’s or checklists.
关于开发实践、操作指南或清单的各种笔记集合。

Adding a new ioctl, extending an existing one
添加新的 ioctl，扩展现有的 ioctl。

• add code to strace so the ioctl calls are parsed into a human readable form. Most of the ioctls are already implemented and can be used a reference.
  添加代码到 strace，以便将 ioctl 调用解析为人类可读的形式。大多数 ioctl 已经实现并可以用作参考。

Tracepoints 跟踪点

The tracepoint message format should be compact and consistent, so please stick to the following format:
跟踪点消息格式应简洁一致，请遵循以下格式：

• key=value no spaces around =
  键=值 等号周围不要有空格

• separated by spaces, not commas
  用空格分隔，而不是逗号

• named values: print value and string, like “%llu(%s)”, no space between, string in parens
  命名值：打印值和字符串，如“%llu(%s)”，之间不要有空格，字符串在括号内

• avoid abbreviating key values too much, (e.g. use ‘size’ not ‘sz’)
  避免过度缩写键值（例如使用'size'而不是'sz'）

• hexadecimal values are always preceded by 0x (use “0x%llx”)
  十六进制值始终以 0x 开头（使用“0x%llx”）

• use struct btrfs_inode for inode types, not plain struct inode
  对于 inode 类型，请使用 struct btrfs_inode，而不是普通的 struct inode

• inode number type is u64, use btrfs_ino if needed
  inode 编号类型为 u64，如有需要，请使用 btrfs_ino

• key can be printed as [%llu,%u,%llu]
  键可以打印为[%llu，%u，%llu]

• enum types need to be exported as TRACE_DEFINE_ENUM
  枚举类型需要导出为 TRACE_DEFINE_ENUM

Example: 例子:

event: btrfs__chunk 事件：btrfs__chunk

string: "root=%llu(%s) offset=%llu size=%llu num_stripes=%d sub_stripes=%d type=%s" 字符串： "root=%llu(%s) offset=%llu size=%llu num_stripes=%d sub_stripes=%d type=%s"

Error messages, verbosity
错误消息，详细程度 

• use btrfs_* helpers (btrfs_err, btrfs_info, …), they print a filesystem identification like BTRFS info (device sdb): ...
  使用 btrfs_* 助手（btrfs_err，btrfs_info，...），它们会打印类似 BTRFS info (device sdb): ... 的文件系统标识

• first letter in the string is lowercase
  字符串中的第一个字母是小写

• message contents 消息内容

  • be descriptive 要描述性的

  • keep the text length reasonable (fits one line without wrapping)
    保持文本长度合理（一行不换行）

  • no typos 没有拼写错误

  • print values that refer to what happened (inode number, subvolume id, path, offset, …)
    打印指向发生的事件的值（索引节点号、子卷 ID、路径、偏移量等）

  • print error value from the last call
    打印上次调用的错误值

  • no “\n” at the end of the string
    字符串末尾没有“\n”

  • no “.’’ at the end of text
    文本末尾不要有“。”

  • un-indent the string so it fits under 80 columns
    不要缩进字符串，使其适合在 80 列下

  • don’t split long strings, overflow 80 is ok in this case (we want to be able to search for the error messages in the sources easily)
    不要拆分长字符串，在这种情况下超过 80 是可以的（我们希望能够轻松地在源代码中搜索错误消息）

• value representation 值表示

  • decimal: offsets, length, ordinary numbers
    十进制：偏移量，长度，普通数字

  • hexadecimal: checksums 十六进制：校验和

  • hexadecimal + string: bitmasks (e.g. raid profiles, flags)
    十六进制 + 字符串：位掩码（例如 RAID 配置文件、标志）

  • intervals of integers: 整数区间：

    • closed interval (end values inclusive): [0, 4096]
      闭区间（包括结束值）：[0, 4096]

    • half-open (right value excluded): [0, 4096)
      半开区间（右值不包括）：[0, 4096)

    • half-open (left value excluded): (0, 4096] -- that one may look strange but is used in several places
      半开区间（左值不包括）：(0, 4096] -- 这个可能看起来有点奇怪，但在几个地方被使用

Message level 消息级别 

• btrfs_err -- such messages have high visibility so use them for serious problems that need user attention
  btrfs_err -- 这些消息具有很高的可见性，因此用于需要用户关注的严重问题

• btrfs_warn -- conditions that are not too serious but can point to potential problems, the system should be still in a good state
  btrfs_warn -- 不太严重但可能指向潜在问题的条件，系统应该仍处于良好状态

• btrfs_info -- use for informative messages that are useful to see what’s happening in the filesystem or might help debugging problems in the future and are worth keeping in the logs
  btrfs_info -- 用于信息性消息，有助于查看文件系统中正在发生的情况或可能有助于未来调试问题，并值得保留在日志中

Error handling and transaction abort
错误处理和事务中止

Please keep all transaction abort exactly at the place where they happen and do not merge them to one. This pattern should be used everywhere and is important when debugging because we can pinpoint the line in the code from the syslog message and do not have to guess which way it got to the merged call.
请确保所有事务中止都准确地发生在它们发生的地方，不要将它们合并为一个。这种模式应该在任何地方使用，并且在调试时非常重要，因为我们可以从系统日志消息中准确定位代码中的行，而不必猜测它是如何到达合并调用的。

Error handling and return values
错误处理和返回值

Functions are supposed to handle all errors of the callees and clean up the local context before returning. If a function does not need to pass errors to the caller it can be switched to return void. Before doing so make sure that:
函数应该处理调用者的所有错误，并在返回之前清理本地上下文。如果函数不需要将错误传递给调用者，则可以切换为返回 void。在这样做之前，请确保：

• the function does not call any BUG/BUG_ON
  函数不调用任何 BUG/BUG_ON

• all callees properly handle errors and do not call BUG/BUG_ON in place of error handling
  所有的被调用者都正确处理错误，并且不在错误处理的地方调用 BUG/BUG_ON

• the whole call chain starting from the function satisfies the above
  从满足上述函数开始的整个调用链

Handling unexpected conditions
处理意外条件

This is different than error handling. An unexpected condition happens when the code invariants/assumptions do not hold and there’s no way to recover from the situation. This means that returning an error to the caller can’t be done and continuing would only propagate the logic error further. The reasons for that bug can be two fold: internal (a genuine bug) or external (e.g. memory bitflip, memory corrupted by other subsystem). In this case it is allowed to use the nuclear option and do BUG_ON, that is otherwise highly discouraged.
这与错误处理不同。当代码的不变性/假设不成立且无法从情况中恢复时，就会发生意外情况。这意味着无法向调用者返回错误，继续操作只会进一步传播逻辑错误。造成该错误的原因可能有两种：内部原因（真正的错误）或外部原因（例如内存位翻转，其他子系统损坏的内存）。在这种情况下，允许使用核心选项并执行 BUG_ON，否则是极不鼓励的。

There are several ways how to react to the unexpected conditions:
如何对意外情况做出反应有几种方式：

• btrfs_abort_transaction()

  The recommended way if and only if we can not recover from the situation and have a transaction handle.
  推荐的方式是只有在我们无法从情况中恢复并且有事务处理时。

  This would cause the filesystem to be flipped read-only to prevent further corruption.
  这将导致文件系统被翻转为只读，以防止进一步损坏。

  Additionally call trace would be dumpped for the first btrfs_abort_transaction() call site.
  此外，将为第一个 btrfs_abort_transaction()调用站点转储调用跟踪。

• ASSERT()

  Conditionally compiled in and crashes when the condition is false.
  当条件为假时，条件编译并崩溃。

  This should only be utilized for debugging purposes, acts as a fail-fast option for developers, thus should not be utilized for error handling.
  这应仅用于调试目的，作为开发人员的快速失败选项，因此不应用于错误处理。

  It’s recommended only for very basic (thus sometimes unnecessary) requirements. Such usage should be easy to locate, have no complex call chain. E.g. to rule out invalid function parameter combinations.
  仅建议用于非常基本（因此有时是不必要的）要求。此类用法应易于定位，没有复杂的调用链。例如，排除无效的函数参数组合。

  Should not be utilized on any data/metadata reads from disks, as they can be invalid. For sanity check examples of on-disk metadata, please refer to Tree checker.
  不应在从磁盘读取任何数据/元数据时使用，因为它们可能无效。有关磁盘上元数据的健全性检查示例，请参考 Tree checker。

• WARN_ON 警告

  Unconditional and noisy checks, but still allow the code to continue.
  无条件且嘈杂的检查，但仍允许代码继续运行。

  Should only be utilized if a call trace is critical for debugging.
  仅在调试时关键时才应使用通话跟踪。

  Not recommended if: 不建议在以下情况使用：

  • The call site is unique or can be easily located
    通话位置是唯一的或可以轻松定位。

    In that case, an error message is recommended.
    在这种情况下，建议显示错误消息。

  • The call site would eventually lead to a btrfs_abort_transaction() call
    调用点最终会导致调用 btrfs_abort_transaction()。

    btrfs_abort_transaction() call would dump the stack anyway. If the call trace is critical, it’s recommended to move the btrfs_abort_transaction() call closer to the place where the error happens.
    btrfs_abort_transaction() 调用无论如何都会转储堆栈。如果调用跟踪很关键，建议将 btrfs_abort_transaction() 调用移动到发生错误的地方附近。

• BUG_ON

  Should not be utilized, and is incrementally removed or replaced in the code.
  不应该被使用，并且在代码中逐步被移除或替换。

Error injection using eBPF
使用 eBPF 进行错误注入 

Functions can be annotated to enable error injection using the eBPF scripts. See e.g. disk-io.c:open_ctree. For btrfs-specific injection, the annotation is ALLOW_ERROR_INJECTION, but beware that this only overrides the return value and this can leak memory or other resources. For error injection to generic helpers (e.g. memory allocation), you can use something like bcc/tools/inject.py kmalloc btrfs_alloc_device() -P 0.001
函数可以被注释以启用使用 eBPF 脚本进行错误注入。例如查看 disk-io.c:open_ctree 。对于特定于 btrfs 的注入，注释是 ALLOW_ERROR_INJECTION，但请注意，这仅覆盖返回值，这可能会泄漏内存或其他资源。对于对通用助手（例如内存分配）进行错误注入，您可以使用类似 bcc/tools/inject.py kmalloc btrfs_alloc_device() -P 0.001 的东西。

Resources: 资源：

• eBPF

• BCC tools BCC 工具

Warnings and issues found by static checkers and similar tools
静态检查器和类似工具发现的警告和问题 

There are tools to automatically identify known issues in code and report them as problems to be fixed, but not all such reports are valid or relevant in the context of the code base. The fix should really fix the code, not just the tool’s warning. Such patches will be rejected with explanation first time and ignored when sent repeatedly. Patches fixing real problems with a good explanation are welcome. If you’re not sure about sending such patch, please ask the https://kernelnewbies.org/KernelJanitors for help.
有工具可以自动识别代码中已知问题并将其报告为需要修复的问题，但并非所有这类报告在代码库的上下文中都是有效或相关的。修复应该真正修复代码，而不仅仅是工具的警告。这样的补丁将首次被拒绝并附有解释，并在重复发送时被忽略。欢迎提供解释良好的修复真正问题的补丁。如果您不确定是否发送此类补丁，请向 https://kernelnewbies.org/KernelJanitors 寻求帮助。

Do not blindly report issues caught by:
不要盲目报告被检测到的问题：

• checkpatch.pl -- the script is good for catching some coding style but this whole wiki page exists to be explicit what we want, not necessarily what checkpatch wants
  checkpatch.pl -- 该脚本适用于捕捉一些编码风格，但整个维基页面的存在是为了明确我们想要的，而不一定是 checkpatch 想要的

• clang static analyzer -- lots of the reports are not real problems and may depend on a condition that’s not recognized by the checker
  clang 静态分析器 -- 许多报告并非真正的问题，可能取决于检查器未识别的条件

• gcc -Wunused -- any of the -Wunused-* options can report a valid issue but it must be viewed in wider context and not just removed to get rid of the warning
  gcc -Wunused -- 任何 -Wunused-* 选项都可能报告一个有效问题，但必须在更广泛的背景下查看，不能仅仅为了消除警告而将其删除

• codespell -- fixing typos is fine but should be done in batches and over whole code base
  codespell -- 修复拼写错误是可以的，但应该批量进行，并覆盖整个代码库

Hints: 提示:

• if you find an issue, look in the whole code base if there are more instances same or following a similar pattern
  如果您发现问题，请查看整个代码库，看看是否有更多相同或类似模式的实例

• look into git history of the changed code, why it got there and when, it may help to understand if it’s a bug or e.g. a stale code
  查看更改代码的 git 历史记录，为什么会出现这种情况以及何时出现，这可能有助于理解它是一个 bug 还是例如一个过时的代码

Coding style preferences
编码风格偏好 

Before applying recommendations from this sections, please make sure you’re familiar with the kernel coding style guide.
在应用本节推荐之前，请确保您熟悉内核编码风格指南。

The purpose of coding style is to maintain unified and consistent look & feel of the patches and code, keeping distractions to minimum which decreases cognitive load and allows focus on the important things. Coding style is not only where to put white space or curly brackets but also coding patterns with meaning that is established and understood in the developer group. The code in linux kernel is maintained for a long period of time and maintainability is of crucial importance. This means it does take time to write good code, with attention to detail. Once written the code could stay unchanged for years but will be read many times. Read more.
编码风格的目的是保持补丁和代码的统一和一致的外观和感觉，尽量减少干扰，降低认知负荷，使注意力集中在重要事项上。编码风格不仅涉及空格或花括号的放置位置，还涉及具有意义的编码模式，这些模式在开发人员组中得到建立和理解。Linux 内核中的代码将被长时间维护，可维护性至关重要。这意味着编写优秀的代码需要时间，并且需要注意细节。一旦编写完成，代码可能在多年内保持不变，但会被多次阅读。阅读更多。

Patches 补丁

• for patch subject use “btrfs:” followed by a lowercase
  对于补丁主题，请使用“btrfs:”后跟小写字母

• read the patch again and fix all typos and grammar
  重新阅读补丁并修复所有拼写错误和语法错误

• size units should use short form K/M/G/T or IEC form KiB/MiB/GiB
  大小单位应使用简短形式 K/M/G/T 或 IEC 形式 KiB/MiB/GiB

• don’t write references to parameters to subject (like removing @pointer)
  不要将参数引用写到主题中（比如删除 @pointer）

• do not end subject with a dot ‘.’
  不要以句点“。”结尾主题

• parts of btrfs that could have a subject prefix to point to a specific subsystem
  btrfs 的部分可以有一个主题前缀，指向特定的子系统

  • scrub, tests, integrity-checker, tree-checker, discard, locking, sysfs, raid56, qgroup, compression, send, ioctl
    scrub、tests、integrity-checker、tree-checker、discard、locking、sysfs、raid56、qgroup、compression、send、ioctl

• additional information 附加信息

  • if there’s a stack trace relevant for the patch, add it ther (lockdep, crash, warning)
    如果有与补丁相关的堆栈跟踪，请在此处添加（lockdep、crash、warning）

  • steps to reproduce a bug (that will also get turned to a proper fstests case)
    复现错误的步骤（这也将转换为适当的 fstests 案例）

  • sample output before/after if it could have impact on userspace
    如果对用户空间可能产生影响，请在之前/之后进行示例输出

  • pahole output if structure is being reorganized and optimized
    如果结构正在重新组织和优化，则显示 pahole 输出

Function declarations 函数声明

• avoid prototypes for static functions, order them in new code in a way that does not need it
  避免为静态函数使用原型，在新代码中以不需要原型的方式对其进行排序

  • but don’t move static functions just to get rid of the prototype
    但不要仅仅为了摆脱原型而移动静态函数

• exported functions have btrfs_ prefix
  导出函数应该有 btrfs_ 前缀

• do not use functions with double underscore, there’s only a few valid uses of that, namely when __function is doing the core of the work with looser checks, no locks or more parameters than function
  不要使用双下划线函数，只有少数几种有效用途，即当 __function 在执行核心工作时使用较宽松的检查，无锁或比函数更多的参数

• function type and name are on the same line, if this is too long, the parameters continue on the next line (indented)
  函数类型和名称在同一行，如果太长，参数将继续在下一行（缩进）

• ‘static inline’ functions should be small (measured by their resulting binary size)
  “静态内联”函数应该很小（通过它们生成的二进制大小来衡量）

• conditional definitions should follow the style below, where the full function body is in .c
  条件定义应遵循以下样式，其中完整的函数体在 .c 中

#ifdef CONFIG_BTRFS_DEBUG
void btrfs_assert_everything_is_fine(void *ptr);
#else
void btrfs_assert_everything_is_fine(void *ptr) { }
#endif

Headers 头文件 

• leave one newline before #endif in headers
  在头文件中的 #endif 前留一个空行

Comments 注释 

• function comment goes to the .c file, not the header
  函数注释写在 .c 文件中，而不是头文件中

  • kdoc style is recommended but the exact syntax is not mandated and we’re using only subset of the formatting
    推荐使用 kdoc 风格，但具体语法并非强制，我们只使用格式的子集

  • the first line (mandatory): contains a brief description of what the function does and should provide a summary information
    第一行（必填）：包含函数的简要描述，应提供摘要信息

    • do write in the imperative style “Iterate all pages and clear some bits”
      请使用祈使句风格编写“迭代所有页面并清除一些位”

    • don’t write “This function is a helper to …”, “This is used to …”
      不要写“此函数是一个辅助函数...”，“这是用来...”

  • parameter description (optional):
    参数描述（可选）：

    • each line describes the parameter
      每行描述一个参数

    • the list needs to be in the same order as for the function
      列表需要与函数的顺序相同

    • the list needs to be complete
      列表需要完整

    • trivial parameters don’t need to be explained, e.g. fs_info is clear so the description could be ‘the filesystem’
      不需要解释琐碎的参数，例如 fs_info 很明显，所以描述可以是“文件系统”

    • context of the parameters matters a lot in some cases and cannot be inferred from the name, then it should be documented
      在某些情况下，参数的上下文非常重要，不能从名称中推断出来，那么应该进行文档记录

/*
 * Look for blocks in the given offset.
 *
 * @fs_info:    trivial parameters should be in the list but with some short description
 * @offset:     describe the context of the argument, e.g. offset to page or inode ...
 *
 * Long description comes here if necessary.
 *
 * Return value semantics if it's not obvious
 */

• comment new enum/define values, brief description or pointers to the code that uses them
  注释新的枚举/定义值，简要描述或指向使用它们的代码

• comment new data structures, their purpose and context of use
  注释新的数据结构，它们的目的和使用背景

• do not put struct member comments on the same line, put it on the line before and do not trim/abbreviate the text
  不要将结构成员注释放在同一行，将其放在前一行，并且不要修剪/缩写文本

• comment text that fits on one line can use the /* text */ format, slight overflow of 80 chars is OK
  适合一行的注释文本可以使用 /* 文本 */ 格式，80 个字符的轻微溢出是可以接受的

Misc 杂项 

• fix spelling, grammar and formatting of comments that get moved or changed
  修正被移动或更改的注释的拼写、语法和格式

• fix coding style in code that’s only moved
  修复仅移动的代码中的编码样式

• one newline between functions
  函数之间有一个换行符

Locking 锁定

• do not use spin_is_locked but lockdep_assert_held
  不要使用 spin_is_locked 而使用 lockdep_assert_held

• do not use assert_spin_locked without reading it’s semantics (it does not check if the caller hold the lock)
  在不阅读其语义的情况下不要使用 assert_spin_locked （它不检查调用者是否持有锁）

• use lockdep_assert_held and its friends for lock assertions
  使用 lockdep_assert_held 及其相关内容进行锁定断言

• add lock assertions to functions called deep in the call chain
  在调用链中深处的函数中添加锁断言

Code 代码

• default function return value is int ret, temporary return values should be named like ret2 etc
  默认函数返回值是 int ret，临时返回值应该命名为 ret2 等

• structure initializers should use { 0 }
  结构初始化器应该使用 { 0 }

• do not use short type if possible, if it fits to char/u8 use it instead, or plain int
  如果可能的话不要使用短类型，如果适合使用 char/u8，就使用它，或者使用 plain int

Output 输出 

• when dumping a lot of data after an error, consider what will remain visible last
  在错误发生后转储大量数据时，请考虑最后保留可见的内容

  • in case of btrfs_print_leaf, print the specific error message after that
    在 btrfs_print_leaf 的情况下，在此之后打印特定的错误消息

Expressions, operators 表达式，运算符 

• spaces around binary operators, no spaces for unary operators
  二进制运算符周围的空格，一元运算符不需要空格

• extra braces around expressions that might be harder to understand wrt precedence are fine (logical and/or, shifts with other operations)
  可能更难理解优先级的表达式周围的额外括号是可以的（逻辑与/或，与其他操作一起的移位）

  • a * b + c, (a << b) + c, (a % b) + c
    a * b + c，(a << b) + c，(a % b) + c

• 64bit division is not allowed, either avoid it completely, or use bit shifts or use div_u64 helpers
  不允许 64 位除法，要么完全避免使用，要么使用位移或使用 div_u64 辅助函数

• do not use chained assignments: no a = b = c;
  不要使用链式赋值：不要 a = b = c;

Variable declarations, parameters
变量声明，参数声明 

• declaration block in a function should do only simple initializations (pointers, constants); nothing that would require error handling or has non-trivial side effects
  函数中的声明块应该只进行简单的初始化（指针，常量）；不应该包含需要错误处理或具有非平凡副作用的内容

• use const extensively 广泛使用 const

• add temporary variable to store a value if it’s used multiple times in the function, or if reading the value needs to chase a long pointer chain
  如果在函数中多次使用某个值，或者读取该值需要追踪长指针链，则添加临时变量来存储该值

Kernel config options 内核配置选项

Compile-time config options for kernel that can help debugging, testing. They usually take a hit on performance or resources (memory) so they should be selected wisely. The options in bold should be safe to use by default for debugging builds.
内核的编译时配置选项，可以帮助调试和测试。它们通常会对性能或资源（内存）产生影响，因此应谨慎选择。粗体显示的选项应该默认情况下对调试构建是安全的。

Please refer to the option documentation for further details.
有关更多详细信息，请参考选项文档。

• devices for testing 用于测试的设备

  • CONFIG_BLK_DEV_LOOP - enable loop device
    CONFIG_BLK_DEV_LOOP - 启用循环设备

  • for fstests: DM_FLAKEY, CONFIG_FAIL_MAKE_REQUEST
    用于 fstests 的：DM_FLAKEY，CONFIG_FAIL_MAKE_REQUEST

  • CONFIG_SCSI_DEBUG - fake scsi block device
    CONFIG_SCSI_DEBUG - 伪 scsi 块设备

• memory 内存

  • CONFIG_SLUB_DEBUG - boot with slub_debug
    CONFIG_SLUB_DEBUG - 使用 slub_debug 启动

  • CONFIG_DEBUG_PAGEALLOC + CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT (on newer kernels)
    CONFIG_DEBUG_PAGEALLOC + CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT（在较新的内核上）

  • CONFIG_SCHED_STACK_END_CHECK

  • CONFIG_PAGE_POISONING

  • CONFIG_HAVE_DEBUG_KMEMLEAK

  • CONFIG_FAILSLAB -- fault injection to kmalloc

  • CONFIG_DEBUG_LIST

  • CONFIG_BUG_ON_DATA_CORRUPTION
    数据损坏时配置错误

• btrfs

  • CONFIG_BTRFS_DEBUG 调试配置 Btrfs

  • CONFIG_BTRFS_ASSERT

  • CONFIG_BTRFS_FS_RUN_SANITY_TESTS -- basic tests on module load
    CONFIG_BTRFS_FS_RUN_SANITY_TESTS -- 模块加载时的基本测试

  • CONFIG_BTRFS_FS_CHECK_INTEGRITY -- block integrity checker enabled by mount options
    CONFIG_BTRFS_FS_CHECK_INTEGRITY -- 通过挂载选项启用块完整性检查器

  • CONFIG_BTRFS_FS_REF_VERIFY -- additional checks for block references
    CONFIG_BTRFS_FS_REF_VERIFY -- 块引用的额外检查

• locking 锁定

  • CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_MUTEXES
    CONFIG_DEBUG_SPINLOCK，CONFIG_DEBUG_MUTEXES

  • CONFIG_DEBUG_LOCK_ALLOC 配置调试锁分配

  • CONFIG_PROVE_LOCKING, CONFIG_LOCKDEP
    配置证明锁定，配置锁依赖

  • CONFIG_LOCK_STAT 配置锁统计

  • CONFIG_PROVE_RCU

  • CONFIG_DEBUG_ATOMIC_SLEEP

• sanity checks 合理性检查

  • CONFIG_DEBUG_STACK_USAGE, CONFIG_HAVE_DEBUG_STACKOVERFLOW, CONFIG_DEBUG_STACKOVERFLOW
    CONFIG_DEBUG_STACK_USAGE，CONFIG_HAVE_DEBUG_STACKOVERFLOW，CONFIG_DEBUG_STACKOVERFLOW

  • CONFIG_STACKTRACE

  • CONFIG_KASAN -- address sanitizer
    CONFIG_KASAN -- 地址检测器

  • CONFIG_UBSAN -- undefined behaviour sanitizer
    CONFIG_UBSAN -- 未定义行为检测器

  • CONFIG_KCSAN -- concurrency checker
    CONFIG_KCSAN -- 并发检查器

• verbose reporting 详细报告

  • CONFIG_DEBUG_BUGVERBOSE 配置调试错误详细信息

• tracing 追踪

  • CONFIG_TRACING etc 配置追踪等

BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
BUG: MAX_LOCKDEP_CHAIN_HLOCKS 太低！

Not a bug. The lockdep structures can get in some cases full and cannot properly track locks anymore. There’s only a workaround to increase the kernel config value of CONFIG_LOCKDEP_CHAINS_BITS, default is 16, 18 tends to work, increase if needed.
不是一个 bug。在某些情况下，lockdep 结构可能会变满，无法正确跟踪锁。只能通过增加内核配置值 CONFIG_LOCKDEP_CHAINS_BITS 来解决，默认值为 16，18 似乎有效，根据需要增加。

fstests setup fstests 设置

The fstests suite has very few “hard” requirements and will succeed without actually running many tests. In order to ensure full test coverage, your test environment should provide the settings from the following sections. Please note that newly added tests silently add new dependencies, so you should always review results after an update.
fstests 套件几乎没有“硬性”要求，并且可以在不运行许多测试的情况下成功。为了确保完整的测试覆盖率，您的测试环境应提供以下部分的设置。请注意，新添加的测试会悄悄地添加新的依赖项，因此您应始终在更新后审查结果。

Kernel config options for complete test coverage
用于完整测试覆盖的内核配置选项

• CONFIG_FAULT_INJECTION=y

• CONFIG_FAULT_INJECTION_DEBUG_FS=y

• CONFIG_FAIL_MAKE_REQUEST=y

• CONFIG_DM_FLAKEY=m or y  CONFIG_DM_FLAKEY=m 或 y

• CONFIG_DM_THIN_PROVISIONING=m or y  CONFIG_DM_THIN_PROVISIONING=m 或 y

• CONFIG_DM_SNAPSHOT=m or y  CONFIG_DM_SNAPSHOT=m 或 y

• CONFIG_DM_DELAY=m or y  CONFIG_DM_DELAY=m 或 y

• CONFIG_DM_ERROR=m or y  CONFIG_DM_ERROR=m 或 y

• CONFIG_DM_LOG_WRITES=m or y  CONFIG_DM_LOG_WRITES=m 或 y

• CONFIG_DM_DUST=m or y  CONFIG_DM_DUST=m 或 y

• CONFIG_DM_ZERO=m or y  CONFIG_DM_ZERO=m 或 y

• CONFIG_BLK_DEV_LOOP=m or y  CONFIG_BLK_DEV_LOOP=m 或 y

• CONFIG_EXT4_FS=m or y  CONFIG_EXT4_FS=m 或 y

• CONFIG_SCSI_DEBUG=m

• CONFIG_BLK_DEV_ZONED=y for zoned mode test coverage
  用于分区模式测试覆盖率

• CONFIG_IO_URING==y

Kernel config options for better bug reports
更好的错误报告的内核配置选项

See the list in the section above for more options.
查看上面部分中的列表以获取更多选项。

User space utilities and development library dependencies
用户空间实用程序和开发库依赖项

• acl

• attr

• btrfsprogs

• dbench

• dmsetup (device-mapper) dmsetup（设备映射器）

• duperemove

• psmisc (killall) psmisc（killall）

• e2fsprogs

• fio

• fsverity-utils

• libacl

• libaio

• libattr

• libcap-progs

• libuuid

• lvm2

• openssl

• xfsprogs >= 4.3.1 (xfs_io -c reflink is required)
  xfsprogs >= 4.3.1 (需要 xfs_io -c reflink )

Note: This list may be incomplete.
注意：此列表可能不完整。

Storage environment 存储环境

• At least 4 identically sized partitions/disks/virtual disks, specified using $SCRATCH_DEV_POOL, some tests may require 8 such partitions
  至少有 4 个相同大小的分区/磁盘/虚拟磁盘，使用 $SCRATCH_DEV_POOL 指定，一些测试可能需要 8 个这样的分区

• some tests need at least 10G of free space, as determined by df, i.e. the size of the device may need to be larger
  一些测试需要至少 10G 的可用空间，由 df 确定，即设备的大小可能需要更大

• some tests require $LOGWRITES_DEV, yet another separate block device, for power fail testing
  一些测试需要 $LOGWRITES_DEV ，另一个单独的块设备，用于断电测试

• for testing trim and discard, the devices must be capable of that (physical or virtual)
  为了测试修剪和丢弃，设备必须具备这样的功能（物理或虚拟）

Other requirements 其他要求 

• An fsgqa user and group must exist.
  必须存在一个 fsgqa 用户和组。

• An fsgqa2 user and group must exist.
  必须存在一个 fsgqa2 用户和组。

• The user nobody must exist.
  用户 nobody 必须存在。

• An 123456-fsgqa user and group must exist.
  必须存在一个 123456-fsgqa 用户和组。