At 2017-08-10 05:00:19, "Cong Wang" wrote:
>On Wed, Aug 9, 2017 at 12:17 AM, Gao Feng wrote:
>> Hi Cong,
>>
>> Actually I have one question about the SOCK_RCU_FREE.
>> I don't think it could resolve the issue you raised even though it exists
>> really.
>>
>> I checked the SOCK_RCU_FREE, it just
At 2017-08-10 02:18:44, "Cong Wang" wrote:
>On Tue, Aug 8, 2017 at 10:13 PM, Gao Feng wrote:
>> Maybe I didn't show my explanation clearly.
>> I think it won't happen as I mentioned in the last email.
>> Because the pptp_release invokes the synchronize_rcu to make sure it, and
>> actually there
On Wed, Aug 9, 2017 at 12:17 AM, Gao Feng wrote:
> Hi Cong,
>
> Actually I have one question about the SOCK_RCU_FREE.
> I don't think it could resolve the issue you raised even though it exists
> really.
>
> I checked the SOCK_RCU_FREE, it just defer the __sk_destruct after one rcu
> period.
> B
On Tue, Aug 8, 2017 at 10:13 PM, Gao Feng wrote:
> Maybe I didn't show my explanation clearly.
> I think it won't happen as I mentioned in the last email.
> Because the pptp_release invokes the synchronize_rcu to make sure it, and
> actually there is no one which would invoke del_chan except pptp
At 2017-08-09 13:13:53, "Gao Feng" wrote:
>At 2017-08-09 03:45:53, "Cong Wang" wrote:
>>On Mon, Aug 7, 2017 at 6:10 PM, Gao Feng wrote:
>>>
>>> Sorry, I don't get you clearly. Why the sock_hold() isn't helpful?
>>
>>I already told you, the dereference happends before sock_hold().
>>
>>so
At 2017-08-09 03:45:53, "Cong Wang" wrote:
>On Mon, Aug 7, 2017 at 6:10 PM, Gao Feng wrote:
>>
>> Sorry, I don't get you clearly. Why the sock_hold() isn't helpful?
>
>I already told you, the dereference happends before sock_hold().
>
>sock = rcu_dereference(callid_sock[call_id]);
>
On Mon, Aug 7, 2017 at 6:10 PM, Gao Feng wrote:
>
> Sorry, I don't get you clearly. Why the sock_hold() isn't helpful?
I already told you, the dereference happends before sock_hold().
sock = rcu_dereference(callid_sock[call_id]);
if (sock) {
opt = &sock->proto.ppt
At 2017-08-08 01:17:02, "Cong Wang" wrote:
>On Sun, Aug 6, 2017 at 6:32 PM, Gao Feng wrote:
>> I think the RCU should be supposed to avoid the race between del_chan and
>> lookup_chan.
>
>More precisely, it is callid_sock which is protected by RCU.
>
>Unless I miss any other code path, pptp_exit
On Mon, Aug 7, 2017 at 10:17 AM, Cong Wang wrote:
> Unless I miss any other code path, pptp_exit_module() is
> problematic too, I don't think it can just vfree() the whole thing.
>
This path should be fine, because:
1. sock holds a refcnt to module via proto->owner
2. gre_del_protocol() already
On Sun, Aug 6, 2017 at 6:32 PM, Gao Feng wrote:
> I think the RCU should be supposed to avoid the race between del_chan and
> lookup_chan.
More precisely, it is callid_sock which is protected by RCU.
Unless I miss any other code path, pptp_exit_module() is
problematic too, I don't think it can
At 2017-08-03 01:13:36, "Cong Wang" wrote:
>Hi, Gao
>
>On Tue, Aug 1, 2017 at 1:39 PM, Cong Wang wrote:
>> From my understanding, this RCU is supposed to protect the pppox_sock
>> pointers in 'callid_sock' which could be NULL'ed in del_chan(). And the
>> pppox_sock is freed when the last refcnt i
Hi, Gao
On Tue, Aug 1, 2017 at 1:39 PM, Cong Wang wrote:
> From my understanding, this RCU is supposed to protect the pppox_sock
> pointers in 'callid_sock' which could be NULL'ed in del_chan(). And the
> pppox_sock is freed when the last refcnt is gone, that is, when sock
> dctor is called. pptp
On Mon, Jul 31, 2017 at 3:07 AM, wrote:
> From: Gao Feng
>
> The PPTP set the pptp_sock_destruct as the sock's sk_destruct, it would
> trigger this bug when __sk_free is invoked in atomic context, because of
> the call path pptp_sock_destruct->del_chan->synchronize_rcu.
>
> Now move the synchron
From: gfree.w...@vip.163.com
Date: Mon, 31 Jul 2017 18:07:38 +0800
> From: Gao Feng
>
> The PPTP set the pptp_sock_destruct as the sock's sk_destruct, it would
> trigger this bug when __sk_free is invoked in atomic context, because of
> the call path pptp_sock_destruct->del_chan->synchronize_rcu
From: Gao Feng
The PPTP set the pptp_sock_destruct as the sock's sk_destruct, it would
trigger this bug when __sk_free is invoked in atomic context, because of
the call path pptp_sock_destruct->del_chan->synchronize_rcu.
Now move the synchronize_rcu to pptp_release from del_chan. This is the
onl
15 matches
Mail list logo
