[PATCH net 4/6] rxrpc: Once packet posted in data_ready, don't retry posting

[David Howells]

Once a packet has been posted to a connection in the data_ready handler, we
mustn't try reposting if we then find that the connection is dying as the
refcount has been given over to the dying connection and the packet might
no longer exist.

Losing the packet isn't a problem as the peer will retransmit.

Signed-off-by: David Howells 
---

 net/rxrpc/input.c |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index 9e0f58edcd01..04afdc09557b 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -567,13 +567,13 @@ done:
  * post connection-level events to the connection
  * - this includes challenges, responses and some aborts
  */
-static bool rxrpc_post_packet_to_conn(struct rxrpc_connection *conn,
+static void rxrpc_post_packet_to_conn(struct rxrpc_connection *conn,
  struct sk_buff *skb)
 {
_enter("%p,%p", conn, skb);
 
skb_queue_tail(>rx_queue, skb);
-   return rxrpc_queue_conn(conn);
+   rxrpc_queue_conn(conn);
 }
 
 /*
@@ -694,7 +694,6 @@ void rxrpc_data_ready(struct sock *sk)
 
rcu_read_lock();
 
-retry_find_conn:
conn = rxrpc_find_connection_rcu(local, skb);
if (!conn)
goto cant_route_call;
@@ -702,8 +701,7 @@ retry_find_conn:
if (sp->hdr.callNumber == 0) {
/* Connection-level packet */
_debug("CONN %p {%d}", conn, conn->debug_id);
-   if (!rxrpc_post_packet_to_conn(conn, skb))
-   goto retry_find_conn;
+   rxrpc_post_packet_to_conn(conn, skb);
} else {
/* Call-bound packets are routed by connection channel. */
unsigned int channel = sp->hdr.cid & RXRPC_CHANNELMASK;

[PATCH net 5/6] rxrpc: Fix a use-after-push in data_ready handler

[David Howells]

Fix a use of a packet after it has been enqueued onto the packet processing
queue in the data_ready handler.  Once on a call's Rx queue, we mustn't
touch it any more as it may be dequeued and freed by the call processor
running on a work queue.

Save the values we need before enqueuing.

Without this, we can get an oops like the following:

BUG: unable to handle kernel NULL pointer dereference at 009c
IP: [] rxrpc_fast_process_packet+0x724/0xa11 [af_rxrpc]
PGD 0
Oops:  [#1] SMP
Modules linked in: kafs(E) af_rxrpc(E) [last unloaded: af_rxrpc]
CPU: 2 PID: 0 Comm: swapper/2 Tainted: GE   4.7.0-fsdevel+ #1336
Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
task: 88040d6863c0 task.stack: 88040d68c000
RIP: 0010:[]  [] 
rxrpc_fast_process_packet+0x724/0xa11 [af_rxrpc]
RSP: 0018:88041fb03a78  EFLAGS: 00010246
RAX:  RBX: 8803ff195b00 RCX: 0001
RDX: a01854d1 RSI: 0008 RDI: 8803ff195b00
RBP: 88041fb03ab0 R08:  R09: 0001
R10: 88041fb038c8 R11:  R12: 880406874800
R13: 0001 R14:  R15: 
FS:  () GS:88041fb0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 009c CR3: 01c14000 CR4: 001406e0
Stack:
 8803ff195ea0 880408348800 880406874800 8803ff195b00
 880408348800 8803ff195ed8  88041fb03af0
 a0186072  8804054da000 
Call Trace:
 
 [] rxrpc_data_ready+0x89d/0xbae [af_rxrpc]
 [] __sock_queue_rcv_skb+0x24c/0x2b2
 [] __udp_queue_rcv_skb+0x4b/0x1bd
 [] udp_queue_rcv_skb+0x281/0x4db
 [] __udp4_lib_rcv+0x7ed/0x963
 [] udp_rcv+0x15/0x17
 [] ip_local_deliver_finish+0x1c3/0x318
 [] ip_local_deliver+0xbb/0xc4
 [] ? inet_del_offload+0x40/0x40
 [] ip_rcv_finish+0x3ce/0x42c
 [] ip_rcv+0x304/0x33d
 [] ? ip_local_deliver_finish+0x318/0x318
 [] __netif_receive_skb_core+0x601/0x6e8
 [] __netif_receive_skb+0x13/0x54
 [] netif_receive_skb_internal+0xbb/0x17c
 [] napi_gro_receive+0xf9/0x1bd
 [] rtl8169_poll+0x32b/0x4a8
 [] net_rx_action+0xe8/0x357
 [] __do_softirq+0x1aa/0x414
 [] irq_exit+0x3d/0xb0
 [] do_IRQ+0xe4/0xfc
 [] common_interrupt+0x93/0x93
 
 [] ? cpuidle_enter_state+0x1ad/0x2be
 [] ? cpuidle_enter_state+0x1a8/0x2be
 [] cpuidle_enter+0x12/0x14
 [] call_cpuidle+0x39/0x3b
 [] cpu_startup_entry+0x230/0x35d
 [] start_secondary+0xf4/0xf7

Signed-off-by: David Howells 
---

 net/rxrpc/input.c |   17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index 04afdc09557b..789719031462 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -124,11 +124,15 @@ static int rxrpc_fast_process_data(struct rxrpc_call 
*call,
struct rxrpc_skb_priv *sp;
bool terminal;
int ret, ackbit, ack;
+   u32 serial;
+   u8 flags;
 
_enter("{%u,%u},,{%u}", call->rx_data_post, call->rx_first_oos, seq);
 
sp = rxrpc_skb(skb);
ASSERTCMP(sp->call, ==, NULL);
+   flags = sp->hdr.flags;
+   serial = sp->hdr.serial;
 
spin_lock(>lock);
 
@@ -192,8 +196,8 @@ static int rxrpc_fast_process_data(struct rxrpc_call *call,
sp->call = call;
rxrpc_get_call(call);
atomic_inc(>skb_count);
-   terminal = ((sp->hdr.flags & RXRPC_LAST_PACKET) &&
-   !(sp->hdr.flags & RXRPC_CLIENT_INITIATED));
+   terminal = ((flags & RXRPC_LAST_PACKET) &&
+   !(flags & RXRPC_CLIENT_INITIATED));
ret = rxrpc_queue_rcv_skb(call, skb, false, terminal);
if (ret < 0) {
if (ret == -ENOMEM || ret == -ENOBUFS) {
@@ -205,12 +209,13 @@ static int rxrpc_fast_process_data(struct rxrpc_call 
*call,
}
 
skb = NULL;
+   sp = NULL;
 
_debug("post #%u", seq);
ASSERTCMP(call->rx_data_post, ==, seq);
call->rx_data_post++;
 
-   if (sp->hdr.flags & RXRPC_LAST_PACKET)
+   if (flags & RXRPC_LAST_PACKET)
set_bit(RXRPC_CALL_RCVD_LAST, >flags);
 
/* if we've reached an out of sequence packet then we need to drain
@@ -226,7 +231,7 @@ static int rxrpc_fast_process_data(struct rxrpc_call *call,
 
spin_unlock(>lock);
atomic_inc(>ackr_not_idle);
-   rxrpc_propose_ACK(call, RXRPC_ACK_DELAY, sp->hdr.serial, false);
+   rxrpc_propose_ACK(call, RXRPC_ACK_DELAY, serial, false);
_leave(" = 0 [posted]");
return 0;
 
@@ -239,7 +244,7 @@ out:
 
 discard_and_ack:
_debug("discard and ACK packet %p", skb);
-   __rxrpc_propose_ACK(call, ack, sp->hdr.serial, true);
+   __rxrpc_propose_ACK(call, ack, serial, true);
 discard:
spin_unlock(>lock);
rxrpc_free_skb(skb);
@@ -247,7 +252,7 @@ discard:
return 0;
 
 enqueue_and_ack:
-   __rxrpc_propose_ACK(call, ack, sp->hdr.serial, 

[PATCH net 0/6] rxrpc: Miscellaneous fixes

[David Howells]

Hi Dave,

Here are a bunch of miscellaneous fixes to AF_RXRPC:

 (*) Fix an uninitialised pointer.

 (*) Fix error handling when we fail to connect a call.

 (*) Fix a NULL pointer dereference.

 (*) Fix two occasions where a packet is accessed again after being queued
 for someone else to deal with.

 (*) Fix a missing skb free.

---
The patches can be found here also:


http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-fixes

Tagged thusly:

git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
rxrpc-fixes-20160809

David
---
Arnd Bergmann (1):
  rxrpc: fix uninitialized pointer dereference in debug code

David Howells (5):
  rxrpc: Need to flag call as being released on connect failure
  rxrpc: Don't access connection from call if pointer is NULL
  rxrpc: Once packet posted in data_ready, don't retry posting
  rxrpc: Fix a use-after-push in data_ready handler
  rxrpc: Free packets discarded in data_ready


 net/rxrpc/call_event.c  |4 
 net/rxrpc/call_object.c |3 +++
 net/rxrpc/input.c   |   27 ---
 3 files changed, 23 insertions(+), 11 deletions(-)

[PATCH net 2/6] rxrpc: Need to flag call as being released on connect failure

[David Howells]

If rxrpc_new_client_call() fails to make a connection, the call record that
it allocated needs to be marked as RXRPC_CALL_RELEASED before it is passed
to rxrpc_put_call() to indicate that it no longer has any attachment to the
AF_RXRPC socket.

Without this, an assertion failure may occur at:

net/rxrpc/call_object:635

Signed-off-by: David Howells 
---

 net/rxrpc/call_object.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
index e8c953c48cb8..ae057e0740f3 100644
--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -275,6 +275,7 @@ error:
list_del_init(>link);
write_unlock_bh(_call_lock);
 
+   set_bit(RXRPC_CALL_RELEASED, >flags);
call->state = RXRPC_CALL_DEAD;
rxrpc_put_call(call);
_leave(" = %d", ret);
@@ -287,6 +288,7 @@ error:
 */
 found_user_ID_now_present:
write_unlock(>call_lock);
+   set_bit(RXRPC_CALL_RELEASED, >flags);
call->state = RXRPC_CALL_DEAD;
rxrpc_put_call(call);
_leave(" = -EEXIST [%p]", call);

[PATCH net 1/6] rxrpc: fix uninitialized pointer dereference in debug code

[David Howells]

From: Arnd Bergmann 

A newly added bugfix caused an uninitialized variable to be
used for printing debug output. This is harmless as long
as the debug setting is disabled, but otherwise leads to an
immediate crash.

gcc warns about this when -Wmaybe-uninitialized is enabled:

net/rxrpc/call_object.c: In function 'rxrpc_release_call':
net/rxrpc/call_object.c:496:163: error: 'sp' may be used uninitialized in this 
function [-Werror=maybe-uninitialized]

The initialization was removed but one of the users remains.
This adds back the initialization.

Signed-off-by: Arnd Bergmann 
Fixes: 372ee16386bb ("rxrpc: Fix races between skb free, ACK generation and 
replying")
Signed-off-by: David Howells 
---

 net/rxrpc/call_object.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
index c47f14fc5e88..e8c953c48cb8 100644
--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -493,6 +493,7 @@ void rxrpc_release_call(struct rxrpc_call *call)
   (skb = skb_dequeue(>rx_oos_queue))) {
spin_unlock_bh(>lock);
 
+   sp = rxrpc_skb(skb);
_debug("- zap %s %%%u #%u",
   rxrpc_pkts[sp->hdr.type],
   sp->hdr.serial, sp->hdr.seq);

[PATCH net 0/6] rxrpc: Miscellaneous fixes

[David Howells]

Hi Dave,

Here are a bunch of miscellaneous fixes to AF_RXRPC:

 (*) Fix an uninitialised pointer.

 (*) Fix error handling when we fail to connect a call.

 (*) Fix a NULL pointer dereference.

 (*) Fix two occasions where a packet is accessed again after being queued
 for someone else to deal with.

 (*) Fix a missing skb free.

---
The patches can be found here also:


http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-fixes

Tagged thusly:

git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
rxrpc-fixes-20160809

David
---
Arnd Bergmann (1):
  rxrpc: fix uninitialized pointer dereference in debug code

David Howells (5):
  rxrpc: Need to flag call as being released on connect failure
  rxrpc: Don't access connection from call if pointer is NULL
  rxrpc: Once packet posted in data_ready, don't retry posting
  rxrpc: Fix a use-after-push in data_ready handler
  rxrpc: Free packets discarded in data_ready


 net/rxrpc/call_event.c  |4 
 net/rxrpc/call_object.c |3 +++
 net/rxrpc/input.c   |   27 ---
 3 files changed, 23 insertions(+), 11 deletions(-)

[PATCH net 2/6] rxrpc: Need to flag call as being released on connect failure

[David Howells]

If rxrpc_new_client_call() fails to make a connection, the call record that
it allocated needs to be marked as RXRPC_CALL_RELEASED before it is passed
to rxrpc_put_call() to indicate that it no longer has any attachment to the
AF_RXRPC socket.

Without this, an assertion failure may occur at:

net/rxrpc/call_object:635

Signed-off-by: David Howells 
---

 net/rxrpc/call_object.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
index e8c953c48cb8..ae057e0740f3 100644
--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -275,6 +275,7 @@ error:
list_del_init(>link);
write_unlock_bh(_call_lock);
 
+   set_bit(RXRPC_CALL_RELEASED, >flags);
call->state = RXRPC_CALL_DEAD;
rxrpc_put_call(call);
_leave(" = %d", ret);
@@ -287,6 +288,7 @@ error:
 */
 found_user_ID_now_present:
write_unlock(>call_lock);
+   set_bit(RXRPC_CALL_RELEASED, >flags);
call->state = RXRPC_CALL_DEAD;
rxrpc_put_call(call);
_leave(" = -EEXIST [%p]", call);

[PATCH net 1/6] rxrpc: fix uninitialized pointer dereference in debug code

[David Howells]

From: Arnd Bergmann 

A newly added bugfix caused an uninitialized variable to be
used for printing debug output. This is harmless as long
as the debug setting is disabled, but otherwise leads to an
immediate crash.

gcc warns about this when -Wmaybe-uninitialized is enabled:

net/rxrpc/call_object.c: In function 'rxrpc_release_call':
net/rxrpc/call_object.c:496:163: error: 'sp' may be used uninitialized in this 
function [-Werror=maybe-uninitialized]

The initialization was removed but one of the users remains.
This adds back the initialization.

Signed-off-by: Arnd Bergmann 
Fixes: 372ee16386bb ("rxrpc: Fix races between skb free, ACK generation and 
replying")
Signed-off-by: David Howells 
---

 net/rxrpc/call_object.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
index c47f14fc5e88..e8c953c48cb8 100644
--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -493,6 +493,7 @@ void rxrpc_release_call(struct rxrpc_call *call)
   (skb = skb_dequeue(>rx_oos_queue))) {
spin_unlock_bh(>lock);
 
+   sp = rxrpc_skb(skb);
_debug("- zap %s %%%u #%u",
   rxrpc_pkts[sp->hdr.type],
   sp->hdr.serial, sp->hdr.seq);

[PATCH net 3/6] rxrpc: Don't access connection from call if pointer is NULL

[David Howells]

The call state machine processor sets up the message parameters for a UDP
message that it might need to transmit in advance on the basis that there's
a very good chance it's going to have to transmit either an ACK or an
ABORT.  This requires it to look in the connection struct to retrieve some
of the parameters.

However, if the call is complete, the call connection pointer may be NULL
to dissuade the processor from transmitting a message.  However, there are
some situations where the processor is still going to be called - and it's
still going to set up message parameters whether it needs them or not.

This results in a NULL pointer dereference at:

net/rxrpc/call_event.c:837

To fix this, skip the message pre-initialisation if there's no connection
attached.

Signed-off-by: David Howells 
---

 net/rxrpc/call_event.c |4 
 1 file changed, 4 insertions(+)

diff --git a/net/rxrpc/call_event.c b/net/rxrpc/call_event.c
index f5e99163a09e..e60cf65c2232 100644
--- a/net/rxrpc/call_event.c
+++ b/net/rxrpc/call_event.c
@@ -837,6 +837,9 @@ void rxrpc_process_call(struct work_struct *work)
return;
}
 
+   if (!call->conn)
+   goto skip_msg_init;
+
/* there's a good chance we're going to have to send a message, so set
 * one up in advance */
msg.msg_name= >conn->params.peer->srx.transport;
@@ -859,6 +862,7 @@ void rxrpc_process_call(struct work_struct *work)
memset(iov, 0, sizeof(iov));
iov[0].iov_base = 
iov[0].iov_len  = sizeof(whdr);
+skip_msg_init:
 
/* deal with events of a final nature */
if (test_bit(RXRPC_CALL_EV_RCVD_ERROR, >events)) {

[PATCH net 3/6] rxrpc: Don't access connection from call if pointer is NULL

[David Howells]

The call state machine processor sets up the message parameters for a UDP
message that it might need to transmit in advance on the basis that there's
a very good chance it's going to have to transmit either an ACK or an
ABORT.  This requires it to look in the connection struct to retrieve some
of the parameters.

However, if the call is complete, the call connection pointer may be NULL
to dissuade the processor from transmitting a message.  However, there are
some situations where the processor is still going to be called - and it's
still going to set up message parameters whether it needs them or not.

This results in a NULL pointer dereference at:

net/rxrpc/call_event.c:837

To fix this, skip the message pre-initialisation if there's no connection
attached.

Signed-off-by: David Howells 
---

 net/rxrpc/call_event.c |4 
 1 file changed, 4 insertions(+)

diff --git a/net/rxrpc/call_event.c b/net/rxrpc/call_event.c
index f5e99163a09e..e60cf65c2232 100644
--- a/net/rxrpc/call_event.c
+++ b/net/rxrpc/call_event.c
@@ -837,6 +837,9 @@ void rxrpc_process_call(struct work_struct *work)
return;
}
 
+   if (!call->conn)
+   goto skip_msg_init;
+
/* there's a good chance we're going to have to send a message, so set
 * one up in advance */
msg.msg_name= >conn->params.peer->srx.transport;
@@ -859,6 +862,7 @@ void rxrpc_process_call(struct work_struct *work)
memset(iov, 0, sizeof(iov));
iov[0].iov_base = 
iov[0].iov_len  = sizeof(whdr);
+skip_msg_init:
 
/* deal with events of a final nature */
if (test_bit(RXRPC_CALL_EV_RCVD_ERROR, >events)) {

Re: drivers/spi/spi.c:1160:3-9: preceding lock on line 1153

[Mark Brown]

On Tue, Aug 09, 2016 at 06:19:13PM +0200, Julia Lawall wrote:

> Looks worth checking.

I don't really have any idea what this is trying to tell me, sorry.

> 
> julia
> 
> -- Forwarded message --
> Date: Wed, 10 Aug 2016 00:17:07 +0800
> From: kbuild test robot 
> To: kbu...@01.org
> Cc: Julia Lawall 
> Subject: drivers/spi/spi.c:1160:3-9: preceding lock on line 1153
> 
> CC: kbuild-...@01.org
> CC: linux-kernel@vger.kernel.org
> TO: Mark Brown 
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   81abf2525827b29839a78fd55ab0699f033c41a5
> commit: ef4d96ec4ad947360f48677b6007a4c77953b090 spi: Split bus and I/O 
> locking
> date:   2 weeks ago
> :: branch date: 18 hours ago
> :: commit date: 2 weeks ago
> 
> >> drivers/spi/spi.c:1160:3-9: preceding lock on line 1153
> 
> git remote add linus 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git remote update linus
> git checkout ef4d96ec4ad947360f48677b6007a4c77953b090
> vim +1160 drivers/spi/spi.c
> 
> ffbbdd213 Linus Walleij 2012-02-22  1147  if (master->busy)
> ffbbdd213 Linus Walleij 2012-02-22  1148  was_busy = true;
> ffbbdd213 Linus Walleij 2012-02-22  1149  else
> ffbbdd213 Linus Walleij 2012-02-22  1150  master->busy = true;
> ffbbdd213 Linus Walleij 2012-02-22  1151  
> spin_unlock_irqrestore(>queue_lock, flags);
> ffbbdd213 Linus Walleij 2012-02-22  1152
> ef4d96ec4 Mark Brown2016-07-21 @1153  mutex_lock(>io_mutex);
> ef4d96ec4 Mark Brown2016-07-21  1154
> 49834de23 Mark Brown2013-07-28  1155  if (!was_busy && 
> master->auto_runtime_pm) {
> 49834de23 Mark Brown2013-07-28  1156  ret = 
> pm_runtime_get_sync(master->dev.parent);
> 49834de23 Mark Brown2013-07-28  1157  if (ret < 0) {
> 49834de23 Mark Brown2013-07-28  1158  
> dev_err(>dev, "Failed to power device: %d\n",
> 49834de23 Mark Brown2013-07-28  1159  ret);
> 49834de23 Mark Brown2013-07-28 @1160  return;
> 49834de23 Mark Brown2013-07-28  1161  }
> 49834de23 Mark Brown2013-07-28  1162  }
> 49834de23 Mark Brown2013-07-28  1163
> 
> :: The code at line 1160 was first introduced by commit
> :: 49834de234f3cf592c3d242c889ca603db8e7050 spi: Provide core support for 
> runtime PM during transfers
> 
> :: TO: Mark Brown 
> :: CC: Mark Brown 
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation


signature.asc
Description: PGP signature

Re: drivers/spi/spi.c:1160:3-9: preceding lock on line 1153

[Mark Brown]

On Tue, Aug 09, 2016 at 06:19:13PM +0200, Julia Lawall wrote:

> Looks worth checking.

I don't really have any idea what this is trying to tell me, sorry.

> 
> julia
> 
> -- Forwarded message --
> Date: Wed, 10 Aug 2016 00:17:07 +0800
> From: kbuild test robot 
> To: kbu...@01.org
> Cc: Julia Lawall 
> Subject: drivers/spi/spi.c:1160:3-9: preceding lock on line 1153
> 
> CC: kbuild-...@01.org
> CC: linux-kernel@vger.kernel.org
> TO: Mark Brown 
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   81abf2525827b29839a78fd55ab0699f033c41a5
> commit: ef4d96ec4ad947360f48677b6007a4c77953b090 spi: Split bus and I/O 
> locking
> date:   2 weeks ago
> :: branch date: 18 hours ago
> :: commit date: 2 weeks ago
> 
> >> drivers/spi/spi.c:1160:3-9: preceding lock on line 1153
> 
> git remote add linus 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git remote update linus
> git checkout ef4d96ec4ad947360f48677b6007a4c77953b090
> vim +1160 drivers/spi/spi.c
> 
> ffbbdd213 Linus Walleij 2012-02-22  1147  if (master->busy)
> ffbbdd213 Linus Walleij 2012-02-22  1148  was_busy = true;
> ffbbdd213 Linus Walleij 2012-02-22  1149  else
> ffbbdd213 Linus Walleij 2012-02-22  1150  master->busy = true;
> ffbbdd213 Linus Walleij 2012-02-22  1151  
> spin_unlock_irqrestore(>queue_lock, flags);
> ffbbdd213 Linus Walleij 2012-02-22  1152
> ef4d96ec4 Mark Brown2016-07-21 @1153  mutex_lock(>io_mutex);
> ef4d96ec4 Mark Brown2016-07-21  1154
> 49834de23 Mark Brown2013-07-28  1155  if (!was_busy && 
> master->auto_runtime_pm) {
> 49834de23 Mark Brown2013-07-28  1156  ret = 
> pm_runtime_get_sync(master->dev.parent);
> 49834de23 Mark Brown2013-07-28  1157  if (ret < 0) {
> 49834de23 Mark Brown2013-07-28  1158  
> dev_err(>dev, "Failed to power device: %d\n",
> 49834de23 Mark Brown2013-07-28  1159  ret);
> 49834de23 Mark Brown2013-07-28 @1160  return;
> 49834de23 Mark Brown2013-07-28  1161  }
> 49834de23 Mark Brown2013-07-28  1162  }
> 49834de23 Mark Brown2013-07-28  1163
> 
> :: The code at line 1160 was first introduced by commit
> :: 49834de234f3cf592c3d242c889ca603db8e7050 spi: Provide core support for 
> runtime PM during transfers
> 
> :: TO: Mark Brown 
> :: CC: Mark Brown 
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation


signature.asc
Description: PGP signature

Re: [PATCH 1/2] of/irq: Mark interrupt controllers as populated before initialisation

[Jon Hunter]

On 09/08/16 15:18, Philipp Zabel wrote:
> That way the init callback may clear the flag again, in case of drivers
> split between early irq chip and a normal platform driver.
> 
> Fixes: 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt controllers as 
> populated")
> Suggested-by: Rob Herring 
> Signed-off-by: Philipp Zabel 
> Cc: Jon Hunter 
> ---
>  drivers/of/irq.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 89a71c6..a2e68f7 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -544,12 +544,15 @@ void __init of_irq_init(const struct of_device_id 
> *matches)
>  
>   list_del(>list);
>  
> + of_node_set_flag(desc->dev, OF_POPULATED);
> +
>   pr_debug("of_irq_init: init %s (%p), parent %p\n",
>desc->dev->full_name,
>desc->dev, desc->interrupt_parent);
>   ret = desc->irq_init_cb(desc->dev,
>   desc->interrupt_parent);
>   if (ret) {
> + of_node_clear_flag(desc->dev, OF_POPULATED);
>   kfree(desc);
>   continue;
>   }
> @@ -559,8 +562,6 @@ void __init of_irq_init(const struct of_device_id 
> *matches)
>* its children can get processed in a subsequent pass.
>*/
>   list_add_tail(>list, _parent_list);
> -
> - of_node_set_flag(desc->dev, OF_POPULATED);
>   }
>  
>   /* Get the next pending parent that might have children */
> 

Acked-by: Jon Hunter 

Cheers
Jon

-- 
nvpublic

Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

[Thomas Garnier]

On Tue, Aug 9, 2016 at 9:03 AM, Joerg Roedel  wrote:
> On Tue, Aug 09, 2016 at 09:00:04AM -0700, Thomas Garnier wrote:
>> On Mon, Aug 8, 2016 at 11:40 AM, Thomas Garnier  wrote:
>> > Initialize KASLR memory randomization after max_pfn is initialized. Also
>> > ensure the size is rounded up. Could have create problems on machines
>> > with more than 1Tb of memory on certain random addresses.
>> >
>> > Signed-off-by: Thomas Garnier 
>>
>> I will send a new version of this PATCH soon. The test bot found
>> places where virtual addresses were computed before PAGE_OFFSET was
>> set. I will investigate that.
>
> When you do that, please also add 'Fixes:' tags to your patches.
>

Will do.

> Thanks,
>
> Joerg
>

Re: [PATCH 1/2] of/irq: Mark interrupt controllers as populated before initialisation

[Jon Hunter]

On 09/08/16 15:18, Philipp Zabel wrote:
> That way the init callback may clear the flag again, in case of drivers
> split between early irq chip and a normal platform driver.
> 
> Fixes: 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt controllers as 
> populated")
> Suggested-by: Rob Herring 
> Signed-off-by: Philipp Zabel 
> Cc: Jon Hunter 
> ---
>  drivers/of/irq.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 89a71c6..a2e68f7 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -544,12 +544,15 @@ void __init of_irq_init(const struct of_device_id 
> *matches)
>  
>   list_del(>list);
>  
> + of_node_set_flag(desc->dev, OF_POPULATED);
> +
>   pr_debug("of_irq_init: init %s (%p), parent %p\n",
>desc->dev->full_name,
>desc->dev, desc->interrupt_parent);
>   ret = desc->irq_init_cb(desc->dev,
>   desc->interrupt_parent);
>   if (ret) {
> + of_node_clear_flag(desc->dev, OF_POPULATED);
>   kfree(desc);
>   continue;
>   }
> @@ -559,8 +562,6 @@ void __init of_irq_init(const struct of_device_id 
> *matches)
>* its children can get processed in a subsequent pass.
>*/
>   list_add_tail(>list, _parent_list);
> -
> - of_node_set_flag(desc->dev, OF_POPULATED);
>   }
>  
>   /* Get the next pending parent that might have children */
> 

Acked-by: Jon Hunter 

Cheers
Jon

-- 
nvpublic

Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

[Thomas Garnier]

On Tue, Aug 9, 2016 at 9:03 AM, Joerg Roedel  wrote:
> On Tue, Aug 09, 2016 at 09:00:04AM -0700, Thomas Garnier wrote:
>> On Mon, Aug 8, 2016 at 11:40 AM, Thomas Garnier  wrote:
>> > Initialize KASLR memory randomization after max_pfn is initialized. Also
>> > ensure the size is rounded up. Could have create problems on machines
>> > with more than 1Tb of memory on certain random addresses.
>> >
>> > Signed-off-by: Thomas Garnier 
>>
>> I will send a new version of this PATCH soon. The test bot found
>> places where virtual addresses were computed before PAGE_OFFSET was
>> set. I will investigate that.
>
> When you do that, please also add 'Fixes:' tags to your patches.
>

Will do.

> Thanks,
>
> Joerg
>

Re: [PACTH v1] mm, proc: Implement /proc//totmaps

[Mateusz Guzik]

On Tue, Aug 09, 2016 at 12:05:43PM -0400, robert.f...@collabora.com wrote:
> From: Sonny Rao 
> 
> This is based on earlier work by Thiago Goncales. It implements a new
> per process proc file which summarizes the contents of the smaps file
> but doesn't display any addresses.  It gives more detailed information
> than statm like the PSS (proprotional set size).  It differs from the
> original implementation in that it doesn't use the full blown set of
> seq operations, uses a different termination condition, and doesn't
> displayed "Locked" as that was broken on the original implemenation.
> 
> This new proc file provides information faster than parsing the potentially
> huge smaps file.

I have no idea about usefulness of this.

The patch is definitely buggy with respect to how it implements actual
access to mm.

> +static int totmaps_proc_show(struct seq_file *m, void *data)
> +{
> + struct proc_maps_private *priv = m->private;
> + struct mm_struct *mm;
> + struct vm_area_struct *vma;
> + struct mem_size_stats *mss_sum = priv->mss;
> +
> + /* reference to priv->task already taken */
> + /* but need to get the mm here because */
> + /* task could be in the process of exiting */
> + mm = get_task_mm(priv->task);
> + if (!mm || IS_ERR(mm))
> + return -EINVAL;
> +

That's not how it's done in smaps.

> +static int totmaps_open(struct inode *inode, struct file *file)
> +{
> + struct proc_maps_private *priv;
> + int ret = -ENOMEM;
> + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> + if (priv) {
> + priv->mss = kzalloc(sizeof(*priv->mss), GFP_KERNEL);
> + if (!priv->mss)
> + return -ENOMEM;

Cases below explicitly kfree(priv). I can't remember whether the close
routine gets called if this one fails. Either way, something is wrong
here.

> +
> + /* we need to grab references to the task_struct */
> + /* at open time, because there's a potential information */
> + /* leak where the totmaps file is opened and held open */
> + /* while the underlying pid to task mapping changes */
> + /* underneath it */
> + priv->task = get_pid_task(proc_pid(inode), PIDTYPE_PID);

This performs no permission checks that I would see. If you take a look
at smaps you will see the user ends up in proc_maps_open which performs
proc_mem_open(inode, PTRACE_MODE_READ) and gets a mm from there.


> + if (!priv->task) {
> + kfree(priv->mss);
> + kfree(priv);
> + return -ESRCH;
> + }
> +
> + ret = single_open(file, totmaps_proc_show, priv);
> + if (ret) {
> + put_task_struct(priv->task);
> + kfree(priv->mss);
> + kfree(priv);
> + }
> + }
> + return ret;
> +}
> +

-- 
Mateusz Guzik

Re: [PACTH v1] mm, proc: Implement /proc//totmaps

[Mateusz Guzik]

On Tue, Aug 09, 2016 at 12:05:43PM -0400, robert.f...@collabora.com wrote:
> From: Sonny Rao 
> 
> This is based on earlier work by Thiago Goncales. It implements a new
> per process proc file which summarizes the contents of the smaps file
> but doesn't display any addresses.  It gives more detailed information
> than statm like the PSS (proprotional set size).  It differs from the
> original implementation in that it doesn't use the full blown set of
> seq operations, uses a different termination condition, and doesn't
> displayed "Locked" as that was broken on the original implemenation.
> 
> This new proc file provides information faster than parsing the potentially
> huge smaps file.

I have no idea about usefulness of this.

The patch is definitely buggy with respect to how it implements actual
access to mm.

> +static int totmaps_proc_show(struct seq_file *m, void *data)
> +{
> + struct proc_maps_private *priv = m->private;
> + struct mm_struct *mm;
> + struct vm_area_struct *vma;
> + struct mem_size_stats *mss_sum = priv->mss;
> +
> + /* reference to priv->task already taken */
> + /* but need to get the mm here because */
> + /* task could be in the process of exiting */
> + mm = get_task_mm(priv->task);
> + if (!mm || IS_ERR(mm))
> + return -EINVAL;
> +

That's not how it's done in smaps.

> +static int totmaps_open(struct inode *inode, struct file *file)
> +{
> + struct proc_maps_private *priv;
> + int ret = -ENOMEM;
> + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> + if (priv) {
> + priv->mss = kzalloc(sizeof(*priv->mss), GFP_KERNEL);
> + if (!priv->mss)
> + return -ENOMEM;

Cases below explicitly kfree(priv). I can't remember whether the close
routine gets called if this one fails. Either way, something is wrong
here.

> +
> + /* we need to grab references to the task_struct */
> + /* at open time, because there's a potential information */
> + /* leak where the totmaps file is opened and held open */
> + /* while the underlying pid to task mapping changes */
> + /* underneath it */
> + priv->task = get_pid_task(proc_pid(inode), PIDTYPE_PID);

This performs no permission checks that I would see. If you take a look
at smaps you will see the user ends up in proc_maps_open which performs
proc_mem_open(inode, PTRACE_MODE_READ) and gets a mm from there.


> + if (!priv->task) {
> + kfree(priv->mss);
> + kfree(priv);
> + return -ESRCH;
> + }
> +
> + ret = single_open(file, totmaps_proc_show, priv);
> + if (ret) {
> + put_task_struct(priv->task);
> + kfree(priv->mss);
> + kfree(priv);
> + }
> + }
> + return ret;
> +}
> +

-- 
Mateusz Guzik

Re: [PATCH] thp: move shmem_huge_enabled() outside of SYSFS ifdef

[Kirill A. Shutemov]

On Tue, Aug 09, 2016 at 02:36:02PM +0200, Arnd Bergmann wrote:
> The newly introduced shmem_huge_enabled() function has two definitions,
> but neither of them is visible if CONFIG_SYSFS is disabled, leading
> to a build error:
> 
> mm/khugepaged.o: In function `khugepaged':
> khugepaged.c:(.text.khugepaged+0x3ca): undefined reference to 
> `shmem_huge_enabled'
> 
> This changes the #ifdef guards around the definition to match those that
> are used in the header file.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: e496cf3d7821 ("thp: introduce CONFIG_TRANSPARENT_HUGE_PAGECACHE")

Acked-by: Kirill A. Shutemov 

-- 
 Kirill A. Shutemov

Re: [PATCH] rmap: Fix compound check logic in page_remove_file_rmap

[Kirill A. Shutemov]

On Tue, Aug 09, 2016 at 01:34:35PM +0100, Steve Capper wrote:
> In page_remove_file_rmap(.) we have the following check:
>   VM_BUG_ON_PAGE(compound && !PageTransHuge(page), page);
> 
> This is meant to check for either HugeTLB pages or THP when a compound
> page is passed in.
> 
> Unfortunately, if one disables CONFIG_TRANSPARENT_HUGEPAGE, then
> PageTransHuge(.) will always return false provoking BUGs when one runs
> the libhugetlbfs test suite.
> 
> Changing the definition of PageTransHuge to be defined for
> !CONFIG_TRANSPARENT_HUGEPAGE turned out to provoke build bugs; so this
> patch instead replaces the errant check with:
>   PageTransHuge(page) || PageHuge(page)

I think PageHead() check should be enough to cover this.

> 
> Fixes: dd78fedde4b9 ("rmap: support file thp")
> Cc: Kirill A. Shutemov 
> Cc: Andrew Morton 
> Signed-off-by: Steve Capper 
> ---
>  mm/rmap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 709bc83..ad8fc51 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1303,7 +1303,7 @@ static void page_remove_file_rmap(struct page *page, 
> bool compound)
>  {
>   int i, nr = 1;
>  
> - VM_BUG_ON_PAGE(compound && !PageTransHuge(page), page);
> + VM_BUG_ON_PAGE(compound && !(PageTransHuge(page) || PageHuge(page)), 
> page);
>   lock_page_memcg(page);
>  
>   /* Hugepages are not counted in NR_FILE_MAPPED for now. */
> -- 
> 1.8.3.1
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
 Kirill A. Shutemov

Re: [PATCH] thp: move shmem_huge_enabled() outside of SYSFS ifdef

[Kirill A. Shutemov]

On Tue, Aug 09, 2016 at 02:36:02PM +0200, Arnd Bergmann wrote:
> The newly introduced shmem_huge_enabled() function has two definitions,
> but neither of them is visible if CONFIG_SYSFS is disabled, leading
> to a build error:
> 
> mm/khugepaged.o: In function `khugepaged':
> khugepaged.c:(.text.khugepaged+0x3ca): undefined reference to 
> `shmem_huge_enabled'
> 
> This changes the #ifdef guards around the definition to match those that
> are used in the header file.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: e496cf3d7821 ("thp: introduce CONFIG_TRANSPARENT_HUGE_PAGECACHE")

Acked-by: Kirill A. Shutemov 

-- 
 Kirill A. Shutemov

Re: [PATCH] rmap: Fix compound check logic in page_remove_file_rmap

[Kirill A. Shutemov]

On Tue, Aug 09, 2016 at 01:34:35PM +0100, Steve Capper wrote:
> In page_remove_file_rmap(.) we have the following check:
>   VM_BUG_ON_PAGE(compound && !PageTransHuge(page), page);
> 
> This is meant to check for either HugeTLB pages or THP when a compound
> page is passed in.
> 
> Unfortunately, if one disables CONFIG_TRANSPARENT_HUGEPAGE, then
> PageTransHuge(.) will always return false provoking BUGs when one runs
> the libhugetlbfs test suite.
> 
> Changing the definition of PageTransHuge to be defined for
> !CONFIG_TRANSPARENT_HUGEPAGE turned out to provoke build bugs; so this
> patch instead replaces the errant check with:
>   PageTransHuge(page) || PageHuge(page)

I think PageHead() check should be enough to cover this.

> 
> Fixes: dd78fedde4b9 ("rmap: support file thp")
> Cc: Kirill A. Shutemov 
> Cc: Andrew Morton 
> Signed-off-by: Steve Capper 
> ---
>  mm/rmap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 709bc83..ad8fc51 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1303,7 +1303,7 @@ static void page_remove_file_rmap(struct page *page, 
> bool compound)
>  {
>   int i, nr = 1;
>  
> - VM_BUG_ON_PAGE(compound && !PageTransHuge(page), page);
> + VM_BUG_ON_PAGE(compound && !(PageTransHuge(page) || PageHuge(page)), 
> page);
>   lock_page_memcg(page);
>  
>   /* Hugepages are not counted in NR_FILE_MAPPED for now. */
> -- 
> 1.8.3.1
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
 Kirill A. Shutemov

[PATCH] NFC: pn533: constify pn533_phy_ops structures

[Julia Lawall]

The pn533_phy_ops are never modified, so declare them as const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/nfc/pn533/i2c.c   |2 +-
 drivers/nfc/pn533/pn533.c |2 +-
 drivers/nfc/pn533/pn533.h |4 ++--
 drivers/nfc/pn533/usb.c   |2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
index 1dc8924..8a7c17e 100644
--- a/drivers/nfc/pn533/i2c.c
+++ b/drivers/nfc/pn533/i2c.c
@@ -176,7 +176,7 @@ static irqreturn_t pn533_i2c_irq_thread_fn(int irq, void 
*data)
return IRQ_HANDLED;
 }
 
-static struct pn533_phy_ops i2c_phy_ops = {
+static const struct pn533_phy_ops i2c_phy_ops = {
.send_frame = pn533_i2c_send_frame,
.send_ack = pn533_i2c_send_ack,
.abort_cmd = pn533_i2c_abort_cmd,
diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
index d9c5583..2f817b3 100644
--- a/drivers/nfc/pn533/pn533.c
+++ b/drivers/nfc/pn533/pn533.c
@@ -2560,7 +2560,7 @@ struct pn533 *pn533_register_device(u32 device_type,
u32 protocols,
enum pn533_protocol_type protocol_type,
void *phy,
-   struct pn533_phy_ops *phy_ops,
+   const struct pn533_phy_ops *phy_ops,
struct pn533_frame_ops *fops,
struct device *dev,
struct device *parent)
diff --git a/drivers/nfc/pn533/pn533.h b/drivers/nfc/pn533/pn533.h
index 553c7d1..e26d634 100644
--- a/drivers/nfc/pn533/pn533.h
+++ b/drivers/nfc/pn533/pn533.h
@@ -179,7 +179,7 @@ struct pn533 {
 
struct device *dev;
void *phy;
-   struct pn533_phy_ops *phy_ops;
+   const struct pn533_phy_ops *phy_ops;
 };
 
 typedef int (*pn533_send_async_complete_t) (struct pn533 *dev, void *arg,
@@ -226,7 +226,7 @@ struct pn533 *pn533_register_device(u32 device_type,
u32 protocols,
enum pn533_protocol_type protocol_type,
void *phy,
-   struct pn533_phy_ops *phy_ops,
+   const struct pn533_phy_ops *phy_ops,
struct pn533_frame_ops *fops,
struct device *dev,
struct device *parent);
diff --git a/drivers/nfc/pn533/usb.c b/drivers/nfc/pn533/usb.c
index 33ed78b..bcf3f54 100644
--- a/drivers/nfc/pn533/usb.c
+++ b/drivers/nfc/pn533/usb.c
@@ -434,7 +434,7 @@ static void pn533_send_complete(struct urb *urb)
}
 }
 
-static struct pn533_phy_ops usb_phy_ops = {
+static const struct pn533_phy_ops usb_phy_ops = {
.send_frame = pn533_usb_send_frame,
.send_ack = pn533_usb_send_ack,
.abort_cmd = pn533_usb_abort_cmd,

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

[Thomas Garnier]

On Tue, Aug 9, 2016 at 9:18 AM, Rafael J. Wysocki  wrote:
> On Tue, Aug 9, 2016 at 5:05 PM, Jiri Kosina  wrote:
>> On Tue, 9 Aug 2016, Thomas Garnier wrote:
>>
>>> >> Okay, I did one-by-one reverts, and the one above, i.e.
>>> >>
>>> >>   commit 021182e52fe01c1f7b126f97fd6ba048dc4234fd
>>> >>   Author: Thomas Garnier 
>>> >>   Date:   Tue Jun 21 17:47:03 2016 -0700
>>> >>
>>> >>   x86/mm: Enable KASLR for physical mapping memory regions
>>> >>
>>> >> is the one that is the culprit on my machine. With this one reverted,
>>> >> resume hibernation doesn't reboot (tripple fault?), but proceeds
>>> >> succesfully.
>>>
>>> My .config is attached. It is basically defconfig (x86_64) + kvmconfig
>>> plus the following:
>>>
>>> CONFIG_PHYSICAL_START=0x100
>>> CONFIG_RELOCATABLE=y
>>> CONFIG_RANDOMIZE_BASE=y
>>> CONFIG_X86_NEED_RELOCS=y
>>> CONFIG_PHYSICAL_ALIGN=0x100
>>> CONFIG_RANDOMIZE_MEMORY=y
>>> CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0xa
>>> CONFIG_X86_PTDUMP_CORE=y
>>> CONFIG_X86_PTDUMP=y
>>> CONFIG_KALLSYMS=y
>>> CONFIG_KALLSYMS_ALL=y
>>> CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
>>> CONFIG_KALLSYMS_BASE_RELATIVE=y
>>> CONFIG_PANIC_ON_OOPS=y
>>> CONFIG_KGDB=y
>>> CONFIG_EARLY_PRINTK=y
>>> CONFIG_EARLY_PRINTK_DBGP=y
>>> CONFIG_DEBUG_INFO=y
>>> CONFIG_DEBUG_INFO_DWARF4=y
>>
>> The config I am reproducing the bug with (on thinkpad x200s) can be found
>> at
>>
>> http://www.jikos.cz/jikos/junk/.config
>>
>> Either later today or tomorrow I could test with the same physical start
>> and align values you're using to see whether that'd make any difference.
>>
>>> > As discussed with Rafael privately, I also tried this very patch
>>> > (x86/power/64: Always create temporary identity mapping correctly) on top
>>> > of the reverted revert of 021182e52fe01c1f7b1 (see the full log below),
>>> > but such kernel triple faults on resume as well.
>>> >
>>> > 87c38d2 x86/power/64: Always create temporary identity mapping correctly
>>> > 3cb504a Revert "Revert "x86/mm: Enable KASLR for physical mapping memory 
>>> > regions""
>>> > 758850d Revert "x86/mm: Enable KASLR for physical mapping memory regions"
>>> > 4a02dfb Revert "x86/mm: Enable KASLR for vmalloc memory regions"
>>> > 037863f Revert "x86/mm: Add memory hotplug support for KASLR memory 
>>> > randomization"
>>> > 3416a21 Revert "x86/mm: Do not reference phys addr beyond kernel"
>>> > 69227be Revert "mm: reorganize SLAB freelist randomization"
>>> > a1d8d71 Revert "mm: SLUB freelist randomization"
>>> >
>>> > IOW, 021182e52f introduces a bug for which there is no existing fix yet.
>>>
>>> You mean it is something different from the previous KASLR bugs we saw?
>>
>> No, I just wanted to explicitly point out that "x86/power/64: Always
>> create temporary identity mapping correctly" is not a fix for this issue.
>
> It is better to say that the $subject patch is not sufficient to fix
> it, because I'm quite confident that it is necessary for that. :-)
>
> Without the $subject patch kernel_ident_mapping_init() makes
> assumptions that simply are not met in the randomized identity mapping
> base case.  Moreover, hibernation works for Thomas with $subject patch
> applied, but it doesn't without it.
>
> So there is something else that we are missing.
>
> I have a murky suspicion, but it is really weird.  Namely, what if
> restore_jump_address in set_up_temporary_text_mapping() happens to be
> covered by the restore kernel's identity mapping?  Then, the image
> kernel's entry point may get overwritten by something else in
> core_restore_code().
>
> But is this possible even?  Thomas?

I had a similar theory before when I was investigating the original
crash. How is it avoided even without KASLR?

Given the space for the physical memory mapping, I doubt this issue
would happen all the time though.

>
> Anyway, I'll try to reproduce this issue later today.
>
> Thanks,
> Rafael

[PATCH] NFC: pn533: constify pn533_phy_ops structures

[Julia Lawall]

The pn533_phy_ops are never modified, so declare them as const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/nfc/pn533/i2c.c   |2 +-
 drivers/nfc/pn533/pn533.c |2 +-
 drivers/nfc/pn533/pn533.h |4 ++--
 drivers/nfc/pn533/usb.c   |2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
index 1dc8924..8a7c17e 100644
--- a/drivers/nfc/pn533/i2c.c
+++ b/drivers/nfc/pn533/i2c.c
@@ -176,7 +176,7 @@ static irqreturn_t pn533_i2c_irq_thread_fn(int irq, void 
*data)
return IRQ_HANDLED;
 }
 
-static struct pn533_phy_ops i2c_phy_ops = {
+static const struct pn533_phy_ops i2c_phy_ops = {
.send_frame = pn533_i2c_send_frame,
.send_ack = pn533_i2c_send_ack,
.abort_cmd = pn533_i2c_abort_cmd,
diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
index d9c5583..2f817b3 100644
--- a/drivers/nfc/pn533/pn533.c
+++ b/drivers/nfc/pn533/pn533.c
@@ -2560,7 +2560,7 @@ struct pn533 *pn533_register_device(u32 device_type,
u32 protocols,
enum pn533_protocol_type protocol_type,
void *phy,
-   struct pn533_phy_ops *phy_ops,
+   const struct pn533_phy_ops *phy_ops,
struct pn533_frame_ops *fops,
struct device *dev,
struct device *parent)
diff --git a/drivers/nfc/pn533/pn533.h b/drivers/nfc/pn533/pn533.h
index 553c7d1..e26d634 100644
--- a/drivers/nfc/pn533/pn533.h
+++ b/drivers/nfc/pn533/pn533.h
@@ -179,7 +179,7 @@ struct pn533 {
 
struct device *dev;
void *phy;
-   struct pn533_phy_ops *phy_ops;
+   const struct pn533_phy_ops *phy_ops;
 };
 
 typedef int (*pn533_send_async_complete_t) (struct pn533 *dev, void *arg,
@@ -226,7 +226,7 @@ struct pn533 *pn533_register_device(u32 device_type,
u32 protocols,
enum pn533_protocol_type protocol_type,
void *phy,
-   struct pn533_phy_ops *phy_ops,
+   const struct pn533_phy_ops *phy_ops,
struct pn533_frame_ops *fops,
struct device *dev,
struct device *parent);
diff --git a/drivers/nfc/pn533/usb.c b/drivers/nfc/pn533/usb.c
index 33ed78b..bcf3f54 100644
--- a/drivers/nfc/pn533/usb.c
+++ b/drivers/nfc/pn533/usb.c
@@ -434,7 +434,7 @@ static void pn533_send_complete(struct urb *urb)
}
 }
 
-static struct pn533_phy_ops usb_phy_ops = {
+static const struct pn533_phy_ops usb_phy_ops = {
.send_frame = pn533_usb_send_frame,
.send_ack = pn533_usb_send_ack,
.abort_cmd = pn533_usb_abort_cmd,

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

[Thomas Garnier]

On Tue, Aug 9, 2016 at 9:18 AM, Rafael J. Wysocki  wrote:
> On Tue, Aug 9, 2016 at 5:05 PM, Jiri Kosina  wrote:
>> On Tue, 9 Aug 2016, Thomas Garnier wrote:
>>
>>> >> Okay, I did one-by-one reverts, and the one above, i.e.
>>> >>
>>> >>   commit 021182e52fe01c1f7b126f97fd6ba048dc4234fd
>>> >>   Author: Thomas Garnier 
>>> >>   Date:   Tue Jun 21 17:47:03 2016 -0700
>>> >>
>>> >>   x86/mm: Enable KASLR for physical mapping memory regions
>>> >>
>>> >> is the one that is the culprit on my machine. With this one reverted,
>>> >> resume hibernation doesn't reboot (tripple fault?), but proceeds
>>> >> succesfully.
>>>
>>> My .config is attached. It is basically defconfig (x86_64) + kvmconfig
>>> plus the following:
>>>
>>> CONFIG_PHYSICAL_START=0x100
>>> CONFIG_RELOCATABLE=y
>>> CONFIG_RANDOMIZE_BASE=y
>>> CONFIG_X86_NEED_RELOCS=y
>>> CONFIG_PHYSICAL_ALIGN=0x100
>>> CONFIG_RANDOMIZE_MEMORY=y
>>> CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0xa
>>> CONFIG_X86_PTDUMP_CORE=y
>>> CONFIG_X86_PTDUMP=y
>>> CONFIG_KALLSYMS=y
>>> CONFIG_KALLSYMS_ALL=y
>>> CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
>>> CONFIG_KALLSYMS_BASE_RELATIVE=y
>>> CONFIG_PANIC_ON_OOPS=y
>>> CONFIG_KGDB=y
>>> CONFIG_EARLY_PRINTK=y
>>> CONFIG_EARLY_PRINTK_DBGP=y
>>> CONFIG_DEBUG_INFO=y
>>> CONFIG_DEBUG_INFO_DWARF4=y
>>
>> The config I am reproducing the bug with (on thinkpad x200s) can be found
>> at
>>
>> http://www.jikos.cz/jikos/junk/.config
>>
>> Either later today or tomorrow I could test with the same physical start
>> and align values you're using to see whether that'd make any difference.
>>
>>> > As discussed with Rafael privately, I also tried this very patch
>>> > (x86/power/64: Always create temporary identity mapping correctly) on top
>>> > of the reverted revert of 021182e52fe01c1f7b1 (see the full log below),
>>> > but such kernel triple faults on resume as well.
>>> >
>>> > 87c38d2 x86/power/64: Always create temporary identity mapping correctly
>>> > 3cb504a Revert "Revert "x86/mm: Enable KASLR for physical mapping memory 
>>> > regions""
>>> > 758850d Revert "x86/mm: Enable KASLR for physical mapping memory regions"
>>> > 4a02dfb Revert "x86/mm: Enable KASLR for vmalloc memory regions"
>>> > 037863f Revert "x86/mm: Add memory hotplug support for KASLR memory 
>>> > randomization"
>>> > 3416a21 Revert "x86/mm: Do not reference phys addr beyond kernel"
>>> > 69227be Revert "mm: reorganize SLAB freelist randomization"
>>> > a1d8d71 Revert "mm: SLUB freelist randomization"
>>> >
>>> > IOW, 021182e52f introduces a bug for which there is no existing fix yet.
>>>
>>> You mean it is something different from the previous KASLR bugs we saw?
>>
>> No, I just wanted to explicitly point out that "x86/power/64: Always
>> create temporary identity mapping correctly" is not a fix for this issue.
>
> It is better to say that the $subject patch is not sufficient to fix
> it, because I'm quite confident that it is necessary for that. :-)
>
> Without the $subject patch kernel_ident_mapping_init() makes
> assumptions that simply are not met in the randomized identity mapping
> base case.  Moreover, hibernation works for Thomas with $subject patch
> applied, but it doesn't without it.
>
> So there is something else that we are missing.
>
> I have a murky suspicion, but it is really weird.  Namely, what if
> restore_jump_address in set_up_temporary_text_mapping() happens to be
> covered by the restore kernel's identity mapping?  Then, the image
> kernel's entry point may get overwritten by something else in
> core_restore_code().
>
> But is this possible even?  Thomas?

I had a similar theory before when I was investigating the original
crash. How is it avoided even without KASLR?

Given the space for the physical memory mapping, I doubt this issue
would happen all the time though.

>
> Anyway, I'll try to reproduce this issue later today.
>
> Thanks,
> Rafael

Re: [PACTH v4 1/2] usb: xhci: plat: Enable runtime PM

[kbuild test robot]

Hi Robert,

[auto build test WARNING on usb/usb-testing]
[also build test WARNING on v4.8-rc1 next-20160809]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/robert-foss-collabora-com/usb-xhci-plat-Enable-PM-async-resume-suspend/20160809-234302
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: i386-randconfig-s0-201632 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/usb/host/xhci-plat.c: In function 'xhci_plat_suspend':
>> drivers/usb/host/xhci-plat.c:303:2: warning: this 'if' clause does not 
>> guard... [-Wmisleading-indentation]
 if (ret < 0)
 ^~
   drivers/usb/host/xhci-plat.c:305:3: note: ...this statement, but the latter 
is misleadingly indented as if it is guarded by the 'if'
  return ret;
  ^~
   drivers/usb/host/xhci-plat.c: In function 'xhci_plat_resume':
   drivers/usb/host/xhci-plat.c:327:2: warning: this 'if' clause does not 
guard... [-Wmisleading-indentation]
 if (ret < 0)
 ^~
   drivers/usb/host/xhci-plat.c:329:3: note: ...this statement, but the latter 
is misleadingly indented as if it is guarded by the 'if'
  return ret;
  ^~

vim +/if +303 drivers/usb/host/xhci-plat.c

   287  
   288  if (!IS_ERR(clk))
   289  clk_disable_unprepare(clk);
   290  usb_put_hcd(hcd);
   291  
   292  return 0;
   293  }
   294  
   295  #ifdef CONFIG_PM_SLEEP
   296  static int xhci_plat_suspend(struct device *dev)
   297  {
   298  struct usb_hcd  *hcd = dev_get_drvdata(dev);
   299  struct xhci_hcd *xhci = hcd_to_xhci(hcd);
   300  int ret;
   301  
   302  ret = pm_runtime_get_sync(dev);
 > 303  if (ret < 0)
   304  atomic_dec(>power.usage_count);
   305  return ret;
   306  /*
   307   * xhci_suspend() needs `do_wakeup` to know whether host is 
allowed
   308   * to do wakeup during suspend. Since xhci_plat_suspend is 
currently
   309   * only designed for system suspend, device_may_wakeup() is 
enough
   310   * to dertermine whether host is allowed to do wakeup. Need to
   311   * reconsider this when xhci_plat_suspend enlarges its scope, 
e.g.,

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PACTH v4 1/2] usb: xhci: plat: Enable runtime PM

[kbuild test robot]

Hi Robert,

[auto build test WARNING on usb/usb-testing]
[also build test WARNING on v4.8-rc1 next-20160809]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/robert-foss-collabora-com/usb-xhci-plat-Enable-PM-async-resume-suspend/20160809-234302
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: i386-randconfig-s0-201632 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/usb/host/xhci-plat.c: In function 'xhci_plat_suspend':
>> drivers/usb/host/xhci-plat.c:303:2: warning: this 'if' clause does not 
>> guard... [-Wmisleading-indentation]
 if (ret < 0)
 ^~
   drivers/usb/host/xhci-plat.c:305:3: note: ...this statement, but the latter 
is misleadingly indented as if it is guarded by the 'if'
  return ret;
  ^~
   drivers/usb/host/xhci-plat.c: In function 'xhci_plat_resume':
   drivers/usb/host/xhci-plat.c:327:2: warning: this 'if' clause does not 
guard... [-Wmisleading-indentation]
 if (ret < 0)
 ^~
   drivers/usb/host/xhci-plat.c:329:3: note: ...this statement, but the latter 
is misleadingly indented as if it is guarded by the 'if'
  return ret;
  ^~

vim +/if +303 drivers/usb/host/xhci-plat.c

   287  
   288  if (!IS_ERR(clk))
   289  clk_disable_unprepare(clk);
   290  usb_put_hcd(hcd);
   291  
   292  return 0;
   293  }
   294  
   295  #ifdef CONFIG_PM_SLEEP
   296  static int xhci_plat_suspend(struct device *dev)
   297  {
   298  struct usb_hcd  *hcd = dev_get_drvdata(dev);
   299  struct xhci_hcd *xhci = hcd_to_xhci(hcd);
   300  int ret;
   301  
   302  ret = pm_runtime_get_sync(dev);
 > 303  if (ret < 0)
   304  atomic_dec(>power.usage_count);
   305  return ret;
   306  /*
   307   * xhci_suspend() needs `do_wakeup` to know whether host is 
allowed
   308   * to do wakeup during suspend. Since xhci_plat_suspend is 
currently
   309   * only designed for system suspend, device_may_wakeup() is 
enough
   310   * to dertermine whether host is allowed to do wakeup. Need to
   311   * reconsider this when xhci_plat_suspend enlarges its scope, 
e.g.,

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCHv4 0/2] USB Type-C Connector class

[Guenter Roeck]

On Tue, Aug 09, 2016 at 04:01:53PM +0200, Greg KH wrote:
> On Wed, Jun 29, 2016 at 04:38:36PM +0300, Heikki Krogerus wrote:
> > Hi,
> > 
> > The USB Type-C class is meant to provide unified interface to the
> > userspace to present the USB Type-C ports in a system.
> > 
> > Changes since v3:
> > - Documentation cleanup as proposed by Roger Quadros
> > - Setting partner altmodes member to NULL on removal and fixing a
> >   warning, as proposed by Guenter Roeck
> > - Added the following attributes for partners and cables:
> >   * supports_usb_power_delivery
> >   * id_header_vdo
> > - "id_header_vdo" is visible only when the partner or cable supports
> >   USB Power Delivery communication.
> > - Partner attribute "accessory" is hidden when the partner type is not
> >   "Accessory".
> > 
> > Changes since v2:
> > - Notification on role and alternate mode changes
> > - cleanups
> > 
> > Changes since v1:
> > - Completely rewrote alternate mode support
> > - Patners, cables and cable plugs presented as devices.
> 
> I'm not going to take this series until everyone agrees on it, sorry.
> I'll wait for you and Guenter and Oliver to all come up with a solution
> that works for everyone.
> 

I have not heard from Heikko for a while. There have been some follow-up
patches in

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=bxt-typec-pd-fixes

but I am not really sure where this is going. I've been wondering if I
can/should get more actively involved and start driving the series if
Heikki is busy. Thoughts, anyone ?

Guenter

Re: [PATCHv4 0/2] USB Type-C Connector class

[Guenter Roeck]

On Tue, Aug 09, 2016 at 04:01:53PM +0200, Greg KH wrote:
> On Wed, Jun 29, 2016 at 04:38:36PM +0300, Heikki Krogerus wrote:
> > Hi,
> > 
> > The USB Type-C class is meant to provide unified interface to the
> > userspace to present the USB Type-C ports in a system.
> > 
> > Changes since v3:
> > - Documentation cleanup as proposed by Roger Quadros
> > - Setting partner altmodes member to NULL on removal and fixing a
> >   warning, as proposed by Guenter Roeck
> > - Added the following attributes for partners and cables:
> >   * supports_usb_power_delivery
> >   * id_header_vdo
> > - "id_header_vdo" is visible only when the partner or cable supports
> >   USB Power Delivery communication.
> > - Partner attribute "accessory" is hidden when the partner type is not
> >   "Accessory".
> > 
> > Changes since v2:
> > - Notification on role and alternate mode changes
> > - cleanups
> > 
> > Changes since v1:
> > - Completely rewrote alternate mode support
> > - Patners, cables and cable plugs presented as devices.
> 
> I'm not going to take this series until everyone agrees on it, sorry.
> I'll wait for you and Guenter and Oliver to all come up with a solution
> that works for everyone.
> 

I have not heard from Heikko for a while. There have been some follow-up
patches in

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=bxt-typec-pd-fixes

but I am not really sure where this is going. I've been wondering if I
can/should get more actively involved and start driving the series if
Heikki is busy. Thoughts, anyone ?

Guenter

Re: [PATCH 6/8] arm64: Introduce raw_{d,i}cache_line_size

[James Morse]

Hi Suzuki,

Sorry this fell through the cracks...

On 08/07/16 12:37, Suzuki K Poulose wrote:
> On systems with mismatched i/d cache min line sizes, we need to use
> the smallest size possible across all CPUs. This will be done by fetching
> the system wide safe value from CPU feature infrastructure.
> However the some special users(e.g kexec, hibernate) would need the line
> size on the CPU (rather than the system wide), when the system wide
> feature may not be accessible. Provide another helper which will fetch
> cache line size on the current CPU.

> diff --git a/arch/arm64/include/asm/assembler.h 
> b/arch/arm64/include/asm/assembler.h
> index d5025c6..a4bb3f5 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -218,9 +218,10 @@ lr   .reqx30 // link register
>   .endm
>  
>  /*
> - * dcache_line_size - get the minimum D-cache line size from the CTR 
> register.
> + * raw_dcache_line_size - get the minimum D-cache line size on this CPU
> + * from the CTR register.
>   */
> - .macro  dcache_line_size, reg, tmp
> + .macro  raw_dcache_line_size, reg, tmp
>   mrs \tmp, ctr_el0   // read CTR
>   ubfm\tmp, \tmp, #16, #19// cache line size encoding
>   mov \reg, #4// bytes per word
> @@ -228,9 +229,17 @@ lr   .reqx30 // link register
>   .endm
>  
>  /*
> - * icache_line_size - get the minimum I-cache line size from the CTR 
> register.
> + * dcache_line_size - get the safe D-cache line size across all CPUs
>   */
> - .macro  icache_line_size, reg, tmp
> + .macro  dcache_line_size, reg, tmp
> + raw_dcache_line_size\reg, \tmp
> + .endm
> +
> +/*
> + * raw_icache_line_size - get the minimum I-cache line size on this CPU
> + * from the CTR register.
> + */
> + .macro  raw_icache_line_size, reg, tmp
>   mrs \tmp, ctr_el0   // read CTR
>   and \tmp, \tmp, #0xf// cache line size encoding
>   mov \reg, #4// bytes per word
> @@ -238,6 +247,13 @@ lr   .reqx30 // link register
>   .endm
>  
>  /*
> + * icache_line_size - get the safe I-cache line size across all CPUs
> + */
> + .macro  icache_line_size, reg, tmp
> + raw_icache_line_size\reg, \tmp
> + .endm
> +
> +/*
>   * tcr_set_idmap_t0sz - update TCR.T0SZ so that we can load the ID map
>   */
>   .macro  tcr_set_idmap_t0sz, valreg, tmpreg
> diff --git a/arch/arm64/kernel/hibernate-asm.S 
> b/arch/arm64/kernel/hibernate-asm.S
> index 46f29b6..4ebc6a1 100644
> --- a/arch/arm64/kernel/hibernate-asm.S
> +++ b/arch/arm64/kernel/hibernate-asm.S
> @@ -96,7 +96,7 @@ ENTRY(swsusp_arch_suspend_exit)
>  
>   add x1, x10, #PAGE_SIZE
>   /* Clean the copied page to PoU - based on flush_icache_range() */
> - dcache_line_size x2, x3
> + raw_dcache_line_size x2, x3
>   sub x3, x2, #1
>   bic x4, x10, x3
>  2:   dc  cvau, x4/* clean D line / unified line */


Looks like no-change to me!

If you think you need it:
Acked-by: James Morse 


Thanks,

James

Re: [PATCH 6/8] arm64: Introduce raw_{d,i}cache_line_size

[James Morse]

Hi Suzuki,

Sorry this fell through the cracks...

On 08/07/16 12:37, Suzuki K Poulose wrote:
> On systems with mismatched i/d cache min line sizes, we need to use
> the smallest size possible across all CPUs. This will be done by fetching
> the system wide safe value from CPU feature infrastructure.
> However the some special users(e.g kexec, hibernate) would need the line
> size on the CPU (rather than the system wide), when the system wide
> feature may not be accessible. Provide another helper which will fetch
> cache line size on the current CPU.

> diff --git a/arch/arm64/include/asm/assembler.h 
> b/arch/arm64/include/asm/assembler.h
> index d5025c6..a4bb3f5 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -218,9 +218,10 @@ lr   .reqx30 // link register
>   .endm
>  
>  /*
> - * dcache_line_size - get the minimum D-cache line size from the CTR 
> register.
> + * raw_dcache_line_size - get the minimum D-cache line size on this CPU
> + * from the CTR register.
>   */
> - .macro  dcache_line_size, reg, tmp
> + .macro  raw_dcache_line_size, reg, tmp
>   mrs \tmp, ctr_el0   // read CTR
>   ubfm\tmp, \tmp, #16, #19// cache line size encoding
>   mov \reg, #4// bytes per word
> @@ -228,9 +229,17 @@ lr   .reqx30 // link register
>   .endm
>  
>  /*
> - * icache_line_size - get the minimum I-cache line size from the CTR 
> register.
> + * dcache_line_size - get the safe D-cache line size across all CPUs
>   */
> - .macro  icache_line_size, reg, tmp
> + .macro  dcache_line_size, reg, tmp
> + raw_dcache_line_size\reg, \tmp
> + .endm
> +
> +/*
> + * raw_icache_line_size - get the minimum I-cache line size on this CPU
> + * from the CTR register.
> + */
> + .macro  raw_icache_line_size, reg, tmp
>   mrs \tmp, ctr_el0   // read CTR
>   and \tmp, \tmp, #0xf// cache line size encoding
>   mov \reg, #4// bytes per word
> @@ -238,6 +247,13 @@ lr   .reqx30 // link register
>   .endm
>  
>  /*
> + * icache_line_size - get the safe I-cache line size across all CPUs
> + */
> + .macro  icache_line_size, reg, tmp
> + raw_icache_line_size\reg, \tmp
> + .endm
> +
> +/*
>   * tcr_set_idmap_t0sz - update TCR.T0SZ so that we can load the ID map
>   */
>   .macro  tcr_set_idmap_t0sz, valreg, tmpreg
> diff --git a/arch/arm64/kernel/hibernate-asm.S 
> b/arch/arm64/kernel/hibernate-asm.S
> index 46f29b6..4ebc6a1 100644
> --- a/arch/arm64/kernel/hibernate-asm.S
> +++ b/arch/arm64/kernel/hibernate-asm.S
> @@ -96,7 +96,7 @@ ENTRY(swsusp_arch_suspend_exit)
>  
>   add x1, x10, #PAGE_SIZE
>   /* Clean the copied page to PoU - based on flush_icache_range() */
> - dcache_line_size x2, x3
> + raw_dcache_line_size x2, x3
>   sub x3, x2, #1
>   bic x4, x10, x3
>  2:   dc  cvau, x4/* clean D line / unified line */


Looks like no-change to me!

If you think you need it:
Acked-by: James Morse 


Thanks,

James

Re: [PATCH v3] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

[Christoph Lameter]

On Tue, 9 Aug 2016, Chris Wilson wrote:

> With debugobjects enabled and using SLAB_DESTROY_BY_RCU, when a
> kmem_cache_node is destroyed the call_rcu() may trigger a slab
> allocation to fill the debug object pool (__debug_object_init:fill_pool).
> Everywhere but during kmem_cache_destroy(), discard_slab() is performed
> outside of the kmem_cache_node->list_lock and avoids a lockdep warning
> about potential recursion:

Acked-by: Christoph Lameter 

Re: [PATCH v3] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

[Christoph Lameter]

On Tue, 9 Aug 2016, Chris Wilson wrote:

> With debugobjects enabled and using SLAB_DESTROY_BY_RCU, when a
> kmem_cache_node is destroyed the call_rcu() may trigger a slab
> allocation to fill the debug object pool (__debug_object_init:fill_pool).
> Everywhere but during kmem_cache_destroy(), discard_slab() is performed
> outside of the kmem_cache_node->list_lock and avoids a lockdep warning
> about potential recursion:

Acked-by: Christoph Lameter 

[PATCH] [media] mtk-vcodec: constify venc_common_if structures

[Julia Lawall]

The venc_common_if structures are never modified, so declare them as const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h|2 +-
 drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c |6 +++---
 drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c  |6 +++---
 drivers/media/platform/mtk-vcodec/venc_drv_if.c   |4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 94f0a42..b0cb3ed 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -240,7 +240,7 @@ struct mtk_vcodec_ctx {
enum mtk_encode_param param_change;
struct mtk_enc_params enc_params;
 
-   struct venc_common_if *enc_if;
+   const struct venc_common_if *enc_if;
unsigned long drv_handle;
 
int int_cond;
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c 
b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
index 9a60052..532cd36 100644
--- a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
@@ -664,16 +664,16 @@ static int h264_enc_deinit(unsigned long handle)
return ret;
 }
 
-static struct venc_common_if venc_h264_if = {
+static const struct venc_common_if venc_h264_if = {
h264_enc_init,
h264_enc_encode,
h264_enc_set_param,
h264_enc_deinit,
 };
 
-struct venc_common_if *get_h264_enc_comm_if(void);
+const struct venc_common_if *get_h264_enc_comm_if(void);
 
-struct venc_common_if *get_h264_enc_comm_if(void)
+const struct venc_common_if *get_h264_enc_comm_if(void)
 {
return _h264_if;
 }
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c 
b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
index 60bbcd2..bdf6780 100644
--- a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
@@ -471,16 +471,16 @@ static int vp8_enc_deinit(unsigned long handle)
return ret;
 }
 
-static struct venc_common_if venc_vp8_if = {
+static const struct venc_common_if venc_vp8_if = {
vp8_enc_init,
vp8_enc_encode,
vp8_enc_set_param,
vp8_enc_deinit,
 };
 
-struct venc_common_if *get_vp8_enc_comm_if(void);
+const struct venc_common_if *get_vp8_enc_comm_if(void);
 
-struct venc_common_if *get_vp8_enc_comm_if(void)
+const struct venc_common_if *get_vp8_enc_comm_if(void)
 {
return _vp8_if;
 }
diff --git a/drivers/media/platform/mtk-vcodec/venc_drv_if.c 
b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
index c4c83e7..d02d5f1 100644
--- a/drivers/media/platform/mtk-vcodec/venc_drv_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
@@ -26,8 +26,8 @@
 #include "mtk_vcodec_enc_pm.h"
 #include "mtk_vpu.h"
 
-struct venc_common_if *get_h264_enc_comm_if(void);
-struct venc_common_if *get_vp8_enc_comm_if(void);
+const struct venc_common_if *get_h264_enc_comm_if(void);
+const struct venc_common_if *get_vp8_enc_comm_if(void);
 
 int venc_if_init(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
 {

[PATCH] [media] mtk-vcodec: constify venc_common_if structures

[Julia Lawall]

The venc_common_if structures are never modified, so declare them as const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h|2 +-
 drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c |6 +++---
 drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c  |6 +++---
 drivers/media/platform/mtk-vcodec/venc_drv_if.c   |4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 94f0a42..b0cb3ed 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -240,7 +240,7 @@ struct mtk_vcodec_ctx {
enum mtk_encode_param param_change;
struct mtk_enc_params enc_params;
 
-   struct venc_common_if *enc_if;
+   const struct venc_common_if *enc_if;
unsigned long drv_handle;
 
int int_cond;
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c 
b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
index 9a60052..532cd36 100644
--- a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
@@ -664,16 +664,16 @@ static int h264_enc_deinit(unsigned long handle)
return ret;
 }
 
-static struct venc_common_if venc_h264_if = {
+static const struct venc_common_if venc_h264_if = {
h264_enc_init,
h264_enc_encode,
h264_enc_set_param,
h264_enc_deinit,
 };
 
-struct venc_common_if *get_h264_enc_comm_if(void);
+const struct venc_common_if *get_h264_enc_comm_if(void);
 
-struct venc_common_if *get_h264_enc_comm_if(void)
+const struct venc_common_if *get_h264_enc_comm_if(void)
 {
return _h264_if;
 }
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c 
b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
index 60bbcd2..bdf6780 100644
--- a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
@@ -471,16 +471,16 @@ static int vp8_enc_deinit(unsigned long handle)
return ret;
 }
 
-static struct venc_common_if venc_vp8_if = {
+static const struct venc_common_if venc_vp8_if = {
vp8_enc_init,
vp8_enc_encode,
vp8_enc_set_param,
vp8_enc_deinit,
 };
 
-struct venc_common_if *get_vp8_enc_comm_if(void);
+const struct venc_common_if *get_vp8_enc_comm_if(void);
 
-struct venc_common_if *get_vp8_enc_comm_if(void)
+const struct venc_common_if *get_vp8_enc_comm_if(void)
 {
return _vp8_if;
 }
diff --git a/drivers/media/platform/mtk-vcodec/venc_drv_if.c 
b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
index c4c83e7..d02d5f1 100644
--- a/drivers/media/platform/mtk-vcodec/venc_drv_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
@@ -26,8 +26,8 @@
 #include "mtk_vcodec_enc_pm.h"
 #include "mtk_vpu.h"
 
-struct venc_common_if *get_h264_enc_comm_if(void);
-struct venc_common_if *get_vp8_enc_comm_if(void);
+const struct venc_common_if *get_h264_enc_comm_if(void);
+const struct venc_common_if *get_vp8_enc_comm_if(void);
 
 int venc_if_init(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
 {

drivers/spi/spi.c:1160:3-9: preceding lock on line 1153

[Julia Lawall]

Looks worth checking.

julia

-- Forwarded message --
Date: Wed, 10 Aug 2016 00:17:07 +0800
From: kbuild test robot 
To: kbu...@01.org
Cc: Julia Lawall 
Subject: drivers/spi/spi.c:1160:3-9: preceding lock on line 1153

CC: kbuild-...@01.org
CC: linux-kernel@vger.kernel.org
TO: Mark Brown 

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   81abf2525827b29839a78fd55ab0699f033c41a5
commit: ef4d96ec4ad947360f48677b6007a4c77953b090 spi: Split bus and I/O locking
date:   2 weeks ago
:: branch date: 18 hours ago
:: commit date: 2 weeks ago

>> drivers/spi/spi.c:1160:3-9: preceding lock on line 1153

git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git remote update linus
git checkout ef4d96ec4ad947360f48677b6007a4c77953b090
vim +1160 drivers/spi/spi.c

ffbbdd213 Linus Walleij 2012-02-22  1147if (master->busy)
ffbbdd213 Linus Walleij 2012-02-22  1148was_busy = true;
ffbbdd213 Linus Walleij 2012-02-22  1149else
ffbbdd213 Linus Walleij 2012-02-22  1150master->busy = true;
ffbbdd213 Linus Walleij 2012-02-22  1151
spin_unlock_irqrestore(>queue_lock, flags);
ffbbdd213 Linus Walleij 2012-02-22  1152
ef4d96ec4 Mark Brown2016-07-21 @1153mutex_lock(>io_mutex);
ef4d96ec4 Mark Brown2016-07-21  1154
49834de23 Mark Brown2013-07-28  1155if (!was_busy && 
master->auto_runtime_pm) {
49834de23 Mark Brown2013-07-28  1156ret = 
pm_runtime_get_sync(master->dev.parent);
49834de23 Mark Brown2013-07-28  1157if (ret < 0) {
49834de23 Mark Brown2013-07-28  1158
dev_err(>dev, "Failed to power device: %d\n",
49834de23 Mark Brown2013-07-28  1159ret);
49834de23 Mark Brown2013-07-28 @1160return;
49834de23 Mark Brown2013-07-28  1161}
49834de23 Mark Brown2013-07-28  1162}
49834de23 Mark Brown2013-07-28  1163

:: The code at line 1160 was first introduced by commit
:: 49834de234f3cf592c3d242c889ca603db8e7050 spi: Provide core support for 
runtime PM during transfers

:: TO: Mark Brown 
:: CC: Mark Brown 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

drivers/spi/spi.c:1160:3-9: preceding lock on line 1153

[Julia Lawall]

Looks worth checking.

julia

-- Forwarded message --
Date: Wed, 10 Aug 2016 00:17:07 +0800
From: kbuild test robot 
To: kbu...@01.org
Cc: Julia Lawall 
Subject: drivers/spi/spi.c:1160:3-9: preceding lock on line 1153

CC: kbuild-...@01.org
CC: linux-kernel@vger.kernel.org
TO: Mark Brown 

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   81abf2525827b29839a78fd55ab0699f033c41a5
commit: ef4d96ec4ad947360f48677b6007a4c77953b090 spi: Split bus and I/O locking
date:   2 weeks ago
:: branch date: 18 hours ago
:: commit date: 2 weeks ago

>> drivers/spi/spi.c:1160:3-9: preceding lock on line 1153

git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git remote update linus
git checkout ef4d96ec4ad947360f48677b6007a4c77953b090
vim +1160 drivers/spi/spi.c

ffbbdd213 Linus Walleij 2012-02-22  1147if (master->busy)
ffbbdd213 Linus Walleij 2012-02-22  1148was_busy = true;
ffbbdd213 Linus Walleij 2012-02-22  1149else
ffbbdd213 Linus Walleij 2012-02-22  1150master->busy = true;
ffbbdd213 Linus Walleij 2012-02-22  1151
spin_unlock_irqrestore(>queue_lock, flags);
ffbbdd213 Linus Walleij 2012-02-22  1152
ef4d96ec4 Mark Brown2016-07-21 @1153mutex_lock(>io_mutex);
ef4d96ec4 Mark Brown2016-07-21  1154
49834de23 Mark Brown2013-07-28  1155if (!was_busy && 
master->auto_runtime_pm) {
49834de23 Mark Brown2013-07-28  1156ret = 
pm_runtime_get_sync(master->dev.parent);
49834de23 Mark Brown2013-07-28  1157if (ret < 0) {
49834de23 Mark Brown2013-07-28  1158
dev_err(>dev, "Failed to power device: %d\n",
49834de23 Mark Brown2013-07-28  1159ret);
49834de23 Mark Brown2013-07-28 @1160return;
49834de23 Mark Brown2013-07-28  1161}
49834de23 Mark Brown2013-07-28  1162}
49834de23 Mark Brown2013-07-28  1163

:: The code at line 1160 was first introduced by commit
:: 49834de234f3cf592c3d242c889ca603db8e7050 spi: Provide core support for 
runtime PM during transfers

:: TO: Mark Brown 
:: CC: Mark Brown 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH 4.6 00/96] 4.6.6-stable review

[Guenter Roeck]

On Tue, Aug 09, 2016 at 10:37:31AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Aug 09, 2016 at 09:33:26AM +0100, Paul Burton wrote:
> > On 09/08/16 09:24, Greg Kroah-Hartman wrote:
> > > On Mon, Aug 08, 2016 at 10:03:39PM -0700, Guenter Roeck wrote:
> > > > On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote:
> > > > > This is the start of the stable review cycle for the 4.6.6 release.
> > > > > There are 96 patches in this series, all will be posted as a response
> > > > > to this one.  If anyone has any issues with these being applied, 
> > > > > please
> > > > > let me know.
> > > > > 
> > > > > Responses should be made by Wed Aug 10 18:02:27 UTC 2016.
> > > > > Anything received after that time might be too late.
> > > > > 
> > > > 
> > > > Build results:
> > > > total: 148 pass: 146 fail: 2
> > > > Failed builds:
> > > > unicore32:defconfig
> > > > unicore32:allnoconfig
> > > > 
> > > > Qemu test results:
> > > > total: 107 pass: 103 fail: 4
> > > > Failed tests:
> > > > mips:malta_defconfig:nosmp
> > > > mips64:malta_defconfig:nosmp
> > > > mipsel:malta_defconfig:nosmp
> > > > mipsel64:malta_defconfig:nosmp
> > > > 
> > > > The unicore32 build error is still not fixed in mainline.
> > > > 
> > > > mips:
> > > > 
> > > > Building mips:malta_defconfig:nosmp ... failed
> > > > 
> > > > Error log:
> > > > drivers/built-in.o: In function `gic_shared_irq_domain_map.isra.0':
> > > > irq-mips-gic.c:(.text+0x1d58): undefined reference to `smp_num_siblings'
> > > > irq-mips-gic.c:(.text+0x1d5c): undefined reference to `smp_num_siblings'
> > > > irq-mips-gic.c:(.text+0x1de0): undefined reference to `smp_num_siblings'
> > > > irq-mips-gic.c:(.text+0x1de8): undefined reference to `smp_num_siblings'
> > > > 
> > > > Only seen with non-SMP builds. Tricky one, required bisect.
> > > > 
> > > > # bad: [0353fa20cb40ea75a7e3b7293b533bde4fa013e9] Linux 4.6.6-rc1
> > > > # good: [bed4c611a3b80fae04d75b9f85fcaf174bac1b06] Linux 4.6.5
> > > > git bisect start 'HEAD' 'v4.6.5'
> > > > # good: [8d3b41c18cff2db7ccea71243b945a33610b8cb5] cgroup: remove 
> > > > redundant cleanup in css_create
> > > > git bisect good 
> > > > 8d3b41c18cff2db7ccea71243b945a33610b8cb583c9f9e994f5c963fc652a52befc120699dcc591
> > > > # good: [3a255979bc75ffcc263928045df4b5f46df8a8ca] sched/fair: Fix 
> > > > effective_load() to consistently use smoothed load
> > > > git bisect good 3a255979bc75ffcc263928045df4b5f46df8a8ca
> > > > # bad: [6eafb1f777de375b52c8a83d262da2885a28579a] posix_cpu_timer: Exit 
> > > > early when process has been reaped
> > > > git bisect bad 6eafb1f777de375b52c8a83d262da2885a28579a
> > > > # bad: [83c9f9e994f5c963fc652a52befc120699dcc591] irqchip/mips-gic: Map 
> > > > to VPs using HW VPNum
> > > > git bisect bad 83c9f9e994f5c963fc652a52befc120699dcc591
> > > > # good: [3a1e9944db1570f9b654b7a187f13898e5c59529] can: fix handling of 
> > > > unmodifiable configuration options fix
> > > > git bisect good 3a1e9944db1570f9b654b7a187f13898e5c59529
> > > > # good: [f06b9b8071ae6e383931795e2a459d6abc0bc7bd] RDS: fix 
> > > > rds_tcp_init() error path
> > > > git bisect good f06b9b8071ae6e383931795e2a459d6abc0bc7bd
> > > > # first bad commit: [83c9f9e994f5c963fc652a52befc120699dcc591] 
> > > > irqchip/mips-gic: Map to VPs using HW VPNum
> > > > 
> > > > Reverting 83c9f9e994f5c963fc652a52befc120699dcc591 fixes the problem.
> > > > Its description suggests that it fixes a real bug, though, so copying 
> > > > Paul for input.
> > > 
> > > Thanks for the bisection and report.
> > > 
> > > Paul, any ideas?  Why doesn't this also fail in 4.7?
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > > 
> > 
> > Hi Greg, Guenter,
> > 
> > The easiest way to fix this is likely to backport a60ae81e5e59 ("MIPS: CM:
> > Fix mips_cm_max_vp_width for UP kernels") which went into mainline in the
> > 4.7 cycle. Apologies for overlooking the need for that one in stable.
> 
> No problem, now added to the 4.6 queue, thanks.
> 
Can you push it into the -rc repository ? I see the patch in the queue,
but not in the repository.

Thanks,
Guenter

Re: [PATCH 4.6 00/96] 4.6.6-stable review

[Guenter Roeck]

On Tue, Aug 09, 2016 at 10:37:31AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Aug 09, 2016 at 09:33:26AM +0100, Paul Burton wrote:
> > On 09/08/16 09:24, Greg Kroah-Hartman wrote:
> > > On Mon, Aug 08, 2016 at 10:03:39PM -0700, Guenter Roeck wrote:
> > > > On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote:
> > > > > This is the start of the stable review cycle for the 4.6.6 release.
> > > > > There are 96 patches in this series, all will be posted as a response
> > > > > to this one.  If anyone has any issues with these being applied, 
> > > > > please
> > > > > let me know.
> > > > > 
> > > > > Responses should be made by Wed Aug 10 18:02:27 UTC 2016.
> > > > > Anything received after that time might be too late.
> > > > > 
> > > > 
> > > > Build results:
> > > > total: 148 pass: 146 fail: 2
> > > > Failed builds:
> > > > unicore32:defconfig
> > > > unicore32:allnoconfig
> > > > 
> > > > Qemu test results:
> > > > total: 107 pass: 103 fail: 4
> > > > Failed tests:
> > > > mips:malta_defconfig:nosmp
> > > > mips64:malta_defconfig:nosmp
> > > > mipsel:malta_defconfig:nosmp
> > > > mipsel64:malta_defconfig:nosmp
> > > > 
> > > > The unicore32 build error is still not fixed in mainline.
> > > > 
> > > > mips:
> > > > 
> > > > Building mips:malta_defconfig:nosmp ... failed
> > > > 
> > > > Error log:
> > > > drivers/built-in.o: In function `gic_shared_irq_domain_map.isra.0':
> > > > irq-mips-gic.c:(.text+0x1d58): undefined reference to `smp_num_siblings'
> > > > irq-mips-gic.c:(.text+0x1d5c): undefined reference to `smp_num_siblings'
> > > > irq-mips-gic.c:(.text+0x1de0): undefined reference to `smp_num_siblings'
> > > > irq-mips-gic.c:(.text+0x1de8): undefined reference to `smp_num_siblings'
> > > > 
> > > > Only seen with non-SMP builds. Tricky one, required bisect.
> > > > 
> > > > # bad: [0353fa20cb40ea75a7e3b7293b533bde4fa013e9] Linux 4.6.6-rc1
> > > > # good: [bed4c611a3b80fae04d75b9f85fcaf174bac1b06] Linux 4.6.5
> > > > git bisect start 'HEAD' 'v4.6.5'
> > > > # good: [8d3b41c18cff2db7ccea71243b945a33610b8cb5] cgroup: remove 
> > > > redundant cleanup in css_create
> > > > git bisect good 
> > > > 8d3b41c18cff2db7ccea71243b945a33610b8cb583c9f9e994f5c963fc652a52befc120699dcc591
> > > > # good: [3a255979bc75ffcc263928045df4b5f46df8a8ca] sched/fair: Fix 
> > > > effective_load() to consistently use smoothed load
> > > > git bisect good 3a255979bc75ffcc263928045df4b5f46df8a8ca
> > > > # bad: [6eafb1f777de375b52c8a83d262da2885a28579a] posix_cpu_timer: Exit 
> > > > early when process has been reaped
> > > > git bisect bad 6eafb1f777de375b52c8a83d262da2885a28579a
> > > > # bad: [83c9f9e994f5c963fc652a52befc120699dcc591] irqchip/mips-gic: Map 
> > > > to VPs using HW VPNum
> > > > git bisect bad 83c9f9e994f5c963fc652a52befc120699dcc591
> > > > # good: [3a1e9944db1570f9b654b7a187f13898e5c59529] can: fix handling of 
> > > > unmodifiable configuration options fix
> > > > git bisect good 3a1e9944db1570f9b654b7a187f13898e5c59529
> > > > # good: [f06b9b8071ae6e383931795e2a459d6abc0bc7bd] RDS: fix 
> > > > rds_tcp_init() error path
> > > > git bisect good f06b9b8071ae6e383931795e2a459d6abc0bc7bd
> > > > # first bad commit: [83c9f9e994f5c963fc652a52befc120699dcc591] 
> > > > irqchip/mips-gic: Map to VPs using HW VPNum
> > > > 
> > > > Reverting 83c9f9e994f5c963fc652a52befc120699dcc591 fixes the problem.
> > > > Its description suggests that it fixes a real bug, though, so copying 
> > > > Paul for input.
> > > 
> > > Thanks for the bisection and report.
> > > 
> > > Paul, any ideas?  Why doesn't this also fail in 4.7?
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > > 
> > 
> > Hi Greg, Guenter,
> > 
> > The easiest way to fix this is likely to backport a60ae81e5e59 ("MIPS: CM:
> > Fix mips_cm_max_vp_width for UP kernels") which went into mainline in the
> > 4.7 cycle. Apologies for overlooking the need for that one in stable.
> 
> No problem, now added to the 4.6 queue, thanks.
> 
Can you push it into the -rc repository ? I see the patch in the queue,
but not in the repository.

Thanks,
Guenter

RE: [v11,3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

Hi Loic,

> -Original Message-
> From: Loic Poulain [mailto:loic.poul...@intel.com]
> Sent: Thursday, June 30, 2016 4:24 PM
> To: Amitkumar Karwar; Jeffy Chen; linux-blueto...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat; Cathy Luo; Marcel
> Holtmann
> Subject: Re: [v11,3/3] Bluetooth: hci_uart: Support firmware download
> for Marvell
> 
> Hi Amitkumar,
> 
> 
> > Hi Marcel,
> 
> I suggest you to add Marcel as recipient of your patches.
> 
> >
> >> From: Jeffy Chen [mailto:jeffy.c...@rock-chips.com]
> >> Sent: Friday, June 24, 2016 11:32 AM
> >> To: Amitkumar Karwar; linux-blueto...@vger.kernel.org
> >> Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat
> >> Subject: Re: [v11,3/3] Bluetooth: hci_uart: Support firmware download
> >> for Marvell
> >>
> >> On 2016-5-6 23:31, Amitkumar Karwar wrote:
> >>> From: Ganapathi Bhat 
> >>>
> >>> This patch implement firmware download feature for Marvell Bluetooth
> >>> devices. If firmware is already downloaded, it will skip
> downloading.
> 
> 
> >>> +static struct sk_buff *mrvl_process_fw_data(struct hci_uart *hu,
> >>> + struct sk_buff *skb,
> >>> + u8 *buf, int count)
> >>> +{
> >>> + struct mrvl_data *mrvl = hu->priv;
> >>> + struct fw_data *fw_data = mrvl->fwdata;
> >>> + int i = 0, len;
> >>> +
> >>> + if (!skb) {
> >>> + while (buf[i] != fw_data->expected_ack && i < count)
> >>> + i++;
> >>> + if (i == count)
> >>> + return ERR_PTR(-EILSEQ);
> >>> +
> >>> + skb = bt_skb_alloc(MRVL_FW_HDR_LEN, GFP_KERNEL);
> 
> Why you don't test skb here.
> 
> >>> + }
> >>> +
> >>> + if (!skb)
> >>> + return ERR_PTR(-ENOMEM);
> >>> +
> >>> + len = count - i;
> >>> + memcpy(skb_put(skb, len), [i], len);
> 
> You copy all the remaining data from buf into your skb, but what if buf
> contains more than one packet ? out of skb.
> Don't assume that buf contains a full packet as well as only one packet.
> 
> 

Thanks for your comments. We have added necessarily checks to address these 
comments. I will submit updated version shortly.

Regards,
Amitkumar Karwar

RE: [v11,3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

Hi Loic,

> -Original Message-
> From: Loic Poulain [mailto:loic.poul...@intel.com]
> Sent: Thursday, June 30, 2016 4:24 PM
> To: Amitkumar Karwar; Jeffy Chen; linux-blueto...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat; Cathy Luo; Marcel
> Holtmann
> Subject: Re: [v11,3/3] Bluetooth: hci_uart: Support firmware download
> for Marvell
> 
> Hi Amitkumar,
> 
> 
> > Hi Marcel,
> 
> I suggest you to add Marcel as recipient of your patches.
> 
> >
> >> From: Jeffy Chen [mailto:jeffy.c...@rock-chips.com]
> >> Sent: Friday, June 24, 2016 11:32 AM
> >> To: Amitkumar Karwar; linux-blueto...@vger.kernel.org
> >> Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat
> >> Subject: Re: [v11,3/3] Bluetooth: hci_uart: Support firmware download
> >> for Marvell
> >>
> >> On 2016-5-6 23:31, Amitkumar Karwar wrote:
> >>> From: Ganapathi Bhat 
> >>>
> >>> This patch implement firmware download feature for Marvell Bluetooth
> >>> devices. If firmware is already downloaded, it will skip
> downloading.
> 
> 
> >>> +static struct sk_buff *mrvl_process_fw_data(struct hci_uart *hu,
> >>> + struct sk_buff *skb,
> >>> + u8 *buf, int count)
> >>> +{
> >>> + struct mrvl_data *mrvl = hu->priv;
> >>> + struct fw_data *fw_data = mrvl->fwdata;
> >>> + int i = 0, len;
> >>> +
> >>> + if (!skb) {
> >>> + while (buf[i] != fw_data->expected_ack && i < count)
> >>> + i++;
> >>> + if (i == count)
> >>> + return ERR_PTR(-EILSEQ);
> >>> +
> >>> + skb = bt_skb_alloc(MRVL_FW_HDR_LEN, GFP_KERNEL);
> 
> Why you don't test skb here.
> 
> >>> + }
> >>> +
> >>> + if (!skb)
> >>> + return ERR_PTR(-ENOMEM);
> >>> +
> >>> + len = count - i;
> >>> + memcpy(skb_put(skb, len), [i], len);
> 
> You copy all the remaining data from buf into your skb, but what if buf
> contains more than one packet ? out of skb.
> Don't assume that buf contains a full packet as well as only one packet.
> 
> 

Thanks for your comments. We have added necessarily checks to address these 
comments. I will submit updated version shortly.

Regards,
Amitkumar Karwar

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

[Rafael J. Wysocki]

On Tue, Aug 9, 2016 at 5:05 PM, Jiri Kosina  wrote:
> On Tue, 9 Aug 2016, Thomas Garnier wrote:
>
>> >> Okay, I did one-by-one reverts, and the one above, i.e.
>> >>
>> >>   commit 021182e52fe01c1f7b126f97fd6ba048dc4234fd
>> >>   Author: Thomas Garnier 
>> >>   Date:   Tue Jun 21 17:47:03 2016 -0700
>> >>
>> >>   x86/mm: Enable KASLR for physical mapping memory regions
>> >>
>> >> is the one that is the culprit on my machine. With this one reverted,
>> >> resume hibernation doesn't reboot (tripple fault?), but proceeds
>> >> succesfully.
>>
>> My .config is attached. It is basically defconfig (x86_64) + kvmconfig
>> plus the following:
>>
>> CONFIG_PHYSICAL_START=0x100
>> CONFIG_RELOCATABLE=y
>> CONFIG_RANDOMIZE_BASE=y
>> CONFIG_X86_NEED_RELOCS=y
>> CONFIG_PHYSICAL_ALIGN=0x100
>> CONFIG_RANDOMIZE_MEMORY=y
>> CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0xa
>> CONFIG_X86_PTDUMP_CORE=y
>> CONFIG_X86_PTDUMP=y
>> CONFIG_KALLSYMS=y
>> CONFIG_KALLSYMS_ALL=y
>> CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
>> CONFIG_KALLSYMS_BASE_RELATIVE=y
>> CONFIG_PANIC_ON_OOPS=y
>> CONFIG_KGDB=y
>> CONFIG_EARLY_PRINTK=y
>> CONFIG_EARLY_PRINTK_DBGP=y
>> CONFIG_DEBUG_INFO=y
>> CONFIG_DEBUG_INFO_DWARF4=y
>
> The config I am reproducing the bug with (on thinkpad x200s) can be found
> at
>
> http://www.jikos.cz/jikos/junk/.config
>
> Either later today or tomorrow I could test with the same physical start
> and align values you're using to see whether that'd make any difference.
>
>> > As discussed with Rafael privately, I also tried this very patch
>> > (x86/power/64: Always create temporary identity mapping correctly) on top
>> > of the reverted revert of 021182e52fe01c1f7b1 (see the full log below),
>> > but such kernel triple faults on resume as well.
>> >
>> > 87c38d2 x86/power/64: Always create temporary identity mapping correctly
>> > 3cb504a Revert "Revert "x86/mm: Enable KASLR for physical mapping memory 
>> > regions""
>> > 758850d Revert "x86/mm: Enable KASLR for physical mapping memory regions"
>> > 4a02dfb Revert "x86/mm: Enable KASLR for vmalloc memory regions"
>> > 037863f Revert "x86/mm: Add memory hotplug support for KASLR memory 
>> > randomization"
>> > 3416a21 Revert "x86/mm: Do not reference phys addr beyond kernel"
>> > 69227be Revert "mm: reorganize SLAB freelist randomization"
>> > a1d8d71 Revert "mm: SLUB freelist randomization"
>> >
>> > IOW, 021182e52f introduces a bug for which there is no existing fix yet.
>>
>> You mean it is something different from the previous KASLR bugs we saw?
>
> No, I just wanted to explicitly point out that "x86/power/64: Always
> create temporary identity mapping correctly" is not a fix for this issue.

It is better to say that the $subject patch is not sufficient to fix
it, because I'm quite confident that it is necessary for that. :-)

Without the $subject patch kernel_ident_mapping_init() makes
assumptions that simply are not met in the randomized identity mapping
base case.  Moreover, hibernation works for Thomas with $subject patch
applied, but it doesn't without it.

So there is something else that we are missing.

I have a murky suspicion, but it is really weird.  Namely, what if
restore_jump_address in set_up_temporary_text_mapping() happens to be
covered by the restore kernel's identity mapping?  Then, the image
kernel's entry point may get overwritten by something else in
core_restore_code().

But is this possible even?  Thomas?

Anyway, I'll try to reproduce this issue later today.

Thanks,
Rafael

[RFC] mm: Don't use radix tree writeback tags for pages in swap cache

[Huang, Ying]

From: Huang Ying 

File pages uses a set of radix tags (DIRTY, TOWRITE, WRITEBACK) to
accelerate finding the pages with the specific tag in the the radix tree
during writing back an inode.  But for anonymous pages in swap cache,
there are no inode based writeback.  So there is no need to find the
pages with some writeback tags in the radix tree.  It is no necessary to
touch radix tree writeback tags for pages in swap cache.

With this patch, the swap out bandwidth improved 22.3% in vm-scalability
swap-w-seq test case with 8 processes on a Xeon E5 v3 system, because of
reduced contention on swap cache radix tree lock.  To test sequence swap
out, the test case uses 8 processes sequentially allocate and write to
anonymous pages until RAM and part of the swap device is used up.

Details of comparison is as follow,

base base+patch
 --
 \  |\
   2506952 ±  2% +28.1%3212076 ±  7%  vm-scalability.throughput
   1207402 ±  7% +22.3%1476578 ±  6%  vmstat.swap.so
 10.86 ± 12% -23.4%   8.31 ± 16%  
perf-profile.cycles-pp._raw_spin_lock_irq.__add_to_swap_cache.add_to_swap_cache.add_to_swap.shrink_page_list
 10.82 ± 13% -33.1%   7.24 ± 14%  
perf-profile.cycles-pp._raw_spin_lock_irqsave.__remove_mapping.shrink_page_list.shrink_inactive_list.shrink_zone_memcg
 10.36 ± 11%-100.0%   0.00 ± -1%  
perf-profile.cycles-pp._raw_spin_lock_irqsave.__test_set_page_writeback.bdev_write_page.__swap_writepage.swap_writepage
 10.52 ± 12%-100.0%   0.00 ± -1%  
perf-profile.cycles-pp._raw_spin_lock_irqsave.test_clear_page_writeback.end_page_writeback.page_endio.pmem_rw_page

Cc: Hugh Dickins 
Cc: Shaohua Li 
Cc: Minchan Kim 
Cc: Rik van Riel 
Cc: Mel Gorman 
Cc: Tejun Heo 
Cc: Wu Fengguang 
Signed-off-by: "Huang, Ying" 
---
 mm/page-writeback.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index f4cd7d8..ebfecb7 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2758,7 +2758,7 @@ int test_clear_page_writeback(struct page *page)
int ret;
 
lock_page_memcg(page);
-   if (mapping) {
+   if (mapping && !PageSwapCache(page)) {
struct inode *inode = mapping->host;
struct backing_dev_info *bdi = inode_to_bdi(inode);
unsigned long flags;
@@ -2801,7 +2801,7 @@ int __test_set_page_writeback(struct page *page, bool 
keep_write)
int ret;
 
lock_page_memcg(page);
-   if (mapping) {
+   if (mapping && !PageSwapCache(page)) {
struct inode *inode = mapping->host;
struct backing_dev_info *bdi = inode_to_bdi(inode);
unsigned long flags;
-- 
2.8.1

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

[Rafael J. Wysocki]

On Tue, Aug 9, 2016 at 5:05 PM, Jiri Kosina  wrote:
> On Tue, 9 Aug 2016, Thomas Garnier wrote:
>
>> >> Okay, I did one-by-one reverts, and the one above, i.e.
>> >>
>> >>   commit 021182e52fe01c1f7b126f97fd6ba048dc4234fd
>> >>   Author: Thomas Garnier 
>> >>   Date:   Tue Jun 21 17:47:03 2016 -0700
>> >>
>> >>   x86/mm: Enable KASLR for physical mapping memory regions
>> >>
>> >> is the one that is the culprit on my machine. With this one reverted,
>> >> resume hibernation doesn't reboot (tripple fault?), but proceeds
>> >> succesfully.
>>
>> My .config is attached. It is basically defconfig (x86_64) + kvmconfig
>> plus the following:
>>
>> CONFIG_PHYSICAL_START=0x100
>> CONFIG_RELOCATABLE=y
>> CONFIG_RANDOMIZE_BASE=y
>> CONFIG_X86_NEED_RELOCS=y
>> CONFIG_PHYSICAL_ALIGN=0x100
>> CONFIG_RANDOMIZE_MEMORY=y
>> CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0xa
>> CONFIG_X86_PTDUMP_CORE=y
>> CONFIG_X86_PTDUMP=y
>> CONFIG_KALLSYMS=y
>> CONFIG_KALLSYMS_ALL=y
>> CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
>> CONFIG_KALLSYMS_BASE_RELATIVE=y
>> CONFIG_PANIC_ON_OOPS=y
>> CONFIG_KGDB=y
>> CONFIG_EARLY_PRINTK=y
>> CONFIG_EARLY_PRINTK_DBGP=y
>> CONFIG_DEBUG_INFO=y
>> CONFIG_DEBUG_INFO_DWARF4=y
>
> The config I am reproducing the bug with (on thinkpad x200s) can be found
> at
>
> http://www.jikos.cz/jikos/junk/.config
>
> Either later today or tomorrow I could test with the same physical start
> and align values you're using to see whether that'd make any difference.
>
>> > As discussed with Rafael privately, I also tried this very patch
>> > (x86/power/64: Always create temporary identity mapping correctly) on top
>> > of the reverted revert of 021182e52fe01c1f7b1 (see the full log below),
>> > but such kernel triple faults on resume as well.
>> >
>> > 87c38d2 x86/power/64: Always create temporary identity mapping correctly
>> > 3cb504a Revert "Revert "x86/mm: Enable KASLR for physical mapping memory 
>> > regions""
>> > 758850d Revert "x86/mm: Enable KASLR for physical mapping memory regions"
>> > 4a02dfb Revert "x86/mm: Enable KASLR for vmalloc memory regions"
>> > 037863f Revert "x86/mm: Add memory hotplug support for KASLR memory 
>> > randomization"
>> > 3416a21 Revert "x86/mm: Do not reference phys addr beyond kernel"
>> > 69227be Revert "mm: reorganize SLAB freelist randomization"
>> > a1d8d71 Revert "mm: SLUB freelist randomization"
>> >
>> > IOW, 021182e52f introduces a bug for which there is no existing fix yet.
>>
>> You mean it is something different from the previous KASLR bugs we saw?
>
> No, I just wanted to explicitly point out that "x86/power/64: Always
> create temporary identity mapping correctly" is not a fix for this issue.

It is better to say that the $subject patch is not sufficient to fix
it, because I'm quite confident that it is necessary for that. :-)

Without the $subject patch kernel_ident_mapping_init() makes
assumptions that simply are not met in the randomized identity mapping
base case.  Moreover, hibernation works for Thomas with $subject patch
applied, but it doesn't without it.

So there is something else that we are missing.

I have a murky suspicion, but it is really weird.  Namely, what if
restore_jump_address in set_up_temporary_text_mapping() happens to be
covered by the restore kernel's identity mapping?  Then, the image
kernel's entry point may get overwritten by something else in
core_restore_code().

But is this possible even?  Thomas?

Anyway, I'll try to reproduce this issue later today.

Thanks,
Rafael

[RFC] mm: Don't use radix tree writeback tags for pages in swap cache

[Huang, Ying]

From: Huang Ying 

File pages uses a set of radix tags (DIRTY, TOWRITE, WRITEBACK) to
accelerate finding the pages with the specific tag in the the radix tree
during writing back an inode.  But for anonymous pages in swap cache,
there are no inode based writeback.  So there is no need to find the
pages with some writeback tags in the radix tree.  It is no necessary to
touch radix tree writeback tags for pages in swap cache.

With this patch, the swap out bandwidth improved 22.3% in vm-scalability
swap-w-seq test case with 8 processes on a Xeon E5 v3 system, because of
reduced contention on swap cache radix tree lock.  To test sequence swap
out, the test case uses 8 processes sequentially allocate and write to
anonymous pages until RAM and part of the swap device is used up.

Details of comparison is as follow,

base base+patch
 --
 \  |\
   2506952 ±  2% +28.1%3212076 ±  7%  vm-scalability.throughput
   1207402 ±  7% +22.3%1476578 ±  6%  vmstat.swap.so
 10.86 ± 12% -23.4%   8.31 ± 16%  
perf-profile.cycles-pp._raw_spin_lock_irq.__add_to_swap_cache.add_to_swap_cache.add_to_swap.shrink_page_list
 10.82 ± 13% -33.1%   7.24 ± 14%  
perf-profile.cycles-pp._raw_spin_lock_irqsave.__remove_mapping.shrink_page_list.shrink_inactive_list.shrink_zone_memcg
 10.36 ± 11%-100.0%   0.00 ± -1%  
perf-profile.cycles-pp._raw_spin_lock_irqsave.__test_set_page_writeback.bdev_write_page.__swap_writepage.swap_writepage
 10.52 ± 12%-100.0%   0.00 ± -1%  
perf-profile.cycles-pp._raw_spin_lock_irqsave.test_clear_page_writeback.end_page_writeback.page_endio.pmem_rw_page

Cc: Hugh Dickins 
Cc: Shaohua Li 
Cc: Minchan Kim 
Cc: Rik van Riel 
Cc: Mel Gorman 
Cc: Tejun Heo 
Cc: Wu Fengguang 
Signed-off-by: "Huang, Ying" 
---
 mm/page-writeback.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index f4cd7d8..ebfecb7 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2758,7 +2758,7 @@ int test_clear_page_writeback(struct page *page)
int ret;
 
lock_page_memcg(page);
-   if (mapping) {
+   if (mapping && !PageSwapCache(page)) {
struct inode *inode = mapping->host;
struct backing_dev_info *bdi = inode_to_bdi(inode);
unsigned long flags;
@@ -2801,7 +2801,7 @@ int __test_set_page_writeback(struct page *page, bool 
keep_write)
int ret;
 
lock_page_memcg(page);
-   if (mapping) {
+   if (mapping && !PageSwapCache(page)) {
struct inode *inode = mapping->host;
struct backing_dev_info *bdi = inode_to_bdi(inode);
unsigned long flags;
-- 
2.8.1

Re: linux-next: please clean up the samsung-krzk tree

[Krzysztof Kozlowski]

On Tue, Aug 09, 2016 at 09:55:05AM +1000, Stephen Rothwell wrote:
> Hi Krzysztof,
> 
> The samsung-krzk tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git#for-next)
> contains just these:
> 
> 253256f64294 Merge branch 'next/soc' into for-next
> b148ebe425aa Merge branch 'next/defconfig64' into for-next
> d11d19d93a01 Merge branch 'next/defconfig64' into for-next
> cc8b7edeaeff Merge branch 'next/drivers' into for-next
> 33d1679aeebb Merge branch 'next/dt64' into for-next
> c239aef8ed5c Merge branch 'fixes' into for-next
> 45338b4af16f Merge branch 'next/drivers' into for-next
> 42628e196937 Merge branch 'next/soc' into for-next
> 336361e2749d arm64: dts: Fix RTC by providing rtc_src clock
> 13fc4c900141 Merge branch 'for-v4.8/exynos-mfc' into for-next
> c210c51020f2 Merge branch 'for-v4.8/dts-exynos5410-odroid-xu' into for-next
> 976b260e2989 Merge branch 'fixes-dt' into for-next
> 279b6fdc5751 Merge branch 'next/defconfig' into for-next
> 42ba6ffaa300 Merge branch 'next/dt' into for-next
> 9f1bc73cb9b2 Merge branch 'next/drivers' into for-next
> a8c1aef0a08b Merge branch 'next/soc64' into for-next
> c39705ddcc6e Merge branch 'next/soc' into for-next
> 63b9ef3830d1 Merge branch 'fixes' into for-next
> 
> and is causing a conflict with mailline.  Please clean it up.

Indeed there was a conflict comming from different merge-conflict
resolution between me and arm-soc (which pulls my stuff). Fixed. Sorry
for the trouble.

However the changelog above is mostly correct. This is a common pattern for
arm-soc related repositories. All work is expected to be done in
separate branches so for-next often looks like this.

Best regards,
Krzysztof

Re: linux-next: please clean up the samsung-krzk tree

[Krzysztof Kozlowski]

On Tue, Aug 09, 2016 at 09:55:05AM +1000, Stephen Rothwell wrote:
> Hi Krzysztof,
> 
> The samsung-krzk tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git#for-next)
> contains just these:
> 
> 253256f64294 Merge branch 'next/soc' into for-next
> b148ebe425aa Merge branch 'next/defconfig64' into for-next
> d11d19d93a01 Merge branch 'next/defconfig64' into for-next
> cc8b7edeaeff Merge branch 'next/drivers' into for-next
> 33d1679aeebb Merge branch 'next/dt64' into for-next
> c239aef8ed5c Merge branch 'fixes' into for-next
> 45338b4af16f Merge branch 'next/drivers' into for-next
> 42628e196937 Merge branch 'next/soc' into for-next
> 336361e2749d arm64: dts: Fix RTC by providing rtc_src clock
> 13fc4c900141 Merge branch 'for-v4.8/exynos-mfc' into for-next
> c210c51020f2 Merge branch 'for-v4.8/dts-exynos5410-odroid-xu' into for-next
> 976b260e2989 Merge branch 'fixes-dt' into for-next
> 279b6fdc5751 Merge branch 'next/defconfig' into for-next
> 42ba6ffaa300 Merge branch 'next/dt' into for-next
> 9f1bc73cb9b2 Merge branch 'next/drivers' into for-next
> a8c1aef0a08b Merge branch 'next/soc64' into for-next
> c39705ddcc6e Merge branch 'next/soc' into for-next
> 63b9ef3830d1 Merge branch 'fixes' into for-next
> 
> and is causing a conflict with mailline.  Please clean it up.

Indeed there was a conflict comming from different merge-conflict
resolution between me and arm-soc (which pulls my stuff). Fixed. Sorry
for the trouble.

However the changelog above is mostly correct. This is a common pattern for
arm-soc related repositories. All work is expected to be done in
separate branches so for-next often looks like this.

Best regards,
Krzysztof

Re: [PATCH] i2c: don't print error when adding adapter fails

[Ray Jui]

Hi Wolfram,

On 8/9/2016 4:36 AM, Wolfram Sang wrote:

The core will do this for us now.

Signed-off-by: Wolfram Sang 


[...]


diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c 
b/drivers/i2c/busses/i2c-bcm-iproc.c
index 19c843828fe2ca..8e3477f9297eda 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -488,13 +488,7 @@ static int bcm_iproc_i2c_probe(struct platform_device 
*pdev)
adap->dev.parent = >dev;
adap->dev.of_node = pdev->dev.of_node;

-   ret = i2c_add_adapter(adap);
-   if (ret) {
-   dev_err(iproc_i2c->device, "failed to add adapter\n");
-   return ret;
-   }
-
-   return 0;
+   return i2c_add_adapter(adap);
 }

 static int bcm_iproc_i2c_remove(struct platform_device *pdev)
diff --git a/drivers/i2c/busses/i2c-bcm-kona.c 
b/drivers/i2c/busses/i2c-bcm-kona.c
index ac9f47679c3a4b..a5c9098507896b 100644
--- a/drivers/i2c/busses/i2c-bcm-kona.c
+++ b/drivers/i2c/busses/i2c-bcm-kona.c
@@ -858,10 +858,8 @@ static int bcm_kona_i2c_probe(struct platform_device *pdev)
adap->dev.of_node = pdev->dev.of_node;

rc = i2c_add_adapter(adap);
-   if (rc) {
-   dev_err(dev->device, "failed to add adapter\n");
+   if (rc)
return rc;
-   }

dev_info(dev->device, "device registered successfully\n");



For both i2c-bcm-iproc.c and i2c-bcm-kona.c:

Acked-by: Ray Jui 

Thanks,

Ray

Re: [PATCH] i2c: don't print error when adding adapter fails

[Ray Jui]

Hi Wolfram,

On 8/9/2016 4:36 AM, Wolfram Sang wrote:

The core will do this for us now.

Signed-off-by: Wolfram Sang 


[...]


diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c 
b/drivers/i2c/busses/i2c-bcm-iproc.c
index 19c843828fe2ca..8e3477f9297eda 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -488,13 +488,7 @@ static int bcm_iproc_i2c_probe(struct platform_device 
*pdev)
adap->dev.parent = >dev;
adap->dev.of_node = pdev->dev.of_node;

-   ret = i2c_add_adapter(adap);
-   if (ret) {
-   dev_err(iproc_i2c->device, "failed to add adapter\n");
-   return ret;
-   }
-
-   return 0;
+   return i2c_add_adapter(adap);
 }

 static int bcm_iproc_i2c_remove(struct platform_device *pdev)
diff --git a/drivers/i2c/busses/i2c-bcm-kona.c 
b/drivers/i2c/busses/i2c-bcm-kona.c
index ac9f47679c3a4b..a5c9098507896b 100644
--- a/drivers/i2c/busses/i2c-bcm-kona.c
+++ b/drivers/i2c/busses/i2c-bcm-kona.c
@@ -858,10 +858,8 @@ static int bcm_kona_i2c_probe(struct platform_device *pdev)
adap->dev.of_node = pdev->dev.of_node;

rc = i2c_add_adapter(adap);
-   if (rc) {
-   dev_err(dev->device, "failed to add adapter\n");
+   if (rc)
return rc;
-   }

dev_info(dev->device, "device registered successfully\n");



For both i2c-bcm-iproc.c and i2c-bcm-kona.c:

Acked-by: Ray Jui 

Thanks,

Ray

Re: [PATCH v13 00/16] PCI: Fixup for 64bit resource with sparc

[Yinghai Lu]

On Mon, Aug 8, 2016 at 12:49 PM, Bjorn Helgaas  wrote:
> On Fri, Jun 17, 2016 at 07:24:45PM -0700, Yinghai Lu wrote:
>
> Can you update these to apply to v4.8-rc1, and we can keep chipping
> away at these?

sure. will send rebased version shortly.

Thanks

Yinghai

Re: [PATCH v13 00/16] PCI: Fixup for 64bit resource with sparc

[Yinghai Lu]

On Mon, Aug 8, 2016 at 12:49 PM, Bjorn Helgaas  wrote:
> On Fri, Jun 17, 2016 at 07:24:45PM -0700, Yinghai Lu wrote:
>
> Can you update these to apply to v4.8-rc1, and we can keep chipping
> away at these?

sure. will send rebased version shortly.

Thanks

Yinghai

Re: [PATCH 4.4 00/68] 4.4.17-stable review

[Guenter Roeck]

On Tue, Aug 09, 2016 at 10:21:33AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Aug 08, 2016 at 09:22:24PM -0700, Guenter Roeck wrote:
> > On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.4.17 release.
> > > There are 68 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > > 
> > > Responses should be made by Wed Aug 10 18:01:56 UTC 2016.
> > > Anything received after that time might be too late.
> > > 
> > 
> > Build results:
> > total: 148 pass: 146 fail: 2
> > Failed builds:
> > arm:allmodconfig
> > arm64:allmodconfig
> > 
> > Qemu test results:
> > total: 101 pass: 99 fail: 2
> > Failed tests:
> > arm64:smp:defconfig
> > arm64:nosmp:defconfig
> > 
> > Common build error:
> > 
> > drivers/i2c/busses/i2c-qup.c: In function 'qup_i2c_read_one':
> > drivers/i2c/busses/i2c-qup.c:438:2: error: 'idx' undeclared
> > 
> > Culprit: ae5451257fc2 ("i2c: qup: Fix wrong value of index variable")
> 
> Ah, thanks, kbuild just caught this one as well.  I've dropped it from
> the queue now.
> 
Build and qemu tests are now clean.

Guenter

Re: [PATCH 4.4 00/68] 4.4.17-stable review

[Guenter Roeck]

On Tue, Aug 09, 2016 at 10:21:33AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Aug 08, 2016 at 09:22:24PM -0700, Guenter Roeck wrote:
> > On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.4.17 release.
> > > There are 68 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > > 
> > > Responses should be made by Wed Aug 10 18:01:56 UTC 2016.
> > > Anything received after that time might be too late.
> > > 
> > 
> > Build results:
> > total: 148 pass: 146 fail: 2
> > Failed builds:
> > arm:allmodconfig
> > arm64:allmodconfig
> > 
> > Qemu test results:
> > total: 101 pass: 99 fail: 2
> > Failed tests:
> > arm64:smp:defconfig
> > arm64:nosmp:defconfig
> > 
> > Common build error:
> > 
> > drivers/i2c/busses/i2c-qup.c: In function 'qup_i2c_read_one':
> > drivers/i2c/busses/i2c-qup.c:438:2: error: 'idx' undeclared
> > 
> > Culprit: ae5451257fc2 ("i2c: qup: Fix wrong value of index variable")
> 
> Ah, thanks, kbuild just caught this one as well.  I've dropped it from
> the queue now.
> 
Build and qemu tests are now clean.

Guenter

Re: [RFC PATCH v7 1/7] Restartable sequences system call

[Boqun Feng]

On Wed, Aug 03, 2016 at 10:03:32PM -0700, Andy Lutomirski wrote:
> On Wed, Aug 3, 2016 at 9:27 PM, Boqun Feng  wrote:
> > On Wed, Aug 03, 2016 at 09:37:57AM -0700, Andy Lutomirski wrote:
> >> On Wed, Aug 3, 2016 at 5:27 AM, Peter Zijlstra  
> >> wrote:
> >> > On Tue, Jul 26, 2016 at 03:02:19AM +, Mathieu Desnoyers wrote:
> >> >> We really care about preemption here. Every migration implies a
> >> >> preemption from a user-space perspective. If we would only care
> >> >> about keeping the CPU id up-to-date, hooking into migration would be
> >> >> enough. But since we want atomicity guarantees for restartable
> >> >> sequences, we need to hook into preemption.
> >> >
> >> >> It allows user-space to perform update operations on per-cpu data 
> >> >> without
> >> >> requiring heavy-weight atomic operations.
> >> >
> >> > Well, a CMPXCHG without LOCK prefix isn't all that expensive on x86.
> >> >
> >> > It is however on PPC and possibly other architectures, so in name of
> >> > simplicity supporting only the one variant makes sense.
> >> >
> >>
> >> I wouldn't want to depend on CMPXCHG.  But imagine we had primitives
> >> that were narrower than the full abort-on-preemption primitive.
> >> Specifically, suppose we had abort if (actual cpu != expected_cpu ||
> >> *aptr != aval).  We could do things like:
> >>
> >> expected_cpu = cpu;
> >> aval = NULL;  // disarm for now
> >> begin();
> >> aval = event_count[cpu] + 1;
> >> event_count[cpu] = aval;
> >> event_count[cpu]++;
> >
> > This line is redundant, right? Because it will guarantee a failure even
> > in no-contention cases.
> >
> >>
> >> ... compute something ...
> >>
> >> // arm the rest of it
> >> aptr = _count[cpu];
> >> if (*aptr != aval)
> >>   goto fail;
> >>
> >> *thing_im_writing = value_i_computed;
> >> end();
> >>
> >> The idea here is that we don't rely on the scheduler to increment the
> >> event count at all, which means that we get to determine the scope of
> >> what kinds of access conflicts we care about ourselves.
> >>
> >
> > If we increase the event count in userspace, how could we prevent two
> > userspace threads from racing on the event_count[cpu] field? For
> > example:
> >
> > CPU 0
> > 
> > {event_count[0] is initially 0}
> >
> > [Thread 1]
> > begin();
> > aval = event_count[cpu] + 1; // 1
> >
> > (preempted)
> > [Thread 2]
> > begin();
> > aval = event_count[cpu] + 1; // 1, too
> > event_count[cpu] = aval; // event_count[0] is 1
> >
> 
> You're right :(  This would work with an xadd instruction, but that's
> very slow and doesn't exist on most architectures.  It could also work
> if we did:
> 
> aval = some_tls_value++;
> 
> where some_tls_value is set up such that no two threads could ever end
> up with the same values (using high bits as thread ids, perhaps), but
> that's messy.  Maybe my idea is no good.

This is a little more complex, plus I failed to find a way to do an
atomic "if (*aptr == aval) *b = c" in userspace ;-(

However, I'm thinking maybe we can use some tricks to avoid unnecessary
aborts-on-preemption.

First of all, I notice we haven't make any constraint on what kind of
memory objects could be "protected" by rseq critical sections yet. And I
think this is something we should decide before adding this feature into
kernel.

We can do some optimization if we have some constraints. For example, if
the memory objects inside the rseq critical sections could only be
modified by userspace programs, we therefore don't need to abort
immediately when userspace task -> kernel task context switch.

Further more, if the memory objects inside the rseq critical sections
could only be modified by userspace programs that have registered their
rseq structures, we don't need to abort immediately between the context
switches between two rseq-unregistered tasks or one rseq-registered
task and one rseq-unregistered task.

Instead, we do tricks as follow:

defining a percpu pointer in kernel:

DEFINE_PER_CPU(struct task_struct *, rseq_owner);

and a cpu field in struct task_struct:

struct task_struct {
...
#ifdef CONFIG_RSEQ  

struct rseq __user *rseq;   

uint32_t rseq_event_counter;

int rseq_cpu;
#endif  
...
};

(task_struct::rseq_cpu should be initialized as -1.)

each time at sched out(in rseq_sched_out()), we do something like:

if (prev->rseq) {
raw_cpu_write(rseq_owner, prev);
prev->rseq_cpu = smp_processor_id();
}

each time sched in(in rseq_handle_notify_resume()), we do something
like:

if (current->rseq &&
(this_cpu_read(rseq_owner) != current || 
 

Re: [RFC PATCH v7 1/7] Restartable sequences system call

[Boqun Feng]

On Wed, Aug 03, 2016 at 10:03:32PM -0700, Andy Lutomirski wrote:
> On Wed, Aug 3, 2016 at 9:27 PM, Boqun Feng  wrote:
> > On Wed, Aug 03, 2016 at 09:37:57AM -0700, Andy Lutomirski wrote:
> >> On Wed, Aug 3, 2016 at 5:27 AM, Peter Zijlstra  
> >> wrote:
> >> > On Tue, Jul 26, 2016 at 03:02:19AM +, Mathieu Desnoyers wrote:
> >> >> We really care about preemption here. Every migration implies a
> >> >> preemption from a user-space perspective. If we would only care
> >> >> about keeping the CPU id up-to-date, hooking into migration would be
> >> >> enough. But since we want atomicity guarantees for restartable
> >> >> sequences, we need to hook into preemption.
> >> >
> >> >> It allows user-space to perform update operations on per-cpu data 
> >> >> without
> >> >> requiring heavy-weight atomic operations.
> >> >
> >> > Well, a CMPXCHG without LOCK prefix isn't all that expensive on x86.
> >> >
> >> > It is however on PPC and possibly other architectures, so in name of
> >> > simplicity supporting only the one variant makes sense.
> >> >
> >>
> >> I wouldn't want to depend on CMPXCHG.  But imagine we had primitives
> >> that were narrower than the full abort-on-preemption primitive.
> >> Specifically, suppose we had abort if (actual cpu != expected_cpu ||
> >> *aptr != aval).  We could do things like:
> >>
> >> expected_cpu = cpu;
> >> aval = NULL;  // disarm for now
> >> begin();
> >> aval = event_count[cpu] + 1;
> >> event_count[cpu] = aval;
> >> event_count[cpu]++;
> >
> > This line is redundant, right? Because it will guarantee a failure even
> > in no-contention cases.
> >
> >>
> >> ... compute something ...
> >>
> >> // arm the rest of it
> >> aptr = _count[cpu];
> >> if (*aptr != aval)
> >>   goto fail;
> >>
> >> *thing_im_writing = value_i_computed;
> >> end();
> >>
> >> The idea here is that we don't rely on the scheduler to increment the
> >> event count at all, which means that we get to determine the scope of
> >> what kinds of access conflicts we care about ourselves.
> >>
> >
> > If we increase the event count in userspace, how could we prevent two
> > userspace threads from racing on the event_count[cpu] field? For
> > example:
> >
> > CPU 0
> > 
> > {event_count[0] is initially 0}
> >
> > [Thread 1]
> > begin();
> > aval = event_count[cpu] + 1; // 1
> >
> > (preempted)
> > [Thread 2]
> > begin();
> > aval = event_count[cpu] + 1; // 1, too
> > event_count[cpu] = aval; // event_count[0] is 1
> >
> 
> You're right :(  This would work with an xadd instruction, but that's
> very slow and doesn't exist on most architectures.  It could also work
> if we did:
> 
> aval = some_tls_value++;
> 
> where some_tls_value is set up such that no two threads could ever end
> up with the same values (using high bits as thread ids, perhaps), but
> that's messy.  Maybe my idea is no good.

This is a little more complex, plus I failed to find a way to do an
atomic "if (*aptr == aval) *b = c" in userspace ;-(

However, I'm thinking maybe we can use some tricks to avoid unnecessary
aborts-on-preemption.

First of all, I notice we haven't make any constraint on what kind of
memory objects could be "protected" by rseq critical sections yet. And I
think this is something we should decide before adding this feature into
kernel.

We can do some optimization if we have some constraints. For example, if
the memory objects inside the rseq critical sections could only be
modified by userspace programs, we therefore don't need to abort
immediately when userspace task -> kernel task context switch.

Further more, if the memory objects inside the rseq critical sections
could only be modified by userspace programs that have registered their
rseq structures, we don't need to abort immediately between the context
switches between two rseq-unregistered tasks or one rseq-registered
task and one rseq-unregistered task.

Instead, we do tricks as follow:

defining a percpu pointer in kernel:

DEFINE_PER_CPU(struct task_struct *, rseq_owner);

and a cpu field in struct task_struct:

struct task_struct {
...
#ifdef CONFIG_RSEQ  

struct rseq __user *rseq;   

uint32_t rseq_event_counter;

int rseq_cpu;
#endif  
...
};

(task_struct::rseq_cpu should be initialized as -1.)

each time at sched out(in rseq_sched_out()), we do something like:

if (prev->rseq) {
raw_cpu_write(rseq_owner, prev);
prev->rseq_cpu = smp_processor_id();
}

each time sched in(in rseq_handle_notify_resume()), we do something
like:

if (current->rseq &&
(this_cpu_read(rseq_owner) != current || 
 current->rseq_cpu != smp_processor_id()))
 

Re: "Failed to create /dev/root: -14" after commit e6978e4bf1 ("ARM: save and reset the address limit when entering an exception")

[Guenter Roeck]

On Tue, Aug 09, 2016 at 05:06:51PM +0200, Gregory CLEMENT wrote:
> Hi Russell King,
>  
>  On jeu., août 04 2016, Russell King - ARM Linux  
> wrote:
> 
> > On Wed, Aug 03, 2016 at 08:07:02AM -0700, Guenter Roeck wrote:
> >> On 08/03/2016 01:38 AM, Russell King - ARM Linux wrote:
> >> >On Tue, Aug 02, 2016 at 07:51:45PM -0700, Guenter Roeck wrote:
> >> >>Hi,
> >> >>
> >> >>I see the following crash when running a qemu arm 'kzm' runtime test with
> >> >>the current mainline.
> >> >>...
> >> >>Failed to create /dev/root: -14
> >> >>
> >> >>[ followed by panic ]
> >> >>
> >> >>A complete log file is at [1].
> >> >
> >> >I think it's because of those undefined instructions you're hitting
> >> >with the hw-breakpoint code... can you try the patch below please?
> >> >
> >> >  arch/arm/kernel/entry-armv.S | 1 +
> >> >  1 file changed, 1 insertion(+)
> >> >
> >> >diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> >> >index bc5f50799d75..9f157e7c51e7 100644
> >> >--- a/arch/arm/kernel/entry-armv.S
> >> >+++ b/arch/arm/kernel/entry-armv.S
> >> >@@ -295,6 +295,7 @@ __und_svc_fault:
> >> >  bl  __und_fault
> >> >
> >> >  __und_svc_finish:
> >> >+ get_thread_info tsk
> >> >  ldr r5, [sp, #S_PSR]@ Get SVC cpsr
> >> >  svc_exit r5 @ return from exception
> >> >   UNWIND(.fnend  )
> >> >
> >> 
> >> Yes, that fixes the problem.
> >> 
> >> Assuming you'll create a patch:
> >> 
> >> Tested-by: Guenter Roeck 
> >> 
> >> Does that need to be addressed in qemu, or is it a Linux bug ?
> >
> > It's a Linux bug provoked by qemu not implementing the hardware
> > breakpoints.  Well worth fixing in Linux.
> 
> The Armada XP base platform were hit by the same bug as we can see on
> kernlci:
> https://storage.kernelci.org/mainline/v4.8-rc1/arm-mvebu_v7_defconfig/lab-baylibre-seattle/boot-armada-xp-openblocks-ax3-4.html
> 
> Your patch solves the issue too.
> 
> Will you push this patch for v4.8-rc2 ?
> 
> Also I wonder if it is something expected to have this issue on a "real"
> hardware.
> 

It would be expected if hardware breakpoint implementation is optional
and not all real CPUs implement it.

Guenter

Re: "Failed to create /dev/root: -14" after commit e6978e4bf1 ("ARM: save and reset the address limit when entering an exception")

[Guenter Roeck]

On Tue, Aug 09, 2016 at 05:06:51PM +0200, Gregory CLEMENT wrote:
> Hi Russell King,
>  
>  On jeu., août 04 2016, Russell King - ARM Linux  
> wrote:
> 
> > On Wed, Aug 03, 2016 at 08:07:02AM -0700, Guenter Roeck wrote:
> >> On 08/03/2016 01:38 AM, Russell King - ARM Linux wrote:
> >> >On Tue, Aug 02, 2016 at 07:51:45PM -0700, Guenter Roeck wrote:
> >> >>Hi,
> >> >>
> >> >>I see the following crash when running a qemu arm 'kzm' runtime test with
> >> >>the current mainline.
> >> >>...
> >> >>Failed to create /dev/root: -14
> >> >>
> >> >>[ followed by panic ]
> >> >>
> >> >>A complete log file is at [1].
> >> >
> >> >I think it's because of those undefined instructions you're hitting
> >> >with the hw-breakpoint code... can you try the patch below please?
> >> >
> >> >  arch/arm/kernel/entry-armv.S | 1 +
> >> >  1 file changed, 1 insertion(+)
> >> >
> >> >diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> >> >index bc5f50799d75..9f157e7c51e7 100644
> >> >--- a/arch/arm/kernel/entry-armv.S
> >> >+++ b/arch/arm/kernel/entry-armv.S
> >> >@@ -295,6 +295,7 @@ __und_svc_fault:
> >> >  bl  __und_fault
> >> >
> >> >  __und_svc_finish:
> >> >+ get_thread_info tsk
> >> >  ldr r5, [sp, #S_PSR]@ Get SVC cpsr
> >> >  svc_exit r5 @ return from exception
> >> >   UNWIND(.fnend  )
> >> >
> >> 
> >> Yes, that fixes the problem.
> >> 
> >> Assuming you'll create a patch:
> >> 
> >> Tested-by: Guenter Roeck 
> >> 
> >> Does that need to be addressed in qemu, or is it a Linux bug ?
> >
> > It's a Linux bug provoked by qemu not implementing the hardware
> > breakpoints.  Well worth fixing in Linux.
> 
> The Armada XP base platform were hit by the same bug as we can see on
> kernlci:
> https://storage.kernelci.org/mainline/v4.8-rc1/arm-mvebu_v7_defconfig/lab-baylibre-seattle/boot-armada-xp-openblocks-ax3-4.html
> 
> Your patch solves the issue too.
> 
> Will you push this patch for v4.8-rc2 ?
> 
> Also I wonder if it is something expected to have this issue on a "real"
> hardware.
> 

It would be expected if hardware breakpoint implementation is optional
and not all real CPUs implement it.

Guenter

[PATCH v3] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

[Chris Wilson]

With debugobjects enabled and using SLAB_DESTROY_BY_RCU, when a
kmem_cache_node is destroyed the call_rcu() may trigger a slab
allocation to fill the debug object pool (__debug_object_init:fill_pool).
Everywhere but during kmem_cache_destroy(), discard_slab() is performed
outside of the kmem_cache_node->list_lock and avoids a lockdep warning
about potential recursion:

[  138.850350] =
[  138.850352] [ INFO: possible recursive locking detected ]
[  138.850355] 4.8.0-rc1-gfxbench+ #1 Tainted: G U
[  138.850357] -
[  138.850359] rmmod/8895 is trying to acquire lock:
[  138.850360]  (&(>list_lock)->rlock){-.-...}, at: [] 
get_partial_node.isra.63+0x47/0x430
[  138.850368]
   but task is already holding lock:
[  138.850371]  (&(>list_lock)->rlock){-.-...}, at: [] 
__kmem_cache_shutdown+0x54/0x320
[  138.850376]
   other info that might help us debug this:
[  138.850378]  Possible unsafe locking scenario:

[  138.850380]CPU0
[  138.850381]
[  138.850382]   lock(&(>list_lock)->rlock);
[  138.850385]   lock(&(>list_lock)->rlock);
[  138.850387]
*** DEADLOCK ***

[  138.850391]  May be due to missing lock nesting notation

[  138.850395] 5 locks held by rmmod/8895:
[  138.850397]  #0:  (>mutex){..}, at: [] 
driver_detach+0x42/0xc0
[  138.850404]  #1:  (>mutex){..}, at: [] 
driver_detach+0x50/0xc0
[  138.850410]  #2:  (cpu_hotplug.dep_map){++}, at: [] 
get_online_cpus+0x2d/0x80
[  138.850418]  #3:  (slab_mutex){+.+.+.}, at: [] 
kmem_cache_destroy+0x3c/0x220
[  138.850424]  #4:  (&(>list_lock)->rlock){-.-...}, at: 
[] __kmem_cache_shutdown+0x54/0x320
[  138.850431]
   stack backtrace:
[  138.850435] CPU: 6 PID: 8895 Comm: rmmod Tainted: G U  
4.8.0-rc1-gfxbench+ #1
[  138.850439] Hardware name: Gigabyte Technology Co., Ltd. H87M-D3H/H87M-D3H, 
BIOS F11 08/18/2015
[  138.850443]   880179b93800 814221f5 
8801d1e5ce40
[  138.850449]  827c6dd0 880179b938c0 810d48a6 
00ff
[  138.850454]  88017990d900 880179b93930 d445 
a70e0e46e14b0709
[  138.850459] Call Trace:
[  138.850463]  [] dump_stack+0x67/0x92
[  138.850467]  [] __lock_acquire+0x1646/0x1ad0
[  138.850492]  [] ? i915_exit+0x1a/0x1e2 [i915]
[  138.850509]  [] lock_acquire+0xb2/0x200
[  138.850512]  [] ? get_partial_node.isra.63+0x47/0x430
[  138.850516]  [] _raw_spin_lock+0x36/0x50
[  138.850519]  [] ? get_partial_node.isra.63+0x47/0x430
[  138.850522]  [] get_partial_node.isra.63+0x47/0x430
[  138.850543]  [] ? __module_address+0x27/0xf0
[  138.850558]  [] ? i915_exit+0x1a/0x1e2 [i915]
[  138.850561]  [] ? __module_text_address+0xd/0x60
[  138.850565]  [] ? is_module_text_address+0x2a/0x50
[  138.850568]  [] ? __kernel_text_address+0x31/0x80
[  138.850572]  [] ? print_context_stack+0x79/0xd0
[  138.850575]  [] ? dump_trace+0x124/0x300
[  138.850579]  [] ___slab_alloc.constprop.67+0x1a7/0x3b0
[  138.850582]  [] ? __debug_object_init+0x2de/0x400
[  138.850586]  [] ? 
add_lock_to_list.isra.22.constprop.41+0x77/0xc0
[  138.850590]  [] ? __lock_acquire+0x13ae/0x1ad0
[  138.850594]  [] ? __debug_object_init+0x2de/0x400
[  138.850597]  [] __slab_alloc.isra.64.constprop.66+0x43/0x80
[  138.850601]  [] kmem_cache_alloc+0x236/0x2d0
[  138.850604]  [] ? __debug_object_init+0x2de/0x400
[  138.850607]  [] __debug_object_init+0x2de/0x400
[  138.850611]  [] debug_object_activate+0x109/0x1e0
[  138.850614]  [] ? slab_cpuup_callback+0x100/0x100
[  138.850618]  [] __call_rcu.constprop.63+0x32/0x2f0
[  138.850621]  [] call_rcu+0x12/0x20
[  138.850624]  [] discard_slab+0x3d/0x40
[  138.850627]  [] __kmem_cache_shutdown+0xdb/0x320
[  138.850631]  [] ? kmem_cache_destroy+0x3c/0x220
[  138.850634]  [] shutdown_cache+0x19/0x60
[  138.850638]  [] kmem_cache_destroy+0x1ae/0x220
[  138.850650]  [] i915_gem_load_cleanup+0x14/0x40 [i915]
[  138.850660]  [] i915_driver_unload+0x151/0x180 [i915]
[  138.850670]  [] i915_pci_remove+0x14/0x20 [i915]
[  138.850673]  [] pci_device_remove+0x34/0xb0
[  138.850677]  [] __device_release_driver+0x95/0x140
[  138.850680]  [] driver_detach+0xb6/0xc0
[  138.850683]  [] bus_remove_driver+0x53/0xd0
[  138.850687]  [] driver_unregister+0x27/0x50
[  138.850689]  [] pci_unregister_driver+0x25/0x70
[  138.850704]  [] i915_exit+0x1a/0x1e2 [i915]
[  138.850707]  [] SyS_delete_module+0x193/0x1f0
[  138.850711]  [] entry_SYSCALL_64_fastpath+0x1c/0xac

v2: Keep remove_partial() under the lock, just move discard_slab()
outside the lock.
v3: Rename discard list.

Fixes: 52b4b950b507 ("mm: slab: free kmem_cache_node after destroy sysfs file")
Reported-by: Dave Gordon 
Signed-off-by: Chris Wilson 
Reviewed-by: Vladimir Davydov 
Cc: Christoph Lameter 
Cc: Pekka Enberg 
Cc: David Rientjes 

Re: rtc regression [463a86304cae ("char/genrtc: x86: remove remnants of asm/rtc.h")]

[Arnd Bergmann]

On Tuesday, August 9, 2016 6:56:49 PM CEST Ville Syrjälä wrote:
> Hi,
> 
> commit 463a86304cae ("char/genrtc: x86: remove remnants of asm/rtc.h")
> broke rtc for me. Neither hwclock or rtcwake work anymore. This is just
> a very standard x86-64 IVB box, and it was reported that machines in
> our i915 test farm are having rtc related problems as well.
> 
> The first time I run hwclock after rebooting I get this:
>  open("/dev/rtc", O_RDONLY)  = 3
>  ioctl(3, PHN_SET_REGS or RTC_UIE_ON, 0) = 0
>  select(4, [3], NULL, NULL, {10, 0}) = 0 (Timeout)
>  ioctl(3, PHN_NOT_OH or RTC_UIE_OFF, 0)  = 0
>  close(3)= 0
> 
> On all subsequent runs I get this:
>  open("/dev/rtc", O_RDONLY)  = 3
>  ioctl(3, PHN_SET_REGS or RTC_UIE_ON, 0) = -1 EINVAL (Invalid argument)
>  ioctl(3, RTC_RD_TIME, 0x7ffd76b3ae70)   = -1 EINVAL (Invalid argument)
>  close(3)= 0
> 
> 463a86304cae^ gets me back to working condition:
>  open("/dev/rtc", O_RDONLY)  = 3
>  ioctl(3, PHN_SET_REGS or RTC_UIE_ON, 0) = 0
>  select(4, [3], NULL, NULL, {10, 0}) = 1 (in [3], left {9, 530998})
>  ioctl(3, PHN_NOT_OH or RTC_UIE_OFF, 0)  = 0
>  ioctl(3, RTC_RD_TIME, {tm_sec=20, tm_min=17, tm_hour=15, tm_mday=9, 
> tm_mon=7, tm_year=116, ...}) = 0
>  close(3)= 0

That commit was supposed to have no effect on the binary, but it
seems I had a typo in one file. Can you try this patch on top
of mainline?

Arnd

diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index ed16e58658a4..c6dfd801df97 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -1242,7 +1242,7 @@ irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id)
memset(_time, 0, sizeof(struct rtc_time));
 
if (hpet_rtc_flags & (RTC_UIE | RTC_AIE))
-   mc146818_set_time(_time);
+   mc146818_get_time(_time);
 
if (hpet_rtc_flags & RTC_UIE &&
curr_time.tm_sec != hpet_prev_update_sec) {

[PATCH v3] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

[Chris Wilson]

With debugobjects enabled and using SLAB_DESTROY_BY_RCU, when a
kmem_cache_node is destroyed the call_rcu() may trigger a slab
allocation to fill the debug object pool (__debug_object_init:fill_pool).
Everywhere but during kmem_cache_destroy(), discard_slab() is performed
outside of the kmem_cache_node->list_lock and avoids a lockdep warning
about potential recursion:

[  138.850350] =
[  138.850352] [ INFO: possible recursive locking detected ]
[  138.850355] 4.8.0-rc1-gfxbench+ #1 Tainted: G U
[  138.850357] -
[  138.850359] rmmod/8895 is trying to acquire lock:
[  138.850360]  (&(>list_lock)->rlock){-.-...}, at: [] 
get_partial_node.isra.63+0x47/0x430
[  138.850368]
   but task is already holding lock:
[  138.850371]  (&(>list_lock)->rlock){-.-...}, at: [] 
__kmem_cache_shutdown+0x54/0x320
[  138.850376]
   other info that might help us debug this:
[  138.850378]  Possible unsafe locking scenario:

[  138.850380]CPU0
[  138.850381]
[  138.850382]   lock(&(>list_lock)->rlock);
[  138.850385]   lock(&(>list_lock)->rlock);
[  138.850387]
*** DEADLOCK ***

[  138.850391]  May be due to missing lock nesting notation

[  138.850395] 5 locks held by rmmod/8895:
[  138.850397]  #0:  (>mutex){..}, at: [] 
driver_detach+0x42/0xc0
[  138.850404]  #1:  (>mutex){..}, at: [] 
driver_detach+0x50/0xc0
[  138.850410]  #2:  (cpu_hotplug.dep_map){++}, at: [] 
get_online_cpus+0x2d/0x80
[  138.850418]  #3:  (slab_mutex){+.+.+.}, at: [] 
kmem_cache_destroy+0x3c/0x220
[  138.850424]  #4:  (&(>list_lock)->rlock){-.-...}, at: 
[] __kmem_cache_shutdown+0x54/0x320
[  138.850431]
   stack backtrace:
[  138.850435] CPU: 6 PID: 8895 Comm: rmmod Tainted: G U  
4.8.0-rc1-gfxbench+ #1
[  138.850439] Hardware name: Gigabyte Technology Co., Ltd. H87M-D3H/H87M-D3H, 
BIOS F11 08/18/2015
[  138.850443]   880179b93800 814221f5 
8801d1e5ce40
[  138.850449]  827c6dd0 880179b938c0 810d48a6 
00ff
[  138.850454]  88017990d900 880179b93930 d445 
a70e0e46e14b0709
[  138.850459] Call Trace:
[  138.850463]  [] dump_stack+0x67/0x92
[  138.850467]  [] __lock_acquire+0x1646/0x1ad0
[  138.850492]  [] ? i915_exit+0x1a/0x1e2 [i915]
[  138.850509]  [] lock_acquire+0xb2/0x200
[  138.850512]  [] ? get_partial_node.isra.63+0x47/0x430
[  138.850516]  [] _raw_spin_lock+0x36/0x50
[  138.850519]  [] ? get_partial_node.isra.63+0x47/0x430
[  138.850522]  [] get_partial_node.isra.63+0x47/0x430
[  138.850543]  [] ? __module_address+0x27/0xf0
[  138.850558]  [] ? i915_exit+0x1a/0x1e2 [i915]
[  138.850561]  [] ? __module_text_address+0xd/0x60
[  138.850565]  [] ? is_module_text_address+0x2a/0x50
[  138.850568]  [] ? __kernel_text_address+0x31/0x80
[  138.850572]  [] ? print_context_stack+0x79/0xd0
[  138.850575]  [] ? dump_trace+0x124/0x300
[  138.850579]  [] ___slab_alloc.constprop.67+0x1a7/0x3b0
[  138.850582]  [] ? __debug_object_init+0x2de/0x400
[  138.850586]  [] ? 
add_lock_to_list.isra.22.constprop.41+0x77/0xc0
[  138.850590]  [] ? __lock_acquire+0x13ae/0x1ad0
[  138.850594]  [] ? __debug_object_init+0x2de/0x400
[  138.850597]  [] __slab_alloc.isra.64.constprop.66+0x43/0x80
[  138.850601]  [] kmem_cache_alloc+0x236/0x2d0
[  138.850604]  [] ? __debug_object_init+0x2de/0x400
[  138.850607]  [] __debug_object_init+0x2de/0x400
[  138.850611]  [] debug_object_activate+0x109/0x1e0
[  138.850614]  [] ? slab_cpuup_callback+0x100/0x100
[  138.850618]  [] __call_rcu.constprop.63+0x32/0x2f0
[  138.850621]  [] call_rcu+0x12/0x20
[  138.850624]  [] discard_slab+0x3d/0x40
[  138.850627]  [] __kmem_cache_shutdown+0xdb/0x320
[  138.850631]  [] ? kmem_cache_destroy+0x3c/0x220
[  138.850634]  [] shutdown_cache+0x19/0x60
[  138.850638]  [] kmem_cache_destroy+0x1ae/0x220
[  138.850650]  [] i915_gem_load_cleanup+0x14/0x40 [i915]
[  138.850660]  [] i915_driver_unload+0x151/0x180 [i915]
[  138.850670]  [] i915_pci_remove+0x14/0x20 [i915]
[  138.850673]  [] pci_device_remove+0x34/0xb0
[  138.850677]  [] __device_release_driver+0x95/0x140
[  138.850680]  [] driver_detach+0xb6/0xc0
[  138.850683]  [] bus_remove_driver+0x53/0xd0
[  138.850687]  [] driver_unregister+0x27/0x50
[  138.850689]  [] pci_unregister_driver+0x25/0x70
[  138.850704]  [] i915_exit+0x1a/0x1e2 [i915]
[  138.850707]  [] SyS_delete_module+0x193/0x1f0
[  138.850711]  [] entry_SYSCALL_64_fastpath+0x1c/0xac

v2: Keep remove_partial() under the lock, just move discard_slab()
outside the lock.
v3: Rename discard list.

Fixes: 52b4b950b507 ("mm: slab: free kmem_cache_node after destroy sysfs file")
Reported-by: Dave Gordon 
Signed-off-by: Chris Wilson 
Reviewed-by: Vladimir Davydov 
Cc: Christoph Lameter 
Cc: Pekka Enberg 
Cc: David Rientjes 
Cc: Joonsoo Kim 
Cc: Andrew Morton 
Cc: Dmitry Safonov 
Cc: Vladimir Davydov 
Cc: Daniel Vetter 
Cc: Dave Gordon 
Cc: 

Re: rtc regression [463a86304cae ("char/genrtc: x86: remove remnants of asm/rtc.h")]

[Arnd Bergmann]

On Tuesday, August 9, 2016 6:56:49 PM CEST Ville Syrjälä wrote:
> Hi,
> 
> commit 463a86304cae ("char/genrtc: x86: remove remnants of asm/rtc.h")
> broke rtc for me. Neither hwclock or rtcwake work anymore. This is just
> a very standard x86-64 IVB box, and it was reported that machines in
> our i915 test farm are having rtc related problems as well.
> 
> The first time I run hwclock after rebooting I get this:
>  open("/dev/rtc", O_RDONLY)  = 3
>  ioctl(3, PHN_SET_REGS or RTC_UIE_ON, 0) = 0
>  select(4, [3], NULL, NULL, {10, 0}) = 0 (Timeout)
>  ioctl(3, PHN_NOT_OH or RTC_UIE_OFF, 0)  = 0
>  close(3)= 0
> 
> On all subsequent runs I get this:
>  open("/dev/rtc", O_RDONLY)  = 3
>  ioctl(3, PHN_SET_REGS or RTC_UIE_ON, 0) = -1 EINVAL (Invalid argument)
>  ioctl(3, RTC_RD_TIME, 0x7ffd76b3ae70)   = -1 EINVAL (Invalid argument)
>  close(3)= 0
> 
> 463a86304cae^ gets me back to working condition:
>  open("/dev/rtc", O_RDONLY)  = 3
>  ioctl(3, PHN_SET_REGS or RTC_UIE_ON, 0) = 0
>  select(4, [3], NULL, NULL, {10, 0}) = 1 (in [3], left {9, 530998})
>  ioctl(3, PHN_NOT_OH or RTC_UIE_OFF, 0)  = 0
>  ioctl(3, RTC_RD_TIME, {tm_sec=20, tm_min=17, tm_hour=15, tm_mday=9, 
> tm_mon=7, tm_year=116, ...}) = 0
>  close(3)= 0

That commit was supposed to have no effect on the binary, but it
seems I had a typo in one file. Can you try this patch on top
of mainline?

Arnd

diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index ed16e58658a4..c6dfd801df97 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -1242,7 +1242,7 @@ irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id)
memset(_time, 0, sizeof(struct rtc_time));
 
if (hpet_rtc_flags & (RTC_UIE | RTC_AIE))
-   mc146818_set_time(_time);
+   mc146818_get_time(_time);
 
if (hpet_rtc_flags & RTC_UIE &&
curr_time.tm_sec != hpet_prev_update_sec) {

Re: tty/serial/8250: use mctrl_gpio helpers - Causes problems on ACPI systems

[Andy Shevchenko]

+Peter

On Tue, 2016-08-09 at 16:02 +0300, Mika Westerberg wrote:
> Hi,
> 
> I noticed that with v4.8-rc1 serial console of some of our Broxton
> systems does not work properly anymore. I'm able to see output but
> input
> does not work.
> 
> I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341
> ("tty/serial/8250: use mctrl_gpio helpers").

Mika, thanks for the detailed analysis. 
Yegor, consider this mail as a follow up to [1].

[1] http://www.spinics.net/lists/linux-serial/msg23071.html

> 
> The reason why it fails is that in ACPI we do not have names for GPIOs
> (except when _DSD is used) so we use the "idx" to index into _CRS GPIO
> resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs
> calling devm_gpiod_get_index_optional() passing "idx" of 0 for each.
> The
> UART device in Broxton has following (simplified) ACPI description:
> 
> Device (URT4)
> {
> ...
> Name (_CRS, ResourceTemplate () {
> GpioIo (Exclusive, PullDefault, 0x, 0x,
> IoRestrictionOutputOnly,
> "\\_SB.GPO0", 0x00, ResourceConsumer)
> {
> 0x003A
> }
> GpioIo (Exclusive, PullDefault, 0x, 0x,
> IoRestrictionOutputOnly,
> "\\_SB.GPO0", 0x00, ResourceConsumer)
> {
> 0x003D
> }
> })
> 
> In this case it finds the first GPIO (0x003A which happens to be RX
> pin
> for that UART), turns it into GPIO which then breaks input for the
> UART
> device. This also breaks systems with bluetooth connected to UART
> (those
> typically have some GPIOs in their _CRS).
> 
> Any ideas how to fix this?
> 
> We cannot just drop the _CRS index lookup fallback because that would
> break many existing machines out there so maybe we can limit this to
> only DT enabled machines. Or alternatively probe if the property first
> exists before trying to acquire the GPIOs (using
> device_property_present()).

-- 
Andy Shevchenko 
Intel Finland Oy

Re: tty/serial/8250: use mctrl_gpio helpers - Causes problems on ACPI systems

[Andy Shevchenko]

+Peter

On Tue, 2016-08-09 at 16:02 +0300, Mika Westerberg wrote:
> Hi,
> 
> I noticed that with v4.8-rc1 serial console of some of our Broxton
> systems does not work properly anymore. I'm able to see output but
> input
> does not work.
> 
> I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341
> ("tty/serial/8250: use mctrl_gpio helpers").

Mika, thanks for the detailed analysis. 
Yegor, consider this mail as a follow up to [1].

[1] http://www.spinics.net/lists/linux-serial/msg23071.html

> 
> The reason why it fails is that in ACPI we do not have names for GPIOs
> (except when _DSD is used) so we use the "idx" to index into _CRS GPIO
> resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs
> calling devm_gpiod_get_index_optional() passing "idx" of 0 for each.
> The
> UART device in Broxton has following (simplified) ACPI description:
> 
> Device (URT4)
> {
> ...
> Name (_CRS, ResourceTemplate () {
> GpioIo (Exclusive, PullDefault, 0x, 0x,
> IoRestrictionOutputOnly,
> "\\_SB.GPO0", 0x00, ResourceConsumer)
> {
> 0x003A
> }
> GpioIo (Exclusive, PullDefault, 0x, 0x,
> IoRestrictionOutputOnly,
> "\\_SB.GPO0", 0x00, ResourceConsumer)
> {
> 0x003D
> }
> })
> 
> In this case it finds the first GPIO (0x003A which happens to be RX
> pin
> for that UART), turns it into GPIO which then breaks input for the
> UART
> device. This also breaks systems with bluetooth connected to UART
> (those
> typically have some GPIOs in their _CRS).
> 
> Any ideas how to fix this?
> 
> We cannot just drop the _CRS index lookup fallback because that would
> break many existing machines out there so maybe we can limit this to
> only DT enabled machines. Or alternatively probe if the property first
> exists before trying to acquire the GPIOs (using
> device_property_present()).

-- 
Andy Shevchenko 
Intel Finland Oy

[PACTH v1] mm, proc: Implement /proc//totmaps

[robert . foss]

From: Sonny Rao 

This is based on earlier work by Thiago Goncales. It implements a new
per process proc file which summarizes the contents of the smaps file
but doesn't display any addresses.  It gives more detailed information
than statm like the PSS (proprotional set size).  It differs from the
original implementation in that it doesn't use the full blown set of
seq operations, uses a different termination condition, and doesn't
displayed "Locked" as that was broken on the original implemenation.

This new proc file provides information faster than parsing the potentially
huge smaps file.

Signed-off-by: Sonny Rao 

Tested-by: Robert Foss 
Signed-off-by: Robert Foss 

---
 fs/proc/base.c |   1 +
 fs/proc/internal.h |   4 ++
 fs/proc/task_mmu.c | 126 +
 3 files changed, 131 insertions(+)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index a11eb71..de3acdf 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2855,6 +2855,7 @@ static const struct pid_entry tgid_base_stuff[] = {
REG("clear_refs", S_IWUSR, proc_clear_refs_operations),
REG("smaps",  S_IRUGO, proc_pid_smaps_operations),
REG("pagemap",S_IRUSR, proc_pagemap_operations),
+   REG("totmaps",S_IRUGO, proc_totmaps_operations),
 #endif
 #ifdef CONFIG_SECURITY
DIR("attr",   S_IRUGO|S_IXUGO, proc_attr_dir_inode_operations, 
proc_attr_dir_operations),
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index aa27810..6f3540f 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -58,6 +58,9 @@ union proc_op {
struct task_struct *task);
 };
 
+
+extern const struct file_operations proc_totmaps_operations;
+
 struct proc_inode {
struct pid *pid;
int fd;
@@ -281,6 +284,7 @@ struct proc_maps_private {
struct mm_struct *mm;
 #ifdef CONFIG_MMU
struct vm_area_struct *tail_vma;
+   struct mem_size_stats *mss;
 #endif
 #ifdef CONFIG_NUMA
struct mempolicy *task_mempolicy;
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 4648c7f..b61873e 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -802,6 +802,81 @@ static int show_smap(struct seq_file *m, void *v, int 
is_pid)
return 0;
 }
 
+static void add_smaps_sum(struct mem_size_stats *mss,
+   struct mem_size_stats *mss_sum)
+{
+   mss_sum->resident += mss->resident;
+   mss_sum->pss += mss->pss;
+   mss_sum->shared_clean += mss->shared_clean;
+   mss_sum->shared_dirty += mss->shared_dirty;
+   mss_sum->private_clean += mss->private_clean;
+   mss_sum->private_dirty += mss->private_dirty;
+   mss_sum->referenced += mss->referenced;
+   mss_sum->anonymous += mss->anonymous;
+   mss_sum->anonymous_thp += mss->anonymous_thp;
+   mss_sum->swap += mss->swap;
+}
+
+static int totmaps_proc_show(struct seq_file *m, void *data)
+{
+   struct proc_maps_private *priv = m->private;
+   struct mm_struct *mm;
+   struct vm_area_struct *vma;
+   struct mem_size_stats *mss_sum = priv->mss;
+
+   /* reference to priv->task already taken */
+   /* but need to get the mm here because */
+   /* task could be in the process of exiting */
+   mm = get_task_mm(priv->task);
+   if (!mm || IS_ERR(mm))
+   return -EINVAL;
+
+   down_read(>mmap_sem);
+   hold_task_mempolicy(priv);
+
+   for (vma = mm->mmap; vma != priv->tail_vma; vma = vma->vm_next) {
+   struct mem_size_stats mss;
+   struct mm_walk smaps_walk = {
+   .pmd_entry = smaps_pte_range,
+   .mm = vma->vm_mm,
+   .private = ,
+   };
+
+   if (vma->vm_mm && !is_vm_hugetlb_page(vma)) {
+   memset(, 0, sizeof(mss));
+   walk_page_vma(vma, _walk);
+   add_smaps_sum(, mss_sum);
+   }
+   }
+   seq_printf(m,
+  "Rss:%8lu kB\n"
+  "Pss:%8lu kB\n"
+  "Shared_Clean:   %8lu kB\n"
+  "Shared_Dirty:   %8lu kB\n"
+  "Private_Clean:  %8lu kB\n"
+  "Private_Dirty:  %8lu kB\n"
+  "Referenced: %8lu kB\n"
+  "Anonymous:  %8lu kB\n"
+  "AnonHugePages:  %8lu kB\n"
+  "Swap:   %8lu kB\n",
+  mss_sum->resident >> 10,
+  (unsigned long)(mss_sum->pss >> (10 + PSS_SHIFT)),
+  mss_sum->shared_clean  >> 10,
+  mss_sum->shared_dirty  >> 10,
+  mss_sum->private_clean >> 10,
+  mss_sum->private_dirty >> 10,
+  mss_sum->referenced >> 10,
+  mss_sum->anonymous >> 10,
+  

[PACTH v1] mm, proc: Implement /proc//totmaps

[robert . foss]

From: Sonny Rao 

This is based on earlier work by Thiago Goncales. It implements a new
per process proc file which summarizes the contents of the smaps file
but doesn't display any addresses.  It gives more detailed information
than statm like the PSS (proprotional set size).  It differs from the
original implementation in that it doesn't use the full blown set of
seq operations, uses a different termination condition, and doesn't
displayed "Locked" as that was broken on the original implemenation.

This new proc file provides information faster than parsing the potentially
huge smaps file.

Signed-off-by: Sonny Rao 

Tested-by: Robert Foss 
Signed-off-by: Robert Foss 

---
 fs/proc/base.c |   1 +
 fs/proc/internal.h |   4 ++
 fs/proc/task_mmu.c | 126 +
 3 files changed, 131 insertions(+)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index a11eb71..de3acdf 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2855,6 +2855,7 @@ static const struct pid_entry tgid_base_stuff[] = {
REG("clear_refs", S_IWUSR, proc_clear_refs_operations),
REG("smaps",  S_IRUGO, proc_pid_smaps_operations),
REG("pagemap",S_IRUSR, proc_pagemap_operations),
+   REG("totmaps",S_IRUGO, proc_totmaps_operations),
 #endif
 #ifdef CONFIG_SECURITY
DIR("attr",   S_IRUGO|S_IXUGO, proc_attr_dir_inode_operations, 
proc_attr_dir_operations),
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index aa27810..6f3540f 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -58,6 +58,9 @@ union proc_op {
struct task_struct *task);
 };
 
+
+extern const struct file_operations proc_totmaps_operations;
+
 struct proc_inode {
struct pid *pid;
int fd;
@@ -281,6 +284,7 @@ struct proc_maps_private {
struct mm_struct *mm;
 #ifdef CONFIG_MMU
struct vm_area_struct *tail_vma;
+   struct mem_size_stats *mss;
 #endif
 #ifdef CONFIG_NUMA
struct mempolicy *task_mempolicy;
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 4648c7f..b61873e 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -802,6 +802,81 @@ static int show_smap(struct seq_file *m, void *v, int 
is_pid)
return 0;
 }
 
+static void add_smaps_sum(struct mem_size_stats *mss,
+   struct mem_size_stats *mss_sum)
+{
+   mss_sum->resident += mss->resident;
+   mss_sum->pss += mss->pss;
+   mss_sum->shared_clean += mss->shared_clean;
+   mss_sum->shared_dirty += mss->shared_dirty;
+   mss_sum->private_clean += mss->private_clean;
+   mss_sum->private_dirty += mss->private_dirty;
+   mss_sum->referenced += mss->referenced;
+   mss_sum->anonymous += mss->anonymous;
+   mss_sum->anonymous_thp += mss->anonymous_thp;
+   mss_sum->swap += mss->swap;
+}
+
+static int totmaps_proc_show(struct seq_file *m, void *data)
+{
+   struct proc_maps_private *priv = m->private;
+   struct mm_struct *mm;
+   struct vm_area_struct *vma;
+   struct mem_size_stats *mss_sum = priv->mss;
+
+   /* reference to priv->task already taken */
+   /* but need to get the mm here because */
+   /* task could be in the process of exiting */
+   mm = get_task_mm(priv->task);
+   if (!mm || IS_ERR(mm))
+   return -EINVAL;
+
+   down_read(>mmap_sem);
+   hold_task_mempolicy(priv);
+
+   for (vma = mm->mmap; vma != priv->tail_vma; vma = vma->vm_next) {
+   struct mem_size_stats mss;
+   struct mm_walk smaps_walk = {
+   .pmd_entry = smaps_pte_range,
+   .mm = vma->vm_mm,
+   .private = ,
+   };
+
+   if (vma->vm_mm && !is_vm_hugetlb_page(vma)) {
+   memset(, 0, sizeof(mss));
+   walk_page_vma(vma, _walk);
+   add_smaps_sum(, mss_sum);
+   }
+   }
+   seq_printf(m,
+  "Rss:%8lu kB\n"
+  "Pss:%8lu kB\n"
+  "Shared_Clean:   %8lu kB\n"
+  "Shared_Dirty:   %8lu kB\n"
+  "Private_Clean:  %8lu kB\n"
+  "Private_Dirty:  %8lu kB\n"
+  "Referenced: %8lu kB\n"
+  "Anonymous:  %8lu kB\n"
+  "AnonHugePages:  %8lu kB\n"
+  "Swap:   %8lu kB\n",
+  mss_sum->resident >> 10,
+  (unsigned long)(mss_sum->pss >> (10 + PSS_SHIFT)),
+  mss_sum->shared_clean  >> 10,
+  mss_sum->shared_dirty  >> 10,
+  mss_sum->private_clean >> 10,
+  mss_sum->private_dirty >> 10,
+  mss_sum->referenced >> 10,
+  mss_sum->anonymous >> 10,
+  mss_sum->anonymous_thp >> 10,
+  mss_sum->swap >> 10);
+
+   release_task_mempolicy(priv);
+   

[PATCH 01/11] perf script: Add 'bpf-output' field to usage message

[Arnaldo Carvalho de Melo]

From: Brendan Gregg 

This adds the 'bpf-output' field to the perf script usage message, and docs.

Signed-off-by: Brendan Gregg 
Cc: Alexander Shishkin 
Cc: Alexei Starovoitov 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1470192469-11910-4-git-send-email-bgr...@netflix.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-script.txt | 4 ++--
 tools/perf/builtin-script.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Documentation/perf-script.txt 
b/tools/perf/Documentation/perf-script.txt
index 1f6c70594f0f..053bbbd84ece 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -116,8 +116,8 @@ OPTIONS
 --fields::
 Comma separated list of fields to print. Options are:
 comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, symoff,
-   srcline, period, iregs, brstack, brstacksym, flags.
-Field list can be prepended with the type, trace, sw or hw,
+srcline, period, iregs, brstack, brstacksym, flags, bpf-output,
+callindent. 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 971ff91b16cb..9c640a8081c7 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -2116,7 +2116,7 @@ int cmd_script(int argc, const char **argv, const char 
*prefix __maybe_unused)
 "Valid types: hw,sw,trace,raw. "
 "Fields: comm,tid,pid,time,cpu,event,trace,ip,sym,dso,"
 "addr,symoff,period,iregs,brstack,brstacksym,flags,"
-"callindent", parse_output_fields),
+"bpf-output,callindent", parse_output_fields),
OPT_BOOLEAN('a', "all-cpus", _wide,
"system-wide collection from all CPUs"),
OPT_STRING('S', "symbols", _conf.sym_list_str, 
"symbol[,symbol...]",
-- 
2.7.4

[PATCH 09/11] tools: Sync cpufeatures headers with the kernel

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

Due to:

  1e61f78baf89 ("x86/cpufeature: Make sure DISABLED/REQUIRED macros are 
updated")

No changes to tools using those headers (tools/arch/x86/lib/mem{set,cpu}_64.S)
seems necessary.

Detected by the tools build header drift checker:

  $ make -C tools/perf O=/tmp/build/perf
  make: Entering directory '/home/acme/git/linux/tools/perf'
BUILD:   Doing 'make -j4' parallel build
GEN  /tmp/build/perf/common-cmds.h
  Warning: tools/arch/x86/include/asm/disabled-features.h differs from kernel
  Warning: tools/arch/x86/include/asm/required-features.h differs from kernel
  Warning: tools/arch/x86/include/asm/cpufeatures.h differs from kernel
CC   /tmp/build/perf/util/probe-finder.o
CC   /tmp/build/perf/builtin-help.o
  
  ^C$

Cc: Adrian Hunter 
Cc: Dave Hansen 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-ja75m7zk8j0jkzmrv16i5...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/arch/x86/include/asm/disabled-features.h | 2 ++
 tools/arch/x86/include/asm/required-features.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/tools/arch/x86/include/asm/disabled-features.h 
b/tools/arch/x86/include/asm/disabled-features.h
index 911e9358ceb1..85599ad4d024 100644
--- a/tools/arch/x86/include/asm/disabled-features.h
+++ b/tools/arch/x86/include/asm/disabled-features.h
@@ -56,5 +56,7 @@
 #define DISABLED_MASK140
 #define DISABLED_MASK150
 #define DISABLED_MASK16(DISABLE_PKU|DISABLE_OSPKE)
+#define DISABLED_MASK170
+#define DISABLED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 18)
 
 #endif /* _ASM_X86_DISABLED_FEATURES_H */
diff --git a/tools/arch/x86/include/asm/required-features.h 
b/tools/arch/x86/include/asm/required-features.h
index 4916144e3c42..fac9a5c0abe9 100644
--- a/tools/arch/x86/include/asm/required-features.h
+++ b/tools/arch/x86/include/asm/required-features.h
@@ -99,5 +99,7 @@
 #define REQUIRED_MASK140
 #define REQUIRED_MASK150
 #define REQUIRED_MASK160
+#define REQUIRED_MASK170
+#define REQUIRED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 18)
 
 #endif /* _ASM_X86_REQUIRED_FEATURES_H */
-- 
2.7.4

[PATCH 03/11] perf probe: Adjust map->reloc offset when finding kernel symbol from map

[Arnaldo Carvalho de Melo]

From: Masami Hiramatsu 

Adjust map->reloc offset for the unmapped address when finding
alternative symbol address from map, because KASLR can relocate the
kernel symbol address.

The same adjustment has been done when finding appropriate kernel symbol
address from map which was introduced by commit f90acac75713 ("perf
probe: Find given address from offline dwarf")

Reported-by: Arnaldo Carvalho de Melo 
Signed-off-by: Masami Hiramatsu 
Cc: Alexei Starovoitov 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/20160806192948.e366f3fbc4b194de600f8...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-event.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 953dc1ab2ed7..d5ccb656fd81 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -385,7 +385,7 @@ static int find_alternative_probe_point(struct debuginfo 
*dinfo,
if (uprobes)
address = sym->start;
else
-   address = map->unmap_ip(map, sym->start);
+   address = map->unmap_ip(map, sym->start) - map->reloc;
break;
}
if (!address) {
-- 
2.7.4

[PATCH 01/11] perf script: Add 'bpf-output' field to usage message

[Arnaldo Carvalho de Melo]

From: Brendan Gregg 

This adds the 'bpf-output' field to the perf script usage message, and docs.

Signed-off-by: Brendan Gregg 
Cc: Alexander Shishkin 
Cc: Alexei Starovoitov 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1470192469-11910-4-git-send-email-bgr...@netflix.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-script.txt | 4 ++--
 tools/perf/builtin-script.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Documentation/perf-script.txt 
b/tools/perf/Documentation/perf-script.txt
index 1f6c70594f0f..053bbbd84ece 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -116,8 +116,8 @@ OPTIONS
 --fields::
 Comma separated list of fields to print. Options are:
 comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, symoff,
-   srcline, period, iregs, brstack, brstacksym, flags.
-Field list can be prepended with the type, trace, sw or hw,
+srcline, period, iregs, brstack, brstacksym, flags, bpf-output,
+callindent. 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 971ff91b16cb..9c640a8081c7 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -2116,7 +2116,7 @@ int cmd_script(int argc, const char **argv, const char 
*prefix __maybe_unused)
 "Valid types: hw,sw,trace,raw. "
 "Fields: comm,tid,pid,time,cpu,event,trace,ip,sym,dso,"
 "addr,symoff,period,iregs,brstack,brstacksym,flags,"
-"callindent", parse_output_fields),
+"bpf-output,callindent", parse_output_fields),
OPT_BOOLEAN('a', "all-cpus", _wide,
"system-wide collection from all CPUs"),
OPT_STRING('S', "symbols", _conf.sym_list_str, 
"symbol[,symbol...]",
-- 
2.7.4

[PATCH 09/11] tools: Sync cpufeatures headers with the kernel

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

Due to:

  1e61f78baf89 ("x86/cpufeature: Make sure DISABLED/REQUIRED macros are 
updated")

No changes to tools using those headers (tools/arch/x86/lib/mem{set,cpu}_64.S)
seems necessary.

Detected by the tools build header drift checker:

  $ make -C tools/perf O=/tmp/build/perf
  make: Entering directory '/home/acme/git/linux/tools/perf'
BUILD:   Doing 'make -j4' parallel build
GEN  /tmp/build/perf/common-cmds.h
  Warning: tools/arch/x86/include/asm/disabled-features.h differs from kernel
  Warning: tools/arch/x86/include/asm/required-features.h differs from kernel
  Warning: tools/arch/x86/include/asm/cpufeatures.h differs from kernel
CC   /tmp/build/perf/util/probe-finder.o
CC   /tmp/build/perf/builtin-help.o
  
  ^C$

Cc: Adrian Hunter 
Cc: Dave Hansen 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-ja75m7zk8j0jkzmrv16i5...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/arch/x86/include/asm/disabled-features.h | 2 ++
 tools/arch/x86/include/asm/required-features.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/tools/arch/x86/include/asm/disabled-features.h 
b/tools/arch/x86/include/asm/disabled-features.h
index 911e9358ceb1..85599ad4d024 100644
--- a/tools/arch/x86/include/asm/disabled-features.h
+++ b/tools/arch/x86/include/asm/disabled-features.h
@@ -56,5 +56,7 @@
 #define DISABLED_MASK140
 #define DISABLED_MASK150
 #define DISABLED_MASK16(DISABLE_PKU|DISABLE_OSPKE)
+#define DISABLED_MASK170
+#define DISABLED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 18)
 
 #endif /* _ASM_X86_DISABLED_FEATURES_H */
diff --git a/tools/arch/x86/include/asm/required-features.h 
b/tools/arch/x86/include/asm/required-features.h
index 4916144e3c42..fac9a5c0abe9 100644
--- a/tools/arch/x86/include/asm/required-features.h
+++ b/tools/arch/x86/include/asm/required-features.h
@@ -99,5 +99,7 @@
 #define REQUIRED_MASK140
 #define REQUIRED_MASK150
 #define REQUIRED_MASK160
+#define REQUIRED_MASK170
+#define REQUIRED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 18)
 
 #endif /* _ASM_X86_REQUIRED_FEATURES_H */
-- 
2.7.4

[PATCH 03/11] perf probe: Adjust map->reloc offset when finding kernel symbol from map

[Arnaldo Carvalho de Melo]

From: Masami Hiramatsu 

Adjust map->reloc offset for the unmapped address when finding
alternative symbol address from map, because KASLR can relocate the
kernel symbol address.

The same adjustment has been done when finding appropriate kernel symbol
address from map which was introduced by commit f90acac75713 ("perf
probe: Find given address from offline dwarf")

Reported-by: Arnaldo Carvalho de Melo 
Signed-off-by: Masami Hiramatsu 
Cc: Alexei Starovoitov 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/20160806192948.e366f3fbc4b194de600f8...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-event.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 953dc1ab2ed7..d5ccb656fd81 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -385,7 +385,7 @@ static int find_alternative_probe_point(struct debuginfo 
*dinfo,
if (uprobes)
address = sym->start;
else
-   address = map->unmap_ip(map, sym->start);
+   address = map->unmap_ip(map, sym->start) - map->reloc;
break;
}
if (!address) {
-- 
2.7.4

[PATCH 08/11] toops: Sync tools/include/uapi/linux/bpf.h with the kernel

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

The way we're using kernel headers in tools/ now, with a copy that is
made to the same path prefixed by "tools/" plus checking if that copy
got stale, i.e. if the kernel counterpart changed, helps in keeping
track with new features that may be useful for tools to exploit.

For instance, looking at all the changes to bpf.h since it was last
copied to tools/include brings this to toolers' attention:

Need to investigate this one to check how to run a program via perf, setting up
a BPF event, that will take advantage of the way perf already calls clang/LLVM,
sets up the event and runs the workload in a single command line, helping in
debugging such semi cooperative programs:

  96ae52279594 ("bpf: Add bpf_probe_write_user BPF helper to be called in 
tracers")

This one needs further investigation about using the feature it improves
in 'perf trace' to do some tcpdumpin' mixed with syscalls, tracepoints,
probe points, callgraphs, etc:

  555c8a8623a3 ("bpf: avoid stack copy and use skb ctx for event output")

Add tracing just packets that are related to some container to that mix:

  4a482f34afcc ("cgroup: bpf: Add bpf_skb_in_cgroup_proto")
  4ed8ec521ed5 ("cgroup: bpf: Add BPF_MAP_TYPE_CGROUP_ARRAY")

Definetely needs to have example programs accessing task_struct from a bpf 
proggie
started from 'perf trace':

  606274c5abd8 ("bpf: introduce bpf_get_current_task() helper")

Core networking related, XDP:

  6ce96ca348a9 ("bpf: add XDP_TX xdp_action for direct forwarding")
  6a773a15a1e8 ("bpf: add XDP prog type for early driver filter")
  13c5c240f789 ("bpf: add bpf_get_hash_recalc helper")
  d2485c4242a8 ("bpf: add bpf_skb_change_type helper")
  6578171a7ff0 ("bpf: add bpf_skb_change_proto helper")

Changes detected by the tools build system:

  $ make -C tools/perf O=/tmp/build/perf install-bin
  make: Entering directory '/home/acme/git/linux/tools/perf'
BUILD:   Doing 'make -j4' parallel build
  Warning: tools/include/uapi/linux/bpf.h differs from kernel
INSTALL  GTK UI
CC   /tmp/build/perf/bench/mem-memcpy-x86-64-asm.o
  
  $

Cc: Adrian Hunter 
Cc: Alexei Starovoitov 
Cc: Brenden Blanco 
Cc: Daniel Borkmann 
Cc: David Ahern 
Cc: David S. Miller 
Cc: Jiri Olsa 
Cc: Martin KaFai Lau 
Cc: Namhyung Kim 
Cc: Sargun Dhillon 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-difq4ts1xvww6eyfs9e7z...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/include/uapi/linux/bpf.h | 86 +-
 1 file changed, 85 insertions(+), 1 deletion(-)

diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 406459b935a2..da218fec6056 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -84,6 +84,7 @@ enum bpf_map_type {
BPF_MAP_TYPE_PERCPU_HASH,
BPF_MAP_TYPE_PERCPU_ARRAY,
BPF_MAP_TYPE_STACK_TRACE,
+   BPF_MAP_TYPE_CGROUP_ARRAY,
 };
 
 enum bpf_prog_type {
@@ -93,6 +94,7 @@ enum bpf_prog_type {
BPF_PROG_TYPE_SCHED_CLS,
BPF_PROG_TYPE_SCHED_ACT,
BPF_PROG_TYPE_TRACEPOINT,
+   BPF_PROG_TYPE_XDP,
 };
 
 #define BPF_PSEUDO_MAP_FD  1
@@ -313,6 +315,66 @@ enum bpf_func_id {
 */
BPF_FUNC_skb_get_tunnel_opt,
BPF_FUNC_skb_set_tunnel_opt,
+
+   /**
+* bpf_skb_change_proto(skb, proto, flags)
+* Change protocol of the skb. Currently supported is
+* v4 -> v6, v6 -> v4 transitions. The helper will also
+* resize the skb. eBPF program is expected to fill the
+* new headers via skb_store_bytes and lX_csum_replace.
+* @skb: pointer to skb
+* @proto: new skb->protocol type
+* @flags: reserved
+* Return: 0 on success or negative error
+*/
+   BPF_FUNC_skb_change_proto,
+
+   /**
+* bpf_skb_change_type(skb, type)
+* Change packet type of skb.
+* @skb: pointer to skb
+* @type: new skb->pkt_type type
+* Return: 0 on success or negative error
+*/
+   BPF_FUNC_skb_change_type,
+
+   /**
+* bpf_skb_in_cgroup(skb, map, index) - Check cgroup2 membership of skb
+* @skb: pointer to skb
+* @map: pointer to bpf_map in BPF_MAP_TYPE_CGROUP_ARRAY type
+* @index: index of the cgroup in the bpf_map
+* Return:
+*   == 0 skb failed the cgroup2 descendant test
+*   == 1 skb succeeded the cgroup2 descendant test
+*< 0 error
+*/
+   BPF_FUNC_skb_in_cgroup,
+
+   /**
+* bpf_get_hash_recalc(skb)
+* Retrieve and possibly recalculate skb->hash.
+* @skb: pointer to skb
+* Return: hash
+*/
+   BPF_FUNC_get_hash_recalc,
+
+ 

[PATCH 11/11] perf probe ppc64le: Fix probe location when using DWARF

[Arnaldo Carvalho de Melo]

From: Ravi Bangoria 

Powerpc has Global Entry Point and Local Entry Point for functions.  LEP
catches call from both the GEP and the LEP. Symbol table of ELF contains
GEP and Offset from which we can calculate LEP, but debuginfo does not
have LEP info.

Currently, perf prioritize symbol table over dwarf to probe on LEP for
ppc64le. But when user tries to probe with function parameter, we fall
back to using dwarf(i.e. GEP) and when function called via LEP, probe
will never hit.

For example:

  $ objdump -d vmlinux
...
do_sys_open():
c02eb4a0:   e8 00 4c 3c addis   r2,r12,232
c02eb4a4:   60 00 42 38 addir2,r2,96
c02eb4a8:   a6 02 08 7c mflrr0
c02eb4ac:   d0 ff 41 fb std r26,-48(r1)

  $ sudo ./perf probe do_sys_open
  $ sudo cat /sys/kernel/debug/tracing/kprobe_events
p:probe/do_sys_open _text+3060904

  $ sudo ./perf probe 'do_sys_open filename:string'
  $ sudo cat /sys/kernel/debug/tracing/kprobe_events
p:probe/do_sys_open _text+3060896 filename_string=+0(%gpr4):string

For second case, perf probed on GEP. So when function will be called via
LEP, probe won't hit.

  $ sudo ./perf record -a -e probe:do_sys_open ls
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.195 MB perf.data ]

To resolve this issue, let's not prioritize symbol table, let perf
decide what it wants to use. Perf is already converting GEP to LEP when
it uses symbol table. When perf uses debuginfo, let it find LEP offset
form symbol table. This way we fall back to probe on LEP for all cases.

After patch:

  $ sudo ./perf probe 'do_sys_open filename:string'
  $ sudo cat /sys/kernel/debug/tracing/kprobe_events
p:probe/do_sys_open _text+3060904 filename_string=+0(%gpr4):string

  $ sudo ./perf record -a -e probe:do_sys_open ls
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.197 MB perf.data (11 samples) ]

Signed-off-by: Ravi Bangoria 
Acked-by: Masami Hiramatsu 
Cc: Alexander Shishkin 
Cc: Ananth N Mavinakayanahalli 
Cc: Balbir Singh 
Cc: Namhyung Kim 
Cc: Naveen N. Rao 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1470723805-5081-2-git-send-email-ravi.bango...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/powerpc/util/sym-handling.c | 27 +
 tools/perf/util/probe-event.c   | 37 -
 tools/perf/util/probe-event.h   |  6 -
 3 files changed, 49 insertions(+), 21 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index c6d0f91731a1..8d4dc97d80ba 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -54,10 +54,6 @@ int arch__compare_symbol_names(const char *namea, const char 
*nameb)
 #endif
 
 #if defined(_CALL_ELF) && _CALL_ELF == 2
-bool arch__prefers_symtab(void)
-{
-   return true;
-}
 
 #ifdef HAVE_LIBELF_SUPPORT
 void arch__sym_update(struct symbol *s, GElf_Sym *sym)
@@ -100,4 +96,27 @@ void arch__fix_tev_from_maps(struct perf_probe_event *pev,
tev->point.offset += lep_offset;
}
 }
+
+void arch__post_process_probe_trace_events(struct perf_probe_event *pev,
+  int ntevs)
+{
+   struct probe_trace_event *tev;
+   struct map *map;
+   struct symbol *sym = NULL;
+   struct rb_node *tmp;
+   int i = 0;
+
+   map = get_target_map(pev->target, pev->uprobes);
+   if (!map || map__load(map, NULL) < 0)
+   return;
+
+   for (i = 0; i < ntevs; i++) {
+   tev = >tevs[i];
+   map__for_each_symbol(map, sym, tmp) {
+   if (map->unmap_ip(map, sym->start) == 
tev->point.address)
+   arch__fix_tev_from_maps(pev, tev, map, sym);
+   }
+   }
+}
+
 #endif
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 234fbfb5c2ed..28733962cd80 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -180,7 +180,7 @@ static struct map *kernel_get_module_map(const char *module)
return NULL;
 }
 
-static struct map *get_target_map(const char *target, bool user)
+struct map *get_target_map(const char *target, bool user)
 {
/* Init maps of given executable or kernel */
if (user)
@@ -705,19 +705,32 @@ post_process_kernel_probe_trace_events(struct 
probe_trace_event *tevs,
return skipped;
 }
 
+void __weak
+arch__post_process_probe_trace_events(struct perf_probe_event 

[PATCH 10/11] perf probe: Add function to post process kernel trace events

[Arnaldo Carvalho de Melo]

From: Ravi Bangoria 

Instead of inline code, introduce function to post process kernel
probe trace events.

Signed-off-by: Ravi Bangoria 
Acked-by: Masami Hiramatsu 
Cc: Alexander Shishkin 
Cc: Ananth N Mavinakayanahalli 
Cc: Balbir Singh 
Cc: Namhyung Kim 
Cc: Naveen N. Rao 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1470723805-5081-1-git-send-email-ravi.bango...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-event.c | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 1201f73ca723..234fbfb5c2ed 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -666,22 +666,14 @@ static int add_module_to_probe_trace_events(struct 
probe_trace_event *tevs,
return ret;
 }
 
-/* Post processing the probe events */
-static int post_process_probe_trace_events(struct probe_trace_event *tevs,
-  int ntevs, const char *module,
-  bool uprobe)
+static int
+post_process_kernel_probe_trace_events(struct probe_trace_event *tevs,
+  int ntevs)
 {
struct ref_reloc_sym *reloc_sym;
char *tmp;
int i, skipped = 0;
 
-   if (uprobe)
-   return add_exec_to_probe_trace_events(tevs, ntevs, module);
-
-   /* Note that currently ref_reloc_sym based probe is not for drivers */
-   if (module)
-   return add_module_to_probe_trace_events(tevs, ntevs, module);
-
reloc_sym = kernel_get_ref_reloc_sym();
if (!reloc_sym) {
pr_warning("Relocated base symbol is not found!\n");
@@ -713,6 +705,21 @@ static int post_process_probe_trace_events(struct 
probe_trace_event *tevs,
return skipped;
 }
 
+/* Post processing the probe events */
+static int post_process_probe_trace_events(struct probe_trace_event *tevs,
+  int ntevs, const char *module,
+  bool uprobe)
+{
+   if (uprobe)
+   return add_exec_to_probe_trace_events(tevs, ntevs, module);
+
+   if (module)
+   /* Currently ref_reloc_sym based probe is not for drivers */
+   return add_module_to_probe_trace_events(tevs, ntevs, module);
+
+   return post_process_kernel_probe_trace_events(tevs, ntevs);
+}
+
 /* Try to find perf_probe_event with debuginfo */
 static int try_to_find_probe_trace_events(struct perf_probe_event *pev,
  struct probe_trace_event **tevs)
-- 
2.7.4

[PATCH 02/11] perf hists: Trim libtraceevent trace_seq buffers

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

When we use libtraceevent to format trace event fields into printable
strings to use in hist entries it is important to trim it from the
default 4 KiB it starts with to what is really used, to reduce the
memory footprint, so use realloc(seq.buffer, seq.len + 1) when returning
the seq.buffer formatted with the fields contents.

Reported-and-Tested-by: Wang Nan 
Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: http://lkml.kernel.org/n/tip-t3hl7uxmilrkigzmc90rl...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/sort.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 947d21f38398..3d3cb8392c86 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -588,7 +588,11 @@ static char *get_trace_output(struct hist_entry *he)
} else {
pevent_event_info(, evsel->tp_format, );
}
-   return seq.buffer;
+   /*
+* Trim the buffer, it starts at 4KB and we're not going to
+* add anything more to this buffer.
+*/
+   return realloc(seq.buffer, seq.len + 1);
 }
 
 static int64_t
-- 
2.7.4

[PATCH 05/11] perf stat: Avoid skew when reading events

[Arnaldo Carvalho de Melo]

From: Mark Rutland 

When we don't have a tracee (i.e. we're attaching to a task or CPU),
counters can still be running after our workload finishes, and can still
be running as we read their values. As we read events one-by-one, there
can be arbitrary skew between values of events, even within a group.
This means that ratios within an event group are not reliable.

This skew can be seen if measuring a group of identical events, e.g:

  # perf stat -a -C0 -e '{cycles,cycles}' sleep 1

To avoid this, we must stop groups from counting before we read the
values of any constituent events. This patch adds and makes use of a new
disable_counters() helper, which disables group leaders (and thus each
group as a whole). This mirrors the use of enable_counters() for
starting event groups in the absence of a tracee.

Closing a group leader splits the group, and without a disabled group
leader the newly split events will begin counting. Thus to ensure counts
are reliable we must defer closing group leaders until all counts have
been read. To do so this patch removes the event closing logic from the
read_counters() helper, explicitly closes the events using
perf_evlist__close(), which also aids legibility.

Signed-off-by: Mark Rutland 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1470747869-3567-1-git-send-email-mark.rutl...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-stat.c | 31 +++
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 0c16d20d7e32..3c7452b39f57 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -331,7 +331,7 @@ static int read_counter(struct perf_evsel *counter)
return 0;
 }
 
-static void read_counters(bool close_counters)
+static void read_counters(void)
 {
struct perf_evsel *counter;
 
@@ -341,11 +341,6 @@ static void read_counters(bool close_counters)
 
if (perf_stat_process_counter(_config, counter))
pr_warning("failed to process counter %s\n", 
counter->name);
-
-   if (close_counters) {
-   perf_evsel__close_fd(counter, 
perf_evsel__nr_cpus(counter),
-
thread_map__nr(evsel_list->threads));
-   }
}
 }
 
@@ -353,7 +348,7 @@ static void process_interval(void)
 {
struct timespec ts, rs;
 
-   read_counters(false);
+   read_counters();
 
clock_gettime(CLOCK_MONOTONIC, );
diff_timespec(, , _time);
@@ -380,6 +375,17 @@ static void enable_counters(void)
perf_evlist__enable(evsel_list);
 }
 
+static void disable_counters(void)
+{
+   /*
+* If we don't have tracee (attaching to task or cpu), counters may
+* still be running. To get accurate group ratios, we must stop groups
+* from counting before reading their constituent counters.
+*/
+   if (!target__none())
+   perf_evlist__disable(evsel_list);
+}
+
 static volatile int workload_exec_errno;
 
 /*
@@ -657,11 +663,20 @@ try_again:
}
}
 
+   disable_counters();
+
t1 = rdclock();
 
update_stats(_nsecs_stats, t1 - t0);
 
-   read_counters(true);
+   /*
+* Closing a group leader splits the group, and as we only disable
+* group leaders, results in remaining events becoming enabled. To
+* avoid arbitrary skew, we must read all counters before closing any
+* group leaders.
+*/
+   read_counters();
+   perf_evlist__close(evsel_list);
 
return WEXITSTATUS(status);
 }
-- 
2.7.4

Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

[Joerg Roedel]

On Tue, Aug 09, 2016 at 09:00:04AM -0700, Thomas Garnier wrote:
> On Mon, Aug 8, 2016 at 11:40 AM, Thomas Garnier  wrote:
> > Initialize KASLR memory randomization after max_pfn is initialized. Also
> > ensure the size is rounded up. Could have create problems on machines
> > with more than 1Tb of memory on certain random addresses.
> >
> > Signed-off-by: Thomas Garnier 
> 
> I will send a new version of this PATCH soon. The test bot found
> places where virtual addresses were computed before PAGE_OFFSET was
> set. I will investigate that.

When you do that, please also add 'Fixes:' tags to your patches.

Thanks,

Joerg

[PATCH 11/11] perf probe ppc64le: Fix probe location when using DWARF

[Arnaldo Carvalho de Melo]

From: Ravi Bangoria 

Powerpc has Global Entry Point and Local Entry Point for functions.  LEP
catches call from both the GEP and the LEP. Symbol table of ELF contains
GEP and Offset from which we can calculate LEP, but debuginfo does not
have LEP info.

Currently, perf prioritize symbol table over dwarf to probe on LEP for
ppc64le. But when user tries to probe with function parameter, we fall
back to using dwarf(i.e. GEP) and when function called via LEP, probe
will never hit.

For example:

  $ objdump -d vmlinux
...
do_sys_open():
c02eb4a0:   e8 00 4c 3c addis   r2,r12,232
c02eb4a4:   60 00 42 38 addir2,r2,96
c02eb4a8:   a6 02 08 7c mflrr0
c02eb4ac:   d0 ff 41 fb std r26,-48(r1)

  $ sudo ./perf probe do_sys_open
  $ sudo cat /sys/kernel/debug/tracing/kprobe_events
p:probe/do_sys_open _text+3060904

  $ sudo ./perf probe 'do_sys_open filename:string'
  $ sudo cat /sys/kernel/debug/tracing/kprobe_events
p:probe/do_sys_open _text+3060896 filename_string=+0(%gpr4):string

For second case, perf probed on GEP. So when function will be called via
LEP, probe won't hit.

  $ sudo ./perf record -a -e probe:do_sys_open ls
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.195 MB perf.data ]

To resolve this issue, let's not prioritize symbol table, let perf
decide what it wants to use. Perf is already converting GEP to LEP when
it uses symbol table. When perf uses debuginfo, let it find LEP offset
form symbol table. This way we fall back to probe on LEP for all cases.

After patch:

  $ sudo ./perf probe 'do_sys_open filename:string'
  $ sudo cat /sys/kernel/debug/tracing/kprobe_events
p:probe/do_sys_open _text+3060904 filename_string=+0(%gpr4):string

  $ sudo ./perf record -a -e probe:do_sys_open ls
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.197 MB perf.data (11 samples) ]

Signed-off-by: Ravi Bangoria 
Acked-by: Masami Hiramatsu 
Cc: Alexander Shishkin 
Cc: Ananth N Mavinakayanahalli 
Cc: Balbir Singh 
Cc: Namhyung Kim 
Cc: Naveen N. Rao 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1470723805-5081-2-git-send-email-ravi.bango...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/powerpc/util/sym-handling.c | 27 +
 tools/perf/util/probe-event.c   | 37 -
 tools/perf/util/probe-event.h   |  6 -
 3 files changed, 49 insertions(+), 21 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index c6d0f91731a1..8d4dc97d80ba 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -54,10 +54,6 @@ int arch__compare_symbol_names(const char *namea, const char 
*nameb)
 #endif
 
 #if defined(_CALL_ELF) && _CALL_ELF == 2
-bool arch__prefers_symtab(void)
-{
-   return true;
-}
 
 #ifdef HAVE_LIBELF_SUPPORT
 void arch__sym_update(struct symbol *s, GElf_Sym *sym)
@@ -100,4 +96,27 @@ void arch__fix_tev_from_maps(struct perf_probe_event *pev,
tev->point.offset += lep_offset;
}
 }
+
+void arch__post_process_probe_trace_events(struct perf_probe_event *pev,
+  int ntevs)
+{
+   struct probe_trace_event *tev;
+   struct map *map;
+   struct symbol *sym = NULL;
+   struct rb_node *tmp;
+   int i = 0;
+
+   map = get_target_map(pev->target, pev->uprobes);
+   if (!map || map__load(map, NULL) < 0)
+   return;
+
+   for (i = 0; i < ntevs; i++) {
+   tev = >tevs[i];
+   map__for_each_symbol(map, sym, tmp) {
+   if (map->unmap_ip(map, sym->start) == 
tev->point.address)
+   arch__fix_tev_from_maps(pev, tev, map, sym);
+   }
+   }
+}
+
 #endif
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 234fbfb5c2ed..28733962cd80 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -180,7 +180,7 @@ static struct map *kernel_get_module_map(const char *module)
return NULL;
 }
 
-static struct map *get_target_map(const char *target, bool user)
+struct map *get_target_map(const char *target, bool user)
 {
/* Init maps of given executable or kernel */
if (user)
@@ -705,19 +705,32 @@ post_process_kernel_probe_trace_events(struct 
probe_trace_event *tevs,
return skipped;
 }
 
+void __weak
+arch__post_process_probe_trace_events(struct perf_probe_event *pev 
__maybe_unused,
+ int ntevs __maybe_unused)
+{
+}
+
 /* Post processing the probe events */
-static int post_process_probe_trace_events(struct probe_trace_event *tevs,
+static int post_process_probe_trace_events(struct perf_probe_event 

[PATCH 10/11] perf probe: Add function to post process kernel trace events

[Arnaldo Carvalho de Melo]

From: Ravi Bangoria 

Instead of inline code, introduce function to post process kernel
probe trace events.

Signed-off-by: Ravi Bangoria 
Acked-by: Masami Hiramatsu 
Cc: Alexander Shishkin 
Cc: Ananth N Mavinakayanahalli 
Cc: Balbir Singh 
Cc: Namhyung Kim 
Cc: Naveen N. Rao 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1470723805-5081-1-git-send-email-ravi.bango...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-event.c | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 1201f73ca723..234fbfb5c2ed 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -666,22 +666,14 @@ static int add_module_to_probe_trace_events(struct 
probe_trace_event *tevs,
return ret;
 }
 
-/* Post processing the probe events */
-static int post_process_probe_trace_events(struct probe_trace_event *tevs,
-  int ntevs, const char *module,
-  bool uprobe)
+static int
+post_process_kernel_probe_trace_events(struct probe_trace_event *tevs,
+  int ntevs)
 {
struct ref_reloc_sym *reloc_sym;
char *tmp;
int i, skipped = 0;
 
-   if (uprobe)
-   return add_exec_to_probe_trace_events(tevs, ntevs, module);
-
-   /* Note that currently ref_reloc_sym based probe is not for drivers */
-   if (module)
-   return add_module_to_probe_trace_events(tevs, ntevs, module);
-
reloc_sym = kernel_get_ref_reloc_sym();
if (!reloc_sym) {
pr_warning("Relocated base symbol is not found!\n");
@@ -713,6 +705,21 @@ static int post_process_probe_trace_events(struct 
probe_trace_event *tevs,
return skipped;
 }
 
+/* Post processing the probe events */
+static int post_process_probe_trace_events(struct probe_trace_event *tevs,
+  int ntevs, const char *module,
+  bool uprobe)
+{
+   if (uprobe)
+   return add_exec_to_probe_trace_events(tevs, ntevs, module);
+
+   if (module)
+   /* Currently ref_reloc_sym based probe is not for drivers */
+   return add_module_to_probe_trace_events(tevs, ntevs, module);
+
+   return post_process_kernel_probe_trace_events(tevs, ntevs);
+}
+
 /* Try to find perf_probe_event with debuginfo */
 static int try_to_find_probe_trace_events(struct perf_probe_event *pev,
  struct probe_trace_event **tevs)
-- 
2.7.4

[PATCH 02/11] perf hists: Trim libtraceevent trace_seq buffers

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

When we use libtraceevent to format trace event fields into printable
strings to use in hist entries it is important to trim it from the
default 4 KiB it starts with to what is really used, to reduce the
memory footprint, so use realloc(seq.buffer, seq.len + 1) when returning
the seq.buffer formatted with the fields contents.

Reported-and-Tested-by: Wang Nan 
Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: http://lkml.kernel.org/n/tip-t3hl7uxmilrkigzmc90rl...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/sort.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 947d21f38398..3d3cb8392c86 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -588,7 +588,11 @@ static char *get_trace_output(struct hist_entry *he)
} else {
pevent_event_info(, evsel->tp_format, );
}
-   return seq.buffer;
+   /*
+* Trim the buffer, it starts at 4KB and we're not going to
+* add anything more to this buffer.
+*/
+   return realloc(seq.buffer, seq.len + 1);
 }
 
 static int64_t
-- 
2.7.4

[PATCH 05/11] perf stat: Avoid skew when reading events

[Arnaldo Carvalho de Melo]

From: Mark Rutland 

When we don't have a tracee (i.e. we're attaching to a task or CPU),
counters can still be running after our workload finishes, and can still
be running as we read their values. As we read events one-by-one, there
can be arbitrary skew between values of events, even within a group.
This means that ratios within an event group are not reliable.

This skew can be seen if measuring a group of identical events, e.g:

  # perf stat -a -C0 -e '{cycles,cycles}' sleep 1

To avoid this, we must stop groups from counting before we read the
values of any constituent events. This patch adds and makes use of a new
disable_counters() helper, which disables group leaders (and thus each
group as a whole). This mirrors the use of enable_counters() for
starting event groups in the absence of a tracee.

Closing a group leader splits the group, and without a disabled group
leader the newly split events will begin counting. Thus to ensure counts
are reliable we must defer closing group leaders until all counts have
been read. To do so this patch removes the event closing logic from the
read_counters() helper, explicitly closes the events using
perf_evlist__close(), which also aids legibility.

Signed-off-by: Mark Rutland 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1470747869-3567-1-git-send-email-mark.rutl...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-stat.c | 31 +++
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 0c16d20d7e32..3c7452b39f57 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -331,7 +331,7 @@ static int read_counter(struct perf_evsel *counter)
return 0;
 }
 
-static void read_counters(bool close_counters)
+static void read_counters(void)
 {
struct perf_evsel *counter;
 
@@ -341,11 +341,6 @@ static void read_counters(bool close_counters)
 
if (perf_stat_process_counter(_config, counter))
pr_warning("failed to process counter %s\n", 
counter->name);
-
-   if (close_counters) {
-   perf_evsel__close_fd(counter, 
perf_evsel__nr_cpus(counter),
-
thread_map__nr(evsel_list->threads));
-   }
}
 }
 
@@ -353,7 +348,7 @@ static void process_interval(void)
 {
struct timespec ts, rs;
 
-   read_counters(false);
+   read_counters();
 
clock_gettime(CLOCK_MONOTONIC, );
diff_timespec(, , _time);
@@ -380,6 +375,17 @@ static void enable_counters(void)
perf_evlist__enable(evsel_list);
 }
 
+static void disable_counters(void)
+{
+   /*
+* If we don't have tracee (attaching to task or cpu), counters may
+* still be running. To get accurate group ratios, we must stop groups
+* from counting before reading their constituent counters.
+*/
+   if (!target__none())
+   perf_evlist__disable(evsel_list);
+}
+
 static volatile int workload_exec_errno;
 
 /*
@@ -657,11 +663,20 @@ try_again:
}
}
 
+   disable_counters();
+
t1 = rdclock();
 
update_stats(_nsecs_stats, t1 - t0);
 
-   read_counters(true);
+   /*
+* Closing a group leader splits the group, and as we only disable
+* group leaders, results in remaining events becoming enabled. To
+* avoid arbitrary skew, we must read all counters before closing any
+* group leaders.
+*/
+   read_counters();
+   perf_evlist__close(evsel_list);
 
return WEXITSTATUS(status);
 }
-- 
2.7.4

Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

[Joerg Roedel]

On Tue, Aug 09, 2016 at 09:00:04AM -0700, Thomas Garnier wrote:
> On Mon, Aug 8, 2016 at 11:40 AM, Thomas Garnier  wrote:
> > Initialize KASLR memory randomization after max_pfn is initialized. Also
> > ensure the size is rounded up. Could have create problems on machines
> > with more than 1Tb of memory on certain random addresses.
> >
> > Signed-off-by: Thomas Garnier 
> 
> I will send a new version of this PATCH soon. The test bot found
> places where virtual addresses were computed before PAGE_OFFSET was
> set. I will investigate that.

When you do that, please also add 'Fixes:' tags to your patches.

Thanks,

Joerg

[PATCH 08/11] toops: Sync tools/include/uapi/linux/bpf.h with the kernel

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

The way we're using kernel headers in tools/ now, with a copy that is
made to the same path prefixed by "tools/" plus checking if that copy
got stale, i.e. if the kernel counterpart changed, helps in keeping
track with new features that may be useful for tools to exploit.

For instance, looking at all the changes to bpf.h since it was last
copied to tools/include brings this to toolers' attention:

Need to investigate this one to check how to run a program via perf, setting up
a BPF event, that will take advantage of the way perf already calls clang/LLVM,
sets up the event and runs the workload in a single command line, helping in
debugging such semi cooperative programs:

  96ae52279594 ("bpf: Add bpf_probe_write_user BPF helper to be called in 
tracers")

This one needs further investigation about using the feature it improves
in 'perf trace' to do some tcpdumpin' mixed with syscalls, tracepoints,
probe points, callgraphs, etc:

  555c8a8623a3 ("bpf: avoid stack copy and use skb ctx for event output")

Add tracing just packets that are related to some container to that mix:

  4a482f34afcc ("cgroup: bpf: Add bpf_skb_in_cgroup_proto")
  4ed8ec521ed5 ("cgroup: bpf: Add BPF_MAP_TYPE_CGROUP_ARRAY")

Definetely needs to have example programs accessing task_struct from a bpf 
proggie
started from 'perf trace':

  606274c5abd8 ("bpf: introduce bpf_get_current_task() helper")

Core networking related, XDP:

  6ce96ca348a9 ("bpf: add XDP_TX xdp_action for direct forwarding")
  6a773a15a1e8 ("bpf: add XDP prog type for early driver filter")
  13c5c240f789 ("bpf: add bpf_get_hash_recalc helper")
  d2485c4242a8 ("bpf: add bpf_skb_change_type helper")
  6578171a7ff0 ("bpf: add bpf_skb_change_proto helper")

Changes detected by the tools build system:

  $ make -C tools/perf O=/tmp/build/perf install-bin
  make: Entering directory '/home/acme/git/linux/tools/perf'
BUILD:   Doing 'make -j4' parallel build
  Warning: tools/include/uapi/linux/bpf.h differs from kernel
INSTALL  GTK UI
CC   /tmp/build/perf/bench/mem-memcpy-x86-64-asm.o
  
  $

Cc: Adrian Hunter 
Cc: Alexei Starovoitov 
Cc: Brenden Blanco 
Cc: Daniel Borkmann 
Cc: David Ahern 
Cc: David S. Miller 
Cc: Jiri Olsa 
Cc: Martin KaFai Lau 
Cc: Namhyung Kim 
Cc: Sargun Dhillon 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-difq4ts1xvww6eyfs9e7z...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/include/uapi/linux/bpf.h | 86 +-
 1 file changed, 85 insertions(+), 1 deletion(-)

diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 406459b935a2..da218fec6056 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -84,6 +84,7 @@ enum bpf_map_type {
BPF_MAP_TYPE_PERCPU_HASH,
BPF_MAP_TYPE_PERCPU_ARRAY,
BPF_MAP_TYPE_STACK_TRACE,
+   BPF_MAP_TYPE_CGROUP_ARRAY,
 };
 
 enum bpf_prog_type {
@@ -93,6 +94,7 @@ enum bpf_prog_type {
BPF_PROG_TYPE_SCHED_CLS,
BPF_PROG_TYPE_SCHED_ACT,
BPF_PROG_TYPE_TRACEPOINT,
+   BPF_PROG_TYPE_XDP,
 };
 
 #define BPF_PSEUDO_MAP_FD  1
@@ -313,6 +315,66 @@ enum bpf_func_id {
 */
BPF_FUNC_skb_get_tunnel_opt,
BPF_FUNC_skb_set_tunnel_opt,
+
+   /**
+* bpf_skb_change_proto(skb, proto, flags)
+* Change protocol of the skb. Currently supported is
+* v4 -> v6, v6 -> v4 transitions. The helper will also
+* resize the skb. eBPF program is expected to fill the
+* new headers via skb_store_bytes and lX_csum_replace.
+* @skb: pointer to skb
+* @proto: new skb->protocol type
+* @flags: reserved
+* Return: 0 on success or negative error
+*/
+   BPF_FUNC_skb_change_proto,
+
+   /**
+* bpf_skb_change_type(skb, type)
+* Change packet type of skb.
+* @skb: pointer to skb
+* @type: new skb->pkt_type type
+* Return: 0 on success or negative error
+*/
+   BPF_FUNC_skb_change_type,
+
+   /**
+* bpf_skb_in_cgroup(skb, map, index) - Check cgroup2 membership of skb
+* @skb: pointer to skb
+* @map: pointer to bpf_map in BPF_MAP_TYPE_CGROUP_ARRAY type
+* @index: index of the cgroup in the bpf_map
+* Return:
+*   == 0 skb failed the cgroup2 descendant test
+*   == 1 skb succeeded the cgroup2 descendant test
+*< 0 error
+*/
+   BPF_FUNC_skb_in_cgroup,
+
+   /**
+* bpf_get_hash_recalc(skb)
+* Retrieve and possibly recalculate skb->hash.
+* @skb: pointer to skb
+* Return: hash
+*/
+   BPF_FUNC_get_hash_recalc,
+
+   /**
+* u64 bpf_get_current_task(void)
+* Returns current task_struct
+* Return: current
+*/
+   BPF_FUNC_get_current_task,
+
+   /**
+* bpf_probe_write_user(void *dst, void *src, int len)
+

[PATCH 07/11] tools: Sync cpufeatures.h and vmx.h with the kernel

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

There were changes related to the deprecation of the "pcommit"
instruction:

  fd1d961dd681 ("x86/insn: remove pcommit")
  dfa169bbee00 ("Revert "KVM: x86: add pcommit support"")

No need to update anything in the tools, as "pcommit" wasn't being
listed on the VMX_EXIT_REASONS in the tools/perf/arch/x86/util/kvm-stat.c
file.

Just grab fresh copies of these files to silence the file cache
coherency detector:

  $ make -C tools/perf O=/tmp/build/perf install-bin
  make: Entering directory '/home/acme/git/linux/tools/perf'
BUILD:   Doing 'make -j4' parallel build
  Warning: tools/arch/x86/include/asm/cpufeatures.h differs from kernel
  Warning: tools/arch/x86/include/uapi/asm/vmx.h differs from kernel
INSTALL  GTK UI
  
  #

Cc: Adrian Hunter 
Cc: Dan Williams 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paolo Bonzini 
Cc: Ross Zwisler 
Cc: Wang Nan 
Cc: Xiao Guangrong 
Link: http://lkml.kernel.org/n/tip-07pmcc1ysydhyyxbmp1vt...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/arch/x86/include/asm/cpufeatures.h | 9 +++--
 tools/arch/x86/include/uapi/asm/vmx.h| 4 +---
 2 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/tools/arch/x86/include/asm/cpufeatures.h 
b/tools/arch/x86/include/asm/cpufeatures.h
index 4a413485f9eb..92a8308b96f6 100644
--- a/tools/arch/x86/include/asm/cpufeatures.h
+++ b/tools/arch/x86/include/asm/cpufeatures.h
@@ -225,7 +225,6 @@
 #define X86_FEATURE_RDSEED ( 9*32+18) /* The RDSEED instruction */
 #define X86_FEATURE_ADX( 9*32+19) /* The ADCX and ADOX 
instructions */
 #define X86_FEATURE_SMAP   ( 9*32+20) /* Supervisor Mode Access Prevention 
*/
-#define X86_FEATURE_PCOMMIT( 9*32+22) /* PCOMMIT instruction */
 #define X86_FEATURE_CLFLUSHOPT ( 9*32+23) /* CLFLUSHOPT instruction */
 #define X86_FEATURE_CLWB   ( 9*32+24) /* CLWB instruction */
 #define X86_FEATURE_AVX512PF   ( 9*32+26) /* AVX-512 Prefetch */
@@ -301,10 +300,6 @@
 #define X86_BUG_FXSAVE_LEAKX86_BUG(6) /* FXSAVE leaks FOP/FIP/FOP */
 #define X86_BUG_CLFLUSH_MONITORX86_BUG(7) /* AAI65, CLFLUSH required 
before MONITOR */
 #define X86_BUG_SYSRET_SS_ATTRSX86_BUG(8) /* SYSRET doesn't fix up SS 
attrs */
-#define X86_BUG_NULL_SEG   X86_BUG(9) /* Nulling a selector preserves the 
base */
-#define X86_BUG_SWAPGS_FENCE   X86_BUG(10) /* SWAPGS without input dep on GS */
-
-
 #ifdef CONFIG_X86_32
 /*
  * 64-bit kernels don't use X86_BUG_ESPFIX.  Make the define conditional
@@ -312,5 +307,7 @@
  */
 #define X86_BUG_ESPFIX X86_BUG(9) /* "" IRET to 16-bit SS corrupts 
ESP/RSP high bits */
 #endif
-
+#define X86_BUG_NULL_SEG   X86_BUG(10) /* Nulling a selector preserves the 
base */
+#define X86_BUG_SWAPGS_FENCE   X86_BUG(11) /* SWAPGS without input dep on GS */
+#define X86_BUG_MONITORX86_BUG(12) /* IPI required to wake up 
remote CPU */
 #endif /* _ASM_X86_CPUFEATURES_H */
diff --git a/tools/arch/x86/include/uapi/asm/vmx.h 
b/tools/arch/x86/include/uapi/asm/vmx.h
index 5b15d94a33f8..37fee272618f 100644
--- a/tools/arch/x86/include/uapi/asm/vmx.h
+++ b/tools/arch/x86/include/uapi/asm/vmx.h
@@ -78,7 +78,6 @@
 #define EXIT_REASON_PML_FULL62
 #define EXIT_REASON_XSAVES  63
 #define EXIT_REASON_XRSTORS 64
-#define EXIT_REASON_PCOMMIT 65
 
 #define VMX_EXIT_REASONS \
{ EXIT_REASON_EXCEPTION_NMI, "EXCEPTION_NMI" }, \
@@ -127,8 +126,7 @@
{ EXIT_REASON_INVVPID,   "INVVPID" }, \
{ EXIT_REASON_INVPCID,   "INVPCID" }, \
{ EXIT_REASON_XSAVES,"XSAVES" }, \
-   { EXIT_REASON_XRSTORS,   "XRSTORS" }, \
-   { EXIT_REASON_PCOMMIT,   "PCOMMIT" }
+   { EXIT_REASON_XRSTORS,   "XRSTORS" }
 
 #define VMX_ABORT_SAVE_GUEST_MSR_FAIL1
 #define VMX_ABORT_LOAD_HOST_MSR_FAIL 4
-- 
2.7.4

[PATCH 07/11] tools: Sync cpufeatures.h and vmx.h with the kernel

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

There were changes related to the deprecation of the "pcommit"
instruction:

  fd1d961dd681 ("x86/insn: remove pcommit")
  dfa169bbee00 ("Revert "KVM: x86: add pcommit support"")

No need to update anything in the tools, as "pcommit" wasn't being
listed on the VMX_EXIT_REASONS in the tools/perf/arch/x86/util/kvm-stat.c
file.

Just grab fresh copies of these files to silence the file cache
coherency detector:

  $ make -C tools/perf O=/tmp/build/perf install-bin
  make: Entering directory '/home/acme/git/linux/tools/perf'
BUILD:   Doing 'make -j4' parallel build
  Warning: tools/arch/x86/include/asm/cpufeatures.h differs from kernel
  Warning: tools/arch/x86/include/uapi/asm/vmx.h differs from kernel
INSTALL  GTK UI
  
  #

Cc: Adrian Hunter 
Cc: Dan Williams 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paolo Bonzini 
Cc: Ross Zwisler 
Cc: Wang Nan 
Cc: Xiao Guangrong 
Link: http://lkml.kernel.org/n/tip-07pmcc1ysydhyyxbmp1vt...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/arch/x86/include/asm/cpufeatures.h | 9 +++--
 tools/arch/x86/include/uapi/asm/vmx.h| 4 +---
 2 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/tools/arch/x86/include/asm/cpufeatures.h 
b/tools/arch/x86/include/asm/cpufeatures.h
index 4a413485f9eb..92a8308b96f6 100644
--- a/tools/arch/x86/include/asm/cpufeatures.h
+++ b/tools/arch/x86/include/asm/cpufeatures.h
@@ -225,7 +225,6 @@
 #define X86_FEATURE_RDSEED ( 9*32+18) /* The RDSEED instruction */
 #define X86_FEATURE_ADX( 9*32+19) /* The ADCX and ADOX 
instructions */
 #define X86_FEATURE_SMAP   ( 9*32+20) /* Supervisor Mode Access Prevention 
*/
-#define X86_FEATURE_PCOMMIT( 9*32+22) /* PCOMMIT instruction */
 #define X86_FEATURE_CLFLUSHOPT ( 9*32+23) /* CLFLUSHOPT instruction */
 #define X86_FEATURE_CLWB   ( 9*32+24) /* CLWB instruction */
 #define X86_FEATURE_AVX512PF   ( 9*32+26) /* AVX-512 Prefetch */
@@ -301,10 +300,6 @@
 #define X86_BUG_FXSAVE_LEAKX86_BUG(6) /* FXSAVE leaks FOP/FIP/FOP */
 #define X86_BUG_CLFLUSH_MONITORX86_BUG(7) /* AAI65, CLFLUSH required 
before MONITOR */
 #define X86_BUG_SYSRET_SS_ATTRSX86_BUG(8) /* SYSRET doesn't fix up SS 
attrs */
-#define X86_BUG_NULL_SEG   X86_BUG(9) /* Nulling a selector preserves the 
base */
-#define X86_BUG_SWAPGS_FENCE   X86_BUG(10) /* SWAPGS without input dep on GS */
-
-
 #ifdef CONFIG_X86_32
 /*
  * 64-bit kernels don't use X86_BUG_ESPFIX.  Make the define conditional
@@ -312,5 +307,7 @@
  */
 #define X86_BUG_ESPFIX X86_BUG(9) /* "" IRET to 16-bit SS corrupts 
ESP/RSP high bits */
 #endif
-
+#define X86_BUG_NULL_SEG   X86_BUG(10) /* Nulling a selector preserves the 
base */
+#define X86_BUG_SWAPGS_FENCE   X86_BUG(11) /* SWAPGS without input dep on GS */
+#define X86_BUG_MONITORX86_BUG(12) /* IPI required to wake up 
remote CPU */
 #endif /* _ASM_X86_CPUFEATURES_H */
diff --git a/tools/arch/x86/include/uapi/asm/vmx.h 
b/tools/arch/x86/include/uapi/asm/vmx.h
index 5b15d94a33f8..37fee272618f 100644
--- a/tools/arch/x86/include/uapi/asm/vmx.h
+++ b/tools/arch/x86/include/uapi/asm/vmx.h
@@ -78,7 +78,6 @@
 #define EXIT_REASON_PML_FULL62
 #define EXIT_REASON_XSAVES  63
 #define EXIT_REASON_XRSTORS 64
-#define EXIT_REASON_PCOMMIT 65
 
 #define VMX_EXIT_REASONS \
{ EXIT_REASON_EXCEPTION_NMI, "EXCEPTION_NMI" }, \
@@ -127,8 +126,7 @@
{ EXIT_REASON_INVVPID,   "INVVPID" }, \
{ EXIT_REASON_INVPCID,   "INVPCID" }, \
{ EXIT_REASON_XSAVES,"XSAVES" }, \
-   { EXIT_REASON_XRSTORS,   "XRSTORS" }, \
-   { EXIT_REASON_PCOMMIT,   "PCOMMIT" }
+   { EXIT_REASON_XRSTORS,   "XRSTORS" }
 
 #define VMX_ABORT_SAVE_GUEST_MSR_FAIL1
 #define VMX_ABORT_LOAD_HOST_MSR_FAIL 4
-- 
2.7.4

Re: [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support

[Paul Gortmaker]

[Re: [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support] On 08/08/2016 
(Mon 13:44) Moritz Fischer wrote:

> Hi Alan,
> 
> On Mon, Aug 8, 2016 at 12:18 PM, atull  wrote:
> 
> >> Please don't use module.h in drivers controlled by a bool
> >> Kconfig setting.
> >>
> >> THanks,
> >> Paul.
> >>
> >
> > Thanks for the feedback.  Can you provide an example of what you
> > would consider to be proper usage in the kernel?
> 
> 
> I think Paul is suggesting to use
> 
> static int __init alt_fpga_bridge_init(void)
> {
> platform_driver_register(_fpga_bridge_driver);
> }
> 
> device_initcall(alt_fpga_bridge_init);
> 
> or better:
> 
> builtin_platform_driver(_fpga_bridge_driver);
> 
> Like for example in: drivers/cpuidle/cpuidle-mvebu-v7.c

Yes, pretty much that -- if you have a bool Kconfig, you should be using
builtin registration functions, and have no need for module.h or
anything MODULE_ or any module_init/module_exit calls.

An empty file containing nothing but #include  will
cause cpp to emit about 750k of goop, so we really should only be using
it for drivers that are genuinely modular; i.e. tristate Kconfig.

Thanks,
Paul.
--

> 
> Cheers,
> 
> Moritz

Re: [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support

[Paul Gortmaker]

[Re: [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support] On 08/08/2016 
(Mon 13:44) Moritz Fischer wrote:

> Hi Alan,
> 
> On Mon, Aug 8, 2016 at 12:18 PM, atull  wrote:
> 
> >> Please don't use module.h in drivers controlled by a bool
> >> Kconfig setting.
> >>
> >> THanks,
> >> Paul.
> >>
> >
> > Thanks for the feedback.  Can you provide an example of what you
> > would consider to be proper usage in the kernel?
> 
> 
> I think Paul is suggesting to use
> 
> static int __init alt_fpga_bridge_init(void)
> {
> platform_driver_register(_fpga_bridge_driver);
> }
> 
> device_initcall(alt_fpga_bridge_init);
> 
> or better:
> 
> builtin_platform_driver(_fpga_bridge_driver);
> 
> Like for example in: drivers/cpuidle/cpuidle-mvebu-v7.c

Yes, pretty much that -- if you have a bool Kconfig, you should be using
builtin registration functions, and have no need for module.h or
anything MODULE_ or any module_init/module_exit calls.

An empty file containing nothing but #include  will
cause cpp to emit about 750k of goop, so we really should only be using
it for drivers that are genuinely modular; i.e. tristate Kconfig.

Thanks,
Paul.
--

> 
> Cheers,
> 
> Moritz

[PATCH 06/11] perf probe: Support signedness casting

[Arnaldo Carvalho de Melo]

From: Naohiro Aota 

The 'perf probe' tool detects a variable's type and use the detected
type to add a new probe. Then, kprobes prints its variable in
hexadecimal format if the variable is unsigned and prints in decimal if
it is signed.

We sometimes want to see unsigned variable in decimal format (i.e.
sector_t or size_t). In that case, we need to investigate the variable's
size manually to specify just signedness.

This patch add signedness casting support. By specifying "s" or "u" as a
type, perf-probe will investigate variable size as usual and use the
specified signedness.

E.g. without this:

  $ perf probe -a 'submit_bio bio->bi_iter.bi_sector'
  Added new event:
probe:submit_bio (on submit_bio with bi_sector=bio->bi_iter.bi_sector)
  You can now use it in all perf tools, such as:
  perf record -e probe:submit_bio -aR sleep 1
  $ cat trace_pipe|head
  dbench-9692  [003] d..1   971.096633: submit_bio: 
(submit_bio+0x0/0x140) bi_sector=0x3a3d00
  dbench-9692  [003] d..1   971.096685: submit_bio: 
(submit_bio+0x0/0x140) bi_sector=0x1a3d80
  dbench-9692  [003] d..1   971.096687: submit_bio: 
(submit_bio+0x0/0x140) bi_sector=0x3a3d80
...
  // need to investigate the variable size
  $ perf probe -a 'submit_bio bio->bi_iter.bi_sector:s64'
  Added new event:
probe:submit_bio (on submit_bio with 
bi_sector=bio->bi_iter.bi_sector:s64)
  You can now use it in all perf tools, such as:
perf record -e probe:submit_bio -aR sleep 1

  With this:

  // just use "s" to cast its signedness
  $ perf probe -v -a 'submit_bio bio->bi_iter.bi_sector:s'
  Added new event:
probe:submit_bio (on submit_bio with bi_sector=bio->bi_iter.bi_sector:s)
  You can now use it in all perf tools, such as:
  perf record -e probe:submit_bio -aR sleep 1
  $ cat trace_pipe|head
  dbench-9689  [001] d..1  1212.391237: submit_bio: 
(submit_bio+0x0/0x140) bi_sector=128
  dbench-9689  [001] d..1  1212.391252: submit_bio: 
(submit_bio+0x0/0x140) bi_sector=131072
  dbench-9697  [006] d..1  1212.398611: submit_bio: 
(submit_bio+0x0/0x140) bi_sector=30208

  This commit also update perf-probe.txt to describe "types". Most parts
  are based on existing documentation: Documentation/trace/kprobetrace.txt

Committer note:

Testing using 'perf trace':

  # perf probe -a 'submit_bio bio->bi_iter.bi_sector'
  Added new event:
probe:submit_bio (on submit_bio with bi_sector=bio->bi_iter.bi_sector)

  You can now use it in all perf tools, such as:

perf record -e probe:submit_bio -aR sleep 1

  # trace --no-syscalls --ev probe:submit_bio
  0.000 probe:submit_bio:(ac3aee00) bi_sector=0xc133c0)
   3181.861 probe:submit_bio:(ac3aee00) bi_sector=0x6cffb8)
   3181.881 probe:submit_bio:(ac3aee00) bi_sector=0x6cffc0)
   3184.488 probe:submit_bio:(ac3aee00) bi_sector=0x6cffc8)

   4717.927 probe:submit_bio:(ac3aee00) bi_sector=0x4dc7a88)
   4717.970 probe:submit_bio:(ac3aee00) bi_sector=0x4dc7880)
  ^C[root@jouet ~]#

Now, using this new feature:

[root@jouet ~]# perf probe -a 'submit_bio bio->bi_iter.bi_sector:s'
Added new event:
  probe:submit_bio (on submit_bio with bi_sector=bio->bi_iter.bi_sector:s)

You can now use it in all perf tools, such as:

perf record -e probe:submit_bio -aR sleep 1

  [root@jouet ~]# trace --no-syscalls --ev probe:submit_bio
 0.000 probe:submit_bio:(ac3aee00) bi_sector=7145704)
 0.017 probe:submit_bio:(ac3aee00) bi_sector=7145712)
 0.019 probe:submit_bio:(ac3aee00) bi_sector=7145720)
 2.567 probe:submit_bio:(ac3aee00) bi_sector=7145728)
  5631.919 probe:submit_bio:(ac3aee00) bi_sector=0)
  5631.941 probe:submit_bio:(ac3aee00) bi_sector=8)
  5631.945 probe:submit_bio:(ac3aee00) bi_sector=16)
  5631.948 probe:submit_bio:(ac3aee00) bi_sector=24)
  ^C#

With callchains:

  # trace --no-syscalls --ev probe:submit_bio/max-stack=10/
 0.000 probe:submit_bio:(ac3aee00) bi_sector=50662544)
   submit_bio+0xa821 ([kernel.kallsyms])
   submit_bh+0xa8200013 ([kernel.kallsyms])
   
jbd2_journal_commit_transaction+0xa8200691 ([kernel.kallsyms])
   kjournald2+0xa82000ca ([kernel.kallsyms])
   kthread+0xa82000d8 ([kernel.kallsyms])
   ret_from_fork+0xa820001f 
([kernel.kallsyms])
 0.023 probe:submit_bio:(ac3aee00) bi_sector=50662552)
   submit_bio+0xa821 ([kernel.kallsyms])
   submit_bh+0xa8200013 ([kernel.kallsyms])
   
jbd2_journal_commit_transaction+0xa8200691 ([kernel.kallsyms])
   

[GIT PULL 00/11] perf/urgent fixes

[Arnaldo Carvalho de Melo]

Hi Ingo,

Please consider pulling,

- Arnaldo

Build test stats:

[root@jouet ~]# time dm
 1: alpine:3.4: Ok 
 2: android-ndk:r12b: Ok 
 3: archlinux:latest: Ok 
 4: centos:5: Ok 
 5: centos:6: Ok 
 6: centos:7: Ok 
 7: debian:7: Ok 
 8: debian:8: Ok 
 9: debian:experimental: Ok 
10: fedora:20: Ok 
11: fedora:21: Ok 
12: fedora:22: Ok 
13: fedora:23: Ok 
14: fedora:24: Ok 
15: fedora:rawhide: Ok 
16: mageia:5: Ok 
17: opensuse:13.2: Ok 
18: opensuse:42.1: Ok 
19: ubuntu:14.04.4: Ok 
20: ubuntu:15.10: Ok 
21: ubuntu:16.04: Ok 
22: ubuntu:16.04-x-arm64: Ok 
23: ubuntu:16.04-x-armhf: Ok 
24: ubuntu:16.04-x-powerpc64: Ok 
25: ubuntu:16.04-x-powerpc64el: Ok 
26: ubuntu:16.04-x-s390: Ok 

real16m44.470s

The following changes since commit f282f7a0ecc3e0b8fd8532a6c3e9401534cb907c:

  Merge tag 'perf-core-for-mingo-20160803' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent 
(2016-08-04 11:02:38 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
tags/perf-urgent-for-mingo-20160809

for you to fetch changes up to 99e608b5954c9e1ebadbf9660b74697d9dfd9f20:

  perf probe ppc64le: Fix probe location when using DWARF (2016-08-09 12:14:29 
-0300)


perf/urgent fixes:

User visible fixes:

- Fix the lookup for a kernel module in 'perf probe', fixing for instance, the
  erroneous return of "[raid10]" when looking for "[raid1]"  (Konstantin 
Khlebnikov)

- Disable counters in a group before reading them in 'perf stat', to avoid skew 
(Mark Rutland)

- Fix adding probes to function aliases in systems using kaslr (Masami 
Hiramatsu)

- Trip libtraceevent trace_seq buffers, removing unnecessary memory usage that 
could
  bring a system using tracepoint events with 'perf top' to a crawl, as the 
trace_seq
  buffers start at a whooping 4 KB, which is very rarely used in perf's 
usecases,
  so realloc it to the really used space as a last measure after using 
libtraceevent
  functions to format the fields of tracepoint events (Arnaldo Carvalho de Melo)

- Fix 'perf probe' location when using DWARF on ppc64le (Ravi Bangoria)

Improvement:

- Allow specifying signedness casts to a 'perf probe' variable, to shorten
  the number of steps to see signed values that otherwise would always appear
  as hex values (Naohiro Aota)

Documentation fixes:

- Add 'bpf-output' field to 'perf script' usage message (Brendan Gregg)

Infrastructure fixes:

- Sync kernel header files: cpufeatures.h, {disabled,required}-features.h,
  bpf.h and vmx.h, so that we get a clean build, without warnings about files
  being different from the kernel counterparts.

  A verification of the need or desirability of changes in tools/ based on what
  was done in the kernel changesets was made and documented in the respective
  file sync changesets (Arnaldo Carvalho de Melo)

Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>


Arnaldo Carvalho de Melo (4):
  perf hists: Trim libtraceevent trace_seq buffers
  tools: Sync cpufeatures.h and vmx.h with the kernel
  toops: Sync tools/include/uapi/linux/bpf.h with the kernel
  tools: Sync cpufeatures headers with the kernel

Brendan Gregg (1):
  perf script: Add 'bpf-output' field to usage message

Konstantin Khlebnikov (1):
  perf probe: Fix module name matching

Mark Rutland (1):
  perf stat: Avoid skew when reading events

Masami Hiramatsu (1):
  perf probe: Adjust map->reloc offset when finding kernel symbol from map

Naohiro Aota (1):
  perf probe: Support signedness casting

Ravi Bangoria (2):
  perf probe: Add function to post process kernel trace events
  perf probe ppc64le: Fix probe location when using DWARF

 tools/arch/x86/include/asm/cpufeatures.h   |  9 +--
 tools/arch/x86/include/asm/disabled-features.h |  2 +
 tools/arch/x86/include/asm/required-features.h |  2 +
 tools/arch/x86/include/uapi/asm/vmx.h  |  4 +-
 tools/include/uapi/linux/bpf.h | 86 +-
 tools/perf/Documentation/perf-probe.txt| 10 ++-
 tools/perf/Documentation/perf-script.txt   |  4 +-
 tools/perf/arch/powerpc/util/sym-handling.c| 27 ++--
 tools/perf/builtin-script.c|  2 +-
 tools/perf/builtin-stat.c  | 31 +++---
 tools/perf/util/probe-event.c  | 60 +++---
 tools/perf/util/probe-event.h  |  6 +-
 tools/perf/util/probe-finder.c | 15 -
 tools/perf/util/sort.c |  6 +-
 14 files changed, 210 insertions(+), 54 deletions(-)

[PATCH 06/11] perf probe: Support signedness casting

[Arnaldo Carvalho de Melo]

From: Naohiro Aota 

The 'perf probe' tool detects a variable's type and use the detected
type to add a new probe. Then, kprobes prints its variable in
hexadecimal format if the variable is unsigned and prints in decimal if
it is signed.

We sometimes want to see unsigned variable in decimal format (i.e.
sector_t or size_t). In that case, we need to investigate the variable's
size manually to specify just signedness.

This patch add signedness casting support. By specifying "s" or "u" as a
type, perf-probe will investigate variable size as usual and use the
specified signedness.

E.g. without this:

  $ perf probe -a 'submit_bio bio->bi_iter.bi_sector'
  Added new event:
probe:submit_bio (on submit_bio with bi_sector=bio->bi_iter.bi_sector)
  You can now use it in all perf tools, such as:
  perf record -e probe:submit_bio -aR sleep 1
  $ cat trace_pipe|head
  dbench-9692  [003] d..1   971.096633: submit_bio: 
(submit_bio+0x0/0x140) bi_sector=0x3a3d00
  dbench-9692  [003] d..1   971.096685: submit_bio: 
(submit_bio+0x0/0x140) bi_sector=0x1a3d80
  dbench-9692  [003] d..1   971.096687: submit_bio: 
(submit_bio+0x0/0x140) bi_sector=0x3a3d80
...
  // need to investigate the variable size
  $ perf probe -a 'submit_bio bio->bi_iter.bi_sector:s64'
  Added new event:
probe:submit_bio (on submit_bio with 
bi_sector=bio->bi_iter.bi_sector:s64)
  You can now use it in all perf tools, such as:
perf record -e probe:submit_bio -aR sleep 1

  With this:

  // just use "s" to cast its signedness
  $ perf probe -v -a 'submit_bio bio->bi_iter.bi_sector:s'
  Added new event:
probe:submit_bio (on submit_bio with bi_sector=bio->bi_iter.bi_sector:s)
  You can now use it in all perf tools, such as:
  perf record -e probe:submit_bio -aR sleep 1
  $ cat trace_pipe|head
  dbench-9689  [001] d..1  1212.391237: submit_bio: 
(submit_bio+0x0/0x140) bi_sector=128
  dbench-9689  [001] d..1  1212.391252: submit_bio: 
(submit_bio+0x0/0x140) bi_sector=131072
  dbench-9697  [006] d..1  1212.398611: submit_bio: 
(submit_bio+0x0/0x140) bi_sector=30208

  This commit also update perf-probe.txt to describe "types". Most parts
  are based on existing documentation: Documentation/trace/kprobetrace.txt

Committer note:

Testing using 'perf trace':

  # perf probe -a 'submit_bio bio->bi_iter.bi_sector'
  Added new event:
probe:submit_bio (on submit_bio with bi_sector=bio->bi_iter.bi_sector)

  You can now use it in all perf tools, such as:

perf record -e probe:submit_bio -aR sleep 1

  # trace --no-syscalls --ev probe:submit_bio
  0.000 probe:submit_bio:(ac3aee00) bi_sector=0xc133c0)
   3181.861 probe:submit_bio:(ac3aee00) bi_sector=0x6cffb8)
   3181.881 probe:submit_bio:(ac3aee00) bi_sector=0x6cffc0)
   3184.488 probe:submit_bio:(ac3aee00) bi_sector=0x6cffc8)

   4717.927 probe:submit_bio:(ac3aee00) bi_sector=0x4dc7a88)
   4717.970 probe:submit_bio:(ac3aee00) bi_sector=0x4dc7880)
  ^C[root@jouet ~]#

Now, using this new feature:

[root@jouet ~]# perf probe -a 'submit_bio bio->bi_iter.bi_sector:s'
Added new event:
  probe:submit_bio (on submit_bio with bi_sector=bio->bi_iter.bi_sector:s)

You can now use it in all perf tools, such as:

perf record -e probe:submit_bio -aR sleep 1

  [root@jouet ~]# trace --no-syscalls --ev probe:submit_bio
 0.000 probe:submit_bio:(ac3aee00) bi_sector=7145704)
 0.017 probe:submit_bio:(ac3aee00) bi_sector=7145712)
 0.019 probe:submit_bio:(ac3aee00) bi_sector=7145720)
 2.567 probe:submit_bio:(ac3aee00) bi_sector=7145728)
  5631.919 probe:submit_bio:(ac3aee00) bi_sector=0)
  5631.941 probe:submit_bio:(ac3aee00) bi_sector=8)
  5631.945 probe:submit_bio:(ac3aee00) bi_sector=16)
  5631.948 probe:submit_bio:(ac3aee00) bi_sector=24)
  ^C#

With callchains:

  # trace --no-syscalls --ev probe:submit_bio/max-stack=10/
 0.000 probe:submit_bio:(ac3aee00) bi_sector=50662544)
   submit_bio+0xa821 ([kernel.kallsyms])
   submit_bh+0xa8200013 ([kernel.kallsyms])
   
jbd2_journal_commit_transaction+0xa8200691 ([kernel.kallsyms])
   kjournald2+0xa82000ca ([kernel.kallsyms])
   kthread+0xa82000d8 ([kernel.kallsyms])
   ret_from_fork+0xa820001f 
([kernel.kallsyms])
 0.023 probe:submit_bio:(ac3aee00) bi_sector=50662552)
   submit_bio+0xa821 ([kernel.kallsyms])
   submit_bh+0xa8200013 ([kernel.kallsyms])
   
jbd2_journal_commit_transaction+0xa8200691 ([kernel.kallsyms])
   kjournald2+0xa82000ca 

[GIT PULL 00/11] perf/urgent fixes

[Arnaldo Carvalho de Melo]

Hi Ingo,

Please consider pulling,

- Arnaldo

Build test stats:

[root@jouet ~]# time dm
 1: alpine:3.4: Ok 
 2: android-ndk:r12b: Ok 
 3: archlinux:latest: Ok 
 4: centos:5: Ok 
 5: centos:6: Ok 
 6: centos:7: Ok 
 7: debian:7: Ok 
 8: debian:8: Ok 
 9: debian:experimental: Ok 
10: fedora:20: Ok 
11: fedora:21: Ok 
12: fedora:22: Ok 
13: fedora:23: Ok 
14: fedora:24: Ok 
15: fedora:rawhide: Ok 
16: mageia:5: Ok 
17: opensuse:13.2: Ok 
18: opensuse:42.1: Ok 
19: ubuntu:14.04.4: Ok 
20: ubuntu:15.10: Ok 
21: ubuntu:16.04: Ok 
22: ubuntu:16.04-x-arm64: Ok 
23: ubuntu:16.04-x-armhf: Ok 
24: ubuntu:16.04-x-powerpc64: Ok 
25: ubuntu:16.04-x-powerpc64el: Ok 
26: ubuntu:16.04-x-s390: Ok 

real16m44.470s

The following changes since commit f282f7a0ecc3e0b8fd8532a6c3e9401534cb907c:

  Merge tag 'perf-core-for-mingo-20160803' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent 
(2016-08-04 11:02:38 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
tags/perf-urgent-for-mingo-20160809

for you to fetch changes up to 99e608b5954c9e1ebadbf9660b74697d9dfd9f20:

  perf probe ppc64le: Fix probe location when using DWARF (2016-08-09 12:14:29 
-0300)


perf/urgent fixes:

User visible fixes:

- Fix the lookup for a kernel module in 'perf probe', fixing for instance, the
  erroneous return of "[raid10]" when looking for "[raid1]"  (Konstantin 
Khlebnikov)

- Disable counters in a group before reading them in 'perf stat', to avoid skew 
(Mark Rutland)

- Fix adding probes to function aliases in systems using kaslr (Masami 
Hiramatsu)

- Trip libtraceevent trace_seq buffers, removing unnecessary memory usage that 
could
  bring a system using tracepoint events with 'perf top' to a crawl, as the 
trace_seq
  buffers start at a whooping 4 KB, which is very rarely used in perf's 
usecases,
  so realloc it to the really used space as a last measure after using 
libtraceevent
  functions to format the fields of tracepoint events (Arnaldo Carvalho de Melo)

- Fix 'perf probe' location when using DWARF on ppc64le (Ravi Bangoria)

Improvement:

- Allow specifying signedness casts to a 'perf probe' variable, to shorten
  the number of steps to see signed values that otherwise would always appear
  as hex values (Naohiro Aota)

Documentation fixes:

- Add 'bpf-output' field to 'perf script' usage message (Brendan Gregg)

Infrastructure fixes:

- Sync kernel header files: cpufeatures.h, {disabled,required}-features.h,
  bpf.h and vmx.h, so that we get a clean build, without warnings about files
  being different from the kernel counterparts.

  A verification of the need or desirability of changes in tools/ based on what
  was done in the kernel changesets was made and documented in the respective
  file sync changesets (Arnaldo Carvalho de Melo)

Signed-off-by: Arnaldo Carvalho de Melo 


Arnaldo Carvalho de Melo (4):
  perf hists: Trim libtraceevent trace_seq buffers
  tools: Sync cpufeatures.h and vmx.h with the kernel
  toops: Sync tools/include/uapi/linux/bpf.h with the kernel
  tools: Sync cpufeatures headers with the kernel

Brendan Gregg (1):
  perf script: Add 'bpf-output' field to usage message

Konstantin Khlebnikov (1):
  perf probe: Fix module name matching

Mark Rutland (1):
  perf stat: Avoid skew when reading events

Masami Hiramatsu (1):
  perf probe: Adjust map->reloc offset when finding kernel symbol from map

Naohiro Aota (1):
  perf probe: Support signedness casting

Ravi Bangoria (2):
  perf probe: Add function to post process kernel trace events
  perf probe ppc64le: Fix probe location when using DWARF

 tools/arch/x86/include/asm/cpufeatures.h   |  9 +--
 tools/arch/x86/include/asm/disabled-features.h |  2 +
 tools/arch/x86/include/asm/required-features.h |  2 +
 tools/arch/x86/include/uapi/asm/vmx.h  |  4 +-
 tools/include/uapi/linux/bpf.h | 86 +-
 tools/perf/Documentation/perf-probe.txt| 10 ++-
 tools/perf/Documentation/perf-script.txt   |  4 +-
 tools/perf/arch/powerpc/util/sym-handling.c| 27 ++--
 tools/perf/builtin-script.c|  2 +-
 tools/perf/builtin-stat.c  | 31 +++---
 tools/perf/util/probe-event.c  | 60 +++---
 tools/perf/util/probe-event.h  |  6 +-
 tools/perf/util/probe-finder.c | 15 -
 tools/perf/util/sort.c |  6 +-
 14 files changed, 210 insertions(+), 54 deletions(-)

[PATCH 04/11] perf probe: Fix module name matching

[Arnaldo Carvalho de Melo]

From: Konstantin Khlebnikov 

If module is "module" then dso->short_name is "[module]".  Substring
comparing is't enough: "raid10" matches to "[raid1]".  This patch also
checks terminating zero in module name.

Signed-off-by: Konstantin Khlebnikov 
Acked-by: Masami Hiramatsu 
Link: 
http://lkml.kernel.org/r/147039975648.715620.12985971832789032159.stgit@buzz
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-event.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index d5ccb656fd81..1201f73ca723 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -170,8 +170,10 @@ static struct map *kernel_get_module_map(const char 
*module)
module = "kernel";
 
for (pos = maps__first(maps); pos; pos = map__next(pos)) {
+   /* short_name is "[module]" */
if (strncmp(pos->dso->short_name + 1, module,
-   pos->dso->short_name_len - 2) == 0) {
+   pos->dso->short_name_len - 2) == 0 &&
+   module[pos->dso->short_name_len - 2] == '\0') {
return pos;
}
}
-- 
2.7.4

[PATCH 04/11] perf probe: Fix module name matching

[Arnaldo Carvalho de Melo]

From: Konstantin Khlebnikov 

If module is "module" then dso->short_name is "[module]".  Substring
comparing is't enough: "raid10" matches to "[raid1]".  This patch also
checks terminating zero in module name.

Signed-off-by: Konstantin Khlebnikov 
Acked-by: Masami Hiramatsu 
Link: 
http://lkml.kernel.org/r/147039975648.715620.12985971832789032159.stgit@buzz
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-event.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index d5ccb656fd81..1201f73ca723 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -170,8 +170,10 @@ static struct map *kernel_get_module_map(const char 
*module)
module = "kernel";
 
for (pos = maps__first(maps); pos; pos = map__next(pos)) {
+   /* short_name is "[module]" */
if (strncmp(pos->dso->short_name + 1, module,
-   pos->dso->short_name_len - 2) == 0) {
+   pos->dso->short_name_len - 2) == 0 &&
+   module[pos->dso->short_name_len - 2] == '\0') {
return pos;
}
}
-- 
2.7.4

Re: [Intel-gfx] include/drm/i915_drm.h:96: possible bad bitmask ?

[Dave Gordon]

On 09/08/16 03:59, Dave Airlie wrote:

On 8 August 2016 at 19:40, Daniel Vetter  wrote:

On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote:

Hello there,

Recent versions of gcc say this:

include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
requires 37 bits to represent, but ‘int’ only has 32 bits
[-Wshift-overflow=]

Source code is

#define   INTEL_BSM_MASK (0x << 20)

Maybe something like

#define   INTEL_BSM_MASK (0xUL<< 20)

might be better.


Yup. Care to bake this into a patch (with s-o-b and everything per
Documentation/SubmittingPatches) so I can apply it?


Why would you want to apply a clearly incorrect patch :-)

INTEL_BSM_MASK is used in one place, on a 32-bit number

I'm not sure what it needs to be, but a 64-bit number it doesn't.

Dave.


I found two uses, but in both cases it's masking a value read
from a 32-bit PCI register, so it can just be (-(1 << 20)).

.Dave.

Re: [Intel-gfx] include/drm/i915_drm.h:96: possible bad bitmask ?

[Dave Gordon]

On 09/08/16 03:59, Dave Airlie wrote:

On 8 August 2016 at 19:40, Daniel Vetter  wrote:

On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote:

Hello there,

Recent versions of gcc say this:

include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
requires 37 bits to represent, but ‘int’ only has 32 bits
[-Wshift-overflow=]

Source code is

#define   INTEL_BSM_MASK (0x << 20)

Maybe something like

#define   INTEL_BSM_MASK (0xUL<< 20)

might be better.


Yup. Care to bake this into a patch (with s-o-b and everything per
Documentation/SubmittingPatches) so I can apply it?


Why would you want to apply a clearly incorrect patch :-)

INTEL_BSM_MASK is used in one place, on a 32-bit number

I'm not sure what it needs to be, but a 64-bit number it doesn't.

Dave.


I found two uses, but in both cases it's masking a value read
from a 32-bit PCI register, so it can just be (-(1 << 20)).

.Dave.

[PATCH] dm9000: Fix irq trigger type setup on non-dt platforms

[Sylwester Nawrocki]

Commit b5a099c67a1c36b "net: ethernet: davicom: fix devicetree irq
resource" causes an interrupt storm after the ethernet interface
is activated on S3C24XX platform (ARM non-dt), due to the interrupt
trigger type not being set properly.

It seems, after adding parsing of IRQ flags in commit 7085a7401ba54e92b
"drivers: platform: parse IRQ flags from resources", there is no path
for non-dt platforms where irq_set_type callback could be invoked when
we don't pass the trigger type flags to the request_irq() call.

In case of a board where the regression is seen the interrupt trigger
type flags are passed through a platform device's resource and it is
not currently handled properly without passing the irq trigger type
flags to the request_irq() call.  In case of OF an of_irq_get() call
within platform_get_irq() function seems to be ensuring required irq_chip
setup, but there is no equivalent code for non OF/ACPI platforms.

This patch mostly restores irq trigger type setting code which has been
removed in commit ("net: ethernet: davicom: fix devicetree irq resource").

Fixes: b5a099c67a1c36b913 ("net: ethernet: davicom: fix devicetree irq 
resource")

Signed-off-by: Sylwester Nawrocki 
---

Perhaps instead the core could be configuring the irqchip automatically as it
is done for OF/ACPI cases. I had doubts though if trying to make such changes
for a bug fix patch was the right thing to do.
---
 drivers/net/ethernet/davicom/dm9000.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/davicom/dm9000.c 
b/drivers/net/ethernet/davicom/dm9000.c
index 1471e16..f45385f 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -1299,6 +1299,7 @@ static int
 dm9000_open(struct net_device *dev)
 {
struct board_info *db = netdev_priv(dev);
+   unsigned int irq_flags = irq_get_trigger_type(dev->irq);
 
if (netif_msg_ifup(db))
dev_dbg(db->dev, "enabling %s\n", dev->name);
@@ -1306,9 +1307,11 @@ dm9000_open(struct net_device *dev)
/* If there is no IRQ type specified, tell the user that this is a
 * problem
 */
-   if (irq_get_trigger_type(dev->irq) == IRQF_TRIGGER_NONE)
+   if (irq_flags == IRQF_TRIGGER_NONE)
dev_warn(db->dev, "WARNING: no IRQ resource flags set.\n");
 
+   irq_flags |= IRQF_SHARED;
+
/* GPIO0 on pre-activate PHY, Reg 1F is not set by reset */
iow(db, DM9000_GPR, 0); /* REG_1F bit0 activate phyxcer */
mdelay(1); /* delay needs by DM9000B */
@@ -1316,8 +1319,7 @@ dm9000_open(struct net_device *dev)
/* Initialize DM9000 board */
dm9000_init_dm9000(dev);
 
-   if (request_irq(dev->irq, dm9000_interrupt, IRQF_SHARED,
-   dev->name, dev))
+   if (request_irq(dev->irq, dm9000_interrupt, irq_flags, dev->name, dev))
return -EAGAIN;
/* Now that we have an interrupt handler hooked up we can unmask
 * our interrupts
-- 
1.9.1

[PATCH] dm9000: Fix irq trigger type setup on non-dt platforms

[Sylwester Nawrocki]

Commit b5a099c67a1c36b "net: ethernet: davicom: fix devicetree irq
resource" causes an interrupt storm after the ethernet interface
is activated on S3C24XX platform (ARM non-dt), due to the interrupt
trigger type not being set properly.

It seems, after adding parsing of IRQ flags in commit 7085a7401ba54e92b
"drivers: platform: parse IRQ flags from resources", there is no path
for non-dt platforms where irq_set_type callback could be invoked when
we don't pass the trigger type flags to the request_irq() call.

In case of a board where the regression is seen the interrupt trigger
type flags are passed through a platform device's resource and it is
not currently handled properly without passing the irq trigger type
flags to the request_irq() call.  In case of OF an of_irq_get() call
within platform_get_irq() function seems to be ensuring required irq_chip
setup, but there is no equivalent code for non OF/ACPI platforms.

This patch mostly restores irq trigger type setting code which has been
removed in commit ("net: ethernet: davicom: fix devicetree irq resource").

Fixes: b5a099c67a1c36b913 ("net: ethernet: davicom: fix devicetree irq 
resource")

Signed-off-by: Sylwester Nawrocki 
---

Perhaps instead the core could be configuring the irqchip automatically as it
is done for OF/ACPI cases. I had doubts though if trying to make such changes
for a bug fix patch was the right thing to do.
---
 drivers/net/ethernet/davicom/dm9000.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/davicom/dm9000.c 
b/drivers/net/ethernet/davicom/dm9000.c
index 1471e16..f45385f 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -1299,6 +1299,7 @@ static int
 dm9000_open(struct net_device *dev)
 {
struct board_info *db = netdev_priv(dev);
+   unsigned int irq_flags = irq_get_trigger_type(dev->irq);
 
if (netif_msg_ifup(db))
dev_dbg(db->dev, "enabling %s\n", dev->name);
@@ -1306,9 +1307,11 @@ dm9000_open(struct net_device *dev)
/* If there is no IRQ type specified, tell the user that this is a
 * problem
 */
-   if (irq_get_trigger_type(dev->irq) == IRQF_TRIGGER_NONE)
+   if (irq_flags == IRQF_TRIGGER_NONE)
dev_warn(db->dev, "WARNING: no IRQ resource flags set.\n");
 
+   irq_flags |= IRQF_SHARED;
+
/* GPIO0 on pre-activate PHY, Reg 1F is not set by reset */
iow(db, DM9000_GPR, 0); /* REG_1F bit0 activate phyxcer */
mdelay(1); /* delay needs by DM9000B */
@@ -1316,8 +1319,7 @@ dm9000_open(struct net_device *dev)
/* Initialize DM9000 board */
dm9000_init_dm9000(dev);
 
-   if (request_irq(dev->irq, dm9000_interrupt, IRQF_SHARED,
-   dev->name, dev))
+   if (request_irq(dev->irq, dm9000_interrupt, irq_flags, dev->name, dev))
return -EAGAIN;
/* Now that we have an interrupt handler hooked up we can unmask
 * our interrupts
-- 
1.9.1

[PATCH] fmc: constify fmc_operations structure

[Julia Lawall]

The fmc_operations structure is never modified, so declare is as const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/fmc/fmc-fakedev.c |2 +-
 include/linux/fmc.h   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/fmc/fmc-fakedev.c b/drivers/fmc/fmc-fakedev.c
index 941d093..3781d0d 100644
--- a/drivers/fmc/fmc-fakedev.c
+++ b/drivers/fmc/fmc-fakedev.c
@@ -231,7 +231,7 @@ static int ff_validate(struct fmc_device *fmc, struct 
fmc_driver *drv)
 
 
 
-static struct fmc_operations ff_fmc_operations = {
+static const struct fmc_operations ff_fmc_operations = {
.read32 =   ff_readl,
.write32 =  ff_writel,
.reprogram =ff_reprogram,
diff --git a/include/linux/fmc.h b/include/linux/fmc.h
index a5f0aa5..fc3a684 100644
--- a/include/linux/fmc.h
+++ b/include/linux/fmc.h
@@ -160,7 +160,7 @@ struct fmc_device {
unsigned long flags;
struct module *owner;   /* char device must pin it */
struct fmc_fru_id id;   /* for EEPROM-based match */
-   struct fmc_operations *op;  /* carrier-provided */
+   const struct fmc_operations *op;/* carrier-provided */
int irq;/* according to host bus. 0 == none */
int eeprom_len; /* Usually 8kB, may be less */
int eeprom_addr;/* 0x50, 0x52 etc */

[PATCH] fmc: constify fmc_operations structure

[Julia Lawall]

The fmc_operations structure is never modified, so declare is as const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/fmc/fmc-fakedev.c |2 +-
 include/linux/fmc.h   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/fmc/fmc-fakedev.c b/drivers/fmc/fmc-fakedev.c
index 941d093..3781d0d 100644
--- a/drivers/fmc/fmc-fakedev.c
+++ b/drivers/fmc/fmc-fakedev.c
@@ -231,7 +231,7 @@ static int ff_validate(struct fmc_device *fmc, struct 
fmc_driver *drv)
 
 
 
-static struct fmc_operations ff_fmc_operations = {
+static const struct fmc_operations ff_fmc_operations = {
.read32 =   ff_readl,
.write32 =  ff_writel,
.reprogram =ff_reprogram,
diff --git a/include/linux/fmc.h b/include/linux/fmc.h
index a5f0aa5..fc3a684 100644
--- a/include/linux/fmc.h
+++ b/include/linux/fmc.h
@@ -160,7 +160,7 @@ struct fmc_device {
unsigned long flags;
struct module *owner;   /* char device must pin it */
struct fmc_fru_id id;   /* for EEPROM-based match */
-   struct fmc_operations *op;  /* carrier-provided */
+   const struct fmc_operations *op;/* carrier-provided */
int irq;/* according to host bus. 0 == none */
int eeprom_len; /* Usually 8kB, may be less */
int eeprom_addr;/* 0x50, 0x52 etc */