[tip:perf/core] perf powerpc: Fix build-test failure

[tip-bot for Ravi Bangoria]

Commit-ID:  25b8592e912f085ce2ff736a2927584ddeab238c
Gitweb: http://git.kernel.org/tip/25b8592e912f085ce2ff736a2927584ddeab238c
Author: Ravi Bangoria 
AuthorDate: Wed, 31 Aug 2016 13:33:11 +0530
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 8 Sep 2016 13:44:07 -0300

perf powerpc: Fix build-test failure

'make -C tools/perf build-test' is failing with below log for poewrpc.

  In file included from 
/tmp/tmp.3eEwmGlYaF/perf-4.8.0-rc4/tools/perf/perf.h:15:0,
   from util/cpumap.h:8,
   from util/env.c:1:
  /tmp/tmp.3eEwmGlYaF/perf-4.8.0-rc4/tools/perf/perf-sys.h:23:56:
  fatal error: ../../arch/powerpc/include/uapi/asm/unistd.h: No such file or 
directory
  compilation terminated.

I bisected it and found it's failing from commit ad430729ae00 ("Remove:
kernel unistd*h files from perf's MANIFEST, not used").

Header file '../../arch/powerpc/include/uapi/asm/unistd.h' is included
only for powerpc in tools/perf/perf-sys.h.

By looking closly at commit history, I found little weird thing:

Commit f2d9cae9ea9e ("perf powerpc: Use uapi/unistd.h to fix build
error") replaced 'asm/unistd.h' with 'uapi/asm/unistd.h'

Commit d2709c7ce4c5 ("perf: Make perf build for x86 with UAPI
disintegration applied") removes all arch specific 'uapi/asm/unistd.h'
for all archs and adds generic .

Commit f0b9abfb0446 ("Merge branch 'linus' into perf/core") again
includes 'uapi/asm/unistd.h' for powerpc. Don't know how exactly this
happened as this change is not part of commit also.

Signed-off-by: Ravi Bangoria 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1472630591-5089-1-git-send-email-ravi.bango...@linux.vnet.ibm.com
Fixes: ad430729ae00 ("Remove: kernel unistd*h files from perf's MANIFEST, not 
used")
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/perf-sys.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/perf/perf-sys.h b/tools/perf/perf-sys.h
index 7ed72a4..e4b717e 100644
--- a/tools/perf/perf-sys.h
+++ b/tools/perf/perf-sys.h
@@ -20,7 +20,6 @@
 #endif
 
 #ifdef __powerpc__
-#include "../../arch/powerpc/include/uapi/asm/unistd.h"
 #define CPUINFO_PROC   {"cpu"}
 #endif
 

[tip:perf/core] perf powerpc: Fix build-test failure

[tip-bot for Ravi Bangoria]

Commit-ID:  25b8592e912f085ce2ff736a2927584ddeab238c
Gitweb: http://git.kernel.org/tip/25b8592e912f085ce2ff736a2927584ddeab238c
Author: Ravi Bangoria 
AuthorDate: Wed, 31 Aug 2016 13:33:11 +0530
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 8 Sep 2016 13:44:07 -0300

perf powerpc: Fix build-test failure

'make -C tools/perf build-test' is failing with below log for poewrpc.

  In file included from 
/tmp/tmp.3eEwmGlYaF/perf-4.8.0-rc4/tools/perf/perf.h:15:0,
   from util/cpumap.h:8,
   from util/env.c:1:
  /tmp/tmp.3eEwmGlYaF/perf-4.8.0-rc4/tools/perf/perf-sys.h:23:56:
  fatal error: ../../arch/powerpc/include/uapi/asm/unistd.h: No such file or 
directory
  compilation terminated.

I bisected it and found it's failing from commit ad430729ae00 ("Remove:
kernel unistd*h files from perf's MANIFEST, not used").

Header file '../../arch/powerpc/include/uapi/asm/unistd.h' is included
only for powerpc in tools/perf/perf-sys.h.

By looking closly at commit history, I found little weird thing:

Commit f2d9cae9ea9e ("perf powerpc: Use uapi/unistd.h to fix build
error") replaced 'asm/unistd.h' with 'uapi/asm/unistd.h'

Commit d2709c7ce4c5 ("perf: Make perf build for x86 with UAPI
disintegration applied") removes all arch specific 'uapi/asm/unistd.h'
for all archs and adds generic .

Commit f0b9abfb0446 ("Merge branch 'linus' into perf/core") again
includes 'uapi/asm/unistd.h' for powerpc. Don't know how exactly this
happened as this change is not part of commit also.

Signed-off-by: Ravi Bangoria 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1472630591-5089-1-git-send-email-ravi.bango...@linux.vnet.ibm.com
Fixes: ad430729ae00 ("Remove: kernel unistd*h files from perf's MANIFEST, not 
used")
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/perf-sys.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/perf/perf-sys.h b/tools/perf/perf-sys.h
index 7ed72a4..e4b717e 100644
--- a/tools/perf/perf-sys.h
+++ b/tools/perf/perf-sys.h
@@ -20,7 +20,6 @@
 #endif
 
 #ifdef __powerpc__
-#include "../../arch/powerpc/include/uapi/asm/unistd.h"
 #define CPUINFO_PROC   {"cpu"}
 #endif
 

[tip:perf/core] perf pmu: Support alternative sysfs cpumask

[tip-bot for Mark Rutland]

Commit-ID:  7e3fcffe955440101493cd8f32f75840ddf87b6f
Gitweb: http://git.kernel.org/tip/7e3fcffe955440101493cd8f32f75840ddf87b6f
Author: Mark Rutland 
AuthorDate: Thu, 8 Sep 2016 11:21:52 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 8 Sep 2016 13:44:06 -0300

perf pmu: Support alternative sysfs cpumask

The perf tools can read a cpumask file for a PMU, describing a subset of
CPUs which that PMU covers. So far this has only been used to cater for
uncore PMUs, which in practice happen to only have a single CPU
described in the mask.

Until recently, the perf tools only correctly handled cpumask containing
a single CPU, and only when monitoring in system-wide mode. For example,
prior to commit 00e727bb389359c8 ("perf stat: Balance opening and
reading events"), a mask with more than a single CPU could cause perf
stat to hang. When a CPU PMU covers a subset of CPUs, but lacks a
cpumask, perf record will fail to open events (on the cores the PMU does
not support), and gives up.

For systems with heterogeneous CPUs such as ARM big.LITTLE systems, this
presents a problem. We have a PMU for each microarchitecture (e.g. a big
PMU and a little PMU), and would like to expose a cpumask for each (so
as to allow perf record and other tools to do the right thing). However,
doing so kernel-side will cause old perf binaries to not function (e.g.
hitting the issue solved by 00e727bb389359c8), and thus commits the
cardinal sin of breaking (existing) userspace.

To address this chicken-and-egg problem, this patch adds support got a
new file, cpus, which is largely identical to the existing cpumask file.
A kernel can expose this file, knowing that new perf binaries will
correctly support it, while old perf binaries will not look for it (and
thus will not be broken).

Signed-off-by: Mark Rutland 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Cc: Will Deacon 
Link: 
http://lkml.kernel.org/r/1473330112-28528-8-git-send-email-mark.rutl...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/pmu.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index ddb0261..2babcdf 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -445,14 +445,23 @@ static struct cpu_map *pmu_cpumask(const char *name)
FILE *file;
struct cpu_map *cpus;
const char *sysfs = sysfs__mountpoint();
+   const char *templates[] = {
+"%s/bus/event_source/devices/%s/cpumask",
+"%s/bus/event_source/devices/%s/cpus",
+NULL
+   };
+   const char **template;
 
if (!sysfs)
return NULL;
 
-   snprintf(path, PATH_MAX,
-"%s/bus/event_source/devices/%s/cpumask", sysfs, name);
+   for (template = templates; *template; template++) {
+   snprintf(path, PATH_MAX, *template, sysfs, name);
+   if (stat(path, ) == 0)
+   break;
+   }
 
-   if (stat(path, ) < 0)
+   if (!*template)
return NULL;
 
file = fopen(path, "r");

[tip:perf/core] perf pmu: Support alternative sysfs cpumask

[tip-bot for Mark Rutland]

Commit-ID:  7e3fcffe955440101493cd8f32f75840ddf87b6f
Gitweb: http://git.kernel.org/tip/7e3fcffe955440101493cd8f32f75840ddf87b6f
Author: Mark Rutland 
AuthorDate: Thu, 8 Sep 2016 11:21:52 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 8 Sep 2016 13:44:06 -0300

perf pmu: Support alternative sysfs cpumask

The perf tools can read a cpumask file for a PMU, describing a subset of
CPUs which that PMU covers. So far this has only been used to cater for
uncore PMUs, which in practice happen to only have a single CPU
described in the mask.

Until recently, the perf tools only correctly handled cpumask containing
a single CPU, and only when monitoring in system-wide mode. For example,
prior to commit 00e727bb389359c8 ("perf stat: Balance opening and
reading events"), a mask with more than a single CPU could cause perf
stat to hang. When a CPU PMU covers a subset of CPUs, but lacks a
cpumask, perf record will fail to open events (on the cores the PMU does
not support), and gives up.

For systems with heterogeneous CPUs such as ARM big.LITTLE systems, this
presents a problem. We have a PMU for each microarchitecture (e.g. a big
PMU and a little PMU), and would like to expose a cpumask for each (so
as to allow perf record and other tools to do the right thing). However,
doing so kernel-side will cause old perf binaries to not function (e.g.
hitting the issue solved by 00e727bb389359c8), and thus commits the
cardinal sin of breaking (existing) userspace.

To address this chicken-and-egg problem, this patch adds support got a
new file, cpus, which is largely identical to the existing cpumask file.
A kernel can expose this file, knowing that new perf binaries will
correctly support it, while old perf binaries will not look for it (and
thus will not be broken).

Signed-off-by: Mark Rutland 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Cc: Will Deacon 
Link: 
http://lkml.kernel.org/r/1473330112-28528-8-git-send-email-mark.rutl...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/pmu.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index ddb0261..2babcdf 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -445,14 +445,23 @@ static struct cpu_map *pmu_cpumask(const char *name)
FILE *file;
struct cpu_map *cpus;
const char *sysfs = sysfs__mountpoint();
+   const char *templates[] = {
+"%s/bus/event_source/devices/%s/cpumask",
+"%s/bus/event_source/devices/%s/cpus",
+NULL
+   };
+   const char **template;
 
if (!sysfs)
return NULL;
 
-   snprintf(path, PATH_MAX,
-"%s/bus/event_source/devices/%s/cpumask", sysfs, name);
+   for (template = templates; *template; template++) {
+   snprintf(path, PATH_MAX, *template, sysfs, name);
+   if (stat(path, ) == 0)
+   break;
+   }
 
-   if (stat(path, ) < 0)
+   if (!*template)
return NULL;
 
file = fopen(path, "r");

[tip:perf/core] perf evlist: Only open events on CPUs an evsel permits

[tip-bot for Mark Rutland]

Commit-ID:  9f21b815be863218192f42f9f5bf78b75f8738e0
Gitweb: http://git.kernel.org/tip/9f21b815be863218192f42f9f5bf78b75f8738e0
Author: Mark Rutland 
AuthorDate: Thu, 8 Sep 2016 11:21:51 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 8 Sep 2016 13:44:06 -0300

perf evlist: Only open events on CPUs an evsel permits

In systems with heterogeneous CPU PMUs, it's possible for each evsel to
cover a distinct set of CPUs, and hence the cpu_map associated with each
evsel may have a distinct idx<->id mapping. Any of these may be distinct
from the evlist's cpu map.

Events can be tied to the same fd so long as they use the same per-cpu
ringbuffer (i.e. so long as they are on the same CPU). To acquire the
correct FDs, we must compare the Linux logical IDs rather than the evsel
or evlist indices.

This path adds logic to perf_evlist__mmap_per_evsel to handle this,
translating IDs as required. As PMUs may cover a subset of CPUs from the
evlist, we skip the CPUs a PMU cannot handle.

Without this patch, perf record may try to mmap erroneous FDs on
heterogeneous systems, and will bail out early rather than running the
workload.

Signed-off-by: Mark Rutland 
Acked-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Cc: Will Deacon 
Link: 
http://lkml.kernel.org/r/1473330112-28528-7-git-send-email-mark.rutl...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evlist.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 097b3ed..ea34c5a 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1032,16 +1032,18 @@ perf_evlist__should_poll(struct perf_evlist *evlist 
__maybe_unused,
 }
 
 static int perf_evlist__mmap_per_evsel(struct perf_evlist *evlist, int idx,
-  struct mmap_params *mp, int cpu,
+  struct mmap_params *mp, int cpu_idx,
   int thread, int *_output, int 
*_output_backward)
 {
struct perf_evsel *evsel;
int revent;
+   int evlist_cpu = cpu_map__cpu(evlist->cpus, cpu_idx);
 
evlist__for_each_entry(evlist, evsel) {
struct perf_mmap *maps = evlist->mmap;
int *output = _output;
int fd;
+   int cpu;
 
if (evsel->attr.write_backward) {
output = _output_backward;
@@ -1060,6 +1062,10 @@ static int perf_evlist__mmap_per_evsel(struct 
perf_evlist *evlist, int idx,
if (evsel->system_wide && thread)
continue;
 
+   cpu = cpu_map__idx(evsel->cpus, evlist_cpu);
+   if (cpu == -1)
+   continue;
+
fd = FD(evsel, cpu, thread);
 
if (*output == -1) {

[tip:perf/core] perf evlist: Only open events on CPUs an evsel permits

[tip-bot for Mark Rutland]

Commit-ID:  9f21b815be863218192f42f9f5bf78b75f8738e0
Gitweb: http://git.kernel.org/tip/9f21b815be863218192f42f9f5bf78b75f8738e0
Author: Mark Rutland 
AuthorDate: Thu, 8 Sep 2016 11:21:51 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 8 Sep 2016 13:44:06 -0300

perf evlist: Only open events on CPUs an evsel permits

In systems with heterogeneous CPU PMUs, it's possible for each evsel to
cover a distinct set of CPUs, and hence the cpu_map associated with each
evsel may have a distinct idx<->id mapping. Any of these may be distinct
from the evlist's cpu map.

Events can be tied to the same fd so long as they use the same per-cpu
ringbuffer (i.e. so long as they are on the same CPU). To acquire the
correct FDs, we must compare the Linux logical IDs rather than the evsel
or evlist indices.

This path adds logic to perf_evlist__mmap_per_evsel to handle this,
translating IDs as required. As PMUs may cover a subset of CPUs from the
evlist, we skip the CPUs a PMU cannot handle.

Without this patch, perf record may try to mmap erroneous FDs on
heterogeneous systems, and will bail out early rather than running the
workload.

Signed-off-by: Mark Rutland 
Acked-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Cc: Will Deacon 
Link: 
http://lkml.kernel.org/r/1473330112-28528-7-git-send-email-mark.rutl...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evlist.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 097b3ed..ea34c5a 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1032,16 +1032,18 @@ perf_evlist__should_poll(struct perf_evlist *evlist 
__maybe_unused,
 }
 
 static int perf_evlist__mmap_per_evsel(struct perf_evlist *evlist, int idx,
-  struct mmap_params *mp, int cpu,
+  struct mmap_params *mp, int cpu_idx,
   int thread, int *_output, int 
*_output_backward)
 {
struct perf_evsel *evsel;
int revent;
+   int evlist_cpu = cpu_map__cpu(evlist->cpus, cpu_idx);
 
evlist__for_each_entry(evlist, evsel) {
struct perf_mmap *maps = evlist->mmap;
int *output = _output;
int fd;
+   int cpu;
 
if (evsel->attr.write_backward) {
output = _output_backward;
@@ -1060,6 +1062,10 @@ static int perf_evlist__mmap_per_evsel(struct 
perf_evlist *evlist, int idx,
if (evsel->system_wide && thread)
continue;
 
+   cpu = cpu_map__idx(evsel->cpus, evlist_cpu);
+   if (cpu == -1)
+   continue;
+
fd = FD(evsel, cpu, thread);
 
if (*output == -1) {

[tip:perf/core] tools lib api fs: Add hugetlbfs filesystem detector

[tip-bot for Wang Nan]

Commit-ID:  5e7be3e1f9d71ed03fac27df25e143815be662d2
Gitweb: http://git.kernel.org/tip/5e7be3e1f9d71ed03fac27df25e143815be662d2
Author: Wang Nan 
AuthorDate: Tue, 6 Sep 2016 04:58:28 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 8 Sep 2016 12:34:43 -0300

tools lib api fs: Add hugetlbfs filesystem detector

Detect hugetlbfs. hugetlbfs__mountpoint() will be used during recording
to help identifying hugetlb mmaps: which should be recognized as anon
mapping.

Signed-off-by: Wang Nan 
Reviewed-by: Nilay Vaish 
Cc: He Kuang 
Cc: Hou Pengyang 
Cc: Zefan Li 
Link: 
http://lkml.kernel.org/r/1473137909-142064-3-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/api/fs/fs.c | 15 +++
 tools/lib/api/fs/fs.h |  1 +
 2 files changed, 16 insertions(+)

diff --git a/tools/lib/api/fs/fs.c b/tools/lib/api/fs/fs.c
index ba7094b..f99f49e4 100644
--- a/tools/lib/api/fs/fs.c
+++ b/tools/lib/api/fs/fs.c
@@ -34,6 +34,10 @@
 #define TRACEFS_MAGIC  0x74726163
 #endif
 
+#ifndef HUGETLBFS_MAGIC
+#define HUGETLBFS_MAGIC0x958458f6
+#endif
+
 static const char * const sysfs__fs_known_mountpoints[] = {
"/sys",
0,
@@ -67,6 +71,10 @@ static const char * const tracefs__known_mountpoints[] = {
0,
 };
 
+static const char * const hugetlbfs__known_mountpoints[] = {
+   0,
+};
+
 struct fs {
const char  *name;
const char * const  *mounts;
@@ -80,6 +88,7 @@ enum {
FS__PROCFS  = 1,
FS__DEBUGFS = 2,
FS__TRACEFS = 3,
+   FS__HUGETLBFS = 4,
 };
 
 #ifndef TRACEFS_MAGIC
@@ -107,6 +116,11 @@ static struct fs fs__entries[] = {
.mounts = tracefs__known_mountpoints,
.magic  = TRACEFS_MAGIC,
},
+   [FS__HUGETLBFS] = {
+   .name   = "hugetlbfs",
+   .mounts = hugetlbfs__known_mountpoints,
+   .magic  = HUGETLBFS_MAGIC,
+   },
 };
 
 static bool fs__read_mounts(struct fs *fs)
@@ -265,6 +279,7 @@ FS(sysfs,   FS__SYSFS);
 FS(procfs,  FS__PROCFS);
 FS(debugfs, FS__DEBUGFS);
 FS(tracefs, FS__TRACEFS);
+FS(hugetlbfs, FS__HUGETLBFS);
 
 int filename__read_int(const char *filename, int *value)
 {
diff --git a/tools/lib/api/fs/fs.h b/tools/lib/api/fs/fs.h
index 16c9c2e..a63269f 100644
--- a/tools/lib/api/fs/fs.h
+++ b/tools/lib/api/fs/fs.h
@@ -21,6 +21,7 @@ FS(sysfs)
 FS(procfs)
 FS(debugfs)
 FS(tracefs)
+FS(hugetlbfs)
 
 #undef FS
 

[PATCH 1/1] Drivers: hv: hv_util: Avoid dynamic allocation in time synch

[kys]

From: Vivek yadav 

Under stress, we have seen allocation failure in time synch code. Avoid
this dynamic allocation.

Signed-off-by: Vivek Yadav 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_util.c |   39 ---
 1 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 6286bdc..4aa3cb6 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -64,9 +64,14 @@ static struct hv_util_service util_shutdown = {
.util_cb = shutdown_onchannelcallback,
 };
 
+static int hv_timesync_init(struct hv_util_service *srv);
+static void hv_timesync_deinit(void);
+
 static void timesync_onchannelcallback(void *context);
 static struct hv_util_service util_timesynch = {
.util_cb = timesync_onchannelcallback,
+   .util_init = hv_timesync_init,
+   .util_deinit = hv_timesync_deinit,
 };
 
 static void heartbeat_onchannelcallback(void *context);
@@ -201,7 +206,6 @@ static void hv_set_host_time(struct work_struct *work)
host_ts = ns_to_timespec(host_tns);
 
do_settimeofday(_ts);
-   kfree(wrk);
 }
 
 /*
@@ -217,22 +221,24 @@ static void hv_set_host_time(struct work_struct *work)
  * typically used as a hint to the guest. The guest is under no obligation
  * to discipline the clock.
  */
+static struct adj_time_work  wrk;
 static inline void adj_guesttime(u64 hosttime, u64 reftime, u8 flags)
 {
-   struct adj_time_work*wrk;
 
-   wrk = kmalloc(sizeof(struct adj_time_work), GFP_ATOMIC);
-   if (wrk == NULL)
+   /*
+* This check is safe since we are executing in the
+* interrupt context and time synch messages arre always
+* delivered on the same CPU.
+*/
+   if (work_pending())
return;
 
-   wrk->host_time = hosttime;
-   wrk->ref_time = reftime;
-   wrk->flags = flags;
+   wrk.host_time = hosttime;
+   wrk.ref_time = reftime;
+   wrk.flags = flags;
if ((flags & (ICTIMESYNCFLAG_SYNC | ICTIMESYNCFLAG_SAMPLE)) != 0) {
-   INIT_WORK(>work, hv_set_host_time);
-   schedule_work(>work);
-   } else
-   kfree(wrk);
+   schedule_work();
+   }
 }
 
 /*
@@ -457,6 +463,17 @@ static  struct hv_driver util_drv = {
.remove =  util_remove,
 };
 
+static int hv_timesync_init(struct hv_util_service *srv)
+{
+   INIT_WORK(, hv_set_host_time);
+   return 0;
+}
+
+static void hv_timesync_deinit(void)
+{
+   cancel_work_sync();
+}
+
 static int __init init_hyperv_utils(void)
 {
pr_info("Registering HyperV Utility Driver\n");
-- 
1.7.4.1

[tip:perf/core] perf record: Mark MAP_HUGETLB when synthesizing mmap events

[tip-bot for Wang Nan]

Commit-ID:  d7e404af115bb4996afa4a0236020969ab007554
Gitweb: http://git.kernel.org/tip/d7e404af115bb4996afa4a0236020969ab007554
Author: Wang Nan 
AuthorDate: Tue, 6 Sep 2016 04:58:29 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 8 Sep 2016 12:36:01 -0300

perf record: Mark MAP_HUGETLB when synthesizing mmap events

When synthesizing mmap events, add MAP_HUGETLB map flag if the source of
mapping is file in hugetlbfs.

After this patch, perf can identify hugetlb mapping even if perf is
started after the mapping of huge pages (like with 'perf top').

Signed-off-by: Wang Nan 
Reviewed-by: Nilay Vaish 
Cc: He Kuang 
Cc: Hou Pengyang 
Cc: Zefan Li 
Link: 
http://lkml.kernel.org/r/1473137909-142064-4-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/event.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 9ad7d32..6c30171 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 #include "event.h"
 #include "debug.h"
 #include "hist.h"
@@ -248,6 +249,10 @@ int perf_event__synthesize_mmap_events(struct perf_tool 
*tool,
bool truncation = false;
unsigned long long timeout = proc_map_timeout * 100ULL;
int rc = 0;
+#ifdef MAP_HUGETLB
+   const char *hugetlbfs_mnt = hugetlbfs__mountpoint();
+   int hugetlbfs_mnt_len = hugetlbfs_mnt ? strlen(hugetlbfs_mnt) : 0;
+#endif
 
if (machine__is_default_guest(machine))
return 0;
@@ -342,6 +347,12 @@ out:
 
if (!strcmp(execname, ""))
strcpy(execname, anonstr);
+#ifdef MAP_HUGETLB
+   if (!strncmp(execname, hugetlbfs_mnt, hugetlbfs_mnt_len)) {
+   strcpy(execname, anonstr);
+   event->mmap2.flags |= MAP_HUGETLB;
+   }
+#endif
 
size = strlen(execname) + 1;
memcpy(event->mmap2.filename, execname, size);

[tip:perf/core] tools lib api fs: Add hugetlbfs filesystem detector

[tip-bot for Wang Nan]

Commit-ID:  5e7be3e1f9d71ed03fac27df25e143815be662d2
Gitweb: http://git.kernel.org/tip/5e7be3e1f9d71ed03fac27df25e143815be662d2
Author: Wang Nan 
AuthorDate: Tue, 6 Sep 2016 04:58:28 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 8 Sep 2016 12:34:43 -0300

tools lib api fs: Add hugetlbfs filesystem detector

Detect hugetlbfs. hugetlbfs__mountpoint() will be used during recording
to help identifying hugetlb mmaps: which should be recognized as anon
mapping.

Signed-off-by: Wang Nan 
Reviewed-by: Nilay Vaish 
Cc: He Kuang 
Cc: Hou Pengyang 
Cc: Zefan Li 
Link: 
http://lkml.kernel.org/r/1473137909-142064-3-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/api/fs/fs.c | 15 +++
 tools/lib/api/fs/fs.h |  1 +
 2 files changed, 16 insertions(+)

diff --git a/tools/lib/api/fs/fs.c b/tools/lib/api/fs/fs.c
index ba7094b..f99f49e4 100644
--- a/tools/lib/api/fs/fs.c
+++ b/tools/lib/api/fs/fs.c
@@ -34,6 +34,10 @@
 #define TRACEFS_MAGIC  0x74726163
 #endif
 
+#ifndef HUGETLBFS_MAGIC
+#define HUGETLBFS_MAGIC0x958458f6
+#endif
+
 static const char * const sysfs__fs_known_mountpoints[] = {
"/sys",
0,
@@ -67,6 +71,10 @@ static const char * const tracefs__known_mountpoints[] = {
0,
 };
 
+static const char * const hugetlbfs__known_mountpoints[] = {
+   0,
+};
+
 struct fs {
const char  *name;
const char * const  *mounts;
@@ -80,6 +88,7 @@ enum {
FS__PROCFS  = 1,
FS__DEBUGFS = 2,
FS__TRACEFS = 3,
+   FS__HUGETLBFS = 4,
 };
 
 #ifndef TRACEFS_MAGIC
@@ -107,6 +116,11 @@ static struct fs fs__entries[] = {
.mounts = tracefs__known_mountpoints,
.magic  = TRACEFS_MAGIC,
},
+   [FS__HUGETLBFS] = {
+   .name   = "hugetlbfs",
+   .mounts = hugetlbfs__known_mountpoints,
+   .magic  = HUGETLBFS_MAGIC,
+   },
 };
 
 static bool fs__read_mounts(struct fs *fs)
@@ -265,6 +279,7 @@ FS(sysfs,   FS__SYSFS);
 FS(procfs,  FS__PROCFS);
 FS(debugfs, FS__DEBUGFS);
 FS(tracefs, FS__TRACEFS);
+FS(hugetlbfs, FS__HUGETLBFS);
 
 int filename__read_int(const char *filename, int *value)
 {
diff --git a/tools/lib/api/fs/fs.h b/tools/lib/api/fs/fs.h
index 16c9c2e..a63269f 100644
--- a/tools/lib/api/fs/fs.h
+++ b/tools/lib/api/fs/fs.h
@@ -21,6 +21,7 @@ FS(sysfs)
 FS(procfs)
 FS(debugfs)
 FS(tracefs)
+FS(hugetlbfs)
 
 #undef FS
 

[PATCH 1/1] Drivers: hv: hv_util: Avoid dynamic allocation in time synch

[kys]

From: Vivek yadav 

Under stress, we have seen allocation failure in time synch code. Avoid
this dynamic allocation.

Signed-off-by: Vivek Yadav 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_util.c |   39 ---
 1 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 6286bdc..4aa3cb6 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -64,9 +64,14 @@ static struct hv_util_service util_shutdown = {
.util_cb = shutdown_onchannelcallback,
 };
 
+static int hv_timesync_init(struct hv_util_service *srv);
+static void hv_timesync_deinit(void);
+
 static void timesync_onchannelcallback(void *context);
 static struct hv_util_service util_timesynch = {
.util_cb = timesync_onchannelcallback,
+   .util_init = hv_timesync_init,
+   .util_deinit = hv_timesync_deinit,
 };
 
 static void heartbeat_onchannelcallback(void *context);
@@ -201,7 +206,6 @@ static void hv_set_host_time(struct work_struct *work)
host_ts = ns_to_timespec(host_tns);
 
do_settimeofday(_ts);
-   kfree(wrk);
 }
 
 /*
@@ -217,22 +221,24 @@ static void hv_set_host_time(struct work_struct *work)
  * typically used as a hint to the guest. The guest is under no obligation
  * to discipline the clock.
  */
+static struct adj_time_work  wrk;
 static inline void adj_guesttime(u64 hosttime, u64 reftime, u8 flags)
 {
-   struct adj_time_work*wrk;
 
-   wrk = kmalloc(sizeof(struct adj_time_work), GFP_ATOMIC);
-   if (wrk == NULL)
+   /*
+* This check is safe since we are executing in the
+* interrupt context and time synch messages arre always
+* delivered on the same CPU.
+*/
+   if (work_pending())
return;
 
-   wrk->host_time = hosttime;
-   wrk->ref_time = reftime;
-   wrk->flags = flags;
+   wrk.host_time = hosttime;
+   wrk.ref_time = reftime;
+   wrk.flags = flags;
if ((flags & (ICTIMESYNCFLAG_SYNC | ICTIMESYNCFLAG_SAMPLE)) != 0) {
-   INIT_WORK(>work, hv_set_host_time);
-   schedule_work(>work);
-   } else
-   kfree(wrk);
+   schedule_work();
+   }
 }
 
 /*
@@ -457,6 +463,17 @@ static  struct hv_driver util_drv = {
.remove =  util_remove,
 };
 
+static int hv_timesync_init(struct hv_util_service *srv)
+{
+   INIT_WORK(, hv_set_host_time);
+   return 0;
+}
+
+static void hv_timesync_deinit(void)
+{
+   cancel_work_sync();
+}
+
 static int __init init_hyperv_utils(void)
 {
pr_info("Registering HyperV Utility Driver\n");
-- 
1.7.4.1

[tip:perf/core] perf record: Mark MAP_HUGETLB when synthesizing mmap events

[tip-bot for Wang Nan]

Commit-ID:  d7e404af115bb4996afa4a0236020969ab007554
Gitweb: http://git.kernel.org/tip/d7e404af115bb4996afa4a0236020969ab007554
Author: Wang Nan 
AuthorDate: Tue, 6 Sep 2016 04:58:29 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 8 Sep 2016 12:36:01 -0300

perf record: Mark MAP_HUGETLB when synthesizing mmap events

When synthesizing mmap events, add MAP_HUGETLB map flag if the source of
mapping is file in hugetlbfs.

After this patch, perf can identify hugetlb mapping even if perf is
started after the mapping of huge pages (like with 'perf top').

Signed-off-by: Wang Nan 
Reviewed-by: Nilay Vaish 
Cc: He Kuang 
Cc: Hou Pengyang 
Cc: Zefan Li 
Link: 
http://lkml.kernel.org/r/1473137909-142064-4-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/event.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 9ad7d32..6c30171 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 #include "event.h"
 #include "debug.h"
 #include "hist.h"
@@ -248,6 +249,10 @@ int perf_event__synthesize_mmap_events(struct perf_tool 
*tool,
bool truncation = false;
unsigned long long timeout = proc_map_timeout * 100ULL;
int rc = 0;
+#ifdef MAP_HUGETLB
+   const char *hugetlbfs_mnt = hugetlbfs__mountpoint();
+   int hugetlbfs_mnt_len = hugetlbfs_mnt ? strlen(hugetlbfs_mnt) : 0;
+#endif
 
if (machine__is_default_guest(machine))
return 0;
@@ -342,6 +347,12 @@ out:
 
if (!strcmp(execname, ""))
strcpy(execname, anonstr);
+#ifdef MAP_HUGETLB
+   if (!strncmp(execname, hugetlbfs_mnt, hugetlbfs_mnt_len)) {
+   strcpy(execname, anonstr);
+   event->mmap2.flags |= MAP_HUGETLB;
+   }
+#endif
 
size = strlen(execname) + 1;
memcpy(event->mmap2.filename, execname, size);

[tip:perf/core] perf symbols: Remove symbol_filter_t machinery

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  be39db9f2932f0ce4e116c71ba5ae2b542e536a7
Gitweb: http://git.kernel.org/tip/be39db9f2932f0ce4e116c71ba5ae2b542e536a7
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 1 Sep 2016 19:25:52 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 5 Sep 2016 11:14:50 -0300

perf symbols: Remove symbol_filter_t machinery

We're not using it anymore, few users were, but we really could do
without it, simplify lots of functions by removing it.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-1zng8wdznn00iiz08bb7q...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/powerpc/util/sym-handling.c |   2 +-
 tools/perf/builtin-inject.c |   2 +-
 tools/perf/builtin-kmem.c   |  10 ++-
 tools/perf/builtin-script.c |   4 +-
 tools/perf/tests/code-reading.c |   4 +-
 tools/perf/tests/vmlinux-kallsyms.c |   8 +--
 tools/perf/ui/browsers/annotate.c   |   2 +-
 tools/perf/ui/browsers/map.c|   4 +-
 tools/perf/util/annotate.c  |   2 +-
 tools/perf/util/event.c |   8 +--
 tools/perf/util/intel-bts.c |   2 +-
 tools/perf/util/intel-pt.c  |   4 +-
 tools/perf/util/machine.c   |  19 +++---
 tools/perf/util/machine.h   |  30 +++-
 tools/perf/util/map.c   |  37 --
 tools/perf/util/map.h   |  32 -
 tools/perf/util/probe-event.c   |  17 +++--
 tools/perf/util/symbol-elf.c|  32 +++--
 tools/perf/util/symbol-minimal.c|   4 +-
 tools/perf/util/symbol.c| 102 
 tools/perf/util/symbol.h|  18 ++---
 21 files changed, 141 insertions(+), 202 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 35745a7..ed9d5d1 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -108,7 +108,7 @@ void arch__post_process_probe_trace_events(struct 
perf_probe_event *pev,
int i = 0;
 
map = get_target_map(pev->target, pev->uprobes);
-   if (!map || map__load(map, NULL) < 0)
+   if (!map || map__load(map) < 0)
return;
 
for (i = 0; i < ntevs; i++) {
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 73c1c4c..b9bc7e3 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -429,7 +429,7 @@ static int perf_event__inject_buildid(struct perf_tool 
*tool,
if (al.map != NULL) {
if (!al.map->dso->hit) {
al.map->dso->hit = 1;
-   if (map__load(al.map, NULL) >= 0) {
+   if (map__load(al.map) >= 0) {
dso__inject_build_id(al.map->dso, tool, 
machine);
/*
 * If this fails, too bad, let the other side
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index fdde1bd..d426dcb 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -330,7 +330,7 @@ static int build_alloc_func_list(void)
}
 
kernel_map = machine__kernel_map(machine);
-   if (map__load(kernel_map, NULL) < 0) {
+   if (map__load(kernel_map) < 0) {
pr_err("cannot load kernel map\n");
return -ENOENT;
}
@@ -979,7 +979,7 @@ static void __print_slab_result(struct rb_root *root,
if (is_caller) {
addr = data->call_site;
if (!raw_ip)
-   sym = machine__find_kernel_function(machine, 
addr, , NULL);
+   sym = machine__find_kernel_function(machine, 
addr, );
} else
addr = data->ptr;
 
@@ -1043,8 +1043,7 @@ static void __print_page_alloc_result(struct perf_session 
*session, int n_lines)
char *caller = buf;
 
data = rb_entry(next, struct page_stat, node);
-   sym = machine__find_kernel_function(machine, data->callsite,
-   , NULL);
+   sym = machine__find_kernel_function(machine, data->callsite, 
);
if (sym && sym->name)
caller = sym->name;
else
@@ -1086,8 +1085,7 @@ static void __print_page_caller_result(struct 
perf_session *session, int n_lines
char *caller = buf;
 
data = rb_entry(next, struct page_stat, node);
-   

[tip:perf/core] perf tools: Recognize hugetlb mapping as anon mapping

[tip-bot for Wang Nan]

Commit-ID:  0ac3348e502423cf2fe86beca83b8835a2e6d289
Gitweb: http://git.kernel.org/tip/0ac3348e502423cf2fe86beca83b8835a2e6d289
Author: Wang Nan 
AuthorDate: Tue, 6 Sep 2016 04:58:27 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 8 Sep 2016 12:28:06 -0300

perf tools: Recognize hugetlb mapping as anon mapping

Hugetlbfs mapping should be recognized as anon mapping so user has a
chance to create /tmp/perf-.map file for symbol resolving. This
patch utilizes MAP_HUGETLB to identify hugetlb mapping.

After this patch, if perf is started before a program starts using huge
pages (so perf gets MMAP2 events from kernel), perf is able to recognize
hugetlb mapping as anon mapping.

Signed-off-by: Wang Nan 
Cc: He Kuang 
Cc: Nilay Vaish 
Cc: Zefan Li 
Link: 
http://lkml.kernel.org/r/1473137909-142064-2-git-send-email-wangn...@huawei.com
Signed-off-by: Hou Pengyang 
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/map.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 0c54adb..d51a125 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "map.h"
 #include "thread.h"
 #include "strlist.h"
@@ -24,9 +25,15 @@ const char *map_type__name[MAP__NR_TYPES] = {
[MAP__VARIABLE] = "Variables",
 };
 
-static inline int is_anon_memory(const char *filename)
+static inline int is_anon_memory(const char *filename, u32 flags)
 {
-   return !strcmp(filename, "//anon") ||
+   u32 anon_flags = 0;
+
+#ifdef MAP_HUGETLB
+   anon_flags |= MAP_HUGETLB;
+#endif
+   return flags & anon_flags ||
+  !strcmp(filename, "//anon") ||
   !strncmp(filename, "/dev/zero", sizeof("/dev/zero") - 1) ||
   !strncmp(filename, "/anon_hugepage", sizeof("/anon_hugepage") - 
1);
 }
@@ -155,7 +162,7 @@ struct map *map__new(struct machine *machine, u64 start, 
u64 len,
int anon, no_dso, vdso, android;
 
android = is_android_lib(filename);
-   anon = is_anon_memory(filename);
+   anon = is_anon_memory(filename, flags);
vdso = is_vdso_map(filename);
no_dso = is_no_dso_memory(filename);
 

[tip:perf/core] perf symbols: Remove symbol_filter_t machinery

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  be39db9f2932f0ce4e116c71ba5ae2b542e536a7
Gitweb: http://git.kernel.org/tip/be39db9f2932f0ce4e116c71ba5ae2b542e536a7
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 1 Sep 2016 19:25:52 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 5 Sep 2016 11:14:50 -0300

perf symbols: Remove symbol_filter_t machinery

We're not using it anymore, few users were, but we really could do
without it, simplify lots of functions by removing it.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-1zng8wdznn00iiz08bb7q...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/powerpc/util/sym-handling.c |   2 +-
 tools/perf/builtin-inject.c |   2 +-
 tools/perf/builtin-kmem.c   |  10 ++-
 tools/perf/builtin-script.c |   4 +-
 tools/perf/tests/code-reading.c |   4 +-
 tools/perf/tests/vmlinux-kallsyms.c |   8 +--
 tools/perf/ui/browsers/annotate.c   |   2 +-
 tools/perf/ui/browsers/map.c|   4 +-
 tools/perf/util/annotate.c  |   2 +-
 tools/perf/util/event.c |   8 +--
 tools/perf/util/intel-bts.c |   2 +-
 tools/perf/util/intel-pt.c  |   4 +-
 tools/perf/util/machine.c   |  19 +++---
 tools/perf/util/machine.h   |  30 +++-
 tools/perf/util/map.c   |  37 --
 tools/perf/util/map.h   |  32 -
 tools/perf/util/probe-event.c   |  17 +++--
 tools/perf/util/symbol-elf.c|  32 +++--
 tools/perf/util/symbol-minimal.c|   4 +-
 tools/perf/util/symbol.c| 102 
 tools/perf/util/symbol.h|  18 ++---
 21 files changed, 141 insertions(+), 202 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 35745a7..ed9d5d1 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -108,7 +108,7 @@ void arch__post_process_probe_trace_events(struct 
perf_probe_event *pev,
int i = 0;
 
map = get_target_map(pev->target, pev->uprobes);
-   if (!map || map__load(map, NULL) < 0)
+   if (!map || map__load(map) < 0)
return;
 
for (i = 0; i < ntevs; i++) {
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 73c1c4c..b9bc7e3 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -429,7 +429,7 @@ static int perf_event__inject_buildid(struct perf_tool 
*tool,
if (al.map != NULL) {
if (!al.map->dso->hit) {
al.map->dso->hit = 1;
-   if (map__load(al.map, NULL) >= 0) {
+   if (map__load(al.map) >= 0) {
dso__inject_build_id(al.map->dso, tool, 
machine);
/*
 * If this fails, too bad, let the other side
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index fdde1bd..d426dcb 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -330,7 +330,7 @@ static int build_alloc_func_list(void)
}
 
kernel_map = machine__kernel_map(machine);
-   if (map__load(kernel_map, NULL) < 0) {
+   if (map__load(kernel_map) < 0) {
pr_err("cannot load kernel map\n");
return -ENOENT;
}
@@ -979,7 +979,7 @@ static void __print_slab_result(struct rb_root *root,
if (is_caller) {
addr = data->call_site;
if (!raw_ip)
-   sym = machine__find_kernel_function(machine, 
addr, , NULL);
+   sym = machine__find_kernel_function(machine, 
addr, );
} else
addr = data->ptr;
 
@@ -1043,8 +1043,7 @@ static void __print_page_alloc_result(struct perf_session 
*session, int n_lines)
char *caller = buf;
 
data = rb_entry(next, struct page_stat, node);
-   sym = machine__find_kernel_function(machine, data->callsite,
-   , NULL);
+   sym = machine__find_kernel_function(machine, data->callsite, 
);
if (sym && sym->name)
caller = sym->name;
else
@@ -1086,8 +1085,7 @@ static void __print_page_caller_result(struct 
perf_session *session, int n_lines
char *caller = buf;
 
data = rb_entry(next, struct page_stat, node);
-   sym = machine__find_kernel_function(machine, data->callsite,
-   , NULL);
+   sym = 

[tip:perf/core] perf tools: Recognize hugetlb mapping as anon mapping

[tip-bot for Wang Nan]

Commit-ID:  0ac3348e502423cf2fe86beca83b8835a2e6d289
Gitweb: http://git.kernel.org/tip/0ac3348e502423cf2fe86beca83b8835a2e6d289
Author: Wang Nan 
AuthorDate: Tue, 6 Sep 2016 04:58:27 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 8 Sep 2016 12:28:06 -0300

perf tools: Recognize hugetlb mapping as anon mapping

Hugetlbfs mapping should be recognized as anon mapping so user has a
chance to create /tmp/perf-.map file for symbol resolving. This
patch utilizes MAP_HUGETLB to identify hugetlb mapping.

After this patch, if perf is started before a program starts using huge
pages (so perf gets MMAP2 events from kernel), perf is able to recognize
hugetlb mapping as anon mapping.

Signed-off-by: Wang Nan 
Cc: He Kuang 
Cc: Nilay Vaish 
Cc: Zefan Li 
Link: 
http://lkml.kernel.org/r/1473137909-142064-2-git-send-email-wangn...@huawei.com
Signed-off-by: Hou Pengyang 
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/map.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 0c54adb..d51a125 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "map.h"
 #include "thread.h"
 #include "strlist.h"
@@ -24,9 +25,15 @@ const char *map_type__name[MAP__NR_TYPES] = {
[MAP__VARIABLE] = "Variables",
 };
 
-static inline int is_anon_memory(const char *filename)
+static inline int is_anon_memory(const char *filename, u32 flags)
 {
-   return !strcmp(filename, "//anon") ||
+   u32 anon_flags = 0;
+
+#ifdef MAP_HUGETLB
+   anon_flags |= MAP_HUGETLB;
+#endif
+   return flags & anon_flags ||
+  !strcmp(filename, "//anon") ||
   !strncmp(filename, "/dev/zero", sizeof("/dev/zero") - 1) ||
   !strncmp(filename, "/anon_hugepage", sizeof("/anon_hugepage") - 
1);
 }
@@ -155,7 +162,7 @@ struct map *map__new(struct machine *machine, u64 start, 
u64 len,
int anon, no_dso, vdso, android;
 
android = is_android_lib(filename);
-   anon = is_anon_memory(filename);
+   anon = is_anon_memory(filename, flags);
vdso = is_vdso_map(filename);
no_dso = is_no_dso_memory(filename);
 

[tip:perf/core] perf test vmlinux: Remove dead symbol_filter_t code

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  c79c809197bf4faaf109d1a7bdc27ecedac375de
Gitweb: http://git.kernel.org/tip/c79c809197bf4faaf109d1a7bdc27ecedac375de
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 1 Sep 2016 19:22:02 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 5 Sep 2016 11:14:50 -0300

perf test vmlinux: Remove dead symbol_filter_t code

We don't need to initialize that area as we're not using it afterwards,
leftover, ditch it.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-jb2un8buy4rqawz73mcdm...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/vmlinux-kallsyms.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/tools/perf/tests/vmlinux-kallsyms.c 
b/tools/perf/tests/vmlinux-kallsyms.c
index 77513bf..e6925d6 100644
--- a/tools/perf/tests/vmlinux-kallsyms.c
+++ b/tools/perf/tests/vmlinux-kallsyms.c
@@ -8,14 +8,6 @@
 #include "debug.h"
 #include "machine.h"
 
-static int vmlinux_matches_kallsyms_filter(struct map *map __maybe_unused,
-  struct symbol *sym)
-{
-   bool *visited = symbol__priv(sym);
-   *visited = true;
-   return 0;
-}
-
 #define UM(x) kallsyms_map->unmap_ip(kallsyms_map, (x))
 
 int test__vmlinux_matches_kallsyms(int subtest __maybe_unused)
@@ -100,8 +92,7 @@ int test__vmlinux_matches_kallsyms(int subtest 
__maybe_unused)
 * maps__reloc_vmlinux will notice and set proper ->[un]map_ip routines
 * to fixup the symbols.
 */
-   if (machine__load_vmlinux_path(, type,
-  vmlinux_matches_kallsyms_filter) <= 0) {
+   if (machine__load_vmlinux_path(, type, NULL) <= 0) {
pr_debug("Couldn't find a vmlinux that matches the kernel 
running on this machine, skipping test\n");
err = TEST_SKIP;
goto out;

[tip:perf/core] perf test vmlinux: Remove dead symbol_filter_t code

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  c79c809197bf4faaf109d1a7bdc27ecedac375de
Gitweb: http://git.kernel.org/tip/c79c809197bf4faaf109d1a7bdc27ecedac375de
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 1 Sep 2016 19:22:02 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 5 Sep 2016 11:14:50 -0300

perf test vmlinux: Remove dead symbol_filter_t code

We don't need to initialize that area as we're not using it afterwards,
leftover, ditch it.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-jb2un8buy4rqawz73mcdm...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/vmlinux-kallsyms.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/tools/perf/tests/vmlinux-kallsyms.c 
b/tools/perf/tests/vmlinux-kallsyms.c
index 77513bf..e6925d6 100644
--- a/tools/perf/tests/vmlinux-kallsyms.c
+++ b/tools/perf/tests/vmlinux-kallsyms.c
@@ -8,14 +8,6 @@
 #include "debug.h"
 #include "machine.h"
 
-static int vmlinux_matches_kallsyms_filter(struct map *map __maybe_unused,
-  struct symbol *sym)
-{
-   bool *visited = symbol__priv(sym);
-   *visited = true;
-   return 0;
-}
-
 #define UM(x) kallsyms_map->unmap_ip(kallsyms_map, (x))
 
 int test__vmlinux_matches_kallsyms(int subtest __maybe_unused)
@@ -100,8 +92,7 @@ int test__vmlinux_matches_kallsyms(int subtest 
__maybe_unused)
 * maps__reloc_vmlinux will notice and set proper ->[un]map_ip routines
 * to fixup the symbols.
 */
-   if (machine__load_vmlinux_path(, type,
-  vmlinux_matches_kallsyms_filter) <= 0) {
+   if (machine__load_vmlinux_path(, type, NULL) <= 0) {
pr_debug("Couldn't find a vmlinux that matches the kernel 
running on this machine, skipping test\n");
err = TEST_SKIP;
goto out;

[tip:perf/core] perf machine: Remove machine->symbol_filter and friends

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  0890e97c20333c439a9bda6a94dd16ed5f508429
Gitweb: http://git.kernel.org/tip/0890e97c20333c439a9bda6a94dd16ed5f508429
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 1 Sep 2016 18:53:58 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 5 Sep 2016 11:14:50 -0300

perf machine: Remove machine->symbol_filter and friends

Including machines__set_symbol_filter(), not used anymore.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-7o1qgmrpvzuis4a9f0t8m...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/event.c |  8 +++-
 tools/perf/util/intel-bts.c |  2 +-
 tools/perf/util/intel-pt.c  |  4 ++--
 tools/perf/util/machine.c   | 21 +
 tools/perf/util/machine.h   |  4 
 5 files changed, 7 insertions(+), 32 deletions(-)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index e20438b..2f91183 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1286,7 +1286,7 @@ try_again:
 * must be done prior to using kernel maps.
 */
if (load_map)
-   map__load(al->map, machine->symbol_filter);
+   map__load(al->map, NULL);
al->addr = al->map->map_ip(al->map, al->addr);
}
 }
@@ -1297,8 +1297,7 @@ void thread__find_addr_location(struct thread *thread,
 {
thread__find_addr_map(thread, cpumode, type, addr, al);
if (al->map != NULL)
-   al->sym = map__find_symbol(al->map, al->addr,
-  thread->mg->machine->symbol_filter);
+   al->sym = map__find_symbol(al->map, al->addr, NULL);
else
al->sym = NULL;
 }
@@ -1359,8 +1358,7 @@ int machine__resolve(struct machine *machine, struct 
addr_location *al,
al->filtered |= (1 << HIST_FILTER__DSO);
}
 
-   al->sym = map__find_symbol(al->map, al->addr,
-  machine->symbol_filter);
+   al->sym = map__find_symbol(al->map, al->addr, NULL);
}
 
if (symbol_conf.sym_list &&
diff --git a/tools/perf/util/intel-bts.c b/tools/perf/util/intel-bts.c
index 749e6f2..240b095 100644
--- a/tools/perf/util/intel-bts.c
+++ b/tools/perf/util/intel-bts.c
@@ -346,7 +346,7 @@ static int intel_bts_get_next_insn(struct intel_bts_queue 
*btsq, u64 ip)
goto out_put;
 
/* Load maps to ensure dso->is_64_bit has been updated */
-   map__load(al.map, machine->symbol_filter);
+   map__load(al.map, NULL);
 
x86_64 = al.map->dso->is_64_bit;
 
diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index 551ff6f..d594052 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -477,7 +477,7 @@ static int intel_pt_walk_next_insn(struct intel_pt_insn 
*intel_pt_insn,
start_ip = *ip;
 
/* Load maps to ensure dso->is_64_bit has been updated */
-   map__load(al.map, machine->symbol_filter);
+   map__load(al.map, NULL);
 
x86_64 = al.map->dso->is_64_bit;
 
@@ -1294,7 +1294,7 @@ static u64 intel_pt_switch_ip(struct intel_pt *pt, u64 
*ptss_ip)
if (!map)
return 0;
 
-   if (map__load(map, machine->symbol_filter))
+   if (map__load(map, NULL))
return 0;
 
start = dso__first_symbol(map->dso, MAP__FUNCTION);
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index cb6388d..7940ddc 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -41,7 +41,6 @@ int machine__init(struct machine *machine, const char 
*root_dir, pid_t pid)
 
machine->pid = pid;
 
-   machine->symbol_filter = NULL;
machine->id_hdr_size = 0;
machine->kptr_restrict_warned = false;
machine->comm_exec = false;
@@ -148,7 +147,6 @@ void machines__init(struct machines *machines)
 {
machine__init(>host, "", HOST_KERNEL_ID);
machines->guests = RB_ROOT;
-   machines->symbol_filter = NULL;
 }
 
 void machines__exit(struct machines *machines)
@@ -172,8 +170,6 @@ struct machine *machines__add(struct machines *machines, 
pid_t pid,
return NULL;
}
 
-   machine->symbol_filter = machines->symbol_filter;
-
while (*p != NULL) {
parent = *p;
pos = rb_entry(parent, struct machine, rb_node);
@@ -189,21 +185,6 @@ struct machine *machines__add(struct machines *machines, 
pid_t pid,
return machine;
 }
 
-void machines__set_symbol_filter(struct machines *machines,
-symbol_filter_t symbol_filter)
-{

[tip:perf/core] perf top: Remove old kernel-only symbol filter

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  b6220212d48a9bfbc694d10b38dbdfbaab81f4a0
Gitweb: http://git.kernel.org/tip/b6220212d48a9bfbc694d10b38dbdfbaab81f4a0
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 1 Sep 2016 18:47:15 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 5 Sep 2016 11:14:50 -0300

perf top: Remove old kernel-only symbol filter

Not needed, we already have code to prune aliases.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-1ysyce7qjgui93gi1efbj...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-top.c | 27 ---
 1 file changed, 27 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 6f48df1..4007857 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -657,31 +657,6 @@ repeat:
return NULL;
 }
 
-static int symbol_filter(struct map *map, struct symbol *sym)
-{
-   const char *name = sym->name;
-
-   if (!__map__is_kernel(map))
-   return 0;
-   /*
-* ppc64 uses function descriptors and appends a '.' to the
-* start of every instruction address. Remove it.
-*/
-   if (name[0] == '.')
-   name++;
-
-   if (!strcmp(name, "_text") ||
-   !strcmp(name, "_etext") ||
-   !strcmp(name, "_sinittext") ||
-   !strncmp("init_module", name, 11) ||
-   !strncmp("cleanup_module", name, 14) ||
-   strstr(name, "_text_start") ||
-   strstr(name, "_text_end"))
-   return 1;
-
-   return 0;
-}
-
 static int hist_iter__top_callback(struct hist_entry_iter *iter,
   struct addr_location *al, bool single,
   void *arg)
@@ -946,8 +921,6 @@ static int __cmd_top(struct perf_top *top)
if (top->session == NULL)
return -1;
 
-   machines__set_symbol_filter(>session->machines, symbol_filter);
-
if (!objdump_path) {
ret = perf_env__lookup_objdump(>session->header.env);
if (ret)

[tip:perf/core] perf machine: Remove machine->symbol_filter and friends

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  0890e97c20333c439a9bda6a94dd16ed5f508429
Gitweb: http://git.kernel.org/tip/0890e97c20333c439a9bda6a94dd16ed5f508429
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 1 Sep 2016 18:53:58 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 5 Sep 2016 11:14:50 -0300

perf machine: Remove machine->symbol_filter and friends

Including machines__set_symbol_filter(), not used anymore.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-7o1qgmrpvzuis4a9f0t8m...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/event.c |  8 +++-
 tools/perf/util/intel-bts.c |  2 +-
 tools/perf/util/intel-pt.c  |  4 ++--
 tools/perf/util/machine.c   | 21 +
 tools/perf/util/machine.h   |  4 
 5 files changed, 7 insertions(+), 32 deletions(-)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index e20438b..2f91183 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1286,7 +1286,7 @@ try_again:
 * must be done prior to using kernel maps.
 */
if (load_map)
-   map__load(al->map, machine->symbol_filter);
+   map__load(al->map, NULL);
al->addr = al->map->map_ip(al->map, al->addr);
}
 }
@@ -1297,8 +1297,7 @@ void thread__find_addr_location(struct thread *thread,
 {
thread__find_addr_map(thread, cpumode, type, addr, al);
if (al->map != NULL)
-   al->sym = map__find_symbol(al->map, al->addr,
-  thread->mg->machine->symbol_filter);
+   al->sym = map__find_symbol(al->map, al->addr, NULL);
else
al->sym = NULL;
 }
@@ -1359,8 +1358,7 @@ int machine__resolve(struct machine *machine, struct 
addr_location *al,
al->filtered |= (1 << HIST_FILTER__DSO);
}
 
-   al->sym = map__find_symbol(al->map, al->addr,
-  machine->symbol_filter);
+   al->sym = map__find_symbol(al->map, al->addr, NULL);
}
 
if (symbol_conf.sym_list &&
diff --git a/tools/perf/util/intel-bts.c b/tools/perf/util/intel-bts.c
index 749e6f2..240b095 100644
--- a/tools/perf/util/intel-bts.c
+++ b/tools/perf/util/intel-bts.c
@@ -346,7 +346,7 @@ static int intel_bts_get_next_insn(struct intel_bts_queue 
*btsq, u64 ip)
goto out_put;
 
/* Load maps to ensure dso->is_64_bit has been updated */
-   map__load(al.map, machine->symbol_filter);
+   map__load(al.map, NULL);
 
x86_64 = al.map->dso->is_64_bit;
 
diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index 551ff6f..d594052 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -477,7 +477,7 @@ static int intel_pt_walk_next_insn(struct intel_pt_insn 
*intel_pt_insn,
start_ip = *ip;
 
/* Load maps to ensure dso->is_64_bit has been updated */
-   map__load(al.map, machine->symbol_filter);
+   map__load(al.map, NULL);
 
x86_64 = al.map->dso->is_64_bit;
 
@@ -1294,7 +1294,7 @@ static u64 intel_pt_switch_ip(struct intel_pt *pt, u64 
*ptss_ip)
if (!map)
return 0;
 
-   if (map__load(map, machine->symbol_filter))
+   if (map__load(map, NULL))
return 0;
 
start = dso__first_symbol(map->dso, MAP__FUNCTION);
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index cb6388d..7940ddc 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -41,7 +41,6 @@ int machine__init(struct machine *machine, const char 
*root_dir, pid_t pid)
 
machine->pid = pid;
 
-   machine->symbol_filter = NULL;
machine->id_hdr_size = 0;
machine->kptr_restrict_warned = false;
machine->comm_exec = false;
@@ -148,7 +147,6 @@ void machines__init(struct machines *machines)
 {
machine__init(>host, "", HOST_KERNEL_ID);
machines->guests = RB_ROOT;
-   machines->symbol_filter = NULL;
 }
 
 void machines__exit(struct machines *machines)
@@ -172,8 +170,6 @@ struct machine *machines__add(struct machines *machines, 
pid_t pid,
return NULL;
}
 
-   machine->symbol_filter = machines->symbol_filter;
-
while (*p != NULL) {
parent = *p;
pos = rb_entry(parent, struct machine, rb_node);
@@ -189,21 +185,6 @@ struct machine *machines__add(struct machines *machines, 
pid_t pid,
return machine;
 }
 
-void machines__set_symbol_filter(struct machines *machines,
-symbol_filter_t symbol_filter)
-{
-   struct rb_node *nd;
-
-   machines->symbol_filter = symbol_filter;
-   machines->host.symbol_filter = symbol_filter;
-
-   for (nd = rb_first(>guests); nd; 

[tip:perf/core] perf top: Remove old kernel-only symbol filter

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  b6220212d48a9bfbc694d10b38dbdfbaab81f4a0
Gitweb: http://git.kernel.org/tip/b6220212d48a9bfbc694d10b38dbdfbaab81f4a0
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 1 Sep 2016 18:47:15 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 5 Sep 2016 11:14:50 -0300

perf top: Remove old kernel-only symbol filter

Not needed, we already have code to prune aliases.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-1ysyce7qjgui93gi1efbj...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-top.c | 27 ---
 1 file changed, 27 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 6f48df1..4007857 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -657,31 +657,6 @@ repeat:
return NULL;
 }
 
-static int symbol_filter(struct map *map, struct symbol *sym)
-{
-   const char *name = sym->name;
-
-   if (!__map__is_kernel(map))
-   return 0;
-   /*
-* ppc64 uses function descriptors and appends a '.' to the
-* start of every instruction address. Remove it.
-*/
-   if (name[0] == '.')
-   name++;
-
-   if (!strcmp(name, "_text") ||
-   !strcmp(name, "_etext") ||
-   !strcmp(name, "_sinittext") ||
-   !strncmp("init_module", name, 11) ||
-   !strncmp("cleanup_module", name, 14) ||
-   strstr(name, "_text_start") ||
-   strstr(name, "_text_end"))
-   return 1;
-
-   return 0;
-}
-
 static int hist_iter__top_callback(struct hist_entry_iter *iter,
   struct addr_location *al, bool single,
   void *arg)
@@ -946,8 +921,6 @@ static int __cmd_top(struct perf_top *top)
if (top->session == NULL)
return -1;
 
-   machines__set_symbol_filter(>session->machines, symbol_filter);
-
if (!objdump_path) {
ret = perf_env__lookup_objdump(>session->header.env);
if (ret)

[tip:perf/core] perf symbols: Mark if a symbol is idle in the library

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  608c34de0b3d7bd15340a95ef758b4d8b81ebfc6
Gitweb: http://git.kernel.org/tip/608c34de0b3d7bd15340a95ef758b4d8b81ebfc6
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 1 Sep 2016 17:54:31 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 5 Sep 2016 11:14:50 -0300

perf symbols: Mark if a symbol is idle in the library

This was being done just in 'perf top', but grouping idle symbols should
be useful in other places as well, so remove one more symbol_filter_t
user by moving this to the symbol library.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-5r7xitjkzjr9jak1zy3d8...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-top.c |  3 ---
 tools/perf/util/symbol-elf.c |  2 +-
 tools/perf/util/symbol.c | 32 +++-
 tools/perf/util/symbol.h |  2 +-
 4 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index e091900..6f48df1 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -679,9 +679,6 @@ static int symbol_filter(struct map *map, struct symbol 
*sym)
strstr(name, "_text_end"))
return 1;
 
-   if (symbol__is_idle(sym))
-   sym->idle = 1;
-
return 0;
 }
 
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 295d314..bd91a4f 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1127,7 +1127,7 @@ new_symbol:
if (filter && filter(curr_map, f))
symbol__delete(f);
else {
-   symbols__insert(_dso->symbols[curr_map->type], f);
+   __symbols__insert(_dso->symbols[curr_map->type], 
f, dso->kernel);
nr++;
}
}
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 98cd503..4c5788f 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -28,6 +28,8 @@ static int dso__load_kernel_sym(struct dso *dso, struct map 
*map,
symbol_filter_t filter);
 static int dso__load_guest_kernel_sym(struct dso *dso, struct map *map,
symbol_filter_t filter);
+static bool symbol__is_idle(const char *name);
+
 int vmlinux_path__nr_entries;
 char **vmlinux_path;
 
@@ -277,13 +279,24 @@ void symbols__delete(struct rb_root *symbols)
}
 }
 
-void symbols__insert(struct rb_root *symbols, struct symbol *sym)
+void __symbols__insert(struct rb_root *symbols, struct symbol *sym, bool 
kernel)
 {
struct rb_node **p = >rb_node;
struct rb_node *parent = NULL;
const u64 ip = sym->start;
struct symbol *s;
 
+   if (kernel) {
+   const char *name = sym->name;
+   /*
+* ppc64 uses function descriptors and appends a '.' to the
+* start of every instruction address. Remove it.
+*/
+   if (name[0] == '.')
+   name++;
+   sym->idle = symbol__is_idle(name);
+   }
+
while (*p != NULL) {
parent = *p;
s = rb_entry(parent, struct symbol, rb_node);
@@ -296,6 +309,11 @@ void symbols__insert(struct rb_root *symbols, struct 
symbol *sym)
rb_insert_color(>rb_node, symbols);
 }
 
+void symbols__insert(struct rb_root *symbols, struct symbol *sym)
+{
+   __symbols__insert(symbols, sym, false);
+}
+
 static struct symbol *symbols__find(struct rb_root *symbols, u64 ip)
 {
struct rb_node *n;
@@ -424,7 +442,7 @@ void dso__reset_find_symbol_cache(struct dso *dso)
 
 void dso__insert_symbol(struct dso *dso, enum map_type type, struct symbol 
*sym)
 {
-   symbols__insert(>symbols[type], sym);
+   __symbols__insert(>symbols[type], sym, dso->kernel);
 
/* update the symbol cache if necessary */
if (dso->last_find_result[type].addr >= sym->start &&
@@ -546,7 +564,7 @@ struct process_kallsyms_args {
  * These are symbols in the kernel image, so make sure that
  * sym is from a kernel DSO.
  */
-bool symbol__is_idle(struct symbol *sym)
+static bool symbol__is_idle(const char *name)
 {
const char * const idle_symbols[] = {
"cpu_idle",
@@ -563,14 +581,10 @@ bool symbol__is_idle(struct symbol *sym)
"pseries_dedicated_idle_sleep",
NULL
};
-
int i;
 
-   if (!sym)
-   return false;
-
for (i = 0; idle_symbols[i]; i++) {
-   if (!strcmp(idle_symbols[i], sym->name))
+   if (!strcmp(idle_symbols[i], name))
return true;
}
 
@@ 

[tip:perf/core] perf symbols: Mark if a symbol is idle in the library

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  608c34de0b3d7bd15340a95ef758b4d8b81ebfc6
Gitweb: http://git.kernel.org/tip/608c34de0b3d7bd15340a95ef758b4d8b81ebfc6
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 1 Sep 2016 17:54:31 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 5 Sep 2016 11:14:50 -0300

perf symbols: Mark if a symbol is idle in the library

This was being done just in 'perf top', but grouping idle symbols should
be useful in other places as well, so remove one more symbol_filter_t
user by moving this to the symbol library.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-5r7xitjkzjr9jak1zy3d8...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-top.c |  3 ---
 tools/perf/util/symbol-elf.c |  2 +-
 tools/perf/util/symbol.c | 32 +++-
 tools/perf/util/symbol.h |  2 +-
 4 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index e091900..6f48df1 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -679,9 +679,6 @@ static int symbol_filter(struct map *map, struct symbol 
*sym)
strstr(name, "_text_end"))
return 1;
 
-   if (symbol__is_idle(sym))
-   sym->idle = 1;
-
return 0;
 }
 
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 295d314..bd91a4f 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1127,7 +1127,7 @@ new_symbol:
if (filter && filter(curr_map, f))
symbol__delete(f);
else {
-   symbols__insert(_dso->symbols[curr_map->type], f);
+   __symbols__insert(_dso->symbols[curr_map->type], 
f, dso->kernel);
nr++;
}
}
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 98cd503..4c5788f 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -28,6 +28,8 @@ static int dso__load_kernel_sym(struct dso *dso, struct map 
*map,
symbol_filter_t filter);
 static int dso__load_guest_kernel_sym(struct dso *dso, struct map *map,
symbol_filter_t filter);
+static bool symbol__is_idle(const char *name);
+
 int vmlinux_path__nr_entries;
 char **vmlinux_path;
 
@@ -277,13 +279,24 @@ void symbols__delete(struct rb_root *symbols)
}
 }
 
-void symbols__insert(struct rb_root *symbols, struct symbol *sym)
+void __symbols__insert(struct rb_root *symbols, struct symbol *sym, bool 
kernel)
 {
struct rb_node **p = >rb_node;
struct rb_node *parent = NULL;
const u64 ip = sym->start;
struct symbol *s;
 
+   if (kernel) {
+   const char *name = sym->name;
+   /*
+* ppc64 uses function descriptors and appends a '.' to the
+* start of every instruction address. Remove it.
+*/
+   if (name[0] == '.')
+   name++;
+   sym->idle = symbol__is_idle(name);
+   }
+
while (*p != NULL) {
parent = *p;
s = rb_entry(parent, struct symbol, rb_node);
@@ -296,6 +309,11 @@ void symbols__insert(struct rb_root *symbols, struct 
symbol *sym)
rb_insert_color(>rb_node, symbols);
 }
 
+void symbols__insert(struct rb_root *symbols, struct symbol *sym)
+{
+   __symbols__insert(symbols, sym, false);
+}
+
 static struct symbol *symbols__find(struct rb_root *symbols, u64 ip)
 {
struct rb_node *n;
@@ -424,7 +442,7 @@ void dso__reset_find_symbol_cache(struct dso *dso)
 
 void dso__insert_symbol(struct dso *dso, enum map_type type, struct symbol 
*sym)
 {
-   symbols__insert(>symbols[type], sym);
+   __symbols__insert(>symbols[type], sym, dso->kernel);
 
/* update the symbol cache if necessary */
if (dso->last_find_result[type].addr >= sym->start &&
@@ -546,7 +564,7 @@ struct process_kallsyms_args {
  * These are symbols in the kernel image, so make sure that
  * sym is from a kernel DSO.
  */
-bool symbol__is_idle(struct symbol *sym)
+static bool symbol__is_idle(const char *name)
 {
const char * const idle_symbols[] = {
"cpu_idle",
@@ -563,14 +581,10 @@ bool symbol__is_idle(struct symbol *sym)
"pseries_dedicated_idle_sleep",
NULL
};
-
int i;
 
-   if (!sym)
-   return false;
-
for (i = 0; idle_symbols[i]; i++) {
-   if (!strcmp(idle_symbols[i], sym->name))
+   if (!strcmp(idle_symbols[i], name))
return true;
}
 
@@ -599,7 +613,7 @@ static int map__process_kallsym_symbol(void *arg, const 
char *name,
 * We will pass the symbols to the filter later, in
 * map__split_kallsyms, 

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

[Ingo Molnar]

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

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> The following changes since commit c0b172e5b6770048751b2c0a4fe44346c2080c5d:
> 
>   Merge tag 'perf-core-for-mingo-20160901' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 
> (2016-09-05 15:15:49 +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-20160908
> 
> for you to fetch changes up to 25b8592e912f085ce2ff736a2927584ddeab238c:
> 
>   perf powerpc: Fix build-test failure (2016-09-08 13:44:07 -0300)
> 
> 
> perf/core improvements and fixes:
> 
> User visible:
> 
> - Add branch stack / basic block info to 'perf annotate --stdio', where for
>   each branch, we add an asm comment after the instruction with information on
>   how often it was taken and predicted. See example with color output at:
> 
> http://vger.kernel.org/~acme/perf/annotate_basic_blocks.png
> 
>   (Peter Zijlstra)
> 
> - Only open an evsel in CPUs in its cpu map, fixing some use cases in
>   systems with multiple PMUs with different CPU maps (Mark Rutland)
> 
> - Fix handling of huge TLB maps, recognizing it as anonymous (Wang Nan)
> 
> Infrastructure:
> 
> - Remove the symbol filtering code, i.e. the callbacks passed to all functions
>   that could end up loading a DSO symtab, simplifying the code, eventually
>   allowing what we should have had since day one: removing the 'map' parameter
>   from dso__load() functions (Arnaldo Carvalho de Melo)
> 
> Arch specific build fixes:
> 
> - Fix detached tarball build on powerpc, where we were still accessing a
>   file outside tools/ (Ravi Bangoria)
> 
> Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
> 
> 
> Arnaldo Carvalho de Melo (5):
>   perf symbols: Mark if a symbol is idle in the library
>   perf top: Remove old kernel-only symbol filter
>   perf machine: Remove machine->symbol_filter and friends
>   perf test vmlinux: Remove dead symbol_filter_t code
>   perf symbols: Remove symbol_filter_t machinery
> 
> Mark Rutland (2):
>   perf evlist: Only open events on CPUs an evsel permits
>   perf pmu: Support alternative sysfs cpumask
> 
> Peter Zijlstra (1):
>   perf annotate: Add branch stack / basic block
> 
> Ravi Bangoria (1):
>   perf powerpc: Fix build-test failure
> 
> Wang Nan (3):
>   perf tools: Recognize hugetlb mapping as anon mapping
>   tools lib api fs: Add hugetlbfs filesystem detector
>   perf record: Mark MAP_HUGETLB when synthesizing mmap events
> 
>  tools/lib/api/fs/fs.c   |  15 ++
>  tools/lib/api/fs/fs.h   |   1 +
>  tools/perf/arch/powerpc/util/sym-handling.c |   2 +-
>  tools/perf/builtin-annotate.c   | 104 +
>  tools/perf/builtin-inject.c |   2 +-
>  tools/perf/builtin-kmem.c   |  10 +-
>  tools/perf/builtin-script.c |   4 +-
>  tools/perf/builtin-top.c|  30 ---
>  tools/perf/perf-sys.h   |   1 -
>  tools/perf/tests/code-reading.c |   4 +-
>  tools/perf/tests/vmlinux-kallsyms.c |  17 +-
>  tools/perf/ui/browsers/annotate.c   |   2 +-
>  tools/perf/ui/browsers/map.c|   4 +-
>  tools/perf/util/Build   |   1 +
>  tools/perf/util/annotate.c  |  95 +++-
>  tools/perf/util/annotate.h  |   1 +
>  tools/perf/util/block-range.c   | 328 
> 
>  tools/perf/util/block-range.h   |  71 ++
>  tools/perf/util/event.c |  21 +-
>  tools/perf/util/evlist.c|   8 +-
>  tools/perf/util/intel-bts.c |   2 +-
>  tools/perf/util/intel-pt.c  |   4 +-
>  tools/perf/util/machine.c   |  38 +---
>  tools/perf/util/machine.h   |  34 +--
>  tools/perf/util/map.c   |  50 ++---
>  tools/perf/util/map.h   |  32 +--
>  tools/perf/util/pmu.c   |  15 +-
>  tools/perf/util/probe-event.c   |  17 +-
>  tools/perf/util/symbol-elf.c|  32 +--
>  tools/perf/util/symbol-minimal.c|   4 +-
>  tools/perf/util/symbol.c| 134 ++--
>  tools/perf/util/symbol.h|  20 +-
>  32 files changed, 817 insertions

linux-next: Tree for Sep 9

[Stephen Rothwell]

Hi all,

Changes since 20160908:

New tree: kvm-mips

The btrfs-kdave tree still had its build failure so I used the version
from next-20160906.

The kbuild tree still had its build warnings for PowerPC, for which I
reverted a commit.

The devicetree tree gained a conflict against the imx-mxs tree.

The gpio tree gained a build failure, so I used the version from
next-20160908.

Non-merge commits (relative to Linus' tree): 5850
 5573 files changed, 273152 insertions(+), 103813 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 241 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (711bef65e91d Merge tag 'ceph-for-4.8-rc6' of 
git://github.com/ceph/ceph-client)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4)
Merging arm-current/fixes (da60626e7d02 ARM: sa1100: clear reset status prior 
to reboot)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (f077aaf0754b powerpc/mm: Don't alias user region 
to other regions below PAGE_OFFSET)
Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (81d1a366ff81 Merge branch 'mlx5-fixes')
Merging ipsec/master (11d7a0bb95ea xfrm: Only add l3mdev oif to dst lookups)
Merging netfilter/master (d1a6cba576fc netfilter: nft_chain_route: re-route 
before skb is queued to userspace)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (a0714125d11b Merge ath-current from ath.git)
Merging mac80211/master (61aaa0e8c1c1 cfg80211: Add stub for 
cfg80211_get_station())
Merging sound-current/for-linus (816f318b2364 ALSA: rawmidi: Fix possible 
deadlock with virmidi registration)
Merging pci-current/for-linus (6af7e4f77259 PCI: Mark Haswell Power Control 
Unit as having non-compliant BARs)
Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5)
Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5)
Merging usb.current/usb-linus (bcf42aa60c28 xhci: fix null pointer dereference 
in stop command timeout function)
Merging usb-gadget-fixes/fixes (696118c016dd usb: dwc3: pci: fix build warning 
on !PM_SLEEP)
Merging usb-serial-fixes/usb-linus (40d9c32525cb USB: serial: option: add 
WeTelecom 0x6802 and 0x6803 products)
Merging usb-chipidea-fixes/ci-for-usb-stable (c4e94174983a usb: chipidea: udc: 
don't touch DP when controller is in host mode)
Merging staging.current/staging-linus (c6935931c189 Linux 4.8-rc5)
Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5)
Merging input-current/for-linus (e3a888a4bff0 Input: ads7846 - remove redundant 
regulator_disable call)
Merging crypto-current/master (0bd2223594a4 crypto: cryptd - initialize child 
shash_desc on import)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (c8952a

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

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> The following changes since commit c0b172e5b6770048751b2c0a4fe44346c2080c5d:
> 
>   Merge tag 'perf-core-for-mingo-20160901' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 
> (2016-09-05 15:15:49 +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-20160908
> 
> for you to fetch changes up to 25b8592e912f085ce2ff736a2927584ddeab238c:
> 
>   perf powerpc: Fix build-test failure (2016-09-08 13:44:07 -0300)
> 
> 
> perf/core improvements and fixes:
> 
> User visible:
> 
> - Add branch stack / basic block info to 'perf annotate --stdio', where for
>   each branch, we add an asm comment after the instruction with information on
>   how often it was taken and predicted. See example with color output at:
> 
> http://vger.kernel.org/~acme/perf/annotate_basic_blocks.png
> 
>   (Peter Zijlstra)
> 
> - Only open an evsel in CPUs in its cpu map, fixing some use cases in
>   systems with multiple PMUs with different CPU maps (Mark Rutland)
> 
> - Fix handling of huge TLB maps, recognizing it as anonymous (Wang Nan)
> 
> Infrastructure:
> 
> - Remove the symbol filtering code, i.e. the callbacks passed to all functions
>   that could end up loading a DSO symtab, simplifying the code, eventually
>   allowing what we should have had since day one: removing the 'map' parameter
>   from dso__load() functions (Arnaldo Carvalho de Melo)
> 
> Arch specific build fixes:
> 
> - Fix detached tarball build on powerpc, where we were still accessing a
>   file outside tools/ (Ravi Bangoria)
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Arnaldo Carvalho de Melo (5):
>   perf symbols: Mark if a symbol is idle in the library
>   perf top: Remove old kernel-only symbol filter
>   perf machine: Remove machine->symbol_filter and friends
>   perf test vmlinux: Remove dead symbol_filter_t code
>   perf symbols: Remove symbol_filter_t machinery
> 
> Mark Rutland (2):
>   perf evlist: Only open events on CPUs an evsel permits
>   perf pmu: Support alternative sysfs cpumask
> 
> Peter Zijlstra (1):
>   perf annotate: Add branch stack / basic block
> 
> Ravi Bangoria (1):
>   perf powerpc: Fix build-test failure
> 
> Wang Nan (3):
>   perf tools: Recognize hugetlb mapping as anon mapping
>   tools lib api fs: Add hugetlbfs filesystem detector
>   perf record: Mark MAP_HUGETLB when synthesizing mmap events
> 
>  tools/lib/api/fs/fs.c   |  15 ++
>  tools/lib/api/fs/fs.h   |   1 +
>  tools/perf/arch/powerpc/util/sym-handling.c |   2 +-
>  tools/perf/builtin-annotate.c   | 104 +
>  tools/perf/builtin-inject.c |   2 +-
>  tools/perf/builtin-kmem.c   |  10 +-
>  tools/perf/builtin-script.c |   4 +-
>  tools/perf/builtin-top.c|  30 ---
>  tools/perf/perf-sys.h   |   1 -
>  tools/perf/tests/code-reading.c |   4 +-
>  tools/perf/tests/vmlinux-kallsyms.c |  17 +-
>  tools/perf/ui/browsers/annotate.c   |   2 +-
>  tools/perf/ui/browsers/map.c|   4 +-
>  tools/perf/util/Build   |   1 +
>  tools/perf/util/annotate.c  |  95 +++-
>  tools/perf/util/annotate.h  |   1 +
>  tools/perf/util/block-range.c   | 328 
> 
>  tools/perf/util/block-range.h   |  71 ++
>  tools/perf/util/event.c |  21 +-
>  tools/perf/util/evlist.c|   8 +-
>  tools/perf/util/intel-bts.c |   2 +-
>  tools/perf/util/intel-pt.c  |   4 +-
>  tools/perf/util/machine.c   |  38 +---
>  tools/perf/util/machine.h   |  34 +--
>  tools/perf/util/map.c   |  50 ++---
>  tools/perf/util/map.h   |  32 +--
>  tools/perf/util/pmu.c   |  15 +-
>  tools/perf/util/probe-event.c   |  17 +-
>  tools/perf/util/symbol-elf.c|  32 +--
>  tools/perf/util/symbol-minimal.c|   4 +-
>  tools/perf/util/symbol.c| 134 ++--
>  tools/perf/util/symbol.h|  20 +-
>  32 files changed, 817 insertions(+), 286 deletions(-)
>  create mode 100644 t

linux-next: Tree for Sep 9

[Stephen Rothwell]

Hi all,

Changes since 20160908:

New tree: kvm-mips

The btrfs-kdave tree still had its build failure so I used the version
from next-20160906.

The kbuild tree still had its build warnings for PowerPC, for which I
reverted a commit.

The devicetree tree gained a conflict against the imx-mxs tree.

The gpio tree gained a build failure, so I used the version from
next-20160908.

Non-merge commits (relative to Linus' tree): 5850
 5573 files changed, 273152 insertions(+), 103813 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 241 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (711bef65e91d Merge tag 'ceph-for-4.8-rc6' of 
git://github.com/ceph/ceph-client)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4)
Merging arm-current/fixes (da60626e7d02 ARM: sa1100: clear reset status prior 
to reboot)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (f077aaf0754b powerpc/mm: Don't alias user region 
to other regions below PAGE_OFFSET)
Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (81d1a366ff81 Merge branch 'mlx5-fixes')
Merging ipsec/master (11d7a0bb95ea xfrm: Only add l3mdev oif to dst lookups)
Merging netfilter/master (d1a6cba576fc netfilter: nft_chain_route: re-route 
before skb is queued to userspace)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (a0714125d11b Merge ath-current from ath.git)
Merging mac80211/master (61aaa0e8c1c1 cfg80211: Add stub for 
cfg80211_get_station())
Merging sound-current/for-linus (816f318b2364 ALSA: rawmidi: Fix possible 
deadlock with virmidi registration)
Merging pci-current/for-linus (6af7e4f77259 PCI: Mark Haswell Power Control 
Unit as having non-compliant BARs)
Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5)
Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5)
Merging usb.current/usb-linus (bcf42aa60c28 xhci: fix null pointer dereference 
in stop command timeout function)
Merging usb-gadget-fixes/fixes (696118c016dd usb: dwc3: pci: fix build warning 
on !PM_SLEEP)
Merging usb-serial-fixes/usb-linus (40d9c32525cb USB: serial: option: add 
WeTelecom 0x6802 and 0x6803 products)
Merging usb-chipidea-fixes/ci-for-usb-stable (c4e94174983a usb: chipidea: udc: 
don't touch DP when controller is in host mode)
Merging staging.current/staging-linus (c6935931c189 Linux 4.8-rc5)
Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5)
Merging input-current/for-linus (e3a888a4bff0 Input: ads7846 - remove redundant 
regulator_disable call)
Merging crypto-current/master (0bd2223594a4 crypto: cryptd - initialize child 
shash_desc on import)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (c8952a

Re: [PATCH -v3 00/10] THP swap: Delay splitting THP during swapping out

[Minchan Kim]

Hi Huang,

On Wed, Sep 07, 2016 at 09:45:59AM -0700, Huang, Ying wrote:
> From: Huang Ying 
> 
> This patchset is to optimize the performance of Transparent Huge Page
> (THP) swap.
> 
> Hi, Andrew, could you help me to check whether the overall design is
> reasonable?
> 
> Hi, Hugh, Shaohua, Minchan and Rik, could you help me to review the
> swap part of the patchset?  Especially [01/10], [04/10], [05/10],
> [06/10], [07/10], [10/10].
> 
> Hi, Andrea and Kirill, could you help me to review the THP part of the
> patchset?  Especially [02/10], [03/10], [09/10] and [10/10].
> 
> Hi, Johannes, Michal and Vladimir, I am not very confident about the
> memory cgroup part, especially [02/10] and [03/10].  Could you help me
> to review it?
> 
> And for all, Any comment is welcome!
> 
> 
> Recently, the performance of the storage devices improved so fast that
> we cannot saturate the disk bandwidth when do page swap out even on a
> high-end server machine.  Because the performance of the storage
> device improved faster than that of CPU.  And it seems that the trend
> will not change in the near future.  On the other hand, the THP
> becomes more and more popular because of increased memory size.  So it
> becomes necessary to optimize THP swap performance.
> 
> The advantages of the THP swap support include:
> 
> - Batch the swap operations for the THP to reduce lock
>   acquiring/releasing, including allocating/freeing the swap space,
>   adding/deleting to/from the swap cache, and writing/reading the swap
>   space, etc.  This will help improve the performance of the THP swap.
> 
> - The THP swap space read/write will be 2M sequential IO.  It is
>   particularly helpful for the swap read, which usually are 4k random
>   IO.  This will improve the performance of the THP swap too.
> 
> - It will help the memory fragmentation, especially when the THP is
>   heavily used by the applications.  The 2M continuous pages will be
>   free up after THP swapping out.

I just read patchset right now and still doubt why the all changes
should be coupled with THP tightly. Many parts(e.g., you introduced
or modifying existing functions for making them THP specific) could
just take page_list and the number of pages then would handle them
without THP awareness.

For example, if the nr_pages is larger than SWAPFILE_CLUSTER, we
can try to allocate new cluster. With that, we could allocate new
clusters to meet nr_pages requested or bail out if we fail to allocate
and fallback to 0-order page swapout. With that, swap layer could
support multiple order-0 pages by batch.

IMO, I really want to land Tim Chen's batching swapout work first.
With Tim Chen's work, I expect we can make better refactoring
for batching swap before adding more confuse to the swap layer.
(I expect it would share several pieces of code for or would be base
for batching allocation of swapcache, swapslot)

After that, we could enhance swap for big contiguous batching
like THP and finally we might make it be aware of THP specific to
enhance further.

A thing I remember you aruged: you want to swapin 512 pages
all at once unconditionally. It's really worth to discuss if
your design is going for the way.
I doubt it's generally good idea. Because, currently, we try to
swap in swapped out pages in THP page with conservative approach
but your direction is going to opposite way.

[mm, thp: convert from optimistic swapin collapsing to conservative]

I think general approach(i.e., less effective than targeting
implement for your own specific goal but less hacky and better job
for many cases) is to rely/improve on the swap readahead.
If most of subpages of a THP page are really workingset, swap readahead
could work well.

Yeah, it's fairly vague feedback so sorry if I miss something clear.

Re: [PATCH -v3 00/10] THP swap: Delay splitting THP during swapping out

[Minchan Kim]

Hi Huang,

On Wed, Sep 07, 2016 at 09:45:59AM -0700, Huang, Ying wrote:
> From: Huang Ying 
> 
> This patchset is to optimize the performance of Transparent Huge Page
> (THP) swap.
> 
> Hi, Andrew, could you help me to check whether the overall design is
> reasonable?
> 
> Hi, Hugh, Shaohua, Minchan and Rik, could you help me to review the
> swap part of the patchset?  Especially [01/10], [04/10], [05/10],
> [06/10], [07/10], [10/10].
> 
> Hi, Andrea and Kirill, could you help me to review the THP part of the
> patchset?  Especially [02/10], [03/10], [09/10] and [10/10].
> 
> Hi, Johannes, Michal and Vladimir, I am not very confident about the
> memory cgroup part, especially [02/10] and [03/10].  Could you help me
> to review it?
> 
> And for all, Any comment is welcome!
> 
> 
> Recently, the performance of the storage devices improved so fast that
> we cannot saturate the disk bandwidth when do page swap out even on a
> high-end server machine.  Because the performance of the storage
> device improved faster than that of CPU.  And it seems that the trend
> will not change in the near future.  On the other hand, the THP
> becomes more and more popular because of increased memory size.  So it
> becomes necessary to optimize THP swap performance.
> 
> The advantages of the THP swap support include:
> 
> - Batch the swap operations for the THP to reduce lock
>   acquiring/releasing, including allocating/freeing the swap space,
>   adding/deleting to/from the swap cache, and writing/reading the swap
>   space, etc.  This will help improve the performance of the THP swap.
> 
> - The THP swap space read/write will be 2M sequential IO.  It is
>   particularly helpful for the swap read, which usually are 4k random
>   IO.  This will improve the performance of the THP swap too.
> 
> - It will help the memory fragmentation, especially when the THP is
>   heavily used by the applications.  The 2M continuous pages will be
>   free up after THP swapping out.

I just read patchset right now and still doubt why the all changes
should be coupled with THP tightly. Many parts(e.g., you introduced
or modifying existing functions for making them THP specific) could
just take page_list and the number of pages then would handle them
without THP awareness.

For example, if the nr_pages is larger than SWAPFILE_CLUSTER, we
can try to allocate new cluster. With that, we could allocate new
clusters to meet nr_pages requested or bail out if we fail to allocate
and fallback to 0-order page swapout. With that, swap layer could
support multiple order-0 pages by batch.

IMO, I really want to land Tim Chen's batching swapout work first.
With Tim Chen's work, I expect we can make better refactoring
for batching swap before adding more confuse to the swap layer.
(I expect it would share several pieces of code for or would be base
for batching allocation of swapcache, swapslot)

After that, we could enhance swap for big contiguous batching
like THP and finally we might make it be aware of THP specific to
enhance further.

A thing I remember you aruged: you want to swapin 512 pages
all at once unconditionally. It's really worth to discuss if
your design is going for the way.
I doubt it's generally good idea. Because, currently, we try to
swap in swapped out pages in THP page with conservative approach
but your direction is going to opposite way.

[mm, thp: convert from optimistic swapin collapsing to conservative]

I think general approach(i.e., less effective than targeting
implement for your own specific goal but less hacky and better job
for many cases) is to rely/improve on the swap readahead.
If most of subpages of a THP page are really workingset, swap readahead
could work well.

Yeah, it's fairly vague feedback so sorry if I miss something clear.

Re: [PATCH][RFC v5] timekeeping: Ignore the bogus sleep time if pm_trace is enabled

[Chen Yu]

Hi,
On Mon, Sep 05, 2016 at 01:54:20AM -0600, Thomas Gleixner wrote:
> On Sun, 4 Sep 2016, Chen Yu wrote:
> > Hi Thomas, Rafael,
> > On Fri, Sep 02, 2016 at 09:26:51PM +0200, Thomas Gleixner wrote:
> > > On Wed, 31 Aug 2016, Rafael J. Wysocki wrote:
> > > > On Monday, August 29, 2016 12:40:39 AM Chen Yu wrote:
> > > > > +
> > > > > + /*
> > > > > +  * Make rtc-based persistent clock unusable
> > > > > +  * if pm_trace is enabled, only take effect
> > > > > +  * for timekeeping_suspend/resume.
> > > > > +  */
> > > > > + if (pm_trace_is_enabled() &&
> > > > > + x86_platform.get_wallclock == mach_get_cmos_time) {
> > > > > + ts->tv_sec = 0;
> > > > > + ts->tv_nsec = 0;
> > > > > + }
> > > > 
> > > > I'm not sure about this.  Looks hackish.
> > > 
> > > Indeed. Can't you just keep track that pm_trace fiddled with the cmos 
> > > clock
> > > and then discard the value either in the core or in mach_get_cmos_time()
> > The previous version is more straightforward, since
> > it ignored the bogus rtc in core. Would you please take
> > a glance at it too, thanks:
> > https://patchwork.kernel.org/patch/9287347/
> 
> This is the same hackery just different:
> 
> > +bool persistent_clock_is_usable(void)
> > +{
> > +   /* Unusable if pm_trace is enabled. */
> > +   return !((x86_platform.get_wallclock == mach_get_cmos_time) &&
> > +   pm_trace_is_enabled());
> > +}
> 
> I really have no idea why this is burried in x86 land. The pm_trace hackery
> issues mc146818_set_time() to fiddle with the RTC. So any implementation of
> this is affected.
OK, I've changed this patch according to this suggestion.

Previously I tried to deal with the case that x86 uses
RTC-CMOS as its presistent clock, not kvm_clock, nor
other get_wallclock, and this seems only be related to x86.
So this piece of code looks hackish.
> 
> So that very piece of pmtrace code should keep track of the wreckage it did
> to the RTC and provide the fact to the core timekeeping code which can then
> skip the update.
> 
OK. I've moved most of the logic into the pm_trace component,
Once the mc146818_set_time has modified the RTC by pm_trace,
related flags will be set which indicates the unusable of RTC.
And timekeeping system is able to query these flags to decide whether
it should inject the sleep time. (We tried to make this patch as
simple as possible, but it looks like we have to deal with persistent
clock for x86, which makes this patch a little more complicated).
Here's the trial version of it, any suggestion would be appreciated:



Index: linux/drivers/base/power/trace.c
===
--- linux.orig/drivers/base/power/trace.c
+++ linux/drivers/base/power/trace.c
@@ -75,6 +75,27 @@
 #define DEVSEED (7919)
 
 static unsigned int dev_hash_value;
+unsigned int timekeeping_tainted;
+
+/* Is the persistent clock effected by pm_trace? */
+int __weak arch_pm_trace_taint_pclock(void)
+{
+   return 0;
+}
+
+void pm_trace_untaint_timekeeping(void)
+{
+   timekeeping_tainted = 0;
+}
+
+void pm_trace_taint_timekeeping(void)
+{
+   if (pm_trace_is_enabled()) {
+   timekeeping_tainted |= TIMEKEEPING_RTC_TAINTED;
+   if (arch_pm_trace_taint_pclock())
+   timekeeping_tainted |= 
TIMEKEEPING_PERSISTENT_CLOCK_TAINTED;
+   }
+}
 
 static int set_magic_time(unsigned int user, unsigned int file, unsigned int 
device)
 {
@@ -104,6 +125,7 @@ static int set_magic_time(unsigned int u
time.tm_min = (n % 20) * 3;
n /= 20;
mc146818_set_time();
+   pm_trace_taint_timekeeping();
return n ? -1 : 0;
 }
 
Index: linux/kernel/power/main.c
===
--- linux.orig/kernel/power/main.c
+++ linux/kernel/power/main.c
@@ -548,6 +548,7 @@ pm_trace_store(struct kobject *kobj, str
if (sscanf(buf, "%d", ) == 1) {
pm_trace_enabled = !!val;
if (pm_trace_enabled) {
+   pm_trace_untaint_timekeeping();
pr_warn("PM: Enabling pm_trace changes system date and 
time during resume.\n"
"PM: Correct system time has to be restored 
manually after resume.\n");
}
Index: linux/include/linux/pm-trace.h
===
--- linux.orig/include/linux/pm-trace.h
+++ linux/include/linux/pm-trace.h
@@ -1,10 +1,14 @@
 #ifndef PM_TRACE_H
 #define PM_TRACE_H
 
+#define TIMEKEEPING_RTC_TAINTED 0x1
+#define TIMEKEEPING_PERSISTENT_CLOCK_TAINTED 0x2
+
 #ifdef CONFIG_PM_TRACE
 #include 
 #include 
 
+extern unsigned int timekeeping_tainted;
 extern int pm_trace_enabled;
 
 static inline int pm_trace_is_enabled(void)
@@ -12,10 +16,23 @@ static inline int pm_trace_is_enabled(vo
return pm_trace_enabled;
 }
 
+static inline int pm_trace_rtc_is_tainted(void)
+{
+   return 

Re: [PATCH][RFC v5] timekeeping: Ignore the bogus sleep time if pm_trace is enabled

[Chen Yu]

Hi,
On Mon, Sep 05, 2016 at 01:54:20AM -0600, Thomas Gleixner wrote:
> On Sun, 4 Sep 2016, Chen Yu wrote:
> > Hi Thomas, Rafael,
> > On Fri, Sep 02, 2016 at 09:26:51PM +0200, Thomas Gleixner wrote:
> > > On Wed, 31 Aug 2016, Rafael J. Wysocki wrote:
> > > > On Monday, August 29, 2016 12:40:39 AM Chen Yu wrote:
> > > > > +
> > > > > + /*
> > > > > +  * Make rtc-based persistent clock unusable
> > > > > +  * if pm_trace is enabled, only take effect
> > > > > +  * for timekeeping_suspend/resume.
> > > > > +  */
> > > > > + if (pm_trace_is_enabled() &&
> > > > > + x86_platform.get_wallclock == mach_get_cmos_time) {
> > > > > + ts->tv_sec = 0;
> > > > > + ts->tv_nsec = 0;
> > > > > + }
> > > > 
> > > > I'm not sure about this.  Looks hackish.
> > > 
> > > Indeed. Can't you just keep track that pm_trace fiddled with the cmos 
> > > clock
> > > and then discard the value either in the core or in mach_get_cmos_time()
> > The previous version is more straightforward, since
> > it ignored the bogus rtc in core. Would you please take
> > a glance at it too, thanks:
> > https://patchwork.kernel.org/patch/9287347/
> 
> This is the same hackery just different:
> 
> > +bool persistent_clock_is_usable(void)
> > +{
> > +   /* Unusable if pm_trace is enabled. */
> > +   return !((x86_platform.get_wallclock == mach_get_cmos_time) &&
> > +   pm_trace_is_enabled());
> > +}
> 
> I really have no idea why this is burried in x86 land. The pm_trace hackery
> issues mc146818_set_time() to fiddle with the RTC. So any implementation of
> this is affected.
OK, I've changed this patch according to this suggestion.

Previously I tried to deal with the case that x86 uses
RTC-CMOS as its presistent clock, not kvm_clock, nor
other get_wallclock, and this seems only be related to x86.
So this piece of code looks hackish.
> 
> So that very piece of pmtrace code should keep track of the wreckage it did
> to the RTC and provide the fact to the core timekeeping code which can then
> skip the update.
> 
OK. I've moved most of the logic into the pm_trace component,
Once the mc146818_set_time has modified the RTC by pm_trace,
related flags will be set which indicates the unusable of RTC.
And timekeeping system is able to query these flags to decide whether
it should inject the sleep time. (We tried to make this patch as
simple as possible, but it looks like we have to deal with persistent
clock for x86, which makes this patch a little more complicated).
Here's the trial version of it, any suggestion would be appreciated:



Index: linux/drivers/base/power/trace.c
===
--- linux.orig/drivers/base/power/trace.c
+++ linux/drivers/base/power/trace.c
@@ -75,6 +75,27 @@
 #define DEVSEED (7919)
 
 static unsigned int dev_hash_value;
+unsigned int timekeeping_tainted;
+
+/* Is the persistent clock effected by pm_trace? */
+int __weak arch_pm_trace_taint_pclock(void)
+{
+   return 0;
+}
+
+void pm_trace_untaint_timekeeping(void)
+{
+   timekeeping_tainted = 0;
+}
+
+void pm_trace_taint_timekeeping(void)
+{
+   if (pm_trace_is_enabled()) {
+   timekeeping_tainted |= TIMEKEEPING_RTC_TAINTED;
+   if (arch_pm_trace_taint_pclock())
+   timekeeping_tainted |= 
TIMEKEEPING_PERSISTENT_CLOCK_TAINTED;
+   }
+}
 
 static int set_magic_time(unsigned int user, unsigned int file, unsigned int 
device)
 {
@@ -104,6 +125,7 @@ static int set_magic_time(unsigned int u
time.tm_min = (n % 20) * 3;
n /= 20;
mc146818_set_time();
+   pm_trace_taint_timekeeping();
return n ? -1 : 0;
 }
 
Index: linux/kernel/power/main.c
===
--- linux.orig/kernel/power/main.c
+++ linux/kernel/power/main.c
@@ -548,6 +548,7 @@ pm_trace_store(struct kobject *kobj, str
if (sscanf(buf, "%d", ) == 1) {
pm_trace_enabled = !!val;
if (pm_trace_enabled) {
+   pm_trace_untaint_timekeeping();
pr_warn("PM: Enabling pm_trace changes system date and 
time during resume.\n"
"PM: Correct system time has to be restored 
manually after resume.\n");
}
Index: linux/include/linux/pm-trace.h
===
--- linux.orig/include/linux/pm-trace.h
+++ linux/include/linux/pm-trace.h
@@ -1,10 +1,14 @@
 #ifndef PM_TRACE_H
 #define PM_TRACE_H
 
+#define TIMEKEEPING_RTC_TAINTED 0x1
+#define TIMEKEEPING_PERSISTENT_CLOCK_TAINTED 0x2
+
 #ifdef CONFIG_PM_TRACE
 #include 
 #include 
 
+extern unsigned int timekeeping_tainted;
 extern int pm_trace_enabled;
 
 static inline int pm_trace_is_enabled(void)
@@ -12,10 +16,23 @@ static inline int pm_trace_is_enabled(vo
return pm_trace_enabled;
 }
 
+static inline int pm_trace_rtc_is_tainted(void)
+{
+   return 

Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client

[Kalle Valo]

Andy Gross  writes:

>> > >> This doesn't compile for me:
>> > >>
>> > >
>> > > I thought I mentioned this in the mail, sorry for missing that.
>> > 
>> > Maybe you did and I just forgot, I have a tendency to do that :)
>> > 
>> > > There is a patch for this issue in linux-next already [1] which is
>> > > part of [2], which was part of the pull request to arm-soc for
>> > > inclusion in v4.9.
>> > >
>> > > [1] https://patchwork.kernel.org/patch/9272457/
>> > > [2] 
>> > > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
>> > 
>> > So the commit in question is:
>> > 
>> > soc: qcom: smd: Correct compile stub prototypes
>> > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9=3a1281848830fcb3202cfd7ffe62d19641471d05
>> > 
>> 
>> Correct
>> 
>> > But that's not obviously in my tree yet, but I should have it after
>> > 4.9-rc1 is released. I think it's easiest that I wait for that before
>> > applying these. Do you agree?
>> > 
>> 
>> Would be nice to have it land sooner rather than later, but I'm okay
>> with this.
>
> We could just treat the tag as immutable.  You can merge the tag in and 
> arm-soc
> can as well.  it'll just get nop'd the second time it is taken.  The only
> downside is if arm-soc doesn't take my merge request.

I take it that you are talking about this tag:

git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git 
qcom-drivers-for-4.9

I did a test pull and there are only 8 commits so in theory that could
work. But my trees go via Dave Miller's net-next so I can't control when
they hit Linus' tree. It might be that Linus pulls the net-next tree
before arm-soc and arm-soc commits coming from net-next might confuse
people. I'm just afraid that the hassle would outweight the benefit.

> Or we can wait till -rc1

To keep things simple I prefer this option. Of course it means waiting
few more extra weeks, but when working with new subsystems that can
happen. The crystall ball[1] says that 4.9-rc1 would be released on
2016-10-16 so it's not that far away.

[1] http://phb-crystal-ball.org/

-- 
Kalle Valo

Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client

[Kalle Valo]

Andy Gross  writes:

>> > >> This doesn't compile for me:
>> > >>
>> > >
>> > > I thought I mentioned this in the mail, sorry for missing that.
>> > 
>> > Maybe you did and I just forgot, I have a tendency to do that :)
>> > 
>> > > There is a patch for this issue in linux-next already [1] which is
>> > > part of [2], which was part of the pull request to arm-soc for
>> > > inclusion in v4.9.
>> > >
>> > > [1] https://patchwork.kernel.org/patch/9272457/
>> > > [2] 
>> > > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
>> > 
>> > So the commit in question is:
>> > 
>> > soc: qcom: smd: Correct compile stub prototypes
>> > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9=3a1281848830fcb3202cfd7ffe62d19641471d05
>> > 
>> 
>> Correct
>> 
>> > But that's not obviously in my tree yet, but I should have it after
>> > 4.9-rc1 is released. I think it's easiest that I wait for that before
>> > applying these. Do you agree?
>> > 
>> 
>> Would be nice to have it land sooner rather than later, but I'm okay
>> with this.
>
> We could just treat the tag as immutable.  You can merge the tag in and 
> arm-soc
> can as well.  it'll just get nop'd the second time it is taken.  The only
> downside is if arm-soc doesn't take my merge request.

I take it that you are talking about this tag:

git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git 
qcom-drivers-for-4.9

I did a test pull and there are only 8 commits so in theory that could
work. But my trees go via Dave Miller's net-next so I can't control when
they hit Linus' tree. It might be that Linus pulls the net-next tree
before arm-soc and arm-soc commits coming from net-next might confuse
people. I'm just afraid that the hassle would outweight the benefit.

> Or we can wait till -rc1

To keep things simple I prefer this option. Of course it means waiting
few more extra weeks, but when working with new subsystems that can
happen. The crystall ball[1] says that 4.9-rc1 would be released on
2016-10-16 so it's not that far away.

[1] http://phb-crystal-ball.org/

-- 
Kalle Valo

[PATCH v2 1/1] usb: dwc3: fix Clear Stall EP command failure

[Lu Baolu]

Commit 50c763f8c1bac ("usb: dwc3: Set the ClearPendIN bit on Clear
Stall EP command") sets ClearPendIN bit for all IN endpoints of
v2.60a+ cores. This causes ClearStall command fails on 2.60+ cores
operating in HighSpeed mode.

In page 539 of 2.60a specification:

"When issuing Clear Stall command for IN endpoints in SuperSpeed
mode, the software must set the "ClearPendIN" bit to '1' to
clear any pending IN transcations, so that the device does not
expect any ACK TP from the host for the data sent earlier."

It's obvious that we only need to apply this rule to those IN
endpoints that currently operating in SuperSpeed mode.

Fixes: 50c763f8c1bac ("usb: dwc3: Set the ClearPendIN bit on Clear Stall EP 
command")
Cc:  # v4.7+
Signed-off-by: Lu Baolu 
---
 v1->v2:
 - check current instead of maximum speed
 - improve the commit message

 drivers/usb/dwc3/gadget.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 7a8d3d8..4fd9fda 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -348,7 +348,8 @@ static int dwc3_send_clear_stall_ep_cmd(struct dwc3_ep *dep)
 * IN transfers due to a mishandled error condition. Synopsys
 * STAR 9000614252.
 */
-   if (dep->direction && (dwc->revision >= DWC3_REVISION_260A))
+   if (dep->direction && (dwc->revision >= DWC3_REVISION_260A) &&
+   (dwc->gadget.speed >= USB_SPEED_SUPER))
cmd |= DWC3_DEPCMD_CLEARPENDIN;
 
memset(, 0, sizeof(params));
-- 
2.1.4

[PATCH v2 1/1] usb: dwc3: fix Clear Stall EP command failure

[Lu Baolu]

Commit 50c763f8c1bac ("usb: dwc3: Set the ClearPendIN bit on Clear
Stall EP command") sets ClearPendIN bit for all IN endpoints of
v2.60a+ cores. This causes ClearStall command fails on 2.60+ cores
operating in HighSpeed mode.

In page 539 of 2.60a specification:

"When issuing Clear Stall command for IN endpoints in SuperSpeed
mode, the software must set the "ClearPendIN" bit to '1' to
clear any pending IN transcations, so that the device does not
expect any ACK TP from the host for the data sent earlier."

It's obvious that we only need to apply this rule to those IN
endpoints that currently operating in SuperSpeed mode.

Fixes: 50c763f8c1bac ("usb: dwc3: Set the ClearPendIN bit on Clear Stall EP 
command")
Cc:  # v4.7+
Signed-off-by: Lu Baolu 
---
 v1->v2:
 - check current instead of maximum speed
 - improve the commit message

 drivers/usb/dwc3/gadget.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 7a8d3d8..4fd9fda 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -348,7 +348,8 @@ static int dwc3_send_clear_stall_ep_cmd(struct dwc3_ep *dep)
 * IN transfers due to a mishandled error condition. Synopsys
 * STAR 9000614252.
 */
-   if (dep->direction && (dwc->revision >= DWC3_REVISION_260A))
+   if (dep->direction && (dwc->revision >= DWC3_REVISION_260A) &&
+   (dwc->gadget.speed >= USB_SPEED_SUPER))
cmd |= DWC3_DEPCMD_CLEARPENDIN;
 
memset(, 0, sizeof(params));
-- 
2.1.4

[PATCH v3 1/1] usb: xhci: fix return value of xhci_setup_device()

[Lu Baolu]

xhci_setup_device() should return failure with correct error number
when xhci host has died, removed or halted.

During usb device enumeration, if usb host is not accessible (died,
removed or halted), the hc_driver->address_device() should return
a corresponding error code to usb core. But current xhci driver just
returns success. This misleads usb core to continue the enumeration
by reading the device descriptor, which will result in failure, and
users will get a misleading message like "device descriptor read/8,
error -110".

Cc:  # v4.3+
Signed-off-by: Lu Baolu 
---
 v2->v3:
 - improve the commit description
 v1->v2:
 - fix email mismatch issue

 drivers/usb/host/xhci.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 01d96c9..3e66e73 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3785,8 +3785,10 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct 
usb_device *udev,
 
mutex_lock(>mutex);
 
-   if (xhci->xhc_state)/* dying, removing or halted */
+   if (xhci->xhc_state) {  /* dying, removing or halted */
+   ret = -ESHUTDOWN;
goto out;
+   }
 
if (!udev->slot_id) {
xhci_dbg_trace(xhci, trace_xhci_dbg_address,
-- 
2.1.4

[PATCH v3 1/1] usb: xhci: fix return value of xhci_setup_device()

[Lu Baolu]

xhci_setup_device() should return failure with correct error number
when xhci host has died, removed or halted.

During usb device enumeration, if usb host is not accessible (died,
removed or halted), the hc_driver->address_device() should return
a corresponding error code to usb core. But current xhci driver just
returns success. This misleads usb core to continue the enumeration
by reading the device descriptor, which will result in failure, and
users will get a misleading message like "device descriptor read/8,
error -110".

Cc:  # v4.3+
Signed-off-by: Lu Baolu 
---
 v2->v3:
 - improve the commit description
 v1->v2:
 - fix email mismatch issue

 drivers/usb/host/xhci.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 01d96c9..3e66e73 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3785,8 +3785,10 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct 
usb_device *udev,
 
mutex_lock(>mutex);
 
-   if (xhci->xhc_state)/* dying, removing or halted */
+   if (xhci->xhc_state) {  /* dying, removing or halted */
+   ret = -ESHUTDOWN;
goto out;
+   }
 
if (!udev->slot_id) {
xhci_dbg_trace(xhci, trace_xhci_dbg_address,
-- 
2.1.4

[PATCH v3 2/2] ASoC: rockchip: Add DP dai-links to the rk3399-gru machine driver

[Chris Zhong]

This patch adds DP audio output support to the rk3399-gru machine
driver.

Signed-off-by: Chris Zhong 
---

Changes in v3:
- change spdif to i2s2

Changes in v2:
- correct the commit message

 .../bindings/sound/rockchip,rk3399-gru-sound.txt   | 11 +--
 sound/soc/rockchip/rk3399_gru_sound.c  | 93 ++
 2 files changed, 99 insertions(+), 5 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt 
b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
index f19b6c8..83af540 100644
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
@@ -1,15 +1,16 @@
-ROCKCHIP with MAX98357A/RT5514/DA7219 codecs on GRU boards
+ROCKCHIP with MAX98357A/RT5514/DA7219 codecs and DP via spdif on GRU boards
 
 Required properties:
 - compatible: "rockchip,rk3399-gru-sound"
-- rockchip,cpu: The phandle of the Rockchip I2S controller that's
+- rockchip,cpu: The phandle of the Rockchip I2S controller controller that's
   connected to the codecs
-- rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs
+- rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs and of the
+  DP encoder node
 
 Example:
 
 sound {
compatible = "rockchip,rk3399-gru-sound";
-   rockchip,cpu = <>;
-   rockchip,codec = <  >;
+   rockchip,cpu = < >;
+   rockchip,codec = <   _dp>;
 };
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c 
b/sound/soc/rockchip/rk3399_gru_sound.c
index 164b6da..d9aa2e0 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -214,6 +215,65 @@ static int rockchip_sound_da7219_init(struct 
snd_soc_pcm_runtime *rtd)
return 0;
 }
 
+
+static int rockchip_sound_cdndp_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+   struct snd_soc_dai *codec_dai = rtd->codec_dai;
+   int mclk, ret;
+
+   /* in bypass mode, the mclk has to be one of the frequencies below */
+   switch (params_rate(params)) {
+   case 8000:
+   case 16000:
+   case 24000:
+   case 32000:
+   case 48000:
+   case 64000:
+   case 96000:
+   mclk = 12288000;
+   break;
+   case 11025:
+   case 22050:
+   case 44100:
+   case 88200:
+   mclk = 11289600;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   ret = snd_soc_dai_set_sysclk(cpu_dai, 0, mclk,
+SND_SOC_CLOCK_OUT);
+   if (ret < 0) {
+   dev_err(codec_dai->dev, "Can't set cpu clock out %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static struct snd_soc_jack cdn_dp_card_jack;
+
+static int rockchip_sound_cdndp_init(struct snd_soc_pcm_runtime *runtime)
+{
+   struct snd_soc_card *card = runtime->card;
+   struct snd_soc_codec *codec = runtime->codec;
+   int ret;
+
+   /* enable jack detection */
+   ret = snd_soc_card_jack_new(card, "DP Jack", SND_JACK_LINEOUT,
+   _dp_card_jack, NULL, 0);
+   if (ret) {
+   dev_err(card->dev, "Can't new DP Jack %d\n", ret);
+   return ret;
+   }
+
+   return hdmi_codec_set_jack_detect(codec, _dp_card_jack);
+}
+
 static struct snd_soc_ops rockchip_sound_max98357a_ops = {
.hw_params = rockchip_sound_max98357a_hw_params,
 };
@@ -226,10 +286,15 @@ static struct snd_soc_ops rockchip_sound_da7219_ops = {
.hw_params = rockchip_sound_da7219_hw_params,
 };
 
+static struct snd_soc_ops rockchip_sound_cdndp_ops = {
+   .hw_params = rockchip_sound_cdndp_hw_params,
+};
+
 enum {
DAILINK_MAX98357A,
DAILINK_RT5514,
DAILINK_DA7219,
+   DAILINK_CDNDP,
DAILINK_RT5514_DSP,
 };
 
@@ -264,6 +329,15 @@ static struct snd_soc_dai_link rockchip_dailinks[] = {
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBS_CFS,
},
+   [DAILINK_CDNDP] = {
+   .name = "DP",
+   .stream_name = "DP PCM",
+   .codec_dai_name = "i2s-hifi",
+   .init = rockchip_sound_cdndp_init,
+   .ops = _sound_cdndp_ops,
+   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+   SND_SOC_DAIFMT_CBS_CFS,
+   },
/* RT5514 DSP for voice wakeup via spi bus */
[DAILINK_RT5514_DSP] = {
.name = "RT5514 DSP",
@@ -334,6 +408,25 @@ static int rockchip_sound_probe(struct platform_device 
*pdev)

[PATCH v3 2/2] ASoC: rockchip: Add DP dai-links to the rk3399-gru machine driver

[Chris Zhong]

This patch adds DP audio output support to the rk3399-gru machine
driver.

Signed-off-by: Chris Zhong 
---

Changes in v3:
- change spdif to i2s2

Changes in v2:
- correct the commit message

 .../bindings/sound/rockchip,rk3399-gru-sound.txt   | 11 +--
 sound/soc/rockchip/rk3399_gru_sound.c  | 93 ++
 2 files changed, 99 insertions(+), 5 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt 
b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
index f19b6c8..83af540 100644
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
@@ -1,15 +1,16 @@
-ROCKCHIP with MAX98357A/RT5514/DA7219 codecs on GRU boards
+ROCKCHIP with MAX98357A/RT5514/DA7219 codecs and DP via spdif on GRU boards
 
 Required properties:
 - compatible: "rockchip,rk3399-gru-sound"
-- rockchip,cpu: The phandle of the Rockchip I2S controller that's
+- rockchip,cpu: The phandle of the Rockchip I2S controller controller that's
   connected to the codecs
-- rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs
+- rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs and of the
+  DP encoder node
 
 Example:
 
 sound {
compatible = "rockchip,rk3399-gru-sound";
-   rockchip,cpu = <>;
-   rockchip,codec = <  >;
+   rockchip,cpu = < >;
+   rockchip,codec = <   _dp>;
 };
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c 
b/sound/soc/rockchip/rk3399_gru_sound.c
index 164b6da..d9aa2e0 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -214,6 +215,65 @@ static int rockchip_sound_da7219_init(struct 
snd_soc_pcm_runtime *rtd)
return 0;
 }
 
+
+static int rockchip_sound_cdndp_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+   struct snd_soc_dai *codec_dai = rtd->codec_dai;
+   int mclk, ret;
+
+   /* in bypass mode, the mclk has to be one of the frequencies below */
+   switch (params_rate(params)) {
+   case 8000:
+   case 16000:
+   case 24000:
+   case 32000:
+   case 48000:
+   case 64000:
+   case 96000:
+   mclk = 12288000;
+   break;
+   case 11025:
+   case 22050:
+   case 44100:
+   case 88200:
+   mclk = 11289600;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   ret = snd_soc_dai_set_sysclk(cpu_dai, 0, mclk,
+SND_SOC_CLOCK_OUT);
+   if (ret < 0) {
+   dev_err(codec_dai->dev, "Can't set cpu clock out %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static struct snd_soc_jack cdn_dp_card_jack;
+
+static int rockchip_sound_cdndp_init(struct snd_soc_pcm_runtime *runtime)
+{
+   struct snd_soc_card *card = runtime->card;
+   struct snd_soc_codec *codec = runtime->codec;
+   int ret;
+
+   /* enable jack detection */
+   ret = snd_soc_card_jack_new(card, "DP Jack", SND_JACK_LINEOUT,
+   _dp_card_jack, NULL, 0);
+   if (ret) {
+   dev_err(card->dev, "Can't new DP Jack %d\n", ret);
+   return ret;
+   }
+
+   return hdmi_codec_set_jack_detect(codec, _dp_card_jack);
+}
+
 static struct snd_soc_ops rockchip_sound_max98357a_ops = {
.hw_params = rockchip_sound_max98357a_hw_params,
 };
@@ -226,10 +286,15 @@ static struct snd_soc_ops rockchip_sound_da7219_ops = {
.hw_params = rockchip_sound_da7219_hw_params,
 };
 
+static struct snd_soc_ops rockchip_sound_cdndp_ops = {
+   .hw_params = rockchip_sound_cdndp_hw_params,
+};
+
 enum {
DAILINK_MAX98357A,
DAILINK_RT5514,
DAILINK_DA7219,
+   DAILINK_CDNDP,
DAILINK_RT5514_DSP,
 };
 
@@ -264,6 +329,15 @@ static struct snd_soc_dai_link rockchip_dailinks[] = {
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBS_CFS,
},
+   [DAILINK_CDNDP] = {
+   .name = "DP",
+   .stream_name = "DP PCM",
+   .codec_dai_name = "i2s-hifi",
+   .init = rockchip_sound_cdndp_init,
+   .ops = _sound_cdndp_ops,
+   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+   SND_SOC_DAIFMT_CBS_CFS,
+   },
/* RT5514 DSP for voice wakeup via spi bus */
[DAILINK_RT5514_DSP] = {
.name = "RT5514 DSP",
@@ -334,6 +408,25 @@ static int rockchip_sound_probe(struct platform_device 
*pdev)
return -ENODEV;
  

Re: [PATCH RFC v6] x86,mm,sched: make lazy TLB mode even lazier

[Andy Lutomirski]

On Thu, Sep 8, 2016 at 5:09 PM, Benjamin Serebrin  wrote:
> Sorry for the delay, I was eaten by a grue.
>
> I found that my initial study did not actually measure the number of
> TLB shootdown IPIs sent per TLB shootdown.  I think the intuition was
> correct but I didn't actually observe what I thought I had; my
> original use of probe points was incorrect.  However, after fixing my
> methodology, I'm having trouble proving that the existing Lazy TLB
> mode is working properly.
>
>
>
> I've spent some time trying to reproduce this in a microbenchmark.
> One thread does mmap, touch page, munmap, while other threads in the
> same process are configured to either busy-spin or busy-spin and
> yield.  All threads set their own affinity to a unique cpu, and the
> system is otherwise idle.  I look at the per-cpu delta of the TLB and
> CAL lines of /proc/interrupts over the run of the microbenchmark.
>
> Let's say I have 4 spin threads that never yield.  The mmap thread
> does N unmaps.  I observe each spin-thread core receives N (+/-  small
> noise) TLB shootdown interrupts, and the total TLB interrupt count is
> 4N (+/- small noise).  This is expected behavior.
>
> Then I add some synchronization:  the unmap thread rendezvouses with
> all the spinners, and when they are all ready, the spinners busy-spin
> for D milliseconds and then yield (pthread_yield, sched_yield produce
> identical results, though I'm not confident here that this is the
> right yield).  Meanwhile, the unmap thread busy-spins for D+E
> milliseconds and then does M map/touch/unmaps.  (D, E are single-digit
> milliseconds).  The idea here is that the unmap happens a little while
> after the spinners yielded; the kernel should be in the user process'
> mm but lazy TLB mode should defer TLB flushes.  It seems that lazy
> mode on each CPU should take 1 interrupt and then suppress subsequent
> interrupts.

If they're busy threads, shouldn't the yield return immediately
because the threads are still ready to run?  Lazy TLB won't do much
unless you get the kernel in some state where it's running in the
context of a different kernel thread and hasn't switched to
swapper_pg_dir.  IIRC idle works like that, but you'd need to actually
sleep to go idle.

--Andy

Re: [PATCH RFC v6] x86,mm,sched: make lazy TLB mode even lazier

[Andy Lutomirski]

On Thu, Sep 8, 2016 at 5:09 PM, Benjamin Serebrin  wrote:
> Sorry for the delay, I was eaten by a grue.
>
> I found that my initial study did not actually measure the number of
> TLB shootdown IPIs sent per TLB shootdown.  I think the intuition was
> correct but I didn't actually observe what I thought I had; my
> original use of probe points was incorrect.  However, after fixing my
> methodology, I'm having trouble proving that the existing Lazy TLB
> mode is working properly.
>
>
>
> I've spent some time trying to reproduce this in a microbenchmark.
> One thread does mmap, touch page, munmap, while other threads in the
> same process are configured to either busy-spin or busy-spin and
> yield.  All threads set their own affinity to a unique cpu, and the
> system is otherwise idle.  I look at the per-cpu delta of the TLB and
> CAL lines of /proc/interrupts over the run of the microbenchmark.
>
> Let's say I have 4 spin threads that never yield.  The mmap thread
> does N unmaps.  I observe each spin-thread core receives N (+/-  small
> noise) TLB shootdown interrupts, and the total TLB interrupt count is
> 4N (+/- small noise).  This is expected behavior.
>
> Then I add some synchronization:  the unmap thread rendezvouses with
> all the spinners, and when they are all ready, the spinners busy-spin
> for D milliseconds and then yield (pthread_yield, sched_yield produce
> identical results, though I'm not confident here that this is the
> right yield).  Meanwhile, the unmap thread busy-spins for D+E
> milliseconds and then does M map/touch/unmaps.  (D, E are single-digit
> milliseconds).  The idea here is that the unmap happens a little while
> after the spinners yielded; the kernel should be in the user process'
> mm but lazy TLB mode should defer TLB flushes.  It seems that lazy
> mode on each CPU should take 1 interrupt and then suppress subsequent
> interrupts.

If they're busy threads, shouldn't the yield return immediately
because the threads are still ready to run?  Lazy TLB won't do much
unless you get the kernel in some state where it's running in the
context of a different kernel thread and hasn't switched to
swapper_pg_dir.  IIRC idle works like that, but you'd need to actually
sleep to go idle.

--Andy

linux-next: build failure after merge of the gpio tree

[Stephen Rothwell]

Hi Linus,

After merging the gpio tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/gpio/gpiolib.c: In function '_gpiochip_irqchip_add':
drivers/gpio/gpiolib.c:1622:62: error: macro "WARN_ON" passed 3 arguments, but 
takes just 1
   "%s: Ignoring %d default trigger\n", of_node->full_name))
  ^
drivers/gpio/gpiolib.c:1621:6: error: 'WARN_ON' undeclared (first use in this 
function)
  if (WARN_ON(of_node && type != IRQ_TYPE_NONE,
  ^

Caused by commit

  1ded8b1dafe6 ("gpio/gpiolib: Forbid irqchip default trigger if probed over 
DT")

I used the version of the gpio tree from next-20160908 for today.

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the gpio tree

[Stephen Rothwell]

Hi Linus,

After merging the gpio tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/gpio/gpiolib.c: In function '_gpiochip_irqchip_add':
drivers/gpio/gpiolib.c:1622:62: error: macro "WARN_ON" passed 3 arguments, but 
takes just 1
   "%s: Ignoring %d default trigger\n", of_node->full_name))
  ^
drivers/gpio/gpiolib.c:1621:6: error: 'WARN_ON' undeclared (first use in this 
function)
  if (WARN_ON(of_node && type != IRQ_TYPE_NONE,
  ^

Caused by commit

  1ded8b1dafe6 ("gpio/gpiolib: Forbid irqchip default trigger if probed over 
DT")

I used the version of the gpio tree from next-20160908 for today.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v2 01/17] rpmsg: Enable matching devices with drivers based on DT

[Bjorn Andersson]

On Wed 07 Sep 18:46 PDT 2016, spjo...@codeaurora.org wrote:

> On 2016-09-01 15:27, Bjorn Andersson wrote:
> >Make it possible to match rpmsg devices based on device tree node, in
> >addition to the id table. In some of these cases the rpmsg driver would
> >not have a id_table, so make this optional.
> >
> >Signed-off-by: Bjorn Andersson 
> >---
> >
> >Changes since v1:
> >- None
> >
> > drivers/rpmsg/virtio_rpmsg_bus.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> >diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
> >b/drivers/rpmsg/virtio_rpmsg_bus.c
> >index 4a4374cc6a59..495fa0a282d3 100644
> >--- a/drivers/rpmsg/virtio_rpmsg_bus.c
> >+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> >@@ -33,6 +33,7 @@
> > #include 
> > #include 
> > #include 
> >+#include 
> >
> > /**
> >  * struct virtproc_info - virtual remote processor state
> >@@ -175,11 +176,12 @@ static int rpmsg_dev_match(struct device *dev,
> >struct device_driver *drv)
> > const struct rpmsg_device_id *ids = rpdrv->id_table;
> > unsigned int i;
> >
> >-for (i = 0; ids[i].name[0]; i++)
> >-if (rpmsg_id_match(rpdev, [i]))
> >-return 1;
> >+if (ids)
> >+for (i = 0; ids[i].name[0]; i++)
> >+if (rpmsg_id_match(rpdev, [i]))
> >+return 1;
> >
> >-return 0;
> >+return of_driver_match_device(dev, drv);
> 
> Do we care falling back to acpi_driver_match_device if
> of_driver_match_device fails (something similar to what platform_match
> does)?
> 

I'm not sure how this would look in the case of ACPI, so I would prefer
if we defer that until such case arise.

Regards,
Bjorn

Re: [PATCH v2 01/17] rpmsg: Enable matching devices with drivers based on DT

[Bjorn Andersson]

On Wed 07 Sep 18:46 PDT 2016, spjo...@codeaurora.org wrote:

> On 2016-09-01 15:27, Bjorn Andersson wrote:
> >Make it possible to match rpmsg devices based on device tree node, in
> >addition to the id table. In some of these cases the rpmsg driver would
> >not have a id_table, so make this optional.
> >
> >Signed-off-by: Bjorn Andersson 
> >---
> >
> >Changes since v1:
> >- None
> >
> > drivers/rpmsg/virtio_rpmsg_bus.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> >diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
> >b/drivers/rpmsg/virtio_rpmsg_bus.c
> >index 4a4374cc6a59..495fa0a282d3 100644
> >--- a/drivers/rpmsg/virtio_rpmsg_bus.c
> >+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> >@@ -33,6 +33,7 @@
> > #include 
> > #include 
> > #include 
> >+#include 
> >
> > /**
> >  * struct virtproc_info - virtual remote processor state
> >@@ -175,11 +176,12 @@ static int rpmsg_dev_match(struct device *dev,
> >struct device_driver *drv)
> > const struct rpmsg_device_id *ids = rpdrv->id_table;
> > unsigned int i;
> >
> >-for (i = 0; ids[i].name[0]; i++)
> >-if (rpmsg_id_match(rpdev, [i]))
> >-return 1;
> >+if (ids)
> >+for (i = 0; ids[i].name[0]; i++)
> >+if (rpmsg_id_match(rpdev, [i]))
> >+return 1;
> >
> >-return 0;
> >+return of_driver_match_device(dev, drv);
> 
> Do we care falling back to acpi_driver_match_device if
> of_driver_match_device fails (something similar to what platform_match
> does)?
> 

I'm not sure how this would look in the case of ACPI, so I would prefer
if we defer that until such case arise.

Regards,
Bjorn

Re: [PATCH 2/2] watchdog: constify watchdog_ops structures

[Guenter Roeck]

On 09/01/2016 10:35 AM, Julia Lawall wrote:

Check for watchdog_ops structures that are only stored in the ops field of
a watchdog_device structure.  This field is declared const, so watchdog_ops
structures that have this property can be declared as const also.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct watchdog_ops i@p = { ... };

@ok@
identifier r.i;
struct watchdog_device e;
position p;
@@
e.ops = @p;

@bad@
position p != {r.p,ok.p};
identifier r.i;
struct watchdog_ops e;
@@
e@i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
 struct watchdog_ops i = { ... };
// 

Signed-off-by: Julia Lawall 




Reviewed-by: Guenter Roeck 

Re: [PATCH 2/2] watchdog: constify watchdog_ops structures

[Guenter Roeck]

On 09/01/2016 10:35 AM, Julia Lawall wrote:

Check for watchdog_ops structures that are only stored in the ops field of
a watchdog_device structure.  This field is declared const, so watchdog_ops
structures that have this property can be declared as const also.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct watchdog_ops i@p = { ... };

@ok@
identifier r.i;
struct watchdog_device e;
position p;
@@
e.ops = @p;

@bad@
position p != {r.p,ok.p};
identifier r.i;
struct watchdog_ops e;
@@
e@i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
 struct watchdog_ops i = { ... };
// 

Signed-off-by: Julia Lawall 




Reviewed-by: Guenter Roeck 

Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client

[Andy Gross]

On Thu, Sep 08, 2016 at 09:21:59PM -0700, Bjorn Andersson wrote:
> On Thu 08 Sep 10:35 PDT 2016, Kalle Valo wrote:
> 
> > Bjorn Andersson  writes:
> > 
> > > On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo  wrote:
> > >> Bjorn Andersson  writes:
> > >>
> > >>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> > >>> channel, as such it should be a SMD client. This patch makes this
> > >>> transition, now that we have the necessary frameworks available.
> > >>>
> > >>> Signed-off-by: Bjorn Andersson 
> > >>> ---
> > >>>
> > >>> Changes since v3:
> > >>> - Made msg_header const in wcn36xx_smd_rsp_process()
> > >>>
> > >>> Changes since v2:
> > >>> - Correct the call to the new ieee80211_scan_completed()
> > >>>
> > >>>  drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +++---
> > >>>  drivers/net/wireless/ath/wcn36xx/main.c| 79 
> > >>> --
> > >>>  drivers/net/wireless/ath/wcn36xx/smd.c | 31 +---
> > >>>  drivers/net/wireless/ath/wcn36xx/smd.h |  5 ++
> > >>>  drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 21 +++-
> > >>>  5 files changed, 86 insertions(+), 66 deletions(-)
> > >>
> > >> This doesn't compile for me:
> > >>
> > >
> > > I thought I mentioned this in the mail, sorry for missing that.
> > 
> > Maybe you did and I just forgot, I have a tendency to do that :)
> > 
> > > There is a patch for this issue in linux-next already [1] which is
> > > part of [2], which was part of the pull request to arm-soc for
> > > inclusion in v4.9.
> > >
> > > [1] https://patchwork.kernel.org/patch/9272457/
> > > [2] 
> > > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
> > 
> > So the commit in question is:
> > 
> > soc: qcom: smd: Correct compile stub prototypes
> > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9=3a1281848830fcb3202cfd7ffe62d19641471d05
> > 
> 
> Correct
> 
> > But that's not obviously in my tree yet, but I should have it after
> > 4.9-rc1 is released. I think it's easiest that I wait for that before
> > applying these. Do you agree?
> > 
> 
> Would be nice to have it land sooner rather than later, but I'm okay
> with this.

We could just treat the tag as immutable.  You can merge the tag in and arm-soc
can as well.  it'll just get nop'd the second time it is taken.  The only
downside is if arm-soc doesn't take my merge request.

Or we can wait till -rc1

Regards,

Andy

Re: [PATCH 1/2] watchdog: tegra: constify watchdog_ops structures

[Guenter Roeck]

On 09/01/2016 10:35 AM, Julia Lawall wrote:

Check for watchdog_ops structures that are only stored in the ops field of
a watchdog_device structure.  This field is declared const, so watchdog_ops
structures that have this property can be declared as const also.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct watchdog_ops i@p = { ... };

@ok@
identifier r.i;
struct watchdog_device e;
position p;
@@
e.ops = @p;

@bad@
position p != {r.p,ok.p};
identifier r.i;
struct watchdog_ops e;
@@
e@i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
 struct watchdog_ops i = { ... };
// 

Signed-off-by: Julia Lawall 


Reviewed-by: Guenter Roeck 


---
 drivers/watchdog/tegra_wdt.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/tegra_wdt.c b/drivers/watchdog/tegra_wdt.c
index 9ec5760..2d53c3f 100644
--- a/drivers/watchdog/tegra_wdt.c
+++ b/drivers/watchdog/tegra_wdt.c
@@ -178,7 +178,7 @@ static const struct watchdog_info tegra_wdt_info = {
.identity   = "Tegra Watchdog",
 };

-static struct watchdog_ops tegra_wdt_ops = {
+static const struct watchdog_ops tegra_wdt_ops = {
.owner = THIS_MODULE,
.start = tegra_wdt_start,
.stop = tegra_wdt_stop,

Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client

[Andy Gross]

On Thu, Sep 08, 2016 at 09:21:59PM -0700, Bjorn Andersson wrote:
> On Thu 08 Sep 10:35 PDT 2016, Kalle Valo wrote:
> 
> > Bjorn Andersson  writes:
> > 
> > > On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo  wrote:
> > >> Bjorn Andersson  writes:
> > >>
> > >>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> > >>> channel, as such it should be a SMD client. This patch makes this
> > >>> transition, now that we have the necessary frameworks available.
> > >>>
> > >>> Signed-off-by: Bjorn Andersson 
> > >>> ---
> > >>>
> > >>> Changes since v3:
> > >>> - Made msg_header const in wcn36xx_smd_rsp_process()
> > >>>
> > >>> Changes since v2:
> > >>> - Correct the call to the new ieee80211_scan_completed()
> > >>>
> > >>>  drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +++---
> > >>>  drivers/net/wireless/ath/wcn36xx/main.c| 79 
> > >>> --
> > >>>  drivers/net/wireless/ath/wcn36xx/smd.c | 31 +---
> > >>>  drivers/net/wireless/ath/wcn36xx/smd.h |  5 ++
> > >>>  drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 21 +++-
> > >>>  5 files changed, 86 insertions(+), 66 deletions(-)
> > >>
> > >> This doesn't compile for me:
> > >>
> > >
> > > I thought I mentioned this in the mail, sorry for missing that.
> > 
> > Maybe you did and I just forgot, I have a tendency to do that :)
> > 
> > > There is a patch for this issue in linux-next already [1] which is
> > > part of [2], which was part of the pull request to arm-soc for
> > > inclusion in v4.9.
> > >
> > > [1] https://patchwork.kernel.org/patch/9272457/
> > > [2] 
> > > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
> > 
> > So the commit in question is:
> > 
> > soc: qcom: smd: Correct compile stub prototypes
> > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9=3a1281848830fcb3202cfd7ffe62d19641471d05
> > 
> 
> Correct
> 
> > But that's not obviously in my tree yet, but I should have it after
> > 4.9-rc1 is released. I think it's easiest that I wait for that before
> > applying these. Do you agree?
> > 
> 
> Would be nice to have it land sooner rather than later, but I'm okay
> with this.

We could just treat the tag as immutable.  You can merge the tag in and arm-soc
can as well.  it'll just get nop'd the second time it is taken.  The only
downside is if arm-soc doesn't take my merge request.

Or we can wait till -rc1

Regards,

Andy

Re: [PATCH 1/2] watchdog: tegra: constify watchdog_ops structures

[Guenter Roeck]

On 09/01/2016 10:35 AM, Julia Lawall wrote:

Check for watchdog_ops structures that are only stored in the ops field of
a watchdog_device structure.  This field is declared const, so watchdog_ops
structures that have this property can be declared as const also.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct watchdog_ops i@p = { ... };

@ok@
identifier r.i;
struct watchdog_device e;
position p;
@@
e.ops = @p;

@bad@
position p != {r.p,ok.p};
identifier r.i;
struct watchdog_ops e;
@@
e@i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
 struct watchdog_ops i = { ... };
// 

Signed-off-by: Julia Lawall 


Reviewed-by: Guenter Roeck 


---
 drivers/watchdog/tegra_wdt.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/tegra_wdt.c b/drivers/watchdog/tegra_wdt.c
index 9ec5760..2d53c3f 100644
--- a/drivers/watchdog/tegra_wdt.c
+++ b/drivers/watchdog/tegra_wdt.c
@@ -178,7 +178,7 @@ static const struct watchdog_info tegra_wdt_info = {
.identity   = "Tegra Watchdog",
 };

-static struct watchdog_ops tegra_wdt_ops = {
+static const struct watchdog_ops tegra_wdt_ops = {
.owner = THIS_MODULE,
.start = tegra_wdt_start,
.stop = tegra_wdt_stop,

Re: [PATCH] watchdog: iTCO_wdt: constify iTCO_wdt_pm structure

[Guenter Roeck]

On 08/28/2016 01:26 PM, Julia Lawall wrote:

iTCO_wdt_pm, of type struct dev_pm_ops, is never modified, so declare it as
const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 


Reviewed-by: Guenter Roeck 

Re: [PATCH] watchdog: iTCO_wdt: constify iTCO_wdt_pm structure

[Guenter Roeck]

On 08/28/2016 01:26 PM, Julia Lawall wrote:

iTCO_wdt_pm, of type struct dev_pm_ops, is never modified, so declare it as
const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 


Reviewed-by: Guenter Roeck 

Re: [PATCH v5 1/3] hwmon: iio_hwmon: defer probe when no channel is found

[Guenter Roeck]

On 09/08/2016 07:28 AM, Quentin Schulz wrote:

iio_channel_get_all returns -ENODEV when it cannot find either phandles and
properties in the Device Tree or channels whose consumer_dev_name matches
iio_hwmon in iio_map_list. The iio_map_list is filled in by iio drivers
which might be probed after iio_hwmon.

It is better to defer the probe of iio_hwmon if such error is returned by
iio_channel_get_all in order to let a chance to iio drivers to expose
channels in iio_map_list.

Signed-off-by: Quentin Schulz 
---

v5:
 - patch re-inserted,


Grumble ... applied to -next anyway.

I'll direct any complaints your way ;-)

Guenter

Re: [PATCH v5 1/3] hwmon: iio_hwmon: defer probe when no channel is found

[Guenter Roeck]

On 09/08/2016 07:28 AM, Quentin Schulz wrote:

iio_channel_get_all returns -ENODEV when it cannot find either phandles and
properties in the Device Tree or channels whose consumer_dev_name matches
iio_hwmon in iio_map_list. The iio_map_list is filled in by iio drivers
which might be probed after iio_hwmon.

It is better to defer the probe of iio_hwmon if such error is returned by
iio_channel_get_all in order to let a chance to iio drivers to expose
channels in iio_map_list.

Signed-off-by: Quentin Schulz 
---

v5:
 - patch re-inserted,


Grumble ... applied to -next anyway.

I'll direct any complaints your way ;-)

Guenter

Re: [PATCH v3] hwmon: xgene: Fix crash when alarm occurs before driver probe

[Guenter Roeck]

On 09/08/2016 09:33 AM, Hoan Tran wrote:

The system crashes during probing xgene-hwmon driver when temperature
alarm interrupt occurs before.
It's because
 - xgene_hwmon_probe() requests mailbox channel which also enables
the mailbox interrupt.
 - As temperature alarm interrupt is pending, ISR runs and crashes when accesses
into invalid resourse as unmapped PCC shared memory.

This patch fixes this issue by saving this alarm message and scheduling a
bottom handler after xgene_hwmon_probe() finish.

Signed-off-by: Hoan Tran 
Reported-by: Itaru Kitayama 
---


Applied to -next.

Thanks,
Guenter

Re: [PATCH v3] hwmon: xgene: Fix crash when alarm occurs before driver probe

[Guenter Roeck]

On 09/08/2016 09:33 AM, Hoan Tran wrote:

The system crashes during probing xgene-hwmon driver when temperature
alarm interrupt occurs before.
It's because
 - xgene_hwmon_probe() requests mailbox channel which also enables
the mailbox interrupt.
 - As temperature alarm interrupt is pending, ISR runs and crashes when accesses
into invalid resourse as unmapped PCC shared memory.

This patch fixes this issue by saving this alarm message and scheduling a
bottom handler after xgene_hwmon_probe() finish.

Signed-off-by: Hoan Tran 
Reported-by: Itaru Kitayama 
---


Applied to -next.

Thanks,
Guenter

Re: [PATCH v2 06/33] Documentation, x86: Documentation for Intel resource allocation user interface

[Fenghua Yu]

On Thu, Sep 08, 2016 at 03:45:14PM -0700, Shaohua Li wrote:
> On Thu, Sep 08, 2016 at 06:17:47PM -0700, Fenghua Yu wrote:
> > On Thu, Sep 08, 2016 at 03:01:20PM -0700, Shaohua Li wrote:
> > > On Thu, Sep 08, 2016 at 02:57:00AM -0700, Fenghua Yu wrote:
> > > > From: Fenghua Yu 
> > > > 
> > > > The documentation describes user interface of how to allocate resource
> > > > in Intel RDT.
> > > > 
> > > > Please note that the documentation covers generic user interface. 
> > > > Current
> > > > patch set code only implemente CAT L3. CAT L2 code will be sent later.
> > > > 
> > > > Signed-off-by: Fenghua Yu 
> > > > Reviewed-by: Tony Luck 
> > > > ---
> > > >  Documentation/x86/intel_rdt_ui.txt | 164 
> > > > +
> > > >  1 file changed, 164 insertions(+)
> > > >  create mode 100644 Documentation/x86/intel_rdt_ui.txt
> > > > 
> > > > diff --git a/Documentation/x86/intel_rdt_ui.txt 
> > > > b/Documentation/x86/intel_rdt_ui.txt
> > > > new file mode 100644
> > > > index 000..27de386
> > > > --- /dev/null
> > > > +++ b/Documentation/x86/intel_rdt_ui.txt
> > > > @@ -0,0 +1,164 @@
> > > > +User Interface for Resource Allocation in Intel Resource Director 
> > > > Technology
> > > > +
> > > > +Copyright (C) 2016 Intel Corporation
> > > > +
> > > > +Fenghua Yu 
> > > > +Tony Luck 
> > > > +
> > > > +This feature is enabled by the CONFIG_INTEL_RDT Kconfig and the
> > > > +X86 /proc/cpuinfo flag bits "rdt", "cat_l3" and "cdp_l3".
> > > > +
> > > > +To use the feature mount the file system:
> > > > +
> > > > + # mount -t resctrl resctrl [-o cdp,verbose] /sys/fs/resctrl
> > > > +
> > > > +mount options are:
> > > > +
> > > > +"cdp": Enable code/data prioritization in L3 cache allocations.
> > > > +
> > > > +"verbose": Output more info in the "info" file under info directory
> > > > +   and in dmesg. This is mainly for debug.
> > > > +
> > > > +
> > > > +Resource groups
> > > > +---
> > > > +Resource groups are represented as directories in the resctrl file
> > > > +system. The default group is the root directory. Other groups may be
> > > > +created as desired by the system administrator using the "mkdir(1)"
> > > > +command, and removed using "rmdir(1)".
> > > > +
> > > > +There are three files associated with each group:
> > > > +
> > > > +"tasks": A list of tasks that belongs to this group. Tasks can be
> > > > +   added to a group by writing the task ID to the "tasks" file
> > > > +   (which will automatically remove them from the previous
> > > > +   group to which they belonged). New tasks created by fork(2)
> > > > +   and clone(2) are added to the same group as their parent.
> > > > +   If a pid is not in any sub partition, it is in root partition
> > > > +   (i.e. default partition).
> > > Hi Fenghua,
> > > 
> > > Will you add a 'procs' interface to allow move a process into a group? 
> > > Using
> > > the 'tasks' interface to move process is inconvenient and has race 
> > > conditions
> > > (eg, some new threads could be escaped).
> > 
> > We don't plan to add a 'procs' interface for rdtgroup. We only use resctrl
> > interface to allocate resources.
> > 
> > Why the "tasks" is inconvenient? If sysadmin wants to allocte a portion of 
> > L3
> > for a pid, the operation in resctl is to write the pid to a "tasks". While
> > in 'procs', the operation is to write a partition to a pid. If considering
> > convenience, they are same, right?
> > 
> > A thread uses either default partition (in root dir) or a sub partition (in
> > sub-directory). Sysadmin can control that. Kernel handles race condition.
> > Any issue with that?
> 
> I don't mean writing the 'tasks' file is inconvenient. So to move a process to
> a group, we do:
> 1. get all thread pid of the process
> 2. write every pid to 'tasks'
> 
> this is inconvenient. And if a new thread is created between 1 and 2, we don't
> put the thread to the group. Am I missing anything?

As said in this doc, "New tasks created by fork(2) and clone(2) are added
to the same group as their parent.". So the new thread created b/w 1 and 2
will automatically go to the "tasks" as the process. Later sysadming can
still move any pid to any group.

Is this convenient?

Thanks.

-Fenghua

Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client

[Bjorn Andersson]

On Thu 08 Sep 10:35 PDT 2016, Kalle Valo wrote:

> Bjorn Andersson  writes:
> 
> > On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo  wrote:
> >> Bjorn Andersson  writes:
> >>
> >>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> >>> channel, as such it should be a SMD client. This patch makes this
> >>> transition, now that we have the necessary frameworks available.
> >>>
> >>> Signed-off-by: Bjorn Andersson 
> >>> ---
> >>>
> >>> Changes since v3:
> >>> - Made msg_header const in wcn36xx_smd_rsp_process()
> >>>
> >>> Changes since v2:
> >>> - Correct the call to the new ieee80211_scan_completed()
> >>>
> >>>  drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +++---
> >>>  drivers/net/wireless/ath/wcn36xx/main.c| 79 
> >>> --
> >>>  drivers/net/wireless/ath/wcn36xx/smd.c | 31 +---
> >>>  drivers/net/wireless/ath/wcn36xx/smd.h |  5 ++
> >>>  drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 21 +++-
> >>>  5 files changed, 86 insertions(+), 66 deletions(-)
> >>
> >> This doesn't compile for me:
> >>
> >
> > I thought I mentioned this in the mail, sorry for missing that.
> 
> Maybe you did and I just forgot, I have a tendency to do that :)
> 
> > There is a patch for this issue in linux-next already [1] which is
> > part of [2], which was part of the pull request to arm-soc for
> > inclusion in v4.9.
> >
> > [1] https://patchwork.kernel.org/patch/9272457/
> > [2] 
> > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
> 
> So the commit in question is:
> 
> soc: qcom: smd: Correct compile stub prototypes
> https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9=3a1281848830fcb3202cfd7ffe62d19641471d05
> 

Correct

> But that's not obviously in my tree yet, but I should have it after
> 4.9-rc1 is released. I think it's easiest that I wait for that before
> applying these. Do you agree?
> 

Would be nice to have it land sooner rather than later, but I'm okay
with this.

Regards,
Bjorn

Re: [PATCH v2 06/33] Documentation, x86: Documentation for Intel resource allocation user interface

[Fenghua Yu]

On Thu, Sep 08, 2016 at 03:45:14PM -0700, Shaohua Li wrote:
> On Thu, Sep 08, 2016 at 06:17:47PM -0700, Fenghua Yu wrote:
> > On Thu, Sep 08, 2016 at 03:01:20PM -0700, Shaohua Li wrote:
> > > On Thu, Sep 08, 2016 at 02:57:00AM -0700, Fenghua Yu wrote:
> > > > From: Fenghua Yu 
> > > > 
> > > > The documentation describes user interface of how to allocate resource
> > > > in Intel RDT.
> > > > 
> > > > Please note that the documentation covers generic user interface. 
> > > > Current
> > > > patch set code only implemente CAT L3. CAT L2 code will be sent later.
> > > > 
> > > > Signed-off-by: Fenghua Yu 
> > > > Reviewed-by: Tony Luck 
> > > > ---
> > > >  Documentation/x86/intel_rdt_ui.txt | 164 
> > > > +
> > > >  1 file changed, 164 insertions(+)
> > > >  create mode 100644 Documentation/x86/intel_rdt_ui.txt
> > > > 
> > > > diff --git a/Documentation/x86/intel_rdt_ui.txt 
> > > > b/Documentation/x86/intel_rdt_ui.txt
> > > > new file mode 100644
> > > > index 000..27de386
> > > > --- /dev/null
> > > > +++ b/Documentation/x86/intel_rdt_ui.txt
> > > > @@ -0,0 +1,164 @@
> > > > +User Interface for Resource Allocation in Intel Resource Director 
> > > > Technology
> > > > +
> > > > +Copyright (C) 2016 Intel Corporation
> > > > +
> > > > +Fenghua Yu 
> > > > +Tony Luck 
> > > > +
> > > > +This feature is enabled by the CONFIG_INTEL_RDT Kconfig and the
> > > > +X86 /proc/cpuinfo flag bits "rdt", "cat_l3" and "cdp_l3".
> > > > +
> > > > +To use the feature mount the file system:
> > > > +
> > > > + # mount -t resctrl resctrl [-o cdp,verbose] /sys/fs/resctrl
> > > > +
> > > > +mount options are:
> > > > +
> > > > +"cdp": Enable code/data prioritization in L3 cache allocations.
> > > > +
> > > > +"verbose": Output more info in the "info" file under info directory
> > > > +   and in dmesg. This is mainly for debug.
> > > > +
> > > > +
> > > > +Resource groups
> > > > +---
> > > > +Resource groups are represented as directories in the resctrl file
> > > > +system. The default group is the root directory. Other groups may be
> > > > +created as desired by the system administrator using the "mkdir(1)"
> > > > +command, and removed using "rmdir(1)".
> > > > +
> > > > +There are three files associated with each group:
> > > > +
> > > > +"tasks": A list of tasks that belongs to this group. Tasks can be
> > > > +   added to a group by writing the task ID to the "tasks" file
> > > > +   (which will automatically remove them from the previous
> > > > +   group to which they belonged). New tasks created by fork(2)
> > > > +   and clone(2) are added to the same group as their parent.
> > > > +   If a pid is not in any sub partition, it is in root partition
> > > > +   (i.e. default partition).
> > > Hi Fenghua,
> > > 
> > > Will you add a 'procs' interface to allow move a process into a group? 
> > > Using
> > > the 'tasks' interface to move process is inconvenient and has race 
> > > conditions
> > > (eg, some new threads could be escaped).
> > 
> > We don't plan to add a 'procs' interface for rdtgroup. We only use resctrl
> > interface to allocate resources.
> > 
> > Why the "tasks" is inconvenient? If sysadmin wants to allocte a portion of 
> > L3
> > for a pid, the operation in resctl is to write the pid to a "tasks". While
> > in 'procs', the operation is to write a partition to a pid. If considering
> > convenience, they are same, right?
> > 
> > A thread uses either default partition (in root dir) or a sub partition (in
> > sub-directory). Sysadmin can control that. Kernel handles race condition.
> > Any issue with that?
> 
> I don't mean writing the 'tasks' file is inconvenient. So to move a process to
> a group, we do:
> 1. get all thread pid of the process
> 2. write every pid to 'tasks'
> 
> this is inconvenient. And if a new thread is created between 1 and 2, we don't
> put the thread to the group. Am I missing anything?

As said in this doc, "New tasks created by fork(2) and clone(2) are added
to the same group as their parent.". So the new thread created b/w 1 and 2
will automatically go to the "tasks" as the process. Later sysadming can
still move any pid to any group.

Is this convenient?

Thanks.

-Fenghua

Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client

[Bjorn Andersson]

On Thu 08 Sep 10:35 PDT 2016, Kalle Valo wrote:

> Bjorn Andersson  writes:
> 
> > On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo  wrote:
> >> Bjorn Andersson  writes:
> >>
> >>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> >>> channel, as such it should be a SMD client. This patch makes this
> >>> transition, now that we have the necessary frameworks available.
> >>>
> >>> Signed-off-by: Bjorn Andersson 
> >>> ---
> >>>
> >>> Changes since v3:
> >>> - Made msg_header const in wcn36xx_smd_rsp_process()
> >>>
> >>> Changes since v2:
> >>> - Correct the call to the new ieee80211_scan_completed()
> >>>
> >>>  drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +++---
> >>>  drivers/net/wireless/ath/wcn36xx/main.c| 79 
> >>> --
> >>>  drivers/net/wireless/ath/wcn36xx/smd.c | 31 +---
> >>>  drivers/net/wireless/ath/wcn36xx/smd.h |  5 ++
> >>>  drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 21 +++-
> >>>  5 files changed, 86 insertions(+), 66 deletions(-)
> >>
> >> This doesn't compile for me:
> >>
> >
> > I thought I mentioned this in the mail, sorry for missing that.
> 
> Maybe you did and I just forgot, I have a tendency to do that :)
> 
> > There is a patch for this issue in linux-next already [1] which is
> > part of [2], which was part of the pull request to arm-soc for
> > inclusion in v4.9.
> >
> > [1] https://patchwork.kernel.org/patch/9272457/
> > [2] 
> > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
> 
> So the commit in question is:
> 
> soc: qcom: smd: Correct compile stub prototypes
> https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9=3a1281848830fcb3202cfd7ffe62d19641471d05
> 

Correct

> But that's not obviously in my tree yet, but I should have it after
> 4.9-rc1 is released. I think it's easiest that I wait for that before
> applying these. Do you agree?
> 

Would be nice to have it land sooner rather than later, but I'm okay
with this.

Regards,
Bjorn

Re: [PATCH v4 0/5] kexec_file: Add buffer hand-over for the next kernel

[Eric W. Biederman]

Thiago Jung Bauermann  writes:

> Am Mittwoch, 07 September 2016, 09:19:40 schrieb Eric W. Biederman:
>> ebied...@xmission.com (Eric W. Biederman) writes:
>> > Thiago Jung Bauermann  writes:
>> >> Hello,
>> >> 
>> >> The purpose of this new version of the series is to fix a small issue
>> >> that I found, which is that the kernel doesn't remove the memory
>> >> reservation for the hand-over buffer it received from the previous
>> >> kernel in the device tree it sets up for the next kernel. The result
>> >> is that for each successive kexec, a stale hand-over buffer is left
>> >> behind, wasting memory.
>> >> 
>> >> This is fixed by changes to kexec_free_handover_buffer and
>> >> setup_handover_buffer in patch 2. The other change is to fix checkpatch
>> >> warnings in the last patch.
>> > 
>> > This is fundamentally broken.  You do not increase the integrity of a
>> > system by dropping integrity checks.
>> > 
>> > No. No. No. No.
>> > 
>> > Nacked-by: "Eric W. Biederman" 
>
> The IMA measurement list can be verified without the need of a checksum over 
> its contents by replaying the PCR extend operations and checking that the 
> result matches the registers in the TPM device. So the fact that it is not 
> part of the kexec segments checksum verification doesn't actually reduce the 
> integrity of the system.

Bit flips and errant DMA transfers are the concern here.  That happens
routinely and can easily result in a corrupt data structure which may be
non-trivial to verify.

> Currently, IMA doesn't perform that verification when it restores the 
> measurement list from the kexec handover buffer, so if you believe it's 
> necessary to do that check at boot time, we could do one of the following:
>
> 1. Have IMA replay the PCR extend operations when it restores the 
> measurement list from the handover buffer and validate it against the TPM 
> PCRs, or
>
> 2. Have a buffer hash in the ima_kexec_hdr that IMA includes in the handover 
> buffer, and verify the buffer checksum before restoring the measurement 
> list.
>
> What do you think?

I think you are playing very much with fire and I am extremely
uncomfortable with the entire concept.  I think you are making things
more complicated in a way that will allow system to try and start
booting when their memory is correct.  Which may wind up corrupting
someones non-volatile storage.

It makes me doubly nervous that this adds a general purpose facility
that is generally not at all reusable.

I have seen malicious actors cause entirely too much damage to be at all
comfortable using a data structure before we validate that it was valid
before we started booting.  This isn't the same case but it is close
enough I don't trust someone just splatting data structures.
We can't guarantee integrity but we should not bypass best practices
either.

>> To be constructive the way we have handled similiar situations in the
>> past (hotplu memory) is to call kexec_load again.
>
> Thanks for your suggestion. Unfortunately it's always possible for new 
> measurements to be added to the measurement list between the kexec_file_load 
> and the reboot. We see that happen in practice with system scripts and 
> configuration files that are only read or executed during the reboot 
> process. They are only measured by IMA as a result of the kexec execute.

If I understand what you are saying correctly I expect things could be
setup so that those measurements are forced to happen before kexec load.

Especially in a boot loader context which you described earlier I
believe you should have quite a lot of control of the system.  Having a
facility that fundamentally undermines the design of kexec for a case
where someone might do something you have not predicted does not make me
comfortable.

Which is to say I don't see why you can't measure things before the
kexec_load system call in a tightly controlled setup like a boot loader.
Which should make it that in practice no measurements change.  I believe
that should increase the reliability of the system overall.

Having code in the kernel that updates a buffer that kexec will use
after that buffer is loaded in memory honestely gives me the heebie
jeebies.

Eric

Re: [PATCH v4 0/5] kexec_file: Add buffer hand-over for the next kernel

[Eric W. Biederman]

Thiago Jung Bauermann  writes:

> Am Mittwoch, 07 September 2016, 09:19:40 schrieb Eric W. Biederman:
>> ebied...@xmission.com (Eric W. Biederman) writes:
>> > Thiago Jung Bauermann  writes:
>> >> Hello,
>> >> 
>> >> The purpose of this new version of the series is to fix a small issue
>> >> that I found, which is that the kernel doesn't remove the memory
>> >> reservation for the hand-over buffer it received from the previous
>> >> kernel in the device tree it sets up for the next kernel. The result
>> >> is that for each successive kexec, a stale hand-over buffer is left
>> >> behind, wasting memory.
>> >> 
>> >> This is fixed by changes to kexec_free_handover_buffer and
>> >> setup_handover_buffer in patch 2. The other change is to fix checkpatch
>> >> warnings in the last patch.
>> > 
>> > This is fundamentally broken.  You do not increase the integrity of a
>> > system by dropping integrity checks.
>> > 
>> > No. No. No. No.
>> > 
>> > Nacked-by: "Eric W. Biederman" 
>
> The IMA measurement list can be verified without the need of a checksum over 
> its contents by replaying the PCR extend operations and checking that the 
> result matches the registers in the TPM device. So the fact that it is not 
> part of the kexec segments checksum verification doesn't actually reduce the 
> integrity of the system.

Bit flips and errant DMA transfers are the concern here.  That happens
routinely and can easily result in a corrupt data structure which may be
non-trivial to verify.

> Currently, IMA doesn't perform that verification when it restores the 
> measurement list from the kexec handover buffer, so if you believe it's 
> necessary to do that check at boot time, we could do one of the following:
>
> 1. Have IMA replay the PCR extend operations when it restores the 
> measurement list from the handover buffer and validate it against the TPM 
> PCRs, or
>
> 2. Have a buffer hash in the ima_kexec_hdr that IMA includes in the handover 
> buffer, and verify the buffer checksum before restoring the measurement 
> list.
>
> What do you think?

I think you are playing very much with fire and I am extremely
uncomfortable with the entire concept.  I think you are making things
more complicated in a way that will allow system to try and start
booting when their memory is correct.  Which may wind up corrupting
someones non-volatile storage.

It makes me doubly nervous that this adds a general purpose facility
that is generally not at all reusable.

I have seen malicious actors cause entirely too much damage to be at all
comfortable using a data structure before we validate that it was valid
before we started booting.  This isn't the same case but it is close
enough I don't trust someone just splatting data structures.
We can't guarantee integrity but we should not bypass best practices
either.

>> To be constructive the way we have handled similiar situations in the
>> past (hotplu memory) is to call kexec_load again.
>
> Thanks for your suggestion. Unfortunately it's always possible for new 
> measurements to be added to the measurement list between the kexec_file_load 
> and the reboot. We see that happen in practice with system scripts and 
> configuration files that are only read or executed during the reboot 
> process. They are only measured by IMA as a result of the kexec execute.

If I understand what you are saying correctly I expect things could be
setup so that those measurements are forced to happen before kexec load.

Especially in a boot loader context which you described earlier I
believe you should have quite a lot of control of the system.  Having a
facility that fundamentally undermines the design of kexec for a case
where someone might do something you have not predicted does not make me
comfortable.

Which is to say I don't see why you can't measure things before the
kexec_load system call in a tightly controlled setup like a boot loader.
Which should make it that in practice no measurements change.  I believe
that should increase the reliability of the system overall.

Having code in the kernel that updates a buffer that kexec will use
after that buffer is loaded in memory honestely gives me the heebie
jeebies.

Eric

Re: [PATCH v4 1/4] firmware: Move umh locking code into fw_load_from_user_helper()

[Ming Lei]

On Fri, Sep 9, 2016 at 11:39 AM, Luis R. Rodriguez  wrote:
> On Sep 8, 2016 6:22 PM, "Ming Lei"  wrote:
>>
>> On Fri, Sep 9, 2016 at 4:11 AM, Luis R. Rodriguez 
>> wrote:
>> > On Thu, Sep 08, 2016 at 11:37:54PM +0800, Ming Lei wrote:
>> >> On Wed, Sep 7, 2016 at 4:45 PM, Daniel Wagner  wrote:
>> >> > From: Daniel Wagner 
>> >> >
>> >> > When we load the firmware directly we don't need to take the umh
>> >> > lock.
>> >>
>> >> I am wondering if it can be wrong.
>> >
>> > If you disable the firmware UMH why would we need to lock if the lock is
>> > being
>> > shown only used for the firmare UMH ?
>> >
>> >> Actually in case of firmware loading, the usermode helper lock doesn't
>> >> only mean the user helper is usable, and it also may serve to mark the
>> >> filesystem/block device is ready for firmware loading, and of couse
>> >> direct
>> >> loading need fs/block to be ready too.
>> >
>> > Yes but that's a race I've identified a while ago present even if you
>> > use initramfs *and*
>> > use kernel_read_file_from_path() on any part of the kernel [0], I
>> > proposed a possible
>>
>> Actualy I mean the situation of suspend vs. resume, and some drivers
>> still may not benefit from firmware loading cache when requesting loading
>> in .resume(), at that time it is still too early for direct loading.
>> With UMH lock,
>> we can get a warning or avoid the issue.
>
> Agreed, but that would seem odd and perhaps misleading to have a try lock
> for UMH when no firmware UMH code is enabled. This should probably made
> clear in comments for now as to why we have it then and we should just mark

That is very helpful, :-)

> a TODO item to generalize this to a common freezer check. Surprised we don't
> have one yet. Rafael ?
>
>   Luis

Re: [PATCH v4 1/4] firmware: Move umh locking code into fw_load_from_user_helper()

[Ming Lei]

On Fri, Sep 9, 2016 at 11:39 AM, Luis R. Rodriguez  wrote:
> On Sep 8, 2016 6:22 PM, "Ming Lei"  wrote:
>>
>> On Fri, Sep 9, 2016 at 4:11 AM, Luis R. Rodriguez 
>> wrote:
>> > On Thu, Sep 08, 2016 at 11:37:54PM +0800, Ming Lei wrote:
>> >> On Wed, Sep 7, 2016 at 4:45 PM, Daniel Wagner  wrote:
>> >> > From: Daniel Wagner 
>> >> >
>> >> > When we load the firmware directly we don't need to take the umh
>> >> > lock.
>> >>
>> >> I am wondering if it can be wrong.
>> >
>> > If you disable the firmware UMH why would we need to lock if the lock is
>> > being
>> > shown only used for the firmare UMH ?
>> >
>> >> Actually in case of firmware loading, the usermode helper lock doesn't
>> >> only mean the user helper is usable, and it also may serve to mark the
>> >> filesystem/block device is ready for firmware loading, and of couse
>> >> direct
>> >> loading need fs/block to be ready too.
>> >
>> > Yes but that's a race I've identified a while ago present even if you
>> > use initramfs *and*
>> > use kernel_read_file_from_path() on any part of the kernel [0], I
>> > proposed a possible
>>
>> Actualy I mean the situation of suspend vs. resume, and some drivers
>> still may not benefit from firmware loading cache when requesting loading
>> in .resume(), at that time it is still too early for direct loading.
>> With UMH lock,
>> we can get a warning or avoid the issue.
>
> Agreed, but that would seem odd and perhaps misleading to have a try lock
> for UMH when no firmware UMH code is enabled. This should probably made
> clear in comments for now as to why we have it then and we should just mark

That is very helpful, :-)

> a TODO item to generalize this to a common freezer check. Surprised we don't
> have one yet. Rafael ?
>
>   Luis

Re: [PATCH v5] hwmon: (max6650.c) Add devicetree support

[Guenter Roeck]

On 08/21/2016 11:47 PM, Mike Looijmans wrote:

Parse devicetree parameters for voltage and prescaler setting. This allows
using multiple max6550 devices with varying settings, and also makes it
possible to instantiate and configure the device using devicetree.

Signed-off-by: Mike Looijmans 



Applied to hwmon-next.

Thanks,
Guenter

Re: [PATCH] hwmon: (max6650.c) Add devicetree support documentation

[Guenter Roeck]

On 08/21/2016 11:44 PM, Mike Looijmans wrote:

This adds the devicetree binding documentation for the max6650 fan
controller.

Signed-off-by: Mike Looijmans 


Applied to hwmon-next.

Thanks,
Guenter

Re: [PATCH v5] hwmon: (max6650.c) Add devicetree support

[Guenter Roeck]

On 08/21/2016 11:47 PM, Mike Looijmans wrote:

Parse devicetree parameters for voltage and prescaler setting. This allows
using multiple max6550 devices with varying settings, and also makes it
possible to instantiate and configure the device using devicetree.

Signed-off-by: Mike Looijmans 



Applied to hwmon-next.

Thanks,
Guenter

Re: [PATCH] hwmon: (max6650.c) Add devicetree support documentation

[Guenter Roeck]

On 08/21/2016 11:44 PM, Mike Looijmans wrote:

This adds the devicetree binding documentation for the max6650 fan
controller.

Signed-off-by: Mike Looijmans 


Applied to hwmon-next.

Thanks,
Guenter

Re: [PATCH 1/2] hwmon: (max6650) Allow fan shutdown and initial rpm target

[Guenter Roeck]

On 08/24/2016 01:13 AM, Mike Looijmans wrote:

The fan can be stopped by writing "3" to pwm1_enable in sysfs.

Add devicetree property for early initialization of the fan controller
to prevent overheating, for example when resetting the board while the
fan was completely turned off.

Also improve error reporting, I2C failures were ignored while writing
new values.

Signed-off-by: Mike Looijmans 



Applied to hwmon-next.

Thanks,
Guenter

Re: [PATCH 1/2] hwmon: (max6650) Allow fan shutdown and initial rpm target

[Guenter Roeck]

On 08/24/2016 01:13 AM, Mike Looijmans wrote:

The fan can be stopped by writing "3" to pwm1_enable in sysfs.

Add devicetree property for early initialization of the fan controller
to prevent overheating, for example when resetting the board while the
fan was completely turned off.

Also improve error reporting, I2C failures were ignored while writing
new values.

Signed-off-by: Mike Looijmans 



Applied to hwmon-next.

Thanks,
Guenter

Re: Kernel panic - encryption/decryption failed when open file on Arm64

[xiakaixu]

Sorry for resend this email, just add the linux-cry...@vger.kernel.org
and linux-kernel@vger.kernel.org.


Hi,

Firstly, thanks for your reply!

To reproduce this kernel panic, I test the encryption/decryption feature 
on arm64 board with more memory. Just add the following

change:

diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c
index 0122bec..10ef3f4 100644
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -240,6 +240,7 @@ static int blkcipher_walk_next(struct 
blkcipher_desc *desc,

walk->flags |= BLKCIPHER_WALK_COPY;
if (!walk->page) {
walk->page = (void 
*)__get_free_page(GFP_ATOMIC);

+  walk->page = NULL;
if (!walk->page)
n = 0;
}


This change just set the walk->page to NULL manually.
I get the same crash when open file with the above change log. So I 
think this NULL page failure is not be handled correctly in current code.


Regards
Kaixu Xia


On Thu, Sep 08, 2016 at 08:38:43PM +0800, xiakaixu wrote:

Hi,

I am using the encryption/decryption feature on arm64 board and a kernel
panic occurs just when open a file.  As the memory size of the board
is limited
and there are some page allocation failures before the panic.

Seems it is a kernel bug from the call trace log.

 ...
 - fscrypt_get_encryption_info
   - get_crypt_info.part.1
- validate_user_key.isra.0
 - derive_aes_gcm_key
  - crypto_gcm_decrypt
   - ablk_decrypt
- ctr_encrypt
 - blkcipher_walk_done
   - blkcipher_walk_next
-  __get_free_pages
--> page allocation failure
   ...
- aes_ctr_encrypt
-> the input parameter is
NULL pointer as the page allocation failure


The input parameter of function aes_ctr_encrypt() comes from the
/struct blkcipher_walk//
//walk/, and this variable /walk /is allocated by the function
__get_free_pages(). So if this
page allocate failed, the input parameter of function
aes_ctr_encrypt() will be NULL. The
panic will occurs if we don't check the input parameter.

Not sure about this and wish to get your opinions!


If the page allocation fails in blkcipher_walk_next it'll simply
switch over to processing it block by block. so I don't think the
warning is related to the crash.

Cheers,

Re: Kernel panic - encryption/decryption failed when open file on Arm64

[xiakaixu]

Sorry for resend this email, just add the linux-cry...@vger.kernel.org
and linux-kernel@vger.kernel.org.


Hi,

Firstly, thanks for your reply!

To reproduce this kernel panic, I test the encryption/decryption feature 
on arm64 board with more memory. Just add the following

change:

diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c
index 0122bec..10ef3f4 100644
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -240,6 +240,7 @@ static int blkcipher_walk_next(struct 
blkcipher_desc *desc,

walk->flags |= BLKCIPHER_WALK_COPY;
if (!walk->page) {
walk->page = (void 
*)__get_free_page(GFP_ATOMIC);

+  walk->page = NULL;
if (!walk->page)
n = 0;
}


This change just set the walk->page to NULL manually.
I get the same crash when open file with the above change log. So I 
think this NULL page failure is not be handled correctly in current code.


Regards
Kaixu Xia


On Thu, Sep 08, 2016 at 08:38:43PM +0800, xiakaixu wrote:

Hi,

I am using the encryption/decryption feature on arm64 board and a kernel
panic occurs just when open a file.  As the memory size of the board
is limited
and there are some page allocation failures before the panic.

Seems it is a kernel bug from the call trace log.

 ...
 - fscrypt_get_encryption_info
   - get_crypt_info.part.1
- validate_user_key.isra.0
 - derive_aes_gcm_key
  - crypto_gcm_decrypt
   - ablk_decrypt
- ctr_encrypt
 - blkcipher_walk_done
   - blkcipher_walk_next
-  __get_free_pages
--> page allocation failure
   ...
- aes_ctr_encrypt
-> the input parameter is
NULL pointer as the page allocation failure


The input parameter of function aes_ctr_encrypt() comes from the
/struct blkcipher_walk//
//walk/, and this variable /walk /is allocated by the function
__get_free_pages(). So if this
page allocate failed, the input parameter of function
aes_ctr_encrypt() will be NULL. The
panic will occurs if we don't check the input parameter.

Not sure about this and wish to get your opinions!


If the page allocation fails in blkcipher_walk_next it'll simply
switch over to processing it block by block. so I don't think the
warning is related to the crash.

Cheers,

[PATCH v2] phy: sun4i-usb: Use spinlock to guard phyctl register access

[Chen-Yu Tsai]

The musb driver calls into this phy driver to disable/enable squelch
detection. This function was introduced in 24fe86a617c5 ("phy: sun4i-usb:
Add a sunxi specific function for setting squelch-detect"). This
function in turn calls sun4i_usb_phy_write, which uses a mutex to
guard the common access register. Unfortunately musb does this
in atomic context, which results in the following warning with lock
debugging enabled:

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97
in_atomic(): 1, irqs_disabled(): 128, pid: 96, name: kworker/0:2
CPU: 0 PID: 96 Comm: kworker/0:2 Not tainted 4.8.0-rc4-00181-gd502f8ad1c3e #13
Hardware name: Allwinner sun8i Family
Workqueue: events musb_deassert_reset
[] (unwind_backtrace) from [] (show_stack+0xb/0xc)
[] (show_stack) from [] (dump_stack+0x67/0x74)
[] (dump_stack) from [] (mutex_lock+0x15/0x2c)
[] (mutex_lock) from [] (sun4i_usb_phy_write+0x39/0xec)
[] (sun4i_usb_phy_write) from [] 
(musb_port_reset+0xfb/0x184)
[] (musb_port_reset) from [] (musb_deassert_reset+0x1f/0x2c)
[] (musb_deassert_reset) from [] 
(process_one_work+0x129/0x2b8)
[] (process_one_work) from [] (worker_thread+0xf3/0x424)
[] (worker_thread) from [] (kthread+0xa1/0xb8)
[] (kthread) from [] (ret_from_fork+0x11/0x20)

Since the register access is mmio, we can use a spinlock to guard this
specific access, rather than the mutex that guards the entire phy.

Fixes: ba4bdc9e1dc0 ("PHY: sunxi: Add driver for sunxi usb phy")
Cc: Hans de Goede 
Cc: sta...@vger.kernel.org
Signed-off-by: Chen-Yu Tsai 
---

Changes since v1:

  - Remove the old mutex, since it is no longer used
  - Use irqsave/irqrestore variant of spinlock ops

---
 drivers/phy/phy-sun4i-usb.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index fcf4d95ecc6d..34b7f0c2e019 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -114,7 +115,7 @@ struct sun4i_usb_phy_data {
void __iomem *base;
const struct sun4i_usb_phy_cfg *cfg;
enum usb_dr_mode dr_mode;
-   struct mutex mutex;
+   spinlock_t reg_lock; /* guard access to phyctl reg */
struct sun4i_usb_phy {
struct phy *phy;
void __iomem *pmu;
@@ -181,9 +182,10 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy *phy, 
u32 addr, u32 data,
struct sun4i_usb_phy_data *phy_data = to_sun4i_usb_phy_data(phy);
u32 temp, usbc_bit = BIT(phy->index * 2);
void __iomem *phyctl = phy_data->base + phy_data->cfg->phyctl_offset;
+   unsigned long flags;
int i;
 
-   mutex_lock(_data->mutex);
+   spin_lock_irqsave(_data->reg_lock, flags);
 
if (phy_data->cfg->type == sun8i_a33_phy ||
phy_data->cfg->type == sun50i_a64_phy) {
@@ -221,7 +223,8 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy *phy, 
u32 addr, u32 data,
 
data >>= 1;
}
-   mutex_unlock(_data->mutex);
+
+   spin_unlock_irqrestore(_data->reg_lock, flags);
 }
 
 static void sun4i_usb_phy_passby(struct sun4i_usb_phy *phy, int enable)
@@ -582,7 +585,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
if (!data)
return -ENOMEM;
 
-   mutex_init(>mutex);
+   spin_lock_init(>reg_lock);
INIT_DELAYED_WORK(>detect, sun4i_usb_phy0_id_vbus_det_scan);
dev_set_drvdata(dev, data);
data->cfg = of_device_get_match_data(dev);
-- 
2.9.3

[PATCH v2] phy: sun4i-usb: Use spinlock to guard phyctl register access

[Chen-Yu Tsai]

The musb driver calls into this phy driver to disable/enable squelch
detection. This function was introduced in 24fe86a617c5 ("phy: sun4i-usb:
Add a sunxi specific function for setting squelch-detect"). This
function in turn calls sun4i_usb_phy_write, which uses a mutex to
guard the common access register. Unfortunately musb does this
in atomic context, which results in the following warning with lock
debugging enabled:

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97
in_atomic(): 1, irqs_disabled(): 128, pid: 96, name: kworker/0:2
CPU: 0 PID: 96 Comm: kworker/0:2 Not tainted 4.8.0-rc4-00181-gd502f8ad1c3e #13
Hardware name: Allwinner sun8i Family
Workqueue: events musb_deassert_reset
[] (unwind_backtrace) from [] (show_stack+0xb/0xc)
[] (show_stack) from [] (dump_stack+0x67/0x74)
[] (dump_stack) from [] (mutex_lock+0x15/0x2c)
[] (mutex_lock) from [] (sun4i_usb_phy_write+0x39/0xec)
[] (sun4i_usb_phy_write) from [] 
(musb_port_reset+0xfb/0x184)
[] (musb_port_reset) from [] (musb_deassert_reset+0x1f/0x2c)
[] (musb_deassert_reset) from [] 
(process_one_work+0x129/0x2b8)
[] (process_one_work) from [] (worker_thread+0xf3/0x424)
[] (worker_thread) from [] (kthread+0xa1/0xb8)
[] (kthread) from [] (ret_from_fork+0x11/0x20)

Since the register access is mmio, we can use a spinlock to guard this
specific access, rather than the mutex that guards the entire phy.

Fixes: ba4bdc9e1dc0 ("PHY: sunxi: Add driver for sunxi usb phy")
Cc: Hans de Goede 
Cc: sta...@vger.kernel.org
Signed-off-by: Chen-Yu Tsai 
---

Changes since v1:

  - Remove the old mutex, since it is no longer used
  - Use irqsave/irqrestore variant of spinlock ops

---
 drivers/phy/phy-sun4i-usb.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index fcf4d95ecc6d..34b7f0c2e019 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -114,7 +115,7 @@ struct sun4i_usb_phy_data {
void __iomem *base;
const struct sun4i_usb_phy_cfg *cfg;
enum usb_dr_mode dr_mode;
-   struct mutex mutex;
+   spinlock_t reg_lock; /* guard access to phyctl reg */
struct sun4i_usb_phy {
struct phy *phy;
void __iomem *pmu;
@@ -181,9 +182,10 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy *phy, 
u32 addr, u32 data,
struct sun4i_usb_phy_data *phy_data = to_sun4i_usb_phy_data(phy);
u32 temp, usbc_bit = BIT(phy->index * 2);
void __iomem *phyctl = phy_data->base + phy_data->cfg->phyctl_offset;
+   unsigned long flags;
int i;
 
-   mutex_lock(_data->mutex);
+   spin_lock_irqsave(_data->reg_lock, flags);
 
if (phy_data->cfg->type == sun8i_a33_phy ||
phy_data->cfg->type == sun50i_a64_phy) {
@@ -221,7 +223,8 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy *phy, 
u32 addr, u32 data,
 
data >>= 1;
}
-   mutex_unlock(_data->mutex);
+
+   spin_unlock_irqrestore(_data->reg_lock, flags);
 }
 
 static void sun4i_usb_phy_passby(struct sun4i_usb_phy *phy, int enable)
@@ -582,7 +585,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
if (!data)
return -ENOMEM;
 
-   mutex_init(>mutex);
+   spin_lock_init(>reg_lock);
INIT_DELAYED_WORK(>detect, sun4i_usb_phy0_id_vbus_det_scan);
dev_set_drvdata(dev, data);
data->cfg = of_device_get_match_data(dev);
-- 
2.9.3

Re: [PATCH] autofs - use dentry flags to block walks during expire

[Ian Kent]

On Fri, 2016-09-09 at 11:39 +1000, NeilBrown wrote:
> On Thu, Sep 01 2016, Ian Kent wrote:
> 
> > Somewhere along the way the autofs expire operation has changed to
> > hold a spin lock over expired dentry selection. The autofs indirect
> > mount expired dentry selection is complicated and quite lengthy so
> > it isn't appropriate to hold a spin lock over the operation.
> > 
> > Commit 47be6184 added a might_sleep() to dput() causing a BUG()
> > about this usage to be issued.
> > 
> > But the spin lock doesn't need to be held over this check, the
> > autofs dentry info. flags are enough to block walks into dentrys
> > during the expire.
> > 
> > I've left the direct mount expire as it is (for now) becuase it
> > is much simpler and quicker than the indirect mount expire and
> > adding spin lock release and re-aquires would do nothing more
> > than add overhead.
> > 
> > Signed-off-by: Ian Kent 
> > ---
> >  fs/autofs4/expire.c |   55 +++-
> > ---
> >  1 file changed, 42 insertions(+), 13 deletions(-)
> > 
> > diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
> > index b493909..2d8e176 100644
> > --- a/fs/autofs4/expire.c
> > +++ b/fs/autofs4/expire.c
> > @@ -417,6 +417,7 @@ static struct dentry *should_expire(struct dentry
> > *dentry,
> > }
> > return NULL;
> >  }
> > +
> >  /*
> >   * Find an eligible tree to time-out
> >   * A tree is eligible if :-
> > @@ -432,6 +433,7 @@ struct dentry *autofs4_expire_indirect(struct
> > super_block *sb,
> > struct dentry *root = sb->s_root;
> > struct dentry *dentry;
> > struct dentry *expired;
> > +   struct dentry *found;
> > struct autofs_info *ino;
> >  
> > if (!root)
> > @@ -442,31 +444,46 @@ struct dentry *autofs4_expire_indirect(struct
> > super_block *sb,
> >  
> > dentry = NULL;
> > while ((dentry = get_next_positive_subdir(dentry, root))) {
> > +   int flags = how;
> > +
> > spin_lock(>fs_lock);
> > ino = autofs4_dentry_ino(dentry);
> > -   if (ino->flags & AUTOFS_INF_WANT_EXPIRE)
> > -   expired = NULL;
> > -   else
> > -   expired = should_expire(dentry, mnt, timeout, how);
> > -   if (!expired) {
> > +   if (ino->flags & AUTOFS_INF_WANT_EXPIRE) {
> > spin_unlock(>fs_lock);
> > continue;
> > }
> > +   spin_unlock(>fs_lock);
> > +
> > +   expired = should_expire(dentry, mnt, timeout, flags);
> > +   if (!expired)
> > +   continue;
> > +
> > +   spin_lock(>fs_lock);
> > ino = autofs4_dentry_ino(expired);
> > ino->flags |= AUTOFS_INF_WANT_EXPIRE;
> > spin_unlock(>fs_lock);
> > synchronize_rcu();
> > -   spin_lock(>fs_lock);
> > -   if (should_expire(expired, mnt, timeout, how)) {
> > -   if (expired != dentry)
> > -   dput(dentry);
> > -   goto found;
> > -   }
> >  
> > +   /* Make sure a reference is not taken on found if
> > +* things have changed.
> > +*/
> > +   flags &= ~AUTOFS_EXP_LEAVES;
> > +   found = should_expire(expired, mnt, timeout, how);
> > +   if (!found || found != expired)
> > +   /* Something has changed, continue */
> > +   goto next;
> > +
> > +   if (expired != dentry)
> > +   dput(dentry);
> > +
> > +   spin_lock(>fs_lock);
> > +   goto found;
> > +next:
> > +   spin_lock(>fs_lock);
> > ino->flags &= ~AUTOFS_INF_WANT_EXPIRE;
> > +   spin_unlock(>fs_lock);
> > if (expired != dentry)
> > dput(expired);
> > -   spin_unlock(>fs_lock);
> > }
> > return NULL;
> >  
> > @@ -483,6 +500,7 @@ int autofs4_expire_wait(struct dentry *dentry, int
> > rcu_walk)
> > struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
> > struct autofs_info *ino = autofs4_dentry_ino(dentry);
> > int status;
> > +   int state;
> >  
> > /* Block on any pending expire */
> > if (!(ino->flags & AUTOFS_INF_WANT_EXPIRE))
> > @@ -490,8 +508,19 @@ int autofs4_expire_wait(struct dentry *dentry, int
> > rcu_walk)
> > if (rcu_walk)
> > return -ECHILD;
> >  
> > +retry:
> > spin_lock(>fs_lock);
> > -   if (ino->flags & AUTOFS_INF_EXPIRING) {
> > +   state = ino->flags & (AUTOFS_INF_WANT_EXPIRE |
> > AUTOFS_INF_EXPIRING);
> > +   if (state == AUTOFS_INF_WANT_EXPIRE) {
> > +   spin_unlock(>fs_lock);
> > +   /*
> > +* Possibly being selected for expire, wait until
> > +* it's selected or not.
> > +*/
> > +   schedule_timeout(HZ/10);
> 
> Hi Ian,
> 
> I think you want schedule_timeout_uninterruptible(HZ/10) here.
> schedule_timeout() only causes a delay if the 

Re: [PATCH] autofs - use dentry flags to block walks during expire

[Ian Kent]

On Fri, 2016-09-09 at 11:39 +1000, NeilBrown wrote:
> On Thu, Sep 01 2016, Ian Kent wrote:
> 
> > Somewhere along the way the autofs expire operation has changed to
> > hold a spin lock over expired dentry selection. The autofs indirect
> > mount expired dentry selection is complicated and quite lengthy so
> > it isn't appropriate to hold a spin lock over the operation.
> > 
> > Commit 47be6184 added a might_sleep() to dput() causing a BUG()
> > about this usage to be issued.
> > 
> > But the spin lock doesn't need to be held over this check, the
> > autofs dentry info. flags are enough to block walks into dentrys
> > during the expire.
> > 
> > I've left the direct mount expire as it is (for now) becuase it
> > is much simpler and quicker than the indirect mount expire and
> > adding spin lock release and re-aquires would do nothing more
> > than add overhead.
> > 
> > Signed-off-by: Ian Kent 
> > ---
> >  fs/autofs4/expire.c |   55 +++-
> > ---
> >  1 file changed, 42 insertions(+), 13 deletions(-)
> > 
> > diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
> > index b493909..2d8e176 100644
> > --- a/fs/autofs4/expire.c
> > +++ b/fs/autofs4/expire.c
> > @@ -417,6 +417,7 @@ static struct dentry *should_expire(struct dentry
> > *dentry,
> > }
> > return NULL;
> >  }
> > +
> >  /*
> >   * Find an eligible tree to time-out
> >   * A tree is eligible if :-
> > @@ -432,6 +433,7 @@ struct dentry *autofs4_expire_indirect(struct
> > super_block *sb,
> > struct dentry *root = sb->s_root;
> > struct dentry *dentry;
> > struct dentry *expired;
> > +   struct dentry *found;
> > struct autofs_info *ino;
> >  
> > if (!root)
> > @@ -442,31 +444,46 @@ struct dentry *autofs4_expire_indirect(struct
> > super_block *sb,
> >  
> > dentry = NULL;
> > while ((dentry = get_next_positive_subdir(dentry, root))) {
> > +   int flags = how;
> > +
> > spin_lock(>fs_lock);
> > ino = autofs4_dentry_ino(dentry);
> > -   if (ino->flags & AUTOFS_INF_WANT_EXPIRE)
> > -   expired = NULL;
> > -   else
> > -   expired = should_expire(dentry, mnt, timeout, how);
> > -   if (!expired) {
> > +   if (ino->flags & AUTOFS_INF_WANT_EXPIRE) {
> > spin_unlock(>fs_lock);
> > continue;
> > }
> > +   spin_unlock(>fs_lock);
> > +
> > +   expired = should_expire(dentry, mnt, timeout, flags);
> > +   if (!expired)
> > +   continue;
> > +
> > +   spin_lock(>fs_lock);
> > ino = autofs4_dentry_ino(expired);
> > ino->flags |= AUTOFS_INF_WANT_EXPIRE;
> > spin_unlock(>fs_lock);
> > synchronize_rcu();
> > -   spin_lock(>fs_lock);
> > -   if (should_expire(expired, mnt, timeout, how)) {
> > -   if (expired != dentry)
> > -   dput(dentry);
> > -   goto found;
> > -   }
> >  
> > +   /* Make sure a reference is not taken on found if
> > +* things have changed.
> > +*/
> > +   flags &= ~AUTOFS_EXP_LEAVES;
> > +   found = should_expire(expired, mnt, timeout, how);
> > +   if (!found || found != expired)
> > +   /* Something has changed, continue */
> > +   goto next;
> > +
> > +   if (expired != dentry)
> > +   dput(dentry);
> > +
> > +   spin_lock(>fs_lock);
> > +   goto found;
> > +next:
> > +   spin_lock(>fs_lock);
> > ino->flags &= ~AUTOFS_INF_WANT_EXPIRE;
> > +   spin_unlock(>fs_lock);
> > if (expired != dentry)
> > dput(expired);
> > -   spin_unlock(>fs_lock);
> > }
> > return NULL;
> >  
> > @@ -483,6 +500,7 @@ int autofs4_expire_wait(struct dentry *dentry, int
> > rcu_walk)
> > struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
> > struct autofs_info *ino = autofs4_dentry_ino(dentry);
> > int status;
> > +   int state;
> >  
> > /* Block on any pending expire */
> > if (!(ino->flags & AUTOFS_INF_WANT_EXPIRE))
> > @@ -490,8 +508,19 @@ int autofs4_expire_wait(struct dentry *dentry, int
> > rcu_walk)
> > if (rcu_walk)
> > return -ECHILD;
> >  
> > +retry:
> > spin_lock(>fs_lock);
> > -   if (ino->flags & AUTOFS_INF_EXPIRING) {
> > +   state = ino->flags & (AUTOFS_INF_WANT_EXPIRE |
> > AUTOFS_INF_EXPIRING);
> > +   if (state == AUTOFS_INF_WANT_EXPIRE) {
> > +   spin_unlock(>fs_lock);
> > +   /*
> > +* Possibly being selected for expire, wait until
> > +* it's selected or not.
> > +*/
> > +   schedule_timeout(HZ/10);
> 
> Hi Ian,
> 
> I think you want schedule_timeout_uninterruptible(HZ/10) here.
> schedule_timeout() only causes a delay if the task state has 

Re: [PATCH v8 10/16] mm/memblock: add a new function memblock_alloc_near_nid

[Leizhen (ThunderTown)]

Hi, linux-mm folks:
Can somebody help me to review this patch?
I ran scripts/get_maintainer.pl -f mm/memblock.c and 
scripts/get_maintainer.pl -f mm/, but
the results showed me that there is no maintainer.
To understand this patch should also read patch 11.

On 2016/9/1 14:55, Zhen Lei wrote:
> If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
> actually exist. The percpu variable areas and numa control blocks of that
> memoryless numa nodes must be allocated from the nearest available node
> to improve performance.
> 
> Signed-off-by: Zhen Lei 
> ---
>  include/linux/memblock.h |  1 +
>  mm/memblock.c| 28 
>  2 files changed, 29 insertions(+)
> 
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 2925da2..8e866e0 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -290,6 +290,7 @@ static inline int memblock_get_region_node(const struct 
> memblock_region *r)
> 
>  phys_addr_t memblock_alloc_nid(phys_addr_t size, phys_addr_t align, int nid);
>  phys_addr_t memblock_alloc_try_nid(phys_addr_t size, phys_addr_t align, int 
> nid);
> +phys_addr_t memblock_alloc_near_nid(phys_addr_t size, phys_addr_t align, int 
> nid);
> 
>  phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t align);
> 
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 483197e..6578fff 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1189,6 +1189,34 @@ again:
>   return ret;
>  }
> 
> +phys_addr_t __init memblock_alloc_near_nid(phys_addr_t size, phys_addr_t 
> align, int nid)
> +{
> + int i, best_nid, distance;
> + u64 pa;
> + DECLARE_BITMAP(nodes_map, MAX_NUMNODES);
> +
> + bitmap_zero(nodes_map, MAX_NUMNODES);
> +
> +find_nearest_node:
> + best_nid = NUMA_NO_NODE;
> + distance = INT_MAX;
> +
> + for_each_clear_bit(i, nodes_map, MAX_NUMNODES)
> + if (node_distance(nid, i) < distance) {
> + best_nid = i;
> + distance = node_distance(nid, i);
> + }
> +
> + pa = memblock_alloc_nid(size, align, best_nid);
> + if (!pa) {
> + BUG_ON(best_nid == NUMA_NO_NODE);
> + bitmap_set(nodes_map, best_nid, 1);
> + goto find_nearest_node;
> + }
> +
> + return pa;
> +}
> +
>  phys_addr_t __init __memblock_alloc_base(phys_addr_t size, phys_addr_t 
> align, phys_addr_t max_addr)
>  {
>   return memblock_alloc_base_nid(size, align, max_addr, NUMA_NO_NODE,
> --
> 2.5.0
> 
> 
> 
> .
> 

Re: [PATCH v8 10/16] mm/memblock: add a new function memblock_alloc_near_nid

[Leizhen (ThunderTown)]

Hi, linux-mm folks:
Can somebody help me to review this patch?
I ran scripts/get_maintainer.pl -f mm/memblock.c and 
scripts/get_maintainer.pl -f mm/, but
the results showed me that there is no maintainer.
To understand this patch should also read patch 11.

On 2016/9/1 14:55, Zhen Lei wrote:
> If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
> actually exist. The percpu variable areas and numa control blocks of that
> memoryless numa nodes must be allocated from the nearest available node
> to improve performance.
> 
> Signed-off-by: Zhen Lei 
> ---
>  include/linux/memblock.h |  1 +
>  mm/memblock.c| 28 
>  2 files changed, 29 insertions(+)
> 
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 2925da2..8e866e0 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -290,6 +290,7 @@ static inline int memblock_get_region_node(const struct 
> memblock_region *r)
> 
>  phys_addr_t memblock_alloc_nid(phys_addr_t size, phys_addr_t align, int nid);
>  phys_addr_t memblock_alloc_try_nid(phys_addr_t size, phys_addr_t align, int 
> nid);
> +phys_addr_t memblock_alloc_near_nid(phys_addr_t size, phys_addr_t align, int 
> nid);
> 
>  phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t align);
> 
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 483197e..6578fff 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1189,6 +1189,34 @@ again:
>   return ret;
>  }
> 
> +phys_addr_t __init memblock_alloc_near_nid(phys_addr_t size, phys_addr_t 
> align, int nid)
> +{
> + int i, best_nid, distance;
> + u64 pa;
> + DECLARE_BITMAP(nodes_map, MAX_NUMNODES);
> +
> + bitmap_zero(nodes_map, MAX_NUMNODES);
> +
> +find_nearest_node:
> + best_nid = NUMA_NO_NODE;
> + distance = INT_MAX;
> +
> + for_each_clear_bit(i, nodes_map, MAX_NUMNODES)
> + if (node_distance(nid, i) < distance) {
> + best_nid = i;
> + distance = node_distance(nid, i);
> + }
> +
> + pa = memblock_alloc_nid(size, align, best_nid);
> + if (!pa) {
> + BUG_ON(best_nid == NUMA_NO_NODE);
> + bitmap_set(nodes_map, best_nid, 1);
> + goto find_nearest_node;
> + }
> +
> + return pa;
> +}
> +
>  phys_addr_t __init __memblock_alloc_base(phys_addr_t size, phys_addr_t 
> align, phys_addr_t max_addr)
>  {
>   return memblock_alloc_base_nid(size, align, max_addr, NUMA_NO_NODE,
> --
> 2.5.0
> 
> 
> 
> .
> 

test

[xiakaixu]

Sorry for noise!
--
Regards
Kaixu Xia

Re: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms

[Scott Wood]

On Tue, 2016-09-06 at 16:28 +0800, Yangbo Lu wrote:
> The global utilities block controls power management, I/O device
> enabling, power-onreset(POR) configuration monitoring, alternate
> function selection for multiplexed signals,and clock control.
> 
> This patch adds a driver to manage and access global utilities block.
> Initially only reading SVR and registering soc device are supported.
> Other guts accesses, such as reading RCW, should eventually be moved
> into this driver as well.
> 
> Signed-off-by: Yangbo Lu 
> Signed-off-by: Scott Wood 

Don't put my signoff on patches that I didn't put it on myself.  Definitely
don't put mine *after* yours on patches that were last modified by you.

If you want to mention that the soc_id encoding was my suggestion, then do so
explicitly.

> +/* SoC attribute definition for QorIQ platform */
> +static const struct soc_device_attribute qoriq_soc[] = {
> +#ifdef CONFIG_PPC
> + /*
> +  * Power Architecture-based SoCs T Series
> +  */
> +
> + /* SoC: T1024/T1014/T1023/T1013 Rev: 1.0 */
> + { .soc_id   = "svr:0x85400010,name:T1024,die:T1024",
> +   .revision = "1.0",
> + },
> + { .soc_id   = "svr:0x85480010,name:T1024E,die:T1024",
> +   .revision = "1.0",
> + },

Revision could be computed from the low 8 bits of SVR (just as you do for 
unknown SVRs).

We could move the die name into .family:

{
.soc_id = "svr:0x85490010,name:T1023E,",
.family = "QorIQ T1024",
}

I see you dropped svre (and the trailing comma), though I guess the vast
majority of potential users will be looking at .family.  In which case do we
even need name?  If we just make the soc_id be "svr:0x" then we could
shrink the table to an svr+mask that identifies each die.  I'd still want to
keep the "svr:" even if we're giving up on the general tagging system, to make
it clear what the number refers to, and to provide some defense against users
who match only against soc_id rather than soc_id+family.  Or we could go
further and format soc_id as "QorIQ SVR 0x" so that soc_id-only
matches are fully acceptable rather than just less dangerous.

> +static const struct soc_device_attribute *fsl_soc_device_match(
> + unsigned int svr, const struct soc_device_attribute *matches)
> +{
> + char svr_match[50];
> + int n;
> +
> + n = sprintf(svr_match, "*%08x*", svr);

n = sprintf(svr_match, "svr:0x%08x,*", svr);

(according to the current encoding)

> +
> + do {
> + if (!matches->soc_id)
> + return NULL;
> + if (glob_match(svr_match, matches->soc_id))
> + break;
> + } while (matches++);

Are you expecting "matches++" to ever evaluate as false?

> + /* Register soc device */
> + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> + if (!soc_dev_attr) {
> + ret = -ENOMEM;
> + goto out_unmap;
> + }

Couldn't this be statically allocated?

> +
> + machine = of_flat_dt_get_machine_name();
> + if (machine)
> + soc_dev_attr->machine = kasprintf(GFP_KERNEL, "%s",
> machine);
> +
> + soc_dev_attr->family = kasprintf(GFP_KERNEL, "QorIQ");
> +
> + svr = fsl_guts_get_svr();
> + fsl_soc = fsl_soc_device_match(svr, qoriq_soc);
> + if (fsl_soc) {
> + soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "%s",
> +  fsl_soc->soc_id);

You can use kstrdup() if you're just copying the string as is.

> + soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%s",
> +    fsl_soc->revision);
> + } else {
> + soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "0x%08x",
> svr);

kasprintf(GFP_KERNEL, "svr:0x%08x,", svr);


> +
> + soc_dev = soc_device_register(soc_dev_attr);
> + if (IS_ERR(soc_dev)) {
> + ret = -ENODEV;

Why are you changing the error code?

> + goto out;
> + } else {

Unnecessary "else".

> + pr_info("Detected: %s\n", soc_dev_attr->machine);

Machine: %s

> + pr_info("Detected SoC family: %s\n", soc_dev_attr->family);
> + pr_info("Detected SoC ID: %s, revision: %s\n",
> + soc_dev_attr->soc_id, soc_dev_attr->revision);

s/Detected //g


> + }
> + return 0;
> +out:
> + kfree(soc_dev_attr->machine);
> + kfree(soc_dev_attr->family);
> + kfree(soc_dev_attr->soc_id);
> + kfree(soc_dev_attr->revision);
> + kfree(soc_dev_attr);
> +out_unmap:
> + iounmap(guts->regs);
> +out_free:
> + kfree(guts);

devm

> +static int fsl_guts_remove(struct platform_device *dev)
> +{
> + kfree(soc_dev_attr->machine);
> + kfree(soc_dev_attr->family);
> + kfree(soc_dev_attr->soc_id);
> + kfree(soc_dev_attr->revision);
> + kfree(soc_dev_attr);
> + 

test

[xiakaixu]

Sorry for noise!
--
Regards
Kaixu Xia

Re: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms

[Scott Wood]

On Tue, 2016-09-06 at 16:28 +0800, Yangbo Lu wrote:
> The global utilities block controls power management, I/O device
> enabling, power-onreset(POR) configuration monitoring, alternate
> function selection for multiplexed signals,and clock control.
> 
> This patch adds a driver to manage and access global utilities block.
> Initially only reading SVR and registering soc device are supported.
> Other guts accesses, such as reading RCW, should eventually be moved
> into this driver as well.
> 
> Signed-off-by: Yangbo Lu 
> Signed-off-by: Scott Wood 

Don't put my signoff on patches that I didn't put it on myself.  Definitely
don't put mine *after* yours on patches that were last modified by you.

If you want to mention that the soc_id encoding was my suggestion, then do so
explicitly.

> +/* SoC attribute definition for QorIQ platform */
> +static const struct soc_device_attribute qoriq_soc[] = {
> +#ifdef CONFIG_PPC
> + /*
> +  * Power Architecture-based SoCs T Series
> +  */
> +
> + /* SoC: T1024/T1014/T1023/T1013 Rev: 1.0 */
> + { .soc_id   = "svr:0x85400010,name:T1024,die:T1024",
> +   .revision = "1.0",
> + },
> + { .soc_id   = "svr:0x85480010,name:T1024E,die:T1024",
> +   .revision = "1.0",
> + },

Revision could be computed from the low 8 bits of SVR (just as you do for 
unknown SVRs).

We could move the die name into .family:

{
.soc_id = "svr:0x85490010,name:T1023E,",
.family = "QorIQ T1024",
}

I see you dropped svre (and the trailing comma), though I guess the vast
majority of potential users will be looking at .family.  In which case do we
even need name?  If we just make the soc_id be "svr:0x" then we could
shrink the table to an svr+mask that identifies each die.  I'd still want to
keep the "svr:" even if we're giving up on the general tagging system, to make
it clear what the number refers to, and to provide some defense against users
who match only against soc_id rather than soc_id+family.  Or we could go
further and format soc_id as "QorIQ SVR 0x" so that soc_id-only
matches are fully acceptable rather than just less dangerous.

> +static const struct soc_device_attribute *fsl_soc_device_match(
> + unsigned int svr, const struct soc_device_attribute *matches)
> +{
> + char svr_match[50];
> + int n;
> +
> + n = sprintf(svr_match, "*%08x*", svr);

n = sprintf(svr_match, "svr:0x%08x,*", svr);

(according to the current encoding)

> +
> + do {
> + if (!matches->soc_id)
> + return NULL;
> + if (glob_match(svr_match, matches->soc_id))
> + break;
> + } while (matches++);

Are you expecting "matches++" to ever evaluate as false?

> + /* Register soc device */
> + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> + if (!soc_dev_attr) {
> + ret = -ENOMEM;
> + goto out_unmap;
> + }

Couldn't this be statically allocated?

> +
> + machine = of_flat_dt_get_machine_name();
> + if (machine)
> + soc_dev_attr->machine = kasprintf(GFP_KERNEL, "%s",
> machine);
> +
> + soc_dev_attr->family = kasprintf(GFP_KERNEL, "QorIQ");
> +
> + svr = fsl_guts_get_svr();
> + fsl_soc = fsl_soc_device_match(svr, qoriq_soc);
> + if (fsl_soc) {
> + soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "%s",
> +  fsl_soc->soc_id);

You can use kstrdup() if you're just copying the string as is.

> + soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%s",
> +    fsl_soc->revision);
> + } else {
> + soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "0x%08x",
> svr);

kasprintf(GFP_KERNEL, "svr:0x%08x,", svr);


> +
> + soc_dev = soc_device_register(soc_dev_attr);
> + if (IS_ERR(soc_dev)) {
> + ret = -ENODEV;

Why are you changing the error code?

> + goto out;
> + } else {

Unnecessary "else".

> + pr_info("Detected: %s\n", soc_dev_attr->machine);

Machine: %s

> + pr_info("Detected SoC family: %s\n", soc_dev_attr->family);
> + pr_info("Detected SoC ID: %s, revision: %s\n",
> + soc_dev_attr->soc_id, soc_dev_attr->revision);

s/Detected //g


> + }
> + return 0;
> +out:
> + kfree(soc_dev_attr->machine);
> + kfree(soc_dev_attr->family);
> + kfree(soc_dev_attr->soc_id);
> + kfree(soc_dev_attr->revision);
> + kfree(soc_dev_attr);
> +out_unmap:
> + iounmap(guts->regs);
> +out_free:
> + kfree(guts);

devm

> +static int fsl_guts_remove(struct platform_device *dev)
> +{
> + kfree(soc_dev_attr->machine);
> + kfree(soc_dev_attr->family);
> + kfree(soc_dev_attr->soc_id);
> + kfree(soc_dev_attr->revision);
> + kfree(soc_dev_attr);
> + soc_device_unregister(soc_dev);
> + 

Re: [PATCH] ARM: dts: sun8i: Move A23/A33 usbphy and usb_otg nodes to common dtsi

[Chen-Yu Tsai]

On Fri, Sep 9, 2016 at 4:23 AM, Maxime Ripard
 wrote:
> Hi,
>
> On Thu, Sep 08, 2016 at 11:25:35AM +0800, Chen-Yu Tsai wrote:
>> The usbphy and usb_otg nodes in the A23 and A33 dts files only differ
>> by compatible, and for the usbphy, the size of one of its register
>> regions.
>>
>> Move all the common bits to the A23/A33 common dtsi file.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>
>> Hi Maxime,
>>
>> This patch applies on top of your A23/A33 CCU patches.
>
> It was not applying properly. I think I did the proper fixup, but
> you'll probably want to double check.

Looks correct. Thanks for the fixup.

ChenYu

Re: [PATCH] ARM: dts: sun8i: Move A23/A33 usbphy and usb_otg nodes to common dtsi

[Chen-Yu Tsai]

On Fri, Sep 9, 2016 at 4:23 AM, Maxime Ripard
 wrote:
> Hi,
>
> On Thu, Sep 08, 2016 at 11:25:35AM +0800, Chen-Yu Tsai wrote:
>> The usbphy and usb_otg nodes in the A23 and A33 dts files only differ
>> by compatible, and for the usbphy, the size of one of its register
>> regions.
>>
>> Move all the common bits to the A23/A33 common dtsi file.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>
>> Hi Maxime,
>>
>> This patch applies on top of your A23/A33 CCU patches.
>
> It was not applying properly. I think I did the proper fixup, but
> you'll probably want to double check.

Looks correct. Thanks for the fixup.

ChenYu

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

[Sean Fu]

On Thu, Sep 08, 2016 at 11:25:48PM -0400, Jeff Mahoney wrote:
> On 9/8/16 11:08 PM, Sean Fu wrote:
> > On Tue, Sep 06, 2016 at 11:12:20AM -0400, Jeff Mahoney wrote:
> >> On 9/6/16 5:58 AM, David Sterba wrote:
> >>> On Mon, Sep 05, 2016 at 11:13:40PM -0400, Jeff Mahoney wrote:
> >> Since root is only used to get fs_info->chunk_root, why not use fs_info
> >> directly?
> >
> > Weird.  Exactly this was a part of my fs_info patchset.  I guess I need
> > to go back and check what else is missing.
> 
>  Actually, most of this didn't land.  Pretty much anything that's a root
>  ->fs_info conversion is in there.
> >>>
> >>> Only half of the patchset has been merged so far because it did not pass
> >>> testing, so I bisected to some point. I was about to let you know once
> >>> most of 4.9 patches are prepared so there are less merge conflicts.
> >>
> >> Ok, thanks.  I was going to start the rebase today but I'll hold off
> >> until you're set for 4.9.
> >>
> > Hi Jeff, Could you please share your patch? Where can i get it?
> > I wanna have a look at it.
> 
> Sure, it's the whole series that starts with this commit:
> commit 160ceedfd40085cfb1e08305917fcc24cefdad93
> Author: Jeff Mahoney 
> Date:   Wed Aug 31 23:55:33 2016 -0400
> 
> btrfs: add dynamic debug support
> 
> ... I still need to do clean up some commits that need merging.
> 
> https://git.kernel.org/cgit/linux/kernel/git/jeffm/linux-btrfs.git/log/?h=btrfs-testing/kdave/misc-4.9/root-fsinfo-cleanup
>
Nice work.
Thanks

> -Jeff
> 
> 
> > Thanks
> >> -Jeff
> >>
> >> -- 
> >> Jeff Mahoney
> >> SUSE Labs
> >>
> > 
> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> 
> -- 
> Jeff Mahoney
> SUSE Labs
> 

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

[Sean Fu]

On Thu, Sep 08, 2016 at 11:25:48PM -0400, Jeff Mahoney wrote:
> On 9/8/16 11:08 PM, Sean Fu wrote:
> > On Tue, Sep 06, 2016 at 11:12:20AM -0400, Jeff Mahoney wrote:
> >> On 9/6/16 5:58 AM, David Sterba wrote:
> >>> On Mon, Sep 05, 2016 at 11:13:40PM -0400, Jeff Mahoney wrote:
> >> Since root is only used to get fs_info->chunk_root, why not use fs_info
> >> directly?
> >
> > Weird.  Exactly this was a part of my fs_info patchset.  I guess I need
> > to go back and check what else is missing.
> 
>  Actually, most of this didn't land.  Pretty much anything that's a root
>  ->fs_info conversion is in there.
> >>>
> >>> Only half of the patchset has been merged so far because it did not pass
> >>> testing, so I bisected to some point. I was about to let you know once
> >>> most of 4.9 patches are prepared so there are less merge conflicts.
> >>
> >> Ok, thanks.  I was going to start the rebase today but I'll hold off
> >> until you're set for 4.9.
> >>
> > Hi Jeff, Could you please share your patch? Where can i get it?
> > I wanna have a look at it.
> 
> Sure, it's the whole series that starts with this commit:
> commit 160ceedfd40085cfb1e08305917fcc24cefdad93
> Author: Jeff Mahoney 
> Date:   Wed Aug 31 23:55:33 2016 -0400
> 
> btrfs: add dynamic debug support
> 
> ... I still need to do clean up some commits that need merging.
> 
> https://git.kernel.org/cgit/linux/kernel/git/jeffm/linux-btrfs.git/log/?h=btrfs-testing/kdave/misc-4.9/root-fsinfo-cleanup
>
Nice work.
Thanks

> -Jeff
> 
> 
> > Thanks
> >> -Jeff
> >>
> >> -- 
> >> Jeff Mahoney
> >> SUSE Labs
> >>
> > 
> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> 
> -- 
> Jeff Mahoney
> SUSE Labs
> 

Re: [PATCH] dt-binding: remoteproc: Document generic properties

[Bjorn Andersson]

On Thu 08 Sep 19:33 PDT 2016, Rob Herring wrote:

> On Thu, Sep 8, 2016 at 1:32 PM, Suman Anna  wrote:
> > Hi Rob,
> >
> > On 09/08/2016 11:50 AM, Rob Herring wrote:
> >> On Fri, Sep 02, 2016 at 04:45:45PM -0500, Suman Anna wrote:
> >>> On 08/12/2016 05:42 PM, Bjorn Andersson wrote:
>  On Fri 12 Aug 11:34 PDT 2016, Rob Herring wrote:
> 
> > On Wed, Aug 10, 2016 at 10:37:02AM -0700, Bjorn Andersson wrote:
> >> This documents the generic properties "rprocs" and "rproc-names", used
> >> for consumer drivers to reference a remoteproc node.
> >
> > How do you intend to use this? I wonder if it would not be better to
> > expose a remote proc with existing bindings for a particular purpose
> > (e.g. clocks, resets, etc.) rather than a generic connection. The client
> > side would have to have specific knowledge as to what functions the
> > remote proc provides.
> >
> 
>  The remoteproc node represents the mechanism and resources needed to
>  control the life cycle a co-processor, e.g. loading, booting, shutting
>  gown a video encoder/decoder.
> 
>  The proposed reference allows a separate thingie to assert control of
>  the life cycle of that co-processor.
> 
> 
>  I acknowledge that in some cases there is a fine line between what is
>  the life cycle management and what is the actual functionality
>  implemented by that remote processor. But as the remoteproc mechanism is
>  reusable between various use cases I think it makes sense to not describe
>  them as one unit.
> >>>
> >>> What's the current state of this patch, not officially acked yet right?
> >>
> >> Bjorn and I have discussed some, but probably needs more discussion.
> >> This binding alone is simple enough, but I want to understand better how
> >> it will be used and digesting all the QCom h/w is not simple.
> >
> > OK, thanks. The binding has no bearing on Qcom h/w though.
> 
> Doesn't have to be QCom, I just want to see some user and understand the use.
> 

For other's reference, we discussed two different cases:
1) The Qualcomm video accelerator; a single-use-case co-processor that
when booted provides a video encoder & decoder.

2) The Qualcomm (A)DSP, a multipurpose generic DSP used for audio
effects, audio control/routing, sensor offloading and general
computational workloads.


In #1 Rob's point is that there's only a single piece of hardware, so it
should be described in a single node.
I think it would be beneficial to represent this as two different nodes,
one for the co-processor management and one for the video-related
resources, but I need to investigate this a little bit more.

In #2 we have the resources related to controlling the DSP and when
booted the firmware presents the additional services in a probable
manner; some of these services interacts with resources or provides
resources and must as such be represented in DT.

In either case there's no reason for me to reference a remoteproc
instance - so far at least.


There is a third case, which I have not researched fully yet, where we
need to represent dependencies between remoteprocs; e.g. we must boot
the audio DSP before booting the modem and if the DSP crashes we must
restart the modem.

Regards,
Bjorn

Re: [PATCH] dt-binding: remoteproc: Document generic properties

[Bjorn Andersson]

On Thu 08 Sep 19:33 PDT 2016, Rob Herring wrote:

> On Thu, Sep 8, 2016 at 1:32 PM, Suman Anna  wrote:
> > Hi Rob,
> >
> > On 09/08/2016 11:50 AM, Rob Herring wrote:
> >> On Fri, Sep 02, 2016 at 04:45:45PM -0500, Suman Anna wrote:
> >>> On 08/12/2016 05:42 PM, Bjorn Andersson wrote:
>  On Fri 12 Aug 11:34 PDT 2016, Rob Herring wrote:
> 
> > On Wed, Aug 10, 2016 at 10:37:02AM -0700, Bjorn Andersson wrote:
> >> This documents the generic properties "rprocs" and "rproc-names", used
> >> for consumer drivers to reference a remoteproc node.
> >
> > How do you intend to use this? I wonder if it would not be better to
> > expose a remote proc with existing bindings for a particular purpose
> > (e.g. clocks, resets, etc.) rather than a generic connection. The client
> > side would have to have specific knowledge as to what functions the
> > remote proc provides.
> >
> 
>  The remoteproc node represents the mechanism and resources needed to
>  control the life cycle a co-processor, e.g. loading, booting, shutting
>  gown a video encoder/decoder.
> 
>  The proposed reference allows a separate thingie to assert control of
>  the life cycle of that co-processor.
> 
> 
>  I acknowledge that in some cases there is a fine line between what is
>  the life cycle management and what is the actual functionality
>  implemented by that remote processor. But as the remoteproc mechanism is
>  reusable between various use cases I think it makes sense to not describe
>  them as one unit.
> >>>
> >>> What's the current state of this patch, not officially acked yet right?
> >>
> >> Bjorn and I have discussed some, but probably needs more discussion.
> >> This binding alone is simple enough, but I want to understand better how
> >> it will be used and digesting all the QCom h/w is not simple.
> >
> > OK, thanks. The binding has no bearing on Qcom h/w though.
> 
> Doesn't have to be QCom, I just want to see some user and understand the use.
> 

For other's reference, we discussed two different cases:
1) The Qualcomm video accelerator; a single-use-case co-processor that
when booted provides a video encoder & decoder.

2) The Qualcomm (A)DSP, a multipurpose generic DSP used for audio
effects, audio control/routing, sensor offloading and general
computational workloads.


In #1 Rob's point is that there's only a single piece of hardware, so it
should be described in a single node.
I think it would be beneficial to represent this as two different nodes,
one for the co-processor management and one for the video-related
resources, but I need to investigate this a little bit more.

In #2 we have the resources related to controlling the DSP and when
booted the firmware presents the additional services in a probable
manner; some of these services interacts with resources or provides
resources and must as such be represented in DT.

In either case there's no reason for me to reference a remoteproc
instance - so far at least.


There is a third case, which I have not researched fully yet, where we
need to represent dependencies between remoteprocs; e.g. we must boot
the audio DSP before booting the modem and if the DSP crashes we must
restart the modem.

Regards,
Bjorn

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

[Jeff Mahoney]

On 9/8/16 11:08 PM, Sean Fu wrote:
> On Tue, Sep 06, 2016 at 11:12:20AM -0400, Jeff Mahoney wrote:
>> On 9/6/16 5:58 AM, David Sterba wrote:
>>> On Mon, Sep 05, 2016 at 11:13:40PM -0400, Jeff Mahoney wrote:
>> Since root is only used to get fs_info->chunk_root, why not use fs_info
>> directly?
>
> Weird.  Exactly this was a part of my fs_info patchset.  I guess I need
> to go back and check what else is missing.

 Actually, most of this didn't land.  Pretty much anything that's a root
 ->fs_info conversion is in there.
>>>
>>> Only half of the patchset has been merged so far because it did not pass
>>> testing, so I bisected to some point. I was about to let you know once
>>> most of 4.9 patches are prepared so there are less merge conflicts.
>>
>> Ok, thanks.  I was going to start the rebase today but I'll hold off
>> until you're set for 4.9.
>>
> Hi Jeff, Could you please share your patch? Where can i get it?
> I wanna have a look at it.

Sure, it's the whole series that starts with this commit:
commit 160ceedfd40085cfb1e08305917fcc24cefdad93
Author: Jeff Mahoney 
Date:   Wed Aug 31 23:55:33 2016 -0400

btrfs: add dynamic debug support

... I still need to do clean up some commits that need merging.

https://git.kernel.org/cgit/linux/kernel/git/jeffm/linux-btrfs.git/log/?h=btrfs-testing/kdave/misc-4.9/root-fsinfo-cleanup

-Jeff


> Thanks
>> -Jeff
>>
>> -- 
>> Jeff Mahoney
>> SUSE Labs
>>
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Jeff Mahoney
SUSE Labs



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

[Jeff Mahoney]

On 9/8/16 11:08 PM, Sean Fu wrote:
> On Tue, Sep 06, 2016 at 11:12:20AM -0400, Jeff Mahoney wrote:
>> On 9/6/16 5:58 AM, David Sterba wrote:
>>> On Mon, Sep 05, 2016 at 11:13:40PM -0400, Jeff Mahoney wrote:
>> Since root is only used to get fs_info->chunk_root, why not use fs_info
>> directly?
>
> Weird.  Exactly this was a part of my fs_info patchset.  I guess I need
> to go back and check what else is missing.

 Actually, most of this didn't land.  Pretty much anything that's a root
 ->fs_info conversion is in there.
>>>
>>> Only half of the patchset has been merged so far because it did not pass
>>> testing, so I bisected to some point. I was about to let you know once
>>> most of 4.9 patches are prepared so there are less merge conflicts.
>>
>> Ok, thanks.  I was going to start the rebase today but I'll hold off
>> until you're set for 4.9.
>>
> Hi Jeff, Could you please share your patch? Where can i get it?
> I wanna have a look at it.

Sure, it's the whole series that starts with this commit:
commit 160ceedfd40085cfb1e08305917fcc24cefdad93
Author: Jeff Mahoney 
Date:   Wed Aug 31 23:55:33 2016 -0400

btrfs: add dynamic debug support

... I still need to do clean up some commits that need merging.

https://git.kernel.org/cgit/linux/kernel/git/jeffm/linux-btrfs.git/log/?h=btrfs-testing/kdave/misc-4.9/root-fsinfo-cleanup

-Jeff


> Thanks
>> -Jeff
>>
>> -- 
>> Jeff Mahoney
>> SUSE Labs
>>
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Jeff Mahoney
SUSE Labs



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 2/3] hwmon: xgene: Add hwmon driver

[AKASHI Takahiro]

On Thu, Sep 08, 2016 at 11:47:59AM +0100, James Morse wrote:
> Hi,
> 
> On 08/09/16 09:14, Arnd Bergmann wrote:
> > On Wednesday, September 7, 2016 3:37:05 PM CEST Guenter Roeck wrote:
> >> On Wed, Sep 07, 2016 at 11:41:44PM +0200, Arnd Bergmann wrote:
> >>> On Thursday, July 21, 2016 1:55:56 PM CEST Hoan Tran wrote:
>  +   ctx->comm_base_addr = cppc_ss->base_address;
>  +   if (ctx->comm_base_addr) {
>  +   ctx->pcc_comm_addr =
>  +   
>  acpi_os_ioremap(ctx->comm_base_addr,
>  +   cppc_ss->length);
> 
> >>>
> >>> This causes the arm64 allmodconfig build to fail now, according to
> >>> kernelci:
> >>>
> >>>   1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] 
> >>> undefined!
> >>>
> >>> Should this perhaps call ioremap() or memremap() instead?
> >>>
> >> Hmmm ... almost sounds to me like blaming the messenger. e7cd190385d1 
> >> ("arm64:
> >> mark reserved memblock regions explicitly in iomem") starts using a 
> >> function
> >> in acpi_os_ioremap() which is not exported. On top of that, 
> >> memblock_is_memory()
> >> is declared as __init_memblock, which makes me really uncomfortable.
> >> If acpi_os_ioremap() must not be used by modules, and possibly only during
> >> early (?) initialization, maybe its declaration should state those 
> >> limitations ?
> > 
> > Ah, I didn't notice that. I guess both patches were correct individually and
> > got added to linux-next around the same time but caused allmodconfig to 
> > blow up
> > when used together.
> > 
> > Adding everyone who was involved in the memblock patch to Cc here, maybe one
> > of them has an idea what the correct fix is. There are only two other 
> > drivers
> > using acpi_os_ioremap() and one of them is x86-specific, so it's still 
> > likely
> > that drivers are not actually supposed to use this symbol. Making
> > acpi_os_ioremap() an exported function in arm64 would also work.
> 
> You could use acpi_os_map_iomem()/acpi_os_unmap_iomem() from acpi/acpi_io.h.
> If there isn't an existing mapping these end up in acpi_os_ioremap(), and are
> already EXPORT_SYMBOL_GPL().

acpi_os_ioremap() is re-defined in arm64/include/asm/acpi.h.

The problem is that, as memblock_is_memory() is declared as __init,
we cannot build any drivers which call acpi_os_ioremap() as modules.

As far as this specific issue is concerned, if we make a change like:

===8<===
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -207,7 +207,7 @@ static void __init request_standard_resources(void)
res = alloc_bootmem_low(sizeof(*res));
if (memblock_is_nomap(region)) {
res->name  = "reserved";
-   res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+   res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
} else {
res->name  = "System RAM";
res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
===>8===

and revert the following hunk from the commit:

===8<===
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -12,7 +12,7 @@
 #ifndef _ASM_ACPI_H
 #define _ASM_ACPI_H
 
-#include 
+#include 
 #include 
 
 #include 
@@ -32,7 +32,11 @@
 static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
 {
-   if (!page_is_ram(phys >> PAGE_SHIFT))
+   /*
+* EFI's reserve_regions() call adds memory with the WB attribute
+* to memblock via early_init_dt_add_memory_arch().
+*/
+   if (!memblock_is_memory(phys))
return ioremap(phys, size);
 
return ioremap_cache(phys, size);
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
===>8===

The build error will be gone. (and still kdump should work.)

But I don't know how we should distinguish IORESOURCE_MEM and
IORESOURCE_SYSTEM_RAM.

Thanks,
-Takahiro AKASHI

> (I'm still waiting for allmodconfig on linux-next to finish building)
> 
> 
> Thanks,
> 
> James
> 
> 

Re: [PATCH v3 2/3] hwmon: xgene: Add hwmon driver

[AKASHI Takahiro]

On Thu, Sep 08, 2016 at 11:47:59AM +0100, James Morse wrote:
> Hi,
> 
> On 08/09/16 09:14, Arnd Bergmann wrote:
> > On Wednesday, September 7, 2016 3:37:05 PM CEST Guenter Roeck wrote:
> >> On Wed, Sep 07, 2016 at 11:41:44PM +0200, Arnd Bergmann wrote:
> >>> On Thursday, July 21, 2016 1:55:56 PM CEST Hoan Tran wrote:
>  +   ctx->comm_base_addr = cppc_ss->base_address;
>  +   if (ctx->comm_base_addr) {
>  +   ctx->pcc_comm_addr =
>  +   
>  acpi_os_ioremap(ctx->comm_base_addr,
>  +   cppc_ss->length);
> 
> >>>
> >>> This causes the arm64 allmodconfig build to fail now, according to
> >>> kernelci:
> >>>
> >>>   1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] 
> >>> undefined!
> >>>
> >>> Should this perhaps call ioremap() or memremap() instead?
> >>>
> >> Hmmm ... almost sounds to me like blaming the messenger. e7cd190385d1 
> >> ("arm64:
> >> mark reserved memblock regions explicitly in iomem") starts using a 
> >> function
> >> in acpi_os_ioremap() which is not exported. On top of that, 
> >> memblock_is_memory()
> >> is declared as __init_memblock, which makes me really uncomfortable.
> >> If acpi_os_ioremap() must not be used by modules, and possibly only during
> >> early (?) initialization, maybe its declaration should state those 
> >> limitations ?
> > 
> > Ah, I didn't notice that. I guess both patches were correct individually and
> > got added to linux-next around the same time but caused allmodconfig to 
> > blow up
> > when used together.
> > 
> > Adding everyone who was involved in the memblock patch to Cc here, maybe one
> > of them has an idea what the correct fix is. There are only two other 
> > drivers
> > using acpi_os_ioremap() and one of them is x86-specific, so it's still 
> > likely
> > that drivers are not actually supposed to use this symbol. Making
> > acpi_os_ioremap() an exported function in arm64 would also work.
> 
> You could use acpi_os_map_iomem()/acpi_os_unmap_iomem() from acpi/acpi_io.h.
> If there isn't an existing mapping these end up in acpi_os_ioremap(), and are
> already EXPORT_SYMBOL_GPL().

acpi_os_ioremap() is re-defined in arm64/include/asm/acpi.h.

The problem is that, as memblock_is_memory() is declared as __init,
we cannot build any drivers which call acpi_os_ioremap() as modules.

As far as this specific issue is concerned, if we make a change like:

===8<===
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -207,7 +207,7 @@ static void __init request_standard_resources(void)
res = alloc_bootmem_low(sizeof(*res));
if (memblock_is_nomap(region)) {
res->name  = "reserved";
-   res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+   res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
} else {
res->name  = "System RAM";
res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
===>8===

and revert the following hunk from the commit:

===8<===
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -12,7 +12,7 @@
 #ifndef _ASM_ACPI_H
 #define _ASM_ACPI_H
 
-#include 
+#include 
 #include 
 
 #include 
@@ -32,7 +32,11 @@
 static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
 {
-   if (!page_is_ram(phys >> PAGE_SHIFT))
+   /*
+* EFI's reserve_regions() call adds memory with the WB attribute
+* to memblock via early_init_dt_add_memory_arch().
+*/
+   if (!memblock_is_memory(phys))
return ioremap(phys, size);
 
return ioremap_cache(phys, size);
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
===>8===

The build error will be gone. (and still kdump should work.)

But I don't know how we should distinguish IORESOURCE_MEM and
IORESOURCE_SYSTEM_RAM.

Thanks,
-Takahiro AKASHI

> (I'm still waiting for allmodconfig on linux-next to finish building)
> 
> 
> Thanks,
> 
> James
> 
> 

linux-next: manual merge of the devicetree tree with the imx-mxs tree

[Stephen Rothwell]

Hi Rob,

Today's linux-next merge of the devicetree tree got a conflict in:

  Documentation/devicetree/bindings/vendor-prefixes.txt

between commit:

  8266b4ae7135 ("devicetree: Add vendor prefix for Inverse Path")

from the imx-mxs tree and commit:

  a24f7253f26d ("devicetree: Sort vendor prefixes in alphabetical order")

from the devicetree tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/devicetree/bindings/vendor-prefixes.txt
index cc15e9911dc8,4d95a9ddecdf..
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@@ -136,7 -134,7 +135,8 @@@ innoluxInnolux Corporatio
  intel Intel Corporation
  intercontrol  Inter Control Group
  invensenseInvenSense Inc.
 +inversepath   Inverse Path
+ iom   Iomega Corporation
  isee  ISEE 2007 S.L.
  isil  Intersil
  issi  Integrated Silicon Solutions Inc.

Re: [PATCH V10 1/8] ACPI: I/O Remapping Table (IORT) initial support

[Dennis Chen]

Hi Tomasz,

On Tue, Sep 06, 2016 at 11:08:51AM +0200, Tomasz Nowicki wrote:
[...]
> +static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
> +u32 *rid_out)
> +{
> + /* Single mapping does not care for input id */
> + if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
> + if (type == ACPI_IORT_NODE_NAMED_COMPONENT ||
> + type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
> + *rid_out = map->output_base;
> + return 0;
> + }
> +
> + pr_warn(FW_BUG "[map %p] SINGLE MAPPING flag not allowed for 
> node type %d, skipping ID map\n",
> + map, type);
> + return -ENXIO;
> + }
> +
> + if (rid_in < map->input_base ||
> + (rid_in >= map->input_base + map->id_count))
> + return -ENXIO;
> +
> + *rid_out = map->output_base + (rid_in - map->input_base);
> + return 0;
> +}
> +
> +static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node *node,
> + u32 rid_in, u32 *rid_out,
> + u8 type)
> +{
> + u32 rid = rid_in;
> +
> + /* Parse the ID mapping tree to find specified node type */
> + while (node) {
> + struct acpi_iort_id_mapping *map;
> + int i;
> +
> + if (node->type == type) {
> + if (rid_out)
> + *rid_out = rid;
> + return node;
> + }
> +
> + if (!node->mapping_offset || !node->mapping_count)
> + goto fail_map;
If node->mapping_count is zero, then node->mapping_offset must be zero. A 
firmware bug
otherwise?
> +
> + map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
> +node->mapping_offset);
> +
> + /* Firmware bug! */
> + if (!map->output_reference) {
> + pr_err(FW_BUG "[node %p type %d] ID map has NULL parent 
> reference\n",
> +node, node->type);
> + goto fail_map;
> + }
> +
> + /* Do the RID translation */
> + for (i = 0; i < node->mapping_count; i++, map++) {
> + if (!iort_id_map(map, node->type, rid, ))
> + break;
> + }
>
Just curious about if there is kind of possibility that we can get some 
reduplicated DeviceIDs
with a deliberate ID mapping design in FW for the SMMU/RC node. For instance, 
for a system with 2
PCIe RCs both behind an individual SMMU device, how to make sure the StreamID 
mapped is unique 
across the entire system, the same for DeviceID mapped. 
Anyway, this is my personal confusion, maybe it's not a problem at all for 
current design ;-)

Thanks,
Dennis
> +
> + if (i == node->mapping_count)
> + goto fail_map;
> +
> + node = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
> + map->output_reference);
> + }
> +
> +fail_map:
> + /* Map input RID to output RID unchanged on mapping failure*/
> + if (rid_out)
> + *rid_out = rid_in;
> +
> + return NULL;
> +}
> +
> +static struct acpi_iort_node *iort_find_dev_node(struct device *dev)
> +{
> + struct pci_bus *pbus;
> +
> + if (!dev_is_pci(dev))
> + return iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
> +   iort_match_node_callback, dev);
> +
> + /* Find a PCI root bus */
> + pbus = to_pci_dev(dev)->bus;
> + while (!pci_is_root_bus(pbus))
> + pbus = pbus->parent;
> +
> + return iort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,
> +   iort_match_node_callback, >dev);
> +}
> +
> +void __init acpi_iort_init(void)
> +{
> + acpi_status status;
> +
> + status = acpi_get_table(ACPI_SIG_IORT, 0, _table);
> + if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> + const char *msg = acpi_format_exception(status);
> + pr_err("Failed to get table, %s\n", msg);
> + }
> +}
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 85b7d07..e56e643 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -36,6 +36,7 @@
>  #ifdef CONFIG_X86
>  #include 
>  #endif
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1186,6 +1187,7 @@ static int __init acpi_init(void)
>   }
>  
>   pci_mmcfg_late_init();
> + acpi_iort_init();
>   acpi_scan_init();
>   acpi_ec_init();
>   acpi_debugfs_init();
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> new file mode 100644
> index 000..fcacaf7
> --- /dev/null
> +++ b/include/linux/acpi_iort.h
> @@ -0,0 +1,30 @@
> +/*
> + * Copyright (C) 2016, Semihalf
> + *   Author: Tomasz Nowicki 
> + *
> + * This program is free software; 

linux-next: manual merge of the devicetree tree with the imx-mxs tree

[Stephen Rothwell]

Hi Rob,

Today's linux-next merge of the devicetree tree got a conflict in:

  Documentation/devicetree/bindings/vendor-prefixes.txt

between commit:

  8266b4ae7135 ("devicetree: Add vendor prefix for Inverse Path")

from the imx-mxs tree and commit:

  a24f7253f26d ("devicetree: Sort vendor prefixes in alphabetical order")

from the devicetree tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/devicetree/bindings/vendor-prefixes.txt
index cc15e9911dc8,4d95a9ddecdf..
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@@ -136,7 -134,7 +135,8 @@@ innoluxInnolux Corporatio
  intel Intel Corporation
  intercontrol  Inter Control Group
  invensenseInvenSense Inc.
 +inversepath   Inverse Path
+ iom   Iomega Corporation
  isee  ISEE 2007 S.L.
  isil  Intersil
  issi  Integrated Silicon Solutions Inc.

Re: [PATCH V10 1/8] ACPI: I/O Remapping Table (IORT) initial support

[Dennis Chen]

Hi Tomasz,

On Tue, Sep 06, 2016 at 11:08:51AM +0200, Tomasz Nowicki wrote:
[...]
> +static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
> +u32 *rid_out)
> +{
> + /* Single mapping does not care for input id */
> + if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
> + if (type == ACPI_IORT_NODE_NAMED_COMPONENT ||
> + type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
> + *rid_out = map->output_base;
> + return 0;
> + }
> +
> + pr_warn(FW_BUG "[map %p] SINGLE MAPPING flag not allowed for 
> node type %d, skipping ID map\n",
> + map, type);
> + return -ENXIO;
> + }
> +
> + if (rid_in < map->input_base ||
> + (rid_in >= map->input_base + map->id_count))
> + return -ENXIO;
> +
> + *rid_out = map->output_base + (rid_in - map->input_base);
> + return 0;
> +}
> +
> +static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node *node,
> + u32 rid_in, u32 *rid_out,
> + u8 type)
> +{
> + u32 rid = rid_in;
> +
> + /* Parse the ID mapping tree to find specified node type */
> + while (node) {
> + struct acpi_iort_id_mapping *map;
> + int i;
> +
> + if (node->type == type) {
> + if (rid_out)
> + *rid_out = rid;
> + return node;
> + }
> +
> + if (!node->mapping_offset || !node->mapping_count)
> + goto fail_map;
If node->mapping_count is zero, then node->mapping_offset must be zero. A 
firmware bug
otherwise?
> +
> + map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
> +node->mapping_offset);
> +
> + /* Firmware bug! */
> + if (!map->output_reference) {
> + pr_err(FW_BUG "[node %p type %d] ID map has NULL parent 
> reference\n",
> +node, node->type);
> + goto fail_map;
> + }
> +
> + /* Do the RID translation */
> + for (i = 0; i < node->mapping_count; i++, map++) {
> + if (!iort_id_map(map, node->type, rid, ))
> + break;
> + }
>
Just curious about if there is kind of possibility that we can get some 
reduplicated DeviceIDs
with a deliberate ID mapping design in FW for the SMMU/RC node. For instance, 
for a system with 2
PCIe RCs both behind an individual SMMU device, how to make sure the StreamID 
mapped is unique 
across the entire system, the same for DeviceID mapped. 
Anyway, this is my personal confusion, maybe it's not a problem at all for 
current design ;-)

Thanks,
Dennis
> +
> + if (i == node->mapping_count)
> + goto fail_map;
> +
> + node = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
> + map->output_reference);
> + }
> +
> +fail_map:
> + /* Map input RID to output RID unchanged on mapping failure*/
> + if (rid_out)
> + *rid_out = rid_in;
> +
> + return NULL;
> +}
> +
> +static struct acpi_iort_node *iort_find_dev_node(struct device *dev)
> +{
> + struct pci_bus *pbus;
> +
> + if (!dev_is_pci(dev))
> + return iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
> +   iort_match_node_callback, dev);
> +
> + /* Find a PCI root bus */
> + pbus = to_pci_dev(dev)->bus;
> + while (!pci_is_root_bus(pbus))
> + pbus = pbus->parent;
> +
> + return iort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,
> +   iort_match_node_callback, >dev);
> +}
> +
> +void __init acpi_iort_init(void)
> +{
> + acpi_status status;
> +
> + status = acpi_get_table(ACPI_SIG_IORT, 0, _table);
> + if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> + const char *msg = acpi_format_exception(status);
> + pr_err("Failed to get table, %s\n", msg);
> + }
> +}
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 85b7d07..e56e643 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -36,6 +36,7 @@
>  #ifdef CONFIG_X86
>  #include 
>  #endif
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1186,6 +1187,7 @@ static int __init acpi_init(void)
>   }
>  
>   pci_mmcfg_late_init();
> + acpi_iort_init();
>   acpi_scan_init();
>   acpi_ec_init();
>   acpi_debugfs_init();
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> new file mode 100644
> index 000..fcacaf7
> --- /dev/null
> +++ b/include/linux/acpi_iort.h
> @@ -0,0 +1,30 @@
> +/*
> + * Copyright (C) 2016, Semihalf
> + *   Author: Tomasz Nowicki 
> + *
> + * This program is free software; you can 

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

[Sean Fu]

On Tue, Sep 06, 2016 at 11:12:20AM -0400, Jeff Mahoney wrote:
> On 9/6/16 5:58 AM, David Sterba wrote:
> > On Mon, Sep 05, 2016 at 11:13:40PM -0400, Jeff Mahoney wrote:
>  Since root is only used to get fs_info->chunk_root, why not use fs_info
>  directly?
> >>>
> >>> Weird.  Exactly this was a part of my fs_info patchset.  I guess I need
> >>> to go back and check what else is missing.
> >>
> >> Actually, most of this didn't land.  Pretty much anything that's a root
> >> ->fs_info conversion is in there.
> > 
> > Only half of the patchset has been merged so far because it did not pass
> > testing, so I bisected to some point. I was about to let you know once
> > most of 4.9 patches are prepared so there are less merge conflicts.
> 
> Ok, thanks.  I was going to start the rebase today but I'll hold off
> until you're set for 4.9.
> 
Hi Jeff, Could you please share your patch? Where can i get it?
I wanna have a look at it.

Thanks
> -Jeff
> 
> -- 
> Jeff Mahoney
> SUSE Labs
> 

Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.

[Sean Fu]

On Tue, Sep 06, 2016 at 11:12:20AM -0400, Jeff Mahoney wrote:
> On 9/6/16 5:58 AM, David Sterba wrote:
> > On Mon, Sep 05, 2016 at 11:13:40PM -0400, Jeff Mahoney wrote:
>  Since root is only used to get fs_info->chunk_root, why not use fs_info
>  directly?
> >>>
> >>> Weird.  Exactly this was a part of my fs_info patchset.  I guess I need
> >>> to go back and check what else is missing.
> >>
> >> Actually, most of this didn't land.  Pretty much anything that's a root
> >> ->fs_info conversion is in there.
> > 
> > Only half of the patchset has been merged so far because it did not pass
> > testing, so I bisected to some point. I was about to let you know once
> > most of 4.9 patches are prepared so there are less merge conflicts.
> 
> Ok, thanks.  I was going to start the rebase today but I'll hold off
> until you're set for 4.9.
> 
Hi Jeff, Could you please share your patch? Where can i get it?
I wanna have a look at it.

Thanks
> -Jeff
> 
> -- 
> Jeff Mahoney
> SUSE Labs
>