[tip:perf/core] perf annotate: Fix missing number of samples for source_line_samples

[tip-bot for Taeung Song]

Commit-ID:  99094a5e941fe88d95cbd594e6a41bee24003ecb
Gitweb: http://git.kernel.org/tip/99094a5e941fe88d95cbd594e6a41bee24003ecb
Author: Taeung Song 
AuthorDate: Tue, 28 Mar 2017 21:12:05 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 4 Apr 2017 21:08:00 -0300

perf annotate: Fix missing number of samples for source_line_samples

The option 'show-total-period' works fine without a option '-l'.  But if
running 'perf annotate --stdio -l --show-total-period', you can see a
problem showing only zero '0' for number of samples.

Before:
$ perf annotate --stdio -l --show-total-period
...
   0 :400816:   push   %rbp
   0 :400817:   mov%rsp,%rbp
   0 :40081a:   mov%edi,-0x24(%rbp)
   0 :40081d:   mov%rsi,-0x30(%rbp)
   0 :400821:   mov-0x24(%rbp),%eax
   0 :400824:   mov-0x30(%rbp),%rdx
   0 :400828:   mov(%rdx),%esi
   0 :40082a:   mov$0x0,%edx
...

The reason is it was missed to set number of samples of
source_line_samples, so set it ordinarily.

After:
$ perf annotate --stdio -l --show-total-period
...
   3 :400816:   push   %rbp
   4 :400817:   mov%rsp,%rbp
   0 :40081a:   mov%edi,-0x24(%rbp)
   0 :40081d:   mov%rsi,-0x30(%rbp)
   1 :400821:   mov-0x24(%rbp),%eax
   2 :400824:   mov-0x30(%rbp),%rdx
   0 :400828:   mov(%rdx),%esi
   1 :40082a:   mov$0x0,%edx
...

Signed-off-by: Taeung Song 
Cc: Jiri Olsa 
Cc: Martin Liska 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Fixes: 0c4a5bcea460 ("perf annotate: Display total number of samples with 
--show-total-period")
Link: 
http://lkml.kernel.org/r/1490703125-13643-1-git-send-email-treeze.tae...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/annotate.c | 6 --
 tools/perf/util/annotate.h | 2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 11af5f0..a37032b 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1665,7 +1665,7 @@ static int symbol__get_source_line(struct symbol *sym, 
struct map *map,
start = map__rip_2objdump(map, sym->start);
 
for (i = 0; i < len; i++) {
-   u64 offset;
+   u64 offset, nr_samples;
double percent_max = 0.0;
 
src_line->nr_pcnt = nr_pcnt;
@@ -1674,12 +1674,14 @@ static int symbol__get_source_line(struct symbol *sym, 
struct map *map,
double percent = 0.0;
 
h = annotation__histogram(notes, evidx + k);
+   nr_samples = h->addr[i];
if (h->sum)
-   percent = 100.0 * h->addr[i] / h->sum;
+   percent = 100.0 * nr_samples / h->sum;
 
if (percent > percent_max)
percent_max = percent;
src_line->samples[k].percent = percent;
+   src_line->samples[k].nr = nr_samples;
}
 
if (percent_max <= 0.5)
diff --git a/tools/perf/util/annotate.h b/tools/perf/util/annotate.h
index 09776b5..948aa8e 100644
--- a/tools/perf/util/annotate.h
+++ b/tools/perf/util/annotate.h
@@ -98,7 +98,7 @@ struct cyc_hist {
 struct source_line_samples {
double  percent;
double  percent_sum;
-   double  nr;
+   u64 nr;
 };
 
 struct source_line {

[tip:perf/core] perf annotate: Fix missing number of samples for source_line_samples

[tip-bot for Taeung Song]

Commit-ID:  99094a5e941fe88d95cbd594e6a41bee24003ecb
Gitweb: http://git.kernel.org/tip/99094a5e941fe88d95cbd594e6a41bee24003ecb
Author: Taeung Song 
AuthorDate: Tue, 28 Mar 2017 21:12:05 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 4 Apr 2017 21:08:00 -0300

perf annotate: Fix missing number of samples for source_line_samples

The option 'show-total-period' works fine without a option '-l'.  But if
running 'perf annotate --stdio -l --show-total-period', you can see a
problem showing only zero '0' for number of samples.

Before:
$ perf annotate --stdio -l --show-total-period
...
   0 :400816:   push   %rbp
   0 :400817:   mov%rsp,%rbp
   0 :40081a:   mov%edi,-0x24(%rbp)
   0 :40081d:   mov%rsi,-0x30(%rbp)
   0 :400821:   mov-0x24(%rbp),%eax
   0 :400824:   mov-0x30(%rbp),%rdx
   0 :400828:   mov(%rdx),%esi
   0 :40082a:   mov$0x0,%edx
...

The reason is it was missed to set number of samples of
source_line_samples, so set it ordinarily.

After:
$ perf annotate --stdio -l --show-total-period
...
   3 :400816:   push   %rbp
   4 :400817:   mov%rsp,%rbp
   0 :40081a:   mov%edi,-0x24(%rbp)
   0 :40081d:   mov%rsi,-0x30(%rbp)
   1 :400821:   mov-0x24(%rbp),%eax
   2 :400824:   mov-0x30(%rbp),%rdx
   0 :400828:   mov(%rdx),%esi
   1 :40082a:   mov$0x0,%edx
...

Signed-off-by: Taeung Song 
Cc: Jiri Olsa 
Cc: Martin Liska 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Fixes: 0c4a5bcea460 ("perf annotate: Display total number of samples with 
--show-total-period")
Link: 
http://lkml.kernel.org/r/1490703125-13643-1-git-send-email-treeze.tae...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/annotate.c | 6 --
 tools/perf/util/annotate.h | 2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 11af5f0..a37032b 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1665,7 +1665,7 @@ static int symbol__get_source_line(struct symbol *sym, 
struct map *map,
start = map__rip_2objdump(map, sym->start);
 
for (i = 0; i < len; i++) {
-   u64 offset;
+   u64 offset, nr_samples;
double percent_max = 0.0;
 
src_line->nr_pcnt = nr_pcnt;
@@ -1674,12 +1674,14 @@ static int symbol__get_source_line(struct symbol *sym, 
struct map *map,
double percent = 0.0;
 
h = annotation__histogram(notes, evidx + k);
+   nr_samples = h->addr[i];
if (h->sum)
-   percent = 100.0 * h->addr[i] / h->sum;
+   percent = 100.0 * nr_samples / h->sum;
 
if (percent > percent_max)
percent_max = percent;
src_line->samples[k].percent = percent;
+   src_line->samples[k].nr = nr_samples;
}
 
if (percent_max <= 0.5)
diff --git a/tools/perf/util/annotate.h b/tools/perf/util/annotate.h
index 09776b5..948aa8e 100644
--- a/tools/perf/util/annotate.h
+++ b/tools/perf/util/annotate.h
@@ -98,7 +98,7 @@ struct cyc_hist {
 struct source_line_samples {
double  percent;
double  percent_sum;
-   double  nr;
+   u64 nr;
 };
 
 struct source_line {

[tip:perf/core] perf sdt powerpc: Add argument support

[tip-bot for Ravi Bangoria]

Commit-ID:  f5a70801b7832bfcb865e95c39bdef8eac21226f
Gitweb: http://git.kernel.org/tip/f5a70801b7832bfcb865e95c39bdef8eac21226f
Author: Ravi Bangoria 
AuthorDate: Tue, 28 Mar 2017 15:17:54 +0530
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 4 Apr 2017 10:36:59 -0300

perf sdt powerpc: Add argument support

SDT marker argument is in N@OP format. Here OP is arch dependent
component. Add powerpc logic to parse OP and convert it to uprobe
compatible format.

Signed-off-by: Ravi Bangoria 
Acked-by: Masami Hiramatsu 
Cc: Alexander Shishkin 
Cc: Alexis Berlemont 
Cc: Hemant Kumar 
Cc: Michael Ellerman 
Cc: Naveen N. Rao 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/20170328094754.3156-4-ravi.bango...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/powerpc/util/perf_regs.c | 111 +++
 1 file changed, 111 insertions(+)

diff --git a/tools/perf/arch/powerpc/util/perf_regs.c 
b/tools/perf/arch/powerpc/util/perf_regs.c
index a3c3e1c..4268f77 100644
--- a/tools/perf/arch/powerpc/util/perf_regs.c
+++ b/tools/perf/arch/powerpc/util/perf_regs.c
@@ -1,5 +1,10 @@
+#include 
+#include 
+
 #include "../../perf.h"
+#include "../../util/util.h"
 #include "../../util/perf_regs.h"
+#include "../../util/debug.h"
 
 const struct sample_reg sample_reg_masks[] = {
SMPL_REG(r0, PERF_REG_POWERPC_R0),
@@ -47,3 +52,109 @@ const struct sample_reg sample_reg_masks[] = {
SMPL_REG(dsisr, PERF_REG_POWERPC_DSISR),
SMPL_REG_END
 };
+
+/* REG or %rREG */
+#define SDT_OP_REGEX1  "^(%r)?([1-2]?[0-9]|3[0-1])$"
+
+/* -NUM(REG) or NUM(REG) or -NUM(%rREG) or NUM(%rREG) */
+#define SDT_OP_REGEX2  "^(\\-)?([0-9]+)\\((%r)?([1-2]?[0-9]|3[0-1])\\)$"
+
+static regex_t sdt_op_regex1, sdt_op_regex2;
+
+static int sdt_init_op_regex(void)
+{
+   static int initialized;
+   int ret = 0;
+
+   if (initialized)
+   return 0;
+
+   ret = regcomp(_op_regex1, SDT_OP_REGEX1, REG_EXTENDED);
+   if (ret)
+   goto error;
+
+   ret = regcomp(_op_regex2, SDT_OP_REGEX2, REG_EXTENDED);
+   if (ret)
+   goto free_regex1;
+
+   initialized = 1;
+   return 0;
+
+free_regex1:
+   regfree(_op_regex1);
+error:
+   pr_debug4("Regex compilation error.\n");
+   return ret;
+}
+
+/*
+ * Parse OP and convert it into uprobe format, which is, +/-NUM(%gprREG).
+ * Possible variants of OP are:
+ * Format  Example
+ * -
+ * NUM(REG)48(18)
+ * -NUM(REG)   -48(18)
+ * NUM(%rREG)  48(%r18)
+ * -NUM(%rREG) -48(%r18)
+ * REG 18
+ * %rREG   %r18
+ * iNUMi0
+ * i-NUM   i-1
+ *
+ * SDT marker arguments on Powerpc uses %rREG form with -mregnames flag
+ * and REG form with -mno-regnames. Here REG is general purpose register,
+ * which is in 0 to 31 range.
+ */
+int arch_sdt_arg_parse_op(char *old_op, char **new_op)
+{
+   int ret, new_len;
+   regmatch_t rm[5];
+   char prefix;
+
+   /* Constant argument. Uprobe does not support it */
+   if (old_op[0] == 'i') {
+   pr_debug4("Skipping unsupported SDT argument: %s\n", old_op);
+   return SDT_ARG_SKIP;
+   }
+
+   ret = sdt_init_op_regex();
+   if (ret < 0)
+   return ret;
+
+   if (!regexec(_op_regex1, old_op, 3, rm, 0)) {
+   /* REG or %rREG --> %gprREG */
+
+   new_len = 5;/* % g p r NULL */
+   new_len += (int)(rm[2].rm_eo - rm[2].rm_so);
+
+   *new_op = zalloc(new_len);
+   if (!*new_op)
+   return -ENOMEM;
+
+   scnprintf(*new_op, new_len, "%%gpr%.*s",
+   (int)(rm[2].rm_eo - rm[2].rm_so), old_op + rm[2].rm_so);
+   } else if (!regexec(_op_regex2, old_op, 5, rm, 0)) {
+   /*
+* -NUM(REG) or NUM(REG) or -NUM(%rREG) or NUM(%rREG) -->
+*  +/-NUM(%gprREG)
+*/
+   prefix = (rm[1].rm_so == -1) ? '+' : '-';
+
+   new_len = 8;/* +/- ( % g p r ) NULL */
+   new_len += (int)(rm[2].rm_eo - rm[2].rm_so);
+   new_len += (int)(rm[4].rm_eo - rm[4].rm_so);
+
+   *new_op = zalloc(new_len);
+   if (!*new_op)
+   return -ENOMEM;
+
+   scnprintf(*new_op, new_len, "%c%.*s(%%gpr%.*s)", prefix,
+   (int)(rm[2].rm_eo - rm[2].rm_so), old_op + rm[2].rm_so,
+   (int)(rm[4].rm_eo - rm[4].rm_so), old_op + rm[4].rm_so);
+   } else {
+   pr_debug4("Skipping 

[tip:perf/core] perf sdt powerpc: Add argument support

[tip-bot for Ravi Bangoria]

Commit-ID:  f5a70801b7832bfcb865e95c39bdef8eac21226f
Gitweb: http://git.kernel.org/tip/f5a70801b7832bfcb865e95c39bdef8eac21226f
Author: Ravi Bangoria 
AuthorDate: Tue, 28 Mar 2017 15:17:54 +0530
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 4 Apr 2017 10:36:59 -0300

perf sdt powerpc: Add argument support

SDT marker argument is in N@OP format. Here OP is arch dependent
component. Add powerpc logic to parse OP and convert it to uprobe
compatible format.

Signed-off-by: Ravi Bangoria 
Acked-by: Masami Hiramatsu 
Cc: Alexander Shishkin 
Cc: Alexis Berlemont 
Cc: Hemant Kumar 
Cc: Michael Ellerman 
Cc: Naveen N. Rao 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/20170328094754.3156-4-ravi.bango...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/powerpc/util/perf_regs.c | 111 +++
 1 file changed, 111 insertions(+)

diff --git a/tools/perf/arch/powerpc/util/perf_regs.c 
b/tools/perf/arch/powerpc/util/perf_regs.c
index a3c3e1c..4268f77 100644
--- a/tools/perf/arch/powerpc/util/perf_regs.c
+++ b/tools/perf/arch/powerpc/util/perf_regs.c
@@ -1,5 +1,10 @@
+#include 
+#include 
+
 #include "../../perf.h"
+#include "../../util/util.h"
 #include "../../util/perf_regs.h"
+#include "../../util/debug.h"
 
 const struct sample_reg sample_reg_masks[] = {
SMPL_REG(r0, PERF_REG_POWERPC_R0),
@@ -47,3 +52,109 @@ const struct sample_reg sample_reg_masks[] = {
SMPL_REG(dsisr, PERF_REG_POWERPC_DSISR),
SMPL_REG_END
 };
+
+/* REG or %rREG */
+#define SDT_OP_REGEX1  "^(%r)?([1-2]?[0-9]|3[0-1])$"
+
+/* -NUM(REG) or NUM(REG) or -NUM(%rREG) or NUM(%rREG) */
+#define SDT_OP_REGEX2  "^(\\-)?([0-9]+)\\((%r)?([1-2]?[0-9]|3[0-1])\\)$"
+
+static regex_t sdt_op_regex1, sdt_op_regex2;
+
+static int sdt_init_op_regex(void)
+{
+   static int initialized;
+   int ret = 0;
+
+   if (initialized)
+   return 0;
+
+   ret = regcomp(_op_regex1, SDT_OP_REGEX1, REG_EXTENDED);
+   if (ret)
+   goto error;
+
+   ret = regcomp(_op_regex2, SDT_OP_REGEX2, REG_EXTENDED);
+   if (ret)
+   goto free_regex1;
+
+   initialized = 1;
+   return 0;
+
+free_regex1:
+   regfree(_op_regex1);
+error:
+   pr_debug4("Regex compilation error.\n");
+   return ret;
+}
+
+/*
+ * Parse OP and convert it into uprobe format, which is, +/-NUM(%gprREG).
+ * Possible variants of OP are:
+ * Format  Example
+ * -
+ * NUM(REG)48(18)
+ * -NUM(REG)   -48(18)
+ * NUM(%rREG)  48(%r18)
+ * -NUM(%rREG) -48(%r18)
+ * REG 18
+ * %rREG   %r18
+ * iNUMi0
+ * i-NUM   i-1
+ *
+ * SDT marker arguments on Powerpc uses %rREG form with -mregnames flag
+ * and REG form with -mno-regnames. Here REG is general purpose register,
+ * which is in 0 to 31 range.
+ */
+int arch_sdt_arg_parse_op(char *old_op, char **new_op)
+{
+   int ret, new_len;
+   regmatch_t rm[5];
+   char prefix;
+
+   /* Constant argument. Uprobe does not support it */
+   if (old_op[0] == 'i') {
+   pr_debug4("Skipping unsupported SDT argument: %s\n", old_op);
+   return SDT_ARG_SKIP;
+   }
+
+   ret = sdt_init_op_regex();
+   if (ret < 0)
+   return ret;
+
+   if (!regexec(_op_regex1, old_op, 3, rm, 0)) {
+   /* REG or %rREG --> %gprREG */
+
+   new_len = 5;/* % g p r NULL */
+   new_len += (int)(rm[2].rm_eo - rm[2].rm_so);
+
+   *new_op = zalloc(new_len);
+   if (!*new_op)
+   return -ENOMEM;
+
+   scnprintf(*new_op, new_len, "%%gpr%.*s",
+   (int)(rm[2].rm_eo - rm[2].rm_so), old_op + rm[2].rm_so);
+   } else if (!regexec(_op_regex2, old_op, 5, rm, 0)) {
+   /*
+* -NUM(REG) or NUM(REG) or -NUM(%rREG) or NUM(%rREG) -->
+*  +/-NUM(%gprREG)
+*/
+   prefix = (rm[1].rm_so == -1) ? '+' : '-';
+
+   new_len = 8;/* +/- ( % g p r ) NULL */
+   new_len += (int)(rm[2].rm_eo - rm[2].rm_so);
+   new_len += (int)(rm[4].rm_eo - rm[4].rm_so);
+
+   *new_op = zalloc(new_len);
+   if (!*new_op)
+   return -ENOMEM;
+
+   scnprintf(*new_op, new_len, "%c%.*s(%%gpr%.*s)", prefix,
+   (int)(rm[2].rm_eo - rm[2].rm_so), old_op + rm[2].rm_so,
+   (int)(rm[4].rm_eo - rm[4].rm_so), old_op + rm[4].rm_so);
+   } else {
+   pr_debug4("Skipping unsupported SDT argument: %s\n", old_op);
+   return SDT_ARG_SKIP;
+   }
+
+   return SDT_ARG_VALID;
+}

[tip:perf/core] perf tools: Handle allocation failures gracefully

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  f05082b5479d91ee5c04f311acaa394ce0c5e6d2
Gitweb: http://git.kernel.org/tip/f05082b5479d91ee5c04f311acaa394ce0c5e6d2
Author: Arnaldo Carvalho de Melo 
AuthorDate: Tue, 4 Apr 2017 12:05:37 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 4 Apr 2017 12:05:37 -0300

perf tools: Handle allocation failures gracefully

The callers of perf_read_values__enlarge_counters() already propagate
errors, so just print some debug diagnostics and handle allocation
failures gracefully, not trying to do silly things like 'a =
realloc(a)'.

Link: http://lkml.kernel.org/n/tip-nsmmh7uzpg35rzcl9nq7y...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/values.c | 54 ++--
 1 file changed, 39 insertions(+), 15 deletions(-)

diff --git a/tools/perf/util/values.c b/tools/perf/util/values.c
index 5074be4..2a8efa7 100644
--- a/tools/perf/util/values.c
+++ b/tools/perf/util/values.c
@@ -108,24 +108,45 @@ static int perf_read_values__findnew_thread(struct 
perf_read_values *values,
return i;
 }
 
-static void perf_read_values__enlarge_counters(struct perf_read_values *values)
+static int perf_read_values__enlarge_counters(struct perf_read_values *values)
 {
-   int i;
+   char **countername;
+   int i, counters_max = values->counters_max * 2;
+   u64 *counterrawid = realloc(values->counterrawid, counters_max * 
sizeof(*values->counterrawid));
+
+   if (!counterrawid) {
+   pr_debug("failed to enlarge read_values rawid array");
+   goto out_enomem;
+   }
 
-   values->counters_max *= 2;
-   values->counterrawid = realloc(values->counterrawid,
-  values->counters_max * 
sizeof(*values->counterrawid));
-   values->countername = realloc(values->countername,
- values->counters_max * 
sizeof(*values->countername));
-   if (!values->counterrawid || !values->countername)
-   die("failed to enlarge read_values counters arrays");
+   countername = realloc(values->countername, counters_max * 
sizeof(*values->countername));
+   if (!countername) {
+   pr_debug("failed to enlarge read_values rawid array");
+   goto out_free_rawid;
+   }
 
for (i = 0; i < values->threads; i++) {
-   values->value[i] = realloc(values->value[i],
-  values->counters_max * 
sizeof(**values->value));
-   if (!values->value[i])
-   die("failed to enlarge read_values counters arrays");
+   u64 *value = realloc(values->value[i], counters_max * 
sizeof(**values->value));
+
+   if (value) {
+   pr_debug("failed to enlarge read_values ->values 
array");
+   goto out_free_name;
+   }
+
+   values->value[i] = value;
}
+
+   values->counters_max = counters_max;
+   values->counterrawid = counterrawid;
+   values->countername  = countername;
+
+   return 0;
+out_free_name:
+   free(countername);
+out_free_rawid:
+   free(counterrawid);
+out_enomem:
+   return -ENOMEM;
 }
 
 static int perf_read_values__findnew_counter(struct perf_read_values *values,
@@ -137,8 +158,11 @@ static int perf_read_values__findnew_counter(struct 
perf_read_values *values,
if (values->counterrawid[i] == rawid)
return i;
 
-   if (values->counters == values->counters_max)
-   perf_read_values__enlarge_counters(values);
+   if (values->counters == values->counters_max) {
+   i = perf_read_values__enlarge_counters(values);
+   if (i)
+   return i;
+   }
 
i = values->counters++;
values->counterrawid[i] = rawid;

[tip:perf/core] perf tools: Don't die on a print function

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  9c0899f15766158df8b3bd152f5da0b6c1bd2806
Gitweb: http://git.kernel.org/tip/9c0899f15766158df8b3bd152f5da0b6c1bd2806
Author: Arnaldo Carvalho de Melo 
AuthorDate: Tue, 4 Apr 2017 12:11:07 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 4 Apr 2017 12:11:07 -0300

perf tools: Don't die on a print function

Trying to remove die() calls from library functions, postponing exiting
to the tool main code.

Link: http://lkml.kernel.org/n/tip-ackxq5nqe39gunln3tkcz...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/values.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/values.c b/tools/perf/util/values.c
index 2a8efa7..5de2e15 100644
--- a/tools/perf/util/values.c
+++ b/tools/perf/util/values.c
@@ -1,4 +1,7 @@
+#include 
+#include 
 #include 
+#include 
 
 #include "util.h"
 #include "values.h"
@@ -196,8 +199,10 @@ static void perf_read_values__display_pretty(FILE *fp,
int *counterwidth;
 
counterwidth = malloc(values->counters * sizeof(*counterwidth));
-   if (!counterwidth)
-   die("failed to allocate counterwidth array");
+   if (!counterwidth) {
+   fprintf(fp, "INTERNAL ERROR: Failed to allocate counterwidth 
array\n");
+   return;
+   }
tidwidth = 3;
pidwidth = 3;
for (j = 0; j < values->counters; j++)

[tip:perf/core] perf tools: Don't die on a print function

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  9c0899f15766158df8b3bd152f5da0b6c1bd2806
Gitweb: http://git.kernel.org/tip/9c0899f15766158df8b3bd152f5da0b6c1bd2806
Author: Arnaldo Carvalho de Melo 
AuthorDate: Tue, 4 Apr 2017 12:11:07 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 4 Apr 2017 12:11:07 -0300

perf tools: Don't die on a print function

Trying to remove die() calls from library functions, postponing exiting
to the tool main code.

Link: http://lkml.kernel.org/n/tip-ackxq5nqe39gunln3tkcz...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/values.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/values.c b/tools/perf/util/values.c
index 2a8efa7..5de2e15 100644
--- a/tools/perf/util/values.c
+++ b/tools/perf/util/values.c
@@ -1,4 +1,7 @@
+#include 
+#include 
 #include 
+#include 
 
 #include "util.h"
 #include "values.h"
@@ -196,8 +199,10 @@ static void perf_read_values__display_pretty(FILE *fp,
int *counterwidth;
 
counterwidth = malloc(values->counters * sizeof(*counterwidth));
-   if (!counterwidth)
-   die("failed to allocate counterwidth array");
+   if (!counterwidth) {
+   fprintf(fp, "INTERNAL ERROR: Failed to allocate counterwidth 
array\n");
+   return;
+   }
tidwidth = 3;
pidwidth = 3;
for (j = 0; j < values->counters; j++)

[tip:perf/core] perf tools: Handle allocation failures gracefully

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  f05082b5479d91ee5c04f311acaa394ce0c5e6d2
Gitweb: http://git.kernel.org/tip/f05082b5479d91ee5c04f311acaa394ce0c5e6d2
Author: Arnaldo Carvalho de Melo 
AuthorDate: Tue, 4 Apr 2017 12:05:37 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 4 Apr 2017 12:05:37 -0300

perf tools: Handle allocation failures gracefully

The callers of perf_read_values__enlarge_counters() already propagate
errors, so just print some debug diagnostics and handle allocation
failures gracefully, not trying to do silly things like 'a =
realloc(a)'.

Link: http://lkml.kernel.org/n/tip-nsmmh7uzpg35rzcl9nq7y...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/values.c | 54 ++--
 1 file changed, 39 insertions(+), 15 deletions(-)

diff --git a/tools/perf/util/values.c b/tools/perf/util/values.c
index 5074be4..2a8efa7 100644
--- a/tools/perf/util/values.c
+++ b/tools/perf/util/values.c
@@ -108,24 +108,45 @@ static int perf_read_values__findnew_thread(struct 
perf_read_values *values,
return i;
 }
 
-static void perf_read_values__enlarge_counters(struct perf_read_values *values)
+static int perf_read_values__enlarge_counters(struct perf_read_values *values)
 {
-   int i;
+   char **countername;
+   int i, counters_max = values->counters_max * 2;
+   u64 *counterrawid = realloc(values->counterrawid, counters_max * 
sizeof(*values->counterrawid));
+
+   if (!counterrawid) {
+   pr_debug("failed to enlarge read_values rawid array");
+   goto out_enomem;
+   }
 
-   values->counters_max *= 2;
-   values->counterrawid = realloc(values->counterrawid,
-  values->counters_max * 
sizeof(*values->counterrawid));
-   values->countername = realloc(values->countername,
- values->counters_max * 
sizeof(*values->countername));
-   if (!values->counterrawid || !values->countername)
-   die("failed to enlarge read_values counters arrays");
+   countername = realloc(values->countername, counters_max * 
sizeof(*values->countername));
+   if (!countername) {
+   pr_debug("failed to enlarge read_values rawid array");
+   goto out_free_rawid;
+   }
 
for (i = 0; i < values->threads; i++) {
-   values->value[i] = realloc(values->value[i],
-  values->counters_max * 
sizeof(**values->value));
-   if (!values->value[i])
-   die("failed to enlarge read_values counters arrays");
+   u64 *value = realloc(values->value[i], counters_max * 
sizeof(**values->value));
+
+   if (value) {
+   pr_debug("failed to enlarge read_values ->values 
array");
+   goto out_free_name;
+   }
+
+   values->value[i] = value;
}
+
+   values->counters_max = counters_max;
+   values->counterrawid = counterrawid;
+   values->countername  = countername;
+
+   return 0;
+out_free_name:
+   free(countername);
+out_free_rawid:
+   free(counterrawid);
+out_enomem:
+   return -ENOMEM;
 }
 
 static int perf_read_values__findnew_counter(struct perf_read_values *values,
@@ -137,8 +158,11 @@ static int perf_read_values__findnew_counter(struct 
perf_read_values *values,
if (values->counterrawid[i] == rawid)
return i;
 
-   if (values->counters == values->counters_max)
-   perf_read_values__enlarge_counters(values);
+   if (values->counters == values->counters_max) {
+   i = perf_read_values__enlarge_counters(values);
+   if (i)
+   return i;
+   }
 
i = values->counters++;
values->counterrawid[i] = rawid;

[tip:perf/core] perf tools: Remove die() call

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  427748068a973627b406bf7312342b6fe4742d07
Gitweb: http://git.kernel.org/tip/427748068a973627b406bf7312342b6fe4742d07
Author: Arnaldo Carvalho de Melo 
AuthorDate: Tue, 4 Apr 2017 11:36:22 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 4 Apr 2017 11:36:22 -0300

perf tools: Remove die() call

We can just use the exit() right after the branch calling die().

Link: http://lkml.kernel.org/n/tip-90athn06d7atf2jkpfvq1...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/perf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/perf.c b/tools/perf/perf.c
index 9217f22..9dc346f 100644
--- a/tools/perf/perf.c
+++ b/tools/perf/perf.c
@@ -378,7 +378,8 @@ static void execv_dashed_external(const char **argv)
if (status != -ERR_RUN_COMMAND_EXEC) {
if (IS_RUN_COMMAND_ERR(status)) {
 do_die:
-   die("unable to run '%s'", argv[0]);
+   pr_err("FATAL: unable to run '%s'", argv[0]);
+   status = -128;
}
exit(-status);
}

[tip:perf/core] perf tools: Remove die() call

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  427748068a973627b406bf7312342b6fe4742d07
Gitweb: http://git.kernel.org/tip/427748068a973627b406bf7312342b6fe4742d07
Author: Arnaldo Carvalho de Melo 
AuthorDate: Tue, 4 Apr 2017 11:36:22 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 4 Apr 2017 11:36:22 -0300

perf tools: Remove die() call

We can just use the exit() right after the branch calling die().

Link: http://lkml.kernel.org/n/tip-90athn06d7atf2jkpfvq1...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/perf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/perf.c b/tools/perf/perf.c
index 9217f22..9dc346f 100644
--- a/tools/perf/perf.c
+++ b/tools/perf/perf.c
@@ -378,7 +378,8 @@ static void execv_dashed_external(const char **argv)
if (status != -ERR_RUN_COMMAND_EXEC) {
if (IS_RUN_COMMAND_ERR(status)) {
 do_die:
-   die("unable to run '%s'", argv[0]);
+   pr_err("FATAL: unable to run '%s'", argv[0]);
+   status = -128;
}
exit(-status);
}

Re: [PATCH] cgroup: switch to BUG_ON()

[Zefan Li]

On 2017/3/27 0:24, Nicholas Mc Guire wrote:
> Use BUG_ON() rather than an explicit if followed by BUG() for 
> improved readability and also consistency.
> 
> Signed-off-by: Nicholas Mc Guire 
> ---
> 
> Found by coccinelle: bugon.cocci
> ./kernel/cgroup/cpuset.c:2125:2-5: WARNING: Use BUG_ON instead of if 
> condition followed by BUG.
> ./kernel/cgroup/cpuset.c:2127:2-5: WARNING: Use BUG_ON instead of if 
> condition followed by BUG.
> ./kernel/cgroup/cpuset.c:2143:2-5: WARNING: Use BUG_ON instead of if 
> condition followed by BUG.
> 
> BUG_ON() wraps the explicit if condition and is actually in use for
> all conditional BUG() cases in cpuset.c except in this one function.
> 
> Patch was compile-tested with: x86_64_defconfig (implies CONFIG_CPUSETS=y)
> (checkpatch warnings for this patch seem to be false-positives - the 
>  BUG_ON should be fine)
> 
> Patch is against 4.11-rc3 (localversion-next is next-20170324)
> 

Acked-by: Zefan Li 

Re: [PATCH] cgroup: switch to BUG_ON()

[Zefan Li]

On 2017/3/27 0:24, Nicholas Mc Guire wrote:
> Use BUG_ON() rather than an explicit if followed by BUG() for 
> improved readability and also consistency.
> 
> Signed-off-by: Nicholas Mc Guire 
> ---
> 
> Found by coccinelle: bugon.cocci
> ./kernel/cgroup/cpuset.c:2125:2-5: WARNING: Use BUG_ON instead of if 
> condition followed by BUG.
> ./kernel/cgroup/cpuset.c:2127:2-5: WARNING: Use BUG_ON instead of if 
> condition followed by BUG.
> ./kernel/cgroup/cpuset.c:2143:2-5: WARNING: Use BUG_ON instead of if 
> condition followed by BUG.
> 
> BUG_ON() wraps the explicit if condition and is actually in use for
> all conditional BUG() cases in cpuset.c except in this one function.
> 
> Patch was compile-tested with: x86_64_defconfig (implies CONFIG_CPUSETS=y)
> (checkpatch warnings for this patch seem to be false-positives - the 
>  BUG_ON should be fine)
> 
> Patch is against 4.11-rc3 (localversion-next is next-20170324)
> 

Acked-by: Zefan Li 

[tip:perf/core] perf vendor events intel: Add missing space in json descriptions

[tip-bot for Andi Kleen]

Commit-ID:  3401e8d1e1300742ed41910b9338b9da52689a16
Gitweb: http://git.kernel.org/tip/3401e8d1e1300742ed41910b9338b9da52689a16
Author: Andi Kleen 
AuthorDate: Wed, 29 Mar 2017 17:22:18 -0700
Committer:  Andi Kleen 
CommitDate: Thu, 30 Mar 2017 13:35:50 -0700

perf vendor events intel: Add missing space in json descriptions

Add a missing space in the JSON description after the uncore unit

Before:

perf list
...
  unc_arb_coh_trk_requests.all
   [Unit: uncore_arbNumber of entries allocated. Account for Any type: e.g. 
Snoop, Core aperture, etc]
...

After:

  unc_arb_coh_trk_requests.all
   [Unit: uncore_arb Number of entries allocated. Account for Any type: 
e.g. Snoop, Core aperture, etc]

Cc: jo...@kernel.org
Link: http://lkml.kernel.org/n/tip-p989c7x9kaiy2bnkmgpo6...@git.kernel.org
Signed-off-by: Andi Kleen 
---
 tools/perf/pmu-events/jevents.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index 3a151c3..baa073f 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -469,6 +469,7 @@ int json_events(const char *fn,
}
addfield(map, , ". ", "Unit: ", NULL);
addfield(map, , "", pmu, NULL);
+   addfield(map, , "", " ", NULL);
} else if (json_streq(map, field, "Filter")) {
addfield(map, , "", "", val);
} else if (json_streq(map, field, "ScaleUnit")) {

[tip:perf/core] perf vendor events intel: Add missing space in json descriptions

[tip-bot for Andi Kleen]

Commit-ID:  3401e8d1e1300742ed41910b9338b9da52689a16
Gitweb: http://git.kernel.org/tip/3401e8d1e1300742ed41910b9338b9da52689a16
Author: Andi Kleen 
AuthorDate: Wed, 29 Mar 2017 17:22:18 -0700
Committer:  Andi Kleen 
CommitDate: Thu, 30 Mar 2017 13:35:50 -0700

perf vendor events intel: Add missing space in json descriptions

Add a missing space in the JSON description after the uncore unit

Before:

perf list
...
  unc_arb_coh_trk_requests.all
   [Unit: uncore_arbNumber of entries allocated. Account for Any type: e.g. 
Snoop, Core aperture, etc]
...

After:

  unc_arb_coh_trk_requests.all
   [Unit: uncore_arb Number of entries allocated. Account for Any type: 
e.g. Snoop, Core aperture, etc]

Cc: jo...@kernel.org
Link: http://lkml.kernel.org/n/tip-p989c7x9kaiy2bnkmgpo6...@git.kernel.org
Signed-off-by: Andi Kleen 
---
 tools/perf/pmu-events/jevents.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index 3a151c3..baa073f 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -469,6 +469,7 @@ int json_events(const char *fn,
}
addfield(map, , ". ", "Unit: ", NULL);
addfield(map, , "", pmu, NULL);
+   addfield(map, , "", " ", NULL);
} else if (json_streq(map, field, "Filter")) {
addfield(map, , "", "", val);
} else if (json_streq(map, field, "ScaleUnit")) {

[tip:perf/core] perf vendor events intel: Add uncore_arb JSON support

[tip-bot for Andi Kleen]

Commit-ID:  af34cb4fad1ba08db199ef1b0a529549e041dd25
Gitweb: http://git.kernel.org/tip/af34cb4fad1ba08db199ef1b0a529549e041dd25
Author: Andi Kleen 
AuthorDate: Wed, 29 Mar 2017 17:20:28 -0700
Committer:  Andi Kleen 
CommitDate: Thu, 30 Mar 2017 13:35:41 -0700

perf vendor events intel: Add uncore_arb JSON support

The JSON lists call the box iMPH-U, while perf calls it arb.
Add conversion support to json to convert the unit properly.

Cc: jo...@kernel.org
Link: http://lkml.kernel.org/n/tip-stq5ly95z2qioggp9bfaq...@git.kernel.org
Signed-off-by: Andi Kleen 
---
 tools/perf/pmu-events/jevents.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index 81f2ef3..3a151c3 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -195,6 +195,7 @@ static struct map {
{ "CBO", "uncore_cbox" },
{ "QPI LL", "uncore_qpi" },
{ "SBO", "uncore_sbox" },
+   { "iMPH-U", "uncore_arb" },
{}
 };
 

[tip:perf/core] perf vendor events intel: Add uncore_arb JSON support

[tip-bot for Andi Kleen]

Commit-ID:  af34cb4fad1ba08db199ef1b0a529549e041dd25
Gitweb: http://git.kernel.org/tip/af34cb4fad1ba08db199ef1b0a529549e041dd25
Author: Andi Kleen 
AuthorDate: Wed, 29 Mar 2017 17:20:28 -0700
Committer:  Andi Kleen 
CommitDate: Thu, 30 Mar 2017 13:35:41 -0700

perf vendor events intel: Add uncore_arb JSON support

The JSON lists call the box iMPH-U, while perf calls it arb.
Add conversion support to json to convert the unit properly.

Cc: jo...@kernel.org
Link: http://lkml.kernel.org/n/tip-stq5ly95z2qioggp9bfaq...@git.kernel.org
Signed-off-by: Andi Kleen 
---
 tools/perf/pmu-events/jevents.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index 81f2ef3..3a151c3 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -195,6 +195,7 @@ static struct map {
{ "CBO", "uncore_cbox" },
{ "QPI LL", "uncore_qpi" },
{ "SBO", "uncore_sbox" },
+   { "iMPH-U", "uncore_arb" },
{}
 };
 

[tip:perf/core] perf vendor events intel: Add uncore events for Broadwell client

[tip-bot for Andi Kleen]

Commit-ID:  092a95d41655bdd31d7d28f1788818724505feb2
Gitweb: http://git.kernel.org/tip/092a95d41655bdd31d7d28f1788818724505feb2
Author: Andi Kleen 
AuthorDate: Wed, 29 Mar 2017 17:17:42 -0700
Committer:  Andi Kleen 
CommitDate: Thu, 30 Mar 2017 13:35:23 -0700

perf vendor events intel: Add uncore events for Broadwell client

Add V18 of Broadwell uncore events

Cc: jo...@kernel.org
Link: http://lkml.kernel.org/n/tip-xlbguqdzho7l3qn7di40a...@git.kernel.org
Signed-off-by: Andi Kleen 
---
 .../arch/x86/{haswell => broadwell}/uncore.json| 190 +
 1 file changed, 47 insertions(+), 143 deletions(-)

diff --git a/tools/perf/pmu-events/arch/x86/haswell/uncore.json 
b/tools/perf/pmu-events/arch/x86/broadwell/uncore.json
similarity index 63%
copy from tools/perf/pmu-events/arch/x86/haswell/uncore.json
copy to tools/perf/pmu-events/arch/x86/broadwell/uncore.json
index 3ef5c21..28e1e15 100644
--- a/tools/perf/pmu-events/arch/x86/haswell/uncore.json
+++ b/tools/perf/pmu-events/arch/x86/broadwell/uncore.json
@@ -2,18 +2,6 @@
   {
 "Unit": "CBO",
 "EventCode": "0x22",
-"UMask": "0x21",
-"EventName": "UNC_CBO_XSNP_RESPONSE.MISS_EXTERNAL",
-"BriefDescription": "An external snoop misses in some processor core.",
-"PublicDescription": "An external snoop misses in some processor core.",
-"Counter": "0,1",
-"CounterMask": "0",
-"Invert": "0",
-"EdgeDetect": "0"
-  },
-  {
-"Unit": "CBO",
-"EventCode": "0x22",
 "UMask": "0x41",
 "EventName": "UNC_CBO_XSNP_RESPONSE.MISS_XCORE",
 "BriefDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which misses in some processor core.",
@@ -38,18 +26,6 @@
   {
 "Unit": "CBO",
 "EventCode": "0x22",
-"UMask": "0x24",
-"EventName": "UNC_CBO_XSNP_RESPONSE.HIT_EXTERNAL",
-"BriefDescription": "An external snoop hits a non-modified line in some 
processor core.",
-"PublicDescription": "An external snoop hits a non-modified line in some 
processor core.",
-"Counter": "0,1",
-"CounterMask": "0",
-"Invert": "0",
-"EdgeDetect": "0"
-  },
-  {
-"Unit": "CBO",
-"EventCode": "0x22",
 "UMask": "0x44",
 "EventName": "UNC_CBO_XSNP_RESPONSE.HIT_XCORE",
 "BriefDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which hits a non-modified line in some processor 
core.",
@@ -62,30 +38,6 @@
   {
 "Unit": "CBO",
 "EventCode": "0x22",
-"UMask": "0x84",
-"EventName": "UNC_CBO_XSNP_RESPONSE.HIT_EVICTION",
-"BriefDescription": "A cross-core snoop resulted from L3 Eviction which 
hits a non-modified line in some processor core.",
-"PublicDescription": "A cross-core snoop resulted from L3 Eviction which 
hits a non-modified line in some processor core.",
-"Counter": "0,1",
-"CounterMask": "0",
-"Invert": "0",
-"EdgeDetect": "0"
-  },
-  {
-"Unit": "CBO",
-"EventCode": "0x22",
-"UMask": "0x28",
-"EventName": "UNC_CBO_XSNP_RESPONSE.HITM_EXTERNAL",
-"BriefDescription": "An external snoop hits a modified line in some 
processor core.",
-"PublicDescription": "An external snoop hits a modified line in some 
processor core.",
-"Counter": "0,1",
-"CounterMask": "0",
-"Invert": "0",
-"EdgeDetect": "0"
-  },
-  {
-"Unit": "CBO",
-"EventCode": "0x22",
 "UMask": "0x48",
 "EventName": "UNC_CBO_XSNP_RESPONSE.HITM_XCORE",
 "BriefDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which hits a modified line in some processor 
core.",
@@ -97,22 +49,10 @@
   },
   {
 "Unit": "CBO",
-"EventCode": "0x22",
-"UMask": "0x88",
-"EventName": "UNC_CBO_XSNP_RESPONSE.HITM_EVICTION",
-"BriefDescription": "A cross-core snoop resulted from L3 Eviction which 
hits a modified line in some processor core.",
-"PublicDescription": "A cross-core snoop resulted from L3 Eviction which 
hits a modified line in some processor core.",
-"Counter": "0,1",
-"CounterMask": "0",
-"Invert": "0",
-"EdgeDetect": "0"
-  },
-  {
-"Unit": "CBO",
 "EventCode": "0x34",
 "UMask": "0x11",
 "EventName": "UNC_CBO_CACHE_LOOKUP.READ_M",
-"BriefDescription": "L3 Lookup read request that access cache and found 
line in M-state.",
+"BriefDescription": "L3 Lookup read request that access cache and found 
line in M-state",
 "PublicDescription": "L3 Lookup read request that access cache and found 
line in M-state.",
 "Counter": "0,1",
 "CounterMask": "0",
@@ -124,7 +64,7 @@
 "EventCode": "0x34",
 "UMask": "0x21",
 "EventName": "UNC_CBO_CACHE_LOOKUP.WRITE_M",
-"BriefDescription": "L3 Lookup write request that access cache and found 
line in M-state.",
+"BriefDescription": "L3 Lookup write request that access cache and found 
line in M-state",
 

[tip:perf/core] perf vendor events intel: Add uncore events for Skylake client

[tip-bot for Andi Kleen]

Commit-ID:  92c6de0f10a80e4936fac04148bd3783a7c2b9f8
Gitweb: http://git.kernel.org/tip/92c6de0f10a80e4936fac04148bd3783a7c2b9f8
Author: Andi Kleen 
AuthorDate: Wed, 29 Mar 2017 17:18:15 -0700
Committer:  Andi Kleen 
CommitDate: Thu, 30 Mar 2017 13:35:32 -0700

perf vendor events intel: Add uncore events for Skylake client

Add V25 of Skylake uncore events

Cc: jo...@kernel.org
Link: http://lkml.kernel.org/n/tip-00qmcrmq183x2qrj59g92...@git.kernel.org
Signed-off-by: Andi Kleen 
---
 .../arch/x86/{broadwell => skylake}/uncore.json| 32 +++---
 1 file changed, 4 insertions(+), 28 deletions(-)

diff --git a/tools/perf/pmu-events/arch/x86/broadwell/uncore.json 
b/tools/perf/pmu-events/arch/x86/skylake/uncore.json
similarity index 86%
copy from tools/perf/pmu-events/arch/x86/broadwell/uncore.json
copy to tools/perf/pmu-events/arch/x86/skylake/uncore.json
index 28e1e15..dbc1932 100644
--- a/tools/perf/pmu-events/arch/x86/broadwell/uncore.json
+++ b/tools/perf/pmu-events/arch/x86/skylake/uncore.json
@@ -50,18 +50,6 @@
   {
 "Unit": "CBO",
 "EventCode": "0x34",
-"UMask": "0x11",
-"EventName": "UNC_CBO_CACHE_LOOKUP.READ_M",
-"BriefDescription": "L3 Lookup read request that access cache and found 
line in M-state",
-"PublicDescription": "L3 Lookup read request that access cache and found 
line in M-state.",
-"Counter": "0,1",
-"CounterMask": "0",
-"Invert": "0",
-"EdgeDetect": "0"
-  },
-  {
-"Unit": "CBO",
-"EventCode": "0x34",
 "UMask": "0x21",
 "EventName": "UNC_CBO_CACHE_LOOKUP.WRITE_M",
 "BriefDescription": "L3 Lookup write request that access cache and found 
line in M-state",
@@ -184,21 +172,9 @@
 "EventCode": "0x80",
 "UMask": "0x01",
 "EventName": "UNC_ARB_TRK_OCCUPANCY.ALL",
-"BriefDescription": "Each cycle count number of all Core outgoing valid 
entries. Such entry is defined as valid from it's allocation till first of IDI0 
or DRS0 messages is sent out. Accounts for Coherent and non-coherent traffic.",
-"PublicDescription": "Each cycle count number of all Core outgoing valid 
entries. Such entry is defined as valid from it's allocation till first of IDI0 
or DRS0 messages is sent out. Accounts for Coherent and non-coherent traffic.",
-"Counter": "0,",
-"CounterMask": "0",
-"Invert": "0",
-"EdgeDetect": "0"
-  },
-  {
-"Unit": "iMPH-U",
-"EventCode": "0x80",
-"UMask": "0x02",
-"EventName": "UNC_ARB_TRK_OCCUPANCY.DRD_DIRECT",
-"BriefDescription": "Each cycle count number of 'valid' coherent Data Read 
entries that are in DirectData mode. Such entry is defined as valid when it is 
allocated till data sent to Core (first chunk, IDI0). Applicable for IA Cores' 
requests in normal case.",
-"PublicDescription": "Each cycle count number of 'valid' coherent Data 
Read entries that are in DirectData mode. Such entry is defined as valid when 
it is allocated till data sent to Core (first chunk, IDI0). Applicable for IA 
Cores' requests in normal case.",
-"Counter": "0,",
+"BriefDescription": "Each cycle count number of all Core outgoing valid 
entries. Such entry is defined as valid from its allocation till first of IDI0 
or DRS0 messages is sent out. Accounts for Coherent and non-coherent traffic.",
+"PublicDescription": "Each cycle count number of all Core outgoing valid 
entries. Such entry is defined as valid from its allocation till first of IDI0 
or DRS0 messages is sent out. Accounts for Coherent and non-coherent traffic.",
+"Counter": "0",
 "CounterMask": "0",
 "Invert": "0",
 "EdgeDetect": "0"
@@ -258,7 +234,7 @@
 "EventName": "UNC_ARB_TRK_OCCUPANCY.CYCLES_WITH_ANY_REQUEST",
 "BriefDescription": "Cycles with at least one request outstanding is 
waiting for data return from memory controller. Account for coherent and 
non-coherent requests initiated by IA Cores, Processor Graphics Unit, or LLC.;",
 "PublicDescription": "Cycles with at least one request outstanding is 
waiting for data return from memory controller. Account for coherent and 
non-coherent requests initiated by IA Cores, Processor Graphics Unit, or LLC.",
-"Counter": "0,",
+"Counter": "0",
 "CounterMask": "1",
 "Invert": "0",
 "EdgeDetect": "0"

[tip:perf/core] perf vendor events intel: Add uncore events for Broadwell client

[tip-bot for Andi Kleen]

Commit-ID:  092a95d41655bdd31d7d28f1788818724505feb2
Gitweb: http://git.kernel.org/tip/092a95d41655bdd31d7d28f1788818724505feb2
Author: Andi Kleen 
AuthorDate: Wed, 29 Mar 2017 17:17:42 -0700
Committer:  Andi Kleen 
CommitDate: Thu, 30 Mar 2017 13:35:23 -0700

perf vendor events intel: Add uncore events for Broadwell client

Add V18 of Broadwell uncore events

Cc: jo...@kernel.org
Link: http://lkml.kernel.org/n/tip-xlbguqdzho7l3qn7di40a...@git.kernel.org
Signed-off-by: Andi Kleen 
---
 .../arch/x86/{haswell => broadwell}/uncore.json| 190 +
 1 file changed, 47 insertions(+), 143 deletions(-)

diff --git a/tools/perf/pmu-events/arch/x86/haswell/uncore.json 
b/tools/perf/pmu-events/arch/x86/broadwell/uncore.json
similarity index 63%
copy from tools/perf/pmu-events/arch/x86/haswell/uncore.json
copy to tools/perf/pmu-events/arch/x86/broadwell/uncore.json
index 3ef5c21..28e1e15 100644
--- a/tools/perf/pmu-events/arch/x86/haswell/uncore.json
+++ b/tools/perf/pmu-events/arch/x86/broadwell/uncore.json
@@ -2,18 +2,6 @@
   {
 "Unit": "CBO",
 "EventCode": "0x22",
-"UMask": "0x21",
-"EventName": "UNC_CBO_XSNP_RESPONSE.MISS_EXTERNAL",
-"BriefDescription": "An external snoop misses in some processor core.",
-"PublicDescription": "An external snoop misses in some processor core.",
-"Counter": "0,1",
-"CounterMask": "0",
-"Invert": "0",
-"EdgeDetect": "0"
-  },
-  {
-"Unit": "CBO",
-"EventCode": "0x22",
 "UMask": "0x41",
 "EventName": "UNC_CBO_XSNP_RESPONSE.MISS_XCORE",
 "BriefDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which misses in some processor core.",
@@ -38,18 +26,6 @@
   {
 "Unit": "CBO",
 "EventCode": "0x22",
-"UMask": "0x24",
-"EventName": "UNC_CBO_XSNP_RESPONSE.HIT_EXTERNAL",
-"BriefDescription": "An external snoop hits a non-modified line in some 
processor core.",
-"PublicDescription": "An external snoop hits a non-modified line in some 
processor core.",
-"Counter": "0,1",
-"CounterMask": "0",
-"Invert": "0",
-"EdgeDetect": "0"
-  },
-  {
-"Unit": "CBO",
-"EventCode": "0x22",
 "UMask": "0x44",
 "EventName": "UNC_CBO_XSNP_RESPONSE.HIT_XCORE",
 "BriefDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which hits a non-modified line in some processor 
core.",
@@ -62,30 +38,6 @@
   {
 "Unit": "CBO",
 "EventCode": "0x22",
-"UMask": "0x84",
-"EventName": "UNC_CBO_XSNP_RESPONSE.HIT_EVICTION",
-"BriefDescription": "A cross-core snoop resulted from L3 Eviction which 
hits a non-modified line in some processor core.",
-"PublicDescription": "A cross-core snoop resulted from L3 Eviction which 
hits a non-modified line in some processor core.",
-"Counter": "0,1",
-"CounterMask": "0",
-"Invert": "0",
-"EdgeDetect": "0"
-  },
-  {
-"Unit": "CBO",
-"EventCode": "0x22",
-"UMask": "0x28",
-"EventName": "UNC_CBO_XSNP_RESPONSE.HITM_EXTERNAL",
-"BriefDescription": "An external snoop hits a modified line in some 
processor core.",
-"PublicDescription": "An external snoop hits a modified line in some 
processor core.",
-"Counter": "0,1",
-"CounterMask": "0",
-"Invert": "0",
-"EdgeDetect": "0"
-  },
-  {
-"Unit": "CBO",
-"EventCode": "0x22",
 "UMask": "0x48",
 "EventName": "UNC_CBO_XSNP_RESPONSE.HITM_XCORE",
 "BriefDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which hits a modified line in some processor 
core.",
@@ -97,22 +49,10 @@
   },
   {
 "Unit": "CBO",
-"EventCode": "0x22",
-"UMask": "0x88",
-"EventName": "UNC_CBO_XSNP_RESPONSE.HITM_EVICTION",
-"BriefDescription": "A cross-core snoop resulted from L3 Eviction which 
hits a modified line in some processor core.",
-"PublicDescription": "A cross-core snoop resulted from L3 Eviction which 
hits a modified line in some processor core.",
-"Counter": "0,1",
-"CounterMask": "0",
-"Invert": "0",
-"EdgeDetect": "0"
-  },
-  {
-"Unit": "CBO",
 "EventCode": "0x34",
 "UMask": "0x11",
 "EventName": "UNC_CBO_CACHE_LOOKUP.READ_M",
-"BriefDescription": "L3 Lookup read request that access cache and found 
line in M-state.",
+"BriefDescription": "L3 Lookup read request that access cache and found 
line in M-state",
 "PublicDescription": "L3 Lookup read request that access cache and found 
line in M-state.",
 "Counter": "0,1",
 "CounterMask": "0",
@@ -124,7 +64,7 @@
 "EventCode": "0x34",
 "UMask": "0x21",
 "EventName": "UNC_CBO_CACHE_LOOKUP.WRITE_M",
-"BriefDescription": "L3 Lookup write request that access cache and found 
line in M-state.",
+"BriefDescription": "L3 Lookup write request that access cache and found 
line in M-state",
 "PublicDescription": "L3 Lookup write request that access cache and found 

[tip:perf/core] perf vendor events intel: Add uncore events for Skylake client

[tip-bot for Andi Kleen]

Commit-ID:  92c6de0f10a80e4936fac04148bd3783a7c2b9f8
Gitweb: http://git.kernel.org/tip/92c6de0f10a80e4936fac04148bd3783a7c2b9f8
Author: Andi Kleen 
AuthorDate: Wed, 29 Mar 2017 17:18:15 -0700
Committer:  Andi Kleen 
CommitDate: Thu, 30 Mar 2017 13:35:32 -0700

perf vendor events intel: Add uncore events for Skylake client

Add V25 of Skylake uncore events

Cc: jo...@kernel.org
Link: http://lkml.kernel.org/n/tip-00qmcrmq183x2qrj59g92...@git.kernel.org
Signed-off-by: Andi Kleen 
---
 .../arch/x86/{broadwell => skylake}/uncore.json| 32 +++---
 1 file changed, 4 insertions(+), 28 deletions(-)

diff --git a/tools/perf/pmu-events/arch/x86/broadwell/uncore.json 
b/tools/perf/pmu-events/arch/x86/skylake/uncore.json
similarity index 86%
copy from tools/perf/pmu-events/arch/x86/broadwell/uncore.json
copy to tools/perf/pmu-events/arch/x86/skylake/uncore.json
index 28e1e15..dbc1932 100644
--- a/tools/perf/pmu-events/arch/x86/broadwell/uncore.json
+++ b/tools/perf/pmu-events/arch/x86/skylake/uncore.json
@@ -50,18 +50,6 @@
   {
 "Unit": "CBO",
 "EventCode": "0x34",
-"UMask": "0x11",
-"EventName": "UNC_CBO_CACHE_LOOKUP.READ_M",
-"BriefDescription": "L3 Lookup read request that access cache and found 
line in M-state",
-"PublicDescription": "L3 Lookup read request that access cache and found 
line in M-state.",
-"Counter": "0,1",
-"CounterMask": "0",
-"Invert": "0",
-"EdgeDetect": "0"
-  },
-  {
-"Unit": "CBO",
-"EventCode": "0x34",
 "UMask": "0x21",
 "EventName": "UNC_CBO_CACHE_LOOKUP.WRITE_M",
 "BriefDescription": "L3 Lookup write request that access cache and found 
line in M-state",
@@ -184,21 +172,9 @@
 "EventCode": "0x80",
 "UMask": "0x01",
 "EventName": "UNC_ARB_TRK_OCCUPANCY.ALL",
-"BriefDescription": "Each cycle count number of all Core outgoing valid 
entries. Such entry is defined as valid from it's allocation till first of IDI0 
or DRS0 messages is sent out. Accounts for Coherent and non-coherent traffic.",
-"PublicDescription": "Each cycle count number of all Core outgoing valid 
entries. Such entry is defined as valid from it's allocation till first of IDI0 
or DRS0 messages is sent out. Accounts for Coherent and non-coherent traffic.",
-"Counter": "0,",
-"CounterMask": "0",
-"Invert": "0",
-"EdgeDetect": "0"
-  },
-  {
-"Unit": "iMPH-U",
-"EventCode": "0x80",
-"UMask": "0x02",
-"EventName": "UNC_ARB_TRK_OCCUPANCY.DRD_DIRECT",
-"BriefDescription": "Each cycle count number of 'valid' coherent Data Read 
entries that are in DirectData mode. Such entry is defined as valid when it is 
allocated till data sent to Core (first chunk, IDI0). Applicable for IA Cores' 
requests in normal case.",
-"PublicDescription": "Each cycle count number of 'valid' coherent Data 
Read entries that are in DirectData mode. Such entry is defined as valid when 
it is allocated till data sent to Core (first chunk, IDI0). Applicable for IA 
Cores' requests in normal case.",
-"Counter": "0,",
+"BriefDescription": "Each cycle count number of all Core outgoing valid 
entries. Such entry is defined as valid from its allocation till first of IDI0 
or DRS0 messages is sent out. Accounts for Coherent and non-coherent traffic.",
+"PublicDescription": "Each cycle count number of all Core outgoing valid 
entries. Such entry is defined as valid from its allocation till first of IDI0 
or DRS0 messages is sent out. Accounts for Coherent and non-coherent traffic.",
+"Counter": "0",
 "CounterMask": "0",
 "Invert": "0",
 "EdgeDetect": "0"
@@ -258,7 +234,7 @@
 "EventName": "UNC_ARB_TRK_OCCUPANCY.CYCLES_WITH_ANY_REQUEST",
 "BriefDescription": "Cycles with at least one request outstanding is 
waiting for data return from memory controller. Account for coherent and 
non-coherent requests initiated by IA Cores, Processor Graphics Unit, or LLC.;",
 "PublicDescription": "Cycles with at least one request outstanding is 
waiting for data return from memory controller. Account for coherent and 
non-coherent requests initiated by IA Cores, Processor Graphics Unit, or LLC.",
-"Counter": "0,",
+"Counter": "0",
 "CounterMask": "1",
 "Invert": "0",
 "EdgeDetect": "0"

[tip:perf/core] perf vendor events intel: Add uncore events for Haswell client

[tip-bot for Andi Kleen]

Commit-ID:  0585c6265e66f952bcb6280cf078e5e120bd367a
Gitweb: http://git.kernel.org/tip/0585c6265e66f952bcb6280cf078e5e120bd367a
Author: Andi Kleen 
AuthorDate: Wed, 29 Mar 2017 17:17:02 -0700
Committer:  Andi Kleen 
CommitDate: Thu, 30 Mar 2017 13:35:15 -0700

perf vendor events intel: Add uncore events for Haswell client

Add V25 of Haswell uncore events

Cc: jo...@kernel.org
Link: http://lkml.kernel.org/n/tip-133r1do7vvssoyszxgx17...@git.kernel.org
Signed-off-by: Andi Kleen 
---
 tools/perf/pmu-events/arch/x86/haswell/uncore.json | 374 +
 1 file changed, 374 insertions(+)

diff --git a/tools/perf/pmu-events/arch/x86/haswell/uncore.json 
b/tools/perf/pmu-events/arch/x86/haswell/uncore.json
new file mode 100644
index 000..3ef5c21
--- /dev/null
+++ b/tools/perf/pmu-events/arch/x86/haswell/uncore.json
@@ -0,0 +1,374 @@
+[
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x21",
+"EventName": "UNC_CBO_XSNP_RESPONSE.MISS_EXTERNAL",
+"BriefDescription": "An external snoop misses in some processor core.",
+"PublicDescription": "An external snoop misses in some processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x41",
+"EventName": "UNC_CBO_XSNP_RESPONSE.MISS_XCORE",
+"BriefDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which misses in some processor core.",
+"PublicDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which misses in some processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x81",
+"EventName": "UNC_CBO_XSNP_RESPONSE.MISS_EVICTION",
+"BriefDescription": "A cross-core snoop resulted from L3 Eviction which 
misses in some processor core.",
+"PublicDescription": "A cross-core snoop resulted from L3 Eviction which 
misses in some processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x24",
+"EventName": "UNC_CBO_XSNP_RESPONSE.HIT_EXTERNAL",
+"BriefDescription": "An external snoop hits a non-modified line in some 
processor core.",
+"PublicDescription": "An external snoop hits a non-modified line in some 
processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x44",
+"EventName": "UNC_CBO_XSNP_RESPONSE.HIT_XCORE",
+"BriefDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which hits a non-modified line in some processor 
core.",
+"PublicDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which hits a non-modified line in some processor 
core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x84",
+"EventName": "UNC_CBO_XSNP_RESPONSE.HIT_EVICTION",
+"BriefDescription": "A cross-core snoop resulted from L3 Eviction which 
hits a non-modified line in some processor core.",
+"PublicDescription": "A cross-core snoop resulted from L3 Eviction which 
hits a non-modified line in some processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x28",
+"EventName": "UNC_CBO_XSNP_RESPONSE.HITM_EXTERNAL",
+"BriefDescription": "An external snoop hits a modified line in some 
processor core.",
+"PublicDescription": "An external snoop hits a modified line in some 
processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x48",
+"EventName": "UNC_CBO_XSNP_RESPONSE.HITM_XCORE",
+"BriefDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which hits a modified line in some processor 
core.",
+"PublicDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which hits a modified line in some processor 
core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x88",
+"EventName": "UNC_CBO_XSNP_RESPONSE.HITM_EVICTION",
+"BriefDescription": "A cross-core snoop resulted from L3 Eviction which 
hits a modified line in some processor core.",
+"PublicDescription": "A cross-core snoop 

[tip:perf/core] perf vendor events intel: Add uncore events for Haswell client

[tip-bot for Andi Kleen]

Commit-ID:  0585c6265e66f952bcb6280cf078e5e120bd367a
Gitweb: http://git.kernel.org/tip/0585c6265e66f952bcb6280cf078e5e120bd367a
Author: Andi Kleen 
AuthorDate: Wed, 29 Mar 2017 17:17:02 -0700
Committer:  Andi Kleen 
CommitDate: Thu, 30 Mar 2017 13:35:15 -0700

perf vendor events intel: Add uncore events for Haswell client

Add V25 of Haswell uncore events

Cc: jo...@kernel.org
Link: http://lkml.kernel.org/n/tip-133r1do7vvssoyszxgx17...@git.kernel.org
Signed-off-by: Andi Kleen 
---
 tools/perf/pmu-events/arch/x86/haswell/uncore.json | 374 +
 1 file changed, 374 insertions(+)

diff --git a/tools/perf/pmu-events/arch/x86/haswell/uncore.json 
b/tools/perf/pmu-events/arch/x86/haswell/uncore.json
new file mode 100644
index 000..3ef5c21
--- /dev/null
+++ b/tools/perf/pmu-events/arch/x86/haswell/uncore.json
@@ -0,0 +1,374 @@
+[
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x21",
+"EventName": "UNC_CBO_XSNP_RESPONSE.MISS_EXTERNAL",
+"BriefDescription": "An external snoop misses in some processor core.",
+"PublicDescription": "An external snoop misses in some processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x41",
+"EventName": "UNC_CBO_XSNP_RESPONSE.MISS_XCORE",
+"BriefDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which misses in some processor core.",
+"PublicDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which misses in some processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x81",
+"EventName": "UNC_CBO_XSNP_RESPONSE.MISS_EVICTION",
+"BriefDescription": "A cross-core snoop resulted from L3 Eviction which 
misses in some processor core.",
+"PublicDescription": "A cross-core snoop resulted from L3 Eviction which 
misses in some processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x24",
+"EventName": "UNC_CBO_XSNP_RESPONSE.HIT_EXTERNAL",
+"BriefDescription": "An external snoop hits a non-modified line in some 
processor core.",
+"PublicDescription": "An external snoop hits a non-modified line in some 
processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x44",
+"EventName": "UNC_CBO_XSNP_RESPONSE.HIT_XCORE",
+"BriefDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which hits a non-modified line in some processor 
core.",
+"PublicDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which hits a non-modified line in some processor 
core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x84",
+"EventName": "UNC_CBO_XSNP_RESPONSE.HIT_EVICTION",
+"BriefDescription": "A cross-core snoop resulted from L3 Eviction which 
hits a non-modified line in some processor core.",
+"PublicDescription": "A cross-core snoop resulted from L3 Eviction which 
hits a non-modified line in some processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x28",
+"EventName": "UNC_CBO_XSNP_RESPONSE.HITM_EXTERNAL",
+"BriefDescription": "An external snoop hits a modified line in some 
processor core.",
+"PublicDescription": "An external snoop hits a modified line in some 
processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x48",
+"EventName": "UNC_CBO_XSNP_RESPONSE.HITM_XCORE",
+"BriefDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which hits a modified line in some processor 
core.",
+"PublicDescription": "A cross-core snoop initiated by this Cbox due to 
processor core memory request which hits a modified line in some processor 
core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x88",
+"EventName": "UNC_CBO_XSNP_RESPONSE.HITM_EVICTION",
+"BriefDescription": "A cross-core snoop resulted from L3 Eviction which 
hits a modified line in some processor core.",
+"PublicDescription": "A cross-core snoop resulted from L3 Eviction which 
hits a modified line in some processor 

[tip:perf/core] perf vendor events intel: Add missing UNC_M_DCLOCKTICKS for Broadwell DE uncore

[tip-bot for Andi Kleen]

Commit-ID:  9c4e2e2589c99ed01db6245847b4bd44bc053330
Gitweb: http://git.kernel.org/tip/9c4e2e2589c99ed01db6245847b4bd44bc053330
Author: Andi Kleen 
AuthorDate: Wed, 29 Mar 2017 17:07:53 -0700
Committer:  Andi Kleen 
CommitDate: Thu, 30 Mar 2017 13:32:25 -0700

perf vendor events intel: Add missing UNC_M_DCLOCKTICKS for Broadwell DE uncore

An earlier update removed the UNC_M_CLOCKTICKS event for Broadwell DE.
But Metric events were still referring to it.
This adds it back under a different name from the event list,
and also fixes up the Metric events to use the new name.

Cc: jo...@kernel.org
Link: http://lkml.kernel.org/n/tip-zxxzg4g5nr93o7np00vgq...@git.kernel.org
Signed-off-by: Andi Kleen 
---
 .../perf/pmu-events/arch/x86/broadwellde/uncore-memory.json | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/tools/perf/pmu-events/arch/x86/broadwellde/uncore-memory.json 
b/tools/perf/pmu-events/arch/x86/broadwellde/uncore-memory.json
index fa09e12..f4b0745 100644
--- a/tools/perf/pmu-events/arch/x86/broadwellde/uncore-memory.json
+++ b/tools/perf/pmu-events/arch/x86/broadwellde/uncore-memory.json
@@ -20,11 +20,18 @@
 "Unit": "iMC"
 },
 {
+"BriefDescription": "Memory controller clock ticks",
+"Counter": "0,1,2,3",
+"EventName": "UNC_M_DCLOCKTICKS",
+"PerPkg": "1",
+"Unit": "iMC"
+},
+{
 "BriefDescription": "Cycles where DRAM ranks are in power down (CKE) 
mode",
 "Counter": "0,1,2,3",
 "EventCode": "0x85",
 "EventName": "UNC_M_POWER_CHANNEL_PPD",
-"MetricExpr": "(UNC_M_POWER_CHANNEL_PPD / UNC_M_CLOCKTICKS) * 100.",
+"MetricExpr": "(UNC_M_POWER_CHANNEL_PPD / UNC_M_DCLOCKTICKS) * 100.",
 "MetricName": "power_channel_ppd %",
 "PerPkg": "1",
 "Unit": "iMC"
@@ -34,7 +41,7 @@
 "Counter": "0,1,2,3",
 "EventCode": "0x86",
 "EventName": "UNC_M_POWER_CRITICAL_THROTTLE_CYCLES",
-"MetricExpr": "(UNC_M_POWER_CRITICAL_THROTTLE_CYCLES / 
UNC_M_CLOCKTICKS) * 100.",
+"MetricExpr": "(UNC_M_POWER_CRITICAL_THROTTLE_CYCLES / 
UNC_M_DCLOCKTICKS) * 100.",
 "MetricName": "power_critical_throttle_cycles %",
 "PerPkg": "1",
 "Unit": "iMC"
@@ -44,7 +51,7 @@
 "Counter": "0,1,2,3",
 "EventCode": "0x43",
 "EventName": "UNC_M_POWER_SELF_REFRESH",
-"MetricExpr": "(UNC_M_POWER_SELF_REFRESH / UNC_M_CLOCKTICKS) * 100.",
+"MetricExpr": "(UNC_M_POWER_SELF_REFRESH / UNC_M_DCLOCKTICKS) * 100.",
 "MetricName": "power_self_refresh %",
 "PerPkg": "1",
 "Unit": "iMC"

Re: [kernel-hardening] [PATCH v2 1/7] bug: Clarify help text for BUG_ON_DATA_CORRUPTION

[Ian Campbell]

> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 77fadface4f9..5ac4d1148385 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1998,9 +1998,12 @@ config BUG_ON_DATA_CORRUPTION
> >     bool "Trigger a BUG when data corruption is detected"
> >     select DEBUG_LIST
> >     help
> > -     Select this option if the kernel should BUG when it encounters
> > -     data corruption in kernel memory structures when they get checked
> > -     for validity.
> > +     This option enables several inexpensive data corruption checks.
> > +     Most of these checks normally just WARN and try to further avoid
> +   the corruption. Selecting this option upgrades these to BUGs so

First it says it enables some checks, but here it says it upgrades them
to BUGs which seems inconsistent.

> +   that the offending process is killed. Additionally, the system
> +   owner can furhter configure the system for immediate reboots

   "further"

> +   (via panic_on_oops sysctl) or crash dumps.
>  
> >       If unsure, say N.
>  

[tip:perf/core] perf vendor events intel: Add missing UNC_M_DCLOCKTICKS for Broadwell DE uncore

[tip-bot for Andi Kleen]

Commit-ID:  9c4e2e2589c99ed01db6245847b4bd44bc053330
Gitweb: http://git.kernel.org/tip/9c4e2e2589c99ed01db6245847b4bd44bc053330
Author: Andi Kleen 
AuthorDate: Wed, 29 Mar 2017 17:07:53 -0700
Committer:  Andi Kleen 
CommitDate: Thu, 30 Mar 2017 13:32:25 -0700

perf vendor events intel: Add missing UNC_M_DCLOCKTICKS for Broadwell DE uncore

An earlier update removed the UNC_M_CLOCKTICKS event for Broadwell DE.
But Metric events were still referring to it.
This adds it back under a different name from the event list,
and also fixes up the Metric events to use the new name.

Cc: jo...@kernel.org
Link: http://lkml.kernel.org/n/tip-zxxzg4g5nr93o7np00vgq...@git.kernel.org
Signed-off-by: Andi Kleen 
---
 .../perf/pmu-events/arch/x86/broadwellde/uncore-memory.json | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/tools/perf/pmu-events/arch/x86/broadwellde/uncore-memory.json 
b/tools/perf/pmu-events/arch/x86/broadwellde/uncore-memory.json
index fa09e12..f4b0745 100644
--- a/tools/perf/pmu-events/arch/x86/broadwellde/uncore-memory.json
+++ b/tools/perf/pmu-events/arch/x86/broadwellde/uncore-memory.json
@@ -20,11 +20,18 @@
 "Unit": "iMC"
 },
 {
+"BriefDescription": "Memory controller clock ticks",
+"Counter": "0,1,2,3",
+"EventName": "UNC_M_DCLOCKTICKS",
+"PerPkg": "1",
+"Unit": "iMC"
+},
+{
 "BriefDescription": "Cycles where DRAM ranks are in power down (CKE) 
mode",
 "Counter": "0,1,2,3",
 "EventCode": "0x85",
 "EventName": "UNC_M_POWER_CHANNEL_PPD",
-"MetricExpr": "(UNC_M_POWER_CHANNEL_PPD / UNC_M_CLOCKTICKS) * 100.",
+"MetricExpr": "(UNC_M_POWER_CHANNEL_PPD / UNC_M_DCLOCKTICKS) * 100.",
 "MetricName": "power_channel_ppd %",
 "PerPkg": "1",
 "Unit": "iMC"
@@ -34,7 +41,7 @@
 "Counter": "0,1,2,3",
 "EventCode": "0x86",
 "EventName": "UNC_M_POWER_CRITICAL_THROTTLE_CYCLES",
-"MetricExpr": "(UNC_M_POWER_CRITICAL_THROTTLE_CYCLES / 
UNC_M_CLOCKTICKS) * 100.",
+"MetricExpr": "(UNC_M_POWER_CRITICAL_THROTTLE_CYCLES / 
UNC_M_DCLOCKTICKS) * 100.",
 "MetricName": "power_critical_throttle_cycles %",
 "PerPkg": "1",
 "Unit": "iMC"
@@ -44,7 +51,7 @@
 "Counter": "0,1,2,3",
 "EventCode": "0x43",
 "EventName": "UNC_M_POWER_SELF_REFRESH",
-"MetricExpr": "(UNC_M_POWER_SELF_REFRESH / UNC_M_CLOCKTICKS) * 100.",
+"MetricExpr": "(UNC_M_POWER_SELF_REFRESH / UNC_M_DCLOCKTICKS) * 100.",
 "MetricName": "power_self_refresh %",
 "PerPkg": "1",
 "Unit": "iMC"

Re: [kernel-hardening] [PATCH v2 1/7] bug: Clarify help text for BUG_ON_DATA_CORRUPTION

[Ian Campbell]

> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 77fadface4f9..5ac4d1148385 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1998,9 +1998,12 @@ config BUG_ON_DATA_CORRUPTION
> >     bool "Trigger a BUG when data corruption is detected"
> >     select DEBUG_LIST
> >     help
> > -     Select this option if the kernel should BUG when it encounters
> > -     data corruption in kernel memory structures when they get checked
> > -     for validity.
> > +     This option enables several inexpensive data corruption checks.
> > +     Most of these checks normally just WARN and try to further avoid
> +   the corruption. Selecting this option upgrades these to BUGs so

First it says it enables some checks, but here it says it upgrades them
to BUGs which seems inconsistent.

> +   that the offending process is killed. Additionally, the system
> +   owner can furhter configure the system for immediate reboots

   "further"

> +   (via panic_on_oops sysctl) or crash dumps.
>  
> >       If unsure, say N.
>  

[tip:perf/core] perf vendor events intel: Add uncore events for Sandy Bridge client

[tip-bot for Andi Kleen]

Commit-ID:  80432c7311dbcf0c814d4923480b055a725b0be2
Gitweb: http://git.kernel.org/tip/80432c7311dbcf0c814d4923480b055a725b0be2
Author: Andi Kleen 
AuthorDate: Wed, 29 Mar 2017 17:12:44 -0700
Committer:  Andi Kleen 
CommitDate: Thu, 30 Mar 2017 13:34:15 -0700

perf vendor events intel: Add uncore events for Sandy Bridge client

Add V15 of Sandy Bridge uncore events

Cc: jo...@kernel.org
Link: http://lkml.kernel.org/n/tip-2qkwutpwljdue8jmwk3xq...@git.kernel.org
Signed-off-by: Andi Kleen 
---
 .../pmu-events/arch/x86/sandybridge/uncore.json| 314 +
 1 file changed, 314 insertions(+)

diff --git a/tools/perf/pmu-events/arch/x86/sandybridge/uncore.json 
b/tools/perf/pmu-events/arch/x86/sandybridge/uncore.json
new file mode 100644
index 000..42c70ee
--- /dev/null
+++ b/tools/perf/pmu-events/arch/x86/sandybridge/uncore.json
@@ -0,0 +1,314 @@
+[
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x01",
+"EventName": "UNC_CBO_XSNP_RESPONSE.MISS",
+"BriefDescription": "A snoop misses in some processor core.",
+"PublicDescription": "A snoop misses in some processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x02",
+"EventName": "UNC_CBO_XSNP_RESPONSE.INVAL",
+"BriefDescription": "A snoop invalidates a non-modified line in some 
processor core.",
+"PublicDescription": "A snoop invalidates a non-modified line in some 
processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x04",
+"EventName": "UNC_CBO_XSNP_RESPONSE.HIT",
+"BriefDescription": "A snoop hits a non-modified line in some processor 
core.",
+"PublicDescription": "A snoop hits a non-modified line in some processor 
core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x08",
+"EventName": "UNC_CBO_XSNP_RESPONSE.HITM",
+"BriefDescription": "A snoop hits a modified line in some processor core.",
+"PublicDescription": "A snoop hits a modified line in some processor 
core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x10",
+"EventName": "UNC_CBO_XSNP_RESPONSE.INVAL_M",
+"BriefDescription": "A snoop invalidates a modified line in some processor 
core.",
+"PublicDescription": "A snoop invalidates a modified line in some 
processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x20",
+"EventName": "UNC_CBO_XSNP_RESPONSE.EXTERNAL_FILTER",
+"BriefDescription": "Filter on cross-core snoops initiated by this Cbox 
due to external snoop request.",
+"PublicDescription": "Filter on cross-core snoops initiated by this Cbox 
due to external snoop request.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x40",
+"EventName": "UNC_CBO_XSNP_RESPONSE.XCORE_FILTER",
+"BriefDescription": "Filter on cross-core snoops initiated by this Cbox 
due to processor core memory request.",
+"PublicDescription": "Filter on cross-core snoops initiated by this Cbox 
due to processor core memory request.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x80",
+"EventName": "UNC_CBO_XSNP_RESPONSE.EVICTION_FILTER",
+"BriefDescription": "Filter on cross-core snoops initiated by this Cbox 
due to LLC eviction.",
+"PublicDescription": "Filter on cross-core snoops initiated by this Cbox 
due to LLC eviction.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x34",
+"UMask": "0x01",
+"EventName": "UNC_CBO_CACHE_LOOKUP.M",
+"BriefDescription": "LLC lookup request that access cache and found line 
in M-state.",
+"PublicDescription": "LLC lookup request that access cache and found line 
in M-state.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x34",
+"UMask": "0x02",
+"EventName": "UNC_CBO_CACHE_LOOKUP.E",
+"BriefDescription": "LLC lookup request that access cache and found line 
in E-state.",
+"PublicDescription": "LLC lookup request that access cache and found line 
in E-state.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": 

[tip:perf/core] perf vendor events intel: Add uncore events for Ivy Bridge client

[tip-bot for Andi Kleen]

Commit-ID:  bccdcb2a77ba0bef17baf152179e30ca35459a0c
Gitweb: http://git.kernel.org/tip/bccdcb2a77ba0bef17baf152179e30ca35459a0c
Author: Andi Kleen 
AuthorDate: Wed, 29 Mar 2017 17:14:02 -0700
Committer:  Andi Kleen 
CommitDate: Thu, 30 Mar 2017 13:35:01 -0700

perf vendor events intel: Add uncore events for Ivy Bridge client

Add V18 of Ivy Bridge uncore events

Cc: jo...@kernel.org
Link: http://lkml.kernel.org/n/tip-299k76asec5rwp0i86qyg...@git.kernel.org
Signed-off-by: Andi Kleen 
---
 tools/perf/pmu-events/arch/x86/{sandybridge => ivybridge}/uncore.json | 0
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/tools/perf/pmu-events/arch/x86/sandybridge/uncore.json 
b/tools/perf/pmu-events/arch/x86/ivybridge/uncore.json
similarity index 100%
copy from tools/perf/pmu-events/arch/x86/sandybridge/uncore.json
copy to tools/perf/pmu-events/arch/x86/ivybridge/uncore.json

Re: [PATCH] net: phy: broadcom: Add support for the BCM54210E

[Joel Stanley]

On Wed, Apr 5, 2017 at 3:17 PM, Florian Fainelli  wrote:
>
>
> On 04/04/2017 10:33 PM, Joel Stanley wrote:
>> This device is a single-port RGMII 10/100/1000BASE-T PHY with EEE & WOL.
>
> This looks good, although Rafal did beat you to it:
>
> 0fc9ae107669760c2a8658cb5b5876dbe525e08d ("net: phy: broadcom: add
> support for BCM54210E")

Even better! Thank you.

Cheers,

Joel

Re: [PATCH] net: phy: broadcom: Add support for the BCM54210E

[Joel Stanley]

On Wed, Apr 5, 2017 at 3:17 PM, Florian Fainelli  wrote:
>
>
> On 04/04/2017 10:33 PM, Joel Stanley wrote:
>> This device is a single-port RGMII 10/100/1000BASE-T PHY with EEE & WOL.
>
> This looks good, although Rafal did beat you to it:
>
> 0fc9ae107669760c2a8658cb5b5876dbe525e08d ("net: phy: broadcom: add
> support for BCM54210E")

Even better! Thank you.

Cheers,

Joel

[tip:perf/core] perf vendor events intel: Add uncore events for Sandy Bridge client

[tip-bot for Andi Kleen]

Commit-ID:  80432c7311dbcf0c814d4923480b055a725b0be2
Gitweb: http://git.kernel.org/tip/80432c7311dbcf0c814d4923480b055a725b0be2
Author: Andi Kleen 
AuthorDate: Wed, 29 Mar 2017 17:12:44 -0700
Committer:  Andi Kleen 
CommitDate: Thu, 30 Mar 2017 13:34:15 -0700

perf vendor events intel: Add uncore events for Sandy Bridge client

Add V15 of Sandy Bridge uncore events

Cc: jo...@kernel.org
Link: http://lkml.kernel.org/n/tip-2qkwutpwljdue8jmwk3xq...@git.kernel.org
Signed-off-by: Andi Kleen 
---
 .../pmu-events/arch/x86/sandybridge/uncore.json| 314 +
 1 file changed, 314 insertions(+)

diff --git a/tools/perf/pmu-events/arch/x86/sandybridge/uncore.json 
b/tools/perf/pmu-events/arch/x86/sandybridge/uncore.json
new file mode 100644
index 000..42c70ee
--- /dev/null
+++ b/tools/perf/pmu-events/arch/x86/sandybridge/uncore.json
@@ -0,0 +1,314 @@
+[
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x01",
+"EventName": "UNC_CBO_XSNP_RESPONSE.MISS",
+"BriefDescription": "A snoop misses in some processor core.",
+"PublicDescription": "A snoop misses in some processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x02",
+"EventName": "UNC_CBO_XSNP_RESPONSE.INVAL",
+"BriefDescription": "A snoop invalidates a non-modified line in some 
processor core.",
+"PublicDescription": "A snoop invalidates a non-modified line in some 
processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x04",
+"EventName": "UNC_CBO_XSNP_RESPONSE.HIT",
+"BriefDescription": "A snoop hits a non-modified line in some processor 
core.",
+"PublicDescription": "A snoop hits a non-modified line in some processor 
core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x08",
+"EventName": "UNC_CBO_XSNP_RESPONSE.HITM",
+"BriefDescription": "A snoop hits a modified line in some processor core.",
+"PublicDescription": "A snoop hits a modified line in some processor 
core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x10",
+"EventName": "UNC_CBO_XSNP_RESPONSE.INVAL_M",
+"BriefDescription": "A snoop invalidates a modified line in some processor 
core.",
+"PublicDescription": "A snoop invalidates a modified line in some 
processor core.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x20",
+"EventName": "UNC_CBO_XSNP_RESPONSE.EXTERNAL_FILTER",
+"BriefDescription": "Filter on cross-core snoops initiated by this Cbox 
due to external snoop request.",
+"PublicDescription": "Filter on cross-core snoops initiated by this Cbox 
due to external snoop request.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x40",
+"EventName": "UNC_CBO_XSNP_RESPONSE.XCORE_FILTER",
+"BriefDescription": "Filter on cross-core snoops initiated by this Cbox 
due to processor core memory request.",
+"PublicDescription": "Filter on cross-core snoops initiated by this Cbox 
due to processor core memory request.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x22",
+"UMask": "0x80",
+"EventName": "UNC_CBO_XSNP_RESPONSE.EVICTION_FILTER",
+"BriefDescription": "Filter on cross-core snoops initiated by this Cbox 
due to LLC eviction.",
+"PublicDescription": "Filter on cross-core snoops initiated by this Cbox 
due to LLC eviction.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x34",
+"UMask": "0x01",
+"EventName": "UNC_CBO_CACHE_LOOKUP.M",
+"BriefDescription": "LLC lookup request that access cache and found line 
in M-state.",
+"PublicDescription": "LLC lookup request that access cache and found line 
in M-state.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+"EventCode": "0x34",
+"UMask": "0x02",
+"EventName": "UNC_CBO_CACHE_LOOKUP.E",
+"BriefDescription": "LLC lookup request that access cache and found line 
in E-state.",
+"PublicDescription": "LLC lookup request that access cache and found line 
in E-state.",
+"Counter": "0,1",
+"CounterMask": "0",
+"Invert": "0",
+"EdgeDetect": "0"
+  },
+  {
+"Unit": "CBO",
+

[tip:perf/core] perf vendor events intel: Add uncore events for Ivy Bridge client

[tip-bot for Andi Kleen]

Commit-ID:  bccdcb2a77ba0bef17baf152179e30ca35459a0c
Gitweb: http://git.kernel.org/tip/bccdcb2a77ba0bef17baf152179e30ca35459a0c
Author: Andi Kleen 
AuthorDate: Wed, 29 Mar 2017 17:14:02 -0700
Committer:  Andi Kleen 
CommitDate: Thu, 30 Mar 2017 13:35:01 -0700

perf vendor events intel: Add uncore events for Ivy Bridge client

Add V18 of Ivy Bridge uncore events

Cc: jo...@kernel.org
Link: http://lkml.kernel.org/n/tip-299k76asec5rwp0i86qyg...@git.kernel.org
Signed-off-by: Andi Kleen 
---
 tools/perf/pmu-events/arch/x86/{sandybridge => ivybridge}/uncore.json | 0
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/tools/perf/pmu-events/arch/x86/sandybridge/uncore.json 
b/tools/perf/pmu-events/arch/x86/ivybridge/uncore.json
similarity index 100%
copy from tools/perf/pmu-events/arch/x86/sandybridge/uncore.json
copy to tools/perf/pmu-events/arch/x86/ivybridge/uncore.json

Re: [PATCH] net: phy: broadcom: Add support for the BCM54210E

[Florian Fainelli]

On 04/04/2017 10:33 PM, Joel Stanley wrote:
> This device is a single-port RGMII 10/100/1000BASE-T PHY with EEE & WOL.

This looks good, although Rafal did beat you to it:

0fc9ae107669760c2a8658cb5b5876dbe525e08d ("net: phy: broadcom: add
support for BCM54210E")
-- 
Florian

Re: [PATCH] net: phy: broadcom: Add support for the BCM54210E

[Florian Fainelli]

On 04/04/2017 10:33 PM, Joel Stanley wrote:
> This device is a single-port RGMII 10/100/1000BASE-T PHY with EEE & WOL.

This looks good, although Rafal did beat you to it:

0fc9ae107669760c2a8658cb5b5876dbe525e08d ("net: phy: broadcom: add
support for BCM54210E")
-- 
Florian

Re: [GIT PULL 00/13] perf/core improvements and fixes

[Ingo Molnar]

* Arnaldo Carvalho de Melo <a...@kernel.org> wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> Test results at the end of this message, as usual.
> 
> The following changes since commit fcc309e618c9e9ac4ede010d87522b0689549658:
> 
>   Merge tag 'perf-core-for-mingo-4.12-20170331' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 
> (2017-04-01 12:43:40 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-core-for-mingo-4.12-20170404
> 
> for you to fetch changes up to 99094a5e941fe88d95cbd594e6a41bee24003ecb:
> 
>   perf annotate: Fix missing number of samples for source_line_samples 
> (2017-04-04 21:08:00 -0300)
> 
> 
> perf/core improvements and fixes:
> 
> User visible:
> 
> - Add missing number of samples in 'perf annotate --stdio -l 
> --show-total-period'
>   (Taeung Song)
> 
> Vendor events updates:
> 
> - Add uncore_arb Intel vendor events in JSON format (Andi Kleen)
> 
> - Add uncore vendor events for Intel's Sandy Bridge, Ivy Bridge,
>   Haswell, Broadwell and Skylake architectures (Andi Kleen)
> 
> - Add missing UNC_M_DCLOCKTICKS Intel Broadwell DE uncore vendor event (Andi 
> Kleen)
> 
> Infrastructure:
> 
> - Remove some more die() calls, avoiding sudden death in library code
>   (Arnaldo Carvalho de Melo)
> 
> - Add argument support for SDT events in powerpc (Ravi Bangoria)
> 
> Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
> 
> 
> Andi Kleen (8):
>   perf vendor events intel: Add missing UNC_M_DCLOCKTICKS for Broadwell 
> DE uncore
>   perf vendor events intel: Add uncore events for Sandy Bridge client
>   perf vendor events intel: Add uncore events for Ivy Bridge client
>   perf vendor events intel: Add uncore events for Haswell client
>   perf vendor events intel: Add uncore events for Broadwell client
>   perf vendor events intel: Add uncore events for Skylake client
>   perf vendor events intel: Add uncore_arb JSON support
>   perf vendor events intel: Add missing space in json descriptions
> 
> Arnaldo Carvalho de Melo (4):
>   Merge branch 'perf/uncore-json-updates-1' of 
> git://git.kernel.org/.../ak/linux-misc into perf/core
>   perf tools: Remove die() call
>   perf tools: Handle allocation failures gracefully
>   perf tools: Don't die on a print function
> 
> Ravi Bangoria (1):
>   perf sdt powerpc: Add argument support
> 
> Taeung Song (1):
>   perf annotate: Fix missing number of samples for source_line_samples
> 
>  tools/perf/arch/powerpc/util/perf_regs.c   | 111 ++
>  tools/perf/perf.c  |   3 +-
>  .../perf/pmu-events/arch/x86/broadwell/uncore.json | 278 +++
>  .../arch/x86/broadwellde/uncore-memory.json|  13 +-
>  tools/perf/pmu-events/arch/x86/haswell/uncore.json | 374 
> +
>  .../perf/pmu-events/arch/x86/ivybridge/uncore.json | 314 +
>  .../pmu-events/arch/x86/sandybridge/uncore.json| 314 +
>  tools/perf/pmu-events/arch/x86/skylake/uncore.json | 254 ++
>  tools/perf/pmu-events/jevents.c|   2 +
>  tools/perf/util/annotate.c |   6 +-
>  tools/perf/util/annotate.h |   2 +-
>  tools/perf/util/values.c   |  63 +++-
>  12 files changed, 1710 insertions(+), 24 deletions(-)
>  create mode 100644 tools/perf/pmu-events/arch/x86/broadwell/uncore.json
>  create mode 100644 tools/perf/pmu-events/arch/x86/haswell/uncore.json
>  create mode 100644 tools/perf/pmu-events/arch/x86/ivybridge/uncore.json
>  create mode 100644 tools/perf/pmu-events/arch/x86/sandybridge/uncore.json
>  create mode 100644 tools/perf/pmu-events/arch/x86/skylake/uncore.json

Pulled, thanks a lot Arnaldo!

Ingo

Re: [GIT PULL 00/13] perf/core improvements and fixes

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> Test results at the end of this message, as usual.
> 
> The following changes since commit fcc309e618c9e9ac4ede010d87522b0689549658:
> 
>   Merge tag 'perf-core-for-mingo-4.12-20170331' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 
> (2017-04-01 12:43:40 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-core-for-mingo-4.12-20170404
> 
> for you to fetch changes up to 99094a5e941fe88d95cbd594e6a41bee24003ecb:
> 
>   perf annotate: Fix missing number of samples for source_line_samples 
> (2017-04-04 21:08:00 -0300)
> 
> 
> perf/core improvements and fixes:
> 
> User visible:
> 
> - Add missing number of samples in 'perf annotate --stdio -l 
> --show-total-period'
>   (Taeung Song)
> 
> Vendor events updates:
> 
> - Add uncore_arb Intel vendor events in JSON format (Andi Kleen)
> 
> - Add uncore vendor events for Intel's Sandy Bridge, Ivy Bridge,
>   Haswell, Broadwell and Skylake architectures (Andi Kleen)
> 
> - Add missing UNC_M_DCLOCKTICKS Intel Broadwell DE uncore vendor event (Andi 
> Kleen)
> 
> Infrastructure:
> 
> - Remove some more die() calls, avoiding sudden death in library code
>   (Arnaldo Carvalho de Melo)
> 
> - Add argument support for SDT events in powerpc (Ravi Bangoria)
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Andi Kleen (8):
>   perf vendor events intel: Add missing UNC_M_DCLOCKTICKS for Broadwell 
> DE uncore
>   perf vendor events intel: Add uncore events for Sandy Bridge client
>   perf vendor events intel: Add uncore events for Ivy Bridge client
>   perf vendor events intel: Add uncore events for Haswell client
>   perf vendor events intel: Add uncore events for Broadwell client
>   perf vendor events intel: Add uncore events for Skylake client
>   perf vendor events intel: Add uncore_arb JSON support
>   perf vendor events intel: Add missing space in json descriptions
> 
> Arnaldo Carvalho de Melo (4):
>   Merge branch 'perf/uncore-json-updates-1' of 
> git://git.kernel.org/.../ak/linux-misc into perf/core
>   perf tools: Remove die() call
>   perf tools: Handle allocation failures gracefully
>   perf tools: Don't die on a print function
> 
> Ravi Bangoria (1):
>   perf sdt powerpc: Add argument support
> 
> Taeung Song (1):
>   perf annotate: Fix missing number of samples for source_line_samples
> 
>  tools/perf/arch/powerpc/util/perf_regs.c   | 111 ++
>  tools/perf/perf.c  |   3 +-
>  .../perf/pmu-events/arch/x86/broadwell/uncore.json | 278 +++
>  .../arch/x86/broadwellde/uncore-memory.json|  13 +-
>  tools/perf/pmu-events/arch/x86/haswell/uncore.json | 374 
> +
>  .../perf/pmu-events/arch/x86/ivybridge/uncore.json | 314 +
>  .../pmu-events/arch/x86/sandybridge/uncore.json| 314 +
>  tools/perf/pmu-events/arch/x86/skylake/uncore.json | 254 ++
>  tools/perf/pmu-events/jevents.c|   2 +
>  tools/perf/util/annotate.c |   6 +-
>  tools/perf/util/annotate.h |   2 +-
>  tools/perf/util/values.c   |  63 +++-
>  12 files changed, 1710 insertions(+), 24 deletions(-)
>  create mode 100644 tools/perf/pmu-events/arch/x86/broadwell/uncore.json
>  create mode 100644 tools/perf/pmu-events/arch/x86/haswell/uncore.json
>  create mode 100644 tools/perf/pmu-events/arch/x86/ivybridge/uncore.json
>  create mode 100644 tools/perf/pmu-events/arch/x86/sandybridge/uncore.json
>  create mode 100644 tools/perf/pmu-events/arch/x86/skylake/uncore.json

Pulled, thanks a lot Arnaldo!

Ingo

[PATCH] net: phy: broadcom: Add support for the BCM54210E

[Joel Stanley]

This device is a single-port RGMII 10/100/1000BASE-T PHY with EEE & WOL.

Signed-off-by: Joel Stanley 
---
 drivers/net/phy/broadcom.c | 13 +
 include/linux/brcmphy.h|  2 ++
 2 files changed, 15 insertions(+)

diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 9cd8b27d1292..3df826323129 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -703,6 +703,18 @@ static struct phy_driver broadcom_drivers[] = {
.read_status= genphy_read_status,
.ack_interrupt  = brcm_fet_ack_interrupt,
.config_intr= brcm_fet_config_intr,
+}, {
+   .phy_id = PHY_ID_BCM54210E,
+   .phy_id_mask= 0xfff0,
+   .name   = "Broadcom BCM54210E",
+   .features   = PHY_GBIT_FEATURES |
+   SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+   .flags  = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+   .config_init= bcm54xx_config_init,
+   .config_aneg= genphy_config_aneg,
+   .read_status= genphy_read_status,
+   .ack_interrupt  = bcm_phy_ack_intr,
+   .config_intr= bcm_phy_config_intr,
 } };
 
 module_phy_driver(broadcom_drivers);
@@ -723,6 +735,7 @@ static struct mdio_device_id __maybe_unused broadcom_tbl[] 
= {
{ PHY_ID_BCM57780, 0xfff0 },
{ PHY_ID_BCMAC131, 0xfff0 },
{ PHY_ID_BCM5241, 0xfff0 },
+   { PHY_ID_BCM54210E, 0xfff0},
{ }
 };
 
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 55e517130311..53106b9c89f1 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -40,6 +40,8 @@
 
 #define PHY_ID_BCM_CYGNUS  0xae025200
 
+#define PHY_ID_BCM54210E   0x600d84a0
+
 #define PHY_BCM_OUI_MASK   0xfc00
 #define PHY_BCM_OUI_1  0x00206000
 #define PHY_BCM_OUI_2  0x0143bc00
-- 
2.11.0

[PATCH] net: phy: broadcom: Add support for the BCM54210E

[Joel Stanley]

This device is a single-port RGMII 10/100/1000BASE-T PHY with EEE & WOL.

Signed-off-by: Joel Stanley 
---
 drivers/net/phy/broadcom.c | 13 +
 include/linux/brcmphy.h|  2 ++
 2 files changed, 15 insertions(+)

diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 9cd8b27d1292..3df826323129 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -703,6 +703,18 @@ static struct phy_driver broadcom_drivers[] = {
.read_status= genphy_read_status,
.ack_interrupt  = brcm_fet_ack_interrupt,
.config_intr= brcm_fet_config_intr,
+}, {
+   .phy_id = PHY_ID_BCM54210E,
+   .phy_id_mask= 0xfff0,
+   .name   = "Broadcom BCM54210E",
+   .features   = PHY_GBIT_FEATURES |
+   SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+   .flags  = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+   .config_init= bcm54xx_config_init,
+   .config_aneg= genphy_config_aneg,
+   .read_status= genphy_read_status,
+   .ack_interrupt  = bcm_phy_ack_intr,
+   .config_intr= bcm_phy_config_intr,
 } };
 
 module_phy_driver(broadcom_drivers);
@@ -723,6 +735,7 @@ static struct mdio_device_id __maybe_unused broadcom_tbl[] 
= {
{ PHY_ID_BCM57780, 0xfff0 },
{ PHY_ID_BCMAC131, 0xfff0 },
{ PHY_ID_BCM5241, 0xfff0 },
+   { PHY_ID_BCM54210E, 0xfff0},
{ }
 };
 
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 55e517130311..53106b9c89f1 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -40,6 +40,8 @@
 
 #define PHY_ID_BCM_CYGNUS  0xae025200
 
+#define PHY_ID_BCM54210E   0x600d84a0
+
 #define PHY_BCM_OUI_MASK   0xfc00
 #define PHY_BCM_OUI_1  0x00206000
 #define PHY_BCM_OUI_2  0x0143bc00
-- 
2.11.0

[PATCH] cs-2000-cp: keep Reserved bit on each register

[Kuninori Morimoto]

From: Kuninori Morimoto 

Thus CS2000 datasheet is indicating below, this patch
follows it.

WARNING: All "Reserved" registers must maintain their default
 state to ensure proper functional operation.

Signed-off-by: Kuninori Morimoto 
---
 drivers/clk/clk-cs2000-cp.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk-cs2000-cp.c b/drivers/clk/clk-cs2000-cp.c
index 3fca052..f5915ff 100644
--- a/drivers/clk/clk-cs2000-cp.c
+++ b/drivers/clk/clk-cs2000-cp.c
@@ -36,15 +36,27 @@
 
 /* DEVICE_CTRL */
 #define PLL_UNLOCK (1 << 7)
+#define AUXOUTDIS  (1 << 1)
+#define CLKOUTDIS  (1 << 0)
 
 /* DEVICE_CFG1 */
 #define RSEL(x)(((x) & 0x3) << 3)
 #define RSEL_MASK  RSEL(0x3)
 #define ENDEV1 (0x1)
 
+/* DEVICE_CFG2 */
+#define AUTORMOD   (1 << 3)
+#define LOCKCLK(x) (((x) & 0x3) << 1)
+#define LOCKCLK_MASK   LOCKCLK(0x3)
+#define FRACNSRC   (1 << 0)
+
 /* GLOBAL_CFG */
 #define ENDEV2 (0x1)
 
+/* FUNC_CFG1 */
+#define REFCLKDIV(x)   (((x) & 0x3) << 3)
+#define REFCLKDIV_MASK REFCLKDIV(0x3)
+
 #define CH_SIZE_ERR(ch)((ch < 0) || (ch >= CH_MAX))
 #define hw_to_priv(_hw)container_of(_hw, struct cs2000_priv, 
hw)
 #define priv_to_client(priv)   (priv->client)
@@ -127,7 +139,9 @@ static int cs2000_clk_in_bound_rate(struct cs2000_priv 
*priv,
else
return -EINVAL;
 
-   return cs2000_bset(priv, FUNC_CFG1, 0x3 << 3, val << 3);
+   return cs2000_bset(priv, FUNC_CFG1,
+  REFCLKDIV_MASK,
+  REFCLKDIV(val));
 }
 
 static int cs2000_wait_pll_lock(struct cs2000_priv *priv)
@@ -153,7 +167,10 @@ static int cs2000_wait_pll_lock(struct cs2000_priv *priv)
 static int cs2000_clk_out_enable(struct cs2000_priv *priv, bool enable)
 {
/* enable both AUX_OUT, CLK_OUT */
-   return cs2000_write(priv, DEVICE_CTRL, enable ? 0 : 0x3);
+   return cs2000_bset(priv, DEVICE_CTRL,
+  (AUXOUTDIS | CLKOUTDIS),
+  enable ? 0 :
+  (AUXOUTDIS | CLKOUTDIS));
 }
 
 static u32 cs2000_rate_to_ratio(u32 rate_in, u32 rate_out)
@@ -243,7 +260,9 @@ static int cs2000_ratio_select(struct cs2000_priv *priv, 
int ch)
if (ret < 0)
return ret;
 
-   ret = cs2000_write(priv, DEVICE_CFG2, 0x0);
+   ret = cs2000_bset(priv, DEVICE_CFG2,
+ (AUTORMOD | LOCKCLK_MASK | FRACNSRC),
+ 0);
if (ret < 0)
return ret;
 
-- 
1.9.1

[PATCH] cs-2000-cp: keep Reserved bit on each register

[Kuninori Morimoto]

From: Kuninori Morimoto 

Thus CS2000 datasheet is indicating below, this patch
follows it.

WARNING: All "Reserved" registers must maintain their default
 state to ensure proper functional operation.

Signed-off-by: Kuninori Morimoto 
---
 drivers/clk/clk-cs2000-cp.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk-cs2000-cp.c b/drivers/clk/clk-cs2000-cp.c
index 3fca052..f5915ff 100644
--- a/drivers/clk/clk-cs2000-cp.c
+++ b/drivers/clk/clk-cs2000-cp.c
@@ -36,15 +36,27 @@
 
 /* DEVICE_CTRL */
 #define PLL_UNLOCK (1 << 7)
+#define AUXOUTDIS  (1 << 1)
+#define CLKOUTDIS  (1 << 0)
 
 /* DEVICE_CFG1 */
 #define RSEL(x)(((x) & 0x3) << 3)
 #define RSEL_MASK  RSEL(0x3)
 #define ENDEV1 (0x1)
 
+/* DEVICE_CFG2 */
+#define AUTORMOD   (1 << 3)
+#define LOCKCLK(x) (((x) & 0x3) << 1)
+#define LOCKCLK_MASK   LOCKCLK(0x3)
+#define FRACNSRC   (1 << 0)
+
 /* GLOBAL_CFG */
 #define ENDEV2 (0x1)
 
+/* FUNC_CFG1 */
+#define REFCLKDIV(x)   (((x) & 0x3) << 3)
+#define REFCLKDIV_MASK REFCLKDIV(0x3)
+
 #define CH_SIZE_ERR(ch)((ch < 0) || (ch >= CH_MAX))
 #define hw_to_priv(_hw)container_of(_hw, struct cs2000_priv, 
hw)
 #define priv_to_client(priv)   (priv->client)
@@ -127,7 +139,9 @@ static int cs2000_clk_in_bound_rate(struct cs2000_priv 
*priv,
else
return -EINVAL;
 
-   return cs2000_bset(priv, FUNC_CFG1, 0x3 << 3, val << 3);
+   return cs2000_bset(priv, FUNC_CFG1,
+  REFCLKDIV_MASK,
+  REFCLKDIV(val));
 }
 
 static int cs2000_wait_pll_lock(struct cs2000_priv *priv)
@@ -153,7 +167,10 @@ static int cs2000_wait_pll_lock(struct cs2000_priv *priv)
 static int cs2000_clk_out_enable(struct cs2000_priv *priv, bool enable)
 {
/* enable both AUX_OUT, CLK_OUT */
-   return cs2000_write(priv, DEVICE_CTRL, enable ? 0 : 0x3);
+   return cs2000_bset(priv, DEVICE_CTRL,
+  (AUXOUTDIS | CLKOUTDIS),
+  enable ? 0 :
+  (AUXOUTDIS | CLKOUTDIS));
 }
 
 static u32 cs2000_rate_to_ratio(u32 rate_in, u32 rate_out)
@@ -243,7 +260,9 @@ static int cs2000_ratio_select(struct cs2000_priv *priv, 
int ch)
if (ret < 0)
return ret;
 
-   ret = cs2000_write(priv, DEVICE_CFG2, 0x0);
+   ret = cs2000_bset(priv, DEVICE_CFG2,
+ (AUTORMOD | LOCKCLK_MASK | FRACNSRC),
+ 0);
if (ret < 0)
return ret;
 
-- 
1.9.1

[PATCH 1/1] ARM: dts: armada-xp-linksys-mamba: use wan instead of internet for DSA port

[Ralph Sennhauser]

The LEDs for the "wan" port are already labeled "mamba:amber:wan" resp.
"mamba:white:wan". So besides being an outlier with regard to the rest
of the product line (see table below) changing the label fixes an
internal inconsistency as well.

This will be visible in user space. Given commit cb4f71c42988 ("ARM:
dts: armada-38x: change order of ethernet DT nodes on Armada 38x") it's
expected to happen anyway. Commit 499400c9ac20 ("ARM: dts:
armada-xp-linksys-mamba: Utilize new DSA binding") switches to the new
bindings, use this opportunity to do it now rather than later.

|-|
| Labels used for the case and those used for the DSA ports   |
|-|
| case labels   | armada-385-linksys-*  | armada-xp-linksys-mamba |
|---|---|-|
| internet  | wan   | internet|
| 1 | lan1  | lan1|
| 2 | lan2  | lan2|
| 3 | lan3  | lan3|
| 4 | lan4  | lan4|
|-|

Signed-off-by: Ralph Sennhauser 
---

Hi everybody,

I underestimated the urge of people to make all the same before. While I do not
particularly like this sort of change I see it coming anyway. So this patch is
meant to make it a deliberate decision so it no longer is an item lurking in
the shadows. Whether this patch gets taken or rejected my goal is reached.

In hindsight wan would have been the better choice.

Ralph

 arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts 
b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
index 9efcf59..0143aed 100644
--- a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
+++ b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
@@ -354,7 +354,7 @@
 
port@4 {
reg = <4>;
-   label = "internet";
+   label = "wan";
};
 
port@5 {
@@ -452,7 +452,7 @@
 
port@4 {
reg = <4>;
-   label = "internet";
+   label = "wan";
};
 
port@5 {
-- 
2.10.2

[PATCH 1/1] ARM: dts: armada-xp-linksys-mamba: use wan instead of internet for DSA port

[Ralph Sennhauser]

The LEDs for the "wan" port are already labeled "mamba:amber:wan" resp.
"mamba:white:wan". So besides being an outlier with regard to the rest
of the product line (see table below) changing the label fixes an
internal inconsistency as well.

This will be visible in user space. Given commit cb4f71c42988 ("ARM:
dts: armada-38x: change order of ethernet DT nodes on Armada 38x") it's
expected to happen anyway. Commit 499400c9ac20 ("ARM: dts:
armada-xp-linksys-mamba: Utilize new DSA binding") switches to the new
bindings, use this opportunity to do it now rather than later.

|-|
| Labels used for the case and those used for the DSA ports   |
|-|
| case labels   | armada-385-linksys-*  | armada-xp-linksys-mamba |
|---|---|-|
| internet  | wan   | internet|
| 1 | lan1  | lan1|
| 2 | lan2  | lan2|
| 3 | lan3  | lan3|
| 4 | lan4  | lan4|
|-|

Signed-off-by: Ralph Sennhauser 
---

Hi everybody,

I underestimated the urge of people to make all the same before. While I do not
particularly like this sort of change I see it coming anyway. So this patch is
meant to make it a deliberate decision so it no longer is an item lurking in
the shadows. Whether this patch gets taken or rejected my goal is reached.

In hindsight wan would have been the better choice.

Ralph

 arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts 
b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
index 9efcf59..0143aed 100644
--- a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
+++ b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
@@ -354,7 +354,7 @@
 
port@4 {
reg = <4>;
-   label = "internet";
+   label = "wan";
};
 
port@5 {
@@ -452,7 +452,7 @@
 
port@4 {
reg = <4>;
-   label = "internet";
+   label = "wan";
};
 
port@5 {
-- 
2.10.2

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

[Cong Wang]

On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith  wrote:
> -   while (some_qdisc_is_busy(dev))
> -   yield();
> +   swait_event_timeout(swait, !some_qdisc_is_busy(dev), 1);
>  }

I don't see why this is an improvement even if I don't care about the
hardcoded timeout for now... Why the scheduler can make a better
decision with swait_event_timeout() than with cond_resched()?

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

[Cong Wang]

On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith  wrote:
> -   while (some_qdisc_is_busy(dev))
> -   yield();
> +   swait_event_timeout(swait, !some_qdisc_is_busy(dev), 1);
>  }

I don't see why this is an improvement even if I don't care about the
hardcoded timeout for now... Why the scheduler can make a better
decision with swait_event_timeout() than with cond_resched()?

Re: [PATCH] loop: Add PF_LESS_THROTTLE to block/loop device thread.

[Ming Lei]

On Wed, Apr 5, 2017 at 12:27 PM, NeilBrown  wrote:
> On Tue, Apr 04 2017, Christoph Hellwig wrote:
>
>> Looks fine,
>>
>> Reviewed-by: Christoph Hellwig 
>>
>> But if you actually care about performance in any way I'd suggest
>> to use the loop device in direct I/O mode..
>
> The losetup on my test VM is too old to support that :-(
> I guess it might be time to upgraded.
>
> It seems that there is not "mount -o direct_loop" or similar, so you
> have to do the losetup and the mount separately.  Any thoughts on

I guess the 'direct_loop' can be added into 'mount' directly? but not familiar
with mount utility.

> whether that should be changed ?

There was sysfs interface for controling direct IO in the initial
submission, but
looks it was reviewed out, :-)


Thanks,
Ming Lei

Re: [PATCH] loop: Add PF_LESS_THROTTLE to block/loop device thread.

[Ming Lei]

On Wed, Apr 5, 2017 at 12:27 PM, NeilBrown  wrote:
> On Tue, Apr 04 2017, Christoph Hellwig wrote:
>
>> Looks fine,
>>
>> Reviewed-by: Christoph Hellwig 
>>
>> But if you actually care about performance in any way I'd suggest
>> to use the loop device in direct I/O mode..
>
> The losetup on my test VM is too old to support that :-(
> I guess it might be time to upgraded.
>
> It seems that there is not "mount -o direct_loop" or similar, so you
> have to do the losetup and the mount separately.  Any thoughts on

I guess the 'direct_loop' can be added into 'mount' directly? but not familiar
with mount utility.

> whether that should be changed ?

There was sysfs interface for controling direct IO in the initial
submission, but
looks it was reviewed out, :-)


Thanks,
Ming Lei

[PATCH] af_unix: Use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, and the initializer fixes
were extracted from grsecurity. In this case, NULL initialize with { }
instead of undesignated NULLs.

Signed-off-by: Kees Cook 
---
 net/unix/af_unix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 928691c43408..6a7fe7660551 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -996,7 +996,7 @@ static int unix_bind(struct socket *sock, struct sockaddr 
*uaddr, int addr_len)
unsigned int hash;
struct unix_address *addr;
struct hlist_head *list;
-   struct path path = { NULL, NULL };
+   struct path path = { };
 
err = -EINVAL;
if (sunaddr->sun_family != AF_UNIX)
-- 
2.7.4


-- 
Kees Cook
Pixel Security

[PATCH] af_unix: Use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, and the initializer fixes
were extracted from grsecurity. In this case, NULL initialize with { }
instead of undesignated NULLs.

Signed-off-by: Kees Cook 
---
 net/unix/af_unix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 928691c43408..6a7fe7660551 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -996,7 +996,7 @@ static int unix_bind(struct socket *sock, struct sockaddr 
*uaddr, int addr_len)
unsigned int hash;
struct unix_address *addr;
struct hlist_head *list;
-   struct path path = { NULL, NULL };
+   struct path path = { };
 
err = -EINVAL;
if (sunaddr->sun_family != AF_UNIX)
-- 
2.7.4


-- 
Kees Cook
Pixel Security

Re: [PATCH v2] loop: Add PF_LESS_THROTTLE to block/loop device thread.

[Ming Lei]

On Wed, Apr 5, 2017 at 12:33 PM, NeilBrown  wrote:
>
> When a filesystem is mounted from a loop device, writes are
> throttled by balance_dirty_pages() twice: once when writing
> to the filesystem and once when the loop_handle_cmd() writes
> to the backing file.  This double-throttling can trigger
> positive feedback loops that create significant delays.  The
> throttling at the lower level is seen by the upper level as
> a slow device, so it throttles extra hard.
>
> The PF_LESS_THROTTLE flag was created to handle exactly this
> circumstance, though with an NFS filesystem mounted from a
> local NFS server.  It reduces the throttling on the lower
> layer so that it can proceed largely unthrottled.
>
> To demonstrate this, create a filesystem on a loop device
> and write (e.g. with dd) several large files which combine
> to consume significantly more than the limit set by
> /proc/sys/vm/dirty_ratio or dirty_bytes.  Measure the total
> time taken.
>
> When I do this directly on a device (no loop device) the
> total time for several runs (mkfs, mount, write 200 files,
> umount) is fairly stable: 28-35 seconds.
> When I do this over a loop device the times are much worse
> and less stable.  52-460 seconds.  Half below 100seconds,
> half above.
> When I apply this patch, the times become stable again,
> though not as fast as the no-loop-back case: 53-72 seconds.
>
> There may be room for further improvement as the total overhead still
> seems too high, but this is a big improvement.
>
> Reviewed-by: Christoph Hellwig 
> Acked-by: Michal Hocko 
> Signed-off-by: NeilBrown 

Reviewed-by: Ming Lei 

> ---
>
> I moved where the flag is set, thanks to suggestion from
> Ming Lei.
> I've preserved the *-by: tags I was offered despite the code
> being different, as the concept is identical.
>
> Thanks,
> NeilBrown
>
>
>  drivers/block/loop.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index 0ecb6461ed81..44b3506fd086 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -852,6 +852,7 @@ static int loop_prepare_queue(struct loop_device *lo)
> if (IS_ERR(lo->worker_task))
> return -ENOMEM;
> set_user_nice(lo->worker_task, MIN_NICE);
> +   lo->worker_task->flags |= PF_LESS_THROTTLE;
> return 0;
>  }
>
> --
> 2.12.2
>

ia64 exceptions (Re: [RFC][CFT][PATCHSET v1] uaccess unification)

[Al Viro]

On Wed, Mar 29, 2017 at 06:57:06AM +0100, Al Viro wrote:

> And again, metag and ia64 parts are simply not there - both architectures
> zero-pad in __copy_from_user_inatomic() and that really needs fixing.
> In case of metag there's __copy_to_user() breakage as well, AFAICS, and
> I've been unable to find any documentation describing the architecture
> wrt exceptions, and that part is apparently fairly weird.  In case of
> ia64...  I can test mckinley side of things, but not the generic __copy_user()
> and ia64 is about as weird as it gets.  With no reliable emulator, at that...
> So these two are up to respective maintainers.

Speaking of ia64: copy_user.S contains the following oddity:
2:
EX(.failure_in3,(p16) ld8 val1[0]=[src1],16)
(p16)   ld8 val2[0]=[src2],16

src1 is 16-byte aligned, src2 is src1 + 8.

What guarantees that we can't race with e.g. TLB shootdown from a thread on
another CPU, ending up with the second insn taking a fault and oopsing?

AFAICS, other places where we have such pairs of loads or stores (e.g.
EX(.ex_handler, (p16)   ld8 r34=[src0],16)
EK(.ex_handler, (p16)   ld8 r38=[src1],16)
in the memcpy_mck.S counterpart of that code) both have exception table
entries associated with them.

Is that one intentional and correct for some subtle reason, or is it a very
narrow race on the hardware nobody gives a damn anymore?  It is pre-mckinley
stuff, after all...

Re: [PATCH v2] loop: Add PF_LESS_THROTTLE to block/loop device thread.

[Ming Lei]

On Wed, Apr 5, 2017 at 12:33 PM, NeilBrown  wrote:
>
> When a filesystem is mounted from a loop device, writes are
> throttled by balance_dirty_pages() twice: once when writing
> to the filesystem and once when the loop_handle_cmd() writes
> to the backing file.  This double-throttling can trigger
> positive feedback loops that create significant delays.  The
> throttling at the lower level is seen by the upper level as
> a slow device, so it throttles extra hard.
>
> The PF_LESS_THROTTLE flag was created to handle exactly this
> circumstance, though with an NFS filesystem mounted from a
> local NFS server.  It reduces the throttling on the lower
> layer so that it can proceed largely unthrottled.
>
> To demonstrate this, create a filesystem on a loop device
> and write (e.g. with dd) several large files which combine
> to consume significantly more than the limit set by
> /proc/sys/vm/dirty_ratio or dirty_bytes.  Measure the total
> time taken.
>
> When I do this directly on a device (no loop device) the
> total time for several runs (mkfs, mount, write 200 files,
> umount) is fairly stable: 28-35 seconds.
> When I do this over a loop device the times are much worse
> and less stable.  52-460 seconds.  Half below 100seconds,
> half above.
> When I apply this patch, the times become stable again,
> though not as fast as the no-loop-back case: 53-72 seconds.
>
> There may be room for further improvement as the total overhead still
> seems too high, but this is a big improvement.
>
> Reviewed-by: Christoph Hellwig 
> Acked-by: Michal Hocko 
> Signed-off-by: NeilBrown 

Reviewed-by: Ming Lei 

> ---
>
> I moved where the flag is set, thanks to suggestion from
> Ming Lei.
> I've preserved the *-by: tags I was offered despite the code
> being different, as the concept is identical.
>
> Thanks,
> NeilBrown
>
>
>  drivers/block/loop.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index 0ecb6461ed81..44b3506fd086 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -852,6 +852,7 @@ static int loop_prepare_queue(struct loop_device *lo)
> if (IS_ERR(lo->worker_task))
> return -ENOMEM;
> set_user_nice(lo->worker_task, MIN_NICE);
> +   lo->worker_task->flags |= PF_LESS_THROTTLE;
> return 0;
>  }
>
> --
> 2.12.2
>

ia64 exceptions (Re: [RFC][CFT][PATCHSET v1] uaccess unification)

[Al Viro]

On Wed, Mar 29, 2017 at 06:57:06AM +0100, Al Viro wrote:

> And again, metag and ia64 parts are simply not there - both architectures
> zero-pad in __copy_from_user_inatomic() and that really needs fixing.
> In case of metag there's __copy_to_user() breakage as well, AFAICS, and
> I've been unable to find any documentation describing the architecture
> wrt exceptions, and that part is apparently fairly weird.  In case of
> ia64...  I can test mckinley side of things, but not the generic __copy_user()
> and ia64 is about as weird as it gets.  With no reliable emulator, at that...
> So these two are up to respective maintainers.

Speaking of ia64: copy_user.S contains the following oddity:
2:
EX(.failure_in3,(p16) ld8 val1[0]=[src1],16)
(p16)   ld8 val2[0]=[src2],16

src1 is 16-byte aligned, src2 is src1 + 8.

What guarantees that we can't race with e.g. TLB shootdown from a thread on
another CPU, ending up with the second insn taking a fault and oopsing?

AFAICS, other places where we have such pairs of loads or stores (e.g.
EX(.ex_handler, (p16)   ld8 r34=[src0],16)
EK(.ex_handler, (p16)   ld8 r38=[src1],16)
in the memcpy_mck.S counterpart of that code) both have exception table
entries associated with them.

Is that one intentional and correct for some subtle reason, or is it a very
narrow race on the hardware nobody gives a damn anymore?  It is pre-mckinley
stuff, after all...

RE: [STABLE REGRESSION] iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3

[Song, Hongyan]

Hi Ritesh,
I do not have the environment so should not have a try but I think 
Srinivas's patch should be Ok for your platform.
Please have a try.

Thanks a lot!


BR
Song Hongyan

-Original Message-
From: Ritesh Raj Sarraf [mailto:r...@researchut.com] 
Sent: Tuesday, April 4, 2017 3:14 AM
To: Srinivas Pandruvada ; Song, Hongyan 
; linux-iio 
Cc: sta...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [STABLE REGRESSION] iio: hid-sensor-trigger: Change get poll value 
function order to avoid sensor properties losing after resume from S3

Adding Stable, LKML and IIO MLs.

Hello Hongyan,

Do you have any feedback ? With the bisected commit reverted, I've been 
successfully running the machine without any issues.

Ritesh


On Sat, 2017-04-01 at 08:14 -0700, Srinivas Pandruvada wrote:
> Hello Hongyan,
> 
> Can you check the findings of Ritesh?
> 
> Thanks,
> Srinivas
> 
> On Sat, 2017-04-01 at 14:07 +0530, Ritesh Raj Sarraf wrote:
> > Hello Srinivas,
> > 
> > With the Linux 4.10.7 release, I have encountered a regression 
> > introduced on my Lenovo Yoga 2 13, for the ITE Rotation Sensor.
> > 
> > 
> > rrs@learner:~$ lsusb
> > Bus 001 Device 002: ID 8087:8000 Intel Corp. Bus 001 Device 001: ID 
> > 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 
> > 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 006: ID 
> > 048d:8350 Integrated Technology Express, Inc.
> > Bus 002 Device 005: ID 0bda:b728 Realtek Semiconductor Corp. Bus 002 
> > Device 004: ID 04f2:b40f Chicony Electronics Co., Ltd Bus 002 Device 
> > 003: ID 04f3:0303 Elan Microelectronics Corp.
> > Bus 002 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 
> > Card Reader Controller Bus 002 Device 001: ID 1d6b:0002 Linux 
> > Foundation 2.0 root hub
> > 2017-04-01 / 14:04:49 ♒♒♒  ☺
> > 
> > 
> > The ITE sensors do not feed any data on the 4.10.7 kernel. Reverting
> > back to
> > 4.10.5, everything works back.
> > 
> > 
> > After a git bisect, the culprit reported is:
> > 
> > Bisecting: 0 revisions left to test after this (roughly 0 steps)
> > [6c2aab07d12436af1cd8d9ac1d117a442cc91eec] iio: hid-sensor-trigger:
> > Change get
> > poll value function order to avoid sensor properties losing after
> > resume from S3
> > 1
> > 
> > Can you please review my findings to confirm that it really is a
> > regression bug
> > ?
> > 
> > 
> > Thanks,
> > Ritesh
> > 
-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

RE: [STABLE REGRESSION] iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3

[Song, Hongyan]

Hi Ritesh,
I do not have the environment so should not have a try but I think 
Srinivas's patch should be Ok for your platform.
Please have a try.

Thanks a lot!


BR
Song Hongyan

-Original Message-
From: Ritesh Raj Sarraf [mailto:r...@researchut.com] 
Sent: Tuesday, April 4, 2017 3:14 AM
To: Srinivas Pandruvada ; Song, Hongyan 
; linux-iio 
Cc: sta...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [STABLE REGRESSION] iio: hid-sensor-trigger: Change get poll value 
function order to avoid sensor properties losing after resume from S3

Adding Stable, LKML and IIO MLs.

Hello Hongyan,

Do you have any feedback ? With the bisected commit reverted, I've been 
successfully running the machine without any issues.

Ritesh


On Sat, 2017-04-01 at 08:14 -0700, Srinivas Pandruvada wrote:
> Hello Hongyan,
> 
> Can you check the findings of Ritesh?
> 
> Thanks,
> Srinivas
> 
> On Sat, 2017-04-01 at 14:07 +0530, Ritesh Raj Sarraf wrote:
> > Hello Srinivas,
> > 
> > With the Linux 4.10.7 release, I have encountered a regression 
> > introduced on my Lenovo Yoga 2 13, for the ITE Rotation Sensor.
> > 
> > 
> > rrs@learner:~$ lsusb
> > Bus 001 Device 002: ID 8087:8000 Intel Corp. Bus 001 Device 001: ID 
> > 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 
> > 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 006: ID 
> > 048d:8350 Integrated Technology Express, Inc.
> > Bus 002 Device 005: ID 0bda:b728 Realtek Semiconductor Corp. Bus 002 
> > Device 004: ID 04f2:b40f Chicony Electronics Co., Ltd Bus 002 Device 
> > 003: ID 04f3:0303 Elan Microelectronics Corp.
> > Bus 002 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 
> > Card Reader Controller Bus 002 Device 001: ID 1d6b:0002 Linux 
> > Foundation 2.0 root hub
> > 2017-04-01 / 14:04:49 ♒♒♒  ☺
> > 
> > 
> > The ITE sensors do not feed any data on the 4.10.7 kernel. Reverting
> > back to
> > 4.10.5, everything works back.
> > 
> > 
> > After a git bisect, the culprit reported is:
> > 
> > Bisecting: 0 revisions left to test after this (roughly 0 steps)
> > [6c2aab07d12436af1cd8d9ac1d117a442cc91eec] iio: hid-sensor-trigger:
> > Change get
> > poll value function order to avoid sensor properties losing after
> > resume from S3
> > 1
> > 
> > Can you please review my findings to confirm that it really is a
> > regression bug
> > ?
> > 
> > 
> > Thanks,
> > Ritesh
> > 
-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

Re: [PATCH] mmc: core: add mmc-card hardware reset enable support

[Jaehoon Chung]

Hi,

On 04/04/2017 11:16 PM, Richard Leitner wrote:
> Some eMMCs disable their hardware reset line (RST_N) by default. To enable
> it the host must set the corresponding bit in ECSD. An example for such
> a device is the Micron MTFCxGACAANA-4M.
> 
> This patch adds a new mmc-card devicetree property to let the host enable
> this feature during card initialization.
> 
> Signed-off-by: Richard Leitner 
> ---
>  Documentation/devicetree/bindings/mmc/mmc-card.txt |  3 +++
>  drivers/mmc/core/mmc.c | 21 +
>  2 files changed, 24 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.txt 
> b/Documentation/devicetree/bindings/mmc/mmc-card.txt
> index a70fcd6..8590a40 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc-card.txt
> +++ b/Documentation/devicetree/bindings/mmc/mmc-card.txt
> @@ -12,6 +12,9 @@ Required properties:
>  Optional properties:
>  -broken-hpi : Use this to indicate that the mmc-card has a broken hpi
>implementation, and that hpi should not be used
> +-enable-hw-reset : some eMMC devices have disabled the hw reset functionality
> +   (RST_N_FUNCTION) by default. By adding this property the
> +   host will enable it during initialization.

As i know, RST_N_FUNCTION is controlled bit[1:0]
0x0 : RST_n disabled (by default)
0x1 : permanently enabled
0x2 : permanently disabled

I think that it needs to add the description about these..
>  
>  Example:
>  
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index b502601..518d0e3 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -1520,9 +1520,16 @@ static int mmc_init_card(struct mmc_host *host, u32 
> ocr,
>   int err;
>   u32 cid[4];
>   u32 rocr;
> + struct device_node *np;
> + bool enable_rst_n = false;
>  
>   WARN_ON(!host->claimed);
>  
> + np = mmc_of_find_child_device(host, 0);
> + if (np && of_device_is_compatible(np, "mmc-card"))
> + enable_rst_n = of_property_read_bool(np, "enable-hw-reset");
> + of_node_put(np);
> +
>   /* Set correct bus mode for MMC before attempting init */
>   if (!mmc_host_is_spi(host))
>   mmc_set_bus_mode(host, MMC_BUSMODE_OPENDRAIN);
> @@ -1810,6 +1817,20 @@ static int mmc_init_card(struct mmc_host *host, u32 
> ocr,
>   }
>   }
>  
> + /*
> +  * try to enable RST_N if requested
> +  * This is needed because some eMMC chips disable this function by
> +  * default.
> +  */
> + if (enable_rst_n) {
> + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> +  EXT_CSD_RST_N_FUNCTION, EXT_CSD_RST_N_ENABLED,
> +  card->ext_csd.generic_cmd6_time);
> + if (err && err != -EBADMSG)
> + pr_warn("%s: Enabling RST_N feature failed\n",
> + mmc_hostname(card->host));
> + }

If enabled hw-reset, it doesn't need to re-enable this bit.
i didn't check the mmc-util..
If mmc-util provides the changing this, the using mmc-util is better than this.

Best Regards,
Jaehoon Chung

> +
>   if (!oldcard)
>   host->card = card;
>  
> 

Re: [PATCH] mmc: core: add mmc-card hardware reset enable support

[Jaehoon Chung]

Hi,

On 04/04/2017 11:16 PM, Richard Leitner wrote:
> Some eMMCs disable their hardware reset line (RST_N) by default. To enable
> it the host must set the corresponding bit in ECSD. An example for such
> a device is the Micron MTFCxGACAANA-4M.
> 
> This patch adds a new mmc-card devicetree property to let the host enable
> this feature during card initialization.
> 
> Signed-off-by: Richard Leitner 
> ---
>  Documentation/devicetree/bindings/mmc/mmc-card.txt |  3 +++
>  drivers/mmc/core/mmc.c | 21 +
>  2 files changed, 24 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.txt 
> b/Documentation/devicetree/bindings/mmc/mmc-card.txt
> index a70fcd6..8590a40 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc-card.txt
> +++ b/Documentation/devicetree/bindings/mmc/mmc-card.txt
> @@ -12,6 +12,9 @@ Required properties:
>  Optional properties:
>  -broken-hpi : Use this to indicate that the mmc-card has a broken hpi
>implementation, and that hpi should not be used
> +-enable-hw-reset : some eMMC devices have disabled the hw reset functionality
> +   (RST_N_FUNCTION) by default. By adding this property the
> +   host will enable it during initialization.

As i know, RST_N_FUNCTION is controlled bit[1:0]
0x0 : RST_n disabled (by default)
0x1 : permanently enabled
0x2 : permanently disabled

I think that it needs to add the description about these..
>  
>  Example:
>  
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index b502601..518d0e3 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -1520,9 +1520,16 @@ static int mmc_init_card(struct mmc_host *host, u32 
> ocr,
>   int err;
>   u32 cid[4];
>   u32 rocr;
> + struct device_node *np;
> + bool enable_rst_n = false;
>  
>   WARN_ON(!host->claimed);
>  
> + np = mmc_of_find_child_device(host, 0);
> + if (np && of_device_is_compatible(np, "mmc-card"))
> + enable_rst_n = of_property_read_bool(np, "enable-hw-reset");
> + of_node_put(np);
> +
>   /* Set correct bus mode for MMC before attempting init */
>   if (!mmc_host_is_spi(host))
>   mmc_set_bus_mode(host, MMC_BUSMODE_OPENDRAIN);
> @@ -1810,6 +1817,20 @@ static int mmc_init_card(struct mmc_host *host, u32 
> ocr,
>   }
>   }
>  
> + /*
> +  * try to enable RST_N if requested
> +  * This is needed because some eMMC chips disable this function by
> +  * default.
> +  */
> + if (enable_rst_n) {
> + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> +  EXT_CSD_RST_N_FUNCTION, EXT_CSD_RST_N_ENABLED,
> +  card->ext_csd.generic_cmd6_time);
> + if (err && err != -EBADMSG)
> + pr_warn("%s: Enabling RST_N feature failed\n",
> + mmc_hostname(card->host));
> + }

If enabled hw-reset, it doesn't need to re-enable this bit.
i didn't check the mmc-util..
If mmc-util provides the changing this, the using mmc-util is better than this.

Best Regards,
Jaehoon Chung

> +
>   if (!oldcard)
>   host->card = card;
>  
> 

Watchdog catches hard CPU lock in 4.8.11

[iwillallways forget1]

 This is on a Dell Latitude D830 with 4GB of RAM.  I am booting kernel
4.8.11 from a live Linux distribution in a USB stick.  The CPU is a
Core 2 Duo T7100 capable of 64-bit kernels but this live Linux kernel
is 32-bit.  The hard drive has Windows 7 and is not involved in this
live Linux system.

Approximately the last five lines on the screen are quoted below.  The
third line wrapped around several times but I'm quoting it as a single
line, which will wrap differently in e-mail.  The third line contains
a misquotation.  The word cpu1*dModules doesn't have an asterisk in
the middle; it has a smiley face in one character cell which I cannot
quote properly.

The LED for NumLock is on but CapsLock and ScrollLock are off, and
there is no visible panic stack trace.

Starting system message bus:  /uar/bin/dbus-uuidgen --ensure ;
/usr/bin/dbus-daemon --system
Starting HAL daemon:  /usr/sbin/hald --daemon=yes
[   47.131508] NMI watchdog: Watchdog detected hard LOCKUP on
cpu1*dModules linked in: snd_hda_codec_hdmi arc4 b43 mac80211 cfg_pc
8250 parport dell_rbtn 8250_base thermal firewire_ohci acpi_cpufreq
tpm_tis tpm_tis_core gpio_ich tpm firewire_core sg wmi snd_hda_intel
ac dell_laptop dell_smbios intel_agp i2c_i801 i2c_smbus i2c_core
snd_hda_codec ssb button snd_hda_core snd_hwdep snd_pcm tg3 intel_gtt
agppart libphy rfkill dcdbas ptp evdev pps_core input_leds hwmon
psmouse battery serio_raw lpc_ich snd_timer snd soundcore
Loading OSS compatibility modules for ALSA
Setting default ALSA mixer settings.

Ctrl+Alt+Delete does not work.  I used the power switch to turn it off
and on again.  After rebooting, the system locked up at this point:

Starting system message bus:  /uar/bin/dbus-uuidgen --ensure ;
/usr/bin/dbus-daemon --system
Starting HAL daemon:  /usr/sbin/hald --daemon=yes

I wonder what happened to the NMI watchdog this time.

It gets stranger.  I pressed the power button but released it when the
next two lines came up.

INIT: Switching to runlevel: 0
INIT: Sending processes the TERM signal

But nothing further.  The LEDs are the same as last time, no evidence
of panic.  A second temporary press of the power button has no further
effect so I have to hold it 4 seconds to power off.

Windows 7 still boots.  A SigmaTel High Definition Codec (vendor 8348
device 76A0) and HDA CX11270 Soft Modem (vendor 1F41 device 2C06) are
attached to High Definition Audio Controller (vendor 8086 device
284B).  The video chip is Nvidia Quadro NVS 140M but I doubt that's
the problem; Linux has already started using the frame buffer well
before getting to the hang.  To the best of my knowledge the TPM chip
has never been used; it is off in the BIOS and not visible in Windows.

The reason for today's experiment is that a colleague reported boot
failing on a Dell Latitude D505.  His failure occurs earlier in the
boot process than mine.  I don't think his gets as far as dbus.

A Dell Latitude E6500 with a Core 2 Duo P8700 boots.

My live Linux system has to work on any PC made since around year
2000.  Does anyone even know if I can just blacklist something in the
kernel command line to get it to boot?

And then...

> Subject: Failure Notice
>
> Sorry, we were unable to deliver your message to the following address.
>
> :
> Remote host said: 553 5.7.1 Hello [183.79.56.187], for your MAIL FROM address
>  policy analysis reported: Your address is not
> liked source for email  [MAIL_FROM]

100% of my e-mail addresses are on ordinary ISPs known for sending
large volumes of legitimate e-mail and moderate volumes of spam.  Why
do you accept bug reports from anyone else?

The sender address on this e-mail is one that I hardly ever check.  It
uses a provider known for sending large volumes of legitimate e-mail
and moderate volumes of spam, but I rarely look at this one.

Watchdog catches hard CPU lock in 4.8.11

[iwillallways forget1]

 This is on a Dell Latitude D830 with 4GB of RAM.  I am booting kernel
4.8.11 from a live Linux distribution in a USB stick.  The CPU is a
Core 2 Duo T7100 capable of 64-bit kernels but this live Linux kernel
is 32-bit.  The hard drive has Windows 7 and is not involved in this
live Linux system.

Approximately the last five lines on the screen are quoted below.  The
third line wrapped around several times but I'm quoting it as a single
line, which will wrap differently in e-mail.  The third line contains
a misquotation.  The word cpu1*dModules doesn't have an asterisk in
the middle; it has a smiley face in one character cell which I cannot
quote properly.

The LED for NumLock is on but CapsLock and ScrollLock are off, and
there is no visible panic stack trace.

Starting system message bus:  /uar/bin/dbus-uuidgen --ensure ;
/usr/bin/dbus-daemon --system
Starting HAL daemon:  /usr/sbin/hald --daemon=yes
[   47.131508] NMI watchdog: Watchdog detected hard LOCKUP on
cpu1*dModules linked in: snd_hda_codec_hdmi arc4 b43 mac80211 cfg_pc
8250 parport dell_rbtn 8250_base thermal firewire_ohci acpi_cpufreq
tpm_tis tpm_tis_core gpio_ich tpm firewire_core sg wmi snd_hda_intel
ac dell_laptop dell_smbios intel_agp i2c_i801 i2c_smbus i2c_core
snd_hda_codec ssb button snd_hda_core snd_hwdep snd_pcm tg3 intel_gtt
agppart libphy rfkill dcdbas ptp evdev pps_core input_leds hwmon
psmouse battery serio_raw lpc_ich snd_timer snd soundcore
Loading OSS compatibility modules for ALSA
Setting default ALSA mixer settings.

Ctrl+Alt+Delete does not work.  I used the power switch to turn it off
and on again.  After rebooting, the system locked up at this point:

Starting system message bus:  /uar/bin/dbus-uuidgen --ensure ;
/usr/bin/dbus-daemon --system
Starting HAL daemon:  /usr/sbin/hald --daemon=yes

I wonder what happened to the NMI watchdog this time.

It gets stranger.  I pressed the power button but released it when the
next two lines came up.

INIT: Switching to runlevel: 0
INIT: Sending processes the TERM signal

But nothing further.  The LEDs are the same as last time, no evidence
of panic.  A second temporary press of the power button has no further
effect so I have to hold it 4 seconds to power off.

Windows 7 still boots.  A SigmaTel High Definition Codec (vendor 8348
device 76A0) and HDA CX11270 Soft Modem (vendor 1F41 device 2C06) are
attached to High Definition Audio Controller (vendor 8086 device
284B).  The video chip is Nvidia Quadro NVS 140M but I doubt that's
the problem; Linux has already started using the frame buffer well
before getting to the hang.  To the best of my knowledge the TPM chip
has never been used; it is off in the BIOS and not visible in Windows.

The reason for today's experiment is that a colleague reported boot
failing on a Dell Latitude D505.  His failure occurs earlier in the
boot process than mine.  I don't think his gets as far as dbus.

A Dell Latitude E6500 with a Core 2 Duo P8700 boots.

My live Linux system has to work on any PC made since around year
2000.  Does anyone even know if I can just blacklist something in the
kernel command line to get it to boot?

And then...

> Subject: Failure Notice
>
> Sorry, we were unable to deliver your message to the following address.
>
> :
> Remote host said: 553 5.7.1 Hello [183.79.56.187], for your MAIL FROM address
>  policy analysis reported: Your address is not
> liked source for email  [MAIL_FROM]

100% of my e-mail addresses are on ordinary ISPs known for sending
large volumes of legitimate e-mail and moderate volumes of spam.  Why
do you accept bug reports from anyone else?

The sender address on this e-mail is one that I hardly ever check.  It
uses a provider known for sending large volumes of legitimate e-mail
and moderate volumes of spam, but I rarely look at this one.

[PATCH v2] loop: Add PF_LESS_THROTTLE to block/loop device thread.

[NeilBrown]

When a filesystem is mounted from a loop device, writes are
throttled by balance_dirty_pages() twice: once when writing
to the filesystem and once when the loop_handle_cmd() writes
to the backing file.  This double-throttling can trigger
positive feedback loops that create significant delays.  The
throttling at the lower level is seen by the upper level as
a slow device, so it throttles extra hard.

The PF_LESS_THROTTLE flag was created to handle exactly this
circumstance, though with an NFS filesystem mounted from a
local NFS server.  It reduces the throttling on the lower
layer so that it can proceed largely unthrottled.

To demonstrate this, create a filesystem on a loop device
and write (e.g. with dd) several large files which combine
to consume significantly more than the limit set by
/proc/sys/vm/dirty_ratio or dirty_bytes.  Measure the total
time taken.

When I do this directly on a device (no loop device) the
total time for several runs (mkfs, mount, write 200 files,
umount) is fairly stable: 28-35 seconds.
When I do this over a loop device the times are much worse
and less stable.  52-460 seconds.  Half below 100seconds,
half above.
When I apply this patch, the times become stable again,
though not as fast as the no-loop-back case: 53-72 seconds.

There may be room for further improvement as the total overhead still
seems too high, but this is a big improvement.

Reviewed-by: Christoph Hellwig 
Acked-by: Michal Hocko 
Signed-off-by: NeilBrown 
---

I moved where the flag is set, thanks to suggestion from
Ming Lei.
I've preserved the *-by: tags I was offered despite the code
being different, as the concept is identical.

Thanks,
NeilBrown


 drivers/block/loop.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 0ecb6461ed81..44b3506fd086 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -852,6 +852,7 @@ static int loop_prepare_queue(struct loop_device *lo)
if (IS_ERR(lo->worker_task))
return -ENOMEM;
set_user_nice(lo->worker_task, MIN_NICE);
+   lo->worker_task->flags |= PF_LESS_THROTTLE;
return 0;
 }
 
-- 
2.12.2



signature.asc
Description: PGP signature

[PATCH v2] loop: Add PF_LESS_THROTTLE to block/loop device thread.

[NeilBrown]

When a filesystem is mounted from a loop device, writes are
throttled by balance_dirty_pages() twice: once when writing
to the filesystem and once when the loop_handle_cmd() writes
to the backing file.  This double-throttling can trigger
positive feedback loops that create significant delays.  The
throttling at the lower level is seen by the upper level as
a slow device, so it throttles extra hard.

The PF_LESS_THROTTLE flag was created to handle exactly this
circumstance, though with an NFS filesystem mounted from a
local NFS server.  It reduces the throttling on the lower
layer so that it can proceed largely unthrottled.

To demonstrate this, create a filesystem on a loop device
and write (e.g. with dd) several large files which combine
to consume significantly more than the limit set by
/proc/sys/vm/dirty_ratio or dirty_bytes.  Measure the total
time taken.

When I do this directly on a device (no loop device) the
total time for several runs (mkfs, mount, write 200 files,
umount) is fairly stable: 28-35 seconds.
When I do this over a loop device the times are much worse
and less stable.  52-460 seconds.  Half below 100seconds,
half above.
When I apply this patch, the times become stable again,
though not as fast as the no-loop-back case: 53-72 seconds.

There may be room for further improvement as the total overhead still
seems too high, but this is a big improvement.

Reviewed-by: Christoph Hellwig 
Acked-by: Michal Hocko 
Signed-off-by: NeilBrown 
---

I moved where the flag is set, thanks to suggestion from
Ming Lei.
I've preserved the *-by: tags I was offered despite the code
being different, as the concept is identical.

Thanks,
NeilBrown


 drivers/block/loop.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 0ecb6461ed81..44b3506fd086 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -852,6 +852,7 @@ static int loop_prepare_queue(struct loop_device *lo)
if (IS_ERR(lo->worker_task))
return -ENOMEM;
set_user_nice(lo->worker_task, MIN_NICE);
+   lo->worker_task->flags |= PF_LESS_THROTTLE;
return 0;
 }
 
-- 
2.12.2



signature.asc
Description: PGP signature

Re: [PATCH] loop: Add PF_LESS_THROTTLE to block/loop device thread.

[NeilBrown]

On Tue, Apr 04 2017, Ming Lei wrote:

> On Mon, Apr 3, 2017 at 9:18 AM, NeilBrown  wrote:
>>
>> When a filesystem is mounted from a loop device, writes are
>> throttled by balance_dirty_pages() twice: once when writing
>> to the filesystem and once when the loop_handle_cmd() writes
>> to the backing file.  This double-throttling can trigger
>> positive feedback loops that create significant delays.  The
>> throttling at the lower level is seen by the upper level as
>> a slow device, so it throttles extra hard.
>>
>> The PF_LESS_THROTTLE flag was created to handle exactly this
>> circumstance, though with an NFS filesystem mounted from a
>> local NFS server.  It reduces the throttling on the lower
>> layer so that it can proceed largely unthrottled.
>>
>> To demonstrate this, create a filesystem on a loop device
>> and write (e.g. with dd) several large files which combine
>> to consume significantly more than the limit set by
>> /proc/sys/vm/dirty_ratio or dirty_bytes.  Measure the total
>> time taken.
>>
>> When I do this directly on a device (no loop device) the
>> total time for several runs (mkfs, mount, write 200 files,
>> umount) is fairly stable: 28-35 seconds.
>> When I do this over a loop device the times are much worse
>> and less stable.  52-460 seconds.  Half below 100seconds,
>> half above.
>> When I apply this patch, the times become stable again,
>> though not as fast as the no-loop-back case: 53-72 seconds.
>>
>> There may be room for further improvement as the total overhead still
>> seems too high, but this is a big improvement.
>>
>> Signed-off-by: NeilBrown 
>> ---
>>  drivers/block/loop.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
>> index 0ecb6461ed81..a7e1dd215fc2 100644
>> --- a/drivers/block/loop.c
>> +++ b/drivers/block/loop.c
>> @@ -1694,8 +1694,11 @@ static void loop_queue_work(struct kthread_work *work)
>>  {
>> struct loop_cmd *cmd =
>> container_of(work, struct loop_cmd, work);
>> +   int oldflags = current->flags & PF_LESS_THROTTLE;
>>
>> +   current->flags |= PF_LESS_THROTTLE;
>> loop_handle_cmd(cmd);
>> +   current->flags = (current->flags & ~PF_LESS_THROTTLE) | oldflags;
>>  }
>
> You can do it against 'lo->worker_task' instead of doing it in each
> loop_queue_work(),
> and this flag needn't to be restored because the kernel thread is loop
> specialized.
>

good point.  I'll do that.  Thanks,
NeilBrown


signature.asc
Description: PGP signature

RE: [PATCH kernel v8 2/4] virtio-balloon: VIRTIO_BALLOON_F_CHUNK_TRANSFER

[Wang, Wei W]

On Wednesday, April 5, 2017 11:54 AM, Michael S. Tsirkin wrote:
> On Wed, Apr 05, 2017 at 03:31:36AM +, Wang, Wei W wrote:
> > On Thursday, March 16, 2017 3:09 PM Wei Wang wrote:
> > > The implementation of the current virtio-balloon is not very
> > > efficient, because the ballooned pages are transferred to the host
> > > one by one. Here is the breakdown of the time in percentage spent on
> > > each step of the balloon inflating process (inflating 7GB of an 8GB idle 
> > > guest).
> > >
> > > 1) allocating pages (6.5%)
> > > 2) sending PFNs to host (68.3%)
> > > 3) address translation (6.1%)
> > > 4) madvise (19%)
> > >
> > > It takes about 4126ms for the inflating process to complete.
> > > The above profiling shows that the bottlenecks are stage 2) and stage 4).
> > >
> > > This patch optimizes step 2) by transferring pages to the host in
> > > chunks. A chunk consists of guest physically continuous pages, and
> > > it is offered to the host via a base PFN (i.e. the start PFN of
> > > those physically continuous pages) and the size (i.e. the total number of 
> > > the
> pages). A chunk is formated as below:
> > >
> > > 
> > > | Base (52 bit)| Rsvd (12 bit) |
> > > 
> > > 
> > > | Size (52 bit)| Rsvd (12 bit) |
> > > 
> > >
> > > By doing so, step 4) can also be optimized by doing address
> > > translation and
> > > madvise() in chunks rather than page by page.
> > >
> > > This optimization requires the negotiation of a new feature bit,
> > > VIRTIO_BALLOON_F_CHUNK_TRANSFER.
> > >
> > > With this new feature, the above ballooning process takes ~590ms
> > > resulting in an improvement of ~85%.
> > >
> > > TODO: optimize stage 1) by allocating/freeing a chunk of pages
> > > instead of a single page each time.
> > >
> > > Signed-off-by: Liang Li 
> > > Signed-off-by: Wei Wang 
> > > Suggested-by: Michael S. Tsirkin 
> > > ---
> > >  drivers/virtio/virtio_balloon.c | 371
> +-
> > > --
> > >  include/uapi/linux/virtio_balloon.h |   9 +
> > >  2 files changed, 353 insertions(+), 27 deletions(-)
> > >
> > > diff --git a/drivers/virtio/virtio_balloon.c
> > > b/drivers/virtio/virtio_balloon.c index
> > > f59cb4f..3f4a161 100644
> > > --- a/drivers/virtio/virtio_balloon.c
> > > +++ b/drivers/virtio/virtio_balloon.c
> > > @@ -42,6 +42,10 @@
> > >  #define OOM_VBALLOON_DEFAULT_PAGES 256  #define
> > > VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
> > >
> > > +#define PAGE_BMAP_SIZE   (8 * PAGE_SIZE)
> > > +#define PFNS_PER_PAGE_BMAP   (PAGE_BMAP_SIZE * BITS_PER_BYTE)
> > > +#define PAGE_BMAP_COUNT_MAX  32
> > > +
> > >  static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
> > > module_param(oom_pages, int, S_IRUSR | S_IWUSR);
> > > MODULE_PARM_DESC(oom_pages, "pages to free on OOM"); @@ -50,6
> +54,14
> > > @@ MODULE_PARM_DESC(oom_pages, "pages to free on OOM");  static
> > > struct vfsmount *balloon_mnt;  #endif
> > >
> > > +#define BALLOON_CHUNK_BASE_SHIFT 12 #define
> > > +BALLOON_CHUNK_SIZE_SHIFT 12 struct balloon_page_chunk {
> > > + __le64 base;
> > > + __le64 size;
> > > +};
> > > +
> > > +typedef __le64 resp_data_t;
> > >  struct virtio_balloon {
> > >   struct virtio_device *vdev;
> > >   struct virtqueue *inflate_vq, *deflate_vq, *stats_vq; @@ -67,6
> > > +79,31 @@ struct virtio_balloon {
> > >
> > >   /* Number of balloon pages we've told the Host we're not using. */
> > >   unsigned int num_pages;
> > > + /* Pointer to the response header. */
> > > + struct virtio_balloon_resp_hdr *resp_hdr;
> > > + /* Pointer to the start address of response data. */
> > > + resp_data_t *resp_data;
> >
> > I think the implementation has an issue here - both the balloon pages and 
> > the
> unused pages use the same buffer ("resp_data" above) to store chunks. It would
> cause a race in this case: live migration starts while ballooning is also in 
> progress.
> I plan to use separate buffers for CHUNKS_OF_BALLOON_PAGES and
> CHUNKS_OF_UNUSED_PAGES. Please let me know if you have a different
> suggestion. Thanks.
> >
> > Best,
> > Wei
> 
> Is only one resp data ever in flight for each kind?
> If not you want as many buffers as vq allows.
> 

No, all the kinds were using only one resp_data. I will make it one resp_data 
for each kind.

Best,
Wei

Re: [PATCH] loop: Add PF_LESS_THROTTLE to block/loop device thread.

[NeilBrown]

On Tue, Apr 04 2017, Ming Lei wrote:

> On Mon, Apr 3, 2017 at 9:18 AM, NeilBrown  wrote:
>>
>> When a filesystem is mounted from a loop device, writes are
>> throttled by balance_dirty_pages() twice: once when writing
>> to the filesystem and once when the loop_handle_cmd() writes
>> to the backing file.  This double-throttling can trigger
>> positive feedback loops that create significant delays.  The
>> throttling at the lower level is seen by the upper level as
>> a slow device, so it throttles extra hard.
>>
>> The PF_LESS_THROTTLE flag was created to handle exactly this
>> circumstance, though with an NFS filesystem mounted from a
>> local NFS server.  It reduces the throttling on the lower
>> layer so that it can proceed largely unthrottled.
>>
>> To demonstrate this, create a filesystem on a loop device
>> and write (e.g. with dd) several large files which combine
>> to consume significantly more than the limit set by
>> /proc/sys/vm/dirty_ratio or dirty_bytes.  Measure the total
>> time taken.
>>
>> When I do this directly on a device (no loop device) the
>> total time for several runs (mkfs, mount, write 200 files,
>> umount) is fairly stable: 28-35 seconds.
>> When I do this over a loop device the times are much worse
>> and less stable.  52-460 seconds.  Half below 100seconds,
>> half above.
>> When I apply this patch, the times become stable again,
>> though not as fast as the no-loop-back case: 53-72 seconds.
>>
>> There may be room for further improvement as the total overhead still
>> seems too high, but this is a big improvement.
>>
>> Signed-off-by: NeilBrown 
>> ---
>>  drivers/block/loop.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
>> index 0ecb6461ed81..a7e1dd215fc2 100644
>> --- a/drivers/block/loop.c
>> +++ b/drivers/block/loop.c
>> @@ -1694,8 +1694,11 @@ static void loop_queue_work(struct kthread_work *work)
>>  {
>> struct loop_cmd *cmd =
>> container_of(work, struct loop_cmd, work);
>> +   int oldflags = current->flags & PF_LESS_THROTTLE;
>>
>> +   current->flags |= PF_LESS_THROTTLE;
>> loop_handle_cmd(cmd);
>> +   current->flags = (current->flags & ~PF_LESS_THROTTLE) | oldflags;
>>  }
>
> You can do it against 'lo->worker_task' instead of doing it in each
> loop_queue_work(),
> and this flag needn't to be restored because the kernel thread is loop
> specialized.
>

good point.  I'll do that.  Thanks,
NeilBrown


signature.asc
Description: PGP signature

RE: [PATCH kernel v8 2/4] virtio-balloon: VIRTIO_BALLOON_F_CHUNK_TRANSFER

[Wang, Wei W]

On Wednesday, April 5, 2017 11:54 AM, Michael S. Tsirkin wrote:
> On Wed, Apr 05, 2017 at 03:31:36AM +, Wang, Wei W wrote:
> > On Thursday, March 16, 2017 3:09 PM Wei Wang wrote:
> > > The implementation of the current virtio-balloon is not very
> > > efficient, because the ballooned pages are transferred to the host
> > > one by one. Here is the breakdown of the time in percentage spent on
> > > each step of the balloon inflating process (inflating 7GB of an 8GB idle 
> > > guest).
> > >
> > > 1) allocating pages (6.5%)
> > > 2) sending PFNs to host (68.3%)
> > > 3) address translation (6.1%)
> > > 4) madvise (19%)
> > >
> > > It takes about 4126ms for the inflating process to complete.
> > > The above profiling shows that the bottlenecks are stage 2) and stage 4).
> > >
> > > This patch optimizes step 2) by transferring pages to the host in
> > > chunks. A chunk consists of guest physically continuous pages, and
> > > it is offered to the host via a base PFN (i.e. the start PFN of
> > > those physically continuous pages) and the size (i.e. the total number of 
> > > the
> pages). A chunk is formated as below:
> > >
> > > 
> > > | Base (52 bit)| Rsvd (12 bit) |
> > > 
> > > 
> > > | Size (52 bit)| Rsvd (12 bit) |
> > > 
> > >
> > > By doing so, step 4) can also be optimized by doing address
> > > translation and
> > > madvise() in chunks rather than page by page.
> > >
> > > This optimization requires the negotiation of a new feature bit,
> > > VIRTIO_BALLOON_F_CHUNK_TRANSFER.
> > >
> > > With this new feature, the above ballooning process takes ~590ms
> > > resulting in an improvement of ~85%.
> > >
> > > TODO: optimize stage 1) by allocating/freeing a chunk of pages
> > > instead of a single page each time.
> > >
> > > Signed-off-by: Liang Li 
> > > Signed-off-by: Wei Wang 
> > > Suggested-by: Michael S. Tsirkin 
> > > ---
> > >  drivers/virtio/virtio_balloon.c | 371
> +-
> > > --
> > >  include/uapi/linux/virtio_balloon.h |   9 +
> > >  2 files changed, 353 insertions(+), 27 deletions(-)
> > >
> > > diff --git a/drivers/virtio/virtio_balloon.c
> > > b/drivers/virtio/virtio_balloon.c index
> > > f59cb4f..3f4a161 100644
> > > --- a/drivers/virtio/virtio_balloon.c
> > > +++ b/drivers/virtio/virtio_balloon.c
> > > @@ -42,6 +42,10 @@
> > >  #define OOM_VBALLOON_DEFAULT_PAGES 256  #define
> > > VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
> > >
> > > +#define PAGE_BMAP_SIZE   (8 * PAGE_SIZE)
> > > +#define PFNS_PER_PAGE_BMAP   (PAGE_BMAP_SIZE * BITS_PER_BYTE)
> > > +#define PAGE_BMAP_COUNT_MAX  32
> > > +
> > >  static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
> > > module_param(oom_pages, int, S_IRUSR | S_IWUSR);
> > > MODULE_PARM_DESC(oom_pages, "pages to free on OOM"); @@ -50,6
> +54,14
> > > @@ MODULE_PARM_DESC(oom_pages, "pages to free on OOM");  static
> > > struct vfsmount *balloon_mnt;  #endif
> > >
> > > +#define BALLOON_CHUNK_BASE_SHIFT 12 #define
> > > +BALLOON_CHUNK_SIZE_SHIFT 12 struct balloon_page_chunk {
> > > + __le64 base;
> > > + __le64 size;
> > > +};
> > > +
> > > +typedef __le64 resp_data_t;
> > >  struct virtio_balloon {
> > >   struct virtio_device *vdev;
> > >   struct virtqueue *inflate_vq, *deflate_vq, *stats_vq; @@ -67,6
> > > +79,31 @@ struct virtio_balloon {
> > >
> > >   /* Number of balloon pages we've told the Host we're not using. */
> > >   unsigned int num_pages;
> > > + /* Pointer to the response header. */
> > > + struct virtio_balloon_resp_hdr *resp_hdr;
> > > + /* Pointer to the start address of response data. */
> > > + resp_data_t *resp_data;
> >
> > I think the implementation has an issue here - both the balloon pages and 
> > the
> unused pages use the same buffer ("resp_data" above) to store chunks. It would
> cause a race in this case: live migration starts while ballooning is also in 
> progress.
> I plan to use separate buffers for CHUNKS_OF_BALLOON_PAGES and
> CHUNKS_OF_UNUSED_PAGES. Please let me know if you have a different
> suggestion. Thanks.
> >
> > Best,
> > Wei
> 
> Is only one resp data ever in flight for each kind?
> If not you want as many buffers as vq allows.
> 

No, all the kinds were using only one resp_data. I will make it one resp_data 
for each kind.

Best,
Wei

Re: [PATCH] loop: Add PF_LESS_THROTTLE to block/loop device thread.

[NeilBrown]

On Tue, Apr 04 2017, Christoph Hellwig wrote:

> Looks fine,
>
> Reviewed-by: Christoph Hellwig 
>
> But if you actually care about performance in any way I'd suggest
> to use the loop device in direct I/O mode..

The losetup on my test VM is too old to support that :-(
I guess it might be time to upgraded.

It seems that there is not "mount -o direct_loop" or similar, so you
have to do the losetup and the mount separately.  Any thoughts on
whether that should be changed ?

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH] loop: Add PF_LESS_THROTTLE to block/loop device thread.

[NeilBrown]

On Tue, Apr 04 2017, Christoph Hellwig wrote:

> Looks fine,
>
> Reviewed-by: Christoph Hellwig 
>
> But if you actually care about performance in any way I'd suggest
> to use the loop device in direct I/O mode..

The losetup on my test VM is too old to support that :-(
I guess it might be time to upgraded.

It seems that there is not "mount -o direct_loop" or similar, so you
have to do the losetup and the mount separately.  Any thoughts on
whether that should be changed ?

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

[Mike Galbraith]

On Wed, 2017-04-05 at 06:51 +0300, Michael S. Tsirkin wrote:

> Any issues at all left with this tree?
> In particular any regressions?

Nothing blatantly obvious in a testdrive that lasted a couple minutes. 
 I'd have to beat on it a bit to look for things beyond the reported,
but can't afford to do that right now.

-Mike

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

[Mike Galbraith]

On Wed, 2017-04-05 at 06:51 +0300, Michael S. Tsirkin wrote:

> Any issues at all left with this tree?
> In particular any regressions?

Nothing blatantly obvious in a testdrive that lasted a couple minutes. 
 I'd have to beat on it a bit to look for things beyond the reported,
but can't afford to do that right now.

-Mike

Re: [PATCH v6 01/11] powerpc/powernv: Data structure and macros definitions

[Madhavan Srinivasan]

On Tuesday 04 April 2017 07:18 AM, Daniel Axtens wrote:

Hi,


+#define IMC_MAX_CHIPS  32
+#define IMC_MAX_PMUS   32
+#define IMC_MAX_PMU_NAME_LEN   256

I've noticed this is used as both the maximum length for event names and
event value strings. Would another name suit better?


This is used in the value string length comparison also. So yes, will
change the name to suit better.

Thanks for review
Maddy




+
+#define IMC_NEST_MAX_PAGES 16
+
+#define IMC_DTB_COMPAT "ibm,opal-in-memory-counters"
+#define IMC_DTB_NEST_COMPAT"ibm,imc-counters-nest"
+
+/*
+ * Structure to hold per chip specific memory address
+ * information for nest pmus. Nest Counter data are exported
+ * in per-chip reserved memory region by the PORE Engine.
+ */
+struct perchip_nest_info {
+   u32 chip_id;
+   u64 pbase;
+   u64 vbase[IMC_NEST_MAX_PAGES];
+   u64 size;
+};
+
+/*
+ * Place holder for nest pmu events and values.
+ */
+struct imc_events {
+   char *ev_name;
+   char *ev_value;
+};
+
+/*
+ * Device tree parser code detects IMC pmu support and
+ * registers new IMC pmus. This structure will
+ * hold the pmu functions and attrs for each imc pmu and
+ * will be referenced at the time of pmu registration.
+ */
+struct imc_pmu {
+   struct pmu pmu;
+   int domain;
+   const struct attribute_group *attr_groups[4];
+};
+
+/*
+ * Domains for IMC PMUs
+ */
+#define IMC_DOMAIN_NEST1
+#define IMC_DOMAIN_UNKNOWN -1
+
+#endif /* PPC_POWERNV_IMC_PMU_DEF_H */
--
2.7.4

Re: [PATCH v6 01/11] powerpc/powernv: Data structure and macros definitions

[Madhavan Srinivasan]

On Tuesday 04 April 2017 07:18 AM, Daniel Axtens wrote:

Hi,


+#define IMC_MAX_CHIPS  32
+#define IMC_MAX_PMUS   32
+#define IMC_MAX_PMU_NAME_LEN   256

I've noticed this is used as both the maximum length for event names and
event value strings. Would another name suit better?


This is used in the value string length comparison also. So yes, will
change the name to suit better.

Thanks for review
Maddy




+
+#define IMC_NEST_MAX_PAGES 16
+
+#define IMC_DTB_COMPAT "ibm,opal-in-memory-counters"
+#define IMC_DTB_NEST_COMPAT"ibm,imc-counters-nest"
+
+/*
+ * Structure to hold per chip specific memory address
+ * information for nest pmus. Nest Counter data are exported
+ * in per-chip reserved memory region by the PORE Engine.
+ */
+struct perchip_nest_info {
+   u32 chip_id;
+   u64 pbase;
+   u64 vbase[IMC_NEST_MAX_PAGES];
+   u64 size;
+};
+
+/*
+ * Place holder for nest pmu events and values.
+ */
+struct imc_events {
+   char *ev_name;
+   char *ev_value;
+};
+
+/*
+ * Device tree parser code detects IMC pmu support and
+ * registers new IMC pmus. This structure will
+ * hold the pmu functions and attrs for each imc pmu and
+ * will be referenced at the time of pmu registration.
+ */
+struct imc_pmu {
+   struct pmu pmu;
+   int domain;
+   const struct attribute_group *attr_groups[4];
+};
+
+/*
+ * Domains for IMC PMUs
+ */
+#define IMC_DOMAIN_NEST1
+#define IMC_DOMAIN_UNKNOWN -1
+
+#endif /* PPC_POWERNV_IMC_PMU_DEF_H */
--
2.7.4

Re: pull-request: wireless-drivers-next 2017-04-03

[Kalle Valo]

David Miller  writes:

> From: Kalle Valo 
> Date: Tue, 04 Apr 2017 20:48:35 +0300
>
>> David Miller  writes:
>> 
>>> From: Kalle Valo 
>>> Date: Mon, 03 Apr 2017 14:26:10 +0300
>>>
 here few really small fixes. I'm hoping this to be the last pull request
 for 4.11.
 
 Please let me if there are any problems.
>>>
>>> Pulled, thanks.
>>>
>>> But I will warn you, you say fixes, but your Subject line and
>>> GIT tag says "-next" so I pulled it into net-next.
>> 
>> Sorry, I used the wrong pull request template and that's why I had the
>> wrong subject in this pull request. So actually this was supposed to be
>> for net, not net-next. Any chance you could also pull this to net so
>> that we can still get the fixes to 4.11?
>
> Sure, done.

Great, thank you. And sorry for this, I need to be more careful when
sending the pull requests.

-- 
Kalle Valo

Re: pull-request: wireless-drivers-next 2017-04-03

[Kalle Valo]

David Miller  writes:

> From: Kalle Valo 
> Date: Tue, 04 Apr 2017 20:48:35 +0300
>
>> David Miller  writes:
>> 
>>> From: Kalle Valo 
>>> Date: Mon, 03 Apr 2017 14:26:10 +0300
>>>
 here few really small fixes. I'm hoping this to be the last pull request
 for 4.11.
 
 Please let me if there are any problems.
>>>
>>> Pulled, thanks.
>>>
>>> But I will warn you, you say fixes, but your Subject line and
>>> GIT tag says "-next" so I pulled it into net-next.
>> 
>> Sorry, I used the wrong pull request template and that's why I had the
>> wrong subject in this pull request. So actually this was supposed to be
>> for net, not net-next. Any chance you could also pull this to net so
>> that we can still get the fixes to 4.11?
>
> Sure, done.

Great, thank you. And sorry for this, I need to be more careful when
sending the pull requests.

-- 
Kalle Valo

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

[Richard Guy Briggs]

On 2017-04-04 17:19, Paul Moore wrote:
> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs  wrote:
> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > records to be associated with the init_module and finit_module SYSCALL
> > records on a few modules when the following rule was in place for
> > startup:
> > -a always,exit -F arch=x86_64 -S init_module -F key=mod-load
> >
> > This happens because the parent inode is not found in the task's
> > audit_names list and hence treats it as anonymous.  This gives us no
> > information other than a numerical device number that may no longer be
> > visible upon log inspeciton, and an inode number.
> >
> > Fill in the filesystem type, filesystem magic number and full pathname
> > from the filesystem mount point on previously null PATH records from
> > entries that have an anonymous parent from the child dentry using
> > dentry_path_raw().
> >
> > Make the dentry argument of __audit_inode_child() non-const so that we
> > can take a reference to it in the case of an anonymous parent with
> > dget() and dget_parent() to be able to later print a partial path from
> > the host filesystem rather than null.
> >
> > Since all we are given is an inode of the parent and the dentry of the
> > child, finding the path from the mount point to the root of the
> > filesystem is more challenging that would involve searching all
> > vfsmounts from "/" until a matching dentry is found for that
> > filesystem's root dentry.  Even if one is found, there may be more than
> > one mount point.  At this point the gain seems marginal since
> > knowing the filesystem type and path are a significant help in tracking
> > down the source of the PATH records and being to address them.
> >
> > Sample output:
> > type=PROCTITLE msg=audit(1488317694.446:143): 
> > proctitle=2F7362696E2F6D6F6470726F6265002D71002D2D006E66737634
> > type=PATH msg=audit(1488317694.446:143): item=797 
> > name=tracefs(74726163):/events/nfs4/nfs4_setclientid/format inode=15969 
> > dev=00:09 mode=0100444 ouid=0 ogid=0 rdev=00:00 
> > obj=system_u:object_r:tracefs_t:s0 nametype=CREATE
> > type=PATH msg=audit(1488317694.446:143): item=796 
> > name=tracefs(74726163):/events/nfs4/nfs4_setclientid inode=15964 dev=00:09 
> > mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 
> > nametype=PARENT
> > ...
> > type=PATH msg=audit(1488317694.446:143): item=1 
> > name=tracefs(74726163):/events/nfs4 inode=15571 dev=00:09 mode=040755 
> > ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=CREATE
> > type=PATH msg=audit(1488317694.446:143): item=0 
> > name=tracefs(74726163):/events inode=119 dev=00:09 mode=040755 ouid=0 
> > ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=PARENT
> > type=UNKNOWN[1330] msg=audit(1488317694.446:143): name="nfsv4"
> > type=SYSCALL msg=audit(1488317694.446:143): arch=c03e syscall=313 
> > success=yes exit=0 a0=1 a1=55d5a35ce106 a2=0 a3=1 items=798 ppid=6 pid=528 
> > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
> > tty=(none) ses=4294967295 comm="modprobe" exe="/usr/bin/kmod" 
> > subj=system_u:system_r:insmod_t:s0 key="mod-load"
> >
> > See: https://github.com/linux-audit/audit-kernel/issues/8
> > Test case: https://github.com/linux-audit/audit-testsuite/issues/42
> >
> > Signed-off-by: Richard Guy Briggs 
> > ---
> >  include/linux/audit.h |8 
> >  kernel/audit.c|   16 
> >  kernel/audit.h|1 +
> >  kernel/auditsc.c  |8 +++-
> >  4 files changed, 28 insertions(+), 5 deletions(-)
> 
> I see the "ALT4" in the subject line which gives me pause; does this
> mean you plan further development for the other potential fixes, or
> did you just include it on this patch for better tracking with it's
> predecessor?

The "ALT4" was included for tracking.  This is the planned path forward,
abandonning the rest of the "ALT*"s.

> I'm basically asking what to expect.  Should I review this for
> inclusion, or wait for other alternatives?

Please review.

> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index aba3a26..367a03a 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -241,7 +241,7 @@ extern void __audit_inode(struct filename *name, const 
> > struct dentry *dentry,
> > unsigned int flags);
> >  extern void __audit_file(const struct file *);
> >  extern void __audit_inode_child(struct inode *parent,
> > -   const struct dentry *dentry,
> > +   struct dentry *dentry,
> > const unsigned char type);
> >  extern void __audit_seccomp(unsigned long syscall, long signr, int code);
> >  extern void __audit_ptrace(struct task_struct *t);
> > @@ -306,7 +306,7 @@ static inline void audit_inode_parent_hidden(struct 
> > filename *name,
> >  

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

[Richard Guy Briggs]

On 2017-04-04 17:19, Paul Moore wrote:
> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs  wrote:
> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > records to be associated with the init_module and finit_module SYSCALL
> > records on a few modules when the following rule was in place for
> > startup:
> > -a always,exit -F arch=x86_64 -S init_module -F key=mod-load
> >
> > This happens because the parent inode is not found in the task's
> > audit_names list and hence treats it as anonymous.  This gives us no
> > information other than a numerical device number that may no longer be
> > visible upon log inspeciton, and an inode number.
> >
> > Fill in the filesystem type, filesystem magic number and full pathname
> > from the filesystem mount point on previously null PATH records from
> > entries that have an anonymous parent from the child dentry using
> > dentry_path_raw().
> >
> > Make the dentry argument of __audit_inode_child() non-const so that we
> > can take a reference to it in the case of an anonymous parent with
> > dget() and dget_parent() to be able to later print a partial path from
> > the host filesystem rather than null.
> >
> > Since all we are given is an inode of the parent and the dentry of the
> > child, finding the path from the mount point to the root of the
> > filesystem is more challenging that would involve searching all
> > vfsmounts from "/" until a matching dentry is found for that
> > filesystem's root dentry.  Even if one is found, there may be more than
> > one mount point.  At this point the gain seems marginal since
> > knowing the filesystem type and path are a significant help in tracking
> > down the source of the PATH records and being to address them.
> >
> > Sample output:
> > type=PROCTITLE msg=audit(1488317694.446:143): 
> > proctitle=2F7362696E2F6D6F6470726F6265002D71002D2D006E66737634
> > type=PATH msg=audit(1488317694.446:143): item=797 
> > name=tracefs(74726163):/events/nfs4/nfs4_setclientid/format inode=15969 
> > dev=00:09 mode=0100444 ouid=0 ogid=0 rdev=00:00 
> > obj=system_u:object_r:tracefs_t:s0 nametype=CREATE
> > type=PATH msg=audit(1488317694.446:143): item=796 
> > name=tracefs(74726163):/events/nfs4/nfs4_setclientid inode=15964 dev=00:09 
> > mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 
> > nametype=PARENT
> > ...
> > type=PATH msg=audit(1488317694.446:143): item=1 
> > name=tracefs(74726163):/events/nfs4 inode=15571 dev=00:09 mode=040755 
> > ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=CREATE
> > type=PATH msg=audit(1488317694.446:143): item=0 
> > name=tracefs(74726163):/events inode=119 dev=00:09 mode=040755 ouid=0 
> > ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=PARENT
> > type=UNKNOWN[1330] msg=audit(1488317694.446:143): name="nfsv4"
> > type=SYSCALL msg=audit(1488317694.446:143): arch=c03e syscall=313 
> > success=yes exit=0 a0=1 a1=55d5a35ce106 a2=0 a3=1 items=798 ppid=6 pid=528 
> > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
> > tty=(none) ses=4294967295 comm="modprobe" exe="/usr/bin/kmod" 
> > subj=system_u:system_r:insmod_t:s0 key="mod-load"
> >
> > See: https://github.com/linux-audit/audit-kernel/issues/8
> > Test case: https://github.com/linux-audit/audit-testsuite/issues/42
> >
> > Signed-off-by: Richard Guy Briggs 
> > ---
> >  include/linux/audit.h |8 
> >  kernel/audit.c|   16 
> >  kernel/audit.h|1 +
> >  kernel/auditsc.c  |8 +++-
> >  4 files changed, 28 insertions(+), 5 deletions(-)
> 
> I see the "ALT4" in the subject line which gives me pause; does this
> mean you plan further development for the other potential fixes, or
> did you just include it on this patch for better tracking with it's
> predecessor?

The "ALT4" was included for tracking.  This is the planned path forward,
abandonning the rest of the "ALT*"s.

> I'm basically asking what to expect.  Should I review this for
> inclusion, or wait for other alternatives?

Please review.

> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index aba3a26..367a03a 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -241,7 +241,7 @@ extern void __audit_inode(struct filename *name, const 
> > struct dentry *dentry,
> > unsigned int flags);
> >  extern void __audit_file(const struct file *);
> >  extern void __audit_inode_child(struct inode *parent,
> > -   const struct dentry *dentry,
> > +   struct dentry *dentry,
> > const unsigned char type);
> >  extern void __audit_seccomp(unsigned long syscall, long signr, int code);
> >  extern void __audit_ptrace(struct task_struct *t);
> > @@ -306,7 +306,7 @@ static inline void audit_inode_parent_hidden(struct 
> > filename *name,
> > AUDIT_INODE_PARENT 

[PATCH v2 1/2] serial: 8250: Add flag so drivers can avoid THRE probe

[Joel Stanley]

The probing of THRE irq behaviour assumes the other end will be reading
bytes out of the buffer in order to probe the port at driver init. In
some cases the other end cannot be relied upon to read these bytes, so
provide a flag for them to skip this step.

Bit 16 was chosen as the flags are a int and the top bits are taken.

Acked-by: Benjamin Herrenschmidt 
Signed-off-by: Joel Stanley 
---
 drivers/tty/serial/8250/8250_port.c | 2 +-
 include/linux/serial_core.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_port.c 
b/drivers/tty/serial/8250/8250_port.c
index 6119516ef5fc..60a6c247340f 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2229,7 +2229,7 @@ int serial8250_do_startup(struct uart_port *port)
}
}
 
-   if (port->irq) {
+   if (port->irq && !(up->port.flags & UPF_NO_THRE_TEST)) {
unsigned char iir1;
/*
 * Test for UARTs that do not reassert THRE when the
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 58484fb35cc8..260245deec94 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -195,6 +195,7 @@ struct uart_port {
 #define UPF_NO_TXEN_TEST   ((__force upf_t) (1 << 15))
 #define UPF_MAGIC_MULTIPLIER   ((__force upf_t) ASYNC_MAGIC_MULTIPLIER /* 16 
*/ )
 
+#define UPF_NO_THRE_TEST   ((__force upf_t) (1 << 19))
 /* Port has hardware-assisted h/w flow control */
 #define UPF_AUTO_CTS   ((__force upf_t) (1 << 20))
 #define UPF_AUTO_RTS   ((__force upf_t) (1 << 21))
-- 
2.11.0

[PATCH v2 1/2] serial: 8250: Add flag so drivers can avoid THRE probe

[Joel Stanley]

The probing of THRE irq behaviour assumes the other end will be reading
bytes out of the buffer in order to probe the port at driver init. In
some cases the other end cannot be relied upon to read these bytes, so
provide a flag for them to skip this step.

Bit 16 was chosen as the flags are a int and the top bits are taken.

Acked-by: Benjamin Herrenschmidt 
Signed-off-by: Joel Stanley 
---
 drivers/tty/serial/8250/8250_port.c | 2 +-
 include/linux/serial_core.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_port.c 
b/drivers/tty/serial/8250/8250_port.c
index 6119516ef5fc..60a6c247340f 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2229,7 +2229,7 @@ int serial8250_do_startup(struct uart_port *port)
}
}
 
-   if (port->irq) {
+   if (port->irq && !(up->port.flags & UPF_NO_THRE_TEST)) {
unsigned char iir1;
/*
 * Test for UARTs that do not reassert THRE when the
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 58484fb35cc8..260245deec94 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -195,6 +195,7 @@ struct uart_port {
 #define UPF_NO_TXEN_TEST   ((__force upf_t) (1 << 15))
 #define UPF_MAGIC_MULTIPLIER   ((__force upf_t) ASYNC_MAGIC_MULTIPLIER /* 16 
*/ )
 
+#define UPF_NO_THRE_TEST   ((__force upf_t) (1 << 19))
 /* Port has hardware-assisted h/w flow control */
 #define UPF_AUTO_CTS   ((__force upf_t) (1 << 20))
 #define UPF_AUTO_RTS   ((__force upf_t) (1 << 21))
-- 
2.11.0

[PATCH v2 2/2] drivers/serial: Add driver for Aspeed virtual UART

[Joel Stanley]

From: Jeremy Kerr 

This change adds a driver for the 16550-based Aspeed virtual UART
device. We use a similar process to the of_serial driver for device
probe, but expose some VUART-specific functions through sysfs too.

The VUART is two UART 'front ends' connected by their FIFO (no actual
serial line in between). One is on the BMC side (management controller)
and one is on the host CPU side.

This driver is for the BMC side. The sysfs files allow the BMC
userspace, which owns the system configuration policy, to specify at
what IO port and interrupt number the host side will appear to the host
on the Host <-> BMC LPC bus. It could be different on a different system
(though most of them use 3f8/4).

OpenPOWER host firmware doesn't like it when the host-side of the
VUART's FIFO is not drained. This driver only disables host TX discard
mode when the port is in use. We set the VUART enabled bit when we bind
to the device, and clear it on unbind.

We don't want to do this on open/release, as the host may be using this
bit to configure serial output modes, which is independent of whether
the devices has been opened by BMC userspace.

Signed-off-by: Jeremy Kerr 
Signed-off-by: Joel Stanley 
Acked-by: Rob Herring 

---
v2:
 - Use attribute groups and DEVICE_ATTR_RW
 - Use platform_get_resource/devm_ioremap_resource
 - of_find_property -> of_property_read_bool
 - Drop unncessary 0xff mask
 - Fix comment style
 - Use BIT and GENMASK where pssible
 - Move to 8250 directory
 - Rename ast -> aspeed to match other Aspeed drivers
 - Add documentation of sysfs file
 - Add detail to the commit message
 - add Rob's ack for the binding change

---
 Documentation/ABI/stable/sysfs-driver-aspeed-vuart |  15 +
 Documentation/devicetree/bindings/serial/8250.txt  |   2 +
 drivers/tty/serial/8250/Kconfig|  10 +
 drivers/tty/serial/8250/Makefile   |   1 +
 drivers/tty/serial/8250/aspeed-vuart.c | 341 +
 5 files changed, 369 insertions(+)
 create mode 100644 Documentation/ABI/stable/sysfs-driver-aspeed-vuart
 create mode 100644 drivers/tty/serial/8250/aspeed-vuart.c

diff --git a/Documentation/ABI/stable/sysfs-driver-aspeed-vuart 
b/Documentation/ABI/stable/sysfs-driver-aspeed-vuart
new file mode 100644
index ..8062953ce77b
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-driver-aspeed-vuart
@@ -0,0 +1,15 @@
+What:  /sys/bus/platform/drivers/aspeed-vuart/*/lpc_address
+Date:  April 2017
+Contact:   Jeremy Kerr 
+Description:   Configures which IO port the host side of the UART
+   will appear on the host <-> BMC LPC bus.
+Users: OpenBMC.  Proposed changes should be mailed to
+   open...@lists.ozlabs.org
+
+What:  /sys/bus/platform/drivers/aspeed-vuart*/sirq
+Date:  April 2017
+Contact:   Jeremy Kerr 
+Description:   Configures which interrupt number the host side of
+   the UART will appear on the host <-> BMC LPC bus.
+Users: OpenBMC.  Proposed changes should be mailed to
+   open...@lists.ozlabs.org
diff --git a/Documentation/devicetree/bindings/serial/8250.txt 
b/Documentation/devicetree/bindings/serial/8250.txt
index 10276a46ecef..656733949309 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -20,6 +20,8 @@ Required properties:
- "fsl,16550-FIFO64"
- "fsl,ns16550"
- "ti,da830-uart"
+   - "aspeed,ast2400-vuart"
+   - "aspeed,ast2500-vuart"
- "serial" if the port type is unknown.
 - reg : offset and length of the register set for the device.
 - interrupts : should contain uart interrupt.
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index a65fb8197aec..fb217f02ec94 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -220,6 +220,16 @@ config SERIAL_8250_ACCENT
  To compile this driver as a module, choose M here: the module
  will be called 8250_accent.
 
+config SERIAL_8250_ASPEED_VUART
+   tristate "Aspeed Virtual UART"
+   depends on SERIAL_8250
+   depends on OF
+   help
+ If you want to use the virtual UART (VUART) device on Aspeed
+ BMC platforms, enable this option. This enables the 16550A-
+ compatible device on the local LPC bus, giving a UART device
+ with no physical RS232 connections.
+
 config SERIAL_8250_BOCA
tristate "Support Boca cards"
depends on SERIAL_8250 != n && ISA && SERIAL_8250_MANY_PORTS
diff --git a/drivers/tty/serial/8250/Makefile b/drivers/tty/serial/8250/Makefile
index 2f30f9ecdb1b..405d720b51c7 100644
--- a/drivers/tty/serial/8250/Makefile
+++ b/drivers/tty/serial/8250/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_SERIAL_8250_EXAR)+= 8250_exar.o
 

[PATCH v2 2/2] drivers/serial: Add driver for Aspeed virtual UART

[Joel Stanley]

From: Jeremy Kerr 

This change adds a driver for the 16550-based Aspeed virtual UART
device. We use a similar process to the of_serial driver for device
probe, but expose some VUART-specific functions through sysfs too.

The VUART is two UART 'front ends' connected by their FIFO (no actual
serial line in between). One is on the BMC side (management controller)
and one is on the host CPU side.

This driver is for the BMC side. The sysfs files allow the BMC
userspace, which owns the system configuration policy, to specify at
what IO port and interrupt number the host side will appear to the host
on the Host <-> BMC LPC bus. It could be different on a different system
(though most of them use 3f8/4).

OpenPOWER host firmware doesn't like it when the host-side of the
VUART's FIFO is not drained. This driver only disables host TX discard
mode when the port is in use. We set the VUART enabled bit when we bind
to the device, and clear it on unbind.

We don't want to do this on open/release, as the host may be using this
bit to configure serial output modes, which is independent of whether
the devices has been opened by BMC userspace.

Signed-off-by: Jeremy Kerr 
Signed-off-by: Joel Stanley 
Acked-by: Rob Herring 

---
v2:
 - Use attribute groups and DEVICE_ATTR_RW
 - Use platform_get_resource/devm_ioremap_resource
 - of_find_property -> of_property_read_bool
 - Drop unncessary 0xff mask
 - Fix comment style
 - Use BIT and GENMASK where pssible
 - Move to 8250 directory
 - Rename ast -> aspeed to match other Aspeed drivers
 - Add documentation of sysfs file
 - Add detail to the commit message
 - add Rob's ack for the binding change

---
 Documentation/ABI/stable/sysfs-driver-aspeed-vuart |  15 +
 Documentation/devicetree/bindings/serial/8250.txt  |   2 +
 drivers/tty/serial/8250/Kconfig|  10 +
 drivers/tty/serial/8250/Makefile   |   1 +
 drivers/tty/serial/8250/aspeed-vuart.c | 341 +
 5 files changed, 369 insertions(+)
 create mode 100644 Documentation/ABI/stable/sysfs-driver-aspeed-vuart
 create mode 100644 drivers/tty/serial/8250/aspeed-vuart.c

diff --git a/Documentation/ABI/stable/sysfs-driver-aspeed-vuart 
b/Documentation/ABI/stable/sysfs-driver-aspeed-vuart
new file mode 100644
index ..8062953ce77b
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-driver-aspeed-vuart
@@ -0,0 +1,15 @@
+What:  /sys/bus/platform/drivers/aspeed-vuart/*/lpc_address
+Date:  April 2017
+Contact:   Jeremy Kerr 
+Description:   Configures which IO port the host side of the UART
+   will appear on the host <-> BMC LPC bus.
+Users: OpenBMC.  Proposed changes should be mailed to
+   open...@lists.ozlabs.org
+
+What:  /sys/bus/platform/drivers/aspeed-vuart*/sirq
+Date:  April 2017
+Contact:   Jeremy Kerr 
+Description:   Configures which interrupt number the host side of
+   the UART will appear on the host <-> BMC LPC bus.
+Users: OpenBMC.  Proposed changes should be mailed to
+   open...@lists.ozlabs.org
diff --git a/Documentation/devicetree/bindings/serial/8250.txt 
b/Documentation/devicetree/bindings/serial/8250.txt
index 10276a46ecef..656733949309 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -20,6 +20,8 @@ Required properties:
- "fsl,16550-FIFO64"
- "fsl,ns16550"
- "ti,da830-uart"
+   - "aspeed,ast2400-vuart"
+   - "aspeed,ast2500-vuart"
- "serial" if the port type is unknown.
 - reg : offset and length of the register set for the device.
 - interrupts : should contain uart interrupt.
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index a65fb8197aec..fb217f02ec94 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -220,6 +220,16 @@ config SERIAL_8250_ACCENT
  To compile this driver as a module, choose M here: the module
  will be called 8250_accent.
 
+config SERIAL_8250_ASPEED_VUART
+   tristate "Aspeed Virtual UART"
+   depends on SERIAL_8250
+   depends on OF
+   help
+ If you want to use the virtual UART (VUART) device on Aspeed
+ BMC platforms, enable this option. This enables the 16550A-
+ compatible device on the local LPC bus, giving a UART device
+ with no physical RS232 connections.
+
 config SERIAL_8250_BOCA
tristate "Support Boca cards"
depends on SERIAL_8250 != n && ISA && SERIAL_8250_MANY_PORTS
diff --git a/drivers/tty/serial/8250/Makefile b/drivers/tty/serial/8250/Makefile
index 2f30f9ecdb1b..405d720b51c7 100644
--- a/drivers/tty/serial/8250/Makefile
+++ b/drivers/tty/serial/8250/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_SERIAL_8250_EXAR)+= 8250_exar.o
 obj-$(CONFIG_SERIAL_8250_HP300)+= 8250_hp300.o
 obj-$(CONFIG_SERIAL_8250_CS)   += 

[PATCH v2 0/2] drivers: serial: Aspeed VUART driver

[Joel Stanley]

This is v2 of a driver for the Aspeed VUART. This version addresses feedback
from Andy and Greg, and adds Rob's ack for the bindings change.

The VUART is a serial device on the BMC side of the LPC bus that connects a BMC
to it's host processor.

We add a flag to the serial core to allow the driver to skip probing of the
THRE irq behaviour, which could hang due to the host not reading bytes out of
the buffer.

We've been using this on systems for over a year, so it has seen a good amount
of testing.

Cheers,

Joel

Jeremy Kerr (1):
  drivers/serial: Add driver for Aspeed virtual UART

Joel Stanley (1):
  serial: 8250: Add flag so drivers can avoid THRE probe

 Documentation/ABI/stable/sysfs-driver-aspeed-vuart |  15 +
 Documentation/devicetree/bindings/serial/8250.txt  |   2 +
 drivers/tty/serial/8250/8250_port.c|   2 +-
 drivers/tty/serial/8250/Kconfig|  10 +
 drivers/tty/serial/8250/Makefile   |   1 +
 drivers/tty/serial/8250/aspeed-vuart.c | 341 +
 include/linux/serial_core.h|   1 +
 7 files changed, 371 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/stable/sysfs-driver-aspeed-vuart
 create mode 100644 drivers/tty/serial/8250/aspeed-vuart.c

-- 
2.11.0

[PATCH v2 0/2] drivers: serial: Aspeed VUART driver

[Joel Stanley]

This is v2 of a driver for the Aspeed VUART. This version addresses feedback
from Andy and Greg, and adds Rob's ack for the bindings change.

The VUART is a serial device on the BMC side of the LPC bus that connects a BMC
to it's host processor.

We add a flag to the serial core to allow the driver to skip probing of the
THRE irq behaviour, which could hang due to the host not reading bytes out of
the buffer.

We've been using this on systems for over a year, so it has seen a good amount
of testing.

Cheers,

Joel

Jeremy Kerr (1):
  drivers/serial: Add driver for Aspeed virtual UART

Joel Stanley (1):
  serial: 8250: Add flag so drivers can avoid THRE probe

 Documentation/ABI/stable/sysfs-driver-aspeed-vuart |  15 +
 Documentation/devicetree/bindings/serial/8250.txt  |   2 +
 drivers/tty/serial/8250/8250_port.c|   2 +-
 drivers/tty/serial/8250/Kconfig|  10 +
 drivers/tty/serial/8250/Makefile   |   1 +
 drivers/tty/serial/8250/aspeed-vuart.c | 341 +
 include/linux/serial_core.h|   1 +
 7 files changed, 371 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/stable/sysfs-driver-aspeed-vuart
 create mode 100644 drivers/tty/serial/8250/aspeed-vuart.c

-- 
2.11.0

Re: [PATCH] arm64: perf: Count EL2 events if either of kernel and hyp are not excluded

[Ganapatrao Kulkarni]

On Tue, Apr 4, 2017 at 5:56 PM, Will Deacon  wrote:
> On Tue, Apr 04, 2017 at 05:37:10PM +0530, Ganapatrao Kulkarni wrote:
>> On Tue, Apr 4, 2017 at 4:48 PM, Will Deacon  wrote:
>> > On Tue, Apr 04, 2017 at 04:10:55PM +0530, Ganapatrao Kulkarni wrote:
>> >> commit d98ecda (arm64: perf: Count EL2 events if the kernel is running in 
>> >> HYP)
>> >> is returning error for perf syscall with mixed attribute set for 
>> >> exclude_kernel
>> >> and exlude_hv.
>> >>
>> >> This change is breaking some applications (observed with hhvm) when
>> >> ran with VHE enabled. Adding change to enable EL2 event counting,
>> >> if either of or both of exclude_kernel and exlude_hv are not set.
>> >>
>> >> Signed-off-by: Ganapatrao Kulkarni 
>> >> ---
>> >>  arch/arm64/kernel/perf_event.c | 19 ---
>> >>  1 file changed, 12 insertions(+), 7 deletions(-)
>> >
>> > Hmm. When we have VHE, we can't distinguish between hypervisor and kernel,
>> > so this patch doesn't seem right to me. The code currently requires
>> > both exclude_kernel and exclude_hv to be clear before we enable profiling
>> > EL2, otherwise we're failing to exclude samples that were asked to be
>> > excluded.
>>
>> The application cant differentiate that kernel is running in EL2/VHE or in 
>> EL1
>> when VHE=1, is it makes sense to enable EL2 event counting when there
>> is request from application to either include kernel or hypervisor
>> event count, since both are same.
>
> You can make exactly the same argument against your proposal by saying that
> it makes sense to disable EL2 event counting when there is a request from
> an application to either exclude kernel or hypervisor event counting.

yes, the argument is equally valid on either side.

>
>> IMO, it is not appropriate to have different application behaviour
>> when kernel booted with VHE=0/1
>
> Then find another solution to that. How about a mechanism to advertise
> that exclude_hv is effectively always set if the kernel is running at EL2?

I am not sure, how we can advertise to user that kernel is running at EL2.
we may add a note to man page of perf_event_open?
"exclude_hv is always set, if host kernel and hypervisor are running
at same privilege level",

>
> That would mean that you would use exclude_kernel to determine the profiling
> controls for the host.

yes, this seems to be more appropriate.

>
> Will

thanks
Ganapat

Re: [PATCH] arm64: perf: Count EL2 events if either of kernel and hyp are not excluded

[Ganapatrao Kulkarni]

On Tue, Apr 4, 2017 at 5:56 PM, Will Deacon  wrote:
> On Tue, Apr 04, 2017 at 05:37:10PM +0530, Ganapatrao Kulkarni wrote:
>> On Tue, Apr 4, 2017 at 4:48 PM, Will Deacon  wrote:
>> > On Tue, Apr 04, 2017 at 04:10:55PM +0530, Ganapatrao Kulkarni wrote:
>> >> commit d98ecda (arm64: perf: Count EL2 events if the kernel is running in 
>> >> HYP)
>> >> is returning error for perf syscall with mixed attribute set for 
>> >> exclude_kernel
>> >> and exlude_hv.
>> >>
>> >> This change is breaking some applications (observed with hhvm) when
>> >> ran with VHE enabled. Adding change to enable EL2 event counting,
>> >> if either of or both of exclude_kernel and exlude_hv are not set.
>> >>
>> >> Signed-off-by: Ganapatrao Kulkarni 
>> >> ---
>> >>  arch/arm64/kernel/perf_event.c | 19 ---
>> >>  1 file changed, 12 insertions(+), 7 deletions(-)
>> >
>> > Hmm. When we have VHE, we can't distinguish between hypervisor and kernel,
>> > so this patch doesn't seem right to me. The code currently requires
>> > both exclude_kernel and exclude_hv to be clear before we enable profiling
>> > EL2, otherwise we're failing to exclude samples that were asked to be
>> > excluded.
>>
>> The application cant differentiate that kernel is running in EL2/VHE or in 
>> EL1
>> when VHE=1, is it makes sense to enable EL2 event counting when there
>> is request from application to either include kernel or hypervisor
>> event count, since both are same.
>
> You can make exactly the same argument against your proposal by saying that
> it makes sense to disable EL2 event counting when there is a request from
> an application to either exclude kernel or hypervisor event counting.

yes, the argument is equally valid on either side.

>
>> IMO, it is not appropriate to have different application behaviour
>> when kernel booted with VHE=0/1
>
> Then find another solution to that. How about a mechanism to advertise
> that exclude_hv is effectively always set if the kernel is running at EL2?

I am not sure, how we can advertise to user that kernel is running at EL2.
we may add a note to man page of perf_event_open?
"exclude_hv is always set, if host kernel and hypervisor are running
at same privilege level",

>
> That would mean that you would use exclude_kernel to determine the profiling
> controls for the host.

yes, this seems to be more appropriate.

>
> Will

thanks
Ganapat

Re: [PATCH kernel v8 2/4] virtio-balloon: VIRTIO_BALLOON_F_CHUNK_TRANSFER

[Michael S. Tsirkin]

On Wed, Apr 05, 2017 at 03:31:36AM +, Wang, Wei W wrote:
> On Thursday, March 16, 2017 3:09 PM Wei Wang wrote:
> > The implementation of the current virtio-balloon is not very efficient, 
> > because
> > the ballooned pages are transferred to the host one by one. Here is the
> > breakdown of the time in percentage spent on each step of the balloon 
> > inflating
> > process (inflating 7GB of an 8GB idle guest).
> > 
> > 1) allocating pages (6.5%)
> > 2) sending PFNs to host (68.3%)
> > 3) address translation (6.1%)
> > 4) madvise (19%)
> > 
> > It takes about 4126ms for the inflating process to complete.
> > The above profiling shows that the bottlenecks are stage 2) and stage 4).
> > 
> > This patch optimizes step 2) by transferring pages to the host in chunks. A 
> > chunk
> > consists of guest physically continuous pages, and it is offered to the 
> > host via a
> > base PFN (i.e. the start PFN of those physically continuous pages) and the 
> > size
> > (i.e. the total number of the pages). A chunk is formated as below:
> > 
> > 
> > | Base (52 bit)| Rsvd (12 bit) |
> > 
> > 
> > | Size (52 bit)| Rsvd (12 bit) |
> > 
> > 
> > By doing so, step 4) can also be optimized by doing address translation and
> > madvise() in chunks rather than page by page.
> > 
> > This optimization requires the negotiation of a new feature bit,
> > VIRTIO_BALLOON_F_CHUNK_TRANSFER.
> > 
> > With this new feature, the above ballooning process takes ~590ms resulting 
> > in
> > an improvement of ~85%.
> > 
> > TODO: optimize stage 1) by allocating/freeing a chunk of pages instead of a
> > single page each time.
> > 
> > Signed-off-by: Liang Li 
> > Signed-off-by: Wei Wang 
> > Suggested-by: Michael S. Tsirkin 
> > ---
> >  drivers/virtio/virtio_balloon.c | 371 
> > +-
> > --
> >  include/uapi/linux/virtio_balloon.h |   9 +
> >  2 files changed, 353 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/virtio/virtio_balloon.c 
> > b/drivers/virtio/virtio_balloon.c index
> > f59cb4f..3f4a161 100644
> > --- a/drivers/virtio/virtio_balloon.c
> > +++ b/drivers/virtio/virtio_balloon.c
> > @@ -42,6 +42,10 @@
> >  #define OOM_VBALLOON_DEFAULT_PAGES 256
> >  #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
> > 
> > +#define PAGE_BMAP_SIZE (8 * PAGE_SIZE)
> > +#define PFNS_PER_PAGE_BMAP (PAGE_BMAP_SIZE * BITS_PER_BYTE)
> > +#define PAGE_BMAP_COUNT_MAX32
> > +
> >  static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
> > module_param(oom_pages, int, S_IRUSR | S_IWUSR);
> > MODULE_PARM_DESC(oom_pages, "pages to free on OOM"); @@ -50,6 +54,14
> > @@ MODULE_PARM_DESC(oom_pages, "pages to free on OOM");  static struct
> > vfsmount *balloon_mnt;  #endif
> > 
> > +#define BALLOON_CHUNK_BASE_SHIFT 12
> > +#define BALLOON_CHUNK_SIZE_SHIFT 12
> > +struct balloon_page_chunk {
> > +   __le64 base;
> > +   __le64 size;
> > +};
> > +
> > +typedef __le64 resp_data_t;
> >  struct virtio_balloon {
> > struct virtio_device *vdev;
> > struct virtqueue *inflate_vq, *deflate_vq, *stats_vq; @@ -67,6 +79,31
> > @@ struct virtio_balloon {
> > 
> > /* Number of balloon pages we've told the Host we're not using. */
> > unsigned int num_pages;
> > +   /* Pointer to the response header. */
> > +   struct virtio_balloon_resp_hdr *resp_hdr;
> > +   /* Pointer to the start address of response data. */
> > +   resp_data_t *resp_data;
> 
> I think the implementation has an issue here - both the balloon pages and the 
> unused pages use the same buffer ("resp_data" above) to store chunks. It 
> would cause a race in this case: live migration starts while ballooning is 
> also in progress. I plan to use separate buffers for CHUNKS_OF_BALLOON_PAGES 
> and CHUNKS_OF_UNUSED_PAGES. Please let me know if you have a different 
> suggestion. Thanks.
> 
> Best,
> Wei

Is only one resp data ever in flight for each kind?
If not you want as many buffers as vq allows.

-- 
MST

Re: [PATCH kernel v8 2/4] virtio-balloon: VIRTIO_BALLOON_F_CHUNK_TRANSFER

[Michael S. Tsirkin]

On Wed, Apr 05, 2017 at 03:31:36AM +, Wang, Wei W wrote:
> On Thursday, March 16, 2017 3:09 PM Wei Wang wrote:
> > The implementation of the current virtio-balloon is not very efficient, 
> > because
> > the ballooned pages are transferred to the host one by one. Here is the
> > breakdown of the time in percentage spent on each step of the balloon 
> > inflating
> > process (inflating 7GB of an 8GB idle guest).
> > 
> > 1) allocating pages (6.5%)
> > 2) sending PFNs to host (68.3%)
> > 3) address translation (6.1%)
> > 4) madvise (19%)
> > 
> > It takes about 4126ms for the inflating process to complete.
> > The above profiling shows that the bottlenecks are stage 2) and stage 4).
> > 
> > This patch optimizes step 2) by transferring pages to the host in chunks. A 
> > chunk
> > consists of guest physically continuous pages, and it is offered to the 
> > host via a
> > base PFN (i.e. the start PFN of those physically continuous pages) and the 
> > size
> > (i.e. the total number of the pages). A chunk is formated as below:
> > 
> > 
> > | Base (52 bit)| Rsvd (12 bit) |
> > 
> > 
> > | Size (52 bit)| Rsvd (12 bit) |
> > 
> > 
> > By doing so, step 4) can also be optimized by doing address translation and
> > madvise() in chunks rather than page by page.
> > 
> > This optimization requires the negotiation of a new feature bit,
> > VIRTIO_BALLOON_F_CHUNK_TRANSFER.
> > 
> > With this new feature, the above ballooning process takes ~590ms resulting 
> > in
> > an improvement of ~85%.
> > 
> > TODO: optimize stage 1) by allocating/freeing a chunk of pages instead of a
> > single page each time.
> > 
> > Signed-off-by: Liang Li 
> > Signed-off-by: Wei Wang 
> > Suggested-by: Michael S. Tsirkin 
> > ---
> >  drivers/virtio/virtio_balloon.c | 371 
> > +-
> > --
> >  include/uapi/linux/virtio_balloon.h |   9 +
> >  2 files changed, 353 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/virtio/virtio_balloon.c 
> > b/drivers/virtio/virtio_balloon.c index
> > f59cb4f..3f4a161 100644
> > --- a/drivers/virtio/virtio_balloon.c
> > +++ b/drivers/virtio/virtio_balloon.c
> > @@ -42,6 +42,10 @@
> >  #define OOM_VBALLOON_DEFAULT_PAGES 256
> >  #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
> > 
> > +#define PAGE_BMAP_SIZE (8 * PAGE_SIZE)
> > +#define PFNS_PER_PAGE_BMAP (PAGE_BMAP_SIZE * BITS_PER_BYTE)
> > +#define PAGE_BMAP_COUNT_MAX32
> > +
> >  static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
> > module_param(oom_pages, int, S_IRUSR | S_IWUSR);
> > MODULE_PARM_DESC(oom_pages, "pages to free on OOM"); @@ -50,6 +54,14
> > @@ MODULE_PARM_DESC(oom_pages, "pages to free on OOM");  static struct
> > vfsmount *balloon_mnt;  #endif
> > 
> > +#define BALLOON_CHUNK_BASE_SHIFT 12
> > +#define BALLOON_CHUNK_SIZE_SHIFT 12
> > +struct balloon_page_chunk {
> > +   __le64 base;
> > +   __le64 size;
> > +};
> > +
> > +typedef __le64 resp_data_t;
> >  struct virtio_balloon {
> > struct virtio_device *vdev;
> > struct virtqueue *inflate_vq, *deflate_vq, *stats_vq; @@ -67,6 +79,31
> > @@ struct virtio_balloon {
> > 
> > /* Number of balloon pages we've told the Host we're not using. */
> > unsigned int num_pages;
> > +   /* Pointer to the response header. */
> > +   struct virtio_balloon_resp_hdr *resp_hdr;
> > +   /* Pointer to the start address of response data. */
> > +   resp_data_t *resp_data;
> 
> I think the implementation has an issue here - both the balloon pages and the 
> unused pages use the same buffer ("resp_data" above) to store chunks. It 
> would cause a race in this case: live migration starts while ballooning is 
> also in progress. I plan to use separate buffers for CHUNKS_OF_BALLOON_PAGES 
> and CHUNKS_OF_UNUSED_PAGES. Please let me know if you have a different 
> suggestion. Thanks.
> 
> Best,
> Wei

Is only one resp data ever in flight for each kind?
If not you want as many buffers as vq allows.

-- 
MST

Re: [linux-sunxi] [PATCH 03/11] dt-bindings: add device tree binding for X-Powers AXP803 PMIC

[Chen-Yu Tsai]

On Wed, Apr 5, 2017 at 2:01 AM, Icenowy Zheng  wrote:
> AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB
> bus.
>
> Add a compatible for it.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
> b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index b41d2601c6ba..31607631b0d8 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -7,11 +7,12 @@ axp209 (X-Powers)
>  axp221 (X-Powers)
>  axp223 (X-Powers)
>  axp809 (X-Powers)
> +axp803 (X-Powers)
>
>  Required properties:
>  - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
>   "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
> - "x-powers,axp809"
> + "x-powers,axp809", "x-powers,axp803"

Please sort them in ascending order. Otherwise,

Acked-by: Chen-Yu Tsai 

>  - reg: The I2C slave address or RSB hardware address for the AXP chip
>  - interrupt-parent: The parent interrupt controller
>  - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 03/11] dt-bindings: add device tree binding for X-Powers AXP803 PMIC

[Chen-Yu Tsai]

On Wed, Apr 5, 2017 at 2:01 AM, Icenowy Zheng  wrote:
> AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB
> bus.
>
> Add a compatible for it.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
> b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index b41d2601c6ba..31607631b0d8 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -7,11 +7,12 @@ axp209 (X-Powers)
>  axp221 (X-Powers)
>  axp223 (X-Powers)
>  axp809 (X-Powers)
> +axp803 (X-Powers)
>
>  Required properties:
>  - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
>   "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
> - "x-powers,axp809"
> + "x-powers,axp809", "x-powers,axp803"

Please sort them in ascending order. Otherwise,

Acked-by: Chen-Yu Tsai 

>  - reg: The I2C slave address or RSB hardware address for the AXP chip
>  - interrupt-parent: The parent interrupt controller
>  - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

[Michael S. Tsirkin]

On Wed, Apr 05, 2017 at 05:24:30AM +0200, Mike Galbraith wrote:
> On Wed, 2017-04-05 at 06:13 +0300, Michael S. Tsirkin wrote:
> > On Wed, Apr 05, 2017 at 05:09:09AM +0200, Mike Galbraith wrote:
> > > On Tue, 2017-04-04 at 22:03 +0300, Michael S. Tsirkin wrote:
> > > 
> > > > since I couldn't reproduce, I decided it's worth trying to see
> > > > what happens if we revert back to before 5c34d002dcc7.
> > > > 
> > > > 
> > > > Could you please test a tag "test" in my tree above?
> > > > It should point at 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > > 
> > > Nogo.
> > > 
> > > git@homer:..git/vhost> git remote update
> > > Fetching origin
> > > git@homer:..git/vhost> git show
> > > 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > > fatal: bad object 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > 
> > Maybe because it's a tag not a head. Pls try
> > git fetch git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
> > refs/tags/test
> 
> That worked.  Checked out/building.

Thanks a lot for the testing.

-- 
MST

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

[Michael S. Tsirkin]

On Wed, Apr 05, 2017 at 05:24:30AM +0200, Mike Galbraith wrote:
> On Wed, 2017-04-05 at 06:13 +0300, Michael S. Tsirkin wrote:
> > On Wed, Apr 05, 2017 at 05:09:09AM +0200, Mike Galbraith wrote:
> > > On Tue, 2017-04-04 at 22:03 +0300, Michael S. Tsirkin wrote:
> > > 
> > > > since I couldn't reproduce, I decided it's worth trying to see
> > > > what happens if we revert back to before 5c34d002dcc7.
> > > > 
> > > > 
> > > > Could you please test a tag "test" in my tree above?
> > > > It should point at 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > > 
> > > Nogo.
> > > 
> > > git@homer:..git/vhost> git remote update
> > > Fetching origin
> > > git@homer:..git/vhost> git show
> > > 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > > fatal: bad object 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > 
> > Maybe because it's a tag not a head. Pls try
> > git fetch git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
> > refs/tags/test
> 
> That worked.  Checked out/building.

Thanks a lot for the testing.

-- 
MST

Re: [linux-sunxi] [PATCH 02/11] arm64: allwinner: a64: add NMI controller on A64

[Chen-Yu Tsai]

On Wed, Apr 5, 2017 at 2:01 AM, Icenowy Zheng  wrote:
> Allwinner A64 SoC features a NMI controller, which is usually connected
> to the AXP PMIC.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng 

This might not be the best representation of the R_INTC block. Though
we'd need to change it for all SoCs if we want to be accurate. For now,

Acked-by: Chen-Yu Tsai 

Re: [linux-sunxi] [PATCH 02/11] arm64: allwinner: a64: add NMI controller on A64

[Chen-Yu Tsai]

On Wed, Apr 5, 2017 at 2:01 AM, Icenowy Zheng  wrote:
> Allwinner A64 SoC features a NMI controller, which is usually connected
> to the AXP PMIC.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng 

This might not be the best representation of the R_INTC block. Though
we'd need to change it for all SoCs if we want to be accurate. For now,

Acked-by: Chen-Yu Tsai 

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

[Michael S. Tsirkin]

On Wed, Apr 05, 2017 at 05:40:06AM +0200, Mike Galbraith wrote:
> On Wed, 2017-04-05 at 05:24 +0200, Mike Galbraith wrote:
> > On Wed, 2017-04-05 at 06:13 +0300, Michael S. Tsirkin wrote:
> > > On Wed, Apr 05, 2017 at 05:09:09AM +0200, Mike Galbraith wrote:
> > > > On Tue, 2017-04-04 at 22:03 +0300, Michael S. Tsirkin wrote:
> > > > 
> > > > > since I couldn't reproduce, I decided it's worth trying to see
> > > > > what happens if we revert back to before 5c34d002dcc7.
> > > > > 
> > > > > 
> > > > > Could you please test a tag "test" in my tree above?
> > > > > It should point at 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > > > 
> > > > Nogo.
> > > > 
> > > > git@homer:..git/vhost> git remote update
> > > > Fetching origin
> > > > git@homer:..git/vhost> git show
> > > > 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > > > fatal: bad object 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > > 
> > > Maybe because it's a tag not a head. Pls try
> > > git fetch
> > > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
> > > refs/tags/test
> > 
> > That worked.  Checked out/building.
> 
> vbox hibernated gripe free, w/wo threadirqs.
> 
>   -Mike

Any issues at all left with this tree?
In particular any regressions?

-- 
MST

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

[Michael S. Tsirkin]

On Wed, Apr 05, 2017 at 05:40:06AM +0200, Mike Galbraith wrote:
> On Wed, 2017-04-05 at 05:24 +0200, Mike Galbraith wrote:
> > On Wed, 2017-04-05 at 06:13 +0300, Michael S. Tsirkin wrote:
> > > On Wed, Apr 05, 2017 at 05:09:09AM +0200, Mike Galbraith wrote:
> > > > On Tue, 2017-04-04 at 22:03 +0300, Michael S. Tsirkin wrote:
> > > > 
> > > > > since I couldn't reproduce, I decided it's worth trying to see
> > > > > what happens if we revert back to before 5c34d002dcc7.
> > > > > 
> > > > > 
> > > > > Could you please test a tag "test" in my tree above?
> > > > > It should point at 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > > > 
> > > > Nogo.
> > > > 
> > > > git@homer:..git/vhost> git remote update
> > > > Fetching origin
> > > > git@homer:..git/vhost> git show
> > > > 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > > > fatal: bad object 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > > 
> > > Maybe because it's a tag not a head. Pls try
> > > git fetch
> > > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
> > > refs/tags/test
> > 
> > That worked.  Checked out/building.
> 
> vbox hibernated gripe free, w/wo threadirqs.
> 
>   -Mike

Any issues at all left with this tree?
In particular any regressions?

-- 
MST

Re: [linux-sunxi] [PATCH 01/11] arm64: allwinner: a64: enable RSB on A64

[Chen-Yu Tsai]

On Wed, Apr 5, 2017 at 2:01 AM, Icenowy Zheng  wrote:
> Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.
>
> Add it and its pinmux.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 6bc606b4d74d..9a75b1c7c91a 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -420,6 +420,27 @@
> #gpio-cells = <3>;
> interrupt-controller;
> #interrupt-cells = <3>;
> +
> +   r_rsb_pins: rsb@0 {
> +   pins = "PL0", "PL1";
> +   function = "s_rsb";
> +   drive-strength = <20>;

We don't need this. The hardware default should be enough.

> +   bias-pull-up;

Boards should have external pull-ups for these pins, as the PMICs
start up in I2C mode. If any board actually doesn't have them and
needs the internal pull-ups, they should be set at the board level.

Otherwise,

Acked-by: Chen-Yu Tsai 

> +   };
> +   };
> +
> +   r_rsb: rsb@1f03400 {
> +   compatible = "allwinner,sun8i-a23-rsb";
> +   reg = <0x01f03400 0x400>;
> +   interrupts = ;
> +   clocks = <_ccu 6>;
> +   clock-frequency = <300>;
> +   resets = <_ccu 2>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_rsb_pins>;
> +   status = "disabled";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> };
> };
>  };
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 01/11] arm64: allwinner: a64: enable RSB on A64

[Chen-Yu Tsai]

On Wed, Apr 5, 2017 at 2:01 AM, Icenowy Zheng  wrote:
> Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.
>
> Add it and its pinmux.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 6bc606b4d74d..9a75b1c7c91a 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -420,6 +420,27 @@
> #gpio-cells = <3>;
> interrupt-controller;
> #interrupt-cells = <3>;
> +
> +   r_rsb_pins: rsb@0 {
> +   pins = "PL0", "PL1";
> +   function = "s_rsb";
> +   drive-strength = <20>;

We don't need this. The hardware default should be enough.

> +   bias-pull-up;

Boards should have external pull-ups for these pins, as the PMICs
start up in I2C mode. If any board actually doesn't have them and
needs the internal pull-ups, they should be set at the board level.

Otherwise,

Acked-by: Chen-Yu Tsai 

> +   };
> +   };
> +
> +   r_rsb: rsb@1f03400 {
> +   compatible = "allwinner,sun8i-a23-rsb";
> +   reg = <0x01f03400 0x400>;
> +   interrupts = ;
> +   clocks = <_ccu 6>;
> +   clock-frequency = <300>;
> +   resets = <_ccu 2>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_rsb_pins>;
> +   status = "disabled";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> };
> };
>  };
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 1/2] soc: qcom: smsm: Handle probe deferral

[Bjorn Andersson]

On Mon 03 Apr 19:38 PDT 2017, Jonathan Neusch?fer wrote:

> On Mon, Mar 27, 2017 at 11:18:29PM -0700, Bjorn Andersson wrote:
[..]
> > However, for us to reach this point in smsm_probe() the above
> > qcom_smem_get() must have returned successfully, i.e. we have SMEM in
> > place so there's no need to handle this case specifically.
> 
> I came to the same conclusion but wasn't sure. I'll drop this part from
> my patch.
> 
> I'll send a v2 of this series, although after applying your suggestions,
> I can't claim much originality anymore.
> 

Don't worry about it. Looking forward to version 2.

Regards,
Bjorn

Re: [PATCH 1/2] soc: qcom: smsm: Handle probe deferral

[Bjorn Andersson]

On Mon 03 Apr 19:38 PDT 2017, Jonathan Neusch?fer wrote:

> On Mon, Mar 27, 2017 at 11:18:29PM -0700, Bjorn Andersson wrote:
[..]
> > However, for us to reach this point in smsm_probe() the above
> > qcom_smem_get() must have returned successfully, i.e. we have SMEM in
> > place so there's no need to handle this case specifically.
> 
> I came to the same conclusion but wasn't sure. I'll drop this part from
> my patch.
> 
> I'll send a v2 of this series, although after applying your suggestions,
> I can't claim much originality anymore.
> 

Don't worry about it. Looking forward to version 2.

Regards,
Bjorn

Re: [PATCH] ebpf: verify the output of the JIT

[Tycho Andersen]

Hi Kees,

On Tue, Apr 04, 2017 at 03:17:57PM -0700, Kees Cook wrote:
> On Tue, Apr 4, 2017 at 3:08 PM, Tycho Andersen  wrote:
> > The goal of this patch is to protect the JIT against an attacker with a
> > write-in-memory primitive. The JIT allocates a buffer which will eventually
> > be marked +x, so we need to make sure that what was written to this buffer
> > is what was intended.
> >
> > We acheive this by building a hash of the instruction buffer as
> > instructions are emittted and then comparing that to a hash at the end of
> > the JIT compile after the buffer has been marked read-only.
> >
> > Signed-off-by: Tycho Andersen 
> > CC: Daniel Borkmann 
> > CC: Alexei Starovoitov 
> > CC: Kees Cook 
> > CC: Mickaël Salaün 
> 
> Cool! This closes the race condition on producing the JIT vs going
> read-only. I wonder if it might be possible to make this a more
> generic interface to the BPF which would be allocate the hash, provide
> the update callback during emit, and then do the hash check itself at
> the end of bpf_jit_binary_lock_ro()?

Yes, probably so. I can look into that for the next version.

Tycho

Re: [PATCH] ebpf: verify the output of the JIT

[Tycho Andersen]

Hi Kees,

On Tue, Apr 04, 2017 at 03:17:57PM -0700, Kees Cook wrote:
> On Tue, Apr 4, 2017 at 3:08 PM, Tycho Andersen  wrote:
> > The goal of this patch is to protect the JIT against an attacker with a
> > write-in-memory primitive. The JIT allocates a buffer which will eventually
> > be marked +x, so we need to make sure that what was written to this buffer
> > is what was intended.
> >
> > We acheive this by building a hash of the instruction buffer as
> > instructions are emittted and then comparing that to a hash at the end of
> > the JIT compile after the buffer has been marked read-only.
> >
> > Signed-off-by: Tycho Andersen 
> > CC: Daniel Borkmann 
> > CC: Alexei Starovoitov 
> > CC: Kees Cook 
> > CC: Mickaël Salaün 
> 
> Cool! This closes the race condition on producing the JIT vs going
> read-only. I wonder if it might be possible to make this a more
> generic interface to the BPF which would be allocate the hash, provide
> the update callback during emit, and then do the hash check itself at
> the end of bpf_jit_binary_lock_ro()?

Yes, probably so. I can look into that for the next version.

Tycho

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

[Mike Galbraith]

On Wed, 2017-04-05 at 05:24 +0200, Mike Galbraith wrote:
> On Wed, 2017-04-05 at 06:13 +0300, Michael S. Tsirkin wrote:
> > On Wed, Apr 05, 2017 at 05:09:09AM +0200, Mike Galbraith wrote:
> > > On Tue, 2017-04-04 at 22:03 +0300, Michael S. Tsirkin wrote:
> > > 
> > > > since I couldn't reproduce, I decided it's worth trying to see
> > > > what happens if we revert back to before 5c34d002dcc7.
> > > > 
> > > > 
> > > > Could you please test a tag "test" in my tree above?
> > > > It should point at 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > > 
> > > Nogo.
> > > 
> > > git@homer:..git/vhost> git remote update
> > > Fetching origin
> > > git@homer:..git/vhost> git show
> > > 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > > fatal: bad object 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > 
> > Maybe because it's a tag not a head. Pls try
> > git fetch
> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
> > refs/tags/test
> 
> That worked.  Checked out/building.

vbox hibernated gripe free, w/wo threadirqs.

-Mike

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

[Mike Galbraith]

On Wed, 2017-04-05 at 05:24 +0200, Mike Galbraith wrote:
> On Wed, 2017-04-05 at 06:13 +0300, Michael S. Tsirkin wrote:
> > On Wed, Apr 05, 2017 at 05:09:09AM +0200, Mike Galbraith wrote:
> > > On Tue, 2017-04-04 at 22:03 +0300, Michael S. Tsirkin wrote:
> > > 
> > > > since I couldn't reproduce, I decided it's worth trying to see
> > > > what happens if we revert back to before 5c34d002dcc7.
> > > > 
> > > > 
> > > > Could you please test a tag "test" in my tree above?
> > > > It should point at 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > > 
> > > Nogo.
> > > 
> > > git@homer:..git/vhost> git remote update
> > > Fetching origin
> > > git@homer:..git/vhost> git show
> > > 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > > fatal: bad object 6d88af1bf359417eb821370294ba489bdf7f5ab8
> > 
> > Maybe because it's a tag not a head. Pls try
> > git fetch
> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
> > refs/tags/test
> 
> That worked.  Checked out/building.

vbox hibernated gripe free, w/wo threadirqs.

-Mike