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 5F2E9C54E94 for ; Thu, 26 Jan 2023 07:59:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8F9076B0071; Thu, 26 Jan 2023 02:59:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8822F6B0072; Thu, 26 Jan 2023 02:59:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6FBAE6B0073; Thu, 26 Jan 2023 02:59:48 -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 5DDB86B0071 for ; Thu, 26 Jan 2023 02:59:48 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CB5B6AAB79 for ; Thu, 26 Jan 2023 07:59:47 +0000 (UTC) X-FDA: 80396201214.19.98DD7CE Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf04.hostedemail.com (Postfix) with ESMTP id CFD9A4000C for ; Thu, 26 Jan 2023 07:59:45 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=qTWifsp9; spf=pass (imf04.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674719986; 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=8phw8z9lSY7iQJCq6VYkn4UUEHCEZ7ZXKi1c7gTwrM4=; b=RhVXmTD3go2qfUSM61P7kri5ICUCgItlsK/+MK92hKjkHM1mw1/pcy1k00D9YPZ1j14ds6 XCM97c786gcBNnzgUXTQbvdyP9IeEM7un6ov8MmAW+UzNQYdhs3DN+o8JdcDno3CXQCJoF 502SXAwhDZL21DhDdDVEoZYrLWJJQKc= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=qTWifsp9; spf=pass (imf04.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674719986; a=rsa-sha256; cv=none; b=ZLWN9mDMwfwMelrX6YKa2XZU+SSAN7AKv5BMLVznB6H/LER7RixdOP/TSSfhAz0hxjr+Vf DCS4L9ojrmU+NjGkkZEJ0w/IncCpHvgpfPOGSG8eiCrNiEzrfXxoB4GD/mw+yuz5KzR4Ns SNEi40TF+BsoXhDW1SGqlwpc3q2uCN0= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 702451FEC1; Thu, 26 Jan 2023 07:59:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1674719984; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8phw8z9lSY7iQJCq6VYkn4UUEHCEZ7ZXKi1c7gTwrM4=; b=qTWifsp9kR6tUF5RbmZkPrFSDZSuoNzYFU4i42xM+2e0bl32CICy762Ehn1A7cN9EuqmJ0 AZkmevMfJIwKOy1HC8U/GL4eP9OHTN67Q3TI95rlLJfzptW0842juEEEyO6mRIlygvAJd6 Y1BtkkMiEmx1HmgPqlW1Wt0jsVYn2mI= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 42F671358A; Thu, 26 Jan 2023 07:59:44 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id rFjmD/Ay0mMFJwAAMHmgww (envelope-from ); Thu, 26 Jan 2023 07:59:44 +0000 Date: Thu, 26 Jan 2023 08:59:43 +0100 From: Michal Hocko To: Suren Baghdasaryan Cc: Andrew Morton , michel@lespinasse.org, jglisse@google.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, paulmck@kernel.org, mingo@redhat.com, will@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 Subject: Re: [PATCH v3 2/7] mm: introduce vma->vm_flags wrapper functions Message-ID: References: <20230125233554.153109-1-surenb@google.com> <20230125233554.153109-3-surenb@google.com> <20230125162810.ec222773d13cd26c55991fde@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: CFD9A4000C X-Stat-Signature: xcphrohjjcwe574k9ww87ifp1w9k6h9y X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1674719985-18631 X-HE-Meta: U2FsdGVkX1/AMpk5caCb750a1iXtHJEonl0eyRiZmnPIBFiPZpQAaAnpNlJUb93P6ybQjcYccFYZq0BdD0Z3kBSUTPOpdsO2V5Q7Qet8hcV1BVYdpZKIakooEJobaH7Tfs8xcc5ZWc/N0F0/AJhmWXPCcadH0eSmg5NmzaQJrBPje6ijbvckWPjBLnUYnbv/9odjevbMLjnG3nH0y3Du5nKxGKLUqJTCXG/BolhD3Oz+DM0rc/AZ711GIodoP4EpgSo5z5PWFP5UwAGbOKWr/e/IAoGPe3otEQhfAxbPA4dnd2UEN8+Db9RQ3expgk39SfKTt22TaZSxSDb23gJNIoddmfP2BkTl0qaTx3bER/S5aCR14BKE2ZKawpeKQgOGwnZSgylgoWGG/Y2AQKGBl5f2mgK5t+Cm90dQABCcpbgBBGf0/2c1Iegabyks86Qkl6akgxxDqFFYV+mABfrEsDY4uyl6j/kGW+M+Ua2+lhfVSh6gmUEpEBc2AwKtf1gprYROSALf3ydh3sweNb0naPF7KSN2eFJAJQAXcrf8+qQxZvzRgQk9tuxLEtnJyGsarsYvbTXtGcHiLVbFbDQ2FXQf+ZWwLMUpvn6EUwro/N9GiaN4zxP3aqdR7hc+5u/zcuhw6Vp7JdFSNZroxG8zgDWAd7bnM7pZJe7864rfOf9FzW6Mea2QH1fonj3n3JPBbnkfhRzm2XmJp5842E8/yb9wwS53PVwCl855b+1OIZgGYiA5UnUXctRpRbvuFkK90vhThQrqDaqzW8Gr2dNl/r6jJAd+NQPXAr01obwHrtPn9um/At4vEizXKHRBAitwyzp7g3/EwYh25sEvrjVsbEQBaSZF7xEB6FY4JehVtL90YJ3mz1kcnciRtS5Pj8P8FWbLqhGOhroCdglGN9emGna7BATaC/gI1Z7NAcK9l/v6136avpd8PlshCDUPWAHfJ8dpsB6NcHiGk7yzSr2 3NOXlgUK XUtFsBRyuOwzgHpERlIaZudVYbf48iKgrLfm5exM3ode9vtFR464Jgxx/Xb3ocuwALlYA7PEMoo6vluvwu36WxP79QG/tE1erZYnBcMnmXyOA60xH4KgIuVX+NQx+zw1jVod1j3jk/QMDDITIHV8qFL7/Xk+bQ+Lxjr7b7MafJcpQXSdE0L1gtQggPxbwsn/UVcWQKYYj6P3H6r+Yhfd/Rfcx3i/kKNVvfqK1vVBfb7ABEOvKsnlVvJ6UuFeG2KItJl2/nCZ7kgcdKgGyKGO2V1H/Wk6fOy1zuwegnaRfK/dSV/E= 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 Wed 25-01-23 16:56:17, Suren Baghdasaryan wrote: > On Wed, Jan 25, 2023 at 4:28 PM Andrew Morton wrote: > > > > On Wed, 25 Jan 2023 15:35:49 -0800 Suren Baghdasaryan wrote: > > > > > --- a/include/linux/mm_types.h > > > +++ b/include/linux/mm_types.h > > > @@ -491,7 +491,15 @@ struct vm_area_struct { > > > * See vmf_insert_mixed_prot() for discussion. > > > */ > > > pgprot_t vm_page_prot; > > > - unsigned long vm_flags; /* Flags, see mm.h. */ > > > + > > > + /* > > > + * Flags, see mm.h. > > > + * To modify use {init|reset|set|clear|mod}_vm_flags() functions. > > > + */ > > > + union { > > > + const vm_flags_t vm_flags; > > > + vm_flags_t __private __vm_flags; > > > + }; > > > > Typically when making a change like this we'll rename the affected > > field/variable/function/etc. This will reliably and deliberately break > > unconverted usage sites. > > > > This const trick will get us partway there, by breaking setters. But > > renaming it will break both setters and getters. > > My intent here is to break setters but to allow getters to keep > reading vma->vm_flags directly. We could provide get_vm_flags() and > convert all getters as well but it would introduce a huge additional > churn (800+ hits) with no obvious benefits, I think. Does that clarify > the intent of this trick? I think that makes sense at this stage. The conversion patch is quite large already. Maybe the final renaming could be done on top of everything and patch generated by coccinele. The const union is a neat trick but a potential lockdep assert is a nice plus as well. I wouldn't see it as a top priority though. -- Michal Hocko SUSE Labs