[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPwn2JR8MUauO44qAeb3tw93PuQHEbO_8Tocs-ZW8Y9ZK+Ln8A@mail.gmail.com>
Date: Fri, 9 Jun 2017 17:06:53 +0800
From: Hangbin Liu <liuhangbin@...il.com>
To: Xin Long <lucien.xin@...il.com>
Cc: Steffen Klassert <steffen.klassert@...unet.com>,
David Miller <davem@...emloft.net>,
network dev <netdev@...r.kernel.org>
Subject: Re: [PATCH net] net/flow: fix fc->percpu NULL pointer dereference
2017-06-09 16:43 GMT+08:00 Xin Long <lucien.xin@...il.com>:
> On Fri, Jun 9, 2017 at 4:32 PM, Steffen Klassert
> <steffen.klassert@...unet.com> wrote:
>> On Fri, Jun 09, 2017 at 04:23:01PM +0800, Hangbin Liu wrote:
>>> Hi Steffen,
>>>
>>> BTW, If we put the check in xfrm_policy_flush(), we can prevent it earlier.
>>> But If we put the check in flow_cache_percpu_empty(), we can prevent
>>> other functions set fc->percpu to NULL, although not much possible : )
>>>
>>> So I'm not quite sure whether we should put the check in
>>> flow_cache_percpu_empty() or in xfrm_policy_flush().
>>
>> Can't we just call xfrm_policy_fini() first and then flow_cache_fini()?
Yes, that would be easy fix. I have been thinking about that. But if we change
the order in xfrm_net_exit(), do we also need to change the order in
xfrm_net_init()? That would change a lot.
If no need, that would be good.
>>
> That would be a better fix. seems safe as what flow_cache_fini does
> is only to free fcp->hash_table and stop timer, I didn't see it has
> any dependence on xfrm_policy stuff.
I'm not familiar about this part. So not sure about the influence if we free
the flow cache after xfrm_policy_fini(). I need do some test first.
I would also be appreciate if you or some one could make sure if it doesn't
influence anything.
Thanks
Hangbin
Powered by blists - more mailing lists