Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: unregister_netdevice: waiting for DEV to become free (2)
To:     Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
        Eric Dumazet <eric.dumazet@gmail.com>,
        "David S. Miller" <davem@davemloft.net>
Cc:     Julian Anastasov <ja@ssi.bg>, Cong Wang <xiyou.wangcong@gmail.com>,
        syzbot <syzbot+30209ea299c09d8785c9@syzkaller.appspotmail.com>,
        ddstreet@ieee.org, dvyukov@google.com,
        linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
        syzkaller-bugs@googlegroups.com
References: <0000000000007d22100573d66078@google.com>
 <alpine.LFD.2.20.1808201527230.2758@ja.home.ssi.bg>
 <4684eef5-ea50-2965-86a0-492b8b1e4f52@I-love.SAKURA.ne.jp>
 <9d430543-33c3-0d9b-dc77-3a179a8e3919@I-love.SAKURA.ne.jp>
 <920ebaf1-ee87-0dbb-6805-660c1cbce3d0@I-love.SAKURA.ne.jp>
 <cc054b5c-4e95-8d30-d4bf-9c85f7e20092@gmail.com>
 <15b353e9-49a2-f08b-dc45-2e9bad3abfe2@i-love.sakura.ne.jp>
 <057735f0-4475-7a7b-815f-034b1095fa6c@gmail.com>
 <6e57bc11-1603-0898-dfd4-0f091901b422@i-love.sakura.ne.jp>
 <f71dd5cd-c040-c8d6-ab4b-df97dea23341@gmail.com>
 <d56b7989-8ac6-36be-0d0b-43251e1a2907@gmail.com>
 <117fcc49-d389-c389-918f-86ccaef82e51@i-love.sakura.ne.jp>
From:   David Ahern <dsahern@gmail.com>
Message-ID: <70be7d61-a6fe-e703-978a-d17f544efb44@gmail.com>
Date:   Wed, 1 May 2019 08:52:37 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <117fcc49-d389-c389-918f-86ccaef82e51@i-love.sakura.ne.jp>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 5/1/19 7:38 AM, Tetsuo Handa wrote:
> On 2019/04/30 3:43, David Ahern wrote:
>>> The attached patch adds a tracepoint to notifier_call_chain. If you have
>>> KALLSYMS enabled it will show the order of the function handlers:
>>>
>>> perf record -e notifier:* -a -g &
>>>
>>> ip netns del <NAME>
>>> <wait a few seconds>
>>>
>>> fg
>>> <ctrl-c on perf-record>
>>>
>>> perf script
>>>
>>
>> with the header file this time.
>>
> 
> What is the intent of your patch? I can see that many notifiers are called. But
> how does this help identify which event is responsible for dropping the refcount?
> 

In a previous response you stated: "Since I'm not a netdev person, I
appreciate if you can explain that shutdown sequence using a flow chart."

The notifier sequence tells you the order of cleanup handlers and what
happens when a namespace is destroyed.

The dev_hold / dev_put tracepoint helps find the refcnt leak but
requires some time analyzing the output to match up hold / put stack traces.