From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S942553AbdAJAVb (ORCPT ); Mon, 9 Jan 2017 19:21:31 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:53657 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756737AbdAJAVJ (ORCPT ); Mon, 9 Jan 2017 19:21:09 -0500 Date: Mon, 9 Jan 2017 16:21:02 -0800 From: "Paul E. McKenney" To: "Rafael J. Wysocki" Cc: Borislav Petkov , "Zheng, Lv" , "Wysocki, Rafael J" , "Moore, Robert" , J?rg R?del , lkml , Linux ACPI Subject: Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel Reply-To: paulmck@linux.vnet.ibm.com References: <20170108130355.vxhjmj6dlkqw6hyq@pd.tnic> <1AE640813FDE7649BE1B193DEA596E886CE27B7E@SHSMSX101.ccr.corp.intel.com> <1AE640813FDE7649BE1B193DEA596E886CE27BEE@SHSMSX101.ccr.corp.intel.com> <20170109093329.jd7uwlcpci4icpd3@pd.tnic> <20170109221831.GC3800@linux.vnet.ibm.com> <20170109231501.xrhwsv46mznw3kqt@pd.tnic> <20170109233204.GG3800@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17011000-0020-0000-0000-00000AB077FB X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006404; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000199; SDB=6.00805275; UDB=6.00391913; IPR=6.00582896; BA=6.00005038; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013872; XFM=3.00000011; UTC=2017-01-10 00:21:06 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17011000-0021-0000-0000-000058BA73B4 Message-Id: <20170110002102.GI3800@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-01-09_16:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701100002 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 10, 2017 at 12:42:47AM +0100, Rafael J. Wysocki wrote: > On Tue, Jan 10, 2017 at 12:32 AM, Paul E. McKenney > wrote: > > 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? > > In the particular AMD IOMMU case it doesn't look like we are, but we > do in other cases. > > > (If we are already context switching, > > short-circuiting synchronize_rcu_expedited() would be a bug.) > > It may be easier to make the caller avoid RCU synchronization > altogether if that's not necessary and the caller should actually be > able to figure out when that's the case. > > The patch from Lv at https://patchwork.kernel.org/patch/9504277/ goes > in the right direction IMO, but I'm not yet convinced that this is the > right one. >>From the RCU end, I could force expedited grace periods to translate to normal grace periods during that window of time, and then make sure that RCU's grace-period kthreads are spawned beforehand. Looking into this... Thanx, Paul