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 6FA64EB64D9 for ; Fri, 7 Jul 2023 20:15:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C2FF78D0001; Fri, 7 Jul 2023 16:15:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BB9F16B0078; Fri, 7 Jul 2023 16:15:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A59A78D0001; Fri, 7 Jul 2023 16:15:44 -0400 (EDT) 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 91EB76B0075 for ; Fri, 7 Jul 2023 16:15:44 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5BE5DC011B for ; Fri, 7 Jul 2023 20:15:44 +0000 (UTC) X-FDA: 80985921408.17.65B7B36 Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by imf10.hostedemail.com (Postfix) with ESMTP id 3D72BC0016 for ; Fri, 7 Jul 2023 20:15:41 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="m/Y0L9N1"; spf=pass (imf10.hostedemail.com: domain of surenb@google.com designates 209.85.219.169 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=1688760942; 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=fNpKXy7AFxltKv4uN+DycBwBsGRtWweYUYY9rGhaZYU=; b=TUF6DypZIGWvl0jyI7SuL7dk1S8GZ+b3S0IcztlZzXEp3YzF78GvVs8RqEmDHfelc5mZJb 4drRCKBzSBqO0J53ZHHkLlRTqdgpAcD6vwiNVnjQtwlR3Udp068N8CkGu4I0VtECNn76xQ kj87OWnDCcSgEf5Gz/W71mFwcrKIGhk= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="m/Y0L9N1"; spf=pass (imf10.hostedemail.com: domain of surenb@google.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688760942; a=rsa-sha256; cv=none; b=NKoDQ4OqYGKSeEGZqhtFBoZauv4KMQQWuGVmAHilVwQPumg5YHhLLs4MZWKM6yH/5fQV2h ORvblTcEf/+PN3wQRcopHPnc4Y3pBUd2MR1ylimxNm3N4Rda6fL4gcuSZ24rqjQVRnbO3M FAwX+dzD0mtbm2x2Ey2jZ0DDtmYsnac= Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-bb3a77abd7bso2571561276.0 for ; Fri, 07 Jul 2023 13:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688760941; x=1691352941; 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=fNpKXy7AFxltKv4uN+DycBwBsGRtWweYUYY9rGhaZYU=; b=m/Y0L9N1Ha8XkEN0zuqSzsZykfZT99fJBZExeWA5YQ/ctbMVRfut9kxGleMJksQk93 o6wKkc+hj1/0cnv+rtL3aHH12HTdv7lsAddD03D1fP/Zd27pcAGefrAUIK9ULJ5nhadZ fbcHvPuLUNOhWf7sm4V7F7NV1H5bu1QKHFEXRtVe1OdvCdAllaXuY+TLC8y2DRklYDCV a6vOKyBqh8YtbwI7jGEtnGb4Y20188PzEDc9VICkPg+RWoLgRI5xll2xMyZ+4eXgxmaI zbzejy+1xTNhSJd9FTUkJtxxmsaoUXbuH5M9w264gh/7Y9oeN3RAPziorzkhHh6oPv4Q MuIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688760941; x=1691352941; 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=fNpKXy7AFxltKv4uN+DycBwBsGRtWweYUYY9rGhaZYU=; b=B7YoLut/72VQIiPynUS7SeKvf09m5CgbJSeD28vxFzGkkU5tBCYrSzq8qFegiWCU1i LVW987aiQdeARLntG9+SQ1chc7C1QF6i8ZMGfNpu0q6FZZgeeRonJH0Y5SZcZoBIR7GX SJ5BZk+dNcJR6x/FqK/rg1bQig290i8wkbudDkh24k84hYT1kua21un4BjLplzcxFWWA a7glw/VnivxvsImKRonZc0jrsnxpfubZfJBPqcxZ4nVUKvppTWbPwZCi2p49upG7ygom pmnHTmVB28GIBn+aNDPdKiNOksarKMWW8pSZJaEPnc1GocXnbQsuVFP0VpdwL0DLFCtn wYGQ== X-Gm-Message-State: ABy/qLaCoFunR7QAe89EkYch4V4NSVu812SbXn2ptPWO5X8eIaiK1Yx9 HcXKeYTroJ025Cz+iyeGNt7iMFwrDAq9GzrAP3IKlQ== X-Google-Smtp-Source: APBJJlGElQexIBo1pPYN0IUfTDXFWBoRHXjH/BQWjQv2+HNUlfs2N/wgEwulUlEQU1dbMhD/xF1TMFid9Dd0E7oqp5Y= X-Received: by 2002:a25:69c6:0:b0:c15:cfc4:45a8 with SMTP id e189-20020a2569c6000000b00c15cfc445a8mr5942453ybc.34.1688760940826; Fri, 07 Jul 2023 13:15:40 -0700 (PDT) MIME-Version: 1.0 References: <20230707043211.3682710-1-surenb@google.com> <20230707043211.3682710-2-surenb@google.com> <20230707194829.u3p5zfjckmh6lktx@revolver> In-Reply-To: <20230707194829.u3p5zfjckmh6lktx@revolver> From: Suren Baghdasaryan Date: Fri, 7 Jul 2023 13:15:29 -0700 Message-ID: Subject: Re: [PATCH 2/2] mm: lock newly mapped VMA which can be modified after it becomes visible To: "Liam R. Howlett" , Suren Baghdasaryan , akpm@linux-foundation.org, willy@infradead.org, 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: 3D72BC0016 X-Rspam-User: X-Stat-Signature: 8pz68ubx5wu6kdb4o1o9t1aingumiwyy X-Rspamd-Server: rspam01 X-HE-Tag: 1688760941-447784 X-HE-Meta: U2FsdGVkX1+OyHVLeUij5gcthvsdIYVPvquX/2zSV137LtymMBZ2FZOhTFErBMkMXEqnzZMrrnSNYmA5atGWKUGLqixPWb2cYH8HbplifcTEDudOXjH0ZNxLWFAO8GUHvVVepgDESt3xGkl4dzd1Z20aIsr19FG6BA/mMaBCDC/YynO43FvAJW2108y1kMZTqQcyoiGkVQhiuAXukAnViKiWyNECjnQIjU6foZLrLr4LZbPV7mBOX9bvdjO3S9y5V1hjvbh5boiqkH+/293/6Nmg0cxe6zXYoouMRfoQ1WnNKMW+zkL6YY74hCH7bu7O6i/oSfW5ynfxWIUFQRNhhUhl3eNkuZckRiMBunWu6IHjXyMatJSVgjSWXkSmsPquxgB+WVdcjpv1K4QgUWIeiXZffcZRce2leqqlkmSdqaN0TKhyCTzOI5VZn9omNIKr7deELgQmca4X/s6Yn7EobygylzckcJmK8gzuJN484WxdcztXpii89mIq/7t2a+9jLm6G+ELa0k+hs7kAQXJMX4auBbsF8j2x/Lz/6fEumIZkQoWXSb4IlZK8Hp8w915ub2oWT+qpKmMUdZrbIiNkZRPWvqjkGCXBrfMxfpIN31isIA/N67ld9h/6QjMh2Ok5vazCc2SPv/a7ltB+wgU8wYARxEI2p0o5Ur368GDtWwhRKC81GAj+pSKDABDbJn1NuSED8xMR5BUSFbXKPFhl15jfotr1kMLyAUEfw26WwXQtBRpEqURLnQZ+5W6q1AGYl0xTcH40rx41MGC473uFxby9AlbpQiPxGefTB33eNonsxiWXMn76t0Lbt2gR/+fE9yH7B9MQ0Q8rMl8jaHTRnLcC2yDJZwTLZfaPmo+tq+OQjGJliz3RlMUGSSO6pqOs66SPwqBHa+DxacodiX/j+YABcFsieaBHZAwMHFWu+G6nVt4r5Gx+X7+bDd+yyu/1ZKxT7/Q1fcdLcszVmoT WNtnCQJq /TGr8AZzy2YphzNgCfTJ1OXBBAevc+9R1I+l3t3fAleunP0DgQ+uzx2ah2dRIqoxO65TVwae0t9VOKpfEdrrf2VGjxIN1TUp0Hs+R/WePfwGyhhMJZN9WnuDmeWRygBpXnieveazm9lEodihp6zuq8Nq+ZMvW7SoskZ8vLo8dW4MgjZLUkY31aU3jqQKToYxmB/hNrmzdrfxurKcMd5st8c897mgRr2PPTUdjuHxF26iYpivihlNTIH5Z4uzkXtwHz2ubv44O9WSA7UweEhlkx3z63q5sam4TR4xQCq8x4bYC9S7iTyLY4iTfZ/RhmP+SQ24Mx/tXNSn1A95luv2pUOEIo/Ex48eNwhTHuHgYMRwjQtUX3Q7ZBAeutwPuWuBGMMsZ29TW5Iu+03XURS0OhJtARA== 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:48=E2=80=AFPM Liam R. Howlett wrote: > > * Suren Baghdasaryan [230707 00:32]: > > mmap_region adds a newly created VMA into VMA tree and might modify it > > afterwards before dropping the mmap_lock. This poses a problem for page > > faults handled under per-VMA locks because they don't take the mmap_loc= k > > and can stumble on this VMA while it's still being modified. Currently > > this does not pose a problem since post-addition modifications are done > > only for file-backed VMAs, which are not handled under per-VMA lock. > > However, once support for handling file-backed page faults with per-VMA > > locks is added, this will become a race. > > Fix this by write-locking the VMA before inserting it into the VMA tree= . > > Other places where a new VMA is added into VMA tree do not modify it > > after the insertion, so do not need the same locking. > > > > Signed-off-by: Suren Baghdasaryan > > --- > > mm/mmap.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > index c66e4622a557..84c71431a527 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -2812,6 +2812,8 @@ unsigned long mmap_region(struct file *file, unsi= gned long addr, > > if (vma->vm_file) > > i_mmap_lock_write(vma->vm_file->f_mapping); > > > > + /* Lock the VMA since it is modified after insertion into VMA tre= e */ > > So it is modified, but that i_mmap_lock_write() directly above this > comment is potentially moving below the insert and that is why this lock > is needed. Correct, we should not rely on i_mmap_lock_write() which can be moved (and is suggested to be moved in https://lore.kernel.org/all/20230606124939.93561-1-yu.ma@intel.com/). > > > + vma_start_write(vma); > > vma_iter_store(&vmi, vma); > > mm->map_count++; > > if (vma->vm_file) { > > -- > > 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. >