[PATCH 0/2] docs/core-api: add memory_hotplug and protection keys translation

[PATCH 0/2] docs/core-api: add memory_hotplug and protection keys translation

[Yanteng Si]

translate core-api/memory-hotplug.rst and core-api/protection-keys.rst into Chinese.

Yanteng Si (2):
  docs/zh_CN: add core api memory_hotplug translation
  docs/zh_CN: add core api protection keys translation

 .../translations/zh_CN/core-api/index.rst     |   2 +-
 .../zh_CN/core-api/memory-hotplug.rst         | 126 ++++++++++++++++++
 .../zh_CN/core-api/protection-keys.rst        |  98 ++++++++++++++
 3 files changed, 225 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/translations/zh_CN/core-api/memory-hotplug.rst
 create mode 100644 Documentation/translations/zh_CN/core-api/protection-keys.rst

-- 
2.27.0

[PATCH 1/2] docs/zh_CN: add core api memory_hotplug translation

[Yanteng Si]

Translate Documentation/core-api/cachetlb.rst into Chinese.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../translations/zh_CN/core-api/index.rst     |   2 +-
 .../zh_CN/core-api/memory-hotplug.rst         | 126 ++++++++++++++++++
 2 files changed, 127 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/translations/zh_CN/core-api/memory-hotplug.rst

diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst
index b4bde9396339..14012c5b0f40 100644
--- a/Documentation/translations/zh_CN/core-api/index.rst
+++ b/Documentation/translations/zh_CN/core-api/index.rst
@@ -80,12 +80,12 @@ Todolist:
    :maxdepth: 1
 
    cachetlb
+   memory-hotplug
 
 Todolist:
 
 
    cpu_hotplug
-   memory-hotplug
    genericirq
    protection-keys
 
diff --git a/Documentation/translations/zh_CN/core-api/memory-hotplug.rst b/Documentation/translations/zh_CN/core-api/memory-hotplug.rst
new file mode 100644
index 000000000000..35bd8f20a1be
--- /dev/null
+++ b/Documentation/translations/zh_CN/core-api/memory-hotplug.rst
@@ -0,0 +1,126 @@
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/core-api/cachetlb.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+:校译:
+
+
+.. _cn_core-api_memory-hotplug:
+.. _memory_hotplug:
+
+==========
+内存热插拔
+==========
+
+内存热拔插事件通知器
+====================
+
+热插拔事件被发送到一个通知队列中。
+
+在 ``include/linux/memory.h`` 中定义了六种类型的通知：
+
+MEM_GOING_ONLINE
+  在新内存可用之前生成，以便能够为子系统处理内存做准备。页面分配器仍然无法从新
+  的内存中进行分配。
+
+MEM_CANCEL_ONLINE
+  如果MEM_GOING_ONLINE失败，则生成。
+
+MEM_ONLINE
+  当内存成功上线时产生。回调可以从新的内存中分配页面。
+
+MEM_GOING_OFFLINE
+  在开始对内存进行下线处理时生成。从内存中的分配不再可能，但是一些要下线的内存
+  仍然在使用。回调可以用来释放一个子系统在指定内存块中已知的内存。
+
+MEM_CANCEL_OFFLINE
+  如果MEM_GOING_OFFLINE失败，则生成。来自我们试图离线的内存块中的内存又可以使
+  用了。
+
+MEM_OFFLINE
+  在下线内存完成后生成。
+
+一个回调程序可以通过调用::
+
+  hotplug_memory_notifier(callback_func, priority)
+
+优先级数值较高的回调函数在数值较低的回调函数之前被调用。
+
+一个回调函数必须有以下原型::
+
+  int callback_func(
+    struct notifier_block *self, unsigned long action, void *arg);
+
+回调函数的第一个参数（self）是指向回调函数本身的通知器链块的一个指针。第二个参
+数（action）是上述的事件类型之一。第三个参数（arg）传递一个指向
+struct memory_notify的指针::
+
+	struct memory_notify {
+		unsigned long start_pfn;
+		unsigned long nr_pages;
+		int status_change_nid_normal;
+		int status_change_nid_high;
+		int status_change_nid;
+	}
+
+- start_pfn是在线/离线内存的start_pfn。
+
+- nr_pages是在线/离线内存的#页数。
+
+- status_change_nid_normal是当nodemask的N_NORMAL_MEMORY被设置/清除时设置节
+  点id，如果是-1，则nodemask状态不改变。
+
+- status_change_nid_high是当nodemask的N_HIGH_MEMORY被设置/清除时设置的节点
+  id，如果这个值为-1，那么nodemask状态不会改变。
+
+- status_change_nid是当nodemask的N_MEMORY被（将）设置/清除时设置的节点id。这
+  意味着一个新的（无记忆的）节点通过联机获得新的内存，而一个节点失去了所有的内
+  存。如果这个值为-1，那么nodemask的状态就不会改变。
+
+  如果 status_changed_nid* >= 0，回调应该在必要时为节点创建/丢弃结构体。
+
+回调例程应返回 ``include/linux/notifier.h`` 中定义的NOTIFY_DONE, NOTIFY_OK,
+NOTIFY_BAD, NOTIFY_STOP中的一个值。
+
+NOTIFY_DONE和NOTIFY_OK对进一步处理没有影响。
+
+NOTIFY_BAD是作为对MEM_GOING_ONLINE、MEM_GOING_OFFLINE、MEM_ONLINE或MEM_OFFLINE
+动作的回应，用于取消热插拔。它停止对通知队列的进一步处理。
+
+NOTIFY_STOP停止对通知队列的进一步处理。
+
+内部锁
+======
+
+当添加/删除使用内存块设备（即普通RAM）的内存时，device_hotplug_lock应该被保持
+为:
+
+- 针对在线/离线请求进行同步（例如，通过sysfs）。这样一来，内存块设备只有在内存
+  被完全添加后才能被用户空间访问（.online/.state属性）。而在删除内存时，我们知
+  道没有人在关键部分。
+
+- 与CPU热插拔和类似的同步（例如，与ACPI和PPC有关）
+
+特别是，在添加内存和用户空间试图以比预期更快的速度联机该内存时，有可能出现锁反转，
+使用device_hotplug_lock可以避免。:
+
+- device_online()将首先接受device_lock()，然后是mem_hotplug_lock。
+
+- add_memory_resource()将首先使用mem_hotplug_lock，然后是device_lock()（在创
+  建设备时，在bus_add_device()期间）。
+
+由于在使用device_lock()之前，设备对用户空间是可见的，这可能导致锁的反转。
+
+内存的上线/下线应该通过device_online()/device_offline()完成--以确保它与通过
+sysfs进行的操作正确同步。建议持有device_hotplug_lock（例如，保护online_type）。
+
+当添加/删除/上线/下线内存或添加/删除异构/设备内存时，我们应该始终持有写模式的
+mem_hotplug_lock，以序列化内存热插拔（例如访问全局/区域变量）。
+
+此外，mem_hotplug_lock（与device_hotplug_lock相反）在读取模式下允许一个相当
+有效的get_online_mems/put_online_mems实现，所以访问内存的代码可以防止该内存
+消失。
-- 
2.27.0

[PATCH 2/2] docs/zh_CN: add core api protection keys translation

[Yanteng Si]

Translate Documentation/core-api/protection-keys.rst into Chinese.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../zh_CN/core-api/protection-keys.rst        | 98 +++++++++++++++++++
 1 file changed, 98 insertions(+)
 create mode 100644 Documentation/translations/zh_CN/core-api/protection-keys.rst

diff --git a/Documentation/translations/zh_CN/core-api/protection-keys.rst b/Documentation/translations/zh_CN/core-api/protection-keys.rst
new file mode 100644
index 000000000000..91a282b9a576
--- /dev/null
+++ b/Documentation/translations/zh_CN/core-api/protection-keys.rst
@@ -0,0 +1,98 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/core-api/protection-keys.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+:校译:
+
+
+.. _cn_core-api_protection-keys:
+
+============
+内存保护密钥
+============
+
+用户空间的内存保护密钥（PKU，又称PKEYs）是英特尔Skylake（及以后）"可扩
+展处理器 "服务器CPU上的一项功能。它将在未来的非服务器英特尔处理器和未来
+的AMD处理器中使用。
+
+对于任何希望测试或使用该功能的人来说，它在亚马逊的EC2 C5实例中是可用的，
+并且已知可以在那里使用Ubuntu 17.04镜像运行。
+
+内存保护密钥提供了一种机制来执行基于页面的保护，但在应用程序改变保护域
+时不需要修改页表。它的工作原理是在每个页表项中为 "保护密钥 "分配4个以
+前被忽略的位，从而提供16个可能的密钥。
+
+还有一个新的用户可访问的寄存器（PKRU），为每个密钥提供两个单独的位（访
+问禁止和写入禁止）。作为一个CPU寄存器，PKRU在本质上是线程本地的，可能
+会给每个线程提供一套不同于其他线程的保护措施。
+
+有两条新指令（RDPKRU/WRPKRU）用于读取和写入新的寄存器。该功能仅在64位
+模式下可用，尽管PAE PTEs中理论上有空间。这些权限只在数据访问上强制执行，
+对指令获取没有影响。
+
+
+系统调用
+========
+
+有3个系统调用可以直接与pkeys进行交互::
+
+	int pkey_alloc(unsigned long flags, unsigned long init_access_rights)
+	int pkey_free(int pkey);
+	int pkey_mprotect(unsigned long start, size_t len,
+			  unsigned long prot, int pkey);
+
+在使用一个pkey之前，必须先用pkey_alloc()分配它。一个应用程序直接调用
+WRPKRU指令，以改变一个密钥覆盖的内存的访问权限。在这个例子中，WRPKRU
+被一个叫做pkey_set()的C函数所封装::
+
+	int real_prot = PROT_READ|PROT_WRITE;
+	pkey = pkey_alloc(0, PKEY_DISABLE_WRITE);
+	ptr = mmap(NULL, PAGE_SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
+	ret = pkey_mprotect(ptr, PAGE_SIZE, real_prot, pkey);
+	... application runs here
+
+现在，如果应用程序需要更新'ptr'处的数据，它可以获得访问权，进行更新，
+然后取消其写访问权::
+
+	pkey_set(pkey, 0); // clear PKEY_DISABLE_WRITE
+	*ptr = foo; // assign something
+	pkey_set(pkey, PKEY_DISABLE_WRITE); // set PKEY_DISABLE_WRITE again
+
+现在，当它释放内存时，它也将释放pkey，因为它不再被使用了::
+
+	munmap(ptr, PAGE_SIZE);
+	pkey_free(pkey);
+
+.. note:: pkey_set()是RDPKRU和WRPKRU指令的一个封装器。在tools/testing/selftests/x86/protection_keys.c中可以找到一个实现实例。
+          tools/testing/selftests/x86/protection_keys.c.
+
+行为
+====
+
+内核试图使保护密钥与普通的protect()的行为一致。例如，如果你这样做::
+
+	mprotect(ptr, size, PROT_NONE);
+	something(ptr);
+
+这样做的时候，你可以期待保护密钥的相同效果::
+
+	pkey = pkey_alloc(0, PKEY_DISABLE_WRITE | PKEY_DISABLE_READ);
+	pkey_mprotect(ptr, size, PROT_READ|PROT_WRITE, pkey);
+	something(ptr);
+
+无论something()是否是对'ptr'的直接访问，这都应该为真。
+如::
+
+	*ptr = foo;
+
+或者当内核代表应用程序进行访问时，比如read()::
+
+	read(fd, ptr, 1);
+
+在这两种情况下，内核都会发送一个SIGSEGV，但当违反保护密钥时，si_code
+将被设置为SEGV_PKERR，而当违反普通的mprotect()权限时，则是SEGV_ACCERR。
-- 
2.27.0

Re: [PATCH 1/2] docs/zh_CN: add core api memory_hotplug translation

[Wu X.C.]

[-- Attachment #1: Type: text/plain, Size: 7217 bytes --]

On Tue, Jun 15, 2021 at 03:52:39PM +0800, Yanteng Si wrote:
> Translate Documentation/core-api/cachetlb.rst into Chinese.
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  .../translations/zh_CN/core-api/index.rst     |   2 +-
>  .../zh_CN/core-api/memory-hotplug.rst         | 126 ++++++++++++++++++
>  2 files changed, 127 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/translations/zh_CN/core-api/memory-hotplug.rst
> 
> diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst
> index b4bde9396339..14012c5b0f40 100644
> --- a/Documentation/translations/zh_CN/core-api/index.rst
> +++ b/Documentation/translations/zh_CN/core-api/index.rst
> @@ -80,12 +80,12 @@ Todolist:
>     :maxdepth: 1
>  
>     cachetlb
> +   memory-hotplug
>  
>  Todolist:
>  
>  
>     cpu_hotplug
> -   memory-hotplug
>     genericirq
>     protection-keys
>  
> diff --git a/Documentation/translations/zh_CN/core-api/memory-hotplug.rst b/Documentation/translations/zh_CN/core-api/memory-hotplug.rst
> new file mode 100644
> index 000000000000..35bd8f20a1be
> --- /dev/null
> +++ b/Documentation/translations/zh_CN/core-api/memory-hotplug.rst
> @@ -0,0 +1,126 @@
> +.. include:: ../disclaimer-zh_CN.rst
> +
> +:Original: Documentation/core-api/cachetlb.rst
> +
> +:翻译:
> +
> + 司延腾 Yanteng Si <siyanteng@loongson.cn>
> +
> +:校译:
> +
> +
> +.. _cn_core-api_memory-hotplug:
> +.. _memory_hotplug:
       ^^^^^^^^^^^^^^
       two tags, remove the 2nd tag

> +
> +==========
> +内存热插拔
> +==========
> +
> +内存热拔插事件通知器
> +====================
> +
> +热插拔事件被发送到一个通知队列中。
> +
> +在 ``include/linux/memory.h`` 中定义了六种类型的通知：
> +
> +MEM_GOING_ONLINE
> +  在新内存可用之前生成，以便能够为子系统处理内存做准备。页面分配器仍然无法从新
> +  的内存中进行分配。
> +
> +MEM_CANCEL_ONLINE
> +  如果MEM_GOING_ONLINE失败，则生成。
> +
> +MEM_ONLINE
> +  当内存成功上线时产生。回调可以从新的内存中分配页面。
> +
> +MEM_GOING_OFFLINE
> +  在开始对内存进行下线处理时生成。从内存中的分配不再可能，但是一些要下线的内存
> +  仍然在使用。回调可以用来释放一个子系统在指定内存块中已知的内存。
> +
> +MEM_CANCEL_OFFLINE
> +  如果MEM_GOING_OFFLINE失败，则生成。来自我们试图离线的内存块中的内存又可以使
> +  用了。
> +
> +MEM_OFFLINE
> +  在下线内存完成后生成。

内存下线完成 ？

> +
> +一个回调程序可以通过调用::

be registered by calling:
可以通过调用如下函数来注册一个回调程序::

> +
> +  hotplug_memory_notifier(callback_func, priority)
> +
> +优先级数值较高的回调函数在数值较低的回调函数之前被调用。
> +
> +一个回调函数必须有以下原型::
> +
> +  int callback_func(
> +    struct notifier_block *self, unsigned long action, void *arg);
> +
> +回调函数的第一个参数（self）是指向回调函数本身的通知器链块的一个指针。第二个参
> +数（action）是上述的事件类型之一。第三个参数（arg）传递一个指向
> +struct memory_notify的指针::
   ^^^^^^^
   memory_notify结构体

> +
> +	struct memory_notify {
> +		unsigned long start_pfn;
> +		unsigned long nr_pages;
> +		int status_change_nid_normal;
> +		int status_change_nid_high;
> +		int status_change_nid;
> +	}
> +
> +- start_pfn是在线/离线内存的start_pfn。
> +
> +- nr_pages是在线/离线内存的#页数。

# of pages = number of pages
remove #

> +
> +- status_change_nid_normal是当nodemask的N_NORMAL_MEMORY被设置/清除时设置节
> +  点id，如果是-1，则nodemask状态不改变。
> +
> +- status_change_nid_high是当nodemask的N_HIGH_MEMORY被设置/清除时设置的节点
> +  id，如果这个值为-1，那么nodemask状态不会改变。
> +
> +- status_change_nid是当nodemask的N_MEMORY被（将）设置/清除时设置的节点id。这
> +  意味着一个新的（无记忆的）节点通过联机获得新的内存，而一个节点失去了所有的内
                                       ^^^^
                                       上线 ？

> +  存。如果这个值为-1，那么nodemask的状态就不会改变。
> +
> +  如果 status_changed_nid* >= 0，回调应该在必要时为节点创建/丢弃结构体。
> +
> +回调例程应返回 ``include/linux/notifier.h`` 中定义的NOTIFY_DONE, NOTIFY_OK,

s/例程/程序/

> +NOTIFY_BAD, NOTIFY_STOP中的一个值。
> +
> +NOTIFY_DONE和NOTIFY_OK对进一步处理没有影响。
> +
> +NOTIFY_BAD是作为对MEM_GOING_ONLINE、MEM_GOING_OFFLINE、MEM_ONLINE或MEM_OFFLINE
> +动作的回应，用于取消热插拔。它停止对通知队列的进一步处理。
> +
> +NOTIFY_STOP停止对通知队列的进一步处理。
> +
> +内部锁
> +======
> +
> +当添加/删除使用内存块设备（即普通RAM）的内存时，device_hotplug_lock应该被保持
> +为:
> +
> +- 针对在线/离线请求进行同步（例如，通过sysfs）。这样一来，内存块设备只有在内存
> +  被完全添加后才能被用户空间访问（.online/.state属性）。而在删除内存时，我们知
> +  道没有人在关键部分。

s/关键部分/临界区/

> +
> +- 与CPU热插拔和类似的同步（例如，与ACPI和PPC有关）

与CPU热拔插或类似操作同步（例如ACPI和PPC相关操作）

> +
> +特别是，在添加内存和用户空间试图以比预期更快的速度联机该内存时，有可能出现锁反转，
                                                     ^^^^

> +使用device_hotplug_lock可以避免。:

remove 。
可以避免此情况

> +
> +- device_online()将首先接受device_lock()，然后是mem_hotplug_lock。
> +
> +- add_memory_resource()将首先使用mem_hotplug_lock，然后是device_lock()（在创
> +  建设备时，在bus_add_device()期间）。
> +
> +由于在使用device_lock()之前，设备对用户空间是可见的，这可能导致锁的反转。
> +
> +内存的上线/下线应该通过device_online()/device_offline()完成--以确保它与通过
                                                              ^^
——

> +sysfs进行的操作正确同步。建议持有device_hotplug_lock（例如，保护online_type）。
> +
> +当添加/删除/上线/下线内存或添加/删除异构/设备内存时，我们应该始终持有写模式的
                            |         |        |
或者添加/删除异构或设备内存

> +mem_hotplug_lock，以序列化内存热插拔（例如访问全局/区域变量）。
> +
> +此外，mem_hotplug_lock（与device_hotplug_lock相反）在读取模式下允许一个相当
> +有效的get_online_mems/put_online_mems实现，所以访问内存的代码可以防止该内存
> +消失。
> -- 
> 2.27.0

Thanks,
        Wu X.C.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 1/2] docs/zh_CN: add core api memory_hotplug translation

[yanteng si]

Wu X.C. <bobwxc@email.cn> 于2021年6月17日周四 下午3:48写道：
>
> On Tue, Jun 15, 2021 at 03:52:39PM +0800, Yanteng Si wrote:
> > Translate Documentation/core-api/cachetlb.rst into Chinese.
> >
> > Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> > ---
> >  .../translations/zh_CN/core-api/index.rst     |   2 +-
> >  .../zh_CN/core-api/memory-hotplug.rst         | 126 ++++++++++++++++++
> >  2 files changed, 127 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/translations/zh_CN/core-api/memory-hotplug.rst
> >
> > diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst
> > index b4bde9396339..14012c5b0f40 100644
> > --- a/Documentation/translations/zh_CN/core-api/index.rst
> > +++ b/Documentation/translations/zh_CN/core-api/index.rst
> > @@ -80,12 +80,12 @@ Todolist:
> >     :maxdepth: 1
> >
> >     cachetlb
> > +   memory-hotplug
> >
> >  Todolist:
> >
> >
> >     cpu_hotplug
> > -   memory-hotplug
> >     genericirq
> >     protection-keys
> >
> > diff --git a/Documentation/translations/zh_CN/core-api/memory-hotplug.rst b/Documentation/translations/zh_CN/core-api/memory-hotplug.rst
> > new file mode 100644
> > index 000000000000..35bd8f20a1be
> > --- /dev/null
> > +++ b/Documentation/translations/zh_CN/core-api/memory-hotplug.rst
> > @@ -0,0 +1,126 @@
> > +.. include:: ../disclaimer-zh_CN.rst
> > +
> > +:Original: Documentation/core-api/cachetlb.rst
> > +
> > +:翻译:
> > +
> > + 司延腾 Yanteng Si <siyanteng@loongson.cn>
> > +
> > +:校译:
> > +
> > +
> > +.. _cn_core-api_memory-hotplug:
> > +.. _memory_hotplug:
>        ^^^^^^^^^^^^^^
>        two tags, remove the 2nd tag
- .. _memory_hotplug:
>
> > +
> > +==========
> > +内存热插拔
> > +==========
> > +
> > +内存热拔插事件通知器
> > +====================
> > +
> > +热插拔事件被发送到一个通知队列中。
> > +
> > +在 ``include/linux/memory.h`` 中定义了六种类型的通知：
> > +
> > +MEM_GOING_ONLINE
> > +  在新内存可用之前生成，以便能够为子系统处理内存做准备。页面分配器仍然无法从新
> > +  的内存中进行分配。
> > +
> > +MEM_CANCEL_ONLINE
> > +  如果MEM_GOING_ONLINE失败，则生成。
> > +
> > +MEM_ONLINE
> > +  当内存成功上线时产生。回调可以从新的内存中分配页面。
> > +
> > +MEM_GOING_OFFLINE
> > +  在开始对内存进行下线处理时生成。从内存中的分配不再可能，但是一些要下线的内存
> > +  仍然在使用。回调可以用来释放一个子系统在指定内存块中已知的内存。
> > +
> > +MEM_CANCEL_OFFLINE
> > +  如果MEM_GOING_OFFLINE失败，则生成。来自我们试图离线的内存块中的内存又可以使
> > +  用了。
> > +
> > +MEM_OFFLINE
> > +  在下线内存完成后生成。
>
> 内存下线完成 ？
ok！
>
> > +
> > +一个回调程序可以通过调用::
>
> be registered by calling:
> 可以通过调用如下函数来注册一个回调程序::
ok!
>
> > +
> > +  hotplug_memory_notifier(callback_func, priority)
> > +
> > +优先级数值较高的回调函数在数值较低的回调函数之前被调用。
> > +
> > +一个回调函数必须有以下原型::
> > +
> > +  int callback_func(
> > +    struct notifier_block *self, unsigned long action, void *arg);
> > +
> > +回调函数的第一个参数（self）是指向回调函数本身的通知器链块的一个指针。第二个参
> > +数（action）是上述的事件类型之一。第三个参数（arg）传递一个指向
> > +struct memory_notify的指针::
>    ^^^^^^^
>    memory_notify结构体
ok!
>
> > +
> > +     struct memory_notify {
> > +             unsigned long start_pfn;
> > +             unsigned long nr_pages;
> > +             int status_change_nid_normal;
> > +             int status_change_nid_high;
> > +             int status_change_nid;
> > +     }
> > +
> > +- start_pfn是在线/离线内存的start_pfn。
> > +
> > +- nr_pages是在线/离线内存的#页数。
>
> # of pages = number of pages
> remove #
ok,removed.
>
> > +
> > +- status_change_nid_normal是当nodemask的N_NORMAL_MEMORY被设置/清除时设置节
> > +  点id，如果是-1，则nodemask状态不改变。
> > +
> > +- status_change_nid_high是当nodemask的N_HIGH_MEMORY被设置/清除时设置的节点
> > +  id，如果这个值为-1，那么nodemask状态不会改变。
> > +
> > +- status_change_nid是当nodemask的N_MEMORY被（将）设置/清除时设置的节点id。这
> > +  意味着一个新的（无记忆的）节点通过联机获得新的内存，而一个节点失去了所有的内
>                                        ^^^^
>                                        上线 ？
emmmm,ok!
没上线的
>
> > +  存。如果这个值为-1，那么nodemask的状态就不会改变。
> > +
> > +  如果 status_changed_nid* >= 0，回调应该在必要时为节点创建/丢弃结构体。
> > +
> > +回调例程应返回 ``include/linux/notifier.h`` 中定义的NOTIFY_DONE, NOTIFY_OK,
>
> s/例程/程序/
ok!
>
> > +NOTIFY_BAD, NOTIFY_STOP中的一个值。
> > +
> > +NOTIFY_DONE和NOTIFY_OK对进一步处理没有影响。
> > +
> > +NOTIFY_BAD是作为对MEM_GOING_ONLINE、MEM_GOING_OFFLINE、MEM_ONLINE或MEM_OFFLINE
> > +动作的回应，用于取消热插拔。它停止对通知队列的进一步处理。
> > +
> > +NOTIFY_STOP停止对通知队列的进一步处理。
> > +
> > +内部锁
> > +======
> > +
> > +当添加/删除使用内存块设备（即普通RAM）的内存时，device_hotplug_lock应该被保持
> > +为:
> > +
> > +- 针对在线/离线请求进行同步（例如，通过sysfs）。这样一来，内存块设备只有在内存
> > +  被完全添加后才能被用户空间访问（.online/.state属性）。而在删除内存时，我们知
> > +  道没有人在关键部分。
>
> s/关键部分/临界区/
ok!
>
> > +
> > +- 与CPU热插拔和类似的同步（例如，与ACPI和PPC有关）
>
> 与CPU热拔插或类似操作同步（例如ACPI和PPC相关操作）
ok!
>
> > +
> > +特别是，在添加内存和用户空间试图以比预期更快的速度联机该内存时，有可能出现锁反转，
上线
>                                                      ^^^^
>
> > +使用device_hotplug_lock可以避免。:
>
> remove 。
> 可以避免此情况
>
> > +
> > +- device_online()将首先接受device_lock()，然后是mem_hotplug_lock。
> > +
> > +- add_memory_resource()将首先使用mem_hotplug_lock，然后是device_lock()（在创
> > +  建设备时，在bus_add_device()期间）。
> > +
> > +由于在使用device_lock()之前，设备对用户空间是可见的，这可能导致锁的反转。
> > +
> > +内存的上线/下线应该通过device_online()/device_offline()完成--以确保它与通过
>                                                               ^^
> ——
ok!
>
> > +sysfs进行的操作正确同步。建议持有device_hotplug_lock（例如，保护online_type）。
> > +
> > +当添加/删除/上线/下线内存或添加/删除异构/设备内存时，我们应该始终持有写模式的
>                             |         |        |
> 或者添加/删除异构或设备内存
great!
>
> > +mem_hotplug_lock，以序列化内存热插拔（例如访问全局/区域变量）。
> > +
> > +此外，mem_hotplug_lock（与device_hotplug_lock相反）在读取模式下允许一个相当
> > +有效的get_online_mems/put_online_mems实现，所以访问内存的代码可以防止该内存
> > +消失。
> > --
> > 2.27.0
>
> Thanks,
>         Wu X.C.

Thanks you for your review!

Thanks,

Yanteng

Re: [PATCH 2/2] docs/zh_CN: add core api protection keys translation

[Wu X.C.]

[-- Attachment #1: Type: text/plain, Size: 5195 bytes --]

On Tue, Jun 15, 2021 at 03:52:40PM +0800, Yanteng Si wrote:
> Translate Documentation/core-api/protection-keys.rst into Chinese.
> 
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  .../zh_CN/core-api/protection-keys.rst        | 98 +++++++++++++++++++
>  1 file changed, 98 insertions(+)
>  create mode 100644 Documentation/translations/zh_CN/core-api/protection-keys.rst
> 
> diff --git a/Documentation/translations/zh_CN/core-api/protection-keys.rst b/Documentation/translations/zh_CN/core-api/protection-keys.rst
> new file mode 100644
> index 000000000000..91a282b9a576
> --- /dev/null
> +++ b/Documentation/translations/zh_CN/core-api/protection-keys.rst
> @@ -0,0 +1,98 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +.. include:: ../disclaimer-zh_CN.rst
> +
> +:Original: Documentation/core-api/protection-keys.rst
> +
> +:翻译:
> +
> + 司延腾 Yanteng Si <siyanteng@loongson.cn>
> +
> +:校译:
> +
> +
> +.. _cn_core-api_protection-keys:
> +
> +============
> +内存保护密钥
> +============
> +
> +用户空间的内存保护密钥（PKU，又称PKEYs）是英特尔Skylake（及以后）"可扩
                                                                    ^
（Memory Protection Keys for Userspace，PKU，亦即PKEYs）

> +展处理器 "服务器CPU上的一项功能。它将在未来的非服务器英特尔处理器和未来
           ^^
           “”

> +的AMD处理器中使用。

s/使用/可用/

> +
> +对于任何希望测试或使用该功能的人来说，它在亚马逊的EC2 C5实例中是可用的，
> +并且已知可以在那里使用Ubuntu 17.04镜像运行。
> +
> +内存保护密钥提供了一种机制来执行基于页面的保护，但在应用程序改变保护域
> +时不需要修改页表。它的工作原理是在每个页表项中为 "保护密钥 "分配4个以
                                                   ^^        ^^

> +前被忽略的位，从而提供16个可能的密钥。
> +
> +还有一个新的用户可访问的寄存器（PKRU），为每个密钥提供两个单独的位（访
                         ^^
                         remove 的
                         断句歧义

> +问禁止和写入禁止）。作为一个CPU寄存器，PKRU在本质上是线程本地的，可能
> +会给每个线程提供一套不同于其他线程的保护措施。
> +
> +有两条新指令（RDPKRU/WRPKRU）用于读取和写入新的寄存器。该功能仅在64位
> +模式下可用，尽管PAE PTEs中理论上有空间。这些权限只在数据访问上强制执行，
> +对指令获取没有影响。

s/PAE PTEs/物理地址扩展页表/ ？

> +
> +
> +系统调用
> +========
> +
> +有3个系统调用可以直接与pkeys进行交互::
> +
> +	int pkey_alloc(unsigned long flags, unsigned long init_access_rights)
> +	int pkey_free(int pkey);
> +	int pkey_mprotect(unsigned long start, size_t len,
> +			  unsigned long prot, int pkey);
> +
> +在使用一个pkey之前，必须先用pkey_alloc()分配它。一个应用程序直接调用
> +WRPKRU指令，以改变一个密钥覆盖的内存的访问权限。在这个例子中，WRPKRU
> +被一个叫做pkey_set()的C函数所封装::
> +
> +	int real_prot = PROT_READ|PROT_WRITE;
> +	pkey = pkey_alloc(0, PKEY_DISABLE_WRITE);
> +	ptr = mmap(NULL, PAGE_SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
> +	ret = pkey_mprotect(ptr, PAGE_SIZE, real_prot, pkey);
> +	... application runs here
> +
> +现在，如果应用程序需要更新'ptr'处的数据，它可以获得访问权，进行更新，
> +然后取消其写访问权::
> +
> +	pkey_set(pkey, 0); // clear PKEY_DISABLE_WRITE
> +	*ptr = foo; // assign something
> +	pkey_set(pkey, PKEY_DISABLE_WRITE); // set PKEY_DISABLE_WRITE again
> +
> +现在，当它释放内存时，它也将释放pkey，因为它不再被使用了::
> +
> +	munmap(ptr, PAGE_SIZE);
> +	pkey_free(pkey);
> +
> +.. note:: pkey_set()是RDPKRU和WRPKRU指令的一个封装器。在tools/testing/selftests/x86/protection_keys.c中可以找到一个实现实例。
> +          tools/testing/selftests/x86/protection_keys.c.
> +
> +行为
> +====
> +
> +内核试图使保护密钥与普通的protect()的行为一致。例如，如果你这样做::
                             ^^^^^^^^^
                             mprotect()

> +
> +	mprotect(ptr, size, PROT_NONE);
> +	something(ptr);
> +
> +这样做的时候，你可以期待保护密钥的相同效果::
> +
> +	pkey = pkey_alloc(0, PKEY_DISABLE_WRITE | PKEY_DISABLE_READ);
> +	pkey_mprotect(ptr, size, PROT_READ|PROT_WRITE, pkey);
> +	something(ptr);
> +
> +无论something()是否是对'ptr'的直接访问，这都应该为真。
> +如::
> +
> +	*ptr = foo;
> +
> +或者当内核代表应用程序进行访问时，比如read()::
> +
> +	read(fd, ptr, 1);
> +
> +在这两种情况下，内核都会发送一个SIGSEGV，但当违反保护密钥时，si_code
> +将被设置为SEGV_PKERR，而当违反普通的mprotect()权限时，则是SEGV_ACCERR。
> -- 
> 2.27.0

Thanks,
        Wu X.C.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 2/2] docs/zh_CN: add core api protection keys translation

[yanteng si]

Wu X.C. <bobwxc@email.cn> 于2021年6月20日周日 下午12:33写道：
>
> On Tue, Jun 15, 2021 at 03:52:40PM +0800, Yanteng Si wrote:
> > Translate Documentation/core-api/protection-keys.rst into Chinese.
> >
> > Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> > ---
> >  .../zh_CN/core-api/protection-keys.rst        | 98 +++++++++++++++++++
> >  1 file changed, 98 insertions(+)
> >  create mode 100644 Documentation/translations/zh_CN/core-api/protection-keys.rst
> >
> > diff --git a/Documentation/translations/zh_CN/core-api/protection-keys.rst b/Documentation/translations/zh_CN/core-api/protection-keys.rst
> > new file mode 100644
> > index 000000000000..91a282b9a576
> > --- /dev/null
> > +++ b/Documentation/translations/zh_CN/core-api/protection-keys.rst
> > @@ -0,0 +1,98 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +.. include:: ../disclaimer-zh_CN.rst
> > +
> > +:Original: Documentation/core-api/protection-keys.rst
> > +
> > +:翻译:
> > +
> > + 司延腾 Yanteng Si <siyanteng@loongson.cn>
> > +
> > +:校译:
> > +
> > +
> > +.. _cn_core-api_protection-keys:
> > +
> > +============
> > +内存保护密钥
> > +============
> > +
> > +用户空间的内存保护密钥（PKU，又称PKEYs）是英特尔Skylake（及以后）"可扩
>                                                                     ^
> （Memory Protection Keys for Userspace，PKU，亦即PKEYs）
ok
>
> > +展处理器 "服务器CPU上的一项功能。它将在未来的非服务器英特尔处理器和未来
>            ^^
>            “”
ok
>
> > +的AMD处理器中使用。
>
> s/使用/可用/
ok
>
> > +
> > +对于任何希望测试或使用该功能的人来说，它在亚马逊的EC2 C5实例中是可用的，
> > +并且已知可以在那里使用Ubuntu 17.04镜像运行。
> > +
> > +内存保护密钥提供了一种机制来执行基于页面的保护，但在应用程序改变保护域
> > +时不需要修改页表。它的工作原理是在每个页表项中为 "保护密钥 "分配4个以
>                                                    ^^        ^^
ok
>
> > +前被忽略的位，从而提供16个可能的密钥。
> > +
> > +还有一个新的用户可访问的寄存器（PKRU），为每个密钥提供两个单独的位（访
>                          ^^
>                          remove 的
>                          断句歧义
ok,removed
>
> > +问禁止和写入禁止）。作为一个CPU寄存器，PKRU在本质上是线程本地的，可能
> > +会给每个线程提供一套不同于其他线程的保护措施。
> > +
> > +有两条新指令（RDPKRU/WRPKRU）用于读取和写入新的寄存器。该功能仅在64位
> > +模式下可用，尽管PAE PTEs中理论上有空间。这些权限只在数据访问上强制执行，
> > +对指令获取没有影响。
>
> s/PAE PTEs/物理地址扩展页表/ ？
ok
>
> > +
> > +
> > +系统调用
> > +========
> > +
> > +有3个系统调用可以直接与pkeys进行交互::
> > +
> > +     int pkey_alloc(unsigned long flags, unsigned long init_access_rights)
> > +     int pkey_free(int pkey);
> > +     int pkey_mprotect(unsigned long start, size_t len,
> > +                       unsigned long prot, int pkey);
> > +
> > +在使用一个pkey之前，必须先用pkey_alloc()分配它。一个应用程序直接调用
> > +WRPKRU指令，以改变一个密钥覆盖的内存的访问权限。在这个例子中，WRPKRU
> > +被一个叫做pkey_set()的C函数所封装::
> > +
> > +     int real_prot = PROT_READ|PROT_WRITE;
> > +     pkey = pkey_alloc(0, PKEY_DISABLE_WRITE);
> > +     ptr = mmap(NULL, PAGE_SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
> > +     ret = pkey_mprotect(ptr, PAGE_SIZE, real_prot, pkey);
> > +     ... application runs here
> > +
> > +现在，如果应用程序需要更新'ptr'处的数据，它可以获得访问权，进行更新，
> > +然后取消其写访问权::
> > +
> > +     pkey_set(pkey, 0); // clear PKEY_DISABLE_WRITE
> > +     *ptr = foo; // assign something
> > +     pkey_set(pkey, PKEY_DISABLE_WRITE); // set PKEY_DISABLE_WRITE again
> > +
> > +现在，当它释放内存时，它也将释放pkey，因为它不再被使用了::
> > +
> > +     munmap(ptr, PAGE_SIZE);
> > +     pkey_free(pkey);
> > +
> > +.. note:: pkey_set()是RDPKRU和WRPKRU指令的一个封装器。在tools/testing/selftests/x86/protection_keys.c中可以找到一个实现实例。
> > +          tools/testing/selftests/x86/protection_keys.c.
> > +
> > +行为
> > +====
> > +
> > +内核试图使保护密钥与普通的protect()的行为一致。例如，如果你这样做::
>                              ^^^^^^^^^
>
ok,
>
> > +
> > +     mprotect(ptr, size, PROT_NONE);
> > +     something(ptr);
> > +
> > +这样做的时候，你可以期待保护密钥的相同效果::
> > +
> > +     pkey = pkey_alloc(0, PKEY_DISABLE_WRITE | PKEY_DISABLE_READ);
> > +     pkey_mprotect(ptr, size, PROT_READ|PROT_WRITE, pkey);
> > +     something(ptr);
> > +
> > +无论something()是否是对'ptr'的直接访问，这都应该为真。
> > +如::
> > +
> > +     *ptr = foo;
> > +
> > +或者当内核代表应用程序进行访问时，比如read()::
> > +
> > +     read(fd, ptr, 1);
> > +
> > +在这两种情况下，内核都会发送一个SIGSEGV，但当违反保护密钥时，si_code
> > +将被设置为SEGV_PKERR，而当违反普通的mprotect()权限时，则是SEGV_ACCERR。
> > --
> > 2.27.0
>
> Thanks,
>         Wu X.C.
Thanks you for your review!

Thanks,

Yanteng