[PATCH v1 00/13] docs/zh_CN: Update the translation to 6.1-rc8

[PATCH v1 00/13] docs/zh_CN: Update the translation to 6.1-rc8

[Yanteng Si]

v1:
The following files were updated to 6.1-rc8:
accounting
admin-guide/mm
core-api
dev-tools
mm
PCI
power

Yanteng Si (13):
  docs/zh_CN: Update the translation of delay-accounting to 6.1-rc8
  docs/zh_CN: Update the translation of kernel-api to 6.1-rc8
  docs/zh_CN: Update the translation of mm-api to 6.1-rc8
  docs/zh_CN: Update the translation of highmem to 6.1-rc8
  docs/zh_CN: Update the translation of page_owner to 6.1-rc8
  docs/zh_CN: Update the translation of kasan to 6.1-rc8
  docs/zh_CN: Update the translation of testing-overview to 6.1-rc8
  docs/zh_CN: Update the translation of reclaim to 6.1-rc8
  docs/zh_CN: Update the translation of start to 6.1-rc8
  docs/zh_CN: Update the translation of usage to 6.1-rc8
  docs/zh_CN: Update the translation of ksm to 6.1-rc8
  docs/zh_CN: Update the translation of msi-howto to 6.1-rc8
  docs/zh_CN: Update the translation of energy-model to 6.1-rc8

 .../translations/zh_CN/PCI/msi-howto.rst      | 11 +++
 .../zh_CN/accounting/delay-accounting.rst     |  7 +-
 .../zh_CN/admin-guide/mm/damon/reclaim.rst    |  4 -
 .../zh_CN/admin-guide/mm/damon/start.rst      | 12 +--
 .../zh_CN/admin-guide/mm/damon/usage.rst      | 68 +++++++++++-----
 .../translations/zh_CN/admin-guide/mm/ksm.rst | 50 ++++++++++++
 .../zh_CN/core-api/kernel-api.rst             | 10 ++-
 .../translations/zh_CN/core-api/mm-api.rst    |  2 +-
 .../translations/zh_CN/dev-tools/kasan.rst    | 77 +++++++++++--------
 .../zh_CN/dev-tools/testing-overview.rst      | 27 +++++++
 .../translations/zh_CN/mm/highmem.rst         | 20 ++++-
 .../translations/zh_CN/mm/page_owner.rst      | 17 +---
 .../translations/zh_CN/power/energy-model.rst | 36 +++++++--
 13 files changed, 246 insertions(+), 95 deletions(-)

-- 
2.31.1

[PATCH v1 01/13] docs/zh_CN: Update the translation of delay-accounting to 6.1-rc8

[Yanteng Si]

Update to commit f347c9d2697f ("filemap: make the accounting
of thrashing more consistent").

Commit 662ce1dc9caf ("delayacct: track delays from write-protect copy").

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

diff --git a/Documentation/translations/zh_CN/accounting/delay-accounting.rst b/Documentation/translations/zh_CN/accounting/delay-accounting.rst
index f1849411018e..71a3c1f2b07a 100644
--- a/Documentation/translations/zh_CN/accounting/delay-accounting.rst
+++ b/Documentation/translations/zh_CN/accounting/delay-accounting.rst
@@ -17,8 +17,9 @@ a) 等待一个CPU（任务为可运行）
 b) 完成由该任务发起的块I/O同步请求
 c) 页面交换
 d) 内存回收
-e) 页缓存抖动
+e) 抖动
 f) 直接规整
+g) 写保护复制
 
 并将这些统计信息通过taskstats接口提供给用户空间。
 
@@ -42,7 +43,7 @@ f) 直接规整
      include/uapi/linux/taskstats.h
 
 其描述了延时计数相关字段。系统通常以计数器形式返回 CPU、同步块 I/O、交换、内存
-回收、页缓存抖动、直接规整等的累积延时。
+回收、页缓存抖动、直接规整、写保护复制等的累积延时。
 
 取任务某计数器两个连续读数的差值，将得到任务在该时间间隔内等待对应资源的总延时。
 
@@ -100,6 +101,8 @@ getdelays命令的一般格式::
 	                    0              0              0ms
 	COMPACT         count    delay total  delay average
 	                    0              0              0ms
+    WPCOPY          count    delay total  delay average
+	                    0              0              0ms
 
 获取pid为1的IO计数，它只和-p一起使用::
 	# ./getdelays -i -p 1
-- 
2.31.1

[PATCH v1 02/13] docs/zh_CN: Update the translation of kernel-api to 6.1-rc8

[Yanteng Si]

Update to commit d28a1de5d112 ("math64: favor kernel-doc
from header files").

Commit 03699f271de1 ("string: Rewrite and add more kern-doc
for the str*() functions").
Commit 31970608a6d3 ("overflow: Fix kern-doc markup for
functions")

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../translations/zh_CN/core-api/kernel-api.rst         | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/translations/zh_CN/core-api/kernel-api.rst b/Documentation/translations/zh_CN/core-api/kernel-api.rst
index c22662679065..a4b373c48c0c 100644
--- a/Documentation/translations/zh_CN/core-api/kernel-api.rst
+++ b/Documentation/translations/zh_CN/core-api/kernel-api.rst
@@ -48,6 +48,8 @@ lib/string_helpers.c
 
 该API在以下内核代码中:
 
+include/linux/fortify-string.h
+
 lib/string.c
 
 include/linux/string.h
@@ -119,6 +121,12 @@ include/linux/textsearch.h
 Linux中的CRC和数学函数
 ======================
 
+算术溢出检查
+------------
+
+该API在以下内核代码中:
+
+include/linux/overflow.h
 
 CRC函数
 -------
@@ -166,8 +174,6 @@ include/asm-generic/div64.h
 
 include/linux/math64.h
 
-lib/math/div64.c
-
 lib/math/gcd.c
 
 UUID/GUID
-- 
2.31.1

[PATCH v1 03/13] docs/zh_CN: Update the translation of mm-api to 6.1-rc8

[Yanteng Si]

Update to commit def76fd549c5 ("mm/page_alloc: remove
obsolete gfpflags_normal_context()").

Commit 7343f2b0db49 ("headers/deps: mm: align
MANITAINERS and Docs with new gfp.h structure")

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 Documentation/translations/zh_CN/core-api/mm-api.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/translations/zh_CN/core-api/mm-api.rst b/Documentation/translations/zh_CN/core-api/mm-api.rst
index a732b0eebf16..113359bdb7be 100644
--- a/Documentation/translations/zh_CN/core-api/mm-api.rst
+++ b/Documentation/translations/zh_CN/core-api/mm-api.rst
@@ -37,7 +37,7 @@ mm/gup.c
 
 该API在以下内核代码中:
 
-include/linux/gfp.h
+include/linux/gfp_types.h
 
 Slab缓存
 ========
-- 
2.31.1

[PATCH v1 04/13] docs/zh_CN: Update the translation of highmem to 6.1-rc8

[Yanteng Si]

Update to commit a9e9c93966af ("Documentation/mm: add
details about kmap_local_page() and preemption").

Commit 84b86f6054c4 ("Documentation/mm: rrefer
kmap_local_page() and avoid kmap()").
Commit 6b3afe2eeec2 ("Documentation/mm: avoid
invalid use of addresses from kmap_local_page()").
Commit 516ea046ec55 ("Documentation/mm: don't kmap*()
pages which can't come from HIGHMEM").

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../translations/zh_CN/mm/highmem.rst         | 20 ++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/Documentation/translations/zh_CN/mm/highmem.rst b/Documentation/translations/zh_CN/mm/highmem.rst
index f74800a6d9a7..2c0ee0cbf5c4 100644
--- a/Documentation/translations/zh_CN/mm/highmem.rst
+++ b/Documentation/translations/zh_CN/mm/highmem.rst
@@ -57,15 +57,29 @@
 
   在可行的情况下，这个函数应该比其他所有的函数优先使用。
 
-  这些映射是线程本地和CPU本地的，这意味着映射只能从这个线程中访问，并且当映射处于活动状
-  态时，该线程与CPU绑定。即使线程被抢占了（因为抢占永远不会被函数禁用），CPU也不能通过
-  CPU-hotplug从系统中拔出，直到映射被处理掉。
+  这些映射是线程本地和CPU本地的，这意味着映射只能从这个线程中访问，并且当映射处于活跃状
+  态时，线程被绑定到CPU上。尽管这个函数从来没有禁用过抢占，但在映射被处理之前，CPU不能
+  通过CPU-hotplug从系统中拔出。
 
   在本地的kmap区域中采取pagefaults是有效的，除非获取本地映射的上下文由于其他原因不允许
   这样做。
 
+  如前所述，缺页异常和抢占从未被禁用。没有必要禁用抢占，因为当上下文切换到一个不同的任务
+  时，离开的任务的映射被保存，而进入的任务的映射被恢复。
+
   kmap_local_page()总是返回一个有效的虚拟地址，并且假定kunmap_local()不会失败。
 
+  在CONFIG_HIGHMEM=n的内核中，对于低内存页，它返回直接映射的虚拟地址。只有真正的高内
+  存页面才会被临时映射。因此，用户可以为那些已知不是来自ZONE_HIGHMEM的页面调用普通的
+  page_address()。然而，使用kmap_local_page() / kunmap_local()总是安全的。
+
+  虽然它比kmap()快得多，但在高内存的情况下，它对指针的有效性有限制。与kmap()映射相反，
+  本地映射只在调用者的上下文中有效，不能传递给其他上下文。这意味着用户必须绝对保证返回
+  地址的使用只限于映射它的线程。
+
+  大多数代码可以被设计成使用线程本地映射。因此，用户在设计他们的代码时，应该尽量避免使用
+  kmap()，将页面映射到将被使用的同一线程中，并优先使用kmap_local_page()。
+
   嵌套kmap_local_page()和kmap_atomic()映射在一定程度上是允许的（最多到KMAP_TYPE_NR），
   但是它们的调用必须严格排序，因为映射的实现是基于堆栈的。关于如何管理嵌套映射的细节，
   请参见kmap_local_page() kdocs（包含在 "函数 "部分）。
-- 
2.31.1

[PATCH v1 05/13] docs/zh_CN: Update the translation of page_owner to 6.1-rc8

[Yanteng Si]

Update to commit 0719fdba5483 ("Documentation/mm/page_owner.rst:
delete frequently changing experimental data").

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../translations/zh_CN/mm/page_owner.rst        | 17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/Documentation/translations/zh_CN/mm/page_owner.rst b/Documentation/translations/zh_CN/mm/page_owner.rst
index 21a6a0837d42..dba511fafef2 100644
--- a/Documentation/translations/zh_CN/mm/page_owner.rst
+++ b/Documentation/translations/zh_CN/mm/page_owner.rst
@@ -34,20 +34,9 @@ page owner在默认情况下是禁用的。所以，如果你想使用它，你
 一样进行。这两个不可能的分支应该不会影响到分配的性能，特别是在静态键跳转标签修补
 功能可用的情况下。以下是由于这个功能而导致的内核代码大小的变化。
 
-- 没有page owner::
-
-   text    data     bss     dec     hex filename
-   48392   2333     644   51369    c8a9 mm/page_alloc.o
-
-- 有page owner::
-
-   text    data     bss     dec     hex filename
-   48800   2445     644   51889    cab1 mm/page_alloc.o
-   6662     108      29    6799    1a8f mm/page_owner.o
-   1025       8       8    1041     411 mm/page_ext.o
-
-虽然总共增加了8KB的代码，但page_alloc.o增加了520字节，其中不到一半是在hotpath
-中。构建带有page owner的内核，并在需要时打开它，将是调试内核内存问题的最佳选择。
+尽管启用page owner会使内核的大小增加几千字节，但这些代码大部分都在页面分配器和
+热路径之外。构建带有page owner的内核，并在需要时打开它，将是调试内核内存问题的
+最佳选择。
 
 有一个问题是由实现细节引起的。页所有者将信息存储到struct page扩展的内存中。这
 个内存的初始化时间比稀疏内存系统中的页面分配器启动的时间要晚一些，所以，在初始化
-- 
2.31.1

[PATCH v1 06/13] docs/zh_CN: Update the translation of kasan to 6.1-rc8

[Yanteng Si]

Update to commit cd36d84d2571 ("kasan: allow sampling
page_alloc allocations for HW_TAGS")

Commit 80b92bfe3bb7 ("kasan: dynamically allocate
stack ring entries")
Commit 7ebfce331251 ("kasan: support kasan.stacktrace
for SW_TAGS")
Commit ca89f2a2e66d ("kasan: move boot parameters
section in documentation")

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

diff --git a/Documentation/translations/zh_CN/dev-tools/kasan.rst b/Documentation/translations/zh_CN/dev-tools/kasan.rst
index fe76cbe77ad6..c645b1b6cc53 100644
--- a/Documentation/translations/zh_CN/dev-tools/kasan.rst
+++ b/Documentation/translations/zh_CN/dev-tools/kasan.rst
@@ -90,6 +90,50 @@ KASAN只支持SLUB。
 ``CONFIG_STACKTRACE`` 。要包括受影响物理页面的分配和释放堆栈跟踪的话，
 请启用 ``CONFIG_PAGE_OWNER`` 并使用 ``page_owner=on`` 进行引导。
 
+启动参数
+~~~~~~~~
+
+KASAN受到通用 ``panic_on_warn`` 命令行参数的影响。当它被启用时，KASAN
+在打印出错误报告后会使内核恐慌。
+
+默认情况下，KASAN只对第一个无效的内存访问打印错误报告。使用
+``kasan_multi_shot``，KASAN对每一个无效的访问都打印一份报告。这有效地
+禁用了KASAN报告的 ``panic_on_warn``。
+
+另外，独立于 ``panic_on_warn`` 、 ``kasan.fault=`` boot参数可以用
+来控制恐慌和报告行为。
+
+- ``kasan.fault=report`` 或 ``=panic`` 控制是否只打印KASAN报告或
+  同时使内核恐慌（默认： ``报告`` ）。即使 ``kasan_multi_shot`` 被
+  启用，恐慌也会发生。
+
+基于软件和硬件标签的KASAN模式（见下面关于各种模式的部分）支持改变堆栈跟
+踪收集行为：
+
+- ``kasan.stacktrace=off`` 或 ``=on`` 禁用或启用分配和释放堆栈痕
+  迹的收集（默认： ``on`` ）。
+
+- ``kasan.stack_ring_size=<number of entries>`` 指定堆栈环的条
+  目数（默认： ``32768`` ）。
+
+基于硬件标签的KASAN模式是为了在生产中作为一种安全缓解措施使用。因此，它
+支持额外的启动参数，允许完全禁用KASAN或控制其功能。
+
+- ``kasan=off`` 或 ``=on`` 控制KASAN是否被启用（默认： ``on`` ）。
+
+- ``kasan.mode=sync``, ``=async`` or ``=asymm`` 控制KASAN是否
+  被配置为同步、异步或非对称的执行模式（默认： ``同步`` ）。
+  同步模式：当标签检查异常发生时，会立即检测到不良访问。
+  异步模式：不良访问的检测是延迟的。当标签检查异常发生时，信息被存储在硬
+  件中（对于arm64来说是在TFSR_EL1寄存器中）。内核周期性地检查硬件，并\
+  且只在这些检查中报告标签异常。
+  非对称模式：读取时同步检测不良访问，写入时异步检测。
+
+- ``kasan.vmalloc=off`` or ``=on`` 禁用或启用vmalloc分配的标记（默认： ``on`` ）。
+
+- ``kasan.page_alloc.sample=<sampling frequency>`` 使得KASAN
+  只对每N次page_alloc分配进行标记，其中N是参数的值（默认值： ``1`` ）。
+
 错误报告
 ~~~~~~~~
 
@@ -194,39 +238,6 @@ slab对象的描述以及关于访问的内存页的信息。
 通用KASAN还报告两个辅助调用堆栈跟踪。这些堆栈跟踪指向代码中与对象交互但不直接
 出现在错误访问堆栈跟踪中的位置。目前，这包括 call_rcu() 和排队的工作队列。
 
-启动参数
-~~~~~~~~
-
-KASAN受通用 ``panic_on_warn`` 命令行参数的影响。启用该功能后，KASAN在打印错误
-报告后会引起内核恐慌。
-
-默认情况下，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=off`` 或 ``=on`` 控制KASAN是否启用 (默认: ``on`` )。
-
-- ``kasan.mode=sync`` 、 ``=async`` 或 ``=asymm`` 控制KASAN是否配置
-  为同步或异步执行模式(默认:``sync`` )。
-  同步模式：当标签检查错误发生时，立即检测到错误访问。
-  异步模式：延迟错误访问检测。当标签检查错误发生时，信息存储在硬件中（在arm64的
-  TFSR_EL1寄存器中）。内核会定期检查硬件，并且仅在这些检查期间报告标签错误。
-  非对称模式：读取时同步检测不良访问，写入时异步检测。
-
-- ``kasan.vmalloc=off`` 或 ``=on`` 禁用或启用vmalloc分配的标记（默认：``on`` ）。
-
-- ``kasan.stacktrace=off`` 或 ``=on`` 禁用或启用alloc和free堆栈跟踪收集
-  (默认: ``on`` )。
-
-
 实施细则
 --------
 
-- 
2.31.1

[PATCH v1 07/13] docs/zh_CN: Update the translation of testing-overview to 6.1-rc8

[Yanteng Si]

Update to commit a32d5c0fc12b ("Documentation: dev-tools:
Enhance static analysis section with discussion")

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

diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
index d6f2c65ed511..d53a326de93a 100644
--- a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
+++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
@@ -132,3 +132,30 @@ Documentation/dev-tools/kcov.rst 是能够构建在内核之中，用于在每
 
  不过要注意的是，静态分析工具存在**假阳性**的问题。在试图修复错误和警
  告之前，需要仔细评估它们。
+
+何时使用Sparse和Smatch
+----------------------
+
+Sparse做类型检查，例如验证注释的变量不会导致无符号的错误，检测
+``__user`` 指针使用不当的地方，以及分析符号初始化器的兼容性。
+
+Smatch进行流程分析，如果允许建立函数数据库，它还会进行跨函数分析。
+Smatch试图回答一些问题，比如这个缓冲区是在哪里分配的？它有多大？这
+个索引可以由用户控制吗？这个变量比那个变量大吗？
+
+一般来说，在Smatch中写检查比在Sparse中写检查要容易。尽管如此，
+Sparse和Smatch的检查还是有一些重叠的地方。
+
+Smatch和Coccinelle的强项
+------------------------
+
+Coccinelle可能是最容易写检查的。它在预处理器之前工作，所以用Coccinelle
+检查宏中的错误更容易。Coccinelle还能为你创建补丁，这是其他工具无法做到的。
+
+例如，用Coccinelle你可以从kmalloc(x * size, GFP_KERNEL)到
+``kmalloc_array(x, size, GFP_KERNEL)`` 进行大规模转换，这真的很有用。
+如果你只是创建一个Smatch警告，并试图把转换的工作推给维护者，他们会很恼火。
+你将不得不为每个警告争论是否真的可以溢出。
+
+Coccinelle不对变量值进行分析，而这正是Smatch的强项。另一方面，Coccinelle
+允许你用简单的方法做简单的事情。
-- 
2.31.1

[PATCH v1 08/13] docs/zh_CN: Update the translation of reclaim to 6.1-rc8

[Yanteng Si]

Update to commit 205498012513 ("Docs/admin-guide/damon/reclaim:
remove a paragraph that been obsolete due to online tuning support")

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../translations/zh_CN/admin-guide/mm/damon/reclaim.rst       | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst
index c976f3e33ffd..bb185b7a9b9c 100644
--- a/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst
+++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst
@@ -47,10 +47,6 @@ DAMON_RECLAIM找到在特定时间内没有被访问的内存区域并分页。
 是说，你可以把 ``damon_reclaim.<parameter>=<value>`` 放在内核启动命令行上，或者把
 适当的值写入 ``/sys/modules/damon_reclaim/parameters/<parameter>`` 文件。
 
-注意，除 ``启用`` 外的参数值只在DAMON_RECLAIM启动时应用。因此，如果你想在运行时应用新
-的参数值，而DAMON_RECLAIM已经被启用，你应该通过 ``启用`` 的参数文件禁用和重新启用它。
-在重新启用之前，应将新的参数值写入适当的参数值中。
-
 下面是每个参数的描述。
 
 enabled
-- 
2.31.1

[PATCH v1 09/13] docs/zh_CN: Update the translation of start to 6.1-rc8

[Yanteng Si]

Update to commit 04cc7e4bf7c4 ("Docs/admin-guide/mm/damon/start:
mention the dependency as sysfs instead of debugfs")

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

diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst
index 67d1b49481dc..bf21ff84f396 100644
--- a/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst
+++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst
@@ -34,16 +34,8 @@
 https://github.com/awslabs/damo找到。下面的例子假设DAMO在你的$PATH上。当然，但
 这并不是强制性的。
 
-因为DAMO使用的是DAMON的debugfs接口(详情请参考 :doc:`usage` 中的使用方法) 你应该
-确保debugfs被挂载。手动挂载它，如下所示::
-
-    # mount -t debugfs none /sys/kernel/debug/
-
-或者在你的 ``/etc/fstab`` 文件中添加以下一行，这样你的系统就可以在启动时自动挂载
-debugfs了::
-
-    debugfs /sys/kernel/debug debugfs defaults 0 0
-
+因为DAMO使用了DAMON的sysfs接口（详情请参考:doc:`usage`），你应该确保
+:doc:`sysfs </filesystems/sysfs>` 被挂载。
 
 记录数据访问模式
 ================
-- 
2.31.1

[PATCH v1 10/13] docs/zh_CN: Update the translation of usage to 6.1-rc8

[Yanteng Si]

Update to commit 1da89ea0b006 ("Docs/admin-guide/mm/damon/usage:
document schemes/<s>/tried_regions sysfs directory")

commit 465d0eb0dc31 ("Docs/admin-guide/mm/damon/usage: fix the
example code snip")
commit f1f3afd59d78 ("Docs/admin-guide/mm/damon/usage: note DAMON
debugfs interface deprecation plan")
commit 9056a2229495 ("Docs/admin-guide/mm/damon/usage: describe
the rules of sysfs region directories")
commit c3774845541e ("Docs/admin-guide/mm/damon/usage: fix wrong
usage example of init_regions file")

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

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 aeae2ab65dd8..17b9949d9b43 100644
--- a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst
+++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst
@@ -46,10 +46,10 @@ DAMON的sysfs接口是在定义 ``CONFIG_DAMON_SYSFS`` 时建立的。它在其s
 对于一个简短的例子，用户可以监测一个给定工作负载的虚拟地址空间，如下所示::
 
     # cd /sys/kernel/mm/damon/admin/
-    # echo 1 > kdamonds/nr && echo 1 > kdamonds/0/contexts/nr
+    # echo 1 > kdamonds/nr_kdamonds && echo 1 > kdamonds/0/contexts/nr_contexts
     # echo vaddr > kdamonds/0/contexts/0/operations
-    # echo 1 > kdamonds/0/contexts/0/targets/nr
-    # echo $(pidof <workload>) > kdamonds/0/contexts/0/targets/0/pid
+    # echo 1 > kdamonds/0/contexts/0/targets/nr_targets
+    # echo $(pidof <workload>) > kdamonds/0/contexts/0/targets/0/pid_target
     # echo on > kdamonds/0/state
 
 文件层次结构
@@ -82,6 +82,9 @@ DAMON sysfs接口的文件层次结构如下图所示。在下图中，父子关
     │ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil
     │ │ │ │ │ │ │ watermarks/metric,interval_us,high,mid,low
     │ │ │ │ │ │ │ stats/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds
+    │ │ │ │ │ │ │ tried_regions/
+    │ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age
+    │ │ │ │ │ │ │ │ ...
     │ │ │ │ │ │ ...
     │ │ │ │ ...
     │ │ ...
@@ -111,7 +114,11 @@ kdamonds/<N>/
 读取 ``state`` 时，如果kdamond当前正在运行，则返回 ``on`` ，如果没有运行则返回 ``off`` 。
 写入 ``on`` 或 ``off`` 使kdamond处于状态。向 ``state`` 文件写 ``update_schemes_stats`` ，
 更新kdamond的每个基于DAMON的操作方案的统计文件的内容。关于统计信息的细节，请参考
-:ref:`stats section <sysfs_schemes_stats>`.
+:ref:`stats section <sysfs_schemes_stats>`. 将 ``update_schemes_tried_regions`` 写到
+``state`` 文件，为kdamond的每个基于DAMON的操作方案，更新基于DAMON的操作方案动作的尝试区域目录。
+将`clear_schemes_tried_regions`写入`state`文件，清除kdamond的每个基于DAMON的操作方案的动作
+尝试区域目录。 关于基于DAMON的操作方案动作尝试区域目录的细节，请参考:ref:tried_regions 部分
+<sysfs_schemes_tried_regions>`。
 
 如果状态为 ``on``，读取 ``pid`` 显示kdamond线程的pid。
 
@@ -186,6 +193,8 @@ regions/<N>/
 在每个区域目录中，你会发现两个文件（ ``start``  和  ``end`` ）。你可以通过向文件写入
 和从文件中读出，分别设置和获得初始监测目标区域的起始和结束地址。
 
+每个区域不应该与其他区域重叠。 目录“N”的“结束”应等于或小于目录“N+1”的“开始”。
+
 contexts/<N>/schemes/
 ---------------------
 
@@ -199,8 +208,8 @@ contexts/<N>/schemes/
 schemes/<N>/
 ------------
 
-在每个方案目录中，存在四个目录(``access_pattern``, ``quotas``,``watermarks``,
-和 ``stats``)和一个文件(``action``)。
+在每个方案目录中，存在五个目录(``access_pattern``、``quotas``、``watermarks``、
+``stats`` 和 ``tried_regions``)和一个文件(``action``)。
 
 ``action`` 文件用于设置和获取你想应用于具有特定访问模式的内存区域的动作。可以写入文件
 和从文件中读取的关键词及其含义如下。
@@ -229,8 +238,8 @@ schemes/<N>/quotas/
 
 每个 ``动作`` 的最佳 ``目标访问模式`` 取决于工作负载，所以不容易找到。更糟糕的是，将某些动作
 的方案设置得过于激进会造成严重的开销。为了避免这种开销，用户可以为每个方案限制时间和大小配额。
-具体来说，用户可以要求DAMON尽量只使用特定的时间（``时间配额``）来应用行动，并且在给定的时间间
-隔（``重置间隔``）内，只对具有目标访问模式的内存区域应用行动，而不使用特定数量（``大小配额``）。
+具体来说，用户可以要求DAMON尽量只使用特定的时间（``时间配额``）来应用动作，并且在给定的时间间
+隔（``重置间隔``）内，只对具有目标访问模式的内存区域应用动作，而不使用特定数量（``大小配额``）。
 
 当预计超过配额限制时，DAMON会根据 ``目标访问模式`` 的大小、访问频率和年龄，对找到的内存区域
 进行优先排序。为了进行个性化的优先排序，用户可以为这三个属性设置权重。
@@ -272,6 +281,24 @@ DAMON统计每个方案被尝试应用的区域的总数量和字节数，每个
 你应该要求DAMON sysfs接口通过在相关的 ``kdamonds/<N>/state`` 文件中写入一个特殊的关键字
 ``update_schemes_stats`` 来更新统计信息的文件内容。
 
+schemes/<N>/tried_regions/
+--------------------------
+
+当一个特殊的关键字 ``update_schemes_tried_regions`` 被写入相关的 ``kdamonds/<N>/state``
+文件时，DAMON会在这个目录下创建从 ``0`` 开始命名的整数目录。每个目录包含的文件暴露了关于每个
+内存区域的详细信息，在下一个 :ref:`聚集区间 <sysfs_monitoring_attrs>`，相应的方案的 ``动作``
+已经尝试在这个目录下应用。这些信息包括地址范围、``nr_accesses`` 以及区域的 ``年龄`` 。
+
+当另一个特殊的关键字 ``clear_schemes_tried_regions`` 被写入相关的 ``kdamonds/<N>/state``
+文件时，这些目录将被删除。
+
+tried_regions/<N>/
+------------------
+
+在每个区域目录中，你会发现四个文件(``start``, ``end``, ``nr_accesses``, and ``age``)。
+读取这些文件将显示相应的基于DAMON的操作方案 ``动作`` 试图应用的区域的开始和结束地址、``nr_accesses``
+和 ``年龄`` 。
+
 用例
 ~~~~
 
@@ -287,12 +314,12 @@ DAMON统计每个方案被尝试应用的区域的总数量和字节数，每个
     # echo 1 > kdamonds/0/contexts/0/schemes/nr_schemes
     # cd kdamonds/0/contexts/0/schemes/0
     # # set the basic access pattern and the action
-    # echo 4096 > access_patterns/sz/min
-    # echo 8192 > access_patterns/sz/max
-    # echo 0 > access_patterns/nr_accesses/min
-    # echo 5 > access_patterns/nr_accesses/max
-    # echo 10 > access_patterns/age/min
-    # echo 20 > access_patterns/age/max
+    # echo 4096 > access_pattern/sz/min
+    # echo 8192 > access_pattern/sz/max
+    # echo 0 > access_pattern/nr_accesses/min
+    # echo 5 > access_pattern/nr_accesses/max
+    # echo 10 > access_pattern/age/min
+    # echo 20 > access_pattern/age/max
     # echo pageout > action
     # # set quotas
     # echo 10 > quotas/ms
@@ -311,6 +338,11 @@ DAMON统计每个方案被尝试应用的区域的总数量和字节数，每个
 debugfs接口
 ===========
 
+.. note::
+
+  DAMON debugfs接口将在下一个LTS内核发布后被移除，所以用户应该转移到
+  :ref:`sysfs接口<sysfs_interface>`。
+
 DAMON导出了八个文件, ``attrs``, ``target_ids``, ``init_regions``,
 ``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts`` 和
 ``rm_contexts`` under its debugfs directory, ``<debugfs>/damon/``.
@@ -364,7 +396,7 @@ DAMON导出了八个文件, ``attrs``, ``target_ids``, ``init_regions``,
 监测目标区域。
 
 在这种情况下，用户可以通过在 ``init_regions`` 文件中写入适当的值，明确地设置他们想要的初
-始监测目标区域。输入的每一行应代表一个区域，形式如下::
+始监测目标区域。输入应该是一个由三个整数组成的队列，用空格隔开，代表一个区域的形式如下::
 
     <target idx> <start address> <end address>
 
@@ -376,9 +408,9 @@ DAMON导出了八个文件, ``attrs``, ``target_ids``, ``init_regions``,
     # cd <debugfs>/damon
     # cat target_ids
     42 4242
-    # echo "0   1       100
-            0   100     200
-            1   20      40
+    # echo "0   1       100 \
+            0   100     200 \
+            1   20      40  \
             1   50      100" > init_regions
 
 请注意，这只是设置了初始的监测目标区域。在虚拟内存监测的情况下，DAMON会在一个 ``更新间隔``
-- 
2.31.1

[PATCH v1 11/13] docs/zh_CN: Update the translation of ksm to 6.1-rc8

[Yanteng Si]

Update to commit 21b7bdb504ae ("ksm: add profit monitoring
documentation")

commit 94bfe85bde18 ("mm/vmstat: add events for ksm cow")

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

diff --git a/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst b/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst
index 4829156ef1ae..e27806aa90dc 100644
--- a/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst
+++ b/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst
@@ -146,3 +146,53 @@ stable_node_dups
 
 比值 ``pages_sharing/pages_shared`` 的最大值受限制于 ``max_page_sharing``
 的设定。要想增加该比值，则相应地要增加 ``max_page_sharing`` 的值。
+
+监测KSM的好处
+=============
+
+KSM可以通过合并相同的页面来节省内存，但也会消耗额外的内存，因为它需要生成一些rmap_items
+来保存每个扫描页面的简要rmap信息。其中有些页面可能会被合并，但有些页面在被检查几次
+后可能无法被合并，这些都是无益的内存消耗。
+
+1) 如何确定KSM在全系统范围内是节省内存还是消耗内存？这里有一个简单的近似计算方法供参考::
+
+       general_profit =~ pages_sharing * sizeof(page) - (all_rmap_items) *
+                         sizeof(rmap_item);
+
+   其中all_rmap_items可以通过对 ``pages_sharing`` 、 ``pages_shared`` 、 ``pages_unshared``
+   和 ``pages_volatile`` 的求和而轻松获得。
+
+2) KSM的好处在一个单一的进程中也可以通过以下近似的计算得到::
+
+       process_profit =~ ksm_merging_pages * sizeof(page) -
+                         ksm_rmap_items * sizeof(rmap_item).
+
+   其中ksm_merging_pages显示在 ``/proc/<pid>/`` 目录下，而ksm_rmap_items
+   显示在 ``/proc/<pid>/ksm_stat`` 。
+
+从应用的角度来看， ``ksm_rmap_items`` 和 ``ksm_merging_pages`` 的高比例意
+味着不好的madvise-applied策略，所以开发者或管理员必须重新考虑如何改变madvis策
+略。举个例子供参考，一个页面的大小通常是4K，而rmap_item的大小在32位CPU架构上分
+别是32B，在64位CPU架构上是64B。所以如果 ``ksm_rmap_items/ksm_merging_pages``
+的比例在64位CPU上超过64，或者在32位CPU上超过128，那么应用程序的madvise策略应
+该被放弃，因为ksm好处大约为零或负值。
+
+监控KSM事件
+===========
+
+在/proc/vmstat中有一些计数器，可以用来监控KSM事件。KSM可能有助于节省内存，这是
+一种权衡，因为它可能会在KSM COW或复制中的交换上遭受延迟。这些事件可以帮助用户评估
+是否或如何使用KSM。例如，如果cow_ksm增加得太快，用户可以减少madvise(, , MADV_MERGEABLE)
+的范围。
+
+cow_ksm
+        在每次KSM页面触发写时拷贝（COW）时都会被递增，当用户试图写到KSM页面时，
+        我们必须做一个拷贝。
+
+ksm_swpin_copy
+        在换入时，每次KSM页被复制时都会被递增。请注意，KSM页在换入时可能会被复
+        制，因为do_swap_page()不能做所有的锁，而需要重组一个跨anon_vma的KSM页。
+
+--
+Izik Eidus,
+Hugh Dickins, 2009年11月17日。
-- 
2.31.1

[PATCH v1 12/13] docs/zh_CN: Update the translation of msi-howto to 6.1-rc8

[Yanteng Si]

Update to commit 88614075a952 ("Documentation: PCI: Add reference
to PCI/MSI device driver APIs")

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

diff --git a/Documentation/translations/zh_CN/PCI/msi-howto.rst b/Documentation/translations/zh_CN/PCI/msi-howto.rst
index 7ea4d50cdad2..1b9b5ea790d8 100644
--- a/Documentation/translations/zh_CN/PCI/msi-howto.rst
+++ b/Documentation/translations/zh_CN/PCI/msi-howto.rst
@@ -231,3 +231,14 @@ ACPI FADT表中指明了它。在这种情况下，Linux会自动禁用MSI。有
 
 也需要检查设备驱动程序，看它是否支持MSI。例如，它可能包含对带有PCI_IRQ_MSI或
 PCI_IRQ_MSIX标志的pci_alloc_irq_vectors（）的调用。
+
+
+MSI(-X) APIs设备驱动程序列表
+============================
+
+PCI/MSI子系统有一个专门的C文件，用于其导出的设备驱动程序APIs - `drivers/pci/msi/api.c` 。
+以下是导出的函数:
+
+该API在以下内核代码中:
+
+drivers/pci/msi/api.c
-- 
2.31.1

[PATCH v1 13/13] docs/zh_CN: Update the translation of energy-model to 6.1-rc8

[Yanteng Si]

Update to commit c5d39fae8992 ("Documentation: EM: Switch to
micro-Watts scale")

commit f48a0c475c2a ("Documentation: EM: Describe new registration
method using DT")
commit 75a3a99a5a98 ("PM: EM: Change the order of arguments in the
.active_power() callback")
commit 015f569c4649 ("Documentation: EM: Add artificial EM
registration description")

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../translations/zh_CN/power/energy-model.rst | 36 ++++++++++++++-----
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/Documentation/translations/zh_CN/power/energy-model.rst b/Documentation/translations/zh_CN/power/energy-model.rst
index c7da1b6aefee..d740bbe22fde 100644
--- a/Documentation/translations/zh_CN/power/energy-model.rst
+++ b/Documentation/translations/zh_CN/power/energy-model.rst
@@ -23,15 +23,15 @@
 实现支持，EM框架作为一个抽象层介入，它在内核中对功率成本表的格式进行标准化，
 因此能够避免多余的工作。
 
-功率值可以用毫瓦或“抽象刻度”表示。多个子系统可能使用EM，由系统集成商来检查
+功率值可以用微瓦或“抽象刻度”表示。多个子系统可能使用EM，由系统集成商来检查
 功率值刻度类型的要求是否满足。可以在能量感知调度器的文档中找到一个例子
 Documentation/scheduler/sched-energy.rst。对于一些子系统，比如热能或
 powercap，用“抽象刻度”描述功率值可能会导致问题。这些子系统对过去使用的功率的
-估算值更感兴趣，因此可能需要真实的毫瓦。这些要求的一个例子可以在智能功率分配
+估算值更感兴趣，因此可能需要真实的微瓦。这些要求的一个例子可以在智能功率分配
 Documentation/driver-api/thermal/power_allocator.rst文档中找到。
 
 内核子系统可能（基于EM内部标志位）实现了对EM注册设备是否具有不一致刻度的自动
-检查。要记住的重要事情是，当功率值以“抽象刻度”表示时，从中推导以毫焦耳为单位
+检查。要记住的重要事情是，当功率值以“抽象刻度”表示时，从中推导以微焦耳为单位
 的真实能量消耗是不可能的。
 
 下图描述了一个驱动的例子（这里是针对Arm的，但该方法适用于任何体系结构），它
@@ -89,20 +89,40 @@ Documentation/driver-api/thermal/power_allocator.rst文档中找到。
 驱动程序应通过以下API将性能域注册到EM框架中::
 
   int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
-		struct em_data_callback *cb, cpumask_t *cpus, bool milliwatts);
+		struct em_data_callback *cb, cpumask_t *cpus, bool microwatts);
 
 驱动程序必须提供一个回调函数，为每个性能状态返回<频率,功率>元组。驱动程序
 提供的回调函数可以自由地从任何相关位置（DT、固件......）以及以任何被认为是
 必要的方式获取数据。只有对于CPU设备，驱动程序必须使用cpumask指定性能域的CPU。
 对于CPU以外的其他设备，最后一个参数必须被设置为NULL。
 
-最后一个参数“milliwatts”（毫瓦）设置成正确的值是很重要的，使用EM的内核
+最后一个参数“microwatts”（微瓦）设置成正确的值是很重要的，使用EM的内核
 子系统可能会依赖这个标志来检查所有的EM设备是否使用相同的刻度。如果有不同的
-刻度，这些子系统可能决定：返回警告/错误，停止工作或崩溃（panic）。
+刻度，这些子系统可能决定返回警告/错误，停止工作或崩溃（panic）。
 
 关于实现这个回调函数的驱动程序的例子，参见第3节。或者在第2.4节阅读这个API
 的更多文档。
 
+使用DT EM的注册
+===============
+
+EM也可以使用OPP框架和DT "操作点-v2 "中的信息注册。DT中的每个OPP条目都可
+以用一个包含微瓦特功率值的属性 "op-microwatt "来扩展。这个OPP DT属性允
+许平台注册反映总功率（静态+动态）的EM功率值。这些功率值可能直接来自实验和
+测量。
+
+“人工”EM的注册
+==============
+
+有一个选项可以为缺少关于每个性能状态的功率值的详细知识的驱动程序提供一个自
+定义回调。回调.get_cost()是可选的，它提供EAS使用的“成本”值。这对那些只提
+供CPU类型之间相对效率信息的平台很有用，人们可以利用这些信息来创建一个抽象的
+功率模型。但是，考虑到输入功率值的大小限制，即使是抽象的功率模型有时也很难装
+进去。.get_cost()允许提供反映CPU效率的“成本”值。这将允许提供EAS信息，它
+与EM内部计算'成本'值的公式有不同的关系。要为这样的平台注册EM，驱动程序必须
+将标志“microwatts”设置为0，提供.get_power()回调和.get_cost()回调。EM
+框架会在注册过程中正确处理这样的平台。一个标志EM_PERF_DOMAIN_ARTIFICIAL
+被设置为这种平台。其他使用EM的框架应该特别注意测试和正确对待这个标志。
 
 “简单”EM的注册
 ~~~~~~~~~~~~~~~~
@@ -147,8 +167,8 @@ cpufreq_driver::register_em()。这个回调必须为每个特定的驱动程序
 
   -> drivers/cpufreq/foo_cpufreq.c
 
-  01	static int est_power(unsigned long *mW, unsigned long *KHz,
-  02			struct device *dev)
+  01   static int est_power(struct device *dev, unsigned long *mW,
+  02                   unsigned long *KHz)
   03	{
   04		long freq, power;
   05
-- 
2.31.1

Re: [PATCH v1 01/13] docs/zh_CN: Update the translation of delay-accounting to 6.1-rc8

[Wu XiangCheng]

> Update to commit f347c9d2697f ("filemap: make the accounting
> of thrashing more consistent").
> 
> Commit 662ce1dc9caf ("delayacct: track delays from write-protect copy").
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  .../translations/zh_CN/accounting/delay-accounting.rst     | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/translations/zh_CN/accounting/delay-accounting.rst b/Documentation/translations/zh_CN/accounting/delay-accounting.rst
> index f1849411018e..71a3c1f2b07a 100644
> --- a/Documentation/translations/zh_CN/accounting/delay-accounting.rst
> +++ b/Documentation/translations/zh_CN/accounting/delay-accounting.rst
> @@ -17,8 +17,9 @@ a) 等待一个CPU（任务为可运行）
>  b) 完成由该任务发起的块I/O同步请求
>  c) 页面交换
>  d) 内存回收
> -e) 页缓存抖动
> +e) 抖动
>  f) 直接规整
> +g) 写保护复制
>  
>  并将这些统计信息通过taskstats接口提供给用户空间。
>  
> @@ -42,7 +43,7 @@ f) 直接规整
>       include/uapi/linux/taskstats.h
>  
>  其描述了延时计数相关字段。系统通常以计数器形式返回 CPU、同步块 I/O、交换、内存
> -回收、页缓存抖动、直接规整等的累积延时。
> +回收、页缓存抖动、直接规整、写保护复制等的累积延时。
>  
>  取任务某计数器两个连续读数的差值，将得到任务在该时间间隔内等待对应资源的总延时。
>  
> @@ -100,6 +101,8 @@ getdelays命令的一般格式::
>  	                    0              0              0ms
>  	COMPACT         count    delay total  delay average
>  	                    0              0              0ms
> +    WPCOPY          count    delay total  delay average
^^^^^^
a Tab

> +	                    0              0              0ms
>  
>  获取pid为1的IO计数，它只和-p一起使用::
>  	# ./getdelays -i -p 1
> -- 
> 2.31.1
> 
> 
> 

Re: [PATCH v1 02/13] docs/zh_CN: Update the translation of kernel-api to 6.1-rc8

[Wu XiangCheng]

> Update to commit d28a1de5d112 ("math64: favor kernel-doc
> from header files").
> 
> Commit 03699f271de1 ("string: Rewrite and add more kern-doc
> for the str*() functions").
> Commit 31970608a6d3 ("overflow: Fix kern-doc markup for
> functions")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>

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

> ---
>  .../translations/zh_CN/core-api/kernel-api.rst         | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/translations/zh_CN/core-api/kernel-api.rst b/Documentation/translations/zh_CN/core-api/kernel-api.rst
> index c22662679065..a4b373c48c0c 100644
> --- a/Documentation/translations/zh_CN/core-api/kernel-api.rst
> +++ b/Documentation/translations/zh_CN/core-api/kernel-api.rst
> @@ -48,6 +48,8 @@ lib/string_helpers.c
>  
>  该API在以下内核代码中:
>  
> +include/linux/fortify-string.h
> +
>  lib/string.c
>  
>  include/linux/string.h
> @@ -119,6 +121,12 @@ include/linux/textsearch.h
>  Linux中的CRC和数学函数
>  ======================
>  
> +算术溢出检查
> +------------
> +
> +该API在以下内核代码中:
> +
> +include/linux/overflow.h
>  
>  CRC函数
>  -------
> @@ -166,8 +174,6 @@ include/asm-generic/div64.h
>  
>  include/linux/math64.h
>  
> -lib/math/div64.c
> -
>  lib/math/gcd.c
>  
>  UUID/GUID
> -- 
> 2.31.1
> 

Re: [PATCH v1 03/13] docs/zh_CN: Update the translation of mm-api to 6.1-rc8

[Wu XiangCheng]

> Update to commit def76fd549c5 ("mm/page_alloc: remove
> obsolete gfpflags_normal_context()").
> 
> Commit 7343f2b0db49 ("headers/deps: mm: align
> MANITAINERS and Docs with new gfp.h structure")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>

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

Such minor path changes can be squashed.

> ---
>  Documentation/translations/zh_CN/core-api/mm-api.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/translations/zh_CN/core-api/mm-api.rst b/Documentation/translations/zh_CN/core-api/mm-api.rst
> index a732b0eebf16..113359bdb7be 100644
> --- a/Documentation/translations/zh_CN/core-api/mm-api.rst
> +++ b/Documentation/translations/zh_CN/core-api/mm-api.rst
> @@ -37,7 +37,7 @@ mm/gup.c
>  
>  该API在以下内核代码中:
>  
> -include/linux/gfp.h
> +include/linux/gfp_types.h
>  
>  Slab缓存
>  ========
> -- 
> 2.31.1
> 
> 
> 

Re: [PATCH v1 04/13] docs/zh_CN: Update the translation of highmem to 6.1-rc8

[Wu XiangCheng]

> Update to commit a9e9c93966af ("Documentation/mm: add
> details about kmap_local_page() and preemption").
> 
> Commit 84b86f6054c4 ("Documentation/mm: rrefer
> kmap_local_page() and avoid kmap()").
> Commit 6b3afe2eeec2 ("Documentation/mm: avoid
> invalid use of addresses from kmap_local_page()").
> Commit 516ea046ec55 ("Documentation/mm: don't kmap*()
> pages which can't come from HIGHMEM").
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>

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

> ---
>  .../translations/zh_CN/mm/highmem.rst         | 20 ++++++++++++++++---
>  1 file changed, 17 insertions(+), 3 deletions(-)

Re: [PATCH v1 05/13] docs/zh_CN: Update the translation of page_owner to 6.1-rc8

[Wu XiangCheng]

> Update to commit 0719fdba5483 ("Documentation/mm/page_owner.rst:
> delete frequently changing experimental data").
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>

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

> ---
>  .../translations/zh_CN/mm/page_owner.rst        | 17 +++--------------
>  1 file changed, 3 insertions(+), 14 deletions(-)

Re: [PATCH v1 07/13] docs/zh_CN: Update the translation of testing-overview to 6.1-rc8

[Wu XiangCheng]

> Update to commit a32d5c0fc12b ("Documentation: dev-tools:
> Enhance static analysis section with discussion")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  .../zh_CN/dev-tools/testing-overview.rst      | 27 +++++++++++++++++++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
> index d6f2c65ed511..d53a326de93a 100644
> --- a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
> +++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
> @@ -132,3 +132,30 @@ Documentation/dev-tools/kcov.rst 是能够构建在内核之中，用于在每
>  
>   不过要注意的是，静态分析工具存在**假阳性**的问题。在试图修复错误和警
>   告之前，需要仔细评估它们。
> +
> +何时使用Sparse和Smatch
> +----------------------
> +
> +Sparse做类型检查，例如验证注释的变量不会导致无符号的错误，检测
> +``__user`` 指针使用不当的地方，以及分析符号初始化器的兼容性。
> +
> +Smatch进行流程分析，如果允许建立函数数据库，它还会进行跨函数分析。
> +Smatch试图回答一些问题，比如这个缓冲区是在哪里分配的？它有多大？这
> +个索引可以由用户控制吗？这个变量比那个变量大吗？
> +
> +一般来说，在Smatch中写检查比在Sparse中写检查要容易。尽管如此，
> +Sparse和Smatch的检查还是有一些重叠的地方。
> +
> +Smatch和Coccinelle的强项
> +------------------------
> +
> +Coccinelle可能是最容易写检查的。它在预处理器之前工作，所以用Coccinelle
> +检查宏中的错误更容易。Coccinelle还能为你创建补丁，这是其他工具无法做到的。
> +
> +例如，用Coccinelle你可以从kmalloc(x * size, GFP_KERNEL)到

``kmalloc(x * size, GFP_KERNEL)``

> +``kmalloc_array(x, size, GFP_KERNEL)`` 进行大规模转换，这真的很有用。
> +如果你只是创建一个Smatch警告，并试图把转换的工作推给维护者，他们会很恼火。
> +你将不得不为每个警告争论是否真的可以溢出。
> +
> +Coccinelle不对变量值进行分析，而这正是Smatch的强项。另一方面，Coccinelle
> +允许你用简单的方法做简单的事情。
> -- 
> 2.31.1
> 

Re: [PATCH v1 08/13] docs/zh_CN: Update the translation of reclaim to 6.1-rc8

[Wu XiangCheng]

> Update to commit 205498012513 ("Docs/admin-guide/damon/reclaim:
> remove a paragraph that been obsolete due to online tuning support")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>

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

> ---
>  .../translations/zh_CN/admin-guide/mm/damon/reclaim.rst       | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst
> index c976f3e33ffd..bb185b7a9b9c 100644
> --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst
> +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst
> @@ -47,10 +47,6 @@ DAMON_RECLAIM找到在特定时间内没有被访问的内存区域并分页。
>  是说，你可以把 ``damon_reclaim.<parameter>=<value>`` 放在内核启动命令行上，或者把
>  适当的值写入 ``/sys/modules/damon_reclaim/parameters/<parameter>`` 文件。
>  
> -注意，除 ``启用`` 外的参数值只在DAMON_RECLAIM启动时应用。因此，如果你想在运行时应用新
> -的参数值，而DAMON_RECLAIM已经被启用，你应该通过 ``启用`` 的参数文件禁用和重新启用它。
> -在重新启用之前，应将新的参数值写入适当的参数值中。
> -
>  下面是每个参数的描述。
>  
>  enabled
> -- 
> 2.31.1
> 
> 
> 

Re: [PATCH v1 09/13] docs/zh_CN: Update the translation of start to 6.1-rc8

[Wu XiangCheng]

> Update to commit 04cc7e4bf7c4 ("Docs/admin-guide/mm/damon/start:
> mention the dependency as sysfs instead of debugfs")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>

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

> ---
>  .../zh_CN/admin-guide/mm/damon/start.rst             | 12 ++----------
>  1 file changed, 2 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst
> index 67d1b49481dc..bf21ff84f396 100644
> --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst
> +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst
> @@ -34,16 +34,8 @@
>  https://github.com/awslabs/damo找到。下面的例子假设DAMO在你的$PATH上。当然，但
>  这并不是强制性的。
>  
> -因为DAMO使用的是DAMON的debugfs接口(详情请参考 :doc:`usage` 中的使用方法) 你应该
> -确保debugfs被挂载。手动挂载它，如下所示::
> -
> -    # mount -t debugfs none /sys/kernel/debug/
> -
> -或者在你的 ``/etc/fstab`` 文件中添加以下一行，这样你的系统就可以在启动时自动挂载
> -debugfs了::
> -
> -    debugfs /sys/kernel/debug debugfs defaults 0 0
> -
> +因为DAMO使用了DAMON的sysfs接口（详情请参考:doc:`usage`），你应该确保
> +:doc:`sysfs </filesystems/sysfs>` 被挂载。
>  
>  记录数据访问模式
>  ================
> -- 
> 2.31.1
> 
> 
> 

Re: [PATCH v1 10/13] docs/zh_CN: Update the translation of usage to 6.1-rc8

[Wu XiangCheng]

> Update to commit 1da89ea0b006 ("Docs/admin-guide/mm/damon/usage:
> document schemes/<s>/tried_regions sysfs directory")
> 
> commit 465d0eb0dc31 ("Docs/admin-guide/mm/damon/usage: fix the
> example code snip")
> commit f1f3afd59d78 ("Docs/admin-guide/mm/damon/usage: note DAMON
> debugfs interface deprecation plan")
> commit 9056a2229495 ("Docs/admin-guide/mm/damon/usage: describe
> the rules of sysfs region directories")
> commit c3774845541e ("Docs/admin-guide/mm/damon/usage: fix wrong
> usage example of init_regions file")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>

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

> ---
>  .../zh_CN/admin-guide/mm/damon/usage.rst      | 68 ++++++++++++++-----
>  1 file changed, 50 insertions(+), 18 deletions(-)

Re: [PATCH v1 11/13] docs/zh_CN: Update the translation of ksm to 6.1-rc8

[Wu XiangCheng]

> Update to commit 21b7bdb504ae ("ksm: add profit monitoring
> documentation")
> 
> commit 94bfe85bde18 ("mm/vmstat: add events for ksm cow")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  .../translations/zh_CN/admin-guide/mm/ksm.rst | 50 +++++++++++++++++++
>  1 file changed, 50 insertions(+)
> 
> diff --git a/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst b/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst
> index 4829156ef1ae..e27806aa90dc 100644
> --- a/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst
> +++ b/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst
> @@ -146,3 +146,53 @@ stable_node_dups
>  
>  比值 ``pages_sharing/pages_shared`` 的最大值受限制于 ``max_page_sharing``
>  的设定。要想增加该比值，则相应地要增加 ``max_page_sharing`` 的值。
> +
> +监测KSM的好处

好处 => 收益

> +=============
> +
> +KSM可以通过合并相同的页面来节省内存，但也会消耗额外的内存，因为它需要生成一些rmap_items
> +来保存每个扫描页面的简要rmap信息。其中有些页面可能会被合并，但有些页面在被检查几次
> +后可能无法被合并，这些都是无益的内存消耗。
> +
> +1) 如何确定KSM在全系统范围内是节省内存还是消耗内存？这里有一个简单的近似计算方法供参考::
> +
> +       general_profit =~ pages_sharing * sizeof(page) - (all_rmap_items) *
> +                         sizeof(rmap_item);
> +
> +   其中all_rmap_items可以通过对 ``pages_sharing`` 、 ``pages_shared`` 、 ``pages_unshared``
> +   和 ``pages_volatile`` 的求和而轻松获得。
> +
> +2) KSM的好处在一个单一的进程中也可以通过以下近似的计算得到::

单一进程中KSM的收益

> +
> +       process_profit =~ ksm_merging_pages * sizeof(page) -
> +                         ksm_rmap_items * sizeof(rmap_item).
> +
> +   其中ksm_merging_pages显示在 ``/proc/<pid>/`` 目录下，而ksm_rmap_items
> +   显示在 ``/proc/<pid>/ksm_stat`` 。
> +
> +从应用的角度来看， ``ksm_rmap_items`` 和 ``ksm_merging_pages`` 的高比例意
> +味着不好的madvise-applied策略，所以开发者或管理员必须重新考虑如何改变madvis策
> +略。举个例子供参考，一个页面的大小通常是4K，而rmap_item的大小在32位CPU架构上分
> +别是32B，在64位CPU架构上是64B。所以如果 ``ksm_rmap_items/ksm_merging_pages``
> +的比例在64位CPU上超过64，或者在32位CPU上超过128，那么应用程序的madvise策略应
> +该被放弃，因为ksm好处大约为零或负值。

好处 => 收益

> +
> +监控KSM事件
> +===========
> +
> +在/proc/vmstat中有一些计数器，可以用来监控KSM事件。KSM可能有助于节省内存，这是
> +一种权衡，因为它可能会在KSM COW或复制中的交换上遭受延迟。这些事件可以帮助用户评估
> +是否或如何使用KSM。例如，如果cow_ksm增加得太快，用户可以减少madvise(, , MADV_MERGEABLE)
> +的范围。
> +
> +cow_ksm
> +        在每次KSM页面触发写时拷贝（COW）时都会被递增，当用户试图写到KSM页面时，

写到 => 写入

> +        我们必须做一个拷贝。
> +
> +ksm_swpin_copy
> +        在换入时，每次KSM页被复制时都会被递增。请注意，KSM页在换入时可能会被复
> +        制，因为do_swap_page()不能做所有的锁，而需要重组一个跨anon_vma的KSM页。
> +
> +--
> +Izik Eidus,
> +Hugh Dickins, 2009年11月17日。
> -- 
> 2.31.1
> 

Re: [PATCH v1 12/13] docs/zh_CN: Update the translation of msi-howto to 6.1-rc8

[Wu XiangCheng]

> Update to commit 88614075a952 ("Documentation: PCI: Add reference
> to PCI/MSI device driver APIs")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>

Only found in next tree.

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

> ---
>  Documentation/translations/zh_CN/PCI/msi-howto.rst | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/translations/zh_CN/PCI/msi-howto.rst b/Documentation/translations/zh_CN/PCI/msi-howto.rst
> index 7ea4d50cdad2..1b9b5ea790d8 100644
> --- a/Documentation/translations/zh_CN/PCI/msi-howto.rst
> +++ b/Documentation/translations/zh_CN/PCI/msi-howto.rst
> @@ -231,3 +231,14 @@ ACPI FADT表中指明了它。在这种情况下，Linux会自动禁用MSI。有
>  
>  也需要检查设备驱动程序，看它是否支持MSI。例如，它可能包含对带有PCI_IRQ_MSI或
>  PCI_IRQ_MSIX标志的pci_alloc_irq_vectors（）的调用。
> +
> +
> +MSI(-X) APIs设备驱动程序列表
> +============================
> +
> +PCI/MSI子系统有一个专门的C文件，用于其导出的设备驱动程序APIs - `drivers/pci/msi/api.c` 。
> +以下是导出的函数:
> +
> +该API在以下内核代码中:
> +
> +drivers/pci/msi/api.c
> -- 
> 2.31.1
> 

Re: [PATCH v1 13/13] docs/zh_CN: Update the translation of energy-model to 6.1-rc8

[Wu XiangCheng]

> Update to commit c5d39fae8992 ("Documentation: EM: Switch to
> micro-Watts scale")
> 
> commit f48a0c475c2a ("Documentation: EM: Describe new registration
> method using DT")
> commit 75a3a99a5a98 ("PM: EM: Change the order of arguments in the
> .active_power() callback")
> commit 015f569c4649 ("Documentation: EM: Add artificial EM
> registration description")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  .../translations/zh_CN/power/energy-model.rst | 36 ++++++++++++++-----
>  1 file changed, 28 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/translations/zh_CN/power/energy-model.rst b/Documentation/translations/zh_CN/power/energy-model.rst
> index c7da1b6aefee..d740bbe22fde 100644
> --- a/Documentation/translations/zh_CN/power/energy-model.rst
> +++ b/Documentation/translations/zh_CN/power/energy-model.rst
> @@ -23,15 +23,15 @@
>  实现支持，EM框架作为一个抽象层介入，它在内核中对功率成本表的格式进行标准化，
>  因此能够避免多余的工作。
>  
> -功率值可以用毫瓦或“抽象刻度”表示。多个子系统可能使用EM，由系统集成商来检查
> +功率值可以用微瓦或“抽象刻度”表示。多个子系统可能使用EM，由系统集成商来检查
>  功率值刻度类型的要求是否满足。可以在能量感知调度器的文档中找到一个例子
>  Documentation/scheduler/sched-energy.rst。对于一些子系统，比如热能或
>  powercap，用“抽象刻度”描述功率值可能会导致问题。这些子系统对过去使用的功率的
> -估算值更感兴趣，因此可能需要真实的毫瓦。这些要求的一个例子可以在智能功率分配
> +估算值更感兴趣，因此可能需要真实的微瓦。这些要求的一个例子可以在智能功率分配
>  Documentation/driver-api/thermal/power_allocator.rst文档中找到。
>  
>  内核子系统可能（基于EM内部标志位）实现了对EM注册设备是否具有不一致刻度的自动
> -检查。要记住的重要事情是，当功率值以“抽象刻度”表示时，从中推导以毫焦耳为单位
> +检查。要记住的重要事情是，当功率值以“抽象刻度”表示时，从中推导以微焦耳为单位
>  的真实能量消耗是不可能的。
>  
>  下图描述了一个驱动的例子（这里是针对Arm的，但该方法适用于任何体系结构），它
> @@ -89,20 +89,40 @@ Documentation/driver-api/thermal/power_allocator.rst文档中找到。
>  驱动程序应通过以下API将性能域注册到EM框架中::
>  
>    int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
> -		struct em_data_callback *cb, cpumask_t *cpus, bool milliwatts);
> +		struct em_data_callback *cb, cpumask_t *cpus, bool microwatts);
>  
>  驱动程序必须提供一个回调函数，为每个性能状态返回<频率,功率>元组。驱动程序
>  提供的回调函数可以自由地从任何相关位置（DT、固件......）以及以任何被认为是
>  必要的方式获取数据。只有对于CPU设备，驱动程序必须使用cpumask指定性能域的CPU。
>  对于CPU以外的其他设备，最后一个参数必须被设置为NULL。
>  
> -最后一个参数“milliwatts”（毫瓦）设置成正确的值是很重要的，使用EM的内核
> +最后一个参数“microwatts”（微瓦）设置成正确的值是很重要的，使用EM的内核
>  子系统可能会依赖这个标志来检查所有的EM设备是否使用相同的刻度。如果有不同的
> -刻度，这些子系统可能决定：返回警告/错误，停止工作或崩溃（panic）。
> +刻度，这些子系统可能决定返回警告/错误，停止工作或崩溃（panic）。
>  
>  关于实现这个回调函数的驱动程序的例子，参见第3节。或者在第2.4节阅读这个API
>  的更多文档。
>  
> +使用DT EM的注册

使用DT的EM注册

> +===============
> +
> +EM也可以使用OPP框架和DT "操作点-v2 "中的信息注册。DT中的每个OPP条目都可
> +以用一个包含微瓦特功率值的属性 "op-microwatt "来扩展。这个OPP DT属性允
> +许平台注册反映总功率（静态+动态）的EM功率值。这些功率值可能直接来自实验和
> +测量。
> +
> +“人工”EM的注册
> +==============
> +
> +有一个选项可以为缺少关于每个性能状态的功率值的详细知识的驱动程序提供一个自
> +定义回调。回调.get_cost()是可选的，它提供EAS使用的“成本”值。这对那些只提
> +供CPU类型之间相对效率信息的平台很有用，人们可以利用这些信息来创建一个抽象的
> +功率模型。但是，考虑到输入功率值的大小限制，即使是抽象的功率模型有时也很难装
> +进去。.get_cost()允许提供反映CPU效率的“成本”值。这将允许提供EAS信息，它
> +与EM内部计算'成本'值的公式有不同的关系。要为这样的平台注册EM，驱动程序必须
> +将标志“microwatts”设置为0，提供.get_power()回调和.get_cost()回调。EM
> +框架会在注册过程中正确处理这样的平台。一个标志EM_PERF_DOMAIN_ARTIFICIAL
> +被设置为这种平台。其他使用EM的框架应该特别注意测试和正确对待这个标志。

这种平台会被设置EM_PERF_DOMAIN_ARTIFICIAL标志。

> “简单”EM的注册
> ~~~~~~~~~~~~~~~~
> @@ -147,8 +167,8 @@ cpufreq_driver::register_em()。这个回调必须为每个特定的驱动程序
>  
>    -> drivers/cpufreq/foo_cpufreq.c
>  
> -  01	static int est_power(unsigned long *mW, unsigned long *KHz,
> -  02			struct device *dev)
> +  01   static int est_power(struct device *dev, unsigned long *mW,
> +  02                   unsigned long *KHz)
>    03	{
>    04		long freq, power;
>    05
> -- 
> 2.31.1
>

Re: [PATCH v1 06/13] docs/zh_CN: Update the translation of kasan to 6.1-rc8

[Wu XiangCheng]

> Update to commit cd36d84d2571 ("kasan: allow sampling
> page_alloc allocations for HW_TAGS")
> 
> Commit 80b92bfe3bb7 ("kasan: dynamically allocate
> stack ring entries")
> Commit 7ebfce331251 ("kasan: support kasan.stacktrace
> for SW_TAGS")
> Commit ca89f2a2e66d ("kasan: move boot parameters
> section in documentation")
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  .../translations/zh_CN/dev-tools/kasan.rst    | 77 +++++++++++--------
>  1 file changed, 44 insertions(+), 33 deletions(-)
> 
> diff --git a/Documentation/translations/zh_CN/dev-tools/kasan.rst b/Documentation/translations/zh_CN/dev-tools/kasan.rst
> index fe76cbe77ad6..c645b1b6cc53 100644
> --- a/Documentation/translations/zh_CN/dev-tools/kasan.rst
> +++ b/Documentation/translations/zh_CN/dev-tools/kasan.rst
> @@ -90,6 +90,50 @@ KASAN只支持SLUB。
>  ``CONFIG_STACKTRACE`` 。要包括受影响物理页面的分配和释放堆栈跟踪的话，
>  请启用 ``CONFIG_PAGE_OWNER`` 并使用 ``page_owner=on`` 进行引导。
>  
> +启动参数
> +~~~~~~~~
> +
> +KASAN受到通用 ``panic_on_warn`` 命令行参数的影响。当它被启用时，KASAN
> +在打印出错误报告后会使内核恐慌。
> +
> +默认情况下，KASAN只对第一个无效的内存访问打印错误报告。使用
> +``kasan_multi_shot``，KASAN对每一个无效的访问都打印一份报告。这有效地

有效地 => 会

> +禁用了KASAN报告的 ``panic_on_warn``。
> +
> +另外，独立于 ``panic_on_warn`` 、 ``kasan.fault=`` boot参数可以用
> +来控制恐慌和报告行为。
> +
> +- ``kasan.fault=report`` 或 ``=panic`` 控制是否只打印KASAN报告或
> +  同时使内核恐慌（默认： ``报告`` ）。即使 ``kasan_multi_shot`` 被

报告 => report

> +  启用，恐慌也会发生。
> +
> +基于软件和硬件标签的KASAN模式（见下面关于各种模式的部分）支持改变堆栈跟
> +踪收集行为：
> +
> +- ``kasan.stacktrace=off`` 或 ``=on`` 禁用或启用分配和释放堆栈痕
> +  迹的收集（默认： ``on`` ）。
> +
> +- ``kasan.stack_ring_size=<number of entries>`` 指定堆栈环的条
> +  目数（默认： ``32768`` ）。
> +
> +基于硬件标签的KASAN模式是为了在生产中作为一种安全缓解措施使用。因此，它
> +支持额外的启动参数，允许完全禁用KASAN或控制其功能。
> +
> +- ``kasan=off`` 或 ``=on`` 控制KASAN是否被启用（默认： ``on`` ）。
> +
> +- ``kasan.mode=sync``, ``=async`` or ``=asymm`` 控制KASAN是否
> +  被配置为同步、异步或非对称的执行模式（默认： ``同步`` ）。
> +  同步模式：当标签检查异常发生时，会立即检测到不良访问。
> +  异步模式：不良访问的检测是延迟的。当标签检查异常发生时，信息被存储在硬
> +  件中（对于arm64来说是在TFSR_EL1寄存器中）。内核周期性地检查硬件，并\
> +  且只在这些检查中报告标签异常。
> +  非对称模式：读取时同步检测不良访问，写入时异步检测。
> +
> +- ``kasan.vmalloc=off`` or ``=on`` 禁用或启用vmalloc分配的标记（默认： ``on`` ）。
> +
> +- ``kasan.page_alloc.sample=<sampling frequency>`` 使得KASAN
> +  只对每N次page_alloc分配进行标记，其中N是参数的值（默认值： ``1`` ）。

Remove previous paragraph.

> +
>  错误报告
>  ~~~~~~~~
>  
> @@ -194,39 +238,6 @@ slab对象的描述以及关于访问的内存页的信息。
>  通用KASAN还报告两个辅助调用堆栈跟踪。这些堆栈跟踪指向代码中与对象交互但不直接
>  出现在错误访问堆栈跟踪中的位置。目前，这包括 call_rcu() 和排队的工作队列。
>  
> -启动参数
> -~~~~~~~~
> -
> -KASAN受通用 ``panic_on_warn`` 命令行参数的影响。启用该功能后，KASAN在打印错误
> -报告后会引起内核恐慌。
> -
> -默认情况下，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=off`` 或 ``=on`` 控制KASAN是否启用 (默认: ``on`` )。
> -
> -- ``kasan.mode=sync`` 、 ``=async`` 或 ``=asymm`` 控制KASAN是否配置
> -  为同步或异步执行模式(默认:``sync`` )。
> -  同步模式：当标签检查错误发生时，立即检测到错误访问。
> -  异步模式：延迟错误访问检测。当标签检查错误发生时，信息存储在硬件中（在arm64的
> -  TFSR_EL1寄存器中）。内核会定期检查硬件，并且仅在这些检查期间报告标签错误。
> -  非对称模式：读取时同步检测不良访问，写入时异步检测。
> -
> -- ``kasan.vmalloc=off`` 或 ``=on`` 禁用或启用vmalloc分配的标记（默认：``on`` ）。
> -
> -- ``kasan.stacktrace=off`` 或 ``=on`` 禁用或启用alloc和free堆栈跟踪收集
> -  (默认: ``on`` )。
> -
> -
>  实施细则
>  --------
>  
> -- 
> 2.31.1
>

Re: [PATCH v1 01/13] docs/zh_CN: Update the translation of delay-accounting to 6.1-rc8

[Yanteng Si]

在 12/9/22 14:55, Wu XiangCheng 写道:
>> Update to commit f347c9d2697f ("filemap: make the accounting
>> of thrashing more consistent").
>>
>> Commit 662ce1dc9caf ("delayacct: track delays from write-protect copy").
>>
>> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
>> ---
>>   .../translations/zh_CN/accounting/delay-accounting.rst     | 7 +++++--
>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/translations/zh_CN/accounting/delay-accounting.rst b/Documentation/translations/zh_CN/accounting/delay-accounting.rst
>> index f1849411018e..71a3c1f2b07a 100644
>> --- a/Documentation/translations/zh_CN/accounting/delay-accounting.rst
>> +++ b/Documentation/translations/zh_CN/accounting/delay-accounting.rst
>> @@ -17,8 +17,9 @@ a) 等待一个CPU（任务为可运行）
>>   b) 完成由该任务发起的块I/O同步请求
>>   c) 页面交换
>>   d) 内存回收
>> -e) 页缓存抖动
>> +e) 抖动
>>   f) 直接规整
>> +g) 写保护复制
>>   
>>   并将这些统计信息通过taskstats接口提供给用户空间。
>>   
>> @@ -42,7 +43,7 @@ f) 直接规整
>>        include/uapi/linux/taskstats.h
>>   
>>   其描述了延时计数相关字段。系统通常以计数器形式返回 CPU、同步块 I/O、交换、内存
>> -回收、页缓存抖动、直接规整等的累积延时。
>> +回收、页缓存抖动、直接规整、写保护复制等的累积延时。
>>   
>>   取任务某计数器两个连续读数的差值，将得到任务在该时间间隔内等待对应资源的总延时。
>>   
>> @@ -100,6 +101,8 @@ getdelays命令的一般格式::
>>   	                    0              0              0ms
>>   	COMPACT         count    delay total  delay average
>>   	                    0              0              0ms
>> +    WPCOPY          count    delay total  delay average
> ^^^^^^
> a Tab

Removed.


Thanks,

Yanteng

>
>> +	                    0              0              0ms
>>   
>>   获取pid为1的IO计数，它只和-p一起使用::
>>   	# ./getdelays -i -p 1
>> -- 
>> 2.31.1
>>
>>
>>

Re: [PATCH v1 07/13] docs/zh_CN: Update the translation of testing-overview to 6.1-rc8

[Yanteng Si]

在 12/9/22 15:05, Wu XiangCheng 写道:
>> Update to commit a32d5c0fc12b ("Documentation: dev-tools:
>> Enhance static analysis section with discussion")
>>
>> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
>> ---
>>   .../zh_CN/dev-tools/testing-overview.rst      | 27 +++++++++++++++++++
>>   1 file changed, 27 insertions(+)
>>
>> diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
>> index d6f2c65ed511..d53a326de93a 100644
>> --- a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
>> +++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
>> @@ -132,3 +132,30 @@ Documentation/dev-tools/kcov.rst 是能够构建在内核之中，用于在每
>>   
>>    不过要注意的是，静态分析工具存在**假阳性**的问题。在试图修复错误和警
>>    告之前，需要仔细评估它们。
>> +
>> +何时使用Sparse和Smatch
>> +----------------------
>> +
>> +Sparse做类型检查，例如验证注释的变量不会导致无符号的错误，检测
>> +``__user`` 指针使用不当的地方，以及分析符号初始化器的兼容性。
>> +
>> +Smatch进行流程分析，如果允许建立函数数据库，它还会进行跨函数分析。
>> +Smatch试图回答一些问题，比如这个缓冲区是在哪里分配的？它有多大？这
>> +个索引可以由用户控制吗？这个变量比那个变量大吗？
>> +
>> +一般来说，在Smatch中写检查比在Sparse中写检查要容易。尽管如此，
>> +Sparse和Smatch的检查还是有一些重叠的地方。
>> +
>> +Smatch和Coccinelle的强项
>> +------------------------
>> +
>> +Coccinelle可能是最容易写检查的。它在预处理器之前工作，所以用Coccinelle
>> +检查宏中的错误更容易。Coccinelle还能为你创建补丁，这是其他工具无法做到的。
>> +
>> +例如，用Coccinelle你可以从kmalloc(x * size, GFP_KERNEL)到
> ``kmalloc(x * size, GFP_KERNEL)``

OK!


Thanks,

Yanteng

>
>> +``kmalloc_array(x, size, GFP_KERNEL)`` 进行大规模转换，这真的很有用。
>> +如果你只是创建一个Smatch警告，并试图把转换的工作推给维护者，他们会很恼火。
>> +你将不得不为每个警告争论是否真的可以溢出。
>> +
>> +Coccinelle不对变量值进行分析，而这正是Smatch的强项。另一方面，Coccinelle
>> +允许你用简单的方法做简单的事情。
>> -- 
>> 2.31.1
>>

Re: [PATCH v1 11/13] docs/zh_CN: Update the translation of ksm to 6.1-rc8

[Yanteng Si]

在 12/9/22 15:09, Wu XiangCheng 写道:
>> Update to commit 21b7bdb504ae ("ksm: add profit monitoring
>> documentation")
>>
>> commit 94bfe85bde18 ("mm/vmstat: add events for ksm cow")
>>
>> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
>> ---
>>   .../translations/zh_CN/admin-guide/mm/ksm.rst | 50 +++++++++++++++++++
>>   1 file changed, 50 insertions(+)
>>
>> diff --git a/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst b/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst
>> index 4829156ef1ae..e27806aa90dc 100644
>> --- a/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst
>> +++ b/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst
>> @@ -146,3 +146,53 @@ stable_node_dups
>>   
>>   比值 ``pages_sharing/pages_shared`` 的最大值受限制于 ``max_page_sharing``
>>   的设定。要想增加该比值，则相应地要增加 ``max_page_sharing`` 的值。
>> +
>> +监测KSM的好处
> 好处 => 收益
OK!
>> +=============
>> +
>> +KSM可以通过合并相同的页面来节省内存，但也会消耗额外的内存，因为它需要生成一些rmap_items
>> +来保存每个扫描页面的简要rmap信息。其中有些页面可能会被合并，但有些页面在被检查几次
>> +后可能无法被合并，这些都是无益的内存消耗。
>> +
>> +1) 如何确定KSM在全系统范围内是节省内存还是消耗内存？这里有一个简单的近似计算方法供参考::
>> +
>> +       general_profit =~ pages_sharing * sizeof(page) - (all_rmap_items) *
>> +                         sizeof(rmap_item);
>> +
>> +   其中all_rmap_items可以通过对 ``pages_sharing`` 、 ``pages_shared`` 、 ``pages_unshared``
>> +   和 ``pages_volatile`` 的求和而轻松获得。
>> +
>> +2) KSM的好处在一个单一的进程中也可以通过以下近似的计算得到::
> 单一进程中KSM的收益
ok!
>
>> +
>> +       process_profit =~ ksm_merging_pages * sizeof(page) -
>> +                         ksm_rmap_items * sizeof(rmap_item).
>> +
>> +   其中ksm_merging_pages显示在 ``/proc/<pid>/`` 目录下，而ksm_rmap_items
>> +   显示在 ``/proc/<pid>/ksm_stat`` 。
>> +
>> +从应用的角度来看， ``ksm_rmap_items`` 和 ``ksm_merging_pages`` 的高比例意
>> +味着不好的madvise-applied策略，所以开发者或管理员必须重新考虑如何改变madvis策
>> +略。举个例子供参考，一个页面的大小通常是4K，而rmap_item的大小在32位CPU架构上分
>> +别是32B，在64位CPU架构上是64B。所以如果 ``ksm_rmap_items/ksm_merging_pages``
>> +的比例在64位CPU上超过64，或者在32位CPU上超过128，那么应用程序的madvise策略应
>> +该被放弃，因为ksm好处大约为零或负值。
> 好处 => 收益
OK！
>> +
>> +监控KSM事件
>> +===========
>> +
>> +在/proc/vmstat中有一些计数器，可以用来监控KSM事件。KSM可能有助于节省内存，这是
>> +一种权衡，因为它可能会在KSM COW或复制中的交换上遭受延迟。这些事件可以帮助用户评估
>> +是否或如何使用KSM。例如，如果cow_ksm增加得太快，用户可以减少madvise(, , MADV_MERGEABLE)
>> +的范围。
>> +
>> +cow_ksm
>> +        在每次KSM页面触发写时拷贝（COW）时都会被递增，当用户试图写到KSM页面时，
> 写到 => 写入

OK！


Thanks,

Yanteng

>
>> +        我们必须做一个拷贝。
>> +
>> +ksm_swpin_copy
>> +        在换入时，每次KSM页被复制时都会被递增。请注意，KSM页在换入时可能会被复
>> +        制，因为do_swap_page()不能做所有的锁，而需要重组一个跨anon_vma的KSM页。
>> +
>> +--
>> +Izik Eidus,
>> +Hugh Dickins, 2009年11月17日。
>> -- 
>> 2.31.1
>>

Re: [PATCH v1 13/13] docs/zh_CN: Update the translation of energy-model to 6.1-rc8

[Yanteng Si]

在 12/9/22 15:12, Wu XiangCheng 写道:
>> Update to commit c5d39fae8992 ("Documentation: EM: Switch to
>> micro-Watts scale")
>>
>> commit f48a0c475c2a ("Documentation: EM: Describe new registration
>> method using DT")
>> commit 75a3a99a5a98 ("PM: EM: Change the order of arguments in the
>> .active_power() callback")
>> commit 015f569c4649 ("Documentation: EM: Add artificial EM
>> registration description")
>>
>> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
>> ---
>>   .../translations/zh_CN/power/energy-model.rst | 36 ++++++++++++++-----
>>   1 file changed, 28 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/translations/zh_CN/power/energy-model.rst b/Documentation/translations/zh_CN/power/energy-model.rst
>> index c7da1b6aefee..d740bbe22fde 100644
>> --- a/Documentation/translations/zh_CN/power/energy-model.rst
>> +++ b/Documentation/translations/zh_CN/power/energy-model.rst
>> @@ -23,15 +23,15 @@
>>   实现支持，EM框架作为一个抽象层介入，它在内核中对功率成本表的格式进行标准化，
>>   因此能够避免多余的工作。
>>   
>> -功率值可以用毫瓦或“抽象刻度”表示。多个子系统可能使用EM，由系统集成商来检查
>> +功率值可以用微瓦或“抽象刻度”表示。多个子系统可能使用EM，由系统集成商来检查
>>   功率值刻度类型的要求是否满足。可以在能量感知调度器的文档中找到一个例子
>>   Documentation/scheduler/sched-energy.rst。对于一些子系统，比如热能或
>>   powercap，用“抽象刻度”描述功率值可能会导致问题。这些子系统对过去使用的功率的
>> -估算值更感兴趣，因此可能需要真实的毫瓦。这些要求的一个例子可以在智能功率分配
>> +估算值更感兴趣，因此可能需要真实的微瓦。这些要求的一个例子可以在智能功率分配
>>   Documentation/driver-api/thermal/power_allocator.rst文档中找到。
>>   
>>   内核子系统可能（基于EM内部标志位）实现了对EM注册设备是否具有不一致刻度的自动
>> -检查。要记住的重要事情是，当功率值以“抽象刻度”表示时，从中推导以毫焦耳为单位
>> +检查。要记住的重要事情是，当功率值以“抽象刻度”表示时，从中推导以微焦耳为单位
>>   的真实能量消耗是不可能的。
>>   
>>   下图描述了一个驱动的例子（这里是针对Arm的，但该方法适用于任何体系结构），它
>> @@ -89,20 +89,40 @@ Documentation/driver-api/thermal/power_allocator.rst文档中找到。
>>   驱动程序应通过以下API将性能域注册到EM框架中::
>>   
>>     int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
>> -		struct em_data_callback *cb, cpumask_t *cpus, bool milliwatts);
>> +		struct em_data_callback *cb, cpumask_t *cpus, bool microwatts);
>>   
>>   驱动程序必须提供一个回调函数，为每个性能状态返回<频率,功率>元组。驱动程序
>>   提供的回调函数可以自由地从任何相关位置（DT、固件......）以及以任何被认为是
>>   必要的方式获取数据。只有对于CPU设备，驱动程序必须使用cpumask指定性能域的CPU。
>>   对于CPU以外的其他设备，最后一个参数必须被设置为NULL。
>>   
>> -最后一个参数“milliwatts”（毫瓦）设置成正确的值是很重要的，使用EM的内核
>> +最后一个参数“microwatts”（微瓦）设置成正确的值是很重要的，使用EM的内核
>>   子系统可能会依赖这个标志来检查所有的EM设备是否使用相同的刻度。如果有不同的
>> -刻度，这些子系统可能决定：返回警告/错误，停止工作或崩溃（panic）。
>> +刻度，这些子系统可能决定返回警告/错误，停止工作或崩溃（panic）。
>>   
>>   关于实现这个回调函数的驱动程序的例子，参见第3节。或者在第2.4节阅读这个API
>>   的更多文档。
>>   
>> +使用DT EM的注册
> 使用DT的EM注册
OK!
>
>> +===============
>> +
>> +EM也可以使用OPP框架和DT "操作点-v2 "中的信息注册。DT中的每个OPP条目都可
>> +以用一个包含微瓦特功率值的属性 "op-microwatt "来扩展。这个OPP DT属性允
>> +许平台注册反映总功率（静态+动态）的EM功率值。这些功率值可能直接来自实验和
>> +测量。
>> +
>> +“人工”EM的注册
>> +==============
>> +
>> +有一个选项可以为缺少关于每个性能状态的功率值的详细知识的驱动程序提供一个自
>> +定义回调。回调.get_cost()是可选的，它提供EAS使用的“成本”值。这对那些只提
>> +供CPU类型之间相对效率信息的平台很有用，人们可以利用这些信息来创建一个抽象的
>> +功率模型。但是，考虑到输入功率值的大小限制，即使是抽象的功率模型有时也很难装
>> +进去。.get_cost()允许提供反映CPU效率的“成本”值。这将允许提供EAS信息，它
>> +与EM内部计算'成本'值的公式有不同的关系。要为这样的平台注册EM，驱动程序必须
>> +将标志“microwatts”设置为0，提供.get_power()回调和.get_cost()回调。EM
>> +框架会在注册过程中正确处理这样的平台。一个标志EM_PERF_DOMAIN_ARTIFICIAL
>> +被设置为这种平台。其他使用EM的框架应该特别注意测试和正确对待这个标志。
> 这种平台会被设置EM_PERF_DOMAIN_ARTIFICIAL标志。

OK!


Thanks,

Yanteng

>
>> “简单”EM的注册
>> ~~~~~~~~~~~~~~~~
>> @@ -147,8 +167,8 @@ cpufreq_driver::register_em()。这个回调必须为每个特定的驱动程序
>>   
>>     -> drivers/cpufreq/foo_cpufreq.c
>>   
>> -  01	static int est_power(unsigned long *mW, unsigned long *KHz,
>> -  02			struct device *dev)
>> +  01   static int est_power(struct device *dev, unsigned long *mW,
>> +  02                   unsigned long *KHz)
>>     03	{
>>     04		long freq, power;
>>     05
>> -- 
>> 2.31.1
>>

Re: [PATCH v1 06/13] docs/zh_CN: Update the translation of kasan to 6.1-rc8

[Yanteng Si]

在 12/9/22 15:33, Wu XiangCheng 写道:
>> Update to commit cd36d84d2571 ("kasan: allow sampling
>> page_alloc allocations for HW_TAGS")
>>
>> Commit 80b92bfe3bb7 ("kasan: dynamically allocate
>> stack ring entries")
>> Commit 7ebfce331251 ("kasan: support kasan.stacktrace
>> for SW_TAGS")
>> Commit ca89f2a2e66d ("kasan: move boot parameters
>> section in documentation")
>>
>> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
>> ---
>>   .../translations/zh_CN/dev-tools/kasan.rst    | 77 +++++++++++--------
>>   1 file changed, 44 insertions(+), 33 deletions(-)
>>
>> diff --git a/Documentation/translations/zh_CN/dev-tools/kasan.rst b/Documentation/translations/zh_CN/dev-tools/kasan.rst
>> index fe76cbe77ad6..c645b1b6cc53 100644
>> --- a/Documentation/translations/zh_CN/dev-tools/kasan.rst
>> +++ b/Documentation/translations/zh_CN/dev-tools/kasan.rst
>> @@ -90,6 +90,50 @@ KASAN只支持SLUB。
>>   ``CONFIG_STACKTRACE`` 。要包括受影响物理页面的分配和释放堆栈跟踪的话，
>>   请启用 ``CONFIG_PAGE_OWNER`` 并使用 ``page_owner=on`` 进行引导。
>>   
>> +启动参数
>> +~~~~~~~~
>> +
>> +KASAN受到通用 ``panic_on_warn`` 命令行参数的影响。当它被启用时，KASAN
>> +在打印出错误报告后会使内核恐慌。
>> +
>> +默认情况下，KASAN只对第一个无效的内存访问打印错误报告。使用
>> +``kasan_multi_shot``，KASAN对每一个无效的访问都打印一份报告。这有效地
> 有效地 => 会
ok!
>
>> +禁用了KASAN报告的 ``panic_on_warn``。
>> +
>> +另外，独立于 ``panic_on_warn`` 、 ``kasan.fault=`` boot参数可以用
>> +来控制恐慌和报告行为。
>> +
>> +- ``kasan.fault=report`` 或 ``=panic`` 控制是否只打印KASAN报告或
>> +  同时使内核恐慌（默认： ``报告`` ）。即使 ``kasan_multi_shot`` 被
> 报告 => report
OK！
>
>> +  启用，恐慌也会发生。
>> +
>> +基于软件和硬件标签的KASAN模式（见下面关于各种模式的部分）支持改变堆栈跟
>> +踪收集行为：
>> +
>> +- ``kasan.stacktrace=off`` 或 ``=on`` 禁用或启用分配和释放堆栈痕
>> +  迹的收集（默认： ``on`` ）。
>> +
>> +- ``kasan.stack_ring_size=<number of entries>`` 指定堆栈环的条
>> +  目数（默认： ``32768`` ）。
>> +
>> +基于硬件标签的KASAN模式是为了在生产中作为一种安全缓解措施使用。因此，它
>> +支持额外的启动参数，允许完全禁用KASAN或控制其功能。
>> +
>> +- ``kasan=off`` 或 ``=on`` 控制KASAN是否被启用（默认： ``on`` ）。
>> +
>> +- ``kasan.mode=sync``, ``=async`` or ``=asymm`` 控制KASAN是否
>> +  被配置为同步、异步或非对称的执行模式（默认： ``同步`` ）。
>> +  同步模式：当标签检查异常发生时，会立即检测到不良访问。
>> +  异步模式：不良访问的检测是延迟的。当标签检查异常发生时，信息被存储在硬
>> +  件中（对于arm64来说是在TFSR_EL1寄存器中）。内核周期性地检查硬件，并\
>> +  且只在这些检查中报告标签异常。
>> +  非对称模式：读取时同步检测不良访问，写入时异步检测。
>> +
>> +- ``kasan.vmalloc=off`` or ``=on`` 禁用或启用vmalloc分配的标记（默认： ``on`` ）。
>> +
>> +- ``kasan.page_alloc.sample=<sampling frequency>`` 使得KASAN
>> +  只对每N次page_alloc分配进行标记，其中N是参数的值（默认值： ``1`` ）。
> Remove previous paragraph.

OK!


Thanks,

Yanteng

>
>> +
>>   错误报告
>>   ~~~~~~~~
>>   
>> @@ -194,39 +238,6 @@ slab对象的描述以及关于访问的内存页的信息。
>>   通用KASAN还报告两个辅助调用堆栈跟踪。这些堆栈跟踪指向代码中与对象交互但不直接
>>   出现在错误访问堆栈跟踪中的位置。目前，这包括 call_rcu() 和排队的工作队列。
>>   
>> -启动参数
>> -~~~~~~~~
>> -
>> -KASAN受通用 ``panic_on_warn`` 命令行参数的影响。启用该功能后，KASAN在打印错误
>> -报告后会引起内核恐慌。
>> -
>> -默认情况下，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=off`` 或 ``=on`` 控制KASAN是否启用 (默认: ``on`` )。
>> -
>> -- ``kasan.mode=sync`` 、 ``=async`` 或 ``=asymm`` 控制KASAN是否配置
>> -  为同步或异步执行模式(默认:``sync`` )。
>> -  同步模式：当标签检查错误发生时，立即检测到错误访问。
>> -  异步模式：延迟错误访问检测。当标签检查错误发生时，信息存储在硬件中（在arm64的
>> -  TFSR_EL1寄存器中）。内核会定期检查硬件，并且仅在这些检查期间报告标签错误。
>> -  非对称模式：读取时同步检测不良访问，写入时异步检测。
>> -
>> -- ``kasan.vmalloc=off`` 或 ``=on`` 禁用或启用vmalloc分配的标记（默认：``on`` ）。
>> -
>> -- ``kasan.stacktrace=off`` 或 ``=on`` 禁用或启用alloc和free堆栈跟踪收集
>> -  (默认: ``on`` )。
>> -
>> -
>>   实施细则
>>   --------
>>   
>> -- 
>> 2.31.1
>>