On Tue, Jun 06, 2023 at 11:24:37AM +0300, Dan Carpenter wrote:
> This error path needs call mutex_unlock(&ocelot->tas_lock) before
> returning.
>
> Fixes: 2d800bc500fb ("net/sched: taprio: replace tc_taprio_qopt_offload :: enable with a "cmd" enum")
> Signed-off-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
> ---
Thanks. I had a slightly different patch which only locked the mutex in
the first place if the taprio->cmd was known at all (there's nothing to
serialize otherwise), but I didn't send it in time to resolve the issue,
so yours will have to do as well.
Reviewed-by: Vladimir Oltean <vladimir.oltean@xxxxxxx>
> drivers/net/dsa/ocelot/felix_vsc9959.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/ocelot/felix_vsc9959.c b/drivers/net/dsa/ocelot/felix_vsc9959.c
> index 5de6a27052fc..903532ea9fa4 100644
> --- a/drivers/net/dsa/ocelot/felix_vsc9959.c
> +++ b/drivers/net/dsa/ocelot/felix_vsc9959.c
> @@ -1424,7 +1424,8 @@ static int vsc9959_qos_port_tas_set(struct ocelot *ocelot, int port,
> mutex_unlock(&ocelot->tas_lock);
> return 0;
> } else if (taprio->cmd != TAPRIO_CMD_REPLACE) {
> - return -EOPNOTSUPP;
> + ret = -EOPNOTSUPP;
> + goto err_unlock;
> }
>
> ret = ocelot_port_mqprio(ocelot, port, &taprio->mqprio);
> --
> 2.39.2
>
