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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Sat, Oct 24, 2026 at 10:21:59AM +0000, sashiko-bot@kernel.org wrote:
> 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?

This describes a bug that I recently sent a fix for.

--
Cheers, Lorenzo