[PATCH] x86_64: move cpu_current_top_of_stack out of TSS
From: Lai Jiangshan
When X86_BUG_CPU_MELTDOWN & KPTI, cpu_current_top_of_stack lives in the
TSS which is also in the user CR3 and it becomes a coveted fruit. An
attacker can fetch the kernel stack top from it and continue next steps
of actions based on the kernel stack.
The address might not be very usefull for attacker, but it is not so
necessary to be in TSS either. It is only accessed when CR3 is kernel CR3
and gs_base is kernel gs_base which means it can be in any percpu variable.
The major reason it is in TSS might be performance because it is hot in
cache and tlb since we just access sp2 as the scratch space in syscall.
So we can move it to a percpu variable near other hot percpu variables,
such as current_task, __preempt_count, and they are in the same
cache line.
tools/testing/selftests/seccomp/seccomp_benchmark desn't show any
performance lost in "getpid native" result. And actually, the result
changes from 93ns before patch to 92ns after patch when !KPTI, and the
test is very stable although the test desn't show a higher degree of
precision but enough to know it doesn't cause degression for the test.
Signed-off-by: Lai Jiangshan
---
arch/x86/include/asm/processor.h | 10 --
arch/x86/include/asm/switch_to.h | 7 +--
arch/x86/include/asm/thread_info.h | 6 --
arch/x86/kernel/cpu/common.c | 3 +++
arch/x86/kernel/process.c | 8 ++--
arch/x86/mm/pti.c | 7 +++
6 files changed, 9 insertions(+), 32 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index c20a52b5534b..886d32da1318 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -314,11 +314,6 @@ struct x86_hw_tss {
struct x86_hw_tss {
u32 reserved1;
u64 sp0;
-
- /*
-* We store cpu_current_top_of_stack in sp1 so it's always accessible.
-* Linux does not use ring 1, so sp1 is not otherwise needed.
-*/
u64 sp1;
/*
@@ -428,12 +423,7 @@ struct irq_stack {
DECLARE_PER_CPU(struct irq_stack *, hardirq_stack_ptr);
-#ifdef CONFIG_X86_32
DECLARE_PER_CPU(unsigned long, cpu_current_top_of_stack);
-#else
-/* The RO copy can't be accessed with this_cpu_xyz(), so use the RW copy. */
-#define cpu_current_top_of_stack cpu_tss_rw.x86_tss.sp1
-#endif
#ifdef CONFIG_X86_64
struct fixed_percpu_data {
diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index 9f69cc497f4b..4f0bc8533a54 100644
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -71,12 +71,7 @@ static inline void update_task_stack(struct task_struct
*task)
else
this_cpu_write(cpu_tss_rw.x86_tss.sp1, task->thread.sp0);
#else
- /*
-* x86-64 updates x86_tss.sp1 via cpu_current_top_of_stack. That
-* doesn't work on x86-32 because sp1 and
-* cpu_current_top_of_stack have different values (because of
-* the non-zero stack-padding on 32bit).
-*/
+ /* XENPV keeps its entry stack to be kernel stack. */
if (static_cpu_has(X86_FEATURE_XENPV))
load_sp0(task_top_of_stack(task));
#endif
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include/asm/thread_info.h
index 0d751d5da702..3dc93d8df425 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -197,12 +197,6 @@ static inline int arch_within_stack_frames(const void *
const stack,
#endif
}
-#else /* !__ASSEMBLY__ */
-
-#ifdef CONFIG_X86_64
-# define cpu_current_top_of_stack (cpu_tss_rw + TSS_sp1)
-#endif
-
#endif
#ifdef CONFIG_COMPAT
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 35ad8480c464..f3d7fd7e9684 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1745,6 +1745,9 @@ DEFINE_PER_CPU(unsigned int, irq_count) __visible = -1;
DEFINE_PER_CPU(int, __preempt_count) = INIT_PREEMPT_COUNT;
EXPORT_PER_CPU_SYMBOL(__preempt_count);
+DEFINE_PER_CPU(unsigned long, cpu_current_top_of_stack) = TOP_OF_INIT_STACK;
+EXPORT_PER_CPU_SYMBOL(cpu_current_top_of_stack);
+
/* May not be marked __init: used by software suspend */
void syscall_init(void)
{
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 145a7ac0c19a..7c4d0184a44a 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -63,14 +63,10 @@ __visible DEFINE_PER_CPU_PAGE_ALIGNED(struct tss_struct,
cpu_tss_rw) = {
*/
.sp0 = (1UL << (BITS_PER_LONG-1)) + 1,
- /*
-* .sp1 is cpu_current_top_of_stack. The init task never
-* runs user code, but cpu_current_top_of_stack should still
-* be well defined before the first context switch.
-*/
+#ifdef CONFIG_X86_32
+ /* .sp1 is used via TSS_entry2task_stack
[PATCH] mm/workingset.c: avoid unnecessary max_nodes estimation in count_shadow_nodes()
If list_lru_shrink_count is 0, we always return SHRINK_EMPTY regardless of the value of max_nodes. So we can return early if nodes == 0 to save some cpu cycles of approximating a reasonable limit for the nodes. Signed-off-by: Miaohe Lin --- mm/workingset.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/mm/workingset.c b/mm/workingset.c index 10e96de945b3..7db8f3dad13c 100644 --- a/mm/workingset.c +++ b/mm/workingset.c @@ -461,6 +461,8 @@ static unsigned long count_shadow_nodes(struct shrinker *shrinker, unsigned long pages; nodes = list_lru_shrink_count(_nodes, sc); + if (!nodes) + return SHRINK_EMPTY; /* * Approximate a reasonable limit for the nodes @@ -503,9 +505,6 @@ static unsigned long count_shadow_nodes(struct shrinker *shrinker, max_nodes = pages >> (XA_CHUNK_SHIFT - 3); - if (!nodes) - return SHRINK_EMPTY; - if (nodes <= max_nodes) return 0; return nodes - max_nodes; -- 2.19.1
Re: [PATCH 4.4 00/29] 4.4.253-rc2 review
On Fri, 22 Jan 2021 at 21:39, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.253 release. > There are 29 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, 24 Jan 2021 16:08:14 +. > 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.253-rc2.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.253-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 36175a29c09cfbebb243f8515f60b3805846fe70 git describe: v4.4.252-30-g36175a29c09c Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.4.y/build/v4.4.252-30-g36175a29c09c No regressions (compared to build v4.4.252) No fixes (compared to build v4.4.252) Ran 18438 total tests in the following environments and test suites. Environments -- - i386 - juno-r2 - arm64 - qemu-arm64-kasan - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - x15 - arm - x86_64 Test Suites --- * build * linux-log-parser * ltp-commands-tests * ltp-containers-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * network-basic-tests * v4l2-compliance * kvm-unit-tests * libhugetlbfs * 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-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-mm-tests * ltp-open-posix-tests * ltp-tracing-tests * ltp-syscalls-tests * ltp-controllers-tests * install-android-platform-tools-r2600 * perf * fwts Summary kernel: 4.4.253-rc2 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.253-rc2-hikey-20210122-904 git commit: de349d25fddae8bf11ff5dc914076c9c021e0505 git describe: 4.4.253-rc2-hikey-20210122-904 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.253-rc2-hikey-20210122-904 No regressions (compared to build 4.4.253-rc1-hikey-20210118-900) No fixes (compared to build 4.4.253-rc1-hikey-20210118-900) Ran 1761 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] RISC-V: probes: Treat the instruction stream as host-endian
Acked-by: Guo Ren
On 2021/1/23 上午11:34, Palmer Dabbelt wrote:
From: Palmer Dabbelt
Neither of these are actually correct: the instruction stream is defined
(for versions of the ISA manual newer than 2.2) as a stream of 16-bit
little-endian parcels, which is different than just being little-endian.
In theory we should represent this as a type, but we don't have any
concrete plans for the big endian stuff so it doesn't seem worth the
time -- we've got variants of this all over the place.
Instead I'm just dropping the unnecessary type conversion, which is a
NOP on LE systems but causes an sparse error as the types are all mixed
up.
Reported-by: kernel test robot
Signed-off-by: Palmer Dabbelt
---
arch/riscv/kernel/probes/decode-insn.c | 2 +-
arch/riscv/kernel/probes/kprobes.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/kernel/probes/decode-insn.c
b/arch/riscv/kernel/probes/decode-insn.c
index 0876c304ca77..0ed043acc882 100644
--- a/arch/riscv/kernel/probes/decode-insn.c
+++ b/arch/riscv/kernel/probes/decode-insn.c
@@ -16,7 +16,7 @@
enum probe_insn __kprobes
riscv_probe_decode_insn(probe_opcode_t *addr, struct arch_probe_insn *api)
{
- probe_opcode_t insn = le32_to_cpu(*addr);
+ probe_opcode_t insn = *addr;
/*
* Reject instructions list:
diff --git a/arch/riscv/kernel/probes/kprobes.c
b/arch/riscv/kernel/probes/kprobes.c
index e60893bd87db..a2ec18662fee 100644
--- a/arch/riscv/kernel/probes/kprobes.c
+++ b/arch/riscv/kernel/probes/kprobes.c
@@ -57,7 +57,7 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
}
/* copy instruction */
- p->opcode = le32_to_cpu(*p->addr);
+ p->opcode = *p->addr;
/* decode instruction */
switch (riscv_probe_decode_insn(p->addr, >ainsn.api)) {
[PATCH] mm/rmap: Correct some obsolete comments of anon_vma
The commit 2b575eb64f7a ("mm: convert anon_vma->lock to a mutex") changed
spinlock used to serialize access to vma list to mutex. And further, the
commit 5a505085f043 ("mm/rmap: Convert the struct anon_vma::mutex to an
rwsem") converted the mutex to an rwsem for solving scalability problem. So
replace spinlock with rwsem to make comment uptodate.
Signed-off-by: Miaohe Lin
---
mm/rmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/rmap.c b/mm/rmap.c
index e26ae119a131..f6f43620cd97 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -168,7 +168,7 @@ static void anon_vma_chain_link(struct vm_area_struct *vma,
*
* Anon-vma allocations are very subtle, because we may have
* optimistically looked up an anon_vma in page_lock_anon_vma_read()
- * and that may actually touch the spinlock even in the newly
+ * and that may actually touch the rwsem even in the newly
* allocated vma (it depends on RCU to make sure that the
* anon_vma isn't actually destroyed).
*
@@ -359,7 +359,7 @@ int anon_vma_fork(struct vm_area_struct *vma, struct
vm_area_struct *pvma)
goto out_error_free_anon_vma;
/*
-* The root anon_vma's spinlock is the lock actually used when we
+* The root anon_vma's rwsem is the lock actually used when we
* lock any of the anon_vmas in this anon_vma tree.
*/
anon_vma->root = pvma->anon_vma->root;
--
2.19.1
Re: [PATCH 4.9 00/33] 4.9.253-rc2 review
On Sat, 23 Jan 2021 at 12:27, Naresh Kamboju wrote: > > On Fri, 22 Jan 2021 at 21:40, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 4.9.253 release. > > There are 33 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, 24 Jan 2021 16:08:20 +. > > 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.253-rc2.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.253-rc2 > git repo: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > git branch: linux-4.9.y > git commit: a4108af7f0fa9a58f591ef0bdc78216746dacbd5 > git describe: v4.9.252-34-ga4108af7f0fa > Test details: > https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.9.y/build/v4.9.252-34-ga4108af7f0fa > > No regressions (compared to build v4.9.252-36-g2d7bd2c1841b) > > No fixes (compared to build v4.9.252-36-g2d7bd2c1841b) > > Ran 39925 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-arm64-kasan > - qemu-x86_64-kasan > - qemu_arm > - qemu_arm64 > - qemu_arm64-compat > - qemu_i386 > - qemu_x86_64 > - qemu_x86_64-compat > - x15 - arm > - x86_64 > - x86-kasan > > Test Suites > --- > * build > * linux-log-parser > * ltp-commands-tests > * ltp-containers-tests > * ltp-hugetlb-tests > * ltp-ipc-tests > * ltp-math-tests > * ltp-mm-tests > * ltp-syscalls-tests > * fwts > * install-android-platform-tools-r2600 > * libhugetlbfs > * ltp-cap_bounds-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-io-tests > * ltp-nptl-tests > * ltp-pty-tests > * ltp-sched-tests > * ltp-securebits-tests > * ltp-tracing-tests > * network-basic-tests > * perf > * v4l2-compliance > * ltp-open-posix-tests > * kvm-unit-tests > > -- > Linaro LKFT > https://lkft.linaro.org
Re: [PATCH 4.14 00/48] 4.14.217-rc2 review
On Sat, 23 Jan 2021 at 12:03, Naresh Kamboju wrote: > > On Fri, 22 Jan 2021 at 21:40, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 4.14.217 release. > > There are 48 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, 24 Jan 2021 16:08:17 +. > > 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.217-rc2.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.217-rc2 > git repo: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > git branch: linux-4.14.y > git commit: 10fddc03bd61fb44e84e0fd3550f78e950cbe2a2 > git describe: v4.14.216-49-g10fddc03bd61 > Test details: > https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.216-49-g10fddc03bd61 > > > No regressions (compared to build v4.14.216) > > No fixes (compared to build v4.14.216) > > Ran 39231 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-arm64-kasan > - qemu-x86_64-kasan > - qemu_arm > - qemu_arm64 > - qemu_arm64-compat > - qemu_i386 > - qemu_x86_64 > - qemu_x86_64-compat > - 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-controllers-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-io-tests > * ltp-math-tests > * ltp-sched-tests > * ltp-syscalls-tests > * perf > * fwts > * ltp-containers-tests > * ltp-fs-tests > * ltp-hugetlb-tests > * ltp-ipc-tests > * ltp-mm-tests > * ltp-nptl-tests > * ltp-pty-tests > * ltp-securebits-tests > * ltp-tracing-tests > * v4l2-compliance > * ltp-open-posix-tests > * network-basic-tests > * kvm-unit-tests > * rcutorture > > -- > Linaro LKFT > https://lkft.linaro.org
Re: [PATCH 4.19 00/22] 4.19.170-rc1 review
On Sat, 23 Jan 2021 at 11:34, Naresh Kamboju wrote: > > On Fri, 22 Jan 2021 at 19:45, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 4.19.170 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, 24 Jan 2021 13:57:23 +. > > 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.170-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.170-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: 6cb90163efb77ad3afe6d40720f0b7cdd0a94812 > git describe: v4.19.169-23-g6cb90163efb7 > Test details: > https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.169-23-g6cb90163efb7 > > > No regressions (compared to build v4.19.169) > > > No fixes (compared to build v4.19.169) > > Ran 46904 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 > - nxp-ls2088 > - qemu-arm64-clang > - qemu-arm64-kasan > - qemu-x86_64-clang > - qemu-x86_64-kasan > - qemu_arm > - qemu_arm64 > - qemu_arm64-compat > - qemu_i386 > - qemu_x86_64 > - qemu_x86_64-compat > - x15 - arm > - x86_64 > - x86-kasan > > Test Suites > --- > * build > * install-android-platform-tools-r2600 > * linux-log-parser > * ltp-containers-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-tracing-tests > * perf > * fwts > * kselftest > * kvm-unit-tests > * libhugetlbfs > * ltp-cap_bounds-tests > * ltp-commands-tests > * ltp-cpuhotplug-tests > * ltp-crypto-tests > * ltp-ipc-tests > * ltp-math-tests > * ltp-nptl-tests > * ltp-pty-tests > * ltp-securebits-tests > * ltp-syscalls-tests > * network-basic-tests > * v4l2-compliance > * ltp-controllers-tests > * ltp-fs-tests > * ltp-open-posix-tests > * ltp-sched-tests > * rcutorture > * kselftest-vsyscall-mode-native > * kselftest-vsyscall-mode-none > > -- > Linaro LKFT > https://lkft.linaro.org
Re: [PATCH 5.4 00/33] 5.4.92-rc1 review
On Sat, 23 Jan 2021 at 11:27, Naresh Kamboju wrote: > > On Fri, 22 Jan 2021 at 19:47, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 5.4.92 release. > > There are 33 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, 24 Jan 2021 13:57:23 +. > > 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.92-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.92-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: eb6c2292de97c5c4e51d98767b4c7acaef0522ec > git describe: v5.4.91-34-geb6c2292de97 > Test details: > https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.91-34-geb6c2292de97 > > > No regressions (compared to build v5.4.91) > > > No fixes (compared to build v5.4.91) > > Ran 53090 total tests in the following environments and test suites. > > Environments > -- > - dragonboard-410c > - hi6220-hikey > - i386 > - juno-r2 > - juno-r2-compat > - juno-r2-kasan > - nxp-ls2088 > - qemu-arm-clang > - qemu-arm64-clang > - qemu-arm64-kasan > - qemu-x86_64-clang > - qemu-x86_64-kasan > - qemu-x86_64-kcsan > - qemu_arm > - qemu_arm64 > - qemu_arm64-compat > - qemu_i386 > - qemu_x86_64 > - qemu_x86_64-compat > - x15 > - x86 > - x86-kasan > > Test Suites > --- > * build > * igt-gpu-tools > * install-android-platform-tools-r2600 > * kselftest > * libhugetlbfs > * linux-log-parser > * ltp-cap_bounds-tests > * ltp-containers-tests > * ltp-cpuhotplug-tests > * ltp-crypto-tests > * ltp-cve-tests > * ltp-dio-tests > * ltp-fs-tests > * ltp-hugetlb-tests > * ltp-io-tests > * ltp-mm-tests > * ltp-syscalls-tests > * perf > * v4l2-compliance > * fwts > * kvm-unit-tests > * ltp-commands-tests > * ltp-controllers-tests > * ltp-fcntl-locktests-tests > * ltp-filecaps-tests > * ltp-fs_bind-tests > * ltp-fs_perms_simple-tests > * ltp-fsx-tests > * ltp-ipc-tests > * ltp-math-tests > * ltp-nptl-tests > * ltp-pty-tests > * ltp-securebits-tests > * ltp-tracing-tests > * network-basic-tests > * ltp-open-posix-tests > * ltp-sched-tests > * rcutorture > * kselftest-vsyscall-mode-native > * kselftest-vsyscall-mode-none > > -- > Linaro LKFT > https://lkft.linaro.org
Re: [PATCH 5.10 00/43] 5.10.10-rc1 review
On Sat, 23 Jan 2021 at 11:14, Naresh Kamboju wrote: > > On Fri, 22 Jan 2021 at 19:49, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 5.10.10 release. > > There are 43 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, 24 Jan 2021 13:57:23 +. > > 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.10.10-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.10.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.10.10-rc1 > git repo: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > git branch: linux-5.10.y > git commit: 402284178c914c87fd7b41bc9bd93f2772c43904 > git describe: v5.10.9-44-g402284178c91 > Test details: > https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.9-44-g402284178c91 > > > No regressions (compared to build v5.10.9) > > > No fixes (compared to build v5.10.9) > > Ran 55124 total tests in the following environments and test suites. > > Environments > -- > - dragonboard-410c > - hi6220-hikey > - i386 > - juno-r2 > - juno-r2-compat > - juno-r2-kasan > - nxp-ls2088 > - qemu-arm-clang > - qemu-arm64-clang > - qemu-arm64-kasan > - qemu-i386-clang > - qemu-x86_64-clang > - qemu-x86_64-kasan > - qemu-x86_64-kcsan > - qemu_arm > - qemu_arm64 > - qemu_arm64-compat > - qemu_i386 > - qemu_x86_64 > - qemu_x86_64-compat > - x15 > - x86 > - x86-kasan > > Test Suites > --- > * build > * igt-gpu-tools > * install-android-platform-tools-r2600 > * libhugetlbfs > * linux-log-parser > * ltp-commands-tests > * ltp-containers-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-sched-tests > * ltp-tracing-tests > * fwts > * kselftest > * ltp-cap_bounds-tests > * ltp-cpuhotplug-tests > * ltp-crypto-tests > * ltp-nptl-tests > * ltp-pty-tests > * ltp-securebits-tests > * ltp-syscalls-tests > * network-basic-tests > * perf > * ltp-controllers-tests > * ltp-open-posix-tests > * v4l2-compliance > * kvm-unit-tests > * kunit > * rcutorture > * kselftest-vsyscall-mode-native > * kselftest-vsyscall-mode-none > > -- > Linaro LKFT > https://lkft.linaro.org
Re: [PATCH] drivers: dma: qcom: bam_dma: Manage clocks when controlled_remotely is set
On Fri, Jan 22, 2021 at 10:44:09AM -0500, Thara Gopinath wrote: > Hi Shawn, > > Thanks for the review > > On 1/22/21 12:10 AM, Shawn Guo wrote: > > On Thu, Jan 21, 2021 at 09:52:51PM -0500, Thara Gopinath wrote: > > > When bam dma is "controlled remotely", thus far clocks were not controlled > > > from the Linux. In this scenario, Linux was disabling runtime pm in bam > > > dma > > > driver and not doing any clock management in suspend/resume hooks. > > > > > > With introduction of crypto engine bam dma, the clock is a rpmh resource > > > that can be controlled from both Linux and TZ/remote side. Now bam dma > > > clock is getting enabled during probe even though the bam dma can be > > > "controlled remotely". But due to clocks not being handled properly, > > > bam_suspend generates a unbalanced clk_unprepare warning during system > > > suspend. > > > > > > To fix the above issue and to enable proper clock-management, this patch > > > enables runtim-pm and handles bam dma clocks in suspend/resume hooks if > > > the clock node is present irrespective of controlled_remotely property. > > > > Shouldn't the following probe code need some update? Now we have both > > controlled_remotely and clocks handle for cryptobam node. For example, > > if devm_clk_get() returns -EPROBE_DEFER, we do not want to continue with > > bamclk forcing to be NULL, right? > > We still will have to set bdev->bamclk to NULL in certain scenarios. For eg > slimbus bam dma is controlled-remotely and the clocks are handled by the > remote s/w. Linux does not handle the clocks at all and there is no clock > specified in the dt node.This is the norm for the devices that are also > controlled by remote s/w. Crypto bam dma is a special case where the clock > is actually a rpmh resource and hence can be independently handled from both > remote side and Linux by voting. In this case, the dma is controlled > remotely but clock can be turned off and on in Linux. Hence the need for > this patch. So is it correct to say that clock is mandatory for !controlled-remotely BAM, while it's optional for controlled-remotely one. If yes, maybe we can do something like below to make the code a bit easier to read? if (controlled-remotely) bdev->bamclk = devm_clk_get_optional(); else bdev->bamclk = devm_clk_get(); > Yes, the probe code needs updating to handle -EPROBE_DEFER (esp if the clock > driver is built in as a module) I am not sure if the clock framework handles > -EPROBE_DEFER properly either. So that > might need updating too. This is a separate activity and not part of this > patch. As the patch breaks the assumption that for controlled-remotely BAM there is no clock to be managed, the probe code becomes buggy right away. Shawn
[PATCH] mm/early_ioremap.c: Use __func__ instead of function name
It is better to use __func__ instead of function name. Signed-off-by: Stephen Zhang --- mm/early_ioremap.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/mm/early_ioremap.c b/mm/early_ioremap.c index a0018ad..164607c 100644 --- a/mm/early_ioremap.c +++ b/mm/early_ioremap.c @@ -181,17 +181,17 @@ void __init early_iounmap(void __iomem *addr, unsigned long size) } } - if (WARN(slot < 0, "early_iounmap(%p, %08lx) not found slot\n", -addr, size)) + if (WARN(slot < 0, "%s(%p, %08lx) not found slot\n", + __func__, addr, size)) return; if (WARN(prev_size[slot] != size, -"early_iounmap(%p, %08lx) [%d] size not consistent %08lx\n", -addr, size, slot, prev_size[slot])) +"%s(%p, %08lx) [%d] size not consistent %08lx\n", + __func__, addr, size, slot, prev_size[slot])) return; - WARN(early_ioremap_debug, "early_iounmap(%p, %08lx) [%d]\n", -addr, size, slot); + WARN(early_ioremap_debug, "%s(%p, %08lx) [%d]\n", + __func__, addr, size, slot); virt_addr = (unsigned long)addr; if (WARN_ON(virt_addr < fix_to_virt(FIX_BTMAP_BEGIN))) -- 1.8.3.1
[PATCH] mm/page_owner: Use helper function zone_end_pfn() to get end_pfn
Commit 108bcc96ef70 ("mm: add & use zone_end_pfn() and zone_spans_pfn()")
introduced the helper zone_end_pfn() to calculate the zone end pfn. But
pagetypeinfo_showmixedcount_print forgot to use it. And the initialization
of local variable pfn is duplicated, remove one.
Signed-off-by: Miaohe Lin
---
mm/page_owner.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/page_owner.c b/mm/page_owner.c
index af464bb7fbe7..d15c7c4994f5 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -263,8 +263,8 @@ void pagetypeinfo_showmixedcount_print(struct seq_file *m,
struct page *page;
struct page_ext *page_ext;
struct page_owner *page_owner;
- unsigned long pfn = zone->zone_start_pfn, block_end_pfn;
- unsigned long end_pfn = pfn + zone->spanned_pages;
+ unsigned long pfn, block_end_pfn;
+ unsigned long end_pfn = zone_end_pfn(zone);
unsigned long count[MIGRATE_TYPES] = { 0, };
int pageblock_mt, page_mt;
int i;
--
2.19.1
[PATCH] Input: ti_am335x_tsc - fix spelling mistake
From: liumingyu fix typo "postion" -> "position" Signed-off-by: liumingyu --- drivers/input/touchscreen/ti_am335x_tsc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c index 83e6855..d77555e 100644 --- a/drivers/input/touchscreen/ti_am335x_tsc.c +++ b/drivers/input/touchscreen/ti_am335x_tsc.c @@ -310,7 +310,7 @@ static irqreturn_t titsc_irq(int irq, void *dev) /* * Calculate pressure using formula * Resistance(touch) = x plate resistance * -* x postion/4096 * ((z2 / z1) - 1) +* x position/4096 * ((z2 / z1) - 1) */ z = z1 - z2; z *= x; -- 1.9.1
Re: [PATCH 4.9 00/33] 4.9.253-rc2 review
On Fri, 22 Jan 2021 at 21:40, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.253 release. > There are 33 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, 24 Jan 2021 16:08:20 +. > 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.253-rc2.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. Summary kernel: 4.9.253-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: a4108af7f0fa9a58f591ef0bdc78216746dacbd5 git describe: v4.9.252-34-ga4108af7f0fa Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.9.y/build/v4.9.252-34-ga4108af7f0fa No regressions (compared to build v4.9.252-36-g2d7bd2c1841b) No fixes (compared to build v4.9.252-36-g2d7bd2c1841b) Ran 39925 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-arm64-kasan - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * linux-log-parser * ltp-commands-tests * ltp-containers-tests * ltp-hugetlb-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-syscalls-tests * fwts * install-android-platform-tools-r2600 * libhugetlbfs * ltp-cap_bounds-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-io-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-tracing-tests * network-basic-tests * perf * v4l2-compliance * ltp-open-posix-tests * kvm-unit-tests -- Linaro LKFT https://lkft.linaro.org
Re: BUG: MAX_LOCKDEP_KEYS too low!
On 23/01/2021 17:01, Hillf Danton wrote:
On Sat, 23 Jan 2021 09:53:42 +1100 Alexey Kardashevskiy wrote:
On 23/01/2021 02:30, Tetsuo Handa wrote:
On 2021/01/22 22:28, Tetsuo Handa wrote:
On 2021/01/22 21:10, Dmitry Vyukov wrote:
On Fri, Jan 22, 2021 at 1:03 PM Alexey Kardashevskiy wrote:
On 22/01/2021 21:30, Tetsuo Handa wrote:
On 2021/01/22 18:16, Dmitry Vyukov wrote:
The reproducer only does 2 bpf syscalls, so something is slowly leaking in bpf.
My first suspect would be one of these. Since workqueue is async, it
may cause such slow drain that happens only when tasks are spawned
fast. I don't know if there is a procfs/debugfs introspection file to
monitor workqueue lengths to verify this hypothesis.
If you can reproduce locally, you can call show_workqueue_state()
(part of SysRq-t) when hitting the limit.
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -1277,6 +1277,7 @@ register_lock_class(struct lockdep_map *lock, unsigned
int subclass, int force)
print_lockdep_off("BUG: MAX_LOCKDEP_KEYS too low!");
dump_stack();
+ show_workqueue_state();
return NULL;
}
nr_lock_classes++;
Here is the result:
https://pastebin.com/rPn0Cytu
Do you mind posting this publicly?
Yes, it seems that bpf_map_free_deferred is the problem (11138
outstanding callbacks).
Need to set up a local queue for releasing bpf maps if 10,000 means
flooding.
Wow. Horribly stuck queue. I guess BPF wants to try WQ created by
alloc_workqueue("bpf_free_wq", WQ_MEM_RECLAIM | WQ_HIGHPRI | WQ_UNBOUND, 0);
rather than system_wq . You can add Tejun Heo for WQ.
Anyway, please post your result to ML.
https://pastebin.com/JfrmzguK is with the patch below applied. Seems
less output. Interestingly when I almost hit "send", OOM kicked in and
tried killing a bunch of "maxlockdep" processes (my test case):
[ 891.037315] [ 31007] 0 31007 2815491520
1000 maxlockdep
[ 891.037540] [ 31009] 0 31009 2815491520
1000 maxlockdep
[ 891.037760] [ 31012] 0 31012 2815491520
1000 maxlockdep
[ 891.037980] [ 31013] 0 31013 2815471040
0 maxlockdep
[ 891.038210] [ 31014] 0 31014 2815491520
1000 maxlockdep
[ 891.038429] [ 31018] 0 31018 2815471040
0 maxlockdep
[ 891.038652] [ 31019] 0 31019 2815491520
1000 maxlockdep
[ 891.038874] [ 31020] 0 31020 2815491520
1000 maxlockdep
[ 891.039095] [ 31021] 0 31021 2815491520
1000 maxlockdep
[ 891.039317] [ 31022] 0 31022 2815471040
0 maxlockdep
A local queue, the mix of list head and spin lock, helps to collapse
the entities of map->work into one work in order to cut the risk of
work flooding to WQ.
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -448,16 +448,40 @@ static void bpf_map_release_memcg(struct
}
#endif
-/* called from workqueue */
+static int worker_idle = 1;
+static LIST_HEAD(bpf_map_work_list);
+static DEFINE_SPINLOCK(bpf_map_work_lock);
+
static void bpf_map_free_deferred(struct work_struct *work)
{
- struct bpf_map *map = container_of(work, struct bpf_map, work);
+ struct bpf_map *map;
+
+ worker_idle = 0;
+again:
+ map = NULL;
+ spin_lock_irq(_map_work_lock);
+
+ if (!list_empty(_map_work_list)) {
+ map = list_first_entry(_map_work_list, struct bpf_map,
+ work_list);
+ list_del_init(>work_list);
+ } else
+ worker_idle = 1;
+
+ spin_unlock_irq(_map_work_lock);
+
+ if (!map)
+ return;
security_bpf_map_free(map);
bpf_map_release_memcg(map);
/* implementation dependent freeing */
map->ops->map_free(map);
+
+ cond_resched();
+ goto again;
}
+static DECLARE_WORK(bpf_map_release_work, bpf_map_free_deferred);
static void bpf_map_put_uref(struct bpf_map *map)
{
@@ -473,11 +497,20 @@ static void bpf_map_put_uref(struct bpf_
static void __bpf_map_put(struct bpf_map *map, bool do_idr_lock)
{
if (atomic64_dec_and_test(>refcnt)) {
+ unsigned long flags;
+ int idle;
+
/* bpf_map_free_id() must be called first */
bpf_map_free_id(map, do_idr_lock);
btf_put(map->btf);
- INIT_WORK(>work, bpf_map_free_deferred);
- schedule_work(>work);
+
+ spin_lock_irqsave(_map_work_lock, flags);
+ idle = worker_idle;
+ list_add(>work_list, _map_work_list);
+
Re: [PATCH 4.14 00/48] 4.14.217-rc2 review
On Fri, 22 Jan 2021 at 21:40, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.217 release. > There are 48 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, 24 Jan 2021 16:08:17 +. > 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.217-rc2.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. Summary kernel: 4.14.217-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: 10fddc03bd61fb44e84e0fd3550f78e950cbe2a2 git describe: v4.14.216-49-g10fddc03bd61 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.216-49-g10fddc03bd61 No regressions (compared to build v4.14.216) No fixes (compared to build v4.14.216) Ran 39231 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-arm64-kasan - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - 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-controllers-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-io-tests * ltp-math-tests * ltp-sched-tests * ltp-syscalls-tests * perf * fwts * ltp-containers-tests * ltp-fs-tests * ltp-hugetlb-tests * ltp-ipc-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * ltp-tracing-tests * v4l2-compliance * ltp-open-posix-tests * network-basic-tests * kvm-unit-tests * rcutorture -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v5 00/10] sunxi: Support IRQ wakeup from deep sleep
On 1/22/21 4:47 AM, Maxime Ripard wrote:
> On Thu, Jan 21, 2021 at 07:33:54PM -0600, Samuel Holland wrote:
>> On 1/21/21 2:35 PM, Marc Zyngier wrote:
>>> On Sun, 17 Jan 2021 23:50:30 -0600, Samuel Holland wrote:
Allwinner sun6i/sun8i/sun50i SoCs (A31 and newer) have two interrupt
controllers: GIC and R_INTC. GIC does not support wakeup. R_INTC handles
the external NMI pin, and provides 32+ IRQs to the ARISC. The first 16
of these correspond 1:1 to a block of GIC IRQs starting with the NMI.
The last 13-16 multiplex the first (up to) 128 GIC SPIs.
This series replaces the existing chained irqchip driver that could only
control the NMI, with a stacked irqchip driver that also provides wakeup
capability for those multiplexed SPI IRQs. The idea is to preconfigure
the ARISC's IRQ controller, and then the ARISC firmware knows to wake up
as soon as it receives an IRQ. It can also decide how deep it can
suspend based on the enabled wakeup IRQs.
[...]
>>>
>>> Applied to irq/irqchip-5.12, thanks!
>>>
>>> [01/10] dt-bindings: irq: sun6i-r: Split the binding from sun7i-nmi
>>> commit: ad6b47cdef760410311f41876b21eb0c6fda4717
>>> [02/10] dt-bindings: irq: sun6i-r: Add a compatible for the H3
>>> commit: 6436eb4417094ea3308b33d8392fc02a1068dc78
>>> [03/10] irqchip/sun6i-r: Use a stacked irqchip driver
>>> commit: 4e34614636b31747b190488240a95647c227021f
>>> [04/10] irqchip/sun6i-r: Add wakeup support
>>> commit: 7ab365f6cd6de1e2b0cb1e1e3873dbf68e6f1003
>>>
>>> Please route the dts patches via the soc tree. Also, I had to
>>> manually fix the first patch as it wouldn't apply on top of
>>> 5.11-rc4 (which tree has it been diffed against?). Please
>>> check that the resolution is correct.
>>
>> This series was based on sunxi/for-next, which contains commit
>> 752b0aac99c7 ("dt-bindings: irq: sun7i-nmi: Add binding documentation
>> for the V3s NMI")[1].
>
> I assume merging the DT bits alone would break things? If so, I guess we
> can wait for 5.12 to be released before merging it
Patch 5 does not depend on the new driver, so it could be merged at any
time. Yes, the remaining patches would break things if merged without
the driver.
Cheers,
Samuel
[PATCH] nfc: fix typo
From: wengjianfeng change 'regster' to 'register' Signed-off-by: wengjianfeng --- drivers/nfc/trf7970a.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c index c70f62fe..3397802 100644 --- a/drivers/nfc/trf7970a.c +++ b/drivers/nfc/trf7970a.c @@ -169,7 +169,7 @@ /* Bits determining whether its a direct command or register R/W, * whether to use a continuous SPI transaction or not, and the actual - * direct cmd opcode or regster address. + * direct cmd opcode or register address. */ #define TRF7970A_CMD_BIT_CTRL BIT(7) #define TRF7970A_CMD_BIT_RWBIT(6) -- 1.9.1
Re: question about bonding mode 4
Ping...
Any comments? Thanks!
On 2021/1/15 10:02, moyufeng wrote:
> Hi Team,
>
> I have a question about bonding. During testing bonding mode 4
> scenarios, I find that there is a very low probability that
> the pointer is null. The following information is displayed:
>
> [99359.795934] bond0: (slave eth13.2001): Port 2 did not find a suitable
> aggregator
> [99359.796960] Unable to handle kernel NULL pointer dereference at virtual
> address 0020
> [99359.798127] Mem abort info:
> [99359.798526] ESR = 0x9604
> [99359.798938] EC = 0x25: DABT (current EL), IL = 32 bits
> [99359.799673] SET = 0, FnV = 0
> [99359.800106] EA = 0, S1PTW = 0
> [99359.800554] Data abort info:
> [99359.800952] ISV = 0, ISS = 0x0004
> [99359.801522] CM = 0, WnR = 0
> [99359.801970] user pgtable: 4k pages, 48-bit VAs, pgdp=c64e6000
> [99359.802876] [0020] pgd=
> [99359.803555] Internal error: Oops: 9604 [#1] PREEMPT SMP
> [99359.804369] Modules linked in: bonding hns3(-) hclgevf hnae3 [last
> unloaded: bonding]
> [99359.805494] CPU: 1 PID: 951 Comm: kworker/u10:2 Not tainted 5.7.0-rc4+ #1
> [99359.806455] Hardware name: linux,dummy-virt (DT)
> [99359.807107] Workqueue: bond0 bond_3ad_state_machine_handler [bonding]
> [99359.808056] pstate: 60c5 (nZCv daif +PAN +UAO)
> [99359.808722] pc : bond_3ad_state_machine_handler+0x7fc/0xdb8 [bonding]
> [99359.809652] lr : bond_3ad_state_machine_handler+0x7f4/0xdb8 [bonding]
> [99359.810535] sp : 80001882bd20
> [99359.811012] x29: 80001882bd20 x28: 85939a38
> [99359.811791] x27: 8649bb68 x26: aaab
> [99359.812871] x25: 89401000 x24: 89408de4
> [99359.814049] x23: 80001882bd98 x22: 8649b880
> [99359.815210] x21: x20: 85939a00
> [99359.816401] x19: 8649b880 x18: 800012572988
> [99359.817637] x17: x16:
> [99359.818870] x15: 80009882b987 x14: 726f746167657267
> [99359.820090] x13: 676120656c626174 x12: 697573206120646e
> [99359.821374] x11: 696620746f6e2064 x10: 696420322074726f
> [99359.822659] x9 : 50203a2931303032 x8 : 00081391
> [99359.823891] x7 : 8000108e3ad0 x6 : 8000128858bb
> [99359.825109] x5 : x4 :
> [99359.826262] x3 : x2 : 906b329bb5362a00
> [99359.827394] x1 : 906b329bb5362a00 x0 :
> [99359.828540] Call trace:
> [99359.829071] bond_3ad_state_machine_handler+0x7fc/0xdb8 [bonding]
> [99359.830367] process_one_work+0x15c/0x4a0
> [99359.831216] worker_thread+0x50/0x478
> [99359.832022] kthread+0x130/0x160
> [99359.832716] ret_from_fork+0x10/0x18
> [99359.833487] Code: 910c0021 95f704bb f9403f80 b5ffe300 (f9401000)
> [99359.834742] ---[ end trace c7a8e02914afc4e0 ]---
> [99359.835817] Kernel panic - not syncing: Fatal exception in interrupt
> [99359.837334] SMP: stopping secondary CPUs
> [99359.838277] Kernel Offset: disabled
> [99359.839086] CPU features: 0x080002,22208218
> [99359.840053] Memory Limit: none
> [99359.840783] ---[ end Kernel panic - not syncing: Fatal exception in
> interrupt ]---
>
> The test procedure is as follows:
> 1. Configure bonding and set it to mode 4.
> echo "4" > /sys/class/net/bond0/bonding/mode
> ifconfig bond0 up
>
> 2. Configure two VLANs and add them to the bonding in step 1.
> vconfig add eth0 2001
> vconfig add eth1 2001
> ifenslave bond0 eth0.2001 eth1.2001
>
> 3. Unload the network device driver and bonding driver.
> rmmod hns3
> rmmod hclge
> rmmod hnae3
> rmmod bonding.ko
>
> 4. Repeat the preceding steps for a long time.
>
> By checking the logic in ad_port_selection_logic(), I find that
> if enter the branch "Port %d did not find a suitable aggregator",
> the value of port->aggregator will be NULL, causing the problem.
>
> So I'd like to ask what circumstances will be involved in this
> branch, and what should be done in this case?
>
>
> The detailed code analysis is as follows:
>
> static void ad_port_selection_logic(struct port *port, bool *update_slave_arr)
> {
> [...]
> /* if the port is connected to other aggregator, detach it */
> if (port->aggregator) {
> /* detach the port from its former aggregator */
> temp_aggregator = port->aggregator;
> for (curr_port = temp_aggregator->lag_ports; curr_port;
>last_port = curr_port,
>curr_port = curr_port->next_port_in_aggregator) {
> if (curr_port == port) {
> temp_aggregator->num_of_ports--;
> /* if it is the first port attached to the
>* aggregator
>*/
> if (!last_port) {
> temp_aggregator->lag_ports =
>
Re: [PATCH v2 5/6] hwmon: (lm70) Avoid undefined reference to match table
On 1/22/21 7:44 PM, Stephen Boyd wrote:
> We're going to remove of_match_ptr() from the definition of
> of_match_device() when CONFIG_OF=n. This way we can always be certain
> that of_match_device() acts the same when CONFIG_OF is set and when it
> isn't. Add of_match_ptr() here so that this doesn't break when that
> change is made to the of_match_device() API.
>
> Signed-off-by: Stephen Boyd
> Acked-by: Guenter Roeck
> Cc: Arnd Bergmann
> Cc: Geert Uytterhoeven
> Cc: Jean Delvare
> Cc: Guenter Roeck
> Cc: Rob Herring
> Cc: Frank Rowand
> Cc:
> ---
>
> Please ack so Rob can apply.
>
This patch already has my Acked-by: above.
Guenter
> drivers/hwmon/lm70.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwmon/lm70.c b/drivers/hwmon/lm70.c
> index ae2b84263a44..e3153ae80634 100644
> --- a/drivers/hwmon/lm70.c
> +++ b/drivers/hwmon/lm70.c
> @@ -178,7 +178,7 @@ static int lm70_probe(struct spi_device *spi)
> struct lm70 *p_lm70;
> int chip;
>
> - of_match = of_match_device(lm70_of_ids, >dev);
> + of_match = of_match_device(of_match_ptr(lm70_of_ids), >dev);
> if (of_match)
> chip = (int)(uintptr_t)of_match->data;
> else {
>
Re: [PATCH 4.19 00/22] 4.19.170-rc1 review
On Fri, 22 Jan 2021 at 19:45, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.170 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, 24 Jan 2021 13:57:23 +. > 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.170-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. Summary kernel: 4.19.170-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: 6cb90163efb77ad3afe6d40720f0b7cdd0a94812 git describe: v4.19.169-23-g6cb90163efb7 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.169-23-g6cb90163efb7 No regressions (compared to build v4.19.169) No fixes (compared to build v4.19.169) Ran 46904 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 - nxp-ls2088 - qemu-arm64-clang - qemu-arm64-kasan - qemu-x86_64-clang - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * linux-log-parser * ltp-containers-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-tracing-tests * perf * fwts * kselftest * kvm-unit-tests * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * ltp-syscalls-tests * network-basic-tests * v4l2-compliance * ltp-controllers-tests * ltp-fs-tests * ltp-open-posix-tests * ltp-sched-tests * rcutorture * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: Duplicate crash reports related with smsc75xx/smsc95xx and root cause analysis
On Sat, Jan 23, 2021 at 1:40 PM 慕冬亮 wrote:
>
> Dear kernel developers,
>
> I found that on the syzbot dashboard, “KMSAN: uninit-value in
> smsc75xx_read_eeprom (2)” [1],
> "KMSAN: uninit-value in smsc95xx_read_eeprom (2)" [2], "KMSAN:
> uninit-value in smsc75xx_bind" [3],
> "KMSAN: uninit-value in smsc95xx_reset" [4], "KMSAN: uninit-value in
> smsc95xx_wait_eeprom (2)" [5]
> should share the same root cause.
>
> ## Root Cause Analysis && Different behaviors
>
> The root cause of these crash reports resides in the
> "__smsc75xx_read_reg/__smsc95xx_read_reg". Take __smsc95xx_read_reg as
> an example,
>
> -
> static int __must_check __smsc95xx_read_reg(struct usbnet *dev, u32 index,
> u32 *data, int in_pm)
> {
> u32 buf;
> int ret;
> int (*fn)(struct usbnet *, u8, u8, u16, u16, void *, u16);
>
> BUG_ON(!dev);
>
> if (!in_pm)
> fn = usbnet_read_cmd;
> else
> fn = usbnet_read_cmd_nopm;
>
> ret = fn(dev, USB_VENDOR_REQUEST_READ_REGISTER, USB_DIR_IN
> | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
> 0, index, , 4);
> if (unlikely(ret < 0)) {
> netdev_warn(dev->net, "Failed to read reg index 0x%08x: %d\n",
> index, ret);
> return ret;
> }
>
> le32_to_cpus();
> *data = buf;
>
> return ret;
> }
>
>
> static int __must_check smsc95xx_eeprom_confirm_not_busy(struct usbnet *dev)
> {
> unsigned long start_time = jiffies;
> u32 val;
> int ret;
>
> do {
> ret = smsc95xx_read_reg(dev, E2P_CMD, );
> if (ret < 0) {
> netdev_warn(dev->net, "Error reading E2P_CMD\n");
> return ret;
> }
>
> if (!(val & E2P_CMD_BUSY_))
> return 0;
> ..
> }
> -
>
> In a special situation, local variable "buf" is not initialized with
> "fn" function invocation. And the ret is bigger than zero, and buf is
> assigned to "*data". In its parent function -
> smsc95xx_eeprom_confirm_not_busy, KMSAN reports "uninit-value" when
> accessing variable "val".
> Note, due to the lack of testing environment, I don't know the
> concrete reason for the uninitialization of "buf" local variable.
>
> The reason for such different crash behaviors is that the event -
> "buf" is not initialized is random when
> "__smsc75xx_read_reg/__smsc95xx_read_reg" is invoked.
>
> ## Patch
>
> diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
> index 4353b370249f..a8e500d92285 100644
> --- a/drivers/net/usb/smsc75xx.c
> +++ b/drivers/net/usb/smsc75xx.c
> @@ -76,7 +76,7 @@ static int smsc75xx_phy_gig_workaround(struct usbnet *dev);
> static int __must_check __smsc75xx_read_reg(struct usbnet *dev, u32 index,
> u32 *data, int in_pm)
> {
> - u32 buf;
> + u32 buf = 0;
> int ret;
> int (*fn)(struct usbnet *, u8, u8, u16, u16, void *, u16);
>
> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
> index 4c8ee1cff4d4..dae3be723e0c 100644
> --- a/drivers/net/usb/smsc95xx.c
> +++ b/drivers/net/usb/smsc95xx.c
> @@ -70,7 +70,7 @@ MODULE_PARM_DESC(turbo_mode, "Enable multiple frames
> per Rx transaction");
> static int __must_check __smsc95xx_read_reg(struct usbnet *dev, u32 index,
> u32 *data, int in_pm)
> {
> - u32 buf;
> + u32 buf = 0;
> int ret;
> int (*fn)(struct usbnet *, u8, u8, u16, u16, void *, u16);
>
> If you can have any issues with this statement or our information is
> useful to you, please let us know. Thanks very much.
>
> [1] “KMSAN: uninit-value in smsc75xx_read_eeprom (2)” - url
> [2] “KMSAN: uninit-value in smsc95xx_read_eeprom (2)” - URL
> [3] "KMSAN: uninit-value in smsc75xx_bind" -
> [4] "KMSAN: uninit-value in smsc95xx_reset" -
> [5] "KMSAN: uninit-value in smsc95xx_wait_eeprom (2)" -
Add links for all five bug reports:
[1] “KMSAN: uninit-value in smsc75xx_read_eeprom (2)” -
https://syzkaller.appspot.com/bug?id=2fb4e465ed593338d043227e7617cbdfaa03ba01
[2] “KMSAN: uninit-value in smsc95xx_read_eeprom (2)” -
https://syzkaller.appspot.com/bug?id=0629febb76ae17ff78874aa68991e542506b1351
[3] "KMSAN: uninit-value in smsc75xx_bind" -
https://syzkaller.appspot.com/bug?id=45ee70ca00699d61239bbf9ebc790e33f83add6a
[4] "KMSAN: uninit-value in smsc95xx_reset" -
https://syzkaller.appspot.com/bug?id=de07a0d125f8f1716eacb7e2ee4ceca251b21511
[5] "KMSAN: uninit-value in smsc95xx_wait_eeprom (2)" -
Re: [PATCH 5.4 00/33] 5.4.92-rc1 review
On Fri, 22 Jan 2021 at 19:47, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.4.92 release. > There are 33 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, 24 Jan 2021 13:57:23 +. > 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.92-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. Summary kernel: 5.4.92-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: eb6c2292de97c5c4e51d98767b4c7acaef0522ec git describe: v5.4.91-34-geb6c2292de97 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.91-34-geb6c2292de97 No regressions (compared to build v5.4.91) No fixes (compared to build v5.4.91) Ran 53090 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu-arm-clang - qemu-arm64-clang - qemu-arm64-kasan - qemu-x86_64-clang - qemu-x86_64-kasan - qemu-x86_64-kcsan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - x15 - x86 - x86-kasan Test Suites --- * build * igt-gpu-tools * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fs-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-mm-tests * ltp-syscalls-tests * perf * v4l2-compliance * fwts * kvm-unit-tests * ltp-commands-tests * ltp-controllers-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * ltp-tracing-tests * network-basic-tests * ltp-open-posix-tests * ltp-sched-tests * rcutorture * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 5.10 00/43] 5.10.10-rc1 review
On Fri, 22 Jan 2021 at 19:49, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.10.10 release. > There are 43 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, 24 Jan 2021 13:57:23 +. > 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.10.10-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.10.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. Summary kernel: 5.10.10-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.10.y git commit: 402284178c914c87fd7b41bc9bd93f2772c43904 git describe: v5.10.9-44-g402284178c91 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.9-44-g402284178c91 No regressions (compared to build v5.10.9) No fixes (compared to build v5.10.9) Ran 55124 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu-arm-clang - qemu-arm64-clang - qemu-arm64-kasan - qemu-i386-clang - qemu-x86_64-clang - qemu-x86_64-kasan - qemu-x86_64-kcsan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - x15 - x86 - x86-kasan Test Suites --- * build * igt-gpu-tools * install-android-platform-tools-r2600 * libhugetlbfs * linux-log-parser * ltp-commands-tests * ltp-containers-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-sched-tests * ltp-tracing-tests * fwts * kselftest * ltp-cap_bounds-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * ltp-syscalls-tests * network-basic-tests * perf * ltp-controllers-tests * ltp-open-posix-tests * v4l2-compliance * kvm-unit-tests * kunit * rcutorture * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Duplicate crash reports related with smsc75xx/smsc95xx and root cause analysis
Dear kernel developers,
I found that on the syzbot dashboard, “KMSAN: uninit-value in
smsc75xx_read_eeprom (2)” [1],
"KMSAN: uninit-value in smsc95xx_read_eeprom (2)" [2], "KMSAN:
uninit-value in smsc75xx_bind" [3],
"KMSAN: uninit-value in smsc95xx_reset" [4], "KMSAN: uninit-value in
smsc95xx_wait_eeprom (2)" [5]
should share the same root cause.
## Root Cause Analysis && Different behaviors
The root cause of these crash reports resides in the
"__smsc75xx_read_reg/__smsc95xx_read_reg". Take __smsc95xx_read_reg as
an example,
-
static int __must_check __smsc95xx_read_reg(struct usbnet *dev, u32 index,
u32 *data, int in_pm)
{
u32 buf;
int ret;
int (*fn)(struct usbnet *, u8, u8, u16, u16, void *, u16);
BUG_ON(!dev);
if (!in_pm)
fn = usbnet_read_cmd;
else
fn = usbnet_read_cmd_nopm;
ret = fn(dev, USB_VENDOR_REQUEST_READ_REGISTER, USB_DIR_IN
| USB_TYPE_VENDOR | USB_RECIP_DEVICE,
0, index, , 4);
if (unlikely(ret < 0)) {
netdev_warn(dev->net, "Failed to read reg index 0x%08x: %d\n",
index, ret);
return ret;
}
le32_to_cpus();
*data = buf;
return ret;
}
static int __must_check smsc95xx_eeprom_confirm_not_busy(struct usbnet *dev)
{
unsigned long start_time = jiffies;
u32 val;
int ret;
do {
ret = smsc95xx_read_reg(dev, E2P_CMD, );
if (ret < 0) {
netdev_warn(dev->net, "Error reading E2P_CMD\n");
return ret;
}
if (!(val & E2P_CMD_BUSY_))
return 0;
..
}
-
In a special situation, local variable "buf" is not initialized with
"fn" function invocation. And the ret is bigger than zero, and buf is
assigned to "*data". In its parent function -
smsc95xx_eeprom_confirm_not_busy, KMSAN reports "uninit-value" when
accessing variable "val".
Note, due to the lack of testing environment, I don't know the
concrete reason for the uninitialization of "buf" local variable.
The reason for such different crash behaviors is that the event -
"buf" is not initialized is random when
"__smsc75xx_read_reg/__smsc95xx_read_reg" is invoked.
## Patch
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 4353b370249f..a8e500d92285 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -76,7 +76,7 @@ static int smsc75xx_phy_gig_workaround(struct usbnet *dev);
static int __must_check __smsc75xx_read_reg(struct usbnet *dev, u32 index,
u32 *data, int in_pm)
{
- u32 buf;
+ u32 buf = 0;
int ret;
int (*fn)(struct usbnet *, u8, u8, u16, u16, void *, u16);
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 4c8ee1cff4d4..dae3be723e0c 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -70,7 +70,7 @@ MODULE_PARM_DESC(turbo_mode, "Enable multiple frames
per Rx transaction");
static int __must_check __smsc95xx_read_reg(struct usbnet *dev, u32 index,
u32 *data, int in_pm)
{
- u32 buf;
+ u32 buf = 0;
int ret;
int (*fn)(struct usbnet *, u8, u8, u16, u16, void *, u16);
If you can have any issues with this statement or our information is
useful to you, please let us know. Thanks very much.
[1] “KMSAN: uninit-value in smsc75xx_read_eeprom (2)” - url
[2] “KMSAN: uninit-value in smsc95xx_read_eeprom (2)” - URL
[3] "KMSAN: uninit-value in smsc75xx_bind" -
[4] "KMSAN: uninit-value in smsc95xx_reset" -
[5] "KMSAN: uninit-value in smsc95xx_wait_eeprom (2)" -
--
My best regards to you.
No System Is Safe!
Dongliang Mu
Re: [PATCH v3 net-next 1/1] Allow user to set metric on default route learned via Router Advertisement.
On 1/22/21 9:02 PM, Maciej Żenczykowski wrote: > Why can't we get rid of the special case for 0 and simply make 1024 the > default value? That would work too. > > As for making it an RA option: it's not clear how that would work, the > use case I see for this is for example two connections to the internet, > of which one is clearly better (higher throughput, lower latency, lower > packet loss, etc) then the other. > > The upstream routers would have to somehow coordinate with each other > the metric values... that seems impossible to achieve in practice - > unless they do something like report expected down/up > bandwidth, latency, etc... While some sort of policy on the machine > itself seems much more feasible (for example wired interface > wireless > interface > cell interface or something like that) I was thinking the admin of the network controls the RAs and knows which paths are preferred over the admin of the node receiving the RA (not practical for a mobile setup with cell vs wifi, but is for a DC which is the driving use case). But it takes an extension to IPv6/ndisc to add metric as an RA option, so not realistic in a reasonable time frame.
Re: [RFC PATCH v0] mm/slub: Let number of online CPUs determine the slub page order
On Fri, Jan 22, 2021 at 01:03:57PM +0100, Vlastimil Babka wrote: > On 1/22/21 9:03 AM, Vincent Guittot wrote: > > On Thu, 21 Jan 2021 at 19:19, Vlastimil Babka wrote: > >> > >> On 1/21/21 11:01 AM, Christoph Lameter wrote: > >> > On Thu, 21 Jan 2021, Bharata B Rao wrote: > >> > > >> >> > The problem is that calculate_order() is called a number of times > >> >> > before secondaries CPUs are booted and it returns 1 instead of 224. > >> >> > This makes the use of num_online_cpus() irrelevant for those cases > >> >> > > >> >> > After adding in my command line "slub_min_objects=36" which equals to > >> >> > 4 * (fls(num_online_cpus()) + 1) with a correct num_online_cpus == 224 > >> >> > , the regression diseapears: > >> >> > > >> >> > 9 iterations of hackbench -l 16000 -g 16: 3.201sec (+/- 0.90%) > >> > >> I'm surprised that hackbench is that sensitive to slab performance, > >> anyway. It's > >> supposed to be a scheduler benchmark? What exactly is going on? > >> > > > > From hackbench description: > > Hackbench is both a benchmark and a stress test for the Linux kernel > > scheduler. It's main > >job is to create a specified number of pairs of schedulable > > entities (either threads or > >traditional processes) which communicate via either sockets or > > pipes and time how long it > >takes for each pair to send data back and forth. > > Yep, so I wonder which slab entities this is stressing that much. > > >> Things would be easier if we could trust *on all arches* either > >> > >> - num_present_cpus() to count what the hardware really physically has > >> during > >> boot, even if not yet onlined, at the time we init slab. This would still > >> not > >> handle later hotplug (probably mostly in a VM scenario, not that somebody > >> would > >> bring bunch of actual new cpu boards to a running bare metal system?). > >> > >> - num_possible_cpus()/nr_cpu_ids not to be excessive (broken BIOS?) on > >> systems > >> where it's not really possible to plug more CPU's. In a VM scenario we > >> could > >> still have an opposite problem, where theoretically "anything is possible" > >> but > >> the virtual cpus are never added later. > > > > On all the system that I have tested num_possible_cpus()/nr_cpu_ids > > were correctly initialized > > > > large arm64 acpi system > > small arm64 DT based system > > VM on x86 system > > So it's just powerpc that has this issue with too large nr_cpu_ids? Is it > caused > by bios or the hypervisor? How does num_present_cpus() look there? PowerPC PowerNV Host: (160 cpus) num_online_cpus 1 num_present_cpus 160 num_possible_cpus 160 nr_cpu_ids 160 PowerPC pseries KVM guest: (-smp 16,maxcpus=160) num_online_cpus 1 num_present_cpus 16 num_possible_cpus 160 nr_cpu_ids 160 That's what I see on powerpc, hence I thought num_present_cpus() could be the correct one to use in slub page order calculation. > > What about heuristic: > - num_online_cpus() > 1 - we trust that and use it > - otherwise nr_cpu_ids > Would that work? Too arbitrary? Looking at the following snippet from include/linux/cpumask.h, it appears that num_present_cpus() should be reasonable compromise between online and possible/nr_cpus_ids to use here. /* * The following particular system cpumasks and operations manage * possible, present, active and online cpus. * * cpu_possible_mask- has bit 'cpu' set iff cpu is populatable * cpu_present_mask - has bit 'cpu' set iff cpu is populated * cpu_online_mask - has bit 'cpu' set iff cpu available to scheduler * cpu_active_mask - has bit 'cpu' set iff cpu available to migration * * If !CONFIG_HOTPLUG_CPU, present == possible, and active == online. * * The cpu_possible_mask is fixed at boot time, as the set of CPU id's * that it is possible might ever be plugged in at anytime during the * life of that system boot. The cpu_present_mask is dynamic(*), * representing which CPUs are currently plugged in. And * cpu_online_mask is the dynamic subset of cpu_present_mask, * indicating those CPUs available for scheduling. * * If HOTPLUG is enabled, then cpu_possible_mask is forced to have * all NR_CPUS bits set, otherwise it is just the set of CPUs that * ACPI reports present at boot. * * If HOTPLUG is enabled, then cpu_present_mask varies dynamically, * depending on what ACPI reports as currently plugged in, otherwise * cpu_present_mask is just a copy of cpu_possible_mask. * * (*) Well, cpu_present_mask is dynamic in the hotplug case. If not * hotplug, it's a copy of cpu_possible_mask, hence fixed at boot. */ So for host systems, present is (usually) equal to possible and for guest systems present should indicate the CPUs found to be present at boottime. The intention of my original patch was to use this metric in slub page order calculation rather than nr_cpus_ids or num_cpus_possible() which could be high on guest systems that typically support CPU hotplug. Regards, Bharata.
[PATCH] usbnet: fix the indentation of one code snippet
Every line of code should start with tab (8 characters)
Signed-off-by: Dongliang Mu
---
drivers/net/usb/usbnet.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 1447da1d5729..305c5f7b9a9b 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1964,12 +1964,12 @@ static int __usbnet_read_cmd(struct usbnet *dev, u8
cmd, u8 reqtype,
cmd, reqtype, value, index, buf, size,
USB_CTRL_GET_TIMEOUT);
if (err > 0 && err <= size) {
-if (data)
-memcpy(data, buf, err);
-else
-netdev_dbg(dev->net,
-"Huh? Data requested but thrown away.\n");
-}
+ if (data)
+ memcpy(data, buf, err);
+ else
+ netdev_dbg(dev->net,
+ "Huh? Data requested but thrown away.\n");
+ }
kfree(buf);
out:
return err;
--
2.25.1
Re: [net-next PATCH 3/7] octeontx2-pf: ethtool fec mode support
On Thu, 21 Jan 2021 13:23:25 +0530 Hariprasad Kelam wrote:
> From: Christina Jacob
>
> Add ethtool support to configure fec modes baser/rs and
> support to fecth FEC stats from CGX as well PHY.
>
> Configure fec mode
> - ethtool --set-fec eth0 encoding rs/baser/off/auto
> Query fec mode
> - ethtool --show-fec eth0
>
> Signed-off-by: Christina Jacob
> Signed-off-by: Sunil Goutham
> Signed-off-by: Hariprasad Kelam
> ---
> .../ethernet/marvell/octeontx2/nic/otx2_common.c | 23 +++
> .../ethernet/marvell/octeontx2/nic/otx2_common.h | 6 +
> .../ethernet/marvell/octeontx2/nic/otx2_ethtool.c | 174
> -
> .../net/ethernet/marvell/octeontx2/nic/otx2_pf.c | 3 +
> 4 files changed, 204 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> index bdfa2e2..d09119b 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> @@ -60,6 +60,22 @@ void otx2_update_lmac_stats(struct otx2_nic *pfvf)
> mutex_unlock(>mbox.lock);
> }
>
> +void otx2_update_lmac_fec_stats(struct otx2_nic *pfvf)
> +{
> + struct msg_req *req;
> +
> + if (!netif_running(pfvf->netdev))
> + return;
> + mutex_lock(>mbox.lock);
> + req = otx2_mbox_alloc_msg_cgx_fec_stats(>mbox);
> + if (!req) {
> + mutex_unlock(>mbox.lock);
> + return;
> + }
> + otx2_sync_mbox_msg(>mbox);
> + mutex_unlock(>mbox.lock);
> +}
> +
> int otx2_update_rq_stats(struct otx2_nic *pfvf, int qidx)
> {
> struct otx2_rcv_queue *rq = >qset.rq[qidx];
> @@ -1491,6 +1507,13 @@ void mbox_handler_cgx_stats(struct otx2_nic *pfvf,
> pfvf->hw.cgx_tx_stats[id] = rsp->tx_stats[id];
> }
>
> +void mbox_handler_cgx_fec_stats(struct otx2_nic *pfvf,
> + struct cgx_fec_stats_rsp *rsp)
> +{
> + pfvf->hw.cgx_fec_corr_blks += rsp->fec_corr_blks;
> + pfvf->hw.cgx_fec_uncorr_blks += rsp->fec_uncorr_blks;
double indented
> +}
> +
> void mbox_handler_nix_txsch_alloc(struct otx2_nic *pf,
> struct nix_txsch_alloc_rsp *rsp)
> {
> @@ -183,12 +210,42 @@ static void otx2_get_ethtool_stats(struct net_device
> *netdev,
> for (stat = 0; stat < CGX_TX_STATS_COUNT; stat++)
> *(data++) = pfvf->hw.cgx_tx_stats[stat];
> *(data++) = pfvf->reset_count;
> +
> + if (pfvf->linfo.fec == OTX2_FEC_NONE)
> + return;
Don't hide the stats based on configuration.
Getting number of stats and requesting them are two different syscalls.
> + fec_corr_blks = pfvf->hw.cgx_fec_corr_blks;
> + fec_uncorr_blks = pfvf->hw.cgx_fec_uncorr_blks;
> +
> + rsp = otx2_get_fwdata(pfvf);
> + if (!IS_ERR(rsp) && rsp->fwdata.phy.misc.has_fec_stats &&
> + !otx2_get_phy_fec_stats(pfvf)) {
> + /* Fetch fwdata again because it's been recently populated with
> + * latest PHY FEC stats.
> + */
> + rsp = otx2_get_fwdata(pfvf);
> + if (!IS_ERR(rsp)) {
> + struct fec_stats_s *p = >fwdata.phy.fec_stats;
> +
> + if (pfvf->linfo.fec == OTX2_FEC_BASER) {
> + fec_corr_blks = p->brfec_corr_blks;
> + fec_uncorr_blks = p->brfec_uncorr_blks;
> + } else {
> + fec_corr_blks = p->rsfec_corr_cws;
> + fec_uncorr_blks = p->rsfec_uncorr_cws;
> + }
> + }
> + }
> +
> + *(data++) = fec_corr_blks;
> + *(data++) = fec_uncorr_blks;
> }
> +static int otx2_get_fecparam(struct net_device *netdev,
> + struct ethtool_fecparam *fecparam)
> +{
> + struct otx2_nic *pfvf = netdev_priv(netdev);
> + struct cgx_fw_data *rsp;
> + int fec[] = {
const
> + ETHTOOL_FEC_OFF,
> + ETHTOOL_FEC_BASER,
> + ETHTOOL_FEC_RS,
> + ETHTOOL_FEC_BASER | ETHTOOL_FEC_RS};
> +#define FEC_MAX_INDEX 3
> + if (pfvf->linfo.fec < FEC_MAX_INDEX)
> + fecparam->active_fec = fec[pfvf->linfo.fec];
> +
> + rsp = otx2_get_fwdata(pfvf);
> + if (IS_ERR(rsp))
> + return PTR_ERR(rsp);
> +
> + if (rsp->fwdata.supported_fec <= FEC_MAX_INDEX) {
> + if (!rsp->fwdata.supported_fec)
> + fecparam->fec = ETHTOOL_FEC_NONE;
> + else
> + fecparam->fec = fec[rsp->fwdata.supported_fec];
> + }
> + return 0;
> +}
> +
> +static int otx2_set_fecparam(struct net_device *netdev,
> + struct ethtool_fecparam *fecparam)
> +{
> + struct otx2_nic *pfvf = netdev_priv(netdev);
> + struct mbox *mbox = >mbox;
> + struct fec_mode *req, *rsp;
> + int
Re: [PATCH] arch/riscv:fix typo in a comment in arch/riscv/kernel/image-vars.h
On Wed, 20 Jan 2021 17:55:13 PST (-0800), tangchun...@163.com wrote: From: tangchunyou "kerne" -> "kernel" Signed-off-by: WenZhang --- arch/riscv/kernel/image-vars.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/kernel/image-vars.h b/arch/riscv/kernel/image-vars.h index 8c212ef..71a76a6 100644 --- a/arch/riscv/kernel/image-vars.h +++ b/arch/riscv/kernel/image-vars.h @@ -3,7 +3,7 @@ * Copyright (C) 2020 Western Digital Corporation or its affiliates. * Linker script variables to be set after section resolution, as * ld.lld does not like variables assigned before SECTIONS is processed. - * Based on arch/arm64/kerne/image-vars.h + * Based on arch/arm64/kernel/image-vars.h */ #ifndef __RISCV_KERNEL_IMAGE_VARS_H #define __RISCV_KERNEL_IMAGE_VARS_H Thanks, this is on for-next.
Re: [PATCH][next] scsi: ibmvfc: Fix spelling mistake "succeded" -> "succeeded"
On Mon, 18 Jan 2021 11:13:46 +, Colin King wrote: > There is a spelling mistake in a ibmvfc_dbg debug message. Fix it. Applied to 5.12/scsi-queue, thanks! [1/1] scsi: ibmvfc: Fix spelling mistake "succeded" -> "succeeded" https://git.kernel.org/mkp/scsi/c/ff79acc49af8 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH][next] scsi: pm80xx: clean up indentation of a code block
On Fri, 15 Jan 2021 09:58:24 +, Colin King wrote: > A block of code is indented one level too deeply, clean this > up. Applied to 5.12/scsi-queue, thanks! [1/1] scsi: pm80xx: clean up indentation of a code block https://git.kernel.org/mkp/scsi/c/7b382122d276 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v3 0/3] scsi: ufs: Cleanup and refactor clock scaling
On Wed, 20 Jan 2021 23:01:39 +0800, Stanley Chu wrote: > This series cleans up and refactors clk-scaling feature, and shall not change > any functionality. > > This series is based on Can's series "Three changes related with UFS clock > scaling" in 5.12/scsi-queue branch in Martin's tree. > > Changes since v2: > - Remove patch 4 > - Rebase to Can's series: [v11] Three changes related with UFS clock scaling > > [...] Applied to 5.12/scsi-queue, thanks! [1/3] scsi: ufs: Refactor cancelling clkscaling works https://git.kernel.org/mkp/scsi/c/f9a7fa345aec [2/3] scsi: ufs: Remove redundant null checking of devfreq instance https://git.kernel.org/mkp/scsi/c/b058fa868234 [3/3] scsi: ufs: Cleanup and refactor clk-scaling feature https://git.kernel.org/mkp/scsi/c/348e1bc5f4b7 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v7 0/6] Several changes for UFS WriteBooster
On Tue, 19 Jan 2021 17:38:41 +0100, Bean Huo wrote: > Changelog: > > v6--v7: > 1. Change wb_on sysfs documentation and add information that WriteBooster > is already enabled after power-on/reset(Incorporate Adrian Hunter's > suggestion) > > v5--v6: > 1. Remove original patch 7/7: > "scsi: ufs: Keep device active mode only > fWriteBoosterBufferFlushDuringHibernate == 1" > 2. Rebased patch onto 5.12/scsi-staging > 3. Add protection of PM ops and err_handler for the wb_on entry access > > [...] Applied to 5.12/scsi-queue, thanks! [1/6] scsi: ufs: Add "wb_on" sysfs node to control WB on/off https://git.kernel.org/mkp/scsi/c/8e834ca551ad [2/6] docs: ABI: Add wb_on documentation for new entry wb_on https://git.kernel.org/mkp/scsi/c/06aea26676a5 [3/6] scsi: ufs: Changes comment in the function ufshcd_wb_probe() https://git.kernel.org/mkp/scsi/c/ae1ce1fc61d4 [4/6] scsi: ufs: Remove two WB related fields from struct ufs_dev_info https://git.kernel.org/mkp/scsi/c/e8d038139420 [5/6] scsi: ufs: Group UFS WB related flags to struct ufs_dev_info https://git.kernel.org/mkp/scsi/c/4cd48995645b -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: ufs: delete redundant if statement in ufshcd_intr()
On Mon, 18 Jan 2021 21:12:33 +0100, Bean Huo wrote: > Once going into while-do loop, intr_status is already true, > this if-statement is redundant, remove it. Applied to 5.12/scsi-queue, thanks! [1/1] scsi: ufs: delete redundant if statement in ufshcd_intr() https://git.kernel.org/mkp/scsi/c/60ec37555d05 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: pm80xx: switch from 'pci_' to 'dma_' API
On Sun, 17 Jan 2021 14:24:45 +0100, Christophe JAILLET wrote: > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'pm8001_init_ccb_tag()' GFP_KERNEL can be used > because this function already uses this flag a few lines above. > > [...] Applied to 5.12/scsi-queue, thanks! [1/1] scsi: pm80xx: switch from 'pci_' to 'dma_' API https://git.kernel.org/mkp/scsi/c/8e60a7deca3d -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v15 03/11] riscv/Kconfig: make direct map manipulation options depend on MMU
On Wed, 20 Jan 2021 10:06:04 PST (-0800), r...@kernel.org wrote: From: Mike Rapoport ARCH_HAS_SET_DIRECT_MAP and ARCH_HAS_SET_MEMORY configuration options have no meaning when CONFIG_MMU is disabled and there is no point to enable them for the nommu case. Add an explicit dependency on MMU for these options. Signed-off-by: Mike Rapoport Reported-by: kernel test robot --- arch/riscv/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index d82303dcc6b6..d35ce19ab1fa 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -25,8 +25,8 @@ config RISCV select ARCH_HAS_KCOV select ARCH_HAS_MMIOWB select ARCH_HAS_PTE_SPECIAL - select ARCH_HAS_SET_DIRECT_MAP - select ARCH_HAS_SET_MEMORY + select ARCH_HAS_SET_DIRECT_MAP if MMU + select ARCH_HAS_SET_MEMORY if MMU select ARCH_HAS_STRICT_KERNEL_RWX if MMU select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT Reviewed-by: Palmer Dabbelt Acked-by: Palmer Dabbelt LMK if you want this to go in via the RISC-V tree, otherwise I'm going to assume it's going in along with the rest of these. FWIW I see these in other architectures without the MMU guard. Thanks!
Re: [PATCH 06/20] clk: sifive: fu540-prci: Declare static const variable 'prci_clk_fu540' where it's used
On Wed, 20 Jan 2021 01:30:26 PST (-0800), lee.jo...@linaro.org wrote:
Fixes the following W=1 kernel build warning(s):
drivers/clk/sifive/fu540-prci.h:16:35: warning: ‘prci_clk_fu540’ defined but
not used [-Wunused-const-variable=]
drivers/clk/sifive/fu540-prci.h:16:35: warning: ‘prci_clk_fu540’ defined but
not used [-Wunused-const-variable=]
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Paul Walmsley
Cc: Palmer Dabbelt
Cc: Pragnesh Patel
Cc: Zong Li
Cc: linux-...@vger.kernel.org
Cc: linux-ri...@lists.infradead.org
Signed-off-by: Lee Jones
---
drivers/clk/sifive/fu540-prci.h | 5 -
drivers/clk/sifive/sifive-prci.c | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/sifive/fu540-prci.h b/drivers/clk/sifive/fu540-prci.h
index c8271efa7bdc7..c220677dc0108 100644
--- a/drivers/clk/sifive/fu540-prci.h
+++ b/drivers/clk/sifive/fu540-prci.h
@@ -13,9 +13,4 @@
extern struct __prci_clock __prci_init_clocks_fu540[NUM_CLOCK_FU540];
-static const struct prci_clk_desc prci_clk_fu540 = {
- .clks = __prci_init_clocks_fu540,
- .num_clks = ARRAY_SIZE(__prci_init_clocks_fu540),
-};
-
#endif /* __SIFIVE_CLK_FU540_PRCI_H */
diff --git a/drivers/clk/sifive/sifive-prci.c b/drivers/clk/sifive/sifive-prci.c
index c78b042750e21..1490b01ce6290 100644
--- a/drivers/clk/sifive/sifive-prci.c
+++ b/drivers/clk/sifive/sifive-prci.c
@@ -12,6 +12,11 @@
#include "fu540-prci.h"
#include "fu740-prci.h"
+static const struct prci_clk_desc prci_clk_fu540 = {
+ .clks = __prci_init_clocks_fu540,
+ .num_clks = ARRAY_SIZE(__prci_init_clocks_fu540),
+};
+
/*
* Private functions
*/
This doesn't look like my sifive-prci.c, so I'm assuming it's against one of
the clock trees and therefor should go in over there.
Acked-by: Palmer Dabbelt
Thanks!
Re: [PATCH v2] lan743x: add virtual PHY for PHY-less devices
resending answer to all:
On Saturday, January 23, 2021 4:32:38 AM MSK Andrew Lunn wrote:
> > it migth be helpful for developers work on userspace networking tools with
> > PHY-less lan743x
>
> (the interface even could not be brought up)
>
> > of course, there nothing much to do without TP port but the difference is
> > representative.
> >
> > sbauer@metamini ~$ sudo ethtool eth7
> > Settings for eth7:
> > Cannot get device settings: No such device
> >
> > Supports Wake-on: pumbag
> > Wake-on: d
> > Current message level: 0x0137 (311)
> >
> >drv probe link ifdown ifup tx_queued
> >
> > Link detected: no
> >
> > sbauer@metamini ~$ sudo ifup eth7
> > sbauer@metamini ~$ sudo ethtool eth7
> >
> > Settings for eth7:
> > Supported ports: [ MII ]
> > Supported link modes: 10baseT/Full
> >
> > 100baseT/Full
> > 1000baseT/Full
> >
> > Supported pause frame use: Symmetric Receive-only
> > Supports auto-negotiation: Yes
> > Supported FEC modes: Not reported
> > Advertised link modes: 10baseT/Full
> >
> > 100baseT/Full
> > 1000baseT/Full
> >
> > Advertised pause frame use: Symmetric Receive-only
> > Advertised auto-negotiation: Yes
> > Advertised FEC modes: Not reported
> > Speed: 1000Mb/s
> > Duplex: Full
> > Port: MII
> > PHYAD: 0
> > Transceiver: internal
> > Auto-negotiation: on
> > Supports Wake-on: pumbag
> > Wake-on: d
> > Current message level: 0x0137 (311)
> >
> >drv probe link ifdown ifup tx_queued
> >
> > Link detected: yes
> >
> > sbauer@metamini ~$ sudo mii-tool -vv eth7
> > Using SIOCGMIIPHY=0x8947
> > eth7: negotiated 1000baseT-FD, link ok
> >
> > registers for MII PHY 0:
> > 5140 512d 7431 0011 4140 4140 000d
> > 0200 7800 2000
> >
> >
> >
> > product info: vendor 1d:0c:40, model 1 rev 1
> > basic mode: loopback, autonegotiation enabled
> > basic status: autonegotiation complete, link ok
> > capabilities: 1000baseT-FD 100baseTx-FD 10baseT-FD
> > advertising: 1000baseT-FD 100baseTx-FD 10baseT-FD
> > link partner: 1000baseT-FD 100baseTx-FD 10baseT-FD
>
> You have not shown anything i cannot do with the ethernet interfaces i
> have in my laptop. And since ethtool is pretty standardized, what
> lan743x offers should be pretty much the same as any 1G Ethernet MAC
> using most 1G PHYs.
>
> Andrew
Andrew, I can reproduce segfault with following changes:
sbauer@metamini ~/devel/kernel-works/net-next.git master$ git diff .
diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/
ethernet/microchip/lan743x_main.c
index 3804310c853a..6e2961f47211 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -1001,6 +1001,8 @@ static void lan743x_phy_close(struct lan743x_adapter
*adapter)
phy_stop(netdev->phydev);
phy_disconnect(netdev->phydev);
+ if (phy_is_pseudo_fixed_link(netdev->phydev))
+ fixed_phy_unregister(netdev->phydev);
netdev->phydev = NULL;
}
@@ -1018,9 +1020,21 @@ static int lan743x_phy_open(struct lan743x_adapter
*adapter)
if (!phydev) {
/* try internal phy */
phydev = phy_find_first(adapter->mdiobus);
- if (!phydev)
- goto return_error;
-
+ if (!phydev) {
+ struct fixed_phy_status status = {
+ .link = 1,
+ .speed = SPEED_1000,
+ .duplex = DUPLEX_FULL,
+ .asym_pause = 1,
+ };
+
+ phydev = fixed_phy_register(PHY_POLL, , NULL);
+ if (!phydev || IS_ERR(phydev)) {
+ netif_err(adapter, probe, netdev,
+ "Failed to register fixed PHY
device\n");
+ goto return_error;
+ }
+ }
ret = phy_connect_direct(netdev, phydev,
lan743x_phy_link_status_change,
PHY_INTERFACE_MODE_GMII);
sbauer@metamini ~/devel/kernel-works/net-next.git master$ sudo modprobe
lan743x
sbauer@metamini ~/devel/kernel-works/net-next.git master$ sudo ifup eth7
sbauer@metamini ~/devel/kernel-works/net-next.git master$ ethtool eth7
Settings for eth7:
Supported ports: [ TP MII ]
Re: [PATCH 1/1] kernel/crash_core.c - Add crashkernel=auto for x86 and ARM
On 01/23/21 at 11:51am, Dave Young wrote: > Hi Saeed, > On 01/22/21 at 05:14pm, Saeed Mirzamohammadi wrote: > > Hi, > > > > > On Jan 21, 2021, at 7:12 PM, Dave Young wrote: > > > > > > On 01/22/21 at 09:22am, Dave Young wrote: > > >> Hi John, > > >> > > >> On 01/21/21 at 09:32am, john.p.donne...@oracle.com wrote: > > >>> On 11/22/20 9:47 PM, Dave Young wrote: > > Hi Guilherme, > > On 11/22/20 at 12:32pm, Guilherme Piccoli wrote: > > > Hi Dave and Kairui, thanks for your responses! OK, if that makes sense > > > to you I'm fine with it. I'd just recommend to test recent kernels in > > > multiple distros with the minimum "range" to see if 64M is enough for > > > crashkernel, maybe we'd need to bump that. > > > > Giving the different kernel configs and the different userspace > > initramfs setup it is hard to get an uniform value for all > > distributions, > > but we can have an interface/kconfig-option for them to provide a > > value like this patch > > is doing. And it could be improved like Kairui said about some known > > kernel added extra values later, probably some more improvements if > > doable. > > > > Thanks > > Dave > > > > >>> > > >>> Hi. > > >>> > > >>> Are we going to move forward with implementing this for X86 and Arm ? > > >>> > > >>> If other platform maintainers want to include this CONFIG option in > > >>> their > > >>> configuration settings they have a starting point. > > >> > > >> I would expect this become arch independent. > > > > > > Clarify a bit, it can be a general config option under arch/Kconfig and > > > just put the code in general arch independent part. > > > > Does this mean that we need to add the option to def_configs in all archs > > as well? > > > > I think we do not need to add defconfig, something like this will just work? > > BTW, it should depend on CRASH_CORE instead of CRASH_DUMP, the logic of > parsing crashkernel is in kernel/crash_core.c > > diff --git a/arch/Kconfig b/arch/Kconfig > index af14a567b493..fa6efeb52dc5 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -14,6 +14,11 @@ menu "General architecture-dependent options" > config CRASH_CORE > bool > > +config CRASH_AUTO_STR > + depends on CRASH_CORE > + string "Memory reserved for crash kernel" > + default "1G-:128M" People do not want to see the default value if they do not need kdump so it would be better to add another kconfig option as a switch which is set default as off in bool state. > + ... help text [snip] ... > + > config KEXEC_CORE > select CRASH_CORE > bool > > [...] > > > Thanks, > > Saeed > > > > > > > >> > > >> Saeed, Kairui, would any of you like to update the patch? > > >> > > >>> > > >>> Thank you, > > >>> > > >>> John. > > >>> > > >>> ( I am not currently on many of the included dist lists in this email, > > >>> so > > >>> hopefully key contributors are included in this exchange ) > > >>> > > >> > > >> Thanks > > >> Dave > > > > Thanks > Dave
Re: [PATCH v2 1/1] riscv/kasan: add KASAN_VMALLOC support
On Fri, 15 Jan 2021 21:58:35 PST (-0800), nyl...@andestech.com wrote:
It references to x86/s390 architecture.
So, it doesn't map the early shadow page to cover VMALLOC space.
Prepopulate top level page table for the range that would otherwise be
empty.
lower levels are filled dynamically upon memory allocation while
booting.
Signed-off-by: Nylon Chen
Signed-off-by: Nick Hu
---
arch/riscv/Kconfig | 1 +
arch/riscv/mm/kasan_init.c | 57 +-
2 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 81b76d44725d..15a2c8088bbe 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -57,6 +57,7 @@ config RISCV
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE
select HAVE_ARCH_KASAN if MMU && 64BIT
+ select HAVE_ARCH_KASAN_VMALLOC if MMU && 64BIT
select HAVE_ARCH_KGDB
select HAVE_ARCH_KGDB_QXFER_PKT
select HAVE_ARCH_MMAP_RND_BITS if MMU
diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index 12ddd1f6bf70..4b9149f963d3 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -9,6 +9,19 @@
#include
#include
#include
+#include
+
+static __init void *early_alloc(size_t size, int node)
+{
+ void *ptr = memblock_alloc_try_nid(size, size,
+ __pa(MAX_DMA_ADDRESS), MEMBLOCK_ALLOC_ACCESSIBLE, node);
+
+ if (!ptr)
+ panic("%pS: Failed to allocate %zu bytes align=%zx nid=%d
from=%llx\n",
+ __func__, size, size, node, (u64)__pa(MAX_DMA_ADDRESS));
+
+ return ptr;
+}
extern pgd_t early_pg_dir[PTRS_PER_PGD];
asmlinkage void __init kasan_early_init(void)
@@ -83,6 +96,40 @@ static void __init populate(void *start, void *end)
memset(start, 0, end - start);
}
+void __init kasan_shallow_populate(void *start, void *end)
+{
+ unsigned long vaddr = (unsigned long)start & PAGE_MASK;
+ unsigned long vend = PAGE_ALIGN((unsigned long)end);
+ unsigned long pfn;
+ int index;
+ void *p;
+ pud_t *pud_dir, *pud_k;
+ pgd_t *pgd_dir, *pgd_k;
+ p4d_t *p4d_dir, *p4d_k;
+
+ while (vaddr < vend) {
+ index = pgd_index(vaddr);
+ pfn = csr_read(CSR_SATP) & SATP_PPN;
+ pgd_dir = (pgd_t *)pfn_to_virt(pfn) + index;
+ pgd_k = init_mm.pgd + index;
+ pgd_dir = pgd_offset_k(vaddr);
+ set_pgd(pgd_dir, *pgd_k);
+
+ p4d_dir = p4d_offset(pgd_dir, vaddr);
+ p4d_k = p4d_offset(pgd_k, vaddr);
+
+ vaddr = (vaddr + PUD_SIZE) & PUD_MASK;
+ pud_dir = pud_offset(p4d_dir, vaddr);
+ pud_k = pud_offset(p4d_k, vaddr);
+
+ if (pud_present(*pud_dir)) {
+ p = early_alloc(PAGE_SIZE, NUMA_NO_NODE);
+ pud_populate(_mm, pud_dir, p);
+ }
+ vaddr += PAGE_SIZE;
+ }
+}
+
void __init kasan_init(void)
{
phys_addr_t _start, _end;
@@ -90,7 +137,15 @@ void __init kasan_init(void)
kasan_populate_early_shadow((void *)KASAN_SHADOW_START,
(void *)kasan_mem_to_shadow((void *)
- VMALLOC_END));
+ VMEMMAP_END));
+ if (IS_ENABLED(CONFIG_KASAN_VMALLOC))
+ kasan_shallow_populate(
+ (void *)kasan_mem_to_shadow((void *)VMALLOC_START),
+ (void *)kasan_mem_to_shadow((void *)VMALLOC_END));
+ else
+ kasan_populate_early_shadow(
+ (void *)kasan_mem_to_shadow((void *)VMALLOC_START),
+ (void *)kasan_mem_to_shadow((void *)VMALLOC_END));
for_each_mem_range(i, &_start, &_end) {
void *start = (void *)_start;
Thanks, this is on for-next.
Re: [PATCH 1/1] kernel/crash_core.c - Add crashkernel=auto for x86 and ARM
Hi Saeed, On 01/22/21 at 05:14pm, Saeed Mirzamohammadi wrote: > Hi, > > > On Jan 21, 2021, at 7:12 PM, Dave Young wrote: > > > > On 01/22/21 at 09:22am, Dave Young wrote: > >> Hi John, > >> > >> On 01/21/21 at 09:32am, john.p.donne...@oracle.com wrote: > >>> On 11/22/20 9:47 PM, Dave Young wrote: > Hi Guilherme, > On 11/22/20 at 12:32pm, Guilherme Piccoli wrote: > > Hi Dave and Kairui, thanks for your responses! OK, if that makes sense > > to you I'm fine with it. I'd just recommend to test recent kernels in > > multiple distros with the minimum "range" to see if 64M is enough for > > crashkernel, maybe we'd need to bump that. > > Giving the different kernel configs and the different userspace > initramfs setup it is hard to get an uniform value for all distributions, > but we can have an interface/kconfig-option for them to provide a value > like this patch > is doing. And it could be improved like Kairui said about some known > kernel added extra values later, probably some more improvements if > doable. > > Thanks > Dave > > >>> > >>> Hi. > >>> > >>> Are we going to move forward with implementing this for X86 and Arm ? > >>> > >>> If other platform maintainers want to include this CONFIG option in their > >>> configuration settings they have a starting point. > >> > >> I would expect this become arch independent. > > > > Clarify a bit, it can be a general config option under arch/Kconfig and > > just put the code in general arch independent part. > > Does this mean that we need to add the option to def_configs in all archs as > well? > I think we do not need to add defconfig, something like this will just work? BTW, it should depend on CRASH_CORE instead of CRASH_DUMP, the logic of parsing crashkernel is in kernel/crash_core.c diff --git a/arch/Kconfig b/arch/Kconfig index af14a567b493..fa6efeb52dc5 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -14,6 +14,11 @@ menu "General architecture-dependent options" config CRASH_CORE bool +config CRASH_AUTO_STR + depends on CRASH_CORE + string "Memory reserved for crash kernel" + default "1G-:128M" + ... help text [snip] ... + config KEXEC_CORE select CRASH_CORE bool [...] > Thanks, > Saeed > > > > >> > >> Saeed, Kairui, would any of you like to update the patch? > >> > >>> > >>> Thank you, > >>> > >>> John. > >>> > >>> ( I am not currently on many of the included dist lists in this email, so > >>> hopefully key contributors are included in this exchange ) > >>> > >> > >> Thanks > >> Dave > Thanks Dave
[PATCH v2 2/3] dma-buf: system_heap: Add pagepool support to system heap
Reuse/abuse the pagepool code from the network code to speed
up allocation performance.
This is similar to the ION pagepool usage, but tries to
utilize generic code instead of a custom implementation.
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix build issue caused by selecting PAGE_POOL w/o NET
as Reported-by: kernel test robot
---
drivers/dma-buf/heaps/Kconfig | 2 +
drivers/dma-buf/heaps/system_heap.c | 68 +++--
2 files changed, 66 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index ecf65204f714..748e840e6edd 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -4,6 +4,8 @@ config DMABUF_HEAPS_DEFERRED_FREE
config DMABUF_HEAPS_SYSTEM
bool "DMA-BUF System Heap"
depends on DMABUF_HEAPS
+ select NET
+ select PAGE_POOL
help
Choose this option to enable the system dmabuf heap. The system heap
is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 17e0e9a68baf..885e30894b77 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
static struct dma_heap *sys_heap;
@@ -53,6 +54,7 @@ static gfp_t order_flags[] = {HIGH_ORDER_GFP, LOW_ORDER_GFP,
LOW_ORDER_GFP};
*/
static const unsigned int orders[] = {8, 4, 0};
#define NUM_ORDERS ARRAY_SIZE(orders)
+struct page_pool *pools[NUM_ORDERS];
static struct sg_table *dup_sg_table(struct sg_table *table)
{
@@ -281,18 +283,59 @@ static void system_heap_vunmap(struct dma_buf *dmabuf,
struct dma_buf_map *map)
dma_buf_map_clear(map);
}
+static int system_heap_clear_pages(struct page **pages, int num, pgprot_t
pgprot)
+{
+ void *addr = vmap(pages, num, VM_MAP, pgprot);
+
+ if (!addr)
+ return -ENOMEM;
+ memset(addr, 0, PAGE_SIZE * num);
+ vunmap(addr);
+ return 0;
+}
+
+static int system_heap_zero_buffer(struct system_heap_buffer *buffer)
+{
+ struct sg_table *sgt = >sg_table;
+ struct sg_page_iter piter;
+ struct page *pages[32];
+ int p = 0;
+ int ret = 0;
+
+ for_each_sgtable_page(sgt, , 0) {
+ pages[p++] = sg_page_iter_page();
+ if (p == ARRAY_SIZE(pages)) {
+ ret = system_heap_clear_pages(pages, p, PAGE_KERNEL);
+ if (ret)
+ return ret;
+ p = 0;
+ }
+ }
+ if (p)
+ ret = system_heap_clear_pages(pages, p, PAGE_KERNEL);
+
+ return ret;
+}
+
static void system_heap_dma_buf_release(struct dma_buf *dmabuf)
{
struct system_heap_buffer *buffer = dmabuf->priv;
struct sg_table *table;
struct scatterlist *sg;
- int i;
+ int i, j;
+
+ /* Zero the buffer pages before adding back to the pool */
+ system_heap_zero_buffer(buffer);
table = >sg_table;
for_each_sg(table->sgl, sg, table->nents, i) {
struct page *page = sg_page(sg);
- __free_pages(page, compound_order(page));
+ for (j = 0; j < NUM_ORDERS; j++) {
+ if (compound_order(page) == orders[j])
+ break;
+ }
+ page_pool_put_full_page(pools[j], page, false);
}
sg_free_table(table);
kfree(buffer);
@@ -322,8 +365,7 @@ static struct page *alloc_largest_available(unsigned long
size,
continue;
if (max_order < orders[i])
continue;
-
- page = alloc_pages(order_flags[i], orders[i]);
+ page = page_pool_alloc_pages(pools[i], order_flags[i]);
if (!page)
continue;
return page;
@@ -428,6 +470,24 @@ static const struct dma_heap_ops system_heap_ops = {
static int system_heap_create(void)
{
struct dma_heap_export_info exp_info;
+ int i;
+
+ for (i = 0; i < NUM_ORDERS; i++) {
+ struct page_pool_params pp;
+
+ memset(, 0, sizeof(pp));
+ pp.order = orders[i];
+ pools[i] = page_pool_create();
+
+ if (IS_ERR(pools[i])) {
+ int j;
+
+ pr_err("%s: page pool creation failed!\n", __func__);
+ for (j = 0; j < i; j++)
+
[PATCH v2 3/3] dma-buf: system_heap: Add deferred freeing to the system heap
Utilize the deferred free helper library in the system heap.
This provides a nice performance bump and puts the
system heap performance on par with ION.
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Rework deferred-free api to use reason enum as suggested by
Suren Baghdasaryan
---
drivers/dma-buf/heaps/Kconfig | 1 +
drivers/dma-buf/heaps/system_heap.c | 32 ++---
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index 748e840e6edd..3f4d7b949301 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -6,6 +6,7 @@ config DMABUF_HEAPS_SYSTEM
depends on DMABUF_HEAPS
select NET
select PAGE_POOL
+ select DMABUF_HEAPS_DEFERRED_FREE
help
Choose this option to enable the system dmabuf heap. The system heap
is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 885e30894b77..747fa2250e84 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -22,6 +22,8 @@
#include
#include
+#include "deferred-free-helper.h"
+
static struct dma_heap *sys_heap;
struct system_heap_buffer {
@@ -32,6 +34,7 @@ struct system_heap_buffer {
struct sg_table sg_table;
int vmap_cnt;
void *vaddr;
+ struct deferred_freelist_item deferred_free;
};
struct dma_heap_attachment {
@@ -317,30 +320,45 @@ static int system_heap_zero_buffer(struct
system_heap_buffer *buffer)
return ret;
}
-static void system_heap_dma_buf_release(struct dma_buf *dmabuf)
+static void system_heap_buf_free(struct deferred_freelist_item *item,
+enum df_reason reason)
{
- struct system_heap_buffer *buffer = dmabuf->priv;
+ struct system_heap_buffer *buffer;
struct sg_table *table;
struct scatterlist *sg;
int i, j;
+ buffer = container_of(item, struct system_heap_buffer, deferred_free);
/* Zero the buffer pages before adding back to the pool */
- system_heap_zero_buffer(buffer);
+ if (reason == DF_NORMAL)
+ if (system_heap_zero_buffer(buffer))
+ reason = DF_UNDER_PRESSURE; // On failure, just free
table = >sg_table;
for_each_sg(table->sgl, sg, table->nents, i) {
struct page *page = sg_page(sg);
- for (j = 0; j < NUM_ORDERS; j++) {
- if (compound_order(page) == orders[j])
- break;
+ if (reason == DF_UNDER_PRESSURE) {
+ __free_pages(page, compound_order(page));
+ } else {
+ for (j = 0; j < NUM_ORDERS; j++) {
+ if (compound_order(page) == orders[j])
+ break;
+ }
+ page_pool_put_full_page(pools[j], page, false);
}
- page_pool_put_full_page(pools[j], page, false);
}
sg_free_table(table);
kfree(buffer);
}
+static void system_heap_dma_buf_release(struct dma_buf *dmabuf)
+{
+ struct system_heap_buffer *buffer = dmabuf->priv;
+
+ deferred_free(>deferred_free, system_heap_buf_free,
buffer->len);
+}
+
static const struct dma_buf_ops system_heap_buf_ops = {
.attach = system_heap_attach,
.detach = system_heap_detach,
--
2.17.1
[PATCH v2 1/3] dma-buf: heaps: Add deferred-free-helper library code
This patch provides infrastructure for deferring buffer frees.
This is a feature ION provided which when used with some form
of a page pool, provides a nice performance boost in an
allocation microbenchmark. The reason it helps is it allows the
page-zeroing to be done out of the normal allocation/free path,
and pushed off to a kthread.
As not all heaps will find this useful, its implemented as
a optional helper library that heaps can utilize.
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix sleep in atomic issue from using a mutex, by switching
to a spinlock as Reported-by: kernel test robot
* Cleanup API to use a reason enum for clarity and add some documentation
comments as suggested by Suren Baghdasaryan.
---
drivers/dma-buf/heaps/Kconfig| 3 +
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/deferred-free-helper.c | 136 +++
drivers/dma-buf/heaps/deferred-free-helper.h | 55
4 files changed, 195 insertions(+)
create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.c
create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.h
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index a5eef06c4226..ecf65204f714 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -1,3 +1,6 @@
+config DMABUF_HEAPS_DEFERRED_FREE
+ bool
+
config DMABUF_HEAPS_SYSTEM
bool "DMA-BUF System Heap"
depends on DMABUF_HEAPS
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 974467791032..4e7839875615 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_DMABUF_HEAPS_DEFERRED_FREE) += deferred-free-helper.o
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/deferred-free-helper.c
b/drivers/dma-buf/heaps/deferred-free-helper.c
new file mode 100644
index ..cf04148167a2
--- /dev/null
+++ b/drivers/dma-buf/heaps/deferred-free-helper.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Deferred dmabuf freeing helper
+ *
+ * Copyright (C) 2020 Linaro, Ltd.
+ *
+ * Based on the ION page pool code
+ * Copyright (C) 2011 Google, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "deferred-free-helper.h"
+
+static LIST_HEAD(free_list);
+static size_t list_size;
+wait_queue_head_t freelist_waitqueue;
+struct task_struct *freelist_task;
+static DEFINE_SPINLOCK(free_list_lock);
+
+void deferred_free(struct deferred_freelist_item *item,
+ void (*free)(struct deferred_freelist_item*,
+ enum df_reason),
+ size_t size)
+{
+ unsigned long flags;
+
+ INIT_LIST_HEAD(>list);
+ item->size = size;
+ item->free = free;
+
+ spin_lock_irqsave(_list_lock, flags);
+ list_add(>list, _list);
+ list_size += size;
+ spin_unlock_irqrestore(_list_lock, flags);
+ wake_up(_waitqueue);
+}
+
+static size_t free_one_item(enum df_reason reason)
+{
+ unsigned long flags;
+ size_t size = 0;
+ struct deferred_freelist_item *item;
+
+ spin_lock_irqsave(_list_lock, flags);
+ if (list_empty(_list)) {
+ spin_unlock_irqrestore(_list_lock, flags);
+ return 0;
+ }
+ item = list_first_entry(_list, struct deferred_freelist_item,
list);
+ list_del(>list);
+ size = item->size;
+ list_size -= size;
+ spin_unlock_irqrestore(_list_lock, flags);
+
+ item->free(item, reason);
+ return size;
+}
+
+static unsigned long get_freelist_size(void)
+{
+ unsigned long size;
+ unsigned long flags;
+
+ spin_lock_irqsave(_list_lock, flags);
+ size = list_size;
+ spin_unlock_irqrestore(_list_lock, flags);
+ return size;
+}
+
+static unsigned long freelist_shrink_count(struct shrinker *shrinker,
+ struct shrink_control *sc)
+{
+ return get_freelist_size();
+}
+
+static unsigned long freelist_shrink_scan(struct shrinker *shrinker,
+ struct shrink_control *sc)
+{
+ int total_freed = 0;
+
+ if (sc->nr_to_scan == 0)
+ return 0;
+
+ while (total_freed < sc->nr_to_scan) {
+ int freed = free_one_item(DF_UNDER_PRESSURE);
+
+ if (!freed)
+ break;
+
+ total_freed += freed;
+ }
+
+ return
[PATCH v2 6/6] of/device: Don't NULLify match table in of_match_device() with CONFIG_OF=n
This effectively reverts 1db73ae39a97 ("of/device: Nullify match table
in of_match_device() for CONFIG_OF=n") because that commit makes it more
surprising to users of this API that the arguments may never be
referenced by any code. This is because the pre-processor will replace
the argument with NULL and then the match table will be left unreferenced
by any code but the compiler optimizer doesn't know to drop it. This can
lead to compilers warning that match tables are unused, when we really
want to pass the match table to the API but have the compiler see that
it's all inlined and not used and then drop the match table while
silencing the warning. We're being too smart here and not giving the
compiler the chance to do dead code elimination.
Signed-off-by: Stephen Boyd
Acked-by: Frank Rowand
Cc: Arnd Bergmann
Cc: Geert Uytterhoeven
Cc: Rob Herring
Cc: Frank Rowand
---
Please ack so Rob can apply.
include/linux/of_device.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index 07ca187fc5e4..937f32f6aecb 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -99,13 +99,11 @@ static inline int of_device_uevent_modalias(struct device
*dev,
static inline void of_device_node_put(struct device *dev) { }
-static inline const struct of_device_id *__of_match_device(
+static inline const struct of_device_id *of_match_device(
const struct of_device_id *matches, const struct device *dev)
{
return NULL;
}
-#define of_match_device(matches, dev) \
- __of_match_device(of_match_ptr(matches), (dev))
static inline struct device_node *of_cpu_device_node_get(int cpu)
{
--
https://chromeos.dev
[PATCH v2 5/6] hwmon: (lm70) Avoid undefined reference to match table
We're going to remove of_match_ptr() from the definition of
of_match_device() when CONFIG_OF=n. This way we can always be certain
that of_match_device() acts the same when CONFIG_OF is set and when it
isn't. Add of_match_ptr() here so that this doesn't break when that
change is made to the of_match_device() API.
Signed-off-by: Stephen Boyd
Acked-by: Guenter Roeck
Cc: Arnd Bergmann
Cc: Geert Uytterhoeven
Cc: Jean Delvare
Cc: Guenter Roeck
Cc: Rob Herring
Cc: Frank Rowand
Cc:
---
Please ack so Rob can apply.
drivers/hwmon/lm70.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/lm70.c b/drivers/hwmon/lm70.c
index ae2b84263a44..e3153ae80634 100644
--- a/drivers/hwmon/lm70.c
+++ b/drivers/hwmon/lm70.c
@@ -178,7 +178,7 @@ static int lm70_probe(struct spi_device *spi)
struct lm70 *p_lm70;
int chip;
- of_match = of_match_device(lm70_of_ids, >dev);
+ of_match = of_match_device(of_match_ptr(lm70_of_ids), >dev);
if (of_match)
chip = (int)(uintptr_t)of_match->data;
else {
--
https://chromeos.dev
[PATCH v2 3/6] serial: stm32: Use of_device_get_match_data()
This driver casts away the constness of struct stm32_usart_info that is
pointed to by the of match table. Use of_device_get_match_data() instead
of of_match_device() here and push the const throughout the code so that
we don't cast away const. This nicely avoids referencing the match table
when it is undefined with configurations where CONFIG_OF=n and fixes the
const issues.
Signed-off-by: Stephen Boyd
Acked-by: Greg Kroah-Hartman
Cc: Arnd Bergmann
Cc: Geert Uytterhoeven
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Maxime Coquelin
Cc: Alexandre Torgue
Cc: Rob Herring
Cc: Frank Rowand
Cc:
---
Please ack so Rob can apply.
drivers/tty/serial/stm32-usart.c | 71 +++-
drivers/tty/serial/stm32-usart.h | 2 +-
2 files changed, 35 insertions(+), 38 deletions(-)
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index f4de32d3f2af..99f04db73830 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -99,8 +99,8 @@ static int stm32_config_rs485(struct uart_port *port,
struct serial_rs485 *rs485conf)
{
struct stm32_port *stm32_port = to_stm32_port(port);
- struct stm32_usart_offsets *ofs = _port->info->ofs;
- struct stm32_usart_config *cfg = _port->info->cfg;
+ const struct stm32_usart_offsets *ofs = _port->info->ofs;
+ const struct stm32_usart_config *cfg = _port->info->cfg;
u32 usartdiv, baud, cr1, cr3;
bool over8;
@@ -166,7 +166,7 @@ static int stm32_pending_rx(struct uart_port *port, u32
*sr, int *last_res,
bool threaded)
{
struct stm32_port *stm32_port = to_stm32_port(port);
- struct stm32_usart_offsets *ofs = _port->info->ofs;
+ const struct stm32_usart_offsets *ofs = _port->info->ofs;
enum dma_status status;
struct dma_tx_state state;
@@ -191,7 +191,7 @@ static unsigned long stm32_get_char(struct uart_port *port,
u32 *sr,
int *last_res)
{
struct stm32_port *stm32_port = to_stm32_port(port);
- struct stm32_usart_offsets *ofs = _port->info->ofs;
+ const struct stm32_usart_offsets *ofs = _port->info->ofs;
unsigned long c;
if (stm32_port->rx_ch) {
@@ -211,7 +211,7 @@ static void stm32_receive_chars(struct uart_port *port,
bool threaded)
{
struct tty_port *tport = >state->port;
struct stm32_port *stm32_port = to_stm32_port(port);
- struct stm32_usart_offsets *ofs = _port->info->ofs;
+ const struct stm32_usart_offsets *ofs = _port->info->ofs;
unsigned long c;
u32 sr;
char flag;
@@ -282,7 +282,7 @@ static void stm32_tx_dma_complete(void *arg)
{
struct uart_port *port = arg;
struct stm32_port *stm32port = to_stm32_port(port);
- struct stm32_usart_offsets *ofs = >info->ofs;
+ const struct stm32_usart_offsets *ofs = >info->ofs;
stm32_clr_bits(port, ofs->cr3, USART_CR3_DMAT);
stm32port->tx_dma_busy = false;
@@ -294,7 +294,7 @@ static void stm32_tx_dma_complete(void *arg)
static void stm32_tx_interrupt_enable(struct uart_port *port)
{
struct stm32_port *stm32_port = to_stm32_port(port);
- struct stm32_usart_offsets *ofs = _port->info->ofs;
+ const struct stm32_usart_offsets *ofs = _port->info->ofs;
/*
* Enables TX FIFO threashold irq when FIFO is enabled,
@@ -309,7 +309,7 @@ static void stm32_tx_interrupt_enable(struct uart_port
*port)
static void stm32_tx_interrupt_disable(struct uart_port *port)
{
struct stm32_port *stm32_port = to_stm32_port(port);
- struct stm32_usart_offsets *ofs = _port->info->ofs;
+ const struct stm32_usart_offsets *ofs = _port->info->ofs;
if (stm32_port->fifoen)
stm32_clr_bits(port, ofs->cr3, USART_CR3_TXFTIE);
@@ -320,7 +320,7 @@ static void stm32_tx_interrupt_disable(struct uart_port
*port)
static void stm32_transmit_chars_pio(struct uart_port *port)
{
struct stm32_port *stm32_port = to_stm32_port(port);
- struct stm32_usart_offsets *ofs = _port->info->ofs;
+ const struct stm32_usart_offsets *ofs = _port->info->ofs;
struct circ_buf *xmit = >state->xmit;
if (stm32_port->tx_dma_busy) {
@@ -347,7 +347,7 @@ static void stm32_transmit_chars_pio(struct uart_port *port)
static void stm32_transmit_chars_dma(struct uart_port *port)
{
struct stm32_port *stm32port = to_stm32_port(port);
- struct stm32_usart_offsets *ofs = >info->ofs;
+ const struct stm32_usart_offsets *ofs = >info->ofs;
struct circ_buf *xmit = >state->xmit;
struct dma_async_tx_descriptor *desc = NULL;
unsigned int count, i;
@@ -407,7 +407,7 @@ static void stm32_transmit_chars_dma(struct uart_port *port)
static void stm32_transmit_chars(struct uart_port *port)
{
struct stm32_port *stm32_port = to_stm32_port(port);
- struct
[PATCH v2 1/6] media: renesas-ceu: Use of_device_get_match_data()
This driver can use the replacement API instead of calling
of_match_device() and then dereferencing the pointer that is returned.
This nicely avoids referencing the match table when it is undefined with
configurations where CONFIG_OF=n.
Signed-off-by: Stephen Boyd
Acked-by: Mauro Carvalho Chehab
Acked-by: Jacopo Mondi
Cc: Arnd Bergmann
Cc: Geert Uytterhoeven
Cc: Jacopo Mondi
Cc: Mauro Carvalho Chehab
Cc: Rob Herring
Cc: Frank Rowand
Cc:
Cc:
---
Please ack so Rob can apply.
drivers/media/platform/renesas-ceu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/renesas-ceu.c
b/drivers/media/platform/renesas-ceu.c
index 4a633ad0e8fa..352e7c84d5ba 100644
--- a/drivers/media/platform/renesas-ceu.c
+++ b/drivers/media/platform/renesas-ceu.c
@@ -1679,7 +1679,7 @@ static int ceu_probe(struct platform_device *pdev)
v4l2_async_notifier_init(>notifier);
if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
- ceu_data = of_match_device(ceu_of_match, dev)->data;
+ ceu_data = of_device_get_match_data(dev);
num_subdevs = ceu_parse_dt(ceudev);
} else if (dev->platform_data) {
/* Assume SH4 if booting with platform data. */
--
https://chromeos.dev
[PATCH v2 2/6] drivers: net: davinci_mdio: Use of_device_get_match_data()
Use the more modern API to get the match data out of the of match table.
This saves some code, lines, and nicely avoids referencing the match
table when it is undefined with configurations where CONFIG_OF=n.
Signed-off-by: Stephen Boyd
Cc: Arnd Bergmann
Cc: Geert Uytterhoeven
Cc: Grygorii Strashko
Cc: "David S. Miller"
Cc: Rob Herring
Cc: Frank Rowand
Cc:
---
Please ack so Rob can apply.
drivers/net/ethernet/ti/davinci_mdio.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c
b/drivers/net/ethernet/ti/davinci_mdio.c
index cfff3d48807a..a4efd5e35158 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -358,20 +358,16 @@ static int davinci_mdio_probe(struct platform_device
*pdev)
}
if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
- const struct of_device_id *of_id;
+ const struct davinci_mdio_of_param *of_mdio_data;
ret = davinci_mdio_probe_dt(>pdata, pdev);
if (ret)
return ret;
snprintf(data->bus->id, MII_BUS_ID_SIZE, "%s", pdev->name);
- of_id = of_match_device(davinci_mdio_of_mtable, >dev);
- if (of_id) {
- const struct davinci_mdio_of_param *of_mdio_data;
-
- of_mdio_data = of_id->data;
- if (of_mdio_data)
- autosuspend_delay_ms =
+ of_mdio_data = of_device_get_match_data(>dev);
+ if (of_mdio_data) {
+ autosuspend_delay_ms =
of_mdio_data->autosuspend_delay_ms;
}
} else {
--
https://chromeos.dev
[PATCH v2 4/6] usb: usb251xb: Use of_device_get_match_data()
Use the more modern API here instead of using of_match_device() and
avoid casting away const from the returned pointer by pushing the const
type through to the users. This nicely avoids referencing the match
table when it is undefined with configurations where CONFIG_OF=n and
avoids const issues.
Signed-off-by: Stephen Boyd
Acked-by: Greg Kroah-Hartman
Cc: Arnd Bergmann
Cc: Geert Uytterhoeven
Cc: Richard Leitner
Cc: Greg Kroah-Hartman
Cc: Rob Herring
Cc: Frank Rowand
Cc:
---
Please ack so Rob can apply.
drivers/usb/misc/usb251xb.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/misc/usb251xb.c b/drivers/usb/misc/usb251xb.c
index 29fe5771c21b..507deef1f709 100644
--- a/drivers/usb/misc/usb251xb.c
+++ b/drivers/usb/misc/usb251xb.c
@@ -396,7 +396,7 @@ static void usb251xb_get_ports_field(struct usb251xb *hub,
}
static int usb251xb_get_ofdata(struct usb251xb *hub,
- struct usb251xb_data *data)
+ const struct usb251xb_data *data)
{
struct device *dev = hub->dev;
struct device_node *np = dev->of_node;
@@ -630,7 +630,7 @@ static const struct of_device_id usb251xb_of_match[] = {
MODULE_DEVICE_TABLE(of, usb251xb_of_match);
#else /* CONFIG_OF */
static int usb251xb_get_ofdata(struct usb251xb *hub,
- struct usb251xb_data *data)
+ const struct usb251xb_data *data)
{
return 0;
}
@@ -647,13 +647,11 @@ static int usb251xb_probe(struct usb251xb *hub)
{
struct device *dev = hub->dev;
struct device_node *np = dev->of_node;
- const struct of_device_id *of_id = of_match_device(usb251xb_of_match,
- dev);
+ const struct usb251xb_data *usb_data = of_device_get_match_data(dev);
int err;
- if (np && of_id) {
- err = usb251xb_get_ofdata(hub,
- (struct usb251xb_data *)of_id->data);
+ if (np && usb_data) {
+ err = usb251xb_get_ofdata(hub, usb_data);
if (err) {
dev_err(dev, "failed to get ofdata: %d\n", err);
return err;
--
https://chromeos.dev
[PATCH v2 0/6] Stop NULLifying match pointer in of_match_device()
(This is a continuation of this series[1] per Rob's request. I've picked up the acks, etc. with b4 and compile tested the patches along with an arm64 allmodconfig build. Presumably Rob will pick these up directly.) of_match_device() uses of_match_ptr() to make the match table argument NULL via the pre-processor when CONFIG_OF=n. This makes life harder for compilers who think that match tables are never used and warn about unused variables when CONFIG_OF=n. This series changes various callers to use of_device_get_match_data() instead, which doesn't have this problem, and removes the of_match_ptr() usage from of_match_device() so that the compiler can stop complaining about unused variables. It will do dead code elimination instead and remove the match table if it isn't actually used. [1] https://lore.kernel.org/r/20191004214334.149976-1-swb...@chromium.org Cc: Alexandre Torgue Cc: Arnd Bergmann Cc: "David S. Miller" Cc: Frank Rowand Cc: Geert Uytterhoeven Cc: Greg Kroah-Hartman Cc: Grygorii Strashko Cc: Guenter Roeck Cc: Jacopo Mondi Cc: Jean Delvare Cc: Jiri Slaby Cc: Cc: , Cc: Cc: Cc: Cc: Cc: Cc: Mauro Carvalho Chehab Cc: Maxime Coquelin Cc: Richard Leitner Cc: Rob Herring Stephen Boyd (6): media: renesas-ceu: Use of_device_get_match_data() drivers: net: davinci_mdio: Use of_device_get_match_data() serial: stm32: Use of_device_get_match_data() usb: usb251xb: Use of_device_get_match_data() hwmon: (lm70) Avoid undefined reference to match table of/device: Don't NULLify match table in of_match_device() with CONFIG_OF=n drivers/hwmon/lm70.c | 2 +- drivers/media/platform/renesas-ceu.c | 2 +- drivers/net/ethernet/ti/davinci_mdio.c | 12 ++--- drivers/tty/serial/stm32-usart.c | 71 -- drivers/tty/serial/stm32-usart.h | 2 +- drivers/usb/misc/usb251xb.c| 12 ++--- include/linux/of_device.h | 4 +- 7 files changed, 47 insertions(+), 58 deletions(-) base-commit: 19c329f6808995b142b3966301f217c831e7cf31 -- https://chromeos.dev
Re: [PATCH V6 5/6] of: unittest: Create overlay_common.dtsi and testcases_common.dtsi
On Fri, Jan 22, 2021 at 04:20:35PM +0530, Viresh Kumar wrote: > In order to build-test the same unit-test files using fdtoverlay tool, > move the device nodes from the existing overlay_base.dts and > testcases_common.dts files to .dtsi files. The .dts files now include > the new .dtsi files, resulting in exactly the same behavior as earlier. > > The .dtsi files can now be reused for compile time tests using > fdtoverlay (will be done in a later patch). > > This is required because the base files passed to fdtoverlay tool > shouldn't be overlays themselves (i.e. shouldn't have the /plugin/; > tag). > > Signed-off-by: Viresh Kumar > --- > drivers/of/unittest-data/overlay_base.dts | 90 +- > drivers/of/unittest-data/overlay_common.dtsi | 91 +++ > drivers/of/unittest-data/testcases.dts| 17 +--- > .../of/unittest-data/testcases_common.dtsi| 18 > 4 files changed, 111 insertions(+), 105 deletions(-) > create mode 100644 drivers/of/unittest-data/overlay_common.dtsi > create mode 100644 drivers/of/unittest-data/testcases_common.dtsi > > diff --git a/drivers/of/unittest-data/overlay_base.dts > b/drivers/of/unittest-data/overlay_base.dts > index 99ab9d12d00b..ab9014589c5d 100644 > --- a/drivers/of/unittest-data/overlay_base.dts > +++ b/drivers/of/unittest-data/overlay_base.dts > @@ -2,92 +2,4 @@ > /dts-v1/; > /plugin/; This still makes no sense to me. Is this data intended as a base tree, or as an overlay? If it's an overlay, what are the constraints on the base tree it's supposed to apply to. This patch is treating it as both in different places, but that's such a bizarre usecase it needs detailed justification. It really looks like the unittest stuff is doing some very bogus stuff that should be fixed first, before trying to do this on top. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [PATCH v16 00/17] KVM RISC-V Support
On Fri, 15 Jan 2021 04:18:29 PST (-0800), Anup Patel wrote: This series adds initial KVM RISC-V support. Currently, we are able to boot Linux on RV64/RV32 Guest with multiple VCPUs. Thanks. IIUC the spec is still in limbo at the RISC-V foundation? I haven't really been paying attention lately. Key aspects of KVM RISC-V added by this series are: 1. No RISC-V specific KVM IOCTL 2. Minimal possible KVM world-switch which touches only GPRs and few CSRs 3. Both RV64 and RV32 host supported 4. Full Guest/VM switch is done via vcpu_get/vcpu_put infrastructure 5. KVM ONE_REG interface for VCPU register access from user-space 6. PLIC emulation is done in user-space 7. Timer and IPI emuation is done in-kernel 8. Both Sv39x4 and Sv48x4 supported for RV64 host 9. MMU notifiers supported 10. Generic dirtylog supported 11. FP lazy save/restore supported 12. SBI v0.1 emulation for KVM Guest available 13. Forward unhandled SBI calls to KVM userspace 14. Hugepage support for Guest/VM 15. IOEVENTFD support for Vhost Here's a brief TODO list which we will work upon after this series: 1. SBI v0.2 emulation in-kernel 2. SBI v0.2 hart state management emulation in-kernel 3. In-kernel PLIC emulation 4. . and more . This series can be found in riscv_kvm_v16 branch at: https//github.com/avpatel/linux.git Our work-in-progress KVMTOOL RISC-V port can be found in riscv_v6 branch at: https//github.com/avpatel/kvmtool.git The QEMU RISC-V hypervisor emulation is done by Alistair and is available in master branch at: https://git.qemu.org/git/qemu.git To play around with KVM RISC-V, refer KVM RISC-V wiki at: https://github.com/kvm-riscv/howto/wiki https://github.com/kvm-riscv/howto/wiki/KVM-RISCV64-on-QEMU https://github.com/kvm-riscv/howto/wiki/KVM-RISCV64-on-Spike Changes since v15: - Rebased on Linux-5.11-rc3 - Fixed kvm_stage2_map() to use gfn_to_pfn_prot() for determing writeability of a host pfn. - Use "__u64" in-place of "u64" and "__u32" in-place of "u32" for uapi/asm/kvm.h Changes since v14: - Rebased on Linux-5.10-rc3 - Fixed Stage2 (G-stage) PDG allocation to ensure it is 16KB aligned Changes since v13: - Rebased on Linux-5.9-rc3 - Fixed kvm_riscv_vcpu_set_reg_csr() for SIP updation in PATCH5 - Fixed instruction length computation in PATCH7 - Added ioeventfd support in PATCH7 - Ensure HSTATUS.SPVP is set to correct value before using HLV/HSV intructions in PATCH7 - Fixed stage2_map_page() to set PTE 'A' and 'D' bits correctly in PATCH10 - Added stage2 dirty page logging in PATCH10 - Allow KVM user-space to SET/GET SCOUNTER CSR in PATCH5 - Save/restore SCOUNTEREN in PATCH6 - Reduced quite a few instructions for __kvm_riscv_switch_to() by using CSR swap instruction in PATCH6 - Detect and use Sv48x4 when available in PATCH10 Changes since v12: - Rebased patches on Linux-5.8-rc4 - By default enable all counters in HCOUNTEREN - RISC-V H-Extension v0.6.1 spec support Changes since v11: - Rebased patches on Linux-5.7-rc3 - Fixed typo in typecast of stage2_map_size define - Introduced struct kvm_cpu_trap to represent trap details and use it as function parameter wherever applicable - Pass memslot to kvm_riscv_stage2_map() for supporing dirty page logging in future - RISC-V H-Extension v0.6 spec support - Send-out first three patches as separate series so that it can be taken by Palmer for Linux RISC-V Changes since v10: - Rebased patches on Linux-5.6-rc5 - Reduce RISCV_ISA_EXT_MAX from 256 to 64 - Separate PATCH for removing N-extension related defines - Added comments as requested by Palmer - Fixed HIDELEG CSR programming Changes since v9: - Rebased patches on Linux-5.5-rc3 - Squash PATCH19 and PATCH20 into PATCH5 - Squash PATCH18 into PATCH11 - Squash PATCH17 into PATCH16 - Added ONE_REG interface for VCPU timer in PATCH13 - Use HTIMEDELTA for VCPU timer in PATCH13 - Updated KVM RISC-V mailing list in MAINTAINERS entry - Update KVM kconfig option to depend on RISCV_SBI and MMU - Check for SBI v0.2 and SBI v0.2 RFENCE extension at boot-time - Use SBI v0.2 RFENCE extension in VMID implementation - Use SBI v0.2 RFENCE extension in Stage2 MMU implementation - Use SBI v0.2 RFENCE extension in SBI implementation - Moved to RISC-V Hypervisor v0.5 draft spec - Updated Documentation/virt/kvm/api.txt for timer ONE_REG interface Changes since v8: - Rebased series on Linux-5.4-rc3 and Atish's SBI v0.2 patches - Use HRTIMER_MODE_REL instead of HRTIMER_MODE_ABS in timer emulation - Fixed kvm_riscv_stage2_map() to handle hugepages - Added patch to forward unhandled SBI calls to user-space - Added patch for iterative/recursive stage2 page table programming - Added patch to remove per-CPU vsip_shadow variable - Added patch to fix race-condition in kvm_riscv_vcpu_sync_interrupts() Changes since v7: - Rebased series on Linux-5.4-rc1 and Atish's SBI v0.2 patches - Removed PATCH1, PATCH3, and PATCH20 because these already merged - Use kernel doc
Re: [PATCH 1/1] scsi: sd: use max_xfer_blocks for set rw_max if max_xfer_blocks is available
Damien, >> How about set larger valid value between sdkp->max_xfer_blocks, >> and sdkp->opt_xfer_blocks to rw_max? > > Again, if your device reports an opt_xfer_blocks value that is too > small for its own good, that is a problem with this device. Correct. It is very much intentional that we do not default to issuing the largest commands supported by the physical hardware. If the device is not reporting an optimal transfer size, and the block layer default is too small, the solution is to adjust max_sectors_kb in sysfs (by adding a udev rule, for instance). -- Martin K. Petersen Oracle Linux Engineering
[PATCH] RISC-V: probes: Treat the instruction stream as host-endian
From: Palmer Dabbelt
Neither of these are actually correct: the instruction stream is defined
(for versions of the ISA manual newer than 2.2) as a stream of 16-bit
little-endian parcels, which is different than just being little-endian.
In theory we should represent this as a type, but we don't have any
concrete plans for the big endian stuff so it doesn't seem worth the
time -- we've got variants of this all over the place.
Instead I'm just dropping the unnecessary type conversion, which is a
NOP on LE systems but causes an sparse error as the types are all mixed
up.
Reported-by: kernel test robot
Signed-off-by: Palmer Dabbelt
---
arch/riscv/kernel/probes/decode-insn.c | 2 +-
arch/riscv/kernel/probes/kprobes.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/kernel/probes/decode-insn.c
b/arch/riscv/kernel/probes/decode-insn.c
index 0876c304ca77..0ed043acc882 100644
--- a/arch/riscv/kernel/probes/decode-insn.c
+++ b/arch/riscv/kernel/probes/decode-insn.c
@@ -16,7 +16,7 @@
enum probe_insn __kprobes
riscv_probe_decode_insn(probe_opcode_t *addr, struct arch_probe_insn *api)
{
- probe_opcode_t insn = le32_to_cpu(*addr);
+ probe_opcode_t insn = *addr;
/*
* Reject instructions list:
diff --git a/arch/riscv/kernel/probes/kprobes.c
b/arch/riscv/kernel/probes/kprobes.c
index e60893bd87db..a2ec18662fee 100644
--- a/arch/riscv/kernel/probes/kprobes.c
+++ b/arch/riscv/kernel/probes/kprobes.c
@@ -57,7 +57,7 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
}
/* copy instruction */
- p->opcode = le32_to_cpu(*p->addr);
+ p->opcode = *p->addr;
/* decode instruction */
switch (riscv_probe_decode_insn(p->addr, >ainsn.api)) {
--
2.30.0.280.ga3ce27912f-goog
Re: [PATCH v2 1/5] dt-bindings: net: renesas,etheravb: Add r8a779a0 support
On Thu, 21 Jan 2021 11:06:15 +0100 Wolfram Sang wrote: > Document the compatible value for the RAVB block in the Renesas R-Car > V3U (R8A779A0) SoC. This variant has no stream buffer, so we only need > to add the new compatible and add it to the TX delay block. > > Reviewed-by: Geert Uytterhoeven > Acked-by: Rob Herring > Signed-off-by: Wolfram Sang > --- > > Please apply via netdev tree. Done, thank you!
Re: [PATCH] net: fec: put child node on error path
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Wed, 20 Jan 2021 04:20:37 -0800 you wrote:
> Also decrement the reference count of child device on error path.
>
> Fixes: 3e782985cb3c ("net: ethernet: fec: Allow configuration of MDIO bus
> speed")
> Signed-off-by: Pan Bian
> ---
> drivers/net/ethernet/freescale/fec_main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Here is the summary with links:
- net: fec: put child node on error path
https://git.kernel.org/netdev/net/c/0607a2cddb60
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH net-next] sfc: reduce the number of requested xdp ev queues
Hello: This patch was applied to netdev/net-next.git (refs/heads/master): On Wed, 20 Jan 2021 13:27:59 -0800 you wrote: > Without this change the driver tries to allocate too many queues, > breaching the number of available msi-x interrupts on machines > with many logical cpus and default adapter settings: > > Insufficient resources for 12 XDP event queues (24 other channels, max 32) > > Which in turn triggers EINVAL on XDP processing: > > [...] Here is the summary with links: - [net-next] sfc: reduce the number of requested xdp ev queues https://git.kernel.org/netdev/net-next/c/e26ca4b53582 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: BPF: unbounded bpf_map_free_deferred problem
On Fri, Jan 22, 2021 at 4:42 PM Tetsuo Handa wrote: > > Hello, BPF developers. > > Alexey Kardashevskiy is reporting that system_wq gets stuck due to flooding of > unbounded bpf_map_free_deferred work. Use of WQ_MEM_RECLAIM | WQ_HIGHPRI | > WQ_UNBOUND > workqueue did not solve this problem. Is it possible that a refcount leak > somewhere > preventing bpf_map_free_deferred from completing? Please see > https://lkml.kernel.org/r/CACT4Y+Z+kwPM=WUzJ-e359PWeLLqmF0w4Yxp1spzZ=+j0ek...@mail.gmail.com > . > Which map does the reproducer create? And where exactly do those work block on? Different map->ops->map_free() waits for different reasons, for example, htab_map_free() waits for flying htab_elem_free_rcu(). I can't immediately see how they could wait for each other, if this is what you meant above. Thanks.
Re: [PATCH] net: Simplify the calculation of variables
On Fri, 22 Jan 2021 16:57:47 +0800 Jiapeng Zhong wrote:
> Fix the following coccicheck warnings:
>
> ./net/ipv4/esp4_offload.c:288:32-34: WARNING !A || A && B is
> equivalent to !A || B.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Zhong
> ---
> net/ipv4/esp4_offload.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/esp4_offload.c b/net/ipv4/esp4_offload.c
> index 5bda5ae..9ba8cc5 100644
> --- a/net/ipv4/esp4_offload.c
> +++ b/net/ipv4/esp4_offload.c
> @@ -285,7 +285,7 @@ static int esp_xmit(struct xfrm_state *x, struct sk_buff
> *skb, netdev_features_
> esp.esph = ip_esp_hdr(skb);
>
>
> - if (!hw_offload || (hw_offload && !skb_is_gso(skb))) {
> + if (!hw_offload || (!skb_is_gso(skb))) {
You can drop the parenthesis around !skb_is_gso(skb) now.
> esp.nfrags = esp_output_head(x, skb, );
> if (esp.nfrags < 0)
> return esp.nfrags;
Re: [PATCH] scsi: megaraid: fix ifnullfree.cocci warnings
Julia, > NULL check before vfree is not needed. > > Generated by: scripts/coccinelle/free/ifnullfree.cocci Applied to 5.12/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v2 net-next] vmxnet3: Remove buf_info from device
On Fri, 22 Jan 2021 00:30:51 -0800 Ronak Doshi wrote: > + tq->buf_info = kcalloc_node(tq->tx_ring.size, sizeof(tq->buf_info[0]), > + GFP_KERNEL | __GFP_ZERO, > + dev_to_node(>pdev->dev)); no need to pass __GFP_ZERO to kcalloc
Re: [External] Re: [PATCH v13 03/12] mm: hugetlb: free the vmemmap pages associated with each HugeTLB page
On Sat, Jan 23, 2021 at 9:00 AM Mike Kravetz wrote:
>
> X-Gm-Spam: 0
> X-Gm-Phishy: 0
>
> On 1/17/21 7:10 AM, Muchun Song wrote:
> > Every HugeTLB has more than one struct page structure. We __know__ that
> > we only use the first 4(HUGETLB_CGROUP_MIN_ORDER) struct page structures
> > to store metadata associated with each HugeTLB.
> >
> > There are a lot of struct page structures associated with each HugeTLB
> > page. For tail pages, the value of compound_head is the same. So we can
> > reuse first page of tail page structures. We map the virtual addresses
> > of the remaining pages of tail page structures to the first tail page
> > struct, and then free these page frames. Therefore, we need to reserve
> > two pages as vmemmap areas.
> >
> > When we allocate a HugeTLB page from the buddy, we can free some vmemmap
> > pages associated with each HugeTLB page. It is more appropriate to do it
> > in the prep_new_huge_page().
> >
> > The free_vmemmap_pages_per_hpage(), which indicates how many vmemmap
> > pages associated with a HugeTLB page can be freed, returns zero for
> > now, which means the feature is disabled. We will enable it once all
> > the infrastructure is there.
> >
> > Signed-off-by: Muchun Song
> > ---
> > include/linux/bootmem_info.h | 27 +-
> > include/linux/mm.h | 3 +
> > mm/Makefile | 1 +
> > mm/hugetlb.c | 3 +
> > mm/hugetlb_vmemmap.c | 211
> > +++
> > mm/hugetlb_vmemmap.h | 20
> > mm/sparse-vmemmap.c | 198
> > 7 files changed, 462 insertions(+), 1 deletion(-)
> > create mode 100644 mm/hugetlb_vmemmap.c
> > create mode 100644 mm/hugetlb_vmemmap.h
>
> Thank you for the continued updates! Just some comments below.
> I am hoping that others can take a look so we can move this forward.
> I do not see any obvious issues.
Yeah, hope more reviewers will participate in this. :)
>
> > diff --git a/include/linux/bootmem_info.h b/include/linux/bootmem_info.h
> > index 4ed6dee1adc9..ec03a624dfa2 100644
> > --- a/include/linux/bootmem_info.h
> > +++ b/include/linux/bootmem_info.h
> > @@ -2,7 +2,7 @@
> > #ifndef __LINUX_BOOTMEM_INFO_H
> > #define __LINUX_BOOTMEM_INFO_H
> >
> > -#include
> > +#include
> >
> > /*
> > * Types for free bootmem stored in page->lru.next. These have to be in
> > @@ -22,6 +22,27 @@ void __init register_page_bootmem_info_node(struct
> > pglist_data *pgdat);
> > void get_page_bootmem(unsigned long info, struct page *page,
> > unsigned long type);
> > void put_page_bootmem(struct page *page);
> > +
> > +/*
> > + * Any memory allocated via the memblock allocator and not via the
> > + * buddy will be marked reserved already in the memmap. For those
> > + * pages, we can call this function to free it to buddy allocator.
> > + */
> > +static inline void free_bootmem_page(struct page *page)
> > +{
> > + unsigned long magic = (unsigned long)page->freelist;
> > +
> > + /*
> > + * The reserve_bootmem_region sets the reserved flag on bootmem
> > + * pages.
> > + */
> > + VM_BUG_ON_PAGE(page_ref_count(page) != 2, page);
> > +
> > + if (magic == SECTION_INFO || magic == MIX_SECTION_INFO)
> > + put_page_bootmem(page);
> > + else
> > + VM_BUG_ON_PAGE(1, page);
> > +}
> > #else
> > static inline void register_page_bootmem_info_node(struct pglist_data
> > *pgdat)
> > {
> > @@ -35,6 +56,10 @@ static inline void get_page_bootmem(unsigned long info,
> > struct page *page,
> > unsigned long type)
> > {
> > }
> > +
> > +static inline void free_bootmem_page(struct page *page)
> > +{
> > +}
> > #endif
> >
> > #endif /* __LINUX_BOOTMEM_INFO_H */
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index eabe7d9f80d8..f928994ed273 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -3005,6 +3005,9 @@ static inline void print_vma_addr(char *prefix,
> > unsigned long rip)
> > }
> > #endif
> >
> > +void vmemmap_remap_free(unsigned long start, unsigned long end,
> > + unsigned long reuse);
> > +
> > void *sparse_buffer_alloc(unsigned long size);
> > struct page * __populate_section_memmap(unsigned long pfn,
> > unsigned long nr_pages, int nid, struct vmem_altmap *altmap);
> > diff --git a/mm/Makefile b/mm/Makefile
> > index ed4b88fa0f5e..056801d8daae 100644
> > --- a/mm/Makefile
> > +++ b/mm/Makefile
> > @@ -71,6 +71,7 @@ obj-$(CONFIG_FRONTSWAP) += frontswap.o
> > obj-$(CONFIG_ZSWAP) += zswap.o
> > obj-$(CONFIG_HAS_DMA)+= dmapool.o
> > obj-$(CONFIG_HUGETLBFS) += hugetlb.o
> > +obj-$(CONFIG_HUGETLB_PAGE_FREE_VMEMMAP) += hugetlb_vmemmap.o
> > obj-$(CONFIG_NUMA) += mempolicy.o
> > obj-$(CONFIG_SPARSEMEM) += sparse.o
> > obj-$(CONFIG_SPARSEMEM_VMEMMAP) += sparse-vmemmap.o
> > diff --git a/mm/hugetlb.c
Re: [External] [PATCH v3 4/5] hugetlb: convert PageHugeTemporary() to HPageTemporary flag
On Sat, Jan 23, 2021 at 3:55 AM Mike Kravetz wrote:
>
> X-Gm-Spam: 0
> X-Gm-Phishy: 0
>
> Use new hugetlb specific HPageTemporary flag to replace the
> PageHugeTemporary() interfaces. PageHugeTemporary does contain
> a PageHuge() check. However, this interface is only used within
> hugetlb code where we know we are dealing with a hugetlb page.
> Therefore, the check can be eliminated.
>
> Signed-off-by: Mike Kravetz
> Reviewed-by: Oscar Salvador
Reviewed-by: Muchun Song
> ---
> include/linux/hugetlb.h | 6 ++
> mm/hugetlb.c| 36 +++-
> 2 files changed, 13 insertions(+), 29 deletions(-)
>
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index cd1960541f2a..3c86c3a0e144 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -483,10 +483,15 @@ unsigned long hugetlb_get_unmapped_area(struct file
> *file, unsigned long addr,
> * HPG_migratable - Set after a newly allocated page is added to the page
> * cache and/or page tables. Indicates the page is a candidate for
> * migration.
> + * HPG_temporary - - Set on a page that is temporarily allocated from the
> buddy
> + * allocator. Typically used for migration target pages when no pages
> + * are available in the pool. The hugetlb free page path will
> + * immediately free pages with this flag set to the buddy allocator.
> */
> enum hugetlb_page_flags {
> HPG_restore_reserve = 0,
> HPG_migratable,
> + HPG_temporary,
> __NR_HPAGEFLAGS,
> };
>
> @@ -530,6 +535,7 @@ static inline void ClearHPage##uname(struct page *page)
> \
> */
> HPAGEFLAG(RestoreReserve, restore_reserve)
> HPAGEFLAG(Migratable, migratable)
> +HPAGEFLAG(Temporary, temporary)
>
> #ifdef CONFIG_HUGETLB_PAGE
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 4da1a29ac5e2..70ffa1027988 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1353,28 +1353,6 @@ struct hstate *size_to_hstate(unsigned long size)
> return NULL;
> }
>
> -/*
> - * Internal hugetlb specific page flag. Do not use outside of the hugetlb
> - * code
> - */
> -static inline bool PageHugeTemporary(struct page *page)
> -{
> - if (!PageHuge(page))
> - return false;
> -
> - return (unsigned long)page[2].mapping == -1U;
> -}
> -
> -static inline void SetPageHugeTemporary(struct page *page)
> -{
> - page[2].mapping = (void *)-1U;
> -}
> -
> -static inline void ClearPageHugeTemporary(struct page *page)
> -{
> - page[2].mapping = NULL;
> -}
> -
> static void __free_huge_page(struct page *page)
> {
> /*
> @@ -1422,9 +1400,9 @@ static void __free_huge_page(struct page *page)
> if (restore_reserve)
> h->resv_huge_pages++;
>
> - if (PageHugeTemporary(page)) {
> + if (HPageTemporary(page)) {
> list_del(>lru);
> - ClearPageHugeTemporary(page);
> + ClearHPageTemporary(page);
> update_and_free_page(h, page);
> } else if (h->surplus_huge_pages_node[nid]) {
> /* remove the page from active list */
> @@ -1860,7 +1838,7 @@ static struct page *alloc_surplus_huge_page(struct
> hstate *h, gfp_t gfp_mask,
> * codeflow
> */
> if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages) {
> - SetPageHugeTemporary(page);
> + SetHPageTemporary(page);
> spin_unlock(_lock);
> put_page(page);
> return NULL;
> @@ -1891,7 +1869,7 @@ static struct page *alloc_migrate_huge_page(struct
> hstate *h, gfp_t gfp_mask,
> * We do not account these pages as surplus because they are only
> * temporary and will be released properly on the last reference
> */
> - SetPageHugeTemporary(page);
> + SetHPageTemporary(page);
>
> return page;
> }
> @@ -5612,12 +5590,12 @@ void move_hugetlb_state(struct page *oldpage, struct
> page *newpage, int reason)
> * here as well otherwise the global surplus count will not match
> * the per-node's.
> */
> - if (PageHugeTemporary(newpage)) {
> + if (HPageTemporary(newpage)) {
> int old_nid = page_to_nid(oldpage);
> int new_nid = page_to_nid(newpage);
>
> - SetPageHugeTemporary(oldpage);
> - ClearPageHugeTemporary(newpage);
> + SetHPageTemporary(oldpage);
> + ClearHPageTemporary(newpage);
>
> spin_lock(_lock);
> if (h->surplus_huge_pages_node[old_nid]) {
> --
> 2.29.2
>
Re: [RFC PATCH 1/4] jbd2: make jdb2_debug module parameter per device
En...，your idea maybe better, thanks for your time.
harshad shirwadkar wrote on 2021/1/23 3:00:
> I wonder if we should retain the existing module param as well apart
> from the new device specific logging switch? If that switch is
> enabled, we'll get jbd2 logs for all the devices. Given that the old
> jbd2_debug interface was a module param, I wonder somebody somewhere
> might have infrastructure on top of that to enable debugging for jbd2?
> And by removing this interface we may accidentally break them?
>
> On Thu, Jan 21, 2021 at 10:48 PM Chunguang Xu wrote:
>>
>> From: Chunguang Xu
>>
>> On a multi-disk machine, because jbd2's debugging switch is global,this
>> confuses the logs of multiple disks. It is not easy to distinguish the
>> logs of each disk and the amount of generated logs is very large. Or a
>> separate debugging switch for each disk would be better, so that you
>> can easily distinguish the logs of a certain disk.
>>
>> Signed-off-by: Chunguang Xu
>> ---
>> fs/jbd2/journal.c | 63 +++
>> fs/jbd2/transaction.c | 2 +-
>> include/linux/jbd2.h | 7 +
>> 3 files changed, 60 insertions(+), 12 deletions(-)
>>
>> diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
>> index 2dc92802..ae147cc713c7 100644
>> --- a/fs/jbd2/journal.c
>> +++ b/fs/jbd2/journal.c
>> @@ -48,14 +48,6 @@
>> #include
>> #include
>>
>> -#ifdef CONFIG_JBD2_DEBUG
>> -ushort jbd2_journal_enable_debug __read_mostly;
>> -EXPORT_SYMBOL(jbd2_journal_enable_debug);
>> -
>> -module_param_named(jbd2_debug, jbd2_journal_enable_debug, ushort, 0644);
>> -MODULE_PARM_DESC(jbd2_debug, "Debugging level for jbd2");
>> -#endif
>> -
>> EXPORT_SYMBOL(jbd2_journal_extend);
>> EXPORT_SYMBOL(jbd2_journal_stop);
>> EXPORT_SYMBOL(jbd2_journal_lock_updates);
>> @@ -101,13 +93,13 @@ EXPORT_SYMBOL(jbd2_inode_cache);
>> static int jbd2_journal_create_slab(size_t slab_size);
>>
>> #ifdef CONFIG_JBD2_DEBUG
>> -void __jbd2_debug(int level, const char *file, const char *func,
>> +void jbd2_log(int level, journal_t *j, const char *file, const char *func,
>> unsigned int line, const char *fmt, ...)
>> {
>> struct va_format vaf;
>> va_list args;
>>
>> - if (level > jbd2_journal_enable_debug)
>> + if (!j || level > j->j_debug_level)
>> return;
>> va_start(args, fmt);
>> vaf.fmt = fmt;
>> @@ -115,7 +107,7 @@ void __jbd2_debug(int level, const char *file, const
>> char *func,
>> printk(KERN_DEBUG "%s: (%s, %u): %pV", file, func, line, );
> Now that you have journal_t passed to jbd2_log, it would also be good
> to print the name of the device in this message. I think you can use
> j->j_devname for that.
>
> Thanks,
> Harshad
>> va_end(args);
>> }
>> -EXPORT_SYMBOL(__jbd2_debug);
>> +EXPORT_SYMBOL(jbd2_log);
>> #endif
>>
>> /* Checksumming functions */
>> @@ -1257,6 +1249,48 @@ static int jbd2_seq_info_release(struct inode *inode,
>> struct file *file)
>> return seq_release(inode, file);
>> }
>>
>> +#ifdef CONFIG_JBD2_DEBUG
>> +static int jbd2_proc_debug_show(struct seq_file *m, void *v)
>> +{
>> + journal_t *j = m->private;
>> +
>> + seq_printf(m, "%d\n", j->j_debug_level);
>> + return 0;
>> +}
>> +
>> +static int jbd2_proc_debug_open(struct inode *inode, struct file *file)
>> +{
>> + journal_t *journal = PDE_DATA(inode);
>> +
>> + return single_open(file, jbd2_proc_debug_show, journal);
>> +}
>> +
>> +static ssize_t jbd2_proc_debug_write(struct file *file,
>> + const char __user *buffer, size_t count, loff_t *ppos)
>> +{
>> + struct seq_file *seq = file->private_data;
>> + journal_t *j = seq->private;
>> + char c;
>> +
>> + if (get_user(c, buffer))
>> + return -EFAULT;
>> +
>> + if (c < '0' || c > '5')
>> + return -EINVAL;
>> +
>> + j->j_debug_level = c - '0';
>> + return count;
>> +}
>> +
>> +static const struct proc_ops jbd2_debug_proc_ops = {
>> + .proc_open = jbd2_proc_debug_open,
>> + .proc_read = seq_read,
>> + .proc_write = jbd2_proc_debug_write,
>> + .proc_release = single_release,
>> + .proc_lseek = seq_lseek,
>> +};
>> +#endif
>> +
>> static const struct proc_ops jbd2_info_proc_ops = {
>> .proc_open = jbd2_seq_info_open,
>> .proc_read = seq_read,
>> @@ -1272,12 +1306,19 @@ static void jbd2_stats_proc_init(journal_t *journal)
>> if (journal->j_proc_entry) {
>> proc_create_data("info", S_IRUGO, journal->j_proc_entry,
>> _info_proc_ops, journal);
>> +#ifdef CONFIG_JBD2_DEBUG
>> + proc_create_data("jbd2_debug", S_IRUGO,
>> journal->j_proc_entry,
>> +_debug_proc_ops, journal);
>> +#endif
>> }
>> }
>>
>> static void jbd2_stats_proc_exit(journal_t *journal)
>> {
>>
Re: [PATCH] usb: cdns3: Add support for TI's AM64 SoC
On 21-01-19 10:58:10, Aswath Govindraju wrote:
> Add support for USB controller present on the AM64x SoC.
>
> Signed-off-by: Aswath Govindraju
> ---
> drivers/usb/cdns3/cdns3-ti.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/cdns3/cdns3-ti.c b/drivers/usb/cdns3/cdns3-ti.c
> index 90e246601537..eccb1c766bba 100644
> --- a/drivers/usb/cdns3/cdns3-ti.c
> +++ b/drivers/usb/cdns3/cdns3-ti.c
> @@ -214,6 +214,7 @@ static int cdns_ti_remove(struct platform_device *pdev)
>
> static const struct of_device_id cdns_ti_of_match[] = {
> { .compatible = "ti,j721e-usb", },
> + { .compatible = "ti,am64-usb", },
> {},
> };
> MODULE_DEVICE_TABLE(of, cdns_ti_of_match);
> --
> 2.17.1
>
Applied, thanks.
--
Thanks,
Peter Chen
Re: [PATCH] scsi_logging: print cdb into new line after opcode
Ewan, >> sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 60 40 00 00 01 >> 00 >> >> Print the cdb into a new line in any case, not only when cmd_len is >> greater than 16. The above example error will then read: >> >> sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 >> 28 00 01 c0 09 00 00 00 08 00 > > I'd rather we not change this. I agree. While the current format is suboptimal, there are lots of things out there parsing these error messages. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: ufs: Cleanup WB buffer flush toggle implementation
Bean, > Delete ufshcd_wb_buf_flush_enable() and ufshcd_wb_buf_flush_disable(), > move the implementation into ufshcd_wb_toggle_flush(). Applied to 5.12/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: qla2xxx: Assign boolean values to a bool variable
Jiapeng, > ./drivers/scsi/qla2xxx/qla_isr.c:780:2-18: WARNING: Assignment > of 0/1 to bool variable. Applied to 5.12/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
[PATCH] spi: spi-au1550: pr_err instead of printk
Signed-off-by: corentin noel
---
drivers/spi/spi-au1550.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/spi/spi-au1550.c b/drivers/spi/spi-au1550.c
index dfb7196f4caf..8f92bbdf391b 100644
--- a/drivers/spi/spi-au1550.c
+++ b/drivers/spi/spi-au1550.c
@@ -972,8 +972,7 @@ static int __init au1550_spi_init(void)
if (usedma) {
ddma_memid = au1xxx_ddma_add_device(_spi_mem_dbdev);
if (!ddma_memid)
- printk(KERN_ERR "au1550-spi: cannot add memory"
- "dbdma device\n");
+ pr_err("au1550-spi: cannot add memory dbdma device\n");
}
return platform_driver_register(_spi_drv);
}
--
2.25.1
Re: [PATCH] scsi: mpt3sas: style: Simplify bool comparison
Yang, > Fix the following coccicheck warning: > ./drivers/scsi/mpt3sas/mpt3sas_base.c:2424:5-20: WARNING: Comparison of > 0/1 to bool variable Applied to 5.12/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v9 13/18] arm64: kexec: add expandable argument to relocation function
On Thu, May 7, 2020 at 12:22 PM James Morse wrote:
>
> Hi Pavel,
>
> On 26/03/2020 03:24, Pavel Tatashin wrote:
> > Currently, kexec relocation function (arm64_relocate_new_kernel) accepts
> > the following arguments:
> >
> > head: start of array that contains relocation information.
> > entry:entry point for new kernel or purgatory.
> > dtb_mem: first and only argument to entry.
>
> > The number of arguments cannot be easily expended, because this
> > function is also called from HVC_SOFT_RESTART, which preserves only
> > three arguments. And, also arm64_relocate_new_kernel is written in
> > assembly but called without stack, thus no place to move extra
> > arguments to free registers.
> >
> > Soon, we will need to pass more arguments: once we enable MMU we
> > will need to pass information about page tables.
>
>
> > Another benefit of allowing this function to accept more arguments, is that
> > kernel can actually accept up to 4 arguments (x0-x3), however currently
> > only one is used, but if in the future we will need for more (for example,
> > pass information about when previous kernel exited to have a precise
> > measurement in time spent in purgatory), we won't be easilty do that
> > if arm64_relocate_new_kernel can't accept more arguments.
>
> This is a niche debug hack.
> We really don't want an ABI with purgatory. I think the register values it
> gets were added
> early for compatibility with kexec_file_load().
>
>
> > So, add a new struct: kern_reloc_arg, and place it in kexec safe page (i.e
> > memory that is not overwritten during relocation).
> > Thus, make arm64_relocate_new_kernel to only take one argument, that
> > contains all the needed information.
>
> Do we really not have enough registers?
>
> The PCS[0] gives you 8 arguments. In this patch you use 6.
>
>
> If this is really about the hyp-stub abi, please state that.
Yes, this is a hypervisor abi limitation. I will improve the commit
log to state it clearly.
> > diff --git a/arch/arm64/kernel/machine_kexec.c
> > b/arch/arm64/kernel/machine_kexec.c
> > index cee3be586384..b1122eea627e 100644
> > --- a/arch/arm64/kernel/machine_kexec.c
> > +++ b/arch/arm64/kernel/machine_kexec.c
> > @@ -59,13 +60,35 @@ void machine_kexec_cleanup(struct kimage *kimage)
>
> > int machine_kexec_post_load(struct kimage *kimage)
> > {
> > void *reloc_code = page_to_virt(kimage->control_code_page);
> > + struct kern_reloc_arg *kern_reloc_arg = kexec_page_alloc(kimage);
> > +
> > + if (!kern_reloc_arg)
> > + return -ENOMEM;
> >
> > memcpy(reloc_code, arm64_relocate_new_kernel,
> > arm64_relocate_new_kernel_size);
> > kimage->arch.kern_reloc = __pa(reloc_code);
> > + kimage->arch.kern_reloc_arg = __pa(kern_reloc_arg);
> > + kern_reloc_arg->head = kimage->head;
> > + kern_reloc_arg->entry_addr = kimage->start;
> > + kern_reloc_arg->kern_arg0 = kimage->arch.dtb_mem;
>
> These kern_reloc_arg values are written via the cacheable linear map.
> They are read in arm64_relocate_new_kernel() where the MMU is disabled an all
> memory
> access are non-cacheable.
>
> To ensure you read the values you wrote, you must clean kern_reloc_arg to the
> PoC.
Thank you for catching this, I added:
__flush_dcache_area(kern_reloc_arg, sizeof (struct kern_reloc_arg));
Re: [PATCH v2 00/20] objtool: vmlinux.o and CLANG LTO support
On Sat, Jan 23, 2021 at 3:46 AM Josh Poimboeuf wrote: > > On Sat, Jan 23, 2021 at 03:31:20AM +0100, Sedat Dilek wrote: > > On Sat, Jan 23, 2021 at 3:26 AM Josh Poimboeuf wrote: > > > > > > On Fri, Jan 22, 2021 at 05:32:43PM -0800, Nick Desaulniers wrote: > > > > > In this specific case, find_func_by_offset returns NULL for > > > > > .text..L.cfi.jumptable.43 at addend 0x8, because Clang doesn't emit > > > > > jump table symbols for static functions: > > > > > > > > > > <__typeid__ZTSFjmiE_global_addr>: > > > > >0: e9 00 00 00 00 jmpq 5 > > > > > <__typeid__ZTSFjmiE_global_addr+0x5> > > > > > 1: R_X86_64_PLT32 io_serial_in-0x4 > > > > >5: cc int3 > > > > >6: cc int3 > > > > >7: cc int3 > > > > >8: e9 00 00 00 00 jmpq d > > > > > <__typeid__ZTSFjmiE_global_addr+0xd> > > > > > 9: R_X86_64_PLT32 mem32_serial_in-0x4 > > > > >d: cc int3 > > > > >e: cc int3 > > > > >f: cc int3 > > > > > > > > > > Nick, do you remember if there were plans to change this? > > > > > > > > Do you have a link to any previous discussion to help jog my mind; I > > > > don't really remember this one. > > > > > > > > Is it that `__typeid__ZTSFjmiE_global_addr` is the synthesized jump > > > > table, and yet there is no `__typeid__ZTSFjmiE_global_addr` entry in > > > > the symbol table? > > > > > > I think he means there's not a 'mem32_serial_in.cfi_jt' symbol at > > > '__typeid__ZTSFjmiE_global_addr+8'. Probably more aggressive symbol > > > pruning from the assembler. > > > > > > It's fine though. I just need to rewrite the CFI support a bit. > > > > > > But that can come later. For now I'll just drop the two CFI-related > > > patches from this set so I can merge the others next week. > > > > > > > Two CFI-related patches? > > > > What's the other than "objtool: Add CONFIG_CFI_CLANG support"? > > I was referring to patches 10 and 11: > > objtool: Move unsuffixed symbol conversion to a helper function > objtool: Add CONFIG_CFI_CLANG support > OK, thanks. I will test with a revert of these two patches in another scenario where I have problems with Clang's IAS but not with GNU AS. - Sedat - > You can just drop those patches from your testing (and don't test with > CFI). > > > Do you plan (or offer) a v3 of objtool-vmlinux? > > Not unless there are any more comments. > > -- > Josh > > -- > You received this message because you are subscribed to the Google Groups > "Clang Built Linux" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clang-built-linux+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clang-built-linux/20210123024634.qu62tyq3nkqusken%40treble.
Re: [PATCH v2 00/20] objtool: vmlinux.o and CLANG LTO support
On Sat, Jan 23, 2021 at 03:31:20AM +0100, Sedat Dilek wrote: > On Sat, Jan 23, 2021 at 3:26 AM Josh Poimboeuf wrote: > > > > On Fri, Jan 22, 2021 at 05:32:43PM -0800, Nick Desaulniers wrote: > > > > In this specific case, find_func_by_offset returns NULL for > > > > .text..L.cfi.jumptable.43 at addend 0x8, because Clang doesn't emit > > > > jump table symbols for static functions: > > > > > > > > <__typeid__ZTSFjmiE_global_addr>: > > > >0: e9 00 00 00 00 jmpq 5 > > > > <__typeid__ZTSFjmiE_global_addr+0x5> > > > > 1: R_X86_64_PLT32 io_serial_in-0x4 > > > >5: cc int3 > > > >6: cc int3 > > > >7: cc int3 > > > >8: e9 00 00 00 00 jmpq d > > > > <__typeid__ZTSFjmiE_global_addr+0xd> > > > > 9: R_X86_64_PLT32 mem32_serial_in-0x4 > > > >d: cc int3 > > > >e: cc int3 > > > >f: cc int3 > > > > > > > > Nick, do you remember if there were plans to change this? > > > > > > Do you have a link to any previous discussion to help jog my mind; I > > > don't really remember this one. > > > > > > Is it that `__typeid__ZTSFjmiE_global_addr` is the synthesized jump > > > table, and yet there is no `__typeid__ZTSFjmiE_global_addr` entry in > > > the symbol table? > > > > I think he means there's not a 'mem32_serial_in.cfi_jt' symbol at > > '__typeid__ZTSFjmiE_global_addr+8'. Probably more aggressive symbol > > pruning from the assembler. > > > > It's fine though. I just need to rewrite the CFI support a bit. > > > > But that can come later. For now I'll just drop the two CFI-related > > patches from this set so I can merge the others next week. > > > > Two CFI-related patches? > > What's the other than "objtool: Add CONFIG_CFI_CLANG support"? I was referring to patches 10 and 11: objtool: Move unsuffixed symbol conversion to a helper function objtool: Add CONFIG_CFI_CLANG support You can just drop those patches from your testing (and don't test with CFI). > Do you plan (or offer) a v3 of objtool-vmlinux? Not unless there are any more comments. -- Josh
[PATCH] spmi: spmi-pmic-arb: Fix hw_irq overflow
Currently, when handling the SPMI summary interrupt, the hw_irq
number is calculated based on SID, Peripheral ID, IRQ index and
APID. This is then passed to irq_find_mapping() to see if a
mapping exists for this hw_irq and if available, invoke the
interrupt handler. Since the IRQ index uses an "int" type, hw_irq
which is of unsigned long data type can take a large value when
SID has its MSB set to 1 and the type conversion happens. Because
of this, irq_find_mapping() returns 0 as there is no mapping
for this hw_irq. This ends up invoking cleanup_irq() as if
the interrupt is spurious whereas it is actually a valid
interrupt. Fix this by using the proper data type (u32) for id.
Signed-off-by: Subbaraman Narayanamurthy
---
drivers/spmi/spmi-pmic-arb.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
index de844b4..bbbd311 100644
--- a/drivers/spmi/spmi-pmic-arb.c
+++ b/drivers/spmi/spmi-pmic-arb.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * Copyright (c) 2012-2015, 2017, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2012-2015, 2017, 2021, The Linux Foundation. All rights
reserved.
*/
#include
#include
@@ -505,8 +505,7 @@ static void cleanup_irq(struct spmi_pmic_arb *pmic_arb, u16
apid, int id)
static void periph_interrupt(struct spmi_pmic_arb *pmic_arb, u16 apid)
{
unsigned int irq;
- u32 status;
- int id;
+ u32 status, id;
u8 sid = (pmic_arb->apid_data[apid].ppid >> 8) & 0xF;
u8 per = pmic_arb->apid_data[apid].ppid & 0xFF;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 3/4] ubifs: Update directory size when creating whiteouts
在 2021/1/23 5:22, Richard Weinberger 写道:
Although whiteouts are unlinked files they will get re-linked later,
I just want to make sure, is this where the count is increased?
do_rename -> inc_nlink(whiteout)
therefore the size of the parent directory needs to be updated too.
Cc: sta...@vger.kernel.org
Fixes: 9e0a1fff8db5 ("ubifs: Implement RENAME_WHITEOUT")
Signed-off-by: Richard Weinberger
---
fs/ubifs/dir.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
index 8a34e0118ee9..b5d523e5854f 100644
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -361,6 +361,7 @@ static int do_tmpfile(struct inode *dir, struct dentry
*dentry,
struct ubifs_budget_req ino_req = { .dirtied_ino = 1 };
struct ubifs_inode *ui, *dir_ui = ubifs_inode(dir);
int err, instantiated = 0;
+ int sz_change = 0;
struct fscrypt_name nm;
/*
@@ -411,6 +412,8 @@ static int do_tmpfile(struct inode *dir, struct dentry
*dentry,
mark_inode_dirty(inode);
drop_nlink(inode);
*whiteout = inode;
+ sz_change = CALC_DENT_SIZE(fname_len());
+ dir->i_size += sz_change;
} else {
d_tmpfile(dentry, inode);
}
@@ -430,6 +433,7 @@ static int do_tmpfile(struct inode *dir, struct dentry
*dentry,
return 0;
out_cancel:
Does this need a judgment? Like this,
if (whiteout)
dir->i_size -= sz_change;
+ dir->i_size -= sz_change;
mutex_unlock(_ui->ui_mutex);
out_inode:
make_bad_inode(inode);
Re: [PATCH net] tcp: make TCP_USER_TIMEOUT accurate for zero window probes
Hi, Jakub:
On Fri, Jan 22, 2021 at 06:34:24PM -0800, Jakub Kicinski wrote:
> On Fri, 22 Jan 2021 18:28:23 -0800 Enke Chen wrote:
> > Hi, Jakub:
> >
> > In terms of backporting, this patch should go together with:
> >
> > 9d9b1ee0b2d1 tcp: fix TCP_USER_TIMEOUT with zero window
>
> As in it:
>
> Fixes: 9d9b1ee0b2d1 tcp: fix TCP_USER_TIMEOUT with zero window
>
> or does it further fix the same issue, so:
>
> Fixes: 9721e709fa68 ("tcp: simplify window probe aborting on USER_TIMEOUT")
>
> ?
Let me clarify:
1) 9d9b1ee0b2d1 tcp: fix TCP_USER_TIMEOUT with zero window
fixes the bug and makes it work.
2) The current patch makes the TCP_USER_TIMEOUT accurate for 0-window probes.
It's independent.
With 1) and 2), the known issues with TCP_USER_TIMEOUT for 0-window probes
would be resolved.
Thanks. -- Enke
Re: [printk] b031a684bf: INFO:rcu_tasks_detected_stalls_on_tasks
On (21/01/22 16:13), kernel test robot wrote: [..] > > ++++ > || 6b916706f8 | b031a684bf | > ++++ > | boot_successes | 66 | 18 | > | boot_failures | 2 | 26 | > | INFO:rcu_sched_detected_stalls_on_CPUs/tasks | 1 || > | RIP:enqueue_hrtimer| 1 || > | RIP:__memset | 1 || > | RIP:clear_page_rep | 2 | 2 | > | BUG:kernel_hang_in_boot_stage | 2 || > | INFO:rcu_sched_self-detected_stall_on_CPU | 1 | 4 | > | INFO:rcu_tasks_detected_stalls_on_tasks| 0 | 22 | > | RIP:kernel_init_free_pages | 0 | 1 | > | IP-Config:Auto-configuration_of_network_failed | 0 | 3 | > | RIP:zone_page_state| 0 | 1 | > ++++ A side note: > # printk and dmesg options > # > CONFIG_PRINTK_TIME=y > # CONFIG_PRINTK_CALLER is not set > CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7 > CONFIG_CONSOLE_LOGLEVEL_QUIET=4 Could you please keep CONFIG_PRINTK_CALLER enabled at all times? -ss
Re: [PATCH] MAINTAINERS: adjust to clang-version.sh removal
On Fri, Jan 22, 2021 at 1:34 PM Dan Carpenter wrote:
>
> On Thu, Jan 21, 2021 at 05:15:56PM +0100, Sedat Dilek wrote:
> > On Thu, Jan 21, 2021 at 5:01 PM Lukas Bulwahn
> > wrote:
> > >
> > > Commit 6c8ad4427f6e ("kbuild: check the minimum compiler version in
> > > Kconfig") removed ./scripts/clang-version.sh and moved its content to
> > > ./scripts/cc-version.sh.
> > >
> > > Since then, ./scripts/get_maintainer.pl --self-test=patterns complains:
> > >
> > > warning: no file matchesF:scripts/clang-version.sh
> > >
> > > The CLANG/LLVM BUILD SUPPORT section in MAINTAINERS intends to track
> > > changes in ./scripts/clang-version.sh; as the file is removed, track
> > > changes in ./scripts/cc-version.sh instead now.
> > >
> > > Signed-off-by: Lukas Bulwahn
> >
> > Good catch, Lukas.
> >
> > As a tipp:
> > Next time you can pass '--subject-prefix="PATCH next-MMDD"' when
> > doing 'git format-patch ...' (or whatever you use to generate the
> > patch).
>
> I've never seen anyone use this prefix before.
>
> What does the date really help? In staging, we apply everything on top
> of staging-next and if it doesn't apply then we don't investigate, we
> just say "doesn't apply. resend if needed".
>
> We may as well just say [PATCH linux-next]. No one is ever going to
> look up the date if it doesn't apply to the latest linux-next.
>
Is there an official rule to label patches for Linux-next?
Usually - when I was more active on Linux-next development - folks add
a "PATCH -next" to the subject.
Of course, this needs additionally a hint in the patch/commit message
against which Linux-next release it is applicable.
Linux-next releases are highly dynamic - a patch might be applicable
to one single "-next" release.
Git trees come and go - are resetted to an older version of a Git tree.
As LKML is CCed - think of the hundreds and thousands of patches
coming in daily.
So a more meaningful subject can give a first orientation.
That was my point.
My €0,02.
- Sedat -
Re: [PATCH 1/4] ubifs: Correctly set inode size in ubifs_link()
在 2021/1/23 5:22, Richard Weinberger 写道:
Reviewed-by: Zhihao Cheng
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
index 9a6b8660425a..04912dedca48 100644
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -693,7 +693,7 @@ static int ubifs_link(struct dentry *old_dentry, struct
inode *dir,
struct inode *inode = d_inode(old_dentry);
struct ubifs_inode *ui = ubifs_inode(inode);
struct ubifs_inode *dir_ui = ubifs_inode(dir);
- int err, sz_change = CALC_DENT_SIZE(dentry->d_name.len);
+ int err, sz_change;
struct ubifs_budget_req req = { .new_dent = 1, .dirtied_ino = 2,
.dirtied_ino_d = ALIGN(ui->data_len, 8) };
struct fscrypt_name nm;
@@ -731,6 +731,8 @@ static int ubifs_link(struct dentry *old_dentry, struct
inode *dir,
if (inode->i_nlink == 0)
ubifs_delete_orphan(c, inode->i_ino);
+ sz_change = CALC_DENT_SIZE(fname_len());
+
inc_nlink(inode);
ihold(inode);
inode->i_ctime = current_time(inode);
Re: [PATCH net] tcp: make TCP_USER_TIMEOUT accurate for zero window probes
On Fri, 22 Jan 2021 18:28:23 -0800 Enke Chen wrote:
> Hi, Jakub:
>
> In terms of backporting, this patch should go together with:
>
> 9d9b1ee0b2d1 tcp: fix TCP_USER_TIMEOUT with zero window
As in it:
Fixes: 9d9b1ee0b2d1 tcp: fix TCP_USER_TIMEOUT with zero window
or does it further fix the same issue, so:
Fixes: 9721e709fa68 ("tcp: simplify window probe aborting on USER_TIMEOUT")
?
Re: [PATCH v3 00/19] scsi: libsas: Remove in_interrupt() check
Ahmed, > Ahmed S. Darwish (18): > Documentation: scsi: libsas: Remove notify_ha_event() > scsi: libsas: Introduce a _gfp() variant of event notifiers > scsi: mvsas: Pass gfp_t flags to libsas event notifiers > scsi: isci: port: link down: Pass gfp_t flags > scsi: isci: port: link up: Pass gfp_t flags > scsi: isci: port: broadcast change: Pass gfp_t flags > scsi: libsas: Pass gfp_t flags to event notifiers > scsi: pm80xx: Pass gfp_t flags to libsas event notifiers > scsi: aic94xx: Pass gfp_t flags to libsas event notifiers > scsi: hisi_sas: Pass gfp_t flags to libsas event notifiers > scsi: libsas: event notifiers API: Add gfp_t flags parameter > scsi: hisi_sas: Switch back to original libsas event notifiers > scsi: aic94xx: Switch back to original libsas event notifiers > scsi: pm80xx: Switch back to original libsas event notifiers > scsi: libsas: Switch back to original event notifiers API > scsi: isci: Switch back to original libsas event notifiers > scsi: mvsas: Switch back to original libsas event notifiers > scsi: libsas: Remove temporarily-added _gfp() API variants > > John Garry (1): > scsi: libsas and users: Remove notifier indirection Applied to 5.12/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
[PATCH] mm/swapfile.c: fix debugging information problem
Once the function name is changed, it may be easy to forget to modify
the corresponding code here.
Signed-off-by: Stephen Zhang
---
mm/swapfile.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 9fffc5a..12a18b8 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1158,13 +1158,13 @@ static struct swap_info_struct
*__swap_info_get(swp_entry_t entry)
return p;
bad_offset:
- pr_err("swap_info_get: %s%08lx\n", Bad_offset, entry.val);
+ pr_err("%s: %s%08lx\n", __func__, Bad_offset, entry.val);
goto out;
bad_device:
- pr_err("swap_info_get: %s%08lx\n", Unused_file, entry.val);
+ pr_err("%s: %s%08lx\n", __func__, Unused_file, entry.val);
goto out;
bad_nofile:
- pr_err("swap_info_get: %s%08lx\n", Bad_file, entry.val);
+ pr_err("%s: %s%08lx\n", __func__, Bad_file, entry.val);
out:
return NULL;
}
@@ -1181,7 +1181,7 @@ static struct swap_info_struct
*_swap_info_get(swp_entry_t entry)
return p;
bad_free:
- pr_err("swap_info_get: %s%08lx\n", Unused_offset, entry.val);
+ pr_err("%s: %s%08lx\n", __func__, Unused_offset, entry.val);
out:
return NULL;
}
--
1.8.3.1
Re: [PATCH v2 00/20] objtool: vmlinux.o and CLANG LTO support
On Sat, Jan 23, 2021 at 3:26 AM Josh Poimboeuf wrote: > > On Fri, Jan 22, 2021 at 05:32:43PM -0800, Nick Desaulniers wrote: > > > In this specific case, find_func_by_offset returns NULL for > > > .text..L.cfi.jumptable.43 at addend 0x8, because Clang doesn't emit > > > jump table symbols for static functions: > > > > > > <__typeid__ZTSFjmiE_global_addr>: > > >0: e9 00 00 00 00 jmpq 5 > > > <__typeid__ZTSFjmiE_global_addr+0x5> > > > 1: R_X86_64_PLT32 io_serial_in-0x4 > > >5: cc int3 > > >6: cc int3 > > >7: cc int3 > > >8: e9 00 00 00 00 jmpq d > > > <__typeid__ZTSFjmiE_global_addr+0xd> > > > 9: R_X86_64_PLT32 mem32_serial_in-0x4 > > >d: cc int3 > > >e: cc int3 > > >f: cc int3 > > > > > > Nick, do you remember if there were plans to change this? > > > > Do you have a link to any previous discussion to help jog my mind; I > > don't really remember this one. > > > > Is it that `__typeid__ZTSFjmiE_global_addr` is the synthesized jump > > table, and yet there is no `__typeid__ZTSFjmiE_global_addr` entry in > > the symbol table? > > I think he means there's not a 'mem32_serial_in.cfi_jt' symbol at > '__typeid__ZTSFjmiE_global_addr+8'. Probably more aggressive symbol > pruning from the assembler. > > It's fine though. I just need to rewrite the CFI support a bit. > > But that can come later. For now I'll just drop the two CFI-related > patches from this set so I can merge the others next week. > Two CFI-related patches? What's the other than "objtool: Add CONFIG_CFI_CLANG support"? Do you plan (or offer) a v3 of objtool-vmlinux? Thanks. - Sedat - [1] https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/commit/?h=objtool-vmlinux-v2=d743f4b36e120c06506567a9f87a062ae03da47f
[GIT PULL] SCSI fixes for 5.11-rc4
Twelve minor fixes, all in drivers or doc. Most of the fixes are pretty obvious (although we have 2 goes to get the UFS sysfs doc right) and the biggest change is in the ufs driver which they've extensively tested. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes The short changelog is: Adrian Hunter (1): scsi: docs: ABI: sysfs-driver-ufs: Add DeepSleep power mode Arnd Bergmann (1): scsi: megaraid_sas: Fix MEGASAS_IOC_FIRMWARE regression Brian King (1): scsi: ibmvfc: Set default timeout to avoid crash during migration Dinghao Liu (1): scsi: fnic: Fix memleak in vnic_dev_init_devcmd2 Jaegeuk Kim (2): scsi: ufs: Fix tm request when non-fatal error happens scsi: ufs: Fix livelock of ufshcd_clear_ua_wluns() Javed Hasan (1): scsi: libfc: Avoid invoking response handler twice if ep is already completed Lukas Bulwahn (1): scsi: docs: ABI: sysfs-driver-ufs: Rectify table formatting Martin Wilck (1): scsi: scsi_transport_srp: Don't block target in failfast state Randy Dunlap (1): scsi: ufs: ufshcd-pltfrm depends on HAS_IOMEM Shin'ichiro Kawasaki (1): scsi: target: tcmu: Fix use-after-free of se_cmd->priv Tyrel Datwyler (1): scsi: ibmvfc: Fix missing cast of ibmvfc_event pointer to u64 handle And the diffstat: Documentation/ABI/testing/sysfs-driver-ufs | 36 ++--- drivers/scsi/fnic/vnic_dev.c | 8 --- drivers/scsi/ibmvscsi/ibmvfc.c | 8 --- drivers/scsi/libfc/fc_exch.c | 16 +++-- drivers/scsi/megaraid/megaraid_sas_base.c | 6 ++--- drivers/scsi/scsi_transport_srp.c | 9 +++- drivers/scsi/ufs/Kconfig | 1 + drivers/scsi/ufs/ufshcd.c | 37 -- drivers/target/target_core_user.c | 11 ++--- 9 files changed, 90 insertions(+), 42 deletions(-) With full diff below. James --- diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index adc0d0e91607..75ccc5c62b3c 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -916,21 +916,25 @@ Date: September 2014 Contact: Subhash Jadavani Description: This entry could be used to set or show the UFS device runtime power management level. The current driver - implementation supports 6 levels with next target states: + implementation supports 7 levels with next target states: == - 0 an UFS device will stay active, an UIC link will + 0 UFS device will stay active, UIC link will stay active - 1 an UFS device will stay active, an UIC link will + 1 UFS device will stay active, UIC link will hibernate - 2 an UFS device will moved to sleep, an UIC link will + 2 UFS device will be moved to sleep, UIC link will stay active - 3 an UFS device will moved to sleep, an UIC link will + 3 UFS device will be moved to sleep, UIC link will hibernate - 4 an UFS device will be powered off, an UIC link will + 4 UFS device will be powered off, UIC link will hibernate - 5 an UFS device will be powered off, an UIC link will + 5 UFS device will be powered off, UIC link will be powered off + 6 UFS device will be moved to deep sleep, UIC link + will be powered off. Note, deep sleep might not be + supported in which case this value will not be + accepted == What: /sys/bus/platform/drivers/ufshcd/*/rpm_target_dev_state @@ -954,21 +958,25 @@ Date: September 2014 Contact: Subhash Jadavani Description: This entry could be used to set or show the UFS device system power management level. The current driver - implementation supports 6 levels with next target states: + implementation supports 7 levels with next target states: == - 0 an UFS device will stay active, an UIC link will + 0 UFS device will stay active, UIC link will stay active - 1 an UFS device will stay active, an UIC link will + 1 UFS device will stay active, UIC link will hibernate - 2 an UFS device will moved to sleep, an UIC link will + 2 UFS device will be moved to sleep, UIC
Re: [PATCH] net: stmmac: dwmac-intel-plat: remove config data on error
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Wed, 20 Jan 2021 03:07:44 -0800 you wrote:
> Remove the config data when rate setting fails.
>
> Fixes: 9efc9b2b04c7 ("net: stmmac: Add dwmac-intel-plat for GBE driver")
> Signed-off-by: Pan Bian
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-intel-plat.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Here is the summary with links:
- net: stmmac: dwmac-intel-plat: remove config data on error
https://git.kernel.org/netdev/net/c/3765d86ffcd3
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH net] tcp: make TCP_USER_TIMEOUT accurate for zero window probes
Hi, Jakub:
In terms of backporting, this patch should go together with:
9d9b1ee0b2d1 tcp: fix TCP_USER_TIMEOUT with zero window
Thanks. -- Enke
On Fri, Jan 22, 2021 at 05:43:25PM -0800, Jakub Kicinski wrote:
> On Fri, 22 Jan 2021 11:13:06 -0800 Enke Chen wrote:
> > From: Enke Chen
> >
> > The TCP_USER_TIMEOUT is checked by the 0-window probe timer. As the
> > timer has backoff with a max interval of about two minutes, the
> > actual timeout for TCP_USER_TIMEOUT can be off by up to two minutes.
> >
> > In this patch the TCP_USER_TIMEOUT is made more accurate by taking it
> > into account when computing the timer value for the 0-window probes.
> >
> > This patch is similar to the one that made TCP_USER_TIMEOUT accurate for
> > RTOs in commit b701a99e431d ("tcp: Add tcp_clamp_rto_to_user_timeout()
> > helper to improve accuracy").
> >
> > Signed-off-by: Enke Chen
> > Reviewed-by: Neal Cardwell
>
> This is targeting net, any guidance on Fixes / backporting?
Re: [PATCH v2 00/20] objtool: vmlinux.o and CLANG LTO support
On Fri, Jan 22, 2021 at 05:32:43PM -0800, Nick Desaulniers wrote: > > In this specific case, find_func_by_offset returns NULL for > > .text..L.cfi.jumptable.43 at addend 0x8, because Clang doesn't emit > > jump table symbols for static functions: > > > > <__typeid__ZTSFjmiE_global_addr>: > >0: e9 00 00 00 00 jmpq 5 > > <__typeid__ZTSFjmiE_global_addr+0x5> > > 1: R_X86_64_PLT32 io_serial_in-0x4 > >5: cc int3 > >6: cc int3 > >7: cc int3 > >8: e9 00 00 00 00 jmpq d > > <__typeid__ZTSFjmiE_global_addr+0xd> > > 9: R_X86_64_PLT32 mem32_serial_in-0x4 > >d: cc int3 > >e: cc int3 > >f: cc int3 > > > > Nick, do you remember if there were plans to change this? > > Do you have a link to any previous discussion to help jog my mind; I > don't really remember this one. > > Is it that `__typeid__ZTSFjmiE_global_addr` is the synthesized jump > table, and yet there is no `__typeid__ZTSFjmiE_global_addr` entry in > the symbol table? I think he means there's not a 'mem32_serial_in.cfi_jt' symbol at '__typeid__ZTSFjmiE_global_addr+8'. Probably more aggressive symbol pruning from the assembler. It's fine though. I just need to rewrite the CFI support a bit. But that can come later. For now I'll just drop the two CFI-related patches from this set so I can merge the others next week. -- Josh
Re: [PATCH net 2/4] net: mvpp2: Remove unneeded Kconfig dependency.
On Thu, 21 Jan 2021 07:08:02 -0800 Richard Cochran wrote:
> On Thu, Jan 21, 2021 at 10:27:54AM +, Russell King - ARM Linux admin
> wrote:
> > On Wed, Jan 20, 2021 at 08:06:01PM -0800, Richard Cochran wrote:
> > > The mvpp2 is an Ethernet driver, and it implements MAC style time
> > > stamping of PTP frames. It has no need of the expensive option to
> > > enable PHY time stamping. Remove the incorrect dependency.
> > >
> > > Signed-off-by: Richard Cochran
> > > Fixes: 91dd71950bd7 ("net: mvpp2: ptp: add TAI support")
> >
> > NAK.
>
> Can you please explain why mvpp2 requires NETWORK_PHY_TIMESTAMING?
Russell, I think we all agree now this is not the solution to the
problem of which entity should provide the timestamp, but the series
doesn't seem objectionable in itself.
Please LMK if you think otherwise.
(I would put it in net-next tho, given the above this at most a space
optimization.)
Re: [PATCH v3 net-next 0/4] net: ipa: remove a build dependency
Hello: This series was applied to netdev/net-next.git (refs/heads/master): On Wed, 20 Jan 2021 15:26:02 -0600 you wrote: > (David/Jakub, please take these all through net-next if they are > acceptable to you, once Rob has acked the binding. Rob, please ack > if the binding looks OK to you.) > > Version 3 removes the "Fixes" tag from the first patch, and updates > the addressee list to include some people I apparently missed. > > [...] Here is the summary with links: - [v3,net-next,1/4] net: ipa: remove a remoteproc dependency https://git.kernel.org/netdev/net-next/c/86fdf1fc60e9 - [v3,net-next,2/4] dt-bindings: net: remove modem-remoteproc property https://git.kernel.org/netdev/net-next/c/27bb36ed7775 - [v3,net-next,3/4] arm64: dts: qcom: sc7180: kill IPA modem-remoteproc property https://git.kernel.org/netdev/net-next/c/8535c8e30010 - [v3,net-next,4/4] arm64: dts: qcom: sdm845: kill IPA modem-remoteproc property https://git.kernel.org/netdev/net-next/c/5da1fca9eb73 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH] regulator: core: avoid regulator_resolve_supply() race condition
Hello Mark,
On 1/21/21 12:30 PM, Marek Szyprowski wrote:
Hi Mark,
On 21.01.2021 16:44, Mark Brown wrote:
On Thu, Jan 21, 2021 at 10:41:59AM +0100, Marek Szyprowski wrote:
On 18.01.2021 21:49, Mark Brown wrote:
Does this help (completely untested):
Sadly nope. I get same warning:
Try this instead:
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 3ae5ccd9277d..31503776dbd7 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1823,17 +1823,6 @@ static int regulator_resolve_supply(struct regulator_dev
*rdev)
if (rdev->supply)
return 0;
- /*
-* Recheck rdev->supply with rdev->mutex lock held to avoid a race
-* between rdev->supply null check and setting rdev->supply in
-* set_supply() from concurrent tasks.
-*/
- regulator_lock(rdev);
-
- /* Supply just resolved by a concurrent task? */
- if (rdev->supply)
- goto out;
-
r = regulator_dev_lookup(dev, rdev->supply_name);
if (IS_ERR(r)) {
ret = PTR_ERR(r);
@@ -1885,12 +1874,29 @@ static int regulator_resolve_supply(struct
regulator_dev *rdev)
goto out;
}
+ /*
+* Recheck rdev->supply with rdev->mutex lock held to avoid a race
+* between rdev->supply null check and setting rdev->supply in
+* set_supply() from concurrent tasks.
+*/
+ regulator_lock(rdev);
+
+ /* Supply just resolved by a concurrent task? */
+ if (rdev->supply) {
+ regulator_unlock(rdev);
+ put_device(>dev);
+ return ret;
+ }
+
ret = set_supply(rdev, r);
if (ret < 0) {
+ regulator_unlock(rdev);
put_device(>dev);
- goto out;
+ return ret;
}
+ regulator_unlock(rdev);
+
/*
* In set_machine_constraints() we may have turned this regulator on
* but we couldn't propagate to the supply if it hadn't been resolved
@@ -1901,12 +1907,11 @@ static int regulator_resolve_supply(struct
regulator_dev *rdev)
if (ret < 0) {
_regulator_put(rdev->supply);
rdev->supply = NULL;
- goto out;
+ goto out_rdev_lock;
drivers/regulator/core.c:1910:4: error: label ‘out_rdev_lock’ used but
not defined
}
}
out:
- regulator_unlock(rdev);
return ret;
}
It looks that it finally fixes the locking issue, with the above goto
removed completely to fix build. Feel free to add:
Reported-by: Marek Szyprowski
Tested-by: Marek Szyprowski
Thank you for making this fix. I'm sorry that I missed the potential
deadlock issue resulting from the regulator_enable() call inside
regulator_resolve_supply() with rdev->mutex locked. Your fix avoids
deadlock while still ensuring that the there isn't a set supply race
condition.
Take care,
David
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v6 00/12] SVM cleanup and INVPCID feature support
On 1/21/21 5:51 PM, Babu Moger wrote: > > > On 1/20/21 9:10 PM, Babu Moger wrote: >> >> >> On 1/20/21 3:45 PM, Babu Moger wrote: >>> >>> >>> On 1/20/21 3:14 PM, Jim Mattson wrote: On Tue, Jan 19, 2021 at 3:45 PM Babu Moger wrote: > > > > On 1/19/21 5:01 PM, Jim Mattson wrote: >> On Mon, Sep 14, 2020 at 11:33 AM Babu Moger wrote: >> >>> Thanks Paolo. Tested Guest/nested guest/kvm units tests. Everything >>> works >>> as expected. >> >> Debian 9 does not like this patch set. As a kvm guest, it panics on a >> Milan CPU unless booted with 'nopcid'. Gmail mangles long lines, so >> please see the attached kernel log snippet. Debian 10 is fine, so I >> assume this is a guest bug. >> > > We had an issue with PCID feature earlier. This was showing only with SEV > guests. It is resolved recently. Do you think it is not related that? > Here are the patch set. > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fkvm%2F160521930597.32054.4906933314022910996.stgit%40bmoger-ubuntu%2Fdata=04%7C01%7CBabu.Moger%40amd.com%7C3009e5f7f32b4dbd4aee08d8bdc045c9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637467980841376327%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2Bva7em372XD7uaCrSy3UBH6a9n8xaTTXWCAlA3gJX78%3Dreserved=0 The Debian 9 release we tested is not an SEV guest. >>> ok. I have not tested Debian 9 before. I will try now. Will let you know >>> how it goes. thanks >>> >> >> I have reproduced the issue locally. Will investigate. thanks >> > Few updates. > 1. Like Jim mentioned earlier, this appears to be guest kernel issue. > Debian 9 runs the base kernel 4.9.0-14. Problem can be seen consistently > with this kernel. > > 2. This guest kernel(4.9.0-14) does not like the new feature INVPCID. > > 3. System comes up fine when invpcid feature is disabled with the boot > parameter "noinvpcid" and also with "nopcid". nopcid disables both pcid > and invpcid. > > 4. Upgraded the guest kernel to v5.0 and system comes up fine. > > 5. Also system comes up fine with latest guest kernel 5.11.0-rc4. > > I did not bisect further yet. > Babu > Thanks Some more update: System comes up fine with kernel v4.9(checked out on upstream tag v4.9). So, I am assuming this is something specific to Debian 4.9.0-14 kernel. Note: I couldn't go back prior versions(v4.8 or earlier) due to compile issues. Thanks Babu
[PATCH] tpm_tis: Add missing start/stop_tpm_chip calls
There is a missing call to start_tpm_chip before the call to
the tpm_get_timeouts() and tpm_tis_probe_irq_single(). As the current
approach maight work for tpm2, it fails for tpm1.x - in that case
call to tpm_get_timeouts() or tpm_tis_probe_irq_single() tries to
transmit TPM commands on a disabled chip what what doesn't succeed
and in turn causes tpm_tis_core_init() to fail.
Tested on Samsung Chromebook Pro (Caroline).
Signed-off-by: Lukasz Majczak
---
drivers/char/tpm/tpm_tis_core.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index 92c51c6cfd1b..ff0e5fe46a9d 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -1063,12 +1063,16 @@ int tpm_tis_core_init(struct device *dev, struct
tpm_tis_data *priv, int irq,
init_waitqueue_head(>read_queue);
init_waitqueue_head(>int_queue);
if (irq != -1) {
+ rc = tpm_chip_start(chip);
+ if (rc)
+ goto out_err;
/* Before doing irq testing issue a command to the TPM in
polling mode
* to make sure it works. May as well use that command to set
the
* proper timeouts for the driver.
*/
if (tpm_get_timeouts(chip)) {
dev_err(dev, "Could not get TPM timeouts and
durations\n");
+ tpm_chip_stop(chip);
rc = -ENODEV;
goto out_err;
}
@@ -1085,6 +1089,7 @@ int tpm_tis_core_init(struct device *dev, struct
tpm_tis_data *priv, int irq,
} else {
tpm_tis_probe_irq(chip, intmask);
}
+ tpm_chip_stop(chip);
}
rc = tpm_chip_register(chip);
--
2.25.1
Re: [PATCH net] tcp: make TCP_USER_TIMEOUT accurate for zero window probes
On Fri, 22 Jan 2021 11:13:06 -0800 Enke Chen wrote:
> From: Enke Chen
>
> The TCP_USER_TIMEOUT is checked by the 0-window probe timer. As the
> timer has backoff with a max interval of about two minutes, the
> actual timeout for TCP_USER_TIMEOUT can be off by up to two minutes.
>
> In this patch the TCP_USER_TIMEOUT is made more accurate by taking it
> into account when computing the timer value for the 0-window probes.
>
> This patch is similar to the one that made TCP_USER_TIMEOUT accurate for
> RTOs in commit b701a99e431d ("tcp: Add tcp_clamp_rto_to_user_timeout()
> helper to improve accuracy").
>
> Signed-off-by: Enke Chen
> Reviewed-by: Neal Cardwell
This is targeting net, any guidance on Fixes / backporting?
Re: [net-next PATCH v4 10/15] net: mdio: Add ACPI support code for mdio
On Fri, 22 Jan 2021 21:12:55 +0530 Calvin Johnson wrote: > Define acpi_mdiobus_register() to Register mii_bus and create PHYs for > each ACPI child node. > > Signed-off-by: Calvin Johnson ERROR: modpost: missing MODULE_LICENSE() in drivers/net/mdio/acpi_mdio.o make[2]: *** [Module.symvers] Error 1
Re: [PATCH v2] lan743x: add virtual PHY for PHY-less devices
On 1/22/2021 5:01 PM, Sergej Bauer wrote: > On Saturday, January 23, 2021 3:01:47 AM MSK Florian Fainelli wrote: >> On 1/22/2021 3:58 PM, Sergej Bauer wrote: >>> On Saturday, January 23, 2021 2:23:25 AM MSK Andrew Lunn wrote: >>> @@ -1000,8 +1005,10 @@ static void lan743x_phy_close(struct >>> lan743x_adapter *adapter)> >>> >>> struct net_device *netdev = adapter->netdev; >>> >>> phy_stop(netdev->phydev); >>> >>> - phy_disconnect(netdev->phydev); >>> - netdev->phydev = NULL; >>> + if (phy_is_pseudo_fixed_link(netdev->phydev)) >>> + lan743x_virtual_phy_disconnect(netdev->phydev); >>> + else >>> + phy_disconnect(netdev->phydev); >> >> phy_disconnect() should work. You might want to call There are drivers which call phy_disconnect() on a fixed_link. e.g. https://elixir.bootlin.com/linux/v5.11-rc4/source/drivers/net/usb/lan78xx .c# L3555. It could be your missing call to fixed_phy_unregister() is leaving behind bad state. >>> >>> lan743x_virtual_phy_disconnect removes sysfs-links and calls >>> fixed_phy_unregister() >>> and the reason was phydev in sysfs. >>> > It was to make ethtool show full set of supported speeds and MII only in > supported ports (without TP and the no any ports in the bare card). But fixed link does not support the full set of speed. It is fixed. It supports only one speed it is configured with. >>> >>> That's why I "re-implemented the fixed PHY driver" as Florian said. >>> The goal of virtual phy was to make an illusion of real device working in >>> loopback mode. So I could use ethtool and ioctl's to switch speed of >>> device.> And by setting it wrongly, you are going to allow the user to do odd things, like use ethtool force the link speed to a speed which is not actually supported. >>> >>> I have lan743x only and in loopback mode it allows to use speeds >>> 10/100/1000MBps >>> in full-duplex mode only. But the highest speed I have achived was >>> something near >>> 752Mbps... >>> And I can switch speed on the fly, without reloading the module. >>> >>> May by I should limit the list of acceptable devices? >> >> It is not clear what your use case is so maybe start with explaining it >> and we can help you define something that may be acceptable for upstream >> inclusion. > it migth be helpful for developers work on userspace networking tools with > PHY-less lan743x (the interface even could not be brought up) > of course, there nothing much to do without TP port but the difference is > representative. You are still not explaining why fixed PHY is not a suitable emulation and what is different, providing the output of ethtool does not tell me how you are using it. Literally everyone using Ethernet switches or MAC to MAC Ethernet connections uses fixed PHY and is reasonably happy with it. -- Florian
Re: [PATCH net 1/1] net: fec: Fix temporary RMII clock reset on link up
On Fri, 22 Jan 2021 16:13:47 +0100 Laurent Badel wrote:
> fec_restart() does a hard reset of the MAC module when the link status
> changes to up. This temporarily resets the R_CNTRL register which controls
> the MII mode of the ENET_OUT clock. In the case of RMII, the clock
> frequency momentarily drops from 50MHz to 25MHz until the register is
> reconfigured. Some link partners do not tolerate this glitch and
> invalidate the link causing failure to establish a stable link when using
> PHY polling mode. Since as per IEEE802.11 the criteria for link validity
> are PHY-specific, what the partner should tolerate cannot be assumed, so
> avoid resetting the MII clock by using software reset instead of hardware
> reset when the link is up. This is generally relevant only if the SoC
> provides the clock to an external PHY and the PHY is configured for RMII.
> static const struct fec_devinfo fec_imx6q_info = {
> @@ -953,7 +954,8 @@ fec_restart(struct net_device *ndev)
>* For i.MX6SX SOC, enet use AXI bus, we use disable MAC
>* instead of reset MAC itself.
>*/
> - if (fep->quirks & FEC_QUIRK_HAS_AVB) {
> + if (fep->quirks & FEC_QUIRK_HAS_AVB ||
> + (fep->quirks & FEC_QUIRK_NO_HARD_RESET) && fep->link) {
> writel(0, fep->hwp + FEC_ECNTRL);
> } else {
> writel(1, fep->hwp + FEC_ECNTRL);
drivers/net/ethernet/freescale/fec_main.c: In function ‘fec_restart’:
drivers/net/ethernet/freescale/fec_main.c:958:46: warning: suggest parentheses
around ‘&&’ within ‘||’ [-Wparentheses]
958 | (fep->quirks & FEC_QUIRK_NO_HARD_RESET) && fep->link) {
| ^~~~
Re: [PATCH v2 00/20] objtool: vmlinux.o and CLANG LTO support
On Fri, Jan 22, 2021 at 1:17 PM Sami Tolvanen wrote: > > Hi Josh, > > On Fri, Jan 22, 2021 at 7:42 AM Josh Poimboeuf wrote: > > > > On Thu, Jan 21, 2021 at 11:38:54PM +0100, Sedat Dilek wrote: > > > On Thu, Jan 21, 2021 at 10:29 PM Josh Poimboeuf > > > wrote: > > > > > > > > v2: > > > > - fix commit description for why xen hypervisor page contents don't > > > > matter [Juergen] > > > > - annotate indirect jumps as safe instead of converting them to > > > > retpolines [Andrew, Juergen] > > > > - drop patch 1 - fake jumps no longer exist > > > > - add acks > > > > > > > > Based on tip/objtool/core. > > > > > > > > > > > > Add support for proper vmlinux.o validation, which will be needed for > > > > Sami's upcoming x86 LTO set. (And vmlinux validation is the future for > > > > objtool anyway, for other reasons.) > > > > > > > > This isn't 100% done -- most notably, crypto still needs to be supported > > > > -- but I think this gets us most of the way there. > > > > > > > > This can also be found at > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git > > > > objtool-vmlinux > > > > > > > > > > Should this be s/objtool-vmlinux/objtool-vmlinux-v2 ? > > > > Indeed: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git > > objtool-vmlinux-v2 > > I tested v2 on top of the LTO tree and with allyesconfig + relevant > crypto configs disabled, and I only see the warnings I reported > earlier. > > I also tested this on top of the CFI tree and with LTO+CFI enabled, I > can reproduce the segfault Sedat reported in the previous thread. This > happens because find_unsuffixed_func is called with a NULL sym in > read_relocs: > > Program received signal SIGSEGV, Segmentation fault. > find_unsuffixed_func (elf=elf@entry=0x755a5010, sym=0x0, > suffix=0x416cbf ".cfi_jt", func=func@entry=0x7fffd5f0) at > elf.c:274 > 274 loc = strstr(sym->name, suffix); > (gdb) bt > #0 find_unsuffixed_func (elf=elf@entry=0x755a5010, sym=0x0, > suffix=0x416cbf ".cfi_jt", func=func@entry=0x7fffd5f0) at > elf.c:274 > #1 0x0040d8f8 in read_relocs (elf=0x755a5010) at elf.c:637 > ... > > In this specific case, find_func_by_offset returns NULL for > .text..L.cfi.jumptable.43 at addend 0x8, because Clang doesn't emit > jump table symbols for static functions: > > <__typeid__ZTSFjmiE_global_addr>: >0: e9 00 00 00 00 jmpq 5 <__typeid__ZTSFjmiE_global_addr+0x5> > 1: R_X86_64_PLT32 io_serial_in-0x4 >5: cc int3 >6: cc int3 >7: cc int3 >8: e9 00 00 00 00 jmpq d <__typeid__ZTSFjmiE_global_addr+0xd> > 9: R_X86_64_PLT32 mem32_serial_in-0x4 >d: cc int3 >e: cc int3 >f: cc int3 > > Nick, do you remember if there were plans to change this? Do you have a link to any previous discussion to help jog my mind; I don't really remember this one. Is it that `__typeid__ZTSFjmiE_global_addr` is the synthesized jump table, and yet there is no `__typeid__ZTSFjmiE_global_addr` entry in the symbol table? -- Thanks, ~Nick Desaulniers
