[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpVTtqQRg7KgQbMQSxxVJRB8a46DGgfU52m=SxF1uYDFWQ@mail.gmail.com>
Date: Tue, 22 Nov 2016 11:28:37 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Daniel Borkmann <daniel@...earbox.net>,
Roi Dayan <roid@...lanox.com>,
"David S. Miller" <davem@...emloft.net>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
Jiri Pirko <jiri@...lanox.com>,
Or Gerlitz <ogerlitz@...lanox.com>,
Cong Wang <cwang@...pensource.com>,
John Fastabend <john.fastabend@...il.com>
Subject: Re: [PATCH net-next] net/sched: cls_flower: verify root pointer
before dereferncing it
On Tue, Nov 22, 2016 at 8:11 AM, Jiri Pirko <jiri@...nulli.us> wrote:
> Tue, Nov 22, 2016 at 05:04:11PM CET, daniel@...earbox.net wrote:
>>Hmm, I don't think we want to have such an additional test in fast
>>path for each and every classifier. Can we think of ways to avoid that?
>>
>>My question is, since we unlink individual instances from such tp-internal
>>lists through RCU and release the instance through call_rcu() as well as
>>the head (tp->root) via kfree_rcu() eventually, against what are we protecting
>>setting RCU_INIT_POINTER(tp->root, NULL) in ->destroy() callback? Something
>>not respecting grace period?
>
> If you call tp->ops->destroy in call_rcu, you don't have to set tp->root
> to null.
We do need to respect the grace period if we touch the globally visible
data structure tp in tcf_destroy(). Therefore Roi's patch is not fixing the
right place.
Also I don't know why you blame my commit, this problem should already
exist prior to my commit, probably date back to John's RCU patches.
I am working on a patch.
Powered by blists - more mailing lists