Periodic locking IO is causing server to stop responding
Hi All, We have run into a slight mishap here on one of our servers, which I am hoping you could help narrow down to a cause. One of our servers locks up every so often, seemingly because of a disk IO lockup. Symptoms include high load average (106) stemming from the processor waiting around 97-99% for the disk. When this occurs any new ssh sessions is met with a connection timeout. Kernel version: 5.10.24-uls #1 SMP Fri Mar 19 11:31:52 SAST 2021 x86_64 Intel(R) Xeon(R) CPU E5-2603 v3 @ 1.60GHz GenuineIntel GNU/Linux The following log entries appeared in dmesg around the time the last lock up started occurring. [Tue Mar 23 06:09:32 2021] scsi target0:0:8: handle(0x0012), sas_address(0x500304800175f088), phy(8) [Tue Mar 23 06:09:32 2021] scsi target0:0:8: enclosure logical id(0x500304800175f0bf), slot(8) [Tue Mar 23 06:09:32 2021] sd 0:0:8:0: No reference found at driver, assuming scmd(0x29a7ef73) might have completed [Tue Mar 23 06:09:32 2021] sd 0:0:8:0: task abort: SUCCESS scmd(0x29a7ef73) [Tue Mar 23 06:09:32 2021] sd 0:0:8:0: attempting task abort!scmd(0xde97f273), outstanding for 184620 ms & timeout 18 ms [Tue Mar 23 06:09:32 2021] sd 0:0:8:0: [sdi] tag#1993 CDB: Write(16) 8a 00 00 00 00 00 34 d5 2c 00 00 00 04 00 00 00 [Tue Mar 23 06:09:32 2021] scsi target0:0:8: handle(0x0012), sas_address(0x500304800175f088), phy(8) [Tue Mar 23 06:09:32 2021] scsi target0:0:8: enclosure logical id(0x500304800175f0bf), slot(8) [Tue Mar 23 06:09:32 2021] sd 0:0:8:0: No reference found at driver, assuming scmd(0xde97f273) might have completed [Tue Mar 23 06:09:32 2021] sd 0:0:8:0: task abort: SUCCESS scmd(0xde97f273) [Tue Mar 23 06:09:32 2021] sd 0:0:8:0: attempting task abort!scmd(0xe4cfbc75), outstanding for 184600 ms & timeout 18 ms [Tue Mar 23 06:09:32 2021] sd 0:0:8:0: [sdi] tag#1987 CDB: Write(16) 8a 00 00 00 00 00 34 d5 96 a8 00 00 01 58 00 00 [Tue Mar 23 06:09:32 2021] scsi target0:0:8: handle(0x0012), sas_address(0x500304800175f088), phy(8) [Tue Mar 23 06:09:32 2021] scsi target0:0:8: enclosure logical id(0x500304800175f0bf), slot(8) [Tue Mar 23 06:09:32 2021] sd 0:0:8:0: No reference found at driver, assuming scmd(0xe4cfbc75) might have completed [Tue Mar 23 06:09:32 2021] sd 0:0:8:0: task abort: SUCCESS scmd(0xe4cfbc75) [Tue Mar 23 06:09:32 2021] sd 0:0:8:0: attempting task abort!scmd(0x2282f27d), outstanding for 184620 ms & timeout 18 ms [Tue Mar 23 06:09:32 2021] sd 0:0:8:0: [sdi] tag#1986 CDB: Write(16) 8a 00 00 00 00 00 34 d5 3c 00 00 00 04 00 00 00 [Tue Mar 23 06:09:32 2021] scsi target0:0:8: handle(0x0012), sas_address(0x500304800175f088), phy(8) [Tue Mar 23 06:09:32 2021] scsi target0:0:8: enclosure logical id(0x500304800175f0bf), slot(8) [Tue Mar 23 06:09:32 2021] sd 0:0:8:0: No reference found at driver, assuming scmd(0x2282f27d) might have completed [Tue Mar 23 06:09:32 2021] sd 0:0:8:0: task abort: SUCCESS scmd(0x2282f27d) [Tue Mar 23 06:09:32 2021] sd 0:0:8:0: device_unblock and setting to running, handle(0x0012) [Tue Mar 23 06:09:33 2021] sd 0:0:8:0: Power-on or device reset occurred We are running a bank of drives on software raid, all on controller *-storage description: Serial Attached SCSI controller product: SAS3008 PCI-Express Fusion-MPT SAS-3 vendor: Broadcom / LSI physical id: 0 bus info: pci@:01:00.0 logical name: scsi0 version: 02 width: 64 bits clock: 33MHz capabilities: storage pm pciexpress vpd msi msix bus_master cap_list rom configuration: driver=mpt3sas latency=0 resources: irq:24 ioport:e000(size=256) memory:fb20-fb20 memory:fb10-fb1f So far we have not seen this on any of other servers on the same kernel version. Please let me know if I can provide anymore information, we have since restarted the server. Kind regards Ian Coetzee
[PATCH v3 02/27] perf jevents: Support unit value "cpu_core" and "cpu_atom"
For some Intel platforms, such as Alderlake, which is a hybrid platform
and it consists of atom cpu and core cpu. Each cpu has dedicated event
list. Part of events are available on core cpu, part of events are
available on atom cpu.
The kernel exports new cpu pmus: cpu_core and cpu_atom. The event in
json is added with a new field "Unit" to indicate which pmu the event
is available on.
For example, one event in cache.json,
{
"BriefDescription": "Counts the number of load ops retired that",
"CollectPEBSRecord": "2",
"Counter": "0,1,2,3",
"EventCode": "0xd2",
"EventName": "MEM_LOAD_UOPS_RETIRED_MISC.MMIO",
"PEBScounters": "0,1,2,3",
"SampleAfterValue": "103",
"UMask": "0x80",
"Unit": "cpu_atom"
},
The unit "cpu_atom" indicates this event is only availabe on "cpu_atom".
In generated pmu-events.c, we can see:
{
.name = "mem_load_uops_retired_misc.mmio",
.event = "period=103,umask=0x80,event=0xd2",
.desc = "Counts the number of load ops retired that. Unit: cpu_atom ",
.topic = "cache",
.pmu = "cpu_atom",
},
But if without this patch, the "uncore_" prefix is added before "cpu_atom",
such as:
.pmu = "uncore_cpu_atom"
That would be a wrong pmu.
Signed-off-by: Jin Yao
---
v3:
- No change.
tools/perf/pmu-events/jevents.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index 33aa3c885eaf..ed4f0bd72e5a 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -285,6 +285,8 @@ static struct map {
{ "imx8_ddr", "imx8_ddr" },
{ "L3PMC", "amd_l3" },
{ "DFPMC", "amd_df" },
+ { "cpu_core", "cpu_core" },
+ { "cpu_atom", "cpu_atom" },
{}
};
--
2.17.1
[PATCH v3 03/27] perf pmu: Simplify arguments of __perf_pmu__new_alias
Simplify the arguments of __perf_pmu__new_alias() by passing
the whole 'struct pme_event' pointer.
Signed-off-by: Jin Yao
---
v3:
- No change.
tools/perf/util/pmu.c | 36
1 file changed, 16 insertions(+), 20 deletions(-)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 88da5cf6aee8..9ed9a6a8b2d2 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -306,18 +306,25 @@ static bool perf_pmu_merge_alias(struct perf_pmu_alias
*newalias,
}
static int __perf_pmu__new_alias(struct list_head *list, char *dir, char *name,
-char *desc, char *val,
-char *long_desc, char *topic,
-char *unit, char *perpkg,
-char *metric_expr,
-char *metric_name,
-char *deprecated)
+char *desc, char *val, struct pmu_event *pe)
{
struct parse_events_term *term;
struct perf_pmu_alias *alias;
int ret;
int num;
char newval[256];
+ char *long_desc = NULL, *topic = NULL, *unit = NULL, *perpkg = NULL,
+*metric_expr = NULL, *metric_name = NULL, *deprecated = NULL;
+
+ if (pe) {
+ long_desc = (char *)pe->long_desc;
+ topic = (char *)pe->topic;
+ unit = (char *)pe->unit;
+ perpkg = (char *)pe->perpkg;
+ metric_expr = (char *)pe->metric_expr;
+ metric_name = (char *)pe->metric_name;
+ deprecated = (char *)pe->deprecated;
+ }
alias = malloc(sizeof(*alias));
if (!alias)
@@ -406,8 +413,7 @@ static int perf_pmu__new_alias(struct list_head *list, char
*dir, char *name, FI
/* Remove trailing newline from sysfs file */
strim(buf);
- return __perf_pmu__new_alias(list, dir, name, NULL, buf, NULL, NULL,
NULL,
-NULL, NULL, NULL, NULL);
+ return __perf_pmu__new_alias(list, dir, name, NULL, buf, NULL);
}
static inline bool pmu_alias_info_file(char *name)
@@ -793,11 +799,7 @@ void pmu_add_cpu_aliases_map(struct list_head *head,
struct perf_pmu *pmu,
/* need type casts to override 'const' */
__perf_pmu__new_alias(head, NULL, (char *)pe->name,
(char *)pe->desc, (char *)pe->event,
- (char *)pe->long_desc, (char *)pe->topic,
- (char *)pe->unit, (char *)pe->perpkg,
- (char *)pe->metric_expr,
- (char *)pe->metric_name,
- (char *)pe->deprecated);
+ pe);
}
}
@@ -864,13 +866,7 @@ static int pmu_add_sys_aliases_iter_fn(struct pmu_event
*pe, void *data)
(char *)pe->name,
(char *)pe->desc,
(char *)pe->event,
- (char *)pe->long_desc,
- (char *)pe->topic,
- (char *)pe->unit,
- (char *)pe->perpkg,
- (char *)pe->metric_expr,
- (char *)pe->metric_name,
- (char *)pe->deprecated);
+ pe);
}
return 0;
--
2.17.1
[PATCH v3 01/27] tools headers uapi: Update tools's copy of linux/perf_event.h
To get the changes in:
Liang Kan's patch
("perf: Introduce PERF_TYPE_HARDWARE_PMU and PERF_TYPE_HW_CACHE_PMU")
Kan's patch is in review at the moment, but the following perf tool
patches need this interface for hybrid support.
This patch can be removed after Kan's patch is upstreamed.
Signed-off-by: Jin Yao
---
v3:
- No change.
tools/include/uapi/linux/perf_event.h | 26 ++
1 file changed, 26 insertions(+)
diff --git a/tools/include/uapi/linux/perf_event.h
b/tools/include/uapi/linux/perf_event.h
index ad15e40d7f5d..c0a511eea498 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -33,6 +33,8 @@ enum perf_type_id {
PERF_TYPE_HW_CACHE = 3,
PERF_TYPE_RAW = 4,
PERF_TYPE_BREAKPOINT= 5,
+ PERF_TYPE_HARDWARE_PMU = 6,
+ PERF_TYPE_HW_CACHE_PMU = 7,
PERF_TYPE_MAX, /* non-ABI */
};
@@ -94,6 +96,30 @@ enum perf_hw_cache_op_result_id {
PERF_COUNT_HW_CACHE_RESULT_MAX, /* non-ABI */
};
+/*
+ * attr.config layout for type PERF_TYPE_HARDWARE* and PERF_TYPE_HW_CACHE*
+ * PERF_TYPE_HARDWARE: 0xAA
+ * AA: hardware event ID
+ * PERF_TYPE_HW_CACHE: 0xCCBBAA
+ * AA: hardware cache ID
+ * BB: hardware cache op ID
+ * CC: hardware cache op result ID
+ * PERF_TYPE_HARDWARE_PMU: 0xDD00AA
+ * AA: hardware event ID
+ * DD: PMU type ID
+ * PERF_TYPE_HW_CACHE_PMU: 0xDD00CCBBAA
+ * AA: hardware cache ID
+ * BB: hardware cache op ID
+ * CC: hardware cache op result ID
+ * DD: PMU type ID
+ */
+#define PERF_HW_CACHE_ID_SHIFT 0
+#define PERF_HW_CACHE_OP_ID_SHIFT 8
+#define PERF_HW_CACHE_OP_RESULT_ID_SHIFT 16
+#define PERF_HW_CACHE_EVENT_MASK 0xff
+
+#define PERF_PMU_TYPE_SHIFT32
+
/*
* Special "software" events provided by the kernel, even if the hardware
* does not support performance events. These events measure various
--
2.17.1
[PATCH v3 00/27] perf tool: AlderLake hybrid support series 1
AlderLake uses a hybrid architecture utilizing Golden Cove cores
(core cpu) and Gracemont cores (atom cpu). Each cpu has dedicated
event list. Some events are available on core cpu, some events
are available on atom cpu and some events can be available on both.
Kernel exports new pmus "cpu_core" and "cpu_atom" through sysfs:
/sys/devices/cpu_core
/sys/devices/cpu_atom
cat /sys/devices/cpu_core/cpus
0-15
cat /sys/devices/cpu_atom/cpus
16-23
In this example, core cpus are 0-15 and atom cpus are 16-23.
To enable a core only event or atom only event:
cpu_core//
or
cpu_atom//
Count the 'cycles' event on core cpus.
# perf stat -e cpu_core/cycles/ -a -- sleep 1
Performance counter stats for 'system wide':
12,853,951,349 cpu_core/cycles/
1.002581249 seconds time elapsed
If one event is available on both atom cpu and core cpu, two events
are created automatically.
# perf stat -e cycles -a -- sleep 1
Performance counter stats for 'system wide':
12,856,467,438 cpu_core/cycles/
6,404,634,785 cpu_atom/cycles/
1.002453013 seconds time elapsed
Group is supported if the events are from same pmu, otherwise a warning
is displayed and disable grouping automatically.
# perf stat -e '{cpu_core/cycles/,cpu_core/instructions/}' -a -- sleep 1
Performance counter stats for 'system wide':
12,863,866,968 cpu_core/cycles/
554,795,017 cpu_core/instructions/
1.002616117 seconds time elapsed
# perf stat -e '{cpu_core/cycles/,cpu_atom/instructions/}' -a -- sleep 1
WARNING: events in group from different hybrid PMUs!
WARNING: grouped events cpus do not match, disabling group:
anon group { cpu_core/cycles/, cpu_atom/instructions/ }
Performance counter stats for 'system wide':
6,283,970 cpu_core/cycles/
765,635 cpu_atom/instructions/
1.003959036 seconds time elapsed
Note that, since the whole patchset for AlderLake hybrid support is very
large (40+ patches). For simplicity, it's splitted into several patch
series.
The patch series 1 only supports the basic functionality. The advanced
supports for perf-c2c/perf-mem/topdown/metrics/topology header and others
will be added in follow-up patch series.
The perf tool codes can also be found at:
https://github.com/yaoj/perf.git
v3:
---
- Drop 'perf evlist: Hybrid event uses its own cpus'. This patch is wide
and actually it's not very necessary. The current perf framework has
processed the cpus for evsel well even for hybrid evsel. So this patch can
be dropped.
- Drop 'perf evsel: Adjust hybrid event and global event mixed group'.
The patch is a bit tricky and hard to understand. In v3, we will disable
grouping when the group members are from different PMUs. So this patch
would be not necessary.
- Create parse-events-hybrid.c/parse-events-hybrid.h and
evlist-hybrid.c/evlist-hybrid.h.
Move hybrid related codes to these files.
- Create a new patch 'perf pmu: Support 'cycles' and 'branches' inside hybrid
PMU' to
support 'cycles' and 'branches' inside PMU.
- Create a new patch 'perf record: Uniquify hybrid event name' to tell user the
pmu which the event belongs to for perf-record.
- If group members are from different hybrid PMUs, shows warning and disable
grouping.
- Other refining and refactoring.
v2:
---
- Drop kernel patches (Kan posted the series "Add Alder Lake support for perf
(kernel)" separately).
- Drop the patches for perf-c2c/perf-mem/topdown/metrics/topology header
supports,
which will be added in series 2 or series 3.
- Simplify the arguments of __perf_pmu__new_alias() by passing
the 'struct pme_event' pointer.
- Check sysfs validity before access.
- Use pmu style event name, such as "cpu_core/cycles/".
- Move command output two chars to the right.
- Move pmu hybrid functions to new created pmu-hybrid.c/pmu-hybrid.h.
This is to pass the perf test python case.
Jin Yao (27):
tools headers uapi: Update tools's copy of linux/perf_event.h
perf jevents: Support unit value "cpu_core" and "cpu_atom"
perf pmu: Simplify arguments of __perf_pmu__new_alias
perf pmu: Save pmu name
perf pmu: Save detected hybrid pmus to a global pmu list
perf pmu: Add hybrid helper functions
perf stat: Uniquify hybrid event name
perf parse-events: Create two hybrid hardware events
perf parse-events: Create two hybrid cache events
perf parse-events: Create two hybrid raw events
perf pmu: Support 'cycles' and 'branches' inside hybrid PMU
perf parse-events: Support no alias assigned event inside hybrid PMU
perf record: Create two hybrid 'cycles' events by default
perf stat: Add default hybrid events
perf stat: Filter out unmatched aggregation for hybrid event
perf stat: Warn group events from different hybrid PMU
perf script: Support PERF_TYPE_HARDWARE_PMU and PERF_TYPE_HW_CACHE_PMU
perf record: Uniquify hybrid event name
perf tests: Add hybrid case
[PATCH v3 04/27] perf pmu: Save pmu name
On hybrid platform, one event is available on one pmu
(such as, available on cpu_core or on cpu_atom).
This patch saves the pmu name to the pmu field of struct perf_pmu_alias.
Then next we can know the pmu which the event can be enabled on.
Signed-off-by: Jin Yao
---
v3:
- Change pmu to pmu_name in struct perf_pmu_alias.
tools/perf/util/pmu.c | 10 +-
tools/perf/util/pmu.h | 1 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 9ed9a6a8b2d2..10709ec1cc3e 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -283,6 +283,7 @@ void perf_pmu_free_alias(struct perf_pmu_alias *newalias)
zfree(&newalias->str);
zfree(&newalias->metric_expr);
zfree(&newalias->metric_name);
+ zfree(&newalias->pmu_name);
parse_events_terms__purge(&newalias->terms);
free(newalias);
}
@@ -297,6 +298,10 @@ static bool perf_pmu_merge_alias(struct perf_pmu_alias
*newalias,
list_for_each_entry(a, alist, list) {
if (!strcasecmp(newalias->name, a->name)) {
+ if (newalias->pmu_name && a->pmu_name &&
+ !strcasecmp(newalias->pmu_name, a->pmu_name)) {
+ continue;
+ }
perf_pmu_update_alias(a, newalias);
perf_pmu_free_alias(newalias);
return true;
@@ -314,7 +319,8 @@ static int __perf_pmu__new_alias(struct list_head *list,
char *dir, char *name,
int num;
char newval[256];
char *long_desc = NULL, *topic = NULL, *unit = NULL, *perpkg = NULL,
-*metric_expr = NULL, *metric_name = NULL, *deprecated = NULL;
+*metric_expr = NULL, *metric_name = NULL, *deprecated = NULL,
+*pmu_name = NULL;
if (pe) {
long_desc = (char *)pe->long_desc;
@@ -324,6 +330,7 @@ static int __perf_pmu__new_alias(struct list_head *list,
char *dir, char *name,
metric_expr = (char *)pe->metric_expr;
metric_name = (char *)pe->metric_name;
deprecated = (char *)pe->deprecated;
+ pmu_name = (char *)pe->pmu;
}
alias = malloc(sizeof(*alias));
@@ -389,6 +396,7 @@ static int __perf_pmu__new_alias(struct list_head *list,
char *dir, char *name,
}
alias->per_pkg = perpkg && sscanf(perpkg, "%d", &num) == 1 && num == 1;
alias->str = strdup(newval);
+ alias->pmu_name = pmu_name ? strdup(pmu_name) : NULL;
if (deprecated)
alias->deprecated = true;
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index 8164388478c6..8493b1719e10 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -72,6 +72,7 @@ struct perf_pmu_alias {
bool deprecated;
char *metric_expr;
char *metric_name;
+ char *pmu_name;
};
struct perf_pmu *perf_pmu__find(const char *name);
--
2.17.1
[PATCH v3 05/27] perf pmu: Save detected hybrid pmus to a global pmu list
We identify the cpu_core pmu and cpu_atom pmu by explicitly
checking following files:
For cpu_core, checks:
"/sys/bus/event_source/devices/cpu_core/cpus"
For cpu_atom, checks:
"/sys/bus/event_source/devices/cpu_atom/cpus"
If the 'cpus' file exists, the pmu exists.
But in order not to hardcode the "cpu_core" and "cpu_atom",
and make the code in a generic way. So if the path
"/sys/bus/event_source/devices/cpu_xxx/cpus" exists, the hybrid
pmu exists. All the detected hybrid pmus are linked to a
global list 'perf_pmu__hybrid_pmus' and then next we just need
to iterate the list to get all hybrid pmu by using
perf_pmu__for_each_hybrid_pmu.
Signed-off-by: Jin Yao
---
v3:
- No functional change.
tools/perf/util/Build| 1 +
tools/perf/util/pmu-hybrid.c | 35 +++
tools/perf/util/pmu-hybrid.h | 18 ++
tools/perf/util/pmu.c| 9 -
tools/perf/util/pmu.h| 4
5 files changed, 66 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/util/pmu-hybrid.c
create mode 100644 tools/perf/util/pmu-hybrid.h
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index e3e12f9d4733..37a8a63c7195 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -69,6 +69,7 @@ perf-y += parse-events-bison.o
perf-y += pmu.o
perf-y += pmu-flex.o
perf-y += pmu-bison.o
+perf-y += pmu-hybrid.o
perf-y += trace-event-read.o
perf-y += trace-event-info.o
perf-y += trace-event-scripting.o
diff --git a/tools/perf/util/pmu-hybrid.c b/tools/perf/util/pmu-hybrid.c
new file mode 100644
index ..7316bf46e54b
--- /dev/null
+++ b/tools/perf/util/pmu-hybrid.c
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "fncache.h"
+#include "pmu-hybrid.h"
+
+LIST_HEAD(perf_pmu__hybrid_pmus);
+
+bool perf_pmu__hybrid_mounted(const char *name)
+{
+ char path[PATH_MAX];
+ const char *sysfs;
+
+ if (strncmp(name, "cpu_", 4))
+ return false;
+
+ sysfs = sysfs__mountpoint();
+ if (!sysfs)
+ return false;
+
+ snprintf(path, PATH_MAX, CPUS_TEMPLATE_CPU, sysfs, name);
+ return file_available(path);
+}
diff --git a/tools/perf/util/pmu-hybrid.h b/tools/perf/util/pmu-hybrid.h
new file mode 100644
index ..35bed3714438
--- /dev/null
+++ b/tools/perf/util/pmu-hybrid.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __PMU_HYBRID_H
+#define __PMU_HYBRID_H
+
+#include
+#include
+#include
+#include
+#include "pmu.h"
+
+extern struct list_head perf_pmu__hybrid_pmus;
+
+#define perf_pmu__for_each_hybrid_pmu(pmu) \
+ list_for_each_entry(pmu, &perf_pmu__hybrid_pmus, hybrid_list)
+
+bool perf_pmu__hybrid_mounted(const char *name);
+
+#endif /* __PMU_HYBRID_H */
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 10709ec1cc3e..35e9660c3904 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -25,6 +25,7 @@
#include "string2.h"
#include "strbuf.h"
#include "fncache.h"
+#include "pmu-hybrid.h"
struct perf_pmu perf_pmu__fake;
@@ -613,7 +614,6 @@ static struct perf_cpu_map *__pmu_cpumask(const char *path)
*/
#define SYS_TEMPLATE_ID"./bus/event_source/devices/%s/identifier"
#define CPUS_TEMPLATE_UNCORE "%s/bus/event_source/devices/%s/cpumask"
-#define CPUS_TEMPLATE_CPU "%s/bus/event_source/devices/%s/cpus"
static struct perf_cpu_map *pmu_cpumask(const char *name)
{
@@ -645,6 +645,9 @@ static bool pmu_is_uncore(const char *name)
char path[PATH_MAX];
const char *sysfs;
+ if (perf_pmu__hybrid_mounted(name))
+ return false;
+
sysfs = sysfs__mountpoint();
snprintf(path, PATH_MAX, CPUS_TEMPLATE_UNCORE, sysfs, name);
return file_available(path);
@@ -946,6 +949,7 @@ static struct perf_pmu *pmu_lookup(const char *name)
pmu->is_uncore = pmu_is_uncore(name);
if (pmu->is_uncore)
pmu->id = pmu_id(name);
+ pmu->is_hybrid = perf_pmu__hybrid_mounted(name);
pmu->max_precise = pmu_max_precise(name);
pmu_add_cpu_aliases(&aliases, pmu);
pmu_add_sys_aliases(&aliases, pmu);
@@ -957,6 +961,9 @@ static struct perf_pmu *pmu_lookup(const char *name)
list_splice(&aliases, &pmu->aliases);
list_add_tail(&pmu->list, &pmus);
+ if (pmu->is_hybrid)
+ list_add_tail(&pmu->hybrid_list, &perf_pmu__hybrid_pmus);
+
pmu->default_config = perf_pmu__get_default_config(pmu);
return pmu;
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index 8493b1719e10..29289e7c2649 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include "parse-events.h"
#include "pmu-events/pmu-events.h"
@@ -19,6 +20,7 @@ enum {
#define
[PATCH v3 06/27] perf pmu: Add hybrid helper functions
The functions perf_pmu__is_hybrid and perf_pmu__find_hybrid_pmu
can be used to identify the hybrid platform and return the found
hybrid cpu pmu. All the detected hybrid pmus have been saved in
'perf_pmu__hybrid_pmus' list. So we just need to search this list.
perf_pmu__hybrid_type_to_pmu converts the user specified string
to hybrid pmu name. This is used to support the '--cputype' option
in next patches.
perf_pmu__has_hybrid checks the existing of hybrid pmu. Note that,
we have to define it in pmu.c (try to make pmu-hybrid.c no more
symbol dependency), otherwise perf test python would be failed.
Signed-off-by: Jin Yao
---
v3:
- Move perf_pmu__has_hybrid from pmu-hybrid.c to pmu.c. We have to
add pmu-hybrid.c to python-ext-sources to solve symbol dependency
issue found in perf test python. For perf_pmu__has_hybrid, it calls
perf_pmu__scan, which is defined in pmu.c. It's very hard to add
pmu.c to python-ext-sources, too much symbol dependency here.
tools/perf/util/pmu-hybrid.c | 40
tools/perf/util/pmu-hybrid.h | 4
tools/perf/util/pmu.c| 11 ++
tools/perf/util/pmu.h| 2 ++
4 files changed, 57 insertions(+)
diff --git a/tools/perf/util/pmu-hybrid.c b/tools/perf/util/pmu-hybrid.c
index 7316bf46e54b..86ba84d9469c 100644
--- a/tools/perf/util/pmu-hybrid.c
+++ b/tools/perf/util/pmu-hybrid.c
@@ -33,3 +33,43 @@ bool perf_pmu__hybrid_mounted(const char *name)
snprintf(path, PATH_MAX, CPUS_TEMPLATE_CPU, sysfs, name);
return file_available(path);
}
+
+struct perf_pmu *perf_pmu__find_hybrid_pmu(const char *name)
+{
+ struct perf_pmu *pmu;
+
+ if (!name)
+ return NULL;
+
+ perf_pmu__for_each_hybrid_pmu(pmu) {
+ if (!strcmp(name, pmu->name))
+ return pmu;
+ }
+
+ return NULL;
+}
+
+bool perf_pmu__is_hybrid(const char *name)
+{
+ return perf_pmu__find_hybrid_pmu(name) != NULL;
+}
+
+char *perf_pmu__hybrid_type_to_pmu(const char *type)
+{
+ char *pmu_name = NULL;
+
+ if (asprintf(&pmu_name, "cpu_%s", type) < 0)
+ return NULL;
+
+ if (perf_pmu__is_hybrid(pmu_name))
+ return pmu_name;
+
+ /*
+* pmu may be not scanned, check the sysfs.
+*/
+ if (perf_pmu__hybrid_mounted(pmu_name))
+ return pmu_name;
+
+ free(pmu_name);
+ return NULL;
+}
diff --git a/tools/perf/util/pmu-hybrid.h b/tools/perf/util/pmu-hybrid.h
index 35bed3714438..d0fa7bc50a76 100644
--- a/tools/perf/util/pmu-hybrid.h
+++ b/tools/perf/util/pmu-hybrid.h
@@ -15,4 +15,8 @@ extern struct list_head perf_pmu__hybrid_pmus;
bool perf_pmu__hybrid_mounted(const char *name);
+struct perf_pmu *perf_pmu__find_hybrid_pmu(const char *name);
+bool perf_pmu__is_hybrid(const char *name);
+char *perf_pmu__hybrid_type_to_pmu(const char *type);
+
#endif /* __PMU_HYBRID_H */
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 35e9660c3904..beff29981101 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -40,6 +40,7 @@ int perf_pmu_parse(struct list_head *list, char *name);
extern FILE *perf_pmu_in;
static LIST_HEAD(pmus);
+static bool hybrid_scanned;
/*
* Parse & process all the sysfs attributes located under
@@ -1823,3 +1824,13 @@ int perf_pmu__caps_parse(struct perf_pmu *pmu)
return nr_caps;
}
+
+bool perf_pmu__has_hybrid(void)
+{
+ if (!hybrid_scanned) {
+ hybrid_scanned = true;
+ perf_pmu__scan(NULL);
+ }
+
+ return !list_empty(&perf_pmu__hybrid_pmus);
+}
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index 29289e7c2649..5ed2abab7fe0 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -128,4 +128,6 @@ int perf_pmu__convert_scale(const char *scale, char **end,
double *sval);
int perf_pmu__caps_parse(struct perf_pmu *pmu);
+bool perf_pmu__has_hybrid(void);
+
#endif /* __PMU_H */
--
2.17.1
[PATCH v3 09/27] perf parse-events: Create two hybrid cache events
For cache events, they have pre-defined configs. The kernel needs to know where the cache event comes from (e.g. from cpu_core pmu or from cpu_atom pmu). But the perf type 'PERF_TYPE_HW_CACHE' can't carry pmu information. So the kernel introduces a new type 'PERF_TYPE_HW_CACHE_PMU'. The new attr.config layout for PERF_TYPE_HW_CACHE_PMU is 0xDD00CCBBAA AA: hardware cache ID BB: hardware cache op ID CC: hardware cache op result ID DD: PMU type ID Similar as hardware event, PMU type ID is retrieved from sysfs. When enabling a hybrid cache event without specified pmu, such as, 'perf stat -e L1-dcache-loads -a', two events are created automatically. One is for atom, the other is for core. # ./perf stat -e L1-dcache-loads -vv -a -- sleep 1 Control descriptor is not initialized perf_event_attr: type 7 size 120 config 0x4 sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 0 group_fd -1 flags 0x8 = 3 perf_event_attr: type 7 size 120 config 0x4 sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 1 group_fd -1 flags 0x8 = 4 .. perf_event_attr: type 7 size 120 config 0x4 sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 15 group_fd -1 flags 0x8 = 19 perf_event_attr: type 7 size 120 config 0xa sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 16 group_fd -1 flags 0x8 = 20 perf_event_attr: type 7 size 120 config 0xa sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 17 group_fd -1 flags 0x8 = 21 .. perf_event_attr: type 7 size 120 config 0xa sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 23 group_fd -1 flags 0x8 = 27 L1-dcache-loads: 0: 12071 1001549888 1001549888 L1-dcache-loads: 1: 12704 1001602818 1001602818 L1-dcache-loads: 2: 21560 1001687258 1001687258 L1-dcache-loads: 3: 8104 1001727825 1001727825 L1-dcache-loads: 4: 7855 1001738995 1001738995 L1-dcache-loads: 5: 7714 1001766241 1001766241 L1-dcache-loads: 6: 7704 1001790333 1001790333 L1-dcache-loads: 7: 58026 1001826950 1001826950 L1-dcache-loads: 8: 107639 1001641286 1001641286 L1-dcache-loads: 9: 67013 1001682357 1001682357 L1-dcache-loads: 10: 17137 1001700068 1001700068 L1-dcache-loads: 11: 86449
[PATCH v3 08/27] perf parse-events: Create two hybrid hardware events
For hardware events, they have pre-defined configs. The kernel needs to know where the event comes from (e.g. from cpu_core pmu or from cpu_atom pmu). But the perf type 'PERF_TYPE_HARDWARE' can't carry pmu information. So the kernel introduces a new type 'PERF_TYPE_HARDWARE_PMU'. The new attr.config layout for PERF_TYPE_HARDWARE_PMU is: 0xDD00AA AA: original hardware event ID DD: PMU type ID PMU type ID is retrieved from sysfs. For example, cat /sys/devices/cpu_atom/type 10 cat /sys/devices/cpu_core/type 4 When enabling a hybrid hardware event without specified pmu, such as, 'perf stat -e cycles -a', two events are created automatically. One is for atom, the other is for core. # ./perf stat -e cycles -a -vv -- sleep 1 Control descriptor is not initialized perf_event_attr: type 6 size 120 config 0x4 sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 0 group_fd -1 flags 0x8 = 3 perf_event_attr: type 6 size 120 config 0x4 sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 1 group_fd -1 flags 0x8 = 4 .. perf_event_attr: type 6 size 120 config 0x4 sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 15 group_fd -1 flags 0x8 = 19 perf_event_attr: type 6 size 120 config 0xa sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 16 group_fd -1 flags 0x8 = 20 perf_event_attr: type 6 size 120 config 0xa sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 17 group_fd -1 flags 0x8 = 21 .. perf_event_attr: type 6 size 120 config 0xa sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 22 group_fd -1 flags 0x8 = 26 perf_event_attr: type 6 size 120 config 0xa sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 23 group_fd -1 flags 0x8 = 27
[PATCH v3 07/27] perf stat: Uniquify hybrid event name
It would be useful to tell user the pmu which the event belongs to.
perf-stat has supported '--no-merge' option and it can print the pmu
name after the event name, such as:
"cycles [cpu_core]"
Now this option is enabled by default for hybrid platform but change
the format to:
"cpu_core/cycles/"
Signed-off-by: Jin Yao
---
v3:
- No functional change.
tools/perf/builtin-stat.c | 4
tools/perf/util/stat-display.c | 13 +++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 4bb48c6b6698..7b2dfe21c5a8 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -68,6 +68,7 @@
#include "util/affinity.h"
#include "util/pfm.h"
#include "util/bpf_counter.h"
+#include "util/pmu-hybrid.h"
#include "asm/bug.h"
#include
@@ -2371,6 +2372,9 @@ int cmd_stat(int argc, const char **argv)
evlist__check_cpu_maps(evsel_list);
+ if (perf_pmu__has_hybrid())
+ stat_config.no_merge = true;
+
/*
* Initialize thread_map with comm names,
* so we could print it out on output.
diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c
index 7f09cdaf5b60..161826938a00 100644
--- a/tools/perf/util/stat-display.c
+++ b/tools/perf/util/stat-display.c
@@ -17,6 +17,7 @@
#include "cgroup.h"
#include
#include "util.h"
+#include "pmu-hybrid.h"
#define CNTR_NOT_SUPPORTED ""
#define CNTR_NOT_COUNTED ""
@@ -526,6 +527,7 @@ static void uniquify_event_name(struct evsel *counter)
{
char *new_name;
char *config;
+ int ret;
if (counter->uniquified_name ||
!counter->pmu_name || !strncmp(counter->name, counter->pmu_name,
@@ -540,8 +542,15 @@ static void uniquify_event_name(struct evsel *counter)
counter->name = new_name;
}
} else {
- if (asprintf(&new_name,
-"%s [%s]", counter->name, counter->pmu_name) > 0) {
+ if (perf_pmu__has_hybrid()) {
+ ret = asprintf(&new_name, "%s/%s/",
+ counter->pmu_name, counter->name);
+ } else {
+ ret = asprintf(&new_name, "%s [%s]",
+ counter->name, counter->pmu_name);
+ }
+
+ if (ret) {
free(counter->name);
counter->name = new_name;
}
--
2.17.1
[PATCH v3 11/27] perf pmu: Support 'cycles' and 'branches' inside hybrid PMU
On hybrid platform, user may want to enable the hardware event
only on one PMU. So following syntax is supported:
cpu_core//
cpu_atom//
# perf stat -e cpu_core/cpu-cycles/ -a -- sleep 1
Performance counter stats for 'system wide':
6,049,336 cpu_core/cpu-cycles/
1.003577042 seconds time elapsed
It enables the event 'cpu-cycles' only on cpu_core pmu.
But for 'cycles' and 'branches', the syntax doesn't work.
Before:
# perf stat -e cpu_core/cycles/ -a -- sleep 1
event syntax error: 'cpu_core/cycles/'
\___ unknown term 'cycles' for pmu 'cpu_core'
# perf stat -e cpu_core/branches/ -a -- sleep 1
event syntax error: 'cpu_core/branches/'
\___ unknown term 'branches' for pmu 'cpu_core'
For 'cpu-cycles', why it works is because the event is defined in
/sys/devices/cpu_core/events/. It's added as alias by
pmu_add_sys_aliases and it's treated as 'event' when parsing the
term->config.
We use a similar idea, create a pme_hybrid_fixup table for
'cycles' and 'branches' and add them as aliases.
After:
# perf stat -e cpu_core/cycles/ -a -- sleep 1
Performance counter stats for 'system wide':
5,769,631 cpu_core/cycles/
1.003833235 seconds time elapsed
# perf stat -e cpu_core/branches/ -a -- sleep 1
Performance counter stats for 'system wide':
490,951 cpu_core/branches/
1.003693946 seconds time elapsed
Signed-off-by: Jin Yao
---
v3:
- New patch in v3.
tools/perf/util/pmu.c | 32
1 file changed, 32 insertions(+)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index beff29981101..72e5ae5e868e 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -916,6 +916,35 @@ static int pmu_max_precise(const char *name)
return max_precise;
}
+static void perf_pmu__add_hybrid_aliases(struct list_head *head)
+{
+ static struct pmu_event pme_hybrid_fixup[] = {
+ {
+ .name = "cycles",
+ .event = "event=0x3c",
+ },
+ {
+ .name = "branches",
+ .event = "event=0xc4",
+ },
+ {
+ .name = 0,
+ .event = 0,
+ },
+ };
+ int i = 0;
+
+ while (1) {
+ struct pmu_event *pe = &pme_hybrid_fixup[i++];
+
+ if (!pe->name)
+ break;
+
+ __perf_pmu__new_alias(head, NULL, (char *)pe->name, NULL,
+ (char *)pe->event, NULL);
+ }
+}
+
static struct perf_pmu *pmu_lookup(const char *name)
{
struct perf_pmu *pmu;
@@ -955,6 +984,9 @@ static struct perf_pmu *pmu_lookup(const char *name)
pmu_add_cpu_aliases(&aliases, pmu);
pmu_add_sys_aliases(&aliases, pmu);
+ if (pmu->is_hybrid)
+ perf_pmu__add_hybrid_aliases(&aliases);
+
INIT_LIST_HEAD(&pmu->format);
INIT_LIST_HEAD(&pmu->aliases);
INIT_LIST_HEAD(&pmu->caps);
--
2.17.1
[PATCH v3 12/27] perf parse-events: Support no alias assigned event inside hybrid PMU
On hybrid platform, similar to hardware event, user may want
to enable other events only on one PMU. So following syntax
should be supported:
cpu_core//
cpu_atom//
But the syntax doesn't work for some events, such as cache
event.
Before:
# perf stat -e cpu_core/LLC-loads/ -a -- sleep 1
event syntax error: 'cpu_core/LLC-loads/'
\___ unknown term 'LLC-loads' for pmu 'cpu_core'
Cache events are much more complex than hardware events, so
we can't create aliases for them. We use another solution.
For example, if we use "cpu_core/LLC-loads/", in parse_events_add_pmu(),
term->config is "LLC-loads".
We create a new "parse_events_state" with the pmu_name and use
parse_events__scanner to scan the term->config ("LLC-loads" in
this example). The parse_events_add_cache() would be called during
parsing. The parse_state->pmu_name is used to identify the pmu
where the event should be enabled on.
After:
# ./perf stat -e cpu_core/LLC-loads/ -a -- sleep 1
Performance counter stats for 'system wide':
24,593 cpu_core/LLC-loads/
1.003911601 seconds time elapsed
Signed-off-by: Jin Yao
---
v3:
- Rename the patch:
'perf parse-events: Support hardware events inside PMU' -->
'perf parse-events: Support no alias assigned event inside hybrid PMU'
- Major code is moved to parse-events-hybrid.c.
- Refine the code.
tools/perf/util/parse-events-hybrid.c | 18 +-
tools/perf/util/parse-events-hybrid.h | 3 +-
tools/perf/util/parse-events.c| 80 +--
tools/perf/util/parse-events.h| 4 +-
tools/perf/util/parse-events.y| 9 ++-
tools/perf/util/pmu.c | 4 +-
tools/perf/util/pmu.h | 2 +-
7 files changed, 108 insertions(+), 12 deletions(-)
diff --git a/tools/perf/util/parse-events-hybrid.c
b/tools/perf/util/parse-events-hybrid.c
index 8a630cbab8f3..5bf176b55573 100644
--- a/tools/perf/util/parse-events-hybrid.c
+++ b/tools/perf/util/parse-events-hybrid.c
@@ -64,6 +64,11 @@ static int add_hw_hybrid(struct parse_events_state
*parse_state,
int ret;
perf_pmu__for_each_hybrid_pmu(pmu) {
+ if (parse_state->pmu_name &&
+ strcmp(parse_state->pmu_name, pmu->name)) {
+ continue;
+ }
+
ret = create_event_hybrid(PERF_TYPE_HARDWARE_PMU,
&parse_state->idx, list, attr, name,
config_terms, pmu);
@@ -100,6 +105,11 @@ static int add_raw_hybrid(struct parse_events_state
*parse_state,
int ret;
perf_pmu__for_each_hybrid_pmu(pmu) {
+ if (parse_state->pmu_name &&
+ strcmp(parse_state->pmu_name, pmu->name)) {
+ continue;
+ }
+
ret = create_raw_event_hybrid(&parse_state->idx, list, attr,
name, config_terms, pmu);
if (ret)
@@ -137,7 +147,8 @@ int parse_events__add_numeric_hybrid(struct
parse_events_state *parse_state,
int parse_events__add_cache_hybrid(struct list_head *list, int *idx,
struct perf_event_attr *attr, char *name,
struct list_head *config_terms,
- bool *hybrid)
+ bool *hybrid,
+ struct parse_events_state *parse_state)
{
struct perf_pmu *pmu;
int ret;
@@ -148,6 +159,11 @@ int parse_events__add_cache_hybrid(struct list_head *list,
int *idx,
*hybrid = true;
perf_pmu__for_each_hybrid_pmu(pmu) {
+ if (parse_state->pmu_name &&
+ strcmp(parse_state->pmu_name, pmu->name)) {
+ continue;
+ }
+
ret = create_event_hybrid(PERF_TYPE_HW_CACHE_PMU, idx, list,
attr, name, config_terms, pmu);
if (ret)
diff --git a/tools/perf/util/parse-events-hybrid.h
b/tools/perf/util/parse-events-hybrid.h
index 9ad33cd0cef4..f33bd67aa851 100644
--- a/tools/perf/util/parse-events-hybrid.h
+++ b/tools/perf/util/parse-events-hybrid.h
@@ -17,6 +17,7 @@ int parse_events__add_numeric_hybrid(struct
parse_events_state *parse_state,
int parse_events__add_cache_hybrid(struct list_head *list, int *idx,
struct perf_event_attr *attr, char *name,
struct list_head *config_terms,
- bool *hybrid);
+ bool *hybrid,
+ struct parse_events_state *parse_state);
#endif /* __PERF_PARSE_EVENTS_HYBRID_H */
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 3692fa3c964a..020c785be742 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/uti
[PATCH v3 10/27] perf parse-events: Create two hybrid raw events
On hybrid platform, same raw event is possible to be available on both cpu_core pmu and cpu_atom pmu. So it's supported to create two raw events for one event encoding. # ./perf stat -e r3c -a -vv -- sleep 1 Control descriptor is not initialized perf_event_attr: type 4 size 120 config 0x3c sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 0 group_fd -1 flags 0x8 = 3 perf_event_attr: type 4 size 120 config 0x3c sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 1 group_fd -1 flags 0x8 = 4 ... perf_event_attr: type 4 size 120 config 0x3c sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 15 group_fd -1 flags 0x8 = 19 perf_event_attr: type 10 size 120 config 0x3c sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 16 group_fd -1 flags 0x8 = 20 perf_event_attr: type 10 size 120 config 0x3c sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 17 group_fd -1 flags 0x8 = 21 ... perf_event_attr: type 10 size 120 config 0x3c sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest1 sys_perf_event_open: pid -1 cpu 23 group_fd -1 flags 0x8 = 27 r3c: 0: 295983 1001500321 1001500321 r3c: 1: 66453 1001536385 1001536385 r3c: 2: 156191 1001559687 1001559687 r3c: 3: 177709 1001590937 1001590937 r3c: 4: 110819 1001674167 1001674167 r3c: 5: 368516 1001693927 1001693927 r3c: 6: 185745 1001782896 1001782896 r3c: 7: 735332 1001567982 1001567982 r3c: 8: 1783115 1001595406 1001595406 r3c: 9: 90088 1001606000 1001606000 r3c: 10: 409253 1001697624 1001697624 r3c: 11: 2942563 1001721371 1001721371 r3c: 12: 100495 1001740753 1001740753 r3c: 13: 62970 1001769269 1001769269 r3c: 14: 201978 1001799810 1001799810 r3c: 15: 1401633 1001829314 1001829314 r3c: 0: 328088 1001962968 1001962968 r3c: 1: 257037 1001990202 1001990202 r3c: 2: 168703 1002065267 1002065267 r3c: 3: 187959 1002115120 1002115120 r3c: 4: 126987 1002151672 1002151672 r3c: 5: 79831 1002202614 1002202614 r3c: 6: 72101 1002214094 1002214094 r3c: 7: 442006 1002248710 1002248710 r3c: 9088843 16026665849 16026665849 r3c: 1662712 8016950647 8016950647 Performance counter stats for 'system wide': 9,088,843 cpu_core/r3c/ 1,662,712 cpu_atom/r3c/ 1.00372
[PATCH v3 13/27] perf record: Create two hybrid 'cycles' events by default
When evlist is empty, for example no '-e' specified in perf record,
one default 'cycles' event is added to evlist.
While on hybrid platform, it needs to create two default 'cycles'
events. One is for cpu_core, the other is for cpu_atom.
This patch actually calls evsel__new_cycles() two times to create
two 'cycles' events.
# ./perf record -vv -a -- sleep 1
...
perf_event_attr:
type 6
size 120
config 0x4
{ sample_period, sample_freq } 4000
sample_type IP|TID|TIME|ID|CPU|PERIOD
read_format ID
disabled 1
inherit 1
freq 1
precise_ip 3
sample_id_all1
exclude_guest1
sys_perf_event_open: pid -1 cpu 0 group_fd -1 flags 0x8 = 5
sys_perf_event_open: pid -1 cpu 1 group_fd -1 flags 0x8 = 6
sys_perf_event_open: pid -1 cpu 2 group_fd -1 flags 0x8 = 7
sys_perf_event_open: pid -1 cpu 3 group_fd -1 flags 0x8 = 9
sys_perf_event_open: pid -1 cpu 4 group_fd -1 flags 0x8 = 10
sys_perf_event_open: pid -1 cpu 5 group_fd -1 flags 0x8 = 11
sys_perf_event_open: pid -1 cpu 6 group_fd -1 flags 0x8 = 12
sys_perf_event_open: pid -1 cpu 7 group_fd -1 flags 0x8 = 13
sys_perf_event_open: pid -1 cpu 8 group_fd -1 flags 0x8 = 14
sys_perf_event_open: pid -1 cpu 9 group_fd -1 flags 0x8 = 15
sys_perf_event_open: pid -1 cpu 10 group_fd -1 flags 0x8 = 16
sys_perf_event_open: pid -1 cpu 11 group_fd -1 flags 0x8 = 17
sys_perf_event_open: pid -1 cpu 12 group_fd -1 flags 0x8 = 18
sys_perf_event_open: pid -1 cpu 13 group_fd -1 flags 0x8 = 19
sys_perf_event_open: pid -1 cpu 14 group_fd -1 flags 0x8 = 20
sys_perf_event_open: pid -1 cpu 15 group_fd -1 flags 0x8 = 21
perf_event_attr:
type 6
size 120
config 0xa
{ sample_period, sample_freq } 4000
sample_type IP|TID|TIME|ID|CPU|PERIOD
read_format ID
disabled 1
inherit 1
freq 1
precise_ip 3
sample_id_all1
exclude_guest1
sys_perf_event_open: pid -1 cpu 16 group_fd -1 flags 0x8 = 22
sys_perf_event_open: pid -1 cpu 17 group_fd -1 flags 0x8 = 23
sys_perf_event_open: pid -1 cpu 18 group_fd -1 flags 0x8 = 24
sys_perf_event_open: pid -1 cpu 19 group_fd -1 flags 0x8 = 25
sys_perf_event_open: pid -1 cpu 20 group_fd -1 flags 0x8 = 26
sys_perf_event_open: pid -1 cpu 21 group_fd -1 flags 0x8 = 27
sys_perf_event_open: pid -1 cpu 22 group_fd -1 flags 0x8 = 28
sys_perf_event_open: pid -1 cpu 23 group_fd -1 flags 0x8 = 29
We have to create evlist-hybrid.c otherwise due to the symbol
dependency the perf test python would be failed.
Signed-off-by: Jin Yao
---
v3:
- Move the major code to new created evlist-hybrid.c.
tools/perf/builtin-record.c | 19 +++
tools/perf/util/Build | 1 +
tools/perf/util/evlist-hybrid.c | 41 +
tools/perf/util/evlist-hybrid.h | 12 ++
tools/perf/util/evlist.c| 5 +++-
tools/perf/util/evsel.c | 6 ++---
tools/perf/util/evsel.h | 2 +-
7 files changed, 77 insertions(+), 9 deletions(-)
create mode 100644 tools/perf/util/evlist-hybrid.c
create mode 100644 tools/perf/util/evlist-hybrid.h
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 35465d1db6dd..1b44b1a8636e 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -47,6 +47,8 @@
#include "util/util.h"
#include "util/pfm.h"
#include "util/clockid.h"
+#include "util/pmu-hybrid.h"
+#include "util/evlist-hybrid.h"
#include "asm/bug.h"
#include "perf.h"
@@ -2786,10 +2788,19 @@ int cmd_record(int argc, const char **argv)
if (record.opts.overwrite)
record.opts.tail_synthesize = true;
- if (rec->evlist->core.nr_entries == 0 &&
- __evlist__add_default(rec->evlist, !record.opts.no_samples) < 0) {
- pr_err("Not enough memory for event selector list\n");
- goto out;
+ if (rec->evlist->core.nr_entries == 0) {
+ if (perf_pmu__has_hybrid()) {
+ err = evlist__add_default_hybrid(rec->evlist,
+
[PATCH v3 15/27] perf stat: Filter out unmatched aggregation for hybrid event
perf-stat has supported some aggregation modes, such as --per-core,
--per-socket and etc. While for hybrid event, it may only available
on part of cpus. So for --per-core, we need to filter out the
unavailable cores, for --per-socket, filter out the unavailable
sockets, and so on.
Before:
# perf stat --per-core -e cpu_core/cycles/ -a -- sleep 1
Performance counter stats for 'system wide':
S0-D0-C0 2479,530 cpu_core/cycles/
S0-D0-C4 2175,007 cpu_core/cycles/
S0-D0-C8 2166,240 cpu_core/cycles/
S0-D0-C12 2704,673 cpu_core/cycles/
S0-D0-C16 2865,835 cpu_core/cycles/
S0-D0-C20 2 2,958,461 cpu_core/cycles/
S0-D0-C24 2163,988 cpu_core/cycles/
S0-D0-C28 2164,729 cpu_core/cycles/
S0-D0-C32 0cpu_core/cycles/
S0-D0-C33 0cpu_core/cycles/
S0-D0-C34 0cpu_core/cycles/
S0-D0-C35 0cpu_core/cycles/
S0-D0-C36 0cpu_core/cycles/
S0-D0-C37 0cpu_core/cycles/
S0-D0-C38 0cpu_core/cycles/
S0-D0-C39 0cpu_core/cycles/
1.003597211 seconds time elapsed
After:
# perf stat --per-core -e cpu_core/cycles/ -a -- sleep 1
Performance counter stats for 'system wide':
S0-D0-C0 2210,428 cpu_core/cycles/
S0-D0-C4 2444,830 cpu_core/cycles/
S0-D0-C8 2435,241 cpu_core/cycles/
S0-D0-C12 2423,976 cpu_core/cycles/
S0-D0-C16 2859,350 cpu_core/cycles/
S0-D0-C20 2 1,559,589 cpu_core/cycles/
S0-D0-C24 2163,924 cpu_core/cycles/
S0-D0-C28 2376,610 cpu_core/cycles/
1.003621290 seconds time elapsed
Signed-off-by: Jin Yao
---
v3:
- No functional change.
tools/perf/util/stat-display.c | 20
1 file changed, 20 insertions(+)
diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c
index 161826938a00..b7ce3c4ae5a8 100644
--- a/tools/perf/util/stat-display.c
+++ b/tools/perf/util/stat-display.c
@@ -635,6 +635,20 @@ static void aggr_cb(struct perf_stat_config *config,
}
}
+static bool aggr_id_hybrid_matched(struct perf_stat_config *config,
+ struct evsel *counter, struct aggr_cpu_id id)
+{
+ struct aggr_cpu_id s;
+
+ for (int i = 0; i < evsel__nr_cpus(counter); i++) {
+ s = config->aggr_get_id(config, evsel__cpus(counter), i);
+ if (cpu_map__compare_aggr_cpu_id(s, id))
+ return true;
+ }
+
+ return false;
+}
+
static void print_counter_aggrdata(struct perf_stat_config *config,
struct evsel *counter, int s,
char *prefix, bool metric_only,
@@ -648,6 +662,12 @@ static void print_counter_aggrdata(struct perf_stat_config
*config,
double uval;
ad.id = id = config->aggr_map->map[s];
+
+ if (perf_pmu__has_hybrid() &&
+ !aggr_id_hybrid_matched(config, counter, id)) {
+ return;
+ }
+
ad.val = ad.ena = ad.run = 0;
ad.nr = 0;
if (!collect_data(config, counter, aggr_cb, &ad))
--
2.17.1
[PATCH v3 17/27] perf script: Support PERF_TYPE_HARDWARE_PMU and PERF_TYPE_HW_CACHE_PMU
For a hybrid system, the perf subsystem doesn't know which PMU the
events belong to. So the PMU aware version PERF_TYPE_HARDWARE_PMU and
PERF_TYPE_HW_CACHE_PMU are introduced.
Now define the new output[] entries for these two types.
Signed-off-by: Jin Yao
---
v3:
- No change.
tools/perf/builtin-script.c | 24
1 file changed, 24 insertions(+)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 1280cbfad4db..627ec640d2e6 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -275,6 +275,30 @@ static struct {
.invalid_fields = PERF_OUTPUT_TRACE | PERF_OUTPUT_BPF_OUTPUT,
},
+ [PERF_TYPE_HARDWARE_PMU] = {
+ .user_set = false,
+
+ .fields = PERF_OUTPUT_COMM | PERF_OUTPUT_TID |
+ PERF_OUTPUT_CPU | PERF_OUTPUT_TIME |
+ PERF_OUTPUT_EVNAME | PERF_OUTPUT_IP |
+ PERF_OUTPUT_SYM | PERF_OUTPUT_SYMOFFSET |
+ PERF_OUTPUT_DSO | PERF_OUTPUT_PERIOD,
+
+ .invalid_fields = PERF_OUTPUT_TRACE | PERF_OUTPUT_BPF_OUTPUT,
+ },
+
+ [PERF_TYPE_HW_CACHE_PMU] = {
+ .user_set = false,
+
+ .fields = PERF_OUTPUT_COMM | PERF_OUTPUT_TID |
+ PERF_OUTPUT_CPU | PERF_OUTPUT_TIME |
+ PERF_OUTPUT_EVNAME | PERF_OUTPUT_IP |
+ PERF_OUTPUT_SYM | PERF_OUTPUT_SYMOFFSET |
+ PERF_OUTPUT_DSO | PERF_OUTPUT_PERIOD,
+
+ .invalid_fields = PERF_OUTPUT_TRACE | PERF_OUTPUT_BPF_OUTPUT,
+ },
+
[OUTPUT_TYPE_SYNTH] = {
.user_set = false,
--
2.17.1
[PATCH v3 14/27] perf stat: Add default hybrid events
Previously if '-e' is not specified in perf stat, some software events
and hardware events are added to evlist by default.
Before:
# ./perf stat -a -- sleep 1
Performance counter stats for 'system wide':
24,044.40 msec cpu-clock # 23.946 CPUs utilized
99 context-switches #4.117 /sec
24 cpu-migrations#0.998 /sec
3 page-faults #0.125 /sec
7,000,244 cycles#0.000 GHz
2,955,024 instructions #0.42 insn per cycle
608,941 branches # 25.326 K/sec
31,991 branch-misses #5.25% of all branches
1.004106859 seconds time elapsed
Among the events, cycles, instructions, branches and branch-misses
are hardware events.
One hybrid platform, two hardware events are created for one
hardware event.
cpu_core/cycles/,
cpu_atom/cycles/,
cpu_core/instructions/,
cpu_atom/instructions/,
cpu_core/branches/,
cpu_atom/branches/,
cpu_core/branch-misses/,
cpu_atom/branch-misses/
These events would be added to evlist on hybrid platform.
Since parse_events() has been supported to create two hardware events
for one event on hybrid platform, so we just use parse_events(evlist,
"cycles,instructions,branches,branch-misses") to create the default
events and add them to evlist.
After:
# ./perf stat -a -- sleep 1
Performance counter stats for 'system wide':
24,048.60 msec task-clock# 23.947 CPUs utilized
438 context-switches # 18.213 /sec
24 cpu-migrations#0.998 /sec
6 page-faults #0.249 /sec
24,813,157 cpu_core/cycles/ #1.032 M/sec
8,072,687 cpu_atom/cycles/ # 335.682 K/sec
20,731,286 cpu_core/instructions/# 862.058 K/sec
3,737,203 cpu_atom/instructions/# 155.402 K/sec
2,620,924 cpu_core/branches/# 108.984 K/sec
381,186 cpu_atom/branches/# 15.851 K/sec
93,248 cpu_core/branch-misses/ #3.877 K/sec
36,515 cpu_atom/branch-misses/ #1.518 K/sec
1.004235472 seconds time elapsed
We can see two events are created for one hardware event.
One TODO is, the shadow stats looks a bit different, now it's just
'M/sec'.
The perf_stat__update_shadow_stats and perf_stat__print_shadow_stats
need to be improved in future if we want to get the original shadow
stats.
Signed-off-by: Jin Yao
---
v3:
- No functional change.
tools/perf/builtin-stat.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 7b2dfe21c5a8..33fda8f55f66 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1140,6 +1140,13 @@ static int parse_stat_cgroups(const struct option *opt,
return parse_cgroups(opt, str, unset);
}
+static int add_default_hybrid_events(struct evlist *evlist)
+{
+ struct parse_events_error err;
+
+ return parse_events(evlist,
"cycles,instructions,branches,branch-misses", &err);
+}
+
static struct option stat_options[] = {
OPT_BOOLEAN('T', "transaction", &transaction_run,
"hardware transaction statistics"),
@@ -1619,6 +1626,12 @@ static int add_default_attributes(void)
{ .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_BRANCH_INSTRUCTIONS
},
{ .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_BRANCH_MISSES
},
+};
+ struct perf_event_attr default_sw_attrs[] = {
+ { .type = PERF_TYPE_SOFTWARE, .config = PERF_COUNT_SW_TASK_CLOCK
},
+ { .type = PERF_TYPE_SOFTWARE, .config = PERF_COUNT_SW_CONTEXT_SWITCHES
},
+ { .type = PERF_TYPE_SOFTWARE, .config = PERF_COUNT_SW_CPU_MIGRATIONS
},
+ { .type = PERF_TYPE_SOFTWARE, .config = PERF_COUNT_SW_PAGE_FAULTS
},
};
/*
@@ -1856,6 +1869,14 @@ static int add_default_attributes(void)
}
if (!evsel_list->core.nr_entries) {
+ if (perf_pmu__has_hybrid()) {
+ if (evlist__add_default_attrs(evsel_list,
+ default_sw_attrs) < 0) {
+ return -1;
+ }
+ return add_default_hybrid_events(evsel_list);
+ }
+
if (target__has_cpu(&target))
default_attrs0[0].config = PERF_COUNT_SW_CPU_CLOCK;
--
2.17.1
[PATCH v3 16/27] perf stat: Warn group events from different hybrid PMU
If a group has events which are from different hybrid PMUs,
shows a warning:
"WARNING: events in group from different hybrid PMUs!"
This is to remind the user not to put the core event and atom
event into one group.
Next, just disable grouping.
# perf stat -e "{cpu_core/cycles/,cpu_atom/cycles/}" -a -- sleep 1
WARNING: events in group from different hybrid PMUs!
WARNING: grouped events cpus do not match, disabling group:
anon group { cpu_core/cycles/, cpu_atom/cycles/ }
Performance counter stats for 'system wide':
5,438,125 cpu_core/cycles/
3,914,586 cpu_atom/cycles/
1.004250966 seconds time elapsed
Signed-off-by: Jin Yao
---
v3:
- Change the processing logic. In v2, it just reported the warning
and returned error. But in v3, we also disable grouping.
tools/perf/builtin-stat.c | 4 +++
tools/perf/util/evlist-hybrid.c| 47 ++
tools/perf/util/evlist-hybrid.h| 2 ++
tools/perf/util/evsel.c| 6
tools/perf/util/evsel.h| 1 +
tools/perf/util/python-ext-sources | 2 ++
6 files changed, 62 insertions(+)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 33fda8f55f66..6f70a9f1971e 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -48,6 +48,7 @@
#include "util/pmu.h"
#include "util/event.h"
#include "util/evlist.h"
+#include "util/evlist-hybrid.h"
#include "util/evsel.h"
#include "util/debug.h"
#include "util/color.h"
@@ -240,6 +241,9 @@ static void evlist__check_cpu_maps(struct evlist *evlist)
struct evsel *evsel, *pos, *leader;
char buf[1024];
+ if (evlist__has_hybrid(evlist))
+ evlist__warn_hybrid_group(evlist);
+
evlist__for_each_entry(evlist, evsel) {
leader = evsel->leader;
diff --git a/tools/perf/util/evlist-hybrid.c b/tools/perf/util/evlist-hybrid.c
index 185f60ec4351..39f520372447 100644
--- a/tools/perf/util/evlist-hybrid.c
+++ b/tools/perf/util/evlist-hybrid.c
@@ -7,6 +7,7 @@
#include "../perf.h"
#include "util/pmu-hybrid.h"
#include "util/evlist-hybrid.h"
+#include "debug.h"
#include
#include
#include
@@ -39,3 +40,49 @@ int evlist__add_default_hybrid(struct evlist *evlist, bool
precise)
return 0;
}
+
+static bool group_hybrid_conflict(struct evsel *leader)
+{
+ struct evsel *pos, *prev = NULL;
+
+ for_each_group_evsel(pos, leader) {
+ if (!evsel__is_hybrid(pos))
+ continue;
+
+ if (prev && strcmp(prev->pmu_name, pos->pmu_name))
+ return true;
+
+ prev = pos;
+ }
+
+ return false;
+}
+
+void evlist__warn_hybrid_group(struct evlist *evlist)
+{
+ struct evsel *evsel;
+
+ evlist__for_each_entry(evlist, evsel) {
+ if (evsel__is_group_leader(evsel) &&
+ evsel->core.nr_members > 1 &&
+ group_hybrid_conflict(evsel)) {
+ pr_warning("WARNING: events in group from "
+ "different hybrid PMUs!\n");
+ return;
+ }
+ }
+}
+
+bool evlist__has_hybrid(struct evlist *evlist)
+{
+ struct evsel *evsel;
+
+ evlist__for_each_entry(evlist, evsel) {
+ if (evsel->pmu_name &&
+ perf_pmu__is_hybrid(evsel->pmu_name)) {
+ return true;
+ }
+ }
+
+ return false;
+}
diff --git a/tools/perf/util/evlist-hybrid.h b/tools/perf/util/evlist-hybrid.h
index e25861649d8f..19f74b4c340a 100644
--- a/tools/perf/util/evlist-hybrid.h
+++ b/tools/perf/util/evlist-hybrid.h
@@ -8,5 +8,7 @@
#include
int evlist__add_default_hybrid(struct evlist *evlist, bool precise);
+void evlist__warn_hybrid_group(struct evlist *evlist);
+bool evlist__has_hybrid(struct evlist *evlist);
#endif /* __PERF_EVLIST_HYBRID_H */
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 0ba4daa09453..0f64a32ea9c5 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -47,6 +47,7 @@
#include "memswap.h"
#include "util.h"
#include "hashmap.h"
+#include "pmu-hybrid.h"
#include "../perf-sys.h"
#include "util/parse-branch-options.h"
#include
@@ -2797,3 +2798,8 @@ void evsel__zero_per_pkg(struct evsel *evsel)
hashmap__clear(evsel->per_pkg_mask);
}
}
+
+bool evsel__is_hybrid(struct evsel *evsel)
+{
+ return evsel->pmu_name && perf_pmu__is_hybrid(evsel->pmu_name);
+}
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index e7dc3448ab2f..e56826bbb628 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -453,4 +453,5 @@ struct perf_env *evsel__env(struct evsel *evsel);
int evsel__store_ids(struct evsel *evsel, struct evlist *evlist);
void evsel__zero_per_pkg(struct evsel *evsel);
+bool evsel__is_hybrid(struct evsel *evsel);
#endif /* __PERF_EVSEL_H */
[PATCH v3 26/27] perf tests: Skip 'perf stat metrics (shadow stat) test' for hybrid
Currently we don't support shadow stat for hybrid.
root@ssp-pwrt-002:~# ./perf stat -e cycles,instructions -a -- sleep 1
Performance counter stats for 'system wide':
12,883,109,591 cpu_core/cycles/
6,405,163,221 cpu_atom/cycles/
555,553,778 cpu_core/instructions/
841,158,734 cpu_atom/instructions/
1.002644773 seconds time elapsed
Now there is no shadow stat 'insn per cycle' reported. We will support
it later and now just skip the 'perf stat metrics (shadow stat) test'.
Signed-off-by: Jin Yao
---
v3:
- No functional change.
tools/perf/tests/shell/stat+shadow_stat.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/perf/tests/shell/stat+shadow_stat.sh
b/tools/perf/tests/shell/stat+shadow_stat.sh
index ebebd3596cf9..e6e35fc6c882 100755
--- a/tools/perf/tests/shell/stat+shadow_stat.sh
+++ b/tools/perf/tests/shell/stat+shadow_stat.sh
@@ -7,6 +7,9 @@ set -e
# skip if system-wide mode is forbidden
perf stat -a true > /dev/null 2>&1 || exit 2
+# skip if on hybrid platform
+perf stat -a -e cycles sleep 1 2>&1 | grep -e cpu_core && exit 2
+
test_global_aggr()
{
perf stat -a --no-big-num -e cycles,instructions sleep 1 2>&1 | \
--
2.17.1
[PATCH v3 21/27] perf tests: Skip 'Setup struct perf_event_attr' test for hybrid
For hybrid, kernel introduces new perf type PERF_TYPE_HARDWARE_PMU (6)
and it's assigned to hybrid hardware events.
# ./perf test 17 -vvv
...
compare
matching [event:base-stat]
to [event-6-17179869184-4]
[cpu] * 0
[flags] 0|8 8
[type] 0 6
->FAIL
match: [event:base-stat] matches []
event:base-stat does not match, but is optional
matched
compare
matching [event-6-17179869184-4]
to [event:base-stat]
[cpu] 0 *
[flags] 8 0|8
[type] 6 0
->FAIL
match: [event-6-17179869184-4] matches []
expected type=6, got 0
expected config=17179869184, got 0
FAILED './tests/attr/test-stat-C0' - match failure
The type matching is failed because one type is 0 but the
type of hybrid hardware event is 6. We temporarily skip this
test case and TODO in future.
Signed-off-by: Jin Yao
---
v3:
- No functional change.
tools/perf/tests/attr.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/perf/tests/attr.c b/tools/perf/tests/attr.c
index dd39ce9b0277..b37c35fb5a46 100644
--- a/tools/perf/tests/attr.c
+++ b/tools/perf/tests/attr.c
@@ -34,6 +34,7 @@
#include "event.h"
#include "util.h"
#include "tests.h"
+#include "pmu.h"
#define ENV "PERF_TEST_ATTR"
@@ -184,6 +185,9 @@ int test__attr(struct test *test __maybe_unused, int
subtest __maybe_unused)
char path_dir[PATH_MAX];
char *exec_path;
+ if (perf_pmu__has_hybrid())
+ return 0;
+
/* First try development tree tests. */
if (!lstat("./tests", &st))
return run_dir("./tests", "./perf");
--
2.17.1
[PATCH v3 20/27] perf tests: Add hybrid cases for 'Roundtrip evsel->name' test
Since for one hw event, two hybrid events are created.
For example,
evsel->idx evsel__name(evsel)
0 cycles
1 cycles
2 instructions
3 instructions
...
So for comparing the evsel name on hybrid, the evsel->idx
needs to be divided by 2.
# ./perf test 14
14: Roundtrip evsel->name : Ok
Signed-off-by: Jin Yao
---
v3:
- No functional change.
tools/perf/tests/evsel-roundtrip-name.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/tools/perf/tests/evsel-roundtrip-name.c
b/tools/perf/tests/evsel-roundtrip-name.c
index f7f3e5b4c180..b74cf80d1f10 100644
--- a/tools/perf/tests/evsel-roundtrip-name.c
+++ b/tools/perf/tests/evsel-roundtrip-name.c
@@ -4,6 +4,7 @@
#include "parse-events.h"
#include "tests.h"
#include "debug.h"
+#include "pmu.h"
#include
#include
@@ -62,7 +63,8 @@ static int perf_evsel__roundtrip_cache_name_test(void)
return ret;
}
-static int __perf_evsel__name_array_test(const char *names[], int nr_names)
+static int __perf_evsel__name_array_test(const char *names[], int nr_names,
+int distance)
{
int i, err;
struct evsel *evsel;
@@ -82,9 +84,9 @@ static int __perf_evsel__name_array_test(const char *names[],
int nr_names)
err = 0;
evlist__for_each_entry(evlist, evsel) {
- if (strcmp(evsel__name(evsel), names[evsel->idx])) {
+ if (strcmp(evsel__name(evsel), names[evsel->idx / distance])) {
--err;
- pr_debug("%s != %s\n", evsel__name(evsel),
names[evsel->idx]);
+ pr_debug("%s != %s\n", evsel__name(evsel),
names[evsel->idx / distance]);
}
}
@@ -93,18 +95,21 @@ static int __perf_evsel__name_array_test(const char
*names[], int nr_names)
return err;
}
-#define perf_evsel__name_array_test(names) \
- __perf_evsel__name_array_test(names, ARRAY_SIZE(names))
+#define perf_evsel__name_array_test(names, distance) \
+ __perf_evsel__name_array_test(names, ARRAY_SIZE(names), distance)
int test__perf_evsel__roundtrip_name_test(struct test *test __maybe_unused,
int subtest __maybe_unused)
{
int err = 0, ret = 0;
- err = perf_evsel__name_array_test(evsel__hw_names);
+ if (perf_pmu__has_hybrid())
+ return perf_evsel__name_array_test(evsel__hw_names, 2);
+
+ err = perf_evsel__name_array_test(evsel__hw_names, 1);
if (err)
ret = err;
- err = __perf_evsel__name_array_test(evsel__sw_names,
PERF_COUNT_SW_DUMMY + 1);
+ err = __perf_evsel__name_array_test(evsel__sw_names,
PERF_COUNT_SW_DUMMY + 1, 1);
if (err)
ret = err;
--
2.17.1
[PATCH v3 27/27] perf Documentation: Document intel-hybrid support
Add some words and examples to help understanding of Intel hybrid perf support. Signed-off-by: Jin Yao --- v3: - No functional change. tools/perf/Documentation/intel-hybrid.txt | 228 ++ tools/perf/Documentation/perf-record.txt | 1 + tools/perf/Documentation/perf-stat.txt| 2 + 3 files changed, 231 insertions(+) create mode 100644 tools/perf/Documentation/intel-hybrid.txt diff --git a/tools/perf/Documentation/intel-hybrid.txt b/tools/perf/Documentation/intel-hybrid.txt new file mode 100644 index ..784f598dd36f --- /dev/null +++ b/tools/perf/Documentation/intel-hybrid.txt @@ -0,0 +1,228 @@ +Intel hybrid support + +Support for Intel hybrid events within perf tools. + +For some Intel platforms, such as AlderLake, which is hybrid platform and +it consists of atom cpu and core cpu. Each cpu has dedicated event list. +Part of events are available on core cpu, part of events are available +on atom cpu and even part of events are available on both. + +Kernel exports two new cpu pmus via sysfs: +/sys/devices/cpu_core +/sys/devices/cpu_atom + +The 'cpus' files are created under the directories. For example, + +cat /sys/devices/cpu_core/cpus +0-15 + +cat /sys/devices/cpu_atom/cpus +16-23 + +It indicates cpu0-cpu15 are core cpus and cpu16-cpu23 are atom cpus. + +Quickstart + +List hybrid event +- + +As before, use perf-list to list the symbolic event. + +perf list + +inst_retired.any + [Fixed Counter: Counts the number of instructions retired. Unit: cpu_atom] +inst_retired.any + [Number of instructions retired. Fixed Counter - architectural event. Unit: cpu_core] + +The 'Unit: xxx' is added to brief description to indicate which pmu +the event is belong to. Same event name but with different pmu can +be supported. + +Enable hybrid event with a specific pmu +--- + +To enable a core only event or atom only event, following syntax is supported: + + cpu_core// +or + cpu_atom// + +For example, count the 'cycles' event on core cpus. + + perf stat -e cpu_core/cycles/ + +Create two events for one hardware event automatically +-- + +When creating one event and the event is available on both atom and core, +two events are created automatically. One is for atom, the other is for +core. Most of hardware events and cache events are available on both +cpu_core and cpu_atom. + +For hardware events, they have pre-defined configs (e.g. 0 for cycles). +But on hybrid platform, kernel needs to know where the event comes from +(from atom or from core). The original perf event type PERF_TYPE_HARDWARE +can't carry pmu information. So a new type PERF_TYPE_HARDWARE_PMU is +introduced. + +The new attr.config layout for PERF_TYPE_HARDWARE_PMU: + +0xDD00AA +AA: original hardware event ID +DD: PMU type ID + +Cache event is similar. A new type PERF_TYPE_HW_CACHE_PMU is introduced. + +The new attr.config layout for PERF_TYPE_HW_CACHE_PMU: + +0xDD00CCBBAA +AA: original hardware cache ID +BB: original hardware cache op ID +CC: original hardware cache op result ID +DD: PMU type ID + +PMU type ID is retrieved from sysfs + +cat /sys/devices/cpu_atom/type +10 + +cat /sys/devices/cpu_core/type +4 + +When enabling a hardware event without specified pmu, such as, +perf stat -e cycles -a (use system-wide in this example), two events +are created automatically. + + +perf_event_attr: + type 6 + size 120 + config 0x4 + sample_type IDENTIFIER + read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING + disabled 1 + inherit 1 + exclude_guest1 + + +and + + +perf_event_attr: + type 6 + size 120 + config 0xa + sample_type IDENTIFIER + read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING + disabled 1 + inherit 1 + exclude_guest1 + + +type 6 is PERF_TYPE_HARDWARE_PMU. +0x4 in 0x4 indicates it's cpu_core pmu. +0xa in 0xa indicates it's cpu_atom pmu (atom pmu type id is random). + +The kernel creates 'cycles' (0x4) on cpu0-cpu15 (core cpus), +and create 'cycles' (0xa) on cpu16-cpu23 (atom cpus). + +For perf-stat result, it displays two events: + + Performance counter stats for 'system wide': + +12,869,720,5
[PATCH v3 23/27] perf tests: Support 'Parse and process metrics' test for hybrid
Some events are not supported. Only pick up some cases for hybrid.
# ./perf test 67
67: Parse and process metrics : Ok
Signed-off-by: Jin Yao
---
v3:
- No functional change.
tools/perf/tests/parse-metric.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/tools/perf/tests/parse-metric.c b/tools/perf/tests/parse-metric.c
index 4968c4106254..24e5ddff515e 100644
--- a/tools/perf/tests/parse-metric.c
+++ b/tools/perf/tests/parse-metric.c
@@ -11,6 +11,7 @@
#include "debug.h"
#include "expr.h"
#include "stat.h"
+#include "pmu.h"
static struct pmu_event pme_test[] = {
{
@@ -370,12 +371,17 @@ static int test_metric_group(void)
int test__parse_metric(struct test *test __maybe_unused, int subtest
__maybe_unused)
{
+ perf_pmu__scan(NULL);
+
TEST_ASSERT_VAL("IPC failed", test_ipc() == 0);
TEST_ASSERT_VAL("frontend failed", test_frontend() == 0);
- TEST_ASSERT_VAL("cache_miss_cycles failed", test_cache_miss_cycles() ==
0);
TEST_ASSERT_VAL("DCache_L2 failed", test_dcache_l2() == 0);
TEST_ASSERT_VAL("recursion fail failed", test_recursion_fail() == 0);
- TEST_ASSERT_VAL("test metric group", test_metric_group() == 0);
TEST_ASSERT_VAL("Memory bandwidth", test_memory_bandwidth() == 0);
+
+ if (!perf_pmu__has_hybrid()) {
+ TEST_ASSERT_VAL("cache_miss_cycles failed",
test_cache_miss_cycles() == 0);
+ TEST_ASSERT_VAL("test metric group", test_metric_group() == 0);
+ }
return 0;
}
--
2.17.1
[PATCH v3 22/27] perf tests: Support 'Track with sched_switch' test for hybrid
Since for "cycles:u' on hybrid platform, it creates two "cycles".
So the number of events in evlist is not expected in next test
steps. Now we just use one event "cpu_core/cycles:u/" for hybrid.
# ./perf test 35
35: Track with sched_switch : Ok
Signed-off-by: Jin Yao
---
v3:
- No functional change.
tools/perf/tests/switch-tracking.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/perf/tests/switch-tracking.c
b/tools/perf/tests/switch-tracking.c
index 3ebaa758df77..3a12176f8c46 100644
--- a/tools/perf/tests/switch-tracking.c
+++ b/tools/perf/tests/switch-tracking.c
@@ -18,6 +18,7 @@
#include "record.h"
#include "tests.h"
#include "util/mmap.h"
+#include "pmu.h"
static int spin_sleep(void)
{
@@ -340,6 +341,10 @@ int test__switch_tracking(struct test *test
__maybe_unused, int subtest __maybe_
struct evsel *switch_evsel, *tracking_evsel;
const char *comm;
int err = -1;
+ bool hybrid = false;
+
+ if (perf_pmu__has_hybrid())
+ hybrid = true;
threads = thread_map__new(-1, getpid(), UINT_MAX);
if (!threads) {
@@ -371,7 +376,10 @@ int test__switch_tracking(struct test *test
__maybe_unused, int subtest __maybe_
cpu_clocks_evsel = evlist__last(evlist);
/* Second event */
- err = parse_events(evlist, "cycles:u", NULL);
+ if (!hybrid)
+ err = parse_events(evlist, "cycles:u", NULL);
+ else
+ err = parse_events(evlist, "cpu_core/cycles/u", NULL);
if (err) {
pr_debug("Failed to parse event cycles:u\n");
goto out_err;
--
2.17.1
[PATCH v3 25/27] perf tests: Support 'Convert perf time to TSC' test for hybrid
Since for "cycles:u' on hybrid platform, it creates two "cycles".
So the second evsel in evlist also needs initialization.
With this patch,
# ./perf test 71
71: Convert perf time to TSC: Ok
Signed-off-by: Jin Yao
---
v3:
- No functional change.
tools/perf/tests/perf-time-to-tsc.c | 16
1 file changed, 16 insertions(+)
diff --git a/tools/perf/tests/perf-time-to-tsc.c
b/tools/perf/tests/perf-time-to-tsc.c
index 680c3cffb128..72f268c6cc5d 100644
--- a/tools/perf/tests/perf-time-to-tsc.c
+++ b/tools/perf/tests/perf-time-to-tsc.c
@@ -20,6 +20,7 @@
#include "tsc.h"
#include "mmap.h"
#include "tests.h"
+#include "pmu.h"
#define CHECK__(x) { \
while ((x) < 0) { \
@@ -66,6 +67,10 @@ int test__perf_time_to_tsc(struct test *test __maybe_unused,
int subtest __maybe
u64 test_tsc, comm1_tsc, comm2_tsc;
u64 test_time, comm1_time = 0, comm2_time = 0;
struct mmap *md;
+ bool hybrid = false;
+
+ if (perf_pmu__has_hybrid())
+ hybrid = true;
threads = thread_map__new(-1, getpid(), UINT_MAX);
CHECK_NOT_NULL__(threads);
@@ -88,6 +93,17 @@ int test__perf_time_to_tsc(struct test *test __maybe_unused,
int subtest __maybe
evsel->core.attr.disabled = 1;
evsel->core.attr.enable_on_exec = 0;
+ /*
+* For hybrid "cycles:u", it creates two events.
+* Init the second evsel here.
+*/
+ if (hybrid) {
+ evsel = evsel__next(evsel);
+ evsel->core.attr.comm = 1;
+ evsel->core.attr.disabled = 1;
+ evsel->core.attr.enable_on_exec = 0;
+ }
+
CHECK__(evlist__open(evlist));
CHECK__(evlist__mmap(evlist, UINT_MAX));
--
2.17.1
[PATCH v3 19/27] perf tests: Add hybrid cases for 'Parse event definition strings' test
Add basic hybrid test cases for 'Parse event definition strings' test.
# ./perf test 6
6: Parse event definition strings : Ok
Signed-off-by: Jin Yao
---
v3:
- Use PERF_TYPE_RAW for cpu_core/cycles/
tools/perf/tests/parse-events.c | 170
1 file changed, 170 insertions(+)
diff --git a/tools/perf/tests/parse-events.c b/tools/perf/tests/parse-events.c
index 026c54743311..1cd1d2778172 100644
--- a/tools/perf/tests/parse-events.c
+++ b/tools/perf/tests/parse-events.c
@@ -1512,6 +1512,123 @@ static int test__all_tracepoints(struct evlist *evlist)
return test__checkevent_tracepoint_multi(evlist);
}
+static int test__hybrid_hw_event_with_pmu(struct evlist *evlist)
+{
+ struct evsel *evsel = evlist__first(evlist);
+
+ TEST_ASSERT_VAL("wrong number of entries", 1 ==
evlist->core.nr_entries);
+ TEST_ASSERT_VAL("wrong type", PERF_TYPE_RAW == evsel->core.attr.type);
+ TEST_ASSERT_VAL("wrong config", 0x3c == evsel->core.attr.config);
+ return 0;
+}
+
+static int test__hybrid_hw_event(struct evlist *evlist)
+{
+ struct evsel *evsel1 = evlist__first(evlist);
+ struct evsel *evsel2 = evlist__last(evlist);
+
+ TEST_ASSERT_VAL("wrong number of entries", 2 ==
evlist->core.nr_entries);
+ TEST_ASSERT_VAL("wrong type", PERF_TYPE_HARDWARE_PMU ==
evsel1->core.attr.type);
+ TEST_ASSERT_VAL("wrong config", 0x4 ==
evsel1->core.attr.config);
+ TEST_ASSERT_VAL("wrong type", PERF_TYPE_HARDWARE_PMU ==
evsel2->core.attr.type);
+ TEST_ASSERT_VAL("wrong config", 0xa ==
evsel2->core.attr.config);
+ return 0;
+}
+
+static int test__hybrid_hw_group_event(struct evlist *evlist)
+{
+ struct evsel *evsel, *leader;
+
+ evsel = leader = evlist__first(evlist);
+ TEST_ASSERT_VAL("wrong number of entries", 2 ==
evlist->core.nr_entries);
+ TEST_ASSERT_VAL("wrong type", PERF_TYPE_RAW == evsel->core.attr.type);
+ TEST_ASSERT_VAL("wrong config", 0x3c == evsel->core.attr.config);
+ TEST_ASSERT_VAL("wrong leader", evsel->leader == leader);
+
+ evsel = evsel__next(evsel);
+ TEST_ASSERT_VAL("wrong type", PERF_TYPE_RAW == evsel->core.attr.type);
+ TEST_ASSERT_VAL("wrong config", 0xc0 == evsel->core.attr.config);
+ TEST_ASSERT_VAL("wrong leader", evsel->leader == leader);
+ return 0;
+}
+
+static int test__hybrid_sw_hw_group_event(struct evlist *evlist)
+{
+ struct evsel *evsel, *leader;
+
+ evsel = leader = evlist__first(evlist);
+ TEST_ASSERT_VAL("wrong number of entries", 2 ==
evlist->core.nr_entries);
+ TEST_ASSERT_VAL("wrong type", PERF_TYPE_SOFTWARE ==
evsel->core.attr.type);
+ TEST_ASSERT_VAL("wrong leader", evsel->leader == leader);
+
+ evsel = evsel__next(evsel);
+ TEST_ASSERT_VAL("wrong type", PERF_TYPE_RAW == evsel->core.attr.type);
+ TEST_ASSERT_VAL("wrong config", 0x3c == evsel->core.attr.config);
+ TEST_ASSERT_VAL("wrong leader", evsel->leader == leader);
+ return 0;
+}
+
+static int test__hybrid_hw_sw_group_event(struct evlist *evlist)
+{
+ struct evsel *evsel, *leader;
+
+ evsel = leader = evlist__first(evlist);
+ TEST_ASSERT_VAL("wrong number of entries", 2 ==
evlist->core.nr_entries);
+ TEST_ASSERT_VAL("wrong type", PERF_TYPE_RAW == evsel->core.attr.type);
+ TEST_ASSERT_VAL("wrong config", 0x3c == evsel->core.attr.config);
+ TEST_ASSERT_VAL("wrong leader", evsel->leader == leader);
+
+ evsel = evsel__next(evsel);
+ TEST_ASSERT_VAL("wrong type", PERF_TYPE_SOFTWARE ==
evsel->core.attr.type);
+ TEST_ASSERT_VAL("wrong leader", evsel->leader == leader);
+ return 0;
+}
+
+static int test__hybrid_group_modifier1(struct evlist *evlist)
+{
+ struct evsel *evsel, *leader;
+
+ evsel = leader = evlist__first(evlist);
+ TEST_ASSERT_VAL("wrong number of entries", 2 ==
evlist->core.nr_entries);
+ TEST_ASSERT_VAL("wrong type", PERF_TYPE_RAW == evsel->core.attr.type);
+ TEST_ASSERT_VAL("wrong config", 0x3c == evsel->core.attr.config);
+ TEST_ASSERT_VAL("wrong leader", evsel->leader == leader);
+ TEST_ASSERT_VAL("wrong exclude_user", evsel->core.attr.exclude_user);
+ TEST_ASSERT_VAL("wrong exclude_kernel",
!evsel->core.attr.exclude_kernel);
+
+ evsel = evsel__next(evsel);
+ TEST_ASSERT_VAL("wrong type", PERF_TYPE_RAW == evsel->core.attr.type);
+ TEST_ASSERT_VAL("wrong config", 0xc0 == evsel->core.attr.config);
+ TEST_ASSERT_VAL("wrong leader", evsel->leader == leader);
+ TEST_ASSERT_VAL("wrong exclude_user", !evsel->core.attr.exclude_user);
+ TEST_ASSERT_VAL("wrong exclude_kernel",
evsel->core.attr.exclude_kernel);
+ return 0;
+}
+
+static int test__hybrid_raw1(struct evlist *evlist)
+{
+ struct evsel *evsel = evlist__first(evlist);
+
+ TEST_ASSERT_VAL("wrong number of entries", 2 ==
e
[PATCH v3 24/27] perf tests: Support 'Session topology' test for hybrid
Force to create one event "cpu_core/cycles/" by default,
otherwise in evlist__valid_sample_type, the checking of
'if (evlist->core.nr_entries == 1)' would be failed.
# ./perf test 41
41: Session topology: Ok
Signed-off-by: Jin Yao
---
v3:
- No functional change.
tools/perf/tests/topology.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/perf/tests/topology.c b/tools/perf/tests/topology.c
index 050489807a47..30b4acb08d35 100644
--- a/tools/perf/tests/topology.c
+++ b/tools/perf/tests/topology.c
@@ -8,6 +8,7 @@
#include "session.h"
#include "evlist.h"
#include "debug.h"
+#include "pmu.h"
#include
#define TEMPL "/tmp/perf-test-XX"
@@ -40,7 +41,14 @@ static int session_write_header(char *path)
session = perf_session__new(&data, false, NULL);
TEST_ASSERT_VAL("can't get session", !IS_ERR(session));
- session->evlist = evlist__new_default();
+ if (!perf_pmu__has_hybrid()) {
+ session->evlist = evlist__new_default();
+ } else {
+ struct parse_events_error err;
+
+ session->evlist = evlist__new();
+ parse_events(session->evlist, "cpu_core/cycles/", &err);
+ }
TEST_ASSERT_VAL("can't get evlist", session->evlist);
perf_header__set_feat(&session->header, HEADER_CPU_TOPOLOGY);
--
2.17.1
[PATCH v3 18/27] perf record: Uniquify hybrid event name
For perf-record, it would be useful to tell user the pmu which the
event belongs to.
For example,
# perf record -a -- sleep 1
# perf report
# To display the perf.data header info, please use --header/--header-only
options.
#
#
# Total Lost Samples: 0
#
# Samples: 106 of event 'cpu_core/cycles/'
# Event count (approx.): 22043448
#
# Overhead Command Shared ObjectSymbol
# ...
#
...
Signed-off-by: Jin Yao
---
v3:
- New patch in v3.
tools/perf/builtin-record.c | 28
1 file changed, 28 insertions(+)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 1b44b1a8636e..74cc9ffbd9ef 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1605,6 +1605,32 @@ static void hit_auxtrace_snapshot_trigger(struct record
*rec)
}
}
+static void record__uniquify_name(struct record *rec)
+{
+ struct evsel *pos;
+ struct evlist *evlist = rec->evlist;
+ char *new_name;
+ int ret;
+
+ if (!perf_pmu__has_hybrid())
+ return;
+
+ evlist__for_each_entry(evlist, pos) {
+ if (!evsel__is_hybrid(pos))
+ continue;
+
+ if (strchr(pos->name, '/'))
+ continue;
+
+ ret = asprintf(&new_name, "%s/%s/",
+ pos->pmu_name, pos->name);
+ if (ret) {
+ free(pos->name);
+ pos->name = new_name;
+ }
+ }
+}
+
static int __cmd_record(struct record *rec, int argc, const char **argv)
{
int err;
@@ -1709,6 +1735,8 @@ static int __cmd_record(struct record *rec, int argc,
const char **argv)
if (data->is_pipe && rec->evlist->core.nr_entries == 1)
rec->opts.sample_id = true;
+ record__uniquify_name(rec);
+
if (record__open(rec) != 0) {
err = -1;
goto out_child;
--
2.17.1
Re: [PATCH 3/3] iio: adc: ad7923: register device with devm_iio_device_register
On 3/28/21 11:46 PM, Lucas Stankus wrote:
Registers the device using the devm variant.
This is the final step of converting the ad7923 to only use devm routines,
meaning that the ad7923_remove() function is no longer needed to release
resources on device detach.
Signed-off-by: Lucas Stankus
Hi,
Thanks for the patches.T his looks good, just one small comment.
---
drivers/iio/adc/ad7923.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/iio/adc/ad7923.c b/drivers/iio/adc/ad7923.c
index d07eaf3111ed..f7af2f194789 100644
--- a/drivers/iio/adc/ad7923.c
+++ b/drivers/iio/adc/ad7923.c
@@ -356,16 +356,7 @@ static int ad7923_probe(struct spi_device *spi)
if (ret)
return ret;
- return iio_device_register(indio_dev);
-}
-
-static int ad7923_remove(struct spi_device *spi)
-{
- struct iio_dev *indio_dev = spi_get_drvdata(spi);
This removes the last user of get_drvdata() on the SPI device. This means you
can also remove the spi_set_drvdata() in the probe function.
-
- iio_device_unregister(indio_dev);
-
- return 0;
+ return devm_iio_device_register(&spi->dev, indio_dev);
}
[PATCH] powerpc/8xx: Load modules closer to kernel text
On the 8xx, TASK_SIZE is 0x8000. The space between TASK_SIZE and PAGE_OFFSET is not used. Use it to load modules in order to minimise the distance between kernel text and modules and avoid trampolines in modules to access kernel functions or other module functions. Define a 16Mbytes area for modules, that's more than enough. DEBUG logs in module_32.c without the patch: [ 1572.588822] module_32: Applying ADD relocate section 13 to 12 [ 1572.588891] module_32: Doing plt for call to 0xc00671a4 at 0xcae04024 [ 1572.588964] module_32: Initialized plt for 0xc00671a4 at cae04000 [ 1572.589037] module_32: REL24 value = CAE04000. location = CAE04024 [ 1572.589110] module_32: Location before: 4801. [ 1572.589171] module_32: Location after: 4BDD. [ 1572.589231] module_32: ie. jump to 03DC+CAE04024 = CEE04000 [ 1572.589317] module_32: Applying ADD relocate section 15 to 14 [ 1572.589386] module_32: Doing plt for call to 0xc00671a4 at 0xcadfc018 [ 1572.589457] module_32: Initialized plt for 0xc00671a4 at cadfc000 [ 1572.589529] module_32: REL24 value = CADFC000. location = CADFC018 [ 1572.589601] module_32: Location before: 4800. [ 1572.589661] module_32: Location after: 4BE8. [ 1572.589723] module_32: ie. jump to 03E8+CADFC018 = CEDFC000 With the patch: [ 279.404671] module_32: Applying ADD relocate section 13 to 12 [ 279.404741] module_32: REL24 value = C00671B4. location = BF808024 [ 279.404814] module_32: Location before: 4801. [ 279.404874] module_32: Location after: 4885F191. [ 279.404933] module_32: ie. jump to 0085F190+BF808024 = C00671B4 [ 279.405016] module_32: Applying ADD relocate section 15 to 14 [ 279.405085] module_32: REL24 value = C00671B4. location = BF800018 [ 279.405156] module_32: Location before: 4800. [ 279.405215] module_32: Location after: 4886719C. [ 279.405275] module_32: ie. jump to 0086719C+BF800018 = C00671B4 Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/nohash/32/mmu-8xx.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/include/asm/nohash/32/mmu-8xx.h b/arch/powerpc/include/asm/nohash/32/mmu-8xx.h index 478249959baa..7902a42d6d3e 100644 --- a/arch/powerpc/include/asm/nohash/32/mmu-8xx.h +++ b/arch/powerpc/include/asm/nohash/32/mmu-8xx.h @@ -172,6 +172,9 @@ #define mmu_linear_psize MMU_PAGE_8M +#define MODULES_VADDR (PAGE_OFFSET - SZ_16M) +#define MODULES_ENDPAGE_OFFSET + #ifndef __ASSEMBLY__ #include -- 2.25.0
Re: [PATCH 16/17] auxdisplay: ht16k33: Add support for segment displays
Hello Geert,
On 2021-03-22 15:48, Geert Uytterhoeven wrote:
The Holtek HT16K33 LED controller is not only used for driving
dot-matrix displays, but also for driving segment displays.
Add support for 4-digit 7-segment and quad 14-segment alphanumeric
displays, like the Adafruit 7-segment and 14-segment display backpack
and FeatherWing expansion boards. Use the character line display core
support to display a message, which will be scrolled if it doesn't fit.
Signed-off-by: Geert Uytterhoeven
---
The 7-segment support is based on schematics, and untested on actual
hardware.
---
drivers/auxdisplay/ht16k33.c | 198 +--
1 file changed, 191 insertions(+), 7 deletions(-)
...
+static int ht16k33_seg_probe(struct i2c_client *client,
+struct ht16k33_priv *priv, uint32_t brightness)
+{
+ struct ht16k33_seg *seg = &priv->seg;
+ struct device *dev = &client->dev;
+ int err;
+
+ err = ht16k33_brightness_set(priv, MAX_BRIGHTNESS);
+ if (err)
+ return err;
+
+ switch (priv->type) {
+ case DISP_MATRIX:
+ /* not handled here */
+ break;
This 'case' shouldn't happen. Having said that, the break here will
still
cause the linedisp_register() function to be called for the DISP_MATRIX
type.
If you'd like to handle this case, a return (or setting 'err') should
prevent this.
+
+ case DISP_QUAD_7SEG:
+ INIT_DELAYED_WORK(&priv->work, ht16k33_seg7_update);
+ seg->map.seg7 = initial_map_seg7;
+ seg->map_size = sizeof(seg->map.seg7);
+ err = device_create_file(dev, &dev_attr_map_seg7);
+ break;
+
+ case DISP_QUAD_14SEG:
+ INIT_DELAYED_WORK(&priv->work, ht16k33_seg14_update);
+ seg->map.seg14 = initial_map_seg14;
+ seg->map_size = sizeof(seg->map.seg14);
+ err = device_create_file(dev, &dev_attr_map_seg14);
+ break;
+ }
+ if (err)
+ return err;
+
+ err = linedisp_register(&seg->linedisp, dev, 4, seg->curr,
+ ht16k33_linedisp_update);
+ if (err)
+ goto err_remove_map_file;
+
+ return 0;
Groetjes/Kind regards,
Robin van der Gracht
Re: [PATCH v2 05/20] drm/dp: Add backpointer to drm_device in drm_dp_aux
On Fri, Mar 26, 2021 at 04:37:52PM -0400, Lyude Paul wrote: > This is something that we've wanted for a while now: the ability to > actually look up the respective drm_device for a given drm_dp_aux struct. > This will also allow us to transition over to using the drm_dbg_*() helpers > for debug message printing, as we'll finally have a drm_device to reference > for doing so. > > Note that there is one limitation with this - because some DP AUX adapters > exist as platform devices which are initialized independently of their > respective DRM devices, one cannot rely on drm_dp_aux->drm_dev to always be > non-NULL until drm_dp_aux_register() has been called. We make sure to point > this out in the documentation for struct drm_dp_aux. > > Signed-off-by: Lyude Paul > --- [...] > drivers/gpu/drm/tegra/dpaux.c| 1 + [...] Acked-by: Thierry Reding signature.asc Description: PGP signature
[PATCH] perf vendor events: Add missing model numbers
Kernel has supported COMETLAKE/COMETLAKE_L to use the SKYLAKE events and supported TIGERLAKE_L/TIGERLAKE/ROCKETLAKE to use the ICELAKE events. But pmu-events mapfile.csv is missing these model numbers. Now add the missing model numbers to mapfile.csv. Signed-off-by: Jin Yao --- tools/perf/pmu-events/arch/x86/mapfile.csv | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/perf/pmu-events/arch/x86/mapfile.csv b/tools/perf/pmu-events/arch/x86/mapfile.csv index 2f2a209e87e1..6455f06f35d3 100644 --- a/tools/perf/pmu-events/arch/x86/mapfile.csv +++ b/tools/perf/pmu-events/arch/x86/mapfile.csv @@ -24,6 +24,7 @@ GenuineIntel-6-1F,v2,nehalemep,core GenuineIntel-6-1A,v2,nehalemep,core GenuineIntel-6-2E,v2,nehalemex,core GenuineIntel-6-[4589]E,v24,skylake,core +GenuineIntel-6-A[56],v24,skylake,core GenuineIntel-6-37,v13,silvermont,core GenuineIntel-6-4D,v13,silvermont,core GenuineIntel-6-4C,v13,silvermont,core @@ -35,6 +36,8 @@ GenuineIntel-6-55-[01234],v1,skylakex,core GenuineIntel-6-55-[56789ABCDEF],v1,cascadelakex,core GenuineIntel-6-7D,v1,icelake,core GenuineIntel-6-7E,v1,icelake,core +GenuineIntel-6-8[CD],v1,icelake,core +GenuineIntel-6-A7,v1,icelake,core GenuineIntel-6-86,v1,tremontx,core AuthenticAMD-23-([12][0-9A-F]|[0-9A-F]),v2,amdzen1,core AuthenticAMD-23-[[:xdigit:]]+,v1,amdzen2,core -- 2.17.1
Re: [PATCH] spi: dt-bindings: nvidia,tegra210-quad: Use documented compatible "jedec,spi-nor" in example
On Sat, Mar 27, 2021 at 03:33:57PM -0500, Rob Herring wrote: > The 'spi-nor' compatible used in the example is not documented. Use the > documented 'jedec,spi-nor' compatible instead. > > Cc: Mark Brown > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: linux-...@vger.kernel.org > Cc: linux-te...@vger.kernel.org > Signed-off-by: Rob Herring > --- > Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Thierry Reding signature.asc Description: PGP signature
Re: [PATCH][next] mlxsw: spectrum_router: remove redundant initialization of variable force
On Sat, Mar 27, 2021 at 10:33:34PM +, Colin King wrote:
> From: Colin Ian King
>
> The variable force is being initialized with a value that is
> never read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
> ---
> drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
> b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
> index 6ccaa194733b..ff240e3c29f7 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
> @@ -5059,7 +5059,7 @@ mlxsw_sp_nexthop_obj_bucket_adj_update(struct mlxsw_sp
> *mlxsw_sp,
> {
> u16 bucket_index = info->nh_res_bucket->bucket_index;
> struct netlink_ext_ack *extack = info->extack;
> - bool force = info->nh_res_bucket->force;
> + bool force;
Actually, there is a bug to be fixed here:
```
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 6ccaa194733b..41259c0004d1 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -5068,8 +5068,9 @@ mlxsw_sp_nexthop_obj_bucket_adj_update(struct mlxsw_sp
*mlxsw_sp,
/* No point in trying an atomic replacement if the idle timer interval
* is smaller than the interval in which we query and clear activity.
*/
- force = info->nh_res_bucket->idle_timer_ms <
- MLXSW_SP_NH_GRP_ACTIVITY_UPDATE_INTERVAL;
+ if (!force && info->nh_res_bucket->idle_timer_ms <
+ MLXSW_SP_NH_GRP_ACTIVITY_UPDATE_INTERVAL)
+ force = true;
adj_index = nh->nhgi->adj_index + bucket_index;
err = mlxsw_sp_nexthop_update(mlxsw_sp, adj_index, nh, force, ratr_pl);
```
We should only fallback to a non-atomic replacement when the current
replacement is atomic and the idle timer is too short.
We currently ignore the value of 'force'. This means that a non-atomic
replacement ('force' is true) can be made atomic if idle timer is larger
than 1 second.
Colin, do you mind if I submit it formally as a fix later this week? I
want to run it through our usual process. Will mention you in
Reported-by, obviously.
> char ratr_pl_new[MLXSW_REG_RATR_LEN];
> char ratr_pl[MLXSW_REG_RATR_LEN];
> u32 adj_index;
> --
> 2.30.2
>
Re: [PATCH 12/17] ASoC: tegra: tegra20_das: clarify expression
On Fri, Mar 26, 2021 at 04:59:22PM -0500, Pierre-Louis Bossart wrote: > cppcheck warning: > > sound/soc/tegra/tegra20_das.c:64:60: style: Boolean result is used in > bitwise operation. Clarify expression with > parentheses. [clarifyCondition] > reg = otherdap << TEGRA20_DAS_DAP_CTRL_SEL_DAP_CTRL_SEL_P | >^ > sound/soc/tegra/tegra20_das.c:65:61: style: Boolean result is used in > bitwise operation. Clarify expression with > parentheses. [clarifyCondition] > > !!sdata2rx << TEGRA20_DAS_DAP_CTRL_SEL_DAP_SDATA2_TX_RX_P | > ^ > sound/soc/tegra/tegra20_das.c:66:61: style: Boolean result is used in > bitwise operation. Clarify expression with > parentheses. [clarifyCondition] > !!sdata1rx << TEGRA20_DAS_DAP_CTRL_SEL_DAP_SDATA1_TX_RX_P | > ^ > > Signed-off-by: Pierre-Louis Bossart > --- > sound/soc/tegra/tegra20_das.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature
Re: [PATCH 13/17] ASoC: tegra: tegra20_das: align function prototypes
On Fri, Mar 26, 2021 at 04:59:23PM -0500, Pierre-Louis Bossart wrote: > cppcheck warnings: > > sound/soc/tegra/tegra20_das.c:35:40: style:inconclusive: Function > 'tegra20_das_connect_dap_to_dac' argument 1 names different: > declaration 'dap_id' definition 'dap'. [funcArgNamesDifferent] > > int tegra20_das_connect_dap_to_dac(int dap, int dac) >^ > sound/soc/tegra/tegra20_das.h:98:47: note: Function > 'tegra20_das_connect_dap_to_dac' argument 1 names different: > declaration 'dap_id' definition 'dap'. > extern int tegra20_das_connect_dap_to_dac(int dap_id, int dac_sel); > ^ > sound/soc/tegra/tegra20_das.c:35:40: note: Function > 'tegra20_das_connect_dap_to_dac' argument 1 names different: > declaration 'dap_id' definition 'dap'. > int tegra20_das_connect_dap_to_dac(int dap, int dac) >^ > sound/soc/tegra/tegra20_das.c:35:49: style:inconclusive: Function > 'tegra20_das_connect_dap_to_dac' argument 2 names different: > declaration 'dac_sel' definition 'dac'. [funcArgNamesDifferent] > int tegra20_das_connect_dap_to_dac(int dap, int dac) > ^ > sound/soc/tegra/tegra20_das.h:98:59: note: Function > 'tegra20_das_connect_dap_to_dac' argument 2 names different: > declaration 'dac_sel' definition 'dac'. > extern int tegra20_das_connect_dap_to_dac(int dap_id, int dac_sel); > ^ > sound/soc/tegra/tegra20_das.c:35:49: note: Function > 'tegra20_das_connect_dap_to_dac' argument 2 names different: declaration > 'dac_sel' definition 'dac'. > int tegra20_das_connect_dap_to_dac(int dap, int dac) > ^ > sound/soc/tegra/tegra20_das.c:53:40: style:inconclusive: Function > 'tegra20_das_connect_dap_to_dap' argument 1 names different: > declaration 'dap_id' definition 'dap'. [funcArgNamesDifferent] > int tegra20_das_connect_dap_to_dap(int dap, int otherdap, int master, >^ > sound/soc/tegra/tegra20_das.h:108:47: note: Function > 'tegra20_das_connect_dap_to_dap' argument 1 names different: > declaration 'dap_id' definition 'dap'. > extern int tegra20_das_connect_dap_to_dap(int dap_id, int other_dap_sel, > ^ > sound/soc/tegra/tegra20_das.c:53:40: note: Function > 'tegra20_das_connect_dap_to_dap' argument 1 names different: > declaration 'dap_id' definition 'dap'. > int tegra20_das_connect_dap_to_dap(int dap, int otherdap, int master, >^ > sound/soc/tegra/tegra20_das.c:53:49: style:inconclusive: Function > 'tegra20_das_connect_dap_to_dap' argument 2 names different: > declaration 'other_dap_sel' definition > 'otherdap'. [funcArgNamesDifferent] > int tegra20_das_connect_dap_to_dap(int dap, int otherdap, int master, > ^ > sound/soc/tegra/tegra20_das.h:108:59: note: Function > 'tegra20_das_connect_dap_to_dap' argument 2 names different: > declaration 'other_dap_sel' definition 'otherdap'. > extern int tegra20_das_connect_dap_to_dap(int dap_id, int other_dap_sel, > ^ > sound/soc/tegra/tegra20_das.c:53:49: note: Function > 'tegra20_das_connect_dap_to_dap' argument 2 names different: > declaration 'other_dap_sel' definition 'otherdap'. > int tegra20_das_connect_dap_to_dap(int dap, int otherdap, int master, > ^ > sound/soc/tegra/tegra20_das.c:75:40: style:inconclusive: Function > 'tegra20_das_connect_dac_to_dap' argument 1 names different: > declaration 'dac_id' definition 'dac'. [funcArgNamesDifferent] > int tegra20_das_connect_dac_to_dap(int dac, int dap) >^ > sound/soc/tegra/tegra20_das.h:118:47: note: Function > 'tegra20_das_connect_dac_to_dap' argument 1 names different: > declaration 'dac_id' definition 'dac'. > extern int tegra20_das_connect_dac_to_dap(int dac_id, int dap_sel); > ^ > sound/soc/tegra/tegra20_das.c:75:40: note: Function > 'tegra20_das_connect_dac_to_dap' argument 1 names different: > declaration 'dac_id' definition 'dac'. > int tegra20_das_connect_dac_to_dap(int dac, int dap) >^ > sound/soc/tegra/tegra20_das.c:75:49: style:inconclusive: Function > 'tegra20_das_connect_dac_to_dap' argument 2 names different: > declaration 'dap_sel' definition 'dap'. [funcArgNamesDifferent] > int tegra20_das_connect_dac_to_dap(int dac, int dap) > ^ > sound/soc/tegra/tegra20_das.h:118:59: note: Function > 'tegra20_das_connect_dac_to_dap' argument 2 names different: > declaration 'dap_sel' definition 'dap'. > extern int tegra20_das_connect_dac_to_dap(int dac_id, int dap_sel); >
Re: [PATCH 16/17] auxdisplay: ht16k33: Add support for segment displays
Hoi Robin,
On Mon, Mar 29, 2021 at 9:09 AM Robin van der Gracht wrote:
> On 2021-03-22 15:48, Geert Uytterhoeven wrote:
> > The Holtek HT16K33 LED controller is not only used for driving
> > dot-matrix displays, but also for driving segment displays.
> >
> > Add support for 4-digit 7-segment and quad 14-segment alphanumeric
> > displays, like the Adafruit 7-segment and 14-segment display backpack
> > and FeatherWing expansion boards. Use the character line display core
> > support to display a message, which will be scrolled if it doesn't fit.
> >
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > The 7-segment support is based on schematics, and untested on actual
> > hardware.
> > ---
> > drivers/auxdisplay/ht16k33.c | 198 +--
> > 1 file changed, 191 insertions(+), 7 deletions(-)
> >
> ...
> >
> > +static int ht16k33_seg_probe(struct i2c_client *client,
> > + struct ht16k33_priv *priv, uint32_t brightness)
> > +{
> > + struct ht16k33_seg *seg = &priv->seg;
> > + struct device *dev = &client->dev;
> > + int err;
> > +
> > + err = ht16k33_brightness_set(priv, MAX_BRIGHTNESS);
> > + if (err)
> > + return err;
> > +
> > + switch (priv->type) {
> > + case DISP_MATRIX:
> > + /* not handled here */
> > + break;
>
> This 'case' shouldn't happen. Having said that, the break here will
> still
> cause the linedisp_register() function to be called for the DISP_MATRIX
> type.
> If you'd like to handle this case, a return (or setting 'err') should
> prevent this.
This function is never called if priv->type == DISP_MATRIX, so this
cannot happen. However, gcc complains if not all enum values are
handled in a switch() statement, hence the dummy case.
Is there a better way to handle this?
> > + case DISP_QUAD_7SEG:
> > + INIT_DELAYED_WORK(&priv->work, ht16k33_seg7_update);
> > + seg->map.seg7 = initial_map_seg7;
> > + seg->map_size = sizeof(seg->map.seg7);
> > + err = device_create_file(dev, &dev_attr_map_seg7);
> > + break;
> > +
> > + case DISP_QUAD_14SEG:
> > + INIT_DELAYED_WORK(&priv->work, ht16k33_seg14_update);
> > + seg->map.seg14 = initial_map_seg14;
> > + seg->map_size = sizeof(seg->map.seg14);
> > + err = device_create_file(dev, &dev_attr_map_seg14);
> > + break;
> > + }
> > + if (err)
> > + return err;
> > +
> > + err = linedisp_register(&seg->linedisp, dev, 4, seg->curr,
> > + ht16k33_linedisp_update);
> > + if (err)
> > + goto err_remove_map_file;
> > +
> > + return 0;
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] MIPS: Loongson64: enable CONFIG_USB_SERIAL_PL2303
When using the Loongson-3A4000 machine for serial port debugging, there is no /dev/ttyUSB* output, which makes the serial port unavailable, For convenience, we open this configuration. zhangqing@loongson-pc:~$ cat /sys/firmware/lefi/boardinfo Board Info Manufacturer: THTF Board Name : THTF-LS3A4000-7A1000-ML4A Family : LOONGSON3 BIOS Info Vendor : ZD tech Version : ZD tech-V2.1.1 ROM Size: 4 KB Release Date: 2020-06-29 zhangqing@loongson-pc:~$ lsusb Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 003: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse Bus 005 Device 002: ID 0c45:760b Microdia USB Keyboard Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Signed-off-by: Qing Zhang --- arch/mips/configs/loongson3_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig index 77f6a3551f46..a18609cf0e5e 100644 --- a/arch/mips/configs/loongson3_defconfig +++ b/arch/mips/configs/loongson3_defconfig @@ -320,6 +320,7 @@ CONFIG_USB_OHCI_HCD=y CONFIG_USB_UHCI_HCD=m CONFIG_USB_STORAGE=m CONFIG_USB_SERIAL=m +CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_OPTION=m CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_CMOS=y -- 2.31.0
[PATCH] locking/mutex: initialize osq lock in __MUTEX_INITIALIZER()
Since __MUTEX_INITIALIZER() is used on memory that is initialized to 0
anyway this change should not have an effect, but it seems better to
initialize osq explicitly for completeness, as done in other macros and
functions that initialize mutex and rwsem.
Signed-off-by: Nikitas Angelinas
---
include/linux/mutex.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 515cff7..bff47f8 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -129,10 +129,18 @@ do {
\
# define __DEP_MAP_MUTEX_INITIALIZER(lockname)
#endif
+#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
+# define __OSQ_MUTEX_INITIALIZER(lockname) \
+ , .osq = OSQ_LOCK_UNLOCKED
+#else
+# define __OSQ_MUTEX_INITIALIZER(lockname)
+#endif
+
#define __MUTEX_INITIALIZER(lockname) \
{ .owner = ATOMIC_LONG_INIT(0) \
, .wait_lock = __SPIN_LOCK_UNLOCKED(lockname.wait_lock) \
, .wait_list = LIST_HEAD_INIT(lockname.wait_list) \
+ __OSQ_MUTEX_INITIALIZER(lockname) \
__DEBUG_MUTEX_INITIALIZER(lockname) \
__DEP_MAP_MUTEX_INITIALIZER(lockname) }
--
2.10.0
Re: [PATCH 0/3] iio: adc: ad7923: convert driver resources routines to device-managed counterparts
On Mon, Mar 29, 2021 at 12:48 AM Lucas Stankus wrote: > > Following the initiative proposed by Alexandru, this patch series aims > to convert the ad7923 to use only device-managed routines. > This idea is becoming popular it seems :) Thanks to Lars for pointing out that spi_set_drvdata() omission. With that fixed: Reviewed-by: Alexandru Ardelean If you want, you can also search for more of these xxx_set_drvdata() omissions. There were more conversions to devm_ that forgot to remove those. Maybe a cocci script would be nice to find them. But all this is optional. Only if you want. > Part of the driver was already using devm_ functions, so it was possible > to convert the remainder of it without much hassle. > > With that, the deregistration function was no longer necessary and could > be entirely removed from the driver. > > Lucas Stankus (3): > iio: adc: ad7923: use devm_add_action_or_reset for regulator disable > iio: adc: ad7923: use device-managed function for triggered buffer > iio: adc: ad7923: register device with devm_iio_device_register > > drivers/iio/adc/ad7923.c | 39 +-- > 1 file changed, 13 insertions(+), 26 deletions(-) > > -- > 2.31.0 >
Re: drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c:2267:16: warning: taking address of packed member 'hw_tx_obj' of class or structure 'mcp251xfd_tx_obj_load_buf::(anonymous)' may result in an unalign
On 27.03.2021 18:16:14, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 0f4498cef9f5cd18d7c6639a2a902ec1edc5be4e
> commit: eb79a267c9b3e608e7762a1b221428f37ace3aa3 can: mcp251xfd: rename all
> remaining occurrence to mcp251xfd
> date: 6 months ago
> config: mips-randconfig-r035-20210327 (attached as .config)
> compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
> d50fe9f0d6b9ee61df8830a67ea0a33c27a637e7)
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install mips cross compiling tool for clang build
> # apt-get install binutils-mips-linux-gnu
> #
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eb79a267c9b3e608e7762a1b221428f37ace3aa3
> git remote add linus
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git fetch --no-tags linus master
> git checkout eb79a267c9b3e608e7762a1b221428f37ace3aa3
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
> All warnings (new ones prefixed by >>):
[...]
> >> drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c:2267:16: warning: taking
> >> address of packed member 'hw_tx_obj' of class or structure
> >> 'mcp251xfd_tx_obj_load_buf::(anonymous)' may result in an unaligned
> >> pointer value [-Waddress-of-packed-member]
>hw_tx_obj = &load_buf->crc.hw_tx_obj;
> ^~~
>drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c:2269:16: warning: taking
> address of packed member 'hw_tx_obj' of class or structure
> 'mcp251xfd_tx_obj_load_buf::(anonymous)' may result in an unaligned pointer
> value [-Waddress-of-packed-member]
>hw_tx_obj = &load_buf->nocrc.hw_tx_obj;
> ^
>4 warnings and 1 error generated.
That warning is technically correct, hw_tx_obj is an unaligned pointer in
the first warning, but...
> vim +2267 drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
>
> 55e5b97f003e85 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c Marc
> Kleine-Budde 2020-09-18 2215 static void
> eb79a267c9b3e6 drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c Marc
> Kleine-Budde 2020-09-30 2216 mcp251xfd_tx_obj_from_skb(const struct
> mcp251xfd_priv *priv,
> eb79a267c9b3e6 drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c Marc
> Kleine-Budde 2020-09-30 2217struct mcp251xfd_tx_obj
> *tx_obj,
> 55e5b97f003e85 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c Marc
> Kleine-Budde 2020-09-18 2218const struct sk_buff
> *skb,
> 55e5b97f003e85 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c Marc
> Kleine-Budde 2020-09-18 2219unsigned int seq)
> 55e5b97f003e85 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c Marc
> Kleine-Budde 2020-09-18 2220 {
[...]
> 55e5b97f003e85 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c Marc
> Kleine-Budde 2020-09-18 2265 load_buf = &tx_obj->buf;
> eb79a267c9b3e6 drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c Marc
> Kleine-Budde 2020-09-30 2266 if (priv->devtype_data.quirks &
> MCP251XFD_QUIRK_CRC_TX)
> 55e5b97f003e85 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c Marc
> Kleine-Budde 2020-09-18 @2267 hw_tx_obj =
> &load_buf->crc.hw_tx_obj;
> 55e5b97f003e85 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c Marc
> Kleine-Budde 2020-09-18 2268 else
> 55e5b97f003e85 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c Marc
> Kleine-Budde 2020-09-18 2269 hw_tx_obj =
> &load_buf->nocrc.hw_tx_obj;
> 55e5b97f003e85 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c Marc
> Kleine-Budde 2020-09-18 2270
> 55e5b97f003e85 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c Marc
> Kleine-Budde 2020-09-18 2271 put_unaligned_le32(id, &hw_tx_obj->id);
> 55e5b97f003e85 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c Marc
> Kleine-Budde 2020-09-18 2272 put_unaligned_le32(flags,
> &hw_tx_obj->flags);
> 55e5b97f003e85 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c Marc
> Kleine-Budde 2020-09-18 2273
> 55e5b97f003e85 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c Marc
> Kleine-Budde 2020-09-18 2274 /* Clear data at end of CAN frame */
> 55e5b97f003e85 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c Marc
> Kleine-Budde 2020-09-18 2275 offset = round_down(cfd->len, sizeof(u32));
> 55e5b97f003e85 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c Marc
> Kleine-Budde 2020-09-18 2276 len = round_up(can_dlc2len(dlc),
> sizeof(u32)) - offset;
> eb79a267c9b3e6 drivers/net/can/spi/mcp251xfd/mcp251
Re: [kbuild-all] Re: include/linux/compiler_types.h:315:38: error: call to '__compiletime_assert_536' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct can_frame, len) != offsetof(st
On 23.03.2021 15:00:55, Rasmus Villemoes wrote: [...] > So let us guess that it's the ABI choice -mabi=apcs-gnu > > $ arm-linux-gnueabihf-gcc -O2 -msoft-float -mabi=apcs-gnu -Q > --help=target | grep struct > -mstructure-size-boundary=32 > > Bingo. (-msoft-float is also included just as in the real command line > because gcc barfs otherwise). > > Now what CONFIG_* knobs are responsible for putting -mabi=apcs-gnu in > CFLAGS is left as an exercise for the reader. Regardless, it is not a > bug in the compiler. The error is the assumption that this language For the record: If CONFIG_AEABI is not set "-mabi=apcs-gnu" is used, which leads to the bigger structure size boundary. | ifeq ($(CONFIG_AEABI),y) | CFLAGS_ABI :=-mabi=aapcs-linux -mfpu=vfp | else | CFLAGS_ABI :=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) $(call cc-option,-mno-thumb-interwork,) | endif regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: PGP signature
[PATCH v3 2/4] dt-bindings: usb: mtk-xhci: remove redefinitions of usb3-lpm-capable
The property usb3-lpm-capable is defined in usb-xhci.yaml which is already referenced in this file, so no need 'description' and 'type' anymore. Signed-off-by: Chunfeng Yun --- v3: new patch --- Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml index 291749f49f35..69c3e7d0f9dd 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml @@ -100,9 +100,7 @@ properties: vbus-supply: description: Regulator of USB VBUS5v - usb3-lpm-capable: -description: supports USB3.0 LPM -type: boolean + usb3-lpm-capable: true usb2-lpm-disable: true -- 2.18.0
[PATCH v3 1/4] dt-bindings: usb: mtk-xhci: support property usb2-lpm-disable
Add support common property usb2-lpm-disable Signed-off-by: Chunfeng Yun --- v3: remove redefinition of type and description suggested by Rob v2: no changes --- Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml index 45bf4ea00c9e..291749f49f35 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml @@ -104,6 +104,8 @@ properties: description: supports USB3.0 LPM type: boolean + usb2-lpm-disable: true + imod-interval-ns: description: Interrupt moderation interval value, it is 8 times as much as that -- 2.18.0
[PATCH v3 4/4] usb: xhci-mtk: support quirk to disable usb2 lpm
The xHCI driver support usb2 HW LPM by default, here add support
XHCI_HW_LPM_DISABLE quirk, then we can disable usb2 lpm when
need it.
Signed-off-by: Chunfeng Yun
---
v2~3: no changes
---
drivers/usb/host/xhci-mtk.c | 3 +++
drivers/usb/host/xhci-mtk.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 4e3d53cc24f4..744639d23fa8 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -411,6 +411,8 @@ static void xhci_mtk_quirks(struct device *dev, struct
xhci_hcd *xhci)
xhci->quirks |= XHCI_SPURIOUS_SUCCESS;
if (mtk->lpm_support)
xhci->quirks |= XHCI_LPM_SUPPORT;
+ if (mtk->u2_lpm_disable)
+ xhci->quirks |= XHCI_HW_LPM_DISABLE;
/*
* MTK xHCI 0.96: PSA is 1 by default even if doesn't support stream,
@@ -493,6 +495,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
return ret;
mtk->lpm_support = of_property_read_bool(node, "usb3-lpm-capable");
+ mtk->u2_lpm_disable = of_property_read_bool(node, "usb2-lpm-disable");
/* optional property, ignore the error if it does not exist */
of_property_read_u32(node, "mediatek,u3p-dis-msk",
&mtk->u3p_dis_msk);
diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
index 621ec1a85009..4ccd08e20a15 100644
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -149,6 +149,7 @@ struct xhci_hcd_mtk {
struct phy **phys;
int num_phys;
bool lpm_support;
+ bool u2_lpm_disable;
/* usb remote wakeup */
bool uwk_en;
struct regmap *uwk;
--
2.18.0
[PATCH v3 3/4] usb: xhci-mtk: fix broken streams issue on 0.96 xHCI
The MediaTek 0.96 xHCI controller on some platforms does not
support bulk stream even HCCPARAMS says supporting, due to MaxPSASize
is set a default value 1 by mistake, here use XHCI_BROKEN_STREAMS
quirk to fix it.
Fixes: 94a631d91ad3 ("usb: xhci-mtk: check hcc_params after adding primary hcd")
Signed-off-by: Chunfeng Yun
---
v2~3: no changes
---
drivers/usb/host/xhci-mtk.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index c1bc40289833..4e3d53cc24f4 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -411,6 +411,13 @@ static void xhci_mtk_quirks(struct device *dev, struct
xhci_hcd *xhci)
xhci->quirks |= XHCI_SPURIOUS_SUCCESS;
if (mtk->lpm_support)
xhci->quirks |= XHCI_LPM_SUPPORT;
+
+ /*
+* MTK xHCI 0.96: PSA is 1 by default even if doesn't support stream,
+* and it's 3 when support it.
+*/
+ if (xhci->hci_version < 0x100 && HCC_MAX_PSA(xhci->hcc_params) == 4)
+ xhci->quirks |= XHCI_BROKEN_STREAMS;
}
/* called during probe() after chip reset completes */
@@ -572,7 +579,8 @@ static int xhci_mtk_probe(struct platform_device *pdev)
if (ret)
goto put_usb3_hcd;
- if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
+ if (HCC_MAX_PSA(xhci->hcc_params) >= 4 &&
+ !(xhci->quirks & XHCI_BROKEN_STREAMS))
xhci->shared_hcd->can_do_streams = 1;
ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
--
2.18.0
Re: [PATCH] xen/pciback: Fix incorrect type warnings
On 26.03.21 19:14, Muhammad Usama Anjum wrote: Correct enum pci_channel_io_normal should be used instead of putting integer value 1. Fix following smatch warnings: drivers/xen/xen-pciback/pci_stub.c:805:40: warning: incorrect type in argument 2 (different base types) drivers/xen/xen-pciback/pci_stub.c:805:40:expected restricted pci_channel_state_t [usertype] state drivers/xen/xen-pciback/pci_stub.c:805:40:got int drivers/xen/xen-pciback/pci_stub.c:862:40: warning: incorrect type in argument 2 (different base types) drivers/xen/xen-pciback/pci_stub.c:862:40:expected restricted pci_channel_state_t [usertype] state drivers/xen/xen-pciback/pci_stub.c:862:40:got int drivers/xen/xen-pciback/pci_stub.c:973:31: warning: incorrect type in argument 2 (different base types) drivers/xen/xen-pciback/pci_stub.c:973:31:expected restricted pci_channel_state_t [usertype] state drivers/xen/xen-pciback/pci_stub.c:973:31:got int Signed-off-by: Muhammad Usama Anjum Reviewed-by: Juergen Gross Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] move_mount: allow to add a mount into an existing group
On 3/29/21 12:47 AM, Andrei Vagin wrote:
On Thu, Mar 25, 2021 at 03:14:44PM +0300, Pavel Tikhomirov wrote:
Previously a sharing group (shared and master ids pair) can be only
inherited when mount is created via bindmount. This patch adds an
ability to add an existing private mount into an existing sharing group.
With this functionality one can first create the desired mount tree from
only private mounts (without the need to care about undesired mount
propagation or mount creation order implied by sharing group
dependencies), and next then setup any desired mount sharing between
those mounts in tree as needed.
This allows CRIU to restore any set of mount namespaces, mount trees and
sharing group trees for a container.
We have many issues with restoring mounts in CRIU related to sharing
groups and propagation:
- reverse sharing groups vs mount tree order requires complex mounts
reordering which mostly implies also using some temporary mounts
(please see https://lkml.org/lkml/2021/3/23/569 for more info)
- mount() syscall creates tons of mounts due to propagation
- mount re-parenting due to propagation
- "Mount Trap" due to propagation
- "Non Uniform" propagation, meaning that with different tricks with
mount order and temporary children-"lock" mounts one can create mount
trees which can't be restored without those tricks
(see https://www.linuxplumbersconf.org/event/7/contributions/640/)
With this new functionality we can resolve all the problems with
propagation at once.
Thanks for picking this up. Overall it looks good for me. Here is one
comment inline.
Cc: Eric W. Biederman
Cc: Alexander Viro
Cc: Andrei Vagin
Cc: linux-fsde...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: lkml
Signed-off-by: Pavel Tikhomirov
---
This is a rework of "mnt: allow to add a mount into an existing group"
patch from Andrei. https://lkml.org/lkml/2017/4/28/20
New do_set_group is similar to do_move_mount, but with many restrictions
of do_move_mount removed and that's why:
1) Allow "cross-namespace" sharing group set. If we allow operation only
with mounts from current+anon mount namespace one would still be able to
setns(from_mntns) + open_tree(from, OPEN_TREE_CLONE) + setns(to_mntns) +
move_mount(anon, to, MOVE_MOUNT_SET_GROUP) to set sharing group to mount
in different mount namespace with source mount. But with this approach
we would need to create anon mount namespace and mount copy each time,
which is just a waste of resources. So instead lets just check if we are
allowed to modify both mount namespaces (which looks equivalent to what
setns-es and open_tree check).
2) Allow operating on non-root dentry of the mount. As if we prohibit it
this would require extra care from CRIU side in places where we wan't to
copy sharing group from mount on host (for external mounts) and user
gives us path to non-root dentry. I don't see any problem with
referencing mount with any dentry for sharing group setting. Also there
is no problem with referencing one by file and one by directory.
3) Also checks wich only apply to actually moving mount which we have in
do_move_mount and open_tree are skipped. We don't need to check
MNT_LOCKED, unbindable, nsfs loops and ancestor relation as we don't
move mounts.
Security note: there would be no (new) loops in sharing groups tree,
because this new move_mount(MOVE_MOUNT_SET_GROUP) operation only adds
one _private_ mount to one group (without moving between groups), the
sharing groups tree itself stays unchanged after it.
In Virtuozzo we have "mount-v2" implementation, based with the original
kernel patch from Andrei, tested for almost a year and it actually
decreased number of bugs with mounts a lot. One can take a look on the
implementation of sharing group restore in CRIU in "mount-v2" here:
https://src.openvz.org/projects/OVZ/repos/criu/browse/criu/mount-v2.c#898
This works almost the same with current version of patch if we replace
mount(MS_SET_GROUP) to move_mount(MOVE_MOUNT_SET_GROUP), please see
super-draft port for mainstream criu, this at least passes
non-user-namespaced mount tests (zdtm.py --mounts-v2 -f ns).
https://github.com/Snorch/criu/commits/mount-v2-poc
---
fs/namespace.c | 57 +-
include/uapi/linux/mount.h | 3 +-
2 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index 9d33909d0f9e..ab439d8510dd 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2660,6 +2660,58 @@ static bool check_for_nsfs_mounts(struct mount *subtree)
return ret;
}
+static int do_set_group(struct path *from_path, struct path *to_path)
+{
+ struct mount *from, *to;
+ int err;
+
+ from = real_mount(from_path->mnt);
+ to = real_mount(to_path->mnt);
+
+ namespace_lock();
+
+ err = -EINVAL;
+ /* To and From must be mounted */
+ if (!is_mounted(&from->mnt))
+ goto out;
+ if (!is_mounted(&to->mnt))
Re: linux-next: build failure after merge of the staging tree
On Mon, 29 Mar 2021 at 09:15, Greg KH wrote:
>
> On Mon, Mar 29, 2021 at 04:55:25PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the staging tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/iio/adc/ti-ads131e08.c: In function 'ads131e08_read_reg':
> > drivers/iio/adc/ti-ads131e08.c:180:5: error: 'struct spi_transfer' has no
> > member named 'delay_usecs'
> > 180 |.delay_usecs = st->sdecode_delay_us,
> > | ^~~
> > drivers/iio/adc/ti-ads131e08.c: In function 'ads131e08_write_reg':
> > drivers/iio/adc/ti-ads131e08.c:206:5: error: 'struct spi_transfer' has no
> > member named 'delay_usecs'
> > 206 |.delay_usecs = st->sdecode_delay_us,
> > | ^~~
> >
> > Caused by commit
> >
> > d935eddd2799 ("iio: adc: Add driver for Texas Instruments ADS131E0x ADC
> > family")
> >
> > interacting with commit
> >
> > 3ab1cce55337 ("spi: core: remove 'delay_usecs' field from spi_transfer")
> >
> > from the spi tree.
> >
> > I have applied the following merge fix patch.
> >
> > From: Stephen Rothwell
> > Date: Mon, 29 Mar 2021 16:51:22 +1100
> > Subject: [PATCH] iio: adc: merge fix for "spi: core: remove 'delay_usecs'
> > field from spi_transfer"
> >
Reviewed-by: Alexandru Ardelean
> > Signed-off-by: Stephen Rothwell
> > ---
> > drivers/iio/adc/ti-ads131e08.c | 10 --
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iio/adc/ti-ads131e08.c b/drivers/iio/adc/ti-ads131e08.c
> > index 0060d5f0abb0..764dab087b41 100644
> > --- a/drivers/iio/adc/ti-ads131e08.c
> > +++ b/drivers/iio/adc/ti-ads131e08.c
> > @@ -177,7 +177,10 @@ static int ads131e08_read_reg(struct ads131e08_state
> > *st, u8 reg)
> > {
> > .tx_buf = &st->tx_buf,
> > .len = 2,
> > - .delay_usecs = st->sdecode_delay_us,
> > + .delay = {
> > + .value = st->sdecode_delay_us,
> > + .unit = SPI_DELAY_UNIT_USECS,
> > + },
> > }, {
> > .rx_buf = &st->rx_buf,
> > .len = 1,
> > @@ -203,7 +206,10 @@ static int ads131e08_write_reg(struct ads131e08_state
> > *st, u8 reg, u8 value)
> > {
> > .tx_buf = &st->tx_buf,
> > .len = 3,
> > - .delay_usecs = st->sdecode_delay_us,
> > + .delay = {
> > + .value = st->sdecode_delay_us,
> > + .unit = SPI_DELAY_UNIT_USECS,
> > + },
> > }
> > };
> >
> > --
> > 2.30.0
> >
>
> Thanks for the fix, looks correct to me.
>
> greg k-h
Re: Candidate Linux ABI for Intel AMX and hypothetical new related features
On Sun, Mar 28, 2021 at 01:53:15AM +0100, Thomas Gleixner wrote: > Though the little devil in my head tells me, that making AMX support > depend on the CPUID faulting capability might be not the worst thing. > > Then we actually enforce CPUID faulting (finally) on CPUs which support > it, which would be a first step into the right direction simply because > then random library X has to go to the kernel and ask for it explicitely > or just shrug and use whatever the kernel is willing to hand out in > CPUID. > > Now take that one step further. When the first part of some user space > application asks for it, then you can register that with the process and > make sane decisions for all other requesters which come after it, which > is an important step into the direction of having a common orchestration > for this. I wrote something like that at least one... https://lore.kernel.org/lkml/20190212164833.gk32...@hirez.programming.kicks-ass.net/ we just need to make sure AMD implements that before it ships a chip with AVX512 on.
[PATCH 1/2] dt-bindings: usb: dwc3-imx8mp: Use the correct name for child node "snps,dwc3"
File snps,dwc3.yaml describes the schema of Synopsys DesignWare USB3
Controller, it directly or indirectly contains "$ref: usb.yaml". So the
node name of "snps,dwc3" must start with "usb". Otherwise, the following
warning will be displayed:
Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.example.dt.yaml: \
dwc3@3810: $nodename:0: 'dwc3@3810' does not match '^usb(@.*)?'
From schema: Documentation/devicetree/bindings/usb/snps,dwc3.yaml
In addition, replace "type: object" with "$ref: snps,dwc3.yaml#". Ensure
that all properties of the child node comply with snps,dwc3.yaml.
Signed-off-by: Zhen Lei
---
Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
index cb4c6f6d3a33a3f..974032b1fda04fb 100644
--- a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
@@ -52,11 +52,8 @@ properties:
# Required child node:
patternProperties:
- "^dwc3@[0-9a-f]+$":
-type: object
-description:
- A child node must exist to represent the core DWC3 IP block
- The content of the node is defined in dwc3.txt.
+ "^usb@[0-9a-f]+$":
+$ref: snps,dwc3.yaml#
required:
- compatible
@@ -87,7 +84,7 @@ examples:
dma-ranges = <0x4000 0x4000 0xc000>;
ranges;
- dwc3@3810 {
+ usb@3810 {
compatible = "snps,dwc3";
reg = <0x3810 0x1>;
clocks = <&clk IMX8MP_CLK_HSIO_AXI>,
--
1.8.3
[PATCH 0/2] dt-bindings: usb: dwc3-imx8mp: Use the correct name for child node "snps,dwc3"
File snps,dwc3.yaml describes the schema of Synopsys DesignWare USB3 Controller, it directly or indirectly contains "$ref: usb.yaml". So the node name of "snps,dwc3" must start with "usb". Otherwise, the following warning will be displayed: Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.example.dt.yaml: \ dwc3@3810: $nodename:0: 'dwc3@3810' does not match '^usb(@.*)?' From schema: Documentation/devicetree/bindings/usb/snps,dwc3.yaml Zhen Lei (2): dt-bindings: usb: dwc3-imx8mp: Use the correct name for child node "snps,dwc3" arm64: dts: imx8mp: Use the correct name for child node "snps,dwc3" Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml | 9 +++-- arch/arm64/boot/dts/freescale/imx8mp.dtsi | 4 ++-- 2 files changed, 5 insertions(+), 8 deletions(-) -- 1.8.3
[PATCH 2/2] arm64: dts: imx8mp: Use the correct name for child node "snps,dwc3"
After the node name of "snps,dwc3" has been corrected to start with "usb"
in fsl,imx8mp-dwc3.yaml. Its name in dts should be modified accordingly.
Signed-off-by: Zhen Lei
---
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index c7523fd4eae9b53..4967d72f41f613f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -828,7 +828,7 @@
ranges;
status = "disabled";
- usb_dwc3_0: dwc3@3810 {
+ usb_dwc3_0: usb@3810 {
compatible = "snps,dwc3";
reg = <0x3810 0x1>;
clocks = <&clk IMX8MP_CLK_HSIO_AXI>,
@@ -869,7 +869,7 @@
ranges;
status = "disabled";
- usb_dwc3_1: dwc3@3820 {
+ usb_dwc3_1: usb@3820 {
compatible = "snps,dwc3";
reg = <0x3820 0x1>;
clocks = <&clk IMX8MP_CLK_HSIO_AXI>,
--
1.8.3
Re: [PATCH 16/17] auxdisplay: ht16k33: Add support for segment displays
On 2021-03-29 09:15, Geert Uytterhoeven wrote:
Hoi Robin,
On Mon, Mar 29, 2021 at 9:09 AM Robin van der Gracht
wrote:
On 2021-03-22 15:48, Geert Uytterhoeven wrote:
> The Holtek HT16K33 LED controller is not only used for driving
> dot-matrix displays, but also for driving segment displays.
>
> Add support for 4-digit 7-segment and quad 14-segment alphanumeric
> displays, like the Adafruit 7-segment and 14-segment display backpack
> and FeatherWing expansion boards. Use the character line display core
> support to display a message, which will be scrolled if it doesn't fit.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> The 7-segment support is based on schematics, and untested on actual
> hardware.
> ---
> drivers/auxdisplay/ht16k33.c | 198 +--
> 1 file changed, 191 insertions(+), 7 deletions(-)
>
...
>
> +static int ht16k33_seg_probe(struct i2c_client *client,
> + struct ht16k33_priv *priv, uint32_t brightness)
> +{
> + struct ht16k33_seg *seg = &priv->seg;
> + struct device *dev = &client->dev;
> + int err;
> +
> + err = ht16k33_brightness_set(priv, MAX_BRIGHTNESS);
> + if (err)
> + return err;
> +
> + switch (priv->type) {
> + case DISP_MATRIX:
> + /* not handled here */
> + break;
This 'case' shouldn't happen. Having said that, the break here will
still
cause the linedisp_register() function to be called for the
DISP_MATRIX
type.
If you'd like to handle this case, a return (or setting 'err') should
prevent this.
This function is never called if priv->type == DISP_MATRIX, so this
cannot happen. However, gcc complains if not all enum values are
handled in a switch() statement, hence the dummy case.
I see. But if it's there it should work right? :P
Is there a better way to handle this?
How about adding the default case:
default:
/* not handled */
err = -EINVAL;
Groetjes/Kind regards,
Robin van der Gracht
--
Protonic Holland
Factorij 36
1689AL Zwaag
+31 (0)229 212928
https://www.protonic.nl
[PATCH v5 3/3] iio: adc: add ADC driver for the TI TSC2046 controller
Basically the TI TSC2046 touchscreen controller is 8 channel ADC optimized for the touchscreen use case. By implementing it as an IIO ADC device, we can make use of resistive-adc-touch and iio-hwmon drivers. Polled readings are currently not implemented to keep this patch small, so iio-hwmon will not work out of the box for now. So far, this driver was tested with a custom version of resistive-adc-touch driver, since it needs to be extended to make use of Z1 and Z2 channels. The X/Y are working without additional changes. Signed-off-by: Oleksij Rempel Reviewed-by: Andy Shevchenko --- MAINTAINERS | 8 + drivers/iio/adc/Kconfig | 12 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/ti-tsc2046.c | 726 +++ 4 files changed, 747 insertions(+) create mode 100644 drivers/iio/adc/ti-tsc2046.c diff --git a/MAINTAINERS b/MAINTAINERS index 9a9bf18bba00..e288fae26cde 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -18013,6 +18013,14 @@ S: Supported F: Documentation/devicetree/bindings/net/nfc/trf7970a.txt F: drivers/nfc/trf7970a.c +TI TSC2046 ADC DRIVER +M: Oleksij Rempel +R: ker...@pengutronix.de +L: linux-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml +F: drivers/iio/adc/ti-tsc2046.c + TI TWL4030 SERIES SOC CODEC DRIVER M: Peter Ujfalusi L: alsa-de...@alsa-project.org (moderated for non-subscribers) diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index 769381b05b9a..6fe8d1046b4b 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -1188,6 +1188,18 @@ config TI_TLC4541 This driver can also be built as a module. If so, the module will be called ti-tlc4541. +config TI_TSC2046 + tristate "Texas Instruments TSC2046 ADC driver" + depends on SPI + select IIO_BUFFER + select IIO_TRIGGERED_BUFFER + help + Say yes here to build support for ADC functionality of Texas + Instruments TSC2046 touch screen controller. + + This driver can also be built as a module. If so, the module will be + called ti-tsc2046. + config TWL4030_MADC tristate "TWL4030 MADC (Monitoring A/D Converter)" depends on TWL4030_CORE diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index a226657d19c0..f70d877c555a 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -106,6 +106,7 @@ obj-$(CONFIG_TI_ADS124S08) += ti-ads124s08.o obj-$(CONFIG_TI_ADS131E08) += ti-ads131e08.o obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o obj-$(CONFIG_TI_TLC4541) += ti-tlc4541.o +obj-$(CONFIG_TI_TSC2046) += ti-tsc2046.o obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o obj-$(CONFIG_VF610_ADC) += vf610_adc.o diff --git a/drivers/iio/adc/ti-tsc2046.c b/drivers/iio/adc/ti-tsc2046.c new file mode 100644 index ..7fe3c677ab1c --- /dev/null +++ b/drivers/iio/adc/ti-tsc2046.c @@ -0,0 +1,726 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Texas Instruments TSC2046 SPI ADC driver + * + * Copyright (c) 2021 Oleksij Rempel , Pengutronix + */ + +#include +#include +#include +#include + +#include + +#include +#include +#include +#include + +/* + * The PENIRQ of TSC2046 controller is implemented as level shifter attached to + * the X+ line. If voltage of the X+ line reaches a specific level the IRQ will + * be activated or deactivated. + * To make this kind of IRQ reusable as trigger following additions were + * implemented: + * - rate limiting: + * For typical touchscreen use case, we need to trigger about each 10ms. + * - hrtimer: + * Continue triggering at least once after the IRQ was deactivated. Then + * deactivate this trigger to stop sampling in order to reduce power + * consumption. + */ + +#define TI_TSC2046_NAME"tsc2046" + +/* This driver doesn't aim at the peak continuous sample rate */ +#defineTI_TSC2046_MAX_SAMPLE_RATE 125000 +#defineTI_TSC2046_SAMPLE_BITS \ + BITS_PER_TYPE(struct tsc2046_adc_atom) +#defineTI_TSC2046_MAX_CLK_FREQ \ + (TI_TSC2046_MAX_SAMPLE_RATE * TI_TSC2046_SAMPLE_BITS) + +#define TI_TSC2046_SAMPLE_INTERVAL_US 1 + +#define TI_TSC2046_START BIT(7) +#define TI_TSC2046_ADDRGENMASK(6, 4) +#define TI_TSC2046_ADDR_TEMP1 7 +#define TI_TSC2046_ADDR_AUX6 +#define TI_TSC2046_ADDR_X 5 +#define TI_TSC2046_ADDR_Z2 4 +#define TI_TSC2046_ADDR_Z1 3 +#define TI_TSC2046_ADDR_VBAT 2 +#define TI_TSC2046_ADDR_Y 1 +#define TI_TSC2046_ADDR_TEMP0 0 + +/* + * The mode bit sets the resolution of the ADC. With this bit low, the next + * conversion has 12-bit resolution, whereas with thi
[PATCH v5 0/3] mainline ti tsc2046 adc driver
changes v5: - remove type for the settling-time-us property changes v4: - spell fixes - add more comments - make code more readable - move scan_buf to the priv - use FIELD_GET to extract ADC data - make some multi line code as one line - do not use atomic API for trig_more_count - fix build warning on 64bit system - add NULL check for the devm_kasprintf() - use return devm_iio_device_register(), without additional error printing. changes v3: - different spell fixes - add some notes about driver structure - rename the trigger to point on the touchscreen nature of it - rename DT binding to oversampling-ratio - make sure we have some defaults in case no DT property is set changes v2: - rework and extend DT binding properties - remove touchscreen related code from the IIO ADC driver - make trigger be active longer then IRQ is requesting. This is needed to get "inactive" samples - make oversampling and settle time configurable TI TSC2046 is a touchscreen controller based on 8 channel ADC. Since most of this ADC based touchscreen controller share same set of challenges, it is better keep then as simple IIO ADC devices attached to a generic resistive-adc-touch driver. This driver can replace drivers/input/touchscreen/ads7846.c and has following advantages over it: - less code to maintain - shared code paths (resistive-adc-touch, iio-hwmon, etc) - can be used as plain IIO ADC to investigate signaling issues or test real capacity of the plates and attached low-pass filters (or use the touchscreen as a microphone if you like ;) ) Oleksij Rempel (3): dt-bindings:iio:adc: add generic settling-time-us and oversampling-ratio channel properties dt-bindings:iio:adc: add documentation for TI TSC2046 controller iio: adc: add ADC driver for the TI TSC2046 controller .../devicetree/bindings/iio/adc/adc.yaml | 8 + .../bindings/iio/adc/ti,tsc2046.yaml | 115 +++ MAINTAINERS | 8 + drivers/iio/adc/Kconfig | 12 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/ti-tsc2046.c | 726 ++ 6 files changed, 870 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml create mode 100644 drivers/iio/adc/ti-tsc2046.c -- 2.29.2
[PATCH v5 2/3] dt-bindings:iio:adc: add documentation for TI TSC2046 controller
Add a binding documentation for the TI TSC2046 touchscreen controllers
ADC functionality.
Signed-off-by: Oleksij Rempel
Reviewed-by: Rob Herring
---
.../bindings/iio/adc/ti,tsc2046.yaml | 115 ++
1 file changed, 115 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml
b/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml
new file mode 100644
index ..601d69971d84
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,tsc2046.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TSC2046 touch screen controller.
+
+maintainers:
+ - Oleksij Rempel
+
+description: |
+ TSC2046 is a touch screen controller with 8 channels ADC.
+
+properties:
+ compatible:
+enum:
+ - ti,tsc2046e-adc
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ spi-max-frequency: true
+
+ "#io-channel-cells":
+const: 1
+
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+required:
+ - compatible
+ - reg
+
+patternProperties:
+ "^channel@[0-7]$":
+$ref: "adc.yaml"
+type: object
+
+properties:
+ reg:
+description: |
+ The channel number. It can have up to 8 channels
+items:
+ minimum: 0
+ maximum: 7
+
+ settling-time-us: true
+ oversampling-ratio: true
+
+required:
+ - reg
+
+additionalProperties: false
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+adc@0 {
+compatible = "ti,tsc2046e-adc";
+reg = <0>;
+spi-max-frequency = <100>;
+interrupts-extended = <&gpio3 20 IRQ_TYPE_LEVEL_LOW>;
+#io-channel-cells = <1>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+channel@0 {
+ reg = <0>;
+};
+channel@1 {
+ reg = <1>;
+ settling-time-us = <700>;
+ oversampling-ratio = <5>;
+};
+channel@2 {
+ reg = <2>;
+};
+channel@3 {
+ reg = <3>;
+ settling-time-us = <700>;
+ oversampling-ratio = <5>;
+};
+channel@4 {
+ reg = <4>;
+ settling-time-us = <700>;
+ oversampling-ratio = <5>;
+};
+channel@5 {
+ reg = <5>;
+ settling-time-us = <700>;
+ oversampling-ratio = <5>;
+};
+channel@6 {
+ reg = <6>;
+};
+channel@7 {
+ reg = <7>;
+};
+};
+};
+...
--
2.29.2
[PATCH v5 1/3] dt-bindings:iio:adc: add generic settling-time-us and oversampling-ratio channel properties
Settling time and over sampling is a typical challenge for different IIO ADC devices. So, introduce channel specific settling-time-us and oversampling-ratio properties to cover this use case. Signed-off-by: Oleksij Rempel --- Documentation/devicetree/bindings/iio/adc/adc.yaml | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml index 912a7635edc4..d5bc86d2a2af 100644 --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml @@ -39,4 +39,12 @@ properties: The first value specifies the positive input pin, the second specifies the negative input pin. + settling-time-us: +description: + Time between enabling the channel and firs stable readings. + + oversampling-ratio: +$ref: /schemas/types.yaml#/definitions/uint32 +description: Number of data samples which are averaged for each read. + additionalProperties: true -- 2.29.2
Re: [PATCH 03/17] ASoC: atmel: atmel-i2s: remove useless initialization
On 26.03.2021 23:59, Pierre-Louis Bossart wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Cppcheck complains: > > sound/soc/atmel/atmel-i2s.c:628:6: style: Redundant initialization for 'err'. > The initialized value is overwritten before it is read. > [redundantInitialization] > err = devm_request_irq(&pdev->dev, irq, atmel_i2s_interrupt, 0, > ^ > sound/soc/atmel/atmel-i2s.c:598:10: note: err is initialized > int err = -ENXIO; > ^ > sound/soc/atmel/atmel-i2s.c:628:6: note: err is overwritten > err = devm_request_irq(&pdev->dev, irq, atmel_i2s_interrupt, 0, > ^ > > Signed-off-by: Pierre-Louis Bossart Reviewed-by: Codrin Ciubotariu Thanks!
linux-next: manual merge of the rust tree with the kbuild tree
Hi all,
Today's linux-next merge of the rust tree got a conflict in:
Makefile
between commit:
b0600f0d9b54 ("kbuild: check the minimum assembler version in Kconfig")
from the kbuild tree and commit:
98898dfbdf72 ("Rust support")
from the rust 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 Makefile
index 072e7a6a1a75,62b3bba38635..f86d011caedf
--- a/Makefile
+++ b/Makefile
@@@ -263,11 -270,7 +270,11 @@@ no-dot-config-targets := $(clean-target
cscope gtags TAGS tags help% %docs check% coccicheck \
$(version_h) headers headers_% archheaders archscripts
\
%asm-generic kernelversion %src-pkg dt_binding_check \
-outputmakefile
+outputmakefile rustfmt rustfmtcheck
+# Installation targets should not require compiler. Unfortunately,
vdso_install
+# is an exception where build artifacts may be updated. This must be fixed.
+no-compiler-targets := $(no-dot-config-targets) install dtbs_install \
+ headers_install modules_install kernelrelease image_name
no-sync-config-targets := $(no-dot-config-targets) %install kernelrelease \
image_name
single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o %.s %.symtypes %/
@@@ -567,24 -588,31 +596,29 @@@ ifdef building_out_of_srctre
{ echo "# this is build directory, ignore it"; echo "*"; } > .gitignore
endif
- # The expansion should be delayed until arch/$(SRCARCH)/Makefile is included.
- # Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile.
- # CC_VERSION_TEXT is referenced from Kconfig (so it needs export),
- # and from include/config/auto.conf.cmd to detect the compiler upgrade.
- CC_VERSION_TEXT = $(subst $(pound),,$(shell $(CC) --version 2>/dev/null |
head -n 1))
+ TENTATIVE_CLANG_FLAGS := -Werror=unknown-warning-option
- ifneq ($(findstring clang,$(CC_VERSION_TEXT)),)
ifneq ($(CROSS_COMPILE),)
- CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%))
+ TENTATIVE_CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%))
-GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
-TENTATIVE_CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir
$(CROSS_COMPILE))
-GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..)
-endif
-ifneq ($(GCC_TOOLCHAIN),)
-TENTATIVE_CLANG_FLAGS += --gcc-toolchain=$(GCC_TOOLCHAIN)
endif
-ifneq ($(LLVM_IAS),1)
+ifeq ($(LLVM_IAS),1)
- CLANG_FLAGS += -integrated-as
++TENTATIVE_CLANG_FLAGS += -integrated-as
+else
- CLANG_FLAGS += -no-integrated-as
+ TENTATIVE_CLANG_FLAGS += -no-integrated-as
+GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
- CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
++TENTATIVE_CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir
$(CROSS_COMPILE))
endif
- CLANG_FLAGS += -Werror=unknown-warning-option
+
+ export TENTATIVE_CLANG_FLAGS
+
+ # The expansion should be delayed until arch/$(SRCARCH)/Makefile is included.
+ # Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile.
+ # CC_VERSION_TEXT is referenced from Kconfig (so it needs export),
+ # and from include/config/auto.conf.cmd to detect the compiler upgrade.
+ CC_VERSION_TEXT = $(shell $(CC) --version 2>/dev/null | head -n 1 | sed
's/\#//g')
+
+ ifneq ($(findstring clang,$(CC_VERSION_TEXT)),)
+ CLANG_FLAGS += $(TENTATIVE_CLANG_FLAGS)
KBUILD_CFLAGS += $(CLANG_FLAGS)
KBUILD_AFLAGS += $(CLANG_FLAGS)
export CLANG_FLAGS
pgpbPsvZk3qhB.pgp
Description: OpenPGP digital signature
[syzbot] WARNING: suspicious RCU usage in io_sq_thread
Hello,
syzbot found the following issue on:
HEAD commit:81b1d39f Merge tag '5.12-rc4-smb3' of git://git.samba.org/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=156f3d9ed0
kernel config: https://syzkaller.appspot.com/x/.config?x=d4e9addca54f3b44
dashboard link: https://syzkaller.appspot.com/bug?extid=0cbf22e728582ade44f2
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+0cbf22e728582ade4...@syzkaller.appspotmail.com
WARNING: suspicious RCU usage
5.12.0-rc4-syzkaller #0 Not tainted
-
kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side critical
section!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 0
1 lock held by iou-sqp-10136/10139:
#0: 88801a5a8c70 (&sqd->lock){+.+.}-{3:3}, at: io_sq_thread+0xff2/0x13a0
fs/io_uring.c:6794
stack backtrace:
CPU: 1 PID: 10139 Comm: iou-sqp-10136 Not tainted 5.12.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
___might_sleep+0x229/0x2c0 kernel/sched/core.c:8294
io_sq_thread+0xbae/0x13a0 fs/io_uring.c:6768
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[syzbot] general protection fault in io_commit_cqring (2)
Hello, syzbot found the following issue on: HEAD commit:81b1d39f Merge tag '5.12-rc4-smb3' of git://git.samba.org/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=10ce6fe6d0 kernel config: https://syzkaller.appspot.com/x/.config?x=daeff30c2474a60f dashboard link: https://syzkaller.appspot.com/bug?extid=0e905eb8228070c457a0 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10e0ed06d0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1144754ed0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+0e905eb8228070c45...@syzkaller.appspotmail.com RBP: 7ffe05a7c220 R08: 0001 R09: 0001 R10: R11: 0246 R12: 0003 R13: 431bde82d7b634db R14: 004ae018 R15: 00400488 general protection fault, probably for non-canonical address 0xdc18: [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x00c0-0x00c7] CPU: 1 PID: 8400 Comm: syz-executor278 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:io_commit_cqring+0x37f/0xc10 fs/io_uring.c:1318 Code: 74 08 3c 03 0f 8e fa 05 00 00 48 8d bb c0 00 00 00 41 8b ac 24 00 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 b7 RSP: 0018:c90001c1fc78 EFLAGS: 00010006 RAX: dc00 RBX: RCX: RDX: 0018 RSI: 81db8861 RDI: 00c0 RBP: R08: 0001 R09: 0003 R10: f52000383f8f R11: R12: 888018166000 R13: R14: 192000383fab R15: 8880181660c0 FS: 006c7300() GS:8880b9d0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fd3db1886c0 CR3: 21099000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: io_kill_timeouts+0x2b5/0x320 fs/io_uring.c:8606 io_ring_ctx_wait_and_kill+0x1da/0x400 fs/io_uring.c:8629 io_uring_create fs/io_uring.c:9572 [inline] io_uring_setup+0x10da/0x2ae0 fs/io_uring.c:9599 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x43ffd9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 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 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:7ffe05a7c208 EFLAGS: 0246 ORIG_RAX: 01a9 RAX: ffda RBX: 0001 RCX: 0043ffd9 RDX: 0020 RSI: 2080 RDI: 54ca RBP: 7ffe05a7c220 R08: 0001 R09: 0001 R10: R11: 0246 R12: 0003 R13: 431bde82d7b634db R14: 004ae018 R15: 00400488 Modules linked in: ---[ end trace a0b1f0cfec9b9808 ]--- RIP: 0010:io_commit_cqring+0x37f/0xc10 fs/io_uring.c:1318 Code: 74 08 3c 03 0f 8e fa 05 00 00 48 8d bb c0 00 00 00 41 8b ac 24 00 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 b7 RSP: 0018:c90001c1fc78 EFLAGS: 00010006 RAX: dc00 RBX: RCX: RDX: 0018 RSI: 81db8861 RDI: 00c0 RBP: R08: 0001 R09: 0003 R10: f52000383f8f R11: R12: 888018166000 R13: R14: 192000383fab R15: 8880181660c0 FS: 006c7300() GS:8880b9d0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fd3db1886c0 CR3: 21099000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
[syzbot] WARNING: still has locks held in io_sq_thread
Hello,
syzbot found the following issue on:
HEAD commit:81b1d39f Merge tag '5.12-rc4-smb3' of git://git.samba.org/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10fcce62d0
kernel config: https://syzkaller.appspot.com/x/.config?x=d4e9addca54f3b44
dashboard link: https://syzkaller.appspot.com/bug?extid=796d767eb376810256f5
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17d06ddcd0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=150764bed0
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+796d767eb37681025...@syzkaller.appspotmail.com
WARNING: iou-sqp-8386/8387 still has locks held!
5.12.0-rc4-syzkaller #0 Not tainted
1 lock held by iou-sqp-8386/8387:
#0: 88801e1d2470 (&sqd->lock){+.+.}-{3:3}, at: io_sq_thread+0x24c/0x13a0
fs/io_uring.c:6731
stack backtrace:
CPU: 1 PID: 8387 Comm: iou-sqp-8386 Not tainted 5.12.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
try_to_freeze include/linux/freezer.h:66 [inline]
get_signal+0x171a/0x2150 kernel/signal.c:2576
io_sq_thread+0x8d2/0x13a0 fs/io_uring.c:6748
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH] sched,psi: fix typo in comment
On Sat, Mar 27, 2021 at 08:46:10PM +0800, Xie XiuQi wrote: > s/exceution/execution/ > s/possibe/possible/ > s/manupulations/manipulations/ > > Signed-off-by: Xie XiuQi Xie, if you'd have bothered to check the development tree of the code you're patching, you'd have found it's long since fixed. Can we please get a MAINTAINERS entry that indicates the willingness to suffer nonsense like this? Then checkpatch will tell people to bugger off and I can stop blacklisting people on this. I'm getting sick and tired of people wasting bandwidth with this nonsense.
Re: [PATCH 02/17] ASoC: atmel: fix shadowed variable
On 26.03.2021 23:59, Pierre-Louis Bossart wrote:
> Fix cppcheck warning:
>
> sound/soc/atmel/atmel-classd.c:51:14: style: Local variable 'pwm_type'
> shadows outer variable [shadowVariable]
> const char *pwm_type;
> ^
> sound/soc/atmel/atmel-classd.c:226:27: note: Shadowed declaration
> static const char * const pwm_type[] = {
>^
> sound/soc/atmel/atmel-classd.c:51:14: note: Shadow variable
> const char *pwm_type;
> ^
>
> Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Codrin Ciubotariu
Thanks!
Re: [PATCH v3 3/3] iio: adc: add ADC driver for the TI TSC2046 controller
On Mon, Mar 22, 2021 at 02:27:22PM +, Jonathan Cameron wrote:
> > > > +static DECLARE_TI_TSC2046_8_CHANNELS(tsc2046_adc, 12);
> > > > +
> > > > +static const struct tsc2046_adc_dcfg tsc2046_adc_dcfg_tsc2046e = {
> > > > + .channels = tsc2046_adc_channels,
> > > > + .num_channels = ARRAY_SIZE(tsc2046_adc_channels),
> > > > +};
> > > > +
> > >
> > > Hmm. Flexibility that isn't yet used. Normally I'm pretty resistant
> > > to this going in, unless I'm reassured that there is support for
> > > additional
> > > devices already in the pipeline. Is that true here? Otherwise
> > > this is basically unneeded complexity.
> >
> > In the long term this driver should replace
> > drivers/input/touchscreen/ads7846.c
> >
> > This driver supports ti,ads7843, ti,ads7845, ti,ads7846.. at least with
> > following number of supported channels:
> > ti,ads7843 - 4 channels: x, y, aux0, aux1
> > ti,ads7845 - 3 channels: x, y, aux0
> > ti,ads7846 - 8 channels...
> >
> > Currently I don't have this HW for testing and there a subtle
> > differences that have to be taken care of and tested.
> >
>
> Note that I'm only going to merge this driver with an explicit statement
> from Dmitry as input maintainer that he is fine with this approach.
Since there is still no Dmitry's feedback please take a look to the
ti,ads7843 datasheet:
https://www.ti.com/lit/ds/symlink/ads7843.pdf
On the page 1 you can see, that this device has two general purpose ADC
inputs IN3, IN4. If some one will decide to mainline support for this
pins, will end with IIO ADC driver any way :)
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[tip:x86/vmware] BUILD SUCCESS 0b4a285e2c65c2c9449c6eccb87298e385213e7b
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/vmware branch HEAD: 0b4a285e2c65c2c9449c6eccb87298e385213e7b x86/vmware: Avoid TSC recalibration when frequency is known elapsed time: 720m configs tested: 83 configs skipped: 53 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig x86_64 allyesconfig riscvallmodconfig i386 allyesconfig riscvallyesconfig powerpc chrp32_defconfig arm omap2plus_defconfig sh rsk7264_defconfig riscvnommu_virt_defconfig umkunit_defconfig mipsworkpad_defconfig nios2 10m50_defconfig powerpc lite5200b_defconfig mipsnlm_xlp_defconfig arm shannon_defconfig mips loongson1b_defconfig sh microdev_defconfig pariscgeneric-64bit_defconfig powerpc ppc6xx_defconfig arm ixp4xx_defconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a002-20210329 x86_64 randconfig-a003-20210329 x86_64 randconfig-a006-20210329 x86_64 randconfig-a001-20210329 x86_64 randconfig-a005-20210329 x86_64 randconfig-a004-20210329 i386 randconfig-a003-20210329 i386 randconfig-a004-20210329 i386 randconfig-a001-20210329 i386 randconfig-a002-20210329 i386 randconfig-a006-20210329 i386 randconfig-a005-20210329 i386 randconfig-a014-20210328 i386 randconfig-a011-20210328 i386 randconfig-a015-20210328 i386 randconfig-a016-20210328 i386 randconfig-a013-20210328 i386 randconfig-a012-20210328 riscvnommu_k210_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig x86_64rhel-8.3-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a015-20210329 x86_64 randconfig-a012-20210329 x86_64 randconfig-a013-20210329 x86_64 randconfig-a014-20210329 x86_64 randconfig-a011-20210329 x86_64 randconfig-a016-20210329 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[tip:locking/core] BUILD SUCCESS bd9a5fc2edb0bdcb0756298daa31ddd6a02f0634
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core branch HEAD: bd9a5fc2edb0bdcb0756298daa31ddd6a02f0634 MAINTAINERS: Add myself as futex reviewer elapsed time: 720m configs tested: 112 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig x86_64 allyesconfig riscvallmodconfig i386 allyesconfig riscvallyesconfig arm aspeed_g4_defconfig arm pxa_defconfig sparc sparc32_defconfig ia64 alldefconfig powerpcicon_defconfig arcnsimosci_defconfig powerpc chrp32_defconfig arm omap2plus_defconfig sh rsk7264_defconfig riscvnommu_virt_defconfig umkunit_defconfig mips cu1830-neo_defconfig sh kfr2r09-romimage_defconfig mips ip32_defconfig sh shx3_defconfig m68k multi_defconfig mipsworkpad_defconfig nios2 10m50_defconfig powerpc lite5200b_defconfig mipsnlm_xlp_defconfig powerpc mpc8313_rdb_defconfig sh sdk7780_defconfig powerpc mpc8560_ads_defconfig sh r7785rp_defconfig sh microdev_defconfig m68k bvme6000_defconfig sh se7705_defconfig arm axm55xx_defconfig powerpc xes_mpc85xx_defconfig arm shannon_defconfig mips loongson1b_defconfig pariscgeneric-64bit_defconfig powerpc ppc6xx_defconfig arm ixp4xx_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a002-20210329 x86_64 randconfig-a003-20210329 x86_64 randconfig-a006-20210329 x86_64 randconfig-a001-20210329 x86_64 randconfig-a005-20210329 x86_64 randconfig-a004-20210329 i386 randconfig-a003-20210329 i386 randconfig-a004-20210329 i386 randconfig-a001-20210329 i386 randconfig-a002-20210329 i386 randconfig-a006-20210329 i386 randconfig-a005-20210329 i386 randconfig-a014-20210328 i386 randconfig-a011-20210328 i386 randconfig-a015-20210328 i386 randconfig-a016-20210328 i386 randconfig-a013-20210328 i386 randconfig-a012-20210328 riscvnommu_k210_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig um allmodconfig umallnoconfig um allyesconfig um
Re: [kbuild-all] Re: [PATCH] riscv: Use $(LD) instead of $(CC) to link vDSO
Hi Nathan, On 3/27/21 7:58 AM, Nathan Chancellor wrote: On Sat, Mar 27, 2021 at 12:05:34AM +0800, kernel test robot wrote: Hi Nathan, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.12-rc4 next-20210326] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Nathan-Chancellor/riscv-Use-LD-instead-of-CC-to-link-vDSO/20210326-055421 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 002322402dafd846c424ffa9240a937f49b48c42 config: riscv-randconfig-r032-20210326 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project f490a5969bd52c8a48586f134ff8f02ccbb295b3) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install riscv cross compiling tool for clang build # apt-get install binutils-riscv64-linux-gnu # https://github.com/0day-ci/linux/commit/dfdcaf93f40f0d15ffc3f25128442c1688e612d6 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Nathan-Chancellor/riscv-Use-LD-instead-of-CC-to-link-vDSO/20210326-055421 git checkout dfdcaf93f40f0d15ffc3f25128442c1688e612d6 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv For the record, I tried to use this script to reproduce but it has a couple of bugs: 1. It does not download the right version of clang. This report says that it is clang-13 but the one that the script downloaded is clang-12. 2. It does not download it to the right location. The script expects ~/0day/clang-latest but it is downloaded to ~/0day/clang it seems. I symlinked it to get around it. Sorry for the inconvenience, we'll fix both asap. Best Regards, Rong Chen If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): riscv64-linux-gnu-objcopy: 'arch/riscv/kernel/vdso/vdso.so.dbg': No such file This error only occurs because of errors before it that are not shown due to a denylist: ld.lld: error: arch/riscv/kernel/vdso/rt_sigreturn.o:(.text+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax ld.lld: error: arch/riscv/kernel/vdso/getcpu.o:(.text+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax ld.lld: error: arch/riscv/kernel/vdso/flush_icache.o:(.text+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax My patch only adds another occurrence of this error because we move from $(CC)'s default linker (in clang's case, ld.bfd) to $(LD), which in the case of 0day appears to be ld.lld. ld.lld should not be used with RISC-V in its current form due to errors of this nature, which happen without my patch as well: https://github.com/ClangBuiltLinux/linux/issues/1020 Linker relaxation in ld.lld for RISC-V is an ongoing debate/process. Please give RISC-V the current treatment as s390 with ld.lld for the time being to get meaningful reports. We will reach out once that issue has been resolved. TL;DR: Patch exposes existing issue with LD=ld.lld that would have happened without it in different areas, the report can be ignored. Cheers! Nathan ___ kbuild-all mailing list -- kbuild-...@lists.01.org To unsubscribe send an email to kbuild-all-le...@lists.01.org
Re: [PATCH net-next v2] net: axienet: Remove redundant dev_err call in axienet_probe()
On 3/29/21 3:45 AM, Huang Guobin wrote:
> From: Guobin Huang
>
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
>
> Reported-by: Hulk Robot
> Signed-off-by: Guobin Huang
> ---
> drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index 5d677db0aee5..f77a794540fc 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -1878,7 +1878,6 @@ static int axienet_probe(struct platform_device *pdev)
> ethres = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> lp->regs = devm_ioremap_resource(&pdev->dev, ethres);
> if (IS_ERR(lp->regs)) {
> - dev_err(&pdev->dev, "could not map Axi Ethernet regs.\n");
> ret = PTR_ERR(lp->regs);
> goto cleanup_clk;
> }
>
I have already reviewed v1 and I can't see any v2 description what has
changed. Why am I getting this v2? Where is my tag?
Thanks,
Michal
Re: [PATCH v7 01/13] dt-bindings: mfd: Add 'nxp,imx8mq-vpu-ctrl' to syscon list
On Mon, 29 Mar 2021, Benjamin Gaignard wrote: > Add 'nxp,imx8mq-vpu-ctrl' in the list of possible syscon. > It will used to access to the VPU control registers. > > Signed-off-by: Benjamin Gaignard > Acked-by: Rob Herring > --- > version 7: > - Add Rob ack > Documentation/devicetree/bindings/mfd/syscon.yaml | 1 + > 1 file changed, 1 insertion(+) Acked-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/8] mm: cma: introduce cma_release_nowait()
On Fri 26-03-21 14:32:01, Mike Kravetz wrote: [...] > - Just change the mutex to an irq safe spinlock. Yes please. > AFAICT, the potential > downsides could be: > - Interrupts disabled during long bitmap scans How large those bitmaps are in practice? > - Wasted cpu cycles (spinning) if there is much contention on lock > Both of these would be more of an issue on small/embedded systems. I > took a quick look at the callers of cma_alloc/cma_release and nothing > stood out that could lead to high degrees of contention. However, I > could have missed something. If this is really a practical concern then we can try a more complex solution based on some data. -- Michal Hocko SUSE Labs
Re: [External] [PATCH 7/8] hugetlb: make free_huge_page irq safe
On Sat 27-03-21 15:06:36, Muchun Song wrote:
> On Thu, Mar 25, 2021 at 8:29 AM Mike Kravetz wrote:
> >
> > Commit c77c0a8ac4c5 ("mm/hugetlb: defer freeing of huge pages if in
> > non-task context") was added to address the issue of free_huge_page
> > being called from irq context. That commit hands off free_huge_page
> > processing to a workqueue if !in_task. However, as seen in [1] this
> > does not cover all cases. Instead, make the locks taken in the
> > free_huge_page irq safe.
> >
> > This patch does the following:
> > - Make hugetlb_lock irq safe. This is mostly a simple process of
> > changing spin_*lock calls to spin_*lock_irq* calls.
> > - Make subpool lock irq safe in a similar manner.
> > - Revert the !in_task check and workqueue handoff.
> >
> > [1]
> > https://lore.kernel.org/linux-mm/f1c03b05bc43a...@google.com/
> >
> > Signed-off-by: Mike Kravetz
>
> The changes are straightforward.
>
> Reviewed-by: Muchun Song
>
> Since this patchset aims to fix a real word issue. Should we add a Fixes
> tag?
Do we know since when it is possible to use hugetlb in the networking
context? Maybe this is possible since ever but I am wondering why the
lockdep started complaining only now. Maybe just fuzzing finally started
using this setup which nobody does normally.
--
Michal Hocko
SUSE Labs
[Resend PATCH V3 2/5] soc: qcom: dcc: Add driver support for Data Capture and Compare unit(DCC)
The DCC is a DMA Engine designed to capture and store data during system crash or software triggers.The DCC operates based on user inputs via the sysfs interface.The user gives addresses as inputs and these addresses are stored in the form of linkedlists.In case of a system crash or a manual software trigger by the user through the sysfs interface, the dcc captures and stores the values at these addresses. This patch contains the driver which has all the methods pertaining to the sysfs interface, auxiliary functions to support all the four fundamental operations of dcc namely read, write, first read then write and loop.The probe method here instantiates all the resources necessary for dcc to operate mainly the dedicated dcc sram where it stores the values.The DCC driver can be used for debugging purposes without going for a reboot since it can perform manual triggers. Signed-off-by: Souradeep Chowdhury --- drivers/soc/qcom/Kconfig |8 + drivers/soc/qcom/Makefile |1 + drivers/soc/qcom/dcc.c| 1549 + 3 files changed, 1558 insertions(+) create mode 100644 drivers/soc/qcom/dcc.c diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig index 79b568f..8819e0b 100644 --- a/drivers/soc/qcom/Kconfig +++ b/drivers/soc/qcom/Kconfig @@ -69,6 +69,14 @@ config QCOM_LLCC SDM845. This provides interfaces to clients that use the LLCC. Say yes here to enable LLCC slice driver. +config QCOM_DCC + tristate "Qualcomm Technologies, Inc. Data Capture and Compare engine driver" + depends on ARCH_QCOM || COMPILE_TEST + help + This option enables driver for Data Capture and Compare engine. DCC + driver provides interface to configure DCC block and read back + captured data from DCC's internal SRAM. + config QCOM_KRYO_L2_ACCESSORS bool depends on ARCH_QCOM && ARM64 || COMPILE_TEST diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile index ad675a6..1b00870 100644 --- a/drivers/soc/qcom/Makefile +++ b/drivers/soc/qcom/Makefile @@ -26,3 +26,4 @@ obj-$(CONFIG_QCOM_LLCC) += llcc-qcom.o obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o obj-$(CONFIG_QCOM_KRYO_L2_ACCESSORS) +=kryo-l2-accessors.o +obj-$(CONFIG_QCOM_DCC) += dcc.o diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c new file mode 100644 index 000..a55d8ca7 --- /dev/null +++ b/drivers/soc/qcom/dcc.c @@ -0,0 +1,1549 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#define TIMEOUT_US 100 + +#define dcc_writel(drvdata, val, off) \ + writel((val), drvdata->base + dcc_offset_conv(drvdata, off)) +#define dcc_readl(drvdata, off) \ + readl(drvdata->base + dcc_offset_conv(drvdata, off)) + +#define dcc_sram_readl(drvdata, off) \ + readl(drvdata->ram_base + off) + +#define DCC_SRAM_NODE "dcc_sram" + +/* DCC registers */ +#define DCC_HW_INFO0x04 +#define DCC_LL_NUM_INFO0x10 +#define DCC_STATUS 0x1C +#define DCC_LL_LOCK(m) (0x34 + 0x80 * m) +#define DCC_LL_CFG(m) (0x38 + 0x80 * m) +#define DCC_LL_BASE(m) (0x3c + 0x80 * m) +#define DCC_FD_BASE(m) (0x40 + 0x80 * m) +#define DCC_LL_TIMEOUT(m) (0x44 + 0x80 * m) +#define DCC_LL_INT_ENABLE(m) (0x4C + 0x80 * m) +#define DCC_LL_INT_STATUS(m) (0x50 + 0x80 * m) +#define DCC_LL_SW_TRIGGER(m) (0x60 + 0x80 * m) +#define DCC_LL_BUS_ACCESS_STATUS(m)(0x64 + 0x80 * m) + +#define DCC_MAP_LEVEL1 0x18 +#define DCC_MAP_LEVEL2 0x34 +#define DCC_MAP_LEVEL3 0x4C + +#define DCC_MAP_OFFSET10x10 +#define DCC_MAP_OFFSET20x18 +#define DCC_MAP_OFFSET30x1C +#define DCC_MAP_OFFSET40x8 + +#define DCC_FIX_LOOP_OFFSET16 +#define DCC_VER_INFO_BIT 9 + +#define DCC_READ 0 +#define DCC_WRITE 1 +#define DCC_LOOP 2 +#define DCC_READ_WRITE 3 + +#define MAX_DCC_OFFSET GENMASK(9, 2) +#define MAX_DCC_LENGENMASK(6, 0) +#define MAX_LOOP_CNT GENMASK(7, 0) + +#define DCC_ADDR_DESCRIPTOR0x00 +#define DCC_LOOP_DESCRIPTORBIT(30) +#define DCC_RD_MOD_WR_DESCRIPTOR BIT(31) +#define DCC_LINK_DESCRIPTORGENMASK(31, 30) + +#define DCC_READ_IND 0x00 +#define DCC_WRITE_IND (BIT(2
[Resend PATCH V3 3/5] DCC: Added the sysfs entries for DCC(Data Capture and Compare) driver
The DCC is a DMA engine designed to store register values either in case of a system crash or in case of software triggers manually done by the user.Using DCC hardware and the sysfs interface of the driver the user can exploit various functionalities of DCC.The user can specify the register addresses,the values of which is stored by DCC in it's dedicated SRAM.The register addresses can be used either to read from, write to,first read and store value and then write or to loop.All these options can be exploited using the sysfs interface given to the user. Following are the sysfs interfaces exposed in DCC driver which are documented 1)trigger 2)config 3)config_write 4)config_reset 5)enable 6)rd_mod_wr 7)loop Signed-off-by: Souradeep Chowdhury --- Documentation/ABI/testing/sysfs-driver-dcc | 114 + 1 file changed, 114 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc diff --git a/Documentation/ABI/testing/sysfs-driver-dcc b/Documentation/ABI/testing/sysfs-driver-dcc new file mode 100644 index 000..05d24f0 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-dcc @@ -0,0 +1,114 @@ +What: /sys/bus/platform/devices/.../trigger +Date: March 2021 +Contact:Souradeep Chowdhury +Description: + This is the sysfs interface for manual software + triggers.The user can simply enter a 1 against + the sysfs file and enable a manual trigger. + Example: + echo 1 > /sys/bus/platform/devices/.../trigger + +What: /sys/bus/platform/devices/.../enable +Date: March 2021 +Contact:Souradeep Chowdhury +Description: + This sysfs interface is used for enabling the + the dcc hardware.Without this being set to 1, + the dcc hardware ceases to function. + Example: + echo 0 > /sys/bus/platform/devices/.../enable + (disable interface) + echo 1 > /sys/bus/platform/devices/.../enable + (enable interface) + +What: /sys/bus/platform/devices/.../config +Date: March 2021 +Contact:Souradeep Chowdhury +Description: + This is the most commonly used sysfs interface + file and this basically stores the addresses of + the registers which needs to be read in case of + a hardware crash or manual software triggers. + Example: + echo 0x8010 10 > /sys/bus/platform/devices/../config + This specifies that 10 words starting from address + 0x8010 is to be read.In case there are no words to be + specified we can simply enter the address. + +What: /sys/bus/platform/devices/.../config_write +Date: March 2021 +Contact:Souradeep Chowdhury +Description: + This file allows user to write a value to the register + address given as argument.The values are entered in the + form of .The reason for this + feature of dcc is that for accessing certain registers + it is necessary to set some bits of soe other register. + That is achievable by giving DCC this privelege. + Example: + echo 0x8000 0xFF > /sys/bus/platform/devices/.../config_write + +What: /sys/bus/platform/devices/.../config_reset +Date: March 2021 +Contact:Souradeep Chowdhury +Description: + This file is used to reset the configuration of + a dcc driver to the default configuration. + Example: + echo 1 > /sys/bus/platform/devices/.../config_reset + +What: /sys/bus/platform/devices/.../loop +Date: March 2021 +Contact:Souradeep Chowdhury +Description: + This file is used to enter the loop count as dcc + driver gives the option to loop multiple times on + the same register and store the values for each + loop.This is done to capture the changing values + of a register with time which comes handy for + debugging purposes. + Example: + echo 10 > /sys/bus/platform/devices/10a2000.dcc/loop + (Setting the loop count to 10) + echo 0x8010 10 > /sys/bus/platform/devices/.../config +(Read 10 words starting from address 0x8010O) + echo 1 > /sys/bus/platform/devices/.../loop + (Terminate the loop by writing a count of 1 to the loop sysfs node) + +What: /sys/bus/platform/devices/.../rd_mod_wr +Date: March 2021 +Contact:Souradeep Chowdhury +Description: + This file is used to read the value of the register + and then write the value given as an argument to the +
[Resend PATCH V3 1/5] dt-bindings: Added the yaml bindings for DCC
Documentation for Data Capture and Compare(DCC) device tree bindings
in yaml format.
Reviewed-by: Rob Herring
Signed-off-by: Souradeep Chowdhury
---
.../devicetree/bindings/arm/msm/qcom,dcc.yaml | 49 ++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml
b/Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml
new file mode 100644
index 000..c6e0a9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/msm/qcom,dcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Data Capture and Compare
+
+maintainers:
+ - Souradeep Chowdhury
+
+description: |
+DCC (Data Capture and Compare) is a DMA engine which is used to save
+configuration data or system memory contents during catastrophic failure
+or SW trigger.DCC is used to capture and store data for debugging purpose
+
+
+properties:
+ compatible:
+items:
+ - enum:
+ - qcom,sm8150-dcc
+ - const: qcom,dcc
+
+ reg:
+items:
+ - description: DCC base register region
+ - description: DCC RAM base register region
+
+ reg-names:
+items:
+ - const: dcc
+ - const: dcc-ram
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+dcc@10a2000{
+compatible = "qcom,sm8150-dcc","qcom,dcc";
+reg = <0x010a2000 0x1000>,
+ <0x010ad000 0x2000>;
+reg-names = "dcc", "dcc-ram";
+};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[Resend PATCH V3 5/5] arm64: dts: qcom: sm8150: Add Data Capture and Compare(DCC) support node
Add the DCC(Data Capture and Compare) device tree node entry along with
the addresses for register regions.
Signed-off-by: Souradeep Chowdhury
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index e5bb17b..ba6acf4 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -654,6 +654,13 @@
interrupts = ;
};
+ dcc@10a2000 {
+ compatible = "qcom,sm8150-dcc", "qcom,dcc";
+ reg = <0x0 0x010a2000 0x0 0x1000>,
+ <0x0 0x010ad000 0x0 0x3000>;
+ reg-names = "dcc", "dcc-ram";
+ };
+
ufs_mem_hc: ufshc@1d84000 {
compatible = "qcom,sm8150-ufshc", "qcom,ufshc",
"jedec,ufs-2.0";
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v4 3/4] locking/qspinlock: Add ARCH_USE_QUEUED_SPINLOCKS_XCHG32
On Sat, Mar 27, 2021 at 06:06:38PM +, guo...@kernel.org wrote: > From: Guo Ren > > Some architectures don't have sub-word swap atomic instruction, > they only have the full word's one. > > The sub-word swap only improve the performance when: > NR_CPUS < 16K > * 0- 7: locked byte > * 8: pending > * 9-15: not used > * 16-17: tail index > * 18-31: tail cpu (+1) > > The 9-15 bits are wasted to use xchg16 in xchg_tail. > > Please let architecture select xchg16/xchg32 to implement > xchg_tail. So I really don't like this, this pushes complexity into the generic code for something that's really not needed. Lots of RISC already implement sub-word atomics using word ll/sc. Obviously they're not sharing code like they should be :/ See for example arch/mips/kernel/cmpxchg.c. Also, I really do think doing ticket locks first is a far more sensible step.
[Resend PATCH V3 4/5] MAINTAINERS:Add the entry for DCC(Data Capture and Compare) driver support
Added the entries for all the files added as a part of driver support for DCC(Data Capture and Compare). Signed-off-by: Souradeep Chowdhury --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index d92f85c..fb28218 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4969,6 +4969,14 @@ F: include/linux/tfrc.h F: include/uapi/linux/dccp.h F: net/dccp/ +QTI DCC DRIVER +M: Souradeep Chowdhury +L: linux-arm-...@vger.kernel.org +S: Maintained +F: Documentation/ABI/testing/sysfs-driver-dcc +F: Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml +F: drivers/soc/qcom/dcc.c + DECnet NETWORK LAYER L: linux-decnet-u...@lists.sourceforge.net S: Orphan -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v2 4/4] erofs: add on-disk compression configurations
On 2021/3/29 14:55, Gao Xiang wrote: I found a reference here, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v5.11#n99 also vaguely remembered some threads from Linus, but hard to find now :-( Sure, we can follow this rule for erofs code style. :) Thanks,
Re: [kernel/resource] cf1e4e12c9: WARNING:possible_recursive_locking_detected
Not sure why I didn't hit this in testing but the problem is obvious: I missed
that revoke_iomem() calls devmem_is_allowed() which on x86 calls
region_intersects(). I guess I must have forgotten to do a boot test with
CONFIG_IO_STRICT_DEVMEM. Will put a fix together.
- Alistair
On Monday, 29 March 2021 4:42:30 PM AEDT kernel test robot wrote:
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: cf1e4e12c95dec0bb945df3eb138190fc353460f ("[PATCH v2] kernel/
resource: Fix locking in request_free_mem_region")
> url:
> https://github.com/0day-ci/linux/commits/Alistair-Popple/kernel-resource-Fix-locking-in-request_free_mem_region/20210326-092150
> base: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
a74e6a014c9d4d4161061f770c9b4f98372ac778
>
> in testcase: boot
>
> on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/
backtrace):
>
>
> +--+++
> | | a74e6a014c | cf1e4e12c9 |
> +--+++
> | boot_successes | 6 | 0 |
> | boot_failures| 0 | 6 |
> | WARNING:possible_recursive_locking_detected | 0 | 6 |
> | INFO:rcu_sched_self-detected_stall_on_CPU| 0 | 6 |
> | INFO:rcu_sched_detected_stalls_on_CPUs/tasks | 0 | 1 |
> | EIP:queued_read_lock_slowpath| 0 | 1 |
> +--+++
>
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot
>
>
> [9.616229] WARNING: possible recursive locking detected
> [9.617758] 5.12.0-rc2-00297-gcf1e4e12c95d #1 Not tainted
> [9.617758]
> [9.617758] swapper/0/1 is trying to acquire lock:
> [9.617758] 41bb9674 (resource_lock){}-{2:2}, at: region_intersects
(kbuild/src/consumer/kernel/resource.c:534 kbuild/src/consumer/kernel/
resource.c:580)
> [9.619753]
> [9.619753] but task is already holding lock:
> [9.619753] 41bb9674 (resource_lock){}-{2:2}, at: __request_region
(kbuild/src/consumer/kernel/resource.c:1188 kbuild/src/consumer/kernel/
resource.c:1255)
> [9.621757]
> [9.621757] other info that might help us debug this:
> [9.621757] Possible unsafe locking scenario:
> [9.621757]
> [9.621757]CPU0
> [9.621757]
> [9.623721] lock(resource_lock);
> [9.623747] lock(resource_lock);
> [9.623747]
> [9.623747] *** DEADLOCK ***
> [9.623747]
> [9.623747] May be due to missing lock nesting notation
> [9.623747]
> [9.625725] 2 locks held by swapper/0/1:
> [9.625759] #0: 42e1f160 (&dev->mutex){}-{3:3}, at: device_lock
(kbuild/src/consumer/include/linux/device.h:741)
> [9.625759] #1: 41bb9674 (resource_lock){}-{2:2}, at:
__request_region (kbuild/src/consumer/kernel/resource.c:1188 kbuild/src/
consumer/kernel/resource.c:1255)
> [9.625759]
> [9.625759] stack backtrace:
> [9.627748] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc2-00297-
gcf1e4e12c95d #1
> [9.627748] Call Trace:
> [9.627748] ? dump_stack (kbuild/src/consumer/lib/dump_stack.c:122)
> [9.627748] ? validate_chain (kbuild/src/consumer/kernel/locking/
lockdep.c:2829 kbuild/src/consumer/kernel/locking/lockdep.c:2872 kbuild/src/
consumer/kernel/locking/lockdep.c:3661)
> [9.629761] ? __lock_acquire (kbuild/src/consumer/kernel/locking/
lockdep.c:4900)
> [9.629761] ? lock_acquire (kbuild/src/consumer/kernel/locking/lockdep.c:
437 kbuild/src/consumer/kernel/locking/lockdep.c:5512 kbuild/src/consumer/
kernel/locking/lockdep.c:5475)
> [9.629761] ? region_intersects (kbuild/src/consumer/kernel/resource.c:
534 kbuild/src/consumer/kernel/resource.c:580)
> [9.629761] ? lock_acquire (kbuild/src/consumer/kernel/locking/lockdep.c:
437 kbuild/src/consumer/kernel/locking/lockdep.c:5512 kbuild/src/consumer/
kernel/locking/lockdep.c:5475)
> [9.629761] ? lock_is_held_type (kbuild/src/consumer/kernel/locking/
lockdep.c:5253 kbuild/src/consumer/kernel/locking/lockdep.c:5549)
> [9.631752] ? _raw_read_lock (kbuild/src/consumer/include/linux/
rwlock_api_smp.h:150 kbuild/src/consumer/kernel/locking/spinlock.c:223)
> [9.631752] ? region_intersects (kbuild/src/consumer/kernel/resource.c:
534 kbuild/src/consumer/kernel/resource.c:580)
> [9.631752] ? devmem_is_allowed (kbuild/src/consumer/arch/x86/mm/init.c:
823)
> [9.633761] ? __request_region (kbuild/src/consumer/kernel/resource.c:
1157 kbuild/src/consumer/kernel/resource.c:1232 kbuild/src/consumer/kernel/
resource.c:1255)
> [9.633761] ? wake_up_q (kbuild/src/co
[PATCH net 1/1] xdp: fix xdp_return_frame() kernel BUG throw for page_pool memory model
xdp_return_frame() may be called outside of NAPI context to return
xdpf back to page_pool. xdp_return_frame() calls __xdp_return() with
napi_direct = false. For page_pool memory model, __xdp_return() calls
xdp_return_frame_no_direct() unconditionally and below false negative
kernel BUG throw happened under preempt-rt build:
[ 430.450355] BUG: using smp_processor_id() in preemptible [] code:
modprobe/3884
[ 430.451678] caller is __xdp_return+0x1ff/0x2e0
[ 430.452111] CPU: 0 PID: 3884 Comm: modprobe Tainted: G U E
5.12.0-rc2+ #45
So, this patch fixes the issue by adding "if (napi_direct)" condition
to skip calling xdp_return_frame_no_direct() if napi_direct = false.
Fixes: 2539650fadbf ("xdp: Helpers for disabling napi_direct of
xdp_return_frame")
Signed-off-by: Ong Boon Leong
---
net/core/xdp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/core/xdp.c b/net/core/xdp.c
index 05354976c1fc..4eaa28972af2 100644
--- a/net/core/xdp.c
+++ b/net/core/xdp.c
@@ -350,7 +350,8 @@ static void __xdp_return(void *data, struct xdp_mem_info
*mem, bool napi_direct,
/* mem->id is valid, checked in xdp_rxq_info_reg_mem_model() */
xa = rhashtable_lookup(mem_id_ht, &mem->id, mem_id_rht_params);
page = virt_to_head_page(data);
- napi_direct &= !xdp_return_frame_no_direct();
+ if (napi_direct)
+ napi_direct &= !xdp_return_frame_no_direct();
page_pool_put_full_page(xa->page_pool, page, napi_direct);
rcu_read_unlock();
break;
--
2.25.1
Re: [PATCH V3 1/5] dt-bindings: Added the yaml bindings for DCC
On 2021-03-29 12:02, Souradeep Chowdhury wrote:
Documentation for Data Capture and Compare(DCC) device tree bindings
in yaml format.
Resent this patch by adding the review tag
Link as follows
https://lore.kernel.org/lkml/20210329074909.vpO1kbU39ZSxJpJFZqQc-9i_h5ucqyd4gqZK3a1DQtg@z/
Signed-off-by: Souradeep Chowdhury
---
.../devicetree/bindings/arm/msm/qcom,dcc.yaml | 49
++
1 file changed, 49 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml
b/Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml
new file mode 100644
index 000..c6e0a9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/msm/qcom,dcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Data Capture and Compare
+
+maintainers:
+ - Souradeep Chowdhury
+
+description: |
+DCC (Data Capture and Compare) is a DMA engine which is used to
save
+configuration data or system memory contents during catastrophic
failure
+or SW trigger.DCC is used to capture and store data for debugging
purpose
+
+
+properties:
+ compatible:
+items:
+ - enum:
+ - qcom,sm8150-dcc
+ - const: qcom,dcc
+
+ reg:
+items:
+ - description: DCC base register region
+ - description: DCC RAM base register region
+
+ reg-names:
+items:
+ - const: dcc
+ - const: dcc-ram
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+dcc@10a2000{
+compatible = "qcom,sm8150-dcc","qcom,dcc";
+reg = <0x010a2000 0x1000>,
+ <0x010ad000 0x2000>;
+reg-names = "dcc", "dcc-ram";
+};
[PATCH 4.4 11/33] u64_stats,lockdep: Fix u64_stats_init() vs lockdep
From: Peter Zijlstra
[ Upstream commit d5b0e0677bfd5efd17c5bbb00156931f0d41cb85 ]
Jakub reported that:
static struct net_device *rtl8139_init_board(struct pci_dev *pdev)
{
...
u64_stats_init(&tp->rx_stats.syncp);
u64_stats_init(&tp->tx_stats.syncp);
...
}
results in lockdep getting confused between the RX and TX stats lock.
This is because u64_stats_init() is an inline calling seqcount_init(),
which is a macro using a static variable to generate a lockdep class.
By wrapping that in an inline, we negate the effect of the macro and
fold the static key variable, hence the confusion.
Fix by also making u64_stats_init() a macro for the case where it
matters, leaving the other case an inline for argument validation
etc.
Reported-by: Jakub Kicinski
Debugged-by: "Ahmed S. Darwish"
Signed-off-by: Peter Zijlstra (Intel)
Tested-by: "Erhard F."
Link: https://lkml.kernel.org/r/yexicy6+9mksd...@hirez.programming.kicks-ass.net
Signed-off-by: Sasha Levin
---
include/linux/u64_stats_sync.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/linux/u64_stats_sync.h b/include/linux/u64_stats_sync.h
index df89c9bcba7d..7b38288dc239 100644
--- a/include/linux/u64_stats_sync.h
+++ b/include/linux/u64_stats_sync.h
@@ -68,12 +68,13 @@ struct u64_stats_sync {
};
+#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
+#define u64_stats_init(syncp) seqcount_init(&(syncp)->seq)
+#else
static inline void u64_stats_init(struct u64_stats_sync *syncp)
{
-#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
- seqcount_init(&syncp->seq);
-#endif
}
+#endif
static inline void u64_stats_update_begin(struct u64_stats_sync *syncp)
{
--
2.30.1
[PATCH 4.4 01/33] net: fec: ptp: avoid register access when ipg clock is disabled
From: Heiko Thiery
[ Upstream commit 6a4d7234ae9a3bb31181f348ade9bbdb55aeb5c5 ]
When accessing the timecounter register on an i.MX8MQ the kernel hangs.
This is only the case when the interface is down. This can be reproduced
by reading with 'phc_ctrl eth0 get'.
Like described in the change in 91c0d987a9788dcc5fe26baafd73bf9242b68900
the igp clock is disabled when the interface is down and leads to a
system hang.
So we check if the ptp clock status before reading the timecounter
register.
Signed-off-by: Heiko Thiery
Acked-by: Richard Cochran
Link: https://lore.kernel.org/r/20210225211514.9115-1-heiko.thi...@gmail.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/freescale/fec_ptp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fec_ptp.c
b/drivers/net/ethernet/freescale/fec_ptp.c
index f9e74461bdc0..123181612595 100644
--- a/drivers/net/ethernet/freescale/fec_ptp.c
+++ b/drivers/net/ethernet/freescale/fec_ptp.c
@@ -396,9 +396,16 @@ static int fec_ptp_gettime(struct ptp_clock_info *ptp,
struct timespec64 *ts)
u64 ns;
unsigned long flags;
+ mutex_lock(&adapter->ptp_clk_mutex);
+ /* Check the ptp clock */
+ if (!adapter->ptp_clk_on) {
+ mutex_unlock(&adapter->ptp_clk_mutex);
+ return -EINVAL;
+ }
spin_lock_irqsave(&adapter->tmreg_lock, flags);
ns = timecounter_read(&adapter->tc);
spin_unlock_irqrestore(&adapter->tmreg_lock, flags);
+ mutex_unlock(&adapter->ptp_clk_mutex);
*ts = ns_to_timespec64(ns);
--
2.30.1
[PATCH 4.4 13/33] ia64: fix ia64_syscall_get_set_arguments() for break-based syscalls
From: Sergei Trofimovich
[ Upstream commit 0ceb1ace4a2778e34a5414e5349712ae4dc41d85 ]
In https://bugs.gentoo.org/769614 Dmitry noticed that
`ptrace(PTRACE_GET_SYSCALL_INFO)` does not work for syscalls called via
glibc's syscall() wrapper.
ia64 has two ways to call syscalls from userspace: via `break` and via
`eps` instructions.
The difference is in stack layout:
1. `eps` creates simple stack frame: no locals, in{0..7} == out{0..8}
2. `break` uses userspace stack frame: may be locals (glibc provides
one), in{0..7} == out{0..8}.
Both work fine in syscall handling cde itself.
But `ptrace(PTRACE_GET_SYSCALL_INFO)` uses unwind mechanism to
re-extract syscall arguments but it does not account for locals.
The change always skips locals registers. It should not change `eps`
path as kernel's handler already enforces locals=0 and fixes `break`.
Tested on v5.10 on rx3600 machine (ia64 9040 CPU).
Link: https://lkml.kernel.org/r/20210221002554.333076-1-sly...@gentoo.org
Link: https://bugs.gentoo.org/769614
Signed-off-by: Sergei Trofimovich
Reported-by: Dmitry V. Levin
Cc: Oleg Nesterov
Cc: John Paul Adrian Glaubitz
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
arch/ia64/kernel/ptrace.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/arch/ia64/kernel/ptrace.c b/arch/ia64/kernel/ptrace.c
index 6f54d511cc50..a757b123ebaf 100644
--- a/arch/ia64/kernel/ptrace.c
+++ b/arch/ia64/kernel/ptrace.c
@@ -2140,27 +2140,39 @@ static void syscall_get_set_args_cb(struct
unw_frame_info *info, void *data)
{
struct syscall_get_set_args *args = data;
struct pt_regs *pt = args->regs;
- unsigned long *krbs, cfm, ndirty;
+ unsigned long *krbs, cfm, ndirty, nlocals, nouts;
int i, count;
if (unw_unwind_to_user(info) < 0)
return;
+ /*
+* We get here via a few paths:
+* - break instruction: cfm is shared with caller.
+* syscall args are in out= regs, locals are non-empty.
+* - epsinstruction: cfm is set by br.call
+* locals don't exist.
+*
+* For both cases argguments are reachable in cfm.sof - cfm.sol.
+* CFM: [ ... | sor: 17..14 | sol : 13..7 | sof : 6..0 ]
+*/
cfm = pt->cr_ifs;
+ nlocals = (cfm >> 7) & 0x7f; /* aka sol */
+ nouts = (cfm & 0x7f) - nlocals; /* aka sof - sol */
krbs = (unsigned long *)info->task + IA64_RBS_OFFSET/8;
ndirty = ia64_rse_num_regs(krbs, krbs + (pt->loadrs >> 19));
count = 0;
if (in_syscall(pt))
- count = min_t(int, args->n, cfm & 0x7f);
+ count = min_t(int, args->n, nouts);
+ /* Iterate over outs. */
for (i = 0; i < count; i++) {
+ int j = ndirty + nlocals + i + args->i;
if (args->rw)
- *ia64_rse_skip_regs(krbs, ndirty + i + args->i) =
- args->args[i];
+ *ia64_rse_skip_regs(krbs, j) = args->args[i];
else
- args->args[i] = *ia64_rse_skip_regs(krbs,
- ndirty + i + args->i);
+ args->args[i] = *ia64_rse_skip_regs(krbs, j);
}
if (!args->rw) {
--
2.30.1
[PATCH 4.4 10/33] atm: idt77252: fix null-ptr-dereference
From: Tong Zhang
[ Upstream commit 4416e98594dc04590ebc498fc4e530009535c511 ]
this one is similar to the phy_data allocation fix in uPD98402, the
driver allocate the idt77105_priv and store to dev_data but later
dereference using dev->dev_data, which will cause null-ptr-dereference.
fix this issue by changing dev_data to phy_data so that PRIV(dev) can
work correctly.
Signed-off-by: Tong Zhang
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/atm/idt77105.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/atm/idt77105.c b/drivers/atm/idt77105.c
index feb023d7eebd..40644670cff2 100644
--- a/drivers/atm/idt77105.c
+++ b/drivers/atm/idt77105.c
@@ -261,7 +261,7 @@ static int idt77105_start(struct atm_dev *dev)
{
unsigned long flags;
- if (!(dev->dev_data = kmalloc(sizeof(struct idt77105_priv),GFP_KERNEL)))
+ if (!(dev->phy_data = kmalloc(sizeof(struct idt77105_priv),GFP_KERNEL)))
return -ENOMEM;
PRIV(dev)->dev = dev;
spin_lock_irqsave(&idt77105_priv_lock, flags);
@@ -338,7 +338,7 @@ static int idt77105_stop(struct atm_dev *dev)
else
idt77105_all = walk->next;
dev->phy = NULL;
-dev->dev_data = NULL;
+dev->phy_data = NULL;
kfree(walk);
break;
}
--
2.30.1
[PATCH 4.4 12/33] nfs: we dont support removing system.nfs4_acl
From: J. Bruce Fields [ Upstream commit 4f8be1f53bf615102d103c0509ffa9596f65b718 ] The NFSv4 protocol doesn't have any notion of reomoving an attribute, so removexattr(path,"system.nfs4_acl") doesn't make sense. There's no documented return value. Arguably it could be EOPNOTSUPP but I'm a little worried an application might take that to mean that we don't support ACLs or xattrs. How about EINVAL? Signed-off-by: J. Bruce Fields Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin --- fs/nfs/nfs4proc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 0c9386978d9d..92ca753723b5 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -4848,6 +4848,9 @@ static int __nfs4_proc_set_acl(struct inode *inode, const void *buf, size_t bufl unsigned int npages = DIV_ROUND_UP(buflen, PAGE_SIZE); int ret, i; + /* You can't remove system.nfs4_acl: */ + if (buflen == 0) + return -EINVAL; if (!nfs4_server_supports_acls(server)) return -EOPNOTSUPP; if (npages > ARRAY_SIZE(pages)) -- 2.30.1
[PATCH 4.4 14/33] ia64: fix ptrace(PTRACE_SYSCALL_INFO_EXIT) sign
From: Sergei Trofimovich
[ Upstream commit 61bf318eac2c13356f7bd1c6a05421ef504ccc8a ]
In https://bugs.gentoo.org/769614 Dmitry noticed that
`ptrace(PTRACE_GET_SYSCALL_INFO)` does not return error sign properly.
The bug is in mismatch between get/set errors:
static inline long syscall_get_error(struct task_struct *task,
struct pt_regs *regs)
{
return regs->r10 == -1 ? regs->r8:0;
}
static inline long syscall_get_return_value(struct task_struct *task,
struct pt_regs *regs)
{
return regs->r8;
}
static inline void syscall_set_return_value(struct task_struct *task,
struct pt_regs *regs,
int error, long val)
{
if (error) {
/* error < 0, but ia64 uses > 0 return value */
regs->r8 = -error;
regs->r10 = -1;
} else {
regs->r8 = val;
regs->r10 = 0;
}
}
Tested on v5.10 on rx3600 machine (ia64 9040 CPU).
Link: https://lkml.kernel.org/r/20210221002554.333076-2-sly...@gentoo.org
Link: https://bugs.gentoo.org/769614
Signed-off-by: Sergei Trofimovich
Reported-by: Dmitry V. Levin
Reviewed-by: Dmitry V. Levin
Cc: John Paul Adrian Glaubitz
Cc: Oleg Nesterov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
arch/ia64/include/asm/syscall.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/ia64/include/asm/syscall.h b/arch/ia64/include/asm/syscall.h
index 1d0b875fec44..ec909eec0b4c 100644
--- a/arch/ia64/include/asm/syscall.h
+++ b/arch/ia64/include/asm/syscall.h
@@ -35,7 +35,7 @@ static inline void syscall_rollback(struct task_struct *task,
static inline long syscall_get_error(struct task_struct *task,
struct pt_regs *regs)
{
- return regs->r10 == -1 ? regs->r8:0;
+ return regs->r10 == -1 ? -regs->r8:0;
}
static inline long syscall_get_return_value(struct task_struct *task,
--
2.30.1
[PATCH 4.4 15/33] x86/tlb: Flush global mappings when KAISER is disabled
From: Borislav Petkov
Jim Mattson reported that Debian 9 guests using a 4.9-stable kernel
are exploding during alternatives patching:
kernel BUG at
/build/linux-dqnRSc/linux-4.9.228/arch/x86/kernel/alternative.c:709!
invalid opcode: [#1] SMP
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.9.0-13-amd64 #1 Debian 4.9.228-1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
swap_entry_free
swap_entry_free
text_poke_bp
swap_entry_free
arch_jump_label_transform
set_debug_rodata
__jump_label_update
static_key_slow_inc
frontswap_register_ops
init_zswap
init_frontswap
do_one_initcall
set_debug_rodata
kernel_init_freeable
rest_init
kernel_init
ret_from_fork
triggering the BUG_ON in text_poke() which verifies whether patched
instruction bytes have actually landed at the destination.
Further debugging showed that the TLB flush before that check is
insufficient because there could be global mappings left in the TLB,
leading to a stale mapping getting used.
I say "global mappings" because the hardware configuration is a new one:
machine is an AMD, which means, KAISER/PTI doesn't need to be enabled
there, which also means there's no user/kernel pagetables split and
therefore the TLB can have global mappings.
And the configuration is new one for a second reason: because that AMD
machine supports PCID and INVPCID, which leads the CPU detection code to
set the synthetic X86_FEATURE_INVPCID_SINGLE flag.
Now, __native_flush_tlb_single() does invalidate global mappings when
X86_FEATURE_INVPCID_SINGLE is *not* set and returns.
When X86_FEATURE_INVPCID_SINGLE is set, however, it invalidates the
requested address from both PCIDs in the KAISER-enabled case. But if
KAISER is not enabled and the machine has global mappings in the TLB,
then those global mappings do not get invalidated, which would lead to
the above mismatch from using a stale TLB entry.
So make sure to flush those global mappings in the KAISER disabled case.
Co-debugged by Babu Moger .
Reported-by: Jim Mattson
Signed-off-by: Borislav Petkov
Acked-by: Hugh Dickins
Reviewed-by: Paolo Bonzini
Tested-by: Babu Moger
Tested-by: Jim Mattson
Link:
https://lkml.kernel.org/r/CALMp9eRDSW66%2BXvbHVF4ohL7XhThoPoT0BrB0TcS0cgk=dk...@mail.gmail.com
Signed-off-by: Sasha Levin
---
arch/x86/include/asm/tlbflush.h | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 8dab88b85785..33a594f728de 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -245,12 +245,15 @@ static inline void __native_flush_tlb_single(unsigned
long addr)
* ASID. But, userspace flushes are probably much more
* important performance-wise.
*
-* Make sure to do only a single invpcid when KAISER is
-* disabled and we have only a single ASID.
+* In the KAISER disabled case, do an INVLPG to make sure
+* the mapping is flushed in case it is a global one.
*/
- if (kaiser_enabled)
+ if (kaiser_enabled) {
invpcid_flush_one(X86_CR3_PCID_ASID_USER, addr);
- invpcid_flush_one(X86_CR3_PCID_ASID_KERN, addr);
+ invpcid_flush_one(X86_CR3_PCID_ASID_KERN, addr);
+ } else {
+ asm volatile("invlpg (%0)" ::"r" (addr) : "memory");
+ }
}
static inline void __flush_tlb_all(void)
--
2.30.1
[PATCH 4.4 16/33] squashfs: fix inode lookup sanity checks
From: Sean Nyekjaer
commit c1b2028315c6b15e8d6725e0d5884b15887d3daa upstream.
When mouting a squashfs image created without inode compression it fails
with: "unable to read inode lookup table"
It turns out that the BLOCK_OFFSET is missing when checking the
SQUASHFS_METADATA_SIZE agaist the actual size.
Link: https://lkml.kernel.org/r/20210226092903.1473545-1-s...@geanix.com
Fixes: eabac19e40c0 ("squashfs: add more sanity checks in inode lookup")
Signed-off-by: Sean Nyekjaer
Acked-by: Phillip Lougher
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
fs/squashfs/export.c |8 ++--
fs/squashfs/squashfs_fs.h |1 +
2 files changed, 7 insertions(+), 2 deletions(-)
--- a/fs/squashfs/export.c
+++ b/fs/squashfs/export.c
@@ -165,14 +165,18 @@ __le64 *squashfs_read_inode_lookup_table
start = le64_to_cpu(table[n]);
end = le64_to_cpu(table[n + 1]);
- if (start >= end || (end - start) > SQUASHFS_METADATA_SIZE) {
+ if (start >= end
+ || (end - start) >
+ (SQUASHFS_METADATA_SIZE + SQUASHFS_BLOCK_OFFSET)) {
kfree(table);
return ERR_PTR(-EINVAL);
}
}
start = le64_to_cpu(table[indexes - 1]);
- if (start >= lookup_table_start || (lookup_table_start - start) >
SQUASHFS_METADATA_SIZE) {
+ if (start >= lookup_table_start ||
+ (lookup_table_start - start) >
+ (SQUASHFS_METADATA_SIZE + SQUASHFS_BLOCK_OFFSET)) {
kfree(table);
return ERR_PTR(-EINVAL);
}
--- a/fs/squashfs/squashfs_fs.h
+++ b/fs/squashfs/squashfs_fs.h
@@ -30,6 +30,7 @@
/* size of metadata (inode and directory) blocks */
#define SQUASHFS_METADATA_SIZE 8192
+#define SQUASHFS_BLOCK_OFFSET 2
/* default size of block device I/O */
#ifdef CONFIG_SQUASHFS_4K_DEVBLK_SIZE
[PATCH 4.4 17/33] squashfs: fix xattr id and id lookup sanity checks
From: Phillip Lougher
commit 8b44ca2b634527151af07447a8090a5f3a043321 upstream.
The checks for maximum metadata block size is missing
SQUASHFS_BLOCK_OFFSET (the two byte length count).
Link:
https://lkml.kernel.org/r/2069685113.2081245.1614583677...@webmail.123-reg.co.uk
Fixes: f37aa4c7366e23f ("squashfs: add more sanity checks in id lookup")
Signed-off-by: Phillip Lougher
Cc: Sean Nyekjaer
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
fs/squashfs/id.c |6 --
fs/squashfs/xattr_id.c |6 --
2 files changed, 8 insertions(+), 4 deletions(-)
--- a/fs/squashfs/id.c
+++ b/fs/squashfs/id.c
@@ -110,14 +110,16 @@ __le64 *squashfs_read_id_index_table(str
start = le64_to_cpu(table[n]);
end = le64_to_cpu(table[n + 1]);
- if (start >= end || (end - start) > SQUASHFS_METADATA_SIZE) {
+ if (start >= end || (end - start) >
+ (SQUASHFS_METADATA_SIZE +
SQUASHFS_BLOCK_OFFSET)) {
kfree(table);
return ERR_PTR(-EINVAL);
}
}
start = le64_to_cpu(table[indexes - 1]);
- if (start >= id_table_start || (id_table_start - start) >
SQUASHFS_METADATA_SIZE) {
+ if (start >= id_table_start || (id_table_start - start) >
+ (SQUASHFS_METADATA_SIZE +
SQUASHFS_BLOCK_OFFSET)) {
kfree(table);
return ERR_PTR(-EINVAL);
}
--- a/fs/squashfs/xattr_id.c
+++ b/fs/squashfs/xattr_id.c
@@ -122,14 +122,16 @@ __le64 *squashfs_read_xattr_id_table(str
start = le64_to_cpu(table[n]);
end = le64_to_cpu(table[n + 1]);
- if (start >= end || (end - start) > SQUASHFS_METADATA_SIZE) {
+ if (start >= end || (end - start) >
+ (SQUASHFS_METADATA_SIZE +
SQUASHFS_BLOCK_OFFSET)) {
kfree(table);
return ERR_PTR(-EINVAL);
}
}
start = le64_to_cpu(table[indexes - 1]);
- if (start >= table_start || (table_start - start) >
SQUASHFS_METADATA_SIZE) {
+ if (start >= table_start || (table_start - start) >
+ (SQUASHFS_METADATA_SIZE +
SQUASHFS_BLOCK_OFFSET)) {
kfree(table);
return ERR_PTR(-EINVAL);
}
[PATCH 4.4 18/33] bus: omap_l3_noc: mark l3 irqs as IRQF_NO_THREAD
From: Grygorii Strashko
[ Upstream commit 7d7275b3e866cf8092bd12553ec53ba26864f7bb ]
The main purpose of l3 IRQs is to catch OCP bus access errors and identify
corresponding code places by showing call stack, so it's important to
handle L3 interconnect errors as fast as possible. On RT these IRQs will
became threaded and will be scheduled much more late from the moment actual
error occurred so showing completely useless information.
Hence, mark l3 IRQs as IRQF_NO_THREAD so they will not be forced threaded
on RT or if force_irqthreads = true.
Fixes: 0ee7261c9212 ("drivers: bus: Move the OMAP interconnect driver to
drivers/bus/")
Signed-off-by: Grygorii Strashko
Signed-off-by: Tony Lindgren
Signed-off-by: Sasha Levin
---
drivers/bus/omap_l3_noc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 5012e3ad1225..624f74d03a83 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -285,7 +285,7 @@ static int omap_l3_probe(struct platform_device *pdev)
*/
l3->debug_irq = platform_get_irq(pdev, 0);
ret = devm_request_irq(l3->dev, l3->debug_irq, l3_interrupt_handler,
- 0x0, "l3-dbg-irq", l3);
+ IRQF_NO_THREAD, "l3-dbg-irq", l3);
if (ret) {
dev_err(l3->dev, "request_irq failed for %d\n",
l3->debug_irq);
@@ -294,7 +294,7 @@ static int omap_l3_probe(struct platform_device *pdev)
l3->app_irq = platform_get_irq(pdev, 1);
ret = devm_request_irq(l3->dev, l3->app_irq, l3_interrupt_handler,
- 0x0, "l3-app-irq", l3);
+ IRQF_NO_THREAD, "l3-app-irq", l3);
if (ret)
dev_err(l3->dev, "request_irq failed for %d\n", l3->app_irq);
--
2.30.1
[PATCH 4.4 19/33] macvlan: macvlan_count_rx() needs to be aware of preemption
From: Eric Dumazet
[ Upstream commit dd4fa1dae9f4847cc1fd78ca468ad69e16e5db3e ]
macvlan_count_rx() can be called from process context, it is thus
necessary to disable preemption before calling u64_stats_update_begin()
syzbot was able to spot this on 32bit arch:
WARNING: CPU: 1 PID: 4632 at include/linux/seqlock.h:271 __seqprop_assert
include/linux/seqlock.h:271 [inline]
WARNING: CPU: 1 PID: 4632 at include/linux/seqlock.h:271
__seqprop_assert.constprop.0+0xf0/0x11c include/linux/seqlock.h:269
Modules linked in:
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 4632 Comm: kworker/1:3 Not tainted 5.12.0-rc2-syzkaller #0
Hardware name: ARM-Versatile Express
Workqueue: events macvlan_process_broadcast
Backtrace:
[<82740468>] (dump_backtrace) from [<827406dc>] (show_stack+0x18/0x1c
arch/arm/kernel/traps.c:252)
r7:0080 r6:6093 r5: r4:8422a3c4
[<827406c4>] (show_stack) from [<82751b58>] (__dump_stack lib/dump_stack.c:79
[inline])
[<827406c4>] (show_stack) from [<82751b58>] (dump_stack+0xb8/0xe8
lib/dump_stack.c:120)
[<82751aa0>] (dump_stack) from [<82741270>] (panic+0x130/0x378
kernel/panic.c:231)
r7:830209b4 r6:84069ea4 r5: r4:844350d0
[<82741140>] (panic) from [<80244924>] (__warn+0xb0/0x164 kernel/panic.c:605)
r3:8404ec8c r2: r1: r0:830209b4
r7:010f
[<80244874>] (__warn) from [<82741520>] (warn_slowpath_fmt+0x68/0xd4
kernel/panic.c:628)
r7:81363f70 r6:010f r5:83018e50 r4:
[<827414bc>] (warn_slowpath_fmt) from [<81363f70>] (__seqprop_assert
include/linux/seqlock.h:271 [inline])
[<827414bc>] (warn_slowpath_fmt) from [<81363f70>]
(__seqprop_assert.constprop.0+0xf0/0x11c include/linux/seqlock.h:269)
r8:5a109000 r7:000f r6:a568dac0 r5:89802300 r4:0001
[<81363e80>] (__seqprop_assert.constprop.0) from [<81364af0>]
(u64_stats_update_begin include/linux/u64_stats_sync.h:128 [inline])
[<81363e80>] (__seqprop_assert.constprop.0) from [<81364af0>] (macvlan_count_rx
include/linux/if_macvlan.h:47 [inline])
[<81363e80>] (__seqprop_assert.constprop.0) from [<81364af0>]
(macvlan_broadcast+0x154/0x26c drivers/net/macvlan.c:291)
r5:89802300 r4:8a927740
[<8136499c>] (macvlan_broadcast) from [<81365020>]
(macvlan_process_broadcast+0x258/0x2d0 drivers/net/macvlan.c:317)
r10:81364f78 r9:8a86d000 r8:8a9c7e7c r7:8413aa5c r6: r5:
r4:89802840
[<81364dc8>] (macvlan_process_broadcast) from [<802696a4>]
(process_one_work+0x2d4/0x998 kernel/workqueue.c:2275)
r10:0008 r9:8404ec98 r8:84367a02 r7:ddfe6400 r6:ddfe2d40 r5:898dac80
r4:8a86d43c
[<802693d0>] (process_one_work) from [<80269dcc>] (worker_thread+0x64/0x54c
kernel/workqueue.c:2421)
r10:0008 r9:8a9c6000 r8:84006d00 r7:ddfe2d78 r6:898dac94 r5:ddfe2d40
r4:898dac80
[<80269d68>] (worker_thread) from [<80271f40>] (kthread+0x184/0x1a4
kernel/kthread.c:292)
r10:85247e64 r9:898dac80 r8:80269d68 r7: r6:8a9c6000 r5:89a2ee40
r4:8a97bd00
[<80271dbc>] (kthread) from [<80200114>] (ret_from_fork+0x14/0x20
arch/arm/kernel/entry-common.S:158)
Exception stack(0x8a9c7fb0 to 0x8a9c7ff8)
Fixes: 412ca1550cbe ("macvlan: Move broadcasts into a work queue")
Signed-off-by: Eric Dumazet
Cc: Herbert Xu
Reported-by: syzbot
Acked-by: Herbert Xu
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
include/linux/if_macvlan.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/if_macvlan.h b/include/linux/if_macvlan.h
index a4ccc3122f93..cfcbc49f4ddf 100644
--- a/include/linux/if_macvlan.h
+++ b/include/linux/if_macvlan.h
@@ -70,13 +70,14 @@ static inline void macvlan_count_rx(const struct
macvlan_dev *vlan,
if (likely(success)) {
struct vlan_pcpu_stats *pcpu_stats;
- pcpu_stats = this_cpu_ptr(vlan->pcpu_stats);
+ pcpu_stats = get_cpu_ptr(vlan->pcpu_stats);
u64_stats_update_begin(&pcpu_stats->syncp);
pcpu_stats->rx_packets++;
pcpu_stats->rx_bytes += len;
if (multicast)
pcpu_stats->rx_multicast++;
u64_stats_update_end(&pcpu_stats->syncp);
+ put_cpu_ptr(vlan->pcpu_stats);
} else {
this_cpu_inc(vlan->pcpu_stats->rx_errors);
}
--
2.30.1
[PATCH 4.4 02/33] powerpc/4xx: Fix build errors from mfdcr()
From: Michael Ellerman
[ Upstream commit eead089311f4d935ab5d1d8fbb0c42ad44699ada ]
lkp reported a build error in fsp2.o:
CC arch/powerpc/platforms/44x/fsp2.o
{standard input}:577: Error: unsupported relocation against base
Which comes from:
pr_err("GESR0: 0x%08x\n", mfdcr(base + PLB4OPB_GESR0));
Where our mfdcr() macro is stringifying "base + PLB4OPB_GESR0", and
passing that to the assembler, which obviously doesn't work.
The mfdcr() macro already checks that the argument is constant using
__builtin_constant_p(), and if not calls the out-of-line version of
mfdcr(). But in this case GCC is smart enough to notice that "base +
PLB4OPB_GESR0" will be constant, even though it's not something we can
immediately stringify into a register number.
Segher pointed out that passing the register number to the inline asm
as a constant would be better, and in fact it fixes the build error,
presumably because it gives GCC a chance to resolve the value.
While we're at it, change mtdcr() similarly.
Reported-by: kernel test robot
Suggested-by: Segher Boessenkool
Signed-off-by: Michael Ellerman
Acked-by: Feng Tang
Link: https://lore.kernel.org/r/20210218123058.748882-1-...@ellerman.id.au
Signed-off-by: Sasha Levin
---
arch/powerpc/include/asm/dcr-native.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/dcr-native.h
b/arch/powerpc/include/asm/dcr-native.h
index 4efc11dacb98..4494d5e1932f 100644
--- a/arch/powerpc/include/asm/dcr-native.h
+++ b/arch/powerpc/include/asm/dcr-native.h
@@ -64,8 +64,8 @@ static inline void mtdcrx(unsigned int reg, unsigned int val)
#define mfdcr(rn) \
({unsigned int rval;\
if (__builtin_constant_p(rn) && rn < 1024) \
- asm volatile("mfdcr %0," __stringify(rn)\
- : "=r" (rval)); \
+ asm volatile("mfdcr %0, %1" : "=r" (rval) \
+ : "n" (rn)); \
else if (likely(cpu_has_feature(CPU_FTR_INDEXED_DCR))) \
rval = mfdcrx(rn); \
else\
@@ -75,8 +75,8 @@ static inline void mtdcrx(unsigned int reg, unsigned int val)
#define mtdcr(rn, v) \
do { \
if (__builtin_constant_p(rn) && rn < 1024) \
- asm volatile("mtdcr " __stringify(rn) ",%0" \
- : : "r" (v)); \
+ asm volatile("mtdcr %0, %1" \
+ : : "n" (rn), "r" (v)); \
else if (likely(cpu_has_feature(CPU_FTR_INDEXED_DCR))) \
mtdcrx(rn, v); \
else\
--
2.30.1
[PATCH 4.4 20/33] net: dsa: bcm_sf2: Qualify phydev->dev_flags based on port
From: Florian Fainelli
[ Upstream commit 47142ed6c34d544ae9f0463e58d482289cbe0d46 ]
Similar to commit 92696286f3bb37ba50e4bd8d1beb24afb759a799 ("net:
bcmgenet: Set phydev->dev_flags only for internal PHYs") we need to
qualify the phydev->dev_flags based on whether the port is connected to
an internal or external PHY otherwise we risk having a flags collision
with a completely different interpretation depending on the driver.
Fixes: aa9aef77c761 ("net: dsa: bcm_sf2: communicate integrated PHY revision to
PHY driver")
Signed-off-by: Florian Fainelli
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/dsa/bcm_sf2.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 0864f05633a2..a56f4f3a5872 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -1067,8 +1067,10 @@ static u32 bcm_sf2_sw_get_phy_flags(struct dsa_switch
*ds, int port)
* in bits 15:8 and the patch level in bits 7:0 which is exactly what
* the REG_PHY_REVISION register layout is.
*/
-
- return priv->hw_params.gphy_rev;
+ if (priv->int_phy_mask & BIT(port))
+ return priv->hw_params.gphy_rev;
+ else
+ return 0;
}
static int bcm_sf2_sw_indir_rw(struct dsa_switch *ds, int op, int addr,
--
2.30.1
[PATCH 4.4 21/33] e1000e: add rtnl_lock() to e1000_reset_task
From: Vitaly Lifshits
[ Upstream commit 21f857f0321d0d0ea9b1a758bd55dc63d1cb2437 ]
A possible race condition was found in e1000_reset_task,
after discovering a similar issue in igb driver via
commit 024a8168b749 ("igb: reinit_locked() should be called
with rtnl_lock").
Added rtnl_lock() and rtnl_unlock() to avoid this.
Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently for
ICH9 devices only)")
Suggested-by: Jakub Kicinski
Signed-off-by: Vitaly Lifshits
Tested-by: Dvora Fuxbrumer
Signed-off-by: Tony Nguyen
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/intel/e1000e/netdev.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 3bd0bdbdfa0e..a8ee20ecb3ad 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5875,15 +5875,19 @@ static void e1000_reset_task(struct work_struct *work)
struct e1000_adapter *adapter;
adapter = container_of(work, struct e1000_adapter, reset_task);
+ rtnl_lock();
/* don't run the task if already down */
- if (test_bit(__E1000_DOWN, &adapter->state))
+ if (test_bit(__E1000_DOWN, &adapter->state)) {
+ rtnl_unlock();
return;
+ }
if (!(adapter->flags & FLAG_RESTART_NOW)) {
e1000e_dump(adapter);
e_err("Reset adapter unexpectedly\n");
}
e1000e_reinit_locked(adapter);
+ rtnl_unlock();
}
/**
--
2.30.1
[PATCH 4.4 22/33] e1000e: Fix error handling in e1000_set_d0_lplu_state_82571
From: Dinghao Liu
[ Upstream commit b52912b8293f2c496f42583e65599aee606a0c18 ]
There is one e1e_wphy() call in e1000_set_d0_lplu_state_82571
that we have caught its return value but lack further handling.
Check and terminate the execution flow just like other e1e_wphy()
in this function.
Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently for
ICH9 devices only)")
Signed-off-by: Dinghao Liu
Acked-by: Sasha Neftin
Tested-by: Dvora Fuxbrumer
Signed-off-by: Tony Nguyen
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/intel/e1000e/82571.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000e/82571.c
b/drivers/net/ethernet/intel/e1000e/82571.c
index 5f7016442ec4..e486f351a54a 100644
--- a/drivers/net/ethernet/intel/e1000e/82571.c
+++ b/drivers/net/ethernet/intel/e1000e/82571.c
@@ -917,6 +917,8 @@ static s32 e1000_set_d0_lplu_state_82571(struct e1000_hw
*hw, bool active)
} else {
data &= ~IGP02E1000_PM_D0_LPLU;
ret_val = e1e_wphy(hw, IGP02E1000_PHY_POWER_MGMT, data);
+ if (ret_val)
+ return ret_val;
/* LPLU and SmartSpeed are mutually exclusive. LPLU is used
* during Dx states where the power conservation is most
* important. During driver activity we should enable
--
2.30.1
