linux-kernel - Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20170109235206.GH3800@linux.vnet.ibm.com>
Date:   Mon, 9 Jan 2017 15:52:06 -0800
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     "Zheng, Lv" <lv.zheng@...el.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        "Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
        "Moore, Robert" <robert.moore@...el.com>,
        J?rg R?del <joro@...tes.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Linux ACPI <linux-acpi@...r.kernel.org>
Subject: Re: 174cc7187e6f ACPICA: Tables: Back port
 acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux
 kernel

On Tue, Jan 10, 2017 at 12:40:39AM +0100, Borislav Petkov wrote:
> On Mon, Jan 09, 2017 at 03:32:04PM -0800, Paul E. McKenney wrote:
> > We could move rcu_scheduler_starting() later, as long as there
> > is no chance of preemption or context switch before it is invoked.
> > Would that help in this case, or are we already context switching before
> > acpi_os_map_cleanup() is invoked?  (If we are already context switching,
> > short-circuiting synchronize_rcu_expedited() would be a bug.)
> 
> Hmm, how about the below?
> 
> It would still happen before
> 
>         /*
>          * The boot idle thread must execute schedule()
>          * at least once to get things moving:
>          */
>         init_idle_bootup_task(current);
>         schedule_preempt_disabled();
> 
> in rest_init() and right after native_smp_prepare_cpus() which is where
> we're splatting.
> 
> Lemme run it.
> 
> Even if it works, we would have to stress-test this seriously...

Yeah, the call to wait_for_completion() at the beginning of
kernel_init_freeable() makes me extremely nervous.  Even if it does
happen to work, this looks like an accident waiting to happen.

Is it possible to instead move the ACPI initialization to follow the
workqueue initialization?

							Thanx, Paul

> ---
> diff --git a/init/main.c b/init/main.c
> index b0c9d6facef9..9be221cc87c3 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -385,7 +385,6 @@ static noinline void __ref rest_init(void)
>  {
>  	int pid;
> 
> -	rcu_scheduler_starting();
>  	/*
>  	 * We need to spawn init first so that it obtains pid 1, however
>  	 * the init task will end up wanting to create kthreads, which, if
> @@ -1019,6 +1018,8 @@ static noinline void __init kernel_init_freeable(void)
> 
>  	smp_prepare_cpus(setup_max_cpus);
> 
> +	rcu_scheduler_starting();
> +
>  	workqueue_init();
> 
>  	do_pre_smp_initcalls();
> 
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> Good mailing practices for 400: avoid top-posting and trim the reply.
>