[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 16 Jan 2017 01:57:25 +0000
From: "Zheng, Lv" <lv.zheng@...el.com>
To: Borislav Petkov <bp@...en8.de>,
"Rafael J. Wysocki" <rafael@...nel.org>
CC: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"stan.kain@...il.com" <stan.kain@...il.com>,
"waffolz@...mail.com" <waffolz@...mail.com>,
Josh Triplett <josh@...htriplett.org>,
Steven Rostedt <rostedt@...dmis.org>,
"mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>,
"jiangshanlai@...il.com" <jiangshanlai@...il.com>,
Ingo Molnar <mingo@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: RE: [PATCH] rcu: Narrow early boot window of illegal synchronous
grace periods
Hi,
> From: Borislav Petkov [mailto:bp@...en8.de]
> Subject: Re: [PATCH] rcu: Narrow early boot window of illegal synchronous grace periods
>
> On Sat, Jan 14, 2017 at 01:27:40PM +0100, Rafael J. Wysocki wrote:
> > OK, so this fixes the problem with synchronize_rcu_expedited() in
> > acpi_os_map_cleanup(), right?
>
> Yeah.
>
> > I wonder if the ACPI-specific fix is still needed, then?
>
> It is not strictly necessary. If you still think it would be better to
> have it regardless, you could pick it up. I.e., making ACPI more robust,
> yadda yadda.
>
> I dunno, though, perhaps it is only complicating the code unnecessarily
> and then can be safely ignored with a mental note for future freezes.
Glad to see it fixed inside of the API provider.
IMO, ACPI fix is unnecessary as ACPI is just a user of the RCU APIs.
And it's pointless to add special checks in the user side in order to use one of them.
Thanks and best regards
Lv
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
Powered by blists - more mailing lists