Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2137157yba; Sat, 27 Apr 2019 15:34:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqwOi0pbnZuUOWBzQ4RcsVd+EgleMCw+32p0Qu+8cCjgboXkYGesxbTQ2Npq5HHViJMCea0A X-Received: by 2002:a65:6201:: with SMTP id d1mr15830217pgv.28.1556404492514; Sat, 27 Apr 2019 15:34:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556404492; cv=none; d=google.com; s=arc-20160816; b=RJ6pp2CZNnm6qfetyGNW+U/iSxTaA7FX2CNjwDZPRUpvgpSYmYYGgDH0i9805TwagG bso51VLCEzqci7tf8GKWpijog39ksNU06sRLXkJyAjEp1DZWPzHcG5XZtQqEoY7cHKA4 VIA5xJaPIFb1mo/qiVGDOYzs+HoWGcatcRluCTKLVJS5x5Op0d4LfIEER+z0eDfZU9nP 4m8FftPeQLRA+hPemVyWzBMhJZ21d365DhubAGbCddbFn0R+a7E8iXl4H2bpriaFYUj3 FcxPVk2q0f+Rj8jK/R8GKe7IAQmA5ZqRFRSS07JbJwZaUBpHbf76nln21YxKvdSEpkq6 TxrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=vZ1HP560MbmsZPlM4yQYshAljpS1RAkicat/98U75Sk=; b=wz5OVG9e8xU2+hQNQ4VjEXmZTe4Qjjoq6W7aoDoKFhGFqwCoN2HnbhUrQ9lYp36W2/ UO+qa3l/gDecUx+24I+5Ilqy3Np/qYSiJY6rku9C/Ba+/uDom7Tj6TUkcyoGluUmEedd exdRRUbfh5BuB5fp+UctfK5yY7cg/5myga5UwkifjUy39XUEwZeRpOJA17J+WYhkyBVC Vyapc/uITF+DoZXDayemjulGILuXPIBcUyuT2idcYhtnFIhsgo+AmIRJEKPuKyNJW8r5 iV4qEtFswcutvnHhSzdcrrKWVOJ2QHrtwo7/fgi2G8e2iGs2DYUI3FMcnrI8ArdyZ7Jr Xeyg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c68si15643278pfa.56.2019.04.27.15.34.35; Sat, 27 Apr 2019 15:34:52 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726173AbfD0Wdl (ORCPT + 99 others); Sat, 27 Apr 2019 18:33:41 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:57312 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726049AbfD0Wdl (ORCPT ); Sat, 27 Apr 2019 18:33:41 -0400 Received: from fsav305.sakura.ne.jp (fsav305.sakura.ne.jp [153.120.85.136]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id x3RMX5IO080649; Sun, 28 Apr 2019 07:33:05 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav305.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav305.sakura.ne.jp); Sun, 28 Apr 2019 07:33:05 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav305.sakura.ne.jp) Received: from [192.168.1.8] (softbank126012062002.bbtec.net [126.12.62.2]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id x3RMX0QS080634 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Sun, 28 Apr 2019 07:33:05 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: unregister_netdevice: waiting for DEV to become free (2) To: David Ahern , "David S. Miller" Cc: Julian Anastasov , Cong Wang , syzbot , ddstreet@ieee.org, dvyukov@google.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, syzkaller-bugs@googlegroups.com References: <0000000000007d22100573d66078@google.com> <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> From: Tetsuo Handa Message-ID: <15b353e9-49a2-f08b-dc45-2e9bad3abfe2@i-love.sakura.ne.jp> Date: Sun, 28 Apr 2019 07:33:00 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/04/28 2:16, David Ahern wrote: > On 4/26/19 7:43 AM, Tetsuo Handa wrote: >> This bug is the top crasher for syzbot and thus we want to fix. I need your >> response regarding commit caacf05e5ad1abf0 ("ipv4: Properly purge netdev >> references on uncached routes.") why you chose "a loopback device in that >> namespace". >> >> On 2019/04/16 23:00, Tetsuo Handa wrote: >>> Hello, David S. Miller. >>> >>> I have a question regarding rt_flush_dev() introduced by commit caacf05e5ad1abf0 >>> ("ipv4: Properly purge netdev references on uncached routes.") which went to >>> Linux 3.6-rc1. That commit started replacing "a device to unregister" with >>> "a loopback device in that namespace", but there is no description why that >>> commit chose "a loopback device in that namespace". If a device to unregister >>> is "a loopback device in that namespace" itself, rt_flush_dev() becomes a no-op >>> because dev == net->loopback_dev from the beginning. Apart from a problem that >>> usage count keeps increasing because dev_put(rt->dst.dev) is not called after >>> rt->dst.dev was replaced with a loopback device, replacing "a device to unregister" >>> with "a loopback device in init namespace" (like shown below) avoids this problem. >>> > > Moving resource use to the init namespace is not really solving the core > problem. It would be better to understand what changes are needed to the > shutdown sequence of a namespace to ensure proper cleanup. I know. > > In this case why are dst entries not getting cleaned up? This one is > referring to entries on the uncached list. What is using the dst entry > and why isn't it getting released? > I'm waiting for davem why it is safe to move the dst entry from "a device to unregister" to "a loopback device in that namespace". I'm waiting for an explanation how the dst entry which was moved to "a loopback device in that namespace" is released (i.e. what the expected shutdown sequence is).