The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Lee Jones <lee@kernel.org>
To: Hongyan Xu <getshell@seu.edu.cn>
Cc: Support Opensource <support.opensource@diasemi.com>,
	linux-kernel@vger.kernel.org, jianhao.xu@seu.edu.cn
Subject: Re: [PATCH] mfd: da903x: cancel IRQ work during teardown
Date: Thu, 6 Aug 2026 15:16:12 +0100	[thread overview]
Message-ID: <20260806141612.GK2869284@google.com> (raw)
In-Reply-To: <20260728065557.1517-1-getshell@seu.edu.cn>

/* Sashiko Automation: Issues Found (2 Findings) */

Please review, explain or fix the Sashiko review(s).

If this is a set, this request includes the other patches too.

On Tue, 28 Jul 2026, Hongyan Xu wrote:

> The IRQ handler disables the IRQ and schedules irq_work. Releasing the
> IRQ does not drain that work, which can continue to use the devm-allocated
> chip and notifier state.
> 
> Add a devm action after requesting the IRQ. The action disables the IRQ
> and cancels the work before automatic IRQ release. Run the same action
> before removing child devices on normal detach.
> 
> This issue was found by a static analysis tool.
> 
> Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
> ---
>  drivers/mfd/da903x.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/mfd/da903x.c b/drivers/mfd/da903x.c
> index e86b39d..fdff445 100644
> --- a/drivers/mfd/da903x.c
> +++ b/drivers/mfd/da903x.c
> @@ -421,6 +421,14 @@ static irqreturn_t da903x_irq_handler(int irq, void *data)
>  	return IRQ_HANDLED;
>  }
>  
> +static void da903x_cancel_irq_work(void *data)
> +{
> +	struct da903x_chip *chip = data;
> +
> +	disable_irq(chip->client->irq);
> +	cancel_work_sync(&chip->irq_work);
> +}
> +
>  static const struct da903x_chip_ops da903x_ops[] = {
>  	[0] = {
>  		.init_chip	= da9030_init_chip,
> @@ -529,6 +537,11 @@ static int da903x_probe(struct i2c_client *client)
>  		return ret;
>  	}
>  
> +	ret = devm_add_action_or_reset(&client->dev, da903x_cancel_irq_work,
> +				       chip);
> +	if (ret)
> +		return ret;
> +
>  	return da903x_add_subdevs(chip, pdata);
>  }

[Severity: High]
If da903x_add_subdevs() fails, it cleans up the subdevices internally
before returning an error, leaving a window where the IRQ and workqueue
are still active.

da903x_add_subdevs() handles errors like this:
    
failed:
        da903x_remove_subdevs(chip);
        return ret;

When the error is returned to da903x_probe(), the devres unwinding will
eventually cancel the IRQ work, but the subdevices have already been
removed.

Since the teardown logic in da903x_remove() explicitly cancels the IRQ
work before removing subdevices, is there a similar race condition
during a probe failure?


>  
> @@ -536,6 +549,7 @@ static void da903x_remove(struct i2c_client *client)
>  {
>  	struct da903x_chip *chip = i2c_get_clientdata(client);
>  
> +	devm_release_action(&client->dev, da903x_cancel_irq_work, chip);
>  	da903x_remove_subdevs(chip);
>  }
>  
> -- 
> 2.50.1.windows.1

-- 
Lee Jones

  reply	other threads:[~2026-08-06 14:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-28  6:55 [PATCH] mfd: da903x: cancel IRQ work during teardown Hongyan Xu
2026-08-06 14:16 ` Lee Jones [this message]
2026-08-06 15:20 ` [PATCH v2] " Hongyan Xu

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=20260806141612.GK2869284@google.com \
    --to=lee@kernel.org \
    --cc=getshell@seu.edu.cn \
    --cc=jianhao.xu@seu.edu.cn \
    --cc=linux-kernel@vger.kernel.org \
    --cc=support.opensource@diasemi.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