* [PATCH 0/2] docs/core-api: add memory_hotplug and protection keys translation
@ 2021-06-15 7:52 Yanteng Si
2021-06-15 7:52 ` [PATCH 1/2] docs/zh_CN: add core api memory_hotplug translation Yanteng Si
2021-06-15 7:52 ` [PATCH 2/2] docs/zh_CN: add core api protection keys translation Yanteng Si
0 siblings, 2 replies; 7+ messages in thread
From: Yanteng Si @ 2021-06-15 7:52 UTC (permalink / raw
To: corbet, alexs, bobwxc, seakeel
Cc: Yanteng Si, chenhuacai, jiaxun.yang, linux-doc, realpuyuwang,
siyanteng01
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 1/2] docs/zh_CN: add core api memory_hotplug translation
2021-06-15 7:52 [PATCH 0/2] docs/core-api: add memory_hotplug and protection keys translation Yanteng Si
@ 2021-06-15 7:52 ` Yanteng Si
2021-06-17 7:48 ` Wu X.C.
2021-06-15 7:52 ` [PATCH 2/2] docs/zh_CN: add core api protection keys translation Yanteng Si
1 sibling, 1 reply; 7+ messages in thread
From: Yanteng Si @ 2021-06-15 7:52 UTC (permalink / raw
To: corbet, alexs, bobwxc, seakeel
Cc: Yanteng Si, chenhuacai, jiaxun.yang, linux-doc, realpuyuwang,
siyanteng01
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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH 2/2] docs/zh_CN: add core api protection keys translation
2021-06-15 7:52 [PATCH 0/2] docs/core-api: add memory_hotplug and protection keys translation Yanteng Si
2021-06-15 7:52 ` [PATCH 1/2] docs/zh_CN: add core api memory_hotplug translation Yanteng Si
@ 2021-06-15 7:52 ` Yanteng Si
2021-06-20 4:33 ` Wu X.C.
1 sibling, 1 reply; 7+ messages in thread
From: Yanteng Si @ 2021-06-15 7:52 UTC (permalink / raw
To: corbet, alexs, bobwxc, seakeel
Cc: Yanteng Si, chenhuacai, jiaxun.yang, linux-doc, realpuyuwang,
siyanteng01
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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] docs/zh_CN: add core api memory_hotplug translation
2021-06-15 7:52 ` [PATCH 1/2] docs/zh_CN: add core api memory_hotplug translation Yanteng Si
@ 2021-06-17 7:48 ` Wu X.C.
2021-06-19 2:07 ` yanteng si
0 siblings, 1 reply; 7+ messages in thread
From: Wu X.C. @ 2021-06-17 7:48 UTC (permalink / raw
To: Yanteng Si
Cc: corbet, alexs, seakeel, chenhuacai, jiaxun.yang, linux-doc,
realpuyuwang, siyanteng01
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] docs/zh_CN: add core api memory_hotplug translation
2021-06-17 7:48 ` Wu X.C.
@ 2021-06-19 2:07 ` yanteng si
0 siblings, 0 replies; 7+ messages in thread
From: yanteng si @ 2021-06-19 2:07 UTC (permalink / raw
To: Wu X.C.
Cc: Yanteng Si, Jonathan Corbet, Alex Shi, Alex Shi, Huacai Chen,
Jiaxun Yang, linux-doc, Puyu Wang
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] docs/zh_CN: add core api protection keys translation
2021-06-15 7:52 ` [PATCH 2/2] docs/zh_CN: add core api protection keys translation Yanteng Si
@ 2021-06-20 4:33 ` Wu X.C.
2021-06-22 13:47 ` yanteng si
0 siblings, 1 reply; 7+ messages in thread
From: Wu X.C. @ 2021-06-20 4:33 UTC (permalink / raw
To: Yanteng Si
Cc: corbet, alexs, seakeel, chenhuacai, jiaxun.yang, linux-doc,
realpuyuwang, siyanteng01
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] docs/zh_CN: add core api protection keys translation
2021-06-20 4:33 ` Wu X.C.
@ 2021-06-22 13:47 ` yanteng si
0 siblings, 0 replies; 7+ messages in thread
From: yanteng si @ 2021-06-22 13:47 UTC (permalink / raw
To: Wu X.C.
Cc: Yanteng Si, Jonathan Corbet, Alex Shi, Alex Shi, Huacai Chen,
Jiaxun Yang, linux-doc, Puyu Wang
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-06-22 13:48 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-06-15 7:52 [PATCH 0/2] docs/core-api: add memory_hotplug and protection keys translation Yanteng Si
2021-06-15 7:52 ` [PATCH 1/2] docs/zh_CN: add core api memory_hotplug translation Yanteng Si
2021-06-17 7:48 ` Wu X.C.
2021-06-19 2:07 ` yanteng si
2021-06-15 7:52 ` [PATCH 2/2] docs/zh_CN: add core api protection keys translation Yanteng Si
2021-06-20 4:33 ` Wu X.C.
2021-06-22 13:47 ` yanteng si
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.