Re: [RFC PATCH 10/24] vdpa: introduce config operations for associating ASID to a virtqueue group
On Fri, Oct 09, 2020 at 11:56:45AM +0800, Jason Wang wrote: > > On 2020/10/1 下午9:29, Eli Cohen wrote: > > On Thu, Sep 24, 2020 at 11:21:11AM +0800, Jason Wang wrote: > > > This patch introduces a new bus operation to allow the vDPA bus driver > > > to associate an ASID to a virtqueue group. > > > > > So in case of virtio_net, I would expect that all the data virtqueues > > will be associated with the same address space identifier. > > > Right. > > I will add the codes to do this in the next version. It should be more > explicit than have this assumption by default. > > > > Moreover, > > this assignment should be provided before the set_map call that provides > > the iotlb for the address space, correct? > > > I think it's better not have this limitation, note that set_map() now takes > a asid argument. > > So for hardware if the associated as is changed, the driver needs to program > the hardware to switch to the new mapping. > > Does this work for mlx5? > So in theory we can have several asid's (for different virtqueues), each one should be followed by a specific set_map call. If this is so, how do I know if I met all the conditions run my driver? Maybe we need another callback to let the driver know it should not expect more set_maps().
Re: [PATCH 1/5] rxrpc: use semicolons rather than commas to separate statements
Julia Lawall wrote: > - call->completion = compl, > + call->completion = compl; Looks good. Do you want me to pick up the patch or send it yourself? If the latter: Acked-by: David Howells
[PATCH 2/6] perf inject: Add missing callbacks in perf_tool
I found some events (like PERF_RECORD_CGROUP) are not copied by perf
inject due to the missing callbacks. Let's add them.
While at it, I've changed the order of the callbacks to match with
struct perf_tool so that we can compare them easily.
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-inject.c | 36 +++-
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index e4d78f11494e..2c5e23d73a8a 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -97,6 +97,13 @@ static int perf_event__repipe_op2_synth(struct perf_session
*session,
return perf_event__repipe_synth(session->tool, event);
}
+static int perf_event__repipe_op4_synth(struct perf_session *session,
+ union perf_event *event,
+ u64 data __maybe_unused)
+{
+ return perf_event__repipe_synth(session->tool, event);
+}
+
static int perf_event__repipe_attr(struct perf_tool *tool,
union perf_event *event,
struct evlist **pevlist)
@@ -115,6 +122,13 @@ static int perf_event__repipe_attr(struct perf_tool *tool,
return perf_event__repipe_synth(tool, event);
}
+static int perf_event__repipe_event_update(struct perf_tool *tool,
+ union perf_event *event,
+ struct evlist **pevlist
__maybe_unused)
+{
+ return perf_event__repipe_synth(tool, event);
+}
+
#ifdef HAVE_AUXTRACE_SUPPORT
static int copy_bytes(struct perf_inject *inject, int fd, off_t size)
@@ -707,9 +721,12 @@ int cmd_inject(int argc, const char **argv)
struct perf_inject inject = {
.tool = {
.sample = perf_event__repipe_sample,
+ .read = perf_event__repipe_sample,
.mmap = perf_event__repipe,
.mmap2 = perf_event__repipe,
.comm = perf_event__repipe,
+ .namespaces = perf_event__repipe,
+ .cgroup = perf_event__repipe,
.fork = perf_event__repipe,
.exit = perf_event__repipe,
.lost = perf_event__repipe,
@@ -717,19 +734,28 @@ int cmd_inject(int argc, const char **argv)
.aux= perf_event__repipe,
.itrace_start = perf_event__repipe,
.context_switch = perf_event__repipe,
- .read = perf_event__repipe_sample,
.throttle = perf_event__repipe,
.unthrottle = perf_event__repipe,
+ .ksymbol= perf_event__repipe,
+ .bpf= perf_event__repipe,
+ .text_poke = perf_event__repipe,
.attr = perf_event__repipe_attr,
+ .event_update = perf_event__repipe_event_update,
.tracing_data = perf_event__repipe_op2_synth,
- .auxtrace_info = perf_event__repipe_op2_synth,
- .auxtrace = perf_event__repipe_auxtrace,
- .auxtrace_error = perf_event__repipe_op2_synth,
- .time_conv = perf_event__repipe_op2_synth,
.finished_round = perf_event__repipe_oe_synth,
.build_id = perf_event__repipe_op2_synth,
.id_index = perf_event__repipe_op2_synth,
+ .auxtrace_info = perf_event__repipe_op2_synth,
+ .auxtrace_error = perf_event__repipe_op2_synth,
+ .time_conv = perf_event__repipe_op2_synth,
+ .thread_map = perf_event__repipe_op2_synth,
+ .cpu_map= perf_event__repipe_op2_synth,
+ .stat_config= perf_event__repipe_op2_synth,
+ .stat = perf_event__repipe_op2_synth,
+ .stat_round = perf_event__repipe_op2_synth,
.feature= perf_event__repipe_op2_synth,
+ .compressed = perf_event__repipe_op4_synth,
+ .auxtrace = perf_event__repipe_auxtrace,
},
.input_name = "-",
.samples = LIST_HEAD_INIT(inject.samples),
--
2.28.0.1011.ga647a8990f-goog
[PATCH 1/6] perf bench: Add build-id injection benchmark
Sometimes I can see perf record piped with perf inject take long time
processing build-id. So add inject-build-id benchmark to the
internals benchmark suite to measure its overhead regularly.
It runs perf inject command internally and feeds the given number of
synthesized events (MMAP2 + SAMPLE basically).
Usage: perf bench internals inject-build-id
-i, --iterations Number of iterations used to compute average
(default: 100)
-m, --nr-mmaps Number of mmap events for each iteration (default:
100)
-n, --nr-samples Number of sample events per mmap event (default: 100)
-v, --verbose be more verbose (show iteration count, DSO name, etc)
By default, it measures average processing time of 100 MMAP2 events
and 1 SAMPLE events. Below is a result on my laptop.
$ perf bench internals inject-build-id
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 25.789 msec (+- 0.202 msec)
Average time per event: 2.528 usec (+- 0.020 usec)
Average memory usage: 8411 KB (+- 7 KB)
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/bench/Build| 1 +
tools/perf/bench/bench.h | 1 +
tools/perf/bench/inject-buildid.c | 460 ++
tools/perf/builtin-bench.c| 1 +
tools/perf/builtin-inject.c | 9 +-
tools/perf/util/build-id.h| 4 +
6 files changed, 471 insertions(+), 5 deletions(-)
create mode 100644 tools/perf/bench/inject-buildid.c
diff --git a/tools/perf/bench/Build b/tools/perf/bench/Build
index dd68a40a790c..8b52591338d6 100644
--- a/tools/perf/bench/Build
+++ b/tools/perf/bench/Build
@@ -12,6 +12,7 @@ perf-y += epoll-ctl.o
perf-y += synthesize.o
perf-y += kallsyms-parse.o
perf-y += find-bit-bench.o
+perf-y += inject-buildid.o
perf-$(CONFIG_X86_64) += mem-memcpy-x86-64-lib.o
perf-$(CONFIG_X86_64) += mem-memcpy-x86-64-asm.o
diff --git a/tools/perf/bench/bench.h b/tools/perf/bench/bench.h
index 2804812d4154..eac36afab2b3 100644
--- a/tools/perf/bench/bench.h
+++ b/tools/perf/bench/bench.h
@@ -47,6 +47,7 @@ int bench_epoll_wait(int argc, const char **argv);
int bench_epoll_ctl(int argc, const char **argv);
int bench_synthesize(int argc, const char **argv);
int bench_kallsyms_parse(int argc, const char **argv);
+int bench_inject_build_id(int argc, const char **argv);
#define BENCH_FORMAT_DEFAULT_STR "default"
#define BENCH_FORMAT_DEFAULT 0
diff --git a/tools/perf/bench/inject-buildid.c
b/tools/perf/bench/inject-buildid.c
new file mode 100644
index ..0fccf2a9e95b
--- /dev/null
+++ b/tools/perf/bench/inject-buildid.c
@@ -0,0 +1,460 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "bench.h"
+#include "util/data.h"
+#include "util/stat.h"
+#include "util/debug.h"
+#include "util/event.h"
+#include "util/symbol.h"
+#include "util/session.h"
+#include "util/build-id.h"
+#include "util/synthetic-events.h"
+
+#define MMAP_DEV_MAJOR 8
+#define DSO_MMAP_RATIO 4
+
+static unsigned int iterations = 100;
+static unsigned int nr_mmaps = 100;
+static unsigned int nr_samples = 100; /* samples per mmap */
+
+static u64 bench_sample_type;
+static u16 bench_id_hdr_size;
+
+struct bench_data {
+ int pid;
+ int input_pipe[2];
+ int output_pipe[2];
+ pthread_t th;
+};
+
+struct bench_dso {
+ struct list_headlist;
+ char*name;
+ int ino;
+};
+
+static int nr_dsos;
+static struct bench_dso *dsos;
+
+extern int cmd_inject(int argc, const char *argv[]);
+
+static const struct option options[] = {
+ OPT_UINTEGER('i', "iterations", &iterations,
+"Number of iterations used to compute average (default:
100)"),
+ OPT_UINTEGER('m', "nr-mmaps", &nr_mmaps,
+"Number of mmap events for each iteration (default: 100)"),
+ OPT_UINTEGER('n', "nr-samples", &nr_samples,
+"Number of sample events per mmap event (default: 100)"),
+ OPT_INCR('v', "verbose", &verbose,
+"be more verbose (show iteration count, DSO name, etc)"),
+ OPT_END()
+};
+
+static const char *const bench_usage[] = {
+ "perf bench internals inject-build-id ",
+ NULL
+};
+
+/*
+ * Helper for collect_dso that adds the given file as a dso to dso_list
+ * if it contains a build-id. Stops after collecting 4 times more than
+ * we need (for MMAP2 events).
+ */
+static int add_dso(const char *fpath, const struct stat *sb __maybe_unused,
+ int typeflag, struct FTW *ftwbuf __maybe_unused)
+{
+ struct bench_dso *dso = &dsos[nr_dsos];
+ unsigned char build_id[BUILD_ID_SIZE];
+
+ if (typeflag == FTW_D || typeflag
Re: [PATCH 1/3] dt-bindings: pwm: Add binding for RPi firmware PWM bus
On Fri, Oct 09, 2020 at 05:30:28PM +0200, Nicolas Saenz Julienne wrote: > The PWM bus controlling the fan in RPi's official PoE hat can only be > controlled by the board's co-processor. > > Signed-off-by: Nicolas Saenz Julienne > --- > .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 21 +++ > .../pwm/raspberrypi,firmware-pwm.h| 13 > 2 files changed, 34 insertions(+) > create mode 100644 include/dt-bindings/pwm/raspberrypi,firmware-pwm.h > > diff --git > a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml > b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml > index a2c63c8b1d10..dcaf00e8602e 100644 > --- > a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml > +++ > b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml > @@ -64,6 +64,22 @@ properties: >- compatible >- "#reset-cells" > > + pwm: > +type: object > + > +properties: > + compatible: > +const: raspberrypi,firmware-pwm > + > + "#pwm-cells": > +const: 1 > +description: > > + The argument is the PWM bus number. This is wrong. #pwm-cells specifies the number of "arguments" for phandles pointing to this node. And I would prefer this being 2 to match the stuff described in the generic pwm binding. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
[PATCH 3/6] perf inject: Enter namespace when reading build-id
It should be in a proper mnt namespace when accessing the file.
I think this had no problem since the build-id was actually read from
map__load() -> dso__load() already. But I'd like to change it in the
following commit.
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-inject.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 2c5e23d73a8a..670157db2502 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -23,6 +23,7 @@
#include "util/symbol.h"
#include "util/synthetic-events.h"
#include "util/thread.h"
+#include "util/namespaces.h"
#include
#include
@@ -419,16 +420,19 @@ static int perf_event__repipe_tracing_data(struct
perf_session *session,
static int dso__read_build_id(struct dso *dso)
{
+ struct nscookie nsc;
+
if (dso->has_build_id)
return 0;
+ nsinfo__mountns_enter(dso->nsinfo, &nsc);
if (filename__read_build_id(dso->long_name, dso->build_id,
sizeof(dso->build_id)) > 0) {
dso->has_build_id = true;
- return 0;
}
+ nsinfo__mountns_exit(&nsc);
- return -1;
+ return dso->has_build_id ? 0 : -1;
}
static int dso__inject_build_id(struct dso *dso, struct perf_tool *tool,
--
2.28.0.1011.ga647a8990f-goog
[PATCHSET v4 0/6] perf inject: Speed build-id injection
Hello, This is the new version of speed up build-id injection. As this is to improve performance, I've added a benchmark for it. Please look at the usage in the first commit. By default, it measures average processing time of 100 MMAP2 events and 1 SAMPLE events. Below is the current result on my laptop. $ perf bench internals inject-build-id # Running 'internals/inject-build-id' benchmark: Average build-id injection took: 25.789 msec (+- 0.202 msec) Average time per event: 2.528 usec (+- 0.020 usec) Average memory usage: 8411 KB (+- 7 KB) With this patchset applied, it got this: $ perf bench internals inject-build-id # Running 'internals/inject-build-id' benchmark: Average build-id injection took: 20.838 msec (+- 0.093 msec) Average time per event: 2.043 usec (+- 0.009 usec) Average memory usage: 8261 KB (+- 0 KB) Average build-id-all injection took: 19.361 msec (+- 0.118 msec) Average time per event: 1.898 usec (+- 0.012 usec) Average memory usage: 7440 KB (+- 0 KB) Real usecases might be different as it depends on the number of mmap/sample events as well as how many DSOs are actually hit. The benchmark result now includes memory footprint in terms of maximum RSS. Also I've update the benchmark code to use timestamp so that it can be queued to the ordered_events (and flushed at the end). It's also important how well it sorts the input events in the queue so I randomly chose a timestamp at the beginning of each MMAP event injection to resemble actual behavior. As I said in other thread, perf inject currently doesn't flush the input events and processes all at the end. This gives a good speedup but spends more memory (in proprotion to the input size). While the build-id-all injection bypasses the queue so it uses less memory as well as faster processing. The downside is that it'll mark all DSOs as hit so later processing steps (like perf report) likely handle them unnecessarily. This code is available at 'perf/inject-speedup-v4' branch on git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git Changes from v3: - add timestamp to the synthesized events in the benchmark - add a separate thread to read pipe in the benchmark Changes from v2: - fix benchmark to read required data - add Acked-by from Jiri and Ian - pass map flag to check huge pages (Jiri) - add comments on some functions (Ian) - show memory (max-RSS) usage in the benchmark (Ian) - drop build-id marking patch at the last (Adrian) Namhyung Kim (6): perf bench: Add build-id injection benchmark perf inject: Add missing callbacks in perf_tool perf inject: Enter namespace when reading build-id perf inject: Do not load map/dso when injecting build-id perf inject: Add --buildid-all option perf bench: Run inject-build-id with --buildid-all option too tools/perf/Documentation/perf-inject.txt | 6 +- tools/perf/bench/Build | 1 + tools/perf/bench/bench.h | 1 + tools/perf/bench/inject-buildid.c| 457 +++ tools/perf/builtin-bench.c | 1 + tools/perf/builtin-inject.c | 199 -- tools/perf/util/build-id.h | 4 + tools/perf/util/map.c| 17 +- tools/perf/util/map.h| 14 + 9 files changed, 645 insertions(+), 55 deletions(-) create mode 100644 tools/perf/bench/inject-buildid.c -- 2.28.0.681.g6f77f65b4e-goog *** BLURB HERE *** Namhyung Kim (6): perf bench: Add build-id injection benchmark perf inject: Add missing callbacks in perf_tool perf inject: Enter namespace when reading build-id perf inject: Do not load map/dso when injecting build-id perf inject: Add --buildid-all option perf bench: Run inject-build-id with --buildid-all option too tools/perf/Documentation/perf-inject.txt | 6 +- tools/perf/bench/Build | 1 + tools/perf/bench/bench.h | 1 + tools/perf/bench/inject-buildid.c| 476 +++ tools/perf/builtin-bench.c | 1 + tools/perf/builtin-inject.c | 199 -- tools/perf/util/build-id.h | 4 + tools/perf/util/map.c| 17 +- tools/perf/util/map.h| 14 + 9 files changed, 664 insertions(+), 55 deletions(-) create mode 100644 tools/perf/bench/inject-buildid.c -- 2.28.0.1011.ga647a8990f-goog
[PATCH 4/6] perf inject: Do not load map/dso when injecting build-id
No need to load symbols in a DSO when injecting build-id. I guess the
reason was to check the DSO is a special file like anon files. Use
some helper functions in map.c to check them before reading build-id.
Also pass sample event's cpumode to a new build-id event.
It brought a speedup in the benchmark of 25 -> 21 msec on my laptop.
Also the memory usage (Max RSS) went down by ~200 KB.
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 21.389 msec (+- 0.138 msec)
Average time per event: 2.097 usec (+- 0.014 usec)
Average memory usage: 8225 KB (+- 0 KB)
Original-patch-by: Stephane Eranian
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-inject.c | 33 -
tools/perf/util/map.c | 17 +
tools/perf/util/map.h | 14 ++
3 files changed, 27 insertions(+), 37 deletions(-)
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 670157db2502..248cd9f3e5bb 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -24,9 +24,10 @@
#include "util/synthetic-events.h"
#include "util/thread.h"
#include "util/namespaces.h"
-#include
+#include
#include
+#include /* To get things like MAP_HUGETLB even on older
libc headers */
#include
#include
@@ -436,21 +437,22 @@ static int dso__read_build_id(struct dso *dso)
}
static int dso__inject_build_id(struct dso *dso, struct perf_tool *tool,
- struct machine *machine)
+ struct machine *machine, u8 cpumode, u32 flags)
{
- u16 misc = PERF_RECORD_MISC_USER;
int err;
+ if (is_anon_memory(dso->long_name) || flags & MAP_HUGETLB)
+ return 0;
+ if (is_no_dso_memory(dso->long_name))
+ return 0;
+
if (dso__read_build_id(dso) < 0) {
pr_debug("no build_id found for %s\n", dso->long_name);
return -1;
}
- if (dso->kernel)
- misc = PERF_RECORD_MISC_KERNEL;
-
- err = perf_event__synthesize_build_id(tool, dso, misc,
perf_event__repipe,
- machine);
+ err = perf_event__synthesize_build_id(tool, dso, cpumode,
+ perf_event__repipe, machine);
if (err) {
pr_err("Can't synthesize build_id event for %s\n",
dso->long_name);
return -1;
@@ -477,19 +479,8 @@ int perf_event__inject_buildid(struct perf_tool *tool,
union perf_event *event,
if (thread__find_map(thread, sample->cpumode, sample->ip, &al)) {
if (!al.map->dso->hit) {
al.map->dso->hit = 1;
- if (map__load(al.map) >= 0) {
- dso__inject_build_id(al.map->dso, tool,
machine);
- /*
-* If this fails, too bad, let the other side
-* account this as unresolved.
-*/
- } else {
-#ifdef HAVE_LIBELF_SUPPORT
- pr_warning("no symbols found in %s, maybe "
- "install a debug package?\n",
- al.map->dso->long_name);
-#endif
- }
+ dso__inject_build_id(al.map->dso, tool, machine,
+sample->cpumode, al.map->flags);
}
}
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index cc0faf8f1321..8b305e624124 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -27,21 +27,6 @@
static void __maps__insert(struct maps *maps, struct map *map);
-static inline int is_anon_memory(const char *filename, u32 flags)
-{
- return flags & MAP_HUGETLB ||
- !strcmp(filename, "//anon") ||
- !strncmp(filename, "/dev/zero", sizeof("/dev/zero") - 1) ||
- !strncmp(filename, "/anon_hugepage", sizeof("/anon_hugepage") -
1);
-}
-
-static inline int is_no_dso_memory(const char *filename)
-{
- return !strncmp(filename, "[stack", 6) ||
- !strncmp(filename, "/SYSV",5) ||
- !strcmp(filename, "[heap]");
-}
-
static inline int is_android_lib(const char *filename)
{
return strstarts(filename, "/data/app-lib/") ||
@@ -158,7 +143,7 @@ struct map *map__new(struct machine *machine, u64 start,
u64 len,
int anon, no_dso, vdso, android;
android = is_android_lib(filename);
- anon = is_anon_memory(filename, flags);
+ anon = is_anon_memory(filename) || flags & MAP_HUGETLB;
vdso = is_vdso_map(filename);
no_dso = is_no_dso_memory(filename);
map->prot = prot;
diff --git a/tools/perf/util/map.h b/tools/perf/util/
Re: possible deadlock in dev_uc_sync
syzbot has found a reproducer for the following issue on:
HEAD commit:3dd0130f Merge branch 'akpm' (patches from Andrew)
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16b3612050
kernel config: https://syzkaller.appspot.com/x/.config?x=c06bcf3cc963d91c
dashboard link: https://syzkaller.appspot.com/bug?extid=4a0f7bc34e3997a6c7df
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=105cbfb850
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13193ce850
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+4a0f7bc34e3997a6c...@syzkaller.appspotmail.com
==
WARNING: possible circular locking dependency detected
5.9.0-rc8-syzkaller #0 Not tainted
--
syz-executor655/7496 is trying to acquire lock:
888092808280 (&dev_addr_list_lock_key/2){+...}-{2:2}, at: netif_addr_lock
include/linux/netdevice.h:4281 [inline]
888092808280 (&dev_addr_list_lock_key/2){+...}-{2:2}, at:
dev_uc_sync+0xdc/0x190 net/core/dev_addr_lists.c:640
but task is already holding lock:
888087efa280 (&macvlan_netdev_addr_lock_key/1){+...}-{2:2}, at:
netif_addr_lock_bh include/linux/netdevice.h:4292 [inline]
888087efa280 (&macvlan_netdev_addr_lock_key/1){+...}-{2:2}, at:
dev_set_rx_mode net/core/dev.c:8274 [inline]
888087efa280 (&macvlan_netdev_addr_lock_key/1){+...}-{2:2}, at:
__dev_open+0x368/0x4d0 net/core/dev.c:1529
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&macvlan_netdev_addr_lock_key/1){+...}-{2:2}:
_raw_spin_lock_nested+0x30/0x40 kernel/locking/spinlock.c:361
netif_addr_lock include/linux/netdevice.h:4281 [inline]
dev_uc_sync+0xdc/0x190 net/core/dev_addr_lists.c:640
bond_hw_addr_swap drivers/net/bonding/bond_main.c:740 [inline]
bond_change_active_slave+0xc3d/0x20d0
drivers/net/bonding/bond_main.c:1007
bond_select_active_slave+0x28d/0xa40 drivers/net/bonding/bond_main.c:1093
bond_enslave+0x4441/0x49a0 drivers/net/bonding/bond_main.c:1947
do_set_master+0x1c8/0x220 net/core/rtnetlink.c:2517
__rtnl_newlink+0x132a/0x1740 net/core/rtnetlink.c:3469
rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3500
rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5563
netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2470
netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919
sock_sendmsg_nosec net/socket.c:651 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:671
sys_sendmsg+0x6e8/0x810 net/socket.c:2353
___sys_sendmsg+0xf3/0x170 net/socket.c:2407
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
-> #0 (&dev_addr_list_lock_key/2){+...}-{2:2}:
check_prev_add kernel/locking/lockdep.c:2496 [inline]
check_prevs_add kernel/locking/lockdep.c:2601 [inline]
validate_chain kernel/locking/lockdep.c:3218 [inline]
__lock_acquire+0x2a96/0x5780 kernel/locking/lockdep.c:4441
lock_acquire+0x1f3/0xaf0 kernel/locking/lockdep.c:5029
_raw_spin_lock_nested+0x30/0x40 kernel/locking/spinlock.c:361
netif_addr_lock include/linux/netdevice.h:4281 [inline]
dev_uc_sync+0xdc/0x190 net/core/dev_addr_lists.c:640
macvlan_set_mac_lists+0x55/0x110 drivers/net/macvlan.c:802
__dev_set_rx_mode+0x1e2/0x2e0 net/core/dev.c:8269
dev_set_rx_mode net/core/dev.c:8275 [inline]
__dev_open+0x370/0x4d0 net/core/dev.c:1529
dev_open net/core/dev.c:1557 [inline]
dev_open+0xe8/0x150 net/core/dev.c:1550
bond_enslave+0x927/0x49a0 drivers/net/bonding/bond_main.c:1728
do_set_master+0x1c8/0x220 net/core/rtnetlink.c:2517
__rtnl_newlink+0x132a/0x1740 net/core/rtnetlink.c:3469
rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3500
rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5563
netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2470
netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919
sock_sendmsg_nosec net/socket.c:651 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:671
sys_sendmsg+0x6e8/0x810 net/socket.c:2353
___sys_sendmsg+0xf3/0x170 net/socket.c:2407
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
Re: use case for register_pstore_blk?
On Wed, Oct 07, 2020 at 12:17:25PM -0700, Kees Cook wrote: > Do you mean psblk_generic_blk_read() and psblk_generic_blk_write()? > These are for writing to the block device... I'm happy to adjust this > if you can show me the better API. (This was being developed in the > middle of the iov_iter changes, so perhaps I missed a more appropriate > way to do things.) The problem is that you use library function for file systems, and then call them on an instance you don't own, and you're feeding crap into them like your own methods. Now given that as far as I can tell you require 4k aligned reads and writes anyway, there doesn't seem to be any need for this whole page cache dance to start with, and you could just do the completely trivial bios submission. But if for some reason you need to use the page cache, that needs to be done through fs/block_dev.c APIs instead of through the side. > > > and it uses name_to_dev_t which must not be used in new code. > > What? > > include/linux/mount.h: > extern dev_t name_to_dev_t(const char *name); It used to be a private API, but then the Chromium folks just exported it in e6e20a7a5f3f49bfee518d5c6849107398d83912 without consulting any relevant maintainer. And now we have this mess :( > Where did this happen, where was it documented, and what should be used > instead? Use blkdev_get_by_path only. If you look at blkdev_get_by_dev it has this very explicit comment: * Use it ONLY if you really do not have anything better - i.e. when * you are behind a truly sucky interface and all you are given is a * device number. _Never_ to be used for internal purposes. If you * ever need it - reconsider your API. > > It also does not happen to share code with the mtd case. > > What? Yes it does: it explicitly uses the pstore/blk configuration > callback to get the details configured at boot to identify and configure > the backing device. This is specifically designed this way to avoid > repeating the mistake of having per-backing-device configuration that is > essentially only actually used by the pstore storage layer. i.e. the very > thing I'm trying to get away from in ramoops, efi-pstore, etc: storage > configuration is tied to the pstore storage layer (i.e. pstore/blk and > pstore/zone), not the specific backing device (i.e. MTD, blk, RAM, NVRAM, > EFI variables, etc). Sharing the config is trivial. But it shared nothing in the actual I/O path, which is entirely different for mtd vs block. And the sad part is that with fs/pstore/zone.c you have added the right abstraction, one that totally makes sense. But only when used by the block and mtd drivers directly. Adding another pointless layer of obsfucation and dead code that doesn't share anything does not help.
[PATCH 5/6] perf inject: Add --buildid-all option
Like perf record, we can even more speedup build-id processing by just
using all DSOs. Then we don't need to look at all the sample events
anymore. The following patch will update perf bench to show the
result of the --buildid-all option too.
Original-patch-by: Stephane Eranian
Acked-by: Jiri Olsa
Acked-by: Ian Rogers
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-inject.txt | 6 +-
tools/perf/builtin-inject.c | 113 ++-
2 files changed, 113 insertions(+), 6 deletions(-)
diff --git a/tools/perf/Documentation/perf-inject.txt
b/tools/perf/Documentation/perf-inject.txt
index 70969ea73e01..a8eccff21281 100644
--- a/tools/perf/Documentation/perf-inject.txt
+++ b/tools/perf/Documentation/perf-inject.txt
@@ -24,8 +24,12 @@ information could make use of this facility.
OPTIONS
---
-b::
---build-ids=::
+--build-ids::
Inject build-ids into the output stream
+
+--buildid-all:
+ Inject build-ids of all DSOs into the output stream
+
-v::
--verbose::
Be more verbose.
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 248cd9f3e5bb..f3f965157d69 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -10,6 +10,7 @@
#include "util/color.h"
#include "util/dso.h"
+#include "util/vdso.h"
#include "util/evlist.h"
#include "util/evsel.h"
#include "util/map.h"
@@ -37,6 +38,7 @@ struct perf_inject {
struct perf_tooltool;
struct perf_session *session;
boolbuild_ids;
+ boolbuild_id_all;
boolsched_stat;
boolhave_auxtrace;
boolstrip;
@@ -56,6 +58,9 @@ struct event_entry {
union perf_event event[];
};
+static int dso__inject_build_id(struct dso *dso, struct perf_tool *tool,
+ struct machine *machine, u8 cpumode, u32 flags);
+
static int output_bytes(struct perf_inject *inject, void *buf, size_t sz)
{
ssize_t size;
@@ -319,6 +324,68 @@ static int perf_event__jit_repipe_mmap(struct perf_tool
*tool,
}
#endif
+static struct dso *findnew_dso(int pid, int tid, const char *filename,
+ struct dso_id *id, struct machine *machine)
+{
+ struct thread *thread;
+ struct nsinfo *nsi = NULL;
+ struct nsinfo *nnsi;
+ struct dso *dso;
+ bool vdso;
+
+ thread = machine__findnew_thread(machine, pid, tid);
+ if (thread == NULL) {
+ pr_err("cannot find or create a task %d/%d.\n", tid, pid);
+ return NULL;
+ }
+
+ vdso = is_vdso_map(filename);
+ nsi = nsinfo__get(thread->nsinfo);
+
+ if (vdso) {
+ /* The vdso maps are always on the host and not the
+* container. Ensure that we don't use setns to look
+* them up.
+*/
+ nnsi = nsinfo__copy(nsi);
+ if (nnsi) {
+ nsinfo__put(nsi);
+ nnsi->need_setns = false;
+ nsi = nnsi;
+ }
+ dso = machine__findnew_vdso(machine, thread);
+ } else {
+ dso = machine__findnew_dso_id(machine, filename, id);
+ }
+
+ if (dso)
+ dso->nsinfo = nsi;
+ else
+ nsinfo__put(nsi);
+
+ thread__put(thread);
+ return dso;
+}
+
+static int perf_event__repipe_buildid_mmap(struct perf_tool *tool,
+ union perf_event *event,
+ struct perf_sample *sample,
+ struct machine *machine)
+{
+ struct dso *dso;
+
+ dso = findnew_dso(event->mmap.pid, event->mmap.tid,
+ event->mmap.filename, NULL, machine);
+
+ if (dso && !dso->hit) {
+ dso->hit = 1;
+ dso__inject_build_id(dso, tool, machine, sample->cpumode, 0);
+ dso__put(dso);
+ }
+
+ return perf_event__repipe(tool, event, sample, machine);
+}
+
static int perf_event__repipe_mmap2(struct perf_tool *tool,
union perf_event *event,
struct perf_sample *sample,
@@ -357,6 +424,34 @@ static int perf_event__jit_repipe_mmap2(struct perf_tool
*tool,
}
#endif
+static int perf_event__repipe_buildid_mmap2(struct perf_tool *tool,
+ union perf_event *event,
+ struct perf_sample *sample,
+ struct machine *machine)
+{
+ struct dso_id dso_id = {
+ .maj = event->mmap2.maj,
+ .min = event->mmap2.min,
+ .ino = event->mmap2.ino,
+ .ino_generation = event->mmap2.ino_generation,
+ };
+ struct dso *dso;
[PATCH 6/6] perf bench: Run inject-build-id with --buildid-all option too
For comparison, it now runs the benchmark twice - one if regular -b
and another for --buildid-all.
$ perf bench internals inject-build-id
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 21.002 msec (+- 0.172 msec)
Average time per event: 2.059 usec (+- 0.017 usec)
Average memory usage: 8169 KB (+- 0 KB)
Average build-id-all injection took: 19.543 msec (+- 0.124 msec)
Average time per event: 1.916 usec (+- 0.012 usec)
Average memory usage: 7348 KB (+- 0 KB)
Acked-by: Jiri Olsa
Acked-by: Ian Rogers
Signed-off-by: Namhyung Kim
---
tools/perf/bench/inject-buildid.c | 54 ---
1 file changed, 35 insertions(+), 19 deletions(-)
diff --git a/tools/perf/bench/inject-buildid.c
b/tools/perf/bench/inject-buildid.c
index 0fccf2a9e95b..e9a11f4a1109 100644
--- a/tools/perf/bench/inject-buildid.c
+++ b/tools/perf/bench/inject-buildid.c
@@ -271,7 +271,7 @@ static void *data_reader(void *arg)
return NULL;
}
-static int setup_injection(struct bench_data *data)
+static int setup_injection(struct bench_data *data, bool build_id_all)
{
int ready_pipe[2];
int dev_null_fd;
@@ -292,6 +292,7 @@ static int setup_injection(struct bench_data *data)
if (data->pid == 0) {
const char **inject_argv;
+ int inject_argc = 2;
close(data->input_pipe[1]);
close(data->output_pipe[0]);
@@ -308,17 +309,22 @@ static int setup_injection(struct bench_data *data)
dup2(dev_null_fd, STDERR_FILENO);
- inject_argv = calloc(3, sizeof(*inject_argv));
+ if (build_id_all)
+ inject_argc++;
+
+ inject_argv = calloc(inject_argc + 1, sizeof(*inject_argv));
if (inject_argv == NULL)
exit(1);
inject_argv[0] = strdup("inject");
inject_argv[1] = strdup("-b");
+ if (build_id_all)
+ inject_argv[2] = strdup("--buildid-all");
/* signal that we're ready to go */
close(ready_pipe[1]);
- cmd_inject(2, inject_argv);
+ cmd_inject(inject_argc, inject_argv);
exit(0);
}
@@ -377,27 +383,17 @@ static int inject_build_id(struct bench_data *data, u64
*max_rss)
return 0;
}
-static int do_inject_loop(struct bench_data *data)
+static void do_inject_loop(struct bench_data *data, bool build_id_all)
{
unsigned int i;
struct stats time_stats, mem_stats;
double time_average, time_stddev;
double mem_average, mem_stddev;
- srand(time(NULL));
init_stats(&time_stats);
init_stats(&mem_stats);
- symbol__init(NULL);
- bench_sample_type = PERF_SAMPLE_IDENTIFIER | PERF_SAMPLE_IP;
- bench_sample_type |= PERF_SAMPLE_TID | PERF_SAMPLE_TIME;
- bench_id_hdr_size = 32;
-
- collect_dso();
- if (nr_dsos == 0) {
- printf(" Cannot collect DSOs for injection\n");
- return -1;
- }
+ pr_debug(" Build-id%s injection benchmark\n", build_id_all ? "-all" :
"");
for (i = 0; i < iterations; i++) {
struct timeval start, end, diff;
@@ -405,7 +401,7 @@ static int do_inject_loop(struct bench_data *data)
pr_debug(" Iteration #%d\n", i+1);
- if (setup_injection(data) < 0) {
+ if (setup_injection(data, build_id_all) < 0) {
printf(" Build-id injection setup failed\n");
break;
}
@@ -427,8 +423,8 @@ static int do_inject_loop(struct bench_data *data)
time_average = avg_stats(&time_stats) / USEC_PER_MSEC;
time_stddev = stddev_stats(&time_stats) / USEC_PER_MSEC;
- printf(" Average build-id injection took: %.3f msec (+- %.3f msec)\n",
- time_average, time_stddev);
+ printf(" Average build-id%s injection took: %.3f msec (+- %.3f
msec)\n",
+ build_id_all ? "-all" : "", time_average, time_stddev);
/* each iteration, it processes MMAP2 + BUILD_ID + nr_samples * SAMPLE
*/
time_average = avg_stats(&time_stats) / (nr_mmaps * (nr_samples + 2));
@@ -440,6 +436,26 @@ static int do_inject_loop(struct bench_data *data)
mem_stddev = stddev_stats(&mem_stats);
printf(" Average memory usage: %.0f KB (+- %.0f KB)\n",
mem_average, mem_stddev);
+}
+
+static int do_inject_loops(struct bench_data *data)
+{
+
+ srand(time(NULL));
+ symbol__init(NULL);
+
+ bench_sample_type = PERF_SAMPLE_IDENTIFIER | PERF_SAMPLE_IP;
+ bench_sample_type |= PERF_SAMPLE_TID | PERF_SAMPLE_TIME;
+ bench_id_hdr_size = 32;
+
+ collect_dso();
+ if (nr_dsos == 0) {
+ printf(" Cannot collect DSOs for injection\n");
+ return -1;
+ }
+
Re: [PATCH 1/5] rxrpc: use semicolons rather than commas to separate statements
On Mon, 12 Oct 2020, David Howells wrote: > Julia Lawall wrote: > > > - call->completion = compl, > > + call->completion = compl; > > Looks good. Do you want me to pick up the patch or send it yourself? Please pick it up. Thanks. julia > > If the latter: > > Acked-by: David Howells > >
Re: [PATCH] mtd: parsers: bcm63xx: Do not make it modular
Hi Guenter,
Guenter Roeck wrote on Sun, 11 Oct 2020 07:14:47
-0700:
> On Tue, Sep 29, 2020 at 10:27:21AM -0700, Florian Fainelli wrote:
> > With commit 91e81150d388 ("mtd: parsers: bcm63xx: simplify CFE
> > detection"), we generate a reference to fw_arg3 which is the fourth
> > firmware/command line argument on MIPS platforms. That symbol is not
> > exported and would cause a linking failure.
> >
> > The parser is typically necessary to boot a BCM63xx-based system anyway
> > so having it be part of the kernel image makes sense, therefore make it
> > 'bool' instead of 'tristate'.
> >
> > Fixes: 91e81150d388 ("mtd: parsers: bcm63xx: simplify CFE detection")
> > Signed-off-by: Florian Fainelli
>
> What happened with this patch ? The build failure is still seen in mainline
> and in next-20201009.
It has been applied on mtd/next:
https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git/log/?h=mtd/next
(I don't remember when though)
Re: [PATCH 3/3] pwm: Add Raspberry Pi Firmware based PWM bus
Hello,
On Fri, Oct 09, 2020 at 05:30:30PM +0200, Nicolas Saenz Julienne wrote:
> Adds support to control the PWM bus available in official Raspberry Pi
> PoE HAT. Only RPi's co-processor has access to it, so commands have to
> be sent through RPi's firmware mailbox interface.
>
> Signed-off-by: Nicolas Saenz Julienne
> ---
> drivers/pwm/Kconfig | 7 ++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-raspberrypi.c | 216 ++
> 3 files changed, 224 insertions(+)
> create mode 100644 drivers/pwm/pwm-raspberrypi.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 63be5362fd3a..a76997ca37d0 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -379,6 +379,13 @@ config PWM_PXA
> To compile this driver as a module, choose M here: the module
> will be called pwm-pxa.
>
> +config PWM_RASPBERRYPI
> + tristate "Raspberry Pi Firwmware PWM support"
s/Firwmware/Firmware/
> + depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST &&
> !RASPBERRYPI_FIRMWARE)
This is more complicated than necessary.
depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
is logically equivalent.
> + help
> + Enable Raspberry Pi firmware controller PWM bus used to control the
> + official RPI PoE hat
> +
> config PWM_RCAR
> tristate "Renesas R-Car PWM support"
> depends on ARCH_RENESAS || COMPILE_TEST
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index cbdcd55d69ee..b557b549d9f3 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -35,6 +35,7 @@ obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
> obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
> obj-$(CONFIG_PWM_PCA9685)+= pwm-pca9685.o
> obj-$(CONFIG_PWM_PXA)+= pwm-pxa.o
> +obj-$(CONFIG_PWM_RASPBERRYPI)+= pwm-raspberrypi.o
> obj-$(CONFIG_PWM_RCAR) += pwm-rcar.o
> obj-$(CONFIG_PWM_RENESAS_TPU)+= pwm-renesas-tpu.o
> obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
> diff --git a/drivers/pwm/pwm-raspberrypi.c b/drivers/pwm/pwm-raspberrypi.c
> new file mode 100644
> index ..1ccff6b1ae34
> --- /dev/null
> +++ b/drivers/pwm/pwm-raspberrypi.c
> @@ -0,0 +1,216 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2020 Nicolas Saenz Julienne
> + */
Please add a paragraph here about the hardware. See pwm-sifive.c for a
template. (Please stick to the format there to simplify grepping.)
The things to point out there are:
- No disable bit, so a disabled PWM is simulated by duty_cycle 0
- Only normal polarity
- Fixed period
Also add a note about if the currently running period is completed when
the hardware is reconfigured.
If possible please also add a link to a product page and/or
documentation.
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define RPI_PWM_MAX_DUTY 255
> +#define RPI_PWM_PERIOD_NS8 /* 12.5KHz */
12.5 kHz
> +#define RPI_PWM_CUR_DUTY_REG 0x0
> +#define RPI_PWM_DEF_DUTY_REG 0x1
> +
> +struct raspberrypi_pwm {
> + struct rpi_firmware *firmware;
> + struct pwm_chip chip;
> + unsigned int duty_cycle;
> +};
> +
> +struct raspberrypi_pwm_prop {
> + __le32 reg;
> + __le32 val;
> + __le32 ret;
> +} __packed;
> +
> +static inline struct raspberrypi_pwm *to_raspberrypi_pwm(struct pwm_chip
> *chip)
> +{
> + return container_of(chip, struct raspberrypi_pwm, chip);
> +}
> +
> +static int raspberrypi_pwm_set_property(struct rpi_firmware *firmware,
> + u32 reg, u32 val)
> +{
> + struct raspberrypi_pwm_prop msg = {
> + .reg = cpu_to_le32(reg),
> + .val = cpu_to_le32(val),
> + };
> + int ret;
> +
> + ret = rpi_firmware_property(firmware, RPI_FIRMWARE_SET_POE_HAT_VAL,
> + &msg, sizeof(msg));
> + if (ret)
> + return ret;
> + else if (msg.ret)
> + return -EIO;
> +
> + return 0;
> +}
> +
> +static int raspberrypi_pwm_get_property(struct rpi_firmware *firmware,
> + u32 reg, u32 *val)
> +{
> + struct raspberrypi_pwm_prop msg = {
> + .reg = reg
> + };
> + int ret;
> +
> + ret = rpi_firmware_property(firmware, RPI_FIRMWARE_GET_POE_HAT_VAL,
> + &msg, sizeof(msg));
> + if (ret)
> + return ret;
> + else if (msg.ret)
> + return -EIO;
> +
> + *val = le32_to_cpu(msg.val);
> +
> + return 0;
> +}
> +
> +static void raspberrypi_pwm_get_state(struct pwm_chip *chip,
> + struct pwm_device *pwm,
> + struct pwm_state *state)
> +{
> + struct raspberrypi_pwm *pc = to_raspberrypi_pwm(chip);
> +
> + state->period = RPI_PWM_PERIOD_NS;
> + state->duty_cycle = pc->duty_cycle * RPI_PWM_PERIOD_N
Re: [PATCH RESEND 1/1] perf build: Allow nested externs to enable BUILD_BUG() usage
On Fri, Oct 9, 2020 at 8:35 PM Vasily Gorbik wrote:
>
> Currently BUILD_BUG() macro is expanded to smth like the following:
Two feedbacks:
#1: Greg KH told me to expand abbreviated words, here "smth = something".
#2: Interesting to see an ASCII-art in the signature is causing such troubles.
- Sedat -
>do {
>extern void __compiletime_assert_0(void)
>__attribute__((error("BUILD_BUG failed")));
>if (!(!(1)))
>__compiletime_assert_0();
>} while (0);
>
> If used in a function body this obviously would produce build errors
> with -Wnested-externs and -Werror.
>
> To enable BUILD_BUG() usage in tools/arch/x86/lib/insn.c which perf
> includes in intel-pt-decoder, build perf without -Wnested-externs.
>
> Reported-by: Stephen Rothwell
> Signed-off-by: Vasily Gorbik
> ---
> Resend with no fancy signatures.
>
> tools/perf/Makefile.config | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> index 854da830b5ca..834061e94e7c 100644
> --- a/tools/perf/Makefile.config
> +++ b/tools/perf/Makefile.config
> @@ -16,7 +16,7 @@ $(shell printf "" > $(OUTPUT).config-detected)
> detected = $(shell echo "$(1)=y" >> $(OUTPUT).config-detected)
> detected_var = $(shell echo "$(1)=$($(1))" >> $(OUTPUT).config-detected)
>
> -CFLAGS := $(EXTRA_CFLAGS) $(EXTRA_WARNINGS)
> +CFLAGS := $(EXTRA_CFLAGS) $(filter-out -Wnested-externs,$(EXTRA_WARNINGS))
>
> include $(srctree)/tools/scripts/Makefile.arch
>
> --
> 2.25.4
Re: [PATCH] arm64: dts: marvell: add DT for ESPRESSObin-Ultra
Hi Vladimir,
a few comments, all by just comparing this device tree to the other
espressobin files.
On 09/10/2020 17:27, Vladimir Vid wrote:
This adds support for ESPRESSObin-Ultra from Globalscale.
Specifications are similar to the base ESPRESSObin board, with main
difference being being WAN port with PoE capability and 2 additional ethernet
ports.
Full specifications:
1x Marvell 64 bit Dual Core ARM A53 Armada 3700 SOC clocked up to 1.2Ghz
1x Topaz 6341 Networking Switch
1GB DDR4
8GB eMMC
1x WAN with 30W POE
4x Gb LAN
1x RTC Clock and battery
1x DC Jack
1x USB 3.0 Type A
1x USB 2.0 Type A
1x SIM NanoSIM card Slot
This one isn't enabled, is it not working?
1x Power Button
4x LED
1x Reset button
1x microUSB for UART
1x M.2 2280 slot for memory
1x 2x2 802.11ac Wi-Fi
1x MiniPCIE slot for Wi-Fi (PCIe interface)
Signed-off-by: Vladimir Vid
---
arch/arm64/boot/dts/marvell/Makefile | 1 +
.../marvell/armada-3720-espressobin-ultra.dts | 242 ++
2 files changed, 243 insertions(+)
create mode 100644
arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts
diff --git a/arch/arm64/boot/dts/marvell/Makefile
b/arch/arm64/boot/dts/marvell/Makefile
index 3e5f2e7a040c..094f451fdd1d 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -3,6 +3,7 @@
dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin-emmc.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin-ultra.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin-v7.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin-v7-emmc.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-turris-mox.dtb
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts
b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts
new file mode 100644
index ..25d10b628e77
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts
@@ -0,0 +1,242 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for ESPRESSObin-Ultra board.
+ * Copyright (C) 2019 Globalscale technologies, Inc.
+ *
+ * Jason Hung
+ */
+
+/dts-v1/;
+
+#include
+#include "armada-372x.dtsi"
+
+/ {
+ model = "Marvell Armada 3720 ESPRESSOBin-Ultra";
the other espressobin boards use "Globalscale Marvell ESPRESSOBin
Board", so maybe "Globalscale Marvell ESPRESSOBin Ultra Board"?
+ compatible = "globalscale,espressobin-ultra", "marvell,armada3720",
+"marvell,armada3710";
+
+ aliases {
+ ethernet0 = ð0;
+ /* for dsa slave device */
+ ethernet1 = &switch0port1;
+ ethernet2 = &switch0port2;
+ ethernet3 = &switch0port3;
+ ethernet4 = &switch0port4;
+ ethernet5 = &switch0port5;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x 0x 0x 0x2000>;
+ };
+
+ reg_usb3_vbus: usb3-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb3-vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ enable-active-high;
+ gpio = <&gpionb 19 GPIO_ACTIVE_HIGH>;
+ };
+
+ usb3_phy: usb3-phy {
+ compatible = "usb-nop-xceiv";
+ vcc-supply = <®_usb3_vbus>;
+ };
+
+ gpio-leds {
+ pinctrl-names = "default";
+ compatible = "gpio-leds";
+ /* No assigned functions to the LEDs by default */
+ led1 {
+ label = "ebin-ultra:blue:led1";
+ gpios = <&gpionb 11 GPIO_ACTIVE_LOW>;
+ };
+ led2 {
+ label = "ebin-ultra:green:led2";
+ gpios = <&gpionb 12 GPIO_ACTIVE_LOW>;
+ };
+ led3 {
+ label = "ebin-ultra:red:led3";
+ gpios = <&gpionb 13 GPIO_ACTIVE_LOW>;
+ };
+ led4 {
+ label = "ebin-ultra:yellow:led4";
+ gpios = <&gpionb 14 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&pcie0 {
+ status = "okay";
armada-3720-espressobin.dtsi additionally has:
pinctrl-names = "default";
pinctrl-0 = <&pcie_reset_pins &pcie_clkreq_pins>;
reset-gpios = <&gpiosb 3 GPIO_ACTIVE_LOW>;
is it missing here?
+};
+
+&sata {
+ status = "okay";
also from armada-3720-espressobin.dtsi, missing?
phys = <&comphy2 0>;
phy-names = "sata-phy";
+};
+
+&sdhci0 {
+ status = "okay";
+ non-removable;
+ bus-width = <8>;
+ mmc-ddr-1_8v;
+ mmc-hs400-1
[PATCH] mtd: hyperbus: Fix build failure when only RPCIF_HYPERBUS is enabled
commit 5de15b610f78 ("mtd: hyperbus: add Renesas RPC-IF driver") leads
to build failure[1] with COMPILE_TEST and RPCIF_HYPERBUS enabled. This
is because driver needs functions RENESAS_RPCIF which is only buildable
for CONFIG_ARCH_RENESAS.
Fix this by dropping COMPILE_TEST from RPCIF_HYPERBUS Kconfig entry.
This ensures driver can be built only when RENESAS_RPCIF is also
selected.
[1]:
rpc-if.c:(.text+0x20): undefined reference to `rpcif_disable_rpm' ld:
drivers/mtd/hyperbus/rpc-if.o: in function `rpcif_hb_prepare_read':
rpc-if.c:(.text+0xd6): undefined reference to `rpcif_prepare' ld:
drivers/mtd/hyperbus/rpc-if.o: in function `rpcif_hb_read16':
[...]
Fixes: 5de15b610f78 ("mtd: hyperbus: add Renesas RPC-IF driver") leads
Reported-by: Richard Weinberger
Signed-off-by: Vignesh Raghavendra
---
Based on mtd/next
Richard,
Could you please pull this into mtd/next?
drivers/mtd/hyperbus/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/hyperbus/Kconfig b/drivers/mtd/hyperbus/Kconfig
index 35b3ab4c8b94..46c7e407e378 100644
--- a/drivers/mtd/hyperbus/Kconfig
+++ b/drivers/mtd/hyperbus/Kconfig
@@ -24,7 +24,7 @@ config HBMC_AM654
config RPCIF_HYPERBUS
tristate "Renesas RPC-IF HyperBus driver"
- depends on RENESAS_RPCIF || COMPILE_TEST
+ depends on RENESAS_RPCIF
depends on MTD_CFI_BE_BYTE_SWAP
help
This option includes Renesas RPC-IF HyperBus support.
--
2.28.0
Re: [PATCH 1/2] net: store KCOV remote handle in sk_buff
On Wed, 2020-10-07 at 10:17 +, Aleksandr Nogikh wrote:
>
> @@ -904,6 +905,10 @@ struct sk_buff {
> __u16 network_header;
> __u16 mac_header;
>
> +#ifdef CONFIG_KCOV
> + u64 kcov_handle;
> +#endif
[...]
> @@ -233,6 +233,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t
> gfp_mask,
> skb->end = skb->tail + size;
> skb->mac_header = (typeof(skb->mac_header))~0U;
> skb->transport_header = (typeof(skb->transport_header))~0U;
> + skb_set_kcov_handle(skb, kcov_common_handle());
Btw, you're only setting this here. It seems to me it would make sense
to copy it when the skb is copied, rather than then having it set to the
kcov handle of the (interrupted) task that was copying the skb?
johannes
Re: [PATCH 6/8] ASoC: samsung: snow: use semicolons rather than commas to separate statements
On Sun, Oct 11, 2020 at 11:19:37AM +0200, Julia Lawall wrote: > Replace commas with semicolons. What is done is essentially described by > the following Coccinelle semantic patch (http://coccinelle.lip6.fr/): > > // > @@ expression e1,e2; @@ > e1 > -, > +; > e2 > ... when any > // > > Signed-off-by: Julia Lawall > > --- > sound/soc/samsung/snow.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v2] drivers:tty:pty: Fix a race causing data loss on close
On 02. 10. 20, 15:03, miny...@acm.org wrote: From: Corey Minyard If you write to a pty master an immediately close the pty master, the receiver might get a chunk of data dropped, but then receive some later data. That's obviously something rather unexpected for a user. It certainly confused my test program. Hmm, that's another instance of bugs which were fixed in the past. Like: commit f8747d4a466ab2cafe56112c51b3379f9fdb7a12 Author: Peter Hurley Date: Fri Sep 27 13:27:05 2013 -0400 tty: Fix pty master read() after slave closes and commit 0f40fbbcc34e093255a2b2d70b6b0fb48c3f39aa Author: Brian Bloniarz Date: Sun Mar 6 13:16:30 2016 -0800 Fix OpenSSH pty regression on close Ccing Peter who is involved in tty buffers a lot and Brian. It turns out that tty_vhangup() gets called from pty_close(), and that causes the data on the slave side to be flushed, but due to races more data can be copied into the slave side's buffer after that. Consider the following sequence: thread1 thread2 thread3 --- --- --- ||-write data into buffer, || n_tty buffer is filled || along with other buffers ||-pty_close() ||--tty_vhangup() This hangup is on slave, not master. This confused me initially. ||---tty_ldisc_hangup() ||n_tty_flush_buffer() ||-reset_buffer_flags() So this flushes the data (as on the toilette; see below) slave already had in its buffer. That's not nice. As I understand it, programs like ssh rely on all the data to be delivered, actually. |-n_tty_read() | |--up_read(&tty->termios_rwsem); ||--down_read(&tty->termios_rwsem) ||--clear n_tty buffer contents ||--up_read(&tty->termios_rwsem) |--tty_buffer_flush_work() | |--schedules work calling| | flush_to_ldisc() | "Flush" doesn't mean "flush" as on the toilette. Here, it's "flush" meaning actually "push" (that confused you given what I read in the note about trying to remove the rwsem lock below). It simply waits for flush_to_ldisc to finish the job. ||-flush_to_ldisc() ||--receive_buf() ||---tty_port_default_receive_buf() ||tty_ldisc_receive_buf() ||-n_tty_receive_buf2() ||--n_tty_receive_buf_common() ||---down_read(&tty->termios_rwsem) ||---__receive_buf() ||---copies data into n_tty buffer ||---up_read(&tty->termios_rwsem) Sure, so we reset the head/tail in reset_buffer_flags (the data you miss) and queued another chunk of data (the data you get). I currently don't see how to fix this properly. Any hint appreciated. |--down_read(&tty->termios_rwsem) |--copy buffer data to user From this sequence, you can see that thread2 writes to the buffer then only clears the part of the buffer in n_tty. The n_tty receive buffer code then copies more data into the n_tty buffer. This change checks to see if the tty is being hung up before copying anything in n_tty_receive_buf_common(). It has to be done after the tty->termios_rwsem semaphore is claimed, for reasons that should be apparent from the sequence above. Signed-off-by: Corey Minyard --- Changes since v1: Added lines to make the sequence diagram clearer. I sent a program to reproduce this, I extended it to prove it wasn't the test program that caused the issue, and I've uploaded it to: http://sourceforge.net/projects/ser2net/files/tmp/testpty.c if you want to run it. It has a lot of comments that explain what is going on. This is not a very satisfying fix, though. It works reliably, but it doesn't seem right to me. My inclination was to remove the up and down semaphore around tty_buffer_flush_work() in n_tty_read(), as it just schedules some work, no need to unlock for that. But that resulted in a deadlock elsewhere, so that up/down on the semaphore is there for another reason. The locking in the tty code is really hard to follow. I believe this is actually a locking problem, but fixing it looks daunting to me. Another way to fix this that occurred just occurred to me would be to clear all the buffers in pty_close(). -corey drivers/tty/n_tty.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c index 1794d84e7bf6..1c33c26dc229 100644 --- a/drivers/tty/n_tty.c +++ b/drivers/tty/n_tty.c @@ -1704,6 +1704,9 @@ n_tty_receive_buf_common(struct tty_struct *tty, const unsigned char *cp, down_read(&tty->termios_rwsem); + if (test_
RE: [PATCH 3/8] ASoC: Intel: bytcr_rt5651: use semicolons rather than commas to separate statements
On 2020-10-11 11:19 AM, Julia Lawall wrote:
> Replace commas with semicolons. What is done is essentially described by
> the following Coccinelle semantic patch (http://coccinelle.lip6.fr/):
>
> //
> @@ expression e1,e2; @@
> e1
> -,
> +;
> e2
> ... when any
> //
>
> Signed-off-by: Julia Lawall
>
Acked-by: Cezary Rojewski
Thanks,
Czarek
> ---
> sound/soc/intel/boards/bytcr_rt5651.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/intel/boards/bytcr_rt5651.c
> b/sound/soc/intel/boards/bytcr_rt5651.c
> index 688b5e0a49e3..64d3fc4a3225 100644
> --- a/sound/soc/intel/boards/bytcr_rt5651.c
> +++ b/sound/soc/intel/boards/bytcr_rt5651.c
> @@ -143,7 +143,7 @@ static int byt_rt5651_prepare_and_enable_pll1(struct
> snd_soc_dai *codec_dai,
>
> /* Configure the PLL before selecting it */
> if (!(byt_rt5651_quirk & BYT_RT5651_MCLK_EN)) {
> - clk_id = RT5651_PLL1_S_BCLK1,
> + clk_id = RT5651_PLL1_S_BCLK1;
> clk_freq = rate * bclk_ratio;
> } else {
> clk_id = RT5651_PLL1_S_MCLK;
>
[PATCH] zram: support a page writeback
There is a demand to writeback specific pages on process to backing store
instead of all idles pages in the system due to storage wear out concern
and launching latency of apps which are most of time idle but critical
for resume latency.
This patch extend writeback knob to support specific page writeback.
Cc: Sergey Senozhatsky
Signed-off-by: Minchan Kim
---
Documentation/admin-guide/blockdev/zram.rst | 5 +
drivers/block/zram/zram_drv.c | 14 ++
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/blockdev/zram.rst
b/Documentation/admin-guide/blockdev/zram.rst
index a6fd1f9b5faf..f9ce26759906 100644
--- a/Documentation/admin-guide/blockdev/zram.rst
+++ b/Documentation/admin-guide/blockdev/zram.rst
@@ -334,6 +334,11 @@ IOW, unless there is access request, those pages are still
idle pages.
With the command, zram writeback idle pages from memory to the storage.
+If admin want to write a specific page in zram device to backing device,
+they could write the page index into the interface.
+
+ echo 1251 > /sys/block/zramX/writeback
+
If there are lots of write IO with flash device, potentially, it has
flash wearout problem so that admin needs to design write limitation
to guarantee storage health for entire product life.
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 9100ac36670a..00c194227d89 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -618,6 +618,7 @@ static int read_from_bdev_async(struct zram *zram, struct
bio_vec *bvec,
return 1;
}
+#define PAGE_WRITEBACK 0
#define HUGE_WRITEBACK 1
#define IDLE_WRITEBACK 2
@@ -626,7 +627,7 @@ static ssize_t writeback_store(struct device *dev,
{
struct zram *zram = dev_to_zram(dev);
unsigned long nr_pages = zram->disksize >> PAGE_SHIFT;
- unsigned long index;
+ unsigned long index = 0;
struct bio bio;
struct bio_vec bio_vec;
struct page *page;
@@ -638,8 +639,13 @@ static ssize_t writeback_store(struct device *dev,
mode = IDLE_WRITEBACK;
else if (sysfs_streq(buf, "huge"))
mode = HUGE_WRITEBACK;
- else
- return -EINVAL;
+ else {
+ ret = kstrtol(buf, 10, &index);
+ if (ret || index >= nr_pages)
+ return -EINVAL;
+ nr_pages = 1;
+ mode = PAGE_WRITEBACK;
+ }
down_read(&zram->init_lock);
if (!init_done(zram)) {
@@ -658,7 +664,7 @@ static ssize_t writeback_store(struct device *dev,
goto release_init_lock;
}
- for (index = 0; index < nr_pages; index++) {
+ while (nr_pages--) {
struct bio_vec bvec;
bvec.bv_page = page;
--
2.28.0.1011.ga647a8990f-goog
Re: [PATCH v3 2/3] media: atmel: introduce microchip csi2dc driver
On 09.10.2020 17:58, Sakari Ailus wrote: > Hi Eugen, > > My apologies for the late reply. > Hi, Thank you for replying, > On Mon, Sep 07, 2020 at 09:16:57AM +, eugen.hris...@microchip.com wrote: >> On 31.08.2020 11:50, Sakari Ailus wrote: >> >>> Hi Eugen, >>> >>> Thanks for the update. >> >> Hi Sakari, >> >> Thanks for reviewing, but, could you please help me understand your >> review below ? >> >>> >>> On Wed, Aug 26, 2020 at 09:51:41AM +0300, Eugen Hristev wrote: Microchip CSI2DC (CSI2 Demultiplexer Controller) is a misc bridge device that converts a byte stream in IDI Synopsys format (coming from a CSI2HOST) to a pixel stream that can be captured by a sensor controller. Signed-off-by: Eugen Hristev --- Changes in v2: - moved driver to platform/atmel - fixed minor things as per Sakari's review - still some things from v2 review are not yet addressed, to be followed up drivers/media/platform/atmel/Kconfig | 13 + drivers/media/platform/atmel/Makefile | 1 + .../media/platform/atmel/microchip-csi2dc.c | 700 ++ 3 files changed, 714 insertions(+) create mode 100644 drivers/media/platform/atmel/microchip-csi2dc.c diff --git a/drivers/media/platform/atmel/Kconfig b/drivers/media/platform/atmel/Kconfig index 1850fe7f9360..80bbddcc2504 100644 --- a/drivers/media/platform/atmel/Kconfig +++ b/drivers/media/platform/atmel/Kconfig @@ -21,3 +21,16 @@ config VIDEO_ATMEL_ISI help This module makes the ATMEL Image Sensor Interface available as a v4l2 device. + +config VIDEO_MICROCHIP_CSI2DC + tristate "Microchip CSI2 Demux Controller" + depends on VIDEO_V4L2 && COMMON_CLK && OF + depends on ARCH_AT91 || COMPILE_TEST + select MEDIA_CONTROLLER + select VIDEO_V4L2_SUBDEV_API + select V4L2_FWNODE + help + CSI2 Demux Controller driver. CSI2DC is a helper chip + that converts IDI interface byte stream to a parallel pixel stream. + It supports various RAW formats as input. + Performs clock domain crossing between hardware blocks. diff --git a/drivers/media/platform/atmel/Makefile b/drivers/media/platform/atmel/Makefile index 2dba38994a70..8af7c5b534c3 100644 --- a/drivers/media/platform/atmel/Makefile +++ b/drivers/media/platform/atmel/Makefile @@ -3,3 +3,4 @@ atmel-isc-objs = atmel-sama5d2-isc.o atmel-isc-base.o obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel-isc.o +obj-$(CONFIG_VIDEO_MICROCHIP_CSI2DC) += microchip-csi2dc.o diff --git a/drivers/media/platform/atmel/microchip-csi2dc.c b/drivers/media/platform/atmel/microchip-csi2dc.c new file mode 100644 index ..97d07a80bbf7 --- /dev/null +++ b/drivers/media/platform/atmel/microchip-csi2dc.c @@ -0,0 +1,700 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Microchip CSI2 Demux Controller (CSI2DC) driver + * + * Copyright (C) 2018-2020 Microchip Technology, Inc. + * + * Author: Eugen Hristev + * + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +/* Global configuration register */ +#define CSI2DC_GCFG 0x0 + +/* MIPI sensor pixel clock is free running */ +#define CSI2DC_GCFG_MIPIFRN BIT(0) +/* Output waveform inter-line minimum delay */ +#define CSI2DC_GCFG_HLC(v) ((v) << 4) +#define CSI2DC_GCFG_HLC_MASK GENMASK(7, 4) + +/* Global control register */ +#define CSI2DC_GCTLR 0x04 +#define CSI2DC_GCTLR_SWRST BIT(0) + +/* Global status register */ +#define CSI2DC_GS0x08 + +/* SSP interrupt status register */ +#define CSI2DC_SSPIS 0x28 +/* Pipe update register */ +#define CSI2DC_PU0xC0 +/* Video pipe attributes update */ +#define CSI2DC_PU_VP BIT(0) + +/* Pipe update status register */ +#define CSI2DC_PUS 0xC4 + +/* Video pipeline enable register */ +#define CSI2DC_VPE 0xF8 +#define CSI2DC_VPE_ENABLEBIT(0) + +/* Video pipeline configuration register */ +#define CSI2DC_VPCFG 0xFC +/* Data type */ +#define CSI2DC_VPCFG_DT(v) ((v) << 0) +#define CSI2DC_VPCFG_DT_MASK GENMASK(5, 0) +/* Virtual channel identifier */ +#define CSI2DC_VPCFG_VC(v) ((v) << 6) +#define CSI2DC_VPCFG_VC_MASK GENMASK(7, 6) +/*
[PATCH v1] ARM: dts: protonic prti6q: fix PHY address
Due to bug in the bootloader, the PHY has floating address and may
randomly change on each PHY reset. To avoid it, the updated bootloader
with the following patch[0] should be used:
| ARM: protonic: disable on-die termination to fix PHY bootstrapping
|
| If on-die termination is enabled, the RXC pin of iMX6 will be pulled
| high. Since we already have an 10K pull-down on board, the RXC level on
| PHY reset will be ~800mV, which is mostly interpreted as 1. On some
| reboots we get 0 instead and kernel can't detect the PHY properly.
|
| Since the default 0x020e07ac value is 0, it is sufficient to remove this
| entry from the affected imxcfg files.
|
| Since we get stable 0 on pin PHYADDR[2], the PHY address is changed from
| 4 to 0.
With latest bootloader update, the PHY address will be fixed to "0".
[0]
https://git.pengutronix.de/cgit/barebox/commit/?id=93f7dcf631edfcda19e7757b28d66017ea274b81
Fixes: 0d446a50559 ("ARM: dts: add Protonic PRTI6Q board")
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6q-prti6q.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-prti6q.dts
b/arch/arm/boot/dts/imx6q-prti6q.dts
index de6cbaab8b49..671bb3a6665d 100644
--- a/arch/arm/boot/dts/imx6q-prti6q.dts
+++ b/arch/arm/boot/dts/imx6q-prti6q.dts
@@ -213,8 +213,8 @@ mdio {
#size-cells = <0>;
/* Microchip KSZ9031RNX PHY */
- rgmii_phy: ethernet-phy@4 {
- reg = <4>;
+ rgmii_phy: ethernet-phy@0 {
+ reg = <0>;
interrupts-extended = <&gpio1 28 IRQ_TYPE_LEVEL_LOW>;
reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
reset-assert-us = <1>;
--
2.28.0
Re: [PATCH v3 1/7] dt-bindings: Add vendor prefix for Netronix, Inc.
On Thu, Sep 24, 2020 at 09:24:49PM +0200, Jonathan Neuschäfer wrote: > Netronix, Inc. (http://www.netronixinc.com/) makes ebook reader board > designs, which are for example used in Kobo and Tolino devices. > > An alternative prefix for Netronix would be "ntx", which is already used > in code released by Netronix. It is shorter, but perhaps less clear. > > Signed-off-by: Jonathan Neuschäfer > Acked-by: Rob Herring minor nitpick: your S-o-b should be last in the tags area. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH v3 1/3] dt-bindings: media: atmel: csi2dc: add bindings for microchip csi2dc
On 11.10.2020 00:17, Laurent Pinchart wrote: > Hi Eugen, > > Thank you for the patch. Hi, Thank you for your review, > > On Wed, Aug 26, 2020 at 09:51:40AM +0300, Eugen Hristev wrote: >> Add bindings documentation for Microchip CSI2 Demultiplexer controller. >> >> CSI2DC is a demultiplexer from Synopsys IDI interface specification to >> parallel interface connection or direct memory access. >> >> Signed-off-by: Eugen Hristev >> --- >> Changes in v3: >> - Removed some text from description, as it was explained in the schema >> - fixed other things as per Rob's review >> - moved some text inside the schema, like the clock description >> >> Changes in v2: >> - fixed warnings reported by dt_binding_check >> >> .../bindings/media/microchip,csi2dc.yaml | 174 ++ >> 1 file changed, 174 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >> >> diff --git a/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >> b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >> new file mode 100644 >> index ..b4c1b8800a3b >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >> @@ -0,0 +1,174 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/media/microchip,csi2dc.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Microchip CSI2 Demux Controller (CSI2DC) >> + >> +maintainers: >> + - Eugen Hristev >> + >> +description: >> + CSI2DC - Camera Serial Interface 2 Demux Controller >> + >> + CSI2DC is a hardware block that receives incoming data from an IDI >> interface >> + and filters packets based on their data type and virtual channel >> identifier, >> + then converts the byte stream into a cross clock domain to a pixel stream >> + to a parallel interface that can be read by a sensor controller. >> + >> + CSI2DC provides two pipes, one video pipe and one data pipe. Video pipe >> + is connected to a sensor controller and the data pipe is accessible >> + as a DMA slave port to a DMA controller. >> + >> + CSI2DC supports a single 'port' node as a source pad with Synopsys 32-bit >> + IDI interface. The connected endpoint must be a IDI interface compatible >> + device (like Synopsys CSI2HOST) , that can provide 32-bit IDI interface >> + connection as sink pad. >> + For media entity and endpoints please refer to the bindings defined in >> + Documentation/devicetree/bindings/media/video-interfaces.txt. >> + For Synopsys IDI interface please refer to >> + Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt >> + >> + CSI2DC supports one 'port' node as sink pad with parallel interface. This >> is >> + called video pipe. >> + This port has an 'endpoint' can then be used as a source pad for another >> + controller (next in pipeline). >> + Please refer to the bindings defined in >> + Documentation/devicetree/bindings/media/video-interfaces.txt. >> + >> + CSI2DC also supports direct access to the data through AHB, via DMA >> channel, >> + called data pipe. >> + Because of this, the sink 'port' child node (second) is not mandatory. >> + If the sink 'port' child node is missing, only data pipe is available. >> + >> +properties: >> + compatible: >> +const: microchip,sama7g5-csi2dc >> + >> + reg: >> +maxItems: 1 >> + >> + clocks: >> +maxItems: 2 >> + >> + clock-names: >> +description: >> + CSI2DC must have two clocks to function correctly. One clock is the >> + peripheral clock for the inside functionality of the hardware block. >> + This is named 'pclk'. The second clock must be the cross domain clock, >> + in which CSI2DC will perform clock crossing. This clock must be fed >> + by the next controller in pipeline, which usually is a sensor >> controller. >> + Normally this clock should be given by this sensor controller who >> + is also a clock source. This clock is named 'scck', sensor controller >> clock. >> +items: >> + - const: pclk >> + - const: scck >> + >> + microchip,clk-gated: >> +type: boolean >> +description: >> + If present, indicates that the clock is gated. >> + Otherwise, the clock is free-running. > > I don't think this belongs to the DT bindings, it should instead be > queried from the source subdev at runtime. If this should be queried, do you know what is the v4l2 mechanism to query such information ? The subdevice is connected through a port interface to this device, so it was natural for me to fully describe the interface in the devicetree port description > >> + >> + microchip,inter-line-delay: >> +allOf: >> +- $ref: /schemas/types.yaml#/definitions/uint32 >> +- minimum: 1 >> +- maximum: 16 >> +default: 16 >> +description: >> + Indicates how many clock cycles should be introduced between each >> line. > > Th
Re: [PATCH v3 02/24] dt-bindings: memory: mediatek: Convert SMI to DT schema
On Sat, Oct 10, 2020 at 02:18:11PM +0800, Yong Wu wrote: > On Tue, 2020-10-06 at 09:15 +0200, Krzysztof Kozlowski wrote: > > On Tue, 6 Oct 2020 at 06:27, Yong Wu wrote: > > > > > > On Fri, 2020-10-02 at 13:08 +0200, Krzysztof Kozlowski wrote: > > > > On Wed, Sep 30, 2020 at 03:06:25PM +0800, Yong Wu wrote: > > > > > Convert MediaTek SMI to DT schema. > > > > > > > > > > Signed-off-by: Yong Wu > > > > > --- > > > > > .../mediatek,smi-common.txt | 49 - > > > > > .../mediatek,smi-common.yaml | 100 > > > > > ++ > > > > > .../memory-controllers/mediatek,smi-larb.txt | 49 - > > > > > .../memory-controllers/mediatek,smi-larb.yaml | 91 > > > > > 4 files changed, 191 insertions(+), 98 deletions(-) > > > > > delete mode 100644 > > > > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt > > > > > create mode 100644 > > > > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml > > > > > delete mode 100644 > > > > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt > > > > > create mode 100644 > > > > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml > > > ... > > > > > +properties: > > > > > + compatible: > > > > > +oneOf: > > > > > + - enum: > > > > > + - mediatek,mt2701-smi-common > > > > > + - mediatek,mt2712-smi-common > > > > > + - mediatek,mt6779-smi-common > > > > > + - mediatek,mt8173-smi-common > > > > > + - mediatek,mt8183-smi-common > > > > > + > > > > > + - description: for mt7623 > > > > > +items: > > > > > + - const: mediatek,mt7623-smi-common > > > > > + - const: mediatek,mt2701-smi-common > > > > > + > > > > > + reg: > > > > > +maxItems: 1 > > > > > + > > > > > + clocks: > > > > > +description: | > > > > > + apb and smi are mandatory. the async is only for generation 1 > > > > > smi HW. > > > > > + gals(global async local sync) also is optional, here is the > > > > > list which > > > > > + require gals: mt6779 and mt8183. > > > > > +minItems: 2 > > > > > +maxItems: 4 > > > > > +items: > > > > > + - description: apb is Advanced Peripheral Bus clock, It's the > > > > > clock for > > > > > + setting the register. > > > > > + - description: smi is the clock for transfer data and command. > > > > > + - description: async is asynchronous clock, it help transform > > > > > the smi clock > > > > > + into the emi clock domain. > > > > > + - description: gals0 is the path0 clock of gals. > > > > > + - description: gals1 is the path1 clock of gals. > > > > > + > > > > > + clock-names: > > > > > +oneOf: > > > > > + - items: > > > > > + - const: apb > > > > > + - const: smi > > > > > + - items: > > > > > + - const: apb > > > > > + - const: smi > > > > > + - const: async > > > > > + - items: > > > > > + - const: apb > > > > > + - const: smi > > > > > + - const: gals0 > > > > > + - const: gals1 > > > > > > > > Similarly to my comment to other properties, this requirement per > > > > compatible should be part of the schema within 'if-then'. > > > > > > I'm not so familiar with this format. Do this has "if-then-'else > > > if'-then-else"? > > > > These are mutually exclusive conditions, so you can skip else: > > - if-then > > - if-then > > - if-then > > It will be more readable then stacking 'if' under 'else' > > Thanks. I will use something like this: > > anyOf: Then it should be oneOf as only one condition can be valid. Best regards, Krzysztof >- if: #gen1 hw > then: >use apb/smi/async clocks > >- if: #gen2 hw that has gals. > then: >use apb/smi/gals0/gals1 clocks > else: # gen2 hw that doesn't have gals. >use apb/smi clocks.
Build regressions/improvements in v5.9
Below is the list of build error/warning regressions/improvements in v5.9[1] compared to v5.8[2]. Summarized: - build errors: +4/-3 - build warnings: +59/-25 JFYI, when comparing v5.9[1] to v5.9-rc8[3], the summaries are: - build errors: +6/-3 - build warnings: +5/-0 Happy fixing! ;-) Thanks to the linux-next team for providing the build service. [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/bbf5c979011a099af5dc76498918ed7df445635b/ (all 192 configs) [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/bcf876870b95592b52519ed4aafcf9d95999bc9c/ (all 192 configs) [3] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/549738f15da0e5a00275977623be199fbbf7df50/ (all 192 configs) *** ERRORS *** 4 error regressions: + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: error: implicit declaration of function 'disable_kernel_vsx' [-Werror=implicit-function-declaration]: => 676:2 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: error: implicit declaration of function 'enable_kernel_vsx' [-Werror=implicit-function-declaration]: => 640:2 + error: modpost: "devm_platform_ioremap_resource_byname" [drivers/net/ethernet/xilinx/ll_temac.ko] undefined!: => N/A + error: modpost: "fw_arg3" [drivers/mtd/parsers/bcm63xxpart.ko] undefined!: => N/A 3 error improvements: - /kisskb/src/arch/powerpc/include/asm/mmu.h: error: unknown type name 'next_tlbcam_idx': 139:22 => - /kisskb/src/arch/sparc/include/asm/trap_block.h: error: 'NR_CPUS' undeclared here (not in a function): 54:39 => - error: modpost: "devm_platform_ioremap_resource" [drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.ko] undefined!: N/A => *** WARNINGS *** 59 warning regressions: + /kisskb/src/arch/arm/crypto/ghash-ce-glue.c: warning: passing argument 4 of 'pmull_ghash_update_p64' from incompatible pointer type: => 67:44 + /kisskb/src/arch/arm/crypto/ghash-ce-glue.c: warning: passing argument 4 of 'pmull_ghash_update_p8' from incompatible pointer type: => 69:43 + /kisskb/src/arch/arm/mach-omap1/board-ams-delta.c: warning: 'ams_delta_camera_power' defined but not used [-Wunused-function]: => 462:12 + /kisskb/src/drivers/crypto/sa2ul.c: warning: (near initialization for 'ad.enc_eng') [-Wmissing-braces]: => 939:9, 1601:9, 1858:9, 1585:9, 1845:9, 957:9, 919:9, 971:9, 1569:9 + /kisskb/src/drivers/crypto/sa2ul.c: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]: => 1486:33 + /kisskb/src/drivers/crypto/sa2ul.c: warning: missing braces around initializer [-Wmissing-braces]: => 971:9, 1569:9, 957:9, 919:9, 1585:9, 1845:9, 1858:9, 1601:9, 939:9 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c: warning: (near initialization for 'hw_locks.bits') [-Wmissing-braces]: => 2342:11, 2527:11 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c: warning: missing braces around initializer [-Wmissing-braces]: => 2342:11, 2527:11 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: warning: (near initialization for 'hw_locks.bits') [-Wmissing-braces]: => 4094:11, 4138:11 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: warning: missing braces around initializer [-Wmissing-braces]: 2714:8, 2712:8 => 2765:8, 2763:8, 4094:11, 4138:11 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_hw_lock_mgr.c: warning: (near initialization for 'cmd.lock_hw') [-Wmissing-braces]: => 36:8 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_hw_lock_mgr.c: warning: missing braces around initializer [-Wmissing-braces]: => 36:8 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: warning: (near initialization for 'hw_locks.bits') [-Wmissing-braces]: => 1795:9 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: warning: missing braces around initializer [-Wmissing-braces]: => 1795:9 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c: warning: (near initialization for 'hw_locks.bits') [-Wmissing-braces]: => 1200:9 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c: warning: missing braces around initializer [-Wmissing-braces]: => 1200:9 + /kisskb/src/drivers/gpu/drm/rockchip/cdn-dp-core.c: warning: 'cdn_dp_resume' defined but not used [-Wunused-function]: => 1124:12 + /kisskb/src/drivers/gpu/drm/xlnx/zynqmp_dp.c: warning: (near initialization for 'opts.mipi_dphy') [-Wmissing-braces]: => 667:9 + /kisskb/src/drivers/gpu/drm/xlnx/zynqmp_dp.c: warning: missing braces around initializer [-Wmissing-braces]: => 667:9 + /kisskb/src/drivers/misc/habanalabs/common/habanalabs_ioctl.c: warning: (near initialization for 'cs_counters.cs_counters') [-Wmissing-braces]: => 282:9 + /kisskb/src/drivers/misc/habanalabs/common/habanalabs_ioctl.c: warning: missing braces around initia
Reconfigure Cisco ASA 5506-X Firewall to Add Support for AnyConnect (MACOS)
Subject: Reconfigure Cisco ASA 5506-X Firewall to Add Support for AnyConnect (MACOS) Author: Mr. Turritopsis Dohrnii Teo En Ming Country: Singapore Date: 12 Oct 2020 Monday Singapore Time Type of Publication: Plain Text Document Version: 20201012.01 Cisco ASA 5506-X Firewall CLI commands: copy ftp://anonymous@/ anyconnect-macos-4.9.02028-webdeploy-k9.pkg show flash config t webvpn no anyconnect image flash:/anyconnect-win-4.9.00086-webdeploy-k9.pkg anyconnect image disk0:/anyconnect-win-4.9.00086-webdeploy-k9.pkg 1 anyconnect image disk0:/anyconnect-macos-4.9.02028-webdeploy-k9.pkg 2 copy run start -- -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Targeted Individual Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE-
Re: Build regressions/improvements in v5.9
On Mon, Oct 12, 2020 at 9:22 AM Geert Uytterhoeven wrote:
> JFYI, when comparing v5.9[1] to v5.9-rc8[3], the summaries are:
> - build errors: +6/-3
> - build warnings: +5/-0
+ error: modpost: "devm_ioremap"
[drivers/net/ethernet/xilinx/ll_temac.ko] undefined!: => N/A
+ error: modpost: "devm_ioremap_resource"
[drivers/net/ethernet/xilinx/xilinx_emac.ko] undefined!: => N/A
+ error: modpost: "devm_of_iomap"
[drivers/net/ethernet/xilinx/ll_temac.ko] undefined!: => N/A
+ error: modpost: "devm_platform_ioremap_resource"
[drivers/iio/adc/adi-axi-adc.ko] undefined!: => N/A
+ error: modpost: "devm_platform_ioremap_resource"
[drivers/ptp/ptp_ines.ko] undefined!: => N/A
+ error: modpost: "devm_platform_ioremap_resource_byname"
[drivers/net/ethernet/xilinx/ll_temac.ko] undefined!: => N/A
um-all{mod,yes}config
> [1]
> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/bbf5c979011a099af5dc76498918ed7df445635b/
> (all 192 configs)
> [3]
> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/549738f15da0e5a00275977623be199fbbf7df50/
> (all 192 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v1 3/3] ARM: dts: add Altesco I6P board
Altesco (Altus-Escon-Company BV) I6P is a part of the diagnostic system
for the vehicle inspection stations.
Co-Developed-by: David Jander
Signed-off-by: David Jander
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-alti6p.dts | 568
2 files changed, 569 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-alti6p.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 43cd1b4be2c7..2289a28c0ff6 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -410,6 +410,7 @@ dtb-$(CONFIG_SOC_IMX53) += \
imx53-usbarmory.dtb \
imx53-voipac-bsb.dtb
dtb-$(CONFIG_SOC_IMX6Q) += \
+ imx6dl-alti6p.dtb \
imx6dl-apf6dev.dtb \
imx6dl-aristainetos_4.dtb \
imx6dl-aristainetos_7.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-alti6p.dts
b/arch/arm/boot/dts/imx6dl-alti6p.dts
new file mode 100644
index ..eab49b74850f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-alti6p.dts
@@ -0,0 +1,568 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2016 Protonic Holland
+ * Copyright (c) 2020 Oleksij Rempel , Pengutronix
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+#include "imx6dl.dtsi"
+
+/ {
+ model = "Altesco I6P Board";
+ compatible = "alt,alti6p", "fsl,imx6dl";
+
+ chosen {
+ stdout-path = &uart4;
+ };
+
+ clock_ksz8081: clock-ksz8081 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5000>;
+ };
+
+ i2c2-mux {
+ compatible = "i2c-mux";
+ i2c-parent = <&i2c2>;
+
+ mux-controls = <&i2c_mux>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ i2c4-mux {
+ compatible = "i2c-mux";
+ i2c-parent = <&i2c4>;
+
+ mux-controls = <&i2c_mux>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-debug0 {
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-debug1 {
+ function = LED_FUNCTION_SD;
+ gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "disk-activity";
+ };
+ };
+
+ i2c_mux: mux-controller {
+ compatible = "gpio-mux";
+ #mux-control-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2cmux>;
+
+ mux-gpios = <&gpio5 10 GPIO_ACTIVE_HIGH>,
+ <&gpio5 11 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_1v8: regulator-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ reg_5v0: regulator-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "5v0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ reg_h1_vbus: regulator-h1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "h1-vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&gpio1 0 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_otg_vbus: regulator-otg-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "otg-vbus";
+ regulator-min-microvolt = <500>;
+ regulato
Re: [PATCH] arm64: KVM: marking pages as XN in Stage-2 does not care about CTR_EL0.DIC
Hi Li,
On 2020-10-12 02:08, l00484210 wrote:
From: MingWang Li
When testing the ARMv8.2-TTS2UXN feature, setting bits of XN is
unavailable.
Because the control bit CTR_EL0.DIC is set by default on system.
But when CTR_EL0.DIC is set, software does not need to flush icache
actively,
instead of clearing XN bits.The patch, the commit id of which
is 6ae4b6e0578886eb36cedbf99f04031d93f9e315, has implemented the
function
of CTR_EL0.DIC.
Signed-off-by: MingWang Li
Signed-off-by: Henglong Fan
---
arch/arm64/include/asm/pgtable-prot.h | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable-prot.h
b/arch/arm64/include/asm/pgtable-prot.h
index 4d867c6446c4..5feb94882bf7 100644
--- a/arch/arm64/include/asm/pgtable-prot.h
+++ b/arch/arm64/include/asm/pgtable-prot.h
@@ -79,17 +79,7 @@ extern bool arm64_use_ng_mappings;
__val; \
})
-#define PAGE_S2_XN \
- ({ \
- u64 __val; \
- if (cpus_have_const_cap(ARM64_HAS_CACHE_DIC)) \
- __val = 0; \
- else\
- __val = PTE_S2_XN; \
- __val; \
- })
-
-#define PAGE_S2__pgprot(_PROT_DEFAULT |
PAGE_S2_MEMATTR(NORMAL) |
PTE_S2_RDONLY | PAGE_S2_XN)
+#define PAGE_S2__pgprot(_PROT_DEFAULT |
PAGE_S2_MEMATTR(NORMAL) |
PTE_S2_RDONLY | PTE_S2_XN)
#define PAGE_S2_DEVICE __pgprot(_PROT_DEFAULT |
PAGE_S2_MEMATTR(DEVICE_nGnRE) | PTE_S2_RDONLY | PTE_S2_XN)
#define PAGE_NONE __pgprot(((_PAGE_DEFAULT) & ~PTE_VALID) |
PTE_PROT_NONE | PTE_RDONLY | PTE_NG | PTE_PXN | PTE_UXN)
I don't understand what you are trying to achieve here.
This whole point of not setting XN in the page tables when DIC is
present
is to avoid a pointless permission fault at run time. At you noticed
above, no icache invalidation is necessary. So why would you ever want
to take a fault on exec the first place?
M.
--
Jazz is not dead. It just smells funny...
[PATCH v1 1/3] dt-bindings: vendor-prefixes: Add an entry for Altus-Escon-Company
Add "alt" entry for Altus-Escon-Company BV: https://www.altus-escon.com/ Signed-off-by: Oleksij Rempel --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 60b59ca04066..801cc267349d 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -65,6 +65,8 @@ patternProperties: description: AlphaScale Integrated Circuits Systems, Inc. "^alps,.*": description: Alps Electric Co., Ltd. + "^alt,.*": +description: Altus-Escon-Company BV "^altr,.*": description: Altera Corp. "^amarula,.*": -- 2.28.0
[PATCH v1 2/3] dt-bindings: arm: fsl: add Altesco I6P board
Add Altus-Escon-Company BV I6P iMX6dl based board Signed-off-by: Oleksij Rempel --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index b615284d1b7c..74aaf68b7d06 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -167,6 +167,7 @@ properties: - description: i.MX6DL based Boards items: - enum: + - alt,alti6p# Altesco I6P Board - armadeus,imx6dl-apf6 # APF6 (Solo) SoM - armadeus,imx6dl-apf6dev # APF6 (Solo) SoM on APF6Dev board - eckelmann,imx6dl-ci4x10 -- 2.28.0
Re: [PATCH v2] media: mtk-vcodec: fix builds when remoteproc is disabled
Em Mon, 12 Oct 2020 13:58:51 +0900 Alexandre Courbot escreveu: > Hi Mauro, > > On Fri, Oct 9, 2020 at 3:34 PM Mauro Carvalho Chehab > wrote: > > > > Em Fri, 9 Oct 2020 13:30:06 +0900 > > Alexandre Courbot escreveu: > > > > > On Fri, Oct 9, 2020 at 1:13 AM Hans Verkuil > > > wrote: > > > > > > >>> If VIDEO_MEDIATEK_VPU=y and MTK_SCP=m, then VIDEO_MEDIATEK_VCODEC > > > > >>> can be configured > > > > >>> to y, and then it won't be able to find the scp_ functions. > > > > >>> > > > > >>> To be honest, I'm not sure how to solve this. > > > > >> > > > > >> Found it. Add this: > > > > >> > > > > >> depends on MTK_SCP || !MTK_SCP > > > > >> depends on VIDEO_MEDIATEK_VPU || !VIDEO_MEDIATEK_VPU > > > > >> > > > > >> Ugly as hell, but it appears to be the correct incantation for this. > > > > >> > > > > While the above does the job, I'm wondering if the better wouldn't > > be to have this spit into 3 config dependencies. E. g. something like: > > > > config VIDEO_MEDIATEK_CODEC > > depends on VIDEO_MEDIATEK_VPU_SCP || VIDEO_MEDIATEK_VPU > > > > config VIDEO_MEDIATEK_VPU > > depends on VIDEO_DEV && VIDEO_V4L2 > > depends on ARCH_MEDIATEK || COMPILE_TEST > > tristate "support for Mediatek Video Processor Unit without SCP" > > help > > ... > > > > config VIDEO_MEDIATEK_VPU_SCP > > depends on VIDEO_DEV && VIDEO_V4L2 > > depends on ARCH_MEDIATEK || COMPILE_TEST > > tristate "support for Mediatek Video Processor Unit with SCP" > > help > > ... > > Doing so would introduce two extra choices to enable the driver, so > I'm a bit concerned this may be a bit confusing? The Kconfig name for "SCP" is already confusing: config MTK_SCP tristate "Mediatek SCP support" Only looking at the helper messages one would understand what SCP actually means ;-) help Say y here to support Mediatek's System Companion Processor (SCP) via the remote processor framework. IMO, the way to make it less confusing would be to change the Kconfig message (probably both here and at remoteproc) to make it easier for people to understand. For example, I would use something similar to this for MTK_SCP prompt: tristate "Use remoteproc with Mediatek companion processor (SCP)" There would be other ways of producing the same result using multiple config entries and just one that would be prompted, but, IMHO, with multiple entries, it t is clearer for the user to understand what what kind of support was selected. This also allows one to look at the produced .config in order to check if SCP was enabled for Mediatek VPU or not. > Also I have experimented with this, and it appears that > VIDEO_MEDIATEK_CODEC won't be automatically enabled if one of the new > options is selected. So this means that after setting e.g. > VIDEO_MEDIATEK_VPU_SCP, one still needs to manually enable > VIDEO_MEDIATEK_CODEC otherwise the driver won't be compiled at all. Actually, the codec config option would need a default line too, e. g. either: config VIDEO_MEDIATEK_CODEC depends on VIDEO_MEDIATEK_VPU_SCP || VIDEO_MEDIATEK_VPU default y or: config VIDEO_MEDIATEK_CODEC depends on VIDEO_MEDIATEK_VPU_SCP || VIDEO_MEDIATEK_VPU default VIDEO_MEDIATEK_VPU_SCP || VIDEO_MEDIATEK_VPU Both should produce exactly the same result. I usually prefer the first, as it is easier to read. > > > > > And split the board-specific data for each variant on separate files, > > doing something like this at the Makefile: > > > > obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-dec.o \ > >mtk-vcodec-enc.o \ > >mtk-vcodec-common.o > > > > ifneq ($(VIDEO_MEDIATEK_VPU_SCP),) > > obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-fw-scp.o > > endif > > > > ifneq ($(VIDEO_MEDIATEK_VPU),) > > obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-fw-vpu.o > > endif > > > > This will avoid the ugly ifdefs in the middle of mtk_vcodec_fw.c, > > and the ugly "depends on FOO || !FOO" usage. > > > > It should also be simpler to add future variants of it in the > > future, if needed. > > Indeed, the split makes sense regardless of the selection mechanism > adopted. I will try to do it in the next revision. Agreed. Thanks, Mauro
Re: [PATCH] arm64/mm: Validate hotplug range before creating linear mapping
On Tue, 6 Oct 2020 at 08:36, Anshuman Khandual
wrote:
>
>
>
> On 09/30/2020 01:32 PM, Anshuman Khandual wrote:
> > But if __is_lm_address() checks against the effective linear range instead
> > i.e [_PAGE_OFFSET(vabits_actual)..(PAGE_END - 1)], it can be used for hot
> > plug physical range check there after. Perhaps something like this, though
> > not tested properly.
> >
> > diff --git a/arch/arm64/include/asm/memory.h
> > b/arch/arm64/include/asm/memory.h
> > index afa722504bfd..6da046b479d4 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -238,7 +238,10 @@ static inline const void *__tag_set(const void *addr,
> > u8 tag)
> > * space. Testing the top bit for the start of the region is a
> > * sufficient check and avoids having to worry about the tag.
> > */
> > -#define __is_lm_address(addr) (!(((u64)addr) & BIT(vabits_actual - 1)))
> > +static inline bool __is_lm_address(unsigned long addr)
> > +{
> > + return ((addr >= _PAGE_OFFSET(vabits_actual)) && (addr <= (PAGE_END
> > - 1)));
> > +}
> >
> > #define __lm_to_phys(addr) (((addr) + physvirt_offset))
> > #define __kimg_to_phys(addr) ((addr) - kimage_voffset)
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index d59ffabb9c84..5750370a7e8c 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -1451,8 +1451,7 @@ static bool inside_linear_region(u64 start, u64 size)
> > * address range mapped by the linear map, the start address should
> > * be calculated using vabits_actual.
> > */
> > - return ((start >= __pa(_PAGE_OFFSET(vabits_actual)))
> > - && ((start + size) <= __pa(PAGE_END - 1)));
> > + return __is_lm_address(__va(start)) && __is_lm_address(__va(start +
> > size));
> > }
> >
> > int arch_add_memory(int nid, u64 start, u64 size,
>
> Will/Ard,
>
> Any thoughts about this ? __is_lm_address() now checks for a range instead
> of a bit. This will be compatible later on, even if linear mapping range
> changes from current lower half scheme.
>
As I'm sure you have noticed, I sent out some patches that get rid of
physvirt_offset, and which simplify __is_lm_address() to only take
compile time constants into account (unless KASAN is enabled). This
means that in the 52-bit VA case, __is_lm_address() does not
distinguish between virtual addresses that can be mapped by the
hardware and ones that cannot.
In the memory hotplug case, we need to decide whether the added memory
will appear in the addressable area, which is a different question. So
it makes sense to duplicate some of the logic that exists in
arm64_memblock_init() (or factor it out) to decide whether this newly
added memory will appear in the addressable window or not.
So I think your original approach makes more sense here, although I
think you want '(start + size - 1) <= __pa(PAGE_END - 1)' in the
comparison above (and please drop the redundant parens)
Re: [PATCH v2 2/2] irqchip/ti-sci-inta: Add support for unmapped event handling
On 2020-10-09 09:58, Peter Ujfalusi wrote: Marc, [...] The design of irqchip/irq-ti-sci-inta.c, soc/ti/ti_sci_inta_msi.c and irqchip/irq-ti-sci-intr.c created to handle the interrupt needs present in K3 devices with NAVSS. DMSS of newer K3 devices extends and simplifies the NAVSS components and a big part of that change was done with the INTA and DMAs. System Firmware also changed to adopt to these changes. As an example, let's assume that we want an interrupt from a ring. The high level of the events in this case are: NAVSS: 1.1 ring generates an internal signal (up or down) 1.2 the ringacc will send a (mapped) Global Event to INTA 1.3 When INTA receives the global event, it will signal it's outgoing VINT to INTR 1.4 INTR will trigger a host interrupt. DMSS 1.1 ring generates an internal signal (up or down) 1.2 the DMA (ring is now part of the DMA) will send an unmapped event to INTA 1.3 When INTA receives the unmapped event, it will send a (mapped) Global Event to itself 1.4 When INTA receives the global event, it will signal it's outgoing VINT to INTR 1.5 INTR will trigger a host interrupt. The API from sysfw is the same to configure the global events and VINT, but we need to use the INTA's tisci device identification number to let sysfw know that the Global event number can be programmed into INTA's unmapped event steering register. The DMA no longer have this register, it sends unmapped event to INTA. The unmapped event number is fixed per sources, they will arrive at the specific unmapped event configuration register of INTA. INTA itself does not know which source are allocated to be used by Linux, the allocation is for the DMA resources and only the DMA driver knows which channels, rings, flows can be used and can ask the INTA MSI domain to create interrupts for those. By handling the ti,unmapped-event-sources the INTA driver can make decision on the correct tisci dev_id to be used for the sysfw API to where the global event must be configured and the client drivers does not need to know how things are working under the hood. There are components in DMSS which use is exactly how they worked within NAVSS, they are not using unmapped events. Ringacc comes to mind first. I can add a comment block to explain the nature of unmapped events and the reason why we need to do what we do. Would this be acceptable? That'd be useful, as long as it is shorter than the above. M. -- Jazz is not dead. It just smells funny...
Re: [PATCH v3 6/8] iommu/arm-smmu: Add impl hook for inherit boot mappings
On Mon 21 Sep 23:08 CEST 2020, Will Deacon wrote:
> On Sat, Sep 12, 2020 at 10:25:59PM -0500, Bjorn Andersson wrote:
> > On Fri 11 Sep 12:13 CDT 2020, Robin Murphy wrote:
> > > On 2020-09-04 16:55, Bjorn Andersson wrote:
> > > > Add a new operation to allow platform implementations to inherit any
> > > > stream mappings from the boot loader.
> > >
> > > Is there a reason we need an explicit step for this? The aim of the
> > > cfg_probe hook is that the SMMU software state should all be set up by
> > > then,
> > > and you can mess about with it however you like before arm_smmu_reset()
> > > actually commits anything to hardware. I would have thought you could
> > > permanently steal a context bank, configure it as your bypass hole, read
> > > out
> > > the previous SME configuration and tweak smmu->smrs and smmu->s2crs
> > > appropriately all together "invisibly" at that point.
> >
> > I did this because as of 6a79a5a3842b ("iommu/arm-smmu: Call
> > configuration impl hook before consuming features") we no longer have
> > setup pgsize_bitmap as we hit cfg_probe, which means that I need to
> > replicate this logic to set up the iommu_domain.
> >
> > If I avoid setting up an iommu_domain for the identity context, as you
> > request in patch 8, this shouldn't be needed anymore.
> >
> > > If that can't work, I'm very curious as to what I've overlooked.
> > >
> >
> > I believe that will work, I will rework the patches and try it out.
>
> Did you get a chance to rework this?
>
Finally got a chance to dig through this properly.
Initial results where positive and with an implementation of cfg_probe
in qcom_smmu_impl I'm able to probe the arm-smmu driver just fine - and
display (e.g. efifb) stays alive.
Unfortunately as the display driver (drivers/gpu/drm/msm) is about to
probe a new iommu domain is created, which due to its match against
qcom_smmu_client_of_match[] becomes of type IOMMU_DOMAIN_IDENTITY.
This results in a S2CR of BYPASS type, which the firmware intercepts and
turns the stream into a type FAULT.
So while the cfg_probe looks very reasonable we're still in need of a
mechanism to use the fake identity context for the iommu domain
associated with the display controller.
The workings of the display driver is that it gets the iommu domain
setup for byass and then after that creates a translation context for
this same stream where it maps the framebuffer.
For testing purposes I made def_domain_type always return 0 in the qcom
impl and the result is that we get a few page faults while probing the
display driver, but these are handled somewhat gracefully and the
initialization did proceed and the system comes up nicely (but in the
case that the display driver would probe defer this leads to an storm of
faults as the screen continues to be refreshed).
TL;DR I think we still need to have a way to get the arm-smmu driver to
allow the qcom implementation to configure identity domains to use
translation - but we can make the setup of the identity context a detail
of the qcom driver.
Regards,
Bjorn
Re: [PATCH 16/18] dt-bindings: usb: meson-g12a-usb: Validate DWC2/DWC3 sub-nodes
On 11/10/2020 00:41, Serge Semin wrote: > Amlogic G12A USB DT sub-nodes are supposed to be compatible with the > generic DWC USB2 and USB3 devices. Since now we've got DT schemas for > both of the later IP cores let's make sure that the Amlogic G12A USB > DT nodes are fully evaluated including the DWC sub-nodes. > > Signed-off-by: Serge Semin > --- > .../bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml | 15 ++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml > b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml > index 88184d7e26cc..3e8ac0ff90de 100644 > --- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml > +++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml > @@ -78,7 +78,20 @@ properties: > > patternProperties: >"^usb@[0-9a-f]+$": > -type: object > +allOf: > + - if: > + properties: > +compatible: > + contains: > +const: snps,dwc2 > +then: > + $ref: dwc2.yaml# > + - if: > + properties: > +compatible: > + const: snps,dwc3 > +then: > + $ref: snps,dwc3.yaml# > > additionalProperties: false > > Reviewed-by: Neil Armstrong
Re: [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()
On 2020/10/12 13:28, Ira Weiny wrote: > On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote: >> On 2020/10/10 03:50, ira.we...@intel.com wrote: >>> From: Ira Weiny >>> >>> These kmap() calls are localized to a single thread. To avoid the over >>> head of global PKRS updates use the new kmap_thread() call. >>> >> >> Hi Ira, >> >> There were a number of options considered. >> >> 1) Attempt to change all the thread local kmap() calls to kmap_atomic() >> 2) Introduce a flags parameter to kmap() to indicate if the mapping >> should be global or not >> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they >> require a global mapping of the pages >> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the >> mapping is to be used within that thread of execution only >> >> >> I copied the above information from patch 00/58 to this message. The >> idea behind kmap_thread() is fine to me, but as you said the new api is >> very easy to be missed in new code (even for me). I would like to be >> supportive to option 2) introduce a flag to kmap(), then we won't forget >> the new thread-localized kmap method, and people won't ask why a >> _thread() function is called but no kthread created. > > Thanks for the feedback. > > I'm going to hold off making any changes until others weigh in. FWIW, I kind > of like option 2 as well. But there is already kmap_atomic() so it seemed > like > kmap_() was more in line with the current API. I understand it now, the idea is fine to me. Acked-by: Coly Li Thanks. Coly Li
Re: [External] Re: [PATCH] mm: proc: add Sock to /proc/meminfo
On Mon, Oct 12, 2020 at 6:22 AM Muchun Song wrote:
>
> On Mon, Oct 12, 2020 at 2:39 AM Cong Wang wrote:
> >
> > On Sat, Oct 10, 2020 at 3:39 AM Muchun Song
> > wrote:
> > >
> > > The amount of memory allocated to sockets buffer can become significant.
> > > However, we do not display the amount of memory consumed by sockets
> > > buffer. In this case, knowing where the memory is consumed by the kernel
> >
> > We do it via `ss -m`. Is it not sufficient? And if not, why not adding it
> > there
> > rather than /proc/meminfo?
>
> If the system has little free memory, we can know where the memory is via
> /proc/meminfo. If a lot of memory is consumed by socket buffer, we cannot
> know it when the Sock is not shown in the /proc/meminfo. If the unaware user
> can't think of the socket buffer, naturally they will not `ss -m`. The
> end result
> is that we still don’t know where the memory is consumed. And we add the
> Sock to the /proc/meminfo just like the memcg does('sock' item in the cgroup
> v2 memory.stat). So I think that adding to /proc/meminfo is sufficient.
>
> >
> > > static inline void __skb_frag_unref(skb_frag_t *frag)
> > > {
> > > - put_page(skb_frag_page(frag));
> > > + struct page *page = skb_frag_page(frag);
> > > +
> > > + if (put_page_testzero(page)) {
> > > + dec_sock_node_page_state(page);
> > > + __put_page(page);
> > > + }
> > > }
> >
> > You mix socket page frag with skb frag at least, not sure this is exactly
> > what you want, because clearly skb page frags are frequently used
> > by network drivers rather than sockets.
> >
> > Also, which one matches this dec_sock_node_page_state()? Clearly
> > not skb_fill_page_desc() or __skb_frag_ref().
>
> Yeah, we call inc_sock_node_page_state() in the skb_page_frag_refill().
> So if someone gets the page returned by skb_page_frag_refill(), it must
> put the page via __skb_frag_unref()/skb_frag_unref(). We use PG_private
> to indicate that we need to dec the node page state when the refcount of
> page reaches zero.
>
Pages can be transferred from pipe to socket, socket to pipe (splice()
and zerocopy friends...)
If you want to track TCP memory allocations, you always can look at
/proc/net/sockstat,
without adding yet another expensive memory accounting.
Re: [PATCH v3 2/2] media: mtk-vcodec: fix build breakage when one of VPU or SCP is enabled
Em Mon, 12 Oct 2020 14:35:57 +0900
Alexandre Courbot escreveu:
> The addition of MT8183 support added a dependency on the SCP remoteproc
> module. However the initial patch used the "select" Kconfig directive,
> which may result in the SCP module to not be compiled if remoteproc was
> disabled. In such a case, mtk-vcodec would try to link against
> non-existent SCP symbols. "select" was clearly misused here as explained
> in kconfig-language.txt.
>
> Replace this by a "depends" directive on at least one of the VPU and
> SCP modules, to allow the driver to be compiled as long as one of these
> is enabled, and adapt the code to support this new scenario.
>
> Also adapt the Kconfig text to explain the extra requirements for MT8173
> and MT8183.
>
> Reported-by: Sakari Ailus
> Signed-off-by: Alexandre Courbot
> Acked-by: Randy Dunlap # build-tested
> Acked-by: Sakari Ailus
> ---
> drivers/media/platform/Kconfig| 22 +++
> drivers/media/platform/mtk-vcodec/Makefile| 10 +++--
> .../platform/mtk-vcodec/mtk_vcodec_fw_priv.h | 18 +++
> 3 files changed, 44 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index a3cb104956d5..457b6c39ddc0 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -253,18 +253,32 @@ config VIDEO_MEDIATEK_VCODEC
> depends on MTK_IOMMU || COMPILE_TEST
> depends on VIDEO_DEV && VIDEO_V4L2
> depends on ARCH_MEDIATEK || COMPILE_TEST
> + depends on VIDEO_MEDIATEK_VPU || MTK_SCP
> + # The two following lines ensure we have the same state ("m" or "y") as
> + # our dependencies, to avoid missing symbols during link.
> + depends on VIDEO_MEDIATEK_VPU || !VIDEO_MEDIATEK_VPU
> + depends on MTK_SCP || !MTK_SCP
> select VIDEOBUF2_DMA_CONTIG
> select V4L2_MEM2MEM_DEV
> - select VIDEO_MEDIATEK_VPU
> - select MTK_SCP
> + select VIDEO_MEDIATEK_VCODEC_VPU if VIDEO_MEDIATEK_VPU
> + select VIDEO_MEDIATEK_VCODEC_SCP if MTK_SCP
> help
> Mediatek video codec driver provides HW capability to
> - encode and decode in a range of video formats
> - This driver rely on VPU driver to communicate with VPU.
> + encode and decode in a range of video formats on MT8173
> + and MT8183.
> +
> + Note that support for MT8173 requires VIDEO_MEDIATEK_VPU to
> + also be selected. Support for MT8183 depends on MTK_SCP.
>
> To compile this driver as modules, choose M here: the
> modules will be called mtk-vcodec-dec and mtk-vcodec-enc.
Just my 2 cents here, and to complement my last e-mail, the helper message
here IMO is a lot more confusing than if you do this, instead:
config VIDEO_MEDIATEK_CODEC
depends on VIDEO_MEDIATEK_VPU_SCP || VIDEO_MEDIATEK_VPU
default y
config VIDEO_MEDIATEK_VPU
depends on VIDEO_DEV && VIDEO_V4L2
depends on ARCH_MEDIATEK || COMPILE_TEST
tristate "Enable Mediatek Video Processor Unit for MT8173"
help
Select this option to enable Mediatek VPU on MT8173.
config VIDEO_MEDIATEK_VPU_SCP
depends on VIDEO_DEV && VIDEO_V4L2
depends on ARCH_MEDIATEK || COMPILE_TEST
tristate "Enable Mediatek Video Processor Unit for MT8183"
help
Select this option to enable Mediatek VPU on MT8183.
To be clear, from my side, I can live with either one of the alternatives,
but, IMHO, the above is a lot clearer for anyone wanting to use
VPU, as, if MTK_SCP is disabled, the MT8183 Kconfig prompt will
disappear.
Thanks,
Mauro
Re: [RFC PATCH 10/24] vdpa: introduce config operations for associating ASID to a virtqueue group
On 2020/10/12 下午2:59, Eli Cohen wrote: On Fri, Oct 09, 2020 at 11:56:45AM +0800, Jason Wang wrote: On 2020/10/1 下午9:29, Eli Cohen wrote: On Thu, Sep 24, 2020 at 11:21:11AM +0800, Jason Wang wrote: This patch introduces a new bus operation to allow the vDPA bus driver to associate an ASID to a virtqueue group. So in case of virtio_net, I would expect that all the data virtqueues will be associated with the same address space identifier. Right. I will add the codes to do this in the next version. It should be more explicit than have this assumption by default. Moreover, this assignment should be provided before the set_map call that provides the iotlb for the address space, correct? I think it's better not have this limitation, note that set_map() now takes a asid argument. So for hardware if the associated as is changed, the driver needs to program the hardware to switch to the new mapping. Does this work for mlx5? So in theory we can have several asid's (for different virtqueues), each one should be followed by a specific set_map call. If this is so, how do I know if I met all the conditions run my driver? Maybe we need another callback to let the driver know it should not expect more set_maps(). This should work similarly as in the past. Two parts of the work is expected to be done by the driver: 1) store the mapping somewhere (e.g hardware) during set_map() 2) associating mapping with a specific virtqueue The only difference is that more than one mapping is used now. For the issue of more set_maps(), driver should be always ready for the new set_maps() call instead of not expecting new set_maps() since guest memory topology could be changed due to several reasons. Qemu or vhost-vDPA will try their best to avoid the frequency of set_maps() for better performance (e.g through batched IOTLB updating). E.g there should be at most one set_map() during one time of guest booting. Thanks
Fair Pay Project now on Bit-Web.EU
For those wanting the email version only: Welcome to Bit-Web, Ywe Cærlyns homepage. I mainly work with OS development and environmentally friendly economically optimal I-T culture. As a conclusion on natural progress and research, we deassociate from regressed deities, where we can rather use a correct variant. So for ease of transition to a solid basis with fair pay principles in La Quran, I work with an operating system, and some related culture. Being on the side of all the politics we wanted in the new millennium. Cider 5 My first amateur project, related to now called 3 D Scene, going back to my teens in Norway. With videogame culture and 4-chan music, which turned cideroriented in a syncretic influenced "christian" culture. I found it no longer suited as a basis for politics or fair pay needed in computing space, and reintegrated myself as muslim. A remix project where I was known for the music Style Blend. And DSP insights, targeting the best of this culture for available source. Bit Trance ! Retro Trance. With a background in I-T, I went on to do techno/E D M music production also, to promote I-T and optimal culture. Such as environment friendlyness, and charitability. And became famous on mp3.com, the worlds first streaming service. And became familiar with Islam, and the arabic concepts Maruf (not Munkar), that is the same as "green" politics. With hopes to the Akira, (afterlife) I pursued this.The genre also gained dubstep breaks from american relatives. I still recommend a bit of 8-bit clap in there, and *nix and tracker, which was like the original. Here as Ihsan VJ. LJX A low latency/jitter I-T centric Supply and Demand Data System. With sorted information, for the derivative works of Adams original infotablet. (The pointer being a sign from The Dispilio Tablet.) With fair pay basis in La Quran. With E-money integration, for a good Tech-Democracy. Emphasizing prominent issues such as Clean Midrange, and Fair Pay. Ultimately aiming for a LCPU (functions library accelerated C-inspired cpu) low-latency system, 48-bit colour graphics, 4K with 8K subpixels. Bit V-log I may vlog here from time to time. Hail La YLAH, Rabb Of The Worlds, La Rahman, La Rahim. (latin capital letter singular form only concept) Serene Greetings, Ywe Cærlyn, Viken County (Norway).
Re: [PATCH] dt-bindings: sound: sun8i-a33-codec: Add Allwinner A64 codec compatible fallback
Hi! On Sun, Oct 11, 2020 at 11:15:42PM +0200, Clément Péron wrote: > make dtbs_check report a warning because the documentation > for the A64 codec compatible is missing. > > The A64 codec compatible is actually a simple fallback to the A33. > > Reflect this in the dt-bindings Documentation. > > Signed-off-by: Clément Péron This patch is already in the ASoC tree and linux-next: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml?id=cef305d4eb0733f25215793ed30b056a7db9bb62 Maxime signature.asc Description: PGP signature
Re: [PATCH] perf vendor events: Fix typos in power8 PMU events
On 10/12/20 10:32 AM, Sandipan Das wrote:
> This replaces the incorrectly spelled word "localtion"
> with "location" in some power8 PMU event descriptions.
Patch looks good to me, Thanks for correcting it.
Reviewed-By: Kajol Jain
Thanks,
Kajol Jain
>
> Fixes: 2a81fa3bb5ed ("perf vendor events: Add power8 PMU events")
> Signed-off-by: Sandipan Das
> ---
> .../pmu-events/arch/powerpc/power8/cache.json| 10 +-
> .../pmu-events/arch/powerpc/power8/frontend.json | 12 ++--
> .../pmu-events/arch/powerpc/power8/marked.json | 10 +-
> .../pmu-events/arch/powerpc/power8/other.json| 16
> .../arch/powerpc/power8/translation.json | 2 +-
> 5 files changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/tools/perf/pmu-events/arch/powerpc/power8/cache.json
> b/tools/perf/pmu-events/arch/powerpc/power8/cache.json
> index 6b792b2c87e2..05a17084d939 100644
> --- a/tools/perf/pmu-events/arch/powerpc/power8/cache.json
> +++ b/tools/perf/pmu-events/arch/powerpc/power8/cache.json
> @@ -32,8 +32,8 @@
>{
> "EventCode": "0x1c04e",
> "EventName": "PM_DATA_FROM_L2MISS_MOD",
> -"BriefDescription": "The processor's data cache was reloaded from a
> localtion other than the local core's L2 due to a demand load",
> -"PublicDescription": "The processor's data cache was reloaded from a
> localtion other than the local core's L2 due to either only demand loads or
> demand loads plus prefetches if MMCR1[16] is 1"
> +"BriefDescription": "The processor's data cache was reloaded from a
> location other than the local core's L2 due to a demand load",
> +"PublicDescription": "The processor's data cache was reloaded from a
> location other than the local core's L2 due to either only demand loads or
> demand loads plus prefetches if MMCR1[16] is 1"
>},
>{
> "EventCode": "0x3c040",
> @@ -74,8 +74,8 @@
>{
> "EventCode": "0x4c04e",
> "EventName": "PM_DATA_FROM_L3MISS_MOD",
> -"BriefDescription": "The processor's data cache was reloaded from a
> localtion other than the local core's L3 due to a demand load",
> -"PublicDescription": "The processor's data cache was reloaded from a
> localtion other than the local core's L3 due to either only demand loads or
> demand loads plus prefetches if MMCR1[16] is 1"
> +"BriefDescription": "The processor's data cache was reloaded from a
> location other than the local core's L3 due to a demand load",
> +"PublicDescription": "The processor's data cache was reloaded from a
> location other than the local core's L3 due to either only demand loads or
> demand loads plus prefetches if MMCR1[16] is 1"
>},
>{
> "EventCode": "0x3c042",
> @@ -134,7 +134,7 @@
>{
> "EventCode": "0x4e04e",
> "EventName": "PM_DPTEG_FROM_L3MISS",
> -"BriefDescription": "A Page Table Entry was loaded into the TLB from a
> localtion other than the local core's L3 due to a data side request",
> +"BriefDescription": "A Page Table Entry was loaded into the TLB from a
> location other than the local core's L3 due to a data side request",
> "PublicDescription": ""
>},
>{
> diff --git a/tools/perf/pmu-events/arch/powerpc/power8/frontend.json
> b/tools/perf/pmu-events/arch/powerpc/power8/frontend.json
> index 1ddc30655d43..1c902a8263b6 100644
> --- a/tools/perf/pmu-events/arch/powerpc/power8/frontend.json
> +++ b/tools/perf/pmu-events/arch/powerpc/power8/frontend.json
> @@ -116,8 +116,8 @@
>{
> "EventCode": "0x1404e",
> "EventName": "PM_INST_FROM_L2MISS",
> -"BriefDescription": "The processor's Instruction cache was reloaded from
> a localtion other than the local core's L2 due to an instruction fetch (not
> prefetch)",
> -"PublicDescription": "The processor's Instruction cache was reloaded
> from a localtion other than the local core's L2 due to either an instruction
> fetch or instruction fetch plus prefetch if MMCR1[17] is 1"
> +"BriefDescription": "The processor's Instruction cache was reloaded from
> a location other than the local core's L2 due to an instruction fetch (not
> prefetch)",
> +"PublicDescription": "The processor's Instruction cache was reloaded
> from a location other than the local core's L2 due to either an instruction
> fetch or instruction fetch plus prefetch if MMCR1[17] is 1"
>},
>{
> "EventCode": "0x34040",
> @@ -158,8 +158,8 @@
>{
> "EventCode": "0x4404e",
> "EventName": "PM_INST_FROM_L3MISS_MOD",
> -"BriefDescription": "The processor's Instruction cache was reloaded from
> a localtion other than the local core's L3 due to a instruction fetch",
> -"PublicDescription": "The processor's Instruction cache was reloaded
> from a localtion other than the local core's L3 due to either an instruction
> fetch or instruction fetch plus prefetch if MMCR1[17] is 1"
> +"BriefDescription": "The processor's Instruction cache was reloaded from
> a locatio
Re: [PATCH 15/18] dt-bindings: usb: meson-g12a-usb: Discard FL-adj property
Hi, On 11/10/2020 00:41, Serge Semin wrote: > An empty snps,quirk-frame-length-adjustment won't cause any change > performed by the driver. Moreover the DT schema validation will fail, > since it expects the property being assigned with some value. So just > discard the property declaration then from the example. > > Signed-off-by: Serge Semin > > --- > > Note the same problem is in the DT source file > arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi . > --- > .../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml | 1 - > 1 file changed, 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml > b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml > index 5b04a7dfa018..88184d7e26cc 100644 > --- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml > +++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml > @@ -209,6 +209,5 @@ examples: >interrupts = <30>; >dr_mode = "host"; >snps,dis_u2_susphy_quirk; > - snps,quirk-frame-length-adjustment; >}; > }; > Thanks for reporting this, actually the fladj must be 0x20 on this hw, but we do set this on the PHY side, so we can let the dwc3 side 0 here. Acked-by: Neil Armstrong Neil
autofs crash with latest linux-next
Hi, on s390 i see the following crash with linux-next: [ 4525.432605] Unable to handle kernel pointer dereference in virtual kernel address space [ 4525.432612] Failing address: TEID: 0483 [ 4525.432613] Fault in home space mode while using kernel ASCE. [ 4525.432616] AS:cf048007 R3:0001fffec007 S:00011800 P:003d [ 4525.432640] Oops: 0004 ilc:3 [#1] SMP [ 4525.432644] Modules linked in: dm_crypt encrypted_keys lcs ctcm fsm nfsv3 nfs_acl nfs lockd grace quota_v2 quota_tree tun overlay ntfs exfat vfat fat sctp vfio_pci irqbypass vfio_virqfd scsi_debug vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb vfio_ap kvm loop nft_counter bridge stp llc dm_service_time nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink sunrpc dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua s390_trng vfio_ccw vfio_mdev mdev vfio_iommu_type1 vfio zcrypt_cex4 eadm_sch sch_fq_codel ip_tables x_tables ghash_s390 prng aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common pkey zcrypt rng_core autofs4 [last unloaded: dummy_del_mod] [ 4525.432691] CPU: 9 PID: 1050921 Comm: find Tainted: G OE 5.9.0-20201011.rc8.git0.d67bc7812221.300.fc32.s390x+next #1 [ 4525.432693] Hardware name: IBM 3906 M04 704 (LPAR) [ 4525.432694] Krnl PSW : 0704d0018000 cde29f70 (__kernel_write+0x1a0/0x2a0) [ 4525.432702]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 [ 4525.432704] Krnl GPRS: 000100067343 0130 0001 [ 4525.432705]0006 5f82be2f 0130 8c6ab568 [ 4525.432728]84441f00 0130 84441f00 [ 4525.432729]81476000 0001 cde29ef4 03e002f5b6f0 [ 4525.432735] Krnl Code: cde29f62: a728lhi %r2,0 cde29f66: a7f4ff9dbrc 15,cde29ea0 #cde29f6a: e310f0f4lg %r1,240(%r15) >cde29f70: e3109024stg %r1,0(%r9) cde29f76: 9104b044tm 68(%r11),4 cde29f7a: a784000fbrc 8,cde29f98 cde29f7e: e3100344lg %r1,832 cde29f84: b904002algr %r2,%r10 [ 4525.432748] Call Trace: [ 4525.432750] [] __kernel_write+0x1a0/0x2a0 [ 4525.432752] ([ ] __kernel_write+0x124/0x2a0) [ 4525.432756] [<03ff80004cfa>] autofs_write+0x5a/0x140 [autofs4] [ 4525.432758] [<03ff80005262>] autofs_notify_daemon.constprop.0+0x10a/0x1c8 [autofs4] [ 4525.432760] [<03ff80005872>] autofs_wait+0x552/0x718 [autofs4] [ 4525.432762] [<03ff800033ca>] autofs_mount_wait+0x5a/0xb0 [autofs4] [ 4525.432764] [<03ff800048b2>] autofs_d_automount+0x102/0x278 [autofs4] [ 4525.432766] [ ] __traverse_mounts+0x9e/0x270 [ 4525.432768] [ ] step_into+0x1de/0x280 [ 4525.432770] [ ] open_last_lookups+0xb8/0x3f8 [ 4525.432772] [ ] path_openat+0x86/0x1d0 [ 4525.432773] [ ] do_filp_open+0x78/0x118 [ 4525.432776] [ ] do_sys_openat2+0xa8/0x168 [ 4525.432778] [ ] __s390x_sys_openat+0x6a/0x98 [ 4525.432781] [ ] system_call+0xdc/0x2a4 [ 4525.432782] Last Breaking-Event-Address: [ 4525.432783] [ ] __kernel_write+0x12c/0x2a0 This seems to be caused by the result of merging 0fb702791bf ("autofs: use __kernel_write() for the autofs pipe writing") and 4d03e3cc5982 ("fs: don't allow kernel reads and writes without iter ops"). __kernel_write() gets now called with a NULL pointer as pos argument, but __kernel_write expects a valid pointer as it fetches/stores the pos value there. Is there a fix pending somewhere? Thanks Sven
Re: [PATCH net] net: 9p: initialize sun_server.sun_path to have addr's value only when addr is valid
Anant Thazhemadam wrote on Mon, Oct 12, 2020: > In p9_fd_create_unix, checking is performed to see if the addr (passed > as an argument) is NULL or not. > However, no check is performed to see if addr is a valid address, i.e., > it doesn't entirely consist of only 0's. > The initialization of sun_server.sun_path to be equal to this faulty > addr value leads to an uninitialized variable, as detected by KMSAN. > Checking for this (faulty addr) and returning a negative error number > appropriately, resolves this issue. I'm not sure I agree a fully zeroed address is faulty but I agree we can probably refuse it given userspace can't pass useful abstract addresses here. Just one nitpick but this is otherwise fine - good catch! > Reported-by: syzbot+75d51fe5bf4ebe988...@syzkaller.appspotmail.com > Tested-by: syzbot+75d51fe5bf4ebe988...@syzkaller.appspotmail.com > Signed-off-by: Anant Thazhemadam > --- > net/9p/trans_fd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c > index c0762a302162..8f528e783a6c 100644 > --- a/net/9p/trans_fd.c > +++ b/net/9p/trans_fd.c > @@ -1023,7 +1023,7 @@ p9_fd_create_unix(struct p9_client *client, const char > *addr, char *args) > > csocket = NULL; > > - if (addr == NULL) > + if (!addr || !strlen(addr)) Since we don't care about the actual length here, how about checking for addr[0] directly? That'll spare a strlen() call in the valid case. Well, I guess it doesn't really matter -- I'll queue this up anyway and update if you resend. Thanks, -- Dominique
[PATCH] powerpc/feature: Fix CPU_FTRS_ALWAYS by removing CPU_FTRS_GENERIC_32
On 8xx, we get the following features:
[0.00] cpu_features = 0x0100
[0.00] possible= 0x0120
[0.00] always = 0x
This is not correct. As CONFIG_PPC_8xx is mutually exclusive with all
other configurations, the three lines should be equal.
The problem is due to CPU_FTRS_GENERIC_32 which is taken when
CONFIG_BOOK3S_32 is NOT selected. This CPU_FTRS_GENERIC_32 is
pointless because there is no generic configuration supporting
all 32 bits but book3s/32.
Remove this pointless generic features definition to unbreak the
calculation of 'possible' features and 'always' features.
Fixes: 76bc080ef5a3 ("[POWERPC] Make default cputable entries reflect selected
CPU family")
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/cputable.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 93bc70d4c9a1..c596bab134e2 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -409,7 +409,6 @@ static inline void cpu_feature_keys_init(void) { }
CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_CELL_TB_BUG | CPU_FTR_SMT)
-#define CPU_FTRS_GENERIC_32(CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN)
/* 64-bit CPUs */
#define CPU_FTRS_PPC970(CPU_FTR_LWSYNC | \
@@ -520,8 +519,6 @@ enum {
CPU_FTRS_7447 | CPU_FTRS_7447A | CPU_FTRS_82XX |
CPU_FTRS_G2_LE | CPU_FTRS_E300 | CPU_FTRS_E300C2 |
CPU_FTRS_CLASSIC32 |
-#else
- CPU_FTRS_GENERIC_32 |
#endif
#ifdef CONFIG_PPC_8xx
CPU_FTRS_8XX |
@@ -596,8 +593,6 @@ enum {
CPU_FTRS_7447 & CPU_FTRS_7447A & CPU_FTRS_82XX &
CPU_FTRS_G2_LE & CPU_FTRS_E300 & CPU_FTRS_E300C2 &
CPU_FTRS_CLASSIC32 &
-#else
- CPU_FTRS_GENERIC_32 &
#endif
#ifdef CONFIG_PPC_8xx
CPU_FTRS_8XX &
--
2.25.0
Re: [PATCH v2 2/3] mm/slub: Fix redzoning for small allocations
On Fri, 9 Oct 2020, Kees Cook wrote: > Store the freelist pointer out of line when object_size is smaller than > sizeof(void *) and redzoning is enabled. > > (Note that no caches with such a size are known to exist in the kernel > currently.) Ummm... The smallest allowable cache size is sizeof(void *) as I recall. mm/slab_common.c::kmem_sanity_check() checks the sizes when caches are created. NAK.
Re: general protection fault in qp_release_pages
On Mon, Oct 12, 2020 at 8:11 AM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:3dd0130f Merge branch 'akpm' (patches from Andrew) > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1219a8e850 > kernel config: https://syzkaller.appspot.com/x/.config?x=c06bcf3cc963d91c > dashboard link: https://syzkaller.appspot.com/bug?extid=f58fe4bb535845237057 > compiler: gcc (GCC) 10.1.0-syz 20200507 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=113937fb90 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1049031b90 > > Bisection is inconclusive: the issue happens on the oldest tested release. > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12d5700790 > final oops: https://syzkaller.appspot.com/x/report.txt?x=11d5700790 > console output: https://syzkaller.appspot.com/x/log.txt?x=16d5700790 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+f58fe4bb535845237...@syzkaller.appspotmail.com > I looked at this for a bit, and I think there is a missing range check for one of the members of 'struct vmci_qp_alloc_info' somewhere in the ioctl path. https://syzkaller.appspot.com/x/repro.c?x=1049031b90 shows what arguments get passed, and while all the members are small, my guess is that something is wrong with the sizes in qp_host_alloc_queue() allocating an array based on produce_size/consume_size, while qp_host_register_user_memory() bases the size on the larger ppn_va/num_ppns. Adding everyone from the git history that did meaningful changes in the past for this driver, as there is no specific maintainer file entry for them to further investigate. Arnd > general protection fault, probably for non-canonical address > 0xdc01: [#1] PREEMPT SMP KASAN > KASAN: null-ptr-deref in range [0x0008-0x000f] > CPU: 1 PID: 6894 Comm: syz-executor291 Not tainted 5.9.0-rc8-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:compound_head include/linux/page-flags.h:182 [inline] > RIP: 0010:put_page include/linux/mm.h:1172 [inline] > RIP: 0010:qp_release_pages+0x5a/0x310 > drivers/misc/vmw_vmci/vmci_queue_pair.c:635 > Code: 5c ad d1 fc 4d 85 f6 c7 44 24 04 00 00 00 00 0f 85 0f 01 00 00 e9 27 02 > 00 00 e8 c1 b0 d1 fc 48 8d 7d 08 48 89 f8 48 c1 e8 03 <42> 80 3c 28 00 0f 85 > 62 02 00 00 48 8b 45 08 31 ff 49 89 c4 48 89 > RSP: 0018:c900014e7948 EFLAGS: 00010202 > RAX: 0001 RBX: 8880a06990d0 RCX: 84a48f81 > RDX: 88808e3ec300 RSI: 84a48e4f RDI: 0008 > RBP: R08: 0001 R09: 8880960634ff > R10: R11: R12: fffd > R13: dc00 R14: fff2 R15: > FS: 01e5e880() GS:8880ae50() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 2040 CR3: a1e74000 CR4: 001506e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > qp_host_get_user_memory+0x249/0x3e0 > drivers/misc/vmw_vmci/vmci_queue_pair.c:660 > qp_host_register_user_memory drivers/misc/vmw_vmci/vmci_queue_pair.c:704 > [inline] > qp_broker_create drivers/misc/vmw_vmci/vmci_queue_pair.c:1383 [inline] > qp_broker_alloc+0x10f9/0x1bf0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1737 > vmci_qp_broker_alloc+0x48/0x60 drivers/misc/vmw_vmci/vmci_queue_pair.c:1930 > vmci_host_do_alloc_queuepair.constprop.0+0x1b4/0x400 > drivers/misc/vmw_vmci/vmci_host.c:488 > vmci_host_unlocked_ioctl+0x13cc/0x1e60 drivers/misc/vmw_vmci/vmci_host.c:927 > vfs_ioctl fs/ioctl.c:48 [inline] > __do_sys_ioctl fs/ioctl.c:753 [inline] > __se_sys_ioctl fs/ioctl.c:739 [inline] > __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x4402f9 > Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 > 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f > 83 7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7ffd6af99eb8 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: 004002c8 RCX: 004402f9 > RDX: 2100 RSI: 07a8 RDI: 0003 > RBP: 006ca018 R08: 004002c8 R09: 004002c8 > R10: 004002c8 R11: 0246 R12: 00401b00 > R13: 00401b90 R14: R15: > Modules linked in: > ---[ end trace 5d73c037702bf45c ]--- > RIP: 0010:compound_head include/linux/page-flags.h:182 [inline] > RIP: 0010:put_page include/linux/mm.h:1172 [inline] > RIP: 0010:qp_release_pages+0x5a/0x310 > dri
[PATCH] powerpc/feature: Add CPU_FTR_NOEXECUTE to G2_LE
G2_LE has a 603 core, add CPU_FTR_NOEXECUTE.
Fixes: 385e89d5b20f ("powerpc/mm: add exec protection on powerpc 603")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/cputable.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index c596bab134e2..9780c55f9811 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -369,7 +369,7 @@ static inline void cpu_feature_keys_init(void) { }
CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_82XX (CPU_FTR_COMMON | CPU_FTR_MAYBE_CAN_DOZE |
CPU_FTR_NOEXECUTE)
#define CPU_FTRS_G2_LE (CPU_FTR_COMMON | CPU_FTR_MAYBE_CAN_DOZE | \
- CPU_FTR_MAYBE_CAN_NAP)
+ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NOEXECUTE)
#define CPU_FTRS_E300 (CPU_FTR_MAYBE_CAN_DOZE | \
CPU_FTR_MAYBE_CAN_NAP | \
CPU_FTR_COMMON | CPU_FTR_NOEXECUTE)
--
2.25.0
[PATCH] powerpc/mm: Remove useless #ifndef CPU_FTR_COHERENT_ICACHE in mem.c
Since commit 10b35d9978ac ("[PATCH] powerpc: merged asm/cputable.h"),
CPU_FTR_COHERENT_ICACHE has always been defined.
Remove the #ifndef CPU_FTR_COHERENT_ICACHE block.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/mem.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index b7586d8c835b..2708d40c38e4 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -53,11 +53,6 @@
#include
-#ifndef CPU_FTR_COHERENT_ICACHE
-#define CPU_FTR_COHERENT_ICACHE0 /* XXX for now */
-#define CPU_FTR_NOEXECUTE 0
-#endif
-
unsigned long long memory_limit;
bool init_mem_is_free;
--
2.25.0
Re: linux-next: manual merge of the arm64 tree with the asm-generic tree
On Mon, Oct 12, 2020 at 12:52 AM Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the arm64 tree got a conflict in:
>
> arch/arm64/include/asm/mmu_context.h
>
> between commit:
>
> f911c2a7c096 ("arm64: use asm-generic/mmu_context.h for no-op
> implementations")
>
> from the asm-generic tree and commit:
>
> 48118151d8cc ("arm64: mm: Pin down ASIDs for sharing mm with devices")
>
> from the arm64 tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
Sorry about that, I had pushed my asm-generic branch to the correct
location on Friday after I noticed it was missing. Removed it again now
until the end up the merge window.
Arnd
[PATCH] powerpc/features: Remove CPU_FTR_NODSISRALIGN
CPU_FTR_NODSISRALIGN has not been used since
commit 31bfdb036f12 ("powerpc: Use instruction emulation
infrastructure to handle alignment faults")
Remove it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/cputable.h | 22 ++
arch/powerpc/kernel/dt_cpu_ftrs.c | 8
arch/powerpc/kernel/prom.c | 2 +-
3 files changed, 11 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 9780c55f9811..accdc1286f37 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -137,7 +137,6 @@ static inline void cpu_feature_keys_init(void) { }
#define CPU_FTR_DBELL ASM_CONST(0x0004)
#define CPU_FTR_CAN_NAPASM_CONST(0x0008)
#define CPU_FTR_DEBUG_LVL_EXC ASM_CONST(0x0010)
-#define CPU_FTR_NODSISRALIGN ASM_CONST(0x0020)
#define CPU_FTR_FPU_UNAVAILABLEASM_CONST(0x0040)
#define CPU_FTR_LWSYNC ASM_CONST(0x0080)
#define CPU_FTR_NOEXECUTE ASM_CONST(0x0100)
@@ -219,7 +218,7 @@ static inline void cpu_feature_keys_init(void) { }
#ifndef __ASSEMBLY__
-#define CPU_FTR_PPCAS_ARCH_V2 (CPU_FTR_NOEXECUTE | CPU_FTR_NODSISRALIGN)
+#define CPU_FTR_PPCAS_ARCH_V2 (CPU_FTR_NOEXECUTE)
#define MMU_FTR_PPCAS_ARCH_V2 (MMU_FTR_TLBIEL | MMU_FTR_16M_PAGE)
@@ -378,33 +377,33 @@ static inline void cpu_feature_keys_init(void) { }
CPU_FTR_COMMON | CPU_FTR_FPU_UNAVAILABLE | CPU_FTR_NOEXECUTE)
#define CPU_FTRS_CLASSIC32 (CPU_FTR_COMMON)
#define CPU_FTRS_8XX (CPU_FTR_NOEXECUTE)
-#define CPU_FTRS_40X (CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE)
-#define CPU_FTRS_44X (CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE)
-#define CPU_FTRS_440x6 (CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE | \
+#define CPU_FTRS_40X (CPU_FTR_NOEXECUTE)
+#define CPU_FTRS_44X (CPU_FTR_NOEXECUTE)
+#define CPU_FTRS_440x6 (CPU_FTR_NOEXECUTE | \
CPU_FTR_INDEXED_DCR)
#define CPU_FTRS_47X (CPU_FTRS_440x6)
#define CPU_FTRS_E200 (CPU_FTR_SPE_COMP | \
- CPU_FTR_NODSISRALIGN | CPU_FTR_COHERENT_ICACHE | \
+ CPU_FTR_COHERENT_ICACHE | \
CPU_FTR_NOEXECUTE | \
CPU_FTR_DEBUG_LVL_EXC)
#define CPU_FTRS_E500 (CPU_FTR_MAYBE_CAN_DOZE | \
- CPU_FTR_SPE_COMP | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
+ CPU_FTR_SPE_COMP | CPU_FTR_MAYBE_CAN_NAP | \
CPU_FTR_NOEXECUTE)
#define CPU_FTRS_E500_2(CPU_FTR_MAYBE_CAN_DOZE | \
CPU_FTR_SPE_COMP | CPU_FTR_MAYBE_CAN_NAP | \
- CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE)
-#define CPU_FTRS_E500MC(CPU_FTR_NODSISRALIGN | \
+ CPU_FTR_NOEXECUTE)
+#define CPU_FTRS_E500MC( \
CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
CPU_FTR_DBELL | CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV)
/*
* e5500/e6500 erratum A-006958 is a timebase bug that can use the
* same workaround as CPU_FTR_CELL_TB_BUG.
*/
-#define CPU_FTRS_E5500 (CPU_FTR_NODSISRALIGN | \
+#define CPU_FTRS_E5500 ( \
CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV | CPU_FTR_CELL_TB_BUG)
-#define CPU_FTRS_E6500 (CPU_FTR_NODSISRALIGN | \
+#define CPU_FTRS_E6500 ( \
CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV | CPU_FTR_ALTIVEC_COMP | \
@@ -554,7 +553,6 @@ enum {
#define CPU_FTRS_DT_CPU_BASE \
(CPU_FTR_LWSYNC | \
CPU_FTR_FPU_UNAVAILABLE | \
-CPU_FTR_NODSISRALIGN | \
CPU_FTR_NOEXECUTE |\
CPU_FTR_COHERENT_ICACHE | \
CPU_FTR_STCX_CHECKS_ADDRESS | \
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c
b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 1098863e17ee..c598961d9f15 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -273,13 +273,6 @@ static int __init feat_enable_idle_nap(struct
dt_cpu_feature *f)
return 1;
}
-static int __init feat_enable_align_dsisr(struct dt_cpu_feature *f)
-{
- cur_cpu_spec->cpu_features &= ~CPU_FTR_NODSISRALIGN;
-
- return 1;
-}
-
static int __init feat_enable_idle_stop(struct dt_cpu_feature *f)
{
u64 lpcr;
@@ -641,7 +634,6 @@ static struct dt_cpu_feature_match __initdata
{"tm-suspend-hypervisor-assist", feat_enable, CPU_FTR_P9_TM_HV_ASSIST},
{"tm-suspend-xer-so-bug", feat_enable, CPU_FTR_P9_TM_XER_SO_BUG},
{"idle-nap", feat_enable_idle_nap, 0},
- {"alignment-interrupt-dsisr", feat_enable_align_dsisr, 0},
{"idle-stop", feat_enable_idle_stop, 0},
{"machine-check-power8", feat_enable_mce_power8, 0},
{
[PATCH] powerpc/mm: Desintegrate MMU_FTR_PPCAS_ARCH_V2
MMU_FTR_PPCAS_ARCH_V2 is defined in cpu_table.h
as MMU_FTR_TLBIEL | MMU_FTR_16M_PAGE.
MMU_FTR_TLBIEL and MMU_FTR_16M_PAGE are defined in mmu.h
MMU_FTR_PPCAS_ARCH_V2 is used only in mmu.h and it is used only once.
Remove MMU_FTR_PPCAS_ARCH_V2 and use
directly MMU_FTR_TLBIEL | MMU_FTR_16M_PAGE
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/cputable.h | 2 --
arch/powerpc/include/asm/mmu.h | 3 +--
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index accdc1286f37..d88bcb79f16d 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -220,8 +220,6 @@ static inline void cpu_feature_keys_init(void) { }
#define CPU_FTR_PPCAS_ARCH_V2 (CPU_FTR_NOEXECUTE)
-#define MMU_FTR_PPCAS_ARCH_V2 (MMU_FTR_TLBIEL | MMU_FTR_16M_PAGE)
-
/* We only set the altivec features if the kernel was compiled with altivec
* support
*/
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 255a1837e9f7..b4367fd0b477 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -126,8 +126,7 @@
#define MMU_FTR_RADIX_KUAP ASM_CONST(0x8000)
/* MMU feature bit sets for various CPUs */
-#define MMU_FTRS_DEFAULT_HPTE_ARCH_V2 \
- MMU_FTR_HPTE_TABLE | MMU_FTR_PPCAS_ARCH_V2
+#define MMU_FTRS_DEFAULT_HPTE_ARCH_V2 (MMU_FTR_HPTE_TABLE | MMU_FTR_TLBIEL |
MMU_FTR_16M_PAGE)
#define MMU_FTRS_POWER MMU_FTRS_DEFAULT_HPTE_ARCH_V2
#define MMU_FTRS_PPC970MMU_FTRS_POWER | MMU_FTR_TLBIE_CROP_VA
#define MMU_FTRS_POWER5MMU_FTRS_POWER | MMU_FTR_LOCKLESS_TLBIE
--
2.25.0
[PATCH] powerpc/mm: MMU_FTR_NEED_DTLB_SW_LRU is only possible with CONFIG_PPC_83xx
Only mpc83xx will set MMU_FTR_NEED_DTLB_SW_LRU and its
definition is enclosed in #ifdef CONFIG_PPC_83xx.
Make MMU_FTR_NEED_DTLB_SW_LRU possible only when
CONFIG_PPC_83xx is set.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/mmu.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index b4367fd0b477..d134f8f8099f 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -172,7 +172,10 @@ enum {
MMU_FTR_TYPE_47x | MMU_FTR_USE_TLBIVAX_BCAST |
MMU_FTR_LOCK_BCAST_INVAL |
#endif
#ifdef CONFIG_PPC_BOOK3S_32
- MMU_FTR_USE_HIGH_BATS | MMU_FTR_NEED_DTLB_SW_LRU |
+ MMU_FTR_USE_HIGH_BATS |
+#endif
+#ifdef CONFIG_PPC_83xx
+ MMU_FTR_NEED_DTLB_SW_LRU |
#endif
#ifdef CONFIG_PPC_BOOK3E_64
MMU_FTR_USE_TLBRSRV | MMU_FTR_USE_PAIRED_MAS |
--
2.25.0
[PATCH] powerpc/mm: Add mask of always present MMU features
On the same principle as commit 773edeadf672 ("powerpc/mm: Add mask
of possible MMU features"), add mask for MMU features that are
always there in order to optimise out dead branches.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/mmu.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index d134f8f8099f..097f23c28c68 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -203,8 +203,30 @@ enum {
0,
};
+enum {
+ MMU_FTRS_ALWAYS =
+#ifdef CONFIG_PPC_8xx
+ MMU_FTR_TYPE_8xx &
+#endif
+#ifdef CONFIG_40x
+ MMU_FTR_TYPE_40x &
+#endif
+#ifdef CONFIG_PPC_47x
+ MMU_FTR_TYPE_47x &
+#elif defined(CONFIG_44x)
+ MMU_FTR_TYPE_44x &
+#endif
+#if defined(CONFIG_E200) || defined(CONFIG_E500)
+ MMU_FTR_TYPE_FSL_E &
+#endif
+ ~0,
+};
+
static inline bool early_mmu_has_feature(unsigned long feature)
{
+ if (MMU_FTRS_ALWAYS & feature)
+ return true;
+
return !!(MMU_FTRS_POSSIBLE & cur_cpu_spec->mmu_features & feature);
}
@@ -233,6 +255,9 @@ static __always_inline bool mmu_has_feature(unsigned long
feature)
}
#endif
+ if (MMU_FTRS_ALWAYS & feature)
+ return true;
+
if (!(MMU_FTRS_POSSIBLE & feature))
return false;
--
2.25.0
[PATCH 1/2] powerpc/44x: Don't support 440 when CONFIG_PPC_47x is set
As stated in platform/44x/Kconfig, CONFIG_PPC_47x is not
compatible with 440 and 460 variants.
This is confirmed in asm/cache.h as L1_CACHE_SHIFT is different
for 47x, meaning a kernel built for 47x will not run correctly
on a 440.
In cputable, opt out all 440 and 460 variants when CONFIG_PPC_47x
is set. Also add a default match dedicated to 470.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/cputable.h | 9 +
arch/powerpc/include/asm/mmu.h | 7 +++
arch/powerpc/kernel/cputable.c | 29 +
3 files changed, 29 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index d88bcb79f16d..4a0ddf66bd4a 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -523,11 +523,10 @@ enum {
#ifdef CONFIG_40x
CPU_FTRS_40X |
#endif
-#ifdef CONFIG_44x
- CPU_FTRS_44X | CPU_FTRS_440x6 |
-#endif
#ifdef CONFIG_PPC_47x
CPU_FTRS_47X | CPU_FTR_476_DD2 |
+#elif defined(CONFIG_44x)
+ CPU_FTRS_44X | CPU_FTRS_440x6 |
#endif
#ifdef CONFIG_E200
CPU_FTRS_E200 |
@@ -596,7 +595,9 @@ enum {
#ifdef CONFIG_40x
CPU_FTRS_40X &
#endif
-#ifdef CONFIG_44x
+#ifdef CONFIG_PPC_47x
+ CPU_FTRS_47X &
+#elif defined(CONFIG_44x)
CPU_FTRS_44X & CPU_FTRS_440x6 &
#endif
#ifdef CONFIG_E200
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 097f23c28c68..49d2c09b7175 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -162,15 +162,14 @@ enum {
#ifdef CONFIG_40x
MMU_FTR_TYPE_40x |
#endif
-#ifdef CONFIG_44x
+#ifdef CONFIG_PPC_47x
+ MMU_FTR_TYPE_47x | MMU_FTR_USE_TLBIVAX_BCAST |
MMU_FTR_LOCK_BCAST_INVAL |
+#elif defined(CONFIG_44x)
MMU_FTR_TYPE_44x |
#endif
#if defined(CONFIG_E200) || defined(CONFIG_E500)
MMU_FTR_TYPE_FSL_E | MMU_FTR_BIG_PHYS | MMU_FTR_USE_TLBILX |
#endif
-#ifdef CONFIG_PPC_47x
- MMU_FTR_TYPE_47x | MMU_FTR_USE_TLBIVAX_BCAST |
MMU_FTR_LOCK_BCAST_INVAL |
-#endif
#ifdef CONFIG_PPC_BOOK3S_32
MMU_FTR_USE_HIGH_BATS |
#endif
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 492c0b36aff6..cf80e6c8ed5e 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1533,6 +1533,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
#endif /* CONFIG_40x */
#ifdef CONFIG_44x
+#ifndef CONFIG_PPC_47x
{
.pvr_mask = 0xffff,
.pvr_value = 0x4850,
@@ -1815,7 +1816,19 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_440A,
.platform = "ppc440",
},
-#ifdef CONFIG_PPC_47x
+ { /* default match */
+ .pvr_mask = 0x,
+ .pvr_value = 0x,
+ .cpu_name = "(generic 44x PPC)",
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE,
+ .mmu_features = MMU_FTR_TYPE_44x,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .machine_check = machine_check_4xx,
+ .platform = "ppc440",
+ }
+#else /* CONFIG_PPC_47x */
{ /* 476 DD2 core */
.pvr_mask = 0x,
.pvr_value = 0x11a52080,
@@ -1872,19 +1885,19 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_47x,
.platform = "ppc470",
},
-#endif /* CONFIG_PPC_47x */
{ /* default match */
.pvr_mask = 0x,
.pvr_value = 0x,
- .cpu_name = "(generic 44x PPC)",
- .cpu_features = CPU_FTRS_44X,
+ .cpu_name = "(generic 47x PPC)",
+ .cpu_features = CPU_FTRS_47X,
.cpu_user_features = COMMON_USER_BOOKE,
- .mmu_features = MMU_FTR_TYPE_44x,
+ .mmu_features = MMU_FTR_TYPE_47x,
.icache_bsize = 32,
- .dcache_bsize = 32,
- .machine_check = machine_check_4xx,
- .platform = "ppc440",
+ .dcache_bsize = 128,
+ .machine_check = machine_check_47x,
+ .platform = "ppc470",
}
+#endif /* CONFIG_PPC_47x */
#endif /* CONFIG_44x */
#ifdef CONFIG_E200
{ /* e200z5 */
--
2.25.0
[PATCH 2/2] powerpc/44x: Don't support 47x code and non 47x code at the same time
440/460 variants and 470 variants are not compatible, no need to make code supporting both and using MMU features. Just use CONFIG_PPC_47x to decide what to build. Signed-off-by: Christophe Leroy --- arch/powerpc/kernel/entry_32.S | 11 +++ arch/powerpc/mm/nohash/tlb_low.S | 29 +++-- 2 files changed, 10 insertions(+), 30 deletions(-) diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index 8cdc8bcde703..a7727006d6f5 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -439,15 +439,13 @@ syscall_exit_cont: andis. r10,r0,DBCR0_IDM@h bnel- load_dbcr0 #endif -#ifdef CONFIG_44x -BEGIN_MMU_FTR_SECTION +#ifdef CONFIG_PPC_47x lis r4,icache_44x_need_flush@ha lwz r5,icache_44x_need_flush@l(r4) cmplwi cr0,r5,0 bne-2f 1: -END_MMU_FTR_SECTION_IFCLR(MMU_FTR_TYPE_47x) -#endif /* CONFIG_44x */ +#endif /* CONFIG_PPC_47x */ BEGIN_FTR_SECTION lwarx r7,0,r1 END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX) @@ -948,10 +946,7 @@ restore_kuap: /* interrupts are hard-disabled at this point */ restore: -#ifdef CONFIG_44x -BEGIN_MMU_FTR_SECTION - b 1f -END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x) +#if defined(CONFIG_44x) && !defined(CONFIG_PPC_47x) lis r4,icache_44x_need_flush@ha lwz r5,icache_44x_need_flush@l(r4) cmplwi cr0,r5,0 diff --git a/arch/powerpc/mm/nohash/tlb_low.S b/arch/powerpc/mm/nohash/tlb_low.S index eaeee402f96e..68797e072f55 100644 --- a/arch/powerpc/mm/nohash/tlb_low.S +++ b/arch/powerpc/mm/nohash/tlb_low.S @@ -92,36 +92,25 @@ _GLOBAL(__tlbil_va) tlbsx. r6,0,r3 bne 10f sync -BEGIN_MMU_FTR_SECTION - b 2f -END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x) +#ifndef CONFIG_PPC_47x /* On 440 There are only 64 TLB entries, so r3 < 64, which means bit * 22, is clear. Since 22 is the V bit in the TLB_PAGEID, loading this * value will invalidate the TLB entry. */ tlbwe r6,r6,PPC44x_TLB_PAGEID - isync -10:wrtee r10 - blr -2: -#ifdef CONFIG_PPC_47x +#else orisr7,r6,0x8000/* specify way explicitly */ clrrwi r4,r3,12/* get an EPN for the hashing with V = 0 */ ori r4,r4,PPC47x_TLBE_SIZE tlbwe r4,r7,0 /* write it */ +#endif /* !CONFIG_PPC_47x */ isync - wrtee r10 +10:wrtee r10 blr -#else /* CONFIG_PPC_47x */ -1: trap - EMIT_BUG_ENTRY 1b,__FILE__,__LINE__,0; -#endif /* !CONFIG_PPC_47x */ _GLOBAL(_tlbil_all) _GLOBAL(_tlbil_pid) -BEGIN_MMU_FTR_SECTION - b 2f -END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x) +#ifndef CONFIG_PPC_47x li r3,0 sync @@ -136,8 +125,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x) isync blr -2: -#ifdef CONFIG_PPC_47x +#else /* 476 variant. There's not simple way to do this, hopefully we'll * try to limit the amount of such full invalidates */ @@ -179,11 +167,8 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x) b 1b /* Then loop */ 1: isync /* Sync shadows */ wrtee r11 -#else /* CONFIG_PPC_47x */ -1: trap - EMIT_BUG_ENTRY 1b,__FILE__,__LINE__,0; -#endif /* !CONFIG_PPC_47x */ blr +#endif /* !CONFIG_PPC_47x */ #ifdef CONFIG_PPC_47x -- 2.25.0
Re: [PATCH] rcutorture/nolibc: Fix a typo in header file
Hello Samuel, On Sun, Oct 11, 2020 at 02:22:31PM -0400, Samuel Hernandez wrote: > Signed-off-by: Samuel Hernandez > --- > This fixes a supposed typo. Before this, the AT_FDCWD macro would be defined > regardless of whether or not it's been defined before. Good catch! Please note that the commit message must be placed *before* the "---" and before the signed-off-by. No need to resend, I'll adjust it on my end. Thank you, Willy
Re: [PATCH 1/3] soc: qcom: geni: More properly switch to DMA mode
On 10/9/2020 4:22 AM, Douglas Anderson wrote:
On geni-i2c transfers using DMA, it was seen that if you program the
command (I2C_READ) before calling geni_se_rx_dma_prep() that it could
cause interrupts to fire. If we get unlucky, these interrupts can
just keep firing (and not be handled) blocking further progress and
hanging the system.
In commit 02b9aec59243 ("i2c: i2c-qcom-geni: Fix DMA transfer race")
we avoided that by making sure we didn't program the command until
after geni_se_rx_dma_prep() was called. While that avoided the
problems, it also turns out to be invalid. At least in the TX case we
started seeing sporadic corrupted transfers. This is easily seen by
adding an msleep() between the DMA prep and the writing of the
command, which makes the problem worse. That means we need to revert
that commit and find another way to fix the bogus IRQs.
Specifically, after reverting commit 02b9aec59243 ("i2c:
i2c-qcom-geni: Fix DMA transfer race"), I put some traces in. I found
that the when the interrupts were firing like crazy:
- "m_stat" had bits for M_RX_IRQ_EN, M_RX_FIFO_WATERMARK_EN set.
- "dma" was set.
Further debugging showed that I could make the problem happen more
reliably by adding an "msleep(1)" any time after geni_se_setup_m_cmd()
ran up until geni_se_rx_dma_prep() programmed the length.
A rather simple fix is to change geni_se_select_dma_mode() so it's a
true inverse of geni_se_select_fifo_mode() and disables all the FIFO
related interrupts. Now the problematic interrupts can't fire and we
can program things in the correct order without worrying.
As part of this, let's also change the writel_relaxed() in the prepare
function to a writel() so that our DMA is guaranteed to be prepared
now that we can't rely on geni_se_setup_m_cmd()'s writel().
NOTE: the only current user of GENI_SE_DMA in mainline is i2c.
Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C
controller")
Fixes: 02b9aec59243 ("i2c: i2c-qcom-geni: Fix DMA transfer race")
Signed-off-by: Douglas Anderson
Reviewed-by: Akash Asthana
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na
Linux Foundation Collaborative Project
Re: [PATCH 2/6] mm: introduce vma_set_file function v3
Am 09.10.20 um 17:14 schrieb Jason Gunthorpe:
On Fri, Oct 09, 2020 at 05:03:38PM +0200, Christian König wrote:
+/*
+ * Change backing file, only valid to use during initial VMA setup.
+ */
+void vma_set_file(struct vm_area_struct *vma, struct file *file)
+{
+ if (file)
+ get_file(file);
+
+ swap(vma->vm_file, file);
+
+ if (file)
+ fput(file);
+}
fput crashes when file is NULL so the error handling after
unmap_and_free_vma: can't handle this case, similarly vm_file can't be
NULL either.
So just simply:
swap(vma->vm_file, file);
get_file(vma->vm_file);
fput(file);
Will do?
I was considering this as well, yes.
Just let it crash if any of them are wrongly NULL.
Mhm, changing from anonymous to file backed or reverse is probably not
such a good idea.
So yes catching those problems early is probably the best approach we
could do.
Going to do this in v4 if nobody objects.
Regards,
Christian.
Jason
Re: [PATCH 1/6] mm: mmap: fix fput in error path
Am 10.10.20 um 00:25 schrieb Jason Gunthorpe: On Fri, Oct 09, 2020 at 03:04:20PM -0700, Andrew Morton wrote: On Fri, 9 Oct 2020 17:03:37 +0200 "Christian König" wrote: Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args..." adds a workaround for a bug in mmap_region. As the comment states ->mmap() callback can change vma->vm_file and so we might call fput() on the wrong file. Revert the workaround and proper fix this in mmap_region. Doesn't this patch series address the same thing as https://lkml.kernel.org/r/20200916090733.31427-1-linmia...@huawei.com? Same basic issue, looks like both of these patches should be combined to plug it fully. Yes, agree completely. It's a different error path, but we need to fix both occasions. Christian. Jason
Re: [PATCH 2/3] Revert "i2c: i2c-qcom-geni: Fix DMA transfer race"
On 10/9/2020 4:22 AM, Douglas Anderson wrote:
This reverts commit 02b9aec59243c6240fc42884acc958602146ddf6.
As talked about in the patch ("soc: qcom: geni: More properly switch
to DMA mode"), swapping the order of geni_se_setup_m_cmd() and
geni_se_xx_dma_prep() can sometimes cause corrupted transfers. Thus
we traded one problem for another. Now that we've debugged the
problem further and fixed the geni helper functions to more disable
FIFO interrupts when we move to DMA mode we can revert it and end up
with (hopefully) zero problems!
To be explicit, the patch ("soc: qcom: geni: More properly switch
to DMA mode") is a prerequisite for this one.
Fixes: 02b9aec59243 ("i2c: i2c-qcom-geni: Fix DMA transfer race")
Signed-off-by: Douglas Anderson
Reviewed-by: Akash Asthana
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na
Linux Foundation Collaborative Project
linux-next: manual merge of the counters tree with the ipmi tree
Hi all,
Today's linux-next merge of the counters tree got a conflict in:
drivers/char/ipmi/ipmi_msghandler.c
between commit:
f8910ffa81b0 ("ipmi:msghandler: retry to get device id on an error")
from the ipmi tree and commit:
dc87264ac991 ("drivers/char/ipmi: convert stats to use counter_atomic32")
from the counters tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/char/ipmi/ipmi_msghandler.c
index 8774a3b8ff95,36c0b1be22fb..
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@@ -34,7 -34,7 +34,8 @@@
#include
#include
#include
+#include
+ #include
#define IPMI_DRIVER_VERSION "39.2"
pgpHg8LPmVR8v.pgp
Description: OpenPGP digital signature
Re: general protection fault in qp_release_pages
On Mon, Oct 12, 2020 at 10:01 AM Arnd Bergmann wrote: > > On Mon, Oct 12, 2020 at 8:11 AM syzbot > wrote: > > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:3dd0130f Merge branch 'akpm' (patches from Andrew) > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=1219a8e850 > > kernel config: https://syzkaller.appspot.com/x/.config?x=c06bcf3cc963d91c > > dashboard link: https://syzkaller.appspot.com/bug?extid=f58fe4bb535845237057 > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=113937fb90 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1049031b90 > > > > Bisection is inconclusive: the issue happens on the oldest tested release. > > > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12d5700790 > > final oops: https://syzkaller.appspot.com/x/report.txt?x=11d5700790 > > console output: https://syzkaller.appspot.com/x/log.txt?x=16d5700790 > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+f58fe4bb535845237...@syzkaller.appspotmail.com > > > > I looked at this for a bit, and I think there is a missing range check > for one of the > members of 'struct vmci_qp_alloc_info' somewhere in the ioctl path. > > https://syzkaller.appspot.com/x/repro.c?x=1049031b90 shows what > arguments get passed, and while all the members are small, my guess is > that something is wrong with the sizes in qp_host_alloc_queue() allocating > an array based on produce_size/consume_size, while > qp_host_register_user_memory() bases the size on the larger > ppn_va/num_ppns. > > Adding everyone from the git history that did meaningful changes in the past > for this driver, as there is no specific maintainer file entry for > them to further > investigate. Hi Arnd, There is already a recorded fix for this on the dashboard: https://syzkaller.appspot.com/bug?extid=f58fe4bb535845237057 VMCI: check return value of get_user_pages_fast() for errors > > general protection fault, probably for non-canonical address > > 0xdc01: [#1] PREEMPT SMP KASAN > > KASAN: null-ptr-deref in range [0x0008-0x000f] > > CPU: 1 PID: 6894 Comm: syz-executor291 Not tainted 5.9.0-rc8-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > RIP: 0010:compound_head include/linux/page-flags.h:182 [inline] > > RIP: 0010:put_page include/linux/mm.h:1172 [inline] > > RIP: 0010:qp_release_pages+0x5a/0x310 > > drivers/misc/vmw_vmci/vmci_queue_pair.c:635 > > Code: 5c ad d1 fc 4d 85 f6 c7 44 24 04 00 00 00 00 0f 85 0f 01 00 00 e9 27 > > 02 00 00 e8 c1 b0 d1 fc 48 8d 7d 08 48 89 f8 48 c1 e8 03 <42> 80 3c 28 00 > > 0f 85 62 02 00 00 48 8b 45 08 31 ff 49 89 c4 48 89 > > RSP: 0018:c900014e7948 EFLAGS: 00010202 > > RAX: 0001 RBX: 8880a06990d0 RCX: 84a48f81 > > RDX: 88808e3ec300 RSI: 84a48e4f RDI: 0008 > > RBP: R08: 0001 R09: 8880960634ff > > R10: R11: R12: fffd > > R13: dc00 R14: fff2 R15: > > FS: 01e5e880() GS:8880ae50() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 2040 CR3: a1e74000 CR4: 001506e0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7: 0400 > > Call Trace: > > qp_host_get_user_memory+0x249/0x3e0 > > drivers/misc/vmw_vmci/vmci_queue_pair.c:660 > > qp_host_register_user_memory drivers/misc/vmw_vmci/vmci_queue_pair.c:704 > > [inline] > > qp_broker_create drivers/misc/vmw_vmci/vmci_queue_pair.c:1383 [inline] > > qp_broker_alloc+0x10f9/0x1bf0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1737 > > vmci_qp_broker_alloc+0x48/0x60 drivers/misc/vmw_vmci/vmci_queue_pair.c:1930 > > vmci_host_do_alloc_queuepair.constprop.0+0x1b4/0x400 > > drivers/misc/vmw_vmci/vmci_host.c:488 > > vmci_host_unlocked_ioctl+0x13cc/0x1e60 > > drivers/misc/vmw_vmci/vmci_host.c:927 > > vfs_ioctl fs/ioctl.c:48 [inline] > > __do_sys_ioctl fs/ioctl.c:753 [inline] > > __se_sys_ioctl fs/ioctl.c:739 [inline] > > __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739 > > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > RIP: 0033:0x4402f9 > > Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 > > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > > ff 0f 83 7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00 > > RSP: 002b:7ffd6af99eb8 EFLAGS: 0246 ORIG_RAX: 0010 > > RAX: ffda RBX: 004002c8 RCX: 004402f9 > > RDX: 2100 RSI: 07a8 RDI: 0003 > > RBP: 000
Re: [PATCH 5.9 RT] net: openvswitch: Fix using smp_processor_id() in preemptible code
On 9 Oct 2020, at 17:41, Sebastian Andrzej Siewior wrote:
On 2020-10-09 14:47:59 [+0200], Juri Lelli wrote:
This happens because openvswitch/flow_table::flow_lookup() accesses
per-cpu data while being preemptible (and migratable).
Fix it by adding get/put_cpu_light(), so that, even if preempted, the
task executing this code is not migrated (operation is also guarded
by
ovs_mutex mutex).
This warning is not limited to PREEMPT_RT it also present upstream
since
commit
eac87c413bf97 ("net: openvswitch: reorder masks array based on
usage")
You should be able to reproduce it there, too.
The path ovs_flow_tbl_lookup() -> flow_lookup() is guarded by
ovs_lock()
I can't say that this true for
ovs_vport_receive() -> ovs_dp_process_packet() ->
ovs_flow_tbl_lookup_stats() -> flow_lookup()
(means I don't know but it looks like coming from NAPI).
Which means u64_stats_update_begin() could have two writers. This must
not happen.
There are two reader which do u64_stats_fetch_begin_irq(). Disabling
interrupts makes no sense since they perform cross-CPU access.
-> You need to ensure that there is only one writer at a time.
If mask_array gains a spinlock_t for writer protection then you can
acquire the lock prio grabbing ->masks_usage_cntr. But as of now there
is one `ma->syncp'.
I’m not too familiar with the RT kernel, but in the none RT kernel,
this function is called in run to completion parts only, hence does not
need a lock. Actually, this was designed in such a way that it does not
need a lock at all.
So maybe this needs a get_cpu() instead of the light variant in the RT
case?
//Eelco
Re: [PATCH v2] usb: cdns3: Rids of duplicate error message
Hi Pawel,
On 12/10/2020 09:42, Pawel Laszczak wrote:
On failure, the platform_get_irq_byname prints an error message
so, patch removes error message related to this function from
core.c file.
A change was suggested during reviewing CDNSP driver by Chunfeng Yun.
Signed-off-by: Pawel Laszczak
---
Changelog:
v2
- simplified code as sugested by Roger Quadros.
drivers/usb/cdns3/core.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
index a0f73d4711ae..85ef3025b293 100644
--- a/drivers/usb/cdns3/core.c
+++ b/drivers/usb/cdns3/core.c
@@ -469,22 +469,14 @@ static int cdns3_probe(struct platform_device *pdev)
if (cdns->dev_irq == -EPROBE_DEFER)
Shouldn't this be
if (cdns->dev_irq < 0)
?
return cdns->dev_irq;
- if (cdns->dev_irq < 0)
- dev_err(dev, "couldn't get peripheral irq\n");
-
regs = devm_platform_ioremap_resource_byname(pdev, "dev");
if (IS_ERR(regs))
return PTR_ERR(regs);
cdns->dev_regs = regs;
cdns->otg_irq = platform_get_irq_byname(pdev, "otg");
- if (cdns->otg_irq == -EPROBE_DEFER)
- return cdns->otg_irq;
-
- if (cdns->otg_irq < 0) {
- dev_err(dev, "couldn't get otg irq\n");
+ if (cdns->otg_irq < 0)
return cdns->otg_irq;
- }
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "otg");
if (!res) {
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2] usb: cdns3: Variable 'length' set but not used
On 12/10/2020 09:45, Pawel Laszczak wrote:
Patch removes not used variable 'length' from
cdns3_wa2_descmiss_copy_data function.
Fixes: 141e70fef4ee ("usb: cdns3: gadget: need to handle sg case for workaround 2
case")
Signed-off-by: Pawel Laszczak
Acked-by: Roger Quadros
---
Changelog:
v2
- added "Fixes" tag.
drivers/usb/cdns3/gadget.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
index 6e7b70a2e352..692acf7b9b14 100644
--- a/drivers/usb/cdns3/gadget.c
+++ b/drivers/usb/cdns3/gadget.c
@@ -506,7 +506,6 @@ static void cdns3_wa2_descmiss_copy_data(struct
cdns3_endpoint *priv_ep,
while (!list_empty(&priv_ep->wa2_descmiss_req_list)) {
int chunk_end;
- int length;
descmiss_priv_req =
cdns3_next_priv_request(&priv_ep->wa2_descmiss_req_list);
@@ -517,7 +516,6 @@ static void cdns3_wa2_descmiss_copy_data(struct
cdns3_endpoint *priv_ep,
break;
chunk_end = descmiss_priv_req->flags & REQUEST_INTERNAL_CH;
- length = request->actual + descmiss_req->actual;
request->status = descmiss_req->status;
__cdns3_descmiss_copy_data(request, descmiss_req);
list_del_init(&descmiss_priv_req->list);
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RFC PATCH 10/24] vdpa: introduce config operations for associating ASID to a virtqueue group
On Mon, Oct 12, 2020 at 03:45:10PM +0800, Jason Wang wrote: > > > > > So in theory we can have several asid's (for different virtqueues), each > > one should be followed by a specific set_map call. If this is so, how do > > I know if I met all the conditions run my driver? Maybe we need another > > callback to let the driver know it should not expect more set_maps(). > > > This should work similarly as in the past. Two parts of the work is expected > to be done by the driver: > > 1) store the mapping somewhere (e.g hardware) during set_map() > 2) associating mapping with a specific virtqueue > > The only difference is that more than one mapping is used now. ok, so like today, I will always get DRIVER_OK after I got all the set_maps(), right? > > For the issue of more set_maps(), driver should be always ready for the new > set_maps() call instead of not expecting new set_maps() since guest memory > topology could be changed due to several reasons. > > Qemu or vhost-vDPA will try their best to avoid the frequency of set_maps() > for better performance (e.g through batched IOTLB updating). E.g there > should be at most one set_map() during one time of guest booting. > > > > >
Re: [LKP] [fs] b6509f6a8c: will-it-scale.per_thread_ops -12.6% regression
On Mon, Oct 12, 2020 at 02:20:26PM +0800, Xing Zhengjun wrote: > Hi Mel, > >It is a revert commit caused the regression, Do you have a plan to fix > it? Thanks. I re-test it in v5.9-rc8, the regression still existed. > The revert caused a *performance* regression but the original performance gain caused a functional failure. The overall performance should be unchanged. I have not revisited the topic since. -- Mel Gorman SUSE Labs
Re: [PATCH 1/6] efistub: pass uefi secureboot flag via fdt params
On Mon, 5 Oct 2020 at 04:20, Chester Lin wrote: > > On Mon, Sep 14, 2020 at 04:05:22PM +0800, Chester Lin wrote: > > Hi Ard, > > > > On Fri, Sep 11, 2020 at 06:01:09PM +0300, Ard Biesheuvel wrote: > > > On Fri, 4 Sep 2020 at 10:29, Chester Lin wrote: > > > > > > > > Add a new UEFI parameter: "linux,uefi-secure-boot" in fdt boot params > > > > as other architectures have done in their own boot data. For example, > > > > the boot_params->secure_boot in x86. > > > > > > > > Signed-off-by: Chester Lin > > > > > > Why do we need this flag? Can't the OS simply check the variable directly? > > > > > > > In fact, there's a difficulty to achieve this. > > > > When linux kernel is booting on ARM, the runtime services are enabled later > > on. > > It's done by arm_enable_runtime_services(), which is registered as an > > early_initcall. > > Before it calls efi_native_runtime_setup(), all EFI runtime callbacks are > > still > > NULL so calling efi.get_variable() will cause NULL pointer dereference. > > > > There's a case that arch_ima_get_secureboot() can be called in early boot > > stage. > > For example, when you try to set "ima_appraise=off" in kernel command line, > > it's > > actually handled early: > > > > [0.00] Kernel command line: > > BOOT_IMAGE=/boot/Image-5.9.0-rc3-9.gdd61cda- > > vanilla root=UUID=a88bfb80-8abb-425c-a0f3-ad317465c28b splash=silent > > mitigations > > =auto ignore_loglevel earlycon=pl011,mmio,0x900 console=ttyAMA0 > > ima_appraise=off > > [0.00] ima: Secure boot enabled: ignoring ima_appraise=off boot > > parameter option > > [0.00] Dentry cache hash table entries: 1048576 (order: 11, 8388608 > > bytes, linear) > > > > However EFI services are remapped and enabled afterwards. > > > > [0.082286] rcu: Hierarchical SRCU implementation. > > [0.089592] Remapping and enabling EFI services. > > [0.097509] smp: Bringing up secondary CPUs ... > > > > Another problem is that efi_rts_wq is created in subsys_initcall so we have > > to > > wait for both EFI services mapping and the workqueue get initiated before > > calling > > efi.get_variable() on ARM. > > > > The only way I can think of is to put a flag via fdt params. May I have your > > suggestions? I will appreciate if there's any better approach. > > > > Thanks, > > Chester > > Ping. May I have some suggestions here? > IMA itself is initialized as a late initcall. The only reason you see this message early is because this is where the parsing of the command line parameter happens. I'll send out a patch with a proposed solution for this issue.
Re: [PATCH 5.9 RT] net: openvswitch: Fix using smp_processor_id() in preemptible code
On 2020-10-12 10:14:42 [+0200], Eelco Chaudron wrote:
>
>
> On 9 Oct 2020, at 17:41, Sebastian Andrzej Siewior wrote:
>
> > On 2020-10-09 14:47:59 [+0200], Juri Lelli wrote:
> > > This happens because openvswitch/flow_table::flow_lookup() accesses
> > > per-cpu data while being preemptible (and migratable).
> > >
> > > Fix it by adding get/put_cpu_light(), so that, even if preempted, the
> > > task executing this code is not migrated (operation is also guarded
> > > by
> > > ovs_mutex mutex).
> >
> > This warning is not limited to PREEMPT_RT it also present upstream since
> > commit
> >eac87c413bf97 ("net: openvswitch: reorder masks array based on
> > usage")
> >
> > You should be able to reproduce it there, too.
> > The path ovs_flow_tbl_lookup() -> flow_lookup() is guarded by ovs_lock()
> > I can't say that this true for
> >ovs_vport_receive() -> ovs_dp_process_packet() ->
> >ovs_flow_tbl_lookup_stats() -> flow_lookup()
> >
> > (means I don't know but it looks like coming from NAPI).
> >
> > Which means u64_stats_update_begin() could have two writers. This must
> > not happen.
> > There are two reader which do u64_stats_fetch_begin_irq(). Disabling
> > interrupts makes no sense since they perform cross-CPU access.
> >
> > -> You need to ensure that there is only one writer at a time.
> >
> > If mask_array gains a spinlock_t for writer protection then you can
> > acquire the lock prio grabbing ->masks_usage_cntr. But as of now there
> > is one `ma->syncp'.
>
> I’m not too familiar with the RT kernel, but in the none RT kernel, this
> function is called in run to completion parts only, hence does not need a
> lock. Actually, this was designed in such a way that it does not need a lock
> at all.
_no_ As explained above, this is not RT specific.
What guaranties that you don't have two flow_lookup() invocations on the
same CPU? You are using u64_stats_update_begin() which must not be
preempted. This means even if preemption is disabled you must not have
another invocation in BH context. This is due to the
write_seqcount_begin() in u64_stats_update_begin().
If preemption / CPU migration is not a problem in the above part, you
can use annotation to disable the warning that led to the warning. But
the u64_stats invocation looks still problematic.
> So maybe this needs a get_cpu() instead of the light variant in the RT case?
> //Eelco
Sebastian
Re: PHY reset question
On 10/12/20 7:48 AM, Oleksij Rempel wrote:
> Hi all,
>
> thank you for the feedback!
>
> On Fri, Oct 09, 2020 at 04:25:49PM +0200, Bruno Thomsen wrote:
>> Hi Fabio and Oleksij
>>
>> Den ons. 7. okt. 2020 kl. 11.50 skrev Fabio Estevam :
>>>
>>> Hi Oleksij,
>>>
>>> On Tue, Oct 6, 2020 at 5:05 AM Oleksij Rempel
>>> wrote:
Hello PHY experts,
Short version:
what is the proper way to handle the PHY reset before identifying PHY?
Long version:
I stumbled over following issue:
If PHY reset is registered within PHY node. Then, sometimes, we will not
be
able to identify it (read PHY ID), because PHY is under reset.
mdio {
compatible = "virtual,mdio-gpio";
[...]
/* Microchip KSZ8081 */
usbeth_phy: ethernet-phy@3 {
reg = <0x3>;
interrupts-extended = <&gpio5 12 IRQ_TYPE_LEVEL_LOW>;
reset-gpios = <&gpio5 11 GPIO_ACTIVE_LOW>;
reset-assert-us = <500>;
reset-deassert-us = <1000>;
};
[...]
};
On simple boards with one PHY per MDIO bus, it is easy to workaround by
using
phy-reset-gpios withing MAC node (illustrated in below DT example),
instead of
using reset-gpios within PHY node (see above DT example).
&fec {
[...]
phy-mode = "rmii";
phy-reset-gpios = <&gpio4 12 GPIO_ACTIVE_LOW>;
[...]
>>>
>>> I thought this has been fixed by Bruno's series:
>>> https://www.spinics.net/lists/netdev/msg673611.html
>>
>> Yes, that has fixed the Microchip/Micrel PHY ID auto detection
>> issue. I have send a DTS patch v3 that makes use of the newly
>> added device tree parameter:
>> https://lkml.org/lkml/2020/9/23/595
>
> This way is suitable only for boards with single PHY and single reset
> line. But it is not scale on boards with multiple PHY and multiple reset
> lines.
>
> So far, it looks like using compatible like "ethernet-phy-id."
> is the only way to go.
I did further digging in this, and I agree it is either this or reset in
boot loader, sigh.
[PATCH] staging: wfx: Spacing and alignment cleanup
From: Izabela Bakollari
This patch fixes minor issue with spacing and alignment.
checkpatch message:
CHECK: Alignment should match open parenthesis
Signed-off-by: Izabela Bakollari
---
drivers/staging/wfx/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wfx/debug.c b/drivers/staging/wfx/debug.c
index 3f1712b7c919..83ccbab50899 100644
--- a/drivers/staging/wfx/debug.c
+++ b/drivers/staging/wfx/debug.c
@@ -32,7 +32,7 @@ static const struct trace_print_flags wfx_reg_print_map[] = {
};
static const char *get_symbol(unsigned long val,
- const struct trace_print_flags *symbol_array)
+ const struct trace_print_flags *symbol_array)
{
int i;
--
2.18.4
Re: [PATCH v5 25/29] arm64: allow LTO_CLANG and THINLTO to be selected
On Fri, Oct 09, 2020 at 09:13:34AM -0700, Sami Tolvanen wrote: > Allow CONFIG_LTO_CLANG and CONFIG_THINLTO to be enabled. > > Signed-off-by: Sami Tolvanen > Reviewed-by: Kees Cook > --- > arch/arm64/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index ad522b021f35..7016d193864f 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -72,6 +72,8 @@ config ARM64 > select ARCH_USE_SYM_ANNOTATIONS > select ARCH_SUPPORTS_MEMORY_FAILURE > select ARCH_SUPPORTS_SHADOW_CALL_STACK if CC_HAVE_SHADOW_CALL_STACK > + select ARCH_SUPPORTS_LTO_CLANG > + select ARCH_SUPPORTS_THINLTO Please don't enable this for arm64 until we have the dependency stuff sorted out. I posted patches [1] for this before, but I think they should be part of this series as they don't make sense on their own. Will [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=rwonce/read-barrier-depends
[PATCH] Documentation/admin-guide: tainted-kernels: Fix typo occured
Fix typo. s/occured/occurred/ Signed-off-by: Naoki Hayama --- Documentation/admin-guide/tainted-kernels.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst index abf804719890..f718a2eaf1f6 100644 --- a/Documentation/admin-guide/tainted-kernels.rst +++ b/Documentation/admin-guide/tainted-kernels.rst @@ -130,7 +130,7 @@ More detailed explanation for tainting 5) ``B`` If a page-release function has found a bad page reference or some unexpected page flags. This indicates a hardware problem or a kernel bug; there should be other information in the log indicating why this tainting - occured. + occurred. 6) ``U`` if a user or user application specifically requested that the Tainted flag be set, ``' '`` otherwise. -- 2.17.1
[PATCH] trace: Return ENOTCONN instead of EBADF
When there is no clients listening on event the trace return EBADF. The file is not a bad file descriptor and to get the userspace able to do a proper error handling it need a different error code that separate a bad file descriptor from a empty listening. Signed-off-by: Peter Enderborg --- kernel/trace/trace.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index d3e5de717df2..6e592bf736df 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -6651,8 +6651,8 @@ tracing_mark_write(struct file *filp, const char __user *ubuf, event = __trace_buffer_lock_reserve(buffer, TRACE_PRINT, size, irq_flags, preempt_count()); if (unlikely(!event)) - /* Ring buffer disabled, return as if not open for write */ - return -EBADF; + /* Ring buffer disabled, return as if not connected */ + return -ENOTCONN; entry = ring_buffer_event_data(event); entry->ip = _THIS_IP_; @@ -6731,8 +6731,8 @@ tracing_mark_raw_write(struct file *filp, const char __user *ubuf, event = __trace_buffer_lock_reserve(buffer, TRACE_RAW_DATA, size, irq_flags, preempt_count()); if (!event) - /* Ring buffer disabled, return as if not open for write */ - return -EBADF; + /* Ring buffer disabled, return not connected */ + return -ENOTCONN; entry = ring_buffer_event_data(event); -- 2.17.1
Re: [Cocci] [PATCH v4 2/3] scripts: coccicheck: Change default condition for parallelism
On Sun, 11 Oct 2020, Sumera Priyadarsini wrote: > Currently, Coccinelle uses at most one thread per core by default in > machines with more than 2 hyperthreads. However, for systems with only 4 > hyperthreads, this does not improve performance. > > Modify coccicheck to use all available threads in machines with > upto 4 hyperthreads. > > Signed-off-by: Sumera Priyadarsini Applied, thanks. > --- > scripts/coccicheck | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/coccicheck b/scripts/coccicheck > index d67907b8a38b..209bb0427b43 100755 > --- a/scripts/coccicheck > +++ b/scripts/coccicheck > @@ -79,7 +79,7 @@ else > THREADS_PER_CORE=$(lscpu | grep "Thread(s) per core: " | tr -cd > "[:digit:]") > if [ -z "$J" ]; then > NPROC=$(getconf _NPROCESSORS_ONLN) > - if [ $THREADS_PER_CORE -gt 1 -a $NPROC -gt 2 ] ; then > + if [ $THREADS_PER_CORE -gt 1 -a $NPROC -gt 4 ] ; then > NPROC=$((NPROC/2)) > fi > else > -- > 2.25.1 > > ___ > Cocci mailing list > co...@systeme.lip6.fr > https://systeme.lip6.fr/mailman/listinfo/cocci >
Re: [Cocci] [PATCH v4 1/3] scripts: coccicheck: Add quotes to improve portability
On Sun, 11 Oct 2020, Sumera Priyadarsini wrote: > While fetching the number of threads per core with lscpu, > the [:digit:] set is used for translation of digits from 0-9. > However, using [:digit:] instead of "[:digit:]" does not seem > to work uniformly for some shell types and configurations > (such as zsh). > > Therefore, modify coccicheck to use double quotes around the > [:digit:] set for uniformity and better portability. > > Signed-off-by: Sumera Priyadarsini Applied, thanks. > --- > scripts/coccicheck | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/coccicheck b/scripts/coccicheck > index 6789751607f5..d67907b8a38b 100755 > --- a/scripts/coccicheck > +++ b/scripts/coccicheck > @@ -76,7 +76,7 @@ else > fi > > # Use only one thread per core by default if hyperthreading is enabled > -THREADS_PER_CORE=$(lscpu | grep "Thread(s) per core: " | tr -cd > [:digit:]) > +THREADS_PER_CORE=$(lscpu | grep "Thread(s) per core: " | tr -cd > "[:digit:]") > if [ -z "$J" ]; then > NPROC=$(getconf _NPROCESSORS_ONLN) > if [ $THREADS_PER_CORE -gt 1 -a $NPROC -gt 2 ] ; then > -- > 2.25.1 > > ___ > Cocci mailing list > co...@systeme.lip6.fr > https://systeme.lip6.fr/mailman/listinfo/cocci >
Re: [PATCH] dt-bindings: sound: sun8i-a33-codec: Add Allwinner A64 codec compatible fallback
Hi Maxime and all, On Mon, 12 Oct 2020 at 09:50, Maxime Ripard wrote: > > Hi! > > On Sun, Oct 11, 2020 at 11:15:42PM +0200, Clément Péron wrote: > > make dtbs_check report a warning because the documentation > > for the A64 codec compatible is missing. > > > > The A64 codec compatible is actually a simple fallback to the A33. > > > > Reflect this in the dt-bindings Documentation. > > > > Signed-off-by: Clément Péron > > This patch is already in the ASoC tree and linux-next: I was indeed on top of sunxi/for-next and not linux-next/master I will test on top of linux-next for the next ones. Sorry for the duplicate patch and the noise :(. Clement > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml?id=cef305d4eb0733f25215793ed30b056a7db9bb62 > > Maxime
Re: [Cocci] [PATCH v4 3/3] Documentation: Coccinelle: Modify Parallelisation information in docs
On Sun, 11 Oct 2020, Sumera Priyadarsini wrote: > This patchset modifies coccicheck to use at most one thread per core by > default in machines with more than 4 hyperthreads for optimal performance. > Modify documentation in coccinelle.rst to reflect the same. > > Signed-off-by: Sumera Priyadarsini Acked-by: Julia Lawall Jonathan, will you take this patch? thanks, julia > --- > Documentation/dev-tools/coccinelle.rst | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/Documentation/dev-tools/coccinelle.rst > b/Documentation/dev-tools/coccinelle.rst > index 74c5e6aeeff5..530d8d313601 100644 > --- a/Documentation/dev-tools/coccinelle.rst > +++ b/Documentation/dev-tools/coccinelle.rst > @@ -130,8 +130,10 @@ To enable verbose messages set the V= variable, for > example:: > Coccinelle parallelization > -- > > -By default, coccicheck tries to run as parallel as possible. To change > -the parallelism, set the J= variable. For example, to run across 4 CPUs:: > +By default, coccicheck uses at most 1 thread per core in a machine > +with more than 4 hyperthreads. In a machine with upto 4 threads, > +all threads are used. To change the parallelism, set the J= variable. > +For example, to run across 4 CPUs:: > > make coccicheck MODE=report J=4 > > -- > 2.25.1 > > ___ > Cocci mailing list > co...@systeme.lip6.fr > https://systeme.lip6.fr/mailman/listinfo/cocci >
Re: [PATCH v4 03/17] x86/acrn: Introduce an API to check if a VM is privileged
Hi Boris,
On Wed 30.Sep'20 at 10:09:59 +0200, Borislav Petkov wrote:
On Tue, Sep 22, 2020 at 07:42:57PM +0800, shuo.a@intel.com wrote:
+static u32 acrn_cpuid_base(void)
+{
+ static u32 acrn_cpuid_base;
+
+ if (!acrn_cpuid_base && boot_cpu_has(X86_FEATURE_HYPERVISOR))
+ acrn_cpuid_base = hypervisor_cpuid_base("ACRNACRNACRN", 0);
+
+ return acrn_cpuid_base;
+}
+
+bool acrn_is_privileged_vm(void)
+{
+ return cpuid_eax(acrn_cpuid_base() | ACRN_CPUID_FEATURES) &
What's that dance and acrn_cpuid_base static thing needed for? Why not
simply:
cpuid_eax(ACRN_CPUID_FEATURES) & ...
?
hypervisor_cpuid_base() searches reserved hypervisor cpuid region and
return the base matched the right signature, the base might vary. So i
put it here.
+ACRN_FEATURE_PRIVILEGED_VM;
+}
+EXPORT_SYMBOL_GPL(acrn_is_privileged_vm);
Also, if you're going to need more of those bit checkers acrn_is_
which look at ACRN_CPUID_FEATURES, just stash CPUID_0x4001_EAX locally and
use a
acrn_has(ACRN_FEATURE_PRIVILEGED_VM)
which does the bit testing.
Thanks. Currently, there is only one feature bit. I will introduce
that you suggested with more feature bits to be tested.
Thanks
shuo
Re: [External] Re: [PATCH] mm: proc: add Sock to /proc/meminfo
On Mon, Oct 12, 2020 at 3:42 PM Eric Dumazet wrote:
>
> On Mon, Oct 12, 2020 at 6:22 AM Muchun Song wrote:
> >
> > On Mon, Oct 12, 2020 at 2:39 AM Cong Wang wrote:
> > >
> > > On Sat, Oct 10, 2020 at 3:39 AM Muchun Song
> > > wrote:
> > > >
> > > > The amount of memory allocated to sockets buffer can become significant.
> > > > However, we do not display the amount of memory consumed by sockets
> > > > buffer. In this case, knowing where the memory is consumed by the kernel
> > >
> > > We do it via `ss -m`. Is it not sufficient? And if not, why not adding it
> > > there
> > > rather than /proc/meminfo?
> >
> > If the system has little free memory, we can know where the memory is via
> > /proc/meminfo. If a lot of memory is consumed by socket buffer, we cannot
> > know it when the Sock is not shown in the /proc/meminfo. If the unaware user
> > can't think of the socket buffer, naturally they will not `ss -m`. The
> > end result
> > is that we still don’t know where the memory is consumed. And we add the
> > Sock to the /proc/meminfo just like the memcg does('sock' item in the cgroup
> > v2 memory.stat). So I think that adding to /proc/meminfo is sufficient.
> >
> > >
> > > > static inline void __skb_frag_unref(skb_frag_t *frag)
> > > > {
> > > > - put_page(skb_frag_page(frag));
> > > > + struct page *page = skb_frag_page(frag);
> > > > +
> > > > + if (put_page_testzero(page)) {
> > > > + dec_sock_node_page_state(page);
> > > > + __put_page(page);
> > > > + }
> > > > }
> > >
> > > You mix socket page frag with skb frag at least, not sure this is exactly
> > > what you want, because clearly skb page frags are frequently used
> > > by network drivers rather than sockets.
> > >
> > > Also, which one matches this dec_sock_node_page_state()? Clearly
> > > not skb_fill_page_desc() or __skb_frag_ref().
> >
> > Yeah, we call inc_sock_node_page_state() in the skb_page_frag_refill().
> > So if someone gets the page returned by skb_page_frag_refill(), it must
> > put the page via __skb_frag_unref()/skb_frag_unref(). We use PG_private
> > to indicate that we need to dec the node page state when the refcount of
> > page reaches zero.
> >
>
> Pages can be transferred from pipe to socket, socket to pipe (splice()
> and zerocopy friends...)
>
> If you want to track TCP memory allocations, you always can look at
> /proc/net/sockstat,
> without adding yet another expensive memory accounting.
The 'mem' item in the /proc/net/sockstat does not represent real
memory usage. This is just the total amount of charged memory.
For example, if a task sends a 10-byte message, it only charges one
page to memcg. But the system may allocate 8 pages. Therefore, it
does not truly reflect the memory allocated by the above memory
allocation path. We can see the difference via the following message.
cat /proc/net/sockstat
sockets: used 698
TCP: inuse 70 orphan 0 tw 617 alloc 134 mem 13
UDP: inuse 90 mem 4
UDPLITE: inuse 0
RAW: inuse 1
FRAG: inuse 0 memory 0
cat /proc/meminfo | grep Sock
Sock: 13664 kB
The /proc/net/sockstat only shows us that there are 17*4 kB TCP
memory allocations. But apply this patch, we can see that we truly
allocate 13664 kB(May be greater than this value because of per-cpu
stat cache). Of course the load of the example here is not high. In
some high load cases, I believe the difference here will be even
greater.
--
Yours,
Muchun
Re: [PATCH v3 0/2] KVM: x86: hyper-v: make KVM_GET_SUPPORTED_HV_CPUID more useful
Vitaly Kuznetsov writes: > Changes since v2: > - Keep vCPU version of the ioctl intact but make it 'deprecated' in > api.rst [Paolo Bonzini] > - First two patches of v2 series already made it to kvm/queue > > QEMU series using the feature: > https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg02017.html > > Original description: > > KVM_GET_SUPPORTED_HV_CPUID was initially implemented as a vCPU ioctl but > this is not very useful when VMM is just trying to query which Hyper-V > features are supported by the host prior to creating VM/vCPUs. The data > in KVM_GET_SUPPORTED_HV_CPUID is mostly static with a few exceptions but > it seems we can change this. Add support for KVM_GET_SUPPORTED_HV_CPUID as > a system ioctl as well. > > QEMU specific description: > In some cases QEMU needs to collect the information about which Hyper-V > features are supported by KVM and pass it up the stack. For non-hyper-v > features this is done with system-wide KVM_GET_SUPPORTED_CPUID/ > KVM_GET_MSRS ioctls but Hyper-V specific features don't get in the output > (as Hyper-V CPUIDs intersect with KVM's). In QEMU, CPU feature expansion > happens before any KVM vcpus are created so KVM_GET_SUPPORTED_HV_CPUID > can't be used in its current shape. > > Vitaly Kuznetsov (2): > KVM: x86: hyper-v: allow KVM_GET_SUPPORTED_HV_CPUID as a system ioctl > KVM: selftests: test KVM_GET_SUPPORTED_HV_CPUID as a system ioctl > > Documentation/virt/kvm/api.rst| 16 ++-- > arch/x86/kvm/hyperv.c | 6 +- > arch/x86/kvm/hyperv.h | 4 +- > arch/x86/kvm/vmx/evmcs.c | 3 +- > arch/x86/kvm/x86.c| 45 ++ > include/uapi/linux/kvm.h | 3 +- > .../testing/selftests/kvm/include/kvm_util.h | 2 + > tools/testing/selftests/kvm/lib/kvm_util.c| 26 ++ > .../selftests/kvm/x86_64/hyperv_cpuid.c | 87 +++ > 9 files changed, 123 insertions(+), 69 deletions(-) Ping) Still hoping this can be picked up for 5.10. the latest QEMU patchset was posted last Friday: https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg02443.html -- Vitaly
[net v4] net: dsa: microchip: fix race condition
Between queuing the delayed work and finishing the setup of the dsa
ports, the process may sleep in request_module() (via
phy_device_create()) and the queued work may be executed prior to the
switch net devices being registered. In ksz_mib_read_work(), a NULL
dereference will happen within netof_carrier_ok(dp->slave).
Not queuing the delayed work in ksz_init_mib_timer() makes things even
worse because the work will now be queued for immediate execution
(instead of 2000 ms) in ksz_mac_link_down() via
dsa_port_link_register_of().
Call tree:
ksz9477_i2c_probe()
\--ksz9477_switch_register()
\--ksz_switch_register()
+--dsa_register_switch()
| \--dsa_switch_probe()
| \--dsa_tree_setup()
|\--dsa_tree_setup_switches()
| +--dsa_switch_setup()
| | +--ksz9477_setup()
| | | \--ksz_init_mib_timer()
| | | |--/* Start the timer 2 seconds later. */
| | | \--schedule_delayed_work(&dev->mib_read,
msecs_to_jiffies(2000));
| | \--__mdiobus_register()
| | \--mdiobus_scan()
| |\--get_phy_device()
| | +--get_phy_id()
| | \--phy_device_create()
| | |--/* sleeping, ksz_mib_read_work() can be
called meanwhile */
| | \--request_module()
| |
| \--dsa_port_setup()
| +--/* Called for non-CPU ports */
| +--dsa_slave_create()
| | +--/* Too late, ksz_mib_read_work() may be called
beforehand */
| | \--port->slave = ...
| ...
| +--Called for CPU port */
| \--dsa_port_link_register_of()
| \--ksz_mac_link_down()
|+--/* mib_read must be initialized here */
|+--/* work is already scheduled, so it will be
executed after 2000 ms */
|\--schedule_delayed_work(&dev->mib_read, 0);
\-- /* here port->slave is setup properly, scheduling the delayed work
should be safe */
Solution:
1. Do not queue (only initialize) delayed work in ksz_init_mib_timer().
2. Only queue delayed work in ksz_mac_link_down() if init is completed.
3. Queue work once in ksz_switch_register(), after dsa_register_switch()
has completed.
Fixes: 7c6ff470aa86 ("net: dsa: microchip: add MIB counter reading support")
Signed-off-by: Christian Eggers
Reviewed-by: Florian Fainelli
Reviewed-by: Vladimir Oltean
Reviewed-by: Jakub Kicinski
---
On Friday, 9 October 2020, 22:04:42 CEST, Jakub Kicinski wrote:
> Your patch seems fine, but I wonder what was the original author trying
> to achieve with this schedule_delayed_work(..., 0) call?
>
> The work is supposed to be scheduled at this point, right?
> In that case another call to schedule_delayed_work() is
> simply ignored.
I came to the same conclusion...
> Judging by the comment it seems like someone was under the impression
> this will reschedule the work to be run immediately, which is not the
> case.
>
> In fact looks like a separate bug introduced in:
>
> 469b390e1ba3 ("net: dsa: microchip: use delayed_work instead of timer + work")
Seems so. Before that change, the "work" was only queued after timer expiry, so
it could be scheduled for "soon" execution when the link is going down. After
that change, the work is always queued as "delayed work", so scheduling when the
the link goes down has no effect.
@George: Can you write a fix for this?
v4:
-
- Added Reviewed-by: tags from Florian, Vladimir and Jakub
v3:
-
- Use 12 digts for commit id in "Fixes:" tag
v2:
-
- no changes in the patch itself
- use correct subject-prefix
- changed wording of commit description
- added call tree to commit description
- added "Fixes:" tag
drivers/net/dsa/microchip/ksz_common.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/dsa/microchip/ksz_common.c
b/drivers/net/dsa/microchip/ksz_common.c
index 01f5784f69cb..0ef854911f21 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -103,14 +103,8 @@ void ksz_init_mib_timer(struct ksz_device *dev)
INIT_DELAYED_WORK(&dev->mib_read, ksz_mib_read_work);
- /* Read MIB counters every 30 seconds to avoid overflow. */
- dev->mib_read_interval = msecs_to_jiffies(3);
-
for (i = 0; i < dev->mib_port_cnt; i++)
dev->dev_ops->port_init_cnt(dev, i);
-
- /* Start the timer 2 seconds later. */
- schedule_delayed_work(&dev->mib_read, msecs_to_jiffies(2000));
}
EXPORT_SYMBOL_GPL(ksz_init_mib_timer);
@@ -143,7 +137,9 @@ void ksz_mac_link_down(struct dsa_switch *ds, int port,
unsigned int mode,
/* Read all MIB counters when the link is going down. */
Re: [PATCH] mmc: sdhci-pci-gli: Set SDR104's clock to 205MHz and enable SSC for GL975x
Hi Ulf,
Regarding this patch, we also want to fix the EMI of one hardware
using the old version(such as v5.4).
Is there a chance to append a Fixes tag on this patch ?
Or what should I do ?
Best Regards,
Ben
On Wed, Aug 5, 2020 at 2:34 PM Ulf Hansson wrote:
>
> On Fri, 17 Jul 2020 at 05:33, Ben Chuang wrote:
> >
> > From: Ben Chuang
> >
> > Set SDR104's clock to 205MHz and enable SSC for GL9750 and GL9755
> >
> > Signed-off-by: Ben Chuang
>
> Applied for next (a while ago), thanks!
>
> Kind regards
> Uffe
>
>
> > ---
> > drivers/mmc/host/sdhci-pci-gli.c | 220 ++-
> > 1 file changed, 218 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-pci-gli.c
> > b/drivers/mmc/host/sdhci-pci-gli.c
> > index ca0166d9bf82..5da2b06d84ae 100644
> > --- a/drivers/mmc/host/sdhci-pci-gli.c
> > +++ b/drivers/mmc/host/sdhci-pci-gli.c
> > @@ -31,10 +31,18 @@
> > #define SDHCI_GLI_9750_ALL_RST (BIT(24)|BIT(25)|BIT(28)|BIT(30))
> >
> > #define SDHCI_GLI_9750_PLL 0x864
> > +#define SDHCI_GLI_9750_PLL_LDIV GENMASK(9, 0)
> > +#define SDHCI_GLI_9750_PLL_PDIV GENMASK(14, 12)
> > +#define SDHCI_GLI_9750_PLL_DIRBIT(15)
> > #define SDHCI_GLI_9750_PLL_TX2_INVBIT(23)
> > #define SDHCI_GLI_9750_PLL_TX2_DLYGENMASK(22, 20)
> > #define GLI_9750_PLL_TX2_INV_VALUE0x1
> > #define GLI_9750_PLL_TX2_DLY_VALUE0x0
> > +#define SDHCI_GLI_9750_PLLSSC_STEPGENMASK(28, 24)
> > +#define SDHCI_GLI_9750_PLLSSC_EN BIT(31)
> > +
> > +#define SDHCI_GLI_9750_PLLSSC0x86C
> > +#define SDHCI_GLI_9750_PLLSSC_PPMGENMASK(31, 16)
> >
> > #define SDHCI_GLI_9750_SW_CTRL 0x874
> > #define SDHCI_GLI_9750_SW_CTRL_4GENMASK(7, 6)
> > @@ -76,6 +84,21 @@
> > #define PCIE_GLI_9763E_SCR 0x8E0
> > #define GLI_9763E_SCR_AXI_REQ BIT(9)
> >
> > +#define PCI_GLI_9755_WT 0x800
> > +#define PCI_GLI_9755_WT_ENBIT(0)
> > +#define GLI_9755_WT_EN_ON 0x1
> > +#define GLI_9755_WT_EN_OFF0x0
> > +
> > +#define PCI_GLI_9755_PLL0x64
> > +#define PCI_GLI_9755_PLL_LDIV GENMASK(9, 0)
> > +#define PCI_GLI_9755_PLL_PDIV GENMASK(14, 12)
> > +#define PCI_GLI_9755_PLL_DIRBIT(15)
> > +#define PCI_GLI_9755_PLLSSC_STEPGENMASK(28, 24)
> > +#define PCI_GLI_9755_PLLSSC_EN BIT(31)
> > +
> > +#define PCI_GLI_9755_PLLSSC0x68
> > +#define PCI_GLI_9755_PLLSSC_PPMGENMASK(15, 0)
> > +
> > #define GLI_MAX_TUNING_LOOP 40
> >
> > /* Genesys Logic chipset */
> > @@ -280,6 +303,84 @@ static int gl9750_execute_tuning(struct sdhci_host
> > *host, u32 opcode)
> > return 0;
> > }
> >
> > +static void gl9750_disable_ssc_pll(struct sdhci_host *host)
> > +{
> > + u32 pll;
> > +
> > + gl9750_wt_on(host);
> > + pll = sdhci_readl(host, SDHCI_GLI_9750_PLL);
> > + pll &= ~(SDHCI_GLI_9750_PLL_DIR | SDHCI_GLI_9750_PLLSSC_EN);
> > + sdhci_writel(host, pll, SDHCI_GLI_9750_PLL);
> > + gl9750_wt_off(host);
> > +}
> > +
> > +static void gl9750_set_pll(struct sdhci_host *host, u8 dir, u16 ldiv, u8
> > pdiv)
> > +{
> > + u32 pll;
> > +
> > + gl9750_wt_on(host);
> > + pll = sdhci_readl(host, SDHCI_GLI_9750_PLL);
> > + pll &= ~(SDHCI_GLI_9750_PLL_LDIV |
> > +SDHCI_GLI_9750_PLL_PDIV |
> > +SDHCI_GLI_9750_PLL_DIR);
> > + pll |= FIELD_PREP(SDHCI_GLI_9750_PLL_LDIV, ldiv) |
> > + FIELD_PREP(SDHCI_GLI_9750_PLL_PDIV, pdiv) |
> > + FIELD_PREP(SDHCI_GLI_9750_PLL_DIR, dir);
> > + sdhci_writel(host, pll, SDHCI_GLI_9750_PLL);
> > + gl9750_wt_off(host);
> > +
> > + /* wait for pll stable */
> > + mdelay(1);
> > +}
> > +
> > +static void gl9750_set_ssc(struct sdhci_host *host, u8 enable, u8 step,
> > u16 ppm)
> > +{
> > + u32 pll;
> > + u32 ssc;
> > +
> > + gl9750_wt_on(host);
> > + pll = sdhci_readl(host, SDHCI_GLI_9750_PLL);
> > + ssc = sdhci_readl(host, SDHCI_GLI_9750_PLLSSC);
> > + pll &= ~(SDHCI_GLI_9750_PLLSSC_STEP |
> > +SDHCI_GLI_9750_PLLSSC_EN);
> > + ssc &= ~SDHCI_GLI_9750_PLLSSC_PPM;
> > + pll |= FIELD_PREP(SDHCI_GLI_9750_PLLSSC_STEP, step) |
> > + FIELD_PREP(SDHCI_GLI_9750_PLLSSC_EN, enable);
> > + ssc |= FIELD_PREP(SDHCI_GLI_9750_PLLSSC_PPM, ppm);
> > + sdhci_writel(host, ssc, SDHCI_GLI_9750_PLLSSC);
> > + sdhci_writel(host, pll, SDHCI_GLI_9750_PLL);
> > + gl9750_wt_off(host);
> > +}
> > +
> > +static void gl9750_set_ssc_pll_205mhz(struct sdhci_host *host)
> > +{
> > + /* set pll to 205MHz and enable ssc */
> > + gl9750_set_ssc(host, 0x1, 0x1F, 0xFFE7);
> > + gl9750_set_pll(host, 0x1, 0x246, 0x0);
> > +}
> > +
> > +static void sdhci_gl9750_set_clock(struct sdhci_host *host, unsigned int
> > clock)
> > +{
> > + struct mmc_ios *ios = &host->mmc->ios;
> > + u16 clk;
> > +
> > + ho
Re: [PATCH v4 04/17] x86/acrn: Introduce hypercall interfaces
On Wed 30.Sep'20 at 12:14:03 -0700, Nick Desaulniers wrote:
On Wed, Sep 30, 2020 at 10:13 AM Peter Zijlstra wrote:
On Wed, Sep 30, 2020 at 11:10:36AM -0500, Segher Boessenkool wrote:
> Since this variable is a local register asm, on entry to the asm the
> compiler guarantees that the value lives in the assigned register (the
> "r8" hardware register in this case). This all works completely fine.
> This is the only guaranteed behaviour for local register asm (well,
> together with analogous behaviour for outputs).
Right, that's what they're trying to achieve. The hypervisor calling
convention needs that variable in %r8 (which is somewhat unfortunate).
AFAIK this is the first such use in the kernel, but at least the gcc-4.9
(our oldest supported version) claims to support this.
So now we need to know if clang will actually do this too..
Does clang support register local storage? Let's use godbolt.org to find out:
https://godbolt.org/z/YM45W5
Looks like yes. You can even check different GCC versions via the
dropdown in the top right.
The -ffixed-* flags are less well supported in Clang; they need to be
reimplemented on a per-backend basis. aarch64 is relatively well
supported, but other arches not so much IME.
Do we need register local storage here?
static inline long bar(unsigned long hcall_id)
{
long result;
asm volatile("movl %1, %%r8d\n\t"
"vmcall\n\t"
: "=a" (result)
: "ir" (hcall_id)
: );
return result;
}
Yeah, this approach is also mentioned in the changelog. I will change to
this way to follow your preference. With an addtional "r8" clobber what
Arvind mentioned.
Thanks
shuo
Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api
On 29/09/2020 01:11, Lu Baolu wrote: Hi Tvrtko, On 9/28/20 5:44 PM, Tvrtko Ursulin wrote: On 27/09/2020 07:34, Lu Baolu wrote: Hi, The previous post of this series could be found here. https://lore.kernel.org/linux-iommu/20200912032200.11489-1-baolu...@linux.intel.com/ This version introduce a new patch [4/7] to fix an issue reported here. https://lore.kernel.org/linux-iommu/51a1baec-48d1-c0ac-181b-1fba92aa4...@linux.intel.com/ There aren't any other changes. Please help to test and review. Best regards, baolu Lu Baolu (3): iommu: Add quirk for Intel graphic devices in map_sg Since I do have patches to fix i915 to handle this, do we want to co-ordinate the two and avoid having to add this quirk and then later remove it? Or you want to go the staged approach? I have no preference. It depends on which patch goes first. Let the maintainers help here. FYI we have merged the required i915 patches to out tree last week or so. I *think* this means they will go into 5.11. So the i915 specific workaround patch will not be needed in Intel IOMMU. Regards, Tvrtko
Re: [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711
On Mon, Oct 12, 2020 at 08:47:15AM +0200, Christoph Hellwig wrote: > On Fri, Oct 09, 2020 at 06:10:52PM +0100, Catalin Marinas wrote: > > kdump wants DMA-able memory and, > > DMAable by whom? The only way to guranteed DMAable memory is to use > the DMA memory allocator(s) and pass a specific device to them. Everyting > else is just fundamentally broken. Note that even when device is not > DMAable we can still use swiotlb to access it. What I meant is that the new kexec'ed kernel needs some memory in the ZONE_DMA range, currently set to the bottom 30-bit even for platforms that can cope with the whole 32-bit range (anything other than RPi4). The memory range available to the kdump kernels is limited to what reserve_crashkernel() allocated, which may not fit in the lower 1GB. There are two ongoing threads (complementary): 1. Change the arm64 reserve_crashkernel() similar to x86 which allocates memory above 4G with a small block in the ZONE_DMA range. 2. Allow zone_dma_bits to be 32 for arm64 platforms other than RPi4. The second point also fixes some regressions with CMA reservations that could no longer fit in the lower 1GB. -- Catalin
Re: [PATCH V9 1/4] perf/core: Add PERF_SAMPLE_DATA_PAGE_SIZE
On Sat, Oct 10, 2020 at 12:28:39AM +1100, Michael Ellerman wrote: > Peter Zijlstra writes: > > Patch 4 makes it all far worse by exposing it to pretty much everybody. > > > > Now, I think we can fix at least the user mappings with the below delta, > > but if archs are using non-page-table MMU sizes we'll need arch helpers. > > > > ARM64 is in that last boat. > > I think we probably need it to be weak so we can provide our own > version. I guess the same thing applies to us, but I can't really tell how accurate this stuff needs to be for userspace. If it's trying to use the page-table configuration to infer properties of the TLB, that's never going to be reliable because the TLB can choose both to split and coalesce entries as long as software can't tell. Will
linux-next: manual merge of the akpm-current tree with the counters tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
lib/Makefile
between commit:
37a0dbf631f6 ("counters: Introduce counter_atomic* counters")
from the counters tree and commit:
ed7f5253e189 ("mm/page_alloc.c: fix freeing non-compound pages")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc lib/Makefile
index 95b357bb5f3c,1c7577b2e86a..
--- a/lib/Makefile
+++ b/lib/Makefile
@@@ -99,7 -101,7 +101,8 @@@ obj-$(CONFIG_TEST_BLACKHOLE_DEV) += tes
obj-$(CONFIG_TEST_MEMINIT) += test_meminit.o
obj-$(CONFIG_TEST_LOCKUP) += test_lockup.o
obj-$(CONFIG_TEST_HMM) += test_hmm.o
+obj-$(CONFIG_TEST_COUNTERS) += test_counters.o
+ obj-$(CONFIG_TEST_FREE_PAGES) += test_free_pages.o
#
# CFLAGS for compiling floating point code inside the kernel. x86/Makefile
turns
pgpQUDEQ5K9L7.pgp
Description: OpenPGP digital signature
Re: [PATCH v4 04/17] x86/acrn: Introduce hypercall interfaces
On Wed 30.Sep'20 at 12:54:08 +0200, Borislav Petkov wrote: On Tue, Sep 22, 2020 at 07:42:58PM +0800, shuo.a@intel.com wrote: From: Shuo Liu The Service VM communicates with the hypervisor via conventional hypercalls. VMCALL instruction is used to make the hypercalls. ACRN hypercall ABI: * Hypercall number is in R8 register. * Up to 2 parameters are in RDI and RSI registers. * Return value is in RAX register. I'm assuming this is already cast in stone in the HV and it cannot be changed? Yes, it is. Introduce the ACRN hypercall interfaces. Because GCC doesn't support R8 register as direct register constraints, here are two ways to use R8 in extended asm: 1) use explicit register variable as input 2) use supported constraint as input with a explicit MOV to R8 in beginning of asm The number of instructions of above two ways are same. Asm code from 1) 38: 41 b8 00 00 00 80 mov$0x8000,%r8d 3e: 48 89 c7mov%rax,%rdi 41: 0f 01 c1vmcall Here, writes to the lower dword (%r8d) clear the upper dword of %r8 when the CPU is in 64-bit mode. Asm code from 2) 38: 48 89 c7mov%rax,%rdi 3b: 49 b8 00 00 00 80 00movabs $0x8000,%r8 42: 00 00 00 45: 0f 01 c1vmcall Choose 1) for code simplicity and a little bit of code size optimization. What? How much "optimization" is this actually? A couple of bytes? And all that for this /* Nothing can come between the r8 assignment and the asm: */ restriction? If it is only a couple of bytes, just do the explicit MOV to %r8 and f'get about it. Yes. Just a couple of bytes. Number of instructions is same. sure, i can change to approach 2) 2) use supported constraint as input with a explicit MOV to R8 in beginning of asm Thanks shuo
Re: [PATCH v4 01/17] docs: acrn: Introduce ACRN
On Thu 8.Oct'20 at 18:48:52 -0700, Randy Dunlap wrote: On 9/22/20 4:42 AM, shuo.a@intel.com wrote: From: Shuo Liu Add documentation on the following aspects of ACRN: 1) A brief introduction on the architecture of ACRN. 2) I/O request handling in ACRN. To learn more about ACRN, please go to ACRN project website https://projectacrn.org, or the documentation page https://projectacrn.github.io/. Signed-off-by: Shuo Liu Reviewed-by: Zhi Wang Reviewed-by: Reinette Chatre Cc: Dave Hansen Cc: Sen Christopherson Cc: Dan Williams Cc: Fengwei Yin Cc: Zhi Wang Cc: Zhenyu Wang Cc: Yu Wang Cc: Reinette Chatre Cc: Greg Kroah-Hartman --- Documentation/virt/acrn/index.rst| 11 +++ Documentation/virt/acrn/introduction.rst | 40 ++ Documentation/virt/acrn/io-request.rst | 97 Documentation/virt/index.rst | 1 + MAINTAINERS | 7 ++ 5 files changed, 156 insertions(+) create mode 100644 Documentation/virt/acrn/index.rst create mode 100644 Documentation/virt/acrn/introduction.rst create mode 100644 Documentation/virt/acrn/io-request.rst diff --git a/Documentation/virt/acrn/io-request.rst b/Documentation/virt/acrn/io-request.rst new file mode 100644 index ..019dc5978f7c --- /dev/null +++ b/Documentation/virt/acrn/io-request.rst @@ -0,0 +1,97 @@ +.. SPDX-License-Identifier: GPL-2.0 + +I/O request handling + + +An I/O request of a User VM, which is constructed by the hypervisor, is +distributed by the ACRN Hypervisor Service Module to an I/O client +corresponding to the address range of the I/O request. Details of I/O request +handling are described in the following sections. + +1. I/O request +-- + ... + +2. I/O clients +-- + ... + +3. I/O request state transition +--- + +The state transitions of a ACRN I/O request are as follows. of an ACRN OK. Thanks for review. Thanks shuo
[PATCH v1 00/15] Introduce threaded trace streaming for basic perf record operation
Patch set provides threaded trace streaming for base perf record operation. Provided streaming mode (--threads) mitigates profiling data losses and resolves scalability issues of serial and asynchronous (--aio) trace streaming modes on multicore server systems. The patch set is based on the prototype [1], [2] and the most closely relates to mode 3) "mode that creates thread for every monitored memory map". The threaded mode executes one-to-one mapping of trace streaming threads to mapped data buffers and streaming into per-CPU trace files located at data directory. The data buffers and threads are affined to NUMA nodes and monitored CPUs according to system topology. --cpu option can be used to specify exact CPUs to be monitored. Basic analysis of data directories is provided for perf report mode. Raw dump (-D) and aggregated reports are available for data directories, still with no memory consumption optimizations. However data directories collected with --compression-level option enabled can be analyzed with little less memory because trace files are unmaped from tool process memory after loading collected data. Provided streaming mode is available with Zstd compression/decompression (--compression-level) and handling of external commands (--control). AUX area tracing, related and derived modes like --snapshot or --aux-sample are not enabled. --switch-output, --switch-output-event, --switch-max-files and --timestamp-filename options are not enabled. Threaded trace streaming is not enabled for pipe mode. Asynchronous (--aio) trace streaming and affinity (--affinity) modes are mutually exclusive to threaded streaming mode. See testing results and validation examples below. [1] git clone https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git -b perf/record_threads [2] https://lore.kernel.org/lkml/20180913125450.21342-1-jo...@kernel.org/ --- Alexey Budankov (15): perf session: introduce trace file path to be shown in raw trace dump perf report: output trace file name in raw trace dump perf data: open data directory in read access mode perf session: move reader object definition to header file perf session: introduce decompressor into trace reader object perf session: load data directory into tool process memory perf record: introduce trace file, compressor and stats in mmap object perf record: write trace data into mmap trace files perf record: introduce thread specific objects for trace streaming perf record: manage thread specific data array perf evlist: introduce evlist__ctlfd_update() to update ctl fd status perf record: introduce thread local variable for trace streaming perf record: stop threads in the end of trace streaming perf record: start threads in the beginning of trace streaming perf record: introduce --threads command line option tools/perf/Documentation/perf-record.txt | 7 + tools/perf/builtin-record.c | 514 +-- tools/perf/util/data.c | 4 + tools/perf/util/evlist.c | 16 + tools/perf/util/evlist.h | 1 + tools/perf/util/mmap.c | 6 + tools/perf/util/mmap.h | 5 + tools/perf/util/ordered-events.h | 1 + tools/perf/util/record.h | 1 + tools/perf/util/session.c| 150 --- tools/perf/util/session.h| 28 ++ tools/perf/util/tool.h | 3 +- 12 files changed, 635 insertions(+), 101 deletions(-) --- Testing results: $ perf test 1: vmlinux symtab matches kallsyms : Skip 2: Detect openat syscall event : Ok 3: Detect openat syscall event on all cpus : Ok 4: Read samples using the mmap interface : Ok 5: Test data source output : Ok 6: Parse event definition strings : Ok 7: Simple expression parser: Ok 8: PERF_RECORD_* events & perf_sample fields : Ok 9: Parse perf pmu format : Ok 10: PMU events : 10.1: PMU event table sanity: Ok 10.2: PMU event map aliases : Ok 10.3: Parsing of PMU event table metrics: Skip (some metrics failed) 10.4: Parsing of PMU event table metrics with fake PMUs : Ok 11: DSO data read : Ok 12: DSO data cache : Ok 13: DSO data reopen : FAILED! 14: Roundtrip evsel->name : Ok 15: Parse sched tracepoints fields : Ok 16: syscalls:sys_ent
[PATCH 1/2] mm: mmap: fix fput in error path v2
Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args..."
adds a workaround for a bug in mmap_region.
As the comment states ->mmap() callback can change
vma->vm_file and so we might call fput() on the wrong file.
Revert the workaround and proper fix this in mmap_region.
v2: drop the extra if in dma_buf_mmap as well
Signed-off-by: Christian König
Reviewed-by: Jason Gunthorpe
---
drivers/dma-buf/dma-buf.c | 20 +++-
mm/mmap.c | 2 +-
2 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index a6ba4d598f0e..08630d057cf2 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1143,9 +1143,6 @@ EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
unsigned long pgoff)
{
- struct file *oldfile;
- int ret;
-
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
@@ -1163,22 +1160,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
return -EINVAL;
/* readjust the vma */
- get_file(dmabuf->file);
- oldfile = vma->vm_file;
- vma->vm_file = dmabuf->file;
+ fput(vma->vm_file);
+ vma->vm_file = get_file(dmabuf->file);
vma->vm_pgoff = pgoff;
- ret = dmabuf->ops->mmap(dmabuf, vma);
- if (ret) {
- /* restore old parameters on failure */
- vma->vm_file = oldfile;
- fput(dmabuf->file);
- } else {
- if (oldfile)
- fput(oldfile);
- }
- return ret;
-
+ return dmabuf->ops->mmap(dmabuf, vma);
}
EXPORT_SYMBOL_GPL(dma_buf_mmap);
diff --git a/mm/mmap.c b/mm/mmap.c
index 40248d84ad5f..3a2670d73355 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1852,8 +1852,8 @@ unsigned long mmap_region(struct file *file, unsigned
long addr,
return addr;
unmap_and_free_vma:
+ fput(vma->vm_file);
vma->vm_file = NULL;
- fput(file);
/* Undo any partial mapping done by a device driver. */
unmap_region(mm, vma, prev, vma->vm_start, vma->vm_end);
--
2.17.1
[PATCH 2/2] mm: introduce vma_set_file function v4
Add the new vma_set_file() function to allow changing
vma->vm_file with the necessary refcount dance.
v2: add more users of this.
v3: add missing EXPORT_SYMBOL, rebase on mmap cleanup,
add comments why we drop the reference on two occasions.
v4: make it clear that changing an anonymous vma is illegal.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter (v2)
---
drivers/dma-buf/dma-buf.c | 3 +--
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 4 +---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 +--
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 5 +++--
drivers/gpu/drm/msm/msm_gem.c | 4 +---
drivers/gpu/drm/omapdrm/omap_gem.c | 3 +--
drivers/gpu/drm/vgem/vgem_drv.c| 3 +--
drivers/staging/android/ashmem.c | 6 +++---
include/linux/mm.h | 2 ++
mm/mmap.c | 12
10 files changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 08630d057cf2..8e6a114c6034 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1160,8 +1160,7 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
return -EINVAL;
/* readjust the vma */
- fput(vma->vm_file);
- vma->vm_file = get_file(dmabuf->file);
+ vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
return dmabuf->ops->mmap(dmabuf, vma);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 312e9d58d5a7..10ce267c0947 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -145,10 +145,8 @@ static int etnaviv_gem_mmap_obj(struct etnaviv_gem_object
*etnaviv_obj,
* address_space (so unmap_mapping_range does what we want,
* in particular in the case of mmap'd dmabufs)
*/
- fput(vma->vm_file);
- get_file(etnaviv_obj->base.filp);
vma->vm_pgoff = 0;
- vma->vm_file = etnaviv_obj->base.filp;
+ vma_set_file(vma, etnaviv_obj->base.filp);
vma->vm_page_prot = vm_page_prot;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index fec0e1e3dc3e..8ce4c9e28b87 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -119,8 +119,7 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf,
struct vm_area_struct *
if (ret)
return ret;
- fput(vma->vm_file);
- vma->vm_file = get_file(obj->base.filp);
+ vma_set_file(vma, obj->base.filp);
return 0;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 3d69e51f3e4d..ec28a6cde49b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -893,8 +893,9 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
* requires avoiding extraneous references to their filp, hence why
* we prefer to use an anonymous file for their mmaps.
*/
- fput(vma->vm_file);
- vma->vm_file = anon;
+ vma_set_file(vma, anon);
+ /* Drop the initial creation reference, the vma is now holding one. */
+ fput(anon);
switch (mmo->mmap_type) {
case I915_MMAP_TYPE_WC:
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index de915ff6f4b4..a71f42870d5e 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -223,10 +223,8 @@ int msm_gem_mmap_obj(struct drm_gem_object *obj,
* address_space (so unmap_mapping_range does what we want,
* in particular in the case of mmap'd dmabufs)
*/
- fput(vma->vm_file);
- get_file(obj->filp);
vma->vm_pgoff = 0;
- vma->vm_file = obj->filp;
+ vma_set_file(vma, obj->filp);
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
}
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 979d53a93c2b..0d4542ff1d7d 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -564,9 +564,8 @@ int omap_gem_mmap_obj(struct drm_gem_object *obj,
* address_space (so unmap_mapping_range does what we want,
* in particular in the case of mmap'd dmabufs)
*/
- fput(vma->vm_file);
vma->vm_pgoff = 0;
- vma->vm_file = get_file(obj->filp);
+ vma_set_file(vma, obj->filp);
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
}
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index
