[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpVnWQ++Ld-=KD8VjVOn--uQfkb5Q_DRg1Xw_pZ02mB-NQ@mail.gmail.com>
Date: Mon, 30 Oct 2017 09:40:51 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: David Miller <davem@...emloft.net>
Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>,
John Fastabend <john.fastabend@...il.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Jiri Pirko <jiri@...lanox.com>
Subject: Re: More painful merges...
On Mon, Oct 30, 2017 at 8:58 AM, Cong Wang <xiyou.wangcong@...il.com> wrote:
> On Mon, Oct 30, 2017 at 5:15 AM, David Miller <davem@...emloft.net> wrote:
>>
>> BPF and tc action bug fixes in 'net' caused some extremely
>> painful merges with 'net-next'.
>>
>> Could the interested parties please take a look at 'net-next'
>> and send me any necessary fixes, as I did the best that I
>> could.
>>
>
> The tcf_block_put_ext() part looks good to me. I will run
> some tests to make sure.
>
Hmm, there is some bug in tcf_unbind_filter() after this
merge, but that is not your fault. In net-next, we use
tp->chain after it is freed:
static inline void
tcf_unbind_filter(struct tcf_proto *tp, struct tcf_result *r)
{
+ struct Qdisc *q = tp->chain->block->q;
unsigned long cl;
+ if (!q)
+ return;
if ((cl = __cls_set_class(&r->class, 0)) != 0)
- tp->q->ops->cl_ops->unbind_tcf(tp->q, cl);
+ q->ops->cl_ops->unbind_tcf(q, cl);
}
I will provide a fix.
Just FYI.
Powered by blists - more mailing lists