[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1455116983.19473.6.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Wed, 10 Feb 2016 07:09:43 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: Maninder Singh <maninder1.s@...sung.com>
Cc: davem@...emloft.net, willemb@...gle.com, daniel@...earbox.net,
edumazet@...gle.com, al.drozdov@...il.com, eyal.birger@...il.com,
tklauser@...tanz.ch, fruggeri@...stanetworks.com,
dwmw2@...radead.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, ajeet.y@...sung.com,
pankaj.m@...sung.com, gh007.kim@...sung.com,
hakbong5.lee@...sung.com, akhilesh.k@...sung.com,
Vaneet Narang <v.narang@...sung.com>,
Amit Nagal <amit.nagal@...sung.com>
Subject: Re: [PATCH 1/1] af_packet: Raw socket destruction warning fix
On Wed, 2016-02-10 at 17:35 +0530, Maninder Singh wrote:
> This Patch fixes below warning:-
> WARNING: at net/packet/af_packet.c:xxx packet_sock_destruct
>
> There is following race between packet_rcv and packet_close
> which keeps unfree packet in receive queue.
>
> CPU 1 CPU2
> packet_rcv
>
> packet_close
> skb_set_owner_r(skb, sk);
>
> skb_queue_purge(&sk->sk_receive_queue);
>
> spin_lock(&sk->sk_receive_queue.lock);
> __skb_queue_tail(&sk->sk_receive_queue, skb);
> spin_unlock(&sk->sk_receive_queue.lock);
This absolutely can not happen.
CPU 1 holds rcu read lock, so cpu 2 can not possibly call
skb_queue_purge()
(cpu 1 is blocked in synchronize_net(), waiting that all cpus are no
longer in packet_rcv())
This patch does not address the root cause of your problem, and only
slightly changes probability for the bug to trigger.
Powered by blists - more mailing lists