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 C2514C001DD for ; Mon, 3 Jul 2023 18:28:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5D547280028; Mon, 3 Jul 2023 14:28:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 55DB6280001; Mon, 3 Jul 2023 14:28:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3FE68280028; Mon, 3 Jul 2023 14:28:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 28436280001 for ; Mon, 3 Jul 2023 14:28:39 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id EE217140905 for ; Mon, 3 Jul 2023 18:28:38 +0000 (UTC) X-FDA: 80971136316.17.DCEFDB6 Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176]) by imf10.hostedemail.com (Postfix) with ESMTP id E1B68C001C for ; Mon, 3 Jul 2023 18:28:35 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=UdVzhraz; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of surenb@google.com designates 209.85.128.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688408917; 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=ek36zKTL7ob82kCPmmYqawPmIUiPev5d+Y7nLKq/8mE=; b=RywNg9lqQrpYAN8euAiZwlE/0qYN1BG5pOfy8JnquR6rT3XPDKiY1URr5ZBKnBD49c+enX AXLupdI3p626SbOS7cVeRPN9/vS9b4fOXE3zqmPxaXz6Dop8LwlbTnO2CsqeHetT7UkJJR LhwtWNaKUaDFqh/UzqqYNEx95iwNitM= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=UdVzhraz; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of surenb@google.com designates 209.85.128.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688408917; a=rsa-sha256; cv=none; b=S0zGplAePOAXDPIa8tN3eGrJ5p8Xcvtf3YSsOMCzsdks159Ydi1dMNBJsCUns89HdcyTRT vPwS0B8Im7asYttccIBnrAXfiHyxZYaQQtGb1AKp7om+Tve189b7snkliQ3pkQDzhn3LzN l8ehPdup5nAXIbiJuAivsZViDj79CKE= Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-5703d12ab9aso58089107b3.2 for ; Mon, 03 Jul 2023 11:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688408916; x=1691000916; 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=ek36zKTL7ob82kCPmmYqawPmIUiPev5d+Y7nLKq/8mE=; b=UdVzhrazyVYscLIb7Y6cNtZWYV2lS7lkeeUa7ehQnJsOxJTSrkjd9zVf6iwQKYDz3W 9Tihj+ZHL8WnaduVfuBYigTx+5EC/aM2HZrX9JutiuXvexBv5qxTXlNuy3eHKLhEp1sJ QSi37TfE+xrrtH08mqpgs5sbXI2p8rQVmzAyqaVY1HiKQ2UXzcBFTrkqZ7saZcZppOo+ RH02sZ2OsxFNeMScxVKFX2rEzINUf2BWCXAg8Aa6GajFXSy6e1CqBp+8EOmpPgG4kx3s gsmRChw46bgB7OCBq8p4h1uuvUQt9KLpSl3r+x5yEwN8vua4eqAl0xTVMN7RzPVpyCqL itbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688408916; x=1691000916; 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=ek36zKTL7ob82kCPmmYqawPmIUiPev5d+Y7nLKq/8mE=; b=lAlSKtCNMmskDSEg7YWs8/FKvr3ar22lmLZLi9sCRKYmWl02zPGeN7rduNGGzBWUAx CsqiprKM5dlR7aP8zrxeYYhtc/oKmRkmfVAviRzVcHRPLd7zm88V10CuwHWaqcoeSC3S LVp+J/LFR/Tpz/VOXQfIpj4e2iBZC5AKwEpS93JnDe+VyyfZKtrp2bf6o/LzbvJ4+uAN TyccZyioQrL9U4U8Rcc+qgVOp5JKk1+I/tSHuHYq8ZM1E+HS2eVkPNEEvgttfyBYVeVp 9gLNgwmxSsMxTF0wFKlMAojX/aM1htwyy2Vpe1XguxZBr14JI/VBdOq0V9dhB2NB7PuH v1xg== X-Gm-Message-State: ABy/qLYPNoGxwabHdxCvn62oGd2jEOVchZKYBGWFInKMnYkDgPflSjju o5O7nxjMMCorrZLKblYpqGqBCh9BxdMbRd9oBz8lSg== X-Google-Smtp-Source: APBJJlEUiq72rW7Q6Yfzz0nDRfcQy0vRp1Kdxwaa8m8rm9mvO4dU/0i5AUun4XT+RQg4WGwEKIGItN4/p3tjRejys1A= X-Received: by 2002:a25:b28e:0:b0:bfe:c4c8:66fa with SMTP id k14-20020a25b28e000000b00bfec4c866famr8920973ybj.35.1688408915818; Mon, 03 Jul 2023 11:28:35 -0700 (PDT) MIME-Version: 1.0 References: <20230227173632.3292573-1-surenb@google.com> <20230227173632.3292573-30-surenb@google.com> <9a8d788c-b8ba-1b8a-fd79-0e25b1b60bed@kernel.org> <2f150512-e460-a9ae-65db-39dc54fe99d6@kernel.org> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 3 Jul 2023 11:28:24 -0700 Message-ID: Subject: Re: [PATCH v4 29/33] x86/mm: try VMA lock-based page fault handling first To: =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= Cc: Jiri Slaby , 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, linux-mm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: E1B68C001C X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: bwygd6uzgmxxadfeu6mnoumkjifad4mj X-HE-Tag: 1688408915-765369 X-HE-Meta: U2FsdGVkX18FrXJmEQpRLSeQfPJkkTydxxjN7+RYebmvwTWLuNp0c2w+L8nMceZ0hPcpFRs5e+2xjVgvmavuHGDvqTAWIFaI2y4cJ84ukmhvHpew0zQB3JdAEQ0uJBKNb5toymEPpXf29T5ZDfHfw0Fv9trPjxAruDz67Kuxy3OsFfvq5iP40Gd0IPAvDagqsBqoeLeWmGHJVMSLD4QfL8JQj/Pfa+EXouCex9PzZHUKRSvINP+jYbFfHwz0BXd1Ul8NcRQ61aMiS/B7aer+snUXAoVp3iNJxXiVfMd2Akvq/KG8R3L+upGjGmOsoNglq93ANeRabvwr8GK24791FhrLucilpDNwm3tIiTduqRlrre+DNaFFowJLHHI5CAwesNzRn1aCD7aJXwsXsYKYpezML4Me+AiICAAh3mGpyljWq9BZGvwT5AjmL+6/WO4U1C/IMmjvPwzMX+lh4uIG7MIskVmkUq+TGK7XpZKxH4ChZghfmFpBdGSLBg3kQyKyGuYNtOancz3N9JmY6pnF2oMOqeXEYGlQh9mJmruM9zNXJPcd8Za6OySAAh/pXnpvGPifXQ/4K1aIkvxB2WGwtCVX7XGBxZFYHaYeRjsNQQwtzec+LfvfjwLagtKqEx81syHdfPEU/TSbLqbXUAfFQIwIPGVryNwQq6jF2tBDQKetWoaVFL/Jzy45BtOEjzeQwfa/5NhrR1yWCRTcjmSI4iaDoSQRiI5RRlCa2sbeVaDenUU8trvHrF5NTgjxsdOFVBJDgoCT5hNJ6pYa5Wb7BAVNaJSNCunA/Mu2rIgAOpZ5mHzQZq0JcnccHVskmUj9eLM9OUz+urdj00SbWjopPBL/8dPBIqKppTvHKSG//bpCePKQ7qjEZQZkSEBL/PW41waBSpFz7zVSOusROn71IhYv1kkjppcMJ/QXxGoszexk7gjxDMBQygZLe6WAop1BOB8Nx1XxzTbV5t6zO2C 32MGUBt7 r5fmlB0VLzSILil9Qdv5gBLm6qhqIfh/V0cNJdPG7QCqvkXmT0REY9c533l9ejrFauAU3N6LYMC9lPL5m9Q1YmVlOEFK5hDZMfFum742PlPtDtytEd+V+i3YZOVpMpahXiDHq5p2wKTflrGJzMTLEsPD4sOgLjsakdq226CjijjW1uh2Lt4JQIFXwnJWqnz8d22uUtp93ghb6Ymzzth7y/3MiAyuEL5/ZZQTOhTW38wPBFSRs7CL1gJrri62xUMEK0GpqsKgg3IVxDBqCdMLfxdnUmRplW961laVMop2iWjctYsZtDp294bC3XYA427l1ykZGH4e12s9hmWb5FgRVsR5gkQs44v/NTu++SqDvQFc9F+MKCNhHZgU4yQ== 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 Mon, Jul 3, 2023 at 8:24=E2=80=AFAM Suren Baghdasaryan wrote: > > On Mon, Jul 3, 2023 at 2:45=E2=80=AFPM Suren Baghdasaryan wrote: > > > > On Mon, Jul 3, 2023 at 6:52=E2=80=AFAM Holger Hoffst=C3=A4tte > > wrote: > > > > > > On 2023-07-03 12:47, Jiri Slaby wrote: > > > > Cc Jacob Young (from kernel bugzilla) > > > > > > > > On 30. 06. 23, 19:40, Suren Baghdasaryan wrote: > > > >> On Fri, Jun 30, 2023 at 1:43=E2=80=AFAM Jiri Slaby wrote: > > > >>> > > > >>> On 30. 06. 23, 10:28, Jiri Slaby wrote: > > > >>>> > 2348 > > > >>>> clone3({flags=3DCLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLON= E_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTI= D, child_tid=3D0x7fcaa5882990, parent_tid=3D0x7fcaa5882990, exit_signal=3D0= , stack=3D0x7fcaa5082000, stack_size=3D0x7ffe00, tls=3D0x7fcaa58826c0} =3D>= {parent_tid=3D[2351]}, 88) =3D 2351 > > > >>>> > 2350 <... clone3 resumed> =3D> {parent_tid=3D[2372]}, 88) = =3D 2372 > > > >>>> > 2351 <... clone3 resumed> =3D> {parent_tid=3D[2354]}, 88) = =3D 2354 > > > >>>> > 2351 <... clone3 resumed> =3D> {parent_tid=3D[2357]}, 88) = =3D 2357 > > > >>>> > 2354 <... clone3 resumed> =3D> {parent_tid=3D[2355]}, 88) = =3D 2355 > > > >>>> > 2355 <... clone3 resumed> =3D> {parent_tid=3D[2370]}, 88) = =3D 2370 > > > >>>> > 2370 mmap(NULL, 262144, PROT_READ|PROT_WRITE, > > > >>>> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 > > > >>>> > 2370 <... mmap resumed>) =3D 0x7fca68249000 > > > >>>> > 2372 <... clone3 resumed> =3D> {parent_tid=3D[2384]}, 88) = =3D 2384 > > > >>>> > 2384 <... clone3 resumed> =3D> {parent_tid=3D[2388]}, 88) = =3D 2388 > > > >>>> > 2388 <... clone3 resumed> =3D> {parent_tid=3D[2392]}, 88) = =3D 2392 > > > >>>> > 2392 <... clone3 resumed> =3D> {parent_tid=3D[2395]}, 88) = =3D 2395 > > > >>>> > 2395 write(2, "runtime: marked free object in s"..., 36 > > >>>> ...> > > > >>>> > > > >>>> I.e. IIUC, all are threads (CLONE_VM) and thread 2370 mapped ANO= N > > > >>>> 0x7fca68249000 - 0x7fca6827ffff and go in thread 2395 thinks for= some > > > >>>> reason 0x7fca6824bec8 in that region is "bad". > > > >> > > > >> Thanks for the analysis Jiri. > > > >> Is it possible from these logs to identify whether 2370 finished t= he > > > >> mmap operation before 2395 tried to access 0x7fca6824bec8? That ac= cess > > > >> has to happen only after mmap finishes mapping the region. > > > > > > > > Hi, > > > > > > > > it's hard to tell, but I assume so. > > > > > > > > For now, forget about this go's overly complicated, hard to reprodu= ce case and concentrate on the very nice reduced testcase in: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=3D217624 > > > > ;) > > > > > > > > FWIW, I can reproduce using the test case too. > > > > Thanks for the reproducer, Jiri! > > Let me try it and see if I can figure this one out. > > Interestingly I can't reproduce it with qemu emulator (reproducer > returns 1) but my host machine with the same kernel reproduces it > every time. Will try tracing the major code paths to see what's going > on. > I have to leave for a day but will resume in the evening once I'm home. I posted a patch to disable per-VMA locks by default for now: https://lore.kernel.org/all/20230703182150.2193578-1-surenb@google.com/ Will re-enable them once we figure this issue out. Thanks, Suren. > Thanks, > Suren. > > > > > > > > > > > thanks, > > > > > > As another (admittedly correlation-only) data point, I noticed at lea= st hourly crashes > > > of Firefox-114 after upgrading to 6.4.1, which had never happened bef= ore with 6.3.x. > > > After reverting 0bff0aaea03e2a3ed6 - with a bit of context fixup due = to follow-up > > > commits in 6.4.1 - it has been rock stable again, for several hours n= ow. > > > > > > cheers > > > Holger