Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2229602imu; Sat, 10 Nov 2018 10:12:14 -0800 (PST) X-Google-Smtp-Source: AJdET5fuB27uKTyaJ6Ad4R3MHzFc6AbEfDEObviqFL8KVJqHtE8IQ6wWa1CwqDnzllW2AejKYou7 X-Received: by 2002:aa7:8685:: with SMTP id d5-v6mr13554099pfo.58.1541873534284; Sat, 10 Nov 2018 10:12:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541873534; cv=none; d=google.com; s=arc-20160816; b=F4ZIQsQCHeVd3hAeN/W4fb3DGLUX0Vli5E+PoSiz0wf6IgB+ioa4oBpAHuj/NDszSF OFyAkCYXVm5/P69jjGcLB1BHdNQW2gJ3kT78xFgiHt2Yr0BUgtmk5hm2Y0THmxCpeIDS dgVhOCYZEsmVnQ5xOolMqLYnn3UGHPsfVa1xF3RCwEObLKjWDkvmHgH5AxjSxKLGzO5p DfKaI8PrF7emKC62mXKehBF5tu6P99U+eR9RMODpCvmxJ6o6nOiMYxG5e/NKA9stDQOI 7aFaaTuOJXGaroBcUQSKEQWW9pF3/I67Btq0ca+jH2yh5OzR9YpkR9HO8aeVHfeybLLl PXqQ== 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:mime-version :message-id:date:subject:cc:to:from; bh=4U7TnaVvlLWIoBSUZZzlH+FA1BbxTzWeliPXM5h4OC4=; b=AILvu+fgfWPmlTT443qIGwzTnW4dJ6nfkHQIr0qO0B7ucVETfgLNoyfx00cQca7jO1 AuO7uc1dxIt3WghQD/TcxgfGNWj9s1U/hW2eljm3XlMiURaYGBfhITkYImfnv5ZcRllz RhzdevJHo7DTmOX0XXgyngNTPG1+jpjBYKAqZuyMcVD0jxBX/dVvqPHlWBRmy5aWDb2+ TP6d8mtaOd3jHE+YDyy2Dw5mKz1CUHNqGNCa23xMVQMG56nsSmytehDM+rVYVLaxNfT0 0mva3w2jdwblghOYtbuUhPjNOaATg46Y8BNHX9eK6bxCc528UlKyEH3D3gg99VP7ColJ oHHQ== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g5-v6si11880541pfg.225.2018.11.10.10.11.59; Sat, 10 Nov 2018 10:12:14 -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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727174AbeKKD5B (ORCPT + 99 others); Sat, 10 Nov 2018 22:57:01 -0500 Received: from mga12.intel.com ([192.55.52.136]:15025 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727067AbeKKD5B (ORCPT ); Sat, 10 Nov 2018 22:57:01 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Nov 2018 10:11:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,488,1534834800"; d="scan'208";a="90126921" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga006.jf.intel.com with ESMTP; 10 Nov 2018 10:11:03 -0800 Received: by black.fi.intel.com (Postfix, from userid 1003) id C77791AC; Sat, 10 Nov 2018 20:11:02 +0200 (EET) From: Andy Shevchenko To: MyungJoo Ham , Chanwoo Choi , linux-usb@vger.kernel.org, Felipe Balbi , Guenter Roeck , Heikki Krogerus , Roger Quadros , linux-pm@vger.kernel.org, "Rafael J. Wysocki" , Sebastian Reichel , linux-omap@vger.kernel.org, Darren Hart , platform-driver-x86@vger.kernel.org, Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Chen-Yu Tsai , Hans de Goede Cc: Andy Shevchenko , Grant Likely , Peter Ujfalusi , Mark Brown , Andrzej Hajda Subject: [PATCH v1 1/5] drivercore: Revert "deferral race condition fix" Date: Sat, 10 Nov 2018 20:10:57 +0200 Message-Id: <20181110181101.24557-1-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.19.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Consider the following scenario. There are two independent devices coupled together by functional dependencies: - USB OTG (dwc3-pci) - extcon (tested with extcon-intel-mrfld, not yet in upstream) Each of the driver services a corresponding device is built as a module. In the Buildroot environment the modules are probed by alphabetical ordering of their modaliases. The latter comes to the case when USB OTG driver will be probed first followed by extcon one. So, if the platform anticipates extcon device to be appeared, in the above case we will get deferred probe of USB OTG, because of ordering. Now, a cherry on top of the cake, the deferred probing list contains the only two modules, i.e. USB OTG and extcon. Due to above circumstances, values in the local_trigger_count and deferred_trigger_count are not the same, and thus provokes deferred probe triggering again and again. ... [ 20.678332] platform dwc3.0.auto: Retrying from deferred list [ 20.694743] platform dwc3.0.auto: Driver dwc3 requests probe deferral [ 20.701254] platform dwc3.0.auto: Added to deferred list [ 20.706620] platform dwc3.0.auto: driver_deferred_probe_add_trigger 1 2 [ 20.713732] platform dwc3.0.auto: Retrying from deferred list [ 20.730035] platform dwc3.0.auto: Driver dwc3 requests probe deferral [ 20.736540] platform dwc3.0.auto: Added to deferred list [ 20.741889] platform dwc3.0.auto: driver_deferred_probe_add_trigger 3 4 [ 20.748991] platform dwc3.0.auto: Retrying from deferred list [ 20.765416] platform dwc3.0.auto: Driver dwc3 requests probe deferral [ 20.771914] platform dwc3.0.auto: Added to deferred list [ 20.777279] platform dwc3.0.auto: driver_deferred_probe_add_trigger 5 6 ... Deeper investigation shows the culprit commit 58b116bce136 ("drivercore: deferral race condition fix") which was dedicated to fix some other issue while bringing a regression. This reverts commit 58b116bce13612e5aa6fcd49ecbd4cf8bb59e835 for good until we will have better solution. Cc: Grant Likely Cc: Peter Ujfalusi Cc: Greg Kroah-Hartman Cc: Mark Brown Cc: Felipe Balbi Cc: Andrzej Hajda Signed-off-by: Andy Shevchenko --- drivers/base/dd.c | 27 ++------------------------- 1 file changed, 2 insertions(+), 25 deletions(-) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 169412ee4ae8..9a966e45fda5 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -53,7 +53,6 @@ static DEFINE_MUTEX(deferred_probe_mutex); static LIST_HEAD(deferred_probe_pending_list); static LIST_HEAD(deferred_probe_active_list); -static atomic_t deferred_trigger_count = ATOMIC_INIT(0); static struct dentry *deferred_devices; static bool initcalls_done; @@ -143,17 +142,6 @@ static bool driver_deferred_probe_enable = false; * This functions moves all devices from the pending list to the active * list and schedules the deferred probe workqueue to process them. It * should be called anytime a driver is successfully bound to a device. - * - * Note, there is a race condition in multi-threaded probe. In the case where - * more than one device is probing at the same time, it is possible for one - * probe to complete successfully while another is about to defer. If the second - * depends on the first, then it will get put on the pending list after the - * trigger event has already occurred and will be stuck there. - * - * The atomic 'deferred_trigger_count' is used to determine if a successful - * trigger has occurred in the midst of probing a driver. If the trigger count - * changes in the midst of a probe, then deferred processing should be triggered - * again. */ static void driver_deferred_probe_trigger(void) { @@ -166,7 +154,6 @@ static void driver_deferred_probe_trigger(void) * into the active list so they can be retried by the workqueue */ mutex_lock(&deferred_probe_mutex); - atomic_inc(&deferred_trigger_count); list_splice_tail_init(&deferred_probe_pending_list, &deferred_probe_active_list); mutex_unlock(&deferred_probe_mutex); @@ -434,19 +421,9 @@ EXPORT_SYMBOL_GPL(device_bind_driver); static atomic_t probe_count = ATOMIC_INIT(0); static DECLARE_WAIT_QUEUE_HEAD(probe_waitqueue); -static void driver_deferred_probe_add_trigger(struct device *dev, - int local_trigger_count) -{ - driver_deferred_probe_add(dev); - /* Did a trigger occur while probing? Need to re-trigger if yes */ - if (local_trigger_count != atomic_read(&deferred_trigger_count)) - driver_deferred_probe_trigger(); -} - static int really_probe(struct device *dev, struct device_driver *drv) { int ret = -EPROBE_DEFER; - int local_trigger_count = atomic_read(&deferred_trigger_count); bool test_remove = IS_ENABLED(CONFIG_DEBUG_TEST_DRIVER_REMOVE) && !drv->suppress_bind_attrs; @@ -463,7 +440,7 @@ static int really_probe(struct device *dev, struct device_driver *drv) ret = device_links_check_suppliers(dev); if (ret == -EPROBE_DEFER) - driver_deferred_probe_add_trigger(dev, local_trigger_count); + driver_deferred_probe_add(dev); if (ret) return ret; @@ -559,7 +536,7 @@ static int really_probe(struct device *dev, struct device_driver *drv) case -EPROBE_DEFER: /* Driver requested deferred probing */ dev_dbg(dev, "Driver %s requests probe deferral\n", drv->name); - driver_deferred_probe_add_trigger(dev, local_trigger_count); + driver_deferred_probe_add(dev); break; case -ENODEV: case -ENXIO: -- 2.19.1