Thread (25 messages) 25 messages, 9 authors, 2021-11-25

Re: [PATCH 20/22] x86,word-at-a-time: Remove .fixup usage

From: Petr Mladek <pmladek@suse.com>
Date: 2021-11-25 08:20:14
Also in: linux-toolchains, live-patching, lkml

On Wed 2021-11-24 09:42:13, Josh Poimboeuf wrote:
On Mon, Nov 22, 2021 at 06:46:44PM +0100, Petr Mladek wrote:
quoted
On Thu 2021-11-11 17:50:03, Josh Poimboeuf wrote:
quoted
On Wed, Nov 10, 2021 at 12:20:47PM +0000, David Laight wrote:
quoted
quoted
quoted
Wouldn't moving part of a function to .text.cold (or .text.unlikely)
generate the same problems with the stack backtrace code as the
.text.fixup section you are removing had??
GCC can already split a function into func and func.cold today (or
worse: func, func.isra.N, func.cold, func.isra.N.cold etc..).

I'm assuming reliable unwind and livepatch know how to deal with this.
They'll have 'proper' function labels at the top - so backtrace
stands a chance.
Indeed you (probably) want it to output "func.irsa.n.cold" rather
than just "func" to help show which copy it is in.  > 
I guess that livepatch will need separate patches for each
version of the function - which might be 'interesting' if
all the copies actually need patching at the same time.
You'd certainly want a warning if there seemed to be multiple
copies of the function.
Hm, I think there is actually a livepatch problem here.

If the .cold (aka "child") function actually had a fentry hook then we'd
be fine.  Then we could just patch both "parent" and "child" functions
at the same time.  We already have the ability to patch multiple
functions having dependent interface changes.

But there's no fentry hook in the child, so we can only patch the
parent.

If the child schedules out, and then the parent gets patched, things can
go off-script if the child later jumps back to the unpatched version of
the parent, and then for example the old parent tries to call another
patched function with a since-changed ABI.
This thread seems to be motivation for the patchset
https://lore.kernel.org/all/20211119090327.12811-1-mbenes@suse.cz/ (local)
I am trying to understand the problem here, first. And I am
a bit lost.

How exactly is child called in the above scenario, please?
How could parent get livepatched when child is sleeping?

I imagine it the following way:

    parent_func()
       fentry

       /* some parent code */
       jmp child
	   /* child code */
	   jmp back_to_parent
       /* more parent code */
       ret
Right.
quoted
In the above example, parent_func() would be on stack and could not
get livepatched even when the process is sleeping in the child code.

The livepatching is done via ftrace. Only code with fentry could be
livepatched. And code called via fentry must be visible on stack.
How would parent_func() be on the stack?  If it jumps to the child then
it leaves no trace on the stack.
Grr, sure. It was off-by-one error on my side. /o\

Thanks for explanation.

Best Regards,
Petr
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help