On Tue 01 Dec 2020 at 21:24, Jakub Kicinski <k...@kernel.org> wrote:
> On Tue, 1 Dec 2020 20:39:16 +0200 Vlad Buslov wrote:
>> On Tue 01 Dec 2020 at 19:03, Jakub Kicinski <k...@kernel.org> wrote:
>> > On Tue, 1 Dec 2020 09:55:37 +0200 Vlad Buslov wrote:
>> >> On Tue 01 Dec 2020 at 04:52, Jakub Kicinski <k...@kernel.org> wrote:
>> >> > On Fri, 27 Nov 2020 17:12:05 +0200 Vlad Buslov wrote:
>> >> >> @@ -2262,7 +2260,7 @@ static int tc_del_tfilter(struct sk_buff *skb,
>> >> >> struct nlmsghdr *n,
>> >> >>
>> >> >> if (prio == 0) {
>> >> >> tfilter_notify_chain(net, skb, block, q, parent, n,
>> >> >> - chain, RTM_DELTFILTER, rtnl_held);
>> >> >> + chain, RTM_DELTFILTER);
>> >> >> tcf_chain_flush(chain, rtnl_held);
>> >> >> err = 0;
>> >> >> goto errout;
>> >> >
>> >> > Hum. This looks off.
>> >>
>> >> Hi Jakub,
>> >>
>> >> Prio==0 means user requests to flush whole chain. In such case rtnl lock
>> >> is obtained earlier in tc_del_tfilter():
>> >>
>> >> /* Take rtnl mutex if flushing whole chain, block is shared (no qdisc
>> >> * found), qdisc is not unlocked, classifier type is not specified,
>> >> * classifier is not unlocked.
>> >> */
>> >> if (!prio ||
>> >> (q && !(q->ops->cl_ops->flags & QDISC_CLASS_OPS_DOIT_UNLOCKED)) ||
>> >> !tcf_proto_is_unlocked(name)) {
>> >> rtnl_held = true;
>> >> rtnl_lock();
>> >> }
>> >>
>> >
>> > Makes sense, although seems a little fragile. Why not put a true in
>> > there, in that case?
>>
>> Because, as I described in commit message, the function will trigger an
>> assertion if called without rtnl lock, so passing rtnl_held==false
>> argument makes no sense and is confusing for the reader.
>
> The assumption being that tcf_ functions without the arg must hold the
> lock?
Yes.
>
>> > Do you have a larger plan here? The motivation seems a little unclear
>> > if I'm completely honest. Are you dropping the rtnl_held from all callers
>> > of __tcf_get_next_proto() just to save the extra argument / typing?
>>
>> The plan is to have 'rtnl_held' arg for functions that can be called
>> without rtnl lock and not have such argument for functions that require
>> caller to hold rtnl :)
>>
>> To elaborate further regarding motivation for this patch: some time ago
>> I received an email asking why I have rtnl_held arg in function that has
>> ASSERT_RTNL() in one of its dependencies. I re-read the code and
>> determined that it was a leftover from earlier version and is not needed
>> in code that was eventually upstreamed. Removing the argument was an
>> easy decision since Jiri hates those and repeatedly asked me to minimize
>> usage of such function arguments, so I didn't expect it to be
>> controversial.
>>
>> > That's nice but there's also value in the API being consistent.
>>
>> Cls_api has multiple functions that don't have 'rtnl_held' argument.
>> Only functions that can work without rtnl lock have it. Why do you
>> suggest it is inconsistent to remove it here?
>
> I see. I was just trying to figure out if you have a plan for larger
> restructuring to improve the situation. I also dislike to arguments
> being passed around in a seemingly random fashion. Removing or adding
> them to a single function does not move the needle much, IMO.
No, this is not part of larger effort. I would like to stop passing
'rtnl_held' everywhere, but for that I need other drivers that implement
TC offload to stop requiring rtnl lock, which would allow removing
rtnl_held from tcf_proto_ops callbacks.
>
> But since the patch is correct I'll apply it now, thanks!
Thank you!
