Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp313584ybc; Tue, 12 Nov 2019 01:49:08 -0800 (PST) X-Google-Smtp-Source: APXvYqx0BVDgEFEtZngcjncHB9/ZK3+Df38Nzq7pdlqIQlArz9/4o8FdRwMD4R3A0T5HQCR9M/UF X-Received: by 2002:a17:906:70d6:: with SMTP id g22mr25032390ejk.221.1573552148736; Tue, 12 Nov 2019 01:49:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573552148; cv=none; d=google.com; s=arc-20160816; b=AENNxR2bYiR8t5sHfDsTg7BnAmLGaI1V/E8S9oOR2P1KHHhh6a5fMHVxBWTioVQby7 QS12sJ8A5Ky18O3+J/gwlPyhFxJ5yaUW4HPX/RV2aHl95IJM5I5kzJqiHMuErtj/PH3k nwOTH5QvFcCCAtUS+YtCY5rkpAphYWVwyDvQP/fneDYtAihjDw1zWTzZ6TvhgM1JaYGz ze7nxMRLCzVOdxGt0WWeecLQfQFVdhwcb6v5IqJathAAOEwEPCdcqup33JS0RR8MhbFN 1ou19B9WdQrPDToSlKe/Rai8/R5JMGyhRsqLSz3lR3QEsBZjbs+NZHG/YkjUdss3VT9V 4B/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:reply-to:message-id :subject:cc:to:from:date; bh=lsJ30IDK4o4S5iHHnOf61G/dWs948WzJNVysTAPw5bA=; b=sHKgVMlo8RQX0hLk60pMqMFysSdclu0wwYfpPvKQnDgmq8p40NlRr3J/3YZDbT+F0l qifEDhOPAw3vIbwWv6d9GS/CmZuWy8MsY+MxgCtSk9V5Xxvsgzwa365GpEhoOT0nEZKE QRhSGcQZC6A+hObQqg0gxadO45pRIsHotJWBRyhsZTwMUAJdG73JY1nbR2Ehb+ULi8pV yglo+q97GAGtSsyfYO7rQH3frHB123KZAfMvhvti3mVxt2e3ILIA8KXiKNlpM9cioDk8 OCuTqovkZjHVdP8Y8jUUqKrBcTPh3gP+oF02/bLQmoWK1XaclJjzrGE/uZPtDsE+AhDS T8gw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r20si11770945edm.17.2019.11.12.01.48.42; Tue, 12 Nov 2019 01:49:08 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727046AbfKLJsN (ORCPT + 99 others); Tue, 12 Nov 2019 04:48:13 -0500 Received: from out30-130.freemail.mail.aliyun.com ([115.124.30.130]:58690 "EHLO out30-130.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725874AbfKLJsN (ORCPT ); Tue, 12 Nov 2019 04:48:13 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R591e4;CH=green;DM=||false|;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01f04391;MF=tonylu@linux.alibaba.com;NM=1;PH=DS;RN=5;SR=0;TI=SMTPD_---0ThtTQAE_1573552089; Received: from localhost(mailfrom:tonylu@linux.alibaba.com fp:SMTPD_---0ThtTQAE_1573552089) by smtp.aliyun-inc.com(127.0.0.1); Tue, 12 Nov 2019 17:48:10 +0800 Date: Tue, 12 Nov 2019 17:48:09 +0800 From: Tony Lu To: Eric Dumazet Cc: davem@davemloft.net, shemminger@osdl.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net: remove static inline from dev_put/dev_hold Message-ID: <20191112094809.GA981@TonyMac-Alibaba> Reply-To: Tony Lu References: <20191111140502.17541-1-tonylu@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 11, 2019 at 09:21:58AM -0800, Eric Dumazet wrote: > > > On 11/11/19 6:05 AM, Tony Lu wrote: > > This patch removes static inline from dev_put/dev_hold in order to help > > trace the pcpu_refcnt leak of net_device. > > > > We have sufferred this kind of issue for several times during > > manipulating NIC between different net namespaces. It prints this > > log in dmesg: > > > > unregister_netdevice: waiting for eth0 to become free. Usage count = 1 > > > > However, it is hard to find out who called and leaked refcnt in time. It > > only left the crime scene but few evidence. Once leaked, it is not > > safe to fix it up on the running host. We can't trace dev_put/dev_hold > > directly, for the functions are inlined and used wildly amoung modules. > > And this issue is common, there are tens of patches fix net_device > > refcnt leak for various causes. > > > > To trace the refcnt manipulating, this patch removes static inline from > > dev_put/dev_hold. We can use handy tools, such as eBPF with kprobe, to > > find out who holds but forgets to put refcnt. This will not be called > > frequently, so the overhead is limited. > > > > This looks as a first step. Yes, I used to want to give a flexible approach for people, and they could choose tools what they want. And I already made a patch, putting a pair tracepoints into dev_put()/dev_hold() to trace that. I will send it out later. > > But I would rather get a full set of scripts/debugging features, > instead of something that most people can not use right now. > > Please share the whole thing. Thanks. Tony Lu