[PATCH net-next] tun: fix build warnings

[Jason Wang]

Stephen Rothwell reports a build warnings(powerpc ppc64_defconfig)

drivers/net/tun.c: In function 'tun_do_read.part.5':
/home/sfr/next/next/drivers/net/tun.c:1491:6: warning: 'err' may be
used uninitialized in this function [-Wmaybe-uninitialized]
   int err;

This is because tun_ring_recv() may return an uninitialized err, fix this.

Reported-by: Stephen Rothwell 
Signed-off-by: Jason Wang 
---
 drivers/net/tun.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 7475215..5eadb7a 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1447,12 +1447,13 @@ static struct sk_buff *tun_ring_recv(struct tun_file 
*tfile, int noblock,
 {
DECLARE_WAITQUEUE(wait, current);
struct sk_buff *skb = NULL;
+   int error = 0;
 
skb = skb_array_consume(>tx_array);
if (skb)
goto out;
if (noblock) {
-   *err = -EAGAIN;
+   error = -EAGAIN;
goto out;
}
 
@@ -1464,11 +1465,11 @@ static struct sk_buff *tun_ring_recv(struct tun_file 
*tfile, int noblock,
if (skb)
break;
if (signal_pending(current)) {
-   *err = -ERESTARTSYS;
+   error = -ERESTARTSYS;
break;
}
if (tfile->socket.sk->sk_shutdown & RCV_SHUTDOWN) {
-   *err = -EFAULT;
+   error = -EFAULT;
break;
}
 
@@ -1479,6 +1480,7 @@ static struct sk_buff *tun_ring_recv(struct tun_file 
*tfile, int noblock,
remove_wait_queue(>wq.wait, );
 
 out:
+   *err = error;
return skb;
 }
 
-- 
2.7.4

[PATCH net-next] tun: fix build warnings

[Jason Wang]

Stephen Rothwell reports a build warnings(powerpc ppc64_defconfig)

drivers/net/tun.c: In function 'tun_do_read.part.5':
/home/sfr/next/next/drivers/net/tun.c:1491:6: warning: 'err' may be
used uninitialized in this function [-Wmaybe-uninitialized]
   int err;

This is because tun_ring_recv() may return an uninitialized err, fix this.

Reported-by: Stephen Rothwell 
Signed-off-by: Jason Wang 
---
 drivers/net/tun.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 7475215..5eadb7a 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1447,12 +1447,13 @@ static struct sk_buff *tun_ring_recv(struct tun_file 
*tfile, int noblock,
 {
DECLARE_WAITQUEUE(wait, current);
struct sk_buff *skb = NULL;
+   int error = 0;
 
skb = skb_array_consume(>tx_array);
if (skb)
goto out;
if (noblock) {
-   *err = -EAGAIN;
+   error = -EAGAIN;
goto out;
}
 
@@ -1464,11 +1465,11 @@ static struct sk_buff *tun_ring_recv(struct tun_file 
*tfile, int noblock,
if (skb)
break;
if (signal_pending(current)) {
-   *err = -ERESTARTSYS;
+   error = -ERESTARTSYS;
break;
}
if (tfile->socket.sk->sk_shutdown & RCV_SHUTDOWN) {
-   *err = -EFAULT;
+   error = -EFAULT;
break;
}
 
@@ -1479,6 +1480,7 @@ static struct sk_buff *tun_ring_recv(struct tun_file 
*tfile, int noblock,
remove_wait_queue(>wq.wait, );
 
 out:
+   *err = error;
return skb;
 }
 
-- 
2.7.4

Re: [PATCH v3 2/3] bcache: update document info

[Coly Li]

在 16/7/4 上午9:23, Yijing Wang 写道:
> There is no return in continue_at(), update the documentation.
> 

Thanks.

Acked-by: Coly Li 

> Signed-off-by: Yijing Wang 
> ---
>  drivers/md/bcache/closure.c |2 +-
>  drivers/md/bcache/closure.h |3 ++-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/md/bcache/closure.c b/drivers/md/bcache/closure.c
> index 9eaf1d6..864e673 100644
> --- a/drivers/md/bcache/closure.c
> +++ b/drivers/md/bcache/closure.c
> @@ -112,7 +112,7 @@ bool closure_wait(struct closure_waitlist *waitlist, 
> struct closure *cl)
>  EXPORT_SYMBOL(closure_wait);
>  
>  /**
> - * closure_sync - sleep until a closure a closure has nothing left to wait on
> + * closure_sync - sleep until a closure has nothing left to wait on
>   *
>   * Sleeps until the refcount hits 1 - the thread that's running the closure 
> owns
>   * the last refcount.
> diff --git a/drivers/md/bcache/closure.h b/drivers/md/bcache/closure.h
> index 782cc2c..9b2fe2d 100644
> --- a/drivers/md/bcache/closure.h
> +++ b/drivers/md/bcache/closure.h
> @@ -31,7 +31,8 @@
>   * passing it, as you might expect, the function to run when nothing is 
> pending
>   * and the workqueue to run that function out of.
>   *
> - * continue_at() also, critically, is a macro that returns the calling 
> function.
> + * continue_at() also, critically, requires a 'return' immediately following 
> the
> + * location where this macro is referenced, to return to the calling 
> function.
>   * There's good reason for this.
>   *
>   * To use safely closures asynchronously, they must always have a refcount 
> while
> 


-- 
Coly Li

Re: [PATCH v3 2/3] bcache: update document info

[Coly Li]

在 16/7/4 上午9:23, Yijing Wang 写道:
> There is no return in continue_at(), update the documentation.
> 

Thanks.

Acked-by: Coly Li 

> Signed-off-by: Yijing Wang 
> ---
>  drivers/md/bcache/closure.c |2 +-
>  drivers/md/bcache/closure.h |3 ++-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/md/bcache/closure.c b/drivers/md/bcache/closure.c
> index 9eaf1d6..864e673 100644
> --- a/drivers/md/bcache/closure.c
> +++ b/drivers/md/bcache/closure.c
> @@ -112,7 +112,7 @@ bool closure_wait(struct closure_waitlist *waitlist, 
> struct closure *cl)
>  EXPORT_SYMBOL(closure_wait);
>  
>  /**
> - * closure_sync - sleep until a closure a closure has nothing left to wait on
> + * closure_sync - sleep until a closure has nothing left to wait on
>   *
>   * Sleeps until the refcount hits 1 - the thread that's running the closure 
> owns
>   * the last refcount.
> diff --git a/drivers/md/bcache/closure.h b/drivers/md/bcache/closure.h
> index 782cc2c..9b2fe2d 100644
> --- a/drivers/md/bcache/closure.h
> +++ b/drivers/md/bcache/closure.h
> @@ -31,7 +31,8 @@
>   * passing it, as you might expect, the function to run when nothing is 
> pending
>   * and the workqueue to run that function out of.
>   *
> - * continue_at() also, critically, is a macro that returns the calling 
> function.
> + * continue_at() also, critically, requires a 'return' immediately following 
> the
> + * location where this macro is referenced, to return to the calling 
> function.
>   * There's good reason for this.
>   *
>   * To use safely closures asynchronously, they must always have a refcount 
> while
> 


-- 
Coly Li

linux-next: manual merge of the kvm tree with the kspp tree

[Stephen Rothwell]

Hi all,

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

  arch/x86/kvm/vmx.c

between commit:

  255303026193 ("x86: apply more __ro_after_init and const")

from the kspp tree and commit:

  c45dcc71b794 ("KVM: VMX: enable guest access to LMCE related MSRs")

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/vmx.c
index 9faec9dc5476,85e2f0a882ca..
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@@ -10905,7 -11123,17 +11127,17 @@@ out
return ret;
  }
  
+ static void vmx_setup_mce(struct kvm_vcpu *vcpu)
+ {
+   if (vcpu->arch.mcg_cap & MCG_LMCE_P)
+   to_vmx(vcpu)->msr_ia32_feature_control_valid_bits |=
+   FEATURE_CONTROL_LMCE;
+   else
+   to_vmx(vcpu)->msr_ia32_feature_control_valid_bits &=
+   ~FEATURE_CONTROL_LMCE;
+ }
+ 
 -static struct kvm_x86_ops vmx_x86_ops = {
 +static struct kvm_x86_ops vmx_x86_ops __ro_after_init = {
.cpu_has_kvm_support = cpu_has_kvm_support,
.disabled_by_bios = vmx_disabled_by_bios,
.hardware_setup = hardware_setup,

Re: [PATCH] netfilter: nf_conntrack_sip: CSeq 0 is a valid CSeq

[Liping Zhang]

2016-07-01 17:48 GMT+08:00 Christophe Leroy :
> Do not drop packet when CSeq is 0 as 0 is also a valid value for CSeq.
>
> --- a/net/netfilter/nf_conntrack_sip.c
> +++ b/net/netfilter/nf_conntrack_sip.c
> @@ -1368,6 +1368,7 @@ static int process_sip_response(struct sk_buff *skb, 
> unsigned int protoff,
> struct nf_conn *ct = nf_ct_get(skb, );
> unsigned int matchoff, matchlen, matchend;
> unsigned int code, cseq, i;
> +   char buf[21];
>
> if (*datalen < strlen("SIP/2.0 200"))
> return NF_ACCEPT;
> @@ -1382,8 +1383,13 @@ static int process_sip_response(struct sk_buff *skb, 
> unsigned int protoff,
> nf_ct_helper_log(skb, ct, "cannot parse cseq");
> return NF_DROP;
> }
> -   cseq = simple_strtoul(*dptr + matchoff, NULL, 10);
> -   if (!cseq) {

I think there is no need to convert simple_strtoul to kstrtouint, add
a further check seems better?
Like this:
 -   if (!cseq) {
+   if (!cseq && *(*dptr + matchoff) != '0') {

> +   if (matchlen > sizeof(buf) - 1) {
> +   nf_ct_helper_log(skb, ct, "cannot parse cseq (too big)");
> +   return NF_DROP;
> +   }
> +   memcpy(buf, *dptr + matchoff, matchlen);
> +   buf[matchlen] = 0;
> +   if (kstrtouint(buf, 10, )) {
> nf_ct_helper_log(skb, ct, "cannot get cseq");
> return NF_DROP;
> }

linux-next: manual merge of the kvm tree with the kspp tree

[Stephen Rothwell]

Hi all,

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

  arch/x86/kvm/vmx.c

between commit:

  255303026193 ("x86: apply more __ro_after_init and const")

from the kspp tree and commit:

  c45dcc71b794 ("KVM: VMX: enable guest access to LMCE related MSRs")

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/vmx.c
index 9faec9dc5476,85e2f0a882ca..
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@@ -10905,7 -11123,17 +11127,17 @@@ out
return ret;
  }
  
+ static void vmx_setup_mce(struct kvm_vcpu *vcpu)
+ {
+   if (vcpu->arch.mcg_cap & MCG_LMCE_P)
+   to_vmx(vcpu)->msr_ia32_feature_control_valid_bits |=
+   FEATURE_CONTROL_LMCE;
+   else
+   to_vmx(vcpu)->msr_ia32_feature_control_valid_bits &=
+   ~FEATURE_CONTROL_LMCE;
+ }
+ 
 -static struct kvm_x86_ops vmx_x86_ops = {
 +static struct kvm_x86_ops vmx_x86_ops __ro_after_init = {
.cpu_has_kvm_support = cpu_has_kvm_support,
.disabled_by_bios = vmx_disabled_by_bios,
.hardware_setup = hardware_setup,

Re: [PATCH] netfilter: nf_conntrack_sip: CSeq 0 is a valid CSeq

[Liping Zhang]

2016-07-01 17:48 GMT+08:00 Christophe Leroy :
> Do not drop packet when CSeq is 0 as 0 is also a valid value for CSeq.
>
> --- a/net/netfilter/nf_conntrack_sip.c
> +++ b/net/netfilter/nf_conntrack_sip.c
> @@ -1368,6 +1368,7 @@ static int process_sip_response(struct sk_buff *skb, 
> unsigned int protoff,
> struct nf_conn *ct = nf_ct_get(skb, );
> unsigned int matchoff, matchlen, matchend;
> unsigned int code, cseq, i;
> +   char buf[21];
>
> if (*datalen < strlen("SIP/2.0 200"))
> return NF_ACCEPT;
> @@ -1382,8 +1383,13 @@ static int process_sip_response(struct sk_buff *skb, 
> unsigned int protoff,
> nf_ct_helper_log(skb, ct, "cannot parse cseq");
> return NF_DROP;
> }
> -   cseq = simple_strtoul(*dptr + matchoff, NULL, 10);
> -   if (!cseq) {

I think there is no need to convert simple_strtoul to kstrtouint, add
a further check seems better?
Like this:
 -   if (!cseq) {
+   if (!cseq && *(*dptr + matchoff) != '0') {

> +   if (matchlen > sizeof(buf) - 1) {
> +   nf_ct_helper_log(skb, ct, "cannot parse cseq (too big)");
> +   return NF_DROP;
> +   }
> +   memcpy(buf, *dptr + matchoff, matchlen);
> +   buf[matchlen] = 0;
> +   if (kstrtouint(buf, 10, )) {
> nf_ct_helper_log(skb, ct, "cannot get cseq");
> return NF_DROP;
> }

[PATCH] fsl/fman: fix error handling

[Christophe JAILLET]

This is likely that checking 'fman->fifo_offset' instead of
'fman->cam_offset' is expected here.

Signed-off-by: Christophe JAILLET 

---

The type of 'fifo_offset' may also need to be changed.
---
 drivers/net/ethernet/freescale/fman/fman.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/fman/fman.c 
b/drivers/net/ethernet/freescale/fman/fman.c
index 1de2e1e..f634e769 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -2036,7 +2036,7 @@ static int fman_init(struct fman *fman)
/* allocate MURAM for FIFO according to total size */
fman->fifo_offset = fman_muram_alloc(fman->muram,
 fman->state->total_fifo_size);
-   if (IS_ERR_VALUE(fman->cam_offset)) {
+   if (IS_ERR_VALUE(fman->fifo_offset)) {
free_init_resources(fman);
dev_err(fman->dev, "%s: MURAM alloc for BMI FIFO failed\n",
__func__);
-- 
2.7.4

Re: [PATCH 3/3] mm/page_owner: track page free call chain

[Sergey Senozhatsky]

On (07/04/16 14:29), Joonsoo Kim wrote:
> > > On Sun, Jul 03, 2016 at 01:16:56AM +0900, Sergey Senozhatsky wrote:
> > > > Introduce PAGE_OWNER_TRACK_FREE config option to extend page owner with
> > > > free_pages() tracking functionality. This adds to the dump_page_owner()
> > > > output an additional backtrace, that tells us what path has freed the
> > > > page.
> > > 
> > > Hmm... Do you have other ideas to use this feature? Following example is
> > > just to detect use-after-free and we have other good tools for it
> > > (KASAN or DEBUG_PAGEALLOC) so I'm not sure whether it's useful or not.
> > 
> > there is no kasan for ARM32, for example (apart from the fact that
> > it's really hard to use kasan sometimes due to its cpu cycles and
> > memory requirements).
> 
> Hmm... for debugging purpose, KASAN provides many more things so IMO it's
> better to implement/support KASAN in ARM32 rather than expand
> PAGE_OWNER for free.
> 

hm, the last time I checked kasan didn't catch that extra put_page() on
x86_64. AFAIK, kasan on ARM32 is a bit hard to do properly
http://www.serverphorums.com/read.php?12,1206479,1281087#msg-1281087

I've played with kasan on arm32 (an internal custom version)... and
extended page_owner turned out to be *incomparably* easier and faster
to use (especially paired with stackdepot).

> > educate me, will DEBUG_PAGEALLOC tell us what path has triggered the
> > extra put_page()? hm... does ARM32 provide ARCH_SUPPORTS_DEBUG_PAGEALLOC?
> 
> Hmm... Now, I notice that PAGE_OWNER_TRACK_FREE will detect
> double-free rather than use-after-free.

well, yes. current hits bad_page(), page_owner helps to find out who
stole and spoiled it from under current.

CPU a   CPU b

alloc_page()
put_page() << legitimate
alloc_page()
err:
put_page() << legitimate, again.
   << but is actually buggy.

put_page() << double 
free. but we need
   << to report 
put_page() from
   << CPU a.

-ss

> DEBUG_PAGEALLOC doesn't catch double-free but it can be implemented
> easily. In this case, we can show call path for second free.
> 
> AFAIK, ARM32 doesn't support ARCH_SUPPORTS_DEBUG_PAGEALLOC.
> 
> Thanks.
> 

[PATCH] fsl/fman: fix error handling

[Christophe JAILLET]

This is likely that checking 'fman->fifo_offset' instead of
'fman->cam_offset' is expected here.

Signed-off-by: Christophe JAILLET 

---

The type of 'fifo_offset' may also need to be changed.
---
 drivers/net/ethernet/freescale/fman/fman.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/fman/fman.c 
b/drivers/net/ethernet/freescale/fman/fman.c
index 1de2e1e..f634e769 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -2036,7 +2036,7 @@ static int fman_init(struct fman *fman)
/* allocate MURAM for FIFO according to total size */
fman->fifo_offset = fman_muram_alloc(fman->muram,
 fman->state->total_fifo_size);
-   if (IS_ERR_VALUE(fman->cam_offset)) {
+   if (IS_ERR_VALUE(fman->fifo_offset)) {
free_init_resources(fman);
dev_err(fman->dev, "%s: MURAM alloc for BMI FIFO failed\n",
__func__);
-- 
2.7.4

Re: [PATCH 3/3] mm/page_owner: track page free call chain

[Sergey Senozhatsky]

On (07/04/16 14:29), Joonsoo Kim wrote:
> > > On Sun, Jul 03, 2016 at 01:16:56AM +0900, Sergey Senozhatsky wrote:
> > > > Introduce PAGE_OWNER_TRACK_FREE config option to extend page owner with
> > > > free_pages() tracking functionality. This adds to the dump_page_owner()
> > > > output an additional backtrace, that tells us what path has freed the
> > > > page.
> > > 
> > > Hmm... Do you have other ideas to use this feature? Following example is
> > > just to detect use-after-free and we have other good tools for it
> > > (KASAN or DEBUG_PAGEALLOC) so I'm not sure whether it's useful or not.
> > 
> > there is no kasan for ARM32, for example (apart from the fact that
> > it's really hard to use kasan sometimes due to its cpu cycles and
> > memory requirements).
> 
> Hmm... for debugging purpose, KASAN provides many more things so IMO it's
> better to implement/support KASAN in ARM32 rather than expand
> PAGE_OWNER for free.
> 

hm, the last time I checked kasan didn't catch that extra put_page() on
x86_64. AFAIK, kasan on ARM32 is a bit hard to do properly
http://www.serverphorums.com/read.php?12,1206479,1281087#msg-1281087

I've played with kasan on arm32 (an internal custom version)... and
extended page_owner turned out to be *incomparably* easier and faster
to use (especially paired with stackdepot).

> > educate me, will DEBUG_PAGEALLOC tell us what path has triggered the
> > extra put_page()? hm... does ARM32 provide ARCH_SUPPORTS_DEBUG_PAGEALLOC?
> 
> Hmm... Now, I notice that PAGE_OWNER_TRACK_FREE will detect
> double-free rather than use-after-free.

well, yes. current hits bad_page(), page_owner helps to find out who
stole and spoiled it from under current.

CPU a   CPU b

alloc_page()
put_page() << legitimate
alloc_page()
err:
put_page() << legitimate, again.
   << but is actually buggy.

put_page() << double 
free. but we need
   << to report 
put_page() from
   << CPU a.

-ss

> DEBUG_PAGEALLOC doesn't catch double-free but it can be implemented
> easily. In this case, we can show call path for second free.
> 
> AFAIK, ARM32 doesn't support ARCH_SUPPORTS_DEBUG_PAGEALLOC.
> 
> Thanks.
> 

linux-next: build warnings after merge of the ftrace tree

[Stephen Rothwell]

Hi Steven,

After merging the ftrace tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:

WARNING: kernel/trace/libftrace.o(.text+0x9569): Section mismatch in reference 
from the function ftrace_init_tracefs() to the variable 
.init.data:function_stats
The function ftrace_init_tracefs() references
the variable __initdata function_stats.
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of function_stats is wrong.

WARNING: kernel/trace/libftrace.o(.text+0x9577): Section mismatch in reference 
from the function ftrace_init_tracefs() to the variable 
.init.data:function_stats
The function ftrace_init_tracefs() references
the variable __initdata function_stats.
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of function_stats is wrong.

WARNING: kernel/trace/libftrace.o(.text+0x9582): Section mismatch in reference 
from the function ftrace_init_tracefs() to the variable 
.init.data:function_stats
The function ftrace_init_tracefs() references
the variable __initdata function_stats.
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of function_stats is wrong.

WARNING: kernel/trace/libftrace.o(.text+0x958d): Section mismatch in reference 
from the function ftrace_init_tracefs() to the (unknown reference) 
.init.data:(unknown)
The function ftrace_init_tracefs() references
the (unknown reference) __initdata (unknown).
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: kernel/trace/libftrace.o(.text+0x9598): Section mismatch in reference 
from the function ftrace_init_tracefs() to the (unknown reference) 
.init.data:(unknown)
The function ftrace_init_tracefs() references
the (unknown reference) __initdata (unknown).
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: kernel/trace/libftrace.o(.text+0x95a3): Section mismatch in reference 
from the function ftrace_init_tracefs() to the (unknown reference) 
.init.data:(unknown)
The function ftrace_init_tracefs() references
the (unknown reference) __initdata (unknown).
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: kernel/trace/libftrace.o(.text+0x95ae): Section mismatch in reference 
from the function ftrace_init_tracefs() to the variable 
.init.data:ftrace_filter_param
The function ftrace_init_tracefs() references
the variable __initdata ftrace_filter_param.
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of ftrace_filter_param is wrong.

WARNING: kernel/trace/built-in.o(.text+0x9789): Section mismatch in reference 
from the function ftrace_init_tracefs() to the variable 
.init.data:function_stats
The function ftrace_init_tracefs() references
the variable __initdata function_stats.
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of function_stats is wrong.

WARNING: kernel/trace/built-in.o(.text+0x9797): Section mismatch in reference 
from the function ftrace_init_tracefs() to the variable 
.init.data:function_stats
The function ftrace_init_tracefs() references
the variable __initdata function_stats.
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of function_stats is wrong.

WARNING: kernel/trace/built-in.o(.text+0x97a2): Section mismatch in reference 
from the function ftrace_init_tracefs() to the variable 
.init.data:function_stats
The function ftrace_init_tracefs() references
the variable __initdata function_stats.
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of function_stats is wrong.

WARNING: kernel/trace/built-in.o(.text+0x97ad): Section mismatch in reference 
from the function ftrace_init_tracefs() to the (unknown reference) 
.init.data:(unknown)
The function ftrace_init_tracefs() references
the (unknown reference) __initdata (unknown).
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: kernel/trace/built-in.o(.text+0x97b8): Section mismatch in reference 
from the function ftrace_init_tracefs() to the (unknown reference) 
.init.data:(unknown)
The function ftrace_init_tracefs() references
the (unknown reference) __initdata (unknown).
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: kernel/trace/built-in.o(.text+0x97c3): Section mismatch in reference 
from the function ftrace_init_tracefs() to the (unknown reference) 
.init.data:(unknown)
The function ftrace_init_tracefs() references
the (unknown reference) __initdata (unknown).
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: 

linux-next: build warnings after merge of the ftrace tree

[Stephen Rothwell]

Hi Steven,

After merging the ftrace tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:

WARNING: kernel/trace/libftrace.o(.text+0x9569): Section mismatch in reference 
from the function ftrace_init_tracefs() to the variable 
.init.data:function_stats
The function ftrace_init_tracefs() references
the variable __initdata function_stats.
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of function_stats is wrong.

WARNING: kernel/trace/libftrace.o(.text+0x9577): Section mismatch in reference 
from the function ftrace_init_tracefs() to the variable 
.init.data:function_stats
The function ftrace_init_tracefs() references
the variable __initdata function_stats.
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of function_stats is wrong.

WARNING: kernel/trace/libftrace.o(.text+0x9582): Section mismatch in reference 
from the function ftrace_init_tracefs() to the variable 
.init.data:function_stats
The function ftrace_init_tracefs() references
the variable __initdata function_stats.
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of function_stats is wrong.

WARNING: kernel/trace/libftrace.o(.text+0x958d): Section mismatch in reference 
from the function ftrace_init_tracefs() to the (unknown reference) 
.init.data:(unknown)
The function ftrace_init_tracefs() references
the (unknown reference) __initdata (unknown).
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: kernel/trace/libftrace.o(.text+0x9598): Section mismatch in reference 
from the function ftrace_init_tracefs() to the (unknown reference) 
.init.data:(unknown)
The function ftrace_init_tracefs() references
the (unknown reference) __initdata (unknown).
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: kernel/trace/libftrace.o(.text+0x95a3): Section mismatch in reference 
from the function ftrace_init_tracefs() to the (unknown reference) 
.init.data:(unknown)
The function ftrace_init_tracefs() references
the (unknown reference) __initdata (unknown).
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: kernel/trace/libftrace.o(.text+0x95ae): Section mismatch in reference 
from the function ftrace_init_tracefs() to the variable 
.init.data:ftrace_filter_param
The function ftrace_init_tracefs() references
the variable __initdata ftrace_filter_param.
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of ftrace_filter_param is wrong.

WARNING: kernel/trace/built-in.o(.text+0x9789): Section mismatch in reference 
from the function ftrace_init_tracefs() to the variable 
.init.data:function_stats
The function ftrace_init_tracefs() references
the variable __initdata function_stats.
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of function_stats is wrong.

WARNING: kernel/trace/built-in.o(.text+0x9797): Section mismatch in reference 
from the function ftrace_init_tracefs() to the variable 
.init.data:function_stats
The function ftrace_init_tracefs() references
the variable __initdata function_stats.
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of function_stats is wrong.

WARNING: kernel/trace/built-in.o(.text+0x97a2): Section mismatch in reference 
from the function ftrace_init_tracefs() to the variable 
.init.data:function_stats
The function ftrace_init_tracefs() references
the variable __initdata function_stats.
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of function_stats is wrong.

WARNING: kernel/trace/built-in.o(.text+0x97ad): Section mismatch in reference 
from the function ftrace_init_tracefs() to the (unknown reference) 
.init.data:(unknown)
The function ftrace_init_tracefs() references
the (unknown reference) __initdata (unknown).
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: kernel/trace/built-in.o(.text+0x97b8): Section mismatch in reference 
from the function ftrace_init_tracefs() to the (unknown reference) 
.init.data:(unknown)
The function ftrace_init_tracefs() references
the (unknown reference) __initdata (unknown).
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: kernel/trace/built-in.o(.text+0x97c3): Section mismatch in reference 
from the function ftrace_init_tracefs() to the (unknown reference) 
.init.data:(unknown)
The function ftrace_init_tracefs() references
the (unknown reference) __initdata (unknown).
This is often because ftrace_init_tracefs lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: 

Re: [PATCH 3/3] mm/page_owner: track page free call chain

[Joonsoo Kim]

On Mon, Jul 04, 2016 at 02:07:30PM +0900, Sergey Senozhatsky wrote:
> Hello,
> 
> On (07/04/16 13:57), Joonsoo Kim wrote:
> > On Sun, Jul 03, 2016 at 01:16:56AM +0900, Sergey Senozhatsky wrote:
> > > Introduce PAGE_OWNER_TRACK_FREE config option to extend page owner with
> > > free_pages() tracking functionality. This adds to the dump_page_owner()
> > > output an additional backtrace, that tells us what path has freed the
> > > page.
> > 
> > Hmm... Do you have other ideas to use this feature? Following example is
> > just to detect use-after-free and we have other good tools for it
> > (KASAN or DEBUG_PAGEALLOC) so I'm not sure whether it's useful or not.
> 
> there is no kasan for ARM32, for example (apart from the fact that
> it's really hard to use kasan sometimes due to its cpu cycles and
> memory requirements).

Hmm... for debugging purpose, KASAN provides many more things so IMO it's
better to implement/support KASAN in ARM32 rather than expand
PAGE_OWNER for free.

> 
> educate me, will DEBUG_PAGEALLOC tell us what path has triggered the
> extra put_page()? hm... does ARM32 provide ARCH_SUPPORTS_DEBUG_PAGEALLOC?

Hmm... Now, I notice that PAGE_OWNER_TRACK_FREE will detect
double-free rather than use-after-free. DEBUG_PAGEALLOC doesn't catch
double-free but it can be implemented easily. In this case, we can
show call path for second free.

AFAIK, ARM32 doesn't support ARCH_SUPPORTS_DEBUG_PAGEALLOC.

Thanks.

Re: [PATCH 3/3] mm/page_owner: track page free call chain

[Joonsoo Kim]

On Mon, Jul 04, 2016 at 02:07:30PM +0900, Sergey Senozhatsky wrote:
> Hello,
> 
> On (07/04/16 13:57), Joonsoo Kim wrote:
> > On Sun, Jul 03, 2016 at 01:16:56AM +0900, Sergey Senozhatsky wrote:
> > > Introduce PAGE_OWNER_TRACK_FREE config option to extend page owner with
> > > free_pages() tracking functionality. This adds to the dump_page_owner()
> > > output an additional backtrace, that tells us what path has freed the
> > > page.
> > 
> > Hmm... Do you have other ideas to use this feature? Following example is
> > just to detect use-after-free and we have other good tools for it
> > (KASAN or DEBUG_PAGEALLOC) so I'm not sure whether it's useful or not.
> 
> there is no kasan for ARM32, for example (apart from the fact that
> it's really hard to use kasan sometimes due to its cpu cycles and
> memory requirements).

Hmm... for debugging purpose, KASAN provides many more things so IMO it's
better to implement/support KASAN in ARM32 rather than expand
PAGE_OWNER for free.

> 
> educate me, will DEBUG_PAGEALLOC tell us what path has triggered the
> extra put_page()? hm... does ARM32 provide ARCH_SUPPORTS_DEBUG_PAGEALLOC?

Hmm... Now, I notice that PAGE_OWNER_TRACK_FREE will detect
double-free rather than use-after-free. DEBUG_PAGEALLOC doesn't catch
double-free but it can be implemented easily. In this case, we can
show call path for second free.

AFAIK, ARM32 doesn't support ARCH_SUPPORTS_DEBUG_PAGEALLOC.

Thanks.

Re: [PATCH perf/core v13 04/15] perf/sdt: ELF support for SDT

[Masami Hiramatsu]

On Fri, 1 Jul 2016 15:56:49 -0300
Arnaldo Carvalho de Melo  wrote:

> Em Fri, Jul 01, 2016 at 05:03:46PM +0900, Masami Hiramatsu escreveu:
> > From: Hemant Kumar 
> > 
> > This patch serves the initial support to identify and list SDT events in 
> > binaries.
> > When programs containing SDT markers are compiled, gcc with the help of 
> > assembler
> > directives identifies them and places them in the section ".note.stapsdt". 
> > To find
> > these markers from the binaries, one needs to traverse through this section 
> > and
> > parse the relevant details like the name, type and location of the marker. 
> > Also,
> > the original location could be skewed due to the effect of prelinking. If 
> > that is
> > the case, the locations need to be adjusted.
> > 
> > The functions in this patch open a given ELF, find out the SDT section, 
> > parse the
> > relevant details, adjust the location (if necessary) and populate them in a 
> > list.
> 
> Breaks the build on older systems:
> 
> 
> [root@jouet perf]# dm
> centos:5: FAIL
>   CC   /tmp/build/perf/util/symbol-elf.o
> cc1: warnings being treated as errors
> util/symbol-elf.c: In function 'construct_sdt_notes_list':
> util/symbol-elf.c:1927: warning: implicit declaration of function 
> 'elf_getshdrstrndx'
> util/symbol-elf.c:1927: warning: nested extern declaration of 
> 'elf_getshdrstrndx'
> mv: cannot stat `/tmp/build/perf/util/.symbol-elf.o.tmp': No such file or 
> directory
> make[3]: *** [/tmp/build/perf/util/symbol-elf.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> make[2]: *** [util] Error 2
> make[1]: *** [/tmp/build/perf/libperf-in.o] Error 2
> make: *** [install-bin] Error 2
> make: Leaving directory `/git/linux/tools/perf'
> centos:6: Ok
> centos:7: Ok
> debian:experimental: Ok
> debian:7: Ok
> debian:8: Ok
> fedora:21: Ok
> fedora:22: Ok
> fedora:23: Ok
> fedora:24: Ok
> opensuse:13.2: Ok
> opensuse:42.1: Ok
> ubuntu:14.04.4: Ok
> ubuntu:15.10: Ok
> ubuntu:16.04: Ok
> ubuntu:12.04.5: Ok
> 
> -

OK, that API is newer one. We have to check wheter it is supported by libelf.

> 
> Needs a feature detection test, I will try to contribute that.

Thanks!

> 
> - Arnaldo
> 
>  
> > A typical note entry in ".note.stapsdt" section is as follows :
> > 
> > 
> >  |--nhdr.n_namesz--|
> > 
> > |  nhdr  | "stapsdt"   |
> > -   |--|
> >  |  |  |
> >  |  |   |
> > nhdr.n_descsize |  "provider_name"   "note_name"   |
> >  |  ||
> > -   |--|
> > |  nhdr  | "stapsdt"   |
> > |...
> > 
> > The above shows an excerpt from the section ".note.stapsdt".
> > 'nhdr' is a structure which has the note name size (n_namesz), note
> > description size (n_desc_sz) and note type (n_type). So, in order to
> > parse the note note info, we need nhdr to tell us where to start from.
> > As can be seen from , the name of the SDT notes given is 
> > "stapsdt".
> > But this is not the identifier of the note.
> > After that, we go to description of the note to find out its location, the
> > address of the ".stapsdt.base" section and the semaphore address.
> > Then, we find the provider name and the SDT marker name and then follow the
> > arguments.
> > 
> > Signed-off-by: Hemant Kumar 
> > Reviewed-by: Masami Hiramatsu 
> > Acked-by: Namhyung Kim 
> > ---
> >  tools/perf/util/symbol-elf.c |  252 
> > ++
> >  tools/perf/util/symbol.h |   22 
> >  2 files changed, 274 insertions(+)
> > 
> > diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> > index 87a297d..e74ce17 100644
> > --- a/tools/perf/util/symbol-elf.c
> > +++ b/tools/perf/util/symbol-elf.c
> > @@ -1781,6 +1781,258 @@ void kcore_extract__delete(struct kcore_extract 
> > *kce)
> > unlink(kce->extract_filename);
> >  }
> >  
> > +/**
> > + * populate_sdt_note : Parse raw data and identify SDT note
> > + * @elf: elf of the opened file
> > + * @data: raw data of a section with description offset applied
> > + * @len: note description size
> > + * @type: type of the note
> > + * @sdt_notes: List to add the SDT note
> > + *
> > + * Responsible for parsing the @data in section .note.stapsdt in @elf and
> > + * if its an SDT note, it appends to @sdt_notes list.
> > + */
> > +static int populate_sdt_note(Elf **elf, const char *data, size_t len,
> > +struct list_head *sdt_notes)
> > +{
> > +   const char *provider, *name;
> > +   struct sdt_note *tmp = NULL;
> > +   GElf_Ehdr ehdr;
> > +   GElf_Addr base_off = 0;
> > +   GElf_Shdr shdr;
> > +   int ret = -EINVAL;
> > +
> > +   

Re: [PATCH perf/core v13 04/15] perf/sdt: ELF support for SDT

[Masami Hiramatsu]

On Fri, 1 Jul 2016 15:56:49 -0300
Arnaldo Carvalho de Melo  wrote:

> Em Fri, Jul 01, 2016 at 05:03:46PM +0900, Masami Hiramatsu escreveu:
> > From: Hemant Kumar 
> > 
> > This patch serves the initial support to identify and list SDT events in 
> > binaries.
> > When programs containing SDT markers are compiled, gcc with the help of 
> > assembler
> > directives identifies them and places them in the section ".note.stapsdt". 
> > To find
> > these markers from the binaries, one needs to traverse through this section 
> > and
> > parse the relevant details like the name, type and location of the marker. 
> > Also,
> > the original location could be skewed due to the effect of prelinking. If 
> > that is
> > the case, the locations need to be adjusted.
> > 
> > The functions in this patch open a given ELF, find out the SDT section, 
> > parse the
> > relevant details, adjust the location (if necessary) and populate them in a 
> > list.
> 
> Breaks the build on older systems:
> 
> 
> [root@jouet perf]# dm
> centos:5: FAIL
>   CC   /tmp/build/perf/util/symbol-elf.o
> cc1: warnings being treated as errors
> util/symbol-elf.c: In function 'construct_sdt_notes_list':
> util/symbol-elf.c:1927: warning: implicit declaration of function 
> 'elf_getshdrstrndx'
> util/symbol-elf.c:1927: warning: nested extern declaration of 
> 'elf_getshdrstrndx'
> mv: cannot stat `/tmp/build/perf/util/.symbol-elf.o.tmp': No such file or 
> directory
> make[3]: *** [/tmp/build/perf/util/symbol-elf.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> make[2]: *** [util] Error 2
> make[1]: *** [/tmp/build/perf/libperf-in.o] Error 2
> make: *** [install-bin] Error 2
> make: Leaving directory `/git/linux/tools/perf'
> centos:6: Ok
> centos:7: Ok
> debian:experimental: Ok
> debian:7: Ok
> debian:8: Ok
> fedora:21: Ok
> fedora:22: Ok
> fedora:23: Ok
> fedora:24: Ok
> opensuse:13.2: Ok
> opensuse:42.1: Ok
> ubuntu:14.04.4: Ok
> ubuntu:15.10: Ok
> ubuntu:16.04: Ok
> ubuntu:12.04.5: Ok
> 
> -

OK, that API is newer one. We have to check wheter it is supported by libelf.

> 
> Needs a feature detection test, I will try to contribute that.

Thanks!

> 
> - Arnaldo
> 
>  
> > A typical note entry in ".note.stapsdt" section is as follows :
> > 
> > 
> >  |--nhdr.n_namesz--|
> > 
> > |  nhdr  | "stapsdt"   |
> > -   |--|
> >  |  |  |
> >  |  |   |
> > nhdr.n_descsize |  "provider_name"   "note_name"   |
> >  |  ||
> > -   |--|
> > |  nhdr  | "stapsdt"   |
> > |...
> > 
> > The above shows an excerpt from the section ".note.stapsdt".
> > 'nhdr' is a structure which has the note name size (n_namesz), note
> > description size (n_desc_sz) and note type (n_type). So, in order to
> > parse the note note info, we need nhdr to tell us where to start from.
> > As can be seen from , the name of the SDT notes given is 
> > "stapsdt".
> > But this is not the identifier of the note.
> > After that, we go to description of the note to find out its location, the
> > address of the ".stapsdt.base" section and the semaphore address.
> > Then, we find the provider name and the SDT marker name and then follow the
> > arguments.
> > 
> > Signed-off-by: Hemant Kumar 
> > Reviewed-by: Masami Hiramatsu 
> > Acked-by: Namhyung Kim 
> > ---
> >  tools/perf/util/symbol-elf.c |  252 
> > ++
> >  tools/perf/util/symbol.h |   22 
> >  2 files changed, 274 insertions(+)
> > 
> > diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> > index 87a297d..e74ce17 100644
> > --- a/tools/perf/util/symbol-elf.c
> > +++ b/tools/perf/util/symbol-elf.c
> > @@ -1781,6 +1781,258 @@ void kcore_extract__delete(struct kcore_extract 
> > *kce)
> > unlink(kce->extract_filename);
> >  }
> >  
> > +/**
> > + * populate_sdt_note : Parse raw data and identify SDT note
> > + * @elf: elf of the opened file
> > + * @data: raw data of a section with description offset applied
> > + * @len: note description size
> > + * @type: type of the note
> > + * @sdt_notes: List to add the SDT note
> > + *
> > + * Responsible for parsing the @data in section .note.stapsdt in @elf and
> > + * if its an SDT note, it appends to @sdt_notes list.
> > + */
> > +static int populate_sdt_note(Elf **elf, const char *data, size_t len,
> > +struct list_head *sdt_notes)
> > +{
> > +   const char *provider, *name;
> > +   struct sdt_note *tmp = NULL;
> > +   GElf_Ehdr ehdr;
> > +   GElf_Addr base_off = 0;
> > +   GElf_Shdr shdr;
> > +   int ret = -EINVAL;
> > +
> > +   union {
> > +   Elf64_Addr a64[NR_ADDR];
> > +   Elf32_Addr a32[NR_ADDR];
> > +   } buf;
> > +
> > +  

السر الخاصة بك الرقم السري: (25512560)

[Microsoft Aisa Prom]

تهنئة حساب بريد إلكتروني حصل لك 90،00 $، USD من مايكروسوفت آسيا، 
ومايكروسوفت هي 41 عام وانتم لإرسال بياناتك الشخصية لهذا المكتب الآن تهنئة مرة 
أخرى.

السر الخاصة بك الرقم السري: (25512560)

[Microsoft Aisa Prom]

تهنئة حساب بريد إلكتروني حصل لك 90،00 $، USD من مايكروسوفت آسيا، 
ومايكروسوفت هي 41 عام وانتم لإرسال بياناتك الشخصية لهذا المكتب الآن تهنئة مرة 
أخرى.

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

[Jason Wang]

On 2016年07月04日 11:15, Stephen Rothwell wrote:

Hi all,

After merging the net-next tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

drivers/net/tun.c: In function 'tun_do_read.part.5':
/home/sfr/next/next/drivers/net/tun.c:1491:6: warning: 'err' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
   int err;
   ^

Introduced by commit

   1576d9860599 ("tun: switch to use skb array for tx")

I can't easily see if this is a false positive.



Thanks for the reporting, will post a fix.

Re: [GIT PULL] drm/mediatek: MT8173 gamma & dither support

[CK Hu]

Hi, Emil:

On Sun, 2016-07-03 at 23:43 +0100, Emil Velikov wrote:
> Hi Bibby,
> 
> On 27 June 2016 at 12:29, Bibby Hsieh  wrote:
> > On Mon, 2016-06-27 at 12:20 +0200, Matthias Brugger wrote:
> >>
> >> On 06/24/2016 09:27 AM, Bibby Hsieh wrote:
> >> > Hi Dave,
> >> >
> >> > Please consider merging this tag, which contains the v2 MT8173 gamma & 
> >> > dither function patches I sent on 2016-06-17, rebased onto v4.7-rc1. 
> >> > There have been no further comments.
> >> >
> >> > Thanks
> >> > Bibby
> >> >
> >> > The following changes since commit 
> >> > 1a695a905c18548062509178b98bc91e67510864:
> >> >
> >> >   Linux 4.7-rc1 (2016-05-29 16:29:24 GMT)
> >> >
> >> > are available in the git repository at:
> >> >
> >> >   g...@github.com:BibbyHsieh/linux4.7-rc1.git
> >> >
> >> > for you to fetch changes up to dd0eb773bc125f5e6bca735d19c08500dc3730f9:
> >> >
> >> >   drm/mediatek: Add gamma correction
> >> >
> >> > -
> >>
> >> As far as I can see, your branch has 3 patches on top from Eddie. It
> >> seems to me as if you didn't send your patches to the mailinglist before?
> >> Anyway this branch does not fulfill the rules to get merged into the
> >> linux kernel.
> >>
> >> Why do you send a pull request? The normal process is to send the
> >> patches via email and if the maintainer wants you can send a pull
> >> request once the patches are ready to be merged.
> >>
> >> Regards,
> >> Matthias
> >>
> >
> > I sent v1 and v2 on 2016-06-14 and 06-17 respectively [0-8].
> > After I made some modifications according to Daniel Vetter's comments,
> > there had been no further comments and I sent the pull request as the
> > other sub-sys.
> >
> > I'm sorry for my mistake, I will re-arrange the tree for upstream.
> > Next time, I will check with maintainer by email first, and sent the
> > pull request.
> >
> It might be a bit hard to find out who's the maintainer considering
> MAINTAINERS has no entry for this driver.
> 
> Looking at how things are going Philipp Zabel will be the more likely
> person for the task, yet I would be nice if someone from the Mediatek
> squad is helping him out - CK Hu perhaps ?
> 
> Regards,
> Emil

I'm willing to be one of Mediatek DRM driver maintainer. I wish this
would make things easier.

Regards,
CK

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

[Jason Wang]

On 2016年07月04日 11:15, Stephen Rothwell wrote:

Hi all,

After merging the net-next tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

drivers/net/tun.c: In function 'tun_do_read.part.5':
/home/sfr/next/next/drivers/net/tun.c:1491:6: warning: 'err' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
   int err;
   ^

Introduced by commit

   1576d9860599 ("tun: switch to use skb array for tx")

I can't easily see if this is a false positive.



Thanks for the reporting, will post a fix.

Re: [GIT PULL] drm/mediatek: MT8173 gamma & dither support

[CK Hu]

Hi, Emil:

On Sun, 2016-07-03 at 23:43 +0100, Emil Velikov wrote:
> Hi Bibby,
> 
> On 27 June 2016 at 12:29, Bibby Hsieh  wrote:
> > On Mon, 2016-06-27 at 12:20 +0200, Matthias Brugger wrote:
> >>
> >> On 06/24/2016 09:27 AM, Bibby Hsieh wrote:
> >> > Hi Dave,
> >> >
> >> > Please consider merging this tag, which contains the v2 MT8173 gamma & 
> >> > dither function patches I sent on 2016-06-17, rebased onto v4.7-rc1. 
> >> > There have been no further comments.
> >> >
> >> > Thanks
> >> > Bibby
> >> >
> >> > The following changes since commit 
> >> > 1a695a905c18548062509178b98bc91e67510864:
> >> >
> >> >   Linux 4.7-rc1 (2016-05-29 16:29:24 GMT)
> >> >
> >> > are available in the git repository at:
> >> >
> >> >   g...@github.com:BibbyHsieh/linux4.7-rc1.git
> >> >
> >> > for you to fetch changes up to dd0eb773bc125f5e6bca735d19c08500dc3730f9:
> >> >
> >> >   drm/mediatek: Add gamma correction
> >> >
> >> > -
> >>
> >> As far as I can see, your branch has 3 patches on top from Eddie. It
> >> seems to me as if you didn't send your patches to the mailinglist before?
> >> Anyway this branch does not fulfill the rules to get merged into the
> >> linux kernel.
> >>
> >> Why do you send a pull request? The normal process is to send the
> >> patches via email and if the maintainer wants you can send a pull
> >> request once the patches are ready to be merged.
> >>
> >> Regards,
> >> Matthias
> >>
> >
> > I sent v1 and v2 on 2016-06-14 and 06-17 respectively [0-8].
> > After I made some modifications according to Daniel Vetter's comments,
> > there had been no further comments and I sent the pull request as the
> > other sub-sys.
> >
> > I'm sorry for my mistake, I will re-arrange the tree for upstream.
> > Next time, I will check with maintainer by email first, and sent the
> > pull request.
> >
> It might be a bit hard to find out who's the maintainer considering
> MAINTAINERS has no entry for this driver.
> 
> Looking at how things are going Philipp Zabel will be the more likely
> person for the task, yet I would be nice if someone from the Mediatek
> squad is helping him out - CK Hu perhaps ?
> 
> Regards,
> Emil

I'm willing to be one of Mediatek DRM driver maintainer. I wish this
would make things easier.

Regards,
CK

Re: [PATCH 3/3] mm/page_owner: track page free call chain

[Sergey Senozhatsky]

Hello,

On (07/04/16 13:57), Joonsoo Kim wrote:
> On Sun, Jul 03, 2016 at 01:16:56AM +0900, Sergey Senozhatsky wrote:
> > Introduce PAGE_OWNER_TRACK_FREE config option to extend page owner with
> > free_pages() tracking functionality. This adds to the dump_page_owner()
> > output an additional backtrace, that tells us what path has freed the
> > page.
> 
> Hmm... Do you have other ideas to use this feature? Following example is
> just to detect use-after-free and we have other good tools for it
> (KASAN or DEBUG_PAGEALLOC) so I'm not sure whether it's useful or not.

there is no kasan for ARM32, for example (apart from the fact that
it's really hard to use kasan sometimes due to its cpu cycles and
memory requirements).

educate me, will DEBUG_PAGEALLOC tell us what path has triggered the
extra put_page()? hm... does ARM32 provide ARCH_SUPPORTS_DEBUG_PAGEALLOC?

-ss

> 
> And, if there is a good usage, I think that we don't need to add new
> Kconfig, PAGE_OWNER_TRACK_FREE. It only takes 8 bytes per page and
> it's not that big in this debugging context.
> 
> Thanks.
> 
> > 
> > Aa a trivial example, let's assume that do_some_foo() has an error - extra
> > put_page() on error return path, and the function is also getting preempted,
> > letting some other task to allocate the same page, which is then mistakenly
> > getting freed once again by do_some_foo().
> > 
> > CPUACPUB
> > 
> > void do_some_foo(void)
> > {
> > page = alloc_page();
> > if (error) {
> > put_page(page);
> > goto out;
> > }
> > ...
> > out:
> > <>
> > void do_some_bar()
> > {
> > page = alloc_page();
> > ...
> > <>
> > ...
> > put_page(page);
> > }
> > <>
> > put_page(page);
> > }
> > 
> > 
> > Backtrace:
> > 
> > 
> >  BUG: Bad page state in process cc1  pfn:bae1d
> >  page:ea0002eb8740 count:-1 mapcount:0 mapping:  (null) 
> > index:0x0
> >  flags: 0x4000()
> >  page dumped because: nonzero _count
> >  page allocated via order 0, migratetype Unmovable, gfp_mask 
> > 0x2000200(GFP_NOWAIT|__GFP_NOWARN)
> >   [] save_stack_trace+0x26/0x41
> >   [] save_stack+0x46/0xc3
> >   [] __page_owner_alloc_pages+0x24/0x41
> >   [] post_alloc_hook+0x1e/0x20
> >   [] get_page_from_freelist+0x4fd/0x756
> >   [] __alloc_pages_nodemask+0xe7/0xbcf
> >   [] __get_free_pages+0x12/0x40
> >   [] __tlb_remove_page_size.part.12+0x37/0x78
> >   [] __tlb_remove_page_size+0x21/0x23
> >   [] unmap_page_range+0x63a/0x75b
> >   [] unmap_single_vma+0xbc/0xc6
> >   [] unmap_vmas+0x35/0x44
> >   [] exit_mmap+0x5a/0xec
> >   [] mmput+0x4a/0xdc
> >   [] do_exit+0x398/0x8de
> >   [] do_group_exit+0x45/0xb0
> >  page freed via order 0, migratetype Unmovable, gfp_mask 
> > 0x2000200(GFP_NOWAIT|__GFP_NOWARN)
> >   [] save_stack_trace+0x26/0x41
> >   [] save_stack+0x46/0xc3
> >   [] __page_owner_free_pages+0x25/0x71
> >   [] free_hot_cold_page+0x1d6/0x1ea
> >   [] __put_page+0x37/0x3a
> >   [] do_some_foo()+0x8a/0x8e
> > ...
> >  Modules linked in: 
> >  CPU: 3 PID: 1274 Comm: cc1 Not tainted 
> > 4.7.0-rc5-next-20160701-dbg-9-ge01494f-dirty #535
> >    8800aeea3c18 811e67ca ea0002eb8740
> >   8175675e 8800aeea3c40 810c87f5 
> >   81880b40 880137d98438 8800aeea3c50 810c88d5
> >  Call Trace:
> >   [] dump_stack+0x68/0x92
> >   [] bad_page+0xf8/0x11e
> >   [] check_new_page_bad+0x63/0x65
> >   [] get_page_from_freelist+0x22a/0x756
> >   [] __alloc_pages_nodemask+0xe7/0xbcf
> >   [] ? trace_hardirqs_on_caller+0x16d/0x189
> >   [] ? vma_merge+0x159/0x249
> >   [] ? __lock_acquire+0x2ac/0x15c7
> >   [] pte_alloc_one+0x1b/0x67
> >   [] __pte_alloc+0x19/0xa6
> >   [] handle_mm_fault+0x409/0xc59
> >   [] __do_page_fault+0x1d8/0x3ac
> >   [] do_page_fault+0xc/0xe
> >   [] page_fault+0x1f/0x30
> > 
> > Signed-off-by: Sergey Senozhatsky 
> > ---
> >  include/linux/page_ext.h | 13 ++-
> >  lib/Kconfig.debug| 10 +
> >  mm/page_owner.c  | 98 
> > ++--
> >  mm/vmstat.c  |  3 ++
> >  4 files changed, 95 insertions(+), 29 deletions(-)
> > 
> > diff --git a/include/linux/page_ext.h b/include/linux/page_ext.h
> > index 66ba2bb..90bd44a 100644
> > --- a/include/linux/page_ext.h
> > +++ b/include/linux/page_ext.h
> > @@ -27,12 +27,23 @@ enum page_ext_flags {
> > PAGE_EXT_DEBUG_POISON,  /* Page is poisoned */
> > PAGE_EXT_DEBUG_GUARD,
> > PAGE_EXT_OWNER_ALLOC,
> > +   PAGE_EXT_OWNER_FREE,
> >  #if 

Re: [PATCH 3/3] mm/page_owner: track page free call chain

[Sergey Senozhatsky]

Hello,

On (07/04/16 13:57), Joonsoo Kim wrote:
> On Sun, Jul 03, 2016 at 01:16:56AM +0900, Sergey Senozhatsky wrote:
> > Introduce PAGE_OWNER_TRACK_FREE config option to extend page owner with
> > free_pages() tracking functionality. This adds to the dump_page_owner()
> > output an additional backtrace, that tells us what path has freed the
> > page.
> 
> Hmm... Do you have other ideas to use this feature? Following example is
> just to detect use-after-free and we have other good tools for it
> (KASAN or DEBUG_PAGEALLOC) so I'm not sure whether it's useful or not.

there is no kasan for ARM32, for example (apart from the fact that
it's really hard to use kasan sometimes due to its cpu cycles and
memory requirements).

educate me, will DEBUG_PAGEALLOC tell us what path has triggered the
extra put_page()? hm... does ARM32 provide ARCH_SUPPORTS_DEBUG_PAGEALLOC?

-ss

> 
> And, if there is a good usage, I think that we don't need to add new
> Kconfig, PAGE_OWNER_TRACK_FREE. It only takes 8 bytes per page and
> it's not that big in this debugging context.
> 
> Thanks.
> 
> > 
> > Aa a trivial example, let's assume that do_some_foo() has an error - extra
> > put_page() on error return path, and the function is also getting preempted,
> > letting some other task to allocate the same page, which is then mistakenly
> > getting freed once again by do_some_foo().
> > 
> > CPUACPUB
> > 
> > void do_some_foo(void)
> > {
> > page = alloc_page();
> > if (error) {
> > put_page(page);
> > goto out;
> > }
> > ...
> > out:
> > <>
> > void do_some_bar()
> > {
> > page = alloc_page();
> > ...
> > <>
> > ...
> > put_page(page);
> > }
> > <>
> > put_page(page);
> > }
> > 
> > 
> > Backtrace:
> > 
> > 
> >  BUG: Bad page state in process cc1  pfn:bae1d
> >  page:ea0002eb8740 count:-1 mapcount:0 mapping:  (null) 
> > index:0x0
> >  flags: 0x4000()
> >  page dumped because: nonzero _count
> >  page allocated via order 0, migratetype Unmovable, gfp_mask 
> > 0x2000200(GFP_NOWAIT|__GFP_NOWARN)
> >   [] save_stack_trace+0x26/0x41
> >   [] save_stack+0x46/0xc3
> >   [] __page_owner_alloc_pages+0x24/0x41
> >   [] post_alloc_hook+0x1e/0x20
> >   [] get_page_from_freelist+0x4fd/0x756
> >   [] __alloc_pages_nodemask+0xe7/0xbcf
> >   [] __get_free_pages+0x12/0x40
> >   [] __tlb_remove_page_size.part.12+0x37/0x78
> >   [] __tlb_remove_page_size+0x21/0x23
> >   [] unmap_page_range+0x63a/0x75b
> >   [] unmap_single_vma+0xbc/0xc6
> >   [] unmap_vmas+0x35/0x44
> >   [] exit_mmap+0x5a/0xec
> >   [] mmput+0x4a/0xdc
> >   [] do_exit+0x398/0x8de
> >   [] do_group_exit+0x45/0xb0
> >  page freed via order 0, migratetype Unmovable, gfp_mask 
> > 0x2000200(GFP_NOWAIT|__GFP_NOWARN)
> >   [] save_stack_trace+0x26/0x41
> >   [] save_stack+0x46/0xc3
> >   [] __page_owner_free_pages+0x25/0x71
> >   [] free_hot_cold_page+0x1d6/0x1ea
> >   [] __put_page+0x37/0x3a
> >   [] do_some_foo()+0x8a/0x8e
> > ...
> >  Modules linked in: 
> >  CPU: 3 PID: 1274 Comm: cc1 Not tainted 
> > 4.7.0-rc5-next-20160701-dbg-9-ge01494f-dirty #535
> >    8800aeea3c18 811e67ca ea0002eb8740
> >   8175675e 8800aeea3c40 810c87f5 
> >   81880b40 880137d98438 8800aeea3c50 810c88d5
> >  Call Trace:
> >   [] dump_stack+0x68/0x92
> >   [] bad_page+0xf8/0x11e
> >   [] check_new_page_bad+0x63/0x65
> >   [] get_page_from_freelist+0x22a/0x756
> >   [] __alloc_pages_nodemask+0xe7/0xbcf
> >   [] ? trace_hardirqs_on_caller+0x16d/0x189
> >   [] ? vma_merge+0x159/0x249
> >   [] ? __lock_acquire+0x2ac/0x15c7
> >   [] pte_alloc_one+0x1b/0x67
> >   [] __pte_alloc+0x19/0xa6
> >   [] handle_mm_fault+0x409/0xc59
> >   [] __do_page_fault+0x1d8/0x3ac
> >   [] do_page_fault+0xc/0xe
> >   [] page_fault+0x1f/0x30
> > 
> > Signed-off-by: Sergey Senozhatsky 
> > ---
> >  include/linux/page_ext.h | 13 ++-
> >  lib/Kconfig.debug| 10 +
> >  mm/page_owner.c  | 98 
> > ++--
> >  mm/vmstat.c  |  3 ++
> >  4 files changed, 95 insertions(+), 29 deletions(-)
> > 
> > diff --git a/include/linux/page_ext.h b/include/linux/page_ext.h
> > index 66ba2bb..90bd44a 100644
> > --- a/include/linux/page_ext.h
> > +++ b/include/linux/page_ext.h
> > @@ -27,12 +27,23 @@ enum page_ext_flags {
> > PAGE_EXT_DEBUG_POISON,  /* Page is poisoned */
> > PAGE_EXT_DEBUG_GUARD,
> > PAGE_EXT_OWNER_ALLOC,
> > +   PAGE_EXT_OWNER_FREE,
> >  #if defined(CONFIG_IDLE_PAGE_TRACKING) && !defined(CONFIG_64BIT)

Re: [PATCH v3 0/2] mark spi clocks as critical and enable spi3 clocks

[Tomasz Figa]

2016-07-04 13:20 GMT+09:00 Andi Shyti :
> Hi Tomasz,
>
>> > This patchset enables spi3 clocks by marking critical clocks as
>> > CLK_IS_CRITICAL and in the meantime replaces the use of
>> > CLK_IGNORE_UNUSED for spi1 clocks.
>> >
>> > The sclk needs to be considered critical as well.
>> >
>> > The SPI3 in the tm2/tm2e boards will control an irled for remote
>> > controlling.
>> >
>> > Changelog:
>> >
>> > V1 -> V2
>> >  - the "sclk_spi3" doesn't need to be enabled in boot time as it
>> >   is handled by the spi driver itself.
>> >
>> >  - use the CLK_IS_CRITICAL flag for the ioclk
>> >
>> > V2 -> V3
>> >  - some more tests has confirmed taht "sclk_spi1,3" need to be
>> >enabled as critical!
>>
>> This sounds like a DTS and/or SPI and/or clock driver bug then. I'm
>> pretty much convinced that it might also cause other problems and this
>> workaround will only mask them making things even more difficult to
>> debug in the future. Let's not introduce more technical debt.
>
> In principle I agree, but, the upcoming TM2/TM2e boards will have
> the audio codec connected on SPI1 and the ir remote controller on
> the SPI3 (others SPI slots are used as well, but we don't have
> the drivers ready for them).
>
> I followed for SPI3 the same approach as it was done for SPI1, so
> that I see two choices here:
>
>  * reject this patches and cleanup the SPI1 from the "technical
>debt" and not have anything working on spi.

>
> or
>
>  * do for SPI3 the same as it has been done for SPI1 (and as it
>is now) with its "technical debt".
>
> I did quite an extensive testing on these lines and I don't see
> any other alternative.

The SPI driver is supposed to enable the SPI bus clock whenever
necessary, if it's given the clock correctly and the clock driver has
the clock hierarchy correctly defined. So I see third choice here:

 * Debug why the SPI driver doesn't properly enable the clock, fix the
cause (fixing both SPI1 and SPI3 sclk at the same time) and then
remove the CLK_IGNORE_UNUSED flag from sclk_spi1.

Of course the above doesn't apply to sclk_ioclk clocks, as we already
agreed that they need CLK_IS_CRITICAL due to their nature.

Best regards,
Tomasz

Re: [PATCH v3 0/2] mark spi clocks as critical and enable spi3 clocks

[Tomasz Figa]

2016-07-04 13:20 GMT+09:00 Andi Shyti :
> Hi Tomasz,
>
>> > This patchset enables spi3 clocks by marking critical clocks as
>> > CLK_IS_CRITICAL and in the meantime replaces the use of
>> > CLK_IGNORE_UNUSED for spi1 clocks.
>> >
>> > The sclk needs to be considered critical as well.
>> >
>> > The SPI3 in the tm2/tm2e boards will control an irled for remote
>> > controlling.
>> >
>> > Changelog:
>> >
>> > V1 -> V2
>> >  - the "sclk_spi3" doesn't need to be enabled in boot time as it
>> >   is handled by the spi driver itself.
>> >
>> >  - use the CLK_IS_CRITICAL flag for the ioclk
>> >
>> > V2 -> V3
>> >  - some more tests has confirmed taht "sclk_spi1,3" need to be
>> >enabled as critical!
>>
>> This sounds like a DTS and/or SPI and/or clock driver bug then. I'm
>> pretty much convinced that it might also cause other problems and this
>> workaround will only mask them making things even more difficult to
>> debug in the future. Let's not introduce more technical debt.
>
> In principle I agree, but, the upcoming TM2/TM2e boards will have
> the audio codec connected on SPI1 and the ir remote controller on
> the SPI3 (others SPI slots are used as well, but we don't have
> the drivers ready for them).
>
> I followed for SPI3 the same approach as it was done for SPI1, so
> that I see two choices here:
>
>  * reject this patches and cleanup the SPI1 from the "technical
>debt" and not have anything working on spi.

>
> or
>
>  * do for SPI3 the same as it has been done for SPI1 (and as it
>is now) with its "technical debt".
>
> I did quite an extensive testing on these lines and I don't see
> any other alternative.

The SPI driver is supposed to enable the SPI bus clock whenever
necessary, if it's given the clock correctly and the clock driver has
the clock hierarchy correctly defined. So I see third choice here:

 * Debug why the SPI driver doesn't properly enable the clock, fix the
cause (fixing both SPI1 and SPI3 sclk at the same time) and then
remove the CLK_IGNORE_UNUSED flag from sclk_spi1.

Of course the above doesn't apply to sclk_ioclk clocks, as we already
agreed that they need CLK_IS_CRITICAL due to their nature.

Best regards,
Tomasz

Re: [PATCH 3/3] mm/page_owner: track page free call chain

[Joonsoo Kim]

On Sun, Jul 03, 2016 at 01:16:56AM +0900, Sergey Senozhatsky wrote:
> Introduce PAGE_OWNER_TRACK_FREE config option to extend page owner with
> free_pages() tracking functionality. This adds to the dump_page_owner()
> output an additional backtrace, that tells us what path has freed the
> page.

Hmm... Do you have other ideas to use this feature? Following example is
just to detect use-after-free and we have other good tools for it
(KASAN or DEBUG_PAGEALLOC) so I'm not sure whether it's useful or not.

And, if there is a good usage, I think that we don't need to add new
Kconfig, PAGE_OWNER_TRACK_FREE. It only takes 8 bytes per page and
it's not that big in this debugging context.

Thanks.

> 
> Aa a trivial example, let's assume that do_some_foo() has an error - extra
> put_page() on error return path, and the function is also getting preempted,
> letting some other task to allocate the same page, which is then mistakenly
> getting freed once again by do_some_foo().
> 
> CPUA  CPUB
> 
> void do_some_foo(void)
> {
>   page = alloc_page();
>   if (error) {
>   put_page(page);
>   goto out;
>   }
>   ...
> out:
>   <>
>   void do_some_bar()
>   {
>   page = alloc_page();
>   ...
>   <>
>   ...
>   put_page(page);
> }
>   <>
>   put_page(page);
>   }
> 
> 
> Backtrace:
> 
> 
>  BUG: Bad page state in process cc1  pfn:bae1d
>  page:ea0002eb8740 count:-1 mapcount:0 mapping:  (null) index:0x0
>  flags: 0x4000()
>  page dumped because: nonzero _count
>  page allocated via order 0, migratetype Unmovable, gfp_mask 
> 0x2000200(GFP_NOWAIT|__GFP_NOWARN)
>   [] save_stack_trace+0x26/0x41
>   [] save_stack+0x46/0xc3
>   [] __page_owner_alloc_pages+0x24/0x41
>   [] post_alloc_hook+0x1e/0x20
>   [] get_page_from_freelist+0x4fd/0x756
>   [] __alloc_pages_nodemask+0xe7/0xbcf
>   [] __get_free_pages+0x12/0x40
>   [] __tlb_remove_page_size.part.12+0x37/0x78
>   [] __tlb_remove_page_size+0x21/0x23
>   [] unmap_page_range+0x63a/0x75b
>   [] unmap_single_vma+0xbc/0xc6
>   [] unmap_vmas+0x35/0x44
>   [] exit_mmap+0x5a/0xec
>   [] mmput+0x4a/0xdc
>   [] do_exit+0x398/0x8de
>   [] do_group_exit+0x45/0xb0
>  page freed via order 0, migratetype Unmovable, gfp_mask 
> 0x2000200(GFP_NOWAIT|__GFP_NOWARN)
>   [] save_stack_trace+0x26/0x41
>   [] save_stack+0x46/0xc3
>   [] __page_owner_free_pages+0x25/0x71
>   [] free_hot_cold_page+0x1d6/0x1ea
>   [] __put_page+0x37/0x3a
>   [] do_some_foo()+0x8a/0x8e
>   ...
>  Modules linked in: 
>  CPU: 3 PID: 1274 Comm: cc1 Not tainted 
> 4.7.0-rc5-next-20160701-dbg-9-ge01494f-dirty #535
>    8800aeea3c18 811e67ca ea0002eb8740
>   8175675e 8800aeea3c40 810c87f5 
>   81880b40 880137d98438 8800aeea3c50 810c88d5
>  Call Trace:
>   [] dump_stack+0x68/0x92
>   [] bad_page+0xf8/0x11e
>   [] check_new_page_bad+0x63/0x65
>   [] get_page_from_freelist+0x22a/0x756
>   [] __alloc_pages_nodemask+0xe7/0xbcf
>   [] ? trace_hardirqs_on_caller+0x16d/0x189
>   [] ? vma_merge+0x159/0x249
>   [] ? __lock_acquire+0x2ac/0x15c7
>   [] pte_alloc_one+0x1b/0x67
>   [] __pte_alloc+0x19/0xa6
>   [] handle_mm_fault+0x409/0xc59
>   [] __do_page_fault+0x1d8/0x3ac
>   [] do_page_fault+0xc/0xe
>   [] page_fault+0x1f/0x30
> 
> Signed-off-by: Sergey Senozhatsky 
> ---
>  include/linux/page_ext.h | 13 ++-
>  lib/Kconfig.debug| 10 +
>  mm/page_owner.c  | 98 
> ++--
>  mm/vmstat.c  |  3 ++
>  4 files changed, 95 insertions(+), 29 deletions(-)
> 
> diff --git a/include/linux/page_ext.h b/include/linux/page_ext.h
> index 66ba2bb..90bd44a 100644
> --- a/include/linux/page_ext.h
> +++ b/include/linux/page_ext.h
> @@ -27,12 +27,23 @@ enum page_ext_flags {
>   PAGE_EXT_DEBUG_POISON,  /* Page is poisoned */
>   PAGE_EXT_DEBUG_GUARD,
>   PAGE_EXT_OWNER_ALLOC,
> + PAGE_EXT_OWNER_FREE,
>  #if defined(CONFIG_IDLE_PAGE_TRACKING) && !defined(CONFIG_64BIT)
>   PAGE_EXT_YOUNG,
>   PAGE_EXT_IDLE,
>  #endif
>  };
>  
> +#ifdef CONFIG_PAGE_OWNER
> +enum page_owner_handles {
> + PAGE_OWNER_HANDLE_ALLOC,
> +#ifdef CONFIG_PAGE_OWNER_TRACK_FREE
> + PAGE_OWNER_HANDLE_FREE,
> +#endif
> + PAGE_OWNER_HANDLE_MAX
> +};
> +#endif
> +
>  /*
>   * Page Extension can be considered as an extended mem_map.
>   * A page_ext page is associated with every page descriptor. The
> @@ -46,7 +57,7 @@ struct page_ext {
>   unsigned int order;
>   gfp_t gfp_mask;
>   int 

Re: [PATCH 3/3] mm/page_owner: track page free call chain

[Joonsoo Kim]

On Sun, Jul 03, 2016 at 01:16:56AM +0900, Sergey Senozhatsky wrote:
> Introduce PAGE_OWNER_TRACK_FREE config option to extend page owner with
> free_pages() tracking functionality. This adds to the dump_page_owner()
> output an additional backtrace, that tells us what path has freed the
> page.

Hmm... Do you have other ideas to use this feature? Following example is
just to detect use-after-free and we have other good tools for it
(KASAN or DEBUG_PAGEALLOC) so I'm not sure whether it's useful or not.

And, if there is a good usage, I think that we don't need to add new
Kconfig, PAGE_OWNER_TRACK_FREE. It only takes 8 bytes per page and
it's not that big in this debugging context.

Thanks.

> 
> Aa a trivial example, let's assume that do_some_foo() has an error - extra
> put_page() on error return path, and the function is also getting preempted,
> letting some other task to allocate the same page, which is then mistakenly
> getting freed once again by do_some_foo().
> 
> CPUA  CPUB
> 
> void do_some_foo(void)
> {
>   page = alloc_page();
>   if (error) {
>   put_page(page);
>   goto out;
>   }
>   ...
> out:
>   <>
>   void do_some_bar()
>   {
>   page = alloc_page();
>   ...
>   <>
>   ...
>   put_page(page);
> }
>   <>
>   put_page(page);
>   }
> 
> 
> Backtrace:
> 
> 
>  BUG: Bad page state in process cc1  pfn:bae1d
>  page:ea0002eb8740 count:-1 mapcount:0 mapping:  (null) index:0x0
>  flags: 0x4000()
>  page dumped because: nonzero _count
>  page allocated via order 0, migratetype Unmovable, gfp_mask 
> 0x2000200(GFP_NOWAIT|__GFP_NOWARN)
>   [] save_stack_trace+0x26/0x41
>   [] save_stack+0x46/0xc3
>   [] __page_owner_alloc_pages+0x24/0x41
>   [] post_alloc_hook+0x1e/0x20
>   [] get_page_from_freelist+0x4fd/0x756
>   [] __alloc_pages_nodemask+0xe7/0xbcf
>   [] __get_free_pages+0x12/0x40
>   [] __tlb_remove_page_size.part.12+0x37/0x78
>   [] __tlb_remove_page_size+0x21/0x23
>   [] unmap_page_range+0x63a/0x75b
>   [] unmap_single_vma+0xbc/0xc6
>   [] unmap_vmas+0x35/0x44
>   [] exit_mmap+0x5a/0xec
>   [] mmput+0x4a/0xdc
>   [] do_exit+0x398/0x8de
>   [] do_group_exit+0x45/0xb0
>  page freed via order 0, migratetype Unmovable, gfp_mask 
> 0x2000200(GFP_NOWAIT|__GFP_NOWARN)
>   [] save_stack_trace+0x26/0x41
>   [] save_stack+0x46/0xc3
>   [] __page_owner_free_pages+0x25/0x71
>   [] free_hot_cold_page+0x1d6/0x1ea
>   [] __put_page+0x37/0x3a
>   [] do_some_foo()+0x8a/0x8e
>   ...
>  Modules linked in: 
>  CPU: 3 PID: 1274 Comm: cc1 Not tainted 
> 4.7.0-rc5-next-20160701-dbg-9-ge01494f-dirty #535
>    8800aeea3c18 811e67ca ea0002eb8740
>   8175675e 8800aeea3c40 810c87f5 
>   81880b40 880137d98438 8800aeea3c50 810c88d5
>  Call Trace:
>   [] dump_stack+0x68/0x92
>   [] bad_page+0xf8/0x11e
>   [] check_new_page_bad+0x63/0x65
>   [] get_page_from_freelist+0x22a/0x756
>   [] __alloc_pages_nodemask+0xe7/0xbcf
>   [] ? trace_hardirqs_on_caller+0x16d/0x189
>   [] ? vma_merge+0x159/0x249
>   [] ? __lock_acquire+0x2ac/0x15c7
>   [] pte_alloc_one+0x1b/0x67
>   [] __pte_alloc+0x19/0xa6
>   [] handle_mm_fault+0x409/0xc59
>   [] __do_page_fault+0x1d8/0x3ac
>   [] do_page_fault+0xc/0xe
>   [] page_fault+0x1f/0x30
> 
> Signed-off-by: Sergey Senozhatsky 
> ---
>  include/linux/page_ext.h | 13 ++-
>  lib/Kconfig.debug| 10 +
>  mm/page_owner.c  | 98 
> ++--
>  mm/vmstat.c  |  3 ++
>  4 files changed, 95 insertions(+), 29 deletions(-)
> 
> diff --git a/include/linux/page_ext.h b/include/linux/page_ext.h
> index 66ba2bb..90bd44a 100644
> --- a/include/linux/page_ext.h
> +++ b/include/linux/page_ext.h
> @@ -27,12 +27,23 @@ enum page_ext_flags {
>   PAGE_EXT_DEBUG_POISON,  /* Page is poisoned */
>   PAGE_EXT_DEBUG_GUARD,
>   PAGE_EXT_OWNER_ALLOC,
> + PAGE_EXT_OWNER_FREE,
>  #if defined(CONFIG_IDLE_PAGE_TRACKING) && !defined(CONFIG_64BIT)
>   PAGE_EXT_YOUNG,
>   PAGE_EXT_IDLE,
>  #endif
>  };
>  
> +#ifdef CONFIG_PAGE_OWNER
> +enum page_owner_handles {
> + PAGE_OWNER_HANDLE_ALLOC,
> +#ifdef CONFIG_PAGE_OWNER_TRACK_FREE
> + PAGE_OWNER_HANDLE_FREE,
> +#endif
> + PAGE_OWNER_HANDLE_MAX
> +};
> +#endif
> +
>  /*
>   * Page Extension can be considered as an extended mem_map.
>   * A page_ext page is associated with every page descriptor. The
> @@ -46,7 +57,7 @@ struct page_ext {
>   unsigned int order;
>   gfp_t gfp_mask;
>   int last_migrate_reason;
> - 

Re: [PATCH] kasan: make depot_fetch_stack more robust

[Joonsoo Kim]

On Fri, Jul 01, 2016 at 07:38:18PM +0200, Dmitry Vyukov wrote:
> I've hit a GPF in depot_fetch_stack when it was given
> bogus stack handle. I think it was caused by a distant
> out-of-bounds that hit a different object, as the result
> we treated uninit garbage as stack handle. Maybe there is
> something to fix in KASAN logic, but I think it makes
> sense to make depot_fetch_stack more robust as well.
> 
> Verify that the provided stack handle looks correct.
> 
> Signed-off-by: Dmitry Vyukov 
> ---
> For your convenience uploaded to codereview:
> https://codereview.appspot.com/295680043
> 
> ---
>  include/linux/stackdepot.h |  2 +-
>  lib/stackdepot.c   | 21 +
>  mm/kasan/report.c  | 10 --
>  mm/page_owner.c| 12 ++--
>  4 files changed, 28 insertions(+), 17 deletions(-)
> 
> diff --git a/include/linux/stackdepot.h b/include/linux/stackdepot.h
> index 7978b3e..b2dbe02 100644
> --- a/include/linux/stackdepot.h
> +++ b/include/linux/stackdepot.h
> @@ -27,6 +27,6 @@ struct stack_trace;
>  
>  depot_stack_handle_t depot_save_stack(struct stack_trace *trace, gfp_t 
> flags);
>  
> -void depot_fetch_stack(depot_stack_handle_t handle, struct stack_trace 
> *trace);
> +bool depot_fetch_stack(depot_stack_handle_t handle, struct stack_trace 
> *trace);
>  
>  #endif
> diff --git a/lib/stackdepot.c b/lib/stackdepot.c
> index 53ad6c0..0982331 100644
> --- a/lib/stackdepot.c
> +++ b/lib/stackdepot.c
> @@ -181,16 +181,29 @@ static inline struct stack_record *find_stack(struct 
> stack_record *bucket,
>   return NULL;
>  }
>  
> -void depot_fetch_stack(depot_stack_handle_t handle, struct stack_trace 
> *trace)
> +bool depot_fetch_stack(depot_stack_handle_t handle, struct stack_trace 
> *trace)
>  {
>   union handle_parts parts = { .handle = handle };
> - void *slab = stack_slabs[parts.slabindex];
> - size_t offset = parts.offset << STACK_ALLOC_ALIGN;
> - struct stack_record *stack = slab + offset;
> + void *slab;
> + struct stack_record *stack;
>  
> + if (handle == 0)
> + return false;
> + if (parts.valid != 1 || parts.slabindex >= ARRAY_SIZE(stack_slabs))
> + goto bad;
> + slab = stack_slabs[parts.slabindex];
> + if (slab == NULL)
> + goto bad;
> + stack = slab + (parts.offset << STACK_ALLOC_ALIGN);
> + if (stack->handle.handle != handle)
> + goto bad;
>   trace->nr_entries = trace->max_entries = stack->size;
>   trace->entries = stack->entries;
>   trace->skip = 0;
> + return true;
> +bad:
> + pr_err("stackdepot: fetching bogus stack %x\n", handle);
> + return false;
>  }
>  
>  /**
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index 861b977..46e4b82 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -118,15 +118,13 @@ static inline bool init_task_stack_addr(const void 
> *addr)
>  
>  static void print_track(struct kasan_track *track)
>  {
> - pr_err("PID = %u\n", track->pid);
> - if (track->stack) {
> - struct stack_trace trace;
> + struct stack_trace trace;
>  
> - depot_fetch_stack(track->stack, );
> + pr_err("PID = %u\n", track->pid);
> + if (depot_fetch_stack(track->stack, ))
>   print_stack_trace(, 0);
> - } else {
> + else
>   pr_err("(stack is not available)\n");
> - }
>  }
>  
>  static void kasan_object_err(struct kmem_cache *cache, struct page *page,
> diff --git a/mm/page_owner.c b/mm/page_owner.c
> index 8fa5083..1862f05 100644
> --- a/mm/page_owner.c
> +++ b/mm/page_owner.c
> @@ -252,10 +252,11 @@ print_page_owner(char __user *buf, size_t count, 
> unsigned long pfn,
>   if (ret >= count)
>   goto err;
>  
> - depot_fetch_stack(handle, );
> - ret += snprint_stack_trace(kbuf + ret, count - ret, , 0);
> - if (ret >= count)
> - goto err;
> + if (depot_fetch_stack(handle, )) {
> + ret += snprint_stack_trace(kbuf + ret, count - ret, , 0);
> + if (ret >= count)
> + goto err;
> + }

Please do 'goto err' if depot_fetch_stack() return false here.

Others looks fine to me.

Thanks.

Re: [PATCH] kasan: make depot_fetch_stack more robust

[Joonsoo Kim]

On Fri, Jul 01, 2016 at 07:38:18PM +0200, Dmitry Vyukov wrote:
> I've hit a GPF in depot_fetch_stack when it was given
> bogus stack handle. I think it was caused by a distant
> out-of-bounds that hit a different object, as the result
> we treated uninit garbage as stack handle. Maybe there is
> something to fix in KASAN logic, but I think it makes
> sense to make depot_fetch_stack more robust as well.
> 
> Verify that the provided stack handle looks correct.
> 
> Signed-off-by: Dmitry Vyukov 
> ---
> For your convenience uploaded to codereview:
> https://codereview.appspot.com/295680043
> 
> ---
>  include/linux/stackdepot.h |  2 +-
>  lib/stackdepot.c   | 21 +
>  mm/kasan/report.c  | 10 --
>  mm/page_owner.c| 12 ++--
>  4 files changed, 28 insertions(+), 17 deletions(-)
> 
> diff --git a/include/linux/stackdepot.h b/include/linux/stackdepot.h
> index 7978b3e..b2dbe02 100644
> --- a/include/linux/stackdepot.h
> +++ b/include/linux/stackdepot.h
> @@ -27,6 +27,6 @@ struct stack_trace;
>  
>  depot_stack_handle_t depot_save_stack(struct stack_trace *trace, gfp_t 
> flags);
>  
> -void depot_fetch_stack(depot_stack_handle_t handle, struct stack_trace 
> *trace);
> +bool depot_fetch_stack(depot_stack_handle_t handle, struct stack_trace 
> *trace);
>  
>  #endif
> diff --git a/lib/stackdepot.c b/lib/stackdepot.c
> index 53ad6c0..0982331 100644
> --- a/lib/stackdepot.c
> +++ b/lib/stackdepot.c
> @@ -181,16 +181,29 @@ static inline struct stack_record *find_stack(struct 
> stack_record *bucket,
>   return NULL;
>  }
>  
> -void depot_fetch_stack(depot_stack_handle_t handle, struct stack_trace 
> *trace)
> +bool depot_fetch_stack(depot_stack_handle_t handle, struct stack_trace 
> *trace)
>  {
>   union handle_parts parts = { .handle = handle };
> - void *slab = stack_slabs[parts.slabindex];
> - size_t offset = parts.offset << STACK_ALLOC_ALIGN;
> - struct stack_record *stack = slab + offset;
> + void *slab;
> + struct stack_record *stack;
>  
> + if (handle == 0)
> + return false;
> + if (parts.valid != 1 || parts.slabindex >= ARRAY_SIZE(stack_slabs))
> + goto bad;
> + slab = stack_slabs[parts.slabindex];
> + if (slab == NULL)
> + goto bad;
> + stack = slab + (parts.offset << STACK_ALLOC_ALIGN);
> + if (stack->handle.handle != handle)
> + goto bad;
>   trace->nr_entries = trace->max_entries = stack->size;
>   trace->entries = stack->entries;
>   trace->skip = 0;
> + return true;
> +bad:
> + pr_err("stackdepot: fetching bogus stack %x\n", handle);
> + return false;
>  }
>  
>  /**
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index 861b977..46e4b82 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -118,15 +118,13 @@ static inline bool init_task_stack_addr(const void 
> *addr)
>  
>  static void print_track(struct kasan_track *track)
>  {
> - pr_err("PID = %u\n", track->pid);
> - if (track->stack) {
> - struct stack_trace trace;
> + struct stack_trace trace;
>  
> - depot_fetch_stack(track->stack, );
> + pr_err("PID = %u\n", track->pid);
> + if (depot_fetch_stack(track->stack, ))
>   print_stack_trace(, 0);
> - } else {
> + else
>   pr_err("(stack is not available)\n");
> - }
>  }
>  
>  static void kasan_object_err(struct kmem_cache *cache, struct page *page,
> diff --git a/mm/page_owner.c b/mm/page_owner.c
> index 8fa5083..1862f05 100644
> --- a/mm/page_owner.c
> +++ b/mm/page_owner.c
> @@ -252,10 +252,11 @@ print_page_owner(char __user *buf, size_t count, 
> unsigned long pfn,
>   if (ret >= count)
>   goto err;
>  
> - depot_fetch_stack(handle, );
> - ret += snprint_stack_trace(kbuf + ret, count - ret, , 0);
> - if (ret >= count)
> - goto err;
> + if (depot_fetch_stack(handle, )) {
> + ret += snprint_stack_trace(kbuf + ret, count - ret, , 0);
> + if (ret >= count)
> + goto err;
> + }

Please do 'goto err' if depot_fetch_stack() return false here.

Others looks fine to me.

Thanks.

Re: [PATCH 00/31] Move LRU page reclaim from zones to nodes v8

[Mel Gorman]

On Mon, Jul 04, 2016 at 10:37:03AM +0900, Minchan Kim wrote:
> > The reason we have zone-based reclaim is that we used to have
> > large highmem zones in common configurations and it was necessary
> > to quickly find ZONE_NORMAL pages for reclaim. Today, this is much
> > less of a concern as machines with lots of memory will (or should) use
> > 64-bit kernels. Combinations of 32-bit hardware and 64-bit hardware are
> > rare. Machines that do use highmem should have relatively low highmem:lowmem
> > ratios than we worried about in the past.
> 
> Hello Mel,
> 
> I agree the direction absolutely. However, I have a concern on highmem
> system as you already mentioned.
> 
> Embedded products still use 2 ~ 3 ratio (highmem:lowmem).
> In such system, LRU churning by skipping other zone pages frequently
> might be significant for the performance.
> 
> How big ratio between highmem:lowmem do you think a problem?
> 

That's a "how long is a piece of string" type question.  The ratio does
not matter as much as whether the workload is both under memory pressure
and requires large amounts of lowmem pages. Even on systems with very high
ratios, it may not be a problem if HIGHPTE is enabled.

> > 
> > Conceptually, moving to node LRUs should be easier to understand. The
> > page allocator plays fewer tricks to game reclaim and reclaim behaves
> > similarly on all nodes. 
> > 
> > The series has been tested on a 16 core UMA machine and a 2-socket 48
> > core NUMA machine. The UMA results are presented in most cases as the NUMA
> > machine behaved similarly.
> 
> I guess you would already test below with various highmem system(e.g.,
> 2:1, 3:1, 4:1 and so on). If you have, could you mind sharing it?
> 

I haven't that data, the baseline distribution used doesn't even have
32-bit support. Even if it was, the results may not be that interesting.
The workloads used were not necessarily going to trigger lowmem pressure
as HIGHPTE was set on the 32-bit configs.

The skip logic has been checked and it does work. This was done during 
development, by forcing the "wrong" reclaim index to use. It was
noticable in system CPU usage and in the "skip" stats. I didn't preserve
this data.

> >  4.7.0-rc4   4.7.0-rc4
> >   mmotm-20160623nodelru-v8
> > Minor Faults645838  644036
> > Major Faults   573 593
> > Swap Ins 0   0
> > Swap Outs0   0
> > Allocation stalls   24   0
> > DMA allocs   0   0
> > DMA32 allocs  4604145344154171
> > Normal allocs 7805307279865782
> > Movable allocs   0   0
> > Direct pages scanned 10969   54504
> > Kswapd pages scanned  9337514493250583
> > Kswapd pages reclaimed9337224393247714
> > Direct pages reclaimed   10969   54504
> > Kswapd efficiency  99% 99%
> > Kswapd velocity  13741.015   13711.950
> > Direct efficiency 100%100%
> > Direct velocity  1.614   8.014
> > Percentage direct scans 0%  0%
> > Zone normal velocity  8641.875   13719.964
> > Zone dma32 velocity   5100.754   0.000
> > Zone dma velocity0.000   0.000
> > Page writes by reclaim   0.000   0.000
> > Page writes file 0   0
> > Page writes anon 0   0
> > Page reclaim immediate  37  54
> > 
> > kswapd activity was roughly comparable. There were differences in direct
> > reclaim activity but negligible in the context of the overall workload
> > (velocity of 8 pages per second with the patches applied, 1.6 pages per
> > second in the baseline kernel).
> 
> Hmm, nodelru's allocation stall is zero above but how does direct page
> scanning/reclaimed happens?
> 

Good spot, it's because I used the wrong comparison script -- one that
doesn't understand the different skip and allocation stats and I was
looking primarily at the scanning activity. This is a correct version

 4.7.0-rc4   4.7.0-rc4
  mmotm-20160623nodelru-v8r26
Minor Faults645838  643815
Major Faults   573 493
Swap Ins 0   0
Swap Outs0   0
DMA allocs   0   0
DMA32 allocs  4604145344174923
Normal allocs 7805307279816443
Movable allocs   0   0
Allocation stalls   24  31
Stall zone DMA   0   0
Stall zone DMA32 0   0
Stall zone Normal0   1
Stall 

Re: [PATCH 00/31] Move LRU page reclaim from zones to nodes v8

[Mel Gorman]

On Mon, Jul 04, 2016 at 10:37:03AM +0900, Minchan Kim wrote:
> > The reason we have zone-based reclaim is that we used to have
> > large highmem zones in common configurations and it was necessary
> > to quickly find ZONE_NORMAL pages for reclaim. Today, this is much
> > less of a concern as machines with lots of memory will (or should) use
> > 64-bit kernels. Combinations of 32-bit hardware and 64-bit hardware are
> > rare. Machines that do use highmem should have relatively low highmem:lowmem
> > ratios than we worried about in the past.
> 
> Hello Mel,
> 
> I agree the direction absolutely. However, I have a concern on highmem
> system as you already mentioned.
> 
> Embedded products still use 2 ~ 3 ratio (highmem:lowmem).
> In such system, LRU churning by skipping other zone pages frequently
> might be significant for the performance.
> 
> How big ratio between highmem:lowmem do you think a problem?
> 

That's a "how long is a piece of string" type question.  The ratio does
not matter as much as whether the workload is both under memory pressure
and requires large amounts of lowmem pages. Even on systems with very high
ratios, it may not be a problem if HIGHPTE is enabled.

> > 
> > Conceptually, moving to node LRUs should be easier to understand. The
> > page allocator plays fewer tricks to game reclaim and reclaim behaves
> > similarly on all nodes. 
> > 
> > The series has been tested on a 16 core UMA machine and a 2-socket 48
> > core NUMA machine. The UMA results are presented in most cases as the NUMA
> > machine behaved similarly.
> 
> I guess you would already test below with various highmem system(e.g.,
> 2:1, 3:1, 4:1 and so on). If you have, could you mind sharing it?
> 

I haven't that data, the baseline distribution used doesn't even have
32-bit support. Even if it was, the results may not be that interesting.
The workloads used were not necessarily going to trigger lowmem pressure
as HIGHPTE was set on the 32-bit configs.

The skip logic has been checked and it does work. This was done during 
development, by forcing the "wrong" reclaim index to use. It was
noticable in system CPU usage and in the "skip" stats. I didn't preserve
this data.

> >  4.7.0-rc4   4.7.0-rc4
> >   mmotm-20160623nodelru-v8
> > Minor Faults645838  644036
> > Major Faults   573 593
> > Swap Ins 0   0
> > Swap Outs0   0
> > Allocation stalls   24   0
> > DMA allocs   0   0
> > DMA32 allocs  4604145344154171
> > Normal allocs 7805307279865782
> > Movable allocs   0   0
> > Direct pages scanned 10969   54504
> > Kswapd pages scanned  9337514493250583
> > Kswapd pages reclaimed9337224393247714
> > Direct pages reclaimed   10969   54504
> > Kswapd efficiency  99% 99%
> > Kswapd velocity  13741.015   13711.950
> > Direct efficiency 100%100%
> > Direct velocity  1.614   8.014
> > Percentage direct scans 0%  0%
> > Zone normal velocity  8641.875   13719.964
> > Zone dma32 velocity   5100.754   0.000
> > Zone dma velocity0.000   0.000
> > Page writes by reclaim   0.000   0.000
> > Page writes file 0   0
> > Page writes anon 0   0
> > Page reclaim immediate  37  54
> > 
> > kswapd activity was roughly comparable. There were differences in direct
> > reclaim activity but negligible in the context of the overall workload
> > (velocity of 8 pages per second with the patches applied, 1.6 pages per
> > second in the baseline kernel).
> 
> Hmm, nodelru's allocation stall is zero above but how does direct page
> scanning/reclaimed happens?
> 

Good spot, it's because I used the wrong comparison script -- one that
doesn't understand the different skip and allocation stats and I was
looking primarily at the scanning activity. This is a correct version

 4.7.0-rc4   4.7.0-rc4
  mmotm-20160623nodelru-v8r26
Minor Faults645838  643815
Major Faults   573 493
Swap Ins 0   0
Swap Outs0   0
DMA allocs   0   0
DMA32 allocs  4604145344174923
Normal allocs 7805307279816443
Movable allocs   0   0
Allocation stalls   24  31
Stall zone DMA   0   0
Stall zone DMA32 0   0
Stall zone Normal0   1
Stall 

Re: [RFC 08/12] lockdep: Apply crossrelease to PG_locked lock

[Byungchul Park]

On Fri, Jul 01, 2016 at 02:18:46PM +0300, Kirill A. Shutemov wrote:
> On Fri, Jul 01, 2016 at 08:21:21AM +0900, Byungchul Park wrote:
> > On Thu, Jun 30, 2016 at 03:04:58PM +0200, Peter Zijlstra wrote:
> > > On Mon, Jun 20, 2016 at 01:55:23PM +0900, Byungchul Park wrote:
> > > > @@ -215,6 +219,11 @@ struct page {
> > > >  #ifdef LAST_CPUPID_NOT_IN_PAGE_FLAGS
> > > > int _last_cpupid;
> > > >  #endif
> > > > +
> > > > +#ifdef CONFIG_LOCKDEP_PAGELOCK
> > > > +   struct lockdep_map map;
> > > > +   struct cross_lock xlock;
> > > > +#endif
> > > >  }
> > > 
> > > So that's 32+64=96 bytes (CONFIG_LOCK_STAT=n) added to struct page,
> > > really!?
> > 
> > Yes... I concerned it at first, but I thought it would be ok since
> > CONFIG_LOCKDEP_PAGE is a debug feature. Anyway, I will try to reduce
> > the size of struct cross_lock which is only thing I can do to reduce
> > it, since we cannot avoid using lockdep_map if we want to make
> > lock_page() participate in the lockdep play.
> 
> Please use page_ext instead. With boottime switch to enable.
> 
> This way we can have this compile-time debug option enabled on more
> machines without unnecessary runtime overhead.

Thank you for advice.

I also think it's one of good candidates except the fact that it have to
depend on page_ext additionally.

> 
> And, please, CC linux-mm next time.
> 
> -- 
>  Kirill A. Shutemov

Re: [PATCH v3] kasan/quarantine: fix bugs on qlist_move_cache()

[Joonsoo Kim]

On Fri, Jul 01, 2016 at 05:17:10PM +0300, Andrey Ryabinin wrote:
> 
> 
> On 07/01/2016 05:02 PM, js1...@gmail.com wrote:
> > From: Joonsoo Kim 
> > 
> > There are two bugs on qlist_move_cache(). One is that qlist's tail
> > isn't set properly. curr->next can be NULL since it is singly linked
> > list and NULL value on tail is invalid if there is one item on qlist.
> > Another one is that if cache is matched, qlist_put() is called and
> > it will set curr->next to NULL. It would cause to stop the loop
> > prematurely.
> > 
> > These problems come from complicated implementation so I'd like to
> > re-implement it completely. Implementation in this patch is really
> > simple. Iterate all qlist_nodes and put them to appropriate list.
> > 
> > Unfortunately, I got this bug sometime ago and lose oops message.
> > But, the bug looks trivial and no need to attach oops.
> > 
> > v3: fix build warning
> > 
> > Signed-off-by: Joonsoo Kim 
> > ---
> >  mm/kasan/quarantine.c | 21 +++--
> >  1 file changed, 7 insertions(+), 14 deletions(-)
> > 
> > diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> > index 4973505..cf92494 100644
> > --- a/mm/kasan/quarantine.c
> > +++ b/mm/kasan/quarantine.c
> > @@ -238,30 +238,23 @@ static void qlist_move_cache(struct qlist_head *from,
> >struct qlist_head *to,
> >struct kmem_cache *cache)
> >  {
> > -   struct qlist_node *prev = NULL, *curr;
> > +   struct qlist_node *curr;
> >  
> > if (unlikely(qlist_empty(from)))
> > return;
> >  
> > curr = from->head;
> > +   qlist_init(from);
> > while (curr) {
> > struct qlist_node *qlink = curr;
> 
> Can you please also get rid of either qlink or curr.
> Those are essentially the same pointers.

Hello,

Before putting the qlist_node to the list, we need to calculate
curr->next and remember it to iterate the list. I use curr
for this purpose so qlink and curr are not the same pointer.

Thanks.

Re: [RFC 08/12] lockdep: Apply crossrelease to PG_locked lock

[Byungchul Park]

On Fri, Jul 01, 2016 at 02:18:46PM +0300, Kirill A. Shutemov wrote:
> On Fri, Jul 01, 2016 at 08:21:21AM +0900, Byungchul Park wrote:
> > On Thu, Jun 30, 2016 at 03:04:58PM +0200, Peter Zijlstra wrote:
> > > On Mon, Jun 20, 2016 at 01:55:23PM +0900, Byungchul Park wrote:
> > > > @@ -215,6 +219,11 @@ struct page {
> > > >  #ifdef LAST_CPUPID_NOT_IN_PAGE_FLAGS
> > > > int _last_cpupid;
> > > >  #endif
> > > > +
> > > > +#ifdef CONFIG_LOCKDEP_PAGELOCK
> > > > +   struct lockdep_map map;
> > > > +   struct cross_lock xlock;
> > > > +#endif
> > > >  }
> > > 
> > > So that's 32+64=96 bytes (CONFIG_LOCK_STAT=n) added to struct page,
> > > really!?
> > 
> > Yes... I concerned it at first, but I thought it would be ok since
> > CONFIG_LOCKDEP_PAGE is a debug feature. Anyway, I will try to reduce
> > the size of struct cross_lock which is only thing I can do to reduce
> > it, since we cannot avoid using lockdep_map if we want to make
> > lock_page() participate in the lockdep play.
> 
> Please use page_ext instead. With boottime switch to enable.
> 
> This way we can have this compile-time debug option enabled on more
> machines without unnecessary runtime overhead.

Thank you for advice.

I also think it's one of good candidates except the fact that it have to
depend on page_ext additionally.

> 
> And, please, CC linux-mm next time.
> 
> -- 
>  Kirill A. Shutemov

Re: [PATCH v3] kasan/quarantine: fix bugs on qlist_move_cache()

[Joonsoo Kim]

On Fri, Jul 01, 2016 at 05:17:10PM +0300, Andrey Ryabinin wrote:
> 
> 
> On 07/01/2016 05:02 PM, js1...@gmail.com wrote:
> > From: Joonsoo Kim 
> > 
> > There are two bugs on qlist_move_cache(). One is that qlist's tail
> > isn't set properly. curr->next can be NULL since it is singly linked
> > list and NULL value on tail is invalid if there is one item on qlist.
> > Another one is that if cache is matched, qlist_put() is called and
> > it will set curr->next to NULL. It would cause to stop the loop
> > prematurely.
> > 
> > These problems come from complicated implementation so I'd like to
> > re-implement it completely. Implementation in this patch is really
> > simple. Iterate all qlist_nodes and put them to appropriate list.
> > 
> > Unfortunately, I got this bug sometime ago and lose oops message.
> > But, the bug looks trivial and no need to attach oops.
> > 
> > v3: fix build warning
> > 
> > Signed-off-by: Joonsoo Kim 
> > ---
> >  mm/kasan/quarantine.c | 21 +++--
> >  1 file changed, 7 insertions(+), 14 deletions(-)
> > 
> > diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> > index 4973505..cf92494 100644
> > --- a/mm/kasan/quarantine.c
> > +++ b/mm/kasan/quarantine.c
> > @@ -238,30 +238,23 @@ static void qlist_move_cache(struct qlist_head *from,
> >struct qlist_head *to,
> >struct kmem_cache *cache)
> >  {
> > -   struct qlist_node *prev = NULL, *curr;
> > +   struct qlist_node *curr;
> >  
> > if (unlikely(qlist_empty(from)))
> > return;
> >  
> > curr = from->head;
> > +   qlist_init(from);
> > while (curr) {
> > struct qlist_node *qlink = curr;
> 
> Can you please also get rid of either qlink or curr.
> Those are essentially the same pointers.

Hello,

Before putting the qlist_node to the list, we need to calculate
curr->next and remember it to iterate the list. I use curr
for this purpose so qlink and curr are not the same pointer.

Thanks.

[PATCH v4] kasan/quarantine: fix bugs on qlist_move_cache()

[js1304]

From: Joonsoo Kim 

There are two bugs on qlist_move_cache(). One is that qlist's tail
isn't set properly. curr->next can be NULL since it is singly linked
list and NULL value on tail is invalid if there is one item on qlist.
Another one is that if cache is matched, qlist_put() is called and
it will set curr->next to NULL. It would cause to stop the loop
prematurely.

These problems come from complicated implementation so I'd like to
re-implement it completely. Implementation in this patch is really
simple. Iterate all qlist_nodes and put them to appropriate list.

Unfortunately, I got this bug sometime ago and lose oops message.
But, the bug looks trivial and no need to attach oops.

v4: fix cache size bug s/cache->size/obj_cache->size/
v3: fix build warning

Signed-off-by: Joonsoo Kim 
---
 mm/kasan/quarantine.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
index 4973505..b2e1827 100644
--- a/mm/kasan/quarantine.c
+++ b/mm/kasan/quarantine.c
@@ -238,30 +238,23 @@ static void qlist_move_cache(struct qlist_head *from,
   struct qlist_head *to,
   struct kmem_cache *cache)
 {
-   struct qlist_node *prev = NULL, *curr;
+   struct qlist_node *curr;
 
if (unlikely(qlist_empty(from)))
return;
 
curr = from->head;
+   qlist_init(from);
while (curr) {
struct qlist_node *qlink = curr;
struct kmem_cache *obj_cache = qlink_to_cache(qlink);
 
-   if (obj_cache == cache) {
-   if (unlikely(from->head == qlink)) {
-   from->head = curr->next;
-   prev = curr;
-   } else
-   prev->next = curr->next;
-   if (unlikely(from->tail == qlink))
-   from->tail = curr->next;
-   from->bytes -= cache->size;
-   qlist_put(to, qlink, cache->size);
-   } else {
-   prev = curr;
-   }
curr = curr->next;
+
+   if (obj_cache == cache)
+   qlist_put(to, qlink, obj_cache->size);
+   else
+   qlist_put(from, qlink, obj_cache->size);
}
 }
 
-- 
1.9.1

Re: linux-next: build failure after merge of the lightnvm tree

[Stephen Rothwell]

Hi Matias,

On Thu, 30 Jun 2016 12:56:35 +1000 Stephen Rothwell  
wrote:
>
> After merging the lightnvm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: "nvm_alloc_dev" [drivers/nvme/host/nvme-core.ko] undefined!
> ERROR: "nvm_alloc_dev" [drivers/block/null_blk.ko] undefined!
> 
> Caused by commit
> 
>   3daf1adc80a8 ("lightnvm: let drivers control the lifetime of nvm_dev")
> 
> I have used the lightnvm tree from next-20160629 for today.

I am still getting this error.

-- 
Cheers,
Stephen Rothwell

[PATCH v4] kasan/quarantine: fix bugs on qlist_move_cache()

[js1304]

From: Joonsoo Kim 

There are two bugs on qlist_move_cache(). One is that qlist's tail
isn't set properly. curr->next can be NULL since it is singly linked
list and NULL value on tail is invalid if there is one item on qlist.
Another one is that if cache is matched, qlist_put() is called and
it will set curr->next to NULL. It would cause to stop the loop
prematurely.

These problems come from complicated implementation so I'd like to
re-implement it completely. Implementation in this patch is really
simple. Iterate all qlist_nodes and put them to appropriate list.

Unfortunately, I got this bug sometime ago and lose oops message.
But, the bug looks trivial and no need to attach oops.

v4: fix cache size bug s/cache->size/obj_cache->size/
v3: fix build warning

Signed-off-by: Joonsoo Kim 
---
 mm/kasan/quarantine.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
index 4973505..b2e1827 100644
--- a/mm/kasan/quarantine.c
+++ b/mm/kasan/quarantine.c
@@ -238,30 +238,23 @@ static void qlist_move_cache(struct qlist_head *from,
   struct qlist_head *to,
   struct kmem_cache *cache)
 {
-   struct qlist_node *prev = NULL, *curr;
+   struct qlist_node *curr;
 
if (unlikely(qlist_empty(from)))
return;
 
curr = from->head;
+   qlist_init(from);
while (curr) {
struct qlist_node *qlink = curr;
struct kmem_cache *obj_cache = qlink_to_cache(qlink);
 
-   if (obj_cache == cache) {
-   if (unlikely(from->head == qlink)) {
-   from->head = curr->next;
-   prev = curr;
-   } else
-   prev->next = curr->next;
-   if (unlikely(from->tail == qlink))
-   from->tail = curr->next;
-   from->bytes -= cache->size;
-   qlist_put(to, qlink, cache->size);
-   } else {
-   prev = curr;
-   }
curr = curr->next;
+
+   if (obj_cache == cache)
+   qlist_put(to, qlink, obj_cache->size);
+   else
+   qlist_put(from, qlink, obj_cache->size);
}
 }
 
-- 
1.9.1

Re: linux-next: build failure after merge of the lightnvm tree

[Stephen Rothwell]

Hi Matias,

On Thu, 30 Jun 2016 12:56:35 +1000 Stephen Rothwell  
wrote:
>
> After merging the lightnvm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: "nvm_alloc_dev" [drivers/nvme/host/nvme-core.ko] undefined!
> ERROR: "nvm_alloc_dev" [drivers/block/null_blk.ko] undefined!
> 
> Caused by commit
> 
>   3daf1adc80a8 ("lightnvm: let drivers control the lifetime of nvm_dev")
> 
> I have used the lightnvm tree from next-20160629 for today.

I am still getting this error.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH 3/4] x86: disallow running with 32-bit PTEs to work around erratum

[Hillf Danton]

> 
> The Intel(R) Xeon Phi(TM) Processor x200 Family (codename: Knights
> Landing) has an erratum where a processor thread setting the Accessed
> or Dirty bits may not do so atomically against its checks for the
> Present bit.  This may cause a thread (which is about to page fault)
> to set A and/or D, even though the Present bit had already been
> atomically cleared.
> 
> If the PTE is used for storing a swap index or a NUMA migration index,
> the A bit could be misinterpreted as part of the swap type.  The stray
> bits being set cause a software-cleared PTE to be interpreted as a
> swap entry.  In some cases (like when the swap index ends up being
> for a non-existent swapfile), the kernel detects the stray value
> and WARN()s about it, but there is no guarantee that the kernel can
> always detect it.
> 
> When we have 64-bit PTEs (64-bit mode or 32-bit PAE), we were able
> to move the swap PTE format around to avoid these troublesome bits.
> But, 32-bit non-PAE is tight on bits.  So, disallow it from running
> on this hardware.  I can't imagine anyone wanting to run 32-bit
> on this hardware, but this is the safe thing to do.
> 
> ---



Isn't this work from Mr. Tlb?
>
>  b/arch/x86/boot/boot.h |1 +
>  b/arch/x86/boot/cpu.c  |2 ++
>  b/arch/x86/boot/cpucheck.c |   32 
>  b/arch/x86/boot/cpuflags.c |1 +
>  b/arch/x86/boot/cpuflags.h |1 +
>  5 files changed, 37 insertions(+)
> 
> diff -puN arch/x86/boot/boot.h~knl-strays-40-disallow-non-PAE-32-bit-on-KNL \
> arch/x86/boot/boot.h
> --- a/arch/x86/boot/boot.h~knl-strays-40-disallow-non-PAE-32-bit-on-KNL   
> 2016-07-01 \
> 10:42:07.302790241 -0700
> +++ b/arch/x86/boot/boot.h2016-07-01 10:42:07.311790650 -0700
> @@ -295,6 +295,7 @@ static inline int cmdline_find_option_bo
> 
>  /* cpu.c, cpucheck.c */
>  int check_cpu(int *cpu_level_ptr, int *req_level_ptr, u32 **err_flags_ptr);
> +int check_knl_erratum(void);
>  int validate_cpu(void);
> 
>  /* early_serial_console.c */
> diff -puN arch/x86/boot/cpu.c~knl-strays-40-disallow-non-PAE-32-bit-on-KNL \
> arch/x86/boot/cpu.c
> --- a/arch/x86/boot/cpu.c~knl-strays-40-disallow-non-PAE-32-bit-on-KNL
> 2016-07-01 \
> 10:42:07.303790286 -0700
> +++ b/arch/x86/boot/cpu.c 2016-07-01 10:42:07.312790695 -0700
> @@ -93,6 +93,8 @@ int validate_cpu(void)
>   show_cap_strs(err_flags);
>   putchar('\n');
>   return -1;
> + } else if (check_knl_erratum()) {
> + return -1;
>   } else {
>   return 0;
>   }
> diff -puN 
> arch/x86/boot/cpucheck.c~knl-strays-40-disallow-non-PAE-32-bit-on-KNL \
> arch/x86/boot/cpucheck.c
> --- a/arch/x86/boot/cpucheck.c~knl-strays-40-disallow-non-PAE-32-bit-on-KNL   
> 2016-07-01 \
> 10:42:07.305790377 -0700
> +++ b/arch/x86/boot/cpucheck.c2016-07-01 10:42:07.312790695 -0700
> @@ -24,6 +24,7 @@
>  # include "boot.h"
>  #endif
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -175,6 +176,8 @@ int check_cpu(int *cpu_level_ptr, int *r
>   puts("WARNING: PAE disabled. Use parameter 'forcepae' 
> to enable at your own \
> risk!\n");  }
>   }
> + if (!err)
> + err = check_knl_erratum();
> 
>   if (err_flags_ptr)
>   *err_flags_ptr = err ? err_flags : NULL;
> @@ -185,3 +188,32 @@ int check_cpu(int *cpu_level_ptr, int *r
> 
>   return (cpu.level < req_level || err) ? -1 : 0;
>  }
> +
> +int check_knl_erratum(void)

s/knl/xeon_knl/ ?
> +{
> + /*
> +  * First check for the affected model/family:
> +  */
> + if (!is_intel() ||
> + cpu.family != 6 ||
> + cpu.model != INTEL_FAM6_XEON_PHI_KNL)
> + return 0;
> +
> + /*
> +  * This erratum affects the Accessed/Dirty bits, and can
> +  * cause stray bits to be set in !Present PTEs.  We have
> +  * enough bits in our 64-bit PTEs (which we have on real
> +  * 64-bit mode or PAE) to avoid using these troublesome
> +  * bits.  But, we do not have enough soace in our 32-bit
> +  * PTEs.  So, refuse to run on 32-bit non-PAE kernels.
> +  */
> + if (IS_ENABLED(CONFIG_X86_64) || IS_ENABLED(CONFIG_X86_PAE))
> + return 0;
> +
> + puts("This 32-bit kernel can not run on this processor due\n"
> +  "to a processor erratum.  Use a 64-bit kernel, or PAE.\n\n");

Give processor name to the scared readers please.

> +
> + return -1;
> +}
> +
> +
> diff -puN 
> arch/x86/boot/cpuflags.c~knl-strays-40-disallow-non-PAE-32-bit-on-KNL \
> arch/x86/boot/cpuflags.c
> --- a/arch/x86/boot/cpuflags.c~knl-strays-40-disallow-non-PAE-32-bit-on-KNL   
> 2016-07-01 \
> 10:42:07.307790468 -0700
> +++ b/arch/x86/boot/cpuflags.c2016-07-01 10:42:07.312790695 -0700
> @@ -102,6 +102,7 @@ void get_cpuflags(void)
>

Re: [PATCH v3 0/2] mark spi clocks as critical and enable spi3 clocks

[Andi Shyti]

Hi Tomasz,

> > This patchset enables spi3 clocks by marking critical clocks as
> > CLK_IS_CRITICAL and in the meantime replaces the use of
> > CLK_IGNORE_UNUSED for spi1 clocks.
> >
> > The sclk needs to be considered critical as well.
> >
> > The SPI3 in the tm2/tm2e boards will control an irled for remote
> > controlling.
> >
> > Changelog:
> >
> > V1 -> V2
> >  - the "sclk_spi3" doesn't need to be enabled in boot time as it
> >   is handled by the spi driver itself.
> >
> >  - use the CLK_IS_CRITICAL flag for the ioclk
> >
> > V2 -> V3
> >  - some more tests has confirmed taht "sclk_spi1,3" need to be
> >enabled as critical!
> 
> This sounds like a DTS and/or SPI and/or clock driver bug then. I'm
> pretty much convinced that it might also cause other problems and this
> workaround will only mask them making things even more difficult to
> debug in the future. Let's not introduce more technical debt.

In principle I agree, but, the upcoming TM2/TM2e boards will have
the audio codec connected on SPI1 and the ir remote controller on
the SPI3 (others SPI slots are used as well, but we don't have
the drivers ready for them).

I followed for SPI3 the same approach as it was done for SPI1, so
that I see two choices here:

 * reject this patches and cleanup the SPI1 from the "technical
   debt" and not have anything working on spi.

or

 * do for SPI3 the same as it has been done for SPI1 (and as it
   is now) with its "technical debt".

I did quite an extensive testing on these lines and I don't see
any other alternative.

Thanks,
Andi

Re: [PATCH 3/4] x86: disallow running with 32-bit PTEs to work around erratum

[Hillf Danton]

> 
> The Intel(R) Xeon Phi(TM) Processor x200 Family (codename: Knights
> Landing) has an erratum where a processor thread setting the Accessed
> or Dirty bits may not do so atomically against its checks for the
> Present bit.  This may cause a thread (which is about to page fault)
> to set A and/or D, even though the Present bit had already been
> atomically cleared.
> 
> If the PTE is used for storing a swap index or a NUMA migration index,
> the A bit could be misinterpreted as part of the swap type.  The stray
> bits being set cause a software-cleared PTE to be interpreted as a
> swap entry.  In some cases (like when the swap index ends up being
> for a non-existent swapfile), the kernel detects the stray value
> and WARN()s about it, but there is no guarantee that the kernel can
> always detect it.
> 
> When we have 64-bit PTEs (64-bit mode or 32-bit PAE), we were able
> to move the swap PTE format around to avoid these troublesome bits.
> But, 32-bit non-PAE is tight on bits.  So, disallow it from running
> on this hardware.  I can't imagine anyone wanting to run 32-bit
> on this hardware, but this is the safe thing to do.
> 
> ---



Isn't this work from Mr. Tlb?
>
>  b/arch/x86/boot/boot.h |1 +
>  b/arch/x86/boot/cpu.c  |2 ++
>  b/arch/x86/boot/cpucheck.c |   32 
>  b/arch/x86/boot/cpuflags.c |1 +
>  b/arch/x86/boot/cpuflags.h |1 +
>  5 files changed, 37 insertions(+)
> 
> diff -puN arch/x86/boot/boot.h~knl-strays-40-disallow-non-PAE-32-bit-on-KNL \
> arch/x86/boot/boot.h
> --- a/arch/x86/boot/boot.h~knl-strays-40-disallow-non-PAE-32-bit-on-KNL   
> 2016-07-01 \
> 10:42:07.302790241 -0700
> +++ b/arch/x86/boot/boot.h2016-07-01 10:42:07.311790650 -0700
> @@ -295,6 +295,7 @@ static inline int cmdline_find_option_bo
> 
>  /* cpu.c, cpucheck.c */
>  int check_cpu(int *cpu_level_ptr, int *req_level_ptr, u32 **err_flags_ptr);
> +int check_knl_erratum(void);
>  int validate_cpu(void);
> 
>  /* early_serial_console.c */
> diff -puN arch/x86/boot/cpu.c~knl-strays-40-disallow-non-PAE-32-bit-on-KNL \
> arch/x86/boot/cpu.c
> --- a/arch/x86/boot/cpu.c~knl-strays-40-disallow-non-PAE-32-bit-on-KNL
> 2016-07-01 \
> 10:42:07.303790286 -0700
> +++ b/arch/x86/boot/cpu.c 2016-07-01 10:42:07.312790695 -0700
> @@ -93,6 +93,8 @@ int validate_cpu(void)
>   show_cap_strs(err_flags);
>   putchar('\n');
>   return -1;
> + } else if (check_knl_erratum()) {
> + return -1;
>   } else {
>   return 0;
>   }
> diff -puN 
> arch/x86/boot/cpucheck.c~knl-strays-40-disallow-non-PAE-32-bit-on-KNL \
> arch/x86/boot/cpucheck.c
> --- a/arch/x86/boot/cpucheck.c~knl-strays-40-disallow-non-PAE-32-bit-on-KNL   
> 2016-07-01 \
> 10:42:07.305790377 -0700
> +++ b/arch/x86/boot/cpucheck.c2016-07-01 10:42:07.312790695 -0700
> @@ -24,6 +24,7 @@
>  # include "boot.h"
>  #endif
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -175,6 +176,8 @@ int check_cpu(int *cpu_level_ptr, int *r
>   puts("WARNING: PAE disabled. Use parameter 'forcepae' 
> to enable at your own \
> risk!\n");  }
>   }
> + if (!err)
> + err = check_knl_erratum();
> 
>   if (err_flags_ptr)
>   *err_flags_ptr = err ? err_flags : NULL;
> @@ -185,3 +188,32 @@ int check_cpu(int *cpu_level_ptr, int *r
> 
>   return (cpu.level < req_level || err) ? -1 : 0;
>  }
> +
> +int check_knl_erratum(void)

s/knl/xeon_knl/ ?
> +{
> + /*
> +  * First check for the affected model/family:
> +  */
> + if (!is_intel() ||
> + cpu.family != 6 ||
> + cpu.model != INTEL_FAM6_XEON_PHI_KNL)
> + return 0;
> +
> + /*
> +  * This erratum affects the Accessed/Dirty bits, and can
> +  * cause stray bits to be set in !Present PTEs.  We have
> +  * enough bits in our 64-bit PTEs (which we have on real
> +  * 64-bit mode or PAE) to avoid using these troublesome
> +  * bits.  But, we do not have enough soace in our 32-bit
> +  * PTEs.  So, refuse to run on 32-bit non-PAE kernels.
> +  */
> + if (IS_ENABLED(CONFIG_X86_64) || IS_ENABLED(CONFIG_X86_PAE))
> + return 0;
> +
> + puts("This 32-bit kernel can not run on this processor due\n"
> +  "to a processor erratum.  Use a 64-bit kernel, or PAE.\n\n");

Give processor name to the scared readers please.

> +
> + return -1;
> +}
> +
> +
> diff -puN 
> arch/x86/boot/cpuflags.c~knl-strays-40-disallow-non-PAE-32-bit-on-KNL \
> arch/x86/boot/cpuflags.c
> --- a/arch/x86/boot/cpuflags.c~knl-strays-40-disallow-non-PAE-32-bit-on-KNL   
> 2016-07-01 \
> 10:42:07.307790468 -0700
> +++ b/arch/x86/boot/cpuflags.c2016-07-01 10:42:07.312790695 -0700
> @@ -102,6 +102,7 @@ void get_cpuflags(void)
>

Re: [PATCH v3 0/2] mark spi clocks as critical and enable spi3 clocks

[Andi Shyti]

Hi Tomasz,

> > This patchset enables spi3 clocks by marking critical clocks as
> > CLK_IS_CRITICAL and in the meantime replaces the use of
> > CLK_IGNORE_UNUSED for spi1 clocks.
> >
> > The sclk needs to be considered critical as well.
> >
> > The SPI3 in the tm2/tm2e boards will control an irled for remote
> > controlling.
> >
> > Changelog:
> >
> > V1 -> V2
> >  - the "sclk_spi3" doesn't need to be enabled in boot time as it
> >   is handled by the spi driver itself.
> >
> >  - use the CLK_IS_CRITICAL flag for the ioclk
> >
> > V2 -> V3
> >  - some more tests has confirmed taht "sclk_spi1,3" need to be
> >enabled as critical!
> 
> This sounds like a DTS and/or SPI and/or clock driver bug then. I'm
> pretty much convinced that it might also cause other problems and this
> workaround will only mask them making things even more difficult to
> debug in the future. Let's not introduce more technical debt.

In principle I agree, but, the upcoming TM2/TM2e boards will have
the audio codec connected on SPI1 and the ir remote controller on
the SPI3 (others SPI slots are used as well, but we don't have
the drivers ready for them).

I followed for SPI3 the same approach as it was done for SPI1, so
that I see two choices here:

 * reject this patches and cleanup the SPI1 from the "technical
   debt" and not have anything working on spi.

or

 * do for SPI3 the same as it has been done for SPI1 (and as it
   is now) with its "technical debt".

I did quite an extensive testing on these lines and I don't see
any other alternative.

Thanks,
Andi

Re: [PATCH v3 0/2] mark spi clocks as critical and enable spi3 clocks

[Tomasz Figa]

Hi Andi,

2016-06-30 16:15 GMT+09:00 Andi Shyti :
> Hi,
>
> This patchset enables spi3 clocks by marking critical clocks as
> CLK_IS_CRITICAL and in the meantime replaces the use of
> CLK_IGNORE_UNUSED for spi1 clocks.
>
> The sclk needs to be considered critical as well.
>
> The SPI3 in the tm2/tm2e boards will control an irled for remote
> controlling.
>
> Changelog:
>
> V1 -> V2
>  - the "sclk_spi3" doesn't need to be enabled in boot time as it
>   is handled by the spi driver itself.
>
>  - use the CLK_IS_CRITICAL flag for the ioclk
>
> V2 -> V3
>  - some more tests has confirmed taht "sclk_spi1,3" need to be
>enabled as critical!

This sounds like a DTS and/or SPI and/or clock driver bug then. I'm
pretty much convinced that it might also cause other problems and this
workaround will only mask them making things even more difficult to
debug in the future. Let's not introduce more technical debt.

Best regards,
Tomasz

Re: [PATCH v3 0/2] mark spi clocks as critical and enable spi3 clocks

[Tomasz Figa]

Hi Andi,

2016-06-30 16:15 GMT+09:00 Andi Shyti :
> Hi,
>
> This patchset enables spi3 clocks by marking critical clocks as
> CLK_IS_CRITICAL and in the meantime replaces the use of
> CLK_IGNORE_UNUSED for spi1 clocks.
>
> The sclk needs to be considered critical as well.
>
> The SPI3 in the tm2/tm2e boards will control an irled for remote
> controlling.
>
> Changelog:
>
> V1 -> V2
>  - the "sclk_spi3" doesn't need to be enabled in boot time as it
>   is handled by the spi driver itself.
>
>  - use the CLK_IS_CRITICAL flag for the ioclk
>
> V2 -> V3
>  - some more tests has confirmed taht "sclk_spi1,3" need to be
>enabled as critical!

This sounds like a DTS and/or SPI and/or clock driver bug then. I'm
pretty much convinced that it might also cause other problems and this
workaround will only mask them making things even more difficult to
debug in the future. Let's not introduce more technical debt.

Best regards,
Tomasz

Re: [PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

[Michel Dänzer]

On 02.07.2016 22:46, Tejun Heo wrote:
> On Sat, Jul 02, 2016 at 04:33:50PM +0530, Bhaktipriya Shridhar wrote:
>> alloc_workqueue replaces deprecated create_singlethread_workqueue().
>>
>> A dedicated workqueue has been used since work items need to be flushed
>> as a group rather than individually.
>>
>> Since the flip_queue workqueue is involved in page-flipping and is not
>> being used on a memory reclaim path, WQ_MEM_RECLAIM has not been set.
>>
>> Since there are only a fixed number of work items, explicit concurrency
>> limit is unnecessary here.
> 
> What are the involved work items?

drivers/gpu/drm/radeon/radeon_display.c:radeon_flip_work_func()


> Is it safe to run them concurrently?

Concurrently with what exactly?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: [PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

[Michel Dänzer]

On 02.07.2016 22:46, Tejun Heo wrote:
> On Sat, Jul 02, 2016 at 04:33:50PM +0530, Bhaktipriya Shridhar wrote:
>> alloc_workqueue replaces deprecated create_singlethread_workqueue().
>>
>> A dedicated workqueue has been used since work items need to be flushed
>> as a group rather than individually.
>>
>> Since the flip_queue workqueue is involved in page-flipping and is not
>> being used on a memory reclaim path, WQ_MEM_RECLAIM has not been set.
>>
>> Since there are only a fixed number of work items, explicit concurrency
>> limit is unnecessary here.
> 
> What are the involved work items?

drivers/gpu/drm/radeon/radeon_display.c:radeon_flip_work_func()


> Is it safe to run them concurrently?

Concurrently with what exactly?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

[Oleg Drokin]

On Jul 3, 2016, at 11:08 PM, Al Viro wrote:

> On Sun, Jul 03, 2016 at 08:37:22PM -0400, Oleg Drokin wrote:
> 
>> Hm… This dates to sometime in 2006 and my memory is a bit hazy here.
>> 
>> I think when we called into the open, it went into fifo open and stuck there
>> waiting for the other opener. Something like that. And we cannot really be 
>> stuck here
>> because we are holding some locks that need to be released in predictable 
>> time.
>> 
>> This code is actually unreachable now because the server never returns an 
>> openhandle
>> for special device nodes anymore (there's a comment about it in current 
>> staging tree,
>> but I guess you are looking at some prior version).
>> 
>> I imagine device nodes might have represented a similar risk too, but it did 
>> not
>> occur to me to test it separately and the testsuite does not do it either.
>> 
>> Directories do not get stuck when you open them so they are ok and we can
>> atomically open them too, I guess.
>> Symlinks are handled specially on the server and the open never returns
>> the actual open handle for those, so this path is also unreachable with 
>> those.
> 
> Hmm...  How much does the safety of client depend upon the correctness of
> server?

Quite a bit, actually. If you connect to an rogue Lustre server,
currently there are many ways it can crash the client.
I suspect this is true not just of Lustre, if e.g. NFS server starts to
send directory inodes with duplicated inode numbers or some such,
VFS would not be super happy about such "hardlinked" directories either.
This is before we even consider that it can feed you garbage data
to crash your apps (or substitute binaries to do something else).

> BTW, there's a fun issue in ll_revalidate_dentry(): there's nothing to
> promise stability of ->d_parent in there, so uses of d_inode(dentry->d_parent)

Yes, we actually had a discussion about that in March, we were not the only ones
affected, and I think it was decided that dget_parent() was a better solution
to get to the parent (I see ext4 has already converted).
I believe you cannot hit it in Lustre now due to Lustre locking magic, but
I'll create a patch to cover this anyway. Thanks for reminding me about this.

> are not safe.  That's independent from parallel lookups, and it's hard
> to hit, but AFAICS it's not impossible to oops there.
> 
> Anyway, for Lustre the analogue of that NFS problem is here:
>} else if (!it_disposition(it, DISP_LOOKUP_NEG)  &&
>   !it_disposition(it, DISP_OPEN_CREATE)) {
>/* With DISP_OPEN_CREATE dentry will be
> * instantiated in ll_create_it.
> */
>LASSERT(!d_inode(*de));
>d_instantiate(*de, inode);
>}

Hm… Do you mean that when we do come hashed here, with a negative dentry
and positive disposition and hit the assertion about inode not being NULL
(still staying negative, basically)?
This one we cannot hit because negative dentries are protected by a Lustre
dlm lock held by the parent directory. Any create in that parent directory
would invalidate the lock and once that happens, all negative dentries would
be killed.
Hmm… This probably means this is a dead code?
Ah, I guess it's not.
If we do a lookup and find this negative dentry (from 2+ threads) and THEN it 
gets invalidated and our two threads both race to instantiate it...
It does look like something that is quite hard to hit, but still looks like a 
race
that could happen.

> AFAICS, this (on top of mainline) ought to work:

Thanks, I'll give this a try.
> 
> diff --git a/drivers/staging/lustre/lustre/llite/namei.c 
> b/drivers/staging/lustre/lustre/llite/namei.c
> index 5eba0eb..b8da5b4 100644
> --- a/drivers/staging/lustre/lustre/llite/namei.c
> +++ b/drivers/staging/lustre/lustre/llite/namei.c
> @@ -581,9 +581,11 @@ static int ll_atomic_open(struct inode *dir, struct 
> dentry *dentry,
> struct file *file, unsigned open_flags,
> umode_t mode, int *opened)
> {
> + DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
>   struct lookup_intent *it;
>   struct dentry *de;
>   long long lookup_flags = LOOKUP_OPEN;
> + bool switched = false;
>   int rc = 0;
> 
>   CDEBUG(D_VFSTRACE, "VFS Op:name=%pd, dir="DFID"(%p),file %p,open_flags 
> %x,mode %x opened %d\n",
> @@ -603,11 +605,28 @@ static int ll_atomic_open(struct inode *dir, struct 
> dentry *dentry,
>   it->it_flags = (open_flags & ~O_ACCMODE) | OPEN_FMODE(open_flags);
> 
>   /* Dentry added to dcache tree in ll_lookup_it */
> + if (!(open_flags & O_CREAT) && !d_unhashed(dentry)) {
> + d_drop(dentry);
> + switched = true;
> + dentry = d_alloc_parallel(dentry->d_parent,
> +   >d_name, );
> + if (IS_ERR(dentry)) {
> + rc = PTR_ERR(dentry);
> + goto out_release;
> + }
> + if 

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

[Oleg Drokin]

On Jul 3, 2016, at 11:08 PM, Al Viro wrote:

> On Sun, Jul 03, 2016 at 08:37:22PM -0400, Oleg Drokin wrote:
> 
>> Hm… This dates to sometime in 2006 and my memory is a bit hazy here.
>> 
>> I think when we called into the open, it went into fifo open and stuck there
>> waiting for the other opener. Something like that. And we cannot really be 
>> stuck here
>> because we are holding some locks that need to be released in predictable 
>> time.
>> 
>> This code is actually unreachable now because the server never returns an 
>> openhandle
>> for special device nodes anymore (there's a comment about it in current 
>> staging tree,
>> but I guess you are looking at some prior version).
>> 
>> I imagine device nodes might have represented a similar risk too, but it did 
>> not
>> occur to me to test it separately and the testsuite does not do it either.
>> 
>> Directories do not get stuck when you open them so they are ok and we can
>> atomically open them too, I guess.
>> Symlinks are handled specially on the server and the open never returns
>> the actual open handle for those, so this path is also unreachable with 
>> those.
> 
> Hmm...  How much does the safety of client depend upon the correctness of
> server?

Quite a bit, actually. If you connect to an rogue Lustre server,
currently there are many ways it can crash the client.
I suspect this is true not just of Lustre, if e.g. NFS server starts to
send directory inodes with duplicated inode numbers or some such,
VFS would not be super happy about such "hardlinked" directories either.
This is before we even consider that it can feed you garbage data
to crash your apps (or substitute binaries to do something else).

> BTW, there's a fun issue in ll_revalidate_dentry(): there's nothing to
> promise stability of ->d_parent in there, so uses of d_inode(dentry->d_parent)

Yes, we actually had a discussion about that in March, we were not the only ones
affected, and I think it was decided that dget_parent() was a better solution
to get to the parent (I see ext4 has already converted).
I believe you cannot hit it in Lustre now due to Lustre locking magic, but
I'll create a patch to cover this anyway. Thanks for reminding me about this.

> are not safe.  That's independent from parallel lookups, and it's hard
> to hit, but AFAICS it's not impossible to oops there.
> 
> Anyway, for Lustre the analogue of that NFS problem is here:
>} else if (!it_disposition(it, DISP_LOOKUP_NEG)  &&
>   !it_disposition(it, DISP_OPEN_CREATE)) {
>/* With DISP_OPEN_CREATE dentry will be
> * instantiated in ll_create_it.
> */
>LASSERT(!d_inode(*de));
>d_instantiate(*de, inode);
>}

Hm… Do you mean that when we do come hashed here, with a negative dentry
and positive disposition and hit the assertion about inode not being NULL
(still staying negative, basically)?
This one we cannot hit because negative dentries are protected by a Lustre
dlm lock held by the parent directory. Any create in that parent directory
would invalidate the lock and once that happens, all negative dentries would
be killed.
Hmm… This probably means this is a dead code?
Ah, I guess it's not.
If we do a lookup and find this negative dentry (from 2+ threads) and THEN it 
gets invalidated and our two threads both race to instantiate it...
It does look like something that is quite hard to hit, but still looks like a 
race
that could happen.

> AFAICS, this (on top of mainline) ought to work:

Thanks, I'll give this a try.
> 
> diff --git a/drivers/staging/lustre/lustre/llite/namei.c 
> b/drivers/staging/lustre/lustre/llite/namei.c
> index 5eba0eb..b8da5b4 100644
> --- a/drivers/staging/lustre/lustre/llite/namei.c
> +++ b/drivers/staging/lustre/lustre/llite/namei.c
> @@ -581,9 +581,11 @@ static int ll_atomic_open(struct inode *dir, struct 
> dentry *dentry,
> struct file *file, unsigned open_flags,
> umode_t mode, int *opened)
> {
> + DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
>   struct lookup_intent *it;
>   struct dentry *de;
>   long long lookup_flags = LOOKUP_OPEN;
> + bool switched = false;
>   int rc = 0;
> 
>   CDEBUG(D_VFSTRACE, "VFS Op:name=%pd, dir="DFID"(%p),file %p,open_flags 
> %x,mode %x opened %d\n",
> @@ -603,11 +605,28 @@ static int ll_atomic_open(struct inode *dir, struct 
> dentry *dentry,
>   it->it_flags = (open_flags & ~O_ACCMODE) | OPEN_FMODE(open_flags);
> 
>   /* Dentry added to dcache tree in ll_lookup_it */
> + if (!(open_flags & O_CREAT) && !d_unhashed(dentry)) {
> + d_drop(dentry);
> + switched = true;
> + dentry = d_alloc_parallel(dentry->d_parent,
> +   >d_name, );
> + if (IS_ERR(dentry)) {
> + rc = PTR_ERR(dentry);
> + goto out_release;
> + }
> + if 

Re: [PATCH v9 01/10] clk: fix initial state of critical clock's parents

[James Liao]

On Fri, 2016-07-01 at 18:21 -0700, Stephen Boyd wrote:
> (Resending to everyone)
> 
> On 06/22, Erin Lo wrote:
> > From: James Liao 
> > 
> > This patch fixed wrong state of parent clocks if they are registered
> > after critical clocks.
> > 
> > Signed-off-by: James Liao 
> > Signed-off-by: Erin Lo 
> 
> It would be nice if you included the information about the
> problem from James' previous mail. This says what it does, but
> doesn't explain what the problem is and how it is fixing it.
> 
> > ---
> >  drivers/clk/clk.c | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index d584004..e9f5f89 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -2388,8 +2388,15 @@ static int __clk_core_init(struct clk_core *core)
> > hlist_for_each_entry_safe(orphan, tmp2, _orphan_list, child_node) {
> > struct clk_core *parent = __clk_init_parent(orphan);
> >  
> > -   if (parent)
> > +   if (parent) {
> > clk_core_reparent(orphan, parent);
> > +
> > +   if (orphan->prepare_count)
> > +   clk_core_prepare(parent);
> > +
> > +   if (orphan->enable_count)
> > +   clk_core_enable(parent);
> > +   }
> > }
> 
> I'm pretty sure I pointed this problem out to Mike when the
> critical clk patches were being pushed. I can't recall what the
> plan was though to fix the problem. I'm pretty sure he said that
> clk_core_reparent() would take care of it, but obviously it is
> not doing that. Or perhaps it was that clk handoff should figure
> out that the parents of a critical clk are also on and thus keep
> them on.

Hi Mike

Is there any other patch to fix this issue? Or did I misuse critical
clock flag?


Best regards,

James

Re: [PATCH v9 01/10] clk: fix initial state of critical clock's parents

[James Liao]

On Fri, 2016-07-01 at 18:21 -0700, Stephen Boyd wrote:
> (Resending to everyone)
> 
> On 06/22, Erin Lo wrote:
> > From: James Liao 
> > 
> > This patch fixed wrong state of parent clocks if they are registered
> > after critical clocks.
> > 
> > Signed-off-by: James Liao 
> > Signed-off-by: Erin Lo 
> 
> It would be nice if you included the information about the
> problem from James' previous mail. This says what it does, but
> doesn't explain what the problem is and how it is fixing it.
> 
> > ---
> >  drivers/clk/clk.c | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index d584004..e9f5f89 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -2388,8 +2388,15 @@ static int __clk_core_init(struct clk_core *core)
> > hlist_for_each_entry_safe(orphan, tmp2, _orphan_list, child_node) {
> > struct clk_core *parent = __clk_init_parent(orphan);
> >  
> > -   if (parent)
> > +   if (parent) {
> > clk_core_reparent(orphan, parent);
> > +
> > +   if (orphan->prepare_count)
> > +   clk_core_prepare(parent);
> > +
> > +   if (orphan->enable_count)
> > +   clk_core_enable(parent);
> > +   }
> > }
> 
> I'm pretty sure I pointed this problem out to Mike when the
> critical clk patches were being pushed. I can't recall what the
> plan was though to fix the problem. I'm pretty sure he said that
> clk_core_reparent() would take care of it, but obviously it is
> not doing that. Or perhaps it was that clk handoff should figure
> out that the parents of a critical clk are also on and thus keep
> them on.

Hi Mike

Is there any other patch to fix this issue? Or did I misuse critical
clock flag?


Best regards,

James

Re: [Nouveau] [PATCH 2/6] drm/nouveau/core: make use of new strtolower() function

[Alexandre Courbot]

On Mon, Jul 4, 2016 at 10:37 AM, Alexandre Courbot  wrote:
> On Sun, Jul 3, 2016 at 12:21 AM, Markus Mayer  
> wrote:
>> On 1 July 2016 at 18:18, Alexandre Courbot  wrote:
>>> On Fri, Jul 1, 2016 at 8:50 AM, Markus Mayer  wrote:
 Call strtolower() rather than walking the string explicitly to convert
 it to lowercase.

 Signed-off-by: Markus Mayer 
 ---
  drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 7 +--
  1 file changed, 1 insertion(+), 6 deletions(-)

 diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c 
 b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
 index 34ecd4a..c50594c 100644
 --- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
 +++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
 @@ -36,16 +36,11 @@ nvkm_firmware_get(struct nvkm_device *device, const 
 char *fwname,
  {
 char f[64];
 char cname[16];
 -   int i;

 /* Convert device name to lowercase */
 strncpy(cname, device->chip->name, sizeof(cname));
 cname[sizeof(cname) - 1] = '\0';
 -   i = strlen(cname);
 -   while (i) {
 -   --i;
 -   cname[i] = tolower(cname[i]);
 -   }
 +   strtolower(cname);
>>>
>>> This function doesn't seem to exist as of next-20160701, where have
>>> you found it?
>>
>> I didn't find it. I wrote it, because it didn't exist and I needed it.
>> See: https://lkml.org/lkml/2016/6/30/727 and
>> https://lkml.org/lkml/2016/6/30/733 (cover letter and first patch in
>> series).
>
> Ah, right - would have been easier to understand if you had sent the
> whole series (or at least patches 0 to 2) to us as well. Please do
> that for the next version.

... found patches 0 and 1 in my spam folder, for some weird reason.
Apologies for jumping to conclusions.

Re: [Nouveau] [PATCH 2/6] drm/nouveau/core: make use of new strtolower() function

[Alexandre Courbot]

On Mon, Jul 4, 2016 at 10:37 AM, Alexandre Courbot  wrote:
> On Sun, Jul 3, 2016 at 12:21 AM, Markus Mayer  
> wrote:
>> On 1 July 2016 at 18:18, Alexandre Courbot  wrote:
>>> On Fri, Jul 1, 2016 at 8:50 AM, Markus Mayer  wrote:
 Call strtolower() rather than walking the string explicitly to convert
 it to lowercase.

 Signed-off-by: Markus Mayer 
 ---
  drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 7 +--
  1 file changed, 1 insertion(+), 6 deletions(-)

 diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c 
 b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
 index 34ecd4a..c50594c 100644
 --- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
 +++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
 @@ -36,16 +36,11 @@ nvkm_firmware_get(struct nvkm_device *device, const 
 char *fwname,
  {
 char f[64];
 char cname[16];
 -   int i;

 /* Convert device name to lowercase */
 strncpy(cname, device->chip->name, sizeof(cname));
 cname[sizeof(cname) - 1] = '\0';
 -   i = strlen(cname);
 -   while (i) {
 -   --i;
 -   cname[i] = tolower(cname[i]);
 -   }
 +   strtolower(cname);
>>>
>>> This function doesn't seem to exist as of next-20160701, where have
>>> you found it?
>>
>> I didn't find it. I wrote it, because it didn't exist and I needed it.
>> See: https://lkml.org/lkml/2016/6/30/727 and
>> https://lkml.org/lkml/2016/6/30/733 (cover letter and first patch in
>> series).
>
> Ah, right - would have been easier to understand if you had sent the
> whole series (or at least patches 0 to 2) to us as well. Please do
> that for the next version.

... found patches 0 and 1 in my spam folder, for some weird reason.
Apologies for jumping to conclusions.

Re: [PATCH 6/8] mm/zsmalloc: keep comments consistent with code

[Ganesh Mahendran]

On Mon, Jul 04, 2016 at 09:05:16AM +0900, Minchan Kim wrote:
> On Fri, Jul 01, 2016 at 02:41:04PM +0800, Ganesh Mahendran wrote:
> > some minor change of comments:
> > 1). update zs_malloc(),zs_create_pool() function header
> > 2). update "Usage of struct page fields"
> > 
> > Signed-off-by: Ganesh Mahendran 
> > ---
> >  mm/zsmalloc.c | 7 +++
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index 2690914..6fc631a 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -20,6 +20,7 @@
> >   * page->freelist(index): links together all component pages of a zspage
> >   * For the huge page, this is always 0, so we use this field
> >   * to store handle.
> > + * page->units: first object index in a subpage of zspage
> 
> Hmm, I want to use offset instead of index.

Yes, it should be offset here. I mixed it with obj index. :)

Thanks

Re: [PATCH 6/8] mm/zsmalloc: keep comments consistent with code

[Ganesh Mahendran]

On Mon, Jul 04, 2016 at 09:05:16AM +0900, Minchan Kim wrote:
> On Fri, Jul 01, 2016 at 02:41:04PM +0800, Ganesh Mahendran wrote:
> > some minor change of comments:
> > 1). update zs_malloc(),zs_create_pool() function header
> > 2). update "Usage of struct page fields"
> > 
> > Signed-off-by: Ganesh Mahendran 
> > ---
> >  mm/zsmalloc.c | 7 +++
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index 2690914..6fc631a 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -20,6 +20,7 @@
> >   * page->freelist(index): links together all component pages of a zspage
> >   * For the huge page, this is always 0, so we use this field
> >   * to store handle.
> > + * page->units: first object index in a subpage of zspage
> 
> Hmm, I want to use offset instead of index.

Yes, it should be offset here. I mixed it with obj index. :)

Thanks

Re: [PATCH v2 1/1] devfreq: exynos-bus: add missing of_node_put after calling of_parse_phandle

[Chanwoo Choi]

On 2016년 07월 04일 11:47, Peter Chen wrote:
> of_node_put needs to be called when the device node which is got
> from of_parse_phandle has finished using.
> 
> Cc: Chanwoo Choi 
> Cc: MyungJoo Ham 
> Cc: Kyungmin Park 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Signed-off-by: Peter Chen 
> ---
> 
> Changes at v2:
> - It should define node as pointer, kbuild test robot reports it
> 
> 
>  drivers/devfreq/exynos-bus.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index 2363d0a..4b4c63c 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -383,7 +383,7 @@ err_clk:
>  static int exynos_bus_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
> - struct device_node *np = dev->of_node;
> + struct device_node *node, *np = dev->of_node;
>   struct devfreq_dev_profile *profile;
>   struct devfreq_simple_ondemand_data *ondemand_data;
>   struct devfreq_passive_data *passive_data;
> @@ -415,10 +415,13 @@ static int exynos_bus_probe(struct platform_device 
> *pdev)
>   goto err;
>   }
>  
> - if (of_parse_phandle(dev->of_node, "devfreq", 0))
> + node = of_parse_phandle(dev->of_node, "devfreq", 0);
> + if (node) {
> + of_node_put(node);
>   goto passive;
> - else
> + } else {
>   ret = exynos_bus_parent_parse_of(np, bus);
> + }
>  
>   if (ret < 0)
>   goto err;
> 

Acked-by: Chanwoo Choi 

Thanks,
Chanwoo Choi

Re: [PATCH v2 1/1] devfreq: exynos-bus: add missing of_node_put after calling of_parse_phandle

[Chanwoo Choi]

On 2016년 07월 04일 11:47, Peter Chen wrote:
> of_node_put needs to be called when the device node which is got
> from of_parse_phandle has finished using.
> 
> Cc: Chanwoo Choi 
> Cc: MyungJoo Ham 
> Cc: Kyungmin Park 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Signed-off-by: Peter Chen 
> ---
> 
> Changes at v2:
> - It should define node as pointer, kbuild test robot reports it
> 
> 
>  drivers/devfreq/exynos-bus.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index 2363d0a..4b4c63c 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -383,7 +383,7 @@ err_clk:
>  static int exynos_bus_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
> - struct device_node *np = dev->of_node;
> + struct device_node *node, *np = dev->of_node;
>   struct devfreq_dev_profile *profile;
>   struct devfreq_simple_ondemand_data *ondemand_data;
>   struct devfreq_passive_data *passive_data;
> @@ -415,10 +415,13 @@ static int exynos_bus_probe(struct platform_device 
> *pdev)
>   goto err;
>   }
>  
> - if (of_parse_phandle(dev->of_node, "devfreq", 0))
> + node = of_parse_phandle(dev->of_node, "devfreq", 0);
> + if (node) {
> + of_node_put(node);
>   goto passive;
> - else
> + } else {
>   ret = exynos_bus_parent_parse_of(np, bus);
> + }
>  
>   if (ret < 0)
>   goto err;
> 

Acked-by: Chanwoo Choi 

Thanks,
Chanwoo Choi

Re: [PATCH 5/8] mm/zsmalloc: avoid calculate max objects of zspage twice

[Ganesh Mahendran]

On Mon, Jul 04, 2016 at 09:03:18AM +0900, Minchan Kim wrote:
> On Fri, Jul 01, 2016 at 02:41:03PM +0800, Ganesh Mahendran wrote:
> > Currently, if a class can not be merged, the max objects of zspage
> > in that class may be calculated twice.
> > 
> > This patch calculate max objects of zspage at the begin, and pass
> > the value to can_merge() to decide whether the class can be merged.
> > 
> > Signed-off-by: Ganesh Mahendran 
> > ---
> >  mm/zsmalloc.c | 21 ++---
> >  1 file changed, 10 insertions(+), 11 deletions(-)
> > 
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index 50283b1..2690914 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -1362,16 +1362,14 @@ static void init_zs_size_classes(void)
> > zs_size_classes = nr;
> >  }
> >  
> > -static bool can_merge(struct size_class *prev, int size, int 
> > pages_per_zspage)
> > +static bool can_merge(struct size_class *prev, int pages_per_zspage,
> > +   int objs_per_zspage)
> >  {
> > -   if (prev->pages_per_zspage != pages_per_zspage)
> > -   return false;
> > -
> > -   if (prev->objs_per_zspage
> > -   != get_maxobj_per_zspage(size, pages_per_zspage))
> > -   return false;
> > +   if (prev->pages_per_zspage == pages_per_zspage &&
> > +   prev->objs_per_zspage == objs_per_zspage)
> > +   return true;
> >  
> > -   return true;
> > +   return false;
> >  }
> >  
> >  static bool zspage_full(struct size_class *class, struct zspage *zspage)
> > @@ -2460,6 +2458,7 @@ struct zs_pool *zs_create_pool(const char *name)
> > for (i = zs_size_classes - 1; i >= 0; i--) {
> > int size;
> > int pages_per_zspage;
> > +   int objs_per_zspage;
> > struct size_class *class;
> > int fullness = 0;
> >  
> > @@ -2467,6 +2466,7 @@ struct zs_pool *zs_create_pool(const char *name)
> > if (size > ZS_MAX_ALLOC_SIZE)
> > size = ZS_MAX_ALLOC_SIZE;
> > pages_per_zspage = get_pages_per_zspage(size);
> > +   objs_per_zspage = get_maxobj_per_zspage(size, pages_per_zspage);
> 
> So, user of get_maxobj_per_zspage is only here? If so, let's remove
> get_maxobj_per_zspage to prevent misuse in future. Instead, use open code
> here.

Yes, get_maxobj_per_zspage is only called here. 
I will remove it in V2.

Thanks.

> 
> 
> >  
> > /*
> >  * size_class is used for normal zsmalloc operation such
> > @@ -2478,7 +2478,7 @@ struct zs_pool *zs_create_pool(const char *name)
> >  * previous size_class if possible.
> >  */
> > if (prev_class) {
> > -   if (can_merge(prev_class, size, pages_per_zspage)) {
> > +   if (can_merge(prev_class, pages_per_zspage, 
> > objs_per_zspage)) {
> > pool->size_class[i] = prev_class;
> > continue;
> > }
> > @@ -2491,8 +2491,7 @@ struct zs_pool *zs_create_pool(const char *name)
> > class->size = size;
> > class->index = i;
> > class->pages_per_zspage = pages_per_zspage;
> > -   class->objs_per_zspage = get_maxobj_per_zspage(class->size,
> > -   
> > class->pages_per_zspage);
> > +   class->objs_per_zspage = objs_per_zspage;
> > spin_lock_init(>lock);
> > pool->size_class[i] = class;
> > for (fullness = ZS_EMPTY; fullness < NR_ZS_FULLNESS;
> > -- 
> > 1.9.1
> > 

Re: [PATCH 5/8] mm/zsmalloc: avoid calculate max objects of zspage twice

[Ganesh Mahendran]

On Mon, Jul 04, 2016 at 09:03:18AM +0900, Minchan Kim wrote:
> On Fri, Jul 01, 2016 at 02:41:03PM +0800, Ganesh Mahendran wrote:
> > Currently, if a class can not be merged, the max objects of zspage
> > in that class may be calculated twice.
> > 
> > This patch calculate max objects of zspage at the begin, and pass
> > the value to can_merge() to decide whether the class can be merged.
> > 
> > Signed-off-by: Ganesh Mahendran 
> > ---
> >  mm/zsmalloc.c | 21 ++---
> >  1 file changed, 10 insertions(+), 11 deletions(-)
> > 
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index 50283b1..2690914 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -1362,16 +1362,14 @@ static void init_zs_size_classes(void)
> > zs_size_classes = nr;
> >  }
> >  
> > -static bool can_merge(struct size_class *prev, int size, int 
> > pages_per_zspage)
> > +static bool can_merge(struct size_class *prev, int pages_per_zspage,
> > +   int objs_per_zspage)
> >  {
> > -   if (prev->pages_per_zspage != pages_per_zspage)
> > -   return false;
> > -
> > -   if (prev->objs_per_zspage
> > -   != get_maxobj_per_zspage(size, pages_per_zspage))
> > -   return false;
> > +   if (prev->pages_per_zspage == pages_per_zspage &&
> > +   prev->objs_per_zspage == objs_per_zspage)
> > +   return true;
> >  
> > -   return true;
> > +   return false;
> >  }
> >  
> >  static bool zspage_full(struct size_class *class, struct zspage *zspage)
> > @@ -2460,6 +2458,7 @@ struct zs_pool *zs_create_pool(const char *name)
> > for (i = zs_size_classes - 1; i >= 0; i--) {
> > int size;
> > int pages_per_zspage;
> > +   int objs_per_zspage;
> > struct size_class *class;
> > int fullness = 0;
> >  
> > @@ -2467,6 +2466,7 @@ struct zs_pool *zs_create_pool(const char *name)
> > if (size > ZS_MAX_ALLOC_SIZE)
> > size = ZS_MAX_ALLOC_SIZE;
> > pages_per_zspage = get_pages_per_zspage(size);
> > +   objs_per_zspage = get_maxobj_per_zspage(size, pages_per_zspage);
> 
> So, user of get_maxobj_per_zspage is only here? If so, let's remove
> get_maxobj_per_zspage to prevent misuse in future. Instead, use open code
> here.

Yes, get_maxobj_per_zspage is only called here. 
I will remove it in V2.

Thanks.

> 
> 
> >  
> > /*
> >  * size_class is used for normal zsmalloc operation such
> > @@ -2478,7 +2478,7 @@ struct zs_pool *zs_create_pool(const char *name)
> >  * previous size_class if possible.
> >  */
> > if (prev_class) {
> > -   if (can_merge(prev_class, size, pages_per_zspage)) {
> > +   if (can_merge(prev_class, pages_per_zspage, 
> > objs_per_zspage)) {
> > pool->size_class[i] = prev_class;
> > continue;
> > }
> > @@ -2491,8 +2491,7 @@ struct zs_pool *zs_create_pool(const char *name)
> > class->size = size;
> > class->index = i;
> > class->pages_per_zspage = pages_per_zspage;
> > -   class->objs_per_zspage = get_maxobj_per_zspage(class->size,
> > -   
> > class->pages_per_zspage);
> > +   class->objs_per_zspage = objs_per_zspage;
> > spin_lock_init(>lock);
> > pool->size_class[i] = class;
> > for (fullness = ZS_EMPTY; fullness < NR_ZS_FULLNESS;
> > -- 
> > 1.9.1
> > 

Re: [PATCH 3/8] mm/zsmalloc: take obj index back from find_alloced_obj

[Ganesh Mahendran]

On Mon, Jul 04, 2016 at 08:57:04AM +0900, Minchan Kim wrote:
> On Fri, Jul 01, 2016 at 02:41:01PM +0800, Ganesh Mahendran wrote:
> > the obj index value should be updated after return from
> > find_alloced_obj()
>  
> to avoid CPU buring caused by unnecessary object scanning.
> 
> Description should include what's the goal.

Thanks for your reminder.

> 
> > 
> > Signed-off-by: Ganesh Mahendran 
> > ---
> >  mm/zsmalloc.c | 13 -
> >  1 file changed, 8 insertions(+), 5 deletions(-)
> > 
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index 405baa5..5c96ed1 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -1744,15 +1744,16 @@ static void zs_object_copy(struct size_class 
> > *class, unsigned long dst,
> >   * return handle.
> >   */
> >  static unsigned long find_alloced_obj(struct size_class *class,
> > -   struct page *page, int index)
> > +   struct page *page, int *index)
> >  {
> > unsigned long head;
> > int offset = 0;
> > +   int objidx = *index;
> 
> Nit:
> 
> We have used obj_idx so I prefer it for consistency with others.

will do it.

> 
> Suggestion:
> Could you mind changing index in zs_compact_control and
> migrate_zspage with obj_idx in this chance?

I will add a clean up patch in this patchset.

> 
> Strictly speaking, such clean up is separate patch but I don't mind
> mixing them here(Of course, you will send it as another clean up patch,
> it would be better). If you mind, just let it leave as is. Sometime,
> I wil do it.
> 
> > unsigned long handle = 0;
> > void *addr = kmap_atomic(page);
> >  
> > offset = get_first_obj_offset(page);
> > -   offset += class->size * index;
> > +   offset += class->size * objidx;
> >  
> > while (offset < PAGE_SIZE) {
> > head = obj_to_head(page, addr + offset);
> > @@ -1764,9 +1765,11 @@ static unsigned long find_alloced_obj(struct 
> > size_class *class,
> > }
> >  
> > offset += class->size;
> > -   index++;
> > +   objidx++;
> > }
> >  
> > +   *index = objidx;
> 
> We can do this out of kmap section right before returing handle.

That's right. I will send a V2 patch soon.

Thanks.

> 
> Thanks!
> 
> > +
> > kunmap_atomic(addr);
> > return handle;
> >  }
> > @@ -1794,11 +1797,11 @@ static int migrate_zspage(struct zs_pool *pool, 
> > struct size_class *class,
> > unsigned long handle;
> > struct page *s_page = cc->s_page;
> > struct page *d_page = cc->d_page;
> > -   unsigned long index = cc->index;
> > +   unsigned int index = cc->index;
> > int ret = 0;
> >  
> > while (1) {
> > -   handle = find_alloced_obj(class, s_page, index);
> > +   handle = find_alloced_obj(class, s_page, );
> > if (!handle) {
> > s_page = get_next_page(s_page);
> > if (!s_page)
> > -- 
> > 1.9.1
> > 

Re: [PATCH 3/8] mm/zsmalloc: take obj index back from find_alloced_obj

[Ganesh Mahendran]

On Mon, Jul 04, 2016 at 08:57:04AM +0900, Minchan Kim wrote:
> On Fri, Jul 01, 2016 at 02:41:01PM +0800, Ganesh Mahendran wrote:
> > the obj index value should be updated after return from
> > find_alloced_obj()
>  
> to avoid CPU buring caused by unnecessary object scanning.
> 
> Description should include what's the goal.

Thanks for your reminder.

> 
> > 
> > Signed-off-by: Ganesh Mahendran 
> > ---
> >  mm/zsmalloc.c | 13 -
> >  1 file changed, 8 insertions(+), 5 deletions(-)
> > 
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index 405baa5..5c96ed1 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -1744,15 +1744,16 @@ static void zs_object_copy(struct size_class 
> > *class, unsigned long dst,
> >   * return handle.
> >   */
> >  static unsigned long find_alloced_obj(struct size_class *class,
> > -   struct page *page, int index)
> > +   struct page *page, int *index)
> >  {
> > unsigned long head;
> > int offset = 0;
> > +   int objidx = *index;
> 
> Nit:
> 
> We have used obj_idx so I prefer it for consistency with others.

will do it.

> 
> Suggestion:
> Could you mind changing index in zs_compact_control and
> migrate_zspage with obj_idx in this chance?

I will add a clean up patch in this patchset.

> 
> Strictly speaking, such clean up is separate patch but I don't mind
> mixing them here(Of course, you will send it as another clean up patch,
> it would be better). If you mind, just let it leave as is. Sometime,
> I wil do it.
> 
> > unsigned long handle = 0;
> > void *addr = kmap_atomic(page);
> >  
> > offset = get_first_obj_offset(page);
> > -   offset += class->size * index;
> > +   offset += class->size * objidx;
> >  
> > while (offset < PAGE_SIZE) {
> > head = obj_to_head(page, addr + offset);
> > @@ -1764,9 +1765,11 @@ static unsigned long find_alloced_obj(struct 
> > size_class *class,
> > }
> >  
> > offset += class->size;
> > -   index++;
> > +   objidx++;
> > }
> >  
> > +   *index = objidx;
> 
> We can do this out of kmap section right before returing handle.

That's right. I will send a V2 patch soon.

Thanks.

> 
> Thanks!
> 
> > +
> > kunmap_atomic(addr);
> > return handle;
> >  }
> > @@ -1794,11 +1797,11 @@ static int migrate_zspage(struct zs_pool *pool, 
> > struct size_class *class,
> > unsigned long handle;
> > struct page *s_page = cc->s_page;
> > struct page *d_page = cc->d_page;
> > -   unsigned long index = cc->index;
> > +   unsigned int index = cc->index;
> > int ret = 0;
> >  
> > while (1) {
> > -   handle = find_alloced_obj(class, s_page, index);
> > +   handle = find_alloced_obj(class, s_page, );
> > if (!handle) {
> > s_page = get_next_page(s_page);
> > if (!s_page)
> > -- 
> > 1.9.1
> > 

linux-next: build warning after merge of the net-next tree

[Stephen Rothwell]

Hi all,

After merging the net-next tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

drivers/net/tun.c: In function 'tun_do_read.part.5':
/home/sfr/next/next/drivers/net/tun.c:1491:6: warning: 'err' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
  int err;
  ^

Introduced by commit

  1576d9860599 ("tun: switch to use skb array for tx")

I can't easily see if this is a false positive.

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the net-next tree

[Stephen Rothwell]

Hi all,

After merging the net-next tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

drivers/net/tun.c: In function 'tun_do_read.part.5':
/home/sfr/next/next/drivers/net/tun.c:1491:6: warning: 'err' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
  int err;
  ^

Introduced by commit

  1576d9860599 ("tun: switch to use skb array for tx")

I can't easily see if this is a false positive.

-- 
Cheers,
Stephen Rothwell

[PATCH] ACPI/init: Correct the comments about acpi_subsystem_init

[Baoquan He]

In acpi_subsystem_init, function acpi_enable_subsystem is called to do
the real job. However with different flags passed to acpi_enable_subsystem,
different code is executed. In acpi_subsystem_init with "~ACPI_NO_ACPI_ENABLE"
passed in it will only switch over the platform to the ACPI mode. The rest
part of acpi_enable_subsystem is done when acpi_bus_init is called.

So the comments above acpi_subsystem_init is not exact, change it here.

Signed-off-by: Baoquan He 
---
 drivers/acpi/bus.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 262ca31..eef468d 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -961,8 +961,7 @@ void __init acpi_early_init(void)
 /**
  * acpi_subsystem_init - Finalize the early initialization of ACPI.
  *
- * Switch over the platform to the ACPI mode (if possible), initialize the
- * handling of ACPI events, install the interrupt and global lock handlers.
+ * Switch over the platform to the ACPI mode (if possible).
  *
  * Doing this too early is generally unsafe, but at the same time it needs to 
be
  * done before all things that really depend on ACPI.  The right spot appears 
to
-- 
2.5.5

[PATCH] ACPI/init: Correct the comments about acpi_subsystem_init

[Baoquan He]

In acpi_subsystem_init, function acpi_enable_subsystem is called to do
the real job. However with different flags passed to acpi_enable_subsystem,
different code is executed. In acpi_subsystem_init with "~ACPI_NO_ACPI_ENABLE"
passed in it will only switch over the platform to the ACPI mode. The rest
part of acpi_enable_subsystem is done when acpi_bus_init is called.

So the comments above acpi_subsystem_init is not exact, change it here.

Signed-off-by: Baoquan He 
---
 drivers/acpi/bus.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 262ca31..eef468d 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -961,8 +961,7 @@ void __init acpi_early_init(void)
 /**
  * acpi_subsystem_init - Finalize the early initialization of ACPI.
  *
- * Switch over the platform to the ACPI mode (if possible), initialize the
- * handling of ACPI events, install the interrupt and global lock handlers.
+ * Switch over the platform to the ACPI mode (if possible).
  *
  * Doing this too early is generally unsafe, but at the same time it needs to 
be
  * done before all things that really depend on ACPI.  The right spot appears 
to
-- 
2.5.5

Re: [PATCH 2/8] mm/zsmalloc: add per class compact trace event

[Ganesh Mahendran]

Hi, Minchan:

On Mon, Jul 04, 2016 at 08:49:21AM +0900, Minchan Kim wrote:
> On Fri, Jul 01, 2016 at 02:41:00PM +0800, Ganesh Mahendran wrote:
> > add per class compact trace event. It will show how many zs pages
> > isolated, how many zs pages reclaimed.
> 
> I don't know what you want with this event trace.
> 
> What's the relation betwwen the number of zspage isolated and zspage
> reclaimed? IOW, with that, what do you want to know?

This is only for our internal debug. And it is not common for everyone.

Please ignore this patch. Sorry for the noise.

Thanks

> 
> > 
> > 
> >   <...>-627   [002]    192.641122: zs_compact_start: pool zram0
> >   <...>-627   [002]    192.641166: zs_compact_class: class 254: 0 
> > zspage isolated, 0 reclaimed
> >   <...>-627   [002]    192.641169: zs_compact_class: class 202: 0 
> > zspage isolated, 0 reclaimed
> >   <...>-627   [002]    192.641172: zs_compact_class: class 190: 0 
> > zspage isolated, 0 reclaimed
> >   <...>-627   [002]    192.641180: zs_compact_class: class 168: 3 
> > zspage isolated, 1 reclaimed
> >   <...>-627   [002]    192.641190: zs_compact_class: class 151: 3 
> > zspage isolated, 1 reclaimed
> >   <...>-627   [002]    192.641201: zs_compact_class: class 144: 6 
> > zspage isolated, 1 reclaimed
> >   <...>-627   [002]    192.641224: zs_compact_class: class 126: 24 
> > zspage isolated, 12 reclaimed
> >   <...>-627   [002]    192.641261: zs_compact_class: class 111: 10 
> > zspage isolated, 2 reclaimed
> > kswapd0-627   [002]    192.641333: zs_compact_class: class 107: 38 
> > zspage isolated, 8 reclaimed
> > kswapd0-627   [002]    192.641415: zs_compact_class: class 100: 45 
> > zspage isolated, 12 reclaimed
> > kswapd0-627   [002]    192.641481: zs_compact_class: class  94: 24 
> > zspage isolated, 5 reclaimed
> > kswapd0-627   [002]    192.641568: zs_compact_class: class  91: 69 
> > zspage isolated, 14 reclaimed
> > kswapd0-627   [002]    192.641688: zs_compact_class: class  83: 120 
> > zspage isolated, 47 reclaimed
> > kswapd0-627   [002]    192.641765: zs_compact_class: class  76: 34 
> > zspage isolated, 5 reclaimed
> > kswapd0-627   [002]    192.641832: zs_compact_class: class  74: 34 
> > zspage isolated, 6 reclaimed
> > kswapd0-627   [002]    192.641958: zs_compact_class: class  71: 66 
> > zspage isolated, 17 reclaimed
> > kswapd0-627   [002]    192.642000: zs_compact_class: class  67: 17 
> > zspage isolated, 3 reclaimed
> > kswapd0-627   [002]    192.642063: zs_compact_class: class  66: 29 
> > zspage isolated, 5 reclaimed
> > kswapd0-627   [002]    192.642113: zs_compact_class: class  62: 38 
> > zspage isolated, 12 reclaimed
> > kswapd0-627   [002]    192.642143: zs_compact_class: class  58: 8 
> > zspage isolated, 1 reclaimed
> > kswapd0-627   [002]    192.642176: zs_compact_class: class  57: 25 
> > zspage isolated, 5 reclaimed
> > kswapd0-627   [002]    192.642184: zs_compact_class: class  54: 11 
> > zspage isolated, 2 reclaimed
> > kswapd0-627   [002]    192.642191: zs_compact_class: class  52: 5 
> > zspage isolated, 1 reclaimed
> > kswapd0-627   [002]    192.642201: zs_compact_class: class  51: 6 
> > zspage isolated, 1 reclaimed
> > kswapd0-627   [002]    192.642211: zs_compact_class: class  49: 11 
> > zspage isolated, 3 reclaimed
> > kswapd0-627   [002]    192.642216: zs_compact_class: class  46: 2 
> > zspage isolated, 1 reclaimed
> > kswapd0-627   [002]    192.642218: zs_compact_class: class  44: 0 
> > zspage isolated, 0 reclaimed
> > kswapd0-627   [002]    192.642221: zs_compact_class: class  43: 0 
> > zspage isolated, 0 reclaimed
> >   ...
> > 
> > 
> > Signed-off-by: Ganesh Mahendran 
> > ---
> >  include/trace/events/zsmalloc.h | 24 
> >  mm/zsmalloc.c   | 16 +++-
> >  2 files changed, 39 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/trace/events/zsmalloc.h 
> > b/include/trace/events/zsmalloc.h
> > index c7a39f4..e745246 100644
> > --- a/include/trace/events/zsmalloc.h
> > +++ b/include/trace/events/zsmalloc.h
> > @@ -46,6 +46,30 @@ TRACE_EVENT(zs_compact_end,
> >   __entry->pages_compacted)
> >  );
> >  
> > +TRACE_EVENT(zs_compact_class,
> > +
> > +   TP_PROTO(int class, unsigned long zspage_isolated, unsigned long 
> > zspage_reclaimed),
> > +
> > +   TP_ARGS(class, zspage_isolated, zspage_reclaimed),
> > +
> > +   TP_STRUCT__entry(
> > +   __field(int, class)
> > +   __field(unsigned long, zspage_isolated)
> > +   __field(unsigned long, zspage_reclaimed)
> > +   ),
> > +
> > +   TP_fast_assign(
> > +   __entry->class = class;
> > +   __entry->zspage_isolated = zspage_isolated;
> > +   __entry->zspage_reclaimed = zspage_reclaimed;
> > +   ),
> > +
> > +   TP_printk("class %3d: %ld zspage isolated, %ld zspage reclaimed",
> > +

Re: [PATCH 2/8] mm/zsmalloc: add per class compact trace event

[Ganesh Mahendran]

Hi, Minchan:

On Mon, Jul 04, 2016 at 08:49:21AM +0900, Minchan Kim wrote:
> On Fri, Jul 01, 2016 at 02:41:00PM +0800, Ganesh Mahendran wrote:
> > add per class compact trace event. It will show how many zs pages
> > isolated, how many zs pages reclaimed.
> 
> I don't know what you want with this event trace.
> 
> What's the relation betwwen the number of zspage isolated and zspage
> reclaimed? IOW, with that, what do you want to know?

This is only for our internal debug. And it is not common for everyone.

Please ignore this patch. Sorry for the noise.

Thanks

> 
> > 
> > 
> >   <...>-627   [002]    192.641122: zs_compact_start: pool zram0
> >   <...>-627   [002]    192.641166: zs_compact_class: class 254: 0 
> > zspage isolated, 0 reclaimed
> >   <...>-627   [002]    192.641169: zs_compact_class: class 202: 0 
> > zspage isolated, 0 reclaimed
> >   <...>-627   [002]    192.641172: zs_compact_class: class 190: 0 
> > zspage isolated, 0 reclaimed
> >   <...>-627   [002]    192.641180: zs_compact_class: class 168: 3 
> > zspage isolated, 1 reclaimed
> >   <...>-627   [002]    192.641190: zs_compact_class: class 151: 3 
> > zspage isolated, 1 reclaimed
> >   <...>-627   [002]    192.641201: zs_compact_class: class 144: 6 
> > zspage isolated, 1 reclaimed
> >   <...>-627   [002]    192.641224: zs_compact_class: class 126: 24 
> > zspage isolated, 12 reclaimed
> >   <...>-627   [002]    192.641261: zs_compact_class: class 111: 10 
> > zspage isolated, 2 reclaimed
> > kswapd0-627   [002]    192.641333: zs_compact_class: class 107: 38 
> > zspage isolated, 8 reclaimed
> > kswapd0-627   [002]    192.641415: zs_compact_class: class 100: 45 
> > zspage isolated, 12 reclaimed
> > kswapd0-627   [002]    192.641481: zs_compact_class: class  94: 24 
> > zspage isolated, 5 reclaimed
> > kswapd0-627   [002]    192.641568: zs_compact_class: class  91: 69 
> > zspage isolated, 14 reclaimed
> > kswapd0-627   [002]    192.641688: zs_compact_class: class  83: 120 
> > zspage isolated, 47 reclaimed
> > kswapd0-627   [002]    192.641765: zs_compact_class: class  76: 34 
> > zspage isolated, 5 reclaimed
> > kswapd0-627   [002]    192.641832: zs_compact_class: class  74: 34 
> > zspage isolated, 6 reclaimed
> > kswapd0-627   [002]    192.641958: zs_compact_class: class  71: 66 
> > zspage isolated, 17 reclaimed
> > kswapd0-627   [002]    192.642000: zs_compact_class: class  67: 17 
> > zspage isolated, 3 reclaimed
> > kswapd0-627   [002]    192.642063: zs_compact_class: class  66: 29 
> > zspage isolated, 5 reclaimed
> > kswapd0-627   [002]    192.642113: zs_compact_class: class  62: 38 
> > zspage isolated, 12 reclaimed
> > kswapd0-627   [002]    192.642143: zs_compact_class: class  58: 8 
> > zspage isolated, 1 reclaimed
> > kswapd0-627   [002]    192.642176: zs_compact_class: class  57: 25 
> > zspage isolated, 5 reclaimed
> > kswapd0-627   [002]    192.642184: zs_compact_class: class  54: 11 
> > zspage isolated, 2 reclaimed
> > kswapd0-627   [002]    192.642191: zs_compact_class: class  52: 5 
> > zspage isolated, 1 reclaimed
> > kswapd0-627   [002]    192.642201: zs_compact_class: class  51: 6 
> > zspage isolated, 1 reclaimed
> > kswapd0-627   [002]    192.642211: zs_compact_class: class  49: 11 
> > zspage isolated, 3 reclaimed
> > kswapd0-627   [002]    192.642216: zs_compact_class: class  46: 2 
> > zspage isolated, 1 reclaimed
> > kswapd0-627   [002]    192.642218: zs_compact_class: class  44: 0 
> > zspage isolated, 0 reclaimed
> > kswapd0-627   [002]    192.642221: zs_compact_class: class  43: 0 
> > zspage isolated, 0 reclaimed
> >   ...
> > 
> > 
> > Signed-off-by: Ganesh Mahendran 
> > ---
> >  include/trace/events/zsmalloc.h | 24 
> >  mm/zsmalloc.c   | 16 +++-
> >  2 files changed, 39 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/trace/events/zsmalloc.h 
> > b/include/trace/events/zsmalloc.h
> > index c7a39f4..e745246 100644
> > --- a/include/trace/events/zsmalloc.h
> > +++ b/include/trace/events/zsmalloc.h
> > @@ -46,6 +46,30 @@ TRACE_EVENT(zs_compact_end,
> >   __entry->pages_compacted)
> >  );
> >  
> > +TRACE_EVENT(zs_compact_class,
> > +
> > +   TP_PROTO(int class, unsigned long zspage_isolated, unsigned long 
> > zspage_reclaimed),
> > +
> > +   TP_ARGS(class, zspage_isolated, zspage_reclaimed),
> > +
> > +   TP_STRUCT__entry(
> > +   __field(int, class)
> > +   __field(unsigned long, zspage_isolated)
> > +   __field(unsigned long, zspage_reclaimed)
> > +   ),
> > +
> > +   TP_fast_assign(
> > +   __entry->class = class;
> > +   __entry->zspage_isolated = zspage_isolated;
> > +   __entry->zspage_reclaimed = zspage_reclaimed;
> > +   ),
> > +
> > +   TP_printk("class %3d: %ld zspage isolated, %ld zspage reclaimed",
> > + __entry->class,
> > +   

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

[Al Viro]

On Sun, Jul 03, 2016 at 08:37:22PM -0400, Oleg Drokin wrote:

> Hm… This dates to sometime in 2006 and my memory is a bit hazy here.
> 
> I think when we called into the open, it went into fifo open and stuck there
> waiting for the other opener. Something like that. And we cannot really be 
> stuck here
> because we are holding some locks that need to be released in predictable 
> time.
> 
> This code is actually unreachable now because the server never returns an 
> openhandle
> for special device nodes anymore (there's a comment about it in current 
> staging tree,
> but I guess you are looking at some prior version).
> 
> I imagine device nodes might have represented a similar risk too, but it did 
> not
> occur to me to test it separately and the testsuite does not do it either.
> 
> Directories do not get stuck when you open them so they are ok and we can
> atomically open them too, I guess.
> Symlinks are handled specially on the server and the open never returns
> the actual open handle for those, so this path is also unreachable with those.

Hmm...  How much does the safety of client depend upon the correctness of
server?

BTW, there's a fun issue in ll_revalidate_dentry(): there's nothing to
promise stability of ->d_parent in there, so uses of d_inode(dentry->d_parent)
are not safe.  That's independent from parallel lookups, and it's hard
to hit, but AFAICS it's not impossible to oops there.

Anyway, for Lustre the analogue of that NFS problem is here:
} else if (!it_disposition(it, DISP_LOOKUP_NEG)  &&
   !it_disposition(it, DISP_OPEN_CREATE)) {
/* With DISP_OPEN_CREATE dentry will be
 * instantiated in ll_create_it.
 */
LASSERT(!d_inode(*de));
d_instantiate(*de, inode);
}
AFAICS, this (on top of mainline) ought to work:

diff --git a/drivers/staging/lustre/lustre/llite/namei.c 
b/drivers/staging/lustre/lustre/llite/namei.c
index 5eba0eb..b8da5b4 100644
--- a/drivers/staging/lustre/lustre/llite/namei.c
+++ b/drivers/staging/lustre/lustre/llite/namei.c
@@ -581,9 +581,11 @@ static int ll_atomic_open(struct inode *dir, struct dentry 
*dentry,
  struct file *file, unsigned open_flags,
  umode_t mode, int *opened)
 {
+   DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
struct lookup_intent *it;
struct dentry *de;
long long lookup_flags = LOOKUP_OPEN;
+   bool switched = false;
int rc = 0;
 
CDEBUG(D_VFSTRACE, "VFS Op:name=%pd, dir="DFID"(%p),file %p,open_flags 
%x,mode %x opened %d\n",
@@ -603,11 +605,28 @@ static int ll_atomic_open(struct inode *dir, struct 
dentry *dentry,
it->it_flags = (open_flags & ~O_ACCMODE) | OPEN_FMODE(open_flags);
 
/* Dentry added to dcache tree in ll_lookup_it */
+   if (!(open_flags & O_CREAT) && !d_unhashed(dentry)) {
+   d_drop(dentry);
+   switched = true;
+   dentry = d_alloc_parallel(dentry->d_parent,
+ >d_name, );
+   if (IS_ERR(dentry)) {
+   rc = PTR_ERR(dentry);
+   goto out_release;
+   }
+   if (unlikely(!d_in_lookup(dentry))) {
+   rc = finish_no_open(file, dentry);
+   goto out_release;
+   }
+   }
+
de = ll_lookup_it(dir, dentry, it, lookup_flags);
if (IS_ERR(de))
rc = PTR_ERR(de);
else if (de)
dentry = de;
+   else if (switched)
+   de = dget(dentry);
 
if (!rc) {
if (it_disposition(it, DISP_OPEN_CREATE)) {
@@ -648,6 +667,10 @@ static int ll_atomic_open(struct inode *dir, struct dentry 
*dentry,
}
 
 out_release:
+   if (unlikely(switched)) {
+   d_lookup_done(dentry);
+   dput(dentry);
+   }
ll_intent_release(it);
kfree(it);
 

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

[Al Viro]

On Sun, Jul 03, 2016 at 08:37:22PM -0400, Oleg Drokin wrote:

> Hm… This dates to sometime in 2006 and my memory is a bit hazy here.
> 
> I think when we called into the open, it went into fifo open and stuck there
> waiting for the other opener. Something like that. And we cannot really be 
> stuck here
> because we are holding some locks that need to be released in predictable 
> time.
> 
> This code is actually unreachable now because the server never returns an 
> openhandle
> for special device nodes anymore (there's a comment about it in current 
> staging tree,
> but I guess you are looking at some prior version).
> 
> I imagine device nodes might have represented a similar risk too, but it did 
> not
> occur to me to test it separately and the testsuite does not do it either.
> 
> Directories do not get stuck when you open them so they are ok and we can
> atomically open them too, I guess.
> Symlinks are handled specially on the server and the open never returns
> the actual open handle for those, so this path is also unreachable with those.

Hmm...  How much does the safety of client depend upon the correctness of
server?

BTW, there's a fun issue in ll_revalidate_dentry(): there's nothing to
promise stability of ->d_parent in there, so uses of d_inode(dentry->d_parent)
are not safe.  That's independent from parallel lookups, and it's hard
to hit, but AFAICS it's not impossible to oops there.

Anyway, for Lustre the analogue of that NFS problem is here:
} else if (!it_disposition(it, DISP_LOOKUP_NEG)  &&
   !it_disposition(it, DISP_OPEN_CREATE)) {
/* With DISP_OPEN_CREATE dentry will be
 * instantiated in ll_create_it.
 */
LASSERT(!d_inode(*de));
d_instantiate(*de, inode);
}
AFAICS, this (on top of mainline) ought to work:

diff --git a/drivers/staging/lustre/lustre/llite/namei.c 
b/drivers/staging/lustre/lustre/llite/namei.c
index 5eba0eb..b8da5b4 100644
--- a/drivers/staging/lustre/lustre/llite/namei.c
+++ b/drivers/staging/lustre/lustre/llite/namei.c
@@ -581,9 +581,11 @@ static int ll_atomic_open(struct inode *dir, struct dentry 
*dentry,
  struct file *file, unsigned open_flags,
  umode_t mode, int *opened)
 {
+   DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
struct lookup_intent *it;
struct dentry *de;
long long lookup_flags = LOOKUP_OPEN;
+   bool switched = false;
int rc = 0;
 
CDEBUG(D_VFSTRACE, "VFS Op:name=%pd, dir="DFID"(%p),file %p,open_flags 
%x,mode %x opened %d\n",
@@ -603,11 +605,28 @@ static int ll_atomic_open(struct inode *dir, struct 
dentry *dentry,
it->it_flags = (open_flags & ~O_ACCMODE) | OPEN_FMODE(open_flags);
 
/* Dentry added to dcache tree in ll_lookup_it */
+   if (!(open_flags & O_CREAT) && !d_unhashed(dentry)) {
+   d_drop(dentry);
+   switched = true;
+   dentry = d_alloc_parallel(dentry->d_parent,
+ >d_name, );
+   if (IS_ERR(dentry)) {
+   rc = PTR_ERR(dentry);
+   goto out_release;
+   }
+   if (unlikely(!d_in_lookup(dentry))) {
+   rc = finish_no_open(file, dentry);
+   goto out_release;
+   }
+   }
+
de = ll_lookup_it(dir, dentry, it, lookup_flags);
if (IS_ERR(de))
rc = PTR_ERR(de);
else if (de)
dentry = de;
+   else if (switched)
+   de = dget(dentry);
 
if (!rc) {
if (it_disposition(it, DISP_OPEN_CREATE)) {
@@ -648,6 +667,10 @@ static int ll_atomic_open(struct inode *dir, struct dentry 
*dentry,
}
 
 out_release:
+   if (unlikely(switched)) {
+   d_lookup_done(dentry);
+   dput(dentry);
+   }
ll_intent_release(it);
kfree(it);
 

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

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

  drivers/net/ethernet/mellanox/mlx5/core/en_main.c

between commit:

  29429f3300a3 ("net/mlx5e: Timeout if SQ doesn't flush during close")

from the net tree and commit:

  507f0c817f7a ("net/mlx5e: Add TXQ set max rate support")

from the net-next tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 7a0dca29c642,96ec53a6a595..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@@ -39,16 -39,10 +39,17 @@@
  #include "eswitch.h"
  #include "vxlan.h"
  
 +enum {
 +  MLX5_EN_QP_FLUSH_TIMEOUT_MS = 5000,
 +  MLX5_EN_QP_FLUSH_MSLEEP_QUANT   = 20,
 +  MLX5_EN_QP_FLUSH_MAX_ITER   = MLX5_EN_QP_FLUSH_TIMEOUT_MS /
 +MLX5_EN_QP_FLUSH_MSLEEP_QUANT,
 +};
 +
  struct mlx5e_rq_param {
-   u32rqc[MLX5_ST_SZ_DW(rqc)];
-   struct mlx5_wq_param   wq;
+   u32 rqc[MLX5_ST_SZ_DW(rqc)];
+   struct mlx5_wq_paramwq;
+   boolam_enabled;
  };
  
  struct mlx5e_sq_param {
@@@ -574,8 -543,9 +582,10 @@@ static void mlx5e_close_rq(struct mlx5e
/* avoid destroying rq before mlx5e_poll_rx_cq() is done with it */
napi_synchronize(>channel->napi);
  
+   cancel_work_sync(>am.work);
+ 
mlx5e_disable_rq(rq);
 +  mlx5e_free_rx_descs(rq);
mlx5e_destroy_rq(rq);
  }
  
@@@ -835,19 -810,12 +853,19 @@@ static void mlx5e_close_sq(struct mlx5e
if (mlx5e_sq_has_room_for(sq, 1))
mlx5e_send_nop(sq, true);
  
 -  mlx5e_modify_sq(sq, MLX5_SQC_STATE_RDY, MLX5_SQC_STATE_ERR,
 -  false, 0);
 +  err = mlx5e_modify_sq(sq, MLX5_SQC_STATE_RDY,
- MLX5_SQC_STATE_ERR);
++MLX5_SQC_STATE_ERR, false, 0);
 +  if (err)
 +  set_bit(MLX5E_SQ_STATE_TX_TIMEOUT, >state);
}
  
 -  while (sq->cc != sq->pc) /* wait till sq is empty */
 -  msleep(20);
 +  /* wait till sq is empty, unless a TX timeout occurred on this SQ */
 +  while (sq->cc != sq->pc &&
 + !test_bit(MLX5E_SQ_STATE_TX_TIMEOUT, >state)) {
 +  msleep(MLX5_EN_QP_FLUSH_MSLEEP_QUANT);
 +  if (tout++ > MLX5_EN_QP_FLUSH_MAX_ITER)
 +  set_bit(MLX5E_SQ_STATE_TX_TIMEOUT, >state);
 +  }
  
/* avoid destroying sq before mlx5e_poll_tx_cq() is done with it */
napi_synchronize(>channel->napi);

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

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

  drivers/net/ethernet/mellanox/mlx5/core/en_main.c

between commit:

  29429f3300a3 ("net/mlx5e: Timeout if SQ doesn't flush during close")

from the net tree and commit:

  507f0c817f7a ("net/mlx5e: Add TXQ set max rate support")

from the net-next tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 7a0dca29c642,96ec53a6a595..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@@ -39,16 -39,10 +39,17 @@@
  #include "eswitch.h"
  #include "vxlan.h"
  
 +enum {
 +  MLX5_EN_QP_FLUSH_TIMEOUT_MS = 5000,
 +  MLX5_EN_QP_FLUSH_MSLEEP_QUANT   = 20,
 +  MLX5_EN_QP_FLUSH_MAX_ITER   = MLX5_EN_QP_FLUSH_TIMEOUT_MS /
 +MLX5_EN_QP_FLUSH_MSLEEP_QUANT,
 +};
 +
  struct mlx5e_rq_param {
-   u32rqc[MLX5_ST_SZ_DW(rqc)];
-   struct mlx5_wq_param   wq;
+   u32 rqc[MLX5_ST_SZ_DW(rqc)];
+   struct mlx5_wq_paramwq;
+   boolam_enabled;
  };
  
  struct mlx5e_sq_param {
@@@ -574,8 -543,9 +582,10 @@@ static void mlx5e_close_rq(struct mlx5e
/* avoid destroying rq before mlx5e_poll_rx_cq() is done with it */
napi_synchronize(>channel->napi);
  
+   cancel_work_sync(>am.work);
+ 
mlx5e_disable_rq(rq);
 +  mlx5e_free_rx_descs(rq);
mlx5e_destroy_rq(rq);
  }
  
@@@ -835,19 -810,12 +853,19 @@@ static void mlx5e_close_sq(struct mlx5e
if (mlx5e_sq_has_room_for(sq, 1))
mlx5e_send_nop(sq, true);
  
 -  mlx5e_modify_sq(sq, MLX5_SQC_STATE_RDY, MLX5_SQC_STATE_ERR,
 -  false, 0);
 +  err = mlx5e_modify_sq(sq, MLX5_SQC_STATE_RDY,
- MLX5_SQC_STATE_ERR);
++MLX5_SQC_STATE_ERR, false, 0);
 +  if (err)
 +  set_bit(MLX5E_SQ_STATE_TX_TIMEOUT, >state);
}
  
 -  while (sq->cc != sq->pc) /* wait till sq is empty */
 -  msleep(20);
 +  /* wait till sq is empty, unless a TX timeout occurred on this SQ */
 +  while (sq->cc != sq->pc &&
 + !test_bit(MLX5E_SQ_STATE_TX_TIMEOUT, >state)) {
 +  msleep(MLX5_EN_QP_FLUSH_MSLEEP_QUANT);
 +  if (tout++ > MLX5_EN_QP_FLUSH_MAX_ITER)
 +  set_bit(MLX5E_SQ_STATE_TX_TIMEOUT, >state);
 +  }
  
/* avoid destroying sq before mlx5e_poll_tx_cq() is done with it */
napi_synchronize(>channel->napi);

Re: [PATCH v5 0/2] [media] atmel-isc: add driver for Atmel ISC

[Wu, Songjun]

On 7/1/2016 20:20, Hans Verkuil wrote:

Hi Songjun,

First of all, please CC patch 2/2 to linux-media as well the next time you post 
this.
I only see 1/2 on the mailinglist, and we need both.

Secondly, before I can accept it you need to run the v4l2-compliance test first 
and
I need to see the output of that test.

The compliance test is here: https://git.linuxtv.org/v4l-utils.git. Always 
compile it from
the repository so you know you are using the latest most up to date version.

Since this driver supports multiple pixelformats you need to test with the -f 
option,
which tests streaming for all pixelformats.

Obviously, there shouldn't be any FAILs :-)

I greatly simplifies the code review if I know it passes the compliance test.


Hi Hans,

You suggestion is very helpful to me.
I will give the output of the compliance test in next version.


Regards,

Hans

Re: [PATCH v5 0/2] [media] atmel-isc: add driver for Atmel ISC

[Wu, Songjun]

On 7/1/2016 20:20, Hans Verkuil wrote:

Hi Songjun,

First of all, please CC patch 2/2 to linux-media as well the next time you post 
this.
I only see 1/2 on the mailinglist, and we need both.

Secondly, before I can accept it you need to run the v4l2-compliance test first 
and
I need to see the output of that test.

The compliance test is here: https://git.linuxtv.org/v4l-utils.git. Always 
compile it from
the repository so you know you are using the latest most up to date version.

Since this driver supports multiple pixelformats you need to test with the -f 
option,
which tests streaming for all pixelformats.

Obviously, there shouldn't be any FAILs :-)

I greatly simplifies the code review if I know it passes the compliance test.


Hi Hans,

You suggestion is very helpful to me.
I will give the output of the compliance test in next version.


Regards,

Hans

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

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

  drivers/net/ethernet/mellanox/mlx5/core/en.h

between commit:

  6cd392a082de ("net/mlx5e: Handle RQ flush in error cases")

from the net tree and commit:

  cb3c7fd4f839 ("net/mlx5e: Support adaptive RX coalescing")

from the net-next tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/mellanox/mlx5/core/en.h
index 943b1bd434bf,00643a116492..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@@ -143,10 -146,32 +146,31 @@@ struct mlx5e_umr_wqe 
struct mlx5_wqe_data_seg   data;
  };
  
+ static const char mlx5e_priv_flags[][ETH_GSTRING_LEN] = {
+   "rx_cqe_moder",
+ };
+ 
+ enum mlx5e_priv_flag {
+   MLX5E_PFLAG_RX_CQE_BASED_MODER = (1 << 0),
+ };
+ 
+ #define MLX5E_SET_PRIV_FLAG(priv, pflag, enable)\
+   do {\
+   if (enable) \
+   priv->pflags |= pflag;  \
+   else\
+   priv->pflags &= ~pflag; \
+   } while (0)
+ 
  #ifdef CONFIG_MLX5_CORE_EN_DCB
  #define MLX5E_MAX_BW_ALLOC 100 /* Max percentage of BW allocation */
 -#define MLX5E_MIN_BW_ALLOC 1   /* Min percentage of BW allocation */
  #endif
  
+ struct mlx5e_cq_moder {
+   u16 usec;
+   u16 pkts;
+ };
+ 
  struct mlx5e_params {
u8  log_sq_size;
u8  rq_wq_type;
@@@ -190,7 -215,7 +214,8 @@@ struct mlx5e_tstamp 
  enum {
MLX5E_RQ_STATE_POST_WQES_ENABLE,
MLX5E_RQ_STATE_UMR_WQE_IN_PROGRESS,
 +  MLX5E_RQ_STATE_FLUSH_TIMEOUT,
+   MLX5E_RQ_STATE_AM,
  };
  
  struct mlx5e_cq {
@@@ -542,9 -610,9 +614,10 @@@ struct mlx5e_priv 
struct workqueue_struct*wq;
struct work_struct update_carrier_work;
struct work_struct set_rx_mode_work;
 +  struct work_struct tx_timeout_work;
struct delayed_workupdate_stats_work;
  
+   u32pflags;
struct mlx5_core_dev  *mdev;
struct net_device *netdev;
struct mlx5e_stats stats;

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

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

  drivers/net/ethernet/mellanox/mlx5/core/en.h

between commit:

  6cd392a082de ("net/mlx5e: Handle RQ flush in error cases")

from the net tree and commit:

  cb3c7fd4f839 ("net/mlx5e: Support adaptive RX coalescing")

from the net-next tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/mellanox/mlx5/core/en.h
index 943b1bd434bf,00643a116492..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@@ -143,10 -146,32 +146,31 @@@ struct mlx5e_umr_wqe 
struct mlx5_wqe_data_seg   data;
  };
  
+ static const char mlx5e_priv_flags[][ETH_GSTRING_LEN] = {
+   "rx_cqe_moder",
+ };
+ 
+ enum mlx5e_priv_flag {
+   MLX5E_PFLAG_RX_CQE_BASED_MODER = (1 << 0),
+ };
+ 
+ #define MLX5E_SET_PRIV_FLAG(priv, pflag, enable)\
+   do {\
+   if (enable) \
+   priv->pflags |= pflag;  \
+   else\
+   priv->pflags &= ~pflag; \
+   } while (0)
+ 
  #ifdef CONFIG_MLX5_CORE_EN_DCB
  #define MLX5E_MAX_BW_ALLOC 100 /* Max percentage of BW allocation */
 -#define MLX5E_MIN_BW_ALLOC 1   /* Min percentage of BW allocation */
  #endif
  
+ struct mlx5e_cq_moder {
+   u16 usec;
+   u16 pkts;
+ };
+ 
  struct mlx5e_params {
u8  log_sq_size;
u8  rq_wq_type;
@@@ -190,7 -215,7 +214,8 @@@ struct mlx5e_tstamp 
  enum {
MLX5E_RQ_STATE_POST_WQES_ENABLE,
MLX5E_RQ_STATE_UMR_WQE_IN_PROGRESS,
 +  MLX5E_RQ_STATE_FLUSH_TIMEOUT,
+   MLX5E_RQ_STATE_AM,
  };
  
  struct mlx5e_cq {
@@@ -542,9 -610,9 +614,10 @@@ struct mlx5e_priv 
struct workqueue_struct*wq;
struct work_struct update_carrier_work;
struct work_struct set_rx_mode_work;
 +  struct work_struct tx_timeout_work;
struct delayed_workupdate_stats_work;
  
+   u32pflags;
struct mlx5_core_dev  *mdev;
struct net_device *netdev;
struct mlx5e_stats stats;

[PATCH v2 1/1] devfreq: exynos-bus: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Cc: Chanwoo Choi 
Cc: MyungJoo Ham 
Cc: Kyungmin Park 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Signed-off-by: Peter Chen 
---

Changes at v2:
- It should define node as pointer, kbuild test robot reports it


 drivers/devfreq/exynos-bus.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
index 2363d0a..4b4c63c 100644
--- a/drivers/devfreq/exynos-bus.c
+++ b/drivers/devfreq/exynos-bus.c
@@ -383,7 +383,7 @@ err_clk:
 static int exynos_bus_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
-   struct device_node *np = dev->of_node;
+   struct device_node *node, *np = dev->of_node;
struct devfreq_dev_profile *profile;
struct devfreq_simple_ondemand_data *ondemand_data;
struct devfreq_passive_data *passive_data;
@@ -415,10 +415,13 @@ static int exynos_bus_probe(struct platform_device *pdev)
goto err;
}
 
-   if (of_parse_phandle(dev->of_node, "devfreq", 0))
+   node = of_parse_phandle(dev->of_node, "devfreq", 0);
+   if (node) {
+   of_node_put(node);
goto passive;
-   else
+   } else {
ret = exynos_bus_parent_parse_of(np, bus);
+   }
 
if (ret < 0)
goto err;
-- 
1.9.1

linux-next: manual merge of the thermal-soc tree with the thermal tree

[Stephen Rothwell]

Hi Eduardo,

Today's linux-next merge of the thermal-soc tree got conflicts in:

  drivers/thermal/thermal_core.c
  drivers/thermal/thermal_helpers.c
  drivers/thermal/thermal_sysfs.c

between commits from the thermal tree and the same (or similar) patches
from the thermal-soc tree.

It looks like a the patches have been slightly changed when applied to the
thermal tree and then more commist have been applied to the thermal-soc
tree, so there are a few conflicts generated.   Please fix up these trees.

I fixed it up (I used what seemed the appropriate versions - which may
or may not be the right ones) and can carry the fixes as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

[PATCH v2 1/1] devfreq: exynos-bus: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Cc: Chanwoo Choi 
Cc: MyungJoo Ham 
Cc: Kyungmin Park 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Signed-off-by: Peter Chen 
---

Changes at v2:
- It should define node as pointer, kbuild test robot reports it


 drivers/devfreq/exynos-bus.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
index 2363d0a..4b4c63c 100644
--- a/drivers/devfreq/exynos-bus.c
+++ b/drivers/devfreq/exynos-bus.c
@@ -383,7 +383,7 @@ err_clk:
 static int exynos_bus_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
-   struct device_node *np = dev->of_node;
+   struct device_node *node, *np = dev->of_node;
struct devfreq_dev_profile *profile;
struct devfreq_simple_ondemand_data *ondemand_data;
struct devfreq_passive_data *passive_data;
@@ -415,10 +415,13 @@ static int exynos_bus_probe(struct platform_device *pdev)
goto err;
}
 
-   if (of_parse_phandle(dev->of_node, "devfreq", 0))
+   node = of_parse_phandle(dev->of_node, "devfreq", 0);
+   if (node) {
+   of_node_put(node);
goto passive;
-   else
+   } else {
ret = exynos_bus_parent_parse_of(np, bus);
+   }
 
if (ret < 0)
goto err;
-- 
1.9.1

linux-next: manual merge of the thermal-soc tree with the thermal tree

[Stephen Rothwell]

Hi Eduardo,

Today's linux-next merge of the thermal-soc tree got conflicts in:

  drivers/thermal/thermal_core.c
  drivers/thermal/thermal_helpers.c
  drivers/thermal/thermal_sysfs.c

between commits from the thermal tree and the same (or similar) patches
from the thermal-soc tree.

It looks like a the patches have been slightly changed when applied to the
thermal tree and then more commist have been applied to the thermal-soc
tree, so there are a few conflicts generated.   Please fix up these trees.

I fixed it up (I used what seemed the appropriate versions - which may
or may not be the right ones) and can carry the fixes as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: [alsa-devel] [PATCH v5 6/9] ASoC: mediatek: add mt2701 platform driver implementation.

[Garlic Tseng]

On Thu, 2016-06-30 at 21:39 +0800, Garlic Tseng wrote:
> On Wed, 2016-06-29 at 20:13 +0100, Mark Brown wrote:
> > On Fri, Jun 17, 2016 at 03:43:57PM +0800, Garlic Tseng wrote:
> > 
> > > +static int mt2701_afe_i2s_set_clkdiv(struct snd_soc_dai *dai, int div_id,
> > > +  int div)
> > > +{
> > 
> > Why are we adding a set_clkdiv() operation?  I would expect the driver
> > to be able to figure things out automatically.
> > 
> > > + case DIV_ID_MCLK_TO_BCK:
> > > + afe_priv->i2s_path[i2s_num].div_mclk_to_bck = div;
> > > + break;
> > > + case DIV_ID_BCK_TO_LRCK:
> > > + afe_priv->i2s_path[i2s_num].div_bck_to_lrck = div;
> > > + break;
> > 
> > Especially in the case where we're configuring LRCLK, that's trivial
> > when we know the sample rate which we have to know anyway.
> 
> Oh... actually I want to say 'div_mclk_over_bck' and 'div_bck_over_lrck'
> I'll fix the naming if we decide to reserve the set_clkdiv() operation.
> (omit some comment)

Hi Mark, I recognize that we can set mclk by set_sysclk, fix bck to 64fs
and let lrck be the same as sample rate so yes we don't need set_clkdiv.

Thanks for comment, I'll fix that in the next patch.

Garlic

Re: [alsa-devel] [PATCH v5 6/9] ASoC: mediatek: add mt2701 platform driver implementation.

[Garlic Tseng]

On Thu, 2016-06-30 at 21:39 +0800, Garlic Tseng wrote:
> On Wed, 2016-06-29 at 20:13 +0100, Mark Brown wrote:
> > On Fri, Jun 17, 2016 at 03:43:57PM +0800, Garlic Tseng wrote:
> > 
> > > +static int mt2701_afe_i2s_set_clkdiv(struct snd_soc_dai *dai, int div_id,
> > > +  int div)
> > > +{
> > 
> > Why are we adding a set_clkdiv() operation?  I would expect the driver
> > to be able to figure things out automatically.
> > 
> > > + case DIV_ID_MCLK_TO_BCK:
> > > + afe_priv->i2s_path[i2s_num].div_mclk_to_bck = div;
> > > + break;
> > > + case DIV_ID_BCK_TO_LRCK:
> > > + afe_priv->i2s_path[i2s_num].div_bck_to_lrck = div;
> > > + break;
> > 
> > Especially in the case where we're configuring LRCLK, that's trivial
> > when we know the sample rate which we have to know anyway.
> 
> Oh... actually I want to say 'div_mclk_over_bck' and 'div_bck_over_lrck'
> I'll fix the naming if we decide to reserve the set_clkdiv() operation.
> (omit some comment)

Hi Mark, I recognize that we can set mclk by set_sysclk, fix bck to 64fs
and let lrck be the same as sample rate so yes we don't need set_clkdiv.

Thanks for comment, I'll fix that in the next patch.

Garlic

[PATCH] Update the maximum depth of C-state from 6 to 9

[baolex.ni]

From: Chuansheng Liu 

Currently, CPUIDLE_STATE_MAX has been defined as 10 in the cpuidle head file,
and max_cstate = CPUIDLE_STATE_MAX – 1, so 9 is the right maximum depth of 
C-state.
This change is reflected in one place of the kernel-param file,
but not in the other place where I suggest changing.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 Documentation/kernel-parameters.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 82b42c9..a863737 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1661,7 +1661,7 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
 
intel_idle.max_cstate=  [KNL,HW,ACPI,X86]
0   disables intel_idle and fall back on acpi_idle.
-   1 to 6  specify maximum depth of C-state.
+   1 to 9  specify maximum depth of C-state.
 
intel_pstate=  [X86]
   disable
-- 
2.8.3

[PATCH] Update the maximum depth of C-state from 6 to 9

[baolex.ni]

From: Chuansheng Liu 

Currently, CPUIDLE_STATE_MAX has been defined as 10 in the cpuidle head file,
and max_cstate = CPUIDLE_STATE_MAX – 1, so 9 is the right maximum depth of 
C-state.
This change is reflected in one place of the kernel-param file,
but not in the other place where I suggest changing.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 Documentation/kernel-parameters.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 82b42c9..a863737 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1661,7 +1661,7 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
 
intel_idle.max_cstate=  [KNL,HW,ACPI,X86]
0   disables intel_idle and fall back on acpi_idle.
-   1 to 6  specify maximum depth of C-state.
+   1 to 9  specify maximum depth of C-state.
 
intel_pstate=  [X86]
   disable
-- 
2.8.3

Re: [PATCH perf/core v13 06/15] perf buildid-cache: Scan and import user SDT events to probe cache

[Masami Hiramatsu]

On Fri, 1 Jul 2016 15:22:01 -0300
Arnaldo Carvalho de Melo  wrote:

> Em Fri, Jul 01, 2016 at 05:04:10PM +0900, Masami Hiramatsu escreveu:
> > From: Masami Hiramatsu 
> > 
> > perf buildid-cache --add  scans given binary and add
> > the SDT events to probe cache. "sdt_" prefix is appended for
> > all SDT providers to avoid event-name clash with other pre-defined
> > events. It is possible to use the cached SDT events as other cached
> > events, via perf probe --add "sdt_:=".
> > 
> > e.g.
> >   
> >   # perf buildid-cache --add /lib/libc-2.17.so
> >   # perf probe --cache --list | head -n 5
> >   /usr/lib/libc-2.17.so (a6fb821bdf53660eb2c29f778757aef294d3d392):
> >   sdt_libc:setjmp=setjmp
> >   sdt_libc:longjmp=longjmp
> >   sdt_libc:longjmp_target=longjmp_target
> >   sdt_libc:memory_heap_new=memory_heap_new
> >   # perf probe -x /usr/lib/libc-2.17.so \
> > -a sdt_libc:memory_heap_new=memory_heap_new
> 
> Why not remove the need for that build-cache --add? I.e. go straight to:
> 
>   perf probe -x /usr/lib/libc-2.17.so -a 
> sdt_libc:memory_heap_new=memory_heap_new
> 
> And all the various steps above be done automagically?

Yes, I can add that.

> It may well be interesting to have it available as separate steps, as above,
> but requiring this cumbersome sequence to performed all the time when it seems
> possible to do automatically seems user unfriendly.

Agreed. In 11/15 added a feature to search SDT without -x, but
usually uprobes requires -x, using -x is also natural.

> 
> I am tentatively applying this and testing.

Thank you!

> 
> - Arnaldo
> 
> >   Added new event:
> > sdt_libc:memory_heap_new (on memory_heap_new
> >in /usr/lib/libc-2.17.so)
> > 
> >   You can now use it in all perf tools, such as:
> > 
> >   perf record -e sdt_libc:memory_heap_new -aR sleep 1
> > 
> >   # perf probe -l
> > sdt_libc:memory_heap_new (on new_heap+183 in /usr/lib/libc-2.17.so)
> >   
> > 
> > Note that SDT event entries in probe-cache file is somewhat different
> > from normal cached events. Normal one starts with "#", but SDTs are
> > starting with "%".
> 
> Is this still the case?
> 
> [root@jouet perf]# perf probe --cache --list
> /usr/lib64/libc-2.23.so (88686319c72f1a9d9cd514af519aa5602880bab2):
> sdt_libc:setjmp=setjmp
> sdt_libc:longjmp=longjmp
> sdt_libc:longjmp_target=longjmp_target
> sdt_libc:memory_arena_reuse_free_list=memory_arena_reuse_free_list
> sdt_libc:memory_heap_new=memory_heap_new
> sdt_libc:memory_sbrk_less=memory_sbrk_less
> sdt_libc:memory_arena_reuse_wait=memory_arena_reuse_wait
> sdt_libc:memory_arena_reuse=memory_arena_reuse
> sdt_libc:memory_arena_new=memory_arena_new
> sdt_libc:memory_arena_retry=memory_arena_retry
> sdt_libc:memory_heap_free=memory_heap_free
> sdt_libc:memory_heap_less=memory_heap_less
> sdt_libc:memory_heap_more=memory_heap_more
> sdt_libc:memory_sbrk_more=memory_sbrk_more
> sdt_libc:memory_malloc_retry=memory_malloc_retry
> sdt_libc:memory_mallopt_free_dyn_thresholds=memory_mallopt_free_dyn_thresholds
> sdt_libc:memory_realloc_retry=memory_realloc_retry
> sdt_libc:memory_memalign_retry=memory_memalign_retry
> sdt_libc:memory_calloc_retry=memory_calloc_retry
> sdt_libc:memory_mallopt=memory_mallopt
> sdt_libc:memory_mallopt_mxfast=memory_mallopt_mxfast
> sdt_libc:memory_mallopt_arena_max=memory_mallopt_arena_max
> sdt_libc:memory_mallopt_arena_test=memory_mallopt_arena_test
> sdt_libc:memory_mallopt_mmap_max=memory_mallopt_mmap_max
> sdt_libc:memory_mallopt_mmap_threshold=memory_mallopt_mmap_threshold
> sdt_libc:memory_mallopt_top_pad=memory_mallopt_top_pad
> sdt_libc:memory_mallopt_trim_threshold=memory_mallopt_trim_threshold
> sdt_libc:memory_mallopt_perturb=memory_mallopt_perturb
> sdt_libc:memory_mallopt_check_action=memory_mallopt_check_action
> sdt_libc:lll_lock_wait_private=lll_lock_wait_private
> [root@jouet perf]# 
> 
> 
>  
> > Signed-off-by: Masami Hiramatsu 
> > Signed-off-by: Masami Hiramatsu 
> > ---
> >  Changes in v11:
> >   - Warn if SDT scanning/updating are failed.
> >  Changes in v10:
> >   - Update Documentation/perf-buildid-cache.txt too.
> >  Changes in v4:
> >   - Fix a bug to copy correct group name to entries.
> >   - Fix to consolidate same-name entries.
> > ---
> >  tools/perf/Documentation/perf-buildid-cache.txt |3 +
> >  tools/perf/util/build-id.c  |   30 ++
> >  tools/perf/util/probe-file.c|   69 
> > ++-
> >  tools/perf/util/probe-file.h|2 +
> >  4 files changed, 101 insertions(+), 3 deletions(-)
> > 
> > diff --git a/tools/perf/Documentation/perf-buildid-cache.txt 
> > b/tools/perf/Documentation/perf-buildid-cache.txt
> > index dd07b55..058064d 100644
> > --- a/tools/perf/Documentation/perf-buildid-cache.txt
> > +++ b/tools/perf/Documentation/perf-buildid-cache.txt
> > @@ -15,6 +15,9 @@ DESCRIPTION
> >  

Re: [PATCH perf/core v13 06/15] perf buildid-cache: Scan and import user SDT events to probe cache

[Masami Hiramatsu]

On Fri, 1 Jul 2016 15:22:01 -0300
Arnaldo Carvalho de Melo  wrote:

> Em Fri, Jul 01, 2016 at 05:04:10PM +0900, Masami Hiramatsu escreveu:
> > From: Masami Hiramatsu 
> > 
> > perf buildid-cache --add  scans given binary and add
> > the SDT events to probe cache. "sdt_" prefix is appended for
> > all SDT providers to avoid event-name clash with other pre-defined
> > events. It is possible to use the cached SDT events as other cached
> > events, via perf probe --add "sdt_:=".
> > 
> > e.g.
> >   
> >   # perf buildid-cache --add /lib/libc-2.17.so
> >   # perf probe --cache --list | head -n 5
> >   /usr/lib/libc-2.17.so (a6fb821bdf53660eb2c29f778757aef294d3d392):
> >   sdt_libc:setjmp=setjmp
> >   sdt_libc:longjmp=longjmp
> >   sdt_libc:longjmp_target=longjmp_target
> >   sdt_libc:memory_heap_new=memory_heap_new
> >   # perf probe -x /usr/lib/libc-2.17.so \
> > -a sdt_libc:memory_heap_new=memory_heap_new
> 
> Why not remove the need for that build-cache --add? I.e. go straight to:
> 
>   perf probe -x /usr/lib/libc-2.17.so -a 
> sdt_libc:memory_heap_new=memory_heap_new
> 
> And all the various steps above be done automagically?

Yes, I can add that.

> It may well be interesting to have it available as separate steps, as above,
> but requiring this cumbersome sequence to performed all the time when it seems
> possible to do automatically seems user unfriendly.

Agreed. In 11/15 added a feature to search SDT without -x, but
usually uprobes requires -x, using -x is also natural.

> 
> I am tentatively applying this and testing.

Thank you!

> 
> - Arnaldo
> 
> >   Added new event:
> > sdt_libc:memory_heap_new (on memory_heap_new
> >in /usr/lib/libc-2.17.so)
> > 
> >   You can now use it in all perf tools, such as:
> > 
> >   perf record -e sdt_libc:memory_heap_new -aR sleep 1
> > 
> >   # perf probe -l
> > sdt_libc:memory_heap_new (on new_heap+183 in /usr/lib/libc-2.17.so)
> >   
> > 
> > Note that SDT event entries in probe-cache file is somewhat different
> > from normal cached events. Normal one starts with "#", but SDTs are
> > starting with "%".
> 
> Is this still the case?
> 
> [root@jouet perf]# perf probe --cache --list
> /usr/lib64/libc-2.23.so (88686319c72f1a9d9cd514af519aa5602880bab2):
> sdt_libc:setjmp=setjmp
> sdt_libc:longjmp=longjmp
> sdt_libc:longjmp_target=longjmp_target
> sdt_libc:memory_arena_reuse_free_list=memory_arena_reuse_free_list
> sdt_libc:memory_heap_new=memory_heap_new
> sdt_libc:memory_sbrk_less=memory_sbrk_less
> sdt_libc:memory_arena_reuse_wait=memory_arena_reuse_wait
> sdt_libc:memory_arena_reuse=memory_arena_reuse
> sdt_libc:memory_arena_new=memory_arena_new
> sdt_libc:memory_arena_retry=memory_arena_retry
> sdt_libc:memory_heap_free=memory_heap_free
> sdt_libc:memory_heap_less=memory_heap_less
> sdt_libc:memory_heap_more=memory_heap_more
> sdt_libc:memory_sbrk_more=memory_sbrk_more
> sdt_libc:memory_malloc_retry=memory_malloc_retry
> sdt_libc:memory_mallopt_free_dyn_thresholds=memory_mallopt_free_dyn_thresholds
> sdt_libc:memory_realloc_retry=memory_realloc_retry
> sdt_libc:memory_memalign_retry=memory_memalign_retry
> sdt_libc:memory_calloc_retry=memory_calloc_retry
> sdt_libc:memory_mallopt=memory_mallopt
> sdt_libc:memory_mallopt_mxfast=memory_mallopt_mxfast
> sdt_libc:memory_mallopt_arena_max=memory_mallopt_arena_max
> sdt_libc:memory_mallopt_arena_test=memory_mallopt_arena_test
> sdt_libc:memory_mallopt_mmap_max=memory_mallopt_mmap_max
> sdt_libc:memory_mallopt_mmap_threshold=memory_mallopt_mmap_threshold
> sdt_libc:memory_mallopt_top_pad=memory_mallopt_top_pad
> sdt_libc:memory_mallopt_trim_threshold=memory_mallopt_trim_threshold
> sdt_libc:memory_mallopt_perturb=memory_mallopt_perturb
> sdt_libc:memory_mallopt_check_action=memory_mallopt_check_action
> sdt_libc:lll_lock_wait_private=lll_lock_wait_private
> [root@jouet perf]# 
> 
> 
>  
> > Signed-off-by: Masami Hiramatsu 
> > Signed-off-by: Masami Hiramatsu 
> > ---
> >  Changes in v11:
> >   - Warn if SDT scanning/updating are failed.
> >  Changes in v10:
> >   - Update Documentation/perf-buildid-cache.txt too.
> >  Changes in v4:
> >   - Fix a bug to copy correct group name to entries.
> >   - Fix to consolidate same-name entries.
> > ---
> >  tools/perf/Documentation/perf-buildid-cache.txt |3 +
> >  tools/perf/util/build-id.c  |   30 ++
> >  tools/perf/util/probe-file.c|   69 
> > ++-
> >  tools/perf/util/probe-file.h|2 +
> >  4 files changed, 101 insertions(+), 3 deletions(-)
> > 
> > diff --git a/tools/perf/Documentation/perf-buildid-cache.txt 
> > b/tools/perf/Documentation/perf-buildid-cache.txt
> > index dd07b55..058064d 100644
> > --- a/tools/perf/Documentation/perf-buildid-cache.txt
> > +++ b/tools/perf/Documentation/perf-buildid-cache.txt
> > @@ -15,6 +15,9 @@ DESCRIPTION
> >  This command manages the build-id cache. It can add, remove, update and 
> > purge
> >  files to/from the 

[PATCH perf/core] [BUGFIX] perf-probe: Fix to show correct error message for $vars and $params

[Masami Hiramatsu]

Fix to show correct error messages for $vars and $params because
those special variables requires debug information to find the
real variables or function parameters.

E.g. without this fix;
  
  # perf probe -x /lib64/libc-2.23.so getaddrinfo \$params
  Failed to write event: Invalid argument
  Please upgrade your kernel to at least 3.14 to have access to feature $params
Error: Failed to add events.
  
Perf ends up with an error, but the message is not correct.
With this fix, perf shows correct error message as below.
  
  # perf probe -x /lib64/libc-2.23.so getaddrinfo \$params
  The /usr/lib64/libc-2.23.so file has no debug information.
  Rebuild with -g, or install an appropriate debuginfo package.
Error: Failed to add events.
  

Reported-by: Arnaldo Carvalho de Melo 
Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-event.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 55f41d5..dcc906b 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1542,7 +1542,9 @@ bool perf_probe_event_need_dwarf(struct perf_probe_event 
*pev)
return true;
 
for (i = 0; i < pev->nargs; i++)
-   if (is_c_varname(pev->args[i].var))
+   if (is_c_varname(pev->args[i].var) ||
+   !strcmp(pev->args[i].var, "$params") ||
+   !strcmp(pev->args[i].var, "$vars"))
return true;
 
return false;

[PATCH perf/core] [BUGFIX] perf-probe: Fix to show correct error message for $vars and $params

[Masami Hiramatsu]

Fix to show correct error messages for $vars and $params because
those special variables requires debug information to find the
real variables or function parameters.

E.g. without this fix;
  
  # perf probe -x /lib64/libc-2.23.so getaddrinfo \$params
  Failed to write event: Invalid argument
  Please upgrade your kernel to at least 3.14 to have access to feature $params
Error: Failed to add events.
  
Perf ends up with an error, but the message is not correct.
With this fix, perf shows correct error message as below.
  
  # perf probe -x /lib64/libc-2.23.so getaddrinfo \$params
  The /usr/lib64/libc-2.23.so file has no debug information.
  Rebuild with -g, or install an appropriate debuginfo package.
Error: Failed to add events.
  

Reported-by: Arnaldo Carvalho de Melo 
Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-event.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 55f41d5..dcc906b 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1542,7 +1542,9 @@ bool perf_probe_event_need_dwarf(struct perf_probe_event 
*pev)
return true;
 
for (i = 0; i < pev->nargs; i++)
-   if (is_c_varname(pev->args[i].var))
+   if (is_c_varname(pev->args[i].var) ||
+   !strcmp(pev->args[i].var, "$params") ||
+   !strcmp(pev->args[i].var, "$vars"))
return true;
 
return false;

[PATCH] regulator: core: Assign bool value to variable has_full_constraints

[Baoquan He]

In commit 21cf891a (regulator: Make regulator_has_full_constraints a bool)
type of variable has_full_constraints is changed to bool, so assign 'true'
to has_full_constraints here.

Signed-off-by: Baoquan He 
---
 drivers/regulator/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index ec8184d5..a4f28b5 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -4193,7 +4193,7 @@ EXPORT_SYMBOL_GPL(regulator_suspend_finish);
  */
 void regulator_has_full_constraints(void)
 {
-   has_full_constraints = 1;
+   has_full_constraints = true;
 }
 EXPORT_SYMBOL_GPL(regulator_has_full_constraints);
 
-- 
2.5.5

[PATCH] regulator: core: Assign bool value to variable has_full_constraints

[Baoquan He]

In commit 21cf891a (regulator: Make regulator_has_full_constraints a bool)
type of variable has_full_constraints is changed to bool, so assign 'true'
to has_full_constraints here.

Signed-off-by: Baoquan He 
---
 drivers/regulator/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index ec8184d5..a4f28b5 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -4193,7 +4193,7 @@ EXPORT_SYMBOL_GPL(regulator_suspend_finish);
  */
 void regulator_has_full_constraints(void)
 {
-   has_full_constraints = 1;
+   has_full_constraints = true;
 }
 EXPORT_SYMBOL_GPL(regulator_has_full_constraints);
 
-- 
2.5.5

Re: [PATCH perf/core v13 02/15] perf probe: Show all cached probes

[Masami Hiramatsu]

On Fri, 1 Jul 2016 10:51:04 -0300
Arnaldo Carvalho de Melo  wrote:

> Em Fri, Jul 01, 2016 at 05:03:26PM +0900, Masami Hiramatsu escreveu:
> > From: Masami Hiramatsu 
> > 
> > perf probe --list shows all cached probes when --cache
> > is given. Each caches are shown with on which binary that
> > probed. e.g.
> >   -
> >   # perf probe --cache vfs_read \$params
> 
> This one works:
> 
> # perf probe --cache vfs_read \$params
> Added new event:
>   probe:vfs_read   (on vfs_read with $params)
> 
> You can now use it in all perf tools, such as:
> 
>   perf record -e probe:vfs_read -aR sleep 1
> 
> #
> 
> >   # perf probe --cache -x /lib64/libc-2.17.so getaddrinfo \$params
> 
> But this one doesn't and provides a funny message:
> 
> [root@jouet perf]# perf probe --cache -x /lib64/libc-2.23.so getaddrinfo 
> \$params
> Failed to write event: Invalid argument
> Please upgrade your kernel to at least 3.14 to have access to feature $params
>   Error: Failed to add events.

Ah, OK, $params requires debuginfo. It this error message is not correct.
I'll send a fix soon.

Thanks!!


-- 
Masami Hiramatsu 

Re: [PATCH v5 01/22] sh: Add sh-specific early_init_dt_reserve_memory_arch

[Rich Felker]

On Mon, Jul 04, 2016 at 01:46:21AM +0900, Yoshinori Sato wrote:
> sh used P1 address space in early device tree.
> So need convert P1 to physical address before reserve memory.
> 
> Signed-off-by: Yoshinori Sato 
> ---
>  arch/sh/boards/of-generic.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/sh/boards/of-generic.c b/arch/sh/boards/of-generic.c
> index 57d45dc..8dbf978 100644
> --- a/arch/sh/boards/of-generic.c
> +++ b/arch/sh/boards/of-generic.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -203,3 +204,14 @@ static int __init sh_of_device_init(void)
>   return 0;
>  }
>  arch_initcall_sync(sh_of_device_init);
> +
> +int __init early_init_dt_reserve_memory_arch(phys_addr_t base,
> +  phys_addr_t size, bool nomap)
> +{
> + if (nomap)
> + return memblock_remove(base, size);
> +
> + if (base >= P1SEG)
> + base &= ~P1SEG;
> + return memblock_reserve(base, size);
> +}
> -- 

I think we need a consistent form of physical memory addressing in the
DT that doesn't require this. Hard-coding details of the segmented
memory model all over the place does not look like a good idea; it's
going to badly break anything with full 32-bit which I believe some
SH-4 models had (those with PMB?) and which J3/J4 will almost
certainly have.

Rich

Re: [PATCH perf/core v13 02/15] perf probe: Show all cached probes

[Masami Hiramatsu]

On Fri, 1 Jul 2016 10:51:04 -0300
Arnaldo Carvalho de Melo  wrote:

> Em Fri, Jul 01, 2016 at 05:03:26PM +0900, Masami Hiramatsu escreveu:
> > From: Masami Hiramatsu 
> > 
> > perf probe --list shows all cached probes when --cache
> > is given. Each caches are shown with on which binary that
> > probed. e.g.
> >   -
> >   # perf probe --cache vfs_read \$params
> 
> This one works:
> 
> # perf probe --cache vfs_read \$params
> Added new event:
>   probe:vfs_read   (on vfs_read with $params)
> 
> You can now use it in all perf tools, such as:
> 
>   perf record -e probe:vfs_read -aR sleep 1
> 
> #
> 
> >   # perf probe --cache -x /lib64/libc-2.17.so getaddrinfo \$params
> 
> But this one doesn't and provides a funny message:
> 
> [root@jouet perf]# perf probe --cache -x /lib64/libc-2.23.so getaddrinfo 
> \$params
> Failed to write event: Invalid argument
> Please upgrade your kernel to at least 3.14 to have access to feature $params
>   Error: Failed to add events.

Ah, OK, $params requires debuginfo. It this error message is not correct.
I'll send a fix soon.

Thanks!!


-- 
Masami Hiramatsu 

Re: [PATCH v5 01/22] sh: Add sh-specific early_init_dt_reserve_memory_arch

[Rich Felker]

On Mon, Jul 04, 2016 at 01:46:21AM +0900, Yoshinori Sato wrote:
> sh used P1 address space in early device tree.
> So need convert P1 to physical address before reserve memory.
> 
> Signed-off-by: Yoshinori Sato 
> ---
>  arch/sh/boards/of-generic.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/sh/boards/of-generic.c b/arch/sh/boards/of-generic.c
> index 57d45dc..8dbf978 100644
> --- a/arch/sh/boards/of-generic.c
> +++ b/arch/sh/boards/of-generic.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -203,3 +204,14 @@ static int __init sh_of_device_init(void)
>   return 0;
>  }
>  arch_initcall_sync(sh_of_device_init);
> +
> +int __init early_init_dt_reserve_memory_arch(phys_addr_t base,
> +  phys_addr_t size, bool nomap)
> +{
> + if (nomap)
> + return memblock_remove(base, size);
> +
> + if (base >= P1SEG)
> + base &= ~P1SEG;
> + return memblock_reserve(base, size);
> +}
> -- 

I think we need a consistent form of physical memory addressing in the
DT that doesn't require this. Hard-coding details of the segmented
memory model all over the place does not look like a good idea; it's
going to badly break anything with full 32-bit which I believe some
SH-4 models had (those with PMB?) and which J3/J4 will almost
certainly have.

Rich

Re: [alsa-devel] [PATCH v5 7/9] ASoC: bt-sco: extend rate and add a general compatible string

[Garlic Tseng]

On Sat, 2016-07-02 at 17:05 +0800, Chen-Yu Tsai wrote:

Hi,

> Could we also make this driver directly configurable from Kconfig,
> and not just selected by platforms (currently Samsung) or by building
> all coddecs?
> 
> Thanks
> ChenYu

I'll add configure prompt for SND_SOC_BT_SCO in next patchset.
Thanks for comment.

Garlic

Re: [alsa-devel] [PATCH v5 7/9] ASoC: bt-sco: extend rate and add a general compatible string

[Garlic Tseng]

On Sat, 2016-07-02 at 17:05 +0800, Chen-Yu Tsai wrote:

Hi,

> Could we also make this driver directly configurable from Kconfig,
> and not just selected by platforms (currently Samsung) or by building
> all coddecs?
> 
> Thanks
> ChenYu

I'll add configure prompt for SND_SOC_BT_SCO in next patchset.
Thanks for comment.

Garlic

Update the maximum depth of C-state from 6 to 9

[baolex.ni]

Currently, CPUIDLE_STATE_MAX has been defined as 10 in the cpuidle head file,
and max_cstate = CPUIDLE_STATE_MAX – 1, so 9 is the right maximum depth of 
C-state.
This change is reflected in one place of the kernel-param file,
but not in the other place where I suggest changing.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 Documentation/kernel-parameters.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 82b42c9..a863737 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1661,7 +1661,7 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
 
intel_idle.max_cstate=  [KNL,HW,ACPI,X86]
0   disables intel_idle and fall back on acpi_idle.
-   1 to 6  specify maximum depth of C-state.
+   1 to 9  specify maximum depth of C-state.
 
intel_pstate=  [X86]
   disable
-- 
2.8.3

Re: [PATCH v5 15/22] sh: Move common PCI stuff to arch/sh/kernel

[Rich Felker]

On Mon, Jul 04, 2016 at 01:46:35AM +0900, Yoshinori Sato wrote:
> Signed-off-by: Yoshinori Sato 
> ---
>  arch/sh/drivers/pci/Makefile |   2 -
>  arch/sh/drivers/pci/common.c | 162 
>  arch/sh/drivers/pci/pci.c| 320 
>  arch/sh/kernel/Makefile  |   2 +
>  arch/sh/kernel/pci-common.c  | 162 
>  arch/sh/kernel/pci.c | 342 
> +++
>  6 files changed, 506 insertions(+), 484 deletions(-)
>  delete mode 100644 arch/sh/drivers/pci/common.c
>  delete mode 100644 arch/sh/drivers/pci/pci.c
>  create mode 100644 arch/sh/kernel/pci-common.c
>  create mode 100644 arch/sh/kernel/pci.c
> 
> diff --git a/arch/sh/drivers/pci/Makefile b/arch/sh/drivers/pci/Makefile
> index 82f0a33..fffbede 100644
> --- a/arch/sh/drivers/pci/Makefile
> +++ b/arch/sh/drivers/pci/Makefile
> @@ -1,8 +1,6 @@
>  #
>  # Makefile for the PCI specific kernel interface routines under Linux.
>  #
> -obj-y+= common.o pci.o
> -
>  obj-$(CONFIG_CPU_SUBTYPE_SH7751) += pci-sh7751.o ops-sh4.o
>  obj-$(CONFIG_CPU_SUBTYPE_SH7751R)+= pci-sh7751.o ops-sh4.o
>  obj-$(CONFIG_CPU_SUBTYPE_SH7763) += pci-sh7780.o ops-sh4.o
> diff --git a/arch/sh/drivers/pci/common.c b/arch/sh/drivers/pci/common.c
> deleted file mode 100644
> index dbf1381..000
> --- a/arch/sh/drivers/pci/common.c
> +++ /dev/null
> @@ -1,162 +0,0 @@
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -/*
> - * These functions are used early on before PCI scanning is done
> - * and all of the pci_dev and pci_bus structures have been created.
> - */
> -static struct pci_dev *fake_pci_dev(struct pci_channel *hose,
> - int top_bus, int busnr, int devfn)
> -{
> - static struct pci_dev dev;
> - static struct pci_bus bus;
> -
> - dev.bus = 
> - dev.sysdata = hose;
> - dev.devfn = devfn;
> - bus.number = busnr;
> - bus.sysdata = hose;
> - bus.ops = hose->pci_ops;
> -
> - if(busnr != top_bus)
> - /* Fake a parent bus structure. */
> - bus.parent = 
> - else
> - bus.parent = NULL;
> -
> - return 
> -}
> -
> -#define EARLY_PCI_OP(rw, size, type) \
> -int __init early_##rw##_config_##size(struct pci_channel *hose,  
> \
> - int top_bus, int bus, int devfn, int offset, type value)\
> -{\
> - return pci_##rw##_config_##size(\
> - fake_pci_dev(hose, top_bus, bus, devfn),\
> - offset, value); \
> -}
> -
> -EARLY_PCI_OP(read, byte, u8 *)
> -EARLY_PCI_OP(read, word, u16 *)
> -EARLY_PCI_OP(read, dword, u32 *)
> -EARLY_PCI_OP(write, byte, u8)
> -EARLY_PCI_OP(write, word, u16)
> -EARLY_PCI_OP(write, dword, u32)
> -
> -int __init pci_is_66mhz_capable(struct pci_channel *hose,
> - int top_bus, int current_bus)
> -{
> - u32 pci_devfn;
> - unsigned short vid;
> - int cap66 = -1;
> - u16 stat;
> -
> - printk(KERN_INFO "PCI: Checking 66MHz capabilities...\n");
> -
> - for (pci_devfn = 0; pci_devfn < 0xff; pci_devfn++) {
> - if (PCI_FUNC(pci_devfn))
> - continue;
> - if (early_read_config_word(hose, top_bus, current_bus,
> -pci_devfn, PCI_VENDOR_ID, ) !=
> - PCIBIOS_SUCCESSFUL)
> - continue;
> - if (vid == 0x)
> - continue;
> -
> - /* check 66MHz capability */
> - if (cap66 < 0)
> - cap66 = 1;
> - if (cap66) {
> - early_read_config_word(hose, top_bus, current_bus,
> -pci_devfn, PCI_STATUS, );
> - if (!(stat & PCI_STATUS_66MHZ)) {
> - printk(KERN_DEBUG
> -"PCI: %02x:%02x not 66MHz capable.\n",
> -current_bus, pci_devfn);
> - cap66 = 0;
> - break;
> - }
> - }
> - }
> -
> - return cap66 > 0;
> -}
> -
> -static void pcibios_enable_err(unsigned long __data)
> -{
> - struct pci_channel *hose = (struct pci_channel *)__data;
> -
> - del_timer(>err_timer);
> - printk(KERN_DEBUG "PCI: re-enabling error IRQ.\n");
> - enable_irq(hose->err_irq);
> -}
> -
> -static void pcibios_enable_serr(unsigned long __data)
> -{
> - struct pci_channel *hose = (struct pci_channel *)__data;
> -
> - del_timer(>serr_timer);
> - printk(KERN_DEBUG "PCI: re-enabling system error IRQ.\n");
> - enable_irq(hose->serr_irq);
> -}
> -
> -void