Re: [PATCH v5 24/38] mm/vma: enforce that mm-managed mappings may not set VMA_IO_BIT
flat view
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Date: 2026-10-12 18:58:22
Also in:
bpf, dri-devel, fuse-devel, kvm, kvm-riscv, kvmarm, linux-arch, linux-doc, linux-fsdevel, linux-mm, linux-perf-users, linux-rdma, linux-s390, linux-scsi, linux-sound, linux-trace-kernel, linux-usb, linuxppc-dev, lkml, selinux, sparclinux
On Mon, Oct 12, 2026 at 08:51:10PM +0200, David Hildenbrand (Arm) wrote:
On 10/12/26 20:48, Lorenzo Stoakes (ARM) wrote:
quoted
On Mon, Oct 12, 2026 at 08:39:35PM +0200, David Hildenbrand (Arm) wrote:
quoted
On 10/12/26 20:35, Lorenzo Stoakes (ARM) wrote:
quoted
That gets removed.
I mean we do that in a subsequent commit, I think even the next one?
Yeah, but to do that the code would now be something like:
vma_flags_t masked = flags;
/*
* vma_flags_is_mm_managed() tests VMA_IO_BIT, which will be removed
* in the next commit.
*/
vma_flags_clear(&flags, VMA_IO_BIT);
if (!vma_flags_is_mm_managed(masked)) {
...
}
Is that really worth it?
I don't think there's really too much confusion intra-patch about that is there?
I would do it as above (- the comment, as that is the next patch indeed) and
only remove the vma_flags_clear() in the next patch.
But in any case, you should spell out that this is only temporary in the patch
description :)
And then there's a 'masked' variable that is unused?
You need to have two vma_flags_t variables to be able both clear VMA_IO_BIT
and use vma_flags_is_mm_managed().
So the change would have to be
+ vma_flags_t masked = *flags;
+
+ vma_flags_clear(&flags, VMA_IO_BIT);
+ if (!vma_flags_is_mm_managed(&masked)) {
+ ...
+ }
Then:
- vma_flags_t masked = *flags;
-
- vma_flags_clear(&flags, VMA_IO_BIT);
- if (!vma_flags_is_mm_managed(&masked)) {
+ if (!vma_flags_is_mm_managed(flags)) {
...
}
Which doesn't really seem worth it for somebody who is confused between two
patches mid-series.
But if you feel strongly I can make the change like that?
Whatever you prefer. Most important thing for me was finding it in the next
patch and being pleasantly surprised ;)
I'd rather not then!
It was always intended that way, this was all part of a careful dance to ensure
correct behaviour right up until the point where we enforce that VMA_IO_BIT is only set when appropriate.
I can update the commit message to reflect it.
--
Cheers, Lorenzo