On Mon, Jan 16, 2017 at 01:57:25AM +, Zheng, Lv wrote:
> Hi,
>
> > From: Borislav Petkov [mailto:b...@alien8.de]
> > Subject: Re: [PATCH] rcu: Narrow early boot window of illegal synchronous
> > grace periods
> >
> > On Sat, Jan 14, 2017 at 01:27
On Mon, Jan 16, 2017 at 01:57:25AM +, Zheng, Lv wrote:
> Hi,
>
> > From: Borislav Petkov [mailto:b...@alien8.de]
> > Subject: Re: [PATCH] rcu: Narrow early boot window of illegal synchronous
> > grace periods
> >
> > On Sat, Jan 14, 2017 at 01:27
Hi,
> From: Borislav Petkov [mailto:b...@alien8.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 sync
Hi,
> From: Borislav Petkov [mailto:b...@alien8.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 sync
On Sun, Jan 15, 2017 at 11:09:31AM +0100, Borislav Petkov wrote:
> On Sat, Jan 14, 2017 at 09:24:43PM -0800, Paul E. McKenney wrote:
> > > Which means, you probably should tag your fix CC:stable and add
> > >
> > > Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
> > >
>
On Sun, Jan 15, 2017 at 11:09:31AM +0100, Borislav Petkov wrote:
> On Sat, Jan 14, 2017 at 09:24:43PM -0800, Paul E. McKenney wrote:
> > > Which means, you probably should tag your fix CC:stable and add
> > >
> > > Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
> > >
>
On Sat, Jan 14, 2017 at 09:24:43PM -0800, Paul E. McKenney wrote:
> > Which means, you probably should tag your fix CC:stable and add
> >
> > Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
> >
> > to it too.
>
> Like this?
Very nice, ship it! :-)
Thanks.
--
On Sat, Jan 14, 2017 at 09:24:43PM -0800, Paul E. McKenney wrote:
> > Which means, you probably should tag your fix CC:stable and add
> >
> > Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
> >
> > to it too.
>
> Like this?
Very nice, ship it! :-)
Thanks.
--
On Sat, Jan 14, 2017 at 11:35:25AM +0100, Borislav Petkov wrote:
> On Sat, Jan 14, 2017 at 12:00:22AM -0800, Paul E. McKenney wrote:
> > It now looks like this:
> >
> >
> >
> > Note that the code was buggy even before this
On Sat, Jan 14, 2017 at 11:35:25AM +0100, Borislav Petkov wrote:
> On Sat, Jan 14, 2017 at 12:00:22AM -0800, Paul E. McKenney wrote:
> > It now looks like this:
> >
> >
> >
> > Note that the code was buggy even before this
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
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
On Sat, Jan 14, 2017 at 11:35 AM, Borislav Petkov wrote:
> On Sat, Jan 14, 2017 at 12:00:22AM -0800, Paul E. McKenney wrote:
>> It now looks like this:
>>
>>
>>
>> Note that the code was buggy even before
On Sat, Jan 14, 2017 at 11:35 AM, Borislav Petkov wrote:
> On Sat, Jan 14, 2017 at 12:00:22AM -0800, Paul E. McKenney wrote:
>> It now looks like this:
>>
>>
>>
>> Note that the code was buggy even before this commit, as it
On Sat, Jan 14, 2017 at 12:00:22AM -0800, Paul E. McKenney wrote:
> It now looks like this:
>
>
>
> Note that the code was buggy even before this commit, as it was subject
> to failure on real-time systems that forced all
On Sat, Jan 14, 2017 at 12:00:22AM -0800, Paul E. McKenney wrote:
> It now looks like this:
>
>
>
> Note that the code was buggy even before this commit, as it was subject
> to failure on real-time systems that forced all
On Fri, Jan 13, 2017 at 12:25:19PM +0100, Borislav Petkov wrote:
> On Thu, Jan 12, 2017 at 06:38:07PM -0800, Paul E. McKenney wrote:
> > The current preemptible RCU implementation goes through three phases
> > during bootup. In the first phase, there is only one CPU that is running
> > with
On Fri, Jan 13, 2017 at 12:25:19PM +0100, Borislav Petkov wrote:
> On Thu, Jan 12, 2017 at 06:38:07PM -0800, Paul E. McKenney wrote:
> > The current preemptible RCU implementation goes through three phases
> > during bootup. In the first phase, there is only one CPU that is running
> > with
On Thu, Jan 12, 2017 at 06:38:07PM -0800, Paul E. McKenney wrote:
> The current preemptible RCU implementation goes through three phases
> during bootup. In the first phase, there is only one CPU that is running
> with preemption disabled, so that a no-op is a synchronous grace period.
> In the
On Thu, Jan 12, 2017 at 06:38:07PM -0800, Paul E. McKenney wrote:
> The current preemptible RCU implementation goes through three phases
> during bootup. In the first phase, there is only one CPU that is running
> with preemption disabled, so that a no-op is a synchronous grace period.
> In the
On Thu, Jan 12, 2017 at 06:38:07PM -0800, Paul E. McKenney wrote:
> The current preemptible RCU implementation goes through three phases
> during bootup. In the first phase, there is only one CPU that is running
> with preemption disabled, so that a no-op is a synchronous grace period.
> In the
On Thu, Jan 12, 2017 at 06:38:07PM -0800, Paul E. McKenney wrote:
> The current preemptible RCU implementation goes through three phases
> during bootup. In the first phase, there is only one CPU that is running
> with preemption disabled, so that a no-op is a synchronous grace period.
> In the
22 matches
Mail list logo