On Thu, 26 Feb 2015 12:47:03 +0100
Ingo Molnar wrote:
> The bona fide removal of a real instruction from a true hot
> path is generally always worth doing, you don't even have
> to 'prove' that it improves things: unless the claim is
> that for some really robust reason the instruction was ze
On Thu, 26 Feb 2015 12:47:03 +0100
Ingo Molnar wrote:
> So the main question here is not whether it's worth doing
> it, the question is the cost of the removal:
>
> - the change in syscall number overflow handling
> behavior. (We might not want the new behavior)
>
> - the increase in t
* Steven Rostedt wrote:
> > That would require a branch insn. The whole idea of
> > masking was merely to avoid that branch. If you need a
> > branch, then you can as well just retain current code.
>
> I'm just curious, do all these micro optimizations have
> any real impact on real use case
On Wed, Feb 25, 2015 at 11:01:29AM -0500, Steven Rostedt wrote:
> I'm just curious, do all these micro optimizations have any real impact
> on real use cases?
>
> That is, if we are going to make the system less robust, shouldn't we
> show that it has real benefit?
I'm wondering the same thing th
On Wed, 25 Feb 2015 16:40:49 +0100
Denys Vlasenko wrote:
> >> The downside would be that if we ever grow past 1024
> >> syscall entries we'll be in trouble if new userspace calls
> >> syscall 513 on an old kernel and gets syscall 1.
> >
> > What if we test against ~0x3ff and jump to sys_ni if any
On Wed, Feb 25, 2015 at 3:43 PM, Steven Rostedt wrote:
> On Wed, 25 Feb 2015 10:20:43 +0100 Ingo Molnar wrote:
>> But, if we do that, we can do even better, and also do an
>> optimization of the 64-bit entry path as well: we could
>> simply mask RAX with 0x3ff and not do a compare. Pad the
>> sys
On Wed, 25 Feb 2015 10:20:43 +0100
Ingo Molnar wrote:
> But, if we do that, we can do even better, and also do an
> optimization of the 64-bit entry path as well: we could
> simply mask RAX with 0x3ff and not do a compare. Pad the
> syscall table up to 0x400 (1024) entries and fill in the
>
* H. Peter Anvin wrote:
> > So could we just zap the high 32 bits of RAX early in
> > the entry code, and then from that point on we could
> > both use 32-bit ops and won't have to remember the
> > possibility either?
>
> We do that, [...]
Ok, indeed, so in ia32_sysenter_target() we have:
On 02/25/2015 01:20 AM, Ingo Molnar wrote:
I think the fundamental fragility is that we allow the high
32 bits to be nonzero.
So could we just zap the high 32 bits of RAX early in the
entry code, and then from that point on we could both use
32-bit ops and won't have to remember the possibility
* H. Peter Anvin wrote:
> On 02/24/2015 02:25 PM, Andy Lutomirski wrote:
> > On Tue, Feb 24, 2015 at 10:51 AM, Denys Vlasenko
> > wrote:
> >>
> >> In all three 32-bit entry points, %eax is
> >> zero-extended to %rax. It is safe to do 32-bit compare
> >> when checking that syscall# is not too
On Wed, Feb 25, 2015 at 12:03 AM, Andy Lutomirski wrote:
>> Actually this part should have been broken up. The word "several" in
>> the patch description is by itself a cause to NAK the patch.
>
> Point taken.
>
> Denys, can you fix this and send a v2 of the entire series with the
> traps.c fix a
On Tue, Feb 24, 2015 at 3:01 PM, H. Peter Anvin wrote:
> On 02/24/2015 02:56 PM, Andy Lutomirski wrote:
>> On Tue, Feb 24, 2015 at 2:52 PM, H. Peter Anvin wrote:
>>> On 02/24/2015 02:25 PM, Andy Lutomirski wrote:
On Tue, Feb 24, 2015 at 10:51 AM, Denys Vlasenko
wrote:
> In all thr
On 02/24/2015 02:56 PM, Andy Lutomirski wrote:
> On Tue, Feb 24, 2015 at 2:52 PM, H. Peter Anvin wrote:
>> On 02/24/2015 02:25 PM, Andy Lutomirski wrote:
>>> On Tue, Feb 24, 2015 at 10:51 AM, Denys Vlasenko
>>> wrote:
In all three 32-bit entry points, %eax is zero-extended to %rax.
It
On Tue, Feb 24, 2015 at 2:52 PM, H. Peter Anvin wrote:
> On 02/24/2015 02:25 PM, Andy Lutomirski wrote:
>> On Tue, Feb 24, 2015 at 10:51 AM, Denys Vlasenko wrote:
>>> In all three 32-bit entry points, %eax is zero-extended to %rax.
>>> It is safe to do 32-bit compare when checking that syscall#
>
On 02/24/2015 02:25 PM, Andy Lutomirski wrote:
> On Tue, Feb 24, 2015 at 10:51 AM, Denys Vlasenko wrote:
>> In all three 32-bit entry points, %eax is zero-extended to %rax.
>> It is safe to do 32-bit compare when checking that syscall#
>> is not too large.
>
> Applied. Thanks!
>
NAK NAK NAK NA
On 02/24/2015 12:36 PM, Borislav Petkov wrote:
> On Tue, Feb 24, 2015 at 09:13:03PM +0100, Denys Vlasenko wrote:
>> They aren't equal. $1 and $2 in two lowest bits will also
>> be interpreted as "userspace" here. "Equal to $3" sends
>> a wrong message here to a human reading the code,
>> the code
On Tue, Feb 24, 2015 at 10:51 AM, Denys Vlasenko wrote:
> In all three 32-bit entry points, %eax is zero-extended to %rax.
> It is safe to do 32-bit compare when checking that syscall#
> is not too large.
Applied. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Tue, Feb 24, 2015 at 09:13:03PM +0100, Denys Vlasenko wrote:
> They aren't equal. $1 and $2 in two lowest bits will also
> be interpreted as "userspace" here. "Equal to $3" sends
> a wrong message here to a human reading the code,
> the code doesn't test for CPL=3, it tests for any nonzero CPL.
On Tue, Feb 24, 2015 at 8:58 PM, Borislav Petkov wrote:
> On Tue, Feb 24, 2015 at 07:51:32PM +0100, Denys Vlasenko wrote:
>> In all three 32-bit entry points, %eax is zero-extended to %rax.
>> It is safe to do 32-bit compare when checking that syscall#
>> is not too large.
>>
>> The last instance
On Tue, Feb 24, 2015 at 07:51:32PM +0100, Denys Vlasenko wrote:
> In all three 32-bit entry points, %eax is zero-extended to %rax.
> It is safe to do 32-bit compare when checking that syscall#
> is not too large.
>
> The last instance of "mysterious" SS+8 constant is replaced by SIZEOF_PTREGS.
>
In all three 32-bit entry points, %eax is zero-extended to %rax.
It is safe to do 32-bit compare when checking that syscall#
is not too large.
The last instance of "mysterious" SS+8 constant is replaced by SIZEOF_PTREGS.
The $AUDIT_ARCH_X86_64 parameter to syscall_trace_enter_phase1/2
is a 32-bit
21 matches
Mail list logo
