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 C0880EB64D9 for ; Tue, 4 Jul 2023 21:28:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D6102800BC; Tue, 4 Jul 2023 17:28:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 261222800B2; Tue, 4 Jul 2023 17:28:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 126E32800BC; Tue, 4 Jul 2023 17:28:51 -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 F2B512800B2 for ; Tue, 4 Jul 2023 17:28:50 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C4E3E160306 for ; Tue, 4 Jul 2023 21:28:50 +0000 (UTC) X-FDA: 80975219220.16.A26106F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf14.hostedemail.com (Postfix) with ESMTP id E4D2410000B for ; Tue, 4 Jul 2023 21:28:48 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=TdvrDHxu; spf=pass (imf14.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688506129; 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=7lziSZBx1GFCSJXWdWJj0pKp0hS/6nytoZkPxpuDpVc=; b=f8+iW26ID4Bf2ClHNWIIM45Coh0lHVXLha6Zb+yEqKsJAPSrCg53NX5JXMxM5u1Hyet6cb Wvuqc3A63sZFkVlTOKVZeWBYr2eeDoon5G4SBHnkFJZpFzDb7Ny99EwUXa0on0rMCfHlaC CszRLHhvovBRCe5nJoJOgzWFJ1IOTpg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688506129; a=rsa-sha256; cv=none; b=hMC7en4lKovP3jrAg9xRJWPNv6thXZjnwe+e9IFwUAwPrIf5NlPzqggdOt8fVje5MHu/6a ALlJYEJtf65YumRCnXcln1bPlAt6kUxiL0RbvibJf/s1wSVkvBWe6wpodfD0wY/cas6RnP cy+2QlIPqndxBFNfn1+WzA1LlURZ14g= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=TdvrDHxu; spf=pass (imf14.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DB1D361281; Tue, 4 Jul 2023 21:28:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6634C433C7; Tue, 4 Jul 2023 21:28:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1688506127; bh=E8dNdMe+o/9ilV1rktIoejIV+3alMbAu3NTh8xMgTwE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TdvrDHxu6v81wGlxPR7qp7Thm9ZHX4mhEdww0ympaj651vktXNup046lqWOb7b5H8 u+MSXBfU9Va4D/dgtEN6/jJ3cw9hglPlIBJ+MVnO2q5VDdIaLI1ZeB/SqsGjgS/vUx eq3GNfQ4jhK+t1UHNj/w5cjGPwcRwCzIOKuBIvY8= Date: Tue, 4 Jul 2023 14:28:46 -0700 From: Andrew Morton To: Suren Baghdasaryan Cc: Greg KH , Linux regressions mailing list , Bagas Sanjaya , Jacob Young , Laurent Dufour , Linux Kernel Mailing List , Linux Memory Management , Linux PowerPC , Linux ARM Subject: Re: Fwd: Memory corruption in multithreaded user space program while calling fork Message-Id: <20230704142846.524daa14ff921ed7eb534594@linux-foundation.org> In-Reply-To: References: <5c7455db-4ed8-b54f-e2d5-d2811908123d@leemhuis.info> <2023070359-evasive-regroup-f3b8@gregkh> <2023070453-plod-swipe-cfbf@gregkh> <20230704091808.aa2ed3c11a5351d9bf217ac9@linux-foundation.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: E4D2410000B X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: iren6crza74me4r6mawniydcn9g44hq5 X-HE-Tag: 1688506128-897894 X-HE-Meta: U2FsdGVkX1/ivICEX01HfQyBfmpJgdIjs07rMQCuYblouktFrLuXthBpWXZTf7wBxFPtdVtdoRVOxmkPYRpqSGl0ighM0FIuUThBBUhPINyA8G+ePSGFV1BMxQd/4puGvmc5Wm7uz/+kMN7MtkU5eQtXjS+KtmQtG/TjQPc2x3Rz6XA8pAcTgXV0Q9IvX9Y+VxphSFghu5a0WyPOE5I0ffrLtytO/ERLuFeZaWKjiWoid37YBguY4TazJptyFI1ALn8QJhxXEIugdBRxm2QgTKyGvR4/vFdjaIHhgca7pGheue1TDj4hIsjvEjLRMnG4WdywcSExXNM0tQyIoyt6xEOKaWphAheN5gNKIpQR3GvzvX06SwjZq3++AbK/hlEj203ODzg9/fbeVf5Ez1PWbn+wLVmCalvxrzFN9HW0CVYOgCbHRm6TUtf4vbmsM3g7ckXYjrAizvfoObXq/mSAS6SSaVlnNFxxHOgLas+zv/glQ+uzpHqVGJA9aW6OfdnrJI5fK+oa1cpv3djrhhzuKoYDVQQVWVdqJHojFEaa1nXjuEnRVBNUkSozUYLiKI4StxJom2Vdubgh0gSxwbeMTjuOKjTmLkmVW2hr4tlPsIxLril3KrmsB1wv74N6T1Ff9s/2Z3rN0YSbujEbNi3AWmLx0UOIrrHCMkMruGynahujS8QjT7q0rTuONRNNIsKq7dR6IUKo3Zvc5CT6C33Td2ElAUagfEGesu4WvJa/333ublOxT3nIXsuoMyVvirzxFYSLq52Ed1g5486skisxloQfBo+Kvx25DDRjxo4/jqGWWURTDhR/AFwf0yYZwe4+VDeaL8mHG77bouNhG7U50+oIwHI1Z4q99jylfrZRzhu9SB63Ea/iJfKq51gEOBToSA5eIMRbx4itkfcgJFwDwYPOO9CLp1kLJ/sIEc1xRW6nXcQbvYi4vqYgQylR9JG9IszsxkLw6fl3Vcl8Buh f4H9ggDC jrQQhojyM8wo+7547zTcLBDRUbA5YvCnU2SQpVN4CZGuPKKlddKiHoCqvqwH0s3NZYHynB8ChkIrVdnbTEjpiohaEequFuQxUHw72pAVQhmx3tGLrlrlnMJgZ221XBkPLjgFOX6Y6Pv/E5nyfTrkoet8gdV68bPXitOgW8SHusBXVMipa96HYexTW1+xopTy/YlH7Dy1gc7opnLNnl/EZ9ytPgdlgdhoIoUvAwwFcdMF2vuNbQQe6C1gdjifTHVvFmkSdZgtUnDJWRNvyZo5Rtibxen43EG3BadS8tA8JTzJJcGcu22H7OWCacebLgVfj/l4q9TY7tHFa+UPJuZwE/mm4067gneli0fPvDzbuUhkUM7xM84Wcl83sVQQPBP85WjhO02/SU7vzXYV7QDPLH+0sBq2VXg26tZXyDJP9IpbmC1Gk+IgiHff4f6633EzxXqgivZXRqvgx/SAuynMTuzKC/4VIrau0+2FPiJ40TCWqhGaJ7rScBAD/IrgKMVlAy88z9Ww1vUQvlvup4f1WOuPJGV4E1KS651sz+pZ7wUomJXoyeJv6Ice2tuTmegumsKpzfU0t51K1CccsFL5xOxbE7WY1DY+/W3VQmsUhnrK4yioCn0jDB3Wm2w== 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, 4 Jul 2023 13:22:54 -0700 Suren Baghdasaryan wrote: > On Tue, Jul 4, 2023 at 9:18 AM 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 default 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 this > > > > 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 included > > > there :) > > > > I'm in wait-a-few-days-mode on this. To see if we have a backportable > > 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=y. 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? 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.