Received: by 10.213.65.68 with SMTP id h4csp1214127imn; Sun, 18 Mar 2018 19:56:30 -0700 (PDT) X-Google-Smtp-Source: AG47ELt8IguNE6J5tuq0UCiULTPxw7Fb0SSutMtZxsJG57uh+fD8EkaMPBsfNBt6Tz0bU5Ft9Udt X-Received: by 10.101.101.15 with SMTP id x15mr3422115pgv.322.1521428189945; Sun, 18 Mar 2018 19:56:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521428189; cv=none; d=google.com; s=arc-20160816; b=VzwsVAxEtle17MSZbzaJP9QnpKvhtrdKTsAQNOnDXSLQBASvjlNpjzUBuIwEjlB0/g zI1mT8KENy/0gjZ0HTqvvDFouHyXYN5hjbHEn9Uk/ewsG1SP+204ncbnsHK4oVts3fET HIS+UGSOASorQ5Jnid8hle2XanLmR0PB6isOdKzoJkVLTrKwghemc+i1eRsHpQvmy0i+ weHiFS+B6OQFH98pmrHrADDaF7UcfvHH5qtS80cDnbcbvf23Q/gVnqyslpJtODq+eO0q oQwWARqfMWxY73LEI7OxFkpkyh42h1Kxu+dUCzJxT9K8I4ZFpNDjBdEwAwXhjyw7L9+E xqOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=DwfarKWcu1Tei/1y0pHJFolLDhxe38iTbkxSOCyFUo4=; b=UGqgDdyGJoG78GrWjzQVhLd6s9x2o7RswFkJOBjkdqLsM7fdB6ZxJgySSLfjihBGxx KPfLKDJPkfNui08dR6/m+Qoxh/yEKL8ifY+vjdua/qbuB2pqOfnacw4zfEiMah9tYjXQ W0+MMrETmQbBliK86FS0DOpaS9+k/uM8NQmsWugSSS+w0KrbLC0Kqp2efbu/dEbJgn1d miPcor5aDZ+C7yBqiH9VvckcApI01xhOux5UV01cNCWDAh1PoMuPiL5hmf0yFklTRLwH Xgq1Hpv0BZ2DZYNvOjoah8dZejG5wgDROMxeBjaD+9RbAScBMlKqge8Yq8DZu+hU3Qmm SiZQ== 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 z15si9852807pfm.352.2018.03.18.19.56.14; Sun, 18 Mar 2018 19:56:29 -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 S1754908AbeCSCzW (ORCPT + 99 others); Sun, 18 Mar 2018 22:55:22 -0400 Received: from mga02.intel.com ([134.134.136.20]:53941 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754383AbeCSCzV (ORCPT ); Sun, 18 Mar 2018 22:55:21 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Mar 2018 19:55:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,328,1517904000"; d="scan'208";a="212762307" Received: from ning-debian.sh.intel.com ([10.239.16.113]) by fmsmga005.fm.intel.com with ESMTP; 18 Mar 2018 19:55:17 -0700 From: ning.a.zhang@intel.com To: dhowells@redhat.com, akpm@linux-foundation.org, alexander.levin@verizon.com, kstewart@linuxfoundation.org, tglx@linutronix.de, gregkh@linuxfoundation.org, pombredanne@nexb.com Cc: linux-kernel@vger.kernel.org, Zhang Ning Subject: [PATCH] init: no need to wait device probe Date: Mon, 19 Mar 2018 10:55:08 +0800 Message-Id: <20180319025508.3767-1-ning.a.zhang@intel.com> X-Mailer: git-send-email 2.14.2 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Zhang Ning 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); -- 2.14.2