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 29111E77198 for ; Tue, 7 Jan 2025 18:05:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B41676B00A4; Tue, 7 Jan 2025 13:05:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AF12F6B00AA; Tue, 7 Jan 2025 13:05:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 991EF6B00AD; Tue, 7 Jan 2025 13:05:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7D1626B00A4 for ; Tue, 7 Jan 2025 13:05:36 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 2B860AFCB4 for ; Tue, 7 Jan 2025 18:05:36 +0000 (UTC) X-FDA: 82981433472.26.224896C Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf16.hostedemail.com (Postfix) with ESMTP id 4EB94180014 for ; Tue, 7 Jan 2025 18:05:34 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="E6/orVQa"; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.160.178 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=1736273134; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=mi8vUyECGOxZyI2yWyC7X/khIQlYQruZTzmD5xskgiE=; b=B7yjnA7SrH/52LEIdQurmUolCPW/5d7KyF+XApCouOhCgeS9GMuk3XrD+wfnu2kE3sMspu mnszwJwPcr2BvD4tlezMWhmaWMo3is/RzIQqfEONFoyg9R5p38CKeBdz/sBQ6rcE9DpNh/ I4q9lA9z7vWRomVZAoCBD1eJ//xzv0s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736273134; a=rsa-sha256; cv=none; b=BJWRE86l7YnuGWIGeXzOcmLkg2Vn96ZYBNxFIbX2oAVAv27F9kdWMBpD5cO7vHrCI/y3yv RJAO4ORUkTb0EYmGi3NlP/B72FaxLGZq2feQn+U/yAxX6zKSBqtlaFNTJaKoUP2daaaRcH t0Jom3U4mKz9/+sxN5LPGCrhLXkswnY= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="E6/orVQa"; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-467abce2ef9so11551cf.0 for ; Tue, 07 Jan 2025 10:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736273133; x=1736877933; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mi8vUyECGOxZyI2yWyC7X/khIQlYQruZTzmD5xskgiE=; b=E6/orVQa8dpwHnovLwH/t/Abwcxw/lYW3/9y/kiH5ZEXXE7GMlfSX+4GYAG0P8lsxj f0PkYN/WQOg28zO4bbYa5nhoIf4V/L/swpsXZ8GvCr7IvWZ44WHauRR7da+bX/E5BQnQ xWCroAxSEBB0feDaCgrI/RF1SY/yUHUu+sDQc5cHaetyiMlzb6jVAzw3zWWtZ3DbbguS UwBh7xVUotDarhdDftGayhixfIQoOnOc4T5i/h/JMP3kNg/Vl14Y1hdS9/aTzLQE9G6o kxSg0yae9ywqN48TTpPmxQhDa5SITVHrmBOWj4wXh380cw6jAlJqRnkn8yiWBVhqbUGP Gejw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736273133; x=1736877933; h=content-transfer-encoding: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=mi8vUyECGOxZyI2yWyC7X/khIQlYQruZTzmD5xskgiE=; b=VrLgpfxbMWsYnOyoSvLvVCn0fOcrUBTcAy1Yw6OMqnCEAikmkGE66RFpuSLWdmJ/a+ kkzU+jPdLcvVMo0xfNptX1sZzDMMoxlo0+6LSLLMB1qpL4sc4OmdF2tz7UroVGKrC159 Gv2WIQO0EXaHTHA+BjGyW3kQ88JofXtTUovU3MWjhN9KgVkK1iMZF6j5rF44ELO6KKL+ tQSHhoLNICssxXyq4DqZus+cFvRAXfspdsV0XGLv10A/M7Rw3SvhWwapWOW+CwwO2Fl3 WAoRN+S4PTyfe5mV3MGrBcUJcluSekGW/mlf1O0EXPzybwtXlLAmoeZBd02zb99xbKLB VXhw== X-Forwarded-Encrypted: i=1; AJvYcCVQ4Y7w5Y9LJ/G0SHrdvNX0L9WMsxLS1hnMo9ldwMsl8nUadSB7Atz5yw2Yi3g/RdBDhKtDW4qt3g==@kvack.org X-Gm-Message-State: AOJu0YwkYWeGBEXr1d8axwtOqdB7DVl7YTVZm6rqahzR4UXLLO5MXurc QKuTEac9JfbqyHgXisCVsmaD1A4NB4/yv344Uofyv8i/JtqBIb+yQP9pU9re1rq4Nc4ZJqM5Uh1 T+6/0EcOKPDRn0UR/89PCH0RJmVPIi+wZ473w X-Gm-Gg: ASbGnctzM7cAkDmklZ/WP3VEev108Dmb4SIOcckt//hlpDuOPhRSQZzsrM7XoQpu6MK TqHqyb4kTiYpcQXKxAXmnKydHeTy9D8+6vsAdBR8wXqVigyQ0kJap4bDsxqu68Tc5lo04 X-Google-Smtp-Source: AGHT+IE9ZiKToP85339GTZL6knFJDZBH+wPf+2gn25k4vD+HxjpROcu+RjNoaUFbdiUIvUqxGVNeySX8ejHQjchcIfI= X-Received: by 2002:ac8:5884:0:b0:466:7926:c69 with SMTP id d75a77b69052e-46b3b7fcd36mr4985011cf.20.1736273133124; Tue, 07 Jan 2025 10:05:33 -0800 (PST) MIME-Version: 1.0 References: <20241226170710.1159679-1-surenb@google.com> <20241226170710.1159679-7-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 7 Jan 2025 10:05:22 -0800 X-Gm-Features: AbW1kvZEgazQlT5cnwjr7aCC59gUjm4MXlBVLcsCWU968CA8pQ3U-eS0rzVVaek Message-ID: Subject: Re: [PATCH v7 06/17] mm/nommu: fix the last places where vma is not locked before being attached To: "Liam R. Howlett" , Suren Baghdasaryan , akpm@linux-foundation.org, peterz@infradead.org, willy@infradead.org, lorenzo.stoakes@oracle.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mjguzik@gmail.com, oliver.sang@intel.com, mgorman@techsingularity.net, david@redhat.com, peterx@redhat.com, oleg@redhat.com, dave@stgolabs.net, paulmck@kernel.org, brauner@kernel.org, dhowells@redhat.com, hdanton@sina.com, hughd@google.com, lokeshgidra@google.com, minchan@google.com, jannh@google.com, shakeel.butt@linux.dev, souravpanda@google.com, pasha.tatashin@soleen.com, klarasmodin@gmail.com, corbet@lwn.net, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 4EB94180014 X-Stat-Signature: adho9jhzqajr5zc4sogs45cwfiirixcw X-Rspam-User: X-HE-Tag: 1736273134-785438 X-HE-Meta: U2FsdGVkX1/4Pov8rj8nrKpKK6l7xyjrKN3ZttosNWjDjwE1x2875O1IvgZH6i9Yf5ahOGonv7AYh1S52XBBMv/clR41qXPX7dHFdxaqCbI9F41Q/Iw5hu42RdlLSTHB2m8wiJENFoyzUZ9XHiGe/DdADcOefFV56/b0pJ6rF6V6BeHsetXPvGcrat4L6GK27t+gIrKhGlwgMmQJqsNX/9YdObM11PV9OvnWlppnir7iU8G6XAX7t5NDl4/JYIJnVDn2rYtQ5H8Jg2IVCsYHQ1Vb1Re+sjYu1X5fdqCsA6qWMBbISJnNIVF05ikfdPKh+QmSGF0V9/+kgxEiDa8kmwDevX/c3FZNiH361JYH6mS5h3NpOeBGHTkqQqAbu8TyKsE88Dv8qoVEucFOwjKbScDOH6+lDKOjp1032niURPLRbdQgUmC0Pyw90rliLRXy4eSctCgX7Qmx+0mfkwL+naSmP9rR/UMDvrWPwCdvMVVZKGER+jv3xcgbwsq61+sC6Wfm+vqxQBk8wiu2PrvvjxnjAHQBAqTFpDEUsjmPK/eUsQbVkLW3qT9V1XxSUCR0qHGclkwFsIbfVqYzmv6h3zBa/qEf/ysRrdsnEAgXRdPtGYcKTKtjRjnNIlqt9XeidvG2Us2jTHVVAe+06JHus+kt+fc8uh7HKIBA5oAL8bhJTFgzOlWKeIqSDC1CpPHMOxkl4jFEZMTe+HmRG2e3obWkFdMv7PQcycHUfS2o8C441AecHaENqoBE/hrcIE2Ig6bHgNsuAy4Hs2McXmX3NwM02LTu176GluuZbHSOa66LJG5I9t6fW4w3uT07pTJ0ghVOKOh9jq+7dO7KJpq5ou9EqfruVTpudAL6k1gA59mq+HtzeZFx8aC0+Vz5GNqSgwExFVHQ/u+jQVf5YwYekLMy+ri5lm1Zp7tdw5Q8mAbMVrOIOvzMbighJ93Vm17OTOctjDk/k1Wh2nmmubE nkbamigm ibvkjtZpaxx2cY4zFu1JpYI6yLLYbgChia7w8YrQi58pessqW6HQ1rBV9UZE2Neg8ZRJAykOe7IMrXbQ/8z23k+ECFy1WcfVUTqa6beJZpEFL/IGMgWj0X+hMxDXY/4QcIHcbbSgIKZSXWnneoxdIGd+sy5jWyjA1jko4+7g5VHv2tCs7vK1WF2N7FTlh1SjWpn+dkVSadUXymlwoNTUuh/vrS7jKHsKxfJY2WCAEzwDbBPsPgxZaV1choIC8zjxR38/9xtGgVYweQTY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000053, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jan 7, 2025 at 9:51=E2=80=AFAM Liam R. Howlett wrote: > > * Suren Baghdasaryan [241226 12:07]: > > nommu configuration has two places where vma gets attached to the vma t= ree > > without write-locking it. Add the missing locks to ensure vma is always > > locked before it's attached. > > Does the delete side need to write lock as well? Ugh. I just realized that CONFIG_PER_VMA_LOCK depends on CONFIG_MMU, so this patch is not needed because all these per-vma functions are NoOps when CONFIG_PER_VMA_LOCK=3Dn. I'll drop it in the next version. > > > > > Signed-off-by: Suren Baghdasaryan > > --- > > mm/nommu.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/mm/nommu.c b/mm/nommu.c > > index 72c8c505836c..1754e84e5758 100644 > > --- a/mm/nommu.c > > +++ b/mm/nommu.c > > @@ -1189,6 +1189,7 @@ unsigned long do_mmap(struct file *file, > > goto error_just_free; > > > > setup_vma_to_mm(vma, current->mm); > > + vma_start_write(vma); > > current->mm->map_count++; > > /* add the VMA to the tree */ > > vma_iter_store(&vmi, vma, true); > > @@ -1356,6 +1357,7 @@ static int split_vma(struct vma_iterator *vmi, st= ruct vm_area_struct *vma, > > > > setup_vma_to_mm(vma, mm); > > setup_vma_to_mm(new, mm); > > + vma_start_write(new); > > vma_iter_store(vmi, new, true); > > mm->map_count++; > > return 0; > > -- > > 2.47.1.613.gc27f4b7a9f-goog > >