Re: dmar compile failure in -git
On 16 October 2020 22:23:46 BST, Jens Axboe wrote:
>Hi,
>
>Ran into this one yesterday:
>
>drivers/iommu/intel/dmar.c: In function ‘free_iommu’:
>drivers/iommu/intel/dmar.c:1139:41: error: ‘struct iommu_device’ has no
>member named ‘ops’
> 1139 | if (intel_iommu_enabled && iommu->iommu.ops) {
> | ^
>make[3]: *** [scripts/Makefile.build:283: drivers/iommu/intel/dmar.o]
>Error 1
>make[3]: *** Waiting for unfinished jobs
>make[2]: *** [scripts/Makefile.build:500: drivers/iommu/intel] Error 2
>make[1]: *** [scripts/Makefile.build:500: drivers/iommu] Error 2
>make: *** [Makefile:1777: drivers] Error 2
>
>which is due to the config I use:
Thanks. Should be fixed by
https://www.mail-archive.com/iommu@lists.linux-foundation.org/msg45697.html
[PATCH v4 1/9] RISC-V: Implement ptrace regs and stack API
From: Patrick Stählin
Needed for kprobes support. Copied and adapted from arm64 code.
Guo Ren fixup pt_regs type for linux-5.8-rc1.
Signed-off-by: Patrick Stählin
Signed-off-by: Guo Ren
Reviewed-by: Pekka Enberg
Reviewed-by: Zong Li
Reviewed-by: Masami Hiramatsu
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/ptrace.h | 29
arch/riscv/kernel/ptrace.c | 99 +
3 files changed, 129 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index b7821ac..e6424d8b 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -87,6 +87,7 @@ config RISCV
select SPARSE_IRQ
select SYSCTL_EXCEPTION_TRACE
select THREAD_INFO_IN_TASK
+ select HAVE_REGS_AND_STACK_ACCESS_API
config ARCH_MMAP_RND_BITS_MIN
default 18 if 64BIT
diff --git a/arch/riscv/include/asm/ptrace.h b/arch/riscv/include/asm/ptrace.h
index ee49f80..23372bb 100644
--- a/arch/riscv/include/asm/ptrace.h
+++ b/arch/riscv/include/asm/ptrace.h
@@ -8,6 +8,7 @@
#include
#include
+#include
#ifndef __ASSEMBLY__
@@ -60,6 +61,7 @@ struct pt_regs {
#define user_mode(regs) (((regs)->status & SR_PP) == 0)
+#define MAX_REG_OFFSET offsetof(struct pt_regs, orig_a0)
/* Helpers for working with the instruction pointer */
static inline unsigned long instruction_pointer(struct pt_regs *regs)
@@ -85,6 +87,12 @@ static inline void user_stack_pointer_set(struct pt_regs
*regs,
regs->sp = val;
}
+/* Valid only for Kernel mode traps. */
+static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
+{
+ return regs->sp;
+}
+
/* Helpers for working with the frame pointer */
static inline unsigned long frame_pointer(struct pt_regs *regs)
{
@@ -101,6 +109,27 @@ static inline unsigned long regs_return_value(struct
pt_regs *regs)
return regs->a0;
}
+extern int regs_query_register_offset(const char *name);
+extern unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
+ unsigned int n);
+
+/**
+ * regs_get_register() - get register value from its offset
+ * @regs: pt_regs from which register value is gotten
+ * @offset:offset of the register.
+ *
+ * regs_get_register returns the value of a register whose offset from @regs.
+ * The @offset is the offset of the register in struct pt_regs.
+ * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
+ */
+static inline unsigned long regs_get_register(struct pt_regs *regs,
+ unsigned int offset)
+{
+ if (unlikely(offset > MAX_REG_OFFSET))
+ return 0;
+
+ return *(unsigned long *)((unsigned long)regs + offset);
+}
#endif /* __ASSEMBLY__ */
#endif /* _ASM_RISCV_PTRACE_H */
diff --git a/arch/riscv/kernel/ptrace.c b/arch/riscv/kernel/ptrace.c
index 2d6395f..1a85305 100644
--- a/arch/riscv/kernel/ptrace.c
+++ b/arch/riscv/kernel/ptrace.c
@@ -114,6 +114,105 @@ const struct user_regset_view
*task_user_regset_view(struct task_struct *task)
return &riscv_user_native_view;
}
+struct pt_regs_offset {
+ const char *name;
+ int offset;
+};
+
+#define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
+#define REG_OFFSET_END {.name = NULL, .offset = 0}
+
+static const struct pt_regs_offset regoffset_table[] = {
+ REG_OFFSET_NAME(epc),
+ REG_OFFSET_NAME(ra),
+ REG_OFFSET_NAME(sp),
+ REG_OFFSET_NAME(gp),
+ REG_OFFSET_NAME(tp),
+ REG_OFFSET_NAME(t0),
+ REG_OFFSET_NAME(t1),
+ REG_OFFSET_NAME(t2),
+ REG_OFFSET_NAME(s0),
+ REG_OFFSET_NAME(s1),
+ REG_OFFSET_NAME(a0),
+ REG_OFFSET_NAME(a1),
+ REG_OFFSET_NAME(a2),
+ REG_OFFSET_NAME(a3),
+ REG_OFFSET_NAME(a4),
+ REG_OFFSET_NAME(a5),
+ REG_OFFSET_NAME(a6),
+ REG_OFFSET_NAME(a7),
+ REG_OFFSET_NAME(s2),
+ REG_OFFSET_NAME(s3),
+ REG_OFFSET_NAME(s4),
+ REG_OFFSET_NAME(s5),
+ REG_OFFSET_NAME(s6),
+ REG_OFFSET_NAME(s7),
+ REG_OFFSET_NAME(s8),
+ REG_OFFSET_NAME(s9),
+ REG_OFFSET_NAME(s10),
+ REG_OFFSET_NAME(s11),
+ REG_OFFSET_NAME(t3),
+ REG_OFFSET_NAME(t4),
+ REG_OFFSET_NAME(t5),
+ REG_OFFSET_NAME(t6),
+ REG_OFFSET_NAME(status),
+ REG_OFFSET_NAME(badaddr),
+ REG_OFFSET_NAME(cause),
+ REG_OFFSET_NAME(orig_a0),
+ REG_OFFSET_END,
+};
+
+/**
+ * regs_query_register_offset() - query register offset from its name
+ * @name: the name of a register
+ *
+ * regs_query_register_offset() returns the offset of a register in struct
+ * pt_regs from its name. If the name is invalid, this returns -EINVAL;
+ */
+int regs_query_register_offset(const char *name)
+{
+ const struct pt_regs_offset *roff;
+
+ for (roff = regoffset_table; roff->name != NULL; roff++)
+ if (!strcmp(roff->name, name))
+
[PATCH v4 0/9] Add k/uprobe & fentry & error_injection supported
From: Guo Ren The patchset includes kprobe/uprobe support and some related fixups. Patrick provides HAVE_REGS_AND_STACK_ACCESS_API support and some kprobe's code. The framework of k/uprobe is from csky but also refers to other arches'. kprobes on ftrace is also supported in the patchset. Modify dynamic ftrace mechanism from mcount to fentry. There is no single step exception in riscv ISA, only single-step facility for jtag. See riscv-Privileged spec: Interrupt Exception Code-Description 1 0 Reserved 1 1 Supervisor software interrupt 1 2–4 Reserved 1 5 Supervisor timer interrupt 1 6–8 Reserved 1 9 Supervisor external interrupt 1 10–15 Reserved 1 ≥16 Available for platform use 0 0 Instruction address misaligned 0 1 Instruction access fault 0 2 Illegal instruction 0 3 Breakpoint 0 4 Load address misaligned 0 5 Load access fault 0 6 Store/AMO address misaligned 0 7 Store/AMO access fault 0 8 Environment call from U-mode 0 9 Environment call from S-mode 0 10–11 Reserved 0 12 Instruction page fault 0 13 Load page fault 0 14 Reserved 0 15 Store/AMO page fault 0 16–23 Reserved 0 24–31 Available for custom use 0 32–47 Reserved 0 48–63 Available for custom use 0 ≥64 Reserved No single step! Other arches use hardware single-step exception for k/uprobe, eg: - powerpc: regs->msr |= MSR_SINGLESTEP - arm/arm64: PSTATE.D for enabling software step exceptions - s390: Set PER control regs, turns on single step for the given address - x86: regs->flags |= X86_EFLAGS_TF - csky: of course use hw single step :) All the above arches use a hardware single-step exception mechanism to execute the instruction that was replaced with a probe breakpoint. So utilize ebreak to simulate. Some pc related instructions couldn't be executed out of line and some system/fence instructions couldn't be a trace site at all. So we give out a reject list and simulate list in decode-insn.c. You could use uprobe to test simulate code like this: echo 'p:enter_current_state_one /hello:0x6e4 a0=%a0 a1=%a1' >> /sys/kernel/debug/tracing/uprobe_events echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable /hello ^C cat /sys/kernel/debug/tracing/trace tracer: nop entries-in-buffer/entries-written: 1/1 #P:1 _-=> irqs-off / _=> need-resched | / _---=> hardirq/softirq || / _--=> preempt-depth ||| / delay TASK-PID CPU# TIMESTAMP FUNCTION | | | | | hello-94[000] d...55.404242: enter_current_state_one: (0x106e4) a0=0x1 a1=0x3fffa8ada8 Be care /hello:0x6e4 is the file offset in elf and it relate to 0x106e4 in memory and hello is your target elf program. Try kprobe like this: echo 'p:myprobe _do_fork dfd=%a0 filename=%a1 flags=%a2 mode=+4($stack)' > /sys/kernel/debug/tracing/kprobe_events echo 'r:myretprobe _do_fork $retval' >> /sys/kernel/debug/tracing/kprobe_event echo 1 >/sys/kernel/debug/tracing/events/kprobes/enable cat /sys/kernel/debug/tracing/trace tracer: nop entries-in-buffer/entries-written: 2/2 #P:1 _-=> irqs-off / _=> need-resched | / _---=> hardirq/softirq || / _--=> preempt-depth ||| / delay TASK-PID CPU# TIMESTAMP FUNCTION | | | | | sh-92[000] .n.. 131.804230: myprobe: (_do_fork+0x0/0x2e6) dfd=0xffe03929fdf8 filename=0x0 flags=0x101000 mode=0x120ffe0 sh-92[000] d... 131.806607: myretprobe: (__do_sys_clone+0x70/0x82 <- _do_fork) arg1=0x5f cat /sys/kernel/debug/tracing/trace Changlog v4: - Revert fixup kprobes handler couldn't change pc - Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNT - rebase on linux-tree: commit 071a0578b0ce0b0e543d1e38ee6926b9cc21c198 Merge: fad7011 be4df0c Author: Linus Torvalds Date: Fri Oct 16 15:29:46 2020 -0700 Merge tag 'ovl-update-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs Changlog v3: - Add upport for function error injection - Fixup kprobes handler couldn't change pc Changlog v2: - Add Reviewed-by, Tested-by, Acked-by, thx for all of you - Add kprobes on ftrace feature - Use __always_inline as same as fix_to_virt for fixup BUILD_BUG_ON - Use const "const unsigned int" for 2th param for fixup BUILD_BUG_ON Guo Ren (8): riscv: Fixup compile error BUILD_BUG_ON failed riscv: Fixup wrong ftrace remove cflag riscv: Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNT riscv: Add kprobes supported riscv: Add KPROBES_ON_FTRACE supported riscv: Add uprobes supported riscv: Add support for function error injection riscv: Fixup lockdep_assert_held(&text_mutex) in patch_insn_write Patrick Stählin (1): RISC-V: Implement ptrac
[PATCH v4 7/9] riscv: Add uprobes supported
From: Guo Ren
This patch adds support for uprobes on riscv architecture.
Just like kprobe, it support single-step and simulate instructions.
Signed-off-by: Guo Ren
Reviewed-by: Pekka Enberg
Cc: Oleg Nesterov
Cc: Masami Hiramatsu
Cc: Palmer Dabbelt
---
arch/riscv/Kconfig | 3 +
arch/riscv/include/asm/processor.h | 1 +
arch/riscv/include/asm/thread_info.h | 4 +-
arch/riscv/include/asm/uprobes.h | 40
arch/riscv/kernel/probes/Makefile| 1 +
arch/riscv/kernel/probes/uprobes.c | 186 +++
arch/riscv/kernel/signal.c | 3 +
arch/riscv/kernel/traps.c| 10 ++
arch/riscv/mm/fault.c| 7 ++
9 files changed, 254 insertions(+), 1 deletion(-)
create mode 100644 arch/riscv/include/asm/uprobes.h
create mode 100644 arch/riscv/kernel/probes/uprobes.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index feafc9d..4081ecf 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -158,6 +158,9 @@ config ARCH_WANT_GENERAL_HUGETLB
config ARCH_SUPPORTS_DEBUG_PAGEALLOC
def_bool y
+config ARCH_SUPPORTS_UPROBES
+ def_bool y
+
config SYS_SUPPORTS_HUGETLBFS
depends on MMU
def_bool y
diff --git a/arch/riscv/include/asm/processor.h
b/arch/riscv/include/asm/processor.h
index bdddcd5..3a24003 100644
--- a/arch/riscv/include/asm/processor.h
+++ b/arch/riscv/include/asm/processor.h
@@ -34,6 +34,7 @@ struct thread_struct {
unsigned long sp; /* Kernel mode stack */
unsigned long s[12];/* s[0]: frame pointer */
struct __riscv_d_ext_state fstate;
+ unsigned long bad_cause;
};
#define INIT_THREAD { \
diff --git a/arch/riscv/include/asm/thread_info.h
b/arch/riscv/include/asm/thread_info.h
index 464a2bb..27240ea 100644
--- a/arch/riscv/include/asm/thread_info.h
+++ b/arch/riscv/include/asm/thread_info.h
@@ -80,6 +80,7 @@ struct thread_info {
#define TIF_SYSCALL_TRACEPOINT 6 /* syscall tracepoint instrumentation
*/
#define TIF_SYSCALL_AUDIT 7 /* syscall auditing */
#define TIF_SECCOMP8 /* syscall secure computing */
+#define TIF_UPROBE 9 /* uprobe breakpoint or singlestep */
#define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
#define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
@@ -88,9 +89,10 @@ struct thread_info {
#define _TIF_SYSCALL_TRACEPOINT(1 << TIF_SYSCALL_TRACEPOINT)
#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
#define _TIF_SECCOMP (1 << TIF_SECCOMP)
+#define _TIF_UPROBE(1 << TIF_UPROBE)
#define _TIF_WORK_MASK \
- (_TIF_NOTIFY_RESUME | _TIF_SIGPENDING | _TIF_NEED_RESCHED)
+ (_TIF_NOTIFY_RESUME | _TIF_SIGPENDING | _TIF_NEED_RESCHED | _TIF_UPROBE)
#define _TIF_SYSCALL_WORK \
(_TIF_SYSCALL_TRACE | _TIF_SYSCALL_TRACEPOINT | _TIF_SYSCALL_AUDIT | \
diff --git a/arch/riscv/include/asm/uprobes.h b/arch/riscv/include/asm/uprobes.h
new file mode 100644
index ..f2183e0
--- /dev/null
+++ b/arch/riscv/include/asm/uprobes.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_RISCV_UPROBES_H
+#define _ASM_RISCV_UPROBES_H
+
+#include
+#include
+#include
+
+#define MAX_UINSN_BYTES8
+
+#ifdef CONFIG_RISCV_ISA_C
+#define UPROBE_SWBP_INSN __BUG_INSN_16
+#define UPROBE_SWBP_INSN_SIZE 2
+#else
+#define UPROBE_SWBP_INSN __BUG_INSN_32
+#define UPROBE_SWBP_INSN_SIZE 4
+#endif
+#define UPROBE_XOL_SLOT_BYTES MAX_UINSN_BYTES
+
+typedef u32 uprobe_opcode_t;
+
+struct arch_uprobe_task {
+ unsigned long saved_cause;
+};
+
+struct arch_uprobe {
+ union {
+ u8 insn[MAX_UINSN_BYTES];
+ u8 ixol[MAX_UINSN_BYTES];
+ };
+ struct arch_probe_insn api;
+ unsigned long insn_size;
+ bool simulate;
+};
+
+bool uprobe_breakpoint_handler(struct pt_regs *regs);
+bool uprobe_single_step_handler(struct pt_regs *regs);
+
+#endif /* _ASM_RISCV_UPROBES_H */
diff --git a/arch/riscv/kernel/probes/Makefile
b/arch/riscv/kernel/probes/Makefile
index abbd131..7f0840d 100644
--- a/arch/riscv/kernel/probes/Makefile
+++ b/arch/riscv/kernel/probes/Makefile
@@ -2,4 +2,5 @@
obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o simulate-insn.o
obj-$(CONFIG_KPROBES) += kprobes_trampoline.o
obj-$(CONFIG_KPROBES_ON_FTRACE)+= ftrace.o
+obj-$(CONFIG_UPROBES) += uprobes.o decode-insn.o simulate-insn.o
CFLAGS_REMOVE_simulate-insn.o = $(CC_FLAGS_FTRACE)
diff --git a/arch/riscv/kernel/probes/uprobes.c
b/arch/riscv/kernel/probes/uprobes.c
new file mode 100644
index ..7a057b5
--- /dev/null
+++ b/arch/riscv/kernel/probes/uprobes.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include
+#include
+#include
+
+#include "decode-insn.h"
+
+#define UPROBE_TRAP_NR UINT_MAX
+
+bool is_swbp_insn(uprobe_opcode_t *insn)
+{
+#ifdef CONFIG_RISCV
[PATCH v4 2/9] riscv: Fixup compile error BUILD_BUG_ON failed
From: Guo Ren
Unfortunately, the current code couldn't be compiled:
CC arch/riscv/kernel/patch.o
In file included from ./include/linux/kernel.h:11,
from ./include/linux/list.h:9,
from ./include/linux/preempt.h:11,
from ./include/linux/spinlock.h:51,
from arch/riscv/kernel/patch.c:6:
In function ‘fix_to_virt’,
inlined from ‘patch_map’ at arch/riscv/kernel/patch.c:37:17:
./include/linux/compiler.h:392:38: error: call to ‘__compiletime_assert_205’
declared with attribute error: BUILD_BUG_ON failed: idx >=
__end_of_fixed_addresses
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^
./include/linux/compiler.h:373:4: note: in definition of macro
‘__compiletime_assert’
prefix ## suffix();\
^~
./include/linux/compiler.h:392:2: note: in expansion of macro
‘_compiletime_assert’
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^~~
./include/linux/build_bug.h:39:37: note: in expansion of macro
‘compiletime_assert’
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
./include/linux/build_bug.h:50:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~
./include/asm-generic/fixmap.h:32:2: note: in expansion of macro ‘BUILD_BUG_ON’
BUILD_BUG_ON(idx >= __end_of_fixed_addresses);
^~~~
Because fix_to_virt(, idx) needs a const value, not a dynamic variable of
reg-a0 or BUILD_BUG_ON failed with "idx >= __end_of_fixed_addresses".
Signed-off-by: Guo Ren
Reviewed-by: Masami Hiramatsu
Reviewed-by: Pekka Enberg
Cc: Paul Walmsley
Cc: Palmer Dabbelt
---
arch/riscv/kernel/patch.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/kernel/patch.c b/arch/riscv/kernel/patch.c
index 3fe7a52..0b55287 100644
--- a/arch/riscv/kernel/patch.c
+++ b/arch/riscv/kernel/patch.c
@@ -20,7 +20,12 @@ struct patch_insn {
};
#ifdef CONFIG_MMU
-static void *patch_map(void *addr, int fixmap)
+/*
+ * The fix_to_virt(, idx) needs a const value (not a dynamic variable of
+ * reg-a0) or BUILD_BUG_ON failed with "idx >= __end_of_fixed_addresses".
+ * So use '__always_inline' and 'const unsigned int fixmap' here.
+ */
+static __always_inline void *patch_map(void *addr, const unsigned int fixmap)
{
uintptr_t uintaddr = (uintptr_t) addr;
struct page *page;
@@ -37,7 +42,6 @@ static void *patch_map(void *addr, int fixmap)
return (void *)set_fixmap_offset(fixmap, page_to_phys(page) +
(uintaddr & ~PAGE_MASK));
}
-NOKPROBE_SYMBOL(patch_map);
static void patch_unmap(int fixmap)
{
--
2.7.4
[PATCH v4 8/9] riscv: Add support for function error injection
From: Guo Ren
Inspired by the commit 42d038c4fb00 ("arm64: Add support for function
error injection"), this patch supports function error injection for
riscv.
This patch mainly support two functions: one is regs_set_return_value()
which is used to overwrite the return value; the another function is
override_function_with_return() which is to override the probed
function returning and jump to its caller.
Test log:
cd /sys/kernel/debug/fail_function
echo sys_clone > inject
echo 100 > probability
echo 1 > interval
ls /
[ 313.176875] FAULT_INJECTION: forcing a failure.
[ 313.176875] name fail_function, interval 1, probability 100, space 0, times 1
[ 313.184357] CPU: 0 PID: 87 Comm: sh Not tainted 5.8.0-rc5-7-g6a758cc #117
[ 313.187616] Call Trace:
[ 313.189100] [] walk_stackframe+0x0/0xc2
[ 313.191626] [] show_stack+0x40/0x4c
[ 313.193927] [] dump_stack+0x7c/0x96
[ 313.194795] [] should_fail+0x140/0x142
[ 313.195923] [] fei_kprobe_handler+0x2c/0x5a
[ 313.197687] [] kprobe_breakpoint_handler+0xb4/0x18a
[ 313.200054] [] do_trap_break+0x36/0xca
[ 313.202147] [] ret_from_exception+0x0/0xc
[ 313.204556] [] ret_from_syscall+0x0/0x2
-sh: can't fork: Invalid argument
Signed-off-by: Guo Ren
Reviewed-by: Masami Hiramatsu
Cc: Palmer Dabbelt
Cc: Paul Walmsley
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/ptrace.h | 6 ++
arch/riscv/lib/Makefile | 2 ++
arch/riscv/lib/error-inject.c | 10 ++
4 files changed, 19 insertions(+)
create mode 100644 arch/riscv/lib/error-inject.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 4081ecf..3d094fd 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -66,6 +66,7 @@ config RISCV
select HAVE_EBPF_JIT if MMU
select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_GCC_PLUGINS
+ select HAVE_FUNCTION_ERROR_INJECTION
select HAVE_GENERIC_VDSO if MMU && 64BIT
select HAVE_KPROBES
select HAVE_KPROBES_ON_FTRACE
diff --git a/arch/riscv/include/asm/ptrace.h b/arch/riscv/include/asm/ptrace.h
index 23372bb..cb4abb6 100644
--- a/arch/riscv/include/asm/ptrace.h
+++ b/arch/riscv/include/asm/ptrace.h
@@ -109,6 +109,12 @@ static inline unsigned long regs_return_value(struct
pt_regs *regs)
return regs->a0;
}
+static inline void regs_set_return_value(struct pt_regs *regs,
+unsigned long val)
+{
+ regs->a0 = val;
+}
+
extern int regs_query_register_offset(const char *name);
extern unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
unsigned int n);
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 0d0db80..04baa93 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -4,3 +4,5 @@ lib-y += memcpy.o
lib-y += memset.o
lib-y += uaccess.o
lib-$(CONFIG_64BIT)+= tishift.o
+
+obj-$(CONFIG_FUNCTION_ERROR_INJECTION) += error-inject.o
diff --git a/arch/riscv/lib/error-inject.c b/arch/riscv/lib/error-inject.c
new file mode 100644
index ..d667ade
--- /dev/null
+++ b/arch/riscv/lib/error-inject.c
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+
+void override_function_with_return(struct pt_regs *regs)
+{
+ instruction_pointer_set(regs, regs->ra);
+}
+NOKPROBE_SYMBOL(override_function_with_return);
--
2.7.4
[PATCH v4 6/9] riscv: Add KPROBES_ON_FTRACE supported
From: Guo Ren
This patch adds support for kprobes on ftrace call sites to avoids
much of the overhead with regular kprobes. Try it with simple
steps:
1. Get _do_fork ftrace call site.
Dump of assembler code for function _do_fork:
0xffe00020af64 <+0>: addisp,sp,-128
0xffe00020af66 <+2>: sd s0,112(sp)
0xffe00020af68 <+4>: sd ra,120(sp)
0xffe00020af6a <+6>: addis0,sp,128
0xffe00020af6c <+8>: sd s1,104(sp)
0xffe00020af6e <+10>:sd s2,96(sp)
0xffe00020af70 <+12>:sd s3,88(sp)
0xffe00020af72 <+14>:sd s4,80(sp)
0xffe00020af74 <+16>:sd s5,72(sp)
0xffe00020af76 <+18>:sd s6,64(sp)
0xffe00020af78 <+20>:sd s7,56(sp)
0xffe00020af7a <+22>:mv s4,a0
0xffe00020af7c <+24>:mv a0,ra
0xffe00020af7e <+26>:nop here!
0xffe00020af82 <+30>:nop
0xffe00020af86 <+34>:ld s3,0(s4)
2. Set _do_fork+26 as the kprobe.
echo 'p:myprobe _do_fork+26 dfd=%a0 filename=%a1 flags=%a2 mode=+4($stack)' >
/sys/kernel/debug/tracing/kprobe_events
echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
cat /sys/kernel/debug/tracing/trace
tracer: nop
entries-in-buffer/entries-written: 3/3 #P:1
_-=> irqs-off
/ _=> need-resched
| / _---=> hardirq/softirq
|| / _--=> preempt-depth
||| / delay
TASK-PID CPU# TIMESTAMP FUNCTION
| | | | |
sh-87[000] 551.557031: myprobe: (_do_fork+0x1a/0x2e6)
dfd=0xffe00020af7e filename=0xffe00020b34e flags=0xffe00101e7c0
mode=0x20af86ffe0
cat /sys/kernel/debug/kprobes/list
ffe00020af7e k _do_fork+0x1a[FTRACE]
^^
Signed-off-by: Guo Ren
Reviewed-by: Masami Hiramatsu
Cc: Palmer Dabbelt
Cc: Paul Walmsley
Cc: Björn Töpel
Cc: Zong Li
Cc: Pekka Enberg
---
arch/riscv/Kconfig| 1 +
arch/riscv/kernel/probes/Makefile | 1 +
arch/riscv/kernel/probes/ftrace.c | 52 +++
3 files changed, 54 insertions(+)
create mode 100644 arch/riscv/kernel/probes/ftrace.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index c07214a..feafc9d 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -68,6 +68,7 @@ config RISCV
select HAVE_GCC_PLUGINS
select HAVE_GENERIC_VDSO if MMU && 64BIT
select HAVE_KPROBES
+ select HAVE_KPROBES_ON_FTRACE
select HAVE_KRETPROBES
select HAVE_PCI
select HAVE_PERF_EVENTS
diff --git a/arch/riscv/kernel/probes/Makefile
b/arch/riscv/kernel/probes/Makefile
index 8a39507..abbd131 100644
--- a/arch/riscv/kernel/probes/Makefile
+++ b/arch/riscv/kernel/probes/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o simulate-insn.o
obj-$(CONFIG_KPROBES) += kprobes_trampoline.o
+obj-$(CONFIG_KPROBES_ON_FTRACE)+= ftrace.o
CFLAGS_REMOVE_simulate-insn.o = $(CC_FLAGS_FTRACE)
diff --git a/arch/riscv/kernel/probes/ftrace.c
b/arch/riscv/kernel/probes/ftrace.c
new file mode 100644
index ..e0fe58a
--- /dev/null
+++ b/arch/riscv/kernel/probes/ftrace.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+
+/* Ftrace callback handler for kprobes -- called under preepmt disabed */
+void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
+ struct ftrace_ops *ops, struct pt_regs *regs)
+{
+ struct kprobe *p;
+ struct kprobe_ctlblk *kcb;
+
+ p = get_kprobe((kprobe_opcode_t *)ip);
+ if (unlikely(!p) || kprobe_disabled(p))
+ return;
+
+ kcb = get_kprobe_ctlblk();
+ if (kprobe_running()) {
+ kprobes_inc_nmissed_count(p);
+ } else {
+ unsigned long orig_ip = instruction_pointer(regs);
+ instruction_pointer_set(regs, ip);
+
+ __this_cpu_write(current_kprobe, p);
+ kcb->kprobe_status = KPROBE_HIT_ACTIVE;
+ if (!p->pre_handler || !p->pre_handler(p, regs)) {
+ /*
+* Emulate singlestep (and also recover regs->pc)
+* as if there is a nop
+*/
+ instruction_pointer_set(regs,
+ (unsigned long)p->addr + MCOUNT_INSN_SIZE);
+ if (unlikely(p->post_handler)) {
+ kcb->kprobe_status = KPROBE_HIT_SSDONE;
+ p->post_handler(p, regs, 0);
+ }
+ instruction_pointer_set(regs, orig_ip);
+ }
+
+
[PATCH v4 5/9] riscv: Add kprobes supported
From: Guo Ren
This patch enables "kprobe & kretprobe" to work with ftrace
interface. It utilized software breakpoint as single-step
mechanism.
Some instructions which can't be single-step executed must be
simulated in kernel execution slot, such as: branch, jal, auipc,
la ...
Some instructions should be rejected for probing and we use a
blacklist to filter, such as: ecall, ebreak, ...
We use ebreak & c.ebreak to replace origin instruction and the
kprobe handler prepares an executable memory slot for out-of-line
execution with a copy of the original instruction being probed.
In execution slot we add ebreak behind original instruction to
simulate a single-setp mechanism.
The patch is based on packi's work [1] and csky's work [2].
- The kprobes_trampoline.S is all from packi's patch
- The single-step mechanism is new designed for riscv without hw
single-step trap
- The simulation codes are from csky
- Frankly, all codes refer to other archs' implementation
[1] https://lore.kernel.org/linux-riscv/20181113195804.22825-1...@packi.ch/
[2]
https://lore.kernel.org/linux-csky/20200403044150.20562-9-guo...@kernel.org/
Signed-off-by: Guo Ren
Co-Developed-by: Patrick Stählin
Acked-by: Masami Hiramatsu
Tested-by: Zong Li
Reviewed-by: Pekka Enberg
Cc: Patrick Stählin
Cc: Palmer Dabbelt
Cc: Björn Töpel
---
arch/riscv/Kconfig| 2 +
arch/riscv/include/asm/kprobes.h | 40 +++
arch/riscv/include/asm/probes.h | 24 ++
arch/riscv/kernel/Makefile| 1 +
arch/riscv/kernel/probes/Makefile | 4 +
arch/riscv/kernel/probes/decode-insn.c| 48
arch/riscv/kernel/probes/decode-insn.h| 18 ++
arch/riscv/kernel/probes/kprobes.c| 398 ++
arch/riscv/kernel/probes/kprobes_trampoline.S | 93 ++
arch/riscv/kernel/probes/simulate-insn.c | 85 ++
arch/riscv/kernel/probes/simulate-insn.h | 47 +++
arch/riscv/kernel/traps.c | 9 +
arch/riscv/mm/fault.c | 4 +
13 files changed, 773 insertions(+)
create mode 100644 arch/riscv/include/asm/probes.h
create mode 100644 arch/riscv/kernel/probes/Makefile
create mode 100644 arch/riscv/kernel/probes/decode-insn.c
create mode 100644 arch/riscv/kernel/probes/decode-insn.h
create mode 100644 arch/riscv/kernel/probes/kprobes.c
create mode 100644 arch/riscv/kernel/probes/kprobes_trampoline.S
create mode 100644 arch/riscv/kernel/probes/simulate-insn.c
create mode 100644 arch/riscv/kernel/probes/simulate-insn.h
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index e6424d8b..c07214a 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -67,6 +67,8 @@ config RISCV
select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_GCC_PLUGINS
select HAVE_GENERIC_VDSO if MMU && 64BIT
+ select HAVE_KPROBES
+ select HAVE_KRETPROBES
select HAVE_PCI
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
diff --git a/arch/riscv/include/asm/kprobes.h b/arch/riscv/include/asm/kprobes.h
index 56a98ea3..4647d38 100644
--- a/arch/riscv/include/asm/kprobes.h
+++ b/arch/riscv/include/asm/kprobes.h
@@ -11,4 +11,44 @@
#include
+#ifdef CONFIG_KPROBES
+#include
+#include
+#include
+
+#define __ARCH_WANT_KPROBES_INSN_SLOT
+#define MAX_INSN_SIZE 2
+
+#define flush_insn_slot(p) do { } while (0)
+#define kretprobe_blacklist_size 0
+
+#include
+
+struct prev_kprobe {
+ struct kprobe *kp;
+ unsigned int status;
+};
+
+/* Single step context for kprobe */
+struct kprobe_step_ctx {
+ unsigned long ss_pending;
+ unsigned long match_addr;
+};
+
+/* per-cpu kprobe control block */
+struct kprobe_ctlblk {
+ unsigned int kprobe_status;
+ unsigned long saved_status;
+ struct prev_kprobe prev_kprobe;
+ struct kprobe_step_ctx ss_ctx;
+};
+
+void arch_remove_kprobe(struct kprobe *p);
+int kprobe_fault_handler(struct pt_regs *regs, unsigned int trapnr);
+bool kprobe_breakpoint_handler(struct pt_regs *regs);
+bool kprobe_single_step_handler(struct pt_regs *regs);
+void kretprobe_trampoline(void);
+void __kprobes *trampoline_probe_handler(struct pt_regs *regs);
+
+#endif /* CONFIG_KPROBES */
#endif /* _ASM_RISCV_KPROBES_H */
diff --git a/arch/riscv/include/asm/probes.h b/arch/riscv/include/asm/probes.h
new file mode 100644
index ..a787e6d
--- /dev/null
+++ b/arch/riscv/include/asm/probes.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _ASM_RISCV_PROBES_H
+#define _ASM_RISCV_PROBES_H
+
+typedef u32 probe_opcode_t;
+typedef bool (probes_handler_t) (u32 opcode, unsigned long addr, struct
pt_regs *);
+
+/* architecture specific copy of original instruction */
+struct arch_probe_insn {
+ probe_opcode_t *insn;
+ probes_handler_t *handler;
+ /* restore address after simulation */
+ unsigned long restore;
+};
+
+#ifdef CO
[PATCH v4 3/9] riscv: Fixup wrong ftrace remove cflag
From: Guo Ren We must use $(CC_FLAGS_FTRACE) instead of directly using -pg. It will cause -fpatchable-function-entry error. Signed-off-by: Guo Ren --- arch/riscv/kernel/Makefile | 4 ++-- arch/riscv/mm/Makefile | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile index dc93710..f14aed2 100644 --- a/arch/riscv/kernel/Makefile +++ b/arch/riscv/kernel/Makefile @@ -4,8 +4,8 @@ # ifdef CONFIG_FTRACE -CFLAGS_REMOVE_ftrace.o = -pg -CFLAGS_REMOVE_patch.o = -pg +CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_patch.o = $(CC_FLAGS_FTRACE) endif extra-y += head.o diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile index c0185e5..6b4b7ec 100644 --- a/arch/riscv/mm/Makefile +++ b/arch/riscv/mm/Makefile @@ -2,7 +2,7 @@ CFLAGS_init.o := -mcmodel=medany ifdef CONFIG_FTRACE -CFLAGS_REMOVE_init.o = -pg +CFLAGS_REMOVE_init.o = $(CC_FLAGS_FTRACE) endif KCOV_INSTRUMENT_init.o := n -- 2.7.4
[PATCH v4 4/9] riscv: Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNT
From: Guo Ren
This patch changes the current detour mechanism of dynamic ftrace
which has been discussed during LPC 2020 RISCV-MC [1].
Before the patch, we used mcount for detour:
:
addi sp,sp,-16
sd ra,8(sp)
sd s0,0(sp)
addi s0,sp,16
mv a5,ra
mv a0,a5
auipc ra,0x0 -> nop
jalr -296(ra) <_mcount@plt> ->nop
...
After the patch:
:
nop
nop
nop, nop
nop, nop
nop
nop
...
The mcount mechanism is mixed with gcc function prologue which is
not very clear. The patchable function entry just put 16 bytes nop
before the front of the function prologue which could be filled
with a separated detour mechanism.
[1] https://www.linuxplumbersconf.org/event/7/contributions/807/
Signed-off-by: Guo Ren
Cc: Alan Kao
Cc: Masami Hiramatsu
Cc: Palmer Dabbelt
Cc: Paul Walmsley
---
arch/riscv/Makefile| 2 +
arch/riscv/kernel/ftrace.c | 94 +-
arch/riscv/kernel/mcount-dyn.S | 211 -
3 files changed, 131 insertions(+), 176 deletions(-)
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index fb6e37d..599aed6 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -12,6 +12,8 @@ OBJCOPYFLAGS:= -O binary
LDFLAGS_vmlinux :=
ifeq ($(CONFIG_DYNAMIC_FTRACE),y)
LDFLAGS_vmlinux := --no-relax
+ KBUILD_CPPFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY
+ CC_FLAGS_FTRACE := -fpatchable-function-entry=8
endif
ifeq ($(CONFIG_64BIT)$(CONFIG_CMODEL_MEDLOW),yy)
diff --git a/arch/riscv/kernel/ftrace.c b/arch/riscv/kernel/ftrace.c
index 99e12fa..a4e66b4 100644
--- a/arch/riscv/kernel/ftrace.c
+++ b/arch/riscv/kernel/ftrace.c
@@ -72,29 +72,55 @@ static int __ftrace_modify_call(unsigned long hook_pos,
unsigned long target,
return 0;
}
+/*
+ * Put 5 instructions with 16 bytes at the front of function within
+ * patchable function entry nops' area.
+ *
+ * 0: addi sp,sp,-8
+ * 1: sd ra, 0(sp)
+ * 2: auipc ra, 0x?
+ * 3: jalr -?(ra)
+ * 4: ld ra,0(sp)
+ * 5: addi sp,sp,8
+ *
+ * So the opcodes is:
+ * 0: 0x1161
+ * 1: 0xe006
+ * 2: 0x
+ * 3: 0x
+ * 4: 0x6082
+ * 5: 0x0121
+ */
+#define INSN0_10xe0061161
+#define INSN4_50x01216082
+
+#define FUNC_ENTRY_SIZE16
+#define FUNC_ENTRY_JMP 4
+
int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
{
- int ret = ftrace_check_current_call(rec->ip, NULL);
+ unsigned int call[4] = {INSN0_1, 0, 0, INSN4_5};
+ unsigned long target = addr;
+ unsigned long caller = rec->ip + FUNC_ENTRY_JMP;
- if (ret)
- return ret;
+ call[1] = to_auipc_insn((unsigned int)(target - caller));
+ call[2] = to_jalr_insn((unsigned int)(target - caller));
+
+ if (patch_text_nosync((void *)rec->ip, call, FUNC_ENTRY_SIZE))
+ return -EPERM;
- return __ftrace_modify_call(rec->ip, addr, true);
+ return 0;
}
int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
unsigned long addr)
{
- unsigned int call[2];
- int ret;
-
- make_call(rec->ip, addr, call);
- ret = ftrace_check_current_call(rec->ip, call);
+ unsigned int nops[4] = {NOP4, NOP4, NOP4, NOP4};
- if (ret)
- return ret;
+ if (patch_text_nosync((void *)rec->ip, nops, FUNC_ENTRY_SIZE))
+ return -EPERM;
- return __ftrace_modify_call(rec->ip, addr, false);
+ return 0;
}
@@ -139,15 +165,16 @@ int ftrace_modify_call(struct dyn_ftrace *rec, unsigned
long old_addr,
unsigned long addr)
{
unsigned int call[2];
+ unsigned long caller = rec->ip + FUNC_ENTRY_JMP;
int ret;
- make_call(rec->ip, old_addr, call);
- ret = ftrace_check_current_call(rec->ip, call);
+ make_call(caller, old_addr, call);
+ ret = ftrace_check_current_call(caller, call);
if (ret)
return ret;
- return __ftrace_modify_call(rec->ip, addr, true);
+ return __ftrace_modify_call(caller, addr, true);
}
#endif
@@ -176,53 +203,30 @@ void prepare_ftrace_return(unsigned long *parent,
unsigned long self_addr,
#ifdef CONFIG_DYNAMIC_FTRACE
extern void ftrace_graph_call(void);
+extern void ftrace_graph_regs_call(void);
int ftrace_enable_ftrace_graph_caller(void)
{
- unsigned int call[2];
- static int init_graph = 1;
int ret;
- make_call(&ftrace_graph_call, &ftrace_stub, call);
-
- /*
-* When enabling graph tracer for the first time, ftrace_graph_call
-* should contains a call to ftrace_stub. Once it has been disabled,
-* the 8-bytes at the position becomes NOPs.
-*/
- if (init_graph) {
- ret = ftrace_check_current_call((unsigned
long)&ftrace_graph_call,
-
[PATCH v4 9/9] riscv: Fixup lockdep_assert_held(&text_mutex) in patch_insn_write
From: Guo Ren It will cause warning messages: echo function_graph > /sys/kernel/debug/tracing/current_tracer [ 47.691397] [ cut here ] [ 47.692899] WARNING: CPU: 0 PID: 11 at arch/riscv/kernel/patch.c:63 patch_insn_write+0x182/0x19a [ 47.694483] Modules linked in: [ 47.695754] CPU: 0 PID: 11 Comm: migration/0 Not tainted 5.9.0-11367-g1054335 #132 [ 47.698228] epc: ffe000204530 ra : ffe00020452c sp : ffe0023ffc20 gp : ffe0013e1fe0 tp : ffe0023e4e00 t0 : [ 47.701872] t1 : 000e t2 : 001b s0 : ffe0023ffc70 s1 : ffe000206850 a0 : a1 : [ 47.705550] a2 : a3 : ffe03af7c5e8 a4 : a5 : a6 : a7 : 150b02d8 [ 47.709159] s2 : 0008 s3 : 0858 s4 : ffe0023ffc98 s5 : 0850 s6 : 0003 s7 : 0002 [ 47.714135] s8 : 0004 s9 : 0001 s10: 0001 s11: 0003 t3 : e000 t4 : 00d86254 [ 47.716574] t5 : 0005 t6 : 0004status: 0100 badaddr: cause: 0003 [ 47.720019] CPU: 0 PID: 11 Comm: migration/0 Not tainted 5.9.0-11367-g1054335 #132 [ 47.722074] Call Trace: [ 47.722561] [] walk_stackframe+0x0/0xc2 [ 47.724608] [] show_stack+0x46/0x52 [ 47.726246] [] dump_stack+0x90/0xb6 [ 47.727672] [] __warn+0x98/0xfa [ 47.729131] [] report_bug+0xaa/0x11e [ 47.730624] [] do_trap_break+0x96/0xfe [ 47.732448] [] ret_from_exception+0x0/0x14 [ 47.734341] [] patch_insn_write+0x17e/0x19a [ 47.737235] irq event stamp: 39 [ 47.738521] hardirqs last enabled at (39): [] _save_context+0xa2/0xe6 [ 47.741055] hardirqs last disabled at (38): [] multi_cpu_stop+0x130/0x166 [ 47.743551] softirqs last enabled at (0): [] copy_process+0x430/0x1316 [ 47.746031] softirqs last disabled at (0): [<>] 0x0 [ 47.748617] ---[ end trace 88a1054faa6524ef ]--- Because the path of stop_machine(__ftrace_modify_code)-> ftrace_modify_all_code->...->patch_insn_write has no pair of lock&unlock text_mutex, so we shouldn't put assert here. Signed-off-by: Guo Ren --- arch/riscv/kernel/patch.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/arch/riscv/kernel/patch.c b/arch/riscv/kernel/patch.c index 0b55287..2ee5063 100644 --- a/arch/riscv/kernel/patch.c +++ b/arch/riscv/kernel/patch.c @@ -55,13 +55,6 @@ static int patch_insn_write(void *addr, const void *insn, size_t len) bool across_pages = (((uintptr_t) addr & ~PAGE_MASK) + len) > PAGE_SIZE; int ret; - /* -* Before reaching here, it was expected to lock the text_mutex -* already, so we don't need to give another lock here and could -* ensure that it was safe between each cores. -*/ - lockdep_assert_held(&text_mutex); - if (across_pages) patch_map(addr + len, FIX_TEXT_POKE1); -- 2.7.4
Re: [PATCH 1/3] dt-bindings: vendor-prefixes: Add Yes Optoelectronics
Hi Jagan. On Fri, Sep 04, 2020 at 11:38:19PM +0530, Jagan Teki wrote: > Add vendor dt-bindings for Yes Optoelectronics Co.,Ltd. > > Signed-off-by: Jagan Teki I have applied the full series to drm-misc-next. Sorry for the delay. Sam > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml > b/Documentation/devicetree/bindings/vendor-prefixes.yaml > index 9aeab66be85f..15a6a8e7260d 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -1167,6 +1167,8 @@ patternProperties: > description: Shenzhen Xunlong Software CO.,Limited >"^xylon,.*": > description: Xylon > + "^yes-optoelectronics,.*": > +description: Yes Optoelectronics Co.,Ltd. >"^yna,.*": > description: YSH & ATIL >"^yones-toptech,.*": > -- > 2.25.1 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5.4 00/22] 5.4.72-rc1 review
On Fri, 16 Oct 2020 at 14:41, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.4.72 release. > There are 22 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 18 Oct 2020 09:04:25 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.72-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.4.72-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.4.y git commit: a3f8c7f24ee00462a09758774aee840317650b51 git describe: v5.4.71-23-ga3f8c7f24ee0 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.71-23-ga3f8c7f24ee0 No regressions (compared to build v5.4.71) No fixes (compared to build v5.4.71) Ran 24730 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-fs-tests * ltp-ipc-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * perf * v4l2-compliance * ltp-commands-tests * ltp-containers-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-math-tests * ltp-mm-tests * network-basic-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none * ssuite -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver
On Sat, Oct 17, 2020 at 08:55:34AM +0200, Jann Horn wrote: > My suggestion is to use a counter *in the UAPI*, not in the hypervisor > protocol. (And as long as that counter can only miss increments in a > cryptographically negligible fraction of cases, everything's fine.) OK I got it now and I agree. > > If what is sought is pure > > randomness (in the sense that it's unpredictable, which I don't think > > is needed here), then randoms are better. > > And this is what *the hypervisor protocol* gives us (which could be > very useful for reseeding the kernel RNG). As an external source, yes very likely, as long as it's not trivially observable by everyone under the same hypervisor :-) > > Now the initial needs in the forwarded message are not entirely clear > > to me but I wanted to rule out the apparent mismatch between the expressed > > needs for uniqueness and the proposed solutions solely based on randomness. > > Sure, from a theoretical standpoint, it would be a little bit nicer if > the hypervisor protocol included a generation number along with the > 128-bit random value. But AFAIU it doesn't, so if we want this to just > work under Microsoft's existing hypervisor, we'll have to make do with > checking whether the random value changed. :P OK got it, thanks for the explanation! Willy
Re: [PATCH v3] drm/bridge: add it6505 driver
Hi Allen On Fri, Sep 04, 2020 at 10:10:23AM +0800, allen wrote: > This adds support for the iTE IT6505. > This device can convert DPI signal to DP output. > > From: Allen Chen > Signed-off-by: Jitao Shi > Signed-off-by: Pi-Hsun Shih > Signed-off-by: Yilun Lin > Signed-off-by: Hermes Wu > Signed-off-by: Allen Chen > Reported-by: kernel test robot Sorry for being so late with the feedback - have been offline for a while. One high-level comment - the bridge does not respect the flags arguments in the it6505_bridge_attach function. And will unconditionally create the connector. The correct approach is that the display driver creates the connector, and pass a flag to the bridge driver to tell it not to create the connector. Could we please update the relevant display drivers to create the connector and then drop it from the bridge driver. So we avoid adding backward compatible code to a new bridge driver. What display driver will this bridge be used with? Sam > --- > drivers/gpu/drm/bridge/Kconfig |7 + > drivers/gpu/drm/bridge/Makefile |1 + > drivers/gpu/drm/bridge/ite-it6505.c | 3338 +++ > 3 files changed, 3346 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 3e11af4e9f63e..f21dce3fabeb9 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -61,6 +61,13 @@ config DRM_LONTIUM_LT9611 > HDMI signals > Please say Y if you have such hardware. > > +config DRM_ITE_IT6505 > + tristate "ITE IT6505 DisplayPort bridge" > + depends on OF > + select DRM_KMS_HELPER > + help > + ITE IT6505 DisplayPort bridge chip driver. > + > config DRM_LVDS_CODEC > tristate "Transparent LVDS encoders and decoders support" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index c589a6a7cbe1d..8a118fd901ad7 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o > obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o > obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o > +obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o > obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += > megachips-stdp-ge-b850v3-fw.o > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o > diff --git a/drivers/gpu/drm/bridge/ite-it6505.c > b/drivers/gpu/drm/bridge/ite-it6505.c > new file mode 100644 > index 0..0ed19673431ee > --- /dev/null > +++ b/drivers/gpu/drm/bridge/ite-it6505.c > @@ -0,0 +1,3338 @@ > +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +/* > + * Copyright (c) 2020, The Linux Foundation. All rights reserved. > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#define REG_IC_VER 0x04 > + > +#define REG_RESET_CTRL 0x05 > +#define VIDEO_RESET BIT(0) > +#define AUDIO_RESET BIT(1) > +#define ALL_LOGIC_RESET BIT(2) > +#define AUX_RESET BIT(3) > +#define HDCP_RESET BIT(4) > + > +#define INT_STATUS_01 0x06 > +#define INT_MASK_01 0x09 > +#define INT_HPD_CHANGE BIT(0) > +#define INT_RECEIVE_HPD_IRQ BIT(1) > +#define INT_SCDT_CHANGE BIT(2) > +#define INT_HDCP_FAIL BIT(3) > +#define INT_HDCP_DONE BIT(4) > + > +#define INT_STATUS_02 0x07 > +#define INT_MASK_02 0x0A > +#define INT_AUX_CMD_FAIL BIT(0) > +#define INT_HDCP_KSV_CHECK BIT(1) > +#define INT_AUDIO_FIFO_ERROR BIT(2) > + > +#define INT_STATUS_03 0x08 > +#define INT_MASK_03 0x0B > +#define INT_LINK_TRAIN_FAIL BIT(4) > +#define INT_VID_FIFO_ERROR BIT(5) > +#define INT_IO_LATCH_FIFO_OVERFLOW BIT(7) > + > +#define REG_SYSTEM_STS 0x0D > +#define INT_STS BIT(0) > +#define HPD_STS BIT(1) > +#define VIDEO_STB BIT(2) > + > +#define REG_LINK_TRAIN_STS 0x0E > +#define LINK_STATE_CR BIT(2) > +#define LINK_STATE_EQ BIT(3) > +#define LINK_STATE_NORP BIT(4) > + > +#define REG_BANK_SEL 0x0F > +#define REG_CLK_CTRL0 0x10 > +#define M_PCLK_DELAY 0x03 > + > +#define REG_AUX_OPT 0x11 > +#define AUX_AUTO_RST BIT(0) > +#define AUX_FIX_FREQ BIT(3) > + > +#define REG_DATA_CTRL0 0x12 > +#define VIDEO_LATCH_EDGE BIT(4) > +#define ENABLE_PCLK_COUNTER BIT(7) > + > +#define REG_PCLK_COUNTER_VALUE 0x13 > + > +#define REG_501_FIFO_CTRL 0x15 > +#define RST_501_FIFO BIT(1) > + > +#define REG_TRAIN_CTRL0 0x16 > +#define FORCE_LBR BIT(0) > +#define LANE_COUNT_MASK 0x06 > +#define LANE_SWAP BIT(3) > +#define SPREAD_AMP_5 BIT(4) > +#define FORCE_CR_DONE BIT(5) > +#define FORC
Re: [PATCH v3] checkpatch: add new exception to repeated word check
On Sat, 2020-10-17 at 11:32 +0530, Dwaipayan Ray wrote:
> > Why include a + character here?
> >
> Hi,
> I tried it without + first, but then lines like
> "The the repeated word."
> didn't register a warning.
>
> I think checkpatch adds a + to the line when used on
> files. Am not sure but my $rawline was:
> +The the repeated word.
The + is the first character of an added line in a
patch.
That's different from lines in a commit message so
there needs to be an additional mechanism to strip
the leading + when not !$in_commit_log.
Add:
pos($rawline) = 1 if (!$in_commit_log);
and test the start position too
---
scripts/checkpatch.pl | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index fab38b493cef..99563b3d5a3e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3050,19 +3050,28 @@ sub process {
# check for repeated words separated by a single space
if ($rawline =~ /^\+/ || $in_commit_log) {
+ pos($rawline) = 1 if (!$in_commit_log);
while ($rawline =~ /\b($word_pattern)
(?=($word_pattern))/g) {
-
my $first = $1;
my $second = $2;
+ my $start_pos = $-[1];
+ my $end_pos = $+[2];
if ($first =~ /(?:struct|union|enum)/) {
pos($rawline) += length($first) +
length($second) + 1;
next;
}
- next if ($first ne $second);
+ next if (lc($first) ne lc($second));
next if ($first eq 'long');
+ my $start_char = "";
+ my $end_char = "";
+ $start_char = substr($rawline, $start_pos - 1,
1) if ($start_pos > ($in_commit_log ? 0 : 1));
+ $end_char = substr($rawline, $end_pos, 1) if
(length($rawline) > $end_pos);
+ next if ($start_char =~ /^\S$/);
+ next if ($end_char !~ /^[\.\,\s]?$/);
+
if (WARN("REPEATED_WORD",
"Possible repeated word: '$first'\n" .
$herecurr) &&
$fix) {
Re: [PATCH 4.19 00/21] 4.19.152-rc1 review
On Fri, 16 Oct 2020 at 14:40, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.152 release. > There are 21 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 18 Oct 2020 09:04:25 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.152-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 4.19.152-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: 5f066e3d5e44986dffd040360637a0dee8c66ccb git describe: v4.19.151-22-g5f066e3d5e44 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.151-22-g5f066e3d5e44 No regressions (compared to build v4.19.151) No fixes (compared to build v4.19.151) Ran 27932 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - juno-r2-compat - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * linux-log-parser * ltp-cve-tests * ltp-hugetlb-tests * ltp-ipc-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * perf * v4l2-compliance * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-io-tests * ltp-math-tests * ltp-sched-tests * network-basic-tests * ltp-cap_bounds-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-fs-tests * ssuite * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v7 4/4] bus: mhi: Add userspace client interface driver
Hi Hemant,
I love your patch! Perhaps something to improve:
[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on staging/staging-testing linus/master next-20201016]
[cannot apply to linux/master v5.9]
[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]
url:
https://github.com/0day-ci/linux/commits/Hemant-Kumar/userspace-MHI-client-interface-driver/20201017-140145
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
f3277cbfba763cd2826396521b9296de67cf1bbc
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/6f44d9c0efd29cbd60a4c26843462a573050a520
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Hemant-Kumar/userspace-MHI-client-interface-driver/20201017-140145
git checkout 6f44d9c0efd29cbd60a4c26843462a573050a520
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:11,
from drivers/bus/mhi/uci.c:4:
include/linux/scatterlist.h: In function 'sg_set_buf':
arch/m68k/include/asm/page_mm.h:169:49: warning: ordered comparison of
pointer with null pointer [-Wextra]
169 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void
*)PAGE_OFFSET && (void *)(kaddr) < high_memory)
| ^~
include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
78 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
include/linux/scatterlist.h:143:2: note: in expansion of macro 'BUG_ON'
143 | BUG_ON(!virt_addr_valid(buf));
| ^~
include/linux/scatterlist.h:143:10: note: in expansion of macro
'virt_addr_valid'
143 | BUG_ON(!virt_addr_valid(buf));
| ^~~
In file included from include/linux/printk.h:405,
from include/linux/kernel.h:15,
from drivers/bus/mhi/uci.c:4:
drivers/bus/mhi/uci.c: In function 'mhi_queue_inbound':
>> drivers/bus/mhi/uci.c:147:16: warning: format '%ld' expects argument of type
>> 'long int', but argument 6 has type 'size_t' {aka 'unsigned int'} [-Wformat=]
147 | dev_dbg(dev, "Allocated buf %d of %d size %ld\n", i, nr_trbs,
|^~~
include/linux/dynamic_debug.h:129:15: note: in definition of macro
'__dynamic_func_call'
129 | func(&id, ##__VA_ARGS__); \
| ^~~
include/linux/dynamic_debug.h:161:2: note: in expansion of macro
'_dynamic_func_call'
161 | _dynamic_func_call(fmt,__dynamic_dev_dbg, \
| ^~
include/linux/dev_printk.h:115:2: note: in expansion of macro
'dynamic_dev_dbg'
115 | dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~
include/linux/dev_printk.h:115:23: note: in expansion of macro 'dev_fmt'
115 | dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~
drivers/bus/mhi/uci.c:147:3: note: in expansion of macro 'dev_dbg'
147 | dev_dbg(dev, "Allocated buf %d of %d size %ld\n", i, nr_trbs,
| ^~~
drivers/bus/mhi/uci.c:147:47: note: format string is defined here
147 | dev_dbg(dev, "Allocated buf %d of %d size %ld\n", i, nr_trbs,
| ~~^
| |
| long int
| %d
In file included from include/linux/printk.h:405,
from include/linux/kernel.h:15,
from drivers/bus/mhi/uci.c:4:
drivers/bus/mhi/uci.c: In function 'mhi_uci_write':
>> drivers/bus/mhi/uci.c:308:15: warning: format '%lu' expects argument of type
>> 'long unsigned int', but argument 5 has type 'size_t' {aka 'unsigned int'}
>> [-Wformat=]
308 | dev_dbg(dev, "%s: to xfer: %lu bytes\n", __func__, count
Re: [PATCH 2/2] arm64: allow hotpluggable sections to be offlined
> Am 17.10.2020 um 04:03 schrieb Sudarshan Rajagopalan
> :
>
> On receiving the MEM_GOING_OFFLINE notification, we disallow offlining of
> any boot memory by checking if section_early or not. With the introduction
> of SECTION_MARK_HOTPLUGGABLE, allow boot mem sections that are marked as
> hotpluggable with this bit set to be offlined and removed. This now allows
> certain boot mem sections to be offlined.
>
The check (notifier) is in arm64 code. I don‘t see why you cannot make such
decisions completely in arm64 code? Why would you have to mark sections?
Also, I think I am missing from *where* the code that marks sections removable
is even called? Who makes such decisions?
This feels wrong.
> Signed-off-by: Sudarshan Rajagopalan
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Anshuman Khandual
> Cc: Mark Rutland
> Cc: Gavin Shan
> Cc: Logan Gunthorpe
> Cc: David Hildenbrand
> Cc: Andrew Morton
> Cc: Steven Price
> Cc: Suren Baghdasaryan
> ---
> arch/arm64/mm/mmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 75df62fea1b6..fb8878698672 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1487,7 +1487,7 @@ static int prevent_bootmem_remove_notifier(struct
> notifier_block *nb,
>
>for (; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
>ms = __pfn_to_section(pfn);
> -if (early_section(ms))
> +if (early_section(ms) && !removable_section(ms))
>return NOTIFY_BAD;
>}
>return NOTIFY_OK;
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
[PATCH] block: use helper function bio_copy_dev to __bio_clone_fast
We have introduced helper function bio_copy_dev. Just use it. Signed-off-by: Jeff Xie --- block/bio.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/block/bio.c b/block/bio.c index 640d0fb..9fce7df 100644 --- a/block/bio.c +++ b/block/bio.c @@ -679,8 +679,6 @@ void __bio_clone_fast(struct bio *bio, struct bio *bio_src) * most users will be overriding ->bi_disk with a new target, * so we don't set nor calculate new physical/hw segment counts here */ - bio->bi_disk = bio_src->bi_disk; - bio->bi_partno = bio_src->bi_partno; bio_set_flag(bio, BIO_CLONED); if (bio_flagged(bio_src, BIO_THROTTLED)) bio_set_flag(bio, BIO_THROTTLED); @@ -690,7 +688,7 @@ void __bio_clone_fast(struct bio *bio, struct bio *bio_src) bio->bi_iter = bio_src->bi_iter; bio->bi_io_vec = bio_src->bi_io_vec; - bio_clone_blkg_association(bio, bio_src); + bio_copy_dev(bio, bio_src); blkcg_bio_issue_init(bio); } EXPORT_SYMBOL(__bio_clone_fast); -- 1.8.3.1
Re: [PATCH v1 05/29] virtio-mem: generalize check for added memory
> Am 17.10.2020 um 00:38 schrieb Wei Yang : > > On Fri, Oct 16, 2020 at 12:32:50PM +0200, David Hildenbrand wrote: > Ok, I seems to understand the logic now. > > But how we prevent ONLINE_PARTIAL memory block get offlined? There are > three > calls in virtio_mem_set_fake_offline(), while all of them adjust page's > flag. > How they hold reference to struct page? Sorry, I should have given you the right pointer. (similar to my other reply) We hold a reference either via 1. alloc_contig_range() >>> >>> I am not familiar with this one, need to spend some time to look into. >> >> Each individual page will have a pagecount of 1. >> >>> 2. memmap init code, when not calling generic_online_page(). >>> >>> I may miss some code here. Before online pages, memmaps are allocated in >>> section_activate(). They are supposed to be zero-ed. (I don't get the exact >>> code line.) I am not sure when we grab a refcount here. >> >> Best to refer to __init_single_page() -> init_page_count(). >> >> Each page that wasn't onlined via generic_online_page() has a refcount >> of 1 and looks like allocated. >> > > Thanks, I see the logic. > >online_pages() >move_pfn_range_to_zone() --- 1) >online_pages_range() --- 2) > > At 1), __init_single_page() would set page count to 1. At 2), > generic_online_page() would clear page count, while the call back would not. > > Then I am trying to search the place where un-zero page count prevent offline. > scan_movable_pages() would fail, since this is a PageOffline() and has 1 page > count. > > So the GUARD we prevent offline partial-onlined pages is > >(PageOffline && page_count) > > And your commit aa218795cb5fd583c94f > > mm: Allow to offline unmovable PageOffline() pages via MEM_GOING_OFFLINE > > is introduced to handle this case. > > That's pretty clear now. > I‘m happy to see that I am no longer the only person that understands all this magic :) Thanks for having a look / reviewing! >> -- >> Thanks, >> >> David / dhildenb > > -- > Wei Yang > Help you, Help me >
Re: [PATCH] kasan: adopt KUNIT tests to SW_TAGS mode
On Sat, Oct 17, 2020 at 3:33 AM Andrey Konovalov wrote: > > Now that we have KASAN-KUNIT tests integration, it's easy to see that > some KASAN tests are not adopted to the SW_TAGS mode and are failing. > > Adjust the allocation size for kasan_memchr() and kasan_memcmp() by > roung it up to OOB_TAG_OFF so the bad access ends up in a separate > memory granule. > > Add new kmalloc_uaf_16() and kasan_bitops_uaf() tests that rely on UAFs, > as it's hard to adopt the existing kmalloc_oob_16() and kasan_bitops_oob() > (rename from kasan_bitops()) without losing the precision. > > Disable kasan_global_oob() and kasan_alloca_oob_left/right() as SW_TAGS > mode doesn't instrument globals nor dynamic allocas. > > Signed-off-by: Andrey Konovalov This looks good to me. Though, as you mention, writing to freed memory might not bode well for system stability after the test runs. I don't think that needs to be a goal for these tests, though. One thing which we're hoping to add to KUnit soon is support for skipping tests: once that's in place, we can use it to mark tests as explicitly skipped if they rely on the GENERIC mode. That'll take a little while to get upstream though, so I wouldn't want to hold this up for it. Otherwise, from the KUnit side, this looks great. I also tested it against the GENERIC mode on x86_64 (which is all I have set up here at the moment), and nothing obviously had broken. So: Tested-by: David Gow Cheers, -- David
Re: [PATCH 4.14 00/18] 4.14.202-rc1 review
On Fri, 16 Oct 2020 at 14:39, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.202 release. > There are 18 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 18 Oct 2020 09:04:25 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.202-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 4.14.202-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: 7d10bbd1a87237a93f881d8cd84dc686b9212378 git describe: v4.14.201-19-g7d10bbd1a872 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.201-19-g7d10bbd1a872 No regressions (compared to build v4.14.201) No fixes (compared to build v4.14.201) Ran 24934 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * linux-log-parser * ltp-cap_bounds-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * perf * libhugetlbfs * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-ipc-tests * ltp-math-tests * network-basic-tests * v4l2-compliance * ltp-fs-tests * ssuite -- Linaro LKFT https://lkft.linaro.org
[PATCH v4] checkpatch: add new exception to repeated word check
Recently, commit 4f6ad8aa1eac ("checkpatch: move repeated word test")
moved the repeated word test to check for more file types. But after
this, if checkpatch.pl is run on MAINTAINERS, it generates several
new warnings of the type:
WARNING: Possible repeated word: 'git'
For example:
WARNING: Possible repeated word: 'git'
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git
So, the pattern "git git://..." is a false positive in this case.
There are several other combinations which may produce a wrong
warning message, such as "@size size", ":Begin begin", etc.
Extend repeated word check to compare the characters before and
after the word matches. If the preceding or succeeding character
belongs to the exception list, the warning is avoided.
Link:
https://lore.kernel.org/linux-kernel-mentees/81b6a0bb2c7b9256361573f7a13201ebcd4876f1.ca...@perches.com/
Suggested-by: Joe Perches
Suggested-by: Lukas Bulwahn
Signed-off-by: Dwaipayan Ray
---
scripts/checkpatch.pl | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index f1a4e61917eb..5dc5bf75c6e7 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3052,19 +3052,30 @@ sub process {
# check for repeated words separated by a single space
if ($rawline =~ /^\+/ || $in_commit_log) {
+ pos($rawline) = 1 if (!$in_commit_log);
while ($rawline =~ /\b($word_pattern)
(?=($word_pattern))/g) {
my $first = $1;
my $second = $2;
-
+ my $start_pos = $-[1];
+ my $end_pos = $+[2];
if ($first =~ /(?:struct|union|enum)/) {
pos($rawline) += length($first) +
length($second) + 1;
next;
}
- next if ($first ne $second);
+ next if (lc($first) ne lc($second));
next if ($first eq 'long');
+ # check for character before and after the word
matches
+ my $start_char = '';
+ my $end_char = '';
+ $start_char = substr($rawline, $start_pos - 1,
1) if ($start_pos > ($in_commit_log? 0 : 1));
+ $end_char = substr($rawline, $end_pos, 1) if
($end_pos < length($rawline));
+
+ next if ($start_char =~ /^\S$/);
+ next if ($end_char !~ /^[\.\,\;\?\!\s]?$/);
+
if (WARN("REPEATED_WORD",
"Possible repeated word: '$first'\n" .
$herecurr) &&
$fix) {
--
2.27.0
Re: [PATCH 4.9 00/16] 4.9.240-rc1 review
On Fri, 16 Oct 2020 at 14:38, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.240 release. > There are 16 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 18 Oct 2020 09:04:25 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.240-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 4.9.240-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: eb0fbe0c6b1c2863b26464de441a406275c47b6d git describe: v4.9.239-17-geb0fbe0c6b1c Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.9.y/build/v4.9.239-17-geb0fbe0c6b1c No regressions (compared to build v4.9.239) No fixes (compared to build v4.9.239) Ran 17816 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-tracing-tests * perf * v4l2-compliance * network-basic-tests * ltp-syscalls-tests * ssuite -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 1/2] drm/mcde: Fix handling of platform_get_irq() error
Hi Krzysztof
On Thu, Aug 27, 2020 at 09:11:06AM +0200, Krzysztof Kozlowski wrote:
> platform_get_irq() returns -ERRNO on error. In such case comparison
> to 0 would pass the check.
>
> Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
> Signed-off-by: Krzysztof Kozlowski
Thanks, applied this and the tve200 patch to drm-misc-next.
They will appear in -next in a few weeks time.
Sam
[GIT PULL] i3c: Changes for 5.10
Hello Linus, I'm a bit late, but here is the I3C PR for 5.10. Regards, Boris The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux.git tags/i3c/for-5.10 for you to fetch changes up to abea14bfdebbe9bd02f2ad24a1f3a878ed21c8f0: i3c: master: Fix error return in cdns_i3c_master_probe() (2020-10-07 15:14:07 +0200) * Fix DAA for the pre-reserved address case * Fix an error path in the cadence driver Jing Xiangfeng (1): i3c: master: Fix error return in cdns_i3c_master_probe() Parshuram Thombare (2): i3c: master add i3c_master_attach_boardinfo to preserve boardinfo i3c: master: fix for SETDASA and DAA process drivers/i3c/master.c | 144 +++-- drivers/i3c/master/i3c-master-cdns.c | 4 +++- 2 files changed, 94 insertions(+), 54 deletions(-)
Re: [PATCH] drm/bridge/tc358775: Fixes bus formats read
Hi Vinay On Tue, Sep 08, 2020 at 08:57:07PM +0300, Laurent Pinchart wrote: > Hi Vinay, > > On Tue, Sep 08, 2020 at 11:22:48PM +0530, Vinay Simha B N wrote: > > laurent, > > > > Please review or give some feedback. > > I'm sorry, I have very little time these days :-( Maybe Neil can provide > feedback ? I have lost the original patch - if this is still pending could you then please resend. Thanks, Sam
Re: [PATCH] ALSA: hda/ca0132: make some const arrays static, makes object smaller
On Sat, 17 Oct 2020 00:49:13 +0200, Colin King wrote: > > From: Colin Ian King > > Don't populate const arrays on the stack but instead make them > static. Makes the object code smaller by 57 bytes. > > Before: >text data bss dec hex filename > 173256 38016 192 211464 33a08 sound/pci/hda/patch_ca0132.o > > After: >text data bss dec hex filename > 172879 38336 192 211407 339cf sound/pci/hda/patch_ca0132.o > > (gcc version 10.2.0) > > Signed-off-by: Colin Ian King Thanks, applied. Takashi
Re: [PATCH v2] sound: sparc: dbri: fix repeated word 'the'
On Fri, 16 Oct 2020 19:44:05 +0200, Randy Dunlap wrote: > > Change the duplicated word "the" to "Then the". > > Signed-off-by: Randy Dunlap > Cc: Jaroslav Kysela > Cc: Takashi Iwai > Cc: alsa-de...@alsa-project.org > Cc: Joe Perches > --- > v2: use "Then the" instead of just "The". (Joe Perches) Thanks, applied now. Takashi
Re: [PATCH 2/2] drm/panel: simple: Add support for Innolux LS075AT011
Hi Lubomir.
Sorry for the late feedback!
On Wed, Aug 19, 2020 at 12:12:06PM +0200, Lubomir Rintel wrote:
> This adds support for the Innolux LS075AT011 7.5" 1200x900 panel. There's
> no public data sheet for the panel -- the values have been taken from Open
> Firmware and the documentation for the display controller that drives
> the panel and tested on the OLPC laptop.
>
> Signed-off-by: Lubomir Rintel
> ---
> drivers/gpu/drm/panel/panel-simple.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index cb6550d37e858..dfc69457ed2d4 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2121,6 +2121,30 @@ static const struct panel_desc innolux_g121x1_l03 = {
> },
> };
>
> +static const struct display_timing innolux_ls075at011_timing = {
> + .pixelclock = { 5600, 5700, 5800 },
> + .hactive = { 1200, 1200, 1200 },
> + .hfront_porch = { 26, 26, 26 },
> + .hback_porch = { 24, 24, 24 },
> + .hsync_len = { 6, 6, 6 },
> + .vactive = { 900, 900, 900 },
> + .vfront_porch = { 4, 4, 4 },
> + .vback_porch = { 5, 5, 5 },
> + .vsync_len = { 3, 3, 3 },
> + .flags = DISPLAY_FLAGS_VSYNC_LOW | DISPLAY_FLAGS_HSYNC_LOW,
> +};
> +
> +static const struct panel_desc innolux_ls075at011 = {
> + .timings = &innolux_ls075at011_timing,
> + .num_timings = 1,
> + .bpc = 8,
> + .size = {
> + .width = 152,
> + .height = 115,
> + },
> + .connector_type = DRM_MODE_CONNECTOR_LVDS,
> +};
For LVDS panels following info is mandatory:
.bus_flags
.bus_format
You have .bpc - so this part is OK.
See the checks in panel_simple_probe() - thay are not allowed to trigger
for any new panels.
Sam
Re: [PATCH 4.4 00/16] 4.4.240-rc1 review
On Fri, 16 Oct 2020 at 14:37, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.240 release. > There are 16 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 18 Oct 2020 09:04:25 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.240-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 4.4.240-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: a37fadd41628f67d277436bb904352b926a59cff git describe: v4.4.239-17-ga37fadd41628 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.4.y/build/v4.4.239-17-ga37fadd41628 No regressions (compared to build v4.4.239) No fixes (compared to build v4.4.239) Ran 11616 total tests in the following environments and test suites. Environments -- - i386 - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * perf * v4l2-compliance * install-android-platform-tools-r2600 * ssuite Summary kernel: 4.4.240-rc1 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.240-rc1-hikey-20201016-831 git commit: 9a6146f70d93713dc4685a840e490dec2d007af8 git describe: 4.4.240-rc1-hikey-20201016-831 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.240-rc1-hikey-20201016-831 No regressions (compared to build 4.4.239-rc1-hikey-20201012-828) No fixes (compared to build 4.4.239-rc1-hikey-20201012-828) Ran 1760 total tests in the following environments and test suites. Environments -- - hi6220-hikey - arm64 Test Suites --- * build * install-android-platform-tools-r2600 * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * spectre-meltdown-checker-test * v4l2-compliance -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH] drm/via: reduce no need mutex_lock area
Hi Bernard. On Fri, Aug 14, 2020 at 01:30:19AM -0700, Bernard Zhao wrote: > In function via_mem_alloc`s error branch, DRM_ERROR is protected > in the mutex_lock(&dev->struct_mutex) area. > >From the code, we see that DRM_ERROR is just an error log print > without any struct element, there is no need to protect this. > > Signed-off-by: Bernard Zhao Thanks, applied to drm-misc-next. The patch will show up in -next in a few weeks. Sam
Re: [PATCH 4.19 14/21] staging: comedi: check validity of wMaxPacketSize of usb endpoints found
On Fri, Oct 16, 2020 at 03:06:27PM +0200, Pavel Machek wrote: > Hi! > > > From: Anant Thazhemadam > > > > commit e1f13c879a7c21bd207dc6242455e8e3a1e88b40 upstream. > > > > While finding usb endpoints in vmk80xx_find_usb_endpoints(), check if > > wMaxPacketSize = 0 for the endpoints found. > > > > Some devices have isochronous endpoints that have wMaxPacketSize = 0 > > (as required by the USB-2 spec). > > However, since this doesn't apply here, wMaxPacketSize = 0 can be > > considered to be invalid. > > > > Reported-by: syzbot+009f546aa1370056b...@syzkaller.appspotmail.com > > Tested-by: syzbot+009f546aa1370056b...@syzkaller.appspotmail.com > > Signed-off-by: Anant Thazhemadam > > Cc: stable > > Link: > > https://lore.kernel.org/r/20201010082933.5417-1-anant.thazhema...@gmail.com > > Signed-off-by: Greg Kroah-Hartman > > Signed-off-by: Greg Kroah-Hartman > > Why duplicate Sign-off? My scripts, I missed this :(
Re: [PATCH 1/2] mm/memory_hotplug: allow marking of memory sections as hotpluggable
On Fri, Oct 16, 2020 at 07:02:23PM -0700, Sudarshan Rajagopalan wrote:
> Certain architectures such as arm64 doesn't allow boot memory to be
> offlined and removed. Distinguish certain memory sections as
> "hotpluggable" which can be marked by module drivers stating to memory
> hotplug layer that these sections can be offlined and then removed.
I don't quite follow why marking sections as hotpluggable or not should
be done by a device driver. Can you describe in more details your
use-case and why there is a need to add a flag to the memory map?
> This is done by using a separate section memory mab bit and setting it,
> rather than clearing the existing SECTION_IS_EARLY bit.
> This patch introduces SECTION_MARK_HOTPLUGGABLE bit into section mem map.
> Only the allowed sections which are in movable zone and have unmovable
> pages are allowed to be set with this new bit.
>
> Signed-off-by: Sudarshan Rajagopalan
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Mike Rapoport
> Cc: Anshuman Khandual
> Cc: David Hildenbrand
> Cc: Mark Rutland
> Cc: Steven Price
> Cc: Logan Gunthorpe
> Cc: Suren Baghdasaryan
> ---
> include/linux/memory_hotplug.h | 1 +
> include/linux/mmzone.h | 9 -
> mm/memory_hotplug.c| 20
> mm/sparse.c| 31 +++
> 4 files changed, 60 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 375515803cd8..81df45b582c8 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -319,6 +319,7 @@ extern int offline_pages(unsigned long start_pfn,
> unsigned long nr_pages);
> extern int remove_memory(int nid, u64 start, u64 size);
> extern void __remove_memory(int nid, u64 start, u64 size);
> extern int offline_and_remove_memory(int nid, u64 start, u64 size);
> +extern int mark_memory_hotpluggable(unsigned long start, unsigned long end);
>
> #else
> static inline void try_offline_node(int nid) {}
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 8379432f4f2f..3df3a4975236 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1247,7 +1247,8 @@ extern size_t mem_section_usage_size(void);
> #define SECTION_HAS_MEM_MAP (1UL<<1)
> #define SECTION_IS_ONLINE(1UL<<2)
> #define SECTION_IS_EARLY (1UL<<3)
> -#define SECTION_MAP_LAST_BIT (1UL<<4)
> +#define SECTION_MARK_HOTPLUGGABLE(1UL<<4)
> +#define SECTION_MAP_LAST_BIT (1UL<<5)
> #define SECTION_MAP_MASK (~(SECTION_MAP_LAST_BIT-1))
> #define SECTION_NID_SHIFT3
>
> @@ -1278,6 +1279,11 @@ static inline int early_section(struct mem_section
> *section)
> return (section && (section->section_mem_map & SECTION_IS_EARLY));
> }
>
> +static inline int removable_section(struct mem_section *section)
> +{
> + return (section && (section->section_mem_map &
> SECTION_MARK_HOTPLUGGABLE));
> +}
> +
> static inline int valid_section_nr(unsigned long nr)
> {
> return valid_section(__nr_to_section(nr));
> @@ -1297,6 +1303,7 @@ static inline int online_section_nr(unsigned long nr)
> void online_mem_sections(unsigned long start_pfn, unsigned long end_pfn);
> #ifdef CONFIG_MEMORY_HOTREMOVE
> void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn);
> +int section_mark_hotpluggable(struct mem_section *ms);
> #endif
> #endif
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index e9d5ab5d3ca0..503b0de489a0 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1860,4 +1860,24 @@ int offline_and_remove_memory(int nid, u64 start, u64
> size)
> return rc;
> }
> EXPORT_SYMBOL_GPL(offline_and_remove_memory);
> +
> +int mark_memory_hotpluggable(unsigned long start_pfn, unsigned long end_pfn)
> +{
> + struct mem_section *ms;
> + unsigned long nr;
> + int rc = -EINVAL;
> +
> + if (end_pfn < start_pfn)
> + return rc;
> +
> + for (nr = start_pfn; nr <= end_pfn; nr++) {
> + ms = __pfn_to_section(nr);
> + rc = section_mark_hotpluggable(ms);
> + if (!rc)
> + break;
> + }
> +
> + return rc;
> +}
> +EXPORT_SYMBOL_GPL(mark_memory_hotpluggable);
> #endif /* CONFIG_MEMORY_HOTREMOVE */
> diff --git a/mm/sparse.c b/mm/sparse.c
> index fcc3d176f1ea..cc21c23e2f1d 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
>
> #include "internal.h"
> #include
> @@ -644,6 +645,36 @@ void offline_mem_sections(unsigned long start_pfn,
> unsigned long end_pfn)
> ms->section_mem_map &= ~SECTION_IS_ONLINE;
> }
> }
> +
> +int section_mark_hotpluggable(struct mem_section *ms)
> +{
> + unsigned long section_nr, pfn;
> + bool unmovable;
> + struct page *page;
> +
> + /* section needs to be both valid and present to be marked */
> + if (WARN_ON(!valid_section(m
Re: [PATCH] fat: Add KUnit tests for checksums and timestamps
David Gow writes:
> Add some basic sanity-check tests for the fat_checksum() function and
> the fat_time_unix2fat() and fat_time_fat2unix() functions. These unit
> tests verify these functions return correct output for a number of test
> inputs.
>
> These tests were inspored by -- and serve a similar purpose to -- the
> timestamp parsing KUnit tests in ext4[1].
>
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/ext4/inode-test.c
>
> Signed-off-by: David Gow
Looks good, thanks.
Acked-by: OGAWA Hirofumi
> ---
> fs/fat/Kconfig| 13 +++
> fs/fat/Makefile | 2 +
> fs/fat/fat_test.c | 197 ++
> 3 files changed, 212 insertions(+)
> create mode 100644 fs/fat/fat_test.c
>
> diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
> index 66532a71e8fd..fdef03b79c69 100644
> --- a/fs/fat/Kconfig
> +++ b/fs/fat/Kconfig
> @@ -115,3 +115,16 @@ config FAT_DEFAULT_UTF8
> Say Y if you use UTF-8 encoding for file names, N otherwise.
>
> See for more information.
> +
> +config FAT_KUNIT_TEST
> + tristate "Unit Tests for FAT filesystems" if !KUNIT_ALL_TESTS
> + select FAT_FS
> + depends on KUNIT
> + default KUNIT_ALL_TESTS
> + help
> + This builds the FAT KUnit tests
> +
> + For more information on KUnit and unit tests in general, please refer
> + to the KUnit documentation in Documentation/dev-tools/kunit
> +
> + If unsure, say N
> diff --git a/fs/fat/Makefile b/fs/fat/Makefile
> index 70645ce2f7fc..2b034112690d 100644
> --- a/fs/fat/Makefile
> +++ b/fs/fat/Makefile
> @@ -10,3 +10,5 @@ obj-$(CONFIG_MSDOS_FS) += msdos.o
> fat-y := cache.o dir.o fatent.o file.o inode.o misc.o nfs.o
> vfat-y := namei_vfat.o
> msdos-y := namei_msdos.o
> +
> +obj-$(CONFIG_FAT_KUNIT_TEST) += fat_test.o
> diff --git a/fs/fat/fat_test.c b/fs/fat/fat_test.c
> new file mode 100644
> index ..c1b4348b9b3b
> --- /dev/null
> +++ b/fs/fat/fat_test.c
> @@ -0,0 +1,197 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KUnit tests for FAT filesystems.
> + *
> + * Copyright (C) 2020 Google LLC.
> + * Author: David Gow
> + */
> +
> +#include
> +
> +#include "fat.h"
> +
> +static void fat_checksum_test(struct kunit *test)
> +{
> + /* With no extension. */
> + KUNIT_EXPECT_EQ(test, fat_checksum("VMLINUX"), 44);
> + /* With 3-letter extension. */
> + KUNIT_EXPECT_EQ(test, fat_checksum("README TXT"), 115);
> + /* With short (1-letter) extension. */
> + KUNIT_EXPECT_EQ(test, fat_checksum("ABCDEFGHA "), 98);
> +}
> +
> +
> +struct fat_timestamp_testcase {
> + const char *name;
> + struct timespec64 ts;
> + __le16 time;
> + __le16 date;
> + u8 cs;
> + int time_offset;
> +};
> +
> +const static struct fat_timestamp_testcase time_test_cases[] = {
> + {
> + .name = "Earliest possible UTC (1980-01-01 00:00:00)",
> + .ts = {.tv_sec = 315532800LL, .tv_nsec = 0L},
> + .time = 0,
> + .date = 33,
> + .cs = 0,
> + .time_offset = 0,
> + },
> + {
> + .name = "Latest possible UTC (2107-12-31 23:59:58)",
> + .ts = {.tv_sec = 4354819198LL, .tv_nsec = 0L},
> + .time = 49021,
> + .date = 65439,
> + .cs = 0,
> + .time_offset = 0,
> + },
> + {
> + .name = "Earliest possible (UTC-11) (== 1979-12-31 13:00:00
> UTC)",
> + .ts = {.tv_sec = 315493200LL, .tv_nsec = 0L},
> + .time = 0,
> + .date = 33,
> + .cs = 0,
> + .time_offset = 11 * 60,
> + },
> + {
> + .name = "Latest possible (UTC+11) (== 2108-01-01 10:59:58 UTC)",
> + .ts = {.tv_sec = 4354858798LL, .tv_nsec = 0L},
> + .time = 49021,
> + .date = 65439,
> + .cs = 0,
> + .time_offset = -11 * 60,
> + },
> + {
> + .name = "Leap Day / Year (1996-02-29 00:00:00)",
> + .ts = {.tv_sec = 825552000LL, .tv_nsec = 0L},
> + .time = 0,
> + .date = 8285,
> + .cs = 0,
> + .time_offset = 0,
> + },
> + {
> + .name = "Year 2000 is leap year (2000-02-29 00:00:00)",
> + .ts = {.tv_sec = 951782400LL, .tv_nsec = 0L},
> + .time = 0,
> + .date = 10333,
> + .cs = 0,
> + .time_offset = 0,
> + },
> + {
> + .name = "Year 2100 not leap year (2100-03-01 00:00:00)",
> + .ts = {.tv_sec = 4107542400LL, .tv_nsec = 0L},
> + .time = 0,
> + .date = 61537,
> + .cs = 0,
> + .time_offset = 0,
> + },
> + {
> + .name = "Leap year + timezone UTC+1 (== 2004-02-29 00:30:00
> UTC)",
> + .ts = {.tv_sec = 1078014600LL, .tv_nsec = 0L},
> + .time = 48064,
> + .date =
Re: [PATCH v2 0/3] drm/panel: mantix panel reset fixes
Hi Sam, On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sam Ravnborg wrote: > Hi Guido. > On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido Günther wrote: [..snip..] > > > > Changes from v1: > > - As per review comments by Fabio Estevam > > > > https://lore.kernel.org/dri-devel/CAOMZO5B5ECcConvKej=rcaf8wvoxgq7nuzkj-ad0asaozuq...@mail.gmail.com/ > >- Fix typo in commit messages > > - As per review comments by Rob Herring > >https://lore.kernel.org/dri-devel/20200929174624.GA832332@bogus/ > >- Don't use an array of reset lines > > > > Guido Günther (3): > > drm/panel: mantix: Don't dereference NULL mode > > drm/panel: mantix: Fix panel reset > > dt-binding: display: Require two resets on mantix panel > > All applied to drm-misc-next and pushed out. > And then I remembered you had commit right - sigh. Thanks! Is there any special care needed to get that into 5.10? The driver landed there in 72967d5616d3f0c714f8eb6c4e258179a9031c45. Cheers, -- Guido > > Sam > > > > > .../display/panel/mantix,mlaf057we51-x.yaml | 4 +++ > > .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 25 +-- > > 2 files changed, 21 insertions(+), 8 deletions(-) > > > > -- > > 2.28.0 > > > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel >
Re: [PATCH v8 0/4] SFH: Add Support for AMD Sensor Fusion Hub
Hi Folks, On 10/10/2020 1:31 AM, Sandeep Singh wrote: From: Sandeep Singh AMD SFH(Sensor Fusion Hub) is HID based driver.SFH FW is part of MP2 processor (MP2 which is an ARM core connected to x86 for processing sensor data) and it runs on MP2 where in the driver resides on X86. The driver functionalities are divided into three parts:- 1: amd-mp2-pcie:- This part of the module will communicate with MP2 firmware. MP2 which is exposed as a PCI device to the X86, uses mailboxes to talk to MP2 firmware to send/receive commands. 2: Client Layer:- This part of the driver will use DRAM data and convert the data into HID format based on HID reports. 3: Transport layer :- This part of the driver the will communicate with HID core.Communication between devices and HID core is mostly done via HID reports In terms of architecture, it resembles like ISH (Intel Integrated Sensor Hub). However the major difference is all the hid reports are generated as part of the kernel driver. AMD SFH is integrated as a part of SoC, starting from 17h family of processors. The solution is working well on several OEM products. AMD SFH uses HID over PCIe bus. Changes since v1: -> Fix auto build test warnings -> Fix smatch warnings "possible memory leak" -Reported by Dan carpenter Links of the review comments for v1: [1] https://patchwork.kernel.org/patch/11325163/ [2] https://patchwork.kernel.org/patch/11325167/ [3] https://patchwork.kernel.org/patch/11325171/ [4] https://patchwork.kernel.org/patch/11325187/ Changes since v2: -> Debugfs divided into another patch -> Fix some cosmetic changes -> Fix for review comments Reported and Suggested by:- Srinivas Pandruvada Links of the review comments for v2: [1] https://patchwork.kernel.org/patch/11355491/ [2] https://patchwork.kernel.org/patch/11355495/ [3] https://patchwork.kernel.org/patch/11355499/ [4] https://patchwork.kernel.org/patch/11355503/ Changes since v3: -> Removed debugfs suggested by - Benjamin Tissoires Links of the review comments for v3: [1] https://lkml.org/lkml/2020/2/11/1256 [2] https://lkml.org/lkml/2020/2/11/1257 [3] https://lkml.org/lkml/2020/2/11/1258 [4] https://lkml.org/lkml/2020/2/11/1259 [5] https://lkml.org/lkml/2020/2/11/1260 Changes since v4: -> use PCI managed calls. -> use kernel APIs Links of the review comments for v4: [1] https://lkml.org/lkml/2020/2/26/1360 [2] https://lkml.org/lkml/2020/2/26/1361 [3] https://lkml.org/lkml/2020/2/26/1362 [4] https://lkml.org/lkml/2020/2/26/1363 [5] https://lkml.org/lkml/2020/2/27/1 Changes since v5 -> Fix for review comments by: Andy Shevchenko -> Fix for indentations erros, NULL pointer,Redundant assignment -> Drop LOCs in many location -> Create as a single driver module instead of two modules. Links of the review comments for v5: [1] https://lkml.org/lkml/2020/5/29/589 [2] https://lkml.org/lkml/2020/5/29/590 [3] https://lkml.org/lkml/2020/5/29/606 [4] https://lkml.org/lkml/2020/5/29/632 [5] https://lkml.org/lkml/2020/5/29/633 Changes since v6 -> fix Kbuild warning "warning: ignoring return value of 'pcim_enable_device', -> Removed select HID and add depends on HID Links of the review comments for v6: [1] https://lkml.org/lkml/2020/8/9/58 [2] https://lkml.org/lkml/2020/8/9/59 [3] https://lkml.org/lkml/2020/8/9/125 [4] https://lkml.org/lkml/2020/8/9/61 [5] https://lkml.org/lkml/2020/8/9/91 Changes since v7 -> Add Co-deveploed-by -> Build the Documentation -> Fix cosmatic changes -> Add init function inside probe function -> Use devm_add_action_or_reset() to avoids the remove() callback. Links of the review comments for v7: [1] https://lkml.org/lkml/2020/8/10/1221 [2] https://lkml.org/lkml/2020/8/10/1222 [3] https://lkml.org/lkml/2020/8/10/1223 [4] https://lkml.org/lkml/2020/8/10/1224 [5] https://lkml.org/lkml/2020/8/10/1225 Sandeep Singh (4): SFH: Add maintainers and documentation for AMD SFH based on HID framework SFH: PCIe driver to add support of AMD sensor fusion hub SFH:Transport Driver to add support of AMD Sensor Fusion Hub (SFH) SFH: Create HID report to Enable support of AMD sensor fusion Hub (SFH) Documentation/hid/amd-sfh-hid.rst | 145 Documentation/hid/index.rst | 1 + MAINTAINERS | 8 + drivers/hid/Kconfig | 2 + drivers/hid/Makefile
Re: arm64: dropping prevent_bootmem_remove_notifier
On 17.10.20 01:11, Sudarshan Rajagopalan wrote:
>
> Hello Anshuman,
>
David here,
in general, if your driver offlines+removes random memory, it is doing
something *very* wrong and dangerous. You shouldn't ever be
offlining+removing memory unless
a) you own that boot memory after boot. E.g., the ACPI driver owns DIMMs
after a reboot.
b) you added that memory via add_memory() and friends.
Even trusting that offline memory can be used by your driver is wrong.
Just imagine you racing with actual memory hot(un)plug, you'll be in
*big* trouble. For example,
1. You offlined memory and assume you can use it. A DIMM can simply get
unplugged. you're doomed.
2. You offlined+removed memory and assume you can use it. A DIMM can
simply get unplugged and the whole machine would crash.
Or imagine your driver running on a system that has virtio-mem, which
will try to remove/offline+remove memory that was added by virtio-mem/
is under its control.
Long story short: don't do it.
There is *one* instance in Linux where we currently allow it for legacy
reasons. It is powernv/memtrace code that offlines+removes boot memory.
But here we are guaranteed to run in an environment (HW) without any
actual memory hot(un)plug.
I guess you're going to say "but in our environment we don't have ..." -
this is not a valid argument to change such generic things upstream /
introducing such hacks.
> In the patch that enables memory hot-remove (commit bbd6ec605c0f
> ("arm64/mm: Enable memory hot remove")) for arm64, there’s a notifier
> put in place that prevents boot memory from being offlined and removed.
> Also commit text mentions that boot memory on arm64 cannot be removed.
> We wanted to understand more about the reasoning for this. X86 and other
> archs doesn’t seem to do this prevention. There’s also comment in the
> code that this notifier could be dropped in future if and when boot
> memory can be removed.
The issue is that with *actual* memory hotunplug (for what the whole
machinery should be used for), that memory/DIMM will be gone. And as you
cannot fixup the initial memmap, if you were to reboot that machine, you
would simply crash immediately.
On x86, you can have that easily: hotplug DIMMs on bare metal and
reboot. The DIMMs will be exposed via e820 during boot, so they are
"early", although if done right (movable_node, movable_core and
similar), they can get hotunplugged later. Important in environments
where you want to hotunplug whole nodes. But has HW on x86 will properly
adjust the initial memmap / e820, there is no such issue as on arm64.
>
> The current logic is that only “new” memory blocks which are hot-added
> can later be offlined and removed. The memory that system booted up with
> cannot be offlined and removed. But there could be many usercases such
> as inter-VM memory sharing where a primary VM could offline and
> hot-remove a block/section of memory and lend it to secondary VM where
> it could hot-add it. And after usecase is done, the reverse happens
That use case is using the wrong mechanisms. It shouldn't be
offlining+removing memory. Read below.
> where secondary VM hot-removes and gives it back to primary which can
> hot-add it back. In such cases, the present logic for arm64 doesn’t
> allow this hot-remove in primary to happen.
>
> Also, on systems with movable zone that sort of guarantees pages to be
> migrated and isolated so that blocks can be offlined, this logic also
> defeats the purpose of having a movable zone which system can rely on
> memory hot-plugging, which say virt-io mem also relies on for fully
> plugged memory blocks.
The MOVABLE_ZONE is *not* just for better guarantees when trying to
hotunplug memory. It also increases the number of THP/huge pages. And
that part works just fine.
>
> So we’re trying to understand the reasoning for such a prevention put in
> place for arm64 arch alone.
>
> One possible way to solve this is by marking the required sections as
> “non-early” by removing the SECTION_IS_EARLY bit in its section_mem_map.
> This puts these sections in the context of “memory hotpluggable” which
> can be offlined-removed and added-onlined which are part of boot RAM
> itself and doesn’t need any extra blocks to be hot added. This way of
> marking certain sections as “non-early” could be exported so that module
> drivers can set the required number of sections as “memory
Oh please no. No driver should be doing that. That's just hacking around
the root issue: you're not supposed to do that.
> hotpluggable”. This could have certain checks put in place to see which
> sections are allowed, example only movable zone sections can be marked
> as “non-early”.
>
I assume what your use case wants to achieve is, starting VMs with
large, contiguous memory backings, not wasting memory for the memmap in
the hypervisor.
The "traditional" way of doing that is using the "mem=" boot parameter,
and starting VMs with memory within the "never exposed
Re: [PATCH 1/2] mm/memory_hotplug: allow marking of memory sections as hotpluggable
On 17.10.20 10:26, Mike Rapoport wrote: > On Fri, Oct 16, 2020 at 07:02:23PM -0700, Sudarshan Rajagopalan wrote: >> Certain architectures such as arm64 doesn't allow boot memory to be >> offlined and removed. Distinguish certain memory sections as >> "hotpluggable" which can be marked by module drivers stating to memory >> hotplug layer that these sections can be offlined and then removed. > > I don't quite follow why marking sections as hotpluggable or not should > be done by a device driver. Can you describe in more details your > use-case and why there is a need to add a flag to the memory map? > This seems to be related to https://lkml.kernel.org/r/de8388df2fbc5a6a33aab95831ba7...@codeaurora.org After reading how the driver is trying to abuse memory hot(un)plug infrastructure, my tentative Nacked-by: David Hildenbrand -- Thanks, David / dhildenb
Re: [PATCH 4.19 00/21] 4.19.152-rc1 review
hi, On Fri, Oct 16, 2020 at 12:01:51PM -0700, Guenter Roeck wrote: > On Fri, Oct 16, 2020 at 11:07:19AM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.152 release. > > There are 21 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun, 18 Oct 2020 09:04:25 +. > > Anything received after that time might be too late. > > > > Build results: > total: 155 pass: 153 fail: 2 > Failed builds: > i386:tools/perf > x86_64:tools/perf I'm seeing the tools/perf failure as well: gcc -Wp,-MD,/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/util/intel-pt-decoder/.intel-pt-insn-decoder.o.d -Wp,-MT,/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.o -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -I/home/build/linux-4.19.152/tools/perf -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf -isystem /home/build/linux-4.19.152/debian/build/build-tools/include -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls -Wshadow -Wstrict-prototypes -Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat -Wstrict-aliasing=3 -DHAVE_ARCH_X86_64_SUPPORT -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/arch/x86/include/generated -DHAVE_SYSCALL_TABLE_SUPPORT -DHAVE_PERF_REGS_SUPPORT -DHAVE_ARCH_REGS_QUERY_REGISTER_OFFSET -O6 -fno-omit-frame-pointer -ggdb3 -funwind-tables -Wall -Wextra -std=gnu99 -fstack-protector-all -D_FORTIFY_SOURCE=2 -I/home/build/linux-4.19.152/tools/perf/util/include -I/home/build/linux-4.19.152/tools/perf/arch/x86/include -I/home/build/linux-4.19.152/tools/include/uapi -I/home/build/linux-4.19.152/tools/include/ -I/home/build/linux-4.19.152/tools/arch/x86/include/uapi -I/home/build/linux-4.19.152/tools/arch/x86/include/ -I/home/build/linux-4.19.152/tools/arch/x86/ -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf//util -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/ -I/home/build/linux-4.19.152/tools/perf/util -I/home/build/linux-4.19.152/tools/perf -I/home/build/linux-4.19.152/tools/lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DHAVE_SYNC_COMPARE_AND_SWAP_SUPPORT -DHAVE_PTHREAD_ATTR_SETAFFINITY_NP -DHAVE_PTHREAD_BARRIER -DHAVE_DWARF_GETLOCATIONS_SUPPORT -DHAVE_GLIBC_SUPPORT -DHAVE_SCHED_GETCPU_SUPPORT -DHAVE_SETNS_SUPPORT -DHAVE_CSTRACE_SUPPORT -DHAVE_LIBELF_SUPPORT -DHAVE_LIBELF_MMAP_SUPPORT -DHAVE_ELF_GETPHDRNUM_SUPPORT -DHAVE_GELF_GETNOTE_SUPPORT -DHAVE_ELF_GETSHDRSTRNDX_SUPPORT -DHAVE_DWARF_SUPPORT -DHAVE_LIBBPF_SUPPORT -DHAVE_BPF_PROLOGUE -DHAVE_JITDUMP -DHAVE_DWARF_UNWIND_SUPPORT -DNO_LIBUNWIND_DEBUG_FRAME -DHAVE_LIBUNWIND_SUPPORT -I/usr/include/slang -DHAVE_SLANG_SUPPORT -DHAVE_LIBPERL_SUPPORT -DHAVE_TIMERFD_SUPPORT -DHAVE_LIBPYTHON_SUPPORT -DHAVE_CPLUS_DEMANGLE_SUPPORT -DHAVE_ZLIB_SUPPORT -DHAVE_LZMA_SUPPORT -DHAVE_BACKTRACE_SUPPORT -DHAVE_LIBNUMA_SUPPORT -DHAVE_KVM_STAT_SUPPORT -DHAVE_PERF_READ_VDSO32 -DHAVE_PERF_READ_VDSOX32 -DHAVE_LIBBABELTRACE_SUPPORT -DHAVE_AUXTRACE_SUPPORT -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/ -D"BUILD_STR(s)=#s" -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/util/intel-pt-decoder -c -o /home/build/linux-4.19.152/debian/build/build-tools/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.o util/intel-pt-decoder/intel-pt-insn-decoder.c util/cs-etm-decoder/cs-etm-decoder.c: In function 'cs_etm_decoder__buffer_packet': util/cs-etm-decoder/cs-etm-decoder.c:287:24: error: 'traceid_list' undeclared (first use in this function); did you mean 'trace_event'? inode = intlist__find(traceid_list, trace_chan_id); ^~~~ trace_event util/cs-etm-decoder/cs-etm-decoder.c:287:24: note: each undeclared identifier is reported only once for each function it appears in make[8]: *** [/home/build/linux-4.19.152/tools/build/Makefile.build:97: /home/build/linux-4.19.152/debian/build/build-tools/tools/perf/util/cs-etm-decoder/cs-etm-decoder.o] Error 1 make[8]: Leaving directory '/home/build/linux-4.19.152/tools/perf' make[7]: *** [/home/build/linux-4.19.152/tools/build/Makefile.build:139: cs-etm-decoder] Error 2 Regards, Salvatore
Linux 4.4.240
I'm announcing the release of the 4.4.240 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 drivers/crypto/qat/qat_common/qat_algs.c | 10 +++- drivers/media/usb/usbtv/usbtv-core.c |3 - drivers/spi/spi.c|4 - drivers/staging/comedi/drivers/vmk80xx.c |3 + drivers/usb/serial/ftdi_sio.c|5 ++ drivers/usb/serial/ftdi_sio_ids.h|7 +++ drivers/usb/serial/option.c |5 ++ drivers/usb/serial/pl2303.c |1 drivers/usb/serial/pl2303.h |1 fs/reiserfs/inode.c |6 -- fs/reiserfs/xattr.c |7 +++ include/net/bluetooth/hci_core.h | 30 ++--- net/bluetooth/a2mp.c | 22 + net/bluetooth/hci_conn.c | 17 +++ net/bluetooth/hci_event.c| 70 --- net/bluetooth/mgmt.c |7 ++- 17 files changed, 140 insertions(+), 60 deletions(-) Alain Michaud (1): Bluetooth: fix kernel oops in store_pending_adv_report Anant Thazhemadam (1): staging: comedi: check validity of wMaxPacketSize of usb endpoints found Dominik Przychodni (1): crypto: qat - check cipher length for aead AES-CBC-HMAC-SHA Greg Kroah-Hartman (1): Linux 4.4.240 Jan Kara (2): reiserfs: Initialize inode keys properly reiserfs: Fix oops during mount Leonid Bloch (1): USB: serial: option: Add Telit FT980-KS composition Luiz Augusto von Dentz (4): Bluetooth: A2MP: Fix not initializing all members Bluetooth: MGMT: Fix not checking if BT_HS is enabled Bluetooth: Consolidate encryption handling in hci_encrypt_cfm Bluetooth: Disconnect if E0 is used for Level 4 Mychaela N. Falconia (1): USB: serial: ftdi_sio: add support for FreeCalypso JTAG+UART adapters Oliver Neukum (1): media: usbtv: Fix refcounting mixup Patrick Steinhardt (1): Bluetooth: Fix update of connection state in `hci_encrypt_cfm` Scott Chen (1): USB: serial: pl2303: add device-id for HP GC device Wilken Gottwalt (1): USB: serial: option: add Cellient MPL200 card yangerkun (1): spi: unbinding slave before calling spi_destroy_queue
Re: [PATCH 4.19 00/21] 4.19.152-rc1 review
On Sat, Oct 17, 2020 at 11:41:53AM +0200, Salvatore Bonaccorso wrote: > hi, > > On Fri, Oct 16, 2020 at 12:01:51PM -0700, Guenter Roeck wrote: > > On Fri, Oct 16, 2020 at 11:07:19AM +0200, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.19.152 release. > > > There are 21 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Sun, 18 Oct 2020 09:04:25 +. > > > Anything received after that time might be too late. > > > > > > > Build results: > > total: 155 pass: 153 fail: 2 > > Failed builds: > > i386:tools/perf > > x86_64:tools/perf > > I'm seeing the tools/perf failure as well: > > gcc > -Wp,-MD,/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/util/intel-pt-decoder/.intel-pt-insn-decoder.o.d > > -Wp,-MT,/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.o > -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall > -Wdate-time -D_FORTIFY_SOURCE=2 -I/home/build/linux-4.19.152/tools/perf > -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf -isystem > /home/build/linux-4.19.152/debian/build/build-tools/include > -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security > -Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes > -Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked > -Wredundant-decls -Wshadow -Wstrict-prototypes -Wswitch-default -Wswitch-enum > -Wundef -Wwrite-strings -Wformat -Wstrict-aliasing=3 > -DHAVE_ARCH_X86_64_SUPPORT > -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/arch/x86/include/generated > -DHAVE_SYSCALL_TABLE_SUPPORT -DHAVE_PERF_REGS_SUPPORT > -DHAVE_ARCH_REGS_QUERY_REGISTER_OFFSET -O6 -fno-omit-frame-pointer -ggdb3 > -funwind-tables -Wall -Wextra -std=gnu99 -fstack-protector-all > -D_FORTIFY_SOURCE=2 -I/home/build/linux-4.19.152/tools/perf/util/include > -I/home/build/linux-4.19.152/tools/perf/arch/x86/include > -I/home/build/linux-4.19.152/tools/include/uapi > -I/home/build/linux-4.19.152/tools/include/ > -I/home/build/linux-4.19.152/tools/arch/x86/include/uapi > -I/home/build/linux-4.19.152/tools/arch/x86/include/ > -I/home/build/linux-4.19.152/tools/arch/x86/ > -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf//util > -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/ > -I/home/build/linux-4.19.152/tools/perf/util > -I/home/build/linux-4.19.152/tools/perf > -I/home/build/linux-4.19.152/tools/lib/ -D_LARGEFILE64_SOURCE > -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DHAVE_SYNC_COMPARE_AND_SWAP_SUPPORT > -DHAVE_PTHREAD_ATTR_SETAFFINITY_NP -DHAVE_PTHREAD_BARRIER > -DHAVE_DWARF_GETLOCATIONS_SUPPORT -DHAVE_GLIBC_SUPPORT > -DHAVE_SCHED_GETCPU_SUPPORT -DHAVE_SETNS_SUPPORT -DHAVE_CSTRACE_SUPPORT > -DHAVE_LIBELF_SUPPORT -DHAVE_LIBELF_MMAP_SUPPORT > -DHAVE_ELF_GETPHDRNUM_SUPPORT -DHAVE_GELF_GETNOTE_SUPPORT > -DHAVE_ELF_GETSHDRSTRNDX_SUPPORT -DHAVE_DWARF_SUPPORT -DHAVE_LIBBPF_SUPPORT > -DHAVE_BPF_PROLOGUE -DHAVE_JITDUMP -DHAVE_DWARF_UNWIND_SUPPORT > -DNO_LIBUNWIND_DEBUG_FRAME -DHAVE_LIBUNWIND_SUPPORT -I/usr/include/slang > -DHAVE_SLANG_SUPPORT -DHAVE_LIBPERL_SUPPORT -DHAVE_TIMERFD_SUPPORT > -DHAVE_LIBPYTHON_SUPPORT -DHAVE_CPLUS_DEMANGLE_SUPPORT -DHAVE_ZLIB_SUPPORT > -DHAVE_LZMA_SUPPORT -DHAVE_BACKTRACE_SUPPORT -DHAVE_LIBNUMA_SUPPORT > -DHAVE_KVM_STAT_SUPPORT -DHAVE_PERF_READ_VDSO32 -DHAVE_PERF_READ_VDSOX32 > -DHAVE_LIBBABELTRACE_SUPPORT -DHAVE_AUXTRACE_SUPPORT > -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/ > -D"BUILD_STR(s)=#s" > -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/util/intel-pt-decoder > -c -o > /home/build/linux-4.19.152/debian/build/build-tools/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.o > util/intel-pt-decoder/intel-pt-insn-decoder.c > util/cs-etm-decoder/cs-etm-decoder.c: In function > 'cs_etm_decoder__buffer_packet': > util/cs-etm-decoder/cs-etm-decoder.c:287:24: error: 'traceid_list' undeclared > (first use in this function); did you mean 'trace_event'? > inode = intlist__find(traceid_list, trace_chan_id); > ^~~~ > trace_event > util/cs-etm-decoder/cs-etm-decoder.c:287:24: note: each undeclared identifier > is reported only once for each function it appears in > make[8]: *** [/home/build/linux-4.19.152/tools/build/Makefile.build:97: > /home/build/linux-4.19.152/debian/build/build-tools/tools/perf/util/cs-etm-decoder/cs-etm-decoder.o] > Error 1 > make[8]: Leaving directory '/home/build/linux-4.19.152/tools/perf' > make[7]: *** [/home/build/linux-4.19.152/tools/build/Makefile.build:139: > cs-etm-decoder] Error 2 Yeah, it's a mess, and I tried to unwind it, but it was not a simple fix. If people still care about building perf on 4.19 wit
Linux 4.14.202
I'm announcing the release of the 4.14.202 kernel. All users of the 4.14 kernel series must upgrade. The updated 4.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 drivers/crypto/bcm/cipher.c | 15 ++ drivers/crypto/qat/qat_common/qat_algs.c | 10 +++- drivers/media/usb/usbtv/usbtv-core.c |3 - drivers/net/ethernet/marvell/mvmdio.c| 22 +++-- drivers/staging/comedi/drivers/vmk80xx.c |3 + drivers/usb/serial/ftdi_sio.c|5 ++ drivers/usb/serial/ftdi_sio_ids.h|7 +++ drivers/usb/serial/option.c |5 ++ drivers/usb/serial/pl2303.c |1 drivers/usb/serial/pl2303.h |1 fs/reiserfs/inode.c |6 -- fs/reiserfs/xattr.c |7 +++ include/net/bluetooth/hci_core.h | 30 ++--- include/net/bluetooth/l2cap.h|2 net/bluetooth/a2mp.c | 22 + net/bluetooth/hci_conn.c | 17 +++ net/bluetooth/hci_event.c| 70 --- net/bluetooth/l2cap_core.c |7 +-- net/bluetooth/l2cap_sock.c | 14 ++ net/bluetooth/mgmt.c |7 ++- 21 files changed, 188 insertions(+), 68 deletions(-) Alain Michaud (1): Bluetooth: fix kernel oops in store_pending_adv_report Anant Thazhemadam (1): staging: comedi: check validity of wMaxPacketSize of usb endpoints found Arnaud Patard (1): drivers/net/ethernet/marvell/mvmdio.c: Fix non OF case Dominik Przychodni (1): crypto: qat - check cipher length for aead AES-CBC-HMAC-SHA Greg Kroah-Hartman (1): Linux 4.14.202 Herbert Xu (1): crypto: bcm - Verify GCM/CCM key length in setkey Jan Kara (2): reiserfs: Initialize inode keys properly reiserfs: Fix oops during mount Leonid Bloch (1): USB: serial: option: Add Telit FT980-KS composition Luiz Augusto von Dentz (5): Bluetooth: A2MP: Fix not initializing all members Bluetooth: L2CAP: Fix calling sk_filter on non-socket based channel Bluetooth: MGMT: Fix not checking if BT_HS is enabled Bluetooth: Consolidate encryption handling in hci_encrypt_cfm Bluetooth: Disconnect if E0 is used for Level 4 Mychaela N. Falconia (1): USB: serial: ftdi_sio: add support for FreeCalypso JTAG+UART adapters Oliver Neukum (1): media: usbtv: Fix refcounting mixup Patrick Steinhardt (1): Bluetooth: Fix update of connection state in `hci_encrypt_cfm` Scott Chen (1): USB: serial: pl2303: add device-id for HP GC device Wilken Gottwalt (1): USB: serial: option: add Cellient MPL200 card
Re: Linux 4.9.240
diff --git a/Makefile b/Makefile
index 82bb1b27d2f5..a6a9d494dc18 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 239
+SUBLEVEL = 240
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/drivers/crypto/qat/qat_common/qat_algs.c
b/drivers/crypto/qat/qat_common/qat_algs.c
index 20f35df8a01f..4f4884521a87 100644
--- a/drivers/crypto/qat/qat_common/qat_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_algs.c
@@ -822,6 +822,11 @@ static int qat_alg_aead_dec(struct aead_request *areq)
struct icp_qat_fw_la_bulk_req *msg;
int digst_size = crypto_aead_authsize(aead_tfm);
int ret, ctr = 0;
+ u32 cipher_len;
+
+ cipher_len = areq->cryptlen - digst_size;
+ if (cipher_len % AES_BLOCK_SIZE != 0)
+ return -EINVAL;
ret = qat_alg_sgl_to_bufl(ctx->inst, areq->src, areq->dst, qat_req);
if (unlikely(ret))
@@ -836,7 +841,7 @@ static int qat_alg_aead_dec(struct aead_request *areq)
qat_req->req.comn_mid.src_data_addr = qat_req->buf.blp;
qat_req->req.comn_mid.dest_data_addr = qat_req->buf.bloutp;
cipher_param = (void *)&qat_req->req.serv_specif_rqpars;
- cipher_param->cipher_length = areq->cryptlen - digst_size;
+ cipher_param->cipher_length = cipher_len;
cipher_param->cipher_offset = areq->assoclen;
memcpy(cipher_param->u.cipher_IV_array, areq->iv, AES_BLOCK_SIZE);
auth_param = (void *)((uint8_t *)cipher_param + sizeof(*cipher_param));
@@ -865,6 +870,9 @@ static int qat_alg_aead_enc(struct aead_request *areq)
uint8_t *iv = areq->iv;
int ret, ctr = 0;
+ if (areq->cryptlen % AES_BLOCK_SIZE != 0)
+ return -EINVAL;
+
ret = qat_alg_sgl_to_bufl(ctx->inst, areq->src, areq->dst, qat_req);
if (unlikely(ret))
return ret;
diff --git a/drivers/media/usb/usbtv/usbtv-core.c
b/drivers/media/usb/usbtv/usbtv-core.c
index d8ce7d75ff18..fcbabd2a4114 100644
--- a/drivers/media/usb/usbtv/usbtv-core.c
+++ b/drivers/media/usb/usbtv/usbtv-core.c
@@ -110,7 +110,8 @@ static int usbtv_probe(struct usb_interface *intf,
usbtv_audio_fail:
/* we must not free at this point */
- usb_get_dev(usbtv->udev);
+ v4l2_device_get(&usbtv->v4l2_dev);
+ /* this will undo the v4l2_device_get() */
usbtv_video_free(usbtv);
usbtv_video_fail:
diff --git a/drivers/staging/comedi/drivers/vmk80xx.c
b/drivers/staging/comedi/drivers/vmk80xx.c
index 1800eb3ae017..cdf86284dd04 100644
--- a/drivers/staging/comedi/drivers/vmk80xx.c
+++ b/drivers/staging/comedi/drivers/vmk80xx.c
@@ -676,6 +676,9 @@ static int vmk80xx_find_usb_endpoints(struct comedi_device
*dev)
if (!devpriv->ep_rx || !devpriv->ep_tx)
return -ENODEV;
+ if (!usb_endpoint_maxp(devpriv->ep_rx) ||
!usb_endpoint_maxp(devpriv->ep_tx))
+ return -EINVAL;
+
return 0;
}
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 838123dc390c..c9f979063af1 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1032,6 +1032,11 @@ static const struct usb_device_id id_table_combined[] = {
/* U-Blox devices */
{ USB_DEVICE(UBLOX_VID, UBLOX_C099F9P_ZED_PID) },
{ USB_DEVICE(UBLOX_VID, UBLOX_C099F9P_ODIN_PID) },
+ /* FreeCalypso USB adapters */
+ { USB_DEVICE(FTDI_VID, FTDI_FALCONIA_JTAG_BUF_PID),
+ .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
+ { USB_DEVICE(FTDI_VID, FTDI_FALCONIA_JTAG_UNBUF_PID),
+ .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ } /* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index c33e06752b5f..f3302516a1e4 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -38,6 +38,13 @@
#define FTDI_LUMEL_PD12_PID0x6002
+/*
+ * Custom USB adapters made by Falconia Partners LLC
+ * for FreeCalypso project, ID codes allocated to Falconia by FTDI.
+ */
+#define FTDI_FALCONIA_JTAG_BUF_PID 0x7150
+#define FTDI_FALCONIA_JTAG_UNBUF_PID 0x7151
+
/* Sienna Serial Interface by Secyourit GmbH */
#define FTDI_SIENNA_PID0x8348
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 8cff50ef4fd1..5017d37afe39 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -529,6 +529,7 @@ static void option_instat_callback(struct urb *urb);
/* Cellient products */
#define CELLIENT_VENDOR_ID 0x2692
#define CELLIENT_PRODUCT_MEN2000x9005
+#define CELLIENT_PRODUCT_MPL2000x9025
/* Hyundai Petatel Inc. products */
#define PETATEL_VENDOR_ID 0x1ff4
@@ -1171,6 +1172,8 @@ static const struct usb_device_id option_ids[] = {
.driver_info = NCTRL(2) | RSVD(3) },
Linux 4.9.240
I'm announcing the release of the 4.9.240 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 drivers/crypto/qat/qat_common/qat_algs.c | 10 +++- drivers/media/usb/usbtv/usbtv-core.c |3 - drivers/staging/comedi/drivers/vmk80xx.c |3 + drivers/usb/serial/ftdi_sio.c|5 ++ drivers/usb/serial/ftdi_sio_ids.h|7 +++ drivers/usb/serial/option.c |5 ++ drivers/usb/serial/pl2303.c |1 drivers/usb/serial/pl2303.h |1 fs/reiserfs/inode.c |6 -- fs/reiserfs/xattr.c |7 +++ include/net/bluetooth/hci_core.h | 30 ++--- include/net/bluetooth/l2cap.h|2 net/bluetooth/a2mp.c | 22 + net/bluetooth/hci_conn.c | 17 +++ net/bluetooth/hci_event.c| 70 --- net/bluetooth/l2cap_core.c |7 +-- net/bluetooth/l2cap_sock.c | 14 ++ net/bluetooth/mgmt.c |7 ++- 19 files changed, 158 insertions(+), 61 deletions(-) Alain Michaud (1): Bluetooth: fix kernel oops in store_pending_adv_report Anant Thazhemadam (1): staging: comedi: check validity of wMaxPacketSize of usb endpoints found Dominik Przychodni (1): crypto: qat - check cipher length for aead AES-CBC-HMAC-SHA Greg Kroah-Hartman (1): Linux 4.9.240 Jan Kara (2): reiserfs: Initialize inode keys properly reiserfs: Fix oops during mount Leonid Bloch (1): USB: serial: option: Add Telit FT980-KS composition Luiz Augusto von Dentz (5): Bluetooth: A2MP: Fix not initializing all members Bluetooth: L2CAP: Fix calling sk_filter on non-socket based channel Bluetooth: MGMT: Fix not checking if BT_HS is enabled Bluetooth: Consolidate encryption handling in hci_encrypt_cfm Bluetooth: Disconnect if E0 is used for Level 4 Mychaela N. Falconia (1): USB: serial: ftdi_sio: add support for FreeCalypso JTAG+UART adapters Oliver Neukum (1): media: usbtv: Fix refcounting mixup Patrick Steinhardt (1): Bluetooth: Fix update of connection state in `hci_encrypt_cfm` Scott Chen (1): USB: serial: pl2303: add device-id for HP GC device Wilken Gottwalt (1): USB: serial: option: add Cellient MPL200 card
Re: Linux 4.4.240
diff --git a/Makefile b/Makefile
index 74072b5a958b..69e7cd30e646 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 239
+SUBLEVEL = 240
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/drivers/crypto/qat/qat_common/qat_algs.c
b/drivers/crypto/qat/qat_common/qat_algs.c
index 367b6661ee04..4dda526bd21b 100644
--- a/drivers/crypto/qat/qat_common/qat_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_algs.c
@@ -822,6 +822,11 @@ static int qat_alg_aead_dec(struct aead_request *areq)
struct icp_qat_fw_la_bulk_req *msg;
int digst_size = crypto_aead_authsize(aead_tfm);
int ret, ctr = 0;
+ u32 cipher_len;
+
+ cipher_len = areq->cryptlen - digst_size;
+ if (cipher_len % AES_BLOCK_SIZE != 0)
+ return -EINVAL;
ret = qat_alg_sgl_to_bufl(ctx->inst, areq->src, areq->dst, qat_req);
if (unlikely(ret))
@@ -836,7 +841,7 @@ static int qat_alg_aead_dec(struct aead_request *areq)
qat_req->req.comn_mid.src_data_addr = qat_req->buf.blp;
qat_req->req.comn_mid.dest_data_addr = qat_req->buf.bloutp;
cipher_param = (void *)&qat_req->req.serv_specif_rqpars;
- cipher_param->cipher_length = areq->cryptlen - digst_size;
+ cipher_param->cipher_length = cipher_len;
cipher_param->cipher_offset = areq->assoclen;
memcpy(cipher_param->u.cipher_IV_array, areq->iv, AES_BLOCK_SIZE);
auth_param = (void *)((uint8_t *)cipher_param + sizeof(*cipher_param));
@@ -865,6 +870,9 @@ static int qat_alg_aead_enc(struct aead_request *areq)
uint8_t *iv = areq->iv;
int ret, ctr = 0;
+ if (areq->cryptlen % AES_BLOCK_SIZE != 0)
+ return -EINVAL;
+
ret = qat_alg_sgl_to_bufl(ctx->inst, areq->src, areq->dst, qat_req);
if (unlikely(ret))
return ret;
diff --git a/drivers/media/usb/usbtv/usbtv-core.c
b/drivers/media/usb/usbtv/usbtv-core.c
index a2eb87d74656..8a1440a573a3 100644
--- a/drivers/media/usb/usbtv/usbtv-core.c
+++ b/drivers/media/usb/usbtv/usbtv-core.c
@@ -96,7 +96,8 @@ static int usbtv_probe(struct usb_interface *intf,
usbtv_audio_fail:
/* we must not free at this point */
- usb_get_dev(usbtv->udev);
+ v4l2_device_get(&usbtv->v4l2_dev);
+ /* this will undo the v4l2_device_get() */
usbtv_video_free(usbtv);
usbtv_video_fail:
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 57001f8f727a..6ed2959ce4dc 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1917,13 +1917,13 @@ static int __unregister(struct device *dev, void *null)
*/
void spi_unregister_master(struct spi_master *master)
{
+ device_for_each_child(&master->dev, NULL, __unregister);
+
if (master->queued) {
if (spi_destroy_queue(master))
dev_err(&master->dev, "queue remove failed\n");
}
- device_for_each_child(&master->dev, NULL, __unregister);
-
mutex_lock(&board_lock);
list_del(&master->list);
mutex_unlock(&board_lock);
diff --git a/drivers/staging/comedi/drivers/vmk80xx.c
b/drivers/staging/comedi/drivers/vmk80xx.c
index 95e53cfd76a4..51f9a7800edf 100644
--- a/drivers/staging/comedi/drivers/vmk80xx.c
+++ b/drivers/staging/comedi/drivers/vmk80xx.c
@@ -676,6 +676,9 @@ static int vmk80xx_find_usb_endpoints(struct comedi_device
*dev)
if (!devpriv->ep_rx || !devpriv->ep_tx)
return -ENODEV;
+ if (!usb_endpoint_maxp(devpriv->ep_rx) ||
!usb_endpoint_maxp(devpriv->ep_tx))
+ return -EINVAL;
+
return 0;
}
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 25e76d4c1505..5b42b8d760cb 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1032,6 +1032,11 @@ static const struct usb_device_id id_table_combined[] = {
/* U-Blox devices */
{ USB_DEVICE(UBLOX_VID, UBLOX_C099F9P_ZED_PID) },
{ USB_DEVICE(UBLOX_VID, UBLOX_C099F9P_ODIN_PID) },
+ /* FreeCalypso USB adapters */
+ { USB_DEVICE(FTDI_VID, FTDI_FALCONIA_JTAG_BUF_PID),
+ .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
+ { USB_DEVICE(FTDI_VID, FTDI_FALCONIA_JTAG_UNBUF_PID),
+ .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ } /* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index c33e06752b5f..f3302516a1e4 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -38,6 +38,13 @@
#define FTDI_LUMEL_PD12_PID0x6002
+/*
+ * Custom USB adapters made by Falconia Partners LLC
+ * for FreeCalypso project, ID codes allocated to Falconia by FTDI.
+ */
+#define FTDI_FALCONIA_JTAG_BUF_PID 0x7150
+#define FTDI_FALCONIA_JTAG_UNBUF_PID 0x7151
+
/* Sienna Serial Interface by Secyourit GmbH */
#define FTDI_SIENNA_PID0x8348
Linux 5.8.16
I'm announcing the release of the 5.8.16 kernel. All users of the 5.8 kernel series must upgrade. The updated 5.8.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.8.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 +- drivers/crypto/bcm/cipher.c | 15 ++- drivers/crypto/qat/qat_common/qat_algs.c | 10 +- drivers/media/usb/usbtv/usbtv-core.c |3 ++- drivers/staging/comedi/drivers/vmk80xx.c |3 +++ drivers/usb/serial/ftdi_sio.c|5 + drivers/usb/serial/ftdi_sio_ids.h|7 +++ drivers/usb/serial/option.c |5 + drivers/usb/serial/pl2303.c |1 + drivers/usb/serial/pl2303.h |1 + fs/reiserfs/inode.c |6 +- fs/reiserfs/xattr.c |7 +++ include/net/bluetooth/hci_core.h | 10 ++ include/net/bluetooth/l2cap.h|2 ++ net/bluetooth/a2mp.c | 22 +- net/bluetooth/hci_conn.c | 17 + net/bluetooth/hci_event.c| 20 net/bluetooth/l2cap_core.c |7 --- net/bluetooth/l2cap_sock.c | 14 ++ net/bluetooth/mgmt.c |7 ++- 20 files changed, 134 insertions(+), 30 deletions(-) Anant Thazhemadam (1): staging: comedi: check validity of wMaxPacketSize of usb endpoints found Dominik Przychodni (1): crypto: qat - check cipher length for aead AES-CBC-HMAC-SHA Greg Kroah-Hartman (1): Linux 5.8.16 Herbert Xu (1): crypto: bcm - Verify GCM/CCM key length in setkey Jan Kara (2): reiserfs: Initialize inode keys properly reiserfs: Fix oops during mount Leonid Bloch (1): USB: serial: option: Add Telit FT980-KS composition Luiz Augusto von Dentz (4): Bluetooth: A2MP: Fix not initializing all members Bluetooth: L2CAP: Fix calling sk_filter on non-socket based channel Bluetooth: MGMT: Fix not checking if BT_HS is enabled Bluetooth: Disconnect if E0 is used for Level 4 Mychaela N. Falconia (1): USB: serial: ftdi_sio: add support for FreeCalypso JTAG+UART adapters Oliver Neukum (1): media: usbtv: Fix refcounting mixup Scott Chen (1): USB: serial: pl2303: add device-id for HP GC device Wilken Gottwalt (1): USB: serial: option: add Cellient MPL200 card
Re: Linux 5.4.72
diff --git a/Makefile b/Makefile
index f342e64c8c1d..8db75cc76ed1 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 5
PATCHLEVEL = 4
-SUBLEVEL = 71
+SUBLEVEL = 72
EXTRAVERSION =
NAME = Kleptomaniac Octopus
diff --git a/arch/arm/boot/compressed/Makefile
b/arch/arm/boot/compressed/Makefile
index 1483966dcf23..6da67789ac22 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -121,7 +121,7 @@ ccflags-y := -fpic $(call cc-option,-mno-single-pic-base,)
-fno-builtin \
asflags-y := -DZIMAGE
# Supply kernel BSS size to the decompressor via a linker symbol.
-KBSS_SZ = $(shell echo $$(($$($(CROSS_COMPILE)nm $(obj)/../../../../vmlinux | \
+KBSS_SZ = $(shell echo $$(($$($(NM) $(obj)/../../../../vmlinux | \
sed -n -e 's/^\([^ ]*\) [AB] __bss_start$$/-0x\1/p' \
-e 's/^\([^ ]*\) [AB] __bss_stop$$/+0x\1/p') )) )
LDFLAGS_vmlinux = --defsym _kernel_bss_size=$(KBSS_SZ)
@@ -165,7 +165,7 @@ $(obj)/bswapsdi2.S:
$(srctree)/arch/$(SRCARCH)/lib/bswapsdi2.S
# The .data section is already discarded by the linker script so no need
# to bother about it here.
check_for_bad_syms = \
-bad_syms=$$($(CROSS_COMPILE)nm $@ | sed -n 's/^.\{8\} [bc] \(.*\)/\1/p') && \
+bad_syms=$$($(NM) $@ | sed -n 's/^.\{8\} [bc] \(.*\)/\1/p') && \
[ -z "$$bad_syms" ] || \
( echo "following symbols must have non local/private scope:" >&2; \
echo "$$bad_syms" >&2; false )
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 5d361e4e3405..ef1ac4d127da 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -48,7 +48,7 @@ acpi-y+= acpi_pnp.o
acpi-$(CONFIG_ARM_AMBA)+= acpi_amba.o
acpi-y += power.o
acpi-y += event.o
-acpi-$(CONFIG_ACPI_REDUCED_HARDWARE_ONLY) += evged.o
+acpi-y += evged.o
acpi-y += sysfs.o
acpi-y += property.o
acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index f85356a48e7e..ec4b5033013e 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -2937,7 +2937,6 @@ static int aead_gcm_ccm_setkey(struct crypto_aead *cipher,
ctx->enckeylen = keylen;
ctx->authkeylen = 0;
- memcpy(ctx->enckey, key, ctx->enckeylen);
switch (ctx->enckeylen) {
case AES_KEYSIZE_128:
@@ -2953,6 +2952,8 @@ static int aead_gcm_ccm_setkey(struct crypto_aead *cipher,
goto badkey;
}
+ memcpy(ctx->enckey, key, ctx->enckeylen);
+
flow_log(" enckeylen:%u authkeylen:%u\n", ctx->enckeylen,
ctx->authkeylen);
flow_dump(" enc: ", ctx->enckey, ctx->enckeylen);
@@ -3013,6 +3014,10 @@ static int aead_gcm_esp_setkey(struct crypto_aead
*cipher,
struct iproc_ctx_s *ctx = crypto_aead_ctx(cipher);
flow_log("%s\n", __func__);
+
+ if (keylen < GCM_ESP_SALT_SIZE)
+ return -EINVAL;
+
ctx->salt_len = GCM_ESP_SALT_SIZE;
ctx->salt_offset = GCM_ESP_SALT_OFFSET;
memcpy(ctx->salt, key + keylen - GCM_ESP_SALT_SIZE, GCM_ESP_SALT_SIZE);
@@ -3041,6 +3046,10 @@ static int rfc4543_gcm_esp_setkey(struct crypto_aead
*cipher,
struct iproc_ctx_s *ctx = crypto_aead_ctx(cipher);
flow_log("%s\n", __func__);
+
+ if (keylen < GCM_ESP_SALT_SIZE)
+ return -EINVAL;
+
ctx->salt_len = GCM_ESP_SALT_SIZE;
ctx->salt_offset = GCM_ESP_SALT_OFFSET;
memcpy(ctx->salt, key + keylen - GCM_ESP_SALT_SIZE, GCM_ESP_SALT_SIZE);
@@ -3070,6 +3079,10 @@ static int aead_ccm_esp_setkey(struct crypto_aead
*cipher,
struct iproc_ctx_s *ctx = crypto_aead_ctx(cipher);
flow_log("%s\n", __func__);
+
+ if (keylen < CCM_ESP_SALT_SIZE)
+ return -EINVAL;
+
ctx->salt_len = CCM_ESP_SALT_SIZE;
ctx->salt_offset = CCM_ESP_SALT_OFFSET;
memcpy(ctx->salt, key + keylen - CCM_ESP_SALT_SIZE, CCM_ESP_SALT_SIZE);
diff --git a/drivers/crypto/qat/qat_common/qat_algs.c
b/drivers/crypto/qat/qat_common/qat_algs.c
index b50eb55f8f57..0d67cf5ede51 100644
--- a/drivers/crypto/qat/qat_common/qat_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_algs.c
@@ -873,6 +873,11 @@ static int qat_alg_aead_dec(struct aead_request *areq)
struct icp_qat_fw_la_bulk_req *msg;
int digst_size = crypto_aead_authsize(aead_tfm);
int ret, ctr = 0;
+ u32 cipher_len;
+
+ cipher_len = areq->cryptlen - digst_size;
+ if (cipher_len % AES_BLOCK_SIZE != 0)
+ return -EINVAL;
ret = qat_alg_sgl_to_bufl(ctx->inst, areq->src, areq->dst, qat_req);
if (unlikely(ret))
@@ -887,7 +892,7 @@ static int qat_alg_aead_dec(struct aead_request *areq)
qat_req->req.comn_mid.src_data_addr = qat_req->buf.blp;
qat_req->req.c
Linux 4.19.152
I'm announcing the release of the 4.19.152 kernel. All users of the 4.19 kernel series must upgrade. The updated 4.19.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.19.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 - arch/arm/boot/compressed/Makefile|4 +- arch/arm/vdso/Makefile | 22 +- drivers/crypto/bcm/cipher.c | 15 + drivers/crypto/qat/qat_common/qat_algs.c | 10 +- drivers/media/usb/usbtv/usbtv-core.c |3 + drivers/net/ethernet/marvell/mvmdio.c| 22 ++ drivers/staging/comedi/drivers/vmk80xx.c |3 + drivers/usb/serial/ftdi_sio.c|5 +++ drivers/usb/serial/ftdi_sio_ids.h|7 drivers/usb/serial/option.c |5 +++ drivers/usb/serial/pl2303.c |1 drivers/usb/serial/pl2303.h |1 fs/reiserfs/inode.c |6 --- fs/reiserfs/xattr.c |7 include/net/bluetooth/hci_core.h | 30 +++ include/net/bluetooth/l2cap.h|2 + net/bluetooth/a2mp.c | 22 +- net/bluetooth/hci_conn.c | 17 ++ net/bluetooth/hci_event.c| 48 +++ net/bluetooth/l2cap_core.c |7 ++-- net/bluetooth/l2cap_sock.c | 14 + net/bluetooth/mgmt.c |7 +++- tools/perf/util/cs-etm.c |3 + tools/perf/util/cs-etm.h |3 - 25 files changed, 185 insertions(+), 81 deletions(-) Anant Thazhemadam (1): staging: comedi: check validity of wMaxPacketSize of usb endpoints found Arnaud Patard (1): drivers/net/ethernet/marvell/mvmdio.c: Fix non OF case Dmitry Golovin (1): ARM: 8939/1: kbuild: use correct nm executable Dominik Przychodni (1): crypto: qat - check cipher length for aead AES-CBC-HMAC-SHA Greg Kroah-Hartman (1): Linux 4.19.152 Herbert Xu (1): crypto: bcm - Verify GCM/CCM key length in setkey Jan Kara (2): reiserfs: Initialize inode keys properly reiserfs: Fix oops during mount Jason A. Donenfeld (1): ARM: 8867/1: vdso: pass --be8 to linker if necessary Leo Yan (1): perf cs-etm: Move definition of 'traceid_list' global variable from header file Leonid Bloch (1): USB: serial: option: Add Telit FT980-KS composition Luiz Augusto von Dentz (5): Bluetooth: A2MP: Fix not initializing all members Bluetooth: L2CAP: Fix calling sk_filter on non-socket based channel Bluetooth: MGMT: Fix not checking if BT_HS is enabled Bluetooth: Consolidate encryption handling in hci_encrypt_cfm Bluetooth: Disconnect if E0 is used for Level 4 Masahiro Yamada (1): ARM: 8858/1: vdso: use $(LD) instead of $(CC) to link VDSO Mychaela N. Falconia (1): USB: serial: ftdi_sio: add support for FreeCalypso JTAG+UART adapters Oliver Neukum (1): media: usbtv: Fix refcounting mixup Patrick Steinhardt (1): Bluetooth: Fix update of connection state in `hci_encrypt_cfm` Scott Chen (1): USB: serial: pl2303: add device-id for HP GC device Wilken Gottwalt (1): USB: serial: option: add Cellient MPL200 card
Re: Linux 5.9.1
Linux 5.9.1
I'm announcing the release of the 5.9.1 kernel. All users of the 5.9 kernel series must upgrade. The updated 5.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.9.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 - drivers/crypto/bcm/cipher.c | 15 +++- drivers/crypto/qat/qat_common/qat_algs.c | 10 - drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c |9 +++- drivers/media/usb/usbtv/usbtv-core.c |3 + drivers/staging/comedi/drivers/vmk80xx.c |3 + drivers/tty/vt/vt_ioctl.c| 57 +-- drivers/usb/serial/ftdi_sio.c|5 ++ drivers/usb/serial/ftdi_sio_ids.h|7 +++ drivers/usb/serial/option.c |5 ++ drivers/usb/serial/pl2303.c |1 drivers/usb/serial/pl2303.h |1 fs/reiserfs/inode.c |6 --- fs/reiserfs/xattr.c |7 +++ include/net/bluetooth/l2cap.h|2 + net/bluetooth/a2mp.c | 22 +++ net/bluetooth/l2cap_core.c |7 ++- net/bluetooth/l2cap_sock.c | 14 +++ net/bluetooth/mgmt.c |7 +++ 19 files changed, 119 insertions(+), 64 deletions(-) Alex Deucher (1): Revert "drm/amdgpu: Fix NULL dereference in dpm sysfs handlers" Anant Thazhemadam (1): staging: comedi: check validity of wMaxPacketSize of usb endpoints found Dominik Przychodni (1): crypto: qat - check cipher length for aead AES-CBC-HMAC-SHA Greg Kroah-Hartman (1): Linux 5.9.1 Herbert Xu (1): crypto: bcm - Verify GCM/CCM key length in setkey Jan Kara (2): reiserfs: Initialize inode keys properly reiserfs: Fix oops during mount Leonid Bloch (1): USB: serial: option: Add Telit FT980-KS composition Luiz Augusto von Dentz (3): Bluetooth: A2MP: Fix not initializing all members Bluetooth: L2CAP: Fix calling sk_filter on non-socket based channel Bluetooth: MGMT: Fix not checking if BT_HS is enabled Mychaela N. Falconia (1): USB: serial: ftdi_sio: add support for FreeCalypso JTAG+UART adapters Oliver Neukum (1): media: usbtv: Fix refcounting mixup Scott Chen (1): USB: serial: pl2303: add device-id for HP GC device Tetsuo Handa (1): vt_ioctl: make VT_RESIZEX behave like VT_RESIZE Wilken Gottwalt (1): USB: serial: option: add Cellient MPL200 card
Re: Linux 5.8.16
diff --git a/Makefile b/Makefile
index 6c787cd1cb51..a4622ef65436 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 5
PATCHLEVEL = 8
-SUBLEVEL = 15
+SUBLEVEL = 16
EXTRAVERSION =
NAME = Kleptomaniac Octopus
diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index a353217a0d33..530c7d9437dd 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -2930,7 +2930,6 @@ static int aead_gcm_ccm_setkey(struct crypto_aead *cipher,
ctx->enckeylen = keylen;
ctx->authkeylen = 0;
- memcpy(ctx->enckey, key, ctx->enckeylen);
switch (ctx->enckeylen) {
case AES_KEYSIZE_128:
@@ -2946,6 +2945,8 @@ static int aead_gcm_ccm_setkey(struct crypto_aead *cipher,
goto badkey;
}
+ memcpy(ctx->enckey, key, ctx->enckeylen);
+
flow_log(" enckeylen:%u authkeylen:%u\n", ctx->enckeylen,
ctx->authkeylen);
flow_dump(" enc: ", ctx->enckey, ctx->enckeylen);
@@ -3000,6 +3001,10 @@ static int aead_gcm_esp_setkey(struct crypto_aead
*cipher,
struct iproc_ctx_s *ctx = crypto_aead_ctx(cipher);
flow_log("%s\n", __func__);
+
+ if (keylen < GCM_ESP_SALT_SIZE)
+ return -EINVAL;
+
ctx->salt_len = GCM_ESP_SALT_SIZE;
ctx->salt_offset = GCM_ESP_SALT_OFFSET;
memcpy(ctx->salt, key + keylen - GCM_ESP_SALT_SIZE, GCM_ESP_SALT_SIZE);
@@ -3028,6 +3033,10 @@ static int rfc4543_gcm_esp_setkey(struct crypto_aead
*cipher,
struct iproc_ctx_s *ctx = crypto_aead_ctx(cipher);
flow_log("%s\n", __func__);
+
+ if (keylen < GCM_ESP_SALT_SIZE)
+ return -EINVAL;
+
ctx->salt_len = GCM_ESP_SALT_SIZE;
ctx->salt_offset = GCM_ESP_SALT_OFFSET;
memcpy(ctx->salt, key + keylen - GCM_ESP_SALT_SIZE, GCM_ESP_SALT_SIZE);
@@ -3057,6 +3066,10 @@ static int aead_ccm_esp_setkey(struct crypto_aead
*cipher,
struct iproc_ctx_s *ctx = crypto_aead_ctx(cipher);
flow_log("%s\n", __func__);
+
+ if (keylen < CCM_ESP_SALT_SIZE)
+ return -EINVAL;
+
ctx->salt_len = CCM_ESP_SALT_SIZE;
ctx->salt_offset = CCM_ESP_SALT_OFFSET;
memcpy(ctx->salt, key + keylen - CCM_ESP_SALT_SIZE, CCM_ESP_SALT_SIZE);
diff --git a/drivers/crypto/qat/qat_common/qat_algs.c
b/drivers/crypto/qat/qat_common/qat_algs.c
index 1b050391c0c9..02dadcb8852f 100644
--- a/drivers/crypto/qat/qat_common/qat_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_algs.c
@@ -871,6 +871,11 @@ static int qat_alg_aead_dec(struct aead_request *areq)
struct icp_qat_fw_la_bulk_req *msg;
int digst_size = crypto_aead_authsize(aead_tfm);
int ret, ctr = 0;
+ u32 cipher_len;
+
+ cipher_len = areq->cryptlen - digst_size;
+ if (cipher_len % AES_BLOCK_SIZE != 0)
+ return -EINVAL;
ret = qat_alg_sgl_to_bufl(ctx->inst, areq->src, areq->dst, qat_req);
if (unlikely(ret))
@@ -885,7 +890,7 @@ static int qat_alg_aead_dec(struct aead_request *areq)
qat_req->req.comn_mid.src_data_addr = qat_req->buf.blp;
qat_req->req.comn_mid.dest_data_addr = qat_req->buf.bloutp;
cipher_param = (void *)&qat_req->req.serv_specif_rqpars;
- cipher_param->cipher_length = areq->cryptlen - digst_size;
+ cipher_param->cipher_length = cipher_len;
cipher_param->cipher_offset = areq->assoclen;
memcpy(cipher_param->u.cipher_IV_array, areq->iv, AES_BLOCK_SIZE);
auth_param = (void *)((uint8_t *)cipher_param + sizeof(*cipher_param));
@@ -914,6 +919,9 @@ static int qat_alg_aead_enc(struct aead_request *areq)
uint8_t *iv = areq->iv;
int ret, ctr = 0;
+ if (areq->cryptlen % AES_BLOCK_SIZE != 0)
+ return -EINVAL;
+
ret = qat_alg_sgl_to_bufl(ctx->inst, areq->src, areq->dst, qat_req);
if (unlikely(ret))
return ret;
diff --git a/drivers/media/usb/usbtv/usbtv-core.c
b/drivers/media/usb/usbtv/usbtv-core.c
index ee9c656d121f..2308c0b4f5e7 100644
--- a/drivers/media/usb/usbtv/usbtv-core.c
+++ b/drivers/media/usb/usbtv/usbtv-core.c
@@ -113,7 +113,8 @@ static int usbtv_probe(struct usb_interface *intf,
usbtv_audio_fail:
/* we must not free at this point */
- usb_get_dev(usbtv->udev);
+ v4l2_device_get(&usbtv->v4l2_dev);
+ /* this will undo the v4l2_device_get() */
usbtv_video_free(usbtv);
usbtv_video_fail:
diff --git a/drivers/staging/comedi/drivers/vmk80xx.c
b/drivers/staging/comedi/drivers/vmk80xx.c
index 65dc6c51037e..7956abcbae22 100644
--- a/drivers/staging/comedi/drivers/vmk80xx.c
+++ b/drivers/staging/comedi/drivers/vmk80xx.c
@@ -667,6 +667,9 @@ static int vmk80xx_find_usb_endpoints(struct comedi_device
*dev)
if (!devpriv->ep_rx || !devpriv->ep_tx)
return -ENODEV;
+ if (!usb_endpoint_maxp(devpriv->ep_rx) ||
!usb_endpoint_maxp(devpriv->ep_tx))
+
Re: Linux 4.19.152
diff --git a/Makefile b/Makefile
index f2c9db9b4015..aa79ce7bfdc7 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 19
-SUBLEVEL = 151
+SUBLEVEL = 152
EXTRAVERSION =
NAME = "People's Front"
diff --git a/arch/arm/boot/compressed/Makefile
b/arch/arm/boot/compressed/Makefile
index 1f5a5ffe7fcf..c762004572ef 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -120,7 +120,7 @@ ccflags-y := -fpic $(call cc-option,-mno-single-pic-base,)
-fno-builtin -I$(obj)
asflags-y := -DZIMAGE
# Supply kernel BSS size to the decompressor via a linker symbol.
-KBSS_SZ = $(shell echo $$(($$($(CROSS_COMPILE)nm $(obj)/../../../../vmlinux | \
+KBSS_SZ = $(shell echo $$(($$($(NM) $(obj)/../../../../vmlinux | \
sed -n -e 's/^\([^ ]*\) [AB] __bss_start$$/-0x\1/p' \
-e 's/^\([^ ]*\) [AB] __bss_stop$$/+0x\1/p') )) )
LDFLAGS_vmlinux = --defsym _kernel_bss_size=$(KBSS_SZ)
@@ -166,7 +166,7 @@ $(obj)/bswapsdi2.S:
$(srctree)/arch/$(SRCARCH)/lib/bswapsdi2.S
# The .data section is already discarded by the linker script so no need
# to bother about it here.
check_for_bad_syms = \
-bad_syms=$$($(CROSS_COMPILE)nm $@ | sed -n 's/^.\{8\} [bc] \(.*\)/\1/p') && \
+bad_syms=$$($(NM) $@ | sed -n 's/^.\{8\} [bc] \(.*\)/\1/p') && \
[ -z "$$bad_syms" ] || \
( echo "following symbols must have non local/private scope:" >&2; \
echo "$$bad_syms" >&2; rm -f $@; false )
diff --git a/arch/arm/vdso/Makefile b/arch/arm/vdso/Makefile
index f4efff9d3afb..1f5ec9741e6d 100644
--- a/arch/arm/vdso/Makefile
+++ b/arch/arm/vdso/Makefile
@@ -10,12 +10,13 @@ obj-vdso := $(addprefix $(obj)/, $(obj-vdso))
ccflags-y := -fPIC -fno-common -fno-builtin -fno-stack-protector
ccflags-y += -DDISABLE_BRANCH_PROFILING
-VDSO_LDFLAGS := -Wl,-Bsymbolic -Wl,--no-undefined -Wl,-soname=linux-vdso.so.1
-VDSO_LDFLAGS += -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096
-VDSO_LDFLAGS += -nostdlib -shared
-VDSO_LDFLAGS += $(call cc-ldoption, -Wl$(comma)--hash-style=sysv)
-VDSO_LDFLAGS += $(call cc-ldoption, -Wl$(comma)--build-id)
-VDSO_LDFLAGS += $(call cc-ldoption, -fuse-ld=bfd)
+ldflags-$(CONFIG_CPU_ENDIAN_BE8) := --be8
+ldflags-y := -Bsymbolic --no-undefined -soname=linux-vdso.so.1 \
+ -z max-page-size=4096 -z common-page-size=4096 \
+ -nostdlib -shared $(ldflags-y) \
+ $(call ld-option, --hash-style=sysv) \
+ $(call ld-option, --build-id) \
+ -T
obj-$(CONFIG_VDSO) += vdso.o
extra-$(CONFIG_VDSO) += vdso.lds
@@ -37,8 +38,8 @@ KCOV_INSTRUMENT := n
$(obj)/vdso.o : $(obj)/vdso.so
# Link rule for the .so file
-$(obj)/vdso.so.raw: $(src)/vdso.lds $(obj-vdso) FORCE
- $(call if_changed,vdsold)
+$(obj)/vdso.so.raw: $(obj)/vdso.lds $(obj-vdso) FORCE
+ $(call if_changed,ld)
$(obj)/vdso.so.dbg: $(obj)/vdso.so.raw $(obj)/vdsomunge FORCE
$(call if_changed,vdsomunge)
@@ -48,11 +49,6 @@ $(obj)/%.so: OBJCOPYFLAGS := -S
$(obj)/%.so: $(obj)/%.so.dbg FORCE
$(call if_changed,objcopy)
-# Actual build commands
-quiet_cmd_vdsold = VDSO$@
- cmd_vdsold = $(CC) $(c_flags) $(VDSO_LDFLAGS) \
- -Wl,-T $(filter %.lds,$^) $(filter %.o,$^) -o $@
-
quiet_cmd_vdsomunge = MUNGE $@
cmd_vdsomunge = $(objtree)/$(obj)/vdsomunge $< $@
diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index 0b1fc5664b1d..c2736274ad63 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -2980,7 +2980,6 @@ static int aead_gcm_ccm_setkey(struct crypto_aead *cipher,
ctx->enckeylen = keylen;
ctx->authkeylen = 0;
- memcpy(ctx->enckey, key, ctx->enckeylen);
switch (ctx->enckeylen) {
case AES_KEYSIZE_128:
@@ -2996,6 +2995,8 @@ static int aead_gcm_ccm_setkey(struct crypto_aead *cipher,
goto badkey;
}
+ memcpy(ctx->enckey, key, ctx->enckeylen);
+
flow_log(" enckeylen:%u authkeylen:%u\n", ctx->enckeylen,
ctx->authkeylen);
flow_dump(" enc: ", ctx->enckey, ctx->enckeylen);
@@ -3056,6 +3057,10 @@ static int aead_gcm_esp_setkey(struct crypto_aead
*cipher,
struct iproc_ctx_s *ctx = crypto_aead_ctx(cipher);
flow_log("%s\n", __func__);
+
+ if (keylen < GCM_ESP_SALT_SIZE)
+ return -EINVAL;
+
ctx->salt_len = GCM_ESP_SALT_SIZE;
ctx->salt_offset = GCM_ESP_SALT_OFFSET;
memcpy(ctx->salt, key + keylen - GCM_ESP_SALT_SIZE, GCM_ESP_SALT_SIZE);
@@ -3084,6 +3089,10 @@ static int rfc4543_gcm_esp_setkey(struct crypto_aead
*cipher,
struct iproc_ctx_s *ctx = crypto_aead_ctx(cipher);
flow_log("%s\n", __func__);
+
+ if (keylen < GCM_ESP_SALT_SIZE)
+ return -EINVAL;
+
ctx->salt_len = GCM_ESP_SALT_SIZE;
ctx->salt_offset = GCM_ESP_SALT_OFFSET;
memcpy(ctx->salt, key + keylen - GCM_ESP_SALT_SIZE, GCM_ESP_SALT_SI
Linux 5.4.72
I'm announcing the release of the 5.4.72 kernel. All users of the 5.4 kernel series must upgrade. The updated 5.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.4.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 - arch/arm/boot/compressed/Makefile|4 +- drivers/acpi/Makefile|2 - drivers/crypto/bcm/cipher.c | 15 - drivers/crypto/qat/qat_common/qat_algs.c | 10 +- drivers/media/usb/usbtv/usbtv-core.c |3 + drivers/staging/comedi/drivers/vmk80xx.c |3 + drivers/usb/serial/ftdi_sio.c|5 +++ drivers/usb/serial/ftdi_sio_ids.h|7 drivers/usb/serial/option.c |5 +++ drivers/usb/serial/pl2303.c |1 drivers/usb/serial/pl2303.h |1 drivers/xen/events/events_base.c | 29 + fs/btrfs/block-group.c | 38 --- fs/btrfs/space-info.c| 50 --- fs/btrfs/space-info.h|3 + fs/reiserfs/inode.c |6 --- fs/reiserfs/xattr.c |7 include/net/bluetooth/hci_core.h | 30 ++ include/net/bluetooth/l2cap.h|2 + net/bluetooth/a2mp.c | 22 + net/bluetooth/hci_conn.c | 17 ++ net/bluetooth/hci_event.c| 48 ++--- net/bluetooth/l2cap_core.c |7 ++-- net/bluetooth/l2cap_sock.c | 14 net/bluetooth/mgmt.c |7 +++- tools/perf/util/cs-etm.c |3 + tools/perf/util/cs-etm.h |3 - 28 files changed, 231 insertions(+), 113 deletions(-) Anant Thazhemadam (1): staging: comedi: check validity of wMaxPacketSize of usb endpoints found Arjan van de Ven (1): ACPI: Always build evged in Dmitry Golovin (1): ARM: 8939/1: kbuild: use correct nm executable Dominik Przychodni (1): crypto: qat - check cipher length for aead AES-CBC-HMAC-SHA Greg Kroah-Hartman (1): Linux 5.4.72 Herbert Xu (1): crypto: bcm - Verify GCM/CCM key length in setkey Jan Kara (2): reiserfs: Initialize inode keys properly reiserfs: Fix oops during mount Josef Bacik (2): btrfs: don't pass system_chunk into can_overcommit btrfs: take overcommit into account in inc_block_group_ro Juergen Gross (1): xen/events: don't use chip_data for legacy IRQs Leo Yan (1): perf cs-etm: Move definition of 'traceid_list' global variable from header file Leonid Bloch (1): USB: serial: option: Add Telit FT980-KS composition Luiz Augusto von Dentz (5): Bluetooth: A2MP: Fix not initializing all members Bluetooth: L2CAP: Fix calling sk_filter on non-socket based channel Bluetooth: MGMT: Fix not checking if BT_HS is enabled Bluetooth: Consolidate encryption handling in hci_encrypt_cfm Bluetooth: Disconnect if E0 is used for Level 4 Mychaela N. Falconia (1): USB: serial: ftdi_sio: add support for FreeCalypso JTAG+UART adapters Oliver Neukum (1): media: usbtv: Fix refcounting mixup Patrick Steinhardt (1): Bluetooth: Fix update of connection state in `hci_encrypt_cfm` Scott Chen (1): USB: serial: pl2303: add device-id for HP GC device Wilken Gottwalt (1): USB: serial: option: add Cellient MPL200 card
Re: Linux 4.14.202
diff --git a/Makefile b/Makefile
index e3e2d7fa7232..0284c231bdea 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 14
-SUBLEVEL = 201
+SUBLEVEL = 202
EXTRAVERSION =
NAME = Petit Gorille
diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index 279e907590e9..af6119b3b6b7 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -2981,7 +2981,6 @@ static int aead_gcm_ccm_setkey(struct crypto_aead *cipher,
ctx->enckeylen = keylen;
ctx->authkeylen = 0;
- memcpy(ctx->enckey, key, ctx->enckeylen);
switch (ctx->enckeylen) {
case AES_KEYSIZE_128:
@@ -2997,6 +2996,8 @@ static int aead_gcm_ccm_setkey(struct crypto_aead *cipher,
goto badkey;
}
+ memcpy(ctx->enckey, key, ctx->enckeylen);
+
flow_log(" enckeylen:%u authkeylen:%u\n", ctx->enckeylen,
ctx->authkeylen);
flow_dump(" enc: ", ctx->enckey, ctx->enckeylen);
@@ -3057,6 +3058,10 @@ static int aead_gcm_esp_setkey(struct crypto_aead
*cipher,
struct iproc_ctx_s *ctx = crypto_aead_ctx(cipher);
flow_log("%s\n", __func__);
+
+ if (keylen < GCM_ESP_SALT_SIZE)
+ return -EINVAL;
+
ctx->salt_len = GCM_ESP_SALT_SIZE;
ctx->salt_offset = GCM_ESP_SALT_OFFSET;
memcpy(ctx->salt, key + keylen - GCM_ESP_SALT_SIZE, GCM_ESP_SALT_SIZE);
@@ -3085,6 +3090,10 @@ static int rfc4543_gcm_esp_setkey(struct crypto_aead
*cipher,
struct iproc_ctx_s *ctx = crypto_aead_ctx(cipher);
flow_log("%s\n", __func__);
+
+ if (keylen < GCM_ESP_SALT_SIZE)
+ return -EINVAL;
+
ctx->salt_len = GCM_ESP_SALT_SIZE;
ctx->salt_offset = GCM_ESP_SALT_OFFSET;
memcpy(ctx->salt, key + keylen - GCM_ESP_SALT_SIZE, GCM_ESP_SALT_SIZE);
@@ -3114,6 +3123,10 @@ static int aead_ccm_esp_setkey(struct crypto_aead
*cipher,
struct iproc_ctx_s *ctx = crypto_aead_ctx(cipher);
flow_log("%s\n", __func__);
+
+ if (keylen < CCM_ESP_SALT_SIZE)
+ return -EINVAL;
+
ctx->salt_len = CCM_ESP_SALT_SIZE;
ctx->salt_offset = CCM_ESP_SALT_OFFSET;
memcpy(ctx->salt, key + keylen - CCM_ESP_SALT_SIZE, CCM_ESP_SALT_SIZE);
diff --git a/drivers/crypto/qat/qat_common/qat_algs.c
b/drivers/crypto/qat/qat_common/qat_algs.c
index baffae817259..bb875245644f 100644
--- a/drivers/crypto/qat/qat_common/qat_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_algs.c
@@ -825,6 +825,11 @@ static int qat_alg_aead_dec(struct aead_request *areq)
struct icp_qat_fw_la_bulk_req *msg;
int digst_size = crypto_aead_authsize(aead_tfm);
int ret, ctr = 0;
+ u32 cipher_len;
+
+ cipher_len = areq->cryptlen - digst_size;
+ if (cipher_len % AES_BLOCK_SIZE != 0)
+ return -EINVAL;
ret = qat_alg_sgl_to_bufl(ctx->inst, areq->src, areq->dst, qat_req);
if (unlikely(ret))
@@ -839,7 +844,7 @@ static int qat_alg_aead_dec(struct aead_request *areq)
qat_req->req.comn_mid.src_data_addr = qat_req->buf.blp;
qat_req->req.comn_mid.dest_data_addr = qat_req->buf.bloutp;
cipher_param = (void *)&qat_req->req.serv_specif_rqpars;
- cipher_param->cipher_length = areq->cryptlen - digst_size;
+ cipher_param->cipher_length = cipher_len;
cipher_param->cipher_offset = areq->assoclen;
memcpy(cipher_param->u.cipher_IV_array, areq->iv, AES_BLOCK_SIZE);
auth_param = (void *)((uint8_t *)cipher_param + sizeof(*cipher_param));
@@ -868,6 +873,9 @@ static int qat_alg_aead_enc(struct aead_request *areq)
uint8_t *iv = areq->iv;
int ret, ctr = 0;
+ if (areq->cryptlen % AES_BLOCK_SIZE != 0)
+ return -EINVAL;
+
ret = qat_alg_sgl_to_bufl(ctx->inst, areq->src, areq->dst, qat_req);
if (unlikely(ret))
return ret;
diff --git a/drivers/media/usb/usbtv/usbtv-core.c
b/drivers/media/usb/usbtv/usbtv-core.c
index 50a61143898b..bf0e3908cdc4 100644
--- a/drivers/media/usb/usbtv/usbtv-core.c
+++ b/drivers/media/usb/usbtv/usbtv-core.c
@@ -113,7 +113,8 @@ static int usbtv_probe(struct usb_interface *intf,
usbtv_audio_fail:
/* we must not free at this point */
- usb_get_dev(usbtv->udev);
+ v4l2_device_get(&usbtv->v4l2_dev);
+ /* this will undo the v4l2_device_get() */
usbtv_video_free(usbtv);
usbtv_video_fail:
diff --git a/drivers/net/ethernet/marvell/mvmdio.c
b/drivers/net/ethernet/marvell/mvmdio.c
index b6ff143c9cff..024688c90aa9 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -319,15 +319,25 @@ static int orion_mdio_probe(struct platform_device *pdev)
init_waitqueue_head(&dev->smi_busy_wait);
- for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
- dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
- if (PTR_ERR(dev->
[PATCH] ring-buffer: Update the description for ring_buffer_wait
The function changed at some point, but the description was not updated. Signed-off-by: Qiujun Huang --- kernel/trace/ring_buffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index b2c6f2546d69..598c388d6436 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -793,7 +793,7 @@ static void rb_wake_up_waiters(struct irq_work *work) * ring_buffer_wait - wait for input to the ring buffer * @buffer: buffer to wait on * @cpu: the cpu buffer to wait on - * @full: wait until a full page is available, if @cpu != RING_BUFFER_ALL_CPUS + * @full: wait until the percentage of pages are available, if @cpu != RING_BUFFER_ALL_CPUS * * If @cpu == RING_BUFFER_ALL_CPUS then the task will wake up as soon * as data is added to any of the @buffer's cpu buffers. Otherwise -- 2.17.1
autofs: use __kernel_write() for the autofs pipe writing causes regression in -next was Re: 5.9.0-next-20201015: autofs oops in update-binfmts
Hi! > > I'm getting this during boot: 32-bit thinkpad x60. > > This is very odd. > > The change in next is essentially a revert of a change, maybe I'm > missing something and the revert isn't quite a revert. Although > there was one difference. > > I'll check for other revert differences too. > > Are you in a position to check a kernel without the 5.9 change > if I send you a patch? I think I can revert changes myself. pavel@amd:/data/l/linux-next-32$ git show 90fb702791bf99b959006972e8ee7bb4609f441b | git apply -R pavel@amd:/data/l/linux-next-32$ pavel@amd:/data/l/linux-next-32$ git show d7a8c5c78d37500346c25cc8887ed2c3fda8ed4d | git apply -R ...and it boots up without a warning. Let me re-apply Linus' patch: pavel@amd:/data/l/linux-next-32$ git show 90fb702791bf99b959006972e8ee7bb4609f441b | git apply pavel@amd:/data/l/linux-next-32$ ...and the oops is back: Bad Linus! [9.889419] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: errors=remount-ro [ 10.042221] BUG: kernel NULL pointer dereference, address: [ 10.045702] #PF: supervisor read access in kernel mode [ 10.048142] #PF: error_code(0x) - not-present page [ 10.052172] *pdpt = 031ea001 *pde = [ 10.052172] Oops: [#1] PREEMPT SMP PTI [ 10.052172] CPU: 1 PID: 2764 Comm: update-binfmts Not tainted 5.9.0-next-20201015+ #154 [ 10.065205] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 03/31/2011 [ 10.065205] EIP: __kernel_write+0xd4/0x230 [ 10.065205] Code: 89 d6 64 8b 15 b4 77 4c c5 8b 8a 38 0b 00 00 31 d2 85 c9 74 04 0f b7 51 30 66 89 75 e8 8b 75 ac 8d 4d b0 89 45 e4 66 89 55 ea <8b> 06 8b 56 04 57 6a 01 89 45 d4 8d 45 b8 89 55 d8 ba 01 00 00 00 [ 10.065205] EAX: 0002 EBX: c192d640 ECX: c2b89ad0 EDX: [ 10.065205] ESI: EDI: 012c EBP: c2b89b20 ESP: c2b89acc [ 10.065205] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010282 [ 10.065205] CR0: 80050033 CR2: CR3: 03414000 CR4: 06b0 [ 10.065205] Call Trace: [ 10.065205] ? __mutex_unlock_slowpath+0x2b/0x2c0 [ 10.065205] ? dma_direct_map_sg+0x13a/0x320 [ 10.065205] autofs_notify_daemon+0x14d/0x2b0 [ 10.065205] autofs_wait+0x4cd/0x770 [ 10.065205] ? autofs_d_automount+0xd6/0x1e0 [ 10.065205] autofs_mount_wait+0x43/0xe0 [ 10.065205] autofs_d_automount+0xdf/0x1e0 [ 10.065205] __traverse_mounts+0x85/0x200 [ 10.065205] step_into+0x368/0x620 [ 10.065205] ? proc_setup_thread_self+0x110/0x110 [ 10.065205] walk_component+0x58/0x190 [ 10.065205] link_path_walk.part.0+0x245/0x360 [ 10.065205] path_lookupat.isra.0+0x31/0x130 [ 10.065205] filename_lookup+0x8d/0x130 [ 10.065205] ? cache_alloc_debugcheck_after+0x151/0x180 [ 10.065205] ? getname_flags+0x1f/0x160 [ 10.065205] ? kmem_cache_alloc+0x75/0x100 [ 10.065205] user_path_at_empty+0x25/0x30 [ 10.065205] vfs_statx+0x63/0x100 [ 10.065205] ? _raw_spin_unlock+0x18/0x30 [ 10.065205] ? replace_page_cache_page+0x160/0x160 [ 10.065205] __do_sys_stat64+0x36/0x60 [ 10.065205] ? exit_to_user_mode_prepare+0x35/0xe0 [ 10.065205] ? irqentry_exit_to_user_mode+0x8/0x20 [ 10.065205] ? irqentry_exit+0x55/0x70 [ 10.065205] ? exc_page_fault+0x228/0x3c0 [ 10.065205] __ia32_sys_stat64+0xd/0x10 [ 10.065205] do_int80_syscall_32+0x2c/0x40 [ 10.065205] entry_INT80_32+0x111/0x111 [ 10.065205] EIP: 0xb7f03092 [ 10.065205] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30 00 00 00 e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00 00 00 00 00 00 cd 80 8d b4 26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d b4 26 00 [ 10.065205] EAX: ffda EBX: 004fa490 ECX: bfaf7e6c EDX: 004f9348 [ 10.065205] ESI: EDI: 004fa490 EBP: bfaf7e6c ESP: bfaf7e44 [ 10.065205] DS: 007b ES: 007b FS: GS: 0033 SS: 007b EFLAGS: 0296 [ 10.065205] Modules linked in: [ 10.065205] CR2: [ 10.073216] ---[ end trace 13a709ba02b08366 ]--- [ 10.073221] EIP: __kernel_write+0xd4/0x230 [ 10.073224] Code: 89 d6 64 8b 15 b4 77 4c c5 8b 8a 38 0b 00 00 31 d2 85 c9 74 04 0f b7 51 30 66 89 75 e8 8b 75 ac 8d 4d b0 89 45 e4 66 89 55 ea <8b> 06 8b 56 04 57 6a 01 89 45 d4 8d 45 b8 89 55 d8 ba 01 00 00 00 [ 10.073226] EAX: 0002 EBX: c192d640 ECX: c2b89ad0 EDX: [ 10.073228] ESI: EDI: 012c EBP: c2b89b20 ESP: c2b89acc [ 10.073230] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010282 [ 10.073232] CR0: 80050033 CR2: b7e10020 CR3: 03414000 CR4: 06b0 [ 10.453818] systemd-journald[2512]: Received request to flush runtime journal from PID 1 [ 24.752167] iwl3945 :03:00.0: loaded firmware version 15.32.2.9 > And we should check if that difference to what was originally > there is the source of the problem, so probably two things to > follow up on, reverting that small difference first would be > the way to go. > > Are you able to reliably reproduce it? Looks so, yes. Best regards,
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.10-1 tag
Linus Torvalds writes: > On Thu, Oct 15, 2020 at 8:24 PM Michael Ellerman wrote: >> >> Just two minor conflicts I'm aware of. The only slight subtlety is the >> conflict >> in kasan_init() where "int ret" needs to move out of the for_each_mem_range() >> and up to the function scope. > > Well, there was also a conflict for the dependencies of OCXL. Yep, it was so trivial I didn't think it was worth calling out. > I resolved that by ruthlessly simplifying the dependency: > > - depends on PPC_POWERNV && PCI && EEH && HOTPLUG_PCI_POWERNV > - depends on PPC_POWERNV && PCI && EEH && PPC_XIVE_NATIVE > ++ depends on HOTPLUG_PCI_POWERNV > > because all the other dependencies seem to be pointless. > > HOTPLUG_PCI_POWERNV already has a > > depends on PPC_POWERNV && EEH > > so there's no point in repeating those. And PPC_POWERNV selects FORCE_PCI, which takes care of the dependency on PCI. > And PPC_XIVE_NATIVE is selected by PPC_POWERNV, so if PPC_POWERNV, we > know PPC_XIVE_NATIVE is set. > > Maybe I missed something strange, so I'm just letting you know so you > can blame me if I broke something. No, that looks good to me. Thanks. cheers
Re: [PATCH next] iommu: intel: don't dereference iommu_device if IOMMU_API is not built
On Wed, 2020-10-14 at 14:57 +0200, Joerg Roedel wrote: > On Wed, Oct 14, 2020 at 03:25:08PM +0800, Lu Baolu wrote: > > I suppose Joerg will pick this up. I guess you don't need to resend it > > unless Joerg asks you to do. > > Yes, will pick this up soon, no need to re-send. Please could it, and the commit it fixes, both go to stable@ smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH net 1/4] ptp: ptp_idt82p33: update to support adjphase
Hi!
> +static int idt82p33_adjwritephase(struct ptp_clock_info *ptp, s32
> +offsetNs) {
adj_write_phase?
> + struct idt82p33_channel *channel =
> + container_of(ptp, struct idt82p33_channel, caps);
> + struct idt82p33 *idt82p33 = channel->idt82p33;
> + s64 offsetInFs;
> + s64 offsetRegVal;
> + u8 val[4] = {0};
> + int err;
> +
> + offsetInFs = (s64)(-offsetNs) * 100;
> +
> + if (offsetInFs > WRITE_PHASE_OFFSET_LIMIT)
> + offsetInFs = WRITE_PHASE_OFFSET_LIMIT;
> + else if (offsetInFs < -WRITE_PHASE_OFFSET_LIMIT)
> + offsetInFs = -WRITE_PHASE_OFFSET_LIMIT;
I'm sure we have macro for this.
> + /* Convert from phaseOffsetInFs to register value */
> + offsetRegVal = ((offsetInFs * 1000) / IDT_T0DPLL_PHASE_RESOL);
> +
> + val[0] = offsetRegVal & 0xFF;
> + val[1] = (offsetRegVal >> 8) & 0xFF;
> + val[2] = (offsetRegVal >> 16) & 0xFF;
> + val[3] = (offsetRegVal >> 24) & 0x1F;
> + val[3] |= PH_OFFSET_EN;
ThisIsReally far away from usual coding style.
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
signature.asc
Description: Digital signature
Re: [PATCH] fs: btrfs: Fix incorrect printf qualifier
On Wed, Oct 14, 2020 at 10:24 AM Pujin Shi wrote:
>
> This patch addresses a compile warning:
> fs/btrfs/extent-tree.c: In function '__btrfs_free_extent':
> fs/btrfs/extent-tree.c:3187:4: warning: format '%lu' expects argument of type
> 'long unsigned int', but argument 8 has type 'unsigned int' [-Wformat=]
>
> Fixes: 3b7b6ffa4f8f ("btrfs: extent-tree: kill BUG_ON() in
> __btrfs_free_extent()")
Btw, that commit id does not exist in Linus' tree, should be 1c2a07f598d5 [1].
> Signed-off-by: Pujin Shi
Other than that it looks good,
Reviewed-by: Filipe Manana
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1c2a07f598d526e39acbf1837b8d521fc0dab9c5
> ---
> fs/btrfs/extent-tree.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 3b21fee13e77..5fd60b13f4f8 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -3185,7 +3185,7 @@ static int __btrfs_free_extent(struct
> btrfs_trans_handle *trans,
> struct btrfs_tree_block_info *bi;
> if (item_size < sizeof(*ei) + sizeof(*bi)) {
> btrfs_crit(info,
> -"invalid extent item size for key (%llu, %u, %llu) owner %llu, has %u expect
> >= %lu",
> +"invalid extent item size for key (%llu, %u, %llu) owner %llu, has %u expect
> >= %zu",
>key.objectid, key.type, key.offset,
>owner_objectid, item_size,
>sizeof(*ei) + sizeof(*bi));
> --
> 2.18.1
>
--
Filipe David Manana,
“Whether you think you can, or you think you can't — you're right.”
Re: [PATCH v2 0/3] drm/panel: mantix panel reset fixes
Hi Guido. On Sat, Oct 17, 2020 at 11:13:07AM +0200, Guido Günther wrote: > Hi Sam, > On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sam Ravnborg wrote: > > Hi Guido. > > On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido Günther wrote: > [..snip..] > > > > > > Changes from v1: > > > - As per review comments by Fabio Estevam > > > > > > https://lore.kernel.org/dri-devel/CAOMZO5B5ECcConvKej=rcaf8wvoxgq7nuzkj-ad0asaozuq...@mail.gmail.com/ > > >- Fix typo in commit messages > > > - As per review comments by Rob Herring > > >https://lore.kernel.org/dri-devel/20200929174624.GA832332@bogus/ > > >- Don't use an array of reset lines > > > > > > Guido Günther (3): > > > drm/panel: mantix: Don't dereference NULL mode > > > drm/panel: mantix: Fix panel reset > > > dt-binding: display: Require two resets on mantix panel > > > > All applied to drm-misc-next and pushed out. > > And then I remembered you had commit right - sigh. > > Thanks! Is there any special care needed to get that into 5.10? The > driver landed there in 72967d5616d3f0c714f8eb6c4e258179a9031c45. As the patches was applied to drm-misc-next the easiet path would be to cherry-pick them and apply to drm-misc-fixes. dim has cherry-pick support - try to use it rahter than doing it by hand. When you apply to drm-misc-fixes include a Fixes: tag so the tooling will pick the patches automagically. In hindsight the patches should have carried a Fixes: tag from a start and should have been applied to drm-misc-fixes from a start too. I have done something like above once or twice but anyway reach out if you have questions. Or ask at #dri-devel. Sam
Re: UBSAN: array-index-out-of-bounds in alg_bind
On Sat, Oct 17, 2020 at 5:49 AM Kees Cook wrote:
>
> On Fri, Oct 16, 2020 at 01:12:24AM -0700, syzbot wrote:
> > dashboard link: https://syzkaller.appspot.com/bug?extid=92ead4eb8e26a26d465e
> > [...]
> > Reported-by: syzbot+92ead4eb8e26a26d4...@syzkaller.appspotmail.com
> > [...]
> > UBSAN: array-index-out-of-bounds in crypto/af_alg.c:166:2
> > index 91 is out of range for type '__u8 [64]'
>
> This seems to be an "as intended", if very odd. false positive (the actual
> memory area is backed by the on-stack _K_SS_MAXSIZE-sized sockaddr_storage
> "address" variable in __sys_bind. But yes, af_alg's salg_name member
> size here doesn't make sense.
As Vegard noted elsewhere, compilers can start making assumptions
based on absence of UB and compile code in surprising ways as the
result leading to very serious and very real bugs.
One example would be a compiler generating jump table for common sizes
during PGO and leaving size > 64 as wild jump.
Another example would be a compiler assuming that copy size <= 64.
Then if there is another copy into a 64-byte buffer with a proper size
check, the compiler can now drop that size check (since it now knows
size <= 64) and we get real stack smash (for a copy that does have a
proper size check before!).
And we do want compilers to be that smart today. Because of all levels
of abstractions/macros/inlining we actually have lots of
redundant/nonsensical code in the end after all inlining and
expansions, and we do want compilers to infer things, remove redundant
checks, etc so that we can have both nice abstract source code and
efficient machine code at the same time.
> The origin appears to be that 3f69cc60768b
> ("crypto: af_alg - Allow arbitrarily long algorithm names") intentionally
> didn't extend the kernel structure (which is actually just using the UAPI
> structure). I don't see a reason the UAPI couldn't have been extended:
> it's a sockaddr implementation, so the size is always passed in as part
> of the existing API.
>
> At the very least the kernel needs to switch to using a correctly-sized
> structure: I expected UBSAN_BOUNDS to be enabled globally by default at
> some point in the future (with the minimal runtime -- the
> instrumentation is tiny and catches real issues).
>
> Reproduction:
>
> struct sockaddr_alg sa = {
> .salg_family = AF_ALG,
> .salg_type = "skcipher",
> .salg_name = "cbc(aes)"
> };
> fd = socket(AF_ALG, SOCK_SEQPACKET, 0);
> bind(fd, (void *)&sa, sizeof(sa));
>
> Replace "sizeof(sa)" with x where 64
> --
> Kees Cook
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/202010162042.7C51549A16%40keescook.
Re: UBSAN: array-index-out-of-bounds in alg_bind
On Sat, Oct 17, 2020 at 12:50 PM Dmitry Vyukov wrote: > On Sat, Oct 17, 2020 at 5:49 AM Kees Cook wrote: > > On Fri, Oct 16, 2020 at 01:12:24AM -0700, syzbot wrote: > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=92ead4eb8e26a26d465e > > > [...] > > > Reported-by: syzbot+92ead4eb8e26a26d4...@syzkaller.appspotmail.com > > > [...] > > > UBSAN: array-index-out-of-bounds in crypto/af_alg.c:166:2 > > > index 91 is out of range for type '__u8 [64]' > > > > This seems to be an "as intended", if very odd. false positive (the actual > > memory area is backed by the on-stack _K_SS_MAXSIZE-sized sockaddr_storage > > "address" variable in __sys_bind. But yes, af_alg's salg_name member > > size here doesn't make sense. > > As Vegard noted elsewhere, compilers can start making assumptions > based on absence of UB and compile code in surprising ways as the > result leading to very serious and very real bugs. > > One example would be a compiler generating jump table for common sizes > during PGO and leaving size > 64 as wild jump. > > Another example would be a compiler assuming that copy size <= 64. > Then if there is another copy into a 64-byte buffer with a proper size > check, the compiler can now drop that size check (since it now knows > size <= 64) and we get real stack smash (for a copy that does have a > proper size check before!). FWIW, the kernel currently still has a bunch of places that use C89-style length-1 arrays (which were in the past used to work around C89's lack of proper flexible arrays). Gustavo A. R. Silva has a bunch of patches pending to change those places now, but those are not marked for stable backporting; so in all currently released kernels, we'll probably keep having length-1 arrays at the ends of C structs that are used as if they were flexible arrays. (Unless someone makes the case that these patches are not just cleanups but actually fix some sort of real bug, and therefore need to be backported.) The code in this example looks just like one of those C89-style length-1 arrays to me (except that the length isn't 1). Of course I do agree that this should be cleaned up, and that having bogus array lengths in the source code is a bad idea. > And we do want compilers to be that smart today. Because of all levels > of abstractions/macros/inlining we actually have lots of > redundant/nonsensical code in the end after all inlining and > expansions, and we do want compilers to infer things, remove redundant > checks, etc so that we can have both nice abstract source code and > efficient machine code at the same time. I guess that kinda leads to the question: Do we just need to fix the kernel code here (which is comparatively easy), or do you think that this is a sufficiently big problem that we need to go and somehow change the actual UAPI headers here (e.g. by deprecating the existing UAPI struct and making a new one with a different name)?
Re: [PATCH 4.19 00/21] 4.19.152-rc1 review
Hi, On Sat, Oct 17, 2020 at 11:49:43AM +0200, Greg Kroah-Hartman wrote: > On Sat, Oct 17, 2020 at 11:41:53AM +0200, Salvatore Bonaccorso wrote: > > hi, > > > > On Fri, Oct 16, 2020 at 12:01:51PM -0700, Guenter Roeck wrote: > > > On Fri, Oct 16, 2020 at 11:07:19AM +0200, Greg Kroah-Hartman wrote: > > > > This is the start of the stable review cycle for the 4.19.152 release. > > > > There are 21 patches in this series, all will be posted as a response > > > > to this one. If anyone has any issues with these being applied, please > > > > let me know. > > > > > > > > Responses should be made by Sun, 18 Oct 2020 09:04:25 +. > > > > Anything received after that time might be too late. > > > > > > > > > > Build results: > > > total: 155 pass: 153 fail: 2 > > > Failed builds: > > > i386:tools/perf > > > x86_64:tools/perf > > > > I'm seeing the tools/perf failure as well: > > > > gcc > > -Wp,-MD,/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/util/intel-pt-decoder/.intel-pt-insn-decoder.o.d > > > > -Wp,-MT,/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.o > > -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall > > -Wdate-time -D_FORTIFY_SOURCE=2 -I/home/build/linux-4.19.152/tools/perf > > -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf -isystem > > /home/build/linux-4.19.152/debian/build/build-tools/include > > -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security > > -Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes > > -Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked > > -Wredundant-decls -Wshadow -Wstrict-prototypes -Wswitch-default > > -Wswitch-enum -Wundef -Wwrite-strings -Wformat -Wstrict-aliasing=3 > > -DHAVE_ARCH_X86_64_SUPPORT > > -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/arch/x86/include/generated > > -DHAVE_SYSCALL_TABLE_SUPPORT -DHAVE_PERF_REGS_SUPPORT > > -DHAVE_ARCH_REGS_QUERY_REGISTER_OFFSET -O6 -fno-omit-frame-pointer -ggdb3 > > -funwind-tables -Wall -Wextra -std=gnu99 -fstack-protector-all > > -D_FORTIFY_SOURCE=2 -I/home/build/linux-4.19.152/tools/perf/util/include > > -I/home/build/linux-4.19.152/tools/perf/arch/x86/include > > -I/home/build/linux-4.19.152/tools/include/uapi > > -I/home/build/linux-4.19.152/tools/include/ > > -I/home/build/linux-4.19.152/tools/arch/x86/include/uapi > > -I/home/build/linux-4.19.152/tools/arch/x86/include/ > > -I/home/build/linux-4.19.152/tools/arch/x86/ > > -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf//util > > -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/ > > -I/home/build/linux-4.19.152/tools/perf/util > > -I/home/build/linux-4.19.152/tools/perf > > -I/home/build/linux-4.19.152/tools/lib/ -D_LARGEFILE64_SOURCE > > -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DHAVE_SYNC_COMPARE_AND_SWAP_SUPPORT > > -DHAVE_PTHREAD_ATTR_SETAFFINITY_NP -DHAVE_PTHREAD_BARRIER > > -DHAVE_DWARF_GETLOCATIONS_SUPPORT -DHAVE_GLIBC_SUPPORT > > -DHAVE_SCHED_GETCPU_SUPPORT -DHAVE_SETNS_SUPPORT -DHAVE_CSTRACE_SUPPORT > > -DHAVE_LIBELF_SUPPORT -DHAVE_LIBELF_MMAP_SUPPORT > > -DHAVE_ELF_GETPHDRNUM_SUPPORT -DHAVE_GELF_GETNOTE_SUPPORT > > -DHAVE_ELF_GETSHDRSTRNDX_SUPPORT -DHAVE_DWARF_SUPPORT -DHAVE_LIBBPF_SUPPORT > > -DHAVE_BPF_PROLOGUE -DHAVE_JITDUMP -DHAVE_DWARF_UNWIND_SUPPORT > > -DNO_LIBUNWIND_DEBUG_FRAME -DHAVE_LIBUNWIND_SUPPORT -I/usr/include/slang > > -DHAVE_SLANG_SUPPORT -DHAVE_LIBPERL_SUPPORT -DHAVE_TIMERFD_SUPPORT > > -DHAVE_LIBPYTHON_SUPPORT -DHAVE_CPLUS_DEMANGLE_SUPPORT -DHAVE_ZLIB_SUPPORT > > -DHAVE_LZMA_SUPPORT -DHAVE_BACKTRACE_SUPPORT -DHAVE_LIBNUMA_SUPPORT > > -DHAVE_KVM_STAT_SUPPORT -DHAVE_PERF_READ_VDSO32 -DHAVE_PERF_READ_VDSOX32 > > -DHAVE_LIBBABELTRACE_SUPPORT -DHAVE_AUXTRACE_SUPPORT > > -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/ > > -D"BUILD_STR(s)=#s" > > -I/home/build/linux-4.19.152/debian/build/build-tools/tools/perf/util/intel-pt-decoder > > -c -o > > /home/build/linux-4.19.152/debian/build/build-tools/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.o > > util/intel-pt-decoder/intel-pt-insn-decoder.c > > util/cs-etm-decoder/cs-etm-decoder.c: In function > > 'cs_etm_decoder__buffer_packet': > > util/cs-etm-decoder/cs-etm-decoder.c:287:24: error: 'traceid_list' > > undeclared (first use in this function); did you mean 'trace_event'? > > inode = intlist__find(traceid_list, trace_chan_id); > > ^~~~ > > trace_event > > util/cs-etm-decoder/cs-etm-decoder.c:287:24: note: each undeclared > > identifier is reported only once for each function it appears in > > make[8]: *** [/home/build/linux-4.19.152/tools/build/Makefile.build:97: > > /home/build/linux-4.19.152/debian/build/build-tools/tools/perf/util/cs-etm-decoder/cs-etm-decoder.o] > > Error 1 > > make[8]: Leaving directory '/home/build/linux-4.19.152/tools
WARNING in md_ioctl
Hi,
I looked into the warning "WARNING in md_ioctl" found by Syzkaller.
(https://syzkaller.appspot.com/bug?id=fbf9eaea2e65bfcabb4e2750c3ab0892867edea1)
I suspect that it is caused by a race between two concurrenct ioctl()s as
belows.
CPU1 (md_ioctl()) CPU2 (md_ioctl())
-- --
set_bit(MD_CLOSING, &mddev->flags);
did_set_md_closing = true;
WARN_ON_ONCE(test_bit(MD_CLOSING,
&mddev->flags));
if(did_set_md_closing)
clear_bit(MD_CLOSING, &mddev->flags);
If the above is correct, this warning is introduced
in the commit 065e519e("md: MD_CLOSING needs to be cleared after called
md_set_readonly or do_md_stop").
Could you please take a look into this?
Best regards,
Dae R. Jeong
Re: [RFC PATCH 0/2] iommu: Avoid unnecessary PRI queue flushes
Hi Jean On Fri, Oct 16, 2020 at 09:59:23AM +0200, Jean-Philippe Brucker wrote: > On Thu, Oct 15, 2020 at 11:22:11AM -0700, Raj, Ashok wrote: > > Hi Jean > > > > + Baolu who is looking into this. > > > > > > On Thu, Oct 15, 2020 at 11:00:27AM +0200, Jean-Philippe Brucker wrote: > > > Add a parameter to iommu_sva_unbind_device() that tells the IOMMU driver > > > whether the PRI queue needs flushing. When looking at the PCIe spec > > > again I noticed that most of the time the SMMUv3 driver doesn't actually > > > need to flush the PRI queue. Does this make sense for Intel VT-d as well > > > or did I overlook something? > > > > > > Before calling iommu_sva_unbind_device(), device drivers must stop the > > > device from using the PASID. For PCIe devices, that consists of > > > completing any pending DMA, and completing any pending page request > > > unless the device uses Stop Markers. So unless the device uses Stop > > > Markers, we don't need to flush the PRI queue. For SMMUv3, stopping DMA > > > means completing all stall events, so we never need to flush the event > > > queue. > > > > I don't think this is true. Baolu is working on an enhancement to this, > > I'll quickly summarize this below: > > > > Stop markers are weird, I'm not certain there is any device today that > > sends STOP markers. Even if they did, markers don't have a required > > response, they are fire and forget from the device pov. > > Definitely agree with this, and I hope none will implement stop marker. > For devices that *don't* use a stop marker, the PCIe spec says (10.4.1.2): > > To stop [using a PASID] without using a Stop Marker Message, the > function shall: > 1. Stop queueing new Page Request Messages for this PASID. The device driver would need to tell stop sending any new PR's. > 2. Finish transmitting any multi-page Page Request Messages for this > PASID (i.e. send the Page Request Message with the L bit Set). > 3. Wait for PRG Response Messages associated any outstanding Page > Request Messages for the PASID. > > So they have to flush their PR themselves. And since the device driver > completes this sequence before calling unbind(), then there shouldn't be > any oustanding PR for the PASID, and unbind() doesn't need to flush, > right? I can see how the device can complete #2,3 above. But the device driver isn't the one managing page-responses right. So in order for the device to know the above sequence is complete, it would need to get some assist from IOMMU driver? How does the driver know that everything host received has been responded back to device? > > > I'm not sure about other IOMMU's how they behave, When there is no space in > > the PRQ, IOMMU auto-responds to the device. This puts the device in a > > while (1) loop. The fake successful response will let the device do a ATS > > lookup, and that would fail forcing the device to do another PRQ. > > But in the sequence above, step 1 should ensure that the device will not > send another PR for any successful response coming back at step 3. True, but there could be some page-request in flight on its way to the IOMMU. By draining and getting that round trip back to IOMMU we gaurantee things in flight are flushed to PRQ after that Drain completes. > > So I agree with the below if we suspect there could be pending PR, but > given that pending PR are a stop marker thing and we don't know any device > using stop markers, I wondered why I bothered implementing PRIq flush at > all for SMMUv3, hence this RFC. > Cheers, Ashok
42d8c91e for drivers/net/phy/realtek.c causing loss on Banana Pi
Hi, in kernel 5.9, my Banana Pi test systems suffers from catastrophic packet loss on the Ethernet that makes the machine nearly unusable. Reverting bbc4d71d63549bcd003a430de18a72a742d8c91e fixes the issue for me. Please investigate the breakage caused by this commit. I am prepared to help with testing and would appreciate a fix even in Greg's stable releases. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [PATCH 4.19 00/21] 4.19.152-rc1 review
On Fri, Oct 16, 2020 at 12:33:54PM +0200, Pavel Machek wrote: > Hi! > > > This is the start of the stable review cycle for the 4.19.152 release. > > There are 21 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > First post! :-). > > No problems revealed by CIP testing. > > https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.19.y > > Tested-by: Pavel Machek (CIP) Thanks for testing 2 of these and letting me know. greg k-h
Re: [PATCH 5.9 00/15] 5.9.1-rc1 review
On Fri, Oct 16, 2020 at 05:45:56PM +0100, Jon Hunter wrote: > > On 16/10/2020 10:08, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.9.1 release. > > There are 15 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun, 18 Oct 2020 09:04:25 +. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.1-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.9.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > There is one test failure (new warning) for Tegra194 but this is a known > issue for v5.9 and is fixed by Viresh's change [0]. Maybe we can pull > into stable once it is merged to the mainline? Please let me know if this hits Linus's tree and I don't pick it up. > > That said everything else looks good ... > > Test results for stable-v5.9: > 15 builds:15 pass, 0 fail > 26 boots: 26 pass, 0 fail > 61 tests: 60 pass, 1 fail > > Linux version:5.9.1-rc1-g1cbc5f2d0eac > Boards tested:tegra124-jetson-tk1, tegra186-p2771-, > tegra194-p2972-, tegra20-ventana, > tegra210-p2371-2180, tegra210-p3450-, > tegra30-cardhu-a04 > > Tested-by: Jon Hunter Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 5.9 00/15] 5.9.1-rc1 review
On Sat, Oct 17, 2020 at 12:33:06AM +0530, Naresh Kamboju wrote: > On Fri, 16 Oct 2020 at 14:42, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 5.9.1 release. > > There are 15 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun, 18 Oct 2020 09:04:25 +. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.1-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.9.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Results from Linaro’s test farm. > No regressions on arm64, arm, x86_64, and i386. > > Tested-by: Linux Kernel Functional Testing Thanks for testing all of these so quickly and letting me know. greg k-h
Re: [PATCH 5.9 00/15] 5.9.1-rc1 review
On Fri, Oct 16, 2020 at 02:09:42PM -0700, Guenter Roeck wrote: > On Fri, Oct 16, 2020 at 11:08:02AM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.9.1 release. > > There are 15 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun, 18 Oct 2020 09:04:25 +. > > Anything received after that time might be too late. > > > > Build results: > total: 154 pass: 153 fail: 1 > Failed builds: > mips:allmodconfig > Qemu test results: > total: 430 pass: 430 fail: 0 > > The mips build problem is inherited from mainline and still seen there. > > ERROR: modpost: "fw_arg3" [drivers/mtd/parsers/bcm63xxpart.ko] undefined! > > A fix is (finally) queued in -next. Good! > Tested-by: Guenter Roeck Great, thanks for testing them all and letting me know. greg k-h
[PATCH V2] Only add -fno-var-tracking-assignments workaround for old GCC versions.
Some old GCC versions between 4.5.0 and 4.9.1 might miscompile code with -fvar-tracking-assingments (which is enabled by default with -g -O2). commit 2062afb4f added -fno-var-tracking-assignments unconditionally to work around this. But newer versions of GCC no longer have this bug, so only add it for versions of GCC before 5.0. This allows various tools such as a perf probe or gdb debuggers or systemtap to resolve variable locations using dwarf locations in more code. Changes in V2: - Update commit message explaining purpose. - Explicitly mention GCC version in comment. - Wrap workaround in ifdef CONFIG_CC_IS_GCC Signed-off-by: Mark Wielaard Acked-by: Ian Rogers Reviewed-by: Andi Kleen Cc: linux-toolcha...@vger.kernel.org Cc: Nick Desaulniers Cc: Segher Boessenkool Cc: Florian Weimer Cc: Sedat Dilek --- Makefile | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 51540b291738..964754b4cedf 100644 --- a/Makefile +++ b/Makefile @@ -813,7 +813,11 @@ KBUILD_CFLAGS += -ftrivial-auto-var-init=zero KBUILD_CFLAGS += -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang endif -DEBUG_CFLAGS := $(call cc-option, -fno-var-tracking-assignments) +# Workaround for GCC versions < 5.0 +# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 +ifdef CONFIG_CC_IS_GCC +DEBUG_CFLAGS := $(call cc-ifversion, -lt, 0500, $(call cc-option, -fno-var-tracking-assignments)) +endif ifdef CONFIG_DEBUG_INFO ifdef CONFIG_DEBUG_INFO_SPLIT -- 2.18.4
Re: [PATCH v2 1/2] ARM: dts: rk3188: correct interrupt flags
Hi, Am Freitag, 2. Oktober 2020, 18:11:28 CEST schrieb Krzysztof Kozlowski: > On Thu, Sep 17, 2020 at 08:52:10PM +0200, Krzysztof Kozlowski wrote: > > GPIO_ACTIVE_x flags are not correct in the context of interrupt flags. > > These are simple defines so they could be used in DTS but they will not > > have the same meaning: > > 1. GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE > > 2. GPIO_ACTIVE_LOW = 1 = IRQ_TYPE_EDGE_RISING > > > > Correct the interrupt flags without affecting the code: > > ACTIVE_HIGH => IRQ_TYPE_NONE > > > > Signed-off-by: Krzysztof Kozlowski > > > > --- > > > > Not tested on HW. > > > > Changes since v1: > > 1. Correct title > > --- > > arch/arm/boot/dts/rk3188-bqedison2qc.dts | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > Hi, > > Any comments/review/testing from Heiko or other Rockchip folks? Shall I > cc here someone? I'm actually wondering about this ... I somehow remember writing a response, but don't see it in my history - so it might have gotten lost before I actually sent it. I think the biggest issue I have is that none of that is tested on any hardware and looking at other brcm wifi drivers in the kernel, the interrupt polarity seems to be all over the place, some set it high, some low and I even have seen edge triggers. As all changes are in regard to (copied) brcm wifi node, it would be really interesting to actually know what trigger is the right one. I've Cc'ed Jagan who I think has worked on an affected board, maybe he can check which trigger is correct. Heiko
[PATCH v2] fs: btrfs: Fix incorrect printf qualifier
This patch addresses a compile warning:
fs/btrfs/extent-tree.c: In function '__btrfs_free_extent':
fs/btrfs/extent-tree.c:3187:4: warning: format '%lu' expects argument of type
'long unsigned int', but argument 8 has type 'unsigned int' [-Wformat=]
Fixes: 1c2a07f598d5 ("btrfs: extent-tree: kill BUG_ON() in
__btrfs_free_extent()")
Signed-off-by: Pujin Shi
---
fs/btrfs/extent-tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 3b21fee13e77..5fd60b13f4f8 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3185,7 +3185,7 @@ static int __btrfs_free_extent(struct btrfs_trans_handle
*trans,
struct btrfs_tree_block_info *bi;
if (item_size < sizeof(*ei) + sizeof(*bi)) {
btrfs_crit(info,
-"invalid extent item size for key (%llu, %u, %llu) owner %llu, has %u expect
>= %lu",
+"invalid extent item size for key (%llu, %u, %llu) owner %llu, has %u expect
>= %zu",
key.objectid, key.type, key.offset,
owner_objectid, item_size,
sizeof(*ei) + sizeof(*bi));
--
2.18.1
Re: [PATCH] vgacon: fix a UAF in do_update_region()
Hi Yang. Can you please resend and include Greg in the recipient list. Greg is maintainer of the console subsystem these days. Sam On Mon, Jul 13, 2020 at 11:04:45AM +, Yang Yingliang wrote: > I got a UAF report in do_update_region() when I doing fuzz test. > > [ 51.161905] BUG: KASAN: use-after-free in do_update_region+0x579/0x600 > [ 51.161918] Read of size 2 at addr 88800010 by task test/295 > > [ 51.161957] CPU: 2 PID: 295 Comm: test Not tainted 5.7.0+ #975 > [ 51.161969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 > [ 51.161976] Call Trace: > [ 51.162001] dump_stack+0xc6/0x11e > [ 51.162019] ? do_update_region+0x579/0x600 > [ 51.162047] print_address_description.constprop.6+0x1a/0x220 > [ 51.162083] ? vprintk_func+0x66/0xed > [ 51.162100] ? do_update_region+0x579/0x600 > [ 51.162112] ? do_update_region+0x579/0x600 > [ 51.162128] kasan_report.cold.9+0x37/0x7c > [ 51.162151] ? do_update_region+0x579/0x600 > [ 51.162173] do_update_region+0x579/0x600 > [ 51.162207] ? con_get_trans_old+0x230/0x230 > [ 51.162229] ? retint_kernel+0x10/0x10 > [ 51.162278] csi_J+0x557/0xa00 > [ 51.162307] do_con_trol+0x49af/0x5cc0 > [ 51.162330] ? lock_downgrade+0x720/0x720 > [ 51.162347] ? reset_palette+0x1b0/0x1b0 > [ 51.162369] ? lockdep_hardirqs_on_prepare+0x379/0x540 > [ 51.162393] ? notifier_call_chain+0x11b/0x160 > [ 51.162438] do_con_write.part.24+0xb0a/0x1a30 > [ 51.162501] ? do_con_trol+0x5cc0/0x5cc0 > [ 51.162522] ? console_unlock+0x7b8/0xb00 > [ 51.162555] ? __mutex_unlock_slowpath+0xd4/0x670 > [ 51.162574] ? this_tty+0xe0/0xe0 > [ 51.162589] ? console_unlock+0x559/0xb00 > [ 51.162605] ? wait_for_completion+0x260/0x260 > [ 51.162638] con_write+0x31/0xb0 > [ 51.162658] n_tty_write+0x4fa/0xd40 > [ 51.162710] ? n_tty_read+0x1800/0x1800 > [ 51.162730] ? prepare_to_wait_exclusive+0x270/0x270 > [ 51.162754] ? __might_fault+0x175/0x1b0 > [ 51.162783] tty_write+0x42b/0x8d0 > [ 51.162795] ? n_tty_read+0x1800/0x1800 > [ 51.162825] ? tty_lookup_driver+0x450/0x450 > [ 51.162848] __vfs_write+0x7c/0x100 > [ 51.162875] vfs_write+0x1c9/0x510 > [ 51.162901] ksys_write+0xff/0x200 > [ 51.162918] ? __ia32_sys_read+0xb0/0xb0 > [ 51.162940] ? do_syscall_64+0x1a/0x520 > [ 51.162957] ? lockdep_hardirqs_on_prepare+0x379/0x540 > [ 51.162984] do_syscall_64+0xa1/0x520 > [ 51.163008] entry_SYSCALL_64_after_hwframe+0x49/0xb3 > > After vgacon_set_origin() is called in set_origin(), the vc_origin is > set to vga_vram_base, the vc_pos should between vga_vram_base and > vga_vram_end. But we still use vc_screenbuf_size, if the vga_vram_size > is smaller than vc_screenbuf_size, vc_pos may be out of bound, using it > will cause a use-after-free(or out-of-bounds). Fix this by calling > vc_resize() if vga_vram_size is smaller than vc_screenbuf_size. > > Signed-off-by: Yang Yingliang > --- > drivers/video/console/vgacon.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c > index b51ffb9a208d..2eabb86bb0dd 100644 > --- a/drivers/video/console/vgacon.c > +++ b/drivers/video/console/vgacon.c > @@ -1341,6 +1341,9 @@ static int vgacon_set_origin(struct vc_data *c) > if (vga_is_gfx || /* We don't play origin tricks in graphic modes > */ > (console_blanked && !vga_palette_blanked)) /* Nor we write to > blanked screens */ > return 0; > + > + if (c->vc_screenbuf_size > vga_vram_size) > + vc_resize(c, screen_info.orig_video_cols, > screen_info.orig_video_lines); > c->vc_origin = c->vc_visible_origin = vga_vram_base; > vga_set_mem_top(c); > vga_rolled_over = 0; > -- > 2.25.1 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] HID: i2c-hid: add polling mode based on connected GPIO chip's pin status
Hi
> [...]
> >> +static int get_gpio_pin_state(struct irq_desc *irq_desc)
> >> +{
> >> + struct gpio_chip *gc = irq_data_get_irq_chip_data(&irq_desc->irq_data);
> >> +
> >> + return gc->get(gc, irq_desc->irq_data.hwirq);
> >> +}
> >> +
> >> +static bool interrupt_line_active(struct i2c_client *client)
> >> +{
> >> + unsigned long trigger_type = irq_get_trigger_type(client->irq);
> >> + struct irq_desc *irq_desc = irq_to_desc(client->irq);
> >> +
> >> + /*
> >> + * According to Windows Precsiontion Touchpad's specs
> >> + *
> >> https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-precision-touchpad-device-bus-connectivity,
> >> + * GPIO Interrupt Assertion Leve could be either ActiveLow or
> >> + * ActiveHigh.
> >> + */
> >> + if (trigger_type & IRQF_TRIGGER_LOW)
> >> + return !get_gpio_pin_state(irq_desc);
> >> +
> >> + return get_gpio_pin_state(irq_desc);
> >> +}
> >
> >Excuse my ignorance, but I think some kind of error handling regarding the
> >return
> >value of `get_gpio_pin_state()` should be present here.
> >
> What kind of errors would you expect? It seems (struct gpio_chip *)->get
> only return 0 or 1.
> >
I read the code of a couple gpio chips and - I may be wrong, but - it seems they
can return an arbitrary errno.
> >> +
> >> +static int i2c_hid_polling_thread(void *i2c_hid)
> >> +{
> >> + struct i2c_hid *ihid = i2c_hid;
> >> + struct i2c_client *client = ihid->client;
> >> + unsigned int polling_interval_idle;
> >> +
> >> + while (1) {
> >> + /*
> >> + * re-calculate polling_interval_idle
> >> + * so the module parameters polling_interval_idle_ms can be
> >> + * changed dynamically through sysfs as
> >> polling_interval_active_us
> >> + */
> >> + polling_interval_idle = polling_interval_idle_ms * 1000;
> >> + if (test_bit(I2C_HID_READ_PENDING, &ihid->flags))
> >> + usleep_range(5, 10);
> >> +
> >> + if (kthread_should_stop())
> >> + break;
> >> +
> >> + while (interrupt_line_active(client)) {
> >
> >I realize it's quite unlikely, but can't this be a endless loop if data is
> >coming
> >in at a high enough rate? Maybe the maximum number of iterations could be
> >limited here?
> >
> If we find HID reports are constantly read and send to front-end
> application like libinput, won't it help expose the problem of the I2C
> HiD device?
> >
I'm not sure I completely understand your point. The reason why I wrote what I
wrote
is that this kthread could potentially could go on forever (since
`kthread_should_stop()`
is not checked in the inner while loop) if the data is supplied at a high
enough rate.
That's why I said, to avoid this problem, only allow a certain number of
iterations
for the inner loop, to guarantee that the kthread can stop in any case.
> >> + i2c_hid_get_input(ihid);
> >> + usleep_range(polling_interval_active_us,
> >> + polling_interval_active_us + 100);
> >> + }
> >> +
> >> + usleep_range(polling_interval_idle,
> >> + polling_interval_idle + 1000);
> >> + }
> >> +
> >> + do_exit(0);
> >> + return 0;
> >> +}
> [...]
> >Excuse my ignorance, but I do not understand why the following two changes
> >are not enough:
> >
> >in `i2c_hid_suspend()`:
> > if (polling_mode == I2C_POLLING_DISABLED)
> > disable_irq(client->irq);
> >
> >in `i2c_hid_resume()`:
> > if (polling_mode == I2C_POLLING_DISABLED)
> > enable_irq(client->irq);
> >
> I think we shouldn't call enable/disable_irq_wake in polling mode
> where we don't set up irq.
I think I now understand what you mean. I'm not sure, but it seems logical to me
that you can enable/disable irq wake regardless whether any irq handlers are
registered or not. Therefore, I figure it makes sense to take the safe path,
and don't touch irq wake when polling, just as you did.
> [...]
Regards,
Barnabás Pőcze
Announce loop-AES-v3.7s file/swap crypto package
loop-AES changes since previous release: - Worked around kernel interface changes on 5.9 kernels - Partial re-write of ioctl handling to get rid of set_fs() which is expected to be removed from mainline kernels in near future. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7s.tar.bz2 md5sum 154fabeb1976dc6dc111c96918d4c128 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7s.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: [PATCH v3 2/2] interconnect: qcom: Add SDM660 interconnect provider driver
Hello! Il giorno ven 16 ott 2020 alle ore 10:46 Georgi Djakov ha scritto: > > Hi, > > Thanks for the patch! My pleasure! > > On 10/8/20 23:45, khol...@gmail.com wrote: > > From: AngeloGioacchino Del Regno > > > > Introduce a driver for the Qualcomm interconnect busses found in > > the SDM630/SDM636/SDM660 SoCs. > > The topology consists of several NoCs that are controlled by a > > remote processor that collects the aggregated bandwidth for each > > master-slave pairs. > > > > On a note, these chips are managing the "bus QoS" in a "hybrid" > > fashion: some of the paths in the topology are managed through > > (and by, of course) the RPM uC, while some others are "AP Owned", > > meaning that the AP shall do direct writes to the appropriate > > QoS registers for the specific paths and ports, instead of sending > > an indication to the RPM and leaving the job to that one. > > > > Signed-off-by: AngeloGioacchino Del Regno > > --- > > drivers/interconnect/qcom/Kconfig | 9 + > > drivers/interconnect/qcom/Makefile | 2 + > > drivers/interconnect/qcom/sdm660.c | 919 + > > 3 files changed, 930 insertions(+) > > create mode 100644 drivers/interconnect/qcom/sdm660.c > > > > diff --git a/drivers/interconnect/qcom/Kconfig > > b/drivers/interconnect/qcom/Kconfig > > index a8f93ba265f8..ae76527a22f6 100644 > > --- a/drivers/interconnect/qcom/Kconfig > > +++ b/drivers/interconnect/qcom/Kconfig > > @@ -42,6 +42,15 @@ config INTERCONNECT_QCOM_QCS404 > > This is a driver for the Qualcomm Network-on-Chip on qcs404-based > > platforms. > > > > +config INTERCONNECT_QCOM_SDM660 > > + tristate "Qualcomm SDM660 interconnect driver" > > + depends on INTERCONNECT_QCOM > > + depends on QCOM_SMD_RPM > > + select INTERCONNECT_QCOM_SMD_RPM > > + help > > + This is a driver for the Qualcomm Network-on-Chip on sdm660-based > > + platforms. > > + > > config INTERCONNECT_QCOM_RPMH > > tristate > > > > diff --git a/drivers/interconnect/qcom/Makefile > > b/drivers/interconnect/qcom/Makefile > > index cf628f7990cd..ebe15d1dfe8b 100644 > > --- a/drivers/interconnect/qcom/Makefile > > +++ b/drivers/interconnect/qcom/Makefile > > @@ -7,6 +7,7 @@ icc-osm-l3-objs := osm-l3.o > > qnoc-qcs404-objs := qcs404.o > > icc-rpmh-obj := icc-rpmh.o > > qnoc-sc7180-objs := sc7180.o > > +qnoc-sdm660-objs := sdm660.o > > qnoc-sdm845-objs := sdm845.o > > qnoc-sm8150-objs := sm8150.o > > qnoc-sm8250-objs := sm8250.o > > @@ -19,6 +20,7 @@ obj-$(CONFIG_INTERCONNECT_QCOM_OSM_L3) += icc-osm-l3.o > > obj-$(CONFIG_INTERCONNECT_QCOM_QCS404) += qnoc-qcs404.o > > obj-$(CONFIG_INTERCONNECT_QCOM_RPMH) += icc-rpmh.o > > obj-$(CONFIG_INTERCONNECT_QCOM_SC7180) += qnoc-sc7180.o > > +obj-$(CONFIG_INTERCONNECT_QCOM_SDM660) += qnoc-sdm660.o > > obj-$(CONFIG_INTERCONNECT_QCOM_SDM845) += qnoc-sdm845.o > > obj-$(CONFIG_INTERCONNECT_QCOM_SM8150) += qnoc-sm8150.o > > obj-$(CONFIG_INTERCONNECT_QCOM_SM8250) += qnoc-sm8250.o > > diff --git a/drivers/interconnect/qcom/sdm660.c > > b/drivers/interconnect/qcom/sdm660.c > > new file mode 100644 > > index ..9ad709dde913 > > --- /dev/null > > +++ b/drivers/interconnect/qcom/sdm660.c > > @@ -0,0 +1,919 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Qualcomm SDM630/SDM636/SDM660 Network-on-Chip (NoC) QoS driver > > + * Copyright (C) 2020, AngeloGioacchino Del Regno > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "smd-rpm.h" > > + > > +#define RPM_BUS_MASTER_REQ 0x73616d62 > > +#define RPM_BUS_SLAVE_REQ0x766c7362 > > + > > +/* BIMC QoS */ > > +#define M_BKE_REG_BASE(n)(0x300 + (0x4000 * n)) > > +#define M_BKE_EN_ADDR(n) (M_BKE_REG_BASE(n)) > > +#define M_BKE_HEALTH_CFG_ADDR(i, n) (M_BKE_REG_BASE(n) + 0x40 + (0x4 * > > i))> + > > +#define M_BKE_HEALTH_CFG_LIMITCMDS_MASK 0x8000 > > +#define M_BKE_HEALTH_CFG_AREQPRIO_MASK 0x300 > > +#define M_BKE_HEALTH_CFG_REG_MASK(n) ((n == 3) ? 0x303 : 0x8303) > > This one is not used? Maybe remove it? > > > +#define M_BKE_HEALTH_CFG_PRIOLVL_MASK0x3 > > +#define M_BKE_HEALTH_CFG_AREQPRIO_SHIFT 0x8 > > +#define M_BKE_HEALTH_CFG_LIMITCMDS_SHIFT 0x1f > > + > > +#define M_BKE_HEALTH_CFG_ALL_MASK(M_BKE_HEALTH_CFG_LIMITCMDS_MASK | \ > > + M_BKE_HEALTH_CFG_AREQPRIO_MASK | \ > > + M_BKE_HEALTH_CFG_PRIOLVL_MASK) > > + > > +#define M_BKE_EN_EN_BMASK0x1 > > + > > +/* Valid for both NoC and BIMC */ > > +#define NOC_QOS_MODE_FIXED 0x0 > > +#define NOC_QOS_MODE_LIMITER 0x1 > > +#define NOC_QOS_MODE_BYPASS
Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver
After discussing this offline with Jann a bit, I have a few general comments on the design of this. First, the UUID communicated by the hypervisor should be consumed by the kernel -- added as another input to the rng -- and then userspace should be notified that it should reseed any userspace RNGs that it may have, without actually communicating that UUID to userspace. IOW, I agree with Jann there. Then, it's the functioning of this notification mechanism to userspace that is interesting to me. There are a few design goals of notifying userspace: it should be fast, because people who are using userspace RNGs are usually doing so in the first place to completely avoid syscall overhead for whatever high performance application they have - e.g. I recall conversations with Colm about his TLS implementation needing to make random IVs _really_ fast. It should also happen as early as possible, with no race or as minimal as possible race window, so that userspace doesn't begin using old randomness and then switch over after the damage is already done. I'm also not wedded to using Microsoft's proprietary hypervisor design for this. If we come up with a better interface, I don't think it's asking too much to implement that and reasonably expect for Microsoft to catch up. Maybe someone here will find that controversial, but whatever -- discussing ideal designs does not seem out of place or inappropriate for how we usually approach things in the kernel, and a closed source hypervisor coming along shouldn't disrupt that. So, anyway, here are a few options with some pros and cons for the kernel notifying userspace that its RNG should reseed. 1. SIGRND - a new signal. Lol. 2. Userspace opens a file descriptor that it can epoll on. Pros are that many notification mechanisms already use this. Cons is that this requires syscall and might be more racy than we want. Another con is that this a new thing for userspace programs to do. 3. We stick an atomic counter in the vDSO, Jann's suggestion. Pros are that this is extremely fast, and also simple to use and implement. There are enough sequence points in typical crypto programs that checking to see whether this counter has changed before doing whatever operation seems easy enough. Cons are that typically we've been conservative about adding things to the vDSO, and this is also a new thing for userspace programs to do. 4. We already have a mechanism for this kind of thing, because the same issue comes up when fork()ing. The solution was MADV_WIPEONFORK, where userspace marks a page to be zeroed when forking, for the purposes of the RNG being notified when its world gets split in two. This is basically the same thing as we're discussing here with guest snapshots, except it's on the system level rather than the process level, and a system has many processes. But the problem space is still almost the same, and we could simply reuse that same mechanism. There are a few implementation strategies for that: 4a. We mess with the PTEs of all processes' pages that are MADV_WIPEONFORK, like fork does now, when the hypervisor notifies us to do so. Then we wind up reusing the already existing logic for userspace RNGs. Cons might be that this usually requires semaphores, and we're in irq context, so we'd have to hoist to a workqueue, which means either more wake up latency, or a larger race window. 4b. We just memzero all processes' pages that are MADV_WIPEONFORK, when the hypervisor notifies us to do so. Then we wind up reusing the already existing logic for userspace RNGs. 4c. The guest kernel maintains an array of physical addresses that are MADV_WIPEONFORK. The hypervisor knows about this array and its location through whatever protocol, and before resuming a moved/snapshotted/duplicated VM, it takes the responsibility for memzeroing this memory. The huge pro here would be that this eliminates all races, and reduces complexity quite a bit, because the hypervisor can perfectly synchronize its bringup (and SMP bringup) with this, and it can even optimize things like on-disk memory snapshots to simply not write out those pages to disk. A 4c-like approach seems like it'd be a lot of bang for the buck -- we reuse the existing mechanism (MADV_WIPEONFORK), so there's no new userspace API to deal with, and it'd be race free, and eliminate a lot of kernel complexity. But 4b and 3 don't seem too bad either. Any thoughts on 4c? Is that utterly insane, or does that actually get us somewhere close to what we want? Jason
Re: [PATCH v7 6/6] rcu/segcblist: Add additional comments to explain smp_mb()
On Fri, Oct 16, 2020 at 11:19:41PM -0400, j...@joelfernandes.org wrote:
> On Fri, Oct 16, 2020 at 09:27:53PM -0400, j...@joelfernandes.org wrote:
> [..]
> > > > + *
> > > > + * Memory barrier is needed after adding to length for the case
> > > > + * where length transitions from 0 -> 1. This is because rcu_barrier()
> > > > + * should never miss an update to the length. So the update to length
> > > > + * has to be seen *before* any modifications to the segmented list.
> > > > Otherwise a
> > > > + * race can happen.
> > > > + * P0 (what P1 sees) P1
> > > > + * queue to list
> > > > + * rcu_barrier sees len as 0
> > > > + * set len = 1.
> > > > + * rcu_barrier does nothing.
> > >
> > > So that would be:
> > >
> > > call_rcu()rcu_barrier()
> > > ----
> > > WRITE(len, len + 1) l = READ(len)
> > > smp_mb() if (!l)
> > > queuecheck next CPU...
> > >
> > >
> > > But I still don't see against what it pairs in rcu_barrier.
> >
> > Actually, for the second case maybe a similar reasoning can be applied
> > (control dependency) but I'm unable to come up with a litmus test.
> > In fact, now I'm wondering how is it possible that call_rcu() races with
> > rcu_barrier(). The module should ensure that no more call_rcu() should
> > happen
> > before rcu_barrier() is called.
> >
> > confused
>
> So I made a litmus test to show that smp_mb() is needed also after the update
> to length. Basically, otherwise it is possible the callback will see garbage
> that the module cleanup/unload did.
>
> C rcubarrier+ctrldep
>
> (*
> * Result: Never
> *
> * This litmus test shows that rcu_barrier (P1) prematurely
> * returning by reading len 0 can cause issues if P0 does
> * NOT have a smb_mb() after WRITE_ONCE(len, 1).
> * mod_data == 2 means module was unloaded (so data is garbage).
> *)
>
> { int len = 0; int enq = 0; }
>
> P0(int *len, int *mod_data, int *enq)
> {
> int r0;
>
> WRITE_ONCE(*len, 1);
> smp_mb(); /* Needed! */
> WRITE_ONCE(*enq, 1);
>
> r0 = READ_ONCE(*mod_data);
> }
>
> P1(int *len, int *mod_data, int *enq)
> {
> int r0;
> int r1;
>
> r1 = READ_ONCE(*enq);
>
> // barrier Just for test purpose ("exists" clause) to force the..
> // ..rcu_barrier() to see enq before len
> smp_mb();
> r0 = READ_ONCE(*len);
>
> // implicit memory barrier due to conditional */
> if (r0 == 0)
> WRITE_ONCE(*mod_data, 2);
> }
I'm not sure what scenario P1 refers to in practice, and to what module?
>
> // Did P0 read garbage?
> exists (0:r0=2 /\ 1:r0=0 /\ 1:r1=1)
>
What also scares me is that in rcu_barrier():
for_each_possible_cpu(cpu) {
rdp = per_cpu_ptr(&rcu_data, cpu);
if (cpu_is_offline(cpu) &&
!rcu_segcblist_is_offloaded(&rdp->cblist))
continue;
if (rcu_segcblist_n_cbs(&rdp->cblist) && cpu_online(cpu)) {
rcu_barrier_trace(TPS("OnlineQ"), cpu,
rcu_state.barrier_sequence);
smp_call_function_single(cpu, rcu_barrier_func, (void
*)cpu, 1);
} else if (rcu_segcblist_n_cbs(&rdp->cblist) &&
cpu_is_offline(cpu)) {
rcu_barrier_trace(TPS("OfflineNoCBQ"), cpu,
rcu_state.barrier_sequence);
local_irq_disable();
rcu_barrier_func((void *)cpu);
local_irq_enable();
} else if (cpu_is_offline(cpu)) {
rcu_barrier_trace(TPS("OfflineNoCBNoQ"), cpu,
rcu_state.barrier_sequence);
} else {
rcu_barrier_trace(TPS("OnlineNQ"), cpu,
rcu_state.barrier_sequence);
}
}
I can't find something that makes sure this isn't racy while reading
rcu_segcblist_n_cbs(&rdp->cblist).
I mean what I see sums up to this:
CPU 0CPU 1
rcu_barrier()call_rcu()/rcu_segcblist_enqueue()
smp_mb();
inc_len();
smp_mb();
queue callback;
for_each_possible_cpu(cpu)
if (!rcu_segcblist_n_cbs(&rdp->cblist))
continue;
It looks possible for rcu_barrier() to believe there is no callback enqueued
and see rcu_segcblist_n_cbs(&rdp->cblist) == 0 here.
I'm very likely missing something obvious somewhere.
[PATCH v4 1/2] dt-bindings: interconnect: Add bindings for Qualcomm SDM660 NoC
From: AngeloGioacchino Del Regno
Add the bindings for the Qualcomm SDM660-class NoC, valid for
SDM630, SDM636, SDM660 and SDA variants.
Signed-off-by: AngeloGioacchino Del Regno
---
.../bindings/interconnect/qcom,sdm660.yaml| 147 ++
.../dt-bindings/interconnect/qcom,sdm660.h| 116 ++
2 files changed, 263 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml
create mode 100644 include/dt-bindings/interconnect/qcom,sdm660.h
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml
b/Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml
new file mode 100644
index ..29de7807df54
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml
@@ -0,0 +1,147 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sdm660.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SDM660 Network-On-Chip interconnect
+
+maintainers:
+ - AngeloGioacchino Del Regno
+
+description: |
+ The Qualcomm SDM660 interconnect providers support adjusting the
+ bandwidth requirements between the various NoC fabrics.
+
+properties:
+ reg:
+maxItems: 1
+
+ compatible:
+enum:
+ - qcom,sdm660-a2noc
+ - qcom,sdm660-bimc
+ - qcom,sdm660-cnoc
+ - qcom,sdm660-gnoc
+ - qcom,sdm660-mnoc
+ - qcom,sdm660-snoc
+
+ '#interconnect-cells':
+const: 1
+
+ clocks:
+minItems: 1
+maxItems: 3
+
+ clock-names:
+minItems: 1
+maxItems: 3
+
+required:
+ - compatible
+ - reg
+ - '#interconnect-cells'
+ - clock-names
+ - clocks
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+enum:
+ - qcom,sdm660-mnoc
+then:
+ properties:
+clocks:
+ items:
+- description: Bus Clock.
+- description: Bus A Clock.
+- description: CPU-NoC High-performance Bus Clock.
+clock-names:
+ items:
+- const: bus
+- const: bus_a
+- const: iface
+
+ - if:
+ properties:
+compatible:
+ contains:
+enum:
+ - qcom,sdm660-a2noc
+ - qcom,sdm660-bimc
+ - qcom,sdm660-cnoc
+ - qcom,sdm660-gnoc
+ - qcom,sdm660-snoc
+then:
+ properties:
+clocks:
+ items:
+- description: Bus Clock.
+- description: Bus A Clock.
+clock-names:
+ items:
+- const: bus
+- const: bus_a
+
+examples:
+ - |
+ #include
+ #include
+
+ bimc: interconnect@1008000 {
+ compatible = "qcom,sdm660-bimc";
+ reg = <0x01008000 0x78000>;
+ #interconnect-cells = <1>;
+ clock-names = "bus", "bus_a";
+ clocks = <&rpmcc RPM_SMD_BIMC_CLK>,
+ <&rpmcc RPM_SMD_BIMC_A_CLK>;
+ };
+
+ cnoc: interconnect@150 {
+ compatible = "qcom,sdm660-cnoc";
+ reg = <0x0150 0x1>;
+ #interconnect-cells = <1>;
+ clock-names = "bus", "bus_a";
+ clocks = <&rpmcc RPM_SMD_CNOC_CLK>,
+ <&rpmcc RPM_SMD_CNOC_A_CLK>;
+ };
+
+ snoc: interconnect@1626000 {
+ compatible = "qcom,sdm660-snoc";
+ reg = <0x01626000 0x7090>;
+ #interconnect-cells = <1>;
+ clock-names = "bus", "bus_a";
+ clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
+ <&rpmcc RPM_SMD_SNOC_A_CLK>;
+ };
+
+ a2noc: interconnect@1704000 {
+ compatible = "qcom,sdm660-a2noc";
+ reg = <0x01704000 0xc100>;
+ #interconnect-cells = <1>;
+ clock-names = "bus", "bus_a";
+ clocks = <&rpmcc RPM_SMD_AGGR2_NOC_CLK>,
+ <&rpmcc RPM_SMD_AGGR2_NOC_A_CLK>;
+ };
+
+ mnoc: interconnect@1745000 {
+ compatible = "qcom,sdm660-mnoc";
+ reg = <0x01745000 0xa010>;
+ #interconnect-cells = <1>;
+ clock-names = "bus", "bus_a", "iface";
+ clocks = <&rpmcc RPM_SMD_MMSSNOC_AXI_CLK>,
+ <&rpmcc RPM_SMD_MMSSNOC_AXI_CLK_A>,
+ <&mmcc AHB_CLK_SRC>;
+ };
+
+ gnoc: interconnect@1790 {
+ compatible = "qcom,sdm660-gnoc";
+ reg = <0x1790 0xe000>;
+ #interconnect-cells = <1>;
+ clock-names = "bus", "bus_a";
+ clocks = <&xo_board>, <&xo_board>;
+ };
diff --git a/include/dt-bindings/interconnect/qcom,sdm660.h
b/include/dt-bindings/interconnect/qcom,sdm660.h
new file mode 100644
index ..62e8d8670d5e
--- /dev/null
+++ b/include/dt-bindings/interconnect/qcom,sdm660.
[PATCH v4 2/2] interconnect: qcom: Add SDM660 interconnect provider driver
From: AngeloGioacchino Del Regno
Introduce a driver for the Qualcomm interconnect busses found in
the SDM630/SDM636/SDM660 SoCs.
The topology consists of several NoCs that are controlled by a
remote processor that collects the aggregated bandwidth for each
master-slave pairs.
On a note, these chips are managing the "bus QoS" in a "hybrid"
fashion: some of the paths in the topology are managed through
(and by, of course) the RPM uC, while some others are "AP Owned",
meaning that the AP shall do direct writes to the appropriate
QoS registers for the specific paths and ports, instead of sending
an indication to the RPM and leaving the job to that one.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/interconnect/qcom/Kconfig | 9 +
drivers/interconnect/qcom/Makefile | 2 +
drivers/interconnect/qcom/sdm660.c | 922 +
3 files changed, 933 insertions(+)
create mode 100644 drivers/interconnect/qcom/sdm660.c
diff --git a/drivers/interconnect/qcom/Kconfig
b/drivers/interconnect/qcom/Kconfig
index a8f93ba265f8..ae76527a22f6 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -42,6 +42,15 @@ config INTERCONNECT_QCOM_QCS404
This is a driver for the Qualcomm Network-on-Chip on qcs404-based
platforms.
+config INTERCONNECT_QCOM_SDM660
+ tristate "Qualcomm SDM660 interconnect driver"
+ depends on INTERCONNECT_QCOM
+ depends on QCOM_SMD_RPM
+ select INTERCONNECT_QCOM_SMD_RPM
+ help
+ This is a driver for the Qualcomm Network-on-Chip on sdm660-based
+ platforms.
+
config INTERCONNECT_QCOM_RPMH
tristate
diff --git a/drivers/interconnect/qcom/Makefile
b/drivers/interconnect/qcom/Makefile
index cf628f7990cd..ebe15d1dfe8b 100644
--- a/drivers/interconnect/qcom/Makefile
+++ b/drivers/interconnect/qcom/Makefile
@@ -7,6 +7,7 @@ icc-osm-l3-objs := osm-l3.o
qnoc-qcs404-objs := qcs404.o
icc-rpmh-obj := icc-rpmh.o
qnoc-sc7180-objs := sc7180.o
+qnoc-sdm660-objs := sdm660.o
qnoc-sdm845-objs := sdm845.o
qnoc-sm8150-objs := sm8150.o
qnoc-sm8250-objs := sm8250.o
@@ -19,6 +20,7 @@ obj-$(CONFIG_INTERCONNECT_QCOM_OSM_L3) += icc-osm-l3.o
obj-$(CONFIG_INTERCONNECT_QCOM_QCS404) += qnoc-qcs404.o
obj-$(CONFIG_INTERCONNECT_QCOM_RPMH) += icc-rpmh.o
obj-$(CONFIG_INTERCONNECT_QCOM_SC7180) += qnoc-sc7180.o
+obj-$(CONFIG_INTERCONNECT_QCOM_SDM660) += qnoc-sdm660.o
obj-$(CONFIG_INTERCONNECT_QCOM_SDM845) += qnoc-sdm845.o
obj-$(CONFIG_INTERCONNECT_QCOM_SM8150) += qnoc-sm8150.o
obj-$(CONFIG_INTERCONNECT_QCOM_SM8250) += qnoc-sm8250.o
diff --git a/drivers/interconnect/qcom/sdm660.c
b/drivers/interconnect/qcom/sdm660.c
new file mode 100644
index ..6953d6d99a11
--- /dev/null
+++ b/drivers/interconnect/qcom/sdm660.c
@@ -0,0 +1,922 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Qualcomm SDM630/SDM636/SDM660 Network-on-Chip (NoC) QoS driver
+ * Copyright (C) 2020, AngeloGioacchino Del Regno
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "smd-rpm.h"
+
+#define RPM_BUS_MASTER_REQ 0x73616d62
+#define RPM_BUS_SLAVE_REQ 0x766c7362
+
+/* BIMC QoS */
+#define M_BKE_REG_BASE(n) (0x300 + (0x4000 * n))
+#define M_BKE_EN_ADDR(n) (M_BKE_REG_BASE(n))
+#define M_BKE_HEALTH_CFG_ADDR(i, n)(M_BKE_REG_BASE(n) + 0x40 + (0x4 * i))
+
+#define M_BKE_HEALTH_CFG_LIMITCMDS_MASK0x8000
+#define M_BKE_HEALTH_CFG_AREQPRIO_MASK 0x300
+#define M_BKE_HEALTH_CFG_PRIOLVL_MASK 0x3
+#define M_BKE_HEALTH_CFG_AREQPRIO_SHIFT0x8
+#define M_BKE_HEALTH_CFG_LIMITCMDS_SHIFT 0x1f
+
+#define M_BKE_EN_EN_BMASK 0x1
+
+/* Valid for both NoC and BIMC */
+#define NOC_QOS_MODE_FIXED 0x0
+#define NOC_QOS_MODE_LIMITER 0x1
+#define NOC_QOS_MODE_BYPASS0x2
+
+/* NoC QoS */
+#define NOC_PERM_MODE_FIXED1
+#define NOC_PERM_MODE_BYPASS (1 << NOC_QOS_MODE_BYPASS)
+
+#define NOC_QOS_PRIORITYn_ADDR(n) (0x8 + (n * 0x1000))
+#define NOC_QOS_PRIORITY_MASK 0xf
+#define NOC_QOS_PRIORITY_P1_SHIFT 0x2
+#define NOC_QOS_PRIORITY_P0_SHIFT 0x3
+
+#define NOC_QOS_MODEn_ADDR(n) (0xc + (n * 0x1000))
+#define NOC_QOS_MODEn_MASK 0x3
+
+enum {
+ SDM660_MASTER_IPA = 1,
+ SDM660_MASTER_CNOC_A2NOC,
+ SDM660_MASTER_SDCC_1,
+ SDM660_MASTER_SDCC_2,
+ SDM660_MASTER_BLSP_1,
+ SDM660_MASTER_BLSP_2,
+ SDM660_MASTER_UFS,
+ SDM660_MASTER_USB_HS,
+ SDM660_MASTER_USB3,
+ SDM660_MASTER_CRYPTO_C0,
+ SDM660_MASTER_GNOC_BIMC,
+ SDM660_MASTER_OXILI,
+ SDM660_MASTER_MNOC_BIMC,
+ SDM660_MASTER_SNOC_BIMC,
+ SDM660_MASTER_PIMEM,
+ SDM660_MASTE
[PATCH v4 0/2] Add SDM630/636/660 interconnect driver
From: AngeloGioacchino Del Regno This patch series adds the SDM660 interconnect provider driver in order to stop some timeouts and achieve some decent performance by avoiding to be NoC limited. It's also providing some power consumption improvement, but I have only measured that as less heat, which is quite important when working on thermally constrained devices like smartphones. Please note that this driver's yaml binding is referring to a MMCC clock, so this series does depend on the SDM660 MMCC driver that I have sent separately. The multimedia clock is required only for the Multimedia NoC (mnoc). This patch series has been tested against the following devices: - Sony Xperia XA2 Ultra (SDM630 Nile Discovery) - Sony Xperia 10(SDM630 Ganges Kirin) - Sony Xperia 10 Plus (SDM636 Ganges Mermaid) Changes in v2: - Added missing qcom,mmcc-sdm660.h dt-binding include in the interconnect/qcom,sdm660.yaml binding, as pointed out by Rob Herring Changes in v3: - Moved the dt-bindings/interconnect/qcom,sdm660.h header to dt-bindings commit. Changes in v4: - Fixed code style issues and removed unused defines as per Georgi Djakov's review - Fixed the SDCC2 RPM master/slave IDs - Added an exception to stop writing LIMITCMDS to M_BKE_HEALTH_3 as it doesn't exist there (it seems to be harmless to write that there, but it's incorrect to) - Tested again on the aforementioned devices AngeloGioacchino Del Regno (2): dt-bindings: interconnect: Add bindings for Qualcomm SDM660 NoC interconnect: qcom: Add SDM660 interconnect provider driver .../bindings/interconnect/qcom,sdm660.yaml| 147 +++ drivers/interconnect/qcom/Kconfig | 9 + drivers/interconnect/qcom/Makefile| 2 + drivers/interconnect/qcom/sdm660.c| 922 ++ .../dt-bindings/interconnect/qcom,sdm660.h| 116 +++ 5 files changed, 1196 insertions(+) create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml create mode 100644 drivers/interconnect/qcom/sdm660.c create mode 100644 include/dt-bindings/interconnect/qcom,sdm660.h -- 2.28.0
Re: Backing up the PGP master key
On Thu, Oct 15, 2020 at 12:34:06AM +0300, Jarkko Sakkinen wrote: > Konstantin, writing to you based on 'git blame' :-) > > The maintainer guide recommends using paperkey for the PGP master key, > which is a prefectly sane method. > > I was just wondering that isn't a backup to a USB stick a reasonable > option? E.g. get a few USB sticks (new, unweared), store your master key > to each of them and put to safe. Sure, it's an option as well. I believe the guide recommends three different backups: 1. thumb drive within reach for regular access 2. another drive in case the first one goes bad 3. paperkey backup in the vault There's no reason why #2 above can't go into the vault as well, if you're inclined. I wouldn't skip paperkey, since I'm generally wary of putting anything long-term onto electronic media due to things like charge decay, cosmic rays, or other weird phenomena resulting in flipped bits. -K
My beloved
-- Good day and God bless you as you read this massage, I am Aadila Laboso a 27 years old girl from Kenya, my mother was Late Mrs. Lorna Laboso the former Kenyan Assistant Minister of Home and affairs who was among plan that crash board in the remote area of Kalong’s western Kenya Read more about the crash with the below web site.http://edition.cnn.com/2008/WORLD/africa/06/10/kenya.crash/index.html I am constrained to contact you because of the maltreatment I am receiving from my step mother. She planned to take away all my late mothers treasury and properties from me since the unexpected death of my beloved mother. One day I opened my mother brave case and secretly found out that my mother deposited the sum of 27.5 million Euros in BMCE bank of Burkina Faso with my name as the next of kin, then I visited Burkina Faso to withdraw the money and take care of myself and start a new life, on my arrival the Bank Director whom I meet in person told me that my mother left an instruction to the bank, that the money should be release to me only when I am an adult to present a trustee who will help me and invest the money overseas. That is the reason why I am in search of a honest and reliable person who will help me and stand as my trustee for the Bank to transfer the fund to your account for me to come over and join you.It will be my great pleasure to compensate you with 30% of the money for your help and the balance shall be my capital with your kind idea for me to invest under your control over there in your country.As soon as I receive your positive response showing your interest I will send you my picture's in my next mail and how you will have the money in your account. (aadilalabo...@gmail.com) Thanks and waiting Yours Sincerely Queen Aadila Laboso
Re: [PATCH v2] HID: i2c-hid: add polling mode based on connected GPIO chip's pin status
Hi,
On Sat, Oct 17, 2020 at 01:06:14PM +, Barnabás Pőcze wrote:
Hi
[...]
>> +static int get_gpio_pin_state(struct irq_desc *irq_desc)
>> +{
>> + struct gpio_chip *gc =
irq_data_get_irq_chip_data(&irq_desc->irq_data);
>> +
>> + return gc->get(gc, irq_desc->irq_data.hwirq);
>> +}
>> +
>> +static bool interrupt_line_active(struct i2c_client *client)
>> +{
>> + unsigned long trigger_type = irq_get_trigger_type(client->irq);
>> + struct irq_desc *irq_desc = irq_to_desc(client->irq);
>> +
>> + /*
>> + * According to Windows Precsiontion Touchpad's specs
>> + *
https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-precision-touchpad-device-bus-connectivity,
>> + * GPIO Interrupt Assertion Leve could be either ActiveLow or
>> + * ActiveHigh.
>> + */
>> + if (trigger_type & IRQF_TRIGGER_LOW)
>> + return !get_gpio_pin_state(irq_desc);
>> +
>> + return get_gpio_pin_state(irq_desc);
>> +}
>
>Excuse my ignorance, but I think some kind of error handling regarding the
return
>value of `get_gpio_pin_state()` should be present here.
>
What kind of errors would you expect? It seems (struct gpio_chip *)->get
only return 0 or 1.
>
I read the code of a couple gpio chips and - I may be wrong, but - it seems they
can return an arbitrary errno.
I thought all GPIO chip return 0 or 1 since !!val is returned. I find
an example which could return negative value,
// drivers/gpio/gpio-wm8994.c
static int wm8994_gpio_get(struct gpio_chip *chip, unsigned offset)
{
struct wm8994_gpio *wm8994_gpio = gpiochip_get_data(chip);
struct wm8994 *wm8994 = wm8994_gpio->wm8994;
int ret;
ret = wm8994_reg_read(wm8994, WM8994_GPIO_1 + offset);
if (ret < 0)
return ret;
if (ret & WM8994_GPN_LVL)
return 1;
else
return 0;
}
>> +
>> +static int i2c_hid_polling_thread(void *i2c_hid)
>> +{
>> + struct i2c_hid *ihid = i2c_hid;
>> + struct i2c_client *client = ihid->client;
>> + unsigned int polling_interval_idle;
>> +
>> + while (1) {
>> + /*
>> + * re-calculate polling_interval_idle
>> + * so the module parameters polling_interval_idle_ms can be
>> + * changed dynamically through sysfs as
polling_interval_active_us
>> + */
>> + polling_interval_idle = polling_interval_idle_ms * 1000;
>> + if (test_bit(I2C_HID_READ_PENDING, &ihid->flags))
>> + usleep_range(5, 10);
>> +
>> + if (kthread_should_stop())
>> + break;
>> +
>> + while (interrupt_line_active(client)) {
>
>I realize it's quite unlikely, but can't this be a endless loop if data is
coming
>in at a high enough rate? Maybe the maximum number of iterations could be
limited here?
>
If we find HID reports are constantly read and send to front-end
application like libinput, won't it help expose the problem of the I2C
HiD device?
>
I'm not sure I completely understand your point. The reason why I wrote what I
wrote
is that this kthread could potentially could go on forever (since
`kthread_should_stop()`
is not checked in the inner while loop) if the data is supplied at a high
enough rate.
That's why I said, to avoid this problem, only allow a certain number of
iterations
for the inner loop, to guarantee that the kthread can stop in any case.
I mean if "data is supplied at a high enough rate" does happen, this is
an abnormal case and indicates a bug. So we shouldn't cover it up. We
expect the user to report it to us.
>> + i2c_hid_get_input(ihid);
>> + usleep_range(polling_interval_active_us,
>> + polling_interval_active_us + 100);
>> + }
>> +
>> + usleep_range(polling_interval_idle,
>> + polling_interval_idle + 1000);
>> + }
>> +
>> + do_exit(0);
>> + return 0;
>> +}
[...]
>Excuse my ignorance, but I do not understand why the following two changes are
not enough:
>
>in `i2c_hid_suspend()`:
> if (polling_mode == I2C_POLLING_DISABLED)
> disable_irq(client->irq);
>
>in `i2c_hid_resume()`:
> if (polling_mode == I2C_POLLING_DISABLED)
> enable_irq(client->irq);
>
I think we shouldn't call enable/disable_irq_wake in polling mode
where we don't set up irq.
I think I now understand what you mean. I'm not sure, but it seems logical to me
that you can enable/disable irq wake regardless whether any irq handlers are
registered or not. Therefore, I figure it makes sense to take the safe path,
and don't touch irq wake when polling, just as you did.
Thank you for offering your understandings on this patch. When I'm going
to submit next version, I will add a "Signed-off-by" tag with your name
and email, does it look good to you?
[...]
Regar
[PATCH 0/3] Fixes and cleanups for atomisp
Hi Mauro, I'm reposting this series [1] as, following the merge window, it now cleanly applies to both Linus' tree and to linux-next. I've made a minor fix to patch #1 (see patch for details) but the other two patches have just been rebased. Best, Alex [1] See https://lore.kernel.org/lkml/20200921215359.45003-1-alex.dewa...@gmail.com/
[PATCH 2/3] staging: media: atomisp: Remove unhelpful info message
We don't really need to know that the LED pin reset successfully. Signed-off-by: Alex Dewar --- drivers/staging/media/atomisp/i2c/atomisp-lm3554.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c index b38df022f880..0043ae8e2ffa 100644 --- a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c +++ b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c @@ -771,7 +771,6 @@ static int lm3554_gpio_init(struct i2c_client *client) ret = gpiod_direction_output(pdata->gpio_reset, 0); if (ret < 0) return ret; - dev_info(&client->dev, "flash led reset successfully\n"); if (!pdata->gpio_strobe) return -EINVAL; -- 2.28.0
[PATCH 3/3] staging: media: atomisp: Don't abort on error in module exit path
The function lm3554_remove() checks for the return code for
lm3554_gpio_uninit() even though this is on the exit path and exits the
function, leaving the variable flash unfreed. Instead, print a warning and
free flash unconditionally.
Signed-off-by: Alex Dewar
---
.../staging/media/atomisp/i2c/atomisp-lm3554.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
index 0043ae8e2ffa..44c41a0119a1 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
@@ -782,7 +782,7 @@ static int lm3554_gpio_init(struct i2c_client *client)
return 0;
}
-static int lm3554_gpio_uninit(struct i2c_client *client)
+static void lm3554_gpio_uninit(struct i2c_client *client)
{
struct v4l2_subdev *sd = i2c_get_clientdata(client);
struct lm3554 *flash = to_lm3554(sd);
@@ -791,13 +791,13 @@ static int lm3554_gpio_uninit(struct i2c_client *client)
ret = gpiod_direction_output(pdata->gpio_strobe, 0);
if (ret < 0)
- return ret;
+ dev_err(&client->dev,
+ "gpio request/direction_output fail for gpio_strobe");
ret = gpiod_direction_output(pdata->gpio_reset, 0);
if (ret < 0)
- return ret;
-
- return 0;
+ dev_err(&client->dev,
+ "gpio request/direction_output fail for gpio_reset");
}
static void *lm3554_platform_data_func(struct i2c_client *client)
@@ -909,7 +909,6 @@ static int lm3554_remove(struct i2c_client *client)
{
struct v4l2_subdev *sd = i2c_get_clientdata(client);
struct lm3554 *flash = to_lm3554(sd);
- int ret;
media_entity_cleanup(&flash->sd.entity);
v4l2_ctrl_handler_free(&flash->ctrl_handler);
@@ -919,16 +918,11 @@ static int lm3554_remove(struct i2c_client *client)
del_timer_sync(&flash->flash_off_delay);
- ret = lm3554_gpio_uninit(client);
- if (ret < 0)
- goto fail;
+ lm3554_gpio_uninit(client);
kfree(flash);
return 0;
-fail:
- dev_err(&client->dev, "gpio request/direction_output fail");
- return ret;
}
static const struct dev_pm_ops lm3554_pm_ops = {
--
2.28.0
Re: [PATCH] skd_main: remove unused including
On 10/16/20 7:52 PM, Tian Tao wrote: > Remove including that don't need it. Applied, thanks. -- Jens Axboe
[PATCH 1/3] staging: media: atomisp: Fix error path in lm3554_probe()
The error path for lm3554_probe() contains a number of bugs, including:
* resource leaks
* jumping to error labels out of sequence
* not setting the return value appropriately
Fix it up and give the labels more memorable names.
This issue has existed since the code was originally contributed in
commit a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2"),
although the code was subsequently removed altogether and then
reinstated with commit ad85094b293e ("Revert "media: staging: atomisp: Remove
driver"").
Addresses-Coverity: 1496802 ("Resource leaks")
Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Alex Dewar
Reviewed-by: Dan Carpenter
---
v5: Check for error, not success (Dan), but do it correctly cf. v4 :)
v4: Rebase
v3: No changes
v2: Fix a couple more leaks on error path (Dan)
.../media/atomisp/i2c/atomisp-lm3554.c| 55 +++
1 file changed, 32 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
index 7ca7378b1859..b38df022f880 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
@@ -833,7 +833,6 @@ static void *lm3554_platform_data_func(struct i2c_client
*client)
static int lm3554_probe(struct i2c_client *client)
{
- int err = 0;
struct lm3554 *flash;
unsigned int i;
int ret;
@@ -843,36 +842,38 @@ static int lm3554_probe(struct i2c_client *client)
return -ENOMEM;
flash->pdata = lm3554_platform_data_func(client);
- if (IS_ERR(flash->pdata))
- return PTR_ERR(flash->pdata);
+ if (IS_ERR(flash->pdata)) {
+ ret = PTR_ERR(flash->pdata);
+ goto err_free_flash;
+ }
v4l2_i2c_subdev_init(&flash->sd, client, &lm3554_ops);
flash->sd.internal_ops = &lm3554_internal_ops;
flash->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
flash->mode = ATOMISP_FLASH_MODE_OFF;
flash->timeout = LM3554_MAX_TIMEOUT / LM3554_TIMEOUT_STEPSIZE - 1;
- ret =
- v4l2_ctrl_handler_init(&flash->ctrl_handler,
- ARRAY_SIZE(lm3554_controls));
+ ret = v4l2_ctrl_handler_init(&flash->ctrl_handler,
+ARRAY_SIZE(lm3554_controls));
if (ret) {
- dev_err(&client->dev, "error initialize a ctrl_handler.\n");
- goto fail2;
+ dev_err(&client->dev, "error initializing ctrl_handler");
+ goto err_unregister_sd;
}
for (i = 0; i < ARRAY_SIZE(lm3554_controls); i++)
v4l2_ctrl_new_custom(&flash->ctrl_handler, &lm3554_controls[i],
NULL);
- if (flash->ctrl_handler.error) {
- dev_err(&client->dev, "ctrl_handler error.\n");
- goto fail2;
+ ret = flash->ctrl_handler.error;
+ if (ret) {
+ dev_err(&client->dev, "ctrl_handler error");
+ goto err_free_ctrl_handler;
}
flash->sd.ctrl_handler = &flash->ctrl_handler;
- err = media_entity_pads_init(&flash->sd.entity, 0, NULL);
- if (err) {
- dev_err(&client->dev, "error initialize a media entity.\n");
- goto fail1;
+ ret = media_entity_pads_init(&flash->sd.entity, 0, NULL);
+ if (ret) {
+ dev_err(&client->dev, "error initializing media entity");
+ goto err_free_ctrl_handler;
}
flash->sd.entity.function = MEDIA_ENT_F_FLASH;
@@ -881,20 +882,28 @@ static int lm3554_probe(struct i2c_client *client)
timer_setup(&flash->flash_off_delay, lm3554_flash_off_delay, 0);
- err = lm3554_gpio_init(client);
- if (err) {
+ ret = lm3554_gpio_init(client);
+ if (ret) {
dev_err(&client->dev, "gpio request/direction_output fail");
- goto fail2;
+ goto err_del_timer;
}
- return atomisp_register_i2c_module(&flash->sd, NULL, LED_FLASH);
-fail2:
+
+ ret = atomisp_register_i2c_module(&flash->sd, NULL, LED_FLASH);
+ if (ret)
+ goto err_del_timer;
+
+ return 0;
+
+err_del_timer:
+ del_timer_sync(&flash->flash_off_delay);
media_entity_cleanup(&flash->sd.entity);
+err_free_ctrl_handler:
v4l2_ctrl_handler_free(&flash->ctrl_handler);
-fail1:
+err_unregister_sd:
v4l2_device_unregister_subdev(&flash->sd);
+err_free_flash:
kfree(flash);
-
- return err;
+ return ret;
}
static int lm3554_remove(struct i2c_client *client)
--
2.28.0
[PATCH v2] checkpatch: add a fixer for missing newline at eof
From: Tom Rix
Remove the trailing error message from the fixed lines
Signed-off-by: Tom Rix
---
v2: fix whitespace
---
scripts/checkpatch.pl | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index fab38b493cef..f9e78a5385ad 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3393,8 +3393,11 @@ sub process {
# check for adding lines without a newline.
if ($line =~ /^\+/ && defined $lines[$linenr] &&
$lines[$linenr] =~ /^\\ No newline at end of file/) {
- WARN("MISSING_EOF_NEWLINE",
-"adding a line without newline at end of file\n" .
$herecurr);
+ if (WARN("MISSING_EOF_NEWLINE",
+"adding a line without newline at end of
file\n" . $herecurr) &&
+ $fix) {
+ fix_delete_line($fixlinenr+1, "No newline at
end of file");
+ }
}
# check we are in a valid source file C or perl if not then ignore this hunk
--
2.18.1
Re: [PATCH v2] checkpatch: add a fixer for missing newline at eof
On Sat, 2020-10-17 at 07:25 -0700, t...@redhat.com wrote:
> From: Tom Rix
>
> Remove the trailing error message from the fixed lines
>
> Signed-off-by: Tom Rix
> ---
> v2: fix whitespace
Thanks Tom. Andrew can you pick this up please?
> ---
> scripts/checkpatch.pl | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index fab38b493cef..f9e78a5385ad 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3393,8 +3393,11 @@ sub process {
>
> # check for adding lines without a newline.
> if ($line =~ /^\+/ && defined $lines[$linenr] &&
> $lines[$linenr] =~ /^\\ No newline at end of file/) {
> - WARN("MISSING_EOF_NEWLINE",
> - "adding a line without newline at end of file\n" .
> $herecurr);
> + if (WARN("MISSING_EOF_NEWLINE",
> + "adding a line without newline at end of
> file\n" . $herecurr) &&
> + $fix) {
> + fix_delete_line($fixlinenr+1, "No newline at
> end of file");
> + }
> }
>
> # check we are in a valid source file C or perl if not then ignore this hunk
[PATCH 2/2] staging: media: atomisp: Remove unused function
The function ia_css_mipi_frame_specify() is not called from anywhere and
the comment above its declaration states that it should be removed when
there are no more users. So remove it.
Signed-off-by: Alex Dewar
---
drivers/staging/media/atomisp/pci/ia_css_mipi.h | 17 -
drivers/staging/media/atomisp/pci/sh_css_mipi.c | 11 ---
2 files changed, 28 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/ia_css_mipi.h
b/drivers/staging/media/atomisp/pci/ia_css_mipi.h
index 7b6d796d6ee0..9e50e1c619be 100644
--- a/drivers/staging/media/atomisp/pci/ia_css_mipi.h
+++ b/drivers/staging/media/atomisp/pci/ia_css_mipi.h
@@ -25,23 +25,6 @@
#include "ia_css_stream_format.h"
#include "ia_css_input_port.h"
-/* Backward compatible for CSS API 2.0 only
- * TO BE REMOVED when all drivers move to CSS API 2.1.
- */
-/* @brief Specify a CSS MIPI frame buffer.
- *
- * @param[in] size_mem_words The frame size in memory words (32B).
- * @param[in] contiguous Allocate memory physically contiguously or not.
- * @return The error code.
- *
- * \deprecated{Use ia_css_mipi_buffer_config instead.}
- *
- * Specifies a CSS MIPI frame buffer: size in memory words (32B).
- */
-int
-ia_css_mipi_frame_specify(const unsigned int size_mem_words,
- const bool contiguous);
-
/* @brief Register size of a CSS MIPI frame for check during capturing.
*
* @param[in] portCSI-2 port this check is registered.
diff --git a/drivers/staging/media/atomisp/pci/sh_css_mipi.c
b/drivers/staging/media/atomisp/pci/sh_css_mipi.c
index d5ae7f0b5864..3f34cc81be87 100644
--- a/drivers/staging/media/atomisp/pci/sh_css_mipi.c
+++ b/drivers/staging/media/atomisp/pci/sh_css_mipi.c
@@ -33,17 +33,6 @@
static u32
ref_count_mipi_allocation[N_CSI_PORTS]; /* Initialized in mipi_init */
-int
-ia_css_mipi_frame_specify(const unsigned int size_mem_words,
- const bool contiguous) {
- int err = 0;
-
- my_css.size_mem_words = size_mem_words;
- (void)contiguous;
-
- return err;
-}
-
/*
* Check if a source port or TPG/PRBS ID is valid
*/
--
2.28.0
[PATCH 1/2] staging: media: atomisp: Remove unnecessary if statement
The bodies of the if and else sections are the same, so just remove the
check.
Signed-off-by: Alex Dewar
---
.../staging/media/atomisp/pci/atomisp_cmd.c | 27 +--
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
index 592ea990d4ca..92ddce409d04 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
@@ -5407,27 +5407,12 @@ static int atomisp_set_fmt_to_isp(struct video_device
*vdev,
return -EINVAL;
}
- if (asd->continuous_mode->val &&
- (configure_pp_input == atomisp_css_preview_configure_pp_input ||
-configure_pp_input == atomisp_css_video_configure_pp_input)) {
- /* for isp 2.2, configure pp input is available for continuous
-* mode */
- ret = configure_pp_input(asd, isp_sink_crop->width,
-isp_sink_crop->height);
- if (ret) {
- dev_err(isp->dev, "configure_pp_input %ux%u\n",
- isp_sink_crop->width,
- isp_sink_crop->height);
- return -EINVAL;
- }
- } else {
- ret = configure_pp_input(asd, isp_sink_crop->width,
-isp_sink_crop->height);
- if (ret) {
- dev_err(isp->dev, "configure_pp_input %ux%u\n",
- isp_sink_crop->width, isp_sink_crop->height);
- return -EINVAL;
- }
+ ret = configure_pp_input(asd, isp_sink_crop->width,
isp_sink_crop->height);
+ if (ret) {
+ dev_err(isp->dev, "configure_pp_input %ux%u\n",
+ isp_sink_crop->width,
+ isp_sink_crop->height);
+ return -EINVAL;
}
if (asd->copy_mode)
ret = atomisp_css_copy_get_output_frame_info(asd, stream_index,
--
2.28.0
Re: [PATCH v7 6/6] rcu/segcblist: Add additional comments to explain smp_mb()
On Fri, Oct 16, 2020 at 09:27:53PM -0400, j...@joelfernandes.org wrote:
> Adding Alan as well as its memory barrier discussion ;-)
I don't know the internals of how RCU works, so I'll just speak to the
litmus test itself, ignoring issues of whether the litmus test is
appropriate or expresses what you really want.
> The following litmus test would confirm it:
>
> C rcubarrier+ctrldep
>
> (*
> * Result: Never
> *
> * This litmus test shows that rcu_barrier (P1) prematurely
> * returning by reading len 0 can cause issues if P0 does
> * NOT have a smb_mb() before WRITE_ONCE().
> *
> * mod_data == 2 means garbage which the callback should never see.
> *)
>
> { int len = 1; }
>
> P0(int *len, int *mod_data)
> {
> int r0;
>
> // accessed by say RCU callback in rcu_do_batch();
> r0 = READ_ONCE(*mod_data);
> smp_mb(); // Remove this and the "exists" will become true.
> WRITE_ONCE(*len, 0);
> }
>
> P1(int *len, int *mod_data)
> {
> int r0;
>
> r0 = READ_ONCE(*len);
>
> // rcu_barrier will return early if len is 0
> if (r0 == 0)
> WRITE_ONCE(*mod_data, 2);
> }
>
> // Is it possible?
> exists (0:r0=2 /\ 1:r0=0)
This result is indeed not possible. And yes, some sort of memory
barrier is needed in P0. But it doesn't have to be smp_mb(); you could
use a weaker barrier instead. For example, you could replace the
READ_ONCE in P0 with smp_load_acquire(), or you could replace the
WRITE_ONCE with smp_store_release(). Either of those changes would
suffice to prevent this outcome.
Alan
Re: UBSAN: array-index-out-of-bounds in alg_bind
On Sat, Oct 17, 2020 at 1:02 PM Jann Horn wrote: > > > > dashboard link: > > > > https://syzkaller.appspot.com/bug?extid=92ead4eb8e26a26d465e > > > > [...] > > > > Reported-by: syzbot+92ead4eb8e26a26d4...@syzkaller.appspotmail.com > > > > [...] > > > > UBSAN: array-index-out-of-bounds in crypto/af_alg.c:166:2 > > > > index 91 is out of range for type '__u8 [64]' > > > > > > This seems to be an "as intended", if very odd. false positive (the actual > > > memory area is backed by the on-stack _K_SS_MAXSIZE-sized sockaddr_storage > > > "address" variable in __sys_bind. But yes, af_alg's salg_name member > > > size here doesn't make sense. > > > > As Vegard noted elsewhere, compilers can start making assumptions > > based on absence of UB and compile code in surprising ways as the > > result leading to very serious and very real bugs. > > > > One example would be a compiler generating jump table for common sizes > > during PGO and leaving size > 64 as wild jump. > > > > Another example would be a compiler assuming that copy size <= 64. > > Then if there is another copy into a 64-byte buffer with a proper size > > check, the compiler can now drop that size check (since it now knows > > size <= 64) and we get real stack smash (for a copy that does have a > > proper size check before!). > > FWIW, the kernel currently still has a bunch of places that use > C89-style length-1 arrays (which were in the past used to work around > C89's lack of proper flexible arrays). Gustavo A. R. Silva has a bunch > of patches pending to change those places now, but those are not > marked for stable backporting; so in all currently released kernels, > we'll probably keep having length-1 arrays at the ends of C structs > that are used as if they were flexible arrays. (Unless someone makes > the case that these patches are not just cleanups but actually fix > some sort of real bug, and therefore need to be backported.) > > The code in this example looks just like one of those C89-style > length-1 arrays to me (except that the length isn't 1). > > Of course I do agree that this should be cleaned up, and that having > bogus array lengths in the source code is a bad idea. > > > And we do want compilers to be that smart today. Because of all levels > > of abstractions/macros/inlining we actually have lots of > > redundant/nonsensical code in the end after all inlining and > > expansions, and we do want compilers to infer things, remove redundant > > checks, etc so that we can have both nice abstract source code and > > efficient machine code at the same time. > > I guess that kinda leads to the question: Do we just need to fix the > kernel code here (which is comparatively easy), or do you think that > this is a sufficiently big problem that we need to go and somehow > change the actual UAPI headers here (e.g. by deprecating the existing > UAPI struct and making a new one with a different name)? Good question. What I wrote is not based on some concrete miscompilation at hand. I just meant that there are more things involved that may appear at first glance. Re proactively fixing UAPI, I would say if somebody is up to doing it now, I would say it's good and a right change. Otherwise delaying fixing it is also a reasonable strategy because (1) there are probably more such cases, (2) any work on enabling more optimizations, global optimizations, etc is only feasible if there is a tool that helps to identify all places that need to be fixed. So whoever/whenever will be fixing this, one more or one less case probably does not matter much. It's a different story if there is already a tool/compiler warning that traps on some code and that code harms deployment of the tool.
Re: [PATCH v2] HID: i2c-hid: add polling mode based on connected GPIO chip's pin status
> [...]
> >> >> +static int get_gpio_pin_state(struct irq_desc *irq_desc)
> >> >> +{
> >> >> + struct gpio_chip *gc =
> >> >> irq_data_get_irq_chip_data(&irq_desc->irq_data);
> >> >> +
> >> >> + return gc->get(gc, irq_desc->irq_data.hwirq);
> >> >> +}
> >> >> +
> >> >> +static bool interrupt_line_active(struct i2c_client *client)
> >> >> +{
> >> >> + unsigned long trigger_type = irq_get_trigger_type(client->irq);
> >> >> + struct irq_desc *irq_desc = irq_to_desc(client->irq);
> >> >> +
> >> >> + /*
> >> >> +* According to Windows Precsiontion Touchpad's specs
> >> >> +*
> >> >> https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-precision-touchpad-device-bus-connectivity,
> >> >> +* GPIO Interrupt Assertion Leve could be either ActiveLow or
> >> >> +* ActiveHigh.
> >> >> +*/
> >> >> + if (trigger_type & IRQF_TRIGGER_LOW)
> >> >> + return !get_gpio_pin_state(irq_desc);
> >> >> +
> >> >> + return get_gpio_pin_state(irq_desc);
> >> >> +}
> >> >
> >> >Excuse my ignorance, but I think some kind of error handling regarding
> >> >the return
> >> >value of `get_gpio_pin_state()` should be present here.
> >> >
> >> What kind of errors would you expect? It seems (struct gpio_chip *)->get
> >> only return 0 or 1.
> >> >
> >
> >I read the code of a couple gpio chips and - I may be wrong, but - it seems
> >they
> >can return an arbitrary errno.
> >
> I thought all GPIO chip return 0 or 1 since !!val is returned. I find
> an example which could return negative value,
>
Yes, when a function returns `int`, there is a very high chance that the return
value may be an errno.
> >
> >> >> +
> >> >> +static int i2c_hid_polling_thread(void *i2c_hid)
> >> >> +{
> >> >> + struct i2c_hid *ihid = i2c_hid;
> >> >> + struct i2c_client *client = ihid->client;
> >> >> + unsigned int polling_interval_idle;
> >> >> +
> >> >> + while (1) {
> >> >> + /*
> >> >> +* re-calculate polling_interval_idle
> >> >> +* so the module parameters polling_interval_idle_ms
> >> >> can be
> >> >> +* changed dynamically through sysfs as
> >> >> polling_interval_active_us
> >> >> +*/
> >> >> + polling_interval_idle = polling_interval_idle_ms * 1000;
> >> >> + if (test_bit(I2C_HID_READ_PENDING, &ihid->flags))
> >> >> + usleep_range(5, 10);
> >> >> +
> >> >> + if (kthread_should_stop())
> >> >> + break;
> >> >> +
> >> >> + while (interrupt_line_active(client)) {
> >> >
> >> >I realize it's quite unlikely, but can't this be a endless loop if data
> >> >is coming
> >> >in at a high enough rate? Maybe the maximum number of iterations could be
> >> >limited here?
> >> >
> >> If we find HID reports are constantly read and send to front-end
> >> application like libinput, won't it help expose the problem of the I2C
> >> HiD device?
> >> >
> >
> >I'm not sure I completely understand your point. The reason why I wrote what
> >I wrote
> >is that this kthread could potentially could go on forever (since
> >`kthread_should_stop()`
> >is not checked in the inner while loop) if the data is supplied at a high
> >enough rate.
> >That's why I said, to avoid this problem, only allow a certain number of
> >iterations
> >for the inner loop, to guarantee that the kthread can stop in any case.
> >
> I mean if "data is supplied at a high enough rate" does happen, this is
> an abnormal case and indicates a bug. So we shouldn't cover it up. We
> expect the user to report it to us.
> >
I agree in principle, but if this abnormal case ever occurs, that'll prevent
this module from being unloaded since `kthread_stop()` will hang because the
thread is "stuck" in the inner loop, never checking `kthread_should_stop()`.
That's why I think it makes sense to only allow a certain number of operations
for the inner loop, and maybe show a warning if that's exceeded:
for (i = 0; i < max_iter && interrupt_line_active(...); i++) {
}
WARN_ON[CE](i == max_iter[, "data is coming in at an unreasonably high rate"]);
or something like this, where `max_iter` could possibly be some value dependent
on
`polling_interval_active_us`, or even just a constant.
> >> >> + i2c_hid_get_input(ihid);
> >> >> + usleep_range(polling_interval_active_us,
> >> >> +polling_interval_active_us + 100);
> >> >> + }
> >> >> +
> >> >> + usleep_range(polling_interval_idle,
> >> >> +polling_interval_idle + 1000);
> >> >> + }
> >> >> +
> >> >> + do_exit(0);
> >> >> + return 0;
> >> >> +}
> [...]
> Thank you for offering your understandings on this patch. When I'm going
> to submit next version, I will add a "Signed-o
