Messages in this thread | | | Date | Fri, 30 Jun 2023 08:35:26 +0200 | Subject | Re: [PATCH v4 29/33] x86/mm: try VMA lock-based page fault handling first | From | Jiri Slaby <> |
| |
On 29. 06. 23, 17:30, Suren Baghdasaryan wrote: > On Thu, Jun 29, 2023 at 7:40 AM Jiri Slaby <jirislaby@kernel.org> wrote: >> >> Hi, >> >> On 27. 02. 23, 18:36, Suren Baghdasaryan wrote: >>> Attempt VMA lock-based page fault handling first, and fall back to the >>> existing mmap_lock-based handling if that fails. >>> >>> Signed-off-by: Suren Baghdasaryan <surenb@google.com> >>> --- >>> arch/x86/Kconfig | 1 + >>> arch/x86/mm/fault.c | 36 ++++++++++++++++++++++++++++++++++++ >>> 2 files changed, 37 insertions(+) >>> >>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig >>> index a825bf031f49..df21fba77db1 100644 >>> --- a/arch/x86/Kconfig >>> +++ b/arch/x86/Kconfig >>> @@ -27,6 +27,7 @@ config X86_64 >>> # Options that are inherently 64-bit kernel only: >>> select ARCH_HAS_GIGANTIC_PAGE >>> select ARCH_SUPPORTS_INT128 if CC_HAS_INT128 >>> + select ARCH_SUPPORTS_PER_VMA_LOCK >>> select ARCH_USE_CMPXCHG_LOCKREF >>> select HAVE_ARCH_SOFT_DIRTY >>> select MODULES_USE_ELF_RELA >>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c >>> index a498ae1fbe66..e4399983c50c 100644 >>> --- a/arch/x86/mm/fault.c >>> +++ b/arch/x86/mm/fault.c >>> @@ -19,6 +19,7 @@ >>> #include <linux/uaccess.h> /* faulthandler_disabled() */ >>> #include <linux/efi.h> /* efi_crash_gracefully_on_page_fault()*/ >>> #include <linux/mm_types.h> >>> +#include <linux/mm.h> /* find_and_lock_vma() */ >>> >>> #include <asm/cpufeature.h> /* boot_cpu_has, ... */ >>> #include <asm/traps.h> /* dotraplinkage, ... */ >>> @@ -1333,6 +1334,38 @@ void do_user_addr_fault(struct pt_regs *regs, >>> } >>> #endif >>> >>> +#ifdef CONFIG_PER_VMA_LOCK >>> + if (!(flags & FAULT_FLAG_USER)) >>> + goto lock_mmap; >>> + >>> + vma = lock_vma_under_rcu(mm, address); >>> + if (!vma) >>> + goto lock_mmap; >>> + >>> + if (unlikely(access_error(error_code, vma))) { >>> + vma_end_read(vma); >>> + goto lock_mmap; >>> + } >>> + fault = handle_mm_fault(vma, address, flags | FAULT_FLAG_VMA_LOCK, regs); >>> + vma_end_read(vma); >>> + >>> + if (!(fault & VM_FAULT_RETRY)) { >>> + count_vm_vma_lock_event(VMA_LOCK_SUCCESS); >>> + goto done; >>> + } >>> + count_vm_vma_lock_event(VMA_LOCK_RETRY); >> >> This is apparently not strong enough as it causes go build failures like: >> >> [ 409s] strconv >> [ 409s] releasep: m=0x579e2000 m->p=0x5781c600 p->m=0x0 p->status=2 >> [ 409s] fatal error: releasep: invalid p state >> [ 409s] >> >> [ 325s] hash/adler32 >> [ 325s] hash/crc32 >> [ 325s] cmd/internal/codesign >> [ 336s] fatal error: runtime: out of memory > > Hi Jiri, > Thanks for reporting! I'm not familiar with go builds. Could you > please explain the error to me or point me to some documentation to > decipher that error?
Sorry, we are on the same boat -- me neither. It only popped up in our (openSUSE) build system and I only tracked it down by bisection. Let me know if I can try something (like a patch or gathering some debug info).
thanks, -- js suse labs
| |