All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Cezary Rojewski <cezary.rojewski@intel.com>,
	alsa-devel@alsa-project.org, broonie@kernel.org,
	vkoul@kernel.org
Subject: Re: [RFC PATCH 0/4] ALSA: hda: potential hdac_stream locking issues?
Date: Tue, 28 Sep 2021 10:45:22 +0200	[thread overview]
Message-ID: <s5hsfxpnl5p.wl-tiwai@suse.de> (raw)
In-Reply-To: <20210924192417.169243-1-pierre-louis.bossart@linux.intel.com>

On Fri, 24 Sep 2021 21:24:13 +0200,
Pierre-Louis Bossart wrote:
> 
> While reviewing the HDAudio DMA handling, I found a number of
> inconsistencies in how spin_locks are used. It's not clear what the
> HDaudio bus->reg_lock is supposed to protect. In most cases only the
> writes to specific boolean status flags are protected, and there are
> multiple cases of taking the lock after testing a status flag.
> 
> This patchset suggests a more consistent locking pattern, but it's
> entirely possible that the bus->reg_lock is only intented to protect
> register read/write access on the HDaudio bus, and not the status
> flags, and that this entire piece of code is completely
> over-engineered.
> 
> On the Intel side no one knows why this spinlock was used, the reasons
> are lost to history. I set the 'RFC' status on purpose in the hope
> that Takashi might recall what this lock is supposed to protect. The
> diff format makes this patchset difficult to review, it's recommended
> to apply the patches and look at entire functions with changes to get
> a better idea of the suggested changes.

Oh well, the missing piece was the lock inside the loop in
*_stream_assign().  It was lost while factoring out and converting to
the HD-audio core code.  (The lock wasn't taken on the whole loop at
that time because the list itself was supposed to be static.)

In anyway, I applied all patches except for patch#2, as the fixes for
spinlock look correct.


thanks,

Takashi

      parent reply	other threads:[~2021-09-28  8:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-24 19:24 [RFC PATCH 0/4] ALSA: hda: potential hdac_stream locking issues? Pierre-Louis Bossart
2021-09-24 19:24 ` [RFC PATCH 1/4] ALSA: hda: hdac_stream: fix potential locking issue in snd_hdac_stream_assign() Pierre-Louis Bossart
2021-09-24 19:24 ` [RFC PATCH 2/4] ALSA: hda: hdac_stream: reset assigned_key in stream_release() Pierre-Louis Bossart
2021-09-28  6:10   ` Takashi Iwai
2021-09-24 19:24 ` [RFC PATCH 3/4] ALSA: hda: hdac_ext_stream: fix potential locking issues Pierre-Louis Bossart
2021-09-24 19:24 ` [RFC PATCH 4/4] ASoC: SOF: Intel: hda-dai: fix potential locking issue Pierre-Louis Bossart
2021-09-24 19:52   ` Mark Brown
2021-09-28  8:45 ` Takashi Iwai [this message]

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=s5hsfxpnl5p.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=vkoul@kernel.org \
    /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.