From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 38A2FC433EF for ; Thu, 23 Jun 2022 09:55:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229592AbiFWJzv (ORCPT ); Thu, 23 Jun 2022 05:55:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57234 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231171AbiFWJzt (ORCPT ); Thu, 23 Jun 2022 05:55:49 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE21C2E9C3; Thu, 23 Jun 2022 02:55:46 -0700 (PDT) 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 ams.source.kernel.org (Postfix) with ESMTPS id 63F23B82236; Thu, 23 Jun 2022 09:55:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63210C3411B; Thu, 23 Jun 2022 09:55:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655978144; bh=3tgSj2b7F5bqM8rHpJ7bzxzD2TUoAE/bbCKa8uujIzc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZgvzyZeua6gp2AlwNoBJJfJCKKDtkcP0jOcabqo4Ve6xzhfqozU3hvrBwzHaUJyql Kn69u/AcTlTOq4NG6WmG9HOBfZc+myqE7DJETCuRE9/61tGz20fCKrR3Vc/Re7eWk2 YKVg1yFopUitiP8xoZYB171/fITa9+k7OIhhtfos= Date: Thu, 23 Jun 2022 11:55:41 +0200 From: Greg Kroah-Hartman To: Saravana Kannan Cc: Marek Szyprowski , LKML , linux-arm-kernel , Geert Uytterhoeven , Kevin Hilman , Marc Zyngier , Will Deacon , Rob Herring , "Rafael J. Wysocki" , Ulf Hansson , Linus Walleij , Sebastian Andrzej Siewior , Android Kernel Team , Linux PM Subject: Re: Default async probing for DT based systems Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Wed, Jun 22, 2022 at 07:36:24PM -0700, Saravana Kannan wrote: > On Fri, Jun 17, 2022 at 11:04 AM Saravana Kannan wrote: > > > > On Fri, Jun 17, 2022 at 2:04 AM Marek Szyprowski > > wrote: > > > > > > Hi Saravana, > > > > > > On 16.06.2022 05:24, Saravana Kannan wrote: > > > > Hi, > > > > > > > > TL;DR: I want to improve boot times by enabling async probing by > > > > default for DT based systems. Can you give it a shot please? > > > > > > Yes, I've gave it a try on my test systems. It looks that there are a > > > few issues. The first one, the most obvious to notice, is related to > > > __request_module() calls from various drivers and frameworks. Here are > > > some examples: > > > > > > ------------[ cut here ]------------ > > > WARNING: CPU: 3 PID: 73 at kernel/kmod.c:136 __request_module+0x230/0x600 > > > Modules linked in: > > > CPU: 3 PID: 73 Comm: kworker/u12:5 Not tainted 5.19.0-rc2-next-20220615+ > > > #5203 > > > Hardware name: ARM Juno development board (r1) (DT) > > > Workqueue: events_unbound async_run_entry_fn > > > pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > > UDC core: g_ether: couldn't find an available UDC > > > pc : __request_module+0x230/0x600 > > > lr : __request_module+0x228/0x600 > > > > Ah, I think I know what these might be. Going by memory, > > __request_module() from asyc thread context has some issues for module > > loading. So I think a check was added like this. And I think the check > > is triggering when it shouldn't (this isn't module context here). > > My memory was right and this is indeed the spurious warning that was > meant to cover a potential deadlock in a module load path. I was > trying to disable this warning till we hit the point in the boot flow > where request_module() can actually succeed. But I got stuck trying to > figure it out. > > It looks like the usermode helper that's used for module loading > triggered by request_module() is enabled in populate_rootfs() that > runs well before most of the initcalls are done. I was under the > impression that init with pid 0 would be the first userspace thread > that can start. But I don't see anything obvious that prevents the > usermode helper from running and loading a module before init process > has been exec'ed after we set system_state to SYSTEM_RUNNING. > > Can someone clarify when is the earliest request_module() can succeed? It can succeed very very early, when we have the initial ramfs mounted before init runs as you sometimes need the modules there to be able to load the device that init is on. thanks, greg k-h