X-Received: by 2002:a17:90b:4d86:b0:1b9:d5fe:b30 with SMTP id oj6-20020a17090b4d8600b001b9d5fe0b30mr2436406pjb.142.1645507241108; Mon, 21 Feb 2022 21:20:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645507241; cv=none; d=google.com; s=arc-20160816; b=biuUxuFhdvQdKL6zH3d6vHuiaGWTE0f5KBIkzOvvzZZ99ra8TVLsIWvH7Km5QQ6Jdc 0TPi0LoARy6BOTZ7eTueKzj4nbQNzMKHENkpQ8/T0a0VoQusnAL3IL8C0ggY3pDx3pC6 0cBEQrLOBoZmlObqM5CZw4NOLlO2zk3O4P+eIFKND6/r5wHe3wN41uiGK/I1yL7y8Whx DjiVu3V4svy2Q3JQDcZLrru6Xnm6AXhsKe5+r803xrfqoQilM6VZFrTNi2iNWP+lYQR9 C9ROQ3sP3RYOA0HiS0AO6vtF/cxBticlP1sXXUnrlIHgBiDI47Wud8HlbAO9ouaXWICG cF9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=8B6/i0j6NeEqB+liKFsHGyucrc3aZekX4ZoLwAh4JZ0=; b=ixLSjhVlP6u21Lzs4Rd9JJNawuZqT+ki06wqq1jse2AVuUMRxYKruXDxWQj1ri2S56 ePQ8/Ti3sGbFatP0+P5APc12o3hqjq7D4D7Qfn9+GdFHwEqDdnLYoVEvLmVXerA2ruAX Fmt19cCVUkq6Zw8X/dz7GG9DgY4Kf6mwbYvFh06q68kb2PLS33puBLR6kVNXmrgjN/Qc i106eeKsZKFQhs97dAlvOXz423HoQUWuBQrTmdDiP94Enmzp9/UPAiC69MRFqJGC1U3g vjSaIH+mui7iajsxhpJqjpU+dn+Izd8E3FNb/P7I6WXaXf3SdlsbU007DsRZ43A0afF/ tAYw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=NWuR7OTS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id q36si4062824pgl.872.2022.02.21.21.20.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Feb 2022 21:20:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=NWuR7OTS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5B5C3888C4; Mon, 21 Feb 2022 20:51:56 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347616AbiBUJIM (ORCPT + 99 others); Mon, 21 Feb 2022 04:08:12 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:41870 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348518AbiBUJC4 (ORCPT ); Mon, 21 Feb 2022 04:02:56 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A2372CC88; Mon, 21 Feb 2022 00:58:17 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 91C6760FB6; Mon, 21 Feb 2022 08:58:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C9E7C340EB; Mon, 21 Feb 2022 08:58:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1645433896; bh=6ISO8dDd+jBpPTo5s/rGjUHrpeEbfdrVumxDZHMAUh8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NWuR7OTStFO/RpsrXbhrhuQTXKN+tROyHlqkeondhXIf7lRWoJBawtg4o58FgWHnU 3JKT/6T7dxeTzmSmVtU4I77tmxXXMS30q90K2YcJNYKFBaMwgq9bS9X/Mwa2mQ5mqk 955G1qkMX2aL6u97Ez38DDwinDk7KfLo3zc1O5Es= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Igor Pylypiv , Changyuan Lyu , Luis Chamberlain , Tejun Heo , Linus Torvalds , Sasha Levin Subject: [PATCH 5.4 22/80] Revert "module, async: async_synchronize_full() on module init iff async is used" Date: Mon, 21 Feb 2022 09:49:02 +0100 Message-Id: <20220221084916.312284506@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220221084915.554151737@linuxfoundation.org> References: <20220221084915.554151737@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Igor Pylypiv [ Upstream commit 67d6212afda218d564890d1674bab28e8612170f ] This reverts commit 774a1221e862b343388347bac9b318767336b20b. We need to finish all async code before the module init sequence is done. In the reverted commit the PF_USED_ASYNC flag was added to mark a thread that called async_schedule(). Then the PF_USED_ASYNC flag was used to determine whether or not async_synchronize_full() needs to be invoked. This works when modprobe thread is calling async_schedule(), but it does not work if module dispatches init code to a worker thread which then calls async_schedule(). For example, PCI driver probing is invoked from a worker thread based on a node where device is attached: if (cpu < nr_cpu_ids) error = work_on_cpu(cpu, local_pci_probe, &ddi); else error = local_pci_probe(&ddi); We end up in a situation where a worker thread gets the PF_USED_ASYNC flag set instead of the modprobe thread. As a result, async_synchronize_full() is not invoked and modprobe completes without waiting for the async code to finish. The issue was discovered while loading the pm80xx driver: (scsi_mod.scan=async) modprobe pm80xx worker ... do_init_module() ... pci_call_probe() work_on_cpu(local_pci_probe) local_pci_probe() pm8001_pci_probe() scsi_scan_host() async_schedule() worker->flags |= PF_USED_ASYNC; ... < return from worker > ... if (current->flags & PF_USED_ASYNC) <--- false async_synchronize_full(); Commit 21c3c5d28007 ("block: don't request module during elevator init") fixed the deadlock issue which the reverted commit 774a1221e862 ("module, async: async_synchronize_full() on module init iff async is used") tried to fix. Since commit 0fdff3ec6d87 ("async, kmod: warn on synchronous request_module() from async workers") synchronous module loading from async is not allowed. Given that the original deadlock issue is fixed and it is no longer allowed to call synchronous request_module() from async we can remove PF_USED_ASYNC flag to make module init consistently invoke async_synchronize_full() unless async module probe is requested. Signed-off-by: Igor Pylypiv Reviewed-by: Changyuan Lyu Reviewed-by: Luis Chamberlain Acked-by: Tejun Heo Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- include/linux/sched.h | 1 - kernel/async.c | 3 --- kernel/module.c | 25 +++++-------------------- 3 files changed, 5 insertions(+), 24 deletions(-) --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1454,7 +1454,6 @@ extern struct pid *cad_pid; #define PF_MEMALLOC 0x00000800 /* Allocating memory */ #define PF_NPROC_EXCEEDED 0x00001000 /* set_user() noticed that RLIMIT_NPROC was exceeded */ #define PF_USED_MATH 0x00002000 /* If unset the fpu must be initialized before use */ -#define PF_USED_ASYNC 0x00004000 /* Used async_schedule*(), used by module init */ #define PF_NOFREEZE 0x00008000 /* This thread should not be frozen */ #define PF_FROZEN 0x00010000 /* Frozen for system suspend */ #define PF_KSWAPD 0x00020000 /* I am kswapd */ --- a/kernel/async.c +++ b/kernel/async.c @@ -205,9 +205,6 @@ async_cookie_t async_schedule_node_domai atomic_inc(&entry_count); spin_unlock_irqrestore(&async_lock, flags); - /* mark that this task has queued an async job, used by module init */ - current->flags |= PF_USED_ASYNC; - /* schedule for execution */ queue_work_node(node, system_unbound_wq, &entry->work); --- a/kernel/module.c +++ b/kernel/module.c @@ -3711,12 +3711,6 @@ static noinline int do_init_module(struc } freeinit->module_init = mod->init_layout.base; - /* - * We want to find out whether @mod uses async during init. Clear - * PF_USED_ASYNC. async_schedule*() will set it. - */ - current->flags &= ~PF_USED_ASYNC; - do_mod_ctors(mod); /* Start the module */ if (mod->init != NULL) @@ -3742,22 +3736,13 @@ static noinline int do_init_module(struc /* * We need to finish all async code before the module init sequence - * is done. This has potential to deadlock. For example, a newly - * detected block device can trigger request_module() of the - * default iosched from async probing task. Once userland helper - * reaches here, async_synchronize_full() will wait on the async - * task waiting on request_module() and deadlock. - * - * This deadlock is avoided by perfomring async_synchronize_full() - * iff module init queued any async jobs. This isn't a full - * solution as it will deadlock the same if module loading from - * async jobs nests more than once; however, due to the various - * constraints, this hack seems to be the best option for now. - * Please refer to the following thread for details. + * is done. This has potential to deadlock if synchronous module + * loading is requested from async (which is not allowed!). * - * http://thread.gmane.org/gmane.linux.kernel/1420814 + * See commit 0fdff3ec6d87 ("async, kmod: warn on synchronous + * request_module() from async workers") for more details. */ - if (!mod->async_probe_requested && (current->flags & PF_USED_ASYNC)) + if (!mod->async_probe_requested) async_synchronize_full(); ftrace_free_mem(mod, mod->init_layout.base, mod->init_layout.base +