From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D9993448BAA for ; Thu, 6 Aug 2026 14:16:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786025777; cv=none; b=ul+/RgJfCltY0h2FdJcxEzTBOAze3DwTP0H5UPGxSgpZ309/+cH+SnTCIvG0oIOPSTMVHkkA47R41WhFTz9sDszQy+GNvhV8gKITfuXdXQQjYUXltR8JpUbd7QacC9SvJp/CkZ/cSGHmgoW7zsJZ+aET0sIZ8s5Ncp3grueaWDA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786025777; c=relaxed/simple; bh=iHJ8wX6Kec+L9CzUT2PGGm2Wyaq75u52/9JwGVIdjb0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FUcTVS5ujy1NkZnlsF1VzYaKQSu884Uk7aT5jtJVfmArpAQ1ygOAkGZ3Syv9T1RE8xm4+WMuRdjMHO0k9dOYXAns702iqd1YYjcDl8JyQ4RaTf6FRcBNPKyIUSJ/Zapvkv0c8d5UDfZ+7uJ4Z2yVWkvlx3R9Io05QYZ28fmfYso= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KoXg2cHF; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KoXg2cHF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80A0B1F00A3A; Thu, 6 Aug 2026 14:16:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786025775; bh=ydBuaLGE1QmvqRm0SO3ndMOWUkTULoPSrf1l4UodDgw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=KoXg2cHFWUIp81EGL/bBAf0g9MriQms498PO2j4tFMTLKO2DNUt5yl8GAzmcH9gAK bdFigAa3cLhd+EAmk43ApzlrK1TSYTxDw1s0VnVBFaHX0Irarfw7DH6/jckUxXf+zW w6ZN78jQXFImUAomEv6iwEFGSbiPN2Q9mjWqh8dySuoB54pBDPe7wae0bTHWvNU4mb v3DUPj9cLGCp/Av1H6ORLENvpxGJK822S6on4v/Ogd8X1ChFICk60Y0jG0yXe5sxQw UiNfL8Z9YOMd5ietVxxMRrgUUlhVhwHvoXC+jfTAfhKNDgcvwwK5nf4LV8ySB7VOlR NrIn4tcoNvrHg== Date: Thu, 6 Aug 2026 15:16:12 +0100 From: Lee Jones To: Hongyan Xu Cc: Support Opensource , linux-kernel@vger.kernel.org, jianhao.xu@seu.edu.cn Subject: Re: [PATCH] mfd: da903x: cancel IRQ work during teardown Message-ID: <20260806141612.GK2869284@google.com> References: <20260728065557.1517-1-getshell@seu.edu.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 > --- > 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