LinuxNews搬运工-CSDN博客

转载 LWN：FDP——更加自由的数据放置！

如果存在一个数据创建者，以及数据创建者与设备之间的多个层（例如，filesystem，即文件系统、device mapper，即设备映射器），那么最终决定数据去向的是最接近设备的那一层。Busch 说，可以使用的测量指标是来自硬盘的 write amplification 信息以及 p99 latency（p99 延迟），当生命周期相似的数据得到正确分组时，这两者都应该会降低。Busch 说，根据具有相似写入到丢弃（或覆盖）时间特性的操作对数据进行分组，并为其提供不同的 tag，将会产生影响。

2025-05-19 13:52:30 114

转载 LWN：提高 FUSE writeback 性能！

在 2025 年 Linux 存储、文件系统、内存管理和 BPF 峰会 (LSFMM+BPF) 上的一次文件系统 (filesystem) 和内存管理 (memory-management) 联合会议上，Joanne Koong 主持了一场关于改进用户空间文件系统 (Filesystem in Userspace - FUSE) 层回写 (writeback) 性能的讨论。她说，问题在于页可能已经被 spliced (spliced)，对于这些页，回写是无法取消的。“你不够值得信赖，不能让你这么做”。

2025-05-15 13:16:15 196

转载 LWN：suspend 时冻结文件系统！

例如，Fstests（文件系统测试套件）就不测试恢复操作。在第一场会话中，大家一致认为，尝试按超级块的反向顺序冻结文件系统是有意义的，这样每一层更接近存储层（storage）的文件系统仍然保持活跃，以便能刷写（flush）数据。大家讨论了冻结文件系统的顺序，包括各种可能的死锁问题，但大多数有问题的用例已经得到解决，或者正在从内核（kernel）中移除。这些设备可能存在脏数据（dirty data），但当这些数据被刷写时，底层的那个文件系统会被冻结，因为块设备是在文件系统之后冻结的，因此会发生死锁。

2025-05-14 13:32:52 231

转载 LWN：优化kernel内联函数调试信息！

因此，例如，一个存储在由寄存器指向的结构体 (structure) 成员中的参数，将表示为类似 "加载寄存器，添加偏移量，解引用，结束" 的序列。在 150,000 个不同的调用点上，内联函数的 228,000 个参数中，大约 83% 的位置可以表示为寄存器 (register) 的偏移量 (offset)，通常是因为该参数存在于调用函数的栈 (stack) 上，或者作为指针 (pointer) 传递。在每个调用点都被内联的函数，比选择性内联函数造成的困惑要少，但支持它们会相当简单。

2025-05-13 13:29:30 240

转载 LWN：让 CPU 调度器考虑 Cache！

最后一级缓存（LLC）（Last-Level Cache），离 CPU 最远，因此也是最慢的，但它往往是最大的，并且被最大数量的 CPU 共享。检测没有这种直接关系的任务中的缓存共享可能是困难的，如果它可能的话。如果感兴趣的线程一直在其他地方运行，它将被移动到所选的 CPU，在那里它将更接近其他线程，并且如果运气好，可以从与它们共享缓存空间中获益。因此，添加另一个启发式方法（“将进程的线程集中在单个缓存域中”）的补丁系列肯定会带来更多令人惊讶的交互，这些交互可能需要用更多的启发式方法来解决。

2025-05-12 13:17:37 273

转载 LWN：UIO驱动的DMA地址！

他后来补充说，该提案“从根本上说是错误的且不安全的”，并且，如果他建议的方法不起作用，则唯一的选择是编写完整的内核驱动程序。当然，如果不破坏未知数量的现有驱动程序，就无法删除 UIO，但是可以将其冻结，目的是减少将来编写的使用 UIO 接口的驱动程序的数量。但是，拒绝新的 UIO 功能的真正结果似乎很可能是将这些功能推入到一组（可能更危险的）特定于驱动程序的 hacks 中，正如 DMA 地址显然已经在发生的那样。该系列还添加了一个新的 dma-buf 堆模块，用于创建简单的、缓存一致的 DMA 缓冲区。

2025-05-06 13:35:00 396

转载 LWN：用户空间的 per-CPU memory！

本质上，这是缓存行对齐数组方法的变体，但分配器会将分配的数据紧凑地排列在每个 CPU 的区域内，从而减少这些区域之间的内存浪费。Desnoyers 首先表示，他的目标是帮助用户空间开发者更好地利用 restartable sequences （可重启序列），它通过在关键部分中断进程（如果进程在此时被迁移），从而促进对 per-CPU 数据的某些类型的访问。因此，该库首先在一个特殊的“初始化区域”中初始化一个 CPU 的内存，然后为每个 CPU 创建该区域的写时复制（copy-on-write）映射。

2025-04-23 13:30:04 655

转载 LWN：buffer write 时不被“撕裂”！

在去年的 Linux 存储、文件系统、内存管理和 BPF 峰会 (LSFMM+BPF) 上，曾就原子写入 (atomic writes)进行过一次讨论，并随之发布了补丁，以在块层 (block layer) 中支持该特性，以及在 XFS 上支持直接 I/O (direct I/O)。他说，一切都只有 99.9% 的时间有效。他看到的一个问题是，开发人员一直在使用“原子”这个术语，因为这是 SCSI 和 NVMe 使用的术语，但随后人们希望 1MB 的原子写入能够工作，但这根本不是数据库开发人员所关心的。

2025-04-18 13:31:08 780

转载 LWN：内核处理Rust代码的流程！

Hindborg 同意，但他也指出，在块（block）子系统中，开发者进行更改时并不担心 Rust 方面的问题。当他收到问题报告时，他会在一天内修复它，一切都会很好。如果 Rust 代码要通过常规的子系统树（subsystem trees），那么维护者至少应该对这些代码进行构建测试（build tests），并且应该有一个明确的方案来应对构建出错（build break）的情况。在他的结论中，他重申，自 6.10 版本以来，Rust 编译器的最低版本一直保持在 1.78.0，即使较新的版本已经获得了支持。

2025-04-16 13:42:02 787

转载 LWN：GCC BPF 支持的进展！

然而，朝着这个目标前进的过程中，发现了一些 Clang 支持 BPF 的问题，需要进行长时间的讨论，以便为这两个项目找到前进的道路。目前，Ihor Solodrai 维护着 bpf-next 树的持续集成测试（他稍后在会议期间对此进行了介绍），该测试会测试每个提交的补丁，以确保验证器接受的内容没有退化。Song 说，这种 Clang 行为既是故意的，也是 BPF 特定的；他们说，如果外部结构是 CO-RE 可重定位的，那么从逻辑上讲，内部结构也应该是 CO-RE 可重定位的，无论它是如何进入该结构的。

2025-04-15 13:49:05 843

转载 LWN：slab 分配器的sheaves以及任意上下文的分配功能！

总而言之，他说，来自 sheaves 层的初步结果是 promising（很有希望的），但它与 slab 调试的交互需要改进。（它是 slab 分配器的一部分）实现的工作会议，该版本期望可以从任何上下文中的 BPF 程序中调用。Hoang Nhat Pham 同意，他说他工作的系统具有大量的 CPU，但只有一个 NUMA 节点，从而导致大量的锁竞争，而 per-CPU 缓存可以改善这种情况。最后一个特性几乎是没有额外代价的，因为幸运的是，当请求到达时，分配器会有一个具有足够对象的 sheaf 存在。

2025-04-14 13:16:12 821

转载 LWN：减少TLB压力的措施！

但是，内存管理子系统面向的是 PMD 级别的大页，在许多系统上，PMD 级别的大页大小为 2MB；如果内核可以使用更多的多尺寸透明大页（multi-size Transparent Huge Pages，mTHP），则可以更好地利用此功能，并在减少内部碎片的同时获得更好的 TLB 利用率。因此，即使没有 TLB 利用率的提高，使用更大的页面也是值得的。一位听众指出，AMD 在没有显式页表条目位的情况下执行 TLB 合并的能力很好，但这仅在应用程序已访问 mTHP 中至少一半的页面时才有效。

2025-04-10 13:34:11 906

转载 LWN：墨西哥政府的开源经验！

这得到了回报，并且随着项目的发展，监管机构掌握了所需的背景知识，从而为项目铺平了道路。这是一场持续了三年的对话，最终达成了一个复杂的方案，即在后续的两个版本发布到生产环境后，可以将旧版本的代码添加到 Mifos 中。每当提出使用开源软件的想法时，由于缺乏相关知识，就会产生恐惧，但是由于决策者是政府官员，因此除了这种恐惧之外，还存在法律上的恐惧。在 López Obrador 政府的领导下，对这些项目的审查经常发现，他们可以使用开源软件，而不是采用提案中的昂贵的专有解决方案，因此这些项目需要进行切换。

2025-04-08 13:37:22 973

转载 LWN：MM 的多重奏（huge page, page promotion, KSM, BPF）！

它的页面扫描需要 CPU 时间，它需要进行一些繁琐的调整才能匹配工作负载，并且它会引发安全问题，因为它可用于确定系统中是否存在具有给定内容的页面。通常，这意味着将频繁访问的（“热（hot）”）数据放置在最快且最靠近使用它的工作负载的内存中，而将不太频繁访问的（“冷（cold）”）数据降级到较慢、更远的内存中。BPF 程序几乎可以在任何上下文中运行，包括在中断处理程序中，甚至在不可屏蔽中断（non-maskable interrupt, NMI）的处理程序中，在这些处理程序中，获取锁的能力受到严重限制。

2025-04-07 13:20:33 978

转载 LWN：保证可以分到连续内存的分配器！

保证 CMA 建立在 cleancache 之上，方法是在启动时分配一个物理上连续的内存区域，此时这种分配相对容易。不过，这些补丁相对较小，并且不会侵入未使用 CMA 的系统上的内存管理子系统，因此我们可能会看到超越内存应用程序在首次提出该想法大约 15 年后真正向前发展。如果内存可用，则可以快速分配。此后，大多数超越内存的工作都未被使用并已从内核中删除，但这个想法仍然存在，并且此补丁系列利用它来提供有保证的 CMA。多年来，人们付出了许多努力来避免对这种分配的需求，但在某些时候，它们是不可避免的。

2025-04-03 13:30:57 1033

转载 LWN：改进CPU漏洞防护措施的配置方式！

用于选择缓解措施的内部逻辑 (internal logic) 也受到了审阅者的广泛关注，尽管仅以代码风格注释的形式出现，但也得到了清理。通过 Kaplan 的更改，功能应该相同，但是该实现已分为 "select" (选择) 、 "update" (更新) 和 "apply" (应用) 函数，用于内核知道的每种缓解措施。select 函数确定是否应启用缓解措施， update 函数允许根据已选择的其他缓解措施来更改缓解措施的特定配置，而 apply 函数则完成将缓解措施应用于内核的实际工作。

2025-03-31 13:12:37 1090

转载 LWN：2025 疯狂的 mapcount！

但是，这种优化只会使专有性问题更加难以回答，尤其是在存在部分映射的页组（其中只有部分页面映射到地址空间中）的情况下。所有这些工作的结果是，内核可以更好地处理任何给定的页组是被独占还是共享映射，尽管它仍然可能偶尔得出结论，即页组在未被独占映射时被共享映射。它们有自己的映射计数，本质上是它们包含的页面的映射计数的总和。对于单个页面，专有性问题很容易回答：如果映射计数为 1，则映射是独占的，否则是共享的。但是，如果映射计数是在页组级别维护的，则该规则不再适用，因为页组级别的计数几乎不可能是 1。

2025-03-28 20:49:16 1158

转载 LWN：网络代码中着手处理冻结页！

包含在该向量中的所有页都需要在操作进行期间保持存在和有效，因此每个页的引用计数在开始时递增，并在操作完成后递减。然而，随着向 folios (更高级的页管理结构) 的转变以及避免不必要的引用计数操作的愿望，这种模式已经发生了变化。，在内存管理代码中添加了一些检查，以防止尝试操作 slab 页上的引用计数，slab 页是 6.14 内核中唯一的冻结页。随后进行了一些广泛的调试和讨论，最终弄清楚是网络代码试图对一个冻结页的引用计数进行递增操作，导致各种内部混乱，并最终导致崩溃。时，冻结页突然进入了人们的视野。

2025-03-27 13:08:52 1154

转载 LWN：内核的capability analysis！

在内核（及其他领域）中的实际使用可能有助于推动 Clang 社区的开发工作，以改进此分析功能，使其能够常规地用于验证锁定模式。但是，由于它是一个 opt-in 的编译时功能，因此即使需要进一步的工作，相对较早地添加它也可能很有价值。当 Van Assche 使用 breadth-first（广度优先）方法处理 mutex 时，Elver 采用了 depth-first（深度优先）方法，该系列为几个 locking primitive（锁定原语）添加了注解，但仅在明确选择加入的子系统中处于活动状态。

2025-03-26 13:38:02 1185

转载 LWN：Timer ID，CRIU，API变动！

但当时真正的问题是，内核中按顺序分配定时器 ID 的要求阻碍了对内部全局哈希表的一些必要更改，而这些更改反过来又阻碍了定时器子系统中的其他更改。timer_create() 的 man 手册指出，每个创建的定时器都有一个在其创建进程中唯一的 ID，但对返回的值没有做出其他承诺。当 CRIU 必须在要恢复的进程中创建一个具有特定 ID 的定时器时，它会利用这些知识，简单地运行一个循环，分配和销毁定时器，直到返回请求的 ID。该表仍然是全局的，但是其中保存的定时器 ID 将拥有进程的身份（具体来说，是它的。

2025-03-25 13:30:01 1194

转载 LWN：基于哈希对module进行完整性检查！

因此，Weißschuh 的补丁集采用了一种更简单的方法：该补丁集没有尝试为可加载模块创建签名，而是计算所有与内核一起构建的模块的加密哈希值，并将这些哈希值嵌入为一个静态列表，以便在加载前验证潜在的模块。这种机制基于构建时计算的哈希值来检查模块的完整性，而不是使用加密签名，从而可以在更多情况下实现可重现的内核构建 (reproducible kernel builds)。这样做的好处是简单 —— 如果一个模块的哈希值与构建时的哈希值相同，那么它肯定没有被篡改 —— 但它不如基于签名的方法灵活。

2025-03-21 13:33:43 1193

转载 LWN：参考文献管理工具Zotero！

的参考文献目录的人来说，特别有用。一些简单的配置步骤就足以满足许多专业人士的需求，包括从事科学论文的学术研究人员、为杂志撰写文章的记者以及希望起草技术书籍的任何人。Zotero 使用 Citation Style Language （CSL）进行格式化，支持大量的样式库，可以通过 XML 编辑对其进行自定义，以满足特定学科的要求。虽然该应用程序支持插件并提供基本的界面调整，但寻求更深入修改（例如创建自定义布局或高级自动化工作流程）的用户通常会遇到限制，这是因为核心元素的自定义选项不足。

2025-03-19 13:15:23 1185

转载 LWN：FineIBT保护仍有漏洞！

在像内核这样庞大的代码中，肯定会存在一个指令序列，当以意外的方式调用时，该序列会为攻击者执行一些有用的操作。目前尚不清楚攻击者是否曾利用 Miller 报告的绕过方法，但是一旦此代码生效，任何此类漏洞利用的作者都将不得不寻找一种新的方法来绕过内核的控制流完整性保护。似乎，这种技巧是能找到的最快，最节省空间的方式来执行测试并生成陷阱，而不会不必要地减慢合法的间接函数调用（应该是所有这些调用）。在内核的实现中，每个间接调用都被修改为首先将一个特殊的哈希值加载到特定的寄存器中。查看代码，可以看到它以预期的。

2025-03-18 13:36:31 1139

转载 LWN：对文件对应内存内容添加保护页！

正如 Stoakes 指出的那样，这不应该是一个问题，因为进程映射文件、放置保护页，之后尝试读取该页面的做法是不寻常的。6.13 内核版本中包含的诸多新特性之一是 guard pages（保护页），这是一种强化机制，能够以高效的方式将 zero-access pages（零访问页）注入到进程的地址空间中。这种情况是，由于这些文件描述的是 VMA，因此它们不适合放置有关保护页的信息，因为根据设计，保护页没有自己的 VMA。但是，仍然存在一些例外情况，其中一个是在发布补丁之前已知的，而另一个是意外的。

2025-03-17 12:33:01 1164

空空如也

空空如也