* Eric Paris wrote:
> On Mon, 2014-10-27 at 10:02 -0700, H. Peter Anvin wrote:
> > On 10/27/2014 06:55 AM, Eric Paris wrote:
> > > My patch was already committed to the -tip urgent branch. I believe any
> > > optimization should be based on that branch, Richard. If you are trying
> > > to
* Eric Paris epa...@redhat.com wrote:
On Mon, 2014-10-27 at 10:02 -0700, H. Peter Anvin wrote:
On 10/27/2014 06:55 AM, Eric Paris wrote:
My patch was already committed to the -tip urgent branch. I believe any
optimization should be based on that branch, Richard. If you are trying
On 14/10/27, Thomas Gleixner wrote:
> On Mon, 27 Oct 2014, Eric Paris wrote:
> > My patch was already committed to the -tip urgent branch. I believe any
> > optimization should be based on that branch, Richard. If you are trying
> > to wrangle every bit of speed out of this, should you
> >
> >
On Mon, 27 Oct 2014, Eric Paris wrote:
> My patch was already committed to the -tip urgent branch. I believe any
> optimization should be based on that branch, Richard. If you are trying
> to wrangle every bit of speed out of this, should you
>
> push %esi;
> push %edi;
> CFI_ADJUST_CFA_OFFSET
On Mon, 2014-10-27 at 21:52 +0100, Thomas Gleixner wrote:
> On Sun, 26 Oct 2014, Richard Guy Briggs wrote:
> > diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> > index b553ed8..344b63f 100644
> > --- a/arch/x86/kernel/entry_32.S
> > +++ b/arch/x86/kernel/entry_32.S
> > @@
On Sun, 26 Oct 2014, Richard Guy Briggs wrote:
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index b553ed8..344b63f 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -447,15 +447,14 @@ sysenter_exit:
> sysenter_audit:
> testl
On 14/10/27, Eric Paris wrote:
> My patch was already committed to the -tip urgent branch. I believe any
> optimization should be based on that branch, Richard. If you are trying
> to wrangle every bit of speed out of this, should you
>
> push %esi;
> push %edi;
> CFI_ADJUST_CFA_OFFSET 8
> call
On Mon, 2014-10-27 at 10:02 -0700, H. Peter Anvin wrote:
> On 10/27/2014 06:55 AM, Eric Paris wrote:
> > My patch was already committed to the -tip urgent branch. I believe any
> > optimization should be based on that branch, Richard. If you are trying
> > to wrangle every bit of speed out of
On 10/27/2014 06:55 AM, Eric Paris wrote:
> My patch was already committed to the -tip urgent branch. I believe any
> optimization should be based on that branch, Richard. If you are trying
> to wrangle every bit of speed out of this, should you
>
> push %esi;
> push %edi;
>
My patch was already committed to the -tip urgent branch. I believe any
optimization should be based on that branch, Richard. If you are trying
to wrangle every bit of speed out of this, should you
push %esi;
push %edi;
CFI_ADJUST_CFA_OFFSET 8
call __audit_syscall_entry
pop;
pop;
My patch was already committed to the -tip urgent branch. I believe any
optimization should be based on that branch, Richard. If you are trying
to wrangle every bit of speed out of this, should you
push %esi;
push %edi;
CFI_ADJUST_CFA_OFFSET 8
call __audit_syscall_entry
pop;
pop;
On 10/27/2014 06:55 AM, Eric Paris wrote:
My patch was already committed to the -tip urgent branch. I believe any
optimization should be based on that branch, Richard. If you are trying
to wrangle every bit of speed out of this, should you
push %esi;
push %edi;
CFI_ADJUST_CFA_OFFSET 8
On Mon, 2014-10-27 at 10:02 -0700, H. Peter Anvin wrote:
On 10/27/2014 06:55 AM, Eric Paris wrote:
My patch was already committed to the -tip urgent branch. I believe any
optimization should be based on that branch, Richard. If you are trying
to wrangle every bit of speed out of this,
On 14/10/27, Eric Paris wrote:
My patch was already committed to the -tip urgent branch. I believe any
optimization should be based on that branch, Richard. If you are trying
to wrangle every bit of speed out of this, should you
push %esi;
push %edi;
CFI_ADJUST_CFA_OFFSET 8
call
On Sun, 26 Oct 2014, Richard Guy Briggs wrote:
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index b553ed8..344b63f 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -447,15 +447,14 @@ sysenter_exit:
sysenter_audit:
testl
On Mon, 2014-10-27 at 21:52 +0100, Thomas Gleixner wrote:
On Sun, 26 Oct 2014, Richard Guy Briggs wrote:
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index b553ed8..344b63f 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -447,15
On Mon, 27 Oct 2014, Eric Paris wrote:
My patch was already committed to the -tip urgent branch. I believe any
optimization should be based on that branch, Richard. If you are trying
to wrangle every bit of speed out of this, should you
push %esi;
push %edi;
CFI_ADJUST_CFA_OFFSET 8
On 14/10/27, Thomas Gleixner wrote:
On Mon, 27 Oct 2014, Eric Paris wrote:
My patch was already committed to the -tip urgent branch. I believe any
optimization should be based on that branch, Richard. If you are trying
to wrangle every bit of speed out of this, should you
push %esi;
git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb.
It was writing over %esp/pt_regs semi-randomly on i686 with the expected
"system can't boot" results. As noted in:
https://bugs.freedesktop.org/show_bug.cgi?id=85277
This patch stops fscking with pt_regs. Instead it sets
On 14/10/24, Andy Lutomirski wrote:
> On Fri, Oct 24, 2014 at 1:19 PM, H. Peter Anvin wrote:
> > On 10/23/2014 12:38 PM, Eric Paris wrote:
> >>> After the call __audit_syscall_entry aren't they already polluted?
> >>> Isn't that the reason we need to reload EAX?
> >>
> >> Well, I guess EAX is
On 14/10/23, Eric Paris wrote:
> On Thu, 2014-10-23 at 12:20 -0700, Andy Lutomirski wrote:
> > On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris wrote:
> > > On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote:
> > >> On 10/22/2014 09:04 PM, Eric Paris wrote:
> > >> > git commit
On 14/10/23, Eric Paris wrote:
On Thu, 2014-10-23 at 12:20 -0700, Andy Lutomirski wrote:
On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris epa...@redhat.com wrote:
On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote:
On 10/22/2014 09:04 PM, Eric Paris wrote:
git commit
On 14/10/24, Andy Lutomirski wrote:
On Fri, Oct 24, 2014 at 1:19 PM, H. Peter Anvin h...@zytor.com wrote:
On 10/23/2014 12:38 PM, Eric Paris wrote:
After the call __audit_syscall_entry aren't they already polluted?
Isn't that the reason we need to reload EAX?
Well, I guess EAX is
git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb.
It was writing over %esp/pt_regs semi-randomly on i686 with the expected
system can't boot results. As noted in:
https://bugs.freedesktop.org/show_bug.cgi?id=85277
This patch stops fscking with pt_regs. Instead it sets up
On Fri, Oct 24, 2014 at 1:19 PM, H. Peter Anvin wrote:
> On 10/23/2014 12:38 PM, Eric Paris wrote:
>>>
>>> After the call __audit_syscall_entry aren't they already polluted?
>>> Isn't that the reason we need to reload EAX?
>>
>> Well, I guess EAX is special...
>>
>
> Because system calls are
On 10/23/2014 12:38 PM, Eric Paris wrote:
>>
>> After the call __audit_syscall_entry aren't they already polluted?
>> Isn't that the reason we need to reload EAX?
>
> Well, I guess EAX is special...
>
Because system calls are "asmlinkage", all the parameters are on the
stack, but %eax is used
On 10/23/2014 12:38 PM, Eric Paris wrote:
After the call __audit_syscall_entry aren't they already polluted?
Isn't that the reason we need to reload EAX?
Well, I guess EAX is special...
Because system calls are asmlinkage, all the parameters are on the
stack, but %eax is used as the index
On Fri, Oct 24, 2014 at 1:19 PM, H. Peter Anvin h...@zytor.com wrote:
On 10/23/2014 12:38 PM, Eric Paris wrote:
After the call __audit_syscall_entry aren't they already polluted?
Isn't that the reason we need to reload EAX?
Well, I guess EAX is special...
Because system calls are
Yes, I will look at this tomorrow.
For the record, the calling convention is that eax, edx, ecx are clobbered, and
used for the three first arguments in that order. eax, edx are used for the
return value(s).
The exception is for __asmlinkage functions where all arguments are passed on
the
On Thu, Oct 23, 2014 at 12:30 PM, Eric Paris wrote:
> On Thu, 2014-10-23 at 12:20 -0700, Andy Lutomirski wrote:
>> On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris wrote:
>> > On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote:
>> >> On 10/22/2014 09:04 PM, Eric Paris wrote:
>> >> > git commit
On Thu, 2014-10-23 at 12:20 -0700, Andy Lutomirski wrote:
> On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris wrote:
> > On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote:
> >> On 10/22/2014 09:04 PM, Eric Paris wrote:
> >> > git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very
On Thu, 2014-10-23 at 15:30 -0400, Eric Paris wrote:
> On Thu, 2014-10-23 at 12:20 -0700, Andy Lutomirski wrote:
> > On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris wrote:
> > > On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote:
> > >> On 10/22/2014 09:04 PM, Eric Paris wrote:
> > >> > git
On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris wrote:
> On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote:
>> On 10/22/2014 09:04 PM, Eric Paris wrote:
>> > git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb.
>> > It was writing over %esp/pt_regs semi-randomly on i686
On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote:
> On 10/22/2014 09:04 PM, Eric Paris wrote:
> > git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb.
> > It was writing over %esp/pt_regs semi-randomly on i686 with the expected
> > "system can't boot" results. As noted
Well, probably not something for stable/urgent...
On October 23, 2014 11:39:48 AM PDT, Andy Lutomirski
wrote:
>On 10/22/2014 09:04 PM, Eric Paris wrote:
>> git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very
>dumb.
>> It was writing over %esp/pt_regs semi-randomly on i686 with
On 10/22/2014 09:04 PM, Eric Paris wrote:
> git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb.
> It was writing over %esp/pt_regs semi-randomly on i686 with the expected
> "system can't boot" results. As noted in:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=85277
>
>
On 10/22/2014 09:04 PM, Eric Paris wrote:
git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb.
It was writing over %esp/pt_regs semi-randomly on i686 with the expected
system can't boot results. As noted in:
https://bugs.freedesktop.org/show_bug.cgi?id=85277
This
Well, probably not something for stable/urgent...
On October 23, 2014 11:39:48 AM PDT, Andy Lutomirski l...@amacapital.net
wrote:
On 10/22/2014 09:04 PM, Eric Paris wrote:
git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very
dumb.
It was writing over %esp/pt_regs semi-randomly on
On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote:
On 10/22/2014 09:04 PM, Eric Paris wrote:
git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb.
It was writing over %esp/pt_regs semi-randomly on i686 with the expected
system can't boot results. As noted in:
On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris epa...@redhat.com wrote:
On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote:
On 10/22/2014 09:04 PM, Eric Paris wrote:
git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb.
It was writing over %esp/pt_regs semi-randomly on
On Thu, 2014-10-23 at 15:30 -0400, Eric Paris wrote:
On Thu, 2014-10-23 at 12:20 -0700, Andy Lutomirski wrote:
On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris epa...@redhat.com wrote:
On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote:
On 10/22/2014 09:04 PM, Eric Paris wrote:
git
On Thu, 2014-10-23 at 12:20 -0700, Andy Lutomirski wrote:
On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris epa...@redhat.com wrote:
On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote:
On 10/22/2014 09:04 PM, Eric Paris wrote:
git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very
On Thu, Oct 23, 2014 at 12:30 PM, Eric Paris epa...@redhat.com wrote:
On Thu, 2014-10-23 at 12:20 -0700, Andy Lutomirski wrote:
On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris epa...@redhat.com wrote:
On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote:
On 10/22/2014 09:04 PM, Eric Paris
Yes, I will look at this tomorrow.
For the record, the calling convention is that eax, edx, ecx are clobbered, and
used for the three first arguments in that order. eax, edx are used for the
return value(s).
The exception is for __asmlinkage functions where all arguments are passed on
the
git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb.
It was writing over %esp/pt_regs semi-randomly on i686 with the expected
"system can't boot" results. As noted in:
https://bugs.freedesktop.org/show_bug.cgi?id=85277
This patch stops fscking with pt_regs. Instead it sets
git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb.
It was writing over %esp/pt_regs semi-randomly on i686 with the expected
system can't boot results. As noted in:
https://bugs.freedesktop.org/show_bug.cgi?id=85277
This patch stops fscking with pt_regs. Instead it sets up
46 matches
Mail list logo