[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9a8d788c-b8ba-1b8a-fd79-0e25b1b60bed@kernel.org>
Date: Fri, 30 Jun 2023 08:35:26 +0200
From: Jiri Slaby <jirislaby@...nel.org>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: akpm@...ux-foundation.org, michel@...pinasse.org,
jglisse@...gle.com, mhocko@...e.com, vbabka@...e.cz,
hannes@...xchg.org, mgorman@...hsingularity.net, dave@...olabs.net,
willy@...radead.org, liam.howlett@...cle.com, peterz@...radead.org,
ldufour@...ux.ibm.com, paulmck@...nel.org, mingo@...hat.com,
will@...nel.org, luto@...nel.org, songliubraving@...com,
peterx@...hat.com, david@...hat.com, dhowells@...hat.com,
hughd@...gle.com, bigeasy@...utronix.de, kent.overstreet@...ux.dev,
punit.agrawal@...edance.com, lstoakes@...il.com,
peterjung1337@...il.com, rientjes@...gle.com, chriscli@...gle.com,
axelrasmussen@...gle.com, joelaf@...gle.com, minchan@...gle.com,
rppt@...nel.org, jannh@...gle.com, shakeelb@...gle.com,
tatashin@...gle.com, edumazet@...gle.com, gthelen@...gle.com,
gurua@...gle.com, arjunroy@...gle.com, soheil@...gle.com,
leewalsh@...gle.com, posk@...gle.com,
michalechner92@...glemail.com, linux-mm@...ck.org,
linux-arm-kernel@...ts.infradead.org,
linuxppc-dev@...ts.ozlabs.org, x86@...nel.org,
linux-kernel@...r.kernel.org, kernel-team@...roid.com
Subject: Re: [PATCH v4 29/33] x86/mm: try VMA lock-based page fault handling
first
On 29. 06. 23, 17:30, Suren Baghdasaryan wrote:
> On Thu, Jun 29, 2023 at 7:40 AM Jiri Slaby <jirislaby@...nel.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@...gle.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
Powered by blists - more mailing lists