[PATCH] uprobes: prevent mutex_lock() under rcu_read_lock()
Recent changes made uprobe_cpu_buffer preparation lazy, and moved it
deeper into __uprobe_trace_func(). This is problematic because
__uprobe_trace_func() is called inside rcu_read_lock()/rcu_read_unlock()
block, which then calls prepare_uprobe_buffer() -> uprobe_buffer_get() ->
mutex_lock(>mutex), leading to a splat about using mutex under
non-sleepable RCU:
BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:585
in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 98231, name:
stress-ng-sigq
preempt_count: 0, expected: 0
RCU nest depth: 1, expected: 0
...
Call Trace:
dump_stack_lvl+0x3d/0xe0
__might_resched+0x24c/0x270
? prepare_uprobe_buffer+0xd5/0x1d0
__mutex_lock+0x41/0x820
? ___perf_sw_event+0x206/0x290
? __perf_event_task_sched_in+0x54/0x660
? __perf_event_task_sched_in+0x54/0x660
prepare_uprobe_buffer+0xd5/0x1d0
__uprobe_trace_func+0x4a/0x140
uprobe_dispatcher+0x135/0x280
? uprobe_dispatcher+0x94/0x280
uprobe_notify_resume+0x650/0xec0
? atomic_notifier_call_chain+0x21/0x110
? atomic_notifier_call_chain+0xf8/0x110
irqentry_exit_to_user_mode+0xe2/0x1e0
asm_exc_int3+0x35/0x40
RIP: 0033:0x7f7e1d4da390
Code: 33 04 00 0f 1f 80 00 00 00 00 f3 0f 1e fa b9 01 00 00 00 e9 b2 fc ff
ff 66 90 f3 0f 1e fa 31 c9 e9 a5 fc ff ff 0f 1f 44 00 00 0f 1e fa b8 27 00
00 00 0f 05 c3 0f 1f 40 00 f3 0f 1e fa b8 6e
RSP: 002b:7ffd2abc3608 EFLAGS: 0246
RAX: RBX: 76d325f1 RCX:
RDX: 76d325f1 RSI: 000a RDI: 7ffd2abc3690
RBP: 000a R08: 00017fb7 R09: 00017fb7
R10: 00017fb7 R11: 0246 R12: 00017ff2
R13: 7ffd2abc3610 R14: R15: 7ffd2abc3780
Luckily, it's easy to fix by moving prepare_uprobe_buffer() to be called
slightly earlier: into uprobe_trace_func() and uretprobe_trace_func(), outside
of RCU locked section. This still keeps this buffer preparation lazy and helps
avoid the overhead when it's not needed. E.g., if there is only BPF uprobe
handler installed on a given uprobe, buffer won't be initialized.
Note, the other user of prepare_uprobe_buffer(), __uprobe_perf_func(), is not
affected, as it doesn't prepare buffer under RCU read lock.
Fixes: 1b8f85defbc8 ("uprobes: prepare uprobe args buffer lazily")
Reported-by: Breno Leitao
Signed-off-by: Andrii Nakryiko
---
kernel/trace/trace_uprobe.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index 8541fa1494ae..c98e3b3386ba 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -970,19 +970,17 @@ static struct uprobe_cpu_buffer
*prepare_uprobe_buffer(struct trace_uprobe *tu,
static void __uprobe_trace_func(struct trace_uprobe *tu,
unsigned long func, struct pt_regs *regs,
- struct uprobe_cpu_buffer **ucbp,
+ struct uprobe_cpu_buffer *ucb,
struct trace_event_file *trace_file)
{
struct uprobe_trace_entry_head *entry;
struct trace_event_buffer fbuffer;
- struct uprobe_cpu_buffer *ucb;
void *data;
int size, esize;
struct trace_event_call *call = trace_probe_event_call(>tp);
WARN_ON(call != trace_file->event_call);
- ucb = prepare_uprobe_buffer(tu, regs, ucbp);
if (WARN_ON_ONCE(ucb->dsize > PAGE_SIZE))
return;
@@ -1014,13 +1012,16 @@ static int uprobe_trace_func(struct trace_uprobe *tu,
struct pt_regs *regs,
struct uprobe_cpu_buffer **ucbp)
{
struct event_file_link *link;
+ struct uprobe_cpu_buffer *ucb;
if (is_ret_probe(tu))
return 0;
+ ucb = prepare_uprobe_buffer(tu, regs, ucbp);
+
rcu_read_lock();
trace_probe_for_each_link_rcu(link, >tp)
- __uprobe_trace_func(tu, 0, regs, ucbp, link->file);
+ __uprobe_trace_func(tu, 0, regs, ucb, link->file);
rcu_read_unlock();
return 0;
@@ -1031,10 +1032,13 @@ static void uretprobe_trace_func(struct trace_uprobe
*tu, unsigned long func,
struct uprobe_cpu_buffer **ucbp)
{
struct event_file_link *link;
+ struct uprobe_cpu_buffer *ucb;
+
+ ucb = prepare_uprobe_buffer(tu, regs, ucbp);
rcu_read_lock();
trace_probe_for_each_link_rcu(link, >tp)
- __uprobe_trace_func(tu, func, regs, ucbp, link->file);
+ __uprobe_trace_func(tu, func, regs, ucb, link->file);
rcu_read_unlock();
}
--
2.43.0
[GIT PULL] remoteproc updates for v6.10
The following changes since commit 4cece764965020c22cff7665b18a012006359095: Linux 6.9-rc1 (2024-03-24 14:10:05 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git tags/rproc-v6.10 for you to fetch changes up to 4d5ba6ead1dc9fa298d727e92db40cd98564d1ac: dt-bindings: remoteproc: qcom,sdm845-adsp-pil: Fix qcom,halt-regs definition (2024-05-06 19:41:38 -0700) remoteproc updates for v6.10 This makes the remoteproc core rproc_class const. DeviceTree bindings for a few different Qualcomm remoteprocs are updated to remove a range of validation warnings/errors. The Qualcomm SMD binding marks qcom,ipc deprecated, in favor or the mailbox interface. The TI K3 R5 remoteproc driver is updated to ensure that cores are powered up in the appropriate order. The driver also see a couple of fixes related to cleanups in error paths during probe. The Mediatek remoteproc driver is extended to support the MT8188 SCP core 1. Support for varying DRAM and IPI shared buffer sizes are introduced. This together with a couple of bug fixes and improvements to the driver. Support for the AMD-Xilinx Versal and Versal-NET platforms are added. Coredump support and support for parsing TCM information from DeviceTree is added to the Xilinx R5F remoteproc driver. AngeloGioacchino Del Regno (1): remoteproc: mediatek: Make sure IPI buffer fits in L2TCM Apurva Nandan (1): remoteproc: k3-r5: Wait for core0 power-up before powering up core1 Beleswar Padhi (2): remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs remoteproc: k3-r5: Jump to error handling labels in start/stop errors Dan Carpenter (1): remoteproc: mediatek: Fix error code in scp_rproc_init() Dmitry Baryshkov (1): dt-bindings: remoteproc: qcom,msm8996-mss-pil: allow glink-edge on msm8996 Leonard Crestez (1): remoteproc: zynqmp: Add coredump support Luca Weiss (4): dt-bindings: remoteproc: qcom,smd-edge: Mark qcom,ipc as deprecated dt-bindings: remoteproc: qcom,qcs404-cdsp-pil: Fix qcom,halt-regs definition dt-bindings: remoteproc: qcom,sc7280-wpss-pil: Fix qcom,halt-regs definition dt-bindings: remoteproc: qcom,sdm845-adsp-pil: Fix qcom,halt-regs definition Olivia Wen (4): dt-bindings: remoteproc: mediatek: Support MT8188 dual-core SCP remoteproc: mediatek: Support MT8188 SCP core 1 remoteproc: mediatek: Support setting DRAM and IPI shared buffer sizes remoteproc: mediatek: Add IMGSYS IPI command Radhey Shyam Pandey (1): dt-bindings: remoteproc: Add Tightly Coupled Memory (TCM) bindings Ricardo B. Marliere (1): remoteproc: Make rproc_class constant Tanmay Shah (5): remoteproc: zynqmp: fix lockstep mode memory region remoteproc: zynqmp: parse TCM from device tree drivers: remoteproc: xlnx: Add Versal and Versal-NET support drivers: remoteproc: xlnx: Fix uninitialized variable use drivers: remoteproc: xlnx: Fix uninitialized tcm mode .../devicetree/bindings/remoteproc/mtk,scp.yaml| 2 + .../bindings/remoteproc/qcom,msm8996-mss-pil.yaml | 1 - .../bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml | 6 +- .../bindings/remoteproc/qcom,sc7280-wpss-pil.yaml | 6 +- .../bindings/remoteproc/qcom,sdm845-adsp-pil.yaml | 6 +- .../bindings/remoteproc/qcom,smd-edge.yaml | 3 +- .../bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 279 +++-- drivers/remoteproc/mtk_common.h| 11 +- drivers/remoteproc/mtk_scp.c | 241 +-- drivers/remoteproc/mtk_scp_ipi.c | 7 +- drivers/remoteproc/remoteproc_internal.h | 2 +- drivers/remoteproc/remoteproc_sysfs.c | 2 +- drivers/remoteproc/ti_k3_r5_remoteproc.c | 58 +++- drivers/remoteproc/xlnx_r5_remoteproc.c| 329 ++--- include/linux/remoteproc/mtk_scp.h | 1 + 15 files changed, 721 insertions(+), 233 deletions(-)
[GIT PULL] rpmsg updates for v6.10
The following changes since commit 4cece764965020c22cff7665b18a012006359095: Linux 6.9-rc1 (2024-03-24 14:10:05 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git tags/rpmsg-v6.10 for you to fetch changes up to bcbab579f968ffd63236d90227212e689ddbd600: rpmsg: qcom_glink_ssr: fix module autoloading (2024-05-06 19:26:28 -0700) rpmsg updates for v6.10 This makes core rpmsg_class const and it ensures automatic module loading of the Qualcomm glink_ssr driver happens. Krzysztof Kozlowski (1): rpmsg: qcom_glink_ssr: fix module autoloading Ricardo B. Marliere (1): rpmsg: core: Make rpmsg_class constant drivers/rpmsg/qcom_glink_ssr.c | 1 + drivers/rpmsg/rpmsg_char.c | 2 +- drivers/rpmsg/rpmsg_core.c | 16 +--- drivers/rpmsg/rpmsg_ctrl.c | 2 +- drivers/rpmsg/rpmsg_internal.h | 2 +- 5 files changed, 13 insertions(+), 10 deletions(-)
[PATCH v3 2/2] LoongArch: Add steal time support in guest side
Percpu struct kvm_steal_time is added here, its size is 64 bytes and
also defined as 64 bytes, so that the whole structure is in one physical
page.
When vcpu is onlined, function pv_enable_steal_time() is called. This
function will pass guest physical address of struct kvm_steal_time and
tells hypervisor to enable steal time. When vcpu is offline, physical
address is set as 0 and tells hypervisor to disable steal time.
Here is output of vmstat on guest when there is workload on both host
and guest. It includes steal time stat information.
procs ---memory-- -io -system-- --cpu-
r b swpd free inact active bibo in cs us sy id wa st
15 1 0 7583616 184112 72208200 162 52 31 6 43 0 20
17 0 0 7583616 184704 721920 0 6318 6885 5 60 8 5 22
16 0 0 7583616 185392 721440 0 1766 1081 0 49 0 1 50
16 0 0 7583616 184816 723040 0 6300 6166 4 62 12 2 20
18 0 0 7583632 184480 722400 0 2814 1754 2 58 4 1 35
Signed-off-by: Bibo Mao
---
.../admin-guide/kernel-parameters.txt | 2 +-
arch/loongarch/Kconfig| 11 ++
arch/loongarch/include/asm/paravirt.h | 5 +
arch/loongarch/kernel/paravirt.c | 131 ++
arch/loongarch/kernel/time.c | 2 +
5 files changed, 150 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 45d95614ec44..502d98292692 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4049,7 +4049,7 @@
prediction) vulnerability. System may allow data
leaks with this option.
- no-steal-acc[X86,PV_OPS,ARM64,PPC/PSERIES,RISCV,EARLY] Disable
+ no-steal-acc[X86,PV_OPS,ARM64,PPC/PSERIES,RISCV,LOONGARCH,EARLY]
Disable
paravirtualized steal time accounting. steal time is
computed, but won't influence scheduler behaviour
diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
index 42331d9a8dd7..76dd20bdf415 100644
--- a/arch/loongarch/Kconfig
+++ b/arch/loongarch/Kconfig
@@ -583,6 +583,17 @@ config CPU_HAS_PREFETCH
bool
default y
+config PARAVIRT_TIME_ACCOUNTING
+ bool "Paravirtual steal time accounting"
+ select PARAVIRT
+ help
+ Select this option to enable fine granularity task steal time
+ accounting. Time spent executing other tasks in parallel with
+ the current vCPU is discounted from the vCPU power. To account for
+ that, there can be a small performance impact.
+
+ If in doubt, say N here.
+
config ARCH_SUPPORTS_KEXEC
def_bool y
diff --git a/arch/loongarch/include/asm/paravirt.h
b/arch/loongarch/include/asm/paravirt.h
index 0965710f47f2..dddec49671ae 100644
--- a/arch/loongarch/include/asm/paravirt.h
+++ b/arch/loongarch/include/asm/paravirt.h
@@ -18,6 +18,7 @@ static inline u64 paravirt_steal_clock(int cpu)
}
int __init pv_ipi_init(void);
+int __init pv_time_init(void);
#else
@@ -26,5 +27,9 @@ static inline int pv_ipi_init(void)
return 0;
}
+static inline int pv_time_init(void)
+{
+ return 0;
+}
#endif // CONFIG_PARAVIRT
#endif
diff --git a/arch/loongarch/kernel/paravirt.c b/arch/loongarch/kernel/paravirt.c
index 1633ed4f692f..c14265fb9701 100644
--- a/arch/loongarch/kernel/paravirt.c
+++ b/arch/loongarch/kernel/paravirt.c
@@ -4,11 +4,14 @@
#include
#include
#include
+#include
#include
#include
struct static_key paravirt_steal_enabled;
struct static_key paravirt_steal_rq_enabled;
+static DEFINE_PER_CPU(struct kvm_steal_time, steal_time) __aligned(64);
+static int has_steal_clock;
static u64 native_steal_clock(int cpu)
{
@@ -17,6 +20,57 @@ static u64 native_steal_clock(int cpu)
DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
+static bool steal_acc = true;
+static int __init parse_no_stealacc(char *arg)
+{
+ steal_acc = false;
+ return 0;
+}
+early_param("no-steal-acc", parse_no_stealacc);
+
+static u64 para_steal_clock(int cpu)
+{
+ u64 steal;
+ struct kvm_steal_time *src;
+ int version;
+
+ src = _cpu(steal_time, cpu);
+ do {
+
+ version = src->version;
+ /* Make sure that the version is read before the steal */
+ virt_rmb();
+ steal = src->steal;
+ /* Make sure that the steal is read before the next version */
+ virt_rmb();
+
+ } while ((version & 1) || (version != src->version));
+ return steal;
+}
+
+static int pv_enable_steal_time(void)
+{
+ int cpu = smp_processor_id();
+ struct kvm_steal_time *st;
+ unsigned long addr;
+
+ if (!has_steal_clock)
+ return -EPERM;
+
+ st =
[PATCH v3 0/2] LoongArch: Add steal time support
Para-virt feature steal time is added in both kvm and guest kernel side. It is silimar with other architectures, steal time structure comes from guest memory, also pseduo register is used to save/restore base address of steal time structure, so that vm migration is supported also. --- v2 ... v3: 1. Solve code confliction based on the kernel 6.9.0 2. Add kernel parameter no-steal-acc support on LoongArch with file Documentation/admin-guide/kernel-parameters.txt 3. Add strict checking with pv stealtimer gpa address in function kvm_save_notify() and kvm_loongarch_pvtime_set_attr() v1 ... v2: 1. Add PARAVIRT_TIME_ACCOUNTING kconfig option in file arch/loongarch/Kconfig 2. Function name change such as replace pv_register_steal_time with pv_enable_steal_time etc --- Bibo Mao (2): LoongArch: KVM: Add steal time support in kvm side LoongArch: Add steal time support in guest side .../admin-guide/kernel-parameters.txt | 2 +- arch/loongarch/Kconfig| 11 ++ arch/loongarch/include/asm/kvm_host.h | 7 + arch/loongarch/include/asm/kvm_para.h | 10 ++ arch/loongarch/include/asm/kvm_vcpu.h | 4 + arch/loongarch/include/asm/loongarch.h| 1 + arch/loongarch/include/asm/paravirt.h | 5 + arch/loongarch/include/uapi/asm/kvm.h | 4 + arch/loongarch/kernel/paravirt.c | 131 ++ arch/loongarch/kernel/time.c | 2 + arch/loongarch/kvm/exit.c | 38 - arch/loongarch/kvm/vcpu.c | 124 + 12 files changed, 336 insertions(+), 3 deletions(-) base-commit: 3c999d1ae3c75991902a1a7dad0cb62c2a3008b4 -- 2.39.3
[PATCH v3 1/2] LoongArch: KVM: Add steal time support in kvm side
Steal time feature is added here in kvm side, VM can search supported
features provided by KVM hypervisor, feature KVM_FEATURE_STEAL_TIME
is added here. Like x86, steal time structure is saved in guest memory,
one hypercall function KVM_HCALL_FUNC_NOTIFY is added to notify KVM to
enable the feature.
One cpu attr ioctl command KVM_LOONGARCH_VCPU_PVTIME_CTRL is added to
save and restore base address of steal time structure when VM is migrated.
Signed-off-by: Bibo Mao
---
arch/loongarch/include/asm/kvm_host.h | 7 ++
arch/loongarch/include/asm/kvm_para.h | 10 ++
arch/loongarch/include/asm/kvm_vcpu.h | 4 +
arch/loongarch/include/asm/loongarch.h | 1 +
arch/loongarch/include/uapi/asm/kvm.h | 4 +
arch/loongarch/kvm/exit.c | 38 +++-
arch/loongarch/kvm/vcpu.c | 124 +
7 files changed, 186 insertions(+), 2 deletions(-)
diff --git a/arch/loongarch/include/asm/kvm_host.h
b/arch/loongarch/include/asm/kvm_host.h
index c87b6ea0ec47..2eb2f7572023 100644
--- a/arch/loongarch/include/asm/kvm_host.h
+++ b/arch/loongarch/include/asm/kvm_host.h
@@ -30,6 +30,7 @@
#define KVM_PRIVATE_MEM_SLOTS 0
#define KVM_HALT_POLL_NS_DEFAULT 50
+#define KVM_REQ_STEAL_UPDATE KVM_ARCH_REQ(1)
#define KVM_GUESTDBG_SW_BP_MASK\
(KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)
@@ -201,6 +202,12 @@ struct kvm_vcpu_arch {
struct kvm_mp_state mp_state;
/* cpucfg */
u32 cpucfg[KVM_MAX_CPUCFG_REGS];
+ /* paravirt steal time */
+ struct {
+ u64 guest_addr;
+ u64 last_steal;
+ struct gfn_to_hva_cache cache;
+ } st;
};
static inline unsigned long readl_sw_gcsr(struct loongarch_csrs *csr, int reg)
diff --git a/arch/loongarch/include/asm/kvm_para.h
b/arch/loongarch/include/asm/kvm_para.h
index 4ba2312e5f8c..a9ba8185d4af 100644
--- a/arch/loongarch/include/asm/kvm_para.h
+++ b/arch/loongarch/include/asm/kvm_para.h
@@ -14,6 +14,7 @@
#define KVM_HCALL_SERVICE HYPERCALL_ENCODE(HYPERVISOR_KVM,
KVM_HCALL_CODE_SERVICE)
#define KVM_HCALL_FUNC_IPI1
+#define KVM_HCALL_FUNC_NOTIFY 2
#define KVM_HCALL_SWDBG
HYPERCALL_ENCODE(HYPERVISOR_KVM, KVM_HCALL_CODE_SWDBG)
@@ -24,6 +25,15 @@
#define KVM_HCALL_INVALID_CODE -1UL
#define KVM_HCALL_INVALID_PARAMETER-2UL
+#define KVM_STEAL_PHYS_VALID BIT_ULL(0)
+#define KVM_STEAL_PHYS_MASKGENMASK_ULL(63, 6)
+struct kvm_steal_time {
+ __u64 steal;
+ __u32 version;
+ __u32 flags;
+ __u32 pad[12];
+};
+
/*
* Hypercall interface for KVM hypervisor
*
diff --git a/arch/loongarch/include/asm/kvm_vcpu.h
b/arch/loongarch/include/asm/kvm_vcpu.h
index 590a92cb5416..d7e51300a89f 100644
--- a/arch/loongarch/include/asm/kvm_vcpu.h
+++ b/arch/loongarch/include/asm/kvm_vcpu.h
@@ -120,4 +120,8 @@ static inline void kvm_write_reg(struct kvm_vcpu *vcpu, int
num, unsigned long v
vcpu->arch.gprs[num] = val;
}
+static inline bool kvm_pvtime_supported(void)
+{
+ return !!sched_info_on();
+}
#endif /* __ASM_LOONGARCH_KVM_VCPU_H__ */
diff --git a/arch/loongarch/include/asm/loongarch.h
b/arch/loongarch/include/asm/loongarch.h
index eb09adda54b7..7a4633ef284b 100644
--- a/arch/loongarch/include/asm/loongarch.h
+++ b/arch/loongarch/include/asm/loongarch.h
@@ -169,6 +169,7 @@
#define KVM_SIGNATURE "KVM\0"
#define CPUCFG_KVM_FEATURE (CPUCFG_KVM_BASE + 4)
#define KVM_FEATURE_IPI BIT(1)
+#define KVM_FEATURE_STEAL_TIMEBIT(2)
#ifndef __ASSEMBLY__
diff --git a/arch/loongarch/include/uapi/asm/kvm.h
b/arch/loongarch/include/uapi/asm/kvm.h
index f9abef382317..ddc5cab0ffd0 100644
--- a/arch/loongarch/include/uapi/asm/kvm.h
+++ b/arch/loongarch/include/uapi/asm/kvm.h
@@ -81,7 +81,11 @@ struct kvm_fpu {
#define LOONGARCH_REG_64(TYPE, REG)(TYPE | KVM_REG_SIZE_U64 | (REG <<
LOONGARCH_REG_SHIFT))
#define KVM_IOC_CSRID(REG) LOONGARCH_REG_64(KVM_REG_LOONGARCH_CSR,
REG)
#define KVM_IOC_CPUCFG(REG)
LOONGARCH_REG_64(KVM_REG_LOONGARCH_CPUCFG, REG)
+
+/* Device Control API on vcpu fd */
#define KVM_LOONGARCH_VCPU_CPUCFG 0
+#define KVM_LOONGARCH_VCPU_PVTIME_CTRL 1
+#define KVM_LOONGARCH_VCPU_PVTIME_GPA 0
struct kvm_debug_exit_arch {
};
diff --git a/arch/loongarch/kvm/exit.c b/arch/loongarch/kvm/exit.c
index c86e099af5ca..e2abd97fb13f 100644
--- a/arch/loongarch/kvm/exit.c
+++ b/arch/loongarch/kvm/exit.c
@@ -24,7 +24,7 @@
static int kvm_emu_cpucfg(struct kvm_vcpu *vcpu, larch_inst inst)
{
int rd, rj;
- unsigned int index;
+ unsigned int index, ret;
if (inst.reg2_format.opcode != cpucfg_op)
return EMULATE_FAIL;
@@ -50,7 +50,10 @@ static int kvm_emu_cpucfg(struct kvm_vcpu *vcpu, larch_inst
inst)
vcpu->arch.gprs[rd] = *(unsigned int
Re: [PATCH v1 1/2] virt: pvmemcontrol: control guest physical memory properties
Hi Yuanchu, kernel test robot noticed the following build errors: [auto build test ERROR on linus/master] [also build test ERROR on v6.9 next-20240520] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Yuanchu-Xie/virt-pvmemcontrol-add-Yuanchu-and-Pasha-as-maintainers/20240518-152618 base: linus/master patch link: https://lore.kernel.org/r/20240518072422.771698-1-yuanchu%40google.com patch subject: [PATCH v1 1/2] virt: pvmemcontrol: control guest physical memory properties config: powerpc-randconfig-r133-20240521 (https://download.01.org/0day-ci/archive/20240521/202405211027.wmbogeyf-...@intel.com/config) compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project fa9b1be45088dce1e4b602d451f118128b94237b) reproduce: (https://download.01.org/0day-ci/archive/20240521/202405211027.wmbogeyf-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202405211027.wmbogeyf-...@intel.com/ All error/warnings (new ones prefixed by >>, old ones prefixed by <<): WARNING: modpost: missing MODULE_DESCRIPTION() in vmlinux.o WARNING: modpost: missing MODULE_DESCRIPTION() in kernel/locking/test-ww_mutex.o WARNING: modpost: missing MODULE_DESCRIPTION() in kernel/kcsan/kcsan_test.o WARNING: modpost: missing MODULE_DESCRIPTION() in mm/dmapool_test.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/fat/fat_test.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_cp860.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_cp861.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_cp864.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_cp874.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_cp936.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_iso8859-2.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_cp1255.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_iso8859-9.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_utf8.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/mac-greek.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/mac-inuit.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/unicode/utf8data.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/unicode/utf8-selftest.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/bcachefs/mean_and_variance_test.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/ext4/ext4-inode-test.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/cramfs/cramfs.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/minix/minix.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/sysv/sysv.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/qnx4/qnx4.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/pstore/pstore.o WARNING: modpost: missing MODULE_DESCRIPTION() in crypto/curve25519-generic.o WARNING: modpost: missing MODULE_DESCRIPTION() in lib/kunit/kunit.o WARNING: modpost: missing MODULE_DESCRIPTION() in lib/kunit/kunit-test.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpio/gpio-gw-pld.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpio/gpio-pcf857x.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pci/controller/pci-host-common.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pci/controller/pci-host-generic.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/video/backlight/platform_lcd.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/video/backlight/rt4831-backlight.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dma/qcom/hdma_mgmt.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dma/qcom/hdma.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/regulator/max20411-regulator.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/char/lp.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/char/hw_random/omap-rng.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/char/hw_random/omap3-rom-rng.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/iommu/iova.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-kunit.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-ram.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-raw-ram.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-slimbus.o WARNING: modpost: missing MODULE_DESCRIPTION(
Re: [PATCH V3 3/3] vdpa_sim: flush workers on suspend
On Mon, May 20, 2024 at 11:21 PM Steve Sistare
wrote:
>
> Flush to guarantee no workers are running when suspend returns.
> Add a lock to enforce ordering between clearing running, flushing,
> and posting new work in vdpasim_kick_vq. It must be a spin lock
> because vdpasim_kick_vq may be reached va eventfd_write.
>
> Signed-off-by: Steve Sistare
> ---
> drivers/vdpa/vdpa_sim/vdpa_sim.c | 16 ++--
> drivers/vdpa/vdpa_sim/vdpa_sim.h | 1 +
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c
> b/drivers/vdpa/vdpa_sim/vdpa_sim.c
> index 8ffea8430f95..67ed49d95bf0 100644
> --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
> @@ -322,7 +322,7 @@ static u16 vdpasim_get_vq_size(struct vdpa_device *vdpa,
> u16 idx)
> return VDPASIM_QUEUE_MAX;
> }
>
> -static void vdpasim_kick_vq(struct vdpa_device *vdpa, u16 idx)
> +static void vdpasim_do_kick_vq(struct vdpa_device *vdpa, u16 idx)
> {
> struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
> struct vdpasim_virtqueue *vq = >vqs[idx];
> @@ -337,6 +337,15 @@ static void vdpasim_kick_vq(struct vdpa_device *vdpa,
> u16 idx)
> vdpasim_schedule_work(vdpasim);
> }
>
> +static void vdpasim_kick_vq(struct vdpa_device *vdpa, u16 idx)
> +{
> + struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
> +
> + spin_lock(>kick_lock);
> + vdpasim_do_kick_vq(vdpa, idx);
> + spin_unlock(>kick_lock);
> +}
> +
> static void vdpasim_set_vq_cb(struct vdpa_device *vdpa, u16 idx,
> struct vdpa_callback *cb)
> {
> @@ -520,8 +529,11 @@ static int vdpasim_suspend(struct vdpa_device *vdpa)
> struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
>
> mutex_lock(>mutex);
> + spin_lock(>kick_lock);
> vdpasim->running = false;
> + spin_unlock(>kick_lock);
> mutex_unlock(>mutex);
> + kthread_flush_work(>work);
>
> return 0;
> }
> @@ -537,7 +549,7 @@ static int vdpasim_resume(struct vdpa_device *vdpa)
> if (vdpasim->pending_kick) {
> /* Process pending descriptors */
> for (i = 0; i < vdpasim->dev_attr.nvqs; ++i)
> - vdpasim_kick_vq(vdpa, i);
> + vdpasim_do_kick_vq(vdpa, i);
>
> vdpasim->pending_kick = false;
> }
> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.h
> b/drivers/vdpa/vdpa_sim/vdpa_sim.h
> index bb137e479763..5eb6ca9c5ec5 100644
> --- a/drivers/vdpa/vdpa_sim/vdpa_sim.h
> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.h
> @@ -75,6 +75,7 @@ struct vdpasim {
> bool pending_kick;
> /* spinlock to synchronize iommu table */
> spinlock_t iommu_lock;
> + spinlock_t kick_lock;
It looks to me this is not initialized?
Thanks
> };
>
> struct vdpasim *vdpasim_create(struct vdpasim_dev_attr *attr,
> --
> 2.39.3
>
Re: [PATCH V3 2/3] vduse: suspend
On Mon, May 20, 2024 at 11:21 PM Steve Sistare
wrote:
>
> Support the suspend operation. There is little to do, except flush to
> guarantee no workers are running when suspend returns.
>
> Signed-off-by: Steve Sistare
> ---
> drivers/vdpa/vdpa_user/vduse_dev.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c
> b/drivers/vdpa/vdpa_user/vduse_dev.c
> index 73c89701fc9d..7dc46f771f12 100644
> --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> @@ -472,6 +472,18 @@ static void vduse_dev_reset(struct vduse_dev *dev)
> up_write(>rwsem);
> }
>
> +static void vduse_flush_work(struct vduse_dev *dev)
> +{
> + flush_work(>inject);
> +
> + for (int i = 0; i < dev->vq_num; i++) {
> + struct vduse_virtqueue *vq = dev->vqs[i];
> +
> + flush_work(>inject);
> + flush_work(>kick);
> + }
> +}
> +
> static int vduse_vdpa_set_vq_address(struct vdpa_device *vdpa, u16 idx,
> u64 desc_area, u64 driver_area,
> u64 device_area)
> @@ -724,6 +736,17 @@ static int vduse_vdpa_reset(struct vdpa_device *vdpa)
> return ret;
> }
>
> +static int vduse_vdpa_suspend(struct vdpa_device *vdpa)
> +{
> + struct vduse_dev *dev = vdpa_to_vduse(vdpa);
> +
> + down_write(>rwsem);
> + vduse_flush_work(dev);
> + up_write(>rwsem);
Can this forbid the new work to be scheduled?
static int vduse_dev_queue_irq_work(struct vduse_dev *dev,
struct work_struct *irq_work,
int irq_effective_cpu)
{
int ret = -EINVAL;
down_read(>rwsem);
if (!(dev->status & VIRTIO_CONFIG_S_DRIVER_OK))
goto unlock;
ret = 0;
if (irq_effective_cpu == IRQ_UNBOUND)
queue_work(vduse_irq_wq, irq_work);
else
queue_work_on(irq_effective_cpu,
vduse_irq_bound_wq, irq_work);
unlock:
up_read(>rwsem);
return ret;
}
Thanks
> +
> + return 0;
> +}
> +
> static u32 vduse_vdpa_get_generation(struct vdpa_device *vdpa)
> {
> struct vduse_dev *dev = vdpa_to_vduse(vdpa);
> @@ -806,6 +829,7 @@ static const struct vdpa_config_ops vduse_vdpa_config_ops
> = {
> .set_vq_affinity= vduse_vdpa_set_vq_affinity,
> .get_vq_affinity= vduse_vdpa_get_vq_affinity,
> .reset = vduse_vdpa_reset,
> + .suspend= vduse_vdpa_suspend,
> .set_map= vduse_vdpa_set_map,
> .free = vduse_vdpa_free,
> };
> --
> 2.39.3
>
Re: [PATCH V3 1/3] vhost-vdpa: flush workers on suspend
On Mon, May 20, 2024 at 11:21 PM Steve Sistare
wrote:
>
> Flush to guarantee no workers are running when suspend returns.
>
> Fixes: f345a0143b4d ("vhost-vdpa: uAPI to suspend the device")
> Signed-off-by: Steve Sistare
> Acked-by: Eugenio Pérez
> ---
> drivers/vhost/vdpa.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> index ba52d128aeb7..189596caaec9 100644
> --- a/drivers/vhost/vdpa.c
> +++ b/drivers/vhost/vdpa.c
> @@ -594,6 +594,7 @@ static long vhost_vdpa_suspend(struct vhost_vdpa *v)
> struct vdpa_device *vdpa = v->vdpa;
> const struct vdpa_config_ops *ops = vdpa->config;
> int ret;
> + struct vhost_dev *vdev = >vdev;
>
> if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK))
> return 0;
> @@ -601,6 +602,8 @@ static long vhost_vdpa_suspend(struct vhost_vdpa *v)
> if (!ops->suspend)
> return -EOPNOTSUPP;
>
> + vhost_dev_flush(vdev);
vhost-vDPA doesn't use workers, see:
vhost_dev_init(dev, vqs, nvqs, 0, 0, 0, false,
vhost_vdpa_process_iotlb_msg);
So I wonder if this is a must.
Thanks
> +
> ret = ops->suspend(vdpa);
> if (!ret)
> v->suspended = true;
> --
> 2.39.3
>
Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support
On Mon, 2024-05-20 at 00:18 +0200, Jiri Olsa wrote: > anyway I think we can fix that in another way by using the optimized > trampoline, > but returning to the user space through iret when shadow stack is detected > (as I did in the first version, before you adjusted it to the sysret path). > > we need to update the return address on stack only when returning through the > trampoline, but we can jump to original return address directly from syscall > through iret.. which is slower, but with shadow stack we don't care > > basically the only change is adding the shstk_is_enabled check to the > following condition in SYSCALL_DEFINE0(uretprobe): > > if (regs->sp != sp || shstk_is_enabled()) > return regs->ax; On the surface it sounds reasonable. Thanks. And then I guess if tradeoffs are seen differently in the future, and we want to enable the fast path for shadow stack we can go with your other solution. So this just simply fixes things functionally without much code.
Re: [PATCH 2/4] perf,uprobes: fix user stack traces in the presence of pending uretprobes
On Mon, May 20, 2024 at 8:20 AM Jiri Olsa wrote:
>
> On Wed, May 15, 2024 at 08:32:30AM -0600, Andrii Nakryiko wrote:
> > On Wed, May 15, 2024 at 3:30 AM Peter Zijlstra wrote:
> > >
> > > On Wed, May 08, 2024 at 02:26:03PM -0700, Andrii Nakryiko wrote:
> > >
> > > > +static void fixup_uretprobe_trampoline_entries(struct
> > > > perf_callchain_entry *entry,
> > > > +int start_entry_idx)
> > > > +{
> > > > +#ifdef CONFIG_UPROBES
> > > > + struct uprobe_task *utask = current->utask;
> > > > + struct return_instance *ri;
> > > > + __u64 *cur_ip, *last_ip, tramp_addr;
> > > > +
> > > > + if (likely(!utask || !utask->return_instances))
> > > > + return;
> > > > +
> > > > + cur_ip = >ip[start_entry_idx];
> > > > + last_ip = >ip[entry->nr - 1];
> > > > + ri = utask->return_instances;
> > > > + tramp_addr = uprobe_get_trampoline_vaddr();
> > > > +
> > > > + /* If there are pending uretprobes for current thread, they are
> > >
> > > Comment style fail. Also 'for *the* current thread'.
> > >
> >
> > ack, will fix
> >
> > > > + * recorded in a list inside utask->return_instances; each such
> > > > + * pending uretprobe replaces traced user function's return
> > > > address on
> > > > + * the stack, so when stack trace is captured, instead of seeing
> > > > + * actual function's return address, we'll have one or many
> > > > uretprobe
> > > > + * trampoline addresses in the stack trace, which are not helpful
> > > > and
> > > > + * misleading to users.
> > >
> > > I would beg to differ, what if the uprobe is causing the performance
> > > issue?
> >
> > If uprobe/uretprobe code itself is causing performance issues, you'll
> > see that in other stack traces, where this code will be actively
> > running on CPU. I don't think we make anything worse here.
>
> I think we do similar thing in kernel unwind for rethook trampoline used
> in fprobe/kretprobe code, so seems ok to me to do it for uprobes as well
>
> >
> > Here we are talking about the case where the uprobe part is done and
> > it hijacked the return address on the stack, uretprobe is not yet
> > running (and so not causing any performance issues). The presence of
> > this "snooping" (pending) uretprobe is irrelevant to the user that is
> > capturing stack trace. Right now address in [uprobes] VMA section
> > installed by uretprobe infra code is directly replacing correct and
> > actual calling function address.
> >
> > Worst case, one can argue that both [uprobes] and original caller
> > address should be in the stack trace, but I think it still will be
> > confusing to users. And also will make implementation less efficient
> > because now we'll need to insert entries into the array and shift
> > everything around.
>
> agreed this would be confusing.. also as you noted above the return
> trampoline did not get executed yet at the time of the callstack,
> so it's bit misleading
>
> might be stupid idea.. but we do have the 'special' context entries
> that we store in the callstack to mark user/kernel/guest context ..
only when explicitly requested (add_mark argument to
get_perf_callchain), right? BPF doesn't ever set this to true and
generally speaking users don't care and shouldn't care about pending
uretprobe. I think we are conflating unrelated things here, uretprobe
is not running, so it's not really in the stack trace. I'd just do
nothing about it, it should stay transparent.
If uretprobe *handler* is causing issues, you'll see that in all the
other stack traces (according to relative CPU/resource usage of that
handler).
> maybe we could add some special entry (context does not fit too well)
> to point out there's uretprobe going on .. perf tool could print
> 'uretprobe' hint when displaying the original address
>
> jirka
>
> >
> > So as I mentioned above, if the concern is seeing uprobe/uretprobe
> > code using CPU, that doesn't change, we'll see that in the overall set
> > of captured stack traces (be it custom uprobe handler code or BPF
> > program).
> >
> > >
> > > While I do think it makes sense to fix the unwind in the sense that we
> > > should be able to continue the unwind, I don't think it makes sense to
> > > completely hide the presence of uprobes.
> >
> > Unwind isn't broken in this sense, we do unwind the entire stack trace
> > (see examples in the later patch). We just don't capture actual
> > callers if they have uretprobe pending.
> >
> > >
> > > > + * So here we go over the pending list of uretprobes, and each
> > > > + * encountered trampoline address is replaced with actual return
> > > > + * address.
> > > > + */
> > > > + while (ri && cur_ip <= last_ip) {
> > > > + if (*cur_ip == tramp_addr) {
> > > > + *cur_ip = ri->orig_ret_vaddr;
> > > > + ri = ri->next;
> > > > + }
> > > > + cur_ip++;
> > > > + }
> > >
Re: [PATCH v3 4/6] module: script to generate offset ranges for builtin modules
On Fri, May 17, 2024 at 1:31 PM Kris Van Hees wrote:
>
> The offset range data for builtin modules is generated using:
> - modules.builtin.modinfo: associates object files with module names
> - vmlinux.map: provides load order of sections and offset of first member
> per section
> - vmlinux.o.map: provides offset of object file content per section
> - .*.cmd: build cmd file with KBUILD_MODFILE and KBUILD_MODNAME
>
> The generated data will look like:
>
> .text - = _text
> .text baf0-cb10 amd_uncore
> .text 0009bd10-0009c8e0 iosf_mbi
> ...
> .text 008e6660-008e9630 snd_soc_wcd_mbhc
> .text 008e9630-008ea610 snd_soc_wcd9335 snd_soc_wcd934x snd_soc_wcd938x
> .text 008ea610-008ea780 snd_soc_wcd9335
> ...
> .data - = _sdata
> .data f020-f680 amd_uncore
>
> For each ELF section, it lists the offset of the first symbol. This can
> be used to determine the base address of the section at runtime.
>
> Next, it lists (in strict ascending order) offset ranges in that section
> that cover the symbols of one or more builtin modules. Multiple ranges
> can apply to a single module, and ranges can be shared between modules.
>
> Signed-off-by: Kris Van Hees
> Reviewed-by: Nick Alcock
> ---
> Changes since v2:
> - 1st arg to generate_builtin_ranges.awk is now modules.builtin.modinfo
> - Switched from using modules.builtin.objs to parsing .*.cmd files
> - Parse data from .*.cmd in generate_builtin_ranges.awk
> ---
> scripts/generate_builtin_ranges.awk | 232
> 1 file changed, 232 insertions(+)
> create mode 100755 scripts/generate_builtin_ranges.awk
>
> diff --git a/scripts/generate_builtin_ranges.awk
> b/scripts/generate_builtin_ranges.awk
> new file mode 100755
> index 0..6975a9c7266d9
> --- /dev/null
> +++ b/scripts/generate_builtin_ranges.awk
> @@ -0,0 +1,232 @@
> +#!/usr/bin/gawk -f
> +# SPDX-License-Identifier: GPL-2.0
> +# generate_builtin_ranges.awk: Generate address range data for builtin
> modules
> +# Written by Kris Van Hees
> +#
> +# Usage: generate_builtin_ranges.awk modules.builtin.modinfo vmlinux.map \
> +# vmlinux.o.map > modules.builtin.ranges
> +#
> +
> +BEGIN {
> + # modules.builtin.modinfo uses \0 as record separator
> + # All other files use \n.
> + RS = "[\n\0]";
> +}
Why do you want to parse modules.builtin.modinfo
instead of modules.builtin?
modules.builtin uses \n separator.
> +
> +# Return the module name(s) (if any) associated with the given object.
> +#
> +# If we have seen this object before, return information from the cache.
> +# Otherwise, retrieve it from the corresponding .cmd file.
> +#
> +function get_module_info(fn, mod, obj, mfn, s) {
There are 5 arguments, while the caller passes only 1 argument
( get_module_info($4) )
> + if (fn in omod)
> + return omod[fn];
> +
> + if (match(fn, /\/[^/]+$/) == 0)
> + return "";
> +
> + obj = fn;
> + mod = "";
> + mfn = "";
> + fn = substr(fn, 1, RSTART) "." substr(fn, RSTART + 1) ".cmd";
> + if (getline s + if (match(s, /DKBUILD_MODNAME=[^ ]+/) > 0) {
> + mod = substr(s, RSTART + 17, RLENGTH - 17);
> + gsub(/['"]/, "", mod);
> + gsub(/:/, " ", mod);
> + }
> +
> + if (match(s, /DKBUILD_MODFILE=[^ ]+/) > 0) {
> + mfn = substr(s, RSTART + 17, RLENGTH - 17);
> + gsub(/['"]/, "", mfn);
> + gsub(/:/, " ", mfn);
> + }
> + }
> + close(fn);
> +
> +# tmp = $0;
> +# $0 = s;
> +# print mod " " mfn " " obj " " $NF;
> +# $0 = tmp;
> +
> + # A single module (common case) also reflects objects that are not
> part
> + # of a module. Some of those objects have names that are also a
> module
> + # name (e.g. core). We check the associated module file name, and if
> + # they do not match, the object is not part of a module.
You do not need to use KBUILD_MODNAME.
Just use KBUILD_MODFILE only.
If the same path is found in modules.builtin,
it is a built-in module.
Its basename is modname.
One more question in a corner case.
How does your code work when an object is shared
by multiple modules?
For example, set
CONFIG_EDAC_SKX=y
CONFIG_EDAC_I10NM=y
How is the address range of drivers/edac/skx_common.o handled?
There are 4 possibilities.
- included in skx_edac
- included in i10nm_edac
- included in both of them
- not included in any of them
The correct behavior should be "included in both of them".
How does your code work?
> + if (mod !~ / /) {
> + if (!(mod in mods))
> + return "";
> + if (mods[mod] != mfn)
> + return "";
> + }
> +
> + # At this point, mod is a single (valid) module name, or a list of
> +
[PATCH V3 3/3] vdpa_sim: flush workers on suspend
Flush to guarantee no workers are running when suspend returns.
Add a lock to enforce ordering between clearing running, flushing,
and posting new work in vdpasim_kick_vq. It must be a spin lock
because vdpasim_kick_vq may be reached va eventfd_write.
Signed-off-by: Steve Sistare
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 16 ++--
drivers/vdpa/vdpa_sim/vdpa_sim.h | 1 +
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 8ffea8430f95..67ed49d95bf0 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -322,7 +322,7 @@ static u16 vdpasim_get_vq_size(struct vdpa_device *vdpa,
u16 idx)
return VDPASIM_QUEUE_MAX;
}
-static void vdpasim_kick_vq(struct vdpa_device *vdpa, u16 idx)
+static void vdpasim_do_kick_vq(struct vdpa_device *vdpa, u16 idx)
{
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
struct vdpasim_virtqueue *vq = >vqs[idx];
@@ -337,6 +337,15 @@ static void vdpasim_kick_vq(struct vdpa_device *vdpa, u16
idx)
vdpasim_schedule_work(vdpasim);
}
+static void vdpasim_kick_vq(struct vdpa_device *vdpa, u16 idx)
+{
+ struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
+
+ spin_lock(>kick_lock);
+ vdpasim_do_kick_vq(vdpa, idx);
+ spin_unlock(>kick_lock);
+}
+
static void vdpasim_set_vq_cb(struct vdpa_device *vdpa, u16 idx,
struct vdpa_callback *cb)
{
@@ -520,8 +529,11 @@ static int vdpasim_suspend(struct vdpa_device *vdpa)
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
mutex_lock(>mutex);
+ spin_lock(>kick_lock);
vdpasim->running = false;
+ spin_unlock(>kick_lock);
mutex_unlock(>mutex);
+ kthread_flush_work(>work);
return 0;
}
@@ -537,7 +549,7 @@ static int vdpasim_resume(struct vdpa_device *vdpa)
if (vdpasim->pending_kick) {
/* Process pending descriptors */
for (i = 0; i < vdpasim->dev_attr.nvqs; ++i)
- vdpasim_kick_vq(vdpa, i);
+ vdpasim_do_kick_vq(vdpa, i);
vdpasim->pending_kick = false;
}
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.h b/drivers/vdpa/vdpa_sim/vdpa_sim.h
index bb137e479763..5eb6ca9c5ec5 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.h
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.h
@@ -75,6 +75,7 @@ struct vdpasim {
bool pending_kick;
/* spinlock to synchronize iommu table */
spinlock_t iommu_lock;
+ spinlock_t kick_lock;
};
struct vdpasim *vdpasim_create(struct vdpasim_dev_attr *attr,
--
2.39.3
[PATCH V3 2/3] vduse: suspend
Support the suspend operation. There is little to do, except flush to
guarantee no workers are running when suspend returns.
Signed-off-by: Steve Sistare
---
drivers/vdpa/vdpa_user/vduse_dev.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c
b/drivers/vdpa/vdpa_user/vduse_dev.c
index 73c89701fc9d..7dc46f771f12 100644
--- a/drivers/vdpa/vdpa_user/vduse_dev.c
+++ b/drivers/vdpa/vdpa_user/vduse_dev.c
@@ -472,6 +472,18 @@ static void vduse_dev_reset(struct vduse_dev *dev)
up_write(>rwsem);
}
+static void vduse_flush_work(struct vduse_dev *dev)
+{
+ flush_work(>inject);
+
+ for (int i = 0; i < dev->vq_num; i++) {
+ struct vduse_virtqueue *vq = dev->vqs[i];
+
+ flush_work(>inject);
+ flush_work(>kick);
+ }
+}
+
static int vduse_vdpa_set_vq_address(struct vdpa_device *vdpa, u16 idx,
u64 desc_area, u64 driver_area,
u64 device_area)
@@ -724,6 +736,17 @@ static int vduse_vdpa_reset(struct vdpa_device *vdpa)
return ret;
}
+static int vduse_vdpa_suspend(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ down_write(>rwsem);
+ vduse_flush_work(dev);
+ up_write(>rwsem);
+
+ return 0;
+}
+
static u32 vduse_vdpa_get_generation(struct vdpa_device *vdpa)
{
struct vduse_dev *dev = vdpa_to_vduse(vdpa);
@@ -806,6 +829,7 @@ static const struct vdpa_config_ops vduse_vdpa_config_ops =
{
.set_vq_affinity= vduse_vdpa_set_vq_affinity,
.get_vq_affinity= vduse_vdpa_get_vq_affinity,
.reset = vduse_vdpa_reset,
+ .suspend= vduse_vdpa_suspend,
.set_map= vduse_vdpa_set_map,
.free = vduse_vdpa_free,
};
--
2.39.3
[PATCH V3 0/3] flush workers on suspend
Flush to guarantee no workers are running when suspend returns, for vdpa, vdpa_sim, and vduse. (mlx5 already does so, via the path mlx5_vdpa_suspend -> unregister_link_notifier -> flush_workqueue.) Changes in V2: - renamed "vduse: suspend" (was vduse: flush workers on suspend) - call vhost_dev_flush unconditionally in "vhost-vdpa: flush workers on suspend" Changes in v3: - rewrote vdpa_sim patch Steve Sistare (3): vhost-vdpa: flush workers on suspend vduse: suspend vdpa_sim: flush workers on suspend drivers/vdpa/vdpa_sim/vdpa_sim.c | 16 ++-- drivers/vdpa/vdpa_sim/vdpa_sim.h | 1 + drivers/vdpa/vdpa_user/vduse_dev.c | 24 drivers/vhost/vdpa.c | 3 +++ 4 files changed, 42 insertions(+), 2 deletions(-) -- 2.39.3
[PATCH V3 1/3] vhost-vdpa: flush workers on suspend
Flush to guarantee no workers are running when suspend returns.
Fixes: f345a0143b4d ("vhost-vdpa: uAPI to suspend the device")
Signed-off-by: Steve Sistare
Acked-by: Eugenio Pérez
---
drivers/vhost/vdpa.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index ba52d128aeb7..189596caaec9 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -594,6 +594,7 @@ static long vhost_vdpa_suspend(struct vhost_vdpa *v)
struct vdpa_device *vdpa = v->vdpa;
const struct vdpa_config_ops *ops = vdpa->config;
int ret;
+ struct vhost_dev *vdev = >vdev;
if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK))
return 0;
@@ -601,6 +602,8 @@ static long vhost_vdpa_suspend(struct vhost_vdpa *v)
if (!ops->suspend)
return -EOPNOTSUPP;
+ vhost_dev_flush(vdev);
+
ret = ops->suspend(vdpa);
if (!ret)
v->suspended = true;
--
2.39.3
Re: [PATCH 3/4] perf,x86: avoid missing caller address in stack traces captured in uprobe
On Wed, May 08, 2024 at 02:26:04PM -0700, Andrii Nakryiko wrote:
> When tracing user functions with uprobe functionality, it's common to
> install the probe (e.g., a BPF program) at the first instruction of the
> function. This is often going to be `push %rbp` instruction in function
> preamble, which means that within that function frame pointer hasn't
> been established yet. This leads to consistently missing an actual
> caller of the traced function, because perf_callchain_user() only
> records current IP (capturing traced function) and then following frame
> pointer chain (which would be caller's frame, containing the address of
> caller's caller).
>
> So when we have target_1 -> target_2 -> target_3 call chain and we are
> tracing an entry to target_3, captured stack trace will report
> target_1 -> target_3 call chain, which is wrong and confusing.
>
> This patch proposes a x86-64-specific heuristic to detect `push %rbp`
> instruction being traced. If that's the case, with the assumption that
> applicatoin is compiled with frame pointers, this instruction would be
> a strong indicator that this is the entry to the function. In that case,
> return address is still pointed to by %rsp, so we fetch it and add to
> stack trace before proceeding to unwind the rest using frame
> pointer-based logic.
>
> Signed-off-by: Andrii Nakryiko
> ---
> arch/x86/events/core.c | 20
> include/linux/uprobes.h | 2 ++
> kernel/events/uprobes.c | 2 ++
> 3 files changed, 24 insertions(+)
>
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index 5b0dd07b1ef1..82d5570b58ff 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -2884,6 +2884,26 @@ perf_callchain_user(struct perf_callchain_entry_ctx
> *entry, struct pt_regs *regs
> return;
>
> pagefault_disable();
> +
> +#ifdef CONFIG_UPROBES
> + /*
> + * If we are called from uprobe handler, and we are indeed at the very
> + * entry to user function (which is normally a `push %rbp` instruction,
> + * under assumption of application being compiled with frame pointers),
> + * we should read return address from *regs->sp before proceeding
> + * to follow frame pointers, otherwise we'll skip immediate caller
> + * as %rbp is not yet setup.
> + */
> + if (current->utask) {
> + struct arch_uprobe *auprobe = current->utask->auprobe;
> + u64 ret_addr;
> +
> + if (auprobe && auprobe->insn[0] == 0x55 /* push %rbp */ &&
nice cactch, I was wondering if we should set some auprobe flag in
arch_uprobe_analyze_insn and test it here instead of matching the
instruction opcode directly, but that would probably be just more
complicated.. this is simple and in arch code, no np
jirka
> + !__get_user(ret_addr, (const u64 __user *)regs->sp))
> + perf_callchain_store(entry, ret_addr);
> + }
> +#endif
> +
> while (entry->nr < entry->max_stack) {
> if (!valid_user_frame(fp, sizeof(frame)))
> break;
> diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
> index 0c57eec85339..7b785cd30d86 100644
> --- a/include/linux/uprobes.h
> +++ b/include/linux/uprobes.h
> @@ -76,6 +76,8 @@ struct uprobe_task {
> struct uprobe *active_uprobe;
> unsigned long xol_vaddr;
>
> + struct arch_uprobe *auprobe;
> +
> struct return_instance *return_instances;
> unsigned intdepth;
> };
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 1c99380dc89d..504693845187 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -2072,6 +2072,7 @@ static void handler_chain(struct uprobe *uprobe, struct
> pt_regs *regs)
> bool need_prep = false; /* prepare return uprobe, when needed */
>
> down_read(>register_rwsem);
> + current->utask->auprobe = >arch;
> for (uc = uprobe->consumers; uc; uc = uc->next) {
> int rc = 0;
>
> @@ -2086,6 +2087,7 @@ static void handler_chain(struct uprobe *uprobe, struct
> pt_regs *regs)
>
> remove &= rc;
> }
> + current->utask->auprobe = NULL;
>
> if (need_prep && !remove)
> prepare_uretprobe(uprobe, regs); /* put bp at return */
> --
> 2.43.0
>
>
Re: [PATCH 2/4] perf,uprobes: fix user stack traces in the presence of pending uretprobes
On Wed, May 15, 2024 at 08:32:30AM -0600, Andrii Nakryiko wrote:
> On Wed, May 15, 2024 at 3:30 AM Peter Zijlstra wrote:
> >
> > On Wed, May 08, 2024 at 02:26:03PM -0700, Andrii Nakryiko wrote:
> >
> > > +static void fixup_uretprobe_trampoline_entries(struct
> > > perf_callchain_entry *entry,
> > > +int start_entry_idx)
> > > +{
> > > +#ifdef CONFIG_UPROBES
> > > + struct uprobe_task *utask = current->utask;
> > > + struct return_instance *ri;
> > > + __u64 *cur_ip, *last_ip, tramp_addr;
> > > +
> > > + if (likely(!utask || !utask->return_instances))
> > > + return;
> > > +
> > > + cur_ip = >ip[start_entry_idx];
> > > + last_ip = >ip[entry->nr - 1];
> > > + ri = utask->return_instances;
> > > + tramp_addr = uprobe_get_trampoline_vaddr();
> > > +
> > > + /* If there are pending uretprobes for current thread, they are
> >
> > Comment style fail. Also 'for *the* current thread'.
> >
>
> ack, will fix
>
> > > + * recorded in a list inside utask->return_instances; each such
> > > + * pending uretprobe replaces traced user function's return address
> > > on
> > > + * the stack, so when stack trace is captured, instead of seeing
> > > + * actual function's return address, we'll have one or many
> > > uretprobe
> > > + * trampoline addresses in the stack trace, which are not helpful
> > > and
> > > + * misleading to users.
> >
> > I would beg to differ, what if the uprobe is causing the performance
> > issue?
>
> If uprobe/uretprobe code itself is causing performance issues, you'll
> see that in other stack traces, where this code will be actively
> running on CPU. I don't think we make anything worse here.
I think we do similar thing in kernel unwind for rethook trampoline used
in fprobe/kretprobe code, so seems ok to me to do it for uprobes as well
>
> Here we are talking about the case where the uprobe part is done and
> it hijacked the return address on the stack, uretprobe is not yet
> running (and so not causing any performance issues). The presence of
> this "snooping" (pending) uretprobe is irrelevant to the user that is
> capturing stack trace. Right now address in [uprobes] VMA section
> installed by uretprobe infra code is directly replacing correct and
> actual calling function address.
>
> Worst case, one can argue that both [uprobes] and original caller
> address should be in the stack trace, but I think it still will be
> confusing to users. And also will make implementation less efficient
> because now we'll need to insert entries into the array and shift
> everything around.
agreed this would be confusing.. also as you noted above the return
trampoline did not get executed yet at the time of the callstack,
so it's bit misleading
might be stupid idea.. but we do have the 'special' context entries
that we store in the callstack to mark user/kernel/guest context ..
maybe we could add some special entry (context does not fit too well)
to point out there's uretprobe going on .. perf tool could print
'uretprobe' hint when displaying the original address
jirka
>
> So as I mentioned above, if the concern is seeing uprobe/uretprobe
> code using CPU, that doesn't change, we'll see that in the overall set
> of captured stack traces (be it custom uprobe handler code or BPF
> program).
>
> >
> > While I do think it makes sense to fix the unwind in the sense that we
> > should be able to continue the unwind, I don't think it makes sense to
> > completely hide the presence of uprobes.
>
> Unwind isn't broken in this sense, we do unwind the entire stack trace
> (see examples in the later patch). We just don't capture actual
> callers if they have uretprobe pending.
>
> >
> > > + * So here we go over the pending list of uretprobes, and each
> > > + * encountered trampoline address is replaced with actual return
> > > + * address.
> > > + */
> > > + while (ri && cur_ip <= last_ip) {
> > > + if (*cur_ip == tramp_addr) {
> > > + *cur_ip = ri->orig_ret_vaddr;
> > > + ri = ri->next;
> > > + }
> > > + cur_ip++;
> > > + }
> > > +#endif
> > > +}
>
Re: [PATCH v3 2/2] remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs
On Sat, 18 May 2024 at 04:44, Christophe JAILLET
wrote:
>
> Le 30/04/2024 à 12:53, Beleswar Padhi a écrit :
> > PSC controller has a limitation that it can only power-up the second
> > core when the first core is in ON state. Power-state for core0 should be
> > equal to or higher than core1.
> >
> > Therefore, prevent core1 from powering up before core0 during the start
> > process from sysfs. Similarly, prevent core0 from shutting down before
> > core1 has been shut down from sysfs.
> >
> > Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F
> > subsystem")
> >
> > Signed-off-by: Beleswar Padhi
> > ---
> > drivers/remoteproc/ti_k3_r5_remoteproc.c | 23 +--
> > 1 file changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > index 6d6afd6beb3a..1799b4f6d11e 100644
> > --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > @@ -548,7 +548,7 @@ static int k3_r5_rproc_start(struct rproc *rproc)
> > struct k3_r5_rproc *kproc = rproc->priv;
> > struct k3_r5_cluster *cluster = kproc->cluster;
> > struct device *dev = kproc->dev;
> > - struct k3_r5_core *core;
> > + struct k3_r5_core *core0, *core;
> > u32 boot_addr;
> > int ret;
> >
> > @@ -574,6 +574,15 @@ static int k3_r5_rproc_start(struct rproc *rproc)
> > goto unroll_core_run;
> > }
> > } else {
> > + /* do not allow core 1 to start before core 0 */
> > + core0 = list_first_entry(>cores, struct k3_r5_core,
> > + elem);
> > + if (core != core0 && core0->rproc->state == RPROC_OFFLINE) {
> > + dev_err(dev, "%s: can not start core 1 before core
> > 0\n",
> > + __func__);
> > + return -EPERM;
> > + }
> > +
> > ret = k3_r5_core_run(core);
> > if (ret)
> > goto put_mbox;
> > @@ -619,7 +628,8 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
> > {
> > struct k3_r5_rproc *kproc = rproc->priv;
> > struct k3_r5_cluster *cluster = kproc->cluster;
> > - struct k3_r5_core *core = kproc->core;
> > + struct device *dev = kproc->dev;
> > + struct k3_r5_core *core1, *core = kproc->core;
> > int ret;
> >
> > /* halt all applicable cores */
> > @@ -632,6 +642,15 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
> > }
> > }
> > } else {
> > + /* do not allow core 0 to stop before core 1 */
> > + core1 = list_last_entry(>cores, struct k3_r5_core,
> > + elem);
> > + if (core != core1 && core1->rproc->state != RPROC_OFFLINE) {
> > + dev_err(dev, "%s: can not stop core 0 before core
> > 1\n",
> > + __func__);
> > + return -EPERM;
>
> Hi,
>
> this patch has already reached -next, but should this "return -EPERM;" be :
> ret = -EPERM;
> goto put_mbox;
>
> instead?
>
This has already been addressed:
https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git/commit/?h=rproc-next=1dc7242f6ee0c99852cb90676d7fe201cf5de422
> CJ
>
> > + }
> > +
> > ret = k3_r5_core_halt(core);
> > if (ret)
> > goto out;
>
Re: [PATCH RFC 1/2] dt-bindings: soc: qcom,smsm: Allow specifying mboxes instead of qcom,ipc
On Montag, 20. Mai 2024 08:46:39 MESZ Krzysztof Kozlowski wrote: > On 15/05/2024 17:06, Luca Weiss wrote: > > Hi Rob, > > > > Any feedback on the below topic? > > Can be explained in description, like > mboxes: > description: Each entry corresponds to one remote processor > maxItems: 5 Hi Krzysztof Ack, sounds good. Maybe also from you, any opinion between these two binding styles? So first using index of mboxes for the numbering, where for the known usages the first element (and sometimes the 3rd - ipc-2) are empty <>. The second variant is using mbox-names to get the correct channel-mbox mapping. - qcom,ipc-1 = < 8 13>; - qcom,ipc-2 = < 8 9>; - qcom,ipc-3 = < 8 19>; + mboxes = <0>, < 13>, < 9>, < 19>; vs. - qcom,ipc-1 = < 8 13>; - qcom,ipc-2 = < 8 9>; - qcom,ipc-3 = < 8 19>; + mboxes = < 13>, < 9>, < 19>; + mbox-names = "ipc-1", "ipc-2", "ipc-3"; Regards Luca > > Best regards, > Krzysztof > >
Re: [PATCH] rpmsg: char: fix rpmsg_eptdev structure documentation
On 5/17/2024 10:26 PM, Arnaud Pouliquen wrote:
Add missing @ tags for some rpmsg_eptdev structure parameters.
This fixes warning messages on build:
drivers/rpmsg/rpmsg_char.c:75: warning: Function parameter or struct member
'remote_flow_restricted' not described in 'rpmsg_eptdev'
drivers/rpmsg/rpmsg_char.c:75: warning: Function parameter or struct member
'remote_flow_updated' not described in 'rpmsg_eptdev'
Fixes: 5550201c0fe2 ("rpmsg: char: Add RPMSG GET/SET FLOWCONTROL IOCTL support")
Signed-off-by: Arnaud Pouliquen
Reviewed-by: Mukesh Ojha
-Mukesh
Re: [PATCH] remoteproc: mediatek: Zero out only remaining bytes of IPI buffer
On 5/20/2024 4:57 PM, AngeloGioacchino Del Regno wrote: In scp_ipi_handler(), instead of zeroing out the entire shared buffer, which may be as large as 600 bytes, overwrite it with the received data, then zero out only the remaining bytes. Signed-off-by: AngeloGioacchino Del Regno --- drivers/remoteproc/mtk_scp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c index e5214d43181e..dc70cf7db44d 100644 --- a/drivers/remoteproc/mtk_scp.c +++ b/drivers/remoteproc/mtk_scp.c @@ -117,8 +117,8 @@ static void scp_ipi_handler(struct mtk_scp *scp) return; } - memset(scp->share_buf, 0, scp_sizes->ipi_share_buffer_size); memcpy_fromio(scp->share_buf, _obj->share_buf, len); + memset(>share_buf[len], 0, scp_sizes->ipi_share_buffer_size - len); Although, it does not make any difference apart from a write of len bytes, still a good improvement to do .. Acked-by: Mukesh Ojha -Mukesh handler(scp->share_buf, len, ipi_desc[id].priv); scp_ipi_unlock(scp, id);
Re: UBSAN: shift-out-of-bounds in validate_sb_layout
On Mon, May 20, 2024 at 10:31:53AM -0400, Steven Rostedt wrote: > On Mon, 20 May 2024 15:02:26 +0800 > "Ubisectech Sirius" wrote: > > > Hello. > > We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. > > Recently, our team has discovered a issue in Linux kernel 6.7. Attached to > > the email were a PoC file of the issue. > > > > Stack dump: > > UBSAN: shift-out-of-bounds in fs/bcachefs/super-io.c:310:18 > > shift exponent 127 is too large for 32-bit type 'int' > > CPU: 0 PID: 14408 Comm: syz-executor.3 Not tainted 6.7.0 #2 > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 > > 04/01/2014 > > Call Trace: > > > > __dump_stack lib/dump_stack.c:88 [inline] > > dump_stack_lvl+0x136/0x150 lib/dump_stack.c:106 > > ubsan_epilogue lib/ubsan.c:217 [inline] > > __ubsan_handle_shift_out_of_bounds+0x24b/0x430 lib/ubsan.c:387 > > validate_sb_layout.cold+0x1a/0x51 fs/bcachefs/super-io.c:310 > > bch2_read_super+0x980/0x1000 fs/bcachefs/super-io.c:786 > > bch2_fs_open+0x471/0x3890 fs/bcachefs/super.c:1922 > > bch2_mount+0x538/0x13c0 fs/bcachefs/fs.c:1863 > > legacy_get_tree+0x109/0x220 fs/fs_context.c:662 > > vfs_get_tree+0x93/0x380 fs/super.c:1771 > > do_new_mount fs/namespace.c:3337 [inline] > > path_mount+0x679/0x1e40 fs/namespace.c:3664 > > do_mount fs/namespace.c:3677 [inline] > > __do_sys_mount fs/namespace.c:3886 [inline] > > __se_sys_mount fs/namespace.c:3863 [inline] > > __x64_sys_mount+0x287/0x310 fs/namespace.c:3863 > > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > > do_syscall_64+0x43/0x120 arch/x86/entry/common.c:83 > > entry_SYSCALL_64_after_hwframe+0x6f/0x77 > > RIP: 0033:0x7f41e1091b3e > > Code: 48 c7 c0 ff ff ff ff eb aa e8 be 0d 00 00 66 2e 0f 1f 84 00 00 00 00 > > 00 0f 1f 40 00 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff > > ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 > > RSP: 002b:7f41e1d22e38 EFLAGS: 0202 ORIG_RAX: 00a5 > > RAX: ffda RBX: 5d82 RCX: 7f41e1091b3e > > RDX: 20005d80 RSI: 2100 RDI: 7f41e1d22e90 > > RBP: 7f41e1d22ed0 R08: 7f41e1d22ed0 R09: 0080 > > R10: 0080 R11: 0202 R12: 20005d80 > > R13: 2100 R14: 7f41e1d22e90 R15: 20005e00 > > > > > > Thank you for taking the time to read this email and we look forward to > > working with you further. > > I'm not sure why this is getting Cc'd to linux-trace-kernel. That's for > anything to do with the tracing code (trace events, tracepoints, kprobes, > uprobes, function tracer etc). > > What part of tracing is this for? Everything I've seen from Ubisectech has been duplicates of stuff syzbot found awhile ago and is already fixed.
Re: UBSAN: shift-out-of-bounds in validate_sb_layout
On Mon, 20 May 2024 15:02:26 +0800 "Ubisectech Sirius" wrote: > Hello. > We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. > Recently, our team has discovered a issue in Linux kernel 6.7. Attached to > the email were a PoC file of the issue. > > Stack dump: > UBSAN: shift-out-of-bounds in fs/bcachefs/super-io.c:310:18 > shift exponent 127 is too large for 32-bit type 'int' > CPU: 0 PID: 14408 Comm: syz-executor.3 Not tainted 6.7.0 #2 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 > 04/01/2014 > Call Trace: > > __dump_stack lib/dump_stack.c:88 [inline] > dump_stack_lvl+0x136/0x150 lib/dump_stack.c:106 > ubsan_epilogue lib/ubsan.c:217 [inline] > __ubsan_handle_shift_out_of_bounds+0x24b/0x430 lib/ubsan.c:387 > validate_sb_layout.cold+0x1a/0x51 fs/bcachefs/super-io.c:310 > bch2_read_super+0x980/0x1000 fs/bcachefs/super-io.c:786 > bch2_fs_open+0x471/0x3890 fs/bcachefs/super.c:1922 > bch2_mount+0x538/0x13c0 fs/bcachefs/fs.c:1863 > legacy_get_tree+0x109/0x220 fs/fs_context.c:662 > vfs_get_tree+0x93/0x380 fs/super.c:1771 > do_new_mount fs/namespace.c:3337 [inline] > path_mount+0x679/0x1e40 fs/namespace.c:3664 > do_mount fs/namespace.c:3677 [inline] > __do_sys_mount fs/namespace.c:3886 [inline] > __se_sys_mount fs/namespace.c:3863 [inline] > __x64_sys_mount+0x287/0x310 fs/namespace.c:3863 > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > do_syscall_64+0x43/0x120 arch/x86/entry/common.c:83 > entry_SYSCALL_64_after_hwframe+0x6f/0x77 > RIP: 0033:0x7f41e1091b3e > Code: 48 c7 c0 ff ff ff ff eb aa e8 be 0d 00 00 66 2e 0f 1f 84 00 00 00 00 00 > 0f 1f 40 00 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 > 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 > RSP: 002b:7f41e1d22e38 EFLAGS: 0202 ORIG_RAX: 00a5 > RAX: ffda RBX: 5d82 RCX: 7f41e1091b3e > RDX: 20005d80 RSI: 2100 RDI: 7f41e1d22e90 > RBP: 7f41e1d22ed0 R08: 7f41e1d22ed0 R09: 0080 > R10: 0080 R11: 0202 R12: 20005d80 > R13: 2100 R14: 7f41e1d22e90 R15: 20005e00 > > > Thank you for taking the time to read this email and we look forward to > working with you further. I'm not sure why this is getting Cc'd to linux-trace-kernel. That's for anything to do with the tracing code (trace events, tracepoints, kprobes, uprobes, function tracer etc). What part of tracing is this for? -- Steve
Re: [PATCH 2/2] ring-buffer: Fix a race between readers and resize checks
On Fri, 17 May 2024 15:40:08 +0200
Petr Pavlu wrote:
> The reader code in rb_get_reader_page() swaps a new reader page into the
> ring buffer by doing cmpxchg on old->list.prev->next to point it to the
> new page. Following that, if the operation is successful,
> old->list.next->prev gets updated too. This means the underlying
> doubly-linked list is temporarily inconsistent, page->prev->next or
> page->next->prev might not be equal back to page for some page in the
> ring buffer.
>
> The resize operation in ring_buffer_resize() can be invoked in parallel.
> It calls rb_check_pages() which can detect the described inconsistency
> and stop further tracing:
>
> [ 190.271762] [ cut here ]
> [ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467
> rb_check_pages.isra.0+0x6a/0xa0
> [ 190.271789] Modules linked in: [...]
> [ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1
> skx_edac(E):1
> [ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G
>E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f
> [ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014
> [ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0
> [ 190.272023] Code: [...]
> [ 190.272028] RSP: 0018:9c37463abb70 EFLAGS: 00010206
> [ 190.272034] RAX: 8eba04b6cb80 RBX: 0007 RCX:
> 8eba01f13d80
> [ 190.272038] RDX: 8eba01f130c0 RSI: 8eba04b6cd00 RDI:
> 8eba0004c700
> [ 190.272042] RBP: 8eba0004c700 R08: 00010002 R09:
>
> [ 190.272045] R10: 7f52 R11: 8eba7f60 R12:
> 8eba0004c720
> [ 190.272049] R13: 8eba00223a00 R14: 0008 R15:
> 8eba067a8000
> [ 190.272053] FS: 7f1bd64752c0() GS:8eba7f68()
> knlGS:
> [ 190.272057] CS: 0010 DS: ES: CR0: 80050033
> [ 190.272061] CR2: 7f1bd6662590 CR3: 00010291e001 CR4:
> 00370ef0
> [ 190.272070] DR0: DR1: DR2:
>
> [ 190.272073] DR3: DR6: fffe0ff0 DR7:
> 0400
> [ 190.272077] Call Trace:
> [ 190.272098]
> [ 190.272189] ring_buffer_resize+0x2ab/0x460
> [ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0
> [ 190.272206] tracing_resize_ring_buffer+0x65/0x90
> [ 190.272216] tracing_entries_write+0x74/0xc0
> [ 190.272225] vfs_write+0xf5/0x420
> [ 190.272248] ksys_write+0x67/0xe0
> [ 190.272256] do_syscall_64+0x82/0x170
> [ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 190.272373] RIP: 0033:0x7f1bd657d263
> [ 190.272381] Code: [...]
> [ 190.272385] RSP: 002b:7ffe72b643f8 EFLAGS: 0246 ORIG_RAX:
> 0001
> [ 190.272391] RAX: ffda RBX: 0002 RCX:
> 7f1bd657d263
> [ 190.272395] RDX: 0002 RSI: 555a6eb538e0 RDI:
> 0001
> [ 190.272398] RBP: 555a6eb538e0 R08: 000a R09:
>
> [ 190.272401] R10: 555a6eb55190 R11: 0246 R12:
> 7f1bd6662500
> [ 190.272404] R13: 0002 R14: 7f1bd6667c00 R15:
> 0002
> [ 190.272412]
> [ 190.272414] ---[ end trace ]---
>
> Note that ring_buffer_resize() calls rb_check_pages() only if the parent
> trace_buffer has recording disabled. Recent commit d78ab792705c
> ("tracing: Stop current tracer when resizing buffer") causes that it is
> now always the case which makes it more likely to experience this issue.
>
> The window to hit this race is nonetheless very small. To help
> reproducing it, one can add a delay loop in rb_get_reader_page():
>
> ret = rb_head_page_replace(reader, cpu_buffer->reader_page);
> if (!ret)
> goto spin;
> for (unsigned i = 0; i < 1U << 26; i++) /* inserted delay loop */
> __asm__ __volatile__ ("" : : : "memory");
> rb_list_head(reader->list.next)->prev = _buffer->reader_page->list;
>
> .. and then run the following commands on the target system:
>
> echo 1 > /sys/kernel/tracing/events/sched/sched_switch/enable
> while true; do
> echo 16 > /sys/kernel/tracing/buffer_size_kb; sleep 0.1
> echo 8 > /sys/kernel/tracing/buffer_size_kb; sleep 0.1
> done &
> while true; do
> for i in /sys/kernel/tracing/per_cpu/*; do
> timeout 0.1 cat $i/trace_pipe; sleep 0.2
> done
> done
>
> To fix the problem, make sure ring_buffer_resize() doesn't invoke
> rb_check_pages() concurrently with a reader operating on the same
> ring_buffer_per_cpu by taking its cpu_buffer->reader_lock.
Definitely a bug. Thanks for catching it. But...
>
> Fixes: 659f451ff213 ("ring-buffer: Add integrity check at end of iter read")
> Signed-off-by: Petr Pavlu
> ---
> kernel/trace/ring_buffer.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git
[PATCH] remoteproc: mediatek: Zero out only remaining bytes of IPI buffer
In scp_ipi_handler(), instead of zeroing out the entire shared buffer, which may be as large as 600 bytes, overwrite it with the received data, then zero out only the remaining bytes. Signed-off-by: AngeloGioacchino Del Regno --- drivers/remoteproc/mtk_scp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c index e5214d43181e..dc70cf7db44d 100644 --- a/drivers/remoteproc/mtk_scp.c +++ b/drivers/remoteproc/mtk_scp.c @@ -117,8 +117,8 @@ static void scp_ipi_handler(struct mtk_scp *scp) return; } - memset(scp->share_buf, 0, scp_sizes->ipi_share_buffer_size); memcpy_fromio(scp->share_buf, _obj->share_buf, len); + memset(>share_buf[len], 0, scp_sizes->ipi_share_buffer_size - len); handler(scp->share_buf, len, ipi_desc[id].priv); scp_ipi_unlock(scp, id); -- 2.45.1
[PATCH] dts: imx8mq-librem5: Don't wake up on volume key press
The only key that should wake up the phone is power button press. This
prevents accidental wakeup due to e.g. pressing the buttons in the
pocket or backpack and is in line what userspace uses to unblank the
device.
Signed-off-by: Guido Günther
---
arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
index ffb5fe61630d..1b39514d5c12 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
@@ -45,7 +45,6 @@ key-vol-down {
gpios = < 17 GPIO_ACTIVE_LOW>;
linux,code = ;
debounce-interval = <50>;
- wakeup-source;
};
key-vol-up {
@@ -53,7 +52,6 @@ key-vol-up {
gpios = < 16 GPIO_ACTIVE_LOW>;
linux,code = ;
debounce-interval = <50>;
- wakeup-source;
};
};
--
2.43.0
Re: [PATCH v3 2/6] trace: add CONFIG_BUILTIN_MODULE_RANGES option
On Fri, May 17, 2024 at 1:30 PM Kris Van Hees wrote: > > The CONFIG_BUILTIN_MODULE_RANGES option controls whether offset range data > is generated for kernel modules that are built into the kernel image. > > Signed-off-by: Kris Van Hees > Reviewed-by: Nick Alcock > Reviewed-by: Alan Maguire > --- > Changes since v2: > - Add explicit dependency on FTRACE for CONFIG_BUILTIN_MODULE_RANGES > --- > kernel/trace/Kconfig | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig > index 47345bf1d4a9f..d0c82b4b3a61e 100644 > --- a/kernel/trace/Kconfig > +++ b/kernel/trace/Kconfig > @@ -188,6 +188,24 @@ menuconfig FTRACE > > if FTRACE > > +config BUILTIN_MODULE_RANGES > + bool "Generate address range information for builtin modules" > + depends on FTRACE > + select VMLINUX_MAP I still got this warning. WARNING: unmet direct dependencies detected for VMLINUX_MAP Depends on [n]: EXPERT [=n] Selected by [y]: - BUILTIN_MODULE_RANGES [=y] && FTRACE [=y] I recommend changing 'select VMLINUX_MAP' to 'depends on VMLINUX_MAP'. BTW, do you need to put this inside 'if FTRACE'? FTRACE is not required to generate the ranges file. -- Best Regards Masahiro Yamada
Re: [PATCH] livepatch: introduce klp_func called interface
OK, I will try to optimize my description after the patch is reviewed. I am sure there are something still need to be fix for that patch. > On May 20, 2024, at 16:00, Markus Elfring wrote: > > Please add a version identifier to the message subject. > > > … >> If the patched function have bug, it may cause serious result >> such as kernel crash. > > Wording suggestion: > > If the patched function has a bug, it might cause serious side effects > like a kernel crash. > > >> This is a kobject attribute of klp_func. Sysfs interface named >> "called" is introduced to livepatch … > > Under which circumstances will imperative wordings be applied for > another improved change description? > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.9#n94 > > > … >> --- >> include/linux/livepatch.h | 2 ++ > … > > You may present version descriptions behind the marker line. > Would you like to indicate any adjustments according to your change approach > (from yesterday)? > https://lore.kernel.org/lkml/20240519074343.5833-1-zhangwar...@gmail.com/ > > Regards, > Markus
Re: [PATCH v3 2/6] trace: add CONFIG_BUILTIN_MODULE_RANGES option
On Fri, May 17, 2024 at 1:30 PM Kris Van Hees wrote: > > The CONFIG_BUILTIN_MODULE_RANGES option controls whether offset range data > is generated for kernel modules that are built into the kernel image. > > Signed-off-by: Kris Van Hees > Reviewed-by: Nick Alcock > Reviewed-by: Alan Maguire > --- > Changes since v2: > - Add explicit dependency on FTRACE for CONFIG_BUILTIN_MODULE_RANGES > --- > kernel/trace/Kconfig | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig > index 47345bf1d4a9f..d0c82b4b3a61e 100644 > --- a/kernel/trace/Kconfig > +++ b/kernel/trace/Kconfig > @@ -188,6 +188,24 @@ menuconfig FTRACE > > if FTRACE > > +config BUILTIN_MODULE_RANGES > + bool "Generate address range information for builtin modules" > + depends on FTRACE This 'depends on' is redundant because this config is already located between 'if FTRACE' and 'endif'. I believe 2/6 thru 5/6 should be squashed into one commit. Adding only the config option does not make much sense. > + select VMLINUX_MAP > + help > + When modules are built into the kernel, there will be no module name > + associated with its symbols in /proc/kallsyms. Tracers may want to > + identify symbols by module name and symbol name regardless of > whether > + the module is configured as loadable or not. > + > + This option generates modules.builtin.ranges in the build tree with > + offset ranges (per ELF section) for the module(s) they belong to. > + It also records an anchor symbol to determine the load address of > the > + section. > + > + It is fully compatible with CONFIG_RANDOMIZE_BASE and similar late- > + address-modification options. > + > config BOOTTIME_TRACING > bool "Boot-time Tracing support" > depends on TRACING > -- > 2.43.0 > -- Best Regards Masahiro Yamada
Re: [PATCH v3 6/6] module: add install target for modules.builtin.ranges
On Fri, May 17, 2024 at 1:32 PM Kris Van Hees wrote: > > When CONFIG_BUILTIN_MODULE_RANGES is enabled, the modules.builtin.ranges > file should be installed in the module install location. > > Signed-off-by: Kris Van Hees > Reviewed-by: Nick Alcock > --- > Changes since v2: > - Include modules.builtin.ranges in modules install target > --- > scripts/Makefile.modinst | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/scripts/Makefile.modinst b/scripts/Makefile.modinst > index 0afd75472679f..f5160ddd74239 100644 > --- a/scripts/Makefile.modinst > +++ b/scripts/Makefile.modinst > @@ -30,10 +30,10 @@ $(MODLIB)/modules.order: modules.order FORCE > quiet_cmd_install_modorder = INSTALL $@ >cmd_install_modorder = sed 's:^\(.*\)\.o$$:kernel/\1.ko:' $< > $@ > > -# Install modules.builtin(.modinfo) even when CONFIG_MODULES is disabled. > -install-y += $(addprefix $(MODLIB)/, modules.builtin modules.builtin.modinfo) > +# Install modules.builtin(.modinfo,.ranges) even when CONFIG_MODULES is > disabled. > +install-y += $(addprefix $(MODLIB)/, modules.builtin modules.builtin.modinfo > modules.builtin.ranges) This will break modules_install when CONFIG_BUILTIN_MODULE_RANGES is disabled. modules.builtin.ranges should be added to install-y conditionally, like this: # Install modules.builtin(.modinfo) even when CONFIG_MODULES is disabled. install-y += $(addprefix $(MODLIB)/, modules.builtin modules.builtin.modinfo) install-$(CONFIG_BUILTIN_MODULE_RANGES) += $(MODLIB)/modules.builtin.ranges > -$(addprefix $(MODLIB)/, modules.builtin modules.builtin.modinfo): > $(MODLIB)/%: % FORCE > +$(addprefix $(MODLIB)/, modules.builtin modules.builtin.modinfo > modules.builtin.ranges): $(MODLIB)/%: % FORCE > $(call cmd,install) > > endif > -- > 2.43.0 > -- Best Regards Masahiro Yamada
Re: [PATCH] livepatch: introduce klp_func called interface
Please add a version identifier to the message subject. … > If the patched function have bug, it may cause serious result > such as kernel crash. Wording suggestion: If the patched function has a bug, it might cause serious side effects like a kernel crash. > This is a kobject attribute of klp_func. Sysfs interface named > "called" is introduced to livepatch … Under which circumstances will imperative wordings be applied for another improved change description? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.9#n94 … > --- > include/linux/livepatch.h | 2 ++ … You may present version descriptions behind the marker line. Would you like to indicate any adjustments according to your change approach (from yesterday)? https://lore.kernel.org/lkml/20240519074343.5833-1-zhangwar...@gmail.com/ Regards, Markus
Re: [PATCH] livepatch: introduce klp_func called interface
> On May 20, 2024, at 14:46, Miroslav Benes wrote: > > Hi, > > On Mon, 20 May 2024, Wardenjohn wrote: > >> Livepatch module usually used to modify kernel functions. >> If the patched function have bug, it may cause serious result >> such as kernel crash. >> >> This is a kobject attribute of klp_func. Sysfs interface named >> "called" is introduced to livepatch which will be set as true >> if the patched function is called. >> >> /sys/kernel/livepatchcalled >> >> This value "called" is quite necessary for kernel stability >> assurance for livepatching module of a running system. >> Testing process is important before a livepatch module apply to >> a production system. With this interface, testing process can >> easily find out which function is successfully called. >> Any testing process can make sure they have successfully cover >> all the patched function that changed with the help of this interface. > > Even easier is to use the existing tracing infrastructure in the kernel > (ftrace for example) to track the new function. You can obtain much more > information with that than the new attribute provides. > > Regards, > Miroslav Hi Miroslav First, in most cases, testing process is should be automated, which make using existing tracing infrastructure inconvenient. Second, livepatch is already use ftrace for functional replacement, I don’t think it is a good choice of using kernel tracing tool to trace a patched function. At last, this attribute can be thought of as a state of a livepatch function. It is a state, like the "patched" "transition" state of a klp_patch. Adding this state will not break the state consistency of livepatch. Regards, Wardenjohn
Re: [PATCH RFC 1/2] dt-bindings: soc: qcom,smsm: Allow specifying mboxes instead of qcom,ipc
On 15/05/2024 17:06, Luca Weiss wrote: > Hi Rob, > > Any feedback on the below topic? Can be explained in description, like mboxes: description: Each entry corresponds to one remote processor maxItems: 5 Best regards, Krzysztof
Re: [PATCH] livepatch: introduce klp_func called interface
Hi, On Mon, 20 May 2024, Wardenjohn wrote: > Livepatch module usually used to modify kernel functions. > If the patched function have bug, it may cause serious result > such as kernel crash. > > This is a kobject attribute of klp_func. Sysfs interface named > "called" is introduced to livepatch which will be set as true > if the patched function is called. > > /sys/kernel/livepatchcalled > > This value "called" is quite necessary for kernel stability > assurance for livepatching module of a running system. > Testing process is important before a livepatch module apply to > a production system. With this interface, testing process can > easily find out which function is successfully called. > Any testing process can make sure they have successfully cover > all the patched function that changed with the help of this interface. Even easier is to use the existing tracing infrastructure in the kernel (ftrace for example) to track the new function. You can obtain much more information with that than the new attribute provides. Regards, Miroslav
