Received: by 10.213.65.68 with SMTP id h4csp1482788imn; Thu, 15 Mar 2018 00:23:06 -0700 (PDT) X-Google-Smtp-Source: AG47ELtljcqEjY+l5Nw9q+gk4bVLFVf51/dudTh5LlfdzvQkFCF+WXihjNRKoypdXD7oS2bhYm2j X-Received: by 2002:a17:902:968c:: with SMTP id n12-v6mr6967400plp.371.1521098585981; Thu, 15 Mar 2018 00:23:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521098585; cv=none; d=google.com; s=arc-20160816; b=KjunjFCe91uIlmmhxN4C3/Txks2i43rTQ6H3sD9Ah+vNvuaU4MsCCnwAC0aPDkgK0N Gtf17xZBXbtYSNf+/3n/hdBplw5MzMQ50j/NDssB5AfYJKvaPVhiCUeeIfBXRdrs2Tea GQPj5HhrbgfT0F7AnOxSF0F8ND4cThyOZ9Ay+Pma5sgNayfbTH8RSYkTZATHqmOTZUHO l8ZxEJVOOb/UdkPydjoXk4cDXhV1lvZV9GjWbGSISxct48Zygx1c6B7mGEX8HH1XLYih 7wT8RYrIskN4YisgJqmeHHMFPh53jqgYr6shtcbR4vGJj59lpYK8uixO5OTRLqf8A55A Wxiw== 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=jc4nG0IZlwMu3kCFuclwqnrcKyvQq1OzeeJDlydjbOt5Rz07r0vHhgVexJ5jyCDDhb 5IX+IVgNhdHer0+CtnUpSCPjW+TqJxmoomJAwaPqCu4xcENnbFe4Vopsyy5YH5KfTqrs qGWgUXlXD195RFTdqZACFrl4ymjc8K/GtrxbsEowMWXHKRnNpJhF3UvPs/FVu1U0wT5w tmNnh8e7q5b4yaUdizZT5c2d0plKGiTwR1RZ22ywKSp274uJKTZBBpOrtS4sGcAM5d67 xXIosGwasoYNhyI696YnBTY3VWO19uutNOUtmnWz2EmON05eCv/+hu7hjlWzB9Asb2bF tI/w== 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 i129si1289153pgd.206.2018.03.15.00.22.51; Thu, 15 Mar 2018 00:23:05 -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 S1751680AbeCOHUn (ORCPT + 99 others); Thu, 15 Mar 2018 03:20:43 -0400 Received: from mga18.intel.com ([134.134.136.126]:47720 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750950AbeCOHUm (ORCPT ); Thu, 15 Mar 2018 03:20:42 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Mar 2018 00:20:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,308,1517904000"; d="scan'208";a="208414772" Received: from ning-debian.sh.intel.com ([10.239.16.113]) by orsmga005.jf.intel.com with ESMTP; 15 Mar 2018 00:20:40 -0700 From: ning.a.zhang@intel.com To: linux-kernel@vger.kernel.org Cc: Zhang Ning Subject: [PATCH] init: no need to wait device probe Date: Thu, 15 Mar 2018 15:20:29 +0800 Message-Id: <20180315072029.11441-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