2019-11-06 22:47:16

by Joe Lawrence

[permalink] [raw]
Subject: [PATCH] x86/stacktrace: update kconfig help text for reliable unwinders

commit 6415b38bae26 ("x86/stacktrace: Enable HAVE_RELIABLE_STACKTRACE
for the ORC unwinder") marked the ORC unwinder as a "reliable" unwinder.
Update the help text to reflect that change: the frame pointer unwinder
is no longer the only one that provides HAVE_RELIABLE_STACKTRACE.

Signed-off-by: Joe Lawrence <[email protected]>
---
arch/x86/Kconfig.debug | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index bf9cd83de777..69cdf0558c13 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -316,10 +316,6 @@ config UNWINDER_FRAME_POINTER
unwinder, but the kernel text size will grow by ~3% and the kernel's
overall performance will degrade by roughly 5-10%.

- This option is recommended if you want to use the livepatch
- consistency model, as this is currently the only way to get a
- reliable stack trace (CONFIG_HAVE_RELIABLE_STACKTRACE).
-
config UNWINDER_GUESS
bool "Guess unwinder"
depends on EXPERT
@@ -333,6 +329,10 @@ config UNWINDER_GUESS
useful in many cases. Unlike the other unwinders, it has no runtime
overhead.

+ This option is not recommended if you want to use the livepatch
+ consistency model, as this unwinder cannot guarantee reliable stack
+ traces.
+
endchoice

config FRAME_POINTER
--
2.21.0


2019-11-06 23:09:10

by Josh Poimboeuf

[permalink] [raw]
Subject: Re: [PATCH] x86/stacktrace: update kconfig help text for reliable unwinders

On Wed, Nov 06, 2019 at 05:43:44PM -0500, Joe Lawrence wrote:
> commit 6415b38bae26 ("x86/stacktrace: Enable HAVE_RELIABLE_STACKTRACE
> for the ORC unwinder") marked the ORC unwinder as a "reliable" unwinder.
> Update the help text to reflect that change: the frame pointer unwinder
> is no longer the only one that provides HAVE_RELIABLE_STACKTRACE.
>
> Signed-off-by: Joe Lawrence <[email protected]>
> ---
> arch/x86/Kconfig.debug | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
> index bf9cd83de777..69cdf0558c13 100644
> --- a/arch/x86/Kconfig.debug
> +++ b/arch/x86/Kconfig.debug
> @@ -316,10 +316,6 @@ config UNWINDER_FRAME_POINTER
> unwinder, but the kernel text size will grow by ~3% and the kernel's
> overall performance will degrade by roughly 5-10%.
>
> - This option is recommended if you want to use the livepatch
> - consistency model, as this is currently the only way to get a
> - reliable stack trace (CONFIG_HAVE_RELIABLE_STACKTRACE).
> -
> config UNWINDER_GUESS
> bool "Guess unwinder"
> depends on EXPERT
> @@ -333,6 +329,10 @@ config UNWINDER_GUESS
> useful in many cases. Unlike the other unwinders, it has no runtime
> overhead.
>
> + This option is not recommended if you want to use the livepatch
> + consistency model, as this unwinder cannot guarantee reliable stack
> + traces.
> +

I'm not sure whether this last hunk is helpful. At the very least the
wording of "not recommended" might be confusing because it's not even
possible to combine UNWINDER_GUESS+HAVE_RELIABLE_STACKTRACE.

arch/x86/Kconfig: select HAVE_RELIABLE_STACKTRACE if X86_64 && (UNWINDER_FRAME_POINTER || UNWINDER_ORC) && STACK_VALIDATION

--
Josh

2019-11-06 23:19:40

by Joe Lawrence

[permalink] [raw]
Subject: Re: [PATCH] x86/stacktrace: update kconfig help text for reliable unwinders

On 11/6/19 6:05 PM, Josh Poimboeuf wrote:
> On Wed, Nov 06, 2019 at 05:43:44PM -0500, Joe Lawrence wrote:
>> commit 6415b38bae26 ("x86/stacktrace: Enable HAVE_RELIABLE_STACKTRACE
>> for the ORC unwinder") marked the ORC unwinder as a "reliable" unwinder.
>> Update the help text to reflect that change: the frame pointer unwinder
>> is no longer the only one that provides HAVE_RELIABLE_STACKTRACE.
>>
>> Signed-off-by: Joe Lawrence <[email protected]>
>> ---
>> arch/x86/Kconfig.debug | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
>> index bf9cd83de777..69cdf0558c13 100644
>> --- a/arch/x86/Kconfig.debug
>> +++ b/arch/x86/Kconfig.debug
>> @@ -316,10 +316,6 @@ config UNWINDER_FRAME_POINTER
>> unwinder, but the kernel text size will grow by ~3% and the kernel's
>> overall performance will degrade by roughly 5-10%.
>>
>> - This option is recommended if you want to use the livepatch
>> - consistency model, as this is currently the only way to get a
>> - reliable stack trace (CONFIG_HAVE_RELIABLE_STACKTRACE).
>> -
>> config UNWINDER_GUESS
>> bool "Guess unwinder"
>> depends on EXPERT
>> @@ -333,6 +329,10 @@ config UNWINDER_GUESS
>> useful in many cases. Unlike the other unwinders, it has no runtime
>> overhead.
>>
>> + This option is not recommended if you want to use the livepatch
>> + consistency model, as this unwinder cannot guarantee reliable stack
>> + traces.
>> +
>
> I'm not sure whether this last hunk is helpful. At the very least the
> wording of "not recommended" might be confusing because it's not even
> possible to combine UNWINDER_GUESS+HAVE_RELIABLE_STACKTRACE.
>
> arch/x86/Kconfig: select HAVE_RELIABLE_STACKTRACE if X86_64 && (UNWINDER_FRAME_POINTER || UNWINDER_ORC) && STACK_VALIDATION
>

Ah good point. The alternative would be to copy the recommended note to
both UNWINDER_FRAME_POINTER and UNWINDER_ORC, or at least remove the
"only" phrasing. I dunno, nobody has noticed it yet, so maybe the first
hunk would be good enough.

-- Joe

2019-11-06 23:56:19

by Josh Poimboeuf

[permalink] [raw]
Subject: Re: [PATCH] x86/stacktrace: update kconfig help text for reliable unwinders

On Wed, Nov 06, 2019 at 06:16:28PM -0500, Joe Lawrence wrote:
> On 11/6/19 6:05 PM, Josh Poimboeuf wrote:
> > On Wed, Nov 06, 2019 at 05:43:44PM -0500, Joe Lawrence wrote:
> > > commit 6415b38bae26 ("x86/stacktrace: Enable HAVE_RELIABLE_STACKTRACE
> > > for the ORC unwinder") marked the ORC unwinder as a "reliable" unwinder.
> > > Update the help text to reflect that change: the frame pointer unwinder
> > > is no longer the only one that provides HAVE_RELIABLE_STACKTRACE.
> > >
> > > Signed-off-by: Joe Lawrence <[email protected]>
> > > ---
> > > arch/x86/Kconfig.debug | 8 ++++----
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
> > > index bf9cd83de777..69cdf0558c13 100644
> > > --- a/arch/x86/Kconfig.debug
> > > +++ b/arch/x86/Kconfig.debug
> > > @@ -316,10 +316,6 @@ config UNWINDER_FRAME_POINTER
> > > unwinder, but the kernel text size will grow by ~3% and the kernel's
> > > overall performance will degrade by roughly 5-10%.
> > > - This option is recommended if you want to use the livepatch
> > > - consistency model, as this is currently the only way to get a
> > > - reliable stack trace (CONFIG_HAVE_RELIABLE_STACKTRACE).
> > > -
> > > config UNWINDER_GUESS
> > > bool "Guess unwinder"
> > > depends on EXPERT
> > > @@ -333,6 +329,10 @@ config UNWINDER_GUESS
> > > useful in many cases. Unlike the other unwinders, it has no runtime
> > > overhead.
> > > + This option is not recommended if you want to use the livepatch
> > > + consistency model, as this unwinder cannot guarantee reliable stack
> > > + traces.
> > > +
> >
> > I'm not sure whether this last hunk is helpful. At the very least the
> > wording of "not recommended" might be confusing because it's not even
> > possible to combine UNWINDER_GUESS+HAVE_RELIABLE_STACKTRACE.
> >
> > arch/x86/Kconfig: select HAVE_RELIABLE_STACKTRACE if X86_64 && (UNWINDER_FRAME_POINTER || UNWINDER_ORC) && STACK_VALIDATION
> >
>
> Ah good point. The alternative would be to copy the recommended note to
> both UNWINDER_FRAME_POINTER and UNWINDER_ORC, or at least remove the "only"
> phrasing. I dunno, nobody has noticed it yet, so maybe the first hunk would
> be good enough.

The guess unwinder is listed as an expert option, so the user would have
to enable CONFIG_EXPERT to get to it. Then if they do enable it and try
to load a livepatch, they'll get a runtime warning along with a patch
which never transitions.

And like you said, nobody has complained, so I'd say just dropping the
2nd hunk would be fine.

--
Josh