On Wed, Aug 9, 2017 at 12:17 AM, Gao Feng <gfree.w...@vip.163.com> 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.
> But when it performs, someone still could find this sock by callid during the 
> del_chan period and it may still deference the sock which may freed soon.
> The right flow should be following.
> del_chan()
> wait a rcu period
> sock_put() ------------ It is safe that someone gets the sock because it 
> already hold sock refcnt.
> When using SOCK_RCU_FREE, its flow would be following.
> wait a rcu period
> del_chan()
> free the sock directly -------- no sock refcnt check again.
> Because the del_chan happens after rcu wait, not before, so it isn't helpful 

Yes, good point! With SOCK_RCU_FREE the sock_hold() should
not be needed. For RCU, unpublish should indeed happen before
grace period.

> I don't know if I misunderstand the SOCK_RCU_FREE usage.
> But it is a good news that the del_chan is only invoked in pptp_release 
> actually and it would wait a rcu period before sock_put.

Looking at the code again, the reader lookup_chan() is actually
invoked in BH context, but neither add_chan() nor del_chan()
actually disables BH...

Reply via email to