Message ID | 20230125233554.153109-3-surenb@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp542761wrn; Wed, 25 Jan 2023 15:40:09 -0800 (PST) X-Google-Smtp-Source: AMrXdXuX/LEKPvlXJwBxfzbyYUppbMDw/6/A73ydyNHWbLruLPxpRGxRKw4WjhJjH2PAd53uCItN X-Received: by 2002:a05:6402:230c:b0:48d:91a9:2cd0 with SMTP id l12-20020a056402230c00b0048d91a92cd0mr30123790eda.29.1674690009524; Wed, 25 Jan 2023 15:40:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674690009; cv=none; d=google.com; s=arc-20160816; b=Eh6XTuBqIuvyF42R2EKCnPkU2jRiRg1L8lKTkPhTC9MPtGfNSTBBTU6qSTvMir3Y5d um0YgqesYxmm6as8TD59M35kxViCX74yl4x+jttl6F/zs8GbaeegELCrelGxXwvhDajG srYqRuqhU///SjMGSMEbxmXRl/CFmCbWksSCH0nM5tEYX3BMMwo5U421Tut56gH8RcF6 XKPU50osCSf5bqtpew0XxNHA928XZR+gV3TyEaaus3Myn9YkHN1fGbMIt9Q1euYTmtV/ TzWGF/hWgVPHF+0Rd1yomX8E55CjAvGRBTLwBdd1ySpt83y3Lfhrr5NPzc10EFi6EMdu ETvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:dkim-signature; bh=ijhDThbayE4MrjmcyJpQB4++KqDnXZSVkoWdTA6boxg=; b=td0PsOtjIX9/0uGRv9tSpE9V4ed5g3Q6rJ0cXgqMMEDxgPg/GMVXaPlt0vNVTMNXop V47ikvRsvxOKWjuJX7Gh7P14NuW52PTXcy/AeFHB9TXoXYvTggFxMlZLLjayuyw3zn9P M/LhEmbkBkAQH608HK4kCVYkeA8mKun8YffNGpDsM6Ydypvn6Wi2FPP4yds07yXI7Sj6 OoH0MV0nEoeIxJKC/3ntTd5FJJ/DIlsdIExbpSySrHqntIrVsDXe+AGvxTg6rdx8oW0V lPybXwv+PVJeD/QR2Vyrchm9CLxvCbSJOH/KEdNZljGLWbMw/ma661j+wjlgMcuo9Weq vd5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=qAP7Xe1j; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j4-20020a170906104400b0087329ff5952si8869036ejj.219.2023.01.25.15.39.46; Wed, 25 Jan 2023 15:40:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=qAP7Xe1j; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236013AbjAYXgL (ORCPT <rfc822;lekhanya01809@gmail.com> + 99 others); Wed, 25 Jan 2023 18:36:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235929AbjAYXgE (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 25 Jan 2023 18:36:04 -0500 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78B5C5E51A for <linux-kernel@vger.kernel.org>; Wed, 25 Jan 2023 15:36:03 -0800 (PST) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-482d3bf0266so1661047b3.3 for <linux-kernel@vger.kernel.org>; Wed, 25 Jan 2023 15:36:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=ijhDThbayE4MrjmcyJpQB4++KqDnXZSVkoWdTA6boxg=; b=qAP7Xe1jWQ2v1pDyzimk/ucUXt6pJgnQPRMzULtUiXJ7miq94fdzWh3UQtS4ELXLXG xnRyMqJvJr9Qyw4fk8i3KNqyrHI6q9BE51NGUhcMbBkXiFN4EkWsXQg+sNncoZfFgpAd pmakogcOD7fawIoyB40GTMQKoodOtmE61jQOjn9IiPN2QveUdh02XHqNgo44qZ1Swkka UsHWmYnCHoE7T0et5kXrXIFTIL10ukIq3X3ayvz36CK5hAZd9JEO8xbOLC65b5H6U0Ms J3NS+Lumkoi4FpH2j3VjTovOoJdkWi+DW6xdc6JIqkzB0eqSo4KKNBbmC2JFmfQN4m9j cFgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ijhDThbayE4MrjmcyJpQB4++KqDnXZSVkoWdTA6boxg=; b=oisXrJ9nNjN19+rP7oWVX1HxLUSgs5w23497396reNy0mR0rupYD+/G9iB6I2hWCPE 9c9D7qIRQHdigLxlkGxLxrLZryMs2V2T2D1Fuu0eQn0BLbxzLZF3iamIm/LQWvYY9xt8 R4b89bmgCG8dt4+mLXkdLNQ/d6tu6HRIxVo0X9uI8NKh77KJBopiwx8XG75j99pTzKxS sN4MBB9425KotZb+OhthkZzqitcUYMLfhYGeff3QbMM6P/25gjAO8SXtsSNHltzIZIg7 FOOirLqXR7DcBGMN888LNqpLTBWbCyjcIKTt+WsF/CcIKfYraork4nsOcuEeoxLCg4Rg YsUw== X-Gm-Message-State: AFqh2kp3HZUpUW3v5ErZ0OvrGVPSUi65JDRXYzoxIhnpqxSNRPYYGe5J aEMn61JzUfgLWyvbf8a5g1EZK2LOmdg= X-Received: from surenb-desktop.mtv.corp.google.com ([2620:15c:211:200:f7b0:20e8:ce66:f98]) (user=surenb job=sendgmr) by 2002:a0d:ff42:0:b0:4e0:8133:2a5a with SMTP id p63-20020a0dff42000000b004e081332a5amr3780554ywf.187.1674689762692; Wed, 25 Jan 2023 15:36:02 -0800 (PST) Date: Wed, 25 Jan 2023 15:35:49 -0800 In-Reply-To: <20230125233554.153109-1-surenb@google.com> Mime-Version: 1.0 References: <20230125233554.153109-1-surenb@google.com> X-Mailer: git-send-email 2.39.1.456.gfc5497dd1b-goog Message-ID: <20230125233554.153109-3-surenb@google.com> Subject: [PATCH v3 2/7] mm: introduce vma->vm_flags wrapper functions From: Suren Baghdasaryan <surenb@google.com> To: akpm@linux-foundation.org Cc: 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, 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, surenb@google.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756039751222320646?= X-GMAIL-MSGID: =?utf-8?q?1756039751222320646?= |
Series |
introduce vm_flags modifier functions
|
|
Commit Message
Suren Baghdasaryan
Jan. 25, 2023, 11:35 p.m. UTC
vm_flags are among VMA attributes which affect decisions like VMA merging
and splitting. Therefore all vm_flags modifications are performed after
taking exclusive mmap_lock to prevent vm_flags updates racing with such
operations. Introduce modifier functions for vm_flags to be used whenever
flags are updated. This way we can better check and control correct
locking behavior during these updates.
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
---
include/linux/mm.h | 37 +++++++++++++++++++++++++++++++++++++
include/linux/mm_types.h | 10 +++++++++-
2 files changed, 46 insertions(+), 1 deletion(-)
Comments
On Wed, 25 Jan 2023 15:35:49 -0800 Suren Baghdasaryan <surenb@google.com> wrote: > vm_flags are among VMA attributes which affect decisions like VMA merging > and splitting. Therefore all vm_flags modifications are performed after > taking exclusive mmap_lock to prevent vm_flags updates racing with such > operations. Introduce modifier functions for vm_flags to be used whenever > flags are updated. This way we can better check and control correct > locking behavior during these updates. > > ... > > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > +static inline void init_vm_flags(struct vm_area_struct *vma, > +static inline void reset_vm_flags(struct vm_area_struct *vma, > +static inline void set_vm_flags(struct vm_area_struct *vma, > +static inline void clear_vm_flags(struct vm_area_struct *vma, > +static inline void mod_vm_flags(struct vm_area_struct *vma, vm_flags_init(), vm_flags_reset(), etc? This would be more idiomatic and I do think the most-significant-first naming style is preferable.
On Wed, 25 Jan 2023 15:35:49 -0800 Suren Baghdasaryan <surenb@google.com> 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.
On Wed, Jan 25, 2023 at 4:24 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Wed, 25 Jan 2023 15:35:49 -0800 Suren Baghdasaryan <surenb@google.com> wrote: > > > vm_flags are among VMA attributes which affect decisions like VMA merging > > and splitting. Therefore all vm_flags modifications are performed after > > taking exclusive mmap_lock to prevent vm_flags updates racing with such > > operations. Introduce modifier functions for vm_flags to be used whenever > > flags are updated. This way we can better check and control correct > > locking behavior during these updates. > > > > ... > > > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > +static inline void init_vm_flags(struct vm_area_struct *vma, > > +static inline void reset_vm_flags(struct vm_area_struct *vma, > > +static inline void set_vm_flags(struct vm_area_struct *vma, > > +static inline void clear_vm_flags(struct vm_area_struct *vma, > > +static inline void mod_vm_flags(struct vm_area_struct *vma, > > vm_flags_init(), vm_flags_reset(), etc? > > This would be more idiomatic and I do think the most-significant-first > naming style is preferable. Thanks for the suggestion! I will rename them in the next version. > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >
On Wed, Jan 25, 2023 at 4:28 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Wed, 25 Jan 2023 15:35:49 -0800 Suren Baghdasaryan <surenb@google.com> 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? > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >
On Wed 25-01-23 16:56:17, Suren Baghdasaryan wrote: > On Wed, Jan 25, 2023 at 4:28 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > On Wed, 25 Jan 2023 15:35:49 -0800 Suren Baghdasaryan <surenb@google.com> 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.
On Wed 25-01-23 15:35:49, Suren Baghdasaryan wrote: > vm_flags are among VMA attributes which affect decisions like VMA merging > and splitting. Therefore all vm_flags modifications are performed after > taking exclusive mmap_lock to prevent vm_flags updates racing with such > operations. Introduce modifier functions for vm_flags to be used whenever > flags are updated. This way we can better check and control correct > locking behavior during these updates. > > Signed-off-by: Suren Baghdasaryan <surenb@google.com> with or without the proposed renaming (it seems we are not consistent on that much even in the core kernel - e.g. init_rwsem vs. mutex_init) Acked-by: Michal Hocko <mhocko@suse.com> > --- > include/linux/mm.h | 37 +++++++++++++++++++++++++++++++++++++ > include/linux/mm_types.h | 10 +++++++++- > 2 files changed, 46 insertions(+), 1 deletion(-) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index c2f62bdce134..bf16ddd544a5 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -627,6 +627,43 @@ static inline void vma_init(struct vm_area_struct *vma, struct mm_struct *mm) > INIT_LIST_HEAD(&vma->anon_vma_chain); > } > > +/* Use when VMA is not part of the VMA tree and needs no locking */ > +static inline void init_vm_flags(struct vm_area_struct *vma, > + vm_flags_t flags) > +{ > + ACCESS_PRIVATE(vma, __vm_flags) = flags; > +} > + > +/* Use when VMA is part of the VMA tree and modifications need coordination */ > +static inline void reset_vm_flags(struct vm_area_struct *vma, > + vm_flags_t flags) > +{ > + mmap_assert_write_locked(vma->vm_mm); > + init_vm_flags(vma, flags); > +} > + > +static inline void set_vm_flags(struct vm_area_struct *vma, > + vm_flags_t flags) > +{ > + mmap_assert_write_locked(vma->vm_mm); > + ACCESS_PRIVATE(vma, __vm_flags) |= flags; > +} > + > +static inline void clear_vm_flags(struct vm_area_struct *vma, > + vm_flags_t flags) > +{ > + mmap_assert_write_locked(vma->vm_mm); > + ACCESS_PRIVATE(vma, __vm_flags) &= ~flags; > +} > + > +static inline void mod_vm_flags(struct vm_area_struct *vma, > + vm_flags_t set, vm_flags_t clear) > +{ > + mmap_assert_write_locked(vma->vm_mm); > + ACCESS_PRIVATE(vma, __vm_flags) |= set; > + ACCESS_PRIVATE(vma, __vm_flags) &= ~clear; > +} > + > static inline void vma_set_anonymous(struct vm_area_struct *vma) > { > vma->vm_ops = NULL; > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > index 2d6d790d9bed..bccbd5896850 100644 > --- 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; > + }; > > /* > * For areas with an address space and backing store, > -- > 2.39.1
On Wed, Jan 25, 2023 at 03:35:49PM -0800, Suren Baghdasaryan wrote: > vm_flags are among VMA attributes which affect decisions like VMA merging > and splitting. Therefore all vm_flags modifications are performed after > taking exclusive mmap_lock to prevent vm_flags updates racing with such > operations. Introduce modifier functions for vm_flags to be used whenever > flags are updated. This way we can better check and control correct > locking behavior during these updates. > > Signed-off-by: Suren Baghdasaryan <surenb@google.com> With or without the suggested rename; Acked-by: Mel Gorman <mgorman@techsingularity.net>
On Thu, Jan 26, 2023 at 5:58 AM Mel Gorman <mgorman@techsingularity.net> wrote: > > On Wed, Jan 25, 2023 at 03:35:49PM -0800, Suren Baghdasaryan wrote: > > vm_flags are among VMA attributes which affect decisions like VMA merging > > and splitting. Therefore all vm_flags modifications are performed after > > taking exclusive mmap_lock to prevent vm_flags updates racing with such > > operations. Introduce modifier functions for vm_flags to be used whenever > > flags are updated. This way we can better check and control correct > > locking behavior during these updates. > > > > Signed-off-by: Suren Baghdasaryan <surenb@google.com> > > With or without the suggested rename; > > Acked-by: Mel Gorman <mgorman@techsingularity.net> Thanks! I'll make the renames and repost the patchset. vm_flags_init(), vm_flags_reset(), etc. sounds like a good naming for this. > > -- > Mel Gorman > SUSE Labs
On Wed, 25 Jan 2023, Andrew Morton wrote: >On Wed, 25 Jan 2023 15:35:49 -0800 Suren Baghdasaryan <surenb@google.com> wrote: > >> vm_flags are among VMA attributes which affect decisions like VMA merging >> and splitting. Therefore all vm_flags modifications are performed after >> taking exclusive mmap_lock to prevent vm_flags updates racing with such >> operations. Introduce modifier functions for vm_flags to be used whenever >> flags are updated. This way we can better check and control correct >> locking behavior during these updates. >> >> ... >> >> --- a/include/linux/mm.h >> +++ b/include/linux/mm.h >> +static inline void init_vm_flags(struct vm_area_struct *vma, >> +static inline void reset_vm_flags(struct vm_area_struct *vma, >> +static inline void set_vm_flags(struct vm_area_struct *vma, >> +static inline void clear_vm_flags(struct vm_area_struct *vma, >> +static inline void mod_vm_flags(struct vm_area_struct *vma, > >vm_flags_init(), vm_flags_reset(), etc? > >This would be more idiomatic and I do think the most-significant-first >naming style is preferable. I tend to prefer this naming yes, but lgtm regardless. Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
diff --git a/include/linux/mm.h b/include/linux/mm.h index c2f62bdce134..bf16ddd544a5 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -627,6 +627,43 @@ static inline void vma_init(struct vm_area_struct *vma, struct mm_struct *mm) INIT_LIST_HEAD(&vma->anon_vma_chain); } +/* Use when VMA is not part of the VMA tree and needs no locking */ +static inline void init_vm_flags(struct vm_area_struct *vma, + vm_flags_t flags) +{ + ACCESS_PRIVATE(vma, __vm_flags) = flags; +} + +/* Use when VMA is part of the VMA tree and modifications need coordination */ +static inline void reset_vm_flags(struct vm_area_struct *vma, + vm_flags_t flags) +{ + mmap_assert_write_locked(vma->vm_mm); + init_vm_flags(vma, flags); +} + +static inline void set_vm_flags(struct vm_area_struct *vma, + vm_flags_t flags) +{ + mmap_assert_write_locked(vma->vm_mm); + ACCESS_PRIVATE(vma, __vm_flags) |= flags; +} + +static inline void clear_vm_flags(struct vm_area_struct *vma, + vm_flags_t flags) +{ + mmap_assert_write_locked(vma->vm_mm); + ACCESS_PRIVATE(vma, __vm_flags) &= ~flags; +} + +static inline void mod_vm_flags(struct vm_area_struct *vma, + vm_flags_t set, vm_flags_t clear) +{ + mmap_assert_write_locked(vma->vm_mm); + ACCESS_PRIVATE(vma, __vm_flags) |= set; + ACCESS_PRIVATE(vma, __vm_flags) &= ~clear; +} + static inline void vma_set_anonymous(struct vm_area_struct *vma) { vma->vm_ops = NULL; diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h index 2d6d790d9bed..bccbd5896850 100644 --- 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; + }; /* * For areas with an address space and backing store,