| Message ID | 20220712231328.5294-1-kirill.shutemov@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Linear Address Masking enabling | expand |
On Wed, Jul 13, 2022 at 1:13 AM Kirill A. Shutemov <kirill.shutemov@linux.intel.com> wrote: > > Linear Address Masking[1] (LAM) modifies the checking that is applied to > 64-bit linear addresses, allowing software to use of the untranslated > address bits for metadata. > > The patchset brings support for LAM for userspace addresses. > > LAM_U48 enabling is controversial since it competes for bits with > 5-level paging. Its enabling isolated into an optional last patch that > can be applied at maintainer's discretion. I believe having optional patches will put unnecessary burden on distro maintainers. Soon after landing U48 support other changes will start piling on top of it, and it will be impossible to maintain a kernel with this patch removed. It also won't make any difference for the upstream, where this patch will be always present. We'd better decide now whether we need U48 or not, and either keep it or delete it.
On Mon, Jul 18, 2022 at 07:39:22PM +0200, Alexander Potapenko wrote: > On Wed, Jul 13, 2022 at 1:13 AM Kirill A. Shutemov > <kirill.shutemov@linux.intel.com> wrote: > > > > Linear Address Masking[1] (LAM) modifies the checking that is applied to > > 64-bit linear addresses, allowing software to use of the untranslated > > address bits for metadata. > > > > The patchset brings support for LAM for userspace addresses. > > > > LAM_U48 enabling is controversial since it competes for bits with > > 5-level paging. Its enabling isolated into an optional last patch that > > can be applied at maintainer's discretion. > > I believe having optional patches will put unnecessary burden on > distro maintainers. > Soon after landing U48 support other changes will start piling on top > of it, and it will be impossible to maintain a kernel with this patch > removed. > It also won't make any difference for the upstream, where this patch > will be always present. > > We'd better decide now whether we need U48 or not, and either keep it > or delete it. Dave, Andy, any position on this? I wrote LAM_U48 support to prove that interface is flexible enough, but I see why it can be a problem if a distro will pick them up ahead of upstream.
On Wed, Jul 20, 2022 at 2:59 AM Kirill A. Shutemov <kirill.shutemov@linux.intel.com> wrote: > > On Mon, Jul 18, 2022 at 07:39:22PM +0200, Alexander Potapenko wrote: > > On Wed, Jul 13, 2022 at 1:13 AM Kirill A. Shutemov > > <kirill.shutemov@linux.intel.com> wrote: > > > > > > Linear Address Masking[1] (LAM) modifies the checking that is applied to > > > 64-bit linear addresses, allowing software to use of the untranslated > > > address bits for metadata. > > > > > > The patchset brings support for LAM for userspace addresses. For what it's worth, there's an LLVM bot running basic HWASan tests on QEMU with the latest LAM patches here: https://lab.llvm.org/buildbot/#/builders/169 So far the bot is happy, giving us some sense of LAM_U57 support being sane. I'll add some tags to individual patches.
On 7/19/22 17:59, Kirill A. Shutemov wrote: > Dave, Andy, any position on this? > > I wrote LAM_U48 support to prove that interface is flexible enough, but I > see why it can be a problem if a distro will pick them up ahead of > upstream. My position is that maintaining distro forks is troublesome. If you held a gun to my head today and made me merge *something* I'd leave out the U48 patch, but reserve the right to add it later. I'm not sure whether that makes the distros lives easier or harder. I'm not promising anything either way, though.
Linear Address Masking[1] (LAM) modifies the checking that is applied to 64-bit linear addresses, allowing software to use of the untranslated address bits for metadata. The patchset brings support for LAM for userspace addresses. LAM_U48 enabling is controversial since it competes for bits with 5-level paging. Its enabling isolated into an optional last patch that can be applied at maintainer's discretion. Please review and consider applying. v5: - Do not use switch_mm() in enable_lam_func() - Use mb()/READ_ONCE() pair on LAM enabling; - Add self-test by Weihong Zhang; - Add comments; v4: - Fix untagged_addr() for LAM_U48; - Remove no-threads restriction on LAM enabling; - Fix mm_struct access from /proc/$PID/arch_status - Fix LAM handling in initialize_tlbstate_and_flush() - Pack tlb_state better; - Comments and commit messages; v3: - Rebased onto v5.19-rc1 - Per-process enabling; - API overhaul (again); - Avoid branches and costly computations in the fast path; - LAM_U48 is in optional patch. v2: - Rebased onto v5.18-rc1 - New arch_prctl(2)-based API - Expose status of LAM (or other thread features) in /proc/$PID/arch_status [1] ISE, Chapter 10. https://cdrdv2.intel.com/v1/dl/getContent/671368 Kirill A. Shutemov (8): x86/mm: Fix CR3_ADDR_MASK x86: CPUID and CR3/CR4 flags for Linear Address Masking mm: Pass down mm_struct to untagged_addr() x86/mm: Handle LAM on context switch x86/uaccess: Provide untagged_addr() and remove tags before address check x86/mm: Provide ARCH_GET_UNTAG_MASK and ARCH_ENABLE_TAGGED_ADDR x86: Expose untagging mask in /proc/$PID/arch_status x86/mm: Extend LAM to support to LAM_U48 Weihong Zhang (5): selftests/x86/lam: Add malloc test cases for linear-address masking selftests/x86/lam: Add mmap and SYSCALL test cases for linear-address masking selftests/x86/lam: Add io_uring test cases for linear-address masking selftests/x86/lam: Add inherit test cases for linear-address masking selftests/x86/lam: Add tests cases for LAM_U48 arch/arm64/include/asm/memory.h | 4 +- arch/arm64/include/asm/signal.h | 2 +- arch/arm64/include/asm/uaccess.h | 4 +- arch/arm64/kernel/hw_breakpoint.c | 2 +- arch/arm64/kernel/traps.c | 4 +- arch/arm64/mm/fault.c | 10 +- arch/sparc/include/asm/pgtable_64.h | 2 +- arch/sparc/include/asm/uaccess_64.h | 2 + arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/elf.h | 3 +- arch/x86/include/asm/mmu.h | 6 + arch/x86/include/asm/mmu_context.h | 58 ++ arch/x86/include/asm/processor-flags.h | 2 +- arch/x86/include/asm/tlbflush.h | 36 + arch/x86/include/asm/uaccess.h | 42 +- arch/x86/include/uapi/asm/prctl.h | 3 + arch/x86/include/uapi/asm/processor-flags.h | 6 + arch/x86/kernel/Makefile | 2 + arch/x86/kernel/fpu/xstate.c | 47 - arch/x86/kernel/proc.c | 60 ++ arch/x86/kernel/process.c | 3 + arch/x86/kernel/process_64.c | 83 +- arch/x86/kernel/sys_x86_64.c | 5 +- arch/x86/mm/hugetlbpage.c | 6 +- arch/x86/mm/mmap.c | 10 +- arch/x86/mm/tlb.c | 42 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +- drivers/gpu/drm/radeon/radeon_gem.c | 2 +- drivers/infiniband/hw/mlx4/mr.c | 2 +- drivers/media/common/videobuf2/frame_vector.c | 2 +- drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +- .../staging/media/atomisp/pci/hmm/hmm_bo.c | 2 +- drivers/tee/tee_shm.c | 2 +- drivers/vfio/vfio_iommu_type1.c | 2 +- fs/proc/task_mmu.c | 2 +- include/linux/mm.h | 11 - include/linux/uaccess.h | 15 + lib/strncpy_from_user.c | 2 +- lib/strnlen_user.c | 2 +- mm/gup.c | 6 +- mm/madvise.c | 2 +- mm/mempolicy.c | 6 +- mm/migrate.c | 2 +- mm/mincore.c | 2 +- mm/mlock.c | 4 +- mm/mmap.c | 2 +- mm/mprotect.c | 2 +- mm/mremap.c | 2 +- mm/msync.c | 2 +- tools/testing/selftests/x86/Makefile | 2 +- tools/testing/selftests/x86/lam.c | 913 ++++++++++++++++++ virt/kvm/kvm_main.c | 2 +- 53 files changed, 1315 insertions(+), 127 deletions(-) create mode 100644 arch/x86/kernel/proc.c create mode 100644 tools/testing/selftests/x86/lam.c