All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	Kazuki Hanai <hnkz.64@gmail.com>, Takashi Iwai <tiwai@suse.de>,
	linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, David Carlier <devnexen@gmail.com>
Subject: Re: [PATCH] ALSA: us122l: mark hwdep mappings VM_MIXEDMAP
Date: Fri, 23 Oct 2026 15:30:28 +0200	[thread overview]
Message-ID: <87pkx0a6iz.wl-tiwai@suse.de> (raw)
In-Reply-To: <20261023-fix-us122l-mixedmap-v1-1-e7bdd053850f@kernel.org>

On Fri, 23 Oct 2026 12:21:31 +0200,
Lorenzo Stoakes (ARM) wrote:
> 
> mm has recently moved to a strict model which requires any driver which
> clears VMA_MAYWRITE_BIT to be mapping non-mm-managed memory
> (VMA_PFNMAP_BIT or VMA_MIXEDMAP_BIT), failing any such mmap() with an
> error and a kernel warning - see "mm/vma: only allow mmap to clear
> VMA_MAYWRITE_BIT if not mm-managed".
> 
> However, simultaneous to this, commit 71c610aeb177 ("ALSA: us122l: Prevent
> write upgrades for read mappings") updated us122l to clear
> VMA_MAYWRITE_BIT without marking the region with either VMA_PFNMAP_BIT or
> VMA_MIXEDMAP_BIT.
> 
> vm_insert_pages() and friends set this automatically, however this driver
> maps its pre-allocated pages from a fault handler, so never calls these.
> 
> Simply set the flag in usb_stream_hwdep_mmap() to resolve the issue. This
> correctly marks the mapping as one whose pages core mm does not manage,
> which has no meaningful impact for this driver beyond preventing the mmap()
> from failing.
> 
> Fixes: 71c610aeb177 ("ALSA: us122l: Prevent write upgrades for read mappings")
> Reported-by: David Carlier <devnexen@gmail.com>
> Closes: https://lore.kernel.org/20261018025905.201296-1-devnexen@gmail.com
> Cc: Kazuki Hanai <hnkz.64@gmail.com>
> Cc: Takashi Iwai <tiwai@suse.com>
> Cc: Jaroslav Kysela <perex@perex.cz>
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
> Andrew - I think easiest for you to take this.
> 
> It should go in before my series ideally to avoid bisection hazard, I think
> while it's a fix for the driver, that'll be the safest way.

Yes, feel free to take:

Acked-by: Takashi Iwai <tiwai@suse.de>


thanks,

Takashi


  reply	other threads:[~2026-10-23 13:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-23 10:21 [PATCH] ALSA: us122l: mark hwdep mappings VM_MIXEDMAP Lorenzo Stoakes (ARM)
2026-10-23 13:30 ` Takashi Iwai [this message]
2026-10-24 10:21 ` sashiko-bot
2026-10-26  9:48   ` 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=87pkx0a6iz.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=devnexen@gmail.com \
    --cc=hnkz.64@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.