On Thu, Feb 26, 2015 at 7:21 AM, Andy Lutomirski wrote:
> On Thu, Feb 26, 2015 at 3:42 AM, Ingo Molnar wrote:
>>
>> * Andy Lutomirski wrote:
>>
>>> >> I added that in and applied this patch.
>>> >
>>> > So this is not just slightly buggy, it's fundamentally
>>> > wrong as well as it removes the
On Thu, Feb 26, 2015 at 3:42 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> >> I added that in and applied this patch.
>> >
>> > So this is not just slightly buggy, it's fundamentally
>> > wrong as well as it removes the possibility of an RSP
>> > value optimization from the 64-bit
* Andy Lutomirski wrote:
> >> I added that in and applied this patch.
> >
> > So this is not just slightly buggy, it's fundamentally
> > wrong as well as it removes the possibility of an RSP
> > value optimization from the 64-bit path, see my
> > previous mail.
>
> This is just trying to
On Thu, Feb 26, 2015 at 3:42 AM, Ingo Molnar mi...@kernel.org wrote:
* Andy Lutomirski l...@amacapital.net wrote:
I added that in and applied this patch.
So this is not just slightly buggy, it's fundamentally
wrong as well as it removes the possibility of an RSP
value optimization
On Thu, Feb 26, 2015 at 7:21 AM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Feb 26, 2015 at 3:42 AM, Ingo Molnar mi...@kernel.org wrote:
* Andy Lutomirski l...@amacapital.net wrote:
I added that in and applied this patch.
So this is not just slightly buggy, it's fundamentally
* Andy Lutomirski l...@amacapital.net wrote:
I added that in and applied this patch.
So this is not just slightly buggy, it's fundamentally
wrong as well as it removes the possibility of an RSP
value optimization from the 64-bit path, see my
previous mail.
This is just trying
On Wed, Feb 25, 2015 at 1:45 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> - BUG_ON(((current_stack_pointer() ^
>> this_cpu_read_stable(kernel_stack))
>> + BUG_ON(((current_stack_pointer() ^
>> +(this_cpu_read_stable(kernel_stack) - 1))
>>
* Denys Vlasenko wrote:
> > The decision on how exactly we should fix
> > KERNEL_STACK_OFFSET (set it to SIZEOF_PTREGS or to
> > zero) depends on whether we switch to using PUSHes, or
> > not. What do you think?
Yes.
> A data point. I implemented push-based creation of
> pt_regs and
On 02/25/2015 01:48 PM, Denys Vlasenko wrote:
> On Wed, Feb 25, 2015 at 9:53 AM, Ingo Molnar wrote:
>> But the fix should be to not touch RSP in SAVE_ARGS, to
>> keep percpu::kernel_stack as an optimized entry point -
>> with KERNEL_STACK_OFFSET pointing to.
>>
>> So NAK - this should be fixed
On Wed, Feb 25, 2015 at 9:53 AM, Ingo Molnar wrote:
>
> * Denys Vlasenko wrote:
>
>> PER_CPU_VAR(kernel_stack) was set up in a way where it
>> points five stack slots below the top of stack.
>>
>> Presumably, it was done to avoid one "sub $5*8,%rsp" in
>> syscall/sysenter code paths, where iret
* Andy Lutomirski wrote:
> - BUG_ON(((current_stack_pointer() ^ this_cpu_read_stable(kernel_stack))
> + BUG_ON(((current_stack_pointer() ^
> +(this_cpu_read_stable(kernel_stack) - 1))
> & ~(THREAD_SIZE - 1)) != 0);
>
>
* Denys Vlasenko wrote:
> PER_CPU_VAR(kernel_stack) was set up in a way where it
> points five stack slots below the top of stack.
>
> Presumably, it was done to avoid one "sub $5*8,%rsp" in
> syscall/sysenter code paths, where iret frame needs to be
> created by hand.
>
> Ironically, none
* Denys Vlasenko dvlas...@redhat.com wrote:
The decision on how exactly we should fix
KERNEL_STACK_OFFSET (set it to SIZEOF_PTREGS or to
zero) depends on whether we switch to using PUSHes, or
not. What do you think?
Yes.
A data point. I implemented push-based creation of
pt_regs
On Wed, Feb 25, 2015 at 9:53 AM, Ingo Molnar mi...@kernel.org wrote:
* Denys Vlasenko dvlas...@redhat.com wrote:
PER_CPU_VAR(kernel_stack) was set up in a way where it
points five stack slots below the top of stack.
Presumably, it was done to avoid one sub $5*8,%rsp in
syscall/sysenter
On 02/25/2015 01:48 PM, Denys Vlasenko wrote:
On Wed, Feb 25, 2015 at 9:53 AM, Ingo Molnar mi...@kernel.org wrote:
But the fix should be to not touch RSP in SAVE_ARGS, to
keep percpu::kernel_stack as an optimized entry point -
with KERNEL_STACK_OFFSET pointing to.
So NAK - this should be
On Wed, Feb 25, 2015 at 1:45 AM, Ingo Molnar mi...@kernel.org wrote:
* Andy Lutomirski l...@amacapital.net wrote:
- BUG_ON(((current_stack_pointer() ^
this_cpu_read_stable(kernel_stack))
+ BUG_ON(((current_stack_pointer() ^
+(this_cpu_read_stable(kernel_stack) -
* Andy Lutomirski l...@amacapital.net wrote:
- BUG_ON(((current_stack_pointer() ^ this_cpu_read_stable(kernel_stack))
+ BUG_ON(((current_stack_pointer() ^
+(this_cpu_read_stable(kernel_stack) - 1))
~(THREAD_SIZE - 1)) != 0);
* Denys Vlasenko dvlas...@redhat.com wrote:
PER_CPU_VAR(kernel_stack) was set up in a way where it
points five stack slots below the top of stack.
Presumably, it was done to avoid one sub $5*8,%rsp in
syscall/sysenter code paths, where iret frame needs to be
created by hand.
On Tue, Feb 24, 2015 at 10:51 AM, Denys Vlasenko wrote:
> PER_CPU_VAR(kernel_stack) was set up in a way where it points
> five stack slots below the top of stack.
>
> Presumably, it was done to avoid one "sub $5*8,%rsp"
> in syscall/sysenter code paths, where iret frame needs to be
> created by
On 02/24/2015 08:30 PM, Steven Rostedt wrote:
> On Tue, 24 Feb 2015 19:51:33 +0100
> Denys Vlasenko wrote:
>
>> PER_CPU_VAR(kernel_stack) was set up in a way where it points
>> five stack slots below the top of stack.
>>
>> Presumably, it was done to avoid one "sub $5*8,%rsp"
>> in
On Tue, 24 Feb 2015 19:51:33 +0100
Denys Vlasenko wrote:
> PER_CPU_VAR(kernel_stack) was set up in a way where it points
> five stack slots below the top of stack.
>
> Presumably, it was done to avoid one "sub $5*8,%rsp"
> in syscall/sysenter code paths, where iret frame needs to be
> created
PER_CPU_VAR(kernel_stack) was set up in a way where it points
five stack slots below the top of stack.
Presumably, it was done to avoid one "sub $5*8,%rsp"
in syscall/sysenter code paths, where iret frame needs to be
created by hand.
Ironically, none of them benefit from this optimization,
since
On 02/24/2015 08:30 PM, Steven Rostedt wrote:
On Tue, 24 Feb 2015 19:51:33 +0100
Denys Vlasenko dvlas...@redhat.com wrote:
PER_CPU_VAR(kernel_stack) was set up in a way where it points
five stack slots below the top of stack.
Presumably, it was done to avoid one sub $5*8,%rsp
in
PER_CPU_VAR(kernel_stack) was set up in a way where it points
five stack slots below the top of stack.
Presumably, it was done to avoid one sub $5*8,%rsp
in syscall/sysenter code paths, where iret frame needs to be
created by hand.
Ironically, none of them benefit from this optimization,
since
On Tue, 24 Feb 2015 19:51:33 +0100
Denys Vlasenko dvlas...@redhat.com wrote:
PER_CPU_VAR(kernel_stack) was set up in a way where it points
five stack slots below the top of stack.
Presumably, it was done to avoid one sub $5*8,%rsp
in syscall/sysenter code paths, where iret frame needs to be
On Tue, Feb 24, 2015 at 10:51 AM, Denys Vlasenko dvlas...@redhat.com wrote:
PER_CPU_VAR(kernel_stack) was set up in a way where it points
five stack slots below the top of stack.
Presumably, it was done to avoid one sub $5*8,%rsp
in syscall/sysenter code paths, where iret frame needs to be
26 matches
Mail list logo
