Received: by 10.213.65.68 with SMTP id h4csp507683imn; Sat, 17 Mar 2018 12:20:26 -0700 (PDT) X-Google-Smtp-Source: AG47ELulj7A1fBDgm0322L6c4ysniCjOazQYnr+QHv5G4/a7Ld8kM/y6CzsB43rLoCxe7SRydIMP X-Received: by 10.98.96.133 with SMTP id u127mr5556033pfb.48.1521314426556; Sat, 17 Mar 2018 12:20:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521314426; cv=none; d=google.com; s=arc-20160816; b=HCKQhdHcWO9TKZXylSfOTb1RzqU/4tAlCaJuN2LoaJKqggb+RSY/Hh54TpKQJ3ozEO BNunE/Ax1Jxc9IYSg7SNxW2Xd/Kdp8Av44mzQ6VyM4Bn6oGojGpLpDKgrGN+ZQPX8ERW 0eoy4ow2EWj1piQi4fxHuWns+2sDcn1WW8dSib17NdBHtSjBVSHGvEUaGJpLa3ssx9D1 UPX0rEHwB+64jOp79ftRQdu8EABg//z5WkRHcCCwelyNpLTlQCfCuPyo1ZQFWWRN0ty+ SZxAkqoAgFB02xjuQncbMLJOHNLgKxshOE2xvkxf37JyGbOFjPwJfDCAoKJZZrpE8T4/ SvFQ== 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:to:subject:dkim-signature :arc-authentication-results; bh=cx1qZ2wFByECgrIHjhile2DryhmnQx+TCS5gVEdTaCA=; b=A774PhkGBOA8dppeAxCSKPM3Mat9pTQ1uSnfLGuXf125ztGzb6XtNiE73ViOFfmAy9 1dYXDylHHAgkKkfDY/m/qqQyn/0l78TIAYrbcFCrKGLt7aFgFdmkYXNBpdgp509YiYZz hoXf/1X2C0XQEraboigRfMy3lsH1NVsXU6pouo7A9Dod1307weSJnwB4Q5LQAJtraSdX dZsHnTBcU19PY4iR+jiRv8nC+2Hdu5LOi6GFfVQHvnNVstfYw2hyoS/eJwsed/k37xOQ xnYuv5tM8oBjkTLjat5Phy5tO/Y4CQpCzS4NqDPqFji/80eyMZRktKKukyXTVfc2D7ne 8zYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=dJ6tL1oE; 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 61-v6si8629527plf.640.2018.03.17.12.20.12; Sat, 17 Mar 2018 12:20:26 -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; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=dJ6tL1oE; 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 S1753855AbeCQTR6 (ORCPT + 99 others); Sat, 17 Mar 2018 15:17:58 -0400 Received: from merlin.infradead.org ([205.233.59.134]:36868 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753439AbeCQTR5 (ORCPT ); Sat, 17 Mar 2018 15:17:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cx1qZ2wFByECgrIHjhile2DryhmnQx+TCS5gVEdTaCA=; b=dJ6tL1oEhefQahEhJwnYlUfmQm 6OGEzkOenjrsHXe8p79QJUjdMA7Ey7/x/TNeCFzXfw3aMs8UOXsgTbkWlGTpvK7g0Je+es372Wp0D 1ymIsR3Zku11B6dE3sHNFbiuZNKR6It9OP3rR78KMVzHIpAvHXU+dGK4p5YrLUCE0XD5LSTqpe6oY LcFR5Huu1OUBx2eMSed31UR0SFFqfObviYMcbAv3t7S2xTqdop26gGyWm0ETBvtfTg1RriU4mPx0m /GlJ7KGv4bCshE8vz8WvCWtdQih0ih6XQ50148mWIJVwtZIxSWCQdD2Q1WcyxwX6suga+MOhOOHiG UqaaZPow==; Received: from static-50-53-52-16.bvtn.or.frontiernet.net ([50.53.52.16] helo=midway.dunlab) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1exHKw-0003gt-62; Sat, 17 Mar 2018 19:17:50 +0000 Subject: Re: [PATCH] init: no need to wait device probe To: ning.a.zhang@intel.com, linux-kernel@vger.kernel.org References: <20180315072029.11441-1-ning.a.zhang@intel.com> From: Randy Dunlap Message-ID: <403951f8-a083-40d4-d58e-1f69ced6195a@infradead.org> Date: Sat, 17 Mar 2018 12:17:46 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180315072029.11441-1-ning.a.zhang@intel.com> 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 Hi, On 03/15/2018 12:20 AM, ning.a.zhang@intel.com wrote: > From: Zhang Ning meta comment (i.e., not about the merits of the patch itself): You'll need to send the patch to someone if you want it to be merged. Maintainers don't mine mailing lists for patches to apply. > there are 2 reasons for no need to wait device probe > > reason 1: > mount root device is very late in kernel initial stage. > all initcalls are finished. that means most of probe functions > are returned. > > and deferred probe are also finished by late_initcall. > only async probe driver are possible in probing. > > no block devices, device-mapper or nfs are use async probe. > so no need to wait device probe. > > reason 2: > let's check dd.c, probe_count is increased and decreased only > in really_probe, and when really_probe returns, probe_count > always be 0. > > when someone really wants to wait device-B probe. > but code looks like: > > thread-1: thread-2: > probe device-A; wait_for_device_probe(); > msleep(30); > probe device-B > > when device-A probe finishes, thread-2 will be wakeup, > but device-B is not probed. > > wait_for_device_probe can't make sure the device you want is probed. > > based on above 2 reasons, no need to wait for device probe. > > Signed-off-by: Zhang Ning > --- > init/do_mounts.c | 9 --------- > init/do_mounts_md.c | 2 -- > 2 files changed, 11 deletions(-) > > diff --git a/init/do_mounts.c b/init/do_mounts.c > index 7cf4f6dafd5f..a9fb2ad44964 100644 > --- a/init/do_mounts.c > +++ b/init/do_mounts.c > @@ -555,15 +555,6 @@ void __init prepare_namespace(void) > ssleep(root_delay); > } > > - /* > - * wait for the known devices to complete their probing > - * > - * Note: this is a potential source of long boot delays. > - * For example, it is not atypical to wait 5 seconds here > - * for the touchpad of a laptop to initialize. > - */ > - wait_for_device_probe(); > - > md_run_setup(); > > if (saved_root_name[0]) { > diff --git a/init/do_mounts_md.c b/init/do_mounts_md.c > index 3f733c760a8c..4aab3492e71d 100644 > --- a/init/do_mounts_md.c > +++ b/init/do_mounts_md.c > @@ -292,8 +292,6 @@ static void __init autodetect_raid(void) > printk(KERN_INFO "md: Waiting for all devices to be available before autodetect\n"); > printk(KERN_INFO "md: If you don't use raid, use raid=noautodetect\n"); > > - wait_for_device_probe(); > - > fd = sys_open("/dev/md0", 0, 0); > if (fd >= 0) { > sys_ioctl(fd, RAID_AUTORUN, raid_autopart); > -- ~Randy