--- /dev/null
+From ac9184fbb8478dab4a0724b279f94956b69be827 Mon Sep 17 00:00:00 2001
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Date: Tue, 2 Jan 2024 20:01:50 +0900
+Subject: firewire: ohci: suppress unexpected system reboot in AMD Ryzen machines and ASM108x/VT630x PCIe cards
+
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+
+commit ac9184fbb8478dab4a0724b279f94956b69be827 upstream.
+
+VIA VT6306/6307/6308 provides PCI interface compliant to 1394 OHCI. When
+the hardware is combined with Asmedia ASM1083/1085 PCIe-to-PCI bus bridge,
+it appears that accesses to its 'Isochronous Cycle Timer' register (offset
+0xf0 on PCI memory space) often causes unexpected system reboot in any
+type of AMD Ryzen machine (both 0x17 and 0x19 families). It does not
+appears in the other type of machine (AMD pre-Ryzen machine, Intel
+machine, at least), or in the other OHCI 1394 hardware (e.g. Texas
+Instruments).
+
+The issue explicitly appears at a commit dcadfd7f7c74 ("firewire: core:
+use union for callback of transaction completion") added to v6.5 kernel.
+It changed 1394 OHCI driver to access to the register every time to
+dispatch local asynchronous transaction. However, the issue exists in
+older version of kernel as long as it runs in AMD Ryzen machine, since
+the access to the register is required to maintain bus time. It is not
+hard to imagine that users experience the unexpected system reboot when
+generating bus reset by plugging any devices in, or reading the register
+by time-aware application programs; e.g. audio sample processing.
+
+This commit suppresses the unexpected system reboot in the combination of
+hardware. It avoids the access itself. As a result, the software stack can
+not provide the hardware time anymore to unit drivers, userspace
+applications, and nodes in the same IEEE 1394 bus. It brings apparent
+disadvantage since time-aware application programs require it, while
+time-unaware applications are available again; e.g. sbp2.
+
+Cc: stable@vger.kernel.org
+Reported-by: Jiri Slaby <jirislaby@kernel.org>
+Closes: https://bugzilla.suse.com/show_bug.cgi?id=1215436
+Reported-by: Mario Limonciello <mario.limonciello@amd.com>
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217994
+Reported-by: Tobias Gruetzmacher <tobias-lists@23.gs>
+Closes: https://sourceforge.net/p/linux1394/mailman/message/58711901/
+Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2240973
+Closes: https://bugs.launchpad.net/linux/+bug/2043905
+Link: https://lore.kernel.org/r/20240102110150.244475-1-o-takashi@sakamocchi.jp
+Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firewire/ohci.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 51 insertions(+)
+
+--- a/drivers/firewire/ohci.c
++++ b/drivers/firewire/ohci.c
+@@ -279,6 +279,51 @@ static char ohci_driver_name[] = KBUILD_
+ #define QUIRK_TI_SLLZ059 0x20
+ #define QUIRK_IR_WAKE 0x40
+
++// On PCI Express Root Complex in any type of AMD Ryzen machine, VIA VT6306/6307/6308 with Asmedia
++// ASM1083/1085 brings an inconvenience that the read accesses to 'Isochronous Cycle Timer' register
++// (at offset 0xf0 in PCI I/O space) often causes unexpected system reboot. The mechanism is not
++// clear, since the read access to the other registers is enough safe; e.g. 'Node ID' register,
++// while it is probable due to detection of any type of PCIe error.
++#define QUIRK_REBOOT_BY_CYCLE_TIMER_READ 0x80000000
++
++#if IS_ENABLED(CONFIG_X86)
++
++static bool has_reboot_by_cycle_timer_read_quirk(const struct fw_ohci *ohci)
++{
++ return !!(ohci->quirks & QUIRK_REBOOT_BY_CYCLE_TIMER_READ);
++}
++
++#define PCI_DEVICE_ID_ASMEDIA_ASM108X 0x1080
++
++static bool detect_vt630x_with_asm1083_on_amd_ryzen_machine(const struct pci_dev *pdev)
++{
++ const struct pci_dev *pcie_to_pci_bridge;
++
++ // Detect any type of AMD Ryzen machine.
++ if (!static_cpu_has(X86_FEATURE_ZEN))
++ return false;
++
++ // Detect VIA VT6306/6307/6308.
++ if (pdev->vendor != PCI_VENDOR_ID_VIA)
++ return false;
++ if (pdev->device != PCI_DEVICE_ID_VIA_VT630X)
++ return false;
++
++ // Detect Asmedia ASM1083/1085.
++ pcie_to_pci_bridge = pdev->bus->self;
++ if (pcie_to_pci_bridge->vendor != PCI_VENDOR_ID_ASMEDIA)
++ return false;
++ if (pcie_to_pci_bridge->device != PCI_DEVICE_ID_ASMEDIA_ASM108X)
++ return false;
++
++ return true;
++}
++
++#else
++#define has_reboot_by_cycle_timer_read_quirk(ohci) false
++#define detect_vt630x_with_asm1083_on_amd_ryzen_machine(pdev) false
++#endif
++
+ /* In case of multiple matches in ohci_quirks[], only the first one is used. */
+ static const struct {
+ unsigned short vendor, device, revision, flags;
+@@ -1713,6 +1758,9 @@ static u32 get_cycle_time(struct fw_ohci
+ s32 diff01, diff12;
+ int i;
+
++ if (has_reboot_by_cycle_timer_read_quirk(ohci))
++ return 0;
++
+ c2 = reg_read(ohci, OHCI1394_IsochronousCycleTimer);
+
+ if (ohci->quirks & QUIRK_CYCLE_TIMER) {
+@@ -3615,6 +3663,9 @@ static int pci_probe(struct pci_dev *dev
+ if (param_quirks)
+ ohci->quirks = param_quirks;
+
++ if (detect_vt630x_with_asm1083_on_amd_ryzen_machine(dev))
++ ohci->quirks |= QUIRK_REBOOT_BY_CYCLE_TIMER_READ;
++
+ /*
+ * Because dma_alloc_coherent() allocates at least one page,
+ * we save space by using a common buffer for the AR request/
--- /dev/null
+From a3368e1186e3ce8e38f78cbca019622095b1f331 Mon Sep 17 00:00:00 2001
+From: Benjamin Bara <benjamin.bara@skidata.com>
+Date: Thu, 4 Jan 2024 09:17:08 +0100
+Subject: i2c: core: Fix atomic xfer check for non-preempt config
+
+From: Benjamin Bara <benjamin.bara@skidata.com>
+
+commit a3368e1186e3ce8e38f78cbca019622095b1f331 upstream.
+
+Since commit aa49c90894d0 ("i2c: core: Run atomic i2c xfer when
+!preemptible"), the whole reboot/power off sequence on non-preempt kernels
+is using atomic i2c xfer, as !preemptible() always results to 1.
+
+During device_shutdown(), the i2c might be used a lot and not all busses
+have implemented an atomic xfer handler. This results in a lot of
+avoidable noise, like:
+
+[ 12.687169] No atomic I2C transfer handler for 'i2c-0'
+[ 12.692313] WARNING: CPU: 6 PID: 275 at drivers/i2c/i2c-core.h:40 i2c_smbus_xfer+0x100/0x118
+...
+
+Fix this by allowing non-atomic xfer when the interrupts are enabled, as
+it was before.
+
+Link: https://lore.kernel.org/r/20231222230106.73f030a5@yea
+Link: https://lore.kernel.org/r/20240102150350.3180741-1-mwalle@kernel.org
+Link: https://lore.kernel.org/linux-i2c/13271b9b-4132-46ef-abf8-2c311967bb46@mailbox.org/
+Fixes: aa49c90894d0 ("i2c: core: Run atomic i2c xfer when !preemptible")
+Cc: stable@vger.kernel.org # v5.2+
+Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
+Tested-by: Michael Walle <mwalle@kernel.org>
+Tested-by: Tor Vic <torvic9@mailbox.org>
+[wsa: removed a comment which needs more work, code is ok]
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/i2c-core.h | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/i2c/i2c-core.h
++++ b/drivers/i2c/i2c-core.h
+@@ -3,6 +3,7 @@
+ * i2c-core.h - interfaces internal to the I2C framework
+ */
+
++#include <linux/kconfig.h>
+ #include <linux/rwsem.h>
+
+ struct i2c_devinfo {
+@@ -29,7 +30,8 @@ int i2c_dev_irq_from_resources(const str
+ */
+ static inline bool i2c_in_atomic_xfer_mode(void)
+ {
+- return system_state > SYSTEM_RUNNING && !preemptible();
++ return system_state > SYSTEM_RUNNING &&
++ (IS_ENABLED(CONFIG_PREEMPT_COUNT) ? !preemptible() : irqs_disabled());
+ }
+
+ static inline int __i2c_lock_bus_helper(struct i2c_adapter *adap)
--- /dev/null
+From 9eab0421fa94a3dde0d1f7e36ab3294fc306c99d Mon Sep 17 00:00:00 2001
+From: Jiajun Xie <jiajun.xie.sh@gmail.com>
+Date: Wed, 20 Dec 2023 13:28:39 +0800
+Subject: mm: fix unmap_mapping_range high bits shift bug
+
+From: Jiajun Xie <jiajun.xie.sh@gmail.com>
+
+commit 9eab0421fa94a3dde0d1f7e36ab3294fc306c99d upstream.
+
+The bug happens when highest bit of holebegin is 1, suppose holebegin is
+0x8000000111111000, after shift, hba would be 0xfff8000000111111, then
+vma_interval_tree_foreach would look it up fail or leads to the wrong
+result.
+
+error call seq e.g.:
+- mmap(..., offset=0x8000000111111000)
+ |- syscall(mmap, ... unsigned long, off):
+ |- ksys_mmap_pgoff( ... , off >> PAGE_SHIFT);
+
+ here pgoff is correctly shifted to 0x8000000111111,
+ but pass 0x8000000111111000 as holebegin to unmap
+ would then cause terrible result, as shown below:
+
+- unmap_mapping_range(..., loff_t const holebegin)
+ |- pgoff_t hba = holebegin >> PAGE_SHIFT;
+ /* hba = 0xfff8000000111111 unexpectedly */
+
+The issue happens in Heterogeneous computing, where the device(e.g.
+gpu) and host share the same virtual address space.
+
+A simple workflow pattern which hit the issue is:
+ /* host */
+ 1. userspace first mmap a file backed VA range with specified offset.
+ e.g. (offset=0x800..., mmap return: va_a)
+ 2. write some data to the corresponding sys page
+ e.g. (va_a = 0xAABB)
+ /* device */
+ 3. gpu workload touches VA, triggers gpu fault and notify the host.
+ /* host */
+ 4. reviced gpu fault notification, then it will:
+ 4.1 unmap host pages and also takes care of cpu tlb
+ (use unmap_mapping_range with offset=0x800...)
+ 4.2 migrate sys page to device
+ 4.3 setup device page table and resolve device fault.
+ /* device */
+ 5. gpu workload continued, it accessed va_a and got 0xAABB.
+ 6. gpu workload continued, it wrote 0xBBCC to va_a.
+ /* host */
+ 7. userspace access va_a, as expected, it will:
+ 7.1 trigger cpu vm fault.
+ 7.2 driver handling fault to migrate gpu local page to host.
+ 8. userspace then could correctly get 0xBBCC from va_a
+ 9. done
+
+But in step 4.1, if we hit the bug this patch mentioned, then userspace
+would never trigger cpu fault, and still get the old value: 0xAABB.
+
+Making holebegin unsigned first fixes the bug.
+
+Link: https://lkml.kernel.org/r/20231220052839.26970-1-jiajun.xie.sh@gmail.com
+Signed-off-by: Jiajun Xie <jiajun.xie.sh@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/memory.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/mm/memory.c
++++ b/mm/memory.c
+@@ -3617,8 +3617,8 @@ EXPORT_SYMBOL_GPL(unmap_mapping_pages);
+ void unmap_mapping_range(struct address_space *mapping,
+ loff_t const holebegin, loff_t const holelen, int even_cows)
+ {
+- pgoff_t hba = holebegin >> PAGE_SHIFT;
+- pgoff_t hlen = (holelen + PAGE_SIZE - 1) >> PAGE_SHIFT;
++ pgoff_t hba = (pgoff_t)(holebegin) >> PAGE_SHIFT;
++ pgoff_t hlen = ((pgoff_t)(holelen) + PAGE_SIZE - 1) >> PAGE_SHIFT;
+
+ /* Check for overflow. */
+ if (sizeof(holelen) > sizeof(hlen)) {
btrfs-fix-qgroup_free_reserved_data-int-overflow.patch
btrfs-mark-the-len-field-in-struct-btrfs_ordered_sum.patch
ring-buffer-fix-32-bit-rb_time_read-race-with-rb_tim.patch
+firewire-ohci-suppress-unexpected-system-reboot-in-amd-ryzen-machines-and-asm108x-vt630x-pcie-cards.patch
+x86-kprobes-fix-incorrect-return-address-calculation-in-kprobe_emulate_call_indirect.patch
+i2c-core-fix-atomic-xfer-check-for-non-preempt-config.patch
+mm-fix-unmap_mapping_range-high-bits-shift-bug.patch
--- /dev/null
+From f5d03da48d062966c94f0199d20be0b3a37a7982 Mon Sep 17 00:00:00 2001
+From: Jinghao Jia <jinghao7@illinois.edu>
+Date: Tue, 2 Jan 2024 17:33:45 -0600
+Subject: x86/kprobes: fix incorrect return address calculation in kprobe_emulate_call_indirect
+
+From: Jinghao Jia <jinghao7@illinois.edu>
+
+commit f5d03da48d062966c94f0199d20be0b3a37a7982 upstream.
+
+kprobe_emulate_call_indirect currently uses int3_emulate_call to emulate
+indirect calls. However, int3_emulate_call always assumes the size of
+the call to be 5 bytes when calculating the return address. This is
+incorrect for register-based indirect calls in x86, which can be either
+2 or 3 bytes depending on whether REX prefix is used. At kprobe runtime,
+the incorrect return address causes control flow to land onto the wrong
+place after return -- possibly not a valid instruction boundary. This
+can lead to a panic like the following:
+
+[ 7.308204][ C1] BUG: unable to handle page fault for address: 000000000002b4d8
+[ 7.308883][ C1] #PF: supervisor read access in kernel mode
+[ 7.309168][ C1] #PF: error_code(0x0000) - not-present page
+[ 7.309461][ C1] PGD 0 P4D 0
+[ 7.309652][ C1] Oops: 0000 [#1] SMP
+[ 7.309929][ C1] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.7.0-rc5-trace-for-next #6
+[ 7.310397][ C1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
+[ 7.311068][ C1] RIP: 0010:__common_interrupt+0x52/0xc0
+[ 7.311349][ C1] Code: 01 00 4d 85 f6 74 39 49 81 fe 00 f0 ff ff 77 30 4c 89 f7 4d 8b 5e 68 41 ba 91 76 d8 42 45 03 53 fc 74 02 0f 0b cc ff d3 65 48 <8b> 05 30 c7 ff 7e 65 4c 89 3d 28 c7 ff 7e 5b 41 5c 41 5e 41 5f c3
+[ 7.312512][ C1] RSP: 0018:ffffc900000e0fd0 EFLAGS: 00010046
+[ 7.312899][ C1] RAX: 0000000000000001 RBX: 0000000000000023 RCX: 0000000000000001
+[ 7.313334][ C1] RDX: 00000000000003cd RSI: 0000000000000001 RDI: ffff888100d302a4
+[ 7.313702][ C1] RBP: 0000000000000001 R08: 0ef439818636191f R09: b1621ff338a3b482
+[ 7.314146][ C1] R10: ffffffff81e5127b R11: ffffffff81059810 R12: 0000000000000023
+[ 7.314509][ C1] R13: 0000000000000000 R14: ffff888100d30200 R15: 0000000000000000
+[ 7.314951][ C1] FS: 0000000000000000(0000) GS:ffff88813bc80000(0000) knlGS:0000000000000000
+[ 7.315396][ C1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 7.315691][ C1] CR2: 000000000002b4d8 CR3: 0000000003028003 CR4: 0000000000370ef0
+[ 7.316153][ C1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[ 7.316508][ C1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[ 7.316948][ C1] Call Trace:
+[ 7.317123][ C1] <IRQ>
+[ 7.317279][ C1] ? __die_body+0x64/0xb0
+[ 7.317482][ C1] ? page_fault_oops+0x248/0x370
+[ 7.317712][ C1] ? __wake_up+0x96/0xb0
+[ 7.317964][ C1] ? exc_page_fault+0x62/0x130
+[ 7.318211][ C1] ? asm_exc_page_fault+0x22/0x30
+[ 7.318444][ C1] ? __cfi_native_send_call_func_single_ipi+0x10/0x10
+[ 7.318860][ C1] ? default_idle+0xb/0x10
+[ 7.319063][ C1] ? __common_interrupt+0x52/0xc0
+[ 7.319330][ C1] common_interrupt+0x78/0x90
+[ 7.319546][ C1] </IRQ>
+[ 7.319679][ C1] <TASK>
+[ 7.319854][ C1] asm_common_interrupt+0x22/0x40
+[ 7.320082][ C1] RIP: 0010:default_idle+0xb/0x10
+[ 7.320309][ C1] Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 b8 0c 67 40 a5 66 90 0f 00 2d 09 b9 3b 00 fb f4 <fa> c3 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 b8 0c 67 40 a5 e9
+[ 7.321449][ C1] RSP: 0018:ffffc9000009bee8 EFLAGS: 00000256
+[ 7.321808][ C1] RAX: ffff88813bca8b68 RBX: 0000000000000001 RCX: 000000000001ef0c
+[ 7.322227][ C1] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 000000000001ef0c
+[ 7.322656][ C1] RBP: ffffc9000009bef8 R08: 8000000000000000 R09: 00000000000008c2
+[ 7.323083][ C1] R10: 0000000000000000 R11: ffffffff81058e70 R12: 0000000000000000
+[ 7.323530][ C1] R13: ffff8881002b30c0 R14: 0000000000000000 R15: 0000000000000000
+[ 7.323948][ C1] ? __cfi_lapic_next_deadline+0x10/0x10
+[ 7.324239][ C1] default_idle_call+0x31/0x50
+[ 7.324464][ C1] do_idle+0xd3/0x240
+[ 7.324690][ C1] cpu_startup_entry+0x25/0x30
+[ 7.324983][ C1] start_secondary+0xb4/0xc0
+[ 7.325217][ C1] secondary_startup_64_no_verify+0x179/0x17b
+[ 7.325498][ C1] </TASK>
+[ 7.325641][ C1] Modules linked in:
+[ 7.325906][ C1] CR2: 000000000002b4d8
+[ 7.326104][ C1] ---[ end trace 0000000000000000 ]---
+[ 7.326354][ C1] RIP: 0010:__common_interrupt+0x52/0xc0
+[ 7.326614][ C1] Code: 01 00 4d 85 f6 74 39 49 81 fe 00 f0 ff ff 77 30 4c 89 f7 4d 8b 5e 68 41 ba 91 76 d8 42 45 03 53 fc 74 02 0f 0b cc ff d3 65 48 <8b> 05 30 c7 ff 7e 65 4c 89 3d 28 c7 ff 7e 5b 41 5c 41 5e 41 5f c3
+[ 7.327570][ C1] RSP: 0018:ffffc900000e0fd0 EFLAGS: 00010046
+[ 7.327910][ C1] RAX: 0000000000000001 RBX: 0000000000000023 RCX: 0000000000000001
+[ 7.328273][ C1] RDX: 00000000000003cd RSI: 0000000000000001 RDI: ffff888100d302a4
+[ 7.328632][ C1] RBP: 0000000000000001 R08: 0ef439818636191f R09: b1621ff338a3b482
+[ 7.329223][ C1] R10: ffffffff81e5127b R11: ffffffff81059810 R12: 0000000000000023
+[ 7.329780][ C1] R13: 0000000000000000 R14: ffff888100d30200 R15: 0000000000000000
+[ 7.330193][ C1] FS: 0000000000000000(0000) GS:ffff88813bc80000(0000) knlGS:0000000000000000
+[ 7.330632][ C1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 7.331050][ C1] CR2: 000000000002b4d8 CR3: 0000000003028003 CR4: 0000000000370ef0
+[ 7.331454][ C1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[ 7.331854][ C1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[ 7.332236][ C1] Kernel panic - not syncing: Fatal exception in interrupt
+[ 7.332730][ C1] Kernel Offset: disabled
+[ 7.333044][ C1] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
+
+The relevant assembly code is (from objdump, faulting address
+highlighted):
+
+ffffffff8102ed9d: 41 ff d3 call *%r11
+ffffffff8102eda0: 65 48 <8b> 05 30 c7 ff mov %gs:0x7effc730(%rip),%rax
+
+The emulation incorrectly sets the return address to be ffffffff8102ed9d
++ 0x5 = ffffffff8102eda2, which is the 8b byte in the middle of the next
+mov. This in turn causes incorrect subsequent instruction decoding and
+eventually triggers the page fault above.
+
+Instead of invoking int3_emulate_call, perform push and jmp emulation
+directly in kprobe_emulate_call_indirect. At this point we can obtain
+the instruction size from p->ainsn.size so that we can calculate the
+correct return address.
+
+Link: https://lore.kernel.org/all/20240102233345.385475-1-jinghao7@illinois.edu/
+
+Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step")
+Cc: stable@vger.kernel.org
+Signed-off-by: Jinghao Jia <jinghao7@illinois.edu>
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/kprobes/core.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/kprobes/core.c
++++ b/arch/x86/kernel/kprobes/core.c
+@@ -549,7 +549,8 @@ static void kprobe_emulate_call_indirect
+ {
+ unsigned long offs = addrmode_regoffs[p->ainsn.indirect.reg];
+
+- int3_emulate_call(regs, regs_get_register(regs, offs));
++ int3_emulate_push(regs, regs->ip - INT3_INSN_SIZE + p->ainsn.size);
++ int3_emulate_jmp(regs, regs_get_register(regs, offs));
+ }
+ NOKPROBE_SYMBOL(kprobe_emulate_call_indirect);
+