Re: [PATCH 20/32] magic number for rscctrl file system

[Nilay Vaish]

On 12 July 2016 at 20:02, Fenghua Yu  wrote:
> From: Fenghua Yu 
>
> Signed-off-by: Fenghua Yu 
> Reviewed-by: Tony Luck 
> ---
>  include/uapi/linux/magic.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
> index 546b388..655036a 100644
> --- a/include/uapi/linux/magic.h
> +++ b/include/uapi/linux/magic.h
> @@ -57,6 +57,8 @@
>  #define CGROUP_SUPER_MAGIC 0x27e0eb
>  #define CGROUP2_SUPER_MAGIC0x63677270
>
> +#define RDTGROUP_SUPER_MAGIC   0x7655821
> +
>
>  #define STACK_END_MAGIC0x57AC6E9D


Just for my information, can you tell me how did you choose the magic number?

--
Nilay

Re: [PATCH 20/32] magic number for rscctrl file system

[Nilay Vaish]

On 12 July 2016 at 20:02, Fenghua Yu  wrote:
> From: Fenghua Yu 
>
> Signed-off-by: Fenghua Yu 
> Reviewed-by: Tony Luck 
> ---
>  include/uapi/linux/magic.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
> index 546b388..655036a 100644
> --- a/include/uapi/linux/magic.h
> +++ b/include/uapi/linux/magic.h
> @@ -57,6 +57,8 @@
>  #define CGROUP_SUPER_MAGIC 0x27e0eb
>  #define CGROUP2_SUPER_MAGIC0x63677270
>
> +#define RDTGROUP_SUPER_MAGIC   0x7655821
> +
>
>  #define STACK_END_MAGIC0x57AC6E9D


Just for my information, can you tell me how did you choose the magic number?

--
Nilay

Re: [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash

[Heiko Carstens]

On Wed, Jul 27, 2016 at 11:46:01PM -0400, Theodore Ts'o wrote:
> On Wed, Jul 27, 2016 at 09:14:00AM +0200, Heiko Carstens wrote:
> > it looks like your patch "random: make /dev/urandom scalable for silly
> > userspace programs" within linux-next seems to be a bit broken:
> > 
> > It causes this allocation failure and subsequent crash on s390 with fake
> > NUMA enabled
> 
> Thanks for reporting this.  This patch fixes things for you, yes?
> 
>   - Ted

Yes, it does. It's actually the same what I did to fix this ;)

> commit 59b8d4f1f5d26e4ca92172ff6dcd1492cdb39613
> Author: Theodore Ts'o 
> Date:   Wed Jul 27 23:30:25 2016 -0400
> 
> random: use for_each_online_node() to iterate over NUMA nodes
> 
> This fixes a crash on s390 with fake NUMA enabled.
> 
> Reported-by: Heiko Carstens 
> Fixes: 1e7f583af67b ("random: make /dev/urandom scalable for silly 
> userspace programs")
> Signed-off-by: Theodore Ts'o 
> 
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index 8d0af74..7f06224 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1668,13 +1668,12 @@ static int rand_initialize(void)
>  #ifdef CONFIG_NUMA
>   pool = kmalloc(num_nodes * sizeof(void *),
>  GFP_KERNEL|__GFP_NOFAIL|__GFP_ZERO);
> - for (i=0; i < num_nodes; i++) {
> + for_each_online_node(i) {
>   crng = kmalloc_node(sizeof(struct crng_state),
>   GFP_KERNEL | __GFP_NOFAIL, i);
>   spin_lock_init(>lock);
>   crng_initialize(crng);
>   pool[i] = crng;
> -
>   }
>   mb();
>   crng_node_pool = pool;
> 

Re: [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash

[Heiko Carstens]

On Wed, Jul 27, 2016 at 11:46:01PM -0400, Theodore Ts'o wrote:
> On Wed, Jul 27, 2016 at 09:14:00AM +0200, Heiko Carstens wrote:
> > it looks like your patch "random: make /dev/urandom scalable for silly
> > userspace programs" within linux-next seems to be a bit broken:
> > 
> > It causes this allocation failure and subsequent crash on s390 with fake
> > NUMA enabled
> 
> Thanks for reporting this.  This patch fixes things for you, yes?
> 
>   - Ted

Yes, it does. It's actually the same what I did to fix this ;)

> commit 59b8d4f1f5d26e4ca92172ff6dcd1492cdb39613
> Author: Theodore Ts'o 
> Date:   Wed Jul 27 23:30:25 2016 -0400
> 
> random: use for_each_online_node() to iterate over NUMA nodes
> 
> This fixes a crash on s390 with fake NUMA enabled.
> 
> Reported-by: Heiko Carstens 
> Fixes: 1e7f583af67b ("random: make /dev/urandom scalable for silly 
> userspace programs")
> Signed-off-by: Theodore Ts'o 
> 
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index 8d0af74..7f06224 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1668,13 +1668,12 @@ static int rand_initialize(void)
>  #ifdef CONFIG_NUMA
>   pool = kmalloc(num_nodes * sizeof(void *),
>  GFP_KERNEL|__GFP_NOFAIL|__GFP_ZERO);
> - for (i=0; i < num_nodes; i++) {
> + for_each_online_node(i) {
>   crng = kmalloc_node(sizeof(struct crng_state),
>   GFP_KERNEL | __GFP_NOFAIL, i);
>   spin_lock_init(>lock);
>   crng_initialize(crng);
>   pool[i] = crng;
> -
>   }
>   mb();
>   crng_node_pool = pool;
> 

Re: bcache super block corruption with non 4k pages

[Kent Overstreet]

On Wed, Jul 27, 2016 at 05:16:36PM +0200, Stefan Bader wrote:
> So here is another attempt which does half the proposed changes. And before 
> you
> point out that it looks still ugly, let me explain some reasons. The goal for 
> me
> would be to have something as small as possible to be acceptable as stable 
> change.
> And the part about putting a bio on the stack and using submit_bio_wait: I
> believe you meant in read_super to replace the __bread. I was thinking about
> that but in the end it seemed to make the change unnecessary big. Whether 
> using
> __bread or submit_bio_wait, in both cases and without needing to make more
> changes on the write side, read_super has to return the in-memory and on-disk
> variant of the superblock. So as long as nothing that is related to __bread is
> leaked out of read_super, it is much better than what is there now. And I 
> remain
> as small as possible for the delta.

I like that approach much better. I suppose it's not _strictly_ necessary to rip
out the __bread()...

Only other comment is that you shouldn't have to pass the buffer to
__write_super() - I'd just move the bch_bio_map() call to when the struct
cache/cached_dev is being initialized (or rip it out and initialize the bvec by
hand) and never touch it after that.

> So there is one part of the patch which I find hard to do in a better manner 
> but
> is a bit ugly: and that is to sanely free the sb_disk_data blob on all error
> paths but not on success when it is assigned to either cache or cached_dev.
> Could possibly pass the address of the pointer and then clear it inside the
> called functions. Not sure that would be much less strange...

Yeah that is a hassle - that's why in the 4k superblocks patch in bcache-dev I
added that "disk_sb" struct - it owns the buffer and random other crap. You
could read that patch for ideas if you want, look at how it transfers ownership
of the disk_sb. 

> From 391682e2329a6f8608bfc7628b6c8a0afa9a5d98 Mon Sep 17 00:00:00 2001
> From: Stefan Bader 
> Date: Tue, 26 Jul 2016 18:47:21 +0200
> Subject: [PATCH] bcache: read_super: handle architectures with more than 4k
>  page size
> 
> There is no guarantee that the superblock which __bread returns in
> a buffer_head starts at offset 0 when an architecture has bigger
> pages than 4k (the used sector size).
> 
> This is the attempt to fix this with the minimum amount of change
> by having a buffer allocated with kmalloc that holds the superblock
> data as it is on disk.
> This buffer can then be passed to bch_map_bio which will set up the
> bio_vec correctly.
> 
> Signed-off-by: Stefan Bader 
> ---
>  drivers/md/bcache/bcache.h |  2 ++
>  drivers/md/bcache/super.c  | 61 
> ++
>  2 files changed, 36 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/md/bcache/bcache.h b/drivers/md/bcache/bcache.h
> index 6b420a5..3c48927 100644
> --- a/drivers/md/bcache/bcache.h
> +++ b/drivers/md/bcache/bcache.h
> @@ -295,6 +295,7 @@ struct cached_dev {
>   struct cache_sb sb;
>   struct bio  sb_bio;
>   struct bio_vec  sb_bv[1];
> + void*sb_disk_data;
>   struct closure  sb_write;
>   struct semaphoresb_write_mutex;
>  
> @@ -382,6 +383,7 @@ struct cache {
>   struct cache_sb sb;
>   struct bio  sb_bio;
>   struct bio_vec  sb_bv[1];
> + void*sb_disk_data;
>  
>   struct kobject  kobj;
>   struct block_device *bdev;
> diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
> index e169739..f017f69 100644
> --- a/drivers/md/bcache/super.c
> +++ b/drivers/md/bcache/super.c
> @@ -62,7 +62,7 @@ struct workqueue_struct *bcache_wq;
>  /* Superblock */
>  
>  static const char *read_super(struct cache_sb *sb, struct block_device *bdev,
> -   struct page **res)
> +   void *sb_data)
>  {
>   const char *err;
>   struct cache_sb *s;
> @@ -191,8 +191,7 @@ static const char *read_super(struct cache_sb *sb, struct 
> block_device *bdev,
>   sb->last_mount = get_seconds();
>   err = NULL;
>  
> - get_page(bh->b_page);
> - *res = bh->b_page;
> + memcpy(sb_data, bh->b_data, SB_SIZE);
>  err:
>   put_bh(bh);
>   return err;
> @@ -206,15 +205,15 @@ static void write_bdev_super_endio(struct bio *bio)
>   closure_put(>sb_write);
>  }
>  
> -static void __write_super(struct cache_sb *sb, struct bio *bio)
> +static void __write_super(struct cache_sb *sb, struct bio *bio, void 
> *sb_data)
>  {
> - struct cache_sb *out = page_address(bio->bi_io_vec[0].bv_page);
> + struct cache_sb *out = sb_data;
>   unsigned i;
>  
>   bio->bi_iter.bi_sector  = SB_SECTOR;
>   bio->bi_rw  = REQ_SYNC|REQ_META;
>   bio->bi_iter.bi_size= SB_SIZE;
> - bch_bio_map(bio, 

Re: bcache super block corruption with non 4k pages

[Kent Overstreet]

On Wed, Jul 27, 2016 at 05:16:36PM +0200, Stefan Bader wrote:
> So here is another attempt which does half the proposed changes. And before 
> you
> point out that it looks still ugly, let me explain some reasons. The goal for 
> me
> would be to have something as small as possible to be acceptable as stable 
> change.
> And the part about putting a bio on the stack and using submit_bio_wait: I
> believe you meant in read_super to replace the __bread. I was thinking about
> that but in the end it seemed to make the change unnecessary big. Whether 
> using
> __bread or submit_bio_wait, in both cases and without needing to make more
> changes on the write side, read_super has to return the in-memory and on-disk
> variant of the superblock. So as long as nothing that is related to __bread is
> leaked out of read_super, it is much better than what is there now. And I 
> remain
> as small as possible for the delta.

I like that approach much better. I suppose it's not _strictly_ necessary to rip
out the __bread()...

Only other comment is that you shouldn't have to pass the buffer to
__write_super() - I'd just move the bch_bio_map() call to when the struct
cache/cached_dev is being initialized (or rip it out and initialize the bvec by
hand) and never touch it after that.

> So there is one part of the patch which I find hard to do in a better manner 
> but
> is a bit ugly: and that is to sanely free the sb_disk_data blob on all error
> paths but not on success when it is assigned to either cache or cached_dev.
> Could possibly pass the address of the pointer and then clear it inside the
> called functions. Not sure that would be much less strange...

Yeah that is a hassle - that's why in the 4k superblocks patch in bcache-dev I
added that "disk_sb" struct - it owns the buffer and random other crap. You
could read that patch for ideas if you want, look at how it transfers ownership
of the disk_sb. 

> From 391682e2329a6f8608bfc7628b6c8a0afa9a5d98 Mon Sep 17 00:00:00 2001
> From: Stefan Bader 
> Date: Tue, 26 Jul 2016 18:47:21 +0200
> Subject: [PATCH] bcache: read_super: handle architectures with more than 4k
>  page size
> 
> There is no guarantee that the superblock which __bread returns in
> a buffer_head starts at offset 0 when an architecture has bigger
> pages than 4k (the used sector size).
> 
> This is the attempt to fix this with the minimum amount of change
> by having a buffer allocated with kmalloc that holds the superblock
> data as it is on disk.
> This buffer can then be passed to bch_map_bio which will set up the
> bio_vec correctly.
> 
> Signed-off-by: Stefan Bader 
> ---
>  drivers/md/bcache/bcache.h |  2 ++
>  drivers/md/bcache/super.c  | 61 
> ++
>  2 files changed, 36 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/md/bcache/bcache.h b/drivers/md/bcache/bcache.h
> index 6b420a5..3c48927 100644
> --- a/drivers/md/bcache/bcache.h
> +++ b/drivers/md/bcache/bcache.h
> @@ -295,6 +295,7 @@ struct cached_dev {
>   struct cache_sb sb;
>   struct bio  sb_bio;
>   struct bio_vec  sb_bv[1];
> + void*sb_disk_data;
>   struct closure  sb_write;
>   struct semaphoresb_write_mutex;
>  
> @@ -382,6 +383,7 @@ struct cache {
>   struct cache_sb sb;
>   struct bio  sb_bio;
>   struct bio_vec  sb_bv[1];
> + void*sb_disk_data;
>  
>   struct kobject  kobj;
>   struct block_device *bdev;
> diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
> index e169739..f017f69 100644
> --- a/drivers/md/bcache/super.c
> +++ b/drivers/md/bcache/super.c
> @@ -62,7 +62,7 @@ struct workqueue_struct *bcache_wq;
>  /* Superblock */
>  
>  static const char *read_super(struct cache_sb *sb, struct block_device *bdev,
> -   struct page **res)
> +   void *sb_data)
>  {
>   const char *err;
>   struct cache_sb *s;
> @@ -191,8 +191,7 @@ static const char *read_super(struct cache_sb *sb, struct 
> block_device *bdev,
>   sb->last_mount = get_seconds();
>   err = NULL;
>  
> - get_page(bh->b_page);
> - *res = bh->b_page;
> + memcpy(sb_data, bh->b_data, SB_SIZE);
>  err:
>   put_bh(bh);
>   return err;
> @@ -206,15 +205,15 @@ static void write_bdev_super_endio(struct bio *bio)
>   closure_put(>sb_write);
>  }
>  
> -static void __write_super(struct cache_sb *sb, struct bio *bio)
> +static void __write_super(struct cache_sb *sb, struct bio *bio, void 
> *sb_data)
>  {
> - struct cache_sb *out = page_address(bio->bi_io_vec[0].bv_page);
> + struct cache_sb *out = sb_data;
>   unsigned i;
>  
>   bio->bi_iter.bi_sector  = SB_SECTOR;
>   bio->bi_rw  = REQ_SYNC|REQ_META;
>   bio->bi_iter.bi_size= SB_SIZE;
> - bch_bio_map(bio, NULL);
> + bch_bio_map(bio, sb_data);
>  
>   

Re: [PATCH 19/32] sched.h: Add rg_list and rdtgroup in task_struct

[Nilay Vaish]

On 12 July 2016 at 20:02, Fenghua Yu  wrote:
> From: Fenghua Yu 
>
> rg_list is linked list to connect to other tasks in a rdtgroup.
>
> The point of rdtgroup allows the task to access its own rdtgroup directly.
>
> Signed-off-by: Fenghua Yu 
> Reviewed-by: Tony Luck 
> ---
>  include/linux/sched.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 253538f..55adf17 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1761,6 +1761,10 @@ struct task_struct {
> /* cg_list protected by css_set_lock and tsk->alloc_lock */
> struct list_head cg_list;
>  #endif
> +#ifdef CONFIG_INTEL_RDT
> +   struct list_head rg_list;
> +   struct rdtgroup *rdtgroup;
> +#endif
>  #ifdef CONFIG_FUTEX
> struct robust_list_head __user *robust_list;
>  #ifdef CONFIG_COMPAT
> --
> 2.5.0
>

I think this patch should be merged with patch 22/32 since struct
rdtgroup 's definition appears in the patch 22/32.  I do not recall
seeing any forward declaration either.

--
Nilay

Re: [PATCH 19/32] sched.h: Add rg_list and rdtgroup in task_struct

[Nilay Vaish]

On 12 July 2016 at 20:02, Fenghua Yu  wrote:
> From: Fenghua Yu 
>
> rg_list is linked list to connect to other tasks in a rdtgroup.
>
> The point of rdtgroup allows the task to access its own rdtgroup directly.
>
> Signed-off-by: Fenghua Yu 
> Reviewed-by: Tony Luck 
> ---
>  include/linux/sched.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 253538f..55adf17 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1761,6 +1761,10 @@ struct task_struct {
> /* cg_list protected by css_set_lock and tsk->alloc_lock */
> struct list_head cg_list;
>  #endif
> +#ifdef CONFIG_INTEL_RDT
> +   struct list_head rg_list;
> +   struct rdtgroup *rdtgroup;
> +#endif
>  #ifdef CONFIG_FUTEX
> struct robust_list_head __user *robust_list;
>  #ifdef CONFIG_COMPAT
> --
> 2.5.0
>

I think this patch should be merged with patch 22/32 since struct
rdtgroup 's definition appears in the patch 22/32.  I do not recall
seeing any forward declaration either.

--
Nilay

Re: staging: lustre: One function call less in class_register_type() after error detection

[SF Markus Elfring]

> This function is called several times during lustre module insert.
> Namely it's called 5 times for 5 types:
> osc, mdc, lov, lmv, mgc.

Will any extra memory accesses matter for the successful execution
in this use case?


> It's not called any more than that, so it's not exactly a super hot-path 
> function
> to overoptimize it, and the failure is presumed to never happen too
> (or the module would be non-functional).

Did the assignment for the local variable "rc" with a well-known error code
influence the run-time characteristics in unwanted ways?
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/staging/lustre/lustre/obdclass/genops.c?id=6a5b99a46bedc2cfbba96dec6d255c4b90af9ff8#n140

Regards,
Markus

Re: staging: lustre: One function call less in class_register_type() after error detection

[SF Markus Elfring]

> This function is called several times during lustre module insert.
> Namely it's called 5 times for 5 types:
> osc, mdc, lov, lmv, mgc.

Will any extra memory accesses matter for the successful execution
in this use case?


> It's not called any more than that, so it's not exactly a super hot-path 
> function
> to overoptimize it, and the failure is presumed to never happen too
> (or the module would be non-functional).

Did the assignment for the local variable "rc" with a well-known error code
influence the run-time characteristics in unwanted ways?
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/staging/lustre/lustre/obdclass/genops.c?id=6a5b99a46bedc2cfbba96dec6d255c4b90af9ff8#n140

Regards,
Markus

Re: [PATCH 1/3] Add a new field to struct shrinker

[Dave Chinner]

[line wrap text at 72 columns, please] 

On Tue, Jul 26, 2016 at 09:40:57AM -0700, Tony Jones wrote:
> On 07/20/2016 07:54 AM, Michal Hocko wrote:
> >On Wed 20-07-16 20:11:09, Janani Ravichandran wrote:
> >>>On Jul 11, 2016, at 8:03 PM, Michal Hocko  wrote:
> >>>On Mon 11-07-16 10:12:51, Rik van Riel wrote:
> 
> What mechanism do you have in mind for obtaining the name,
> Michal?
> >>>
> >>>Not sure whether tracing infrastructure allows printk like %ps.
> >>>If not then it doesn't sound too hard to add.
> >>
> >>It does allow %ps. Currently what is being printed is the
> >>function symbol of the callback using %pF. I’d like to know
> >>why %pF is used instead of %ps in this case.
> >
> >From a quick look into the code %pF should be doing the same
> >thing as %ps in the end. Some architectures just need some magic
> >to get a proper address of the function.
> >
> >>Michal, just to make sure I understand you correctly, do you
> >>mean that we could infer the names of the shrinkers by looking
> >>at the names of their callbacks?
> >
> >Yes, %ps can then be used for the name of the shrinker structure
> >(assuming it is available).
> 
> The "shrinker structure" (struct shrinker) isn't a good candidate
> (as it's often embedded as thus no symbol name can be resolved)
> but the callback seems to work fine in my testing.
> 
> I made an earlier suggestion to Janani that it was helpful to have
> the superblock shrinker name constructed to include the fstype.
> This level of specificity would be lost if just the callback is
> used.  I talked briefly to Michal and his view is that more
> specific tracepoints can be added for this case.   This is
> certainly an option as the super_cache_scan callback can access
> the superblock and thus the file_system_type via containing
> record.   It's just more work to later reconcile the output of two
> tracepoints.
> 
> I talked briefly to Mel and we both think being able to have this
> level (of fstype) specificity would be useful and it would be lost
> just using the callback.   Another option which would avoid the
> static overhead of the names would be to add a new shrinker_name()
> callback.  If NULL,  the caller can just perform the default, in
> this case lookup the symbol for the callback, if !NULL it would
> provide additional string information which the caller could use.
> The per-sb shrinker could implement it and return the fstype.
> It's obviously still a +1 word growth of the struct shrinker but
> it avoids the text overhead of the constructed names.
> 
> Opinions?

Seems you're all missing the obvious.

Add a tracepoint for a shrinker callback that includes a "name"
field, have the shrinker callback fill it out appropriately. e.g
in the superblock shrinker:


trace_shrinker_callback(shrinker, shrink_control, sb->s_type->name);

And generic code that doesn't want to put a specific context name in
there can simply call:

trace_shrinker_callback(shrinker, shrink_control, __func__);

And now you know exactly what shrinker is being run.

No need to add names to any structures, it's call site defined so is
flexible, and if you're not using tracepoints has no overhead.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH 1/3] Add a new field to struct shrinker

[Dave Chinner]

[line wrap text at 72 columns, please] 

On Tue, Jul 26, 2016 at 09:40:57AM -0700, Tony Jones wrote:
> On 07/20/2016 07:54 AM, Michal Hocko wrote:
> >On Wed 20-07-16 20:11:09, Janani Ravichandran wrote:
> >>>On Jul 11, 2016, at 8:03 PM, Michal Hocko  wrote:
> >>>On Mon 11-07-16 10:12:51, Rik van Riel wrote:
> 
> What mechanism do you have in mind for obtaining the name,
> Michal?
> >>>
> >>>Not sure whether tracing infrastructure allows printk like %ps.
> >>>If not then it doesn't sound too hard to add.
> >>
> >>It does allow %ps. Currently what is being printed is the
> >>function symbol of the callback using %pF. I’d like to know
> >>why %pF is used instead of %ps in this case.
> >
> >From a quick look into the code %pF should be doing the same
> >thing as %ps in the end. Some architectures just need some magic
> >to get a proper address of the function.
> >
> >>Michal, just to make sure I understand you correctly, do you
> >>mean that we could infer the names of the shrinkers by looking
> >>at the names of their callbacks?
> >
> >Yes, %ps can then be used for the name of the shrinker structure
> >(assuming it is available).
> 
> The "shrinker structure" (struct shrinker) isn't a good candidate
> (as it's often embedded as thus no symbol name can be resolved)
> but the callback seems to work fine in my testing.
> 
> I made an earlier suggestion to Janani that it was helpful to have
> the superblock shrinker name constructed to include the fstype.
> This level of specificity would be lost if just the callback is
> used.  I talked briefly to Michal and his view is that more
> specific tracepoints can be added for this case.   This is
> certainly an option as the super_cache_scan callback can access
> the superblock and thus the file_system_type via containing
> record.   It's just more work to later reconcile the output of two
> tracepoints.
> 
> I talked briefly to Mel and we both think being able to have this
> level (of fstype) specificity would be useful and it would be lost
> just using the callback.   Another option which would avoid the
> static overhead of the names would be to add a new shrinker_name()
> callback.  If NULL,  the caller can just perform the default, in
> this case lookup the symbol for the callback, if !NULL it would
> provide additional string information which the caller could use.
> The per-sb shrinker could implement it and return the fstype.
> It's obviously still a +1 word growth of the struct shrinker but
> it avoids the text overhead of the constructed names.
> 
> Opinions?

Seems you're all missing the obvious.

Add a tracepoint for a shrinker callback that includes a "name"
field, have the shrinker callback fill it out appropriately. e.g
in the superblock shrinker:


trace_shrinker_callback(shrinker, shrink_control, sb->s_type->name);

And generic code that doesn't want to put a specific context name in
there can simply call:

trace_shrinker_callback(shrinker, shrink_control, __func__);

And now you know exactly what shrinker is being run.

No need to add names to any structures, it's call site defined so is
flexible, and if you're not using tracepoints has no overhead.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

[Eric Dumazet]

On Wed, 2016-07-27 at 14:38 -0700, Jeff Kirsher wrote:
> On Tue, 2016-07-26 at 11:14 +0200, Eric Dumazet wrote:
> > Could you try this ?
> > 
> > diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
> > b/drivers/net/ethernet/intel/e1000/e1000_main.c
> > index
> > f42129d09e2c23ba9fdb5cde890d50ecb7166a42..a53c41c4c4f7d1fe52f95a2cab8784a
> > 938b3820b 100644
> > --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
> > +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
> > @@ -5257,9 +5257,13 @@ static void e1000_netpoll(struct net_device
> > *netdev)
> >  {
> > struct e1000_adapter *adapter = netdev_priv(netdev);
> >  
> > -   disable_irq(adapter->pdev->irq);
> > -   e1000_intr(adapter->pdev->irq, netdev);
> > -   enable_irq(adapter->pdev->irq);
> > +   if (napi_schedule_prep(>napi)) {
> > +   adapter->total_tx_bytes = 0;
> > +   adapter->total_tx_packets = 0;
> > +   adapter->total_rx_bytes = 0;
> > +   adapter->total_rx_packets = 0;
> > +   __napi_schedule(>napi);
> > +   }
> >  }
> >  #endif
> >  
> 
> Since this fixes the issue Fengguang saw, will you be submitting a formal
> patch Eric? (please) I can get this queued up for Dave's net tree as soon
> as I receive the formal patch.

I would prefer having a definitive advice from Thomas Gleixner and/or
others if disable_irq() is forbidden from IRQ path.

As I said, about all netpoll() methods in net drivers use disable_irq()
so a lot of patches would be needed.

disable_irq() should then test this condition earlier, so that we can
detect potential bug, even if the IRQ is not (yet) threaded.

Thanks.

Re: [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

[Eric Dumazet]

On Wed, 2016-07-27 at 14:38 -0700, Jeff Kirsher wrote:
> On Tue, 2016-07-26 at 11:14 +0200, Eric Dumazet wrote:
> > Could you try this ?
> > 
> > diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
> > b/drivers/net/ethernet/intel/e1000/e1000_main.c
> > index
> > f42129d09e2c23ba9fdb5cde890d50ecb7166a42..a53c41c4c4f7d1fe52f95a2cab8784a
> > 938b3820b 100644
> > --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
> > +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
> > @@ -5257,9 +5257,13 @@ static void e1000_netpoll(struct net_device
> > *netdev)
> >  {
> > struct e1000_adapter *adapter = netdev_priv(netdev);
> >  
> > -   disable_irq(adapter->pdev->irq);
> > -   e1000_intr(adapter->pdev->irq, netdev);
> > -   enable_irq(adapter->pdev->irq);
> > +   if (napi_schedule_prep(>napi)) {
> > +   adapter->total_tx_bytes = 0;
> > +   adapter->total_tx_packets = 0;
> > +   adapter->total_rx_bytes = 0;
> > +   adapter->total_rx_packets = 0;
> > +   __napi_schedule(>napi);
> > +   }
> >  }
> >  #endif
> >  
> 
> Since this fixes the issue Fengguang saw, will you be submitting a formal
> patch Eric? (please) I can get this queued up for Dave's net tree as soon
> as I receive the formal patch.

I would prefer having a definitive advice from Thomas Gleixner and/or
others if disable_irq() is forbidden from IRQ path.

As I said, about all netpoll() methods in net drivers use disable_irq()
so a lot of patches would be needed.

disable_irq() should then test this condition earlier, so that we can
detect potential bug, even if the IRQ is not (yet) threaded.

Thanks.

Re: [PATCH 17/32] x86, intel_cacheinfo: Enable cache id in x86

[Nilay Vaish]

On 12 July 2016 at 20:02, Fenghua Yu  wrote:
> From: Fenghua Yu 
>
> Enable cache id in x86. Cache id comes from APIC ID and CPUID4.
>

I think one of these patches on cache ids should refer to some
documentation from Intel on this subject, either in the commit message
or in the comments in some file.  I found one:
https://software.intel.com/sites/default/files/63/1a/Kuo_CpuTopology_rc1.rh1.final.pdf.
You would know better than me which document we should be looking at.

Thanks
Nilay

Re: [PATCH 17/32] x86, intel_cacheinfo: Enable cache id in x86

[Nilay Vaish]

On 12 July 2016 at 20:02, Fenghua Yu  wrote:
> From: Fenghua Yu 
>
> Enable cache id in x86. Cache id comes from APIC ID and CPUID4.
>

I think one of these patches on cache ids should refer to some
documentation from Intel on this subject, either in the commit message
or in the comments in some file.  I found one:
https://software.intel.com/sites/default/files/63/1a/Kuo_CpuTopology_rc1.rh1.final.pdf.
You would know better than me which document we should be looking at.

Thanks
Nilay

Re: [PATCH 6/7] qemu: Implement virtio-pstore device

[Namhyung Kim]

On Thu, Jul 28, 2016 at 03:02:54AM +0300, Michael S. Tsirkin wrote:
> On Thu, Jul 28, 2016 at 12:08:30AM +0900, Namhyung Kim wrote:
> > Add virtio pstore device to allow kernel log files saved on the host.
> > It will save the log files on the directory given by pstore device
> > option.
> > 
> >   $ qemu-system-x86_64 -device virtio-pstore,directory=dir-xx ...
> > 
> >   (guest) # echo c > /proc/sysrq-trigger
> 
> So if the point is handling system crashes, I suspect
> virtio is the wrong protocol to use. ATM it's rather
> elaborate for performance, it's likely not to work when
> linux is crashing. I think you want something very very
> simple that will still work when you crash. Like maybe
> a serial device?

Well, I dont' know.  As you know, the kernel oops dump is already sent
to serial device but it's rather slow.  As I wrote in the cover
letter, enabling ftrace_dump_on_oops makes it even worse..  Also
pstore saves the (compressed) binary data so I thought it'd be better
to have a dedicated IO channel.

I know that we can't rely on anything in kernel when the kernel is
crashing.  In the virtualization environment, I think it'd be great if
it can dump the crash data in the host directly so I chose the virtio.
I thought the virtio is a relatively thin layer and independent from
other kernel features.  Even if it doesn't guarantee to work 100%,
it's worth trying IMHO.


> 
> >   $ ls dir-xx
> >   dmesg-1.enc.z  dmesg-2.enc.z
> > 
> > The log files are usually compressed using zlib.  Users can see the log
> > messages directly on the host or on the guest (using pstore filesystem).
> 
> So this lacks all management tools that a regular storage device
> has, and these are necessary if people are to use this
> in production.
> 
> For example, some kind of provision for limiting the amount of host disk
> this can consume seems called for. Rate-limiting disk writes
> on host also seems necessary. Handling host disk errors always
> propagates error to guest but an option to e.g. stop vm might
> be useful to avoid corruption.

Yes, it needs that kind of management.  I'd like to look at the
existing implementation.  But basically I thought it as a debugging
feature and it won't produce much data for the default setting.  Maybe
I can limit the file size not to exceed the buffer size and keep up to
pre-configured number of files for each type.  Now host disk error
will be propagated to guest.


> 
> > 
> > The 'directory' property is required for virtio-pstore device to work.
> > It also adds 'bufsize' and 'console' (boolean) properties.
> 
> No idea what these do. Seem to be RW by guest but have no effect
> otherwise.

The 'directory' is a pathname which it saves the data files.  The
'bufsize' sets the size of buffer used by pstore.  The 'console'
enables saving pstore console type data.


> 
> 
> > Cc: Paolo Bonzini 
> > Cc: Radim Krčmář 
> > Cc: "Michael S. Tsirkin" 
> > Cc: Anthony Liguori 
> > Cc: Anton Vorontsov 
> > Cc: Colin Cross 
> > Cc: Kees Cook 
> > Cc: Tony Luck 
> > Cc: Steven Rostedt 
> > Cc: Ingo Molnar 
> > Cc: Minchan Kim 
> > Cc: k...@vger.kernel.org
> > Cc: qemu-de...@nongnu.org
> > Cc: virtualizat...@lists.linux-foundation.org
> > Signed-off-by: Namhyung Kim 
> > ---

[SNIP]
> > diff --git a/hw/virtio/virtio-pstore.c b/hw/virtio/virtio-pstore.c
> > new file mode 100644
> > index 000..2ca7786
> > --- /dev/null
> > +++ b/hw/virtio/virtio-pstore.c
> > @@ -0,0 +1,477 @@
> > +/*
> > + * Virtio Pstore Device
> > + *
> > + * Copyright (C) 2016  LG Electronics
> > + *
> > + * Authors:
> > + *  Namhyung Kim  
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2.
> 
> We generally ask new code to be v2 or later.

Ok, will update.


> 
> >  See
> > + * the COPYING file in the top-level directory.
> > + *
> > + */
> > +
> > +#include 
> > +
> > +#include "qemu/osdep.h"
> > +#include "qemu/iov.h"
> > +#include "qemu-common.h"
> > +#include "qemu/cutils.h"
> > +#include "qemu/error-report.h"
> > +#include "sysemu/kvm.h"
> > +#include "qapi/visitor.h"
> > +#include "qapi-event.h"
> > +#include "trace.h"
> > +
> > +#include "hw/virtio/virtio.h"
> > +#include "hw/virtio/virtio-bus.h"
> > +#include "hw/virtio/virtio-access.h"
> > +#include "hw/virtio/virtio-pstore.h"
> > +
> > +
> > +static void virtio_pstore_to_filename(VirtIOPstore *s, char *buf, size_t 
> > sz,
> > +  struct virtio_pstore_req *req)
> > +{
> > +const char *basename;
> > +unsigned long long id = 0;
> > +unsigned int flags = le32_to_cpu(req->flags);
> > +
> > +switch (le16_to_cpu(req->type)) {
> > +case VIRTIO_PSTORE_TYPE_DMESG:
> > +basename = "dmesg";
> > +id = s->id++;
> > +

Re: [PATCH 6/7] qemu: Implement virtio-pstore device

[Namhyung Kim]

On Thu, Jul 28, 2016 at 03:02:54AM +0300, Michael S. Tsirkin wrote:
> On Thu, Jul 28, 2016 at 12:08:30AM +0900, Namhyung Kim wrote:
> > Add virtio pstore device to allow kernel log files saved on the host.
> > It will save the log files on the directory given by pstore device
> > option.
> > 
> >   $ qemu-system-x86_64 -device virtio-pstore,directory=dir-xx ...
> > 
> >   (guest) # echo c > /proc/sysrq-trigger
> 
> So if the point is handling system crashes, I suspect
> virtio is the wrong protocol to use. ATM it's rather
> elaborate for performance, it's likely not to work when
> linux is crashing. I think you want something very very
> simple that will still work when you crash. Like maybe
> a serial device?

Well, I dont' know.  As you know, the kernel oops dump is already sent
to serial device but it's rather slow.  As I wrote in the cover
letter, enabling ftrace_dump_on_oops makes it even worse..  Also
pstore saves the (compressed) binary data so I thought it'd be better
to have a dedicated IO channel.

I know that we can't rely on anything in kernel when the kernel is
crashing.  In the virtualization environment, I think it'd be great if
it can dump the crash data in the host directly so I chose the virtio.
I thought the virtio is a relatively thin layer and independent from
other kernel features.  Even if it doesn't guarantee to work 100%,
it's worth trying IMHO.


> 
> >   $ ls dir-xx
> >   dmesg-1.enc.z  dmesg-2.enc.z
> > 
> > The log files are usually compressed using zlib.  Users can see the log
> > messages directly on the host or on the guest (using pstore filesystem).
> 
> So this lacks all management tools that a regular storage device
> has, and these are necessary if people are to use this
> in production.
> 
> For example, some kind of provision for limiting the amount of host disk
> this can consume seems called for. Rate-limiting disk writes
> on host also seems necessary. Handling host disk errors always
> propagates error to guest but an option to e.g. stop vm might
> be useful to avoid corruption.

Yes, it needs that kind of management.  I'd like to look at the
existing implementation.  But basically I thought it as a debugging
feature and it won't produce much data for the default setting.  Maybe
I can limit the file size not to exceed the buffer size and keep up to
pre-configured number of files for each type.  Now host disk error
will be propagated to guest.


> 
> > 
> > The 'directory' property is required for virtio-pstore device to work.
> > It also adds 'bufsize' and 'console' (boolean) properties.
> 
> No idea what these do. Seem to be RW by guest but have no effect
> otherwise.

The 'directory' is a pathname which it saves the data files.  The
'bufsize' sets the size of buffer used by pstore.  The 'console'
enables saving pstore console type data.


> 
> 
> > Cc: Paolo Bonzini 
> > Cc: Radim Krčmář 
> > Cc: "Michael S. Tsirkin" 
> > Cc: Anthony Liguori 
> > Cc: Anton Vorontsov 
> > Cc: Colin Cross 
> > Cc: Kees Cook 
> > Cc: Tony Luck 
> > Cc: Steven Rostedt 
> > Cc: Ingo Molnar 
> > Cc: Minchan Kim 
> > Cc: k...@vger.kernel.org
> > Cc: qemu-de...@nongnu.org
> > Cc: virtualizat...@lists.linux-foundation.org
> > Signed-off-by: Namhyung Kim 
> > ---

[SNIP]
> > diff --git a/hw/virtio/virtio-pstore.c b/hw/virtio/virtio-pstore.c
> > new file mode 100644
> > index 000..2ca7786
> > --- /dev/null
> > +++ b/hw/virtio/virtio-pstore.c
> > @@ -0,0 +1,477 @@
> > +/*
> > + * Virtio Pstore Device
> > + *
> > + * Copyright (C) 2016  LG Electronics
> > + *
> > + * Authors:
> > + *  Namhyung Kim  
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2.
> 
> We generally ask new code to be v2 or later.

Ok, will update.


> 
> >  See
> > + * the COPYING file in the top-level directory.
> > + *
> > + */
> > +
> > +#include 
> > +
> > +#include "qemu/osdep.h"
> > +#include "qemu/iov.h"
> > +#include "qemu-common.h"
> > +#include "qemu/cutils.h"
> > +#include "qemu/error-report.h"
> > +#include "sysemu/kvm.h"
> > +#include "qapi/visitor.h"
> > +#include "qapi-event.h"
> > +#include "trace.h"
> > +
> > +#include "hw/virtio/virtio.h"
> > +#include "hw/virtio/virtio-bus.h"
> > +#include "hw/virtio/virtio-access.h"
> > +#include "hw/virtio/virtio-pstore.h"
> > +
> > +
> > +static void virtio_pstore_to_filename(VirtIOPstore *s, char *buf, size_t 
> > sz,
> > +  struct virtio_pstore_req *req)
> > +{
> > +const char *basename;
> > +unsigned long long id = 0;
> > +unsigned int flags = le32_to_cpu(req->flags);
> > +
> > +switch (le16_to_cpu(req->type)) {
> > +case VIRTIO_PSTORE_TYPE_DMESG:
> > +basename = "dmesg";
> > +id = s->id++;
> > +break;
> > +case VIRTIO_PSTORE_TYPE_CONSOLE:
> > +basename = "console";
> > +if (s->console_id) {
> > +id = s->console_id;
> > +} else {
> > +id = s->console_id = s->id++;
> > +}
> > +break;
> > 

[GIT PULL] libnvdimm for 4.8

[Williams, Dan J]

Hi Linus, please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm 
tags/libnvdimm-for-4.8

...to receive the libnvdimm update for 4.8.

This has been in -next with the following reported conflicts:

1/ The __pmem address space has been removed.  New usages of __pmem
came in through the DM tree this cycle.

2/ A minor conflict in the pmem driver with the device_add_disk()
changes that came in through the block layer.

3/ The removal of pcommit collided with new enabling in KVM.  At the
time of writing you have not yet merged the KVM tree.

A test resolution for 1 and 2 is available here:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm 
libnvdimm-for-4.8-merge

Stephen's resolution of the KVM conflict is available here:

  https://lkml.org/lkml/2016/7/25/11

The pcommit removal in arch/x86/ has an ack from Ingo.

---

The following changes since commit a72255983f12f31f0c8d8275fb1a781546cfacb7:

  nfit: make DIMM DSMs optional (2016-07-19 12:32:39 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm 
tags/libnvdimm-for-4.8

for you to fetch changes up to 0606263f24f3d64960de742c55894190b5df903b:

  Merge branch 'for-4.8/libnvdimm' into libnvdimm-for-next (2016-07-24 08:05:44 
-0700)


libnvdimm for 4.8

1/ Replace pcommit with ADR / directed-flushing:
   The pcommit instruction, which has not shipped on any product, is
   deprecated. Instead, the requirement is that platforms implement either
   ADR, or provide one or more flush addresses per nvdimm. ADR
   (Asynchronous DRAM Refresh) flushes data in posted write buffers to the
   memory controller on a power-fail event. Flush addresses are defined in
   ACPI 6.x as an NVDIMM Firmware Interface Table (NFIT) sub-structure:
   "Flush Hint Address Structure". A flush hint is an mmio address that
   when written and fenced assures that all previous posted writes
   targeting a given dimm have been flushed to media.

2/ On-demand ARS (address range scrub):
   Linux uses the results of the ACPI ARS commands to track bad blocks
   in pmem devices.  When latent errors are detected we re-scrub the media
   to refresh the bad block list, userspace can also request a re-scrub at
   any time.

3/ Support for the Microsoft DSM (device specific method) command format.

4/ Support for EDK2/OVMF virtual disk device memory ranges.

5/ Various fixes and cleanups across the subsystem.


Dan Williams (32):
  libnvdimm: use devm_add_action_or_reset()
  libnvdimm: IS_ERR() usage cleanup
  tools/testing/nvdimm: add pfn device dependency
  libnvdimm, pmem: allow nfit_test to override pmem_direct_access()
  tools/testing/nvdimm: replace CONFIG_DMA_CMA dependency with vmalloc()
  tools/testing/nvdimm: remove __wrap_devm_memremap_pages placeholder
  nfit: always associate flush hints
  nfit: don't override return value of nfit_mem_init
  libnvdimm: introduce devm_nvdimm_memremap(), convert nfit_spa_map() users
  libnvdimm, nfit: remove nfit_spa_map() infrastructure
  libnvdimm, nfit: move flush hint mapping to region-device driver-data
  tools/testing/nvdimm: simulate multiple flush hints per-dimm
  libnvdimm: keep region data alive over namespace removal
  libnvdimm: introduce nvdimm_flush() and nvdimm_has_flush()
  libnvdimm: cycle flush hints
  libnvdimm, pmem: use REQ_FUA, REQ_FLUSH for nvdimm_flush()
  libnvdimm, pmem: flush posted-write queues on shutdown
  fs/dax: remove wmb_pmem()
  libnvdimm, pmem: use nvdimm_flush() for namespace I/O writes
  pmem: kill wmb_pmem()
  pmem: kill __pmem address space
  tools/testing/nvdimm: add virtual ramdisk range
  tools/testing/nvdimm: add manufacturing_{date|location} dimm properties
  nfit: fix _FIT evaluation memory leak + use after free
  nfit: cleanup acpi_nfit_init calling convention
  libnvdimm: move ->module to struct nvdimm_bus_descriptor
  nfit, tools/testing/nvdimm/: unify shutdown paths
  Revert "KVM: x86: add pcommit support"
  x86/insn: remove pcommit
  libnvdimm: register nvdimm_bus devices with an nd_bus driver
  nfit: move to nfit/ sub-directory
  Merge branch 'for-4.8/libnvdimm' into libnvdimm-for-next

Johannes Thumshirn (1):
  libnvdimm: initialize struct blk_integrity with 0

Lee, Chun-Yi (1):
  acpi, nfit: treat virtual ramdisk SPA as pmem region

Markus Elfring (1):
  libnvdimm-btt: Delete an unnecessary check before the function call 
"__nd_device_register"

Sajjan, Vikas C (2):
  nfit: use devm_add_action_or_reset()
  dax: use devm_add_action_or_reset()

Vishal Verma (4):
  libnvdimm, btt: update the usage section in Documentation
  pmem: clarify a debug print in pmem_clear_poison
  nfit, libnvdimm: allow an ARS scrub to be triggered on 

[GIT PULL] libnvdimm for 4.8

[Williams, Dan J]

Hi Linus, please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm 
tags/libnvdimm-for-4.8

...to receive the libnvdimm update for 4.8.

This has been in -next with the following reported conflicts:

1/ The __pmem address space has been removed.  New usages of __pmem
came in through the DM tree this cycle.

2/ A minor conflict in the pmem driver with the device_add_disk()
changes that came in through the block layer.

3/ The removal of pcommit collided with new enabling in KVM.  At the
time of writing you have not yet merged the KVM tree.

A test resolution for 1 and 2 is available here:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm 
libnvdimm-for-4.8-merge

Stephen's resolution of the KVM conflict is available here:

  https://lkml.org/lkml/2016/7/25/11

The pcommit removal in arch/x86/ has an ack from Ingo.

---

The following changes since commit a72255983f12f31f0c8d8275fb1a781546cfacb7:

  nfit: make DIMM DSMs optional (2016-07-19 12:32:39 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm 
tags/libnvdimm-for-4.8

for you to fetch changes up to 0606263f24f3d64960de742c55894190b5df903b:

  Merge branch 'for-4.8/libnvdimm' into libnvdimm-for-next (2016-07-24 08:05:44 
-0700)


libnvdimm for 4.8

1/ Replace pcommit with ADR / directed-flushing:
   The pcommit instruction, which has not shipped on any product, is
   deprecated. Instead, the requirement is that platforms implement either
   ADR, or provide one or more flush addresses per nvdimm. ADR
   (Asynchronous DRAM Refresh) flushes data in posted write buffers to the
   memory controller on a power-fail event. Flush addresses are defined in
   ACPI 6.x as an NVDIMM Firmware Interface Table (NFIT) sub-structure:
   "Flush Hint Address Structure". A flush hint is an mmio address that
   when written and fenced assures that all previous posted writes
   targeting a given dimm have been flushed to media.

2/ On-demand ARS (address range scrub):
   Linux uses the results of the ACPI ARS commands to track bad blocks
   in pmem devices.  When latent errors are detected we re-scrub the media
   to refresh the bad block list, userspace can also request a re-scrub at
   any time.

3/ Support for the Microsoft DSM (device specific method) command format.

4/ Support for EDK2/OVMF virtual disk device memory ranges.

5/ Various fixes and cleanups across the subsystem.


Dan Williams (32):
  libnvdimm: use devm_add_action_or_reset()
  libnvdimm: IS_ERR() usage cleanup
  tools/testing/nvdimm: add pfn device dependency
  libnvdimm, pmem: allow nfit_test to override pmem_direct_access()
  tools/testing/nvdimm: replace CONFIG_DMA_CMA dependency with vmalloc()
  tools/testing/nvdimm: remove __wrap_devm_memremap_pages placeholder
  nfit: always associate flush hints
  nfit: don't override return value of nfit_mem_init
  libnvdimm: introduce devm_nvdimm_memremap(), convert nfit_spa_map() users
  libnvdimm, nfit: remove nfit_spa_map() infrastructure
  libnvdimm, nfit: move flush hint mapping to region-device driver-data
  tools/testing/nvdimm: simulate multiple flush hints per-dimm
  libnvdimm: keep region data alive over namespace removal
  libnvdimm: introduce nvdimm_flush() and nvdimm_has_flush()
  libnvdimm: cycle flush hints
  libnvdimm, pmem: use REQ_FUA, REQ_FLUSH for nvdimm_flush()
  libnvdimm, pmem: flush posted-write queues on shutdown
  fs/dax: remove wmb_pmem()
  libnvdimm, pmem: use nvdimm_flush() for namespace I/O writes
  pmem: kill wmb_pmem()
  pmem: kill __pmem address space
  tools/testing/nvdimm: add virtual ramdisk range
  tools/testing/nvdimm: add manufacturing_{date|location} dimm properties
  nfit: fix _FIT evaluation memory leak + use after free
  nfit: cleanup acpi_nfit_init calling convention
  libnvdimm: move ->module to struct nvdimm_bus_descriptor
  nfit, tools/testing/nvdimm/: unify shutdown paths
  Revert "KVM: x86: add pcommit support"
  x86/insn: remove pcommit
  libnvdimm: register nvdimm_bus devices with an nd_bus driver
  nfit: move to nfit/ sub-directory
  Merge branch 'for-4.8/libnvdimm' into libnvdimm-for-next

Johannes Thumshirn (1):
  libnvdimm: initialize struct blk_integrity with 0

Lee, Chun-Yi (1):
  acpi, nfit: treat virtual ramdisk SPA as pmem region

Markus Elfring (1):
  libnvdimm-btt: Delete an unnecessary check before the function call 
"__nd_device_register"

Sajjan, Vikas C (2):
  nfit: use devm_add_action_or_reset()
  dax: use devm_add_action_or_reset()

Vishal Verma (4):
  libnvdimm, btt: update the usage section in Documentation
  pmem: clarify a debug print in pmem_clear_poison
  nfit, libnvdimm: allow an ARS scrub to be triggered on 

RE: [virtio-dev] Re: [PATCH v2 repost 6/7] mm: add the related functions to get free page info

[Li, Liang Z]

> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 7da61ad..3ad8b10
> > 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -4523,6 +4523,52 @@ unsigned long get_max_pfn(void)  }
> > EXPORT_SYMBOL(get_max_pfn);
> >
> > +static void mark_free_pages_bitmap(struct zone *zone, unsigned long
> start_pfn,
> > +   unsigned long end_pfn, unsigned long *bitmap, unsigned long len) {
> > +   unsigned long pfn, flags, page_num;
> > +   unsigned int order, t;
> > +   struct list_head *curr;
> > +
> > +   if (zone_is_empty(zone))
> > +   return;
> > +   end_pfn = min(start_pfn + len, end_pfn);
> > +   spin_lock_irqsave(>lock, flags);
> > +
> > +   for_each_migratetype_order(order, t) {
> 
> Why not do each order separately? This way you can use a single bit to pass a
> huge page to host.
> 

I thought about that before, and did not that because of complexity and small 
benefits.
Use separated page bitmaps for each order won't help to reduce the data 
traffic, except
ignoring the pages with small order. 

> Not a requirement but hey.
> 
> Alternatively (and maybe that is a better idea0 if you wanted to, you could
> just skip lone 4K pages.
> It's not clear that they are worth bothering with.
> Add a flag to start with some reasonably large order and go from there.
> 
One of the main reason of this patch is to reduce the network traffic as much 
as possible,
it looks strange to skip the lone 4K pages. Skipping these pages can made live 
migration
faster? I think it depends on the amount of lone 4K pages.

In the other hand, it's faster to send one bit through virtio than that send 4K 
bytes 
through even 10Gps network, is that true?

Liang

RE: [virtio-dev] Re: [PATCH v2 repost 6/7] mm: add the related functions to get free page info

[Li, Liang Z]

> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 7da61ad..3ad8b10
> > 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -4523,6 +4523,52 @@ unsigned long get_max_pfn(void)  }
> > EXPORT_SYMBOL(get_max_pfn);
> >
> > +static void mark_free_pages_bitmap(struct zone *zone, unsigned long
> start_pfn,
> > +   unsigned long end_pfn, unsigned long *bitmap, unsigned long len) {
> > +   unsigned long pfn, flags, page_num;
> > +   unsigned int order, t;
> > +   struct list_head *curr;
> > +
> > +   if (zone_is_empty(zone))
> > +   return;
> > +   end_pfn = min(start_pfn + len, end_pfn);
> > +   spin_lock_irqsave(>lock, flags);
> > +
> > +   for_each_migratetype_order(order, t) {
> 
> Why not do each order separately? This way you can use a single bit to pass a
> huge page to host.
> 

I thought about that before, and did not that because of complexity and small 
benefits.
Use separated page bitmaps for each order won't help to reduce the data 
traffic, except
ignoring the pages with small order. 

> Not a requirement but hey.
> 
> Alternatively (and maybe that is a better idea0 if you wanted to, you could
> just skip lone 4K pages.
> It's not clear that they are worth bothering with.
> Add a flag to start with some reasonably large order and go from there.
> 
One of the main reason of this patch is to reduce the network traffic as much 
as possible,
it looks strange to skip the lone 4K pages. Skipping these pages can made live 
migration
faster? I think it depends on the amount of lone 4K pages.

In the other hand, it's faster to send one bit through virtio than that send 4K 
bytes 
through even 10Gps network, is that true?

Liang

[GIT PULL]: dmaengine update for 4.8-rc1

[Vinod Koul]

Hello Linus,

Here is the PULL request for 4.8-rc1. Two new drivers, bunch of updates and
cleanups to existing set. Nothing super exciting though.

The following changes since commit 1a695a905c18548062509178b98bc91e67510864:

  Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)

are available in the git repository at:

  git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-4.8-rc1

for you to fetch changes up to 4bb0439626983fdde5af3ce970bd0ba2070f5378:

  Merge branch 'topic/dmaengine_cleanups' into for-linus (2016-07-28 10:10:37 
+0530)



dmaengine updates for 4.8-rc1

This time we have bit of largish changes:

New drivers:
 - Xilinx zynqmp dma engine driver.
 - Marvell xor2 driver.

Updates:
 - dmatest sg support.
 - updates and enhancements to Xilinx drivers, adding of cyclic mode.
 - clock handling fixes across drivers.
 - removal of OOM messages on kzalloc across subsystem.
 - interleaved transfers support in omap driver.
 - runtime pm support in qcom bam dma.
 - tasklet kill freeup across drivers.
 - irq cleanup on remove across drivers.


Alexandre Belloni (1):
  dmaengine: at_xdmac: fix debug string

Arnd Bergmann (6):
  dmaengine: xilinx-vdma: add some sanity checks
  dmaengine: bcm2835: fix 64-bit warning
  dmaengine: bcm2835: fix 64-bit warning
  dmaengine: qcom-bam-dma: add __maybe_unused annotations for PM
  dmaengine: zynqmp: avoid cast warning
  dmaengine: zynqmp_dma: add missing MODULE_LICENSE

Ben Dooks (5):
  dmaengine: ste_dma40_ll: make d40_width_to_bits static
  dmaengine: sirf: fix un-exported struct warnings
  dmaengine: at_xdmac: fix un-exported functions
  dmaengine: bcm2835: fix unexported function
  dmaengine: ti-dma-crossbar: make omap_dmaxbar_init static

Jon Hunter (3):
  dmaengine: tegra-apb: Correct grammar in TX status debug message
  dmaengine: tegra-apb: Remove duplicated residue calculation
  dmaengine: tegra-apb: Return the actual descriptor status

Kedareswara rao Appana (15):
  dmaengine: vdma: Add support for cyclic dma mode
  dmaengine: vdma: Use dma_pool_zalloc
  dmaengine: vdma: Fix compilation warning in cyclic dma mode
  dmaengine: vdma: Add 64 bit addressing support for the axi dma
  dmaengine: vdma: Add 64 bit addressing support for the axi cdma
  Documentation: DT: vdma: Update binding doc for multi-channel dma mode
  dmaengine: vdma: Add support for mulit-channel dma mode
  Documentation: DT: dma: Delete binding doc for AXI DMA
  dmaengine: xilinx: Rename driver and config
  dmaengine: xilinx: Use different channel names for each dma
  Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding 
documentation
  dmaengine: Add Xilinx zynqmp dma engine driver support
  dmaengine: xilinx: Fix race condition in axi dma cyclic dma mode
  dmaengine: dmatest: Add support for scatter-gather DMA mode
  dmaengine: zynqmp_dma: Fix static checker warning

Kuninori Morimoto (1):
  dmaengine: rcar-dmac: use list_add() on rcar_dmac_desc_put()

Lars-Peter Clausen (3):
  dmaengine: axi-dmac: Add MODULE_DEVICE_TABLE()
  dmaengine: axi-dmac: Propagate errors from platform_get_irq()
  dmaengine: axi-dmac: Return IRQ_NONE if no IRQs are pending

Laurent Pinchart (1):
  dmaengine: rcar-dmac: Fix residue reporting for pending descriptors

Michael Olbrich (1):
  dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt handler

Muhammad Hamza Farooq (2):
  dmaengine: rcar-dmac: use result of updated get_residue in tx_status
  dmaengine: rcar-dmac: Fixed active descriptor initializing

Niklas Söderlund (1):
  dmaengine: rcar-dmac: warn if transfer cannot start as TE = 1

Peter Griffin (8):
  dmaengine: fsl-edma: Fix clock handling error paths
  dmaengine: fsl-edma: print error code in error messages.
  dmaengine: coh901318: Only calculate residue if txstate exists.
  dmaengine: s3c24xx: Simplify code in s3c24xx_dma_tx_status()
  dmaengine: ste_dma40: Only calculate residue if txstate exists.
  dmaengine: sun6i-dma: Only calculate residue if state exists.
  dmaengine: tegra20-apb-dma: Only calculate residue if txstate exists.
  dmaengine: Remove site specific OOM error messages on kzalloc

Peter Ujfalusi (2):
  dmaengine: edma: Use early completion for intermediate paRAM set in 
slave_sg
  dmaengine: omap-dma: Support for interleaved transfer

Pramod Gurav (1):
  dmaengine: qcom-bam-dma: Add pm_runtime support

Robert Jarzmik (1):
  dmaengine: pxa_dma: implement device_synchronize

Stefan Roese (1):
  dmaengine: mv_xor: Minor coding style fix

Thierry Reding (1):
  dmaengine: tegra: Remove some whitespace funkiness

Thomas Petazzoni (2):
  dt-bindings: dma: add binding for the Marvell XOR v2 engine
  dmaengine: mv_xor_v2: new driver

[GIT PULL]: dmaengine update for 4.8-rc1

[Vinod Koul]

Hello Linus,

Here is the PULL request for 4.8-rc1. Two new drivers, bunch of updates and
cleanups to existing set. Nothing super exciting though.

The following changes since commit 1a695a905c18548062509178b98bc91e67510864:

  Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)

are available in the git repository at:

  git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-4.8-rc1

for you to fetch changes up to 4bb0439626983fdde5af3ce970bd0ba2070f5378:

  Merge branch 'topic/dmaengine_cleanups' into for-linus (2016-07-28 10:10:37 
+0530)



dmaengine updates for 4.8-rc1

This time we have bit of largish changes:

New drivers:
 - Xilinx zynqmp dma engine driver.
 - Marvell xor2 driver.

Updates:
 - dmatest sg support.
 - updates and enhancements to Xilinx drivers, adding of cyclic mode.
 - clock handling fixes across drivers.
 - removal of OOM messages on kzalloc across subsystem.
 - interleaved transfers support in omap driver.
 - runtime pm support in qcom bam dma.
 - tasklet kill freeup across drivers.
 - irq cleanup on remove across drivers.


Alexandre Belloni (1):
  dmaengine: at_xdmac: fix debug string

Arnd Bergmann (6):
  dmaengine: xilinx-vdma: add some sanity checks
  dmaengine: bcm2835: fix 64-bit warning
  dmaengine: bcm2835: fix 64-bit warning
  dmaengine: qcom-bam-dma: add __maybe_unused annotations for PM
  dmaengine: zynqmp: avoid cast warning
  dmaengine: zynqmp_dma: add missing MODULE_LICENSE

Ben Dooks (5):
  dmaengine: ste_dma40_ll: make d40_width_to_bits static
  dmaengine: sirf: fix un-exported struct warnings
  dmaengine: at_xdmac: fix un-exported functions
  dmaengine: bcm2835: fix unexported function
  dmaengine: ti-dma-crossbar: make omap_dmaxbar_init static

Jon Hunter (3):
  dmaengine: tegra-apb: Correct grammar in TX status debug message
  dmaengine: tegra-apb: Remove duplicated residue calculation
  dmaengine: tegra-apb: Return the actual descriptor status

Kedareswara rao Appana (15):
  dmaengine: vdma: Add support for cyclic dma mode
  dmaengine: vdma: Use dma_pool_zalloc
  dmaengine: vdma: Fix compilation warning in cyclic dma mode
  dmaengine: vdma: Add 64 bit addressing support for the axi dma
  dmaengine: vdma: Add 64 bit addressing support for the axi cdma
  Documentation: DT: vdma: Update binding doc for multi-channel dma mode
  dmaengine: vdma: Add support for mulit-channel dma mode
  Documentation: DT: dma: Delete binding doc for AXI DMA
  dmaengine: xilinx: Rename driver and config
  dmaengine: xilinx: Use different channel names for each dma
  Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding 
documentation
  dmaengine: Add Xilinx zynqmp dma engine driver support
  dmaengine: xilinx: Fix race condition in axi dma cyclic dma mode
  dmaengine: dmatest: Add support for scatter-gather DMA mode
  dmaengine: zynqmp_dma: Fix static checker warning

Kuninori Morimoto (1):
  dmaengine: rcar-dmac: use list_add() on rcar_dmac_desc_put()

Lars-Peter Clausen (3):
  dmaengine: axi-dmac: Add MODULE_DEVICE_TABLE()
  dmaengine: axi-dmac: Propagate errors from platform_get_irq()
  dmaengine: axi-dmac: Return IRQ_NONE if no IRQs are pending

Laurent Pinchart (1):
  dmaengine: rcar-dmac: Fix residue reporting for pending descriptors

Michael Olbrich (1):
  dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt handler

Muhammad Hamza Farooq (2):
  dmaengine: rcar-dmac: use result of updated get_residue in tx_status
  dmaengine: rcar-dmac: Fixed active descriptor initializing

Niklas Söderlund (1):
  dmaengine: rcar-dmac: warn if transfer cannot start as TE = 1

Peter Griffin (8):
  dmaengine: fsl-edma: Fix clock handling error paths
  dmaengine: fsl-edma: print error code in error messages.
  dmaengine: coh901318: Only calculate residue if txstate exists.
  dmaengine: s3c24xx: Simplify code in s3c24xx_dma_tx_status()
  dmaengine: ste_dma40: Only calculate residue if txstate exists.
  dmaengine: sun6i-dma: Only calculate residue if state exists.
  dmaengine: tegra20-apb-dma: Only calculate residue if txstate exists.
  dmaengine: Remove site specific OOM error messages on kzalloc

Peter Ujfalusi (2):
  dmaengine: edma: Use early completion for intermediate paRAM set in 
slave_sg
  dmaengine: omap-dma: Support for interleaved transfer

Pramod Gurav (1):
  dmaengine: qcom-bam-dma: Add pm_runtime support

Robert Jarzmik (1):
  dmaengine: pxa_dma: implement device_synchronize

Stefan Roese (1):
  dmaengine: mv_xor: Minor coding style fix

Thierry Reding (1):
  dmaengine: tegra: Remove some whitespace funkiness

Thomas Petazzoni (2):
  dt-bindings: dma: add binding for the Marvell XOR v2 engine
  dmaengine: mv_xor_v2: new driver

Re: lib/mpi: BUG: sleeping function called from invalid context on next-20160726

[Herbert Xu]

On Wed, Jul 27, 2016 at 11:05:05PM +0200, Nicolai Stange wrote:
> 
> with linux-next-20160726, I get this:
> 
>  BUG: sleeping function called from invalid context at 
> /mnt/scratch/nic/linux-next/mm/slab.h:388

Does this patch help?
 
> I would have sent a patch, but there is another point which puzzles me
> in mpi_read_raw_from_sgl():
> 
>   [...]
>   const u8 *buff;
>   [...]
>   sg_miter_start(, sgl, ents, SG_MITER_ATOMIC | SG_MITER_FROM_SG);
> 
>   lzeros = 0;
>   len = 0;
>   while (nbytes > 0) {
>   while (len && !*buff) {
>   lzeros++;
>   len--;
>   buff++;
>   }
> 
> 
> Thus, buff isn't initialized before its first use? Or am I misreading
> something here?

On the first entry len is zero therefore we will go to the end of the
loop and initialise buff.  Anyway, it will no longer be as confusing
with this patch applied.

Thanks,

---8<---
Subject: lib/mpi: Fix SG miter leak

In mpi_read_raw_from_sgl we may leak the SG miter resouces after
reading the leading zeroes.  This patch fixes this by stopping the
iteration once the leading zeroes have been read.

Fixes: 127827b9c295 ("lib/mpi: Do not do sg_virt")
Reported-by: Nicolai Stange 
Signed-off-by: Herbert Xu 

diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index c6272ae..5a0f75a 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -363,6 +363,9 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, unsigned 
int nbytes)
lzeros = 0;
}
 
+   miter.consumed = lzeros;
+   sg_miter_stop();
+
nbytes -= lzeros;
nbits = nbytes * 8;
if (nbits > MAX_EXTERN_MPI_BITS) {
@@ -390,7 +393,10 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, 
unsigned int nbytes)
z = BYTES_PER_MPI_LIMB - nbytes % BYTES_PER_MPI_LIMB;
z %= BYTES_PER_MPI_LIMB;
 
-   for (;;) {
+   while (sg_miter_next()) {
+   buff = miter.addr;
+   len = miter.length;
+
for (x = 0; x < len; x++) {
a <<= 8;
a |= *buff++;
@@ -400,12 +406,6 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, 
unsigned int nbytes)
}
}
z += x;
-
-   if (!sg_miter_next())
-   break;
-
-   buff = miter.addr;
-   len = miter.length;
}
 
return val;
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: lib/mpi: BUG: sleeping function called from invalid context on next-20160726

[Herbert Xu]

On Wed, Jul 27, 2016 at 11:05:05PM +0200, Nicolai Stange wrote:
> 
> with linux-next-20160726, I get this:
> 
>  BUG: sleeping function called from invalid context at 
> /mnt/scratch/nic/linux-next/mm/slab.h:388

Does this patch help?
 
> I would have sent a patch, but there is another point which puzzles me
> in mpi_read_raw_from_sgl():
> 
>   [...]
>   const u8 *buff;
>   [...]
>   sg_miter_start(, sgl, ents, SG_MITER_ATOMIC | SG_MITER_FROM_SG);
> 
>   lzeros = 0;
>   len = 0;
>   while (nbytes > 0) {
>   while (len && !*buff) {
>   lzeros++;
>   len--;
>   buff++;
>   }
> 
> 
> Thus, buff isn't initialized before its first use? Or am I misreading
> something here?

On the first entry len is zero therefore we will go to the end of the
loop and initialise buff.  Anyway, it will no longer be as confusing
with this patch applied.

Thanks,

---8<---
Subject: lib/mpi: Fix SG miter leak

In mpi_read_raw_from_sgl we may leak the SG miter resouces after
reading the leading zeroes.  This patch fixes this by stopping the
iteration once the leading zeroes have been read.

Fixes: 127827b9c295 ("lib/mpi: Do not do sg_virt")
Reported-by: Nicolai Stange 
Signed-off-by: Herbert Xu 

diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index c6272ae..5a0f75a 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -363,6 +363,9 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, unsigned 
int nbytes)
lzeros = 0;
}
 
+   miter.consumed = lzeros;
+   sg_miter_stop();
+
nbytes -= lzeros;
nbits = nbytes * 8;
if (nbits > MAX_EXTERN_MPI_BITS) {
@@ -390,7 +393,10 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, 
unsigned int nbytes)
z = BYTES_PER_MPI_LIMB - nbytes % BYTES_PER_MPI_LIMB;
z %= BYTES_PER_MPI_LIMB;
 
-   for (;;) {
+   while (sg_miter_next()) {
+   buff = miter.addr;
+   len = miter.length;
+
for (x = 0; x < len; x++) {
a <<= 8;
a |= *buff++;
@@ -400,12 +406,6 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, 
unsigned int nbytes)
}
}
z += x;
-
-   if (!sg_miter_next())
-   break;
-
-   buff = miter.addr;
-   len = miter.length;
}
 
return val;
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: RFC: using worker threadpool to speed up clear_huge_page() by up to 5x

[David Miller]

From: kpusukur 
Date: Sun, 17 Jul 2016 12:35:20 -0700

> We would welcome feedback and discussion of potential problems.
> 
> We would also like to hear ideas for other areas in the kernel where a
> similar technique could be employed. For example, we've also applied
> this idea to copy on write operations for huge pages and it achieves
> around 20x speedup.

I don't know about this.

You can only profitably do this when you have enough physical cpu
resources schedulable, and on the same NUMA node.

By the time you compute the complete answer to that entire condition
you could have completed the hugepage clear.

Also, you should experiment with simply using a dedicated hugepage
clear assembler loop for these chips.  It's really stupid to pay the
transaction cost of going in and out of the clear_user_highpage()
function N times per huge page.

Re: RFC: using worker threadpool to speed up clear_huge_page() by up to 5x

[David Miller]

From: kpusukur 
Date: Sun, 17 Jul 2016 12:35:20 -0700

> We would welcome feedback and discussion of potential problems.
> 
> We would also like to hear ideas for other areas in the kernel where a
> similar technique could be employed. For example, we've also applied
> this idea to copy on write operations for huge pages and it achieves
> around 20x speedup.

I don't know about this.

You can only profitably do this when you have enough physical cpu
resources schedulable, and on the same NUMA node.

By the time you compute the complete answer to that entire condition
you could have completed the hugepage clear.

Also, you should experiment with simply using a dedicated hugepage
clear assembler loop for these chips.  It's really stupid to pay the
transaction cost of going in and out of the clear_user_highpage()
function N times per huge page.

linux-next: Tree for Jul 28

[Stephen Rothwell]

Hi all,

Please do not add material destined for v4.9 to your linux-next included
branches until after v4.8-rc1 has been released.

Changes since 20160727:

The powerpc tree lost its build failure.

The kbuild tree gained a conflict against Linus' tree and a build failure
due to an interaction with the powerpc tree for which I applied a merge
fix patch.

Non-merge commits (relative to Linus' tree): 5790
 5136 files changed, 220734 insertions(+), 89901 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 240 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (8448cefe499a Merge tag 'hsi-for-4.8' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi)
Merging fixes/master (3fc9d690936f Merge branch 'for-4.8/drivers' of 
git://git.kernel.dk/linux-block)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (9bd54517ee86 arc: unwind: warn only once if 
DW2_UNWIND is disabled)
Merging arm-current/fixes (f6492164ecb1 ARM: 8577/1: Fix Cortex-A15 798181 
errata initialization)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (bfa37087aa04 powerpc: Initialise pci_io_base as 
early as possible)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (6b15d6650c53 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (6a492b0f23d2 Merge tag 'scsi-misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging ipsec/master (1ba5bf993c6a xfrm: fix crash in XFRM_MSG_GETSA netlink 
handler)
Merging netfilter/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git)
Merging mac80211/master (16a910a6722b cfg80211: handle failed skb allocation)
Merging sound-current/for-linus (0984d159c8ad sound: oss: Use 
kernel_read_file_from_path() for mod_firmware_load())
Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC 
code)
Merging driver-core.current/driver-core-linus (523d939ef98f Linux 4.7)
Merging tty.current/tty-linus (0e06f5c0deee Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (e65805251f2d Merge branch 'irq-core-for-linus' 
of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (4c2e07c6a29e Linux 4.7-rc5)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (0e06f5c0deee Merge branch 'akpm' 
(patches from Andrew))
Merging char-misc.current/char-misc-linus (0e06f5c0deee Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (080888286377 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (0f95e2ffc58f Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging ide/master (d4f8c2e0f827 ide: missing break statement in 
set_timings_mdma())
Merging rr-fixes/fixes (8244062ef1e5 modules: fi

linux-next: Tree for Jul 28

[Stephen Rothwell]

Hi all,

Please do not add material destined for v4.9 to your linux-next included
branches until after v4.8-rc1 has been released.

Changes since 20160727:

The powerpc tree lost its build failure.

The kbuild tree gained a conflict against Linus' tree and a build failure
due to an interaction with the powerpc tree for which I applied a merge
fix patch.

Non-merge commits (relative to Linus' tree): 5790
 5136 files changed, 220734 insertions(+), 89901 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 240 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (8448cefe499a Merge tag 'hsi-for-4.8' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi)
Merging fixes/master (3fc9d690936f Merge branch 'for-4.8/drivers' of 
git://git.kernel.dk/linux-block)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (9bd54517ee86 arc: unwind: warn only once if 
DW2_UNWIND is disabled)
Merging arm-current/fixes (f6492164ecb1 ARM: 8577/1: Fix Cortex-A15 798181 
errata initialization)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (bfa37087aa04 powerpc: Initialise pci_io_base as 
early as possible)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (6b15d6650c53 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (6a492b0f23d2 Merge tag 'scsi-misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging ipsec/master (1ba5bf993c6a xfrm: fix crash in XFRM_MSG_GETSA netlink 
handler)
Merging netfilter/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git)
Merging mac80211/master (16a910a6722b cfg80211: handle failed skb allocation)
Merging sound-current/for-linus (0984d159c8ad sound: oss: Use 
kernel_read_file_from_path() for mod_firmware_load())
Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC 
code)
Merging driver-core.current/driver-core-linus (523d939ef98f Linux 4.7)
Merging tty.current/tty-linus (0e06f5c0deee Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (e65805251f2d Merge branch 'irq-core-for-linus' 
of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (4c2e07c6a29e Linux 4.7-rc5)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (0e06f5c0deee Merge branch 'akpm' 
(patches from Andrew))
Merging char-misc.current/char-misc-linus (0e06f5c0deee Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (080888286377 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (0f95e2ffc58f Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging ide/master (d4f8c2e0f827 ide: missing break statement in 
set_timings_mdma())
Merging rr-fixes/fixes (8244062ef1e5 modules: fi

[PATCH 1/2] tracing: Add latency histograms

[Binoy Jayan]

From: Carsten Emde 

This patch provides a recording mechanism to store data of potential
sources of system latencies. The recordings separately determine the
latency caused by a delayed timer expiration, by a delayed wakeup of the
related user space program and by the sum of both. The histograms can be
enabled and reset individually. The data are accessible via the debug
filesystem. The patch is adapted from the rt kernel and restructured to
avoid unwanted macros from source files. For details please consult
Documentation/trace/histograms.txt.

Signed-off-by: Carsten Emde 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Binoy Jayan 
---
 Documentation/trace/histograms.txt  |  186 ++
 include/linux/hrtimer.h |3 +
 include/linux/sched.h   |6 +
 include/trace/events/hist.h |   72 +++
 include/trace/events/latency_hist.h |  136 +
 kernel/time/hrtimer.c   |   20 +
 kernel/trace/Kconfig|  104 
 kernel/trace/Makefile   |4 +
 kernel/trace/latency_hist.c | 1091 +++
 kernel/trace/trace_irqsoff.c|9 +
 10 files changed, 1631 insertions(+)
 create mode 100644 Documentation/trace/histograms.txt
 create mode 100644 include/trace/events/hist.h
 create mode 100644 include/trace/events/latency_hist.h
 create mode 100644 kernel/trace/latency_hist.c

diff --git a/Documentation/trace/histograms.txt 
b/Documentation/trace/histograms.txt
new file mode 100644
index 000..60644ff
--- /dev/null
+++ b/Documentation/trace/histograms.txt
@@ -0,0 +1,186 @@
+   Using the Linux Kernel Latency Histograms
+
+
+This document gives a short explanation how to enable, configure and use
+latency histograms. Latency histograms are primarily relevant in the
+context of real-time enabled kernels (CONFIG_PREEMPT/CONFIG_PREEMPT_RT)
+and are used in the quality management of the Linux real-time
+capabilities.
+
+
+* Purpose of latency histograms
+
+A latency histogram continuously accumulates the frequencies of latency
+data. There are two types of histograms
+- potential sources of latencies
+- effective latencies
+
+
+* Potential sources of latencies
+
+Potential sources of latencies are code segments where interrupts,
+preemption or both are disabled (aka critical sections). To create
+histograms of potential sources of latency, the kernel stores the time
+stamp at the start of a critical section, determines the time elapsed
+when the end of the section is reached, and increments the frequency
+counter of that latency value - irrespective of whether any concurrently
+running process is affected by latency or not.
+- Configuration items (in the Kernel hacking/Tracers submenu)
+  CONFIG_INTERRUPT_OFF_LATENCY
+  CONFIG_PREEMPT_OFF_LATENCY
+
+
+* Effective latencies
+
+Effective latencies are actually occurring during wakeup of a process. To
+determine effective latencies, the kernel stores the time stamp when a
+process is scheduled to be woken up, and determines the duration of the
+wakeup time shortly before control is passed over to this process. Note
+that the apparent latency in user space may be somewhat longer, since the
+process may be interrupted after control is passed over to it but before
+the execution in user space takes place. Simply measuring the interval
+between enqueuing and wakeup may also not appropriate in cases when a
+process is scheduled as a result of a timer expiration. The timer may have
+missed its deadline, e.g. due to disabled interrupts, but this latency
+would not be registered. Therefore, the offsets of missed timers are
+recorded in a separate histogram. If both wakeup latency and missed timer
+offsets are configured and enabled, a third histogram may be enabled that
+records the overall latency as a sum of the timer latency, if any, and the
+wakeup latency. This histogram is called "timerandwakeup".
+- Configuration items (in the Kernel hacking/Tracers submenu)
+  CONFIG_WAKEUP_LATENCY
+  CONFIG_MISSED_TIMER_OFSETS
+
+
+* Usage
+
+The interface to the administration of the latency histograms is located
+in the debugfs file system. To mount it, either enter
+
+mount -t sysfs nodev /sys
+mount -t debugfs nodev /sys/kernel/debug
+
+from shell command line level, or add
+
+nodev  /syssysfs   defaults0 0
+nodev  /sys/kernel/debug   debugfs defaults0 0
+
+to the file /etc/fstab. All latency histogram related files are then
+available in the directory /sys/kernel/debug/tracing/latency_hist. A
+particular histogram type is enabled by writing non-zero to the related
+variable in the /sys/kernel/debug/tracing/latency_hist/enable directory.
+Select "preemptirqsoff" for the histograms of potential sources of
+latencies and "wakeup" for histograms of effective latencies etc. The
+histogram data - one per CPU - are available in the files
+

[PATCH 2/2] trace: Add missing tracer macros

[Binoy Jayan]

From: Yang Shi 

When building rt kernel with IRQSOFF_TRACER enabled but INTERRUPT_OFF_HIST
or PREEMPT_OFF_HIST disabled, the below build failure will be triggered:

| kernel/trace/trace_irqsoff.c: In function 'time_hardirqs_on':
| kernel/trace/trace_irqsoff.c:453:2: error: implicit declaration of
|   function 'trace_preemptirqsoff_hist_rcuidle'
|   [-Werror=implicit-function-declaration]
|   trace_preemptirqsoff_hist_rcuidle(IRQS_ON, 0);
|   ^
| cc1: some warnings being treated as errors
| scripts/Makefile.build:258: recipe for target
|   'kernel/trace/trace_irqsoff.o' failed
| make[4]: *** [kernel/trace/trace_irqsoff.o] Error 1
| make[4]: *** Waiting for unfinished jobs
| scripts/Makefile.build:403: recipe for target 'kernel/trace' failed

These macros are only defined when both PREEMPT_OFF_HIST and
PREEMPT_OFF_HIST are enabled, otherwise just trace_preemptirqsoff_hist
is defined as a preprocessor macro.

Signed-off-by: Yang Shi 
Cc: linaro-ker...@lists.linaro.org
Cc: bige...@linutronix.de
Cc: rost...@goodmis.org
Cc: stable...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1445280008-8456-1-git-send-email-yang@linaro.org
Signed-off-by: Thomas Gleixner 
---
 include/trace/events/hist.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/trace/events/hist.h b/include/trace/events/hist.h
index 6122e42..37f6eb8 100644
--- a/include/trace/events/hist.h
+++ b/include/trace/events/hist.h
@@ -9,6 +9,7 @@
 
 #if !defined(CONFIG_PREEMPT_OFF_HIST) && !defined(CONFIG_INTERRUPT_OFF_HIST)
 #define trace_preemptirqsoff_hist(a, b)
+#define trace_preemptirqsoff_hist_rcuidle(a, b)
 #else
 TRACE_EVENT(preemptirqsoff_hist,
 
@@ -33,6 +34,7 @@ TRACE_EVENT(preemptirqsoff_hist,
 
 #ifndef CONFIG_MISSED_TIMER_OFFSETS_HIST
 #define trace_hrtimer_interrupt(a, b, c, d)
+#define trace_hrtimer_interrupt_rcuidle(a, b, c, d)
 #else
 TRACE_EVENT(hrtimer_interrupt,
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/2] tracing: Add latency histograms

[Binoy Jayan]

From: Carsten Emde 

This patch provides a recording mechanism to store data of potential
sources of system latencies. The recordings separately determine the
latency caused by a delayed timer expiration, by a delayed wakeup of the
related user space program and by the sum of both. The histograms can be
enabled and reset individually. The data are accessible via the debug
filesystem. The patch is adapted from the rt kernel and restructured to
avoid unwanted macros from source files. For details please consult
Documentation/trace/histograms.txt.

Signed-off-by: Carsten Emde 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Binoy Jayan 
---
 Documentation/trace/histograms.txt  |  186 ++
 include/linux/hrtimer.h |3 +
 include/linux/sched.h   |6 +
 include/trace/events/hist.h |   72 +++
 include/trace/events/latency_hist.h |  136 +
 kernel/time/hrtimer.c   |   20 +
 kernel/trace/Kconfig|  104 
 kernel/trace/Makefile   |4 +
 kernel/trace/latency_hist.c | 1091 +++
 kernel/trace/trace_irqsoff.c|9 +
 10 files changed, 1631 insertions(+)
 create mode 100644 Documentation/trace/histograms.txt
 create mode 100644 include/trace/events/hist.h
 create mode 100644 include/trace/events/latency_hist.h
 create mode 100644 kernel/trace/latency_hist.c

diff --git a/Documentation/trace/histograms.txt 
b/Documentation/trace/histograms.txt
new file mode 100644
index 000..60644ff
--- /dev/null
+++ b/Documentation/trace/histograms.txt
@@ -0,0 +1,186 @@
+   Using the Linux Kernel Latency Histograms
+
+
+This document gives a short explanation how to enable, configure and use
+latency histograms. Latency histograms are primarily relevant in the
+context of real-time enabled kernels (CONFIG_PREEMPT/CONFIG_PREEMPT_RT)
+and are used in the quality management of the Linux real-time
+capabilities.
+
+
+* Purpose of latency histograms
+
+A latency histogram continuously accumulates the frequencies of latency
+data. There are two types of histograms
+- potential sources of latencies
+- effective latencies
+
+
+* Potential sources of latencies
+
+Potential sources of latencies are code segments where interrupts,
+preemption or both are disabled (aka critical sections). To create
+histograms of potential sources of latency, the kernel stores the time
+stamp at the start of a critical section, determines the time elapsed
+when the end of the section is reached, and increments the frequency
+counter of that latency value - irrespective of whether any concurrently
+running process is affected by latency or not.
+- Configuration items (in the Kernel hacking/Tracers submenu)
+  CONFIG_INTERRUPT_OFF_LATENCY
+  CONFIG_PREEMPT_OFF_LATENCY
+
+
+* Effective latencies
+
+Effective latencies are actually occurring during wakeup of a process. To
+determine effective latencies, the kernel stores the time stamp when a
+process is scheduled to be woken up, and determines the duration of the
+wakeup time shortly before control is passed over to this process. Note
+that the apparent latency in user space may be somewhat longer, since the
+process may be interrupted after control is passed over to it but before
+the execution in user space takes place. Simply measuring the interval
+between enqueuing and wakeup may also not appropriate in cases when a
+process is scheduled as a result of a timer expiration. The timer may have
+missed its deadline, e.g. due to disabled interrupts, but this latency
+would not be registered. Therefore, the offsets of missed timers are
+recorded in a separate histogram. If both wakeup latency and missed timer
+offsets are configured and enabled, a third histogram may be enabled that
+records the overall latency as a sum of the timer latency, if any, and the
+wakeup latency. This histogram is called "timerandwakeup".
+- Configuration items (in the Kernel hacking/Tracers submenu)
+  CONFIG_WAKEUP_LATENCY
+  CONFIG_MISSED_TIMER_OFSETS
+
+
+* Usage
+
+The interface to the administration of the latency histograms is located
+in the debugfs file system. To mount it, either enter
+
+mount -t sysfs nodev /sys
+mount -t debugfs nodev /sys/kernel/debug
+
+from shell command line level, or add
+
+nodev  /syssysfs   defaults0 0
+nodev  /sys/kernel/debug   debugfs defaults0 0
+
+to the file /etc/fstab. All latency histogram related files are then
+available in the directory /sys/kernel/debug/tracing/latency_hist. A
+particular histogram type is enabled by writing non-zero to the related
+variable in the /sys/kernel/debug/tracing/latency_hist/enable directory.
+Select "preemptirqsoff" for the histograms of potential sources of
+latencies and "wakeup" for histograms of effective latencies etc. The
+histogram data - one per CPU - are available in the files
+
+/sys/kernel/debug/tracing/latency_hist/preemptoff/CPUx

[PATCH 2/2] trace: Add missing tracer macros

[Binoy Jayan]

From: Yang Shi 

When building rt kernel with IRQSOFF_TRACER enabled but INTERRUPT_OFF_HIST
or PREEMPT_OFF_HIST disabled, the below build failure will be triggered:

| kernel/trace/trace_irqsoff.c: In function 'time_hardirqs_on':
| kernel/trace/trace_irqsoff.c:453:2: error: implicit declaration of
|   function 'trace_preemptirqsoff_hist_rcuidle'
|   [-Werror=implicit-function-declaration]
|   trace_preemptirqsoff_hist_rcuidle(IRQS_ON, 0);
|   ^
| cc1: some warnings being treated as errors
| scripts/Makefile.build:258: recipe for target
|   'kernel/trace/trace_irqsoff.o' failed
| make[4]: *** [kernel/trace/trace_irqsoff.o] Error 1
| make[4]: *** Waiting for unfinished jobs
| scripts/Makefile.build:403: recipe for target 'kernel/trace' failed

These macros are only defined when both PREEMPT_OFF_HIST and
PREEMPT_OFF_HIST are enabled, otherwise just trace_preemptirqsoff_hist
is defined as a preprocessor macro.

Signed-off-by: Yang Shi 
Cc: linaro-ker...@lists.linaro.org
Cc: bige...@linutronix.de
Cc: rost...@goodmis.org
Cc: stable...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1445280008-8456-1-git-send-email-yang@linaro.org
Signed-off-by: Thomas Gleixner 
---
 include/trace/events/hist.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/trace/events/hist.h b/include/trace/events/hist.h
index 6122e42..37f6eb8 100644
--- a/include/trace/events/hist.h
+++ b/include/trace/events/hist.h
@@ -9,6 +9,7 @@
 
 #if !defined(CONFIG_PREEMPT_OFF_HIST) && !defined(CONFIG_INTERRUPT_OFF_HIST)
 #define trace_preemptirqsoff_hist(a, b)
+#define trace_preemptirqsoff_hist_rcuidle(a, b)
 #else
 TRACE_EVENT(preemptirqsoff_hist,
 
@@ -33,6 +34,7 @@ TRACE_EVENT(preemptirqsoff_hist,
 
 #ifndef CONFIG_MISSED_TIMER_OFFSETS_HIST
 #define trace_hrtimer_interrupt(a, b, c, d)
+#define trace_hrtimer_interrupt_rcuidle(a, b, c, d)
 #else
 TRACE_EVENT(hrtimer_interrupt,
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 0/2] *** Latency Histogram ***

[Binoy Jayan]

Hi,

I was looking at these RT kernel patches and was wondering why it has
not been upstreamed yet. I have made a few changes to these patches to
make it compliant with upstream submission process. Also did a minimal
testing on my msm board. Can some one from rt kernel team shed some
light on why this is not upstreamed yet? Also if there some way to test
this throroughly on a board with a high resolution timer running mainline
(and not rt) kernel.

Binoy

Carsten Emde (1):
  tracing: Add latency histograms

Yang Shi (1):
  trace: Add missing tracer macros

 Documentation/trace/histograms.txt  |  186 ++
 include/linux/hrtimer.h |3 +
 include/linux/sched.h   |6 +
 include/trace/events/hist.h |   74 +++
 include/trace/events/latency_hist.h |  136 +
 kernel/time/hrtimer.c   |   20 +
 kernel/trace/Kconfig|  104 
 kernel/trace/Makefile   |4 +
 kernel/trace/latency_hist.c | 1091 +++
 kernel/trace/trace_irqsoff.c|9 +
 10 files changed, 1633 insertions(+)
 create mode 100644 Documentation/trace/histograms.txt
 create mode 100644 include/trace/events/hist.h
 create mode 100644 include/trace/events/latency_hist.h
 create mode 100644 kernel/trace/latency_hist.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 0/2] *** Latency Histogram ***

[Binoy Jayan]

Hi,

I was looking at these RT kernel patches and was wondering why it has
not been upstreamed yet. I have made a few changes to these patches to
make it compliant with upstream submission process. Also did a minimal
testing on my msm board. Can some one from rt kernel team shed some
light on why this is not upstreamed yet? Also if there some way to test
this throroughly on a board with a high resolution timer running mainline
(and not rt) kernel.

Binoy

Carsten Emde (1):
  tracing: Add latency histograms

Yang Shi (1):
  trace: Add missing tracer macros

 Documentation/trace/histograms.txt  |  186 ++
 include/linux/hrtimer.h |3 +
 include/linux/sched.h   |6 +
 include/trace/events/hist.h |   74 +++
 include/trace/events/latency_hist.h |  136 +
 kernel/time/hrtimer.c   |   20 +
 kernel/trace/Kconfig|  104 
 kernel/trace/Makefile   |4 +
 kernel/trace/latency_hist.c | 1091 +++
 kernel/trace/trace_irqsoff.c|9 +
 10 files changed, 1633 insertions(+)
 create mode 100644 Documentation/trace/histograms.txt
 create mode 100644 include/trace/events/hist.h
 create mode 100644 include/trace/events/latency_hist.h
 create mode 100644 kernel/trace/latency_hist.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] dmaengine: device must have at least one channel

[Viresh Kumar]

On 28-07-16, 09:18, Vinod Koul wrote:
> On Wed, Jul 27, 2016 at 02:32:58PM -0700, Viresh Kumar wrote:
> > The DMA device can't be registered if it doesn't have any channels
> > registered at all. Moreover, it leads to memory leak and is reported by
> > kmemleak as (on 3.10 kernel, and same shall happen on mainline):
> > 
> > unreferenced object 0xffc09e597240 (size 64):
> >   comm "swapper/0", pid 1, jiffies 4294877736 (age 7060.280s)
> >   hex dump (first 32 bytes):
> > 00 00 00 00 c0 ff ff ff 30 00 00 ff 00 00 00 ff  0...
> > 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff  
> >   backtrace:
> > [] create_object+0x148/0x2a0
> > [] kmemleak_alloc+0x80/0xbc
> > [] kmem_cache_alloc_trace+0x120/0x1ac
> > [] dma_async_device_register+0x160/0x46c
> > [] foo_probe+0x1a0/0x264
> > [] platform_drv_probe+0x14/0x20
> > [] driver_probe_device+0x160/0x374
> > [] __driver_attach+0x60/0x90
> > [] bus_for_each_dev+0x7c/0xb0
> > [] driver_attach+0x1c/0x28
> > [] bus_add_driver+0x124/0x248
> > [] driver_register+0x90/0x110
> > [] platform_driver_register+0x58/0x64
> > [] foo_driver_init+0x10/0x1c
> > [] do_one_initcall+0xac/0x148
> > [] kernel_init_freeable+0x1a0/0x258
> > 
> > Return -ENODEV from dma_async_device_register() on such a case.
> > 
> > /Signed-off-by: Viresh Kumar 
> > ---
> > Hi Vinod,
> > 
> > Sorry if the fundamentals behind this patch are completely incorrect,
> > i.e. We *can't* register a dma device with 0 channels. Its been long
> > that I have worked on dma stuff :)
> 
> This sounds okay,

Great..

> but why would anyone register a device without having
> a channel?

A buggy driver? The core should be handling this no matter what,
right?

The out of tree driver, 3.10 based driver I have looks to be buggy to
me. It is doing something like this (please ignore naming/formatting):

xlate()
{
chan = alloc();
list_add(chan.device_node, _dev.channels)
}

probe()
{
...
dma_async_device_register()
of_dma_controller_register(xlate);
...
}

But with this it looks like the 'chan' structure wouldn't get
initialized properly as that is done from within
dma_async_device_register(). Right? Also, I am not sure if DMA is
getting used at all right now on my platform. Just noticed the
memleak, which I tried to fix.

-- 
viresh

Re: [PATCH] dmaengine: device must have at least one channel

[Viresh Kumar]

On 28-07-16, 09:18, Vinod Koul wrote:
> On Wed, Jul 27, 2016 at 02:32:58PM -0700, Viresh Kumar wrote:
> > The DMA device can't be registered if it doesn't have any channels
> > registered at all. Moreover, it leads to memory leak and is reported by
> > kmemleak as (on 3.10 kernel, and same shall happen on mainline):
> > 
> > unreferenced object 0xffc09e597240 (size 64):
> >   comm "swapper/0", pid 1, jiffies 4294877736 (age 7060.280s)
> >   hex dump (first 32 bytes):
> > 00 00 00 00 c0 ff ff ff 30 00 00 ff 00 00 00 ff  0...
> > 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff  
> >   backtrace:
> > [] create_object+0x148/0x2a0
> > [] kmemleak_alloc+0x80/0xbc
> > [] kmem_cache_alloc_trace+0x120/0x1ac
> > [] dma_async_device_register+0x160/0x46c
> > [] foo_probe+0x1a0/0x264
> > [] platform_drv_probe+0x14/0x20
> > [] driver_probe_device+0x160/0x374
> > [] __driver_attach+0x60/0x90
> > [] bus_for_each_dev+0x7c/0xb0
> > [] driver_attach+0x1c/0x28
> > [] bus_add_driver+0x124/0x248
> > [] driver_register+0x90/0x110
> > [] platform_driver_register+0x58/0x64
> > [] foo_driver_init+0x10/0x1c
> > [] do_one_initcall+0xac/0x148
> > [] kernel_init_freeable+0x1a0/0x258
> > 
> > Return -ENODEV from dma_async_device_register() on such a case.
> > 
> > /Signed-off-by: Viresh Kumar 
> > ---
> > Hi Vinod,
> > 
> > Sorry if the fundamentals behind this patch are completely incorrect,
> > i.e. We *can't* register a dma device with 0 channels. Its been long
> > that I have worked on dma stuff :)
> 
> This sounds okay,

Great..

> but why would anyone register a device without having
> a channel?

A buggy driver? The core should be handling this no matter what,
right?

The out of tree driver, 3.10 based driver I have looks to be buggy to
me. It is doing something like this (please ignore naming/formatting):

xlate()
{
chan = alloc();
list_add(chan.device_node, _dev.channels)
}

probe()
{
...
dma_async_device_register()
of_dma_controller_register(xlate);
...
}

But with this it looks like the 'chan' structure wouldn't get
initialized properly as that is done from within
dma_async_device_register(). Right? Also, I am not sure if DMA is
getting used at all right now on my platform. Just noticed the
memleak, which I tried to fix.

-- 
viresh

[PATCH] mpt3sas: Ensure the connector_name string is NUL-terminated

[Calvin Owens]

We blindly trust the hardware to give us NUL-terminated strings, which
is a bad idea because it doesn't always do that. For example:

  [  481.184784] mpt3sas_cm0:   enclosure level(0x), connector name( 
\x3)

In this case, connector_name is four spaces. We got lucky here because
the 2nd byte beyond our character array happens to be a NUL. Fix this
by explicitly writing '\0' to the end of the string to ensure we don't
run off the edge of the world in printk().

Signed-off-by: Calvin Owens 
---
 drivers/scsi/mpt3sas/mpt3sas_base.h  |  2 +-
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 10 ++
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 892c9be..eb7f5b0 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -478,7 +478,7 @@ struct _sas_device {
u8  pfa_led_on;
u8  pend_sas_rphy_add;
u8  enclosure_level;
-   u8  connector_name[4];
+   u8  connector_name[5];
struct kref refcount;
 };
 
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index cd91a68..acabe48 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -5380,8 +5380,9 @@ _scsih_check_device(struct MPT3SAS_ADAPTER *ioc,
 MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID) {
sas_device->enclosure_level =
le16_to_cpu(sas_device_pg0.EnclosureLevel);
-   memcpy(_device->connector_name[0],
-   _device_pg0.ConnectorName[0], 4);
+   memcpy(sas_device->connector_name,
+   sas_device_pg0.ConnectorName, 4);
+   sas_device->connector_name[4] = '\0';
} else {
sas_device->enclosure_level = 0;
sas_device->connector_name[0] = '\0';
@@ -5508,8 +5509,9 @@ _scsih_add_device(struct MPT3SAS_ADAPTER *ioc, u16 
handle, u8 phy_num,
if (sas_device_pg0.Flags & MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID) {
sas_device->enclosure_level =
le16_to_cpu(sas_device_pg0.EnclosureLevel);
-   memcpy(_device->connector_name[0],
-   _device_pg0.ConnectorName[0], 4);
+   memcpy(sas_device->connector_name,
+   sas_device_pg0.ConnectorName, 4);
+   sas_device->connector_name[4] = '\0';
} else {
sas_device->enclosure_level = 0;
sas_device->connector_name[0] = '\0';
-- 
2.8.0.rc2

[PATCH] mpt3sas: Ensure the connector_name string is NUL-terminated

[Calvin Owens]

We blindly trust the hardware to give us NUL-terminated strings, which
is a bad idea because it doesn't always do that. For example:

  [  481.184784] mpt3sas_cm0:   enclosure level(0x), connector name( 
\x3)

In this case, connector_name is four spaces. We got lucky here because
the 2nd byte beyond our character array happens to be a NUL. Fix this
by explicitly writing '\0' to the end of the string to ensure we don't
run off the edge of the world in printk().

Signed-off-by: Calvin Owens 
---
 drivers/scsi/mpt3sas/mpt3sas_base.h  |  2 +-
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 10 ++
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 892c9be..eb7f5b0 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -478,7 +478,7 @@ struct _sas_device {
u8  pfa_led_on;
u8  pend_sas_rphy_add;
u8  enclosure_level;
-   u8  connector_name[4];
+   u8  connector_name[5];
struct kref refcount;
 };
 
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index cd91a68..acabe48 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -5380,8 +5380,9 @@ _scsih_check_device(struct MPT3SAS_ADAPTER *ioc,
 MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID) {
sas_device->enclosure_level =
le16_to_cpu(sas_device_pg0.EnclosureLevel);
-   memcpy(_device->connector_name[0],
-   _device_pg0.ConnectorName[0], 4);
+   memcpy(sas_device->connector_name,
+   sas_device_pg0.ConnectorName, 4);
+   sas_device->connector_name[4] = '\0';
} else {
sas_device->enclosure_level = 0;
sas_device->connector_name[0] = '\0';
@@ -5508,8 +5509,9 @@ _scsih_add_device(struct MPT3SAS_ADAPTER *ioc, u16 
handle, u8 phy_num,
if (sas_device_pg0.Flags & MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID) {
sas_device->enclosure_level =
le16_to_cpu(sas_device_pg0.EnclosureLevel);
-   memcpy(_device->connector_name[0],
-   _device_pg0.ConnectorName[0], 4);
+   memcpy(sas_device->connector_name,
+   sas_device_pg0.ConnectorName, 4);
+   sas_device->connector_name[4] = '\0';
} else {
sas_device->enclosure_level = 0;
sas_device->connector_name[0] = '\0';
-- 
2.8.0.rc2

Re: [RFC 4/4] Restartable sequences: Add self-tests for PPC

[Boqun Feng]

On Thu, Jul 28, 2016 at 02:59:45AM +, Mathieu Desnoyers wrote:
> - On Jul 27, 2016, at 11:05 AM, Boqun Feng boqun.f...@gmail.com wrote:
> 
> > As rseq syscall is enabled on PPC, implement the self-tests on PPC to
> > verify the implementation of the syscall.
> > 
> > Please note we only support 32bit userspace on BE kernel.
> > 
> > Signed-off-by: Boqun Feng 
> > ---
> > tools/testing/selftests/rseq/param_test.c |  14 
> > tools/testing/selftests/rseq/rseq.h   | 120 
> > ++
> > 2 files changed, 134 insertions(+)
> > 
> > diff --git a/tools/testing/selftests/rseq/param_test.c
> > b/tools/testing/selftests/rseq/param_test.c
> > index db25e0a818e5..e2cb1b165f81 100644
> > --- a/tools/testing/selftests/rseq/param_test.c
> > +++ b/tools/testing/selftests/rseq/param_test.c
> > @@ -75,6 +75,20 @@ static __thread unsigned int yield_mod_cnt, nr_retry;
> > "bne 222b\n\t" \
> > "333:\n\t"
> > 
> > +#elif __PPC__
> > +#define INJECT_ASM_REG "r18"
> > +
> > +#define RSEQ_INJECT_CLOBBER \
> > +   , INJECT_ASM_REG
> > +
> > +#define RSEQ_INJECT_ASM(n) \
> > +   "lwz %%" INJECT_ASM_REG ", %[loop_cnt_" #n "]\n\t" \
> > +   "cmpwi %%" INJECT_ASM_REG ", 0\n\t" \
> > +   "beq 333f\n\t" \
> > +   "222:\n\t" \
> > +   "subic. %%" INJECT_ASM_REG ", %%" INJECT_ASM_REG ", 1\n\t" \
> > +   "bne 222b\n\t" \
> > +   "333:\n\t"
> > #else
> > #error unsupported target
> > #endif
> > diff --git a/tools/testing/selftests/rseq/rseq.h
> > b/tools/testing/selftests/rseq/rseq.h
> > index 791e14cf42ae..dea0bea52566 100644
> > --- a/tools/testing/selftests/rseq/rseq.h
> > +++ b/tools/testing/selftests/rseq/rseq.h
> > @@ -138,6 +138,35 @@ do {   
> > \
> > #define has_fast_acquire_release()  0
> > #define has_single_copy_load_64()   1
> > 
> > +#elif __PPC__
> > +#define smp_mb()   __asm__ __volatile__ ("sync" : : : "memory")
> > +#define smp_lwsync()   __asm__ __volatile__ ("lwsync" : : : "memory")
> > +#define smp_rmb()  smp_lwsync()
> > +#define smp_wmb()  smp_lwsync()
> > +
> > +#define smp_load_acquire(p)
> > \
> > +__extension__ ({   \
> > +   __typeof(*p) p1 = READ_ONCE(*p);\
> > +   smp_lwsync();   \
> > +   p1; \
> > +})
> > +
> > +#define smp_acquire__after_ctrl_dep()  smp_lwsync()
> > +
> > +#define smp_store_release(p, v)
> > \
> > +do {   
> > \
> > +   smp_lwsync();   \
> > +   WRITE_ONCE(*p, v);  \
> > +} while (0)
> > +
> > +#define has_fast_acquire_release() 1
> 
> Can you check if defining has_fast_acquire_release() to 0 speeds up
> performance significantly ? It turns the smp_lwsync() into a
> compiler barrier() on the smp_load_acquire() side (fast-path), and
> turn the smp_lwsync() into a membarrier system call instead of the
> matching smp_store_release() (slow path).
> 

Good point. Here are the numbers:

Power8 PSeries KVM Guest(64 VCPUs, the host has 16 cores, 128 hardware
threads):

 Counter increment speed (ns/increment)
  1 thread   2 threads   4 threads   8 threads   16 
threads   32 threads
global increment (baseline) 6.5  N/A N/A N/A   
N/A   N/A
percpu rseq increment   7.0  7.0 7.2 7.2   
9.3  14.5
percpu rseq spinlock   18.5 18.518.618.8  
25.5  52.7

So looks like defining has_fast_acquire_release() to 0 could benefit the
cases with more threads in current benchmark. I will send a updated
patch doing this.

And as discussed in IRC, I will also remove jump from rseq_finish()
fast-path in powerpc asm in the updated patch as you did for x86 and
ARM.

Regards,
Boqun


> Thanks,
> 
> Mathieu
> 
> > +
> > +# if __PPC64__
> > +# define has_single_copy_load_64() 1
> > +# else
> > +# define has_single_copy_load_64() 0
> > +# endif
> > +
> > #else
> > #error unsupported target
> > #endif
> > @@ -404,6 +433,97 @@ bool rseq_finish(struct rseq_lock *rlock,
> > : succeed
> > );
> > }
> > +#elif __PPC64__
> > +   {
> > +   /*
> > +* The __rseq_table section can be used by debuggers to better
> > +* handle single-stepping through the restartable critical
> > +* sections.
> > +*/
> > +   __asm__ __volatile__ goto (
> > +   ".pushsection __rseq_table, \"aw\"\n\t"
> > +   ".balign 8\n\t"
> > +   "4:\n\t"
> > + 

Re: [RFC 4/4] Restartable sequences: Add self-tests for PPC

[Boqun Feng]

On Thu, Jul 28, 2016 at 02:59:45AM +, Mathieu Desnoyers wrote:
> - On Jul 27, 2016, at 11:05 AM, Boqun Feng boqun.f...@gmail.com wrote:
> 
> > As rseq syscall is enabled on PPC, implement the self-tests on PPC to
> > verify the implementation of the syscall.
> > 
> > Please note we only support 32bit userspace on BE kernel.
> > 
> > Signed-off-by: Boqun Feng 
> > ---
> > tools/testing/selftests/rseq/param_test.c |  14 
> > tools/testing/selftests/rseq/rseq.h   | 120 
> > ++
> > 2 files changed, 134 insertions(+)
> > 
> > diff --git a/tools/testing/selftests/rseq/param_test.c
> > b/tools/testing/selftests/rseq/param_test.c
> > index db25e0a818e5..e2cb1b165f81 100644
> > --- a/tools/testing/selftests/rseq/param_test.c
> > +++ b/tools/testing/selftests/rseq/param_test.c
> > @@ -75,6 +75,20 @@ static __thread unsigned int yield_mod_cnt, nr_retry;
> > "bne 222b\n\t" \
> > "333:\n\t"
> > 
> > +#elif __PPC__
> > +#define INJECT_ASM_REG "r18"
> > +
> > +#define RSEQ_INJECT_CLOBBER \
> > +   , INJECT_ASM_REG
> > +
> > +#define RSEQ_INJECT_ASM(n) \
> > +   "lwz %%" INJECT_ASM_REG ", %[loop_cnt_" #n "]\n\t" \
> > +   "cmpwi %%" INJECT_ASM_REG ", 0\n\t" \
> > +   "beq 333f\n\t" \
> > +   "222:\n\t" \
> > +   "subic. %%" INJECT_ASM_REG ", %%" INJECT_ASM_REG ", 1\n\t" \
> > +   "bne 222b\n\t" \
> > +   "333:\n\t"
> > #else
> > #error unsupported target
> > #endif
> > diff --git a/tools/testing/selftests/rseq/rseq.h
> > b/tools/testing/selftests/rseq/rseq.h
> > index 791e14cf42ae..dea0bea52566 100644
> > --- a/tools/testing/selftests/rseq/rseq.h
> > +++ b/tools/testing/selftests/rseq/rseq.h
> > @@ -138,6 +138,35 @@ do {   
> > \
> > #define has_fast_acquire_release()  0
> > #define has_single_copy_load_64()   1
> > 
> > +#elif __PPC__
> > +#define smp_mb()   __asm__ __volatile__ ("sync" : : : "memory")
> > +#define smp_lwsync()   __asm__ __volatile__ ("lwsync" : : : "memory")
> > +#define smp_rmb()  smp_lwsync()
> > +#define smp_wmb()  smp_lwsync()
> > +
> > +#define smp_load_acquire(p)
> > \
> > +__extension__ ({   \
> > +   __typeof(*p) p1 = READ_ONCE(*p);\
> > +   smp_lwsync();   \
> > +   p1; \
> > +})
> > +
> > +#define smp_acquire__after_ctrl_dep()  smp_lwsync()
> > +
> > +#define smp_store_release(p, v)
> > \
> > +do {   
> > \
> > +   smp_lwsync();   \
> > +   WRITE_ONCE(*p, v);  \
> > +} while (0)
> > +
> > +#define has_fast_acquire_release() 1
> 
> Can you check if defining has_fast_acquire_release() to 0 speeds up
> performance significantly ? It turns the smp_lwsync() into a
> compiler barrier() on the smp_load_acquire() side (fast-path), and
> turn the smp_lwsync() into a membarrier system call instead of the
> matching smp_store_release() (slow path).
> 

Good point. Here are the numbers:

Power8 PSeries KVM Guest(64 VCPUs, the host has 16 cores, 128 hardware
threads):

 Counter increment speed (ns/increment)
  1 thread   2 threads   4 threads   8 threads   16 
threads   32 threads
global increment (baseline) 6.5  N/A N/A N/A   
N/A   N/A
percpu rseq increment   7.0  7.0 7.2 7.2   
9.3  14.5
percpu rseq spinlock   18.5 18.518.618.8  
25.5  52.7

So looks like defining has_fast_acquire_release() to 0 could benefit the
cases with more threads in current benchmark. I will send a updated
patch doing this.

And as discussed in IRC, I will also remove jump from rseq_finish()
fast-path in powerpc asm in the updated patch as you did for x86 and
ARM.

Regards,
Boqun


> Thanks,
> 
> Mathieu
> 
> > +
> > +# if __PPC64__
> > +# define has_single_copy_load_64() 1
> > +# else
> > +# define has_single_copy_load_64() 0
> > +# endif
> > +
> > #else
> > #error unsupported target
> > #endif
> > @@ -404,6 +433,97 @@ bool rseq_finish(struct rseq_lock *rlock,
> > : succeed
> > );
> > }
> > +#elif __PPC64__
> > +   {
> > +   /*
> > +* The __rseq_table section can be used by debuggers to better
> > +* handle single-stepping through the restartable critical
> > +* sections.
> > +*/
> > +   __asm__ __volatile__ goto (
> > +   ".pushsection __rseq_table, \"aw\"\n\t"
> > +   ".balign 8\n\t"
> > +   "4:\n\t"
> > +   ".quad 1f, 2f, 

RE: [PATCH v2 repost 6/7] mm: add the related functions to get free page info

[Li, Liang Z]

> On 07/27/2016 03:05 PM, Michael S. Tsirkin wrote:
> > On Wed, Jul 27, 2016 at 09:40:56AM -0700, Dave Hansen wrote:
> >> On 07/26/2016 06:23 PM, Liang Li wrote:
> >>> + for_each_migratetype_order(order, t) {
> >>> + list_for_each(curr, >free_area[order].free_list[t]) {
> >>> + pfn = page_to_pfn(list_entry(curr, struct page, lru));
> >>> + if (pfn >= start_pfn && pfn <= end_pfn) {
> >>> + page_num = 1UL << order;
> >>> + if (pfn + page_num > end_pfn)
> >>> + page_num = end_pfn - pfn;
> >>> + bitmap_set(bitmap, pfn - start_pfn,
> page_num);
> >>> + }
> >>> + }
> >>> + }
> >>
> >> Nit:  The 'page_num' nomenclature really confused me here.  It is the
> >> number of bits being set in the bitmap.  Seems like calling it
> >> nr_pages or num_pages would be more appropriate.
> >>
> >> Isn't this bitmap out of date by the time it's send up to the
> >> hypervisor?  Is there something that makes the inaccuracy OK here?
> >
> > Yes. Calling these free pages is unfortunate. It's likely to confuse
> > people thinking they can just discard these pages.
> >
> > Hypervisor sends a request. We respond with this list of pages, and
> > the guarantee hypervisor needs is that these were free sometime
> > between request and response, so they are safe to free if they are
> > unmodified since the request. hypervisor can detect modifications so
> > it can detect modifications itself and does not need guest help.
> 
> Ahh, that makes sense.
> 
> So the hypervisor is trying to figure out: "Which pages do I move?".  It wants
> to know which pages the guest thinks have good data and need to move.
> But, the list of free pages is (likely) smaller than the list of pages with 
> good
> data, so it asks for that instead.
> 
> A write to a page means that it has valuable data, regardless of whether it
> was in the free list or not.
> 
> The hypervisor only skips moving pages that were free *and* were never
> written to.  So we never lose data, even if this "get free page info"
> stuff is totally out of date.
> 
> The patch description and code comments are, um, a _bit_ light for this level
> of subtlety. :)

I will add more description about this in v3.

Thanks!
Liang

RE: [PATCH v2 repost 6/7] mm: add the related functions to get free page info

[Li, Liang Z]

> On 07/27/2016 03:05 PM, Michael S. Tsirkin wrote:
> > On Wed, Jul 27, 2016 at 09:40:56AM -0700, Dave Hansen wrote:
> >> On 07/26/2016 06:23 PM, Liang Li wrote:
> >>> + for_each_migratetype_order(order, t) {
> >>> + list_for_each(curr, >free_area[order].free_list[t]) {
> >>> + pfn = page_to_pfn(list_entry(curr, struct page, lru));
> >>> + if (pfn >= start_pfn && pfn <= end_pfn) {
> >>> + page_num = 1UL << order;
> >>> + if (pfn + page_num > end_pfn)
> >>> + page_num = end_pfn - pfn;
> >>> + bitmap_set(bitmap, pfn - start_pfn,
> page_num);
> >>> + }
> >>> + }
> >>> + }
> >>
> >> Nit:  The 'page_num' nomenclature really confused me here.  It is the
> >> number of bits being set in the bitmap.  Seems like calling it
> >> nr_pages or num_pages would be more appropriate.
> >>
> >> Isn't this bitmap out of date by the time it's send up to the
> >> hypervisor?  Is there something that makes the inaccuracy OK here?
> >
> > Yes. Calling these free pages is unfortunate. It's likely to confuse
> > people thinking they can just discard these pages.
> >
> > Hypervisor sends a request. We respond with this list of pages, and
> > the guarantee hypervisor needs is that these were free sometime
> > between request and response, so they are safe to free if they are
> > unmodified since the request. hypervisor can detect modifications so
> > it can detect modifications itself and does not need guest help.
> 
> Ahh, that makes sense.
> 
> So the hypervisor is trying to figure out: "Which pages do I move?".  It wants
> to know which pages the guest thinks have good data and need to move.
> But, the list of free pages is (likely) smaller than the list of pages with 
> good
> data, so it asks for that instead.
> 
> A write to a page means that it has valuable data, regardless of whether it
> was in the free list or not.
> 
> The hypervisor only skips moving pages that were free *and* were never
> written to.  So we never lose data, even if this "get free page info"
> stuff is totally out of date.
> 
> The patch description and code comments are, um, a _bit_ light for this level
> of subtlety. :)

I will add more description about this in v3.

Thanks!
Liang

[PATCH v3 1/2] tpm: devicetree: document properties for cr50

[Andrey Pronin]

Add TPM2.0 PTP FIFO compatible SPI interface for chips with Cr50
firmware.

Signed-off-by: Andrey Pronin 
---
 .../devicetree/bindings/security/tpm/cr50_spi.txt   | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/security/tpm/cr50_spi.txt

diff --git a/Documentation/devicetree/bindings/security/tpm/cr50_spi.txt 
b/Documentation/devicetree/bindings/security/tpm/cr50_spi.txt
new file mode 100644
index 000..2fbebd3
--- /dev/null
+++ b/Documentation/devicetree/bindings/security/tpm/cr50_spi.txt
@@ -0,0 +1,21 @@
+* H1 Secure Microcontroller with Cr50 Firmware on SPI Bus.
+
+H1 Secure Microcontroller running Cr50 firmware provides several
+functions, including TPM-like functionality. It communicates over
+SPI using the FIFO protocol described in the PTP Spec, section 6.
+
+Required properties:
+- compatible: Should be "google,cr50".
+- spi-max-frequency: Maximum SPI frequency.
+
+Example:
+
+ {
+status = "okay";
+
+cr50@0 {
+compatible = "google,cr50";
+reg = <0>;
+spi-max-frequency = <80>;
+};
+};
-- 
2.6.6

[PATCH v3 1/2] tpm: devicetree: document properties for cr50

[Andrey Pronin]

Add TPM2.0 PTP FIFO compatible SPI interface for chips with Cr50
firmware.

Signed-off-by: Andrey Pronin 
---
 .../devicetree/bindings/security/tpm/cr50_spi.txt   | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/security/tpm/cr50_spi.txt

diff --git a/Documentation/devicetree/bindings/security/tpm/cr50_spi.txt 
b/Documentation/devicetree/bindings/security/tpm/cr50_spi.txt
new file mode 100644
index 000..2fbebd3
--- /dev/null
+++ b/Documentation/devicetree/bindings/security/tpm/cr50_spi.txt
@@ -0,0 +1,21 @@
+* H1 Secure Microcontroller with Cr50 Firmware on SPI Bus.
+
+H1 Secure Microcontroller running Cr50 firmware provides several
+functions, including TPM-like functionality. It communicates over
+SPI using the FIFO protocol described in the PTP Spec, section 6.
+
+Required properties:
+- compatible: Should be "google,cr50".
+- spi-max-frequency: Maximum SPI frequency.
+
+Example:
+
+ {
+status = "okay";
+
+cr50@0 {
+compatible = "google,cr50";
+reg = <0>;
+spi-max-frequency = <80>;
+};
+};
-- 
2.6.6

[PATCH v3 2/2] tpm: add driver for cr50 on SPI

[Andrey Pronin]

Add TPM2.0 PTP FIFO compatible SPI interface for chips with Cr50
firmware. The firmware running on the currently supported H1
Secure Microcontroller requires a special driver to handle its
specifics:
 - need to ensure a certain delay between spi transactions, or else
   the chip may miss some part of the next transaction;
 - if there is no spi activity for some time, it may go to sleep,
   and needs to be waken up before sending further commands;
 - access to vendor-specific registers.

Signed-off-by: Andrey Pronin 
---
 drivers/char/tpm/Kconfig|   9 ++
 drivers/char/tpm/Makefile   |   1 +
 drivers/char/tpm/cr50_spi.c | 350 
 3 files changed, 360 insertions(+)
 create mode 100644 drivers/char/tpm/cr50_spi.c

diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 9faa0b1..3320acc 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -100,6 +100,15 @@ config TCG_ATMEL
  will be accessible from within Linux.  To compile this driver 
  as a module, choose M here; the module will be called tpm_atmel.
 
+config TCG_CR50_SPI
+   tristate "TCG PTP FIFO Interface over SPI - Chips with Cr50 Firmware"
+   depends on SPI
+   select TCG_TIS_CORE
+   ---help---
+ If you have a chip running Cr50 firmware on SPI bus, say Yes and it
+ will be accessible from within Linux. To compile this driver as a
+ module, choose M here; the module will be called cr50_spi.
+
 config TCG_INFINEON
tristate "Infineon Technologies TPM Interface"
depends on PNP
diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index a385fb8..b346306 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_TCG_TIS_I2C_INFINEON) += tpm_i2c_infineon.o
 obj-$(CONFIG_TCG_TIS_I2C_NUVOTON) += tpm_i2c_nuvoton.o
 obj-$(CONFIG_TCG_NSC) += tpm_nsc.o
 obj-$(CONFIG_TCG_ATMEL) += tpm_atmel.o
+obj-$(CONFIG_TCG_CR50_SPI) += cr50_spi.o
 obj-$(CONFIG_TCG_INFINEON) += tpm_infineon.o
 obj-$(CONFIG_TCG_IBMVTPM) += tpm_ibmvtpm.o
 obj-$(CONFIG_TCG_TIS_ST33ZP24) += st33zp24/
diff --git a/drivers/char/tpm/cr50_spi.c b/drivers/char/tpm/cr50_spi.c
new file mode 100644
index 000..57ba8b3
--- /dev/null
+++ b/drivers/char/tpm/cr50_spi.c
@@ -0,0 +1,350 @@
+/*
+ * Copyright (C) 2016 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2, as published by
+ * the Free Software Foundation.
+ *
+ * This device driver implements a TCG PTP FIFO interface over SPI for chips
+ * with Cr50 firmware.
+ * It is based on tpm_tis_spi driver by Peter Huewe and Christophe Ricard.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include "tpm.h"
+#include "tpm_tis_core.h"
+
+/*
+ * Cr50 timing constants:
+ * - can go to sleep not earlier than after CR50_SLEEP_DELAY_MSEC
+ * - needs up to CR50_WAKE_START_DELAY_MSEC to wake after sleep
+ * - requires at least CR50_ACCESS_DELAY_MSEC between transactions
+ */
+#define CR50_SLEEP_DELAY_MSEC  1000
+#define CR50_WAKE_START_DELAY_MSEC 60
+#define CR50_ACCESS_DELAY_MSEC 2
+
+#define MAX_SPI_FRAMESIZE  64
+
+#define TPM_CR50_FW_VER(l) (0x0F90 | ((l) << 12))
+#define TPM_CR50_MAX_FW_VER_LEN64
+
+struct cr50_spi_phy {
+   struct tpm_tis_data priv;
+   struct spi_device *spi_device;
+
+   struct mutex time_track_mutex;
+   unsigned long last_access_jiffies;
+   unsigned long wake_after_jiffies;
+
+   unsigned long access_delay_jiffies;
+   unsigned long sleep_delay_jiffies;
+   unsigned int wake_start_delay_msec;
+
+   u8 tx_buf[MAX_SPI_FRAMESIZE];
+   u8 rx_buf[MAX_SPI_FRAMESIZE];
+};
+
+static struct cr50_spi_phy *to_cr50_spi_phy(struct tpm_tis_data *data)
+{
+   return container_of(data, struct cr50_spi_phy, priv);
+}
+
+/*
+ * Cr50 needs to have at least some delay between consecutive
+ * transactions. Make sure we wait.
+ */
+static void cr50_ensure_access_delay(struct cr50_spi_phy *phy)
+{
+   /*
+* Note: There is a small chance, if Cr50 is not accessed in a few days,
+* that time_in_range will not provide the correct result after the wrap
+* around for jiffies. In this case, we'll have an unneeded short delay,
+* which is fine.
+*/
+   unsigned long allowed_access =
+   phy->last_access_jiffies + phy->access_delay_jiffies;
+   unsigned long time_now = jiffies;
+
+   if (time_in_range_open(time_now,
+  phy->last_access_jiffies, allowed_access))
+   mdelay(jiffies_to_msecs(allowed_access - time_now));
+}
+
+/*
+ * Cr50 might go to sleep if there is no SPI activity for some time and
+ * miss the first few bits/bytes on the bus. In 

[PATCH v3 2/2] tpm: add driver for cr50 on SPI

[Andrey Pronin]

Add TPM2.0 PTP FIFO compatible SPI interface for chips with Cr50
firmware. The firmware running on the currently supported H1
Secure Microcontroller requires a special driver to handle its
specifics:
 - need to ensure a certain delay between spi transactions, or else
   the chip may miss some part of the next transaction;
 - if there is no spi activity for some time, it may go to sleep,
   and needs to be waken up before sending further commands;
 - access to vendor-specific registers.

Signed-off-by: Andrey Pronin 
---
 drivers/char/tpm/Kconfig|   9 ++
 drivers/char/tpm/Makefile   |   1 +
 drivers/char/tpm/cr50_spi.c | 350 
 3 files changed, 360 insertions(+)
 create mode 100644 drivers/char/tpm/cr50_spi.c

diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 9faa0b1..3320acc 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -100,6 +100,15 @@ config TCG_ATMEL
  will be accessible from within Linux.  To compile this driver 
  as a module, choose M here; the module will be called tpm_atmel.
 
+config TCG_CR50_SPI
+   tristate "TCG PTP FIFO Interface over SPI - Chips with Cr50 Firmware"
+   depends on SPI
+   select TCG_TIS_CORE
+   ---help---
+ If you have a chip running Cr50 firmware on SPI bus, say Yes and it
+ will be accessible from within Linux. To compile this driver as a
+ module, choose M here; the module will be called cr50_spi.
+
 config TCG_INFINEON
tristate "Infineon Technologies TPM Interface"
depends on PNP
diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index a385fb8..b346306 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_TCG_TIS_I2C_INFINEON) += tpm_i2c_infineon.o
 obj-$(CONFIG_TCG_TIS_I2C_NUVOTON) += tpm_i2c_nuvoton.o
 obj-$(CONFIG_TCG_NSC) += tpm_nsc.o
 obj-$(CONFIG_TCG_ATMEL) += tpm_atmel.o
+obj-$(CONFIG_TCG_CR50_SPI) += cr50_spi.o
 obj-$(CONFIG_TCG_INFINEON) += tpm_infineon.o
 obj-$(CONFIG_TCG_IBMVTPM) += tpm_ibmvtpm.o
 obj-$(CONFIG_TCG_TIS_ST33ZP24) += st33zp24/
diff --git a/drivers/char/tpm/cr50_spi.c b/drivers/char/tpm/cr50_spi.c
new file mode 100644
index 000..57ba8b3
--- /dev/null
+++ b/drivers/char/tpm/cr50_spi.c
@@ -0,0 +1,350 @@
+/*
+ * Copyright (C) 2016 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2, as published by
+ * the Free Software Foundation.
+ *
+ * This device driver implements a TCG PTP FIFO interface over SPI for chips
+ * with Cr50 firmware.
+ * It is based on tpm_tis_spi driver by Peter Huewe and Christophe Ricard.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include "tpm.h"
+#include "tpm_tis_core.h"
+
+/*
+ * Cr50 timing constants:
+ * - can go to sleep not earlier than after CR50_SLEEP_DELAY_MSEC
+ * - needs up to CR50_WAKE_START_DELAY_MSEC to wake after sleep
+ * - requires at least CR50_ACCESS_DELAY_MSEC between transactions
+ */
+#define CR50_SLEEP_DELAY_MSEC  1000
+#define CR50_WAKE_START_DELAY_MSEC 60
+#define CR50_ACCESS_DELAY_MSEC 2
+
+#define MAX_SPI_FRAMESIZE  64
+
+#define TPM_CR50_FW_VER(l) (0x0F90 | ((l) << 12))
+#define TPM_CR50_MAX_FW_VER_LEN64
+
+struct cr50_spi_phy {
+   struct tpm_tis_data priv;
+   struct spi_device *spi_device;
+
+   struct mutex time_track_mutex;
+   unsigned long last_access_jiffies;
+   unsigned long wake_after_jiffies;
+
+   unsigned long access_delay_jiffies;
+   unsigned long sleep_delay_jiffies;
+   unsigned int wake_start_delay_msec;
+
+   u8 tx_buf[MAX_SPI_FRAMESIZE];
+   u8 rx_buf[MAX_SPI_FRAMESIZE];
+};
+
+static struct cr50_spi_phy *to_cr50_spi_phy(struct tpm_tis_data *data)
+{
+   return container_of(data, struct cr50_spi_phy, priv);
+}
+
+/*
+ * Cr50 needs to have at least some delay between consecutive
+ * transactions. Make sure we wait.
+ */
+static void cr50_ensure_access_delay(struct cr50_spi_phy *phy)
+{
+   /*
+* Note: There is a small chance, if Cr50 is not accessed in a few days,
+* that time_in_range will not provide the correct result after the wrap
+* around for jiffies. In this case, we'll have an unneeded short delay,
+* which is fine.
+*/
+   unsigned long allowed_access =
+   phy->last_access_jiffies + phy->access_delay_jiffies;
+   unsigned long time_now = jiffies;
+
+   if (time_in_range_open(time_now,
+  phy->last_access_jiffies, allowed_access))
+   mdelay(jiffies_to_msecs(allowed_access - time_now));
+}
+
+/*
+ * Cr50 might go to sleep if there is no SPI activity for some time and
+ * miss the first few bits/bytes on the bus. In such case, wake it up
+ * 

[PATCH v3 0/2] tpm: add driver for cr50 on SPI

[Andrey Pronin]

This patchset adds support for H1 Secure Microcontroller running
Cr50 firmware. It implements several functions, including TPM-like
functionality, and communicates over SPI using the FIFO protocol
described in the PTP Spec, section 6.
H1 is a proprietary chip that the Chrome OS team is investigating
for inclusion in future Chromebooks.

Depends on the following patchset:
 - tpm_tis_core: add optional max xfer size check

v2: Removed driver-specific sysfs attributes.
Compatible id changed to cr50 from cr50_spi.
Updated descriptions of the supported device/interface.

v3: Fixed potential race-condition with last_access_jiffies.
Started using tx_buf/rx_buf in cr50_spi_phy to avoid
potential problems with DMA.
Removed DT properties for fw timing parameters.
Fixed style.

Andrey Pronin (2):
  tpm: devicetree: document properties for cr50
  tpm: add driver for cr50 on SPI

 .../devicetree/bindings/security/tpm/cr50_spi.txt  |  21 ++
 drivers/char/tpm/Kconfig   |   9 +
 drivers/char/tpm/Makefile  |   1 +
 drivers/char/tpm/cr50_spi.c| 350 +
 4 files changed, 381 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/security/tpm/cr50_spi.txt
 create mode 100644 drivers/char/tpm/cr50_spi.c

-- 
2.6.6

[PATCH v3 0/2] tpm: add driver for cr50 on SPI

[Andrey Pronin]

This patchset adds support for H1 Secure Microcontroller running
Cr50 firmware. It implements several functions, including TPM-like
functionality, and communicates over SPI using the FIFO protocol
described in the PTP Spec, section 6.
H1 is a proprietary chip that the Chrome OS team is investigating
for inclusion in future Chromebooks.

Depends on the following patchset:
 - tpm_tis_core: add optional max xfer size check

v2: Removed driver-specific sysfs attributes.
Compatible id changed to cr50 from cr50_spi.
Updated descriptions of the supported device/interface.

v3: Fixed potential race-condition with last_access_jiffies.
Started using tx_buf/rx_buf in cr50_spi_phy to avoid
potential problems with DMA.
Removed DT properties for fw timing parameters.
Fixed style.

Andrey Pronin (2):
  tpm: devicetree: document properties for cr50
  tpm: add driver for cr50 on SPI

 .../devicetree/bindings/security/tpm/cr50_spi.txt  |  21 ++
 drivers/char/tpm/Kconfig   |   9 +
 drivers/char/tpm/Makefile  |   1 +
 drivers/char/tpm/cr50_spi.c| 350 +
 4 files changed, 381 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/security/tpm/cr50_spi.txt
 create mode 100644 drivers/char/tpm/cr50_spi.c

-- 
2.6.6

Re: [PATCH] Kbuild: Move -Wmaybe-uninitialized to W=1

[Borislav Petkov]

Hi Linus,

about 6e8d666e9253 ("Disable "maybe-uninitialized" warning globally"):

Good! Finally!

This thing was really getting on my nerves.

Btw, I tried at the time to move it to W=1 insted of completely
disabling it, see below. That got nowhere though.

On Mon, Jul 07, 2014 at 12:53:39PM +0200, Borislav Petkov wrote:
> Ok, here's a v2 which goes ontop of
> 
> http://lkml.kernel.org/r/1404175346-12330-1-git-send-email-beh...@converseincode.com
> 
> After this, all warnings stuff should be back to normal.
> 
> ---
> From: Borislav Petkov 
> Subject: [PATCH -v2] Kbuild: Move -Wmaybe-uninitialized to W=1
> 
> This warning is enabled by -Wall or -Wextra, says the gcc manpage. It
> also says that gcc cannot always know whether the warning is issued
> correctly:
> 
> "These warnings are made optional because GCC is not smart enough to see
> all the reasons why the code might be correct in spite of appearing to
> have an error."
> 
> And, as expected, it fires for perfectly valid use cases, thus making it
> not really useful. Let's move it to the W=1 bunch in case people want to
> enable it with the additional checks.
> 
> Signed-off-by: Borislav Petkov 
> ---
>  Makefile   | 5 -
>  scripts/Makefile   | 1 +
>  scripts/Makefile.extrawarn | 1 +
>  3 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index 4d75b4bceedd..b58c94261960 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -613,7 +613,7 @@ include $(srctree)/arch/$(SRCARCH)/Makefile
>  KBUILD_CFLAGS+= $(call cc-option,-fno-delete-null-pointer-checks,)
>  
>  ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
> -KBUILD_CFLAGS+= -Os $(call cc-disable-warning,maybe-uninitialized,)
> +KBUILD_CFLAGS+= -Os
>  else
>  KBUILD_CFLAGS+= -O2
>  endif
> @@ -742,6 +742,9 @@ KBUILD_CFLAGS   += $(call cc-option,-Werror=date-time)
>  # use the deterministic mode of AR if available
>  KBUILD_ARFLAGS := $(call ar-option,D)
>  
> +# disable -Wmaybe-uninitialized as too noisy, see Makefile.extrawarn instead
> +KBUILD_CFLAGS   += $(call cc-disable-warning, maybe-uninitialized)
> +
>  # check for 'asm goto'
>  ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)), y)
>   KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
> diff --git a/scripts/Makefile b/scripts/Makefile
> index 890df5c6adfb..a483d9988a2e 100644
> --- a/scripts/Makefile
> +++ b/scripts/Makefile
> @@ -19,6 +19,7 @@ hostprogs-$(CONFIG_BUILDTIME_EXTABLE_SORT) += sortextable
>  hostprogs-$(CONFIG_ASN1)  += asn1_compiler
>  
>  HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include
> +HOSTCFLAGS_sortextable.o += $(call cc-disable-warning, maybe-uninitialized)
>  HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
>  
>  always   := $(hostprogs-y) $(hostprogs-m)
> diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
> index e3501272cd93..9657d5778e06 100644
> --- a/scripts/Makefile.extrawarn
> +++ b/scripts/Makefile.extrawarn
> @@ -25,6 +25,7 @@ warning-1 += -Wold-style-definition
>  warning-1 += $(call cc-option, -Wmissing-include-dirs)
>  warning-1 += $(call cc-option, -Wunused-but-set-variable)
>  warning-1 += $(call cc-disable-warning, missing-field-initializers)
> +warning-1 += $(call cc-option, -Wmaybe-uninitialized)
>  
>  ifeq ($(COMPILER),clang)
>  warning-1 += $(call cc-disable-warning, initializer-overrides)
> -- 
> 2.0.0
> 
> -- 
> Regards/Gruss,
> Boris.
> 
> Sent from a fat crate under my desk. Formatting is fine.
> --
> 

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH] Kbuild: Move -Wmaybe-uninitialized to W=1

[Borislav Petkov]

Hi Linus,

about 6e8d666e9253 ("Disable "maybe-uninitialized" warning globally"):

Good! Finally!

This thing was really getting on my nerves.

Btw, I tried at the time to move it to W=1 insted of completely
disabling it, see below. That got nowhere though.

On Mon, Jul 07, 2014 at 12:53:39PM +0200, Borislav Petkov wrote:
> Ok, here's a v2 which goes ontop of
> 
> http://lkml.kernel.org/r/1404175346-12330-1-git-send-email-beh...@converseincode.com
> 
> After this, all warnings stuff should be back to normal.
> 
> ---
> From: Borislav Petkov 
> Subject: [PATCH -v2] Kbuild: Move -Wmaybe-uninitialized to W=1
> 
> This warning is enabled by -Wall or -Wextra, says the gcc manpage. It
> also says that gcc cannot always know whether the warning is issued
> correctly:
> 
> "These warnings are made optional because GCC is not smart enough to see
> all the reasons why the code might be correct in spite of appearing to
> have an error."
> 
> And, as expected, it fires for perfectly valid use cases, thus making it
> not really useful. Let's move it to the W=1 bunch in case people want to
> enable it with the additional checks.
> 
> Signed-off-by: Borislav Petkov 
> ---
>  Makefile   | 5 -
>  scripts/Makefile   | 1 +
>  scripts/Makefile.extrawarn | 1 +
>  3 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index 4d75b4bceedd..b58c94261960 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -613,7 +613,7 @@ include $(srctree)/arch/$(SRCARCH)/Makefile
>  KBUILD_CFLAGS+= $(call cc-option,-fno-delete-null-pointer-checks,)
>  
>  ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
> -KBUILD_CFLAGS+= -Os $(call cc-disable-warning,maybe-uninitialized,)
> +KBUILD_CFLAGS+= -Os
>  else
>  KBUILD_CFLAGS+= -O2
>  endif
> @@ -742,6 +742,9 @@ KBUILD_CFLAGS   += $(call cc-option,-Werror=date-time)
>  # use the deterministic mode of AR if available
>  KBUILD_ARFLAGS := $(call ar-option,D)
>  
> +# disable -Wmaybe-uninitialized as too noisy, see Makefile.extrawarn instead
> +KBUILD_CFLAGS   += $(call cc-disable-warning, maybe-uninitialized)
> +
>  # check for 'asm goto'
>  ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)), y)
>   KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
> diff --git a/scripts/Makefile b/scripts/Makefile
> index 890df5c6adfb..a483d9988a2e 100644
> --- a/scripts/Makefile
> +++ b/scripts/Makefile
> @@ -19,6 +19,7 @@ hostprogs-$(CONFIG_BUILDTIME_EXTABLE_SORT) += sortextable
>  hostprogs-$(CONFIG_ASN1)  += asn1_compiler
>  
>  HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include
> +HOSTCFLAGS_sortextable.o += $(call cc-disable-warning, maybe-uninitialized)
>  HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
>  
>  always   := $(hostprogs-y) $(hostprogs-m)
> diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
> index e3501272cd93..9657d5778e06 100644
> --- a/scripts/Makefile.extrawarn
> +++ b/scripts/Makefile.extrawarn
> @@ -25,6 +25,7 @@ warning-1 += -Wold-style-definition
>  warning-1 += $(call cc-option, -Wmissing-include-dirs)
>  warning-1 += $(call cc-option, -Wunused-but-set-variable)
>  warning-1 += $(call cc-disable-warning, missing-field-initializers)
> +warning-1 += $(call cc-option, -Wmaybe-uninitialized)
>  
>  ifeq ($(COMPILER),clang)
>  warning-1 += $(call cc-disable-warning, initializer-overrides)
> -- 
> 2.0.0
> 
> -- 
> Regards/Gruss,
> Boris.
> 
> Sent from a fat crate under my desk. Formatting is fine.
> --
> 

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

[PATCH v3] tpm: add sysfs attributes for tpm2

[Andrey Pronin]

Add sysfs attributes in TPM2.0 case for:
 - TPM_PT_PERMANENT flags
 - TPM_PT_STARTUP_CLEAR flags
 - lockout-related properties

v2: Dropped adding driver-specific attributes.
No legacy links for TPM2 attributes.
All attributes created in groups[0].
Added actual attributes for flags and lockout properties.

v3: Avoid creating a separate 'show' function for each attribute.

Signed-off-by: Andrey Pronin 
---
 drivers/char/tpm/tpm-chip.c  |   4 +-
 drivers/char/tpm/tpm-sysfs.c | 122 +--
 drivers/char/tpm/tpm.h   |  30 +++
 3 files changed, 150 insertions(+), 6 deletions(-)

diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index e595013..ede2ca0 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -281,8 +281,6 @@ static int tpm1_chip_register(struct tpm_chip *chip)
if (chip->flags & TPM_CHIP_FLAG_TPM2)
return 0;
 
-   tpm_sysfs_add_device(chip);
-
chip->bios_dir = tpm_bios_log_setup(dev_name(>dev));
 
return 0;
@@ -363,6 +361,8 @@ int tpm_chip_register(struct tpm_chip *chip)
return rc;
}
 
+   tpm_sysfs_add_device(chip);
+
rc = tpm1_chip_register(chip);
if (rc)
return rc;
diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
index b46cf70..62940ef 100644
--- a/drivers/char/tpm/tpm-sysfs.c
+++ b/drivers/char/tpm/tpm-sysfs.c
@@ -264,7 +264,7 @@ static ssize_t timeouts_show(struct device *dev, struct 
device_attribute *attr,
 }
 static DEVICE_ATTR_RO(timeouts);
 
-static struct attribute *tpm_dev_attrs[] = {
+static struct attribute *tpm1_dev_attrs[] = {
_attr_pubek.attr,
_attr_pcrs.attr,
_attr_enabled.attr,
@@ -278,8 +278,120 @@ static struct attribute *tpm_dev_attrs[] = {
NULL,
 };
 
-static const struct attribute_group tpm_dev_group = {
-   .attrs = tpm_dev_attrs,
+static const struct attribute_group tpm1_dev_group = {
+   .attrs = tpm1_dev_attrs,
+};
+
+struct tpm2_prop_flag_dev_attribute {
+   struct device_attribute attr;
+   u32 property_id;
+   u32 flag_mask;
+};
+
+struct tpm2_prop_u32_dev_attribute {
+   struct device_attribute attr;
+   u32 property_id;
+};
+
+static ssize_t tpm2_prop_flag_show(struct device *dev,
+  struct device_attribute *attr,
+  char *buf)
+{
+   struct tpm2_prop_flag_dev_attribute *pa =
+   container_of(attr, struct tpm2_prop_flag_dev_attribute, attr);
+   u32 flags;
+   ssize_t rc;
+
+   rc = tpm2_get_tpm_pt(to_tpm_chip(dev), pa->property_id, ,
+"reading property");
+   if (rc)
+   return 0;
+
+   return sprintf(buf, "%d\n", !!(flags & pa->flag_mask));
+}
+
+static ssize_t tpm2_prop_u32_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   struct tpm2_prop_u32_dev_attribute *pa =
+   container_of(attr, struct tpm2_prop_u32_dev_attribute, attr);
+   u32 value;
+   ssize_t rc;
+
+   rc = tpm2_get_tpm_pt(to_tpm_chip(dev), pa->property_id, ,
+"reading property");
+   if (rc)
+   return 0;
+
+   return sprintf(buf, "%u\n", value);
+}
+
+#define TPM2_PROP_FLAG_ATTR(_name, _property_id, _flag_mask)   \
+   struct tpm2_prop_flag_dev_attribute attr_tpm2_prop_##_name = { \
+   __ATTR(_name, S_IRUGO, tpm2_prop_flag_show, NULL), \
+   _property_id, _flag_mask   \
+   }
+
+#define TPM2_PROP_U32_ATTR(_name, _property_id)\
+   struct tpm2_prop_u32_dev_attribute attr_tpm2_prop_##_name = {  \
+   __ATTR(_name, S_IRUGO, tpm2_prop_u32_show, NULL),  \
+   _property_id   \
+   }
+
+TPM2_PROP_FLAG_ATTR(owner_auth_set,
+   TPM2_PT_PERMANENT, TPM2_ATTR_OWNER_AUTH_SET);
+TPM2_PROP_FLAG_ATTR(endorsement_auth_set,
+   TPM2_PT_PERMANENT, TPM2_ATTR_ENDORSEMENT_AUTH_SET);
+TPM2_PROP_FLAG_ATTR(lockout_auth_set,
+   TPM2_PT_PERMANENT, TPM2_ATTR_LOCKOUT_AUTH_SET);
+TPM2_PROP_FLAG_ATTR(disable_clear,
+   TPM2_PT_PERMANENT, TPM2_ATTR_DISABLE_CLEAR);
+TPM2_PROP_FLAG_ATTR(in_lockout,
+   TPM2_PT_PERMANENT, TPM2_ATTR_IN_LOCKOUT);
+TPM2_PROP_FLAG_ATTR(tpm_generated_eps,
+   TPM2_PT_PERMANENT, TPM2_ATTR_TPM_GENERATED_EPS);
+
+TPM2_PROP_FLAG_ATTR(ph_enable,
+   TPM2_PT_STARTUP_CLEAR, TPM2_ATTR_PH_ENABLE);
+TPM2_PROP_FLAG_ATTR(sh_enable,
+   TPM2_PT_STARTUP_CLEAR, TPM2_ATTR_SH_ENABLE);
+TPM2_PROP_FLAG_ATTR(eh_enable,
+   TPM2_PT_STARTUP_CLEAR, TPM2_ATTR_EH_ENABLE);

[PATCH v3] tpm: add sysfs attributes for tpm2

[Andrey Pronin]

Add sysfs attributes in TPM2.0 case for:
 - TPM_PT_PERMANENT flags
 - TPM_PT_STARTUP_CLEAR flags
 - lockout-related properties

v2: Dropped adding driver-specific attributes.
No legacy links for TPM2 attributes.
All attributes created in groups[0].
Added actual attributes for flags and lockout properties.

v3: Avoid creating a separate 'show' function for each attribute.

Signed-off-by: Andrey Pronin 
---
 drivers/char/tpm/tpm-chip.c  |   4 +-
 drivers/char/tpm/tpm-sysfs.c | 122 +--
 drivers/char/tpm/tpm.h   |  30 +++
 3 files changed, 150 insertions(+), 6 deletions(-)

diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index e595013..ede2ca0 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -281,8 +281,6 @@ static int tpm1_chip_register(struct tpm_chip *chip)
if (chip->flags & TPM_CHIP_FLAG_TPM2)
return 0;
 
-   tpm_sysfs_add_device(chip);
-
chip->bios_dir = tpm_bios_log_setup(dev_name(>dev));
 
return 0;
@@ -363,6 +361,8 @@ int tpm_chip_register(struct tpm_chip *chip)
return rc;
}
 
+   tpm_sysfs_add_device(chip);
+
rc = tpm1_chip_register(chip);
if (rc)
return rc;
diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
index b46cf70..62940ef 100644
--- a/drivers/char/tpm/tpm-sysfs.c
+++ b/drivers/char/tpm/tpm-sysfs.c
@@ -264,7 +264,7 @@ static ssize_t timeouts_show(struct device *dev, struct 
device_attribute *attr,
 }
 static DEVICE_ATTR_RO(timeouts);
 
-static struct attribute *tpm_dev_attrs[] = {
+static struct attribute *tpm1_dev_attrs[] = {
_attr_pubek.attr,
_attr_pcrs.attr,
_attr_enabled.attr,
@@ -278,8 +278,120 @@ static struct attribute *tpm_dev_attrs[] = {
NULL,
 };
 
-static const struct attribute_group tpm_dev_group = {
-   .attrs = tpm_dev_attrs,
+static const struct attribute_group tpm1_dev_group = {
+   .attrs = tpm1_dev_attrs,
+};
+
+struct tpm2_prop_flag_dev_attribute {
+   struct device_attribute attr;
+   u32 property_id;
+   u32 flag_mask;
+};
+
+struct tpm2_prop_u32_dev_attribute {
+   struct device_attribute attr;
+   u32 property_id;
+};
+
+static ssize_t tpm2_prop_flag_show(struct device *dev,
+  struct device_attribute *attr,
+  char *buf)
+{
+   struct tpm2_prop_flag_dev_attribute *pa =
+   container_of(attr, struct tpm2_prop_flag_dev_attribute, attr);
+   u32 flags;
+   ssize_t rc;
+
+   rc = tpm2_get_tpm_pt(to_tpm_chip(dev), pa->property_id, ,
+"reading property");
+   if (rc)
+   return 0;
+
+   return sprintf(buf, "%d\n", !!(flags & pa->flag_mask));
+}
+
+static ssize_t tpm2_prop_u32_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   struct tpm2_prop_u32_dev_attribute *pa =
+   container_of(attr, struct tpm2_prop_u32_dev_attribute, attr);
+   u32 value;
+   ssize_t rc;
+
+   rc = tpm2_get_tpm_pt(to_tpm_chip(dev), pa->property_id, ,
+"reading property");
+   if (rc)
+   return 0;
+
+   return sprintf(buf, "%u\n", value);
+}
+
+#define TPM2_PROP_FLAG_ATTR(_name, _property_id, _flag_mask)   \
+   struct tpm2_prop_flag_dev_attribute attr_tpm2_prop_##_name = { \
+   __ATTR(_name, S_IRUGO, tpm2_prop_flag_show, NULL), \
+   _property_id, _flag_mask   \
+   }
+
+#define TPM2_PROP_U32_ATTR(_name, _property_id)\
+   struct tpm2_prop_u32_dev_attribute attr_tpm2_prop_##_name = {  \
+   __ATTR(_name, S_IRUGO, tpm2_prop_u32_show, NULL),  \
+   _property_id   \
+   }
+
+TPM2_PROP_FLAG_ATTR(owner_auth_set,
+   TPM2_PT_PERMANENT, TPM2_ATTR_OWNER_AUTH_SET);
+TPM2_PROP_FLAG_ATTR(endorsement_auth_set,
+   TPM2_PT_PERMANENT, TPM2_ATTR_ENDORSEMENT_AUTH_SET);
+TPM2_PROP_FLAG_ATTR(lockout_auth_set,
+   TPM2_PT_PERMANENT, TPM2_ATTR_LOCKOUT_AUTH_SET);
+TPM2_PROP_FLAG_ATTR(disable_clear,
+   TPM2_PT_PERMANENT, TPM2_ATTR_DISABLE_CLEAR);
+TPM2_PROP_FLAG_ATTR(in_lockout,
+   TPM2_PT_PERMANENT, TPM2_ATTR_IN_LOCKOUT);
+TPM2_PROP_FLAG_ATTR(tpm_generated_eps,
+   TPM2_PT_PERMANENT, TPM2_ATTR_TPM_GENERATED_EPS);
+
+TPM2_PROP_FLAG_ATTR(ph_enable,
+   TPM2_PT_STARTUP_CLEAR, TPM2_ATTR_PH_ENABLE);
+TPM2_PROP_FLAG_ATTR(sh_enable,
+   TPM2_PT_STARTUP_CLEAR, TPM2_ATTR_SH_ENABLE);
+TPM2_PROP_FLAG_ATTR(eh_enable,
+   TPM2_PT_STARTUP_CLEAR, TPM2_ATTR_EH_ENABLE);
+TPM2_PROP_FLAG_ATTR(ph_enable_nv,
+   

[patch-rt] scsi/fcoe: Fix get_cpu()/put_cpu_light() imbalance in fcoe_recv_frame()

[Mike Galbraith]

During master->rt merge, I stumbled across the buglet below.

Fix get_cpu()/put_cpu_light() imbalance.

Signed-off-by: Mike Gabraith 
---
 drivers/scsi/fcoe/fcoe.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
@@ -1814,7 +1814,7 @@ static void fcoe_recv_frame(struct sk_bu
 */
hp = (struct fcoe_hdr *) skb_network_header(skb);
 
-   stats = per_cpu_ptr(lport->stats, get_cpu());
+   stats = per_cpu_ptr(lport->stats, get_cpu_light());
if (unlikely(FC_FCOE_DECAPS_VER(hp) != FC_FCOE_VER)) {
if (stats->ErrorFrames < 5)
printk(KERN_WARNING "fcoe: FCoE version "

[patch-rt] scsi/fcoe: Fix get_cpu()/put_cpu_light() imbalance in fcoe_recv_frame()

[Mike Galbraith]

During master->rt merge, I stumbled across the buglet below.

Fix get_cpu()/put_cpu_light() imbalance.

Signed-off-by: Mike Gabraith 
---
 drivers/scsi/fcoe/fcoe.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
@@ -1814,7 +1814,7 @@ static void fcoe_recv_frame(struct sk_bu
 */
hp = (struct fcoe_hdr *) skb_network_header(skb);
 
-   stats = per_cpu_ptr(lport->stats, get_cpu());
+   stats = per_cpu_ptr(lport->stats, get_cpu_light());
if (unlikely(FC_FCOE_DECAPS_VER(hp) != FC_FCOE_VER)) {
if (stats->ErrorFrames < 5)
printk(KERN_WARNING "fcoe: FCoE version "

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

[Joe Perches]

On Wed, 2016-07-27 at 20:33 -0700, Linus Torvalds wrote:
> On Wed, Jul 27, 2016 at 8:31 PM, Linus Torvalds 
>  wrote:
> > I'd actually prefer to make "--git" the default, if you are inside a
> > git repository. Because obviously the *actual* default is too hard to
> > understand ;)

Well, you are in the minority there.

Most people seem not to want to be cc'd on stuff they may have
sent an odd patch on but don't actually maintain.

You could create a .get_maintainer.conf file and add --git
to it if you want that.

> I'd also like to make the "-f" optional.
> 
> I constantly forget it, and curse it. It should be trivial to see "the
> argument is a file that is tracked in git, so it clearly isn't the
> name of a patch".

You could send a patch ;)

I'll look at it in any case.

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

[Joe Perches]

On Wed, 2016-07-27 at 20:33 -0700, Linus Torvalds wrote:
> On Wed, Jul 27, 2016 at 8:31 PM, Linus Torvalds 
>  wrote:
> > I'd actually prefer to make "--git" the default, if you are inside a
> > git repository. Because obviously the *actual* default is too hard to
> > understand ;)

Well, you are in the minority there.

Most people seem not to want to be cc'd on stuff they may have
sent an odd patch on but don't actually maintain.

You could create a .get_maintainer.conf file and add --git
to it if you want that.

> I'd also like to make the "-f" optional.
> 
> I constantly forget it, and curse it. It should be trivial to see "the
> argument is a file that is tracked in git, so it clearly isn't the
> name of a patch".

You could send a patch ;)

I'll look at it in any case.

Re: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe

[Steven Rostedt]

On Wed, 27 Jul 2016 20:21:50 -0700
Linus Torvalds  wrote:

> On Wed, Jul 27, 2016 at 6:58 PM, Steven Rostedt  wrote:
> > On Wed, 27 Jul 2016 16:00:54 -0700
> > Linus Torvalds  wrote:  
> >>
> >> I can just add a
> >>
> >>   KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)  
> >
> > I like this solution.  
> 
> Ok. Pushed out. As long as people are aware of this, and are hopefully
> at least looking for potential alternatives, it's fine.

I just looked at your patch. Would this work if you moved that
KBUILD_CFLAGS to the tracing directory? Something like the below (never
compiled or tested).

This way we still get warnings from other users.

Signed-off-by: Steven Rostedt 
---

diff --git a/Makefile b/Makefile
index 393b615..d384848 100644
--- a/Makefile
+++ b/Makefile
@@ -620,7 +620,6 @@ include arch/$(SRCARCH)/Makefile
 
 KBUILD_CFLAGS  += $(call cc-option,-fno-delete-null-pointer-checks,)
 KBUILD_CFLAGS  += $(call cc-disable-warning,maybe-uninitialized,)
-KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)
 
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
 KBUILD_CFLAGS  += -Os
diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
index 979e7bf..48079dd 100644
--- a/kernel/trace/Makefile
+++ b/kernel/trace/Makefile
@@ -1,4 +1,7 @@
 
+# We are fully aware of the dangers of __builtin_return_address() > 0
+KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
+
 # Do not instrument the tracer itself:
 
 ifdef CONFIG_FUNCTION_TRACER

Re: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe

[Steven Rostedt]

On Wed, 27 Jul 2016 20:21:50 -0700
Linus Torvalds  wrote:

> On Wed, Jul 27, 2016 at 6:58 PM, Steven Rostedt  wrote:
> > On Wed, 27 Jul 2016 16:00:54 -0700
> > Linus Torvalds  wrote:  
> >>
> >> I can just add a
> >>
> >>   KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)  
> >
> > I like this solution.  
> 
> Ok. Pushed out. As long as people are aware of this, and are hopefully
> at least looking for potential alternatives, it's fine.

I just looked at your patch. Would this work if you moved that
KBUILD_CFLAGS to the tracing directory? Something like the below (never
compiled or tested).

This way we still get warnings from other users.

Signed-off-by: Steven Rostedt 
---

diff --git a/Makefile b/Makefile
index 393b615..d384848 100644
--- a/Makefile
+++ b/Makefile
@@ -620,7 +620,6 @@ include arch/$(SRCARCH)/Makefile
 
 KBUILD_CFLAGS  += $(call cc-option,-fno-delete-null-pointer-checks,)
 KBUILD_CFLAGS  += $(call cc-disable-warning,maybe-uninitialized,)
-KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)
 
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
 KBUILD_CFLAGS  += -Os
diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
index 979e7bf..48079dd 100644
--- a/kernel/trace/Makefile
+++ b/kernel/trace/Makefile
@@ -1,4 +1,7 @@
 
+# We are fully aware of the dangers of __builtin_return_address() > 0
+KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
+
 # Do not instrument the tracer itself:
 
 ifdef CONFIG_FUNCTION_TRACER

[PATCH v3 1/2] tpm_tis_core: add optional max xfer size check

[Andrey Pronin]

If tpm reports a bigger burstcnt than allowed by the physical protocol,
set burstcnt to the max allowed value.

In practice, seen in case of xfer issues (e.g. in spi interface case,
lost header causing flow control issues and wrong values returned on read
from TPM_STS). Without catching, causes the physical layer to reject xfer.

Signed-off-by: Andrey Pronin 
---
 drivers/char/tpm/tpm_tis_core.c | 9 -
 drivers/char/tpm/tpm_tis_core.h | 1 +
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index f22caf8..7c4fa0c 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -168,8 +168,15 @@ static int get_burstcount(struct tpm_chip *chip)
return rc;
 
burstcnt = (value >> 8) & 0x;
-   if (burstcnt)
+   if (burstcnt) {
+   if (priv->phy_ops->max_xfer_size &&
+   (burstcnt > priv->phy_ops->max_xfer_size)) {
+   dev_warn(>dev,
+"Bad burstcnt read: %d\n", burstcnt);
+   burstcnt = priv->phy_ops->max_xfer_size;
+   }
return burstcnt;
+   }
msleep(TPM_TIMEOUT);
} while (time_before(jiffies, stop));
return -EBUSY;
diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
index 9191aab..58e8b14 100644
--- a/drivers/char/tpm/tpm_tis_core.h
+++ b/drivers/char/tpm/tpm_tis_core.h
@@ -102,6 +102,7 @@ struct tpm_tis_phy_ops {
int (*read16)(struct tpm_tis_data *data, u32 addr, u16 *result);
int (*read32)(struct tpm_tis_data *data, u32 addr, u32 *result);
int (*write32)(struct tpm_tis_data *data, u32 addr, u32 src);
+   u16 max_xfer_size;
 };
 
 static inline int tpm_tis_read_bytes(struct tpm_tis_data *data, u32 addr,
-- 
2.6.6

[PATCH v3 1/2] tpm_tis_core: add optional max xfer size check

[Andrey Pronin]

If tpm reports a bigger burstcnt than allowed by the physical protocol,
set burstcnt to the max allowed value.

In practice, seen in case of xfer issues (e.g. in spi interface case,
lost header causing flow control issues and wrong values returned on read
from TPM_STS). Without catching, causes the physical layer to reject xfer.

Signed-off-by: Andrey Pronin 
---
 drivers/char/tpm/tpm_tis_core.c | 9 -
 drivers/char/tpm/tpm_tis_core.h | 1 +
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index f22caf8..7c4fa0c 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -168,8 +168,15 @@ static int get_burstcount(struct tpm_chip *chip)
return rc;
 
burstcnt = (value >> 8) & 0x;
-   if (burstcnt)
+   if (burstcnt) {
+   if (priv->phy_ops->max_xfer_size &&
+   (burstcnt > priv->phy_ops->max_xfer_size)) {
+   dev_warn(>dev,
+"Bad burstcnt read: %d\n", burstcnt);
+   burstcnt = priv->phy_ops->max_xfer_size;
+   }
return burstcnt;
+   }
msleep(TPM_TIMEOUT);
} while (time_before(jiffies, stop));
return -EBUSY;
diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
index 9191aab..58e8b14 100644
--- a/drivers/char/tpm/tpm_tis_core.h
+++ b/drivers/char/tpm/tpm_tis_core.h
@@ -102,6 +102,7 @@ struct tpm_tis_phy_ops {
int (*read16)(struct tpm_tis_data *data, u32 addr, u16 *result);
int (*read32)(struct tpm_tis_data *data, u32 addr, u32 *result);
int (*write32)(struct tpm_tis_data *data, u32 addr, u32 src);
+   u16 max_xfer_size;
 };
 
 static inline int tpm_tis_read_bytes(struct tpm_tis_data *data, u32 addr,
-- 
2.6.6

[PATCH v3 2/2] tpm_tis_spi: add max xfer size

[Andrey Pronin]

Reject burstcounts larger than 64 bytes reported by tpm.
SPI Hardware Protocol defined in section 6.4 of TCG PTP
Spec supports up to 64 bytes of data in a transaction.

Signed-off-by: Andrey Pronin 
---
 drivers/char/tpm/tpm_tis_spi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/char/tpm/tpm_tis_spi.c b/drivers/char/tpm/tpm_tis_spi.c
index dbaad9c..b103373 100644
--- a/drivers/char/tpm/tpm_tis_spi.c
+++ b/drivers/char/tpm/tpm_tis_spi.c
@@ -206,6 +206,7 @@ static const struct tpm_tis_phy_ops tpm_spi_phy_ops = {
.read16 = tpm_tis_spi_read16,
.read32 = tpm_tis_spi_read32,
.write32 = tpm_tis_spi_write32,
+   .max_xfer_size = MAX_SPI_FRAMESIZE,
 };
 
 static int tpm_tis_spi_probe(struct spi_device *dev)
-- 
2.6.6

[PATCH v3 2/2] tpm_tis_spi: add max xfer size

[Andrey Pronin]

Reject burstcounts larger than 64 bytes reported by tpm.
SPI Hardware Protocol defined in section 6.4 of TCG PTP
Spec supports up to 64 bytes of data in a transaction.

Signed-off-by: Andrey Pronin 
---
 drivers/char/tpm/tpm_tis_spi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/char/tpm/tpm_tis_spi.c b/drivers/char/tpm/tpm_tis_spi.c
index dbaad9c..b103373 100644
--- a/drivers/char/tpm/tpm_tis_spi.c
+++ b/drivers/char/tpm/tpm_tis_spi.c
@@ -206,6 +206,7 @@ static const struct tpm_tis_phy_ops tpm_spi_phy_ops = {
.read16 = tpm_tis_spi_read16,
.read32 = tpm_tis_spi_read32,
.write32 = tpm_tis_spi_write32,
+   .max_xfer_size = MAX_SPI_FRAMESIZE,
 };
 
 static int tpm_tis_spi_probe(struct spi_device *dev)
-- 
2.6.6

[PATCH v3 0/2] tpm: add optional max xfer size check

[Andrey Pronin]

This patchset introduces an optional maximum transfer size that can
be specified by a tpm driver. Setting the max_xfer_size helps to catch
the cases when burstcnt is incorrectly reported by the device (e.g. >64
for spi - happened in practice) and gracefully handle such situations.

v2: removed unnecessary accessors in tpm_tis_core.h, fixed style

v3: simplified logic: simply cap the burstcnt at max_xfer_size, don't
attempt to re-request from tpm.

Andrey Pronin (2):
  tpm_tis_core: add optional max xfer size check
  tpm_tis_spi: add max xfer size

 drivers/char/tpm/tpm_tis_core.c | 9 -
 drivers/char/tpm/tpm_tis_core.h | 1 +
 drivers/char/tpm/tpm_tis_spi.c  | 1 +
 3 files changed, 10 insertions(+), 1 deletion(-)

-- 
2.6.6

[PATCH v3 0/2] tpm: add optional max xfer size check

[Andrey Pronin]

This patchset introduces an optional maximum transfer size that can
be specified by a tpm driver. Setting the max_xfer_size helps to catch
the cases when burstcnt is incorrectly reported by the device (e.g. >64
for spi - happened in practice) and gracefully handle such situations.

v2: removed unnecessary accessors in tpm_tis_core.h, fixed style

v3: simplified logic: simply cap the burstcnt at max_xfer_size, don't
attempt to re-request from tpm.

Andrey Pronin (2):
  tpm_tis_core: add optional max xfer size check
  tpm_tis_spi: add max xfer size

 drivers/char/tpm/tpm_tis_core.c | 9 -
 drivers/char/tpm/tpm_tis_core.h | 1 +
 drivers/char/tpm/tpm_tis_spi.c  | 1 +
 3 files changed, 10 insertions(+), 1 deletion(-)

-- 
2.6.6

RE: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

[Li, Liang Z]

> > +/*
> > + * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page bitmap
> > + * to prevent a very large page bitmap, there are two reasons for this:
> > + * 1) to save memory.
> > + * 2) allocate a large bitmap may fail.
> > + *
> > + * The actual limit of pfn is determined by:
> > + * pfn_limit = min(max_pfn, VIRTIO_BALLOON_PFNS_LIMIT);
> > + *
> > + * If system has more pages than VIRTIO_BALLOON_PFNS_LIMIT, we will
> > +scan
> > + * the page list and send the PFNs with several times. To reduce the
> > + * overhead of scanning the page list. VIRTIO_BALLOON_PFNS_LIMIT
> > +should
> > + * be set with a value which can cover most cases.
> > + */
> > +#define VIRTIO_BALLOON_PFNS_LIMIT ((32 * (1ULL << 30)) >>
> PAGE_SHIFT)
> > +/* 32GB */
> > +
> >  static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
> > module_param(oom_pages, int, S_IRUSR | S_IWUSR);
> > MODULE_PARM_DESC(oom_pages, "pages to free on OOM");
> >
> > +extern unsigned long get_max_pfn(void);
> > +
> 
> Please just include the correct header. No need for this hackery.
> 

Will change. Thanks!

Liang

RE: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

[Li, Liang Z]

> > +/*
> > + * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page bitmap
> > + * to prevent a very large page bitmap, there are two reasons for this:
> > + * 1) to save memory.
> > + * 2) allocate a large bitmap may fail.
> > + *
> > + * The actual limit of pfn is determined by:
> > + * pfn_limit = min(max_pfn, VIRTIO_BALLOON_PFNS_LIMIT);
> > + *
> > + * If system has more pages than VIRTIO_BALLOON_PFNS_LIMIT, we will
> > +scan
> > + * the page list and send the PFNs with several times. To reduce the
> > + * overhead of scanning the page list. VIRTIO_BALLOON_PFNS_LIMIT
> > +should
> > + * be set with a value which can cover most cases.
> > + */
> > +#define VIRTIO_BALLOON_PFNS_LIMIT ((32 * (1ULL << 30)) >>
> PAGE_SHIFT)
> > +/* 32GB */
> > +
> >  static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
> > module_param(oom_pages, int, S_IRUSR | S_IWUSR);
> > MODULE_PARM_DESC(oom_pages, "pages to free on OOM");
> >
> > +extern unsigned long get_max_pfn(void);
> > +
> 
> Please just include the correct header. No need for this hackery.
> 

Will change. Thanks!

Liang

[REGRESSION] wlcore wlcore_op_get_expected_throughput null ptr dereference

[John Stultz]

So after rebasing my HiKey tree ontop of Linus' HEAD today, I started
having trouble with the wlcore wifi.

The first issue was that the firmware I was using was deemed too old,
but after updating to .69, I then started hitting null pointer crashes
when wifi was initialized.


[7.326224] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
[7.336328] wlcore: loaded
...
[   26.254559] wlcore: PHY firmware version: Rev 8.2.0.0.236
[   26.308764] wlcore: firmware booted (Rev 8.9.0.0.69)
...
[   60.297307] wlan0: send auth to 04:a1:51:da:5b:a7 (try 1/3)
[   60.316271] wlan0: authenticated
[   60.320853] wl18xx_driver wl18xx.2.auto wlan0: disabling HT as
WMM/QoS is not supported by the AP
[   60.329858] wl18xx_driver wl18xx.2.auto wlan0: disabling VHT as
WMM/QoS is not supported by the AP
[   60.342624] wlan0: associate with 04:a1:51:da:5b:a7 (try 1/3)
[   60.352475] wlan0: RX AssocResp from 04:a1:51:da:5b:a7
(capab=0x1411 status=0 aid=1)
[   60.417880] wlan0: associated
[   60.444554] wlcore: Association completed.
[   60.507987] Unable to handle kernel NULL pointer dereference at
virtual address 0aea
[   60.516180] pgd = ffc07365b000
[   60.519645] [0aea] *pgd=, *pud=
[   60.526027] Internal error: Oops: 9605 [#1] PREEMPT SMP
[   60.531616] CPU: 0 PID: 2306 Comm: wpa_supplicant Not tainted
4.7.0-05982-g3bd0464 #550
[   60.539623] Hardware name: HiKey Development Board (DT)
[   60.544853] task: ffc0788fa580 ti: ffc058be4000 task.ti:
ffc058be4000
[   60.552357] PC is at wlcore_op_get_expected_throughput+0xc/0x1c
[   60.558287] LR is at sta_set_sinfo+0x608/0x7d0
[   60.562735] pc : [] lr : []
pstate: 8145
[   60.570132] sp : ffc058be7640
[   60.573448] x29: ffc058be7640 x28: ffc058be4000
[   60.578776] x27: ffc0481211f8 x26: 0008
[   60.584103] x25: 161d x24: ffc0481217f8
[   60.589430] x23:  x22: ffc0792d86e0
[   60.594756] x21: ffc0784e6880 x20: ffc048121000
[   60.600083] x19: ffc058be7720 x18: 
[   60.605409] x17:  x16: ff80081bdcd8
[   60.610735] x15: 004fbc5c x14: 0241
[   60.616061] x13: aaab x12: ff8008f79000
[   60.621388] x11: ffc058be73c8 x10: 0860
[   60.626714] x9 : ffc058be4000 x8 : 4000
[   60.632039] x7 : 00210d00 x6 : ffc048121448
[   60.637366] x5 : ffc058be7a70 x4 : 001e
[   60.642692] x3 : 000a x2 : 
[   60.648017] x1 :  x0 : 
[   60.653342]
[   60.654836] Process wpa_supplicant (pid: 2306, stack limit =
0xffc058be4020)
[   60.662236] Stack: (0xffc058be7640 to 0xffc058be8000)
...
[   61.278789] Call trace:
[   61.281232] Exception stack(0xffc058be7470 to 0xffc058be75a0)
[   61.287669] 7460:
ffc058be7720 0080
[   61.295497] 7480: ffc058be7640 ff80085dd404
ff80081081f8 ffc058be74f0
[   61.303325] 74a0: ffc058be74e0 ff80081081f8
ffc058be74d0 ff800899cd68
[   61.311152] 74c0: ffc058be74d0 ff800810758c
ffc058be74e0 ff800899cf10
[   61.318980] 74e0: ffc058be74f0 ff800810823c
ffc058be7570 ff80081083c0
[   61.326806] 7500: 0140 ffc07856d400
 
[   61.334633] 7520:  000a
001e ffc058be7a70
[   61.342461] 7540: ffc048121448 00210d00
4000 ffc058be4000
[   61.350289] 7560: 0860 ffc058be73c8
ff8008f79000 aaab
[   61.358117] 7580: 0241 004fbc5c
ff80081bdcd8 
[   61.365946] [] wlcore_op_get_expected_throughput+0xc/0x1c
[   61.372908] [] ieee80211_get_station+0x4c/0x6c
[   61.378915] [] nl80211_get_station+0x68/0x144
[   61.384835] [] genl_family_rcv_msg+0x1ec/0x340
[   61.390838] [] genl_rcv_msg+0x90/0xd8
[   61.396059] [] netlink_rcv_skb+0xec/0x100
[   61.401627] [] genl_rcv+0x34/0x48
[   61.406501] [] netlink_unicast+0x164/0x258
[   61.412156] [] netlink_sendmsg+0x310/0x374
[   61.417812] [] sock_sendmsg+0x44/0x50
[   61.423033] [] ___sys_sendmsg+0x24c/0x25c
[   61.428601] [] __sys_sendmsg+0x44/0x88
[   61.433907] [] SyS_sendmsg+0x10/0x20
[   61.439043] [] el0_svc_naked+0x24/0x28
[   61.444352] Code: d65f03c0 39438001 f9407800 8b011c00 (396ba801)
[   61.450537] ---[ end trace d464b2870b6d1378 ]---


Digging in it seems like commit 5f6d4ca3c196814bef0cbbb195acd9ecc178588b
("wlcore: Add support for get_expected_throughput opcode") is to
blame, and reverting that seems to resolve the issue.

thanks
-john

[REGRESSION] wlcore wlcore_op_get_expected_throughput null ptr dereference

[John Stultz]

So after rebasing my HiKey tree ontop of Linus' HEAD today, I started
having trouble with the wlcore wifi.

The first issue was that the firmware I was using was deemed too old,
but after updating to .69, I then started hitting null pointer crashes
when wifi was initialized.


[7.326224] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
[7.336328] wlcore: loaded
...
[   26.254559] wlcore: PHY firmware version: Rev 8.2.0.0.236
[   26.308764] wlcore: firmware booted (Rev 8.9.0.0.69)
...
[   60.297307] wlan0: send auth to 04:a1:51:da:5b:a7 (try 1/3)
[   60.316271] wlan0: authenticated
[   60.320853] wl18xx_driver wl18xx.2.auto wlan0: disabling HT as
WMM/QoS is not supported by the AP
[   60.329858] wl18xx_driver wl18xx.2.auto wlan0: disabling VHT as
WMM/QoS is not supported by the AP
[   60.342624] wlan0: associate with 04:a1:51:da:5b:a7 (try 1/3)
[   60.352475] wlan0: RX AssocResp from 04:a1:51:da:5b:a7
(capab=0x1411 status=0 aid=1)
[   60.417880] wlan0: associated
[   60.444554] wlcore: Association completed.
[   60.507987] Unable to handle kernel NULL pointer dereference at
virtual address 0aea
[   60.516180] pgd = ffc07365b000
[   60.519645] [0aea] *pgd=, *pud=
[   60.526027] Internal error: Oops: 9605 [#1] PREEMPT SMP
[   60.531616] CPU: 0 PID: 2306 Comm: wpa_supplicant Not tainted
4.7.0-05982-g3bd0464 #550
[   60.539623] Hardware name: HiKey Development Board (DT)
[   60.544853] task: ffc0788fa580 ti: ffc058be4000 task.ti:
ffc058be4000
[   60.552357] PC is at wlcore_op_get_expected_throughput+0xc/0x1c
[   60.558287] LR is at sta_set_sinfo+0x608/0x7d0
[   60.562735] pc : [] lr : []
pstate: 8145
[   60.570132] sp : ffc058be7640
[   60.573448] x29: ffc058be7640 x28: ffc058be4000
[   60.578776] x27: ffc0481211f8 x26: 0008
[   60.584103] x25: 161d x24: ffc0481217f8
[   60.589430] x23:  x22: ffc0792d86e0
[   60.594756] x21: ffc0784e6880 x20: ffc048121000
[   60.600083] x19: ffc058be7720 x18: 
[   60.605409] x17:  x16: ff80081bdcd8
[   60.610735] x15: 004fbc5c x14: 0241
[   60.616061] x13: aaab x12: ff8008f79000
[   60.621388] x11: ffc058be73c8 x10: 0860
[   60.626714] x9 : ffc058be4000 x8 : 4000
[   60.632039] x7 : 00210d00 x6 : ffc048121448
[   60.637366] x5 : ffc058be7a70 x4 : 001e
[   60.642692] x3 : 000a x2 : 
[   60.648017] x1 :  x0 : 
[   60.653342]
[   60.654836] Process wpa_supplicant (pid: 2306, stack limit =
0xffc058be4020)
[   60.662236] Stack: (0xffc058be7640 to 0xffc058be8000)
...
[   61.278789] Call trace:
[   61.281232] Exception stack(0xffc058be7470 to 0xffc058be75a0)
[   61.287669] 7460:
ffc058be7720 0080
[   61.295497] 7480: ffc058be7640 ff80085dd404
ff80081081f8 ffc058be74f0
[   61.303325] 74a0: ffc058be74e0 ff80081081f8
ffc058be74d0 ff800899cd68
[   61.311152] 74c0: ffc058be74d0 ff800810758c
ffc058be74e0 ff800899cf10
[   61.318980] 74e0: ffc058be74f0 ff800810823c
ffc058be7570 ff80081083c0
[   61.326806] 7500: 0140 ffc07856d400
 
[   61.334633] 7520:  000a
001e ffc058be7a70
[   61.342461] 7540: ffc048121448 00210d00
4000 ffc058be4000
[   61.350289] 7560: 0860 ffc058be73c8
ff8008f79000 aaab
[   61.358117] 7580: 0241 004fbc5c
ff80081bdcd8 
[   61.365946] [] wlcore_op_get_expected_throughput+0xc/0x1c
[   61.372908] [] ieee80211_get_station+0x4c/0x6c
[   61.378915] [] nl80211_get_station+0x68/0x144
[   61.384835] [] genl_family_rcv_msg+0x1ec/0x340
[   61.390838] [] genl_rcv_msg+0x90/0xd8
[   61.396059] [] netlink_rcv_skb+0xec/0x100
[   61.401627] [] genl_rcv+0x34/0x48
[   61.406501] [] netlink_unicast+0x164/0x258
[   61.412156] [] netlink_sendmsg+0x310/0x374
[   61.417812] [] sock_sendmsg+0x44/0x50
[   61.423033] [] ___sys_sendmsg+0x24c/0x25c
[   61.428601] [] __sys_sendmsg+0x44/0x88
[   61.433907] [] SyS_sendmsg+0x10/0x20
[   61.439043] [] el0_svc_naked+0x24/0x28
[   61.444352] Code: d65f03c0 39438001 f9407800 8b011c00 (396ba801)
[   61.450537] ---[ end trace d464b2870b6d1378 ]---


Digging in it seems like commit 5f6d4ca3c196814bef0cbbb195acd9ecc178588b
("wlcore: Add support for get_expected_throughput opcode") is to
blame, and reverting that seems to resolve the issue.

thanks
-john

Re: [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash

[Theodore Ts'o]

On Wed, Jul 27, 2016 at 09:14:00AM +0200, Heiko Carstens wrote:
> it looks like your patch "random: make /dev/urandom scalable for silly
> userspace programs" within linux-next seems to be a bit broken:
> 
> It causes this allocation failure and subsequent crash on s390 with fake
> NUMA enabled

Thanks for reporting this.  This patch fixes things for you, yes?

- Ted

commit 59b8d4f1f5d26e4ca92172ff6dcd1492cdb39613
Author: Theodore Ts'o 
Date:   Wed Jul 27 23:30:25 2016 -0400

random: use for_each_online_node() to iterate over NUMA nodes

This fixes a crash on s390 with fake NUMA enabled.

Reported-by: Heiko Carstens 
Fixes: 1e7f583af67b ("random: make /dev/urandom scalable for silly 
userspace programs")
Signed-off-by: Theodore Ts'o 

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 8d0af74..7f06224 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1668,13 +1668,12 @@ static int rand_initialize(void)
 #ifdef CONFIG_NUMA
pool = kmalloc(num_nodes * sizeof(void *),
   GFP_KERNEL|__GFP_NOFAIL|__GFP_ZERO);
-   for (i=0; i < num_nodes; i++) {
+   for_each_online_node(i) {
crng = kmalloc_node(sizeof(struct crng_state),
GFP_KERNEL | __GFP_NOFAIL, i);
spin_lock_init(>lock);
crng_initialize(crng);
pool[i] = crng;
-
}
mb();
crng_node_pool = pool;

Re: [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash

[Theodore Ts'o]

On Wed, Jul 27, 2016 at 09:14:00AM +0200, Heiko Carstens wrote:
> it looks like your patch "random: make /dev/urandom scalable for silly
> userspace programs" within linux-next seems to be a bit broken:
> 
> It causes this allocation failure and subsequent crash on s390 with fake
> NUMA enabled

Thanks for reporting this.  This patch fixes things for you, yes?

- Ted

commit 59b8d4f1f5d26e4ca92172ff6dcd1492cdb39613
Author: Theodore Ts'o 
Date:   Wed Jul 27 23:30:25 2016 -0400

random: use for_each_online_node() to iterate over NUMA nodes

This fixes a crash on s390 with fake NUMA enabled.

Reported-by: Heiko Carstens 
Fixes: 1e7f583af67b ("random: make /dev/urandom scalable for silly 
userspace programs")
Signed-off-by: Theodore Ts'o 

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 8d0af74..7f06224 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1668,13 +1668,12 @@ static int rand_initialize(void)
 #ifdef CONFIG_NUMA
pool = kmalloc(num_nodes * sizeof(void *),
   GFP_KERNEL|__GFP_NOFAIL|__GFP_ZERO);
-   for (i=0; i < num_nodes; i++) {
+   for_each_online_node(i) {
crng = kmalloc_node(sizeof(struct crng_state),
GFP_KERNEL | __GFP_NOFAIL, i);
spin_lock_init(>lock);
crng_initialize(crng);
pool[i] = crng;
-
}
mb();
crng_node_pool = pool;

Re: [PATCH] dmaengine: device must have at least one channel

[Vinod Koul]

On Wed, Jul 27, 2016 at 02:32:58PM -0700, Viresh Kumar wrote:
> The DMA device can't be registered if it doesn't have any channels
> registered at all. Moreover, it leads to memory leak and is reported by
> kmemleak as (on 3.10 kernel, and same shall happen on mainline):
> 
> unreferenced object 0xffc09e597240 (size 64):
>   comm "swapper/0", pid 1, jiffies 4294877736 (age 7060.280s)
>   hex dump (first 32 bytes):
> 00 00 00 00 c0 ff ff ff 30 00 00 ff 00 00 00 ff  0...
> 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff  
>   backtrace:
> [] create_object+0x148/0x2a0
> [] kmemleak_alloc+0x80/0xbc
> [] kmem_cache_alloc_trace+0x120/0x1ac
> [] dma_async_device_register+0x160/0x46c
> [] foo_probe+0x1a0/0x264
> [] platform_drv_probe+0x14/0x20
> [] driver_probe_device+0x160/0x374
> [] __driver_attach+0x60/0x90
> [] bus_for_each_dev+0x7c/0xb0
> [] driver_attach+0x1c/0x28
> [] bus_add_driver+0x124/0x248
> [] driver_register+0x90/0x110
> [] platform_driver_register+0x58/0x64
> [] foo_driver_init+0x10/0x1c
> [] do_one_initcall+0xac/0x148
> [] kernel_init_freeable+0x1a0/0x258
> 
> Return -ENODEV from dma_async_device_register() on such a case.
> 
> Signed-off-by: Viresh Kumar 
> ---
> Hi Vinod,
> 
> Sorry if the fundamentals behind this patch are completely incorrect,
> i.e. We *can't* register a dma device with 0 channels. Its been long
> that I have worked on dma stuff :)

This sounds okay, but why would anyone register a device without having
a channel?

> 
>  drivers/dma/dmaengine.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 8c9f45fd55fc..6b535262ac5d 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -997,6 +997,13 @@ int dma_async_device_register(struct dma_device *device)
>   }
>   chan->client_count = 0;
>   }
> +
> + if (!chancnt) {
> + dev_err(device->dev, "%s: device has no channels!\n", __func__);
> + rc = -ENODEV;
> + goto err_out;
> + }
> +
>   device->chancnt = chancnt;
>  
>   mutex_lock(_list_mutex);
> -- 
> 2.7.4
> 

-- 
~Vinod

Re: [PATCH] dmaengine: device must have at least one channel

[Vinod Koul]

On Wed, Jul 27, 2016 at 02:32:58PM -0700, Viresh Kumar wrote:
> The DMA device can't be registered if it doesn't have any channels
> registered at all. Moreover, it leads to memory leak and is reported by
> kmemleak as (on 3.10 kernel, and same shall happen on mainline):
> 
> unreferenced object 0xffc09e597240 (size 64):
>   comm "swapper/0", pid 1, jiffies 4294877736 (age 7060.280s)
>   hex dump (first 32 bytes):
> 00 00 00 00 c0 ff ff ff 30 00 00 ff 00 00 00 ff  0...
> 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff  
>   backtrace:
> [] create_object+0x148/0x2a0
> [] kmemleak_alloc+0x80/0xbc
> [] kmem_cache_alloc_trace+0x120/0x1ac
> [] dma_async_device_register+0x160/0x46c
> [] foo_probe+0x1a0/0x264
> [] platform_drv_probe+0x14/0x20
> [] driver_probe_device+0x160/0x374
> [] __driver_attach+0x60/0x90
> [] bus_for_each_dev+0x7c/0xb0
> [] driver_attach+0x1c/0x28
> [] bus_add_driver+0x124/0x248
> [] driver_register+0x90/0x110
> [] platform_driver_register+0x58/0x64
> [] foo_driver_init+0x10/0x1c
> [] do_one_initcall+0xac/0x148
> [] kernel_init_freeable+0x1a0/0x258
> 
> Return -ENODEV from dma_async_device_register() on such a case.
> 
> Signed-off-by: Viresh Kumar 
> ---
> Hi Vinod,
> 
> Sorry if the fundamentals behind this patch are completely incorrect,
> i.e. We *can't* register a dma device with 0 channels. Its been long
> that I have worked on dma stuff :)

This sounds okay, but why would anyone register a device without having
a channel?

> 
>  drivers/dma/dmaengine.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 8c9f45fd55fc..6b535262ac5d 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -997,6 +997,13 @@ int dma_async_device_register(struct dma_device *device)
>   }
>   chan->client_count = 0;
>   }
> +
> + if (!chancnt) {
> + dev_err(device->dev, "%s: device has no channels!\n", __func__);
> + rc = -ENODEV;
> + goto err_out;
> + }
> +
>   device->chancnt = chancnt;
>  
>   mutex_lock(_list_mutex);
> -- 
> 2.7.4
> 

-- 
~Vinod

Re: [PATCH v2 3/3] drm/mediatek: fix the wrong pixel clock when resolution is 4K

[Bibby Hsieh]

Hi, Philipp,

Thanks for your comments.

On Wed, 2016-07-27 at 11:23 +0200, Philipp Zabel wrote:
> Am Mittwoch, den 27.07.2016, 16:31 +0800 schrieb Bibby Hsieh:
> > From: Junzhi Zhao 
> > 
> > Pixel clock should be 297MHz when resolution is 4K.
> 
> This patch does two different things, please don't conflate them.
> 
> First, it adds support for 16*3 and 2*3 factors between PLL and pixel
> clock. This should be a separate patch and does what this patch
> description says.
> 
> The second part moves the clocks into an array and adds an indirection
> to clock registration depending on of_match_node. This should be a
> separate patch. I suppose this change is in preparation for mt2701
> support, but I'm not sure yet if it is needed at all.
> 

Ok, I will move the change for mt2701 to another patch and send it until
mt2701 start upstream.

> regards
> Philipp
> 
> > Signed-off-by: Junzhi Zhao 
> > Signed-off-by: Bibby Hsieh 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_dpi.c |  149 
> > +++-
> >  1 file changed, 96 insertions(+), 53 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index d05ca79..fa390e0 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -60,14 +60,25 @@ enum mtk_dpi_out_color_format {
> > MTK_DPI_COLOR_FORMAT_YCBCR_422_FULL
> >  };
> >  
> > +enum mtk_dpi_clk_id {
> > +   MTK_DPI_CLK_DPI_ENGINE,
> > +   MTK_DPI_CLK_DPI_PIXEL,
> > +   MTK_DPI_CLK_TVD_PLL,
> > +   MTK_DPI_CLK_COUNT,
> > +};
> > +
> > +static const char * const mtk_dpi_clk_names[MTK_DPI_CLK_COUNT] = {
> > +   [MTK_DPI_CLK_DPI_ENGINE] = "engine",
> > +   [MTK_DPI_CLK_DPI_PIXEL] = "pixel",
> > +   [MTK_DPI_CLK_TVD_PLL] = "pll",
> > +};
> > +
> >  struct mtk_dpi {
> > struct mtk_ddp_comp ddp_comp;
> > struct drm_encoder encoder;
> > void __iomem *regs;
> > struct device *dev;
> > -   struct clk *engine_clk;
> > -   struct clk *pixel_clk;
> > -   struct clk *tvd_clk;
> > +   struct clk *clk[MTK_DPI_CLK_COUNT];
> > int irq;
> > struct drm_display_mode mode;
> > enum mtk_dpi_out_color_format color_format;
> > @@ -76,6 +87,7 @@ struct mtk_dpi {
> > enum mtk_dpi_out_channel_swap channel_swap;
> > bool power_sta;
> > u8 power_ctl;
> > +   void *data;
> >  };
> >  
> >  static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
> > @@ -114,6 +126,10 @@ struct mtk_dpi_yc_limit {
> > u16 c_bottom;
> >  };
> >  
> > +struct mtk_dpi_conf {
> > +   int (*clk_config)(struct mtk_dpi *dpi, struct drm_display_mode *mode);
> > +};
> > +
> >  static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 
> > mask)
> >  {
> > u32 tmp = readl(dpi->regs + offset) & ~mask;
> > @@ -377,8 +393,8 @@ static void mtk_dpi_power_off(struct mtk_dpi *dpi, enum 
> > mtk_dpi_power_ctl pctl)
> > return;
> >  
> > mtk_dpi_disable(dpi);
> > -   clk_disable_unprepare(dpi->pixel_clk);
> > -   clk_disable_unprepare(dpi->engine_clk);
> > +   clk_disable_unprepare(dpi->clk[MTK_DPI_CLK_DPI_PIXEL]);
> > +   clk_disable_unprepare(dpi->clk[MTK_DPI_CLK_DPI_ENGINE]);
> > dpi->power_sta = false;
> >  }
> >  
> > @@ -395,13 +411,13 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum 
> > mtk_dpi_power_ctl pctl)
> > if (dpi->power_sta)
> > return 0;
> >  
> > -   ret = clk_prepare_enable(dpi->engine_clk);
> > +   ret = clk_prepare_enable(dpi->clk[MTK_DPI_CLK_DPI_ENGINE]);
> > if (ret) {
> > dev_err(dpi->dev, "Failed to enable engine clock: %d\n", ret);
> > goto err_eng;
> > }
> >  
> > -   ret = clk_prepare_enable(dpi->pixel_clk);
> > +   ret = clk_prepare_enable(dpi->clk[MTK_DPI_CLK_DPI_PIXEL]);
> > if (ret) {
> > dev_err(dpi->dev, "Failed to enable pixel clock: %d\n", ret);
> > goto err_pixel;
> > @@ -412,7 +428,7 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum 
> > mtk_dpi_power_ctl pctl)
> > return 0;
> >  
> >  err_pixel:
> > -   clk_disable_unprepare(dpi->engine_clk);
> > +   clk_disable_unprepare(dpi->clk[MTK_DPI_CLK_DPI_ENGINE]);
> >  err_eng:
> > dpi->power_ctl &= ~pctl;
> > return ret;
> > @@ -428,34 +444,18 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi 
> > *dpi,
> > struct mtk_dpi_sync_param vsync_leven = { 0 };
> > struct mtk_dpi_sync_param vsync_rodd = { 0 };
> > struct mtk_dpi_sync_param vsync_reven = { 0 };
> > -   unsigned long pix_rate;
> > -   unsigned long pll_rate;
> > -   unsigned int factor;
> > +   struct mtk_dpi_conf *conf;
> > +   int ret;
> >  
> > if (!dpi) {
> > dev_err(dpi->dev, "invalid argument\n");
> > return -EINVAL;
> > }
> >  
> > -   pix_rate = 1000UL * mode->clock;
> > -   if (mode->clock <= 74000)
> > -   factor = 8 * 3;
> > -   else
> > -   factor = 4 * 3;
> 

Re: [PATCH v2 3/3] drm/mediatek: fix the wrong pixel clock when resolution is 4K

[Bibby Hsieh]

Hi, Philipp,

Thanks for your comments.

On Wed, 2016-07-27 at 11:23 +0200, Philipp Zabel wrote:
> Am Mittwoch, den 27.07.2016, 16:31 +0800 schrieb Bibby Hsieh:
> > From: Junzhi Zhao 
> > 
> > Pixel clock should be 297MHz when resolution is 4K.
> 
> This patch does two different things, please don't conflate them.
> 
> First, it adds support for 16*3 and 2*3 factors between PLL and pixel
> clock. This should be a separate patch and does what this patch
> description says.
> 
> The second part moves the clocks into an array and adds an indirection
> to clock registration depending on of_match_node. This should be a
> separate patch. I suppose this change is in preparation for mt2701
> support, but I'm not sure yet if it is needed at all.
> 

Ok, I will move the change for mt2701 to another patch and send it until
mt2701 start upstream.

> regards
> Philipp
> 
> > Signed-off-by: Junzhi Zhao 
> > Signed-off-by: Bibby Hsieh 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_dpi.c |  149 
> > +++-
> >  1 file changed, 96 insertions(+), 53 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index d05ca79..fa390e0 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -60,14 +60,25 @@ enum mtk_dpi_out_color_format {
> > MTK_DPI_COLOR_FORMAT_YCBCR_422_FULL
> >  };
> >  
> > +enum mtk_dpi_clk_id {
> > +   MTK_DPI_CLK_DPI_ENGINE,
> > +   MTK_DPI_CLK_DPI_PIXEL,
> > +   MTK_DPI_CLK_TVD_PLL,
> > +   MTK_DPI_CLK_COUNT,
> > +};
> > +
> > +static const char * const mtk_dpi_clk_names[MTK_DPI_CLK_COUNT] = {
> > +   [MTK_DPI_CLK_DPI_ENGINE] = "engine",
> > +   [MTK_DPI_CLK_DPI_PIXEL] = "pixel",
> > +   [MTK_DPI_CLK_TVD_PLL] = "pll",
> > +};
> > +
> >  struct mtk_dpi {
> > struct mtk_ddp_comp ddp_comp;
> > struct drm_encoder encoder;
> > void __iomem *regs;
> > struct device *dev;
> > -   struct clk *engine_clk;
> > -   struct clk *pixel_clk;
> > -   struct clk *tvd_clk;
> > +   struct clk *clk[MTK_DPI_CLK_COUNT];
> > int irq;
> > struct drm_display_mode mode;
> > enum mtk_dpi_out_color_format color_format;
> > @@ -76,6 +87,7 @@ struct mtk_dpi {
> > enum mtk_dpi_out_channel_swap channel_swap;
> > bool power_sta;
> > u8 power_ctl;
> > +   void *data;
> >  };
> >  
> >  static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
> > @@ -114,6 +126,10 @@ struct mtk_dpi_yc_limit {
> > u16 c_bottom;
> >  };
> >  
> > +struct mtk_dpi_conf {
> > +   int (*clk_config)(struct mtk_dpi *dpi, struct drm_display_mode *mode);
> > +};
> > +
> >  static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 
> > mask)
> >  {
> > u32 tmp = readl(dpi->regs + offset) & ~mask;
> > @@ -377,8 +393,8 @@ static void mtk_dpi_power_off(struct mtk_dpi *dpi, enum 
> > mtk_dpi_power_ctl pctl)
> > return;
> >  
> > mtk_dpi_disable(dpi);
> > -   clk_disable_unprepare(dpi->pixel_clk);
> > -   clk_disable_unprepare(dpi->engine_clk);
> > +   clk_disable_unprepare(dpi->clk[MTK_DPI_CLK_DPI_PIXEL]);
> > +   clk_disable_unprepare(dpi->clk[MTK_DPI_CLK_DPI_ENGINE]);
> > dpi->power_sta = false;
> >  }
> >  
> > @@ -395,13 +411,13 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum 
> > mtk_dpi_power_ctl pctl)
> > if (dpi->power_sta)
> > return 0;
> >  
> > -   ret = clk_prepare_enable(dpi->engine_clk);
> > +   ret = clk_prepare_enable(dpi->clk[MTK_DPI_CLK_DPI_ENGINE]);
> > if (ret) {
> > dev_err(dpi->dev, "Failed to enable engine clock: %d\n", ret);
> > goto err_eng;
> > }
> >  
> > -   ret = clk_prepare_enable(dpi->pixel_clk);
> > +   ret = clk_prepare_enable(dpi->clk[MTK_DPI_CLK_DPI_PIXEL]);
> > if (ret) {
> > dev_err(dpi->dev, "Failed to enable pixel clock: %d\n", ret);
> > goto err_pixel;
> > @@ -412,7 +428,7 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum 
> > mtk_dpi_power_ctl pctl)
> > return 0;
> >  
> >  err_pixel:
> > -   clk_disable_unprepare(dpi->engine_clk);
> > +   clk_disable_unprepare(dpi->clk[MTK_DPI_CLK_DPI_ENGINE]);
> >  err_eng:
> > dpi->power_ctl &= ~pctl;
> > return ret;
> > @@ -428,34 +444,18 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi 
> > *dpi,
> > struct mtk_dpi_sync_param vsync_leven = { 0 };
> > struct mtk_dpi_sync_param vsync_rodd = { 0 };
> > struct mtk_dpi_sync_param vsync_reven = { 0 };
> > -   unsigned long pix_rate;
> > -   unsigned long pll_rate;
> > -   unsigned int factor;
> > +   struct mtk_dpi_conf *conf;
> > +   int ret;
> >  
> > if (!dpi) {
> > dev_err(dpi->dev, "invalid argument\n");
> > return -EINVAL;
> > }
> >  
> > -   pix_rate = 1000UL * mode->clock;
> > -   if (mode->clock <= 74000)
> > -   factor = 8 * 3;
> > -   else
> > -   factor = 4 * 3;
> > -   pll_rate = pix_rate * factor;
> > -
> > -   dev_dbg(dpi->dev, "Want PLL 

Re: [PATCH v11] acpi, apei, arm64: APEI initial support for aarch64.

[Fu Wei]

Hi Rafael,

On 28 July 2016 at 07:12, Rafael J. Wysocki  wrote:
> On Thursday, July 28, 2016 01:29:05 AM fu@linaro.org wrote:
>> From: Tomasz Nowicki 
>>
>> This commit provides APEI arch-specific bits for aarch64
>>
>> Meanwhile,
>> (1)add a new subfunction "hest_ia32_init" for
>> "acpi_disable_cmcff" which is used by IA-32 Architecture
>> Corrected Machine Check (CMC).
>> (2)move HEST type (ACPI_HEST_TYPE_IA32_CORRECTED_CHECK) checking to
>> a generic place.
>> (3)select HAVE_ACPI_APEI when EFI and ACPI is set on ARM64,
>> because arch_apei_get_mem_attribute is using efi_mem_attributes on ARM64.
>>
>> [Fu Wei: improve && upstream]
>>
>> Signed-off-by: Tomasz Nowicki 
>> Tested-by: Jonathan (Zhixiong) Zhang 
>> Signed-off-by: Fu Wei 
>> Acked-by: Hanjun Guo 
>> Tested-by: Tyler Baicar 
>> Acked-by: Will Deacon 
>
> You have an impressive list of addresses in the CC, the majority of them
> probably quite irrelevant.  Any chance to reduce that next time?
>
> Boris and Tony need to be CCed, though.

OK, will do, Thanks for reminding me  :-)

>
>> ---
>> Changelog:
>> v11:https://lkml.org/lkml/2016/7
>> Rebase to v4.7-0e06f5c0
>>
>> v10:https://lkml.org/lkml/2016/4/14
>> Fix the Alphabetical order problem in arch/arm64/Kconfig
>>
>> v9: https://lkml.org/lkml/2016/4/5/522
>> Improve the comment for arch_apei_flush_tlb_one.
>> Using select "HAVE_ACPI_APEI if (ACPI && EFI)" to fix the EFI dependence
>> problem.
>>
>> v8: https://lkml.org/lkml/2016/3/29/132
>> Fix a "undefined reference" bug by selecting EFI when ACPI_APEI is set
>> on ARM64.
>>
>> v7: https://lkml.org/lkml/2016/3/17/183
>> Add comment for arch_apei_flush_tlb_one in arch/arm64/include/asm/acpi.h
>>
>> v6: https://lists.linaro.org/pipermail/linaro-acpi/2016-March/006644.html
>> Move HEST type (ACPI_HEST_TYPE_IA32_CORRECTED_CHECK) checking to
>> a generic place.
>> Delete HAVE_ACPI_APEI_HEST_IA32.
>>
>> v5: https://lkml.org/lkml/2015/12/10/131
>> Add "HAVE_ACPI_APEI_HEST_IA32" instead of
>> "#if defined(__i386__) || defined(__x86_64__)".
>>
>> v4: https://lkml.org/lkml/2015/12/8/188
>> Rebase to latest kernel version(4.4-rc4).
>> Move arch_apei_flush_tlb_one into header file as a inline function
>> Add a new subfunction "hest_ia_init" for "acpi_disable_cmcff".
>>
>> v3: https://lkml.org/lkml/2015/12/3/521
>> Remove "acpi_disable_cmcff" from arm64 code,
>> and wrap it in hest.c by "#if defined(__i386__) || defined(__x86_64__)"
>>
>> v2: https://lkml.org/lkml/2015/12/2/432
>> Rebase to latest kernel version(4.4-rc3).
>> Move arch_apei_flush_tlb_one() to arch/arm64/kernel/acpi.c
>>
>> v1: https://lkml.org/lkml/2015/8/14/199
>> Move arch_apei_flush_tlb_one() to arch/arm64/include/asm/apci.h.
>> Delete arch/arm64/kernel/apei.c.
>> Add "#ifdef CONFIG_ACPI_APEI" for "acpi_disable_cmcff".
>>
>>  arch/arm64/Kconfig|  1 +
>>  arch/arm64/include/asm/acpi.h | 16 +++-
>>  arch/x86/kernel/acpi/apei.c   |  3 ---
>>  drivers/acpi/apei/hest.c  | 18 +++---
>>  4 files changed, 31 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 20d5a60..a301765 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -49,6 +49,7 @@ config ARM64
>>   select GENERIC_TIME_VSYSCALL
>>   select HANDLE_DOMAIN_IRQ
>>   select HARDIRQS_SW_RESEND
>> + select HAVE_ACPI_APEI if (ACPI && EFI)
>>   select HAVE_ALIGNED_STRUCT_PAGE if SLUB
>>   select HAVE_ARCH_AUDITSYSCALL
>>   select HAVE_ARCH_BITREVERSE
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 5420cb0..d3d02dc 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -17,6 +17,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>
>>  /* Macros for consistency checks of the GICC subtable of MADT */
>>  #define ACPI_MADT_GICC_LENGTH\
>> @@ -110,8 +111,21 @@ static inline const char *acpi_get_enable_method(int 
>> cpu)
>>  }
>>
>>  #ifdef   CONFIG_ACPI_APEI
>> +#define acpi_disable_cmcff 1
>>  pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
>> -#endif
>> +
>> +/*
>> + * Despite its name, this function must still broadcast the TLB
>> + * invalidation in order to ensure other CPUs don't up with with junk
>> + * entries as a result of speculation. Unusually, its also called in
>> + * IRQ context (ghes_iounmap_irq) so if we ever need to use IPIs for
>> + * TLB broadcasting, then we're in trouble here.
>> + */
>> +static inline void arch_apei_flush_tlb_one(unsigned long addr)
>> +{
>> + flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
>> +}
>> +#endif /* CONFIG_ACPI_APEI */
>>
>>  #ifdef CONFIG_ACPI_NUMA
>>  int arm64_acpi_numa_init(void);
>> diff 

Re: [PATCH v11] acpi, apei, arm64: APEI initial support for aarch64.

[Fu Wei]

Hi Rafael,

On 28 July 2016 at 07:12, Rafael J. Wysocki  wrote:
> On Thursday, July 28, 2016 01:29:05 AM fu@linaro.org wrote:
>> From: Tomasz Nowicki 
>>
>> This commit provides APEI arch-specific bits for aarch64
>>
>> Meanwhile,
>> (1)add a new subfunction "hest_ia32_init" for
>> "acpi_disable_cmcff" which is used by IA-32 Architecture
>> Corrected Machine Check (CMC).
>> (2)move HEST type (ACPI_HEST_TYPE_IA32_CORRECTED_CHECK) checking to
>> a generic place.
>> (3)select HAVE_ACPI_APEI when EFI and ACPI is set on ARM64,
>> because arch_apei_get_mem_attribute is using efi_mem_attributes on ARM64.
>>
>> [Fu Wei: improve && upstream]
>>
>> Signed-off-by: Tomasz Nowicki 
>> Tested-by: Jonathan (Zhixiong) Zhang 
>> Signed-off-by: Fu Wei 
>> Acked-by: Hanjun Guo 
>> Tested-by: Tyler Baicar 
>> Acked-by: Will Deacon 
>
> You have an impressive list of addresses in the CC, the majority of them
> probably quite irrelevant.  Any chance to reduce that next time?
>
> Boris and Tony need to be CCed, though.

OK, will do, Thanks for reminding me  :-)

>
>> ---
>> Changelog:
>> v11:https://lkml.org/lkml/2016/7
>> Rebase to v4.7-0e06f5c0
>>
>> v10:https://lkml.org/lkml/2016/4/14
>> Fix the Alphabetical order problem in arch/arm64/Kconfig
>>
>> v9: https://lkml.org/lkml/2016/4/5/522
>> Improve the comment for arch_apei_flush_tlb_one.
>> Using select "HAVE_ACPI_APEI if (ACPI && EFI)" to fix the EFI dependence
>> problem.
>>
>> v8: https://lkml.org/lkml/2016/3/29/132
>> Fix a "undefined reference" bug by selecting EFI when ACPI_APEI is set
>> on ARM64.
>>
>> v7: https://lkml.org/lkml/2016/3/17/183
>> Add comment for arch_apei_flush_tlb_one in arch/arm64/include/asm/acpi.h
>>
>> v6: https://lists.linaro.org/pipermail/linaro-acpi/2016-March/006644.html
>> Move HEST type (ACPI_HEST_TYPE_IA32_CORRECTED_CHECK) checking to
>> a generic place.
>> Delete HAVE_ACPI_APEI_HEST_IA32.
>>
>> v5: https://lkml.org/lkml/2015/12/10/131
>> Add "HAVE_ACPI_APEI_HEST_IA32" instead of
>> "#if defined(__i386__) || defined(__x86_64__)".
>>
>> v4: https://lkml.org/lkml/2015/12/8/188
>> Rebase to latest kernel version(4.4-rc4).
>> Move arch_apei_flush_tlb_one into header file as a inline function
>> Add a new subfunction "hest_ia_init" for "acpi_disable_cmcff".
>>
>> v3: https://lkml.org/lkml/2015/12/3/521
>> Remove "acpi_disable_cmcff" from arm64 code,
>> and wrap it in hest.c by "#if defined(__i386__) || defined(__x86_64__)"
>>
>> v2: https://lkml.org/lkml/2015/12/2/432
>> Rebase to latest kernel version(4.4-rc3).
>> Move arch_apei_flush_tlb_one() to arch/arm64/kernel/acpi.c
>>
>> v1: https://lkml.org/lkml/2015/8/14/199
>> Move arch_apei_flush_tlb_one() to arch/arm64/include/asm/apci.h.
>> Delete arch/arm64/kernel/apei.c.
>> Add "#ifdef CONFIG_ACPI_APEI" for "acpi_disable_cmcff".
>>
>>  arch/arm64/Kconfig|  1 +
>>  arch/arm64/include/asm/acpi.h | 16 +++-
>>  arch/x86/kernel/acpi/apei.c   |  3 ---
>>  drivers/acpi/apei/hest.c  | 18 +++---
>>  4 files changed, 31 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 20d5a60..a301765 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -49,6 +49,7 @@ config ARM64
>>   select GENERIC_TIME_VSYSCALL
>>   select HANDLE_DOMAIN_IRQ
>>   select HARDIRQS_SW_RESEND
>> + select HAVE_ACPI_APEI if (ACPI && EFI)
>>   select HAVE_ALIGNED_STRUCT_PAGE if SLUB
>>   select HAVE_ARCH_AUDITSYSCALL
>>   select HAVE_ARCH_BITREVERSE
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 5420cb0..d3d02dc 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -17,6 +17,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>
>>  /* Macros for consistency checks of the GICC subtable of MADT */
>>  #define ACPI_MADT_GICC_LENGTH\
>> @@ -110,8 +111,21 @@ static inline const char *acpi_get_enable_method(int 
>> cpu)
>>  }
>>
>>  #ifdef   CONFIG_ACPI_APEI
>> +#define acpi_disable_cmcff 1
>>  pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
>> -#endif
>> +
>> +/*
>> + * Despite its name, this function must still broadcast the TLB
>> + * invalidation in order to ensure other CPUs don't up with with junk
>> + * entries as a result of speculation. Unusually, its also called in
>> + * IRQ context (ghes_iounmap_irq) so if we ever need to use IPIs for
>> + * TLB broadcasting, then we're in trouble here.
>> + */
>> +static inline void arch_apei_flush_tlb_one(unsigned long addr)
>> +{
>> + flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
>> +}
>> +#endif /* CONFIG_ACPI_APEI */
>>
>>  #ifdef CONFIG_ACPI_NUMA
>>  int arm64_acpi_numa_init(void);
>> diff --git a/arch/x86/kernel/acpi/apei.c b/arch/x86/kernel/acpi/apei.c
>> index c280df6..ea3046e 100644
>> --- a/arch/x86/kernel/acpi/apei.c
>> +++ b/arch/x86/kernel/acpi/apei.c
>> @@ -24,9 

Re: [PATCH v2 2/3] drm/mediatek: enhance the HDMI driving current

[Bibby Hsieh]

Hi, Philipp,

Thanks for your review.

On Wed, 2016-07-27 at 11:25 +0200, Philipp Zabel wrote:
> Am Mittwoch, den 27.07.2016, 16:31 +0800 schrieb Bibby Hsieh:
> > From: Junzhi Zhao 
> > 
> > In order to improve 4K resolution performance,
> > we have to enhance the HDMI driving currend
>^
> Typo, s/currend/current/
> 
> Besides that, this patch looks good to me.
> 
Ok, I will fix that, thanks.
> regards
> Philipp
> 
> > when clock rate is greater than 165MHz.
> > 
> > Signed-off-by: Junzhi Zhao 
> > Signed-off-by: Bibby Hsieh 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c |   42 
> > +---
> >  1 file changed, 30 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
> > b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > index 8a24754..51cb9cf 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > @@ -265,6 +265,9 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
> > unsigned long rate,
> > struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> > unsigned int pre_div;
> > unsigned int div;
> > +   unsigned int pre_ibias;
> > +   unsigned int hdmi_ibias;
> > +   unsigned int imp_en;
> >  
> > dev_dbg(hdmi_phy->dev, "%s: %lu Hz, parent: %lu Hz\n", __func__,
> > rate, parent_rate);
> > @@ -298,18 +301,31 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
> > unsigned long rate,
> >   (0x1 << PLL_BR_SHIFT),
> >   RG_HDMITX_PLL_BP | RG_HDMITX_PLL_BC |
> >   RG_HDMITX_PLL_BR);
> > -   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3, RG_HDMITX_PRD_IMP_EN);
> > +   if (rate < 16500) {
> > +   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3,
> > +   RG_HDMITX_PRD_IMP_EN);
> > +   pre_ibias = 0x3;
> > +   imp_en = 0x0;
> > +   hdmi_ibias = hdmi_phy->ibias;
> > +   } else {
> > +   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON3,
> > + RG_HDMITX_PRD_IMP_EN);
> > +   pre_ibias = 0x6;
> > +   imp_en = 0xf;
> > +   hdmi_ibias = hdmi_phy->ibias_up;
> > +   }
> > mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON4,
> > - (0x3 << PRD_IBIAS_CLK_SHIFT) |
> > - (0x3 << PRD_IBIAS_D2_SHIFT) |
> > - (0x3 << PRD_IBIAS_D1_SHIFT) |
> > - (0x3 << PRD_IBIAS_D0_SHIFT),
> > + (pre_ibias << PRD_IBIAS_CLK_SHIFT) |
> > + (pre_ibias << PRD_IBIAS_D2_SHIFT) |
> > + (pre_ibias << PRD_IBIAS_D1_SHIFT) |
> > + (pre_ibias << PRD_IBIAS_D0_SHIFT),
> >   RG_HDMITX_PRD_IBIAS_CLK |
> >   RG_HDMITX_PRD_IBIAS_D2 |
> >   RG_HDMITX_PRD_IBIAS_D1 |
> >   RG_HDMITX_PRD_IBIAS_D0);
> > mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON3,
> > - (0x0 << DRV_IMP_EN_SHIFT), RG_HDMITX_DRV_IMP_EN);
> > + (imp_en << DRV_IMP_EN_SHIFT),
> > + RG_HDMITX_DRV_IMP_EN);
> > mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6,
> >   (hdmi_phy->drv_imp_clk << DRV_IMP_CLK_SHIFT) |
> >   (hdmi_phy->drv_imp_d2 << DRV_IMP_D2_SHIFT) |
> > @@ -318,12 +334,14 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
> > unsigned long rate,
> >   RG_HDMITX_DRV_IMP_CLK | RG_HDMITX_DRV_IMP_D2 |
> >   RG_HDMITX_DRV_IMP_D1 | RG_HDMITX_DRV_IMP_D0);
> > mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON5,
> > - (hdmi_phy->ibias << DRV_IBIAS_CLK_SHIFT) |
> > - (hdmi_phy->ibias << DRV_IBIAS_D2_SHIFT) |
> > - (hdmi_phy->ibias << DRV_IBIAS_D1_SHIFT) |
> > - (hdmi_phy->ibias << DRV_IBIAS_D0_SHIFT),
> > - RG_HDMITX_DRV_IBIAS_CLK | RG_HDMITX_DRV_IBIAS_D2 |
> > - RG_HDMITX_DRV_IBIAS_D1 | RG_HDMITX_DRV_IBIAS_D0);
> > + (hdmi_ibias << DRV_IBIAS_CLK_SHIFT) |
> > + (hdmi_ibias << DRV_IBIAS_D2_SHIFT) |
> > + (hdmi_ibias << DRV_IBIAS_D1_SHIFT) |
> > + (hdmi_ibias << DRV_IBIAS_D0_SHIFT),
> > + RG_HDMITX_DRV_IBIAS_CLK |
> > + RG_HDMITX_DRV_IBIAS_D2 |
> > + RG_HDMITX_DRV_IBIAS_D1 |
> > + RG_HDMITX_DRV_IBIAS_D0);
> > return 0;
> >  }
> >  
> 
> 

-- 
Bibby

Re: [PATCH v2 2/3] drm/mediatek: enhance the HDMI driving current

[Bibby Hsieh]

Hi, Philipp,

Thanks for your review.

On Wed, 2016-07-27 at 11:25 +0200, Philipp Zabel wrote:
> Am Mittwoch, den 27.07.2016, 16:31 +0800 schrieb Bibby Hsieh:
> > From: Junzhi Zhao 
> > 
> > In order to improve 4K resolution performance,
> > we have to enhance the HDMI driving currend
>^
> Typo, s/currend/current/
> 
> Besides that, this patch looks good to me.
> 
Ok, I will fix that, thanks.
> regards
> Philipp
> 
> > when clock rate is greater than 165MHz.
> > 
> > Signed-off-by: Junzhi Zhao 
> > Signed-off-by: Bibby Hsieh 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c |   42 
> > +---
> >  1 file changed, 30 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
> > b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > index 8a24754..51cb9cf 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > @@ -265,6 +265,9 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
> > unsigned long rate,
> > struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> > unsigned int pre_div;
> > unsigned int div;
> > +   unsigned int pre_ibias;
> > +   unsigned int hdmi_ibias;
> > +   unsigned int imp_en;
> >  
> > dev_dbg(hdmi_phy->dev, "%s: %lu Hz, parent: %lu Hz\n", __func__,
> > rate, parent_rate);
> > @@ -298,18 +301,31 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
> > unsigned long rate,
> >   (0x1 << PLL_BR_SHIFT),
> >   RG_HDMITX_PLL_BP | RG_HDMITX_PLL_BC |
> >   RG_HDMITX_PLL_BR);
> > -   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3, RG_HDMITX_PRD_IMP_EN);
> > +   if (rate < 16500) {
> > +   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3,
> > +   RG_HDMITX_PRD_IMP_EN);
> > +   pre_ibias = 0x3;
> > +   imp_en = 0x0;
> > +   hdmi_ibias = hdmi_phy->ibias;
> > +   } else {
> > +   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON3,
> > + RG_HDMITX_PRD_IMP_EN);
> > +   pre_ibias = 0x6;
> > +   imp_en = 0xf;
> > +   hdmi_ibias = hdmi_phy->ibias_up;
> > +   }
> > mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON4,
> > - (0x3 << PRD_IBIAS_CLK_SHIFT) |
> > - (0x3 << PRD_IBIAS_D2_SHIFT) |
> > - (0x3 << PRD_IBIAS_D1_SHIFT) |
> > - (0x3 << PRD_IBIAS_D0_SHIFT),
> > + (pre_ibias << PRD_IBIAS_CLK_SHIFT) |
> > + (pre_ibias << PRD_IBIAS_D2_SHIFT) |
> > + (pre_ibias << PRD_IBIAS_D1_SHIFT) |
> > + (pre_ibias << PRD_IBIAS_D0_SHIFT),
> >   RG_HDMITX_PRD_IBIAS_CLK |
> >   RG_HDMITX_PRD_IBIAS_D2 |
> >   RG_HDMITX_PRD_IBIAS_D1 |
> >   RG_HDMITX_PRD_IBIAS_D0);
> > mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON3,
> > - (0x0 << DRV_IMP_EN_SHIFT), RG_HDMITX_DRV_IMP_EN);
> > + (imp_en << DRV_IMP_EN_SHIFT),
> > + RG_HDMITX_DRV_IMP_EN);
> > mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6,
> >   (hdmi_phy->drv_imp_clk << DRV_IMP_CLK_SHIFT) |
> >   (hdmi_phy->drv_imp_d2 << DRV_IMP_D2_SHIFT) |
> > @@ -318,12 +334,14 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
> > unsigned long rate,
> >   RG_HDMITX_DRV_IMP_CLK | RG_HDMITX_DRV_IMP_D2 |
> >   RG_HDMITX_DRV_IMP_D1 | RG_HDMITX_DRV_IMP_D0);
> > mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON5,
> > - (hdmi_phy->ibias << DRV_IBIAS_CLK_SHIFT) |
> > - (hdmi_phy->ibias << DRV_IBIAS_D2_SHIFT) |
> > - (hdmi_phy->ibias << DRV_IBIAS_D1_SHIFT) |
> > - (hdmi_phy->ibias << DRV_IBIAS_D0_SHIFT),
> > - RG_HDMITX_DRV_IBIAS_CLK | RG_HDMITX_DRV_IBIAS_D2 |
> > - RG_HDMITX_DRV_IBIAS_D1 | RG_HDMITX_DRV_IBIAS_D0);
> > + (hdmi_ibias << DRV_IBIAS_CLK_SHIFT) |
> > + (hdmi_ibias << DRV_IBIAS_D2_SHIFT) |
> > + (hdmi_ibias << DRV_IBIAS_D1_SHIFT) |
> > + (hdmi_ibias << DRV_IBIAS_D0_SHIFT),
> > + RG_HDMITX_DRV_IBIAS_CLK |
> > + RG_HDMITX_DRV_IBIAS_D2 |
> > + RG_HDMITX_DRV_IBIAS_D1 |
> > + RG_HDMITX_DRV_IBIAS_D0);
> > return 0;
> >  }
> >  
> 
> 

-- 
Bibby

Re: [PATCH v2 1/3] drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable

[Bibby Hsieh]

Hi, Philipp,

Thanks for your review.

On Wed, 2016-07-27 at 11:27 +0200, Philipp Zabel wrote:
> Am Mittwoch, den 27.07.2016, 16:31 +0800 schrieb Bibby Hsieh:
> > From: Junzhi Zhao 
> > 
> > The mtk_hdmi_send_infoframe have to
> > be run after PLL and PIXEL clock of HDMI enable.
> > Make sure that HDMI inforframes can be sent
> > successfully.
> > 
> > Signed-off-by: Junzhi Zhao 
> > Signed-off-by: Bibby Hsieh 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_hdmi.c |   19 ---
> >  1 file changed, 12 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
> > b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > index ba812ef..d8609f5 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > @@ -1133,12 +1133,6 @@ static int mtk_hdmi_output_set_display_mode(struct 
> > mtk_hdmi *hdmi,
> > phy_power_on(hdmi->phy);
> > mtk_hdmi_aud_output_config(hdmi, mode);
> >  
> > -   mtk_hdmi_setup_audio_infoframe(hdmi);
> > -   mtk_hdmi_setup_avi_infoframe(hdmi, mode);
> > -   mtk_hdmi_setup_spd_infoframe(hdmi, "mediatek", "On-chip HDMI");
> > -   if (mode->flags & DRM_MODE_FLAG_3D_MASK)
> > -   mtk_hdmi_setup_vendor_specific_infoframe(hdmi, mode);
> > -
> > mtk_hdmi_hw_vid_black(hdmi, false);
> > mtk_hdmi_hw_aud_unmute(hdmi);
> > mtk_hdmi_hw_send_av_unmute(hdmi);
> > @@ -1401,14 +1395,25 @@ static void mtk_hdmi_bridge_pre_enable(struct 
> > drm_bridge *bridge)
> > hdmi->powered = true;
> >  }
> >  
> > +static void mtk_hdmi_send_infoframe(struct mtk_hdmi *hdmi,
> > +   struct drm_display_mode *mode)
> > +{
> > +   mtk_hdmi_setup_audio_infoframe(hdmi);
> > +   mtk_hdmi_setup_avi_infoframe(hdmi, mode);
> > +   mtk_hdmi_setup_spd_infoframe(hdmi, "mediatek", "On-chip HDMI");
> > +   if (mode->flags & DRM_MODE_FLAG_3D_MASK)
> > +   mtk_hdmi_setup_vendor_specific_infoframe(hdmi, mode);
> > +}
> > +
> >  static void mtk_hdmi_bridge_enable(struct drm_bridge *bridge)
> >  {
> > struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
> >  
> > +   phy_power_on(hdmi->phy);
> > mtk_hdmi_output_set_display_mode(hdmi, >mode);
> > clk_prepare_enable(hdmi->clk[MTK_HDMI_CLK_HDMI_PLL]);
> > clk_prepare_enable(hdmi->clk[MTK_HDMI_CLK_HDMI_PIXEL]);
> > -   phy_power_on(hdmi->phy);
> 
> This change is not described in the patch description. Why is the phy
> power on moved after the pixel clock enable?
> 
Ok, will rollback it.
> > +   mtk_hdmi_send_infoframe(hdmi, >mode);
> >  
> > hdmi->enabled = true;
> >  }
> 
> regards
> Philipp
> 

-- 
Bibby

Re: [PATCH v2 1/3] drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable

[Bibby Hsieh]

Hi, Philipp,

Thanks for your review.

On Wed, 2016-07-27 at 11:27 +0200, Philipp Zabel wrote:
> Am Mittwoch, den 27.07.2016, 16:31 +0800 schrieb Bibby Hsieh:
> > From: Junzhi Zhao 
> > 
> > The mtk_hdmi_send_infoframe have to
> > be run after PLL and PIXEL clock of HDMI enable.
> > Make sure that HDMI inforframes can be sent
> > successfully.
> > 
> > Signed-off-by: Junzhi Zhao 
> > Signed-off-by: Bibby Hsieh 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_hdmi.c |   19 ---
> >  1 file changed, 12 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
> > b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > index ba812ef..d8609f5 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > @@ -1133,12 +1133,6 @@ static int mtk_hdmi_output_set_display_mode(struct 
> > mtk_hdmi *hdmi,
> > phy_power_on(hdmi->phy);
> > mtk_hdmi_aud_output_config(hdmi, mode);
> >  
> > -   mtk_hdmi_setup_audio_infoframe(hdmi);
> > -   mtk_hdmi_setup_avi_infoframe(hdmi, mode);
> > -   mtk_hdmi_setup_spd_infoframe(hdmi, "mediatek", "On-chip HDMI");
> > -   if (mode->flags & DRM_MODE_FLAG_3D_MASK)
> > -   mtk_hdmi_setup_vendor_specific_infoframe(hdmi, mode);
> > -
> > mtk_hdmi_hw_vid_black(hdmi, false);
> > mtk_hdmi_hw_aud_unmute(hdmi);
> > mtk_hdmi_hw_send_av_unmute(hdmi);
> > @@ -1401,14 +1395,25 @@ static void mtk_hdmi_bridge_pre_enable(struct 
> > drm_bridge *bridge)
> > hdmi->powered = true;
> >  }
> >  
> > +static void mtk_hdmi_send_infoframe(struct mtk_hdmi *hdmi,
> > +   struct drm_display_mode *mode)
> > +{
> > +   mtk_hdmi_setup_audio_infoframe(hdmi);
> > +   mtk_hdmi_setup_avi_infoframe(hdmi, mode);
> > +   mtk_hdmi_setup_spd_infoframe(hdmi, "mediatek", "On-chip HDMI");
> > +   if (mode->flags & DRM_MODE_FLAG_3D_MASK)
> > +   mtk_hdmi_setup_vendor_specific_infoframe(hdmi, mode);
> > +}
> > +
> >  static void mtk_hdmi_bridge_enable(struct drm_bridge *bridge)
> >  {
> > struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
> >  
> > +   phy_power_on(hdmi->phy);
> > mtk_hdmi_output_set_display_mode(hdmi, >mode);
> > clk_prepare_enable(hdmi->clk[MTK_HDMI_CLK_HDMI_PLL]);
> > clk_prepare_enable(hdmi->clk[MTK_HDMI_CLK_HDMI_PIXEL]);
> > -   phy_power_on(hdmi->phy);
> 
> This change is not described in the patch description. Why is the phy
> power on moved after the pixel clock enable?
> 
Ok, will rollback it.
> > +   mtk_hdmi_send_infoframe(hdmi, >mode);
> >  
> > hdmi->enabled = true;
> >  }
> 
> regards
> Philipp
> 

-- 
Bibby

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

[Linus Torvalds]

On Wed, Jul 27, 2016 at 8:31 PM, Linus Torvalds
 wrote:
>
> I'd actually prefer to make "--git" the default, if you are inside a
> git repository. Because obviously the *actual* default is too hard to
> understand ;)

I'd also like to make the "-f" optional.

I constantly forget it, and curse it. It should be trivial to see "the
argument is a file that is tracked in git, so it clearly isn't the
name of a patch".

   Linus

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

[Linus Torvalds]

On Wed, Jul 27, 2016 at 8:31 PM, Linus Torvalds
 wrote:
>
> I'd actually prefer to make "--git" the default, if you are inside a
> git repository. Because obviously the *actual* default is too hard to
> understand ;)

I'd also like to make the "-f" optional.

I constantly forget it, and curse it. It should be trivial to see "the
argument is a file that is tracked in git, so it clearly isn't the
name of a patch".

   Linus

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

[Linus Torvalds]

On Wed, Jul 27, 2016 at 8:26 PM, Linus Torvalds
 wrote:
>
> Hmm. Fishy.

Hmm. The exact match logic is a bit odd, and clearly doesn't mean what
I thought it meant. Reading that perl code just makes me more
confused.

I'd actually prefer to make "--git" the default, if you are inside a
git repository. Because obviously the *actual* default is too hard to
understand ;)

   Linus

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

[Linus Torvalds]

On Wed, Jul 27, 2016 at 8:26 PM, Linus Torvalds
 wrote:
>
> Hmm. Fishy.

Hmm. The exact match logic is a bit odd, and clearly doesn't mean what
I thought it meant. Reading that perl code just makes me more
confused.

I'd actually prefer to make "--git" the default, if you are inside a
git repository. Because obviously the *actual* default is too hard to
understand ;)

   Linus

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

[Joe Perches]

On Wed, 2016-07-27 at 20:26 -0700, Linus Torvalds wrote:
> On Wed, Jul 27, 2016 at 8:21 PM, Joe Perches  wrote:
> > 
> > On Wed, 2016-07-27 at 20:12 -0700, Linus Torvalds wrote:
> > > 
> > > Did you actually try it.
> > yes.
> Well, in that case the script is buggy. It self-documents as having
> "--git-fallback" on by default, and I'm not seeing anybody claiming
> explicit maintenance of fs/binfmt_misc.c.
> 
> Al's match comes from a wildcard, not an exact one.

Nope, the script doesn't have a defect here.
It's documented what the script does with wildcards.

You _could_ argue that the file pattern specified
for VFS is inappropriate though,

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

[Joe Perches]

On Wed, 2016-07-27 at 20:26 -0700, Linus Torvalds wrote:
> On Wed, Jul 27, 2016 at 8:21 PM, Joe Perches  wrote:
> > 
> > On Wed, 2016-07-27 at 20:12 -0700, Linus Torvalds wrote:
> > > 
> > > Did you actually try it.
> > yes.
> Well, in that case the script is buggy. It self-documents as having
> "--git-fallback" on by default, and I'm not seeing anybody claiming
> explicit maintenance of fs/binfmt_misc.c.
> 
> Al's match comes from a wildcard, not an exact one.

Nope, the script doesn't have a defect here.
It's documented what the script does with wildcards.

You _could_ argue that the file pattern specified
for VFS is inappropriate though,

RE: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

[Li, Liang Z]

> Subject: Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate
> process
> 
> On Wed, Jul 27, 2016 at 09:03:21AM -0700, Dave Hansen wrote:
> > On 07/26/2016 06:23 PM, Liang Li wrote:
> > > + vb->pfn_limit = VIRTIO_BALLOON_PFNS_LIMIT;
> > > + vb->pfn_limit = min(vb->pfn_limit, get_max_pfn());
> > > + vb->bmap_len = ALIGN(vb->pfn_limit, BITS_PER_LONG) /
> > > +  BITS_PER_BYTE + 2 * sizeof(unsigned long);
> > > + hdr_len = sizeof(struct balloon_bmap_hdr);
> > > + vb->bmap_hdr = kzalloc(hdr_len + vb->bmap_len, GFP_KERNEL);
> >
> > This ends up doing a 1MB kmalloc() right?  That seems a _bit_ big.
> > How big was the pfn buffer before?
> 
> 
> Yes I would limit this to 1G memory in a go, will result in a 32KByte bitmap.
> 
> --
> MST

Limit to 1G is bad for the performance, I sent you the test result several 
weeks ago.

Paste it bellow:

About the size of page bitmap, I have test the performance of filling the 
balloon to 15GB with a
 16GB RAM VM.

===
32K Byte (cover 1GB of RAM)

Time spends on inflating: 2031ms
-
64K Byte (cover 2GB of RAM)

Time spends on inflating: 1507ms

512K Byte (cover 16GB of RAM)

Time spends on inflating: 1237ms


If possible, a big bitmap is better for performance.

Liang

RE: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

[Li, Liang Z]

> Subject: Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate
> process
> 
> On Wed, Jul 27, 2016 at 09:03:21AM -0700, Dave Hansen wrote:
> > On 07/26/2016 06:23 PM, Liang Li wrote:
> > > + vb->pfn_limit = VIRTIO_BALLOON_PFNS_LIMIT;
> > > + vb->pfn_limit = min(vb->pfn_limit, get_max_pfn());
> > > + vb->bmap_len = ALIGN(vb->pfn_limit, BITS_PER_LONG) /
> > > +  BITS_PER_BYTE + 2 * sizeof(unsigned long);
> > > + hdr_len = sizeof(struct balloon_bmap_hdr);
> > > + vb->bmap_hdr = kzalloc(hdr_len + vb->bmap_len, GFP_KERNEL);
> >
> > This ends up doing a 1MB kmalloc() right?  That seems a _bit_ big.
> > How big was the pfn buffer before?
> 
> 
> Yes I would limit this to 1G memory in a go, will result in a 32KByte bitmap.
> 
> --
> MST

Limit to 1G is bad for the performance, I sent you the test result several 
weeks ago.

Paste it bellow:

About the size of page bitmap, I have test the performance of filling the 
balloon to 15GB with a
 16GB RAM VM.

===
32K Byte (cover 1GB of RAM)

Time spends on inflating: 2031ms
-
64K Byte (cover 2GB of RAM)

Time spends on inflating: 1507ms

512K Byte (cover 16GB of RAM)

Time spends on inflating: 1237ms


If possible, a big bitmap is better for performance.

Liang

Re: [PATCH v1 2/2] drm/bridge: analogix_dp: turn off the panel when eDP need to disable

[Yakir Yang]

Sean,

Oops, sorry about miss your suggest :(

On 07/22/2016 11:03 PM, Sean Paul wrote:

On Thu, Jul 21, 2016 at 9:00 PM, Yakir Yang  wrote:

Sean,

Thanks for your fast respond :-)

But this patch is not the latest one, I have upgraded this to "v1.1" version
to fix the eDP can't be disabled problem:
 [PATCH v1.1 2/2] drm/bridge: analogix_dp: turn off the panel when eDP
need to disable
 Changes in v1.1: - unprepare the panel at the end of
bridge->disable() function

In spite of this, I would take your comments with my "v1.1" patch.

On 07/21/2016 10:28 PM, Sean Paul wrote:

On Thu, Jul 21, 2016 at 9:14 AM, Yakir Yang  wrote:

Some panels (like Sharp LQ123P1JX31) need to be turn off when eDP
controller stop to send valid video signal, otherwhise panel would
go burn in, and keep flicker and flicker.

So it's better to turn off the panel when eDP need to disable, and
we need to turn on the panel in connector->detect() callback, so
that driver would detect panel status rightly.

Signed-off-by: Yakir Yang 
---
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 18 ++
  1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 32715da..ea059b3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -961,6 +961,14 @@ analogix_dp_detect(struct drm_connector *connector,
bool force)
  {
 struct analogix_dp_device *dp = to_dp(connector);

+   /*
+* Panle would prepare for several times here, but don't worry it

s/Panle/Panel/


Done

+* would only enable the hardware at the first prepare time.

Errr, this shouldn't go in detect. How about putting this in
bridge_enable instead?


Nope, if we put this in bridge_enable, then eDP would never be enabled.
Here're the calling flow.

--> analogix_dp_probe
   --> analogix_dp_bind  # we still haven't prepared the panel here, that
means panel have been powered up
 --> analogix_dp_detect  # Oops, losing panel valid hotplug signal, cause
panel have been powered up
 --> ** Keep detecting **


Yeah, after playing around with the patch yesterday I discovered this
for myself. I still don't think detect() should be changing hardware
state. Perhaps you could add a matching unprepare() after you attempt
to detect the panel?


Hmm, I don't understand the meaning of "add a matching unprepare()".

I didn't see there is an unprepare() callback in drm_crtc_helper.h, would
you like to share some simple code :-D

Thanks,
- Yakir


Sean


+*/
+   if (dp->plat_data->panel)
+   if (drm_panel_prepare(dp->plat_data->panel))

Personally, I don't like doing work in a conditional since you're
throwing the return code away. Could you break this out into:

ret = drm_panel_prepare(dp->plat_data->panel);
if (ret)
   DRM_ERROR("failed to setup the panel ret=%d\n", ret);


Okay


+   DRM_ERROR("failed to setup the panel\n");
+
 if (analogix_dp_detect_hpd(dp))
 return connector_status_disconnected;

@@ -1063,7 +1071,8 @@ static void analogix_dp_bridge_disable(struct
drm_bridge *bridge)
 return;

 if (dp->plat_data->panel) {
-   if (drm_panel_disable(dp->plat_data->panel)) {
+   if (drm_panel_disable(dp->plat_data->panel) ||
+   drm_panel_unprepare(dp->plat_data->panel)) {

Same comment here, please break this out into separate statements for
better readability/logging.


Okay,


Thanks,
- Yakir


 DRM_ERROR("failed to disable the panel\n");
 return;
 }
@@ -1333,13 +1342,6 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,

 phy_power_on(dp->phy);

-   if (dp->plat_data->panel) {
-   if (drm_panel_prepare(dp->plat_data->panel)) {
-   DRM_ERROR("failed to setup the panel\n");
-   return -EBUSY;
-   }
-   }
-
 analogix_dp_init_dp(dp);

 ret = devm_request_threaded_irq(>dev, dp->irq,
--
1.9.1

Re: [PATCH v1 2/2] drm/bridge: analogix_dp: turn off the panel when eDP need to disable

[Yakir Yang]

Sean,

Oops, sorry about miss your suggest :(

On 07/22/2016 11:03 PM, Sean Paul wrote:

On Thu, Jul 21, 2016 at 9:00 PM, Yakir Yang  wrote:

Sean,

Thanks for your fast respond :-)

But this patch is not the latest one, I have upgraded this to "v1.1" version
to fix the eDP can't be disabled problem:
 [PATCH v1.1 2/2] drm/bridge: analogix_dp: turn off the panel when eDP
need to disable
 Changes in v1.1: - unprepare the panel at the end of
bridge->disable() function

In spite of this, I would take your comments with my "v1.1" patch.

On 07/21/2016 10:28 PM, Sean Paul wrote:

On Thu, Jul 21, 2016 at 9:14 AM, Yakir Yang  wrote:

Some panels (like Sharp LQ123P1JX31) need to be turn off when eDP
controller stop to send valid video signal, otherwhise panel would
go burn in, and keep flicker and flicker.

So it's better to turn off the panel when eDP need to disable, and
we need to turn on the panel in connector->detect() callback, so
that driver would detect panel status rightly.

Signed-off-by: Yakir Yang 
---
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 18 ++
  1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 32715da..ea059b3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -961,6 +961,14 @@ analogix_dp_detect(struct drm_connector *connector,
bool force)
  {
 struct analogix_dp_device *dp = to_dp(connector);

+   /*
+* Panle would prepare for several times here, but don't worry it

s/Panle/Panel/


Done

+* would only enable the hardware at the first prepare time.

Errr, this shouldn't go in detect. How about putting this in
bridge_enable instead?


Nope, if we put this in bridge_enable, then eDP would never be enabled.
Here're the calling flow.

--> analogix_dp_probe
   --> analogix_dp_bind  # we still haven't prepared the panel here, that
means panel have been powered up
 --> analogix_dp_detect  # Oops, losing panel valid hotplug signal, cause
panel have been powered up
 --> ** Keep detecting **


Yeah, after playing around with the patch yesterday I discovered this
for myself. I still don't think detect() should be changing hardware
state. Perhaps you could add a matching unprepare() after you attempt
to detect the panel?


Hmm, I don't understand the meaning of "add a matching unprepare()".

I didn't see there is an unprepare() callback in drm_crtc_helper.h, would
you like to share some simple code :-D

Thanks,
- Yakir


Sean


+*/
+   if (dp->plat_data->panel)
+   if (drm_panel_prepare(dp->plat_data->panel))

Personally, I don't like doing work in a conditional since you're
throwing the return code away. Could you break this out into:

ret = drm_panel_prepare(dp->plat_data->panel);
if (ret)
   DRM_ERROR("failed to setup the panel ret=%d\n", ret);


Okay


+   DRM_ERROR("failed to setup the panel\n");
+
 if (analogix_dp_detect_hpd(dp))
 return connector_status_disconnected;

@@ -1063,7 +1071,8 @@ static void analogix_dp_bridge_disable(struct
drm_bridge *bridge)
 return;

 if (dp->plat_data->panel) {
-   if (drm_panel_disable(dp->plat_data->panel)) {
+   if (drm_panel_disable(dp->plat_data->panel) ||
+   drm_panel_unprepare(dp->plat_data->panel)) {

Same comment here, please break this out into separate statements for
better readability/logging.


Okay,


Thanks,
- Yakir


 DRM_ERROR("failed to disable the panel\n");
 return;
 }
@@ -1333,13 +1342,6 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,

 phy_power_on(dp->phy);

-   if (dp->plat_data->panel) {
-   if (drm_panel_prepare(dp->plat_data->panel)) {
-   DRM_ERROR("failed to setup the panel\n");
-   return -EBUSY;
-   }
-   }
-
 analogix_dp_init_dp(dp);

 ret = devm_request_threaded_irq(>dev, dp->irq,
--
1.9.1

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

[Linus Torvalds]

On Wed, Jul 27, 2016 at 8:21 PM, Joe Perches  wrote:
> On Wed, 2016-07-27 at 20:12 -0700, Linus Torvalds wrote:
>> Did you actually try it.
>
> yes.

Well, in that case the script is buggy. It self-documents as having
"--git-fallback" on by default, and I'm not seeing anybody claiming
explicit maintenance of fs/binfmt_misc.c.

Al's match comes from a wildcard, not an exact one.

Hmm. Fishy.

 Linus

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

[Linus Torvalds]

On Wed, Jul 27, 2016 at 8:21 PM, Joe Perches  wrote:
> On Wed, 2016-07-27 at 20:12 -0700, Linus Torvalds wrote:
>> Did you actually try it.
>
> yes.

Well, in that case the script is buggy. It self-documents as having
"--git-fallback" on by default, and I'm not seeing anybody claiming
explicit maintenance of fs/binfmt_misc.c.

Al's match comes from a wildcard, not an exact one.

Hmm. Fishy.

 Linus

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

[Joe Perches]

On Wed, 2016-07-27 at 20:12 -0700, Linus Torvalds wrote:
> On Wed, Jul 27, 2016 at 7:57 PM, Joe Perches  wrote:
> > It'll continue to list only Al Viro unless a --git cmdline option
> > is specified and almost no one uses that.
> Did you actually try it.

Sorry about the last reply, typing with a broken arm is a bit difficult.

Yes.  I gather you did not.

The VFS MAINTAINERS entry is:

FILESYSTEMS (VFS and infrastructure)
M:  Alexander Viro 
L:  linux-fsde...@vger.kernel.org
S:  Maintained
F:  fs/*

so that matches this file location.

$ ./scripts/get_maintainer.pl -f fs/binfmt_misc.c 
Alexander Viro  (maintainer:FILESYSTEMS (VFS and 
infrastructure))
linux-fsde...@vger.kernel.org (open list:FILESYSTEMS (VFS and infrastructure))
linux-kernel@vger.kernel.org (open list)
$ ./scripts/get_maintainer.pl -f fs/binfmt_misc.c --git
Alexander Viro  (maintainer:FILESYSTEMS (VFS and 
infrastructure),commit_signer:2/3=67%,authored:2/3=67%,added_lines:10/49=20%,removed_lines:14/16=88%)
James Bottomley  
(commit_signer:1/3=33%,authored:1/3=33%,added_lines:39/49=80%,removed_lines:2/16=12%)
Serge Hallyn  (commit_signer:1/3=33%)
linux-fsde...@vger.kernel.org (open list:FILESYSTEMS (VFS and infrastructure))
linux-kernel@vger.kernel.org (open list)

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

[Joe Perches]

On Wed, 2016-07-27 at 20:12 -0700, Linus Torvalds wrote:
> On Wed, Jul 27, 2016 at 7:57 PM, Joe Perches  wrote:
> > It'll continue to list only Al Viro unless a --git cmdline option
> > is specified and almost no one uses that.
> Did you actually try it.

Sorry about the last reply, typing with a broken arm is a bit difficult.

Yes.  I gather you did not.

The VFS MAINTAINERS entry is:

FILESYSTEMS (VFS and infrastructure)
M:  Alexander Viro 
L:  linux-fsde...@vger.kernel.org
S:  Maintained
F:  fs/*

so that matches this file location.

$ ./scripts/get_maintainer.pl -f fs/binfmt_misc.c 
Alexander Viro  (maintainer:FILESYSTEMS (VFS and 
infrastructure))
linux-fsde...@vger.kernel.org (open list:FILESYSTEMS (VFS and infrastructure))
linux-kernel@vger.kernel.org (open list)
$ ./scripts/get_maintainer.pl -f fs/binfmt_misc.c --git
Alexander Viro  (maintainer:FILESYSTEMS (VFS and 
infrastructure),commit_signer:2/3=67%,authored:2/3=67%,added_lines:10/49=20%,removed_lines:14/16=88%)
James Bottomley  
(commit_signer:1/3=33%,authored:1/3=33%,added_lines:39/49=80%,removed_lines:2/16=12%)
Serge Hallyn  (commit_signer:1/3=33%)
linux-fsde...@vger.kernel.org (open list:FILESYSTEMS (VFS and infrastructure))
linux-kernel@vger.kernel.org (open list)

Re: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe

[Linus Torvalds]

On Wed, Jul 27, 2016 at 6:58 PM, Steven Rostedt  wrote:
> On Wed, 27 Jul 2016 16:00:54 -0700
> Linus Torvalds  wrote:
>>
>> I can just add a
>>
>>   KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)
>
> I like this solution.

Ok. Pushed out. As long as people are aware of this, and are hopefully
at least looking for potential alternatives, it's fine.

I've squashed most of the warnings I see in my allmodconfig build.

The remaining ones are mostly objtool warnings (Josh added to cc: I
get both a "objtool: x86 instruction decoder differs from kernel"
warning, and several new "sibling call from callable instruction with
changed frame pointer" warnings).

There's also a couple of really annoying warnings from gcc:

  drivers/sfi/sfi_core.c:175:53: warning: self-comparison always
evaluates to true [-Wtautological-compare]

which is a classic case of compiler people thinking that "comparing
things to itself is stupid", but it comes from using general-case
macros that then sometimes end up having simple uses where one part of
the comparison ends up being trivially true.

Since the "fix" (to avoid a generic macro helper and use special-case
simpler tests) is likely much worse than what the compiler actually
warns about, I suspect I will be just disabling that silly compiler
warning.

People who love being warned about tautological compares, speak up now
about your preferred alternative, or forever hold your peace. I do
*not* want to have stupid warnings show up by default, because then
people will just ignore the real ones when they pop up. That already
happens much too frequently.

Linus

Re: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe

[Linus Torvalds]

On Wed, Jul 27, 2016 at 6:58 PM, Steven Rostedt  wrote:
> On Wed, 27 Jul 2016 16:00:54 -0700
> Linus Torvalds  wrote:
>>
>> I can just add a
>>
>>   KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)
>
> I like this solution.

Ok. Pushed out. As long as people are aware of this, and are hopefully
at least looking for potential alternatives, it's fine.

I've squashed most of the warnings I see in my allmodconfig build.

The remaining ones are mostly objtool warnings (Josh added to cc: I
get both a "objtool: x86 instruction decoder differs from kernel"
warning, and several new "sibling call from callable instruction with
changed frame pointer" warnings).

There's also a couple of really annoying warnings from gcc:

  drivers/sfi/sfi_core.c:175:53: warning: self-comparison always
evaluates to true [-Wtautological-compare]

which is a classic case of compiler people thinking that "comparing
things to itself is stupid", but it comes from using general-case
macros that then sometimes end up having simple uses where one part of
the comparison ends up being trivially true.

Since the "fix" (to avoid a generic macro helper and use special-case
simpler tests) is likely much worse than what the compiler actually
warns about, I suspect I will be just disabling that silly compiler
warning.

People who love being warned about tautological compares, speak up now
about your preferred alternative, or forever hold your peace. I do
*not* want to have stupid warnings show up by default, because then
people will just ignore the real ones when they pop up. That already
happens much too frequently.

Linus

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

[Joe Perches]

On Wed, 2016-07-27 at 20:12 -0700, Linus Torvalds wrote:
> On Wed, Jul 27, 2016 at 7:57 PM, Joe Perches  wrote:
> > 
> > 
> > It'll continue to list only Al Viro unless a --git cmdline option
> > is specified and almost no one uses that.
> Did you actually try it.

yes.
$ ./scripts/get_maintainer.pl -f fs/binfmt_misc.c 
Alexander Viro  (maintainer:FILESYSTEMS (VFS
and infrastructure))
linux-fsde...@vger.kernel.org (open list:FILESYSTEMS (VFS and
infrastructure))
linux-kernel@vger.kernel.org (open list)
joe@XPS-9350:~/linux/next$ ./scripts/get_maintainer.pl -f
fs/binfmt_misc.c --git
Alexander Viro  (maintainer:FILESYSTEMS (VFS
and
infrastructure),commit_signer:2/3=67%,authored:2/3=67%,added_lines:10/49
=20%,removed_lines:14/16=88%)
James Bottomley 
(commit_signer:1/3=33%,authored:1/3=33%,added_lines:39/49=80%,removed_li
nes:2/16=12%)
Serge Hallyn  (commit_signer:1/3=33%)
linux-fsde...@vger.kernel.org (open list:FILESYSTEMS (VFS and
infrastructure))
linux-kernel@vger.kernel.org (open list)

> The get_maintainer.pl script should use "--git-fallback" by default,
> so in the absence of a an exact match (which it won't have) it _will_
> in fact pick out recent git authorship.
> 
> (Where "recent" means "in the last year" by default).
> 
> I depend that recent authorship matching quite a lot. In fact, I think
> the reason nobody uses "--git" is that the default "--git-fallback" is
> sufficient most of the time.
> 
> Linus

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

[Joe Perches]

On Wed, 2016-07-27 at 20:12 -0700, Linus Torvalds wrote:
> On Wed, Jul 27, 2016 at 7:57 PM, Joe Perches  wrote:
> > 
> > 
> > It'll continue to list only Al Viro unless a --git cmdline option
> > is specified and almost no one uses that.
> Did you actually try it.

yes.
$ ./scripts/get_maintainer.pl -f fs/binfmt_misc.c 
Alexander Viro  (maintainer:FILESYSTEMS (VFS
and infrastructure))
linux-fsde...@vger.kernel.org (open list:FILESYSTEMS (VFS and
infrastructure))
linux-kernel@vger.kernel.org (open list)
joe@XPS-9350:~/linux/next$ ./scripts/get_maintainer.pl -f
fs/binfmt_misc.c --git
Alexander Viro  (maintainer:FILESYSTEMS (VFS
and
infrastructure),commit_signer:2/3=67%,authored:2/3=67%,added_lines:10/49
=20%,removed_lines:14/16=88%)
James Bottomley 
(commit_signer:1/3=33%,authored:1/3=33%,added_lines:39/49=80%,removed_li
nes:2/16=12%)
Serge Hallyn  (commit_signer:1/3=33%)
linux-fsde...@vger.kernel.org (open list:FILESYSTEMS (VFS and
infrastructure))
linux-kernel@vger.kernel.org (open list)

> The get_maintainer.pl script should use "--git-fallback" by default,
> so in the absence of a an exact match (which it won't have) it _will_
> in fact pick out recent git authorship.
> 
> (Where "recent" means "in the last year" by default).
> 
> I depend that recent authorship matching quite a lot. In fact, I think
> the reason nobody uses "--git" is that the default "--git-fallback" is
> sufficient most of the time.
> 
> Linus