Re: WARNING in __rcu_read_unlock

2018-12-18 Thread Paul E. McKenney
On Tue, Dec 18, 2018 at 02:26:00PM +0100, Dmitry Vyukov wrote:
> On Tue, Dec 18, 2018 at 1:40 PM Stefano Brivio  wrote:
> >
> > On Tue, 18 Dec 2018 09:49:17 +0100
> > Dmitry Vyukov  wrote:
> >
> > > On Tue, Dec 18, 2018 at 12:18 AM Stefano Brivio  
> > > wrote:
> > > >
> > > > On Mon, 17 Dec 2018 16:53:36 +0100
> > > > Dmitry Vyukov  wrote:
> > > >
> > > > > On Mon, Dec 17, 2018 at 4:24 PM Stefano Brivio  
> > > > > wrote:
> > > > > >
> > > > > > On Mon, 17 Dec 2018 06:57:35 -0800
> > > > > > Eric Dumazet  wrote:
> > > > > >
> > > > > > > Might be cause by commit b8a51b38e4d4dec3e379d52c0fe1a66827f7cf1e
> > > > > > > fou, fou6: ICMP error handlers for FoU and GUE
> > > > > >
> > > > > > This:
> > > > > >
> > > > > > diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
> > > > > > index 0d0ad19ecb87..20a6de26d146 100644
> > > > > > --- a/net/ipv4/fou.c
> > > > > > +++ b/net/ipv4/fou.c
> > > > > > @@ -1008,6 +1008,9 @@ static int gue_err_proto_handler(int proto, 
> > > > > > struct sk_buff *skb, u32 info)
> > > > > >  {
> > > > > > const struct net_protocol *ipprot = 
> > > > > > rcu_dereference(inet_protos[proto]);
> > > > > >
> > > > > > +   if (ipprot == IPPROTO_UDP)
> > > > > > +   return -EINVAL;
> > > > > > +
> > > > > > if (ipprot && ipprot->err_handler) {
> > > > > > if (!ipprot->err_handler(skb, info))
> > > > > > return 0;
> > > > > >
> > > > > > should fix the issue, but I still have to run tests and make sure we
> > > > > > don't hit similar cases.
> > > > >
> > > > > Please don't forget to add a regression test for it too ;)
> > > >
> > > > Where would you suggest to add this? The only selftest that goes
> > >
> > > I dunno. But there must be some place for such tests, right?
> >
> > Not as far as I know. The selftests checking this path, by design, only
> > use supported configurations, they don't forge packets.
> >
> > Maybe it would be nice to have a semi-automated way to isolate and
> > describe/name specific conditions found by syzbot via fuzzing and turn
> > those into tests that are then repeated periodically. I'm not sure how
> > that would look like, but I think it's still more maintainable than a
> > pile of C reproducers with forged packets in selftests/net.
> 
> It would be nice to do something like this. Filed
> https://github.com/google/syzkaller/issues/884
> However, there are few open questions that I am not sure how to resolve yet...
> 
> 
> > Eric, Cong, Xin, as you also recently fixed a nice deal of similar cases
> > reported by syzbot, what do you think? Did you ever feel the need to
> > turn a syzbot reproducer into a regression test case?
> >
> > > > through this path currently is net/pmtu.sh, but as configuration of an
> > > > actual UDP-in-GUE tunnel is currently not supported, I would really
> > > > need to forge that specific packet, so that doesn't seem to be a good
> > > > fit.
> > > >
> > > > Won't syzbot add this to some list of reproducers that are checked in
> > > > the future?
> > >
> > > It won't. Also fuzzing is complementary to testing, not a replacement:
> >
> > Indeed, but that doesn't mean we need to limit the potential of fuzzing
> > because "it's not testing". It can be used to check for regressions,
> > too, especially in these cases.
> >
> > > https://twitter.com/dvyukov/status/1074719682962358272
> >
> > Now, I'm extremely thankful for the work you're doing and especially
> > for finding this subtle condition with syzbot, but this is quite
> > inaccurate. To be exposed to this issue, the user would need to
> > have the fou module loaded (it won't autoload), which is used quite
> > rarely, and, on top of that, have a UDP tunnel configured. It wouldn't
> > have been the kind of "evil packet crashes the internet" scenario you
> > were dreaming of ;)
> 
> Okay, I see. Full bug assessment is hard. I mess it both ways for
> different bugs.
> But I did not claim that it does not require some setup :)
> And maybe there is somebody important on the internet that uses such
> setup. Who knows.

Black hats, if no one else.  ;-)

Thanx, Paul



[tip:perf/core] tools lib traceevent: Rename tep_free_format() to tep_free_event()

2018-12-18 Thread tip-bot for Tzvetomir Stoyanov
Commit-ID:  fc39851c455ce9e593302c9e376cdb9593c10704
Gitweb: https://git.kernel.org/tip/fc39851c455ce9e593302c9e376cdb9593c10704
Author: Tzvetomir Stoyanov 
AuthorDate: Fri, 30 Nov 2018 10:44:08 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:56:05 -0300

tools lib traceevent: Rename tep_free_format() to tep_free_event()

In order to make libtraceevent into a proper library, variables, data
structures and functions require a unique prefix to prevent name space
conflicts. This renames tep_free_format() to tep_free_event(), which
describes more closely the purpose of the function.

Signed-off-by: Tzvetomir Stoyanov 
Cc: Andrew Morton 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: http://lkml.kernel.org/r/20181130154647.591673...@goodmis.org
Signed-off-by: Steven Rostedt (VMware) 
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/traceevent/event-parse.c | 6 +++---
 tools/lib/traceevent/event-parse.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/lib/traceevent/event-parse.c 
b/tools/lib/traceevent/event-parse.c
index 047be5f700b5..a3e7d0a75e11 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -6154,7 +6154,7 @@ __parse_event(struct tep_handle *pevent,
return 0;
 
 event_add_failed:
-   tep_free_format(event);
+   tep_free_event(event);
return ret;
 }
 
@@ -6763,7 +6763,7 @@ static void free_formats(struct tep_format *format)
free_format_fields(format->fields);
 }
 
-void tep_free_format(struct tep_event *event)
+void tep_free_event(struct tep_event *event)
 {
free(event->name);
free(event->system);
@@ -6849,7 +6849,7 @@ void tep_free(struct tep_handle *pevent)
}
 
for (i = 0; i < pevent->nr_events; i++)
-   tep_free_format(pevent->events[i]);
+   tep_free_event(pevent->events[i]);
 
while (pevent->handlers) {
handle = pevent->handlers;
diff --git a/tools/lib/traceevent/event-parse.h 
b/tools/lib/traceevent/event-parse.h
index 2a1a644c5ec8..950ad185a5c4 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -475,7 +475,7 @@ enum tep_errno tep_parse_format(struct tep_handle *pevent,
struct tep_event **eventp,
const char *buf,
unsigned long size, const char *sys);
-void tep_free_format(struct tep_event *event);
+void tep_free_event(struct tep_event *event);
 void tep_free_format_field(struct tep_format_field *field);
 
 void *tep_get_field_raw(struct trace_seq *s, struct tep_event *event,


[tip:perf/core] tools lib traceevent, perf tools: Rename 'struct tep_event_format' to 'struct tep_event'

2018-12-18 Thread tip-bot for Tzvetomir Stoyanov
Commit-ID:  97fbf3f0e0aa854ed33141dc9a5410f0ac6c71f3
Gitweb: https://git.kernel.org/tip/97fbf3f0e0aa854ed33141dc9a5410f0ac6c71f3
Author: Tzvetomir Stoyanov 
AuthorDate: Fri, 30 Nov 2018 10:44:07 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:56:02 -0300

tools lib traceevent, perf tools: Rename 'struct tep_event_format' to 'struct 
tep_event'

In order to make libtraceevent into a proper library, variables, data
structures and functions require a unique prefix to prevent name space
conflicts.

This renames 'struct tep_event_format' to 'struct tep_event', which
describes more closely the purpose of the struct.

Signed-off-by: Tzvetomir Stoyanov 
Cc: Adrian Hunter 
Cc: Andrew Morton 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: http://lkml.kernel.org/r/20181130154647.436403...@goodmis.org
Signed-off-by: Steven Rostedt (VMware) 
[ Fixup conflict with 6e33c250a88f ("tools lib traceevent: Fix compile warnings 
in tools/lib/traceevent/event-parse.c") ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/traceevent/event-parse-api.c |   2 +-
 tools/lib/traceevent/event-parse-local.h   |   6 +-
 tools/lib/traceevent/event-parse.c | 188 ++---
 tools/lib/traceevent/event-parse.h |  62 +++
 tools/lib/traceevent/parse-filter.c|  42 ++---
 tools/lib/traceevent/plugin_function.c |   2 +-
 tools/lib/traceevent/plugin_hrtimer.c  |   4 +-
 tools/lib/traceevent/plugin_kmem.c |   2 +-
 tools/lib/traceevent/plugin_kvm.c  |  14 +-
 tools/lib/traceevent/plugin_mac80211.c |   4 +-
 tools/lib/traceevent/plugin_sched_switch.c |   4 +-
 tools/perf/builtin-trace.c |   2 +-
 tools/perf/util/evsel.h|   4 +-
 tools/perf/util/header.c   |   2 +-
 tools/perf/util/python.c   |   4 +-
 .../perf/util/scripting-engines/trace-event-perl.c |   6 +-
 .../util/scripting-engines/trace-event-python.c|   8 +-
 tools/perf/util/trace-event-parse.c|  16 +-
 tools/perf/util/trace-event.c  |   8 +-
 tools/perf/util/trace-event.h  |  16 +-
 20 files changed, 198 insertions(+), 198 deletions(-)

diff --git a/tools/lib/traceevent/event-parse-api.c 
b/tools/lib/traceevent/event-parse-api.c
index 61f7149085ee..0dc011154ee9 100644
--- a/tools/lib/traceevent/event-parse-api.c
+++ b/tools/lib/traceevent/event-parse-api.c
@@ -15,7 +15,7 @@
  * This returns pointer to the first element of the events array
  * If @tep is NULL, NULL is returned.
  */
-struct tep_event_format *tep_get_first_event(struct tep_handle *tep)
+struct tep_event *tep_get_first_event(struct tep_handle *tep)
 {
if (tep && tep->events)
return tep->events[0];
diff --git a/tools/lib/traceevent/event-parse-local.h 
b/tools/lib/traceevent/event-parse-local.h
index b9bddde577f8..94746efef433 100644
--- a/tools/lib/traceevent/event-parse-local.h
+++ b/tools/lib/traceevent/event-parse-local.h
@@ -50,9 +50,9 @@ struct tep_handle {
unsigned int printk_count;
 
 
-   struct tep_event_format **events;
+   struct tep_event **events;
int nr_events;
-   struct tep_event_format **sort_events;
+   struct tep_event **sort_events;
enum tep_event_sort_type last_type;
 
int type_offset;
@@ -84,7 +84,7 @@ struct tep_handle {
struct tep_function_handler *func_handlers;
 
/* cache */
-   struct tep_event_format *last_event;
+   struct tep_event *last_event;
 
char *trace_clock;
 };
diff --git a/tools/lib/traceevent/event-parse.c 
b/tools/lib/traceevent/event-parse.c
index d1e6ee3d43cf..047be5f700b5 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -96,7 +96,7 @@ struct tep_function_handler {
 
 static unsigned long long
 process_defined_func(struct trace_seq *s, void *data, int size,
-struct tep_event_format *event, struct tep_print_arg *arg);
+struct tep_event *event, struct tep_print_arg *arg);
 
 static void free_func_handle(struct tep_function_handler *func);
 
@@ -739,16 +739,16 @@ void tep_print_printk(struct tep_handle *pevent)
}
 }
 
-static struct tep_event_format *alloc_event(void)
+static struct tep_event *alloc_event(void)
 {
-   return calloc(1, sizeof(struct tep_event_format));
+   return calloc(1, sizeof(struct tep_event));
 }
 
-static int add_event(struct tep_handle *pevent, struct tep_event_format *event)
+static int add_event(struct tep_handle *pevent, struct tep_event *event)
 {
int i;
-   struct tep_event_format **events = realloc(pevent->events, 
sizeof(event) *
- (pevent->nr_events + 1));
+   struct tep_event **events = realloc(pevent->events, sizeof(event) *
+

[tip:perf/core] perf tools: traceevent API cleanup, remove __tep_data2host*()

2018-12-18 Thread tip-bot for Tzvetomir Stoyanov
Commit-ID:  f0bba09ce3f88ddeef7a3e45f612d26b1e951d5b
Gitweb: https://git.kernel.org/tip/f0bba09ce3f88ddeef7a3e45f612d26b1e951d5b
Author: Tzvetomir Stoyanov 
AuthorDate: Fri, 30 Nov 2018 10:44:09 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:56:08 -0300

perf tools: traceevent API cleanup, remove __tep_data2host*()

In order to make libtraceevent into a proper library, its API should be
straightforward. The __tep_data2host*() functions are going to no longer
be available as a libtraceevent API, tep_read_number() should be used
instead. This patch replaces __tep_data2host*() usage with
tep_read_number() in perf.

Signed-off-by: Tzvetomir Stoyanov 
Cc: Andrew Morton 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: http://lkml.kernel.org/r/20181130154647.743979...@goodmis.org
Signed-off-by: Steven Rostedt (VMware) 
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/trace-event-read.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/trace-event-read.c 
b/tools/perf/util/trace-event-read.c
index 76f12c705ef9..efe2f58cff4e 100644
--- a/tools/perf/util/trace-event-read.c
+++ b/tools/perf/util/trace-event-read.c
@@ -102,7 +102,7 @@ static unsigned int read4(struct tep_handle *pevent)
 
if (do_read(, 4) < 0)
return 0;
-   return __tep_data2host4(pevent, data);
+   return tep_read_number(pevent, , 4);
 }
 
 static unsigned long long read8(struct tep_handle *pevent)
@@ -111,7 +111,7 @@ static unsigned long long read8(struct tep_handle *pevent)
 
if (do_read(, 8) < 0)
return 0;
-   return __tep_data2host8(pevent, data);
+   return tep_read_number(pevent, , 8);
 }
 
 static char *read_string(void)


[tip:perf/core] tools lib traceevent: traceevent API cleanup

2018-12-18 Thread tip-bot for Tzvetomir Stoyanov
Commit-ID:  6cd99d21741dbffb40e28ab7d955b27d09c3352f
Gitweb: https://git.kernel.org/tip/6cd99d21741dbffb40e28ab7d955b27d09c3352f
Author: Tzvetomir Stoyanov 
AuthorDate: Fri, 30 Nov 2018 10:44:10 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:56:10 -0300

tools lib traceevent: traceevent API cleanup

In order to make libtraceevent into a proper library, its API should be
straightforward. This patch hides few API functions, intended for
internal usage only:

tep_free_event(), tep_free_format_field(), __tep_data2host2(),
__tep_data2host4() and __tep_data2host8().
The patch also alignes the libtraceevent summary man page with
these API changes.

Signed-off-by: Tzvetomir Stoyanov 
Cc: Andrew Morton 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: http://lkml.kernel.org/r/20181130154647.891651...@goodmis.org
Signed-off-by: Steven Rostedt (VMware) 
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/traceevent/event-parse-api.c   |  6 +++---
 tools/lib/traceevent/event-parse-local.h |  7 +++
 tools/lib/traceevent/event-parse.c   | 13 -
 tools/lib/traceevent/event-parse.h   | 16 
 4 files changed, 18 insertions(+), 24 deletions(-)

diff --git a/tools/lib/traceevent/event-parse-api.c 
b/tools/lib/traceevent/event-parse-api.c
index 0dc011154ee9..8b31c0e00ba3 100644
--- a/tools/lib/traceevent/event-parse-api.c
+++ b/tools/lib/traceevent/event-parse-api.c
@@ -51,7 +51,7 @@ void tep_set_flag(struct tep_handle *tep, int flag)
tep->flags |= flag;
 }
 
-unsigned short __tep_data2host2(struct tep_handle *pevent, unsigned short data)
+unsigned short tep_data2host2(struct tep_handle *pevent, unsigned short data)
 {
unsigned short swap;
 
@@ -64,7 +64,7 @@ unsigned short __tep_data2host2(struct tep_handle *pevent, 
unsigned short data)
return swap;
 }
 
-unsigned int __tep_data2host4(struct tep_handle *pevent, unsigned int data)
+unsigned int tep_data2host4(struct tep_handle *pevent, unsigned int data)
 {
unsigned int swap;
 
@@ -80,7 +80,7 @@ unsigned int __tep_data2host4(struct tep_handle *pevent, 
unsigned int data)
 }
 
 unsigned long long
-__tep_data2host8(struct tep_handle *pevent, unsigned long long data)
+tep_data2host8(struct tep_handle *pevent, unsigned long long data)
 {
unsigned long long swap;
 
diff --git a/tools/lib/traceevent/event-parse-local.h 
b/tools/lib/traceevent/event-parse-local.h
index 94746efef433..9a092dd4a86d 100644
--- a/tools/lib/traceevent/event-parse-local.h
+++ b/tools/lib/traceevent/event-parse-local.h
@@ -89,4 +89,11 @@ struct tep_handle {
char *trace_clock;
 };
 
+void tep_free_event(struct tep_event *event);
+void tep_free_format_field(struct tep_format_field *field);
+
+unsigned short tep_data2host2(struct tep_handle *pevent, unsigned short data);
+unsigned int tep_data2host4(struct tep_handle *pevent, unsigned int data);
+unsigned long long tep_data2host8(struct tep_handle *pevent, unsigned long 
long data);
+
 #endif /* _PARSE_EVENTS_INT_H */
diff --git a/tools/lib/traceevent/event-parse.c 
b/tools/lib/traceevent/event-parse.c
index a3e7d0a75e11..ffa656b868a9 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -3328,15 +3328,18 @@ tep_find_any_field(struct tep_event *event, const char 
*name)
 unsigned long long tep_read_number(struct tep_handle *pevent,
   const void *ptr, int size)
 {
+   unsigned long long val;
+
switch (size) {
case 1:
return *(unsigned char *)ptr;
case 2:
-   return tep_data2host2(pevent, ptr);
+   return tep_data2host2(pevent, *(unsigned short *)ptr);
case 4:
-   return tep_data2host4(pevent, ptr);
+   return tep_data2host4(pevent, *(unsigned int *)ptr);
case 8:
-   return tep_data2host8(pevent, ptr);
+   memcpy(, (ptr), sizeof(unsigned long long));
+   return tep_data2host8(pevent, val);
default:
/* BUG! */
return 0;
@@ -4062,7 +4065,7 @@ static void print_str_arg(struct trace_seq *s, void 
*data, int size,
f = tep_find_any_field(event, arg->string.string);
arg->string.offset = f->offset;
}
-   str_offset = tep_data2host4(pevent, data + arg->string.offset);
+   str_offset = tep_data2host4(pevent, *(unsigned int *)(data + 
arg->string.offset));
str_offset &= 0x;
print_str_to_seq(s, format, len_arg, ((char *)data) + 
str_offset);
break;
@@ -4080,7 +4083,7 @@ static void print_str_arg(struct trace_seq *s, void 
*data, int size,
f = tep_find_any_field(event, arg->bitmask.bitmask);
arg->bitmask.offset = f->offset;
}
-   bitmask_offset = tep_data2host4(pevent, data + 

[tip:perf/core] perf beauty mmap_flags: Fixed syntax error Fixed missing ']' error

2018-12-18 Thread tip-bot for Sihyeon Jang
Commit-ID:  00879763fcf21f4b32d63d2241c877f8c1df950e
Gitweb: https://git.kernel.org/tip/00879763fcf21f4b32d63d2241c877f8c1df950e
Author: Sihyeon Jang 
AuthorDate: Sun, 2 Dec 2018 17:06:51 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:56:13 -0300

perf beauty mmap_flags: Fixed syntax error Fixed missing ']' error

Committer testing:

Before:

  # tools/perf/trace/beauty/mmap_flags.sh
  static const char *mmap_flags[] = {
[ilog2(0x40) + 1] = "32BIT",
  tools/perf/trace/beauty/mmap_flags.sh: line 23: [: missing `]'
[ilog2(0x01) + 1] = "SHARED",
[ilog2(0x02) + 1] = "PRIVATE",
[ilog2(0x10) + 1] = "FIXED",
[ilog2(0x20) + 1] = "ANONYMOUS",
[ilog2(0x10) + 1] = "FIXED_NOREPLACE",
  tools/perf/trace/beauty/mmap_flags.sh: line 28: [: missing `]'
[ilog2(0x0100) + 1] = "GROWSDOWN",
[ilog2(0x0800) + 1] = "DENYWRITE",
[ilog2(0x1000) + 1] = "EXECUTABLE",
[ilog2(0x2000) + 1] = "LOCKED",
[ilog2(0x4000) + 1] = "NORESERVE",
[ilog2(0x8000) + 1] = "POPULATE",
[ilog2(0x1) + 1] = "NONBLOCK",
[ilog2(0x2) + 1] = "STACK",
[ilog2(0x4) + 1] = "HUGETLB",
[ilog2(0x8) + 1] = "SYNC",
  };
  #

After:

  $ tools/perf/trace/beauty/mmap_flags.sh
  static const char *mmap_flags[] = {
[ilog2(0x40) + 1] = "32BIT",
[ilog2(0x01) + 1] = "SHARED",
[ilog2(0x02) + 1] = "PRIVATE",
[ilog2(0x10) + 1] = "FIXED",
[ilog2(0x20) + 1] = "ANONYMOUS",
[ilog2(0x10) + 1] = "FIXED_NOREPLACE",
[ilog2(0x0100) + 1] = "GROWSDOWN",
[ilog2(0x0800) + 1] = "DENYWRITE",
[ilog2(0x1000) + 1] = "EXECUTABLE",
[ilog2(0x2000) + 1] = "LOCKED",
[ilog2(0x4000) + 1] = "NORESERVE",
[ilog2(0x8000) + 1] = "POPULATE",
[ilog2(0x1) + 1] = "NONBLOCK",
[ilog2(0x2) + 1] = "STACK",
[ilog2(0x4) + 1] = "HUGETLB",
[ilog2(0x8) + 1] = "SYNC",
  };
  $

Signed-off-by: Sihyeon Jang 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Fixes: aca70cc40a0b ("perf beauty mmap_flags: Check if the arch has a mmap.h 
file")
Link: http://lkml.kernel.org/r/20181202080651.4685-1-uneedsihy...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/trace/beauty/mmap_flags.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/trace/beauty/mmap_flags.sh 
b/tools/perf/trace/beauty/mmap_flags.sh
index cd41023107d7..32bac9c0d694 100755
--- a/tools/perf/trace/beauty/mmap_flags.sh
+++ b/tools/perf/trace/beauty/mmap_flags.sh
@@ -20,12 +20,12 @@ egrep -q $regex ${arch_mman} && \
 (egrep $regex ${arch_mman} | \
sed -r "s/$regex/\2 \1/g"   | \
xargs printf "\t[ilog2(%s) + 1] = \"%s\",\n")
-[ ! -f ${arch_mman} || egrep -q 
'#[[:space:]]*include[[:space:]]+.*' ${arch_mman} ] &&
+([ ! -f ${arch_mman} ] || egrep -q 
'#[[:space:]]*include[[:space:]]+.*' ${arch_mman}) &&
 (egrep $regex ${header_dir}/mman.h | \
sed -r "s/$regex/\2 \1/g"   | \
xargs printf "\t[ilog2(%s) + 1] = \"%s\",\n")


[tip:perf/core] perf cs-etm: Support for ARM A32/T32 instruction sets in CoreSight trace

2018-12-18 Thread tip-bot for Robert Walker
Commit-ID:  a7ee4d625ede4f62146ff3bb2aeee074e4cf5fa1
Gitweb: https://git.kernel.org/tip/a7ee4d625ede4f62146ff3bb2aeee074e4cf5fa1
Author: Robert Walker 
AuthorDate: Mon, 3 Dec 2018 12:18:46 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:56:18 -0300

perf cs-etm: Support for ARM A32/T32 instruction sets in CoreSight trace

This patch adds support for generating instruction samples from trace of
AArch32 programs using the A32 and T32 instruction sets.

T32 has variable 2 or 4 byte instruction size, so the conversion between
addresses and instruction counts requires extra information from the
trace decoder, requiring version 0.10.0 of OpenCSD.  A check for the
OpenCSD library version has been added to the feature check for OpenCSD.

Signed-off-by: Robert Walker 
Reviewed-by: Mathieu Poirier 
Tested-by: Leo Yan 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: coresi...@lists.linaro.org
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1543839526-30348-1-git-send-email-robert.wal...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/feature/test-libopencsd.c   |  8 +++
 tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 29 ++
 tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 10 
 tools/perf/util/cs-etm.c| 70 +++--
 4 files changed, 78 insertions(+), 39 deletions(-)

diff --git a/tools/build/feature/test-libopencsd.c 
b/tools/build/feature/test-libopencsd.c
index 5ff1246e6194..d68eb4fb40cc 100644
--- a/tools/build/feature/test-libopencsd.c
+++ b/tools/build/feature/test-libopencsd.c
@@ -1,6 +1,14 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
 
+/*
+ * Check OpenCSD library version is sufficient to provide required features
+ */
+#define OCSD_MIN_VER ((0 << 16) | (10 << 8) | (0))
+#if !defined(OCSD_VER_NUM) || (OCSD_VER_NUM < OCSD_MIN_VER)
+#error "OpenCSD >= 0.10.0 is required"
+#endif
+
 int main(void)
 {
(void)ocsd_get_version();
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c 
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index 938def6d0bb9..5efb616bd609 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -263,9 +263,12 @@ static void cs_etm_decoder__clear_buffer(struct 
cs_etm_decoder *decoder)
decoder->tail = 0;
decoder->packet_count = 0;
for (i = 0; i < MAX_BUFFER; i++) {
+   decoder->packet_buffer[i].isa = CS_ETM_ISA_UNKNOWN;
decoder->packet_buffer[i].start_addr = CS_ETM_INVAL_ADDR;
decoder->packet_buffer[i].end_addr = CS_ETM_INVAL_ADDR;
+   decoder->packet_buffer[i].instr_count = 0;
decoder->packet_buffer[i].last_instr_taken_branch = false;
+   decoder->packet_buffer[i].last_instr_size = 0;
decoder->packet_buffer[i].exc = false;
decoder->packet_buffer[i].exc_ret = false;
decoder->packet_buffer[i].cpu = INT_MIN;
@@ -294,11 +297,15 @@ cs_etm_decoder__buffer_packet(struct cs_etm_decoder 
*decoder,
decoder->packet_count++;
 
decoder->packet_buffer[et].sample_type = sample_type;
+   decoder->packet_buffer[et].isa = CS_ETM_ISA_UNKNOWN;
decoder->packet_buffer[et].exc = false;
decoder->packet_buffer[et].exc_ret = false;
decoder->packet_buffer[et].cpu = *((int *)inode->priv);
decoder->packet_buffer[et].start_addr = CS_ETM_INVAL_ADDR;
decoder->packet_buffer[et].end_addr = CS_ETM_INVAL_ADDR;
+   decoder->packet_buffer[et].instr_count = 0;
+   decoder->packet_buffer[et].last_instr_taken_branch = false;
+   decoder->packet_buffer[et].last_instr_size = 0;
 
if (decoder->packet_count == MAX_BUFFER - 1)
return OCSD_RESP_WAIT;
@@ -321,8 +328,28 @@ cs_etm_decoder__buffer_range(struct cs_etm_decoder 
*decoder,
 
packet = >packet_buffer[decoder->tail];
 
+   switch (elem->isa) {
+   case ocsd_isa_aarch64:
+   packet->isa = CS_ETM_ISA_A64;
+   break;
+   case ocsd_isa_arm:
+   packet->isa = CS_ETM_ISA_A32;
+   break;
+   case ocsd_isa_thumb2:
+   packet->isa = CS_ETM_ISA_T32;
+   break;
+   case ocsd_isa_tee:
+   case ocsd_isa_jazelle:
+   case ocsd_isa_custom:
+   case ocsd_isa_unknown:
+   default:
+   packet->isa = CS_ETM_ISA_UNKNOWN;
+   }
+
packet->start_addr = elem->st_addr;
packet->end_addr = elem->en_addr;
+   packet->instr_count = elem->num_instr_range;
+
switch (elem->last_i_type) {
case OCSD_INSTR_BR:
case OCSD_INSTR_BR_INDIRECT:
@@ -336,6 +363,8 @@ cs_etm_decoder__buffer_range(struct cs_etm_decoder *decoder,
break;
}
 
+   packet->last_instr_size = elem->last_instr_sz;
+
return ret;
 }
 
diff 

Re: [PATCH v3] powerpc: implement CONFIG_DEBUG_VIRTUAL

2018-12-18 Thread Michael Ellerman
Christophe Leroy  writes:

> This patch implements CONFIG_DEBUG_VIRTUAL to warn about
> incorrect use of virt_to_phys() and page_to_phys()

This commit is breaking my p5020ds booting a 32-bit kernel with:

  smp: Bringing up secondary CPUs ...
  __ioremap(): phys addr 0x7fef5000 is RAM lr ioremap_coherent
  Unable to handle kernel paging request for data at address 0x
  Faulting instruction address: 0xc002e950
  Oops: Kernel access of bad area, sig: 11 [#1]
  BE SMP NR_CPUS=24 CoreNet Generic
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.20.0-rc2-gcc-7.0.1-00138-g9a0380d299e9 #148
  NIP:  c002e950 LR: c002eb20 CTR: 0001
  REGS: e804bd20 TRAP: 0300   Not tainted  
(4.20.0-rc2-gcc-7.0.1-00138-g9a0380d299e9)
  MSR:  00021002   CR: 28004222  XER: 
  DEAR:  ESR:  
  GPR00: c002eb20 e804bdd0 e805  00021002  0050 
00021002 
  GPR08: 2d3f 0001  0004 24000842  c00026d0 
 
  GPR16:        
0001 
  GPR24: 00029002 7fef5140 3000   0040 0001 
 
  NIP [c002e950] smp_85xx_kick_cpu+0x120/0x410
  LR [c002eb20] smp_85xx_kick_cpu+0x2f0/0x410
  Call Trace:
  [e804bdd0] [c002eb20] smp_85xx_kick_cpu+0x2f0/0x410 (unreliable)
  [e804be20] [c0012e38] __cpu_up+0xc8/0x230
  [e804be50] [c0040b34] bringup_cpu+0x34/0x110
  [e804be70] [c00418a8] cpu_up+0x128/0x250
  [e804beb0] [c0b84b14] smp_init+0xc4/0x10c
  [e804bee0] [c0b75c1c] kernel_init_freeable+0xc8/0x250
  [e804bf20] [c00026e8] kernel_init+0x18/0x120
  [e804bf40] [c0011298] ret_from_kernel_thread+0x14/0x1c
  Instruction dump:
  7fb3e850 57bdd1be 2e1d 41d20250 57bd3032 393dffc0 7e6a9b78 5529d1be 
  39290001 7d2903a6 6000 6000 <7c0050ac> 394a0040 4200fff8 7c0004ac 
  ---[ end trace edcab2a1dfd5b38c ]---


Which is obviously this hunk:

> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index 4fc77a99c9bf..68d204a45cd0 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -143,7 +143,7 @@ __ioremap_caller(phys_addr_t addr, unsigned long size, 
> pgprot_t prot, void *call
>* Don't allow anybody to remap normal RAM that we're using.
>* mem_init() sets high_memory so only do the check after that.
>*/
> - if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
> + if (slab_is_available() && virt_addr_valid(p) &&
>   page_is_ram(__phys_to_pfn(p))) {
>   printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n",
>  (unsigned long long)p, __builtin_return_address(0));


I'll try and come up with a fix tomorrow.

cheers



Re: [PATCH v2] debugobjects: Move printk out of db lock critical sections

2018-12-18 Thread Thomas Gleixner
On Tue, 18 Dec 2018, Ingo Molnar wrote:
> * Linus Torvalds  wrote:
> > So thinking that early_printk is any better is just puting your head in 
> > the sand.
> 
> ... at my own feet. ;-) Apologies to the syslog folks!
> 
> early_printk should still in principle be more robust: it tries to use as 
> little (no) locking as possible, and definitely tries to do no 
> allocations. It doesn't use syslog, nor any console locking, nor any 
> regular console drivers.
> 
> Which results in usability trade-offs: trashed screen output, mangled 
> lines. It's a superior debug facility when debugging particularly hairy 
> low level code - which most of the kernel isn't where it turns into an 
> inferior debugging method.
> 
> I thing a good solution would be PeterZ's force_early_printk boot knob, 
> for those low level folks who absolutely want to rely on printk always 
> working in some fashion.
> 
> ( I think it might even be possible to add a non-locked feature to 
>   early-printk that actually adds the messages to the syslog ring-buffer 
>   - without any notification/wakeup/serialization features. 'dmesg' is 
>   handy and its lack is the primary usability disadvantage of 
>   earlyprintk. )

There is work in progress on that... Should be in your inbox early next
year.

Thanks,

tglx


Re: [PATCH v2 2/2] gpio: Add Cadence GPIO driver

2018-12-18 Thread Bartosz Golaszewski
wt., 18 gru 2018 o 14:54 Janek Kotas  napisał(a):
>
>
> > On 18 Dec 2018, at 13:50, Bartosz Golaszewski  
> > wrote:
> >
> >
> > pon., 17 gru 2018 o 23:22 Linus Walleij  
> > napisał(a):
> >>
> >> On Mon, Dec 17, 2018 at 4:51 PM Bartosz Golaszewski
> >>  wrote:
> >>
> >>> The driver looks good but is there any particular reason not to use
> >>> regmap for register IO?
> >>
> >> I thought we only use regmap for MMIO when the register range is
> >> shared (as in a system controller) so that some registers are for this,
> >> some register or even bits in a register for some other driver, so they
> >> need the spinlock in the regmap to protect the register range.
> >>
> >
> > This is what syscon is for. Regmap simply abstracts any register IO.
> > For instance: there's no locking in this driver. Are we sure it's not
> > needed? Regmap provides internal locking for you in the form of a
> > mutex or spinlock.
> >
> > Also: it looks like the interrupts here are quite simple with a single
> > bit per interrupt in the status register and the same layout in the
> > mask register - it could probably profit from using the
> > regmap_irq_chip and not bother with reimplementing irq_chip callbacks.
> >
> >> It is also nice for shadowing/caching of register contents I guess,
> >> wat does this driver get from regmap MMIO?
> >>
> >
> > Code shrinkage IMO.
> >
> > Note that I'm not blocking this from being merged - I just think that
> > using modern frameworks is always a good idea.
>
> I can reimplement the driver using regmap, but It seems in such case
> I won’t be able to use the Generic GPIO Infrastructure, would I?
> So I would need to provide functions for setting direction, etc.
> I think it would make the driver code bigger.
>

Indeed. If anything: gpio-mmio would need to be converted to using regmap.

So I guess nevermind my comment.

Bart


Re: [PATCH v1 03/13] powerpc/mm/32s: rework mmu_mapin_ram()

2018-12-18 Thread Jonathan Neuschäfer
On Tue, Dec 18, 2018 at 09:18:42AM +, Christophe Leroy wrote:
> The only difference I see then are the flags. Everything else is seems
> identical.
> 
> I know you tried already, but would you mind trying once more with the
> following change ?
> 
[...]
> - setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT);
> + setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_X);

Good call, with this workaround on top of patches 1-3, it boots again:

# mount -t debugfs d /sys/kernel/debug
# cat /sys/kernel/debug/powerpc/block_address_translation
---[ Instruction Block Address Translation ]---
0: 0xc000-0xc0ff 0x Kernel EXEC
1: -
2: 0xc100-0xc17f 0x0100 Kernel EXEC
3: -
4: 0xd000-0xd1ff 0x1000 Kernel EXEC
5: -
6: -
7: -

---[ Data Block Address Translation ]---
0: 0xc000-0xc0ff 0x Kernel RW
1: 0xfffe-0x 0x0d00 Kernel RW no cache guarded
2: 0xc100-0xc17f 0x0100 Kernel RW
3: -
4: 0xd000-0xd1ff 0x1000 Kernel RW
5: -
6: -
7: -

> I think we may have some code trying to modify the kernel text without using
> code patching functions.

Is there any faster way than to sprinkle some printks in setup_kernel
and try to find the guilty piece of code this way?


Jonathan


signature.asc
Description: PGP signature


[tip:perf/core] perf tests ARM: Disable breakpoint tests 32-bit

2018-12-18 Thread tip-bot for Florian Fainelli
Commit-ID:  24f967337f6d6bce931425769c0f5ff5cf2d212e
Gitweb: https://git.kernel.org/tip/24f967337f6d6bce931425769c0f5ff5cf2d212e
Author: Florian Fainelli 
AuthorDate: Mon, 3 Dec 2018 11:11:36 -0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:56:27 -0300

perf tests ARM: Disable breakpoint tests 32-bit

The breakpoint tests on the ARM 32-bit kernel are broken in several
ways.

The breakpoint length requested does not necessarily match whether the
function address has the Thumb bit (bit 0) set or not, and this does
matter to the ARM kernel hw_breakpoint infrastructure. See [1] for
background.

[1]: https://lkml.org/lkml/2018/11/15/205

As Will indicated, the overflow handling would require single-stepping
which is not supported at the moment. Just disable those tests for the
ARM 32-bit platforms and update the comment above to explain these
limitations.

Co-developed-by: Will Deacon 
Signed-off-by: Florian Fainelli 
Signed-off-by: Will Deacon 
Acked-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20181203191138.2419-1-f.faine...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/bp_signal.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/tools/perf/tests/bp_signal.c b/tools/perf/tests/bp_signal.c
index a467615c5a0e..910e25e64188 100644
--- a/tools/perf/tests/bp_signal.c
+++ b/tools/perf/tests/bp_signal.c
@@ -291,12 +291,20 @@ int test__bp_signal(struct test *test __maybe_unused, int 
subtest __maybe_unused
 
 bool test__bp_signal_is_supported(void)
 {
-/*
- * The powerpc so far does not have support to even create
- * instruction breakpoint using the perf event interface.
- * Once it's there we can release this.
- */
-#if defined(__powerpc__) || defined(__s390x__)
+   /*
+* PowerPC and S390 do not support creation of instruction
+* breakpoints using the perf_event interface.
+*
+* ARM requires explicit rounding down of the instruction
+* pointer in Thumb mode, and then requires the single-step
+* to be handled explicitly in the overflow handler to avoid
+* stepping into the SIGIO handler and getting stuck on the
+* breakpointed instruction.
+*
+* Just disable the test for these architectures until these
+* issues are resolved.
+*/
+#if defined(__powerpc__) || defined(__s390x__) || defined(__arm__)
return false;
 #else
return true;


[tip:perf/core] perf vendor events intel: Fix diverse typos

2018-12-18 Thread tip-bot for Ingo Molnar
Commit-ID:  b1d6f155e1bbb67778c17aba661fb4ea4e1a3641
Gitweb: https://git.kernel.org/tip/b1d6f155e1bbb67778c17aba661fb4ea4e1a3641
Author: Ingo Molnar 
AuthorDate: Mon, 3 Dec 2018 11:22:00 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:56:31 -0300

perf vendor events intel: Fix diverse typos

Go over the tools/ files that are maintained in Arnaldo's tree and
fix common typos: half of them were in comments, the other half
in JSON files.

( Care should be taken not to re-import these typos in the future,
  if the JSON files get updated by the vendor without fixing the typos. )

No change in functionality intended.

Committer notes:

This was split from a larger patch as there are code that is,
additionally, maintained outside the kernel tree, so to ease cherry
picking and/or backporting, split this into multiple patches.

Signed-off-by: Ingo Molnar 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20181203102200.ga104...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../perf/pmu-events/arch/x86/broadwell/cache.json  |  4 +--
 .../pmu-events/arch/x86/broadwell/pipeline.json|  2 +-
 .../pmu-events/arch/x86/broadwellde/cache.json |  4 +--
 .../pmu-events/arch/x86/broadwellde/pipeline.json  |  2 +-
 .../perf/pmu-events/arch/x86/broadwellx/cache.json |  4 +--
 .../pmu-events/arch/x86/broadwellx/pipeline.json   |  2 +-
 tools/perf/pmu-events/arch/x86/jaketown/cache.json |  4 +--
 .../pmu-events/arch/x86/jaketown/pipeline.json |  2 +-
 .../pmu-events/arch/x86/knightslanding/cache.json  | 30 +++---
 .../pmu-events/arch/x86/sandybridge/cache.json |  4 +--
 .../pmu-events/arch/x86/sandybridge/pipeline.json  |  2 +-
 .../pmu-events/arch/x86/skylakex/uncore-other.json | 12 -
 12 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/tools/perf/pmu-events/arch/x86/broadwell/cache.json 
b/tools/perf/pmu-events/arch/x86/broadwell/cache.json
index bba3152ec54a..0b080b0352d8 100644
--- a/tools/perf/pmu-events/arch/x86/broadwell/cache.json
+++ b/tools/perf/pmu-events/arch/x86/broadwell/cache.json
@@ -433,7 +433,7 @@
 },
 {
 "PEBS": "1",
-"PublicDescription": "This is a precise version (that is, uses PEBS) 
of the event that counts line-splitted load uops retired to the architected 
path. A line split is across 64B cache-line which includes a page split (4K).",
+"PublicDescription": "This is a precise version (that is, uses PEBS) 
of the event that counts line-split load uops retired to the architected path. 
A line split is across 64B cache-line which includes a page split (4K).",
 "EventCode": "0xD0",
 "Counter": "0,1,2,3",
 "UMask": "0x41",
@@ -445,7 +445,7 @@
 },
 {
 "PEBS": "1",
-"PublicDescription": "This is a precise version (that is, uses PEBS) 
of the event that counts line-splitted store uops retired to the architected 
path. A line split is across 64B cache-line which includes a page split (4K).",
+"PublicDescription": "This is a precise version (that is, uses PEBS) 
of the event that counts line-split store uops retired to the architected path. 
A line split is across 64B cache-line which includes a page split (4K).",
 "EventCode": "0xD0",
 "Counter": "0,1,2,3",
 "UMask": "0x42",
diff --git a/tools/perf/pmu-events/arch/x86/broadwell/pipeline.json 
b/tools/perf/pmu-events/arch/x86/broadwell/pipeline.json
index 97c5d0784c6c..999cf3066363 100644
--- a/tools/perf/pmu-events/arch/x86/broadwell/pipeline.json
+++ b/tools/perf/pmu-events/arch/x86/broadwell/pipeline.json
@@ -317,7 +317,7 @@
 "CounterHTOff": "0,1,2,3,4,5,6,7"
 },
 {
-"PublicDescription": "This event counts stalls occured due to changing 
prefix length (66, 67 or REX.W when they change the length of the decoded 
instruction). Occurrences counting is proportional to the number of prefixes in 
a 16B-line. This may result in the following penalties: three-cycle penalty for 
each LCP in a 16-byte chunk.",
+"PublicDescription": "This event counts stalls occurred due to 
changing prefix length (66, 67 or REX.W when they change the length of the 
decoded instruction). Occurrences counting is proportional to the number of 
prefixes in a 16B-line. This may result in the following penalties: three-cycle 
penalty for each LCP in a 16-byte chunk.",
 "EventCode": "0x87",
 "Counter": "0,1,2,3",
 "UMask": "0x1",
diff --git a/tools/perf/pmu-events/arch/x86/broadwellde/cache.json 
b/tools/perf/pmu-events/arch/x86/broadwellde/cache.json
index bf243fe2a0ec..4ad425312bdc 100644
--- a/tools/perf/pmu-events/arch/x86/broadwellde/cache.json
+++ b/tools/perf/pmu-events/arch/x86/broadwellde/cache.json
@@ -439,7 +439,7 @@
 "PEBS": "1",
 "Counter": "0,1,2,3",
 "EventName": "MEM_UOPS_RETIRED.SPLIT_LOADS",
-

[tip:perf/core] tools lib traceevent: Fix diverse typos in comments

2018-12-18 Thread tip-bot for Ingo Molnar
Commit-ID:  3e449f7c36c3ac49f140b5dc3c40693e551f47d2
Gitweb: https://git.kernel.org/tip/3e449f7c36c3ac49f140b5dc3c40693e551f47d2
Author: Ingo Molnar 
AuthorDate: Mon, 3 Dec 2018 11:22:00 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:56:34 -0300

tools lib traceevent: Fix diverse typos in comments

Go over the tools/ files that are maintained in Arnaldo's tree and
fix common typos: half of them were in comments, the other half
in JSON files.

No change in functionality intended.

Committer notes:

This was split from a larger patch as there are code that is,
additionally, maintained outside the kernel tree, so to ease cherry
picking and/or backporting, split this into multiple patches.

Signed-off-by: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Steven Rostedt (VMware) 
Cc: Tzvetomir Stoyanov 
Link: http://lkml.kernel.org/r/20181203102200.ga104...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/traceevent/event-parse.c | 12 ++--
 tools/lib/traceevent/plugin_kvm.c  |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/lib/traceevent/event-parse.c 
b/tools/lib/traceevent/event-parse.c
index ffa656b868a9..a5ed291b8a9f 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -1145,7 +1145,7 @@ static enum tep_event_type read_token(char **tok)
 }
 
 /**
- * tep_read_token - access to utilites to use the pevent parser
+ * tep_read_token - access to utilities to use the pevent parser
  * @tok: The token to return
  *
  * This will parse tokens from the string given by
@@ -3258,7 +3258,7 @@ static int event_read_print(struct tep_event *event)
  * @name: the name of the common field to return
  *
  * Returns a common field from the event by the given @name.
- * This only searchs the common fields and not all field.
+ * This only searches the common fields and not all field.
  */
 struct tep_format_field *
 tep_find_common_field(struct tep_event *event, const char *name)
@@ -3302,7 +3302,7 @@ tep_find_field(struct tep_event *event, const char *name)
  * @name: the name of the field
  *
  * Returns a field by the given @name.
- * This searchs the common field names first, then
+ * This searches the common field names first, then
  * the non-common ones if a common one was not found.
  */
 struct tep_format_field *
@@ -3841,7 +3841,7 @@ static void print_bitmask_to_seq(struct tep_handle 
*pevent,
/*
 * data points to a bit mask of size bytes.
 * In the kernel, this is an array of long words, thus
-* endianess is very important.
+* endianness is very important.
 */
if (pevent->file_bigendian)
index = size - (len + 1);
@@ -5316,9 +5316,9 @@ pid_from_cmdlist(struct tep_handle *pevent, const char 
*comm, struct cmdline *ne
  * This returns the cmdline structure that holds a pid for a given
  * comm, or NULL if none found. As there may be more than one pid for
  * a given comm, the result of this call can be passed back into
- * a recurring call in the @next paramater, and then it will find the
+ * a recurring call in the @next parameter, and then it will find the
  * next pid.
- * Also, it does a linear seach, so it may be slow.
+ * Also, it does a linear search, so it may be slow.
  */
 struct cmdline *tep_data_pid_from_comm(struct tep_handle *pevent, const char 
*comm,
   struct cmdline *next)
diff --git a/tools/lib/traceevent/plugin_kvm.c 
b/tools/lib/traceevent/plugin_kvm.c
index 637be7c18476..754050eea467 100644
--- a/tools/lib/traceevent/plugin_kvm.c
+++ b/tools/lib/traceevent/plugin_kvm.c
@@ -387,7 +387,7 @@ static int kvm_mmu_print_role(struct trace_seq *s, struct 
tep_record *record,
 
/*
 * We can only use the structure if file is of the same
-* endianess.
+* endianness.
 */
if (tep_is_file_bigendian(event->pevent) ==
tep_is_host_bigendian(event->pevent)) {


[tip:perf/core] perf tools Documentation: Fix diverse typos

2018-12-18 Thread tip-bot for Ingo Molnar
Commit-ID:  1a7ea3283f7d15d7ce76a30870c3ca648adf1fc4
Gitweb: https://git.kernel.org/tip/1a7ea3283f7d15d7ce76a30870c3ca648adf1fc4
Author: Ingo Molnar 
AuthorDate: Mon, 3 Dec 2018 11:22:00 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:56:36 -0300

perf tools Documentation: Fix diverse typos

Go over the tools/ files that are maintained in Arnaldo's tree and
fix common typos: half of them were in comments, the other half
in JSON files.

No change in functionality intended.

Committer notes:

This was split from a larger patch as there are code that is,
additionally, maintained outside the kernel tree, so to ease cherry
picking and/or backporting, split this into multiple patches.

In this particular case, it affects documentation, so may be interesting
to cherry pick as it is information that is presented to the user.

Signed-off-by: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20181203102200.ga104...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-list.txt   | 2 +-
 tools/perf/Documentation/perf-report.txt | 2 +-
 tools/perf/Documentation/perf-stat.txt   | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/Documentation/perf-list.txt 
b/tools/perf/Documentation/perf-list.txt
index 667c14e56031..138fb6e94b3c 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -172,7 +172,7 @@ like cycles and instructions and some software events.
 Other PMUs and global measurements are normally root only.
 Some event qualifiers, such as "any", are also root only.
 
-This can be overriden by setting the kernel.perf_event_paranoid
+This can be overridden by setting the kernel.perf_event_paranoid
 sysctl to -1, which allows non root to use these events.
 
 For accessing trace point events perf needs to have read access to
diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index ed2bf37ab132..1a27bfe05039 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -252,7 +252,7 @@ OPTIONS
  Usually more convenient to use --branch-history for this.
 
value can be:
-   - percent: diplay overhead percent (default)
+   - percent: display overhead percent (default)
- period: display event period
- count: display event count
 
diff --git a/tools/perf/Documentation/perf-stat.txt 
b/tools/perf/Documentation/perf-stat.txt
index b10a90b6a718..4bc2085e5197 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -50,7 +50,7 @@ report::
  /sys/bus/event_source/devices//format/*
 
Note that the last two syntaxes support prefix and glob matching in
-   the PMU name to simplify creation of events accross multiple instances
+   the PMU name to simplify creation of events across multiple instances
of the same type of PMU in large systems (e.g. memory controller PMUs).
Multiple PMU instances are typical for uncore PMUs, so the prefix
'uncore_' is also ignored when performing this match.
@@ -277,7 +277,7 @@ echo 0 > /proc/sys/kernel/nmi_watchdog
 for best results. Otherwise the bottlenecks may be inconsistent
 on workload with changing phases.
 
-This enables --metric-only, unless overriden with --no-metric-only.
+This enables --metric-only, unless overridden with --no-metric-only.
 
 To interpret the results it is usually needed to know on which
 CPUs the workload runs on. If needed the CPUs can be forced using


[tip:perf/core] perf bpf-loader: Fix debugging message typo

2018-12-18 Thread tip-bot for Ingo Molnar
Commit-ID:  e4a8b0af5121392da2d40204ee330fd9e88d0858
Gitweb: https://git.kernel.org/tip/e4a8b0af5121392da2d40204ee330fd9e88d0858
Author: Ingo Molnar 
AuthorDate: Mon, 3 Dec 2018 11:22:00 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:56:39 -0300

perf bpf-loader: Fix debugging message typo

Go over the tools/ files that are maintained in Arnaldo's tree and
fix common typos: half of them were in comments, the other half
in JSON files.

No change in functionality intended.

Committer notes:

This was split from a larger patch as there are code that is,
additionally, maintained outside the kernel tree, so to ease cherry
picking and/or backporting, split this into multiple patches.

This one has information that is presented to the user, albeit in debug
mode.

Signed-off-by: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Link: http://lkml.kernel.org/r/20181203102200.ga104...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/bpf-loader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index 9a280647d829..2f3eb6d293ee 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -99,7 +99,7 @@ struct bpf_object *bpf__prepare_load(const char *filename, 
bool source)
if (err)
return ERR_PTR(-BPF_LOADER_ERRNO__COMPILE);
} else
-   pr_debug("bpf: successfull builtin compilation\n");
+   pr_debug("bpf: successful builtin compilation\n");
obj = bpf_object__open_buffer(obj_buf, obj_buf_sz, filename);
 
if (!IS_ERR_OR_NULL(obj) && llvm_param.dump_obj)


[tip:perf/core] perf tools: Fix diverse comment typos

2018-12-18 Thread tip-bot for Ingo Molnar
Commit-ID:  adba163441597ffb56141233a2ef722b75caca87
Gitweb: https://git.kernel.org/tip/adba163441597ffb56141233a2ef722b75caca87
Author: Ingo Molnar 
AuthorDate: Mon, 3 Dec 2018 11:22:00 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:56:47 -0300

perf tools: Fix diverse comment typos

Go over the tools/ files that are maintained in Arnaldo's tree and
fix common typos: half of them were in comments, the other half
in JSON files.

No change in functionality intended.

Committer notes:

This was split from a larger patch as there are code that is,
additionally, maintained outside the kernel tree, so to ease
cherry-picking and/or backporting, split this into multiple patches.

Just typos in comments, no need to backport, reducing the possibility of
possible backporting artifacts.

Signed-off-by: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20181203102200.ga104...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/x86/tests/insn-x86.c | 2 +-
 tools/perf/builtin-top.c | 2 +-
 tools/perf/builtin-trace.c   | 2 +-
 tools/perf/tests/attr.c  | 2 +-
 tools/perf/util/annotate.c   | 2 +-
 tools/perf/util/header.c | 2 +-
 tools/perf/util/hist.c   | 2 +-
 tools/perf/util/jitdump.c| 2 +-
 tools/perf/util/machine.c| 2 +-
 tools/perf/util/probe-event.c| 4 ++--
 tools/perf/util/sort.c   | 2 +-
 11 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/tools/perf/arch/x86/tests/insn-x86.c 
b/tools/perf/arch/x86/tests/insn-x86.c
index a5d24ae5810d..c3e5f4ab0d3e 100644
--- a/tools/perf/arch/x86/tests/insn-x86.c
+++ b/tools/perf/arch/x86/tests/insn-x86.c
@@ -170,7 +170,7 @@ static int test_data_set(struct test_data *dat_set, int 
x86_64)
  *
  * If the test passes %0 is returned, otherwise %-1 is returned.  Use the
  * verbose (-v) option to see all the instructions and whether or not they
- * decoded successfuly.
+ * decoded successfully.
  */
 int test__insn_x86(struct test *test __maybe_unused, int subtest 
__maybe_unused)
 {
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 1252d1759064..c59a3eb0d697 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -595,7 +595,7 @@ static void *display_thread_tui(void *arg)
 
/*
 * Initialize the uid_filter_str, in the future the TUI will allow
-* Zooming in/out UIDs. For now juse use whatever the user passed
+* Zooming in/out UIDs. For now just use whatever the user passed
 * via --uid.
 */
evlist__for_each_entry(top->evlist, pos) {
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index a57a9ae1fd4b..a6aa4589ad50 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -2782,7 +2782,7 @@ static int trace__run(struct trace *trace, int argc, 
const char **argv)
 * Now that we already used evsel->attr to ask the kernel to setup the
 * events, lets reuse evsel->attr.sample_max_stack as the limit in
 * trace__resolve_callchain(), allowing per-event max-stack settings
-* to override an explicitely set --max-stack global setting.
+* to override an explicitly set --max-stack global setting.
 */
evlist__for_each_entry(evlist, evsel) {
if (evsel__has_callchain(evsel) &&
diff --git a/tools/perf/tests/attr.c b/tools/perf/tests/attr.c
index 05dfe11c2f9e..d8426547219b 100644
--- a/tools/perf/tests/attr.c
+++ b/tools/perf/tests/attr.c
@@ -182,7 +182,7 @@ int test__attr(struct test *test __maybe_unused, int 
subtest __maybe_unused)
char path_perf[PATH_MAX];
char path_dir[PATH_MAX];
 
-   /* First try developement tree tests. */
+   /* First try development tree tests. */
if (!lstat("./tests", ))
return run_dir("./tests", "./perf");
 
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index f69d8e177fa3..51d291b0b81f 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1772,7 +1772,7 @@ static int symbol__disassemble(struct symbol *sym, struct 
annotate_args *args)
while (!feof(file)) {
/*
 * The source code line number (lineno) needs to be kept in
-* accross calls to symbol__parse_objdump_line(), so that it
+* across calls to symbol__parse_objdump_line(), so that it
 * can associate it with the instructions till the next one.
 * See disasm_line__new() and struct disasm_line::line_nr.
 */
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 9cc81d48a908..4a64739c67e7 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -2798,7 +2798,7 @@ static int perf_header__adds_write(struct perf_header 
*header,
lseek(fd, sec_start, 

Re: [PATCH v2 3/3] sched/fair: fix unnecessary increase of balance interval

2018-12-18 Thread Valentin Schneider
On 18/12/2018 13:23, Vincent Guittot wrote:
[...]
>> Ah, I think I get it: you're saying that this balance_interval increase
>> is done because it is always assumed we do an active balance with
>> busiest->nr_running > 1 && pinned tasks, and that all that is left to
>> migrate after the active_balance is pinned tasks that we can't actually
>> migrate.
>>
>> Maybe that's what we should target (as always, totally untested):
>>
>> -8<-
>> @@ -9131,18 +9144,16 @@ static int load_balance(int this_cpu, struct rq 
>> *this_rq,
>> } else
>> sd->nr_balance_failed = 0;
>>
>> -   if (likely(!active_balance)) {
>> -   /* We were unbalanced, so reset the balancing interval */
>> -   sd->balance_interval = sd->min_interval;
>> -   } else {
>> +   if (unlikely(active_balance && (env.flags & LBF_ALL_PINNED))) {
> 
> So it's not exactly LBF_ALL_PINNED but also some pinned tasks
> 

Wouldn't LBF_ALL_PINNED cover all relevant cases? It's set at the very top
of the 'if (busiest->nr_running > 1)' block and cleared whenever we find
at least one task we could pull, even if we don't pull it because of 
other reasons in can_migrate_task() (e.g. cache hotness).

If we have LBF_SOME_PINNED but not LBF_ALL_PINNED, we currently don't
increase the balance_interval, which is what we would want to maintain.

> but IIUC, you would like to extend the reset of balance  interval  to
> all the "good" reasons to trig active load balance

Right

> In fact the condition used in need_active_balance except the last
> remaining one. Good reasons are:
> - asym packing
> - /*
> * The dst_cpu is idle and the src_cpu CPU has only 1 CFS task.
> * It's worth migrating the task if the src_cpu's capacity is reduced
> * because of other sched_class or IRQs if more capacity stays
> * available on dst_cpu.
> */
> - misfit task
> 
> I can extend the test for these conditions

So that's all the need_active_balance() cases except the last
sd->nr_balance_failed one. I'd argue this could also be counted as a
"good" reason to active balance which shouldn't lead to a balance_interval
increase. Plus, it keeps to the logic of increasing the balance_interval
only when task affinity gets in the way.


[tip:perf/core] tools lib subcmd: Fix a few source code comment typos

2018-12-18 Thread tip-bot for Ingo Molnar
Commit-ID:  65c9fee2da2fbbedbba402996ddb412072e762fc
Gitweb: https://git.kernel.org/tip/65c9fee2da2fbbedbba402996ddb412072e762fc
Author: Ingo Molnar 
AuthorDate: Mon, 3 Dec 2018 11:22:00 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:56:51 -0300

tools lib subcmd: Fix a few source code comment typos

Go over the tools/ files that are maintained in Arnaldo's tree and
fix common typos: half of them were in comments, the other half
in JSON files.

No change in functionality intended.

Committer notes:

This was split from a larger patch as there are code that is,
additionally, maintained outside the kernel tree, so to ease
cherry-picking and/or backporting, split this into multiple patches.

Signed-off-by: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Josh Poimboeuf 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20181203102200.ga104...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/subcmd/parse-options.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/lib/subcmd/parse-options.h b/tools/lib/subcmd/parse-options.h
index 6ca2a8bfe716..af9def589863 100644
--- a/tools/lib/subcmd/parse-options.h
+++ b/tools/lib/subcmd/parse-options.h
@@ -71,7 +71,7 @@ typedef int parse_opt_cb(const struct option *, const char 
*arg, int unset);
  *
  * `argh`::
  *   token to explain the kind of argument this option wants. Keep it
- *   homogenous across the repository.
+ *   homogeneous across the repository.
  *
  * `help`::
  *   the short help associated to what the option does.
@@ -80,7 +80,7 @@ typedef int parse_opt_cb(const struct option *, const char 
*arg, int unset);
  *
  * `flags`::
  *   mask of parse_opt_option_flags.
- *   PARSE_OPT_OPTARG: says that the argument is optionnal (not for BOOLEANs)
+ *   PARSE_OPT_OPTARG: says that the argument is optional (not for BOOLEANs)
  *   PARSE_OPT_NOARG: says that this option takes no argument, for CALLBACKs
  *   PARSE_OPT_NONEG: says that this option cannot be negated
  *   PARSE_OPT_HIDDEN this option is skipped in the default usage, showed in


[tip:perf/core] perf trace: We need to consider "nr" if "__syscall_nr" is not there

2018-12-18 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  42da438c1bc4ad9b904401aff03678ddbf1329b0
Gitweb: https://git.kernel.org/tip/42da438c1bc4ad9b904401aff03678ddbf1329b0
Author: Arnaldo Carvalho de Melo 
AuthorDate: Wed, 5 Dec 2018 13:08:11 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:57:02 -0300

perf trace: We need to consider "nr" if "__syscall_nr" is not there

To cope with older kernels that don't have this patch backported:

  026842d148b9 ("tracing/syscalls: Rename "/format" tracepoint field name "nr" 
to "__syscall_nr:")

This makes 'perf trace' work again in RHEL7 kernels.

Cc: Taeung Song 
Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-6h1syw2isegnhb1bjmtr9...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 2a347ed7bdf4..98aff12af9e6 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -258,7 +258,8 @@ static int perf_evsel__init_syscall_tp(struct perf_evsel 
*evsel)
struct syscall_tp *sc = evsel->priv = malloc(sizeof(struct syscall_tp));
 
if (evsel->priv != NULL) {
-   if (perf_evsel__init_tp_uint_field(evsel, >id, 
"__syscall_nr"))
+   if (perf_evsel__init_tp_uint_field(evsel, >id, 
"__syscall_nr") &&
+   perf_evsel__init_tp_uint_field(evsel, >id, "nr"))
goto out_delete;
return 0;
}


[tip:perf/core] perf tools: Support 'srccode' output

2018-12-18 Thread tip-bot for Andi Kleen
Commit-ID:  dd2e18e9ac20e3ffc27cabf318e83b43ed5ddb92
Gitweb: https://git.kernel.org/tip/dd2e18e9ac20e3ffc27cabf318e83b43ed5ddb92
Author: Andi Kleen 
AuthorDate: Mon, 3 Dec 2018 16:18:48 -0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:57:07 -0300

perf tools: Support 'srccode' output

When looking at PT or brstackinsn traces with 'perf script' it can be
very useful to see the source code. This adds a simple facility to print
them with 'perf script', if the information is available through dwarf

  % perf record ...
  % perf script -F insn,ip,sym,srccode
  ...

4004c6 main
  5   for (i = 0; i < 1000; i++)
 4004cd main
  5   for (i = 0; i < 1000; i++)
 4004c6 main
  5   for (i = 0; i < 1000; i++)
 4004cd main
  5   for (i = 0; i < 1000; i++)
 4004cd main
  5   for (i = 0; i < 1000; i++)
 4004cd main
  5   for (i = 0; i < 1000; i++)
 4004cd main
  5   for (i = 0; i < 1000; i++)
 4004cd main
  5   for (i = 0; i < 1000; i++)
 4004b3 main
  6   v++;

  % perf record -b ...
  % perf script -F insn,ip,sym,srccode,brstackinsn

  ...
 main+22:
  00400543insn: e8 ca ff ff ff# PRED
  |18 f1();
  f1:
  00400512insn: 55
  |10   {
  00400513insn: 48 89 e5
  00400516insn: b8 00 00 00 00
  |11 f2();
  0040051binsn: e8 d6 ff ff ff# PRED
  f2:
  004004f6insn: 55
  |5{
  004004f7insn: 48 89 e5
  004004fainsn: 8b 05 2c 0b 20 00
  |6  c = a / b;
  00400500insn: 8b 0d 2a 0b 20 00
  00400506insn: 99
  00400507insn: f7 f9
  00400509insn: 89 05 29 0b 20 00
  0040050finsn: 90
  |7}
  00400510insn: 5d
  00400511insn: c3# PRED
  f1+14:
  00400520insn: b8 00 00 00 00
  |12 f2();
  00400525insn: e8 cc ff ff ff# PRED
  f2:
  004004f6insn: 55
  |5{
  004004f7insn: 48 89 e5
  004004fainsn: 8b 05 2c 0b 20 00
  |6  c = a / b;

Not supported for callchains currently, would need some layout changes
there.

Committer notes:

Fixed the build on Alpine Linux (3.4 .. 3.8) by addressing this
warning:

  In file included from util/srccode.c:19:0:
  /usr/include/sys/fcntl.h:1:2: error: #warning redirecting incorrect #include 
 to  [-Werror=cpp]
   #warning redirecting incorrect #include  to 
^~~
  cc1: all warnings being treated as errors

Signed-off-by: Andi Kleen 
Tested-by: Jiri Olsa 
Link: http://lkml.kernel.org/r/20181204001848.24769-1-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-script.txt |   2 +-
 tools/perf/builtin-script.c  |  47 +++-
 tools/perf/util/Build|   1 +
 tools/perf/util/evsel_fprintf.c  |   1 +
 tools/perf/util/map.c|  49 
 tools/perf/util/map.h|  16 +++
 tools/perf/util/srccode.c| 186 +++
 tools/perf/util/srccode.h|   7 ++
 tools/perf/util/srcline.c|  28 +
 tools/perf/util/srcline.h|   1 +
 tools/perf/util/thread.c |   2 +
 tools/perf/util/thread.h |   2 +
 12 files changed, 339 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Documentation/perf-script.txt 
b/tools/perf/Documentation/perf-script.txt
index a2b37ce48094..9e4def08d569 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -117,7 +117,7 @@ OPTIONS
 Comma separated list of fields to print. Options are:
 comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, symoff,
 srcline, period, iregs, uregs, brstack, brstacksym, flags, bpf-output, 
brstackinsn,
-brstackoff, callindent, insn, insnlen, synth, phys_addr, metric, misc.
+brstackoff, callindent, insn, insnlen, synth, phys_addr, metric, misc, 
srccode.
 Field list can be prepended with the type, trace, sw or hw,
 to indicate to which event type the field list applies.
 e.g., -F sw:comm,tid,time,ip,sym  and -F trace:time,cpu,trace
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 3ea98fe72f7f..3728b50e52e2 100644
--- a/tools/perf/builtin-script.c

Re: [PATCH v2] crypto: talitos - fix ablkcipher for CONFIG_VMAP_STACK

2018-12-18 Thread Horia Geanta
On 12/13/2018 9:34 AM, Christophe Leroy wrote:
> [2.364486] WARNING: CPU: 0 PID: 60 at ./arch/powerpc/include/asm/io.h:837 
> dma_nommu_map_page+0x44/0xd4
> [2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: GW
>  4.20.0-rc5-00560-g6bfb52e23a00-dirty #531
> [2.384740] NIP:  c000c540 LR: c000c584 CTR: 
> [2.389743] REGS: c95abab0 TRAP: 0700   Tainted: GW  
> (4.20.0-rc5-00560-g6bfb52e23a00-dirty)
> [2.400042] MSR:  00029032   CR: 24042204  XER: 
> [2.406669]
> [2.406669] GPR00: c02f2244 c95abb60 c6262990 c95abd80 256a 0001 
> 0001 0001
> [2.406669] GPR08:  2000 0010 0010 24042202  
> 0100 c95abd88
> [2.406669] GPR16:  c05569d4 0001 0010 c95abc88 c0615664 
> 0004 
> [2.406669] GPR24: 0010 c95abc88 c95abc88  c61ae210 c7ff6d40 
> c61ae210 3d68
> [2.441559] NIP [c000c540] dma_nommu_map_page+0x44/0xd4
> [2.446720] LR [c000c584] dma_nommu_map_page+0x88/0xd4
> [2.451762] Call Trace:
> [2.454195] [c95abb60] [82000808] 0x82000808 (unreliable)
> [2.459572] [c95abb80] [c02f2244] talitos_edesc_alloc+0xbc/0x3c8
> [2.465493] [c95abbb0] [c02f2600] ablkcipher_edesc_alloc+0x4c/0x5c
> [2.471606] [c95abbd0] [c02f4ed0] ablkcipher_encrypt+0x20/0x64
> [2.477389] [c95abbe0] [c02023b0] __test_skcipher+0x4bc/0xa08
> [2.483049] [c95abe00] [c0204b60] test_skcipher+0x2c/0xcc
> [2.488385] [c95abe20] [c0204c48] alg_test_skcipher+0x48/0xbc
> [2.494064] [c95abe40] [c0205cec] alg_test+0x164/0x2e8
> [2.499142] [c95abf00] [c0200dec] cryptomgr_test+0x48/0x50
> [2.504558] [c95abf10] [c0039ff4] kthread+0xe4/0x110
> [2.509471] [c95abf40] [c000e1d0] ret_from_kernel_thread+0x14/0x1c
> [2.515532] Instruction dump:
> [2.518468] 7c7e1b78 7c9d2378 7cbf2b78 41820054 3d20c076 8089c200 3d20c076 
> 7c84e850
> [2.526127] 8129c204 7c842e70 7f844840 419c0008 <0fe0> 2f9e 
> 54847022 7c84fa14
> [2.533960] ---[ end trace bf78d94af73fe3b8 ]---
> [2.539123] talitos ff02.crypto: master data transfer error
> [2.544775] talitos ff02.crypto: TEA error: ISR 0x2000_0040
> [2.551625] alg: skcipher: encryption failed on test 1 for 
> ecb-aes-talitos: ret=22
> 
> IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
> cannot be DMA mapped anymore.
> 
Same failure could happen for aead.

> This patch copies the IV from areq->info into the request context.
> 
There is already a per-request structure - talitos_edesc - that should be used
to save the IV.

The best approach to fix the issue (both for ablkcipher and aead) would be to
update talitos_edesc_alloc().

Thanks,
Horia


[tip:perf/core] perf tools: Allow specifying proc-map-timeout in config file

2018-12-18 Thread tip-bot for Mark Drayton
Commit-ID:  3fcb10e496505e5573a7fc386cd1152781d37fe6
Gitweb: https://git.kernel.org/tip/3fcb10e496505e5573a7fc386cd1152781d37fe6
Author: Mark Drayton 
AuthorDate: Tue, 4 Dec 2018 12:34:20 -0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:56:57 -0300

perf tools: Allow specifying proc-map-timeout in config file

The default timeout of 500ms for parsing /proc//maps files is too
short for profiling many of our services.

This can be overridden by passing --proc-map-timeout to the relevant
command but it'd be nice to globally increase our default value.

This patch permits setting a different default with the
core.proc-map-timeout config file parameter.

Signed-off-by: Mark Drayton 
Acked-by: Song Liu 
Acked-by: Namhyung Kim 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20181204203420.1683114-1-...@fb.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-config.txt |  6 ++
 tools/perf/builtin-kvm.c |  6 ++
 tools/perf/builtin-record.c  |  8 +++-
 tools/perf/builtin-top.c |  4 +---
 tools/perf/builtin-trace.c   |  5 ++---
 tools/perf/perf.h|  1 -
 tools/perf/tests/code-reading.c  |  2 +-
 tools/perf/tests/dwarf-unwind.c  |  2 +-
 tools/perf/tests/mmap-thread-lookup.c|  4 ++--
 tools/perf/util/config.c |  4 
 tools/perf/util/event.c  | 32 +---
 tools/perf/util/event.h  |  8 +++-
 tools/perf/util/machine.c|  4 +---
 tools/perf/util/machine.h|  3 ---
 14 files changed, 39 insertions(+), 50 deletions(-)

diff --git a/tools/perf/Documentation/perf-config.txt 
b/tools/perf/Documentation/perf-config.txt
index 32f4a898e3f2..661b1fb3f8ba 100644
--- a/tools/perf/Documentation/perf-config.txt
+++ b/tools/perf/Documentation/perf-config.txt
@@ -199,6 +199,12 @@ colors.*::
Colors for headers in the output of a sub-commands (top, 
report).
Default values are 'white', 'blue'.
 
+core.*::
+   core.proc-map-timeout::
+   Sets a timeout (in milliseconds) for parsing /proc//maps 
files.
+   Can be overridden by the --proc-map-timeout option on supported
+   subcommands. The default timeout is 500ms.
+
 tui.*, gtk.*::
Subcommands that can be configured here are 'top', 'report' and 
'annotate'.
These values are booleans, for example:
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index 2b1ef704169f..3d4cbc4e87c7 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -1364,7 +1364,7 @@ static int kvm_events_live(struct perf_kvm_stat *kvm,
"show events other than"
" HLT (x86 only) or Wait state (s390 only)"
" that take longer than duration usecs"),
-   OPT_UINTEGER(0, "proc-map-timeout", >opts.proc_map_timeout,
+   OPT_UINTEGER(0, "proc-map-timeout", _map_timeout,
"per thread proc mmap processing timeout in 
ms"),
OPT_END()
};
@@ -1394,7 +1394,6 @@ static int kvm_events_live(struct perf_kvm_stat *kvm,
kvm->opts.target.uses_mmap = false;
kvm->opts.target.uid_str = NULL;
kvm->opts.target.uid = UINT_MAX;
-   kvm->opts.proc_map_timeout = 500;
 
symbol__init(NULL);
disable_buildid_cache();
@@ -1453,8 +1452,7 @@ static int kvm_events_live(struct perf_kvm_stat *kvm,
perf_session__set_id_hdr_size(kvm->session);
ordered_events__set_copy_on_queue(>session->ordered_events, true);
machine__synthesize_threads(>session->machines.host, 
>opts.target,
-   kvm->evlist->threads, false,
-   kvm->opts.proc_map_timeout, 1);
+   kvm->evlist->threads, false, 1);
err = kvm_live_open_events(kvm);
if (err)
goto out;
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 4736dc96c4ca..882285fb9f64 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -867,8 +867,7 @@ static int record__synthesize_workload(struct record *rec, 
bool tail)
err = perf_event__synthesize_thread_map(>tool, thread_map,
 process_synthesized_event,
 >session->machines.host,
-rec->opts.sample_address,
-rec->opts.proc_map_timeout);
+rec->opts.sample_address);
thread_map__put(thread_map);
return err;
 }
@@ -1085,7 +1084,7 @@ static int record__synthesize(struct record *rec, bool 
tail)
 

[tip:perf/core] perf ordered_events: Rework show_progress for __ordered_events__flush

2018-12-18 Thread tip-bot for Jiri Olsa
Commit-ID:  b8494f1df875abba925374cf31bd96a464a7e5d1
Gitweb: https://git.kernel.org/tip/b8494f1df875abba925374cf31bd96a464a7e5d1
Author: Jiri Olsa 
AuthorDate: Wed, 7 Nov 2018 16:46:47 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:57:12 -0300

perf ordered_events: Rework show_progress for __ordered_events__flush

Decide to use the progress bar one level higher, we will need this in
following patch.

Signed-off-by: Jiri Olsa 
Acked-by: David S. Miller 
Acked-by: Namhyung Kim 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-ocjdukp2a8ujikkmafd0j...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/ordered-events.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c
index 1904e7f6ec84..28f0f5c95024 100644
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -219,13 +219,13 @@ int ordered_events__queue(struct ordered_events *oe, 
union perf_event *event,
return 0;
 }
 
-static int __ordered_events__flush(struct ordered_events *oe)
+static int __ordered_events__flush(struct ordered_events *oe,
+  bool show_progress)
 {
struct list_head *head = >events;
struct ordered_event *tmp, *iter;
u64 limit = oe->next_flush;
u64 last_ts = oe->last ? oe->last->timestamp : 0ULL;
-   bool show_progress = limit == ULLONG_MAX;
struct ui_progress prog;
int ret;
 
@@ -272,6 +272,7 @@ int ordered_events__flush(struct ordered_events *oe, enum 
oe_flush how)
"HALF ",
};
int err;
+   bool show_progress = false;
 
if (oe->nr_events == 0)
return 0;
@@ -279,6 +280,7 @@ int ordered_events__flush(struct ordered_events *oe, enum 
oe_flush how)
switch (how) {
case OE_FLUSH__FINAL:
oe->next_flush = ULLONG_MAX;
+   show_progress = true;
break;
 
case OE_FLUSH__HALF:
@@ -308,7 +310,7 @@ int ordered_events__flush(struct ordered_events *oe, enum 
oe_flush how)
   str[how], oe->nr_events);
pr_oe_time(oe->max_timestamp, "max_timestamp\n");
 
-   err = __ordered_events__flush(oe);
+   err = __ordered_events__flush(oe, show_progress);
 
if (!err) {
if (how == OE_FLUSH__ROUND)


Re: WARNING in ovl_instantiate

2018-12-18 Thread Dmitry Vyukov
On Mon, Dec 17, 2018 at 2:30 PM Amir Goldstein  wrote:
> > On Sun, Dec 16, 2018 at 6:00 PM Amir Goldstein  wrote:
> > >
> > > On Sat, Dec 15, 2018 at 9:34 PM syzbot
> > >  wrote:
> > > >
> > > > syzbot has found a reproducer for the following crash on:
> > > >
> > > > HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214
> > > > git tree:   linux-next
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=143f9a1540
> > > > kernel config:  
> > > > https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140
> > > > dashboard link: 
> > > > https://syzkaller.appspot.com/bug?extid=9c69c282adc4edd2b540
> > > > compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> > > > syz repro:  
> > > > https://syzkaller.appspot.com/x/repro.syz?x=12a6e54340
> > > >
> > > > IMPORTANT: if you fix the bug, please add the following tag to the 
> > > > commit:
> > > > Reported-by: syzbot+9c69c282adc4edd2b...@syzkaller.appspotmail.com
> > > >
> > > > overlayfs: filesystem on './file0' not supported as upperdir
> > > > overlayfs: filesystem on './file0' not supported as upperdir
> > > > overlayfs: filesystem on './file0' not supported as upperdir
> > > > overlayfs: filesystem on './file0' not supported as upperdir
> > > > overlayfs: filesystem on './file0' not supported as upperdir
> > > > WARNING: CPU: 1 PID: 28918 at fs/overlayfs/dir.c:263
> > > > ovl_instantiate+0x369/0x400 fs/overlayfs/dir.c:263
> > >
> > > Looks like some corner case race when using same dir as upper and lower.
> > > Doesn't look like a critical issue, I just don't know how to explain
> > > getting to this
> > > state. Couldn't reproduce on my target machine.
> > >
> > > It would have been interesting for me to see the strace of the repro 
> > > threads
> > > when that WARN happens. I wonder if anyone else has already asked for it 
> > > and
> > > how hard would it be to make that information available with the bug 
> > > report.
> >
> > Hi Amir,
> >
> > By strace you mean return values of syscalls, or something else?
> >
>
> I do mean return values.
> Some of the commands in the repro are obviously going to fail and
> some will fail conditionally depending on who wins the race.
> It could have been good for analysis of the bug to know when the
> race happened which syscall sequence took place.
>
> > We had only 1 strace-related request, and it was related to better
> > static decoding of inputs rather then dynamic behavior:
> > https://github.com/google/syzkaller/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aopen+strace
> >
> > I don't immediately see how to capture runtime behavior. It would work
> > if we dump everything onto console right away. But this will produce
> > tons of output (really lots). And that output will be intermixed
> > across parallel processes. And it will be hard to understand which
> > exactly syscalls participated in the process that provoked the crash.
> > Or maybe it's exactly syscalls from several processes interacted. Lots
> > of output can also slow down and perturb execution.
>
> Yeh, I figured. Maybe the return values of syscalls is something that 
> syzkaller
> should cache and in case of failure, report recent run sequences in format
> similar to the repro program. Just a though. Much easier said than done.

Yes, not so easy to do. This info needs to be piped through several
processes and then sent off the machine. But then again we won't know
which exactly execution provoked the crash. Reporting just any
execution can work simpler cases, but in these cases this info is not
so useful because all executions are the same and a developer can
probably predict outcome of syscalls, or re-reproduce locally and
strace. And it won't exactly for harder cases like this where 1/1
executions trigger the crash. And in such cases reporting a wrong info
may be worse then not reporting it at all.
Part of the idea is to provide enough info for a developer to
reproduce the crash locally and then they can dump any kind of info,
add additional checks, debugging output, etc. We can't cover debugging
problem in all its generality, there is no common recipe. And for
simpler cases a developer frequently does not need anything other than
kernel crash message.


> > But meanwhile I was able to reproduce this on the first run within 4
> > minutes. Maybe you need to wait longer, it does not happen
> > immediately.
>
> Oh! I wonder if this type of information, how long or how many repeats before
> crash happens is available in the bug report and I missed it - if not, could 
> be
> useful to add it.

There are some implicit signals like the log saying that it took 7 minutes:

2018/12/15 18:45:07 executed programs: 0
[ 1266.911390] IPVS: ftp: loaded support on port[0] = 21
...
[ 1665.610555] overlayfs: filesystem on './file0' not supported as upperdir
[ 1665.617831] WARNING: CPU: 1 PID: 28918 at fs/overlayfs/dir.c:263
ovl_instantiate+0x369/0x400

or mentions of any of these in the repro (which are all present 

[tip:perf/core] perf top: Save and display the lost count stats

2018-12-18 Thread tip-bot for Jiri Olsa
Commit-ID:  d24e3c98ac11b941669885cc09d88b3b970e9d66
Gitweb: https://git.kernel.org/tip/d24e3c98ac11b941669885cc09d88b3b970e9d66
Author: Jiri Olsa 
AuthorDate: Tue, 6 Nov 2018 15:45:14 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:57:36 -0300

perf top: Save and display the lost count stats

Add a 'lost count' to 'perf top' headers:

  # perf top --stdio
   PerfTop:3850 irqs/sec  kernel:49.0%  exact: 100.0% lost: 0/0 [4000Hz 
cycles:ppp],  (all, 8 CPUs)

  # perf top
  Samples: 0  of event 'cycles:ppp', 4000 Hz, Event count (approx.): 0 lost: 0/0

The format is: /

Signed-off-by: Jiri Olsa 
Acked-by: David S. Miller 
Acked-by: Namhyung Kim 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: https://lkml.kernel.org/n/tip-zo11rn270gij5jtp8fknp...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-top.c   | 27 +++
 tools/perf/ui/browsers/hists.c |  4 
 tools/perf/util/top.c  |  6 +++---
 tools/perf/util/top.h  |  2 +-
 4 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 1beb3e360521..c02ea537d5a7 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -800,6 +800,29 @@ static void perf_event__process_sample(struct perf_tool 
*tool,
addr_location__put();
 }
 
+static void
+perf_top__process_lost(struct perf_top *top, union perf_event *event,
+  struct perf_evsel *evsel)
+{
+   struct hists *hists = evsel__hists(evsel);
+
+   top->lost += event->lost.lost;
+   top->lost_total += event->lost.lost;
+   hists->stats.total_lost += event->lost.lost;
+}
+
+static void
+perf_top__process_lost_samples(struct perf_top *top,
+  union perf_event *event,
+  struct perf_evsel *evsel)
+{
+   struct hists *hists = evsel__hists(evsel);
+
+   top->lost += event->lost_samples.lost;
+   top->lost_total += event->lost_samples.lost;
+   hists->stats.total_lost_samples += event->lost_samples.lost;
+}
+
 static void perf_top__mmap_read_idx(struct perf_top *top, int idx)
 {
struct record_opts *opts = >record_opts;
@@ -865,6 +888,10 @@ static void perf_top__mmap_read_idx(struct perf_top *top, 
int idx)
if (event->header.type == PERF_RECORD_SAMPLE) {
perf_event__process_sample(>tool, event, evsel,
   , machine);
+   } else if (event->header.type == PERF_RECORD_LOST) {
+   perf_top__process_lost(top, event, evsel);
+   } else if (event->header.type == PERF_RECORD_LOST_SAMPLES) {
+   perf_top__process_lost_samples(top, event, evsel);
} else if (event->header.type < PERF_RECORD_MAX) {
hists__inc_nr_events(evsel__hists(evsel), 
event->header.type);
machine__process_event(machine, event, );
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index a96f62ca984a..ae208c16c8a3 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -2219,6 +2219,10 @@ static int hists_browser__scnprintf_title(struct 
hist_browser *browser, char *bf
if (!is_report_browser(hbt)) {
struct perf_top *top = hbt->arg;
 
+   printed += scnprintf(bf + printed, size - printed,
+" lost: %" PRIu64 "/%" PRIu64,
+top->lost, top->lost_total);
+
if (top->zero)
printed += scnprintf(bf + printed, size - printed, " 
[z]");
}
diff --git a/tools/perf/util/top.c b/tools/perf/util/top.c
index 8e517def925b..e6582fa6a4db 100644
--- a/tools/perf/util/top.c
+++ b/tools/perf/util/top.c
@@ -46,8 +46,8 @@ size_t perf_top__header_snprintf(struct perf_top *top, char 
*bf, size_t size)
samples_per_sec;
ret = SNPRINTF(bf, size,
   "   PerfTop:%8.0f irqs/sec  kernel:%4.1f%%"
-  "  exact: %4.1f%% [", samples_per_sec,
-  ksamples_percent, esamples_percent);
+  "  exact: %4.1f%% lost: %" PRIu64 "/%" PRIu64 " 
[", samples_per_sec,
+  ksamples_percent, esamples_percent, top->lost, 
top->lost_total);
} else {
float us_samples_per_sec = top->us_samples / top->delay_secs;
float guest_kernel_samples_per_sec = top->guest_kernel_samples 
/ top->delay_secs;
@@ -113,5 +113,5 @@ void perf_top__reset_sample_counters(struct perf_top *top)
 {
top->samples = top->us_samples = top->kernel_samples =
top->exact_samples = top->guest_kernel_samples =
-   top->guest_us_samples 

[tip:perf/core] perf ordered_events: Add private data member

2018-12-18 Thread tip-bot for Jiri Olsa
Commit-ID:  a4a6668a623e11f818a6abc9b5339855ee0407b1
Gitweb: https://git.kernel.org/tip/a4a6668a623e11f818a6abc9b5339855ee0407b1
Author: Jiri Olsa 
AuthorDate: Wed, 7 Nov 2018 16:58:36 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:57:30 -0300

perf ordered_events: Add private data member

We will need it in following patch, where we can't use the
container_of() trick to get the higher level object.

Signed-off-by: Jiri Olsa 
Acked-by: David S. Miller 
Acked-by: Namhyung Kim 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-vgs9aoek21v14o3obza58...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/ordered-events.c | 6 --
 tools/perf/util/ordered-events.h | 4 +++-
 tools/perf/util/session.c| 3 ++-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c
index 28f0f5c95024..d053aa0a7582 100644
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -326,7 +326,8 @@ int ordered_events__flush(struct ordered_events *oe, enum 
oe_flush how)
return err;
 }
 
-void ordered_events__init(struct ordered_events *oe, ordered_events__deliver_t 
deliver)
+void ordered_events__init(struct ordered_events *oe, ordered_events__deliver_t 
deliver,
+ void *data)
 {
INIT_LIST_HEAD(>events);
INIT_LIST_HEAD(>cache);
@@ -334,6 +335,7 @@ void ordered_events__init(struct ordered_events *oe, 
ordered_events__deliver_t d
oe->max_alloc_size = (u64) -1;
oe->cur_alloc_size = 0;
oe->deliver= deliver;
+   oe->data   = data;
 }
 
 static void
@@ -377,5 +379,5 @@ void ordered_events__reinit(struct ordered_events *oe)
 
ordered_events__free(oe);
memset(oe, '\0', sizeof(*oe));
-   ordered_events__init(oe, old_deliver);
+   ordered_events__init(oe, old_deliver, oe->data);
 }
diff --git a/tools/perf/util/ordered-events.h b/tools/perf/util/ordered-events.h
index 1338d5c345dc..507b4e4df79e 100644
--- a/tools/perf/util/ordered-events.h
+++ b/tools/perf/util/ordered-events.h
@@ -47,13 +47,15 @@ struct ordered_events {
enum oe_flushlast_flush_type;
u32  nr_unordered_events;
bool copy_on_queue;
+   void*data;
 };
 
 int ordered_events__queue(struct ordered_events *oe, union perf_event *event,
  u64 timestamp, u64 file_offset);
 void ordered_events__delete(struct ordered_events *oe, struct ordered_event 
*event);
 int ordered_events__flush(struct ordered_events *oe, enum oe_flush how);
-void ordered_events__init(struct ordered_events *oe, ordered_events__deliver_t 
deliver);
+void ordered_events__init(struct ordered_events *oe, ordered_events__deliver_t 
deliver,
+ void *data);
 void ordered_events__free(struct ordered_events *oe);
 void ordered_events__reinit(struct ordered_events *oe);
 
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index f8eab197f35c..78a06144 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -126,7 +126,8 @@ struct perf_session *perf_session__new(struct perf_data 
*data,
session->tool   = tool;
INIT_LIST_HEAD(>auxtrace_index);
machines__init(>machines);
-   ordered_events__init(>ordered_events, 
ordered_events__deliver_event);
+   ordered_events__init(>ordered_events,
+ordered_events__deliver_event, NULL);
 
if (data) {
if (perf_data__open(data))


Re: WARNING in __rcu_read_unlock

2018-12-18 Thread Stefano Brivio
[Dropping syzbot from Cc:]

On Tue, 18 Dec 2018 14:26:00 +0100
Dmitry Vyukov  wrote:

> On Tue, Dec 18, 2018 at 1:40 PM Stefano Brivio 
> wrote:
>
> > Maybe it would be nice to have a semi-automated way to isolate and
> > describe/name specific conditions found by syzbot via fuzzing and
> > turn those into tests that are then repeated periodically. I'm not
> > sure how that would look like, but I think it's still more
> > maintainable than a pile of C reproducers with forged packets in
> > selftests/net.  
> 
> It would be nice to do something like this. Filed
> https://github.com/google/syzkaller/issues/884
> However, there are few open questions that I am not sure how to
> resolve yet...

I don't have a github account, so let me comment on your questions here:

> 1. How to effectively fetch so many repros from datastore without
> hitting timeouts? We probably need to limit this to 1 repro per bug,
> but still that's many repros.

I guess this would be less of a problem if reproducers are selected
based on input from developers, instead of just taking all the
reproducers. E.g. one could answer a report with something like:

#syz regression-test: 


in this case I would have answered:

#syz regression-test: icmp-udp-in-gue-recursion
ICMP exceptions on UDP direct encapsulation in GUE

and something could be automatically appended to the test name,
perhaps e-mail and date. It would also be nice to be able to undo
this and delete a regression test.

> 2. Do we need some sorting based on namespace? E.g. stable releases
> may not include fixes for bugs fixed in upstream, then we will just
> crash lots of kernels in vain.

Same here, I guess developer input might help, but I'm not sure how to
formalise this.

> 3. syzkaller repros depend on exact syzkaller revision, new syzkaller
> won't be able to use old repros. Using C repros is much harder and
> they are not present for all bugs. Not sure what to do here.

Would it make a difference if you could use the "syz" reproducers and
translate them to C reproducer only once needed?

-- 
Stefano


[tip:perf/core] perf top: Add processing thread

2018-12-18 Thread tip-bot for Jiri Olsa
Commit-ID:  16c66bc167cc52992f66748aed7ac21396189457
Gitweb: https://git.kernel.org/tip/16c66bc167cc52992f66748aed7ac21396189457
Author: Jiri Olsa 
AuthorDate: Mon, 5 Nov 2018 13:24:55 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:57:52 -0300

perf top: Add processing thread

Add a new thread that takes care of the hist creating to alleviate the
main reader thread so it can keep perf mmaps served in time so that we
reduce the possibility of losing events.

The 'perf top' command now spawns 2 extra threads, the data processing
is the following:

  1) The main thread reads the data from mmaps and queues them to
 ordered events object;

  2) The processing threads takes the data from the ordered events
 object and create initial histogram;

  3) The GUI thread periodically sorts the initial histogram and
 presents it.

Passing the data between threads 1 and 2 is done by having 2 ordered
events queues. One is always being stored by thread 1 while the other is
flushed out in thread 2.

Passing the data between threads 2 and 3 stays the same as was initially
for threads 1 and 3.

Signed-off-by: Jiri Olsa 
Acked-by: David S. Miller 
Acked-by: Namhyung Kim 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-hhf4hllgkmle9wl1aly1j...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-top.c | 202 +++
 tools/perf/util/ordered-events.c |   4 +-
 tools/perf/util/ordered-events.h |   1 +
 tools/perf/util/top.h|   6 ++
 4 files changed, 151 insertions(+), 62 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 9fe835ba0697..75afeae7f04d 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -46,6 +46,7 @@
 #include "arch/common.h"
 
 #include "util/debug.h"
+#include "util/ordered-events.h"
 
 #include 
 #include 
@@ -830,78 +831,28 @@ static void perf_top__mmap_read_idx(struct perf_top *top, 
int idx)
 {
struct record_opts *opts = >record_opts;
struct perf_evlist *evlist = top->evlist;
-   struct perf_sample sample;
-   struct perf_evsel *evsel;
struct perf_mmap *md;
-   struct perf_session *session = top->session;
union perf_event *event;
-   struct machine *machine;
-   int ret;
 
md = opts->overwrite ? >overwrite_mmap[idx] : 
>mmap[idx];
if (perf_mmap__read_init(md) < 0)
return;
 
while ((event = perf_mmap__read_event(md)) != NULL) {
-   ret = perf_evlist__parse_sample(evlist, event, );
-   if (ret) {
-   pr_err("Can't parse sample, err = %d\n", ret);
-   goto next_event;
-   }
-
-   evsel = perf_evlist__id2evsel(session->evlist, sample.id);
-   assert(evsel != NULL);
+   u64 timestamp = -1ULL;
+   int ret;
 
-   if (event->header.type == PERF_RECORD_SAMPLE)
-   ++top->samples;
-
-   switch (sample.cpumode) {
-   case PERF_RECORD_MISC_USER:
-   ++top->us_samples;
-   if (top->hide_user_symbols)
-   goto next_event;
-   machine = >machines.host;
-   break;
-   case PERF_RECORD_MISC_KERNEL:
-   ++top->kernel_samples;
-   if (top->hide_kernel_symbols)
-   goto next_event;
-   machine = >machines.host;
+   ret = perf_evlist__parse_sample_timestamp(evlist, event, 
);
+   if (ret && ret != -1)
break;
-   case PERF_RECORD_MISC_GUEST_KERNEL:
-   ++top->guest_kernel_samples;
-   machine = perf_session__find_machine(session,
-sample.pid);
-   break;
-   case PERF_RECORD_MISC_GUEST_USER:
-   ++top->guest_us_samples;
-   /*
-* TODO: we don't process guest user from host side
-* except simple counting.
-*/
-   goto next_event;
-   default:
-   if (event->header.type == PERF_RECORD_SAMPLE)
-   goto next_event;
-   machine = >machines.host;
-   break;
-   }
 
+   pthread_mutex_lock(>qe.lock);
+   ret = ordered_events__queue(top->qe.in, event, timestamp, 0);
+   pthread_mutex_unlock(>qe.lock);
 
-   if (event->header.type == PERF_RECORD_SAMPLE) {
-   perf_event__process_sample(>tool, event, evsel,
-  

[tip:perf/core] perf top: Move lost events warning to helpline

2018-12-18 Thread tip-bot for Jiri Olsa
Commit-ID:  254de74cd14a2e64323caeffe653de0f390a4e65
Gitweb: https://git.kernel.org/tip/254de74cd14a2e64323caeffe653de0f390a4e65
Author: Jiri Olsa 
AuthorDate: Mon, 5 Nov 2018 21:34:47 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:57:45 -0300

perf top: Move lost events warning to helpline

We can't display the UI box saying that we are slow in the reader
thread.  That will make 'perf top' even slower and the user even more
angry ;-)

Move the UI box message from the reader thread to the UI thread and
change it to a helpline, so there's no need to 'press any key'.

Signed-off-by: Jiri Olsa 
Acked-by: David S. Miller 
Acked-by: Namhyung Kim 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: https://lkml.kernel.org/n/tip-x4k0iuw7tt6mywsaguq6j...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-top.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index c02ea537d5a7..9fe835ba0697 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -553,8 +553,6 @@ static void perf_top__sort_new_samples(void *arg)
struct perf_evsel *evsel = t->sym_evsel;
struct hists *hists;
 
-   perf_top__reset_sample_counters(t);
-
if (t->evlist->selected != NULL)
t->sym_evsel = t->evlist->selected;
 
@@ -571,6 +569,11 @@ static void perf_top__sort_new_samples(void *arg)
 
hists__collapse_resort(hists, NULL);
perf_evsel__output_resort(evsel, NULL);
+
+   if (t->lost)
+   pr_warning("Too slow to read ring buffer (change period (-c/-F) 
or limit CPUs (-C)\n");
+
+   perf_top__reset_sample_counters(t);
 }
 
 static void *display_thread_tui(void *arg)
@@ -908,10 +911,8 @@ static void perf_top__mmap_read(struct perf_top *top)
 {
bool overwrite = top->record_opts.overwrite;
struct perf_evlist *evlist = top->evlist;
-   unsigned long long start, end;
int i;
 
-   start = rdclock();
if (overwrite)
perf_evlist__toggle_bkw_mmap(evlist, BKW_MMAP_DATA_PENDING);
 
@@ -922,13 +923,6 @@ static void perf_top__mmap_read(struct perf_top *top)
perf_evlist__toggle_bkw_mmap(evlist, BKW_MMAP_EMPTY);
perf_evlist__toggle_bkw_mmap(evlist, BKW_MMAP_RUNNING);
}
-   end = rdclock();
-
-   if ((end - start) > (unsigned long long)top->delay_secs * NSEC_PER_SEC)
-   ui__warning("Too slow to read ring buffer.\n"
-   "Please try increasing the period (-c) or\n"
-   "decreasing the freq (-F) or\n"
-   "limiting the number of CPUs (-C)\n");
 }
 
 /*


Re: [PATCH 05/12] PCI: aardvark: add suspend to RAM support

2018-12-18 Thread Miquel Raynal
Hi Rafael, Stephen & Bjorn,

Glad to see you all in this thread that talks about:
  * adding S2RAM support to a PCIe controller driver
  * by taking into account that the PCI clock must be
{enabled before,disabled after} the PCI IP itself
  * and that it requires some tweaking in the clock driver to
promote the suspend/resume() callbacks to the NOIRQ phase
(reference there [1]).

Stephen, Rafael answered here to your remark (in thread [1]) about the
NOIRQ promotion (see below).

Bjorn, there is a question for you below about the need for a PCI
controller driver to suspend/resume in the NOIRQ phase.

Rafael, thanks for the explanation of what the PM core sequences really
are, I would need you to confirm my approach that promotes the clock
suspend/resume() callbacks to the NOIRQ phase, or otherwise give me
pointers to an alternate solution (also below).


"Rafael J. Wysocki"  wrote on Tue, 18 Dec 2018
11:54:43 +0100:

> On Monday, December 17, 2018 3:54:26 PM CET Miquel Raynal wrote:
> > Hi Rafael,
> > 
> > "Rafael J. Wysocki"  wrote on Thu, 13 Dec 2018
> > 22:50:51 +0100:
> >   
> > > On Thursday, December 13, 2018 3:30:00 PM CET Miquel Raynal wrote:  
> > > > Hi Lorenzo,
> > > > 
> > > > > > If that's really the case, then I can see how one device and it's
> > > > > > children are suspended and the irq for it is disabled but the 
> > > > > > providing
> > > > > > devices (clk, regulator, bus controller, etc.) are still fully 
> > > > > > active
> > > > > > and not suspended but in fact completely usable and able to service
> > > > > > interrupts. If that all makes sense, then I would answer the 
> > > > > > question
> > > > > > with a definitive "yes it's all fine" because the clk consumer 
> > > > > > could be
> > > > > > in the NOIRQ phase of its suspend but the clk provider wouldn't have
> > > > > > even started suspending yet when clk_disable_unprepare() is called. 
> > > > > >  
> > > > > 
> > > > > That's a very good summary and address my concern, I still question 
> > > > > this
> > > > > patch correctness (and many others that carry out clk operations in 
> > > > > S2R
> > > > > NOIRQ phase), they may work but do not tell me they are rock solid 
> > > > > given
> > > > > your accurate summary above.
> > > > 
> > > > I understand your concern but I don't see any alternative right now
> > > > and a deep rework of the PM core to respect such dependency is not
> > > > something that can be done in a reasonable amount of time.
> > > 
> > > Maybe you don't need to rework anything. :-)
> > > 
> > > Have you considered using device links?  
> > 
> > Absolutely, yes :) I am actively working on it in parallel, you can
> > check the third version there [1]. Stephen Boyd has a slightly
> > different idea of how it should be done, I will propose a v4 this week,
> > I can add you in copy if you are interested!
> > 
> > Anyway, there is one thing that is still missing:
> > * Let's have device A that requests clock B
> > * With the device link series, A is linked (as a child) to B.
> > * A suspend/resume hooks handle things in the NOIRQ phase.  
> 
> Why do you need them to run in the "noirq" phase in the first place?

I suppose (and I would like Bjorn to validate my thoughts) that this
is a limitation imposed by the PCI core, as described in this
commit:

commit ab14d45ea58eae67c739e4ba01871cae7b6c4586
Author: Thomas Petazzoni 
Date:   Tue Mar 17 15:55:45 2015 +0100

PCI: mvebu: Add suspend/resume support

Add suspend/resume support for the mvebu PCIe host driver.  Without this
commit, the system will panic at resume time when PCIe devices are
connected.

Note that we have to use the ->suspend_noirq() and ->resume_noirq() hooks,
because at resume time, the PCI fixups are done at ->resume_noirq() time,
so the PCIe controller has to be ready at this point.

Signed-off-by: Thomas Petazzoni 
Signed-off-by: Bjorn Helgaas 
Acked-by: Jason Cooper 

> 
> > * B suspend/resume hooks handle things in the default phase.
> > 
> > What I expected during a suspend:
> > 1/ ->suspend_noirq(device A)
> > 2/ ->suspend(clock B)  
> 
> This expectation is not in agreement with the documented suspend code flow,
> however.
> 
> Each phase of it is carried out for *all* devices completely before getting
> to the next phase, "prepare" first, then "suspend", "suspend_late" and
> "suspend_noirq", in this order.

Thanks for clarifying, now it is clear and it also answers Stephen
remark in the related thread [1]:

[PATCH 2/4] clk: mvebu: armada-37xx-periph: change
suspend/resume time

Stephen, said:

"This seems sad that the PM core can't "priority boost" any
suspend/resume callbacks of a device that doesn't have noirq callbacks
when a device that depends on it from the device link perspective does
have noirq callbacks."

> 
> > Unfortunately, device links do not seem to enforce any priority between
> > phases 

Re: [RESEND PATCH v5 4/6] coresight: Use PMU driver configuration for sink selection

2018-12-18 Thread Suzuki K Poulose

Hi Mathieu,

On 17/12/2018 17:21, Mathieu Poirier wrote:

This patch uses the PMU driver configuration held in event::hw::drv_config
to select a sink for each event that is created (the old sysFS way of
working is kept around for backward compatibility).

By proceeding in this way a sink can be used by multiple sessions
without having to play games with entries in sysFS.

Signed-off-by: Mathieu Poirier 
---
  drivers/hwtracing/coresight/coresight-etm-perf.c | 74 
  1 file changed, 62 insertions(+), 12 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
b/drivers/hwtracing/coresight/coresight-etm-perf.c
index f21eb28b6782..a7e1fdef07f2 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -4,6 +4,7 @@
   * Author: Mathieu Poirier 
   */
  
+#include 

  #include 
  #include 
  #include 
@@ -11,6 +12,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -177,6 +179,26 @@ static void etm_free_aux(void *data)
schedule_work(_data->work);
  }
  
+static struct coresight_device *etm_drv_config_sync(struct perf_event *event)


minor nit: The name doesn't quite imply what we do here. Did you mean
s/sync/sink ?


+{
+   struct coresight_device *sink = NULL;
+   struct pmu_drv_config *drv_config = perf_event_get_drv_config(event);
+
+   /*
+* Make sure we don't race with perf_drv_config_replace() in
+* kernel/events/core.c.
+*/
+   raw_spin_lock(_config->lock);
+
+   /* Copy what we got from user space if applicable. */
+   if (drv_config->config)
+   sink = drv_config->config;
+
+   raw_spin_unlock(_config->lock);
+
+   return sink;
+}
+
  static void *etm_setup_aux(struct perf_event *event, void **pages,
   int nr_pages, bool overwrite)
  {
@@ -190,18 +212,11 @@ static void *etm_setup_aux(struct perf_event *event, void 
**pages,
return NULL;
INIT_WORK(_data->work, free_event_data);
  
-	/*

-* In theory nothing prevent tracers in a trace session from being
-* associated with different sinks, nor having a sink per tracer.  But
-* until we have HW with this kind of topology we need to assume tracers
-* in a trace session are using the same sink.  Therefore go through
-* the coresight bus and pick the first enabled sink.
-*
-* When operated from sysFS users are responsible to enable the sink
-* while from perf, the perf tools will do it based on the choice made
-* on the cmd line.  As such the "enable_sink" flag in sysFS is reset.
-*/
-   sink = coresight_get_enabled_sink(true);
+   /* First get the sink config from user space. */
+   sink = etm_drv_config_sync(event);
+   if (!sink)
+   sink = coresight_get_enabled_sink(true);
+
if (!sink || !sink_ops(sink)->alloc_buffer)
goto err;
  
@@ -454,6 +469,40 @@ static void etm_addr_filters_sync(struct perf_event *event)

filters->nr_filters = i;
  }
  
+static int etm_drv_config_find_sink(struct device *dev, void *data)

+{
+   struct amba_device *adev = to_amba_device(dev->parent);
+   struct resource *res = >res;
+   u64 value = *((u64 *)data);
+
+   /*
+* The HW mapping of a component is unique.  If the value we've been
+* given matches the component's start address, then we must have found
+* the device we are looking for.
+*/


To be frank, I don't quite like the idea of passing the base address of the
component as the key to locate a device, (even though that is unique and readily
available). I would rather prefer a programmable way to map the keys to the
"sink" devices, which works platform agnostic (e.g, ACPI support, where the base
address is not obvious from the name). Also if we decide to use a platform
agnostic naming scheme, it becomes even more complex.

We could assign a static "id/key" exported either via the device sysfs dir or
the "pmu" dir. I prefer the latter.

Thoughts ?

And whatever we decide to choose, needs to be clearly documented under the 
Documentation/perf/cs_etm.txt.


Cheers
Suzuki


Re: [PATCH v6 1/3] x86/fpu: track AVX-512 usage of tasks

2018-12-18 Thread Thomas Gleixner
On Tue, 18 Dec 2018, Aubrey Li wrote:
> diff --git a/arch/x86/include/asm/fpu/internal.h 
> b/arch/x86/include/asm/fpu/internal.h
> index a38bf5a1e37a..8778ac172255 100644
> --- a/arch/x86/include/asm/fpu/internal.h
> +++ b/arch/x86/include/asm/fpu/internal.h
> @@ -411,6 +411,13 @@ static inline int copy_fpregs_to_fpstate(struct fpu *fpu)
>  {
>   if (likely(use_xsave())) {
>   copy_xregs_to_kernel(>state.xsave);
> +
> + /*
> +  * AVX512 state is tracked here because its use is
> +  * known to slow the max clock speed of the core.
> +  */
> + if (fpu->state.xsave.header.xfeatures & XFEATURE_MASK_AVX512)
> + fpu->avx512_timestamp = jiffies_64;

Even if unlikely this is incorrect when running a 32 bit kernel because
there jiffies_64 cannot be atomically loaded vs. a concurrent update. See
the comment in include/linux/jiffies.h right above the jiffies_64
declaration.

Thanks,

tglx



Re: [PATCH v1 03/13] powerpc/mm/32s: rework mmu_mapin_ram()

2018-12-18 Thread Christophe Leroy




Le 18/12/2018 à 15:07, Jonathan Neuschäfer a écrit :

On Tue, Dec 18, 2018 at 09:18:42AM +, Christophe Leroy wrote:

The only difference I see then are the flags. Everything else is seems
identical.

I know you tried already, but would you mind trying once more with the
following change ?


[...]

-   setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT);
+   setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_X);


Good call, with this workaround on top of patches 1-3, it boots again:

# mount -t debugfs d /sys/kernel/debug
# cat /sys/kernel/debug/powerpc/block_address_translation
---[ Instruction Block Address Translation ]---
0: 0xc000-0xc0ff 0x Kernel EXEC
1: -
2: 0xc100-0xc17f 0x0100 Kernel EXEC
3: -
4: 0xd000-0xd1ff 0x1000 Kernel EXEC
5: -
6: -
7: -

---[ Data Block Address Translation ]---
0: 0xc000-0xc0ff 0x Kernel RW
1: 0xfffe-0x 0x0d00 Kernel RW no cache guarded
2: 0xc100-0xc17f 0x0100 Kernel RW
3: -
4: 0xd000-0xd1ff 0x1000 Kernel RW
5: -
6: -
7: -


I think we may have some code trying to modify the kernel text without using
code patching functions.


Is there any faster way than to sprinkle some printks in setup_kernel
and try to find the guilty piece of code this way?


Can you start with the serie 
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=75072 ?


Christophe




Jonathan



[tip:perf/core] perf top: Use cond variable instead of a lock

2018-12-18 Thread tip-bot for Jiri Olsa
Commit-ID:  94ad6e7e3606454498aeac1fdd1b9de5c1e6735a
Gitweb: https://git.kernel.org/tip/94ad6e7e3606454498aeac1fdd1b9de5c1e6735a
Author: Jiri Olsa 
AuthorDate: Mon, 5 Nov 2018 21:23:40 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:58:03 -0300

perf top: Use cond variable instead of a lock

Use conditional variable logic to synchronize between the reading and
processing threads. Currently it's done by having mutex around rotation
code.

Using a POSIX cond variable to sync both threads after queues rotation:

  Process thread:

- Detects data
- Switches queues
- Sets rotate variable
- Waits in pthread_cond_wait()

  Read thread:

- Detects rotate is set
- Kicks the process thread with a pthread_cond_signal()

After this rotation is safely completed and both threads can continue
with the new queue.

Signed-off-by: Jiri Olsa 
Acked-by: David S. Miller 
Acked-by: Namhyung Kim 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-3rdeg23rv3brvy1pwt3ig...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-top.c | 24 +---
 tools/perf/util/top.h|  4 +++-
 2 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 75afeae7f04d..aad58643102e 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -846,13 +846,18 @@ static void perf_top__mmap_read_idx(struct perf_top *top, 
int idx)
if (ret && ret != -1)
break;
 
-   pthread_mutex_lock(>qe.lock);
ret = ordered_events__queue(top->qe.in, event, timestamp, 0);
-   pthread_mutex_unlock(>qe.lock);
-
-   perf_mmap__consume(md);
if (ret)
break;
+
+   perf_mmap__consume(md);
+
+   if (top->qe.rotate) {
+   pthread_mutex_lock(>qe.mutex);
+   top->qe.rotate = false;
+   pthread_cond_signal(>qe.cond);
+   pthread_mutex_unlock(>qe.mutex);
+   }
}
 
perf_mmap__read_done(md);
@@ -1059,9 +1064,12 @@ static void *process_thread(void *arg)
continue;
}
 
-   pthread_mutex_lock(>qe.lock);
out = rotate_queues(top);
-   pthread_mutex_unlock(>qe.lock);
+
+   pthread_mutex_lock(>qe.mutex);
+   top->qe.rotate = true;
+   pthread_cond_wait(>qe.cond, >qe.mutex);
+   pthread_mutex_unlock(>qe.mutex);
 
if (ordered_events__flush(out, OE_FLUSH__TOP))
pr_err("failed to process events\n");
@@ -1151,7 +1159,8 @@ static void init_process_thread(struct perf_top *top)
ordered_events__set_copy_on_queue(>qe.data[0], true);
ordered_events__set_copy_on_queue(>qe.data[1], true);
top->qe.in = >qe.data[0];
-   pthread_mutex_init(>qe.lock, NULL);
+   pthread_mutex_init(>qe.mutex, NULL);
+   pthread_cond_init(>qe.cond, NULL);
 }
 
 static int __cmd_top(struct perf_top *top)
@@ -1271,6 +1280,7 @@ static int __cmd_top(struct perf_top *top)
 out_join:
pthread_join(thread, NULL);
 out_join_thread:
+   pthread_cond_signal(>qe.cond);
pthread_join(thread_process, NULL);
 out_delete:
perf_session__delete(top->session);
diff --git a/tools/perf/util/top.h b/tools/perf/util/top.h
index 5f503293cfd8..5bce62ebcf14 100644
--- a/tools/perf/util/top.h
+++ b/tools/perf/util/top.h
@@ -44,7 +44,9 @@ struct perf_top {
struct {
struct ordered_events   *in;
struct ordered_eventsdata[2];
-   pthread_mutex_t  lock;
+   bool rotate;
+   pthread_mutex_t  mutex;
+   pthread_cond_t   cond;
} qe;
 };
 


Re: [PATCH v5 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver

2018-12-18 Thread Kishon Vijay Abraham I



On 17/12/18 6:04 AM, Shawn Guo wrote:
> On Tue, Dec 04, 2018 at 02:01:07PM +0800, Shawn Guo wrote:
>> Hi Kishon,
>>
>> On Tue, Dec 04, 2018 at 10:38:19AM +0530, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
>>> On 27/11/18 3:37 PM, Shawn Guo wrote:
 It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
 is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.
>>>
>>> Is this Synopsys PHY specific to Qualcomm or could it be used by other 
>>> vendors
>>> (with just changing tuning parameters)? If it could be used by other vendors
>>> then it would make sense to add this PHY driver in synopsys directory.
>>
>> My knowledge is that this Synopsys PHY is specific to Qualcomm SoCs.
>> @Sriharsha, correct me if I'm wrong.
> 
> Kishon,
> 
> Do you have any further comments on the patches?  We are close the 4.21
> merge window, and I really hope they can hit mainline with 4.21 release.
> Thanks.

Aren't we waiting for feedback from Sriharsha?

-Kishon


[tip:perf/core] perf top: Drop samples which are behind the refresh rate

2018-12-18 Thread tip-bot for Jiri Olsa
Commit-ID:  d63b9f6fea7613e2fdc8a5ef7e17ecc9cf24bf9d
Gitweb: https://git.kernel.org/tip/d63b9f6fea7613e2fdc8a5ef7e17ecc9cf24bf9d
Author: Jiri Olsa 
AuthorDate: Sun, 11 Nov 2018 19:52:06 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:58:26 -0300

perf top: Drop samples which are behind the refresh rate

Drop samples from processing thread if they get behind the latest event
read from the kernel maps. If it gets behind more than the refresh rate
(-d option), drop the sample.

Signed-off-by: Jiri Olsa 
Acked-by: David S. Miller 
Acked-by: Namhyung Kim 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: https://lkml.kernel.org/n/tip-x533ra5c1pgofvbtsizzu...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-top.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 50ec01eb7f57..234232d538c2 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -833,6 +833,8 @@ perf_top__process_lost_samples(struct perf_top *top,
hists->stats.total_lost_samples += event->lost_samples.lost;
 }
 
+static u64 last_timestamp;
+
 static void perf_top__mmap_read_idx(struct perf_top *top, int idx)
 {
struct record_opts *opts = >record_opts;
@@ -845,14 +847,13 @@ static void perf_top__mmap_read_idx(struct perf_top *top, 
int idx)
return;
 
while ((event = perf_mmap__read_event(md)) != NULL) {
-   u64 timestamp = -1ULL;
int ret;
 
-   ret = perf_evlist__parse_sample_timestamp(evlist, event, 
);
+   ret = perf_evlist__parse_sample_timestamp(evlist, event, 
_timestamp);
if (ret && ret != -1)
break;
 
-   ret = ordered_events__queue(top->qe.in, event, timestamp, 0);
+   ret = ordered_events__queue(top->qe.in, event, last_timestamp, 
0);
if (ret)
break;
 
@@ -1084,6 +1085,21 @@ static void *process_thread(void *arg)
return NULL;
 }
 
+/*
+ * Allow only 'top->delay_secs' seconds behind samples.
+ */
+static int should_drop(struct ordered_event *qevent, struct perf_top *top)
+{
+   union perf_event *event = qevent->event;
+   u64 delay_timestamp;
+
+   if (event->header.type != PERF_RECORD_SAMPLE)
+   return false;
+
+   delay_timestamp = qevent->timestamp + top->delay_secs * NSEC_PER_SEC;
+   return delay_timestamp < last_timestamp;
+}
+
 static int deliver_event(struct ordered_events *qe,
 struct ordered_event *qevent)
 {
@@ -1096,6 +1112,9 @@ static int deliver_event(struct ordered_events *qe,
struct machine *machine;
int ret = -1;
 
+   if (should_drop(qevent, top))
+   return 0;
+
ret = perf_evlist__parse_sample(evlist, event, );
if (ret) {
pr_err("Can't parse sample, err = %d\n", ret);


[tip:perf/core] perf top: Set the 'session_done' volatile variable when exiting

2018-12-18 Thread tip-bot for Jiri Olsa
Commit-ID:  c94cef4beb66d3e1f4ed0f3bf6c2663a9c3cf3c0
Gitweb: https://git.kernel.org/tip/c94cef4beb66d3e1f4ed0f3bf6c2663a9c3cf3c0
Author: Jiri Olsa 
AuthorDate: Wed, 7 Nov 2018 20:11:19 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:58:19 -0300

perf top: Set the 'session_done' volatile variable when exiting

So we can get out of hist processing ASAP on user request.

Signed-off-by: Jiri Olsa 
Acked-by: David S. Miller 
Acked-by: Namhyung Kim 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: https://lkml.kernel.org/n/tip-r8aufbgbixr2f85s3wcoa...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-top.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index aad58643102e..50ec01eb7f57 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -577,6 +577,12 @@ static void perf_top__sort_new_samples(void *arg)
perf_top__reset_sample_counters(t);
 }
 
+static void stop_top(void)
+{
+   session_done = 1;
+   done = 1;
+}
+
 static void *display_thread_tui(void *arg)
 {
struct perf_evsel *pos;
@@ -613,13 +619,13 @@ static void *display_thread_tui(void *arg)
  !top->record_opts.overwrite,
  >annotation_opts);
 
-   done = 1;
+   stop_top();
return NULL;
 }
 
 static void display_sig(int sig __maybe_unused)
 {
-   done = 1;
+   stop_top();
 }
 
 static void display_setup_sig(void)
@@ -672,7 +678,7 @@ repeat:
 
if (perf_top__handle_keypress(top, c))
goto repeat;
-   done = 1;
+   stop_top();
}
}
 


[tip:perf/core] perf top: Save and display the drop count stats

2018-12-18 Thread tip-bot for Jiri Olsa
Commit-ID:  97f7e0b33db81fd821828390e9095771abe62816
Gitweb: https://git.kernel.org/tip/97f7e0b33db81fd821828390e9095771abe62816
Author: Jiri Olsa 
AuthorDate: Sun, 11 Nov 2018 20:02:46 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:58:33 -0300

perf top: Save and display the drop count stats

Add drop count to 'perf top' headers:

  # perf top --stdio
   PerfTop:3549 irqs/sec  kernel:51.8%  exact: 100.0% lost: 0/0 drop: 0/0 
[4000Hz cycles:ppp],  (all, 8 CPUs)

  # perf top
  Samples: 0  of event 'cycles:ppp', 4000 Hz, Event count (approx.): 0 lost: 
0/0 drop: 0/0

The format is: /

Signed-off-by: Jiri Olsa 
Acked-by: David S. Miller 
Acked-by: Namhyung Kim 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-2lj87zz8tq9ye1ntax3ul...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-top.c   | 5 -
 tools/perf/ui/browsers/hists.c | 4 
 tools/perf/util/top.c  | 7 ---
 tools/perf/util/top.h  | 2 +-
 4 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 234232d538c2..9166f6087e3f 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1112,8 +1112,11 @@ static int deliver_event(struct ordered_events *qe,
struct machine *machine;
int ret = -1;
 
-   if (should_drop(qevent, top))
+   if (should_drop(qevent, top)) {
+   top->drop++;
+   top->drop_total++;
return 0;
+   }
 
ret = perf_evlist__parse_sample(evlist, event, );
if (ret) {
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index ae208c16c8a3..36b262c49f51 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -2223,6 +2223,10 @@ static int hists_browser__scnprintf_title(struct 
hist_browser *browser, char *bf
 " lost: %" PRIu64 "/%" PRIu64,
 top->lost, top->lost_total);
 
+   printed += scnprintf(bf + printed, size - printed,
+" drop: %" PRIu64 "/%" PRIu64,
+top->drop, top->drop_total);
+
if (top->zero)
printed += scnprintf(bf + printed, size - printed, " 
[z]");
}
diff --git a/tools/perf/util/top.c b/tools/perf/util/top.c
index e6582fa6a4db..31a8dee9af69 100644
--- a/tools/perf/util/top.c
+++ b/tools/perf/util/top.c
@@ -46,8 +46,9 @@ size_t perf_top__header_snprintf(struct perf_top *top, char 
*bf, size_t size)
samples_per_sec;
ret = SNPRINTF(bf, size,
   "   PerfTop:%8.0f irqs/sec  kernel:%4.1f%%"
-  "  exact: %4.1f%% lost: %" PRIu64 "/%" PRIu64 " 
[", samples_per_sec,
-  ksamples_percent, esamples_percent, top->lost, 
top->lost_total);
+  "  exact: %4.1f%% lost: %" PRIu64 "/%" PRIu64 " 
drop: %" PRIu64 "/%" PRIu64 " [",
+  samples_per_sec, ksamples_percent, 
esamples_percent,
+  top->lost, top->lost_total, top->drop, 
top->drop_total);
} else {
float us_samples_per_sec = top->us_samples / top->delay_secs;
float guest_kernel_samples_per_sec = top->guest_kernel_samples 
/ top->delay_secs;
@@ -113,5 +114,5 @@ void perf_top__reset_sample_counters(struct perf_top *top)
 {
top->samples = top->us_samples = top->kernel_samples =
top->exact_samples = top->guest_kernel_samples =
-   top->guest_us_samples = top->lost = 0;
+   top->guest_us_samples = top->lost = top->drop = 0;
 }
diff --git a/tools/perf/util/top.h b/tools/perf/util/top.h
index 5bce62ebcf14..19f95eaf75c8 100644
--- a/tools/perf/util/top.h
+++ b/tools/perf/util/top.h
@@ -22,7 +22,7 @@ struct perf_top {
 * Symbols will be added here in perf_event__process_sample and will
 * get out after decayed.
 */
-   u64samples, lost, lost_total;
+   u64samples, lost, lost_total, drop, drop_total;
u64kernel_samples, us_samples;
u64exact_samples;
u64guest_us_samples, guest_kernel_samples;


[tip:perf/core] perf top: Display slow reader warning when droping samples

2018-12-18 Thread tip-bot for Jiri Olsa
Commit-ID:  d8590430fb1e70132f1d330d6bbab7b943b35c3c
Gitweb: https://git.kernel.org/tip/d8590430fb1e70132f1d330d6bbab7b943b35c3c
Author: Jiri Olsa 
AuthorDate: Mon, 19 Nov 2018 11:12:01 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:58:40 -0300

perf top: Display slow reader warning when droping samples

Currently we display the "Too slow to read ring buffer.." helpline only
in the slow reader thread. This patch triggers it also when the
processing thread drops samples, because it has the same reason, which
is too many data on input.

Signed-off-by: Jiri Olsa 
Acked-by: David S. Miller 
Acked-by: Namhyung Kim 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: https://lkml.kernel.org/n/tip-bnev2mloavyurmgchcr3o...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-top.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 9166f6087e3f..f22c531be366 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -571,7 +571,7 @@ static void perf_top__sort_new_samples(void *arg)
hists__collapse_resort(hists, NULL);
perf_evsel__output_resort(evsel, NULL);
 
-   if (t->lost)
+   if (t->lost || t->drop)
pr_warning("Too slow to read ring buffer (change period (-c/-F) 
or limit CPUs (-C)\n");
 
perf_top__reset_sample_counters(t);


[tip:perf/core] perf top: Move perf_top__reset_sample_counters() to after counts display

2018-12-18 Thread tip-bot for Jiri Olsa
Commit-ID:  8aa5c8eddcdd055c29a4c30df2587104c07c7c2d
Gitweb: https://git.kernel.org/tip/8aa5c8eddcdd055c29a4c30df2587104c07c7c2d
Author: Jiri Olsa 
AuthorDate: Tue, 13 Nov 2018 11:15:34 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:58:47 -0300

perf top: Move perf_top__reset_sample_counters() to after counts display

Move the perf_top__reset_sample_counters() call to right after we
display the counters so we can see the updated numbers for longer.

Signed-off-by: Jiri Olsa 
Acked-by: David S. Miller 
Acked-by: Namhyung Kim 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: https://lkml.kernel.org/n/tip-o72pyiwt05f3p2juprwmz...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-top.c   | 4 
 tools/perf/ui/browsers/hists.c | 3 +++
 tools/perf/util/top.c  | 1 +
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index f22c531be366..fe3ecfb2e64b 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -273,8 +273,6 @@ static void perf_top__print_sym_table(struct perf_top *top)
perf_top__header_snprintf(top, bf, sizeof(bf));
printf("%s\n", bf);
 
-   perf_top__reset_sample_counters(top);
-
printf("%-*.*s\n", win_width, win_width, graph_dotted_line);
 
if (!top->record_opts.overwrite &&
@@ -573,8 +571,6 @@ static void perf_top__sort_new_samples(void *arg)
 
if (t->lost || t->drop)
pr_warning("Too slow to read ring buffer (change period (-c/-F) 
or limit CPUs (-C)\n");
-
-   perf_top__reset_sample_counters(t);
 }
 
 static void stop_top(void)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 36b262c49f51..ffac1d54a3d4 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -2229,8 +2229,11 @@ static int hists_browser__scnprintf_title(struct 
hist_browser *browser, char *bf
 
if (top->zero)
printed += scnprintf(bf + printed, size - printed, " 
[z]");
+
+   perf_top__reset_sample_counters(top);
}
 
+
return printed;
 }
 
diff --git a/tools/perf/util/top.c b/tools/perf/util/top.c
index 31a8dee9af69..4c8da8c4435f 100644
--- a/tools/perf/util/top.c
+++ b/tools/perf/util/top.c
@@ -107,6 +107,7 @@ size_t perf_top__header_snprintf(struct perf_top *top, char 
*bf, size_t size)
top->evlist->cpus->nr > 1 ? "s" : "");
}
 
+   perf_top__reset_sample_counters(top);
return ret;
 }
 


[tip:perf/core] perf cs-etm: Add support for ETMv3 trace decoding

2018-12-18 Thread tip-bot for Mathieu Poirier
Commit-ID:  7d0f4fefc492498a180da8fd5c9ebe11dc768c83
Gitweb: https://git.kernel.org/tip/7d0f4fefc492498a180da8fd5c9ebe11dc768c83
Author: Mathieu Poirier 
AuthorDate: Tue, 4 Dec 2018 13:39:03 -0700
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:58:59 -0300

perf cs-etm: Add support for ETMv3 trace decoding

Add support for the creation of packet printer and decoder for the ETMv3
trace architecture.  That way traces generated by tracers adhering to
that trace protocol can be handled properly by the perf infrastructure.

Signed-off-by: Mathieu Poirier 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: coresi...@lists.linaro.org
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1543955944-10042-3-git-send-email-mathieu.poir...@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c 
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index 5efb616bd609..952d1f43f3fa 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -116,6 +116,19 @@ int cs_etm_decoder__get_packet(struct cs_etm_decoder 
*decoder,
return 1;
 }
 
+static int cs_etm_decoder__gen_etmv3_config(struct cs_etm_trace_params *params,
+   ocsd_etmv3_cfg *config)
+{
+   config->reg_idr = params->etmv3.reg_idr;
+   config->reg_ctrl = params->etmv3.reg_ctrl;
+   config->reg_ccer = params->etmv3.reg_ccer;
+   config->reg_trc_id = params->etmv3.reg_trc_id;
+   config->arch_ver = ARCH_V7;
+   config->core_prof = profile_CortexA;
+
+   return 0;
+}
+
 static void cs_etm_decoder__gen_etmv4_config(struct cs_etm_trace_params 
*params,
 ocsd_etmv4_cfg *config)
 {
@@ -237,10 +250,16 @@ cs_etm_decoder__create_etm_packet_printer(struct 
cs_etm_trace_params *t_params,
  struct cs_etm_decoder *decoder)
 {
const char *decoder_name;
+   ocsd_etmv3_cfg config_etmv3;
ocsd_etmv4_cfg trace_config_etmv4;
void *trace_config;
 
switch (t_params->protocol) {
+   case CS_ETM_PROTO_ETMV3:
+   cs_etm_decoder__gen_etmv3_config(t_params, _etmv3);
+   decoder_name = OCSD_BUILTIN_DCD_ETMV3;
+   trace_config = _etmv3;
+   break;
case CS_ETM_PROTO_ETMV4i:
cs_etm_decoder__gen_etmv4_config(t_params, _config_etmv4);
decoder_name = OCSD_BUILTIN_DCD_ETMV4I;
@@ -427,11 +446,17 @@ static int cs_etm_decoder__create_etm_packet_decoder(
struct cs_etm_decoder *decoder)
 {
const char *decoder_name;
+   ocsd_etmv3_cfg config_etmv3;
ocsd_etmv4_cfg trace_config_etmv4;
void *trace_config;
u8 csid;
 
switch (t_params->protocol) {
+   case CS_ETM_PROTO_ETMV3:
+   cs_etm_decoder__gen_etmv3_config(t_params, _etmv3);
+   decoder_name = OCSD_BUILTIN_DCD_ETMV3;
+   trace_config = _etmv3;
+   break;
case CS_ETM_PROTO_ETMV4i:
cs_etm_decoder__gen_etmv4_config(t_params, _config_etmv4);
decoder_name = OCSD_BUILTIN_DCD_ETMV4I;


[tip:perf/core] perf dso: Fix unchecked usage of strncpy()

2018-12-18 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  fca5085c15255bbde203b7322c15f07ebb12f63e
Gitweb: https://git.kernel.org/tip/fca5085c15255bbde203b7322c15f07ebb12f63e
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 6 Dec 2018 10:49:46 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:59:03 -0300

perf dso: Fix unchecked usage of strncpy()

The strncpy() function may leave the destination string buffer
unterminated, better use strlcpy() that we have a __weak fallback
implementation for systems without it.

This fixes this warning on an Alpine Linux Edge system with gcc 8.2:

  In function 'decompress_kmodule',
  inlined from 'dso__decompress_kmodule_fd' at util/dso.c:305:9:
  util/dso.c:298:3: error: 'strncpy' destination unchanged after copying no 
bytes [-Werror=stringop-truncation]
 strncpy(pathname, tmpbuf, len);
 ^~
CC   /tmp/build/perf/util/values.o
CC   /tmp/build/perf/util/debug.o
  cc1: all warnings being treated as errors

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Fixes: c9a8a6131fb6 ("perf tools: Move the temp file processing into 
decompress_kmodule")
Link: https://lkml.kernel.org/n/tip-tl2hdxj64tt4k8btbi6a0...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/dso.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index bbed90e5d9bb..cee717a3794f 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -295,7 +295,7 @@ static int decompress_kmodule(struct dso *dso, const char 
*name,
unlink(tmpbuf);
 
if (pathname && (fd >= 0))
-   strncpy(pathname, tmpbuf, len);
+   strlcpy(pathname, tmpbuf, len);
 
return fd;
 }


[tip:perf/core] perf cs-etm: Add support for PTMv1.1 decoding

2018-12-18 Thread tip-bot for Mathieu Poirier
Commit-ID:  15a5cd19627a3046e7b66626abdeed3f92daafd2
Gitweb: https://git.kernel.org/tip/15a5cd19627a3046e7b66626abdeed3f92daafd2
Author: Mathieu Poirier 
AuthorDate: Tue, 4 Dec 2018 13:39:04 -0700
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:59:01 -0300

perf cs-etm: Add support for PTMv1.1 decoding

This patch is re-using the mechanic set forth by ETMv3 to add support
for PTM decoding.  Configuration for both encoding protocol is similar
but the generated stream itself is very different, hence requiring
special handling.

Signed-off-by: Mathieu Poirier 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: coresi...@lists.linaro.org
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1543955944-10042-4-git-send-email-mathieu.poir...@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 10 --
 tools/perf/util/cs-etm-decoder/cs-etm-decoder.h |  1 +
 tools/perf/util/cs-etm.c| 23 +--
 3 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c 
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index 952d1f43f3fa..0b4c8629f578 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -256,8 +256,11 @@ cs_etm_decoder__create_etm_packet_printer(struct 
cs_etm_trace_params *t_params,
 
switch (t_params->protocol) {
case CS_ETM_PROTO_ETMV3:
+   case CS_ETM_PROTO_PTM:
cs_etm_decoder__gen_etmv3_config(t_params, _etmv3);
-   decoder_name = OCSD_BUILTIN_DCD_ETMV3;
+   decoder_name = (t_params->protocol == CS_ETM_PROTO_ETMV3) ?
+   OCSD_BUILTIN_DCD_ETMV3 :
+   OCSD_BUILTIN_DCD_PTM;
trace_config = _etmv3;
break;
case CS_ETM_PROTO_ETMV4i:
@@ -453,8 +456,11 @@ static int cs_etm_decoder__create_etm_packet_decoder(
 
switch (t_params->protocol) {
case CS_ETM_PROTO_ETMV3:
+   case CS_ETM_PROTO_PTM:
cs_etm_decoder__gen_etmv3_config(t_params, _etmv3);
-   decoder_name = OCSD_BUILTIN_DCD_ETMV3;
+   decoder_name = (t_params->protocol == CS_ETM_PROTO_ETMV3) ?
+   OCSD_BUILTIN_DCD_ETMV3 :
+   OCSD_BUILTIN_DCD_PTM;
trace_config = _etmv3;
break;
case CS_ETM_PROTO_ETMV4i:
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h 
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
index 6b5525410a43..b295dd2b8292 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
@@ -96,6 +96,7 @@ enum {
CS_ETM_PROTO_ETMV3 = 1,
CS_ETM_PROTO_ETMV4i,
CS_ETM_PROTO_ETMV4d,
+   CS_ETM_PROTO_PTM,
 };
 
 enum {
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 76e509c32a28..23159c33db2a 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -83,6 +83,19 @@ static int cs_etm__update_queues(struct cs_etm_auxtrace 
*etm);
 static int cs_etm__process_timeless_queues(struct cs_etm_auxtrace *etm,
   pid_t tid, u64 time_);
 
+/* PTMs ETMIDR [11:8] set to b0011 */
+#define ETMIDR_PTM_VERSION 0x0300
+
+static u32 cs_etm__get_v7_protocol_version(u32 etmidr)
+{
+   etmidr &= ETMIDR_PTM_VERSION;
+
+   if (etmidr == ETMIDR_PTM_VERSION)
+   return CS_ETM_PROTO_PTM;
+
+   return CS_ETM_PROTO_ETMV3;
+}
+
 static void cs_etm__packet_dump(const char *pkt_string)
 {
const char *color = PERF_COLOR_BLUE;
@@ -115,7 +128,10 @@ static void cs_etm__dump_event(struct cs_etm_auxtrace *etm,
t_params = zalloc(sizeof(*t_params) * etm->num_cpu);
for (i = 0; i < etm->num_cpu; i++) {
if (etm->metadata[i][CS_ETM_MAGIC] == __perf_cs_etmv3_magic) {
-   t_params[i].protocol = CS_ETM_PROTO_ETMV3;
+   u32 etmidr = etm->metadata[i][CS_ETM_ETMIDR];
+
+   t_params[i].protocol =
+   cs_etm__get_v7_protocol_version(etmidr);
t_params[i].etmv3.reg_ctrl =
etm->metadata[i][CS_ETM_ETMCR];
t_params[i].etmv3.reg_trc_id =
@@ -366,7 +382,10 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct 
cs_etm_auxtrace *etm,
 
for (i = 0; i < etm->num_cpu; i++) {
if (etm->metadata[i][CS_ETM_MAGIC] == __perf_cs_etmv3_magic) {
-   t_params[i].protocol = CS_ETM_PROTO_ETMV3;
+   u32 etmidr = etm->metadata[i][CS_ETM_ETMIDR];
+
+ 

[tip:perf/core] perf cs-etm: Add configuration for ETMv3 trace protocol

2018-12-18 Thread tip-bot for Mathieu Poirier
Commit-ID:  78688342c547bb274b563e6d87ef7774c7686aaf
Gitweb: https://git.kernel.org/tip/78688342c547bb274b563e6d87ef7774c7686aaf
Author: Mathieu Poirier 
AuthorDate: Tue, 4 Dec 2018 13:39:02 -0700
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:58:53 -0300

perf cs-etm: Add configuration for ETMv3 trace protocol

This patch deals with the proper initialisation of configuration
parameters for the ETMv3 trace protocol in order to properly handle
packets generated by tracers following this specification.

Signed-off-by: Mathieu Poirier 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: coresi...@lists.linaro.org
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1543955944-10042-2-git-send-email-mathieu.poir...@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/cs-etm-decoder/cs-etm-decoder.h |  8 
 tools/perf/util/cs-etm.c| 54 ++---
 2 files changed, 48 insertions(+), 14 deletions(-)

diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h 
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
index 9351bd10d864..6b5525410a43 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
@@ -53,6 +53,13 @@ struct cs_etm_queue;
 typedef u32 (*cs_etm_mem_cb_type)(struct cs_etm_queue *, u64,
  size_t, u8 *);
 
+struct cs_etmv3_trace_params {
+   u32 reg_ctrl;
+   u32 reg_trc_id;
+   u32 reg_ccer;
+   u32 reg_idr;
+};
+
 struct cs_etmv4_trace_params {
u32 reg_idr0;
u32 reg_idr1;
@@ -65,6 +72,7 @@ struct cs_etmv4_trace_params {
 struct cs_etm_trace_params {
int protocol;
union {
+   struct cs_etmv3_trace_params etmv3;
struct cs_etmv4_trace_params etmv4;
};
 };
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 48ad217bf0df..76e509c32a28 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -114,15 +114,28 @@ static void cs_etm__dump_event(struct cs_etm_auxtrace 
*etm,
/* Use metadata to fill in trace parameters for trace decoder */
t_params = zalloc(sizeof(*t_params) * etm->num_cpu);
for (i = 0; i < etm->num_cpu; i++) {
-   t_params[i].protocol = CS_ETM_PROTO_ETMV4i;
-   t_params[i].etmv4.reg_idr0 = etm->metadata[i][CS_ETMV4_TRCIDR0];
-   t_params[i].etmv4.reg_idr1 = etm->metadata[i][CS_ETMV4_TRCIDR1];
-   t_params[i].etmv4.reg_idr2 = etm->metadata[i][CS_ETMV4_TRCIDR2];
-   t_params[i].etmv4.reg_idr8 = etm->metadata[i][CS_ETMV4_TRCIDR8];
-   t_params[i].etmv4.reg_configr =
+   if (etm->metadata[i][CS_ETM_MAGIC] == __perf_cs_etmv3_magic) {
+   t_params[i].protocol = CS_ETM_PROTO_ETMV3;
+   t_params[i].etmv3.reg_ctrl =
+   etm->metadata[i][CS_ETM_ETMCR];
+   t_params[i].etmv3.reg_trc_id =
+   etm->metadata[i][CS_ETM_ETMTRACEIDR];
+   } else if (etm->metadata[i][CS_ETM_MAGIC] ==
+ __perf_cs_etmv4_magic) {
+   t_params[i].protocol = CS_ETM_PROTO_ETMV4i;
+   t_params[i].etmv4.reg_idr0 =
+   etm->metadata[i][CS_ETMV4_TRCIDR0];
+   t_params[i].etmv4.reg_idr1 =
+   etm->metadata[i][CS_ETMV4_TRCIDR1];
+   t_params[i].etmv4.reg_idr2 =
+   etm->metadata[i][CS_ETMV4_TRCIDR2];
+   t_params[i].etmv4.reg_idr8 =
+   etm->metadata[i][CS_ETMV4_TRCIDR8];
+   t_params[i].etmv4.reg_configr =
etm->metadata[i][CS_ETMV4_TRCCONFIGR];
-   t_params[i].etmv4.reg_traceidr =
+   t_params[i].etmv4.reg_traceidr =
etm->metadata[i][CS_ETMV4_TRCTRACEIDR];
+   }
}
 
/* Set decoder parameters to simply print the trace packets */
@@ -352,15 +365,28 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct 
cs_etm_auxtrace *etm,
goto out_free;
 
for (i = 0; i < etm->num_cpu; i++) {
-   t_params[i].protocol = CS_ETM_PROTO_ETMV4i;
-   t_params[i].etmv4.reg_idr0 = etm->metadata[i][CS_ETMV4_TRCIDR0];
-   t_params[i].etmv4.reg_idr1 = etm->metadata[i][CS_ETMV4_TRCIDR1];
-   t_params[i].etmv4.reg_idr2 = etm->metadata[i][CS_ETMV4_TRCIDR2];
-   t_params[i].etmv4.reg_idr8 = etm->metadata[i][CS_ETMV4_TRCIDR8];
-   t_params[i].etmv4.reg_configr =
+   if (etm->metadata[i][CS_ETM_MAGIC] == 

[tip:perf/core] perf header: Fix unchecked usage of strncpy()

2018-12-18 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  7572588085a13d5db02bf159542189f52fdb507e
Gitweb: https://git.kernel.org/tip/7572588085a13d5db02bf159542189f52fdb507e
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 6 Dec 2018 11:02:57 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:59:06 -0300

perf header: Fix unchecked usage of strncpy()

The strncpy() function may leave the destination string buffer
unterminated, better use strlcpy() that we have a __weak fallback
implementation for systems without it.

This fixes this warning on an Alpine Linux Edge system with gcc 8.2:

  util/header.c: In function 'perf_event__synthesize_event_update_unit':
  util/header.c:3586:2: error: 'strncpy' output truncated before terminating 
nul copying as many bytes from a string as its length 
[-Werror=stringop-truncation]
strncpy(ev->data, evsel->unit, size);
^~~~
  util/header.c:3579:16: note: length computed here
size_t size = strlen(evsel->unit);
  ^~~

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Fixes: a6e5281780d1 ("perf tools: Add event_update event unit type")
Link: https://lkml.kernel.org/n/tip-fiikh5nay70bv4zskw2aa...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/header.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 4a64739c67e7..c87cfe6b7c96 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -3583,7 +3583,7 @@ perf_event__synthesize_event_update_unit(struct perf_tool 
*tool,
if (ev == NULL)
return -ENOMEM;
 
-   strncpy(ev->data, evsel->unit, size);
+   strlcpy(ev->data, evsel->unit, size + 1);
err = process(tool, (union perf_event *)ev, NULL, NULL);
free(ev);
return err;


[tip:perf/core] perf header: Fix unchecked usage of strncpy()

2018-12-18 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  5192bde7d98c99f2cd80225649e3c2e7493722f7
Gitweb: https://git.kernel.org/tip/5192bde7d98c99f2cd80225649e3c2e7493722f7
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 6 Dec 2018 11:09:46 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:59:08 -0300

perf header: Fix unchecked usage of strncpy()

The strncpy() function may leave the destination string buffer
unterminated, better use strlcpy() that we have a __weak fallback
implementation for systems without it.

This fixes this warning on an Alpine Linux Edge system with gcc 8.2:

  util/header.c: In function 'perf_event__synthesize_event_update_name':
  util/header.c:3625:2: error: 'strncpy' output truncated before terminating 
nul copying as many bytes from a string as its length 
[-Werror=stringop-truncation]
strncpy(ev->data, evsel->name, len);
^~~
  util/header.c:3618:15: note: length computed here
size_t len = strlen(evsel->name);
 ^~~

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Fixes: a6e5281780d1 ("perf tools: Add event_update event unit type")
Link: https://lkml.kernel.org/n/tip-wycz66iy8dl2z3yifgqf8...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/header.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index c87cfe6b7c96..1171d8400bf4 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -3622,7 +3622,7 @@ perf_event__synthesize_event_update_name(struct perf_tool 
*tool,
if (ev == NULL)
return -ENOMEM;
 
-   strncpy(ev->data, evsel->name, len);
+   strlcpy(ev->data, evsel->name, len + 1);
err = process(tool, (union perf_event*) ev, NULL, NULL);
free(ev);
return err;


[tip:perf/core] perf help: Remove needless use of strncpy()

2018-12-18 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  b6313899f4ed2e76b8375cf8069556f5b94fbff0
Gitweb: https://git.kernel.org/tip/b6313899f4ed2e76b8375cf8069556f5b94fbff0
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 6 Dec 2018 11:20:21 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:59:18 -0300

perf help: Remove needless use of strncpy()

Since we make sure the destination buffer has at least strlen(orig) + 1,
no need to do a strncpy(dest, orig, strlen(orig)), just use strcpy(dest,
orig).

This silences this gcc 8.2 warning on Alpine Linux:

  In function 'add_man_viewer',
  inlined from 'perf_help_config' at builtin-help.c:284:3:
  builtin-help.c:192:2: error: 'strncpy' output truncated before terminating 
nul copying as many bytes from a string as its length 
[-Werror=stringop-truncation]
strncpy((*p)->name, name, len);
^~
  builtin-help.c: In function 'perf_help_config':
  builtin-help.c:187:15: note: length computed here
size_t len = strlen(name);
 ^~~~

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Fixes: 078006012401 ("perf_counter tools: add in basic glue from Git")
Link: https://lkml.kernel.org/n/tip-2f69l7drca427ob4km8i7...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-help.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-help.c b/tools/perf/builtin-help.c
index 1c41b4eaf73c..3d29d0524a89 100644
--- a/tools/perf/builtin-help.c
+++ b/tools/perf/builtin-help.c
@@ -189,7 +189,7 @@ static void add_man_viewer(const char *name)
while (*p)
p = &((*p)->next);
*p = zalloc(sizeof(**p) + len + 1);
-   strncpy((*p)->name, name, len);
+   strcpy((*p)->name, name);
 }
 
 static int supported_man_viewer(const char *name, size_t len)


Re: [PATCH V4 0/3] * mm/kvm/vfio/ppc64: Migrate compound pages out of CMA region

2018-12-18 Thread Michal Hocko
On Fri 07-12-18 15:12:26, Andrew Morton wrote:
> On Wed, 21 Nov 2018 14:52:56 +0530 "Aneesh Kumar K.V" 
>  wrote:
> 
> > Subject: [PATCH V4 0/3] * mm/kvm/vfio/ppc64: Migrate compound pages out of 
> > CMA region
> 
> Asterisk in title is strange?
> 
> > ppc64 use CMA area for the allocation of guest page table (hash page 
> > table). We won't
> > be able to start guest if we fail to allocate hash page table. We have 
> > observed
> > hash table allocation failure because we failed to migrate pages out of CMA 
> > region
> > because they were pinned. This happen when we are using VFIO. VFIO on ppc64 
> > pins
> > the entire guest RAM. If the guest RAM pages get allocated out of CMA 
> > region, we
> > won't be able to migrate those pages. The pages are also pinned for the 
> > lifetime of the
> > guest.
> > 
> > Currently we support migration of non-compound pages. With THP and with the 
> > addition of
> >  hugetlb migration we can end up allocating compound pages from CMA region. 
> > This
> > patch series add support for migrating compound pages. The first path adds 
> > the helper
> > get_user_pages_cma_migrate() which pin the page making sure we migrate them 
> > out of
> > CMA region before incrementing the reference count. 
> 
> Very little review activity.  Perhaps Andrey and/or Michal can find the
> time..

I will unlikely find some time before the end of the year. Sorry about
that.
-- 
Michal Hocko
SUSE Labs


[tip:perf/core] perf svghelper: Fix unchecked usage of strncpy()

2018-12-18 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  2f5302533f306d5ee87bd375aef9ca35b91762cb
Gitweb: https://git.kernel.org/tip/2f5302533f306d5ee87bd375aef9ca35b91762cb
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 6 Dec 2018 11:29:48 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:59:20 -0300

perf svghelper: Fix unchecked usage of strncpy()

The strncpy() function may leave the destination string buffer
unterminated, better use strlcpy() that we have a __weak fallback
implementation for systems without it.

In this specific case this would only happen if fgets() was buggy, as
its man page states that it should read one less byte than the size of
the destination buffer, so that it can put the nul byte at the end of
it, so it would never copy 255 non-nul chars, as fgets reads into the
orig buffer at most 254 non-nul chars and terminates it. But lets just
switch to strlcpy to keep the original intent and silence the gcc 8.2
warning.

This fixes this warning on an Alpine Linux Edge system with gcc 8.2:

  In function 'cpu_model',
  inlined from 'svg_cpu_box' at util/svghelper.c:378:2:
  util/svghelper.c:337:5: error: 'strncpy' output may be truncated copying 255 
bytes from a string of length 255 [-Werror=stringop-truncation]
   strncpy(cpu_m, [13], 255);
   ^

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Arjan van de Ven 
Fixes: f48d55ce7871 ("perf: Add a SVG helper library file")
Link: https://lkml.kernel.org/n/tip-xzkoo0gyr56gej39ltivu...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/svghelper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/svghelper.c b/tools/perf/util/svghelper.c
index 1cbada2dc6be..f735ee038713 100644
--- a/tools/perf/util/svghelper.c
+++ b/tools/perf/util/svghelper.c
@@ -334,7 +334,7 @@ static char *cpu_model(void)
if (file) {
while (fgets(buf, 255, file)) {
if (strstr(buf, "model name")) {
-   strncpy(cpu_m, [13], 255);
+   strlcpy(cpu_m, [13], 255);
break;
}
}


[tip:perf/core] perf ui helpline: Use strlcpy() as a shorter form of strncpy() + explicit set nul

2018-12-18 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  4d0f16d059ddb91424480d88473f7392f24aebdc
Gitweb: https://git.kernel.org/tip/4d0f16d059ddb91424480d88473f7392f24aebdc
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 6 Dec 2018 11:41:03 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:59:23 -0300

perf ui helpline: Use strlcpy() as a shorter form of strncpy() + explicit set 
nul

The strncpy() function may leave the destination string buffer
unterminated, better use strlcpy() that we have a __weak fallback
implementation for systems without it.

In this case we are actually setting the null byte at the right place,
but since we pass the buffer size as the limit to strncpy() and not
it minus one, gcc ends up warning us about that, see below. So, lets
just switch to the shorter form provided by strlcpy().

This fixes this warning on an Alpine Linux Edge system with gcc 8.2:

  ui/tui/helpline.c: In function 'tui_helpline__push':
  ui/tui/helpline.c:27:2: error: 'strncpy' specified bound 512 equals 
destination size [-Werror=stringop-truncation]
strncpy(ui_helpline__current, msg, sz)[sz - 1] = '\0';
^~
  cc1: all warnings being treated as errors

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Fixes: e6e904687949 ("perf ui: Introduce struct ui_helpline")
Link: https://lkml.kernel.org/n/tip-d1wz0hjjsh19xbalw69qp...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/tui/helpline.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/ui/tui/helpline.c b/tools/perf/ui/tui/helpline.c
index 4ca799aadb4e..93d6b7240285 100644
--- a/tools/perf/ui/tui/helpline.c
+++ b/tools/perf/ui/tui/helpline.c
@@ -24,7 +24,7 @@ static void tui_helpline__push(const char *msg)
SLsmg_set_color(0);
SLsmg_write_nstring((char *)msg, SLtt_Screen_Cols);
SLsmg_refresh();
-   strncpy(ui_helpline__current, msg, sz)[sz - 1] = '\0';
+   strlcpy(ui_helpline__current, msg, sz);
 }
 
 static int tui_helpline__show(const char *format, va_list ap)


[tip:perf/core] perf parse-events: Fix unchecked usage of strncpy()

2018-12-18 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  bd8d57fb7e25e9fcf67a9eef5fa13aabe2016e07
Gitweb: https://git.kernel.org/tip/bd8d57fb7e25e9fcf67a9eef5fa13aabe2016e07
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 6 Dec 2018 13:52:13 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:59:30 -0300

perf parse-events: Fix unchecked usage of strncpy()

The strncpy() function may leave the destination string buffer
unterminated, better use strlcpy() that we have a __weak fallback
implementation for systems without it.

This fixes this warning on an Alpine Linux Edge system with gcc 8.2:

  util/parse-events.c: In function 'print_symbol_events':
  util/parse-events.c:2465:4: error: 'strncpy' specified bound 100 equals 
destination size [-Werror=stringop-truncation]
  strncpy(name, syms->symbol, MAX_NAME_LEN);
  ^
  In function 'print_symbol_events.constprop',
  inlined from 'print_events' at util/parse-events.c:2508:2:
  util/parse-events.c:2465:4: error: 'strncpy' specified bound 100 equals 
destination size [-Werror=stringop-truncation]
  strncpy(name, syms->symbol, MAX_NAME_LEN);
  ^
  In function 'print_symbol_events.constprop',
  inlined from 'print_events' at util/parse-events.c:2511:2:
  util/parse-events.c:2465:4: error: 'strncpy' specified bound 100 equals 
destination size [-Werror=stringop-truncation]
  strncpy(name, syms->symbol, MAX_NAME_LEN);
  ^
  cc1: all warnings being treated as errors

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Fixes: 947b4ad1d198 ("perf list: Fix max event string size")
Link: https://lkml.kernel.org/n/tip-b663e33bm6x8hrkie4uxh...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/parse-events.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 59be3466d64d..920e1e6551dd 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -2462,7 +2462,7 @@ restart:
if (!name_only && strlen(syms->alias))
snprintf(name, MAX_NAME_LEN, "%s OR %s", syms->symbol, 
syms->alias);
else
-   strncpy(name, syms->symbol, MAX_NAME_LEN);
+   strlcpy(name, syms->symbol, MAX_NAME_LEN);
 
evt_list[evt_i] = strdup(name);
if (evt_list[evt_i] == NULL)


[tip:perf/core] perf probe: Fix unchecked usage of strncpy()

2018-12-18 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  bef0b8970f27da5ca223e522a174d03e2587761d
Gitweb: https://git.kernel.org/tip/bef0b8970f27da5ca223e522a174d03e2587761d
Author: Arnaldo Carvalho de Melo 
AuthorDate: Thu, 6 Dec 2018 11:50:08 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:59:28 -0300

perf probe: Fix unchecked usage of strncpy()

The strncpy() function may leave the destination string buffer
unterminated, better use strlcpy() that we have a __weak fallback
implementation for systems without it.

In this case the 'target' buffer is coming from a list of build-ids that
are expected to have a len of at most (SBUILD_ID_SIZE - 1) chars, so
probably we're safe, but since we're using strncpy() here, use strlcpy()
instead to provide the intended safety checking without the using the
problematic strncpy() function.

This fixes this warning on an Alpine Linux Edge system with gcc 8.2:

  util/probe-file.c: In function 'probe_cache__open.isra.5':
  util/probe-file.c:427:3: error: 'strncpy' specified bound 41 equals 
destination size [-Werror=stringop-truncation]
 strncpy(sbuildid, target, SBUILD_ID_SIZE);
 ^
  cc1: all warnings being treated as errors

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Fixes: 1f3736c9c833 ("perf probe: Show all cached probes")
Link: https://lkml.kernel.org/n/tip-l7n8ggc9kl38qtdlouke5...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index aac7817d9e14..0b1195cad0e5 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -424,7 +424,7 @@ static int probe_cache__open(struct probe_cache *pcache, 
const char *target,
 
if (target && build_id_cache__cached(target)) {
/* This is a cached buildid */
-   strncpy(sbuildid, target, SBUILD_ID_SIZE);
+   strlcpy(sbuildid, target, SBUILD_ID_SIZE);
dir_name = build_id_cache__linkname(sbuildid, NULL, 0);
goto found;
}


[tip:perf/core] perf vendor events intel: Fix Load_Miss_Real_Latency on SKL/SKX

2018-12-18 Thread tip-bot for Andi Kleen
Commit-ID:  91b2b97025097ce7ca7536bc87eba2bf14760fb4
Gitweb: https://git.kernel.org/tip/91b2b97025097ce7ca7536bc87eba2bf14760fb4
Author: Andi Kleen 
AuthorDate: Mon, 19 Nov 2018 21:06:35 -0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:59:32 -0300

perf vendor events intel: Fix Load_Miss_Real_Latency on SKL/SKX

Fix incorrect event names for the Load_Miss_Real_Latency metric for
Skylake and Skylake Server.

Fixes https://github.com/andikleen/pmu-tools/issues/158

Before:

  % perf stat -M Load_Miss_Real_Latency true
  event syntax error: 
'..ss.pending,mem_load_retired.l1_miss_ps,mem_load_retired.fb_hit_ps}:W'
\___ parser error

   Usage: perf stat [] []

  -M, --metrics 
monitor specified metrics or metric groups 
(separated by ,)

After:

  % perf stat -M Load_Miss_Real_Latency true

   Performance counter stats for 'true':

 279,204  l1d_pend_miss.pending # 14.0 
Load_Miss_Real_Latency
   4,784  mem_load_uops_retired.l1_miss
  15,188  mem_load_uops_retired.hit_lfb

 0.000899640 seconds time elapsed

Signed-off-by: Andi Kleen 
Acked-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Link: http://lkml.kernel.org/r/20181120050635.4215-1-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/pmu-events/arch/x86/skylake/skl-metrics.json  | 2 +-
 tools/perf/pmu-events/arch/x86/skylakex/skx-metrics.json | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/pmu-events/arch/x86/skylake/skl-metrics.json 
b/tools/perf/pmu-events/arch/x86/skylake/skl-metrics.json
index 36c903faed0b..71e9737f4614 100644
--- a/tools/perf/pmu-events/arch/x86/skylake/skl-metrics.json
+++ b/tools/perf/pmu-events/arch/x86/skylake/skl-metrics.json
@@ -73,7 +73,7 @@
 },
 {
 "BriefDescription": "Actual Average Latency for L1 data-cache miss 
demand loads",
-"MetricExpr": "L1D_PEND_MISS.PENDING / ( MEM_LOAD_RETIRED.L1_MISS_PS + 
MEM_LOAD_RETIRED.FB_HIT_PS )",
+"MetricExpr": "L1D_PEND_MISS.PENDING / ( MEM_LOAD_RETIRED.L1_MISS + 
MEM_LOAD_RETIRED.FB_HIT )",
 "MetricGroup": "Memory_Bound;Memory_Lat",
 "MetricName": "Load_Miss_Real_Latency"
 },
diff --git a/tools/perf/pmu-events/arch/x86/skylakex/skx-metrics.json 
b/tools/perf/pmu-events/arch/x86/skylakex/skx-metrics.json
index 36c903faed0b..71e9737f4614 100644
--- a/tools/perf/pmu-events/arch/x86/skylakex/skx-metrics.json
+++ b/tools/perf/pmu-events/arch/x86/skylakex/skx-metrics.json
@@ -73,7 +73,7 @@
 },
 {
 "BriefDescription": "Actual Average Latency for L1 data-cache miss 
demand loads",
-"MetricExpr": "L1D_PEND_MISS.PENDING / ( MEM_LOAD_RETIRED.L1_MISS_PS + 
MEM_LOAD_RETIRED.FB_HIT_PS )",
+"MetricExpr": "L1D_PEND_MISS.PENDING / ( MEM_LOAD_RETIRED.L1_MISS + 
MEM_LOAD_RETIRED.FB_HIT )",
 "MetricGroup": "Memory_Bound;Memory_Lat",
 "MetricName": "Load_Miss_Real_Latency"
 },


[PATCH net-next] MAINTAINERS: Add a maintainer for Microsemi switches

2018-12-18 Thread Alexandre Belloni
Microsemi has been bought by Microchip and Microchip is supporting those
switches.

Signed-off-by: Alexandre Belloni 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 50223cba6ddb..48abe982aed6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9823,6 +9823,7 @@ F:Documentation/scsi/smartpqi.txt
 
 MICROSEMI ETHERNET SWITCH DRIVER
 M: Alexandre Belloni 
+M: Microchip Linux Driver Support 
 L: net...@vger.kernel.org
 S: Supported
 F: drivers/net/ethernet/mscc/
-- 
2.20.0



Re: [RFC][PATCH] printk: increase devkmsg write() ratelimit

2018-12-18 Thread Borislav Petkov
On Tue, Dec 18, 2018 at 10:07:50PM +0900, Sergey Senozhatsky wrote:
> This is right before shutdown. dmesg is not really available anymore.
> I can only guess why do they write it to devkmsg - to make it appear
> on the serial/net console, perhaps. Dunno.

But still, why do we want to see those messages and enlarge the
ratelimit for that? Do they contain any particularly important
information?

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.


[tip:perf/core] perf config: Modify size factor of snprintf

2018-12-18 Thread tip-bot for Sihyeon Jang
Commit-ID:  75c375c0ae7cc75cec6683ee2539937c60c3e4af
Gitweb: https://git.kernel.org/tip/75c375c0ae7cc75cec6683ee2539937c60c3e4af
Author: Sihyeon Jang 
AuthorDate: Sun, 2 Dec 2018 00:46:03 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:59:40 -0300

perf config: Modify size factor of snprintf

According to definition of snprintf, it gets size factor including
null('\0') byte.  So '-1' is not neccessary. Also it will be helpful
unfied style with other cases. (eg. builtin-script.c)

Signed-off-by: Sihyeon Jang 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: http://lkml.kernel.org/r/20181201154603.10093-1-uneedsihy...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/config.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index 3beb4cf44c31..1ea8f898f1a1 100644
--- a/tools/perf/util/config.c
+++ b/tools/perf/util/config.c
@@ -815,14 +815,14 @@ int config_error_nonbool(const char *var)
 void set_buildid_dir(const char *dir)
 {
if (dir)
-   scnprintf(buildid_dir, MAXPATHLEN-1, "%s", dir);
+   scnprintf(buildid_dir, MAXPATHLEN, "%s", dir);
 
/* default to $HOME/.debug */
if (buildid_dir[0] == '\0') {
char *home = getenv("HOME");
 
if (home) {
-   snprintf(buildid_dir, MAXPATHLEN-1, "%s/%s",
+   snprintf(buildid_dir, MAXPATHLEN, "%s/%s",
 home, DEBUG_CACHE_DIR);
} else {
strncpy(buildid_dir, DEBUG_CACHE_DIR, MAXPATHLEN-1);


[PATCH] MAINTAINERS: Add a maintainer for MSCC MIPS SoCs

2018-12-18 Thread Alexandre Belloni
Microsemi has been bought by Microchip and Microchip is supporting those
SoCs.

Signed-off-by: Alexandre Belloni 
---
 MAINTAINERS | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index f4855974f325..50223cba6ddb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9801,8 +9801,9 @@ F:drivers/dma/at_xdmac.c
 
 MICROSEMI MIPS SOCS
 M: Alexandre Belloni 
+M: Microchip Linux Driver Support 
 L: linux-m...@linux-mips.org
-S: Maintained
+S: Supported
 F: arch/mips/generic/board-ocelot.c
 F: arch/mips/configs/generic/board-ocelot.config
 F: arch/mips/boot/dts/mscc/
-- 
2.20.0



Re: [PATCH v5 5/6] net: maclorawan: Implement maclorawan class module

2018-12-18 Thread Jian-Hong Pan
> Sun, Dec 16, 2018 at 11:18:59AM CET, starni...@g.ncu.edu.tw wrote:
> >LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa devices.
> >
> >This patch implements part of Class A end-devices SoftMAC defined in
> >LoRaWAN(TM) Specification Ver. 1.0.2:
> >1. End-device receive slot timing
> >2. Only single channel and single data rate for now
> >3. Unconfirmed data up/down message types
> >
> >On the other side, it defines the basic interface and operation
> >functions for compatible LoRa device drivers.
> >
> >Signed-off-by: Jian-Hong Pan 
> >---
> >V2:
> >- Split the LoRaWAN class module patch in V1 into LoRaWAN socket and
> >  LoRaWAN Soft MAC modules
> >- Modify for Big/Little-Endian
> >- Use SPDX license identifiers
> >
> >V3:
> >- Remove the decoration word - inline of the functions
> >- Order local variables from longest to shortest line in the functions
> >- Change the calling mac_cb function to lrw_get_mac_cb macro
> >
> >V4:
> >- Fix the delay period between RX window#1 and window#2
> >- Fix by coding style report from scripts/checkpatch.pl
> >
> >V5:
> >- Initial rx_skb_list when it is allocated with LoRa hardware
> >- Check the sk_buff's data length before access it
> >- Deal FPort field and decrypt payload in lrw_parse_frame function
> >- Drop the recieved frame if parse failed
> >- Fix the bug which passes wrong skb properties from maclorawan to lorawan 
> >module
> >
> > net/maclorawan/Kconfig  |  14 +
> > net/maclorawan/Makefile |   2 +
> > net/maclorawan/mac.c| 555 
> > net/maclorawan/main.c   | 606 
> > 4 files changed, 1177 insertions(+)
> > create mode 100644 net/maclorawan/Kconfig
> > create mode 100644 net/maclorawan/Makefile
> > create mode 100644 net/maclorawan/mac.c
> > create mode 100644 net/maclorawan/main.c
>
>
> I don't get it. In patch "Add LoRaWAN API declaration for LoRa devices"
> you add headers for "API" and here you implement functions. That is just
> weird. Does it mean you can have other implementations?

LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa PHY.
This part is soft-MAC as Andreas mentioned
http://lists.infradead.org/pipermail/linux-lpwan/2018-December/10.html

> Also, you don't really have any user of this API in the set. Please
> introduce at least 1 driver, preferably more (I see that Andreas has
> multiple ones in his patchset). You cannot push kernel infrastructure
> without kernel user.

The soft-MAC is suitable for the LoRa chips' device drivers, like
sx1276/77/78/79, RFM95/96/97/98W ...
Still waiting for Andreas' sx1276 version 2 patch and more discussion.
For example, how to make PF_LORA and PF_LORAWAN like Ethernet, PF_INET
and PF_INET6 don't need separate devices either, both use eth0.
https://lkml.org/lkml/2018/8/3/266

Jian-Hong Pan


[tip:perf/core] perf annotate: Introduce basic support for ARC

2018-12-18 Thread tip-bot for Eugeniy Paltsev
Commit-ID:  6d99a79cb40da3eddafef844b7a679fe5162f224
Gitweb: https://git.kernel.org/tip/6d99a79cb40da3eddafef844b7a679fe5162f224
Author: Eugeniy Paltsev 
AuthorDate: Tue, 4 Dec 2018 20:51:18 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:59:42 -0300

perf annotate: Introduce basic support for ARC

Introduce basic 'perf annotate' support for ARC to be able to use
anotation via stdio interface.

Signed-off-by: Eugeniy Paltsev 
Cc: Alexander Shishkin 
Cc: Alexey Brodkin 
Cc: Jiri Olsa 
Cc: linux-snps-...@lists.infradead.org
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Vineet Gupta 
Link: 
http://lkml.kernel.org/r/20181204175118.25232-1-eugeniy.palt...@synopsys.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/arc/annotate/instructions.c |  9 +
 tools/perf/arch/common.c| 11 ++-
 tools/perf/util/annotate.c  |  5 +
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/tools/perf/arch/arc/annotate/instructions.c 
b/tools/perf/arch/arc/annotate/instructions.c
new file mode 100644
index ..2f00e995c7e3
--- /dev/null
+++ b/tools/perf/arch/arc/annotate/instructions.c
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
+#include 
+
+static int arc__annotate_init(struct arch *arch, char *cpuid __maybe_unused)
+{
+   arch->initialized = true;
+   arch->objdump.comment_char = ';';
+   return 0;
+}
diff --git a/tools/perf/arch/common.c b/tools/perf/arch/common.c
index 5f69fd0b745a..f3824ca7c20b 100644
--- a/tools/perf/arch/common.c
+++ b/tools/perf/arch/common.c
@@ -5,6 +5,13 @@
 #include "../util/util.h"
 #include "../util/debug.h"
 
+const char *const arc_triplets[] = {
+   "arc-linux-",
+   "arc-snps-linux-uclibc-",
+   "arc-snps-linux-gnu-",
+   NULL
+};
+
 const char *const arm_triplets[] = {
"arm-eabi-",
"arm-linux-androideabi-",
@@ -147,7 +154,9 @@ static int perf_env__lookup_binutils_path(struct perf_env 
*env,
zfree();
}
 
-   if (!strcmp(arch, "arm"))
+   if (!strcmp(arch, "arc"))
+   path_list = arc_triplets;
+   else if (!strcmp(arch, "arm"))
path_list = arm_triplets;
else if (!strcmp(arch, "arm64"))
path_list = arm64_triplets;
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 51d291b0b81f..ac9805e0bc76 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -134,6 +134,7 @@ static int arch__associate_ins_ops(struct arch* arch, const 
char *name, struct i
return 0;
 }
 
+#include "arch/arc/annotate/instructions.c"
 #include "arch/arm/annotate/instructions.c"
 #include "arch/arm64/annotate/instructions.c"
 #include "arch/x86/annotate/instructions.c"
@@ -142,6 +143,10 @@ static int arch__associate_ins_ops(struct arch* arch, 
const char *name, struct i
 #include "arch/sparc/annotate/instructions.c"
 
 static struct arch architectures[] = {
+   {
+   .name = "arc",
+   .init = arc__annotate_init,
+   },
{
.name = "arm",
.init = arm__annotate_init,


[tip:perf/core] perf ordered_events: Add ordered_events__flush_time interface

2018-12-18 Thread tip-bot for Jiri Olsa
Commit-ID:  68ca5d07de207e56f57e887de23b03fbc1ebc2a6
Gitweb: https://git.kernel.org/tip/68ca5d07de207e56f57e887de23b03fbc1ebc2a6
Author: Jiri Olsa 
AuthorDate: Wed, 5 Dec 2018 17:05:07 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 15:02:12 -0300

perf ordered_events: Add ordered_events__flush_time interface

Add OE_FLUSH__TIME flush type, to be able to flush only certain amount
of the queue based on the provided timestamp. It will be used in the
following patches.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Dmitry Levin 
Cc: Eugene Syromiatnikov 
Cc: Frederic Weisbecker 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Steven Rostedt (VMware) 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20181205160509.1168-7-jo...@kernel.org
[ Fix the build on older systems such as centos 5 and 6 where 'time' shadows a 
global declaration ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/ordered-events.c | 23 +++
 tools/perf/util/ordered-events.h |  2 ++
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c
index c5412db05683..46965643020b 100644
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -219,8 +219,7 @@ int ordered_events__queue(struct ordered_events *oe, union 
perf_event *event,
return 0;
 }
 
-static int __ordered_events__flush(struct ordered_events *oe,
-  bool show_progress)
+static int do_flush(struct ordered_events *oe, bool show_progress)
 {
struct list_head *head = >events;
struct ordered_event *tmp, *iter;
@@ -263,7 +262,8 @@ static int __ordered_events__flush(struct ordered_events 
*oe,
return 0;
 }
 
-int ordered_events__flush(struct ordered_events *oe, enum oe_flush how)
+static int __ordered_events__flush(struct ordered_events *oe, enum oe_flush 
how,
+  u64 timestamp)
 {
static const char * const str[] = {
"NONE",
@@ -302,6 +302,11 @@ int ordered_events__flush(struct ordered_events *oe, enum 
oe_flush how)
break;
}
 
+   case OE_FLUSH__TIME:
+   oe->next_flush = timestamp;
+   show_progress = false;
+   break;
+
case OE_FLUSH__ROUND:
case OE_FLUSH__NONE:
default:
@@ -312,7 +317,7 @@ int ordered_events__flush(struct ordered_events *oe, enum 
oe_flush how)
   str[how], oe->nr_events);
pr_oe_time(oe->max_timestamp, "max_timestamp\n");
 
-   err = __ordered_events__flush(oe, show_progress);
+   err = do_flush(oe, show_progress);
 
if (!err) {
if (how == OE_FLUSH__ROUND)
@@ -328,6 +333,16 @@ int ordered_events__flush(struct ordered_events *oe, enum 
oe_flush how)
return err;
 }
 
+int ordered_events__flush(struct ordered_events *oe, enum oe_flush how)
+{
+   return __ordered_events__flush(oe, how, 0);
+}
+
+int ordered_events__flush_time(struct ordered_events *oe, u64 timestamp)
+{
+   return __ordered_events__flush(oe, OE_FLUSH__TIME, timestamp);
+}
+
 void ordered_events__init(struct ordered_events *oe, ordered_events__deliver_t 
deliver,
  void *data)
 {
diff --git a/tools/perf/util/ordered-events.h b/tools/perf/util/ordered-events.h
index 0c6e26aec0e3..f352af20e167 100644
--- a/tools/perf/util/ordered-events.h
+++ b/tools/perf/util/ordered-events.h
@@ -19,6 +19,7 @@ enum oe_flush {
OE_FLUSH__ROUND,
OE_FLUSH__HALF,
OE_FLUSH__TOP,
+   OE_FLUSH__TIME,
 };
 
 struct ordered_events;
@@ -55,6 +56,7 @@ int ordered_events__queue(struct ordered_events *oe, union 
perf_event *event,
  u64 timestamp, u64 file_offset);
 void ordered_events__delete(struct ordered_events *oe, struct ordered_event 
*event);
 int ordered_events__flush(struct ordered_events *oe, enum oe_flush how);
+int ordered_events__flush_time(struct ordered_events *oe, u64 timestamp);
 void ordered_events__init(struct ordered_events *oe, ordered_events__deliver_t 
deliver,
  void *data);
 void ordered_events__free(struct ordered_events *oe);


[tip:perf/core] perf record: Fix memory leak on AIO objects deallocation

2018-12-18 Thread tip-bot for Alexey Budankov
Commit-ID:  c8dd6ee51a4d0a119c8b4121d83008215e3209ed
Gitweb: https://git.kernel.org/tip/c8dd6ee51a4d0a119c8b4121d83008215e3209ed
Author: Alexey Budankov 
AuthorDate: Wed, 5 Dec 2018 20:19:41 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 14:59:34 -0300

perf record: Fix memory leak on AIO objects deallocation

Sending a part which was missed between v12 and v13 of the patch set
introducing AIO trace streaming for perf record mode.

The part is essential to avoid memory leakage during deallocation of AIO
related trace data buffers.

Signed-off-by: Alexey Budankov 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/e5d3154e-1583-83bb-9527-28ddbc6db...@linux.intel.com
[ No need to test for NULL before calling zfree() ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/mmap.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
index ab30555d2afc..8fc39311a30d 100644
--- a/tools/perf/util/mmap.c
+++ b/tools/perf/util/mmap.c
@@ -207,8 +207,14 @@ static int perf_mmap__aio_mmap(struct perf_mmap *map, 
struct mmap_params *mp)
 
 static void perf_mmap__aio_munmap(struct perf_mmap *map)
 {
+   int i;
+
+   for (i = 0; i < map->aio.nr_cblocks; ++i)
+   zfree(>aio.data[i]);
if (map->aio.data)
zfree(>aio.data);
+   zfree(>aio.cblocks);
+   zfree(>aio.aiocb);
 }
 
 int perf_mmap__aio_push(struct perf_mmap *md, void *to, int idx,


[tip:perf/core] perf trace: Move event delivery to a new deliver_event() function

2018-12-18 Thread tip-bot for Jiri Olsa
Commit-ID:  1f44b3e2fc5d7a2c5f6d1e67c80ebc226d6bd25f
Gitweb: https://git.kernel.org/tip/1f44b3e2fc5d7a2c5f6d1e67c80ebc226d6bd25f
Author: Jiri Olsa 
AuthorDate: Wed, 5 Dec 2018 17:05:08 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 15:02:17 -0300

perf trace: Move event delivery to a new deliver_event() function

Mov event delivery code to a new trace__deliver_event() function, so
it's easier to add ordered delivery coming in the following patches.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Dmitry Levin 
Cc: Eugene Syromiatnikov 
Cc: Frederic Weisbecker 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Steven Rostedt (VMware) 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20181205160509.1168-8-jo...@kernel.org
[ Add trace__ prefix to the deliver_event method ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 98aff12af9e6..3b6b1fecf2bb 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -2637,6 +2637,21 @@ static int trace__set_filter_pids(struct trace *trace)
return err;
 }
 
+static int trace__deliver_event(struct trace *trace, union perf_event *event)
+{
+   struct perf_evlist *evlist = trace->evlist;
+   struct perf_sample sample;
+   int err;
+
+   err = perf_evlist__parse_sample(evlist, event, );
+   if (err)
+   fprintf(trace->output, "Can't parse sample, err = %d, 
skipping...\n", err);
+   else
+   trace__handle_event(trace, event, );
+
+   return 0;
+}
+
 static int trace__run(struct trace *trace, int argc, const char **argv)
 {
struct perf_evlist *evlist = trace->evlist;
@@ -2802,18 +2817,10 @@ again:
continue;
 
while ((event = perf_mmap__read_event(md)) != NULL) {
-   struct perf_sample sample;
-
++trace->nr_events;
 
-   err = perf_evlist__parse_sample(evlist, event, );
-   if (err) {
-   fprintf(trace->output, "Can't parse sample, err 
= %d, skipping...\n", err);
-   goto next_event;
-   }
+   trace__deliver_event(trace, event);
 
-   trace__handle_event(trace, event, );
-next_event:
perf_mmap__consume(md);
 
if (interrupted)


[tip:perf/core] perf ordered_events: Add first_time() method

2018-12-18 Thread tip-bot for Jiri Olsa
Commit-ID:  83356b3d124af5ae472ce1358222f6b7749d2322
Gitweb: https://git.kernel.org/tip/83356b3d124af5ae472ce1358222f6b7749d2322
Author: Jiri Olsa 
AuthorDate: Thu, 6 Dec 2018 14:38:52 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 15:02:17 -0300

perf ordered_events: Add first_time() method

To get the timestamp in the first event in the queue.

Signed-off-by: Jiri Olsa 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Dmitry Levin 
Cc: Eugene Syromiatnikov 
Cc: Frederic Weisbecker 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Steven Rostedt (VMware) 
Cc: Thomas Gleixner 
Link: https://lkml.kernel.org/n/tip-appp27jw1ul8kgg872j43...@git.kernel.org
[ split from a larger patch ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/ordered-events.c | 11 +++
 tools/perf/util/ordered-events.h |  1 +
 2 files changed, 12 insertions(+)

diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c
index 46965643020b..897589507d97 100644
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -343,6 +343,17 @@ int ordered_events__flush_time(struct ordered_events *oe, 
u64 timestamp)
return __ordered_events__flush(oe, OE_FLUSH__TIME, timestamp);
 }
 
+u64 ordered_events__first_time(struct ordered_events *oe)
+{
+   struct ordered_event *event;
+
+   if (list_empty(>events))
+   return 0;
+
+   event = list_first_entry(>events, struct ordered_event, list);
+   return event->timestamp;
+}
+
 void ordered_events__init(struct ordered_events *oe, ordered_events__deliver_t 
deliver,
  void *data)
 {
diff --git a/tools/perf/util/ordered-events.h b/tools/perf/util/ordered-events.h
index f352af20e167..0920fb0ec6cc 100644
--- a/tools/perf/util/ordered-events.h
+++ b/tools/perf/util/ordered-events.h
@@ -61,6 +61,7 @@ void ordered_events__init(struct ordered_events *oe, 
ordered_events__deliver_t d
  void *data);
 void ordered_events__free(struct ordered_events *oe);
 void ordered_events__reinit(struct ordered_events *oe);
+u64 ordered_events__first_time(struct ordered_events *oe);
 
 static inline
 void ordered_events__set_alloc_size(struct ordered_events *oe, u64 size)


[PATCH v3 -next] staging: fbtft: fix strncmp() size warning

2018-12-18 Thread YueHaibing
strncmp() stops comparing when either the end of one of the first two
arguments is reached or when 'n' characters have been compared, whichever
comes first.That means that strncmp(s1, s2, n) is equivalent to
strcmp(s1, s2) if n exceeds the length of s1 or the length of s2.

This patch avoids that the following warning is reported by smatch:

drivers/staging/fbtft/fbtft_device.c:1458
 fbtft_device_init() error: strncmp() '"list"' too small (5 vs 32)

Signed-off-by: YueHaibing 
---
v2-v3: fix messed patch title
---
 drivers/staging/fbtft/fbtft_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/fbtft/fbtft_device.c 
b/drivers/staging/fbtft/fbtft_device.c
index 50e97da..046f9d3 100644
--- a/drivers/staging/fbtft/fbtft_device.c
+++ b/drivers/staging/fbtft/fbtft_device.c
@@ -1455,7 +1455,7 @@ static int __init fbtft_device_init(void)
}
 
/* name=list lists all supported displays */
-   if (strncmp(name, "list", FBTFT_GPIO_NAME_SIZE) == 0) {
+   if (strcmp(name, "list") == 0) {
pr_info("Supported displays:\n");
 
for (i = 0; i < ARRAY_SIZE(displays); i++)
-- 
2.7.0




[tip:perf/core] perf trace: Add ordered processing

2018-12-18 Thread tip-bot for Jiri Olsa
Commit-ID:  028713aa8389d960cb1935a9954327bdaa163cf8
Gitweb: https://git.kernel.org/tip/028713aa8389d960cb1935a9954327bdaa163cf8
Author: Jiri Olsa 
AuthorDate: Wed, 5 Dec 2018 17:05:09 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Dec 2018 15:21:17 -0300

perf trace: Add ordered processing

Sort events to provide the precise outcome of ordered events, just like
is done with 'perf report' and 'perf top'.

Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Dmitry Levin 
Cc: Eugene Syromiatnikov 
Cc: Frederic Weisbecker 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Steven Rostedt (VMware) 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20181205160509.1168-9-jo...@kernel.org
[ split from a larger patch, added trace__ prefixes to new 'struct trace' 
methods ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c | 52 +-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 3b6b1fecf2bb..366ec3c8f580 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -127,6 +127,10 @@ struct trace {
boolforce;
boolvfs_getname;
int trace_pgfaults;
+   struct {
+   struct ordered_events   data;
+   u64 last;
+   } oe;
 };
 
 struct tp_field {
@@ -2652,6 +2656,42 @@ static int trace__deliver_event(struct trace *trace, 
union perf_event *event)
return 0;
 }
 
+static int trace__flush_ordered_events(struct trace *trace)
+{
+   u64 first = ordered_events__first_time(>oe.data);
+   u64 flush = trace->oe.last - NSEC_PER_SEC;
+
+   /* Is there some thing to flush.. */
+   if (first && first < flush)
+   return ordered_events__flush_time(>oe.data, flush);
+
+   return 0;
+}
+
+static int trace__deliver_ordered_event(struct trace *trace, union perf_event 
*event)
+{
+   struct perf_evlist *evlist = trace->evlist;
+   int err;
+
+   err = perf_evlist__parse_sample_timestamp(evlist, event, 
>oe.last);
+   if (err && err != -1)
+   return err;
+
+   err = ordered_events__queue(>oe.data, event, trace->oe.last, 0);
+   if (err)
+   return err;
+
+   return trace__flush_ordered_events(trace);
+}
+
+static int ordered_events__deliver_event(struct ordered_events *oe,
+struct ordered_event *event)
+{
+   struct trace *trace = container_of(oe, struct trace, oe.data);
+
+   return trace__deliver_event(trace, event->event);
+}
+
 static int trace__run(struct trace *trace, int argc, const char **argv)
 {
struct perf_evlist *evlist = trace->evlist;
@@ -2819,7 +2859,9 @@ again:
while ((event = perf_mmap__read_event(md)) != NULL) {
++trace->nr_events;
 
-   trace__deliver_event(trace, event);
+   err = trace__deliver_ordered_event(trace, event);
+   if (err)
+   goto out_disable;
 
perf_mmap__consume(md);
 
@@ -2842,6 +2884,9 @@ again:
draining = true;
 
goto again;
+   } else {
+   if (trace__flush_ordered_events(trace))
+   goto out_disable;
}
} else {
goto again;
@@ -2852,6 +2897,8 @@ out_disable:
 
perf_evlist__disable(evlist);
 
+   ordered_events__flush(>oe.data, OE_FLUSH__FINAL);
+
if (!err) {
if (trace->summary)
trace__fprintf_thread_summary(trace, trace->output);
@@ -3562,6 +3609,9 @@ int cmd_trace(int argc, const char **argv)
}
}
 
+   ordered_events__init(, ordered_events__deliver_event, 
);
+   ordered_events__set_copy_on_queue(, true);
+
/*
 * If we are augmenting syscalls, then combine what we put in the
 * __augmented_syscalls__ BPF map with what is in the


Re: [PATCH 09/14] mm, compaction: Ignore the fragmentation avoidance boost for isolation and compaction

2018-12-18 Thread Mel Gorman
On Tue, Dec 18, 2018 at 02:58:33PM +0100, Vlastimil Babka wrote:
> On 12/18/18 2:51 PM, Mel Gorman wrote:
> > On Tue, Dec 18, 2018 at 01:36:42PM +0100, Vlastimil Babka wrote:
> >> On 12/15/18 12:03 AM, Mel Gorman wrote:
> >>> When pageblocks get fragmented, watermarks are artifically boosted to 
> >>> pages
> >>> are reclaimed to avoid further fragmentation events. However, compaction
> >>> is often either fragmentation-neutral or moving movable pages away from
> >>> unmovable/reclaimable pages. As the actual watermarks are preserved,
> >>> allow compaction to ignore the boost factor.
> >>
> >> Right, I should have realized that when reviewing the boost patch. I
> >> think it would be useful to do the same change in
> >> __compaction_suitable() as well. Compaction has its own "gap".
> >>
> > 
> > That gap is somewhat static though so I'm a bit more wary of it. However,
> 
> Well, watermark boost is dynamic, but based on allocations stealing from
> other migratetypes, not reflecting compaction chances of success.
> 

True.

> > the check in __isolate_free_page looks too agressive. We isolate in
> > units of COMPACT_CLUSTER_MAX yet the watermark check there is based on
> > the allocation request. That means for THP that we check if 512 pages
> > can be allocated when only somewhere between 1 and 32 is needed for that
> > compaction cycle to complete. Adjusting that might be more appropriate?
> 
> AFAIU the code in __isolate_free_page() reflects that if there's less
> than 512 free pages gap, we might form a high-order page for THP but
> won't be able to allocate it afterwards due to watermark.

Yeah but it used to be a lot more important when watermark checking for
high-orders was very different. Now, if the watermark is met for order-0
and a large enough free page is allocated, the allocation succeeds so
it's a lot less relevant than it used to be. kswapd will still run in
the background for order-0 if necessary so a heavy watermark check there
doesn't really help.

-- 
Mel Gorman
SUSE Labs


Re: [PATCH] kbuild: fix false positive warning/error about missing libelf

2018-12-18 Thread Qian Cai
On Tue, 2018-12-18 at 14:25 +0900, Masahiro Yamada wrote:
> For the same reason as commit 25896d073d8a ("x86/build: Fix compiler
> support check for CONFIG_RETPOLINE"), you cannot put this $(error ...)
> into the parse stage of the top Makefile.
> 
> Perhaps I'd propose a more sophisticated solution later, but this is
> the best I can do for now.
> 
> Link: https://lkml.org/lkml/2017/12/25/211
> Reported-by: Paul Gortmaker 
> Reported-by: Bernd Edlinger 
> Reported-by: Qian Cai 
> Cc: Josh Poimboeuf 
> Signed-off-by: Masahiro Yamada 
> ---
> 

Tested-by: Qian Cai 

>  Makefile | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 56d5270..d45856f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -962,11 +962,6 @@ ifdef CONFIG_STACK_VALIDATION
>    ifeq ($(has_libelf),1)
>  objtool_target := tools/objtool FORCE
>    else
> -ifdef CONFIG_UNWINDER_ORC
> -  $(error "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please
> install libelf-dev, libelf-devel or elfutils-libelf-devel")
> -else
> -  $(warning "Cannot use CONFIG_STACK_VALIDATION=y, please install libelf-
> dev, libelf-devel or elfutils-libelf-devel")
> -endif
>  SKIP_STACK_VALIDATION := 1
>  export SKIP_STACK_VALIDATION
>    endif
> @@ -1125,6 +1120,14 @@ uapi-asm-generic:
>  
>  PHONY += prepare-objtool
>  prepare-objtool: $(objtool_target)
> +ifeq ($(SKIP_STACK_VALIDATION),1)
> +ifdef CONFIG_UNWINDER_ORC
> + @echo "error: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y,
> please install libelf-dev, libelf-devel or elfutils-libelf-devel" >&2
> + @false
> +else
> + @echo "warning: Cannot use CONFIG_STACK_VALIDATION=y, please install
> libelf-dev, libelf-devel or elfutils-libelf-devel" >&2
> +endif
> +endif
>  
>  # Generate some files
>  # ---


Re: [PATCH] usb: dwc2: gadget: fix ISOC frame overflow handling

2018-12-18 Thread John Keeping
Hi Minas,

On Fri, 14 Dec 2018 09:00:08 +
Minas Harutyunyan  wrote:
> First of all, sorry for delayed answer.
> Looks like similar issue seen by Andrzej Pietrasiewicz 
> : "dwc2 isochronous transfers issues". Same 
> feedback provided to Andrzej.
> 
> I run tests on 4.20.0-rc4 in DDMA. By default IN ISOC traffic failed 
> because of BNA interrupts. It's happen because UAC2 requests count
> set by default to 2. Our core and driver can't work in DDMA with
> descriptor list length equal to 2. It's not possible on time prepare
> next descriptors to avoid BNA interrupt.
> 
> By changing UAC2_DEF_REQ_NUM to 4 all audio gadget tests passed
> smoothly. Could you please apply this patch and run tests in DDMA
> mode:
> 
> diff --git a/drivers/usb/gadget/function/u_uac2.h 
> b/drivers/usb/gadget/function/u_uac2.h
> index 8362ee572e1e..5e649259ab76 100644
> --- a/drivers/usb/gadget/function/u_uac2.h
> +++ b/drivers/usb/gadget/function/u_uac2.h
> @@ -21,7 +21,7 @@
>   #define UAC2_DEF_CCHMASK 0x3
>   #define UAC2_DEF_CSRATE 64000
>   #define UAC2_DEF_CSSIZE 2
> -#define UAC2_DEF_REQ_NUM 2
> +#define UAC2_DEF_REQ_NUM 4
> 
>   struct f_uac2_opts {
>  struct usb_function_instancefunc_inst;
> 
> 
> If it will OK on your side also then will switch to BDMA mode and
> debug.

With DDMA enabled, I see the following error after the stream has been
running for a while (anything from a few seconds to a few minutes):

-- >8 --
[ 1798.836322] dwc2 ff58.usb: dwc2_hsotg_ep_disable: called for ep0
[ 1798.836329] dwc2 ff58.usb: dwc2_hsotg_ep_disable: called for ep0
[ 1798.851092] dwc2 ff58.usb: new device is high-speed
[ 1798.924461] dwc2 ff58.usb: new device is high-speed
[ 1798.982887] dwc2 ff58.usb: new address 25
[ 1799.002463] configfs-gadget gadget: high-speed config #1: config
-- 8< --

On the host side (Linux 4.18.16 Intel xHCI), I see this logged at the
same time:

-- >8 --
[1735740.716242] retire_capture_urb: usb 1-2.2.7: frame 0 active: -71
[1735740.716990] retire_capture_urb: usb 1-2.2.7: frame 0 active: -71
[1735740.717906] retire_capture_urb: usb 1-2.2.7: frame 0 active: -71
[1735740.718905] retire_capture_urb: usb 1-2.2.7: frame 0 active: -71
[1735740.719916] retire_capture_urb: usb 1-2.2.7: frame 0 active: -71
[1735740.720032] usb 1-2.2-port7: disabled by hub (EMI?), re-enabling...
[1735740.720036] usb 1-2.2.7: USB disconnect, device number 28
[1735740.937500] usb 1-2.2.7: new high-speed USB device number 29 using xhci_hcd
-- 8< --

The device does then enumerate and works for a period of time before the
same error happens again.


Regards,
John


Re: [PATCH 05/13] clk: qcom: apcs-msm8916: get parent clock names from DT

2018-12-18 Thread Niklas Cassel
On Mon, Dec 17, 2018 at 03:37:43PM -0800, Stephen Boyd wrote:
> Quoting Jorge Ramirez-Ortiz (2018-12-17 01:46:22)
> > Allow accessing the parent clock names required for the driver
> > operation by using the device tree node.
> > 
> > This permits extending the driver to other platforms without having to
> > modify its source code.
> > 
> > For backwards compatibility leave previous values as default.
> 
> Why do we need to maintain backwards compatibility? Isn't is required
> that the nodes have clocks properties?
> 

Hello Stephen,


This is the existing DT nodes for msm8916:

   a53pll: clock@b016000 {
compatible = "qcom,msm8916-a53pll";
reg = <0xb016000 0x40>;
#clock-cells = <0>;
};

apcs: mailbox@b011000 {
compatible = "qcom,msm8916-apcs-kpss-global", "syscon";
reg = <0xb011000 0x1000>;
#mbox-cells = <1>;
clocks = <>;
#clock-cells = <0>;
};


This is the (suggested) DT nodes for qcs404:

apcs_hfpll: clock-controller@0b016000 {
compatible = "qcom,hfpll";
reg = <0x0b016000 0x30>;
#clock-cells = <0>;
clock-output-names = "apcs_hfpll";
clocks = <_board>;
clock-names = "xo";
};

apcs_glb: mailbox@b011000 {
compatible = "qcom,qcs404-apcs-apps-global", "syscon";
reg = <0x0b011000 0x1000>;
#mbox-cells = <1>;
clocks = < GCC_GPLL0_AO_OUT_MAIN>, <_hfpll>;
clock-names = "aux", "pll";
#clock-cells = <0>;
};

qcs404 specifies two clocks, with an accompanied clock-name for each clock.

msm8916 specifies a single clock, without an accompanied clock-name.

It is possible to append clock-names = "pll" for the existing clock,
as well as to define the aux clock in the apcs node in the msm8916 DT:
clocks = < GPLL0_VOTE>;
clock-names = "aux";

However, since the DT is treated as an ABI, the existing DT for msm8916 must
still work, so I don't think that it is possible to ignore having backwards
compability in the apcs clock driver.


Kind regards,
Niklas


Re: [PATCH v5 5/6] net: maclorawan: Implement maclorawan class module

2018-12-18 Thread Jiri Pirko
Tue, Dec 18, 2018 at 03:27:09PM CET, starni...@g.ncu.edu.tw wrote:
>> Sun, Dec 16, 2018 at 11:18:59AM CET, starni...@g.ncu.edu.tw wrote:
>> >LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa devices.
>> >
>> >This patch implements part of Class A end-devices SoftMAC defined in
>> >LoRaWAN(TM) Specification Ver. 1.0.2:
>> >1. End-device receive slot timing
>> >2. Only single channel and single data rate for now
>> >3. Unconfirmed data up/down message types
>> >
>> >On the other side, it defines the basic interface and operation
>> >functions for compatible LoRa device drivers.
>> >
>> >Signed-off-by: Jian-Hong Pan 
>> >---
>> >V2:
>> >- Split the LoRaWAN class module patch in V1 into LoRaWAN socket and
>> >  LoRaWAN Soft MAC modules
>> >- Modify for Big/Little-Endian
>> >- Use SPDX license identifiers
>> >
>> >V3:
>> >- Remove the decoration word - inline of the functions
>> >- Order local variables from longest to shortest line in the functions
>> >- Change the calling mac_cb function to lrw_get_mac_cb macro
>> >
>> >V4:
>> >- Fix the delay period between RX window#1 and window#2
>> >- Fix by coding style report from scripts/checkpatch.pl
>> >
>> >V5:
>> >- Initial rx_skb_list when it is allocated with LoRa hardware
>> >- Check the sk_buff's data length before access it
>> >- Deal FPort field and decrypt payload in lrw_parse_frame function
>> >- Drop the recieved frame if parse failed
>> >- Fix the bug which passes wrong skb properties from maclorawan to lorawan 
>> >module
>> >
>> > net/maclorawan/Kconfig  |  14 +
>> > net/maclorawan/Makefile |   2 +
>> > net/maclorawan/mac.c| 555 
>> > net/maclorawan/main.c   | 606 
>> > 4 files changed, 1177 insertions(+)
>> > create mode 100644 net/maclorawan/Kconfig
>> > create mode 100644 net/maclorawan/Makefile
>> > create mode 100644 net/maclorawan/mac.c
>> > create mode 100644 net/maclorawan/main.c
>>
>>
>> I don't get it. In patch "Add LoRaWAN API declaration for LoRa devices"
>> you add headers for "API" and here you implement functions. That is just
>> weird. Does it mean you can have other implementations?
>
>LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa PHY.
>This part is soft-MAC as Andreas mentioned
>http://lists.infradead.org/pipermail/linux-lpwan/2018-December/10.html

Okay, that does not answer my concern about header file in one patch and
the actual implementation of functions in another one.


>
>> Also, you don't really have any user of this API in the set. Please
>> introduce at least 1 driver, preferably more (I see that Andreas has
>> multiple ones in his patchset). You cannot push kernel infrastructure
>> without kernel user.
>
>The soft-MAC is suitable for the LoRa chips' device drivers, like
>sx1276/77/78/79, RFM95/96/97/98W ...
>Still waiting for Andreas' sx1276 version 2 patch and more discussion.
>For example, how to make PF_LORA and PF_LORAWAN like Ethernet, PF_INET
>and PF_INET6 don't need separate devices either, both use eth0.
>https://lkml.org/lkml/2018/8/3/266

Then you should push this is RFC or together with Andreases work in a
single patchset. Infra without users cannot be merged.


>
>Jian-Hong Pan


[PATCH: linux-next] ARM: dts: am33xx: Remove unnecessary properties

2018-12-18 Thread Felix Brack
Remove the unnecessary properties #address-cells and #size-cells
of node pinmux as there are no child-nodes with property reg.

Signed-off-by: Felix Brack 
---
 arch/arm/boot/dts/am33xx-l4.dtsi | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi b/arch/arm/boot/dts/am33xx-l4.dtsi
index 7b818d9d2eab..e957370f8aec 100644
--- a/arch/arm/boot/dts/am33xx-l4.dtsi
+++ b/arch/arm/boot/dts/am33xx-l4.dtsi
@@ -288,8 +288,6 @@
am33xx_pinmux: pinmux@800 {
compatible = "pinctrl-single";
reg = <0x800 0x238>;
-   #address-cells = <1>;
-   #size-cells = <0>;
#pinctrl-cells = <1>;
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <0x7f>;
-- 
2.17.1



Re: kernel BUG at fs/inode.c:LINE!

2018-12-18 Thread Ian Kent
On Tue, 2018-12-18 at 14:19 +0100, Dmitry Vyukov wrote:
> On Tue, Dec 18, 2018 at 1:42 PM Ian Kent  wrote:
> > 
> > On Tue, 2018-12-18 at 13:27 +0100, Dmitry Vyukov wrote:
> > > On Tue, Dec 18, 2018 at 12:35 PM Ian Kent  wrote:
> > > > 
> > > > On Tue, 2018-12-18 at 18:42 +0800, Ian Kent wrote:
> > > > > On Mon, 2018-12-17 at 07:21 +, Al Viro wrote:
> > > > > > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote:
> > > > > > > Hello,
> > > > > > > 
> > > > > > > syzbot found the following crash on:
> > > > > > > 
> > > > > > > HEAD commit:d14b746c6c1c Add linux-next specific files for
> > > > > > > 20181214
> > > > > > > git tree:   linux-next
> > > > > > > console output:
> > > > > > > https://syzkaller.appspot.com/x/log.txt?x=1370634740
> > > > > > > kernel config:
> > > > > > > https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140
> > > > > > > dashboard link:
> > > > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392
> > > > > > > compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> > > > > > > syz repro:
> > > > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b340
> > > > > > > C reproducer:
> > > > > > > https://syzkaller.appspot.com/x/repro.c?x=1653406340
> > > > > > > 
> > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the
> > > > > > > commit:
> > > > > > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com
> > > > > > > 
> > > > > > >  slab_pre_alloc_hook mm/slab.h:423 [inline]
> > > > > > >  slab_alloc mm/slab.c:3365 [inline]
> > > > > > >  kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539
> > > > > > >  __d_alloc+0xc8/0xb90 fs/dcache.c:1599
> > > > > > > [ cut here ]
> > > > > > > kernel BUG at fs/inode.c:1566!
> > > > > > >  d_alloc_anon fs/dcache.c:1698 [inline]
> > > > > > >  d_make_root+0x43/0xc0 fs/dcache.c:1885
> > > > > > >  autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273
> > > > > > 
> > > > > > Huh?  BUG is in iput(), AFAICS, so the stack trace is rather
> > > > > > misreported.
> > > > > > iput() can be called by d_make_root(), provided that dentry
> > > > > > allocation
> > > > > > fails.  So the most straightforward interpretation would be that we
> > > > > > had an allocation failure (injected?), followed by iput() of the
> > > > > > inode
> > > > > > passed to d_make_root().  Which happened to find I_CLEAR in
> > > > > > ->i_state
> > > > > > of that inode somehow, which should be impossible short of seriously
> > > > > > buggered inode refcounting somewhere - the inode has just been
> > > > > > returned
> > > > > > by new_inode(), which clears i_state, and it would have to have
> > > > > > passed
> > > > > > clear_inode() (i.e. has been through inode eviction) since then...
> > > > > 
> > > > > Sorry Al, that's my bad.
> > > > > 
> > > > > See
> > > > > 
> > 
> > 
https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch
> > > > > 
> > > > > I think this will fix it, I'll forward it to Andrew if you agree:
> > > > 
> > > > Actually, looking at it again the above patch is plain not needed,
> > > > dropping it and updating the patch which follows it in the series
> > > > is what needs to be done.
> > > > 
> > > > Andrew, what should I do to make this easiest for you to handle,
> > > > a respost with v2 in the subject of the patch affected by dropping
> > > > the above patch?
> > > > 
> > > > Or I could repost the series with above patch dropped and the affected
> > > > patch corrected?
> > > 
> > > Hi Ian,
> > > 
> > > If you going to amend any commits, please add:
> > > Tested-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com
> > > otherwise:
> > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com
> > 
> > I was thinking about how to handle loosing that information.
> > 
> > I don't think this amounts amending commits since Andrews mmotm is
> > based on patch series so dropping a patch and updating patches before
> > being merged won't capture this.
> > 
> > Adding the "Tested-by" attribution to the updated patch prior to syzbot
> > actually performing the test might be ok since it will get tested along
> > the way. Although the problem patch itself won't exist any more so ... ?
> 
> I am a bit lost.
> There should be some patch that will fix this (new or amended). Either
> that patch needs to include Reporter/Tested-by tag, or we will need to
> tell syzbot about the fix manually with the "#syz fix:" command.

One of the patches that I forwarded to Andrew was plain wrong, it isn't
actually needed so it needs to be dropped altogether (this one caused
the breakage). Doing so then requires a minor (unrelated) change to the
next of my patches in the series I sent.

Andrew forwards certain patches in his patch queue to to the linux-next
tree. I'm not sure if that is done via a cumulative pull request or via
actual patches.

Whether dropping a patch from Andrews mmotm tree when 

[PATCH v2] ARM: dts: imx: Add Y Soft IOTA Draco, Hydra and Ursa boards

2018-12-18 Thread Vokáč Michal
These are i.MX6S/DL based SBCs embedded in various Y Soft products.
All share the same board design but have slightly different HW
configuration.

Ursa
- i.MX6S SoC, 512MB RAM DDR3, 4GB eMMC, microSD
- parallel WVGA 7" LCD with touch panel
- 1x Eth (QCA8334 switch)
- USB OTG
- USB host (micro-B)

Draco
- i.MX6S SoC, 512MB RAM DDR3, 4GB eMMC, microSD
- parallel WVGA 7" LCD with touch panel
- 2x Eth (QCA8334 switch)
- USB OTG
- USB host (micro-B)
- RGB LED (I2C LP5562)
- 3.5mm audio jack + codec (LM49350)

Hydra
- i.MX6DL SoC, 2GB RAM DDR3, 4GB eMMC, microSD
- I2C OLED display, capacitive matrix keys
- 2x Eth (QCA8334 switch)
- USB OTG
- RGB LED (I2C LP5562)
- 3.5mm audio jack + codec (LM49350)
- HDMI
- miniPCIe slot

Cc: Andrew Lunn 
Signed-off-by: Michal Vokáč 
---
Changes since v1:
 - Enable HDMI on Hydra board.
 - Move regulators to the root node and remove simple-bus property. (Rob)
 - Remove reg and unit-address property from regulators. (Rob)
 - Use correct names for led-controller and pmic node. (Rob)
 - Use wakeup-source instead of deprecated enable-sdio-wakeup. (Shawn)

Link to v1: http://patchwork.ozlabs.org/patch/991975/

No change regarding the documentation and split of the dtsi files as
I did not get answers to my questions and was not sure how to proceed.
Andrew pointed me to the Kirkwood Synology platform. That boards use
the same concept to organize the "disabled" and "okay" nodes.

Thanks,
Michal

 arch/arm/boot/dts/Makefile |   3 +
 arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 595 +
 arch/arm/boot/dts/imx6dl-yapp4-draco.dts   |  61 +++
 arch/arm/boot/dts/imx6dl-yapp4-hydra.dts   |  49 +++
 arch/arm/boot/dts/imx6dl-yapp4-ursa.dts|  57 +++
 5 files changed, 765 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
 create mode 100644 arch/arm/boot/dts/imx6dl-yapp4-draco.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-yapp4-hydra.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-yapp4-ursa.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b0e966d..9bdf394 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -443,6 +443,9 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-wandboard.dtb \
imx6dl-wandboard-revb1.dtb \
imx6dl-wandboard-revd1.dtb \
+   imx6dl-yapp4-draco.dtb \
+   imx6dl-yapp4-hydra.dtb \
+   imx6dl-yapp4-ursa.dtb \
imx6q-apalis-eval.dtb \
imx6q-apalis-ixora.dtb \
imx6q-apalis-ixora-v1.1.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi 
b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
new file mode 100644
index 000..7eb6427
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
@@ -0,0 +1,595 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2015-2018 Y Soft Corporation, a.s.
+
+#include 
+#include 
+#include 
+
+/ {
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 50 PWM_POLARITY_INVERTED>;
+   brightness-levels = <0 32 64 128 255>;
+   default-brightness-level = <32>;
+   num-interpolated-steps = <8>;
+   power-supply = <_reg>;
+   status = "disabled";
+   };
+
+   lcd_display: display {
+   compatible = "fsl,imx-parallel-display";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interface-pix-fmt = "rgb24";
+   pinctrl-names = "default";
+   pinctrl-0 = <_ipu1>;
+   status = "disabled";
+
+   port@0 {
+   reg = <0>;
+
+   lcd_display_in: endpoint {
+   remote-endpoint = <_di0_disp0>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   lcd_display_out: endpoint {
+   remote-endpoint = <_panel_in>;
+   };
+   };
+   };
+
+   panel: panel {
+   compatible = "dataimage,scf0700c48ggu18";
+   power-supply = <_reg>;
+   status = "disabled";
+
+   port {
+   lcd_panel_in: endpoint {
+   remote-endpoint = <_display_out>;
+   };
+   };
+   };
+
+   reg_usb_h1_vbus: reg_usb_h1_vbus {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <_usbh1_vbus>;
+   regulator-name = "usb_h1_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 29 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   status = "disabled";
+   };
+
+   reg_usb_otg_vbus: reg_usb_otg_vbus {
+   compatible = "regulator-fixed";
+   

[PATCH 1/1] ARM: STi: Restore secondary CPU's bringup

2018-12-18 Thread patrice.chotard
From: Patrice Chotard 

Due to pen_release and boot_lock removal, secondary CPU's bringup
was broken. Restore CPU's bringup by reworking properly
.smp_prepare_cpus and .smp_boot_secondary STi callbacks.

Signed-off-by: Patrice Chotard 
---
 arch/arm/mach-sti/platsmp.c | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-sti/platsmp.c b/arch/arm/mach-sti/platsmp.c
index 2166850..9bfc93a 100644
--- a/arch/arm/mach-sti/platsmp.c
+++ b/arch/arm/mach-sti/platsmp.c
@@ -28,8 +28,21 @@
 
 #include "smp.h"
 
+static u32 __iomem *cpu_strt_ptr;
+
 static int sti_boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
+   unsigned long entry_pa = __pa_symbol(secondary_startup);
+
+   __raw_writel(entry_pa, cpu_strt_ptr);
+
+   /*
+* wmb so that data is actually written
+* before cache flush is done
+*/
+   smp_wmb();
+   sync_cache_w(cpu_strt_ptr);
+
/*
 * Send the secondary CPU a soft interrupt, thereby causing
 * it to jump to the secondary entrypoint.
@@ -43,10 +56,8 @@ static void __init sti_smp_prepare_cpus(unsigned int 
max_cpus)
 {
struct device_node *np;
void __iomem *scu_base;
-   u32 __iomem *cpu_strt_ptr;
u32 release_phys;
int cpu;
-   unsigned long entry_pa = __pa_symbol(secondary_startup);
 
np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
 
@@ -74,8 +85,8 @@ static void __init sti_smp_prepare_cpus(unsigned int max_cpus)
}
 
/*
-* holding pen is usually configured in SBC DMEM but can also be
-* in RAM.
+* cpu-release-addr is usually configured in SBC DMEM but can
+* also be in RAM.
 */
 
if (!memblock_is_memory(release_phys))
@@ -85,17 +96,7 @@ static void __init sti_smp_prepare_cpus(unsigned int 
max_cpus)
cpu_strt_ptr =
(u32 __iomem *)phys_to_virt(release_phys);
 
-   __raw_writel(entry_pa, cpu_strt_ptr);
-
-   /*
-* wmb so that data is actually written
-* before cache flush is done
-*/
-   smp_wmb();
-   sync_cache_w(cpu_strt_ptr);
-
-   if (!memblock_is_memory(release_phys))
-   iounmap(cpu_strt_ptr);
+   set_cpu_possible(cpu, true);
}
 }
 
-- 
1.9.1



Re: selftests/net: udpgso: LTS kernels supportability ?

2018-12-18 Thread shuah

On 12/18/18 4:37 AM, Rafael David Tinoco wrote:

On 12/17/18 4:42 PM, shuah wrote:

Hi Rafael,

On 12/17/18 10:53 AM, Rafael David Tinoco wrote:

Shuah,

I was recently investigating some errors coming out of our functional
tests and we, Dan and I, came up with a discussion that might not be new
for you, but, interests us, in defining how to better use kselftests as
a regression mechanism/tool in our LKFT (https://lkft.linaro.org).

David / Willem,

I'm only using udpgso as an example for what I'd like to ask Shuah. Feel
free to jump in in the discussion if you think its worth.

All,

Regarding: udpgso AND https://bugs.linaro.org/show_bug.cgi?id=3980

udpgso tests are failing in kernels bellow 4.18 because of 2 main
reasons:

1) udp4_ufo_fragment does not seem to demand the GSO SKB to be > than
the MTU for older kernels (4th test case in udpgso.c).

2) setsockopt(...UDP_SEGMENT) support is not present for older kernels.
(commits "udp: generate gso with UDP_SEGMENT" and its fixes seem to be
needed).


This case is easy right? Based on the test output below , I can see that
the failure is due to

./udpgso: setsockopt udp segment: Protocol not available. setsockopt()
is returning an error to clearly indicate that this options isn't
supported. This will be a test change to say test is a skip as opposed
to fail.


You referred to (2). (1) isn't that straightforward.


We have a solution for this - test should SKIP as opposed to FAIL.


With that explained, finally the question/discussion:

Shouldn't we enforce a versioning mechanism for tests that are testing
recently added features ? I mean, some of the tests inside udpgso
selftest are good enough for older kernels...


Right - we do have generic way to handle that by detecting if feature is
supported and skip instead of using Kernel version which is going to be
hard to maintain.


You can't distinguish case (1) failures between real failures OR older
kernel behaving differently then testcase expects.



But, because we have no control over "kernel features" and "supported
test cases", we, Linaro, have to end up blacklisting all selftests that
have new feature oriented tests, because one or two test cases only.



Can you share the blacklisted tests?

thanks,
-- Shuah


Re: [PATCH v6 08/11] dt-bindings: serial: Document RDA Micro UART

2018-12-18 Thread Rob Herring
On Tue, Dec 18, 2018 at 01:35:24PM +0530, Manivannan Sadhasivam wrote:
> From: Andreas Färber 
> 
> Add an initial binding for the UART in RDA Micro RDA8810PL SoC.
> 
> Signed-off-by: Andreas Färber 
> Signed-off-by: Manivannan Sadhasivam 
> ---
>  .../bindings/serial/rda,8810pl-uart.txt | 17 +
>  1 file changed, 17 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt

Please add acks/reviewed-bys when posting new versions.

Rob


[PATCH 3/3] PM/runtime:Replace jiffies based accounting with ktime based accounting

2018-12-18 Thread Vincent Guittot
From: Thara Gopinath 

This patch replaces jiffies based accounting for runtime_active_time
and runtime_suspended_time with ktime base accounting. This makes the
runtime debug counters inline with genpd and other pm subsytems which
uses ktime based accounting.

Signed-off-by: Thara Gopinath 
[move from ktime to raw nsec]
Signed-off-by: Vincent Guittot 
---
 drivers/base/power/runtime.c | 10 +-
 drivers/base/power/sysfs.c   | 11 ---
 include/linux/pm.h   |  6 +++---
 3 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 6461469..5c18e28 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -66,8 +66,8 @@ static int rpm_suspend(struct device *dev, int rpmflags);
  */
 void update_pm_runtime_accounting(struct device *dev)
 {
-   unsigned long now = jiffies;
-   unsigned long delta;
+   u64 now = ktime_to_ns(ktime_get());
+   u64 delta;
 
delta = now - dev->power.accounting_timestamp;
 
@@ -77,9 +77,9 @@ void update_pm_runtime_accounting(struct device *dev)
return;
 
if (dev->power.runtime_status == RPM_SUSPENDED)
-   dev->power.suspended_jiffies += delta;
+   dev->power.suspended_time += delta;
else
-   dev->power.active_jiffies += delta;
+   dev->power.active_time += delta;
 }
 
 static void __update_runtime_status(struct device *dev, enum rpm_status status)
@@ -1517,7 +1517,7 @@ void pm_runtime_init(struct device *dev)
dev->power.request_pending = false;
dev->power.request = RPM_REQ_NONE;
dev->power.deferred_resume = false;
-   dev->power.accounting_timestamp = jiffies;
+   dev->power.accounting_timestamp = ktime_to_ns(ktime_get());
INIT_WORK(>power.work, pm_runtime_work);
 
dev->power.timer_expires = 0;
diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
index d713738..96c8a22 100644
--- a/drivers/base/power/sysfs.c
+++ b/drivers/base/power/sysfs.c
@@ -125,9 +125,12 @@ static ssize_t runtime_active_time_show(struct device *dev,
struct device_attribute *attr, char *buf)
 {
int ret;
+   u64 tmp;
spin_lock_irq(>power.lock);
update_pm_runtime_accounting(dev);
-   ret = sprintf(buf, "%i\n", jiffies_to_msecs(dev->power.active_jiffies));
+   tmp = dev->power.active_time;
+   do_div(tmp, NSEC_PER_MSEC);
+   ret = sprintf(buf, "%llu\n", tmp);
spin_unlock_irq(>power.lock);
return ret;
 }
@@ -138,10 +141,12 @@ static ssize_t runtime_suspended_time_show(struct device 
*dev,
struct device_attribute *attr, char *buf)
 {
int ret;
+   u64 tmp;
spin_lock_irq(>power.lock);
update_pm_runtime_accounting(dev);
-   ret = sprintf(buf, "%i\n",
-   jiffies_to_msecs(dev->power.suspended_jiffies));
+   tmp = dev->power.suspended_time;
+   do_div(tmp, NSEC_PER_MSEC);
+   ret = sprintf(buf, "%llu\n", tmp);
spin_unlock_irq(>power.lock);
return ret;
 }
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 0bd9de1..3d2cbf9 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -633,9 +633,9 @@ struct dev_pm_info {
int runtime_error;
int autosuspend_delay;
u64 last_busy;
-   unsigned long   active_jiffies;
-   unsigned long   suspended_jiffies;
-   unsigned long   accounting_timestamp;
+   u64 active_time;
+   u64 suspended_time;
+   u64 accounting_timestamp;
 #endif
struct pm_subsys_data   *subsys_data;  /* Owned by the subsystem. */
void (*set_latency_tolerance)(struct device *, s32);
-- 
2.7.4



Re: [PATCH v1 03/13] powerpc/mm/32s: rework mmu_mapin_ram()

2018-12-18 Thread Christophe Leroy




Le 18/12/2018 à 15:15, Christophe Leroy a écrit :



Le 18/12/2018 à 15:07, Jonathan Neuschäfer a écrit :

On Tue, Dec 18, 2018 at 09:18:42AM +, Christophe Leroy wrote:

The only difference I see then are the flags. Everything else is seems
identical.

I know you tried already, but would you mind trying once more with the
following change ?


[...]

-    setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT);
+    setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_X);


Good call, with this workaround on top of patches 1-3, it boots again:

# mount -t debugfs d /sys/kernel/debug
# cat /sys/kernel/debug/powerpc/block_address_translation
---[ Instruction Block Address Translation ]---
0: 0xc000-0xc0ff 0x Kernel EXEC
1: -
2: 0xc100-0xc17f 0x0100 Kernel EXEC
3: -
4: 0xd000-0xd1ff 0x1000 Kernel EXEC
5: -
6: -
7: -

---[ Data Block Address Translation ]---
0: 0xc000-0xc0ff 0x Kernel RW
1: 0xfffe-0x 0x0d00 Kernel RW no cache guarded
2: 0xc100-0xc17f 0x0100 Kernel RW
3: -
4: 0xd000-0xd1ff 0x1000 Kernel RW
5: -
6: -
7: -

I think we may have some code trying to modify the kernel text 
without using

code patching functions.


Is there any faster way than to sprinkle some printks in setup_kernel
and try to find the guilty piece of code this way?


Can you start with the serie 
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=75072 ?


Ok, the thing I was thinking about was the MMU_init_hw() but it is 
called before mapin_ram() so it should not be a problem. Not sure that 
serie improves anything at all here.


So there must be something else, pretty early (before the system is able 
to properly handle and display an Oops for write to RO area.)


Does anybody have an idea of what it can be ?

Christophe



Christophe




Jonathan



[PATCH v3 0/3] Move pm_runtime accounted time to raw nsec

2018-12-18 Thread Vincent Guittot
Move pm_runtime accounted time to raw nsec. The subject of the patchset
has changed as the 1st patch has been queued by Rafael

Patch 1 adds a new pm_runtime interface to get accounted suspended time

Patch 2 moves drm/i915 driver on the new interface and removes access to 
internal
fields

Patch 3 moves time accounting on raw ns. This patch initially used
ktime instead of raw ns but it was easier to move i915 driver on raw ns
than on ktim

Changes since v2:
- remove patch1 that has been queued by rafael
- add new interface in pm_runtime to get accounted time
- reorder patchset to prevent compilation error

Changes since v1:
- updated commit message of patch 1
- Added patches 2 & 3 to move runtime_pm accounting on raw ns
  
Thara Gopinath (1):
  PM/runtime:Replace jiffies based accounting with ktime based
accounting

Vincent Guittot (2):
  PM/runtime: Add a new interface to get accounted time
  drm/i915: Move on the new pm runtime interface

 drivers/base/power/runtime.c| 36 +++-
 drivers/base/power/sysfs.c  | 11 ---
 drivers/gpu/drm/i915/i915_pmu.c | 18 --
 drivers/gpu/drm/i915/i915_pmu.h |  4 ++--
 include/linux/pm.h  |  6 +++---
 include/linux/pm_runtime.h  |  2 ++
 6 files changed, 54 insertions(+), 23 deletions(-)

-- 
2.7.4



[RFC 2/3] drm/i915: Move on the new pm runtime interface

2018-12-18 Thread Vincent Guittot
Use the new pm runtime interface to get the accounted suspended time:
pm_runtime_accounted_time_get()

Signed-off-by: Vincent Guittot 
---
 drivers/gpu/drm/i915/i915_pmu.c | 18 --
 drivers/gpu/drm/i915/i915_pmu.h |  4 ++--
 2 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index d6c8f8f..ebc49ea 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include "i915_pmu.h"
 #include "intel_ringbuffer.h"
 #include "i915_drv.h"
@@ -478,7 +479,6 @@ static u64 get_rc6(struct drm_i915_private *i915)
 * counter value.
 */
spin_lock_irqsave(>pmu.lock, flags);
-   spin_lock(>power.lock);
 
/*
 * After the above branch intel_runtime_pm_get_if_in_use failed
@@ -491,16 +491,15 @@ static u64 get_rc6(struct drm_i915_private *i915)
 * suspended and if not we cannot do better than report the last
 * known RC6 value.
 */
-   if (kdev->power.runtime_status == RPM_SUSPENDED) {
+   val = pm_runtime_accounted_time_get(kdev, RPM_SUSPENDED, true);
+   if (pm_runtime_status_suspended(kdev)) {
if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
-   i915->pmu.suspended_jiffies_last =
- kdev->power.suspended_jiffies;
+   i915->pmu.suspended_time_last =
+   pm_runtime_accounted_time_get(kdev,
+ 
RPM_SUSPENDED,
+ false);
 
-   val = kdev->power.suspended_jiffies -
- i915->pmu.suspended_jiffies_last;
-   val += jiffies - kdev->power.accounting_timestamp;
-
-   val = jiffies_to_nsecs(val);
+   val -= i915->pmu.suspended_time_last;
val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
 
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
@@ -510,7 +509,6 @@ static u64 get_rc6(struct drm_i915_private *i915)
val = i915->pmu.sample[__I915_SAMPLE_RC6].cur;
}
 
-   spin_unlock(>power.lock);
spin_unlock_irqrestore(>pmu.lock, flags);
}
 
diff --git a/drivers/gpu/drm/i915/i915_pmu.h b/drivers/gpu/drm/i915/i915_pmu.h
index 7f164ca..3dc2a30 100644
--- a/drivers/gpu/drm/i915/i915_pmu.h
+++ b/drivers/gpu/drm/i915/i915_pmu.h
@@ -95,9 +95,9 @@ struct i915_pmu {
 */
struct i915_pmu_sample sample[__I915_NUM_PMU_SAMPLERS];
/**
-* @suspended_jiffies_last: Cached suspend time from PM core.
+* @suspended_time_last: Cached suspend time from PM core.
 */
-   unsigned long suspended_jiffies_last;
+   u64 suspended_time_last;
/**
 * @i915_attr: Memory block holding device attributes.
 */
-- 
2.7.4



Re: [PATCH v4] clk: qcom: smd: Add support for MSM8998 rpm clocks

2018-12-18 Thread Rob Herring
On Mon, 17 Dec 2018 19:15:36 -0700, Jeffrey Hugo wrote:
> Add rpm smd clocks, PMIC and bus clocks which are required on MSM8998
> for clients to vote on.
> 
> Signed-off-by: Jeffrey Hugo 
> ---
> v4
> -Fix compile issue
> 
> v3
> -Ensure Marc's hang was addressed by GCC fixes
> -Renamed the bb clks to ln_bb to match the schematics
> 
> v2
> -fix compatible ordering nits per Stephen 
> 
>  .../devicetree/bindings/clock/qcom,rpmcc.txt   |  1 +
>  drivers/clk/qcom/clk-smd-rpm.c | 63 
> ++
>  include/dt-bindings/clock/qcom,rpmcc.h | 10 
>  3 files changed, 74 insertions(+)
> 

Reviewed-by: Rob Herring 


[RFC v3 1/3] PM/runtime: Add a new interface to get accounted time

2018-12-18 Thread Vincent Guittot
Some drivers (like i915/drm) need to get the accounted suspended time.
pm_runtime_accounted_time_get() will return the suspended or active
accounted time until now.

Signed-off-by: Vincent Guittot 
---
 drivers/base/power/runtime.c | 26 ++
 include/linux/pm_runtime.h   |  2 ++
 2 files changed, 28 insertions(+)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 7062469..6461469 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -88,6 +88,32 @@ static void __update_runtime_status(struct device *dev, enum 
rpm_status status)
dev->power.runtime_status = status;
 }
 
+u64 pm_runtime_accounted_time_get(struct device *dev, enum rpm_status status, 
bool update)
+{
+   u64 now = ktime_to_ns(ktime_get());
+   u64 delta = 0, time = 0;
+   unsigned long flags;
+
+   spin_lock_irqsave(>power.lock, flags);
+
+   if (dev->power.disable_depth > 0)
+   goto unlock;
+
+   /* Add ongoing state  if requested */
+   if (update && dev->power.runtime_status == status)
+   delta = now - dev->power.accounting_timestamp;
+
+   if (status == RPM_SUSPENDED)
+   time = dev->power.suspended_time + delta;
+   else
+   time = dev->power.active_time + delta;
+
+unlock:
+   spin_unlock_irqrestore(>power.lock, flags);
+
+   return time;
+}
+
 /**
  * pm_runtime_deactivate_timer - Deactivate given device's suspend timer.
  * @dev: Device to handle.
diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
index 54af4ee..86f21f9 100644
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -113,6 +113,8 @@ static inline bool pm_runtime_is_irq_safe(struct device 
*dev)
return dev->power.irq_safe;
 }
 
+extern u64 pm_runtime_accounted_time_get(struct device *dev, enum rpm_status 
status, bool update);
+
 #else /* !CONFIG_PM */
 
 static inline bool queue_pm_work(struct work_struct *work) { return false; }
-- 
2.7.4



Re: [RFC][PATCH] printk: increase devkmsg write() ratelimit

2018-12-18 Thread Sergey Senozhatsky
On (12/18/18 15:26), Borislav Petkov wrote:
> On Tue, Dec 18, 2018 at 10:07:50PM +0900, Sergey Senozhatsky wrote:
> > This is right before shutdown. dmesg is not really available anymore.
> > I can only guess why do they write it to devkmsg - to make it appear
> > on the serial/net console, perhaps. Dunno.
> 
> But still, why do we want to see those messages and enlarge the
> ratelimit for that? Do they contain any particularly important
> information?

Good question. Theoretically, there can be some interesting stuff.
Examples: https://bugzilla.redhat.com/show_bug.cgi?id=1515373#c6
orhttps://github.com/systemd/systemd/issues/5433

-ss


Re: [PATCH v6 08/11] dt-bindings: serial: Document RDA Micro UART

2018-12-18 Thread Manivannan Sadhasivam
On Tue, Dec 18, 2018 at 08:54:43AM -0600, Rob Herring wrote:
> On Tue, Dec 18, 2018 at 01:35:24PM +0530, Manivannan Sadhasivam wrote:
> > From: Andreas Färber 
> > 
> > Add an initial binding for the UART in RDA Micro RDA8810PL SoC.
> > 
> > Signed-off-by: Andreas Färber 
> > Signed-off-by: Manivannan Sadhasivam 
> > ---
> >  .../bindings/serial/rda,8810pl-uart.txt | 17 +
> >  1 file changed, 17 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt
> 
> Please add acks/reviewed-bys when posting new versions.
>

Hi Rob,

Sorry for that. I missed your Reviewed-by tag here. Will add it in the
next iteration which I'm going to send to ARM SoC list.

Regards,
Mani

> Rob


Re: [PATCH v3 01/15] dt-bindings: net: broadcom-bluetooth: Fix external clock names

2018-12-18 Thread Rob Herring
On Mon, 17 Dec 2018 12:04:35 +0800, Chen-Yu Tsai wrote:
> The Broadcom Bluetooth controllers can take up to two external clocks:
> an external frequency reference, substituting the main crystal, and a
> LPO clock at 32.768 kHz substituting the internal LPO clock.
> 
> In particular, the external LPO clock must be used when the controller
> does not have NVRAM connected, and the main reference frequency is not
> the default 20 MHz. This is described in detail in the datasheet.
> 
> The original "extclk" clock name is ambiguous as to which of these it
> refers to, and some designs might even require both.
> 
> This patch deprecates the existing name, and adds "txco" and "lpo".
> 
> Tested-by: Ondrej Jirman 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  .../devicetree/bindings/net/broadcom-bluetooth.txt | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring 


[PATCH v7 01/11] dt-bindings: Add RDA Micro vendor prefix

2018-12-18 Thread Manivannan Sadhasivam
From: Andreas Färber 

Add vendor prefix for RDA Micro which now merged into Unisoc
Communications Inc.

Signed-off-by: Andreas Färber 
Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Rob Herring 
Acked-by: Arnd Bergmann 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 4b1a2a8fcc16..37826fac7684 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -320,6 +320,7 @@ ralink  Mediatek/Ralink Technology Corp.
 ramtronRamtron International
 raspberrypiRaspberry Pi Foundation
 raydiumRaydium Semiconductor Corp.
+rdaUnisoc Communications, Inc.
 realtek Realtek Semiconductor Corp.
 renesasRenesas Electronics Corporation
 richtekRichtek Technology Corporation
-- 
2.17.1



[PATCH v7 00/11] Add initial RDA8810PL SoC and Orange Pi boards support

2018-12-18 Thread Manivannan Sadhasivam
Hello Maintainers,

This patch series adds initial RDA8810PL SoC and Orange Pi boards (2G IoT and
i96) support. RDA8810PL is an ARM Cortex A5 based SoC with Vivante's GC860
GPU. The SoC has been added as a new ARM sub architecture with myself as the
maintainer.

More information about the boards can be found in below links:

1. Orange Pi 2G-IoT - http://www.orangepi.org/OrangePi2GIOT/
2. Orange Pi i96 - https://www.96boards.org/product/orangepi-i96/

All patches are reviewed by the corresponding subsystem maintainers. The
clocksource and irqchip patches are reviewed and merged while the serial
driver got review from Greg but I'm not sure who will apply it.

So as per my discussion with Arnd, sending the individual patches instead
of a Pull request so that the rest of the patches can go through the
ARM SoC tree.

Please consider applying it.

Thanks,
Mani

Andreas Färber (4):
  dt-bindings: Add RDA Micro vendor prefix
  dt-bindings: arm: Document RDA8810PL and reference boards
  ARM: Prepare RDA8810PL SoC
  dt-bindings: serial: Document RDA Micro UART

Manivannan Sadhasivam (7):
  ARM: dts: Add devicetree for RDA8810PL SoC
  ARM: dts: Add devicetree for OrangePi 2G IoT board
  ARM: dts: Add devicetree for OrangePi i96 board
  ARM: dts: rda8810pl: Add timer support
  ARM: dts: rda8810pl: Add interrupt support for UART
  tty: serial: Add RDA8810PL UART driver
  MAINTAINERS: Add entry for RDA Micro SoC architecture

 .../admin-guide/kernel-parameters.txt |   6 +
 Documentation/devicetree/bindings/arm/rda.txt |  17 +
 .../bindings/serial/rda,8810pl-uart.txt   |  17 +
 .../devicetree/bindings/vendor-prefixes.txt   |   1 +
 MAINTAINERS   |  14 +
 arch/arm/Kconfig  |   2 +
 arch/arm/Makefile |   1 +
 arch/arm/boot/dts/Makefile|   3 +
 .../boot/dts/rda8810pl-orangepi-2g-iot.dts|  50 ++
 arch/arm/boot/dts/rda8810pl-orangepi-i96.dts  |  50 ++
 arch/arm/boot/dts/rda8810pl.dtsi  |  99 +++
 arch/arm/mach-rda/Kconfig |   7 +
 arch/arm/mach-rda/Makefile|   1 +
 drivers/tty/serial/Kconfig|  19 +
 drivers/tty/serial/Makefile   |   1 +
 drivers/tty/serial/rda-uart.c | 831 ++
 include/uapi/linux/serial_core.h  |   3 +
 17 files changed, 1122 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/rda.txt
 create mode 100644 Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt
 create mode 100644 arch/arm/boot/dts/rda8810pl-orangepi-2g-iot.dts
 create mode 100644 arch/arm/boot/dts/rda8810pl-orangepi-i96.dts
 create mode 100644 arch/arm/boot/dts/rda8810pl.dtsi
 create mode 100644 arch/arm/mach-rda/Kconfig
 create mode 100644 arch/arm/mach-rda/Makefile
 create mode 100644 drivers/tty/serial/rda-uart.c

-- 
2.17.1



[PATCH v7 02/11] dt-bindings: arm: Document RDA8810PL and reference boards

2018-12-18 Thread Manivannan Sadhasivam
From: Andreas Färber 

Add bindings for RDA Micro RDA8810PL SoC and below reference boards:

1. Orange Pi 2G-IoT - http://www.orangepi.org/OrangePi2GIOT/
2. Orange Pi i96 - https://www.96boards.org/product/orangepi-i96/

Cc: zhao_ste...@263.net
Signed-off-by: Andreas Färber 
Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Rob Herring 
Acked-by: Arnd Bergmann 
---
 Documentation/devicetree/bindings/arm/rda.txt | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/rda.txt

diff --git a/Documentation/devicetree/bindings/arm/rda.txt 
b/Documentation/devicetree/bindings/arm/rda.txt
new file mode 100644
index ..43c80762c428
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rda.txt
@@ -0,0 +1,17 @@
+RDA Micro platforms device tree bindings
+
+
+RDA8810PL SoC
+=
+
+Required root node properties:
+
+ - compatible :  must contain "rda,8810pl"
+
+
+Boards:
+
+Root node property compatible must contain, depending on board:
+
+ - Orange Pi 2G-IoT: "xunlong,orangepi-2g-iot"
+ - Orange Pi i96: "xunlong,orangepi-i96"
-- 
2.17.1



[PATCH v7 05/11] ARM: dts: Add devicetree for OrangePi 2G IoT board

2018-12-18 Thread Manivannan Sadhasivam
Add initial devicetree support for OrangePi 2G IoT board from Xunlong.

Signed-off-by: Andreas Färber 
Signed-off-by: Manivannan Sadhasivam 
Acked-by: Arnd Bergmann 
---
 arch/arm/boot/dts/Makefile|  2 +
 .../boot/dts/rda8810pl-orangepi-2g-iot.dts| 50 +++
 2 files changed, 52 insertions(+)
 create mode 100644 arch/arm/boot/dts/rda8810pl-orangepi-2g-iot.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b0e966d625b9..a0fdad8f10dd 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -806,6 +806,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-msm8974-sony-xperia-castor.dtb \
qcom-msm8974-sony-xperia-honami.dtb \
qcom-mdm9615-wp8548-mangoh-green.dtb
+dtb-$(CONFIG_ARCH_RDA) += \
+   rda8810pl-orangepi-2g-iot.dtb
 dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pb1176.dtb \
arm-realview-pb11mp.dtb \
diff --git a/arch/arm/boot/dts/rda8810pl-orangepi-2g-iot.dts 
b/arch/arm/boot/dts/rda8810pl-orangepi-2g-iot.dts
new file mode 100644
index ..98e34248ae80
--- /dev/null
+++ b/arch/arm/boot/dts/rda8810pl-orangepi-2g-iot.dts
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ * Copyright (c) 2018 Manivannan Sadhasivam
+ */
+
+/dts-v1/;
+
+#include "rda8810pl.dtsi"
+
+/ {
+   compatible = "xunlong,orangepi-2g-iot", "rda,8810pl";
+   model = "Orange Pi 2G-IoT";
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   };
+
+   chosen {
+   stdout-path = "serial2:921600n8";
+   };
+
+   memory@8000 {
+   device_type = "memory";
+   reg = <0x8000 0x1000>;
+   };
+
+   uart_clk: uart-clk {
+   compatible = "fixed-clock";
+   clock-frequency = <921600>;
+   #clock-cells = <0>;
+   };
+};
+
+ {
+   status = "okay";
+   clocks = <_clk>;
+};
+
+ {
+   status = "okay";
+   clocks = <_clk>;
+};
+
+ {
+   status = "okay";
+   clocks = <_clk>;
+};
-- 
2.17.1



[PATCH v7 04/11] ARM: dts: Add devicetree for RDA8810PL SoC

2018-12-18 Thread Manivannan Sadhasivam
Add initial device tree for RDA8810PL SoC from RDA Microelectronics.

Signed-off-by: Andreas Färber 
Signed-off-by: Manivannan Sadhasivam 
Acked-by: Arnd Bergmann 
---
 arch/arm/boot/dts/rda8810pl.dtsi | 86 
 1 file changed, 86 insertions(+)
 create mode 100644 arch/arm/boot/dts/rda8810pl.dtsi

diff --git a/arch/arm/boot/dts/rda8810pl.dtsi b/arch/arm/boot/dts/rda8810pl.dtsi
new file mode 100644
index ..15547b138977
--- /dev/null
+++ b/arch/arm/boot/dts/rda8810pl.dtsi
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * RDA8810PL SoC
+ *
+ * Copyright (c) 2017 Andreas Färber
+ * Copyright (c) 2018 Manivannan Sadhasivam
+ */
+
+/ {
+   compatible = "rda,8810pl";
+   interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a5";
+   reg = <0x0>;
+   };
+   };
+
+   sram@10 {
+   compatible = "mmio-sram";
+   reg = <0x10 0x1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   };
+
+   apb@2080 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x2080 0x10>;
+
+   intc: interrupt-controller@0 {
+   compatible = "rda,8810pl-intc";
+   reg = <0x0 0x1000>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+   };
+
+   apb@2090 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x2090 0x10>;
+   };
+
+   apb@20a0 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x20a0 0x10>;
+
+   uart1: serial@0 {
+   compatible = "rda,8810pl-uart";
+   reg = <0x0 0x1000>;
+   status = "disabled";
+   };
+
+   uart2: serial@1 {
+   compatible = "rda,8810pl-uart";
+   reg = <0x1 0x1000>;
+   status = "disabled";
+   };
+
+   uart3: serial@9 {
+   compatible = "rda,8810pl-uart";
+   reg = <0x9 0x1000>;
+   status = "disabled";
+   };
+   };
+
+   l2: cache-controller@2110 {
+   compatible = "arm,pl310-cache";
+   reg = <0x2110 0x1000>;
+   cache-unified;
+   cache-level = <2>;
+   };
+};
-- 
2.17.1



Re: [RFC][PATCH] printk: increase devkmsg write() ratelimit

2018-12-18 Thread Borislav Petkov
On Tue, Dec 18, 2018 at 11:55:58PM +0900, Sergey Senozhatsky wrote:
> Good question. Theoretically, there can be some interesting stuff.
> Examples: https://bugzilla.redhat.com/show_bug.cgi?id=1515373#c6
> orhttps://github.com/systemd/systemd/issues/5433

Just like that last page says, people should use the printk.devkmsg=
option when they wanna see all messages. Normally, we do add cmdline
options to the kernel cmdline when debugging, like

debug ignore_loglevel log_buf_len=16M ...

etc and this is no different AFAICT.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.


Re: [RFC][PATCH 0/3] arm64 relaxed ABI

2018-12-18 Thread Andrey Konovalov
On Wed, Dec 12, 2018 at 4:02 PM Catalin Marinas  wrote:
>
> Hi Andrey,
>
> On Wed, Dec 12, 2018 at 03:23:25PM +0100, Andrey Konovalov wrote:
> > On Mon, Dec 10, 2018 at 3:31 PM Vincenzo Frascino
> >  wrote:
> > > On arm64 the TCR_EL1.TBI0 bit has been set since Linux 3.x hence
> > > the userspace (EL0) is allowed to set a non-zero value in the top
> > > byte but the resulting pointers are not allowed at the user-kernel
> > > syscall ABI boundary.
> > >
> > > This patchset proposes a relaxation of the ABI and a mechanism to
> > > advertise it to the userspace via an AT_FLAGS.
> > >
> > > The rationale behind the choice of AT_FLAGS is that the Unix System V
> > > ABI defines AT_FLAGS as "flags", leaving some degree of freedom in
> > > interpretation.
> > > There are two previous attempts of using AT_FLAGS in the Linux Kernel
> > > for different reasons: the first was more generic and was used to expose
> > > the support for the GNU STACK NX feature [1] and the second was done for
> > > the MIPS architecture and was used to expose the support of "MIPS ABI
> > > Extension for IEEE Std 754 Non-Compliant Interlinking" [2].
> > > Both the changes are currently _not_ merged in mainline.
> > > The only architecture that reserves some of the bits in AT_FLAGS is
> > > currently MIPS, which introduced the concept of platform specific ABI
> > > (psABI) reserving the top-byte [3].
> > >
> > > When ARM64_AT_FLAGS_SYSCALL_TBI is set the kernel is advertising
> > > to the userspace that a relaxed ABI is supported hence this type
> > > of pointers are now allowed to be passed to the syscalls when they are
> > > in memory ranges obtained by anonymous mmap() or brk().
> > >
> > > The userspace _must_ verify that the flag is set before passing tagged
> > > pointers to the syscalls allowed by this relaxation.
> > >
> > > More in general, exposing the ARM64_AT_FLAGS_SYSCALL_TBI flag and 
> > > mandating
> > > to the software to check that the feature is present, before using the
> > > associated functionality, it provides a degree of control on the decision
> > > of disabling such a feature in future without consequently breaking the
> > > userspace.
> [...]
> > Acked-by: Andrey Konovalov 
>
> Thanks for the ack. However, if we go ahead with this ABI proposal it
> means that your patches need to be reworked to allow a non-zero top byte
> in all syscalls, including mmap() and friends, ioctl(). There are ABI
> concerns in either case but I'd rather have this discussion in the open.
> It doesn't necessarily mean that I endorse this proposal, I would like
> feedback and not just from kernel developers but user space ones.
>
> The summary of our internal discussions (mostly between kernel
> developers) is that we can't properly describe a user ABI that covers
> future syscalls or syscall extensions while not all syscalls accept
> tagged pointers. So we tweaked the requirements slightly to only allow
> tagged pointers back into the kernel *if* the originating address is
> from an anonymous mmap() or below sbrk(0). This should cover some of the
> ioctls or getsockopt(TCP_ZEROCOPY_RECEIVE) where the user passes a
> pointer to a buffer obtained via mmap() on the device operations.
>
> (sorry for not being clear on what Vincenzo's proposal implies)

OK, I see. So I need to make the following changes to my patchset AFAIU.

1. Make sure that we only allow tagged user addresses that originate
from an anonymous mmap() or below sbrk(0). How exactly should this
check be performed?

2. Allow tagged addressed passed to memory syscalls (as long as (1) is
satisfied). Do I understand correctly that this means that I need to
locate all find_vma() callers outside of mm/ and fix them up as well?


[PATCH v7 08/11] dt-bindings: serial: Document RDA Micro UART

2018-12-18 Thread Manivannan Sadhasivam
From: Andreas Färber 

Add an initial binding for the UART in RDA Micro RDA8810PL SoC.

Signed-off-by: Andreas Färber 
Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Rob Herring 
Acked-by: Arnd Bergmann 
---
 .../bindings/serial/rda,8810pl-uart.txt | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt

diff --git a/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt 
b/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt
new file mode 100644
index ..a08df97a69e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt
@@ -0,0 +1,17 @@
+RDA Micro UART
+
+Required properties:
+- compatible :  "rda,8810pl-uart" for RDA8810PL SoCs.
+- reg:  Offset and length of the register set for the device.
+- interrupts :  Should contain UART interrupt.
+- clocks :  Phandle to the input clock.
+
+
+Example:
+
+   uart2: serial@20a9 {
+   compatible = "rda,8810pl-uart";
+   reg = <0x20a9 0x1000>;
+   interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <_clk>;
+   };
-- 
2.17.1



[PATCH v7 03/11] ARM: Prepare RDA8810PL SoC

2018-12-18 Thread Manivannan Sadhasivam
From: Andreas Färber 

Introduce ARCH_RDA and mach-rda for RDA Micro SoCs.

Signed-off-by: Andreas Färber 
Signed-off-by: Manivannan Sadhasivam 
Acked-by: Arnd Bergmann 
---
 arch/arm/Kconfig   | 2 ++
 arch/arm/Makefile  | 1 +
 arch/arm/mach-rda/Kconfig  | 7 +++
 arch/arm/mach-rda/Makefile | 1 +
 4 files changed, 11 insertions(+)
 create mode 100644 arch/arm/mach-rda/Kconfig
 create mode 100644 arch/arm/mach-rda/Makefile

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 91be74d8df65..084f0983e6b2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -804,6 +804,8 @@ source "arch/arm/plat-pxa/Kconfig"
 
 source "arch/arm/mach-qcom/Kconfig"
 
+source "arch/arm/mach-rda/Kconfig"
+
 source "arch/arm/mach-realview/Kconfig"
 
 source "arch/arm/mach-rockchip/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 05a91d8b89f3..10056ccdb8be 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -202,6 +202,7 @@ machine-$(CONFIG_ARCH_ORION5X)  += orion5x
 machine-$(CONFIG_ARCH_PICOXCELL)   += picoxcell
 machine-$(CONFIG_ARCH_PXA) += pxa
 machine-$(CONFIG_ARCH_QCOM)+= qcom
+machine-$(CONFIG_ARCH_RDA) += rda
 machine-$(CONFIG_ARCH_REALVIEW)+= realview
 machine-$(CONFIG_ARCH_ROCKCHIP)+= rockchip
 machine-$(CONFIG_ARCH_RPC) += rpc
diff --git a/arch/arm/mach-rda/Kconfig b/arch/arm/mach-rda/Kconfig
new file mode 100644
index ..4df8b8ee1a9d
--- /dev/null
+++ b/arch/arm/mach-rda/Kconfig
@@ -0,0 +1,7 @@
+menuconfig ARCH_RDA
+   bool "RDA Micro SoCs"
+   depends on ARCH_MULTI_V7
+   select RDA_INTC
+   select RDA_TIMER
+   help
+ This enables support for the RDA Micro 8810PL SoC family.
diff --git a/arch/arm/mach-rda/Makefile b/arch/arm/mach-rda/Makefile
new file mode 100644
index ..6bea3d3a2dd7
--- /dev/null
+++ b/arch/arm/mach-rda/Makefile
@@ -0,0 +1 @@
+obj- += dummy.o
-- 
2.17.1



Re: [PATCH] Prevent race condition between USB authorisation and USB discovery events

2018-12-18 Thread Alan Stern
On Tue, 18 Dec 2018, Andrew Worsley wrote:

> On Tue, 18 Dec 2018 at 03:21, Alan Stern  wrote:
> >
> > On Mon, 17 Dec 2018, Andrew Worsley wrote:
> >
> > > A sysfs driven USB authorisation change can trigger a 
> > > usb_set_configuration
> > > while a hub_event worker thread is running. This can result in a USB 
> > > device
> > > being disabled just after it was configured and bringing down all the
> > > devices and impacting hardware and user processes that were established on
> > > top of this these interfaces. In some cases the USB disable never 
> > > completed
> > > and the whole system hung.
> >
> > Can you be more specific about this?  Disabling a USB device shouldn't
> > cause these kinds of problems, regardless of whether or not the device
> > was just configured.
> 
> I can't say too much about the hardware - but there was an SPI bus and
> an i2c bus built
> on top of USB devices on a bus. It appears the SPI bus shutdown was
> the item that was prone
> to problems when being torn down.
> 
> I understand it would be better if the dependant systems shutdown
> cleanly, which it
> did about 75% of the time but then it was rather messy sequence. So
> the current system
> is far from ideal. The crux of the issue is the usb_disable_device()
> (line 1874 of drivers/usb/core/message.c)
> call in usb_set_configuration() is applied to a configured device and
> triggers the
> tear down of all the devices built on that USB device and is very disruptive.

This is intentional.  When a USB device is disabled, nothing that
depends on it is supposed to survive.  However in spite of all the
disruption, nothing should hang.

> > > At my work I had an occasional hang due to this race condition. Roughly 1
> > > in 50 boots had the race occurrence and 1 in 4 of those resulted in a 
> > > hang.
> > > This patch fixed the problem and I had no problems (spurious disables
> > > or hangs) in 750+ boots.
> >
> > usb_authorize_device, usb_deauthorize_device, and hub_event all acquire
> > the device mutex.  Why should adding another mutex make any difference?
> 
> I believe the new usb_authorize_mutex prevents the cascade of USB
> device bus scans,
> discoveries and probes from colliding with those caused a change in
> USB bus authorisation.
> The individual device / hub locks are not across the whole system,
> only an individual
> component hub/device so any logic that gives an orderly USB device
> scanning and probing is
> undermined. The idea of the mutex is to keep the USB device discovery
> work when a device is
> added/removed/powered up is separated from those that are caused by
> authorisation changes.
> 
> I don't pretend to understand all the logic and sequencing of the
> current code which works works
> faultlessly when these threads are serialised by the mutex (750+
> times) in boot ups which
> build up the system and shutdowns which bring down the system.
> Likewise if I endlessly run
> the authorisation off / on by itself it is faultless over hundreds of
> iterations.

Can you post a dmesg log that illustrates the problem with dynamic
debugging enabled for the usbcore module?

> > In fact there's an actual disadvantage: Making hub_event acquire a
> > global mutex will prevent us from handling multiple hubs concurrently.
> > Although we don't do this now, we might want to in the future.
> >
> > Alan Stern
> 
> This is true - I am not trying to serialise the hub_event() threads -
> but to prevent the authorisation changes
> from happening during the hub_event threads. So perhaps there would be
> a way of allowing multiple
> concurrent hub_events from happening but only one authorisation thread
> at a time. Assuming multiple
> hub_event()s are deemed ok. Something like a lock which allows
> multiple readers but only a single exclusive
> writer lock?

It's not that simple.  There are other ways a USB device can be
disabled that don't involve authorization.  For example, the user can
do:

echo 0 >/sys/bus/usb/devices/.../bConfigurationValue

(the ... gets filled in with the device's path).  This should cause
just as much disruption.

The locking we already have is supposed to prevent the sort of problem 
you are seeing.  To find out why it doesn't, we need more information.

Alan Stern



[PATCH v7 09/11] ARM: dts: rda8810pl: Add interrupt support for UART

2018-12-18 Thread Manivannan Sadhasivam
Add interrupt support for UART in RDA Micro RDA8810PL SoC.

Signed-off-by: Andreas Färber 
Signed-off-by: Manivannan Sadhasivam 
Acked-by: Arnd Bergmann 
---
 arch/arm/boot/dts/rda8810pl.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/rda8810pl.dtsi b/arch/arm/boot/dts/rda8810pl.dtsi
index 84baa4c0a14c..19cde895bf65 100644
--- a/arch/arm/boot/dts/rda8810pl.dtsi
+++ b/arch/arm/boot/dts/rda8810pl.dtsi
@@ -71,18 +71,21 @@
uart1: serial@0 {
compatible = "rda,8810pl-uart";
reg = <0x0 0x1000>;
+   interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
};
 
uart2: serial@1 {
compatible = "rda,8810pl-uart";
reg = <0x1 0x1000>;
+   interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
};
 
uart3: serial@9 {
compatible = "rda,8810pl-uart";
reg = <0x9 0x1000>;
+   interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
};
};
-- 
2.17.1



[PATCH v7 06/11] ARM: dts: Add devicetree for OrangePi i96 board

2018-12-18 Thread Manivannan Sadhasivam
Add initial devicetree for Orange Pi i96 board from Xunlong. It
is one of the 96Boards IoT Edition board.

Signed-off-by: Andreas Färber 
Signed-off-by: Manivannan Sadhasivam 
Acked-by: Arnd Bergmann 
---
 arch/arm/boot/dts/Makefile   |  3 +-
 arch/arm/boot/dts/rda8810pl-orangepi-i96.dts | 50 
 2 files changed, 52 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/rda8810pl-orangepi-i96.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a0fdad8f10dd..cfb08ea33872 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -807,7 +807,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-msm8974-sony-xperia-honami.dtb \
qcom-mdm9615-wp8548-mangoh-green.dtb
 dtb-$(CONFIG_ARCH_RDA) += \
-   rda8810pl-orangepi-2g-iot.dtb
+   rda8810pl-orangepi-2g-iot.dtb \
+   rda8810pl-orangepi-i96.dtb
 dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pb1176.dtb \
arm-realview-pb11mp.dtb \
diff --git a/arch/arm/boot/dts/rda8810pl-orangepi-i96.dts 
b/arch/arm/boot/dts/rda8810pl-orangepi-i96.dts
new file mode 100644
index ..728f76931b99
--- /dev/null
+++ b/arch/arm/boot/dts/rda8810pl-orangepi-i96.dts
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ * Copyright (c) 2018 Manivannan Sadhasivam
+ */
+
+/dts-v1/;
+
+#include "rda8810pl.dtsi"
+
+/ {
+   compatible = "xunlong,orangepi-i96", "rda,8810pl";
+   model = "Orange Pi i96";
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   };
+
+   chosen {
+   stdout-path = "serial2:921600n8";
+   };
+
+   memory@8000 {
+   device_type = "memory";
+   reg = <0x8000 0x1000>;
+   };
+
+   uart_clk: uart-clk {
+   compatible = "fixed-clock";
+   clock-frequency = <921600>;
+   #clock-cells = <0>;
+   };
+};
+
+ {
+   status = "okay";
+   clocks = <_clk>;
+};
+
+ {
+   status = "okay";
+   clocks = <_clk>;
+};
+
+ {
+   status = "okay";
+   clocks = <_clk>;
+};
-- 
2.17.1



[PATCH v7 07/11] ARM: dts: rda8810pl: Add timer support

2018-12-18 Thread Manivannan Sadhasivam
Add timer support for RDA Micro RDA8810PL SoC.

Signed-off-by: Andreas Färber 
Signed-off-by: Manivannan Sadhasivam 
Acked-by: Arnd Bergmann 
---
 arch/arm/boot/dts/rda8810pl.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/rda8810pl.dtsi b/arch/arm/boot/dts/rda8810pl.dtsi
index 15547b138977..84baa4c0a14c 100644
--- a/arch/arm/boot/dts/rda8810pl.dtsi
+++ b/arch/arm/boot/dts/rda8810pl.dtsi
@@ -6,6 +6,8 @@
  * Copyright (c) 2018 Manivannan Sadhasivam
  */
 
+#include 
+
 / {
compatible = "rda,8810pl";
interrupt-parent = <>;
@@ -50,6 +52,14 @@
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x2090 0x10>;
+
+   timer@1 {
+   compatible = "rda,8810pl-timer";
+   reg = <0x1 0x1000>;
+   interrupts = <16 IRQ_TYPE_LEVEL_HIGH>,
+<17 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-names = "hwtimer", "ostimer";
+   };
};
 
apb@20a0 {
-- 
2.17.1



[PATCH v7 10/11] tty: serial: Add RDA8810PL UART driver

2018-12-18 Thread Manivannan Sadhasivam
Add UART driver for RDA Micro RDA8810PL SoC.

Signed-off-by: Andreas Färber 
Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Greg Kroah-Hartman 
Acked-by: Arnd Bergmann 
---
 .../admin-guide/kernel-parameters.txt |   6 +
 drivers/tty/serial/Kconfig|  19 +
 drivers/tty/serial/Makefile   |   1 +
 drivers/tty/serial/rda-uart.c | 831 ++
 include/uapi/linux/serial_core.h  |   3 +
 5 files changed, 860 insertions(+)
 create mode 100644 drivers/tty/serial/rda-uart.c

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index aefd358a5ca3..98ee9eaa52be 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1021,6 +1021,12 @@
specified address. The serial port must already be
setup and configured. Options are not yet supported.
 
+   rda,
+   Start an early, polled-mode console on a serial port
+   of an RDA Micro SoC, such as RDA8810PL, at the
+   specified address. The serial port must already be
+   setup and configured. Options are not yet supported.
+
smh Use ARM semihosting calls for early console.
 
s3c2410,
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 32886c304641..67b9bf3b500e 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1529,6 +1529,25 @@ config SERIAL_OWL_CONSOLE
  Say 'Y' here if you wish to use Actions Semiconductor S500/S900 UART
  as the system console.
 
+config SERIAL_RDA
+   bool "RDA Micro serial port support"
+   depends on ARCH_RDA || COMPILE_TEST
+   select SERIAL_CORE
+   help
+ This driver is for RDA8810PL SoC's UART.
+ Say 'Y' here if you wish to use the on-board serial port.
+ Otherwise, say 'N'.
+
+config SERIAL_RDA_CONSOLE
+   bool "Console on RDA Micro serial port"
+   depends on SERIAL_RDA=y
+   select SERIAL_CORE_CONSOLE
+   select SERIAL_EARLYCON
+   default y
+   help
+ Say 'Y' here if you wish to use the RDA8810PL UART as the system
+ console. Only earlycon is implemented currently.
+
 endmenu
 
 config SERIAL_MCTRL_GPIO
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index daac675612df..8c303736b7e8 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_SERIAL_MVEBU_UART)   += mvebu-uart.o
 obj-$(CONFIG_SERIAL_PIC32) += pic32_uart.o
 obj-$(CONFIG_SERIAL_MPS2_UART) += mps2-uart.o
 obj-$(CONFIG_SERIAL_OWL)   += owl-uart.o
+obj-$(CONFIG_SERIAL_RDA)   += rda-uart.o
 
 # GPIOLIB helpers for modem control lines
 obj-$(CONFIG_SERIAL_MCTRL_GPIO)+= serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/rda-uart.c b/drivers/tty/serial/rda-uart.c
new file mode 100644
index ..284623eefaeb
--- /dev/null
+++ b/drivers/tty/serial/rda-uart.c
@@ -0,0 +1,831 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * RDA8810PL serial device driver
+ *
+ * Copyright RDA Microelectronics Company Limited
+ * Copyright (c) 2017 Andreas Färber
+ * Copyright (c) 2018 Manivannan Sadhasivam
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RDA_UART_PORT_NUM 3
+#define RDA_UART_DEV_NAME "ttyRDA"
+
+#define RDA_UART_CTRL  0x00
+#define RDA_UART_STATUS0x04
+#define RDA_UART_RXTX_BUFFER   0x08
+#define RDA_UART_IRQ_MASK  0x0c
+#define RDA_UART_IRQ_CAUSE 0x10
+#define RDA_UART_IRQ_TRIGGERS  0x14
+#define RDA_UART_CMD_SET   0x18
+#define RDA_UART_CMD_CLR   0x1c
+
+/* UART_CTRL Bits */
+#define RDA_UART_ENABLEBIT(0)
+#define RDA_UART_DBITS_8   BIT(1)
+#define RDA_UART_TX_SBITS_2BIT(2)
+#define RDA_UART_PARITY_EN BIT(3)
+#define RDA_UART_PARITY(x) (((x) & 0x3) << 4)
+#define RDA_UART_PARITY_ODDRDA_UART_PARITY(0)
+#define RDA_UART_PARITY_EVEN   RDA_UART_PARITY(1)
+#define RDA_UART_PARITY_SPACE  RDA_UART_PARITY(2)
+#define RDA_UART_PARITY_MARK   RDA_UART_PARITY(3)
+#define RDA_UART_DIV_MODE  BIT(20)
+#define RDA_UART_IRDA_EN   BIT(21)
+#define RDA_UART_DMA_ENBIT(22)
+#define RDA_UART_FLOW_CNT_EN   BIT(23)
+#define RDA_UART_LOOP_BACK_EN  BIT(24)
+#define RDA_UART_RX_LOCK_ERR   BIT(25)
+#define RDA_UART_RX_BREAK_LEN(x)   (((x) & 0xf) << 28)
+
+/* UART_STATUS Bits */
+#define RDA_UART_RX_FIFO(x)(((x) & 0x7f) << 0)
+#define RDA_UART_RX_FIFO_MASK  (0x7f << 0)
+#define RDA_UART_TX_FIFO(x)(((x) & 0x1f) << 8)
+#define RDA_UART_TX_FIFO_MASK  

<    1   2   3   4   5   6   7   8   9   10   >