public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	Bard Liao <yung-chuan.liao@linux.intel.com>,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Daniel Baluta <daniel.baluta@nxp.com>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	Paul Olaru <paul.olaru@oss.nxp.com>,
	Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>,
	sound-open-firmware@alsa-project.org,
	linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] ASoC: SOF: Don't allow pointer operations on unconfigured streams
Date: Tue, 31 Mar 2026 08:12:25 +0300	[thread overview]
Message-ID: <8f37f7dc-bcac-4344-9532-b59eac7e1ffd@linux.intel.com> (raw)
In-Reply-To: <accf8fa2-72b2-48a5-bdb7-72784b199347@sirena.org.uk>



On 30/03/2026 23:11, Mark Brown wrote:
> On Mon, Mar 30, 2026 at 02:50:15PM +0300, Péter Ujfalusi wrote:
>> On 30/03/2026 14:05, Mark Brown wrote:
> 
>>> We don't generally guard calls based on the state the stream is in,
> 
>> compress does this quite much, just avail and tstamp is exempt for some
>> reason.
> 
> Actually already we have a guard preventing userspace from doing an
> avail() when we're unconfigured but we do it after we've called down
> into the driver which is less than ideal.  I think that's because we
> also check for XRUN and the availability check might cause us to notice
> that we're in a bad state for that.

I don't see how the avail path checks for XRUN and if the drivers
supposed to do that, I'm not even sure if XRUN is possible with compress..

I did noted that the avail have the state check reversed, making it
ineffective.

The other point is that any return code from the driver's pointer
callback is ignored by the core, the return value of
stream->ops->pointer() is not even captured, it could be void.
Looks like a design choice, but I cannot say.

fwiw, the same check should be added to sound/soc/qcom/qdsp6/q6apm-dai.c
as it does div with prtd->pcm_size (q6apm_dai_compr_pointer), which is
only initialized in set_params.

-- 
Péter


  reply	other threads:[~2026-03-31  5:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-26 14:52 [PATCH] ASoC: SOF: Don't allow pointer operations on unconfigured streams Mark Brown
2026-03-27  2:09 ` Liao, Bard
2026-03-27 16:48   ` Mark Brown
2026-03-30  2:32     ` Liao, Bard
2026-03-27  9:49 ` Péter Ujfalusi
2026-03-27 16:52   ` Mark Brown
2026-03-30  7:01     ` Péter Ujfalusi
2026-03-30 11:05       ` Mark Brown
2026-03-30 11:50         ` Péter Ujfalusi
2026-03-30 20:11           ` Mark Brown
2026-03-31  5:12             ` Péter Ujfalusi [this message]
2026-03-31 11:25               ` Mark Brown

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=8f37f7dc-bcac-4344-9532-b59eac7e1ffd@linux.intel.com \
    --to=peter.ujfalusi@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=daniel.baluta@nxp.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=laurentiu.mihalcea@nxp.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=paul.olaru@oss.nxp.com \
    --cc=perex@perex.cz \
    --cc=pierre-louis.bossart@linux.dev \
    --cc=ranjani.sridharan@linux.intel.com \
    --cc=sound-open-firmware@alsa-project.org \
    --cc=stable@vger.kernel.org \
    --cc=tiwai@suse.com \
    --cc=yung-chuan.liao@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox