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 F0E29C46467 for ; Wed, 11 Jan 2023 21:23:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 558288E0002; Wed, 11 Jan 2023 16:23:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5079C8E0001; Wed, 11 Jan 2023 16:23:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CF898E0002; Wed, 11 Jan 2023 16:23:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 2D4B78E0001 for ; Wed, 11 Jan 2023 16:23:50 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 01FDEA01D9 for ; Wed, 11 Jan 2023 21:23:49 +0000 (UTC) X-FDA: 80343795378.06.6C59569 Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) by imf10.hostedemail.com (Postfix) with ESMTP id 7BD59C0005 for ; Wed, 11 Jan 2023 21:23:48 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=AlFLNWR2; spf=pass (imf10.hostedemail.com: domain of surenb@google.com designates 209.85.128.173 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=1673472228; a=rsa-sha256; cv=none; b=nKvMRRSWQGLvzLvosY36iN3vSrCF6iT4XcErqqKAmVDVxF7vTs8gSZHFt0qYTb8PSUZH7g FFyGs5gr3rjBpP2JIFW3XDk7T4jy075XxmCkfd0mNowNm4v7bL6OROADFkpT+JAG+Iaqe2 JowgtjVzKwlo8I0BgAKHO+MHwQnKbbM= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=AlFLNWR2; spf=pass (imf10.hostedemail.com: domain of surenb@google.com designates 209.85.128.173 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=1673472228; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SxCfhGNrfWy89W/U+pPUVQaJLaBqtZaaZxJq5wlMRbw=; b=LqB0XH8mA1//LZdb2WG/HS/zRfPSyYn1/aGRaW7/9qU0tmgbkDW4ooR1smuS27LMaMYstb SAoVqB6+Xdhh78800DwVMDy0G+GwwPZ6bovZEmJtLwhihNq5QFIWPcdAuibpYegjpQSrK5 n6jAKThKRVfuS7RtDsvdYQUGHwP7aFc= Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-4c15c4fc8ccso212968847b3.4 for ; Wed, 11 Jan 2023 13:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=SxCfhGNrfWy89W/U+pPUVQaJLaBqtZaaZxJq5wlMRbw=; b=AlFLNWR2lfiXPfEMGFqHZytcNNrUL9Uj9qeAqkeKRYgTrO2dCdhF9YPB5VkmKVyv2h kfDuyeZ0c2W077izhhNcCx4PzDF+gJ2VLHARsWGsxazXli8H8VYDDOjK5W34rgwB62i6 iPyeCKiIhFaM471RKJFtueTSOvbG31VbMye+Z/zVohNQSHKqqi14CnP8+P7P3kEL3S5S nSBSCMQRiDK55LzhXVB3FSialBZ5FiyQBR4BCpnLtN7Eq2tXD30YcBcPHELpFHw7JPAU DceYtiB1wobFLb7CkOWU6Yuw9oTRkFdP/RRU8Wc5gMEB/DeAD4cvlXv4ZOBaAO+du5We xOFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=SxCfhGNrfWy89W/U+pPUVQaJLaBqtZaaZxJq5wlMRbw=; b=FBjE12+KwjtkO2ECgOtANeO6sSJJaqlX0XcFL9d5ySWutovRTORBrmEO0AmcnYINaR hwzNiT43SkgAbuR24RZGxXx8/KRFoz1YjHAWjyjpnFysrAvk4dujJ55S9+jrdc6eYmad QrU0R/LIBSSRgz8C3/zD7yFSOjZc9RWm9z1B4geAON6uBm+5WNtBUx/xgK7xEHCHfL/2 wrYcH6F2XzLJ494RkFIN6V+FiAgPXuPK7wVaQNZBeBdNfxVU/ecj7jA80GNFr6OCJcuk IQgk14MKfXOsHw4f8tLL5MBtlw/Hg0V8oi2RfYFsOPoCY/n7J0RykDXzZnl5lideQPZ8 VB0g== X-Gm-Message-State: AFqh2kp2SlZlM0JJpFRytyDaxmGUX5MR4HJiGKcREjDYpfNcuTtiJumU mXZdUbnwThECtZthIdJvGLkzhy+Rho13z0EftPamXQ== X-Google-Smtp-Source: AMrXdXvkk9wMrdla5WxSOI7zrH4TdD8mYzSa58gnz4fRSmPZ7cdc+yy1/593wOoB6SdGGhG6a9NhgrILr9krFbI1xEA= X-Received: by 2002:a81:c56:0:b0:490:89c3:21b0 with SMTP id 83-20020a810c56000000b0049089c321b0mr6779232ywm.132.1673472227332; Wed, 11 Jan 2023 13:23:47 -0800 (PST) MIME-Version: 1.0 References: <20230109205336.3665937-1-surenb@google.com> <20230109205336.3665937-14-surenb@google.com> <20230111154726.stadwtzicabwh5u5@offworld> <20230111195250.cj27sg4yoslbdjdp@offworld> In-Reply-To: <20230111195250.cj27sg4yoslbdjdp@offworld> From: Suren Baghdasaryan Date: Wed, 11 Jan 2023 13:23:35 -0800 Message-ID: Subject: Re: [PATCH 13/41] mm: introduce vma->vm_flags modifier functions To: Suren Baghdasaryan , akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, 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, 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-Rspam-User: X-Rspamd-Queue-Id: 7BD59C0005 X-Rspamd-Server: rspam01 X-Stat-Signature: hhpkzoxyp933x4tm7buurcotoaz5neac X-HE-Tag: 1673472228-871444 X-HE-Meta: U2FsdGVkX1+cm2UVuFocgIhxWszoPDMQYzSHfsPiBzDk9GmcucyLoUfsTTn9krZvFPjbS7mNJJ5vpVyHJtuD329iyTaRdyDAYnci0I2yCT5w6eOT1Gztsu7KFM/GNf8T1BBUlgWNxAiADKlVD7VmgY5hq/moFQJURijWIGnTXeWyNb8Kd3+1PALqqwLrBVo2qzTpaOZJLOv8cBni5870w/kNY78zIGYLqa9ws0APvgg9AYjh5I9s6kAqWGpDkFV7tSpp6JC9U1gDXqhNL85Gq+GbASDvGG6mAHwPxK46/9uWxK7e83+RqDAIDWXa3S1W8TOtzkjXNOL7zbXEU+IXLHtlPN3z/KhOX5FtnG2JfAYAOHHUiVc6RR9EbrkvKBBBs/w/wIdr56u/FVYPFtve5HicJAUNmH9DOj9g59HvN0kGd0LxvJ/DhhfNRxKPpnz5Yoq53nxxGl+hrrlLYo+xbfP8iDgG+cVNMPe88w4vINVfZL8p0CUclHcHdZqU/l6P2tb2hc3mfN9+Y5G0EHD6HRoc7kKBgiwT6ngNgYFMoKBdds6NDSeoCmReVergLosIpQpU1vhSyVqb0UUqN9M2Ng/Ab1Pi7rRWfBAzRXWZzl3nfykIkZTqhSxd+f1MacTQf+ZAOLsnqSGhoEw54gkoNSbD+xgF2b+wnVvUdcLTXeR2V0TjbNpWFwirxC27cb0nk0HEUKZzDClUiV0w7FF3YrM7Ty7YqNGQ5GSINdDqCFytrZao46WfwwqUrPTTf5awnSceg97OOlhC+yw/kDUU3X9k1iyzrMuerHCvqnty88xxTTy7VCJpSZBSvCnORV2HNqvnKVNb3kuHmJUcGOxibIi5sVUvvLizsOgEIP/R74c2KoVXE75lOqaQugjkGOjmGML06RtP7xDnpm7Ct1oIeg7Gy6XxB5PGKRqt8gXaKM+oMuCfzycAFXjGunoKnJri4jxc13z+TRp6IUvJVGq U43jyH1L PtMxEA77lsifIvi1jylbuKFdpGNOKwDyukzQaS3kAQ1gB7IivN9qnpwACXg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001930, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jan 11, 2023 at 12:19 PM Davidlohr Bueso wrote: > > On Wed, 11 Jan 2023, Suren Baghdasaryan wrote: > > >On Wed, Jan 11, 2023 at 8:13 AM Davidlohr Bueso wrote: > >> > >> On Mon, 09 Jan 2023, Suren Baghdasaryan wrote: > >> > >> >To keep vma locking correctness when vm_flags are modified, add modifier > >> >functions to be used whenever flags are updated. > >> > >> How about moving this patch and the ones that follow out of this series, > >> into a preliminary patchset? It would reduce the amount of noise in the > >> per-vma lock changes, which would then only be adding the needed > >> vma_write_lock()ing. > > > >How about moving those prerequisite patches to the beginning of the > >patchset (before maple_tree RCU changes)? I feel like they do belong > >in the patchset because as a standalone patchset it would be unclear > >why I'm adding all these accessor functions and introducing this > >churn. Would that be acceptable? > > imo the abstraction of vm_flags handling is worth being standalone and is > easier to be picked up before a more complex locking scheme change. But > either way, it's up to you. I see your point. Ok, if you think it makes sense as a stand-alone patch I can post it separately in the next version. Thanks, Suren. > > Thanks, > Davidlohr > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >