On Wed, Oct 17, 2018 at 06:00:51PM +0200, 'Sebastian Andrzej Siewior' wrote:
> On 2018-10-17 17:47:07 [+0200], Peter Zijlstra wrote:
> > > > Ideally we'd never ever merge anything that only does local invalidates,
> > > > on a global address space, that's just broken.
> > >
> > > A little bit
On Wed, Oct 17, 2018 at 06:00:51PM +0200, 'Sebastian Andrzej Siewior' wrote:
> On 2018-10-17 17:47:07 [+0200], Peter Zijlstra wrote:
> > > > Ideally we'd never ever merge anything that only does local invalidates,
> > > > on a global address space, that's just broken.
> > >
> > > A little bit
On 2018-10-17 17:47:07 [+0200], Peter Zijlstra wrote:
> > > Ideally we'd never ever merge anything that only does local invalidates,
> > > on a global address space, that's just broken.
> >
> > A little bit late to lament about that.
>
> For this, yes :/ But for future stuff we should really not
On 2018-10-17 17:47:07 [+0200], Peter Zijlstra wrote:
> > > Ideally we'd never ever merge anything that only does local invalidates,
> > > on a global address space, that's just broken.
> >
> > A little bit late to lament about that.
>
> For this, yes :/ But for future stuff we should really not
On Wed, 17 Oct 2018, Peter Zijlstra wrote:
> On Wed, Oct 17, 2018 at 01:17:18PM +0200, Thomas Gleixner wrote:
> > On Wed, 17 Oct 2018, Peter Zijlstra wrote:
> > > On Wed, Oct 17, 2018 at 09:54:38AM +, David Laight wrote:
> > > > >* We should perform an IPI and flush all tlbs,
> > > > >
On Wed, 17 Oct 2018, Peter Zijlstra wrote:
> On Wed, Oct 17, 2018 at 01:17:18PM +0200, Thomas Gleixner wrote:
> > On Wed, 17 Oct 2018, Peter Zijlstra wrote:
> > > On Wed, Oct 17, 2018 at 09:54:38AM +, David Laight wrote:
> > > > >* We should perform an IPI and flush all tlbs,
> > > > >
On Wed, Oct 17, 2018 at 01:17:18PM +0200, Thomas Gleixner wrote:
> On Wed, 17 Oct 2018, Peter Zijlstra wrote:
> > On Wed, Oct 17, 2018 at 09:54:38AM +, David Laight wrote:
> > > > * We should perform an IPI and flush all tlbs,
> > > > * but that can deadlock->flush only
On Wed, Oct 17, 2018 at 01:17:18PM +0200, Thomas Gleixner wrote:
> On Wed, 17 Oct 2018, Peter Zijlstra wrote:
> > On Wed, Oct 17, 2018 at 09:54:38AM +, David Laight wrote:
> > > > * We should perform an IPI and flush all tlbs,
> > > > * but that can deadlock->flush only
On 2018-10-17 11:45:59 [+], David Laight wrote:
> Right, so it should be disabled before the CR3 reload and enabled after?
It was before commit decab0888e6e1 ("x86/mm: Remove
preempt_disable/enable() from __native_flush_tlb()") then it was lifted
to the caller.
> David
Sebastian
On 2018-10-17 11:45:59 [+], David Laight wrote:
> Right, so it should be disabled before the CR3 reload and enabled after?
It was before commit decab0888e6e1 ("x86/mm: Remove
preempt_disable/enable() from __native_flush_tlb()") then it was lifted
to the caller.
> David
Sebastian
From: 'Sebastian Andrzej Siewior'
> Sent: 17 October 2018 11:39
> On 2018-10-17 09:54:38 [+], David Laight wrote:
> > Can it make any sense to flush the tlb with preemption enabled?
> it might. Usually it is disabled for other reasons.
That's what I mean, it should be disabled by the caller.
From: 'Sebastian Andrzej Siewior'
> Sent: 17 October 2018 11:39
> On 2018-10-17 09:54:38 [+], David Laight wrote:
> > Can it make any sense to flush the tlb with preemption enabled?
> it might. Usually it is disabled for other reasons.
That's what I mean, it should be disabled by the caller.
On Wed, 17 Oct 2018, Peter Zijlstra wrote:
> On Wed, Oct 17, 2018 at 09:54:38AM +, David Laight wrote:
> > >* We should perform an IPI and flush all tlbs,
> > >* but that can deadlock->flush only current cpu:
> > >*/
> > > + preempt_disable();
> > > __flush_tlb_all();
> > > +
On Wed, 17 Oct 2018, Peter Zijlstra wrote:
> On Wed, Oct 17, 2018 at 09:54:38AM +, David Laight wrote:
> > >* We should perform an IPI and flush all tlbs,
> > >* but that can deadlock->flush only current cpu:
> > >*/
> > > + preempt_disable();
> > > __flush_tlb_all();
> > > +
On Wed, Oct 17, 2018 at 09:54:38AM +, David Laight wrote:
> From: Sebastian Andrzej Siewior
> > Sent: 16 October 2018 21:25
> > I've seen the WARN_ON_ONCE(__read_cr3() != build_cr3()) in
> > switch_mm_irqs_off() every once in a while during a snapshotted system
> > upgrade.
> > I also saw the
On Wed, Oct 17, 2018 at 09:54:38AM +, David Laight wrote:
> From: Sebastian Andrzej Siewior
> > Sent: 16 October 2018 21:25
> > I've seen the WARN_ON_ONCE(__read_cr3() != build_cr3()) in
> > switch_mm_irqs_off() every once in a while during a snapshotted system
> > upgrade.
> > I also saw the
On 2018-10-17 09:54:38 [+], David Laight wrote:
> Can it make any sense to flush the tlb with preemption enabled?
it might. Usually it is disabled for other reasons.
> Surely preemption must be disabled over something else as well?
In this case it is due to the CR3 reload. I don't see
On 2018-10-17 09:54:38 [+], David Laight wrote:
> Can it make any sense to flush the tlb with preemption enabled?
it might. Usually it is disabled for other reasons.
> Surely preemption must be disabled over something else as well?
In this case it is due to the CR3 reload. I don't see
From: Sebastian Andrzej Siewior
> Sent: 16 October 2018 21:25
> I've seen the WARN_ON_ONCE(__read_cr3() != build_cr3()) in
> switch_mm_irqs_off() every once in a while during a snapshotted system
> upgrade.
> I also saw the warning early during which was introduced in commit
> decab0888e6e
From: Sebastian Andrzej Siewior
> Sent: 16 October 2018 21:25
> I've seen the WARN_ON_ONCE(__read_cr3() != build_cr3()) in
> switch_mm_irqs_off() every once in a while during a snapshotted system
> upgrade.
> I also saw the warning early during which was introduced in commit
> decab0888e6e
On Tue, Oct 16, 2018 at 2:39 PM Sebastian Andrzej Siewior
wrote:
>
> On 2018-10-16 14:25:07 [-0700], Andy Lutomirski wrote:
> > > diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> > > index 51a5a69ecac9f..fe6b21f0a6631 100644
> > > --- a/arch/x86/mm/pageattr.c
> > > +++
On Tue, Oct 16, 2018 at 2:39 PM Sebastian Andrzej Siewior
wrote:
>
> On 2018-10-16 14:25:07 [-0700], Andy Lutomirski wrote:
> > > diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> > > index 51a5a69ecac9f..fe6b21f0a6631 100644
> > > --- a/arch/x86/mm/pageattr.c
> > > +++
On 2018-10-16 14:25:07 [-0700], Andy Lutomirski wrote:
> > diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> > index 51a5a69ecac9f..fe6b21f0a6631 100644
> > --- a/arch/x86/mm/pageattr.c
> > +++ b/arch/x86/mm/pageattr.c
> > @@ -2088,7 +2088,9 @@ void __kernel_map_pages(struct page
On 2018-10-16 14:25:07 [-0700], Andy Lutomirski wrote:
> > diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> > index 51a5a69ecac9f..fe6b21f0a6631 100644
> > --- a/arch/x86/mm/pageattr.c
> > +++ b/arch/x86/mm/pageattr.c
> > @@ -2088,7 +2088,9 @@ void __kernel_map_pages(struct page
On Tue, Oct 16, 2018 at 1:25 PM Sebastian Andrzej Siewior
wrote:
>
> I've seen the WARN_ON_ONCE(__read_cr3() != build_cr3()) in
> switch_mm_irqs_off() every once in a while during a snapshotted system
> upgrade.
> I also saw the warning early during which was introduced in commit
> decab0888e6e
On Tue, Oct 16, 2018 at 1:25 PM Sebastian Andrzej Siewior
wrote:
>
> I've seen the WARN_ON_ONCE(__read_cr3() != build_cr3()) in
> switch_mm_irqs_off() every once in a while during a snapshotted system
> upgrade.
> I also saw the warning early during which was introduced in commit
> decab0888e6e
26 matches
Mail list logo
