| Message ID | 20250609-must_check-devm_mutex_init-v6-1-9540d5df9704@weissschuh.net |
|---|---|
| State | New |
| Headers | show |
| Series | [v6,1/3] spi: spi-nxp-fspi: check return value of devm_mutex_init() | expand |
On Tue, Jun 10, 2025 at 12:57:37PM +0300, Andy Shevchenko wrote: > On Mon, Jun 09, 2025 at 09:59:46PM +0100, Mark Brown wrote: > > I don't understand the comment about leaking here? We might end up with > > an unitialised mutex but how would we leak anything? > In case if the mutex_init() allocates something that needs to be freed > (in the future). I don't see how checking the return value impacts that? The management via devm is still there either way.
diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c index e63c77e418231cd0698ffb73eeeebfbe63cc3065..f3d5765054132cd18b7257439ece971f58e9ceb2 100644 --- a/drivers/spi/spi-nxp-fspi.c +++ b/drivers/spi/spi-nxp-fspi.c @@ -1273,7 +1273,9 @@ static int nxp_fspi_probe(struct platform_device *pdev) if (ret) return dev_err_probe(dev, ret, "Failed to request irq\n"); - devm_mutex_init(dev, &f->lock); + ret = devm_mutex_init(dev, &f->lock); + if (ret) + return dev_err_probe(dev, ret, "Failed to initialize lock\n"); ctlr->bus_num = -1; ctlr->num_chipselect = NXP_FSPI_MAX_CHIPSELECT;
Even if it's not critical, the avoidance of checking the error code from devm_mutex_init() call today diminishes the point of using devm variant of it. Tomorrow it may even leak something. Add the missed check. Fixes: 48900813abd2 ("spi: spi-nxp-fspi: remove the goto in probe") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> --- drivers/spi/spi-nxp-fspi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)