From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE27CEB64D9 for ; Thu, 29 Jun 2023 15:31:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 44C958D0002; Thu, 29 Jun 2023 11:31:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3FD618D0001; Thu, 29 Jun 2023 11:31:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2C5C98D0002; Thu, 29 Jun 2023 11:31:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1EDD18D0001 for ; Thu, 29 Jun 2023 11:31:03 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BE8A31C830B for ; Thu, 29 Jun 2023 15:31:02 +0000 (UTC) X-FDA: 80956173564.15.2CA21CB Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by imf20.hostedemail.com (Postfix) with ESMTP id 145A61C003C for ; Thu, 29 Jun 2023 15:30:58 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=r0WnIICq; spf=pass (imf20.hostedemail.com: domain of surenb@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688052659; a=rsa-sha256; cv=none; b=S48NYEsyp67c47JGca6qlrpDUJb378zXcK5pFbdCYptpYlrJq2R+zuzn6W16Ok3c/Qkn3h GILbwsaWUnb+iGCPVoYvlbDeKN/aFT7laYuHlyBanihHjsbuvDidXPLG0SaVmp7G3K84UI RnXzquRly9UDCNP1bqEltzpnQfBHXRg= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=r0WnIICq; spf=pass (imf20.hostedemail.com: domain of surenb@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688052659; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=VL6wKBophCJT750RGEYyX1lE9eIiUgZcFU/NnUJTEDA=; b=TQI2C4frK5WXNM52ve7DI8XSWXqkn6vTcIagc8feLvuQf8LMQvsePnGkavvrRAf18p/pBB x6E83+s8xiYpFislQ9SkDFXGEm9mgDrCIEQ6hjk1CnIdbIfA3s6z5RjrSYjY0Dj10rAYLJ H0Z57U31lthGz6hfXaRSDbDPTyEDero= Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-57725e1c24bso7826207b3.1 for ; Thu, 29 Jun 2023 08:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688052658; x=1690644658; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=VL6wKBophCJT750RGEYyX1lE9eIiUgZcFU/NnUJTEDA=; b=r0WnIICqLcQpC2z4k1OXqjdIHwbyPvk1Z8ri5rmK+ckoNK18AT6VPUSbdQmfmsx18M wpL4jWqQfgb/a0s8JMpZaBrgwnhJIf1ZGhC2od40BCjr+QlmX2ql2nZl1ck/r7A8cgTa n0RD9fpWUbCghdSpcnZNAOfA8ihWS+0uQ7L4MUsNXxfZoEYZsiYCuttP18dSP3+DAvuQ Y0KT2h9YNtynUz89d0/QqugdvmBW+mUOFFNQLmfN9qfC1rZIqrqRPTUQIPAJEt1tnlQX FC34JywB7aEarHByxfMPXtMTg/OEGYqBC8nbWMkvV1YAG76K9xeVTkeqDCIyr7z2EoiU 15Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688052658; x=1690644658; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VL6wKBophCJT750RGEYyX1lE9eIiUgZcFU/NnUJTEDA=; b=LlMpTP9twP9RsA2sJsLV5uG7/3F64+JtgD7jiv+jl9UWixM/ratIn7aGnzjNtGgpOk Ky/JDoSUIuFXN/Uph5y5Tr31+Lbo9X0kQbWVVJFsep1sbsk7USnMZP6sW3pgA+kaegIX 8CF1iccNlVF9hvqTTvu1E4XnnAxu8XWKMhJ9jjZ79FXqSFiWOnNsQ4q2LvPmOI7/6J0i g5BTV+xnaCAxCIr0g+bBujYSipW5tn/xmcBEMUjx2TW86iFAWKyZ5ddyj/vNEBHZloPi CNqoEiCTy9Hx5Up12GvpkyRyk3l+yB06K/g2mvtnf3MnZoJ5IneYUk61B2E1OijH/Pkr OBKQ== X-Gm-Message-State: ABy/qLatsFqlJD7H8ZCYPuI9VJffLBlxe4qPggX05JIJv6MmOcFVwH8n ULhgyvgofWkH+CbXSsSkPufWu0mA27NZjXAGx3FdxA== X-Google-Smtp-Source: APBJJlHpQCyFxGZ2wEWn3k5zfeZwCJEObRUSbe49PZI26MJdi9kBQNmWxonB8vDszBerZkC/zLjl3GPQlhEj+vvvXB0= X-Received: by 2002:a25:f603:0:b0:c11:565:debb with SMTP id t3-20020a25f603000000b00c110565debbmr322761ybd.17.1688052657580; Thu, 29 Jun 2023 08:30:57 -0700 (PDT) MIME-Version: 1.0 References: <20230227173632.3292573-1-surenb@google.com> <20230227173632.3292573-30-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 29 Jun 2023 08:30:45 -0700 Message-ID: Subject: Re: [PATCH v4 29/33] x86/mm: try VMA lock-based page fault handling first To: Jiri Slaby Cc: akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, paulmck@kernel.org, mingo@redhat.com, will@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, punit.agrawal@bytedance.com, lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com, chriscli@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, rppt@kernel.org, jannh@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, gurua@google.com, arjunroy@google.com, soheil@google.com, leewalsh@google.com, posk@google.com, michalechner92@googlemail.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 145A61C003C X-Stat-Signature: cfaxwgcj6qpp6tp7mnepqoo48j3nehye X-Rspam-User: X-HE-Tag: 1688052658-565558 X-HE-Meta: U2FsdGVkX1+fMQYbTZxa7qHlU6iHBI9QWTc6vFcFxvedDymUKoZ+SFomqX1bZ00NCKGmd2SSIYBzrwAqyofBgFoafIjh/uUpj4blb6bEEsoy8lNE8Vkr45BL1I8Vhg1jNAa4H1MKAdc3PRz93rVBet56VCaQjC24BdRRcCCoBjpe8Bq9W/KkslDTfvZLS1qo17x1D0f1NA7hBJQthvNlBB9ZLBo2sQfOMO+DBMclz44n7rEf1LO0nXY0k2hU1X5V7rL84BP4/MjXhkGSYvflAyqCsD6cJFT0RUnOM40+MKe0rlJBzjV5UoSArgcKHG7nFQE8q5lIrARheFFzvOkqjv2ZK3vU0ADXkcW4U5LnH4S1txWTdssjKQAkv2DmjHAaX5qarLAqs7C2D/1qLJH7pXnM6UrVPaNsuCmd5aNaPQVZl+fmgDkIX60GB0P/NnHO0haruIFy1/oAnuqCs5HhdYTEmmGNpg/4RRMUPJJaCOVLzv87mCTv9EMj+ttEjIc7Ewz4nX/sBkEX5yELJrwjxru4gIq/2fLW3WHe4OV7o261NOEBZJQmbS2/sTxxqoABL98H4sFiz/xlFwQ0n5pFI6ANXTIVt8dYD/eaNJ2O5MMyvO5oQBaTAzXXgNPBzPY2M0MySsb2jf8cigAKzzqdHV8KQCdTa7KvJkC1QZHCMCsfI8fS8pb9SzCAcN1l3JcyEDuTKllH/yy+XETscDl8o/rc7NvyA4IG9Uw0bAy4bcq7u2cxYneWR+jnpcfQ9gooVB8kUeRe6P72+uvgz3oBDMz4fS951SsggzzgDkPWULdf70/WETpp0fL1MYNbIzNdF0a11Z23ZDhDbfRwp3jdv26rdO1koj5LIE9A6EXxF2NHPhJczcepTKAhp733nW2S5ydnfqfkqUEjsOT9iCNuZ2AdZ3DxrmhjsFkoFmeQFl8xU+6u7vwtDOoX5ivHbAu5YZkAJ7GJqHKwo2r/UMH sBPSdt95 76Ioz6dMLjIylCTsC7OTvPa+VGpSzMFHGqV+aMWIOsqFq51u9AnHWJGjfX/m5jW2g1zRH9USqiJ0DFapN50d/kLrREx/NKi6Xw/VMCu5Bfpj0puE5bUveyYdD+y+Pqm+3o2xBXQAQAryPVyf+qBrKjVo3Z7YKTTeqdsB1gqcM4XhGn3CMm5kaQNO4ivzoXa2CeBiZ+MBxs127rdxnuFBo/XHbH4l/IBWOxl1ycO+mn4zSaS/tpCeRJemkN7d1md08CIeeatzPwCLoHRgjlRNFTn4x4C6lvM+U9Bl/mUgW/W9uxvr1khIa2u9ijOMqKVe/m4cW94jcCiT44F6IJuhQefc9itik2mHzcOq7wlhYWm01VphmIhXGr68Ryw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jun 29, 2023 at 7:40=E2=80=AFAM Jiri Slaby w= rote: > > 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 > > --- > > 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 /* faulthandler_disabled() *= / > > #include /* efi_crash_gracefully_o= n_page_fault()*/ > > #include > > +#include /* find_and_lock_vma() */ > > > > #include /* boot_cpu_has, ... *= / > > #include /* 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 =3D 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 =3D handle_mm_fault(vma, address, flags | FAULT_FLAG_VMA_LO= CK, 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=3D0x579e2000 m->p=3D0x5781c600 p->m=3D0x0 p->status= =3D2 > [ 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? Thanks, Suren. > > There are many kinds of similar errors. It happens in 1-3 out of 20 > builds only. > > If I revert the commit on top of 6.4, they all dismiss. Any idea? > > The downstream report: > https://bugzilla.suse.com/show_bug.cgi?id=3D1212775 > > > + > > + /* Quick path to respond to signals */ > > + if (fault_signal_pending(fault, regs)) { > > + if (!user_mode(regs)) > > + kernelmode_fixup_or_oops(regs, error_code, addres= s, > > + SIGBUS, BUS_ADRERR, > > + ARCH_DEFAULT_PKEY); > > + return; > > + } > > +lock_mmap: > > +#endif /* CONFIG_PER_VMA_LOCK */ > > + > > /* > > * Kernel-mode access to the user address space should only occur > > * on well-defined single instructions listed in the exception > > @@ -1433,6 +1466,9 @@ void do_user_addr_fault(struct pt_regs *regs, > > } > > > > mmap_read_unlock(mm); > > +#ifdef CONFIG_PER_VMA_LOCK > > +done: > > +#endif > > if (likely(!(fault & VM_FAULT_ERROR))) > > return; > > > > thanks, > -- > js > suse labs >