Re: [PATCH v4 07/15] media: meson-ir-tx: Ensure clock is disabled on unbind

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

Pre-existing issues:
- [High] Memory leak of the rc_dev struct on driver unbind due to mixing unmanaged allocation with managed registration.
- [High] Integer underflow and division by zero when configuring high carrier frequencies.
- [High] Lockless check of completion_done in the IRQ handler exposes a race that can overflow the hardware FIFO.
- [Medium] Error codes from core kernel APIs are hardcoded to -ENODEV, breaking probe deferral.
--

--- Patch [7]: [PATCH v4 07/15] media: meson-ir-tx: Ensure clock is disabled on unbind ---
commit b425f7e336876fa07197476c4560b56dec0eb33d
Author: Sean Young <sean@mess.org>

media: meson-ir-tx: Ensure clock is disabled on unbind
    
clk_prepare_enable() needs a call to clk_disable_unprepare() on
driver unbind. Make it devm managed.

> diff --git a/drivers/media/rc/meson-ir-tx.c b/drivers/media/rc/meson-ir-tx.c
> index fded2c256f2a6..e7bb107e6a843 100644
> --- a/drivers/media/rc/meson-ir-tx.c
> +++ b/drivers/media/rc/meson-ir-tx.c
> @@ -288,8 +288,8 @@ static int meson_irtx_mod_clock_probe(struct meson_irtx *ir,
>  	if (!np)
>  		return -ENODEV;
>  
> -	clock = devm_clk_get(ir->dev, "xtal");
> -	if (IS_ERR(clock) || clk_prepare_enable(clock))
> +	clock = devm_clk_get_enabled(ir->dev, "xtal");
> +	if (IS_ERR(clock))
>  		return -ENODEV;
>  
>  	*clk_nr = IRB_MOD_XTAL3_CLK;

[Severity: Medium]
This isn't a bug introduced by this patch, but returning -ENODEV here prevents
proper probe deferral. If the clock is not yet ready and devm_clk_get_enabled()
returns -EPROBE_DEFER, the initialization will permanently fail instead of
trying again later.

Also in meson_irtx_probe(), the same pattern exists for the IRQ:

drivers/media/rc/meson-ir-tx.c:meson_irtx_probe() {
    ...
	irq = platform_get_irq(pdev, 0);
	if (irq < 0)
		return -ENODEV;
    ...
}

Should these functions return the exact error pointer (e.g. PTR_ERR(clock))
or error code rather than hardcoding -ENODEV?

[Severity: High]
This is a pre-existing issue, but does this code cause an integer underflow
and division by zero when configuring high carrier frequencies?

drivers/media/rc/meson-ir-tx.c:meson_irtx_set_mod() {
    ...
	unsigned int cnt = DIV_ROUND_CLOSEST(ir->clk_rate, ir->carrier);
	unsigned int pulse_cnt = DIV_ROUND_CLOSEST(cnt * ir->duty_cycle, 100);
	unsigned int space_cnt = cnt - pulse_cnt;

	dev_dbg(ir->dev, "F_mod = %uHz, T_mod = %luns, duty_cycle = %u%%\n",
		ir->carrier, NSEC_PER_SEC / ir->clk_rate * cnt,
		100 * pulse_cnt / cnt);
    ...
}

If a user space process provides a carrier frequency greater than twice the
modulator clock rate (ir->clk_rate), cnt will be 0. This results in pulse_cnt
being 0, which triggers a division by zero in the dev_dbg() statement. 

Could this also cause an underflow when writing to the hardware register via
IRB_MOD_COUNT(pulse_cnt, space_cnt)?

[Severity: High]
This is a pre-existing issue, but does the lockless check of completion_done()
in the IRQ handler expose a race condition?

drivers/media/rc/meson-ir-tx.c:meson_irtx_irqhandler() {
    ...
	if (completion_done(&ir->completion))
		return IRQ_HANDLED;

	spin_lock_irqsave(&ir->lock, flags);
	if (ir->buf_head < ir->buf_len)
		meson_irtx_send_buffer(ir);
	else
		complete(&ir->completion);
	spin_unlock_irqrestore(&ir->lock, flags);
    ...
}

If an edge interrupt for the FIFO threshold is delayed, and a new transmission
begins by acquiring the lock and reinitializing the completion, could the
delayed IRQ handler evaluate completion_done() outside the lock, see it as
false, and then blindly write up to 96 more words, overflowing the hardware
FIFO?

[Severity: High]
This is a pre-existing issue, but does this code leak the rc_dev structure on
driver unbind?

drivers/media/rc/meson-ir-tx.c:meson_irtx_probe() {
    ...
	rc = rc_allocate_device(RC_DRIVER_IR_RAW_TX);
	if (!rc)
		return -ENOMEM;
    ...
	ret = devm_rc_register_device(dev, rc);
	if (ret < 0) {
		rc_free_device(rc);
		return dev_err_probe(dev, ret, "rc_dev registration failed\n");
	}
    ...
}

Because rc is allocated with rc_allocate_device() instead of a managed
variant like devm_rc_allocate_device(), when the driver is unbound,
devm_rc_register_device() will automatically unregister the device, but the
memory for the rc_dev structure is never freed since there is no remove
callback.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1785158244.git.sean@mess.org?part=7

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic