Re: [PATCH] ALSA: us122l: mark hwdep mappings VM_MIXEDMAP

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ALSA: us122l: VM_MIXEDMAP in usb_stream_hwdep_mmap() breaks mremap()
--

commit c40f3445d293957b8d56aca33b8d5ed4071fcf4b
Author: Lorenzo Stoakes (ARM) <ljs@kernel.org>

ALSA: us122l: mark hwdep mappings VM_MIXEDMAP

This commit sets VM_MIXEDMAP in usb_stream_hwdep_mmap() so that clearing
VM_MAYWRITE on read mappings satisfies the core mm requirement that
mappings clearing VMA_MAYWRITE_BIT must not be mm-managed.

> diff --git a/sound/usb/usx2y/us122l.c b/sound/usb/usx2y/us122l.c
> index a5db0d044ef96..2986a90ea3351 100644
> --- a/sound/usb/usx2y/us122l.c
> +++ b/sound/usb/usx2y/us122l.c
> @@ -193,7 +193,7 @@ static int usb_stream_hwdep_mmap(struct snd_hwdep *hw,
>  	}
>  
>  	area->vm_ops = &usb_stream_hwdep_vm_ops;
> -	vm_flags_set(area, VM_DONTDUMP);
> +	vm_flags_set(area, VM_MIXEDMAP | VM_DONTDUMP);
>  	if (!read)
>  		vm_flags_set(area, VM_DONTEXPAND);

[Severity: High]
Does setting VM_MIXEDMAP here cause a regression when userspace expands
the read mapping with mremap()?

In sound/usb/usx2y/us122l.c:usb_stream_hwdep_mmap(), VM_DONTEXPAND is
intentionally omitted when read is true so that userspace (such as the
alsa-plugins pcm_usb_stream plugin) can initially mmap() the first page to
read s->read_size and then expand the read VMA to s->read_size via
mremap().

When userspace calls mremap() to expand this VMA and the virtual address
range following the VMA is unmapped, do_mremap() -> mremap_at() ->
expand_vma() takes the in-place expansion path in mm/mremap.c:

mm/mremap.c:expand_vma() {
	if (vrm_can_expand_in_place(vrm)) {
		err = expand_vma_in_place(vrm);
		if (err)
			return err;

		/* OK we're done! */
		return vrm->addr;
	}
}

expand_vma_in_place() then calls vma_merge_extend():

mm/mremap.c:expand_vma_in_place() {
	vma = vma_merge_extend(&vmi, vma, vrm->delta);
	if (!vma) {
		vrm_uncharge(vrm);
		return -ENOMEM;
	}
}

However, vma_merge_extend() -> vma_merge_new_range() in mm/vma.c checks
whether the VMA flags allow merging:

mm/vma.c:vma_merge_new_range() {
	if (!vma_flags_can_merge(&vmg->vma_flags))
		return NULL;
}

And vma_flags_can_merge() -> vma_flags_is_mm_backed() ->
vma_flags_is_mm_managed() in include/linux/mm.h rejects VMAs with
VMA_MIXEDMAP_BIT set:

include/linux/mm.h:vma_flags_is_mm_managed() {
	return !vma_flags_test_any(flags, VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT);
}

With VM_MIXEDMAP set on the read VMA, won't vma_merge_extend() return NULL
and cause expand_vma_in_place() to fail the mremap() call with -ENOMEM?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261023-fix-us122l-mixedmap-v1-1-e7bdd053850f@kernel.org?part=1