| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <Y9JFFYjfJf9uDijE@kernel.org>
Date: Thu, 26 Jan 2023 11:17:09 +0200
From: Mike Rapoport <rppt@...nel.org>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: akpm@...ux-foundation.org, michel@...pinasse.org,
jglisse@...gle.com, mhocko@...e.com, vbabka@...e.cz,
hannes@...xchg.org, mgorman@...hsingularity.net, dave@...olabs.net,
willy@...radead.org, liam.howlett@...cle.com, peterz@...radead.org,
ldufour@...ux.ibm.com, paulmck@...nel.org, luto@...nel.org,
songliubraving@...com, peterx@...hat.com, david@...hat.com,
dhowells@...hat.com, hughd@...gle.com, bigeasy@...utronix.de,
kent.overstreet@...ux.dev, punit.agrawal@...edance.com,
lstoakes@...il.com, peterjung1337@...il.com, rientjes@...gle.com,
axelrasmussen@...gle.com, joelaf@...gle.com, minchan@...gle.com,
jannh@...gle.com, shakeelb@...gle.com, tatashin@...gle.com,
edumazet@...gle.com, gthelen@...gle.com, gurua@...gle.com,
arjunroy@...gle.com, soheil@...gle.com, hughlynch@...gle.com,
leewalsh@...gle.com, posk@...gle.com, will@...nel.org,
aneesh.kumar@...ux.ibm.com, npiggin@...il.com,
chenhuacai@...nel.org, tglx@...utronix.de, mingo@...hat.com,
bp@...en8.de, dave.hansen@...ux.intel.com, richard@....at,
anton.ivanov@...bridgegreys.com, johannes@...solutions.net,
qianweili@...wei.com, wangzhou1@...ilicon.com,
herbert@...dor.apana.org.au, davem@...emloft.net, vkoul@...nel.org,
airlied@...il.com, daniel@...ll.ch,
maarten.lankhorst@...ux.intel.com, mripard@...nel.org,
tzimmermann@...e.de, l.stach@...gutronix.de,
krzysztof.kozlowski@...aro.org, patrik.r.jakobsson@...il.com,
matthias.bgg@...il.com, robdclark@...il.com,
quic_abhinavk@...cinc.com, dmitry.baryshkov@...aro.org,
tomba@...nel.org, hjc@...k-chips.com, heiko@...ech.de,
ray.huang@....com, kraxel@...hat.com, sre@...nel.org,
mcoquelin.stm32@...il.com, alexandre.torgue@...s.st.com,
tfiga@...omium.org, m.szyprowski@...sung.com, mchehab@...nel.org,
dimitri.sivanich@....com, zhangfei.gao@...aro.org,
jejb@...ux.ibm.com, martin.petersen@...cle.com,
dgilbert@...erlog.com, hdegoede@...hat.com, mst@...hat.com,
jasowang@...hat.com, alex.williamson@...hat.com, deller@....de,
jayalk@...works.biz, viro@...iv.linux.org.uk, nico@...xnic.net,
xiang@...nel.org, chao@...nel.org, tytso@....edu,
adilger.kernel@...ger.ca, miklos@...redi.hu,
mike.kravetz@...cle.com, muchun.song@...ux.dev, bhe@...hat.com,
andrii@...nel.org, yoshfuji@...ux-ipv6.org, dsahern@...nel.org,
kuba@...nel.org, pabeni@...hat.com, perex@...ex.cz, tiwai@...e.com,
haojian.zhuang@...il.com, robert.jarzmik@...e.fr,
linux-mm@...ck.org, linux-arm-kernel@...ts.infradead.org,
linuxppc-dev@...ts.ozlabs.org, x86@...nel.org,
linux-kernel@...r.kernel.org, linux-graphics-maintainer@...are.com,
linux-ia64@...r.kernel.org, linux-arch@...r.kernel.org,
loongarch@...ts.linux.dev, kvm@...r.kernel.org,
linux-s390@...r.kernel.org, linux-sgx@...r.kernel.org,
linux-um@...ts.infradead.org, linux-acpi@...r.kernel.org,
linux-crypto@...r.kernel.org, nvdimm@...ts.linux.dev,
dmaengine@...r.kernel.org, amd-gfx@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org, etnaviv@...ts.freedesktop.org,
linux-samsung-soc@...r.kernel.org, intel-gfx@...ts.freedesktop.org,
linux-mediatek@...ts.infradead.org, linux-arm-msm@...r.kernel.org,
freedreno@...ts.freedesktop.org,
linux-rockchip@...ts.infradead.org, linux-tegra@...r.kernel.org,
virtualization@...ts.linux-foundation.org,
xen-devel@...ts.xenproject.org,
linux-stm32@...md-mailman.stormreply.com,
linux-rdma@...r.kernel.org, linux-media@...r.kernel.org,
linux-accelerators@...ts.ozlabs.org, sparclinux@...r.kernel.org,
linux-scsi@...r.kernel.org, linux-staging@...ts.linux.dev,
target-devel@...r.kernel.org, linux-usb@...r.kernel.org,
netdev@...r.kernel.org, linux-fbdev@...r.kernel.org,
linux-aio@...ck.org, linux-fsdevel@...r.kernel.org,
linux-erofs@...ts.ozlabs.org, linux-ext4@...r.kernel.org,
devel@...ts.orangefs.org, kexec@...ts.infradead.org,
linux-xfs@...r.kernel.org, bpf@...r.kernel.org,
linux-perf-users@...r.kernel.org, kasan-dev@...glegroups.com,
selinux@...r.kernel.org, alsa-devel@...a-project.org,
kernel-team@...roid.com
Subject: Re: [PATCH v2 1/6] mm: introduce vma->vm_flags modifier functions
On Wed, Jan 25, 2023 at 12:38:46AM -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@...gle.com>
> ---
> include/linux/mm.h | 37 +++++++++++++++++++++++++++++++++++++
> include/linux/mm_types.h | 8 +++++++-
> 2 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index c2f62bdce134..b71f2809caac 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,
> + unsigned long flags)
I'd suggest to make it vm_flags_init() etc.
Except that
Acked-by: Mike Rapoport (IBM) <rppt@...nel.org>
> +{
> + 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,
> + unsigned long flags)
> +{
> + mmap_assert_write_locked(vma->vm_mm);
> + init_vm_flags(vma, flags);
> +}
> +
> +static inline void set_vm_flags(struct vm_area_struct *vma,
> + unsigned long flags)
> +{
> + mmap_assert_write_locked(vma->vm_mm);
> + vma->vm_flags |= flags;
> +}
> +
> +static inline void clear_vm_flags(struct vm_area_struct *vma,
> + unsigned long flags)
> +{
> + mmap_assert_write_locked(vma->vm_mm);
> + vma->vm_flags &= ~flags;
> +}
> +
> +static inline void mod_vm_flags(struct vm_area_struct *vma,
> + unsigned long set, unsigned long clear)
> +{
> + mmap_assert_write_locked(vma->vm_mm);
> + 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 2d6d790d9bed..6c7c70bf50dd 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -491,7 +491,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.
> + * Use {init|reset|set|clear|mod}_vm_flags() functions instead.
> + */
> + unsigned long vm_flags;
>
> /*
> * For areas with an address space and backing store,
> --
> 2.39.1
>
>
Powered by blists - more mailing lists