[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMDZJNU5Cpkcrn5sy=7u_vTGcdMjDfCqzSCJ0WLk-3M5RROh=Q@mail.gmail.com>
Date: Tue, 11 Aug 2020 11:26:24 +0800
From: Tonghao Zhang <xiangxia.m.yue@...il.com>
To: Cong Wang <xiyou.wangcong@...il.com>
Cc: "Paul E . McKenney" <paulmck@...nel.org>,
Joel Fernandes <joel@...lfernandes.org>,
Johan Knöös <jknoos@...gle.com>,
Gregory Rose <gvrose8192@...il.com>,
bugs <bugs@...nvswitch.org>, Netdev <netdev@...r.kernel.org>,
"Uladzislau Rezki (Sony)" <urezki@...il.com>,
rcu <rcu@...r.kernel.org>
Subject: Re: [ovs-discuss] Double free in recent kernels after memleak fix
On Tue, Aug 11, 2020 at 10:24 AM Cong Wang <xiyou.wangcong@...il.com> wrote:
>
> On Mon, Aug 10, 2020 at 6:16 PM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote:
> > Hi all, I send a patch to fix this. The rcu warnings disappear. I
> > don't reproduce the double free issue.
> > But I guess this patch may address this issue.
> >
> > http://patchwork.ozlabs.org/project/netdev/patch/20200811011001.75690-1-xiangxia.m.yue@gmail.com/
>
> I don't see how your patch address the double-free, as we still
> free mask array twice after your patch: once in tbl_mask_array_realloc()
> and once in ovs_flow_tbl_destroy().
Hi Cong.
Before my patch, we use the ovsl_dereference
(rcu_dereference_protected) in the rcu callback.
ovs_flow_tbl_destroy
->table_instance_destroy
->table_instance_flow_free
->flow_mask_remove
ASSERT_OVSL(will print warning)
->tbl_mask_array_del_mask
ovsl_dereference(rcu usage warning)
so we should invoke the table_instance_destroy or others under
ovs_lock to avoid (ASSERT_OVSL and rcu usage warning).
with this patch, we reallocate the mask_array under ovs_lock, and free
it in the rcu callback. Without it, we reallocate and free it in the
rcu callback.
I think we may fix it with this patch.
> Have you tried my patch which is supposed to address this double-free?
I don't reproduce it. but your patch does not avoid ruc usage warning
and ASSERT_OVSL.
> It simply skips the reallocation as it makes no sense to trigger reallocation
> when destroying it.
>
> Thanks.
--
Best regards, Tonghao
Powered by blists - more mailing lists