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 488EBEB64D9 for ; Tue, 4 Jul 2023 22:05:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D29042800BF; Tue, 4 Jul 2023 18:05:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CD9B62800B2; Tue, 4 Jul 2023 18:05:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC8AB2800BF; Tue, 4 Jul 2023 18:05:02 -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 ABDB42800B2 for ; Tue, 4 Jul 2023 18:05:02 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 723CA1607B8 for ; Tue, 4 Jul 2023 22:05:02 +0000 (UTC) X-FDA: 80975310444.07.28F593E Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by imf21.hostedemail.com (Postfix) with ESMTP id B23FA1C0002 for ; Tue, 4 Jul 2023 22:05:00 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=uWDLDVCv; spf=pass (imf21.hostedemail.com: domain of surenb@google.com designates 209.85.219.175 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=1688508300; a=rsa-sha256; cv=none; b=OZGw6XHwFPfKRsa1sOlm/PF+JRdpqWaCdrxFzmPE3eIY3dHwSNvoHCwAcU4cBYQ8Ke5oyI XXvW78NjQRI79MkrTA4Ez3JW+zf1xAxmZJ6hd+ykTdvCXzFzDxIbCMI5ZjcARHnOf4SgYa nJzM5wsr45+J4ed3Av5FS8MJKIz++fE= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=uWDLDVCv; spf=pass (imf21.hostedemail.com: domain of surenb@google.com designates 209.85.219.175 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=1688508300; 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=nswOflL+ad3Rf8OdqQYDYHaGrkZ9dAMLf54yrOYBn/c=; b=rM7WSTP9KrmtLcJbw9Fjk+kKCqJLQEId970iJzfBQR1arAhSdcUX3mjHiITseir63LIvcT Hh/XB0BVSTvSrii72kMIeJG/jk1qR1Lpk7pLPz4TqZL3wTymBhNFSQvvRhxdaoCfLUsfvq K5DC6pX/OW65fkpi2zJOY9pDagY0O3c= Received: by mail-yb1-f175.google.com with SMTP id 3f1490d57ef6-c5e76dfcc36so954796276.2 for ; Tue, 04 Jul 2023 15:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688508299; x=1691100299; 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=nswOflL+ad3Rf8OdqQYDYHaGrkZ9dAMLf54yrOYBn/c=; b=uWDLDVCv+cij7Hgi1Dfyr9iYQ1IdZH68Kx0m/+1EN0oyYPmGjjkclXXBbFwVdPM2yH AVHBn4wuVtu2DZ9INL0uK6cnZInJcl2+pwwUCKHPvEP/M8v7Out/g1itOkKVHPIxwihZ xYI0wflgLgYZcwlVIYA07695rhSEHx0ncHS8v0w9o0or/zlXHzUtQM4S/DHuXuBqEjSX 1MHEVGC+Sfa6ZZOytGkLjCZFflKm35xQw8zHDl0gDWv8dlF8PW1s3MHLfAxrNMfR6uMU Kay/b1fyx27XReXEAEcfb0D8ekyWpR8/l2wt4q2zbSSZqvlvA3J5k4wvwSnIgqYt4zFx 7glQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688508299; x=1691100299; 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=nswOflL+ad3Rf8OdqQYDYHaGrkZ9dAMLf54yrOYBn/c=; b=f3uEPDlnT6ikymVldy9GqqJ/OdN+AC0bRJgvNV7IQ9OQYdKr1MPEqU67AQOSN6XG6q V3eup2k38AaNLtiVA++9fITfzHJQBpWP6N7iov4IBOuJmlSTB5EVGC8ttKjBQZkxbPDI 9Dq73zlDXCNdAjczze4vG/hALWGsT83HSXMSrT1snNUaJV3O5v46rg2kZ3DBvUi063Yg cnilHcz1Du15ZzM2+3rtdRVqzzDnOm+A7sNxmIQh+Nc5qI0dcTuSAuf7/UVkasKr4381 v6I8WZv5AuuEEtUFzTqBL8Gm5NU0F2vMNFFQm+WoR8acK/zzizZJ0WSc/NIn2NgzpvXH Pk7w== X-Gm-Message-State: ABy/qLYVlI+n10UgwJ/qdqqYkRkx6C5Nehy4/F6Fau+MtyET8PT0AhQu /AGr/1QraxVYdWWEUOgxASh1WrEkTmt1V7i3lyF0Rg== X-Google-Smtp-Source: APBJJlFn5VR+cnfVz1hYer80K/3NNixQJwpfU/KzY+2o39e/PwrqHafpMNiEhbiPGgr7TJ9T1M42aVv9KpISdV3ua7E= X-Received: by 2002:a25:ac20:0:b0:c42:97f9:cda6 with SMTP id w32-20020a25ac20000000b00c4297f9cda6mr10984031ybi.29.1688508299539; Tue, 04 Jul 2023 15:04:59 -0700 (PDT) MIME-Version: 1.0 References: <5c7455db-4ed8-b54f-e2d5-d2811908123d@leemhuis.info> <2023070359-evasive-regroup-f3b8@gregkh> <2023070453-plod-swipe-cfbf@gregkh> <20230704091808.aa2ed3c11a5351d9bf217ac9@linux-foundation.org> <20230704142846.524daa14ff921ed7eb534594@linux-foundation.org> In-Reply-To: <20230704142846.524daa14ff921ed7eb534594@linux-foundation.org> From: Suren Baghdasaryan Date: Tue, 4 Jul 2023 15:04:48 -0700 Message-ID: Subject: Re: Fwd: Memory corruption in multithreaded user space program while calling fork To: Andrew Morton Cc: Greg KH , Linux regressions mailing list , Bagas Sanjaya , Jacob Young , Laurent Dufour , Linux Kernel Mailing List , Linux Memory Management , Linux PowerPC , Linux ARM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: B23FA1C0002 X-Stat-Signature: 64a5n8t6gt57re8775uku9x7gizffjk1 X-Rspam-User: X-HE-Tag: 1688508300-98183 X-HE-Meta: U2FsdGVkX18qXE8TQ+XG+uQeYHteRLU1a0Thm2Kx23mWypMRgg92RYKSBk7ogReNx3xcZPUIEZpzHCbrb3f1caoT7GEd4tE9h5dJoy9MYkUnyVxh9Cn+70hvKUuDEaG6h0X6HFJjKLZeNGj0KYy7ttnViNccKt/ktqQywrB62pX5nGFo8WlUv++dxpe1zfwQskBLB80Mrw5WRAMbTmX+2Ywv4SV+pL/uStKdh224h+J7v3yhaVBUZQSZ29oWPRjdBjew5mtA/k3kEXuZZmNr2nX9dT27B9a/zXzPcVrtEv1jU//AwGRHdZFwBXDwmH2Zk2qqTbmlovXVyMUcW9+5ys1TXGnoFr4W+SAiYpRblsQp6NtHeLGxE86IX3xlMUmlgGZYaFoiIqnHR78BngnLMjdXbY1vsMdM7I9ckUs9FJLES9rg51gp+08NreefxjW7rmrGz+zBmf7mswUyvDTbNQK89t9inqrsM8QCJ0o04JJ9BXGQYYz+G75JddSPLIVqU0vkm8ch/HPFN1utlC/gblXjI2hGnmsTCguQAO77h3Jj5/S/T/s9AWiSVBKi+EyqHcbZUxGmhkGrJdL7bjgBj7/aEnD+2YirQFF0/S1+aN9Ue8p2sMUqO2ThQ8Rfahhy7SdKfohBHIgeJgL+/RnRQeEbUZkHZ59/qx4OTMA/bkliXC0usx5jdLeH1GPffwaampf7emmXv2f++aMWAA/16MeW806f3OZNJud3C+mkL34Ary5XlQMrY0LmTO5MIsmI7RPpmxFmWVjvnI+3UIJ9Mxm/KGbN3yr7Kw0oALczehOlyh1kKCLzRfjoIzlYwYuSondZ3qO7JrMl6QpkwhphXbbpQM6EbsjCXXvZ1E2nxZXyDpq3TJH1GkPkN1+RYutfGqUBOk4fVUWQEfVSXmZ9Lq8If9EOti8jyu964fDQpO+xsyzMbFjo/hLUHMAZUg7mfms+ue1yEYdwXLmNIV8 Z/KMGWPI ftokHtGCPgjxE1QWDnuZmHYIeHNaahyRk/FQQjCbGUK+cPaD5/fG6PvNQubATWs25PsZAzXB+E0anhUaEpRwjzwrWjjzQCJBkdD7KNae661meIEQtg7tSuNGxUHRtD5IxX/7YoqbkZUQ2Qcr7hO8dVA9VlYTtxIV0Ez9/G1OrlSAJn1lwbFW8hNeB+ZAf9szNLlgnZ2OSQM2CFlC+zhtrDKiBBHniunTQljJXf3hkt9c0mMmvVrZ1ULATXNqNkjRB4EmGCKdGCM+J/vFQfO8A924dgVmdFoCbf2UkGRRcBTnAPz9hbkEFBfpNT9VQdAPHhQ4Dg2oQ2ysMZhLOVz06wF/rIDansVE6sTwgPHUn0COnmOKUXy9BBVX6K6Z+zHKG15NgTo1PyTqXNe4vhPNkekgPqZlAXaEJlIa2tQBwCpVa3Z9yiHMIkP8rUQ== 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 Tue, Jul 4, 2023 at 2:28=E2=80=AFPM Andrew Morton wrote: > > On Tue, 4 Jul 2023 13:22:54 -0700 Suren Baghdasaryan = wrote: > > > On Tue, Jul 4, 2023 at 9:18=E2=80=AFAM Andrew Morton wrote: > > > > > > On Tue, 4 Jul 2023 09:00:19 +0100 Greg KH wrote: > > > > > > > > > > > Thanks! I'll investigate this later today. After discussing= with > > > > > > > > Andrew, we would like to disable CONFIG_PER_VMA_LOCK by def= ault until > > > > > > > > the issue is fixed. I'll post a patch shortly. > > > > > > > > > > > > > > Posted at: https://lore.kernel.org/all/20230703182150.2193578= -1-surenb@google.com/ > > > > > > > > > > > > As that change fixes something in 6.4, why not cc: stable on it= as well? > > > > > > > > > > Sorry, I thought since per-VMA locks were introduced in 6.4 and t= his > > > > > patch is fixing 6.4 I didn't need to send it to stable for older > > > > > versions. Did I miss something? > > > > > > > > 6.4.y is a stable kernel tree right now, so yes, it needs to be inc= luded > > > > there :) > > > > > > I'm in wait-a-few-days-mode on this. To see if we have a backportabl= e > > > fix rather than disabling the feature in -stable. > > > > Ok, I think we have a fix posted at [2] and it's cleanly applies to > > 6.4.y stable branch as well. However fork() performance might slightly > > regress, therefore disabling per-VMA locks by default for now seems to > > be preferable even with this fix (see discussion at > > https://lore.kernel.org/all/54cd9ffb-8f4b-003f-c2d6-3b6b0d2cb7d9@google= .com/). > > IOW, both [1] and [2] should be applied to 6.4.y stable. Both apply > > cleanly and I CC'ed stable on [2]. Greg, should I send [1] separately > > to stable@vger? > > > > [1] https://lore.kernel.org/all/20230703182150.2193578-1-surenb@google.= com/ > > This one isn't sufficient for .configs which already have > PER_VMA_LOCK=3Dy. Using `depends on BROKEN' would be better. > > > [2] https://lore.kernel.org/all/20230704200656.2526715-1-surenb@google.= com/ > > > > We're still awaiting tester input on this? Yeah, and it seems to be negative... Anyway, I'll post a dependency on BROK= EN. > > I think a clean new fully-changelogged two-patch series would be the > best way to handle this. Please ensure that the [0/2] intro clearly > explains what we're proposing here, and why. > > Also, "might slightly regress" is a bit weak. These things are > measurable, no? Because a better solution would be to fix 6.4.x and > mainline and leave it at that. >