Message ID | 20230109205336.3665937-14-surenb@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp2375494wrt; Mon, 9 Jan 2023 12:56:39 -0800 (PST) X-Google-Smtp-Source: AMrXdXtKE9OdX5iXf6qw7wP5CBczigoChH+VXwxAtJKa+EBWCALf/7vX2CLuBuSgD5JRqGtTir44 X-Received: by 2002:a17:907:900b:b0:84d:4e4e:2c7b with SMTP id ay11-20020a170907900b00b0084d4e4e2c7bmr2383763ejc.30.1673297799357; Mon, 09 Jan 2023 12:56:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673297799; cv=none; d=google.com; s=arc-20160816; b=qGrFwq5q9C8kQq7fobZSnzQNvrSG/w0RYYHs7RQvRjuH4M48fjCt2sQpJCBP6J3rXh 7KaZJhK9tIfZwIInsfAEVbJX/KwKdaYVVXPeIprvGQ0UNdAAdNDrEi9FjEimsqekvrEi /p+KOOszw0tN8C15vebB3y/lzRY59uTmSTQ3Y3I/XAm4f1c/HWDjFzZal2+q5BOJoFrc UD5Ty1tIdJVZQMuv4Ej0p+l1eJTcU0gHMqr71ZO+42u78YqsnlJq6+0/z8FOqFndflVD SV/zmzlj+97/9WTKLEcFnH8LcXYZeFXb321gGsZsv08YmgOlPC/F3B7Y4TykZjiR1dkg rX+Q== 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=7ThjMRKbwnKxVGB3eylsidymuk6Qi/iLA6nYtJEm4MU=; b=T5rUvR/A5jGNr3V6OInKuGyDya81frGUaTXEa1xlJ+yB3OKtosqWPq+b+jmnzda2MD PLS2z83+4iDETakith+7HvhnUEdlNE4UzuGSwiRyx27rjm0ocRYuY6BEqPAgHpNOSlaw WFQsNfW2nu2R98AS0FpF17tDdg9vL7onWqvHv9zIZTd4kz5YRj+4px44IeI6ntxtaCRO RUVVxDiHpH+C+G7XxjXGhP3/spxGdCPk2FN3iJpb+sjH2aMqotqBfZSP93Ya83AFrloe G1je0aBfNixvXcPtSVxQyFzsgsuNIEKSDMyJc1vgEOU+Ypd9ePxkl2SReT857Z8u0JVU 9vYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="RKn/zVLZ"; 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 hd41-20020a17090796a900b007c0c0d7c4c8si10271549ejc.44.2023.01.09.12.56.16; Mon, 09 Jan 2023 12:56:39 -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="RKn/zVLZ"; 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 S236688AbjAIUzG (ORCPT <rfc822;syz17693488234@gmail.com> + 99 others); Mon, 9 Jan 2023 15:55:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60358 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237397AbjAIUyR (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 9 Jan 2023 15:54:17 -0500 Received: from mail-pj1-x104a.google.com (mail-pj1-x104a.google.com [IPv6:2607:f8b0:4864:20::104a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 318B077D0E for <linux-kernel@vger.kernel.org>; Mon, 9 Jan 2023 12:54:14 -0800 (PST) Received: by mail-pj1-x104a.google.com with SMTP id 31-20020a17090a0fa200b00226e43409c2so3542156pjz.9 for <linux-kernel@vger.kernel.org>; Mon, 09 Jan 2023 12:54:14 -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=7ThjMRKbwnKxVGB3eylsidymuk6Qi/iLA6nYtJEm4MU=; b=RKn/zVLZEJYWNukTXjRCu4nz81zaytlRkR7rakIR2uB/aIfeElp0yCIRzuM8+pvZ3x BQOElK8tbS+rhMmhhEhBtfHOWGZOyvH/HCUdLENpEngLYbZsqjJ9OUXahFZPUHh+XaxU YMwkVhfHQ73TasfAveK5V4w8pX7O6IKpRzfg+l1/+SN9l2l60gXMRIOKbNPAPi3/90FE v/HorT/klJnq8Lcd3XX+VkW89j017v/vCfpCQTBG4XFodaDoUu6obKl8t1y+jpshNDo0 91Vfmkl3EHo0Elu4jQ9efLprq8Gy+cE160O08y2PdqRoSx1lsEPlDSvoNxeAyXeTk2x0 qpkw== 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=7ThjMRKbwnKxVGB3eylsidymuk6Qi/iLA6nYtJEm4MU=; b=l4mmbpAKy2O1PAk8y/kacszyy540lIu8NNdeipP2LJKtrQyYzk9nV6Fu1tx9MiKM5j uUeLzhlLkEUwfiEKdZOjwrLNCMRI568fRbN/X6m3+/hS6R3bBhN75o2Uw2ZPDPW7yxV+ HDcayym1tf0eLVREY8FZkNDu9Zv/fvRxaoz4M2VyhAkRUR/nNopM77caUZXVGa5bh2kd tN3ytoJNxrfcRDTi/CG8CisttQiFvEB19gstYBwZdmYtaTmJAnkjtVvG+cy11NA2LWlc /4N10RT07r3FKa0q95OknOBvxkUj0MsML4LkYkwHfYrJnnG74hMroXy3CM/bgbtHj0iD kNNA== X-Gm-Message-State: AFqh2kp2usmtUDJcRzsbUz5rsJL1fo9OhRCe0zylOGXAesmm6V48xPNh HjJFWQItY15pjQk4JqLYhgrmmLh67Fw= X-Received: from surenb-desktop.mtv.corp.google.com ([2620:15c:211:200:9393:6f7a:d410:55ca]) (user=surenb job=sendgmr) by 2002:a17:90a:5c86:b0:219:c1fb:5da8 with SMTP id r6-20020a17090a5c8600b00219c1fb5da8mr5399379pji.221.1673297653600; Mon, 09 Jan 2023 12:54:13 -0800 (PST) Date: Mon, 9 Jan 2023 12:53:08 -0800 In-Reply-To: <20230109205336.3665937-1-surenb@google.com> Mime-Version: 1.0 References: <20230109205336.3665937-1-surenb@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230109205336.3665937-14-surenb@google.com> Subject: [PATCH 13/41] mm: introduce vma->vm_flags modifier 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, 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, 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?1754579913271725691?= X-GMAIL-MSGID: =?utf-8?q?1754579913271725691?= |
Series |
Per-VMA locks
|
|
Commit Message
Suren Baghdasaryan
Jan. 9, 2023, 8:53 p.m. UTC
To keep vma locking correctness when vm_flags are modified, add modifier
functions to be used whenever flags are updated.
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
---
include/linux/mm.h | 38 ++++++++++++++++++++++++++++++++++++++
include/linux/mm_types.h | 8 +++++++-
2 files changed, 45 insertions(+), 1 deletion(-)
Comments
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. Thanks, Davidlohr
On Wed, Jan 11, 2023 at 8:13 AM Davidlohr Bueso <dave@stgolabs.net> 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? > > Thanks, > Davidlohr > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >
On Wed, 11 Jan 2023, Suren Baghdasaryan wrote: >On Wed, Jan 11, 2023 at 8:13 AM Davidlohr Bueso <dave@stgolabs.net> 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. Thanks, Davidlohr
On Wed, Jan 11, 2023 at 12:19 PM Davidlohr Bueso <dave@stgolabs.net> wrote: > > On Wed, 11 Jan 2023, Suren Baghdasaryan wrote: > > >On Wed, Jan 11, 2023 at 8:13 AM Davidlohr Bueso <dave@stgolabs.net> 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. >
On Mon 09-01-23 12:53:08, Suren Baghdasaryan wrote: > To keep vma locking correctness when vm_flags are modified, add modifier > functions to be used whenever flags are updated. > > Signed-off-by: Suren Baghdasaryan <surenb@google.com> > --- > include/linux/mm.h | 38 ++++++++++++++++++++++++++++++++++++++ > include/linux/mm_types.h | 8 +++++++- > 2 files changed, 45 insertions(+), 1 deletion(-) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index ec2c4c227d51..35cf0a6cbcc2 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -702,6 +702,44 @@ static inline void vma_init(struct vm_area_struct *vma, struct mm_struct *mm) > vma_init_lock(vma); > } > > +/* 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, unsigned long flags) > +{ > + WRITE_ONCE(vma->vm_flags, flags); > +} Why do we need WRITE_ONCE here? Isn't vma invisible during its initialization? > + > +/* Use when VMA is part of the VMA tree and needs appropriate locking */ > +static inline > +void reset_vm_flags(struct vm_area_struct *vma, unsigned long flags) > +{ > + vma_write_lock(vma); > + init_vm_flags(vma, flags); > +} > + > +static inline > +void set_vm_flags(struct vm_area_struct *vma, unsigned long flags) > +{ > + vma_write_lock(vma); > + vma->vm_flags |= flags; > +} > + > +static inline > +void clear_vm_flags(struct vm_area_struct *vma, unsigned long flags) > +{ > + vma_write_lock(vma); > + vma->vm_flags &= ~flags; > +} > + > +static inline > +void mod_vm_flags(struct vm_area_struct *vma, > + unsigned long set, unsigned long clear) > +{ > + vma_write_lock(vma); > + vma->vm_flags |= set; > + vma->vm_flags &= ~clear; > +} > + This is rather unusual pattern. There is no note about locking involved in the naming and also why is the locking part of this interface in the first place? I can see reason for access functions to actually check for lock asserts.
On Tue 17-01-23 16:09:03, Michal Hocko wrote: > On Mon 09-01-23 12:53:08, Suren Baghdasaryan wrote: > > To keep vma locking correctness when vm_flags are modified, add modifier > > functions to be used whenever flags are updated. > > > > Signed-off-by: Suren Baghdasaryan <surenb@google.com> > > --- > > include/linux/mm.h | 38 ++++++++++++++++++++++++++++++++++++++ > > include/linux/mm_types.h | 8 +++++++- > > 2 files changed, 45 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index ec2c4c227d51..35cf0a6cbcc2 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -702,6 +702,44 @@ static inline void vma_init(struct vm_area_struct *vma, struct mm_struct *mm) > > vma_init_lock(vma); > > } > > > > +/* 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, unsigned long flags) > > +{ > > + WRITE_ONCE(vma->vm_flags, flags); > > +} > > Why do we need WRITE_ONCE here? Isn't vma invisible during its > initialization? > > > + > > +/* Use when VMA is part of the VMA tree and needs appropriate locking */ > > +static inline > > +void reset_vm_flags(struct vm_area_struct *vma, unsigned long flags) > > +{ > > + vma_write_lock(vma); > > + init_vm_flags(vma, flags); > > +} > > + > > +static inline > > +void set_vm_flags(struct vm_area_struct *vma, unsigned long flags) > > +{ > > + vma_write_lock(vma); > > + vma->vm_flags |= flags; > > +} > > + > > +static inline > > +void clear_vm_flags(struct vm_area_struct *vma, unsigned long flags) > > +{ > > + vma_write_lock(vma); > > + vma->vm_flags &= ~flags; > > +} > > + > > +static inline > > +void mod_vm_flags(struct vm_area_struct *vma, > > + unsigned long set, unsigned long clear) > > +{ > > + vma_write_lock(vma); > > + vma->vm_flags |= set; > > + vma->vm_flags &= ~clear; > > +} > > + > > This is rather unusual pattern. There is no note about locking involved > in the naming and also why is the locking part of this interface in the > first place? I can see reason for access functions to actually check for > lock asserts. OK, it took me a while but it is clear to me now. The confusion comes from the naming vma_write_lock is no a lock in its usual terms. It is more of a vma_mark_modified with side effects to read locking which is a real lock. With that it makes more sense to have this done in these helpers rather than requiring all users to keep this subtletly in mind.
On Tue, Jan 17, 2023 at 7:15 AM 'Michal Hocko' via kernel-team <kernel-team@android.com> wrote: > > On Tue 17-01-23 16:09:03, Michal Hocko wrote: > > On Mon 09-01-23 12:53:08, Suren Baghdasaryan wrote: > > > To keep vma locking correctness when vm_flags are modified, add modifier > > > functions to be used whenever flags are updated. > > > > > > Signed-off-by: Suren Baghdasaryan <surenb@google.com> > > > --- > > > include/linux/mm.h | 38 ++++++++++++++++++++++++++++++++++++++ > > > include/linux/mm_types.h | 8 +++++++- > > > 2 files changed, 45 insertions(+), 1 deletion(-) > > > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > > index ec2c4c227d51..35cf0a6cbcc2 100644 > > > --- a/include/linux/mm.h > > > +++ b/include/linux/mm.h > > > @@ -702,6 +702,44 @@ static inline void vma_init(struct vm_area_struct *vma, struct mm_struct *mm) > > > vma_init_lock(vma); > > > } > > > > > > +/* 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, unsigned long flags) > > > +{ > > > + WRITE_ONCE(vma->vm_flags, flags); > > > +} > > > > Why do we need WRITE_ONCE here? Isn't vma invisible during its > > initialization? Ack. Will change to a simple assignment. > > > > > + > > > +/* Use when VMA is part of the VMA tree and needs appropriate locking */ > > > +static inline > > > +void reset_vm_flags(struct vm_area_struct *vma, unsigned long flags) > > > +{ > > > + vma_write_lock(vma); > > > + init_vm_flags(vma, flags); > > > +} > > > + > > > +static inline > > > +void set_vm_flags(struct vm_area_struct *vma, unsigned long flags) > > > +{ > > > + vma_write_lock(vma); > > > + vma->vm_flags |= flags; > > > +} > > > + > > > +static inline > > > +void clear_vm_flags(struct vm_area_struct *vma, unsigned long flags) > > > +{ > > > + vma_write_lock(vma); > > > + vma->vm_flags &= ~flags; > > > +} > > > + > > > +static inline > > > +void mod_vm_flags(struct vm_area_struct *vma, > > > + unsigned long set, unsigned long clear) > > > +{ > > > + vma_write_lock(vma); > > > + vma->vm_flags |= set; > > > + vma->vm_flags &= ~clear; > > > +} > > > + > > > > This is rather unusual pattern. There is no note about locking involved > > in the naming and also why is the locking part of this interface in the > > first place? I can see reason for access functions to actually check for > > lock asserts. > > OK, it took me a while but it is clear to me now. The confusion comes > from the naming vma_write_lock is no a lock in its usual terms. It is > more of a vma_mark_modified with side effects to read locking which is a > real lock. With that it makes more sense to have this done in these > helpers rather than requiring all users to keep this subtletly in mind. If renaming vma-locking primitives the way Matthew suggested in https://lore.kernel.org/all/Y8cZMt01Z1FvVFXh@casper.infradead.org/ makes it easier to read/understand, I'm all for it. Let's discuss the naming in that email thread because that's where these functions are introduced. > > -- > Michal Hocko > SUSE Labs > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >
diff --git a/include/linux/mm.h b/include/linux/mm.h index ec2c4c227d51..35cf0a6cbcc2 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -702,6 +702,44 @@ static inline void vma_init(struct vm_area_struct *vma, struct mm_struct *mm) vma_init_lock(vma); } +/* 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, unsigned long flags) +{ + WRITE_ONCE(vma->vm_flags, flags); +} + +/* Use when VMA is part of the VMA tree and needs appropriate locking */ +static inline +void reset_vm_flags(struct vm_area_struct *vma, unsigned long flags) +{ + vma_write_lock(vma); + init_vm_flags(vma, flags); +} + +static inline +void set_vm_flags(struct vm_area_struct *vma, unsigned long flags) +{ + vma_write_lock(vma); + vma->vm_flags |= flags; +} + +static inline +void clear_vm_flags(struct vm_area_struct *vma, unsigned long flags) +{ + vma_write_lock(vma); + vma->vm_flags &= ~flags; +} + +static inline +void mod_vm_flags(struct vm_area_struct *vma, + unsigned long set, unsigned long clear) +{ + vma_write_lock(vma); + vma->vm_flags |= set; + 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 5f7c5ca89931..0d27edd3e63a 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -553,7 +553,13 @@ 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. + * WARNING! Do not modify directly to keep correct VMA locking. + * Use {init|reset|set|clear|mod}_vm_flags() functions instead. + */ + unsigned long vm_flags; #ifdef CONFIG_PER_VMA_LOCK int vm_lock_seq;