On Sun, Mar 8, 2015 at 6:59 AM, Andy Lutomirski wrote:
> There's another problem, though: We don't have a real stack pointer
> just after syscall and just before sysexit, and therefore we *must*
> use IST for anything that can happen while we still have
> user-controlled rsp. That includes #DB,
On Mar 8, 2015 4:55 AM, "Ingo Molnar" wrote:
>
>
> * Linus Torvalds wrote:
>
> > On Sat, Mar 7, 2015 at 2:36 AM, Ingo Molnar wrote:
> > >
> > > We could save the same 10 cycles from page fault overhead as well,
> > > AFAICS.
> >
> > Are trap gates actually noticeably faster? Or is it just he
> >
* Ingo Molnar wrote:
> Doing that would give us four (theoretical) performance advantages:
>
> - No implicit irq disabling overhead when the syscall instruction is
> executed: we could change MSR_SYSCALL_MASK from 0xc084 to
> 0xc284, which removes the implicit CLI on syscall e
* Linus Torvalds wrote:
> On Sat, Mar 7, 2015 at 2:36 AM, Ingo Molnar wrote:
> >
> > We could save the same 10 cycles from page fault overhead as well,
> > AFAICS.
>
> Are trap gates actually noticeably faster? Or is it just he
> "conditional_sti()" you're worried about?
( I'll talk about the
On Sat, Mar 7, 2015 at 2:36 AM, Ingo Molnar wrote:
>
> We could save the same 10 cycles from page fault overhead as well,
> AFAICS.
Are trap gates actually noticeably faster? Or is it just he
"conditional_sti()" you're worried about?
Anyway, for page faulting, we traditionally actually wanted an
* Andy Lutomirski wrote:
> On Fri, Mar 6, 2015 at 2:00 PM, Linus Torvalds
> wrote:
> > On Fri, Mar 6, 2015 at 11:23 AM, Andy Lutomirski
> > wrote:
> >>
> >> Please don't. IMO it's really nice that we don't use trap gates at
> >> all on x86_64, and I find the conditional_sti thing much nicer
* Linus Torvalds wrote:
> On Thu, Mar 5, 2015 at 11:58 PM, Ingo Molnar wrote:
> >
> > math_state_restore() was historically called with irqs disabled,
> > because that's how the hardware generates the trap, and also because
> > back in the days it was possible for it to be an asynchronous
> > i
On Fri, Mar 6, 2015 at 2:00 PM, Linus Torvalds
wrote:
> On Fri, Mar 6, 2015 at 11:23 AM, Andy Lutomirski wrote:
>>
>> Please don't. IMO it's really nice that we don't use trap gates at
>> all on x86_64, and I find the conditional_sti thing much nicer than
>> having to audit all of the entry code
On Fri, Mar 6, 2015 at 11:23 AM, Andy Lutomirski wrote:
>
> Please don't. IMO it's really nice that we don't use trap gates at
> all on x86_64, and I find the conditional_sti thing much nicer than
> having to audit all of the entry code to see whether it's safe to run
> it with IRQs on.
So I'm n
On Fri, Mar 6, 2015 at 9:33 AM, Linus Torvalds
wrote:
> On Thu, Mar 5, 2015 at 11:58 PM, Ingo Molnar wrote:
>>
>> math_state_restore() was historically called with irqs disabled,
>> because that's how the hardware generates the trap, and also because
>> back in the days it was possible for it to
On 03/06, Linus Torvalds wrote:
>
> On Thu, Mar 5, 2015 at 11:58 PM, Ingo Molnar wrote:
> >
> > math_state_restore() was historically called with irqs disabled,
> > because that's how the hardware generates the trap, and also because
> > back in the days it was possible for it to be an asynchronou
On Thu, Mar 5, 2015 at 11:58 PM, Ingo Molnar wrote:
>
> math_state_restore() was historically called with irqs disabled,
> because that's how the hardware generates the trap, and also because
> back in the days it was possible for it to be an asynchronous
> interrupt and interrupt handlers run wit
On 03/06, David Vrabel wrote:
>
> On 06/03/15 15:36, Oleg Nesterov wrote:
> >
> > This needs more discussion, but in short so far I think that fpu_alloc()
> > from #NM exception is fine if user_mode(regs) == T.
>
> I think a memory allocation here, where the only behaviour on a failure
> is to kill
On 06/03/15 15:36, Oleg Nesterov wrote:
> On 03/06, David Vrabel wrote:
>>
>> On 06/03/15 14:01, Oleg Nesterov wrote:
>>
>>> Not sure I understand it correctly after the first quick look, but
>>>
>>> 1. It conflicts with the recent changes in tip/x86/fpu
>>>
>>> 2. fpu_ini() initializes current->th
On 03/06, David Vrabel wrote:
>
> On 06/03/15 14:01, Oleg Nesterov wrote:
>
> > Not sure I understand it correctly after the first quick look, but
> >
> > 1. It conflicts with the recent changes in tip/x86/fpu
> >
> > 2. fpu_ini() initializes current->thread.fpu.state. This looks unneeded,
> >t
On 06/03/15 14:01, Oleg Nesterov wrote:
> On 03/06, Ingo Molnar wrote:
>>
>> * Oleg Nesterov wrote:
>>
>>> On 03/06, Ingo Molnar wrote:
* Oleg Nesterov wrote:
> [...] The patch above looks "obviously safe", but perhaps I am
> paranoid too much...
IMHO your hack ab
On 03/06, Oleg Nesterov wrote:
>
> On 03/06, Ingo Molnar wrote:
> >
> > How about the patch from David Vrabel? That seems to solve the
> > irq-disable problem too, right?
>
> I wasn't cc'ed, I guess you mean
>
> [PATCHv4] x86, fpu: remove the logic of non-eager fpu mem allocation at
> the fi
On 03/06, Ingo Molnar wrote:
>
> * Oleg Nesterov wrote:
>
> > On 03/06, Ingo Molnar wrote:
> > >
> > > * Oleg Nesterov wrote:
> > >
> > > > [...] The patch above looks "obviously safe", but perhaps I am
> > > > paranoid too much...
> > >
> > > IMHO your hack above isn't really acceptable, even fo
* Oleg Nesterov wrote:
> On 03/06, Ingo Molnar wrote:
> >
> > * Oleg Nesterov wrote:
> >
> > > [...] The patch above looks "obviously safe", but perhaps I am
> > > paranoid too much...
> >
> > IMHO your hack above isn't really acceptable, even for a backport.
> > So lets test the patch below (a
On 03/06, Oleg Nesterov wrote:
>
> OK, but please note that this patch is not beckportable. If you think
> that -stable doesn't need this fix, then I agree.
>
> If the caller is do_device_not_available(), then we can not enable
> irqs before __thread_fpu_begin() + restore_fpu_checking().
>
> 1. Pre
On 03/06, Ingo Molnar wrote:
>
> * Oleg Nesterov wrote:
>
> > [...] The patch above looks "obviously safe", but perhaps I am
> > paranoid too much...
>
> IMHO your hack above isn't really acceptable, even for a backport.
> So lets test the patch below (assuming it's the right thing to do)
> and mo
* Oleg Nesterov wrote:
> On 03/05, Ingo Molnar wrote:
> >
> > * Oleg Nesterov wrote:
> >
> > > --- a/arch/x86/kernel/traps.c
> > > +++ b/arch/x86/kernel/traps.c
> > > @@ -774,7 +774,10 @@ void math_state_restore(void)
> > > struct task_struct *tsk = current;
> > >
> > > if (!tsk_used_math(t
On 03/05, Ingo Molnar wrote:
>
> * Oleg Nesterov wrote:
>
> > --- a/arch/x86/kernel/traps.c
> > +++ b/arch/x86/kernel/traps.c
> > @@ -774,7 +774,10 @@ void math_state_restore(void)
> > struct task_struct *tsk = current;
> >
> > if (!tsk_used_math(tsk)) {
> > - local_irq_enable();
* Oleg Nesterov wrote:
> math_state_restore() assumes it is called with irqs disabled, but
> this is not true if the caller is __restore_xstate_sig().
>
> This means that if ia32_fxstate == T and __copy_from_user() fails
> __restore_xstate_sig() returns with irqs disabled too. This trgiggers
>
24 matches
Mail list logo
