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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1E89C54EAA for ; Thu, 26 Jan 2023 23:09:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233386AbjAZXJl (ORCPT ); Thu, 26 Jan 2023 18:09:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34490 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229817AbjAZXJj (ORCPT ); Thu, 26 Jan 2023 18:09:39 -0500 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1785669500 for ; Thu, 26 Jan 2023 15:09:37 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 1B95FCE2537 for ; Thu, 26 Jan 2023 23:09:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48C3AC433EF; Thu, 26 Jan 2023 23:09:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1674774574; bh=4gTy5wgZAtiBSFoLKlintzelM/FHQ+CuaAWY/Aw+Tjk=; h=Date:To:From:Subject:From; b=rnT164sHXeZXF9PfknQlNTbjdKJJYuf8DiCLAuyTEetTM/kQjEDA6mBOYamx/y1TC 3FVdNUx5QM5E5hJvT+BFU31aflZodF6a549wAdcLejiDiUF+OHULmYpdBEY2+p7CZG KIYMHMCa1LLSYYjZkNTZ5DFLhVuqg9L6lGx23IfE= Date: Thu, 26 Jan 2023 15:09:33 -0800 To: mm-commits@vger.kernel.org, willy@infradead.org, will@kernel.org, vbabka@suse.cz, songliubraving@fb.com, soheil@google.com, shakeelb@google.com, sebastian.reichel@collabora.com, rppt@kernel.org, rientjes@google.com, punit.agrawal@bytedance.com, posk@google.com, peterz@infradead.org, peterx@redhat.com, paulmck@kernel.org, mingo@redhat.com, minchan@google.com, mhocko@suse.com, mgorman@techsingularity.net, luto@kernel.org, lstoakes@gmail.com, Liam.Howlett@Oracle.com, ldufour@linux.ibm.com, kent.overstreet@linux.dev, joelaf@google.com, jannh@google.com, hughd@google.com, hannes@cmpxchg.org, gthelen@google.com, edumazet@google.com, dhowells@redhat.com, david@redhat.com, dave@stgolabs.net, bigeasy@linutronix.de, axelrasmussen@google.com, arjunroy@google.com, surenb@google.com, akpm@linux-foundation.org From: Andrew Morton Subject: + mm-introduce-vma-vm_flags-wrapper-functions.patch added to mm-unstable branch Message-Id: <20230126230934.48C3AC433EF@smtp.kernel.org> Precedence: bulk Reply-To: linux-kernel@vger.kernel.org List-ID: X-Mailing-List: mm-commits@vger.kernel.org The patch titled Subject: mm: introduce vma->vm_flags wrapper functions has been added to the -mm mm-unstable branch. Its filename is mm-introduce-vma-vm_flags-wrapper-functions.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-introduce-vma-vm_flags-wrapper-functions.patch This patch will later appear in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Suren Baghdasaryan Subject: mm: introduce vma->vm_flags wrapper functions Date: Thu, 26 Jan 2023 11:37:47 -0800 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. Link: https://lkml.kernel.org/r/20230126193752.297968-3-surenb@google.com Signed-off-by: Suren Baghdasaryan Reviewed-by: Davidlohr Bueso Acked-by: Michal Hocko Acked-by: Mel Gorman Acked-by: Mike Rapoport (IBM) Cc: Andy Lutomirski Cc: Arjun Roy Cc: Axel Rasmussen Cc: David Hildenbrand Cc: David Howells Cc: David Rientjes Cc: Eric Dumazet Cc: Greg Thelen Cc: Hugh Dickins Cc: Ingo Molnar Cc: Jann Horn Cc: Joel Fernandes Cc: Johannes Weiner Cc: Kent Overstreet Cc: Laurent Dufour Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Wilcox Cc: Minchan Kim Cc: Paul E. McKenney Cc: Peter Oskolkov Cc: Peter Xu Cc: Peter Zijlstra Cc: Punit Agrawal Cc: Sebastian Andrzej Siewior Cc: Sebastian Reichel Cc: Shakeel Butt Cc: Soheil Hassas Yeganeh Cc: Song Liu Cc: Vlastimil Babka Cc: Will Deacon Signed-off-by: Andrew Morton --- include/linux/mm.h | 40 +++++++++++++++++++++++++++++++++++++ include/linux/mm_types.h | 10 ++++++++- 2 files changed, 49 insertions(+), 1 deletion(-) --- a/include/linux/mm.h~mm-introduce-vma-vm_flags-wrapper-functions +++ a/include/linux/mm.h @@ -627,6 +627,46 @@ static inline void vma_init(struct vm_ar INIT_LIST_HEAD(&vma->anon_vma_chain); } +/* Use when VMA is not part of the VMA tree and needs no locking */ +static inline void vm_flags_init(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 vm_flags_reset(struct vm_area_struct *vma, + vm_flags_t flags) +{ + mmap_assert_write_locked(vma->vm_mm); + vm_flags_init(vma, flags); +} + +static inline void vm_flags_set(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 vm_flags_clear(struct vm_area_struct *vma, + vm_flags_t flags) +{ + mmap_assert_write_locked(vma->vm_mm); + ACCESS_PRIVATE(vma, __vm_flags) &= ~flags; +} + +/* + * Use only when the order of set/clear operations is unimportant, otherwise + * use vm_flags_{set|clear} explicitly. + */ +static inline void vm_flags_mod(struct vm_area_struct *vma, + vm_flags_t set, vm_flags_t clear) +{ + mmap_assert_write_locked(vma->vm_mm); + vm_flags_init(vma, (vma->vm_flags | set) & ~clear); +} + static inline void vma_set_anonymous(struct vm_area_struct *vma) { vma->vm_ops = NULL; --- a/include/linux/mm_types.h~mm-introduce-vma-vm_flags-wrapper-functions +++ a/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 vm_flags_{init|reset|set|clear|mod} functions. + */ + union { + const vm_flags_t vm_flags; + vm_flags_t __private __vm_flags; + }; /* * For areas with an address space and backing store, _ Patches currently in -mm which might be from surenb@google.com are kernel-fork-convert-vma-assignment-to-a-memcpy.patch mm-introduce-vma-vm_flags-wrapper-functions.patch mm-replace-vm_locked_clear_mask-with-vm_locked_mask.patch mm-replace-vma-vm_flags-direct-modifications-with-modifier-calls.patch mm-replace-vma-vm_flags-indirect-modification-in-ksm_madvise.patch mm-introduce-__vm_flags_mod-and-use-it-in-untrack_pfn.patch mm-export-dump_mm.patch