>>> On 11.04.15 at 01:05, wrote:
>> One might argue that this code serves no purpose, but it's there, so
>> we had better keep our per-invocation usage of DEBUG_STACK within 4k.
>
> Only if you run NKLD. I doubt KDB or GDB support nesting.
> We can ask Jan if he still uses it.
I didn't have the
On Fri, Apr 10, 2015 at 4:18 PM, Andi Kleen wrote:
> On Fri, Apr 10, 2015 at 04:15:39PM -0700, Andy Lutomirski wrote:
>> On Fri, Apr 10, 2015 at 4:05 PM, Andi Kleen wrote:
>> >> One might argue that this code serves no purpose, but it's there, so
>> >> we had better keep our per-invocation usage
On Fri, Apr 10, 2015 at 04:15:39PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 10, 2015 at 4:05 PM, Andi Kleen wrote:
> >> One might argue that this code serves no purpose, but it's there, so
> >> we had better keep our per-invocation usage of DEBUG_STACK within 4k.
> >
> > Only if you run NKLD. I
On Fri, Apr 10, 2015 at 4:05 PM, Andi Kleen wrote:
>> One might argue that this code serves no purpose, but it's there, so
>> we had better keep our per-invocation usage of DEBUG_STACK within 4k.
>
> Only if you run NKLD. I doubt KDB or GDB support nesting.
> We can ask Jan if he still uses it.
Y
On Sat, Apr 11, 2015 at 01:05:46AM +0200, Andi Kleen wrote:
> > One might argue that this code serves no purpose, but it's there, so
> > we had better keep our per-invocation usage of DEBUG_STACK within 4k.
>
> Only if you run NKLD. I doubt KDB or GDB support nesting.
> We can ask Jan if he still
> One might argue that this code serves no purpose, but it's there, so
> we had better keep our per-invocation usage of DEBUG_STACK within 4k.
Only if you run NKLD. I doubt KDB or GDB support nesting.
We can ask Jan if he still uses it.
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
On Fri, Apr 10, 2015 at 3:52 PM, Andi Kleen wrote:
>> I think all of this stems from unfortunate naming. DEBUG_STACK isn't
>> one stack -- it's a debug stack *array*. The IST shift mechanism
>> means that we can use different entries in that array as our stacks
>> depending on how deeply nested
> I think all of this stems from unfortunate naming. DEBUG_STACK isn't
> one stack -- it's a debug stack *array*. The IST shift mechanism
> means that we can use different entries in that array as our stacks
> depending on how deeply nested we are.
It's not. It was always intended as one stack.
On Fri, Apr 10, 2015 at 1:57 PM, Andi Kleen wrote:
>> I think all of this stems from unfortunate naming. DEBUG_STACK isn't
>> one stack -- it's a debug stack *array*. The IST shift mechanism
>> means that we can use different entries in that array as our stacks
>> depending on how deeply nested
> I think all of this stems from unfortunate naming. DEBUG_STACK isn't
> one stack -- it's a debug stack *array*. The IST shift mechanism
> means that we can use different entries in that array as our stacks
> depending on how deeply nested we are.
I still think it's a terrible idea.
> > Just h
On Fri, Apr 10, 2015 at 01:52:05PM -0700, Andi Kleen wrote:
> I don't think that macro works jumps that are patched in
> (and probably should have never been added because of that)
-ENOPARSE.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from th
On Fri, Apr 10, 2015 at 10:25:42PM +0200, Borislav Petkov wrote:
> On Fri, Apr 10, 2015 at 01:21:32PM -0700, Andi Kleen wrote:
> > > Is there some reason that the normal ALTERNATIVE macro can't be used here?
> >
> > This is assembler, not C.
>
> He's talking about the ALTERNATIVE asm macro in alt
On Fri, Apr 10, 2015 at 1:41 PM, Andi Kleen wrote:
>> It wouldn't take any additional memory at all. Currently we have 8k
>> of "debug" stack which is really two 4k pieces, and you're putting the
>> kernel gs base in the bottom word. I'm suggesting that you duplicate
>> the kernel gs base at the
> It wouldn't take any additional memory at all. Currently we have 8k
> of "debug" stack which is really two 4k pieces, and you're putting the
> kernel gs base in the bottom word. I'm suggesting that you duplicate
> the kernel gs base at the bottom work and the bottom word + 4k. We
> already hav
On Fri, Apr 10, 2015 at 1:21 PM, Andi Kleen wrote:
>> We never run paranoid_exit if we interrupted userspace, and we can't
>> context switch on the IST stack, so I don't see how this is possible.
>>
>> > - Restore from R15 (with FSGSBASE), if the gs base was saved
>> > in R15
>>
>> What about case
On Fri, Apr 10, 2015 at 01:21:32PM -0700, Andi Kleen wrote:
> > Is there some reason that the normal ALTERNATIVE macro can't be used here?
>
> This is assembler, not C.
He's talking about the ALTERNATIVE asm macro in alternative-asm.h in
tip/master now. No open coded crap.
--
Regards/Gruss,
> We never run paranoid_exit if we interrupted userspace, and we can't
> context switch on the IST stack, so I don't see how this is possible.
>
> > - Restore from R15 (with FSGSBASE), if the gs base was saved
> > in R15
>
> What about case 4: we interrupted the kernel with usergs? (The code
> s
On Tue, Nov 11, 2014 at 12:05 PM, Andy Lutomirski wrote:
> On 11/10/2014 03:55 PM, Andi Kleen wrote:
>> To prevent recursive interrupts clobbering this
>> state in the task_struct this is only done for interrupts
>> coming directly from ring 3.
>
> Since this just came up in a different context to
On 11/10/2014 03:55 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> Introduction:
>
> IvyBridge added four new instructions to directly write the fs and gs
> 64bit base registers. Previously this had to be done with a system
> call to write to MSRs. The main use case is fast user space threading
>
From: Andi Kleen
Introduction:
IvyBridge added four new instructions to directly write the fs and gs
64bit base registers. Previously this had to be done with a system
call to write to MSRs. The main use case is fast user space threading
and switching the fs/gs registers quickly there. Another u
From: Andi Kleen
Introduction:
IvyBridge added four new instructions to directly write the fs and gs
64bit base registers. Previously this had to be done with a system
call to write to MSRs. The main use case is fast user space threading
and switching the fs/gs registers quickly there. Another u
21 matches
Mail list logo
