All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Patel <ripatel@wii.dev>
To: Charles Keepax <ckeepax@opensource.cirrus.com>
Cc: vkoul@kernel.org, yung-chuan.liao@linux.intel.com,
	pierre-louis.bossart@linux.dev, peter.ujfalusi@linux.intel.com,
	linux-sound@vger.kernel.org, patches@opensource.cirrus.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] soundwire: intel_auxdevice: Don't disable IRQs before removing children
Date: Sun, 4 Oct 2026 12:29:58 +0000	[thread overview]
Message-ID: <asJGxhij4OzWNYn9@wii.dev> (raw)
In-Reply-To: <20260925154216.3520136-4-ckeepax@opensource.cirrus.com>

On Fri, Sep 25, 2026 at 04:42:16PM +0100, Charles Keepax wrote:
> Currently the auxiliary device for the link disables IRQs before it
> calls sdw_bus_master_delete(). This has the side effect that none
> of the devices on the link can access their own registers whilst
> their remove functions run, because the IRQs are required for bus
> transactions to function.
> 
> There appear to be two things that currently block leaving the
> IRQs enabled during peripheral removal. Firstly, the IRQ handler
> iterates through a linked list of all the links, once a link is
> removed the memory pointed at by this linked list is freed, but
> not removed from the linked_list. Secondly, the potential that
> an IRQ runs after the controller itself has been destroyed.
> 
> For the first problem add a list_del() for the linked list item,
> note whilst the list itself is contained in the intel_init portion
> of the code, the list remove needs to be attached to the auxiliary
> device for the link, since that owns the memory that the list points
> at. Locking is also required to ensure the IRQ handler runs either
> before or after any additions/removals from the list. A new lock is
> added for this, the shim_lock is used to gate access to the shared
> registers so doesn't feel a super obvious fit for managing the list.
> 
> For the second problem utilise the newly added helper that allows
> destroying the peripherals separately, allowing the auxiliary device
> to disable IRQs before running its own cleanup.

I ran into a use-after-free on Samsung Galaxy Book6 (Panther Lake)
the other day.  I was going to send a patch adding RCU, then I saw
your patch already added a mutex:

  sof-audio-pci-intel-ptl 0000:00:1f.3: SOF firmware and/or topology file not found.
  Oops: general protection fault, kernel NULL pointer dereference 0x3c0: 0000 [#1] SMP NOPTI
  RIP: 0010:sdw_cdns_irq+0x9/0x1f0 [soundwire_cadence]
  Call Trace:
   sdw_intel_thread+0x2d/0x50 [soundwire_intel]
   hda_dsp_interrupt_thread+0x97/0x320 [snd_sof_intel_hda_generic]
   irq_thread_fn+0x23/0x60
   irq_thread+0xc7/0x190

I would add 'Fixes: 4a98a6b2fa75 ("soundwire: intel/cadence: merge Soundwire interrupt handlers/threads")' maybe

> @@ -145,8 +155,10 @@ irqreturn_t sdw_intel_thread(int irq, void *dev_id)
>  	struct sdw_intel_ctx *ctx = dev_id;
>  	struct sdw_intel_link_res *link;
>  
> +	mutex_lock(&ctx->link_lock);
>  	list_for_each_entry(link, &ctx->link_list, list)
>  		sdw_cdns_irq(irq, link->cdns);
> +	mutex_unlock(&ctx->link_lock);
>  
>  	return IRQ_HANDLED;
>  }

I don't understand the code very well, but isn't there a second UAF
with the ctx object getting freed?  kfree(ctx) in sdw_intel_exit()
runs well before the IRQ is unregistered.

  -- Richard

  parent reply	other threads:[~2026-10-04 12:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-25 15:42 [PATCH v2 0/3] Allow SoundWire devices to communicate during remove Charles Keepax
2026-09-25 15:42 ` [PATCH v2 1/3] soundwire: bus: Don't unassign dev_num before unregistering device Charles Keepax
2026-10-03  8:18   ` Vinod Koul
2026-10-05  9:08     ` Charles Keepax
2026-09-25 15:42 ` [PATCH v2 2/3] soundwire: bus: Expose a helper to remove devices from the bus Charles Keepax
2026-09-25 15:42 ` [PATCH v2 3/3] soundwire: intel_auxdevice: Don't disable IRQs before removing children Charles Keepax
2026-09-26 15:55   ` Pierre-Louis Bossart
2026-09-28  8:39     ` Charles Keepax
2026-09-29  8:34       ` Pierre-Louis Bossart
2026-09-29 12:40         ` Charles Keepax
2026-09-29 18:31           ` Pierre-Louis Bossart
2026-10-04 12:29   ` Richard Patel [this message]
2026-10-05 10:32     ` Charles Keepax
2026-10-05 13:11       ` Charles Keepax
2026-10-08 12:41         ` Charles Keepax
2026-10-08 23:11           ` Richard Patel
2026-10-09  9:03             ` Charles Keepax
2026-10-09  9:23               ` Richard Patel
2026-10-09  9:42                 ` Charles Keepax
2026-09-29 18:34 ` [PATCH v2 0/3] Allow SoundWire devices to communicate during remove Pierre-Louis Bossart

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=asJGxhij4OzWNYn9@wii.dev \
    --to=ripatel@wii.dev \
    --cc=ckeepax@opensource.cirrus.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=patches@opensource.cirrus.com \
    --cc=peter.ujfalusi@linux.intel.com \
    --cc=pierre-louis.bossart@linux.dev \
    --cc=vkoul@kernel.org \
    --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 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.