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 53D97C636D4 for ; Tue, 7 Feb 2023 17:51:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BFE856B0139; Tue, 7 Feb 2023 12:51:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B87746B013A; Tue, 7 Feb 2023 12:51:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A01556B013B; Tue, 7 Feb 2023 12:51:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8CE8E6B0139 for ; Tue, 7 Feb 2023 12:51:44 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 66F95160A21 for ; Tue, 7 Feb 2023 17:51:44 +0000 (UTC) X-FDA: 80441238528.20.6E38C6F Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by imf01.hostedemail.com (Postfix) with ESMTP id 0B4994001E for ; Tue, 7 Feb 2023 17:51:40 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=osqPv5YX; spf=pass (imf01.hostedemail.com: domain of elver@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=elver@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=1675792301; 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=Qb55dZPeepUrU4dONRVCiplOK1WRN2GzgymWvixZoMg=; b=uUTe49rRrtcXmpDLwuOro5EMUAvQOnpud/A9l6AqaTj47iSGWj35vR9YUXJd1ORiuZ43FI FJoKfI4Pq/gWEeh0HsjUoYUxRF5jrjYhOpp7ASLnUZtfnzZQ4naCiwOxRrD8KFeMmw3HFy QRhIUfrFicFdLkJmAwfAAIKkqTk/ksk= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=osqPv5YX; spf=pass (imf01.hostedemail.com: domain of elver@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675792301; a=rsa-sha256; cv=none; b=h0y+XD2gE5KzqauIzQLbY52BVARFRdsESJzkh8iPCYnX+NjVjaZjo7R73sxKggincPfJMF X29m5zBBfG6vKDxHu6irmpmja/PM175k7Y4pSmtBGkEq3053VE40vfC07kSFPg3wW+Pw2p qlAIygrR6qb19tuUGgV0LbSnhvnqtp0= Received: by mail-yb1-f177.google.com with SMTP id u7so3568961ybi.6 for ; Tue, 07 Feb 2023 09:51:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Qb55dZPeepUrU4dONRVCiplOK1WRN2GzgymWvixZoMg=; b=osqPv5YXD9KFrvX5xnFy8CUYFAWiSf0TV9t5i3MEKamSmU9tFGjRDCs1u/XqY1G13c i6pYlMd68NMPO/Vedk6AcIFLgqm8HrI3/qPL1y7vZncAYTCEyqSrNAbJZM2VrqErZ8vE vYSPBKKwZMjz5SEmQBIcguvlkAAu4HI8iU9GtcIxBLqfIFtHc1+tEcsFlKjpkFlG3dFW gBuI4hLJV/kDKiZTVpscn7mE6ZSCu01j1e0PqLYCrPPeQY790Sql5iGePJqjpe7p+/8m QMCJPDQeKVMx4ezFk3QQVdPny7Iqi5MsgukjUBO+FDede2Fc9auClY/3UNbI1EeJUwJr wSEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=Qb55dZPeepUrU4dONRVCiplOK1WRN2GzgymWvixZoMg=; b=Gv+odKLdPAjkHyFM5OQ4L/dZ4OGdysBPSziamlJjpO4MunAVLfgVTIg9WN8Y2TKahG 7Bkvtv5ZgH4MKj4Vqrgcb7UtZKeENr2mk+3GXUHzaQO80y5wuq32WBvVoM/YBXpd5y16 4DkoWv5QcgxdC6F//dJHrZsRgrt9itz+GAr7d55xx+pir+xqrGkRJIw2lH6WfBDWS3/E pEk3yAypmwIIvNuOmwV8d6OaCfqmAmfzQxmIvOCThde0Q5Nw/wMTSicGrak3jHuJogyD AGiob0WhHLgiJJUGf2MygESptX/HL+RKkEB/5tlh+xrh/u1aVbJCfx/JE+XmPJv2Nfwi 7okQ== X-Gm-Message-State: AO0yUKXb2dhNaROb/yP0Niyp5g7GLAcI81HI/1TZIS6guRnbP74MRs56 HL1+asR1D0rv0UfhygaIu+4vld2RxKxloQ4QZn7ADw== X-Google-Smtp-Source: AK7set9r3qcQFvPGmSBKOE2p2Dur7dojJoZY7jIMhwlJcCIVaJG5DIhQnDd3GTlaHrTkINqqtCRHtwU34sRjaK5kIvM= X-Received: by 2002:a5b:8c8:0:b0:821:e4b8:8802 with SMTP id w8-20020a5b08c8000000b00821e4b88802mr443293ybq.142.1675792299969; Tue, 07 Feb 2023 09:51:39 -0800 (PST) MIME-Version: 1.0 References: <20230125233554.153109-1-surenb@google.com> <20230125233554.153109-2-surenb@google.com> <20230125162159.a66e5ef05fecb405e85ffec9@linux-foundation.org> <20230125173449.5472cffc989dfab4b83c491d@linux-foundation.org> <20230126172726.GA682281@paulmck-ThinkPad-P17-Gen-1> In-Reply-To: From: Marco Elver Date: Tue, 7 Feb 2023 18:51:03 +0100 Message-ID: Subject: Re: [PATCH v3 1/7] kernel/fork: convert vma assignment to a memcpy To: Suren Baghdasaryan Cc: "Paul E. McKenney" , Andrew Morton , 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, 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, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, jannh@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, gurua@google.com, arjunroy@google.com, soheil@google.com, hughlynch@google.com, leewalsh@google.com, posk@google.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 0B4994001E X-Stat-Signature: p5u5xj3ub7sro1q7f1c79s6jnjkj7bia X-Rspam-User: X-HE-Tag: 1675792300-761397 X-HE-Meta: U2FsdGVkX19dI5301ZcpE9jbDaIK6NSXKyXSVaYPXe7PBfZoKpBz2RFQS3CBYEI3z90/MB4hBsn9sOlxFH3u0HYHnYgLXwIa/5cQA8STXzxoourVXhb5xJjRhC2rbZrrLRnYz9lZTuY7ttgiFpjN/+Tiq58xfQQFrnm22oN0mDElADe7Qo/we5PK4Qd4qUaW4k55g0q/lfZv4p7iixk60g8YReJtoODxXHLYIHiHklOMb0XDmUYiJkRXbEq+8YYNKfdi983lwu4aP23AoLdrkYwrrITjL+1z6LE1PYZ2Mk+xiPV5m7OPtQTUq1shHnnq+XlGDIfpsk91JS0IuaazF4xL+H2n4nUcFbqJIT4FTHpJcynPOLnsmJ7ANXDxFNlXJ9ZpOOSnmuN8VYsGwJnNiU+HS9bHvsVVm5n/cnP0GKUAfZVctPNt3Pbt1rdefB230v8Pb6zR6wXeZWqWNM+rf26zwR/iklM+C3qjEMxQ8Sv7ulUeW1g0ai5MSEKbUiUPLGMUg7OBhKhcuvGHkW97cphSMCU+u5vTyA602MfvUdvQJqDhNbexfzE7zES3/fpn/kYEkAgrMRVWo326MBT0g0LUczCXED9RtAS6z/ZrMdm2EhlB4Mh/RB+Vzys5mtWQa7JL++CHMJkEgNuSBtnXwEsiJL61TNyNhoq41ksimRp+3S5joVdD4Ed1yj6Dsoe+hR5DRMipzecbweFZP482hJ14RRA92pexRoF/4wRg/NRLoEo8OHjD2QQOpIRqby98n9Mlhh2AOArUXlcEWBX+vtLqnN2BQPios/NoRdH5qbD29xJzD3q+ckXch3ebmvq9TfVgyrAb2SuKk/mU5B4MeDxx/J+Kd7HmjpHQBBVawiuEy3Ui2fhmWbVMiB5TTSGKicHqEI2gXhmLuaMXnkbt0jjyshKlwRmL752qR66AgbFMqXSKZxVhoXzcPBd+G/gEFTPb1ODzp8+hmpRYtIQ TkM2Hui4 gFjNZXSifCyxyiTjnjPWnPo1PnWnNxFJNCJAADRgXtvFQ8kQvV/Zr/0Qzt3EkdyyquvHjANsyJew2WarLjQncrQ2Hr3sk7okiZETPeM/EY9vsTJlusNIvT2reFmikrx7FksxlJ4hLLn/7SH/LVTcIY/D96ferfuz5eBx7oaQhHKsjsLNyTycTHcDFvy7OTaci7djLDjbLTYhv+7uheDBVBDLxDhBHxEAL5RkTRTadVLsPjNvXVf0iqG9C1eUILxEP1xzrg5tp6l7Vp+/xEPbv08TtrMOKfOrFmJKzgjUPQrJYFwTAVGKc+VEUI1ZrZD09zB078rbpkYuHJBiADrHRP2R1btXoZ6SrdjLooLqJwONAAKiXbqpgYFGuIaq9ZXqJLePT 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, 7 Feb 2023 at 18:24, Suren Baghdasaryan wrote: > > On Tue, Feb 7, 2023 at 9:16 AM Marco Elver wrote: > > > > On Thu, Jan 26, 2023 at 09:27AM -0800, Paul E. McKenney wrote: > > > On Wed, Jan 25, 2023 at 05:34:49PM -0800, Andrew Morton wrote: > > > > On Wed, 25 Jan 2023 16:50:01 -0800 Suren Baghdasaryan wrote: > > > > > > > > > On Wed, Jan 25, 2023 at 4:22 PM Andrew Morton wrote: > > > > > > > > > > > > On Wed, 25 Jan 2023 15:35:48 -0800 Suren Baghdasaryan wrote: > > > > > > > > > > > > > Convert vma assignment in vm_area_dup() to a memcpy() to prevent compiler > > > > > > > errors when we add a const modifier to vma->vm_flags. > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > --- a/kernel/fork.c > > > > > > > +++ b/kernel/fork.c > > > > > > > @@ -482,7 +482,7 @@ struct vm_area_struct *vm_area_dup(struct vm_area_struct *orig) > > > > > > > * orig->shared.rb may be modified concurrently, but the clone > > > > > > > * will be reinitialized. > > > > > > > */ > > > > > > > - *new = data_race(*orig); > > > > > > > + memcpy(new, orig, sizeof(*new)); > > > > > > > > > > > > The data_race() removal is unchangelogged? > > > > > > > > > > True. I'll add a note in the changelog about that. Ideally I would > > > > > like to preserve it but I could not find a way to do that. > > > > > > > > Perhaps Paul can comment? > > > > > > > > I wonder if KCSAN knows how to detect this race, given that it's now in > > > > a memcpy. I assume so. > > > > > > I ran an experiment memcpy()ing between a static array and an onstack > > > array, and KCSAN did not complain. But maybe I was setting it up wrong. > > > > > > This is what I did: > > > > > > long myid = (long)arg; /* different value for each task */ > > > static unsigned long z1[10] = { 0 }; > > > unsigned long z2[10]; > > > > > > ... > > > > > > memcpy(z1, z2, ARRAY_SIZE(z1) * sizeof(z1[0])); > > > for (zi = 0; zi < ARRAY_SIZE(z1); zi++) > > > z2[zi] += myid; > > > memcpy(z2, z1, ARRAY_SIZE(z1) * sizeof(z1[0])); > > > > > > Adding Marco on CC for his thoughts. > > > > ( Sorry for not seeing it earlier - just saw this by chance. ) > > > > memcpy() data races will be detected as of (given a relatively recent > > Clang compiler): > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7c201739beef > > > > Also beware that the compiler is free to "optimize" things by either > > inlining memcpy() (turning an explicit memcpy() into just a bunch of > > loads/stores), or outline plain assignments into memcpy() calls. So the > > only way to be sure what ends up there is to look at the disassembled > > code. > > > > The data_race() was introduced by: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cda099b37d716 > > > > It says: > > "vm_area_dup() blindly copies all fields of original VMA to the new one. > > This includes coping vm_area_struct::shared.rb which is normally > > protected by i_mmap_lock. But this is fine because the read value will > > be overwritten on the following __vma_link_file() under proper > > protection. Thus, mark it as an intentional data race and insert a few > > assertions for the fields that should not be modified concurrently." > > > > And as far as I can tell this hasn't changed. > > Thanks for the feedback, Marco! > So, IIUC Mel's proposal to use data_race(memcpy(new, orig, > sizeof(*new))); is fine in this case, right? Yes, that'd work.