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 DABA9EB64DA for ; Sat, 8 Jul 2023 18:05:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 252938D0001; Sat, 8 Jul 2023 14:05:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 202FF6B0075; Sat, 8 Jul 2023 14:05:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0CAB98D0001; Sat, 8 Jul 2023 14:05:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id F0EA46B0074 for ; Sat, 8 Jul 2023 14:05:11 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id AF93EC01EF for ; Sat, 8 Jul 2023 18:05:11 +0000 (UTC) X-FDA: 80989221222.22.6D6E8D4 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf13.hostedemail.com (Postfix) with ESMTP id AD8B82001A for ; Sat, 8 Jul 2023 18:05:09 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=GIjkI0H+; spf=pass (imf13.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.48 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688839509; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=MjnZGX1PQcWVMUP4ngUH52YPa64eL7ZPB4WTz7UhRF0=; b=rGWtW+npLeLWOQeA3SiUPR8hLju+XQrWVOw8UxCqz6cwCcDxgsB1chSnDMdXcjhZGkL8Kw qAg+4zdEvAvL6W4Ok4oXv36WxaL4w8U/4m6s+VWNPd2b2BFUmB0i75wKHeaRmA8VUQJLvc Vu9FI6PGlYDl7xoj1mpui2s9BPFnchs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688839509; a=rsa-sha256; cv=none; b=tCA8mPJLgVIOKKVtj9vkeqhqzQqih8Iu+N9j4WR076NO/E3IrnapaBw+vB+wJ3jhtsKUXc LSpbZdcixLzdNH+cEA2r7qbIomQZajTC1Vz2NxYUP860KjTgot+5/kqNWjPi9krLCNz3GT RznbfnlCkiVDxuynzkAfeasokLgi+I0= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=GIjkI0H+; spf=pass (imf13.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.48 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-991ef0b464cso807936066b.0 for ; Sat, 08 Jul 2023 11:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1688839508; x=1691431508; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MjnZGX1PQcWVMUP4ngUH52YPa64eL7ZPB4WTz7UhRF0=; b=GIjkI0H+l12pwV8268GoTcFasRmnKd5Q9vwyG/4x3rs3N7icFJh7p7JRu5il/KcK+n FJAMZUGCO5MVPgZ0B9Z+w0Ubs0vs6elQPlWXN52AsnYirx8/q2pjyxNtEx0yI/KoIrsl eJGztnSX9KK+1RZWhCrQH2vCYWF5pGyCVfTwE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688839508; x=1691431508; h=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=MjnZGX1PQcWVMUP4ngUH52YPa64eL7ZPB4WTz7UhRF0=; b=OARv1gECPPbFyTLg0pR4JAePNOK8oKaawZxdlmpzwjGGLVEMn+ZwPJIqLdhA9xpWCl c+3i2s5WalA7rxkJ5sf2/hvdfW4KgSFb7LQq72o/ula6H6aoP4i6f23onma0pjauRsht rzyPWY0bs0RjELJeMukt2Iq9LDXDSwHv+y8Js2tUt0MfnFQNiuhqJRMDiE/JkNq/K6pG wCYZzbKe1sHNEz+45Yjn2ILALhXJUB/LWyccGyY6BzqoReUlx4Ack5KEKTsYjMPULdMk 8JL1bLdrTmiaq1nBM6PGsg3sDf5auoflaD2CGiP4awV+wlq+wwEaBA6OxT4GRv63M1wX Qqnw== X-Gm-Message-State: ABy/qLYBDmeKgqVoD5MtszzuHWFHdJaxJlboQmUaQeaU+QgKZUvGUZoK QzHkjfmUIh1F2v6ajG/+H6d4wFaBmpkiDsHVYAGwmnnv X-Google-Smtp-Source: APBJJlEpdqkDmxASZHhzIEIBivEsFjNiXbu0vrtIBo5JW2vg7Bm0OTHYtzwTih69oLC8WsQrNNTGog== X-Received: by 2002:a17:907:948a:b0:992:13c7:560 with SMTP id dm10-20020a170907948a00b0099213c70560mr10380030ejc.38.1688839507961; Sat, 08 Jul 2023 11:05:07 -0700 (PDT) Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com. [209.85.208.49]) by smtp.gmail.com with ESMTPSA id bi1-20020a170906a24100b00992aea2c55dsm3791731ejb.153.2023.07.08.11.05.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Jul 2023 11:05:06 -0700 (PDT) Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-51a52a7d859so7922357a12.0 for ; Sat, 08 Jul 2023 11:05:06 -0700 (PDT) X-Received: by 2002:a05:6402:274c:b0:51b:d59f:8518 with SMTP id z12-20020a056402274c00b0051bd59f8518mr12625706edd.16.1688839506127; Sat, 08 Jul 2023 11:05:06 -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> <2023070509-undertow-pulverize-5adc@gregkh> <7668c45a-70b1-dc2f-d0f5-c0e76ec17145@leemhuis.info> <20230705084906.22eee41e6e72da588fce5a48@linux-foundation.org> <20230708103936.4f6655cd0d8e8a0478509e25@linux-foundation.org> In-Reply-To: <20230708103936.4f6655cd0d8e8a0478509e25@linux-foundation.org> From: Linus Torvalds Date: Sat, 8 Jul 2023 11:04:49 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Fwd: Memory corruption in multithreaded user space program while calling fork To: Andrew Morton Cc: Thorsten Leemhuis , Suren Baghdasaryan , Bagas Sanjaya , Jacob Young , Laurent Dufour , Linux Kernel Mailing List , Linux Memory Management , Linux PowerPC , Linux ARM , Greg KH , Linux regressions mailing list Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: AD8B82001A X-Rspam-User: X-Stat-Signature: 9sri4dey631xjqypucpgi378bozxbtm3 X-Rspamd-Server: rspam03 X-HE-Tag: 1688839509-273484 X-HE-Meta: U2FsdGVkX19AHCkvj5bn/ou+FQ0kK5EVJ+QCPDiRsg8zWhT5gb1xAL1cpnVaEPYiY54t6L2YFr+vUpsiQsz0WL340/8J7YU2CfG4ZkgWSAOkt7j/2YQoigiJGjjUR0cZkZl+kWBV8zms9LCsa6XycspsGlNQV1mJwszUfj7Ir+uX45qIjB6nj3BBYazzMgCbIep9tdoUXSU303UDs97yQKjfJZbsUe6e94kQH4qGXYptCs8dMJSEZiuAxUTFS6Y1u4xI63g98h49RB6aK6EqZVz3UwD8w0FqSW6zuAttSHkId0iQ99AKESj0gJh1H2Ubvi4IiFmImiHNfkLLVTmI3B6tPOykt3+9AL/oZ8gSj8czM257tyxlroEUlFhKjBSQlWQRhXugidnT85vHfOPqgRhaREq4JFBldDM0wGeBydGcPn7nzuB2IzAMGVuJAbSIdoe8TgpXd8K7PtfCqP371BSazHOdF/jCjSJelW5NYw78baEbqBgz9CGKsIYhpJYB0nKL2R6Tv8Atm5iS7eM3qkxImG+GfGwi5f+P3OEIJNsgiTwugjxrMxy8jyamhUs0lxoEhTGZhdDLM+0VBTytnR8o+3ku7UeLCx6XTvsT7Oy/GOG9ZjiQCwQPBPlAf0ufv0BXk4oAO3tlInY5GdaxSbSmV2SUZTSQU4aQBlAwhdc2f+QAJgl+5GAAGMDA/pEONdQAERBtah9DBr8RD4BiwiHWHhb1Lk+wzYfhEnsyz2B54FqxIEdi30/wWy6mWHoJbnKoffbcu0ZsqjDsuWagzha/HyvDH8+BW+FmdseCorK52l+ZtVqzOv0xyyioalquLo0KSDytrAVv0bB2UA64yFmuAXGIJZbA4UnFhhFRZtpnDBeyk/Xnc8eITecwfgxrE25GqhX6ze6utlOmNq27JqqJRb3Sa9Wbtz6FW1X/4oObD/cslmeH+Z0cnAOxyy+HBRHZMv5Qhr+H4qCmuCN +39RWjH5 A0PxQD9RIa+g7RaAhgxlNAW42v/rCktiu6PinrsNS8fHEVdBCG/4mEgLpuV4Hv8JzOwtVw4yhddrz8WsMF1ohBu9hKR0OGxX8x0eHd02Ig1ekYMX6fGTT9/HUNKL1YdvTJl3FFI48LkV9CJ7ALBhsIZZ9v16mUI+BYlGA3Vf2B7HQPUSY50NM4N/UOJTqH/NGEsgIXy8XdtqFZuHH6U8M3RfL7VpcAp8tTe4GVOrXD5eqOmYccR878p6NbidpewwG+o5xaYmuY2OxF0ncv7DDkstFvKNATROG1V+iWySrGC8VNTB2NDGftyanv3gVhY/XyMewzxPdheMiGdYFCfF/DzDLtf1aE4ZWTQxdBQt4psctdd/Jj2ySDNJbcTCyspC63BOuloO+NDpjbwXTR3ltIkYrJA54BFlndaqNoxD90W1Tl5D7cLQeWOglXM0xRnHMFf0y3R/qkvFL+Ercaq32zbkeyaFoSGcz9Z6FMz8X1YNVK2EQ/LX/1zK1ZLxs+cKU1Lr6w3GqXSxOGZ/7HDUtq6uJS70kdr/h4nBGlWklLT65QUg3Rl7/4H4UqrbVuJ2Z2WYIePqVLBot8pvoeZt0VuOJ8SztYrj3gNO+p/Srdxr6Tw/msyhcZsetKZPgAljNvM7y8NYRET1WUqyZbzjvFSSoJZGiv+pkidwbTua5Bi1GCO3BLiUJlD+W9VJRdEryy3nrT0XH9X0OO3I= 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 Sat, 8 Jul 2023 at 10:39, Andrew Morton wrote: > > That was the v1 fix, but after some discussion > (https://lkml.kernel.org/r/20230705063711.2670599-1-surenb@google.com) > it was decided to take the "excessive" approach. That makes absolutely _zero_ sense. It seems to be complete voodoo programming. To some degree I don't care what happens in stable kernels, but there's no way we'll do that kind of thing in mainline without some logic or reason, when it makes no sense. flush_cache_dup_mm() is entirely irrelevant to the whole issue, for several reason, but the core one being that it only matters on broken virtually indexed caches, so none of the architectures that do per-vma locking. And the argument that "After the mmap_write_lock_killable(), there will still be a period where page faults can happen" may be true (that's kind of the *point* of per-vma locking), but it's irrelevant. It's true for *all* users of mmap_write_lock_killable, whether in fork or anywhere else. What makes fork() so magically special? It's why we have that vma_start_write(), to say "I'm now modifying *this* vma, so stop accessing it in parallel". Because no, flush_cache_dup_mm() is not the magical reason to do that thing. Maybe there is something else going on, but no, we don't write crazy code without a reason for it. That's completely unmaintainable, because people will look at that code, not understand it (because there is nothing to understand) and be afraid to touch it. For no actual reason. The obvious place to say "I'm now starting to modify the vma" is when you actually start to modify the vma. > Also, this change needs a couple more updates: Those updates seem sane, and come with explanations of why they exist. Looks fine to me. Suren, please send me the proper fixes. Not the voodoo one. The ones you can explain. And if stable wants to do something else, then that's fine. But for the development kernel,. we have two options: - fix the PER_VMA_LOCK code - decide that it's not worth it, and just revert it all and honestly, I'm ok with that second option, simply because this has all been way too much pain. But no, we don't mark it broken thinking we can't deal with it, or do random non-sensible code code we can't explain. Linus