Re: [PATCH 4.4 000/158] 4.4.187-stable review
On Fri, 2 Aug 2019 at 15:00, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.187 release. > There are 158 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 04 Aug 2019 09:19:34 AM UTC. > 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.187-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.4.187-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: d9815060e3ec2433dfffc8a3dcaed9842b1798c7 git describe: v4.4.186-157-gd9815060e3ec Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.186-157-gd9815060e3ec No regressions (compared to build v4.4.186) No fixes (compared to build v4.4.186) Ran 13277 total tests in the following environments and test suites. Environments -- - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * build * kselftest * kvm-unit-tests * libhugetlbfs * 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-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * network-basic-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * install-android-platform-tools-r2600 Summary kernel: 4.4.187-rc2 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.187-rc2-hikey-20190802-517 git commit: 83e555c108c2c8fc5cc0af29c02f47cc2676fb88 git describe: 4.4.187-rc2-hikey-20190802-517 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.187-rc2-hikey-20190802-517 No regressions (compared to build 4.4.187-rc1-hikey-20190802-516) No fixes (compared to build 4.4.187-rc1-hikey-20190802-516) Ran 1549 total tests in the following environments and test suites. Environments -- - hi6220-hikey - arm64 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * 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 * ltp-timers-tests * perf * spectre-meltdown-checker-test * v4l2-compliance -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 5.2 00/20] 5.2.6-stable review
On Fri, 2 Aug 2019 at 15:28, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.2.6 release. > There are 20 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 04 Aug 2019 09:19:34 AM UTC. > 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.2.6-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.2.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.2.6-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.2.y git commit: 44397d30b22dd93340c705ef34bb61c16f43503b git describe: v5.2.4-235-g44397d30b22d Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.2-oe/build/v5.2.4-235-g44397d30b22d No regressions (compared to build v5.2.4) No fixes (compared to build v5.2.4) Ran 21444 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * libhugetlbfs * 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_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * network-basic-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * ltp-fs-tests * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none * ssuite -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.19 00/32] 4.19.64-stable review
On Fri, 2 Aug 2019 at 15:26, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.64 release. > There are 32 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 04 Aug 2019 09:19:34 AM UTC. > 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.64-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.64-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: 63a8dab46af2b65ecdb5a83662d94a3a26be973e git describe: v4.19.62-148-g63a8dab46af2 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.62-148-g63a8dab46af2 No regressions (compared to build v4.19.62) No fixes (compared to build v4.19.62) Ran 25243 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * libhugetlbfs * 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_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * ltp-fs-tests * network-basic-tests * ltp-open-posix-tests * kvm-unit-tests * ssuite * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.14 00/25] 4.14.136-stable review
On Fri, 2 Aug 2019 at 21:20, Greg Kroah-Hartman wrote: > > On Fri, Aug 02, 2019 at 11:39:32AM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.136 release. > > There are 25 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 04 Aug 2019 09:19:34 AM UTC. > > 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.136-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.14.y > > and the diffstat can be found below. > > -rc2 is out to match up with the failure of one patch to apply, and the > ip tunnel patch added. Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.14.136-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: 8c06cc9d417294ee552cee5025f8dad9a982a026 git describe: v4.14.134-319-g8c06cc9d4172 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.134-319-g8c06cc9d4172 No regressions (compared to build v4.14.134) No fixes (compared to build v4.14.134) Ran 23868 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * 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-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 * ltp-ipc-tests * ltp-timers-tests * network-basic-tests * ltp-open-posix-tests * kvm-unit-tests * ssuite * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 1/2] perf: Fix failure to set cpumask when only one cpu
On 8/2/19 9:06 PM, Jiri Olsa wrote: > On Fri, Aug 02, 2019 at 04:29:51PM +0800, zhe...@windriver.com wrote: >> From: He Zhe >> >> The buffer containing string used to set cpumask is overwritten by end of >> string later in cpu_map__snprint_mask due to not enough memory space, when >> there is only one cpu. And thus causes the following failure. >> >> $ perf ftrace ls >> failed to reset ftrace >> >> This patch fixes the calculation of cpumask string size. >> >> Signed-off-by: He Zhe >> --- >> tools/perf/builtin-ftrace.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c >> index 66d5a66..0193128 100644 >> --- a/tools/perf/builtin-ftrace.c >> +++ b/tools/perf/builtin-ftrace.c >> @@ -173,7 +173,7 @@ static int set_tracing_cpumask(struct cpu_map *cpumap) >> int last_cpu; >> >> last_cpu = cpu_map__cpu(cpumap, cpumap->nr - 1); >> -mask_size = (last_cpu + 3) / 4 + 1; >> +mask_size = last_cpu / 4 + 2; /* one more byte for EOS */ >> mask_size += last_cpu / 32; /* ',' is needed for every 32th cpus */ > ugh.. why do we care about last_cpu value in here at all? > > feels like using static buffer would be more reasonable Thanks, and yes, a static buffer would be easy to handle. A 2KB buffer is enough to cover 8196 cpus, the maximum numbers of cpus we can run with for now. Let's see if there is any other concerns. Zhe > > jirka > >> >> cpumask = malloc(mask_size); >> -- >> 2.7.4 >>
[PATCH v4 4/4] dt-bindings: Update the riscv,isa string description
Since the RISC-V specification states that ISA description strings are case-insensitive, there's no functional difference between mixed-case, upper-case, and lower-case ISA strings. Thus, to simplify parsing, specify that the letters present in "riscv,isa" must be all lowercase. Suggested-by: Paul Walmsley Signed-off-by: Atish Patra --- Documentation/devicetree/bindings/riscv/cpus.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml index c899111aa5e3..9d3fe6aada2b 100644 --- a/Documentation/devicetree/bindings/riscv/cpus.yaml +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml @@ -50,6 +50,10 @@ properties: User-Level ISA document, available from https://riscv.org/specifications/ + While the isa strings in ISA specification are case + insensitive, letters in the riscv,isa string must be all + lowercase to simplify parsing. + timebase-frequency: type: integer minimum: 1 -- 2.21.0
[PATCH v4 1/4] RISC-V: Remove per cpu clocksource
There is only one clocksource in RISC-V. The boot cpu initializes
that clocksource. No need to keep a percpu data structure.
Signed-off-by: Atish Patra
---
drivers/clocksource/timer-riscv.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/clocksource/timer-riscv.c
b/drivers/clocksource/timer-riscv.c
index 5e6038fbf115..09e031176bc6 100644
--- a/drivers/clocksource/timer-riscv.c
+++ b/drivers/clocksource/timer-riscv.c
@@ -55,7 +55,7 @@ static u64 riscv_sched_clock(void)
return get_cycles64();
}
-static DEFINE_PER_CPU(struct clocksource, riscv_clocksource) = {
+static struct clocksource riscv_clocksource = {
.name = "riscv_clocksource",
.rating = 300,
.mask = CLOCKSOURCE_MASK(64),
@@ -92,7 +92,6 @@ void riscv_timer_interrupt(void)
static int __init riscv_timer_init_dt(struct device_node *n)
{
int cpuid, hartid, error;
- struct clocksource *cs;
hartid = riscv_of_processor_hartid(n);
if (hartid < 0) {
@@ -112,8 +111,7 @@ static int __init riscv_timer_init_dt(struct device_node *n)
pr_info("%s: Registering clocksource cpuid [%d] hartid [%d]\n",
__func__, cpuid, hartid);
- cs = per_cpu_ptr(_clocksource, cpuid);
- error = clocksource_register_hz(cs, riscv_timebase);
+ error = clocksource_register_hz(_clocksource, riscv_timebase);
if (error) {
pr_err("RISCV timer register failed [%d] for cpu = [%d]\n",
error, cpuid);
--
2.21.0
[PATCH v4 0/4] Miscellaneous fixes
This patch series have some unrelated fixes related to clocksource, dt-bindings and isa strings. I combined them into series as most of them are prerequisite for kvm patch series. Changes from v3->v4: 1. Removed export module patch. 2. Updated dt binding description. Changes from v2->v3: 1. Updated commit text of dt binding patch. 2. Removed couple of remaining uppercase usage. Changes from v1->v2: 1. Dropped the case-insensitive support patch and added a dt-bindings update patch. 2. Added a export symbol patch. Anup Patel (1): RISC-V: Add riscv_isa reprensenting ISA features common across CPUs Atish Patra (3): RISC-V: Remove per cpu clocksource RISC-V: Fix unsupported isa string info. dt-bindings: Update the riscv,isa string description .../devicetree/bindings/riscv/cpus.yaml | 4 ++ arch/riscv/include/asm/hwcap.h| 16 +++ arch/riscv/kernel/cpu.c | 47 +++ arch/riscv/kernel/cpufeature.c| 39 +-- drivers/clocksource/timer-riscv.c | 6 +-- 5 files changed, 95 insertions(+), 17 deletions(-) -- 2.21.0
[PATCH v4 3/4] RISC-V: Fix unsupported isa string info.
Currently, kernel prints a info warning if any of the extensions
from "mafdcsu" is missing in device tree. This is not entirely
correct as Linux can boot with "f or d" extensions if kernel is
configured accordingly. Moreover, it will continue to print the
info string for future extensions such as hypervisor as well which
is misleading. /proc/cpuinfo also doesn't print any other extensions
except "mafdcsu".
Make sure that info log is only printed only if kernel is configured
to have any mandatory extensions but device tree doesn't describe it.
All the extensions present in device tree and follow the order
described in the RISC-V specification (except 'S') are printed via
/proc/cpuinfo always.
Signed-off-by: Atish Patra
---
arch/riscv/kernel/cpu.c | 47 -
1 file changed, 37 insertions(+), 10 deletions(-)
diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
index 7da3c6a93abd..9b1d4550fbe6 100644
--- a/arch/riscv/kernel/cpu.c
+++ b/arch/riscv/kernel/cpu.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
/*
* Returns the hart ID of the given device tree node, or -ENODEV if the node
@@ -46,11 +47,14 @@ int riscv_of_processor_hartid(struct device_node *node)
#ifdef CONFIG_PROC_FS
-static void print_isa(struct seq_file *f, const char *orig_isa)
+static void print_isa(struct seq_file *f, const char *orig_isa,
+ unsigned long cpuid)
{
- static const char *ext = "mafdcsu";
+ static const char *mandatory_ext = "mafdcsu";
const char *isa = orig_isa;
const char *e;
+ char unsupported_isa[26] = {0};
+ int index = 0;
/*
* Linux doesn't support rv32e or rv128i, and we only support booting
@@ -70,27 +74,50 @@ static void print_isa(struct seq_file *f, const char
*orig_isa)
isa += 5;
/*
-* Check the rest of the ISA string for valid extensions, printing those
-* we find. RISC-V ISA strings define an order, so we only print the
+* RISC-V ISA strings define an order, so we only print all the
* extension bits when they're in order. Hide the supervisor (S)
* extension from userspace as it's not accessible from there.
+* Throw a warning only if any mandatory extensions are not available
+* and kernel is configured to have that mandatory extensions.
*/
- for (e = ext; *e != '\0'; ++e) {
- if (isa[0] == e[0]) {
+ for (e = mandatory_ext; *e != '\0'; ++e) {
+ if (isa[0] != e[0]) {
+#if defined(CONFIG_ISA_RISCV_C)
+ if (isa[0] == 'c')
+ continue;
+#endif
+#if defined(CONFIG_FP)
+ if ((isa[0] == 'f') || (isa[0] == 'd'))
+ continue;
+#endif
+ unsupported_isa[index] = e[0];
+ index++;
+ }
+ /* Only write if part of isa string */
+ if (isa[0] != '\0') {
if (isa[0] != 's')
seq_write(f, isa, 1);
-
isa++;
}
}
+ if (isa[0] != '\0') {
+ /* Add remainging isa strings */
+ for (e = isa; *e != '\0'; ++e) {
+#if !defined(CONFIG_VIRTUALIZATION)
+ if (e[0] != 'h')
+#endif
+ seq_write(f, e, 1);
+ }
+ }
seq_puts(f, "\n");
/*
* If we were given an unsupported ISA in the device tree then print
* a bit of info describing what went wrong.
*/
- if (isa[0] != '\0')
- pr_info("unsupported ISA \"%s\" in device tree\n", orig_isa);
+ if (unsupported_isa[0])
+ pr_info("unsupported ISA extensions \"%s\" in device tree for
cpu [%ld]\n",
+ unsupported_isa, cpuid);
}
static void print_mmu(struct seq_file *f, const char *mmu_type)
@@ -134,7 +161,7 @@ static int c_show(struct seq_file *m, void *v)
seq_printf(m, "processor\t: %lu\n", cpu_id);
seq_printf(m, "hart\t\t: %lu\n", cpuid_to_hartid_map(cpu_id));
if (!of_property_read_string(node, "riscv,isa", ))
- print_isa(m, isa);
+ print_isa(m, isa, cpu_id);
if (!of_property_read_string(node, "mmu-type", ))
print_mmu(m, mmu);
if (!of_property_read_string(node, "compatible", )
--
2.21.0
[PATCH v4 2/4] RISC-V: Add riscv_isa reprensenting ISA features common across CPUs
From: Anup Patel
This patch adds riscv_isa integer to represent ISA features common
across all CPUs. The riscv_isa is not same as elf_hwcap because
elf_hwcap will only have ISA features relevant for user-space apps
whereas riscv_isa will have ISA features relevant to both kernel
and user-space apps.
One of the use case is KVM hypervisor where riscv_isa will be used
to do following operations:
1. Check whether hypervisor extension is available
2. Find ISA features that need to be virtualized (e.g. floating
point support, vector extension, etc.)
Signed-off-by: Anup Patel
Signed-off-by: Atish Patra
---
arch/riscv/include/asm/hwcap.h | 16 ++
arch/riscv/kernel/cpufeature.c | 39 +++---
2 files changed, 52 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 7ecb7c6a57b1..717306780add 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -22,5 +22,21 @@ enum {
};
extern unsigned long elf_hwcap;
+
+#define RISCV_ISA_EXT_a(1UL << ('a' - 'a'))
+#define RISCV_ISA_EXT_c(1UL << ('c' - 'a'))
+#define RISCV_ISA_EXT_d(1UL << ('d' - 'a'))
+#define RISCV_ISA_EXT_f(1UL << ('f' - 'a'))
+#define RISCV_ISA_EXT_h(1UL << ('h' - 'a'))
+#define RISCV_ISA_EXT_i(1UL << ('i' - 'a'))
+#define RISCV_ISA_EXT_m(1UL << ('m' - 'a'))
+#define RISCV_ISA_EXT_s(1UL << ('s' - 'a'))
+#define RISCV_ISA_EXT_u(1UL << ('u' - 'a'))
+
+extern unsigned long riscv_isa;
+
+#define riscv_isa_extension_available(ext_char)\
+ (riscv_isa & RISCV_ISA_EXT_##ext_char)
+
#endif
#endif
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index b1ade9a49347..becc99272341 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -12,6 +12,9 @@
#include
unsigned long elf_hwcap __read_mostly;
+unsigned long riscv_isa __read_mostly;
+EXPORT_SYMBOL_GPL(riscv_isa);
+
#ifdef CONFIG_FPU
bool has_fpu __read_mostly;
#endif
@@ -20,7 +23,8 @@ void riscv_fill_hwcap(void)
{
struct device_node *node;
const char *isa;
- size_t i;
+ char print_str[BITS_PER_LONG+1];
+ size_t i, j, isa_len;
static unsigned long isa2hwcap[256] = {0};
isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I;
@@ -31,9 +35,11 @@ void riscv_fill_hwcap(void)
isa2hwcap['c'] = isa2hwcap['C'] = COMPAT_HWCAP_ISA_C;
elf_hwcap = 0;
+ riscv_isa = 0;
for_each_of_cpu_node(node) {
unsigned long this_hwcap = 0;
+ unsigned long this_isa = 0;
if (riscv_of_processor_hartid(node) < 0)
continue;
@@ -43,8 +49,20 @@ void riscv_fill_hwcap(void)
continue;
}
- for (i = 0; i < strlen(isa); ++i)
+ i = 0;
+ isa_len = strlen(isa);
+#if defined(CONFIG_32BIT)
+ if (!strncmp(isa, "rv32", 4))
+ i += 4;
+#elif defined(CONFIG_64BIT)
+ if (!strncmp(isa, "rv64", 4))
+ i += 4;
+#endif
+ for (; i < isa_len; ++i) {
this_hwcap |= isa2hwcap[(unsigned char)(isa[i])];
+ if ('a' <= isa[i] && isa[i] <= 'z')
+ this_isa |= (1UL << (isa[i] - 'a'));
+ }
/*
* All "okay" hart should have same isa. Set HWCAP based on
@@ -55,6 +73,11 @@ void riscv_fill_hwcap(void)
elf_hwcap &= this_hwcap;
else
elf_hwcap = this_hwcap;
+
+ if (riscv_isa)
+ riscv_isa &= this_isa;
+ else
+ riscv_isa = this_isa;
}
/* We don't support systems with F but without D, so mask those out
@@ -64,7 +87,17 @@ void riscv_fill_hwcap(void)
elf_hwcap &= ~COMPAT_HWCAP_ISA_F;
}
- pr_info("elf_hwcap is 0x%lx\n", elf_hwcap);
+ memset(print_str, 0, sizeof(print_str));
+ for (i = 0, j = 0; i < BITS_PER_LONG; i++)
+ if (riscv_isa & (1UL << i))
+ print_str[j++] = (char)('a' + i);
+ pr_info("riscv: ISA extensions %s\n", print_str);
+
+ memset(print_str, 0, sizeof(print_str));
+ for (i = 0, j = 0; i < BITS_PER_LONG; i++)
+ if (elf_hwcap & (1UL << i))
+ print_str[j++] = (char)('a' + i);
+ pr_info("riscv: ELF capabilities %s\n", print_str);
#ifdef CONFIG_FPU
if (elf_hwcap & (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D))
--
2.21.0
Re: [PATCH 1/1] block: Use bits.h macros to improve readability
On 8/1/19 6:00 PM, Leonardo Bras wrote: > Applies some bits.h macros in order to improve readability of > linux/blk_types.h. > > Signed-off-by: Leonardo Bras > --- > include/linux/blk_types.h | 55 --- > 1 file changed, 28 insertions(+), 27 deletions(-) > > diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h > index 95202f80676c..31c8c6d274f6 100644 > --- a/include/linux/blk_types.h > +++ b/include/linux/blk_types.h > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > > struct bio_set; > struct bio; > @@ -101,13 +102,13 @@ static inline bool blk_path_error(blk_status_t error) > #define BIO_ISSUE_SIZE_BITS 12 > #define BIO_ISSUE_RES_SHIFT (64 - BIO_ISSUE_RES_BITS) > #define BIO_ISSUE_SIZE_SHIFT(BIO_ISSUE_RES_SHIFT - BIO_ISSUE_SIZE_BITS) > -#define BIO_ISSUE_TIME_MASK ((1ULL << BIO_ISSUE_SIZE_SHIFT) - 1) > +#define BIO_ISSUE_TIME_MASK GENMASK_ULL(BIO_ISSUE_SIZE_SHIFT - 1, 0) Not sure why we even have these helpers, I'd argue that patches like this HURT readability, not improve it. When I see ((1ULL << SOME_SHIFT) - 1) I know precisely what that does, whereas I have to think about the other one, maybe even look it up to be sure. For instance, without looking now, I have no idea what the second argument is. Looking at the git log, I see numerous instances of: "xxx: Fix misuses of GENMASK macro Arguments are supposed to be ordered high then low." Hence it seems GENMASK_ULL is easy to misuse or get wrong, the very opposite of what you'd want in a helper. How is it helping readability if the helper is easy to misuse? Ditto with (1ULL << SOME_SHIFT) vs BIT_ULL. But at least that one doesn't have a mysterious 2nd argument. Hence I'm not inclined to apply this patch. -- Jens Axboe
Re: [PATCH] linux/bits.h: Add compile time sanity check of GENMASK inputs
On Sat, Aug 3, 2019 at 12:03 PM Masahiro Yamada wrote: > > BTW, v2 is already inconsistent. > If you wanted GENMASK_INPUT_CHECK() to return 'unsigned long',, > you would have to cast (low) > (high) as well: > >(unsigned long)((low) > (high)), UL(0 > > This is totally redundant, and weird. I take back this comment. You added (unsigned long) to the beginning of this macro. So, the type is consistent, but I believe all casts should be removed. -- Best Regards Masahiro Yamada
Re: [PATCH] linux/bits.h: Add compile time sanity check of GENMASK inputs
On Sat, Aug 3, 2019 at 3:19 AM Rikard Falkeborn
wrote:
>
> On Fri, Aug 02, 2019 at 12:25:06PM +0900, Masahiro Yamada wrote:
> > On Fri, Aug 2, 2019 at 12:14 PM Joe Perches wrote:
> > >
> > > On Fri, 2019-08-02 at 10:40 +0900, Masahiro Yamada wrote:
> > > > On Thu, Aug 1, 2019 at 4:27 AM Joe Perches wrote:
> > > > > On Wed, 2019-07-31 at 21:03 +0200, Rikard Falkeborn wrote:
> > > > > > GENMASK() and GENMASK_ULL() are supposed to be called with the high
> > > > > > bit
> > > > > > as the first argument and the low bit as the second argument. Mixing
> > > > > > them will return a mask with zero bits set.
> > > > > >
> > > > > > Recent commits show getting this wrong is not uncommon, see e.g.
> > > > > > commit aa4c0c9091b0 ("net: stmmac: Fix misuses of GENMASK macro")
> > > > > > and
> > > > > > commit 9bdd7bb3a844 ("clocksource/drivers/npcm: Fix misuse of
> > > > > > GENMASK
> > > > > > macro").
> > > > > >
> > > > > > To prevent such mistakes from appearing again, add compile time
> > > > > > sanity
> > > > > > checking to the arguments of GENMASK() and GENMASK_ULL(). If both
> > > > > > the
> > > > > > arguments are known at compile time, and the low bit is higher than
> > > > > > the
> > > > > > high bit, break the build to detect the mistake immediately.
> > > > > >
> > > > > > Since GENMASK() is used in declarations, BUILD_BUG_OR_ZERO() must be
> > > > > > used instead of BUILD_BUG_ON(), and __is_constexpr() must be used
> > > > > > instead
> > > > > > of __builtin_constant_p().
> > > > > >
> > > > > > Commit 95b980d62d52 ("linux/bits.h: make BIT(), GENMASK(), and
> > > > > > friends
> > > > > > available in assembly") made the macros in linux/bits.h available in
> > > > > > assembly. Since neither BUILD_BUG_OR_ZERO() or __is_constexpr() are
> > > > > > asm
> > > > > > compatible, disable the checks if the file is included in an asm
> > > > > > file.
> > > > > >
> > > > > > Signed-off-by: Rikard Falkeborn
> > > > > > ---
> > > > > > Joe Perches sent a series to fix the existing misuses of GENMASK()
> > > > > > that
> > > > > > needs to be merged before this to avoid build failures. Currently,
> > > > > > 7 of
> > > > > > the patches were not in Linus tree, and 2 were not in linux-next.
> > > > > >
> > > > > > Also, there's currently no asm users of bits.h, but since it was
> > > > > > made
> > > > > > asm-compatible just two weeks ago it would be a shame to break it
> > > > > > right
> > > > > > away...
> > > > > []
> > > > > > diff --git a/include/linux/bits.h b/include/linux/bits.h
> > > > > []
> > > > > > @@ -18,12 +18,22 @@
> > > > > > * position @h. For example
> > > > > > * GENMASK_ULL(39, 21) gives us the 64bit vector
> > > > > > 0x00e0.
> > > > > > */
> > > > > > +#ifndef __ASSEMBLY__
> > > > > > +#include
> > > > > > +#define GENMASK_INPUT_CHECK(h, l)
> > > > > > BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
> > > > > > + __is_constexpr(h) && __is_constexpr(l), (l) > (h), 0))
> > > > > > +#else
> > > > > > +#define GENMASK_INPUT_CHECK(h, l) 0
> > > > >
> > > > > A few things:
> > > > >
> > > > > o Reading the final code is a bit confusing.
> > > > > Perhaps add a comment description saying it's not checked
> > > > > in asm .h uses.
> > > > >
> > > > > o Maybe use:
> > > > > #define GENMASK_INPUT_CHECK(h, l) UL(0)
> > > >
> > > > Why?
> > >
> > > Consistency with the uses in what's now called __GENMASK
> >
> > Inconsistent with __GENMASK_ULL.
>
> Would you prefer to add GENMASK_ULL_INPUT_CHECK?
No.
> Or replace UL(0) with
> 0 and then probably move the cast of BUILD_BUG_OR_ZERO (to avoid
> GENMASK be of type size_t) to GENMASK and GENMASK_ULL?
No.
Your original code is absolutely fine.
C aligns the types to the wider one.
(unsigned long) + (int) -> (unsigned long)
(unsigned long long) + (int) -> (unsigned long long)
Having GENMASK_INPUT_CHECK to return 'int' is OK.
The resulted GENMASK(), GENMASK_ULL() still
have unsigned long, unsigned long long, respectively.
BTW, v2 is already inconsistent.
If you wanted GENMASK_INPUT_CHECK() to return 'unsigned long',,
you would have to cast (low) > (high) as well:
(unsigned long)((low) > (high)), UL(0
This is totally redundant, and weird.
--
Best Regards
Masahiro Yamada
Re: [PATCH] net/mlx4_core: Use refcount_t for refcount
Saeed Mahameed 于2019年8月3日周六 上午2:38写道： > > On Sat, 2019-08-03 at 00:10 +0800, Chuhong Yuan wrote: > > Chuhong Yuan 于2019年8月2日周五 下午8:10写道： > > > refcount_t is better for reference counters since its > > > implementation can prevent overflows. > > > So convert atomic_t ref counters to refcount_t. > > > > > > Also convert refcount from 0-based to 1-based. > > > > > > > It seems that directly converting refcount from 0-based > > to 1-based is infeasible. > > I am sorry for this mistake. > > Just curious, why not keep it 0 based and use refcout_t ? > > refcount API should have the same semantics as atomic_t API .. no ? refcount API will warn when increase a 0 refcount. It regards this as a use-after-free.
Re: Possible mem cgroup bug in kernels between 4.18.0 and 5.3-rc1.
Well, while mem_cgroup_oom() is actually called, due to hitting
/*
* The OOM killer does not compensate for IO-less reclaim.
* pagefault_out_of_memory lost its gfp context so we have to
* make sure exclude 0 mask - all other users should have at least
* ___GFP_DIRECT_RECLAIM to get here.
*/
if (oc->gfp_mask && !(oc->gfp_mask & __GFP_FS))
return true;
path inside out_of_memory(), OOM_SUCCESS is returned and retrying without
making forward progress...
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2447,6 +2447,8 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t
gfp_mask,
*/
oom_status = mem_cgroup_oom(mem_over_limit, gfp_mask,
get_order(nr_pages * PAGE_SIZE));
+ printk("mem_cgroup_oom(%pGg)=%u\n", _mask, oom_status);
+ dump_stack();
switch (oom_status) {
case OOM_SUCCESS:
nr_retries = MEM_CGROUP_RECLAIM_RETRIES;
[ 55.208578][ T2798] mem_cgroup_oom(GFP_NOFS)=0
[ 55.210424][ T2798] CPU: 3 PID: 2798 Comm: leaker Not tainted 5.3.0-rc2+ #637
[ 55.212985][ T2798] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 04/13/2018
[ 55.217260][ T2798] Call Trace:
[ 55.218597][ T2798] dump_stack+0x67/0x95
[ 55.220200][ T2798] try_charge+0x4ca/0x6d0
[ 55.221843][ T2798] ? get_mem_cgroup_from_mm+0x1ff/0x2c0
[ 55.223855][ T2798] mem_cgroup_try_charge+0x88/0x2d0
[ 55.225723][ T2798] __add_to_page_cache_locked+0x27e/0x4c0
[ 55.227784][ T2798] ? scan_shadow_nodes+0x30/0x30
[ 55.229577][ T2798] add_to_page_cache_lru+0x72/0x180
[ 55.231467][ T2798] iomap_readpages_actor+0xeb/0x1e0
[ 55.233376][ T2798] ? iomap_migrate_page+0x120/0x120
[ 55.235382][ T2798] iomap_apply+0xaf/0x150
[ 55.237049][ T2798] iomap_readpages+0x9f/0x160
[ 55.239061][ T2798] ? iomap_migrate_page+0x120/0x120
[ 55.241013][ T2798] xfs_vm_readpages+0x54/0x130 [xfs]
[ 55.242960][ T2798] read_pages+0x63/0x160
[ 55.244613][ T2798] __do_page_cache_readahead+0x1cd/0x200
[ 55.246699][ T2798] ondemand_readahead+0x201/0x4d0
[ 55.248562][ T2798] page_cache_async_readahead+0x16e/0x2e0
[ 55.250740][ T2798] ? page_cache_async_readahead+0xa5/0x2e0
[ 55.252881][ T2798] filemap_fault+0x3f3/0xc20
[ 55.254813][ T2798] ? xfs_ilock+0x1de/0x2c0 [xfs]
[ 55.256858][ T2798] ? __xfs_filemap_fault+0x7f/0x270 [xfs]
[ 55.259118][ T2798] ? down_read_nested+0x98/0x170
[ 55.261123][ T2798] ? xfs_ilock+0x1de/0x2c0 [xfs]
[ 55.263146][ T2798] __xfs_filemap_fault+0x92/0x270 [xfs]
[ 55.265210][ T2798] xfs_filemap_fault+0x27/0x30 [xfs]
[ 55.267164][ T2798] __do_fault+0x33/0xd0
[ 55.268784][ T2798] do_fault+0x3be/0x5c0
[ 55.270390][ T2798] __handle_mm_fault+0x462/0xc00
[ 55.272251][ T2798] handle_mm_fault+0x17c/0x380
[ 55.274055][ T2798] ? handle_mm_fault+0x46/0x380
[ 55.275877][ T2798] __do_page_fault+0x24a/0x4c0
[ 55.277676][ T2798] do_page_fault+0x27/0x1b0
[ 55.279399][ T2798] page_fault+0x34/0x40
[ 55.281053][ T2798] RIP: 0033:0x4009f0
[ 55.282564][ T2798] Code: 03 00 00 00 e8 71 fd ff ff 48 83 f8 ff 49 89 c6 74
74 48 89 c6 bf c0 0c 40 00 31 c0 e8 69 fd ff ff 45 85 ff 7e 21 31 c9 66 90 <41>
0f be 14 0e 01 d3 f7 c1 ff 0f 00 00 75 05 41 c6 04 0e 2a 48 83
[ 55.289631][ T2798] RSP: 002b:7fff1804ec00 EFLAGS: 00010206
[ 55.291835][ T2798] RAX: 001b RBX: RCX:
01a1a000
[ 55.294745][ T2798] RDX: RSI: 7fe5 RDI:
[ 55.297500][ T2798] RBP: 000c R08: R09:
7f4e7392320d
[ 55.300225][ T2798] R10: 0002 R11: 0246 R12:
000186a0
[ 55.303047][ T2798] R13: 0003 R14: 7f4e530d6000 R15:
0280
Re: [PATCH] kconfig: fix missing choice values in auto.conf
On Sat, Aug 3, 2019 at 9:35 AM M. Vefa Bicakci wrote:
>
> Hello,
>
> > conf_write() must be changed accordingly. Currently, it clears
> > SYMBOL_WRITE after the symbol is written into the .config file. This
> > is needed to prevent it from writing the same symbol multiple times in
> > case the symbol is declared in two or more locations. I added the new
> > flag SYMBOL_WRITTEN, to track the symbols that have been written.
> [snip]
> > diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> > index cbb6efa4a5a6..e0972b255aac 100644
> > --- a/scripts/kconfig/confdata.c
> > +++ b/scripts/kconfig/confdata.c
> [snip]
> > @@ -903,7 +904,7 @@ int conf_write(const char *name)
> > fprintf(out, "\n");
> > need_newline = false;
> > }
> > - sym->flags &= ~SYMBOL_WRITE;
> > + sym->flags |= SYMBOL_WRITTEN;
>
> The SYMBOL_WRITTEN flag is never cleared after being set in this
> function, which unfortunately causes data loss to occur when a user
> starts xconfig, gconfig, or nconfig and saves a config file more than
> once. Every save operation after the first one causes the saved .config
> file to contain only comments.
>
> I am appending a patch that resolves this issue. The patch is a bit
> ugly because of the code duplication, but it fixes this bug. (I have
> lightly tested the patch.) Even if the patch is not merged, I would
> appreciate it if this bug could be fixed.
>
> Thank you,
When you clear a flag, the tree traverse order is not a big deal.
So, you can use for_all_symbols() iterator.
Could you send v2 with the following code ?
for_all_symbols(i, sym)
sym->flags &= ~SYMBOL_WRITTEN;
This is quite simple, so you do not need to create a
new helper function for this.
Thanks.
>
> Vefa
>
> === 8< === Patch Follows === >8 ===
>
> From: "M. Vefa Bicakci"
> Date: Fri, 2 Aug 2019 17:44:40 -0400
> Subject: [PATCH] kconfig: Clear "written" flag to avoid data loss
>
> Prior to this commit, starting nconfig, xconfig or gconfig, and saving
> the .config file more than once caused data loss, where a .config file
> that contained only comments would be written to disk starting from the
> second save operation.
>
> This bug manifests itself because the SYMBOL_WRITTEN flag is never
> cleared after the first call to conf_write, and subsequent calls to
> conf_write then skip all of the configuration symbols due to the
> SYMBOL_WRITTEN flag being set.
>
> This commit resolves this issue by clearing the SYMBOL_WRITTEN flag
> from all symbols before conf_write returns.
>
> Fixes: 8e2442a5f86e ("kconfig: fix missing choice values in auto.conf")
> Cc: linux-stable # 4.19+
> Signed-off-by: M. Vefa Bicakci
> ---
> scripts/kconfig/confdata.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> index 1134892599da..24fe0c851e8c 100644
> --- a/scripts/kconfig/confdata.c
> +++ b/scripts/kconfig/confdata.c
> @@ -840,6 +840,35 @@ int conf_write_defconfig(const char *filename)
> return 0;
> }
>
> +static void conf_clear_written_flag(void)
> +{
> + struct menu *menu;
> + struct symbol *sym;
> +
> + menu = rootmenu.list;
> + while (menu) {
> + sym = menu->sym;
> + if (sym && (sym->flags & SYMBOL_WRITTEN))
> + sym->flags &= ~SYMBOL_WRITTEN;
> +
> + if (menu->list) {
> + menu = menu->list;
> + continue;
> + }
> +
> + if (menu->next) {
> + menu = menu->next;
> + } else {
> + while ((menu = menu->parent)) {
> + if (menu->next) {
> + menu = menu->next;
> + break;
> + }
> + }
> + }
> + }
> +}
> +
> int conf_write(const char *name)
> {
> FILE *out;
> @@ -930,6 +959,8 @@ int conf_write(const char *name)
> }
> fclose(out);
>
> + conf_clear_written_flag();
> +
> if (*tmpname) {
> if (is_same(name, tmpname)) {
> conf_message("No change to %s", name);
> --
> 2.21.0
>
--
Best Regards
Masahiro Yamada
Re: [PATCH 4/6] lib/refcount: Move bulk of REFCOUNT_FULL implementation into header
On Fri, Aug 02, 2019 at 08:52:22PM +0200, Peter Zijlstra wrote: > On Fri, Aug 02, 2019 at 11:09:58AM +0100, Will Deacon wrote: > > In an effort to improve performance of the REFCOUNT_FULL implementation, > > move the bulk of its functions into linux/refcount.h. This allows them > > to be inlined in the same way as if they had been provided via > > CONFIG_ARCH_HAS_REFCOUNT. > > Hehe, they started out this way, then Linus said to stuff them in a C > file :-) I asked this at the time and didn't quite get a straight answer; Linus's request was private: https://lore.kernel.org/lkml/20170213180020.gk6...@twins.programming.kicks-ass.net/ It seemed sensible to me (then and now) to have them be inline if there were so many performance concerns about it, etc. Was it just the image size bloat due to the WARNs? So... since we're back to this topic. Why should they not be inline? -- Kees Cook
Re: [RFC PATCH] Revert "mwifiex: fix system hang problem after resume"
Brian Norris writes: >> Changing the patchwork state to RFC means that it's dropped and out of >> my radar. Also, if I see "RFC" in the subject I assume that's a patch >> which I should not apply by default. > > Ack. Well, there were some "RFCs" I sent recently that you *did* > apply, so I didn't really know what happens normally. True, I have sometimes applied RFC patches in case they look good enough and I do not want them to get lost (and this is a good example of RFC patches getting lost). But by default I drop RFC patches after a quick glance. >> > On Fri, Mar 31, 2017 at 01:21:36PM -0700, Brian Norris wrote: > ... >> > FWIW, I got an Acked-by from Amit when he was still at Marvell. And >> > another Reviewed-by from Dmitry. This still applies. Should I resend? >> > (I'll do that if I don't hear a response within a few days.) >> >> This patch is from 2017 so better to resend, and without RFC markings. > > Yep, will do. Thanks. -- https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [RFC PATCH] Revert "mwifiex: fix system hang problem after resume"
On Fri, Aug 2, 2019 at 6:55 PM Kalle Valo wrote: > > Brian Norris writes: > > > + Doug, Matthias, who are seeing problems (or, failure to try to > > recover, as predicted below) > > + Amit's new email > > + new maintainers > > > > Perhaps it's my fault for marking this RFC. But I changed the status > > back to "New" in Patchwork, in case that helps: > > But I still see it marked as RFC. So the patch in question is: > > https://patchwork.kernel.org/patch/9657277/ Oops, I didn't hit the "Update" button :( I changed it now, but I'll change it back again. > Changing the patchwork state to RFC means that it's dropped and out of > my radar. Also, if I see "RFC" in the subject I assume that's a patch > which I should not apply by default. Ack. Well, there were some "RFCs" I sent recently that you *did* apply, so I didn't really know what happens normally. > > On Fri, Mar 31, 2017 at 01:21:36PM -0700, Brian Norris wrote: ... > > FWIW, I got an Acked-by from Amit when he was still at Marvell. And > > another Reviewed-by from Dmitry. This still applies. Should I resend? > > (I'll do that if I don't hear a response within a few days.) > > This patch is from 2017 so better to resend, and without RFC markings. Yep, will do. Brian
Re: [RFC PATCH] Revert "mwifiex: fix system hang problem after resume"
Brian Norris writes: > + Doug, Matthias, who are seeing problems (or, failure to try to > recover, as predicted below) > + Amit's new email > + new maintainers > > Perhaps it's my fault for marking this RFC. But I changed the status > back to "New" in Patchwork, in case that helps: But I still see it marked as RFC. So the patch in question is: https://patchwork.kernel.org/patch/9657277/ Changing the patchwork state to RFC means that it's dropped and out of my radar. Also, if I see "RFC" in the subject I assume that's a patch which I should not apply by default. > On Fri, Mar 31, 2017 at 01:21:36PM -0700, Brian Norris wrote: >> This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836. >> >> This above-mentioned "fix" does not actually do anything to prevent a >> race condition. It simply papers over it so that the issue doesn't >> appear. >> >> If this is a real problem, it should be explained better than the above >> commit does, and an alternative, non-racy solution should be found. >> >> For further reason to revert this: there's ot reason we can't try > > s/ot/no/ > > ...oops. > >> resetting the card when it's *actually* stuck in host-sleep mode. So >> instead, this is unnecessarily creating scenarios where we can't recover >> Wifi. >> >> Cc: Amitkumar Karwar >> Signed-off-by: Brian Norris >> --- >> Amit, please take a look. AIUI, your "fix" is wrong, and quite racy. If you >> still think it's needed, can you please propose an alternative? Or at least >> explain more why this is needed? Thanks. > > FWIW, I got an Acked-by from Amit when he was still at Marvell. And > another Reviewed-by from Dmitry. This still applies. Should I resend? > (I'll do that if I don't hear a response within a few days.) This patch is from 2017 so better to resend, and without RFC markings. -- https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
NFSv4: rare bug *and* root cause captured in the wild
Hi,
While testing unrelated (put_user_pages) work on Linux 5.3-rc2+,
I rebooted the NFS *server*, tried to ssh to the client, and the
client dumped a backtrace as shown below.
Good news: I found that I can reliably reproduce it with those steps,
at commit 1e78030e5e5b (in linux.git) plus my 34-patch series [1], which
off course is completely unrelated. :) Anyway, I'm making a note of the
exact repro commit, so I don't lose the repro.
I see what's wrong, but I do *not* see an easy fix. Can one of the
designers please recommend an approach to fixing this?
This is almost certainly caused by commit 7e0a0e38fcfe ("SUNRPC:
Replace the queue timer with a delayed work function"), which changed
over to running things in process (kthread) context. The commit is dated
May 1, 2019, but I've only been running NFSv4 for a couple days, so
the problem has likely been there all along, not specific to 5.3.
The call stack starts off in atomic context, so we get the bug:
nfs4_do_reclaim
rcu_read_lock /* we are now in_atomic() and must not sleep */
nfs4_purge_state_owners
nfs4_free_state_owner
nfs4_destroy_seqid_counter
rpc_destroy_wait_queue
cancel_delayed_work_sync
__cancel_work_timer
__flush_work
start_flush_work
might_sleep:
(kernel/workqueue.c:2975: BUG)
Details: actual backtrace I am seeing:
BUG: sleeping function called from invalid context at kernel/workqueue.c:2975
in_atomic(): 1, irqs_disabled(): 0, pid: 2224, name: 10.110.48.28-ma
1 lock held by 10.110.48.28-ma/2224:
#0: d338d2ec (rcu_read_lock){}, at: nfs4_do_reclaim+0x22/0x6b0
[nfsv4]
CPU: 8 PID: 2224 Comm: 10.110.48.28-ma Not tainted 5.3.0-rc2-hubbard-github+ #52
Hardware name: ASUS X299-A/PRIME X299-A, BIOS 1704 02/14/2019
Call Trace:
dump_stack+0x46/0x60
___might_sleep.cold+0x8e/0x9b
__flush_work+0x61/0x370
? find_held_lock+0x2b/0x80
? add_timer+0x100/0x200
? _raw_spin_lock_irqsave+0x35/0x40
__cancel_work_timer+0xfb/0x180
? nfs4_purge_state_owners+0xf4/0x170 [nfsv4]
nfs4_free_state_owner+0x10/0x50 [nfsv4]
nfs4_purge_state_owners+0x139/0x170 [nfsv4]
nfs4_do_reclaim+0x7a/0x6b0 [nfsv4]
? pnfs_destroy_layouts_byclid+0xc4/0x100 [nfsv4]
nfs4_state_manager+0x6be/0x7f0 [nfsv4]
nfs4_run_state_manager+0x1b/0x40 [nfsv4]
kthread+0xfb/0x130
? nfs4_state_manager+0x7f0/0x7f0 [nfsv4]
? kthread_bind+0x20/0x20
ret_from_fork+0x35/0x40
And last but not least, some words of encouragement: the reason I moved
from NFSv3 to NFSv4 is that the easy authentication (matching UIDs on
client and server) now works perfectly. Yea! So I'm enjoying v4, despite
the occasional minor glitch. :)
[1] https://lore.kernel.org/r/20190802022005.5117-1-jhubb...@nvidia.com
thanks,
--
John Hubbard
NVIDIA
[PATCH] platform/x86: silead_dmi: Add touchscreen platform data for the Chuwi Surbook Mini tablet
From: Buzzle
---
drivers/platform/x86/touchscreen_dmi.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/platform/x86/touchscreen_dmi.c
b/drivers/platform/x86/touchscreen_dmi.c
index 4370e4add83a..72535b0268eb 100644
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -136,6 +136,22 @@ static const struct ts_dmi_data chuwi_vi10_data = {
.properties = chuwi_vi10_props,
};
+static const struct property_entry chuwi_surbook_mini_props[] = {
+ PROPERTY_ENTRY_U32("touchscreen-min-x", 88),
+ PROPERTY_ENTRY_U32("touchscreen-min-y", 13),
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 2040),
+ PROPERTY_ENTRY_U32("touchscreen-size-y", 1524),
+ PROPERTY_ENTRY_STRING("firmware-name", "gsl1680-chuwi-surbook-mini.fw"),
+ PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+ PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
+ { }
+};
+
+static const struct ts_dmi_data chuwi_surbook_mini_data = {
+ .acpi_name = "MSSL1680:00",
+ .properties = chuwi_surbook_mini_props,
+};
+
static const struct property_entry connect_tablet9_props[] = {
PROPERTY_ENTRY_U32("touchscreen-min-x", 9),
PROPERTY_ENTRY_U32("touchscreen-min-y", 10),
@@ -646,6 +662,14 @@ static const struct dmi_system_id touchscreen_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, "S165"),
},
},
+ {
+ /* Chuwi Surbook Mini (CWI540) */
+ .driver_data = (void *)_surbook_mini_data,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "C3W6_AP108_4G"),
+ },
+ },
{
/* Connect Tablet 9 */
.driver_data = (void *)_tablet9_data,
--
2.22.0
Re: [PATCH] enetc: Select PHYLIB while CONFIG_FSL_ENETC_VF is set
From: YueHaibing
Date: Thu, 1 Aug 2019 09:24:19 +0800
> Like FSL_ENETC, when CONFIG_FSL_ENETC_VF is set,
> we should select PHYLIB, otherwise building still fails:
>
> drivers/net/ethernet/freescale/enetc/enetc.o: In function `enetc_open':
> enetc.c:(.text+0x2744): undefined reference to `phy_start'
> enetc.c:(.text+0x282c): undefined reference to `phy_disconnect'
> drivers/net/ethernet/freescale/enetc/enetc.o: In function `enetc_close':
> enetc.c:(.text+0x28f8): undefined reference to `phy_stop'
> enetc.c:(.text+0x2904): undefined reference to `phy_disconnect'
> drivers/net/ethernet/freescale/enetc/enetc_ethtool.o:(.rodata+0x3f8):
> undefined reference to `phy_ethtool_get_link_ksettings'
> drivers/net/ethernet/freescale/enetc/enetc_ethtool.o:(.rodata+0x400):
> undefined reference to `phy_ethtool_set_link_ksettings'
>
> Reported-by: Hulk Robot
> Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet
> drivers")
> Signed-off-by: YueHaibing
Applied.
Re: [RFC PATCH] Revert "mwifiex: fix system hang problem after resume"
+ Doug, Matthias, who are seeing problems (or, failure to try to recover, as predicted below) + Amit's new email + new maintainers Perhaps it's my fault for marking this RFC. But I changed the status back to "New" in Patchwork, in case that helps: On Fri, Mar 31, 2017 at 01:21:36PM -0700, Brian Norris wrote: > This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836. > > This above-mentioned "fix" does not actually do anything to prevent a > race condition. It simply papers over it so that the issue doesn't > appear. > > If this is a real problem, it should be explained better than the above > commit does, and an alternative, non-racy solution should be found. > > For further reason to revert this: there's ot reason we can't try s/ot/no/ ...oops. > resetting the card when it's *actually* stuck in host-sleep mode. So > instead, this is unnecessarily creating scenarios where we can't recover > Wifi. > > Cc: Amitkumar Karwar > Signed-off-by: Brian Norris > --- > Amit, please take a look. AIUI, your "fix" is wrong, and quite racy. If you > still think it's needed, can you please propose an alternative? Or at least > explain more why this is needed? Thanks. FWIW, I got an Acked-by from Amit when he was still at Marvell. And another Reviewed-by from Dmitry. This still applies. Should I resend? (I'll do that if I don't hear a response within a few days.) Thanks, Brian > drivers/net/wireless/marvell/mwifiex/init.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/marvell/mwifiex/init.c > b/drivers/net/wireless/marvell/mwifiex/init.c > index 756948385b60..0dab77b526de 100644 > --- a/drivers/net/wireless/marvell/mwifiex/init.c > +++ b/drivers/net/wireless/marvell/mwifiex/init.c > @@ -60,7 +60,7 @@ static void wakeup_timer_fn(unsigned long data) > adapter->hw_status = MWIFIEX_HW_STATUS_RESET; > mwifiex_cancel_all_pending_cmd(adapter); > > - if (adapter->if_ops.card_reset && !adapter->hs_activated) > + if (adapter->if_ops.card_reset) > adapter->if_ops.card_reset(adapter); > } > > -- > 2.12.2.564.g063fe858b8-goog >
Re: [PATCH net-next v2 0/6] net: dsa: mv88e6xxx: add support for MV88E6220
From: Hubert Feurstein Date: Wed, 31 Jul 2019 10:23:45 +0200 > This patch series adds support for the MV88E6220 chip to the mv88e6xxx driver. > The MV88E6220 is almost the same as MV88E6250 except that the ports 2-4 are > not routed to pins. > > Furthermore, PTP support is added to the MV88E6250 family. > > v2: > - insert all 6220 entries in correct numerical order > - introduce invalid_port_mask > - move ptp_cc_mult* to ptp_ops and restored original ptp_adjfine code > - added Andrews Reviewed-By to patch 2 and 4 Series applied, thank you.
RE: [PATCH v2 net] hv_sock: Fix hang when a connection is closed
> From: linux-hyperv-ow...@vger.kernel.org > Sent: Friday, August 2, 2019 5:27 PM > ... > Applied and queued up for -stable. > > Do not ever CC: stable for networking patches, we submit to -stable manually. Thanks, David! I'll remember to not add the stable tag for network patches. Thanks, -- Dexuan
Re: [PATCH 4.14 43/43] tipc: pass tunnel dev as NULL to udp_tunnel(6)_xmit_skb
On Fri, Aug 2, 2019 at 7:03 PM Rantala, Tommi T. (Nokia - FI/Espoo) wrote: > > On Fri, 2019-08-02 at 09:28 +0200, gre...@linuxfoundation.org wrote: > > On Thu, Aug 01, 2019 at 10:17:30AM +, Rantala, Tommi T. (Nokia - > > FI/Espoo) wrote: > > > Hi, > > > > > > This tipc patch added in 4.14.132 is triggering a crash for me, > > > revert > > > fixes it. > > > > > > Anyone have ideas if some other commits missing in 4.14.x to make > > > this > > > work...? > > > > Do you also hav a problem with 4.19.y? How about 5.2.y? If not, can > > you do 'git bisect' to find the patch that fixes the issue? > > > > thanks, > > > > greg k-h > > Hi, please pick this to 4.14.y and 4.19.y, tested that it fixes the > crash in both: > > commit 5684abf7020dfc5f0b6ba1d68eda3663871fce52 > Author: Xin Long > Date: Mon Jun 17 21:34:13 2019 +0800 > > ip_tunnel: allow not to count pkts on tstats by setting skb's dev > to NULL Thanks Rantala, sorry for late, I was in a trip. The patch belongs to a patchset: https://www.spinics.net/lists/netdev/msg578674.html So this commit should also be included: commit 6f6a8622057c92408930c31698394fae1557b188 Author: Xin Long Date: Mon Jun 17 21:34:14 2019 +0800 ip6_tunnel: allow not to count pkts on tstats by passing dev as NULL Next time I think I should put "Fixes:" flag into each patch. > > > For 5.2.y nothing is needed, these commits were in v5.2-rc6 already. > > -Tommi >
Re: [PATCH] atm: iphase: Fix Spectre v1 vulnerability
Hi Dave, On 8/2/19 7:31 PM, David Miller wrote: > From: "Gustavo A. R. Silva" > Date: Tue, 30 Jul 2019 22:21:41 -0500 > >> board is controlled by user-space, hence leading to a potential >> exploitation of the Spectre variant 1 vulnerability. >> >> This issue was detected with the help of Smatch: > > Applied and queued up for -stable. > > Do not CC: -stable for networking fixes, we take care of the stable > submissions manually for this subsystem. > Yeah. I'm aware of that. The thing is that you don't appear as a maintainer of this file: $ scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback -f drivers/atm/iphase.c Chas Williams <3ch...@gmail.com> (maintainer:ATM) linux-atm-gene...@lists.sourceforge.net (moderated list:ATM) net...@vger.kernel.org (open list:ATM) linux-kernel@vger.kernel.org (open list) so, I didn't know this patch would be applied to net. Thanks -- Gustavo
Re: linux-next: Fixes tag needs some work in the arm64-fixes tree
On Fri, 2 Aug 2019 07:48:13 +1000
Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 72de4a283cb1 ("arm64: kprobes: Recover pstate.D in single-step exception
> handler")
>
> Fixes tag
>
> Fixes: commit 7419333fa15e ("arm64: kprobe: Always clear pstate.D in
> breakpoint exception handler")
>
> has these problem(s):
>
> - leading word 'commit' unexpected
Oops, sorry. It was my mistake to add "commit", it should be removed.
Will, should I remove it? or could you modify on your tree?
Thank you,
--
Masami Hiramatsu
Re: [PATCH] kconfig: fix missing choice values in auto.conf
Hello,
> conf_write() must be changed accordingly. Currently, it clears
> SYMBOL_WRITE after the symbol is written into the .config file. This
> is needed to prevent it from writing the same symbol multiple times in
> case the symbol is declared in two or more locations. I added the new
> flag SYMBOL_WRITTEN, to track the symbols that have been written.
[snip]
> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> index cbb6efa4a5a6..e0972b255aac 100644
> --- a/scripts/kconfig/confdata.c
> +++ b/scripts/kconfig/confdata.c
[snip]
> @@ -903,7 +904,7 @@ int conf_write(const char *name)
> fprintf(out, "\n");
> need_newline = false;
> }
> - sym->flags &= ~SYMBOL_WRITE;
> + sym->flags |= SYMBOL_WRITTEN;
The SYMBOL_WRITTEN flag is never cleared after being set in this
function, which unfortunately causes data loss to occur when a user
starts xconfig, gconfig, or nconfig and saves a config file more than
once. Every save operation after the first one causes the saved .config
file to contain only comments.
I am appending a patch that resolves this issue. The patch is a bit
ugly because of the code duplication, but it fixes this bug. (I have
lightly tested the patch.) Even if the patch is not merged, I would
appreciate it if this bug could be fixed.
Thank you,
Vefa
=== 8< === Patch Follows === >8 ===
From: "M. Vefa Bicakci"
Date: Fri, 2 Aug 2019 17:44:40 -0400
Subject: [PATCH] kconfig: Clear "written" flag to avoid data loss
Prior to this commit, starting nconfig, xconfig or gconfig, and saving
the .config file more than once caused data loss, where a .config file
that contained only comments would be written to disk starting from the
second save operation.
This bug manifests itself because the SYMBOL_WRITTEN flag is never
cleared after the first call to conf_write, and subsequent calls to
conf_write then skip all of the configuration symbols due to the
SYMBOL_WRITTEN flag being set.
This commit resolves this issue by clearing the SYMBOL_WRITTEN flag
from all symbols before conf_write returns.
Fixes: 8e2442a5f86e ("kconfig: fix missing choice values in auto.conf")
Cc: linux-stable # 4.19+
Signed-off-by: M. Vefa Bicakci
---
scripts/kconfig/confdata.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index 1134892599da..24fe0c851e8c 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -840,6 +840,35 @@ int conf_write_defconfig(const char *filename)
return 0;
}
+static void conf_clear_written_flag(void)
+{
+ struct menu *menu;
+ struct symbol *sym;
+
+ menu = rootmenu.list;
+ while (menu) {
+ sym = menu->sym;
+ if (sym && (sym->flags & SYMBOL_WRITTEN))
+ sym->flags &= ~SYMBOL_WRITTEN;
+
+ if (menu->list) {
+ menu = menu->list;
+ continue;
+ }
+
+ if (menu->next) {
+ menu = menu->next;
+ } else {
+ while ((menu = menu->parent)) {
+ if (menu->next) {
+ menu = menu->next;
+ break;
+ }
+ }
+ }
+ }
+}
+
int conf_write(const char *name)
{
FILE *out;
@@ -930,6 +959,8 @@ int conf_write(const char *name)
}
fclose(out);
+ conf_clear_written_flag();
+
if (*tmpname) {
if (is_same(name, tmpname)) {
conf_message("No change to %s", name);
--
2.21.0
[PATCH v2] arm64/prefetch: fix a -Wtype-limits warning
The commit d5370f754875 ("arm64: prefetch: add alternative pattern for
CPUs without a prefetcher") introduced MIDR_IS_CPU_MODEL_RANGE() to be
used in has_no_hw_prefetch() with rv_min=0 which generates a compilation
warning from GCC,
In file included from ./arch/arm64/include/asm/cache.h:8,
from ./include/linux/cache.h:6,
from ./include/linux/printk.h:9,
from ./include/linux/kernel.h:15,
from ./include/linux/cpumask.h:10,
from arch/arm64/kernel/cpufeature.c:11:
arch/arm64/kernel/cpufeature.c: In function 'has_no_hw_prefetch':
./arch/arm64/include/asm/cputype.h:59:26: warning: comparison of
unsigned expression >= 0 is always true [-Wtype-limits]
_model == (model) && rv >= (rv_min) && rv <= (rv_max); \
^~
arch/arm64/kernel/cpufeature.c:889:9: note: in expansion of macro
'MIDR_IS_CPU_MODEL_RANGE'
return MIDR_IS_CPU_MODEL_RANGE(midr, MIDR_THUNDERX,
^~~
Fix it by making "rv" a "s32".
Signed-off-by: Qian Cai
---
v2: Use "s32" for "rv", so "variant 0/revision 0" can be covered.
arch/arm64/include/asm/cputype.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index e7d46631cc42..d52fe8651c2d 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -54,7 +54,7 @@
#define MIDR_IS_CPU_MODEL_RANGE(midr, model, rv_min, rv_max) \
({ \
u32 _model = (midr) & MIDR_CPU_MODEL_MASK; \
- u32 rv = (midr) & (MIDR_REVISION_MASK | MIDR_VARIANT_MASK); \
+ s32 rv = (midr) & (MIDR_REVISION_MASK | MIDR_VARIANT_MASK); \
\
_model == (model) && rv >= (rv_min) && rv <= (rv_max); \
})
--
2.20.1 (Apple Git-117)
Re: [PATCH net-next v2 0/4] net: phy: Add AST2600 MDIO support
From: Andrew Jeffery Date: Wed, 31 Jul 2019 15:09:55 +0930 > v2 of the ASPEED MDIO series addresses comments from Rob on the devicetree > bindings and Andrew on the driver itself. > > v1 of the series can be found here: > > http://patchwork.ozlabs.org/cover/1138140/ > > Please review! Series applied, thank you.
Re: [PATCH] atm: iphase: Fix Spectre v1 vulnerability
From: "Gustavo A. R. Silva" Date: Tue, 30 Jul 2019 22:21:41 -0500 > board is controlled by user-space, hence leading to a potential > exploitation of the Spectre variant 1 vulnerability. > > This issue was detected with the help of Smatch: Applied and queued up for -stable. Do not CC: -stable for networking fixes, we take care of the stable submissions manually for this subsystem. Thank you.
Re: [PATCH net v3] net: ipv6: Fix a bug in ndisc_send_ns when netdev only has a global address
From: Su Yanjun Date: Wed, 31 Jul 2019 09:52:52 +0800 > When the egress interface does not have a link local address, it can > not communicate with other hosts. > > In RFC4861, 7.2.2 says > "If the source address of the packet prompting the solicitation is the > same as one of the addresses assigned to the outgoing interface, that > address SHOULD be placed in the IP Source Address of the outgoing > solicitation. Otherwise, any one of the addresses assigned to the > interface should be used." > > In this patch we try get a global address if we get ll address failed. > > Signed-off-by: Su Yanjun > --- > Changes since V2: > - Let banned_flags under the scope of its use. I do not want to apply this. The only situation where this can occur is when userland is managing the interface addresses and has failed to properly add a link local address. That is a failure by userspace to uphold it's responsibilites when it has taken over management of these issues, not a situation the kernel should handle. Sorry.
Re: [PATCH v2 net] hv_sock: Fix hang when a connection is closed
From: Dexuan Cui
Date: Wed, 31 Jul 2019 01:25:45 +
>
> There is a race condition for an established connection that is being closed
> by the guest: the refcnt is 4 at the end of hvs_release() (Note: here the
> 'remove_sock' is false):
>
> 1 for the initial value;
> 1 for the sk being in the bound list;
> 1 for the sk being in the connected list;
> 1 for the delayed close_work.
>
> After hvs_release() finishes, __vsock_release() -> sock_put(sk) *may*
> decrease the refcnt to 3.
>
> Concurrently, hvs_close_connection() runs in another thread:
> calls vsock_remove_sock() to decrease the refcnt by 2;
> call sock_put() to decrease the refcnt to 0, and free the sk;
> next, the "release_sock(sk)" may hang due to use-after-free.
>
> In the above, after hvs_release() finishes, if hvs_close_connection() runs
> faster than "__vsock_release() -> sock_put(sk)", then there is not any issue,
> because at the beginning of hvs_close_connection(), the refcnt is still 4.
>
> The issue can be resolved if an extra reference is taken when the
> connection is established.
>
> Fixes: a9eeb998c28d ("hv_sock: Add support for delayed close")
> Signed-off-by: Dexuan Cui
Applied and queued up for -stable.
Do not ever CC: stable for networking patches, we submit to -stable manually.
Thank you.
Re: [PATCH v2] media:dvb-frontends:Remove dvb_pll_devcount and id module parameters.
On Fri, Aug 02, 2019 at 12:20:19PM +0530, Vandana BN wrote: > > On 01/08/19 2:31 PM, Michael Ira Krufky wrote: > > Sean, > > > > Please pardon the late reply. See my responses inline below: > > > > On Wed, Jul 24, 2019 at 1:36 AM Sean Young wrote: > >> On Sat, Jul 20, 2019 at 11:43:02AM +0530, Vandana BN wrote: > >>> Syzbot reported global-out-of-bounds Read in dvb_pll_attach, while > >>> accessing id[dvb_pll_devcount], because dvb_pll_devcount was 65, > >>> that is more than size of 'id' which is DVB_PLL_MAX(64). > >>> > >>> Fix would be to check if DVB_PLL_MAX devices are attached and if so return > >>> NULL from dvb_pll_attach(). But this will put a limit on the number of > >>> devices that can be attached. > >>> Also dvb_pll_devcount and "id" module parameter are used for debugging > >>> purpose to override/force PLL type. > >>> So this patch removes these module parameters. > >>> > >>> Reported-by: syz...@syzkaller.appspotmail.com > >>> > >>> usb 1-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the > >>> software demuxer > >>> dvbdev: DVB: registering new adapter (774 Friio White ISDB-T USB2.0) > >>> usb 1-1: media controller created > >>> dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered. > >>> tc90522 0-0018: Toshiba TC90522 attached. > >>> usb 1-1: DVB: registering adapter 0 frontend 0 (Toshiba TC90522 ISDB-T > >>> module)... > >>> dvbdev: dvb_create_media_entity: media entity 'Toshiba TC90522 ISDB-T > >>> module' registered. > >>> == > >>> BUG: KASAN: global-out-of-bounds in dvb_pll_attach+0x6c5/0x830 > >>> drivers/media/dvb-frontends/dvb-pll.c:798 > >>> Read of size 4 at addr 89c9e5e0 by task kworker/0:1/12 > >>> > >>> CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.2.0-rc6+ #13 > >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > >>> Google 01/01/2011 > >>> Workqueue: usb_hub_wq hub_event > >>> Call Trace: > >>> __dump_stack lib/dump_stack.c:77 [inline] > >>> dump_stack+0xca/0x13e lib/dump_stack.c:113 > >>> print_address_description+0x67/0x231 mm/kasan/report.c:188 > >>> __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317 > >>> kasan_report+0xe/0x20 mm/kasan/common.c:614 > >>> dvb_pll_attach+0x6c5/0x830 drivers/media/dvb-frontends/dvb-pll.c:798 > >>> dvb_pll_probe+0xfe/0x174 drivers/media/dvb-frontends/dvb-pll.c:877 > >>> i2c_device_probe+0x790/0xaa0 drivers/i2c/i2c-core-base.c:389 > >>> really_probe+0x281/0x660 drivers/base/dd.c:509 > >>> driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > >>> __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > >>> bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > >>> __device_attach+0x217/0x360 drivers/base/dd.c:843 > >>> bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > >>> device_add+0xae6/0x16f0 drivers/base/core.c:2111 > >>> i2c_new_client_device+0x5b3/0xc40 drivers/i2c/i2c-core-base.c:778 > >>> i2c_new_device+0x19/0x50 drivers/i2c/i2c-core-base.c:821 > >>> dvb_module_probe+0xf9/0x220 drivers/media/dvb-core/dvbdev.c:985 > >>> friio_tuner_attach+0x125/0x1d0 drivers/media/usb/dvb-usb-v2/gl861.c:536 > >>> dvb_usbv2_adapter_frontend_init > >>> drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:675 [inline] > >>> dvb_usbv2_adapter_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:804 > >>> [inline] > >>> dvb_usbv2_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:865 [inline] > >>> dvb_usbv2_probe.cold+0x24dc/0x255d > >>> drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:980 > >>> usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361 > >>> really_probe+0x281/0x660 drivers/base/dd.c:509 > >>> driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > >>> __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > >>> bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > >>> __device_attach+0x217/0x360 drivers/base/dd.c:843 > >>> bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > >>> device_add+0xae6/0x16f0 drivers/base/core.c:2111 > >>> usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023 > >>> generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210 > >>> usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266 > >>> really_probe+0x281/0x660 drivers/base/dd.c:509 > >>> driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > >>> __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > >>> bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > >>> __device_attach+0x217/0x360 drivers/base/dd.c:843 > >>> bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > >>> device_add+0xae6/0x16f0 drivers/base/core.c:2111 > >>> usb_new_device.cold+0x8c1/0x1016 drivers/usb/core/hub.c:2534 > >>> hub_port_connect drivers/usb/core/hub.c:5089 [inline] > >>> hub_port_connect_change drivers/usb/core/hub.c:5204 [inline] > >>> port_event drivers/usb/core/hub.c:5350 [inline] > >>> hub_event+0x1ada/0x3590 drivers/usb/core/hub.c:5432 >
Re: [PATCH v4] staging: kpc2000: Convert put_page() to put_user_page*()
On 7/25/19 5:44 AM, Bharath Vedartham wrote:
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
Hi Bharath,
If you like, I could re-post your patch here, modified slightly, as part of
the next version of the miscellaneous call site conversion series [1].
As part of that, we should change this to use put_user_pages_dirty_lock()
(see below).
> Cc: Ira Weiny
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Greg Kroah-Hartman
> Cc: Matt Sickler
> Cc: de...@driverdev.osuosl.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@kvack.org
> Reviewed-by: John Hubbard
> Signed-off-by: Bharath Vedartham
> ---
> Changes since v1
> - Improved changelog by John's suggestion.
> - Moved logic to dirty pages below sg_dma_unmap
> and removed PageReserved check.
> Changes since v2
> - Added back PageResevered check as
> suggested by John Hubbard.
> Changes since v3
> - Changed the changelog as suggested by John.
> - Added John's Reviewed-By tag.
> Changes since v4
> - Rebased the patch on the staging tree.
> - Improved commit log by fixing a line wrap.
> ---
> drivers/staging/kpc2000/kpc_dma/fileops.c | 17 ++---
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/staging/kpc2000/kpc_dma/fileops.c
> b/drivers/staging/kpc2000/kpc_dma/fileops.c
> index 48ca88b..f15e292 100644
> --- a/drivers/staging/kpc2000/kpc_dma/fileops.c
> +++ b/drivers/staging/kpc2000/kpc_dma/fileops.c
> @@ -190,9 +190,7 @@ static int kpc_dma_transfer(struct dev_private_data *priv,
> sg_free_table(>sgt);
> err_dma_map_sg:
> err_alloc_sg_table:
> - for (i = 0 ; i < acd->page_count ; i++) {
> - put_page(acd->user_pages[i]);
> - }
> + put_user_pages(acd->user_pages, acd->page_count);
> err_get_user_pages:
> kfree(acd->user_pages);
> err_alloc_userpages:
> @@ -211,16 +209,13 @@ void transfer_complete_cb(struct aio_cb_data *acd,
> size_t xfr_count, u32 flags)
> BUG_ON(acd->ldev == NULL);
> BUG_ON(acd->ldev->pldev == NULL);
>
> - for (i = 0 ; i < acd->page_count ; i++) {
> - if (!PageReserved(acd->user_pages[i])) {
> - set_page_dirty(acd->user_pages[i]);
> - }
> - }
> -
> dma_unmap_sg(>ldev->pldev->dev, acd->sgt.sgl, acd->sgt.nents,
> acd->ldev->dir);
>
> - for (i = 0 ; i < acd->page_count ; i++) {
> - put_page(acd->user_pages[i]);
> + for (i = 0; i < acd->page_count; i++) {
> + if (!PageReserved(acd->user_pages[i]))
> + put_user_pages_dirty(>user_pages[i], 1);
This would change to:
put_user_pages_dirty_lock(>user_pages[i], 1, true);
...and we'd add this blurb (this time with CH's name spelled properly) to
the commit description:
Note that this effectively changes the code's behavior in
qp_release_pages(): it now ultimately calls set_page_dirty_lock(),
instead of set_page_dirty(). This is probably more accurate.
As Christoph Hellwig put it, "set_page_dirty() is only safe if we are
dealing with a file backed page where we have reference on the inode it
hangs off." [1]
[1] https://lore.kernel.org/r/20190723153640.gb...@lst.de
Also, future: I don't know the driver well enough to say, but maybe "true"
could be replaced by "acd->ldev->dir == DMA_FROM_DEVICE", there, but that
would be a separate patch.
thanks,
--
John Hubbard
NVIDIA
> + else
> + put_user_page(acd->user_pages[i]);
> }
>
> sg_free_table(>sgt);
>
Re: [PATCH] selftest/ftrace: Fix typo in trigger-snapshot.tc
On 8/2/19 5:01 PM, Masanari Iida wrote: > This patch fixes a spelling typo in tigger-snapshot.tc typo:)trigger- > Signed-off-by: Masanari Iida > --- > .../testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git > a/tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc > b/tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc > index 7717c0a09686..ac738500d17f 100644 > --- a/tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc > +++ b/tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc > @@ -28,7 +28,7 @@ if [ -z "$FEATURE" ]; then > exit_unsupported > fi > > -echo "Test snapshot tigger" > +echo "Test snapshot trigger" > echo 0 > snapshot > echo 1 > events/sched/sched_process_fork/enable > ( echo "forked") > -- ~Randy
[PATCH] selftest/ftrace: Fix typo in trigger-snapshot.tc
This patch fixes a spelling typo in tigger-snapshot.tc Signed-off-by: Masanari Iida --- .../testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc b/tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc index 7717c0a09686..ac738500d17f 100644 --- a/tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc +++ b/tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc @@ -28,7 +28,7 @@ if [ -z "$FEATURE" ]; then exit_unsupported fi -echo "Test snapshot tigger" +echo "Test snapshot trigger" echo 0 > snapshot echo 1 > events/sched/sched_process_fork/enable ( echo "forked") -- 2.23.0.rc0
RE: [PATCH V3 1/2] cpufreq: schedutil: Don't skip freq update when limits change
On 2019.08.02 02:12 Rafael J. Wysocki wrote:
> On Fri, Aug 2, 2019 at 7:44 AM Viresh Kumar wrote:
>>
>> To avoid reducing the frequency of a CPU prematurely, we skip reducing
>> the frequency if the CPU had been busy recently.
>>
>> This should not be done when the limits of the policy are changed, for
>> example due to thermal throttling. We should always get the frequency
>> within the new limits as soon as possible.
>>
>> Trying to fix this by using only one flag, i.e. need_freq_update, can
>> lead to a race condition where the flag gets cleared without forcing us
>> to change the frequency at least once. And so this patch introduces
>> another flag to avoid that race condition.
>>
>> Fixes: ecd288429126 ("cpufreq: schedutil: Don't set next_freq to UINT_MAX")
>> Cc: v4.18+ # v4.18+
>> Reported-by: Doug Smythies
>> Signed-off-by: Viresh Kumar
>> ---
>> V2->V3:
>> - Updated commit log.
>>
>> V1->V2:
>> - Fixed the race condition using a different flag.
>>
>> @Doug: I haven't changed the code since you last tested these. Your
>> Tested-by tag can be useful while applying the patches. Thanks.
Tested-by: Doug Smythies
For acpi-cpufreq/schedutil only (which we already know).
I tested including Rafael's suggested change.
I.E.
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 592ff72..ae3ec77 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -441,7 +441,7 @@ static void sugov_update_single(struct update_util_data
*hook, u64 time,
struct sugov_policy *sg_policy = sg_cpu->sg_policy;
unsigned long util, max;
unsigned int next_f;
- bool busy = false;
+ bool busy;
sugov_iowait_boost(sg_cpu, time, flags);
sg_cpu->last_update = time;
@@ -452,8 +452,7 @@ static void sugov_update_single(struct update_util_data
*hook, u64 time,
return;
/* Limits may have changed, don't skip frequency update */
- if (!sg_policy->need_freq_update)
- busy = sugov_cpu_is_busy(sg_cpu);
+ busy = !sg_policy->need_freq_update && sugov_cpu_is_busy(sg_cpu);
util = sugov_get_util(sg_cpu);
max = sg_cpu->max;
... Doug
Re: [PATCH v7 07/20] clk: tegra: clk-periph: Add save and restore support
On 8/2/19 2:15 PM, Dmitry Osipenko wrote:
02.08.2019 23:32, Sowjanya Komatineni пишет:
On 8/2/19 1:17 PM, Dmitry Osipenko wrote:
02.08.2019 23:13, Dmitry Osipenko пишет:
02.08.2019 21:33, Sowjanya Komatineni пишет:
On 8/2/19 5:38 AM, Dmitry Osipenko wrote:
02.08.2019 2:49, Sowjanya Komatineni пишет:
On 8/1/19 4:19 PM, Sowjanya Komatineni wrote:
On 8/1/19 2:30 PM, Sowjanya Komatineni wrote:
On 8/1/19 1:54 PM, Dmitry Osipenko wrote:
01.08.2019 23:31, Sowjanya Komatineni пишет:
On 8/1/19 1:17 PM, Dmitry Osipenko wrote:
01.08.2019 22:42, Sowjanya Komatineni пишет:
On 8/1/19 12:00 PM, Dmitry Osipenko wrote:
01.08.2019 20:58, Sowjanya Komatineni пишет:
On 7/31/19 4:09 PM, Sowjanya Komatineni wrote:
On 7/31/19 3:44 AM, Dmitry Osipenko wrote:
31.07.2019 12:50, Dmitry Osipenko пишет:
31.07.2019 3:20, Sowjanya Komatineni пишет:
This patch implements save and restore context for
peripheral
fixed
clock ops, peripheral gate clock ops, sdmmc mux clock
ops, and
peripheral clock ops.
During system suspend, core power goes off and looses the
settings
of the Tegra CAR controller registers.
So during suspend entry clock and reset state of
peripherals is
saved
and on resume they are restored to have clocks back to
same
rate and
state as before suspend.
Acked-by: Thierry Reding
Signed-off-by: Sowjanya Komatineni
---
drivers/clk/tegra/clk-periph-fixed.c | 33
drivers/clk/tegra/clk-periph-gate.c | 34
+
drivers/clk/tegra/clk-periph.c | 37
drivers/clk/tegra/clk-sdmmc-mux.c | 28
+++
drivers/clk/tegra/clk.h | 6 ++
5 files changed, 138 insertions(+)
diff --git a/drivers/clk/tegra/clk-periph-fixed.c
b/drivers/clk/tegra/clk-periph-fixed.c
index c088e7a280df..21b24530fa00 100644
--- a/drivers/clk/tegra/clk-periph-fixed.c
+++ b/drivers/clk/tegra/clk-periph-fixed.c
@@ -60,11 +60,44 @@
tegra_clk_periph_fixed_recalc_rate(struct
clk_hw *hw,
return (unsigned long)rate;
}
+static int
tegra_clk_periph_fixed_save_context(struct
clk_hw
*hw)
+{
+ struct tegra_clk_periph_fixed *fixed =
to_tegra_clk_periph_fixed(hw);
+ u32 mask = 1 << (fixed->num % 32);
+
+ fixed->enb_ctx = readl_relaxed(fixed->base +
fixed->regs->enb_reg) &
+ mask;
+ fixed->rst_ctx = readl_relaxed(fixed->base +
fixed->regs->rst_reg) &
+ mask;
+
+ return 0;
+}
+
+static void
tegra_clk_periph_fixed_restore_context(struct
clk_hw
*hw)
+{
+ struct tegra_clk_periph_fixed *fixed =
to_tegra_clk_periph_fixed(hw);
+ u32 mask = 1 << (fixed->num % 32);
+
+ if (fixed->enb_ctx)
+ writel_relaxed(mask, fixed->base +
fixed->regs->enb_set_reg);
+ else
+ writel_relaxed(mask, fixed->base +
fixed->regs->enb_clr_reg);
+
+ udelay(2);
+
+ if (!fixed->rst_ctx) {
+ udelay(5); /* reset propogation delay */
+ writel_relaxed(mask, fixed->base +
fixed->regs->rst_reg);
+ }
+}
+
static const struct clk_ops
tegra_clk_periph_fixed_ops
= {
.is_enabled =
tegra_clk_periph_fixed_is_enabled,
.enable = tegra_clk_periph_fixed_enable,
.disable = tegra_clk_periph_fixed_disable,
.recalc_rate =
tegra_clk_periph_fixed_recalc_rate,
+ .save_context = tegra_clk_periph_fixed_save_context,
+ .restore_context =
tegra_clk_periph_fixed_restore_context,
};
struct clk
*tegra_clk_register_periph_fixed(const
char
*name,
diff --git a/drivers/clk/tegra/clk-periph-gate.c
b/drivers/clk/tegra/clk-periph-gate.c
index 4b31beefc9fc..6ba5b08e0787 100644
--- a/drivers/clk/tegra/clk-periph-gate.c
+++ b/drivers/clk/tegra/clk-periph-gate.c
@@ -25,6 +25,8 @@ static
DEFINE_SPINLOCK(periph_ref_lock);
#define read_rst(gate) \
readl_relaxed(gate->clk_base +
(gate->regs->rst_reg))
+#define write_rst_set(val, gate) \
+ writel_relaxed(val, gate->clk_base +
(gate->regs->rst_set_reg))
#define write_rst_clr(val, gate) \
writel_relaxed(val, gate->clk_base +
(gate->regs->rst_clr_reg))
@@ -110,10 +112,42 @@ static void
clk_periph_disable(struct
clk_hw *hw)
spin_unlock_irqrestore(_ref_lock, flags);
}
+static int clk_periph_gate_save_context(struct
clk_hw
*hw)
+{
+ struct tegra_clk_periph_gate *gate =
to_clk_periph_gate(hw);
+
+ gate->clk_state_ctx = read_enb(gate) &
periph_clk_to_bit(gate);
+ gate->rst_state_ctx = read_rst(gate) &
periph_clk_to_bit(gate);
+
+ return 0;
+}
+
+static void clk_periph_gate_restore_context(struct
clk_hw
*hw)
+{
+ struct tegra_clk_periph_gate *gate =
to_clk_periph_gate(hw);
+
+ if (gate->clk_state_ctx)
+ write_enb_set(periph_clk_to_bit(gate), gate);
+ else
+ write_enb_clr(periph_clk_to_bit(gate), gate);
+
+ udelay(5);
+
+ if (!(gate->flags & TEGRA_PERIPH_NO_RESET) &&
+ !(gate->flags & TEGRA_PERIPH_MANUAL_RESET)) {
+
Re: [PATCH] arm64/prefetch: fix a -Wtype-limits warning
On 2019-08-02 10:08 pm, Qian Cai wrote:
The commit d5370f754875 ("arm64: prefetch: add alternative pattern for
CPUs without a prefetcher") introduced MIDR_IS_CPU_MODEL_RANGE() to be
used in has_no_hw_prefetch() with rv_min=0 which generates a compilation
warning from GCC,
In file included from ./arch/arm64/include/asm/cache.h:8,
from ./include/linux/cache.h:6,
from ./include/linux/printk.h:9,
from ./include/linux/kernel.h:15,
from ./include/linux/cpumask.h:10,
from arch/arm64/kernel/cpufeature.c:11:
arch/arm64/kernel/cpufeature.c: In function 'has_no_hw_prefetch':
./arch/arm64/include/asm/cputype.h:59:26: warning: comparison of
unsigned expression >= 0 is always true [-Wtype-limits]
_model == (model) && rv >= (rv_min) && rv <= (rv_max); \
^~
arch/arm64/kernel/cpufeature.c:889:9: note: in expansion of macro
'MIDR_IS_CPU_MODEL_RANGE'
return MIDR_IS_CPU_MODEL_RANGE(midr, MIDR_THUNDERX,
^~~
Fix it by making rv_min=1.
With what justification? Are you suggesting revision 0 variant 0 of this
CPU has suddenly grown a prefetcher? Or that arbitrarily perturbing
bounds until a warning shuts up is a fine development strategy, because
a quiet build for people who like turning on random extra warnings is
more important than correct functionality?
Robin.
Signed-off-by: Qian Cai
---
arch/arm64/kernel/cpufeature.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index f29f36a65175..7d15cf6d62c1 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -883,7 +883,7 @@ static bool has_no_hw_prefetch(const struct
arm64_cpu_capabilities *entry, int _
/* Cavium ThunderX pass 1.x and 2.x */
return MIDR_IS_CPU_MODEL_RANGE(midr, MIDR_THUNDERX,
- MIDR_CPU_VAR_REV(0, 0),
+ MIDR_CPU_VAR_REV(0, 1),
MIDR_CPU_VAR_REV(1, MIDR_REVISION_MASK));
}
Re: [PATCH] m68k: Prevent some compiler warnings in coldfire builds
Hi Finn,
On 2/8/19 10:10 am, Finn Thain wrote:
Since commit d3b41b6bb49e ("m68k: Dispatch nvram_ops calls to Atari or
Mac functions"), Coldfire builds generate compiler warnings due to the
unconditional inclusion of asm/atarihw.h and asm/macintosh.h.
The inclusion of asm/atarihw.h causes warnings like this:
In file included from ./arch/m68k/include/asm/atarihw.h:25:0,
from arch/m68k/kernel/setup_mm.c:41,
from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/raw_io.h:39:0: warning: "__raw_readb" redefined
#define __raw_readb in_8
In file included from ./arch/m68k/include/asm/io.h:6:0,
from arch/m68k/kernel/setup_mm.c:36,
from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/io_no.h:16:0: note: this is the location of the
previous definition
#define __raw_readb(addr) \
...
This issue is resolved by dropping the asm/raw_io.h include. It turns out
that asm/io_mm.h already includes that header file.
Moving the relevant macro definitions helps to clarify this dependency
and make it safe to include asm/atarihw.h.
The other warnings look like this:
In file included from arch/m68k/kernel/setup_mm.c:48:0,
from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/macintosh.h:19:35: warning: 'struct irq_data' declared
inside parameter list will not be visible outside of this definition or
declaration
extern void mac_irq_enable(struct irq_data *data);
^~~~
...
This issue is resolved by adding the missing linux/irq.h include.
Cc: Michael Schmitz
Signed-off-by: Finn Thain
---
arch/m68k/include/asm/atarihw.h | 9 -
arch/m68k/include/asm/io_mm.h | 6 +-
arch/m68k/include/asm/macintosh.h | 1 +
3 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/arch/m68k/include/asm/atarihw.h b/arch/m68k/include/asm/atarihw.h
index 533008262b69..5e5601c382b8 100644
--- a/arch/m68k/include/asm/atarihw.h
+++ b/arch/m68k/include/asm/atarihw.h
@@ -22,7 +22,6 @@
#include
#include
-#include
#include
extern u_long atari_mch_cookie;
@@ -132,14 +131,6 @@ extern struct atari_hw_present atari_hw_present;
*/
-#define atari_readb raw_inb
-#define atari_writeb raw_outb
-
-#define atari_inb_p raw_inb
-#define atari_outb_p raw_outb
-
-
-
#include
#include
diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
index 6c03ca5bc436..819f611dccf2 100644
--- a/arch/m68k/include/asm/io_mm.h
+++ b/arch/m68k/include/asm/io_mm.h
@@ -29,7 +29,11 @@
#include
#ifdef CONFIG_ATARI
-#include
+#define atari_readb raw_inb
+#define atari_writeb raw_outb
+
+#define atari_inb_p raw_inb
+#define atari_outb_p raw_outb
#endif
diff --git a/arch/m68k/include/asm/macintosh.h b/arch/m68k/include/asm/macintosh.h
index 8f0698bca3dc..8a43babcf53a 100644
--- a/arch/m68k/include/asm/macintosh.h
+++ b/arch/m68k/include/asm/macintosh.h
@@ -4,6 +4,7 @@
#include
#include
+#include
#include
Looks good to me:
Acked-by: Greg Ungerer
Geert: I can take this via the m68knommu tree if you like?
Or if you want to pick it up then no problem.
Regards
Greg
Re: [PATCH] net: sctp: Rename fallthrough label to unhandled
On Fri, 2019-08-02 at 16:19 -0700, David Miller wrote: > From: Joe Perches > Date: Fri, 02 Aug 2019 10:47:34 -0700 > > > On Wed, 2019-07-31 at 08:16 -0400, Neil Horman wrote: > >> On Wed, Jul 31, 2019 at 04:32:43AM -0700, Joe Perches wrote: > >> > On Wed, 2019-07-31 at 07:19 -0400, Neil Horman wrote: > >> > > On Tue, Jul 30, 2019 at 10:04:37PM -0700, Joe Perches wrote: > >> > > > fallthrough may become a pseudo reserved keyword so this only use of > >> > > > fallthrough is better renamed to allow it. > > > > Can you or any other maintainer apply this patch > > or ack it so David Miller can apply it? > > I, like others, don't like the lack of __ in the keyword. It's kind of > rediculous the problems it creates to pollute the global namespace like > that and yes also inconsistent with other shorthands for builtins. Please add that to the conversation on the RFC thread. https://lore.kernel.org/patchwork/patch/1108577/ In any case, fallthrough is not really a good label name for this use.
Re: [PATCH 5.2 00/20] 5.2.6-stable review
On 8/2/19 3:39 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 5.2.6 release. There are 20 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 04 Aug 2019 09:19:34 AM UTC. 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.2.6-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.2.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH v2 1/6] hwrng: core: Freeze khwrng thread during suspend
Quoting Jarkko Sakkinen (2019-08-02 13:22:09)
> On Tue, Jul 16, 2019 at 03:45:13PM -0700, Stephen Boyd wrote:
> > The hwrng_fill() function can run while devices are suspending and
> > resuming. If the hwrng is behind a bus such as i2c or SPI and that bus
> > is suspended, the hwrng may hang the bus while attempting to add some
> > randomness. It's been observed on ChromeOS devices with suspend-to-idle
> > (s2idle) and an i2c based hwrng that this kthread may run and ask the
> > hwrng device for randomness before the i2c bus has been resumed.
> >
> > Let's make this kthread freezable so that we don't try to touch the
> > hwrng during suspend/resume. This ensures that we can't cause the hwrng
> > backing driver to get into a bad state because the device is guaranteed
> > to be resumed before the hwrng kthread is thawed.
> >
> > Cc: Andrey Pronin
> > Cc: Herbert Xu
> > Cc: Duncan Laurie
> > Signed-off-by: Stephen Boyd
>
> This does not need a fixes tag?
>
I'll add Fixes: be4000bc4644 ("hwrng: create filler thread")
Re: [PATCH 4.19 00/32] 4.19.64-stable review
On 8/2/19 3:39 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.19.64 release. There are 32 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 04 Aug 2019 09:19:34 AM UTC. 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.64-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 Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.14 00/25] 4.14.136-stable review
On 8/2/19 3:39 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.136 release. There are 25 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 04 Aug 2019 09:19:34 AM UTC. 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.136-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH] net: sctp: Rename fallthrough label to unhandled
From: Joe Perches Date: Fri, 02 Aug 2019 10:47:34 -0700 > On Wed, 2019-07-31 at 08:16 -0400, Neil Horman wrote: >> On Wed, Jul 31, 2019 at 04:32:43AM -0700, Joe Perches wrote: >> > On Wed, 2019-07-31 at 07:19 -0400, Neil Horman wrote: >> > > On Tue, Jul 30, 2019 at 10:04:37PM -0700, Joe Perches wrote: >> > > > fallthrough may become a pseudo reserved keyword so this only use of >> > > > fallthrough is better renamed to allow it. > > Can you or any other maintainer apply this patch > or ack it so David Miller can apply it? I, like others, don't like the lack of __ in the keyword. It's kind of rediculous the problems it creates to pollute the global namespace like that and yes also inconsistent with other shorthands for builtins.
Re: [PATCH 4.9 000/223] 4.9.187-stable review
On 8/2/19 3:33 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.187 release. There are 223 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 04 Aug 2019 09:19:34 AM UTC. 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.187-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [GIT PULL] parisc architecture fixes for kernel v5.3-rc3
The pull request you sent on Fri, 2 Aug 2019 18:04:47 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git > parisc-5.3-4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9100fc5ae83e64d99fd3300104893ef0e0b0aadb Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] s390 updates for 5.3-rc3
The pull request you sent on Fri, 2 Aug 2019 16:08:08 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-5.3-4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4dd68199f3ed7ee62f94869a1d7b29749e3696fb Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] xen: fixes for 5.3-rc3
The pull request you sent on Fri, 2 Aug 2019 16:47:46 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > for-linus-5.3a-rc3-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/dcb8cfbd8fe9e62c7d64e82288d3ffe2502b7371 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] arm64 fixes for 5.3-rc3
The pull request you sent on Fri, 2 Aug 2019 18:17:55 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a507f25d1c2048c136f6834f10966510b62af987 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 4.4 000/158] 4.4.187-stable review
On 8/2/19 3:27 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.187 release. There are 158 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 04 Aug 2019 09:19:34 AM UTC. 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.187-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
[PATCH v4 0/2] khugepaged: collapse pmd for pte-mapped THP
Changes v3 => v4: 1. Simplify locking for pte_mapped_thp (Oleg). 2. Improve checks for the page in collapse_pte_mapped_thp() (Oleg). 3. Move HPAGE_PMD_MASK to collapse_pte_mapped_thp() (kbuild test robot). Changes v2 => v3: 1. Update vma/pmd check in collapse_pte_mapped_thp() (Oleg). 2. Add Acked-by from Kirill Changes v1 => v2: 1. Call collapse_pte_mapped_thp() directly from uprobe_write_opcode(); 2. Add VM_BUG_ON() for addr alignment in khugepaged_add_pte_mapped_thp() and collapse_pte_mapped_thp(). This set is the newer version of 5/6 and 6/6 of [1]. Newer version of 1-4 of the work [2] was recently picked by Andrew. Patch 1 enables khugepaged to handle pte-mapped THP. These THPs are left in such state when khugepaged failed to get exclusive lock of mmap_sem. Patch 2 leverages work in 1 for uprobe on THP. After [2], uprobe only splits the PMD. When the uprobe is disabled, we get pte-mapped THP. After this set, these pte-mapped THP will be collapsed as pmd-mapped. [1] https://lkml.org/lkml/2019/6/23/23 [2] https://www.spinics.net/lists/linux-mm/msg185889.html Song Liu (2): khugepaged: enable collapse pmd for pte-mapped THP uprobe: collapse THP pmd after removing all uprobes include/linux/khugepaged.h | 12 kernel/events/uprobes.c| 9 +++ mm/khugepaged.c| 125 - 3 files changed, 145 insertions(+), 1 deletion(-) -- 2.17.1
[PATCH v4 1/2] khugepaged: enable collapse pmd for pte-mapped THP
khugepaged needs exclusive mmap_sem to access page table. When it fails
to lock mmap_sem, the page will fault in as pte-mapped THP. As the page
is already a THP, khugepaged will not handle this pmd again.
This patch enables the khugepaged to retry collapse the page table.
struct mm_slot (in khugepaged.c) is extended with an array, containing
addresses of pte-mapped THPs. We use array here for simplicity. We can
easily replace it with more advanced data structures when needed.
In khugepaged_scan_mm_slot(), if the mm contains pte-mapped THP, we try
to collapse the page table.
Since collapse may happen at an later time, some pages may already fault
in. collapse_pte_mapped_thp() is added to properly handle these pages.
collapse_pte_mapped_thp() also double checks whether all ptes in this pmd
are mapping to the same THP. This is necessary because some subpage of
the THP may be replaced, for example by uprobe. In such cases, it is not
possible to collapse the pmd.
Acked-by: Kirill A. Shutemov
Cc: Oleg Nesterov
Signed-off-by: Song Liu
---
include/linux/khugepaged.h | 12
mm/khugepaged.c| 123 -
2 files changed, 134 insertions(+), 1 deletion(-)
diff --git a/include/linux/khugepaged.h b/include/linux/khugepaged.h
index 082d1d2a5216..bc45ea1efbf7 100644
--- a/include/linux/khugepaged.h
+++ b/include/linux/khugepaged.h
@@ -15,6 +15,14 @@ extern int __khugepaged_enter(struct mm_struct *mm);
extern void __khugepaged_exit(struct mm_struct *mm);
extern int khugepaged_enter_vma_merge(struct vm_area_struct *vma,
unsigned long vm_flags);
+#ifdef CONFIG_SHMEM
+extern void collapse_pte_mapped_thp(struct mm_struct *mm, unsigned long addr);
+#else
+static inline void collapse_pte_mapped_thp(struct mm_struct *mm,
+ unsigned long addr)
+{
+}
+#endif
#define khugepaged_enabled() \
(transparent_hugepage_flags & \
@@ -73,6 +81,10 @@ static inline int khugepaged_enter_vma_merge(struct
vm_area_struct *vma,
{
return 0;
}
+static inline void collapse_pte_mapped_thp(struct mm_struct *mm,
+ unsigned long addr)
+{
+}
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
#endif /* _LINUX_KHUGEPAGED_H */
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index eaaa21b23215..ba36ff5c1d82 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -76,6 +76,8 @@ static __read_mostly DEFINE_HASHTABLE(mm_slots_hash,
MM_SLOTS_HASH_BITS);
static struct kmem_cache *mm_slot_cache __read_mostly;
+#define MAX_PTE_MAPPED_THP 8
+
/**
* struct mm_slot - hash lookup from mm to mm_slot
* @hash: hash collision list
@@ -86,6 +88,10 @@ struct mm_slot {
struct hlist_node hash;
struct list_head mm_node;
struct mm_struct *mm;
+
+ /* pte-mapped THP in this mm */
+ int nr_pte_mapped_thp;
+ unsigned long pte_mapped_thp[MAX_PTE_MAPPED_THP];
};
/**
@@ -1248,6 +1254,119 @@ static void collect_mm_slot(struct mm_slot *mm_slot)
}
#if defined(CONFIG_SHMEM) && defined(CONFIG_TRANSPARENT_HUGE_PAGECACHE)
+/*
+ * Notify khugepaged that given addr of the mm is pte-mapped THP. Then
+ * khugepaged should try to collapse the page table.
+ */
+static int khugepaged_add_pte_mapped_thp(struct mm_struct *mm,
+unsigned long addr)
+{
+ struct mm_slot *mm_slot;
+
+ VM_BUG_ON(addr & ~HPAGE_PMD_MASK);
+
+ spin_lock(_mm_lock);
+ mm_slot = get_mm_slot(mm);
+ if (likely(mm_slot && mm_slot->nr_pte_mapped_thp < MAX_PTE_MAPPED_THP))
+ mm_slot->pte_mapped_thp[mm_slot->nr_pte_mapped_thp++] = addr;
+ spin_unlock(_mm_lock);
+ return 0;
+}
+
+/**
+ * Try to collapse a pte-mapped THP for mm at address haddr.
+ *
+ * This function checks whether all the PTEs in the PMD are pointing to the
+ * right THP. If so, retract the page table so the THP can refault in with
+ * as pmd-mapped.
+ */
+void collapse_pte_mapped_thp(struct mm_struct *mm, unsigned long addr)
+{
+ unsigned long haddr = addr & HPAGE_PMD_MASK;
+ struct vm_area_struct *vma = find_vma(mm, haddr);
+ pmd_t *pmd = mm_find_pmd(mm, haddr);
+ struct page *hpage = NULL;
+ spinlock_t *ptl;
+ int count = 0;
+ pmd_t _pmd;
+ int i;
+
+ if (!vma || !vma->vm_file || !pmd ||
+ vma->vm_start > haddr || vma->vm_end < haddr + HPAGE_PMD_SIZE)
+ return;
+
+ /* step 1: check all mapped PTEs are to the right huge page */
+ for (i = 0, addr = haddr; i < HPAGE_PMD_NR; i++, addr += PAGE_SIZE) {
+ pte_t *pte = pte_offset_map(pmd, addr);
+ struct page *page;
+
+ if (pte_none(*pte))
+ continue;
+
+ page = vm_normal_page(vma, addr, *pte);
+
+ if (!page || !PageCompound(page))
[PATCH v4 2/2] uprobe: collapse THP pmd after removing all uprobes
After all uprobes are removed from the huge page (with PTE pgtable), it is possible to collapse the pmd and benefit from THP again. This patch does the collapse by calling collapse_pte_mapped_thp(). Acked-by: Kirill A. Shutemov Reported-by: kbuild test robot Signed-off-by: Song Liu --- kernel/events/uprobes.c | 9 + 1 file changed, 9 insertions(+) diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c index 27b596f14463..94d38a39d72e 100644 --- a/kernel/events/uprobes.c +++ b/kernel/events/uprobes.c @@ -26,6 +26,7 @@ #include #include #include +#include #include @@ -472,6 +473,7 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct *mm, struct page *old_page, *new_page; struct vm_area_struct *vma; int ret, is_register, ref_ctr_updated = 0; + bool orig_page_huge = false; is_register = is_swbp_insn(); uprobe = container_of(auprobe, struct uprobe, arch); @@ -529,6 +531,9 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct *mm, /* let go new_page */ put_page(new_page); new_page = NULL; + + if (PageCompound(orig_page)) + orig_page_huge = true; } put_page(orig_page); } @@ -547,6 +552,10 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct *mm, if (ret && is_register && ref_ctr_updated) update_ref_ctr(uprobe, mm, -1); + /* try collapse pmd for compound page */ + if (!ret && orig_page_huge) + collapse_pte_mapped_thp(mm, vaddr); + return ret; } -- 2.17.1
Re: [PATCH v3 0/6] mm / virtio: Provide support for unused page reporting
On Fri, 2019-08-02 at 10:28 -0700, Alexander Duyck wrote: > On Fri, 2019-08-02 at 12:19 -0400, Nitesh Narayan Lal wrote: > > On 8/2/19 11:13 AM, Alexander Duyck wrote: > > > On Fri, 2019-08-02 at 10:41 -0400, Nitesh Narayan Lal wrote: > > > > On 8/1/19 6:24 PM, Alexander Duyck wrote: > > > > > > > > > > One side effect of these patches is that the guest becomes much more > > > > > resilient in terms of NUMA locality. With the pages being freed and > > > > > then > > > > > reallocated when used it allows for the pages to be much closer to the > > > > > active thread, and as a result there can be situations where this > > > > > patch > > > > > set will out-perform the stock kernel when the guest memory is not > > > > > local > > > > > to the guest vCPUs. > > > > Was this the reason because of which you were seeing better results for > > > > page_fault1 earlier? > > > Yes I am thinking so. What I have found is that in the case where the > > > patches are not applied on the guest it takes a few runs for the numbers > > > to stabilize. What I think was going on is that I was running memhog to > > > initially fill the guest and that was placing all the pages on one node or > > > the other and as such was causing additional variability as the pages were > > > slowly being migrated over to the other node to rebalance the workload. > > > One way I tested it was by trying the unpatched case with a direct- > > > assigned device since that forces it to pin the memory. In that case I was > > > getting bad results consistently as all the memory was forced to come from > > > one node during the pre-allocation process. > > > > > > > I have also seen that the page_fault1 values take some time to get > > stabilize on > > an unmodified kernel. > > What I am wondering here is that if on a single NUMA guest doing the > > following > > will give the right/better idea or not: > > > > 1. Pin the guest to a single NUMA node. > > 2. Run memhog so that it touches all the guest memory. > > 3. Run will-it-scale/page_fault1. > > > > Compare/observe the values for the last core (this is considering the other > > core > > values doesn't drastically differ). > > I'll rerun the test with qemu affinitized to one specific socket. It will > cut the core/thread count down to 8/16 on my test system. Also I will try > with THP and page shuffling enabled. Okay so results with 8/16 all affinitized to one socket, THP enabled page_fault1, and shuffling enabled: With page reporting disabled in the hypervisor there wasn't much difference. I saw a range of 0.69% to -1.35% versus baseline, and an average of 0.16% improvement. So effectively no change. With page reporting enabled I saw a range of -2.10% to -4.50%, with an average of -3.05% regression. This is much closer to what I would expect for this patch set as the page faulting, double zeroing (once in host, and once in guest), and hinting process itself should have some overhead.
Re: [PATCH tip/core/rcu 1/1] rcu: Remove unused function hlist_bl_del_init_rcu
On Fri, Aug 02, 2019 at 01:37:58PM -0700, Ethan Hansen wrote:
> The function hlist_bl_del_init_rcu is declared in rculist_bl.h,
> but never used. Remove hlist_bl_del_init_rcu to clean code.
>
> Signed-off-by: Ethan Hansen <1ethanhan...@gmail.com>
Queued, thank you!
Thanx, Paul
> ---
> include/linux/rculist_bl.h | 28
> 1 file changed, 28 deletions(-)
>
> diff --git a/include/linux/rculist_bl.h b/include/linux/rculist_bl.h
> index 66e73ec..0b952d0 100644
> --- a/include/linux/rculist_bl.h
> +++ b/include/linux/rculist_bl.h
> @@ -25,34 +25,6 @@ static inline struct hlist_bl_node
> *hlist_bl_first_rcu(struct hlist_bl_head *h)
> }
>
> /**
> - * hlist_bl_del_init_rcu - deletes entry from hash list with
> re-initialization
> - * @n: the element to delete from the hash list.
> - *
> - * Note: hlist_bl_unhashed() on the node returns true after this. It is
> - * useful for RCU based read lockfree traversal if the writer side
> - * must know if the list entry is still hashed or already unhashed.
> - *
> - * In particular, it means that we can not poison the forward pointers
> - * that may still be used for walking the hash list and we can only
> - * zero the pprev pointer so list_unhashed() will return true after
> - * this.
> - *
> - * The caller must take whatever precautions are necessary (such as
> - * holding appropriate locks) to avoid racing with another
> - * list-mutation primitive, such as hlist_bl_add_head_rcu() or
> - * hlist_bl_del_rcu(), running on this same list. However, it is
> - * perfectly legal to run concurrently with the _rcu list-traversal
> - * primitives, such as hlist_bl_for_each_entry_rcu().
> - */
> -static inline void hlist_bl_del_init_rcu(struct hlist_bl_node *n)
> -{
> - if (!hlist_bl_unhashed(n)) {
> - __hlist_bl_del(n);
> - n->pprev = NULL;
> - }
> -}
> -
> -/**
> * hlist_bl_del_rcu - deletes entry from hash list without re-initialization
> * @n: the element to delete from the hash list.
> *
> --
> 1.8.3.1
>
Re: [PATCH v2 03/10] locking/locktorture: Replace strncmp with str_has_prefix
On Fri, Aug 02, 2019 at 09:46:56AM +0800, Chuhong Yuan wrote: > strncmp(str, const, len) is error-prone because len > is easy to have typo. > The example is the hard-coded len has counting error > or sizeof(const) forgets - 1. > So we prefer using newly introduced str_has_prefix > to substitute such strncmp. > > Signed-off-by: Chuhong Yuan Queued, thank you! I updated the commit log as follows. Please let me know if I messed anything up. Thanx, Paul commit e2be525371b2f6790f6c1ab712c3d273fb1f2bea Author: Chuhong Yuan Date: Fri Aug 2 09:46:56 2019 +0800 locktorture: Replace strncmp() with str_has_prefix() The strncmp() function is error-prone because it is easy to get the length wrong, especially if the string is subject to change, especially given the need to account for the terminating nul byte. This commit therefore substitutes the newly introduced str_has_prefix(), which does not require a separately specified length. Signed-off-by: Chuhong Yuan Signed-off-by: Paul E. McKenney diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c index c513031cd7e3..8dd900247205 100644 --- a/kernel/locking/locktorture.c +++ b/kernel/locking/locktorture.c @@ -889,16 +889,16 @@ static int __init lock_torture_init(void) cxt.nrealwriters_stress = 2 * num_online_cpus(); #ifdef CONFIG_DEBUG_MUTEXES - if (strncmp(torture_type, "mutex", 5) == 0) + if (str_has_prefix(torture_type, "mutex")) cxt.debug_lock = true; #endif #ifdef CONFIG_DEBUG_RT_MUTEXES - if (strncmp(torture_type, "rtmutex", 7) == 0) + if (str_has_prefix(torture_type, "rtmutex")) cxt.debug_lock = true; #endif #ifdef CONFIG_DEBUG_SPINLOCK - if ((strncmp(torture_type, "spin", 4) == 0) || - (strncmp(torture_type, "rw_lock", 7) == 0)) + if ((str_has_prefix(torture_type, "spin")) || + (str_has_prefix(torture_type, "rw_lock"))) cxt.debug_lock = true; #endif
Re: [PATCH v2] KVM: x86: Unconditionally call x86 ops that are always implemented
On Fri, Aug 02, 2019 at 03:48:27PM -0700, Krish Sadhukhan wrote:
>
> On 08/02/2019 03:06 PM, Sean Christopherson wrote:
> >Remove a few stale checks for non-NULL ops now that the ops in question
> >are implemented by both VMX and SVM.
> >
> >Note, this is **not** stable material, the Fixes tags are there purely
> >to show when a particular op was first supported by both VMX and SVM.
> >
> >Fixes: 74f169090b6f ("kvm/svm: Setup MCG_CAP on AMD properly")
> >Fixes: b31c114b82b2 ("KVM: X86: Provide a capability to disable PAUSE
> >intercepts")
> >Fixes: 411b44ba80ab ("svm: Implements update_pi_irte hook to setup posted
> >interrupt")
> >Cc: Krish Sadhukhan
> >Signed-off-by: Sean Christopherson
> >---
> >
> >v2: Give update_pi_iret the same treatment [Krish].
> >
> > arch/x86/kvm/x86.c | 13 +++--
> > 1 file changed, 3 insertions(+), 10 deletions(-)
> >
> >diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> >index 01e18caac825..e7c993f0cbed 100644
> >--- a/arch/x86/kvm/x86.c
> >+++ b/arch/x86/kvm/x86.c
> >@@ -3506,8 +3506,7 @@ static int kvm_vcpu_ioctl_x86_setup_mce(struct
> >kvm_vcpu *vcpu,
> > for (bank = 0; bank < bank_num; bank++)
> > vcpu->arch.mce_banks[bank*4] = ~(u64)0;
> >-if (kvm_x86_ops->setup_mce)
> >-kvm_x86_ops->setup_mce(vcpu);
> >+kvm_x86_ops->setup_mce(vcpu);
> > out:
> > return r;
> > }
> >@@ -9313,10 +9312,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long
> >type)
> > kvm_page_track_init(kvm);
> > kvm_mmu_init_vm(kvm);
> >-if (kvm_x86_ops->vm_init)
> >-return kvm_x86_ops->vm_init(kvm);
> >-
> >-return 0;
> >+return kvm_x86_ops->vm_init(kvm);
> > }
> > static void kvm_unload_vcpu_mmu(struct kvm_vcpu *vcpu)
> >@@ -9992,7 +9988,7 @@ EXPORT_SYMBOL_GPL(kvm_arch_has_noncoherent_dma);
> > bool kvm_arch_has_irq_bypass(void)
>
> Now that this is returning true always and that this is called only in
> kvm_irqfd_assign(), this can perhaps be removed altogether ?
No go, PowerPC has a conditional implementation.
Re: [PATCH v2 1/6] hwrng: core: Freeze khwrng thread during suspend
Quoting Stephen Boyd (2019-07-17 10:03:22) > Quoting Jason Gunthorpe (2019-07-17 09:50:11) > > On Wed, Jul 17, 2019 at 09:42:32AM -0700, Stephen Boyd wrote: > > Yes. That's exactly my point. A hwrng that's suspended will fail here > and it's better to just not try until it's guaranteed to have resumed. > > > > > It just seems weird to do this, what about all the other tpm API > > users? Do they have a racy problem with suspend too? > > I haven't looked at them. Are they being called from suspend/resume > paths? I don't think anything for the userspace API can be a problem > because those tasks are all frozen. The only problem would be some > kernel internal API that TPM API exposes. I did a quick grep and I see > things like IMA or the trusted keys APIs that might need a closer look. > > Either way, trying to hold off a TPM operation from the TPM API when > we're suspended isn't really possible. If something like IMA needs to > get TPM data from deep suspend path and it fails because the device is > suspended, all we can do is return an error from TPM APIs and hope the > caller can recover. The fix is probably going to be to change the code > to not call into the TPM API until the hardware has resumed by avoiding > doing anything with the TPM until resume is over. So we're at best able > to make same sort of band-aid here in the TPM API where all we can do is > say -EAGAIN but we can't tell the caller when to try again. > Andrey talked to me a little about this today. Andrey would prefer we don't just let the TPM go into a wonky state if it's used during suspend/resume so that it can stay resilient to errors. Sounds OK to me, but my point still stands that we need to fix the callers. I'll resurrect the IS_SUSPENDED flag and make it set generically by the tpm_pm_suspend() and tpm_pm_resume() functions and then spit out a big WARN_ON() and return an error value like -EAGAIN if the TPM functions are called when the TPM is suspended. I hope we don't hit the warning message, but if we do then at least we can track it down rather quickly and figure out how to fix the caller instead of just silently returning -EAGAIN and hoping for that to be visible to the user. This patch will still be required to avoid the WARN message, so I'll resend with the Cc to crypto list so it can be picked up.
Re: [PATCH] KVM: x86: Unconditionally call x86 ops that are always implemented
On Thu, Aug 01, 2019 at 02:42:07PM -0700, Sean Christopherson wrote:
> On Thu, Aug 01, 2019 at 02:39:38PM -0700, Krish Sadhukhan wrote:
> >
> >
> > On 08/01/2019 09:46 AM, Sean Christopherson wrote:
> > >Remove two stale checks for non-NULL ops now that they're implemented by
> > >both VMX and SVM.
> > >
> > >Fixes: 74f169090b6f ("kvm/svm: Setup MCG_CAP on AMD properly")
> > >Fixes: b31c114b82b2 ("KVM: X86: Provide a capability to disable PAUSE
> > >intercepts")
> > >Signed-off-by: Sean Christopherson
> > >---
> > > arch/x86/kvm/x86.c | 8 ++--
> > > 1 file changed, 2 insertions(+), 6 deletions(-)
> > >
> > >diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > >index 01e18caac825..2c25a19d436f 100644
> > >--- a/arch/x86/kvm/x86.c
> > >+++ b/arch/x86/kvm/x86.c
> > >@@ -3506,8 +3506,7 @@ static int kvm_vcpu_ioctl_x86_setup_mce(struct
> > >kvm_vcpu *vcpu,
> > > for (bank = 0; bank < bank_num; bank++)
> > > vcpu->arch.mce_banks[bank*4] = ~(u64)0;
> > >- if (kvm_x86_ops->setup_mce)
> > >- kvm_x86_ops->setup_mce(vcpu);
> > >+ kvm_x86_ops->setup_mce(vcpu);
> > > out:
> > > return r;
> > > }
> > >@@ -9313,10 +9312,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long
> > >type)
> > > kvm_page_track_init(kvm);
> > > kvm_mmu_init_vm(kvm);
> > >- if (kvm_x86_ops->vm_init)
> > >- return kvm_x86_ops->vm_init(kvm);
> > >-
> > >- return 0;
> > >+ return kvm_x86_ops->vm_init(kvm);
> > > }
> > > static void kvm_unload_vcpu_mmu(struct kvm_vcpu *vcpu)
> >
> > The following two ops are also implemented by both VMX and SVM:
> >
> > update_cr8_intercept
> > update_pi_irte
>
> Drat, I didn't think to grep for !kvm_x86_ops. I'll spin a v2. Thanks!
Ah, but update_cr8_intercept is zapped by VMX if hardware doesn't support
the TPR shadow.
P.S. I meant to send this before posting v2, but I got distracted...
Re: [PATCH v2] KVM: x86: Unconditionally call x86 ops that are always implemented
On 08/02/2019 03:06 PM, Sean Christopherson wrote:
Remove a few stale checks for non-NULL ops now that the ops in question
are implemented by both VMX and SVM.
Note, this is **not** stable material, the Fixes tags are there purely
to show when a particular op was first supported by both VMX and SVM.
Fixes: 74f169090b6f ("kvm/svm: Setup MCG_CAP on AMD properly")
Fixes: b31c114b82b2 ("KVM: X86: Provide a capability to disable PAUSE
intercepts")
Fixes: 411b44ba80ab ("svm: Implements update_pi_irte hook to setup posted
interrupt")
Cc: Krish Sadhukhan
Signed-off-by: Sean Christopherson
---
v2: Give update_pi_iret the same treatment [Krish].
arch/x86/kvm/x86.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 01e18caac825..e7c993f0cbed 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3506,8 +3506,7 @@ static int kvm_vcpu_ioctl_x86_setup_mce(struct kvm_vcpu
*vcpu,
for (bank = 0; bank < bank_num; bank++)
vcpu->arch.mce_banks[bank*4] = ~(u64)0;
- if (kvm_x86_ops->setup_mce)
- kvm_x86_ops->setup_mce(vcpu);
+ kvm_x86_ops->setup_mce(vcpu);
out:
return r;
}
@@ -9313,10 +9312,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
kvm_page_track_init(kvm);
kvm_mmu_init_vm(kvm);
- if (kvm_x86_ops->vm_init)
- return kvm_x86_ops->vm_init(kvm);
-
- return 0;
+ return kvm_x86_ops->vm_init(kvm);
}
static void kvm_unload_vcpu_mmu(struct kvm_vcpu *vcpu)
@@ -9992,7 +9988,7 @@ EXPORT_SYMBOL_GPL(kvm_arch_has_noncoherent_dma);
bool kvm_arch_has_irq_bypass(void)
Now that this is returning true always and that this is called only in
kvm_irqfd_assign(), this can perhaps be removed altogether ?
{
- return kvm_x86_ops->update_pi_irte != NULL;
+ return true;
}
int kvm_arch_irq_bypass_add_producer(struct irq_bypass_consumer *cons,
@@ -10032,9 +10028,6 @@ void kvm_arch_irq_bypass_del_producer(struct
irq_bypass_consumer *cons,
int kvm_arch_update_irqfd_routing(struct kvm *kvm, unsigned int host_irq,
uint32_t guest_irq, bool set)
{
- if (!kvm_x86_ops->update_pi_irte)
- return -EINVAL;
-
return kvm_x86_ops->update_pi_irte(kvm, host_irq, guest_irq, set);
}
Reviewed-by: Krish Sadhukhan
[PATCH 0/3] address hugetlb page allocation stalls
Allocation of hugetlb pages via sysctl or procfs can stall for minutes or hours. A simple example on a two node system with 8GB of memory is as follows: echo 4096 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages echo 4096 > /proc/sys/vm/nr_hugepages Obviously, both allocation attempts will fall short of their 8GB goal. However, one or both of these commands may stall and not be interruptible. The issues were initially discussed in mail thread [1] and RFC code at [2]. This series addresses the issues causing the stalls. There are two distinct fixes, and an optimization. The reclaim patch by Hillf and compaction patch by Vlasitmil address corner cases in their respective areas. hugetlb page allocation could stall due to either of these issues. The hugetlb patch by Mike is an optimization suggested during the debug and development process. [1] http://lkml.kernel.org/r/d38a095e-dc39-7e82-bb76-2c9247929...@oracle.com [2] http://lkml.kernel.org/r/20190724175014.9935-1-mike.krav...@oracle.com Hillf Danton (1): mm, reclaim: make should_continue_reclaim perform dryrun detection Mike Kravetz (1): hugetlbfs: don't retry when pool page allocations start to fail Vlastimil Babka (1): mm, compaction: raise compaction priority after it withdrawns include/linux/compaction.h | 22 +++--- mm/hugetlb.c | 86 +- mm/page_alloc.c| 16 +-- mm/vmscan.c| 28 +++-- 4 files changed, 120 insertions(+), 32 deletions(-) -- 2.20.1
[PATCH 1/3] mm, reclaim: make should_continue_reclaim perform dryrun detection
From: Hillf Danton
Address the issue of should_continue_reclaim continuing true too often
for __GFP_RETRY_MAYFAIL attempts when !nr_reclaimed and nr_scanned.
This could happen during hugetlb page allocation causing stalls for
minutes or hours.
We can stop reclaiming pages if compaction reports it can make a progress.
A code reshuffle is needed to do that. And it has side-effects, however,
with allocation latencies in other cases but that would come at the cost
of potential premature reclaim which has consequences of itself.
We can also bail out of reclaiming pages if we know that there are not
enough inactive lru pages left to satisfy the costly allocation.
We can give up reclaiming pages too if we see dryrun occur, with the
certainty of plenty of inactive pages. IOW with dryrun detected, we are
sure we have reclaimed as many pages as we could.
Cc: Mike Kravetz
Cc: Mel Gorman
Cc: Michal Hocko
Cc: Vlastimil Babka
Cc: Johannes Weiner
Signed-off-by: Hillf Danton
Tested-by: Mike Kravetz
Acked-by: Mel Gorman
---
mm/vmscan.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 47aa2158cfac..a386c5351592 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2738,18 +2738,6 @@ static inline bool should_continue_reclaim(struct
pglist_data *pgdat,
return false;
}
- /*
-* If we have not reclaimed enough pages for compaction and the
-* inactive lists are large enough, continue reclaiming
-*/
- pages_for_compaction = compact_gap(sc->order);
- inactive_lru_pages = node_page_state(pgdat, NR_INACTIVE_FILE);
- if (get_nr_swap_pages() > 0)
- inactive_lru_pages += node_page_state(pgdat, NR_INACTIVE_ANON);
- if (sc->nr_reclaimed < pages_for_compaction &&
- inactive_lru_pages > pages_for_compaction)
- return true;
-
/* If compaction would go ahead or the allocation would succeed, stop */
for (z = 0; z <= sc->reclaim_idx; z++) {
struct zone *zone = >node_zones[z];
@@ -2765,7 +2753,21 @@ static inline bool should_continue_reclaim(struct
pglist_data *pgdat,
;
}
}
- return true;
+
+ /*
+* If we have not reclaimed enough pages for compaction and the
+* inactive lists are large enough, continue reclaiming
+*/
+ pages_for_compaction = compact_gap(sc->order);
+ inactive_lru_pages = node_page_state(pgdat, NR_INACTIVE_FILE);
+ if (get_nr_swap_pages() > 0)
+ inactive_lru_pages += node_page_state(pgdat, NR_INACTIVE_ANON);
+
+ return inactive_lru_pages > pages_for_compaction &&
+ /*
+* avoid dryrun with plenty of inactive pages
+*/
+ nr_scanned && nr_reclaimed;
}
static bool pgdat_memcg_congested(pg_data_t *pgdat, struct mem_cgroup *memcg)
--
2.20.1
[PATCH 3/3] hugetlbfs: don't retry when pool page allocations start to fail
When allocating hugetlbfs pool pages via /proc/sys/vm/nr_hugepages,
the pages will be interleaved between all nodes of the system. If
nodes are not equal, it is quite possible for one node to fill up
before the others. When this happens, the code still attempts to
allocate pages from the full node. This results in calls to direct
reclaim and compaction which slow things down considerably.
When allocating pool pages, note the state of the previous allocation
for each node. If previous allocation failed, do not use the
aggressive retry algorithm on successive attempts. The allocation
will still succeed if there is memory available, but it will not try
as hard to free up memory.
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 86 ++--
1 file changed, 76 insertions(+), 10 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index ede7e7f5d1ab..c707207e208f 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1405,12 +1405,25 @@ pgoff_t __basepage_index(struct page *page)
}
static struct page *alloc_buddy_huge_page(struct hstate *h,
- gfp_t gfp_mask, int nid, nodemask_t *nmask)
+ gfp_t gfp_mask, int nid, nodemask_t *nmask,
+ nodemask_t *node_alloc_noretry)
{
int order = huge_page_order(h);
struct page *page;
+ bool alloc_try_hard = true;
- gfp_mask |= __GFP_COMP|__GFP_RETRY_MAYFAIL|__GFP_NOWARN;
+ /*
+* By default we always try hard to allocate the page with
+* __GFP_RETRY_MAYFAIL flag. However, if we are allocating pages in
+* a loop (to adjust global huge page counts) and previous allocation
+* failed, do not continue to try hard on the same node. Use the
+* node_alloc_noretry bitmap to manage this state information.
+*/
+ if (node_alloc_noretry && node_isset(nid, *node_alloc_noretry))
+ alloc_try_hard = false;
+ gfp_mask |= __GFP_COMP|__GFP_NOWARN;
+ if (alloc_try_hard)
+ gfp_mask |= __GFP_RETRY_MAYFAIL;
if (nid == NUMA_NO_NODE)
nid = numa_mem_id();
page = __alloc_pages_nodemask(gfp_mask, order, nid, nmask);
@@ -1419,6 +1432,22 @@ static struct page *alloc_buddy_huge_page(struct hstate
*h,
else
__count_vm_event(HTLB_BUDDY_PGALLOC_FAIL);
+ /*
+* If we did not specify __GFP_RETRY_MAYFAIL, but still got a page this
+* indicates an overall state change. Clear bit so that we resume
+* normal 'try hard' allocations.
+*/
+ if (node_alloc_noretry && page && !alloc_try_hard)
+ node_clear(nid, *node_alloc_noretry);
+
+ /*
+* If we tried hard to get a page but failed, set bit so that
+* subsequent attempts will not try as hard until there is an
+* overall state change.
+*/
+ if (node_alloc_noretry && !page && alloc_try_hard)
+ node_set(nid, *node_alloc_noretry);
+
return page;
}
@@ -1427,7 +1456,8 @@ static struct page *alloc_buddy_huge_page(struct hstate
*h,
* should use this function to get new hugetlb pages
*/
static struct page *alloc_fresh_huge_page(struct hstate *h,
- gfp_t gfp_mask, int nid, nodemask_t *nmask)
+ gfp_t gfp_mask, int nid, nodemask_t *nmask,
+ nodemask_t *node_alloc_noretry)
{
struct page *page;
@@ -1435,7 +1465,7 @@ static struct page *alloc_fresh_huge_page(struct hstate
*h,
page = alloc_gigantic_page(h, gfp_mask, nid, nmask);
else
page = alloc_buddy_huge_page(h, gfp_mask,
- nid, nmask);
+ nid, nmask, node_alloc_noretry);
if (!page)
return NULL;
@@ -1450,14 +1480,16 @@ static struct page *alloc_fresh_huge_page(struct hstate
*h,
* Allocates a fresh page to the hugetlb allocator pool in the node interleaved
* manner.
*/
-static int alloc_pool_huge_page(struct hstate *h, nodemask_t *nodes_allowed)
+static int alloc_pool_huge_page(struct hstate *h, nodemask_t *nodes_allowed,
+ nodemask_t *node_alloc_noretry)
{
struct page *page;
int nr_nodes, node;
gfp_t gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE;
for_each_node_mask_to_alloc(h, nr_nodes, node, nodes_allowed) {
- page = alloc_fresh_huge_page(h, gfp_mask, node, nodes_allowed);
+ page = alloc_fresh_huge_page(h, gfp_mask, node, nodes_allowed,
+ node_alloc_noretry);
if (page)
break;
}
@@ -1601,7 +1633,7 @@ static struct page *alloc_surplus_huge_page(struct hstate
*h, gfp_t gfp_mask,
goto out_unlock;
spin_unlock(_lock);
- page = alloc_fresh_huge_page(h, gfp_mask, nid, nmask);
+ page = alloc_fresh_huge_page(h, gfp_mask, nid,
[PATCH 2/3] mm, compaction: raise compaction priority after it withdrawns
From: Vlastimil Babka
Mike Kravetz reports that "hugetlb allocations could stall for minutes or hours
when should_compact_retry() would return true more often then it should.
Specifically, this was in the case where compact_result was COMPACT_DEFERRED
and COMPACT_PARTIAL_SKIPPED and no progress was being made."
The problem is that the compaction_withdrawn() test in should_compact_retry()
includes compaction outcomes that are only possible on low compaction priority,
and results in a retry without increasing the priority. This may result in
furter reclaim, and more incomplete compaction attempts.
With this patch, compaction priority is raised when possible, or
should_compact_retry() returns false.
The COMPACT_SKIPPED result doesn't really fit together with the other outcomes
in compaction_withdrawn(), as that's a result caused by insufficient order-0
pages, not due to low compaction priority. With this patch, it is moved to
a new compaction_needs_reclaim() function, and for that outcome we keep the
current logic of retrying if it looks like reclaim will be able to help.
Reported-by: Mike Kravetz
Signed-off-by: Vlastimil Babka
Tested-by: Mike Kravetz
---
include/linux/compaction.h | 22 +-
mm/page_alloc.c| 16
2 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index 9569e7c786d3..4b898cdbdf05 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -129,11 +129,8 @@ static inline bool compaction_failed(enum compact_result
result)
return false;
}
-/*
- * Compaction has backed off for some reason. It might be throttling or
- * lock contention. Retrying is still worthwhile.
- */
-static inline bool compaction_withdrawn(enum compact_result result)
+/* Compaction needs reclaim to be performed first, so it can continue. */
+static inline bool compaction_needs_reclaim(enum compact_result result)
{
/*
* Compaction backed off due to watermark checks for order-0
@@ -142,6 +139,16 @@ static inline bool compaction_withdrawn(enum
compact_result result)
if (result == COMPACT_SKIPPED)
return true;
+ return false;
+}
+
+/*
+ * Compaction has backed off for some reason after doing some work or none
+ * at all. It might be throttling or lock contention. Retrying might be still
+ * worthwhile, but with a higher priority if allowed.
+ */
+static inline bool compaction_withdrawn(enum compact_result result)
+{
/*
* If compaction is deferred for high-order allocations, it is
* because sync compaction recently failed. If this is the case
@@ -207,6 +214,11 @@ static inline bool compaction_failed(enum compact_result
result)
return false;
}
+static inline bool compaction_needs_reclaim(enum compact_result result)
+{
+ return false;
+}
+
static inline bool compaction_withdrawn(enum compact_result result)
{
return true;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d3bb601c461b..af29c05e23aa 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3965,15 +3965,23 @@ should_compact_retry(struct alloc_context *ac, int
order, int alloc_flags,
if (compaction_failed(compact_result))
goto check_priority;
+ /*
+* compaction was skipped because there are not enough order-0 pages
+* to work with, so we retry only if it looks like reclaim can help.
+*/
+ if (compaction_needs_reclaim(compact_result)) {
+ ret = compaction_zonelist_suitable(ac, order, alloc_flags);
+ goto out;
+ }
+
/*
* make sure the compaction wasn't deferred or didn't bail out early
* due to locks contention before we declare that we should give up.
-* But do not retry if the given zonelist is not suitable for
-* compaction.
+* But the next retry should use a higher priority if allowed, so
+* we don't just keep bailing out endlessly.
*/
if (compaction_withdrawn(compact_result)) {
- ret = compaction_zonelist_suitable(ac, order, alloc_flags);
- goto out;
+ goto check_priority;
}
/*
--
2.20.1
Re: [patch 2/5] x86/kvm: Handle task_work on VMENTER/EXIT
> On Aug 2, 2019, at 3:22 PM, Thomas Gleixner wrote:
>
>> On Fri, 2 Aug 2019, Paolo Bonzini wrote:
>>> On 01/08/19 23:47, Thomas Gleixner wrote:
>>> Right you are about cond_resched() being called, but for SRCU this does not
>>> matter unless there is some way to do a synchronize operation on that SRCU
>>> entity. It might have some other performance side effect though.
>>
>> I would use srcu_read_unlock/lock around the call.
>>
>> However, I'm wondering if the API can be improved because basically we
>> have six functions for three checks of TIF flags. Does it make sense to
>> have something like task_has_request_flags and task_do_requests (names
>> are horrible I know) that can be used like
>>
>>if (task_has_request_flags()) {
>>int err;
>>...srcu_read_unlock...
>>// return -EINTR if signal_pending
>>err = task_do_requests();
>>if (err < 0)
>>goto exit_no_srcu_read_unlock;
>>...srcu_read_lock...
>>}
>>
>> taking care of all three cases with a single hook? This is important
>> especially because all these checks are done by all KVM architectures in
>> slightly different ways, and a unified API would be a good reason to
>> make all architectures look the same.
>>
>> (Of course I could also define this unified API in virt/kvm/kvm_main.c,
>> so this is not blocking the series in any way!).
>
> You're not holding up something. Having a common function for this is
> definitely the right approach.
>
> As this is virt specific because it only checks for non arch specific bits
> (TIF_NOTIFY_RESUME should be available for all KVM archs) and the TIF bits
> are a subset of the available TIF bits because all others do not make any
> sense there, this really should be a common function for KVM so that all
> other archs which obviously lack a TIF_NOTIFY_RESUME check, can be fixed up
> and consolidated. If we add another TIF check later then we only have to do
> it in one place.
>
>
If we add a real API for this, can we make it, or a very similar API, work for
exit_to_usermode_loop() too? Maybe:
bool usermode_work_pending();
bool guestmode_work_pending();
void do_usermode_work();
void do_guestmode_work();
The first two are called with IRQs off. The latter two are called with IRQs on.
Re: [Regression] Commit "ACPI: PM: Allow transitions to D0 to occur in special cases"
On Thu, Aug 01, 2019 at 12:26:51AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 31, 2019 11:30:01 PM CEST Bjorn Helgaas wrote:
> > [+cc Thunderbolt folks, see
> > https://lore.kernel.org/r/578bd3f1-b185-471b-a3eb-ff71ba34b...@canonical.com
> > for beginning of thread]
> >
> > On Thu, Aug 01, 2019 at 12:04:29AM +0800, Kai-Heng Feng wrote:
> > > Hi,
> > >
> > > After commit "ACPI: PM: Allow transitions to D0 to occur in special
> > > cases”,
> >
> > This is f850a48a0799 ("ACPI: PM: Allow transitions to D0 to occur in
> > special cases").
> >
> > > Thunderbolt on XPS 9380 spews the following when it runtime resumes:
> > > [ 36.136554] pci_raw_set_power_state: 25 callbacks suppressed
> > > [ 36.136558] pcieport :03:00.0: Refused to change power state,
> > > currently in D3
> >
> > We really should be smarter about what we print here, maybe something
> > like the patch below?
> >
> > pci_raw_set_power_state() prints "Refused to change power state" if
> > (in this case) the value of (PCI_PM_CTRL & PCI_PM_CTRL_STATE_MASK) is
> > 0x3. Most likely we got 0x from PCI_PM_CTRL because the device is
> > in D3cold. If the device is in D3cold, pci_raw_set_power_state() has
> > no hope of doing anything because it only uses PCI PM config
> > registers, and they're inaccessible in D3cold.
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index 29ed5ec1ac27..63ca963ebff9 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -851,6 +852,11 @@ static int pci_raw_set_power_state(struct pci_dev
> > *dev, pci_power_t state)
> > return -EIO;
> >
> > pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, );
> > + if (pmcsr == (u16) ~0) {
>
> Is the "device not accessible" the only case in which we can get all ones
> from this?
>
> If so, the change will be fine by me.
There are several RsvdP bits in that register, so it's not possible to
read all ones except in error cases. I'll finish up a patch for it.
Bjorn
Re: [PATCH v2] ARM: dts: rockchip: A few fixes for veyron-{fievel,tiger}
Am Mittwoch, 31. Juli 2019, 17:15:27 CEST schrieb Matthias Kaehlcke:
> Fix/improve a few things for veyron fievel/tiger:
>
> - move 'vccsys' regulator from tiger to fievel, both boards
> have it (and tiger includes the fievel .dtsi)
> - move 'ext_gmac' node below regulators
> - fix GPIO ids of vcc5_host1 and vcc5_host2 regulators
> - remove reset configuration from 'gmac' node, this is already done
> in rk3288.dtsi
> - fixed style issues of some multi-line comments
> - switch 'vcc18_lcdt', 'vdd10_lcd' and 'vcc33_ccd' regulators off
> during suspend
> - no pull-up on the Bluetooth wake-up pin, there is an external
> pull-up. The signal is active low, add the 'bt_host_wake_l'
> pinctrl config
> - move BC 1.2 pins up in the pinctrl config to keep 'wake only' pins
> separate
> - add BC 1.2 pins to sleep config
>
> Fixes: 0067692b662e ("ARM: dts: rockchip: add veyron-fievel board")
> Reviewed-by: Douglas Anderson
> Signed-off-by: Matthias Kaehlcke
applied for 5.4
Thanks
Heiko
Re: [PATCH] ARM: dts: rockchip: Add pin names for rk3288-veyron fievel
Am Freitag, 2. August 2019, 00:03:54 CEST schrieb Matthias Kaehlcke:
> This is like commit 0ca87bd5baa6 ("ARM: dts: rockchip: Add pin names
> for rk3288-veyron-jerry") and other similar commits, but for the
> veyron fievel board (and tiger, which includes the fievel .dtsi).
>
> Signed-off-by: Matthias Kaehlcke
applied for 5.4
Thanks
Heiko
Re: [PATCH v2 5/6] tpm: add driver for cr50 on SPI
Quoting Jarkko Sakkinen (2019-08-02 13:43:18) > On Thu, Jul 18, 2019 at 06:47:14PM +0200, Alexander Steffen wrote: > > On 17.07.2019 21:57, Stephen Boyd wrote: > > > Quoting Alexander Steffen (2019-07-17 05:00:06) > > > > On 17.07.2019 00:45, Stephen Boyd wrote: > > > > > From: Andrey Pronin > > > > > > > > > > +static unsigned short rng_quality = 1022; > > > > > +module_param(rng_quality, ushort, 0644); > > > > > +MODULE_PARM_DESC(rng_quality, > > > > > + "Estimation of true entropy, in bits per 1024 bits."); > > > > > > > > What is the purpose of this parameter? None of the other TPM drivers > > > > have it. > > > > > > I think the idea is to let users override the quality if they decide > > > that they don't want to use the default value specified in the driver. > > > > But isn't this something that applies to all TPMs, not only cr50? So > > shouldn't this parameter be added to one of the global modules (tpm? > > tpm_tis_core?) instead? Or do all low-level drivers (tpm_tis, tpm_tis_spi, > > ...) need this parameter to provide a consistent interface for the user? > > This definitely something that is out of context of the patch set and > thus must be removed from the patch set. Ok. I've dropped this part of the patch.
Re: [PATCH] dt-bindings: pinctrl: stm32: Fix missing 'clocks' property in examples
On Tue, Jul 16, 2019 at 11:56 PM Rob Herring wrote:
> Now that examples are validated against the DT schema, an error with
> required 'clocks' property missing is exposed:
>
> Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.example.dt.yaml: \
> pinctrl@4002: gpio@0: 'clocks' is a required property
> Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.example.dt.yaml: \
> pinctrl@5002: gpio@1000: 'clocks' is a required property
> Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.example.dt.yaml: \
> pinctrl@5002: gpio@2000: 'clocks' is a required property
>
> Add the missing 'clocks' properties to the examples to fix the errors.
>
> Fixes: 2c9239c125f0 ("dt-bindings: pinctrl: Convert stm32 pinctrl bindings to
> json-schema")
> Cc: Linus Walleij
> Cc: Maxime Coquelin
> Cc: Alexandre Torgue
> Cc: linux-g...@vger.kernel.org
> Cc: linux-st...@st-md-mailman.stormreply.com
> Signed-off-by: Rob Herring
This seems to already be upstream, but I have no memory of applying it.
Less work for me :)
Yours,
Linus Walleij
Re: [PATCH] firmware: google: update vpd_decode from upstream
Quoting Hung-Te Lin (2019-08-02 01:20:31)
> The VPD implementation from Chromium Vital Product Data project has been
> updated so vpd_decode be easily shared by kernel, firmware and the user
> space utility programs. Also improved value range checks to prevent
> kernel crash due to bad VPD data.
Please add a Fixes: tag here to fix the commit that introduces the
problem. It would also be nice to get a description of the problem that
this patch is fixing. For example, explaining why the types change from
signed to unsigned.
>
> Signed-off-by: Hung-Te Lin
> ---
> drivers/firmware/google/vpd.c| 38 +--
> drivers/firmware/google/vpd_decode.c | 69 +++-
> drivers/firmware/google/vpd_decode.h | 17 ---
> 3 files changed, 71 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/firmware/google/vpd.c b/drivers/firmware/google/vpd.c
> index 0739f3b70347..ecf217a7db39 100644
> --- a/drivers/firmware/google/vpd.c
> +++ b/drivers/firmware/google/vpd.c
> @@ -73,7 +73,7 @@ static ssize_t vpd_attrib_read(struct file *filp, struct
> kobject *kobp,
> * exporting them as sysfs attributes. These keys present in old firmwares
> are
> * ignored.
> *
> - * Returns VPD_OK for a valid key name, VPD_FAIL otherwise.
> + * Returns VPD_DECODE_OK for a valid key name, VPD_DECODE_FAIL otherwise.
Maybe we should convert these things to use linux conventions instead of
VPD error codes?
> *
> * @key: The key name to check
> * @key_len: key name length
> @@ -86,14 +86,14 @@ static int vpd_section_check_key_name(const u8 *key, s32
> key_len)
> c = *key++;
>
> if (!isalnum(c) && c != '_')
> - return VPD_FAIL;
> + return VPD_DECODE_FAIL;
> }
>
> - return VPD_OK;
> + return VPD_DECODE_OK;
Can you split this rename out into it's own patch. That way we can
confirm that there are no changes due to the rename of the enum.
> }
>
> -static int vpd_section_attrib_add(const u8 *key, s32 key_len,
> - const u8 *value, s32 value_len,
> +static int vpd_section_attrib_add(const u8 *key, u32 key_len,
> + const u8 *value, u32 value_len,
> void *arg)
> {
> int ret;
> @@ -246,7 +246,7 @@ static int vpd_section_destroy(struct vpd_section *sec)
>
> static int vpd_sections_init(phys_addr_t physaddr)
> {
> - struct vpd_cbmem *temp;
> + struct vpd_cbmem __iomem *temp;
> struct vpd_cbmem header;
> int ret = 0;
>
> @@ -254,7 +254,7 @@ static int vpd_sections_init(phys_addr_t physaddr)
> if (!temp)
> return -ENOMEM;
>
> - memcpy(, temp, sizeof(struct vpd_cbmem));
> + memcpy_fromio(, temp, sizeof(struct vpd_cbmem));
> memunmap(temp);
>
> if (header.magic != VPD_CBMEM_MAGIC)
> @@ -316,7 +316,19 @@ static struct coreboot_driver vpd_driver = {
> },
> .tag = CB_TAG_VPD,
> };
> -module_coreboot_driver(vpd_driver);
> +
> +static int __init coreboot_vpd_init(void)
> +{
> + return coreboot_driver_register(_driver);
> +}
> +
> +static void __exit coreboot_vpd_exit(void)
> +{
> + coreboot_driver_unregister(_driver);
> +}
> +
> +module_init(coreboot_vpd_init);
> +module_exit(coreboot_vpd_exit);
>
> MODULE_AUTHOR("Google, Inc.");
> MODULE_LICENSE("GPL");
The above three hunks should be dropped. They're undoing other patches
that have gone upstream.
> diff --git a/drivers/firmware/google/vpd_decode.c
> b/drivers/firmware/google/vpd_decode.c
> index 92e3258552fc..5531770e3d58 100644
> --- a/drivers/firmware/google/vpd_decode.c
> +++ b/drivers/firmware/google/vpd_decode.c
> @@ -9,19 +9,19 @@
>
> #include "vpd_decode.h"
>
> -static int vpd_decode_len(const s32 max_len, const u8 *in,
> - s32 *length, s32 *decoded_len)
> +static int vpd_decode_len(const u32 max_len, const u8 *in, u32 *length,
Is there a reason why max_len and length changes to be unsigned?
Presumably to fix something.
> + u32 *decoded_len)
> {
> u8 more;
> int i = 0;
>
> if (!length || !decoded_len)
> - return VPD_FAIL;
> + return VPD_DECODE_FAIL;
>
> *length = 0;
> do {
> if (i >= max_len)
> - return VPD_FAIL;
> + return VPD_DECODE_FAIL;
>
> more = in[i] & 0x80;
> *length <<= 7;
> @@ -30,24 +30,43 @@ static int vpd_decode_len(const s32 max_len, const u8 *in,
> } while (more);
>
> *decoded_len = i;
> + return VPD_DECODE_OK;
> +}
> +
> +static int vpd_decode_entry(const u32 max_len, const u8 *input_buf,
> + u32 *consumed, const u8 **entry, u32 *entry_len)
> +{
> + u32 decoded_len;
> +
> + if (vpd_decode_len(max_len - *consumed,
Re: [PATCH] gpio: refactor gpiochip_allocate_mask() with bitmap_alloc()
On Thu, Jul 18, 2019 at 8:51 AM Masahiro Yamada wrote: > Refactor gpiochip_allocate_mask() slightly by using bitmap_alloc(). > > I used bitmap_free() for the corresponding free parts. Actually, > bitmap_free() is a wrapper of kfree(), but I did this for consistency. > > Signed-off-by: Masahiro Yamada Patch applied with Stephen's ACK. Yours, Linus Walleij
Re: [patch 2/5] x86/kvm: Handle task_work on VMENTER/EXIT
On Fri, 2 Aug 2019, Paolo Bonzini wrote:
> On 01/08/19 23:47, Thomas Gleixner wrote:
> > Right you are about cond_resched() being called, but for SRCU this does not
> > matter unless there is some way to do a synchronize operation on that SRCU
> > entity. It might have some other performance side effect though.
>
> I would use srcu_read_unlock/lock around the call.
>
> However, I'm wondering if the API can be improved because basically we
> have six functions for three checks of TIF flags. Does it make sense to
> have something like task_has_request_flags and task_do_requests (names
> are horrible I know) that can be used like
>
> if (task_has_request_flags()) {
> int err;
> ...srcu_read_unlock...
> // return -EINTR if signal_pending
> err = task_do_requests();
> if (err < 0)
> goto exit_no_srcu_read_unlock;
> ...srcu_read_lock...
> }
>
> taking care of all three cases with a single hook? This is important
> especially because all these checks are done by all KVM architectures in
> slightly different ways, and a unified API would be a good reason to
> make all architectures look the same.
>
> (Of course I could also define this unified API in virt/kvm/kvm_main.c,
> so this is not blocking the series in any way!).
You're not holding up something. Having a common function for this is
definitely the right approach.
As this is virt specific because it only checks for non arch specific bits
(TIF_NOTIFY_RESUME should be available for all KVM archs) and the TIF bits
are a subset of the available TIF bits because all others do not make any
sense there, this really should be a common function for KVM so that all
other archs which obviously lack a TIF_NOTIFY_RESUME check, can be fixed up
and consolidated. If we add another TIF check later then we only have to do
it in one place.
Thanks,
tglx
Re: [PATCH 2/2] gpio: mpc8xxx: Add ls1028a device specify function.
On Thu, Jul 18, 2019 at 11:58 AM Hui Song wrote: > From: Song Hui > > There is a device specify register(named GPIO_IBE) > on ls1028a need to enable in initial stage. > > Signed-off-by: Song Hui Patch applied. As noted on patch 1/2, send a separate patch to add the device tree bindings in Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt Yours, Linus Walleij
Re: [GIT PULL] SCSI fixes for 5.3-rc2
The pull request you sent on Fri, 02 Aug 2019 08:39:17 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6e6d05360b80f196ed07061327f03346b204abea Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PULL REQUEST] Please pull rdma.git
The pull request you sent on Fri, 02 Aug 2019 10:39:04 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b07042ca32ffca69b4e3c3b938bb89ab8aa18035 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: please revert "drm/msm: Use the correct dma_sync calls in msm_gem"
On Fri, Aug 2, 2019 at 2:37 PM Christoph Hellwig wrote:
>
> Hi Rob,
>
> I just saw your above commit in Linus' tree, which is completely
> bogus and misunderstand the DMA API. Next time you have any issues
> please Cc the relevant maintainers and mailing lists. But even
> more importantly get_dma_ops is an completely internal API, and
> whatevet your helpers are trying to do is bad - if the dma wasn't
> mapped at the time you call the new sync_for_device helper, this
> is broken because you can't call dma_sync_sg_for_device on unmapped
> address. If it was mapped it is bogus as well as you can't double
> map it. Please describe what you're actually trying to fix and we're
> going to work on a proper solution, but this shot from the hip is just
> going to make things worse.
Sorry, this is just a temporary band-aid for v5.3 to get things
working again. Yes, I realize it is a complete hack.
The root problem is that I'm using the DMA API in the first place. I
don't actually use the DMA API to map buffers, for various reasons,
but instead manage the iommu_domain directly.
Because arm/arm64 cache ops are not exported to modules, so currently
I need to abuse the DMA API for cache operations (really just to clean
pages if I need to mmap them uncached/writecombine). Originally I was
doing that w/ dma_{map,unmap}_sg. But to avoid debug splats I
switched that to dma_sync_sg (see
0036bc73ccbe7e600a3468bf8e8879b122252274). But now it seems the
dma-direct ops are unhappy w/ dma_sync without a dma_map (AFAICT).
(On some generations of hw, the iommu is attached to the device node
that maps to the drm device, which is passed to dma_map/dma_sync. On
other generations the iommu is attached to a sub-device. Changing
this would break dtb compatibility.. so for now I need to handle both
iommu-ops and direct-ops cases.)
For v5.4, my plan was to revisit (at least for arm64) exposing cache
ops to drivers, so I can use drm_clflush_* instead, and stop abusing
DMA API.
BR,
-R
[PATCH v2] KVM: x86: Unconditionally call x86 ops that are always implemented
Remove a few stale checks for non-NULL ops now that the ops in question
are implemented by both VMX and SVM.
Note, this is **not** stable material, the Fixes tags are there purely
to show when a particular op was first supported by both VMX and SVM.
Fixes: 74f169090b6f ("kvm/svm: Setup MCG_CAP on AMD properly")
Fixes: b31c114b82b2 ("KVM: X86: Provide a capability to disable PAUSE
intercepts")
Fixes: 411b44ba80ab ("svm: Implements update_pi_irte hook to setup posted
interrupt")
Cc: Krish Sadhukhan
Signed-off-by: Sean Christopherson
---
v2: Give update_pi_iret the same treatment [Krish].
arch/x86/kvm/x86.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 01e18caac825..e7c993f0cbed 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3506,8 +3506,7 @@ static int kvm_vcpu_ioctl_x86_setup_mce(struct kvm_vcpu
*vcpu,
for (bank = 0; bank < bank_num; bank++)
vcpu->arch.mce_banks[bank*4] = ~(u64)0;
- if (kvm_x86_ops->setup_mce)
- kvm_x86_ops->setup_mce(vcpu);
+ kvm_x86_ops->setup_mce(vcpu);
out:
return r;
}
@@ -9313,10 +9312,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
kvm_page_track_init(kvm);
kvm_mmu_init_vm(kvm);
- if (kvm_x86_ops->vm_init)
- return kvm_x86_ops->vm_init(kvm);
-
- return 0;
+ return kvm_x86_ops->vm_init(kvm);
}
static void kvm_unload_vcpu_mmu(struct kvm_vcpu *vcpu)
@@ -9992,7 +9988,7 @@ EXPORT_SYMBOL_GPL(kvm_arch_has_noncoherent_dma);
bool kvm_arch_has_irq_bypass(void)
{
- return kvm_x86_ops->update_pi_irte != NULL;
+ return true;
}
int kvm_arch_irq_bypass_add_producer(struct irq_bypass_consumer *cons,
@@ -10032,9 +10028,6 @@ void kvm_arch_irq_bypass_del_producer(struct
irq_bypass_consumer *cons,
int kvm_arch_update_irqfd_routing(struct kvm *kvm, unsigned int host_irq,
uint32_t guest_irq, bool set)
{
- if (!kvm_x86_ops->update_pi_irte)
- return -EINVAL;
-
return kvm_x86_ops->update_pi_irte(kvm, host_irq, guest_irq, set);
}
--
2.22.0
[ANNOUNCE] Git v2.23.0-rc1
A release candidate Git v2.23.0-rc1 is now available for testing at the usual places. It is comprised of 471 non-merge commits since v2.22.0, contributed by 63 people, 23 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.23.0-rc1' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git New contributors whose contributions weren't in v2.22.0 are as follows. Welcome to the Git development community! Ariadne Conill, Barret Rhoden, Ben Avison, Daniel Ferreira, Doug Ilijev, Dr. Adam Nielsen, Jakub Wilk, John Lin, Matheus Tavares, Mazo, Andrey, Michael Osipov, Michael Platings, Miguel Ojeda, Mike Mueller, Morian Sonnet, Quentin Nerden, Robert Morgan, Simon Williams, Steven Roberts, Tigran Mkrtchyan, Varun Naik, Vishal Verma, and Xin Li. Returning contributors who helped this release are as follows. Thanks for your continued support. Ævar Arnfjörð Bjarmason, Beat Bolli, Boxuan Li, brian m. carlson, Carlo Marcelo Arenas Belón, Cesar Eduardo Barros, Chris Mayo, Christian Couder, Denton Liu, Derrick Stolee, Dimitriy Ryazantcev, Edmundo Carmona Antoranz, Elijah Newren, Emily Shaffer, Eric Wong, Felipe Contreras, Jeff Hostetler, Jeff King, Johannes Schindelin, Johannes Sixt, Jonathan Tan, Josh Steadmon, Junio C Hamano, Karsten Blees, Marc-André Lureau, Martin Ågren, Matthew DeVore, Mike Hommey, Nguyễn Thái Ngọc Duy, Nickolai Belakovski, Paolo Bonzini, Philip Oakley, Phillip Wood, Ramsay Jones, René Scharfe, Rohit Ashiwal, Stephen Boyd, SZEDER Gábor, Taylor Blau, and Thomas Gummerer. Git 2.23 Release Notes (draft) == Updates since v2.22 --- Backward compatibility note * The "--base" option of "format-patch" computed the patch-ids for prerequisite patches in an unstable way, which has been updated to compute in a way that is compatible with "git patch-id --stable". * The "git log" command by default behaves as if the --mailmap option was given. UI, Workflows & Features * The "git fast-export/import" pair has been taught to handle commits with log messages in encoding other than UTF-8 better. * In recent versions of Git, per-worktree refs are exposed in refs/worktrees// hierarchy, which means that worktree names must be a valid refname component. The code now sanitizes the names given to worktrees, to make sure these refs are well-formed. * "git merge" learned "--quit" option that cleans up the in-progress merge while leaving the working tree and the index still in a mess. * "git format-patch" learns a configuration to set the default for its --notes= option. * The code to show args with potential typo that cannot be interpreted as a commit-ish has been improved. * "git clone --recurse-submodules" learned to set up the submodules to ignore commit object names recorded in the superproject gitlink and instead use the commits that happen to be at the tip of the remote-tracking branches from the get-go, by passing the new "--remote-submodules" option. * The pattern "git diff/grep" use to extract funcname and words boundary for Matlab has been extend to cover Octave, which is more or less equivalent. * "git help git" was hard to discover (well, at least for some people). * The pattern "git diff/grep" use to extract funcname and words boundary for Rust has been added. * "git status" can be told a non-standard default value for the "--[no-]ahead-behind" option with a new configuration variable status.aheadBehind. * "git fetch" and "git pull" reports when a fetch results in non-fast-forward updates to let the user notice unusual situation. The commands learned "--no-show-forced-updates" option to disable this safety feature. * Two new commands "git switch" and "git restore" are introduced to split "checking out a branch to work on advancing its history" and "checking out paths out of the index and/or a tree-ish to work on advancing the current history" out of the single "git checkout" command. * "git branch --list" learned to always output the detached HEAD as the first item (when the HEAD is detached, of course), regardless of the locale. * The conditional inclusion mechanism learned to base the choice on the branch the HEAD currently is on. * "git rev-list --objects" learned the "--no-object-names" option to squelch the path to the object that is used as a grouping hint for pack-objects. * A new tag.gpgSign configuration variable turns "git tag -a" into "git tag -s". * "git multi-pack-index" learned expire and repack subcommands. * "git blame" learned to "ignore" commits in the history,
Re: [PATCH] isdn: hysdn: Fix error spaces around '*'
On Fri, 2019-08-02 at 14:55 -0700, Stephen Hemminger wrote: > On Fri, 2 Aug 2019 19:56:02 + > Jose Carlos Cazarin Filho wrote: > > > Fix checkpath error: > > CHECK: spaces preferred around that '*' (ctx:WxV) > > +extern hysdn_card *card_root;/* pointer to first card */ > > > > Signed-off-by: Jose Carlos Cazarin Filho > > Read the TODO, these drivers are scheduled for removal, so changes > are not helpful at this time. Maybe better to mark the MAINTAINERS entry obsolete so checkpatch bleats a message about unnecessary changes. --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 30bf852e6d6b..b5df91032574 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8628,7 +8628,7 @@ M:Karsten Keil L: isdn4li...@listserv.isdn4linux.de (subscribers-only) L: net...@vger.kernel.org W: http://www.isdn4linux.de -S: Odd Fixes +S: Obsolete F: Documentation/isdn/ F: drivers/isdn/capi/ F: drivers/staging/isdn/
Highpoint RocketRAID 3720A not detected (4.19.63)
I've just bought a Highpoint RocketRAID 3720A, and I can't seem to persuade it to show me any disks. I've built a vanilla 4.19.63 kernel for this, and I'm not seeing any of the six (SATA) disks I've attached to it. I've tried modprobing the hptiop module manually, and still nothing. I've even, in desperation, tried installing Highpoint's own driver, but that's also not having any effect. I've probably missed something really obvious, but this is my first time with both SAS and this hardware. However, I note that the PCI ID (1103:3720) doesn't appear to be in include/linux/pci_ids.h, at which point I've more or less exhausted my knowledge of kernel internals... What do I need to do to get this thing to work? I'm only after JBOD -- I don't actually need the hardware RAID capabilities. Thanks, Hugo. hrm@amelia:~ $ sudo lspci 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD9x0/RX980 Host Bridge (rev 02) 00:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GFX port 0) 00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 0) 00:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 2) 00:09.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 4) 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] (rev 40) 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller (rev 42) 00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) (rev 40) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller (rev 40) 00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI Bridge (rev 40) 00:14.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller 00:15.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB700/SB800/SB900 PCI to PCI bridge (PCIE port 0) 00:16.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:16.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 0 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 1 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 2 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 3 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 4 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 5 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series] 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cedar HDMI Audio [Radeon HD 5400/6300/7300 Series] 02:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host Controller (rev 01) 03:00.0 SATA controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01) 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) 06:00.0 RAID bus controller: HighPoint Technologies, Inc. Device 3720 (rev a1) hrm@amelia:~ $ sudo lspci -n 00:00.0 0600: 1002:5a14 (rev 02) 00:02.0 0604: 1002:5a16 00:04.0 0604: 1002:5a18 00:06.0 0604: 1002:5a1a 00:09.0 0604: 1002:5a1c 00:11.0 0106: 1002:4391 (rev 40) 00:12.0 0c03: 1002:4397 00:12.2 0c03: 1002:4396 00:13.0 0c03: 1002:4397 00:13.2 0c03: 1002:4396 00:14.0 0c05: 1002:4385 (rev 42) 00:14.2 0403: 1002:4383 (rev 40) 00:14.3 0601: 1002:439d (rev 40) 00:14.4 0604: 1002:4384 (rev 40) 00:14.5 0c03: 1002:4399 00:15.0 0604: 1002:43a0 00:16.0 0c03: 1002:4397 00:16.2 0c03: 1002:4396 00:18.0 0600: 1022:1600 00:18.1 0600: 1022:1601 00:18.2 0600: 1022:1602 00:18.3 0600: 1022:1603 00:18.4 0600: 1022:1604 00:18.5 0600: 1022:1605 01:00.0 0300: 1002:68f9 01:00.1 0403: 1002:aa68 02:00.0 0c03: 1106:3483 (rev 01) 03:00.0 0106: 1095:3132 (rev 01) 04:00.0 0200: 10ec:8168 (rev 0c) 06:00.0 0104: 1103:3720 (rev a1) hrm@amelia:~ $ lsmod Module Size Used by hptiop 20480 0 rr3740a 573440 0 tun40960 0 nfsd 290816 13 auth_rpcgss57344 2 nfsd
Re: [PATCH] Add default binder devices through binderfs when configured
On Fri, Aug 2, 2019 at 8:06 AM Christian Brauner wrote:
>
> On Fri, Aug 02, 2019 at 08:18:38AM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Aug 01, 2019 at 03:35:56PM -0700, Hridya Valsaraju wrote:
> > > If CONFIG_ANDROID_BINDERFS is set, the default binder devices
> > > specified by CONFIG_ANDROID_BINDER_DEVICES are created in each
> > > binderfs instance instead of global devices being created by
> > > the binder driver.
> > >
> > > Co-developed-by: Christian Brauner
> > > Signed-off-by: Christian Brauner
> > > Signed-off-by: Hridya Valsaraju
> > > ---
> > > drivers/android/binder.c | 3 ++-
> > > drivers/android/binderfs.c | 46 ++
> > > 2 files changed, 44 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> > > index 466b6a7f8ab7..65a99ac26711 100644
> > > --- a/drivers/android/binder.c
> > > +++ b/drivers/android/binder.c
> > > @@ -6279,7 +6279,8 @@ static int __init binder_init(void)
> > > _log_fops);
> > > }
> > >
> > > - if (strcmp(binder_devices_param, "") != 0) {
> > > + if (!IS_ENABLED(CONFIG_ANDROID_BINDERFS) &&
> > > + strcmp(binder_devices_param, "") != 0) {
> > > /*
> > > * Copy the module_parameter string, because we don't want to
> > > * tokenize it in-place.
> > > diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> > > index e773f45d19d9..9f5ed50ffd70 100644
> > > --- a/drivers/android/binderfs.c
> > > +++ b/drivers/android/binderfs.c
> > > @@ -48,6 +48,10 @@ static dev_t binderfs_dev;
> > > static DEFINE_MUTEX(binderfs_minors_mutex);
> > > static DEFINE_IDA(binderfs_minors);
> > >
> > > +static char *binder_devices_param = CONFIG_ANDROID_BINDER_DEVICES;
> > > +module_param_named(devices, binder_devices_param, charp, 0444);
> > > +MODULE_PARM_DESC(devices, "Binder devices to be created by default");
> > > +
> >
> > Why are you creating a module parameter? That was not in your changelog
> > :(
>
> Yeah, you don't need an additional module parameter. You can just move
>
> static char *binder_devices_param = CONFIG_ANDROID_BINDER_DEVICES;
> module_param_named(devices, binder_devices_param, charp, 0444);
>
> from binder.c to binder_internal.h and expose it to binder.c and
> binderfs.c this way. This will work just fine since binderfs.c doesn't
> modify the parameter and binder.c makes a copy of it before doing so.
>
> >
> >
> >
> > > /**
> > > * binderfs_mount_opts - mount options for binderfs
> > > * @max: maximum number of allocatable binderfs binder devices
> > > @@ -135,7 +139,6 @@ static int binderfs_binder_device_create(struct inode
> > > *ref_inode,
> > > #else
> > > bool use_reserve = true;
> > > #endif
> > > -
> > > /* Reserve new minor number for the new device. */
> > > mutex_lock(_minors_mutex);
> > > if (++info->device_count <= info->mount_opts.max)
> > > @@ -186,8 +189,7 @@ static int binderfs_binder_device_create(struct inode
> > > *ref_inode,
> > > req->major = MAJOR(binderfs_dev);
> > > req->minor = minor;
> > >
> > > - ret = copy_to_user(userp, req, sizeof(*req));
> > > - if (ret) {
> > > + if (userp && copy_to_user(userp, req, sizeof(*req))) {
> > > ret = -EFAULT;
> > > goto err;
> > > }
> > > @@ -467,6 +469,9 @@ static int binderfs_fill_super(struct super_block
> > > *sb, void *data, int silent)
> > > int ret;
> > > struct binderfs_info *info;
> > > struct inode *inode = NULL;
> > > + struct binderfs_device device_info = { 0 };
> > > + const char *name;
> > > + size_t len;
> > >
> > > sb->s_blocksize = PAGE_SIZE;
> > > sb->s_blocksize_bits = PAGE_SHIFT;
> > > @@ -521,7 +526,28 @@ static int binderfs_fill_super(struct super_block
> > > *sb, void *data, int silent)
> > > if (!sb->s_root)
> > > return -ENOMEM;
> > >
> > > - return binderfs_binder_ctl_create(sb);
> > > + ret = binderfs_binder_ctl_create(sb);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + name = binder_devices_param;
> > > + for (len = strcspn(name, ","); len > 0; len = strcspn(name, ",")) {
> > > + /*
> > > +* init_binderfs() has already checked that the length of
> > > +* device_name_entry->name is not greater than
> > > device_info.name.
> > > +*/
> > > + strscpy(device_info.name, name, len + 1);
> > > + ret = binderfs_binder_device_create(inode, NULL,
> > > _info);
> > > + if (ret)
> > > + return ret;
> > > + name += len;
> > > + if (*name == ',')
> > > + name++;
> > > +
> > > + }
> > > +
> > > + return 0;
> > > +
> > > }
> > >
> > > static struct dentry *binderfs_mount(struct file_system_type *fs_type,
> > > @@ -553,6 +579,18 @@ static struct file_system_type binder_fs_type = {
> > > int __init init_binderfs(void)
> > > {
> > >
[PATCH net-next v3] net: phy: broadcom: add 1000Base-X support for BCM54616S
genphy_read_status() cannot report correct link speed when BCM54616S PHY
is configured in RGMII->1000Base-KX mode (for example, on Facebook CMM
BMC platform), and it is because speed-related fields in MII registers
are assigned different meanings in 1000X register set. Actually there
is no speed field in 1000X register set because link speed is always
1000 Mb/s.
The patch adds "probe" callback to detect PHY's operation mode based on
INTERF_SEL[1:0] pins and 1000X/100FX selection bit in SerDES 100-FX
Control register. Besides, link speed is manually set to 1000 Mb/s in
"read_status" callback if PHY-switch link is 1000Base-X.
Signed-off-by: Tao Ren
---
Changes in v3:
- rename bcm5482_read_status to bcm54xx_read_status so the callback can
be shared by BCM5482 and BCM54616S.
Changes in v2:
- Auto-detect PHY operation mode instead of passing DT node.
- move PHY mode auto-detect logic from config_init to probe callback.
- only set speed (not including duplex) in read_status callback.
- update patch description with more background to avoid confusion.
- patch #1 in the series ("net: phy: broadcom: set features explicitly
for BCM54616") is dropped: the fix should go to get_features callback
which may potentially depend on this patch.
drivers/net/phy/broadcom.c | 41 +-
include/linux/brcmphy.h| 10 --
2 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 937d0059e8ac..ecad8a201a09 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -383,9 +383,9 @@ static int bcm5482_config_init(struct phy_device *phydev)
/*
* Select 1000BASE-X register set (primary SerDes)
*/
- reg = bcm_phy_read_shadow(phydev, BCM5482_SHD_MODE);
- bcm_phy_write_shadow(phydev, BCM5482_SHD_MODE,
-reg | BCM5482_SHD_MODE_1000BX);
+ reg = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
+ bcm_phy_write_shadow(phydev, BCM54XX_SHD_MODE,
+reg | BCM54XX_SHD_MODE_1000BX);
/*
* LED1=ACTIVITYLED, LED3=LINKSPD[2]
@@ -409,7 +409,7 @@ static int bcm5482_config_init(struct phy_device *phydev)
return err;
}
-static int bcm5482_read_status(struct phy_device *phydev)
+static int bcm54xx_read_status(struct phy_device *phydev)
{
int err;
@@ -464,6 +464,35 @@ static int bcm54616s_config_aneg(struct phy_device *phydev)
return ret;
}
+static int bcm54616s_probe(struct phy_device *phydev)
+{
+ int val, intf_sel;
+
+ val = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
+ if (val < 0)
+ return val;
+
+ /* The PHY is strapped in RGMII to fiber mode when INTERF_SEL[1:0]
+* is 01b.
+*/
+ intf_sel = (val & BCM54XX_SHD_INTF_SEL_MASK) >> 1;
+ if (intf_sel == 1) {
+ val = bcm_phy_read_shadow(phydev, BCM54616S_SHD_100FX_CTRL);
+ if (val < 0)
+ return val;
+
+ /* Bit 0 of the SerDes 100-FX Control register, when set
+* to 1, sets the MII/RGMII -> 100BASE-FX configuration.
+* When this bit is set to 0, it sets the GMII/RGMII ->
+* 1000BASE-X configuration.
+*/
+ if (!(val & BCM54616S_100FX_MODE))
+ phydev->dev_flags |= PHY_BCM_FLAGS_MODE_1000BX;
+ }
+
+ return 0;
+}
+
static int brcm_phy_setbits(struct phy_device *phydev, int reg, int set)
{
int val;
@@ -655,6 +684,8 @@ static struct phy_driver broadcom_drivers[] = {
.config_aneg= bcm54616s_config_aneg,
.ack_interrupt = bcm_phy_ack_intr,
.config_intr= bcm_phy_config_intr,
+ .read_status= bcm54xx_read_status,
+ .probe = bcm54616s_probe,
}, {
.phy_id = PHY_ID_BCM5464,
.phy_id_mask= 0xfff0,
@@ -689,7 +720,7 @@ static struct phy_driver broadcom_drivers[] = {
.name = "Broadcom BCM5482",
/* PHY_GBIT_FEATURES */
.config_init= bcm5482_config_init,
- .read_status= bcm5482_read_status,
+ .read_status= bcm54xx_read_status,
.ack_interrupt = bcm_phy_ack_intr,
.config_intr= bcm_phy_config_intr,
}, {
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 6db2d9a6e503..b475e7f20d28 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -200,9 +200,15 @@
#define BCM5482_SHD_SSD0x14/* 10100: Secondary SerDes
control */
#define BCM5482_SHD_SSD_LEDM 0x0008 /* SSD LED Mode enable */
#define BCM5482_SHD_SSD_EN 0x0001 /* SSD enable */
-#define BCM5482_SHD_MODE 0x1f/* 1: Mode Control Register */
-#define BCM5482_SHD_MODE_1000BX0x0001 /* Enable
Re: [PATCH] isdn: hysdn: fix code style error from checkpatch
On Fri, 2 Aug 2019 19:50:17 + Ricardo Bruno Lopes da Silva wrote: > Fix error bellow from checkpatch. > > WARNING: Block comments use * on subsequent lines > +/*** > + > > Signed-off-by: Ricardo Bruno Lopes da Silva Read the TODO, these drivers are scheduled for removal, so changes are not helpful at this time.
Re: [PATCH] isdn: hysdn: Fix error spaces around '*'
On Fri, 2 Aug 2019 19:56:02 + Jose Carlos Cazarin Filho wrote: > Fix checkpath error: > CHECK: spaces preferred around that '*' (ctx:WxV) > +extern hysdn_card *card_root;/* pointer to first card */ > > Signed-off-by: Jose Carlos Cazarin Filho Read the TODO, these drivers are scheduled for removal, so changes are not helpful at this time.
Re: [PATCH v2] power: supply: ab8500: remove set but not used variables 'vbup33_vrtcn' and 'bup_vch_range'
On Wed, Jul 17, 2019 at 4:19 PM YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warnings:
>
> drivers/power/supply/ab8500_charger.c:
> In function ab8500_charger_init_hw_registers:
> drivers/power/supply/ab8500_charger.c:3013:24: warning:
> variable vbup33_vrtcn set but not used [-Wunused-but-set-variable]
> drivers/power/supply/ab8500_charger.c:3013:5: warning:
> variable bup_vch_range set but not used [-Wunused-but-set-variable]
>
> They are not used since commit 4c4268dc97c4 ("power:
> supply: ab8500: Drop AB8540/9540 support")
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
Thanks for fixing my forgotten codepaths!
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Re: [PATCH 09/20] ext4: Initialize timestamps limits
On Fri, Aug 02, 2019 at 09:00:52PM +0200, Arnd Bergmann wrote: > > I must have misunderstood what the field says. I expected that > with s_min_extra_isize set beyond the nanosecond fields, there > would be a guarantee that all inodes have at least as many > extra bytes already allocated. What circumstances would lead to > an i_extra_isize smaller than s_min_extra_isize? When allocating new inodes, i_extra_isize is set to s_want_extra_isize. When modifying existing inodes, if i_extra_isize is less than s_min_extra_isize, then we will attempt to move out extended attribute(s) to the external xattr block. So the s_min_extra_isize field is not a guarantee, but rather an aspirationa goal. The idea is that at some point when we want to enable a new feature, which needs more extra inode space, we can adjust s_min_extra_size and s_want_extra_size, and the file system will migrate things to meet these constraints. The plan was to teach e2fsck how to fix all of the inodes to meet theh s_min_extra_size value, but that never got implemented, and we even then, e2fsck would have to deal with the case where tit couldn't move the extended attribute(s) in the inode out, because there was no place to put them. In practice, this hasn't been that much of a limitation because we haven't been adding that many extra inode fields. Keep in mind that Red Hat for example, has explicitly said they will *never* support adding new features to an existing file system. Their only supported method is back up the file system, reformat it with the new file system features, and then restore the file system. Of course, if the backup/restore includes backing up the extended attributes, and then restoring them, the xattr restore could fail, unless the user also increased the inode size (e.g., from 256 bytes to 512 bytes). Getting this right in the general case is *hard*. Fortunately, the corner cases really don't happen that often in practice, at least not for pure Linux workloads. Windows which can have arbitrarily large security id's and ACL's might make this harder, of course --- although ext4's EA in inode feature would make this better, modulo needing to write more complex file system code to handle moving xattrs around. Since the extended timestamps were one of the first extra inode fields to be added, I strongly suggest that we not try to borrow trouble. Solving the general case problem is *hard*. - Ted
please revert "drm/msm: Use the correct dma_sync calls in msm_gem"
Hi Rob, I just saw your above commit in Linus' tree, which is completely bogus and misunderstand the DMA API. Next time you have any issues please Cc the relevant maintainers and mailing lists. But even more importantly get_dma_ops is an completely internal API, and whatevet your helpers are trying to do is bad - if the dma wasn't mapped at the time you call the new sync_for_device helper, this is broken because you can't call dma_sync_sg_for_device on unmapped address. If it was mapped it is bogus as well as you can't double map it. Please describe what you're actually trying to fix and we're going to work on a proper solution, but this shot from the hip is just going to make things worse.
Re: [patch 2/5] x86/kvm: Handle task_work on VMENTER/EXIT
On 01/08/19 23:47, Thomas Gleixner wrote:
> Right you are about cond_resched() being called, but for SRCU this does not
> matter unless there is some way to do a synchronize operation on that SRCU
> entity. It might have some other performance side effect though.
I would use srcu_read_unlock/lock around the call.
However, I'm wondering if the API can be improved because basically we
have six functions for three checks of TIF flags. Does it make sense to
have something like task_has_request_flags and task_do_requests (names
are horrible I know) that can be used like
if (task_has_request_flags()) {
int err;
...srcu_read_unlock...
// return -EINTR if signal_pending
err = task_do_requests();
if (err < 0)
goto exit_no_srcu_read_unlock;
...srcu_read_lock...
}
taking care of all three cases with a single hook? This is important
especially because all these checks are done by all KVM architectures in
slightly different ways, and a unified API would be a good reason to
make all architectures look the same.
(Of course I could also define this unified API in virt/kvm/kvm_main.c,
so this is not blocking the series in any way!).
Paolo
Re: [PATCH v2 4/6] irqchip/irq-pruss-intc: Add helper functions to configure internal mapping
Hi David, On 8/1/19 1:31 PM, David Lechner wrote: > On 8/1/19 12:10 PM, Suman Anna wrote: >> Hi Marc, >> >> On 8/1/19 3:45 AM, Marc Zyngier wrote: >>> On 31/07/2019 23:41, Suman Anna wrote: The PRUSS INTC receives a number of system input interrupt source events and supports individual control configuration and hardware prioritization. These input events can be mapped to some output interrupt lines through 2 levels of many-to-one mapping i.e. events to channel mapping and channels to output interrupts. This mapping information is provided through the PRU firmware that is loaded onto a PRU core/s or through the device tree node of the PRU application. The mapping is configured by the PRU remoteproc driver, and is setup before the PRU core is started and cleaned up after the PRU core is stopped. This event mapping configuration logic programs the Channel Map Registers (CMRx) and Host-Interrupt Map Registers (HMRx) only when a new program is being loaded/started and the same events and interrupt channels are reset to zero when stopping a PRU. Add two helper functions: pruss_intc_configure() & pruss_intc_unconfigure() that the PRU remoteproc driver can use to configure the PRUSS INTC. >>> >>> So let me see if I correctly understand this: this adds yet >>> another firmware description parser, with a private interface to >>> another (undisclosed?) driver, bypassing the standard irqchip >>> configuration mechanism. It sounds great, doesn't it? >>> >>> What I cannot really infer from this message (-ETOOMUCHJARGON) is >>> what interrupts this affects: >>> >>> - Interrupts from random devices to the PRUSS? - Interrupts from >>> the PRUSS to the host? - Something else? >> >> The interrupt sources (called system events) can be from internal >> PRUSS peripherals, SoC-level peripherals or just software >> triggering (limited to some events). >> >> So, the PRUSS INTC behaves as a funnel and is both an interrupt >> router and multiplexer. The INTC itself is part of the PRUSS, and >> all PRU application related interrupts/events that need to trigger >> an interrupt to either the PRU cores or other host processors (like >> DSP, ARM) have to go through this INTC, and routed out to a limited >> number of output interrupts that are then connected to different >> processors. >> >> The split of interrupt handling between a PRU and its peer host >> processor will be a application design choice (We can implement >> soft IPs like UARTs, ADCs, I2Cs etc using PRUs). Some of the input >> events themselves are multiplexed and controlled by a single MMR >> (outside of INTC) that feeds different sets of events into the >> INTC. The MMR configuration is outside of scope of this driver and >> will depend on the application/client driver being run. >> >>> >>> When does this happen? Under control of what? It isn't even clear >>> why this is part of this irqchip driver. >> >> The mapping configuration is per PRU application and firmware, and >> is done in line with acquiring and release a PRU which is treated >> as an exclusive resource. We establish the mapping for all events >> through this driver including the events that are to be routed to >> PRUs. This is done to save the tiny/limited Instruction RAM space >> that PRUs have. >> >> We have designed this as an irqchip driver (instead of some custom >> SoC driver exporting custom functions) to use standard Linux >> semantics/irq API and better integrate with Linux DT, but we need >> some semantics for establishing the routing at runtime depending on >> the PRU client driver we are running. The exported functions will >> be called only by the PRU remoteproc driver during a >> pru_rproc_get()/pru_rproc_put(), and are transparent to PRU client >> drivers. >> >> Please also see the discussion from v1 [1] on why we can't use an >> extended number of interrupt-cells infrastructure for achieving >> this. >> >> [1] https://patchwork.kernel.org/patch/11034563/ >> >> >>> Depending what this does, there may be ways to fit it into the >>> standard interrupt configuration framework. After all, we already >>> have standard interfaces to route interrupts to virtual CPUs, >>> effectively passing full control of an interrupt to another >>> entity. If you squint hard enough, your PRUSS can fit that >>> description. >> >> Yeah, I am open to suggestions if there is a better way of doing >> this. > > Hi Suman, > > Can you explain more about the use case where one PRU system event > is mapped to multiple host events? On AM335x, for example, we have 64 events out of which events 16 to 31 are not sourced by any peripherals and are used for general purpose signaling between a PRU0/PRU1 core and any external host processor (like an ARM). So, different applications/drivers implementing a different soft IP like a Soft UART, Soft I2C, ADC etc will need to be using among these generic set to
Re: [PATCH 7/7] tracing: Un-export ftrace_set_clr_event
On Fri, 2 Aug 2019 14:12:54 -0700
Divya Indi wrote:
> Hi Steve,
>
> The first patch would be like a temporary fix in case we need more
> changes to the patches that add the new function - trace_array_set_clr()
> and unexport ftrace_set_clr_event() and might take some time. In which
> case I think it would be good to have this in place (But, not part of
> this series).
>
> If they all are to go in together as part of the same release ie if all
> is good with the concerned patches (Patch 6 & Patch 7), then I think
> having this patch would be meaningless.
Can you just do this part of patch 6 instead?
+/**
+ * trace_array_set_clr_event - enable or disable an event for a trace array
+ * @system: system name to match (NULL for any system)
+ * @event: event name to match (NULL for all events, within system)
+ * @set: 1 to enable, 0 to disable
+ *
+ * This is a way for other parts of the kernel to enable or disable
+ * event recording to instances.
+ *
+ * Returns 0 on success, -EINVAL if the parameters do not match any
+ * registered events.
+ */
+int trace_array_set_clr_event(struct trace_array *tr, const char *system,
+ const char *event, int set)
+{
+ if (!tr)
+ return -ENOENT;
+
+ return __ftrace_set_clr_event(tr, NULL, system, event, set);
+}
+EXPORT_SYMBOL_GPL(trace_array_set_clr_event);
+
-- Steve
Re: [PATCH] KEYS: trusted: allow module init if TPM is inactive or deactivated
On 2019-07-09 12:31:45, Mimi Zohar wrote: > On Tue, 2019-07-09 at 19:24 +0300, Jarkko Sakkinen wrote: > > On Mon, Jul 08, 2019 at 01:34:59PM -0700, James Bottomley wrote: > > > Not a criticism of your patch, but can we please stop doing this. > > > Single random number sources are horrendously bad practice because it > > > gives an attacker a single target to subvert. We should ensure the TPM > > > is plugged into the kernel RNG as a source and then take randomness > > > from the mixed pool so it's harder for an attacker because they have to > > > subvert all our sources to predict what came out. > > > > It is and I agree. > > I still haven't quite figured out why the digests need to be > initialized to anything other than 0. After looking into 0b6cf6b97b7ef1fa3c7fefab0cac897a1c4a3400, I have to agree. I don't see the purpose of using tpm_get_random() in init_digests(). Roberto, why can't we just initialize the digests with zeroes? It would fix the bug for eCryptfs and NVDIMM and address the concern that James had regarding the single random number source. Tyler
Re: [PATCH v7 07/20] clk: tegra: clk-periph: Add save and restore support
On 8/2/19 2:15 PM, Dmitry Osipenko wrote:
02.08.2019 23:32, Sowjanya Komatineni пишет:
On 8/2/19 1:17 PM, Dmitry Osipenko wrote:
02.08.2019 23:13, Dmitry Osipenko пишет:
02.08.2019 21:33, Sowjanya Komatineni пишет:
On 8/2/19 5:38 AM, Dmitry Osipenko wrote:
02.08.2019 2:49, Sowjanya Komatineni пишет:
On 8/1/19 4:19 PM, Sowjanya Komatineni wrote:
On 8/1/19 2:30 PM, Sowjanya Komatineni wrote:
On 8/1/19 1:54 PM, Dmitry Osipenko wrote:
01.08.2019 23:31, Sowjanya Komatineni пишет:
On 8/1/19 1:17 PM, Dmitry Osipenko wrote:
01.08.2019 22:42, Sowjanya Komatineni пишет:
On 8/1/19 12:00 PM, Dmitry Osipenko wrote:
01.08.2019 20:58, Sowjanya Komatineni пишет:
On 7/31/19 4:09 PM, Sowjanya Komatineni wrote:
On 7/31/19 3:44 AM, Dmitry Osipenko wrote:
31.07.2019 12:50, Dmitry Osipenko пишет:
31.07.2019 3:20, Sowjanya Komatineni пишет:
This patch implements save and restore context for
peripheral
fixed
clock ops, peripheral gate clock ops, sdmmc mux clock
ops, and
peripheral clock ops.
During system suspend, core power goes off and looses the
settings
of the Tegra CAR controller registers.
So during suspend entry clock and reset state of
peripherals is
saved
and on resume they are restored to have clocks back to
same
rate and
state as before suspend.
Acked-by: Thierry Reding
Signed-off-by: Sowjanya Komatineni
---
drivers/clk/tegra/clk-periph-fixed.c | 33
drivers/clk/tegra/clk-periph-gate.c | 34
+
drivers/clk/tegra/clk-periph.c | 37
drivers/clk/tegra/clk-sdmmc-mux.c | 28
+++
drivers/clk/tegra/clk.h | 6 ++
5 files changed, 138 insertions(+)
diff --git a/drivers/clk/tegra/clk-periph-fixed.c
b/drivers/clk/tegra/clk-periph-fixed.c
index c088e7a280df..21b24530fa00 100644
--- a/drivers/clk/tegra/clk-periph-fixed.c
+++ b/drivers/clk/tegra/clk-periph-fixed.c
@@ -60,11 +60,44 @@
tegra_clk_periph_fixed_recalc_rate(struct
clk_hw *hw,
return (unsigned long)rate;
}
+static int
tegra_clk_periph_fixed_save_context(struct
clk_hw
*hw)
+{
+ struct tegra_clk_periph_fixed *fixed =
to_tegra_clk_periph_fixed(hw);
+ u32 mask = 1 << (fixed->num % 32);
+
+ fixed->enb_ctx = readl_relaxed(fixed->base +
fixed->regs->enb_reg) &
+ mask;
+ fixed->rst_ctx = readl_relaxed(fixed->base +
fixed->regs->rst_reg) &
+ mask;
+
+ return 0;
+}
+
+static void
tegra_clk_periph_fixed_restore_context(struct
clk_hw
*hw)
+{
+ struct tegra_clk_periph_fixed *fixed =
to_tegra_clk_periph_fixed(hw);
+ u32 mask = 1 << (fixed->num % 32);
+
+ if (fixed->enb_ctx)
+ writel_relaxed(mask, fixed->base +
fixed->regs->enb_set_reg);
+ else
+ writel_relaxed(mask, fixed->base +
fixed->regs->enb_clr_reg);
+
+ udelay(2);
+
+ if (!fixed->rst_ctx) {
+ udelay(5); /* reset propogation delay */
+ writel_relaxed(mask, fixed->base +
fixed->regs->rst_reg);
+ }
+}
+
static const struct clk_ops
tegra_clk_periph_fixed_ops
= {
.is_enabled =
tegra_clk_periph_fixed_is_enabled,
.enable = tegra_clk_periph_fixed_enable,
.disable = tegra_clk_periph_fixed_disable,
.recalc_rate =
tegra_clk_periph_fixed_recalc_rate,
+ .save_context = tegra_clk_periph_fixed_save_context,
+ .restore_context =
tegra_clk_periph_fixed_restore_context,
};
struct clk
*tegra_clk_register_periph_fixed(const
char
*name,
diff --git a/drivers/clk/tegra/clk-periph-gate.c
b/drivers/clk/tegra/clk-periph-gate.c
index 4b31beefc9fc..6ba5b08e0787 100644
--- a/drivers/clk/tegra/clk-periph-gate.c
+++ b/drivers/clk/tegra/clk-periph-gate.c
@@ -25,6 +25,8 @@ static
DEFINE_SPINLOCK(periph_ref_lock);
#define read_rst(gate) \
readl_relaxed(gate->clk_base +
(gate->regs->rst_reg))
+#define write_rst_set(val, gate) \
+ writel_relaxed(val, gate->clk_base +
(gate->regs->rst_set_reg))
#define write_rst_clr(val, gate) \
writel_relaxed(val, gate->clk_base +
(gate->regs->rst_clr_reg))
@@ -110,10 +112,42 @@ static void
clk_periph_disable(struct
clk_hw *hw)
spin_unlock_irqrestore(_ref_lock, flags);
}
+static int clk_periph_gate_save_context(struct
clk_hw
*hw)
+{
+ struct tegra_clk_periph_gate *gate =
to_clk_periph_gate(hw);
+
+ gate->clk_state_ctx = read_enb(gate) &
periph_clk_to_bit(gate);
+ gate->rst_state_ctx = read_rst(gate) &
periph_clk_to_bit(gate);
+
+ return 0;
+}
+
+static void clk_periph_gate_restore_context(struct
clk_hw
*hw)
+{
+ struct tegra_clk_periph_gate *gate =
to_clk_periph_gate(hw);
+
+ if (gate->clk_state_ctx)
+ write_enb_set(periph_clk_to_bit(gate), gate);
+ else
+ write_enb_clr(periph_clk_to_bit(gate), gate);
+
+ udelay(5);
+
+ if (!(gate->flags & TEGRA_PERIPH_NO_RESET) &&
+ !(gate->flags & TEGRA_PERIPH_MANUAL_RESET)) {
+
Re: [PATCH v7 07/20] clk: tegra: clk-periph: Add save and restore support
02.08.2019 23:32, Sowjanya Komatineni пишет:
>
> On 8/2/19 1:17 PM, Dmitry Osipenko wrote:
>> 02.08.2019 23:13, Dmitry Osipenko пишет:
>>> 02.08.2019 21:33, Sowjanya Komatineni пишет:
On 8/2/19 5:38 AM, Dmitry Osipenko wrote:
> 02.08.2019 2:49, Sowjanya Komatineni пишет:
>> On 8/1/19 4:19 PM, Sowjanya Komatineni wrote:
>>> On 8/1/19 2:30 PM, Sowjanya Komatineni wrote:
On 8/1/19 1:54 PM, Dmitry Osipenko wrote:
> 01.08.2019 23:31, Sowjanya Komatineni пишет:
>> On 8/1/19 1:17 PM, Dmitry Osipenko wrote:
>>> 01.08.2019 22:42, Sowjanya Komatineni пишет:
On 8/1/19 12:00 PM, Dmitry Osipenko wrote:
> 01.08.2019 20:58, Sowjanya Komatineni пишет:
>> On 7/31/19 4:09 PM, Sowjanya Komatineni wrote:
>>> On 7/31/19 3:44 AM, Dmitry Osipenko wrote:
31.07.2019 12:50, Dmitry Osipenko пишет:
> 31.07.2019 3:20, Sowjanya Komatineni пишет:
>> This patch implements save and restore context for
>> peripheral
>> fixed
>> clock ops, peripheral gate clock ops, sdmmc mux clock
>> ops, and
>> peripheral clock ops.
>>
>> During system suspend, core power goes off and looses the
>> settings
>> of the Tegra CAR controller registers.
>>
>> So during suspend entry clock and reset state of
>> peripherals is
>> saved
>> and on resume they are restored to have clocks back to
>> same
>> rate and
>> state as before suspend.
>>
>> Acked-by: Thierry Reding
>> Signed-off-by: Sowjanya Komatineni
>>
>> ---
>> drivers/clk/tegra/clk-periph-fixed.c | 33
>>
>> drivers/clk/tegra/clk-periph-gate.c | 34
>> +
>> drivers/clk/tegra/clk-periph.c | 37
>>
>> drivers/clk/tegra/clk-sdmmc-mux.c | 28
>> +++
>> drivers/clk/tegra/clk.h | 6 ++
>> 5 files changed, 138 insertions(+)
>>
>> diff --git a/drivers/clk/tegra/clk-periph-fixed.c
>> b/drivers/clk/tegra/clk-periph-fixed.c
>> index c088e7a280df..21b24530fa00 100644
>> --- a/drivers/clk/tegra/clk-periph-fixed.c
>> +++ b/drivers/clk/tegra/clk-periph-fixed.c
>> @@ -60,11 +60,44 @@
>> tegra_clk_periph_fixed_recalc_rate(struct
>> clk_hw *hw,
>> return (unsigned long)rate;
>> }
>> +static int
>> tegra_clk_periph_fixed_save_context(struct
>> clk_hw
>> *hw)
>> +{
>> + struct tegra_clk_periph_fixed *fixed =
>> to_tegra_clk_periph_fixed(hw);
>> + u32 mask = 1 << (fixed->num % 32);
>> +
>> + fixed->enb_ctx = readl_relaxed(fixed->base +
>> fixed->regs->enb_reg) &
>> + mask;
>> + fixed->rst_ctx = readl_relaxed(fixed->base +
>> fixed->regs->rst_reg) &
>> + mask;
>> +
>> + return 0;
>> +}
>> +
>> +static void
>> tegra_clk_periph_fixed_restore_context(struct
>> clk_hw
>> *hw)
>> +{
>> + struct tegra_clk_periph_fixed *fixed =
>> to_tegra_clk_periph_fixed(hw);
>> + u32 mask = 1 << (fixed->num % 32);
>> +
>> + if (fixed->enb_ctx)
>> + writel_relaxed(mask, fixed->base +
>> fixed->regs->enb_set_reg);
>> + else
>> + writel_relaxed(mask, fixed->base +
>> fixed->regs->enb_clr_reg);
>> +
>> + udelay(2);
>> +
>> + if (!fixed->rst_ctx) {
>> + udelay(5); /* reset propogation delay */
>> + writel_relaxed(mask, fixed->base +
>> fixed->regs->rst_reg);
>> + }
>> +}
>> +
>> static const struct clk_ops
>> tegra_clk_periph_fixed_ops
>> = {
>> .is_enabled
Re: [PATCH 7/7] tracing: Un-export ftrace_set_clr_event
Hi Steve, The first patch would be like a temporary fix in case we need more changes to the patches that add the new function - trace_array_set_clr() and unexport ftrace_set_clr_event() and might take some time. In which case I think it would be good to have this in place (But, not part of this series). If they all are to go in together as part of the same release ie if all is good with the concerned patches (Patch 6 & Patch 7), then I think having this patch would be meaningless. Thanks, Divya On 8/2/19 1:46 PM, Steven Rostedt wrote: On Fri, 2 Aug 2019 13:41:20 -0700 Divya Indi wrote: As a stand alone patch, the first one may be fine. But as part of a series, it doesn't make sense to add it. I see. Will separate this out from the series. Is that really needed? Do you need to have that patch in the kernel? Do you plan on marking it for stable? -- Steve
