[PATCH v2] selftests: intel_pstate: ftime() is deprecated

[Tommi Rantala]

Use clock_gettime() instead of deprecated ftime().

  aperf.c: In function ‘main’:
  aperf.c:58:2: warning: ‘ftime’ is deprecated [-Wdeprecated-declarations]
 58 |  ftime();
|  ^
  In file included from aperf.c:9:
  /usr/include/sys/timeb.h:39:12: note: declared here
 39 | extern int ftime (struct timeb *__timebuf)
|^

Signed-off-by: Tommi Rantala 
---
 tools/testing/selftests/intel_pstate/aperf.c | 22 ++--
 1 file changed, 16 insertions(+), 6 deletions(-)

v2: define and use NSEC_PER_MSEC and MSEC_PER_SEC

diff --git a/tools/testing/selftests/intel_pstate/aperf.c 
b/tools/testing/selftests/intel_pstate/aperf.c
index f6cd03a87493..a8acf3996973 100644
--- a/tools/testing/selftests/intel_pstate/aperf.c
+++ b/tools/testing/selftests/intel_pstate/aperf.c
@@ -10,8 +10,12 @@
 #include 
 #include 
 #include 
+#include 
 #include "../kselftest.h"
 
+#define MSEC_PER_SEC   1000L
+#define NSEC_PER_MSEC  100L
+
 void usage(char *name) {
printf ("Usage: %s cpunum\n", name);
 }
@@ -22,7 +26,7 @@ int main(int argc, char **argv) {
long long tsc, old_tsc, new_tsc;
long long aperf, old_aperf, new_aperf;
long long mperf, old_mperf, new_mperf;
-   struct timeb before, after;
+   struct timespec before, after;
long long int start, finish, total;
cpu_set_t cpuset;
 
@@ -55,7 +59,10 @@ int main(int argc, char **argv) {
return 1;
}
 
-   ftime();
+   if (clock_gettime(CLOCK_MONOTONIC, ) < 0) {
+   perror("clock_gettime");
+   return 1;
+   }
pread(fd, _tsc,  sizeof(old_tsc), 0x10);
pread(fd, _aperf,  sizeof(old_mperf), 0xe7);
pread(fd, _mperf,  sizeof(old_aperf), 0xe8);
@@ -64,7 +71,10 @@ int main(int argc, char **argv) {
sqrt(i);
}
 
-   ftime();
+   if (clock_gettime(CLOCK_MONOTONIC, ) < 0) {
+   perror("clock_gettime");
+   return 1;
+   }
pread(fd, _tsc,  sizeof(new_tsc), 0x10);
pread(fd, _aperf,  sizeof(new_mperf), 0xe7);
pread(fd, _mperf,  sizeof(new_aperf), 0xe8);
@@ -73,11 +83,11 @@ int main(int argc, char **argv) {
aperf = new_aperf-old_aperf;
mperf = new_mperf-old_mperf;
 
-   start = before.time*1000 + before.millitm;
-   finish = after.time*1000 + after.millitm;
+   start = before.tv_sec*MSEC_PER_SEC + before.tv_nsec/NSEC_PER_MSEC;
+   finish = after.tv_sec*MSEC_PER_SEC + after.tv_nsec/NSEC_PER_MSEC;
total = finish - start;
 
-   printf("runTime: %4.2f\n", 1.0*total/1000);
+   printf("runTime: %4.2f\n", 1.0*total/MSEC_PER_SEC);
printf("freq: %7.0f\n", tsc / (1.0*aperf / (1.0 * mperf)) / total);
return 0;
 }
-- 
2.26.2

[PATCH] selftests: intel_pstate: ftime() is deprecated

[Tommi Rantala]

Use clock_gettime() instead of deprecated ftime().

  aperf.c: In function ‘main’:
  aperf.c:58:2: warning: ‘ftime’ is deprecated [-Wdeprecated-declarations]
 58 |  ftime();
|  ^
  In file included from aperf.c:9:
  /usr/include/sys/timeb.h:39:12: note: declared here
 39 | extern int ftime (struct timeb *__timebuf)
|^

Signed-off-by: Tommi Rantala 
---
 tools/testing/selftests/intel_pstate/aperf.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/tools/testing/selftests/intel_pstate/aperf.c 
b/tools/testing/selftests/intel_pstate/aperf.c
index f6cd03a87493..eea9dbab459b 100644
--- a/tools/testing/selftests/intel_pstate/aperf.c
+++ b/tools/testing/selftests/intel_pstate/aperf.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "../kselftest.h"
 
 void usage(char *name) {
@@ -22,7 +23,7 @@ int main(int argc, char **argv) {
long long tsc, old_tsc, new_tsc;
long long aperf, old_aperf, new_aperf;
long long mperf, old_mperf, new_mperf;
-   struct timeb before, after;
+   struct timespec before, after;
long long int start, finish, total;
cpu_set_t cpuset;
 
@@ -55,7 +56,10 @@ int main(int argc, char **argv) {
return 1;
}
 
-   ftime();
+   if (clock_gettime(CLOCK_MONOTONIC, ) < 0) {
+   perror("clock_gettime");
+   return 1;
+   }
pread(fd, _tsc,  sizeof(old_tsc), 0x10);
pread(fd, _aperf,  sizeof(old_mperf), 0xe7);
pread(fd, _mperf,  sizeof(old_aperf), 0xe8);
@@ -64,7 +68,10 @@ int main(int argc, char **argv) {
sqrt(i);
}
 
-   ftime();
+   if (clock_gettime(CLOCK_MONOTONIC, ) < 0) {
+   perror("clock_gettime");
+   return 1;
+   }
pread(fd, _tsc,  sizeof(new_tsc), 0x10);
pread(fd, _aperf,  sizeof(new_mperf), 0xe7);
pread(fd, _mperf,  sizeof(new_aperf), 0xe8);
@@ -73,8 +80,8 @@ int main(int argc, char **argv) {
aperf = new_aperf-old_aperf;
mperf = new_mperf-old_mperf;
 
-   start = before.time*1000 + before.millitm;
-   finish = after.time*1000 + after.millitm;
+   start = before.tv_sec*1000 + before.tv_nsec/100L;
+   finish = after.tv_sec*1000 + after.tv_nsec/100L;
total = finish - start;
 
printf("runTime: %4.2f\n", 1.0*total/1000);
-- 
2.26.2

[PATCH] perf test: Implement skip_reason callback for watchpoint tests

[Tommi Rantala]

Currently reason for skipping the read only watchpoint test is only seen
when running in verbose mode:

  $ perf test watchpoint
  23: Watchpoint:
  23.1: Read Only Watchpoint: Skip
  23.2: Write Only Watchpoint   : Ok
  23.3: Read / Write Watchpoint : Ok
  23.4: Modify Watchpoint   : Ok

  $ perf test -v watchpoint
  23: Watchpoint:
  23.1: Read Only Watchpoint:
  --- start ---
  test child forked, pid 60204
  Hardware does not support read only watchpoints.
  test child finished with -2

Implement skip_reason callback for the watchpoint tests, so that it's
easy to see reason why the test is skipped:

  $ perf test watchpoint
  23: Watchpoint:
  23.1: Read Only Watchpoint: Skip (missing 
hardware support)
  23.2: Write Only Watchpoint   : Ok
  23.3: Read / Write Watchpoint : Ok
  23.4: Modify Watchpoint   : Ok

Signed-off-by: Tommi Rantala 
---
 tools/perf/tests/builtin-test.c |  1 +
 tools/perf/tests/tests.h|  1 +
 tools/perf/tests/wp.c   | 21 +++--
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index d328caaba45d..3bfad4ee31ae 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -142,6 +142,7 @@ static struct test generic_tests[] = {
.skip_if_fail   = false,
.get_nr = test__wp_subtest_get_nr,
.get_desc   = test__wp_subtest_get_desc,
+   .skip_reason= test__wp_subtest_skip_reason,
},
},
{
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index 4447a516c689..0630301087a6 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -66,6 +66,7 @@ int test__bp_signal_overflow(struct test *test, int subtest);
 int test__bp_accounting(struct test *test, int subtest);
 int test__wp(struct test *test, int subtest);
 const char *test__wp_subtest_get_desc(int subtest);
+const char *test__wp_subtest_skip_reason(int subtest);
 int test__wp_subtest_get_nr(void);
 int test__task_exit(struct test *test, int subtest);
 int test__mem(struct test *test, int subtest);
diff --git a/tools/perf/tests/wp.c b/tools/perf/tests/wp.c
index d262d6639829..9387fa76faa5 100644
--- a/tools/perf/tests/wp.c
+++ b/tools/perf/tests/wp.c
@@ -174,10 +174,12 @@ static bool wp_ro_supported(void)
 #endif
 }
 
-static void wp_ro_skip_msg(void)
+static const char *wp_ro_skip_msg(void)
 {
 #if defined (__x86_64__) || defined (__i386__)
-   pr_debug("Hardware does not support read only watchpoints.\n");
+   return "missing hardware support";
+#else
+   return NULL;
 #endif
 }
 
@@ -185,7 +187,7 @@ static struct {
const char *desc;
int (*target_func)(void);
bool (*is_supported)(void);
-   void (*skip_msg)(void);
+   const char *(*skip_msg)(void);
 } wp_testcase_table[] = {
{
.desc = "Read Only Watchpoint",
@@ -219,16 +221,23 @@ const char *test__wp_subtest_get_desc(int i)
return wp_testcase_table[i].desc;
 }
 
+const char *test__wp_subtest_skip_reason(int i)
+{
+   if (i < 0 || i >= (int)ARRAY_SIZE(wp_testcase_table))
+   return NULL;
+   if (!wp_testcase_table[i].skip_msg)
+   return NULL;
+   return wp_testcase_table[i].skip_msg();
+}
+
 int test__wp(struct test *test __maybe_unused, int i)
 {
if (i < 0 || i >= (int)ARRAY_SIZE(wp_testcase_table))
return TEST_FAIL;
 
if (wp_testcase_table[i].is_supported &&
-   !wp_testcase_table[i].is_supported()) {
-   wp_testcase_table[i].skip_msg();
+   !wp_testcase_table[i].is_supported())
return TEST_SKIP;
-   }
 
return !wp_testcase_table[i].target_func() ? TEST_OK : TEST_FAIL;
 }
-- 
2.26.2

[PATCH] perf tools: Fix crash with non-jited bpf progs

[Tommi Rantala]

The addr in PERF_RECORD_KSYMBOL events for non-jited bpf progs points to
the bpf interpreter, ie. within kernel text section. When processing the
unregister event, this causes unexpected removal of vmlinux_map,
crashing perf later in cleanup:

  # perf record -- timeout --signal=INT 2s /usr/share/bcc/tools/execsnoop
  PCOMMPIDPPID   RET ARGS
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.208 MB perf.data (5155 samples) ]
  perf: tools/include/linux/refcount.h:131: refcount_sub_and_test: Assertion 
`!(new > val)' failed.
  Aborted (core dumped)

  # perf script -D|grep KSYM
  0 0xa40 [0x48]: PERF_RECORD_KSYMBOL addr a9b6b530 len 0 type 1 flags 
0x0 name bpf_prog_f958f6eb72ef5af6
  0 0xab0 [0x48]: PERF_RECORD_KSYMBOL addr a9b6b530 len 0 type 1 flags 
0x0 name bpf_prog_8c42dee26e8cd4c2
  0 0xb20 [0x48]: PERF_RECORD_KSYMBOL addr a9b6b530 len 0 type 1 flags 
0x0 name bpf_prog_f958f6eb72ef5af6
  108563691893 0x33d98 [0x58]: PERF_RECORD_KSYMBOL addr a9b6b3b0 len 0 
type 1 flags 0x0 name bpf_prog_bc5697a410556fc2_syscall__execve
  108568518458 0x34098 [0x58]: PERF_RECORD_KSYMBOL addr a9b6b3f0 len 0 
type 1 flags 0x0 name bpf_prog_45e2203c2928704d_do_ret_sys_execve
  109301967895 0x34830 [0x58]: PERF_RECORD_KSYMBOL addr a9b6b3b0 len 0 
type 1 flags 0x1 name bpf_prog_bc5697a410556fc2_syscall__execve
  109302007356 0x348b0 [0x58]: PERF_RECORD_KSYMBOL addr a9b6b3f0 len 0 
type 1 flags 0x1 name bpf_prog_45e2203c2928704d_do_ret_sys_execve
  perf: tools/include/linux/refcount.h:131: refcount_sub_and_test: Assertion 
`!(new > val)' failed.

Here the addresses match the bpf interpreter:

  # grep -e a9b6b530 -e a9b6b3b0 -e a9b6b3f0 
/proc/kallsyms
  a9b6b3b0 t __bpf_prog_run224
  a9b6b3f0 t __bpf_prog_run192
  a9b6b530 t __bpf_prog_run32

Fix by not allowing vmlinux_map to be removed by PERF_RECORD_KSYMBOL
unregister event.

Signed-off-by: Tommi Rantala 
---
 tools/perf/util/machine.c | 11 ++-
 tools/perf/util/symbol.c  |  7 +++
 tools/perf/util/symbol.h  |  2 ++
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 85587de027a5..d93d35463c61 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -786,11 +786,20 @@ static int machine__process_ksymbol_unregister(struct 
machine *machine,
   union perf_event *event,
   struct perf_sample *sample 
__maybe_unused)
 {
+   struct symbol *sym;
struct map *map;
 
map = maps__find(>kmaps, event->ksymbol.addr);
-   if (map)
+   if (!map)
+   return 0;
+
+   if (map != machine->vmlinux_map)
maps__remove(>kmaps, map);
+   else {
+   sym = dso__find_symbol(map->dso, map->map_ip(map, map->start));
+   if (sym)
+   dso__delete_symbol(map->dso, sym);
+   }
 
return 0;
 }
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 5151a8c0b791..6bf8e74ea1d1 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -515,6 +515,13 @@ void dso__insert_symbol(struct dso *dso, struct symbol 
*sym)
}
 }
 
+void dso__delete_symbol(struct dso *dso, struct symbol *sym)
+{
+   rb_erase_cached(>rb_node, >symbols);
+   symbol__delete(sym);
+   dso__reset_find_symbol_cache(dso);
+}
+
 struct symbol *dso__find_symbol(struct dso *dso, u64 addr)
 {
if (dso->last_find_result.addr != addr || dso->last_find_result.symbol 
== NULL) {
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 03e264a27cd3..60345691db09 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -130,6 +130,8 @@ int dso__load_kallsyms(struct dso *dso, const char 
*filename, struct map *map);
 
 void dso__insert_symbol(struct dso *dso,
struct symbol *sym);
+void dso__delete_symbol(struct dso *dso,
+   struct symbol *sym);
 
 struct symbol *dso__find_symbol(struct dso *dso, u64 addr);
 struct symbol *dso__find_symbol_by_name(struct dso *dso, const char *name);
-- 
2.26.2

[PATCH 12/13] selftests: clone3: use SKIP instead of XFAIL

[Tommi Rantala]

XFAIL is gone since 9847d24af95c ("selftests/harness: Refactor XFAIL
into SKIP"), use SKIP instead.

Fixes: 9847d24af95c ("selftests/harness: Refactor XFAIL into SKIP")
Signed-off-by: Tommi Rantala 
---
 tools/testing/selftests/clone3/clone3_cap_checkpoint_restore.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/clone3/clone3_cap_checkpoint_restore.c 
b/tools/testing/selftests/clone3/clone3_cap_checkpoint_restore.c
index 9562425aa0a9..614091de4c54 100644
--- a/tools/testing/selftests/clone3/clone3_cap_checkpoint_restore.c
+++ b/tools/testing/selftests/clone3/clone3_cap_checkpoint_restore.c
@@ -145,7 +145,7 @@ TEST(clone3_cap_checkpoint_restore)
test_clone3_supported();
 
EXPECT_EQ(getuid(), 0)
-   XFAIL(return, "Skipping all tests as non-root\n");
+   SKIP(return, "Skipping all tests as non-root");
 
memset(_tid, 0, sizeof(set_tid));
 
-- 
2.26.2

[PATCH 06/13] selftests: pidfd: skip test on kcmp() ENOSYS

[Tommi Rantala]

Skip test if kcmp() is not available, for example if kernel is compiled
without CONFIG_CHECKPOINT_RESTORE=y.

Signed-off-by: Tommi Rantala 
---
 tools/testing/selftests/pidfd/pidfd_getfd_test.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/pidfd/pidfd_getfd_test.c 
b/tools/testing/selftests/pidfd/pidfd_getfd_test.c
index 7758c98be015..0930e2411dfb 100644
--- a/tools/testing/selftests/pidfd/pidfd_getfd_test.c
+++ b/tools/testing/selftests/pidfd/pidfd_getfd_test.c
@@ -204,7 +204,10 @@ TEST_F(child, fetch_fd)
fd = sys_pidfd_getfd(self->pidfd, self->remote_fd, 0);
ASSERT_GE(fd, 0);
 
-   EXPECT_EQ(0, sys_kcmp(getpid(), self->pid, KCMP_FILE, fd, 
self->remote_fd));
+   ret = sys_kcmp(getpid(), self->pid, KCMP_FILE, fd, self->remote_fd);
+   if (ret < 0 && errno == ENOSYS)
+   SKIP(return, "kcmp() syscall not supported");
+   EXPECT_EQ(ret, 0);
 
ret = fcntl(fd, F_GETFD);
ASSERT_GE(ret, 0);
-- 
2.26.2

[PATCH 10/13] selftests: proc: fix warning: _GNU_SOURCE redefined

[Tommi Rantala]

Makefile already contains -D_GNU_SOURCE, so we can remove it from the
*.c files.

Signed-off-by: Tommi Rantala 
---
 tools/testing/selftests/proc/proc-loadavg-001.c  | 1 -
 tools/testing/selftests/proc/proc-self-syscall.c | 1 -
 tools/testing/selftests/proc/proc-uptime-002.c   | 1 -
 3 files changed, 3 deletions(-)

diff --git a/tools/testing/selftests/proc/proc-loadavg-001.c 
b/tools/testing/selftests/proc/proc-loadavg-001.c
index 471e2aa28077..fb4fe9188806 100644
--- a/tools/testing/selftests/proc/proc-loadavg-001.c
+++ b/tools/testing/selftests/proc/proc-loadavg-001.c
@@ -14,7 +14,6 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 /* Test that /proc/loadavg correctly reports last pid in pid namespace. */
-#define _GNU_SOURCE
 #include 
 #include 
 #include 
diff --git a/tools/testing/selftests/proc/proc-self-syscall.c 
b/tools/testing/selftests/proc/proc-self-syscall.c
index 9f6d000c0245..8511dcfe67c7 100644
--- a/tools/testing/selftests/proc/proc-self-syscall.c
+++ b/tools/testing/selftests/proc/proc-self-syscall.c
@@ -13,7 +13,6 @@
  * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
-#define _GNU_SOURCE
 #include 
 #include 
 #include 
diff --git a/tools/testing/selftests/proc/proc-uptime-002.c 
b/tools/testing/selftests/proc/proc-uptime-002.c
index 30e2b7849089..e7ceabed7f51 100644
--- a/tools/testing/selftests/proc/proc-uptime-002.c
+++ b/tools/testing/selftests/proc/proc-uptime-002.c
@@ -15,7 +15,6 @@
  */
 // Test that values in /proc/uptime increment monotonically
 // while shifting across CPUs.
-#define _GNU_SOURCE
 #undef NDEBUG
 #include 
 #include 
-- 
2.26.2

[PATCH 08/13] selftests: pidfd: drop needless linux/kcmp.h inclusion in pidfd_setns_test.c

[Tommi Rantala]

kcmp is not used in pidfd_setns_test.c, so do not include 

Signed-off-by: Tommi Rantala 
---
 tools/testing/selftests/pidfd/pidfd_setns_test.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/testing/selftests/pidfd/pidfd_setns_test.c 
b/tools/testing/selftests/pidfd/pidfd_setns_test.c
index 7dca1aa4672d..3f3dc7a02a01 100644
--- a/tools/testing/selftests/pidfd/pidfd_setns_test.c
+++ b/tools/testing/selftests/pidfd/pidfd_setns_test.c
@@ -16,7 +16,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "pidfd.h"
 #include "../clone3/clone3_selftests.h"
-- 
2.26.2

[PATCH 07/13] selftests: pidfd: add CONFIG_CHECKPOINT_RESTORE=y to config

[Tommi Rantala]

kcmp syscall is used in pidfd_getfd_test.c, so add
CONFIG_CHECKPOINT_RESTORE=y to config to ensure kcmp is available.

Signed-off-by: Tommi Rantala 
---
 tools/testing/selftests/pidfd/config | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/testing/selftests/pidfd/config 
b/tools/testing/selftests/pidfd/config
index bb11de90c0c9..f6f2965e17af 100644
--- a/tools/testing/selftests/pidfd/config
+++ b/tools/testing/selftests/pidfd/config
@@ -4,3 +4,4 @@ CONFIG_USER_NS=y
 CONFIG_PID_NS=y
 CONFIG_NET_NS=y
 CONFIG_CGROUPS=y
+CONFIG_CHECKPOINT_RESTORE=y
-- 
2.26.2

[PATCH 11/13] selftests: core: use SKIP instead of XFAIL in close_range_test.c

[Tommi Rantala]

XFAIL is gone since 9847d24af95c ("selftests/harness: Refactor XFAIL
into SKIP"), use SKIP instead.

Fixes: 9847d24af95c ("selftests/harness: Refactor XFAIL into SKIP")
Signed-off-by: Tommi Rantala 
---
 tools/testing/selftests/core/close_range_test.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/core/close_range_test.c 
b/tools/testing/selftests/core/close_range_test.c
index c99b98b0d461..575b391ddc78 100644
--- a/tools/testing/selftests/core/close_range_test.c
+++ b/tools/testing/selftests/core/close_range_test.c
@@ -44,7 +44,7 @@ TEST(close_range)
fd = open("/dev/null", O_RDONLY | O_CLOEXEC);
ASSERT_GE(fd, 0) {
if (errno == ENOENT)
-   XFAIL(return, "Skipping test since /dev/null 
does not exist");
+   SKIP(return, "Skipping test since /dev/null 
does not exist");
}
 
open_fds[i] = fd;
@@ -52,7 +52,7 @@ TEST(close_range)
 
EXPECT_EQ(-1, sys_close_range(open_fds[0], open_fds[100], -1)) {
if (errno == ENOSYS)
-   XFAIL(return, "close_range() syscall not supported");
+   SKIP(return, "close_range() syscall not supported");
}
 
EXPECT_EQ(0, sys_close_range(open_fds[0], open_fds[50], 0));
@@ -108,7 +108,7 @@ TEST(close_range_unshare)
fd = open("/dev/null", O_RDONLY | O_CLOEXEC);
ASSERT_GE(fd, 0) {
if (errno == ENOENT)
-   XFAIL(return, "Skipping test since /dev/null 
does not exist");
+   SKIP(return, "Skipping test since /dev/null 
does not exist");
}
 
open_fds[i] = fd;
@@ -197,7 +197,7 @@ TEST(close_range_unshare_capped)
fd = open("/dev/null", O_RDONLY | O_CLOEXEC);
ASSERT_GE(fd, 0) {
if (errno == ENOENT)
-   XFAIL(return, "Skipping test since /dev/null 
does not exist");
+   SKIP(return, "Skipping test since /dev/null 
does not exist");
}
 
open_fds[i] = fd;
-- 
2.26.2

[PATCH 09/13] selftests: android: fix multiple definition of sock_name

[Tommi Rantala]

Fix multiple definition of sock_name compilation error:

  tools/testing/selftests/android/ion/ipcsocket.h:8: multiple definition of 
`sock_name'

Signed-off-by: Tommi Rantala 
---
 tools/testing/selftests/android/ion/ipcsocket.c | 1 +
 tools/testing/selftests/android/ion/ipcsocket.h | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/testing/selftests/android/ion/ipcsocket.c 
b/tools/testing/selftests/android/ion/ipcsocket.c
index 7dc521002095..67ec69410d2e 100644
--- a/tools/testing/selftests/android/ion/ipcsocket.c
+++ b/tools/testing/selftests/android/ion/ipcsocket.c
@@ -10,6 +10,7 @@
 
 #include "ipcsocket.h"
 
+static char sock_name[MAX_SOCK_NAME_LEN];
 
 int opensocket(int *sockfd, const char *name, int connecttype)
 {
diff --git a/tools/testing/selftests/android/ion/ipcsocket.h 
b/tools/testing/selftests/android/ion/ipcsocket.h
index b3e84498a8a1..ec5efb23e7b0 100644
--- a/tools/testing/selftests/android/ion/ipcsocket.h
+++ b/tools/testing/selftests/android/ion/ipcsocket.h
@@ -5,8 +5,6 @@
 
 #define MAX_SOCK_NAME_LEN  64
 
-char sock_name[MAX_SOCK_NAME_LEN];
-
 /* This structure is responsible for holding the IPC data
  * data: hold the buffer fd
  * len: just the length of 32-bit integer fd
-- 
2.26.2

[PATCH 04/13] selftests/harness: prettify SKIP message whitespace again

[Tommi Rantala]

Commit 9847d24af95c ("selftests/harness: Refactor XFAIL into SKIP")
replaced XFAIL with SKIP in the output. Add one more space to make the
output aligned and pretty again.

Fixes: 9847d24af95c ("selftests/harness: Refactor XFAIL into SKIP")
Signed-off-by: Tommi Rantala 
---
 tools/testing/selftests/kselftest_harness.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/kselftest_harness.h 
b/tools/testing/selftests/kselftest_harness.h
index 4f78e4805633..d8f44f4bdb3f 100644
--- a/tools/testing/selftests/kselftest_harness.h
+++ b/tools/testing/selftests/kselftest_harness.h
@@ -126,7 +126,7 @@
snprintf(_metadata->results->reason, \
 sizeof(_metadata->results->reason), fmt, ##__VA_ARGS__); \
if (TH_LOG_ENABLED) { \
-   fprintf(TH_LOG_STREAM, "#  SKIP %s\n", \
+   fprintf(TH_LOG_STREAM, "#  SKIP  %s\n", \
_metadata->results->reason); \
} \
_metadata->passed = 1; \
-- 
2.26.2

[PATCH 00/13] selftests fixes

[Tommi Rantala]

Hi, small fixes to issues I hit with selftests.

Tommi Rantala (13):
  selftests: filter kselftest headers from command in lib.mk
  selftests: pidfd: fix compilation errors due to wait.h
  selftests: add vmaccess to .gitignore
  selftests/harness: prettify SKIP message whitespace again
  selftests: pidfd: use ksft_test_result_skip() when skipping test
  selftests: pidfd: skip test on kcmp() ENOSYS
  selftests: pidfd: add CONFIG_CHECKPOINT_RESTORE=y to config
  selftests: pidfd: drop needless linux/kcmp.h inclusion in
pidfd_setns_test.c
  selftests: android: fix multiple definition of sock_name
  selftests: proc: fix warning: _GNU_SOURCE redefined
  selftests: core: use SKIP instead of XFAIL in close_range_test.c
  selftests: clone3: use SKIP instead of XFAIL
  selftests: binderfs: use SKIP instead of XFAIL

 tools/testing/selftests/android/ion/ipcsocket.c   | 1 +
 tools/testing/selftests/android/ion/ipcsocket.h   | 2 --
 .../selftests/clone3/clone3_cap_checkpoint_restore.c  | 2 +-
 tools/testing/selftests/core/close_range_test.c   | 8 
 .../selftests/filesystems/binderfs/binderfs_test.c| 8 
 tools/testing/selftests/kselftest_harness.h   | 2 +-
 tools/testing/selftests/lib.mk| 2 +-
 tools/testing/selftests/pidfd/config  | 1 +
 tools/testing/selftests/pidfd/pidfd_getfd_test.c  | 5 -
 tools/testing/selftests/pidfd/pidfd_open_test.c   | 1 -
 tools/testing/selftests/pidfd/pidfd_poll_test.c   | 1 -
 tools/testing/selftests/pidfd/pidfd_setns_test.c  | 1 -
 tools/testing/selftests/pidfd/pidfd_test.c| 2 +-
 tools/testing/selftests/proc/proc-loadavg-001.c   | 1 -
 tools/testing/selftests/proc/proc-self-syscall.c  | 1 -
 tools/testing/selftests/proc/proc-uptime-002.c| 1 -
 tools/testing/selftests/ptrace/.gitignore | 1 +
 17 files changed, 19 insertions(+), 21 deletions(-)

-- 
2.26.2

[PATCH 13/13] selftests: binderfs: use SKIP instead of XFAIL

[Tommi Rantala]

XFAIL is gone since 9847d24af95c ("selftests/harness: Refactor XFAIL
into SKIP"), use SKIP instead.

Fixes: 9847d24af95c ("selftests/harness: Refactor XFAIL into SKIP")
Signed-off-by: Tommi Rantala 
---
 .../selftests/filesystems/binderfs/binderfs_test.c| 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/filesystems/binderfs/binderfs_test.c 
b/tools/testing/selftests/filesystems/binderfs/binderfs_test.c
index 1d27f52c61e6..477cbb042f5b 100644
--- a/tools/testing/selftests/filesystems/binderfs/binderfs_test.c
+++ b/tools/testing/selftests/filesystems/binderfs/binderfs_test.c
@@ -74,7 +74,7 @@ static int __do_binderfs_test(struct __test_metadata 
*_metadata)
ret = mount(NULL, binderfs_mntpt, "binder", 0, 0);
EXPECT_EQ(ret, 0) {
if (errno == ENODEV)
-   XFAIL(goto out, "binderfs missing");
+   SKIP(goto out, "binderfs missing");
TH_LOG("%s - Failed to mount binderfs", strerror(errno));
goto rmdir;
}
@@ -475,10 +475,10 @@ TEST(binderfs_stress)
 TEST(binderfs_test_privileged)
 {
if (geteuid() != 0)
-   XFAIL(return, "Tests are not run as root. Skipping privileged 
tests");
+   SKIP(return, "Tests are not run as root. Skipping privileged 
tests");
 
if (__do_binderfs_test(_metadata))
-   XFAIL(return, "The Android binderfs filesystem is not 
available");
+   SKIP(return, "The Android binderfs filesystem is not 
available");
 }
 
 TEST(binderfs_test_unprivileged)
@@ -511,7 +511,7 @@ TEST(binderfs_test_unprivileged)
ret = wait_for_pid(pid);
if (ret) {
if (ret == 2)
-   XFAIL(return, "The Android binderfs filesystem is not 
available");
+   SKIP(return, "The Android binderfs filesystem is not 
available");
ASSERT_EQ(ret, 0) {
TH_LOG("wait_for_pid() failed");
}
-- 
2.26.2

[PATCH 05/13] selftests: pidfd: use ksft_test_result_skip() when skipping test

[Tommi Rantala]

There's planned tests != run tests in pidfd_test when some test is
skipped:

  $ ./pidfd_test
  TAP version 13
  1..8
  [...]
  # pidfd_send_signal signal recycled pid test: Skipping test
  # Planned tests != run tests (8 != 7)
  # Totals: pass:7 fail:0 xfail:0 xpass:0 skip:0 error:0

Fix by using ksft_test_result_skip():

  $ ./pidfd_test
  TAP version 13
  1..8
  [...]
  ok 8 # SKIP pidfd_send_signal signal recycled pid test: Unsharing pid 
namespace not permitted
  # Totals: pass:7 fail:0 xfail:0 xpass:0 skip:1 error:0

Signed-off-by: Tommi Rantala 
---
 tools/testing/selftests/pidfd/pidfd_test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/pidfd/pidfd_test.c 
b/tools/testing/selftests/pidfd/pidfd_test.c
index c585aaa2acd8..529eb700ac26 100644
--- a/tools/testing/selftests/pidfd/pidfd_test.c
+++ b/tools/testing/selftests/pidfd/pidfd_test.c
@@ -330,7 +330,7 @@ static int test_pidfd_send_signal_recycled_pid_fail(void)
ksft_exit_fail_msg("%s test: Failed to recycle pid %d\n",
   test_name, PID_RECYCLE);
case PIDFD_SKIP:
-   ksft_print_msg("%s test: Skipping test\n", test_name);
+   ksft_test_result_skip("%s test: Skipping test\n", test_name);
ret = 0;
break;
case PIDFD_XFAIL:
-- 
2.26.2

[PATCH 02/13] selftests: pidfd: fix compilation errors due to wait.h

[Tommi Rantala]

Drop unneeded  header inclusion to fix pidfd compilation
errors seen in Fedora 32:

In file included from pidfd_open_test.c:9:
../../../../usr/include/linux/wait.h:17:16: error: expected identifier before 
numeric constant
   17 | #define P_ALL  0
  |^

Signed-off-by: Tommi Rantala 
---
 tools/testing/selftests/pidfd/pidfd_open_test.c | 1 -
 tools/testing/selftests/pidfd/pidfd_poll_test.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/tools/testing/selftests/pidfd/pidfd_open_test.c 
b/tools/testing/selftests/pidfd/pidfd_open_test.c
index b9fe75fc3e51..8a59438ccc78 100644
--- a/tools/testing/selftests/pidfd/pidfd_open_test.c
+++ b/tools/testing/selftests/pidfd/pidfd_open_test.c
@@ -6,7 +6,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/tools/testing/selftests/pidfd/pidfd_poll_test.c 
b/tools/testing/selftests/pidfd/pidfd_poll_test.c
index 4b115444dfe9..610811275357 100644
--- a/tools/testing/selftests/pidfd/pidfd_poll_test.c
+++ b/tools/testing/selftests/pidfd/pidfd_poll_test.c
@@ -3,7 +3,6 @@
 #define _GNU_SOURCE
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.26.2

[PATCH 01/13] selftests: filter kselftest headers from command in lib.mk

[Tommi Rantala]

Commit 1056d3d2c97e ("selftests: enforce local header dependency in
lib.mk") added header dependency to the rule, but as the rule uses $^,
the headers are added to the compiler command line.

This can cause unexpected precompiled header files being generated when
compilation fails:

  $ echo { >> openat2_test.c

  $ make
  gcc -Wall -O2 -g -fsanitize=address -fsanitize=undefined  openat2_test.c
tools/testing/selftests/kselftest_harness.h 
tools/testing/selftests/kselftest.h helpers.c
-o tools/testing/selftests/openat2/openat2_test
  openat2_test.c:313:1: error: expected identifier or ‘(’ before ‘{’ token
313 | {
| ^
  make: *** [../lib.mk:140: tools/testing/selftests/openat2/openat2_test] Error 
1

  $ file openat2_test*
  openat2_test:   GCC precompiled header (version 014) for C
  openat2_test.c: C source, ASCII text

Fix it by filtering out the headers, so that we'll only pass the actual
*.c files in the compiler command line.

Fixes: 1056d3d2c97e ("selftests: enforce local header dependency in lib.mk")
Signed-off-by: Tommi Rantala 
---
 tools/testing/selftests/lib.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
index 7a17ea815736..66f3317dc365 100644
--- a/tools/testing/selftests/lib.mk
+++ b/tools/testing/selftests/lib.mk
@@ -137,7 +137,7 @@ endif
 ifeq ($(OVERRIDE_TARGETS),)
 LOCAL_HDRS := $(selfdir)/kselftest_harness.h $(selfdir)/kselftest.h
 $(OUTPUT)/%:%.c $(LOCAL_HDRS)
-   $(LINK.c) $^ $(LDLIBS) -o $@
+   $(LINK.c) $(filter-out $(LOCAL_HDRS),$^) $(LDLIBS) -o $@
 
 $(OUTPUT)/%.o:%.S
$(COMPILE.S) $^ -o $@
-- 
2.26.2

[PATCH 03/13] selftests: add vmaccess to .gitignore

[Tommi Rantala]

Commit 2de4e82318c7 ("selftests/ptrace: add test cases for dead-locks")
added vmaccess testcase, add the binary to .gitignore

Fixes: 2de4e82318c7 ("selftests/ptrace: add test cases for dead-locks")
Signed-off-by: Tommi Rantala 
---
 tools/testing/selftests/ptrace/.gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/testing/selftests/ptrace/.gitignore 
b/tools/testing/selftests/ptrace/.gitignore
index 7bebf9534a86..792318aaa30c 100644
--- a/tools/testing/selftests/ptrace/.gitignore
+++ b/tools/testing/selftests/ptrace/.gitignore
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
 get_syscall_info
 peeksiginfo
+vmaccess
-- 
2.26.2

[tip: perf/core] perf bench: Fix div-by-zero if runtime is zero

[tip-bot2 for Tommi Rantala]

The following commit has been merged into the perf/core branch of tip:

Commit-ID: 41e7c32b978974adaadd4808ba42f9026634dca3
Gitweb:
https://git.kernel.org/tip/41e7c32b978974adaadd4808ba42f9026634dca3
Author:Tommi Rantala 
AuthorDate:Fri, 17 Apr 2020 16:23:29 +03:00
Committer: Arnaldo Carvalho de Melo 
CommitterDate: Wed, 22 Apr 2020 10:01:33 -03:00

perf bench: Fix div-by-zero if runtime is zero

Fix div-by-zero if runtime is zero:

  $ perf bench futex hash --runtime=0
  # Running 'futex/hash' benchmark:
  Run summary [PID 12090]: 4 threads, each operating on 1024 [private] futexes 
for 0 secs.
  Floating point exception (core dumped)

Signed-off-by: Tommi Rantala 
Acked-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Darren Hart 
Cc: Mark Rutland 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lore.kernel.org/lkml/20200417132330.119407-4-tommi.t.rant...@nokia.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/bench/epoll-wait.c| 3 ++-
 tools/perf/bench/futex-hash.c| 3 ++-
 tools/perf/bench/futex-lock-pi.c | 3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/tools/perf/bench/epoll-wait.c b/tools/perf/bench/epoll-wait.c
index f938c58..cf79736 100644
--- a/tools/perf/bench/epoll-wait.c
+++ b/tools/perf/bench/epoll-wait.c
@@ -519,7 +519,8 @@ int bench_epoll_wait(int argc, const char **argv)
qsort(worker, nthreads, sizeof(struct worker), cmpworker);
 
for (i = 0; i < nthreads; i++) {
-   unsigned long t = worker[i].ops / bench__runtime.tv_sec;
+   unsigned long t = bench__runtime.tv_sec > 0 ?
+   worker[i].ops / bench__runtime.tv_sec : 0;
 
update_stats(_stats, t);
 
diff --git a/tools/perf/bench/futex-hash.c b/tools/perf/bench/futex-hash.c
index 65eebe0..915bf3d 100644
--- a/tools/perf/bench/futex-hash.c
+++ b/tools/perf/bench/futex-hash.c
@@ -205,7 +205,8 @@ int bench_futex_hash(int argc, const char **argv)
pthread_mutex_destroy(_lock);
 
for (i = 0; i < nthreads; i++) {
-   unsigned long t = worker[i].ops / bench__runtime.tv_sec;
+   unsigned long t = bench__runtime.tv_sec > 0 ?
+   worker[i].ops / bench__runtime.tv_sec : 0;
update_stats(_stats, t);
if (!silent) {
if (nfutexes == 1)
diff --git a/tools/perf/bench/futex-lock-pi.c b/tools/perf/bench/futex-lock-pi.c
index 89fd8f3..bb25d8b 100644
--- a/tools/perf/bench/futex-lock-pi.c
+++ b/tools/perf/bench/futex-lock-pi.c
@@ -211,7 +211,8 @@ int bench_futex_lock_pi(int argc, const char **argv)
pthread_mutex_destroy(_lock);
 
for (i = 0; i < nthreads; i++) {
-   unsigned long t = worker[i].ops / bench__runtime.tv_sec;
+   unsigned long t = bench__runtime.tv_sec > 0 ?
+   worker[i].ops / bench__runtime.tv_sec : 0;
 
update_stats(_stats, t);
if (!silent)

[tip: perf/core] perf cgroup: Avoid needless closing of unopened fd

[tip-bot2 for Tommi Rantala]

The following commit has been merged into the perf/core branch of tip:

Commit-ID: d2e7d8636fb7d3e30aa8f894003f9e293ea62eea
Gitweb:
https://git.kernel.org/tip/d2e7d8636fb7d3e30aa8f894003f9e293ea62eea
Author:Tommi Rantala 
AuthorDate:Fri, 17 Apr 2020 16:23:26 +03:00
Committer: Arnaldo Carvalho de Melo 
CommitterDate: Wed, 22 Apr 2020 10:01:33 -03:00

perf cgroup: Avoid needless closing of unopened fd

Do not bother with close() if fd is not valid, just to silence valgrind:

$ valgrind ./perf script
==59169== Memcheck, a memory error detector
==59169== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==59169== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==59169== Command: ./perf script
==59169==
==59169== Warning: invalid file descriptor -1 in syscall close()
==59169== Warning: invalid file descriptor -1 in syscall close()
==59169== Warning: invalid file descriptor -1 in syscall close()
==59169== Warning: invalid file descriptor -1 in syscall close()
==59169== Warning: invalid file descriptor -1 in syscall close()
==59169== Warning: invalid file descriptor -1 in syscall close()
==59169== Warning: invalid file descriptor -1 in syscall close()
==59169== Warning: invalid file descriptor -1 in syscall close()

Signed-off-by: Tommi Rantala 
Acked-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Mark Rutland 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lore.kernel.org/lkml/20200417132330.119407-1-tommi.t.rant...@nokia.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/cgroup.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/cgroup.c b/tools/perf/util/cgroup.c
index b73fb78..050dea9 100644
--- a/tools/perf/util/cgroup.c
+++ b/tools/perf/util/cgroup.c
@@ -107,7 +107,8 @@ found:
 
 static void cgroup__delete(struct cgroup *cgroup)
 {
-   close(cgroup->fd);
+   if (cgroup->fd >= 0)
+   close(cgroup->fd);
zfree(>name);
free(cgroup);
 }

[tip: perf/core] perf test session topology: Fix data path

[tip-bot2 for Tommi Rantala]

The following commit has been merged into the perf/core branch of tip:

Commit-ID: dbd660e6b2884b864d2642d930a163d3bcebe4be
Gitweb:
https://git.kernel.org/tip/dbd660e6b2884b864d2642d930a163d3bcebe4be
Author:Tommi Rantala 
AuthorDate:Thu, 23 Apr 2020 14:53:40 +03:00
Committer: Arnaldo Carvalho de Melo 
CommitterDate: Thu, 23 Apr 2020 11:08:24 -03:00

perf test session topology: Fix data path

Commit 2d4f27999b88 ("perf data: Add global path holder") missed path
conversion in tests/topology.c, causing the "Session topology" testcase
to "hang" (waits forever for input from stdin) when doing "ssh $VM perf
test".

Can be reproduced by running "cat | perf test topo", and crashed by
replacing cat with true:

  $ true | perf test -v topo
  40: Session topology  :
  --- start ---
  test child forked, pid 3638
  templ file: /tmp/perf-test-QPvAch
  incompatible file format
  incompatible file format (rerun with -v to learn more)
  free(): invalid pointer
  test child interrupted
   end 
  Session topology: FAILED!

Committer testing:

Reproduced the above result before the patch and after it is back
working:

  # true | perf test -v topo
  41: Session topology  :
  --- start ---
  test child forked, pid 19374
  templ file: /tmp/perf-test-YOTEQg
  CPU 0, core 0, socket 0
  CPU 1, core 1, socket 0
  CPU 2, core 2, socket 0
  CPU 3, core 3, socket 0
  CPU 4, core 0, socket 0
  CPU 5, core 1, socket 0
  CPU 6, core 2, socket 0
  CPU 7, core 3, socket 0
  test child finished with 0
   end 
  Session topology: Ok
  #

Fixes: 2d4f27999b88 ("perf data: Add global path holder")
Signed-off-by: Tommi Rantala 
Tested-by: Arnaldo Carvalho de Melo 
Acked-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Mamatha Inamdar 
Cc: Mark Rutland 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Ravi Bangoria 
Link: 
http://lore.kernel.org/lkml/20200423115341.562782-1-tommi.t.rant...@nokia.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/topology.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/tools/perf/tests/topology.c b/tools/perf/tests/topology.c
index 4a80049..22daf2b 100644
--- a/tools/perf/tests/topology.c
+++ b/tools/perf/tests/topology.c
@@ -33,10 +33,8 @@ static int session_write_header(char *path)
 {
struct perf_session *session;
struct perf_data data = {
-   .file  = {
-   .path = path,
-   },
-   .mode  = PERF_DATA_MODE_WRITE,
+   .path = path,
+   .mode = PERF_DATA_MODE_WRITE,
};
 
session = perf_session__new(, false, NULL);
@@ -63,10 +61,8 @@ static int check_cpu_topology(char *path, struct 
perf_cpu_map *map)
 {
struct perf_session *session;
struct perf_data data = {
-   .file  = {
-   .path = path,
-   },
-   .mode  = PERF_DATA_MODE_READ,
+   .path = path,
+   .mode = PERF_DATA_MODE_READ,
};
int i;
 

[tip:perf/core] perf tests shell: Skip trace+probe_vfs_getname.sh if built without trace support

[tip-bot for Tommi Rantala]

Commit-ID:  83244772a4cf9490a54182be2f65f45d6b1a1ee8
Gitweb: https://git.kernel.org/tip/83244772a4cf9490a54182be2f65f45d6b1a1ee8
Author: Tommi Rantala 
AuthorDate: Fri, 15 Feb 2019 15:42:46 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Fri, 15 Feb 2019 13:42:26 -0300

perf tests shell: Skip trace+probe_vfs_getname.sh if built without trace support

If perf was built without trace support, the trace+probe_vfs_getname.sh
'perf test' entry fails:

  # perf trace -h
  perf: 'trace' is not a perf-command. See 'perf --help'

  # perf test 64
  64: Check open filename arg using perf trace + vfs_getname: FAILED!

Check trace support, so that we'll skip the test in that case:

  # perf test 64
  64: Check open filename arg using perf trace + vfs_getname: Skip

Signed-off-by: Tommi Rantala 
Cc: Alexander Shishkin 
Cc: Hendrik Brueckner 
Cc: Jiri Olsa 
Cc: Kim Phillips 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20190215134253.11454-1-tt.rant...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/shell/lib/probe.sh   | 5 +
 tools/perf/tests/shell/trace+probe_vfs_getname.sh | 1 +
 2 files changed, 6 insertions(+)

diff --git a/tools/perf/tests/shell/lib/probe.sh 
b/tools/perf/tests/shell/lib/probe.sh
index 6293cc660947..e37787be672b 100644
--- a/tools/perf/tests/shell/lib/probe.sh
+++ b/tools/perf/tests/shell/lib/probe.sh
@@ -4,3 +4,8 @@ skip_if_no_perf_probe() {
perf probe 2>&1 | grep -q 'is not a perf-command' && return 2
return 0
 }
+
+skip_if_no_perf_trace() {
+   perf trace -h 2>&1 | grep -q -e 'is not a perf-command' -e 'trace 
command not available' && return 2
+   return 0
+}
diff --git a/tools/perf/tests/shell/trace+probe_vfs_getname.sh 
b/tools/perf/tests/shell/trace+probe_vfs_getname.sh
index 50109f27ca07..147efeb6b195 100755
--- a/tools/perf/tests/shell/trace+probe_vfs_getname.sh
+++ b/tools/perf/tests/shell/trace+probe_vfs_getname.sh
@@ -12,6 +12,7 @@
 . $(dirname $0)/lib/probe.sh
 
 skip_if_no_perf_probe || exit 2
+skip_if_no_perf_trace || exit 2
 
 . $(dirname $0)/lib/probe_vfs_getname.sh
 

[PATCH] perf tests shell: Skip trace+probe_vfs_getname.sh if built without trace support

[Tommi Rantala]

From: Tommi Rantala 

If perf was built without trace support, trace+probe_vfs_getname.sh
fails:

  # perf trace -h
  perf: 'trace' is not a perf-command. See 'perf --help'

  # perf test 64
  64: Check open filename arg using perf trace + vfs_getname: FAILED!

Check trace support, so that we'll skip the test:

  # perf test 64
  64: Check open filename arg using perf trace + vfs_getname: Skip

Signed-off-by: Tommi Rantala 
---
 tools/perf/tests/shell/lib/probe.sh   | 5 +
 tools/perf/tests/shell/trace+probe_vfs_getname.sh | 1 +
 2 files changed, 6 insertions(+)

diff --git a/tools/perf/tests/shell/lib/probe.sh 
b/tools/perf/tests/shell/lib/probe.sh
index 6293cc660947..e37787be672b 100644
--- a/tools/perf/tests/shell/lib/probe.sh
+++ b/tools/perf/tests/shell/lib/probe.sh
@@ -4,3 +4,8 @@ skip_if_no_perf_probe() {
perf probe 2>&1 | grep -q 'is not a perf-command' && return 2
return 0
 }
+
+skip_if_no_perf_trace() {
+   perf trace -h 2>&1 | grep -q -e 'is not a perf-command' -e 'trace 
command not available' && return 2
+   return 0
+}
diff --git a/tools/perf/tests/shell/trace+probe_vfs_getname.sh 
b/tools/perf/tests/shell/trace+probe_vfs_getname.sh
index 50109f27ca07..147efeb6b195 100755
--- a/tools/perf/tests/shell/trace+probe_vfs_getname.sh
+++ b/tools/perf/tests/shell/trace+probe_vfs_getname.sh
@@ -12,6 +12,7 @@
 . $(dirname $0)/lib/probe.sh
 
 skip_if_no_perf_probe || exit 2
+skip_if_no_perf_trace || exit 2
 
 . $(dirname $0)/lib/probe_vfs_getname.sh
 
-- 
2.20.1

perf trace --no-syscalls -e rcu:* -- garbage in output

[Tommi Rantala]

Hi,

There some garbage in perf trace output, when tracing some rcu 
tracepoints (kernel is configured with CONFIG_RCU_TRACE=y).


For example in rcu:rcu_callback, instead of getting proper rcuname in 
the first "%s" here, there's garbage:


$ tail -1 /sys/kernel/debug/tracing/events/rcu/rcu_callback/format
print fmt: "%s rhp=%p func=%pf %ld/%ld", REC->rcuname, REC->rhp, 
REC->func, REC->qlen_lazy, REC->qlen


$ ./perf trace --no-syscalls -e 'rcu:*' -- sleep 1 2>&1 | od -t c

000   0   .   0   0   0   r   c   u   :   r
020   c   u   _   c   a   l   l   b   a   c   k   : 200 351 345 215
040 377 377 377 377   r   h   p   =   0   x   f   f   f   f   8
060   d   5   5   8   f   5   b   0   1   0   0   f   u   n   c
100   =   f   i   l   e   _   f   r   e   e   _   r   c   u   0
120   /   1  \n   0   .   0   0   8   r   c
140   u   :   r   c   u   _   d   y   n   t   i   c   k   : 373 217
160 276 215 377 377 377 377   4   0   0   0   0   0   0   0   0
200   0   0   0   0   0   0   0   4   0   0   0   0   0   0   0
220   0   0   0   0   0   0   0   2   0   x   1   d   2  \n
240   0   .   0   2   3   r   c   u   :   r   c
260   u   _   d   y   n   t   i   c   k   : 023 220 276 215 377 377
300 377 377   4   0   0   0   0   0   0   0   0   0   0   0   0
320   0   0   2   4   0   0   0   0   0   0   0   0   0   0   0
340   0   0   0   0   0   x   1   d   2  \n
360   0   .   0   2   8   r   c   u   :   r   c   u   _   d   y
400   n   t   i   c   k   : 373 217 276 215 377 377 377 377   4
420   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
440   4   0   0   0   0   0   0   0   0   0   0   0   0   0   0   2
460   0   x   1   d   2  \n   0   .   0   3
[...]


If I got it right, "pevent" in print_str_arg() is zero-initialized 
(pevent->long_size is zero...), causing "%s" format to produce garbage 
bytes instead of the proper string.


-Tommi

perf trace --no-syscalls -e rcu:* -- garbage in output

[Tommi Rantala]

Hi,

There some garbage in perf trace output, when tracing some rcu 
tracepoints (kernel is configured with CONFIG_RCU_TRACE=y).


For example in rcu:rcu_callback, instead of getting proper rcuname in 
the first "%s" here, there's garbage:


$ tail -1 /sys/kernel/debug/tracing/events/rcu/rcu_callback/format
print fmt: "%s rhp=%p func=%pf %ld/%ld", REC->rcuname, REC->rhp, 
REC->func, REC->qlen_lazy, REC->qlen


$ ./perf trace --no-syscalls -e 'rcu:*' -- sleep 1 2>&1 | od -t c

000   0   .   0   0   0   r   c   u   :   r
020   c   u   _   c   a   l   l   b   a   c   k   : 200 351 345 215
040 377 377 377 377   r   h   p   =   0   x   f   f   f   f   8
060   d   5   5   8   f   5   b   0   1   0   0   f   u   n   c
100   =   f   i   l   e   _   f   r   e   e   _   r   c   u   0
120   /   1  \n   0   .   0   0   8   r   c
140   u   :   r   c   u   _   d   y   n   t   i   c   k   : 373 217
160 276 215 377 377 377 377   4   0   0   0   0   0   0   0   0
200   0   0   0   0   0   0   0   4   0   0   0   0   0   0   0
220   0   0   0   0   0   0   0   2   0   x   1   d   2  \n
240   0   .   0   2   3   r   c   u   :   r   c
260   u   _   d   y   n   t   i   c   k   : 023 220 276 215 377 377
300 377 377   4   0   0   0   0   0   0   0   0   0   0   0   0
320   0   0   2   4   0   0   0   0   0   0   0   0   0   0   0
340   0   0   0   0   0   x   1   d   2  \n
360   0   .   0   2   8   r   c   u   :   r   c   u   _   d   y
400   n   t   i   c   k   : 373 217 276 215 377 377 377 377   4
420   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
440   4   0   0   0   0   0   0   0   0   0   0   0   0   0   0   2
460   0   x   1   d   2  \n   0   .   0   3
[...]


If I got it right, "pevent" in print_str_arg() is zero-initialized 
(pevent->long_size is zero...), causing "%s" format to produce garbage 
bytes instead of the proper string.


-Tommi

Re: backporting "ext4: inplace xattr block update fails to deduplicate blocks" to LTS kernels?

[Tommi Rantala]

On 21.02.2018 17:56, Theodore Ts'o wrote:

On Wed, Feb 21, 2018 at 12:40:00PM +0100, Greg Kroah-Hartman wrote:

On Mon, Feb 19, 2018 at 03:26:37PM +0200, Tommi Rantala wrote:


OK to backport it?
I tested it briefly in 4.9, seems to work.


It looks sane, but it would be nice if I can get people who are
backporting ext4 patches to make sure there are no regressions using
one of kvm-xfstests[1] or gce-xfstests[2][3].

[1] 
https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-xfstests.md
[2] 
https://github.com/tytso/xfstests-bld/blob/master/Documentation/gce-xfstests.md
[3] https://thunk.org/gce-xfstests

I do run regression tests[4] on stable kernels when I have time, but
it scales much better when other people can help.

[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/tag/?h=ext4-4.9.54-1


I need an ack from the ext4 maintainers before I can take this...


Greg, you can go ahead and take this, but in the future I'd appreciate
it if ext4 backporters could at least run a smoke test (which takes
less than 15 minutes on GCE) before and after the patch, and report no
test regressions.


Thanks for the instructions!

Smoke test results 4.9.82 with and without the patch (attached, to avoid 
email client mangling it), no new failures:


 Summary report
KERNEL:kernel 4.9.82-xfstests #2 SMP Thu Feb 22 14:58:27 EET 2018 x86_64
CPUS:  2
MEM:   1989.2

ext4/4k: 271 tests, 7 failures, 34 skipped, 737 seconds
  Failures: generic/081 generic/383 generic/384 generic/386
generic/441 generic/451 generic/472
Totals: 271 tests, 34 skipped, 7 failures, 0 errors, 685s


 Summary report
KERNEL:kernel 4.9.82-xfstests-1-gb98ae0251413 #1 SMP Thu Feb 22 
14:31:01 EET 2018 x86_64

CPUS:  2
MEM:   1989.2

ext4/4k: 271 tests, 7 failures, 34 skipped, 749 seconds
  Failures: generic/081 generic/383 generic/384 generic/386
generic/441 generic/451 generic/472
Totals: 271 tests, 34 skipped, 7 failures, 0 errors, 694s

FSTESTVER: e2fsprogs v1.43.6-85-g7595699d0 (Wed, 6 Sep 2017 22:04:14 -0400)
FSTESTVER: fio  fio-3.2 (Fri, 3 Nov 2017 15:23:49 -0600)
FSTESTVER: quota  4d81e8b (Mon, 16 Oct 2017 09:42:44 +0200)
FSTESTVER: stress-ng 977ae35 (Wed, 6 Sep 2017 23:45:03 -0400)
FSTESTVER: xfsprogs v4.14.0-rc2-1-g19ca9b0b (Mon, 27 Nov 2017 10:56:21 
-0600)

FSTESTVER: xfstests-bld ff7b8c2 (Wed, 13 Dec 2017 21:24:24 -0500)
FSTESTVER: xfstests linux-v3.8-1832-gafeee2d9 (Sun, 31 Dec 2017 13:35:28 
-0500)

FSTESTCFG: 4k
FSTESTSET: -g quick
FSTESTOPT: aex


Tommi
>From b98ae025141361b9e92fdd470dfd2314a64a47d0 Mon Sep 17 00:00:00 2001
From: Tahsin Erdogan <tah...@google.com>
Date: Sat, 5 Aug 2017 22:41:42 -0400
Subject: [PATCH] ext4: inplace xattr block update fails to deduplicate blocks

commit ec00022030da5761518476096626338bd67df57a upstream.

When an xattr block has a single reference, block is updated inplace
and it is reinserted to the cache. Later, a cache lookup is performed
to see whether an existing block has the same contents. This cache
lookup will most of the time return the just inserted entry so
deduplication is not achieved.

Running the following test script will produce two xattr blocks which
can be observed in "File ACL: " line of debugfs output:

  mke2fs -b 1024 -I 128 -F -O extent /dev/sdb 1G
  mount /dev/sdb /mnt/sdb

  touch /mnt/sdb/{x,y}

  setfattr -n user.1 -v aaa /mnt/sdb/x
  setfattr -n user.2 -v bbb /mnt/sdb/x

  setfattr -n user.1 -v aaa /mnt/sdb/y
  setfattr -n user.2 -v bbb /mnt/sdb/y

  debugfs -R 'stat x' /dev/sdb | cat
  debugfs -R 'stat y' /dev/sdb | cat

This patch defers the reinsertion to the cache so that we can locate
other blocks with the same contents.

Signed-off-by: Tahsin Erdogan <tah...@google.com>
Signed-off-by: Theodore Ts'o <ty...@mit.edu>
Reviewed-by: Andreas Dilger <adil...@dilger.ca>
Signed-off-by: Tommi Rantala <tommi.t.rant...@nokia.com>
---
 fs/ext4/xattr.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 3eeed8f0aa06..3fadfabcac39 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -837,8 +837,6 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
 if (!IS_LAST_ENTRY(s->first))
 	ext4_xattr_rehash(header(s->base),
 			  s->here);
-ext4_xattr_cache_insert(ext4_mb_cache,
-	bs->bh);
 			}
 			ext4_xattr_block_csum_set(inode, bs->bh);
 			unlock_buffer(bs->bh);
@@ -959,6 +957,7 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
 		} else if (bs->bh && s->base == bs->bh->b_data) {
 			/* We were modifying this block in-place. */
 			ea_bdebug(bs->bh, "keeping this block");
+			ext4_xattr_cache_insert(ext4_mb_cache, bs->bh);
 			new_bh = bs->bh;
 			get_bh(new_bh);
 		} else {
-- 
2.14.3

Re: backporting "ext4: inplace xattr block update fails to deduplicate blocks" to LTS kernels?

[Tommi Rantala]

On 21.02.2018 17:56, Theodore Ts'o wrote:

On Wed, Feb 21, 2018 at 12:40:00PM +0100, Greg Kroah-Hartman wrote:

On Mon, Feb 19, 2018 at 03:26:37PM +0200, Tommi Rantala wrote:


OK to backport it?
I tested it briefly in 4.9, seems to work.


It looks sane, but it would be nice if I can get people who are
backporting ext4 patches to make sure there are no regressions using
one of kvm-xfstests[1] or gce-xfstests[2][3].

[1] 
https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-xfstests.md
[2] 
https://github.com/tytso/xfstests-bld/blob/master/Documentation/gce-xfstests.md
[3] https://thunk.org/gce-xfstests

I do run regression tests[4] on stable kernels when I have time, but
it scales much better when other people can help.

[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/tag/?h=ext4-4.9.54-1


I need an ack from the ext4 maintainers before I can take this...


Greg, you can go ahead and take this, but in the future I'd appreciate
it if ext4 backporters could at least run a smoke test (which takes
less than 15 minutes on GCE) before and after the patch, and report no
test regressions.


Thanks for the instructions!

Smoke test results 4.9.82 with and without the patch (attached, to avoid 
email client mangling it), no new failures:


 Summary report
KERNEL:kernel 4.9.82-xfstests #2 SMP Thu Feb 22 14:58:27 EET 2018 x86_64
CPUS:  2
MEM:   1989.2

ext4/4k: 271 tests, 7 failures, 34 skipped, 737 seconds
  Failures: generic/081 generic/383 generic/384 generic/386
generic/441 generic/451 generic/472
Totals: 271 tests, 34 skipped, 7 failures, 0 errors, 685s


 Summary report
KERNEL:kernel 4.9.82-xfstests-1-gb98ae0251413 #1 SMP Thu Feb 22 
14:31:01 EET 2018 x86_64

CPUS:  2
MEM:   1989.2

ext4/4k: 271 tests, 7 failures, 34 skipped, 749 seconds
  Failures: generic/081 generic/383 generic/384 generic/386
generic/441 generic/451 generic/472
Totals: 271 tests, 34 skipped, 7 failures, 0 errors, 694s

FSTESTVER: e2fsprogs v1.43.6-85-g7595699d0 (Wed, 6 Sep 2017 22:04:14 -0400)
FSTESTVER: fio  fio-3.2 (Fri, 3 Nov 2017 15:23:49 -0600)
FSTESTVER: quota  4d81e8b (Mon, 16 Oct 2017 09:42:44 +0200)
FSTESTVER: stress-ng 977ae35 (Wed, 6 Sep 2017 23:45:03 -0400)
FSTESTVER: xfsprogs v4.14.0-rc2-1-g19ca9b0b (Mon, 27 Nov 2017 10:56:21 
-0600)

FSTESTVER: xfstests-bld ff7b8c2 (Wed, 13 Dec 2017 21:24:24 -0500)
FSTESTVER: xfstests linux-v3.8-1832-gafeee2d9 (Sun, 31 Dec 2017 13:35:28 
-0500)

FSTESTCFG: 4k
FSTESTSET: -g quick
FSTESTOPT: aex


Tommi
>From b98ae025141361b9e92fdd470dfd2314a64a47d0 Mon Sep 17 00:00:00 2001
From: Tahsin Erdogan 
Date: Sat, 5 Aug 2017 22:41:42 -0400
Subject: [PATCH] ext4: inplace xattr block update fails to deduplicate blocks

commit ec00022030da5761518476096626338bd67df57a upstream.

When an xattr block has a single reference, block is updated inplace
and it is reinserted to the cache. Later, a cache lookup is performed
to see whether an existing block has the same contents. This cache
lookup will most of the time return the just inserted entry so
deduplication is not achieved.

Running the following test script will produce two xattr blocks which
can be observed in "File ACL: " line of debugfs output:

  mke2fs -b 1024 -I 128 -F -O extent /dev/sdb 1G
  mount /dev/sdb /mnt/sdb

  touch /mnt/sdb/{x,y}

  setfattr -n user.1 -v aaa /mnt/sdb/x
  setfattr -n user.2 -v bbb /mnt/sdb/x

  setfattr -n user.1 -v aaa /mnt/sdb/y
  setfattr -n user.2 -v bbb /mnt/sdb/y

  debugfs -R 'stat x' /dev/sdb | cat
  debugfs -R 'stat y' /dev/sdb | cat

This patch defers the reinsertion to the cache so that we can locate
other blocks with the same contents.

Signed-off-by: Tahsin Erdogan 
Signed-off-by: Theodore Ts'o 
Reviewed-by: Andreas Dilger 
Signed-off-by: Tommi Rantala 
---
 fs/ext4/xattr.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 3eeed8f0aa06..3fadfabcac39 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -837,8 +837,6 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
 if (!IS_LAST_ENTRY(s->first))
 	ext4_xattr_rehash(header(s->base),
 			  s->here);
-ext4_xattr_cache_insert(ext4_mb_cache,
-	bs->bh);
 			}
 			ext4_xattr_block_csum_set(inode, bs->bh);
 			unlock_buffer(bs->bh);
@@ -959,6 +957,7 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
 		} else if (bs->bh && s->base == bs->bh->b_data) {
 			/* We were modifying this block in-place. */
 			ea_bdebug(bs->bh, "keeping this block");
+			ext4_xattr_cache_insert(ext4_mb_cache, bs->bh);
 			new_bh = bs->bh;
 			get_bh(new_bh);
 		} else {
-- 
2.14.3

Re: net: hang in unregister_netdevice: waiting for lo to become free

[Tommi Rantala]

On 20.02.2018 18:26, Neil Horman wrote:

On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote:

On Tue, Feb 20, 2018 at 8:56 AM, Tommi Rantala
<tommi.t.rant...@nokia.com> wrote:

On 19.02.2018 20:59, Dmitry Vyukov wrote:

Is this meant to be fixed already? I am still seeing this on the
latest upstream tree.



These two commits are in v4.16-rc1:

commit 4a31a6b19f9ddf498c81f5c9b089742b7472a6f8
Author: Tommi Rantala <tommi.t.rant...@nokia.com>
Date:   Mon Feb 5 21:48:14 2018 +0200

 sctp: fix dst refcnt leak in sctp_v4_get_dst
...
 Fixes: 410f03831 ("sctp: add routing output fallback")
 Fixes: 0ca50d12f ("sctp: fix src address selection if using secondary
addresses")


commit 957d761cf91cdbb175ad7d8f5472336a4d54dbf2
Author: Alexey Kodanev <alexey.koda...@oracle.com>
Date:   Mon Feb 5 15:10:35 2018 +0300

 sctp: fix dst refcnt leak in sctp_v6_get_dst()
...
 Fixes: dbc2b5e9a09e ("sctp: fix src address selection if using secondary
addresses for ipv6")


I guess we missed something if it's still reproducible.

I can check it later this week, unless someone else beat me to it.


Hi Tommi,

Hmmm, I can't claim that it's exactly the same bug. Perhaps it's
another one then. But I am still seeing these:

[   58.799130] unregister_netdevice: waiting for lo to become free.
Usage count = 4
[   60.847138] unregister_netdevice: waiting for lo to become free.
Usage count = 4
[   62.895093] unregister_netdevice: waiting for lo to become free.
Usage count = 4
[   64.943103] unregister_netdevice: waiting for lo to become free.
Usage count = 4

on upstream tree pulled ~12 hours ago.


Can you write a systemtap script to probe dev_hold, and dev_put, printing out a
backtrace if the device name matches "lo".  That should tell us definitively if
the problem is in the same location or not


Hi Dmitry, I tested with the reproducer and the kernel .config file that 
you sent in the first email in this thread:


With 4.16-rc2 unable to reproduce.

With 4.15-rc9 bug reproducible, and I get "unregister_netdevice: waiting 
for lo to become free. Usage count = 3"


With 4.15-rc9 and Alexey's "sctp: fix dst refcnt leak in 
sctp_v6_get_dst()" cherry-picked on top, unable to reproduce.



Is syzkaller doing something else now to trigger the bug...?
Can you still trigger the bug with the same reproducer?


Tommi

Re: net: hang in unregister_netdevice: waiting for lo to become free

[Tommi Rantala]

On 20.02.2018 18:26, Neil Horman wrote:

On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote:

On Tue, Feb 20, 2018 at 8:56 AM, Tommi Rantala
 wrote:

On 19.02.2018 20:59, Dmitry Vyukov wrote:

Is this meant to be fixed already? I am still seeing this on the
latest upstream tree.



These two commits are in v4.16-rc1:

commit 4a31a6b19f9ddf498c81f5c9b089742b7472a6f8
Author: Tommi Rantala 
Date:   Mon Feb 5 21:48:14 2018 +0200

 sctp: fix dst refcnt leak in sctp_v4_get_dst
...
 Fixes: 410f03831 ("sctp: add routing output fallback")
 Fixes: 0ca50d12f ("sctp: fix src address selection if using secondary
addresses")


commit 957d761cf91cdbb175ad7d8f5472336a4d54dbf2
Author: Alexey Kodanev 
Date:   Mon Feb 5 15:10:35 2018 +0300

 sctp: fix dst refcnt leak in sctp_v6_get_dst()
...
 Fixes: dbc2b5e9a09e ("sctp: fix src address selection if using secondary
addresses for ipv6")


I guess we missed something if it's still reproducible.

I can check it later this week, unless someone else beat me to it.


Hi Tommi,

Hmmm, I can't claim that it's exactly the same bug. Perhaps it's
another one then. But I am still seeing these:

[   58.799130] unregister_netdevice: waiting for lo to become free.
Usage count = 4
[   60.847138] unregister_netdevice: waiting for lo to become free.
Usage count = 4
[   62.895093] unregister_netdevice: waiting for lo to become free.
Usage count = 4
[   64.943103] unregister_netdevice: waiting for lo to become free.
Usage count = 4

on upstream tree pulled ~12 hours ago.


Can you write a systemtap script to probe dev_hold, and dev_put, printing out a
backtrace if the device name matches "lo".  That should tell us definitively if
the problem is in the same location or not


Hi Dmitry, I tested with the reproducer and the kernel .config file that 
you sent in the first email in this thread:


With 4.16-rc2 unable to reproduce.

With 4.15-rc9 bug reproducible, and I get "unregister_netdevice: waiting 
for lo to become free. Usage count = 3"


With 4.15-rc9 and Alexey's "sctp: fix dst refcnt leak in 
sctp_v6_get_dst()" cherry-picked on top, unable to reproduce.



Is syzkaller doing something else now to trigger the bug...?
Can you still trigger the bug with the same reproducer?


Tommi

Re: net: hang in unregister_netdevice: waiting for lo to become free

[Tommi Rantala]

On 19.02.2018 20:59, Dmitry Vyukov wrote:

On Sat, Feb 3, 2018 at 1:15 PM, Xin Long <lucien@gmail.com> wrote:

On 1/30/18 1:57 PM, David Ahern wrote:

On 1/30/18 1:08 PM, Daniel Borkmann wrote:

On 01/30/2018 07:32 PM, Cong Wang wrote:

On Tue, Jan 30, 2018 at 4:09 AM, Dmitry Vyukov <dvyu...@google.com> wrote:

Hello,

The following program creates a hang in unregister_netdevice.
cleanup_net work hangs there forever periodically printing
"unregister_netdevice: waiting for lo to become free. Usage count = 3"
and creation of any new network namespaces hangs forever.


Interestingly, this is not reproducible on net-next.


The most recent change on netns refcnt was 4ee806d51176 ("net: tcp: close
sock if net namespace is exiting") in net/net-next from 5 days ago, maybe
fixed due to that?



This appears to be the commit introducing the refcnt leak:

$ git bisect bad
dbc2b5e9a09e9a6664679a667ff81cff6e5f2641 is the first bad commit
commit dbc2b5e9a09e9a6664679a667ff81cff6e5f2641
Author: Xin Long <lucien@gmail.com>
Date:   Fri May 12 14:39:52 2017 +0800

 sctp: fix src address selection if using secondary addresses for ipv6


v4.14 is bad. Running bisect in the background while doing other things



Interesting. The commit that avoids the refcnt leak is

commit 955ec4cb3b54c7c389a9f830be7d3ae2056b9212
Author: David Ahern <dsah...@gmail.com>
Date:   Wed Jan 24 19:45:29 2018 -0800

 net/ipv6: Do not allow route add with a device that is down

That commit does not intentionally address the problem so it is just
masking the problematic code introduced by the commit above.

Thanks, David A.

I'm still on a trip. will look into this asap.


Alexey and Tommi already had the patches for this issue on
both SCTP v4 and v6 dst_get, Thanks.




Is this meant to be fixed already? I am still seeing this on the
latest upstream tree.



These two commits are in v4.16-rc1:

commit 4a31a6b19f9ddf498c81f5c9b089742b7472a6f8
Author: Tommi Rantala <tommi.t.rant...@nokia.com>
Date:   Mon Feb 5 21:48:14 2018 +0200

sctp: fix dst refcnt leak in sctp_v4_get_dst
...
Fixes: 410f03831 ("sctp: add routing output fallback")
Fixes: 0ca50d12f ("sctp: fix src address selection if using 
secondary addresses")



commit 957d761cf91cdbb175ad7d8f5472336a4d54dbf2
Author: Alexey Kodanev <alexey.koda...@oracle.com>
Date:   Mon Feb 5 15:10:35 2018 +0300

sctp: fix dst refcnt leak in sctp_v6_get_dst()
...
Fixes: dbc2b5e9a09e ("sctp: fix src address selection if using 
secondary addresses for ipv6")



I guess we missed something if it's still reproducible.

I can check it later this week, unless someone else beat me to it.

Tommi

Re: net: hang in unregister_netdevice: waiting for lo to become free

[Tommi Rantala]

On 19.02.2018 20:59, Dmitry Vyukov wrote:

On Sat, Feb 3, 2018 at 1:15 PM, Xin Long  wrote:

On 1/30/18 1:57 PM, David Ahern wrote:

On 1/30/18 1:08 PM, Daniel Borkmann wrote:

On 01/30/2018 07:32 PM, Cong Wang wrote:

On Tue, Jan 30, 2018 at 4:09 AM, Dmitry Vyukov  wrote:

Hello,

The following program creates a hang in unregister_netdevice.
cleanup_net work hangs there forever periodically printing
"unregister_netdevice: waiting for lo to become free. Usage count = 3"
and creation of any new network namespaces hangs forever.


Interestingly, this is not reproducible on net-next.


The most recent change on netns refcnt was 4ee806d51176 ("net: tcp: close
sock if net namespace is exiting") in net/net-next from 5 days ago, maybe
fixed due to that?



This appears to be the commit introducing the refcnt leak:

$ git bisect bad
dbc2b5e9a09e9a6664679a667ff81cff6e5f2641 is the first bad commit
commit dbc2b5e9a09e9a6664679a667ff81cff6e5f2641
Author: Xin Long 
Date:   Fri May 12 14:39:52 2017 +0800

 sctp: fix src address selection if using secondary addresses for ipv6


v4.14 is bad. Running bisect in the background while doing other things



Interesting. The commit that avoids the refcnt leak is

commit 955ec4cb3b54c7c389a9f830be7d3ae2056b9212
Author: David Ahern 
Date:   Wed Jan 24 19:45:29 2018 -0800

 net/ipv6: Do not allow route add with a device that is down

That commit does not intentionally address the problem so it is just
masking the problematic code introduced by the commit above.

Thanks, David A.

I'm still on a trip. will look into this asap.


Alexey and Tommi already had the patches for this issue on
both SCTP v4 and v6 dst_get, Thanks.




Is this meant to be fixed already? I am still seeing this on the
latest upstream tree.



These two commits are in v4.16-rc1:

commit 4a31a6b19f9ddf498c81f5c9b089742b7472a6f8
Author: Tommi Rantala 
Date:   Mon Feb 5 21:48:14 2018 +0200

sctp: fix dst refcnt leak in sctp_v4_get_dst
...
Fixes: 410f03831 ("sctp: add routing output fallback")
Fixes: 0ca50d12f ("sctp: fix src address selection if using 
secondary addresses")



commit 957d761cf91cdbb175ad7d8f5472336a4d54dbf2
Author: Alexey Kodanev 
Date:   Mon Feb 5 15:10:35 2018 +0300

sctp: fix dst refcnt leak in sctp_v6_get_dst()
...
Fixes: dbc2b5e9a09e ("sctp: fix src address selection if using 
secondary addresses for ipv6")



I guess we missed something if it's still reproducible.

I can check it later this week, unless someone else beat me to it.

Tommi

backporting "ext4: inplace xattr block update fails to deduplicate blocks" to LTS kernels?

[Tommi Rantala]

Hi,

4.9 (and earlier) LTS kernels are missing this:

commit ec00022030da5761518476096626338bd67df57a
Author: Tahsin Erdogan 
Date:   Sat Aug 5 22:41:42 2017 -0400

ext4: inplace xattr block update fails to deduplicate blocks


OK to backport it?
I tested it briefly in 4.9, seems to work.

One of our testers noticed a glusterfs performance regression when going 
from 4.4 to 4.9, caused by the duplicated blocks.


In I understand everything correctly, in 4.4 mbcache uses the block 
number in the hash table bucket calculation, and the hash table is 
populated quite evenly even if there are duplicates. So the mbcache is fast.


But in later kernels mbcache puts all the duplicate entries into a 
single bucket. As the entries are stored in one big linked list, this 
obviously makes the mbcache slow.



I tested this in 4.9 (which still has the ext4_xattr_rehash() call that 
got eliminated in commit "ext4: eliminate xattr entry e_hash 
recalculation for removes"):



diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 3eeed8f0aa06..3fadfabcac39 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -837,8 +837,6 @@ ext4_xattr_block_set(handle_t *handle, struct inode 
*inode,

if (!IS_LAST_ENTRY(s->first))
ext4_xattr_rehash(header(s->base),
  s->here);
-   ext4_xattr_cache_insert(ext4_mb_cache,
-   bs->bh);
}
ext4_xattr_block_csum_set(inode, bs->bh);
unlock_buffer(bs->bh);
@@ -959,6 +957,7 @@ ext4_xattr_block_set(handle_t *handle, struct inode 
*inode,

} else if (bs->bh && s->base == bs->bh->b_data) {
/* We were modifying this block in-place. */
ea_bdebug(bs->bh, "keeping this block");
+   ext4_xattr_cache_insert(ext4_mb_cache, bs->bh);
new_bh = bs->bh;
get_bh(new_bh);
} else {



Tommi

backporting "ext4: inplace xattr block update fails to deduplicate blocks" to LTS kernels?

[Tommi Rantala]

Hi,

4.9 (and earlier) LTS kernels are missing this:

commit ec00022030da5761518476096626338bd67df57a
Author: Tahsin Erdogan 
Date:   Sat Aug 5 22:41:42 2017 -0400

ext4: inplace xattr block update fails to deduplicate blocks


OK to backport it?
I tested it briefly in 4.9, seems to work.

One of our testers noticed a glusterfs performance regression when going 
from 4.4 to 4.9, caused by the duplicated blocks.


In I understand everything correctly, in 4.4 mbcache uses the block 
number in the hash table bucket calculation, and the hash table is 
populated quite evenly even if there are duplicates. So the mbcache is fast.


But in later kernels mbcache puts all the duplicate entries into a 
single bucket. As the entries are stored in one big linked list, this 
obviously makes the mbcache slow.



I tested this in 4.9 (which still has the ext4_xattr_rehash() call that 
got eliminated in commit "ext4: eliminate xattr entry e_hash 
recalculation for removes"):



diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 3eeed8f0aa06..3fadfabcac39 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -837,8 +837,6 @@ ext4_xattr_block_set(handle_t *handle, struct inode 
*inode,

if (!IS_LAST_ENTRY(s->first))
ext4_xattr_rehash(header(s->base),
  s->here);
-   ext4_xattr_cache_insert(ext4_mb_cache,
-   bs->bh);
}
ext4_xattr_block_csum_set(inode, bs->bh);
unlock_buffer(bs->bh);
@@ -959,6 +957,7 @@ ext4_xattr_block_set(handle_t *handle, struct inode 
*inode,

} else if (bs->bh && s->base == bs->bh->b_data) {
/* We were modifying this block in-place. */
ea_bdebug(bs->bh, "keeping this block");
+   ext4_xattr_cache_insert(ext4_mb_cache, bs->bh);
new_bh = bs->bh;
get_bh(new_bh);
} else {



Tommi

intel_pmu_init() extra_attr memory leak

[Tommi Rantala]

Hi,

I'm seeing this kmemleak report in v4.15-rc4:

# cat /sys/kernel/debug/kmemleak
unreferenced object 0x8801f3d5d720 (size 64):
  comm "swapper/0", pid 1, jiffies 4294667312 (age 2687.423s)
  hex dump (first 32 bytes):
60 d1 41 ad ff ff ff ff 20 d1 41 ad ff ff ff ff  `.A. .A.
80 d0 41 ad ff ff ff ff 40 d0 41 ad ff ff ff ff  ..A.@.A.
  backtrace:
[] intel_pmu_init+0x1844/0x1d38
[] init_hw_perf_events+0x8c/0x66f
[] do_one_initcall+0x7b/0x1d0
[<8ee1f02a>] kernel_init_freeable+0x163/0x2f9
[] kernel_init+0xf/0x120
[<38a99264>] ret_from_fork+0x24/0x30
[] 0x


$ ./scripts/faddr2line vmlinux intel_pmu_init+0x1844/0x1d38
intel_pmu_init+0x1844/0x1d38:
intel_pmu_init at arch/x86/events/intel/core.c:4296


Which matches line:
extra_attr = merge_attr(extra_attr, skl_format_attr);


So looks like "extra_attr" is leaked here.


"git blame" points to this commit:

commit a5df70c354c26e20d5fd8eb64517f724e97ef0b2
Author: Andi Kleen 
Date:   Tue Aug 22 11:52:00 2017 -0700

perf/x86: Only show format attributes when supported



-Tommi

intel_pmu_init() extra_attr memory leak

[Tommi Rantala]

Hi,

I'm seeing this kmemleak report in v4.15-rc4:

# cat /sys/kernel/debug/kmemleak
unreferenced object 0x8801f3d5d720 (size 64):
  comm "swapper/0", pid 1, jiffies 4294667312 (age 2687.423s)
  hex dump (first 32 bytes):
60 d1 41 ad ff ff ff ff 20 d1 41 ad ff ff ff ff  `.A. .A.
80 d0 41 ad ff ff ff ff 40 d0 41 ad ff ff ff ff  ..A.@.A.
  backtrace:
[] intel_pmu_init+0x1844/0x1d38
[] init_hw_perf_events+0x8c/0x66f
[] do_one_initcall+0x7b/0x1d0
[<8ee1f02a>] kernel_init_freeable+0x163/0x2f9
[] kernel_init+0xf/0x120
[<38a99264>] ret_from_fork+0x24/0x30
[] 0x


$ ./scripts/faddr2line vmlinux intel_pmu_init+0x1844/0x1d38
intel_pmu_init+0x1844/0x1d38:
intel_pmu_init at arch/x86/events/intel/core.c:4296


Which matches line:
extra_attr = merge_attr(extra_attr, skl_format_attr);


So looks like "extra_attr" is leaked here.


"git blame" points to this commit:

commit a5df70c354c26e20d5fd8eb64517f724e97ef0b2
Author: Andi Kleen 
Date:   Tue Aug 22 11:52:00 2017 -0700

perf/x86: Only show format attributes when supported



-Tommi

Re: [PATCH net v2] tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()

[Tommi Rantala]

On 01.12.2017 15:18, Ying Xue wrote:

On 11/30/2017 08:32 PM, Tommi Rantala wrote:

In my opinion, the real root cause of the issue is because we too early
set a not-yet-initialized bearer instance to ub->bearer through
rcu_assign_pointer(ub->bearer, b) in tipc_udp_enable(). Instead if we
assign the bearer pointer at the end of tipc_udp_enable() where the
bearer has been completed the initialization, the issue would be avoided.

Hi, sorry, I fail to see how that helps.

bearer->tolerance is only initialized in tipc_enable_bearer() after
calling m->enable_media() ie. tipc_udp_enable().

So even if we do "rcu_assign_pointer(ub->bearer, b)" later in
tipc_udp_enable(), bearer->tolerance will still be uninitialized, and
the crash can happen.


Sorry, I missed the point that b->tolerance is not uninitialized when we
assign bearer pointer to ub->bearer later.

But in my view the issue happened is because we enable media too early.
So it's better to change the code as belows:


Thanks, looks good to me!

Tested in 4.4 (which does not have b->up), and this fixes the oops also 
there.


-Tommi



diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
index 47ec121..ec6f02a 100644
--- a/net/tipc/bearer.c
+++ b/net/tipc/bearer.c
@@ -320,19 +320,18 @@ static int tipc_enable_bearer(struct net *net,
const char *name,

 strcpy(b->name, name);
 b->media = m;
-   res = m->enable_media(net, b, attr);
-   if (res) {
-   pr_warn("Bearer <%s> rejected, enable failure (%d)\n",
-   name, -res);
-   return -EINVAL;
-   }
-
 b->identity = bearer_id;
 b->tolerance = m->tolerance;
 b->window = m->window;
 b->domain = disc_domain;
 b->net_plane = bearer_id + 'A';
 b->priority = priority;
+   res = m->enable_media(net, b, attr);
+   if (res) {
+   pr_warn("Bearer <%s> rejected, enable failure (%d)\n",
+   name, -res);
+   return -EINVAL;
+   }
 test_and_set_bit_lock(0, >up);

Re: [PATCH net v2] tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()

[Tommi Rantala]

On 01.12.2017 15:18, Ying Xue wrote:

On 11/30/2017 08:32 PM, Tommi Rantala wrote:

In my opinion, the real root cause of the issue is because we too early
set a not-yet-initialized bearer instance to ub->bearer through
rcu_assign_pointer(ub->bearer, b) in tipc_udp_enable(). Instead if we
assign the bearer pointer at the end of tipc_udp_enable() where the
bearer has been completed the initialization, the issue would be avoided.

Hi, sorry, I fail to see how that helps.

bearer->tolerance is only initialized in tipc_enable_bearer() after
calling m->enable_media() ie. tipc_udp_enable().

So even if we do "rcu_assign_pointer(ub->bearer, b)" later in
tipc_udp_enable(), bearer->tolerance will still be uninitialized, and
the crash can happen.


Sorry, I missed the point that b->tolerance is not uninitialized when we
assign bearer pointer to ub->bearer later.

But in my view the issue happened is because we enable media too early.
So it's better to change the code as belows:


Thanks, looks good to me!

Tested in 4.4 (which does not have b->up), and this fixes the oops also 
there.


-Tommi



diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
index 47ec121..ec6f02a 100644
--- a/net/tipc/bearer.c
+++ b/net/tipc/bearer.c
@@ -320,19 +320,18 @@ static int tipc_enable_bearer(struct net *net,
const char *name,

 strcpy(b->name, name);
 b->media = m;
-   res = m->enable_media(net, b, attr);
-   if (res) {
-   pr_warn("Bearer <%s> rejected, enable failure (%d)\n",
-   name, -res);
-   return -EINVAL;
-   }
-
 b->identity = bearer_id;
 b->tolerance = m->tolerance;
 b->window = m->window;
 b->domain = disc_domain;
 b->net_plane = bearer_id + 'A';
 b->priority = priority;
+   res = m->enable_media(net, b, attr);
+   if (res) {
+   pr_warn("Bearer <%s> rejected, enable failure (%d)\n",
+   name, -res);
+   return -EINVAL;
+   }
 test_and_set_bit_lock(0, >up);

Re: [PATCH net v2] tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()

[Tommi Rantala]

On 30.11.2017 12:57, Ying Xue wrote:

On 11/29/2017 06:48 PM, Tommi Rantala wrote:

Remove the second tipc_rcv() call in tipc_udp_recv(). We have just
checked that the bearer is not up, and calling tipc_rcv() with a bearer
that is not up leads to a TIPC div-by-zero crash in
tipc_node_calculate_timer(). The crash is rare in practice, but can
happen like this:


In my opinion, the real root cause of the issue is because we too early
set a not-yet-initialized bearer instance to ub->bearer through
rcu_assign_pointer(ub->bearer, b) in tipc_udp_enable(). Instead if we
assign the bearer pointer at the end of tipc_udp_enable() where the
bearer has been completed the initialization, the issue would be avoided.


Hi, sorry, I fail to see how that helps.

bearer->tolerance is only initialized in tipc_enable_bearer() after 
calling m->enable_media() ie. tipc_udp_enable().


So even if we do "rcu_assign_pointer(ub->bearer, b)" later in 
tipc_udp_enable(), bearer->tolerance will still be uninitialized, and 
the crash can happen.


BR,
Tommi


Thanks,
Ying



   We're enabling a bearer, but it's not yet up and fully initialized.
   At the same time we receive a discovery packet, and in tipc_udp_recv()
   we end up calling tipc_rcv() with the not-yet-initialized bearer,
   causing later the div-by-zero crash in tipc_node_calculate_timer().

Jon Maloy explains the impact of removing the second tipc_rcv() call:
   "link setup in the worst case will be delayed until the next arriving
discovery messages, 1 sec later, and this is an acceptable delay."

As the tipc_rcv() call is removed, just leave the function via the
rcu_out label, so that we will kfree_skb().

[   12.590450] Own node address <1.1.1>, network identity 1
[   12.668088] divide error:  [#1] SMP
[   12.676952] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.14.2-dirty #1
[   12.679225] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-2.fc27 04/01/2014
[   12.682095] task: 8c2a761edb80 task.stack: a41cc0cac000
[   12.684087] RIP: 0010:tipc_node_calculate_timer.isra.12+0x45/0x60 [tipc]
[   12.686486] RSP: 0018:8c2a7fc838a0 EFLAGS: 00010246
[   12.688451] RAX:  RBX: 8c2a5b382600 RCX: 
[   12.691197] RDX:  RSI: 8c2a5b382600 RDI: 8c2a5b382600
[   12.693945] RBP: 8c2a7fc838b0 R08: 0001 R09: 0001
[   12.696632] R10:  R11:  R12: 8c2a5d8949d8
[   12.699491] R13: 95ede400 R14:  R15: 8c2a5d894800
[   12.702338] FS:  () GS:8c2a7fc8() 
knlGS:
[   12.705099] CS:  0010 DS:  ES:  CR0: 80050033
[   12.706776] CR2: 01bb9440 CR3: bd009001 CR4: 003606e0
[   12.708847] DR0:  DR1:  DR2: 
[   12.711016] DR3:  DR6: fffe0ff0 DR7: 0400
[   12.712627] Call Trace:
[   12.713390]  
[   12.714011]  tipc_node_check_dest+0x2e8/0x350 [tipc]
[   12.715286]  tipc_disc_rcv+0x14d/0x1d0 [tipc]
[   12.716370]  tipc_rcv+0x8b0/0xd40 [tipc]
[   12.717396]  ? minmax_running_min+0x2f/0x60
[   12.718248]  ? dst_alloc+0x4c/0xa0
[   12.718964]  ? tcp_ack+0xaf1/0x10b0
[   12.719658]  ? tipc_udp_is_known_peer+0xa0/0xa0 [tipc]
[   12.720634]  tipc_udp_recv+0x71/0x1d0 [tipc]
[   12.721459]  ? dst_alloc+0x4c/0xa0
[   12.722130]  udp_queue_rcv_skb+0x264/0x490
[   12.722924]  __udp4_lib_rcv+0x21e/0x990
[   12.723670]  ? ip_route_input_rcu+0x2dd/0xbf0
[   12.724442]  ? tcp_v4_rcv+0x958/0xa40
[   12.725039]  udp_rcv+0x1a/0x20
[   12.725587]  ip_local_deliver_finish+0x97/0x1d0
[   12.726323]  ip_local_deliver+0xaf/0xc0
[   12.726959]  ? ip_route_input_noref+0x19/0x20
[   12.727689]  ip_rcv_finish+0xdd/0x3b0
[   12.728307]  ip_rcv+0x2ac/0x360
[   12.728839]  __netif_receive_skb_core+0x6fb/0xa90
[   12.729580]  ? udp4_gro_receive+0x1a7/0x2c0
[   12.730274]  __netif_receive_skb+0x1d/0x60
[   12.730953]  ? __netif_receive_skb+0x1d/0x60
[   12.731637]  netif_receive_skb_internal+0x37/0xd0
[   12.732371]  napi_gro_receive+0xc7/0xf0
[   12.732920]  receive_buf+0x3c3/0xd40
[   12.733441]  virtnet_poll+0xb1/0x250
[   12.733944]  net_rx_action+0x23e/0x370
[   12.734476]  __do_softirq+0xc5/0x2f8
[   12.734922]  irq_exit+0xfa/0x100
[   12.735315]  do_IRQ+0x4f/0xd0
[   12.735680]  common_interrupt+0xa2/0xa2
[   12.736126]  
[   12.736416] RIP: 0010:native_safe_halt+0x6/0x10
[   12.736925] RSP: 0018:a41cc0cafe90 EFLAGS: 0246 ORIG_RAX: 
ff4d
[   12.737756] RAX:  RBX: 8c2a761edb80 RCX: 
[   12.738504] RDX:  RSI:  RDI: 
[   12.739258] RBP: a41cc0cafe90 R08: 014b5b9795e5 R09: a41cc12c7e88
[   12.740118] R10:  R11:  R12: 0002
[   12.740964] R13: 8c2a761edb80 R14: 

Re: [PATCH net v2] tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()

[Tommi Rantala]

On 30.11.2017 12:57, Ying Xue wrote:

On 11/29/2017 06:48 PM, Tommi Rantala wrote:

Remove the second tipc_rcv() call in tipc_udp_recv(). We have just
checked that the bearer is not up, and calling tipc_rcv() with a bearer
that is not up leads to a TIPC div-by-zero crash in
tipc_node_calculate_timer(). The crash is rare in practice, but can
happen like this:


In my opinion, the real root cause of the issue is because we too early
set a not-yet-initialized bearer instance to ub->bearer through
rcu_assign_pointer(ub->bearer, b) in tipc_udp_enable(). Instead if we
assign the bearer pointer at the end of tipc_udp_enable() where the
bearer has been completed the initialization, the issue would be avoided.


Hi, sorry, I fail to see how that helps.

bearer->tolerance is only initialized in tipc_enable_bearer() after 
calling m->enable_media() ie. tipc_udp_enable().


So even if we do "rcu_assign_pointer(ub->bearer, b)" later in 
tipc_udp_enable(), bearer->tolerance will still be uninitialized, and 
the crash can happen.


BR,
Tommi


Thanks,
Ying



   We're enabling a bearer, but it's not yet up and fully initialized.
   At the same time we receive a discovery packet, and in tipc_udp_recv()
   we end up calling tipc_rcv() with the not-yet-initialized bearer,
   causing later the div-by-zero crash in tipc_node_calculate_timer().

Jon Maloy explains the impact of removing the second tipc_rcv() call:
   "link setup in the worst case will be delayed until the next arriving
discovery messages, 1 sec later, and this is an acceptable delay."

As the tipc_rcv() call is removed, just leave the function via the
rcu_out label, so that we will kfree_skb().

[   12.590450] Own node address <1.1.1>, network identity 1
[   12.668088] divide error:  [#1] SMP
[   12.676952] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.14.2-dirty #1
[   12.679225] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-2.fc27 04/01/2014
[   12.682095] task: 8c2a761edb80 task.stack: a41cc0cac000
[   12.684087] RIP: 0010:tipc_node_calculate_timer.isra.12+0x45/0x60 [tipc]
[   12.686486] RSP: 0018:8c2a7fc838a0 EFLAGS: 00010246
[   12.688451] RAX:  RBX: 8c2a5b382600 RCX: 
[   12.691197] RDX:  RSI: 8c2a5b382600 RDI: 8c2a5b382600
[   12.693945] RBP: 8c2a7fc838b0 R08: 0001 R09: 0001
[   12.696632] R10:  R11:  R12: 8c2a5d8949d8
[   12.699491] R13: 95ede400 R14:  R15: 8c2a5d894800
[   12.702338] FS:  () GS:8c2a7fc8() 
knlGS:
[   12.705099] CS:  0010 DS:  ES:  CR0: 80050033
[   12.706776] CR2: 01bb9440 CR3: bd009001 CR4: 003606e0
[   12.708847] DR0:  DR1:  DR2: 
[   12.711016] DR3:  DR6: fffe0ff0 DR7: 0400
[   12.712627] Call Trace:
[   12.713390]  
[   12.714011]  tipc_node_check_dest+0x2e8/0x350 [tipc]
[   12.715286]  tipc_disc_rcv+0x14d/0x1d0 [tipc]
[   12.716370]  tipc_rcv+0x8b0/0xd40 [tipc]
[   12.717396]  ? minmax_running_min+0x2f/0x60
[   12.718248]  ? dst_alloc+0x4c/0xa0
[   12.718964]  ? tcp_ack+0xaf1/0x10b0
[   12.719658]  ? tipc_udp_is_known_peer+0xa0/0xa0 [tipc]
[   12.720634]  tipc_udp_recv+0x71/0x1d0 [tipc]
[   12.721459]  ? dst_alloc+0x4c/0xa0
[   12.722130]  udp_queue_rcv_skb+0x264/0x490
[   12.722924]  __udp4_lib_rcv+0x21e/0x990
[   12.723670]  ? ip_route_input_rcu+0x2dd/0xbf0
[   12.724442]  ? tcp_v4_rcv+0x958/0xa40
[   12.725039]  udp_rcv+0x1a/0x20
[   12.725587]  ip_local_deliver_finish+0x97/0x1d0
[   12.726323]  ip_local_deliver+0xaf/0xc0
[   12.726959]  ? ip_route_input_noref+0x19/0x20
[   12.727689]  ip_rcv_finish+0xdd/0x3b0
[   12.728307]  ip_rcv+0x2ac/0x360
[   12.728839]  __netif_receive_skb_core+0x6fb/0xa90
[   12.729580]  ? udp4_gro_receive+0x1a7/0x2c0
[   12.730274]  __netif_receive_skb+0x1d/0x60
[   12.730953]  ? __netif_receive_skb+0x1d/0x60
[   12.731637]  netif_receive_skb_internal+0x37/0xd0
[   12.732371]  napi_gro_receive+0xc7/0xf0
[   12.732920]  receive_buf+0x3c3/0xd40
[   12.733441]  virtnet_poll+0xb1/0x250
[   12.733944]  net_rx_action+0x23e/0x370
[   12.734476]  __do_softirq+0xc5/0x2f8
[   12.734922]  irq_exit+0xfa/0x100
[   12.735315]  do_IRQ+0x4f/0xd0
[   12.735680]  common_interrupt+0xa2/0xa2
[   12.736126]  
[   12.736416] RIP: 0010:native_safe_halt+0x6/0x10
[   12.736925] RSP: 0018:a41cc0cafe90 EFLAGS: 0246 ORIG_RAX: 
ff4d
[   12.737756] RAX:  RBX: 8c2a761edb80 RCX: 
[   12.738504] RDX:  RSI:  RDI: 
[   12.739258] RBP: a41cc0cafe90 R08: 014b5b9795e5 R09: a41cc12c7e88
[   12.740118] R10:  R11:  R12: 0002
[   12.740964] R13: 8c2a761edb80 R14: 

[PATCH net v2] tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()

[Tommi Rantala]

(relocation range: 0x8000-0xbfff)
[   12.751215] Rebooting in 60 seconds..

Fixes: c9b64d492b1f ("tipc: add replicast peer discovery")
Signed-off-by: Tommi Rantala <tommi.t.rant...@nokia.com>
Cc: Jon Maloy <jon.ma...@ericsson.com>
---

v2: Resorted to a minimal fix, as per feedback from David M.

 net/tipc/udp_media.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
index ecca64fc6a6f..3deabcab4882 100644
--- a/net/tipc/udp_media.c
+++ b/net/tipc/udp_media.c
@@ -371,10 +371,6 @@ static int tipc_udp_recv(struct sock *sk, struct sk_buff 
*skb)
goto rcu_out;
}
 
-   tipc_rcv(sock_net(sk), skb, b);
-   rcu_read_unlock();
-   return 0;
-
 rcu_out:
rcu_read_unlock();
 out:
-- 
2.14.3

[PATCH net v2] tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()

[Tommi Rantala]

(relocation range: 0x8000-0xbfff)
[   12.751215] Rebooting in 60 seconds..

Fixes: c9b64d492b1f ("tipc: add replicast peer discovery")
Signed-off-by: Tommi Rantala 
Cc: Jon Maloy 
---

v2: Resorted to a minimal fix, as per feedback from David M.

 net/tipc/udp_media.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
index ecca64fc6a6f..3deabcab4882 100644
--- a/net/tipc/udp_media.c
+++ b/net/tipc/udp_media.c
@@ -371,10 +371,6 @@ static int tipc_udp_recv(struct sock *sk, struct sk_buff 
*skb)
goto rcu_out;
}
 
-   tipc_rcv(sock_net(sk), skb, b);
-   rcu_read_unlock();
-   return 0;
-
 rcu_out:
rcu_read_unlock();
 out:
-- 
2.14.3

Re: [PATCH] tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()

[Tommi Rantala]

On 28.11.2017 16:58, David Miller wrote:

From: Tommi Rantala <tommi.t.rant...@nokia.com>
Date: Tue, 28 Nov 2017 14:53:15 +0200


-
-   if (unlikely(msg_user(hdr) == LINK_CONFIG)) {
-   err = tipc_udp_rcast_disc(b, skb);
-   if (err)
-   goto rcu_out;
+   } else {
+   if (unlikely(b && msg_user(hdr) == LINK_CONFIG))
+   tipc_udp_rcast_disc(b, skb);
+   kfree_skb(skb);
}


Either put the 'err' propagation back or clearly explain in your
commit log message why this part of the change if absolutely essential
for this bug fix.

Thank you.



Thanks for the feedback. I'll post patch v2 soon.

-Tommi

Re: [PATCH] tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()

[Tommi Rantala]

On 28.11.2017 16:58, David Miller wrote:

From: Tommi Rantala 
Date: Tue, 28 Nov 2017 14:53:15 +0200


-
-   if (unlikely(msg_user(hdr) == LINK_CONFIG)) {
-   err = tipc_udp_rcast_disc(b, skb);
-   if (err)
-   goto rcu_out;
+   } else {
+   if (unlikely(b && msg_user(hdr) == LINK_CONFIG))
+   tipc_udp_rcast_disc(b, skb);
+   kfree_skb(skb);
}


Either put the 'err' propagation back or clearly explain in your
commit log message why this part of the change if absolutely essential
for this bug fix.

Thank you.



Thanks for the feedback. I'll post patch v2 soon.

-Tommi

[PATCH] tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()

[Tommi Rantala]

Call tipc_rcv() only if bearer is up in tipc_udp_recv().
Fixes a rare TIPC div-by-zero crash in tipc_node_calculate_timer():

We're enabling a bearer, but it's not yet up and fully initialized.
At the same time we receive a discovery packet, and in tipc_udp_recv()
we end up calling tipc_rcv() with the not-yet-initialized bearer,
causing later a div-by-zero crash in tipc_node_calculate_timer().

[   12.590450] Own node address <1.1.1>, network identity 1
[   12.668088] divide error:  [#1] SMP
[   12.676952] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.14.2-dirty #1
[   12.679225] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-2.fc27 04/01/2014
[   12.682095] task: 8c2a761edb80 task.stack: a41cc0cac000
[   12.684087] RIP: 0010:tipc_node_calculate_timer.isra.12+0x45/0x60 [tipc]
[   12.686486] RSP: 0018:8c2a7fc838a0 EFLAGS: 00010246
[   12.688451] RAX:  RBX: 8c2a5b382600 RCX: 
[   12.691197] RDX:  RSI: 8c2a5b382600 RDI: 8c2a5b382600
[   12.693945] RBP: 8c2a7fc838b0 R08: 0001 R09: 0001
[   12.696632] R10:  R11:  R12: 8c2a5d8949d8
[   12.699491] R13: 95ede400 R14:  R15: 8c2a5d894800
[   12.702338] FS:  () GS:8c2a7fc8() 
knlGS:
[   12.705099] CS:  0010 DS:  ES:  CR0: 80050033
[   12.706776] CR2: 01bb9440 CR3: bd009001 CR4: 003606e0
[   12.708847] DR0:  DR1:  DR2: 
[   12.711016] DR3:  DR6: fffe0ff0 DR7: 0400
[   12.712627] Call Trace:
[   12.713390]  
[   12.714011]  tipc_node_check_dest+0x2e8/0x350 [tipc]
[   12.715286]  tipc_disc_rcv+0x14d/0x1d0 [tipc]
[   12.716370]  tipc_rcv+0x8b0/0xd40 [tipc]
[   12.717396]  ? minmax_running_min+0x2f/0x60
[   12.718248]  ? dst_alloc+0x4c/0xa0
[   12.718964]  ? tcp_ack+0xaf1/0x10b0
[   12.719658]  ? tipc_udp_is_known_peer+0xa0/0xa0 [tipc]
[   12.720634]  tipc_udp_recv+0x71/0x1d0 [tipc]
[   12.721459]  ? dst_alloc+0x4c/0xa0
[   12.722130]  udp_queue_rcv_skb+0x264/0x490
[   12.722924]  __udp4_lib_rcv+0x21e/0x990
[   12.723670]  ? ip_route_input_rcu+0x2dd/0xbf0
[   12.724442]  ? tcp_v4_rcv+0x958/0xa40
[   12.725039]  udp_rcv+0x1a/0x20
[   12.725587]  ip_local_deliver_finish+0x97/0x1d0
[   12.726323]  ip_local_deliver+0xaf/0xc0
[   12.726959]  ? ip_route_input_noref+0x19/0x20
[   12.727689]  ip_rcv_finish+0xdd/0x3b0
[   12.728307]  ip_rcv+0x2ac/0x360
[   12.728839]  __netif_receive_skb_core+0x6fb/0xa90
[   12.729580]  ? udp4_gro_receive+0x1a7/0x2c0
[   12.730274]  __netif_receive_skb+0x1d/0x60
[   12.730953]  ? __netif_receive_skb+0x1d/0x60
[   12.731637]  netif_receive_skb_internal+0x37/0xd0
[   12.732371]  napi_gro_receive+0xc7/0xf0
[   12.732920]  receive_buf+0x3c3/0xd40
[   12.733441]  virtnet_poll+0xb1/0x250
[   12.733944]  net_rx_action+0x23e/0x370
[   12.734476]  __do_softirq+0xc5/0x2f8
[   12.734922]  irq_exit+0xfa/0x100
[   12.735315]  do_IRQ+0x4f/0xd0
[   12.735680]  common_interrupt+0xa2/0xa2
[   12.736126]  
[   12.736416] RIP: 0010:native_safe_halt+0x6/0x10
[   12.736925] RSP: 0018:a41cc0cafe90 EFLAGS: 0246 ORIG_RAX: 
ff4d
[   12.737756] RAX:  RBX: 8c2a761edb80 RCX: 
[   12.738504] RDX:  RSI:  RDI: 
[   12.739258] RBP: a41cc0cafe90 R08: 014b5b9795e5 R09: a41cc12c7e88
[   12.740118] R10:  R11:  R12: 0002
[   12.740964] R13: 8c2a761edb80 R14:  R15: 
[   12.741831]  default_idle+0x2a/0x100
[   12.742323]  arch_cpu_idle+0xf/0x20
[   12.742796]  default_idle_call+0x28/0x40
[   12.743312]  do_idle+0x179/0x1f0
[   12.743761]  cpu_startup_entry+0x1d/0x20
[   12.744291]  start_secondary+0x112/0x120
[   12.744816]  secondary_startup_64+0xa5/0xa5
[   12.745367] Code: b9 f4 01 00 00 48 89 c2 48 c1 ea 02 48 3d d3 07 00
00 48 0f 47 d1 49 8b 0c 24 48 39 d1 76 07 49 89 14 24 48 89 d1 31 d2 48
89 df <48> f7 f1 89 c6 e8 81 6e ff ff 5b 41 5c 5d c3 66 90 66 2e 0f 1f
[   12.747527] RIP: tipc_node_calculate_timer.isra.12+0x45/0x60 [tipc] RSP: 
8c2a7fc838a0
[   12.748555] ---[ end trace 1399ab83390650fd ]---
[   12.749296] Kernel panic - not syncing: Fatal exception in interrupt
[   12.750123] Kernel Offset: 0x1320 from 0x8200
(relocation range: 0x8000-0xbfff)
[   12.751215] Rebooting in 60 seconds..

Fixes: c9b64d492b1f ("tipc: add replicast peer discovery")
Signed-off-by: Tommi Rantala <tommi.t.rant...@nokia.com>
---
 net/tipc/udp_media.c | 29 +++--
 1 file changed, 7 insertions(+), 22 deletions(-)

diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
index ecca64fc6a6f..599e7be92024 100644
--- a/net/tipc/udp_media.c
+++ b/net/tipc/ud

[PATCH] tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()

[Tommi Rantala]

Call tipc_rcv() only if bearer is up in tipc_udp_recv().
Fixes a rare TIPC div-by-zero crash in tipc_node_calculate_timer():

We're enabling a bearer, but it's not yet up and fully initialized.
At the same time we receive a discovery packet, and in tipc_udp_recv()
we end up calling tipc_rcv() with the not-yet-initialized bearer,
causing later a div-by-zero crash in tipc_node_calculate_timer().

[   12.590450] Own node address <1.1.1>, network identity 1
[   12.668088] divide error:  [#1] SMP
[   12.676952] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.14.2-dirty #1
[   12.679225] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-2.fc27 04/01/2014
[   12.682095] task: 8c2a761edb80 task.stack: a41cc0cac000
[   12.684087] RIP: 0010:tipc_node_calculate_timer.isra.12+0x45/0x60 [tipc]
[   12.686486] RSP: 0018:8c2a7fc838a0 EFLAGS: 00010246
[   12.688451] RAX:  RBX: 8c2a5b382600 RCX: 
[   12.691197] RDX:  RSI: 8c2a5b382600 RDI: 8c2a5b382600
[   12.693945] RBP: 8c2a7fc838b0 R08: 0001 R09: 0001
[   12.696632] R10:  R11:  R12: 8c2a5d8949d8
[   12.699491] R13: 95ede400 R14:  R15: 8c2a5d894800
[   12.702338] FS:  () GS:8c2a7fc8() 
knlGS:
[   12.705099] CS:  0010 DS:  ES:  CR0: 80050033
[   12.706776] CR2: 01bb9440 CR3: bd009001 CR4: 003606e0
[   12.708847] DR0:  DR1:  DR2: 
[   12.711016] DR3:  DR6: fffe0ff0 DR7: 0400
[   12.712627] Call Trace:
[   12.713390]  
[   12.714011]  tipc_node_check_dest+0x2e8/0x350 [tipc]
[   12.715286]  tipc_disc_rcv+0x14d/0x1d0 [tipc]
[   12.716370]  tipc_rcv+0x8b0/0xd40 [tipc]
[   12.717396]  ? minmax_running_min+0x2f/0x60
[   12.718248]  ? dst_alloc+0x4c/0xa0
[   12.718964]  ? tcp_ack+0xaf1/0x10b0
[   12.719658]  ? tipc_udp_is_known_peer+0xa0/0xa0 [tipc]
[   12.720634]  tipc_udp_recv+0x71/0x1d0 [tipc]
[   12.721459]  ? dst_alloc+0x4c/0xa0
[   12.722130]  udp_queue_rcv_skb+0x264/0x490
[   12.722924]  __udp4_lib_rcv+0x21e/0x990
[   12.723670]  ? ip_route_input_rcu+0x2dd/0xbf0
[   12.724442]  ? tcp_v4_rcv+0x958/0xa40
[   12.725039]  udp_rcv+0x1a/0x20
[   12.725587]  ip_local_deliver_finish+0x97/0x1d0
[   12.726323]  ip_local_deliver+0xaf/0xc0
[   12.726959]  ? ip_route_input_noref+0x19/0x20
[   12.727689]  ip_rcv_finish+0xdd/0x3b0
[   12.728307]  ip_rcv+0x2ac/0x360
[   12.728839]  __netif_receive_skb_core+0x6fb/0xa90
[   12.729580]  ? udp4_gro_receive+0x1a7/0x2c0
[   12.730274]  __netif_receive_skb+0x1d/0x60
[   12.730953]  ? __netif_receive_skb+0x1d/0x60
[   12.731637]  netif_receive_skb_internal+0x37/0xd0
[   12.732371]  napi_gro_receive+0xc7/0xf0
[   12.732920]  receive_buf+0x3c3/0xd40
[   12.733441]  virtnet_poll+0xb1/0x250
[   12.733944]  net_rx_action+0x23e/0x370
[   12.734476]  __do_softirq+0xc5/0x2f8
[   12.734922]  irq_exit+0xfa/0x100
[   12.735315]  do_IRQ+0x4f/0xd0
[   12.735680]  common_interrupt+0xa2/0xa2
[   12.736126]  
[   12.736416] RIP: 0010:native_safe_halt+0x6/0x10
[   12.736925] RSP: 0018:a41cc0cafe90 EFLAGS: 0246 ORIG_RAX: 
ff4d
[   12.737756] RAX:  RBX: 8c2a761edb80 RCX: 
[   12.738504] RDX:  RSI:  RDI: 
[   12.739258] RBP: a41cc0cafe90 R08: 014b5b9795e5 R09: a41cc12c7e88
[   12.740118] R10:  R11:  R12: 0002
[   12.740964] R13: 8c2a761edb80 R14:  R15: 
[   12.741831]  default_idle+0x2a/0x100
[   12.742323]  arch_cpu_idle+0xf/0x20
[   12.742796]  default_idle_call+0x28/0x40
[   12.743312]  do_idle+0x179/0x1f0
[   12.743761]  cpu_startup_entry+0x1d/0x20
[   12.744291]  start_secondary+0x112/0x120
[   12.744816]  secondary_startup_64+0xa5/0xa5
[   12.745367] Code: b9 f4 01 00 00 48 89 c2 48 c1 ea 02 48 3d d3 07 00
00 48 0f 47 d1 49 8b 0c 24 48 39 d1 76 07 49 89 14 24 48 89 d1 31 d2 48
89 df <48> f7 f1 89 c6 e8 81 6e ff ff 5b 41 5c 5d c3 66 90 66 2e 0f 1f
[   12.747527] RIP: tipc_node_calculate_timer.isra.12+0x45/0x60 [tipc] RSP: 
8c2a7fc838a0
[   12.748555] ---[ end trace 1399ab83390650fd ]---
[   12.749296] Kernel panic - not syncing: Fatal exception in interrupt
[   12.750123] Kernel Offset: 0x1320 from 0x8200
(relocation range: 0x8000-0xbfff)
[   12.751215] Rebooting in 60 seconds..

Fixes: c9b64d492b1f ("tipc: add replicast peer discovery")
Signed-off-by: Tommi Rantala 
---
 net/tipc/udp_media.c | 29 +++--
 1 file changed, 7 insertions(+), 22 deletions(-)

diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
index ecca64fc6a6f..599e7be92024 100644
--- a/net/tipc/udp_media.c
+++ b/net/tipc/udp_media.c
@@ -344,42 +344,27 @@ static in

tipc_node_calculate_timer div-by-zero

[Tommi Rantala]

Hi,

I'm seeing a rare TIPC div-by-zero crash in tipc_node_calculate_timer().

If I get it right, we're receiving a discovery packet while enabling a 
bearer. The bearer is not yet fully initialized, causing the discovery 
packet processing to use zero tolerance value, which then causes the 
div-by-zero in tipc_node_calculate_timer().


I can reproduce the issue easily by adding some sleep in 
tipc_enable_bearer(), and the machine always crashes after booting it up:


diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
index 47ec121574ce..00bdd87cd614 100644
--- a/net/tipc/bearer.c
+++ b/net/tipc/bearer.c
@@ -327,12 +327,16 @@ static int tipc_enable_bearer(struct net *net, 
const char *name,

return -EINVAL;
}

+   pr_warn("HACK: sleeping 2 seconds!");
+   usleep_range(200, 210);
+
b->identity = bearer_id;
b->tolerance = m->tolerance;
b->window = m->window;


In 4.14 removing the latter tipc_rcv() call in tipc_udp_recv() [which 
was added in in commit c9b64d492b1f (tipc: add replicast peer 
discovery)] seems to fix the crash, but I do not really understand the code:


diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
index ecca64fc6a6f..371653acf1f6 100644
--- a/net/tipc/udp_media.c
+++ b/net/tipc/udp_media.c
@@ -371,9 +371,11 @@ static int tipc_udp_recv(struct sock *sk, struct 
sk_buff *skb)

goto rcu_out;
}

+   /*
tipc_rcv(sock_net(sk), skb, b);
rcu_read_unlock();
return 0;
+   */

 rcu_out:
rcu_read_unlock();



I have tested 4.4 and 4.14, and the bug is reproducible in both versions.

Comments?

-Tommi



[   12.576885] tipc: Activated (version 2.0.0)
[   12.577506] NET: Registered protocol family 30
[   12.578212] tipc: Started in single node mode
[   12.589907] Started in network mode
[   12.590450] Own node address <1.1.1>, network identity 1
[   12.592022] HACK: sleeping 2 seconds!
[   12.668088] divide error:  [#1] SMP
[   12.670993] Modules linked in: tipc ip6_udp_tunnel udp_tunnel nfsd 
auth_rpcgss oid_registry nfs_acl nfs lockd grace sunrpc isofs 
aesni_intel aes_x86_64 crypto_simd cryptd glue_helper ata_piix 
sch_fq_codel autofs4
[   12.676952] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 
4.14.2-pc64-dirty #1
[   12.679225] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
BIOS 1.10.2-2.fc27 04/01/2014

[   12.682095] task: 8c2a761edb80 task.stack: a41cc0cac000
[   12.684087] RIP: 0010:tipc_node_calculate_timer.isra.12+0x45/0x60 [tipc]
[   12.686486] RSP: 0018:8c2a7fc838a0 EFLAGS: 00010246
[   12.688451] RAX:  RBX: 8c2a5b382600 RCX: 

[   12.691197] RDX:  RSI: 8c2a5b382600 RDI: 
8c2a5b382600
[   12.693945] RBP: 8c2a7fc838b0 R08: 0001 R09: 
0001
[   12.696632] R10:  R11:  R12: 
8c2a5d8949d8
[   12.699491] R13: 95ede400 R14:  R15: 
8c2a5d894800
[   12.702338] FS:  () GS:8c2a7fc8() 
knlGS:

[   12.705099] CS:  0010 DS:  ES:  CR0: 80050033
[   12.706776] CR2: 01bb9440 CR3: bd009001 CR4: 
003606e0
[   12.708847] DR0:  DR1:  DR2: 

[   12.711016] DR3:  DR6: fffe0ff0 DR7: 
0400

[   12.712627] Call Trace:
[   12.713390]  
[   12.714011]  tipc_node_check_dest+0x2e8/0x350 [tipc]
[   12.715286]  tipc_disc_rcv+0x14d/0x1d0 [tipc]
[   12.716370]  tipc_rcv+0x8b0/0xd40 [tipc]
[   12.717396]  ? minmax_running_min+0x2f/0x60
[   12.718248]  ? dst_alloc+0x4c/0xa0
[   12.718964]  ? tcp_ack+0xaf1/0x10b0
[   12.719658]  ? tipc_udp_is_known_peer+0xa0/0xa0 [tipc]
[   12.720634]  tipc_udp_recv+0x71/0x1d0 [tipc]
[   12.721459]  ? dst_alloc+0x4c/0xa0
[   12.722130]  udp_queue_rcv_skb+0x264/0x490
[   12.722924]  __udp4_lib_rcv+0x21e/0x990
[   12.723670]  ? ip_route_input_rcu+0x2dd/0xbf0
[   12.724442]  ? tcp_v4_rcv+0x958/0xa40
[   12.725039]  udp_rcv+0x1a/0x20
[   12.725587]  ip_local_deliver_finish+0x97/0x1d0
[   12.726323]  ip_local_deliver+0xaf/0xc0
[   12.726959]  ? ip_route_input_noref+0x19/0x20
[   12.727689]  ip_rcv_finish+0xdd/0x3b0
[   12.728307]  ip_rcv+0x2ac/0x360
[   12.728839]  __netif_receive_skb_core+0x6fb/0xa90
[   12.729580]  ? udp4_gro_receive+0x1a7/0x2c0
[   12.730274]  __netif_receive_skb+0x1d/0x60
[   12.730953]  ? __netif_receive_skb+0x1d/0x60
[   12.731637]  netif_receive_skb_internal+0x37/0xd0
[   12.732371]  napi_gro_receive+0xc7/0xf0
[   12.732920]  receive_buf+0x3c3/0xd40
[   12.733441]  virtnet_poll+0xb1/0x250
[   12.733944]  net_rx_action+0x23e/0x370
[   12.734476]  __do_softirq+0xc5/0x2f8
[   12.734922]  irq_exit+0xfa/0x100
[   12.735315]  do_IRQ+0x4f/0xd0
[   12.735680]  common_interrupt+0xa2/0xa2
[   12.736126]  
[   12.736416] RIP: 0010:native_safe_halt+0x6/0x10
[   12.736925] RSP: 0018:a41cc0cafe90 

tipc_node_calculate_timer div-by-zero

[Tommi Rantala]

Hi,

I'm seeing a rare TIPC div-by-zero crash in tipc_node_calculate_timer().

If I get it right, we're receiving a discovery packet while enabling a 
bearer. The bearer is not yet fully initialized, causing the discovery 
packet processing to use zero tolerance value, which then causes the 
div-by-zero in tipc_node_calculate_timer().


I can reproduce the issue easily by adding some sleep in 
tipc_enable_bearer(), and the machine always crashes after booting it up:


diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
index 47ec121574ce..00bdd87cd614 100644
--- a/net/tipc/bearer.c
+++ b/net/tipc/bearer.c
@@ -327,12 +327,16 @@ static int tipc_enable_bearer(struct net *net, 
const char *name,

return -EINVAL;
}

+   pr_warn("HACK: sleeping 2 seconds!");
+   usleep_range(200, 210);
+
b->identity = bearer_id;
b->tolerance = m->tolerance;
b->window = m->window;


In 4.14 removing the latter tipc_rcv() call in tipc_udp_recv() [which 
was added in in commit c9b64d492b1f (tipc: add replicast peer 
discovery)] seems to fix the crash, but I do not really understand the code:


diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
index ecca64fc6a6f..371653acf1f6 100644
--- a/net/tipc/udp_media.c
+++ b/net/tipc/udp_media.c
@@ -371,9 +371,11 @@ static int tipc_udp_recv(struct sock *sk, struct 
sk_buff *skb)

goto rcu_out;
}

+   /*
tipc_rcv(sock_net(sk), skb, b);
rcu_read_unlock();
return 0;
+   */

 rcu_out:
rcu_read_unlock();



I have tested 4.4 and 4.14, and the bug is reproducible in both versions.

Comments?

-Tommi



[   12.576885] tipc: Activated (version 2.0.0)
[   12.577506] NET: Registered protocol family 30
[   12.578212] tipc: Started in single node mode
[   12.589907] Started in network mode
[   12.590450] Own node address <1.1.1>, network identity 1
[   12.592022] HACK: sleeping 2 seconds!
[   12.668088] divide error:  [#1] SMP
[   12.670993] Modules linked in: tipc ip6_udp_tunnel udp_tunnel nfsd 
auth_rpcgss oid_registry nfs_acl nfs lockd grace sunrpc isofs 
aesni_intel aes_x86_64 crypto_simd cryptd glue_helper ata_piix 
sch_fq_codel autofs4
[   12.676952] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 
4.14.2-pc64-dirty #1
[   12.679225] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
BIOS 1.10.2-2.fc27 04/01/2014

[   12.682095] task: 8c2a761edb80 task.stack: a41cc0cac000
[   12.684087] RIP: 0010:tipc_node_calculate_timer.isra.12+0x45/0x60 [tipc]
[   12.686486] RSP: 0018:8c2a7fc838a0 EFLAGS: 00010246
[   12.688451] RAX:  RBX: 8c2a5b382600 RCX: 

[   12.691197] RDX:  RSI: 8c2a5b382600 RDI: 
8c2a5b382600
[   12.693945] RBP: 8c2a7fc838b0 R08: 0001 R09: 
0001
[   12.696632] R10:  R11:  R12: 
8c2a5d8949d8
[   12.699491] R13: 95ede400 R14:  R15: 
8c2a5d894800
[   12.702338] FS:  () GS:8c2a7fc8() 
knlGS:

[   12.705099] CS:  0010 DS:  ES:  CR0: 80050033
[   12.706776] CR2: 01bb9440 CR3: bd009001 CR4: 
003606e0
[   12.708847] DR0:  DR1:  DR2: 

[   12.711016] DR3:  DR6: fffe0ff0 DR7: 
0400

[   12.712627] Call Trace:
[   12.713390]  
[   12.714011]  tipc_node_check_dest+0x2e8/0x350 [tipc]
[   12.715286]  tipc_disc_rcv+0x14d/0x1d0 [tipc]
[   12.716370]  tipc_rcv+0x8b0/0xd40 [tipc]
[   12.717396]  ? minmax_running_min+0x2f/0x60
[   12.718248]  ? dst_alloc+0x4c/0xa0
[   12.718964]  ? tcp_ack+0xaf1/0x10b0
[   12.719658]  ? tipc_udp_is_known_peer+0xa0/0xa0 [tipc]
[   12.720634]  tipc_udp_recv+0x71/0x1d0 [tipc]
[   12.721459]  ? dst_alloc+0x4c/0xa0
[   12.722130]  udp_queue_rcv_skb+0x264/0x490
[   12.722924]  __udp4_lib_rcv+0x21e/0x990
[   12.723670]  ? ip_route_input_rcu+0x2dd/0xbf0
[   12.724442]  ? tcp_v4_rcv+0x958/0xa40
[   12.725039]  udp_rcv+0x1a/0x20
[   12.725587]  ip_local_deliver_finish+0x97/0x1d0
[   12.726323]  ip_local_deliver+0xaf/0xc0
[   12.726959]  ? ip_route_input_noref+0x19/0x20
[   12.727689]  ip_rcv_finish+0xdd/0x3b0
[   12.728307]  ip_rcv+0x2ac/0x360
[   12.728839]  __netif_receive_skb_core+0x6fb/0xa90
[   12.729580]  ? udp4_gro_receive+0x1a7/0x2c0
[   12.730274]  __netif_receive_skb+0x1d/0x60
[   12.730953]  ? __netif_receive_skb+0x1d/0x60
[   12.731637]  netif_receive_skb_internal+0x37/0xd0
[   12.732371]  napi_gro_receive+0xc7/0xf0
[   12.732920]  receive_buf+0x3c3/0xd40
[   12.733441]  virtnet_poll+0xb1/0x250
[   12.733944]  net_rx_action+0x23e/0x370
[   12.734476]  __do_softirq+0xc5/0x2f8
[   12.734922]  irq_exit+0xfa/0x100
[   12.735315]  do_IRQ+0x4f/0xd0
[   12.735680]  common_interrupt+0xa2/0xa2
[   12.736126]  
[   12.736416] RIP: 0010:native_safe_halt+0x6/0x10
[   12.736925] RSP: 0018:a41cc0cafe90 

Re: tipc_udp_send_msg oops in 4.4 when setting link tolerance

[Tommi Rantala]

On 14.11.2017 13:35, Jon Maloy wrote:

Found it, the missing patch is this one (9b3009604b8e does not help):

commit d01332f1acacc0cb43a61f4244dd2b846d4cd585
Author: Richard Alpe 
Date:   Mon Feb 1 08:19:56 2016 +0100

  tipc: fix link attribute propagation bug


It does not apply as-is to 4.4, so backported it, see below.
Does it look good? I can send it forward to Greg for inclusion in 4.4.


Yes. I would be very grateful if you do.


OK, sent the patch to sta...@vger.kernel.org


But with this patch included, I can easily reproduce the "BUG: Bad page state
in process git" issue also in 4.4 like this:

$ tipc link set tolerance 100 link $LINKNAME $ cd /tmp && git clone
/path/to/linux-stable

I can try to debug that a bit more to see if I can figure it out.


I would appreciate that. If this turns out to also be an already fixed bug 
(most likely) you can send that directly to GKH too.
If you find a bug that requires a new patch send it to tipc-discussion for 
review first.

Finally, I want to say that I very much appreciate users like you, who try 
solving the problems themselves and contribute to the code.
We are right now in an upgrade phase of TIPC, where we have been/are adding new 
features to TIPC (overlapping ring neighbor monitoring, group communication, 
new addressing model, performance improvements...) which inevitably entail some 
new bugs, but I expect the frequency of these changes/improvements to TIPC go 
down in a few months, and with that the number of fixes needed.


Thanks!

After more testing, I noticed that I could only reproduce the "BUG: Bad 
page state" in a single machine, so maybe something wrong with the 
machine, and not with tipc.


-Tommi

Re: tipc_udp_send_msg oops in 4.4 when setting link tolerance

[Tommi Rantala]

On 14.11.2017 13:35, Jon Maloy wrote:

Found it, the missing patch is this one (9b3009604b8e does not help):

commit d01332f1acacc0cb43a61f4244dd2b846d4cd585
Author: Richard Alpe 
Date:   Mon Feb 1 08:19:56 2016 +0100

  tipc: fix link attribute propagation bug


It does not apply as-is to 4.4, so backported it, see below.
Does it look good? I can send it forward to Greg for inclusion in 4.4.


Yes. I would be very grateful if you do.


OK, sent the patch to sta...@vger.kernel.org


But with this patch included, I can easily reproduce the "BUG: Bad page state
in process git" issue also in 4.4 like this:

$ tipc link set tolerance 100 link $LINKNAME $ cd /tmp && git clone
/path/to/linux-stable

I can try to debug that a bit more to see if I can figure it out.


I would appreciate that. If this turns out to also be an already fixed bug 
(most likely) you can send that directly to GKH too.
If you find a bug that requires a new patch send it to tipc-discussion for 
review first.

Finally, I want to say that I very much appreciate users like you, who try 
solving the problems themselves and contribute to the code.
We are right now in an upgrade phase of TIPC, where we have been/are adding new 
features to TIPC (overlapping ring neighbor monitoring, group communication, 
new addressing model, performance improvements...) which inevitably entail some 
new bugs, but I expect the frequency of these changes/improvements to TIPC go 
down in a few months, and with that the number of fixes needed.


Thanks!

After more testing, I noticed that I could only reproduce the "BUG: Bad 
page state" in a single machine, so maybe something wrong with the 
machine, and not with tipc.


-Tommi

Re: tipc_udp_send_msg oops in 4.4 when setting link tolerance

[Tommi Rantala]

On 13.11.2017 23:25, Jon Maloy wrote:
> Hi Tommi,
> I am not sure, but is seems like the following patch is what you need:
> commit 9b3009604b8e ("tipc: add net device to skb before UDP xmit")
> This was applied in tipc 4.5.

Found it, the missing patch is this one (9b3009604b8e does not help):

commit d01332f1acacc0cb43a61f4244dd2b846d4cd585
Author: Richard Alpe <richard.a...@ericsson.com>
Date:   Mon Feb 1 08:19:56 2016 +0100

tipc: fix link attribute propagation bug


It does not apply as-is to 4.4, so backported it, see below.
Does it look good? I can send it forward to Greg for inclusion in 4.4.


But with this patch included, I can easily reproduce the "BUG: Bad page 
state in process git" issue also in 4.4 like this:


$ tipc link set tolerance 100 link $LINKNAME
$ cd /tmp && git clone /path/to/linux-stable

I can try to debug that a bit more to see if I can figure it out.

-Tommi



From e1857e6c60355296fd1cbe6e376d8a7265c2b289 Mon Sep 17 00:00:00 2001
From: Richard Alpe <richard.a...@ericsson.com>
Date: Tue, 14 Nov 2017 11:09:50 +0200
Subject: [PATCH] tipc: fix link attribute propagation bug

commit d01332f1acacc0cb43a61f4244dd2b846d4cd585 upstream.

[backported to 4.4 by Tommi Rantala]

Changing certain link attributes (link tolerance and link priority)
from the TIPC management tool is supposed to automatically take
effect at both endpoints of the affected link.

Currently the media address is not instantiated for the link and is
used uninstantiated when crafting protocol messages designated for the
peer endpoint. This means that changing a link property currently
results in the property being changed on the local machine but the
protocol message designated for the peer gets lost. Resulting in
property discrepancy between the endpoints.

In this patch we resolve this by using the media address from the
link entry and using the bearer transmit function to send it. Hence,
we can now eliminate the redundant function tipc_link_prot_xmit() and
the redundant field tipc_link::media_addr.

Fixes: 2af5ae372a4b (tipc: clean up unused code and structures)
Reviewed-by: Jon Maloy <jon.ma...@ericsson.com>
Reported-by: Jason Hu <huzhiji...@gmail.com>
Signed-off-by: Richard Alpe <richard.a...@ericsson.com>
Signed-off-by: David S. Miller <da...@davemloft.net>
Signed-off-by: Tommi Rantala <tommi.t.rant...@nokia.com>
---
 net/tipc/link.c | 28 ++--
 net/tipc/link.h |  1 - 

 2 files changed, 6 insertions(+), 23 deletions(-) 




diff --git a/net/tipc/link.c b/net/tipc/link.c 

index 72268eac4ec7..736fffb28ab6 100644 

--- a/net/tipc/link.c 

+++ b/net/tipc/link.c 

@@ -1084,25 +1084,6 @@ drop: 

return rc; 

 } 




-/* 

- * Send protocol message to the other endpoint. 

- */ 

-void tipc_link_proto_xmit(struct tipc_link *l, u32 msg_typ, int 
probe_msg,
- u32 gap, u32 tolerance, u32 priority) 

-{ 

-   struct sk_buff *skb = NULL; 

-   struct sk_buff_head xmitq; 

- 

-   __skb_queue_head_init(); 

-   tipc_link_build_proto_msg(l, msg_typ, probe_msg, gap, 

- tolerance, priority, ); 

-   skb = __skb_dequeue(); 

-   if (!skb) 

-   return; 

-   tipc_bearer_xmit_skb(l->net, l->bearer_id, skb, l->media_addr); 

-   l->rcv_unacked = 0; 

-} 

- 

 static void tipc_link_build_proto_msg(struct tipc_link *l, int mtyp, 
bool probe,
  u16 rcvgap, int tolerance, int 
priority,
  struct sk_buff_head *xmitq) 

@@ -1636,9 +1617,12 @@ int tipc_nl_link_set(struct sk_buff *skb, struct 
genl_info *info)
char *name; 


struct tipc_link *link;
struct tipc_node *node;
+   struct sk_buff_head xmitq;
struct nlattr *attrs[TIPC_NLA_LINK_MAX + 1];
struct net *net = sock_net(skb->sk);

+   __skb_queue_head_init();
+
if (!info->attrs[TIPC_NLA_LINK])
return -EINVAL;

@@ -1683,14 +1667,14 @@ int tipc_nl_link_set(struct sk_buff *skb, struct 
genl_info *info)


tol = nla_get_u32(props[TIPC_NLA_PROP_TOL]);
link->tolerance = tol;
-   tipc_link_proto_xmit(link, STATE_MSG, 0, 0, tol, 0);
+   tipc_link_build_proto_msg(link, STATE_MSG, 0, 0, 
tol, 0, );

}
if (props[TIPC_NLA_PROP_PRIO]) {
u32 prio;

prio = nla_get_u32(props[TIPC_NLA_PROP_PRIO]);
link->priority = prio;
-   tipc_link_proto_xmit(link, STATE_MSG, 0, 0, 0, 
prio);
+   tipc_link_build_proto_msg(link, STATE_MSG, 0, 0, 
0, prio, );

}
if (props[TIPC_NLA_PROP_WIN]) {
u32 win;
@@ -1702,7 +1686,7 @@ int tipc_nl_link_set(struct

Re: tipc_udp_send_msg oops in 4.4 when setting link tolerance

[Tommi Rantala]

On 13.11.2017 23:25, Jon Maloy wrote:
> Hi Tommi,
> I am not sure, but is seems like the following patch is what you need:
> commit 9b3009604b8e ("tipc: add net device to skb before UDP xmit")
> This was applied in tipc 4.5.

Found it, the missing patch is this one (9b3009604b8e does not help):

commit d01332f1acacc0cb43a61f4244dd2b846d4cd585
Author: Richard Alpe 
Date:   Mon Feb 1 08:19:56 2016 +0100

tipc: fix link attribute propagation bug


It does not apply as-is to 4.4, so backported it, see below.
Does it look good? I can send it forward to Greg for inclusion in 4.4.


But with this patch included, I can easily reproduce the "BUG: Bad page 
state in process git" issue also in 4.4 like this:


$ tipc link set tolerance 100 link $LINKNAME
$ cd /tmp && git clone /path/to/linux-stable

I can try to debug that a bit more to see if I can figure it out.

-Tommi



From e1857e6c60355296fd1cbe6e376d8a7265c2b289 Mon Sep 17 00:00:00 2001
From: Richard Alpe 
Date: Tue, 14 Nov 2017 11:09:50 +0200
Subject: [PATCH] tipc: fix link attribute propagation bug

commit d01332f1acacc0cb43a61f4244dd2b846d4cd585 upstream.

[backported to 4.4 by Tommi Rantala]

Changing certain link attributes (link tolerance and link priority)
from the TIPC management tool is supposed to automatically take
effect at both endpoints of the affected link.

Currently the media address is not instantiated for the link and is
used uninstantiated when crafting protocol messages designated for the
peer endpoint. This means that changing a link property currently
results in the property being changed on the local machine but the
protocol message designated for the peer gets lost. Resulting in
property discrepancy between the endpoints.

In this patch we resolve this by using the media address from the
link entry and using the bearer transmit function to send it. Hence,
we can now eliminate the redundant function tipc_link_prot_xmit() and
the redundant field tipc_link::media_addr.

Fixes: 2af5ae372a4b (tipc: clean up unused code and structures)
Reviewed-by: Jon Maloy 
Reported-by: Jason Hu 
Signed-off-by: Richard Alpe 
Signed-off-by: David S. Miller 
Signed-off-by: Tommi Rantala 
---
 net/tipc/link.c | 28 ++--
 net/tipc/link.h |  1 - 

 2 files changed, 6 insertions(+), 23 deletions(-) 




diff --git a/net/tipc/link.c b/net/tipc/link.c 

index 72268eac4ec7..736fffb28ab6 100644 

--- a/net/tipc/link.c 

+++ b/net/tipc/link.c 

@@ -1084,25 +1084,6 @@ drop: 

return rc; 

 } 




-/* 

- * Send protocol message to the other endpoint. 

- */ 

-void tipc_link_proto_xmit(struct tipc_link *l, u32 msg_typ, int 
probe_msg,
- u32 gap, u32 tolerance, u32 priority) 

-{ 

-   struct sk_buff *skb = NULL; 

-   struct sk_buff_head xmitq; 

- 

-   __skb_queue_head_init(); 

-   tipc_link_build_proto_msg(l, msg_typ, probe_msg, gap, 

- tolerance, priority, ); 

-   skb = __skb_dequeue(); 

-   if (!skb) 

-   return; 

-   tipc_bearer_xmit_skb(l->net, l->bearer_id, skb, l->media_addr); 

-   l->rcv_unacked = 0; 

-} 

- 

 static void tipc_link_build_proto_msg(struct tipc_link *l, int mtyp, 
bool probe,
  u16 rcvgap, int tolerance, int 
priority,
  struct sk_buff_head *xmitq) 

@@ -1636,9 +1617,12 @@ int tipc_nl_link_set(struct sk_buff *skb, struct 
genl_info *info)
char *name; 


struct tipc_link *link;
struct tipc_node *node;
+   struct sk_buff_head xmitq;
struct nlattr *attrs[TIPC_NLA_LINK_MAX + 1];
struct net *net = sock_net(skb->sk);

+   __skb_queue_head_init();
+
if (!info->attrs[TIPC_NLA_LINK])
return -EINVAL;

@@ -1683,14 +1667,14 @@ int tipc_nl_link_set(struct sk_buff *skb, struct 
genl_info *info)


tol = nla_get_u32(props[TIPC_NLA_PROP_TOL]);
link->tolerance = tol;
-   tipc_link_proto_xmit(link, STATE_MSG, 0, 0, tol, 0);
+   tipc_link_build_proto_msg(link, STATE_MSG, 0, 0, 
tol, 0, );

}
if (props[TIPC_NLA_PROP_PRIO]) {
u32 prio;

prio = nla_get_u32(props[TIPC_NLA_PROP_PRIO]);
link->priority = prio;
-   tipc_link_proto_xmit(link, STATE_MSG, 0, 0, 0, 
prio);
+   tipc_link_build_proto_msg(link, STATE_MSG, 0, 0, 
0, prio, );

}
if (props[TIPC_NLA_PROP_WIN]) {
u32 win;
@@ -1702,7 +1686,7 @@ int tipc_nl_link_set(struct sk_buff *skb, struct 
genl_info *info)


 out:
tipc_node_unlock(node);
-
+   tipc_bearer_xmit(net, bearer_id, , 
>links[bearer_id].maddr);

return res;
 }

diff --git a/net/tipc/link.h b/net

tipc_udp_send_msg oops in 4.4 when setting link tolerance

[Tommi Rantala]

Hi,

I always get an instant TIPC oops in 4.4, when I try to set the link 
tolerance (with LINKNAME != "broadcast-link"):


 $ tipc link set tolerance 1000 link $LINKNAME

Any idea what's going on? Some tipc patch missing in 4.4?

In 4.9 the "tipc" command executes just fine, but I've seen a few times 
that later some random process crashes with "BUG: Bad page state". KASAN 
does not report anything before it happens.


4.14 is OK, could not reproduce these problems with it.




tipc_udp_send_msg+0x102/0x4f0

matches to:
tipc_udp_send_msg at linux-stable/net/tipc/udp_media.c:172

static int tipc_udp_send_msg(struct net *net, struct sk_buff *skb,
 struct tipc_bearer *b,
 struct tipc_media_addr *dest)
{
int ttl, err = 0;
struct udp_bearer *ub;
struct udp_media_addr *dst = (struct udp_media_addr *)>value;
struct udp_media_addr *src = (struct udp_media_addr 
*)>addr.value;

struct rtable *rt;

if (skb_headroom(skb) < UDP_MIN_HEADROOM) {
err = pskb_expand_head(skb, UDP_MIN_HEADROOM, 0, 
GFP_ATOMIC);

if (err)
goto tx_error;
}

skb_set_inner_protocol(skb, htons(ETH_P_TIPC));
ub = rcu_dereference_rtnl(b->media_ptr);
if (!ub) {
err = -ENODEV;
goto tx_error;
}
if (dst->proto == htons(ETH_P_IP)) {   <-- HERE



[  111.423647] 
==

[  111.424826] BUG: KASAN: null-ptr-deref on address   (null)
[  111.425538] Read of size 2 by task tipc/2643
[  111.426215] CPU: 3 PID: 2643 Comm: tipc Not tainted 4.4.97-pc64 #1
[  111.428081]   880026327478 8248005e 
0002
[  111.429476]  880047ad5ac0 8800263274f8 8227f5af 
000265711040
[  111.430728]   0297 a0387fd2 
02090220

[  111.432051] Call Trace:
[  111.432472]  [] dump_stack+0x86/0xc8
[  111.433208]  [] kasan_report.part.2+0x41f/0x520
[  111.434040]  [] ? tipc_udp_send_msg+0x102/0x4f0 [tipc]
[  111.434908]  [] kasan_report+0x25/0x30
[  111.435647]  [] __asan_load2+0x66/0x70
[  111.436391]  [] tipc_udp_send_msg+0x102/0x4f0 [tipc]
[  111.437334]  [] ? kasan_kmalloc+0x5e/0x70
[  111.438301]  [] ? kasan_slab_alloc+0xd/0x10
[  111.439328]  [] ? 
__kmalloc_node_track_caller+0xac/0x230

[  111.440493]  [] ? kasan_kmalloc+0x5e/0x70
[  111.441479]  [] ? tipc_udp_disable+0xe0/0xe0 [tipc]
[  111.442628]  [] ? kasan_kmalloc+0x5e/0x70
[  111.443598]  [] ? kasan_krealloc+0x62/0x80
[  111.444610]  [] ? memset+0x28/0x30
[  111.445539]  [] ? __alloc_skb+0x2b3/0x310
[  111.446560]  [] ? skb_complete_tx_timestamp+0x110/0x110
[  111.447695]  [] ? __module_text_address+0x16/0xa0
[  111.448735]  [] ? skb_put+0x8b/0xd0
[  111.449608]  [] ? memcpy+0x36/0x40
[  111.450524]  [] ? 
tipc_link_build_proto_msg+0x398/0x4c0 [tipc]

[  111.451946]  [] tipc_bearer_xmit_skb+0xa0/0xb0 [tipc]
[  111.453078]  [] tipc_link_proto_xmit+0x11b/0x160 [tipc]
[  111.454218]  [] ? 
tipc_link_build_reset_msg+0x50/0x50 [tipc]

[  111.455542]  [] tipc_nl_link_set+0x1ee/0x3b0 [tipc]
[  111.456659]  [] ? tipc_nl_parse_link_prop+0xd0/0xd0 
[tipc]

[  111.457831]  [] ? is_ftrace_trampoline+0x59/0x90
[  111.458884]  [] ? __kernel_text_address+0x65/0x80
[  111.459931]  [] ? nla_parse+0xb6/0x140
[  111.460892]  [] genl_family_rcv_msg+0x37e/0x5e0
[  111.461948]  [] ? set_orig_addr.isra.53+0xe5/0x120 
[tipc]

[  111.463107]  [] ? genl_rcv+0x40/0x40
[  111.463987]  [] ? alloc_debug_processing+0x154/0x180
[  111.465048]  [] ? ___slab_alloc+0x43d/0x460
[  111.465986]  [] ? alloc_debug_processing+0x154/0x180
[  111.467045]  [] ? netlink_lookup+0x19c/0x220
[  111.468067]  [] genl_rcv_msg+0xd8/0x110
[  111.468994]  [] netlink_rcv_skb+0x14b/0x180
[  111.469939]  [] ? genl_family_rcv_msg+0x5e0/0x5e0
[  111.470954]  [] genl_rcv+0x28/0x40
[  111.471798]  [] netlink_unicast+0x2e7/0x3a0
[  111.472806]  [] ? netlink_attachskb+0x330/0x330
[  111.473845]  [] ? copy_from_iter+0xf1/0x3b0
[  111.474847]  [] netlink_sendmsg+0x4ad/0x620
[  111.475788]  [] ? netlink_unicast+0x3a0/0x3a0
[  111.476793]  [] ? __fdget+0x13/0x20
[  111.477723]  [] ? sockfd_lookup_light+0x95/0xb0
[  111.478773]  [] SYSC_sendto+0x1bc/0x290
[  111.479659]  [] ? sock_write_iter+0x200/0x200
[  111.480692]  [] ? __fdget+0x13/0x20
[  111.481559]  [] ? sockfd_lookup_light+0x95/0xb0
[  111.482591]  [] ? netlink_getname+0xb1/0x110
[  111.483570]  [] ? move_addr_to_user+0x5c/0x70
[  111.484539]  [] ? SYSC_getsockname+0x176/0x190
[  111.485540]  [] ? sockfd_lookup_light+0xb0/0xb0
[  111.486558]  [] ? SYSC_bind+0xe5/0x180
[  111.487548]  [] ? __sock_recv_ts_and_drops+0x260/0x260
[  111.488700]  [] ? fd_install+0x3b/0x50
[  111.489596]  [] ? sock_map_fd+0x44/0x70
[  111.490553]  [] ? SyS_socket+0xcc/0x120
[  111.491437]  [] ? move_addr_to_kernel+0x40/0x40
[  111.492505]  [] ? 

tipc_udp_send_msg oops in 4.4 when setting link tolerance

[Tommi Rantala]

Hi,

I always get an instant TIPC oops in 4.4, when I try to set the link 
tolerance (with LINKNAME != "broadcast-link"):


 $ tipc link set tolerance 1000 link $LINKNAME

Any idea what's going on? Some tipc patch missing in 4.4?

In 4.9 the "tipc" command executes just fine, but I've seen a few times 
that later some random process crashes with "BUG: Bad page state". KASAN 
does not report anything before it happens.


4.14 is OK, could not reproduce these problems with it.




tipc_udp_send_msg+0x102/0x4f0

matches to:
tipc_udp_send_msg at linux-stable/net/tipc/udp_media.c:172

static int tipc_udp_send_msg(struct net *net, struct sk_buff *skb,
 struct tipc_bearer *b,
 struct tipc_media_addr *dest)
{
int ttl, err = 0;
struct udp_bearer *ub;
struct udp_media_addr *dst = (struct udp_media_addr *)>value;
struct udp_media_addr *src = (struct udp_media_addr 
*)>addr.value;

struct rtable *rt;

if (skb_headroom(skb) < UDP_MIN_HEADROOM) {
err = pskb_expand_head(skb, UDP_MIN_HEADROOM, 0, 
GFP_ATOMIC);

if (err)
goto tx_error;
}

skb_set_inner_protocol(skb, htons(ETH_P_TIPC));
ub = rcu_dereference_rtnl(b->media_ptr);
if (!ub) {
err = -ENODEV;
goto tx_error;
}
if (dst->proto == htons(ETH_P_IP)) {   <-- HERE



[  111.423647] 
==

[  111.424826] BUG: KASAN: null-ptr-deref on address   (null)
[  111.425538] Read of size 2 by task tipc/2643
[  111.426215] CPU: 3 PID: 2643 Comm: tipc Not tainted 4.4.97-pc64 #1
[  111.428081]   880026327478 8248005e 
0002
[  111.429476]  880047ad5ac0 8800263274f8 8227f5af 
000265711040
[  111.430728]   0297 a0387fd2 
02090220

[  111.432051] Call Trace:
[  111.432472]  [] dump_stack+0x86/0xc8
[  111.433208]  [] kasan_report.part.2+0x41f/0x520
[  111.434040]  [] ? tipc_udp_send_msg+0x102/0x4f0 [tipc]
[  111.434908]  [] kasan_report+0x25/0x30
[  111.435647]  [] __asan_load2+0x66/0x70
[  111.436391]  [] tipc_udp_send_msg+0x102/0x4f0 [tipc]
[  111.437334]  [] ? kasan_kmalloc+0x5e/0x70
[  111.438301]  [] ? kasan_slab_alloc+0xd/0x10
[  111.439328]  [] ? 
__kmalloc_node_track_caller+0xac/0x230

[  111.440493]  [] ? kasan_kmalloc+0x5e/0x70
[  111.441479]  [] ? tipc_udp_disable+0xe0/0xe0 [tipc]
[  111.442628]  [] ? kasan_kmalloc+0x5e/0x70
[  111.443598]  [] ? kasan_krealloc+0x62/0x80
[  111.444610]  [] ? memset+0x28/0x30
[  111.445539]  [] ? __alloc_skb+0x2b3/0x310
[  111.446560]  [] ? skb_complete_tx_timestamp+0x110/0x110
[  111.447695]  [] ? __module_text_address+0x16/0xa0
[  111.448735]  [] ? skb_put+0x8b/0xd0
[  111.449608]  [] ? memcpy+0x36/0x40
[  111.450524]  [] ? 
tipc_link_build_proto_msg+0x398/0x4c0 [tipc]

[  111.451946]  [] tipc_bearer_xmit_skb+0xa0/0xb0 [tipc]
[  111.453078]  [] tipc_link_proto_xmit+0x11b/0x160 [tipc]
[  111.454218]  [] ? 
tipc_link_build_reset_msg+0x50/0x50 [tipc]

[  111.455542]  [] tipc_nl_link_set+0x1ee/0x3b0 [tipc]
[  111.456659]  [] ? tipc_nl_parse_link_prop+0xd0/0xd0 
[tipc]

[  111.457831]  [] ? is_ftrace_trampoline+0x59/0x90
[  111.458884]  [] ? __kernel_text_address+0x65/0x80
[  111.459931]  [] ? nla_parse+0xb6/0x140
[  111.460892]  [] genl_family_rcv_msg+0x37e/0x5e0
[  111.461948]  [] ? set_orig_addr.isra.53+0xe5/0x120 
[tipc]

[  111.463107]  [] ? genl_rcv+0x40/0x40
[  111.463987]  [] ? alloc_debug_processing+0x154/0x180
[  111.465048]  [] ? ___slab_alloc+0x43d/0x460
[  111.465986]  [] ? alloc_debug_processing+0x154/0x180
[  111.467045]  [] ? netlink_lookup+0x19c/0x220
[  111.468067]  [] genl_rcv_msg+0xd8/0x110
[  111.468994]  [] netlink_rcv_skb+0x14b/0x180
[  111.469939]  [] ? genl_family_rcv_msg+0x5e0/0x5e0
[  111.470954]  [] genl_rcv+0x28/0x40
[  111.471798]  [] netlink_unicast+0x2e7/0x3a0
[  111.472806]  [] ? netlink_attachskb+0x330/0x330
[  111.473845]  [] ? copy_from_iter+0xf1/0x3b0
[  111.474847]  [] netlink_sendmsg+0x4ad/0x620
[  111.475788]  [] ? netlink_unicast+0x3a0/0x3a0
[  111.476793]  [] ? __fdget+0x13/0x20
[  111.477723]  [] ? sockfd_lookup_light+0x95/0xb0
[  111.478773]  [] SYSC_sendto+0x1bc/0x290
[  111.479659]  [] ? sock_write_iter+0x200/0x200
[  111.480692]  [] ? __fdget+0x13/0x20
[  111.481559]  [] ? sockfd_lookup_light+0x95/0xb0
[  111.482591]  [] ? netlink_getname+0xb1/0x110
[  111.483570]  [] ? move_addr_to_user+0x5c/0x70
[  111.484539]  [] ? SYSC_getsockname+0x176/0x190
[  111.485540]  [] ? sockfd_lookup_light+0xb0/0xb0
[  111.486558]  [] ? SYSC_bind+0xe5/0x180
[  111.487548]  [] ? __sock_recv_ts_and_drops+0x260/0x260
[  111.488700]  [] ? fd_install+0x3b/0x50
[  111.489596]  [] ? sock_map_fd+0x44/0x70
[  111.490553]  [] ? SyS_socket+0xcc/0x120
[  111.491437]  [] ? move_addr_to_kernel+0x40/0x40
[  111.492505]  [] ? 

4.9.30 NULL pointer dereference in __remove_shared_vm_struct

[Tommi Rantala]

Hi,

I have hit this kernel bug twice with 4.9.30 while running trinity, any 
ideas? It's not easily reproducible.


Perhaps I should enable some more debug options to see if they reveal 
anything...


(note that I had different kernel builds, so the IP addresses are 
different in the logs below)



$ scripts/faddr2line vmlinux __remove_shared_vm_struct+0x16/0x40
__remove_shared_vm_struct+0x16/0x40:
atomic_inc at arch/x86/include/asm/atomic.h:91
 (inlined by) __remove_shared_vm_struct at mm/mmap.c:137


(gdb) disassemble __remove_shared_vm_struct
Dump of assembler code for function __remove_shared_vm_struct:
   0x8218e7a0 <+0>: callq  0x825db650 <__fentry__>
   0x8218e7a5 <+5>: mov0x50(%rdi),%rax
   0x8218e7a9 <+9>: push   %rbp
   0x8218e7aa <+10>:mov%rsp,%rbp
   0x8218e7ad <+13>:test   $0x8,%ah
   0x8218e7b0 <+16>:je 0x8218e7c1 
<__remove_shared_vm_struct+33>

   0x8218e7b2 <+18>:mov0x20(%rsi),%rax
   0x8218e7b6 <+22>:lock incl 0x158(%rax)
   0x8218e7bd <+29>:mov0x50(%rdi),%rax
   0x8218e7c1 <+33>:test   $0x8,%al
   0x8218e7c3 <+35>:je 0x8218e7c9 
<__remove_shared_vm_struct+41>

   0x8218e7c5 <+37>:lock decl 0x1c(%rdx)
   0x8218e7c9 <+41>:lea0x20(%rdx),%rsi
   0x8218e7cd <+45>:callq  0x82183460 


   0x8218e7d2 <+50>:pop%rbp
   0x8218e7d3 <+51>:retq




[16076.230255] BUG: unable to handle kernel NULL pointer dereference at 
0158

[16076.231566] IP: [] __remove_shared_vm_struct+0x16/0x40
[16076.232533] PGD 0
[16076.233125] Oops: 0002 [#1] SMP
[16076.233631] Modules linked in: fuse tun bridge hmac 8021q garp stp 
llc2 af_key llc rds xfrm_user xfrm_algo nfnetlink dccp_ipv6 sctp 
libcrc32c dccp_ipv4 dccp iptable_filter ip_tables x_tables isofs 
ata_piix autofs4

[16076.236688] CPU: 10 PID: 10753 Comm: trinity-main Not tainted 4.9.30 #1
[16076.238917] task: 880285b58000 task.stack: c90108d4c000
[16076.239741] RIP: 0010:[]  [] 
__remove_shared_vm_struct+0x16/0x40

[16076.241085] RSP: 0018:c90108d4fd38  EFLAGS: 00010202
[16076.241841] RAX:  RBX: 8801568867e8 RCX: 

[16076.242807] RDX: 88032c7581d8 RSI: 88012af34a00 RDI: 
8801568867e8
[16076.243773] RBP: c90108d4fd38 R08: 880156886b80 R09: 
7fffcf5d4000
[16076.244737] R10:  R11: 0001 R12: 
88012af34a00
[16076.245698] R13: 88032c758200 R14: 88032c7581d8 R15: 
8801568868a0
[16076.246659] FS:  () GS:88033348() 
knlGS:

[16076.247864] CS:  0010 DS:  ES:  CR0: 80050033
[16076.248667] CR2: 0158 CR3: 00c07000 CR4: 
06e0
[16076.249634] DR0: 7f54c4cae000 DR1: 7ff1276c9000 DR2: 

[16076.250599] DR3:  DR6: fffe0ff0 DR7: 
0600

[16076.251563] Stack:
[16076.251942]  c90108d4fd68 8038ef91 8801568867e8 
0040
[16076.253139]   c90108d4fdc0 c90108d4fda8 
80387893
[16076.254335]    8801d1126c00 


[16076.255528] Call Trace:
[16076.255959]  [] unlink_file_vma+0x41/0x60
[16076.256746]  [] free_pgtables+0x43/0x120
[16076.257520]  [] exit_mmap+0xb2/0x150
[16076.258258]  [] mmput+0x3b/0x100
[16076.258953]  [] do_exit+0x255/0xb20
[16076.259673]  [] ? syscall_trace_enter+0x1c1/0x2d0
[16076.260538]  [] do_group_exit+0x43/0xb0
[16076.261303]  [] SyS_exit_group+0x14/0x20
[16076.262078]  [] do_syscall_64+0x7e/0x1a0
[16076.262852]  [] entry_SYSCALL64_slow_path+0x25/0x25
[16076.263736] Code: 3d 00 20 00 00 48 0f 47 c2 48 89 05 cd dc 95 00 31 
c0 c3 66 90 0f 1f 44 00 00 48 8b 47 50 55 48 89 e5 f6 c4 08 74 0f 48 8b 
46 20  ff 80 58 01 00 00 48 8b 47 50 a8 08 74 04 f0 ff 4a 1c 48 8d

[16076.267481] RIP  [] __remove_shared_vm_struct+0x16/0x40
[16076.268424]  RSP 
[16076.268973] CR2: 0158
[16076.269844] ---[ end trace 98a1bbd8d9e50234 ]---
[16076.270565] Fixing recursive fault but reboot is needed!





[69086.066173] Out of memory: Kill process 2485 (trinity-c309) score 503 
or sacrifice child
[69086.067383] Killed process 2485 (trinity-c309) total-vm:73816kB, 
anon-rss:7196kB, file-rss:3940kB, shmem-rss:17248kB
[69086.071158] oom_reaper: reaped process 2485 (trinity-c309), now 
anon-rss:0kB, file-rss:0kB, shmem-rss:17248kB

[69089.763240] scsi_nl_rcv_msg: discarding partial skb
[69093.568099] scsi_nl_rcv_msg: discarding partial skb
[69095.925546] BUG: unable to handle kernel NULL pointer dereference at 
0158

[69095.926875] IP: [] __remove_shared_vm_struct+0x16/0x40
[69095.927836] PGD 0
[69095.928411] Oops: 0002 [#1] SMP
[69095.928934] Modules linked in: fuse tun 8021q xfrm_user garp 
dccp_ipv6 dccp_ipv4 dccp sctp bridge llc2 rds 

4.9.30 NULL pointer dereference in __remove_shared_vm_struct

[Tommi Rantala]

Hi,

I have hit this kernel bug twice with 4.9.30 while running trinity, any 
ideas? It's not easily reproducible.


Perhaps I should enable some more debug options to see if they reveal 
anything...


(note that I had different kernel builds, so the IP addresses are 
different in the logs below)



$ scripts/faddr2line vmlinux __remove_shared_vm_struct+0x16/0x40
__remove_shared_vm_struct+0x16/0x40:
atomic_inc at arch/x86/include/asm/atomic.h:91
 (inlined by) __remove_shared_vm_struct at mm/mmap.c:137


(gdb) disassemble __remove_shared_vm_struct
Dump of assembler code for function __remove_shared_vm_struct:
   0x8218e7a0 <+0>: callq  0x825db650 <__fentry__>
   0x8218e7a5 <+5>: mov0x50(%rdi),%rax
   0x8218e7a9 <+9>: push   %rbp
   0x8218e7aa <+10>:mov%rsp,%rbp
   0x8218e7ad <+13>:test   $0x8,%ah
   0x8218e7b0 <+16>:je 0x8218e7c1 
<__remove_shared_vm_struct+33>

   0x8218e7b2 <+18>:mov0x20(%rsi),%rax
   0x8218e7b6 <+22>:lock incl 0x158(%rax)
   0x8218e7bd <+29>:mov0x50(%rdi),%rax
   0x8218e7c1 <+33>:test   $0x8,%al
   0x8218e7c3 <+35>:je 0x8218e7c9 
<__remove_shared_vm_struct+41>

   0x8218e7c5 <+37>:lock decl 0x1c(%rdx)
   0x8218e7c9 <+41>:lea0x20(%rdx),%rsi
   0x8218e7cd <+45>:callq  0x82183460 


   0x8218e7d2 <+50>:pop%rbp
   0x8218e7d3 <+51>:retq




[16076.230255] BUG: unable to handle kernel NULL pointer dereference at 
0158

[16076.231566] IP: [] __remove_shared_vm_struct+0x16/0x40
[16076.232533] PGD 0
[16076.233125] Oops: 0002 [#1] SMP
[16076.233631] Modules linked in: fuse tun bridge hmac 8021q garp stp 
llc2 af_key llc rds xfrm_user xfrm_algo nfnetlink dccp_ipv6 sctp 
libcrc32c dccp_ipv4 dccp iptable_filter ip_tables x_tables isofs 
ata_piix autofs4

[16076.236688] CPU: 10 PID: 10753 Comm: trinity-main Not tainted 4.9.30 #1
[16076.238917] task: 880285b58000 task.stack: c90108d4c000
[16076.239741] RIP: 0010:[]  [] 
__remove_shared_vm_struct+0x16/0x40

[16076.241085] RSP: 0018:c90108d4fd38  EFLAGS: 00010202
[16076.241841] RAX:  RBX: 8801568867e8 RCX: 

[16076.242807] RDX: 88032c7581d8 RSI: 88012af34a00 RDI: 
8801568867e8
[16076.243773] RBP: c90108d4fd38 R08: 880156886b80 R09: 
7fffcf5d4000
[16076.244737] R10:  R11: 0001 R12: 
88012af34a00
[16076.245698] R13: 88032c758200 R14: 88032c7581d8 R15: 
8801568868a0
[16076.246659] FS:  () GS:88033348() 
knlGS:

[16076.247864] CS:  0010 DS:  ES:  CR0: 80050033
[16076.248667] CR2: 0158 CR3: 00c07000 CR4: 
06e0
[16076.249634] DR0: 7f54c4cae000 DR1: 7ff1276c9000 DR2: 

[16076.250599] DR3:  DR6: fffe0ff0 DR7: 
0600

[16076.251563] Stack:
[16076.251942]  c90108d4fd68 8038ef91 8801568867e8 
0040
[16076.253139]   c90108d4fdc0 c90108d4fda8 
80387893
[16076.254335]    8801d1126c00 


[16076.255528] Call Trace:
[16076.255959]  [] unlink_file_vma+0x41/0x60
[16076.256746]  [] free_pgtables+0x43/0x120
[16076.257520]  [] exit_mmap+0xb2/0x150
[16076.258258]  [] mmput+0x3b/0x100
[16076.258953]  [] do_exit+0x255/0xb20
[16076.259673]  [] ? syscall_trace_enter+0x1c1/0x2d0
[16076.260538]  [] do_group_exit+0x43/0xb0
[16076.261303]  [] SyS_exit_group+0x14/0x20
[16076.262078]  [] do_syscall_64+0x7e/0x1a0
[16076.262852]  [] entry_SYSCALL64_slow_path+0x25/0x25
[16076.263736] Code: 3d 00 20 00 00 48 0f 47 c2 48 89 05 cd dc 95 00 31 
c0 c3 66 90 0f 1f 44 00 00 48 8b 47 50 55 48 89 e5 f6 c4 08 74 0f 48 8b 
46 20  ff 80 58 01 00 00 48 8b 47 50 a8 08 74 04 f0 ff 4a 1c 48 8d

[16076.267481] RIP  [] __remove_shared_vm_struct+0x16/0x40
[16076.268424]  RSP 
[16076.268973] CR2: 0158
[16076.269844] ---[ end trace 98a1bbd8d9e50234 ]---
[16076.270565] Fixing recursive fault but reboot is needed!





[69086.066173] Out of memory: Kill process 2485 (trinity-c309) score 503 
or sacrifice child
[69086.067383] Killed process 2485 (trinity-c309) total-vm:73816kB, 
anon-rss:7196kB, file-rss:3940kB, shmem-rss:17248kB
[69086.071158] oom_reaper: reaped process 2485 (trinity-c309), now 
anon-rss:0kB, file-rss:0kB, shmem-rss:17248kB

[69089.763240] scsi_nl_rcv_msg: discarding partial skb
[69093.568099] scsi_nl_rcv_msg: discarding partial skb
[69095.925546] BUG: unable to handle kernel NULL pointer dereference at 
0158

[69095.926875] IP: [] __remove_shared_vm_struct+0x16/0x40
[69095.927836] PGD 0
[69095.928411] Oops: 0002 [#1] SMP
[69095.928934] Modules linked in: fuse tun 8021q xfrm_user garp 
dccp_ipv6 dccp_ipv4 dccp sctp bridge llc2 rds 

Re: nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3

[Tommi Rantala]

2017-05-15 8:20 GMT+03:00 Tommi Rantala <tt.rant...@gmail.com>:
> 2017-05-15 3:03 GMT+03:00 Ben Skeggs <bske...@redhat.com>:
>> On 05/15/2017 01:10 AM, Tommi Rantala wrote:
>>>
>>> Hi,
>>
>> Hey Tommi,
>>
>> Thanks for bisecting this.  It's rather unexpected that you should be seeing
>> problems here, but, the commit makes sense for it at least.
>>
>> Are you able to get me new kernel logs of both before and after this patch
>> with "log_buf_len=8M drm.debug=0x14
>> nouveau.debug=disp=trace,i2c=trace,bios=trace" please?
>
> Hi Ben,
>
> Before:
> https://www.dropbox.com/s/b2namqtqvzv5ppp/trace.4.10.0-tr-10409-g5c68d91?dl=1
>
> After:
> https://www.dropbox.com/s/9url8qdo15959fy/trace.4.10.0-tr-10410-gdf8dc97?dl=1

Hi, any comments to this?

-Tommi

> -Tommi
>
>> Thanks,
>> Ben.
>>
>>
>>>
>>> Bisected this to:
>>>
>>> commit df8dc97cd17269474344d73cc02739532c468d04
>>> Author: Ben Skeggs <bske...@redhat.com>
>>> Date:   Wed Mar 1 09:42:04 2017 +1000
>>>
>>> drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm
>>>
>>> I'm not entirely sure NVKM needs to support this now, but I haven't
>>> removed it as of yet just in case it's needed from DEVINIT scripts
>>> where DRM isn't available.
>>>
>>> Signed-off-by: Ben Skeggs <bske...@redhat.com>
>>>
>>>
>>> dmesg after boot with drm.debug enabled:
>>>
>>> v4.10-10409-g5c68d91 (still works):
>>> http://termbin.com/b0is
>>>
>>> v4.10-10410-gdf8dc97 (failure):
>>> http://termbin.com/j6lq
>>>
>>>
>>> Tommi
>>>
>>>
>>> 2017-05-10 11:24 GMT+03:00 Tommi Rantala <tt.rant...@gmail.com>:
>>>>
>>>> Hi,
>>>>
>>>> The HP ZBook 15 G3 laptop builtin display (eDP-1) does not work
>>>> correctly with v4.11-11413-g2868b25.
>>>>
>>>> When booting the laptop, the resolution seems to be limited to
>>>> 1024x768, and gnome-session segfaults.
>>>>
>>>> Up to 4.11 the display works just fine in 1920x1080 mode.
>>>>
>>>> I'm seeing this in the kernel logs:
>>>>
>>>> nouveau :01:00.0: eDP-1: EDID is invalid:
>>>>  [00] BAD  00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
>>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff 84 53 54
>>>>  [00] BAD  66 69 50 55 57 66 74 49 48 ff ff ff ff ff ff ff
>>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff 00 00 ff 00 ff
>>>> nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1
>>>> [drm] Cannot find any crtc or sizes - going 1024x768
>>>>
>>>>
>>>> $ lspci | grep NVIDIA
>>>> 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro
>>>> M2000M] (rev a2)
>>>>
>>>> Any ideas, or should I bisect?
>>>>
>>>> 4.11 dmesg & xrandr output:
>>>> https://pastebin.com/raw/P9LGP7e1
>>>>
>>>> 4.11-11413-g2868b25 dmesg:
>>>> https://pastebin.com/raw/QBT9mMua
>>>>
>>>> -Tommi

Re: nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3

[Tommi Rantala]

2017-05-15 8:20 GMT+03:00 Tommi Rantala :
> 2017-05-15 3:03 GMT+03:00 Ben Skeggs :
>> On 05/15/2017 01:10 AM, Tommi Rantala wrote:
>>>
>>> Hi,
>>
>> Hey Tommi,
>>
>> Thanks for bisecting this.  It's rather unexpected that you should be seeing
>> problems here, but, the commit makes sense for it at least.
>>
>> Are you able to get me new kernel logs of both before and after this patch
>> with "log_buf_len=8M drm.debug=0x14
>> nouveau.debug=disp=trace,i2c=trace,bios=trace" please?
>
> Hi Ben,
>
> Before:
> https://www.dropbox.com/s/b2namqtqvzv5ppp/trace.4.10.0-tr-10409-g5c68d91?dl=1
>
> After:
> https://www.dropbox.com/s/9url8qdo15959fy/trace.4.10.0-tr-10410-gdf8dc97?dl=1

Hi, any comments to this?

-Tommi

> -Tommi
>
>> Thanks,
>> Ben.
>>
>>
>>>
>>> Bisected this to:
>>>
>>> commit df8dc97cd17269474344d73cc02739532c468d04
>>> Author: Ben Skeggs 
>>> Date:   Wed Mar 1 09:42:04 2017 +1000
>>>
>>> drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm
>>>
>>> I'm not entirely sure NVKM needs to support this now, but I haven't
>>> removed it as of yet just in case it's needed from DEVINIT scripts
>>> where DRM isn't available.
>>>
>>> Signed-off-by: Ben Skeggs 
>>>
>>>
>>> dmesg after boot with drm.debug enabled:
>>>
>>> v4.10-10409-g5c68d91 (still works):
>>> http://termbin.com/b0is
>>>
>>> v4.10-10410-gdf8dc97 (failure):
>>> http://termbin.com/j6lq
>>>
>>>
>>> Tommi
>>>
>>>
>>> 2017-05-10 11:24 GMT+03:00 Tommi Rantala :
>>>>
>>>> Hi,
>>>>
>>>> The HP ZBook 15 G3 laptop builtin display (eDP-1) does not work
>>>> correctly with v4.11-11413-g2868b25.
>>>>
>>>> When booting the laptop, the resolution seems to be limited to
>>>> 1024x768, and gnome-session segfaults.
>>>>
>>>> Up to 4.11 the display works just fine in 1920x1080 mode.
>>>>
>>>> I'm seeing this in the kernel logs:
>>>>
>>>> nouveau :01:00.0: eDP-1: EDID is invalid:
>>>>  [00] BAD  00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
>>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff 84 53 54
>>>>  [00] BAD  66 69 50 55 57 66 74 49 48 ff ff ff ff ff ff ff
>>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff 00 00 ff 00 ff
>>>> nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1
>>>> [drm] Cannot find any crtc or sizes - going 1024x768
>>>>
>>>>
>>>> $ lspci | grep NVIDIA
>>>> 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro
>>>> M2000M] (rev a2)
>>>>
>>>> Any ideas, or should I bisect?
>>>>
>>>> 4.11 dmesg & xrandr output:
>>>> https://pastebin.com/raw/P9LGP7e1
>>>>
>>>> 4.11-11413-g2868b25 dmesg:
>>>> https://pastebin.com/raw/QBT9mMua
>>>>
>>>> -Tommi

Re: (radeon?) WARNING: drivers/gpu/drm/drm_irq.c:1195 drm_vblank_put (v4.11-12441-g56868a4)

[Tommi Rantala]

2017-05-22 10:32 GMT+03:00 Daniel Vetter :
> Yeah I think the locking stuff we've fixed, at least if you don't see it
> in 4.12 it should be all good. And I think I spotted the bug you've
> bisected to, patch is on dri-devel, pls test.

Thanks! I'll test it later today.

-Tommi

Re: (radeon?) WARNING: drivers/gpu/drm/drm_irq.c:1195 drm_vblank_put (v4.11-12441-g56868a4)

[Tommi Rantala]

2017-05-22 10:32 GMT+03:00 Daniel Vetter :
> Yeah I think the locking stuff we've fixed, at least if you don't see it
> in 4.12 it should be all good. And I think I spotted the bug you've
> bisected to, patch is on dri-devel, pls test.

Thanks! I'll test it later today.

-Tommi

Re: (radeon?) WARNING: drivers/gpu/drm/drm_irq.c:1195 drm_vblank_put (v4.11-12441-g56868a4)

[Tommi Rantala]

2017-05-11 5:51 GMT+03:00 Michel Dänzer <mic...@daenzer.net>:
> On 11/05/17 04:33 AM, Tommi Rantala wrote:
>> Complete kernel log:
>> http://termbin.com/dzy5
>>
>> [  249.952546] [ cut here ]
>> [  249.952593] WARNING: CPU: 5 PID: 0 at
>> /home/ttrantal/git/linux/drivers/gpu/drm/drm_irq.c:1195
>> drm_vblank_put+0xc4/0x120 [drm]
>> [  249.952596] Modules linked in: fuse tun bridge stp llc af_packet
>> pl2303 usbserial shpchp acpi_cpufreq binfmt_misc amdgpu hid_generic
>> uhci_hcd radeon 3c59x mii tg3 ehci_pci ehci_hcd i2c_algo_bit
>> drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm
>> agpgart unix autofs4
>> [  249.952675] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW
>> 4.11.0+ #4
>> [  249.952678] Hardware name: Hewlett-Packard HP xw6600
>> Workstation/0A9Ch, BIOS 786F4 v01.46 09/20/2012
>> [  249.952681] task: 88080aea task.stack: c900031b
>> [  249.952695] RIP: 0010:drm_vblank_put+0xc4/0x120 [drm]
>> [  249.952698] RSP: 0018:88080f003d70 EFLAGS: 00010046
>> [  249.952703] RAX:  RBX: 880801d53000 RCX: 
>> 
>> [  249.952706] RDX:  RSI:  RDI: 
>> 88080a4ac000
>> [  249.952709] RBP: 88080f003d88 R08: 0001 R09: 
>> 0003
>> [  249.952711] R10: 88080f003d08 R11: 001da540 R12: 
>> 88080a4ac000
>> [  249.952714] R13:  R14: 0086 R15: 
>> 8808019a
>> [  249.952717] FS:  () GS:88080f00()
>> knlGS:
>> [  249.952720] CS:  0010 DS:  ES:  CR0: 80050033
>> [  249.952723] CR2: 7f8bcc3a5810 CR3: 000808789000 CR4: 
>> 06e0
>> [  249.952726] Call Trace:
>> [  249.952731]  
>> [  249.952746]  drm_crtc_vblank_put+0x1b/0x30 [drm]
>> [  249.952813]  radeon_crtc_handle_flip+0xdc/0x140 [radeon]
>> [  249.952843]  si_irq_process+0x610/0x1e90 [radeon]
>> [  249.952872]  radeon_driver_irq_handler_kms+0x39/0xc0 [radeon]
>> [  249.952881]  __handle_irq_event_percpu+0x60/0x580
>> [  249.952887]  handle_irq_event_percpu+0x20/0x90
>> [  249.952892]  handle_irq_event+0x46/0xb0
>> [  249.952897]  handle_edge_irq+0x13d/0x370
>> [  249.952903]  handle_irq+0x66/0x210
>> [  249.952908]  ? __local_bh_enable+0x34/0x50
>> [  249.952914]  do_IRQ+0x7e/0x1b0
>> [  249.952920]  common_interrupt+0x95/0x95
>
> Weird, not sure how this could happen. Can you bisect?

Hi,

Bisection points to this (also manually applied commit 9739e74646
while testing, got kernel oops otherwise):

commit 29dc0d1de18239cf3ef8bab578b8321ed340d81c
Author: Daniel Vetter <daniel.vet...@ffwll.ch>
Date:   Wed Mar 22 22:50:49 2017 +0100

drm: Roll out acquire context for the page_flip ioctl

Again just prep work.

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-11-daniel.vet...@ffwll.ch


I'm also seeing some more warnings in this version:


May 18 19:21:55 xw6600 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp14s0:
link becomes ready
May 18 19:21:57 xw6600 kernel: [ cut here ]
May 18 19:21:57 xw6600 kernel: WARNING: CPU: 5 PID: 4607 at
/home/ttrantal/git/linux/drivers/gpu/drm/drm_modeset_lock.c:193
drm_modeset_lock_crtc+0xe5/0x100 [drm]
May 18 19:21:57 xw6600 kernel: Modules linked in: tun bridge stp llc
af_packet pl2303 usbserial shpchp acpi_cpufreq binfmt_misc amdgpu
hid_generic uhci_hcd radeon 3c59x mii i2c_algo_bit drm_kms_helper tg3
syscopyarea sysfillrect sysimgblt
May 18 19:21:57 xw6600 kernel: CPU: 5 PID: 4607 Comm: gnome-shell Not
tainted 4.11.0-rc3-00944-g29dc0d1-dirty #30
May 18 19:21:57 xw6600 kernel: Hardware name: Hewlett-Packard HP
xw6600 Workstation/0A9Ch, BIOS 786F4 v01.46 09/20/2012
May 18 19:21:57 xw6600 kernel: Call Trace:
May 18 19:21:57 xw6600 kernel:  dump_stack+0x69/0x9b
May 18 19:21:57 xw6600 kernel:  __warn+0xff/0x140
May 18 19:21:57 xw6600 kernel:  warn_slowpath_null+0x18/0x20
May 18 19:21:57 xw6600 kernel:  drm_modeset_lock_crtc+0xe5/0x100 [drm]
May 18 19:21:57 xw6600 kernel:  drm_mode_cursor_common+0xbd/0x200 [drm]
May 18 19:21:57 xw6600 kernel:  drm_mode_cursor_ioctl+0x3c/0x40 [drm]
May 18 19:21:57 xw6600 kernel:  drm_ioctl+0x3ea/0x870 [drm]
May 18 19:21:57 xw6600 kernel:  ? drm_mode_setplane+0x1a0/0x1a0 [drm]
May 18 19:21:57 xw6600 kernel:  ? trace_hardirqs_on_caller+0x1ad/0x2c0
May 18 19:21:57 xw6600 kernel:  ? trace_hardirqs_on+0xd/0x10
May 18 19:21:57 xw6600 kernel:  radeon_drm_ioctl+0x6e/0x110 [radeon]
May 18 19:21:57 xw6600 kernel:  do_vfs_ioctl+0xac/0x9d0
Ma

Re: (radeon?) WARNING: drivers/gpu/drm/drm_irq.c:1195 drm_vblank_put (v4.11-12441-g56868a4)

[Tommi Rantala]

2017-05-11 5:51 GMT+03:00 Michel Dänzer :
> On 11/05/17 04:33 AM, Tommi Rantala wrote:
>> Complete kernel log:
>> http://termbin.com/dzy5
>>
>> [  249.952546] [ cut here ]
>> [  249.952593] WARNING: CPU: 5 PID: 0 at
>> /home/ttrantal/git/linux/drivers/gpu/drm/drm_irq.c:1195
>> drm_vblank_put+0xc4/0x120 [drm]
>> [  249.952596] Modules linked in: fuse tun bridge stp llc af_packet
>> pl2303 usbserial shpchp acpi_cpufreq binfmt_misc amdgpu hid_generic
>> uhci_hcd radeon 3c59x mii tg3 ehci_pci ehci_hcd i2c_algo_bit
>> drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm
>> agpgart unix autofs4
>> [  249.952675] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW
>> 4.11.0+ #4
>> [  249.952678] Hardware name: Hewlett-Packard HP xw6600
>> Workstation/0A9Ch, BIOS 786F4 v01.46 09/20/2012
>> [  249.952681] task: 88080aea task.stack: c900031b
>> [  249.952695] RIP: 0010:drm_vblank_put+0xc4/0x120 [drm]
>> [  249.952698] RSP: 0018:88080f003d70 EFLAGS: 00010046
>> [  249.952703] RAX:  RBX: 880801d53000 RCX: 
>> 
>> [  249.952706] RDX:  RSI:  RDI: 
>> 88080a4ac000
>> [  249.952709] RBP: 88080f003d88 R08: 0001 R09: 
>> 0003
>> [  249.952711] R10: 88080f003d08 R11: 001da540 R12: 
>> 88080a4ac000
>> [  249.952714] R13:  R14: 0086 R15: 
>> 8808019a
>> [  249.952717] FS:  () GS:88080f00()
>> knlGS:
>> [  249.952720] CS:  0010 DS:  ES:  CR0: 80050033
>> [  249.952723] CR2: 7f8bcc3a5810 CR3: 000808789000 CR4: 
>> 06e0
>> [  249.952726] Call Trace:
>> [  249.952731]  
>> [  249.952746]  drm_crtc_vblank_put+0x1b/0x30 [drm]
>> [  249.952813]  radeon_crtc_handle_flip+0xdc/0x140 [radeon]
>> [  249.952843]  si_irq_process+0x610/0x1e90 [radeon]
>> [  249.952872]  radeon_driver_irq_handler_kms+0x39/0xc0 [radeon]
>> [  249.952881]  __handle_irq_event_percpu+0x60/0x580
>> [  249.952887]  handle_irq_event_percpu+0x20/0x90
>> [  249.952892]  handle_irq_event+0x46/0xb0
>> [  249.952897]  handle_edge_irq+0x13d/0x370
>> [  249.952903]  handle_irq+0x66/0x210
>> [  249.952908]  ? __local_bh_enable+0x34/0x50
>> [  249.952914]  do_IRQ+0x7e/0x1b0
>> [  249.952920]  common_interrupt+0x95/0x95
>
> Weird, not sure how this could happen. Can you bisect?

Hi,

Bisection points to this (also manually applied commit 9739e74646
while testing, got kernel oops otherwise):

commit 29dc0d1de18239cf3ef8bab578b8321ed340d81c
Author: Daniel Vetter 
Date:   Wed Mar 22 22:50:49 2017 +0100

drm: Roll out acquire context for the page_flip ioctl

Again just prep work.

Reviewed-by: Harry Wentland 
Signed-off-by: Daniel Vetter 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-11-daniel.vet...@ffwll.ch


I'm also seeing some more warnings in this version:


May 18 19:21:55 xw6600 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp14s0:
link becomes ready
May 18 19:21:57 xw6600 kernel: [ cut here ]
May 18 19:21:57 xw6600 kernel: WARNING: CPU: 5 PID: 4607 at
/home/ttrantal/git/linux/drivers/gpu/drm/drm_modeset_lock.c:193
drm_modeset_lock_crtc+0xe5/0x100 [drm]
May 18 19:21:57 xw6600 kernel: Modules linked in: tun bridge stp llc
af_packet pl2303 usbserial shpchp acpi_cpufreq binfmt_misc amdgpu
hid_generic uhci_hcd radeon 3c59x mii i2c_algo_bit drm_kms_helper tg3
syscopyarea sysfillrect sysimgblt
May 18 19:21:57 xw6600 kernel: CPU: 5 PID: 4607 Comm: gnome-shell Not
tainted 4.11.0-rc3-00944-g29dc0d1-dirty #30
May 18 19:21:57 xw6600 kernel: Hardware name: Hewlett-Packard HP
xw6600 Workstation/0A9Ch, BIOS 786F4 v01.46 09/20/2012
May 18 19:21:57 xw6600 kernel: Call Trace:
May 18 19:21:57 xw6600 kernel:  dump_stack+0x69/0x9b
May 18 19:21:57 xw6600 kernel:  __warn+0xff/0x140
May 18 19:21:57 xw6600 kernel:  warn_slowpath_null+0x18/0x20
May 18 19:21:57 xw6600 kernel:  drm_modeset_lock_crtc+0xe5/0x100 [drm]
May 18 19:21:57 xw6600 kernel:  drm_mode_cursor_common+0xbd/0x200 [drm]
May 18 19:21:57 xw6600 kernel:  drm_mode_cursor_ioctl+0x3c/0x40 [drm]
May 18 19:21:57 xw6600 kernel:  drm_ioctl+0x3ea/0x870 [drm]
May 18 19:21:57 xw6600 kernel:  ? drm_mode_setplane+0x1a0/0x1a0 [drm]
May 18 19:21:57 xw6600 kernel:  ? trace_hardirqs_on_caller+0x1ad/0x2c0
May 18 19:21:57 xw6600 kernel:  ? trace_hardirqs_on+0xd/0x10
May 18 19:21:57 xw6600 kernel:  radeon_drm_ioctl+0x6e/0x110 [radeon]
May 18 19:21:57 xw6600 kernel:  do_vfs_ioctl+0xac/0x9d0
May 18 19:21:57 xw6600 kernel:  ? security_file_ioctl+0x4c/0x80
May 18 19:21:57 xw6600 kernel:  SyS_ioctl+0x74/0x80
May

Re: nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3

[Tommi Rantala]

2017-05-15 3:03 GMT+03:00 Ben Skeggs <bske...@redhat.com>:
> On 05/15/2017 01:10 AM, Tommi Rantala wrote:
>>
>> Hi,
>
> Hey Tommi,
>
> Thanks for bisecting this.  It's rather unexpected that you should be seeing
> problems here, but, the commit makes sense for it at least.
>
> Are you able to get me new kernel logs of both before and after this patch
> with "log_buf_len=8M drm.debug=0x14
> nouveau.debug=disp=trace,i2c=trace,bios=trace" please?

Hi Ben,

Before:
https://www.dropbox.com/s/b2namqtqvzv5ppp/trace.4.10.0-tr-10409-g5c68d91?dl=1

After:
https://www.dropbox.com/s/9url8qdo15959fy/trace.4.10.0-tr-10410-gdf8dc97?dl=1

-Tommi

> Thanks,
> Ben.
>
>
>>
>> Bisected this to:
>>
>> commit df8dc97cd17269474344d73cc02739532c468d04
>> Author: Ben Skeggs <bske...@redhat.com>
>> Date:   Wed Mar 1 09:42:04 2017 +1000
>>
>> drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm
>>
>> I'm not entirely sure NVKM needs to support this now, but I haven't
>> removed it as of yet just in case it's needed from DEVINIT scripts
>> where DRM isn't available.
>>
>> Signed-off-by: Ben Skeggs <bske...@redhat.com>
>>
>>
>> dmesg after boot with drm.debug enabled:
>>
>> v4.10-10409-g5c68d91 (still works):
>> http://termbin.com/b0is
>>
>> v4.10-10410-gdf8dc97 (failure):
>> http://termbin.com/j6lq
>>
>>
>> Tommi
>>
>>
>> 2017-05-10 11:24 GMT+03:00 Tommi Rantala <tt.rant...@gmail.com>:
>>>
>>> Hi,
>>>
>>> The HP ZBook 15 G3 laptop builtin display (eDP-1) does not work
>>> correctly with v4.11-11413-g2868b25.
>>>
>>> When booting the laptop, the resolution seems to be limited to
>>> 1024x768, and gnome-session segfaults.
>>>
>>> Up to 4.11 the display works just fine in 1920x1080 mode.
>>>
>>> I'm seeing this in the kernel logs:
>>>
>>> nouveau :01:00.0: eDP-1: EDID is invalid:
>>>  [00] BAD  00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff 84 53 54
>>>  [00] BAD  66 69 50 55 57 66 74 49 48 ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff 00 00 ff 00 ff
>>> nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1
>>> [drm] Cannot find any crtc or sizes - going 1024x768
>>>
>>>
>>> $ lspci | grep NVIDIA
>>> 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro
>>> M2000M] (rev a2)
>>>
>>> Any ideas, or should I bisect?
>>>
>>> 4.11 dmesg & xrandr output:
>>> https://pastebin.com/raw/P9LGP7e1
>>>
>>> 4.11-11413-g2868b25 dmesg:
>>> https://pastebin.com/raw/QBT9mMua
>>>
>>> -Tommi

Re: nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3

[Tommi Rantala]

2017-05-15 3:03 GMT+03:00 Ben Skeggs :
> On 05/15/2017 01:10 AM, Tommi Rantala wrote:
>>
>> Hi,
>
> Hey Tommi,
>
> Thanks for bisecting this.  It's rather unexpected that you should be seeing
> problems here, but, the commit makes sense for it at least.
>
> Are you able to get me new kernel logs of both before and after this patch
> with "log_buf_len=8M drm.debug=0x14
> nouveau.debug=disp=trace,i2c=trace,bios=trace" please?

Hi Ben,

Before:
https://www.dropbox.com/s/b2namqtqvzv5ppp/trace.4.10.0-tr-10409-g5c68d91?dl=1

After:
https://www.dropbox.com/s/9url8qdo15959fy/trace.4.10.0-tr-10410-gdf8dc97?dl=1

-Tommi

> Thanks,
> Ben.
>
>
>>
>> Bisected this to:
>>
>> commit df8dc97cd17269474344d73cc02739532c468d04
>> Author: Ben Skeggs 
>> Date:   Wed Mar 1 09:42:04 2017 +1000
>>
>> drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm
>>
>> I'm not entirely sure NVKM needs to support this now, but I haven't
>> removed it as of yet just in case it's needed from DEVINIT scripts
>> where DRM isn't available.
>>
>> Signed-off-by: Ben Skeggs 
>>
>>
>> dmesg after boot with drm.debug enabled:
>>
>> v4.10-10409-g5c68d91 (still works):
>> http://termbin.com/b0is
>>
>> v4.10-10410-gdf8dc97 (failure):
>> http://termbin.com/j6lq
>>
>>
>> Tommi
>>
>>
>> 2017-05-10 11:24 GMT+03:00 Tommi Rantala :
>>>
>>> Hi,
>>>
>>> The HP ZBook 15 G3 laptop builtin display (eDP-1) does not work
>>> correctly with v4.11-11413-g2868b25.
>>>
>>> When booting the laptop, the resolution seems to be limited to
>>> 1024x768, and gnome-session segfaults.
>>>
>>> Up to 4.11 the display works just fine in 1920x1080 mode.
>>>
>>> I'm seeing this in the kernel logs:
>>>
>>> nouveau :01:00.0: eDP-1: EDID is invalid:
>>>  [00] BAD  00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff 84 53 54
>>>  [00] BAD  66 69 50 55 57 66 74 49 48 ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff 00 00 ff 00 ff
>>> nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1
>>> [drm] Cannot find any crtc or sizes - going 1024x768
>>>
>>>
>>> $ lspci | grep NVIDIA
>>> 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro
>>> M2000M] (rev a2)
>>>
>>> Any ideas, or should I bisect?
>>>
>>> 4.11 dmesg & xrandr output:
>>> https://pastebin.com/raw/P9LGP7e1
>>>
>>> 4.11-11413-g2868b25 dmesg:
>>> https://pastebin.com/raw/QBT9mMua
>>>
>>> -Tommi

Re: nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3

[Tommi Rantala]

Hi,

Bisected this to:

commit df8dc97cd17269474344d73cc02739532c468d04
Author: Ben Skeggs <bske...@redhat.com>
Date:   Wed Mar 1 09:42:04 2017 +1000

   drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm

   I'm not entirely sure NVKM needs to support this now, but I haven't
   removed it as of yet just in case it's needed from DEVINIT scripts
   where DRM isn't available.

   Signed-off-by: Ben Skeggs <bske...@redhat.com>


dmesg after boot with drm.debug enabled:

v4.10-10409-g5c68d91 (still works):
http://termbin.com/b0is

v4.10-10410-gdf8dc97 (failure):
http://termbin.com/j6lq


Tommi


2017-05-10 11:24 GMT+03:00 Tommi Rantala <tt.rant...@gmail.com>:
> Hi,
>
> The HP ZBook 15 G3 laptop builtin display (eDP-1) does not work
> correctly with v4.11-11413-g2868b25.
>
> When booting the laptop, the resolution seems to be limited to
> 1024x768, and gnome-session segfaults.
>
> Up to 4.11 the display works just fine in 1920x1080 mode.
>
> I'm seeing this in the kernel logs:
>
> nouveau :01:00.0: eDP-1: EDID is invalid:
> [00] BAD  00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff 84 53 54
> [00] BAD  66 69 50 55 57 66 74 49 48 ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff 00 00 ff 00 ff
> nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1
> [drm] Cannot find any crtc or sizes - going 1024x768
>
>
> $ lspci | grep NVIDIA
> 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro
> M2000M] (rev a2)
>
> Any ideas, or should I bisect?
>
> 4.11 dmesg & xrandr output:
> https://pastebin.com/raw/P9LGP7e1
>
> 4.11-11413-g2868b25 dmesg:
> https://pastebin.com/raw/QBT9mMua
>
> -Tommi

Re: nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3

[Tommi Rantala]

Hi,

Bisected this to:

commit df8dc97cd17269474344d73cc02739532c468d04
Author: Ben Skeggs 
Date:   Wed Mar 1 09:42:04 2017 +1000

   drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm

   I'm not entirely sure NVKM needs to support this now, but I haven't
   removed it as of yet just in case it's needed from DEVINIT scripts
   where DRM isn't available.

   Signed-off-by: Ben Skeggs 


dmesg after boot with drm.debug enabled:

v4.10-10409-g5c68d91 (still works):
http://termbin.com/b0is

v4.10-10410-gdf8dc97 (failure):
http://termbin.com/j6lq


Tommi


2017-05-10 11:24 GMT+03:00 Tommi Rantala :
> Hi,
>
> The HP ZBook 15 G3 laptop builtin display (eDP-1) does not work
> correctly with v4.11-11413-g2868b25.
>
> When booting the laptop, the resolution seems to be limited to
> 1024x768, and gnome-session segfaults.
>
> Up to 4.11 the display works just fine in 1920x1080 mode.
>
> I'm seeing this in the kernel logs:
>
> nouveau :01:00.0: eDP-1: EDID is invalid:
> [00] BAD  00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff 84 53 54
> [00] BAD  66 69 50 55 57 66 74 49 48 ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff 00 00 ff 00 ff
> nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1
> [drm] Cannot find any crtc or sizes - going 1024x768
>
>
> $ lspci | grep NVIDIA
> 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro
> M2000M] (rev a2)
>
> Any ideas, or should I bisect?
>
> 4.11 dmesg & xrandr output:
> https://pastebin.com/raw/P9LGP7e1
>
> 4.11-11413-g2868b25 dmesg:
> https://pastebin.com/raw/QBT9mMua
>
> -Tommi

Re: [PATCH] hwmon: (coretemp) Handle frozen hotplug state correctly

[Tommi Rantala]

2017-05-10 23:09 GMT+03:00 Guenter Roeck <li...@roeck-us.net>:
> On Wed, May 10, 2017 at 10:16:33PM +0300, Tommi Rantala wrote:
>> 2017-05-10 17:30 GMT+03:00 Thomas Gleixner <t...@linutronix.de>:
>> > The recent conversion to the hotplug state machine missed that the original
>> > hotplug notifiers did not execute in the frozen state, which is used on
>> > suspend on resume.
>> >
>> > This does not matter on single socket machines, but on multi socket systems
>> > this breaks when the device for a non-boot socket is removed when the last
>> > CPU of that socket is brought offline. The device removal locks up the
>> > machine hard w/o any debug output.
>> >
>> > Prevent executing the hotplug callbacks when cpuhp_tasks_frozen is true.
>> >
>> > Thanks to Tommi for providing debug information patiently while I failed to
>> > spot the obvious.
>> >
>> > Fixes: e00ca5df37ad ("hwmon: (coretemp) Convert to hotplug state machine")
>> > Reported-by: Tommi Rantala <tt.rant...@gmail.com>
>> > Signed-off-by: Thomas Gleixner <t...@linutronix.de>
>>
>> Many thanks, I can confirm that it works well!
>>
> Ok if I add your Tested-by: ?

Sure!

Tested-by: Tommi Rantala <tt.rant...@gmail.com>

> Thanks,
> Guenter
>
>> -Tommi
>>
>> > ---
>> >  drivers/hwmon/coretemp.c |   14 ++
>> >  1 file changed, 14 insertions(+)
>> >
>> > --- a/drivers/hwmon/coretemp.c
>> > +++ b/drivers/hwmon/coretemp.c
>> > @@ -605,6 +605,13 @@ static int coretemp_cpu_online(unsigned
>> > struct platform_data *pdata;
>> >
>> > /*
>> > +* Don't execute this on resume as the offline callback did
>> > +* not get executed on suspend.
>> > +*/
>> > +   if (cpuhp_tasks_frozen)
>> > +   return 0;
>> > +
>> > +   /*
>> >  * CPUID.06H.EAX[0] indicates whether the CPU has thermal
>> >  * sensors. We check this bit only, all the early CPUs
>> >  * without thermal sensors will be filtered out.
>> > @@ -654,6 +661,13 @@ static int coretemp_cpu_offline(unsigned
>> > struct temp_data *tdata;
>> > int indx, target;
>> >
>> > +   /*
>> > +* Don't execute this on suspend as the device remove locks
>> > +* up the machine.
>> > +*/
>> > +   if (cpuhp_tasks_frozen)
>> > +   return 0;
>> > +
>> > /* If the physical CPU device does not exist, just return */
>> > if (!pdev)
>> > return 0;

Re: [PATCH] hwmon: (coretemp) Handle frozen hotplug state correctly

[Tommi Rantala]

2017-05-10 23:09 GMT+03:00 Guenter Roeck :
> On Wed, May 10, 2017 at 10:16:33PM +0300, Tommi Rantala wrote:
>> 2017-05-10 17:30 GMT+03:00 Thomas Gleixner :
>> > The recent conversion to the hotplug state machine missed that the original
>> > hotplug notifiers did not execute in the frozen state, which is used on
>> > suspend on resume.
>> >
>> > This does not matter on single socket machines, but on multi socket systems
>> > this breaks when the device for a non-boot socket is removed when the last
>> > CPU of that socket is brought offline. The device removal locks up the
>> > machine hard w/o any debug output.
>> >
>> > Prevent executing the hotplug callbacks when cpuhp_tasks_frozen is true.
>> >
>> > Thanks to Tommi for providing debug information patiently while I failed to
>> > spot the obvious.
>> >
>> > Fixes: e00ca5df37ad ("hwmon: (coretemp) Convert to hotplug state machine")
>> > Reported-by: Tommi Rantala 
>> > Signed-off-by: Thomas Gleixner 
>>
>> Many thanks, I can confirm that it works well!
>>
> Ok if I add your Tested-by: ?

Sure!

Tested-by: Tommi Rantala 

> Thanks,
> Guenter
>
>> -Tommi
>>
>> > ---
>> >  drivers/hwmon/coretemp.c |   14 ++
>> >  1 file changed, 14 insertions(+)
>> >
>> > --- a/drivers/hwmon/coretemp.c
>> > +++ b/drivers/hwmon/coretemp.c
>> > @@ -605,6 +605,13 @@ static int coretemp_cpu_online(unsigned
>> > struct platform_data *pdata;
>> >
>> > /*
>> > +* Don't execute this on resume as the offline callback did
>> > +* not get executed on suspend.
>> > +*/
>> > +   if (cpuhp_tasks_frozen)
>> > +   return 0;
>> > +
>> > +   /*
>> >  * CPUID.06H.EAX[0] indicates whether the CPU has thermal
>> >  * sensors. We check this bit only, all the early CPUs
>> >  * without thermal sensors will be filtered out.
>> > @@ -654,6 +661,13 @@ static int coretemp_cpu_offline(unsigned
>> > struct temp_data *tdata;
>> > int indx, target;
>> >
>> > +   /*
>> > +* Don't execute this on suspend as the device remove locks
>> > +* up the machine.
>> > +*/
>> > +   if (cpuhp_tasks_frozen)
>> > +   return 0;
>> > +
>> > /* If the physical CPU device does not exist, just return */
>> > if (!pdev)
>> > return 0;

(radeon?) WARNING: drivers/gpu/drm/drm_irq.c:1195 drm_vblank_put (v4.11-12441-g56868a4)

[Tommi Rantala]

Hi,

I just tested v4.11-12441-g56868a4 on HP xw6600 with radeon graphics,
and I'm seeing the following WARNING triggered constantly.

I have not seen this earlier e.g. with the distro kernel 4.10.13-200.fc25.x86_64

$ lspci|grep -i amd
60:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Curacao PRO [Radeon R7 370 / R9 270/370 OEM]
60:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cape
Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series]

Complete kernel log:
http://termbin.com/dzy5

[  249.952546] [ cut here ]
[  249.952593] WARNING: CPU: 5 PID: 0 at
/home/ttrantal/git/linux/drivers/gpu/drm/drm_irq.c:1195
drm_vblank_put+0xc4/0x120 [drm]
[  249.952596] Modules linked in: fuse tun bridge stp llc af_packet
pl2303 usbserial shpchp acpi_cpufreq binfmt_misc amdgpu hid_generic
uhci_hcd radeon 3c59x mii tg3 ehci_pci ehci_hcd i2c_algo_bit
drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm
agpgart unix autofs4
[  249.952675] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW
4.11.0+ #4
[  249.952678] Hardware name: Hewlett-Packard HP xw6600
Workstation/0A9Ch, BIOS 786F4 v01.46 09/20/2012
[  249.952681] task: 88080aea task.stack: c900031b
[  249.952695] RIP: 0010:drm_vblank_put+0xc4/0x120 [drm]
[  249.952698] RSP: 0018:88080f003d70 EFLAGS: 00010046
[  249.952703] RAX:  RBX: 880801d53000 RCX: 
[  249.952706] RDX:  RSI:  RDI: 88080a4ac000
[  249.952709] RBP: 88080f003d88 R08: 0001 R09: 0003
[  249.952711] R10: 88080f003d08 R11: 001da540 R12: 88080a4ac000
[  249.952714] R13:  R14: 0086 R15: 8808019a
[  249.952717] FS:  () GS:88080f00()
knlGS:
[  249.952720] CS:  0010 DS:  ES:  CR0: 80050033
[  249.952723] CR2: 7f8bcc3a5810 CR3: 000808789000 CR4: 06e0
[  249.952726] Call Trace:
[  249.952731]  
[  249.952746]  drm_crtc_vblank_put+0x1b/0x30 [drm]
[  249.952813]  radeon_crtc_handle_flip+0xdc/0x140 [radeon]
[  249.952843]  si_irq_process+0x610/0x1e90 [radeon]
[  249.952872]  radeon_driver_irq_handler_kms+0x39/0xc0 [radeon]
[  249.952881]  __handle_irq_event_percpu+0x60/0x580
[  249.952887]  handle_irq_event_percpu+0x20/0x90
[  249.952892]  handle_irq_event+0x46/0xb0
[  249.952897]  handle_edge_irq+0x13d/0x370
[  249.952903]  handle_irq+0x66/0x210
[  249.952908]  ? __local_bh_enable+0x34/0x50
[  249.952914]  do_IRQ+0x7e/0x1b0
[  249.952920]  common_interrupt+0x95/0x95
[  249.952924] RIP: 0010:mwait_idle+0x9c/0x3c0
[  249.952927] RSP: 0018:c900031b3e68 EFLAGS: 0246 ORIG_RAX:
ff4d
[  249.952932] RAX:  RBX: 88080aea RCX: 
[  249.952935] RDX: 0001 RSI: 0001 RDI: 88080aea
[  249.952938] RBP: c900031b3e98 R08: 0006 R09: 
[  249.952941] R10:  R11:  R12: 88080aea
[  249.952943] R13: 0005 R14: 839ca0c8 R15: 
[  249.952946]  
[  249.952955]  ? mwait_idle+0x93/0x3c0
[  249.952961]  arch_cpu_idle+0xa/0x10
[  249.952965]  default_idle_call+0x24/0x40
[  249.952971]  do_idle+0x154/0x1f0
[  249.952976]  cpu_startup_entry+0x18/0x20
[  249.952981]  start_secondary+0x159/0x1f0
[  249.952987]  secondary_startup_64+0x9f/0x9f
[  249.952995] Code: 0d 32 c7 9a e2 f7 ea 41 c1 fc 1f 48 8d 7b 60 c1
fa 06 44 29 e2 48 63 f2 48 01 ce e8 37 7d 1e e1 eb be 0f ff 5b 41 5c
41 5d 5d c3 <0f> ff eb b1 48 89 df e8 40 fe ff ff eb a7 41 0f b6 f4 48
c7 c7
[  249.953135] ---[ end trace 399ab7917ed3b208 ]---
[  251.185850] [ cut here ]
[  251.185896] WARNING: CPU: 5 PID: 4425 at
/home/ttrantal/git/linux/drivers/gpu/drm/drm_irq.c:1195
drm_vblank_put+0xc4/0x120 [drm]
[  251.185899] Modules linked in: fuse tun bridge stp llc af_packet
pl2303 usbserial shpchp acpi_cpufreq binfmt_misc amdgpu hid_generic
uhci_hcd radeon 3c59x mii tg3 ehci_pci ehci_hcd i2c_algo_bit
drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm
agpgart unix autofs4
[  251.185979] CPU: 5 PID: 4425 Comm: in:imjournal Tainted: GW
  4.11.0+ #4
[  251.185982] Hardware name: Hewlett-Packard HP xw6600
Workstation/0A9Ch, BIOS 786F4 v01.46 09/20/2012
[  251.185984] task: 880802f8b280 task.stack: c900034c8000
[  251.185998] RIP: 0010:drm_vblank_put+0xc4/0x120 [drm]
[  251.186001] RSP: :88080f003d70 EFLAGS: 00010046
[  251.186006] RAX:  RBX: 880801d53000 RCX: 
[  251.186009] RDX:  RSI:  RDI: 88080a4ac000
[  251.186012] RBP: 88080f003d88 R08: 0001 R09: 0003
[  251.186015] R10: 88080f003d08 R11: 001da540 R12: 88080a4ac000
[  251.186017] R13:  R14: 0086 R15: 8808019a
[  

(radeon?) WARNING: drivers/gpu/drm/drm_irq.c:1195 drm_vblank_put (v4.11-12441-g56868a4)

[Tommi Rantala]

Hi,

I just tested v4.11-12441-g56868a4 on HP xw6600 with radeon graphics,
and I'm seeing the following WARNING triggered constantly.

I have not seen this earlier e.g. with the distro kernel 4.10.13-200.fc25.x86_64

$ lspci|grep -i amd
60:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Curacao PRO [Radeon R7 370 / R9 270/370 OEM]
60:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cape
Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series]

Complete kernel log:
http://termbin.com/dzy5

[  249.952546] [ cut here ]
[  249.952593] WARNING: CPU: 5 PID: 0 at
/home/ttrantal/git/linux/drivers/gpu/drm/drm_irq.c:1195
drm_vblank_put+0xc4/0x120 [drm]
[  249.952596] Modules linked in: fuse tun bridge stp llc af_packet
pl2303 usbserial shpchp acpi_cpufreq binfmt_misc amdgpu hid_generic
uhci_hcd radeon 3c59x mii tg3 ehci_pci ehci_hcd i2c_algo_bit
drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm
agpgart unix autofs4
[  249.952675] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW
4.11.0+ #4
[  249.952678] Hardware name: Hewlett-Packard HP xw6600
Workstation/0A9Ch, BIOS 786F4 v01.46 09/20/2012
[  249.952681] task: 88080aea task.stack: c900031b
[  249.952695] RIP: 0010:drm_vblank_put+0xc4/0x120 [drm]
[  249.952698] RSP: 0018:88080f003d70 EFLAGS: 00010046
[  249.952703] RAX:  RBX: 880801d53000 RCX: 
[  249.952706] RDX:  RSI:  RDI: 88080a4ac000
[  249.952709] RBP: 88080f003d88 R08: 0001 R09: 0003
[  249.952711] R10: 88080f003d08 R11: 001da540 R12: 88080a4ac000
[  249.952714] R13:  R14: 0086 R15: 8808019a
[  249.952717] FS:  () GS:88080f00()
knlGS:
[  249.952720] CS:  0010 DS:  ES:  CR0: 80050033
[  249.952723] CR2: 7f8bcc3a5810 CR3: 000808789000 CR4: 06e0
[  249.952726] Call Trace:
[  249.952731]  
[  249.952746]  drm_crtc_vblank_put+0x1b/0x30 [drm]
[  249.952813]  radeon_crtc_handle_flip+0xdc/0x140 [radeon]
[  249.952843]  si_irq_process+0x610/0x1e90 [radeon]
[  249.952872]  radeon_driver_irq_handler_kms+0x39/0xc0 [radeon]
[  249.952881]  __handle_irq_event_percpu+0x60/0x580
[  249.952887]  handle_irq_event_percpu+0x20/0x90
[  249.952892]  handle_irq_event+0x46/0xb0
[  249.952897]  handle_edge_irq+0x13d/0x370
[  249.952903]  handle_irq+0x66/0x210
[  249.952908]  ? __local_bh_enable+0x34/0x50
[  249.952914]  do_IRQ+0x7e/0x1b0
[  249.952920]  common_interrupt+0x95/0x95
[  249.952924] RIP: 0010:mwait_idle+0x9c/0x3c0
[  249.952927] RSP: 0018:c900031b3e68 EFLAGS: 0246 ORIG_RAX:
ff4d
[  249.952932] RAX:  RBX: 88080aea RCX: 
[  249.952935] RDX: 0001 RSI: 0001 RDI: 88080aea
[  249.952938] RBP: c900031b3e98 R08: 0006 R09: 
[  249.952941] R10:  R11:  R12: 88080aea
[  249.952943] R13: 0005 R14: 839ca0c8 R15: 
[  249.952946]  
[  249.952955]  ? mwait_idle+0x93/0x3c0
[  249.952961]  arch_cpu_idle+0xa/0x10
[  249.952965]  default_idle_call+0x24/0x40
[  249.952971]  do_idle+0x154/0x1f0
[  249.952976]  cpu_startup_entry+0x18/0x20
[  249.952981]  start_secondary+0x159/0x1f0
[  249.952987]  secondary_startup_64+0x9f/0x9f
[  249.952995] Code: 0d 32 c7 9a e2 f7 ea 41 c1 fc 1f 48 8d 7b 60 c1
fa 06 44 29 e2 48 63 f2 48 01 ce e8 37 7d 1e e1 eb be 0f ff 5b 41 5c
41 5d 5d c3 <0f> ff eb b1 48 89 df e8 40 fe ff ff eb a7 41 0f b6 f4 48
c7 c7
[  249.953135] ---[ end trace 399ab7917ed3b208 ]---
[  251.185850] [ cut here ]
[  251.185896] WARNING: CPU: 5 PID: 4425 at
/home/ttrantal/git/linux/drivers/gpu/drm/drm_irq.c:1195
drm_vblank_put+0xc4/0x120 [drm]
[  251.185899] Modules linked in: fuse tun bridge stp llc af_packet
pl2303 usbserial shpchp acpi_cpufreq binfmt_misc amdgpu hid_generic
uhci_hcd radeon 3c59x mii tg3 ehci_pci ehci_hcd i2c_algo_bit
drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm
agpgart unix autofs4
[  251.185979] CPU: 5 PID: 4425 Comm: in:imjournal Tainted: GW
  4.11.0+ #4
[  251.185982] Hardware name: Hewlett-Packard HP xw6600
Workstation/0A9Ch, BIOS 786F4 v01.46 09/20/2012
[  251.185984] task: 880802f8b280 task.stack: c900034c8000
[  251.185998] RIP: 0010:drm_vblank_put+0xc4/0x120 [drm]
[  251.186001] RSP: :88080f003d70 EFLAGS: 00010046
[  251.186006] RAX:  RBX: 880801d53000 RCX: 
[  251.186009] RDX:  RSI:  RDI: 88080a4ac000
[  251.186012] RBP: 88080f003d88 R08: 0001 R09: 0003
[  251.186015] R10: 88080f003d08 R11: 001da540 R12: 88080a4ac000
[  251.186017] R13:  R14: 0086 R15: 8808019a
[  

Re: [PATCH] hwmon: (coretemp) Handle frozen hotplug state correctly

[Tommi Rantala]

2017-05-10 17:30 GMT+03:00 Thomas Gleixner <t...@linutronix.de>:
> The recent conversion to the hotplug state machine missed that the original
> hotplug notifiers did not execute in the frozen state, which is used on
> suspend on resume.
>
> This does not matter on single socket machines, but on multi socket systems
> this breaks when the device for a non-boot socket is removed when the last
> CPU of that socket is brought offline. The device removal locks up the
> machine hard w/o any debug output.
>
> Prevent executing the hotplug callbacks when cpuhp_tasks_frozen is true.
>
> Thanks to Tommi for providing debug information patiently while I failed to
> spot the obvious.
>
> Fixes: e00ca5df37ad ("hwmon: (coretemp) Convert to hotplug state machine")
> Reported-by: Tommi Rantala <tt.rant...@gmail.com>
> Signed-off-by: Thomas Gleixner <t...@linutronix.de>

Many thanks, I can confirm that it works well!

-Tommi

> ---
>  drivers/hwmon/coretemp.c |   14 ++
>  1 file changed, 14 insertions(+)
>
> --- a/drivers/hwmon/coretemp.c
> +++ b/drivers/hwmon/coretemp.c
> @@ -605,6 +605,13 @@ static int coretemp_cpu_online(unsigned
> struct platform_data *pdata;
>
> /*
> +* Don't execute this on resume as the offline callback did
> +* not get executed on suspend.
> +*/
> +   if (cpuhp_tasks_frozen)
> +   return 0;
> +
> +   /*
>  * CPUID.06H.EAX[0] indicates whether the CPU has thermal
>  * sensors. We check this bit only, all the early CPUs
>  * without thermal sensors will be filtered out.
> @@ -654,6 +661,13 @@ static int coretemp_cpu_offline(unsigned
> struct temp_data *tdata;
> int indx, target;
>
> +   /*
> +* Don't execute this on suspend as the device remove locks
> +* up the machine.
> +*/
> +   if (cpuhp_tasks_frozen)
> +   return 0;
> +
> /* If the physical CPU device does not exist, just return */
> if (!pdev)
> return 0;

Re: [PATCH] hwmon: (coretemp) Handle frozen hotplug state correctly

[Tommi Rantala]

2017-05-10 17:30 GMT+03:00 Thomas Gleixner :
> The recent conversion to the hotplug state machine missed that the original
> hotplug notifiers did not execute in the frozen state, which is used on
> suspend on resume.
>
> This does not matter on single socket machines, but on multi socket systems
> this breaks when the device for a non-boot socket is removed when the last
> CPU of that socket is brought offline. The device removal locks up the
> machine hard w/o any debug output.
>
> Prevent executing the hotplug callbacks when cpuhp_tasks_frozen is true.
>
> Thanks to Tommi for providing debug information patiently while I failed to
> spot the obvious.
>
> Fixes: e00ca5df37ad ("hwmon: (coretemp) Convert to hotplug state machine")
> Reported-by: Tommi Rantala 
> Signed-off-by: Thomas Gleixner 

Many thanks, I can confirm that it works well!

-Tommi

> ---
>  drivers/hwmon/coretemp.c |   14 ++
>  1 file changed, 14 insertions(+)
>
> --- a/drivers/hwmon/coretemp.c
> +++ b/drivers/hwmon/coretemp.c
> @@ -605,6 +605,13 @@ static int coretemp_cpu_online(unsigned
> struct platform_data *pdata;
>
> /*
> +* Don't execute this on resume as the offline callback did
> +* not get executed on suspend.
> +*/
> +   if (cpuhp_tasks_frozen)
> +   return 0;
> +
> +   /*
>  * CPUID.06H.EAX[0] indicates whether the CPU has thermal
>  * sensors. We check this bit only, all the early CPUs
>  * without thermal sensors will be filtered out.
> @@ -654,6 +661,13 @@ static int coretemp_cpu_offline(unsigned
> struct temp_data *tdata;
> int indx, target;
>
> +   /*
> +* Don't execute this on suspend as the device remove locks
> +* up the machine.
> +*/
> +   if (cpuhp_tasks_frozen)
> +   return 0;
> +
> /* If the physical CPU device does not exist, just return */
> if (!pdev)
> return 0;

Re: [patch 0/6] hwmon/coretemp: Hotplug fixes, cleanups and state machine conversion

[Tommi Rantala]

2017-05-10 17:01 GMT+03:00 Thomas Gleixner <t...@linutronix.de>:
> On Wed, 10 May 2017, Tommi Rantala wrote:
>> 2017-05-09 10:16 GMT+03:00 Thomas Gleixner <t...@linutronix.de>:
>> > On Thu, 4 May 2017, Tommi Rantala wrote:
>> >> Here's the trace output, does it help?
>> >
>> > Not much. Can you please try the following:
>> >
>> > 1) Offline all CPUs except CPU0 before suspend/resume
>>
>> it works!
>>
>> > 2) Offline all CPUs except CPU0 and CPU1 before suspend/resume
>>
>> now it breaks.
>>
>> > 3) Offline all CPUs except CPU0 and CPU2 before suspend/resume
>>
>> works again!
>>
>> (Also works with CPUs 0,2,4,6 onlined.)
>
> Output from /proc/cpuinfo please.

http://termbin.com/vec2

Re: [patch 0/6] hwmon/coretemp: Hotplug fixes, cleanups and state machine conversion

[Tommi Rantala]

2017-05-10 17:01 GMT+03:00 Thomas Gleixner :
> On Wed, 10 May 2017, Tommi Rantala wrote:
>> 2017-05-09 10:16 GMT+03:00 Thomas Gleixner :
>> > On Thu, 4 May 2017, Tommi Rantala wrote:
>> >> Here's the trace output, does it help?
>> >
>> > Not much. Can you please try the following:
>> >
>> > 1) Offline all CPUs except CPU0 before suspend/resume
>>
>> it works!
>>
>> > 2) Offline all CPUs except CPU0 and CPU1 before suspend/resume
>>
>> now it breaks.
>>
>> > 3) Offline all CPUs except CPU0 and CPU2 before suspend/resume
>>
>> works again!
>>
>> (Also works with CPUs 0,2,4,6 onlined.)
>
> Output from /proc/cpuinfo please.

http://termbin.com/vec2

Re: [patch 0/6] hwmon/coretemp: Hotplug fixes, cleanups and state machine conversion

[Tommi Rantala]

2017-05-09 10:16 GMT+03:00 Thomas Gleixner <t...@linutronix.de>:
> On Thu, 4 May 2017, Tommi Rantala wrote:
>> Here's the trace output, does it help?
>
> Not much. Can you please try the following:
>
> 1) Offline all CPUs except CPU0 before suspend/resume

it works!

> 2) Offline all CPUs except CPU0 and CPU1 before suspend/resume

now it breaks.

> 3) Offline all CPUs except CPU0 and CPU2 before suspend/resume

works again!

(Also works with CPUs 0,2,4,6 onlined.)

-Tommi

Re: [patch 0/6] hwmon/coretemp: Hotplug fixes, cleanups and state machine conversion

[Tommi Rantala]

2017-05-09 10:16 GMT+03:00 Thomas Gleixner :
> On Thu, 4 May 2017, Tommi Rantala wrote:
>> Here's the trace output, does it help?
>
> Not much. Can you please try the following:
>
> 1) Offline all CPUs except CPU0 before suspend/resume

it works!

> 2) Offline all CPUs except CPU0 and CPU1 before suspend/resume

now it breaks.

> 3) Offline all CPUs except CPU0 and CPU2 before suspend/resume

works again!

(Also works with CPUs 0,2,4,6 onlined.)

-Tommi

nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3

[Tommi Rantala]

Hi,

The HP ZBook 15 G3 laptop builtin display (eDP-1) does not work
correctly with v4.11-11413-g2868b25.

When booting the laptop, the resolution seems to be limited to
1024x768, and gnome-session segfaults.

Up to 4.11 the display works just fine in 1920x1080 mode.

I'm seeing this in the kernel logs:

nouveau :01:00.0: eDP-1: EDID is invalid:
[00] BAD  00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
[00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff 84 53 54
[00] BAD  66 69 50 55 57 66 74 49 48 ff ff ff ff ff ff ff
[00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[00] BAD  ff ff ff ff ff ff ff ff ff ff ff 00 00 ff 00 ff
nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1
[drm] Cannot find any crtc or sizes - going 1024x768


$ lspci | grep NVIDIA
01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro
M2000M] (rev a2)

Any ideas, or should I bisect?

4.11 dmesg & xrandr output:
https://pastebin.com/raw/P9LGP7e1

4.11-11413-g2868b25 dmesg:
https://pastebin.com/raw/QBT9mMua

-Tommi

nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3

[Tommi Rantala]

Hi,

The HP ZBook 15 G3 laptop builtin display (eDP-1) does not work
correctly with v4.11-11413-g2868b25.

When booting the laptop, the resolution seems to be limited to
1024x768, and gnome-session segfaults.

Up to 4.11 the display works just fine in 1920x1080 mode.

I'm seeing this in the kernel logs:

nouveau :01:00.0: eDP-1: EDID is invalid:
[00] BAD  00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
[00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff 84 53 54
[00] BAD  66 69 50 55 57 66 74 49 48 ff ff ff ff ff ff ff
[00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[00] BAD  ff ff ff ff ff ff ff ff ff ff ff 00 00 ff 00 ff
nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1
[drm] Cannot find any crtc or sizes - going 1024x768


$ lspci | grep NVIDIA
01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro
M2000M] (rev a2)

Any ideas, or should I bisect?

4.11 dmesg & xrandr output:
https://pastebin.com/raw/P9LGP7e1

4.11-11413-g2868b25 dmesg:
https://pastebin.com/raw/QBT9mMua

-Tommi

Re: [patch 0/6] hwmon/coretemp: Hotplug fixes, cleanups and state machine conversion

[Tommi Rantala]

2017-04-23 18:01 GMT+03:00 Thomas Gleixner <t...@linutronix.de>:
> On Sat, 15 Apr 2017, Tommi Rantala wrote:
>
>> Testing with 4.10.8-200.fc25.x86_64: freezer, devices and platform are
>> OK, it breaks at "processors".
>> The screen stays off, and the machine no longer answers to ping.
>>
>> (Without coretemp loaded, the machine survives all the states. There
>> are some graphics glitches and radeon error messages)
>
> That's odd. I tried on a similar machine (w/o a radeon card) and it just
> works with the coretemp module loaded.
>
> Can you please do a CPU hotplug cycle (just one CPU) with the cpuhp events
> in the tracer enabled. Send me the trace output so I might be able to spot
> whats different and what interdependencies between other callbacks might be
> there.

Hi,

Here's the trace output, does it help?

http://termbin.com/qugr

-Tommi

Re: [patch 0/6] hwmon/coretemp: Hotplug fixes, cleanups and state machine conversion

[Tommi Rantala]

2017-04-23 18:01 GMT+03:00 Thomas Gleixner :
> On Sat, 15 Apr 2017, Tommi Rantala wrote:
>
>> Testing with 4.10.8-200.fc25.x86_64: freezer, devices and platform are
>> OK, it breaks at "processors".
>> The screen stays off, and the machine no longer answers to ping.
>>
>> (Without coretemp loaded, the machine survives all the states. There
>> are some graphics glitches and radeon error messages)
>
> That's odd. I tried on a similar machine (w/o a radeon card) and it just
> works with the coretemp module loaded.
>
> Can you please do a CPU hotplug cycle (just one CPU) with the cpuhp events
> in the tracer enabled. Send me the trace output so I might be able to spot
> whats different and what interdependencies between other callbacks might be
> there.

Hi,

Here's the trace output, does it help?

http://termbin.com/qugr

-Tommi

Re: [patch 0/6] hwmon/coretemp: Hotplug fixes, cleanups and state machine conversion

[Tommi Rantala]

2017-04-14 20:35 GMT+03:00 Thomas Gleixner :
> On Wed, 12 Apr 2017, Thomas Gleixner wrote:
>>
>> Can you please try the following:
>>
>> # for STATE in freezer devices platform processors core; do \
>>   echo $STATE; \
>>   echo $STATE >/sys/power/pm_test; \
>>   echo mem >/sys/power/state
>>
>> That should give us at least a hint in which area to dig.
>
> Any news on that?

Sorry, was traveling.

Testing with 4.10.8-200.fc25.x86_64: freezer, devices and platform are
OK, it breaks at "processors".
The screen stays off, and the machine no longer answers to ping.

(Without coretemp loaded, the machine survives all the states. There
are some graphics glitches and radeon error messages)

-Tommi

Re: [patch 0/6] hwmon/coretemp: Hotplug fixes, cleanups and state machine conversion

[Tommi Rantala]

2017-04-14 20:35 GMT+03:00 Thomas Gleixner :
> On Wed, 12 Apr 2017, Thomas Gleixner wrote:
>>
>> Can you please try the following:
>>
>> # for STATE in freezer devices platform processors core; do \
>>   echo $STATE; \
>>   echo $STATE >/sys/power/pm_test; \
>>   echo mem >/sys/power/state
>>
>> That should give us at least a hint in which area to dig.
>
> Any news on that?

Sorry, was traveling.

Testing with 4.10.8-200.fc25.x86_64: freezer, devices and platform are
OK, it breaks at "processors".
The screen stays off, and the machine no longer answers to ping.

(Without coretemp loaded, the machine survives all the states. There
are some graphics glitches and radeon error messages)

-Tommi

Re: [patch 0/6] hwmon/coretemp: Hotplug fixes, cleanups and state machine conversion

[Tommi Rantala]

2017-04-12 13:52 GMT+03:00 Thomas Gleixner <t...@linutronix.de>:
> On Wed, 12 Apr 2017, Tommi Rantala wrote:
>> 2017-04-12 12:28 GMT+03:00 Thomas Gleixner <t...@linutronix.de>:
>> > On Wed, 12 Apr 2017, Tommi Rantala wrote:
>> >> Resume-from-suspend stopped working in HP xw6600 in fedora kernel
>> >> 4.10.8-200.fc25.x86_64, while it worked just fine in
>> >> 4.9.9-200.fc25.x86_64.
>> >>
>> >> When powering on the suspended PC, there is no video output, and to
>> >> recover, I need to reset the machine.
>> >
>> > Is there just no video output or is the machine completely frozen? If it's
>> > not completely dead, then you might be able to ssh into it.
>>
>> It's completely hosed: not possible to ssh, does not respond to ping either.
>>
>> I made a quick test with netconsole. After booting with
>> no_console_suspend=1, and setting the netconsole parameters, I can get
>> kernel messages (to my android phone) when suspending the machine. But
>> no messages after the failed resume.
>
> Let's do something else first.
>
> Can you please try to offline/online CPUs from the console?
>
> # echo 0 >/sys/devices/system/cpu1/online
> # echo 1 >/sys/devices/system/cpu1/online

ok, that works.

> If that works, then try to offline all CPUs (except 0) in the same order as
> suspend (1 ... 7) and then online them again in the same order?

Seems to work without problems:

# for i in $(seq 1 7) ; do echo 0 > /sys/devices/system/cpu/cpu$i/online ; done

[ 1237.317537] intel_powerclamp: No package C-state available
[ 1308.997620] smpboot: CPU 1 is now offline
[ 1309.007167] intel_powerclamp: No package C-state available
[ 1309.032563] smpboot: CPU 2 is now offline
[ 1309.038118] intel_powerclamp: No package C-state available
[ 1309.072495] smpboot: CPU 3 is now offline
[ 1309.077807] intel_powerclamp: No package C-state available
[ 1309.099545] Broke affinity for irq 29
[ 1309.100587] smpboot: CPU 4 is now offline
[ 1309.105346] intel_powerclamp: No package C-state available
[ 1309.135530] Broke affinity for irq 22
[ 1309.135540] Broke affinity for irq 29
[ 1309.136579] smpboot: CPU 5 is now offline
[ 1309.141653] intel_powerclamp: No package C-state available
[ 1309.171517] Broke affinity for irq 22
[ 1309.171526] Broke affinity for irq 29
[ 1309.171535] Broke affinity for irq 31
[ 1309.172586] smpboot: CPU 6 is now offline
[ 1309.176967] intel_powerclamp: No package C-state available
[ 1309.209122] Broke affinity for irq 19
[ 1309.209126] Broke affinity for irq 22
[ 1309.209135] Broke affinity for irq 29
[ 1309.209145] Broke affinity for irq 31
[ 1309.212071] smpboot: CPU 7 is now offline


# for i in $(seq 1 7) ; do echo 1 > /sys/devices/system/cpu/cpu$i/online ; done

[ 1309.217476] intel_powerclamp: No package C-state available
[ 1380.624184] x86: Booting SMP configuration:
[ 1380.624186] smpboot: Booting Node 0 Processor 1 APIC 0x4
[ 1380.659810] intel_powerclamp: No package C-state available
[ 1380.659957] smpboot: Booting Node 0 Processor 2 APIC 0x2
[ 1380.671198] microcode: sig=0x10676, pf=0x40, revision=0x60f
[ 1380.672088] smpboot: Booting Node 0 Processor 3 APIC 0x6
[ 1380.677952] intel_powerclamp: No package C-state available
[ 1380.686260] microcode: sig=0x1067a, pf=0x40, revision=0xa0b
[ 1380.687098] smpboot: Booting Node 0 Processor 4 APIC 0x1
[ 1380.699214] microcode: sig=0x10676, pf=0x40, revision=0x60f
[ 1380.699742] intel_powerclamp: No package C-state available
[ 1380.700267] smpboot: Booting Node 0 Processor 5 APIC 0x5
[ 1380.715207] microcode: sig=0x1067a, pf=0x40, revision=0xa0b
[ 1380.716202] smpboot: Booting Node 0 Processor 6 APIC 0x3
[ 1380.730264] microcode: sig=0x10676, pf=0x40, revision=0x60f
[ 1380.730567] intel_powerclamp: No package C-state available
[ 1380.731267] smpboot: Booting Node 0 Processor 7 APIC 0x7
[ 1380.748276] microcode: sig=0x1067a, pf=0x40, revision=0xa0b

Re: [patch 0/6] hwmon/coretemp: Hotplug fixes, cleanups and state machine conversion

[Tommi Rantala]

2017-04-12 13:52 GMT+03:00 Thomas Gleixner :
> On Wed, 12 Apr 2017, Tommi Rantala wrote:
>> 2017-04-12 12:28 GMT+03:00 Thomas Gleixner :
>> > On Wed, 12 Apr 2017, Tommi Rantala wrote:
>> >> Resume-from-suspend stopped working in HP xw6600 in fedora kernel
>> >> 4.10.8-200.fc25.x86_64, while it worked just fine in
>> >> 4.9.9-200.fc25.x86_64.
>> >>
>> >> When powering on the suspended PC, there is no video output, and to
>> >> recover, I need to reset the machine.
>> >
>> > Is there just no video output or is the machine completely frozen? If it's
>> > not completely dead, then you might be able to ssh into it.
>>
>> It's completely hosed: not possible to ssh, does not respond to ping either.
>>
>> I made a quick test with netconsole. After booting with
>> no_console_suspend=1, and setting the netconsole parameters, I can get
>> kernel messages (to my android phone) when suspending the machine. But
>> no messages after the failed resume.
>
> Let's do something else first.
>
> Can you please try to offline/online CPUs from the console?
>
> # echo 0 >/sys/devices/system/cpu1/online
> # echo 1 >/sys/devices/system/cpu1/online

ok, that works.

> If that works, then try to offline all CPUs (except 0) in the same order as
> suspend (1 ... 7) and then online them again in the same order?

Seems to work without problems:

# for i in $(seq 1 7) ; do echo 0 > /sys/devices/system/cpu/cpu$i/online ; done

[ 1237.317537] intel_powerclamp: No package C-state available
[ 1308.997620] smpboot: CPU 1 is now offline
[ 1309.007167] intel_powerclamp: No package C-state available
[ 1309.032563] smpboot: CPU 2 is now offline
[ 1309.038118] intel_powerclamp: No package C-state available
[ 1309.072495] smpboot: CPU 3 is now offline
[ 1309.077807] intel_powerclamp: No package C-state available
[ 1309.099545] Broke affinity for irq 29
[ 1309.100587] smpboot: CPU 4 is now offline
[ 1309.105346] intel_powerclamp: No package C-state available
[ 1309.135530] Broke affinity for irq 22
[ 1309.135540] Broke affinity for irq 29
[ 1309.136579] smpboot: CPU 5 is now offline
[ 1309.141653] intel_powerclamp: No package C-state available
[ 1309.171517] Broke affinity for irq 22
[ 1309.171526] Broke affinity for irq 29
[ 1309.171535] Broke affinity for irq 31
[ 1309.172586] smpboot: CPU 6 is now offline
[ 1309.176967] intel_powerclamp: No package C-state available
[ 1309.209122] Broke affinity for irq 19
[ 1309.209126] Broke affinity for irq 22
[ 1309.209135] Broke affinity for irq 29
[ 1309.209145] Broke affinity for irq 31
[ 1309.212071] smpboot: CPU 7 is now offline


# for i in $(seq 1 7) ; do echo 1 > /sys/devices/system/cpu/cpu$i/online ; done

[ 1309.217476] intel_powerclamp: No package C-state available
[ 1380.624184] x86: Booting SMP configuration:
[ 1380.624186] smpboot: Booting Node 0 Processor 1 APIC 0x4
[ 1380.659810] intel_powerclamp: No package C-state available
[ 1380.659957] smpboot: Booting Node 0 Processor 2 APIC 0x2
[ 1380.671198] microcode: sig=0x10676, pf=0x40, revision=0x60f
[ 1380.672088] smpboot: Booting Node 0 Processor 3 APIC 0x6
[ 1380.677952] intel_powerclamp: No package C-state available
[ 1380.686260] microcode: sig=0x1067a, pf=0x40, revision=0xa0b
[ 1380.687098] smpboot: Booting Node 0 Processor 4 APIC 0x1
[ 1380.699214] microcode: sig=0x10676, pf=0x40, revision=0x60f
[ 1380.699742] intel_powerclamp: No package C-state available
[ 1380.700267] smpboot: Booting Node 0 Processor 5 APIC 0x5
[ 1380.715207] microcode: sig=0x1067a, pf=0x40, revision=0xa0b
[ 1380.716202] smpboot: Booting Node 0 Processor 6 APIC 0x3
[ 1380.730264] microcode: sig=0x10676, pf=0x40, revision=0x60f
[ 1380.730567] intel_powerclamp: No package C-state available
[ 1380.731267] smpboot: Booting Node 0 Processor 7 APIC 0x7
[ 1380.748276] microcode: sig=0x1067a, pf=0x40, revision=0xa0b

Re: [patch 0/6] hwmon/coretemp: Hotplug fixes, cleanups and state machine conversion

[Tommi Rantala]

2017-04-12 12:28 GMT+03:00 Thomas Gleixner <t...@linutronix.de>:
> On Wed, 12 Apr 2017, Tommi Rantala wrote:
>> Resume-from-suspend stopped working in HP xw6600 in fedora kernel
>> 4.10.8-200.fc25.x86_64, while it worked just fine in
>> 4.9.9-200.fc25.x86_64.
>>
>> When powering on the suspended PC, there is no video output, and to
>> recover, I need to reset the machine.
>
> Is there just no video output or is the machine completely frozen? If it's
> not completely dead, then you might be able to ssh into it.

It's completely hosed: not possible to ssh, does not respond to ping either.

I made a quick test with netconsole. After booting with
no_console_suspend=1, and setting the netconsole parameters, I can get
kernel messages (to my android phone) when suspending the machine. But
no messages after the failed resume.

Hmm, might I be able to capture messages over USB serial port...?

-Tommi

Re: [patch 0/6] hwmon/coretemp: Hotplug fixes, cleanups and state machine conversion

[Tommi Rantala]

2017-04-12 12:28 GMT+03:00 Thomas Gleixner :
> On Wed, 12 Apr 2017, Tommi Rantala wrote:
>> Resume-from-suspend stopped working in HP xw6600 in fedora kernel
>> 4.10.8-200.fc25.x86_64, while it worked just fine in
>> 4.9.9-200.fc25.x86_64.
>>
>> When powering on the suspended PC, there is no video output, and to
>> recover, I need to reset the machine.
>
> Is there just no video output or is the machine completely frozen? If it's
> not completely dead, then you might be able to ssh into it.

It's completely hosed: not possible to ssh, does not respond to ping either.

I made a quick test with netconsole. After booting with
no_console_suspend=1, and setting the netconsole parameters, I can get
kernel messages (to my android phone) when suspending the machine. But
no messages after the failed resume.

Hmm, might I be able to capture messages over USB serial port...?

-Tommi

Re: [patch 0/6] hwmon/coretemp: Hotplug fixes, cleanups and state machine conversion

[Tommi Rantala]

2016-11-23 17:28 GMT+02:00 Guenter Roeck :
>
> On 11/22/2016 09:42 AM, Thomas Gleixner wrote:
>>
>> After the first attempt to convert the coretemp driver to the hotplug state
>> machine failed, we had a deeper look and went a bit farther.
>>
>> The driver has quite some interesting concepts vs. the package, core and
>> sysfs file management and a bug in the package temperature sysfs interface
>> vs. cpu hotplug.
>>
>> The following series fixes that bug and simplifies the package/core
>> management and at the end converts it to the hotplug state machine.
>>
>> Along with the source size the binary size shrinks as well:
>>textdata bss dec hex
>>4068360   20 4448 1160 Before
>>3801180   364017 fb1   After
>>
>> Thanks,
>>
>> tglx
>> -
>>  coretemp.c |  321 
>> +
>>  1 file changed, 113 insertions(+), 208 deletions(-)

Hi,

Resume-from-suspend stopped working in HP xw6600 in fedora kernel
4.10.8-200.fc25.x86_64, while it worked just fine in
4.9.9-200.fc25.x86_64.

When powering on the suspended PC, there is no video output, and to
recover, I need to reset the machine.
Nothing is recorded in the journal logs for the resume, last lines are
from the suspend:

  Apr 08 15:41:49 xw6600 systemd[1]: Reached target Sleep.
  Apr 08 15:41:49 xw6600 systemd[1]: Starting Suspend...
  Apr 08 15:41:49 xw6600 systemd-sleep[6675]: Suspending system...

Also tested 4.11-rc5, but it fails the same way.

Bisection leads to commit:

commit e00ca5df37adc68052ea699cbd010ee4e19e39e4
Author: Thomas Gleixner 
Date:   Tue Nov 22 17:42:04 2016 +

hwmon: (coretemp) Convert to hotplug state machine

Install the callbacks via the state machine. Setup and teardown are handled
by the hotplug core.

Signed-off-by: Sebastian Andrzej Siewior 
Cc: linux-hw...@vger.kernel.org
Cc: Fenghua Yu 
Cc: Jean Delvare 
Cc: r...@linuxtronix.de
Cc: Guenter Roeck 
Link: http://lkml.kernel.org/r/20161117183541.8588-5-bige...@linutronix.de
Signed-off-by: Guenter Roeck 

If I do "modprobe -r coretemp", then the resume works OK with
4.10.8-200.fc25.x86_64.

Any ideas?

4.9.9-200.fc25.x86_64 dmesg:
http://termbin.com/3kcl

4.10.8-200.fc25.x86_64 dmesg:
http://termbin.com/62d9

-Tommi

Re: [patch 0/6] hwmon/coretemp: Hotplug fixes, cleanups and state machine conversion

[Tommi Rantala]

2016-11-23 17:28 GMT+02:00 Guenter Roeck :
>
> On 11/22/2016 09:42 AM, Thomas Gleixner wrote:
>>
>> After the first attempt to convert the coretemp driver to the hotplug state
>> machine failed, we had a deeper look and went a bit farther.
>>
>> The driver has quite some interesting concepts vs. the package, core and
>> sysfs file management and a bug in the package temperature sysfs interface
>> vs. cpu hotplug.
>>
>> The following series fixes that bug and simplifies the package/core
>> management and at the end converts it to the hotplug state machine.
>>
>> Along with the source size the binary size shrinks as well:
>>textdata bss dec hex
>>4068360   20 4448 1160 Before
>>3801180   364017 fb1   After
>>
>> Thanks,
>>
>> tglx
>> -
>>  coretemp.c |  321 
>> +
>>  1 file changed, 113 insertions(+), 208 deletions(-)

Hi,

Resume-from-suspend stopped working in HP xw6600 in fedora kernel
4.10.8-200.fc25.x86_64, while it worked just fine in
4.9.9-200.fc25.x86_64.

When powering on the suspended PC, there is no video output, and to
recover, I need to reset the machine.
Nothing is recorded in the journal logs for the resume, last lines are
from the suspend:

  Apr 08 15:41:49 xw6600 systemd[1]: Reached target Sleep.
  Apr 08 15:41:49 xw6600 systemd[1]: Starting Suspend...
  Apr 08 15:41:49 xw6600 systemd-sleep[6675]: Suspending system...

Also tested 4.11-rc5, but it fails the same way.

Bisection leads to commit:

commit e00ca5df37adc68052ea699cbd010ee4e19e39e4
Author: Thomas Gleixner 
Date:   Tue Nov 22 17:42:04 2016 +

hwmon: (coretemp) Convert to hotplug state machine

Install the callbacks via the state machine. Setup and teardown are handled
by the hotplug core.

Signed-off-by: Sebastian Andrzej Siewior 
Cc: linux-hw...@vger.kernel.org
Cc: Fenghua Yu 
Cc: Jean Delvare 
Cc: r...@linuxtronix.de
Cc: Guenter Roeck 
Link: http://lkml.kernel.org/r/20161117183541.8588-5-bige...@linutronix.de
Signed-off-by: Guenter Roeck 

If I do "modprobe -r coretemp", then the resume works OK with
4.10.8-200.fc25.x86_64.

Any ideas?

4.9.9-200.fc25.x86_64 dmesg:
http://termbin.com/3kcl

4.10.8-200.fc25.x86_64 dmesg:
http://termbin.com/62d9

-Tommi

Re: [RFC][PATCH] mm: Tighten x86 /dev/mem with zeroing

[Tommi Rantala]

On 06.04.2017 03:00, Kees Cook wrote:

This changes the x86 exception for the low 1MB by reading back zeros for
RAM areas instead of blindly allowing them. (It may be possible for heap
to end up getting allocated in low 1MB RAM, and then read out, possibly
tripping hardened usercopy.)

Unfinished: this still needs mmap support.

Reported-by: Tommi Rantala <tommi.t.rant...@nokia.com>
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
Tommi, can you check and see if this fixes what you're seeing? I want to
make sure this actually works first. (x86info uses seek/read not mmap.)


Hi, I can confirm that it works (after adding CONFIG_STRICT_DEVMEM), no 
more kernel bugs when running x86info.



open("/dev/mem", O_RDONLY)  = 3
lseek(3, 1038, SEEK_SET)= 1038
read(3, "\300\235", 2)  = 2
lseek(3, 646144, SEEK_SET)  = 646144
read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1024) = 1024

lseek(3, 1043, SEEK_SET)= 1043
read(3, "w\2", 2)   = 2
lseek(3, 645120, SEEK_SET)  = 645120
read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1024) = 1024

lseek(3, 654336, SEEK_SET)  = 654336
read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1024) = 1024

lseek(3, 983040, SEEK_SET)  = 983040
read(3, 
"IFE$\245S\0\0\1\0\0\0\0\360y\0\0\360\220\260\30\237{=\23\10\17\\276\17\0"..., 
65536) = 65536

lseek(3, 917504, SEEK_SET)  = 917504
read(3, 
"\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 
65536) = 65536

lseek(3, 524288, SEEK_SET)  = 524288
read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
65536) = 65536

lseek(3, 589824, SEEK_SET)  = 589824
read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
65536) = 65536



dd works too:

# LANG=C dd if=/dev/mem of=/dev/null bs=4096 count=256
256+0 records in
256+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0874073 s, 12.0 MB/s



---

 arch/x86/mm/init.c | 41 +++
 drivers/char/mem.c | 82 ++
 2 files changed, 82 insertions(+), 41 deletions(-)

Re: [RFC][PATCH] mm: Tighten x86 /dev/mem with zeroing

[Tommi Rantala]

On 06.04.2017 03:00, Kees Cook wrote:

This changes the x86 exception for the low 1MB by reading back zeros for
RAM areas instead of blindly allowing them. (It may be possible for heap
to end up getting allocated in low 1MB RAM, and then read out, possibly
tripping hardened usercopy.)

Unfinished: this still needs mmap support.

Reported-by: Tommi Rantala 
Signed-off-by: Kees Cook 
---
Tommi, can you check and see if this fixes what you're seeing? I want to
make sure this actually works first. (x86info uses seek/read not mmap.)


Hi, I can confirm that it works (after adding CONFIG_STRICT_DEVMEM), no 
more kernel bugs when running x86info.



open("/dev/mem", O_RDONLY)  = 3
lseek(3, 1038, SEEK_SET)= 1038
read(3, "\300\235", 2)  = 2
lseek(3, 646144, SEEK_SET)  = 646144
read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1024) = 1024

lseek(3, 1043, SEEK_SET)= 1043
read(3, "w\2", 2)   = 2
lseek(3, 645120, SEEK_SET)  = 645120
read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1024) = 1024

lseek(3, 654336, SEEK_SET)  = 654336
read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1024) = 1024

lseek(3, 983040, SEEK_SET)  = 983040
read(3, 
"IFE$\245S\0\0\1\0\0\0\0\360y\0\0\360\220\260\30\237{=\23\10\17\\276\17\0"..., 
65536) = 65536

lseek(3, 917504, SEEK_SET)  = 917504
read(3, 
"\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 
65536) = 65536

lseek(3, 524288, SEEK_SET)  = 524288
read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
65536) = 65536

lseek(3, 589824, SEEK_SET)  = 589824
read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
65536) = 65536



dd works too:

# LANG=C dd if=/dev/mem of=/dev/null bs=4096 count=256
256+0 records in
256+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0874073 s, 12.0 MB/s



---

 arch/x86/mm/init.c | 41 +++
 drivers/char/mem.c | 82 ++
 2 files changed, 82 insertions(+), 41 deletions(-)

Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78!

[Tommi Rantala]

On 31.03.2017 21:26, Linus Torvalds wrote:

Hmm. Thinking more about this, we do allow access to the first 1MB of
physical memory unconditionally (see devmem_is_allowed() in
arch/x86/mm/init.c). And I think we only _reserve_ the first 64kB or
something. So I guess even STRICT_DEVMEM isn't actually all that
strict.

So this should be visible even *with* STRICT_DEVMEM.

Does a simple

 sudo dd if=/dev/mem of=/dev/null bs=4096 count=256

also show the same issue? Maybe regardless of STRICT_DEVMEM?


Yep, it is enough to trigger the bug.

Also crashes with the fedora kernel that has STRICT_DEVMEM:

$ sudo dd if=/dev/mem of=/dev/null bs=4096 count=256
Segmentation fault

[   73.224025] usercopy: kernel memory exposure attempt detected from 
893a80059000 (dma-kmalloc-16) (4096 bytes)

[   73.224049] [ cut here ]
[   73.224056] kernel BUG at mm/usercopy.c:75!
[   73.224060] invalid opcode:  [#1] SMP
[   73.224237] CPU: 5 PID: 2860 Comm: dd Not tainted 
4.9.14-200.fc25.x86_64 #1




Maybe we should change devmem_is_allowed() to return a ternary value,
and then have it be "allow access" (for reserved pages), "disallow
access" (for various random stuff), and "just read zero" (for pages in
the low 1M that aren't marked reserved).

That way things like that read the low 1M (like x86info) will
hopefully not be unhappy, but also won't be reading random kernel
data.

  Linus

Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78!

[Tommi Rantala]

On 31.03.2017 21:26, Linus Torvalds wrote:

Hmm. Thinking more about this, we do allow access to the first 1MB of
physical memory unconditionally (see devmem_is_allowed() in
arch/x86/mm/init.c). And I think we only _reserve_ the first 64kB or
something. So I guess even STRICT_DEVMEM isn't actually all that
strict.

So this should be visible even *with* STRICT_DEVMEM.

Does a simple

 sudo dd if=/dev/mem of=/dev/null bs=4096 count=256

also show the same issue? Maybe regardless of STRICT_DEVMEM?


Yep, it is enough to trigger the bug.

Also crashes with the fedora kernel that has STRICT_DEVMEM:

$ sudo dd if=/dev/mem of=/dev/null bs=4096 count=256
Segmentation fault

[   73.224025] usercopy: kernel memory exposure attempt detected from 
893a80059000 (dma-kmalloc-16) (4096 bytes)

[   73.224049] [ cut here ]
[   73.224056] kernel BUG at mm/usercopy.c:75!
[   73.224060] invalid opcode:  [#1] SMP
[   73.224237] CPU: 5 PID: 2860 Comm: dd Not tainted 
4.9.14-200.fc25.x86_64 #1




Maybe we should change devmem_is_allowed() to return a ternary value,
and then have it be "allow access" (for reserved pages), "disallow
access" (for various random stuff), and "just read zero" (for pages in
the low 1M that aren't marked reserved).

That way things like that read the low 1M (like x86info) will
hopefully not be unhappy, but also won't be reading random kernel
data.

  Linus

Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78!

[Tommi Rantala]

On 31.03.2017 08:40, Tommi Rantala wrote:

The only thing that I can think of would be a rogue ptr in the bios
table, but that seems unlikely.  Tommi, can you put strace of x86info
-mp somewhere?
That will confirm/deny whether we're at least asking the kernel to do
sane things.


Indeed the bug happens when reading from /dev/mem:

https://pastebin.com/raw/ZEJGQP1X

# strace -f -y x86info -mp
[...]
open("/dev/mem", O_RDONLY)  = 3
lseek(3, 1038, SEEK_SET)  = 1038
read(3, "\300\235", 2)= 2
lseek(3, 646144, SEEK_SET)= 646144
read(3,
"\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1024) = 1024
lseek(3, 1043, SEEK_SET)  = 1043
read(3, "w\2", 2) = 2
lseek(3, 645120, SEEK_SET)= 645120
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1024) = 1024
lseek(3, 654336, SEEK_SET)= 654336
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1024) = 1024
lseek(3, 983040, SEEK_SET)= 983040
read(3,
"IFE$\245S\0\0\1\0\0\0\0\360y\0\0\360\220\260\30\237{=\23\10\17\\276\17\0"...,
65536) = 65536
lseek(3, 917504, SEEK_SET)= 917504
read(3,
"\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"...,
65536) = 65536
lseek(3, 524288, SEEK_SET)= 524288
read(3,  )= ?
+++ killed by SIGSEGV +++


That last read is done in mptable.c:347, trying to read GROPE_AREA1.

# ./x86info --debug
x86info v1.31pre
get_intel_topology:
Siblings: 2
Physical Processor ID: 0
Processor Core ID: 0
get_intel_topology:
Siblings: 2
Physical Processor ID: 0
Processor Core ID: 1
get_intel_topology:
Siblings: 2
Physical Processor ID: 0
Processor Core ID: 2
get_intel_topology:
Siblings: 2
Physical Processor ID: 0
Processor Core ID: 3
get_intel_topology:
Siblings: 2
Physical Processor ID: 0
Processor Core ID: 0
get_intel_topology:
Siblings: 2
Physical Processor ID: 0
Processor Core ID: 1
get_intel_topology:
Siblings: 2
Physical Processor ID: 0
Processor Core ID: 2
get_intel_topology:
Siblings: 2
Physical Processor ID: 0
Processor Core ID: 3
Found 8 identical CPUs
EBDA points to: 9dc0
EBDA segment ptr: 9dc00
Segmentation fault


If I comment out the GROPE_AREA1 read, the same kernel bug still happens 
with the GROPE_AREA2 read.


Removing both GROPE_AREA1 and GROPE_AREA2 reads avoids the crash:

$ git diff
diff --git a/mptable.c b/mptable.c
index 480f19b..00fff35 100644
--- a/mptable.c
+++ b/mptable.c
@@ -342,6 +342,7 @@ static int apic_probe(unsigned long* paddr)
}

/* search additional memory */
+   /*
target = GROPE_AREA1;
seekEntry(target);
if (readEntry(buffer, GROPE_SIZE)) {
@@ -371,6 +372,7 @@ static int apic_probe(unsigned long* paddr)
return 6;
}
}
+   */

*paddr = (unsigned long)0;
return 0;

# ./x86info -mp
x86info v1.31pre
Found 8 identical CPUs
Extended Family: 0 Extended Model: 5 Family: 6 Model: 94 Stepping: 3
Type: 0 (Original OEM)
CPU Model (x86info's best guess): Unknown model.
Processor name string (BIOS programmed): Intel(R) Core(TM) i7-6820HQ CPU 
@ 2.70GHz


Total processor threads: 8
This system has 1 quad-core processor with hyper-threading (2 threads 
per core) running at an estimated 2.70GHz

#

-Tommi

Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78!

[Tommi Rantala]

On 31.03.2017 08:40, Tommi Rantala wrote:

The only thing that I can think of would be a rogue ptr in the bios
table, but that seems unlikely.  Tommi, can you put strace of x86info
-mp somewhere?
That will confirm/deny whether we're at least asking the kernel to do
sane things.


Indeed the bug happens when reading from /dev/mem:

https://pastebin.com/raw/ZEJGQP1X

# strace -f -y x86info -mp
[...]
open("/dev/mem", O_RDONLY)  = 3
lseek(3, 1038, SEEK_SET)  = 1038
read(3, "\300\235", 2)= 2
lseek(3, 646144, SEEK_SET)= 646144
read(3,
"\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1024) = 1024
lseek(3, 1043, SEEK_SET)  = 1043
read(3, "w\2", 2) = 2
lseek(3, 645120, SEEK_SET)= 645120
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1024) = 1024
lseek(3, 654336, SEEK_SET)= 654336
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1024) = 1024
lseek(3, 983040, SEEK_SET)= 983040
read(3,
"IFE$\245S\0\0\1\0\0\0\0\360y\0\0\360\220\260\30\237{=\23\10\17\\276\17\0"...,
65536) = 65536
lseek(3, 917504, SEEK_SET)= 917504
read(3,
"\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"...,
65536) = 65536
lseek(3, 524288, SEEK_SET)= 524288
read(3,  )= ?
+++ killed by SIGSEGV +++


That last read is done in mptable.c:347, trying to read GROPE_AREA1.

# ./x86info --debug
x86info v1.31pre
get_intel_topology:
Siblings: 2
Physical Processor ID: 0
Processor Core ID: 0
get_intel_topology:
Siblings: 2
Physical Processor ID: 0
Processor Core ID: 1
get_intel_topology:
Siblings: 2
Physical Processor ID: 0
Processor Core ID: 2
get_intel_topology:
Siblings: 2
Physical Processor ID: 0
Processor Core ID: 3
get_intel_topology:
Siblings: 2
Physical Processor ID: 0
Processor Core ID: 0
get_intel_topology:
Siblings: 2
Physical Processor ID: 0
Processor Core ID: 1
get_intel_topology:
Siblings: 2
Physical Processor ID: 0
Processor Core ID: 2
get_intel_topology:
Siblings: 2
Physical Processor ID: 0
Processor Core ID: 3
Found 8 identical CPUs
EBDA points to: 9dc0
EBDA segment ptr: 9dc00
Segmentation fault


If I comment out the GROPE_AREA1 read, the same kernel bug still happens 
with the GROPE_AREA2 read.


Removing both GROPE_AREA1 and GROPE_AREA2 reads avoids the crash:

$ git diff
diff --git a/mptable.c b/mptable.c
index 480f19b..00fff35 100644
--- a/mptable.c
+++ b/mptable.c
@@ -342,6 +342,7 @@ static int apic_probe(unsigned long* paddr)
}

/* search additional memory */
+   /*
target = GROPE_AREA1;
seekEntry(target);
if (readEntry(buffer, GROPE_SIZE)) {
@@ -371,6 +372,7 @@ static int apic_probe(unsigned long* paddr)
return 6;
}
}
+   */

*paddr = (unsigned long)0;
return 0;

# ./x86info -mp
x86info v1.31pre
Found 8 identical CPUs
Extended Family: 0 Extended Model: 5 Family: 6 Model: 94 Stepping: 3
Type: 0 (Original OEM)
CPU Model (x86info's best guess): Unknown model.
Processor name string (BIOS programmed): Intel(R) Core(TM) i7-6820HQ CPU 
@ 2.70GHz


Total processor threads: 8
This system has 1 quad-core processor with hyper-threading (2 threads 
per core) running at an estimated 2.70GHz

#

-Tommi

Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78!

[Tommi Rantala]

On 30.03.2017 20:44, Laura Abbott wrote:

On 03/30/2017 10:37 AM, Kees Cook wrote:


Reads out of /dev/mem should be restricted to non-RAM on Fedora, yes?

Tommi, do your kernels have CONFIG_STRICT_DEVMEM=y ?

-Kees



CONFIG_STRICT_DEVMEM should be on in all Fedora kernels.


Yes, the fedora kernels do have it enabled:

  $ grep STRICT_DEVMEM /boot/config-4.9.14-200.fc25.x86_64
  CONFIG_STRICT_DEVMEM=y
  CONFIG_IO_STRICT_DEVMEM=y

But I do not have it in my own build:

  $ grep STRICT_DEVMEM .config
  # CONFIG_STRICT_DEVMEM is not set

-Tommi

Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78!

[Tommi Rantala]

On 30.03.2017 20:44, Laura Abbott wrote:

On 03/30/2017 10:37 AM, Kees Cook wrote:


Reads out of /dev/mem should be restricted to non-RAM on Fedora, yes?

Tommi, do your kernels have CONFIG_STRICT_DEVMEM=y ?

-Kees



CONFIG_STRICT_DEVMEM should be on in all Fedora kernels.


Yes, the fedora kernels do have it enabled:

  $ grep STRICT_DEVMEM /boot/config-4.9.14-200.fc25.x86_64
  CONFIG_STRICT_DEVMEM=y
  CONFIG_IO_STRICT_DEVMEM=y

But I do not have it in my own build:

  $ grep STRICT_DEVMEM .config
  # CONFIG_STRICT_DEVMEM is not set

-Tommi

Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78!

[Tommi Rantala]

On 30.03.2017 23:01, Dave Jones wrote:

On Thu, Mar 30, 2017 at 12:52:31PM -0700, Kees Cook wrote:
 > On Thu, Mar 30, 2017 at 12:41 PM, Dave Jones <da...@codemonkey.org.uk> wrote:
 > > On Thu, Mar 30, 2017 at 09:45:26AM -0700, Kees Cook wrote:
 > >  > On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala
 > >  > <tommi.t.rant...@nokia.com> wrote:
 > >  > > Hi,
 > >  > >
 > >  > > Running:
 > >  > >
 > >  > >   $ sudo x86info -a
 > >  > >
 > >  > > On this HP ZBook 15 G3 laptop kills the x86info process with segfault 
and
 > >  > > produces the following kernel BUG.
 > >  > >
 > >  > >   $ git describe
 > >  > >   v4.11-rc4-40-gfe82203
 > >  > >
 > >  > > It is also reproducible with the fedora kernel: 4.9.14-200.fc25.x86_64
 > >  > >
 > >  > > Full dmesg output here: https://pastebin.com/raw/Kur2mpZq
 > >  > >
 > >  > > [   51.418954] usercopy: kernel memory exposure attempt detected from
 > >  > > 8809 (dma-kmalloc-256) (4096 bytes)
 > >  >
 > >  > This seems like a real exposure: the copy is attempting to read 4096
 > >  > bytes from a 256 byte object.
 > >
 > > The code[1] is doing a 4k read from /dev/mem in the range 0x9 -> 
0xa
 > > According to arch/x86/mm/init.c:devmem_is_allowed, that's still valid..
 > >
 > > Note that the printk is using the direct mapping address. Is that what's
 > > being passed down to devmem_is_allowed now ? If so, that's probably what 
broke.
 >
 > So this is attempting to read physical memory 0x9 -> 0xa, but
 > that's somehow resolving to a virtual address that is claimed by
 > dma-kmalloc?? I'm confused how that's happening...

The only thing that I can think of would be a rogue ptr in the bios
table, but that seems unlikely.  Tommi, can you put strace of x86info -mp 
somewhere?
That will confirm/deny whether we're at least asking the kernel to do sane 
things.


Indeed the bug happens when reading from /dev/mem:

https://pastebin.com/raw/ZEJGQP1X

# strace -f -y x86info -mp
[...]
open("/dev/mem", O_RDONLY)  = 3
lseek(3, 1038, SEEK_SET)  = 1038
read(3, "\300\235", 2)= 2
lseek(3, 646144, SEEK_SET)= 646144
read(3, 
"\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1024) = 1024

lseek(3, 1043, SEEK_SET)  = 1043
read(3, "w\2", 2) = 2
lseek(3, 645120, SEEK_SET)= 645120
read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1024) = 1024

lseek(3, 654336, SEEK_SET)= 654336
read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1024) = 1024

lseek(3, 983040, SEEK_SET)= 983040
read(3, 
"IFE$\245S\0\0\1\0\0\0\0\360y\0\0\360\220\260\30\237{=\23\10\17\\276\17\0"..., 
65536) = 65536

lseek(3, 917504, SEEK_SET)= 917504
read(3, 
"\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 
65536) = 65536

lseek(3, 524288, SEEK_SET)= 524288
read(3,  )= ?
+++ killed by SIGSEGV +++

Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78!

[Tommi Rantala]

On 30.03.2017 23:01, Dave Jones wrote:

On Thu, Mar 30, 2017 at 12:52:31PM -0700, Kees Cook wrote:
 > On Thu, Mar 30, 2017 at 12:41 PM, Dave Jones  wrote:
 > > On Thu, Mar 30, 2017 at 09:45:26AM -0700, Kees Cook wrote:
 > >  > On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala
 > >  >  wrote:
 > >  > > Hi,
 > >  > >
 > >  > > Running:
 > >  > >
 > >  > >   $ sudo x86info -a
 > >  > >
 > >  > > On this HP ZBook 15 G3 laptop kills the x86info process with segfault 
and
 > >  > > produces the following kernel BUG.
 > >  > >
 > >  > >   $ git describe
 > >  > >   v4.11-rc4-40-gfe82203
 > >  > >
 > >  > > It is also reproducible with the fedora kernel: 4.9.14-200.fc25.x86_64
 > >  > >
 > >  > > Full dmesg output here: https://pastebin.com/raw/Kur2mpZq
 > >  > >
 > >  > > [   51.418954] usercopy: kernel memory exposure attempt detected from
 > >  > > 8809 (dma-kmalloc-256) (4096 bytes)
 > >  >
 > >  > This seems like a real exposure: the copy is attempting to read 4096
 > >  > bytes from a 256 byte object.
 > >
 > > The code[1] is doing a 4k read from /dev/mem in the range 0x9 -> 
0xa
 > > According to arch/x86/mm/init.c:devmem_is_allowed, that's still valid..
 > >
 > > Note that the printk is using the direct mapping address. Is that what's
 > > being passed down to devmem_is_allowed now ? If so, that's probably what 
broke.
 >
 > So this is attempting to read physical memory 0x9 -> 0xa, but
 > that's somehow resolving to a virtual address that is claimed by
 > dma-kmalloc?? I'm confused how that's happening...

The only thing that I can think of would be a rogue ptr in the bios
table, but that seems unlikely.  Tommi, can you put strace of x86info -mp 
somewhere?
That will confirm/deny whether we're at least asking the kernel to do sane 
things.


Indeed the bug happens when reading from /dev/mem:

https://pastebin.com/raw/ZEJGQP1X

# strace -f -y x86info -mp
[...]
open("/dev/mem", O_RDONLY)  = 3
lseek(3, 1038, SEEK_SET)  = 1038
read(3, "\300\235", 2)= 2
lseek(3, 646144, SEEK_SET)= 646144
read(3, 
"\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1024) = 1024

lseek(3, 1043, SEEK_SET)  = 1043
read(3, "w\2", 2) = 2
lseek(3, 645120, SEEK_SET)= 645120
read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1024) = 1024

lseek(3, 654336, SEEK_SET)= 654336
read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1024) = 1024

lseek(3, 983040, SEEK_SET)= 983040
read(3, 
"IFE$\245S\0\0\1\0\0\0\0\360y\0\0\360\220\260\30\237{=\23\10\17\\276\17\0"..., 
65536) = 65536

lseek(3, 917504, SEEK_SET)= 917504
read(3, 
"\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 
65536) = 65536

lseek(3, 524288, SEEK_SET)= 524288
read(3,  )= ?
+++ killed by SIGSEGV +++

sudo x86info -a => kernel BUG at mm/usercopy.c:78!

[Tommi Rantala]

Hi,

Running:

  $ sudo x86info -a

On this HP ZBook 15 G3 laptop kills the x86info process with segfault 
and produces the following kernel BUG.


  $ git describe
  v4.11-rc4-40-gfe82203

It is also reproducible with the fedora kernel: 4.9.14-200.fc25.x86_64

Full dmesg output here: https://pastebin.com/raw/Kur2mpZq

[   51.418954] usercopy: kernel memory exposure attempt detected from 
8809 (dma-kmalloc-256) (4096 bytes)

[   51.418959] [ cut here ]
[   51.418968] kernel BUG at /home/tomranta/git/linux/mm/usercopy.c:78!
[   51.418970] invalid opcode:  [#1] SMP
[   51.418972] Modules linked in: fuse ccm ipt_REJECT nf_reject_ipv4 
xt_tcpudp tun af_packet xt_conntrack nf_conntrack libcrc32c ebtable_nat 
ebtable_broute bridge ip6table_mangle ip6table_raw iptable_mangle 
iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables 
iptable_filter ip_tables x_tables nls_iso8859_1 nls_cp437 vfat fat 
dm_mirror dm_region_hash dm_log arc4 hp_wmi sparse_keymap coretemp 
kvm_intel snd_hda_codec_hdmi kvm irqbypass pcbc aesni_intel aes_x86_64 
crypto_simd cryptd glue_helper intel_cstate intel_uncore intel_rapl_perf 
iwlmvm mac80211 snd_usb_audio mousedev snd_usbmidi_lib snd_rawmidi 
input_leds snd_hda_codec_conexant snd_hda_codec_generic efivars iwlwifi 
uvcvideo videobuf2_vmalloc videobuf2_memops snd_hda_intel videobuf2_v4l2 
cfg80211 videobuf2_core snd_hda_codec snd_seq snd_hwdep
[   51.419010]  snd_seq_device snd_hda_core snd_pcm thermal hp_accel 
lis3lv02d input_polldev ac acpi_pad battery led_class evdev hp_wireless 
nfsd lockd grace sunrpc tg3 libphy crc32_pclmul crc32c_intel e1000e 
sd_mod 8021q garp stp llc mrp unix autofs4
[   51.419025] CPU: 7 PID: 2406 Comm: x86info Not tainted 
4.11.0-rc4-tommi+ #14
[   51.419027] Hardware name: HP HP ZBook 15 G3/80D5, BIOS N81 Ver. 
01.12 11/01/2016

[   51.419030] task: 88026ce84100 task.stack: c90003b94000
[   51.419035] RIP: 0010:__check_object_size+0xfd/0x195
[   51.419037] RSP: 0018:c90003b97de0 EFLAGS: 00010282
[   51.419039] RAX: 0066 RBX: 8809 RCX: 

[   51.419042] RDX: 8802bddd33e8 RSI: 8802bddcc9e8 RDI: 
8802bddcc9e8
[   51.419044] RBP: c90003b97e00 R08: 0006648a R09: 
048b
[   51.419046] R10: 0100 R11: 81e9a86d R12: 
1000
[   51.419049] R13: 0001 R14: 88091000 R15: 
8809
[   51.419051] FS:  7f8323436b40() GS:8802bddc() 
knlGS:

[   51.419054] CS:  0010 DS:  ES:  CR0: 80050033
[   51.419056] CR2: 7ffcbec21000 CR3: 00026c8e8000 CR4: 
003406a0
[   51.419058] DR0:  DR1:  DR2: 

[   51.419061] DR3:  DR6: fffe0ff0 DR7: 
0400

[   51.419063] Call Trace:
[   51.419066]  read_mem+0x70/0x120
[   51.419069]  __vfs_read+0x28/0x130
[   51.419072]  ? security_file_permission+0x9b/0xb0
[   51.419075]  ? rw_verify_area+0x4e/0xb0
[   51.419077]  vfs_read+0x96/0x130
[   51.419079]  SyS_read+0x46/0xb0
[   51.419082]  ? SyS_lseek+0x87/0xb0
[   51.419085]  entry_SYSCALL_64_fastpath+0x1a/0xa9
[   51.419087] RIP: 0033:0x7f8322d56bd0
[   51.419089] RSP: 002b:7ffcbec11c68 EFLAGS: 0246 ORIG_RAX: 

[   51.419091] RAX: ffda RBX: 0006 RCX: 
7f8322d56bd0
[   51.419094] RDX: 0001 RSI: 7ffcbec11ca0 RDI: 
0003
[   51.419096] RBP: 0008 R08: 0005 R09: 
0050
[   51.419098] R10:  R11: 0246 R12: 
02231c00
[   51.419100] R13: 7ffcbec11c9e R14: 7ffcbec51cf8 R15: 

[   51.419103] Code: a8 81 48 c7 c2 29 69 a4 81 48 c7 c6 82 89 a5 81 48 
0f 45 d0 48 c7 c0 1a 1e a6 81 48 c7 c7 d0 ed a5 81 48 0f 45 f0 e8 7f 74 
f8 ff <0f> 0b 48 89 df e8 29 98 e8 ff 84 c0 0f 84 3a ff ff ff b8 00 00

[   51.419123] RIP: __check_object_size+0xfd/0x195 RSP: c90003b97de0
[   51.421565] ---[ end trace 441f7992ca25e39d ]---

sudo x86info -a => kernel BUG at mm/usercopy.c:78!

[Tommi Rantala]

Hi,

Running:

  $ sudo x86info -a

On this HP ZBook 15 G3 laptop kills the x86info process with segfault 
and produces the following kernel BUG.


  $ git describe
  v4.11-rc4-40-gfe82203

It is also reproducible with the fedora kernel: 4.9.14-200.fc25.x86_64

Full dmesg output here: https://pastebin.com/raw/Kur2mpZq

[   51.418954] usercopy: kernel memory exposure attempt detected from 
8809 (dma-kmalloc-256) (4096 bytes)

[   51.418959] [ cut here ]
[   51.418968] kernel BUG at /home/tomranta/git/linux/mm/usercopy.c:78!
[   51.418970] invalid opcode:  [#1] SMP
[   51.418972] Modules linked in: fuse ccm ipt_REJECT nf_reject_ipv4 
xt_tcpudp tun af_packet xt_conntrack nf_conntrack libcrc32c ebtable_nat 
ebtable_broute bridge ip6table_mangle ip6table_raw iptable_mangle 
iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables 
iptable_filter ip_tables x_tables nls_iso8859_1 nls_cp437 vfat fat 
dm_mirror dm_region_hash dm_log arc4 hp_wmi sparse_keymap coretemp 
kvm_intel snd_hda_codec_hdmi kvm irqbypass pcbc aesni_intel aes_x86_64 
crypto_simd cryptd glue_helper intel_cstate intel_uncore intel_rapl_perf 
iwlmvm mac80211 snd_usb_audio mousedev snd_usbmidi_lib snd_rawmidi 
input_leds snd_hda_codec_conexant snd_hda_codec_generic efivars iwlwifi 
uvcvideo videobuf2_vmalloc videobuf2_memops snd_hda_intel videobuf2_v4l2 
cfg80211 videobuf2_core snd_hda_codec snd_seq snd_hwdep
[   51.419010]  snd_seq_device snd_hda_core snd_pcm thermal hp_accel 
lis3lv02d input_polldev ac acpi_pad battery led_class evdev hp_wireless 
nfsd lockd grace sunrpc tg3 libphy crc32_pclmul crc32c_intel e1000e 
sd_mod 8021q garp stp llc mrp unix autofs4
[   51.419025] CPU: 7 PID: 2406 Comm: x86info Not tainted 
4.11.0-rc4-tommi+ #14
[   51.419027] Hardware name: HP HP ZBook 15 G3/80D5, BIOS N81 Ver. 
01.12 11/01/2016

[   51.419030] task: 88026ce84100 task.stack: c90003b94000
[   51.419035] RIP: 0010:__check_object_size+0xfd/0x195
[   51.419037] RSP: 0018:c90003b97de0 EFLAGS: 00010282
[   51.419039] RAX: 0066 RBX: 8809 RCX: 

[   51.419042] RDX: 8802bddd33e8 RSI: 8802bddcc9e8 RDI: 
8802bddcc9e8
[   51.419044] RBP: c90003b97e00 R08: 0006648a R09: 
048b
[   51.419046] R10: 0100 R11: 81e9a86d R12: 
1000
[   51.419049] R13: 0001 R14: 88091000 R15: 
8809
[   51.419051] FS:  7f8323436b40() GS:8802bddc() 
knlGS:

[   51.419054] CS:  0010 DS:  ES:  CR0: 80050033
[   51.419056] CR2: 7ffcbec21000 CR3: 00026c8e8000 CR4: 
003406a0
[   51.419058] DR0:  DR1:  DR2: 

[   51.419061] DR3:  DR6: fffe0ff0 DR7: 
0400

[   51.419063] Call Trace:
[   51.419066]  read_mem+0x70/0x120
[   51.419069]  __vfs_read+0x28/0x130
[   51.419072]  ? security_file_permission+0x9b/0xb0
[   51.419075]  ? rw_verify_area+0x4e/0xb0
[   51.419077]  vfs_read+0x96/0x130
[   51.419079]  SyS_read+0x46/0xb0
[   51.419082]  ? SyS_lseek+0x87/0xb0
[   51.419085]  entry_SYSCALL_64_fastpath+0x1a/0xa9
[   51.419087] RIP: 0033:0x7f8322d56bd0
[   51.419089] RSP: 002b:7ffcbec11c68 EFLAGS: 0246 ORIG_RAX: 

[   51.419091] RAX: ffda RBX: 0006 RCX: 
7f8322d56bd0
[   51.419094] RDX: 0001 RSI: 7ffcbec11ca0 RDI: 
0003
[   51.419096] RBP: 0008 R08: 0005 R09: 
0050
[   51.419098] R10:  R11: 0246 R12: 
02231c00
[   51.419100] R13: 7ffcbec11c9e R14: 7ffcbec51cf8 R15: 

[   51.419103] Code: a8 81 48 c7 c2 29 69 a4 81 48 c7 c6 82 89 a5 81 48 
0f 45 d0 48 c7 c0 1a 1e a6 81 48 c7 c7 d0 ed a5 81 48 0f 45 f0 e8 7f 74 
f8 ff <0f> 0b 48 89 df e8 29 98 e8 ff 84 c0 0f 84 3a ff ff ff b8 00 00

[   51.419123] RIP: __check_object_size+0xfd/0x195 RSP: c90003b97de0
[   51.421565] ---[ end trace 441f7992ca25e39d ]---

[tip:perf/core] perf utils: Readlink /proc/self/exe to find the perf binary

[tip-bot for Tommi Rantala]

Commit-ID:  55f77128e7652e537d6c226d5b56821cdb5c22de
Gitweb: http://git.kernel.org/tip/55f77128e7652e537d6c226d5b56821cdb5c22de
Author: Tommi Rantala <tommi.t.rant...@nokia.com>
AuthorDate: Wed, 22 Mar 2017 15:06:24 +0200
Committer:  Arnaldo Carvalho de Melo <a...@redhat.com>
CommitDate: Mon, 27 Mar 2017 15:37:54 -0300

perf utils: Readlink /proc/self/exe to find the perf binary

Simplification: it is easier to open /proc/self/exe than /proc/$pid/exe.

Signed-off-by: Tommi Rantala <tommi.t.rant...@nokia.com>
Cc: Alexander Shishkin <alexander.shish...@linux.intel.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Link: http://lkml.kernel.org/r/20170322130624.21881-7-tommi.t.rant...@nokia.com
Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
---
 tools/perf/util/header.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index cf22962..ef09f26 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -370,15 +370,11 @@ static int write_cmdline(int fd, struct perf_header *h 
__maybe_unused,
 struct perf_evlist *evlist __maybe_unused)
 {
char buf[MAXPATHLEN];
-   char proc[32];
u32 n;
int i, ret;
 
-   /*
-* actual atual path to perf binary
-*/
-   sprintf(proc, "/proc/%d/exe", getpid());
-   ret = readlink(proc, buf, sizeof(buf) - 1);
+   /* actual path to perf binary */
+   ret = readlink("/proc/self/exe", buf, sizeof(buf) - 1);
if (ret <= 0)
return -1;