[PATCH 0/8] Docs/zh_CN: Update some translation to 5.19-rc8

[PATCH 0/8] Docs/zh_CN: Update some translation to 5.19-rc8

[Yanteng Si]

Update the following Chinese documents to 5.19-rc8:

iio
dev-tools
mm/damon
PCI
scheduler


Yanteng Si (8):
  Docs/zh_CN: Update the translation of iio_configfs to 5.19-rc8
  Docs/zh_CN: Update the translation of kasan to 5.19-rc8
  Docs/zh_CN: Update the translation of sparse to 5.19-rc8
  Docs/zh_CN: Update the translation of testing-overview to 5.19-rc8
  Docs/zh_CN: Update the translation of usage to 5.19-rc8
  Docs/zh_CN: Update the translation of pci-iov-howto to 5.19-rc8
  Docs/zh_CN: Update the translation of pci to 5.19-rc8
  Docs/zh_CN: Update the translation of sched-stats to 5.19-rc8

 .../translations/zh_CN/PCI/pci-iov-howto.rst  |   7 +-
 Documentation/translations/zh_CN/PCI/pci.rst  |   6 +-
 .../zh_CN/admin-guide/mm/damon/usage.rst      |   2 +
 .../translations/zh_CN/dev-tools/kasan.rst    | 117 ++++++++++++------
 .../translations/zh_CN/dev-tools/sparse.rst   |   2 +
 .../zh_CN/dev-tools/testing-overview.rst      |  25 ++++
 .../translations/zh_CN/iio/iio_configfs.rst   |  12 +-
 .../zh_CN/scheduler/sched-stats.rst           |   8 +-
 8 files changed, 123 insertions(+), 56 deletions(-)

-- 
2.31.1

[PATCH 1/8] Docs/zh_CN: Update the translation of iio_configfs to 5.19-rc8

[Yanteng Si]

update to commit dafcf4ed8392 ("iio: hrtimer: Allow
sub Hz granularity").

c1d82dbcb0a6 ("docs: iio: fix example formatting").

Remove some useless spaces.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../translations/zh_CN/iio/iio_configfs.rst          | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/Documentation/translations/zh_CN/iio/iio_configfs.rst b/Documentation/translations/zh_CN/iio/iio_configfs.rst
index d5460e951804..eccaf1c644b4 100644
--- a/Documentation/translations/zh_CN/iio/iio_configfs.rst
+++ b/Documentation/translations/zh_CN/iio/iio_configfs.rst
@@ -37,10 +37,10 @@ configfs轻松配置的对象（例如：设备，触发器）。
 3. 软件触发器
 =============
 
-IIO默认configfs组之一是“触发器”组。 挂载configfs后可以自动访问它，并且可
+IIO默认configfs组之一是“触发器”组。挂载configfs后可以自动访问它，并且可
 以在/config/iio/triggers下找到。
 
-IIO软件触发器为创建多种触发器类型提供了支持。 通常在include/linux/iio
+IIO软件触发器为创建多种触发器类型提供了支持。通常在include/linux/iio
 /sw_trigger.h：中的接口下将新的触发器类型实现为单独的内核模块：
 ::
 
@@ -76,10 +76,10 @@ IIO软件触发器为创建多种触发器类型提供了支持。 通常在incl
 	.ops = &iio_trig_sample_ops,
   };
 
-module_iio_sw_trigger_driver(iio_trig_sample);
+  module_iio_sw_trigger_driver(iio_trig_sample);
 
-每种触发器类型在/config/iio/triggers下都有其自己的目录。 加载iio-trig-sample
-模块将创建“ trig-sample”触发器类型目录/config/iio/triggers/trig-sample.
+每种触发器类型在/config/iio/triggers下都有其自己的目录。加载iio-trig-sample
+模块将创建“trig-sample”触发器类型目录/config/iio/triggers/trig-sample.
 
 我们支持以下中断源（触发器类型）
 
@@ -102,3 +102,5 @@ module_iio_sw_trigger_driver(iio_trig_sample);
 ----------------------------
 
 "hrtimer”触发器类型没有来自/config dir的任何可配置属性。
+它确实引入了触发目录的sampling_frequency属性。
+该属性以Hz为单位设置轮询频率，精度为mHz。
\ No newline at end of file
-- 
2.31.1

Re: [PATCH 1/8] Docs/zh_CN: Update the translation of iio_configfs to 5.19-rc8

[Alex Shi]

On 7/25/22 17:20, Yanteng Si wrote:
> update to commit dafcf4ed8392 ("iio: hrtimer: Allow
> sub Hz granularity").
> 
> c1d82dbcb0a6 ("docs: iio: fix example formatting").
> 
> Remove some useless spaces.
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>

Reviewed-by: Alex Shi <alexs@kernel.org>
> ---
>  .../translations/zh_CN/iio/iio_configfs.rst          | 12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/translations/zh_CN/iio/iio_configfs.rst b/Documentation/translations/zh_CN/iio/iio_configfs.rst
> index d5460e951804..eccaf1c644b4 100644
> --- a/Documentation/translations/zh_CN/iio/iio_configfs.rst
> +++ b/Documentation/translations/zh_CN/iio/iio_configfs.rst
> @@ -37,10 +37,10 @@ configfs轻松配置的对象（例如：设备，触发器）。
>  3. 软件触发器
>  =============
>  
> -IIO默认configfs组之一是“触发器”组。 挂载configfs后可以自动访问它，并且可
> +IIO默认configfs组之一是“触发器”组。挂载configfs后可以自动访问它，并且可
>  以在/config/iio/triggers下找到。
>  
> -IIO软件触发器为创建多种触发器类型提供了支持。 通常在include/linux/iio
> +IIO软件触发器为创建多种触发器类型提供了支持。通常在include/linux/iio
>  /sw_trigger.h：中的接口下将新的触发器类型实现为单独的内核模块：
>  ::
>  
> @@ -76,10 +76,10 @@ IIO软件触发器为创建多种触发器类型提供了支持。 通常在incl
>  	.ops = &iio_trig_sample_ops,
>    };
>  
> -module_iio_sw_trigger_driver(iio_trig_sample);
> +  module_iio_sw_trigger_driver(iio_trig_sample);
>  
> -每种触发器类型在/config/iio/triggers下都有其自己的目录。 加载iio-trig-sample
> -模块将创建“ trig-sample”触发器类型目录/config/iio/triggers/trig-sample.
> +每种触发器类型在/config/iio/triggers下都有其自己的目录。加载iio-trig-sample
> +模块将创建“trig-sample”触发器类型目录/config/iio/triggers/trig-sample.
>  
>  我们支持以下中断源（触发器类型）
>  
> @@ -102,3 +102,5 @@ module_iio_sw_trigger_driver(iio_trig_sample);
>  ----------------------------
>  
>  "hrtimer”触发器类型没有来自/config dir的任何可配置属性。
> +它确实引入了触发目录的sampling_frequency属性。
> +该属性以Hz为单位设置轮询频率，精度为mHz。
> \ No newline at end of file

[PATCH 2/8] Docs/zh_CN: Update the translation of kasan to 5.19-rc8

[Yanteng Si]

update to commit 3ff16d30f593 ("kasan: test:
improve failure message in KUNIT_EXPECT_KASAN_FAIL()")

c9d1af2b780a ("mm/kasan: move kasan.fault to mm/kasan/report.c")
2d27e5851473 ("kasan: Extend KASAN mode kernel parameter")
8479d7b5be2f ("kasan: documentation updates")
c2ec0c8f6877 ("kasan: update documentation")

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../translations/zh_CN/dev-tools/kasan.rst    | 117 ++++++++++++------
 1 file changed, 77 insertions(+), 40 deletions(-)

diff --git a/Documentation/translations/zh_CN/dev-tools/kasan.rst b/Documentation/translations/zh_CN/dev-tools/kasan.rst
index 23db9d419047..20f22a5b4c27 100644
--- a/Documentation/translations/zh_CN/dev-tools/kasan.rst
+++ b/Documentation/translations/zh_CN/dev-tools/kasan.rst
@@ -11,34 +11,65 @@
 概述
 ----
 
-KernelAddressSANitizer(KASAN)是一种动态内存安全错误检测工具，主要功能是
-检查内存越界访问和使用已释放内存的问题。KASAN有三种模式:
+Kernel Address SANitizer(KASAN)是一种动态内存安全错误检测工具，主要功能是
+检查内存越界访问和使用已释放内存的问题。
 
-1. 通用KASAN（与用户空间的ASan类似）
-2. 基于软件标签的KASAN（与用户空间的HWASan类似）
-3. 基于硬件标签的KASAN（基于硬件内存标签）
+KASAN有三种模式:
 
-由于通用KASAN的内存开销较大，通用KASAN主要用于调试。基于软件标签的KASAN
-可用于dogfood测试，因为它具有较低的内存开销，并允许将其用于实际工作量。
-基于硬件标签的KASAN具有较低的内存和性能开销，因此可用于生产。同时可用于
-检测现场内存问题或作为安全缓解措施。
+1. 通用KASAN
+2. 基于软件标签的KASAN
+3. 基于硬件标签的KASAN
 
-软件KASAN模式（#1和#2）使用编译时工具在每次内存访问之前插入有效性检查，
-因此需要一个支持它的编译器版本。
+用CONFIG_KASAN_GENERIC启用的通用KASAN，是用于调试的模式，类似于用户空
+间的ASan。这种模式在许多CPU架构上都被支持，但它有明显的性能和内存开销。
 
-通用KASAN在GCC和Clang受支持。GCC需要8.3.0或更高版本。任何受支持的Clang
-版本都是兼容的，但从Clang 11才开始支持检测全局变量的越界访问。
+基于软件标签的KASAN或SW_TAGS KASAN，通过CONFIG_KASAN_SW_TAGS启用，
+可以用于调试和狗粮测试，类似于用户空间HWASan。这种模式只支持arm64，但其
+适度的内存开销允许在内存受限的设备上用真实的工作负载进行测试。
 
-基于软件标签的KASAN模式仅在Clang中受支持。
+基于硬件标签的KASAN或HW_TAGS KASAN，用CONFIG_KASAN_HW_TAGS启用，被
+用作现场内存错误检测器或作为安全缓解的模式。这种模式只在支持MTE（内存标签
+扩展）的arm64 CPU上工作，但它的内存和性能开销很低，因此可以在生产中使用。
 
-硬件KASAN模式（#3）依赖硬件来执行检查，但仍需要支持内存标签指令的编译器
-版本。GCC 10+和Clang 11+支持此模式。
+关于每种KASAN模式的内存和性能影响的细节，请参见相应的Kconfig选项的描述。
 
-两种软件KASAN模式都适用于SLUB和SLAB内存分配器，而基于硬件标签的KASAN目前
-仅支持SLUB。
+通用模式和基于软件标签的模式通常被称为软件模式。基于软件标签的模式和基于
+硬件标签的模式被称为基于标签的模式。
 
-目前x86_64、arm、arm64、xtensa、s390、riscv架构支持通用KASAN模式，仅
-arm64架构支持基于标签的KASAN模式。
+支持
+----
+
+体系架构
+~~~~~~~~
+
+在x86_64、arm、arm64、powerpc、riscv、s390和xtensa上支持通用KASAN，
+而基于标签的KASAN模式只在arm64上支持。
+
+编译器
+~~~~~~
+
+软件KASAN模式使用编译时工具在每个内存访问之前插入有效性检查，因此需要一个
+提供支持的编译器版本。基于硬件标签的模式依靠硬件来执行这些检查，但仍然需要
+一个支持内存标签指令的编译器版本。
+
+通用KASAN需要GCC 8.3.0版本或更高版本，或者内核支持的任何Clang版本。
+
+基于软件标签的KASAN需要GCC 11+或者内核支持的任何Clang版本。
+
+基于硬件标签的KASAN需要GCC 10+或Clang 12+。
+
+内存类型
+~~~~~~~~
+
+通用KASAN支持在所有的slab、page_alloc、vmap、vmalloc、堆栈和全局内存
+中查找错误。
+
+基于软件标签的KASAN支持slab、page_alloc、vmalloc和堆栈内存。
+
+基于硬件标签的KASAN支持slab、page_alloc和不可执行的vmalloc内存。
+
+对于slab，两种软件KASAN模式都支持SLUB和SLAB分配器，而基于硬件标签的
+KASAN只支持SLUB。
 
 用法
 ----
@@ -53,7 +84,7 @@ arm64架构支持基于标签的KASAN模式。
 
 对于软件模式，还可以在 ``CONFIG_KASAN_OUTLINE`` 和 ``CONFIG_KASAN_INLINE``
 之间进行选择。outline和inline是编译器插桩类型。前者产生较小的二进制文件，
-而后者快1.1-2倍。
+而后者快2倍。
 
 要将受影响的slab对象的alloc和free堆栈跟踪包含到报告中，请启用
 ``CONFIG_STACKTRACE`` 。要包括受影响物理页面的分配和释放堆栈跟踪的话，
@@ -172,21 +203,29 @@ KASAN受通用 ``panic_on_warn`` 命令行参数的影响。启用该功能后
 默认情况下，KASAN只为第一次无效内存访问打印错误报告。使用 ``kasan_multi_shot`` ，
 KASAN会针对每个无效访问打印报告。这有效地禁用了KASAN报告的 ``panic_on_warn`` 。
 
+另外，独立于 ``panic_on_warn`` , ``kasan.fault=`` 引导参数可以用来控制恐慌和报
+告行为:
+
+- ``kasan.fault=report`` 或 ``=panic`` 控制是只打印KASAN报告还是同时使内核恐慌
+  (默认: ``report`` )。即使启用了 ``kasan_multi_shot`` ，也会发生内核恐慌。
+
 基于硬件标签的KASAN模式（请参阅下面有关各种模式的部分）旨在在生产中用作安全缓解
-措施。因此，它支持允许禁用KASAN或控制其功能的引导参数。
+措施。因此，它支持允许禁用KASAN或控制其功能的附加引导参数。
 
 - ``kasan=off`` 或 ``=on`` 控制KASAN是否启用 (默认: ``on`` )。
 
-- ``kasan.mode=sync`` 或 ``=async`` 控制KASAN是否配置为同步或异步执行模式(默认:
-  ``sync`` )。同步模式：当标签检查错误发生时，立即检测到错误访问。异步模式：
-  延迟错误访问检测。当标签检查错误发生时，信息存储在硬件中（在arm64的
+- ``kasan.mode=sync`` 、 ``=async`` 或 ``=asymm`` 控制KASAN是否配置
+  为同步或异步执行模式(默认:``sync`` )。
+  同步模式：当标签检查错误发生时，立即检测到错误访问。
+  异步模式：延迟错误访问检测。当标签检查错误发生时，信息存储在硬件中（在arm64的
   TFSR_EL1寄存器中）。内核会定期检查硬件，并且仅在这些检查期间报告标签错误。
+  非对称模式：读取时同步检测不良访问，写入时异步检测。
+
+- ``kasan.vmalloc=off`` 或 ``=on`` 禁用或启用vmalloc分配的标记（默认：``on`` ）。
 
 - ``kasan.stacktrace=off`` 或 ``=on`` 禁用或启用alloc和free堆栈跟踪收集
   (默认: ``on`` )。
 
-- ``kasan.fault=report`` 或 ``=panic`` 控制是只打印KASAN报告还是同时使内核恐慌
-  (默认: ``report`` )。即使启用了 ``kasan_multi_shot`` ，也会发生内核恐慌。
 
 实施细则
 --------
@@ -244,7 +283,6 @@ KASAN会针对每个无效访问打印报告。这有效地禁用了KASAN报告
 基于软件标签的KASAN使用0xFF作为匹配所有指针标签（不检查通过带有0xFF指针标签
 的指针进行的访问）。值0xFE当前保留用于标记已释放的内存区域。
 
-基于软件标签的KASAN目前仅支持对Slab和page_alloc内存进行标记。
 
 基于硬件标签的KASAN模式
 ~~~~~~~~~~~~~~~~~~~~~~~
@@ -262,8 +300,6 @@ KASAN会针对每个无效访问打印报告。这有效地禁用了KASAN报告
 基于硬件标签的KASAN使用0xFF作为匹配所有指针标签（不检查通过带有0xFF指针标签的
 指针进行的访问）。值0xFE当前保留用于标记已释放的内存区域。
 
-基于硬件标签的KASAN目前仅支持对Slab和page_alloc内存进行标记。
-
 如果硬件不支持MTE（ARMv8.5之前），则不会启用基于硬件标签的KASAN。在这种情况下，
 所有KASAN引导参数都将被忽略。
 
@@ -275,6 +311,8 @@ KASAN会针对每个无效访问打印报告。这有效地禁用了KASAN报告
 影子内存
 --------
 
+本节的内容只适用于软件KASAN模式。
+
 内核将内存映射到地址空间的几个不同部分。内核虚拟地址的范围很大：没有足够的真实
 内存来支持内核可以访问的每个地址的真实影子区域。因此，KASAN只为地址空间的某些
 部分映射真实的影子。
@@ -297,7 +335,7 @@ CONFIG_KASAN_VMALLOC
 ~~~~~~~~~~~~~~~~~~~~
 
 使用 ``CONFIG_KASAN_VMALLOC`` ，KASAN可以以更大的内存使用为代价覆盖vmalloc
-空间。目前，这在x86、riscv、s390和powerpc上受支持。
+空间。目前，这在arm64、x86、riscv、s390和powerpc上受支持。
 
 这通过连接到vmalloc和vmap并动态分配真实的影子内存来支持映射。
 
@@ -349,10 +387,10 @@ KASAN连接到vmap基础架构以懒清理未使用的影子内存。
 ``kasan_disable_current()``/``kasan_enable_current()`` 部分注释这部分代码。
 这也会禁用通过函数调用发生的间接访问的报告。
 
-对于基于标签的KASAN模式（包括硬件模式），要禁用访问检查，请使用
-``kasan_reset_tag()`` 或 ``page_kasan_tag_reset()`` 。请注意，通过
-``page_kasan_tag_reset()`` 临时禁用访问检查需要通过 ``page_kasan_tag``
-/ ``page_kasan_tag_set`` 保存和恢复每页KASAN标签。
+对于基于标签的KASAN模式，要禁用访问检查，请使用 ``kasan_reset_tag()`` 或
+``page_kasan_tag_reset()`` 。请注意，通过 ``page_kasan_tag_reset()``
+临时禁用访问检查需要通过 ``page_kasan_tag`` / ``page_kasan_tag_set`` 保
+存和恢复每页KASAN标签。
 
 测试
 ~~~~
@@ -381,11 +419,10 @@ KASAN连接到vmap基础架构以懒清理未使用的影子内存。
 
 当由于缺少KASAN报告而导致测试失败时::
 
-        # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629
-        Expected kasan_data->report_expected == kasan_data->report_found, but
-        kasan_data->report_expected == 1
-        kasan_data->report_found == 0
-        not ok 28 - kmalloc_double_kzfree
+        # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:974
+        KASAN failure expected in "kfree_sensitive(ptr)", but none occurred
+        not ok 44 - kmalloc_double_kzfree
+
 
 最后打印所有KASAN测试的累积状态。成功::
 
-- 
2.31.1

Re: [PATCH 2/8] Docs/zh_CN: Update the translation of kasan to 5.19-rc8

[Alex Shi]

On 7/25/22 17:20, Yanteng Si wrote:
> update to commit 3ff16d30f593 ("kasan: test:
> improve failure message in KUNIT_EXPECT_KASAN_FAIL()")
> 
> c9d1af2b780a ("mm/kasan: move kasan.fault to mm/kasan/report.c")
> 2d27e5851473 ("kasan: Extend KASAN mode kernel parameter")
> 8479d7b5be2f ("kasan: documentation updates")
> c2ec0c8f6877 ("kasan: update documentation")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  .../translations/zh_CN/dev-tools/kasan.rst    | 117 ++++++++++++------
>  1 file changed, 77 insertions(+), 40 deletions(-)
> 
> diff --git a/Documentation/translations/zh_CN/dev-tools/kasan.rst b/Documentation/translations/zh_CN/dev-tools/kasan.rst
> index 23db9d419047..20f22a5b4c27 100644
> --- a/Documentation/translations/zh_CN/dev-tools/kasan.rst
> +++ b/Documentation/translations/zh_CN/dev-tools/kasan.rst
> @@ -11,34 +11,65 @@
>  概述
>  ----
>  
> -KernelAddressSANitizer(KASAN)是一种动态内存安全错误检测工具，主要功能是
> -检查内存越界访问和使用已释放内存的问题。KASAN有三种模式:
> +Kernel Address SANitizer(KASAN)是一种动态内存安全错误检测工具，主要功能是
> +检查内存越界访问和使用已释放内存的问题。
>  
> -1. 通用KASAN（与用户空间的ASan类似）
> -2. 基于软件标签的KASAN（与用户空间的HWASan类似）
> -3. 基于硬件标签的KASAN（基于硬件内存标签）
> +KASAN有三种模式:
>  
> -由于通用KASAN的内存开销较大，通用KASAN主要用于调试。基于软件标签的KASAN
> -可用于dogfood测试，因为它具有较低的内存开销，并允许将其用于实际工作量。
> -基于硬件标签的KASAN具有较低的内存和性能开销，因此可用于生产。同时可用于
> -检测现场内存问题或作为安全缓解措施。
> +1. 通用KASAN
> +2. 基于软件标签的KASAN
> +3. 基于硬件标签的KASAN
>  
> -软件KASAN模式（#1和#2）使用编译时工具在每次内存访问之前插入有效性检查，
> -因此需要一个支持它的编译器版本。
> +用CONFIG_KASAN_GENERIC启用的通用KASAN，是用于调试的模式，类似于用户空
> +间的ASan。这种模式在许多CPU架构上都被支持，但它有明显的性能和内存开销。
>  
> -通用KASAN在GCC和Clang受支持。GCC需要8.3.0或更高版本。任何受支持的Clang
> -版本都是兼容的，但从Clang 11才开始支持检测全局变量的越界访问。
> +基于软件标签的KASAN或SW_TAGS KASAN，通过CONFIG_KASAN_SW_TAGS启用，
> +可以用于调试和狗粮测试，类似于用户空间HWASan。这种模式只支持arm64，但其

dogfood testing usually means self testing, so maybe 自我测试 is better?

Reviewed-by: Alex Shi <alexs@kernel.org>

> +适度的内存开销允许在内存受限的设备上用真实的工作负载进行测试。
>  
> -基于软件标签的KASAN模式仅在Clang中受支持。
> +基于硬件标签的KASAN或HW_TAGS KASAN，用CONFIG_KASAN_HW_TAGS启用，被
> +用作现场内存错误检测器或作为安全缓解的模式。这种模式只在支持MTE（内存标签
> +扩展）的arm64 CPU上工作，但它的内存和性能开销很低，因此可以在生产中使用。
>  
> -硬件KASAN模式（#3）依赖硬件来执行检查，但仍需要支持内存标签指令的编译器
> -版本。GCC 10+和Clang 11+支持此模式。
> +关于每种KASAN模式的内存和性能影响的细节，请参见相应的Kconfig选项的描述。
>  
> -两种软件KASAN模式都适用于SLUB和SLAB内存分配器，而基于硬件标签的KASAN目前
> -仅支持SLUB。
> +通用模式和基于软件标签的模式通常被称为软件模式。基于软件标签的模式和基于
> +硬件标签的模式被称为基于标签的模式。
>  
> -目前x86_64、arm、arm64、xtensa、s390、riscv架构支持通用KASAN模式，仅
> -arm64架构支持基于标签的KASAN模式。
> +支持
> +----
> +
> +体系架构
> +~~~~~~~~
> +
> +在x86_64、arm、arm64、powerpc、riscv、s390和xtensa上支持通用KASAN，
> +而基于标签的KASAN模式只在arm64上支持。
> +
> +编译器
> +~~~~~~
> +
> +软件KASAN模式使用编译时工具在每个内存访问之前插入有效性检查，因此需要一个
> +提供支持的编译器版本。基于硬件标签的模式依靠硬件来执行这些检查，但仍然需要
> +一个支持内存标签指令的编译器版本。
> +
> +通用KASAN需要GCC 8.3.0版本或更高版本，或者内核支持的任何Clang版本。
> +
> +基于软件标签的KASAN需要GCC 11+或者内核支持的任何Clang版本。
> +
> +基于硬件标签的KASAN需要GCC 10+或Clang 12+。
> +
> +内存类型
> +~~~~~~~~
> +
> +通用KASAN支持在所有的slab、page_alloc、vmap、vmalloc、堆栈和全局内存
> +中查找错误。
> +
> +基于软件标签的KASAN支持slab、page_alloc、vmalloc和堆栈内存。
> +
> +基于硬件标签的KASAN支持slab、page_alloc和不可执行的vmalloc内存。
> +
> +对于slab，两种软件KASAN模式都支持SLUB和SLAB分配器，而基于硬件标签的
> +KASAN只支持SLUB。
>  
>  用法
>  ----
> @@ -53,7 +84,7 @@ arm64架构支持基于标签的KASAN模式。
>  
>  对于软件模式，还可以在 ``CONFIG_KASAN_OUTLINE`` 和 ``CONFIG_KASAN_INLINE``
>  之间进行选择。outline和inline是编译器插桩类型。前者产生较小的二进制文件，
> -而后者快1.1-2倍。
> +而后者快2倍。
>  
>  要将受影响的slab对象的alloc和free堆栈跟踪包含到报告中，请启用
>  ``CONFIG_STACKTRACE`` 。要包括受影响物理页面的分配和释放堆栈跟踪的话，
> @@ -172,21 +203,29 @@ KASAN受通用 ``panic_on_warn`` 命令行参数的影响。启用该功能后
>  默认情况下，KASAN只为第一次无效内存访问打印错误报告。使用 ``kasan_multi_shot`` ，
>  KASAN会针对每个无效访问打印报告。这有效地禁用了KASAN报告的 ``panic_on_warn`` 。
>  
> +另外，独立于 ``panic_on_warn`` , ``kasan.fault=`` 引导参数可以用来控制恐慌和报
> +告行为:
> +
> +- ``kasan.fault=report`` 或 ``=panic`` 控制是只打印KASAN报告还是同时使内核恐慌
> +  (默认: ``report`` )。即使启用了 ``kasan_multi_shot`` ，也会发生内核恐慌。
> +
>  基于硬件标签的KASAN模式（请参阅下面有关各种模式的部分）旨在在生产中用作安全缓解
> -措施。因此，它支持允许禁用KASAN或控制其功能的引导参数。
> +措施。因此，它支持允许禁用KASAN或控制其功能的附加引导参数。
>  
>  - ``kasan=off`` 或 ``=on`` 控制KASAN是否启用 (默认: ``on`` )。
>  
> -- ``kasan.mode=sync`` 或 ``=async`` 控制KASAN是否配置为同步或异步执行模式(默认:
> -  ``sync`` )。同步模式：当标签检查错误发生时，立即检测到错误访问。异步模式：
> -  延迟错误访问检测。当标签检查错误发生时，信息存储在硬件中（在arm64的
> +- ``kasan.mode=sync`` 、 ``=async`` 或 ``=asymm`` 控制KASAN是否配置
> +  为同步或异步执行模式(默认:``sync`` )。
> +  同步模式：当标签检查错误发生时，立即检测到错误访问。
> +  异步模式：延迟错误访问检测。当标签检查错误发生时，信息存储在硬件中（在arm64的
>    TFSR_EL1寄存器中）。内核会定期检查硬件，并且仅在这些检查期间报告标签错误。
> +  非对称模式：读取时同步检测不良访问，写入时异步检测。
> +
> +- ``kasan.vmalloc=off`` 或 ``=on`` 禁用或启用vmalloc分配的标记（默认：``on`` ）。
>  
>  - ``kasan.stacktrace=off`` 或 ``=on`` 禁用或启用alloc和free堆栈跟踪收集
>    (默认: ``on`` )。
>  
> -- ``kasan.fault=report`` 或 ``=panic`` 控制是只打印KASAN报告还是同时使内核恐慌
> -  (默认: ``report`` )。即使启用了 ``kasan_multi_shot`` ，也会发生内核恐慌。
>  
>  实施细则
>  --------
> @@ -244,7 +283,6 @@ KASAN会针对每个无效访问打印报告。这有效地禁用了KASAN报告
>  基于软件标签的KASAN使用0xFF作为匹配所有指针标签（不检查通过带有0xFF指针标签
>  的指针进行的访问）。值0xFE当前保留用于标记已释放的内存区域。
>  
> -基于软件标签的KASAN目前仅支持对Slab和page_alloc内存进行标记。
>  
>  基于硬件标签的KASAN模式
>  ~~~~~~~~~~~~~~~~~~~~~~~
> @@ -262,8 +300,6 @@ KASAN会针对每个无效访问打印报告。这有效地禁用了KASAN报告
>  基于硬件标签的KASAN使用0xFF作为匹配所有指针标签（不检查通过带有0xFF指针标签的
>  指针进行的访问）。值0xFE当前保留用于标记已释放的内存区域。
>  
> -基于硬件标签的KASAN目前仅支持对Slab和page_alloc内存进行标记。
> -
>  如果硬件不支持MTE（ARMv8.5之前），则不会启用基于硬件标签的KASAN。在这种情况下，
>  所有KASAN引导参数都将被忽略。
>  
> @@ -275,6 +311,8 @@ KASAN会针对每个无效访问打印报告。这有效地禁用了KASAN报告
>  影子内存
>  --------
>  
> +本节的内容只适用于软件KASAN模式。
> +
>  内核将内存映射到地址空间的几个不同部分。内核虚拟地址的范围很大：没有足够的真实
>  内存来支持内核可以访问的每个地址的真实影子区域。因此，KASAN只为地址空间的某些
>  部分映射真实的影子。
> @@ -297,7 +335,7 @@ CONFIG_KASAN_VMALLOC
>  ~~~~~~~~~~~~~~~~~~~~
>  
>  使用 ``CONFIG_KASAN_VMALLOC`` ，KASAN可以以更大的内存使用为代价覆盖vmalloc
> -空间。目前，这在x86、riscv、s390和powerpc上受支持。
> +空间。目前，这在arm64、x86、riscv、s390和powerpc上受支持。
>  
>  这通过连接到vmalloc和vmap并动态分配真实的影子内存来支持映射。
>  
> @@ -349,10 +387,10 @@ KASAN连接到vmap基础架构以懒清理未使用的影子内存。
>  ``kasan_disable_current()``/``kasan_enable_current()`` 部分注释这部分代码。
>  这也会禁用通过函数调用发生的间接访问的报告。
>  
> -对于基于标签的KASAN模式（包括硬件模式），要禁用访问检查，请使用
> -``kasan_reset_tag()`` 或 ``page_kasan_tag_reset()`` 。请注意，通过
> -``page_kasan_tag_reset()`` 临时禁用访问检查需要通过 ``page_kasan_tag``
> -/ ``page_kasan_tag_set`` 保存和恢复每页KASAN标签。
> +对于基于标签的KASAN模式，要禁用访问检查，请使用 ``kasan_reset_tag()`` 或
> +``page_kasan_tag_reset()`` 。请注意，通过 ``page_kasan_tag_reset()``
> +临时禁用访问检查需要通过 ``page_kasan_tag`` / ``page_kasan_tag_set`` 保
> +存和恢复每页KASAN标签。
>  
>  测试
>  ~~~~
> @@ -381,11 +419,10 @@ KASAN连接到vmap基础架构以懒清理未使用的影子内存。
>  
>  当由于缺少KASAN报告而导致测试失败时::
>  
> -        # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629
> -        Expected kasan_data->report_expected == kasan_data->report_found, but
> -        kasan_data->report_expected == 1
> -        kasan_data->report_found == 0
> -        not ok 28 - kmalloc_double_kzfree
> +        # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:974
> +        KASAN failure expected in "kfree_sensitive(ptr)", but none occurred
> +        not ok 44 - kmalloc_double_kzfree
> +
>  
>  最后打印所有KASAN测试的累积状态。成功::
>  

Re: [PATCH 2/8] Docs/zh_CN: Update the translation of kasan to 5.19-rc8

[YanTeng Si]

在 2022/7/27 10:15, Alex Shi 写道:
>
> On 7/25/22 17:20, Yanteng Si wrote:
>> update to commit 3ff16d30f593 ("kasan: test:
>> improve failure message in KUNIT_EXPECT_KASAN_FAIL()")
>>
>> c9d1af2b780a ("mm/kasan: move kasan.fault to mm/kasan/report.c")
>> 2d27e5851473 ("kasan: Extend KASAN mode kernel parameter")
>> 8479d7b5be2f ("kasan: documentation updates")
>> c2ec0c8f6877 ("kasan: update documentation")
>>
>> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
>> ---
>>   .../translations/zh_CN/dev-tools/kasan.rst    | 117 ++++++++++++------
>>   1 file changed, 77 insertions(+), 40 deletions(-)
>>
>> diff --git a/Documentation/translations/zh_CN/dev-tools/kasan.rst b/Documentation/translations/zh_CN/dev-tools/kasan.rst
>> index 23db9d419047..20f22a5b4c27 100644
>> --- a/Documentation/translations/zh_CN/dev-tools/kasan.rst
>> +++ b/Documentation/translations/zh_CN/dev-tools/kasan.rst
>> @@ -11,34 +11,65 @@
>>   概述
>>   ----
>>   
>> -KernelAddressSANitizer(KASAN)是一种动态内存安全错误检测工具，主要功能是
>> -检查内存越界访问和使用已释放内存的问题。KASAN有三种模式:
>> +Kernel Address SANitizer(KASAN)是一种动态内存安全错误检测工具，主要功能是
>> +检查内存越界访问和使用已释放内存的问题。
>>   
>> -1. 通用KASAN（与用户空间的ASan类似）
>> -2. 基于软件标签的KASAN（与用户空间的HWASan类似）
>> -3. 基于硬件标签的KASAN（基于硬件内存标签）
>> +KASAN有三种模式:
>>   
>> -由于通用KASAN的内存开销较大，通用KASAN主要用于调试。基于软件标签的KASAN
>> -可用于dogfood测试，因为它具有较低的内存开销，并允许将其用于实际工作量。
>> -基于硬件标签的KASAN具有较低的内存和性能开销，因此可用于生产。同时可用于
>> -检测现场内存问题或作为安全缓解措施。
>> +1. 通用KASAN
>> +2. 基于软件标签的KASAN
>> +3. 基于硬件标签的KASAN
>>   
>> -软件KASAN模式（#1和#2）使用编译时工具在每次内存访问之前插入有效性检查，
>> -因此需要一个支持它的编译器版本。
>> +用CONFIG_KASAN_GENERIC启用的通用KASAN，是用于调试的模式，类似于用户空
>> +间的ASan。这种模式在许多CPU架构上都被支持，但它有明显的性能和内存开销。
>>   
>> -通用KASAN在GCC和Clang受支持。GCC需要8.3.0或更高版本。任何受支持的Clang
>> -版本都是兼容的，但从Clang 11才开始支持检测全局变量的越界访问。
>> +基于软件标签的KASAN或SW_TAGS KASAN，通过CONFIG_KASAN_SW_TAGS启用，
>> +可以用于调试和狗粮测试，类似于用户空间HWASan。这种模式只支持arm64，但其
> dogfood testing usually means self testing, so maybe 自我测试 is better?

Great！


Thanks,

Yanteng

>
> Reviewed-by: Alex Shi <alexs@kernel.org>
>
>> +适度的内存开销允许在内存受限的设备上用真实的工作负载进行测试。
>>   
>> -基于软件标签的KASAN模式仅在Clang中受支持。
>> +基于硬件标签的KASAN或HW_TAGS KASAN，用CONFIG_KASAN_HW_TAGS启用，被
>> +用作现场内存错误检测器或作为安全缓解的模式。这种模式只在支持MTE（内存标签
>> +扩展）的arm64 CPU上工作，但它的内存和性能开销很低，因此可以在生产中使用。
>>   
>> -硬件KASAN模式（#3）依赖硬件来执行检查，但仍需要支持内存标签指令的编译器
>> -版本。GCC 10+和Clang 11+支持此模式。
>> +关于每种KASAN模式的内存和性能影响的细节，请参见相应的Kconfig选项的描述。
>>   
>> -两种软件KASAN模式都适用于SLUB和SLAB内存分配器，而基于硬件标签的KASAN目前
>> -仅支持SLUB。
>> +通用模式和基于软件标签的模式通常被称为软件模式。基于软件标签的模式和基于
>> +硬件标签的模式被称为基于标签的模式。
>>   
>> -目前x86_64、arm、arm64、xtensa、s390、riscv架构支持通用KASAN模式，仅
>> -arm64架构支持基于标签的KASAN模式。
>> +支持
>> +----
>> +
>> +体系架构
>> +~~~~~~~~
>> +
>> +在x86_64、arm、arm64、powerpc、riscv、s390和xtensa上支持通用KASAN，
>> +而基于标签的KASAN模式只在arm64上支持。
>> +
>> +编译器
>> +~~~~~~
>> +
>> +软件KASAN模式使用编译时工具在每个内存访问之前插入有效性检查，因此需要一个
>> +提供支持的编译器版本。基于硬件标签的模式依靠硬件来执行这些检查，但仍然需要
>> +一个支持内存标签指令的编译器版本。
>> +
>> +通用KASAN需要GCC 8.3.0版本或更高版本，或者内核支持的任何Clang版本。
>> +
>> +基于软件标签的KASAN需要GCC 11+或者内核支持的任何Clang版本。
>> +
>> +基于硬件标签的KASAN需要GCC 10+或Clang 12+。
>> +
>> +内存类型
>> +~~~~~~~~
>> +
>> +通用KASAN支持在所有的slab、page_alloc、vmap、vmalloc、堆栈和全局内存
>> +中查找错误。
>> +
>> +基于软件标签的KASAN支持slab、page_alloc、vmalloc和堆栈内存。
>> +
>> +基于硬件标签的KASAN支持slab、page_alloc和不可执行的vmalloc内存。
>> +
>> +对于slab，两种软件KASAN模式都支持SLUB和SLAB分配器，而基于硬件标签的
>> +KASAN只支持SLUB。
>>   
>>   用法
>>   ----
>> @@ -53,7 +84,7 @@ arm64架构支持基于标签的KASAN模式。
>>   
>>   对于软件模式，还可以在 ``CONFIG_KASAN_OUTLINE`` 和 ``CONFIG_KASAN_INLINE``
>>   之间进行选择。outline和inline是编译器插桩类型。前者产生较小的二进制文件，
>> -而后者快1.1-2倍。
>> +而后者快2倍。
>>   
>>   要将受影响的slab对象的alloc和free堆栈跟踪包含到报告中，请启用
>>   ``CONFIG_STACKTRACE`` 。要包括受影响物理页面的分配和释放堆栈跟踪的话，
>> @@ -172,21 +203,29 @@ KASAN受通用 ``panic_on_warn`` 命令行参数的影响。启用该功能后
>>   默认情况下，KASAN只为第一次无效内存访问打印错误报告。使用 ``kasan_multi_shot`` ，
>>   KASAN会针对每个无效访问打印报告。这有效地禁用了KASAN报告的 ``panic_on_warn`` 。
>>   
>> +另外，独立于 ``panic_on_warn`` , ``kasan.fault=`` 引导参数可以用来控制恐慌和报
>> +告行为:
>> +
>> +- ``kasan.fault=report`` 或 ``=panic`` 控制是只打印KASAN报告还是同时使内核恐慌
>> +  (默认: ``report`` )。即使启用了 ``kasan_multi_shot`` ，也会发生内核恐慌。
>> +
>>   基于硬件标签的KASAN模式（请参阅下面有关各种模式的部分）旨在在生产中用作安全缓解
>> -措施。因此，它支持允许禁用KASAN或控制其功能的引导参数。
>> +措施。因此，它支持允许禁用KASAN或控制其功能的附加引导参数。
>>   
>>   - ``kasan=off`` 或 ``=on`` 控制KASAN是否启用 (默认: ``on`` )。
>>   
>> -- ``kasan.mode=sync`` 或 ``=async`` 控制KASAN是否配置为同步或异步执行模式(默认:
>> -  ``sync`` )。同步模式：当标签检查错误发生时，立即检测到错误访问。异步模式：
>> -  延迟错误访问检测。当标签检查错误发生时，信息存储在硬件中（在arm64的
>> +- ``kasan.mode=sync`` 、 ``=async`` 或 ``=asymm`` 控制KASAN是否配置
>> +  为同步或异步执行模式(默认:``sync`` )。
>> +  同步模式：当标签检查错误发生时，立即检测到错误访问。
>> +  异步模式：延迟错误访问检测。当标签检查错误发生时，信息存储在硬件中（在arm64的
>>     TFSR_EL1寄存器中）。内核会定期检查硬件，并且仅在这些检查期间报告标签错误。
>> +  非对称模式：读取时同步检测不良访问，写入时异步检测。
>> +
>> +- ``kasan.vmalloc=off`` 或 ``=on`` 禁用或启用vmalloc分配的标记（默认：``on`` ）。
>>   
>>   - ``kasan.stacktrace=off`` 或 ``=on`` 禁用或启用alloc和free堆栈跟踪收集
>>     (默认: ``on`` )。
>>   
>> -- ``kasan.fault=report`` 或 ``=panic`` 控制是只打印KASAN报告还是同时使内核恐慌
>> -  (默认: ``report`` )。即使启用了 ``kasan_multi_shot`` ，也会发生内核恐慌。
>>   
>>   实施细则
>>   --------
>> @@ -244,7 +283,6 @@ KASAN会针对每个无效访问打印报告。这有效地禁用了KASAN报告
>>   基于软件标签的KASAN使用0xFF作为匹配所有指针标签（不检查通过带有0xFF指针标签
>>   的指针进行的访问）。值0xFE当前保留用于标记已释放的内存区域。
>>   
>> -基于软件标签的KASAN目前仅支持对Slab和page_alloc内存进行标记。
>>   
>>   基于硬件标签的KASAN模式
>>   ~~~~~~~~~~~~~~~~~~~~~~~
>> @@ -262,8 +300,6 @@ KASAN会针对每个无效访问打印报告。这有效地禁用了KASAN报告
>>   基于硬件标签的KASAN使用0xFF作为匹配所有指针标签（不检查通过带有0xFF指针标签的
>>   指针进行的访问）。值0xFE当前保留用于标记已释放的内存区域。
>>   
>> -基于硬件标签的KASAN目前仅支持对Slab和page_alloc内存进行标记。
>> -
>>   如果硬件不支持MTE（ARMv8.5之前），则不会启用基于硬件标签的KASAN。在这种情况下，
>>   所有KASAN引导参数都将被忽略。
>>   
>> @@ -275,6 +311,8 @@ KASAN会针对每个无效访问打印报告。这有效地禁用了KASAN报告
>>   影子内存
>>   --------
>>   
>> +本节的内容只适用于软件KASAN模式。
>> +
>>   内核将内存映射到地址空间的几个不同部分。内核虚拟地址的范围很大：没有足够的真实
>>   内存来支持内核可以访问的每个地址的真实影子区域。因此，KASAN只为地址空间的某些
>>   部分映射真实的影子。
>> @@ -297,7 +335,7 @@ CONFIG_KASAN_VMALLOC
>>   ~~~~~~~~~~~~~~~~~~~~
>>   
>>   使用 ``CONFIG_KASAN_VMALLOC`` ，KASAN可以以更大的内存使用为代价覆盖vmalloc
>> -空间。目前，这在x86、riscv、s390和powerpc上受支持。
>> +空间。目前，这在arm64、x86、riscv、s390和powerpc上受支持。
>>   
>>   这通过连接到vmalloc和vmap并动态分配真实的影子内存来支持映射。
>>   
>> @@ -349,10 +387,10 @@ KASAN连接到vmap基础架构以懒清理未使用的影子内存。
>>   ``kasan_disable_current()``/``kasan_enable_current()`` 部分注释这部分代码。
>>   这也会禁用通过函数调用发生的间接访问的报告。
>>   
>> -对于基于标签的KASAN模式（包括硬件模式），要禁用访问检查，请使用
>> -``kasan_reset_tag()`` 或 ``page_kasan_tag_reset()`` 。请注意，通过
>> -``page_kasan_tag_reset()`` 临时禁用访问检查需要通过 ``page_kasan_tag``
>> -/ ``page_kasan_tag_set`` 保存和恢复每页KASAN标签。
>> +对于基于标签的KASAN模式，要禁用访问检查，请使用 ``kasan_reset_tag()`` 或
>> +``page_kasan_tag_reset()`` 。请注意，通过 ``page_kasan_tag_reset()``
>> +临时禁用访问检查需要通过 ``page_kasan_tag`` / ``page_kasan_tag_set`` 保
>> +存和恢复每页KASAN标签。
>>   
>>   测试
>>   ~~~~
>> @@ -381,11 +419,10 @@ KASAN连接到vmap基础架构以懒清理未使用的影子内存。
>>   
>>   当由于缺少KASAN报告而导致测试失败时::
>>   
>> -        # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629
>> -        Expected kasan_data->report_expected == kasan_data->report_found, but
>> -        kasan_data->report_expected == 1
>> -        kasan_data->report_found == 0
>> -        not ok 28 - kmalloc_double_kzfree
>> +        # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:974
>> +        KASAN failure expected in "kfree_sensitive(ptr)", but none occurred
>> +        not ok 44 - kmalloc_double_kzfree
>> +
>>   
>>   最后打印所有KASAN测试的累积状态。成功::
>>   

[PATCH 3/8] Docs/zh_CN: Update the translation of sparse to 5.19-rc8

[Yanteng Si]

Update to commit179fd6ba3bac ("Documentation/sparse:
 add hints about __CHECKER__")

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 Documentation/translations/zh_CN/dev-tools/sparse.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/translations/zh_CN/dev-tools/sparse.rst b/Documentation/translations/zh_CN/dev-tools/sparse.rst
index 556282437aad..0664c634bc4f 100644
--- a/Documentation/translations/zh_CN/dev-tools/sparse.rst
+++ b/Documentation/translations/zh_CN/dev-tools/sparse.rst
@@ -106,3 +106,5 @@ __releases  - 指定的锁在函数进入时被持有，但在退出时不被持
 
 make 的可选变量 CHECKFLAGS 可以用来向 sparse 工具传递参数。编译系统会自
 动向 sparse 工具传递 -Wbitwise 参数。
+
+注意sparse定义了__CHECKER__预处理器符号。
\ No newline at end of file
-- 
2.31.1

Re: [PATCH 3/8] Docs/zh_CN: Update the translation of sparse to 5.19-rc8

[Alex Shi]

Reviewed-by: Alex Shi <alexs@kernel.org>

On 7/25/22 17:20, Yanteng Si wrote:
> Update to commit179fd6ba3bac ("Documentation/sparse:
>  add hints about __CHECKER__")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  Documentation/translations/zh_CN/dev-tools/sparse.rst | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/translations/zh_CN/dev-tools/sparse.rst b/Documentation/translations/zh_CN/dev-tools/sparse.rst
> index 556282437aad..0664c634bc4f 100644
> --- a/Documentation/translations/zh_CN/dev-tools/sparse.rst
> +++ b/Documentation/translations/zh_CN/dev-tools/sparse.rst
> @@ -106,3 +106,5 @@ __releases  - 指定的锁在函数进入时被持有，但在退出时不被持
>  
>  make 的可选变量 CHECKFLAGS 可以用来向 sparse 工具传递参数。编译系统会自
>  动向 sparse 工具传递 -Wbitwise 参数。
> +
> +注意sparse定义了__CHECKER__预处理器符号。
> \ No newline at end of file

[PATCH 4/8] Docs/zh_CN: Update the translation of testing-overview to 5.19-rc8

[Yanteng Si]

Update to commit 12379401c000 ("Documentation: dev-tools:
Add a section for static analysis tools")

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../zh_CN/dev-tools/testing-overview.rst      | 25 +++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
index b7a1d13da6c6..d6f2c65ed511 100644
--- a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
+++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
@@ -107,3 +107,28 @@ Documentation/dev-tools/kcov.rst 是能够构建在内核之中，用于在每
 之后你就能确保这些错误在测试过程中都不会发生了。
 
 一些工具与KUnit和kselftest集成，并且在检测到问题时会自动打断测试。
+
+静态分析工具
+============
+
+除了测试运行中的内核，我们还可以使用**静态分析**工具直接分析内核的源代
+码（**在编译时**）。内核中常用的工具允许人们检查整个源代码树或其中的特
+定文件。它们使得在开发过程中更容易发现和修复问题。
+
+ Sparse可以通过执行类型检查、锁检查、值范围检查来帮助测试内核，此外还
+ 可以在检查代码时报告各种错误和警告。关于如何使用它的细节，请参阅
+ Documentation/translations/zh_CN/dev-tools/sparse.rst。
+
+ Smatch扩展了Sparse，并提供了对编程逻辑错误的额外检查，如开关语句中
+ 缺少断点，错误检查中未使用的返回值，忘记在错误路径的返回中设置错误代
+ 码等。Smatch也有针对更严重问题的测试，如整数溢出、空指针解除引用和内
+ 存泄漏。见项目页面http://smatch.sourceforge.net/。
+
+ Coccinelle是我们可以使用的另一个静态分析器。Coccinelle经常被用来
+ 帮助源代码的重构和并行演化，但它也可以帮助避免常见代码模式中出现的某
+ 些错误。可用的测试类型包括API测试、内核迭代器的正确使用测试、自由操
+ 作的合理性检查、锁定行为的分析，以及已知的有助于保持内核使用一致性的
+ 进一步测试。详情请见Documentation/dev-tools/coccinelle.rst。
+
+ 不过要注意的是，静态分析工具存在**假阳性**的问题。在试图修复错误和警
+ 告之前，需要仔细评估它们。
-- 
2.31.1

Re: [PATCH 4/8] Docs/zh_CN: Update the translation of testing-overview to 5.19-rc8

[Alex Shi]

Reviewed-by: Alex Shi <alexs@kernel.org>

On 7/25/22 17:23, Yanteng Si wrote:
> Update to commit 12379401c000 ("Documentation: dev-tools:
> Add a section for static analysis tools")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  .../zh_CN/dev-tools/testing-overview.rst      | 25 +++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 
> diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
> index b7a1d13da6c6..d6f2c65ed511 100644
> --- a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
> +++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
> @@ -107,3 +107,28 @@ Documentation/dev-tools/kcov.rst 是能够构建在内核之中，用于在每
>  之后你就能确保这些错误在测试过程中都不会发生了。
>  
>  一些工具与KUnit和kselftest集成，并且在检测到问题时会自动打断测试。
> +
> +静态分析工具
> +============
> +
> +除了测试运行中的内核，我们还可以使用**静态分析**工具直接分析内核的源代
> +码（**在编译时**）。内核中常用的工具允许人们检查整个源代码树或其中的特
> +定文件。它们使得在开发过程中更容易发现和修复问题。
> +
> + Sparse可以通过执行类型检查、锁检查、值范围检查来帮助测试内核，此外还
> + 可以在检查代码时报告各种错误和警告。关于如何使用它的细节，请参阅
> + Documentation/translations/zh_CN/dev-tools/sparse.rst。
> +
> + Smatch扩展了Sparse，并提供了对编程逻辑错误的额外检查，如开关语句中
> + 缺少断点，错误检查中未使用的返回值，忘记在错误路径的返回中设置错误代
> + 码等。Smatch也有针对更严重问题的测试，如整数溢出、空指针解除引用和内
> + 存泄漏。见项目页面http://smatch.sourceforge.net/。
> +
> + Coccinelle是我们可以使用的另一个静态分析器。Coccinelle经常被用来
> + 帮助源代码的重构和并行演化，但它也可以帮助避免常见代码模式中出现的某
> + 些错误。可用的测试类型包括API测试、内核迭代器的正确使用测试、自由操
> + 作的合理性检查、锁定行为的分析，以及已知的有助于保持内核使用一致性的
> + 进一步测试。详情请见Documentation/dev-tools/coccinelle.rst。
> +
> + 不过要注意的是，静态分析工具存在**假阳性**的问题。在试图修复错误和警
> + 告之前，需要仔细评估它们。

[PATCH 5/8] Docs/zh_CN: Update the translation of usage to 5.19-rc8

[Yanteng Si]

Update to commit b57e39a743e4 ("Docs/admin-guide
/damon/sysfs: document 'LRU_DEPRIO' scheme action")

0bcba960b1fa ("Docs/admin-guide/damon/sysfs: document 'LRU_PRIO' scheme action")

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst
index cd41ada4fdad..aeae2ab65dd8 100644
--- a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst
+++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst
@@ -210,6 +210,8 @@ schemes/<N>/
  - ``pageout``: 为具有 ``MADV_PAGEOUT`` 的区域调用 ``madvise()`` 。
  - ``hugepage``: 为带有 ``MADV_HUGEPAGE`` 的区域调用 ``madvise()`` 。
  - ``nohugepage``: 为带有 ``MADV_NOHUGEPAGE`` 的区域调用 ``madvise()``。
+ - ``lru_prio``: 在其LRU列表上对区域进行优先排序。
+ - ``lru_deprio``: 对区域的LRU列表进行降低优先处理。
  - ``stat``: 什么都不做，只计算统计数据
 
 schemes/<N>/access_pattern/
-- 
2.31.1

Re: [PATCH 5/8] Docs/zh_CN: Update the translation of usage to 5.19-rc8

[Alex Shi]

Reviewed-by: Alex Shi <alexs@kernel.org>

On 7/25/22 17:24, Yanteng Si wrote:
> Update to commit b57e39a743e4 ("Docs/admin-guide
> /damon/sysfs: document 'LRU_DEPRIO' scheme action")
> 
> 0bcba960b1fa ("Docs/admin-guide/damon/sysfs: document 'LRU_PRIO' scheme action")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst
> index cd41ada4fdad..aeae2ab65dd8 100644
> --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst
> +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst
> @@ -210,6 +210,8 @@ schemes/<N>/
>   - ``pageout``: 为具有 ``MADV_PAGEOUT`` 的区域调用 ``madvise()`` 。
>   - ``hugepage``: 为带有 ``MADV_HUGEPAGE`` 的区域调用 ``madvise()`` 。
>   - ``nohugepage``: 为带有 ``MADV_NOHUGEPAGE`` 的区域调用 ``madvise()``。
> + - ``lru_prio``: 在其LRU列表上对区域进行优先排序。
> + - ``lru_deprio``: 对区域的LRU列表进行降低优先处理。
>   - ``stat``: 什么都不做，只计算统计数据
>  
>  schemes/<N>/access_pattern/

[PATCH 6/8] Docs/zh_CN: Update the translation of pci-iov-howto to 5.19-rc8

[Yanteng Si]

Update to commit 4f23bd5d09af ("PCI/doc: Convert
examples to generic power management")

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 Documentation/translations/zh_CN/PCI/pci-iov-howto.rst | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/Documentation/translations/zh_CN/PCI/pci-iov-howto.rst b/Documentation/translations/zh_CN/PCI/pci-iov-howto.rst
index fbc83dfdcead..fb023ea1374d 100644
--- a/Documentation/translations/zh_CN/PCI/pci-iov-howto.rst
+++ b/Documentation/translations/zh_CN/PCI/pci-iov-howto.rst
@@ -123,14 +123,14 @@ nr_virtfn'是要启用的VF的编号。
 		...
 	}
 
-	static int dev_suspend(struct pci_dev *dev, pm_message_t state)
+	static int dev_suspend(struct device *dev)
 	{
 		...
 
 		return 0;
 	}
 
-	static int dev_resume(struct pci_dev *dev)
+	static int dev_resume(struct device *dev)
 	{
 		...
 
@@ -163,8 +163,7 @@ nr_virtfn'是要启用的VF的编号。
 		.id_table =	dev_id_table,
 		.probe =	dev_probe,
 		.remove =	dev_remove,
-		.suspend =	dev_suspend,
-		.resume =	dev_resume,
+		.driver.pm =    &dev_pm_ops
 		.shutdown =	dev_shutdown,
 		.sriov_configure = dev_sriov_configure,
 	};
-- 
2.31.1

Re: [PATCH 6/8] Docs/zh_CN: Update the translation of pci-iov-howto to 5.19-rc8

[Alex Shi]

Reviewed-by: Alex Shi <alexs@kernel.org>

On 7/25/22 17:24, Yanteng Si wrote:
> Update to commit 4f23bd5d09af ("PCI/doc: Convert
> examples to generic power management")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  Documentation/translations/zh_CN/PCI/pci-iov-howto.rst | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/translations/zh_CN/PCI/pci-iov-howto.rst b/Documentation/translations/zh_CN/PCI/pci-iov-howto.rst
> index fbc83dfdcead..fb023ea1374d 100644
> --- a/Documentation/translations/zh_CN/PCI/pci-iov-howto.rst
> +++ b/Documentation/translations/zh_CN/PCI/pci-iov-howto.rst
> @@ -123,14 +123,14 @@ nr_virtfn'是要启用的VF的编号。
>  		...
>  	}
>  
> -	static int dev_suspend(struct pci_dev *dev, pm_message_t state)
> +	static int dev_suspend(struct device *dev)
>  	{
>  		...
>  
>  		return 0;
>  	}
>  
> -	static int dev_resume(struct pci_dev *dev)
> +	static int dev_resume(struct device *dev)
>  	{
>  		...
>  
> @@ -163,8 +163,7 @@ nr_virtfn'是要启用的VF的编号。
>  		.id_table =	dev_id_table,
>  		.probe =	dev_probe,
>  		.remove =	dev_remove,
> -		.suspend =	dev_suspend,
> -		.resume =	dev_resume,
> +		.driver.pm =    &dev_pm_ops
>  		.shutdown =	dev_shutdown,
>  		.sriov_configure = dev_sriov_configure,
>  	};

[PATCH 7/8] Docs/zh_CN: Update the translation of pci to 5.19-rc8

[Yanteng Si]

Update to commit f21949c14968 ("PCI/doc:Update
obsolete pci_set_dma_mask() references")

05b0ebd06ae6 ("PCI/doc: cleanup references to
the legacy PCI DMA API")

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 Documentation/translations/zh_CN/PCI/pci.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/translations/zh_CN/PCI/pci.rst b/Documentation/translations/zh_CN/PCI/pci.rst
index 520707787256..83c2a41d38d3 100644
--- a/Documentation/translations/zh_CN/PCI/pci.rst
+++ b/Documentation/translations/zh_CN/PCI/pci.rst
@@ -255,13 +255,13 @@ pci_set_master()将通过设置PCI_COMMAND寄存器中的总线主控位来启
 
 虽然所有的驱动程序都应该明确指出PCI总线主控的DMA功能（如32位或64位），但对于流式
 数据来说，具有超过32位总线主站功能的设备需要驱动程序通过调用带有适当参数的
-``pci_set_dma_mask()`` 来“注册”这种功能。一般来说，在系统RAM高于4G物理地址的情
+``dma_set_mask()`` 来“注册”这种功能。一般来说，在系统RAM高于4G物理地址的情
 况下，这允许更有效的DMA。
 
-所有PCI-X和PCIe兼容设备的驱动程序必须调用 ``pci_set_dma_mask()`` ，因为它们
+所有PCI-X和PCIe兼容设备的驱动程序必须调用 ``dma_set_mask()`` ，因为它们
 是64位DMA设备。
 
-同样，如果设备可以通过调用 ``pci_set_consistent_dma_mask()`` 直接寻址到
+同样，如果设备可以通过调用 ``dma_set_coherent_mask()`` 直接寻址到
 4G物理地址以上的系统RAM中的“一致性内存”，那么驱动程序也必须“注册”这种功能。同
 样，这包括所有PCI-X和PCIe兼容设备的驱动程序。许多64位“PCI”设备（在PCI-X之前）
 和一些PCI-X设备对有效载荷（“流式”）数据具有64位DMA功能，但对控制（“一致性”）数
-- 
2.31.1

Re: [PATCH 7/8] Docs/zh_CN: Update the translation of pci to 5.19-rc8

[Wu XiangCheng]

On Mon, Jul 25, 2022 at 05:24:35PM +0800, Yanteng Si wrote:
> Update to commit f21949c14968 ("PCI/doc:Update
> obsolete pci_set_dma_mask() references")
> 
> 05b0ebd06ae6 ("PCI/doc: cleanup references to
> the legacy PCI DMA API")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>

Reviewed-by: Wu XiangCheng <bobwxc@email.cn>

Thanks,
	Wu

> ---
>  Documentation/translations/zh_CN/PCI/pci.rst | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/translations/zh_CN/PCI/pci.rst b/Documentation/translations/zh_CN/PCI/pci.rst
> index 520707787256..83c2a41d38d3 100644
> --- a/Documentation/translations/zh_CN/PCI/pci.rst
> +++ b/Documentation/translations/zh_CN/PCI/pci.rst
> @@ -255,13 +255,13 @@ pci_set_master()将通过设置PCI_COMMAND寄存器中的总线主控位来启
>  
>  虽然所有的驱动程序都应该明确指出PCI总线主控的DMA功能（如32位或64位），但对于流式
>  数据来说，具有超过32位总线主站功能的设备需要驱动程序通过调用带有适当参数的
> -``pci_set_dma_mask()`` 来“注册”这种功能。一般来说，在系统RAM高于4G物理地址的情
> +``dma_set_mask()`` 来“注册”这种功能。一般来说，在系统RAM高于4G物理地址的情
>  况下，这允许更有效的DMA。
>  
> -所有PCI-X和PCIe兼容设备的驱动程序必须调用 ``pci_set_dma_mask()`` ，因为它们
> +所有PCI-X和PCIe兼容设备的驱动程序必须调用 ``dma_set_mask()`` ，因为它们
>  是64位DMA设备。
>  
> -同样，如果设备可以通过调用 ``pci_set_consistent_dma_mask()`` 直接寻址到
> +同样，如果设备可以通过调用 ``dma_set_coherent_mask()`` 直接寻址到
>  4G物理地址以上的系统RAM中的“一致性内存”，那么驱动程序也必须“注册”这种功能。同
>  样，这包括所有PCI-X和PCIe兼容设备的驱动程序。许多64位“PCI”设备（在PCI-X之前）
>  和一些PCI-X设备对有效载荷（“流式”）数据具有64位DMA功能，但对控制（“一致性”）数
> -- 
> 2.31.1

Re: [PATCH 7/8] Docs/zh_CN: Update the translation of pci to 5.19-rc8

[Alex Shi]

Reviewed-by: Alex Shi <alexs@kernel.org>

On 7/25/22 17:24, Yanteng Si wrote:
> Update to commit f21949c14968 ("PCI/doc:Update
> obsolete pci_set_dma_mask() references")
> 
> 05b0ebd06ae6 ("PCI/doc: cleanup references to
> the legacy PCI DMA API")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  Documentation/translations/zh_CN/PCI/pci.rst | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/translations/zh_CN/PCI/pci.rst b/Documentation/translations/zh_CN/PCI/pci.rst
> index 520707787256..83c2a41d38d3 100644
> --- a/Documentation/translations/zh_CN/PCI/pci.rst
> +++ b/Documentation/translations/zh_CN/PCI/pci.rst
> @@ -255,13 +255,13 @@ pci_set_master()将通过设置PCI_COMMAND寄存器中的总线主控位来启
>  
>  虽然所有的驱动程序都应该明确指出PCI总线主控的DMA功能（如32位或64位），但对于流式
>  数据来说，具有超过32位总线主站功能的设备需要驱动程序通过调用带有适当参数的
> -``pci_set_dma_mask()`` 来“注册”这种功能。一般来说，在系统RAM高于4G物理地址的情
> +``dma_set_mask()`` 来“注册”这种功能。一般来说，在系统RAM高于4G物理地址的情
>  况下，这允许更有效的DMA。
>  
> -所有PCI-X和PCIe兼容设备的驱动程序必须调用 ``pci_set_dma_mask()`` ，因为它们
> +所有PCI-X和PCIe兼容设备的驱动程序必须调用 ``dma_set_mask()`` ，因为它们
>  是64位DMA设备。
>  
> -同样，如果设备可以通过调用 ``pci_set_consistent_dma_mask()`` 直接寻址到
> +同样，如果设备可以通过调用 ``dma_set_coherent_mask()`` 直接寻址到
>  4G物理地址以上的系统RAM中的“一致性内存”，那么驱动程序也必须“注册”这种功能。同
>  样，这包括所有PCI-X和PCIe兼容设备的驱动程序。许多64位“PCI”设备（在PCI-X之前）
>  和一些PCI-X设备对有效载荷（“流式”）数据具有64位DMA功能，但对控制（“一致性”）数

[PATCH 8/8] Docs/zh_CN: Update the translation of sched-stats to 5.19-rc8

[Yanteng Si]

Update to commit 6c757e9f55f0 ("docs/scheduler:
fix unit error")

ddb21d27a6a5 ("docs/scheduler: Change unit of
cpu_time and rq_time to nanoseconds")

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../translations/zh_CN/scheduler/sched-stats.rst          | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/translations/zh_CN/scheduler/sched-stats.rst b/Documentation/translations/zh_CN/scheduler/sched-stats.rst
index 1c68c3d1c283..c5e0be663837 100644
--- a/Documentation/translations/zh_CN/scheduler/sched-stats.rst
+++ b/Documentation/translations/zh_CN/scheduler/sched-stats.rst
@@ -57,8 +57,8 @@ cpu<N> 1 2 3 4 5 6 7 8 9
 
 接下来的三个统计数据描述了调度延迟：
 
-     7) 本处理器运行任务的总时间，单位是jiffies
-     8) 本处理器任务等待运行的时间，单位是jiffies
+     7) 本处理器运行任务的总时间，单位是纳秒
+     8) 本处理器任务等待运行的时间，单位是纳秒
      9) 本CPU运行了#个时间片
 
 域统计数据
@@ -146,8 +146,8 @@ domain<N> <cpumask> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
 schedstats还添加了一个新的/proc/<pid>/schedstat文件，来提供一些进程级的
 相同信息。这个文件中，有三个字段与该进程相关：
 
-     1) 在CPU上运行花费的时间
-     2) 在运行队列上等待的时间
+     1) 在CPU上运行花费的时间(单位是纳秒)
+     2) 在运行队列上等待的时间(单位是纳秒)
      3) 在CPU上运行了#个时间片
 
 可以很容易地编写一个程序，利用这些额外的字段来报告一个特定的进程或一组进程在
-- 
2.31.1

Re: [PATCH 8/8] Docs/zh_CN: Update the translation of sched-stats to 5.19-rc8

[Wu XiangCheng]

On Mon, Jul 25, 2022 at 05:24:47PM +0800, Yanteng Si wrote:
> Update to commit 6c757e9f55f0 ("docs/scheduler:
> fix unit error")
> 
> ddb21d27a6a5 ("docs/scheduler: Change unit of
> cpu_time and rq_time to nanoseconds")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>

Reviewed-by: Wu XiangCheng <bobwxc@email.cn>

Thanks,
	Wu

> ---
>  .../translations/zh_CN/scheduler/sched-stats.rst          | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/translations/zh_CN/scheduler/sched-stats.rst b/Documentation/translations/zh_CN/scheduler/sched-stats.rst
> index 1c68c3d1c283..c5e0be663837 100644
> --- a/Documentation/translations/zh_CN/scheduler/sched-stats.rst
> +++ b/Documentation/translations/zh_CN/scheduler/sched-stats.rst
> @@ -57,8 +57,8 @@ cpu<N> 1 2 3 4 5 6 7 8 9
>  
>  接下来的三个统计数据描述了调度延迟：
>  
> -     7) 本处理器运行任务的总时间，单位是jiffies
> -     8) 本处理器任务等待运行的时间，单位是jiffies
> +     7) 本处理器运行任务的总时间，单位是纳秒
> +     8) 本处理器任务等待运行的时间，单位是纳秒
>       9) 本CPU运行了#个时间片
>  
>  域统计数据
> @@ -146,8 +146,8 @@ domain<N> <cpumask> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
>  schedstats还添加了一个新的/proc/<pid>/schedstat文件，来提供一些进程级的
>  相同信息。这个文件中，有三个字段与该进程相关：
>  
> -     1) 在CPU上运行花费的时间
> -     2) 在运行队列上等待的时间
> +     1) 在CPU上运行花费的时间(单位是纳秒)
> +     2) 在运行队列上等待的时间(单位是纳秒)
>       3) 在CPU上运行了#个时间片
>  
>  可以很容易地编写一个程序，利用这些额外的字段来报告一个特定的进程或一组进程在
> -- 
> 2.31.1

Re: [PATCH 8/8] Docs/zh_CN: Update the translation of sched-stats to 5.19-rc8

[Alex Shi]

Reviewed-by: Alex Shi <alexs@kernel.org>

On 7/25/22 17:24, Yanteng Si wrote:
> Update to commit 6c757e9f55f0 ("docs/scheduler:
> fix unit error")
>
> ddb21d27a6a5 ("docs/scheduler: Change unit of
> cpu_time and rq_time to nanoseconds")
>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  .../translations/zh_CN/scheduler/sched-stats.rst          | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/translations/zh_CN/scheduler/sched-stats.rst b/Documentation/translations/zh_CN/scheduler/sched-stats.rst
> index 1c68c3d1c283..c5e0be663837 100644
> --- a/Documentation/translations/zh_CN/scheduler/sched-stats.rst
> +++ b/Documentation/translations/zh_CN/scheduler/sched-stats.rst
> @@ -57,8 +57,8 @@ cpu<N> 1 2 3 4 5 6 7 8 9
>  
>  接下来的三个统计数据描述了调度延迟：
>  
> -     7) 本处理器运行任务的总时间，单位是jiffies
> -     8) 本处理器任务等待运行的时间，单位是jiffies
> +     7) 本处理器运行任务的总时间，单位是纳秒
> +     8) 本处理器任务等待运行的时间，单位是纳秒
>       9) 本CPU运行了#个时间片
>  
>  域统计数据
> @@ -146,8 +146,8 @@ domain<N> <cpumask> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
>  schedstats还添加了一个新的/proc/<pid>/schedstat文件，来提供一些进程级的
>  相同信息。这个文件中，有三个字段与该进程相关：
>  
> -     1) 在CPU上运行花费的时间
> -     2) 在运行队列上等待的时间
> +     1) 在CPU上运行花费的时间(单位是纳秒)
> +     2) 在运行队列上等待的时间(单位是纳秒)
>       3) 在CPU上运行了#个时间片
>  
>  可以很容易地编写一个程序，利用这些额外的字段来报告一个特定的进程或一组进程在