Ingo Molnar writes:
>
> Especially on modern x86 CPUs with stack engines (latest Intel and AMD
> CPUs) that keeps ESP updates out of the later stages of execution
> pipelines, going from RBP framepointers to direct ESP use is
> beneficial to performance and compresses I$ footprint as well:
Not
On Fri, May 22, 2015 at 09:32:12AM -0500, Josh Poimboeuf wrote:
> If instead the above code were patched into a non-leaf function, we'd
> have to change it to restore the frame pointer before returning.
Not a problem, I think. One'll need to add the FP restoring before the
retq.
--
Regards/Gruss
On Fri, May 22, 2015 at 11:18:57PM +0200, Jiri Kosina wrote:
> On Fri, 22 May 2015, Josh Poimboeuf wrote:
>
> > Hm, alternatives do complicate things a bit. It *is* a false positive,
> > but not necessarily because its part of an alternative instruction
> > block.
> >
> > The above code would be
On Fri, 22 May 2015, Josh Poimboeuf wrote:
> Hm, alternatives do complicate things a bit. It *is* a false positive,
> but not necessarily because its part of an alternative instruction
> block.
>
> The above code would be patched into memmove(), which is a leaf function
> because it doesn't call
On Thu, May 21, 2015 at 02:53:07PM -0700, Andy Lutomirski wrote:
> On Thu, May 21, 2015 at 1:54 PM, Josh Poimboeuf wrote:
> > After removing the frame pointer checks for leaf functions, and adding a
> > check for all functions which jump outside of their scope, the number of
> > defconfig warnings
On Fri, May 22, 2015 at 12:01:58AM +0200, Borislav Petkov wrote:
> On Thu, May 21, 2015 at 03:54:25PM -0500, Josh Poimboeuf wrote:
> > stackvalidate: arch/x86/lib/memmove_64.o: return instruction outside of a
> > function at .altinstr_replacement+0x5
>
> That must be something like this:
>
> 000
On Thu, May 21, 2015 at 03:54:25PM -0500, Josh Poimboeuf wrote:
> stackvalidate: arch/x86/lib/memmove_64.o: return instruction outside of a
> function at .altinstr_replacement+0x5
That must be something like this:
<.altinstr_replacement>:
0: 48 89 d1mov%
On Thu, May 21, 2015 at 1:54 PM, Josh Poimboeuf wrote:
> On Wed, May 20, 2015 at 04:48:10PM +0200, Ingo Molnar wrote:
>> Yeah, so many of these seem to be 'leaf only' functions: functions
>> that don't ever call functions themselves.
>>
>> So lets assume we always have CONFIG_FRAME_POINTERS=y.
>>
On Wed, May 20, 2015 at 04:48:10PM +0200, Ingo Molnar wrote:
> Yeah, so many of these seem to be 'leaf only' functions: functions
> that don't ever call functions themselves.
>
> So lets assume we always have CONFIG_FRAME_POINTERS=y.
>
> If they don't set up a frame pointer then they in essence
* Ingo Molnar wrote:
> Especially on modern x86 CPUs with stack engines (latest Intel and
> AMD CPUs) that keeps ESP updates out of the later stages of
> execution pipelines, going from RBP framepointers to direct ESP use
> is beneficial to performance and compresses I$ footprint as well:
>
* Borislav Petkov wrote:
> On Thu, May 21, 2015 at 12:16:14PM +0200, Ingo Molnar wrote:
> > So this is how we are printing backtraces on x86:
>
>
>
> This is pretty useful info and the question about the '?' keeps popping
> up.
>
> How about I moved Documentation/x86/x86_64/kernel-stacks to
On Thu, May 21, 2015 at 12:16:14PM +0200, Ingo Molnar wrote:
> So this is how we are printing backtraces on x86:
This is pretty useful info and the question about the '?' keeps popping
up.
How about I moved Documentation/x86/x86_64/kernel-stacks to
Documentation/x86/kernel-stacks and added that
* Josh Poimboeuf wrote:
> On Wed, May 20, 2015 at 09:59:18AM -0700, Linus Torvalds wrote:
> > On Wed, May 20, 2015 at 9:25 AM, Josh Poimboeuf wrote:
> > > On Wed, May 20, 2015 at 09:03:37AM -0700, Andy Lutomirski wrote:
> > >>
> > >> I've never quite understood what the '?' means.
> > >
> > > I
* Borislav Petkov wrote:
> On Wed, May 20, 2015 at 11:25:37AM -0500, Josh Poimboeuf wrote:
> > > I've never quite understood what the '?' means.
> >
> > It basically means "here's a function address we found on the stack,
> > which may or may not have been called." It's needed because stack
>
* Linus Torvalds wrote:
> On Wed, May 20, 2015 at 9:25 AM, Josh Poimboeuf wrote:
> > On Wed, May 20, 2015 at 09:03:37AM -0700, Andy Lutomirski wrote:
> >>
> >> I've never quite understood what the '?' means.
> >
> > It basically means "here's a function address we found on the
> > stack, which
On Wed, 20 May 2015, Peter Zijlstra wrote:
> > I think it would be nice to have full DWARF unwind support for
> > everything at some point. Unfortunately, I don't see any easy path to
> > getting there. It doesn't help that AFAIK no one has ever proposed a
> > usable in-kernel DWARF unwinder.
>
On Wed, May 20, 2015 at 09:03:37AM -0700, Andy Lutomirski wrote:
> I think it would be nice to have full DWARF unwind support for
> everything at some point. Unfortunately, I don't see any easy path to
> getting there. It doesn't help that AFAIK no one has ever proposed a
> usable in-kernel DWARF
On Wed, May 20, 2015 at 09:59:18AM -0700, Linus Torvalds wrote:
> On Wed, May 20, 2015 at 9:25 AM, Josh Poimboeuf wrote:
> > On Wed, May 20, 2015 at 09:03:37AM -0700, Andy Lutomirski wrote:
> >>
> >> I've never quite understood what the '?' means.
> >
> > It basically means "here's a function addr
On Wed, May 20, 2015 at 9:25 AM, Josh Poimboeuf wrote:
> On Wed, May 20, 2015 at 09:03:37AM -0700, Andy Lutomirski wrote:
>>
>> I've never quite understood what the '?' means.
>
> It basically means "here's a function address we found on the stack,
> which may or may not have been called." It's n
On Wed, May 20, 2015 at 11:25:37AM -0500, Josh Poimboeuf wrote:
> > I've never quite understood what the '?' means.
>
> It basically means "here's a function address we found on the stack,
> which may or may not have been called." It's needed because stack
> walking isn't currently 100% reliable.
On Wed, May 20, 2015 at 9:25 AM, Josh Poimboeuf wrote:
> On Wed, May 20, 2015 at 09:03:37AM -0700, Andy Lutomirski wrote:
>> On Wed, May 20, 2015 at 7:48 AM, Ingo Molnar wrote:
>> > Yeah, so many of these seem to be 'leaf only' functions: functions
>> > that don't ever call functions themselves.
On Wed, May 20, 2015 at 09:03:37AM -0700, Andy Lutomirski wrote:
> On Wed, May 20, 2015 at 7:48 AM, Ingo Molnar wrote:
> > Yeah, so many of these seem to be 'leaf only' functions: functions
> > that don't ever call functions themselves.
> >
> > So lets assume we always have CONFIG_FRAME_POINTERS=y
On Wed, May 20, 2015 at 10:51:56AM -0500, Josh Poimboeuf wrote:
> On Wed, May 20, 2015 at 04:48:10PM +0200, Ingo Molnar wrote:
> > Yeah, so many of these seem to be 'leaf only' functions: functions
> > that don't ever call functions themselves.
>
> Yeah, good observation.
>
> > So lets assume we
On Wed, May 20, 2015 at 7:48 AM, Ingo Molnar wrote:
>
> * Josh Poimboeuf wrote:
>
>> On Wed, May 20, 2015 at 12:33:39PM +0200, Ingo Molnar wrote:
>> >
>> > * Josh Poimboeuf wrote:
>> >
>> > > In discussions around the live kernel patching consistency model RFC
>> > > [1], Peter and Ingo correctl
On Wed, May 20, 2015 at 04:48:10PM +0200, Ingo Molnar wrote:
>
> * Josh Poimboeuf wrote:
>
> > On Wed, May 20, 2015 at 12:33:39PM +0200, Ingo Molnar wrote:
> > >
> > > * Josh Poimboeuf wrote:
> > >
> > > > In discussions around the live kernel patching consistency model RFC
> > > > [1], Peter
* Josh Poimboeuf wrote:
> On Wed, May 20, 2015 at 12:33:39PM +0200, Ingo Molnar wrote:
> >
> > * Josh Poimboeuf wrote:
> >
> > > In discussions around the live kernel patching consistency model RFC
> > > [1], Peter and Ingo correctly pointed out that stack traces aren't
> > > reliable. And a
On Wed, May 20, 2015 at 12:33:39PM +0200, Ingo Molnar wrote:
>
> * Josh Poimboeuf wrote:
>
> > In discussions around the live kernel patching consistency model RFC
> > [1], Peter and Ingo correctly pointed out that stack traces aren't
> > reliable. And as Ingo said, there's no "strong force" wh
* Josh Poimboeuf wrote:
> In discussions around the live kernel patching consistency model RFC
> [1], Peter and Ingo correctly pointed out that stack traces aren't
> reliable. And as Ingo said, there's no "strong force" which ensures we
> can rely on them.
>
> So I've been thinking about how t
28 matches
Mail list logo
