On Sat, Jul 22, 2017 at 8:40 PM, Ding Tianhong <dingtianh...@huawei.com> wrote: > Hi, Cong: > > Thanks for your quirk solution, but I still has some doubts about it, > it looks like fix the problem in the packet_setsockopt->packet_set_ring > processing, > but when in packet_release processing, it may could not release the > real pg_vec for the TPACKET_V3 ring, and then cause the mem leak, > maybe I miss something here, nice to hear from your feedback. :)
Yes you miss that packet_release() has memset()'s so we won't hit that path. :) However, I missed the swap() in this messy function, actually I believe the bug is that we modify tpacket_kbdq_core inside rx_ring in non-closing case without actually stopping its timer. I feel more confident with the following patch: diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index 008bb34ee324..267b181fef15 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -4263,6 +4263,7 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u, case TPACKET_V3: /* Block transmit is not supported yet */ if (!tx_ring) { + prb_shutdown_retire_blk_timer(po, rb_queue); init_prb_bdqc(po, rb, pg_vec, req_u); } else { struct tpacket_req3 *req3 = &req_u->req3;