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
