stable inclusion
from stable-5.10.42
commit 020b6b0dc7b61346e829bef3877110ba83628fb6
bugzilla: 55093
CVE: NA

--------------------------------

commit 265d1a90 upstream.

Add separate init function to call the existing controls_create
function so a custom error can be displayed if initialisation fails.

Use info level instead of error for notifications.

Display the VID/PID so device_setup is targeted to the right device.

Display "enabled" message to easily confirm that the driver is loaded.
Signed-off-by: NGeoffrey D. Bennett <g@b4.vu>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/b5d140c65f640faf2427e085fbbc0297b32e5fce.1621584566.git.g@b4.vuSigned-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.42
commit 9a75ed5103855500362d35c9107b7e78df320154
bugzilla: 55093
CVE: NA

--------------------------------

commit 764fa6e6 upstream.

Use usb_rcvctrlpipe() not usb_sndctrlpipe() for USB control input in
the Scarlett Gen 2 mixer driver. This fixes the device hang during
initialisation when used with the ehci-pci host driver.

Fixes: 9e4d5c1b ("ALSA: usb-audio: Scarlett Gen 2 mixer interface")
Signed-off-by: NGeoffrey D. Bennett <g@b4.vu>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/66a3d05dac325d5b53e4930578e143cef1f50dbe.1621584566.git.g@b4.vuSigned-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.42
commit 7b42f41dab4c5c0a2f9cd53c9b5db793cc7b2c21
bugzilla: 55093
CVE: NA

--------------------------------

commit 50dbfae9 upstream.

The HP ZBook Studio 17.3 Inch G8 is using ALC285 codec which is
using 0x04 to control mute LED and 0x01 to control micmute LED.
In the other hand, there is no output from right channel of speaker.
Therefore, add a quirk to make it works.
Signed-off-by: NJeremy Szu <jeremy.szu@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210519170357.58410-4-jeremy.szu@canonical.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.42
commit 7573b58a2d8fcb5e0f83e8fa1756ab14f3569914
bugzilla: 55093
CVE: NA

--------------------------------

commit e650c1a9 upstream.

The HP ZBook Fury 15.6 Inch G8 is using ALC285 codec which is
using 0x04 to control mute LED and 0x01 to control micmute LED.
In the other hand, there is no output from right channel of speaker.
Therefore, add a quirk to make it works.
Signed-off-by: NJeremy Szu <jeremy.szu@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210519170357.58410-3-jeremy.szu@canonical.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.42
commit b8cd7164b345a479e36dc67bdb036df7ddb19581
bugzilla: 55093
CVE: NA

--------------------------------

commit bbe183e0 upstream.

The HP ZBook Studio 15.6 Inch G8 is using ALC285 codec which is
using 0x04 to control mute LED and 0x01 to control micmute LED.
In the other hand, there is no output from right channel of speaker.
Therefore, add a quirk to make it works.
Signed-off-by: NJeremy Szu <jeremy.szu@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210519170357.58410-2-jeremy.szu@canonical.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.42
commit 8ffce2b02b4542236861fc1afbf3e4a561edbd7c
bugzilla: 55093
CVE: NA

--------------------------------

commit 0e68c4b1 upstream.

The HP EliteBook 855 G8 Notebook PC is using ALC285 codec which needs
ALC285_FIXUP_HP_MUTE_LED fixup to make it works. After applying the
fixup, the mute/micmute LEDs work good.
Signed-off-by: NJeremy Szu <jeremy.szu@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210519170357.58410-1-jeremy.szu@canonical.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.42
commit 7906018de7365995756171f3bc2a4d3208ccc66e
bugzilla: 55093
CVE: NA

--------------------------------

commit 29c8f40b upstream.

Lenovo ThinkStation P340 uses ALC623 codec (SSID 17aa:1048) and it produces
bug plock/pop noise over line out (green jack on the back) which can be
fixed by applying ALC269_FIXUP_NO_SHUTUP tot he machine.

Convert the existing entry for the same SSID to chain to apply this fixup
as well.
Suggested-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@linux.intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210524203726.2278-1-peter.ujfalusi@linux.intel.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.42
commit 2f0f8e06e7ea2325b585bc07a058932f2cc75208
bugzilla: 55093
CVE: NA

--------------------------------

commit 119b75c1 upstream.

On some ASUS and MSI machines, the audio codec is alc1220 and the
Headphone is connected to audio mixer 0xf and DAC 0x5, in theory
the Headphone volume is controlled by DAC 0x5 (Heapdhone Playback
Volume), but somehow it is controlled by DAC 0x2 (Front Playback
Volume), maybe this is a defect on the codec alc1220.

Because of this issue, the PA couldn't switch the headphone and
Lineout correctly, If we apply the quirk CLEVO_P950 to those machines,
the Lineout and Headphone will share the audio mixer 0xc and DAC 0x2,
and generate Headphone+LO mixer, then PA could handle them when
switching between them.

BugLink: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1206
Cc: <stable@vger.kernel.org>
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20210522034741.13415-1-hui.wang@canonical.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.42
commit 8ca63ce0278219b5c60d610d8caba6bda116636f
bugzilla: 55093
CVE: NA

--------------------------------

commit 9ebaef05 upstream.

The Lenovo Yoga 9i has bass speaker, but the bass speaker can't work,
that is because there is an i2s amplifier on that speaker, need to
run ideapad_s740_coef() to initialize the amplifier.

And also needs to apply ALC285_FIXUP_THINKPAD_HEADSET_JACK to rename
the speaker's mixer control name, otherwise the PA can't handle them.

BugLink: http://bugs.launchpad.net/bugs/1926165Signed-off-by: NHui Wang <hui.wang@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210522042645.14221-1-hui.wang@canonical.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 55087
CVE: NA

--------------------------------
Signed-off-by: NZheng Zucheng <zhengzucheng@huawei.com>
Reviewed-by: NChen Hui <judy.chenhui@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: 55083
CVE: NA

------------------------------------------------------------------------

Gcc flag '-fvisibility=hidden' specifies the visibility attribute for external linkage entities in object files.
You can also selectively set visibility attributes for entities by using pairs of the #pragma GCC visibility push
and #pragma GCC visibility pop compiler directives throughout your source program.when we include the hidden.h,
__bss_start and __bss_end went from global symbol to local symbol,so we need to modify the regular expression to
accommodate this change.

Fixes: 27fdadbf34d2 ("[Backport] ARM: 9056/1: decompressor: fix BSS size calculation for LLVM ld.lld")
Signed-off-by: NGaosheng Cui <cuigaosheng1@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: 51781
CVE: NA

Reference: https://lore.kernel.org/linux-mm/20210417075946.181402-1-wangkefeng.wang@huawei.com/
--------------------------------

Move HOLES_IN_ZONE into mm/Kconfig, select it if architecture needs
this feature.
Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NJing Xiangfeng <jingxiangfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.11-rc1
commit 3f4b815a
category: bugfix
bugzilla: 55077
CVE: NA

During LTP test, testcase 'move_pages12' failed. This is because
__soft_offline_page() will return -EIO when fail to migrate page.
This is not an error for 'move_pages12' but LTP treats 'return -EIO'
as an error.

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f4b815a439adfb8f238335612c4b28bc10084d8

-------------------------------------------------

Currently, we return -EIO when we fail to migrate the page.

Migrations' failures are rather transient as they can happen due to
several reasons, e.g: high page refcount bump, mapping->migrate_page
failing etc.  All meaning that at that time the page could not be
migrated, but that has nothing to do with an EIO error.

Let us return -EBUSY instead, as we do in case we failed to isolate the
page.

While are it, let us remove the "ret" print as its value does not change.

Link: https://lkml.kernel.org/r/20201209092818.30417-1-osalvador@suse.deSigned-off-by: NOscar Salvador <osalvador@suse.de>
Acked-by: NNaoya Horiguchi <naoya.horiguchi@nec.com>
Acked-by: NVlastimil Babka <vbabka@suse.cz>
Cc: David Hildenbrand <david@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NShixin Liu <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 51924
CVE: NA

---------------------------

When a livepatch is insmod, stop machine will stop other cores, which
interrupts services. Therefore, the shorter the stop machine duration,
the better. The application and release of memory from the stop machine
can shorten the time for stopping the machine.

Especially, module_alloc and module_memfree is a kind of vmalloc, that
may sleep when called. So it is not permitted to use them in stop machine
context.
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euler inclusion
category: feature
bugzilla: 51921
CVE: N/A

----------------------------------------

Some functions in the kernel are always on the stack of some
thread in the system. Attempts to patch these function will
currently always fail the activeness safety check.

However, through human inspection, it can be determined that,
for a particular function, consistency is maintained even if
the old and new versions of the function run concurrently.

commit 2e93c5e1e3dc ("support forced patching") in kpatch-build
introduces a KPATCH_FORCE_UNSAFE() macro to define patched
functions that such be exempted from the activeness safety
check. now kernel implement this feature.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NLi Bin <huawei.libin@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 51924
CVE: NA

---------------------------

We have completed support for the ppc64de livepatch, and we
can now enable it
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Nyangerkun <yangerkun@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 51924
CVE: NA

---------------------------

The previous sample use case did not consider the APC and function
descriptors of PPC64
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Nyangerkun <yangerkun@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

rtos inclusion
category: bugfix
bugzilla: 42399/46793/51924
CVE: NA

----------------------------------------

According to function _switch in entry_32/64.S, for non-current and
not-in-interrupt task, the LR is saved in the LR position in the 2nd
frame. The content in LR position in the 1st frame is not filled, so
it is left by previous stack frames and may be an address in a kernel
function, resulting in failure in applying a kernel patch even when the
target function is not actually in stack.

Therefore, we should ignore the first frame to get a more reliable
backtrace.
Signed-off-by: NLexi Shao <shaolexi@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: Nyangerkun <yangerkun@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: 34578/46793/51924
CVE: NA

-------------------------------------------------------------------------

When we make a livepatch, since we did not save the stack frame
according to the call requirementsthen, we can't see that the
caller function in the stack after the patch is activated.

At this time, if we also patch the caller function, because it's
is not seen in the stack, then this patch can be enabled normally
without being checked by the stack check.

This is very dangerous. If there are other processes running or
sleeping in the context of the first patched callee function, then
after the caller function is patched, we have changed the first few
instructions of the caller to bstub to jump directly, so the context
of the process will be destroyed, after he returns to the caller,
the wrong instruction will be executed.

The following problems can occur in our testcase:
	Unrecoverable FP Unavailable Exception 800 at 80000000000c80d8
	Oops: Unrecoverable FP Unavailable Exception, sig: 6 [#1]
	PREEMPT SMP NR_CPUS=4 QEMU e500
	Modules linked in: level2_delay_patch(O) delay_patch(O) delay(O)
	CPU: 1 PID: 328 Comm: cat Tainted: G           O  K 4.4.222 #334
	task: c0000000f02da100 task.stack: c00000007a52c000
	NIP: 80000000000c80d8 LR: 80000000000c80d8 CTR: c0000000003cef10
	REGS: c00000007a52eea0 TRAP: 0800   Tainted: G O  K  (4.4.222)
	MSR: 0000000080009000 <EE,ME>  CR: 28022882  XER: 00000000
	NIP [80000000000c80d8] .foo_show+0x18/0x48 [delay]
	LR [80000000000c80d8] .foo_show+0x18/0x48 [delay]
	Call Trace:
	[c00000007a52f120] [c00000007e015af8] 0xc00000007e015af8(unreliable)
	[c00000007a52f1a0] [c00000000032d11c].kobj_attr_show+0x2c/0x50
	[c00000007a52f210] [c000000000230b74].sysfs_kf_seq_show+0xf4/0x1d0
	[c00000007a52f2b0] [c00000000022ea2c].kernfs_seq_show+0x3c/0x50
	[c00000007a52f320] [c0000000001c1f88].seq_read+0x118/0x5c0
	[c00000007a52f420] [c00000000022fa04].kernfs_fop_read+0x194/0x240
	[c00000007a52f4c0] [c00000000018e27c].do_loop_readv_writev+0xac/0x100
	[c00000007a52f560] [c00000000018f284].do_readv_writev+0x2a4/0x2f0
	[c00000007a52f6d0] [c0000000001cf3cc].default_file_splice_read+0x22c/0x490
	[c00000007a52fa60] [c0000000001cd704].do_splice_to+0x94/0xe0
	[c00000007a52fb00] [c0000000001cd814].splice_direct_to_actor+0xc4/0x320
	[c00000007a52fbd0] [c0000000001cdb14].do_splice_direct+0xa4/0x120
	[c00000007a52fc90] [c00000000018f9fc].do_sendfile+0x27c/0x440
	[c00000007a52fd80] [c0000000001910f4].compat_SyS_sendfile64+0xe4/0x140
	[c00000007a52fe30] [c00000000000058c]system_call+0x40/0xc8
	Instruction dump:
	ebe1fff8 7c0803a6 4e800020 60000000 60000000 60000000 3d62ffff 396b7bf0
	e98b0018 7d8903a6 4e800420 73747563 <c0000000> f030a948 7fe3fb78 38a00001
	---[ end trace 07a14bdffccc341f ]---

We solve this problem by disguising the stack frame, so that the caller
function will appear in the stack, which can be detected by the stack
check, so that when the patch is enabled, it will be found

Ather this patch, when enable the second livepatch, we will find the
caller on the stack.

	livepatch_64: func .foo_show is in use!
	livepatch_64: PID: 328 Comm: cat
	Call Trace:
	[c00000007a596bd0] [c00000007a596cd0] 0xc00000007a596cd0(unreliable)
	[c00000007a596da0] [c000000000008b20].__switch_to+0x70/0xa0
	[c00000007a596e20] [c000000000557a5c].__schedule+0x2fc/0x830
	[c00000007a596ed0] [c0000000005581b8] .schedule+0x38/0xc0
	[c00000007a596f40] [c00000000055c7e8].schedule_timeout+0x148/0x210
	[c00000007a597030] [80000000000ff054].new_stack_func+0x54/0x90 [delay_patch]
	[c00000007a5970b0] [c0000000f025d67c] 0xc0000000f025d67c
	[c00000007a597120] [80000000000c80d8] .foo_show+0x18/0x48 [delay]
	[c00000007a5971a0] [c00000000032d11c].kobj_attr_show+0x2c/0x50
	[c00000007a597210] [c000000000230b74].sysfs_kf_seq_show+0xf4/0x1d0
	[c00000007a5972b0] [c00000000022ea2c].kernfs_seq_show+0x3c/0x50
	[c00000007a597320] [c0000000001c1f88].seq_read+0x118/0x5c0
	[c00000007a597420] [c00000000022fa04].kernfs_fop_read+0x194/0x240
	[c00000007a5974c0] [c00000000018e27c].do_loop_readv_writev+0xac/0x100
	[c00000007a597560] [c00000000018f284].do_readv_writev+0x2a4/0x2f0
	[c00000007a5976d0] [c0000000001cf3cc].default_file_splice_read+0x22c/0x490
	[c00000007a597a60] [c0000000001cd704].do_splice_to+0x94/0xe0
	[c00000007a597b00] [c0000000001cd814].splice_direct_to_actor+0xc4/0x320
	[c00000007a597bd0] [c0000000001cdb14].do_splice_direct+0xa4/0x120
	[c00000007a597c90] [c00000000018f9fc].do_sendfile+0x27c/0x440
	[c00000007a597d80] [c0000000001910f4].compat_SyS_sendfile64+0xe4/0x140
	[c00000007a597e30] [c00000000000058c]system_call+0x40/0xc8
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Nyangerkun <yangerkun@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 51924
CVE: NA

---------------------------

In the prev commit, we implement per func_node livepatch
trampoline. For elf abi v1, the trampoline area is also
malloced and it has no permission to execute. So we use
module_alloc to set trampoline executable.
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 51924
CVE: NA

---------------------------

We call from old func to new func, when return form new func, we
need to restore R2. The previous module relocation was by adding
an extra nop space after the call (bxxx) instruction to restore R2,
but it is impossible to use extra space here, because we will not
return after calling new func, so we need to use a trampoline space.

We will call new func in trampoline and then restore R2 when we return.
Please note that we can also use old func as trampoline as a solution,
but we are afraid that old func often does not have that much space to
store trampoline instruction fragments.

The trampoline can be implemented as global. However we need to
implement a trampoline for each function and improve its stack
check.

Our call chain to the new function looks like this:

CALLER
        old_func        |       old_func
                        |       -=> trampoline
                        |               -=> new_func

So we can't simply check that new_func, old_func and trampoline are
both possible on the stack.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Nyangerkun <yangerkun@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: 51924
CVE: NA

---------------------------

When doing consistency stack checking, if we try to patch a function
which has been patched already. We should check the new function(not
the origin func) that is activeness currently, it's always the first
entry in list func_node->func_stack.

Example :
        module : origin                 livepatch v1            livepatch v2
        func   : old func A -[enable]=> new func A' -[enable]=> new func A''
        check  :                A                       A'

when we try to patch function A to new function A'' by livepatch v2,
but the func A has already patched to function A' by livepatch v1, so
function A' which provided in livepatch v1 is active in the stack
instead of origin function A. Even if the long jump method is used, we
jump to the new function A' using a call without LR, the origin function
A will not appear in the stack. We must check the active function A' in
consistency stack checking.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Nyangerkun <yangerkun@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 51924
CVE: NA

---------------------------

The ppc64 ABI V1 function pointer points to the function descriptor,
which we use in the sample demo.

        $cat /proc/kallsyms | grep  livepatch_cmdline_proc_show
        80000000000d4830 d livepatch_cmdline_proc_show  [livepatch_sample]      -=> func descr
        80000000000d40c0 t .livepatch_cmdline_proc_show [livepatch_sample]      -=> func addr

However, the livepatch module made by kpatch just passes the address of
the function to kernel(saved in func->new_func), so the kernel needs to
obtain the toc address and combine the function descriptors to implement
long jump.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Nyangerkun <yangerkun@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 51924
CVE: NA

---------------------------

Initially completed the livepatch for ppc64be, the call from
the old function to the new function, using stub space, this
is actually problematic, because we cannot effectively recover
R2. This problem will be fixed later.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Nyangerkun <yangerkun@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

rtos inclusion
category: bugfix
bugzilla: 51924
CVE: NA

----------------------------------------

According to function _switch in entry_32/64.S, for non-current and
not-in-interrupt task, the LR is saved in the LR position in the 2nd
frame. The content in LR position in the 1st frame is not filled, so
it is left by previous stack frames and may be an address in a kernel
function, resulting in failure in applying a kernel patch even when the
target function is not actually in stack.

Therefore, we should ignore the first frame to get a more reliable
backtrace.
Signed-off-by: NLexi Shao <shaolexi@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: Nyangerkun <yangerkun@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: 51924
CVE: NA

---------------------------

When doing consistency stack checking, if we try to patch a function
which has been patched already. We should check the new function(not
the origin func) that is activeness currently, it's always the first
entry in list func_node->func_stack.

Example :
        module : origin                 livepatch v1            livepatch v2
        func   : old func A -[enable]=> new func A' -[enable]=> new func A''
        check  :                A                       A'

when we try to patch function A to new function A'' by livepatch v2,
but the func A has already patched to function A' by livepatch v1, so
function A' which provided in livepatch v1 is active in the stack
instead of origin function A. Even if the long jump method is used, we
jump to the new function A' using a call without LR, the origin function
A will not appear in the stack. We must check the active function A' in
consistency stack checking.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Nyangerkun <yangerkun@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euler inclusion
category: bugfix
bugzilla: 51924
CVE: NA

---------------------------------

We through stack checking to ensure the consistency of livepatch.
Task blocked in __switch_to when switch out, thread_saved_fs/pc
store the FP and PC when switching, it can be useful when tracing
blocked threads. For running task, current_stack_pointer can be
used, but it's difficult to backtracking the running task on other
CPUs.

Fortunately, all CPUs will stay in this function, the current's
backtrace is so similar. so just backtracking the current on this
CPU, skip the current of other CPUs.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Nzhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euler inclusion
category: feature
bugzilla: 51924
CVE: N/A

----------------------------------------

we need to modify the first 4 instructions of a livepatch function to
complete the long jump if offset out of short-range. So it's important
that this function must have more than 4 instructions, so we checked it
when the livepatch module insmod.

testcase : testEL_HOTPATCH_ADDFUNTOMULTIFILE_FUN-001
before this patch:
        insmod ./klp_patch.ko
        echo 1 > /sys/kernel/livepatch/klp_patch/enable
        echo 3 > /proc/sys/vm/drop_caches
        kernel crash, the call trace is like
        Call Trace:
                Unable to handler kernel paging request for instruction fetch
                Fualting instruction address: 0x00000000
                invalidate_mapping_pages+x0cc/0x180
                drop_pagecache_sb+0x84/0x94
                iterate_supers+0xf8/0xfc
                drop_caches_sysctl_handler+0x88/0x108
                proc_sys_call_handler+0xbc/0xfc
                __vfs_write+0x3c/0x154
                vfs_write+0xa0/0x114
                Sys_write+0x4c/0xc4
                ret_from_syscall+0x0/0x38

after this patch:
        insmod ./klp_patch.ko
                insmod: can't insert './klp_patch.ko': Operation not permitted

        dmesg -c
                livepatch: func drop_slab size(2) less than limit(4)
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NLi Bin <huawei.libin@huawei.com>
Tested-by: NCheng Jian <cj.chengjian@huawei.com>
Tested-by: NWang Feng <wangfeng59@huawei.com>
Tested-by: NLin DingYu <lindingyu@huawei.com>
Tested-by: NYang ZuoTing <yangzuoting@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Nzhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euler inclusion
category: feature
bugzilla: 51924
CVE: NA

----------------------------------------

The offset of the direct jump under PPC is 32M. Longer jumps are required
to exceed this range.

Therefore, long jumps of instruction patched when enable livepatch module
is supported here.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NLi Bin <huawei.libin@huawei.com>
Tested-by: NWang Feng <wangfeng59@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Nzhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euler inclusion
category: feature
bugzilla: 51924
CVE: NA

----------------------------------------

support livepatch without ftrace for powerpc

supported now:
	livepatch relocation when init_patch after load_module;
	instruction patched when enable;
	activeness function check;
	enforcing the patch stacking principle;

unsupport now:(will fix it feature)
	long jump (both livepatch relocation and insn patched)
	module plts request by livepatch-relocation
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NLi Bin <huawei.libin@huawei.com>
Tested-by: NWang Feng <wangfeng59@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Nzhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: 51919
CVE: NA

---------------------------

When doing consistency stack checking, if we try to patch a
function which has been patched already. We should check the
new function(not the origin func) that is activeness currently,
it's always the first entry in list func_node->func_stack.

Example :
	module : origin			livepatch v1		livepatch v2
	func   : old func A -[enable]=> new func A' -[enable]=> new func A''
	check  :		A			A'

when we try to patch function A to new function A'' by livepatch
v2, but the func A has already patched to function A' by livepatch
v1, so function A' which provided in livepatch v1 is active in the
stack instead of origin function A. Even if the long jump method is
used, we jump to the new function A' using a call without LR, the
origin function A will not appear in the stack. We must check the
active function A' in consistency stack checking.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 51919
CVE: NA

----------------------------------------

support livepatch without ftrace for x86_64

supported now:
        livepatch relocation when init_patch after load_module;
        instruction patched when enable;
	activeness function check;
	enforcing the patch stacking principle;

x86_64 use variable length instruction, so there's no need to consider
extra implementation for long jumps.
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NLi Bin <huawei.libin@huawei.com>
Tested-by: NYang ZuoTing <yangzuoting@huawei.com>
Tested-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: Nzhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 51921
CVE: NA

---------------------------

After commit d556e1be ("livepatch: Remove module_disable_ro() usage")
and commit 0d9fbf78 ("module: Remove module_disable_ro()") and
commit e6eff437 ("module: Make module_enable_ro() static again") merged,
the module_disable_ro is removed and module_enable_ro is make static.

It's ok for x86/ppc platform because the livepatch module relocation is
done by text poke func which internally modify the text addr by remap
to high virtaddr which has write permission.

However for arm/arm64 platform, it's apply_relocate[_add] still directly
modify the text code so we should change the module text permission before
relocation. Otherwise it will lead to following problem:

  Unable to handle kernel write to read-only memory at virtual address ffff800008a95288
  Mem abort info:
  ESR = 0x9600004f
  EC = 0x25: DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
  Data abort info:
  ISV = 0, ISS = 0x0000004f
  CM = 0, WnR = 1
  swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000004133c000
  [ffff800008a95288] pgd=00000000bdfff003, p4d=00000000bdfff003, pud=00000000bdffe003,
		     pmd=0000000080ce7003, pte=0040000080d5d783
  Internal error: Oops: 9600004f [#1] PREEMPT SMP
  Modules linked in: livepatch_testmod_drv(OK+) testmod_drv(O)
  CPU: 0 PID: 139 Comm: insmod Tainted: G           O  K   5.10.0-01131-gf6b4602e09b2-dirty #35
  Hardware name: linux,dummy-virt (DT)
  pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
  pc : reloc_insn_imm+0x54/0x78
  lr : reloc_insn_imm+0x50/0x78
  sp : ffff800011cf3910
  ...
  Call trace:
   reloc_insn_imm+0x54/0x78
   apply_relocate_add+0x464/0x680
   klp_apply_section_relocs+0x11c/0x148
   klp_enable_patch+0x338/0x998
   patch_init+0x338/0x1000 [livepatch_testmod_drv]
   do_one_initcall+0x60/0x1d8
   do_init_module+0x58/0x1e0
   load_module+0x1fb4/0x2688
   __do_sys_finit_module+0xc0/0x128
   __arm64_sys_finit_module+0x20/0x30
   do_el0_svc+0x84/0x1b0
   el0_svc+0x14/0x20
   el0_sync_handler+0x90/0xc8
   el0_sync+0x158/0x180
   Code: 2a0503e0 9ad42a73 97d6a499 91000673 (b90002a0)
   ---[ end trace 67dd2ef1203ed335 ]---

Though the permission change is not necessary to x86/ppc platform, consider
that the jump_label_register api may modify the text code either, we just
put the change handle here instead of putting it in arch-specific relocate.

Besides, the jump_label_module_nb callback called in jump_label_register
also maybe need motify the module code either, it sort and swap the jump
entries if necessary. So just disable ro before jump_label handling and
restore it back.
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: 51923
CVE: NA

---------------------------

When doing consistency stack checking, if we try to patch a function
which has been patched already. We should check the new function(not
the origin func) that is activeness currently, it's always the first
entry in list func_node->func_stack.

Example :
	module : origin			livepatch v1		livepatch v2
	func   : old func A -[enable]=> new func A' -[enable]=> new func A''
	check  :                A			A'

when we try to patch function A to new function A'' by livepatch v2,
but the func A has already patched to function A' by livepatch v1, so
function A' which provided in livepatch v1 is active in the stack
instead of origin function A. Even if the long jump method is used, we
jump to the new function A' using a call without LR, the origin function
A will not appear in the stack. We must check the active function A' in
consistency stack checking.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Nyangerkun <yangerkun@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euler inclusion
category: feature
bugzilla: 51923
CVE: N/A

----------------------------------------

The offset of the direct jump under ARM is 32M. Longer jumps are
required to exceed this range.

First-- long jump for relocations

If the jump address exceeds the range in these relocation, it
needs to be implemented with a long jump. but there is no
function for us to modify its first LJMP_INSN_SIZE instructions
like enable livepatch do, we should use module plts to store
the information. so we need enough PLTS to store the symbol.

The .klp.rela.objname.secname section store all symbols that required
relocate by livepatch. For commit 425595a7 ("livepatch: reuse
module loader code to write relocations") merged, load_module can
create enough plt entries for livepatch by module_frob_arch_sections.

However, the module loader only use rel section, this is will be
fixed in the next commits and need adapter kpatch-build front-tools.

Second-- long jump for call new function

We modify several instructions from the beginning of the function
to jump instructions, thus completing the jump from the old
function to the new function. Unlike the relocation information,
there is no plt sections to use here, so use the LDT instruction
to complete the long jump using the LDT instruction.

[PC+0]: ldr PC [PC+8]
[PC+4]: nop
[PC+8]: new_addr_to_jump
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NBin Li <huawei.libin@huawei.com>
Signed-off-by: Nzhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euler inclusion
category: bugfix
bugzilla: 51923
CVE: NA

---------------------------------

We through stack checking to ensure the consistency of livepatch.
Task blocked in __switch_to when switch out, thread_saved_fs/pc
store the FP and PC when switching, it can be useful when tracing
blocked threads. For running task, __builtin_frame_address can be
used, but it's difficult to backtracking the running task on other
CPUs.

Fortunately, all CPUs will stay in this function, the current's
backtrace is so similar. so just backtracking the current on this
CPU, skip the current of other CPUs.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Nzhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euler inclusion
category: feature
bugzilla: 51923
CVE: N/A

----------------------------------------

support livepatch without ftrace for ARM

supported now:
        livepatch relocation when init_patch after load_module;
	instruction patched when enable;
	activeness function check;
	enforcing the patch stacking principle;

unsupport now:(willn't fix it feature)
	long jump (both livepatch relocation and insn patched)
	module plts request by livepatch-relocation

Because CONFIG_ARM_MODULE_PLTS will be not set in ARM, so we needn't
long jump and livepatch plts.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NLi Bin <huawei.libin@huawei.com>
Tested-by: NCheng Jian <cj.chengjian@huawei.com>
Tested-by: NWang Feng <wangfeng59@huawei.com>
Tested-by: NLin DingYu <lindingyu@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Nzhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 51923
CVE: NA

---------------------------

In the older version of livepatch implementation without ftrace on
arm, it use klp_relocs and do special relocation for klp syms. The
kpatch-build front-tools use kpatch version to generate klp_relocs.

After commit 7c8e2bdd ("livepatch: Apply vmlinux-specific KLP
relocations early") and commit 425595a7 ("livepatch: reuse module
loader code to write relocations"), the mainline klp relocation flow
is always using ".klp.rela." section and kpatch-build front-tools use
klp version to generate klp module.

The default klp_apply_section_relocs is only for 64bit and modules
with rela support. Because CONFIG_MODULES_USE_ELF_REL is set in arm,
so we modify klp relocation to support 32bit and modules using rel.
Also the kpatch-build front-tools should adapter to support this.
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 51921
CVE: NA

---------------------------

We are planning to add livepatch without ftrace support for arm
in the next commit. However after commit 425595a7 ("livepatch:
reuse module loader code to write relocations") merged, the klp
relocations is done by apply_relocate function.

The mod->arch.{core,init}.plt pointers were problematic for livepatch
because they pointed within temporary section headers (provided by the
module loader via info->sechdrs) that would be freed after module load.

Here we take same modification based on commit c8ebf64e
("arm64/module: use plt section indices for relocations") to solve.
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euler inclusion
category: feature
Bugzilla: 51921
CVE: N/A

----------------------------------------

Now, arm64 don't support DYNAMIC_FTRACE_WITH_REGS and RELIABLE_STACKTRACE.
which the first is necessary to implement livepatch with ftrace and the
second allow to implement per-task consistency.

So. arm64 only support LIVEPATCH_WO_FTRACE and STOP_MACHINE_CONSISTENCY.
but other architectures can work under LIVEPATCH_FTRACE with
PER_TASK_CONSISTENCY. commit the depends to avoid incorrect configuration.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NLi Bin <huawei.libin@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NDong Kai <dongkai11@huawei.com>
Signed-off-by: NYe Weihua <yeweihua4@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>