From patchwork Mon Jan 9 22:18:31 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Paul E. McKenney" X-Patchwork-Id: 9506033 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 410A16071A for ; Mon, 9 Jan 2017 22:19:10 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 318372832B for ; Mon, 9 Jan 2017 22:19:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2632F28528; Mon, 9 Jan 2017 22:19:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 594D428452 for ; Mon, 9 Jan 2017 22:19:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933090AbdAIWS6 (ORCPT ); Mon, 9 Jan 2017 17:18:58 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:47218 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933731AbdAIWSp (ORCPT ); Mon, 9 Jan 2017 17:18:45 -0500 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v09MEJo8129600 for ; Mon, 9 Jan 2017 17:18:39 -0500 Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by mx0a-001b2d01.pphosted.com with ESMTP id 27vj15th7t-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 09 Jan 2017 17:18:39 -0500 Received: from localhost by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 9 Jan 2017 15:18:38 -0700 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 9 Jan 2017 15:18:33 -0700 Received: from b03cxnp08027.gho.boulder.ibm.com (b03cxnp08027.gho.boulder.ibm.com [9.17.130.19]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 5EDEC1FF0027; Mon, 9 Jan 2017 15:18:11 -0700 (MST) Received: from b03ledav001.gho.boulder.ibm.com (b03ledav001.gho.boulder.ibm.com [9.17.130.232]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v09MIWbk10420510; Mon, 9 Jan 2017 15:18:32 -0700 Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 735C86E03A; Mon, 9 Jan 2017 15:18:32 -0700 (MST) Received: from paulmck-ThinkPad-W541 (unknown [9.85.137.27]) by b03ledav001.gho.boulder.ibm.com (Postfix) with ESMTP id D8E226E038; Mon, 9 Jan 2017 15:18:31 -0700 (MST) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id 3CE8816C0CF5; Mon, 9 Jan 2017 14:18:31 -0800 (PST) Date: Mon, 9 Jan 2017 14:18:31 -0800 From: "Paul E. McKenney" To: Borislav Petkov Cc: "Zheng, Lv" , "Rafael J. Wysocki" , "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: <20170108003730.hlcqkhdxtah65z66@pd.tnic> <20170108010158.b62eovaxsbmhfnkb@pd.tnic> <20170108130355.vxhjmj6dlkqw6hyq@pd.tnic> <1AE640813FDE7649BE1B193DEA596E886CE27B7E@SHSMSX101.ccr.corp.intel.com> <1AE640813FDE7649BE1B193DEA596E886CE27BEE@SHSMSX101.ccr.corp.intel.com> <20170109093329.jd7uwlcpci4icpd3@pd.tnic> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170109093329.jd7uwlcpci4icpd3@pd.tnic> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17010922-0004-0000-0000-0000114075A5 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006403; 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.00013870; XFM=3.00000011; UTC=2017-01-09 22:18:36 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17010922-0005-0000-0000-00007C0782D0 Message-Id: <20170109221831.GC3800@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-1701090298 Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Jan 09, 2017 at 10:33:29AM +0100, Borislav Petkov wrote: > + Paul for comment. > > Leaving in the rest for him. > > On Mon, Jan 09, 2017 at 02:36:33AM +0000, Zheng, Lv wrote: > > Hi, > > > > > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Zheng, > > > Lv > > > Subject: RE: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and > > > early_acpi_os_unmap_memory() from Linux kernel > > > > > > Hi, > > > > > > > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of > > > Borislav > > > > Petkov > > > > Subject: Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and > > > > early_acpi_os_unmap_memory() from Linux kernel > > > > > > > > On Sun, Jan 08, 2017 at 03:20:20AM +0100, Rafael J. Wysocki wrote: > > > > > drivers/iommu/amd_iommu_init.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > Index: linux-pm/drivers/iommu/amd_iommu_init.c > > > > > =================================================================== > > > > > --- linux-pm.orig/drivers/iommu/amd_iommu_init.c > > > > > +++ linux-pm/drivers/iommu/amd_iommu_init.c > > > > > @@ -2230,7 +2230,7 @@ static int __init early_amd_iommu_init(v > > > > > */ > > > > > ret = check_ivrs_checksum(ivrs_base); > > > > > if (ret) > > > > > - return ret; > > > > > + goto out; > > > > > > > > > > amd_iommu_target_ivhd_type = get_highest_supported_ivhd_type(ivrs_base); > > > > > DUMP_printk("Using IVHD type %#x\n", amd_iommu_target_ivhd_type); > > > > > > > > Good catch, this one needs to be applied regardless. > > > > > > > > However, it doesn't fix my issue though. > > > > > > > > But I think I have it - I went and applied the well-proven debugging > > > > technique of sprinkling printks around. Here's what I'm seeing: > > > > > > > > early_amd_iommu_init() > > > > |-> 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 <-- the kernel/rcu/tree_exp.h version with CONFIG_PREEMPT_RCU=y > > > > > > > > Now that function goes and sends IPIs, i.e., schedule_work() > > > > but this is too early - we haven't even done workqueue_init(). > > > > Actually, from looking at the callstack, we do > > > > kernel_init_freeable->native_smp_prepare_cpus() and workqueue_init() > > > > comes next. > > > > > > > > And this makes sense because the splat rIP points to __queue_work() but > > > > we haven't done that yet. > > > > > > > > So that acpi_put_table() is happening too early. Looks like AMD IOMMU > > > > should not put the table but WTH do I know?! > > > > > > > > In any case, commenting out: > > > > > > > > acpi_put_table(ivrs_base); > > > > ivrs_base = NULL; > > > > > > > > and the end of early_amd_iommu_init() makes the box boot again. > > > > > > So please help to comment out these 2 lines (with descriptions and do not delete them). > > > Until acpi_os_unmap_memory() is able to handle such an early case. > > > > IMO, synchronize_rcu_expedited() should be improved: > > If rcu_init() isn't called or there is nothing to synchronize, schedule_work() shouldn't be invoked. Indeed it should! Does the (untested) patch below fix things for you? If so, does this need to go into 4.10? (My default workflow would get it into 4.11 or 4.12, so please speak up if you need it.) Thanx, Paul ------------------------------------------------------------------------ commit 1b7feb708241f1662cfd529118468c9f9c0b1449 Author: Paul E. McKenney Date: Mon Jan 9 14:10:50 2017 -0800 rcu: Make synchronize_rcu_expedited() safe for early boot The synchronize_rcu_expedited() function does not check for early-boot use, which can result in failures if it is invoked before the scheduler has started. Given that the rcupdate.rcu_expedited kernel parameter causes all calls to synchronize_rcu() to be directed instead to synchronize_rcu_expedited(), a usage restriction does not make sense. This commit therefore adds a rcu_scheduler_active check to synchronize_rcu_expedited(), so that it is a no-op before the scheduler starts. This behavior is correct because there is only a single CPU running during that time. Reported-by: Lv Zheng Reported-by: Borislav Petkov Signed-off-by: Paul E. McKenney --- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h index dfc3ba5a429e..a6c3d86480de 100644 --- a/kernel/rcu/tree_exp.h +++ b/kernel/rcu/tree_exp.h @@ -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);