lkml.org 
[lkml]   [2023]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: [PATCH v8 30/33] x86/fred: allow dynamic stack frame size
On June 6, 2023 6:27:25 AM PDT, Thomas Gleixner <tglx@linutronix.de> wrote:
>On Tue, Jun 06 2023 at 06:18, Xin3 Li wrote:
>>> > A FRED stack frame could contain different amount of information for
>>> > This approach also works for IDT, thus we unify the code.
>>>
>>> And thereby remove the useful comment and replace it with an undocumented
>>> macro mess.
>>>
>>> I'm simply refusing to review this. It's not my job to understand this
>>> undocumented hackery.
>>>
>>
>> I believe it's a nice idea to allow dynamic stack frame size, at least for
>> FRED.
>
>Believe belongs in the realm of religion. What we need here are proper
>facts, explanations and justifications. Nice ideas are not helpful when
>they are not having a value.
>
>> It's totally my bad that I didn't make it meet the minimum standards,
>> I will rewrite the commit message and add better comments.
>>
>> After a second thought, I probably should only apply the change to FRED for
>> 2 reasons, the change seems problematic with ESPFIX (which FRED
>> doesn't need),
>
>Indeed. Making this FRED only is going to need even more justification.
>
>> and such corner cases are hard to test (self-tests needed?)
>
>There is a test. It's not that hard to find:
>
># git grep -li ESPFIX tools/testing/selftests/
>tools/testing/selftests/x86/sigreturn.c
>
>Thanks,
>
> tglx

For what it is worth, I am working on a FRED forward compatibly document at the moment.

\
 
 \ /
  Last update: 2023-06-07 01:09    [W:0.084 / U:0.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site