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 B53DCC001B0 for ; Fri, 7 Jul 2023 20:03:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 57D566B0078; Fri, 7 Jul 2023 16:03:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 52CE78D0001; Fri, 7 Jul 2023 16:03:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F5316B007D; Fri, 7 Jul 2023 16:03:28 -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 30DA46B0078 for ; Fri, 7 Jul 2023 16:03:28 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E57831A00E9 for ; Fri, 7 Jul 2023 20:03:27 +0000 (UTC) X-FDA: 80985890454.06.4EA98EE Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by imf20.hostedemail.com (Postfix) with ESMTP id 925FB1C0018 for ; Fri, 7 Jul 2023 20:03:25 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="0aTqwR/d"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of surenb@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688760205; 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=jiYXPeVVhPYiIi5FqOxRE62I4iZJmKF5ifkdaBLEcDA=; b=QQ9ExBzot+Bd7C5UPytUIGZ+9MGg0lpb07nMMfKHXy/+BIUmOmplZ8R1LO+vb8AInSrvmT 8K0f0ectjKMMXqPMcBWiXSRcedi9xTKjOoQeH4Z0lGb5QSBeaWSm+jHmDaV4/7BeCHvoWd KCqOBJJJrwrrakn2M0HWq5X21OWqHqs= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="0aTqwR/d"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of surenb@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688760205; a=rsa-sha256; cv=none; b=zKhtSogn41z8V0Dx2ERXyUzaGXqKx1zXwET1RdBL1nvsquTE6bEFOVRGql6DKKsKMfKMI4 INL8Bn0B7fxYW7X3FIfsydSkpPw8Q/1QAau8tlGPyqcU3WQodEVZj1obQge4F/HVwVhLkd iwwLfkWjAgfS9MbPbBfAuYlbszOVl/k= Received: by mail-yb1-f179.google.com with SMTP id 3f1490d57ef6-c5ffb6cda23so2586398276.0 for ; Fri, 07 Jul 2023 13:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688760204; x=1691352204; 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=jiYXPeVVhPYiIi5FqOxRE62I4iZJmKF5ifkdaBLEcDA=; b=0aTqwR/dpi0vpYuL7RdUssVpIH0lUmB7Xo91oQVnf+ilkQDF98MAWO0vCOgJKJskml HDbMD8n4sTjxGTKqIrLBS+zpYcFfkT7M5RxXAUFaZ4RiffjjlN1JI7lYDC6Z1wUBEOyE bCstYIYNMrmLVmCEvJmDg8oJyJ4pE/rRVwfx3rgVXQIWDsf1LC+nuTul0LXi2F/5rl9F Fh2d5JBeZfwz0TT+GS7rDI07SGX5MnjlPhfVvpjOQzlp/ww+KftyoZX1hxmwuomie533 6qez7jIIBW0ZBqRpRUT/ZMWM47LVk+VMAnvg3VAlbRS46l6F//g2kgJFK6uV8Qskg84V 5zcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688760204; x=1691352204; 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=jiYXPeVVhPYiIi5FqOxRE62I4iZJmKF5ifkdaBLEcDA=; b=i0FxkopPwuELi72I5zWqseBaUZtiBs4YEAuXzkkizKBWLlZT/tCLYuJ3Vc5MGf+Gq5 u2y/og7DF7TG2mrLeqfcuHQoeLPPU5pCr0ZzbVIA4NpuprBXWwq5fq9EitOF0bV7Dnpx cSheHXom/ghsA6nqW/mExRMy/+Zsy1UidG1dcAwNNPW5IKdn67dVf+JS5IljiMaqiIDs dNOhE/fvPUumPtvkhSfkBRMcSM2rrq+W9E3ueW3xuhwClJ8EtMh0QSOpW3aaIXzWeSWk EE4M0eFJSoEZznutoNLN0H/m/PL7pVEh2SJL6fsT/xdF/hSINJps08DrRzeh0EOny9ha HxEA== X-Gm-Message-State: ABy/qLZ4tRTMwXI3wx96VRqXxOff6+kp2rULwJCjvCLzHDs3tQqbR44t UJMyjdT9OP2DRYM14UDvR3wi1zDI2JgetBBJxvxuwQ== X-Google-Smtp-Source: APBJJlGW6vzwmyM80moGDJZ2wgLQhm/Wo3bCA3iZE7mjjt+A012sDA18VUZL6P8nzQcPyYNuTqQi5GzZBXcfIV+8ic8= X-Received: by 2002:a5b:44a:0:b0:c0b:7483:5cf0 with SMTP id s10-20020a5b044a000000b00c0b74835cf0mr4783782ybp.65.1688760204437; Fri, 07 Jul 2023 13:03:24 -0700 (PDT) MIME-Version: 1.0 References: <20230707043211.3682710-1-surenb@google.com> <20230707122750.f7cd77fe19b625cff37423ed@linux-foundation.org> In-Reply-To: <20230707122750.f7cd77fe19b625cff37423ed@linux-foundation.org> From: Suren Baghdasaryan Date: Fri, 7 Jul 2023 20:03:13 +0000 Message-ID: Subject: Re: [PATCH 1/2] mm: lock a vma before stack expansion To: Andrew Morton Cc: willy@infradead.org, liam.howlett@oracle.com, david@redhat.com, peterx@redhat.com, vbabka@suse.cz, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, hannes@cmpxchg.org, dave@stgolabs.net, ldufour@linux.ibm.com, hughd@google.com, punit.agrawal@bytedance.com, lstoakes@gmail.com, rientjes@google.com, axelrasmussen@google.com, jannh@google.com, shakeelb@google.com, tatashin@google.com, gthelen@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 925FB1C0018 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: ngoofd9jma9ptwdccf8acrjxzdudkxsb X-HE-Tag: 1688760205-879513 X-HE-Meta: U2FsdGVkX1/wAfNXcZJ+4utgD3PQe09UXYZuWJkc1oALOGQ4qb3NMQAaqsxEuSzUPsUbLTQVYYZrHEIAP8nbIFtOtVnWPEiTqZLVanaS0uxI3ZPes1Ah0x+oXmEmmepQ9dMbe7shoZsNQWlo/SySLHAexowj7Upq7GN7s/NYHXDXdc37ubxmuW+AusxWeKC9nf3X2XKry6cp+5piV+mqfJgtPEo4DW5Q7kPKQ6Ueh0ujo3YJ1cEXNJSyMPpr3nEe8307kYl5NNcsHW/wyVH6ZHFWBAz+S1ODPhGlrcpTOIHV27DHqBXqIKQH+v2CcgzEETqHEJ9okAgb3SH/It7FX1hyZWRrxVlKr6hUOlRUh7xWAyZBXpkjojbeXo8JSLfTyDzBNaTHthA/B7BSW0XrjtV9HQtH9MATPAWgVLIf5S9X59wH1fu05H1I3hEGZbGhQgPOTL3Yweerx96Ys5C8qnYkWwmZecByXxPtFGaTEzCLkN15OH8B8pWC5RaFHgfUFzPH2V8uQLZsSevEZAjzi9cX5HNerwwTTLKkOX/bTBYc4pAx3Jp4dNBUPdjJJP6zQXP4JcG3nrwes2SSovJ9WWGrLgSwgF3LCXvGGCscwOZwW9tmuFy+X+JKHgL+cvPaAlzYSlUrVd68LVa97Gu/RXbQIBIH1/ZqSVyAcrw53YdoxRWN/RItztY4x7rjpj0xuO13g4FC5eROSGdikSXP7ZpNedVyIx7HHSB78wrfUr5T/GMOCi5x8roTOln8LtUpWFppbO1ATwh8n6Ypc4l94gkyRWDohiA/zdsF37mLVj6qlpq+gUMPbmhvN7pg6O7zka4g1RL3BYWksLjTyrBxHAr6GcKDj7UIZw8m3OTlzp6uVLAvgpcTUI3XUtj7poR20Jiy3VzaicKle6lexMGKrsSe1ZSxTYujbx7ewmA1hDx+jm2k9cd9k1L8Du7nzPmjCT5JHQa6RNVBX5avW/n fv0n5CXr g966JgmZVycml0YMor+UudxG53R3Xdt3hg52dT9QsgjI5D5l4B8cFPMY8ZMsS5hU2ymQPem6sFWE/ZJY+vIj9Qb2LxJZUhN0cU8VleUYnfU7B3rKSt8aJT9TlF/vSBq1FctMFSi/ZM3kT/dSUoZZmq6S/IQfpPIK7Hgb+oOgSIAZ+w1gnw0xvP384lwv/XJ9BSkBkQdQa0XWnsiREq6Dy5WfNmsTl5epa7qU8zQvgMLDhEko2zCjnQ55xiCVc1PSXm6qsWMVgnS+ihmJO476poxsidZQtqW1nufpbFs3/NIfuylth+NSbuZRhicowtDSC2mj1AXjrzwZYbtzm4iWujkg+7oGLqD8SNJKn 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 Fri, Jul 7, 2023 at 7:27=E2=80=AFPM Andrew Morton wrote: > > On Thu, 6 Jul 2023 21:32:10 -0700 Suren Baghdasaryan = wrote: > > > With recent changes necessitating mmap_lock to be held for write while > > expanding a stack, per-VMA locks should follow the same rules and be > > write-locked to prevent page faults into the VMA being expanded. Add > > the necessary locking. > > What are the possible runtime effects of this change? During the stack expansion concurrent page faults would have to wait and visa versa (stack expansion would have to wait if there are ongoing page faults). I think it's the same runtime effects as the recent similar change requiring mmap_lock to be write lock before stack expansion. > > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1977,6 +1977,8 @@ static int expand_upwards(struct vm_area_struct *= vma, unsigned long address) > > return -ENOMEM; > > } > > > > + /* Lock the VMA before expanding to prevent concurrent page fault= s */ > > + vma_start_write(vma); > > /* > > * vma->vm_start/vm_end cannot change under us because the caller > > * is required to hold the mmap_lock in read mode. We need the > > @@ -2064,6 +2066,8 @@ int expand_downwards(struct vm_area_struct *vma, = unsigned long address) > > return -ENOMEM; > > } > > > > + /* Lock the VMA before expanding to prevent concurrent page fault= s */ > > + vma_start_write(vma); > > /* > > * vma->vm_start/vm_end cannot change under us because the caller > > * is required to hold the mmap_lock in read mode. We need the > > -- > > 2.41.0.255.g8b1d071c50-goog > > -- > To unsubscribe from this group and stop receiving emails from it, send an= email to kernel-team+unsubscribe@android.com. >