[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <256f533f019b6392b41701707eb7aa056b2f16c0.camel@redhat.com>
Date: Tue, 06 Dec 2022 13:31:53 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Horatiu Vultur <horatiu.vultur@...rochip.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
Steen.Hegelund@...rochip.com, lars.povlsen@...rochip.com,
daniel.machon@...rochip.com, richardcochran@...il.com,
UNGLinuxDriver@...rochip.com, olteanv@...il.com
Subject: Re: [PATCH net-next v3 1/4] net: microchip: vcap: Add vcap_get_rule
Hello,
On Sat, 2022-12-03 at 11:43 +0100, Horatiu Vultur wrote:
> @@ -632,32 +264,22 @@ static int vcap_show_admin(struct vcap_control *vctrl,
> struct vcap_admin *admin,
> struct vcap_output_print *out)
> {
> - struct vcap_rule_internal *elem, *ri;
> + struct vcap_rule_internal *elem;
> + struct vcap_rule *vrule;
> int ret = 0;
>
> vcap_show_admin_info(vctrl, admin, out);
> - mutex_lock(&admin->lock);
> list_for_each_entry(elem, &admin->rules, list) {
Not strictly related to this patch, as the patter is AFAICS already
there in other places, but I'd like to understand the admin->rules
locking schema.
It looks like addition/removal are protected by admin->lock, but
traversal is usually lockless, which in turn looks buggy ?!?
Note: as this patch does not introduce the mentioned behavior, I'm not
going to block the series for the above.
Thanks,
Paolo
> - ri = vcap_dup_rule(elem);
> - if (IS_ERR(ri)) {
> - ret = PTR_ERR(ri);
> - goto err_unlock;
> + vrule = vcap_get_rule(vctrl, elem->data.id);
> + if (IS_ERR_OR_NULL(vrule)) {
> + ret = PTR_ERR(vrule);
> + break;
> }
> - /* Read data from VCAP */
> - ret = vcap_read_rule(ri);
> - if (ret)
> - goto err_free_rule;
> +
> out->prf(out->dst, "\n");
> - vcap_show_admin_rule(vctrl, admin, out, ri);
> - vcap_free_rule((struct vcap_rule *)ri);
> + vcap_show_admin_rule(vctrl, admin, out, to_intrule(vrule));
> + vcap_free_rule(vrule);
> }
> - mutex_unlock(&admin->lock);
> - return 0;
> -
> -err_free_rule:
> - vcap_free_rule((struct vcap_rule *)ri);
> -err_unlock:
> - mutex_unlock(&admin->lock);
> return ret;
> }
Powered by blists - more mailing lists