[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170109233204.GG3800@linux.vnet.ibm.com>
Date: Mon, 9 Jan 2017 15:32:04 -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:15:01AM +0100, Borislav Petkov wrote:
> On Mon, Jan 09, 2017 at 02:18:31PM -0800, Paul E. McKenney wrote:
> > @@ -690,6 +690,8 @@ void synchronize_rcu_expedited(void)
> > {
> > struct rcu_state *rsp = rcu_state_p;
> >
> > + if (!rcu_scheduler_active)
> > + return;
> > _synchronize_rcu_expedited(rsp, sync_rcu_exp_handler);
> > }
> > EXPORT_SYMBOL_GPL(synchronize_rcu_expedited);
>
> That doesn't work and it is because of those damn what goes before what
> boot sequence issues :-\
>
> We have:
>
> rest_init()
> |-> rcu_scheduler_starting() ---> that sets rcu_scheduler_active = 1;
> |-> kernel_thread(kernel_init, NULL, CLONE_FS);
> |-> kernel_init()
> |-> kernel_init_freeable()
> |-> native_smp_prepare_cpus(setup_max_cpus)
> |-> default_setup_apic_routing
> |-> enable_IR_x2apic
> |-> irq_remapping_prepare
> |-> amd_iommu_prepare
> |-> iommu_go_to_state
> |-> acpi_put_table(ivrs_base);
> |-> acpi_tb_put_table(table_desc);
> |-> acpi_tb_invalidate_table(table_desc);
> |-> acpi_tb_release_table(...)
> |-> acpi_os_unmap_memory
> |-> acpi_os_unmap_iomem
> |-> acpi_os_map_cleanup
> |-> synchronize_rcu_expedited()
>
> Now here we have rcu_scheduler_active already set so the test doesn't
> hit and we hang.
>
> So we must do it differently.
Yeah, there is a window just as the scheduler is starting where things don't
work.
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.)
Thanx, Paul
Powered by blists - more mailing lists