From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760455AbdAKJwG (ORCPT ); Wed, 11 Jan 2017 04:52:06 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:59831 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1758960AbdAKJwE (ORCPT ); Wed, 11 Jan 2017 04:52:04 -0500 Date: Wed, 11 Jan 2017 01:51:56 -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: <20170109221831.GC3800@linux.vnet.ibm.com> <20170109231501.xrhwsv46mznw3kqt@pd.tnic> <20170109233204.GG3800@linux.vnet.ibm.com> <20170109234039.mfefmv5dv4shxnfn@pd.tnic> <20170109235211.yetponvbexvalkir@pd.tnic> <20170110022338.GJ3800@linux.vnet.ibm.com> <1AE640813FDE7649BE1B193DEA596E886CE286C3@SHSMSX101.ccr.corp.intel.com> <20170110055129.GK3800@linux.vnet.ibm.com> <20170111092105.3y57tyeskpyjtmxi@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170111092105.3y57tyeskpyjtmxi@pd.tnic> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17011109-0028-0000-0000-0000066C8CA9 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006413; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000199; SDB=6.00806074; UDB=6.00392224; IPR=6.00583409; BA=6.00005045; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013888; XFM=3.00000011; UTC=2017-01-11 09:52:01 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17011109-0029-0000-0000-000032498CAB Message-Id: <20170111095156.GR3800@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-01-11_09:,, 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-1701110139 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 11, 2017 at 10:21:06AM +0100, Borislav Petkov wrote: > On Mon, Jan 09, 2017 at 09:51:29PM -0800, Paul E. McKenney wrote: > > Definitely. > > Btw, we have more breakage from RCU expedited using workqueues: > https://bugzilla.kernel.org/show_bug.cgi?id=192111 > > I've added you to CC but let me have other bug reporters confirm reverting > > 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue") > > does fix the issue for them too. Yes, you could make RCU expedited grace periods go back to using the requesting task, and that would allow expedited grace periods to run early in the boot process. But that causes problems with signals and the like unless you revert a few other patches. The bugzilla is interesting -- it looks like ACPI was in some cases doing early-boot grace-period waits some time back? I have a limping prototype RCU patch that should avoid this problem. If all goes well, I will send it out late tomorrow evening, Pacific Time. Thanx, Paul