英特尔希望将其 LAM（Linear Address Masking ：线性地址掩码） 功能合并到 Linux 6.2，但该功能被 Linus 批评了一番，并拒绝了该合并。
英特尔线性地址掩码 (LAM) 允许软件将 64 位线性地址的未转换地址位用于元数据，线性地址使用 48 位（4 级分页）或 57 位（5 级分页），而 LAM 允许将 64 位线性地址的剩余空间用于元数据。
简而言之，英特尔 LAM 在使用用户空间地址的未翻译地址位，因此它可用于用户空间内存清理和标记等元数据的多种用途，它的本质上类似于 AMD 的高位地址忽略“UAI”（Upper Address Ignore ）以及 Arm 的顶部字节忽略“TBI”（Top-Bits-Ignore）功能。
英特尔在 2020 年初次对外展示 LAM，从那以后一直致力于 Linux 内核支持。11月中旬，英特尔工程师为 Linux 6.2 的 x86/mm 分支提交了大量补丁，希望将该功能代码合并到内核中。
然而，LAM 随即遭受了 Linus 的猛烈批评，不仅是内核实现代码，Linus 甚至连“LAM” 这个名称都不满意：
现在要求英特尔将这个 LAM 功能称为“Top-Bits-Ignore” （TBI） ，会不会有些太晚了？
...
整个 LAM 功能不是特定于 mm ，它可以轻松影响每个线程。
想象一下，有一个设置，其中一些线程使用标记指针，而一些线程不使用。例如，地址的高位可能包含一个仅在虚拟机中使用的标签，甚至可以让“本机”模式使用完整的地址空间，并将其自身及私有数据虚拟地放在高位。
再想象一下，使用虚拟地址掩码不仅能实现内存清理器，还能实现一种真实的分离功能（例如，JITed 代码可能基本上只能访问较低的位，而 JITter 本身可以看到整个地址空间）。
也许这不是 LAM 在 x86 上的工作方式，但它对 untagged_addr() 的更改并不是 x86 特定的。所以我真的认为这是完全错误的，除了命名之外， 它全都是一些无效的假设。事实上，这个特定于 mm 的 LAM 功能，最后只会成为代码中一个活跃的 Bug ，即使在 x86-64 上也是如此。
所以我真的认为 LAM 是一个根本性的设计错误，虽然我把它拉出来并解决了琐碎的冲突，但我又把它拉了下来，因为它的设计是错误的。
Linux 内核邮件列表讨论了对英特尔的 LAM 的 Linux 实现方式的设计更改。但 Linus 认为英特尔 LAM 代码还没有为 Linux 做好准备，因此最终没有合并代码。英特尔已提交新的 x86/mm pull ，但删除了 LAM 代码。英特尔 Linux 工程师将重新编写 LAM 代码，为 Linux 6.3 做准备。
想象一下，有一个设置，其中一些线程使用标记指针，而一些线程不使用。例如，地址的高位可能包含一个仅在虚拟机中使用的标签，甚至可以让“本机”模式使用完整的地址空间，并将其自身及私有数据虚拟地放在高位。
再想象一下，使用虚拟地址掩码不仅能实现内存清理器，还能实现一种真实的分离功能（例如，JITed 代码可能基本上只能访问较低的位，而 JITter 本身可以看到整个地址空间）。
也许这不是 LAM 在 x86 上的工作方式，但它对 untagged_addr() 的更改并不是 x86 特定的。所以我真的认为这是完全错误的，除了命名之外， 它全都是一些无效的假设。事实上，这个特定于 mm 的 LAM 功能，最后只会成为代码中一个活跃的 Bug ，即使在 x86-64 上也是如此”