[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LSU.2.21.1905090921460.12541@pobox.suse.cz>
Date: Thu, 9 May 2019 09:24:53 +0200 (CEST)
From: Miroslav Benes <mbenes@...e.cz>
To: Josh Poimboeuf <jpoimboe@...hat.com>
cc: Petr Mladek <pmladek@...e.com>, Jiri Kosina <jikos@...nel.org>,
Joe Lawrence <joe.lawrence@...hat.com>,
Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] livepatch: Remove duplicate warning about missing
reliable stacktrace support
> > > But I think Miroslav's suggestion to revert 1d98a69e5cef would be even
> > > better.
> >
> > AFAIK, Miroslav wanted to point out that your opinion was inconsistent.
>
> How is my opinion inconsistent?
>
> Is there something wrong with the original approach, which was reverted
> with
>
> 1d98a69e5cef ("livepatch: Remove reliable stacktrace check in klp_try_switch_task()")
>
> ?
>
> As I mentioned, that has some advantages:
>
> - The generated code is simpler/faster because it uses a build-time
> check.
>
> - The code is more readable IMO. Especially if the check is done higher
> up the call stack by reverting 1d98a69e5cef. That way the arch
> support short-circuiting is done in the logical place, before doing
> any more unnecessary work. It's faster, but also, more importantly,
> it's less surprising.
Correct. I forgot we removed return from klp_enable_patch() if
klp_have_reliable_stack() errors out and we only warn now. So reverting
1d98a69e5cef definitely makes sense.
My...
"We removed it in 1d98a69e5cef ("livepatch: Remove reliable stacktrace
check in klp_try_switch_task()") and I do think it does not belong here.
We can check for the facility right at the beginning in klp_enable_patch()
and it is not necessary to do it every time klp_check_stack() is called."
...from the other email is rubbish then.
Miroslav
Powered by blists - more mailing lists