[PATCH v3,net-next 2/2] ip6_gre: fix potential memory leak in ip6erspan_rcv

[Haishuang Yan]

If md is NULL, tun_dst must be freed, otherwise it will cause memory
leak.

Fixes: ef7baf5e083c ("ip6_gre: add ip6 erspan collect_md mode")
Cc: William Tu 
Signed-off-by: Haishuang Yan 

---
Changes since v3:
  * Rebase on latest master branch.
  * Fix wrong commit information.
---
 net/ipv6/ip6_gre.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 9bd1103..45038a9 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -550,8 +550,10 @@ static int ip6erspan_rcv(struct sk_buff *skb, int 
gre_hdr_len,
 
info = _dst->u.tun_info;
md = ip_tunnel_info_opts(info);
-   if (!md)
+   if (!md) {
+   dst_release((struct dst_entry *)tun_dst);
return PACKET_REJECT;
+   }
 
memcpy(md, pkt_md, sizeof(*md));
md->version = ver;
-- 
1.8.3.1

[PATCH v3,net-next 2/2] ip6_gre: fix potential memory leak in ip6erspan_rcv

[Haishuang Yan]

If md is NULL, tun_dst must be freed, otherwise it will cause memory
leak.

Fixes: ef7baf5e083c ("ip6_gre: add ip6 erspan collect_md mode")
Cc: William Tu 
Signed-off-by: Haishuang Yan 

---
Changes since v3:
  * Rebase on latest master branch.
  * Fix wrong commit information.
---
 net/ipv6/ip6_gre.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 9bd1103..45038a9 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -550,8 +550,10 @@ static int ip6erspan_rcv(struct sk_buff *skb, int 
gre_hdr_len,
 
info = _dst->u.tun_info;
md = ip_tunnel_info_opts(info);
-   if (!md)
+   if (!md) {
+   dst_release((struct dst_entry *)tun_dst);
return PACKET_REJECT;
+   }
 
memcpy(md, pkt_md, sizeof(*md));
md->version = ver;
-- 
1.8.3.1

[PATCH v3,net-next 1/2] ip_gre: fix potential memory leak in erspan_rcv

[Haishuang Yan]

If md is NULL, tun_dst must be freed, otherwise it will cause memory
leak.

Fixes: 1a66a836da6 ("gre: add collect_md mode to ERSPAN tunnel")
Cc: William Tu 
Signed-off-by: Haishuang Yan 

---
Changes since v3:
  * Rebase on latest master branch.
  * Fix wrong commit information.
---
 net/ipv4/ip_gre.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index fd4d6e9..3029e3e 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -313,8 +313,10 @@ static int erspan_rcv(struct sk_buff *skb, struct 
tnl_ptk_info *tpi,
return PACKET_REJECT;
 
md = ip_tunnel_info_opts(_dst->u.tun_info);
-   if (!md)
+   if (!md) {
+   dst_release((struct dst_entry *)tun_dst);
return PACKET_REJECT;
+   }
 
memcpy(md, pkt_md, sizeof(*md));
md->version = ver;
-- 
1.8.3.1

[PATCH v3,net-next 0/2] net: erspan: fix potential memory leak

[Haishuang Yan]

This patch series fix potential memory leak issue.

Haishuang Yan (2):
  ip_gre: fix potential memory leak in erspan_rcv
  ip6_gre: fix potential memory leak in ip6erspan_rcv

 net/ipv4/ip_gre.c  | 4 +++-
 net/ipv6/ip6_gre.c | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

--
1.8.3.1

[PATCH v3,net-next 1/2] ip_gre: fix potential memory leak in erspan_rcv

[Haishuang Yan]

If md is NULL, tun_dst must be freed, otherwise it will cause memory
leak.

Fixes: 1a66a836da6 ("gre: add collect_md mode to ERSPAN tunnel")
Cc: William Tu 
Signed-off-by: Haishuang Yan 

---
Changes since v3:
  * Rebase on latest master branch.
  * Fix wrong commit information.
---
 net/ipv4/ip_gre.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index fd4d6e9..3029e3e 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -313,8 +313,10 @@ static int erspan_rcv(struct sk_buff *skb, struct 
tnl_ptk_info *tpi,
return PACKET_REJECT;
 
md = ip_tunnel_info_opts(_dst->u.tun_info);
-   if (!md)
+   if (!md) {
+   dst_release((struct dst_entry *)tun_dst);
return PACKET_REJECT;
+   }
 
memcpy(md, pkt_md, sizeof(*md));
md->version = ver;
-- 
1.8.3.1

[PATCH v3,net-next 0/2] net: erspan: fix potential memory leak

[Haishuang Yan]

This patch series fix potential memory leak issue.

Haishuang Yan (2):
  ip_gre: fix potential memory leak in erspan_rcv
  ip6_gre: fix potential memory leak in ip6erspan_rcv

 net/ipv4/ip_gre.c  | 4 +++-
 net/ipv6/ip6_gre.c | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

--
1.8.3.1

Re: proc_flush_task oops

[Eric W. Biederman]

ebied...@xmission.com (Eric W. Biederman) writes:

> Dave Jones  writes:
>
>> On Tue, Dec 19, 2017 at 12:27:30PM -0600, Eric W. Biederman wrote:
>>  > Dave Jones  writes:
>>  > 
>>  > > On Mon, Dec 18, 2017 at 03:50:52PM -0800, Linus Torvalds wrote:
>>  > >
>>  > >  > But I don't see what would have changed in this area recently.
>>  > >  > 
>>  > >  > Do you end up saving the seeds that cause crashes? Is this
>>  > >  > reproducible? (Other than seeing it twoce, of course)
>>  > >
>>  > > Only clue so far, is every time I'm able to trigger it, the last thing
>>  > > the child process that triggers it did, was an execveat.
>>  > 
>>  > Is there any chance the excveat might be called from a child thread?
>>
>> If trinity choose one of the exec syscalls, it forks off an extra child
>> to do it in, on the off-chance that it succeeds, and we never return.
>> https://github.com/kernelslacker/trinity/blob/master/syscall.c#L139
>
>   extrapid = fork();
>   if (extrapid == 0) {
>   /* grand-child */
>   char childname[]="trinity-subchild";
>   prctl(PR_SET_NAME, (unsigned long) );
>
>   __do_syscall(rec, GOING_AWAY);
>   /* if this was for eg. an successful execve, we should never 
> get here.
>* if it failed though... */
>   _exit(EXIT_SUCCESS);
>   }
>
> That is interesting.
>
>
> So the system call sequence is a fork which just succeeded and than an
> exec.  That reduces the possibilities quite a lot.
>
> With pids there was a recent change that just replaced the pid hash
> table and the pid bitmap with and idr.  It changes the locking somewhat
> and probably changes the timing so that might be the culprit.
>
> I am trying to figure out if there is an interface that would let
> ns_last_pid for a pid namespace be accessed before the first pid is
> allocated and I am not seeing it.  It does not appear to be possible
> to mount a proc for a pid namespace you are not currently in.
>
> *Scratches my head*  I am not seeing anything obvious.

Can you try this patch as you reproduce this issue?

diff --git a/kernel/pid.c b/kernel/pid.c
index b13b624e2c49..df9e5d4d8f83 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -210,6 +210,7 @@ struct pid *alloc_pid(struct pid_namespace *ns)
goto out_unlock;
for ( ; upid >= pid->numbers; --upid) {
/* Make the PID visible to find_pid_ns. */
+   WARN_ON(!upid->ns->proc_mnt);
idr_replace(>ns->idr, pid, upid->nr);
upid->ns->pid_allocated++;
}


If the warning triggers it means the bug is in alloc_pid and somehow
something has gotten past the is_child_reaper check.

If the warning does not trigger it means something is stomping proc_mnt.

In the entire kernel there are exactly two assignments to proc_mnt.
- kmem_cache_zalloc in create_pid_namespace.
- In pid_ns_prepare_proc where proc_mnt is set to a non-zero value.

On the 29th of Nov syzkaller also hit this and gave me this reproducer
that I can't figure out heads or tails of.

#{Threaded:true Collide:true Repeat:true Procs:8 Sandbox:namespace Fault:false 
FaultCall:-1 FaultNth:0 EnableTun:true UseTmpDir:true HandleSegv:true 
WaitRepeat:true Debug:false Repro:false}
mmap(&(0x7f00/0xfff000)=nil, 0xfff000, 0x3, 0x32, 0x, 
0x0)
perf_event_open(&(0x7f25c000)={0x2, 0x78, 0x3e3, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0xf72, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0}, 0x0, 0x, 0x, 0x0)
socket$inet6_dccp(0xa, 0x6, 0x0)
unshare(0x2400)
sendmsg$unix(0x, 
&(0x7f001000-0x38)={&(0x7f239000-0x8)=@abs={0x0, 0x0, 0x0}, 0x8, 
&(0x7f008000)=[], 0x0, &(0x7f001000-0x10)=[@rights={0x200, 0x1, 0x1, 
[0x]}], 0x1, 0x0}, 0x0)
process_vm_writev(0x0, 
&(0x7f699000-0x70)=[{&(0x7f6a5000)="",
 0x4c}, {&(0x7f7b9000-0x54)="", 0x0}, {&(0x7f4f3000)="", 0x0}, 
{&(0x7f2e3000-0xd6)="",
 0xd6}, 
{&(0x7ff2e000)="",
 0x52}, {&(0x7f8e5000-0x10)="", 0x10}, 
{&(0x7fa3a000)="", 0x0}], 0x7, 

Re: proc_flush_task oops

[Eric W. Biederman]

ebied...@xmission.com (Eric W. Biederman) writes:

> Dave Jones  writes:
>
>> On Tue, Dec 19, 2017 at 12:27:30PM -0600, Eric W. Biederman wrote:
>>  > Dave Jones  writes:
>>  > 
>>  > > On Mon, Dec 18, 2017 at 03:50:52PM -0800, Linus Torvalds wrote:
>>  > >
>>  > >  > But I don't see what would have changed in this area recently.
>>  > >  > 
>>  > >  > Do you end up saving the seeds that cause crashes? Is this
>>  > >  > reproducible? (Other than seeing it twoce, of course)
>>  > >
>>  > > Only clue so far, is every time I'm able to trigger it, the last thing
>>  > > the child process that triggers it did, was an execveat.
>>  > 
>>  > Is there any chance the excveat might be called from a child thread?
>>
>> If trinity choose one of the exec syscalls, it forks off an extra child
>> to do it in, on the off-chance that it succeeds, and we never return.
>> https://github.com/kernelslacker/trinity/blob/master/syscall.c#L139
>
>   extrapid = fork();
>   if (extrapid == 0) {
>   /* grand-child */
>   char childname[]="trinity-subchild";
>   prctl(PR_SET_NAME, (unsigned long) );
>
>   __do_syscall(rec, GOING_AWAY);
>   /* if this was for eg. an successful execve, we should never 
> get here.
>* if it failed though... */
>   _exit(EXIT_SUCCESS);
>   }
>
> That is interesting.
>
>
> So the system call sequence is a fork which just succeeded and than an
> exec.  That reduces the possibilities quite a lot.
>
> With pids there was a recent change that just replaced the pid hash
> table and the pid bitmap with and idr.  It changes the locking somewhat
> and probably changes the timing so that might be the culprit.
>
> I am trying to figure out if there is an interface that would let
> ns_last_pid for a pid namespace be accessed before the first pid is
> allocated and I am not seeing it.  It does not appear to be possible
> to mount a proc for a pid namespace you are not currently in.
>
> *Scratches my head*  I am not seeing anything obvious.

Can you try this patch as you reproduce this issue?

diff --git a/kernel/pid.c b/kernel/pid.c
index b13b624e2c49..df9e5d4d8f83 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -210,6 +210,7 @@ struct pid *alloc_pid(struct pid_namespace *ns)
goto out_unlock;
for ( ; upid >= pid->numbers; --upid) {
/* Make the PID visible to find_pid_ns. */
+   WARN_ON(!upid->ns->proc_mnt);
idr_replace(>ns->idr, pid, upid->nr);
upid->ns->pid_allocated++;
}


If the warning triggers it means the bug is in alloc_pid and somehow
something has gotten past the is_child_reaper check.

If the warning does not trigger it means something is stomping proc_mnt.

In the entire kernel there are exactly two assignments to proc_mnt.
- kmem_cache_zalloc in create_pid_namespace.
- In pid_ns_prepare_proc where proc_mnt is set to a non-zero value.

On the 29th of Nov syzkaller also hit this and gave me this reproducer
that I can't figure out heads or tails of.

#{Threaded:true Collide:true Repeat:true Procs:8 Sandbox:namespace Fault:false 
FaultCall:-1 FaultNth:0 EnableTun:true UseTmpDir:true HandleSegv:true 
WaitRepeat:true Debug:false Repro:false}
mmap(&(0x7f00/0xfff000)=nil, 0xfff000, 0x3, 0x32, 0x, 
0x0)
perf_event_open(&(0x7f25c000)={0x2, 0x78, 0x3e3, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0xf72, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0}, 0x0, 0x, 0x, 0x0)
socket$inet6_dccp(0xa, 0x6, 0x0)
unshare(0x2400)
sendmsg$unix(0x, 
&(0x7f001000-0x38)={&(0x7f239000-0x8)=@abs={0x0, 0x0, 0x0}, 0x8, 
&(0x7f008000)=[], 0x0, &(0x7f001000-0x10)=[@rights={0x200, 0x1, 0x1, 
[0x]}], 0x1, 0x0}, 0x0)
process_vm_writev(0x0, 
&(0x7f699000-0x70)=[{&(0x7f6a5000)="",
 0x4c}, {&(0x7f7b9000-0x54)="", 0x0}, {&(0x7f4f3000)="", 0x0}, 
{&(0x7f2e3000-0xd6)="",
 0xd6}, 
{&(0x7ff2e000)="",
 0x52}, {&(0x7f8e5000-0x10)="", 0x10}, 
{&(0x7fa3a000)="", 0x0}], 0x7, &(0x7fd05000)=[{&(0x7fd64000)="", 
0x0}, 

[PATCH v3,net-next] ip6_gre: fix a pontential issue in ip6erspan_rcv

[Haishuang Yan]

pskb_may_pull() can change skb->data, so we need to load ipv6h/ershdr at
the right place.

Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support")
Cc: William Tu 
Acked-by: William Tu 
Signed-off-by: Haishuang Yan 

---
Change since v3:
  * Rebase on latest master branch.
  * Fix wrong commit information.
---
 net/ipv6/ip6_gre.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 87b9892..9bd1103 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -507,12 +507,11 @@ static int ip6erspan_rcv(struct sk_buff *skb, int 
gre_hdr_len,
struct ip6_tnl *tunnel;
u8 ver;
 
-   ipv6h = ipv6_hdr(skb);
-   ershdr = (struct erspan_base_hdr *)skb->data;
-
if (unlikely(!pskb_may_pull(skb, sizeof(*ershdr
return PACKET_REJECT;
 
+   ipv6h = ipv6_hdr(skb);
+   ershdr = (struct erspan_base_hdr *)skb->data;
ver = (ntohs(ershdr->ver_vlan) & VER_MASK) >> VER_OFFSET;
tpi->key = cpu_to_be32(ntohs(ershdr->session_id) & ID_MASK);
 
-- 
1.8.3.1

[PATCH v3,net-next] ip6_gre: fix a pontential issue in ip6erspan_rcv

[Haishuang Yan]

pskb_may_pull() can change skb->data, so we need to load ipv6h/ershdr at
the right place.

Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support")
Cc: William Tu 
Acked-by: William Tu 
Signed-off-by: Haishuang Yan 

---
Change since v3:
  * Rebase on latest master branch.
  * Fix wrong commit information.
---
 net/ipv6/ip6_gre.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 87b9892..9bd1103 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -507,12 +507,11 @@ static int ip6erspan_rcv(struct sk_buff *skb, int 
gre_hdr_len,
struct ip6_tnl *tunnel;
u8 ver;
 
-   ipv6h = ipv6_hdr(skb);
-   ershdr = (struct erspan_base_hdr *)skb->data;
-
if (unlikely(!pskb_may_pull(skb, sizeof(*ershdr
return PACKET_REJECT;
 
+   ipv6h = ipv6_hdr(skb);
+   ershdr = (struct erspan_base_hdr *)skb->data;
ver = (ntohs(ershdr->ver_vlan) & VER_MASK) >> VER_OFFSET;
tpi->key = cpu_to_be32(ntohs(ershdr->session_id) & ID_MASK);
 
-- 
1.8.3.1

Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures

[Matthew Wilcox]

On Tue, Dec 19, 2017 at 04:20:51PM -0800, Paul E. McKenney wrote:
> If we are going to make this sort of change, we should do so in a way
> that allows the slab code to actually do the optimizations that might
> make this sort of thing worthwhile.  After all, if the main goal was small
> code size, the best approach is to drop kfree_bulk() and get on with life
> in the usual fashion.
> 
> I would prefer to believe that something like kfree_bulk() can help,
> and if that is the case, we should give it a chance to do things like
> group kfree_rcu() requests by destination slab and soforth, allowing
> batching optimizations that might provide more significant increases
> in performance.  Furthermore, having this in slab opens the door to
> slab taking emergency action when memory is low.

kfree_bulk does sort by destination slab; look at build_detached_freelist.

Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures

[Matthew Wilcox]

On Tue, Dec 19, 2017 at 04:20:51PM -0800, Paul E. McKenney wrote:
> If we are going to make this sort of change, we should do so in a way
> that allows the slab code to actually do the optimizations that might
> make this sort of thing worthwhile.  After all, if the main goal was small
> code size, the best approach is to drop kfree_bulk() and get on with life
> in the usual fashion.
> 
> I would prefer to believe that something like kfree_bulk() can help,
> and if that is the case, we should give it a chance to do things like
> group kfree_rcu() requests by destination slab and soforth, allowing
> batching optimizations that might provide more significant increases
> in performance.  Furthermore, having this in slab opens the door to
> slab taking emergency action when memory is low.

kfree_bulk does sort by destination slab; look at build_detached_freelist.

Re: [PATCH v4 0/5] Add Intel IOMMU debugfs support

[Mehta, Sohil]

On Tue, 2017-12-19 at 23:25 +0200, Andy Shevchenko wrote:
> 
> Perhaps you need to switch to SPDX license pointer.
> I dunno if Thomas' patch with documentation how to do this made
> upstream
>  / linux-next yet.
> 

Thanks. I found the information at https://patchwork.kernel.org/patch/1
0091607/. 
I'll replace the GPL 2.0 license information in intel-iommu-debug.c
with the tag:
// SPDX-License-Identifier: GPL-2.0

Re: [PATCH v4 0/5] Add Intel IOMMU debugfs support

[Mehta, Sohil]

On Tue, 2017-12-19 at 23:25 +0200, Andy Shevchenko wrote:
> 
> Perhaps you need to switch to SPDX license pointer.
> I dunno if Thomas' patch with documentation how to do this made
> upstream
>  / linux-next yet.
> 

Thanks. I found the information at https://patchwork.kernel.org/patch/1
0091607/. 
I'll replace the GPL 2.0 license information in intel-iommu-debug.c
with the tag:
// SPDX-License-Identifier: GPL-2.0

Re: [v2 PATCH -tip 1/6] net: tcp: Add trace events for TCP congestion window tracing

[kbuild test robot]

Hi Masami,

I love your patch! Yet something to improve:

[auto build test ERROR on net/master]
[also build test ERROR on v4.15-rc4 next-20171219]
[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/Masami-Hiramatsu/net-tcp-sctp-dccp-Replace-jprobe-usage-with-trace-events/20171220-081035
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh 

All error/warnings (new ones prefixed by >>):

   In file included from include/trace/events/udp.h:9:0,
from net//core/net-traces.c:35:
>> include/trace/events/tcp.h:37:11: error: expected ')' before 'const'
 TP_PROTO(const struct sock *sk, const struct sk_buff *skb),
  ^
   include/linux/tracepoint.h:105:27: note: in definition of macro 'TP_PROTO'
#define TP_PROTO(args...) args
  ^~~~
>> include/linux/tracepoint.h:237:20: error: redefinition of 
>> '__tpstrtab_tcp_retransmit_skb'
 static const char __tpstrtab_##name[] \
   ^
>> include/linux/tracepoint.h:247:2: note: in expansion of macro 
>> 'DEFINE_TRACE_FN'
 DEFINE_TRACE_FN(name, NULL, NULL);
 ^~~
>> include/trace/define_trace.h:51:2: note: in expansion of macro 'DEFINE_TRACE'
 DEFINE_TRACE(name)
 ^~~~
>> include/trace/events/tcp.h:90:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(tcp_event_sk_skb, tcp_retransmit_skb,
^~~~
   In file included from include/trace/events/tcp.h:10:0,
from net//core/net-traces.c:34:
   include/linux/tracepoint.h:237:20: note: previous definition of 
'__tpstrtab_tcp_retransmit_skb' was here
 static const char __tpstrtab_##name[] \
   ^
>> include/linux/tracepoint.h:247:2: note: in expansion of macro 
>> 'DEFINE_TRACE_FN'
 DEFINE_TRACE_FN(name, NULL, NULL);
 ^~~
>> include/trace/define_trace.h:51:2: note: in expansion of macro 'DEFINE_TRACE'
 DEFINE_TRACE(name)
 ^~~~
>> include/trace/events/tcp.h:90:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(tcp_event_sk_skb, tcp_retransmit_skb,
^~~~
   In file included from include/trace/events/udp.h:9:0,
from net//core/net-traces.c:35:
   include/linux/tracepoint.h:239:20: error: redefinition of 
'__tracepoint_tcp_retransmit_skb'
 struct tracepoint __tracepoint_##name \
   ^
>> include/linux/tracepoint.h:247:2: note: in expansion of macro 
>> 'DEFINE_TRACE_FN'
 DEFINE_TRACE_FN(name, NULL, NULL);
 ^~~
>> include/trace/define_trace.h:51:2: note: in expansion of macro 'DEFINE_TRACE'
 DEFINE_TRACE(name)
 ^~~~
>> include/trace/events/tcp.h:90:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(tcp_event_sk_skb, tcp_retransmit_skb,
^~~~
   In file included from include/trace/events/tcp.h:10:0,
from net//core/net-traces.c:34:
   include/linux/tracepoint.h:239:20: note: previous definition of 
'__tracepoint_tcp_retransmit_skb' was here
 struct tracepoint __tracepoint_##name \
   ^
>> include/linux/tracepoint.h:247:2: note: in expansion of macro 
>> 'DEFINE_TRACE_FN'
 DEFINE_TRACE_FN(name, NULL, NULL);
 ^~~
>> include/trace/define_trace.h:51:2: note: in expansion of macro 'DEFINE_TRACE'
 DEFINE_TRACE(name)
 ^~~~
>> include/trace/events/tcp.h:90:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(tcp_event_sk_skb, tcp_retransmit_skb,
^~~~
   In file included from include/trace/events/udp.h:9:0,
from net//core/net-traces.c:35:
>> include/linux/tracepoint.h:242:35: error: redefinition of 
>> '__tracepoint_ptr_tcp_retransmit_skb'
 static struct tracepoint * const __tracepoint_ptr_##name __used  \
  ^
>> include/linux/tracepoint.h:247:2: note: in expansion of macro 
>> 'DEFINE_TRACE_FN'
 DEFINE_TRACE_FN(name, NULL, NULL);
 ^~~
>> include/trace/define_trace.h:51:2: note: in expansion of macro 'DEFINE_TRACE'
 DEFINE_TRACE(name)
 ^~~~
>> include/trace/events/tcp.h:90:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(tcp_event_sk_skb, tcp_retransmit_skb,
^~~~
   In file included from include/trace/events/tcp.h:10:0,
from net//core/net-traces.c:34:
   include/linux/tracepoint

Re: [v2 PATCH -tip 1/6] net: tcp: Add trace events for TCP congestion window tracing

[kbuild test robot]

Hi Masami,

I love your patch! Yet something to improve:

[auto build test ERROR on net/master]
[also build test ERROR on v4.15-rc4 next-20171219]
[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/Masami-Hiramatsu/net-tcp-sctp-dccp-Replace-jprobe-usage-with-trace-events/20171220-081035
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh 

All error/warnings (new ones prefixed by >>):

   In file included from include/trace/events/udp.h:9:0,
from net//core/net-traces.c:35:
>> include/trace/events/tcp.h:37:11: error: expected ')' before 'const'
 TP_PROTO(const struct sock *sk, const struct sk_buff *skb),
  ^
   include/linux/tracepoint.h:105:27: note: in definition of macro 'TP_PROTO'
#define TP_PROTO(args...) args
  ^~~~
>> include/linux/tracepoint.h:237:20: error: redefinition of 
>> '__tpstrtab_tcp_retransmit_skb'
 static const char __tpstrtab_##name[] \
   ^
>> include/linux/tracepoint.h:247:2: note: in expansion of macro 
>> 'DEFINE_TRACE_FN'
 DEFINE_TRACE_FN(name, NULL, NULL);
 ^~~
>> include/trace/define_trace.h:51:2: note: in expansion of macro 'DEFINE_TRACE'
 DEFINE_TRACE(name)
 ^~~~
>> include/trace/events/tcp.h:90:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(tcp_event_sk_skb, tcp_retransmit_skb,
^~~~
   In file included from include/trace/events/tcp.h:10:0,
from net//core/net-traces.c:34:
   include/linux/tracepoint.h:237:20: note: previous definition of 
'__tpstrtab_tcp_retransmit_skb' was here
 static const char __tpstrtab_##name[] \
   ^
>> include/linux/tracepoint.h:247:2: note: in expansion of macro 
>> 'DEFINE_TRACE_FN'
 DEFINE_TRACE_FN(name, NULL, NULL);
 ^~~
>> include/trace/define_trace.h:51:2: note: in expansion of macro 'DEFINE_TRACE'
 DEFINE_TRACE(name)
 ^~~~
>> include/trace/events/tcp.h:90:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(tcp_event_sk_skb, tcp_retransmit_skb,
^~~~
   In file included from include/trace/events/udp.h:9:0,
from net//core/net-traces.c:35:
   include/linux/tracepoint.h:239:20: error: redefinition of 
'__tracepoint_tcp_retransmit_skb'
 struct tracepoint __tracepoint_##name \
   ^
>> include/linux/tracepoint.h:247:2: note: in expansion of macro 
>> 'DEFINE_TRACE_FN'
 DEFINE_TRACE_FN(name, NULL, NULL);
 ^~~
>> include/trace/define_trace.h:51:2: note: in expansion of macro 'DEFINE_TRACE'
 DEFINE_TRACE(name)
 ^~~~
>> include/trace/events/tcp.h:90:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(tcp_event_sk_skb, tcp_retransmit_skb,
^~~~
   In file included from include/trace/events/tcp.h:10:0,
from net//core/net-traces.c:34:
   include/linux/tracepoint.h:239:20: note: previous definition of 
'__tracepoint_tcp_retransmit_skb' was here
 struct tracepoint __tracepoint_##name \
   ^
>> include/linux/tracepoint.h:247:2: note: in expansion of macro 
>> 'DEFINE_TRACE_FN'
 DEFINE_TRACE_FN(name, NULL, NULL);
 ^~~
>> include/trace/define_trace.h:51:2: note: in expansion of macro 'DEFINE_TRACE'
 DEFINE_TRACE(name)
 ^~~~
>> include/trace/events/tcp.h:90:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(tcp_event_sk_skb, tcp_retransmit_skb,
^~~~
   In file included from include/trace/events/udp.h:9:0,
from net//core/net-traces.c:35:
>> include/linux/tracepoint.h:242:35: error: redefinition of 
>> '__tracepoint_ptr_tcp_retransmit_skb'
 static struct tracepoint * const __tracepoint_ptr_##name __used  \
  ^
>> include/linux/tracepoint.h:247:2: note: in expansion of macro 
>> 'DEFINE_TRACE_FN'
 DEFINE_TRACE_FN(name, NULL, NULL);
 ^~~
>> include/trace/define_trace.h:51:2: note: in expansion of macro 'DEFINE_TRACE'
 DEFINE_TRACE(name)
 ^~~~
>> include/trace/events/tcp.h:90:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(tcp_event_sk_skb, tcp_retransmit_skb,
^~~~
   In file included from include/trace/events/tcp.h:10:0,
from net//core/net-traces.c:34:
   include/linux/tracepoint

Re: [PATCH] tools/power: Don't make man pages executable

[Rafael J. Wysocki]

On 12/20/2017 1:36 AM, Laura Abbott wrote:

On 12/19/2017 03:48 PM, Rafael J. Wysocki wrote:

On 12/19/2017 8:54 PM, Laura Abbott wrote:

rpm-lint flagged these as being executable:

kernel-tools.x86_64: W: spurious-executable-perm 
/usr/share/man/man8/turbostat.8.gz
kernel-tools.x86_64: W: spurious-executable-perm 
/usr/share/man/man8/x86_energy_perf_policy.8.gz


Fix this

Signed-off-by: Laura Abbott 


Please CC PM stuff to linux-pm (which makes it easier to handle).



Neither of these are listed in MAINTAINERS so I missed sending to
linux-pm. I'll remember for next time, do you want me to resend
for tracking?



Yes, please.

Thanks,
Rafael





---
  tools/power/x86/turbostat/Makefile  | 2 +-
  tools/power/x86/x86_energy_perf_policy/Makefile | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/power/x86/turbostat/Makefile 
b/tools/power/x86/turbostat/Makefile

index a9bc914a8fe8..2ab25aa38263 100644
--- a/tools/power/x86/turbostat/Makefile
+++ b/tools/power/x86/turbostat/Makefile
@@ -25,4 +25,4 @@ install : turbostat
  install -d  $(DESTDIR)$(PREFIX)/bin
  install $(BUILD_OUTPUT)/turbostat 
$(DESTDIR)$(PREFIX)/bin/turbostat

  install -d  $(DESTDIR)$(PREFIX)/share/man/man8
-    install turbostat.8 $(DESTDIR)$(PREFIX)/share/man/man8
+    install -m 644 turbostat.8 $(DESTDIR)$(PREFIX)/share/man/man8
diff --git a/tools/power/x86/x86_energy_perf_policy/Makefile 
b/tools/power/x86/x86_energy_perf_policy/Makefile

index 2447b1bbaacf..f4534fb8b951 100644
--- a/tools/power/x86/x86_energy_perf_policy/Makefile
+++ b/tools/power/x86/x86_energy_perf_policy/Makefile
@@ -24,5 +24,5 @@ install : x86_energy_perf_policy
  install -d  $(DESTDIR)$(PREFIX)/bin
  install $(BUILD_OUTPUT)/x86_energy_perf_policy 
$(DESTDIR)$(PREFIX)/bin/x86_energy_perf_policy

  install -d  $(DESTDIR)$(PREFIX)/share/man/man8
-    install x86_energy_perf_policy.8 
$(DESTDIR)$(PREFIX)/share/man/man8
+    install -m 644 x86_energy_perf_policy.8 
$(DESTDIR)$(PREFIX)/share/man/man8



Thanks,

Rafael

Re: [PATCH] tools/power: Don't make man pages executable

[Rafael J. Wysocki]

On 12/20/2017 1:36 AM, Laura Abbott wrote:

On 12/19/2017 03:48 PM, Rafael J. Wysocki wrote:

On 12/19/2017 8:54 PM, Laura Abbott wrote:

rpm-lint flagged these as being executable:

kernel-tools.x86_64: W: spurious-executable-perm 
/usr/share/man/man8/turbostat.8.gz
kernel-tools.x86_64: W: spurious-executable-perm 
/usr/share/man/man8/x86_energy_perf_policy.8.gz


Fix this

Signed-off-by: Laura Abbott 


Please CC PM stuff to linux-pm (which makes it easier to handle).



Neither of these are listed in MAINTAINERS so I missed sending to
linux-pm. I'll remember for next time, do you want me to resend
for tracking?



Yes, please.

Thanks,
Rafael





---
  tools/power/x86/turbostat/Makefile  | 2 +-
  tools/power/x86/x86_energy_perf_policy/Makefile | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/power/x86/turbostat/Makefile 
b/tools/power/x86/turbostat/Makefile

index a9bc914a8fe8..2ab25aa38263 100644
--- a/tools/power/x86/turbostat/Makefile
+++ b/tools/power/x86/turbostat/Makefile
@@ -25,4 +25,4 @@ install : turbostat
  install -d  $(DESTDIR)$(PREFIX)/bin
  install $(BUILD_OUTPUT)/turbostat 
$(DESTDIR)$(PREFIX)/bin/turbostat

  install -d  $(DESTDIR)$(PREFIX)/share/man/man8
-    install turbostat.8 $(DESTDIR)$(PREFIX)/share/man/man8
+    install -m 644 turbostat.8 $(DESTDIR)$(PREFIX)/share/man/man8
diff --git a/tools/power/x86/x86_energy_perf_policy/Makefile 
b/tools/power/x86/x86_energy_perf_policy/Makefile

index 2447b1bbaacf..f4534fb8b951 100644
--- a/tools/power/x86/x86_energy_perf_policy/Makefile
+++ b/tools/power/x86/x86_energy_perf_policy/Makefile
@@ -24,5 +24,5 @@ install : x86_energy_perf_policy
  install -d  $(DESTDIR)$(PREFIX)/bin
  install $(BUILD_OUTPUT)/x86_energy_perf_policy 
$(DESTDIR)$(PREFIX)/bin/x86_energy_perf_policy

  install -d  $(DESTDIR)$(PREFIX)/share/man/man8
-    install x86_energy_perf_policy.8 
$(DESTDIR)$(PREFIX)/share/man/man8
+    install -m 644 x86_energy_perf_policy.8 
$(DESTDIR)$(PREFIX)/share/man/man8



Thanks,

Rafael

Re: [PATCH] mm: thp: use down_read_trylock in khugepaged to avoid long block

[Yang Shi]

On 12/18/17 12:41 AM, Michal Hocko wrote:

On Sat 16-12-17 23:09:25, Kirill A. Shutemov wrote:

On Sat, Dec 16, 2017 at 12:45:25PM +0100, Michal Hocko wrote:

On Sat 16-12-17 04:04:10, Yang Shi wrote:

[...]

Shall we add "cond_resched()" in unmap_vmas(), i.e for every 100 vmas? It
may improve the responsiveness a little bit for non-preempt kernel, although
it still can't release the semaphore.


We already do, once per pmd (see zap_pmd_range).


It doesn't help. We would need to find a way to drop mmap_sem, if we're
holding it way too long. And doing it on per-vma count basis is not right
call. It won't address issue with single huge vma.


Absolutely agreed. I just wanted to point out that a new cond_resched is
not really needed. One way to reduce the lock starvation is to use range
locking.


It looks the range locking development is stalled?

Yang




Do we have any instrumentation that would help detect starvation on a
rw_semaphore?


I am afraid we don't.

Re: [PATCH] mm: thp: use down_read_trylock in khugepaged to avoid long block

[Yang Shi]

On 12/18/17 12:41 AM, Michal Hocko wrote:

On Sat 16-12-17 23:09:25, Kirill A. Shutemov wrote:

On Sat, Dec 16, 2017 at 12:45:25PM +0100, Michal Hocko wrote:

On Sat 16-12-17 04:04:10, Yang Shi wrote:

[...]

Shall we add "cond_resched()" in unmap_vmas(), i.e for every 100 vmas? It
may improve the responsiveness a little bit for non-preempt kernel, although
it still can't release the semaphore.


We already do, once per pmd (see zap_pmd_range).


It doesn't help. We would need to find a way to drop mmap_sem, if we're
holding it way too long. And doing it on per-vma count basis is not right
call. It won't address issue with single huge vma.


Absolutely agreed. I just wanted to point out that a new cond_resched is
not really needed. One way to reduce the lock starvation is to use range
locking.


It looks the range locking development is stalled?

Yang




Do we have any instrumentation that would help detect starvation on a
rw_semaphore?


I am afraid we don't.

Re: [PATCH v2,net-next 1/2] ip_gre: fix potential memory leak in erspan_rcv

[Haishuang Yan]

> On 2017年12月19日, at 下午11:36, David Miller  wrote:
> 
> From: Haishuang Yan 
> Date: Sat, 16 Dec 2017 10:48:38 +0800
> 
>> If md is NULL, tun_dst must be freed, otherwise it will cause memory
>> leak.
>> 
>> Fixes: 1a66a836da6 ("gre: add collect_md mode to ERSPAN tunnel")
>> Cc: William Tu 
>> Signed-off-by: Haishuang Yan 
>> 
>> Change since v2:
>>  * Rebase on latest master branch.
>>  * Correct wrong fix information.
> 
> Please do not put a changelog after the fixes and signoff tags, those tags 
> must
> appear last in the commit message.
> 
> Thank you.
> 

Okay, I will resubmit another commit, thanks.

Re: [PATCH v2,net-next 1/2] ip_gre: fix potential memory leak in erspan_rcv

[Haishuang Yan]

> On 2017年12月19日, at 下午11:36, David Miller  wrote:
> 
> From: Haishuang Yan 
> Date: Sat, 16 Dec 2017 10:48:38 +0800
> 
>> If md is NULL, tun_dst must be freed, otherwise it will cause memory
>> leak.
>> 
>> Fixes: 1a66a836da6 ("gre: add collect_md mode to ERSPAN tunnel")
>> Cc: William Tu 
>> Signed-off-by: Haishuang Yan 
>> 
>> Change since v2:
>>  * Rebase on latest master branch.
>>  * Correct wrong fix information.
> 
> Please do not put a changelog after the fixes and signoff tags, those tags 
> must
> appear last in the commit message.
> 
> Thank you.
> 

Okay, I will resubmit another commit, thanks.

Re: [PATCH v2,net-next] ip6_gre: fix a pontential issue in ip6erspan_rcv

[Haishuang Yan]

> On 2017年12月19日, at 下午11:34, David Miller  wrote:
> 
> From: Haishuang Yan 
> Date: Sat, 16 Dec 2017 10:25:25 +0800
> 
>> pskb_may_pull() can change skb->data, so we need to load ipv6h/ershdr at
>> the right place.
>> 
>> Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support")
>> Acked-by: William Tu 
>> Cc: William Tu 
>> Signed-off-by: Haishuang Yan 
> 
> This patch does not apply:
> 
>> +ipv6h = ipv6_hdr(skb);
>> +ershdr = (struct erspan_base_hdr *)skb->data;
>>  ver = (ntohs(ershdr->ver_vlan) & VER_MASK) >> VER_OFFSET;
>>  tpi->key = cpu_to_be32(ntohs(ershdr->session_id) & ID_MASK);
>>  pkt_md = (struct erspan_metadata *)(ershdr + 1);
> 
> There is not "pkt_md = ..." assignment in net-next on this line.
> 

Okay, I will fix it and resubmit another commit, thanks.

Re: [PATCH v2,net-next] ip6_gre: fix a pontential issue in ip6erspan_rcv

[Haishuang Yan]

> On 2017年12月19日, at 下午11:34, David Miller  wrote:
> 
> From: Haishuang Yan 
> Date: Sat, 16 Dec 2017 10:25:25 +0800
> 
>> pskb_may_pull() can change skb->data, so we need to load ipv6h/ershdr at
>> the right place.
>> 
>> Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support")
>> Acked-by: William Tu 
>> Cc: William Tu 
>> Signed-off-by: Haishuang Yan 
> 
> This patch does not apply:
> 
>> +ipv6h = ipv6_hdr(skb);
>> +ershdr = (struct erspan_base_hdr *)skb->data;
>>  ver = (ntohs(ershdr->ver_vlan) & VER_MASK) >> VER_OFFSET;
>>  tpi->key = cpu_to_be32(ntohs(ershdr->session_id) & ID_MASK);
>>  pkt_md = (struct erspan_metadata *)(ershdr + 1);
> 
> There is not "pkt_md = ..." assignment in net-next on this line.
> 

Okay, I will fix it and resubmit another commit, thanks.

[PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations

[Huang, Ying]

From: Huang Ying 

When the swapin is performed, after getting the swap entry information
from the page table, system will swap in the swap entry, without any
lock held to prevent the swap device from being swapoff.  This may
cause the race like below,

CPU 1   CPU 2
-   -
do_swap_page
  swapin_readahead
__read_swap_cache_async
swapoff   swapcache_prepare
  p->swap_map = NULL__swap_duplicate
  p->swap_map[?] /* !!! NULL pointer 
access */

Because swapoff is usually done when system shutdown only, the race
may not hit many people in practice.  But it is still a race need to
be fixed.

To fix the race, get_swap_device() is added to check whether the
specified swap entry is valid in its swap device.  If so, it will keep
the swap entry valid via preventing the swap device from being
swapoff, until put_swap_device() is called.

Because swapoff() is very race code path, to make the normal path runs
as fast as possible, RCU instead of reference count is used to
implement get/put_swap_device().  From get_swap_device() to
put_swap_device(), the RCU read lock is held, so synchronize_rcu() in
swapoff() will wait until put_swap_device() is called.

In addition to swap_map, cluster_info, etc. data structure in the
struct swap_info_struct, the swap cache radix tree will be freed after
swapoff, so this patch fixes the race between swap cache looking up
and swapoff too.

Cc: Hugh Dickins 
Cc: Paul E. McKenney 
Cc: Minchan Kim 
Cc: Johannes Weiner 
Cc: Tim Chen 
Cc: Shaohua Li 
Cc: Mel Gorman 
Cc: "Jérôme Glisse" 
Cc: Michal Hocko 
Cc: Andrea Arcangeli 
Cc: David Rientjes 
Cc: Rik van Riel 
Cc: Jan Kara 
Cc: Dave Jiang 
Cc: Aaron Lu 
Signed-off-by: "Huang, Ying" 

Changelog:

v4:

- Use synchronize_rcu() in enable_swap_info() to reduce overhead of
  normal paths further.

v3:

- Re-implemented with RCU to reduce the overhead of normal paths

v2:

- Re-implemented with SRCU to reduce the overhead of normal paths.

- Avoid to check whether the swap device has been swapoff in
  get_swap_device().  Because we can check the origin of the swap
  entry to make sure the swap device hasn't bee swapoff.
---
 include/linux/swap.h |  11 -
 mm/memory.c  |   2 +-
 mm/swap_state.c  |  16 +--
 mm/swapfile.c| 123 ++-
 4 files changed, 116 insertions(+), 36 deletions(-)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index 2417d288e016..f7e8f26cf07f 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -172,8 +172,9 @@ enum {
SWP_PAGE_DISCARD = (1 << 9),/* freed swap page-cluster discards */
SWP_STABLE_WRITES = (1 << 10),  /* no overwrite PG_writeback pages */
SWP_SYNCHRONOUS_IO = (1 << 11), /* synchronous IO is efficient */
+   SWP_VALID   = (1 << 12),/* swap is valid to be operated on? */
/* add others here before... */
-   SWP_SCANNING= (1 << 12),/* refcount in scan_swap_map */
+   SWP_SCANNING= (1 << 13),/* refcount in scan_swap_map */
 };
 
 #define SWAP_CLUSTER_MAX 32UL
@@ -460,7 +461,7 @@ extern unsigned int count_swap_pages(int, int);
 extern sector_t map_swap_page(struct page *, struct block_device **);
 extern sector_t swapdev_block(int, pgoff_t);
 extern int page_swapcount(struct page *);
-extern int __swap_count(struct swap_info_struct *si, swp_entry_t entry);
+extern int __swap_count(swp_entry_t entry);
 extern int __swp_swapcount(swp_entry_t entry);
 extern int swp_swapcount(swp_entry_t entry);
 extern struct swap_info_struct *page_swap_info(struct page *);
@@ -470,6 +471,12 @@ extern int try_to_free_swap(struct page *);
 struct backing_dev_info;
 extern int init_swap_address_space(unsigned int type, unsigned long nr_pages);
 extern void exit_swap_address_space(unsigned int type);
+extern struct swap_info_struct *get_swap_device(swp_entry_t entry);
+
+static inline void put_swap_device(struct swap_info_struct *si)
+{
+   rcu_read_unlock();
+}
 
 #else /* CONFIG_SWAP */
 
diff --git a/mm/memory.c b/mm/memory.c
index 1a969992f76b..77a7d6191218 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2909,7 +2909,7 @@ int do_swap_page(struct vm_fault *vmf)
struct swap_info_struct *si = swp_swap_info(entry);
 
if (si->flags & SWP_SYNCHRONOUS_IO &&
-   __swap_count(si, entry) == 1) {
+

[PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations

[Huang, Ying]

From: Huang Ying 

When the swapin is performed, after getting the swap entry information
from the page table, system will swap in the swap entry, without any
lock held to prevent the swap device from being swapoff.  This may
cause the race like below,

CPU 1   CPU 2
-   -
do_swap_page
  swapin_readahead
__read_swap_cache_async
swapoff   swapcache_prepare
  p->swap_map = NULL__swap_duplicate
  p->swap_map[?] /* !!! NULL pointer 
access */

Because swapoff is usually done when system shutdown only, the race
may not hit many people in practice.  But it is still a race need to
be fixed.

To fix the race, get_swap_device() is added to check whether the
specified swap entry is valid in its swap device.  If so, it will keep
the swap entry valid via preventing the swap device from being
swapoff, until put_swap_device() is called.

Because swapoff() is very race code path, to make the normal path runs
as fast as possible, RCU instead of reference count is used to
implement get/put_swap_device().  From get_swap_device() to
put_swap_device(), the RCU read lock is held, so synchronize_rcu() in
swapoff() will wait until put_swap_device() is called.

In addition to swap_map, cluster_info, etc. data structure in the
struct swap_info_struct, the swap cache radix tree will be freed after
swapoff, so this patch fixes the race between swap cache looking up
and swapoff too.

Cc: Hugh Dickins 
Cc: Paul E. McKenney 
Cc: Minchan Kim 
Cc: Johannes Weiner 
Cc: Tim Chen 
Cc: Shaohua Li 
Cc: Mel Gorman 
Cc: "Jérôme Glisse" 
Cc: Michal Hocko 
Cc: Andrea Arcangeli 
Cc: David Rientjes 
Cc: Rik van Riel 
Cc: Jan Kara 
Cc: Dave Jiang 
Cc: Aaron Lu 
Signed-off-by: "Huang, Ying" 

Changelog:

v4:

- Use synchronize_rcu() in enable_swap_info() to reduce overhead of
  normal paths further.

v3:

- Re-implemented with RCU to reduce the overhead of normal paths

v2:

- Re-implemented with SRCU to reduce the overhead of normal paths.

- Avoid to check whether the swap device has been swapoff in
  get_swap_device().  Because we can check the origin of the swap
  entry to make sure the swap device hasn't bee swapoff.
---
 include/linux/swap.h |  11 -
 mm/memory.c  |   2 +-
 mm/swap_state.c  |  16 +--
 mm/swapfile.c| 123 ++-
 4 files changed, 116 insertions(+), 36 deletions(-)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index 2417d288e016..f7e8f26cf07f 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -172,8 +172,9 @@ enum {
SWP_PAGE_DISCARD = (1 << 9),/* freed swap page-cluster discards */
SWP_STABLE_WRITES = (1 << 10),  /* no overwrite PG_writeback pages */
SWP_SYNCHRONOUS_IO = (1 << 11), /* synchronous IO is efficient */
+   SWP_VALID   = (1 << 12),/* swap is valid to be operated on? */
/* add others here before... */
-   SWP_SCANNING= (1 << 12),/* refcount in scan_swap_map */
+   SWP_SCANNING= (1 << 13),/* refcount in scan_swap_map */
 };
 
 #define SWAP_CLUSTER_MAX 32UL
@@ -460,7 +461,7 @@ extern unsigned int count_swap_pages(int, int);
 extern sector_t map_swap_page(struct page *, struct block_device **);
 extern sector_t swapdev_block(int, pgoff_t);
 extern int page_swapcount(struct page *);
-extern int __swap_count(struct swap_info_struct *si, swp_entry_t entry);
+extern int __swap_count(swp_entry_t entry);
 extern int __swp_swapcount(swp_entry_t entry);
 extern int swp_swapcount(swp_entry_t entry);
 extern struct swap_info_struct *page_swap_info(struct page *);
@@ -470,6 +471,12 @@ extern int try_to_free_swap(struct page *);
 struct backing_dev_info;
 extern int init_swap_address_space(unsigned int type, unsigned long nr_pages);
 extern void exit_swap_address_space(unsigned int type);
+extern struct swap_info_struct *get_swap_device(swp_entry_t entry);
+
+static inline void put_swap_device(struct swap_info_struct *si)
+{
+   rcu_read_unlock();
+}
 
 #else /* CONFIG_SWAP */
 
diff --git a/mm/memory.c b/mm/memory.c
index 1a969992f76b..77a7d6191218 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2909,7 +2909,7 @@ int do_swap_page(struct vm_fault *vmf)
struct swap_info_struct *si = swp_swap_info(entry);
 
if (si->flags & SWP_SYNCHRONOUS_IO &&
-   __swap_count(si, entry) == 1) {
+   __swap_count(entry) == 1) {
/* skip swapcache */
page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma,
vmf->address);
diff --git a/mm/swap_state.c b/mm/swap_state.c
index 0b8ae361981f..8dde719e973c 100644
--- a/mm/swap_state.c
+++ 

Re: [PATCH v4 2/2] kbuild: Cache a few more calls to the compiler

[Dave Hansen]

I'm seeing some build breakage that I bisected to commit 4e56207130eda:

>   CC  kernel/bounds.s
> In file included from /home/davehans/linux.git/include/asm-generic/bug.h:15:0,
>  from /home/davehans/linux.git/arch/x86/include/asm/bug.h:81,
>  from /home/davehans/linux.git/include/linux/bug.h:4,
>  from /home/davehans/linux.git/include/linux/page-flags.h:9,
>  from /home/davehans/linux.git/kernel/bounds.c:9:
> /home/davehans/linux.git/include/linux/kernel.h:5:20: fatal error: stdarg.h: 
> No such file or directory
>  #include 
> ^
> compilation terminated.

It's odd because I'm pretty sure I've done 4.15-rc compiles on this
system before without issues.  I suspect something in my config
(attached) is triggering this.

Does this look familiar to anyone?

gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.4.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 6.4.1 20170727 (Red Hat 6.4.1-1) (GCC)

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.14.0-rc3 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
CONFIG_IRQ_TIME_ACCOUNTING=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y

Re: [PATCH v4 2/2] kbuild: Cache a few more calls to the compiler

[Dave Hansen]

I'm seeing some build breakage that I bisected to commit 4e56207130eda:

>   CC  kernel/bounds.s
> In file included from /home/davehans/linux.git/include/asm-generic/bug.h:15:0,
>  from /home/davehans/linux.git/arch/x86/include/asm/bug.h:81,
>  from /home/davehans/linux.git/include/linux/bug.h:4,
>  from /home/davehans/linux.git/include/linux/page-flags.h:9,
>  from /home/davehans/linux.git/kernel/bounds.c:9:
> /home/davehans/linux.git/include/linux/kernel.h:5:20: fatal error: stdarg.h: 
> No such file or directory
>  #include 
> ^
> compilation terminated.

It's odd because I'm pretty sure I've done 4.15-rc compiles on this
system before without issues.  I suspect something in my config
(attached) is triggering this.

Does this look familiar to anyone?

gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.4.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 6.4.1 20170727 (Red Hat 6.4.1-1) (GCC)

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.14.0-rc3 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
CONFIG_IRQ_TIME_ACCOUNTING=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y

RE: [PATCH v4 07/12] [media] cxd2880: Add top level of the driver

[Takiguchi, Yasunari]

Hi, Mauro

> > +
> > +#define pr_fmt(fmt) KBUILD_MODNAME ": %s: " fmt, __func__
> 
> Same comments as on other patches: use SPDX and dev_foo() for printing
> messages.

About printing messages pr_fmt, I also replied a comment to [PATCH v4 02/12] 
[media] cxd2880-spi: Add support for CXD2880 SPI interface.
Please refer to the comment.

Thanks,
Takiguchi

RE: [PATCH v4 07/12] [media] cxd2880: Add top level of the driver

[Takiguchi, Yasunari]

Hi, Mauro

> > +
> > +#define pr_fmt(fmt) KBUILD_MODNAME ": %s: " fmt, __func__
> 
> Same comments as on other patches: use SPDX and dev_foo() for printing
> messages.

About printing messages pr_fmt, I also replied a comment to [PATCH v4 02/12] 
[media] cxd2880-spi: Add support for CXD2880 SPI interface.
Please refer to the comment.

Thanks,
Takiguchi

Re: [PATCH] kthread: finer-grained lockdep/cross-release completion

[Byungchul Park]

On 12/19/2017 6:59 PM, Daniel Vetter wrote:

On Mon, Dec 18, 2017 at 09:42:13AM -0800, Linus Torvalds wrote:

On Sun, Dec 17, 2017 at 11:11 PM, Daniel Vetter  wrote:


This didn't seem to have made it into -rc4. Anything needed to get it
going?


Do you actually see the problem in -rc4?

Because we ended up removing the cross-release checking due to other
developers complaining. It seemed to need a lot more work before it
was ready.

So I suspect the patch is simply not relevant any more (even if it's
not necessarily wrong either).


Awww ... I like the cross release stuff, it's catching lots of good bugs
for us - writing a gpu memory manager that's supposed to interface with
the core one ain't the simplest thing to get right. That's also why we're
going around and fixing up fallout (we've worked on the worker annotations
for 4.14 too). I guess next release, hopefully.

I think between 4.14 and 4.15 attemps cross-release spotted around 5 or so
genuine deadlocks in i915 code. And at least right now, with the current
set of fixups our CI runs are splat-free. So at least a Kconfig option
would be nice, to be able to enable it easily when you want to.

Wrt us not noticing: Getting the patches in through normal means takes too
long, so we constantly carry arounda  bunch of fixup patches to address
serious issues that block CI (no lockdep is no good CI). That's why we
won't immediately notice when an issue is resolved some other way.


Hello Ingo and Linus,

IMO, taking it off by default is enough. What fs folk actually
wanted is not to remove whole stuff but make it off by default.

Cross-release logic itself makes sense. Please consider it back
and apply my patch making it off by default.

I will do what I can do for the classification in layered fs.

--
Thanks,
Byungchul

Re: [PATCH] kthread: finer-grained lockdep/cross-release completion

[Byungchul Park]

On 12/19/2017 6:59 PM, Daniel Vetter wrote:

On Mon, Dec 18, 2017 at 09:42:13AM -0800, Linus Torvalds wrote:

On Sun, Dec 17, 2017 at 11:11 PM, Daniel Vetter  wrote:


This didn't seem to have made it into -rc4. Anything needed to get it
going?


Do you actually see the problem in -rc4?

Because we ended up removing the cross-release checking due to other
developers complaining. It seemed to need a lot more work before it
was ready.

So I suspect the patch is simply not relevant any more (even if it's
not necessarily wrong either).


Awww ... I like the cross release stuff, it's catching lots of good bugs
for us - writing a gpu memory manager that's supposed to interface with
the core one ain't the simplest thing to get right. That's also why we're
going around and fixing up fallout (we've worked on the worker annotations
for 4.14 too). I guess next release, hopefully.

I think between 4.14 and 4.15 attemps cross-release spotted around 5 or so
genuine deadlocks in i915 code. And at least right now, with the current
set of fixups our CI runs are splat-free. So at least a Kconfig option
would be nice, to be able to enable it easily when you want to.

Wrt us not noticing: Getting the patches in through normal means takes too
long, so we constantly carry arounda  bunch of fixup patches to address
serious issues that block CI (no lockdep is no good CI). That's why we
won't immediately notice when an issue is resolved some other way.


Hello Ingo and Linus,

IMO, taking it off by default is enough. What fs folk actually
wanted is not to remove whole stuff but make it off by default.

Cross-release logic itself makes sense. Please consider it back
and apply my patch making it off by default.

I will do what I can do for the classification in layered fs.

--
Thanks,
Byungchul

Re: [PATCH 14/15] dax: associate mappings with inodes, and warn if dma collides with truncate

[Dan Williams]

On Fri, Nov 10, 2017 at 1:08 AM, Christoph Hellwig  wrote:
>> + struct {
>> + /*
>> +  * ZONE_DEVICE pages are never on an lru or handled by
>> +  * a slab allocator, this points to the hosting device
>> +  * page map.
>> +  */
>> + struct dev_pagemap *pgmap;
>> + /*
>> +  * inode association for MEMORY_DEVICE_FS_DAX page-idle
>> +  * callbacks. Note that we don't use ->mapping since
>> +  * that has hard coded page-cache assumptions in
>> +  * several paths.
>> +  */
>
> What assumptions?  I'd much rather fix those up than having two fields
> that have the same functionality.

[ Reviving this old thread where you asked why I introduce page->inode
instead of reusing page->mapping ]

For example, xfs_vm_set_page_dirty() assumes that page->mapping being
non-NULL indicates a typical page cache page, this is a false
assumption for DAX. My guess at a fix for this is to add
pagecache_page() checks to locations like this, but I worry about how
to find them all. Where pagecache_page() is:

bool pagecache_page(struct page *page)
{
if (!page->mapping)
return false;
if (!IS_DAX(page->mapping->host))
return false;
return true;
}

Otherwise we go off the rails:

 WARNING: CPU: 27 PID: 1783 at fs/xfs/xfs_aops.c:1468
xfs_vm_set_page_dirty+0xf3/0x1b0 [xfs]
 [..]
 CPU: 27 PID: 1783 Comm: dma-collision Tainted: G   O
4.15.0-rc2+ #984
 [..]
 Call Trace:
  set_page_dirty_lock+0x40/0x60
  bio_set_pages_dirty+0x37/0x50
  iomap_dio_actor+0x2b7/0x3b0
  ? iomap_dio_zero+0x110/0x110
  iomap_apply+0xa4/0x110
  iomap_dio_rw+0x29e/0x3b0
  ? iomap_dio_zero+0x110/0x110
  ? xfs_file_dio_aio_read+0x7c/0x1a0 [xfs]
  xfs_file_dio_aio_read+0x7c/0x1a0 [xfs]
  xfs_file_read_iter+0xa0/0xc0 [xfs]
  __vfs_read+0xf9/0x170
  vfs_read+0xa6/0x150
  SyS_pread64+0x93/0xb0
  entry_SYSCALL_64_fastpath+0x1f/0x96

Re: [PATCH 14/15] dax: associate mappings with inodes, and warn if dma collides with truncate

[Dan Williams]

On Fri, Nov 10, 2017 at 1:08 AM, Christoph Hellwig  wrote:
>> + struct {
>> + /*
>> +  * ZONE_DEVICE pages are never on an lru or handled by
>> +  * a slab allocator, this points to the hosting device
>> +  * page map.
>> +  */
>> + struct dev_pagemap *pgmap;
>> + /*
>> +  * inode association for MEMORY_DEVICE_FS_DAX page-idle
>> +  * callbacks. Note that we don't use ->mapping since
>> +  * that has hard coded page-cache assumptions in
>> +  * several paths.
>> +  */
>
> What assumptions?  I'd much rather fix those up than having two fields
> that have the same functionality.

[ Reviving this old thread where you asked why I introduce page->inode
instead of reusing page->mapping ]

For example, xfs_vm_set_page_dirty() assumes that page->mapping being
non-NULL indicates a typical page cache page, this is a false
assumption for DAX. My guess at a fix for this is to add
pagecache_page() checks to locations like this, but I worry about how
to find them all. Where pagecache_page() is:

bool pagecache_page(struct page *page)
{
if (!page->mapping)
return false;
if (!IS_DAX(page->mapping->host))
return false;
return true;
}

Otherwise we go off the rails:

 WARNING: CPU: 27 PID: 1783 at fs/xfs/xfs_aops.c:1468
xfs_vm_set_page_dirty+0xf3/0x1b0 [xfs]
 [..]
 CPU: 27 PID: 1783 Comm: dma-collision Tainted: G   O
4.15.0-rc2+ #984
 [..]
 Call Trace:
  set_page_dirty_lock+0x40/0x60
  bio_set_pages_dirty+0x37/0x50
  iomap_dio_actor+0x2b7/0x3b0
  ? iomap_dio_zero+0x110/0x110
  iomap_apply+0xa4/0x110
  iomap_dio_rw+0x29e/0x3b0
  ? iomap_dio_zero+0x110/0x110
  ? xfs_file_dio_aio_read+0x7c/0x1a0 [xfs]
  xfs_file_dio_aio_read+0x7c/0x1a0 [xfs]
  xfs_file_read_iter+0xa0/0xc0 [xfs]
  __vfs_read+0xf9/0x170
  vfs_read+0xa6/0x150
  SyS_pread64+0x93/0xb0
  entry_SYSCALL_64_fastpath+0x1f/0x96

[PATCH 1/1] powerpc: Emulate paste instruction

[Sukadev Bhattiprolu]

From: Michael Neuling 

On POWER9 DD2.1 and below there are issues when the paste instruction
generates an error. If an error occurs when thread reconfiguration
happens (ie another thread in the core goes into/out of powersave) the
core may hang.

To avoid this a special sequence is required which stops thread
configuration so that the paste can be safely executed.

This patch assumes paste executed in userspace are trapped into the
illegal instruction exception at 0xe40.

Here we re-execute the paste instruction but with the required
sequence to ensure thread reconfiguration doesn't occur.

Signed-off-by: Michael Neuling 
Signed-off-by: Sukadev Bhattiprolu 
---
Changelog[v4]:
- We need to disable pagefaults after all when modifying the thread
  reconfig registers. Use a mutex, rather than a spinlock around
  the thread reconfig registers. Acquire the mutex first then block
  interrupts so we don't sleep on the mutex with interrupts disabled.

Changlog[v3]:
- [Michael Ellerman] We don't need to disable/enable pagefaults
  when emulating paste;
- [Michael Ellerman, Aneesh Kumar] Fix retval from emulate_paste()

Changelog[v2]:
[Sukadev]: Use PPC_PASTE() rather than the paste instruction since
in older versions the instruction required a third parameter.
---
 arch/powerpc/include/asm/emulated_ops.h |  1 +
 arch/powerpc/include/asm/ppc-opcode.h   |  1 +
 arch/powerpc/include/asm/reg.h  |  2 +
 arch/powerpc/kernel/traps.c | 73 +
 4 files changed, 77 insertions(+)

diff --git a/arch/powerpc/include/asm/emulated_ops.h 
b/arch/powerpc/include/asm/emulated_ops.h
index 651e135..fdc95cf 100644
--- a/arch/powerpc/include/asm/emulated_ops.h
+++ b/arch/powerpc/include/asm/emulated_ops.h
@@ -59,6 +59,7 @@ extern struct ppc_emulated {
struct ppc_emulated_entry lxvh8x;
struct ppc_emulated_entry lxvd2x;
struct ppc_emulated_entry lxvb16x;
+   struct ppc_emulated_entry paste;
 #endif
 } ppc_emulated;
 
diff --git a/arch/powerpc/include/asm/ppc-opcode.h 
b/arch/powerpc/include/asm/ppc-opcode.h
index ce0930d..a55d2ef 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -229,6 +229,7 @@
 #define PPC_INST_MTTMR 0x7c0003dc
 #define PPC_INST_NOP   0x6000
 #define PPC_INST_PASTE 0x7c20070d
+#define PPC_INST_PASTE_MASK0xfc2007ff
 #define PPC_INST_POPCNTB   0x7cf4
 #define PPC_INST_POPCNTB_MASK  0xfc0007fe
 #define PPC_INST_POPCNTD   0x7c0003f4
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index b779f3c..3495ecf 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -469,6 +469,8 @@
 #define SPRN_DBAT7U0x23E   /* Data BAT 7 Upper Register */
 #define SPRN_PPR   0x380   /* SMT Thread status Register */
 #define SPRN_TSCR  0x399   /* Thread Switch Control Register */
+#define SPRN_TRIG1 0x371   /* WAT Trigger 1 */
+#define SPRN_TRIG2 0x372   /* WAT Trigger 2 */
 
 #define SPRN_DEC   0x016   /* Decrement Register */
 #define SPRN_DER   0x095   /* Debug Enable Register */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index f3eb61b..e1ea3be 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1153,6 +1153,74 @@ static inline bool tm_abort_check(struct pt_regs *regs, 
int reason)
 }
 #endif
 
+static DEFINE_MUTEX(paste_emulation_mutex);
+
+static inline int paste(void *i)
+{
+   int cr;
+   long retval = 0;
+
+   /* Need per core lock to ensure trig1/2 writes don't race */
+   mutex_lock(_emulation_mutex);
+
+   hard_irq_disable();
+
+   mtspr(SPRN_TRIG1, 0); /* data doesn't matter */
+   mtspr(SPRN_TRIG1, 0); /* HW says do this twice */
+   asm volatile(
+   "1: " PPC_PASTE(0, %2) "\n"
+   "2: mfcr %1\n"
+   ".section .fixup,\"ax\"\n"
+   "3: li %0,%3\n"
+   "   li %2,0\n"
+   "   b 2b\n"
+   ".previous\n"
+   EX_TABLE(1b, 3b)
+   : "=r" (retval), "=r" (cr)
+   : "b" (i), "i" (-EFAULT), "0" (retval));
+   mtspr(SPRN_TRIG2, 0);
+
+   local_irq_enable();
+
+   mutex_unlock(_emulation_mutex);
+
+   return retval ? retval : cr;
+}
+
+static int emulate_paste(struct pt_regs *regs, u32 instword)
+{
+   const void __user *addr;
+   unsigned long ea;
+   u8 ra, rb;
+   int rc;
+
+   if (!cpu_has_feature(CPU_FTR_ARCH_300))
+   return -EINVAL;
+
+   ra = (instword >> 16) & 0x1f;
+   rb = (instword >> 11) & 0x1f;
+
+   ea = regs->gpr[rb] + (ra ? regs->gpr[ra] : 0ul);
+   if (is_32bit_task())
+   ea &= 

[PATCH 1/1] powerpc: Emulate paste instruction

[Sukadev Bhattiprolu]

From: Michael Neuling 

On POWER9 DD2.1 and below there are issues when the paste instruction
generates an error. If an error occurs when thread reconfiguration
happens (ie another thread in the core goes into/out of powersave) the
core may hang.

To avoid this a special sequence is required which stops thread
configuration so that the paste can be safely executed.

This patch assumes paste executed in userspace are trapped into the
illegal instruction exception at 0xe40.

Here we re-execute the paste instruction but with the required
sequence to ensure thread reconfiguration doesn't occur.

Signed-off-by: Michael Neuling 
Signed-off-by: Sukadev Bhattiprolu 
---
Changelog[v4]:
- We need to disable pagefaults after all when modifying the thread
  reconfig registers. Use a mutex, rather than a spinlock around
  the thread reconfig registers. Acquire the mutex first then block
  interrupts so we don't sleep on the mutex with interrupts disabled.

Changlog[v3]:
- [Michael Ellerman] We don't need to disable/enable pagefaults
  when emulating paste;
- [Michael Ellerman, Aneesh Kumar] Fix retval from emulate_paste()

Changelog[v2]:
[Sukadev]: Use PPC_PASTE() rather than the paste instruction since
in older versions the instruction required a third parameter.
---
 arch/powerpc/include/asm/emulated_ops.h |  1 +
 arch/powerpc/include/asm/ppc-opcode.h   |  1 +
 arch/powerpc/include/asm/reg.h  |  2 +
 arch/powerpc/kernel/traps.c | 73 +
 4 files changed, 77 insertions(+)

diff --git a/arch/powerpc/include/asm/emulated_ops.h 
b/arch/powerpc/include/asm/emulated_ops.h
index 651e135..fdc95cf 100644
--- a/arch/powerpc/include/asm/emulated_ops.h
+++ b/arch/powerpc/include/asm/emulated_ops.h
@@ -59,6 +59,7 @@ extern struct ppc_emulated {
struct ppc_emulated_entry lxvh8x;
struct ppc_emulated_entry lxvd2x;
struct ppc_emulated_entry lxvb16x;
+   struct ppc_emulated_entry paste;
 #endif
 } ppc_emulated;
 
diff --git a/arch/powerpc/include/asm/ppc-opcode.h 
b/arch/powerpc/include/asm/ppc-opcode.h
index ce0930d..a55d2ef 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -229,6 +229,7 @@
 #define PPC_INST_MTTMR 0x7c0003dc
 #define PPC_INST_NOP   0x6000
 #define PPC_INST_PASTE 0x7c20070d
+#define PPC_INST_PASTE_MASK0xfc2007ff
 #define PPC_INST_POPCNTB   0x7cf4
 #define PPC_INST_POPCNTB_MASK  0xfc0007fe
 #define PPC_INST_POPCNTD   0x7c0003f4
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index b779f3c..3495ecf 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -469,6 +469,8 @@
 #define SPRN_DBAT7U0x23E   /* Data BAT 7 Upper Register */
 #define SPRN_PPR   0x380   /* SMT Thread status Register */
 #define SPRN_TSCR  0x399   /* Thread Switch Control Register */
+#define SPRN_TRIG1 0x371   /* WAT Trigger 1 */
+#define SPRN_TRIG2 0x372   /* WAT Trigger 2 */
 
 #define SPRN_DEC   0x016   /* Decrement Register */
 #define SPRN_DER   0x095   /* Debug Enable Register */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index f3eb61b..e1ea3be 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1153,6 +1153,74 @@ static inline bool tm_abort_check(struct pt_regs *regs, 
int reason)
 }
 #endif
 
+static DEFINE_MUTEX(paste_emulation_mutex);
+
+static inline int paste(void *i)
+{
+   int cr;
+   long retval = 0;
+
+   /* Need per core lock to ensure trig1/2 writes don't race */
+   mutex_lock(_emulation_mutex);
+
+   hard_irq_disable();
+
+   mtspr(SPRN_TRIG1, 0); /* data doesn't matter */
+   mtspr(SPRN_TRIG1, 0); /* HW says do this twice */
+   asm volatile(
+   "1: " PPC_PASTE(0, %2) "\n"
+   "2: mfcr %1\n"
+   ".section .fixup,\"ax\"\n"
+   "3: li %0,%3\n"
+   "   li %2,0\n"
+   "   b 2b\n"
+   ".previous\n"
+   EX_TABLE(1b, 3b)
+   : "=r" (retval), "=r" (cr)
+   : "b" (i), "i" (-EFAULT), "0" (retval));
+   mtspr(SPRN_TRIG2, 0);
+
+   local_irq_enable();
+
+   mutex_unlock(_emulation_mutex);
+
+   return retval ? retval : cr;
+}
+
+static int emulate_paste(struct pt_regs *regs, u32 instword)
+{
+   const void __user *addr;
+   unsigned long ea;
+   u8 ra, rb;
+   int rc;
+
+   if (!cpu_has_feature(CPU_FTR_ARCH_300))
+   return -EINVAL;
+
+   ra = (instword >> 16) & 0x1f;
+   rb = (instword >> 11) & 0x1f;
+
+   ea = regs->gpr[rb] + (ra ? regs->gpr[ra] : 0ul);
+   if (is_32bit_task())
+   ea &= 0xul;
+   addr = (__force const void __user *)ea;
+
+  

[PATCH 1/1] vas: vas_window_init_dbgdir: fix order of cleanup.

[Sukadev Bhattiprolu]

Fix the order of cleanup to ensure we free the name buffer in case
of an error creating 'hvwc' or 'info' files.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-debug.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/vas-debug.c 
b/arch/powerpc/platforms/powernv/vas-debug.c
index ca22f1e..b4de4c6 100644
--- a/arch/powerpc/platforms/powernv/vas-debug.c
+++ b/arch/powerpc/platforms/powernv/vas-debug.c
@@ -166,13 +166,13 @@ void vas_window_init_dbgdir(struct vas_window *window)
 
return;
 
-free_name:
-   kfree(window->dbgname);
-   window->dbgname = NULL;
-
 remove_dir:
debugfs_remove_recursive(window->dbgdir);
window->dbgdir = NULL;
+
+free_name:
+   kfree(window->dbgname);
+   window->dbgname = NULL;
 }
 
 void vas_instance_init_dbgdir(struct vas_instance *vinst)
-- 
2.7.4

[PATCH 1/1] vas: vas_window_init_dbgdir: fix order of cleanup.

[Sukadev Bhattiprolu]

Fix the order of cleanup to ensure we free the name buffer in case
of an error creating 'hvwc' or 'info' files.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-debug.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/vas-debug.c 
b/arch/powerpc/platforms/powernv/vas-debug.c
index ca22f1e..b4de4c6 100644
--- a/arch/powerpc/platforms/powernv/vas-debug.c
+++ b/arch/powerpc/platforms/powernv/vas-debug.c
@@ -166,13 +166,13 @@ void vas_window_init_dbgdir(struct vas_window *window)
 
return;
 
-free_name:
-   kfree(window->dbgname);
-   window->dbgname = NULL;
-
 remove_dir:
debugfs_remove_recursive(window->dbgdir);
window->dbgdir = NULL;
+
+free_name:
+   kfree(window->dbgname);
+   window->dbgname = NULL;
 }
 
 void vas_instance_init_dbgdir(struct vas_instance *vinst)
-- 
2.7.4

RE: [PATCH v4 06/12] [media] cxd2880: Add integration layer for the driver

[Takiguchi, Yasunari]

Hi, Mauro.

> >
> > These functions monitor the driver and watch for task completion.
> > This is part of the Sony CXD2880 DVB-T2/T tuner + demodulator driver.
> 
> If I understand well, the goal here is to have thread that would be waking
> up from time to time, right? Just use the infrastructure that the Kernel
> has for it, like a kthread, or timer_setup() & friends.
> 
> Take a look at include/linux/timer.h, and just use what's already defined.

This code is initialize process.
Therefore, it is executed only once and it will not execute other processing at 
the same time.
We think that the current implementation is enough.
What do you think?
furthermore, we will modify this code by using ktime_foo().

Thanks,
Takiguchi

RE: [PATCH v4 06/12] [media] cxd2880: Add integration layer for the driver

[Takiguchi, Yasunari]

Hi, Mauro.

> >
> > These functions monitor the driver and watch for task completion.
> > This is part of the Sony CXD2880 DVB-T2/T tuner + demodulator driver.
> 
> If I understand well, the goal here is to have thread that would be waking
> up from time to time, right? Just use the infrastructure that the Kernel
> has for it, like a kthread, or timer_setup() & friends.
> 
> Take a look at include/linux/timer.h, and just use what's already defined.

This code is initialize process.
Therefore, it is executed only once and it will not execute other processing at 
the same time.
We think that the current implementation is enough.
What do you think?
furthermore, we will modify this code by using ktime_foo().

Thanks,
Takiguchi

Re: [PATCH -tip v3 3/6] net: sctp: Add SCTP ACK tracking trace event

[Masami Hiramatsu]

On Tue, 19 Dec 2017 10:20:24 -0500
Steven Rostedt  wrote:

> On Tue, 19 Dec 2017 17:58:25 +0900
> Masami Hiramatsu  wrote:
> 
> > +TRACE_EVENT(sctp_probe,
> > +
> > +   TP_PROTO(const struct sctp_endpoint *ep,
> > +const struct sctp_association *asoc,
> > +struct sctp_chunk *chunk),
> > +
> > +   TP_ARGS(ep, asoc, chunk),
> > +
> > +   TP_STRUCT__entry(
> > +   __field(__u64, asoc)
> > +   __field(__u32, mark)
> > +   __field(__u16, bind_port)
> > +   __field(__u16, peer_port)
> > +   __field(__u32, pathmtu)
> > +   __field(__u32, rwnd)
> > +   __field(__u16, unack_data)
> > +   ),
> > +
> > +   TP_fast_assign(
> > +   struct sctp_transport *sp;
> > +   struct sk_buff *skb = chunk->skb;
> > +
> > +   __entry->asoc = (__u64)asoc;
> > +   __entry->mark = skb->mark;
> > +   __entry->bind_port = ep->base.bind_addr.port;
> > +   __entry->peer_port = asoc->peer.port;
> > +   __entry->pathmtu = asoc->pathmtu;
> > +   __entry->rwnd = asoc->peer.rwnd;
> > +   __entry->unack_data = asoc->unack_data;
> > +
> > +   if (trace_sctp_probe_path_enabled()) {
> > +   list_for_each_entry(sp, >peer.transport_addr_list,
> > +   transports) {
> > +   trace_sctp_probe_path(sp, asoc);
> > +   }
> > +   }
> 
> I thought you were going to move this into the code, like I suggested?

Ah, I missed to define sp in the block...

Thanks,

> 
> -- Steve
> 
> > +   ),
> > +
> > +   TP_printk("asoc=%#llx mark=%#x bind_port=%d peer_port=%d pathmtu=%d "
> > + "rwnd=%u unack_data=%d",
> > + __entry->asoc, __entry->mark, __entry->bind_port,
> > + __entry->peer_port, __entry->pathmtu, __entry->rwnd,
> > + __entry->unack_data)
> > +);
> > +


-- 
Masami Hiramatsu 

Re: [PATCH -tip v3 3/6] net: sctp: Add SCTP ACK tracking trace event

[Masami Hiramatsu]

On Tue, 19 Dec 2017 10:20:24 -0500
Steven Rostedt  wrote:

> On Tue, 19 Dec 2017 17:58:25 +0900
> Masami Hiramatsu  wrote:
> 
> > +TRACE_EVENT(sctp_probe,
> > +
> > +   TP_PROTO(const struct sctp_endpoint *ep,
> > +const struct sctp_association *asoc,
> > +struct sctp_chunk *chunk),
> > +
> > +   TP_ARGS(ep, asoc, chunk),
> > +
> > +   TP_STRUCT__entry(
> > +   __field(__u64, asoc)
> > +   __field(__u32, mark)
> > +   __field(__u16, bind_port)
> > +   __field(__u16, peer_port)
> > +   __field(__u32, pathmtu)
> > +   __field(__u32, rwnd)
> > +   __field(__u16, unack_data)
> > +   ),
> > +
> > +   TP_fast_assign(
> > +   struct sctp_transport *sp;
> > +   struct sk_buff *skb = chunk->skb;
> > +
> > +   __entry->asoc = (__u64)asoc;
> > +   __entry->mark = skb->mark;
> > +   __entry->bind_port = ep->base.bind_addr.port;
> > +   __entry->peer_port = asoc->peer.port;
> > +   __entry->pathmtu = asoc->pathmtu;
> > +   __entry->rwnd = asoc->peer.rwnd;
> > +   __entry->unack_data = asoc->unack_data;
> > +
> > +   if (trace_sctp_probe_path_enabled()) {
> > +   list_for_each_entry(sp, >peer.transport_addr_list,
> > +   transports) {
> > +   trace_sctp_probe_path(sp, asoc);
> > +   }
> > +   }
> 
> I thought you were going to move this into the code, like I suggested?

Ah, I missed to define sp in the block...

Thanks,

> 
> -- Steve
> 
> > +   ),
> > +
> > +   TP_printk("asoc=%#llx mark=%#x bind_port=%d peer_port=%d pathmtu=%d "
> > + "rwnd=%u unack_data=%d",
> > + __entry->asoc, __entry->mark, __entry->bind_port,
> > + __entry->peer_port, __entry->pathmtu, __entry->rwnd,
> > + __entry->unack_data)
> > +);
> > +


-- 
Masami Hiramatsu 

RE: [PATCH v4 05/12] [media] cxd2880: Add tuner part of the driver

[Takiguchi, Yasunari]

Hi, Mauro


> > +   ret = tnr_dmd->io->read_regs(tnr_dmd->io,
> > +CXD2880_IO_TGT_SYS,
> > +0x10, data, 1);
> > +   if (ret)
> > +   return ret;
> > +   if ((data[0] & 0x01) == 0x00)
> > +   return -EBUSY;
> 
> I don't know anything about this hardware, but it sounds weird to return
> -EBUSY here, except if the hardware reached a permanent busy condition,
> and would require some sort of reset to work again.
> 
> As this is in the middle of lots of things, I *suspect* that this is
> not the case.
> 
> If I'm right, and this is just a transitory solution that could happen
> for a limited amount of time, e. g. if what's there at data[0] is a flag
> saying that the device didn't finish the last operation yet, maybe the
> best would be to do something like:
> 
>   for (i = 0; i < 10; i++) {
>   ret = tnr_dmd->io->read_regs(tnr_dmd->io,
>CXD2880_IO_TGT_SYS,
>0x10, data, 1);
>   if (ret)
>   return ret;
>   if (data[0] & 0x01)
>   break;
>   msleep(10);
>   }
>   if (!(data[0] & 0x01))
>   return -EBUSY;
> 
> > +
> > +   ret = cxd2880_io_write_multi_regs(tnr_dmd->io,
> > + CXD2880_IO_TGT_SYS,
> > + rf_init1_seq5,
> > + ARRAY_SIZE(rf_init1_seq5));
> > +   if (ret)
> > +   return ret;
> > +
> > +   usleep_range(1000, 2000);
> > +
> > +   ret = tnr_dmd->io->write_reg(tnr_dmd->io,
> > +CXD2880_IO_TGT_SYS,
> > +0x00, 0x0a);
> > +   if (ret)
> > +   return ret;
> > +   ret = tnr_dmd->io->read_regs(tnr_dmd->io,
> > +CXD2880_IO_TGT_SYS,
> > +0x11, data, 1);
> > +   if (ret)
> > +   return ret;
> > +   if ((data[0] & 0x01) == 0x00)
> > +   return -EBUSY;
> 
> Same here and on similar places.

As the hardware specification, It is abnormal if certain register doesn't 
become 1 even if sleep time passes.
Perhaps it should not be return EBUSY.
We will reconsider error code.

Thanks,
Takiguchi

RE: [PATCH v4 05/12] [media] cxd2880: Add tuner part of the driver

[Takiguchi, Yasunari]

Hi, Mauro


> > +   ret = tnr_dmd->io->read_regs(tnr_dmd->io,
> > +CXD2880_IO_TGT_SYS,
> > +0x10, data, 1);
> > +   if (ret)
> > +   return ret;
> > +   if ((data[0] & 0x01) == 0x00)
> > +   return -EBUSY;
> 
> I don't know anything about this hardware, but it sounds weird to return
> -EBUSY here, except if the hardware reached a permanent busy condition,
> and would require some sort of reset to work again.
> 
> As this is in the middle of lots of things, I *suspect* that this is
> not the case.
> 
> If I'm right, and this is just a transitory solution that could happen
> for a limited amount of time, e. g. if what's there at data[0] is a flag
> saying that the device didn't finish the last operation yet, maybe the
> best would be to do something like:
> 
>   for (i = 0; i < 10; i++) {
>   ret = tnr_dmd->io->read_regs(tnr_dmd->io,
>CXD2880_IO_TGT_SYS,
>0x10, data, 1);
>   if (ret)
>   return ret;
>   if (data[0] & 0x01)
>   break;
>   msleep(10);
>   }
>   if (!(data[0] & 0x01))
>   return -EBUSY;
> 
> > +
> > +   ret = cxd2880_io_write_multi_regs(tnr_dmd->io,
> > + CXD2880_IO_TGT_SYS,
> > + rf_init1_seq5,
> > + ARRAY_SIZE(rf_init1_seq5));
> > +   if (ret)
> > +   return ret;
> > +
> > +   usleep_range(1000, 2000);
> > +
> > +   ret = tnr_dmd->io->write_reg(tnr_dmd->io,
> > +CXD2880_IO_TGT_SYS,
> > +0x00, 0x0a);
> > +   if (ret)
> > +   return ret;
> > +   ret = tnr_dmd->io->read_regs(tnr_dmd->io,
> > +CXD2880_IO_TGT_SYS,
> > +0x11, data, 1);
> > +   if (ret)
> > +   return ret;
> > +   if ((data[0] & 0x01) == 0x00)
> > +   return -EBUSY;
> 
> Same here and on similar places.

As the hardware specification, It is abnormal if certain register doesn't 
become 1 even if sleep time passes.
Perhaps it should not be return EBUSY.
We will reconsider error code.

Thanks,
Takiguchi

Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures

[Christopher Lameter]

On Tue, 19 Dec 2017, Rao Shoaib wrote:

> > > mm/slab_common.c
> > It would be great to have separate patches so that we can review it
> > properly:
> >
> > 1. Move the code into slab_common.c
> > 2. The actual code changes to the kfree rcu mechanism
> > 3. The whitespace changes

> I can certainly break down the patch and submit smaller patches as you have
> suggested.
>
> BTW -- This is my first ever patch to Linux, so I am still learning the
> etiquette.

You are doing great. Keep at improving the patches and we will get your
changes into the kernel source. If you want to sent your first patchset
then a tool like "quilt" or "git" might be helpful.

Re: [PATCH/RFC] llist: add llist_[add|del_first]_exclusive

[Huang, Ying]

Vitaly Wool  writes:

> 2017-12-19 2:35 GMT+01:00 Huang, Ying :
>
>> Vitaly Wool  writes:
>>
>> > It sometimes is necessary to be able to be able to use llist in
>> > the following manner:
>> >   if (node_unlisted(node))
>> >   llst_add(node, list);
>> > i. e. only add a node to the list if it's not already on a list.
>> >
>> > This is not possible without taking locks because otherwise there's
>> > an obvious race between the check and the addition. This patch adds
>> > the routine to add a node only if it is not on any list that is
>> > lockless and race free as long as there's only one consumer.
>> >
>> > That is, llist_add_exclusive would only add a node if it's not
>> > already on a list, and llist_del_first_exclusive will delete the
>> > first node off the list and mark it as not being on any list.
>> >
>> > Signed-off-by: Vitaly Wool 
>> > ---
>> >  include/linux/llist.h | 25 +
>> >  lib/llist.c   | 29 +
>> >  2 files changed, 54 insertions(+)
>> >
>> > diff --git a/include/linux/llist.h b/include/linux/llist.h
>> > index 85abc29..5c60e9e 100644
>> > --- a/include/linux/llist.h
>> > +++ b/include/linux/llist.h
>> > @@ -74,6 +74,10 @@ struct llist_node {
>> >  #define LLIST_HEAD_INIT(name){ NULL }
>> >  #define LLIST_HEAD(name) struct llist_head name =
>> LLIST_HEAD_INIT(name)
>> >
>> > +#define LLIST_NODE_UNLISTED  ((void *)(-1L))
>> > +#define LLIST_NODE_INIT(name){ LLIST_NODE_UNLISTED }
>> > +#define LLIST_NODE(name) struct llist_node name =
>> LLIST_NODE_INIT(name)
>> > +
>> >  /**
>> >   * init_llist_head - initialize lock-less list head
>> >   * @head:the head for your lock-less list
>> > @@ -238,4 +242,25 @@ extern struct llist_node *llist_del_first(struct
>> llist_head *head);
>> >
>> >  struct llist_node *llist_reverse_order(struct llist_node *head);
>> >
>> > +/**
>> > + * llist_del_first_exclusive - delete the first entry of lock-less list
>> > + *  and make sure its ->next is NULL
>> > + * @head:the head for your lock-less list
>> > + *
>> > + * If list is empty, return NULL, otherwise, return the first entry
>> > + * deleted, this is the newest added one.
>> > + *
>> > + */
>> > +static inline struct llist_node *llist_del_first_exclusive(
>> > + struct llist_head *head)
>> > +{
>> > + struct llist_node *node = llist_del_first(head);
>> > +
>> > + if (READ_ONCE(node))
>> > + smp_store_release(>next, LLIST_NODE_UNLISTED);
>> > + return node;
>> > +}
>> > +
>> > +extern bool llist_add_exclusive(struct llist_node *, struct llist_head
>> *);
>> > +
>> >  #endif /* LLIST_H */
>> > diff --git a/lib/llist.c b/lib/llist.c
>> > index 7062e93..c85fa6b 100644
>> > --- a/lib/llist.c
>> > +++ b/lib/llist.c
>> > @@ -102,3 +102,32 @@ struct llist_node *llist_reverse_order(struct
>> llist_node *head)
>> >   return new_head;
>> >  }
>> >  EXPORT_SYMBOL_GPL(llist_reverse_order);
>> > +
>> > +/**
>> > + * llist_add_exclusive - add a node only if its ->next is NULL
>> > + * @node:the node to be added
>> > + * @head:the head for your lock-less list
>> > + *
>> > + * Return true if the node was added, or false otherwise.
>> > + */
>> > +bool llist_add_exclusive(struct llist_node *node, struct llist_head
>> *head)
>> > +{
>> > + struct llist_node *next = LLIST_NODE_UNLISTED;
>> > + struct llist_node *entry, *new_next;
>> > +
>> > + /*
>> > +  * if new_next is next (== LLIST_NODE_UNLISTED) on the first run,
>> we
>> > +  * get exclusive access to this node as long as others use
>> > +  * llist_add_safe too.
>> > +  * Then false can be returned no more and we'll loop until we get
>> the
>> > +  * stuff right.
>> > +  */
>> > + do {
>> > + entry = READ_ONCE(head->first);
>> > + if ((new_next = cmpxchg(>next, next, entry)) != next)
>> > + return false;
>> > + next = entry;
>> > + } while (cmpxchg(>first, entry, node) != entry);
>> > + return true;
>> > +}
>> > +EXPORT_SYMBOL_GPL(llist_add_exclusive);
>>
>> I think this could be implemented on top of llist, why add it into llist
>> itself?
>>
>
>
> Could you please elaborate how this would be implemented "on top"?

struct llist_node *my_del_first_exclusive(struct llist_head *head)
{
struct llist_node *node = llist_del_first(head);

if (node)
node->next = LLIST_NODE_UNLISTED;
}

bool my_add_exclusive(struct llist_node *node, struct llist_head *head)
{
if (node->next != LLIST_NODE_UNLIST)
return false;
if (cmpxchg(>next, LLIST_NODE_UNLIST, NULL) !=
LLIST_NODE_UNLIST)
return false;
llist_add(node, head);
return true;
}

Best Regards,
Huang, Ying

Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures

[Christopher Lameter]

On Tue, 19 Dec 2017, Rao Shoaib wrote:

> > > mm/slab_common.c
> > It would be great to have separate patches so that we can review it
> > properly:
> >
> > 1. Move the code into slab_common.c
> > 2. The actual code changes to the kfree rcu mechanism
> > 3. The whitespace changes

> I can certainly break down the patch and submit smaller patches as you have
> suggested.
>
> BTW -- This is my first ever patch to Linux, so I am still learning the
> etiquette.

You are doing great. Keep at improving the patches and we will get your
changes into the kernel source. If you want to sent your first patchset
then a tool like "quilt" or "git" might be helpful.

Re: [PATCH/RFC] llist: add llist_[add|del_first]_exclusive

[Huang, Ying]

Vitaly Wool  writes:

> 2017-12-19 2:35 GMT+01:00 Huang, Ying :
>
>> Vitaly Wool  writes:
>>
>> > It sometimes is necessary to be able to be able to use llist in
>> > the following manner:
>> >   if (node_unlisted(node))
>> >   llst_add(node, list);
>> > i. e. only add a node to the list if it's not already on a list.
>> >
>> > This is not possible without taking locks because otherwise there's
>> > an obvious race between the check and the addition. This patch adds
>> > the routine to add a node only if it is not on any list that is
>> > lockless and race free as long as there's only one consumer.
>> >
>> > That is, llist_add_exclusive would only add a node if it's not
>> > already on a list, and llist_del_first_exclusive will delete the
>> > first node off the list and mark it as not being on any list.
>> >
>> > Signed-off-by: Vitaly Wool 
>> > ---
>> >  include/linux/llist.h | 25 +
>> >  lib/llist.c   | 29 +
>> >  2 files changed, 54 insertions(+)
>> >
>> > diff --git a/include/linux/llist.h b/include/linux/llist.h
>> > index 85abc29..5c60e9e 100644
>> > --- a/include/linux/llist.h
>> > +++ b/include/linux/llist.h
>> > @@ -74,6 +74,10 @@ struct llist_node {
>> >  #define LLIST_HEAD_INIT(name){ NULL }
>> >  #define LLIST_HEAD(name) struct llist_head name =
>> LLIST_HEAD_INIT(name)
>> >
>> > +#define LLIST_NODE_UNLISTED  ((void *)(-1L))
>> > +#define LLIST_NODE_INIT(name){ LLIST_NODE_UNLISTED }
>> > +#define LLIST_NODE(name) struct llist_node name =
>> LLIST_NODE_INIT(name)
>> > +
>> >  /**
>> >   * init_llist_head - initialize lock-less list head
>> >   * @head:the head for your lock-less list
>> > @@ -238,4 +242,25 @@ extern struct llist_node *llist_del_first(struct
>> llist_head *head);
>> >
>> >  struct llist_node *llist_reverse_order(struct llist_node *head);
>> >
>> > +/**
>> > + * llist_del_first_exclusive - delete the first entry of lock-less list
>> > + *  and make sure its ->next is NULL
>> > + * @head:the head for your lock-less list
>> > + *
>> > + * If list is empty, return NULL, otherwise, return the first entry
>> > + * deleted, this is the newest added one.
>> > + *
>> > + */
>> > +static inline struct llist_node *llist_del_first_exclusive(
>> > + struct llist_head *head)
>> > +{
>> > + struct llist_node *node = llist_del_first(head);
>> > +
>> > + if (READ_ONCE(node))
>> > + smp_store_release(>next, LLIST_NODE_UNLISTED);
>> > + return node;
>> > +}
>> > +
>> > +extern bool llist_add_exclusive(struct llist_node *, struct llist_head
>> *);
>> > +
>> >  #endif /* LLIST_H */
>> > diff --git a/lib/llist.c b/lib/llist.c
>> > index 7062e93..c85fa6b 100644
>> > --- a/lib/llist.c
>> > +++ b/lib/llist.c
>> > @@ -102,3 +102,32 @@ struct llist_node *llist_reverse_order(struct
>> llist_node *head)
>> >   return new_head;
>> >  }
>> >  EXPORT_SYMBOL_GPL(llist_reverse_order);
>> > +
>> > +/**
>> > + * llist_add_exclusive - add a node only if its ->next is NULL
>> > + * @node:the node to be added
>> > + * @head:the head for your lock-less list
>> > + *
>> > + * Return true if the node was added, or false otherwise.
>> > + */
>> > +bool llist_add_exclusive(struct llist_node *node, struct llist_head
>> *head)
>> > +{
>> > + struct llist_node *next = LLIST_NODE_UNLISTED;
>> > + struct llist_node *entry, *new_next;
>> > +
>> > + /*
>> > +  * if new_next is next (== LLIST_NODE_UNLISTED) on the first run,
>> we
>> > +  * get exclusive access to this node as long as others use
>> > +  * llist_add_safe too.
>> > +  * Then false can be returned no more and we'll loop until we get
>> the
>> > +  * stuff right.
>> > +  */
>> > + do {
>> > + entry = READ_ONCE(head->first);
>> > + if ((new_next = cmpxchg(>next, next, entry)) != next)
>> > + return false;
>> > + next = entry;
>> > + } while (cmpxchg(>first, entry, node) != entry);
>> > + return true;
>> > +}
>> > +EXPORT_SYMBOL_GPL(llist_add_exclusive);
>>
>> I think this could be implemented on top of llist, why add it into llist
>> itself?
>>
>
>
> Could you please elaborate how this would be implemented "on top"?

struct llist_node *my_del_first_exclusive(struct llist_head *head)
{
struct llist_node *node = llist_del_first(head);

if (node)
node->next = LLIST_NODE_UNLISTED;
}

bool my_add_exclusive(struct llist_node *node, struct llist_head *head)
{
if (node->next != LLIST_NODE_UNLIST)
return false;
if (cmpxchg(>next, LLIST_NODE_UNLIST, NULL) !=
LLIST_NODE_UNLIST)
return false;
llist_add(node, head);
return true;
}

Best Regards,
Huang, Ying

RE: [PATCH v4 02/12] [media] cxd2880-spi: Add support for CXD2880 SPI interface

[Takiguchi, Yasunari]

Hi, Mauro.

> > +
> > +#define pr_fmt(fmt) KBUILD_MODNAME ": %s: " fmt, __func__
> 
> It would be better to use dev_foo() debug macros instead of
> pr_foo() ones.

I got comment for this previous version patch as below
--
The best would be to se dev_err() & friends for printing messages, 
as they print the device's name as filled at struct device.
If you don't use, please add a define that will print the name at the logs, 
like:

  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

either at the begining of the driver or at some header file.

Btw, I'm noticing that you're also using dev_err() on other places of the code. 
Please standardize. OK, on a few places, you may still need to use pr_err(), 
if you need to print a message before initializing struct device, but I suspect 
that you can init
--

You pointed out here before. Because dev_foo () and pr_foo () were mixed.
We standardize with pr_foo() because the logs is outputted before getting the 
device structure.
Is it better to use dev_foo() where we can use it?


> > +static int cxd2880_stop_feed(struct dvb_demux_feed *feed) {
> > +   int i = 0;
> > +   int ret;
> > +   struct dvb_demux *demux = NULL;
> > +   struct cxd2880_dvb_spi *dvb_spi = NULL;
> > +
> > +   if (!feed) {
> > +   pr_err("invalid arg\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   demux = feed->demux;
> > +   if (!demux) {
> > +   pr_err("feed->demux is NULL\n");
> > +   return -EINVAL;
> > +   }
> > +   dvb_spi = demux->priv;
> > +
> > +   if (!dvb_spi->feed_count) {
> > +   pr_err("no feed is started\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   if (feed->pid == 0x2000) {
> > +   /*
> > +* Special PID case.
> > +* Number of 0x2000 feed request was stored
> > +* in dvb_spi->all_pid_feed_count.
> > +*/
> > +   if (dvb_spi->all_pid_feed_count <= 0) {
> > +   pr_err("PID %d not found.\n", feed->pid);
> > +   return -EINVAL;
> > +   }
> > +   dvb_spi->all_pid_feed_count--;
> > +   } else {
> > +   struct cxd2880_pid_filter_config cfgtmp;
> > +
> > +   cfgtmp = dvb_spi->filter_config;
> > +
> > +   for (i = 0; i < CXD2880_MAX_FILTER_SIZE; i++) {
> > +   if (feed->pid == cfgtmp.pid_config[i].pid &&
> > +   cfgtmp.pid_config[i].is_enable != 0) {
> > +   cfgtmp.pid_config[i].is_enable = 0;
> > +   cfgtmp.pid_config[i].pid = 0;
> > +   pr_debug("removed PID %d from #%d\n",
> > +feed->pid, i);
> > +   break;
> > +   }
> > +   }
> > +   dvb_spi->filter_config = cfgtmp;
> > +
> > +   if (i == CXD2880_MAX_FILTER_SIZE) {
> > +   pr_err("PID %d not found\n", feed->pid);
> > +   return -EINVAL;
> > +   }
> > +   }
> > +
> > +   ret = cxd2880_update_pid_filter(dvb_spi,
> > +   _spi->filter_config,
> > +   dvb_spi->all_pid_feed_count >
> 0);
> > +   dvb_spi->feed_count--;
> > +
> > +   if (dvb_spi->feed_count == 0) {
> > +   int ret_stop = 0;
> > +
> > +   ret_stop =
> kthread_stop(dvb_spi->cxd2880_ts_read_thread);
> > +   if (ret_stop) {
> > +   pr_err("'kthread_stop failed. (%d)\n",
> ret_stop);
> > +   ret = ret_stop;
> > +   }
> > +   kfree(dvb_spi->ts_buf);
> > +   dvb_spi->ts_buf = NULL;
> > +   }
> > +
> > +   pr_debug("stop feed ok.(count %d)\n", dvb_spi->feed_count);
> > +
> > +   return ret;
> > +}
> 
> I have the feeling that I've seen the code above before at the dvb core.
> Any reason why don't use the already-existing code at dvb_demux.c &
> friends?

The CXD2880 HW PID filter is used to decrease the amount of TS data transferred 
via limited bit rate SPI interface.

Thanks,
Takiguchi

RE: [PATCH v4 02/12] [media] cxd2880-spi: Add support for CXD2880 SPI interface

[Takiguchi, Yasunari]

Hi, Mauro.

> > +
> > +#define pr_fmt(fmt) KBUILD_MODNAME ": %s: " fmt, __func__
> 
> It would be better to use dev_foo() debug macros instead of
> pr_foo() ones.

I got comment for this previous version patch as below
--
The best would be to se dev_err() & friends for printing messages, 
as they print the device's name as filled at struct device.
If you don't use, please add a define that will print the name at the logs, 
like:

  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

either at the begining of the driver or at some header file.

Btw, I'm noticing that you're also using dev_err() on other places of the code. 
Please standardize. OK, on a few places, you may still need to use pr_err(), 
if you need to print a message before initializing struct device, but I suspect 
that you can init
--

You pointed out here before. Because dev_foo () and pr_foo () were mixed.
We standardize with pr_foo() because the logs is outputted before getting the 
device structure.
Is it better to use dev_foo() where we can use it?


> > +static int cxd2880_stop_feed(struct dvb_demux_feed *feed) {
> > +   int i = 0;
> > +   int ret;
> > +   struct dvb_demux *demux = NULL;
> > +   struct cxd2880_dvb_spi *dvb_spi = NULL;
> > +
> > +   if (!feed) {
> > +   pr_err("invalid arg\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   demux = feed->demux;
> > +   if (!demux) {
> > +   pr_err("feed->demux is NULL\n");
> > +   return -EINVAL;
> > +   }
> > +   dvb_spi = demux->priv;
> > +
> > +   if (!dvb_spi->feed_count) {
> > +   pr_err("no feed is started\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   if (feed->pid == 0x2000) {
> > +   /*
> > +* Special PID case.
> > +* Number of 0x2000 feed request was stored
> > +* in dvb_spi->all_pid_feed_count.
> > +*/
> > +   if (dvb_spi->all_pid_feed_count <= 0) {
> > +   pr_err("PID %d not found.\n", feed->pid);
> > +   return -EINVAL;
> > +   }
> > +   dvb_spi->all_pid_feed_count--;
> > +   } else {
> > +   struct cxd2880_pid_filter_config cfgtmp;
> > +
> > +   cfgtmp = dvb_spi->filter_config;
> > +
> > +   for (i = 0; i < CXD2880_MAX_FILTER_SIZE; i++) {
> > +   if (feed->pid == cfgtmp.pid_config[i].pid &&
> > +   cfgtmp.pid_config[i].is_enable != 0) {
> > +   cfgtmp.pid_config[i].is_enable = 0;
> > +   cfgtmp.pid_config[i].pid = 0;
> > +   pr_debug("removed PID %d from #%d\n",
> > +feed->pid, i);
> > +   break;
> > +   }
> > +   }
> > +   dvb_spi->filter_config = cfgtmp;
> > +
> > +   if (i == CXD2880_MAX_FILTER_SIZE) {
> > +   pr_err("PID %d not found\n", feed->pid);
> > +   return -EINVAL;
> > +   }
> > +   }
> > +
> > +   ret = cxd2880_update_pid_filter(dvb_spi,
> > +   _spi->filter_config,
> > +   dvb_spi->all_pid_feed_count >
> 0);
> > +   dvb_spi->feed_count--;
> > +
> > +   if (dvb_spi->feed_count == 0) {
> > +   int ret_stop = 0;
> > +
> > +   ret_stop =
> kthread_stop(dvb_spi->cxd2880_ts_read_thread);
> > +   if (ret_stop) {
> > +   pr_err("'kthread_stop failed. (%d)\n",
> ret_stop);
> > +   ret = ret_stop;
> > +   }
> > +   kfree(dvb_spi->ts_buf);
> > +   dvb_spi->ts_buf = NULL;
> > +   }
> > +
> > +   pr_debug("stop feed ok.(count %d)\n", dvb_spi->feed_count);
> > +
> > +   return ret;
> > +}
> 
> I have the feeling that I've seen the code above before at the dvb core.
> Any reason why don't use the already-existing code at dvb_demux.c &
> friends?

The CXD2880 HW PID filter is used to decrease the amount of TS data transferred 
via limited bit rate SPI interface.

Thanks,
Takiguchi

Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114

[vcaputo]

On Wed, Dec 20, 2017 at 01:33:45AM +0100, Thomas Gleixner wrote:
> On Tue, 19 Dec 2017, vcap...@pengaru.com wrote:
> > On Wed, Dec 20, 2017 at 12:22:12AM +0100, Pavel Machek wrote:
> > > You forgot to mention commit id :-).
> > > 
> > 
> > That is very strange, anyhow:
> > 
> >  commit fdba46ffb4c203b6e6794163493fd310f98bb4be
> >  Author: Thomas Gleixner 
> >  Date:   Wed Sep 13 23:29:27 2017 +0200
> > 
> >  x86/apic: Get rid of multi CPU affinity
> > 
> > 
> > Will try reverting soon, just a bit busy today out in the desert and the sun
> > is going down so my solar panel is useless.
> 
> The revert is not trivial.
> 
> What is the exact problem and how do you reproduce that?
> 

Dang.

Ostensibly the problem is audio playback looping what seems to be stuck in
a DMA buffer when I pause the audio.

I also saw once during the bisect on a 'bad' commit, a reproduction of
this, which hung everything doing IO until it the ata1 reset happened:

[   36.606657] Monitor-Mwait will be used to enter C-3 state
[   36.628663] do_IRQ: 0.35 No irq handler for vector
[   37.875724] do_IRQ: 0.194 No irq handler for vector
[   69.099090] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[   69.099165] ata1.00: failed command: FLUSH CACHE EXT
[   69.099211] ata1.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 6
res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 
(timeout)
[   69.099285] ata1.00: status: { DRDY }
[   69.099309] ata1: hard resetting link
[   69.406185] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   69.409255] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[   69.409259] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) 
filtered out
[   69.409261] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered 
out
[   69.409433] ata1.00: supports DRM functions and may not be fully accessible
[   69.409819] ata1.00: NCQ Send/Recv Log not supported
[   69.411644] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[   69.411649] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) 
filtered out
[   69.411654] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered 
out
[   69.411842] ata1.00: supports DRM functions and may not be fully accessible
[   69.412242] ata1.00: NCQ Send/Recv Log not supported
[   69.412719] ata1.00: configured for UDMA/133
[   69.412721] ata1.00: retrying FLUSH 0xea Emask 0x4
[   69.412964] ata1: EH complete

But that is more difficult to reproduce, it doesn't seem to happen
regularly.  Infact, I thought that was independent from the audio problem
at first but now it's become clear they're all related.

The 'bad' commits always showed the 'do_IRQ: No irq handler for vector'
lines, sometimes they appear for the first time on the console when I
yanked the power cord while playing music in the quick repro cycle without
running X or anything.

What I've been doing to reproduce this is simply boot to multi-user.target,
login, run `cmus`, and play a song.  Next pull the AC power from the
thinkpad x61s.

Immediately the audio gets messed up, pausing the audio doesn't pause it,
it just loops the last tiny buffer contents.

That's all I've got right now, but it doesn't seem to be limited to the
audio problem as shown by the ata1 reset.  Also I've searched through all
my stored journals for anything resembling that ata1 problem, and there's
not a single occurrence going back ~300 boots across a handful of kernel
versions.

If you'd like to prep a patch for me to test, I'm happy to test, but I'm
not sure how online I'll be for the next 24 hours.  It's some kind of
miracle we're communicating as-is, I'm in the middle of the damn desert but
somehow there's a cell signal.

Thanks,
Vito Caputo

Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114

[vcaputo]

On Wed, Dec 20, 2017 at 01:33:45AM +0100, Thomas Gleixner wrote:
> On Tue, 19 Dec 2017, vcap...@pengaru.com wrote:
> > On Wed, Dec 20, 2017 at 12:22:12AM +0100, Pavel Machek wrote:
> > > You forgot to mention commit id :-).
> > > 
> > 
> > That is very strange, anyhow:
> > 
> >  commit fdba46ffb4c203b6e6794163493fd310f98bb4be
> >  Author: Thomas Gleixner 
> >  Date:   Wed Sep 13 23:29:27 2017 +0200
> > 
> >  x86/apic: Get rid of multi CPU affinity
> > 
> > 
> > Will try reverting soon, just a bit busy today out in the desert and the sun
> > is going down so my solar panel is useless.
> 
> The revert is not trivial.
> 
> What is the exact problem and how do you reproduce that?
> 

Dang.

Ostensibly the problem is audio playback looping what seems to be stuck in
a DMA buffer when I pause the audio.

I also saw once during the bisect on a 'bad' commit, a reproduction of
this, which hung everything doing IO until it the ata1 reset happened:

[   36.606657] Monitor-Mwait will be used to enter C-3 state
[   36.628663] do_IRQ: 0.35 No irq handler for vector
[   37.875724] do_IRQ: 0.194 No irq handler for vector
[   69.099090] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[   69.099165] ata1.00: failed command: FLUSH CACHE EXT
[   69.099211] ata1.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 6
res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 
(timeout)
[   69.099285] ata1.00: status: { DRDY }
[   69.099309] ata1: hard resetting link
[   69.406185] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   69.409255] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[   69.409259] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) 
filtered out
[   69.409261] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered 
out
[   69.409433] ata1.00: supports DRM functions and may not be fully accessible
[   69.409819] ata1.00: NCQ Send/Recv Log not supported
[   69.411644] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[   69.411649] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) 
filtered out
[   69.411654] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered 
out
[   69.411842] ata1.00: supports DRM functions and may not be fully accessible
[   69.412242] ata1.00: NCQ Send/Recv Log not supported
[   69.412719] ata1.00: configured for UDMA/133
[   69.412721] ata1.00: retrying FLUSH 0xea Emask 0x4
[   69.412964] ata1: EH complete

But that is more difficult to reproduce, it doesn't seem to happen
regularly.  Infact, I thought that was independent from the audio problem
at first but now it's become clear they're all related.

The 'bad' commits always showed the 'do_IRQ: No irq handler for vector'
lines, sometimes they appear for the first time on the console when I
yanked the power cord while playing music in the quick repro cycle without
running X or anything.

What I've been doing to reproduce this is simply boot to multi-user.target,
login, run `cmus`, and play a song.  Next pull the AC power from the
thinkpad x61s.

Immediately the audio gets messed up, pausing the audio doesn't pause it,
it just loops the last tiny buffer contents.

That's all I've got right now, but it doesn't seem to be limited to the
audio problem as shown by the ata1 reset.  Also I've searched through all
my stored journals for anything resembling that ata1 problem, and there's
not a single occurrence going back ~300 boots across a handful of kernel
versions.

If you'd like to prep a patch for me to test, I'm happy to test, but I'm
not sure how online I'll be for the next 24 hours.  It's some kind of
miracle we're communicating as-is, I'm in the middle of the damn desert but
somehow there's a cell signal.

Thanks,
Vito Caputo

Re: [v2 PATCH -tip 3/6] net: sctp: Add SCTP ACK tracking trace event

[kbuild test robot]

Hi Masami,

I love your patch! Perhaps something to improve:

[auto build test WARNING on net/master]
[also build test WARNING on v4.15-rc4 next-20171219]
[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/Masami-Hiramatsu/net-tcp-sctp-dccp-Replace-jprobe-usage-with-trace-events/20171220-081035
config: i386-randconfig-x011-201751 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from include/trace/define_trace.h:96:0,
from include/trace/events/sctp.h:96,
from net//sctp/sm_statefuns.c:63:
   include/trace/events/sctp.h: In function 
'trace_event_raw_event_sctp_probe_path':
>> include/trace/events/sctp.h:31:19: warning: cast from pointer to integer of 
>> different size [-Wpointer-to-int-cast]
  __entry->asoc = (__u64)asoc;
  ^
   include/trace/trace_events.h:719:4: note: in definition of macro 
'DECLARE_EVENT_CLASS'
 { assign; }   \
   ^~
   include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~
>> include/trace/events/sctp.h:11:1: note: in expansion of macro 'TRACE_EVENT'
TRACE_EVENT(sctp_probe_path,
^~~
>> include/trace/events/sctp.h:30:2: note: in expansion of macro 
>> 'TP_fast_assign'
 TP_fast_assign(
 ^~
   include/trace/events/sctp.h: In function 'trace_event_raw_event_sctp_probe':
   include/trace/events/sctp.h:72:19: warning: cast from pointer to integer of 
different size [-Wpointer-to-int-cast]
  __entry->asoc = (__u64)asoc;
  ^
   include/trace/trace_events.h:719:4: note: in definition of macro 
'DECLARE_EVENT_CLASS'
 { assign; }   \
   ^~
   include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~
   include/trace/events/sctp.h:50:1: note: in expansion of macro 'TRACE_EVENT'
TRACE_EVENT(sctp_probe,
^~~
   include/trace/events/sctp.h:68:2: note: in expansion of macro 
'TP_fast_assign'
 TP_fast_assign(
 ^~
   In file included from include/trace/define_trace.h:97:0,
from include/trace/events/sctp.h:96,
from net//sctp/sm_statefuns.c:63:
   include/trace/events/sctp.h: In function 'perf_trace_sctp_probe_path':
>> include/trace/events/sctp.h:31:19: warning: cast from pointer to integer of 
>> different size [-Wpointer-to-int-cast]
  __entry->asoc = (__u64)asoc;
  ^
   include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
 { assign; }   \
   ^~
   include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~
>> include/trace/events/sctp.h:11:1: note: in expansion of macro 'TRACE_EVENT'
TRACE_EVENT(sctp_probe_path,
^~~
>> include/trace/events/sctp.h:30:2: note: in expansion of macro 
>> 'TP_fast_assign'
 TP_fast_assign(
 ^~
   include/trace/events/sctp.h: In function 'perf_trace_sctp_probe':
   include/trace/events/sctp.h:72:19: warning: cast from pointer to integer of 
different size [-Wpointer-to-int-cast]
  __entry->asoc = (__u64)asoc;
  ^
   include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
 { assign; }   \
   ^~
   include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~
   include/trace/events/sctp.h:50:1: note: in expansion of macro 'TRACE_EVENT'
TRACE_EVENT(sctp_probe,
^~~
   include/trace/events/sctp.h:68:2: note: in expansion of macro 
'TP_fast_assign'
 TP_fast_assign(
 ^~

vim +31 include/trace/events/sctp.h

10  
  > 11  TRACE_EVENT(sctp_probe_path,
12  
13  TP_PROTO(struct sctp_transport *sp,
14   const struct sctp_association *asoc),
15  
16  TP_ARGS(sp, asoc),
17  
18  TP_STRUCT__entry(
19  __field(__u64, asoc)
20  __field(__u32, primary)
21  __array(__u8, ipaddr, sizeof(union sctp_addr))
22  __field(__u32, state)
23  __field(__u32, cwnd)
24  __field(__u32, ssthresh)
25  __field(__u32, flight_size)
26  __field(__u32, partial_bytes_acked)
27  __field(__u32, pathmtu)
28  ),
29  
  > 30  TP_fast_assign(
  > 31  __entry->asoc = (__u6

Re: [v2 PATCH -tip 3/6] net: sctp: Add SCTP ACK tracking trace event

[kbuild test robot]

Hi Masami,

I love your patch! Perhaps something to improve:

[auto build test WARNING on net/master]
[also build test WARNING on v4.15-rc4 next-20171219]
[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/Masami-Hiramatsu/net-tcp-sctp-dccp-Replace-jprobe-usage-with-trace-events/20171220-081035
config: i386-randconfig-x011-201751 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from include/trace/define_trace.h:96:0,
from include/trace/events/sctp.h:96,
from net//sctp/sm_statefuns.c:63:
   include/trace/events/sctp.h: In function 
'trace_event_raw_event_sctp_probe_path':
>> include/trace/events/sctp.h:31:19: warning: cast from pointer to integer of 
>> different size [-Wpointer-to-int-cast]
  __entry->asoc = (__u64)asoc;
  ^
   include/trace/trace_events.h:719:4: note: in definition of macro 
'DECLARE_EVENT_CLASS'
 { assign; }   \
   ^~
   include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~
>> include/trace/events/sctp.h:11:1: note: in expansion of macro 'TRACE_EVENT'
TRACE_EVENT(sctp_probe_path,
^~~
>> include/trace/events/sctp.h:30:2: note: in expansion of macro 
>> 'TP_fast_assign'
 TP_fast_assign(
 ^~
   include/trace/events/sctp.h: In function 'trace_event_raw_event_sctp_probe':
   include/trace/events/sctp.h:72:19: warning: cast from pointer to integer of 
different size [-Wpointer-to-int-cast]
  __entry->asoc = (__u64)asoc;
  ^
   include/trace/trace_events.h:719:4: note: in definition of macro 
'DECLARE_EVENT_CLASS'
 { assign; }   \
   ^~
   include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~
   include/trace/events/sctp.h:50:1: note: in expansion of macro 'TRACE_EVENT'
TRACE_EVENT(sctp_probe,
^~~
   include/trace/events/sctp.h:68:2: note: in expansion of macro 
'TP_fast_assign'
 TP_fast_assign(
 ^~
   In file included from include/trace/define_trace.h:97:0,
from include/trace/events/sctp.h:96,
from net//sctp/sm_statefuns.c:63:
   include/trace/events/sctp.h: In function 'perf_trace_sctp_probe_path':
>> include/trace/events/sctp.h:31:19: warning: cast from pointer to integer of 
>> different size [-Wpointer-to-int-cast]
  __entry->asoc = (__u64)asoc;
  ^
   include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
 { assign; }   \
   ^~
   include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~
>> include/trace/events/sctp.h:11:1: note: in expansion of macro 'TRACE_EVENT'
TRACE_EVENT(sctp_probe_path,
^~~
>> include/trace/events/sctp.h:30:2: note: in expansion of macro 
>> 'TP_fast_assign'
 TP_fast_assign(
 ^~
   include/trace/events/sctp.h: In function 'perf_trace_sctp_probe':
   include/trace/events/sctp.h:72:19: warning: cast from pointer to integer of 
different size [-Wpointer-to-int-cast]
  __entry->asoc = (__u64)asoc;
  ^
   include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
 { assign; }   \
   ^~
   include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~
   include/trace/events/sctp.h:50:1: note: in expansion of macro 'TRACE_EVENT'
TRACE_EVENT(sctp_probe,
^~~
   include/trace/events/sctp.h:68:2: note: in expansion of macro 
'TP_fast_assign'
 TP_fast_assign(
 ^~

vim +31 include/trace/events/sctp.h

10  
  > 11  TRACE_EVENT(sctp_probe_path,
12  
13  TP_PROTO(struct sctp_transport *sp,
14   const struct sctp_association *asoc),
15  
16  TP_ARGS(sp, asoc),
17  
18  TP_STRUCT__entry(
19  __field(__u64, asoc)
20  __field(__u32, primary)
21  __array(__u8, ipaddr, sizeof(union sctp_addr))
22  __field(__u32, state)
23  __field(__u32, cwnd)
24  __field(__u32, ssthresh)
25  __field(__u32, flight_size)
26  __field(__u32, partial_bytes_acked)
27  __field(__u32, pathmtu)
28  ),
29  
  > 30  TP_fast_assign(
  > 31  __entry->asoc = (__u6

[GIT PULL 1/2] bcm2835-dt-next-2017-12-19

[Eric Anholt]

Hi Florian,

The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:

  Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)

are available in the Git repository at:

  git://github.com/anholt/linux tags/bcm2835-dt-next-2017-12-19

for you to fetch changes up to 3edb73d87e9e824326f588b5d5c5661bf53449be:

  ARM: dts: bcm283x: Use GPIO polarity defines consistently (2017-12-08 
13:10:09 -0800)


This pull request cleans up the bcm2835 DT to use #defines for GPIO
polarity.


Stefan Wahren (1):
  ARM: dts: bcm283x: Use GPIO polarity defines consistently

 arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 4 ++--
 arch/arm/boot/dts/bcm2835-rpi-a.dts  | 2 +-
 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 4 ++--
 arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 2 +-
 arch/arm/boot/dts/bcm2835-rpi-b.dts  | 2 +-
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts| 4 ++--
 arch/arm/boot/dts/bcm2837-rpi-3-b.dts| 2 +-
 7 files changed, 10 insertions(+), 10 deletions(-)

[GIT PULL 1/2] bcm2835-dt-next-2017-12-19

[Eric Anholt]

Hi Florian,

The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:

  Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)

are available in the Git repository at:

  git://github.com/anholt/linux tags/bcm2835-dt-next-2017-12-19

for you to fetch changes up to 3edb73d87e9e824326f588b5d5c5661bf53449be:

  ARM: dts: bcm283x: Use GPIO polarity defines consistently (2017-12-08 
13:10:09 -0800)


This pull request cleans up the bcm2835 DT to use #defines for GPIO
polarity.


Stefan Wahren (1):
  ARM: dts: bcm283x: Use GPIO polarity defines consistently

 arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 4 ++--
 arch/arm/boot/dts/bcm2835-rpi-a.dts  | 2 +-
 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 4 ++--
 arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 2 +-
 arch/arm/boot/dts/bcm2835-rpi-b.dts  | 2 +-
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts| 4 ++--
 arch/arm/boot/dts/bcm2837-rpi-3-b.dts| 2 +-
 7 files changed, 10 insertions(+), 10 deletions(-)

[GIT PULL 2/2] bcm2835-drivers-next-2017-12-19

[Eric Anholt]

The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the Git repository at:

  git://github.com/anholt/linux tags/bcm2835-drivers-next-2017-12-19

for you to fetch changes up to 9107ee6a50b81180f29a9f6588b21917dde2abdd:

  firmware: raspberrypi: print time using time64_t (2017-11-28 16:24:33 -0800)


This pull request brings in a (cosmetic) y2038 fix for the Raspberry
Pi firmware driver.


Arnd Bergmann (1):
  firmware: raspberrypi: print time using time64_t

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

[GIT PULL 2/2] bcm2835-drivers-next-2017-12-19

[Eric Anholt]

The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the Git repository at:

  git://github.com/anholt/linux tags/bcm2835-drivers-next-2017-12-19

for you to fetch changes up to 9107ee6a50b81180f29a9f6588b21917dde2abdd:

  firmware: raspberrypi: print time using time64_t (2017-11-28 16:24:33 -0800)


This pull request brings in a (cosmetic) y2038 fix for the Raspberry
Pi firmware driver.


Arnd Bergmann (1):
  firmware: raspberrypi: print time using time64_t

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

Re: [PATCH v4 5/5] iommu/vt-d: Add debugfs support for Interrupt remapping

[Mehta, Sohil]

On Tue, 2017-12-19 at 23:30 +0200, Andy Shevchenko wrote:
> On Tue, 2017-12-19 at 13:08 -0800, Sohil Mehta wrote:
> > 
> > Debugfs extension for Intel IOMMU to dump Interrupt remapping table
> > entries for Interrupt remapping and Interrupt posting.
> > 
> > The file /sys/kernel/debug/intel_iommu/ir_translation_struct
> > provides
> > detailed information, such as Index, Source Id, Destination Id,
> > Vector
> > and the raw values for entries with the present bit set, in the
> > format
> > shown.
> > 
> > Remapped Interrupt supported on IOMMU: dmar5
> >  IR table address:93e09d54c310
> > ---
> >  Index  SID  Dest_ID  Vct Raw_value_high   Raw_value_low
> >  1  3a00 0600 2c  00043a00 062c0009
> >  1114301 0900 a2  00044301 09a20009
> > 
> > Posted Interrupt supported on IOMMU: dmar5
> >  IR table address:93e09d54c310
> > -
> > ---
> >  Index  SID  PDA_high PDA_low  Vct Raw_value_high   Raw_value_low
> >  4  4300 0010 40c7c880 41  00144300
> > 40c7c88000418001
> >  5  4300 0010 40c7c880 51  00144300
> > 40c7c88000518001
> > 
> > 
> > 
> > +   seq_printf(m, "\nRemapped Interrupt supported on
> > IOMMU: %s\n"
> Please, avoid leading \n.

Sure. I'll add a separate seq_puts(m, "\n") after each of the loops to
avoid having the leading '\n's.

> 
> > 
> > +      " IR table address:%p\n", iommu->name,
> > +      iommu->ir_table);
> > +
> > +   seq_puts(m, "-
> > -
> > -"
> > +    "\n");
> It's okay to use long string literal on one line. So, don't split (or
> for multi-line string literals, split by \n like you do above).
> 
Thanks. Will fix this and the other one.

> > 
> > +   seq_puts(m,
> > "\n\t\t\t\t\t\t\t\n");
> Leading \n.
> 
> > 
> > +   seq_printf(m, "\nPosted Interrupt supported on
> > IOMMU:
> > %s\n"
> Ditto.
> 
> > 
> > +      " IR table address:%p\n", iommu->name,
> > +      iommu->ir_table);
> > +
> > +   seq_puts(m, "-
> > -
> > --"
> > +    "\n");
> Join back.
> 

Re: [PATCH v4 5/5] iommu/vt-d: Add debugfs support for Interrupt remapping

[Mehta, Sohil]

On Tue, 2017-12-19 at 23:30 +0200, Andy Shevchenko wrote:
> On Tue, 2017-12-19 at 13:08 -0800, Sohil Mehta wrote:
> > 
> > Debugfs extension for Intel IOMMU to dump Interrupt remapping table
> > entries for Interrupt remapping and Interrupt posting.
> > 
> > The file /sys/kernel/debug/intel_iommu/ir_translation_struct
> > provides
> > detailed information, such as Index, Source Id, Destination Id,
> > Vector
> > and the raw values for entries with the present bit set, in the
> > format
> > shown.
> > 
> > Remapped Interrupt supported on IOMMU: dmar5
> >  IR table address:93e09d54c310
> > ---
> >  Index  SID  Dest_ID  Vct Raw_value_high   Raw_value_low
> >  1  3a00 0600 2c  00043a00 062c0009
> >  1114301 0900 a2  00044301 09a20009
> > 
> > Posted Interrupt supported on IOMMU: dmar5
> >  IR table address:93e09d54c310
> > -
> > ---
> >  Index  SID  PDA_high PDA_low  Vct Raw_value_high   Raw_value_low
> >  4  4300 0010 40c7c880 41  00144300
> > 40c7c88000418001
> >  5  4300 0010 40c7c880 51  00144300
> > 40c7c88000518001
> > 
> > 
> > 
> > +   seq_printf(m, "\nRemapped Interrupt supported on
> > IOMMU: %s\n"
> Please, avoid leading \n.

Sure. I'll add a separate seq_puts(m, "\n") after each of the loops to
avoid having the leading '\n's.

> 
> > 
> > +      " IR table address:%p\n", iommu->name,
> > +      iommu->ir_table);
> > +
> > +   seq_puts(m, "-
> > -
> > -"
> > +    "\n");
> It's okay to use long string literal on one line. So, don't split (or
> for multi-line string literals, split by \n like you do above).
> 
Thanks. Will fix this and the other one.

> > 
> > +   seq_puts(m,
> > "\n\t\t\t\t\t\t\t\n");
> Leading \n.
> 
> > 
> > +   seq_printf(m, "\nPosted Interrupt supported on
> > IOMMU:
> > %s\n"
> Ditto.
> 
> > 
> > +      " IR table address:%p\n", iommu->name,
> > +      iommu->ir_table);
> > +
> > +   seq_puts(m, "-
> > -
> > --"
> > +    "\n");
> Join back.
> 

Re: [PATCH] tools/power: Don't make man pages executable

[Laura Abbott]

On 12/19/2017 03:48 PM, Rafael J. Wysocki wrote:

On 12/19/2017 8:54 PM, Laura Abbott wrote:

rpm-lint flagged these as being executable:

kernel-tools.x86_64: W: spurious-executable-perm 
/usr/share/man/man8/turbostat.8.gz
kernel-tools.x86_64: W: spurious-executable-perm 
/usr/share/man/man8/x86_energy_perf_policy.8.gz

Fix this

Signed-off-by: Laura Abbott 


Please CC PM stuff to linux-pm (which makes it easier to handle).



Neither of these are listed in MAINTAINERS so I missed sending to
linux-pm. I'll remember for next time, do you want me to resend
for tracking?

Thanks,
Laura


---
  tools/power/x86/turbostat/Makefile  | 2 +-
  tools/power/x86/x86_energy_perf_policy/Makefile | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/power/x86/turbostat/Makefile 
b/tools/power/x86/turbostat/Makefile
index a9bc914a8fe8..2ab25aa38263 100644
--- a/tools/power/x86/turbostat/Makefile
+++ b/tools/power/x86/turbostat/Makefile
@@ -25,4 +25,4 @@ install : turbostat
  install -d  $(DESTDIR)$(PREFIX)/bin
  install $(BUILD_OUTPUT)/turbostat $(DESTDIR)$(PREFIX)/bin/turbostat
  install -d  $(DESTDIR)$(PREFIX)/share/man/man8
-    install turbostat.8 $(DESTDIR)$(PREFIX)/share/man/man8
+    install -m 644 turbostat.8 $(DESTDIR)$(PREFIX)/share/man/man8
diff --git a/tools/power/x86/x86_energy_perf_policy/Makefile 
b/tools/power/x86/x86_energy_perf_policy/Makefile
index 2447b1bbaacf..f4534fb8b951 100644
--- a/tools/power/x86/x86_energy_perf_policy/Makefile
+++ b/tools/power/x86/x86_energy_perf_policy/Makefile
@@ -24,5 +24,5 @@ install : x86_energy_perf_policy
  install -d  $(DESTDIR)$(PREFIX)/bin
  install $(BUILD_OUTPUT)/x86_energy_perf_policy 
$(DESTDIR)$(PREFIX)/bin/x86_energy_perf_policy
  install -d  $(DESTDIR)$(PREFIX)/share/man/man8
-    install x86_energy_perf_policy.8 $(DESTDIR)$(PREFIX)/share/man/man8
+    install -m 644 x86_energy_perf_policy.8 $(DESTDIR)$(PREFIX)/share/man/man8



Thanks,

Rafael

Re: [PATCH] tools/power: Don't make man pages executable

[Laura Abbott]

On 12/19/2017 03:48 PM, Rafael J. Wysocki wrote:

On 12/19/2017 8:54 PM, Laura Abbott wrote:

rpm-lint flagged these as being executable:

kernel-tools.x86_64: W: spurious-executable-perm 
/usr/share/man/man8/turbostat.8.gz
kernel-tools.x86_64: W: spurious-executable-perm 
/usr/share/man/man8/x86_energy_perf_policy.8.gz

Fix this

Signed-off-by: Laura Abbott 


Please CC PM stuff to linux-pm (which makes it easier to handle).



Neither of these are listed in MAINTAINERS so I missed sending to
linux-pm. I'll remember for next time, do you want me to resend
for tracking?

Thanks,
Laura


---
  tools/power/x86/turbostat/Makefile  | 2 +-
  tools/power/x86/x86_energy_perf_policy/Makefile | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/power/x86/turbostat/Makefile 
b/tools/power/x86/turbostat/Makefile
index a9bc914a8fe8..2ab25aa38263 100644
--- a/tools/power/x86/turbostat/Makefile
+++ b/tools/power/x86/turbostat/Makefile
@@ -25,4 +25,4 @@ install : turbostat
  install -d  $(DESTDIR)$(PREFIX)/bin
  install $(BUILD_OUTPUT)/turbostat $(DESTDIR)$(PREFIX)/bin/turbostat
  install -d  $(DESTDIR)$(PREFIX)/share/man/man8
-    install turbostat.8 $(DESTDIR)$(PREFIX)/share/man/man8
+    install -m 644 turbostat.8 $(DESTDIR)$(PREFIX)/share/man/man8
diff --git a/tools/power/x86/x86_energy_perf_policy/Makefile 
b/tools/power/x86/x86_energy_perf_policy/Makefile
index 2447b1bbaacf..f4534fb8b951 100644
--- a/tools/power/x86/x86_energy_perf_policy/Makefile
+++ b/tools/power/x86/x86_energy_perf_policy/Makefile
@@ -24,5 +24,5 @@ install : x86_energy_perf_policy
  install -d  $(DESTDIR)$(PREFIX)/bin
  install $(BUILD_OUTPUT)/x86_energy_perf_policy 
$(DESTDIR)$(PREFIX)/bin/x86_energy_perf_policy
  install -d  $(DESTDIR)$(PREFIX)/share/man/man8
-    install x86_energy_perf_policy.8 $(DESTDIR)$(PREFIX)/share/man/man8
+    install -m 644 x86_energy_perf_policy.8 $(DESTDIR)$(PREFIX)/share/man/man8



Thanks,

Rafael

Waiting For Your Urgent Replay.........

[Mr.Akram Mohamed]

My Dear,

How are you together with your family? I hope all is well. Considering
the fact, I did not know you in person or even have seen you before
but due to the true revelation that I should share this lucrative
opportunity with you, I have no choice other than to contact you. So,
kindly consider this message essential and confidential.

first and foremost I have to introduce myself to you I am Mr.Akram
Mohamed, from Burkina Faso in west Africa, the Audit and Account
Manager BANK OF AFRICA (BOA) in Ouagadougou Burkina Faso west Africa.

I had the intent to contact you over transfer of fund worth the sum of
Six million two hundred thousand u.s dollars. (Us$6.2m) for the
betterment of our life, I agree that 40% of the total amount will be
for you and 60% for me.

I need your urgent response on assurance of trust that you will not
deny my share when once the fund is transfer to your personal bank
account.

Your urgently responses is needed through this email
address:mrakram.m...@gmail.com reply with your information as I stated
it bellow once I receive your information I will give you more details
as application and how you will apply to our bank on how to transfer
the fund into your bank account.

(1) Full names:

(2) private phone number:

(3) occupation:

Make sure you keep this transaction as top secret and make it
confidential till we receive the fund into your bank account that you
will provide to our bank. Don't disclose it to anybody, because the
secret of this transaction is as well as the success of it.

I look forward to hear from you call me immediately as soon as you
receive this message or email me urgent.

In sincerity,
Mr.Akram Mohamed

Waiting For Your Urgent Replay.........

[Mr.Akram Mohamed]

My Dear,

How are you together with your family? I hope all is well. Considering
the fact, I did not know you in person or even have seen you before
but due to the true revelation that I should share this lucrative
opportunity with you, I have no choice other than to contact you. So,
kindly consider this message essential and confidential.

first and foremost I have to introduce myself to you I am Mr.Akram
Mohamed, from Burkina Faso in west Africa, the Audit and Account
Manager BANK OF AFRICA (BOA) in Ouagadougou Burkina Faso west Africa.

I had the intent to contact you over transfer of fund worth the sum of
Six million two hundred thousand u.s dollars. (Us$6.2m) for the
betterment of our life, I agree that 40% of the total amount will be
for you and 60% for me.

I need your urgent response on assurance of trust that you will not
deny my share when once the fund is transfer to your personal bank
account.

Your urgently responses is needed through this email
address:mrakram.m...@gmail.com reply with your information as I stated
it bellow once I receive your information I will give you more details
as application and how you will apply to our bank on how to transfer
the fund into your bank account.

(1) Full names:

(2) private phone number:

(3) occupation:

Make sure you keep this transaction as top secret and make it
confidential till we receive the fund into your bank account that you
will provide to our bank. Don't disclose it to anybody, because the
secret of this transaction is as well as the success of it.

I look forward to hear from you call me immediately as soon as you
receive this message or email me urgent.

In sincerity,
Mr.Akram Mohamed

Re: [v4.14-rt][report] arm: run: stress-ng --class os --all 0 -t 5m

[Grygorii Strashko]

On 12/19/2017 02:27 AM, Sebastian Andrzej Siewior wrote:
> On 2017-12-18 20:01:05 [-0600], Grygorii Strashko wrote:
>> Hi All,
> Hi,
> 
>> Below results of running stress-ng --class os --all 0 -t 5m on TI am57xx-evm 
>> (SMP, 2 cpu)
>> git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git
>> branch: linux-4.14.y-rt
>> commit: d3d9904 v4.14.6-rt7
>> - only config changes applied.
>>
>> one "WARNING: possible circular locking dependency detected"
>> [   85.943562] ==
>> [   85.943564] WARNING: possible circular locking dependency detected
>> [   85.943568] 4.14.6-rt7-dirty #29 Not tainted
>> [   85.943570] --
>> [   85.943573] stress-ng-cpu-o/764 is trying to acquire lock:
>> [   85.943576]  (>pi_lock){-...}, at: [] 
>> try_to_wake_up+0x28/0x924
>> [   85.943594]
>> [   85.943594] but task is already holding lock:
>> [   85.943596]  (hrtimer_bases.lock){-...}, at: [] 
>> hrtimer_interrupt+0x68/0x2b0
>>
>> one "WARNING: CPU: 0 PID: 3514 at kernel/rcu/tree_plugin.h:310 
>> rcu_note_context_switch+0x3e8/0x988"
>> ^ sorry, log not very readable
> 
> This should cure it, does it?
> 
> diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
> index c2c344fda487..3971fa0c7194 100644
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -1952,6 +1952,7 @@ int hrtimers_dead_cpu(unsigned int scpu)
>   BUG_ON(cpu_online(scpu));
>   tick_cancel_sched_timer(scpu);
>   
> + local_bh_disable();
>   local_irq_disable();
>   old_base = _cpu(hrtimer_bases, scpu);
>   new_base = this_cpu_ptr(_bases);
> @@ -1979,6 +1980,7 @@ int hrtimers_dead_cpu(unsigned int scpu)
>   /* Check, if we got expired work to do */
>   __hrtimer_peek_ahead_timers();
>   local_irq_enable();
> + local_bh_enable();
>   return 0;
>   }
> 

I've run test few times - can't see "WARNING: possible circular locking 
dependency detected"
any more. Below warning happened once.

[ 3091.593894] [ cut here ]
[ 3091.593909] WARNING: CPU: 0 PID: 1797 at kernel/rcu/tree_plugin.h:310 
rcu_note_context_switch+0x554/0x950
[ 3091.593912] Modules linked in:
[ 3091.593923] CPU: 0 PID: 1797 Comm: stress-ng-clock Not tainted 
4.14.6-rt7-dirty #37
[ 3091.593926] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 3091.593941] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[ 3091.593952] [] (show_stack) from [] 
(dump_stack+0xa0/0xd4)
[ 3091.593964] [] (dump_stack) from [] (__warn+0xd8/0x104)
[ 3091.593975] [] (__warn) from [] 
(warn_slowpath_null+0x20/0x28)
[ 3091.593984] [] (warn_slowpath_null) from [] 
(rcu_note_context_switch+0x554/0x950)
[ 3091.593996] [] (rcu_note_context_switch) from [] 
(__schedule+0xc4/0xa7c)
[ 3091.594005] [] (__schedule) from [] (schedule+0x60/0xf8)
[ 3091.594016] [] (schedule) from [] 
(rt_spin_lock_slowlock_locked+0xa8/0x304)
[ 3091.594026] [] (rt_spin_lock_slowlock_locked) from [] 
(__read_rt_lock+0xc0/0xf4)
[ 3091.594036] [] (__read_rt_lock) from [] 
(pin_current_cpu+0x3c/0x11c)
[ 3091.594047] [] (pin_current_cpu) from [] 
(migrate_disable+0x78/0x1e8)
[ 3091.594057] [] (migrate_disable) from [] 
(rt_spin_lock+0x14/0x4c)
[ 3091.594066] [] (rt_spin_lock) from [] 
(__lock_timer+0xc0/0x220)
[ 3091.594076] [] (__lock_timer) from [] 
(SyS_timer_gettime+0x14/0xb8)
[ 3091.594087] [] (SyS_timer_gettime) from [] 
(__sys_trace_return+0x0/0x10)
[ 3091.594091] ---[ end trace 0002 ]---


-- 
regards,
-grygorii

Re: [v4.14-rt][report] arm: run: stress-ng --class os --all 0 -t 5m

[Grygorii Strashko]

On 12/19/2017 02:27 AM, Sebastian Andrzej Siewior wrote:
> On 2017-12-18 20:01:05 [-0600], Grygorii Strashko wrote:
>> Hi All,
> Hi,
> 
>> Below results of running stress-ng --class os --all 0 -t 5m on TI am57xx-evm 
>> (SMP, 2 cpu)
>> git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git
>> branch: linux-4.14.y-rt
>> commit: d3d9904 v4.14.6-rt7
>> - only config changes applied.
>>
>> one "WARNING: possible circular locking dependency detected"
>> [   85.943562] ==
>> [   85.943564] WARNING: possible circular locking dependency detected
>> [   85.943568] 4.14.6-rt7-dirty #29 Not tainted
>> [   85.943570] --
>> [   85.943573] stress-ng-cpu-o/764 is trying to acquire lock:
>> [   85.943576]  (>pi_lock){-...}, at: [] 
>> try_to_wake_up+0x28/0x924
>> [   85.943594]
>> [   85.943594] but task is already holding lock:
>> [   85.943596]  (hrtimer_bases.lock){-...}, at: [] 
>> hrtimer_interrupt+0x68/0x2b0
>>
>> one "WARNING: CPU: 0 PID: 3514 at kernel/rcu/tree_plugin.h:310 
>> rcu_note_context_switch+0x3e8/0x988"
>> ^ sorry, log not very readable
> 
> This should cure it, does it?
> 
> diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
> index c2c344fda487..3971fa0c7194 100644
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -1952,6 +1952,7 @@ int hrtimers_dead_cpu(unsigned int scpu)
>   BUG_ON(cpu_online(scpu));
>   tick_cancel_sched_timer(scpu);
>   
> + local_bh_disable();
>   local_irq_disable();
>   old_base = _cpu(hrtimer_bases, scpu);
>   new_base = this_cpu_ptr(_bases);
> @@ -1979,6 +1980,7 @@ int hrtimers_dead_cpu(unsigned int scpu)
>   /* Check, if we got expired work to do */
>   __hrtimer_peek_ahead_timers();
>   local_irq_enable();
> + local_bh_enable();
>   return 0;
>   }
> 

I've run test few times - can't see "WARNING: possible circular locking 
dependency detected"
any more. Below warning happened once.

[ 3091.593894] [ cut here ]
[ 3091.593909] WARNING: CPU: 0 PID: 1797 at kernel/rcu/tree_plugin.h:310 
rcu_note_context_switch+0x554/0x950
[ 3091.593912] Modules linked in:
[ 3091.593923] CPU: 0 PID: 1797 Comm: stress-ng-clock Not tainted 
4.14.6-rt7-dirty #37
[ 3091.593926] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 3091.593941] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[ 3091.593952] [] (show_stack) from [] 
(dump_stack+0xa0/0xd4)
[ 3091.593964] [] (dump_stack) from [] (__warn+0xd8/0x104)
[ 3091.593975] [] (__warn) from [] 
(warn_slowpath_null+0x20/0x28)
[ 3091.593984] [] (warn_slowpath_null) from [] 
(rcu_note_context_switch+0x554/0x950)
[ 3091.593996] [] (rcu_note_context_switch) from [] 
(__schedule+0xc4/0xa7c)
[ 3091.594005] [] (__schedule) from [] (schedule+0x60/0xf8)
[ 3091.594016] [] (schedule) from [] 
(rt_spin_lock_slowlock_locked+0xa8/0x304)
[ 3091.594026] [] (rt_spin_lock_slowlock_locked) from [] 
(__read_rt_lock+0xc0/0xf4)
[ 3091.594036] [] (__read_rt_lock) from [] 
(pin_current_cpu+0x3c/0x11c)
[ 3091.594047] [] (pin_current_cpu) from [] 
(migrate_disable+0x78/0x1e8)
[ 3091.594057] [] (migrate_disable) from [] 
(rt_spin_lock+0x14/0x4c)
[ 3091.594066] [] (rt_spin_lock) from [] 
(__lock_timer+0xc0/0x220)
[ 3091.594076] [] (__lock_timer) from [] 
(SyS_timer_gettime+0x14/0xb8)
[ 3091.594087] [] (SyS_timer_gettime) from [] 
(__sys_trace_return+0x0/0x10)
[ 3091.594091] ---[ end trace 0002 ]---


-- 
regards,
-grygorii

Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114

[Thomas Gleixner]

On Tue, 19 Dec 2017, vcap...@pengaru.com wrote:
> On Wed, Dec 20, 2017 at 12:22:12AM +0100, Pavel Machek wrote:
> > You forgot to mention commit id :-).
> > 
> 
> That is very strange, anyhow:
> 
>  commit fdba46ffb4c203b6e6794163493fd310f98bb4be
>  Author: Thomas Gleixner 
>  Date:   Wed Sep 13 23:29:27 2017 +0200
> 
>  x86/apic: Get rid of multi CPU affinity
> 
> 
> Will try reverting soon, just a bit busy today out in the desert and the sun
> is going down so my solar panel is useless.

The revert is not trivial.

What is the exact problem and how do you reproduce that?

Thanks,

tglx

Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114

[Thomas Gleixner]

On Tue, 19 Dec 2017, vcap...@pengaru.com wrote:
> On Wed, Dec 20, 2017 at 12:22:12AM +0100, Pavel Machek wrote:
> > You forgot to mention commit id :-).
> > 
> 
> That is very strange, anyhow:
> 
>  commit fdba46ffb4c203b6e6794163493fd310f98bb4be
>  Author: Thomas Gleixner 
>  Date:   Wed Sep 13 23:29:27 2017 +0200
> 
>  x86/apic: Get rid of multi CPU affinity
> 
> 
> Will try reverting soon, just a bit busy today out in the desert and the sun
> is going down so my solar panel is useless.

The revert is not trivial.

What is the exact problem and how do you reproduce that?

Thanks,

tglx

Re: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop

[Thomas Gleixner]

On Tue, 19 Dec 2017, Alexandru Chirvasitu wrote:

> I had never heard of 'bisect' before this casual mention (you might tell
> I am a bit out of my depth). I've since applied it to Linus' tree between

> bebc608 Linux 4.14 (good)
> 
> and
> 
> 4fbd8d1 Linux 4.15-rc1 (bad)

Is Linus current head 4.15-rc4 bad as well?

> It took about 13 attempts (I had access to a faster machine to compile
> on, and ccache helped once the cache built up some momentum). The result
> is (as presented by 'git bisect' at the end of the process, between the
> --- dividers added by me for clarity):

> --- start of output ---
> 
> 2b5175c4fa974b6aa05bbd2ee8d443a8036a1714 is the first bad commit
> commit 2b5175c4fa974b6aa05bbd2ee8d443a8036a1714
> Author: Thomas Gleixner 
> Date:   Tue Oct 17 09:54:57 2017 +0200
> 
> genirq: Add config option for reservation mode
> 
> The interrupt reservation mode requires reactivation of PCI/MSI
> interrupts. Create a config option, so the PCI code can set the
> corresponding flag when required.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: Josh Poulson 
> Cc: Mihai Costache 
> Cc: Stephen Hemminger 
> Cc: Marc Zyngier 
> Cc: linux-...@vger.kernel.org
> Cc: Haiyang Zhang 
> Cc: Dexuan Cui 
> Cc: Simon Xiao 
> Cc: Saeed Mahameed 
> Cc: Jork Loeser 
> Cc: Bjorn Helgaas 
> Cc: de...@linuxdriverproject.org
> Cc: KY Srinivasan 
> Link: https://lkml.kernel.org/r/20171017075600.369375...@linutronix.de
> 
> :04 04 5e73031cc0c8411a20722cce7876ab7b82ed3858 
> dcf98e7a6b7d5f7c5353b7ccab02125e6d332ec8 M  kernel
> 
> --- end of output ---
> 
> Consequently, I am cc-ing in the listed addresses.

Thanks for doing that bisect, but unfortunately this commit cannot be the
problematic one, It merily adds a config symbol, but it does not change any
code at all. It has no effect whatsoever. So something might have gone
wrong in your bisecting.

I CC'ed Dou Liyang. He has changed the early APIC setup code and there has
been an issue reported already. Though I lost track of that. Dou, any
pointers?

Thanks,

tglx

Re: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop

[Thomas Gleixner]

On Tue, 19 Dec 2017, Alexandru Chirvasitu wrote:

> I had never heard of 'bisect' before this casual mention (you might tell
> I am a bit out of my depth). I've since applied it to Linus' tree between

> bebc608 Linux 4.14 (good)
> 
> and
> 
> 4fbd8d1 Linux 4.15-rc1 (bad)

Is Linus current head 4.15-rc4 bad as well?

> It took about 13 attempts (I had access to a faster machine to compile
> on, and ccache helped once the cache built up some momentum). The result
> is (as presented by 'git bisect' at the end of the process, between the
> --- dividers added by me for clarity):

> --- start of output ---
> 
> 2b5175c4fa974b6aa05bbd2ee8d443a8036a1714 is the first bad commit
> commit 2b5175c4fa974b6aa05bbd2ee8d443a8036a1714
> Author: Thomas Gleixner 
> Date:   Tue Oct 17 09:54:57 2017 +0200
> 
> genirq: Add config option for reservation mode
> 
> The interrupt reservation mode requires reactivation of PCI/MSI
> interrupts. Create a config option, so the PCI code can set the
> corresponding flag when required.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: Josh Poulson 
> Cc: Mihai Costache 
> Cc: Stephen Hemminger 
> Cc: Marc Zyngier 
> Cc: linux-...@vger.kernel.org
> Cc: Haiyang Zhang 
> Cc: Dexuan Cui 
> Cc: Simon Xiao 
> Cc: Saeed Mahameed 
> Cc: Jork Loeser 
> Cc: Bjorn Helgaas 
> Cc: de...@linuxdriverproject.org
> Cc: KY Srinivasan 
> Link: https://lkml.kernel.org/r/20171017075600.369375...@linutronix.de
> 
> :04 04 5e73031cc0c8411a20722cce7876ab7b82ed3858 
> dcf98e7a6b7d5f7c5353b7ccab02125e6d332ec8 M  kernel
> 
> --- end of output ---
> 
> Consequently, I am cc-ing in the listed addresses.

Thanks for doing that bisect, but unfortunately this commit cannot be the
problematic one, It merily adds a config symbol, but it does not change any
code at all. It has no effect whatsoever. So something might have gone
wrong in your bisecting.

I CC'ed Dou Liyang. He has changed the early APIC setup code and there has
been an issue reported already. Though I lost track of that. Dou, any
pointers?

Thanks,

tglx

[PATCH] vfb: fix video mode and line_length being set when loaded

[Pieter "PoroCYon" Sluys]

Currently, when loading the vfb module, the newly created fbdev
has a line_length of 0, and its video mode would be PSEUDOCOLOR
regardless of color depth. (The former could be worked around by
calling the FBIOPUT_VSCREENINFO ioctl with having the FBACTIVIATE_FORCE
flag set.) This patch automatically sets the line_length correctly,
and the video mode is derived from the bit depth now as well.

Thanks to Geert Uytterhoeven for confirming the bug and helping me with
the patch.

Output of `fbset -i' before the patch:
mode "1366x768-60"
# D: 72.432 MHz, H: 47.403 kHz, V: 60.004 Hz
geometry 1366 768 1366 768 32
timings 13806 120 10 14 3 32 5
rgba 8/0,8/8,8/16,8/24
endmode

Frame buffer device information:
Name: Virtual FB
Address : 0xaa1405d85000
Size: 4196352
Type: PACKED PIXELS
Visual  : PSEUDOCOLOR
XPanStep: 1
YPanStep: 1
YWrapStep   : 1
LineLength  : 0<-- note this
Accelerator : No

After:
mode "1366x768-60"
# D: 72.432 MHz, H: 47.403 kHz, V: 60.004 Hz
geometry 1366 768 1366 768 32
timings 13806 120 10 14 3 32 5
rgba 8/0,8/8,8/16,8/24
endmode

Frame buffer device information:
Name: Virtual FB
Address : 0xaa1405d85000
Size: 4196352
Type: PACKED PIXELS
Visual  : TRUECOLOR
XPanStep: 1
YPanStep: 1
YWrapStep   : 1
LineLength  : 5464
Accelerator : No

Thanks for your consideration,
Pieter "PoroCYon" Sluys

---
 drivers/video/fbdev/vfb.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c
index da653a080394..6e866fbaab8a 100644
--- a/drivers/video/fbdev/vfb.c
+++ b/drivers/video/fbdev/vfb.c
@@ -239,8 +239,25 @@ static int vfb_check_var(struct fb_var_screeninfo *var,
  */
 static int vfb_set_par(struct fb_info *info)
 {
+   switch (info->var.bits_per_pixel) {
+   case 1:
+   info->fix.visual = FB_VISUAL_MONO01;
+   break;
+   case 2:
+   case 4:
+   case 8:
+   info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
+   break;
+   case 16:
+   case 24:
+   case 32:
+   info->fix.visual = FB_VISUAL_TRUECOLOR;
+   break;
+   }
+
info->fix.line_length = get_line_length(info->var.xres_virtual,
info->var.bits_per_pixel);
+
return 0;
 }

@@ -450,6 +467,8 @@ static int vfb_probe(struct platform_device *dev)
goto err2;
platform_set_drvdata(dev, info);

+   vfb_set_par(info);
+
fb_info(info, "Virtual frame buffer device, using %ldK of video 
memory\n",
videomemorysize >> 10);
return 0;
--
2.15.1
Fix vfb not setting the video mode and line_length when loaded.
Copyright 2017 Pieter "PoroCYon" Sluys 
under the terms of the GPLv2
---
 drivers/video/fbdev/vfb.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c
index da653a080394..6e866fbaab8a 100644
--- a/drivers/video/fbdev/vfb.c
+++ b/drivers/video/fbdev/vfb.c
@@ -239,8 +239,25 @@ static int vfb_check_var(struct fb_var_screeninfo *var,
  */
 static int vfb_set_par(struct fb_info *info)
 {
+	switch (info->var.bits_per_pixel) {
+		case 1:
+			info->fix.visual = FB_VISUAL_MONO01;
+			break;
+		case 2:
+		case 4:
+		case 8:
+			info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
+			break;
+		case 16:
+		case 24:
+		case 32:
+			info->fix.visual = FB_VISUAL_TRUECOLOR;
+			break;
+	}
+
 	info->fix.line_length = get_line_length(info->var.xres_virtual,
 		info->var.bits_per_pixel);
+
 	return 0;
 }
 
@@ -450,6 +467,8 @@ static int vfb_probe(struct platform_device *dev)
 		goto err2;
 	platform_set_drvdata(dev, info);
 
+	vfb_set_par(info);
+
 	fb_info(info, "Virtual frame buffer device, using %ldK of video memory\n",
 		videomemorysize >> 10);
 	return 0;
--
2.15.1

[PATCH] vfb: fix video mode and line_length being set when loaded

[Pieter "PoroCYon" Sluys]

Currently, when loading the vfb module, the newly created fbdev
has a line_length of 0, and its video mode would be PSEUDOCOLOR
regardless of color depth. (The former could be worked around by
calling the FBIOPUT_VSCREENINFO ioctl with having the FBACTIVIATE_FORCE
flag set.) This patch automatically sets the line_length correctly,
and the video mode is derived from the bit depth now as well.

Thanks to Geert Uytterhoeven for confirming the bug and helping me with
the patch.

Output of `fbset -i' before the patch:
mode "1366x768-60"
# D: 72.432 MHz, H: 47.403 kHz, V: 60.004 Hz
geometry 1366 768 1366 768 32
timings 13806 120 10 14 3 32 5
rgba 8/0,8/8,8/16,8/24
endmode

Frame buffer device information:
Name: Virtual FB
Address : 0xaa1405d85000
Size: 4196352
Type: PACKED PIXELS
Visual  : PSEUDOCOLOR
XPanStep: 1
YPanStep: 1
YWrapStep   : 1
LineLength  : 0<-- note this
Accelerator : No

After:
mode "1366x768-60"
# D: 72.432 MHz, H: 47.403 kHz, V: 60.004 Hz
geometry 1366 768 1366 768 32
timings 13806 120 10 14 3 32 5
rgba 8/0,8/8,8/16,8/24
endmode

Frame buffer device information:
Name: Virtual FB
Address : 0xaa1405d85000
Size: 4196352
Type: PACKED PIXELS
Visual  : TRUECOLOR
XPanStep: 1
YPanStep: 1
YWrapStep   : 1
LineLength  : 5464
Accelerator : No

Thanks for your consideration,
Pieter "PoroCYon" Sluys

---
 drivers/video/fbdev/vfb.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c
index da653a080394..6e866fbaab8a 100644
--- a/drivers/video/fbdev/vfb.c
+++ b/drivers/video/fbdev/vfb.c
@@ -239,8 +239,25 @@ static int vfb_check_var(struct fb_var_screeninfo *var,
  */
 static int vfb_set_par(struct fb_info *info)
 {
+   switch (info->var.bits_per_pixel) {
+   case 1:
+   info->fix.visual = FB_VISUAL_MONO01;
+   break;
+   case 2:
+   case 4:
+   case 8:
+   info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
+   break;
+   case 16:
+   case 24:
+   case 32:
+   info->fix.visual = FB_VISUAL_TRUECOLOR;
+   break;
+   }
+
info->fix.line_length = get_line_length(info->var.xres_virtual,
info->var.bits_per_pixel);
+
return 0;
 }

@@ -450,6 +467,8 @@ static int vfb_probe(struct platform_device *dev)
goto err2;
platform_set_drvdata(dev, info);

+   vfb_set_par(info);
+
fb_info(info, "Virtual frame buffer device, using %ldK of video 
memory\n",
videomemorysize >> 10);
return 0;
--
2.15.1
Fix vfb not setting the video mode and line_length when loaded.
Copyright 2017 Pieter "PoroCYon" Sluys 
under the terms of the GPLv2
---
 drivers/video/fbdev/vfb.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c
index da653a080394..6e866fbaab8a 100644
--- a/drivers/video/fbdev/vfb.c
+++ b/drivers/video/fbdev/vfb.c
@@ -239,8 +239,25 @@ static int vfb_check_var(struct fb_var_screeninfo *var,
  */
 static int vfb_set_par(struct fb_info *info)
 {
+	switch (info->var.bits_per_pixel) {
+		case 1:
+			info->fix.visual = FB_VISUAL_MONO01;
+			break;
+		case 2:
+		case 4:
+		case 8:
+			info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
+			break;
+		case 16:
+		case 24:
+		case 32:
+			info->fix.visual = FB_VISUAL_TRUECOLOR;
+			break;
+	}
+
 	info->fix.line_length = get_line_length(info->var.xres_virtual,
 		info->var.bits_per_pixel);
+
 	return 0;
 }
 
@@ -450,6 +467,8 @@ static int vfb_probe(struct platform_device *dev)
 		goto err2;
 	platform_set_drvdata(dev, info);
 
+	vfb_set_par(info);
+
 	fb_info(info, "Virtual frame buffer device, using %ldK of video memory\n",
 		videomemorysize >> 10);
 	return 0;
--
2.15.1

Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114

[vcaputo]

On Wed, Dec 20, 2017 at 12:22:12AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > > > > > > > > Reappeared, 4.15-rc1.
> > > > > > > > > > > 
> > > > > > > > > > > [   40.473822] PM: suspend exit
> > > > > > > > > > > [   40.526027] sdhci-pci :15:00.2: Will use DMA mode 
> > > > > > > > > > > even though
> > > > > > > > > > > HW doesn't fully claim to support it.
> > > > > > > > > > > [   40.569765] e1000e: eth1 NIC Link is Down
> > > > > > > > > > > [   40.578257] sdhci-pci :15:00.2: Will use DMA mode 
> > > > > > > > > > > even though
> > > > > > > > > > > HW doesn't fully claim to support it.
> > > > > > > > > > > [   40.648476] sdhci-pci :15:00.2: Will use DMA mode 
> > > > > > > > > > > even though
> > > > > > > > > > > HW doesn't fully claim to support it.
> > > > > > > > > > > [   40.737339] sdhci-pci :15:00.2: Will use DMA mode 
> > > > > > > > > > > even though
> > > > > > > > > > > HW doesn't fully claim to support it.
> > > > > > > > > > > [   43.018955] wlan0: authenticate with 00:00:00:00:00:01
> > > > > > > > > > > [   43.019072] wlan0: send auth to 00:00:00:00:00:01 (try 
> > > > > > > > > > > 1/3)
> > > > > > > > > > > [   43.023955] wlan0: authenticated
> > > > > > > > > > > [   43.031721] wlan0: associate with 00:00:00:00:00:01 
> > > > > > > > > > > (try 1/3)
> > > > > > > > > > > [   43.039733] wlan0: RX AssocResp from 00:00:00:00:00:01 
> > > > > > > > > > > (capab=0x401
> > > > > > > > > > > status=0 aid=1)
> > > > > > > > > > > [   43.042712] wlan0: associated
> > > > > > > > > > > [  480.662456] snd_hda_intel :00:1b.0: IRQ timing 
> > > > > > > > > > > workaround is
> > > > > > > > > > > activated for card #0. Suggest a bigger bdl_pos_adj.
> > > > > > > > > > 
> > > > > > > > > > This message is often superfluous, so don't take this too 
> > > > > > > > > > seriously.
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > pavel@amd:~$
> > > > > > > > > > > 
> > > > > > > > > > > Again, mplayer has problems, mpg123 works. This time 
> > > > > > > > > > > mplayer started
> > > > > > > > > > > playing video (w/o sound) after long delay.
> > > > > > > > > > > 
> > > > > > > > > > > Uh. huh. And now problems appeared in mpg123, too, and 
> > > > > > > > > > > then went away
> > > > > > > > > > > in mpg123 _and_ mplayer. Interesting.
> > > > > > > > > > > 
> > > > > > > > > > > I suspect some pulseaudio fun. chromium always has sound 
> > > > > > > > > > > problems,
> > > > > > > > > > > then I restart chromium and everything is ok. But 
> > > > > > > > > > > something changed in
> > > > > > > > > > > -next and 4.15-rc1, because mplayer did not have problems 
> > > > > > > > > > > before.
> > > > > > > > > > 
> > > > > > > > > > Hm, there is no code change at all in sound/*.  If it 
> > > > > > > > > > happens only in
> > > > > > > > > > linux-next, it must be something else...
> > > > > > > > > 
> > > > > > > > > It happened first in -next, now it is in 4.15-rc1.
> > > > > > > > 
> > > > > > > > So you meant a possible regression between 4.14 and 4.15-rc1?
> > > > > > > 
> > > > > > > Yes.
> > > > > > 
> > > > > > Hm, as far as I see, the only significant difference is the commit
> > > > > > 20e3f985bb875fea4f86b04eba4b6cc29bfd6b71
> > > > > > ALSA: pcm: update tstamp only if audio_tstamp changed
> > > > > > 
> > > > > > Another change d6c0615f510bc1ee26cfb2b9a3343ac99b9c46fb
> > > > > > ALSA: hda - Fix yet remaining issue with vmaster 0dB
> > > > > > initialization
> > > > > > is basically for fixing a previous wrong fix, and it should 
> > > > > > influence
> > > > > > on all use cases, not only for a specific application.
> > > > > 
> > > > > Happened again, this time on -rc3. It is more than "audio is silent"
> > > > > -- apps behave strangely. Let me test with
> > > > > 20e3f985bb875fea4f86b04eba4b6cc29bfd6b71 reverted.
> > > > > 
> > > > > Hmm. This is 4th regression this release cycle :-(.
> > > > 
> > > > 
> > > > Today I jumped to 4.15-rc4 from 4.14-rc6, and have noticed some oddities
> > > > with audio in youtube under firefox which I never experienced before.
> > > > 
> > > > If I pause the playback, the audio seems to infinitely loop on whatever
> > > > is in the dma buffer.  Resuming playback works but now the expected
> > > > audio has repeated pops and clicks mixed in with it.
> > > > 
> > > > Even closing firefox doesn't seem to stop the looping buffer...
> > > > 
> > > > Machine is an x61s 1.8ghz thinkpad, x86_64, debian stretch, .config 
> > > > attached.
> > > > 
> > > > This for me is a 4.15 blocker, and I presume it's related to Pavel's
> > > > experience as the x60 isn't much different AFAIK.
> > > > 
> > > 
> > > Just reproduced this, it seems to be trivial to repro and doesn't
> > > actually require pausing or anything.  Simply watching a youtube video
> > > causes the audio to get messed up after a short period.
> > > 
> > > I monitored `journalctl --dmesg --follow` while reproducing this and saw
> > > this line appear at 

Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114

[vcaputo]

On Wed, Dec 20, 2017 at 12:22:12AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > > > > > > > > Reappeared, 4.15-rc1.
> > > > > > > > > > > 
> > > > > > > > > > > [   40.473822] PM: suspend exit
> > > > > > > > > > > [   40.526027] sdhci-pci :15:00.2: Will use DMA mode 
> > > > > > > > > > > even though
> > > > > > > > > > > HW doesn't fully claim to support it.
> > > > > > > > > > > [   40.569765] e1000e: eth1 NIC Link is Down
> > > > > > > > > > > [   40.578257] sdhci-pci :15:00.2: Will use DMA mode 
> > > > > > > > > > > even though
> > > > > > > > > > > HW doesn't fully claim to support it.
> > > > > > > > > > > [   40.648476] sdhci-pci :15:00.2: Will use DMA mode 
> > > > > > > > > > > even though
> > > > > > > > > > > HW doesn't fully claim to support it.
> > > > > > > > > > > [   40.737339] sdhci-pci :15:00.2: Will use DMA mode 
> > > > > > > > > > > even though
> > > > > > > > > > > HW doesn't fully claim to support it.
> > > > > > > > > > > [   43.018955] wlan0: authenticate with 00:00:00:00:00:01
> > > > > > > > > > > [   43.019072] wlan0: send auth to 00:00:00:00:00:01 (try 
> > > > > > > > > > > 1/3)
> > > > > > > > > > > [   43.023955] wlan0: authenticated
> > > > > > > > > > > [   43.031721] wlan0: associate with 00:00:00:00:00:01 
> > > > > > > > > > > (try 1/3)
> > > > > > > > > > > [   43.039733] wlan0: RX AssocResp from 00:00:00:00:00:01 
> > > > > > > > > > > (capab=0x401
> > > > > > > > > > > status=0 aid=1)
> > > > > > > > > > > [   43.042712] wlan0: associated
> > > > > > > > > > > [  480.662456] snd_hda_intel :00:1b.0: IRQ timing 
> > > > > > > > > > > workaround is
> > > > > > > > > > > activated for card #0. Suggest a bigger bdl_pos_adj.
> > > > > > > > > > 
> > > > > > > > > > This message is often superfluous, so don't take this too 
> > > > > > > > > > seriously.
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > pavel@amd:~$
> > > > > > > > > > > 
> > > > > > > > > > > Again, mplayer has problems, mpg123 works. This time 
> > > > > > > > > > > mplayer started
> > > > > > > > > > > playing video (w/o sound) after long delay.
> > > > > > > > > > > 
> > > > > > > > > > > Uh. huh. And now problems appeared in mpg123, too, and 
> > > > > > > > > > > then went away
> > > > > > > > > > > in mpg123 _and_ mplayer. Interesting.
> > > > > > > > > > > 
> > > > > > > > > > > I suspect some pulseaudio fun. chromium always has sound 
> > > > > > > > > > > problems,
> > > > > > > > > > > then I restart chromium and everything is ok. But 
> > > > > > > > > > > something changed in
> > > > > > > > > > > -next and 4.15-rc1, because mplayer did not have problems 
> > > > > > > > > > > before.
> > > > > > > > > > 
> > > > > > > > > > Hm, there is no code change at all in sound/*.  If it 
> > > > > > > > > > happens only in
> > > > > > > > > > linux-next, it must be something else...
> > > > > > > > > 
> > > > > > > > > It happened first in -next, now it is in 4.15-rc1.
> > > > > > > > 
> > > > > > > > So you meant a possible regression between 4.14 and 4.15-rc1?
> > > > > > > 
> > > > > > > Yes.
> > > > > > 
> > > > > > Hm, as far as I see, the only significant difference is the commit
> > > > > > 20e3f985bb875fea4f86b04eba4b6cc29bfd6b71
> > > > > > ALSA: pcm: update tstamp only if audio_tstamp changed
> > > > > > 
> > > > > > Another change d6c0615f510bc1ee26cfb2b9a3343ac99b9c46fb
> > > > > > ALSA: hda - Fix yet remaining issue with vmaster 0dB
> > > > > > initialization
> > > > > > is basically for fixing a previous wrong fix, and it should 
> > > > > > influence
> > > > > > on all use cases, not only for a specific application.
> > > > > 
> > > > > Happened again, this time on -rc3. It is more than "audio is silent"
> > > > > -- apps behave strangely. Let me test with
> > > > > 20e3f985bb875fea4f86b04eba4b6cc29bfd6b71 reverted.
> > > > > 
> > > > > Hmm. This is 4th regression this release cycle :-(.
> > > > 
> > > > 
> > > > Today I jumped to 4.15-rc4 from 4.14-rc6, and have noticed some oddities
> > > > with audio in youtube under firefox which I never experienced before.
> > > > 
> > > > If I pause the playback, the audio seems to infinitely loop on whatever
> > > > is in the dma buffer.  Resuming playback works but now the expected
> > > > audio has repeated pops and clicks mixed in with it.
> > > > 
> > > > Even closing firefox doesn't seem to stop the looping buffer...
> > > > 
> > > > Machine is an x61s 1.8ghz thinkpad, x86_64, debian stretch, .config 
> > > > attached.
> > > > 
> > > > This for me is a 4.15 blocker, and I presume it's related to Pavel's
> > > > experience as the x60 isn't much different AFAIK.
> > > > 
> > > 
> > > Just reproduced this, it seems to be trivial to repro and doesn't
> > > actually require pausing or anything.  Simply watching a youtube video
> > > causes the audio to get messed up after a short period.
> > > 
> > > I monitored `journalctl --dmesg --follow` while reproducing this and saw
> > > this line appear at 

Re: [PATCH v4 1/3] dt-bindings: mailbox: Introduce Hi3660 controller binding

[Leo Yan]

On Tue, Dec 19, 2017 at 05:30:38PM -0600, Rob Herring wrote:
> On Tue, Dec 19, 2017 at 07:15:43PM +0800, Kaihua Zhong wrote:
> > From: Leo Yan 
> > 
> > Introduce a binding for the Hi3660 mailbox controller, the mailbox is
> > used within application processor (AP), communication processor (CP),
> > HIFI and MCU, etc.
> > 
> > Signed-off-by: Leo Yan 
> > ---
> >  .../bindings/mailbox/hisilicon,hi3660-mailbox.txt  | 51 
> > ++
> >  1 file changed, 51 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/mailbox/hisilicon,hi3660-mailbox.txt
> 
> Please add acks when posting new versions.

Thanks, Rob.

This is my bad :) and will add acks in later version.

Thanks,
Leo Yan

Re: [PATCH v4 1/3] dt-bindings: mailbox: Introduce Hi3660 controller binding

[Leo Yan]

On Tue, Dec 19, 2017 at 05:30:38PM -0600, Rob Herring wrote:
> On Tue, Dec 19, 2017 at 07:15:43PM +0800, Kaihua Zhong wrote:
> > From: Leo Yan 
> > 
> > Introduce a binding for the Hi3660 mailbox controller, the mailbox is
> > used within application processor (AP), communication processor (CP),
> > HIFI and MCU, etc.
> > 
> > Signed-off-by: Leo Yan 
> > ---
> >  .../bindings/mailbox/hisilicon,hi3660-mailbox.txt  | 51 
> > ++
> >  1 file changed, 51 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/mailbox/hisilicon,hi3660-mailbox.txt
> 
> Please add acks when posting new versions.

Thanks, Rob.

This is my bad :) and will add acks in later version.

Thanks,
Leo Yan

Maintainer docs for patch merging

[Tobin C. Harding]

Hi,

Recently we started a maintainer book (merged into Jonathan's docs-next
branch).

Would any current maintainers please be willing to explain how they go
about generating the automated emails one often receives when a patch
[set] is applied.

This may also be related to tree/branch management for maintainers
kernel.org shows some people like to use multiple trees and some use
branches? 

If deemed relevant we could add a section to the new book (and I'd also
like to know how to do it for my own tree please so I can copy ;)

I have CC'd Greg and Andrew because they seem to have a system in place
for this.

No rush on this, I know Christmas is soon.

thanks,
Tobin.

Maintainer docs for patch merging

[Tobin C. Harding]

Hi,

Recently we started a maintainer book (merged into Jonathan's docs-next
branch).

Would any current maintainers please be willing to explain how they go
about generating the automated emails one often receives when a patch
[set] is applied.

This may also be related to tree/branch management for maintainers
kernel.org shows some people like to use multiple trees and some use
branches? 

If deemed relevant we could add a section to the new book (and I'd also
like to know how to do it for my own tree please so I can copy ;)

I have CC'd Greg and Andrew because they seem to have a system in place
for this.

No rush on this, I know Christmas is soon.

thanks,
Tobin.

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

[Bruno Wolff III]

On Tue, Dec 19, 2017 at 10:24:52 -0800,
 Shaohua Li  wrote:


Not sure if this is MD related, but could you please check if this debug patch
changes anything?


The system still had cpu hangs. I've attached dmesg output saved by systemd 
and retrieved after booting with a pre-rc2 kernel.
-- Logs begin at Sun 2017-10-15 17:28:43 CDT, end at Tue 2017-12-19 16:44:19 
CST. --
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: microcode: microcode updated early 
to revision 0x3a, date = 2017-01-30
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: Linux version 4.15.0-rc4+ 
(br...@cerberus.csd.uwm.edu) (gcc version 7.2.1 20170915 (Red Hat 7.2.1-4) 
(GCC)) #20 SMP Tue Dec 19 16:11:36 CST 2017
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: Command line: 
BOOT_IMAGE=/vmlinuz-4.15.0-rc4+ 
root=/dev/mapper/luks-f5e2d09b-f8a3-487d-9517-abe4fb0eada3 ro 
rd.md.uuid=7f4fcca0:13b1445f:a91ff455:6bb1ab48 
rd.luks.uuid=luks-cc6ee93c-e729-4f78-9baf-0cc5cc8a9ff1 
rd.md.uuid=ef18531c:760102fb:7797cbdb:5cf9516f 
rd.md.uuid=42efe386:0c315f28:f7c61920:ea098f81 
rd.luks.uuid=luks-f5e2d09b-f8a3-487d-9517-abe4fb0eada3 LANG=en_US.UTF-8
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: x86/fpu: Supporting XSAVE feature 
0x001: 'x87 floating point registers'
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: x86/fpu: Supporting XSAVE feature 
0x002: 'SSE registers'
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: x86/fpu: Supporting XSAVE feature 
0x004: 'AVX registers'
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: x86/fpu: xstate_offset[2]:  576, 
xstate_sizes[2]:  256
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: x86/fpu: Enabled xstate features 
0x7, context size is 832 bytes, using 'standard' format.
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: e820: BIOS-provided physical RAM 
map:
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x-0x0009e7ff] usable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x0009e800-0x0009] reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x000e-0x000f] reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x0010-0x998f1fff] usable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x998f2000-0x9a29dfff] reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x9a29e000-0x9a2e6fff] ACPI data
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x9a2e7000-0x9af43fff] ACPI NVS
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x9af44000-0x9b40afff] reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x9b40b000-0x9b40bfff] usable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x9b40c000-0x9b419fff] reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x9b41a000-0x9cff] usable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0xa000-0xafff] reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0xfed1c000-0xfed1] reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0xff00-0x] reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x0001-0x00085fff] usable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: NX (Execute Disable) protection: 
active
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: random: fast init done
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: SMBIOS 2.8 present.
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: DMI: Dell Inc. Precision Tower 
5810/0WR1RF, BIOS A07 04/14/2015
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: e820: update [mem 
0x-0x0fff] usable ==> reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: e820: remove [mem 
0x000a-0x000f] usable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: e820: last_pfn = 0x86 
max_arch_pfn = 0x4
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: MTRR default type: write-back
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: MTRR fixed ranges enabled:
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   0-9 write-back
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   A-B uncachable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   C-E3FFF write-through
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   E4000-F write-protect
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: MTRR variable ranges enabled:
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   0 base C000 mask 
3FFFC000 uncachable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   1 base A000 mask 
3FFFE000 uncachable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   2 base 0300 mask 
3FC0 uncachable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   3 base 9E00 mask 
3E00 uncachable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   4 base 

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

[Bruno Wolff III]

On Tue, Dec 19, 2017 at 10:24:52 -0800,
 Shaohua Li  wrote:


Not sure if this is MD related, but could you please check if this debug patch
changes anything?


The system still had cpu hangs. I've attached dmesg output saved by systemd 
and retrieved after booting with a pre-rc2 kernel.
-- Logs begin at Sun 2017-10-15 17:28:43 CDT, end at Tue 2017-12-19 16:44:19 
CST. --
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: microcode: microcode updated early 
to revision 0x3a, date = 2017-01-30
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: Linux version 4.15.0-rc4+ 
(br...@cerberus.csd.uwm.edu) (gcc version 7.2.1 20170915 (Red Hat 7.2.1-4) 
(GCC)) #20 SMP Tue Dec 19 16:11:36 CST 2017
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: Command line: 
BOOT_IMAGE=/vmlinuz-4.15.0-rc4+ 
root=/dev/mapper/luks-f5e2d09b-f8a3-487d-9517-abe4fb0eada3 ro 
rd.md.uuid=7f4fcca0:13b1445f:a91ff455:6bb1ab48 
rd.luks.uuid=luks-cc6ee93c-e729-4f78-9baf-0cc5cc8a9ff1 
rd.md.uuid=ef18531c:760102fb:7797cbdb:5cf9516f 
rd.md.uuid=42efe386:0c315f28:f7c61920:ea098f81 
rd.luks.uuid=luks-f5e2d09b-f8a3-487d-9517-abe4fb0eada3 LANG=en_US.UTF-8
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: x86/fpu: Supporting XSAVE feature 
0x001: 'x87 floating point registers'
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: x86/fpu: Supporting XSAVE feature 
0x002: 'SSE registers'
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: x86/fpu: Supporting XSAVE feature 
0x004: 'AVX registers'
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: x86/fpu: xstate_offset[2]:  576, 
xstate_sizes[2]:  256
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: x86/fpu: Enabled xstate features 
0x7, context size is 832 bytes, using 'standard' format.
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: e820: BIOS-provided physical RAM 
map:
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x-0x0009e7ff] usable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x0009e800-0x0009] reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x000e-0x000f] reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x0010-0x998f1fff] usable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x998f2000-0x9a29dfff] reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x9a29e000-0x9a2e6fff] ACPI data
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x9a2e7000-0x9af43fff] ACPI NVS
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x9af44000-0x9b40afff] reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x9b40b000-0x9b40bfff] usable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x9b40c000-0x9b419fff] reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x9b41a000-0x9cff] usable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0xa000-0xafff] reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0xfed1c000-0xfed1] reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0xff00-0x] reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: BIOS-e820: [mem 
0x0001-0x00085fff] usable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: NX (Execute Disable) protection: 
active
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: random: fast init done
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: SMBIOS 2.8 present.
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: DMI: Dell Inc. Precision Tower 
5810/0WR1RF, BIOS A07 04/14/2015
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: e820: update [mem 
0x-0x0fff] usable ==> reserved
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: e820: remove [mem 
0x000a-0x000f] usable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: e820: last_pfn = 0x86 
max_arch_pfn = 0x4
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: MTRR default type: write-back
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: MTRR fixed ranges enabled:
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   0-9 write-back
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   A-B uncachable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   C-E3FFF write-through
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   E4000-F write-protect
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel: MTRR variable ranges enabled:
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   0 base C000 mask 
3FFFC000 uncachable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   1 base A000 mask 
3FFFE000 uncachable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   2 base 0300 mask 
3FC0 uncachable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   3 base 9E00 mask 
3E00 uncachable
Dec 19 16:35:05 cerberus.csd.uwm.edu kernel:   4 base E000 mask 

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

[Thomas Gleixner]

On Tue, 19 Dec 2017, Thomas Gleixner wrote:
> On Tue, 19 Dec 2017, Ingo Molnar wrote:
> We don't run out of space, but the 0-day robot triggered a nasty issue.
> 
> The fixmap bottom address, which contains the early_ioremap fixmap area, is:
> 
> vaddr_bt = FIXADDR_TOP - FIX_BTMAP_BEGIN * PAGE_SIZE
> 
> If that address is lower than:
> 
> vaddr_end = __START_KERNEL_map + KERNEL_IMAGE_SIZE;
> 
> then cleanup_highmap() will happily 0 out the PMD entry for the PTE page of
> FIX_BTMAP. That entry was set up earlier in early_ioremap_init().
> 
> As a consequence the first call to __early_set_fixmap() which tries to
> install a PTE for early_ioremap() will crash and burn.
> 
> Below is a nasty hack which fixes the problem. Ideally we get all of this
> cpu_entry_stuff out of the fixmap. I'll look into that later, but for now
> the patch 'fixes' the issue.

I had a stab on moving the cpu_entry_area to some other place.

The patch below works, but:

 - it breaks i386 build because I have not yet found a way to place the
   CPU_ENTRY_AREA_BASE without creating include recursion hell

 - it probably does not work on XEN_PV, but I'm too tired now to figure
   that out.

Thanks,

tglx

8<---

 Documentation/x86/x86_64/mm.txt |4 
 arch/x86/events/intel/ds.c  |   53 ++--
 arch/x86/include/asm/desc.h |1 
 arch/x86/include/asm/fixmap.h   |   89 
 arch/x86/include/asm/pgtable_32_types.h |6 -
 arch/x86/include/asm/pgtable_64_types.h |   49 ++-
 arch/x86/kernel/cpu/common.c|  125 
 arch/x86/kernel/dumpstack.c |1 
 arch/x86/kernel/traps.c |5 -
 arch/x86/mm/Makefile|2 
 arch/x86/mm/dump_pagetables.c   |2 
 arch/x86/mm/kasan_init_64.c |6 -
 arch/x86/mm/pti.c   |   39 +++--
 arch/x86/xen/mmu_pv.c   |2 
 b/arch/x86/include/asm/cpu_entry_area.h |   79 ++
 b/arch/x86/mm/cpu_entry_area.c  |  138 
 16 files changed, 309 insertions(+), 292 deletions(-)

--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -12,7 +12,8 @@ ea00 - eaff (=40
 ... unused hole ...
 ec00 - fbff (=44 bits) kasan shadow memory (16TB)
 ... unused hole ...
-fe80 - feff (=39 bits) LDT remap for PTI
+fe00 - fe7f (=39 bits) LDT remap for PTI
+fe80 - feff (=39 bits) cpu_entry_area mapping
 ff00 - ff7f (=39 bits) %esp fixup stacks
 ... unused hole ...
 ffef - fffe (=64 GB) EFI region mapping space
@@ -36,6 +37,7 @@ ffd4 - ffd5 (=49
 ... unused hole ...
 ffdf - fc00 (=53 bits) kasan shadow memory (8PB)
 ... unused hole ...
+fe80 - feff (=39 bits) cpu_entry_area mapping
 ff00 - ff7f (=39 bits) %esp fixup stacks
 ... unused hole ...
 ffef - fffe (=64 GB) EFI region mapping space
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -76,36 +76,39 @@ typedef struct { pteval_t pte; } pte_t;
 #define PGDIR_MASK (~(PGDIR_SIZE - 1))
 
 /* See Documentation/x86/x86_64/mm.txt for a description of the memory map. */
-#define MAXMEM _AC(__AC(1, UL) << MAX_PHYSMEM_BITS, UL)
+#define MAXMEM _AC(__AC(1, UL) << MAX_PHYSMEM_BITS, UL)
 #ifdef CONFIG_X86_5LEVEL
-#define VMALLOC_SIZE_TB _AC(12800, UL)
-#define __VMALLOC_BASE _AC(0xffa0, UL)
-#define __VMEMMAP_BASE _AC(0xffd4, UL)
-#define LDT_PGD_ENTRY _AC(-112, UL)
-#define LDT_BASE_ADDR (LDT_PGD_ENTRY << PGDIR_SHIFT)
+#define VMALLOC_SIZE_TB_AC(12800, UL)
+#define __VMALLOC_BASE _AC(0xffa0, UL)
+#define __VMEMMAP_BASE _AC(0xffd4, UL)
+#define LDT_PGD_ENTRY  _AC(-112, UL)
+#define LDT_BASE_ADDR  (LDT_PGD_ENTRY << PGDIR_SHIFT)
 #else
-#define VMALLOC_SIZE_TB_AC(32, UL)
-#define __VMALLOC_BASE _AC(0xc900, UL)
-#define __VMEMMAP_BASE _AC(0xea00, UL)
-#define LDT_PGD_ENTRY _AC(-3, UL)
-#define LDT_BASE_ADDR (LDT_PGD_ENTRY << PGDIR_SHIFT)
+#define VMALLOC_SIZE_TB_AC(32, UL)
+#define __VMALLOC_BASE _AC(0xc900, UL)
+#define __VMEMMAP_BASE _AC(0xea00, UL)
+#define LDT_PGD_ENTRY  _AC(-4, UL)
+#define LDT_BASE_ADDR  (LDT_PGD_ENTRY << PGDIR_SHIFT)
 #endif
 #ifdef CONFIG_RANDOMIZE_MEMORY
-#define VMALLOC_START  vmalloc_base
-#define VMEMMAP_START  vmemmap_base
+#define VMALLOC_START  vmalloc_base
+#define VMEMMAP_START  vmemmap_base
 #else
-#define VMALLOC_START  __VMALLOC_BASE
-#define VMEMMAP_START  __VMEMMAP_BASE

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

[Thomas Gleixner]

On Tue, 19 Dec 2017, Thomas Gleixner wrote:
> On Tue, 19 Dec 2017, Ingo Molnar wrote:
> We don't run out of space, but the 0-day robot triggered a nasty issue.
> 
> The fixmap bottom address, which contains the early_ioremap fixmap area, is:
> 
> vaddr_bt = FIXADDR_TOP - FIX_BTMAP_BEGIN * PAGE_SIZE
> 
> If that address is lower than:
> 
> vaddr_end = __START_KERNEL_map + KERNEL_IMAGE_SIZE;
> 
> then cleanup_highmap() will happily 0 out the PMD entry for the PTE page of
> FIX_BTMAP. That entry was set up earlier in early_ioremap_init().
> 
> As a consequence the first call to __early_set_fixmap() which tries to
> install a PTE for early_ioremap() will crash and burn.
> 
> Below is a nasty hack which fixes the problem. Ideally we get all of this
> cpu_entry_stuff out of the fixmap. I'll look into that later, but for now
> the patch 'fixes' the issue.

I had a stab on moving the cpu_entry_area to some other place.

The patch below works, but:

 - it breaks i386 build because I have not yet found a way to place the
   CPU_ENTRY_AREA_BASE without creating include recursion hell

 - it probably does not work on XEN_PV, but I'm too tired now to figure
   that out.

Thanks,

tglx

8<---

 Documentation/x86/x86_64/mm.txt |4 
 arch/x86/events/intel/ds.c  |   53 ++--
 arch/x86/include/asm/desc.h |1 
 arch/x86/include/asm/fixmap.h   |   89 
 arch/x86/include/asm/pgtable_32_types.h |6 -
 arch/x86/include/asm/pgtable_64_types.h |   49 ++-
 arch/x86/kernel/cpu/common.c|  125 
 arch/x86/kernel/dumpstack.c |1 
 arch/x86/kernel/traps.c |5 -
 arch/x86/mm/Makefile|2 
 arch/x86/mm/dump_pagetables.c   |2 
 arch/x86/mm/kasan_init_64.c |6 -
 arch/x86/mm/pti.c   |   39 +++--
 arch/x86/xen/mmu_pv.c   |2 
 b/arch/x86/include/asm/cpu_entry_area.h |   79 ++
 b/arch/x86/mm/cpu_entry_area.c  |  138 
 16 files changed, 309 insertions(+), 292 deletions(-)

--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -12,7 +12,8 @@ ea00 - eaff (=40
 ... unused hole ...
 ec00 - fbff (=44 bits) kasan shadow memory (16TB)
 ... unused hole ...
-fe80 - feff (=39 bits) LDT remap for PTI
+fe00 - fe7f (=39 bits) LDT remap for PTI
+fe80 - feff (=39 bits) cpu_entry_area mapping
 ff00 - ff7f (=39 bits) %esp fixup stacks
 ... unused hole ...
 ffef - fffe (=64 GB) EFI region mapping space
@@ -36,6 +37,7 @@ ffd4 - ffd5 (=49
 ... unused hole ...
 ffdf - fc00 (=53 bits) kasan shadow memory (8PB)
 ... unused hole ...
+fe80 - feff (=39 bits) cpu_entry_area mapping
 ff00 - ff7f (=39 bits) %esp fixup stacks
 ... unused hole ...
 ffef - fffe (=64 GB) EFI region mapping space
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -76,36 +76,39 @@ typedef struct { pteval_t pte; } pte_t;
 #define PGDIR_MASK (~(PGDIR_SIZE - 1))
 
 /* See Documentation/x86/x86_64/mm.txt for a description of the memory map. */
-#define MAXMEM _AC(__AC(1, UL) << MAX_PHYSMEM_BITS, UL)
+#define MAXMEM _AC(__AC(1, UL) << MAX_PHYSMEM_BITS, UL)
 #ifdef CONFIG_X86_5LEVEL
-#define VMALLOC_SIZE_TB _AC(12800, UL)
-#define __VMALLOC_BASE _AC(0xffa0, UL)
-#define __VMEMMAP_BASE _AC(0xffd4, UL)
-#define LDT_PGD_ENTRY _AC(-112, UL)
-#define LDT_BASE_ADDR (LDT_PGD_ENTRY << PGDIR_SHIFT)
+#define VMALLOC_SIZE_TB_AC(12800, UL)
+#define __VMALLOC_BASE _AC(0xffa0, UL)
+#define __VMEMMAP_BASE _AC(0xffd4, UL)
+#define LDT_PGD_ENTRY  _AC(-112, UL)
+#define LDT_BASE_ADDR  (LDT_PGD_ENTRY << PGDIR_SHIFT)
 #else
-#define VMALLOC_SIZE_TB_AC(32, UL)
-#define __VMALLOC_BASE _AC(0xc900, UL)
-#define __VMEMMAP_BASE _AC(0xea00, UL)
-#define LDT_PGD_ENTRY _AC(-3, UL)
-#define LDT_BASE_ADDR (LDT_PGD_ENTRY << PGDIR_SHIFT)
+#define VMALLOC_SIZE_TB_AC(32, UL)
+#define __VMALLOC_BASE _AC(0xc900, UL)
+#define __VMEMMAP_BASE _AC(0xea00, UL)
+#define LDT_PGD_ENTRY  _AC(-4, UL)
+#define LDT_BASE_ADDR  (LDT_PGD_ENTRY << PGDIR_SHIFT)
 #endif
 #ifdef CONFIG_RANDOMIZE_MEMORY
-#define VMALLOC_START  vmalloc_base
-#define VMEMMAP_START  vmemmap_base
+#define VMALLOC_START  vmalloc_base
+#define VMEMMAP_START  vmemmap_base
 #else
-#define VMALLOC_START  __VMALLOC_BASE
-#define VMEMMAP_START  __VMEMMAP_BASE

Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures

[Paul E. McKenney]

On Tue, Dec 19, 2017 at 02:12:06PM -0800, Matthew Wilcox wrote:
> On Tue, Dec 19, 2017 at 09:41:58PM +0100, Jesper Dangaard Brouer wrote:
> > If I had to implement this: I would choose to do the optimization in
> > __rcu_process_callbacks() create small on-call-stack ptr-array for
> > kfree_bulk().  I would only optimize the case that call kfree()
> > directly.  In the while(list) loop I would defer calling
> > __rcu_reclaim() for __is_kfree_rcu_offset(head->func), and instead add
> > them to the ptr-array (and flush if the array is full in loop, and
> > kfree_bulk flush after loop).
> > 
> > The real advantage of kfree_bulk() comes from amortizing the per kfree
> > (behind-the-scenes) sync cost.  There is an additional benefit, because
> > objects comes from RCU and will hit a slower path in SLUB.   The SLUB
> > allocator is very fast for objects that gets recycled quickly (short
> > lifetime), non-locked (cpu-local) double-cmpxchg.  But slower for
> > longer-lived/more-outstanding objects, as this hits a slower code-path,
> > fully locked (cross-cpu) double-cmpxchg.  
> 
> Something like this ...  (compile tested only)
> 
> Considerably less code; Rao, what do you think?

I am sorry, but I am not at all fan of this approach.

If we are going to make this sort of change, we should do so in a way
that allows the slab code to actually do the optimizations that might
make this sort of thing worthwhile.  After all, if the main goal was small
code size, the best approach is to drop kfree_bulk() and get on with life
in the usual fashion.

I would prefer to believe that something like kfree_bulk() can help,
and if that is the case, we should give it a chance to do things like
group kfree_rcu() requests by destination slab and soforth, allowing
batching optimizations that might provide more significant increases
in performance.  Furthermore, having this in slab opens the door to
slab taking emergency action when memory is low.

But for the patch below, NAK.

Thanx, Paul

> diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
> index 59c471de342a..5ac4ed077233 100644
> --- a/kernel/rcu/rcu.h
> +++ b/kernel/rcu/rcu.h
> @@ -174,20 +174,19 @@ static inline void debug_rcu_head_unqueue(struct 
> rcu_head *head)
>  }
>  #endif   /* #else !CONFIG_DEBUG_OBJECTS_RCU_HEAD */
> 
> -void kfree(const void *);
> -
>  /*
>   * Reclaim the specified callback, either by invoking it (non-lazy case)
>   * or freeing it directly (lazy case).  Return true if lazy, false otherwise.
>   */
> -static inline bool __rcu_reclaim(const char *rn, struct rcu_head *head)
> +static inline bool __rcu_reclaim(const char *rn, struct rcu_head *head, void 
> **kfree,
> + unsigned int *idx)
>  {
>   unsigned long offset = (unsigned long)head->func;
> 
>   rcu_lock_acquire(_callback_map);
>   if (__is_kfree_rcu_offset(offset)) {
>   RCU_TRACE(trace_rcu_invoke_kfree_callback(rn, head, offset);)
> - kfree((void *)head - offset);
> + kfree[*idx++] = (void *)head - offset;
>   rcu_lock_release(_callback_map);
>   return true;
>   } else {
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index f9c0ca2ccf0c..7e13979b4697 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -2725,6 +2725,8 @@ static void rcu_do_batch(struct rcu_state *rsp, struct 
> rcu_data *rdp)
>   struct rcu_head *rhp;
>   struct rcu_cblist rcl = RCU_CBLIST_INITIALIZER(rcl);
>   long bl, count;
> + void *to_free[16];
> + unsigned int to_free_idx = 0;
> 
>   /* If no callbacks are ready, just return. */
>   if (!rcu_segcblist_ready_cbs(>cblist)) {
> @@ -2755,8 +2757,10 @@ static void rcu_do_batch(struct rcu_state *rsp, struct 
> rcu_data *rdp)
>   rhp = rcu_cblist_dequeue();
>   for (; rhp; rhp = rcu_cblist_dequeue()) {
>   debug_rcu_head_unqueue(rhp);
> - if (__rcu_reclaim(rsp->name, rhp))
> + if (__rcu_reclaim(rsp->name, rhp, to_free, _free_idx))
>   rcu_cblist_dequeued_lazy();
> + if (to_free_idx == 16)
> + kfree_bulk(16, to_free);
>   /*
>* Stop only if limit reached and CPU has something to do.
>* Note: The rcl structure counts down from zero.
> @@ -2766,6 +2770,8 @@ static void rcu_do_batch(struct rcu_state *rsp, struct 
> rcu_data *rdp)
>(!is_idle_task(current) && !rcu_is_callbacks_kthread(
>   break;
>   }
> + if (to_free_idx)
> + kfree_bulk(to_free_idx, to_free);
> 
>   local_irq_save(flags);
>   count = -rcl.len;
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index db85ca3975f1..4127be06759b 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -2189,6 +2189,8 @@ static int rcu_nocb_kthread(void *arg)
>   struct rcu_head 

Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures

[Paul E. McKenney]

On Tue, Dec 19, 2017 at 02:12:06PM -0800, Matthew Wilcox wrote:
> On Tue, Dec 19, 2017 at 09:41:58PM +0100, Jesper Dangaard Brouer wrote:
> > If I had to implement this: I would choose to do the optimization in
> > __rcu_process_callbacks() create small on-call-stack ptr-array for
> > kfree_bulk().  I would only optimize the case that call kfree()
> > directly.  In the while(list) loop I would defer calling
> > __rcu_reclaim() for __is_kfree_rcu_offset(head->func), and instead add
> > them to the ptr-array (and flush if the array is full in loop, and
> > kfree_bulk flush after loop).
> > 
> > The real advantage of kfree_bulk() comes from amortizing the per kfree
> > (behind-the-scenes) sync cost.  There is an additional benefit, because
> > objects comes from RCU and will hit a slower path in SLUB.   The SLUB
> > allocator is very fast for objects that gets recycled quickly (short
> > lifetime), non-locked (cpu-local) double-cmpxchg.  But slower for
> > longer-lived/more-outstanding objects, as this hits a slower code-path,
> > fully locked (cross-cpu) double-cmpxchg.  
> 
> Something like this ...  (compile tested only)
> 
> Considerably less code; Rao, what do you think?

I am sorry, but I am not at all fan of this approach.

If we are going to make this sort of change, we should do so in a way
that allows the slab code to actually do the optimizations that might
make this sort of thing worthwhile.  After all, if the main goal was small
code size, the best approach is to drop kfree_bulk() and get on with life
in the usual fashion.

I would prefer to believe that something like kfree_bulk() can help,
and if that is the case, we should give it a chance to do things like
group kfree_rcu() requests by destination slab and soforth, allowing
batching optimizations that might provide more significant increases
in performance.  Furthermore, having this in slab opens the door to
slab taking emergency action when memory is low.

But for the patch below, NAK.

Thanx, Paul

> diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
> index 59c471de342a..5ac4ed077233 100644
> --- a/kernel/rcu/rcu.h
> +++ b/kernel/rcu/rcu.h
> @@ -174,20 +174,19 @@ static inline void debug_rcu_head_unqueue(struct 
> rcu_head *head)
>  }
>  #endif   /* #else !CONFIG_DEBUG_OBJECTS_RCU_HEAD */
> 
> -void kfree(const void *);
> -
>  /*
>   * Reclaim the specified callback, either by invoking it (non-lazy case)
>   * or freeing it directly (lazy case).  Return true if lazy, false otherwise.
>   */
> -static inline bool __rcu_reclaim(const char *rn, struct rcu_head *head)
> +static inline bool __rcu_reclaim(const char *rn, struct rcu_head *head, void 
> **kfree,
> + unsigned int *idx)
>  {
>   unsigned long offset = (unsigned long)head->func;
> 
>   rcu_lock_acquire(_callback_map);
>   if (__is_kfree_rcu_offset(offset)) {
>   RCU_TRACE(trace_rcu_invoke_kfree_callback(rn, head, offset);)
> - kfree((void *)head - offset);
> + kfree[*idx++] = (void *)head - offset;
>   rcu_lock_release(_callback_map);
>   return true;
>   } else {
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index f9c0ca2ccf0c..7e13979b4697 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -2725,6 +2725,8 @@ static void rcu_do_batch(struct rcu_state *rsp, struct 
> rcu_data *rdp)
>   struct rcu_head *rhp;
>   struct rcu_cblist rcl = RCU_CBLIST_INITIALIZER(rcl);
>   long bl, count;
> + void *to_free[16];
> + unsigned int to_free_idx = 0;
> 
>   /* If no callbacks are ready, just return. */
>   if (!rcu_segcblist_ready_cbs(>cblist)) {
> @@ -2755,8 +2757,10 @@ static void rcu_do_batch(struct rcu_state *rsp, struct 
> rcu_data *rdp)
>   rhp = rcu_cblist_dequeue();
>   for (; rhp; rhp = rcu_cblist_dequeue()) {
>   debug_rcu_head_unqueue(rhp);
> - if (__rcu_reclaim(rsp->name, rhp))
> + if (__rcu_reclaim(rsp->name, rhp, to_free, _free_idx))
>   rcu_cblist_dequeued_lazy();
> + if (to_free_idx == 16)
> + kfree_bulk(16, to_free);
>   /*
>* Stop only if limit reached and CPU has something to do.
>* Note: The rcl structure counts down from zero.
> @@ -2766,6 +2770,8 @@ static void rcu_do_batch(struct rcu_state *rsp, struct 
> rcu_data *rdp)
>(!is_idle_task(current) && !rcu_is_callbacks_kthread(
>   break;
>   }
> + if (to_free_idx)
> + kfree_bulk(to_free_idx, to_free);
> 
>   local_irq_save(flags);
>   count = -rcl.len;
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index db85ca3975f1..4127be06759b 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -2189,6 +2189,8 @@ static int rcu_nocb_kthread(void *arg)
>   struct rcu_head 

Re: linux-next: build warning after merge of the btrfs-kdave tree

[Qu Wenruo]

On 2017年12月20日 06:20, Stephen Rothwell wrote:
> Hi David,
> 
> After merging the btrfs-kdave tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> fs/btrfs/qgroup.c: In function 'qgroup_reserve':
> fs/btrfs/qgroup.c:2432:1: warning: label 'retry' defined but not used 
> [-Wunused-label]
>  retry:
>  ^
> 
> Introduced by commit
> 
>   b283738ab0ad ("Revert "btrfs: qgroups: Retry after commit on getting 
> EDQUOT"")
> 
Sorry, I forgot to clean it up.

I'll update the patchset along with new patches to handle qgroup limit
better.

Thanks,
Qu



signature.asc
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the btrfs-kdave tree

[Qu Wenruo]

On 2017年12月20日 06:20, Stephen Rothwell wrote:
> Hi David,
> 
> After merging the btrfs-kdave tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> fs/btrfs/qgroup.c: In function 'qgroup_reserve':
> fs/btrfs/qgroup.c:2432:1: warning: label 'retry' defined but not used 
> [-Wunused-label]
>  retry:
>  ^
> 
> Introduced by commit
> 
>   b283738ab0ad ("Revert "btrfs: qgroups: Retry after commit on getting 
> EDQUOT"")
> 
Sorry, I forgot to clean it up.

I'll update the patchset along with new patches to handle qgroup limit
better.

Thanks,
Qu



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v9 7/7] intel_sgx: in-kernel launch enclave

[Jarkko Sakkinen]

On Tue, 2017-12-19 at 17:36 +0200, Andy Shevchenko wrote:
> On Tue, Dec 19, 2017 at 3:59 PM, Jarkko Sakkinen
>  wrote:
> 
> > I streamlined the IPC quite a bit. See the attached patch. Can be
> > applied on top of this patch.
> 
> Sorry, I didn't look into actual code, but WRT the attached patch,
> wouldn't be better / possible to use
> pr_fmt() to print "intel_sgx:" prefix for all pr_*() ?

Would make much sense. I can do this. In any case Ineed to update this
series at least once more for the copyright platters. Thanks for the
comment.

Now that the series does not add anything intrusive (namely pipe exports
or use a fragile AES implementation) I would propose to pull the current
series as a single platform driver and move relevant code under arch/x86
in subsequent series.

I've taken great of making sure that it would be doable to move code
later on when I first decided to make it as a plaform driver. My
thinking has been that encapsulating the codebase to a driver would be
the least intrusive way to mainline the first version of the SGX support
for the Linux kernel especially when there isn't publicly available HW
to test it yet with launch control that makes sense for Linux.

I can write a detailed description to the documentation how the 
implementation works in order to help to make the right decision for
subsequent series. 

/Jarkko

Re: [PATCH v9 7/7] intel_sgx: in-kernel launch enclave

[Jarkko Sakkinen]

On Tue, 2017-12-19 at 17:36 +0200, Andy Shevchenko wrote:
> On Tue, Dec 19, 2017 at 3:59 PM, Jarkko Sakkinen
>  wrote:
> 
> > I streamlined the IPC quite a bit. See the attached patch. Can be
> > applied on top of this patch.
> 
> Sorry, I didn't look into actual code, but WRT the attached patch,
> wouldn't be better / possible to use
> pr_fmt() to print "intel_sgx:" prefix for all pr_*() ?

Would make much sense. I can do this. In any case Ineed to update this
series at least once more for the copyright platters. Thanks for the
comment.

Now that the series does not add anything intrusive (namely pipe exports
or use a fragile AES implementation) I would propose to pull the current
series as a single platform driver and move relevant code under arch/x86
in subsequent series.

I've taken great of making sure that it would be doable to move code
later on when I first decided to make it as a plaform driver. My
thinking has been that encapsulating the codebase to a driver would be
the least intrusive way to mainline the first version of the SGX support
for the Linux kernel especially when there isn't publicly available HW
to test it yet with launch control that makes sense for Linux.

I can write a detailed description to the documentation how the 
implementation works in order to help to make the right decision for
subsequent series. 

/Jarkko

Re: [PATCH v5 01/18] PCI: dwc: Use the DMA-API to get the MSI address

[Niklas Cassel]

On Tue, Dec 19, 2017 at 12:45:30PM +, Gustavo Pimentel wrote:
> Tested-By: Gustavo Pimentel 
> 
> Using an arc board with USB and SATA end points with a root complex PCIe IP 
> core
> version 5.00, I ran the the following tests:
>  - I checked that all end points were listed correctly;
>  - I checked that no PCI related errors was present in dmesg;
>  - I copied a file from arc to the USB flash drive and checked the checksum;
>  - I copied a file from USB flash drive to the ARC and checked the checksum;
>  - I copied a file from arc to the SATA disk and checked the checksum;
>  - I copied a file from SATA disk to the arc and checked the checksum;
>  - I copied a file from USB flash drive to the SATA disk and checked the 
> checksum;
>  - I copied a file from SATA disk to the USB flash drive and checked the 
> checksum;
>  - I checked that no PCI related errors was present in dmesg;
> 
> Everything seemed normal to me.

Hello Gustavo,

Thanks a lot for testing.

FYI: I submitted a new patch set to address Lorenzo's review comments,
however, I do not think that we need to redo all the testing, since
now we are using the same GFP flags for MSI as we did before, which
obviously worked.

https://marc.info/?l=devicetree=151372652827788=2

Regards,
Niklas

Re: [PATCH v5 01/18] PCI: dwc: Use the DMA-API to get the MSI address

[Niklas Cassel]

On Tue, Dec 19, 2017 at 12:45:30PM +, Gustavo Pimentel wrote:
> Tested-By: Gustavo Pimentel 
> 
> Using an arc board with USB and SATA end points with a root complex PCIe IP 
> core
> version 5.00, I ran the the following tests:
>  - I checked that all end points were listed correctly;
>  - I checked that no PCI related errors was present in dmesg;
>  - I copied a file from arc to the USB flash drive and checked the checksum;
>  - I copied a file from USB flash drive to the ARC and checked the checksum;
>  - I copied a file from arc to the SATA disk and checked the checksum;
>  - I copied a file from SATA disk to the arc and checked the checksum;
>  - I copied a file from USB flash drive to the SATA disk and checked the 
> checksum;
>  - I copied a file from SATA disk to the USB flash drive and checked the 
> checksum;
>  - I checked that no PCI related errors was present in dmesg;
> 
> Everything seemed normal to me.

Hello Gustavo,

Thanks a lot for testing.

FYI: I submitted a new patch set to address Lorenzo's review comments,
however, I do not think that we need to redo all the testing, since
now we are using the same GFP flags for MSI as we did before, which
obviously worked.

https://marc.info/?l=devicetree=151372652827788=2

Regards,
Niklas

Re: [PATCH 2/2 v2] scsi: ufs: use sysfs entry for health info

[Bart Van Assche]

On Tue, 2017-12-19 at 14:46 -0800, Jaegeuk Kim wrote:
> Subject: [PATCH 2/2] scsi: ufs: introduce sysfs entries exposing UFS health
>  info
> 
> This patch adds a new sysfs group, namely health, via:
> 
>/sys/devices/soc/X.ufshc/health/

Thanks for the quick respin. This looks a lot better to me. I will leave
it to a UFS expert to do an in-depth review.

Bart.

Re: [PATCH 2/2 v2] scsi: ufs: use sysfs entry for health info

[Bart Van Assche]

On Tue, 2017-12-19 at 14:46 -0800, Jaegeuk Kim wrote:
> Subject: [PATCH 2/2] scsi: ufs: introduce sysfs entries exposing UFS health
>  info
> 
> This patch adds a new sysfs group, namely health, via:
> 
>/sys/devices/soc/X.ufshc/health/

Thanks for the quick respin. This looks a lot better to me. I will leave
it to a UFS expert to do an in-depth review.

Bart.

Re: [PATCH v2] IPI performance benchmark

[Andrew Morton]

On Tue, 19 Dec 2017 11:50:10 +0300 Yury Norov  wrote:

> This benchmark sends many IPIs in different modes and measures
> time for IPI delivery (first column), and total time, ie including
> time to acknowledge the receive by sender (second column).
> 
> The scenarios are:
> Dry-run:  do everything except actually sending IPI. Useful
>   to estimate system overhead.
> Self-IPI: Send IPI to self CPU.
> Normal IPI:   Send IPI to some other CPU.
> Broadcast IPI:Send broadcast IPI to all online CPUs.
> Broadcast lock:   Send broadcast IPI to all online CPUs and force them
> acquire/release spinlock.
> 
> The raw output looks like this:
> [  155.363374] Dry-run: 0,2999696 ns
> [  155.429162] Self-IPI: 30385328,   65589392 ns
> [  156.060821] Normal IPI:  566914128,  631453008 ns
> [  158.384427] Broadcast IPI:   0, 2323368720 ns
> [  160.831850] Broadcast lock:  0, 2447000544 ns
> 
> For virtualized guests, sending and reveiving IPIs causes guest exit.
> I used this test to measure performance impact on KVM subsystem of
> Christoffer Dall's series "Optimize KVM/ARM for VHE systems" [1].
> 
> Test machine is ThunderX2, 112 online CPUs. Below the results normalized
> to host dry-run time, broadcast lock results omitted. Smaller - better.
> 
> Host, v4.14:
> Dry-run:0 1
> Self-IPI: 9  18
> Normal IPI:  81 110
> Broadcast IPI:02106
> 
> Guest, v4.14:
> Dry-run:  0   1
> Self-IPI:10  18
> Normal IPI: 305 525
> Broadcast IPI:09729
> 
> Guest, v4.14 + [1]:
> Dry-run:  0   1
> Self-IPI: 9  18
> Normal IPI: 176 343
> Broadcast IPI:09885
> 

That looks handy.  Peter and Ingo might be interested.

I wonder if it should be in kernel/.  Perhaps it's better to accumulate
these things in lib/test_*.c, rather than cluttering up other top-level
directories.

> +static ktime_t __init send_ipi(int flags)
> +{
> + ktime_t time = 0;
> + DEFINE_SPINLOCK(lock);

I have some vague historical memory that an on-stack spinlock can cause
problems, perhaps with debugging code.  Can't remember, maybe I dreamed it.

Re: [PATCH v2] IPI performance benchmark

[Andrew Morton]

On Tue, 19 Dec 2017 11:50:10 +0300 Yury Norov  wrote:

> This benchmark sends many IPIs in different modes and measures
> time for IPI delivery (first column), and total time, ie including
> time to acknowledge the receive by sender (second column).
> 
> The scenarios are:
> Dry-run:  do everything except actually sending IPI. Useful
>   to estimate system overhead.
> Self-IPI: Send IPI to self CPU.
> Normal IPI:   Send IPI to some other CPU.
> Broadcast IPI:Send broadcast IPI to all online CPUs.
> Broadcast lock:   Send broadcast IPI to all online CPUs and force them
> acquire/release spinlock.
> 
> The raw output looks like this:
> [  155.363374] Dry-run: 0,2999696 ns
> [  155.429162] Self-IPI: 30385328,   65589392 ns
> [  156.060821] Normal IPI:  566914128,  631453008 ns
> [  158.384427] Broadcast IPI:   0, 2323368720 ns
> [  160.831850] Broadcast lock:  0, 2447000544 ns
> 
> For virtualized guests, sending and reveiving IPIs causes guest exit.
> I used this test to measure performance impact on KVM subsystem of
> Christoffer Dall's series "Optimize KVM/ARM for VHE systems" [1].
> 
> Test machine is ThunderX2, 112 online CPUs. Below the results normalized
> to host dry-run time, broadcast lock results omitted. Smaller - better.
> 
> Host, v4.14:
> Dry-run:0 1
> Self-IPI: 9  18
> Normal IPI:  81 110
> Broadcast IPI:02106
> 
> Guest, v4.14:
> Dry-run:  0   1
> Self-IPI:10  18
> Normal IPI: 305 525
> Broadcast IPI:09729
> 
> Guest, v4.14 + [1]:
> Dry-run:  0   1
> Self-IPI: 9  18
> Normal IPI: 176 343
> Broadcast IPI:09885
> 

That looks handy.  Peter and Ingo might be interested.

I wonder if it should be in kernel/.  Perhaps it's better to accumulate
these things in lib/test_*.c, rather than cluttering up other top-level
directories.

> +static ktime_t __init send_ipi(int flags)
> +{
> + ktime_t time = 0;
> + DEFINE_SPINLOCK(lock);

I have some vague historical memory that an on-stack spinlock can cause
problems, perhaps with debugging code.  Can't remember, maybe I dreamed it.

Urgent Message.

[James Udo]

Dear Friend,

I am Mr. James Udo, a computer scientist with UBA Bank. I am 29 years old, just 
started work with UBA Bank. I came across your (B) file which was marked X and 
your released D disk painted RED, I took time to study it and found out that 
you have paid VIRTUALLY all fees and certificate but the fund has not been 
release to you. The most annoying thing is that they cannot tell you the truth 
that on no account will they ever release the fund to you. Please this is like 
a Mafia setting in Benin Republic/ Burkina Faso and Nigeria; you may not 
understand it because you are not from this country. The only thing I will need 
to release this fund to you is a special HARD DISK. I will buy two of it, 
recopy your information, destroy the previous one, and punch the computer to 
reflect in your bank within 24 banking hours. I will clean up 
the tracer and destroy your file, after which I will quit the UBA bank i don't 
want to work with them again. Some mafias in the bank are behind the non 
release of your money that's why i managed to sneak out this information for 
your kind perusal.If you are interested do get in touch with me immediately, 
you should send to me you phone numbers for easy communications and also re 
confirm your banking details, so 
that there won't be any mistake. 

Regards,
James.

Urgent Message.

[James Udo]

Dear Friend,

I am Mr. James Udo, a computer scientist with UBA Bank. I am 29 years old, just 
started work with UBA Bank. I came across your (B) file which was marked X and 
your released D disk painted RED, I took time to study it and found out that 
you have paid VIRTUALLY all fees and certificate but the fund has not been 
release to you. The most annoying thing is that they cannot tell you the truth 
that on no account will they ever release the fund to you. Please this is like 
a Mafia setting in Benin Republic/ Burkina Faso and Nigeria; you may not 
understand it because you are not from this country. The only thing I will need 
to release this fund to you is a special HARD DISK. I will buy two of it, 
recopy your information, destroy the previous one, and punch the computer to 
reflect in your bank within 24 banking hours. I will clean up 
the tracer and destroy your file, after which I will quit the UBA bank i don't 
want to work with them again. Some mafias in the bank are behind the non 
release of your money that's why i managed to sneak out this information for 
your kind perusal.If you are interested do get in touch with me immediately, 
you should send to me you phone numbers for easy communications and also re 
confirm your banking details, so 
that there won't be any mistake. 

Regards,
James.

Re: [PATCH] tools/power: Don't make man pages executable

[Rafael J. Wysocki]

On 12/19/2017 8:54 PM, Laura Abbott wrote:

rpm-lint flagged these as being executable:

kernel-tools.x86_64: W: spurious-executable-perm 
/usr/share/man/man8/turbostat.8.gz
kernel-tools.x86_64: W: spurious-executable-perm 
/usr/share/man/man8/x86_energy_perf_policy.8.gz

Fix this

Signed-off-by: Laura Abbott 


Please CC PM stuff to linux-pm (which makes it easier to handle).


---
  tools/power/x86/turbostat/Makefile  | 2 +-
  tools/power/x86/x86_energy_perf_policy/Makefile | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/power/x86/turbostat/Makefile 
b/tools/power/x86/turbostat/Makefile
index a9bc914a8fe8..2ab25aa38263 100644
--- a/tools/power/x86/turbostat/Makefile
+++ b/tools/power/x86/turbostat/Makefile
@@ -25,4 +25,4 @@ install : turbostat
install -d  $(DESTDIR)$(PREFIX)/bin
install $(BUILD_OUTPUT)/turbostat $(DESTDIR)$(PREFIX)/bin/turbostat
install -d  $(DESTDIR)$(PREFIX)/share/man/man8
-   install turbostat.8 $(DESTDIR)$(PREFIX)/share/man/man8
+   install -m 644 turbostat.8 $(DESTDIR)$(PREFIX)/share/man/man8
diff --git a/tools/power/x86/x86_energy_perf_policy/Makefile 
b/tools/power/x86/x86_energy_perf_policy/Makefile
index 2447b1bbaacf..f4534fb8b951 100644
--- a/tools/power/x86/x86_energy_perf_policy/Makefile
+++ b/tools/power/x86/x86_energy_perf_policy/Makefile
@@ -24,5 +24,5 @@ install : x86_energy_perf_policy
install -d  $(DESTDIR)$(PREFIX)/bin
install $(BUILD_OUTPUT)/x86_energy_perf_policy 
$(DESTDIR)$(PREFIX)/bin/x86_energy_perf_policy
install -d  $(DESTDIR)$(PREFIX)/share/man/man8
-   install x86_energy_perf_policy.8 $(DESTDIR)$(PREFIX)/share/man/man8
+   install -m 644 x86_energy_perf_policy.8 
$(DESTDIR)$(PREFIX)/share/man/man8
  



Thanks,

Rafael

Re: [PATCH] tools/power: Don't make man pages executable

[Rafael J. Wysocki]

On 12/19/2017 8:54 PM, Laura Abbott wrote:

rpm-lint flagged these as being executable:

kernel-tools.x86_64: W: spurious-executable-perm 
/usr/share/man/man8/turbostat.8.gz
kernel-tools.x86_64: W: spurious-executable-perm 
/usr/share/man/man8/x86_energy_perf_policy.8.gz

Fix this

Signed-off-by: Laura Abbott 


Please CC PM stuff to linux-pm (which makes it easier to handle).


---
  tools/power/x86/turbostat/Makefile  | 2 +-
  tools/power/x86/x86_energy_perf_policy/Makefile | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/power/x86/turbostat/Makefile 
b/tools/power/x86/turbostat/Makefile
index a9bc914a8fe8..2ab25aa38263 100644
--- a/tools/power/x86/turbostat/Makefile
+++ b/tools/power/x86/turbostat/Makefile
@@ -25,4 +25,4 @@ install : turbostat
install -d  $(DESTDIR)$(PREFIX)/bin
install $(BUILD_OUTPUT)/turbostat $(DESTDIR)$(PREFIX)/bin/turbostat
install -d  $(DESTDIR)$(PREFIX)/share/man/man8
-   install turbostat.8 $(DESTDIR)$(PREFIX)/share/man/man8
+   install -m 644 turbostat.8 $(DESTDIR)$(PREFIX)/share/man/man8
diff --git a/tools/power/x86/x86_energy_perf_policy/Makefile 
b/tools/power/x86/x86_energy_perf_policy/Makefile
index 2447b1bbaacf..f4534fb8b951 100644
--- a/tools/power/x86/x86_energy_perf_policy/Makefile
+++ b/tools/power/x86/x86_energy_perf_policy/Makefile
@@ -24,5 +24,5 @@ install : x86_energy_perf_policy
install -d  $(DESTDIR)$(PREFIX)/bin
install $(BUILD_OUTPUT)/x86_energy_perf_policy 
$(DESTDIR)$(PREFIX)/bin/x86_energy_perf_policy
install -d  $(DESTDIR)$(PREFIX)/share/man/man8
-   install x86_energy_perf_policy.8 $(DESTDIR)$(PREFIX)/share/man/man8
+   install -m 644 x86_energy_perf_policy.8 
$(DESTDIR)$(PREFIX)/share/man/man8
  



Thanks,

Rafael

Re: [PATCH] dt-bindings: display: panel: Fix compatible string for Toshiba LT089AC29000

[Rob Herring]

On Sun, Dec 17, 2017 at 03:34:33AM +0100, Jonathan Neuschäfer wrote:
> The compatible string for this panel was specified as
> toshiba,lt089ac29000.txt. I believe this is a mistake.
> 
> Fixes: 06e733e41f87 ("drm/panel: simple: add Toshiba LT089AC19000")
> Cc: Lucas Stach 
> Signed-off-by: Jonathan Neuschäfer 
> ---
>  .../devicetree/bindings/display/panel/toshiba,lt089ac29000.txt  | 2 
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied.

Rob

Re: [PATCH] dt-bindings: display: panel: Fix compatible string for Toshiba LT089AC29000

[Rob Herring]

On Sun, Dec 17, 2017 at 03:34:33AM +0100, Jonathan Neuschäfer wrote:
> The compatible string for this panel was specified as
> toshiba,lt089ac29000.txt. I believe this is a mistake.
> 
> Fixes: 06e733e41f87 ("drm/panel: simple: add Toshiba LT089AC19000")
> Cc: Lucas Stach 
> Signed-off-by: Jonathan Neuschäfer 
> ---
>  .../devicetree/bindings/display/panel/toshiba,lt089ac29000.txt  | 2 
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied.

Rob