On 2019/5/9 下午1:34, Cong Wang wrote:
On Tue, May 7, 2019 at 7:54 PM Jason Wang <jasow...@redhat.com> wrote:
This is only true if you can make sure tfile[tun->numqueues] is not
freed. Either my patch or SOCK_RCU_FREE can solve this, but for
SOCK_RCU_FREE we need do extra careful audit to make sure it doesn't
break someting. So synchronize through pointers in tfiles[] which is
already protected by RCU is much more easier. It can make sure no
dereference from xmit path after synchornize_net(). And this matches the
assumptions of the codes after synchronize_net().
It is hard to tell which sock_put() matches with this synchronize_net()
given the call path is complicated.
With SOCK_RCU_FREE, no such a problem, all sock_put() will be safe.
So to me SOCK_RCU_FREE is much easier to understand and audit.
The problem is not tfile itself but the data structure associated. As I
mentioned earlier, the xdp_rxq_info_unreg() looks racy if tun_net_xmit()
can read stale value of numqueues. It's just one example, we may meet
similar issues in the future when adding more features.
Thanks
Thanks.
