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 B30E0C677F1 for ; Tue, 17 Jan 2023 18:03:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 334306B0073; Tue, 17 Jan 2023 13:03:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2BD8C6B0074; Tue, 17 Jan 2023 13:03:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1372A6B0078; Tue, 17 Jan 2023 13:03:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id F26B16B0073 for ; Tue, 17 Jan 2023 13:03:34 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 969AA160B6C for ; Tue, 17 Jan 2023 18:03:34 +0000 (UTC) X-FDA: 80365063548.12.ABC8E4D Received: from mail-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) by imf18.hostedemail.com (Postfix) with ESMTP id BBE8B1C0018 for ; Tue, 17 Jan 2023 18:03:32 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Mooewx5N; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of jannh@google.com designates 209.85.166.178 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673978612; 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=2LfIzIDKNfdwhzRI4wk4tbto15PFLzQqPn6IM74K1Nc=; b=tQGYYBveQExQ8VloQMCGarRkuTdPUE6kiVElXpAVXT/G9XXIWCBur4IiFHh9Qr68EZlroc +U4Be6s/2iymbDNtEAvcF/q81G7cg5UAMLRgagF2BbI8gfsR8UnUU42DtGMU3m1/GnmhaZ uWK3F5Im/9q1an1mV+AA2ImwMruACdo= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Mooewx5N; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of jannh@google.com designates 209.85.166.178 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673978612; a=rsa-sha256; cv=none; b=CnoCZwLP4rePwDpkukLgLvBcvMm6yEyW5cj+gBOJ2KspIPsr1UT/P8mMIWmsLEUqCPmCsA EKLmWib/CU4UN+LDgiDGCA4DTVm7aij70SJx/lD+zD4yW+0ltsS3CCBukR+1+x2Cpsy2Lf RuOqVcGu/egmyp8rM+eg8U7/VYmhhzc= Received: by mail-il1-f178.google.com with SMTP id m7so3231517ilh.7 for ; Tue, 17 Jan 2023 10:03:32 -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=2LfIzIDKNfdwhzRI4wk4tbto15PFLzQqPn6IM74K1Nc=; b=Mooewx5NuvmBi8G3lPeDVvjeMhDwam4J3V5WoYrMGEaACQq8r01FTJwg9r5gNAqKHv BcT+clyjtziDoHfDoZgf8mXwiyxjshQK9AVHMyb/QWVVp32ww9ingtrVqod0LDfOJImz Y0TwcaekYYsJ//YdVBtdZXByqq9WLLeZf19Z8v3wfd8Qhfwfau1IdSR4Tc4e6jr2szha MfdiYZLdlOAFeQe7T4M3d15TPoEEp9r20dwRTcjDofABHxa96XnhDW06/jzXCIqYK82c D9cdjVUUN6zid8FXGy9WF8BxgN6Gta9IfDG+F3FYzRS4GL6vM308WQjFQsyY7d5ObtDP aykg== 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=2LfIzIDKNfdwhzRI4wk4tbto15PFLzQqPn6IM74K1Nc=; b=Cxg1l6mFrp5mWbfCFSYm/RW9jHdcwr8fWy+riggvCsH7L9JHaTFSDpReJuobRKYsj3 xPd9mVXyEllgB5ra8V3gpTK/i6Uhb/6dN8tEJbHQHQFQ7UoBw1MqErmTtuS2qpkoUaSg IY1MkYeO/o6/cBuIA8cJSCByF5OBkropCo773FtogOT2O225ixFsmSPNHZasOMaeZMZq lpjqfr4zv+DIvid3b0lribQdMpAEqxwE7IriUsnLxm4zlRVukAqcvJN8aNDc0pkGT2Um OPv7bC4ODA1+lLW3tvZExTi27ad9gX1S1CUmPbMmpaudeQKpPV/FHGpHD/H98SAqz3Sx wbiw== X-Gm-Message-State: AFqh2kqBDrRarO6FwF3mxm6esOTMmRC3HuotffdhtSfu8iKJ5odRh5Tj XWxcupx6nKtfAJ8LtgnbETtuvpGmb4restotiKEMgA== X-Google-Smtp-Source: AMrXdXuYG9pfhe3BEDdAxOrlJ5FMm60eG9MzyrHap4mGomMoh4ycHHb4WuecCt1NKPItKhuNPMbigXyQKtN6iEbWTIk= X-Received: by 2002:a92:a043:0:b0:30b:f4af:87bd with SMTP id b3-20020a92a043000000b0030bf4af87bdmr425702ilm.254.1673978611685; Tue, 17 Jan 2023 10:03:31 -0800 (PST) MIME-Version: 1.0 References: <20230109205336.3665937-1-surenb@google.com> <20230109205336.3665937-13-surenb@google.com> In-Reply-To: <20230109205336.3665937-13-surenb@google.com> From: Jann Horn Date: Tue, 17 Jan 2023 19:02:55 +0100 Message-ID: Subject: Re: [PATCH 12/41] mm: add per-VMA lock and helper functions to control it To: Suren Baghdasaryan , peterz@infradead.org, Ingo Molnar , Will Deacon Cc: akpm@linux-foundation.org, 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, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, paulmck@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, 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-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: BBE8B1C0018 X-Stat-Signature: 1uuczy3axm81iygih1pw8ah7osp54epw X-HE-Tag: 1673978612-952432 X-HE-Meta: U2FsdGVkX18XnTed+64HOl1fVRyr4UDtEVVbNbbV9GN4eDJIqtIQhfQImaDKIPl0T4bdu5J241SMAht4Ymk1RowGflFNaFTyd5SlaMhhbVHeQ+iVURwUjES7gGNarE0jCpR71reb8gAiwFtMkOEOztDtg0OqN8HcqZzFboYQGig78KbNb8wzKIewFoYC6gLP0Vc/CL3ZW+pfKxdeijkTiQYOisxfHPb9jtszmtED8vFVkeJZkCfbeHBAkvUxEJY9XBtP9QpSI4odr/f5xByf2bKsh7NxCRrweUxPqu/uQiFU0KCc2l3FGDTkOEDMD41uLaEh/ED7ZyzkZrBzCbuQMXajD9zWOGJdBgS3/AxYNPE77xWwgm1i9n919cn8XncvTRY8sDWLuROuxJTIfVlZNey0Wh5BYqN1g0MduBlgTk/do1tHYXRpfuUSXsprmY0C7rommM4WEPUgLieDNHhc67DiRUsRivLXz5VfgDW+aAHpCd/wv5yMXwuu24pMHLR8i6uyrJlhLZWT0qlbnPhrNg0A49TjUler/XHVBQA3gadCOOc0QhpnsE9bUT/TVGCnUU9H+DhujfFADvGcEgR2n+baMFb5LCUU7aO1F9qzmI0xw03v/NWViI2Ch3bAiSNG2UAZlxhpiqOQaQqvN6pR7RQxThOrVLQYL9lW3lnACbO20AjTRI+uBark3iheeXg68DLqeVBnLFmD6Qry/bEvdXSaZxKGzaIK9Jkv6z1F/QAhKs3OJp6gPtDuDHigFMj+IwExBdZ+HKtrKRUbd4eaTDLJLr2rec2JfTR+6lvnvEE1G5rTl2ZMbq0k2s8GO6dn48TaYqp+H3sKsN/k735onFBwxbmGuamTj6n88nw93BEzeKAo4TxjDGzuubwLh6JgdBekTRTHYmRqwJ2/0ZwrNqJd4kpc9krNY8XBU7Wcy4a16nuW34KOuTJTMXEi6yf4q0MaGqi25UAUgea1PHx YHtJj4Ty h8DGL3JaR3b9CO74= 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: +locking maintainers On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan wrote: > Introduce a per-VMA rw_semaphore to be used during page fault handling > instead of mmap_lock. Because there are cases when multiple VMAs need > to be exclusively locked during VMA tree modifications, instead of the > usual lock/unlock patter we mark a VMA as locked by taking per-VMA lock > exclusively and setting vma->lock_seq to the current mm->lock_seq. When > mmap_write_lock holder is done with all modifications and drops mmap_lock, > it will increment mm->lock_seq, effectively unlocking all VMAs marked as > locked. [...] > +static inline void vma_read_unlock(struct vm_area_struct *vma) > +{ > + up_read(&vma->lock); > +} One thing that might be gnarly here is that I think you might not be allowed to use up_read() to fully release ownership of an object - from what I remember, I think that up_read() (unlike something like spin_unlock()) can access the lock object after it's already been acquired by someone else. So if you want to protect against concurrent deletion, this might have to be something like: rcu_read_lock(); /* keeps vma alive */ up_read(&vma->lock); rcu_read_unlock(); But I'm not entirely sure about that, the locking folks might know better. Also, it might not matter given that the rw_semaphore part is removed in the current patch 41/41 anyway...