[PATCH 3/3] perf list: Add 'pfm' to list libpfm4 events
Print libpfm4 events with 'perf list pfm' command like others.
When libpfm4 support is not enabled, it'd print nothing.
Also it support glob pattern matching for event name.
$ perf list pfm
List of pre-defined events (to be used in --pfm-events):
ix86arch:
UNHALTED_CORE_CYCLES
[count core clock cycles whenever the clock signal ...
INSTRUCTION_RETIRED
[count the number of instructions at retirement. ...
...
Signed-off-by: Namhyung Kim
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 10ab5e40a34f..167868053fe0 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -14,6 +14,7 @@
#include "util/pmu.h"
#include "util/debug.h"
#include "util/metricgroup.h"
+#include "util/pfm.h"
#include
#include
#include
@@ -42,7 +43,7 @@ int cmd_list(int argc, const char **argv)
OPT_END()
};
const char * const list_usage[] = {
- "perf list []
[hw|sw|cache|tracepoint|pmu|sdt|metric|metricgroup|event_glob]",
+ "perf list []
[hw|sw|cache|tracepoint|pmu|sdt|metric|metricgroup|pfm|event_glob]",
NULL
};
@@ -53,7 +54,7 @@ int cmd_list(int argc, const char **argv)
setup_pager();
- if (!raw_dump && pager_in_use())
+ if (!raw_dump && pager_in_use() && (argc != 1 || strcmp(argv[0],
"pfm")))
printf("\nList of pre-defined events (to be used in -e):\n\n");
if (argc == 0) {
@@ -89,6 +90,8 @@ int cmd_list(int argc, const char **argv)
metricgroup__print(true, false, NULL, raw_dump,
details_flag);
else if (strcmp(argv[i], "metricgroup") == 0 || strcmp(argv[i],
"metricgroups") == 0)
metricgroup__print(false, true, NULL, raw_dump,
details_flag);
+ else if (strcmp(argv[i], "pfm") == 0)
+ print_libpfm_events(NULL, raw_dump, long_desc_flag);
else if ((sep = strchr(argv[i], ':')) != NULL) {
int sep_idx;
@@ -120,6 +123,7 @@ int cmd_list(int argc, const char **argv)
print_tracepoint_events(NULL, s, raw_dump);
print_sdt_events(NULL, s, raw_dump);
metricgroup__print(true, true, s, raw_dump,
details_flag);
+ print_libpfm_events(s, raw_dump, long_desc_flag);
free(s);
}
}
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 772f1057647f..ae8ab930a792 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -2593,7 +2593,7 @@ static struct option __record_options[] = {
"number of threads to run for event synthesis"),
#ifdef HAVE_LIBPFM
OPT_CALLBACK(0, "pfm-events", , "event",
- "libpfm4 event selector. use 'perf list' to list available
events",
+ "libpfm4 event selector. use 'perf list pfm' to list available
events",
parse_libpfm_events_option),
#endif
OPT_CALLBACK(0, "control", , "fd:ctl-fd[,ack-fd]",
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 483a28ef4ec4..a672d2b68e8a 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1166,7 +1166,7 @@ static struct option stat_options[] = {
"threads of same physical core"),
#ifdef HAVE_LIBPFM
OPT_CALLBACK(0, "pfm-events", _list, "event",
- "libpfm4 event selector. use 'perf list' to list available
events",
+ "libpfm4 event selector. use 'perf list pfm' to list available
events",
parse_libpfm_events_option),
#endif
OPT_CALLBACK(0, "control", _config, "fd:ctl-fd[,ack-fd]",
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 7c64134472c7..d6adc7d34210 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1578,7 +1578,7 @@ int cmd_top(int argc, const char **argv)
"Enable LBR callgraph stitching approach"),
#ifdef HAVE_LIBPFM
OPT_CALLBACK(0, "pfm-events", , "event",
- "libpfm4 event selector. use 'perf list' to list available
events",
+ "libpfm4 event selector. use 'perf list pfm' to list available
events",
parse_libpfm_events_option),
#endif
OPTS_EVSWITCH(),
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index c4d2394e2b2d..2d426a4f3bc7 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -2899,7 +2899,7 @@ void print_events(const char *event_glob, bool name_only,
bool quiet_flag,
metricgroup__print(true, true, NULL, name_only, details_flag);
- print_libpfm_events(name_only, long_desc);
+ print_libpfm_events(NULL, name_only, long_desc);
}
int parse_events__is_hardcoded_term(struct parse_events_term *term)
diff --git a/tools/perf/util/pfm.c
[PATCH 2/3] perf list: Do not print 'Metric Groups:' unnecessarily
It was printed unconditionally even if nothing is printed.
Check if the output list empty when filter is given.
Before:
$ ./perf list duration
List of pre-defined events (to be used in -e):
duration_time [Tool event]
Metric Groups:
After:
$ ./perf list duration
List of pre-defined events (to be used in -e):
duration_time [Tool event]
Signed-off-by: Namhyung Kim
diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
index 8831b964288f..38464d7d2d63 100644
--- a/tools/perf/util/metricgroup.c
+++ b/tools/perf/util/metricgroup.c
@@ -535,10 +535,12 @@ void metricgroup__print(bool metrics, bool metricgroups,
char *filter,
}
}
- if (metricgroups && !raw)
- printf("\nMetric Groups:\n\n");
- else if (metrics && !raw)
- printf("\nMetrics:\n\n");
+ if (!filter || !rblist__empty()) {
+ if (metricgroups && !raw)
+ printf("\nMetric Groups:\n\n");
+ else if (metrics && !raw)
+ printf("\nMetrics:\n\n");
+ }
for (node = rb_first_cached(); node; node = next) {
struct mep *me = container_of(node, struct mep, nd);
--
2.28.0.526.ge36021eeef-goog
[PATCH 1/3] perf list: Remove dead code in argument check
The sep is already checked being not NULL. The code seems to be a
leftover from some refactoring.
Signed-off-by: Namhyung Kim
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 0a7fe4cb..10ab5e40a34f 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -92,13 +92,6 @@ int cmd_list(int argc, const char **argv)
else if ((sep = strchr(argv[i], ':')) != NULL) {
int sep_idx;
- if (sep == NULL) {
- print_events(argv[i], raw_dump, !desc_flag,
- long_desc_flag,
- details_flag,
- deprecated);
- continue;
- }
sep_idx = sep - argv[i];
s = strdup(argv[i]);
if (s == NULL)
--
2.28.0.526.ge36021eeef-goog
Re: Mailing list about low levels of Linux on cellphones
* Bhaskar Chowdhury [200908 23:08]: > On 00:56 Wed 09 Sep 2020, Pavel Machek wrote: > > Would it be possible to create a mailing list on vger.kernel.org? > > Probably phones@ or phone-devel@? I believe it would be useful to > > cover hardware-dependend pieces of the phone stack (ofono, > > modemmanager) as well as kernel. Good idea, probably phone-devel list would be better for Linux kernel stuff. Regards, Tony
linux-next: build warning after merge of the tty tree
Hi all,
After merging the tty tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/tty/serial/8250/8250_bcm2835aux.c: In function
'bcm2835aux_serial_probe':
drivers/tty/serial/8250/8250_bcm2835aux.c:154:3: warning: ignoring return value
of 'dev_err_probe' declared with attribute 'warn_unused_result'
[-Wunused-result]
154 | dev_err_probe(>dev, ret, "unable to register 8250 port\n");
| ^~~~
Introduced by commit
ea43a60b1548 ("serial: 8250: Simplify with dev_err_probe()")
--
Cheers,
Stephen Rothwell
pgp5MOzggYyyG.pgp
Description: OpenPGP digital signature
Re: [PATCH] Rescan the entire target on transport reset when LUN is 0
On Tue, Sep 08, 2020 at 05:53:16PM +, Felipe Franciosi wrote:
>
>
> > On Sep 8, 2020, at 3:22 PM, Paolo Bonzini wrote:
> >
> > On 28/08/20 14:21, Matej Genci wrote:
> >> VirtIO 1.0 spec says
> >>The removed and rescan events ... when sent for LUN 0, they MAY
> >>apply to the entire target so the driver can ask the initiator
> >>to rescan the target to detect this.
> >>
> >> This change introduces the behaviour described above by scanning the
> >> entire scsi target when LUN is set to 0. This is both a functional and a
> >> performance fix. It aligns the driver with the spec and allows control
> >> planes to hotplug targets with large numbers of LUNs without having to
> >> request a RESCAN for each one of them.
> >>
> >> Signed-off-by: Matej Genci
> >> Suggested-by: Felipe Franciosi
> >> ---
> >> drivers/scsi/virtio_scsi.c | 7 ++-
> >> 1 file changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
> >> index bfec84aacd90..a4b9bc7b4b4a 100644
> >> --- a/drivers/scsi/virtio_scsi.c
> >> +++ b/drivers/scsi/virtio_scsi.c
> >> @@ -284,7 +284,12 @@ static void virtscsi_handle_transport_reset(struct
> >> virtio_scsi *vscsi,
> >>
> >>switch (virtio32_to_cpu(vscsi->vdev, event->reason)) {
> >>case VIRTIO_SCSI_EVT_RESET_RESCAN:
> >> - scsi_add_device(shost, 0, target, lun);
> >> + if (lun == 0) {
> >> + scsi_scan_target(>shost_gendev, 0, target,
> >> + SCAN_WILD_CARD, SCSI_SCAN_INITIAL);
> >> + } else {
> >> + scsi_add_device(shost, 0, target, lun);
> >> + }
> >>break;
> >>case VIRTIO_SCSI_EVT_RESET_REMOVED:
> >>sdev = scsi_device_lookup(shost, 0, target, lun);
> >>
> >
> >
> > Acked-by: Paolo Bonzini
>
> Cc: sta...@vger.kernel.org
>
> Thanks, Paolo.
>
> I'm Cc'ing stable as I believe this fixes a driver bug where it
> doesn't follow the spec. Per commit message, today devices are
> required to issue RESCAN events for each LUN behind a target when
> hotplugging, or risking the driver not seeing the new LUNs.
>
> Is this enough? Or should we resend after merge per below?
> https://www.kernel.org/doc/Documentation/process/stable-kernel-rules.rst
You need to let stable know the git commit id of the patch in Linus's
tree if the cc: stable is not on the final commit that gets merged.
thanks,
greg k-h
Re: [RFC PATCH v2 0/6] SCHED_DEADLINE server infrastructure
Hi Pavel, On 09/09/20 00:22, Pavel Machek wrote: > Hi! > > > This is RFC v2 of Peter's SCHED_DEADLINE server infrastructure > > implementation [1]. > > > > SCHED_DEADLINE servers can help fixing starvation issues of low priority > > tasks (e.g., > > SCHED_OTHER) when higher priority tasks monopolize CPU cycles. Today we > > have RT > > Throttling; DEADLINE servers should be able to replace and improve that. > > It would be worth noting what "server" is in this context. It comes from Constant Bandwidth Server (CBS), that SCHED_DEADLINE is implementing [1]. > > It is not white box with CPU inside, it is not even an userland process, > afaict. > > Subject is quite confusing. Best, Juri 1 - https://elixir.bootlin.com/linux/latest/source/Documentation/scheduler/sched-deadline.rst#L42
Re: [PATCH 5.4 000/129] 5.4.64-rc1 review
On Tue, 8 Sep 2020 at 21:12, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.4.64 release. > There are 129 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 Thu, 10 Sep 2020 15:21:57 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.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-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.4.64-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.4.y git commit: be965cc6b079fbac3bf73ce195ae06aa5314fd99 git describe: v5.4.63-130-gbe965cc6b079 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.63-130-gbe965cc6b079 No regressions (compared to build v5.4.63) No fixes (compared to build v5.4.63) Ran 34523 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * build * igt-gpu-tools * install-android-platform-tools-r2600 * kselftest * kselftest/drivers * kselftest/filesystems * kselftest/net * kvm-unit-tests * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-tracing-tests * perf * v4l2-compliance * ltp-commands-tests * ltp-ipc-tests * ltp-math-tests * ltp-syscalls-tests * network-basic-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-native/drivers * kselftest-vsyscall-mode-native/filesystems * kselftest-vsyscall-mode-native/net * kselftest-vsyscall-mode-none * kselftest-vsyscall-mode-none/drivers * kselftest-vsyscall-mode-none/filesystems * kselftest-vsyscall-mode-none/net * ssuite -- Linaro LKFT https://lkft.linaro.org
[PATCH V4] arm64/cpuinfo: Define HWCAP name arrays per their actual bit definitions
HWCAP name arrays (hwcap_str, compat_hwcap_str, compat_hwcap2_str) that are
scanned for /proc/cpuinfo are detached from their bit definitions making it
vulnerable and difficult to correlate. It is also bit problematic because
during /proc/cpuinfo dump these arrays get traversed sequentially assuming
they reflect and match actual HWCAP bit sequence, to test various features
for a given CPU. This redefines name arrays per their HWCAP bit definitions
. It also warns after detecting any feature which is not expected on arm64.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Brown
Cc: Dave Martin
Cc: Ard Biesheuvel
Cc: Mark Rutland
Cc: Suzuki K Poulose
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
This applies on 5.9-rc4
Mark, since the patch has changed I have dropped your Acked-by: tag. Are you
happy to give a new one ?
Changes in V4:
- Unified all three HWCAP array traversal per Will
Changes in V3: (https://patchwork.kernel.org/patch/11718113/)
- Moved name arrays to (arch/arm64/kernel/cpuinfo.c) to prevent a build warning
- Replaced string values with NULL for all compat features not possible on arm64
- Changed compat_hwcap_str[] iteration on size as some NULL values are expected
- Warn once after detecting any feature on arm64 that is not expected
Changes in V2: (https://patchwork.kernel.org/patch/11533755/)
- Defined COMPAT_KERNEL_HWCAP[2] and updated the name arrays per Mark
- Updated the commit message as required
Changes in V1: (https://patchwork.kernel.org/patch/11532945/)
arch/arm64/include/asm/hwcap.h | 9 ++
arch/arm64/kernel/cpuinfo.c| 176 +
2 files changed, 101 insertions(+), 84 deletions(-)
diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
index 22f73fe09030..6493a4c63a2f 100644
--- a/arch/arm64/include/asm/hwcap.h
+++ b/arch/arm64/include/asm/hwcap.h
@@ -8,18 +8,27 @@
#include
#include
+#define COMPAT_HWCAP_SWP (1 << 0)
#define COMPAT_HWCAP_HALF (1 << 1)
#define COMPAT_HWCAP_THUMB (1 << 2)
+#define COMPAT_HWCAP_26BIT (1 << 3)
#define COMPAT_HWCAP_FAST_MULT (1 << 4)
+#define COMPAT_HWCAP_FPA (1 << 5)
#define COMPAT_HWCAP_VFP (1 << 6)
#define COMPAT_HWCAP_EDSP (1 << 7)
+#define COMPAT_HWCAP_JAVA (1 << 8)
+#define COMPAT_HWCAP_IWMMXT(1 << 9)
+#define COMPAT_HWCAP_CRUNCH(1 << 10)
+#define COMPAT_HWCAP_THUMBEE (1 << 11)
#define COMPAT_HWCAP_NEON (1 << 12)
#define COMPAT_HWCAP_VFPv3 (1 << 13)
+#define COMPAT_HWCAP_VFPV3D16 (1 << 14)
#define COMPAT_HWCAP_TLS (1 << 15)
#define COMPAT_HWCAP_VFPv4 (1 << 16)
#define COMPAT_HWCAP_IDIVA (1 << 17)
#define COMPAT_HWCAP_IDIVT (1 << 18)
#define COMPAT_HWCAP_IDIV (COMPAT_HWCAP_IDIVA|COMPAT_HWCAP_IDIVT)
+#define COMPAT_HWCAP_VFPD32(1 << 19)
#define COMPAT_HWCAP_LPAE (1 << 20)
#define COMPAT_HWCAP_EVTSTRM (1 << 21)
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index d0076c2159e6..04640f5f9f0f 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -43,94 +43,93 @@ static const char *icache_policy_str[] = {
unsigned long __icache_flags;
static const char *const hwcap_str[] = {
- "fp",
- "asimd",
- "evtstrm",
- "aes",
- "pmull",
- "sha1",
- "sha2",
- "crc32",
- "atomics",
- "fphp",
- "asimdhp",
- "cpuid",
- "asimdrdm",
- "jscvt",
- "fcma",
- "lrcpc",
- "dcpop",
- "sha3",
- "sm3",
- "sm4",
- "asimddp",
- "sha512",
- "sve",
- "asimdfhm",
- "dit",
- "uscat",
- "ilrcpc",
- "flagm",
- "ssbs",
- "sb",
- "paca",
- "pacg",
- "dcpodp",
- "sve2",
- "sveaes",
- "svepmull",
- "svebitperm",
- "svesha3",
- "svesm4",
- "flagm2",
- "frint",
- "svei8mm",
- "svef32mm",
- "svef64mm",
- "svebf16",
- "i8mm",
- "bf16",
- "dgh",
- "rng",
- "bti",
+ [KERNEL_HWCAP_FP] = "fp",
+ [KERNEL_HWCAP_ASIMD]= "asimd",
+ [KERNEL_HWCAP_EVTSTRM] = "evtstrm",
+ [KERNEL_HWCAP_AES] = "aes",
+ [KERNEL_HWCAP_PMULL]= "pmull",
+ [KERNEL_HWCAP_SHA1] = "sha1",
+ [KERNEL_HWCAP_SHA2] = "sha2",
+ [KERNEL_HWCAP_CRC32]= "crc32",
+ [KERNEL_HWCAP_ATOMICS] = "atomics",
+ [KERNEL_HWCAP_FPHP] = "fphp",
+ [KERNEL_HWCAP_ASIMDHP] = "asimdhp",
+ [KERNEL_HWCAP_CPUID]= "cpuid",
+ [KERNEL_HWCAP_ASIMDRDM] = "asimdrdm",
+ [KERNEL_HWCAP_JSCVT]= "jscvt",
+ [KERNEL_HWCAP_FCMA] = "fcma",
+ [KERNEL_HWCAP_LRCPC]= "lrcpc",
+ [KERNEL_HWCAP_DCPOP]
Re: [PATCH 5.8 000/186] 5.8.8-rc1 review
On Tue, 8 Sep 2020 at 21:05, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.8.8 release. > There are 186 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 Thu, 10 Sep 2020 15:21:57 +. > 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.8.8-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.8.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.8.8-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.8.y git commit: 456fe9607f8f8a55179d2527598b8e90a2591e4d git describe: v5.8.7-187-g456fe9607f8f Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.8-oe/build/v5.8.7-187-g456fe9607f8f No regressions (compared to build v5.8.7) No fixes (compared to build v5.8.7) Ran 36239 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * build * igt-gpu-tools * install-android-platform-tools-r2600 * kselftest * kselftest/drivers * kselftest/filesystems * kselftest/net * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-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-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * v4l2-compliance * ltp-containers-tests * ltp-ipc-tests * ltp-tracing-tests * network-basic-tests * ltp-dio-tests * ltp-io-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-native/drivers * kselftest-vsyscall-mode-native/filesystems * kselftest-vsyscall-mode-native/net * kselftest-vsyscall-mode-none * kselftest-vsyscall-mode-none/drivers * kselftest-vsyscall-mode-none/filesystems * kselftest-vsyscall-mode-none/net * ssuite -- Linaro LKFT https://lkft.linaro.org
Re: kernel BUG at /usr/src/kernel/lib/dynamic_debug.c:267!
Hi Naresh, Thanks for reporting, it seems that you have run the kselftests/livepatch/test-livepatch.sh. Then, I think it is better to report to Livepatch maintainers too. (I Cc'd them) Thank you, On Wed, 9 Sep 2020 10:24:09 +0530 Naresh Kamboju wrote: > While testing livepatch test cases on x86_64 with Linux next 20200908 tag > kernel > this kernel BUG noticed several times. > > metadata: > git branch: master > git repo: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > git commit: dff9f829e5b0181d4ed9d35aa62d695292399b54 > git describe: next-20200908 > kernel-config: > http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkft/linux-next/853/config > > kernel BUG log, > -- > [ 634.063970] % rmmod test_klp_livepatch > [ 634.114787] test_klp_atomic_replace: this has been live patched > [ 634.121953] % echo 0 > > /sys/kernel/livepatch/test_klp_atomic_replace/enabled > [ 634.129391] livepatch: 'test_klp_atomic_replace': starting > unpatching transition > [ 634.143990] livepatch: 'test_klp_atomic_replace': unpatching complete > [ 634.156223] % rmmod test_klp_atomic_replace > [ 634.235451] [ cut here ] > [ 634.240314] kernel BUG at /usr/src/kernel/lib/dynamic_debug.c:267! > [ 634.246584] invalid opcode: [#1] SMP PTI > [ 634.250955] CPU: 0 PID: 12791 Comm: test-livepatch. Tainted: G > W K 5.9.0-rc4-next-20200908 #1 > [ 634.260615] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS > 2.2 05/23/2018 > [ 634.268007] RIP: 0010:ddebug_exec_query+0x77b/0xb90 > [ 634.272886] Code: 4c 89 ad 70 ff ff ff e9 db fb ff ff b8 03 00 00 > 00 e9 20 fb ff ff b8 02 00 00 00 e9 16 fb ff ff b8 01 00 00 00 e9 0c > fb ff ff <0f> 0b 31 c0 e9 03 fb ff ff 49 89 f4 48 89 f7 e9 78 f9 ff ff > 8b 15 > [ 634.291630] RSP: 0018:9f0c80a5bd18 EFLAGS: 00010246 > [ 634.296856] RAX: 003d RBX: RCX: > > [ 634.303987] RDX: 003d RSI: RDI: > 90db906583ec > [ 634.31] RBP: 9f0c80a5bde8 R08: 000a R09: > 003b > [ 634.318236] R10: 90db9261 R11: 0246 R12: > 90db906583ec > [ 634.325368] R13: be87cbc0 R14: R15: > 0004 > [ 634.332500] FS: 7fd37249a740() GS:90dbefa0() > knlGS: > [ 634.340578] CS: 0010 DS: ES: CR0: 80050033 > [ 634.346315] CR2: 00e6d00c CR3: 00026a4b8004 CR4: > 003706f0 > [ 634.353446] DR0: DR1: DR2: > > [ 634.360570] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 634.367693] Call Trace: > [ 634.370139] ? lock_acquire+0xa6/0x390 > [ 634.373892] ? __might_fault+0x34/0x80 > [ 634.377648] ddebug_exec_queries+0x6e/0x140 > [ 634.381831] ddebug_proc_write+0x4b/0xa0 > [ 634.385756] full_proxy_write+0x5f/0x90 > [ 634.389595] vfs_write+0xed/0x240 > [ 634.392915] ksys_write+0xad/0xf0 > [ 634.396233] ? syscall_trace_enter+0x17a/0x240 > [ 634.400670] __x64_sys_write+0x1a/0x20 > [ 634.404416] do_syscall_64+0x37/0x50 > [ 634.407993] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 634.413038] RIP: 0033:0x7fd371b84144 > [ 634.416617] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 > 00 00 00 00 66 90 48 8d 05 c1 e7 2c 00 8b 00 85 c0 75 13 b8 01 00 00 > 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 > f5 53 > [ 634.435362] RSP: 002b:7ffd19447658 EFLAGS: 0246 ORIG_RAX: > 0001 > [ 634.442928] RAX: ffda RBX: 00bc RCX: > 7fd371b84144 > [ 634.450059] RDX: 00bc RSI: 00e6cf70 RDI: > 0001 > [ 634.457181] RBP: 00e6cf70 R08: 00e9 R09: > > [ 634.464305] R10: 7ffd19447c48 R11: 0246 R12: > 7fd371e4e760 > [ 634.471429] R13: 00bc R14: 7fd371e49760 R15: > 00bc > [ 634.478559] Modules linked in: trace_printk sch_fq 8021q > iptable_filter xt_mark ip_tables cls_bpf sch_ingress veth algif_hash > x86_pkg_temp_thermal fuse [last unloaded: test_klp_atomic_replace] > [ 634.495695] ---[ end trace d04d7e11bd1458bf ]--- > [ 634.500333] RIP: 0010:ddebug_exec_query+0x77b/0xb90 > [ 634.505218] Code: 4c 89 ad 70 ff ff ff e9 db fb ff ff b8 03 00 00 > 00 e9 20 fb ff ff b8 02 00 00 00 e9 16 fb ff ff b8 01 00 00 00 e9 0c > fb ff ff <0f> 0b 31 c0 e9 03 fb ff ff 49 89 f4 48 89 f7 e9 78 f9 ff ff > 8b 15 > [ 634.523969] RSP: 0018:9f0c80a5bd18 EFLAGS: 00010246 > [ 634.529197] RAX: 003
linux-next: build failure after merge of the driver-core tree
Hi all,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
lib/test_firmware.c: In function 'trigger_request_platform_store':
lib/test_firmware.c:517:35: error: 'efi_embedded_fw_list' undeclared (first use
in this function); did you mean 'efi_embedded_fw_desc'?
517 | list_add(_embedded_fw.list, _embedded_fw_list);
| ^~~~
| efi_embedded_fw_desc
lib/test_firmware.c:517:35: note: each undeclared identifier is reported only
once for each function it appears in
lib/test_firmware.c:518:34: error: 'efi_embedded_fw_checked' undeclared (first
use in this function); did you mean 'saved_efi_embedded_fw_checked'?
518 | saved_efi_embedded_fw_checked = efi_embedded_fw_checked;
| ^~~
| saved_efi_embedded_fw_checked
Caused by commit
18efb2f9e897 ("test_firmware: Test platform fw loading on non-EFI systems")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpt4WlwUKydW.pgp
Description: OpenPGP digital signature
Re: [BUG RT] dump-capture kernel not executed for panic in interrupt context
Hi,
here is the new version of the patch based on Peters suggestion
It looks like it works fine. I added the BUG_ON to __crash_kexec,
because it is a precondition, that panic_cpu is set correctly, otherwise
the whole locking logic fails.
The mutex_trylock can still be used, because it is only in syscall
context and no interrupt context.
Jörg
---
kernel/kexec.c | 8 ++--
kernel/kexec_core.c | 86 +++--
kernel/kexec_file.c | 4 +-
kernel/kexec_internal.h | 6 ++-
4 files changed, 69 insertions(+), 35 deletions(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index f977786fe498..118a012aeac2 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -255,12 +255,12 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry,
unsigned long, nr_segments,
*
* KISS: always take the mutex.
*/
- if (!mutex_trylock(_mutex))
+ if (!kexec_trylock())
return -EBUSY;
result = do_kexec_load(entry, nr_segments, segments, flags);
- mutex_unlock(_mutex);
+ kexec_unlock();
return result;
}
@@ -309,12 +309,12 @@ COMPAT_SYSCALL_DEFINE4(kexec_load, compat_ulong_t,
entry,
*
* KISS: always take the mutex.
*/
- if (!mutex_trylock(_mutex))
+ if (!kexec_trylock())
return -EBUSY;
result = do_kexec_load(entry, nr_segments, ksegments, flags);
- mutex_unlock(_mutex);
+ kexec_unlock();
return result;
}
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index c19c0dad1ebe..71682a33b1ba 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -45,7 +45,7 @@
#include
#include "kexec_internal.h"
-DEFINE_MUTEX(kexec_mutex);
+static DEFINE_MUTEX(kexec_mutex);
/* Per cpu memory for storing cpu states in case of system crash. */
note_buf_t __percpu *crash_notes;
@@ -70,6 +70,43 @@ struct resource crashk_low_res = {
.desc = IORES_DESC_CRASH_KERNEL
};
+void kexec_lock(void)
+{
+ /*
+ * LOCK kexec_mutex cmpxchg(_cpu, INVALID, cpu)
+ * MB MB
+ * panic_cpu == INVALID kexec_mutex == LOCKED
+ *
+ * Ensures either we observe the cmpxchg, or crash_kernel() observes
+ * our lock acquisition.
+ */
+ mutex_lock(_mutex);
+ smp_mb();
+ atomic_cond_read_acquire(_cpu, VAL == PANIC_CPU_INVALID);
+}
+
+int kexec_trylock(void) {
+ if (!mutex_trylock(_mutex)) {
+ return 0;
+ }
+ smp_mb();
+ if (atomic_read(_cpu) != PANIC_CPU_INVALID) {
+ mutex_unlock(_mutex);
+ return 0;
+ }
+ return 1;
+}
+
+void kexec_unlock(void)
+{
+ mutex_unlock(_mutex);
+}
+
+int kexec_is_locked(void)
+{
+ return mutex_is_locked(_mutex);
+}
+
int kexec_should_crash(struct task_struct *p)
{
/*
@@ -943,24 +980,15 @@ int kexec_load_disabled;
*/
void __noclone __crash_kexec(struct pt_regs *regs)
{
- /* Take the kexec_mutex here to prevent sys_kexec_load
- * running on one cpu from replacing the crash kernel
- * we are using after a panic on a different cpu.
- *
- * If the crash kernel was not located in a fixed area
- * of memory the xchg(_crash_image) would be
- * sufficient. But since I reuse the memory...
- */
- if (mutex_trylock(_mutex)) {
- if (kexec_crash_image) {
- struct pt_regs fixed_regs;
-
- crash_setup_regs(_regs, regs);
- crash_save_vmcoreinfo();
- machine_crash_shutdown(_regs);
- machine_kexec(kexec_crash_image);
- }
- mutex_unlock(_mutex);
+ BUG_ON(atomic_read(_cpu) != raw_smp_processor_id());
+
+ if (!kexec_is_locked() && kexec_crash_image) {
+ struct pt_regs fixed_regs;
+
+ crash_setup_regs(_regs, regs);
+ crash_save_vmcoreinfo();
+ machine_crash_shutdown(_regs);
+ machine_kexec(kexec_crash_image);
}
}
STACK_FRAME_NON_STANDARD(__crash_kexec);
@@ -977,9 +1005,11 @@ void crash_kexec(struct pt_regs *regs)
this_cpu = raw_smp_processor_id();
old_cpu = atomic_cmpxchg(_cpu, PANIC_CPU_INVALID, this_cpu);
if (old_cpu == PANIC_CPU_INVALID) {
- /* This is the 1st CPU which comes here, so go ahead. */
- printk_safe_flush_on_panic();
- __crash_kexec(regs);
+ if (!kexec_is_locked()) {
+ /* This is the 1st CPU which comes here, so go ahead. */
+ printk_safe_flush_on_panic();
+ __crash_kexec(regs);
+ }
/*
* Reset panic_cpu to allow another panic()/crash_kexec()
@@ -993,10 +1023,10 @@ size_t crash_get_memory_size(void)
{
size_t size = 0;
- mutex_lock(_mutex);
+ kexec_lock();
if (crashk_res.end != crashk_res.start)
size = resource_size(_res);
- mutex_unlock(_mutex);
+ kexec_unlock();
return size;
}
@@ -1016,7 +1046,7 @@ int crash_shrink_memory(unsigned long new_size)
unsigned long old_size;
struct resource *ram_res;
- mutex_lock(_mutex);
+ kexec_lock();
if
Re: [ANNOUNCE] v5.9-rc3-rt3
On Wed, 2020-09-09 at 05:12 +0200, Mike Galbraith wrote: > On Wed, 2020-09-02 at 17:55 +0200, Sebastian Andrzej Siewior wrote: > > > > Known issues > > - It has been pointed out that due to changes to the printk code the > >internal buffer representation changed. This is only an issue if > > tools > >like `crash' are used to extract the printk buffer from a kernel > > memory > >image. > > Ouch. While installing -rt5 on lappy via nfs, -rt5 server box exploded > leaving nada in logs. I have a nifty crash dump of the event, but... After convincing crash (with club) that it didn't _really_ need a log_buf, nfs had nothing to do with the crash, it was nouveau. KERNEL: vmlinux-5.9.0.gf4d51df-rt5-rt.gz DUMPFILE: vmcore CPUS: 8 DATE: Wed Sep 9 04:41:24 2020 UPTIME: 00:08:10 LOAD AVERAGE: 3.17, 1.86, 0.99 TASKS: 715 NODENAME: homer RELEASE: 5.9.0.gf4d51df-rt5-rt VERSION: #1 SMP PREEMPT_RT Wed Sep 9 03:22:01 CEST 2020 MACHINE: x86_64 (3591 Mhz) MEMORY: 16 GB PANIC: "" PID: 2146 COMMAND: "X" TASK: 994c7fad [THREAD_INFO: 994c7fad] CPU: 0 STATE: TASK_RUNNING (PANIC) crash> bt -l PID: 2146 TASK: 994c7fad CPU: 0 COMMAND: "X" #0 [bfffc11a76c8] machine_kexec at b7064879 /backup/usr/local/src/kernel/linux-master-rt/./include/linux/ftrace.h: 792 #1 [bfffc11a7710] __crash_kexec at b7173622 /backup/usr/local/src/kernel/linux-master-rt/kernel/kexec_core.c: 963 #2 [bfffc11a77d0] crash_kexec at b7174920 /backup/usr/local/src/kernel/linux-master-rt/./arch/x86/include/asm/atomic.h: 41 #3 [bfffc11a77e0] oops_end at b702716f /backup/usr/local/src/kernel/linux-master-rt/arch/x86/kernel/dumpstack.c: 342 #4 [bfffc11a7800] exc_general_protection at b79a2fc6 /backup/usr/local/src/kernel/linux-master-rt/arch/x86/kernel/traps.c: 82 #5 [bfffc11a7890] asm_exc_general_protection at b7a00a1e /backup/usr/local/src/kernel/linux-master-rt/./arch/x86/include/asm/idtentry.h: 532 #6 [bfffc11a78a0] nvif_object_ctor at c07ee6a7 [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nvif/object.c: 280 #7 [bfffc11a7918] __kmalloc at b72eea12 /backup/usr/local/src/kernel/linux-master-rt/mm/slub.c: 261 #8 [bfffc11a7980] nvif_object_ctor at c07ee6a7 [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nvif/object.c: 280 #9 [bfffc11a79d0] nvif_mem_ctor_type at c07eef48 [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nvif/mem.c: 74 #10 [bfffc11a7aa8] nouveau_mem_vram at c08b5291 [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nouveau_mem.c: 155 #11 [bfffc11a7b10] nouveau_vram_manager_new at c08b594d [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nouveau_ttm.c: 76 #12 [bfffc11a7b30] ttm_bo_mem_space at c05af2ac [ttm] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/ttm/ttm_bo.c: 1065 #13 [bfffc11a7b88] ttm_bo_validate at c05afaca [ttm] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/ttm/ttm_bo.c: 1137 #14 [bfffc11a7c18] ttm_bo_init_reserved at c05afe70 [ttm] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/ttm/ttm_bo.c: 1330 #15 [bfffc11a7c60] ttm_bo_init at c05afff7 [ttm] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/ttm/ttm_bo.c: 1364 #16 [bfffc11a7cc8] nouveau_bo_init at c08b0f7b [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nouveau_bo.c: 317 #17 [bfffc11a7d38] nouveau_gem_new at c08b2f7b [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nouveau_gem.c: 206 #18 [bfffc11a7d70] nouveau_gem_ioctl_new at c08b3001 [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nouveau_gem.c: 272 #19 [bfffc11a7da0] drm_ioctl_kernel at c066f564 [drm] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/drm_ioctl.c: 793 #20 [bfffc11a7de0] drm_ioctl at c066f88e [drm] /backup/usr/local/src/kernel/linux-master-rt/./include/linux/uaccess.h: 168 #21 [bfffc11a7ed0] nouveau_drm_ioctl at c08abf56 [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nouveau_drm.c: 1163 #22 [bfffc11a7f08] __x64_sys_ioctl at b733255e /backup/usr/local/src/kernel/linux-master-rt/fs/ioctl.c: 49 #23 [bfffc11a7f40] do_syscall_64 at b79a25c3 /backup/usr/local/src/kernel/linux-master-rt/arch/x86/entry/common.c: 46 #24 [bfffc11a7f50] entry_SYSCALL_64_after_hwframe at b7a0008c
[rcu:rcu/next] BUILD SUCCESS d3f3d87569786ca7c672fe75af446ab346455682
randconfig-a001-20200907 x86_64 randconfig-a002-20200907 i386 randconfig-a004-20200908 i386 randconfig-a005-20200908 i386 randconfig-a006-20200908 i386 randconfig-a002-20200908 i386 randconfig-a001-20200908 i386 randconfig-a003-20200908 i386 randconfig-a004-20200907 i386 randconfig-a005-20200907 i386 randconfig-a006-20200907 i386 randconfig-a002-20200907 i386 randconfig-a003-20200907 i386 randconfig-a001-20200907 i386 randconfig-a004-20200909 i386 randconfig-a005-20200909 i386 randconfig-a006-20200909 i386 randconfig-a002-20200909 i386 randconfig-a001-20200909 i386 randconfig-a003-20200909 x86_64 randconfig-a013-20200908 x86_64 randconfig-a016-20200908 x86_64 randconfig-a011-20200908 x86_64 randconfig-a012-20200908 x86_64 randconfig-a015-20200908 x86_64 randconfig-a014-20200908 i386 randconfig-a016-20200907 i386 randconfig-a015-20200907 i386 randconfig-a011-20200907 i386 randconfig-a013-20200907 i386 randconfig-a014-20200907 i386 randconfig-a012-20200907 i386 randconfig-a016-20200908 i386 randconfig-a015-20200908 i386 randconfig-a011-20200908 i386 randconfig-a013-20200908 i386 randconfig-a014-20200908 i386 randconfig-a012-20200908 i386 randconfig-a016-20200909 i386 randconfig-a015-20200909 i386 randconfig-a011-20200909 i386 randconfig-a013-20200909 i386 randconfig-a014-20200909 i386 randconfig-a012-20200909 riscvallyesconfig riscv allnoconfig riscvallmodconfig riscv defconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a004-20200908 x86_64 randconfig-a006-20200908 x86_64 randconfig-a003-20200908 x86_64 randconfig-a001-20200908 x86_64 randconfig-a005-20200908 x86_64 randconfig-a002-20200908 x86_64 randconfig-a013-20200909 x86_64 randconfig-a016-20200909 x86_64 randconfig-a011-20200909 x86_64 randconfig-a012-20200909 x86_64 randconfig-a015-20200909 x86_64 randconfig-a014-20200909 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH] iommu/dma: Fix IOVA reserve dma ranges
Fix IOVA reserve failure for memory regions listed in dma-ranges in the
following cases.
- start address of memory region is 0x0.
- end address of a memory region is equal to start address of next memory
region.
Fixes: aadad097cd46f ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA
address")
Signed-off-by: Srinath Mannam
---
drivers/iommu/dma-iommu.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 5141d49a046b..0a3f67a4f9ae 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -213,14 +213,21 @@ static int iova_reserve_pci_windows(struct pci_dev *dev,
resource_list_for_each_entry(window, >dma_ranges) {
end = window->res->start - window->offset;
resv_iova:
+ if (end < start) {
+ /* dma_ranges list should be sorted */
+ dev_err(>dev, "Failed to reserve IOVA\n");
+ return -EINVAL;
+ }
+ /*
+* Skip the cases when start address of first memory region is
+* 0x0 and end address of one memory region and start address
+* of next memory region are equal. Reserve IOVA for rest of
+* addresses fall in between given memory ranges.
+*/
if (end > start) {
lo = iova_pfn(iovad, start);
hi = iova_pfn(iovad, end);
reserve_iova(iovad, lo, hi);
- } else {
- /* dma_ranges list should be sorted */
- dev_err(>dev, "Failed to reserve IOVA\n");
- return -EINVAL;
}
start = window->res->end - window->offset + 1;
--
2.17.1
INFO: rcu detected stall in cleanup_net (4)
Hello,
syzbot found the following issue on:
HEAD commit:59126901 Merge tag 'perf-tools-fixes-for-v5.9-2020-09-03' ..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12edb93590
kernel config: https://syzkaller.appspot.com/x/.config?x=3c5f6ce8d5b68299
dashboard link: https://syzkaller.appspot.com/bug?extid=8267241609ae8c23b248
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=157c7aa590
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13c92ef990
The issue was bisected to:
commit 5a781ccbd19e4664babcbe4b4ead7aa2b9283d22
Author: Vinicius Costa Gomes
Date: Sat Sep 29 00:59:43 2018 +
tc: Add support for configuring the taprio scheduler
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12f2424590
console output: https://syzkaller.appspot.com/x/log.txt?x=16f2424590
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8267241609ae8c23b...@syzkaller.appspotmail.com
Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler")
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu:1-...0: (1 GPs behind) idle=2e2/1/0x4000 softirq=8639/8646
fqs=5250
(detected by 0, t=10502 jiffies, g=10573, q=113)
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 2516 Comm: kworker/u4:4 Not tainted 5.9.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Workqueue: netns cleanup_net
RIP: 0010:__rb_erase_augmented include/linux/rbtree_augmented.h:201 [inline]
RIP: 0010:rb_erase+0x0/0x1210 lib/rbtree.c:443
Code: 08 4c 8b 04 24 e9 1f f6 ff ff e8 fb f1 00 fe 48 8b 54 24 08 4c 8b 04 24
e9 f7 f5 ff ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 <48> b8 00 00 00 00 00 fc
ff df 41 57 49 89 f7 41 56 41 55 49 89 fd
RSP: 0018:c9da8db8 EFLAGS: 0046
RAX: 00010002 RBX: 88808ed3fb40 RCX: 111015ce4f13
RDX: 88809fb66540 RSI: 8880ae727890 RDI: 88808ed3fb40
RBP: 8880ae727890 R08: R09: 8ab2640f
R10: 888099a68400 R11: 0001 R12: 8880ae727898
R13: 8880ae727840 R14: 88808ed3fb40 R15: dc00
FS: () GS:8880ae70() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 2610 CR3: 09a8d000 CR4: 001506e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
rb_erase_cached include/linux/rbtree.h:149 [inline]
timerqueue_del+0x7f/0x140 lib/timerqueue.c:67
__remove_hrtimer kernel/time/hrtimer.c:1001 [inline]
__run_hrtimer kernel/time/hrtimer.c:1504 [inline]
__hrtimer_run_queues+0x518/0xfc0 kernel/time/hrtimer.c:1588
hrtimer_interrupt+0x32a/0x930 kernel/time/hrtimer.c:1650
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1080 [inline]
__sysvec_apic_timer_interrupt+0x142/0x5e0 arch/x86/kernel/apic/apic.c:1097
asm_call_on_stack+0xf/0x20 arch/x86/entry/entry_64.S:706
__run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline]
run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline]
sysvec_apic_timer_interrupt+0xb2/0xf0 arch/x86/kernel/apic/apic.c:1091
asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:581
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:770 [inline]
RIP: 0010:console_unlock+0xb4a/0xe60 kernel/printk/printk.c:2509
Code: 89 48 c1 e8 03 42 80 3c 38 00 0f 85 18 03 00 00 48 83 3d a0 f8 58 08 00
0f 84 90 01 00 00 e8 4d 07 17 00 48 8b 7c 24 30 57 9d <0f> 1f 44 00 00 8b 5c 24
64 31 ff 89 de e8 b4 03 17 00 85 db 0f 84
RSP: 0018:c90008797280 EFLAGS: 0293
RAX: RBX: 0200 RCX: 0006
RDX: 88809fb66540 RSI: 815d43b3 RDI: 0293
RBP: R08: 0001 R09: 8c5f49e7
R10: fbfff18be93c R11: 000808e8 R12: 84c29820
R13: 0073 R14: 8a3cb4b0 R15: dc00
vprintk_emit+0x2ff/0x740 kernel/printk/printk.c:2029
dev_vprintk_emit+0x3eb/0x436 drivers/base/core.c:4133
dev_printk_emit+0xba/0xf1 drivers/base/core.c:4144
__netdev_printk+0x1c6/0x27a net/core/dev.c:10749
netdev_info+0xd7/0x109 net/core/dev.c:10804
nsim_udp_tunnel_unset_port.cold+0x179/0x1c8
drivers/net/netdevsim/udp_tunnels.c:59
udp_tunnel_nic_device_sync_one net/ipv4/udp_tunnel_nic.c:224 [inline]
udp_tunnel_nic_device_sync_by_port net/ipv4/udp_tunnel_nic.c:245 [inline]
__udp_tunnel_nic_device_sync.part.0+0xa50/0xcb0 net/ipv4/udp_tunnel_nic.c:288
__udp_tunnel_nic_device_sync net/ipv4/udp_tunnel_nic.c:282 [inline]
udp_tunnel_nic_flush+0x24c/0x560 net/ipv4/udp_tunnel_nic.c:665
udp_tunnel_nic_unregister net/ipv4/udp_tunnel_nic.c:791 [inline]
udp_tunnel_nic_netdevice_event+0x7c5/0xfcf
Re: [PATCH v5 00/21] kprobes: Unify kretprobe trampoline handlers and make kretprobe lockless
On Wed, 9 Sep 2020 00:09:23 +0900 Masami Hiramatsu wrote: > > > Of course make it lockless then warning is gone. > > > But even without the lockless patch, this warning can be false-positive > > > because we prohibit nested kprobe call, right? > > > > Yes, because the actual nesting is avoided by kprobe_busy, but lockdep > > can't tell. Lockdep sees a regular lock user and an in-nmi lock user and > > figures that's a bad combination. Hmm, what about introducing new LOCK_USED_KPROBE bit, which will be set if the lock is accessed when the current_kprobe is set (including kprobe_busy)? This means it is in the kprobe user-handler context. If we access the lock always in the kprobes context, it is never nested. Thank you, -- Masami Hiramatsu
Re: [RFC PATCH 1/2] lib/string: Disable instrumentation
On Tue, Sep 8, 2020 at 8:40 PM Arvind Sankar wrote: > > On Tue, Sep 08, 2020 at 10:21:32AM -0700, Kees Cook wrote: > > On Tue, Sep 08, 2020 at 11:39:11AM +0200, Marco Elver wrote: > > > On Sun, 6 Sep 2020 at 00:23, Arvind Sankar wrote: > > > > > > > > String functions can be useful in early boot, but using instrumented > > > > versions can be problematic: eg on x86, some of the early boot code is > > > > executing out of an identity mapping rather than the kernel virtual > > > > addresses. Accessing any global variables at this point will lead to a > > > > crash. > > > > > > > > > > Ouch. > > > > > > We have found manifestations of bugs in lib/string.c functions, e.g.: > > > > > > https://groups.google.com/forum/#!msg/syzkaller-bugs/atbKWcFqE9s/x7AtoVoBAgAJ > > > > > > https://groups.google.com/forum/#!msg/syzkaller-bugs/iGBUm-FDhkM/chl05uEgBAAJ > > > > > > Is there any way this can be avoided? > > > > Agreed: I would like to keep this instrumentation; it's a common place > > to find bugs, security issues, etc. > > > > -- > > Kees Cook > > Ok, understood. I'll revise to open-code the strscpy instead. > > Is instrumentation supported on x86-32? load_ucode_bsp() on 32-bit is > called before paging is enabled, and load_ucode_bsp() itself, along with > eg lib/earlycpio and lib/string that it uses, don't have anything to > disable instrumentation. kcov, kasan, kcsan are unsupported already on > 32-bit, but the others like gcov and PROFILE_ALL_BRANCHES look like they > would just cause a crash if microcode loading is enabled. I agree we should not disable instrumentation of such common functions. Instead of open-coding these functions maybe we could produce both instrumented and non-instrumented versions from the same source implementation. Namely, place implementation in a header function with always_inline attribute and include it from 2 source files, one with instrumentation enabled and another with instrumentation disabled. This way we could produce strscpy (instrumented) and __strscpy (non-instrumented) from the same source.
Re: [PATCH v2 6/7] xen/balloon: try to merge system ram resources
On 08.09.20 22:10, David Hildenbrand wrote: Let's try to merge system ram resources we add, to minimize the number of resources in /proc/iomem. We don't care about the boundaries of individual chunks we added. Cc: Andrew Morton Cc: Michal Hocko Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Stefano Stabellini Cc: Roger Pau Monné Cc: Julien Grall Cc: Pankaj Gupta Cc: Baoquan He Cc: Wei Yang Signed-off-by: David Hildenbrand Reviewed-by: Juergen Gross Juergen --- drivers/xen/balloon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 7bac38764513d..b57b2067ecbfb 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -331,7 +331,7 @@ static enum bp_state reserve_additional_memory(void) mutex_unlock(_mutex); /* add_memory_resource() requires the device_hotplug lock */ lock_device_hotplug(); - rc = add_memory_resource(nid, resource, 0); + rc = add_memory_resource(nid, resource, MEMHP_MERGE_RESOURCE); unlock_device_hotplug(); mutex_lock(_mutex);
Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
On 08.09.20 22:10, David Hildenbrand wrote:
We soon want to pass flags, e.g., to mark added System RAM resources.
mergeable. Prepare for that.
This patch is based on a similar patch by Oscar Salvador:
https://lkml.kernel.org/r/20190625075227.15193-3-osalva...@suse.de
Acked-by: Wei Liu
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Dan Williams
Cc: Jason Gunthorpe
Cc: Pankaj Gupta
Cc: Baoquan He
Cc: Wei Yang
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Greg Kroah-Hartman
Cc: Vishal Verma
Cc: Dave Jiang
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Wei Liu
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Cc: David Hildenbrand
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: "Oliver O'Halloran"
Cc: Pingfan Liu
Cc: Nathan Lynch
Cc: Libor Pechacek
Cc: Anton Blanchard
Cc: Leonardo Bras
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-a...@vger.kernel.org
Cc: linux-nvd...@lists.01.org
Cc: linux-hyp...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: xen-de...@lists.xenproject.org
Signed-off-by: David Hildenbrand
Reviewed-by: Juergen Gross (Xen related part)
Juergen
---
arch/powerpc/platforms/powernv/memtrace.c | 2 +-
arch/powerpc/platforms/pseries/hotplug-memory.c | 2 +-
drivers/acpi/acpi_memhotplug.c | 2 +-
drivers/base/memory.c | 2 +-
drivers/dax/kmem.c | 2 +-
drivers/hv/hv_balloon.c | 2 +-
drivers/s390/char/sclp_cmd.c| 2 +-
drivers/virtio/virtio_mem.c | 2 +-
drivers/xen/balloon.c | 2 +-
include/linux/memory_hotplug.h | 10 ++
mm/memory_hotplug.c | 15 ---
11 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/memtrace.c
b/arch/powerpc/platforms/powernv/memtrace.c
index 13b369d2cc454..a7475d18c671c 100644
--- a/arch/powerpc/platforms/powernv/memtrace.c
+++ b/arch/powerpc/platforms/powernv/memtrace.c
@@ -224,7 +224,7 @@ static int memtrace_online(void)
ent->mem = 0;
}
- if (add_memory(ent->nid, ent->start, ent->size)) {
+ if (add_memory(ent->nid, ent->start, ent->size, 0)) {
pr_err("Failed to add trace memory to node %d\n",
ent->nid);
ret += 1;
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 5d545b78111f9..54a888ea7f751 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -606,7 +606,7 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
block_sz = memory_block_size_bytes();
/* Add the memory */
- rc = __add_memory(lmb->nid, lmb->base_addr, block_sz);
+ rc = __add_memory(lmb->nid, lmb->base_addr, block_sz, 0);
if (rc) {
invalidate_lmb_associativity_index(lmb);
return rc;
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index e294f44a78504..d91b3584d4b2b 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -207,7 +207,7 @@ static int acpi_memory_enable_device(struct
acpi_memory_device *mem_device)
if (node < 0)
node = memory_add_physaddr_to_nid(info->start_addr);
- result = __add_memory(node, info->start_addr, info->length);
+ result = __add_memory(node, info->start_addr, info->length, 0);
/*
* If the memory block has been used by the kernel, add_memory()
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 4db3c660de831..2287bcf86480e 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -432,7 +432,7 @@ static ssize_t probe_store(struct device *dev, struct
device_attribute *attr,
nid = memory_add_physaddr_to_nid(phys_addr);
ret = __add_memory(nid, phys_addr,
- MIN_MEMORY_BLOCK_SIZE * sections_per_block);
+ MIN_MEMORY_BLOCK_SIZE * sections_per_block, 0);
if (ret)
goto out;
diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index 7dcb2902e9b1b..8e66b28ef5bc6 100644
--- a/drivers/dax/kmem.c
+++ b/drivers/dax/kmem.c
@@ -95,7 +95,7 @@ int dev_dax_kmem_probe(struct dev_dax *dev_dax)
* this as RAM automatically.
*/
rc = add_memory_driver_managed(numa_node, range.start,
- range_len(), kmem_name);
+ range_len(), kmem_name, 0);
res->flags |= IORESOURCE_BUSY;
if (rc) {
[PATCH v2] mailbox: sti: fix struct description warnings
Fix formating of struct description to avoid warning highlighted
by W=1 compilation.
Signed-off-by: Alain Volmat
---
v2: fixes tag removed
drivers/mailbox/mailbox-sti.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mailbox/mailbox-sti.c b/drivers/mailbox/mailbox-sti.c
index 2baf69a0b81c..0f2bc09c364d 100644
--- a/drivers/mailbox/mailbox-sti.c
+++ b/drivers/mailbox/mailbox-sti.c
@@ -36,7 +36,7 @@
#define MBOX_BASE(mdev, inst) ((mdev)->base + ((inst) * 4))
/**
- * STi Mailbox device data
+ * struct sti_mbox_device - STi Mailbox device data
*
* An IP Mailbox is currently composed of 4 instances
* Each instance is currently composed of 32 channels
@@ -60,7 +60,7 @@ struct sti_mbox_device {
};
/**
- * STi Mailbox platform specific configuration
+ * struct sti_mbox_pdata - STi Mailbox platform specific configuration
*
* @num_inst: Maximum number of instances in one HW Mailbox
* @num_chan: Maximum number of channel per instance
@@ -71,7 +71,7 @@ struct sti_mbox_pdata {
};
/**
- * STi Mailbox allocated channel information
+ * struct sti_channel - STi Mailbox allocated channel information
*
* @mdev: Pointer to parent Mailbox device
* @instance: Instance number channel resides in
--
2.17.1
[PATCH v2] Documentation: kunit: Add naming guidelines
As discussed in [1], KUnit tests have hitherto not had a particularly consistent naming scheme. This adds documentation outlining how tests and test suites should be named, including how those names should be used in Kconfig entries and filenames. [1]: https://lore.kernel.org/linux-kselftest/202006141005.BA19A9D3@keescook/t/#u Signed-off-by: David Gow Reviewed-by: Kees Cook Reviewed-by: Brendan Higgins --- This is v2 of the KUnit test nomenclature guidelines. The guidelines have changed a bit in response to the discussion on the v1 thread which came about after plumbers. The major change is that the filename suffix is now "_test", with "_kunit" permitted where it conflicts. There are also some other exceptions carved out around existing tests, and very non-unit-like tests. Changelog: v2: - Rewrote the filename section to use "_test" as a suffix, and focus on module names, not filenames. - Add a motivating introduction, which also calls out existing tests and tests which cause problems when run automatically (long running, flaky tests) as reasons to avoid the guidelines. - Talk about including the type of test in the suite name, but only if theres an actual confict. (And update the example for this). v1: https://lore.kernel.org/linux-kselftest/20200702071416.1780522-1-david...@google.com/ - Fixed a bit of space/tab confusion in the index (Thanks, Randy) - Added some more examples (and some test case examples). - Added some examples of what not to call subsystems and suites. - No longer explicitly require "If unsure, put N" in Kconfig entries. - Minor formatting changes RFC: https://lore.kernel.org/linux-kselftest/20200620054944.167330-1-david...@google.com/T/#u - Initial version The result is a little bit weaker than the previous versions, but hopefully will let us get the areas we agree on down. -- David Documentation/dev-tools/kunit/index.rst | 1 + Documentation/dev-tools/kunit/style.rst | 207 2 files changed, 208 insertions(+) create mode 100644 Documentation/dev-tools/kunit/style.rst diff --git a/Documentation/dev-tools/kunit/index.rst b/Documentation/dev-tools/kunit/index.rst index e93606ecfb01..c234a3ab3c34 100644 --- a/Documentation/dev-tools/kunit/index.rst +++ b/Documentation/dev-tools/kunit/index.rst @@ -11,6 +11,7 @@ KUnit - Unit Testing for the Linux Kernel usage kunit-tool api/index + style faq What is KUnit? diff --git a/Documentation/dev-tools/kunit/style.rst b/Documentation/dev-tools/kunit/style.rst new file mode 100644 index ..c001ea1cd87d --- /dev/null +++ b/Documentation/dev-tools/kunit/style.rst @@ -0,0 +1,207 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +Test Style and Nomenclature +=== + +To make finding, writing, and using KUnit tests as simple as possible, it's +strongly encouraged that they are named and written according to the guidelines +below. While it's possible to write KUnit tests which do not follow these rules, +they may break some tooling, may conflict with other tests, and may not be run +automatically by testing systems. + +It's recommended that you only deviate from these guidelines when: + +1. Porting tests to KUnit which are already known with an existing name, or +2. Writing tests which would cause serious problems if automatically run (e.g., + nonderministically producing false positives or negatives, or taking an + extremely long time to run). + +Subsystems, Suites, and Tests += + +In order to make tests as easy to find as possible, they're grouped into suites +and subsystems. A test suite is a group of tests which test a related area of +the kernel, and a subsystem is a set of test suites which test different parts +of the same kernel subsystem or driver. + +Subsystems +-- + +Every test suite must belong to a subsystem. A subsystem is a collection of one +or more KUnit test suites which test the same driver or part of the kernel. A +rule of thumb is that a test subsystem should match a single kernel module. If +the code being tested can't be compiled as a module, in many cases the subsystem +should correspond to a directory in the source tree or an entry in the +MAINTAINERS file. If unsure, follow the conventions set by tests in similar +areas. + +Test subsystems should be named after the code being tested, either after the +module (wherever possible), or after the directory or files being tested. Test +subsystems should be named to avoid ambiguity where necessary. + +If a test subsystem name has multiple components, they should be separated by +underscores. *Do not* include "test" or "kunit" directly in the subsystem name +unless you are actually testing other tests or the kunit framework itself. + +Example subsystems could be: + +``ext4`` + Matches the module and filesystem name. +``apparmor`` + Matches the module name and LSM name. +``kasan`` + Common name
[PATCH v3 0/2] use SPDX also for GFDL documents
There are 438 document files that were licensed under the free versions of GNU Free Document License. The free versions are the one that doesn't contain invariant parts. The first patch adds the license files. As newer documents aren't supposed to use them without being dual-licensed with GPLv2, add them under LICENSE/deprecated. The second patch replaces a boilerplate text from ring-buffer-design.rst by the corresponding SPDX header. The other documents are all under Documentation/uapi/media. A separate patchset, to be merged via the linux-media tree will cover those. --- v3: - Added Valid-License-Identifier, SPDX_URL, Usage-Guide and License-Text meta-tags. Mauro Carvalho Chehab (2): LICENSE: add GFDL deprecated licenses docs: trace: ring-buffer-design.rst: use the new SPDX tag Documentation/trace/ring-buffer-design.rst | 26 +- LICENSES/deprecated/GFDL-1.1 | 377 +++ LICENSES/deprecated/GFDL-1.2 | 417 + 3 files changed, 795 insertions(+), 25 deletions(-) create mode 100644 LICENSES/deprecated/GFDL-1.1 create mode 100644 LICENSES/deprecated/GFDL-1.2 -- 2.26.2
[PATCH v3 2/2] docs: trace: ring-buffer-design.rst: use the new SPDX tag
SPDX v3.10 gained support for GFDL-1.2 with no invariant sections: https://spdx.org/licenses/GFDL-1.2-no-invariants-only.html Let's use it, instead of keeping a license text for this file. Signed-off-by: Mauro Carvalho Chehab --- Documentation/trace/ring-buffer-design.rst | 26 +- 1 file changed, 1 insertion(+), 25 deletions(-) diff --git a/Documentation/trace/ring-buffer-design.rst b/Documentation/trace/ring-buffer-design.rst index 9c8d22a53d6c..c5d77fcbb5bc 100644 --- a/Documentation/trace/ring-buffer-design.rst +++ b/Documentation/trace/ring-buffer-design.rst @@ -1,28 +1,4 @@ -.. This file is dual-licensed: you can use it either under the terms -.. of the GPL 2.0 or the GFDL 1.2 license, at your option. Note that this -.. dual licensing only applies to this file, and not this project as a -.. whole. -.. -.. a) This file is free software; you can redistribute it and/or -..modify it under the terms of the GNU General Public License as -..published by the Free Software Foundation version 2 of -..the License. -.. -..This file is distributed in the hope that it will be useful, -..but WITHOUT ANY WARRANTY; without even the implied warranty of -..MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -..GNU General Public License for more details. -.. -.. Or, alternatively, -.. -.. b) Permission is granted to copy, distribute and/or modify this -..document under the terms of the GNU Free Documentation License, -..Version 1.2 version published by the Free Software -..Foundation, with no Invariant Sections, no Front-Cover Texts -..and no Back-Cover Texts. A copy of the license is included at -..Documentation/userspace-api/media/fdl-appendix.rst. -.. -.. TODO: replace it to GPL-2.0 OR GFDL-1.2 WITH no-invariant-sections +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.2-no-invariants-only === Lockless Ring Buffer Design -- 2.26.2
[PATCH v3 1/2] LICENSE: add GFDL deprecated licenses
There are some files under Documentation which uses deprecated versions of GNU Free Documentation License, on both versions 1.1 and 1.2. On all cases, the license is with no Invariant Sections, Front-Cover Texts or Back-Cover Texts. Add the text file for them, as we'll start using SPDX for those. Signed-off-by: Mauro Carvalho Chehab --- LICENSES/deprecated/GFDL-1.1 | 377 +++ LICENSES/deprecated/GFDL-1.2 | 417 +++ 2 files changed, 794 insertions(+) create mode 100644 LICENSES/deprecated/GFDL-1.1 create mode 100644 LICENSES/deprecated/GFDL-1.2 diff --git a/LICENSES/deprecated/GFDL-1.1 b/LICENSES/deprecated/GFDL-1.1 new file mode 100644 index ..ae62699ab62c --- /dev/null +++ b/LICENSES/deprecated/GFDL-1.1 @@ -0,0 +1,377 @@ +Valid-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later +Valid-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-only +Valid-License-Identifier: GFDL-1.1-no-invariants-or-later +Valid-License-Identifier: GFDL-1.1-no-invariants-only +SPDX-URL: https://spdx.org/licenses/GFDL-1.1-no-invariants-or-later.html +Usage-Guide: + The GNU Free Documentation License should only be used without + Invariant Sections, Front-Cover Texts or Back-Cover Texts. + It should not be used for new documents, except when they are + part of sections that are already using it (notably, the + userspace-api media documentation). + To use the license in source code, put the following SPDX tag/value pair + into a comment according to the placement guidelines in the licensing + rules documentation: +SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later + or +SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-only + or +SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later + or +SPDX-License-Identifier: GFDL-1.1-no-invariants-only +License-Text: +GNU Free Documentation License + Version 1.1, March 2000 + + Copyright (C) 2000 Free Software Foundation, Inc. + 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + +0. PREAMBLE + +The purpose of this License is to make a manual, textbook, or other +written document "free" in the sense of freedom: to assure everyone +the effective freedom to copy and redistribute it, with or without +modifying it, either commercially or noncommercially. Secondarily, +this License preserves for the author and publisher a way to get +credit for their work, while not being considered responsible for +modifications made by others. + +This License is a kind of "copyleft", which means that derivative +works of the document must themselves be free in the same sense. It +complements the GNU General Public License, which is a copyleft +license designed for free software. + +We have designed this License in order to use it for manuals for free +software, because free software needs free documentation: a free +program should come with manuals providing the same freedoms that the +software does. But this License is not limited to software manuals; +it can be used for any textual work, regardless of subject matter or +whether it is published as a printed book. We recommend this License +principally for works whose purpose is instruction or reference. + + +1. APPLICABILITY AND DEFINITIONS + +This License applies to any manual or other work that contains a +notice placed by the copyright holder saying it can be distributed +under the terms of this License. The "Document", below, refers to any +such manual or work. Any member of the public is a licensee, and is +addressed as "you". + +A "Modified Version" of the Document means any work containing the +Document or a portion of it, either copied verbatim, or with +modifications and/or translated into another language. + +A "Secondary Section" is a named appendix or a front-matter section of +the Document that deals exclusively with the relationship of the +publishers or authors of the Document to the Document's overall subject +(or to related matters) and contains nothing that could fall directly +within that overall subject. (For example, if the Document is in part a +textbook of mathematics, a Secondary Section may not explain any +mathematics.) The relationship could be a matter of historical +connection with the subject or with related matters, or of legal, +commercial, philosophical, ethical or political position regarding +them. + +The "Invariant Sections" are certain Secondary Sections whose titles +are designated, as being those of Invariant Sections, in the notice +that says that the Document is released under this License. + +The "Cover Texts" are certain short passages of text that are listed, +as Front-Cover Texts or Back-Cover Texts, in the notice that says that +the Document is released under this License. + +A "Transparent"
Re: [ANNOUNCE] v5.9-rc3-rt3
On Wed, 2020-09-09 at 05:12 +0200, Mike Galbraith wrote: > On Wed, 2020-09-02 at 17:55 +0200, Sebastian Andrzej Siewior wrote: > > > > Known issues > > - It has been pointed out that due to changes to the printk code the > >internal buffer representation changed. This is only an issue if > > tools > >like `crash' are used to extract the printk buffer from a kernel > > memory > >image. > > Ouch. While installing -rt5 on lappy via nfs, -rt5 server box exploded > leaving nada in logs. I have a nifty crash dump of the event, but... I backed out 1ce98b8a0a1..463463c6fa3f so crash will work again, but haven't as yet been able to convince box to explode. Hohum, I'll give it some time. Lockdep did repeat dirtying of its diaper though, on both lappy and desktop boxen at roughly the same uptime. [ 922.978106] BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! [ 922.978112] turning off the locking correctness validator. [ 922.978116] CPU: 2 PID: 5837 Comm: kworker/u16:0 Kdump: loaded Tainted: G S E 5.9.0.gf4d51df-rt5-rt #3 [ 922.978120] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C 09/23/2013 [ 922.978127] Workqueue: writeback wb_workfn (flush-8:48) [ 922.978131] Call Trace: [ 922.978138] dump_stack+0x77/0x9b [ 922.978143] validate_chain+0xf60/0x1230 [ 922.978147] __lock_acquire+0x880/0xbf0 [ 922.978151] lock_acquire+0x92/0x3f0 [ 922.978155] ? rt_spin_lock_slowlock_locked+0x5d/0x2c0 [ 922.978160] _raw_spin_lock+0x2f/0x40 [ 922.978163] ? rt_spin_lock_slowlock_locked+0x5d/0x2c0 [ 922.978169] rt_spin_lock_slowlock_locked+0x5d/0x2c0 [ 922.978173] __read_rt_lock+0x97/0xc0 [ 922.978194] ext4_es_lookup_extent+0x4f/0x410 [ext4] [ 922.978205] ext4_map_blocks+0x50/0x530 [ext4] [ 922.978209] ? kmem_cache_alloc+0x636/0x8b0 [ 922.978220] ext4_writepages+0xa2c/0x1330 [ext4] [ 922.978228] ? do_writepages+0x3c/0xe0 [ 922.978231] do_writepages+0x3c/0xe0 [ 922.978236] ? __writeback_single_inode+0x62/0x890 [ 922.978240] __writeback_single_inode+0x62/0x890 [ 922.978244] writeback_sb_inodes+0x217/0x580 [ 922.978250] __writeback_inodes_wb+0x5d/0xd0 [ 922.978254] wb_writeback+0x28c/0x620 [ 922.978259] ? wb_workfn+0x2bc/0x7f0 [ 922.978262] wb_workfn+0x2bc/0x7f0 [ 922.978266] ? lock_acquire+0x92/0x3f0 [ 922.978270] ? process_one_work+0x1fa/0x730 [ 922.978274] ? process_one_work+0x284/0x730 [ 922.978278] ? process_one_work+0x251/0x730 [ 922.978281] process_one_work+0x284/0x730 [ 922.978285] ? _raw_spin_lock_irq+0x16/0x50 [ 922.978289] ? process_one_work+0x730/0x730 [ 922.978293] worker_thread+0x39/0x3f0 [ 922.978297] ? process_one_work+0x730/0x730 [ 922.978300] kthread+0x171/0x190 [ 922.978304] ? kthread_park+0x90/0x90 [ 922.978308] ret_from_fork+0x1f/0x30
Re: [PATCH v2 1/2] scsi: ufs: Abort tasks before clear them from doorbell
I can't reconcile this hunk:
On Wed, 2020-09-02 at 19:24 -0700, Can Guo wrote:
> @@ -6504,6 +6505,80 @@ static void ufshcd_set_req_abort_skip(struct
> ufs_hba *hba, unsigned long bitmap)
> * issued. To avoid that, first issue UFS_QUERY_TASK to check if the
> command is
> * really issued and then try to abort it.
> *
> + * Returns zero on success, non-zero on failure
> + */
> +static int ufshcd_try_to_abort_task(struct ufs_hba *hba, int tag)
> +{
> + struct ufshcd_lrb *lrbp = >lrb[tag];
> + int err = 0;
> + int poll_cnt;
> + u8 resp = 0xF;
> + u32 reg;
> +
> + for (poll_cnt = 100; poll_cnt; poll_cnt--) {
> + err = ufshcd_issue_tm_cmd(hba, lrbp->lun, lrbp-
> >task_tag,
> + UFS_QUERY_TASK, );
> + if (!err && resp ==
> UPIU_TASK_MANAGEMENT_FUNC_SUCCEEDED) {
> + /* cmd pending in the device */
> + dev_err(hba->dev, "%s: cmd pending in the
> device. tag = %d\n",
> + __func__, tag);
> + break;
> + } else if (!err && resp ==
> UPIU_TASK_MANAGEMENT_FUNC_COMPL) {
> + /*
> + * cmd not pending in the device, check if
> it is
> + * in transition.
> + */
> + dev_err(hba->dev, "%s: cmd at tag %d not
> pending in the device.\n",
> + __func__, tag);
> + reg = ufshcd_readl(hba,
> REG_UTP_TRANSFER_REQ_DOOR_BELL);
> + if (reg & (1 << tag)) {
> + /* sleep for max. 200us to stabilize
> */
> + usleep_range(100, 200);
> + continue;
> + }
> + /* command completed already */
> + dev_err(hba->dev, "%s: cmd at tag %d
> successfully cleared from DB.\n",
> + __func__, tag);
> + goto out;
> + } else {
> + dev_err(hba->dev,
> + "%s: no response from device. tag =
> %d, err %d\n",
> + __func__, tag, err);
> + if (!err)
> + err = resp; /* service response
> error */
> + goto out;
> + }
> + }
> +
> + if (!poll_cnt) {
> + err = -EBUSY;
> + goto out;
> + }
> +
> + err = ufshcd_issue_tm_cmd(hba, lrbp->lun, lrbp->task_tag,
> + UFS_ABORT_TASK, );
> + if (err || resp != UPIU_TASK_MANAGEMENT_FUNC_COMPL) {
> + if (!err) {
> + err = resp; /* service response error */
> + dev_err(hba->dev, "%s: issued. tag = %d, err
> %d\n",
> + __func__, tag, err);
> + }
> + goto out;
> + }
> +
> + err = ufshcd_clear_cmd(hba, tag);
> + if (err)
> + dev_err(hba->dev, "%s: Failed clearing cmd at tag
> %d, err %d\n",
> + __func__, tag, err);
> +
> +out:
> + return err;
> +}
> +
> +/**
> + * ufshcd_abort - scsi host template eh_abort_handler callback
> + * @cmd: SCSI command pointer
> + *
> * Returns SUCCESS/FAILED
> */
> static int ufshcd_abort(struct scsi_cmnd *cmd)
> @@ -6513,8 +6588,6 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
> unsigned long flags;
> unsigned int tag;
> int err = 0;
> - int poll_cnt;
> - u8 resp = 0xF;
> struct ufshcd_lrb *lrbp;
> u32 reg;
>
> @@ -6583,63 +6656,9 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
> goto out;
> }
>
> - for (poll_cnt = 100; poll_cnt; poll_cnt--) {
> - err = ufshcd_issue_tm_cmd(hba, lrbp->lun, lrbp-
> >task_tag,
> - UFS_QUERY_TASK, );
> - if (!err && resp ==
> UPIU_TASK_MANAGEMENT_FUNC_SUCCEEDED) {
> - /* cmd pending in the device */
> - dev_err(hba->dev, "%s: cmd pending in the
> device. tag = %d\n",
> - __func__, tag);
> - break;
> - } else if (!err && resp ==
> UPIU_TASK_MANAGEMENT_FUNC_COMPL) {
> - /*
> - * cmd not pending in the device, check if
> it is
> - * in transition.
> - */
> - dev_err(hba->dev, "%s: cmd at tag %d not
> pending in the device.\n",
> - __func__, tag);
> - reg = ufshcd_readl(hba,
> REG_UTP_TRANSFER_REQ_DOOR_BELL);
> - if (reg & (1 << tag)) {
> - /* sleep for max. 200us to stabilize
> */
> - usleep_range(100, 200);
> - continue;
> - }
> - /* command completed already
Re: [PATCH 8/8] riscv: remove address space overrides using set_fs()
On Sun, 06 Sep 2020 22:58:25 PDT (-0700), Christoph Hellwig wrote:
Stop providing the possibility to override the address space using
set_fs() now that there is no need for that any more.
Signed-off-by: Christoph Hellwig
---
arch/riscv/Kconfig | 1 -
arch/riscv/include/asm/thread_info.h | 6 --
arch/riscv/include/asm/uaccess.h | 27 +--
arch/riscv/kernel/process.c | 1 -
4 files changed, 1 insertion(+), 34 deletions(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 460e3971a80fde..33dde87218ddab 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -86,7 +86,6 @@ config RISCV
select SPARSE_IRQ
select SYSCTL_EXCEPTION_TRACE
select THREAD_INFO_IN_TASK
- select SET_FS
select UACCESS_MEMCPY if !MMU
config ARCH_MMAP_RND_BITS_MIN
diff --git a/arch/riscv/include/asm/thread_info.h
b/arch/riscv/include/asm/thread_info.h
index 464a2bbc97ea33..a390711129de64 100644
--- a/arch/riscv/include/asm/thread_info.h
+++ b/arch/riscv/include/asm/thread_info.h
@@ -24,10 +24,6 @@
#include
#include
-typedef struct {
- unsigned long seg;
-} mm_segment_t;
-
/*
* low level task data that entry.S needs immediate access to
* - this struct should fit entirely inside of one cache line
@@ -39,7 +35,6 @@ typedef struct {
struct thread_info {
unsigned long flags; /* low level flags */
int preempt_count; /* 0=>preemptible, <0=>BUG */
- mm_segment_taddr_limit;
/*
* These stack pointers are overwritten on every system call or
* exception. SP is also saved to the stack it can be recovered when
@@ -59,7 +54,6 @@ struct thread_info {
{ \
.flags = 0,\
.preempt_count = INIT_PREEMPT_COUNT, \
- .addr_limit = KERNEL_DS,\
}
#endif /* !__ASSEMBLY__ */
diff --git a/arch/riscv/include/asm/uaccess.h b/arch/riscv/include/asm/uaccess.h
index 264e52fb62b143..c47e6b35c551f4 100644
--- a/arch/riscv/include/asm/uaccess.h
+++ b/arch/riscv/include/asm/uaccess.h
@@ -26,29 +26,6 @@
#define __disable_user_access()
\
__asm__ __volatile__ ("csrc sstatus, %0" : : "r" (SR_SUM) : "memory")
-/*
- * The fs value determines whether argument validity checking should be
- * performed or not. If get_fs() == USER_DS, checking is performed, with
- * get_fs() == KERNEL_DS, checking is bypassed.
- *
- * For historical reasons, these macros are grossly misnamed.
- */
-
-#define MAKE_MM_SEG(s) ((mm_segment_t) { (s) })
-
-#define KERNEL_DS MAKE_MM_SEG(~0UL)
-#define USER_DSMAKE_MM_SEG(TASK_SIZE)
-
-#define get_fs() (current_thread_info()->addr_limit)
-
-static inline void set_fs(mm_segment_t fs)
-{
- current_thread_info()->addr_limit = fs;
-}
-
-#define uaccess_kernel() (get_fs().seg == KERNEL_DS.seg)
-#define user_addr_max()(get_fs().seg)
-
/**
* access_ok: - Checks if a user space pointer is valid
* @addr: User space pointer to start of block to check
@@ -76,9 +53,7 @@ static inline void set_fs(mm_segment_t fs)
*/
static inline int __access_ok(unsigned long addr, unsigned long size)
{
- const mm_segment_t fs = get_fs();
-
- return size <= fs.seg && addr <= fs.seg - size;
+ return size <= TASK_SIZE && addr <= TASK_SIZE - size;
}
/*
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index 2b97c493427c9e..19225ec65db62f 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -84,7 +84,6 @@ void start_thread(struct pt_regs *regs, unsigned long pc,
}
regs->epc = pc;
regs->sp = sp;
- set_fs(USER_DS);
}
void flush_thread(void)
Reviewed-by: Palmer Dabbelt
Acked-by: Palmer Dabbelt
Re: [PATCH 7/8] riscv: implement __get_kernel_nofault and __put_user_nofault
On Sun, 06 Sep 2020 22:58:24 PDT (-0700), Christoph Hellwig wrote:
Implement the non-faulting kernel access helpers directly instead of
abusing the uaccess routines under set_fs(KERNEL_DS).
Signed-off-by: Christoph Hellwig
---
arch/riscv/include/asm/uaccess.h | 20
1 file changed, 20 insertions(+)
diff --git a/arch/riscv/include/asm/uaccess.h b/arch/riscv/include/asm/uaccess.h
index b67d1c616ec348..264e52fb62b143 100644
--- a/arch/riscv/include/asm/uaccess.h
+++ b/arch/riscv/include/asm/uaccess.h
@@ -486,6 +486,26 @@ unsigned long __must_check clear_user(void __user *to,
unsigned long n)
__ret; \
})
+#define HAVE_GET_KERNEL_NOFAULT
+
+#define __get_kernel_nofault(dst, src, type, err_label)
\
+do { \
+ long __kr_err; \
+ \
+ __get_user_nocheck(*((type *)(dst)), (type *)(src), __kr_err); \
+ if (unlikely(__kr_err)) \
+ goto err_label; \
+} while (0)
+
+#define __put_kernel_nofault(dst, src, type, err_label)
\
+do { \
+ long __kr_err; \
+ \
+ __put_user_nocheck(*((type *)(dst)), (type *)(src), __kr_err); \
+ if (unlikely(__kr_err)) \
+ goto err_label; \
+} while (0)
+
#else /* CONFIG_MMU */
#include
#endif /* CONFIG_MMU */
Reviewed-by: Palmer Dabbelt
Acked-by: Palmer Dabbelt
Re: [PATCH 6/8] riscv: refactor __get_user and __put_user
On Sun, 06 Sep 2020 22:58:23 PDT (-0700), Christoph Hellwig wrote:
Add new __get_user_nocheck and __put_user_nocheck that switch on the size
and call the actual inline assembly helpers, and move the uaccess enable
/ disable into the actual __get_user and __put_user. This prepares for
natively implementing __get_kernel_nofault and __put_kernel_nofault.
Also don't bother with the deprecated register keyword for the error
return.
Signed-off-by: Christoph Hellwig
---
arch/riscv/include/asm/uaccess.h | 94 ++--
1 file changed, 52 insertions(+), 42 deletions(-)
diff --git a/arch/riscv/include/asm/uaccess.h b/arch/riscv/include/asm/uaccess.h
index e8eedf22e90747..b67d1c616ec348 100644
--- a/arch/riscv/include/asm/uaccess.h
+++ b/arch/riscv/include/asm/uaccess.h
@@ -107,7 +107,6 @@ static inline int __access_ok(unsigned long addr, unsigned
long size)
do { \
uintptr_t __tmp;\
__typeof__(x) __x; \
- __enable_user_access(); \
__asm__ __volatile__ ( \
"1:\n"\
" " insn " %1, %3\n" \
@@ -125,7 +124,6 @@ do {
\
" .previous" \
: "+r" (err), "=" (__x), "=r" (__tmp) \
: "m" (*(ptr)), "i" (-EFAULT)); \
- __disable_user_access();\
(x) = __x; \
} while (0)
@@ -138,7 +136,6 @@ do {
\
u32 __user *__ptr = (u32 __user *)(ptr);\
u32 __lo, __hi; \
uintptr_t __tmp;\
- __enable_user_access(); \
__asm__ __volatile__ ( \
"1:\n"\
" lw %1, %4\n" \
@@ -162,12 +159,30 @@ do {
\
"=r" (__tmp) \
: "m" (__ptr[__LSW]), "m" (__ptr[__MSW]), \
"i" (-EFAULT)); \
- __disable_user_access();\
(x) = (__typeof__(x))((__typeof__((x)-(x)))(\
(((u64)__hi << 32) | __lo))); \
} while (0)
#endif /* CONFIG_64BIT */
+#define __get_user_nocheck(x, __gu_ptr, __gu_err) \
+do { \
+ switch (sizeof(*__gu_ptr)) {\
+ case 1: \
+ __get_user_asm("lb", (x), __gu_ptr, __gu_err);\
+ break; \
+ case 2: \
+ __get_user_asm("lh", (x), __gu_ptr, __gu_err);\
+ break; \
+ case 4: \
+ __get_user_asm("lw", (x), __gu_ptr, __gu_err);\
+ break; \
+ case 8: \
+ __get_user_8((x), __gu_ptr, __gu_err); \
+ break; \
+ default:\
+ BUILD_BUG();\
+ } \
+} while (0)
/**
* __get_user: - Get a simple variable from user space, with less checking.
@@ -191,25 +206,15 @@ do {
\
*/
#define __get_user(x, ptr) \
({ \
- register long __gu_err = 0; \
const __typeof__(*(ptr)) __user *__gu_ptr = (ptr); \
+ long __gu_err = 0; \
+ \
__chk_user_ptr(__gu_ptr); \
- switch (sizeof(*__gu_ptr)) {\
- case 1: \
- __get_user_asm("lb", (x), __gu_ptr, __gu_err);\
- break; \
Re: remove set_fs for riscv v2
On Sun, 06 Sep 2020 22:58:17 PDT (-0700), Christoph Hellwig wrote: Hi all, this series converts riscv to the new set_fs less world and is on top of this branch: https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/log/?h=base.set_fs The first four patches are general improvements and enablement for all nommu ports, and might make sense to merge through the above base branch. Seems like it to me. These won't work without the SET_FS code so I'm OK if you guys want to keep them all together. Otherwise I think I'd need to wait until the SET_FS stuff gets merged before taking any of these, which would be a bit of a headache. Thanks! Changes since v1: - implement __get_user_fn and __put_user_fn for the UACCESS_MEMCPY case and remove the small constant size optimizations in raw_copy_from_user and raw_copy_to_user - reshuffle the patch order a little Diffstat arch/riscv/Kconfig |2 arch/riscv/include/asm/thread_info.h |6 - arch/riscv/include/asm/uaccess.h | 177 +-- arch/riscv/kernel/process.c |1 arch/riscv/lib/Makefile |2 include/asm-generic/uaccess.h| 109 + include/linux/uaccess.h |4 7 files changed, 166 insertions(+), 135 deletions(-)
Re: [PATCH 5/8] riscv: use memcpy based uaccess for nommu again
On Sun, 06 Sep 2020 22:58:22 PDT (-0700), Christoph Hellwig wrote:
This reverts commit adccfb1a805ea84d2db38eb53032533279bdaa97.
Now that the generic uaccess by mempcy code handles unaligned addresses
the generic code can be used for all RISC-V CPUs.
Signed-off-by: Christoph Hellwig
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/uaccess.h | 36
arch/riscv/lib/Makefile | 2 +-
3 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 07d53044013ede..460e3971a80fde 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -87,6 +87,7 @@ config RISCV
select SYSCTL_EXCEPTION_TRACE
select THREAD_INFO_IN_TASK
select SET_FS
+ select UACCESS_MEMCPY if !MMU
config ARCH_MMAP_RND_BITS_MIN
default 18 if 64BIT
diff --git a/arch/riscv/include/asm/uaccess.h b/arch/riscv/include/asm/uaccess.h
index f56c66b3f5fe21..e8eedf22e90747 100644
--- a/arch/riscv/include/asm/uaccess.h
+++ b/arch/riscv/include/asm/uaccess.h
@@ -13,24 +13,6 @@
/*
* User space memory access functions
*/
-
-extern unsigned long __must_check __asm_copy_to_user(void __user *to,
- const void *from, unsigned long n);
-extern unsigned long __must_check __asm_copy_from_user(void *to,
- const void __user *from, unsigned long n);
-
-static inline unsigned long
-raw_copy_from_user(void *to, const void __user *from, unsigned long n)
-{
- return __asm_copy_from_user(to, from, n);
-}
-
-static inline unsigned long
-raw_copy_to_user(void __user *to, const void *from, unsigned long n)
-{
- return __asm_copy_to_user(to, from, n);
-}
-
#ifdef CONFIG_MMU
#include
#include
@@ -385,6 +367,24 @@ do {
\
-EFAULT;\
})
+
+unsigned long __must_check __asm_copy_to_user(void __user *to,
+ const void *from, unsigned long n);
+unsigned long __must_check __asm_copy_from_user(void *to,
+ const void __user *from, unsigned long n);
+
+static inline unsigned long
+raw_copy_from_user(void *to, const void __user *from, unsigned long n)
+{
+ return __asm_copy_from_user(to, from, n);
+}
+
+static inline unsigned long
+raw_copy_to_user(void __user *to, const void *from, unsigned long n)
+{
+ return __asm_copy_to_user(to, from, n);
+}
+
extern long strncpy_from_user(char *dest, const char __user *src, long count);
extern long __must_check strlen_user(const char __user *str);
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 0d0db80800c4ed..47e7a82044608d 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -2,5 +2,5 @@
lib-y += delay.o
lib-y += memcpy.o
lib-y += memset.o
-lib-y += uaccess.o
+lib-$(CONFIG_MMU) += uaccess.o
lib-$(CONFIG_64BIT)+= tishift.o
Reviewed-by: Palmer Dabbelt
Acked-by: Palmer Dabbelt
kernel BUG at /usr/src/kernel/lib/dynamic_debug.c:267!
While testing livepatch test cases on x86_64 with Linux next 20200908 tag kernel this kernel BUG noticed several times. metadata: git branch: master git repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git git commit: dff9f829e5b0181d4ed9d35aa62d695292399b54 git describe: next-20200908 kernel-config: http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkft/linux-next/853/config kernel BUG log, -- [ 634.063970] % rmmod test_klp_livepatch [ 634.114787] test_klp_atomic_replace: this has been live patched [ 634.121953] % echo 0 > /sys/kernel/livepatch/test_klp_atomic_replace/enabled [ 634.129391] livepatch: 'test_klp_atomic_replace': starting unpatching transition [ 634.143990] livepatch: 'test_klp_atomic_replace': unpatching complete [ 634.156223] % rmmod test_klp_atomic_replace [ 634.235451] [ cut here ] [ 634.240314] kernel BUG at /usr/src/kernel/lib/dynamic_debug.c:267! [ 634.246584] invalid opcode: [#1] SMP PTI [ 634.250955] CPU: 0 PID: 12791 Comm: test-livepatch. Tainted: G W K 5.9.0-rc4-next-20200908 #1 [ 634.260615] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS 2.2 05/23/2018 [ 634.268007] RIP: 0010:ddebug_exec_query+0x77b/0xb90 [ 634.272886] Code: 4c 89 ad 70 ff ff ff e9 db fb ff ff b8 03 00 00 00 e9 20 fb ff ff b8 02 00 00 00 e9 16 fb ff ff b8 01 00 00 00 e9 0c fb ff ff <0f> 0b 31 c0 e9 03 fb ff ff 49 89 f4 48 89 f7 e9 78 f9 ff ff 8b 15 [ 634.291630] RSP: 0018:9f0c80a5bd18 EFLAGS: 00010246 [ 634.296856] RAX: 003d RBX: RCX: [ 634.303987] RDX: 003d RSI: RDI: 90db906583ec [ 634.31] RBP: 9f0c80a5bde8 R08: 000a R09: 003b [ 634.318236] R10: 90db9261 R11: 0246 R12: 90db906583ec [ 634.325368] R13: be87cbc0 R14: R15: 0004 [ 634.332500] FS: 7fd37249a740() GS:90dbefa0() knlGS: [ 634.340578] CS: 0010 DS: ES: CR0: 80050033 [ 634.346315] CR2: 00e6d00c CR3: 00026a4b8004 CR4: 003706f0 [ 634.353446] DR0: DR1: DR2: [ 634.360570] DR3: DR6: fffe0ff0 DR7: 0400 [ 634.367693] Call Trace: [ 634.370139] ? lock_acquire+0xa6/0x390 [ 634.373892] ? __might_fault+0x34/0x80 [ 634.377648] ddebug_exec_queries+0x6e/0x140 [ 634.381831] ddebug_proc_write+0x4b/0xa0 [ 634.385756] full_proxy_write+0x5f/0x90 [ 634.389595] vfs_write+0xed/0x240 [ 634.392915] ksys_write+0xad/0xf0 [ 634.396233] ? syscall_trace_enter+0x17a/0x240 [ 634.400670] __x64_sys_write+0x1a/0x20 [ 634.404416] do_syscall_64+0x37/0x50 [ 634.407993] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 634.413038] RIP: 0033:0x7fd371b84144 [ 634.416617] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 c1 e7 2c 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53 [ 634.435362] RSP: 002b:7ffd19447658 EFLAGS: 0246 ORIG_RAX: 0001 [ 634.442928] RAX: ffda RBX: 00bc RCX: 7fd371b84144 [ 634.450059] RDX: 00bc RSI: 00e6cf70 RDI: 0001 [ 634.457181] RBP: 00e6cf70 R08: 00e9 R09: [ 634.464305] R10: 7ffd19447c48 R11: 0246 R12: 7fd371e4e760 [ 634.471429] R13: 00bc R14: 7fd371e49760 R15: 00bc [ 634.478559] Modules linked in: trace_printk sch_fq 8021q iptable_filter xt_mark ip_tables cls_bpf sch_ingress veth algif_hash x86_pkg_temp_thermal fuse [last unloaded: test_klp_atomic_replace] [ 634.495695] ---[ end trace d04d7e11bd1458bf ]--- [ 634.500333] RIP: 0010:ddebug_exec_query+0x77b/0xb90 [ 634.505218] Code: 4c 89 ad 70 ff ff ff e9 db fb ff ff b8 03 00 00 00 e9 20 fb ff ff b8 02 00 00 00 e9 16 fb ff ff b8 01 00 00 00 e9 0c fb ff ff <0f> 0b 31 c0 e9 03 fb ff ff 49 89 f4 48 89 f7 e9 78 f9 ff ff 8b 15 [ 634.523969] RSP: 0018:9f0c80a5bd18 EFLAGS: 00010246 [ 634.529197] RAX: 003d RBX: RCX: [ 634.536330] RDX: 003d RSI: RDI: 90db906583ec [ 634.543462] RBP: 9f0c80a5bde8 R08: 000a R09: 003b [ 634.550593] R10: 90db9261 R11: 0246 R12: 90db906583ec [ 634.557727] R13: be87cbc0 R14: R15: 0004 [ 634.564869] FS: 7fd37249a740() GS:90dbefa0() knlGS: [ 634.572953] CS: 0010 DS: ES: CR0: 80050033 [ 634.578699] CR2: 00e6d00c CR3: 00026a4b8004 CR4: 003706f0 [ 634.585829] DR0: DR1: DR2: [ 634.592964] DR3: DR6: fffe0ff0
[PATCH V2 1/2] arm64/mm: Change THP helpers to comply with generic MM semantics
pmd_present() and pmd_trans_huge() are expected to behave in the following
manner during various phases of a given PMD. It is derived from a previous
detailed discussion on this topic [1] and present THP documentation [2].
pmd_present(pmd):
- Returns true if pmd refers to system RAM with a valid pmd_page(pmd)
- Returns false if pmd refers to a migration or swap entry
pmd_trans_huge(pmd):
- Returns true if pmd refers to system RAM and is a trans huge mapping
-
| PMD states | pmd_present | pmd_trans_huge |
-
| Mapped | Yes | Yes |
-
| Splitting | Yes | Yes |
-
| Migration/Swap | No | No |
-
The problem:
PMD is first invalidated with pmdp_invalidate() before it's splitting. This
invalidation clears PMD_SECT_VALID as below.
PMD Split -> pmdp_invalidate() -> pmd_mkinvalid -> Clears PMD_SECT_VALID
Once PMD_SECT_VALID gets cleared, it results in pmd_present() return false
on the PMD entry. It will need another bit apart from PMD_SECT_VALID to re-
affirm pmd_present() as true during the THP split process. To comply with
above mentioned semantics, pmd_trans_huge() should also check pmd_present()
first before testing presence of an actual transparent huge mapping.
The solution:
Ideally PMD_TYPE_SECT should have been used here instead. But it shares the
bit position with PMD_SECT_VALID which is used for THP invalidation. Hence
it will not be there for pmd_present() check after pmdp_invalidate().
A new software defined PMD_PRESENT_INVALID (bit 59) can be set on the PMD
entry during invalidation which can help pmd_present() return true and in
recognizing the fact that it still points to memory.
This bit is transient. During the split process it will be overridden by a
page table page representing normal pages in place of erstwhile huge page.
Other pmdp_invalidate() callers always write a fresh PMD value on the entry
overriding this transient PMD_PRESENT_INVALID bit, which makes it safe.
[1]: https://lkml.org/lkml/2018/10/17/231
[2]: https://www.kernel.org/doc/Documentation/vm/transhuge.txt
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Suzuki Poulose
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Catalin Marinas
Signed-off-by: Anshuman Khandual
---
arch/arm64/include/asm/pgtable-prot.h | 7 ++
arch/arm64/include/asm/pgtable.h | 34 ---
2 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable-prot.h
b/arch/arm64/include/asm/pgtable-prot.h
index 4d867c6446c4..2df4b75fce3c 100644
--- a/arch/arm64/include/asm/pgtable-prot.h
+++ b/arch/arm64/include/asm/pgtable-prot.h
@@ -19,6 +19,13 @@
#define PTE_DEVMAP (_AT(pteval_t, 1) << 57)
#define PTE_PROT_NONE (_AT(pteval_t, 1) << 58) /* only when
!PTE_VALID */
+/*
+ * This bit indicates that the entry is present i.e. pmd_page()
+ * still points to a valid huge page in memory even if the pmd
+ * has been invalidated.
+ */
+#define PMD_PRESENT_INVALID(_AT(pteval_t, 1) << 59) /* only when
!PMD_SECT_VALID */
+
#ifndef __ASSEMBLY__
#include
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index d5d3fbe73953..d8258ae8fce0 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -145,6 +145,18 @@ static inline pte_t set_pte_bit(pte_t pte, pgprot_t prot)
return pte;
}
+static inline pmd_t clear_pmd_bit(pmd_t pmd, pgprot_t prot)
+{
+ pmd_val(pmd) &= ~pgprot_val(prot);
+ return pmd;
+}
+
+static inline pmd_t set_pmd_bit(pmd_t pmd, pgprot_t prot)
+{
+ pmd_val(pmd) |= pgprot_val(prot);
+ return pmd;
+}
+
static inline pte_t pte_wrprotect(pte_t pte)
{
pte = clear_pte_bit(pte, __pgprot(PTE_WRITE));
@@ -363,15 +375,24 @@ static inline int pmd_protnone(pmd_t pmd)
}
#endif
+#define pmd_present_invalid(pmd) (!!(pmd_val(pmd) & PMD_PRESENT_INVALID))
+
+static inline int pmd_present(pmd_t pmd)
+{
+ return pte_present(pmd_pte(pmd)) || pmd_present_invalid(pmd);
+}
+
/*
* THP definitions.
*/
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
-#define pmd_trans_huge(pmd)(pmd_val(pmd) && !(pmd_val(pmd) &
PMD_TABLE_BIT))
+static inline int pmd_trans_huge(pmd_t pmd)
+{
+ return pmd_val(pmd) && pmd_present(pmd) && !(pmd_val(pmd) &
PMD_TABLE_BIT);
+}
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
-#define pmd_present(pmd) pte_present(pmd_pte(pmd))
#define
[PATCH V2 0/2] arm64/mm: Enable THP migration
This series enables THP migration on arm64 via ARCH_ENABLE_THP_MIGRATION. But first this modifies all existing THP helpers like pmd_present() and pmd_trans_huge() etc per expected generic memory semantics as concluded from a previous discussion here. https://lkml.org/lkml/2018/10/9/220 This series is based on v5.9-rc4. Changes in V2: - Renamed clr_pmd_bit() as clear_pmd_bit() per Catalin - Updated in-code documentation per Catalin and Ralph - Updated commit message in the first patch per Catalin - Updated commit message in the second patch per Catalin - Added tags from Catalin Changes in V1: (https://patchwork.kernel.org/project/linux-mm/list/?series=333627) - Used new PMD_PRESENT_INVALID (bit 59) to represent invalidated PMD state per Catalin Changes in RFC V2: (https://patchwork.kernel.org/project/linux-mm/list/?series=302965) - Used PMD_TABLE_BIT to represent splitting PMD state per Catalin Changes in RFC V1: (https://patchwork.kernel.org/project/linux-mm/list/?series=138797) Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Rutland Cc: Marc Zyngier Cc: Suzuki Poulose Cc: Zi Yan Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Anshuman Khandual (2): arm64/mm: Change THP helpers to comply with generic MM semantics arm64/mm: Enable THP migration arch/arm64/Kconfig| 4 +++ arch/arm64/include/asm/pgtable-prot.h | 7 + arch/arm64/include/asm/pgtable.h | 39 --- 3 files changed, 47 insertions(+), 3 deletions(-) -- 2.20.1
[PATCH V2 2/2] arm64/mm: Enable THP migration
In certain page migration situations, a THP page can be migrated without
being split into it's constituent subpages. This saves time required to
split a THP and put it back together when required. But it also saves an
wider address range translation covered by a single TLB entry, reducing
future page fault costs.
A previous patch changed platform THP helpers per generic memory semantics,
clearing the path for THP migration support. This adds two more THP helpers
required to create PMD migration swap entries. Now enable THP migration via
ARCH_ENABLE_THP_MIGRATION.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Suzuki Poulose
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Catalin Marinas
Signed-off-by: Anshuman Khandual
---
arch/arm64/Kconfig | 4
arch/arm64/include/asm/pgtable.h | 5 +
2 files changed, 9 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6d232837cbee..e21b94061780 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1876,6 +1876,10 @@ config ARCH_ENABLE_HUGEPAGE_MIGRATION
def_bool y
depends on HUGETLB_PAGE && MIGRATION
+config ARCH_ENABLE_THP_MIGRATION
+ def_bool y
+ depends on TRANSPARENT_HUGEPAGE
+
menu "Power management options"
source "kernel/power/Kconfig"
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index d8258ae8fce0..bc68da9f5706 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -875,6 +875,11 @@ static inline pmd_t pmdp_establish(struct vm_area_struct
*vma,
#define __pte_to_swp_entry(pte)((swp_entry_t) { pte_val(pte) })
#define __swp_entry_to_pte(swp)((pte_t) { (swp).val })
+#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
+#define __pmd_to_swp_entry(pmd)((swp_entry_t) { pmd_val(pmd) })
+#define __swp_entry_to_pmd(swp)__pmd((swp).val)
+#endif /* CONFIG_ARCH_ENABLE_THP_MIGRATION */
+
/*
* Ensure that there are not more swap files than can be encoded in the kernel
* PTEs.
--
2.20.1
Re: KASAN: use-after-free Read in delete_partition
I am having difficulty actually reproducing the bug from the supplied C repro and .config. Perhaps it is some sort of race condition?
Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
On 08-09-20, 22:23, Jassi Brar wrote: > From the test case Sudeep last shared, the scmi usage on mhu doesn't > not even hit any bottleneck ... the test "failed" because of the too > small hardcoded timeout value. Otherwise the current code actually > shows better numbers. Its not important on why the test failed there, but the fact that there were requests in queue which have to be completed one by one and the last ones in the queue will always pay the penalty. > We need some synthetic tests to bring the limitation to the surface. I > agree that there may be such a test case, however fictitious. For that > reason, I am ok with the doorbell mode. > > I totally agree with one compat-string for one hardware. However, as > you said, unlike other device classes, the mailbox driver runs the > sumtotal of hardware and the remote firmware behaviour. Also the > implementations wouldn't share much, so I think a separate file+dt > will be better. > But I wanna get rid of this toothache that flares up > every season, so whatever. I can't agree more :) So to conclude the thread, if I have understood correctly, we are going to implement another doorbell driver for this hardware which will use a different compatible string and #mbox-cells value. I will try to refresh the bindings soon, which will be followed by the driver implementation. Thanks everyone. -- viresh
Question about STEP_DECOMPRESS_NOWQ
Hi Chao, I have a question about the below flag for decompression. STEP_DECOMPRESS_NOWQ, /* handle normal cluster data inplace */ According to the comment, you added this for using inplace decompression but inplace decompression mode is not being activated now, since we are setting STEP_DECOMPRESS right after bio_add_page(). if (bio_add_page(bio, page, blocksize, 0) < blocksize) goto submit_and_realloc; /* tag STEP_DECOMPRESS to handle IO in wq */ ctx = bio->bi_private; if (!(ctx->enabled_steps & (1 << STEP_DECOMPRESS))) ctx->enabled_steps |= 1 << STEP_DECOMPRESS; Did you mean to deactivate inplace decompression mode on purpose, since it had an issue? I am a little bit confused about this.
WARNING: suspicious RCU usage: race/events/tlb.h:57 suspicious rcu_dereference_check() usage!
While booting x86_64 with Linux next 20200908 tag kernel this warning
was noticed.
metadata:
git branch: master
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git commit: dff9f829e5b0181d4ed9d35aa62d695292399b54
git describe: next-20200908
kernel-config:
http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkft/linux-next/853/config
warning logs:
-
[ 18.874329] Freeing unused kernel image (rodata/data gap) memory: 2012K
[ 18.881107] Run /sbin/init as init process
[ 18.905611]
[ 18.907190] =
[ 18.911194] WARNING: suspicious RCU usage
[ 18.915199] 5.9.0-rc4-next-20200908 #1 Not tainted
[ 18.919982] -
[ 18.923984] /usr/src/kernel/include/trace/events/tlb.h:57
suspicious rcu_dereference_check() usage!
[ 18.933016]
[ 18.933016] other info that might help us debug this:
[ 18.933016]
[ 18.941006]
[ 18.941006] rcu_scheduler_active = 2, debug_locks = 1
[ 18.947523] RCU used illegally from extended quiescent state!
[ 18.953261] no locks held by swapper/2/0.
[ 18.957264]
[ 18.957264] stack backtrace:
[ 18.961619] CPU: 2 PID: 0 Comm: swapper/2 Not tainted
5.9.0-rc4-next-20200908 #1
[ 18.969007] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.2 05/23/2018
[ 18.976392] Call Trace:
[ 18.978844] dump_stack+0x7d/0x9f
[ 18.982158] lockdep_rcu_suspicious+0xce/0xf0
[ 18.986517] switch_mm_irqs_off+0x441/0x450
[ 18.990702] switch_mm+0x1b/0x50
[ 18.993936] leave_mm+0x34/0x40
[ 18.997082] acpi_idle_enter_bm+0x23/0x120
[ 19.001180] acpi_idle_enter+0x189/0x2a0
[ 19.005104] ? rcu_eqs_enter.constprop.85+0xb2/0x180
[ 19.010072] cpuidle_enter_state+0xa5/0x4b0
[ 19.015265] cpuidle_enter+0x2e/0x40
[ 19.015268] do_idle+0x226/0x2b0
[ 19.015273] cpu_startup_entry+0x1d/0x20
[ 19.015275] start_secondary+0x114/0x150
[ 19.029943] secondary_startup_64+0xb6/0xc0
[ 19.034141]
[ 19.034142] =
[ 19.034142] WARNING: suspicious RCU usage
[ 19.034142] 5.9.0-rc4-next-20200908 #1 Not tainted
[ 19.034143] -
[ 19.034143] /usr/src/kernel/include/trace/events/lock.h:37
suspicious rcu_dereference_check() usage!
[ 19.034143]
[ 19.034144] other info that might help us debug this:
[ 19.034144]
[ 19.034144]
[ 19.034145] rcu_scheduler_active = 2, debug_locks = 1
[ 19.034145] RCU used illegally from extended quiescent state!
[ 19.034146] no locks held by swapper/2/0.
[ 19.034146]
[ 19.034146] stack backtrace:
[ 19.034147] CPU: 2 PID: 0 Comm: swapper/2 Not tainted
5.9.0-rc4-next-20200908 #1
[ 19.034147] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.2 05/23/2018
[ 19.034147] Call Trace:
[ 19.034148] dump_stack+0x7d/0x9f
[ 19.034148] lockdep_rcu_suspicious+0xce/0xf0
[ 19.034148] lock_acquire+0x327/0x390
[ 19.034149] _raw_spin_lock+0x2f/0x40
[ 19.034149] ? vprintk_emit+0x78/0x2f0
[ 19.034149] vprintk_emit+0x78/0x2f0
[ 19.034149] vprintk_default+0x1f/0x30
[ 19.034150] vprintk_func+0x51/0xf0
[ 19.034150] printk+0x52/0x6e
[ 19.034150] ? __lock_acquire+0x32a/0x19f0
[ 19.034151] lockdep_rcu_suspicious+0x20/0xf0
[ 19.034151] switch_mm_irqs_off+0x441/0x450
[ 19.034151] switch_mm+0x1b/0x50
[ 19.034152] leave_mm+0x34/0x40
[ 19.034152] acpi_idle_enter_bm+0x23/0x120
[ 19.034152] acpi_idle_enter+0x189/0x2a0
[ 19.034153] ? rcu_eqs_enter.constprop.85+0xb2/0x180
[ 19.034153] cpuidle_enter_state+0xa5/0x4b0
[ 19.034153] cpuidle_enter+0x2e/0x40
[ 19.034154] do_idle+0x226/0x2b0
[ 19.034154] cpu_startup_entry+0x1d/0x20
[ 19.034154] start_secondary+0x114/0x150
[ 19.034155] secondary_startup_64+0xb6/0xc0
[ 19.034155]
[ 19.034155] =
[ 19.034156] WARNING: suspicious RCU usage
[ 19.034156] 5.9.0-rc4-next-20200908 #1 Not tainted
[ 19.034156] -
[ 19.034157] /usr/src/kernel/include/trace/events/lock.h:63
suspicious rcu_dereference_check() usage!
[ 19.034157]
[ 19.034157] other info that might help us debug this:
[ 19.034158]
[ 19.034158]
[ 19.034158] rcu_scheduler_active = 2, debug_locks = 1
[ 19.034159] RCU used illegally from extended quiescent state!
[ 19.034159] 1 lock held by swapper/2/0:
[ 19.034159] #0: bed25f58 (logbuf_lock){-...}-{2:2}, at:
vprintk_emit+0x78/0x2f0
[ 19.034161]
[ 19.034161] stack backtrace:
[ 19.034162] CPU: 2 PID: 0 Comm: swapper/2 Not tainted
5.9.0-rc4-next-20200908 #1
[ 19.034162] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.2 05/23/2018
[ 19.034162] Call Trace:
[ 19.034163] dump_stack+0x7d/0x9f
[ 19.034163] lockdep_rcu_suspicious+0xce/0xf0
[ 19.034163] ? vprintk_emit+0x9e/0x2f0
[ 19.034164] lock_release+0x246/0x270
[ 19.034164] _raw_spin_unlock+0x1a/0x30
[ 19.034164] vprintk_emit+0x9e/0x2f0
[ 19.034165] vprintk_default+0x1f/0x30
[ 19.034165
Re: [PATCH 5/7] cpufreq: qcom-hw: Use regmap for accessing hardware registers
On 08-09-20, 17:38, Amit Kucheria wrote: > On Tue, Sep 8, 2020 at 5:18 PM Amit Kucheria wrote: > > > > On Tue, Sep 8, 2020 at 4:48 PM Viresh Kumar wrote: > > > > > > On 08-09-20, 16:41, Manivannan Sadhasivam wrote: > > > > On 0908, Viresh Kumar wrote: > > > > > On 08-09-20, 13:27, Manivannan Sadhasivam wrote: > > > > > > Use regmap for accessing cpufreq registers in hardware. > > > > > > > > > > Why ? Please mention why a change is required in the log. > > > > > > > > > > > > > Only because it is recommended to use regmap for abstracting the hw > > > > access. > > > > > > Yes it can be very useful in abstracting the hw access in case of > > > busses like SPI/I2C, others, but in this case there is only one way of > > > doing it with the exact same registers. I am not sure it is worth it > > > here. FWIW, I have never played with regmaps personally, and so every > > > chance I can be wrong here. > > > > One could handle the reg offsets through a struct initialisation, but > > then you end up with lots of #defines for bitmasks and bits for each > > version of the IP. And the core code becomes a bit convoluted IMO, > > trying to handle the differences. > > > > regmap hides the differences of the bit positions and register offsets > > between several IP versions. Right and I agree that is another useful aspect of it which I missed mentioning. > > > > Moreover it handles the proper locking for us in the core (spinlock vs > > > > mutex). > > > > > > What locking do you need here ? > > > > Right, locking isn't the main reason here. > > Having said this, perhaps this patch can be held back for now, since > we're not yet using some of the features of regmap to abstract away > bit fields and such. > > We don't strictly need it for just different register offsets. Right, I just didn't understood why it was required currently as it wasn't all that complex at all. -- viresh
[PATCH net-next] net: dsa: b53: Report VLAN table occupancy via devlink
We already maintain an array of VLANs used by the switch so we can
simply iterate over it to report the occupancy via devlink.
Signed-off-by: Florian Fainelli
---
drivers/net/dsa/b53/b53_common.c | 59 ++--
drivers/net/dsa/b53/b53_priv.h | 1 +
drivers/net/dsa/bcm_sf2.c| 8 -
3 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 26fcff85d881..a1527665e817 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -977,6 +977,53 @@ int b53_get_sset_count(struct dsa_switch *ds, int port,
int sset)
}
EXPORT_SYMBOL(b53_get_sset_count);
+enum b53_devlink_resource_id {
+ B53_DEVLINK_PARMA_ID_VLAN_TABLE,
+};
+
+static u64 b53_devlink_vlan_table_get(void *priv)
+{
+ struct b53_device *dev = priv;
+ unsigned int i, count = 0;
+ struct b53_vlan *vl;
+
+ for (i = 0; i < dev->num_vlans; i++) {
+ vl = >vlans[i];
+ if (vl->members)
+ count++;
+ }
+
+ return count;
+}
+
+int b53_setup_devlink_resources(struct dsa_switch *ds)
+{
+ struct devlink_resource_size_params size_params;
+ struct b53_device *dev = ds->priv;
+ int err;
+
+ devlink_resource_size_params_init(_params, dev->num_vlans,
+ dev->num_vlans,
+ 1, DEVLINK_RESOURCE_UNIT_ENTRY);
+
+ err = dsa_devlink_resource_register(ds, "VLAN", dev->num_vlans,
+ B53_DEVLINK_PARMA_ID_VLAN_TABLE,
+ DEVLINK_RESOURCE_ID_PARENT_TOP,
+ _params);
+ if (err)
+ goto out;
+
+ dsa_devlink_resource_occ_get_register(ds,
+ B53_DEVLINK_PARMA_ID_VLAN_TABLE,
+ b53_devlink_vlan_table_get, dev);
+
+ return 0;
+out:
+ dsa_devlink_resources_unregister(ds);
+ return err;
+}
+EXPORT_SYMBOL(b53_setup_devlink_resources);
+
static int b53_setup(struct dsa_switch *ds)
{
struct b53_device *dev = ds->priv;
@@ -992,8 +1039,10 @@ static int b53_setup(struct dsa_switch *ds)
b53_reset_mib(dev);
ret = b53_apply_config(dev);
- if (ret)
+ if (ret) {
dev_err(ds->dev, "failed to apply configuration\n");
+ return ret;
+ }
/* Configure IMP/CPU port, disable all other ports. Enabled
* ports will be configured with .port_enable
@@ -1012,7 +1061,12 @@ static int b53_setup(struct dsa_switch *ds)
*/
ds->vlan_filtering_is_global = true;
- return ret;
+ return b53_setup_devlink_resources(ds);
+}
+
+static void b53_teardown(struct dsa_switch *ds)
+{
+ dsa_devlink_resources_unregister(ds);
}
static void b53_force_link(struct b53_device *dev, int port, int link)
@@ -2141,6 +2195,7 @@ static int b53_get_max_mtu(struct dsa_switch *ds, int
port)
static const struct dsa_switch_ops b53_switch_ops = {
.get_tag_protocol = b53_get_tag_protocol,
.setup = b53_setup,
+ .teardown = b53_teardown,
.get_strings= b53_get_strings,
.get_ethtool_stats = b53_get_ethtool_stats,
.get_sset_count = b53_get_sset_count,
diff --git a/drivers/net/dsa/b53/b53_priv.h b/drivers/net/dsa/b53/b53_priv.h
index e942c60e4365..c55c0a9f1b47 100644
--- a/drivers/net/dsa/b53/b53_priv.h
+++ b/drivers/net/dsa/b53/b53_priv.h
@@ -328,6 +328,7 @@ void b53_br_set_stp_state(struct dsa_switch *ds, int port,
u8 state);
void b53_br_fast_age(struct dsa_switch *ds, int port);
int b53_br_egress_floods(struct dsa_switch *ds, int port,
bool unicast, bool multicast);
+int b53_setup_devlink_resources(struct dsa_switch *ds);
void b53_port_event(struct dsa_switch *ds, int port);
void b53_phylink_validate(struct dsa_switch *ds, int port,
unsigned long *supported,
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 3263e8a0ae67..723820603107 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -936,7 +936,12 @@ static int bcm_sf2_sw_setup(struct dsa_switch *ds)
b53_configure_vlan(ds);
bcm_sf2_enable_acb(ds);
- return 0;
+ return b53_setup_devlink_resources(ds);
+}
+
+static void bcm_sf2_sw_teardown(struct dsa_switch *ds)
+{
+ dsa_devlink_resources_unregister(ds);
}
/* The SWITCH_CORE register space is managed by b53 but operates on a page +
@@ -1073,6 +1078,7 @@ static int bcm_sf2_sw_get_sset_count(struct dsa_switch
*ds, int port,
static const struct dsa_switch_ops bcm_sf2_ops = {
.get_tag_protocol = b53_get_tag_protocol,
.setup = bcm_sf2_sw_setup,
+
WARNING: suspicious RCU usage: include/trace/events/tlb.h:57 suspicious rcu_dereference_check() usage!
While booting i386 with Linux next 20200908 tag kernel this warning noticed.
metadata:
git branch: master
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git commit: dff9f829e5b0181d4ed9d35aa62d695292399b54
git describe: next-20200908
kernel-config:
http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-core2-32/lkft/linux-next/853/config
warning log:
-
[ 11.451223] Write protecting kernel text and read-only data: 20800k
[ 11.457522] Run /sbin/init as init process
[ 11.463807] random: fast init done
[ 11.471527]
[ 11.473118] =
[ 11.477129] WARNING: suspicious RCU usage
[ 11.481135] 5.9.0-rc4-next-20200908 #1 Not tainted
[ 11.485926] -
[ 11.489931] /usr/src/kernel/include/trace/events/tlb.h:57
suspicious rcu_dereference_check() usage!
[ 11.498970]
[ 11.498970] other info that might help us debug this:
[ 11.498970]
[ 11.506961]
[ 11.506961] rcu_scheduler_active = 2, debug_locks = 1
[ 11.513476] RCU used illegally from extended quiescent state!
[ 11.519215] no locks held by swapper/0/0.
[ 11.523217]
[ 11.523217] stack backtrace:
[ 11.527569] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
5.9.0-rc4-next-20200908 #1
[ 11.534955] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.2 05/23/2018
[ 11.542345] Call Trace:
[ 11.544792] dump_stack+0x6d/0x8b
[ 11.548112] lockdep_rcu_suspicious+0xb2/0xd0
[ 11.552473] switch_mm_irqs_off+0x508/0x510
[ 11.556658] switch_mm+0x19/0x50
[ 11.559890] leave_mm+0x2d/0x40
[ 11.563034] acpi_idle_enter_bm+0x1c/0x120
[ 11.567127] acpi_idle_enter+0x13b/0x230
[ 11.571049] ? rcu_eqs_enter.constprop.87+0x9e/0x180
[ 11.576008] ? acpi_idle_enter_s2idle+0x50/0x50
[ 11.580542] cpuidle_enter_state+0x87/0x560
[ 11.584732] cpuidle_enter+0x27/0x40
[ 11.588316] do_idle+0x20b/0x2a0
[ 11.591551] cpu_startup_entry+0x25/0x30
[ 11.595474] rest_init+0x166/0x230
[ 11.598881] arch_call_rest_init+0xd/0x19
[ 11.602893] start_kernel+0x481/0x4a0
[ 11.606562] i386_start_kernel+0x48/0x4a
[ 11.610485] startup_32_smp+0x164/0x168
[ 11.614338]
[ 11.614339] =
[ 11.614339] WARNING: suspicious RCU usage
[ 11.614340] 5.9.0-rc4-next-20200908 #1 Not tainted
[ 11.614340] -
[ 11.614341] /usr/src/kernel/include/trace/events/lock.h:37
suspicious rcu_dereference_check() usage!
[ 11.614341]
[ 11.614341] other info that might help us debug this:
[ 11.614342]
[ 11.614342]
[ 11.614342] rcu_scheduler_active = 2, debug_locks = 1
[ 11.614343] RCU used illegally from extended quiescent state!
[ 11.614343] no locks held by swapper/0/0.
[ 11.614343]
[ 11.614344] stack backtrace:
[ 11.614344] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
5.9.0-rc4-next-20200908 #1
[ 11.614345] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.2 05/23/2018
[ 11.614345] Call Trace:
[ 11.614345] dump_stack+0x6d/0x8b
[ 11.614346] lockdep_rcu_suspicious+0xb2/0xd0
[ 11.614346] lock_acquire+0x2d8/0x340
[ 11.614346] _raw_spin_lock+0x27/0x40
[ 11.614347] ? vprintk_emit+0x57/0x2c0
[ 11.614347] vprintk_emit+0x57/0x2c0
[ 11.614347] vprintk_default+0x17/0x20
[ 11.614348] vprintk_func+0x4f/0xd0
[ 11.614348] printk+0x13/0x15
[ 11.614348] lockdep_rcu_suspicious+0x21/0xd0
[ 11.614349] switch_mm_irqs_off+0x508/0x510
[ 11.614349] switch_mm+0x19/0x50
[ 11.614349] leave_mm+0x2d/0x40
[ 11.614350] acpi_idle_enter_bm+0x1c/0x120
[ 11.614350] acpi_idle_enter+0x13b/0x230
[ 11.614351] ? rcu_eqs_enter.constprop.87+0x9e/0x180
[ 11.614351] ? acpi_idle_enter_s2idle+0x50/0x50
[ 11.614351] cpuidle_enter_state+0x87/0x560
[ 11.614352] cpuidle_enter+0x27/0x40
[ 11.614352] do_idle+0x20b/0x2a0
[ 11.614352] cpu_startup_entry+0x25/0x30
[ 11.614353] rest_init+0x166/0x230
[ 11.614353] arch_call_rest_init+0xd/0x19
[ 11.614353] start_kernel+0x481/0x4a0
[ 11.614354] i386_start_kernel+0x48/0x4a
[ 11.614354] startup_32_smp+0x164/0x168
[ 11.614354]
[ 11.614355] =
[ 11.614355] WARNING: suspicious RCU usage
[ 11.614356] 5.9.0-rc4-next-20200908 #1 Not tainted
[ 11.614356] -
[ 11.614356] /usr/src/kernel/include/trace/events/lock.h:63
suspicious rcu_dereference_check() usage!
[ 11.614357]
[ 11.614357] other info that might help us debug this:
[ 11.614357]
[ 11.614358]
[ 11.614358] rcu_scheduler_active = 2, debug_locks = 1
[ 11.614358] RCU used illegally from extended quiescent state!
[ 11.614359] 1 lock held by swapper/0/0:
[ 11.614359] #0: c82fd670 (logbuf_lock){-...}-{2:2}, at:
vprintk_emit+0x57/0x2c0
[ 11.614361]
[ 11.614361] stack backtrace:
[ 11.614362] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
5.9.0-rc4-next-20200908 #1
[ 11.614362] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.2 05/23/2018
[ 11.614362] Call Trace
Re: [PATCH v2] kbuild: preprocess module linker script
On Mon, 07 Sep 2020 21:27:08 PDT (-0700), masahi...@kernel.org wrote:
There was a request to preprocess the module linker script like we
do for the vmlinux one. (https://lkml.org/lkml/2020/8/21/512)
The difference between vmlinux.lds and module.lds is that the latter
is needed for external module builds, thus must be cleaned up by
'make mrproper' instead of 'make clean'. Also, it must be created
by 'make modules_prepare'.
You cannot put it in arch/$(SRCARCH)/kernel/, which is cleaned up by
'make clean'. I moved arch/$(SRCARCH)/kernel/module.lds to
arch/$(SRCARCH)/include/asm/module.lds.h, which is included from
scripts/module.lds.S.
scripts/module.lds is fine because 'make clean' keeps all the
build artifacts under scripts/.
You can add arch-specific sections in .
for the arch/riscv stuff
Acked-by: Palmer Dabbelt
Thanks!
Signed-off-by: Masahiro Yamada
Tested-by: Jessica Yu
Acked-by: Will Deacon
---
Changes in v2:
- Fix the race between the two targets 'scripts' and 'asm-generic'
Makefile | 10 ++
arch/arm/Makefile | 4
.../{kernel/module.lds => include/asm/module.lds.h}| 2 ++
arch/arm64/Makefile| 4
.../{kernel/module.lds => include/asm/module.lds.h}| 2 ++
arch/ia64/Makefile | 1 -
arch/ia64/{module.lds => include/asm/module.lds.h} | 0
arch/m68k/Makefile | 1 -
.../{kernel/module.lds => include/asm/module.lds.h}| 0
arch/powerpc/Makefile | 1 -
.../{kernel/module.lds => include/asm/module.lds.h}| 0
arch/riscv/Makefile| 3 ---
.../{kernel/module.lds => include/asm/module.lds.h}| 3 ++-
arch/um/include/asm/Kbuild | 1 +
include/asm-generic/Kbuild | 1 +
include/asm-generic/module.lds.h | 10 ++
scripts/.gitignore | 1 +
scripts/Makefile | 3 +++
scripts/Makefile.modfinal | 5 ++---
scripts/{module-common.lds => module.lds.S}| 3 +++
scripts/package/builddeb | 2 +-
21 files changed, 34 insertions(+), 23 deletions(-)
rename arch/arm/{kernel/module.lds => include/asm/module.lds.h} (72%)
rename arch/arm64/{kernel/module.lds => include/asm/module.lds.h} (76%)
rename arch/ia64/{module.lds => include/asm/module.lds.h} (100%)
rename arch/m68k/{kernel/module.lds => include/asm/module.lds.h} (100%)
rename arch/powerpc/{kernel/module.lds => include/asm/module.lds.h} (100%)
rename arch/riscv/{kernel/module.lds => include/asm/module.lds.h} (84%)
create mode 100644 include/asm-generic/module.lds.h
rename scripts/{module-common.lds => module.lds.S} (93%)
diff --git a/Makefile b/Makefile
index 37739ee53f27..97b1dae1783b 100644
--- a/Makefile
+++ b/Makefile
@@ -505,7 +505,6 @@ KBUILD_CFLAGS_KERNEL :=
KBUILD_AFLAGS_MODULE := -DMODULE
KBUILD_CFLAGS_MODULE := -DMODULE
KBUILD_LDFLAGS_MODULE :=
-export KBUILD_LDS_MODULE := $(srctree)/scripts/module-common.lds
KBUILD_LDFLAGS :=
CLANG_FLAGS :=
@@ -1395,7 +1394,7 @@ endif
# using awk while concatenating to the final file.
PHONY += modules
-modules: $(if $(KBUILD_BUILTIN),vmlinux) modules_check
+modules: $(if $(KBUILD_BUILTIN),vmlinux) modules_check modules_prepare
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
PHONY += modules_check
@@ -1412,6 +1411,7 @@ targets += modules.order
# Target to prepare building external modules
PHONY += modules_prepare
modules_prepare: prepare
+ $(Q)$(MAKE) $(build)=scripts scripts/module.lds
# Target to install modules
PHONY += modules_install
@@ -1743,7 +1743,9 @@ help:
@echo ' clean - remove generated files in module directory
only'
@echo ''
-PHONY += prepare
+# no-op for external module builds
+PHONY += prepare modules_prepare
+
endif # KBUILD_EXTMOD
# Single targets
@@ -1776,7 +1778,7 @@ MODORDER := .modules.tmp
endif
PHONY += single_modpost
-single_modpost: $(single-no-ko)
+single_modpost: $(single-no-ko) modules_prepare
$(Q){ $(foreach m, $(single-ko), echo $(extmod-prefix)$m;) } >
$(MODORDER)
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4e877354515f..a0cb15de9677 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -16,10 +16,6 @@ LDFLAGS_vmlinux += --be8
KBUILD_LDFLAGS_MODULE += --be8
endif
-ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
-KBUILD_LDS_MODULE += $(srctree)/arch/arm/kernel/module.lds
-endif
-
GZFLAGS:=-9
#KBUILD_CFLAGS +=-pipe
diff --git a/arch/arm/kernel/module.lds b/arch/arm/include/asm/module.lds.h
similarity index 72%
rename from arch/arm/kernel/module.lds
rename to
Re: [External] Re: [PATCH] mm/vmscan: fix infinite loop in drop_slab_node
Hi Chris,
On Tue, Sep 8, 2020 at 11:09 PM Chris Down wrote:
>
> drop_caches by its very nature can be extremely performance intensive -- if
> someone wants to abort after trying too long, they can just send a
> TASK_KILLABLE signal, no? If exiting the loop and returning to usermode
> doesn't
> reliably work when doing that, then _that's_ something to improve, but this
> looks premature to me until that's demonstrated not to work.
Sending a TASK_KILLABLE signal? It didn't work now. Because the the
current task has no chance to handle the signal. So I think we may
need to do any of the following things to avoid this case happening.
1. Double the threshold currently hard coded as "10" with each iteration
suggested by Vlastimil. It is also a good idea.
2. In the while loop, we can check whether the TASK_KILLABLE
signal is set, if so, we should break the loop. like the following code
snippe. Thanks.
@@ -704,6 +704,9 @@ void drop_slab_node(int nid)
do {
struct mem_cgroup *memcg = NULL;
+ if (fatal_signal_pending(current))
+ return;
+
freed = 0;
memcg = mem_cgroup_iter(NULL, NULL, NULL);
do {
>
> zangchun...@bytedance.com writes:
> >In one drop caches action, only traverse memcg once maybe is better.
> >If user need more memory, they can do drop caches again.
>
> Can you please provide some measurements of the difference in reclamation in
> practice?
--
Yours,
Muchun
Re: [PATCH 0/2] scsi: lpfc: Reduce logging object code size
On Mon, 2020-08-10 at 15:59 -0700, Joe Perches wrote: > The logging macros are pretty heavyweight and can be consolidated > to reduce overall object size. > > Joe Perches (2): > scsi: lpfc: Neaten logging macro #defines > scsi: lpfc: Add logging functions to reduce object size > > drivers/scsi/lpfc/Makefile | 2 +- > drivers/scsi/lpfc/lpfc.h | 5 ++ > drivers/scsi/lpfc/lpfc_attr.h| 5 ++ > drivers/scsi/lpfc/lpfc_bsg.h | 6 ++ > drivers/scsi/lpfc/lpfc_compat.h | 5 ++ > drivers/scsi/lpfc/lpfc_crtn.h| 5 ++ > drivers/scsi/lpfc/lpfc_disc.h| 5 ++ > drivers/scsi/lpfc/lpfc_hw.h | 5 ++ > drivers/scsi/lpfc/lpfc_hw4.h | 5 ++ > drivers/scsi/lpfc/lpfc_ids.h | 5 ++ > drivers/scsi/lpfc/lpfc_logmsg.c | 112 +++ > drivers/scsi/lpfc/lpfc_logmsg.h | 63 ++--- > drivers/scsi/lpfc/lpfc_nl.h | 4 ++ > drivers/scsi/lpfc/lpfc_nvme.h| 5 ++ > drivers/scsi/lpfc/lpfc_scsi.h| 4 ++ > drivers/scsi/lpfc/lpfc_sli.h | 5 ++ > drivers/scsi/lpfc/lpfc_sli4.h| 5 ++ > drivers/scsi/lpfc/lpfc_version.h | 5 ++ > 18 files changed, 208 insertions(+), 43 deletions(-) > create mode 100644 drivers/scsi/lpfc/lpfc_logmsg.c ping?
[PATCH net 1/2] hv_netvsc: Switch the data path at the right time during hibernation
When netvsc_resume() is called, the mlx5 VF NIC has not been resumed yet,
so in the future the host might sliently fail the call netvsc_vf_changed()
-> netvsc_switch_datapath() there, even if the call works now.
Call netvsc_vf_changed() in the NETDEV_CHANGE event handler: at that time
the mlx5 VF NIC has been resumed.
Fixes: 19162fd4063a ("hv_netvsc: Fix hibernation for mlx5 VF driver")
Signed-off-by: Dexuan Cui
---
drivers/net/hyperv/netvsc_drv.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 81c5c70b616a..4a25886e2346 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -2619,7 +2619,6 @@ static int netvsc_resume(struct hv_device *dev)
struct net_device *net = hv_get_drvdata(dev);
struct net_device_context *net_device_ctx;
struct netvsc_device_info *device_info;
- struct net_device *vf_netdev;
int ret;
rtnl_lock();
@@ -2632,15 +2631,6 @@ static int netvsc_resume(struct hv_device *dev)
netvsc_devinfo_put(device_info);
net_device_ctx->saved_netvsc_dev_info = NULL;
- /* A NIC driver (e.g. mlx5) may keep the VF network interface across
-* hibernation, but here the data path is implicitly switched to the
-* netvsc NIC since the vmbus channel is closed and re-opened, so
-* netvsc_vf_changed() must be used to switch the data path to the VF.
-*/
- vf_netdev = rtnl_dereference(net_device_ctx->vf_netdev);
- if (vf_netdev && netvsc_vf_changed(vf_netdev) != NOTIFY_OK)
- ret = -EINVAL;
-
rtnl_unlock();
return ret;
@@ -2701,6 +2691,7 @@ static int netvsc_netdev_event(struct notifier_block
*this,
return netvsc_unregister_vf(event_dev);
case NETDEV_UP:
case NETDEV_DOWN:
+ case NETDEV_CHANGE:
return netvsc_vf_changed(event_dev);
default:
return NOTIFY_DONE;
--
2.19.1
[PATCH net 2/2] hv_netvsc: Cache the current data path to avoid duplicate call and message
The previous change "hv_netvsc: Switch the data path at the right time
during hibernation" adds the call of netvsc_vf_changed() upon
NETDEV_CHANGE, so it's necessary to avoid the duplicate call and message
when the VF is brought UP or DOWN.
Signed-off-by: Dexuan Cui
---
drivers/net/hyperv/hyperv_net.h | 3 +++
drivers/net/hyperv/netvsc_drv.c | 21 -
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 2181d4538ab7..ff33f27cdcd3 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -974,6 +974,9 @@ struct net_device_context {
/* Serial number of the VF to team with */
u32 vf_serial;
+ /* Is the current data path through the VF NIC? */
+ bool data_path_is_vf;
+
/* Used to temporarily save the config info across hibernation */
struct netvsc_device_info *saved_netvsc_dev_info;
};
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 4a25886e2346..b7db3766f5b9 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -2366,7 +2366,16 @@ static int netvsc_register_vf(struct net_device
*vf_netdev)
return NOTIFY_OK;
}
-/* VF up/down change detected, schedule to change data path */
+/* Change the data path when VF UP/DOWN/CHANGE are detected.
+ *
+ * Typically a UP or DOWN event is followed by a CHANGE event, so
+ * net_device_ctx->data_path_is_vf is used to cache the current data path
+ * to avoid the duplicate call of netvsc_switch_datapath() and the duplicate
+ * message.
+ *
+ * During hibernation, if a VF NIC driver (e.g. mlx5) preserves the network
+ * interface, there is only the CHANGE event and no UP or DOWN event.
+ */
static int netvsc_vf_changed(struct net_device *vf_netdev)
{
struct net_device_context *net_device_ctx;
@@ -2383,6 +2392,10 @@ static int netvsc_vf_changed(struct net_device
*vf_netdev)
if (!netvsc_dev)
return NOTIFY_DONE;
+ if (net_device_ctx->data_path_is_vf == vf_is_up)
+ return NOTIFY_OK;
+ net_device_ctx->data_path_is_vf = vf_is_up;
+
netvsc_switch_datapath(ndev, vf_is_up);
netdev_info(ndev, "Data path switched %s VF: %s\n",
vf_is_up ? "to" : "from", vf_netdev->name);
@@ -2624,6 +2637,12 @@ static int netvsc_resume(struct hv_device *dev)
rtnl_lock();
net_device_ctx = netdev_priv(net);
+
+ /* Reset the data path to the netvsc NIC before re-opening the vmbus
+* channel. Later netvsc_netdev_event() will switch the data path to
+* the VF upon the UP or CHANGE event.
+*/
+ net_device_ctx->data_path_is_vf = false;
device_info = net_device_ctx->saved_netvsc_dev_info;
ret = netvsc_attach(net, device_info);
--
2.19.1
Re: [Nouveau] [PATCH] drm/nouveau: Add fine-grain temperature reporting
On Thu, 13 Aug 2020 at 06:50, Jeremy Cline wrote:
>
> Commit d32656373857 ("drm/nouveau/therm/gp100: initial implementation of
> new gp1xx temperature sensor") added support for reading finer-grain
> temperatures, but continued to report temperatures in 1 degree Celsius
> increments via nvkm_therm_temp_get().
>
> Rather than altering nvkm_therm_temp_get() to report finer-grain
> temperatures, which would be inconvenient for other users of the
> function, a second interface has been added to line up with hwmon's
> native unit of temperature.
Hey Jeremy,
Sorry this slipped past me until now. I'm OK with adding support for
millidegree temperature reporting, but don't think we need to keep
both interfaces around and would rather see the existing code
converted to return millidegrees (even on GPUs that don't support it)
instead of degrees.
Thanks!
Ben.
>
> Signed-off-by: Jeremy Cline
> ---
> .../drm/nouveau/include/nvkm/subdev/therm.h | 18 +
> drivers/gpu/drm/nouveau/nouveau_hwmon.c | 4 +--
> .../gpu/drm/nouveau/nvkm/subdev/therm/base.c | 16
> .../gpu/drm/nouveau/nvkm/subdev/therm/gp100.c | 25 +--
> .../gpu/drm/nouveau/nvkm/subdev/therm/priv.h | 1 +
> 5 files changed, 60 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> index 62c34f98c930..7b9928dd001c 100644
> --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> @@ -100,6 +100,24 @@ struct nvkm_therm {
> };
>
> int nvkm_therm_temp_get(struct nvkm_therm *);
> +
> +/**
> + * nvkm_therm_temp_millidegree_get() - get the temperature in millidegrees
> + * @therm: The thermal device to read from.
> + *
> + * This interface reports temperatures in units of millidegree Celsius to
> + * align with the hwmon API. Some cards may only be capable of reporting in
> + * units of Celsius, and those that report finer grain temperatures may not
> be
> + * capable of millidegree Celsius accuracy,
> + *
> + * For cases where millidegree temperature is too fine-grain, the
> + * nvkm_therm_temp_get() interface reports temperatures in one degree Celsius
> + * increments.
> + *
> + * Return: The temperature in millidegrees Celsius, or -ENODEV if temperature
> + * reporting is not supported.
> + */
> +int nvkm_therm_temp_millidegree_get(struct nvkm_therm *therm);
> int nvkm_therm_fan_sense(struct nvkm_therm *);
> int nvkm_therm_cstate(struct nvkm_therm *, int, int);
> void nvkm_therm_clkgate_init(struct nvkm_therm *,
> diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> index 1c3104d20571..e96355f93ce5 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> @@ -428,8 +428,8 @@ nouveau_temp_read(struct device *dev, u32 attr, int
> channel, long *val)
> case hwmon_temp_input:
> if (drm_dev->switch_power_state != DRM_SWITCH_POWER_ON)
> return -EINVAL;
> - ret = nvkm_therm_temp_get(therm);
> - *val = ret < 0 ? ret : (ret * 1000);
> + ret = nvkm_therm_temp_millidegree_get(therm);
> + *val = ret;
> break;
> case hwmon_temp_max:
> *val = therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK)
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> index 4a4d1e224126..e655b32c78b8 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> @@ -34,6 +34,22 @@ nvkm_therm_temp_get(struct nvkm_therm *therm)
> return -ENODEV;
> }
>
> +int
> +nvkm_therm_temp_millidegree_get(struct nvkm_therm *therm)
> +{
> + int ret = -ENODEV;
> +
> + if (therm->func->temp_millidegree_get)
> + return therm->func->temp_millidegree_get(therm);
> +
> + if (therm->func->temp_get) {
> + ret = therm->func->temp_get(therm);
> + if (ret > 0)
> + ret *= 1000;
> + }
> + return ret;
> +}
> +
> static int
> nvkm_therm_update_trip(struct nvkm_therm *therm)
> {
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c
> index 9f0dea3f61dc..4c3c2895a3cb 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c
> @@ -24,7 +24,7 @@
> #include "priv.h"
>
> static int
> -gp100_temp_get(struct nvkm_therm *therm)
> +gp100_temp_get_raw(struct nvkm_therm *therm)
> {
> struct nvkm_device *device = therm->subdev.device;
> struct nvkm_subdev *subdev = >subdev;
> @@ -37,14 +37,35 @@ gp100_temp_get(struct nvkm_therm *therm)
>
> /* device valid */
> if (tsensor &
[PATCH] platform/chrome: cros_ec_debugfs: Support pd_info v2 format
Let's try to read more information out of more modern cros_ec devices by
using the v2 format first and then fall back to the v1 format. This
gives us more information about things such as DP mode of the typec pins
and the CC state, along with some more things.
Cc: Gwendal Grignou
Cc: Prashant Malani
Cc: Guenter Roeck
Signed-off-by: Stephen Boyd
---
Should we move read_buf to the heap?
drivers/platform/chrome/cros_ec_debugfs.c | 40 +--
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_debugfs.c
b/drivers/platform/chrome/cros_ec_debugfs.c
index 272c89837d74..4f8c902c0de6 100644
--- a/drivers/platform/chrome/cros_ec_debugfs.c
+++ b/drivers/platform/chrome/cros_ec_debugfs.c
@@ -195,28 +195,31 @@ static ssize_t cros_ec_pdinfo_read(struct file *file,
size_t count,
loff_t *ppos)
{
- char read_buf[EC_USB_PD_MAX_PORTS * 40], *p = read_buf;
+ char read_buf[EC_USB_PD_MAX_PORTS * 64], *p = read_buf;
struct cros_ec_debugfs *debug_info = file->private_data;
struct cros_ec_device *ec_dev = debug_info->ec->ec_dev;
struct {
struct cros_ec_command msg;
union {
- struct ec_response_usb_pd_control_v1 resp;
+ struct ec_response_usb_pd_control_v2 resp_v2;
+ struct ec_response_usb_pd_control_v1 resp_v1;
struct ec_params_usb_pd_control params;
};
} __packed ec_buf;
struct cros_ec_command *msg;
- struct ec_response_usb_pd_control_v1 *resp;
+ struct ec_response_usb_pd_control_v1 *resp_v1;
+ struct ec_response_usb_pd_control_v2 *resp_v2;
struct ec_params_usb_pd_control *params;
int i;
msg = _buf.msg;
params = (struct ec_params_usb_pd_control *)msg->data;
- resp = (struct ec_response_usb_pd_control_v1 *)msg->data;
+ resp_v1 = (struct ec_response_usb_pd_control_v1 *)msg->data;
+ resp_v2 = (struct ec_response_usb_pd_control_v2 *)msg->data;
msg->command = EC_CMD_USB_PD_CONTROL;
- msg->version = 1;
- msg->insize = sizeof(*resp);
+ msg->version = 2;
+ msg->insize = sizeof(*resp_v2);
msg->outsize = sizeof(*params);
/*
@@ -229,13 +232,30 @@ static ssize_t cros_ec_pdinfo_read(struct file *file,
params->mux = 0;
params->swap = 0;
- if (cros_ec_cmd_xfer_status(ec_dev, msg) < 0)
+ if (cros_ec_cmd_xfer_status(ec_dev, msg) < 0) {
+ if (i == 0 && msg->version == 2) {
+ /* Try again with version 1 */
+ msg->version = 1;
+ msg->insize = sizeof(*resp_v1);
+ i = 0;
+ continue;
+ }
+
break;
+ }
p += scnprintf(p, sizeof(read_buf) + read_buf - p,
- "p%d: %s en:%.2x role:%.2x pol:%.2x\n", i,
- resp->state, resp->enabled, resp->role,
- resp->polarity);
+ "p%d: %s en:%.2x role:%.2x pol:%.2x", i,
+ resp_v1->state, resp_v1->enabled, resp_v1->role,
+ resp_v1->polarity);
+ if (msg->version == 2) {
+ p += scnprintf(p, sizeof(read_buf) + read_buf - p,
+ " cc:%.2x dp:%.2x ctrl:%.2x cs:%.2x
gen:%.2x",
+ resp_v2->cc_state, resp_v2->dp_mode,
+ resp_v2->control_flags,
resp_v2->cable_speed,
+ resp_v2->cable_gen);
+ }
+ p += scnprintf(p, sizeof(read_buf) + read_buf - p, "\n");
}
return simple_read_from_buffer(user_buf, count, ppos,
--
Sent by a computer, using git, on the internet
Re: [RFC PATCH 00/16] 1GB THP support on x86_64
On 9/8/20 12:58 PM, Roman Gushchin wrote: On Tue, Sep 08, 2020 at 11:09:25AM -0400, Zi Yan wrote: On 7 Sep 2020, at 3:20, Michal Hocko wrote: On Fri 04-09-20 14:10:45, Roman Gushchin wrote: On Fri, Sep 04, 2020 at 09:42:07AM +0200, Michal Hocko wrote: [...] Something like MADV_HUGEPAGE_SYNC? It would be useful, since users have better and clearer control of getting huge pages from the kernel and know when they will pay the cost of getting the huge pages. I would think the suggestion is more about the huge page control options currently provided by the kernel do not have predictable performance outcome, since MADV_HUGEPAGE is a best-effort option and does not tell users whether the marked virtual address range is backed by huge pages or not when the madvise returns. MADV_HUGEPAGE_SYNC would provide a deterministic result to users on whether the huge page(s) are formed or not. Yeah, I agree with Michal here, we need a more straightforward interface. The hard question here is how hard the kernel should try to allocate a gigantic page and how fast it should give up and return an error? I'd say to try really hard if there are some chances to succeed, so that if an error is returned, there are no more reasons to retry. Any objections/better ideas here? I agree, especially because this is starting to look a lot more like an allocation call. And I think it would be appropriate for the kernel to try approximately as hard to provide these 1GB pages, as it would to allocate normal memory to a process. In fact, for a moment I thought, why not go all the way and make this actually be a true allocation? However, given that we still have operations that require page splitting, with no good way to call back user space to notify it that its "allocated" huge pages are being split, that fails. But it's still pretty close. Given that we need to pass a page size, we probably need either to introduce a new syscall (madvise2?) with an additional argument, or add a bunch of new madvise flags, like MADV_HUGEPAGE_SYNC + encoded 2MB, 1GB etc. Idk what is better long-term, but new madvise flags are probably slightly easier to deal with in the development process. Probably either an MADV_* flag or a new syscall would work fine. But given that this seems like a pretty distinct new capability, one with options and man page documentation and possibly future flags itself, I'd lean toward making it its own new syscall, maybe: compact_huge_pages(nbytes or npages, flags /* page size, etc */); ...thus leaving madvise() and it's remaining flags still available, to further refine things. thanks, -- John Hubbard NVIDIA
[PATCH] usb: ohci: Default to per-port over-current protection
Some integrated OHCI controller hubs do not expose all ports of the hub
to pins on the SoC. In some cases the unconnected ports generate
spurious over-current events. For example the Broadcom 56060/Ranger 2 SoC
contains a nominally 3 port hub but only the first port is wired.
Default behaviour for ohci-platform driver is to use global over-current
protection mode (AKA "ganged"). This leads to the spurious over-current
events affecting all ports in the hub.
We now alter the default to use per-port over-current protection.
This patch results in the following configuration changes depending
on quirks:
- For quirk OHCI_QUIRK_SUPERIO no changes. These systems remain set up
for ganged power switching and no over-current protection.
- For quirk OHCI_QUIRK_AMD756 or OHCI_QUIRK_HUB_POWER power switching
remains at none, while over-current protection is now guaranteed to be
set to per-port rather than the previous behaviour where it was either
none or global over-current protection depending on the value at
function entry.
Suggested-by: Alan Stern
Signed-off-by: Hamish Martin
---
drivers/usb/host/ohci-hcd.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index dd37e77dae00..8ab81f6ab150 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -673,20 +673,25 @@ static int ohci_run (struct ohci_hcd *ohci)
/* handle root hub init quirks ... */
val = roothub_a (ohci);
- val &= ~(RH_A_PSM | RH_A_OCPM);
+ /* Configure for per-port over-current protection by default */
+ val &= ~RH_A_NOCP;
+ val |= RH_A_OCPM;
if (ohci->flags & OHCI_QUIRK_SUPERIO) {
- /* NSC 87560 and maybe others */
+ /* NSC 87560 and maybe others.
+* Ganged power switching, no over-current protection.
+*/
val |= RH_A_NOCP;
- val &= ~(RH_A_POTPGT | RH_A_NPS);
- ohci_writel (ohci, val, >regs->roothub.a);
+ val &= ~(RH_A_POTPGT | RH_A_NPS | RH_A_PSM | RH_A_OCPM);
} else if ((ohci->flags & OHCI_QUIRK_AMD756) ||
(ohci->flags & OHCI_QUIRK_HUB_POWER)) {
/* hub power always on; required for AMD-756 and some
-* Mac platforms. ganged overcurrent reporting, if any.
+* Mac platforms.
*/
+ val &= ~RH_A_PSM;
val |= RH_A_NPS;
- ohci_writel (ohci, val, >regs->roothub.a);
}
+ ohci_writel(ohci, val, >regs->roothub.a);
+
ohci_writel (ohci, RH_HS_LPSC, >regs->roothub.status);
ohci_writel (ohci, (val & RH_A_NPS) ? 0 : RH_B_PPCM,
>regs->roothub.b);
--
2.28.0
RE: [PATCH v2 2/3] soc: sifive: Add SiFive specific Cadence DDR controller driver
> -Original Message- > From: Palmer Dabbelt > Sent: 09 September 2020 08:42 > To: Christoph Hellwig ; dkang...@cadence.com > Cc: Yash Shah ; robh...@kernel.org; Paul > Walmsley ( Sifive) ; b...@alien8.de; > mche...@kernel.org; tony.l...@intel.com; devicet...@vger.kernel.org; > a...@eecs.berkeley.edu; linux-kernel@vger.kernel.org; Sachin Ghadi > ; rrich...@marvell.com; > james.mo...@arm.com; linux-ri...@lists.infradead.org; linux- > e...@vger.kernel.org > Subject: Re: [PATCH v2 2/3] soc: sifive: Add SiFive specific Cadence DDR > controller driver > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Sun, 06 Sep 2020 23:11:26 PDT (-0700), Christoph Hellwig wrote: > > On Mon, Sep 07, 2020 at 11:17:58AM +0530, Yash Shah wrote: > >> Add a driver to manage the Cadence DDR controller present on SiFive > >> SoCs At present the driver manages the EDAC feature of the DDR > controller. > >> Additional features may be added to the driver in future to control > >> other aspects of the DDR controller. > > > > So if this is a generic(ish) Cadence IP block shouldn't it be named > > Cadence and made generic? Or is the frontend somehow SiFive specific? > > For some reason I thought we had a SiFive-specific interface to this, but I > may > have gotten that confused with something else as it's been a while. Someone > from SiFive would probably have a better idea, but it looks like the person > I'd > ask isn't thereany more so I'm all out of options ;) > > It looks like there was a very similar driver posted by Dhananjay Kangude > from Cadence in April: https://lkml.org/lkml/2020/4/6/358 . Some of the > register definitions seem to be different, but the code I looked at is very > similar so there's at least some bits that could be shared. I found a v4 of > that > patch set, but that was back in May: https://lkml.org/lkml/2020/5/11/912 . It > alludes to a v5, but I can't find one. I've added Dhananjay, maybe he knows > what's up? > I consulted with Dhananjay before posting this patch. From what I understood, Cadence provide highly configurable and customised DDR IP blocks based on the SoC vendor's need. This impacts the register configuration and probably the offsets too. I had also refer the v4 patch posted by Dhananjay mentioned above and found that the registers offsets are not matching with that of Cadence DDR IP in SiFive SoC. Therefore it seems this DDR IP block has SiFive specific configurations and hence this Sifive specific driver. > I don't know enough about the block to know if the subtle difference in > register names/offsets means. They look properly jumbled up (ie, not just an > offset), so maybe there's just different versions or that's the > SiFive-specific > part I had bouncing around my head? Either way, it seems like one driver > with some simple configuration could handle both of these -- either sticking > the offsets in the DT (if they're going to be different everywhere) or by > coming up with some version sort of thing (if there's a handful of these). > > I'm now also a bit worried about the provenace of this code. The two drivers > are errily similar -- for example, the variable definitions in handle_ce() > >u64 err_c_addr = 0x0; >u64 err_c_data = 0x0; >u32 err_c_synd, err_c_id; >u32 sig_val_l, sig_val_h; > > are exactly the same. I apologized, I forgot to mention it in cover-letter. I have based my work on Dhananjay's v4 patch[0]. - Yash [0]: https://lkml.org/lkml/2020/4/24/183
Re: Question: Why is there no notification when a file is opened using filp_open()?
On Tue, Sep 8, 2020 at 8:19 PM Matthew Wilcox wrote: > > On Tue, Sep 08, 2020 at 04:18:29PM +0300, Amir Goldstein wrote: > > On Tue, Sep 8, 2020 at 3:53 PM Xiaoming Ni wrote: > > > For example, in fs/coredump.c, do_coredump() calls filp_open() to > > > generate core files. > > > In this scenario, the fsnotify_open() notification is missing. > > > > I am not convinced that we should generate an event. > > You will have to explain in what is the real world use case that requires > > this > > event to be generated. > > Take the typical usage for fsnotify of a graphical file manager. > It would be nice if the file manager showed a corefile as soon as it > appeared in a directory rather than waiting until some other operation > in that directory caused those directory contents to be refreshed. fsnotify_open() is not the correct notification for file managers IMO. fsnotify_create() is and it will be called in this case. If the reason you are interested in open events is because you want to monitor the entire filesystem then welcome to the future - FAN_CREATE is supported since kernel v5.1. Is there another real life case you have in mind where you think users should be able to get an open fd for a file that the kernel has opened? Because that is what FAN_OPEN will do. Thanks, Amir.
Re: [v1,1/3] dt-bindings: Add YAML schemas for Gen3 PCIe controller
On Tue, 2020-09-08 at 14:21 -0600, Rob Herring wrote:
> On Mon, Sep 07, 2020 at 08:08:50PM +0800, Jianjun Wang wrote:
> > Add YAML schemas documentation for Gen3 PCIe controller on
> > MediaTek SoCs.
>
> dt-bindings: PCI: mediatek: ... for the subject.
>
> >
> > Acked-by: Ryder Lee
> > Signed-off-by: Jianjun Wang
> > ---
> > .../bindings/pci/mediatek-pcie-gen3.yaml | 158 ++
> > 1 file changed, 158 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
> > b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
> > new file mode 100644
> > index ..108d29259c05
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
> > @@ -0,0 +1,158 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pci/mediatek-pcie-gen3.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Gen3 PCIe controller on MediaTek SoCs
> > +
> > +maintainers:
> > + - Jianjun Wang
> > +
> > +allOf:
> > + - $ref: /schemas/pci/pci-bus.yaml#
> > +
> > +properties:
> > + compatible:
> > +oneOf:
> > + - const: mediatek,gen3-pcie
> > + - const: mediatek,mt8192-pcie
> > +
>
> > + device_type:
> > +const: pci
> > +
> > + "#address-cells":
> > +const: 3
> > +
> > + "#size-cells":
> > +const: 2
>
> Can drop these 3. Already in pci-bus.yaml.
>
> > +
> > + reg:
> > +items:
> > + - description: Controller control and status registers.
>
> Just 'maxItems: 1'. The description doesn't add any value.
>
> > +
> > + reg-names:
> > +items:
> > + - const: pcie-mac
>
> Don't really need a name here.
>
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > + bus-range:
> > +description: Range of bus numbers associated with this controller.
> > +
> > + ranges:
> > +minItems: 1
> > +maxItems: 8
> > +
> > + resets:
> > +minItems: 1
> > +maxItems: 2
> > +
> > + reset-names:
> > +anyOf:
> > + - const: mac-rst
> > + - const: phy-rst
>
> Doesn't the PHY's reset belong in the PHY node?
There are some cases that we don't need the PHY driver, but for the
reason of power saving, the HW still remain the PHY's reset in infra
domain and it will be asserted before kernel stage, so we still need to
release this reset in the PCIe MAC driver.
>
> > +
> > + clocks:
> > +maxItems: 5
> > +
> > + assigned-clocks:
> > +maxItems: 1
> > +
> > + assigned-clock-parents:
> > +maxItems: 1
> > +
> > + phys:
> > +maxItems: 1
> > +
> > + phy-names:
> > +const: pcie-phy
>
> Not really a useful name and there's only one. Please drop.
>
> > +
> > + '#interrupt-cells':
> > +const: 1
> > +
>
> > + interrupt-map-mask:
> > +description: Standard PCI IRQ mapping properties.
> > +
> > + interrupt-map:
> > +description: Standard PCI IRQ mapping properties.
>
> Can drop these.
>
> > +
> > + legacy-interrupt-controller:
>
> Just 'interrupt-controller'
>
> And don't copy the same bug of using 'of_get_next_child'. You should get
> the child node by name.
>
> > +description: Interrupt controller node for handling legacy PCI
> > interrupts.
> > +type: object
> > +properties:
> > + "#address-cells":
> > +const: 0
> > + "#interrupt-cells":
> > +const: 1
> > + interrupt-controller: true
> > +
> > +required:
> > + - "#address-cells"
> > + - "#interrupt-cells"
> > + - interrupt-controller
>
>additionalProperties: false
>
> > +
> > +required:
> > + - compatible
>
> > + - device_type
> > + - "#address-cells"
> > + - "#size-cells"
>
> Don't need these, pci-bus.yaml already requires them.
>
> > + - reg
> > + - reg-names
> > + - bus-range
>
> If the range is 0-0xff, then this isn't really required.
>
> > + - interrupts
> > + - ranges
> > + - clocks
> > + - '#interrupt-cells'
> > + - interrupt-map
> > + - interrupt-map-mask
> > + - legacy-interrupt-controller
> > +
> > +additionalProperties: false
>
> unevaluatedProperties: false
>
> (Should be used when including a ref (pci-bus.yaml).)
>
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +
> > +bus {
> > +#address-cells = <2>;
> > +#size-cells = <2>;
> > +
> > +pcie: pcie@1123 {
> > +compatible = "mediatek,mt8192-pcie";
> > +device_type = "pci";
> > +#address-cells = <3>;
> > +#size-cells = <2>;
> > +reg = <0x00 0x1123 0x00 0x4000>;
> > +reg-names = "pcie-mac";
> > +interrupts = ;
> > +bus-range = <0x00 0xff>;
> > +ranges = <0x8200 0x00 0x1200 0x00 0x1200 0x00
> > 0x100>;
> > +clocks = < 40>,
> > + < 43>,
>
Re: [RESEND PATCH 1/1] block: Set same_page to false in __bio_try_merge_page if ret is false
On Wed, Sep 9, 2020 at 11:16 AM Ritesh Harjani wrote:
>
> If we hit the UINT_MAX limit of bio->bi_iter.bi_size and so we are anyway
> not merging this page in this bio, then it make sense to make same_page
> also as false before returning.
>
> Without this patch, we hit below WARNING in iomap.
> This mostly happens with very large memory system and / or after tweaking
> vm dirty threshold params to delay writeback of dirty data.
>
> WARNING: CPU: 18 PID: 5130 at fs/iomap/buffered-io.c:74
> iomap_page_release+0x120/0x150
> CPU: 18 PID: 5130 Comm: fio Kdump: loaded Tainted: GW
> 5.8.0-rc3 #6
> Call Trace:
> __remove_mapping+0x154/0x320 (unreliable)
> iomap_releasepage+0x80/0x180
> try_to_release_page+0x94/0xe0
> invalidate_inode_page+0xc8/0x110
> invalidate_mapping_pages+0x1dc/0x540
> generic_fadvise+0x3c8/0x450
> xfs_file_fadvise+0x2c/0xe0 [xfs]
> vfs_fadvise+0x3c/0x60
> ksys_fadvise64_64+0x68/0xe0
> sys_fadvise64+0x28/0x40
> system_call_exception+0xf8/0x1c0
> system_call_common+0xf0/0x278
>
> Fixes: cc90bc68422 ("block: fix "check bi_size overflow before merge"")
> Suggested-by: Christoph Hellwig
> Reported-by: Shivaprasad G Bhat
> Signed-off-by: Anju T Sudhakar
> Signed-off-by: Ritesh Harjani
> ---
> RESEND: added "fixes" tag
>
> block/bio.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/block/bio.c b/block/bio.c
> index a7366c02c9b5..675ecd81047b 100644
> --- a/block/bio.c
> +++ b/block/bio.c
> @@ -877,8 +877,10 @@ bool __bio_try_merge_page(struct bio *bio, struct page
> *page,
> struct bio_vec *bv = >bi_io_vec[bio->bi_vcnt - 1];
>
> if (page_is_mergeable(bv, page, len, off, same_page)) {
> - if (bio->bi_iter.bi_size > UINT_MAX - len)
> + if (bio->bi_iter.bi_size > UINT_MAX - len) {
> + *same_page = false;
> return false;
> + }
> bv->bv_len += len;
> bio->bi_iter.bi_size += len;
> return true;
Reviewed-by: Ming Lei
--
Ming Lei
Re: [f2fs-dev] [PATCH] f2fs: clean up vm_map_ram() call
On 09/09, Chao Yu wrote:
> On 2020/9/9 10:36, Daeho Jeong wrote:
> > From: Daeho Jeong
> >
> > Made f2fs_vmap() wrapper to handle vm_map_ram() stuff.
> >
> > Signed-off-by: Daeho Jeong
>
> LGTM,
>
> I think it should be merged into original patch. :)
>
> Maybe Jaeguek could help to do that.
Yeah, no worries. :)
>
> Thanks,
>
> > ---
> > fs/f2fs/compress.c | 42 ++
> > 1 file changed, 18 insertions(+), 24 deletions(-)
> >
> > diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
> > index 357303d8514b..7895186cc765 100644
> > --- a/fs/f2fs/compress.c
> > +++ b/fs/f2fs/compress.c
> > @@ -557,6 +557,20 @@ static void f2fs_compress_free_page(struct page *page)
> > #define MAX_VMAP_RETRIES 3
> > +static void *f2fs_vmap(struct page **pages, unsigned int count)
> > +{
> > + int i;
> > + void *buf = NULL;
> > +
> > + for (i = 0; i < MAX_VMAP_RETRIES; i++) {
> > + buf = vm_map_ram(pages, count, -1);
> > + if (buf)
> > + break;
> > + vm_unmap_aliases();
> > + }
> > + return buf;
> > +}
> > +
> > static int f2fs_compress_pages(struct compress_ctx *cc)
> > {
> > struct f2fs_sb_info *sbi = F2FS_I_SB(cc->inode);
> > @@ -593,23 +607,13 @@ static int f2fs_compress_pages(struct compress_ctx
> > *cc)
> > }
> > }
> > - for (i = 0; i < MAX_VMAP_RETRIES; i++) {
> > - cc->rbuf = vm_map_ram(cc->rpages, cc->cluster_size, -1);
> > - if (cc->rbuf)
> > - break;
> > - vm_unmap_aliases();
> > - }
> > + cc->rbuf = f2fs_vmap(cc->rpages, cc->cluster_size);
> > if (!cc->rbuf) {
> > ret = -ENOMEM;
> > goto out_free_cpages;
> > }
> > - for (i = 0; i < MAX_VMAP_RETRIES; i++) {
> > - cc->cbuf = vm_map_ram(cc->cpages, cc->nr_cpages, -1);
> > - if (cc->cbuf)
> > - break;
> > - vm_unmap_aliases();
> > - }
> > + cc->cbuf = f2fs_vmap(cc->cpages, cc->nr_cpages);
> > if (!cc->cbuf) {
> > ret = -ENOMEM;
> > goto out_vunmap_rbuf;
> > @@ -728,23 +732,13 @@ void f2fs_decompress_pages(struct bio *bio, struct
> > page *page, bool verity)
> > goto out_free_dic;
> > }
> > - for (i = 0; i < MAX_VMAP_RETRIES; i++) {
> > - dic->rbuf = vm_map_ram(dic->tpages, dic->cluster_size, -1);
> > - if (dic->rbuf)
> > - break;
> > - vm_unmap_aliases();
> > - }
> > + dic->rbuf = f2fs_vmap(dic->tpages, dic->cluster_size);
> > if (!dic->rbuf) {
> > ret = -ENOMEM;
> > goto destroy_decompress_ctx;
> > }
> > - for (i = 0; i < MAX_VMAP_RETRIES; i++) {
> > - dic->cbuf = vm_map_ram(dic->cpages, dic->nr_cpages, -1);
> > - if (dic->cbuf)
> > - break;
> > - vm_unmap_aliases();
> > - }
> > + dic->cbuf = f2fs_vmap(dic->cpages, dic->nr_cpages);
> > if (!dic->cbuf) {
> > ret = -ENOMEM;
> > goto out_vunmap_rbuf;
> >
>
>
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [PATCH net-next 1/5] net: ipa: use atomic exchange for suspend reference
From: Alex Elder Date: Tue, 8 Sep 2020 19:21:23 -0500 > We take a single IPA clock reference to keep the clock running > until we get a system suspend operation. When a system suspend > request arrives, we drop that reference, and if that's the last > reference (likely) we'll proceed with suspending endpoints and > disabling the IPA core clock and interconnects. > > In most places we simply set the reference count to 0 or 1 > atomically. Instead--primarily to catch coding errors--use an > atomic exchange to update the reference count value, and report > an error in the event the previous value was unexpected. > > In a few cases it's not hard to see that the error message should > never be reported. Report them anyway, but add some excitement > to the message by ending it with an exclamation point. > > Signed-off-by: Alex Elder Please use refcount_t if you're wanting to validate things like this. Thank you.
Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
On Tue, Sep 8, 2020 at 4:15 AM Arnd Bergmann wrote: > > Picking up the old thread again after and getting pinged by multiple > colleagues about it (thanks!) reading through the history. > > On Fri, Jun 12, 2020 at 7:29 AM Viresh Kumar wrote: > > > > On 11-06-20, 19:34, Jassi Brar wrote: > > > In the first post in this thread, Viresh lamented that mailbox > > > introduces "a few ms" delay in the scheduler path. > > > Your own tests show that is certainly not the case -- average is the > > > same as proposed virtual channels 50-100us, the best case is 3us vs > > > 53us for virtual channels. > > > > Hmmm, I am not sure where is the confusion here Jassi. There are two > > things which are very very different from each other. > > > > - Time taken by the mailbox framework (and remote for acknowledging > > it) for completion of a single request, this can be 3us to 100s of > > us. This is clear for everyone. THIS IS NOT THE PROBLEM. > > > > - Delay introduced by few of such requests on the last one, i.e. 5 > > normal requests followed by an important one (like DVFS), the last > > one needs to wait for the first 5 to finish first. THIS IS THE > > PROBLEM. > > Earlier, Jassi also commented "Linux does not provide real-time > guarantees", which to me is what actually causes the issue here: > > Linux having timeouts when communicating to the firmware means > that it relies on the hardware and firmware having real-time behavior > even when not providing real-time guarantees to its processes. > The timeout used in SCMI is simply based on how long the Juno (?) platform takes to reply in most cases. Talking proper code-design, the timeout (if at all) shouldn't even be a hardcoded value, but instead taken from the platform. > When comparing the two usage models, it's clear that the minimum > latency for a message delivery is always at least the time time > to process an interrupt, plus at least one expensive MMIO read > and one less expensive posted MMIO write for an Ack. If we > have a doorbell plus out-of-band message, we need an extra > DMA barrier and a read from coherent memory, both of which can > be noticeable. As soon as messages are queued in the current > model, the maximum latency increases by a potentially unbounded > number of round-trips, while in the doorbell model that problem > does not exist, so I agree that we need to handle both modes > in the kernel deal with all existing hardware as well as firmware > that requires low-latency communication. > >From the test case Sudeep last shared, the scmi usage on mhu doesn't not even hit any bottleneck ... the test "failed" because of the too small hardcoded timeout value. Otherwise the current code actually shows better numbers. We need some synthetic tests to bring the limitation to the surface. I agree that there may be such a test case, however fictitious. For that reason, I am ok with the doorbell mode. > The only questions that I see in need of being answered are: > > 1. Should the binding use just different "#mbox-cells" values or >also different "compatible" strings to tell that difference? > 2. Should one driver try to handle both modes or should there >be two drivers? > > It sounds like Jassi strongly prefers separate drivers, which > would make separate compatible strings the more practical > approach. While the argument can be made that a single > piece of hardware should only have one DT description, > the counter-argument would be that the behavior described > by the DT here is made up by both the hardware and the > firmware behind it, and they are in fact different. > I totally agree with one compat-string for one hardware. However, as you said, unlike other device classes, the mailbox driver runs the sumtotal of hardware and the remote firmware behaviour. Also the implementations wouldn't share much, so I think a separate file+dt will be better. But I wanna get rid of this toothache that flares up every season, so whatever. Cheers!
Re: [f2fs-dev] [PATCH] f2fs: clean up vm_map_ram() call
On 2020/9/9 10:36, Daeho Jeong wrote:
From: Daeho Jeong
Made f2fs_vmap() wrapper to handle vm_map_ram() stuff.
Signed-off-by: Daeho Jeong
LGTM,
I think it should be merged into original patch. :)
Maybe Jaeguek could help to do that.
Thanks,
---
fs/f2fs/compress.c | 42 ++
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
index 357303d8514b..7895186cc765 100644
--- a/fs/f2fs/compress.c
+++ b/fs/f2fs/compress.c
@@ -557,6 +557,20 @@ static void f2fs_compress_free_page(struct page *page)
#define MAX_VMAP_RETRIES 3
+static void *f2fs_vmap(struct page **pages, unsigned int count)
+{
+ int i;
+ void *buf = NULL;
+
+ for (i = 0; i < MAX_VMAP_RETRIES; i++) {
+ buf = vm_map_ram(pages, count, -1);
+ if (buf)
+ break;
+ vm_unmap_aliases();
+ }
+ return buf;
+}
+
static int f2fs_compress_pages(struct compress_ctx *cc)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(cc->inode);
@@ -593,23 +607,13 @@ static int f2fs_compress_pages(struct compress_ctx *cc)
}
}
- for (i = 0; i < MAX_VMAP_RETRIES; i++) {
- cc->rbuf = vm_map_ram(cc->rpages, cc->cluster_size, -1);
- if (cc->rbuf)
- break;
- vm_unmap_aliases();
- }
+ cc->rbuf = f2fs_vmap(cc->rpages, cc->cluster_size);
if (!cc->rbuf) {
ret = -ENOMEM;
goto out_free_cpages;
}
- for (i = 0; i < MAX_VMAP_RETRIES; i++) {
- cc->cbuf = vm_map_ram(cc->cpages, cc->nr_cpages, -1);
- if (cc->cbuf)
- break;
- vm_unmap_aliases();
- }
+ cc->cbuf = f2fs_vmap(cc->cpages, cc->nr_cpages);
if (!cc->cbuf) {
ret = -ENOMEM;
goto out_vunmap_rbuf;
@@ -728,23 +732,13 @@ void f2fs_decompress_pages(struct bio *bio, struct page
*page, bool verity)
goto out_free_dic;
}
- for (i = 0; i < MAX_VMAP_RETRIES; i++) {
- dic->rbuf = vm_map_ram(dic->tpages, dic->cluster_size, -1);
- if (dic->rbuf)
- break;
- vm_unmap_aliases();
- }
+ dic->rbuf = f2fs_vmap(dic->tpages, dic->cluster_size);
if (!dic->rbuf) {
ret = -ENOMEM;
goto destroy_decompress_ctx;
}
- for (i = 0; i < MAX_VMAP_RETRIES; i++) {
- dic->cbuf = vm_map_ram(dic->cpages, dic->nr_cpages, -1);
- if (dic->cbuf)
- break;
- vm_unmap_aliases();
- }
+ dic->cbuf = f2fs_vmap(dic->cpages, dic->nr_cpages);
if (!dic->cbuf) {
ret = -ENOMEM;
goto out_vunmap_rbuf;
Re: [PATCH net-next 0/3] rxrpc: Allow more calls to same peer
From: David Howells Date: Tue, 08 Sep 2020 21:50:51 +0100 > Here are some development patches for AF_RXRPC that allow more simultaneous > calls to be made to the same peer with the same security parameters. The > current code allows a maximum of 4 simultaneous calls, which limits the afs > filesystem to that many simultaneous threads. This increases the limit to > 16. > > To make this work, the way client connections are limited has to be changed > (incoming call/connection limits are unaffected) as the current code > depends on queuing calls on a connection and then pushing the connection > through a queue. The limit is on the number of available connections. > > This is changed such that there's a limit[*] on the total number of calls > systemwide across all namespaces, but the limit on the number of client > connections is removed. > > Once a call is allowed to proceed, it finds a bundle of connections and > tries to grab a call slot. If there's a spare call slot, fine, otherwise > it will wait. If there's already a waiter, it will try to create another > connection in the bundle, unless the limit of 4 is reached (4 calls per > connection, giving 16). > > A number of things throttle someone trying to set up endless connections: > > - Calls that fail immediately have their conns deleted immediately, > > - Calls that don't fail immediately have to wait for a timeout, > > - Connections normally get automatically reaped if they haven't been used >for 2m, but this is sped up to 2s if the number of connections rises >over 900. This number is tunable by sysctl. > > > [*] Technically two limits - kernel sockets and userspace rxrpc sockets are > accounted separately. > > The patches are tagged here: > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > rxrpc-next-20200908 Pulled, thanks David.
Re: [PATCH] net: tc35815: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Tue, 8 Sep 2020 22:27:47 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'tc35815_init_queues()' GFP_ATOMIC must be used > because it can be called from 'tc35815_restart()' where some spinlock are > taken. > The call chain is: > tc35815_restart > --> tc35815_clear_queues > --> tc35815_init_queues > ... > Signed-off-by: Christophe JAILLET Applied.
Re: [PATCH] hippi: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Tue, 8 Sep 2020 22:08:39 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'rr_init_one()' GFP_KERNEL can be used because > it is a probe function and no spinlock is taken in the between. > > When memory is allocated in 'rr_open()' GFP_KERNEL can be used because > it is a '.ndo_open' function (see struct net_device_ops) and no spinlock is > taken in the between. > '.ndo_open' functions are synchronized using the rtnl_lock() semaphore. ... > Signed-off-by: Christophe JAILLET Applied.
Re: [v1,1/3] dt-bindings: Add YAML schemas for Gen3 PCIe controller
On Tue, 2020-09-08 at 15:04 -0500, Bjorn Helgaas wrote: > On Mon, Sep 07, 2020 at 08:08:50PM +0800, Jianjun Wang wrote: > > Add YAML schemas documentation for Gen3 PCIe controller on > > MediaTek SoCs. > > Please mention "mediatek" in the subject line so "git log --oneline" > is more useful. > > The convention (not universally observed) seems to be something like: > > dt-bindings: PCI: : Add YAML schema Thanks for your review, I will fix it in the next version.
[RESEND PATCH 1/1] block: Set same_page to false in __bio_try_merge_page if ret is false
If we hit the UINT_MAX limit of bio->bi_iter.bi_size and so we are anyway
not merging this page in this bio, then it make sense to make same_page
also as false before returning.
Without this patch, we hit below WARNING in iomap.
This mostly happens with very large memory system and / or after tweaking
vm dirty threshold params to delay writeback of dirty data.
WARNING: CPU: 18 PID: 5130 at fs/iomap/buffered-io.c:74
iomap_page_release+0x120/0x150
CPU: 18 PID: 5130 Comm: fio Kdump: loaded Tainted: GW
5.8.0-rc3 #6
Call Trace:
__remove_mapping+0x154/0x320 (unreliable)
iomap_releasepage+0x80/0x180
try_to_release_page+0x94/0xe0
invalidate_inode_page+0xc8/0x110
invalidate_mapping_pages+0x1dc/0x540
generic_fadvise+0x3c8/0x450
xfs_file_fadvise+0x2c/0xe0 [xfs]
vfs_fadvise+0x3c/0x60
ksys_fadvise64_64+0x68/0xe0
sys_fadvise64+0x28/0x40
system_call_exception+0xf8/0x1c0
system_call_common+0xf0/0x278
Fixes: cc90bc68422 ("block: fix "check bi_size overflow before merge"")
Suggested-by: Christoph Hellwig
Reported-by: Shivaprasad G Bhat
Signed-off-by: Anju T Sudhakar
Signed-off-by: Ritesh Harjani
---
RESEND: added "fixes" tag
block/bio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/bio.c b/block/bio.c
index a7366c02c9b5..675ecd81047b 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -877,8 +877,10 @@ bool __bio_try_merge_page(struct bio *bio, struct page
*page,
struct bio_vec *bv = >bi_io_vec[bio->bi_vcnt - 1];
if (page_is_mergeable(bv, page, len, off, same_page)) {
- if (bio->bi_iter.bi_size > UINT_MAX - len)
+ if (bio->bi_iter.bi_size > UINT_MAX - len) {
+ *same_page = false;
return false;
+ }
bv->bv_len += len;
bio->bi_iter.bi_size += len;
return true;
--
2.25.4
Re: [PATCH 4.19 41/88] net: ethernet: mlx4: Fix memory allocation in mlx4_buddy_init()
On Tue, Sep 08, 2020 at 09:53:11PM +0200, Pavel Machek wrote:
> Hi!
>
> > On machines with much memory (> 2 TByte) and log_mtts_per_seg == 0, a
> > max_order of 31 will be passed to mlx_buddy_init(), which results in
> > s = BITS_TO_LONGS(1 << 31) becoming a negative value, leading to
> > kvmalloc_array() failure when it is converted to size_t.
> >
> > mlx4_core :b1:00.0: Failed to initialize memory region table, aborting
> > mlx4_core: probe of :b1:00.0 failed with error -12
> >
> > Fix this issue by changing the left shifting operand from a signed literal
> > to
> > an unsigned one.
>
> Will we still have problems with > 4 TByte machines?
AFAIK we're safe since max_buddy is calculated as such
/* In drivers/net/ethernet/mellanox/mlx4/mr.c */
err = mlx4_buddy_init(_table->mtt_buddy,
ilog2((u32)dev->caps.num_mtts /
(1 << log_mtts_per_seg)));
Also, num_mtts is capped at 2^31
/* In drivers/net/ethernet/mellanox/mlx4/profile.c */
/*
* We want to scale the number of MTTs with the size of the
* system memory, since it makes sense to register a lot of
* memory on a system with a lot of memory. As a heuristic,
* make sure we have enough MTTs to cover twice the system
* memory (with PAGE_SIZE entries).
*
* This number has to be a power of two and fit into 32 bits
* due to device limitations, so cap this at 2^31 as well.
* That limits us to 8TB of memory registration per HCA with
* 4KB pages, which is probably OK for the next few months.
*/
si_meminfo();
request->num_mtt =
roundup_pow_of_two(max_t(unsigned, request->num_mtt,
min(1UL << (31 - log_mtts_per_seg),
(si.totalram << 1) >>
log_mtts_per_seg)));
Best,
Shung-Hsi Yu
> Should the computation be done in u64?
>
> Best regards,
> Pavel
>
> > Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand
> > adapters")
> > Signed-off-by: Shung-Hsi Yu
> > Signed-off-by: David S. Miller
> > Signed-off-by: Sasha Levin
>
> > +++ b/drivers/net/ethernet/mellanox/mlx4/mr.c
> > @@ -114,7 +114,7 @@ static int mlx4_buddy_init(struct mlx4_buddy *buddy,
> > int max_order)
> > goto err_out;
> >
> > for (i = 0; i <= buddy->max_order; ++i) {
> > - s = BITS_TO_LONGS(1 << (buddy->max_order - i));
> > + s = BITS_TO_LONGS(1UL << (buddy->max_order - i));
> > buddy->bits[i] = kvmalloc_array(s, sizeof(long), GFP_KERNEL |
> > __GFP_ZERO);
> > if (!buddy->bits[i])
> > goto err_out_free;
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [ANNOUNCE] v5.9-rc3-rt3
On Wed, 2020-09-02 at 17:55 +0200, Sebastian Andrzej Siewior wrote: > > Known issues > - It has been pointed out that due to changes to the printk code the >internal buffer representation changed. This is only an issue if tools >like `crash' are used to extract the printk buffer from a kernel memory >image. Ouch. While installing -rt5 on lappy via nfs, -rt5 server box exploded leaving nada in logs. I have a nifty crash dump of the event, but... -Mike
Re: [PATCH net-next] rcu: prevent RCU_LOCKDEP_WARN() from swallowing the condition
From: Jakub Kicinski Date: Tue, 8 Sep 2020 10:36:24 -0700 > We run into a unused variable warning in bridge code when > variable is only used inside the condition of > rcu_dereference_protected(). > > #define mlock_dereference(X, br) \ > rcu_dereference_protected(X, lockdep_is_held(>multicast_lock)) > > Since on builds with CONFIG_PROVE_RCU=n rcu_dereference_protected() > compiles to nothing the compiler doesn't see the variable use. > > Prevent the warning by adding the condition as dead code. > We need to un-hide the declaration of lockdep_tasklist_lock_is_held() > and fix a bug the crept into a net/sched header. > > Signed-off-by: Jakub Kicinski I ended up applying Nikolay's fix, but this situation with the rcu macros needs to be addressed.
Re: [PATCH v2 2/3] soc: sifive: Add SiFive specific Cadence DDR controller driver
On Sun, 06 Sep 2020 23:11:26 PDT (-0700), Christoph Hellwig wrote: On Mon, Sep 07, 2020 at 11:17:58AM +0530, Yash Shah wrote: Add a driver to manage the Cadence DDR controller present on SiFive SoCs At present the driver manages the EDAC feature of the DDR controller. Additional features may be added to the driver in future to control other aspects of the DDR controller. So if this is a generic(ish) Cadence IP block shouldn't it be named Cadence and made generic? Or is the frontend somehow SiFive specific? For some reason I thought we had a SiFive-specific interface to this, but I may have gotten that confused with something else as it's been a while. Someone from SiFive would probably have a better idea, but it looks like the person I'd ask isn't thereany more so I'm all out of options ;) It looks like there was a very similar driver posted by Dhananjay Kangude from Cadence in April: https://lkml.org/lkml/2020/4/6/358 . Some of the register definitions seem to be different, but the code I looked at is very similar so there's at least some bits that could be shared. I found a v4 of that patch set, but that was back in May: https://lkml.org/lkml/2020/5/11/912 . It alludes to a v5, but I can't find one. I've added Dhananjay, maybe he knows what's up? I don't know enough about the block to know if the subtle difference in register names/offsets means. They look properly jumbled up (ie, not just an offset), so maybe there's just different versions or that's the SiFive-specific part I had bouncing around my head? Either way, it seems like one driver with some simple configuration could handle both of these -- either sticking the offsets in the DT (if they're going to be different everywhere) or by coming up with some version sort of thing (if there's a handful of these). I'm now also a bit worried about the provenace of this code. The two drivers are errily similar -- for example, the variable definitions in handle_ce() u64 err_c_addr = 0x0; u64 err_c_data = 0x0; u32 err_c_synd, err_c_id; u32 sig_val_l, sig_val_h; are exactly the same.
Re: [v1,1/3] dt-bindings: Add YAML schemas for Gen3 PCIe controller
On Tue, 2020-09-08 at 13:50 -0600, Rob Herring wrote: > On Mon, 07 Sep 2020 20:08:50 +0800, Jianjun Wang wrote: > > Add YAML schemas documentation for Gen3 PCIe controller on > > MediaTek SoCs. > > > > Acked-by: Ryder Lee > > Signed-off-by: Jianjun Wang > > --- > > .../bindings/pci/mediatek-pcie-gen3.yaml | 158 ++ > > 1 file changed, 158 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.example.dts:55.56-59.19: > Warning (pci_device_reg): > /example-0/bus/pcie@1123/legacy-interrupt-controller: missing PCI reg > property > > > See https://patchwork.ozlabs.org/patch/1359119 > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure dt-schema is up to date: > > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master > --upgrade > > Please check and re-submit. > Yes, I have already found this warning message, but I'm confused with how to add this reg property, since the interrupt-controller has inherit the pci device type but does not have its own registers. Could you please tell me how to fix this error, or which docs can I refer to? Thanks.
Re: [PATCH] fib: fix fib_rule_ops indirect call wrappers when CONFIG_IPV6=m
From: Brian Vazquez
Date: Tue, 8 Sep 2020 09:18:12 -0700
> If CONFIG_IPV6=m, the IPV6 functions won't be found by the linker:
>
> ld: net/core/fib_rules.o: in function `fib_rules_lookup':
> fib_rules.c:(.text+0x606): undefined reference to `fib6_rule_match'
> ld: fib_rules.c:(.text+0x611): undefined reference to `fib6_rule_match'
> ld: fib_rules.c:(.text+0x68c): undefined reference to `fib6_rule_action'
> ld: fib_rules.c:(.text+0x693): undefined reference to `fib6_rule_action'
> ld: fib_rules.c:(.text+0x6aa): undefined reference to `fib6_rule_suppress'
> ld: fib_rules.c:(.text+0x6bc): undefined reference to `fib6_rule_suppress'
> make: *** [Makefile:1166: vmlinux] Error 1
>
> Reported-by: Sven Joachim
> Fixes: b9aaec8f0be5 ("fib: use indirect call wrappers in the most common
> fib_rules_ops")
> Acked-by: Randy Dunlap # build-tested
> Signed-off-by: Brian Vazquez
Applied, thanks.
Re: [RFC V2 0/9] x86/mmu:Introduce parallel memory virtualization to boost performance
Any comments? guys! On Tue, 1 Sep 2020 at 19:52, wrote: > > From: Yulei Zhang > > Currently in KVM memory virtulization we relay on mmu_lock to > synchronize the memory mapping update, which make vCPUs work > in serialize mode and slow down the execution, especially after > migration to do substantial memory mapping will cause visible > performance drop, and it can get worse if guest has more vCPU > numbers and memories. > > The idea we present in this patch set is to mitigate the issue > with pre-constructed memory mapping table. We will fast pin the > guest memory to build up a global memory mapping table according > to the guest memslots changes and apply it to cr3, so that after > guest starts up all the vCPUs would be able to update the memory > simultaneously without page fault exception, thus the performance > improvement is expected. > > We use memory dirty pattern workload to test the initial patch > set and get positive result even with huge page enabled. For example, > we create guest with 32 vCPUs and 64G memories, and let the vcpus > dirty the entire memory region concurrently, as the initial patch > eliminate the overhead of mmu_lock, in 2M/1G huge page mode we would > get the job done in about 50% faster. > > We only validate this feature on Intel x86 platform. And as Ben > pointed out in RFC V1, so far we disable the SMM for resource > consideration, drop the mmu notification as in this case the > memory is pinned. > > V1->V2: > * Rebase the code to kernel version 5.9.0-rc1. > > Yulei Zhang (9): > Introduce new fields in kvm_arch/vcpu_arch struct for direct build EPT > support > Introduce page table population function for direct build EPT feature > Introduce page table remove function for direct build EPT feature > Add release function for direct build ept when guest VM exit > Modify the page fault path to meet the direct build EPT requirement > Apply the direct build EPT according to the memory slots change > Add migration support when using direct build EPT > Introduce kvm module parameter global_tdp to turn on the direct build > EPT mode > Handle certain mmu exposed functions properly while turn on direct > build EPT mode > > arch/mips/kvm/mips.c| 13 + > arch/powerpc/kvm/powerpc.c | 13 + > arch/s390/kvm/kvm-s390.c| 13 + > arch/x86/include/asm/kvm_host.h | 13 +- > arch/x86/kvm/mmu/mmu.c | 533 ++-- > arch/x86/kvm/svm/svm.c | 2 +- > arch/x86/kvm/vmx/vmx.c | 7 +- > arch/x86/kvm/x86.c | 55 ++-- > include/linux/kvm_host.h| 7 +- > virt/kvm/kvm_main.c | 43 ++- > 10 files changed, 639 insertions(+), 60 deletions(-) > > -- > 2.17.1 >
Re: [PATCH net-next] bnx2x: Fix some kernel-doc warnings
From: Wang Hai Date: Tue, 8 Sep 2020 22:01:58 +0800 > Fixes the following W=1 kernel build warning(s): > > drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:4238: warning: Excess > function parameter 'netdev' description in 'bnx2x_setup_tc' > drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:4238: warning: Excess > function parameter 'tc' description in 'bnx2x_setup_tc' > > Reported-by: Hulk Robot > Signed-off-by: Wang Hai Applied.
Re: [PATCH net-next] net: wimax: i2400m: fix 'msg_skb' kernel-doc warning in i2400m_msg_to_dev()
From: Wang Hai Date: Tue, 8 Sep 2020 22:03:33 +0800 > Fixes the following W=1 kernel build warning(s): > > drivers/net/wimax/i2400m/control.c:709: warning: Excess function parameter > 'msg_skb' description in 'i2400m_msg_to_dev' > > This parameter is not in use. Remove it. > > Reported-by: Hulk Robot > Signed-off-by: Wang Hai Applied.
Re: [PATCH stable 4.19 v2 0/2] arm64: entry: Place an SB sequence following an ERET instruction
On 8/24/2020 11:35 AM, Florian Fainelli wrote: Changes in v2: - included missing preliminary patch to define the SB barrier instruction Will Deacon (2): arm64: Add support for SB barrier and patch in over DSB; ISB sequences arm64: entry: Place an SB sequence following an ERET instruction Does anybody at ARM or Android care about those changes? If so, would you be willing to review these? Thanks arch/arm64/include/asm/assembler.h | 13 + arch/arm64/include/asm/barrier.h| 4 arch/arm64/include/asm/cpucaps.h| 3 ++- arch/arm64/include/asm/sysreg.h | 6 ++ arch/arm64/include/asm/uaccess.h| 3 +-- arch/arm64/include/uapi/asm/hwcap.h | 1 + arch/arm64/kernel/cpufeature.c | 12 arch/arm64/kernel/cpuinfo.c | 1 + arch/arm64/kernel/entry.S | 2 ++ arch/arm64/kvm/hyp/entry.S | 1 + arch/arm64/kvm/hyp/hyp-entry.S | 4 11 files changed, 47 insertions(+), 3 deletions(-) -- Florian
Re: [PATCH net-next] netlabel: Fix some kernel-doc warnings
From: Wang Hai Date: Tue, 8 Sep 2020 22:05:43 +0800 > Fixes the following W=1 kernel build warning(s): > > net/netlabel/netlabel_calipso.c:438: warning: Excess function parameter > 'audit_secid' description in 'calipso_doi_remove' > net/netlabel/netlabel_calipso.c:605: warning: Excess function parameter 'reg' > description in 'calipso_req_delattr' > > Reported-by: Hulk Robot > Signed-off-by: Wang Hai Applied.
Re: [PATCH net-next] cipso: fix 'audit_secid' kernel-doc warning in cipso_ipv4.c
From: Wang Hai Date: Tue, 8 Sep 2020 21:59:15 +0800 > Fixes the following W=1 kernel build warning(s): > > net/ipv4/cipso_ipv4.c:510: warning: Excess function parameter 'audit_secid' > description in 'cipso_v4_doi_remove' > > Reported-by: Hulk Robot > Signed-off-by: Wang Hai Applied.
[MPTCP][PATCH net] mptcp: fix kmalloc flag in mptcp_pm_nl_get_local_id
mptcp_pm_nl_get_local_id may be called in interrupt context, so we need to
use GFP_ATOMIC flag to allocate memory to avoid sleeping in atomic context.
[ 280.209809] BUG: sleeping function called from invalid context at
mm/slab.h:498
[ 280.209812] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1680,
name: kworker/1:3
[ 280.209814] INFO: lockdep is turned off.
[ 280.209816] CPU: 1 PID: 1680 Comm: kworker/1:3 Tainted: GW
5.9.0-rc3-mptcp+ #146
[ 280.209818] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
VirtualBox 12/01/2006
[ 280.209820] Workqueue: events mptcp_worker
[ 280.209822] Call Trace:
[ 280.209824]
[ 280.209826] dump_stack+0x77/0xa0
[ 280.209829] ___might_sleep.cold+0xa6/0xb6
[ 280.209832] kmem_cache_alloc_trace+0x1d1/0x290
[ 280.209835] mptcp_pm_nl_get_local_id+0x23c/0x410
[ 280.209840] subflow_init_req+0x1e9/0x2ea
[ 280.209843] ? inet_reqsk_alloc+0x1c/0x120
[ 280.209845] ? kmem_cache_alloc+0x264/0x290
[ 280.209849] tcp_conn_request+0x303/0xae0
[ 280.209854] ? printk+0x53/0x6a
[ 280.209857] ? tcp_rcv_state_process+0x28f/0x1374
[ 280.209859] tcp_rcv_state_process+0x28f/0x1374
[ 280.209864] ? tcp_v4_do_rcv+0xb3/0x1f0
[ 280.209866] tcp_v4_do_rcv+0xb3/0x1f0
[ 280.209869] tcp_v4_rcv+0xed6/0xfa0
[ 280.209873] ip_protocol_deliver_rcu+0x28/0x270
[ 280.209875] ip_local_deliver_finish+0x89/0x120
[ 280.209877] ip_local_deliver+0x180/0x220
[ 280.209881] ip_rcv+0x166/0x210
[ 280.209885] __netif_receive_skb_one_core+0x82/0x90
[ 280.209888] process_backlog+0xd6/0x230
[ 280.209891] net_rx_action+0x13a/0x410
[ 280.209895] __do_softirq+0xcf/0x468
[ 280.209899] asm_call_on_stack+0x12/0x20
[ 280.209901]
[ 280.209903] ? ip_finish_output2+0x240/0x9a0
[ 280.209906] do_softirq_own_stack+0x4d/0x60
[ 280.209908] do_softirq.part.0+0x2b/0x60
[ 280.209911] __local_bh_enable_ip+0x9a/0xa0
[ 280.209913] ip_finish_output2+0x264/0x9a0
[ 280.209916] ? rcu_read_lock_held+0x4d/0x60
[ 280.209920] ? ip_output+0x7a/0x250
[ 280.209922] ip_output+0x7a/0x250
[ 280.209925] ? __ip_finish_output+0x330/0x330
[ 280.209928] __ip_queue_xmit+0x1dc/0x5a0
[ 280.209931] __tcp_transmit_skb+0xa0f/0xc70
[ 280.209937] tcp_connect+0xb03/0xff0
[ 280.209939] ? lockdep_hardirqs_on_prepare+0xe7/0x190
[ 280.209942] ? ktime_get_with_offset+0x125/0x150
[ 280.209944] ? trace_hardirqs_on+0x1c/0xe0
[ 280.209948] tcp_v4_connect+0x449/0x550
[ 280.209953] __inet_stream_connect+0xbb/0x320
[ 280.209955] ? mark_held_locks+0x49/0x70
[ 280.209958] ? lockdep_hardirqs_on_prepare+0xe7/0x190
[ 280.209960] ? __local_bh_enable_ip+0x6b/0xa0
[ 280.209963] inet_stream_connect+0x32/0x50
[ 280.209966] __mptcp_subflow_connect+0x1fd/0x242
[ 280.209972] mptcp_pm_create_subflow_or_signal_addr+0x2db/0x600
[ 280.209975] mptcp_worker+0x543/0x7a0
[ 280.209980] process_one_work+0x26d/0x5b0
[ 280.209984] ? process_one_work+0x5b0/0x5b0
[ 280.209987] worker_thread+0x48/0x3d0
[ 280.209990] ? process_one_work+0x5b0/0x5b0
[ 280.209993] kthread+0x117/0x150
[ 280.209996] ? kthread_park+0x80/0x80
[ 280.209998] ret_from_fork+0x22/0x30
Fixes: 01cacb00b35cb ("mptcp: add netlink-based PM")
Signed-off-by: Geliang Tang
---
net/mptcp/pm_netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c
index bd88e9c0bf71..1f6d029ccf40 100644
--- a/net/mptcp/pm_netlink.c
+++ b/net/mptcp/pm_netlink.c
@@ -354,7 +354,7 @@ int mptcp_pm_nl_get_local_id(struct mptcp_sock *msk, struct
sock_common *skc)
return ret;
/* address not found, add to local list */
- entry = kmalloc(sizeof(*entry), GFP_KERNEL);
+ entry = kmalloc(sizeof(*entry), GFP_ATOMIC);
if (!entry)
return -ENOMEM;
--
2.17.1
Re: [PATCH 2/2] kunit: ubsan integration
Hi Qian, On Thu, 3 Sep 2020 08:38:25 -0400 Qian Cai wrote: > > On Wed, Sep 02, 2020 at 08:52:24AM -0400, Qian Cai wrote: > > On Thu, Aug 06, 2020 at 05:43:26PM +, Uriel Guajardo wrote: > > > Integrates UBSAN into the KUnit testing framework. It fails KUnit tests > > > whenever it reports undefined behavior. > > > > > > Signed-off-by: Uriel Guajardo > > > > It looks like this patch had been merged into linux-next but the "[PATCH > > 1/2] > > kunit: support failure from dynamic analysis tools" did not. Hence, it > > caused a > > compiling failure. > > > > lib/ubsan.c: In function ‘ubsan_prologue’: > > lib/ubsan.c:141:2: error: implicit declaration of function > > ‘kunit_fail_current_test’; did you mean ‘kunit_init_test’? > > [-Werror=implicit-function-declaration] > > kunit_fail_current_test(); > > ^~~ > > kunit_init_test > > cc1: some warnings being treated as errors > > Stephen, Shuah, can you revert this commit or pick up its dependency as well? Sorry, for the slow response ... this should be gone today. -- Cheers, Stephen Rothwell pgpfENtWvT0E3.pgp Description: OpenPGP digital signature
Re: [v4,3/4] reset-controller: ti: introduce a new reset handler
On Thu, 2020-09-03 at 07:40 +0800, Suman Anna wrote:
> Hi Crystal,
>
> On 8/16/20 10:03 PM, Crystal Guo wrote:
> > Introduce ti_syscon_reset() to integrate assert and deassert together.
> > If some modules need do serialized assert and deassert operations
> > to reset itself, reset_control_reset can be called for convenience.
>
> There are multiple changes in this same patch. I think you should split this
> functionality away from the change for the regmap_update_bits() to
> regmap_write_bits(), similar to what you have done in your v2 Patch 4.
>
Thanks for your suggestion.
I will split this patch in the next version.
> >
> > Such as reset-qcom-aoss.c, it integrates assert and deassert together
> > by 'reset' method. MTK Socs also need this method to perform reset.
> >
> > Signed-off-by: Crystal Guo
> > ---
> > drivers/reset/reset-ti-syscon.c | 26 --
> > 1 file changed, 24 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/reset/reset-ti-syscon.c
> > b/drivers/reset/reset-ti-syscon.c
> > index a2635c21db7f..08289342f9af 100644
> > --- a/drivers/reset/reset-ti-syscon.c
> > +++ b/drivers/reset/reset-ti-syscon.c
> > @@ -15,6 +15,7 @@
> > * GNU General Public License for more details.
> > */
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -56,6 +57,7 @@ struct ti_syscon_reset_data {
> > struct regmap *regmap;
> > struct ti_syscon_reset_control *controls;
> > unsigned int nr_controls;
> > + unsigned int reset_duration_us;
> > };
> >
> > #define to_ti_syscon_reset_data(rcdev) \
> > @@ -89,7 +91,7 @@ static int ti_syscon_reset_assert(struct
> > reset_controller_dev *rcdev,
> > mask = BIT(control->assert_bit);
> > value = (control->flags & ASSERT_SET) ? mask : 0x0;
> >
> > - return regmap_update_bits(data->regmap, control->assert_offset, mask,
> > value);
> > + return regmap_write_bits(data->regmap, control->assert_offset, mask,
> > value);
> > }
> >
> > /**
> > @@ -120,7 +122,7 @@ static int ti_syscon_reset_deassert(struct
> > reset_controller_dev *rcdev,
> > mask = BIT(control->deassert_bit);
> > value = (control->flags & DEASSERT_SET) ? mask : 0x0;
> >
> > - return regmap_update_bits(data->regmap, control->deassert_offset, mask,
> > value);
> > + return regmap_write_bits(data->regmap, control->deassert_offset, mask,
> > value);
> > }
> >
> > /**
> > @@ -158,9 +160,26 @@ static int ti_syscon_reset_status(struct
> > reset_controller_dev *rcdev,
> > !(control->flags & STATUS_SET);
> > }
> >
> > +static int ti_syscon_reset(struct reset_controller_dev *rcdev,
> > + unsigned long id)
> > +{
> > + struct ti_syscon_reset_data *data = to_ti_syscon_reset_data(rcdev);
> > + int ret;
> > +
> > + ret = ti_syscon_reset_assert(rcdev, id);
> > + if (ret)
> > + return ret;
> > +
> > + if (data->reset_duration_us)
> > + usleep_range(data->reset_duration_us, data->reset_duration_us *
> > 2);
> > +
> > + return ti_syscon_reset_deassert(rcdev, id);
>
> I echo Philipp's comments [1] from your original v1 series about this. We
> don't
> need a property to distinguish this, but you could add a flag using match data
> and Mediatek compatible, and use that within this function, or optionally set
> this ops based on compatible (whatever is preferred by Philipp).
>
> regards
> Suman
>
> [1] https://patchwork.kernel.org/comment/23519193/
>
Hi Suman, Philipp
Which method would you recommend more?
1. like v2 patch, but assign the flag "data->assert_deassert_together"
directly (maybe rename "assert_deassert_together" to
"reset_op_available")
2. use Mediatek compatible to decide the reset handler available or not.
Thanks
Crystal
> > +}
> > +
> > static const struct reset_control_ops ti_syscon_reset_ops = {
> > .assert = ti_syscon_reset_assert,
> > .deassert = ti_syscon_reset_deassert,
> > + .reset = ti_syscon_reset,
> > .status = ti_syscon_reset_status,
> > };
> >
> > @@ -204,6 +223,9 @@ static int ti_syscon_reset_probe(struct platform_device
> > *pdev)
> > controls[i].flags = be32_to_cpup(list++);
> > }
> >
> > + of_property_read_u32(pdev->dev.of_node, "reset-duration-us",
> > + >reset_duration_us);
> > +
> > data->rcdev.ops = _syscon_reset_ops;
> > data->rcdev.owner = THIS_MODULE;
> > data->rcdev.of_node = np;
> >
>
Re: [PATCH v2 3/5] i2c: aspeed: Mask IRQ status to relevant bits
On Tue, Sep 08, 2020 at 03:00:59PM -0500, Eddie James wrote: > Mask the IRQ status to only the bits that the driver checks. This > prevents excessive driver warnings when operating in slave mode > when additional bits are set that the driver doesn't handle. > > Signed-off-by: Eddie James Reviewed-by: Tao Ren > --- > drivers/i2c/busses/i2c-aspeed.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c > index 31268074c422..2a388911038a 100644 > --- a/drivers/i2c/busses/i2c-aspeed.c > +++ b/drivers/i2c/busses/i2c-aspeed.c > @@ -69,6 +69,7 @@ > * These share bit definitions, so use the same values for the enable & > * status bits. > */ > +#define ASPEED_I2CD_INTR_ALL 0xf000 > #define ASPEED_I2CD_INTR_SDA_DL_TIMEOUT BIT(14) > #define ASPEED_I2CD_INTR_BUS_RECOVER_DONEBIT(13) > #define ASPEED_I2CD_INTR_SLAVE_MATCH BIT(7) > @@ -604,6 +605,7 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void > *dev_id) > writel(irq_received & ~ASPEED_I2CD_INTR_RX_DONE, > bus->base + ASPEED_I2C_INTR_STS_REG); > readl(bus->base + ASPEED_I2C_INTR_STS_REG); > + irq_received &= ASPEED_I2CD_INTR_ALL; > irq_remaining = irq_received; > > #if IS_ENABLED(CONFIG_I2C_SLAVE) > -- > 2.26.2 >
[PATCH RESEND 3/3] KVM: SVM: Reenable handle_fastpath_set_msr_irqoff() after complete_interrupts()
From: Wanpeng Li
Moving the call to svm_exit_handlers_fastpath() after svm_complete_interrupts()
since svm_complete_interrupts() consumes rip and reenable the function
handle_fastpath_set_msr_irqoff() call in svm_exit_handlers_fastpath().
Suggested-by: Sean Christopherson
Cc: Paul K.
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/svm/svm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 74bcf0a..ac819f0 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -3347,6 +3347,11 @@ static void svm_cancel_injection(struct kvm_vcpu *vcpu)
static fastpath_t svm_exit_handlers_fastpath(struct kvm_vcpu *vcpu)
{
+ if (!is_guest_mode(vcpu) &&
+ to_svm(vcpu)->vmcb->control.exit_code == SVM_EXIT_MSR &&
+ to_svm(vcpu)->vmcb->control.exit_info_1)
+ return handle_fastpath_set_msr_irqoff(vcpu);
+
return EXIT_FASTPATH_NONE;
}
@@ -3495,7 +3500,6 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu
*vcpu)
stgi();
/* Any pending NMI will happen here */
- exit_fastpath = svm_exit_handlers_fastpath(vcpu);
if (unlikely(svm->vmcb->control.exit_code == SVM_EXIT_NMI))
kvm_after_interrupt(>vcpu);
@@ -3529,6 +3533,7 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu
*vcpu)
svm_handle_mce(svm);
svm_complete_interrupts(svm);
+ exit_fastpath = svm_exit_handlers_fastpath(vcpu);
vmcb_mark_all_clean(svm->vmcb);
return exit_fastpath;
--
2.7.4
[PATCH RESEND 2/3] KVM: SVM: Move svm_complete_interrupts() into svm_vcpu_run()
From: Wanpeng Li
Moving svm_complete_interrupts() into svm_vcpu_run() which can align VMX
and SVM with respect to completing interrupts.
Suggested-by: Sean Christopherson
Cc: Paul K.
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/svm/svm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index c61bc3b..74bcf0a 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -2938,8 +2938,6 @@ static int handle_exit(struct kvm_vcpu *vcpu, fastpath_t
exit_fastpath)
if (npt_enabled)
vcpu->arch.cr3 = svm->vmcb->save.cr3;
- svm_complete_interrupts(svm);
-
if (is_guest_mode(vcpu)) {
int vmexit;
@@ -3530,6 +3528,8 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu
*vcpu)
SVM_EXIT_EXCP_BASE + MC_VECTOR))
svm_handle_mce(svm);
+ svm_complete_interrupts(svm);
+
vmcb_mark_all_clean(svm->vmcb);
return exit_fastpath;
}
--
2.7.4
[PATCH RESEND 1/3] KVM: SVM: Get rid of handle_fastpath_set_msr_irqoff()
From: Wanpeng Li
Analysis from Sean:
| svm->next_rip is reset in svm_vcpu_run() only after calling
| svm_exit_handlers_fastpath(), which will cause SVM's
| skip_emulated_instruction() to write a stale RIP.
Let's get rid of handle_fastpath_set_msr_irqoff() in
svm_exit_handlers_fastpath()
to have a quick fix.
Reported-by: Paul K.
Suggested-by: Sean Christopherson
Cc: Paul K.
Cc: # v5.8-rc1+
Fixes: 404d5d7bff0d (KVM: X86: Introduce more exit_fastpath_completion enum
values)
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/svm/svm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 19e622a..c61bc3b 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -3349,11 +3349,6 @@ static void svm_cancel_injection(struct kvm_vcpu *vcpu)
static fastpath_t svm_exit_handlers_fastpath(struct kvm_vcpu *vcpu)
{
- if (!is_guest_mode(vcpu) &&
- to_svm(vcpu)->vmcb->control.exit_code == SVM_EXIT_MSR &&
- to_svm(vcpu)->vmcb->control.exit_info_1)
- return handle_fastpath_set_msr_irqoff(vcpu);
-
return EXIT_FASTPATH_NONE;
}
--
2.7.4
[PATCH v4] usb-serial:cp210x: add support to software flow control
From: Wang Sheng Long
When data is transmitted between two serial ports,
the phenomenon of data loss often occurs. The two kinds
of flow control commonly used in serial communication
are hardware flow control and software flow control.
In serial communication, If you only use RX/TX/GND Pins, you
can't do hardware flow. So we often used software flow control
and prevent data loss. The user sets the software flow control
through the application program, and the application program
sets the software flow control mode for the serial port
chip through the driver.
For the cp210 serial port chip, its driver lacks the
software flow control setting code, so the user cannot set
the software flow control function through the application
program. This adds the missing software flow control.
Signed-off-by: Wang Sheng Long
Changes in v3:
- fixed code style, It mainly adjusts the code style acccording
to kernel specification.
Changes in v4:
- It mainly adjusts the patch based on the last usb-next branch
of the usb-serial and optimized the relevant code.
---
drivers/usb/serial/cp210x.c | 125 ++--
1 file changed, 120 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index d0c05aa8a0d6..bcbf8da99ebb 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -412,6 +412,15 @@ struct cp210x_comm_status {
u8 bReserved;
} __packed;
+struct cp210x_special_chars {
+ u8 bEofChar;
+ u8 bErrorChar;
+ u8 bBreakChar;
+ u8 bEventChar;
+ u8 bXonChar;
+ u8 bXoffChar;
+};
+
/*
* CP210X_PURGE - 16 bits passed in wValue of USB request.
* SiLabs app note AN571 gives a strange description of the 4 bits:
@@ -675,6 +684,69 @@ static int cp210x_read_vendor_block(struct usb_serial
*serial, u8 type, u16 val,
return result;
}
+static int cp210x_get_chars(struct usb_serial_port *port, void *buf, int
bufsize)
+{
+ struct usb_serial *serial = port->serial;
+ struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
+ void *dmabuf;
+ int result;
+
+ dmabuf = kmemdup(buf, bufsize, GFP_KERNEL);
+ if (!dmabuf)
+ return -ENOMEM;
+
+ result = usb_control_msg(serial->dev,
+ usb_sndctrlpipe(serial->dev, 0),
+ CP210X_GET_CHARS, REQTYPE_DEVICE_TO_HOST, 0,
+ port_priv->bInterfaceNumber,
+ dmabuf, bufsize, USB_CTRL_SET_TIMEOUT);
+
+ if (result == bufsize) {
+ memcpy(buf, dmabuf, bufsize);
+ result = 0;
+ } else {
+ dev_err(>dev, "failed get req 0x%x size %d status: %d\n",
+ CP210X_GET_CHARS, bufsize, result);
+ if (result >= 0)
+ result = -EIO;
+ }
+
+ kfree(dmabuf);
+
+ return result;
+}
+
+static int cp210x_set_chars(struct usb_serial_port *port, void *buf, int
bufsize)
+{
+ struct usb_serial *serial = port->serial;
+ struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
+ void *dmabuf;
+ int result;
+
+ dmabuf = kmemdup(buf, bufsize, GFP_KERNEL);
+ if (!dmabuf)
+ return -ENOMEM;
+
+ result = usb_control_msg(serial->dev,
+ usb_sndctrlpipe(serial->dev, 0),
+ CP210X_SET_CHARS, REQTYPE_HOST_TO_INTERFACE, 0,
+ port_priv->bInterfaceNumber,
+ dmabuf, bufsize, USB_CTRL_SET_TIMEOUT);
+
+ if (result == bufsize) {
+ result = 0;
+ } else {
+ dev_err(>dev, "failed get req 0x%x size %d status: %d\n",
+ CP210X_SET_CHARS, bufsize, result);
+ if (result >= 0)
+ result = -EIO;
+ }
+
+ kfree(dmabuf);
+
+ return result;
+}
+
/*
* Writes any 16-bit CP210X_ register (req) whose value is passed
* entirely in the wValue field of the USB request.
@@ -1356,11 +1428,17 @@ static void cp210x_set_termios(struct tty_struct *tty,
struct usb_serial_port *port, struct ktermios *old_termios)
{
struct device *dev = >dev;
- unsigned int cflag, old_cflag;
+ unsigned int cflag, old_cflag, iflag;
+ struct cp210x_special_chars charsres;
+ struct cp210x_flow_ctl flow_ctl;
u16 bits;
+ int result;
+ u32 ctl_hs;
+ u32 flow_repl;
cflag = tty->termios.c_cflag;
old_cflag = old_termios->c_cflag;
+ iflag = tty->termios.c_iflag;
if (tty->termios.c_ospeed != old_termios->c_ospeed)
cp210x_change_speed(tty, port, old_termios);
@@ -1434,10 +1512,6 @@ static void cp210x_set_termios(struct tty_struct *tty,
}
if ((cflag & CRTSCTS) !=
[PATCH 2/3] KVM: SVM: Move svm_complete_interrupts() into svm_vcpu_run()
From: Wanpeng Li
Moving svm_complete_interrupts() into svm_vcpu_run() which can align VMX
and SVM with respect to completing interrupts.
Suggested-by: Sean Christopherson
Cc: Paul K.
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/svm/svm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index c61bc3b..74bcf0a 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -2938,8 +2938,6 @@ static int handle_exit(struct kvm_vcpu *vcpu, fastpath_t
exit_fastpath)
if (npt_enabled)
vcpu->arch.cr3 = svm->vmcb->save.cr3;
- svm_complete_interrupts(svm);
-
if (is_guest_mode(vcpu)) {
int vmexit;
@@ -3530,6 +3528,8 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu
*vcpu)
SVM_EXIT_EXCP_BASE + MC_VECTOR))
svm_handle_mce(svm);
+ svm_complete_interrupts(svm);
+
vmcb_mark_all_clean(svm->vmcb);
return exit_fastpath;
}
--
2.7.4
[PATCH 3/3] KVM: SVM: Reenable handle_fastpath_set_msr_irqoff() after complete_interrupts()
From: Wanpeng Li
Moving the call to svm_exit_handlers_fastpath() after svm_complete_interrupts()
since svm_complete_interrupts() consumes rip and reenable the function
handle_fastpath_set_msr_irqoff() call in svm_exit_handlers_fastpath().
Suggested-by: Sean Christopherson
Cc: Paul K.
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/svm/svm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 74bcf0a..ac819f0 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -3347,6 +3347,11 @@ static void svm_cancel_injection(struct kvm_vcpu *vcpu)
static fastpath_t svm_exit_handlers_fastpath(struct kvm_vcpu *vcpu)
{
+ if (!is_guest_mode(vcpu) &&
+ to_svm(vcpu)->vmcb->control.exit_code == SVM_EXIT_MSR &&
+ to_svm(vcpu)->vmcb->control.exit_info_1)
+ return handle_fastpath_set_msr_irqoff(vcpu);
+
return EXIT_FASTPATH_NONE;
}
@@ -3495,7 +3500,6 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu
*vcpu)
stgi();
/* Any pending NMI will happen here */
- exit_fastpath = svm_exit_handlers_fastpath(vcpu);
if (unlikely(svm->vmcb->control.exit_code == SVM_EXIT_NMI))
kvm_after_interrupt(>vcpu);
@@ -3529,6 +3533,7 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu
*vcpu)
svm_handle_mce(svm);
svm_complete_interrupts(svm);
+ exit_fastpath = svm_exit_handlers_fastpath(vcpu);
vmcb_mark_all_clean(svm->vmcb);
return exit_fastpath;
--
2.7.4
Re: [PATCH v9 00/24] coresight: allow to build coresight as modules
On Wed, Sep 09, 2020 at 01:53:51AM +0800, Mathieu Poirier wrote:
> Hi Tingwei,
>
> Apologies for the untimely response to this set, I am hoping to get to
> it in the next two weeks.
>
It's fine, Mathieu. Please let me know your comments once you have time.
I'm targeting to get these set merged in 5.10 Kernel.
> Thanks,
> Mathieu
>
> On Wed, 19 Aug 2020 at 23:47, Tingwei Zhang
> wrote:
> >
> > Allow to build coresight as modules. This gives developers the
> feasibility to
> > test their code without reboot.
> >
> > This series is based on below two series.
> >
> > - "coresight: allow to build components as modules"
> >https://lkml.org/lkml/2018/6/5/989
> > - "coresight: make drivers modular"
> >https://lkml.org/lkml/2020/1/17/468
> >
> > Change from v8:
> > Protect etmdrvdata[] by modifying it on relevant CPU (Mathieu and
> Suzuki)
> > Grab the device before allocating memory for the node (Mathieu)
> > Add author of coresight core driver (Mathieu)
> >
> > Change from v7:
> > Depends on below change for ETM hotplug (Sai)
> >
> https://lore.kernel.org/linux-arm-kernel/20200729051310.18436-1-saiprakash
> .ran...@codeaurora.org/
> > Add mutex lock to protect etmdrvdata[] (Suzuki)
> > Add helper function coresight_get_ref() (Suzuki)
> > Reorg replicator and funnel change. Use two patches to support these
> > two drivers. (Suzuki)
> > Add fix tag to "coresight: etm: perf: Fix warning caused by
> etm_setup_aux
> > failure" (Suzuki)
> > Update author of "coresight: cti: Fix bug clearing sysfs links on
> callback"
> >
> > Change from v6:
> > Correct module description for CATU (Mike)
> > Check ect_ret equals 0 and set ect_enabled flag (Mike)
> > Add Tested-by and Reviewed-by from Mike
> >
> > Change from v5:
> > Add below CTI clean up change from Mike into series
> > -https://lists.linaro.org/pipermail/coresight/2020-July/004349.html
> > Increase module reference count when enabling CTI device (Mike)
> >
> > Change from v4:
> > Fix error handling in coresight_grab_devicei() (Greg)
> > Add coresight: cti: Fix remove sysfs link error from Mike
> > -https://lists.linaro.org/pipermail/coresight/2020-July/004275.html
> > Move cti_remove_conn_xrefs() into cti_remove() (Mike)
> > Align patch subject to coresight: : (Mike)
> >
> > Change from v3:
> > Rebase to coresight-next (Mike and Mathieu)
> > Reorder try_get_module() (Suzuki)
> > Clean up etmdrvdata[] in device remote path (Mike)
> > Move cti_remove_conn_xrefs to cti_remove (Mike)
> >
> > Change from v2:
> > Rebase to 5.8-rc5. Export coresight_add_sysfs_link and
> > coresight_remove_sysfs_link
> > Fix one cut and paste error on MODULE_DESCRIPTION of CTI
> >
> > Change from v1:
> > Use try_module_get() to avoid module to be unloaded when device is used
> > in active trace session. (Mathieu P)
> >
> > Change from above two series.
> > This series adds the support to dynamically remove module when the
> device in
> > that module is enabled and used by some trace path. It disables all
> trace
> > paths with that device and release the trace path.
> >
> > Kim Phillips (8):
> > coresight: use IS_ENABLED for CONFIGs that may be modules
> > coresight: etm3x: allow etm3x to be built as a module
> > coresight: etm4x: allow etm4x to be built as a module
> > coresight: etb: allow etb to be built as a module
> > coresight: tpiu: allow tpiu to be built as a module
> > coresight: tmc: allow tmc to be built as a module
> > coresight: allow funnel driver to be built as module
> > coresight: allow replicator driver to be built as module
> >
> > Mian Yousaf Kaukab (2):
> > coresight: export global symbols
> > coresight: tmc-etr: add function to register catu ops
> >
> > Mike Leach (2):
> > coresight: cti: Fix remove sysfs link error
> > coresight: cti: Fix bug clearing sysfs links on callback
> >
> > Tingwei Zhang (12):
> > coresight: cpu_debug: add module name in Kconfig
> > coresight: cpu_debug: define MODULE_DEVICE_TABLE
> > coresight: add coresight prefix to barrier_pkt
> > coresight: add try_get_module() in coresight_grab_device()
> > coresight: stm: allow to build coresight-stm as a module
> > coresight: etm: perf: Fix warning caused by etm_setup_aux failure
> > coresight: cti: add function to register cti associate ops
> > coresight: cti: don't disable ect device if it's not enabled
> > coresight: cti: increase reference count when enabling cti
> > coresight: cti: allow cti to be built as a module
> > coresight: catu: allow catu drivers to be built as modules
> > coresight: allow the coresight core driver to be built as a module
> >
> > drivers/hwtracing/coresight/Kconfig | 54 --
> > drivers/hwtracing/coresight/Makefile | 22 +--
> > drivers/hwtracing/coresight/coresight-catu.c | 37 -
> > drivers/hwtracing/coresight/coresight-catu.h | 2 -
> > .../{coresight.c => coresight-core.c} | 154 +++---
> > .../hwtracing/coresight/coresight-cpu-debug.c | 2 +
> >
[PATCH 1/3] KVM: SVM: Get rid of handle_fastpath_set_msr_irqoff()
From: Wanpeng Li
Analysis from Sean:
| svm->next_rip is reset in svm_vcpu_run() only after calling
| svm_exit_handlers_fastpath(), which will cause SVM's
| skip_emulated_instruction() to write a stale RIP.
Let's get rid of handle_fastpath_set_msr_irqoff() in
svm_exit_handlers_fastpath()
to have a quick fix.
Reported-by: Paul K.
Suggested-by: Sean Christopherson
Cc: Paul K.
Cc: # v5.8-rc1+
Fixes: 404d5d7bff0d (KVM: X86: Introduce more exit_fastpath_completion enum
values)
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/svm/svm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 19e622a..c61bc3b 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -3349,11 +3349,6 @@ static void svm_cancel_injection(struct kvm_vcpu *vcpu)
static fastpath_t svm_exit_handlers_fastpath(struct kvm_vcpu *vcpu)
{
- if (!is_guest_mode(vcpu) &&
- to_svm(vcpu)->vmcb->control.exit_code == SVM_EXIT_MSR &&
- to_svm(vcpu)->vmcb->control.exit_info_1)
- return handle_fastpath_set_msr_irqoff(vcpu);
-
return EXIT_FASTPATH_NONE;
}
--
2.7.4
Re: [net-next] net: smsc911x: Remove unused variables
From: Wei Xu Date: Tue, 8 Sep 2020 11:49:25 +0800 > Fixes the following W=1 kernel build warning(s): > > drivers/net/ethernet/smsc/smsc911x.c: In function ‘smsc911x_rx_fastforward’: > drivers/net/ethernet/smsc/smsc911x.c:1199:16: warning: variable ‘temp’ set > but not used [-Wunused-but-set-variable] > > drivers/net/ethernet/smsc/smsc911x.c: In function > ‘smsc911x_eeprom_write_location’: > drivers/net/ethernet/smsc/smsc911x.c:2058:6: warning: variable ‘temp’ set > but not used [-Wunused-but-set-variable] > > Signed-off-by: Wei Xu Applied, thank you.
Re: [PATCH 0/4] scsi: ufs-mediatek: Fixes for kernel v5.10
Stanley, > This series fix some defects and introduce host reset mechanism in > MediaTek UFS platforms. Please consider this patch series for kernel > v5.10. Applied to the 5.10 SCSI staging tree. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH net-next 0/7] net: hns3: misc updates
From: Jakub Kicinski Date: Tue, 8 Sep 2020 12:05:38 -0700 > On Tue, 8 Sep 2020 10:59:47 +0800 Huazhong Tan wrote: >> There are some misc updates for the HNS3 ethernet driver. >> >> #1 narrows two local variable range in hclgevf_reset_prepare_wait(). >> #2 adds reset failure check in periodic service task. >> #3~#7 adds some cleanups. > > Looks trivial: > > Reviewed-by: Jakub Kicinski Series applied, thanks everyone.
Re: [PATCH v18 00/32] per memcg lru_lock
On Thu, Aug 27, 2020 at 09:40:22PM -0400, Daniel Jordan wrote: > I went back to your v1 post to see what motivated you originally, and you had > some results from aim9 but nothing about where this reared its head in the > first place. How did you discover the bottleneck? I'm just curious about how > lru_lock hurts in practice. I think making lru_lock per-memcg helps in colocated environment: some workloads are of high priority while some workloads are of low priority. For these low priority workloads, we may even want to use some swap for it to save memory and this can cause frequent alloc/reclaim, depending on its workingset etc. and these alloc/reclaim need to hold the global lru lock and zone lock. And then when the high priority workloads do page fault, their performance can be adversely affected and that is not acceptible since these high priority workloads normally have strict SLA requirement.
Re: [PATCH v2 1/2] dt-bindings: spmi: document binding for the Mediatek SPMI controller
Hi, On Tue, 2020-09-08 at 14:49 -0600, Rob Herring wrote: > On Fri, Aug 21, 2020 at 06:44:36PM +0800, Hsin-Hsiung Wang wrote: > > This adds documentation for the SPMI controller found on Mediatek SoCs. > > > > Signed-off-by: Hsin-Hsiung Wang > > --- > > .../devicetree/bindings/spmi/spmi-mtk-pmif.txt | 33 > > ++ > > 1 file changed, 33 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/spmi/spmi-mtk-pmif.txt > > Bindings are in DT schema format now. Please convert this. > > Rob Thanks, I will update it with correct format in next patch.
Re: [PATCH next v2 0/3] soc: ti: k3: ringacc: add am65x sr2.0 support
On 9/8/20 3:09 PM, Suman Anna wrote:
Hi Santosh,
On 8/31/20 1:34 PM, santosh.shilim...@oracle.com wrote:
On 8/29/20 11:41 AM, Grygorii Strashko wrote:
Hi Santosh,
I've rebased on top of linux-next and identified merge conflict of patch 3
with commit 6da45875fa17 ("arm64: dts: k3-am65: Update the RM resource types")
in -next.
---
This series adds support for the TI AM65x SR2.0 SoC Ringacc which has fixed
errata i2023 "RINGACC, UDMA: RINGACC and UDMA Ring State Interoperability
Issue after Channel Teardown". This errata also fixed for J271E SoC.
The SOC bus chipinfo data is used to identify the SoC and configure
i2023 errata W/A.
This changes made "ti,dma-ring-reset-quirk" DT property obsolete, so it's
removed.
Changes in v2:
- no functional changes
- rebased on top of linux-next
- added ask from Rob Herring
Thanks. Can you please followup DT acks for PRUSS series so that I can
apply PRUSS + $subject series.
PRUSS dt binding is acked now, so can you pick up the PRUSS v2 series for 5.10
merge window.
Yes, I saw ack from Rob. Will try to get to this over coming weekend.
Regards,
Santosh
RE: [PATCH] Revert "block: revert back to synchronous request_queue removal"
Ming, Got it, will try and give you feedback. Thanks, -Original Message- From: Ming Lei Sent: Wednesday, September 9, 2020 10:39 AM To: Zhao, Haifeng Cc: Christoph Hellwig ; ax...@kernel.dk; bhelg...@google.com; linux-bl...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; mcg...@kernel.org; Zhang, ShanshanX ; Jia, Pei P Subject: Re: [PATCH] Revert "block: revert back to synchronous request_queue removal" Hello Haifeng, On Wed, Sep 09, 2020 at 02:11:20AM +, Zhao, Haifeng wrote: > Ming, Christoph, > Could you point out the patch aimed to fix this issue ? I would like to > try it. This issue blocked my other PCI patch developing and verification > work, > I am not a BLOCK/NVMe expert, wouldn't to be trapped into other sub-system > bugs, so just reported it for other expert's quick fix. > Please try the following patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cafe01ef8fcb248583038e1be071383530fe355a Thanks, Ming
Re: v5.9-rc3-rt3 boot time networking lockdep splat
On Tue, 2020-09-08 at 17:06 +0200, Sebastian Andrzej Siewior wrote: > > This should cure it: It did. -Mike
Re: [PATCH] Revert "block: revert back to synchronous request_queue removal"
Hello Haifeng, On Wed, Sep 09, 2020 at 02:11:20AM +, Zhao, Haifeng wrote: > Ming, Christoph, > Could you point out the patch aimed to fix this issue ? I would like to > try it. This issue blocked my other PCI patch developing and verification > work, > I am not a BLOCK/NVMe expert, wouldn't to be trapped into other sub-system > bugs, so just reported it for other expert's quick fix. > Please try the following patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cafe01ef8fcb248583038e1be071383530fe355a Thanks, Ming
linux-next: build warning after merge of the pci tree
Hi all,
After merging the pci tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
WARNING: modpost: "dw_pcie_link_set_max_speed" [vmlinux] is a static
EXPORT_SYMBOL_GPL
Introduced by commit
3af45d34d30c ("PCI: dwc: Centralize link gen setting")
--
Cheers,
Stephen Rothwell
pgpR7ZKuyf9ts.pgp
Description: OpenPGP digital signature
