From: sashiko-bot@kernel.org
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Cc: linux-usb@vger.kernel.org, linux-rdma@vger.kernel.org,
selinux@vger.kernel.org, bpf@vger.kernel.org,
linux-scsi@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-trace-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org, kvmarm@lists.linux.dev,
kvm@vger.kernel.org, linux-s390@vger.kernel.org,
"Oliver Upton" <oupton@kernel.org>,
"Marc Zyngier" <maz@kernel.org>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>
Subject: Re: [PATCH v6 11/39] infiniband: update hfi1 to use remap_vmalloc_range()
Date: Tue, 13 Oct 2026 17:04:45 +0000 [thread overview]
Message-ID: <sashiko-outbox-170187@kernel.org> (raw)
In-Reply-To: <20261013-b4-mmap-prepare-vma-flag-sanify-v6-11-1aa3c9b139f9@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mm: VM_WARN_ON_ONCE triggered by vm_flags_reset() in mmap hook
--
commit a356d47e4beede9d3e032c777130976d06dd5dd8
Author: Lorenzo Stoakes (ARM) <ljs@kernel.org>
infiniband: update hfi1 to use remap_vmalloc_range()
In cases which map chip memory from vmalloc()'d ranges, the hfi1 infiniband
drivers currently installs a fault handler, and then smuggles the kernel
virtual address of this range in vma->vm_pgoff.
> diff --git a/drivers/infiniband/hw/hfi1/file_ops.c b/drivers/infiniband/hw/hfi1/file_ops.c
> index dc548e6802e24..b02d1f1dbb27b 100644
> --- a/drivers/infiniband/hw/hfi1/file_ops.c
> +++ b/drivers/infiniband/hw/hfi1/file_ops.c
[ ... ]
> @@ -422,7 +418,7 @@ static int hfi1_file_mmap(struct file *fp, struct vm_area_struct *vma)
> ret = -EPERM;
> goto done;
> }
> - vm_flags_clear(vma, VM_MAYWRITE);
> + vm_flags_mod(vma, VM_DONTEXPAND, VM_MAYWRITE);
> /*
> * Mmap multiple separate allocations into a single vma. From
> * here, dma_mmap_coherent() calls dma_direct_mmap(), which
[ ... ]
> @@ -559,12 +546,10 @@ static int hfi1_file_mmap(struct file *fp, struct vm_area_struct *vma)
> }
>
> vm_flags_reset(vma, flags);
> - mmap_cdbg(ctxt, subctxt, type, mapio, vmf, memaddr, memvirt, memdma,
> + mmap_cdbg(ctxt, subctxt, type, mapio, is_vmalloc, memaddr, memvirt, memdma,
> memlen, vma);
> - if (vmf) {
> - vma->vm_pgoff = PFN_DOWN(memaddr);
> - vma->vm_ops = &vm_ops;
> - ret = 0;
> + if (is_vmalloc) {
> + ret = remap_vmalloc_range(vma, memvirt, 0);
[Severity: Medium]
Will this trigger a lockdep warning due to the VMA not being write-locked?
In hfi1_file_mmap(), modifying the VMA flags using vm_flags_reset() (and
the newly introduced vm_flags_mod() earlier in this function) enforces
write-lock assertions via vma_assert_write_locked().
Because the VMA is not yet inserted into the tree and is not write-locked
during the mmap callback, its vm_lock_seq is uninitialized (UINT_MAX) and
will not match the mm lock sequence. This triggers a VM_WARN_ON_ONCE_VMA.
Should vm_flags_init() be used instead?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261013-b4-mmap-prepare-vma-flag-sanify-v6-0-1aa3c9b139f9@kernel.org?part=11
next prev parent reply other threads:[~2026-10-13 17:04 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 15:04 [PATCH v6 00/39] mm: make VMA flag semantics explicit, eliminate VM_SPECIAL Lorenzo Stoakes (ARM)
2026-10-13 15:04 ` [PATCH v6 01/39] mm/vma: fix mmap_prepare file handling, remove file_doesnt_need_get Lorenzo Stoakes (ARM)
2026-10-13 15:04 ` [PATCH v6 02/39] mm/vma: introduce and use vma_[flags_]can_merge() Lorenzo Stoakes (ARM)
2026-10-13 15:19 ` David Hildenbrand (Arm)
2026-10-13 15:04 ` [PATCH v6 03/39] mm: consistently validate VMA state after mmap[_prepare] hooks Lorenzo Stoakes (ARM)
2026-10-13 15:04 ` [PATCH v6 04/39] mm/vma: ensure mmap_prepare doesn't set actions on a mergeable vma Lorenzo Stoakes (ARM)
2026-10-13 15:04 ` [PATCH v6 05/39] mm: make map_kernel_pages_[prepare,complete] internal and unexported Lorenzo Stoakes (ARM)
2026-10-13 15:04 ` [PATCH v6 06/39] mm/vma: tidy up map kernel pages enum values Lorenzo Stoakes (ARM)
2026-10-13 15:04 ` [PATCH v6 07/39] mm: assert mmap lock held, use new flags API in vm_insert_page[s] Lorenzo Stoakes (ARM)
2026-10-13 15:20 ` David Hildenbrand (Arm)
2026-10-13 15:04 ` [PATCH v6 08/39] mm: add mmap action for discontiguous kernel page mapping Lorenzo Stoakes (ARM)
2026-10-13 15:24 ` David Hildenbrand (Arm)
2026-10-13 16:29 ` sashiko-bot
2026-10-13 15:04 ` [PATCH v6 09/39] docs: filesystems: update mmap_prepare docs for discontig kernel pgs Lorenzo Stoakes (ARM)
2026-10-13 15:25 ` David Hildenbrand (Arm)
2026-10-13 15:04 ` [PATCH v6 10/39] drivers/usb/mon: update to use mmap_prepare + map kernel pages Lorenzo Stoakes (ARM)
2026-10-13 15:04 ` [PATCH v6 11/39] infiniband: update hfi1 to use remap_vmalloc_range() Lorenzo Stoakes (ARM)
2026-10-13 17:04 ` sashiko-bot [this message]
2026-10-13 15:04 ` [PATCH v6 12/39] selinux: reject writable opens of policy file, drop mmap shared/write check Lorenzo Stoakes (ARM)
2026-10-13 15:04 ` [PATCH v6 13/39] ALSA: pcm: use vm_insert_page() to map PCM status page Lorenzo Stoakes (ARM)
2026-10-13 15:04 ` [PATCH v6 14/39] bpf: arena: mark arena_map_mmap() mappings VM_MIXEDMAP Lorenzo Stoakes (ARM)
2026-10-13 15:04 ` [PATCH v6 15/39] mm/vma: add vma[_flags]_is_mm_managed() predicates Lorenzo Stoakes (ARM)
2026-10-13 15:04 ` [PATCH v6 16/39] mm/vma: only allow mmap to clear VMA_MAYWRITE_BIT if not mm-managed Lorenzo Stoakes (ARM)
2026-10-13 15:04 ` [PATCH v6 17/39] mm/vma: add and use vma_[flags]_is_fixed_mapping Lorenzo Stoakes (ARM)
2026-10-13 15:04 ` [PATCH v6 18/39] scsi: sg: convert mmap hook to mmap_prepare and rework Lorenzo Stoakes (ARM)
2026-10-13 15:04 ` [PATCH v6 19/39] fbdev: defio: assert FBINFO_VIRTFB, drop VM_IO, add VM_MIXEDMAP Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 20/39] HSI: cmt_speech: convert mmap hook to mmap_prepare, refactor Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 21/39] mm/gup: error out early on !VMA_MAYREAD_BIT VMAs Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 22/39] uprobes: remove VM_IO, set VM_MIXEDMAP for mapped kernel pages Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 23/39] mm/mlock: clear VMA_LOCKED_MASK over mmap callback Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 24/39] mm/mlock: eliminate weird VMA_IO_BIT abuse and simplify Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 25/39] mm/vma: enforce that mm-managed mappings may not set VMA_IO_BIT Lorenzo Stoakes (ARM)
2026-10-13 15:26 ` David Hildenbrand (Arm)
2026-10-13 15:05 ` [PATCH v6 26/39] mm: remove VMA_IO_BIT check in vma[_flags]_is_mm_managed() Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 27/39] mm: remove hugetlb_inline.h Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 28/39] mm: rename is_vm_hugetlb_page() to vma_is_hugetlb() Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 29/39] mm: drop some redundant checks around hugetlb VMAs Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 30/39] mm/vma: introduce vma[_flags]_is_mm_backed() Lorenzo Stoakes (ARM)
2026-10-13 15:31 ` David Hildenbrand (Arm)
2026-10-13 15:05 ` [PATCH v6 31/39] mm/madvise: update is_valid_guard_vma() to use vma_is_mm_backed() Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 32/39] mm/uffd: use predicates for userfaultfd checks Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 33/39] mm/madvise: use predicates for madvise(..., MADV_DOFORK) Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 34/39] mm: eliminate VMA_SPECIAL_FLAGS usage when hugetlb explicitly tested Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 35/39] mm: eliminate VMA_SPECIAL_FLAGS check in lru_gen_look_around() Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 36/39] mm: avoid use of VMA_SPECIAL_FLAGS in migrate_vma_setup() Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 37/39] mm: eliminate VM_SPECIAL, VMA_SPECIAL_FLAGS Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 38/39] fuse: dax: do not set VM_MIXEDMAP Lorenzo Stoakes (ARM)
2026-10-13 15:05 ` [PATCH v6 39/39] mm/huge_memory: remove vma_is_special_huge() Lorenzo Stoakes (ARM)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-170187@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=bpf@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=selinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox