On Thu, 21 Feb 2019, Linus Torvalds wrote:
> On Thu, Feb 21, 2019 at 1:35 PM Thomas Gleixner wrote:
> >
> > IMNSHO any call inside a AC region is a bug lurking round the corner. The
> > only thing which is tolerable is an exception of some sort.
> >
> > Enforce that with objtool. End of story.
>
On Thu, Feb 21, 2019 at 02:08:11PM -0800, Linus Torvalds wrote:
> On Thu, Feb 21, 2019 at 1:35 PM Thomas Gleixner wrote:
> >
> > IMNSHO any call inside a AC region is a bug lurking round the corner. The
> > only thing which is tolerable is an exception of some sort.
> >
> > Enforce that with objto
On Thu, Feb 21, 2019 at 1:35 PM Thomas Gleixner wrote:
>
> IMNSHO any call inside a AC region is a bug lurking round the corner. The
> only thing which is tolerable is an exception of some sort.
>
> Enforce that with objtool. End of story.
Not quite that simple.
There are some use cases where yo
> On Feb 21, 2019, at 4:46 AM, Will Deacon wrote:
>
>> On Wed, Feb 20, 2019 at 02:55:59PM -0800, H. Peter Anvin wrote:
>>> On 2/19/19 4:48 AM, Will Deacon wrote:
>>>
>>> I think you'll still hate this, but could we not disable preemption during
>>> the uaccess-enabled region, re-enabling it
On Thu, 21 Feb 2019, Julien Thierry wrote:
> On 20/02/2019 22:55, H. Peter Anvin wrote:
> > Now, __fentry__ is kind of a special beast; in some ways it is an "exception
> > implemented as a function call"; on x86 one could even consider using an INT
> > instruction in order to reduce the NOP footpr
On Wed, Feb 20, 2019 at 02:55:59PM -0800, H. Peter Anvin wrote:
> On 2/19/19 4:48 AM, Will Deacon wrote:
> >
> > I think you'll still hate this, but could we not disable preemption during
> > the uaccess-enabled region, re-enabling it on the fault path after we've
> > toggled uaccess off and disab
On 20/02/2019 22:55, H. Peter Anvin wrote:
> On 2/19/19 4:48 AM, Will Deacon wrote:
>>
>> I think you'll still hate this, but could we not disable preemption during
>> the uaccess-enabled region, re-enabling it on the fault path after we've
>> toggled uaccess off and disable it again when we ret
On 2/19/19 4:48 AM, Will Deacon wrote:
>
> I think you'll still hate this, but could we not disable preemption during
> the uaccess-enabled region, re-enabling it on the fault path after we've
> toggled uaccess off and disable it again when we return back to the
> uaccess-enabled region? Doesn't h
On Tue, Feb 19, 2019 at 10:04:09AM +0100, Peter Zijlstra wrote:
> On Mon, Feb 18, 2019 at 02:30:21PM -0800, H. Peter Anvin wrote:
> > On 2/16/19 2:30 AM, Peter Zijlstra wrote:
> > > On Fri, Feb 15, 2019 at 08:06:56PM -0800, h...@zytor.com wrote:
> > >> This implies we invoke schedule -- a restricte
On Tue, Feb 19, 2019 at 12:38:42PM +0100, Thomas Gleixner wrote:
> On Tue, 19 Feb 2019, Peter Zijlstra wrote:
>
> > On Tue, Feb 19, 2019 at 10:04:09AM +0100, Peter Zijlstra wrote:
> > > > Does that make more sense?
> > >
> > > It appears to me you're going about it backwards.
> >
> > So how abou
On Tue, 19 Feb 2019, Peter Zijlstra wrote:
> On Tue, Feb 19, 2019 at 10:04:09AM +0100, Peter Zijlstra wrote:
> > > Does that make more sense?
> >
> > It appears to me you're going about it backwards.
>
> So how about you do a GCC plugin that verifies limits on code-gen
> between user_access_begi
On Tue, Feb 19, 2019 at 10:04:09AM +0100, Peter Zijlstra wrote:
> > Does that make more sense?
>
> It appears to me you're going about it backwards.
So how about you do a GCC plugin that verifies limits on code-gen
between user_access_begin/user_access_end() ?
- No CALL/RET
- implies user_ac
On February 19, 2019 1:04:09 AM PST, Peter Zijlstra
wrote:
>On Mon, Feb 18, 2019 at 02:30:21PM -0800, H. Peter Anvin wrote:
>> On 2/16/19 2:30 AM, Peter Zijlstra wrote:
>> > On Fri, Feb 15, 2019 at 08:06:56PM -0800, h...@zytor.com wrote:
>> >> This implies we invoke schedule -- a restricted opera
On Tue, Feb 19, 2019 at 10:15:25AM +0100, Peter Zijlstra wrote:
> On Mon, Feb 18, 2019 at 04:24:30PM -0800, Linus Torvalds wrote:
> > On Mon, Feb 18, 2019 at 2:31 PM H. Peter Anvin wrote:
> > >
> > > The question is what "fix it" means. I'm really concerned about AC
> > > escapes,
> > > and every
On Mon, Feb 18, 2019 at 04:24:30PM -0800, Linus Torvalds wrote:
> On Mon, Feb 18, 2019 at 2:31 PM H. Peter Anvin wrote:
> >
> > The question is what "fix it" means. I'm really concerned about AC escapes,
> > and everyone else should be, too.
>
> I do think that it might be the right thing to do t
On 19/02/2019 02:46, H. Peter Anvin wrote:
> On 2/18/19 6:20 PM, Andy Lutomirski wrote:
>>
>>
>>> On Feb 18, 2019, at 4:24 PM, Linus Torvalds
>>> wrote:
>>>
On Mon, Feb 18, 2019 at 2:31 PM H. Peter Anvin wrote:
The question is what "fix it" means. I'm really concerned about AC
On Mon, Feb 18, 2019 at 02:30:21PM -0800, H. Peter Anvin wrote:
> On 2/16/19 2:30 AM, Peter Zijlstra wrote:
> > On Fri, Feb 15, 2019 at 08:06:56PM -0800, h...@zytor.com wrote:
> >> This implies we invoke schedule -- a restricted operation (consider
> >> may_sleep) during execution of STAC-enabled c
On 19/02/2019 00:24, Linus Torvalds wrote:
> On Mon, Feb 18, 2019 at 2:31 PM H. Peter Anvin wrote:
>>
>> The question is what "fix it" means. I'm really concerned about AC escapes,
>> and everyone else should be, too.
>
> I do think that it might be the right thing to do to add some kind of
>
On 2/18/19 6:20 PM, Andy Lutomirski wrote:
>
>
>> On Feb 18, 2019, at 4:24 PM, Linus Torvalds
>> wrote:
>>
>>> On Mon, Feb 18, 2019 at 2:31 PM H. Peter Anvin wrote:
>>>
>>> The question is what "fix it" means. I'm really concerned about AC escapes,
>>> and everyone else should be, too.
>>
>> I
> On Feb 18, 2019, at 4:24 PM, Linus Torvalds
> wrote:
>
>> On Mon, Feb 18, 2019 at 2:31 PM H. Peter Anvin wrote:
>>
>> The question is what "fix it" means. I'm really concerned about AC escapes,
>> and everyone else should be, too.
>
> I do think that it might be the right thing to do to
On Mon, Feb 18, 2019 at 2:31 PM H. Peter Anvin wrote:
>
> The question is what "fix it" means. I'm really concerned about AC escapes,
> and everyone else should be, too.
I do think that it might be the right thing to do to add some kind of
WARN_ON_ONCE() for AC being set in various can-reschedule
On 2/16/19 2:30 AM, Peter Zijlstra wrote:
> On Fri, Feb 15, 2019 at 08:06:56PM -0800, h...@zytor.com wrote:
>> This implies we invoke schedule -- a restricted operation (consider
>> may_sleep) during execution of STAC-enabled code, but *not* as an
>> exception or interrupt, since those preserve the
On Fri, Feb 15, 2019 at 04:21:46PM -0800, Linus Torvalds wrote:
> Even just a comment about it would be fine. But it might also be good
> to show that it's an explicit eflags value and just use
> X86_EFLAGS_FIXED as the initializer.
That is in fact what I have now; I'll repost on Monday or so.
On Fri, Feb 15, 2019 at 08:06:56PM -0800, h...@zytor.com wrote:
> This implies we invoke schedule -- a restricted operation (consider
> may_sleep) during execution of STAC-enabled code, but *not* as an
> exception or interrupt, since those preserve the flags.
Meet preempt_enable().
> I have serio
On February 14, 2019 2:14:29 AM PST, Peter Zijlstra
wrote:
>On Wed, Feb 13, 2019 at 02:49:47PM -0800, Andy Lutomirski wrote:
>
>> Do we need to backport this thing?
>
>Possibly, just to be safe.
>
>> The problem can’t be too widespread or we would have heard of it
>before.
>
>Yes, so far we've be
On Fri, Feb 15, 2019 at 3:34 PM Peter Zijlstra wrote:
>
> Now, EFLAGS bit 1 is supposedly always 1, but it really doesn't seem to
> matter for POPF.
Correct, it's "read as 1", you can try to write it and it doesn't matter.
> I went through the other flags, and aside from VIP/VIF (I've no clue),
On Fri, Feb 15, 2019 at 06:40:34PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 15, 2019 at 09:18:00AM -0800, Linus Torvalds wrote:
> > On Thu, Feb 14, 2019 at 11:34 AM Peter Zijlstra
> > wrote:
> > >
> > > Something like the below, right?
> > >
> > > + frame->flags = 0;
> > > + frame->
> On Feb 15, 2019, at 9:40 AM, Peter Zijlstra wrote:
>
>> On Fri, Feb 15, 2019 at 09:18:00AM -0800, Linus Torvalds wrote:
>>> On Thu, Feb 14, 2019 at 11:34 AM Peter Zijlstra
>>> wrote:
>>>
>>> Something like the below, right?
>>>
>>> + frame->flags = 0;
>>> + frame->flags = 0;
On Fri, Feb 15, 2019 at 09:18:00AM -0800, Linus Torvalds wrote:
> On Thu, Feb 14, 2019 at 11:34 AM Peter Zijlstra wrote:
> >
> > Something like the below, right?
> >
> > + frame->flags = 0;
> > + frame->flags = 0;
>
> Those are not valid flag values.
>
> Can you popf them? Yes.
>
>
On Thu, Feb 14, 2019 at 11:34 AM Peter Zijlstra wrote:
>
> Something like the below, right?
>
> + frame->flags = 0;
> + frame->flags = 0;
Those are not valid flag values.
Can you popf them? Yes.
Do they make sense? No.
It has the IF flag clear, for example. Is that intentional? If
On Thu, Feb 14, 2019 at 2:34 PM Peter Zijlstra wrote:
>
> On Thu, Feb 14, 2019 at 11:18:01AM -0500, Brian Gerst wrote:
>
> > > --- a/arch/x86/include/asm/switch_to.h
> > > +++ b/arch/x86/include/asm/switch_to.h
> > > @@ -40,6 +40,7 @@ asmlinkage void ret_from_fork(void);
> > > * order of the fie
On Thu, Feb 14, 2019 at 11:18:01AM -0500, Brian Gerst wrote:
> > --- a/arch/x86/include/asm/switch_to.h
> > +++ b/arch/x86/include/asm/switch_to.h
> > @@ -40,6 +40,7 @@ asmlinkage void ret_from_fork(void);
> > * order of the fields must match the code in __switch_to_asm().
> > */
> > struct i
On Thu, Feb 14, 2019 at 5:14 AM Peter Zijlstra wrote:
>
> On Wed, Feb 13, 2019 at 02:49:47PM -0800, Andy Lutomirski wrote:
>
> > Do we need to backport this thing?
>
> Possibly, just to be safe.
>
> > The problem can’t be too widespread or we would have heard of it before.
>
> Yes, so far we've be
33 matches
Mail list logo
