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

[James Liao]

On Mon, 2016-07-11 at 16:24 +0800, James Liao wrote:
> Hi Mike,
> 
> On Fri, 2016-07-08 at 16:32 -0700, Michael Turquette wrote:
> > Hi James,
> > 
> > Quoting James Liao (2016-07-03 20:51:48)
> > > On Fri, 2016-07-01 at 18:21 -0700, Stephen Boyd wrote:
> > > > (Resending to everyone)
> > > > 
> > > > On 06/22, Erin Lo wrote:
> > > > > From: James Liao 
> > > > > 
> > > > > This patch fixed wrong state of parent clocks if they are registered
> > > > > after critical clocks.
> > > > > 
> > > > > Signed-off-by: James Liao 
> > > > > Signed-off-by: Erin Lo 
> > > > 
> > > > It would be nice if you included the information about the
> > > > problem from James' previous mail. This says what it does, but
> > > > doesn't explain what the problem is and how it is fixing it.
> > > > 
> > > > > ---
> > > > >  drivers/clk/clk.c | 9 -
> > > > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > > > > index d584004..e9f5f89 100644
> > > > > --- a/drivers/clk/clk.c
> > > > > +++ b/drivers/clk/clk.c
> > > > > @@ -2388,8 +2388,15 @@ static int __clk_core_init(struct clk_core 
> > > > > *core)
> > > > > hlist_for_each_entry_safe(orphan, tmp2, _orphan_list, 
> > > > > child_node) {
> > > > > struct clk_core *parent = __clk_init_parent(orphan);
> > > > >  
> > > > > -   if (parent)
> > > > > +   if (parent) {
> > > > > clk_core_reparent(orphan, parent);
> > > > > +
> > > > > +   if (orphan->prepare_count)
> > > > > +   clk_core_prepare(parent);
> > > > > +
> > > > > +   if (orphan->enable_count)
> > > > > +   clk_core_enable(parent);
> > > > > +   }
> > > > > }
> > > > 
> > > > I'm pretty sure I pointed this problem out to Mike when the
> > > > critical clk patches were being pushed. I can't recall what the
> > > > plan was though to fix the problem. I'm pretty sure he said that
> > > > clk_core_reparent() would take care of it, but obviously it is
> > > > not doing that. Or perhaps it was that clk handoff should figure
> > > > out that the parents of a critical clk are also on and thus keep
> > > > them on.
> > > 
> > > Hi Mike
> > > 
> > > Is there any other patch to fix this issue? Or did I misuse critical
> > > clock flag?
> > 
> > There is no fix yes. Your fix is basically correct. I was mistaken back
> > when I told you and Stephen that the framework already took care of
> > this.
> > 
> > However, instead of "open coding" this solution, I would rather re-use
> > the __clk_set_parent_{before,after} helpers instead. Can you review/test
> > the following patch and let me know what you think?
> > 
> > Thanks,
> > Mike
> > 
> > 
> > 
> > From c0163b3f719b1e219b28ad425f94f9ef54a25a8f Mon Sep 17 00:00:00 2001
> > From: Michael Turquette 
> > Date: Fri, 8 Jul 2016 16:05:22 -0700
> > Subject: [PATCH] clk: migrate ref counts when orphans are reunited
> > 
> > It's always nice to see families reunited, and this is equally true when
> > talking about parent clocks and their children. However, if the orphan
> > clk had a positive prepare_count or enable_count, then we would not
> > migrate those counts up the parent chain correctly.
> > 
> > This has manifested with the recent critical clocks feature, which often
> > enables clocks very early, before their parents have been registered.
> > 
> > Fixed by replacing the call to clk_core_reparent with calls to
> > __clk_set_parent_{before,after}.
> > 
> > Cc: James Liao 
> > Cc: Erin Lo 
> > Signed-off-by: Michael Turquette 
> > ---
> >  drivers/clk/clk.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index 820a939fb6bb..70efe4c4e0cc 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -2449,8 +2449,14 @@ static int __clk_core_init(struct clk_core *core)
> > hlist_for_each_entry_safe(orphan, tmp2, _orphan_list, child_node) {
> > struct clk_core *parent = __clk_init_parent(orphan);
> >  
> > -   if (parent)
> > -   clk_core_reparent(orphan, parent);
> 
> Is it correct to remove clk_core_reparent()? It lacks
> __clk_recalc_accuracies() and __clk_recalc_rates(), so the new parent's
> rate will not propagate correctly.
> 
> For example, I set vdec_sel as a critical clock. Without your patch, the
> result was:
> 
> vdecpll 00   33800
>vdecpll_ck   11   33800
>   vdec_sel  11   33800
> 
> With your patch, it became:
> 
> vdecpll 11   33800
>vdecpll_ck   11   0
>   vdec_sel  11   0
> 
> The 

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

[James Liao]

On Mon, 2016-07-11 at 16:24 +0800, James Liao wrote:
> Hi Mike,
> 
> On Fri, 2016-07-08 at 16:32 -0700, Michael Turquette wrote:
> > Hi James,
> > 
> > Quoting James Liao (2016-07-03 20:51:48)
> > > On Fri, 2016-07-01 at 18:21 -0700, Stephen Boyd wrote:
> > > > (Resending to everyone)
> > > > 
> > > > On 06/22, Erin Lo wrote:
> > > > > From: James Liao 
> > > > > 
> > > > > This patch fixed wrong state of parent clocks if they are registered
> > > > > after critical clocks.
> > > > > 
> > > > > Signed-off-by: James Liao 
> > > > > Signed-off-by: Erin Lo 
> > > > 
> > > > It would be nice if you included the information about the
> > > > problem from James' previous mail. This says what it does, but
> > > > doesn't explain what the problem is and how it is fixing it.
> > > > 
> > > > > ---
> > > > >  drivers/clk/clk.c | 9 -
> > > > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > > > > index d584004..e9f5f89 100644
> > > > > --- a/drivers/clk/clk.c
> > > > > +++ b/drivers/clk/clk.c
> > > > > @@ -2388,8 +2388,15 @@ static int __clk_core_init(struct clk_core 
> > > > > *core)
> > > > > hlist_for_each_entry_safe(orphan, tmp2, _orphan_list, 
> > > > > child_node) {
> > > > > struct clk_core *parent = __clk_init_parent(orphan);
> > > > >  
> > > > > -   if (parent)
> > > > > +   if (parent) {
> > > > > clk_core_reparent(orphan, parent);
> > > > > +
> > > > > +   if (orphan->prepare_count)
> > > > > +   clk_core_prepare(parent);
> > > > > +
> > > > > +   if (orphan->enable_count)
> > > > > +   clk_core_enable(parent);
> > > > > +   }
> > > > > }
> > > > 
> > > > I'm pretty sure I pointed this problem out to Mike when the
> > > > critical clk patches were being pushed. I can't recall what the
> > > > plan was though to fix the problem. I'm pretty sure he said that
> > > > clk_core_reparent() would take care of it, but obviously it is
> > > > not doing that. Or perhaps it was that clk handoff should figure
> > > > out that the parents of a critical clk are also on and thus keep
> > > > them on.
> > > 
> > > Hi Mike
> > > 
> > > Is there any other patch to fix this issue? Or did I misuse critical
> > > clock flag?
> > 
> > There is no fix yes. Your fix is basically correct. I was mistaken back
> > when I told you and Stephen that the framework already took care of
> > this.
> > 
> > However, instead of "open coding" this solution, I would rather re-use
> > the __clk_set_parent_{before,after} helpers instead. Can you review/test
> > the following patch and let me know what you think?
> > 
> > Thanks,
> > Mike
> > 
> > 
> > 
> > From c0163b3f719b1e219b28ad425f94f9ef54a25a8f Mon Sep 17 00:00:00 2001
> > From: Michael Turquette 
> > Date: Fri, 8 Jul 2016 16:05:22 -0700
> > Subject: [PATCH] clk: migrate ref counts when orphans are reunited
> > 
> > It's always nice to see families reunited, and this is equally true when
> > talking about parent clocks and their children. However, if the orphan
> > clk had a positive prepare_count or enable_count, then we would not
> > migrate those counts up the parent chain correctly.
> > 
> > This has manifested with the recent critical clocks feature, which often
> > enables clocks very early, before their parents have been registered.
> > 
> > Fixed by replacing the call to clk_core_reparent with calls to
> > __clk_set_parent_{before,after}.
> > 
> > Cc: James Liao 
> > Cc: Erin Lo 
> > Signed-off-by: Michael Turquette 
> > ---
> >  drivers/clk/clk.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index 820a939fb6bb..70efe4c4e0cc 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -2449,8 +2449,14 @@ static int __clk_core_init(struct clk_core *core)
> > hlist_for_each_entry_safe(orphan, tmp2, _orphan_list, child_node) {
> > struct clk_core *parent = __clk_init_parent(orphan);
> >  
> > -   if (parent)
> > -   clk_core_reparent(orphan, parent);
> 
> Is it correct to remove clk_core_reparent()? It lacks
> __clk_recalc_accuracies() and __clk_recalc_rates(), so the new parent's
> rate will not propagate correctly.
> 
> For example, I set vdec_sel as a critical clock. Without your patch, the
> result was:
> 
> vdecpll 00   33800
>vdecpll_ck   11   33800
>   vdec_sel  11   33800
> 
> With your patch, it became:
> 
> vdecpll 11   33800
>vdecpll_ck   11   0
>   vdec_sel  11   0
> 
> The prepare_count and enable_count are correct with your patch, but the
> rates of vdecpll_ck and vdec_sel become incorrect.
> 
> 
> Best regards,
> 
> James
> 
> > +   /*
> > + 

Re: [PATCH] mips: lantiq: fix irq_chip name to not land in new parent field

[Ralf Baechle]

On Tue, Aug 02, 2016 at 02:54:47PM -0400, Paul Gortmaker wrote:

> As of commit be45beb2df69 ("genirq: Add runtime power management
> support for IRQ chips") the irq_chip struct got a struct *device
> parent_device field added to it.  However, it was added at the
> beginning of the struct, which previously was the "name" entry.
> 
> The driver here was using a mix of ordered struct init entries and
> named init entries.  It was supplying the name assuming it was the 1st
> in the order, and hence when that became a struct *device we get:
> 
> arch/mips/lantiq/irq.c:209:2: warning: initialization from incompatible 
> pointer type [enabled by default]
> arch/mips/lantiq/irq.c:209:2: warning: (near initialization for 
> 'ltq_irq_type.parent_device') [enabled by default]
> arch/mips/lantiq/irq.c:219:2: warning: initialization from incompatible 
> pointer type [enabled by default]
> arch/mips/lantiq/irq.c:219:2: warning: (near initialization for 
> 'ltq_eiu_type.parent_device') [enabled by default]
> 
> While not runtime tested, I can't imagine trying to dereference a
> a struct device field from a char string will end well.
> 
> Here we've used named element init entries for the name string as well
> to fix it.
> 
> Fixes: be45beb2df69 ("genirq: Add runtime power management support for IRQ 
> chips")
> Cc: Jon Hunter 
> Cc: Kevin Hilman 
> Cc: Marc Zyngier 
> Cc: John Crispin 
> Cc: Ralf Baechle 
> Cc: Thomas Gleixner 
> Cc: linux-m...@linux-mips.org
> Signed-off-by: Paul Gortmaker 

Thanks for the patch but I've already applied the identical patch
https://patchwork.linux-mips.org/patch/13684/.

  Ralf

Re: [PATCH] mips: lantiq: fix irq_chip name to not land in new parent field

[Ralf Baechle]

On Tue, Aug 02, 2016 at 02:54:47PM -0400, Paul Gortmaker wrote:

> As of commit be45beb2df69 ("genirq: Add runtime power management
> support for IRQ chips") the irq_chip struct got a struct *device
> parent_device field added to it.  However, it was added at the
> beginning of the struct, which previously was the "name" entry.
> 
> The driver here was using a mix of ordered struct init entries and
> named init entries.  It was supplying the name assuming it was the 1st
> in the order, and hence when that became a struct *device we get:
> 
> arch/mips/lantiq/irq.c:209:2: warning: initialization from incompatible 
> pointer type [enabled by default]
> arch/mips/lantiq/irq.c:209:2: warning: (near initialization for 
> 'ltq_irq_type.parent_device') [enabled by default]
> arch/mips/lantiq/irq.c:219:2: warning: initialization from incompatible 
> pointer type [enabled by default]
> arch/mips/lantiq/irq.c:219:2: warning: (near initialization for 
> 'ltq_eiu_type.parent_device') [enabled by default]
> 
> While not runtime tested, I can't imagine trying to dereference a
> a struct device field from a char string will end well.
> 
> Here we've used named element init entries for the name string as well
> to fix it.
> 
> Fixes: be45beb2df69 ("genirq: Add runtime power management support for IRQ 
> chips")
> Cc: Jon Hunter 
> Cc: Kevin Hilman 
> Cc: Marc Zyngier 
> Cc: John Crispin 
> Cc: Ralf Baechle 
> Cc: Thomas Gleixner 
> Cc: linux-m...@linux-mips.org
> Signed-off-by: Paul Gortmaker 

Thanks for the patch but I've already applied the identical patch
https://patchwork.linux-mips.org/patch/13684/.

  Ralf

Re: [PATCH] raid5: fix incorrectly counter of conf->empty_inactive_list_nr

[liuzhengyuan]

Thanks for you replay.
I think it may be on the temp inactive list. An active sh was handled
and put to temp inactive list firstly, then moved to inactive list.
If sh is on the temp inactive list,  sh->count is zero too.

-- Original --
From:  "NeilBrown";
Date:  Wed, Aug 3, 2016 08:44 AM
To:  "ZhengYuan Liu";
Cc:  "shli"; "liuzhengyuang521"; 
"linux-raid"; 
"linux-kernel"; "ZhengYuan 
Liu";
Subject:  Re: [PATCH] raid5: fix incorrectly counter of 
conf->empty_inactive_list_nr
 
On Thu, Jul 28 2016, ZhengYuan Liu wrote:

> The counter conf->empty_inactive_list_nr is only used for determine if the
> raid5 is congested which is deal with in function raid5_congested().
> It was increased in get_free_stripe() when conf->inactive_list got to be
> empty and decreased in release_inactive_stripe_list() when splice
> temp_inactive_list to conf->inactive_list. However, this may have a
> problem when raid5_get_active_stripe or stripe_add_to_batch_list was called,
> because these two functions may call list_del_init(>lru) to delete sh from
> "conf->inactive_list + hash" which may cause "conf->inactive_list + hash" to
> be empty when atomic_inc_not_zero(>count) got false. So a check should be
> done at these two point and increase empty_inactive_list_nr accordingly.
> Otherwise the counter may get to be negative number which would influence
> async readahead from VFS.
>
> Signed-off-by: ZhengYuan Liu 
> ---
>  drivers/md/raid5.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 7c53861..1656c44 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -659,6 +659,7 @@ raid5_get_active_stripe(struct r5conf *conf, sector_t 
> sector,
>  {
>  struct stripe_head *sh;
>  int hash = stripe_hash_locks_hash(sector);
> + int inc_empty_inactive_list_flag;
>  
>  pr_debug("get_stripe, sector %llu\n", (unsigned long long)sector);
>  
> @@ -703,7 +704,12 @@ raid5_get_active_stripe(struct r5conf *conf, sector_t 
> sector,
>  atomic_inc(>active_stripes);
>  BUG_ON(list_empty(>lru) &&
> !test_bit(STRIPE_EXPANDING, >state));
> + inc_empty_inactive_list_flag = 0;
> + if (!list_empty(conf->inactive_list + hash))
> + inc_empty_inactive_list_flag = 1;
>  list_del_init(>lru);
> + if (list_empty(conf->inactive_list + hash) && 
> inc_empty_inactive_list_flag)
> + atomic_inc(>empty_inactive_list_nr);

Maybe I'm forgetting an important detail, but this seems more
complicated than it needs to be.
The code just just confirmed that sh->count is zero, so sh must be on
the inactive list, mustn't it?
So inc_empty_inactive_list_flag can never be set to 1.

What am I missing?  Could sh not be on the inactive list at this point?

Same for the code below.

NeilBrown


>  if (sh->group) {
>  sh->group->stripes_cnt--;
>  sh->group = NULL;
> @@ -762,6 +768,7 @@ static void stripe_add_to_batch_list(struct r5conf *conf, 
> struct stripe_head *sh
>  sector_t head_sector, tmp_sec;
>  int hash;
>  int dd_idx;
> + int inc_empty_inactive_list_flag;
>  
>  if (!stripe_can_batch(sh))
>  return;
> @@ -781,7 +788,11 @@ static void stripe_add_to_batch_list(struct r5conf 
> *conf, struct stripe_head *sh
>  atomic_inc(>active_stripes);
>  BUG_ON(list_empty(>lru) &&
> !test_bit(STRIPE_EXPANDING, >state));
> + if (!list_empty(conf->inactive_list + hash))
> + inc_empty_inactive_list_flag = 1;
>  list_del_init(>lru);
> + if (list_empty(conf->inactive_list + hash) && 
> inc_empty_inactive_list_flag)
> + atomic_inc(>empty_inactive_list_nr);
>  if (head->group) {
>  head->group->stripes_cnt--;
>  head->group = NULL;
> -- 
> 1.9.1

Re: [PATCH] raid5: fix incorrectly counter of conf->empty_inactive_list_nr

[liuzhengyuan]

Thanks for you replay.
I think it may be on the temp inactive list. An active sh was handled
and put to temp inactive list firstly, then moved to inactive list.
If sh is on the temp inactive list,  sh->count is zero too.

-- Original --
From:  "NeilBrown";
Date:  Wed, Aug 3, 2016 08:44 AM
To:  "ZhengYuan Liu";
Cc:  "shli"; "liuzhengyuang521"; 
"linux-raid"; 
"linux-kernel"; "ZhengYuan 
Liu";
Subject:  Re: [PATCH] raid5: fix incorrectly counter of 
conf->empty_inactive_list_nr
 
On Thu, Jul 28 2016, ZhengYuan Liu wrote:

> The counter conf->empty_inactive_list_nr is only used for determine if the
> raid5 is congested which is deal with in function raid5_congested().
> It was increased in get_free_stripe() when conf->inactive_list got to be
> empty and decreased in release_inactive_stripe_list() when splice
> temp_inactive_list to conf->inactive_list. However, this may have a
> problem when raid5_get_active_stripe or stripe_add_to_batch_list was called,
> because these two functions may call list_del_init(>lru) to delete sh from
> "conf->inactive_list + hash" which may cause "conf->inactive_list + hash" to
> be empty when atomic_inc_not_zero(>count) got false. So a check should be
> done at these two point and increase empty_inactive_list_nr accordingly.
> Otherwise the counter may get to be negative number which would influence
> async readahead from VFS.
>
> Signed-off-by: ZhengYuan Liu 
> ---
>  drivers/md/raid5.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 7c53861..1656c44 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -659,6 +659,7 @@ raid5_get_active_stripe(struct r5conf *conf, sector_t 
> sector,
>  {
>  struct stripe_head *sh;
>  int hash = stripe_hash_locks_hash(sector);
> + int inc_empty_inactive_list_flag;
>  
>  pr_debug("get_stripe, sector %llu\n", (unsigned long long)sector);
>  
> @@ -703,7 +704,12 @@ raid5_get_active_stripe(struct r5conf *conf, sector_t 
> sector,
>  atomic_inc(>active_stripes);
>  BUG_ON(list_empty(>lru) &&
> !test_bit(STRIPE_EXPANDING, >state));
> + inc_empty_inactive_list_flag = 0;
> + if (!list_empty(conf->inactive_list + hash))
> + inc_empty_inactive_list_flag = 1;
>  list_del_init(>lru);
> + if (list_empty(conf->inactive_list + hash) && 
> inc_empty_inactive_list_flag)
> + atomic_inc(>empty_inactive_list_nr);

Maybe I'm forgetting an important detail, but this seems more
complicated than it needs to be.
The code just just confirmed that sh->count is zero, so sh must be on
the inactive list, mustn't it?
So inc_empty_inactive_list_flag can never be set to 1.

What am I missing?  Could sh not be on the inactive list at this point?

Same for the code below.

NeilBrown


>  if (sh->group) {
>  sh->group->stripes_cnt--;
>  sh->group = NULL;
> @@ -762,6 +768,7 @@ static void stripe_add_to_batch_list(struct r5conf *conf, 
> struct stripe_head *sh
>  sector_t head_sector, tmp_sec;
>  int hash;
>  int dd_idx;
> + int inc_empty_inactive_list_flag;
>  
>  if (!stripe_can_batch(sh))
>  return;
> @@ -781,7 +788,11 @@ static void stripe_add_to_batch_list(struct r5conf 
> *conf, struct stripe_head *sh
>  atomic_inc(>active_stripes);
>  BUG_ON(list_empty(>lru) &&
> !test_bit(STRIPE_EXPANDING, >state));
> + if (!list_empty(conf->inactive_list + hash))
> + inc_empty_inactive_list_flag = 1;
>  list_del_init(>lru);
> + if (list_empty(conf->inactive_list + hash) && 
> inc_empty_inactive_list_flag)
> + atomic_inc(>empty_inactive_list_nr);
>  if (head->group) {
>  head->group->stripes_cnt--;
>  head->group = NULL;
> -- 
> 1.9.1

Re: ARC stable backport request

[Greg KH]

On Tue, Aug 02, 2016 at 09:45:56AM +0200, Jiri Slaby wrote:
> On 08/02/2016, 09:00 AM, Greg KH wrote:
> > On Wed, May 25, 2016 at 05:13:31PM +0530, Vineet Gupta wrote:
> >> Hi,
> >>
> >> Can we please backport a6416f57ce57fb390b "ARC: use ASL assembler 
> >> mnemonic".
> >> Newer binutils don't like ASL instruction and fail to build kernels prior 
> >> to v4.4
> >> which added this fix.
> > 
> > Didn't apply to 3.14-stable :(
> 
> I have a backport in 3.12. There was a conflict in comments. Could you
> try that?
> 
> commit fa5d506592a759b7848a59d1d5a025af8c9a7a6c
> Author: Vineet Gupta 
> Date:   Thu Nov 5 09:13:31 2015 +0530
> 
> ARC: use ASL assembler mnemonic
> 
> commit a6416f57ce57fb390b6ee30b12c01c29032a26af upstream.
> 
> ARCompact and ARCv2 only have ASL, while binutils used to support LSL as
> a alias mnemonic.
> 
> Newer binutils (upstream) don't want to do that so replace it.
> 
> Signed-off-by: Vineet Gupta 
> Signed-off-by: Jiri Slaby 

Ah, that worked, thanks, now applied.

greg k-h

Re: ARC stable backport request

[Greg KH]

On Tue, Aug 02, 2016 at 09:45:56AM +0200, Jiri Slaby wrote:
> On 08/02/2016, 09:00 AM, Greg KH wrote:
> > On Wed, May 25, 2016 at 05:13:31PM +0530, Vineet Gupta wrote:
> >> Hi,
> >>
> >> Can we please backport a6416f57ce57fb390b "ARC: use ASL assembler 
> >> mnemonic".
> >> Newer binutils don't like ASL instruction and fail to build kernels prior 
> >> to v4.4
> >> which added this fix.
> > 
> > Didn't apply to 3.14-stable :(
> 
> I have a backport in 3.12. There was a conflict in comments. Could you
> try that?
> 
> commit fa5d506592a759b7848a59d1d5a025af8c9a7a6c
> Author: Vineet Gupta 
> Date:   Thu Nov 5 09:13:31 2015 +0530
> 
> ARC: use ASL assembler mnemonic
> 
> commit a6416f57ce57fb390b6ee30b12c01c29032a26af upstream.
> 
> ARCompact and ARCv2 only have ASL, while binutils used to support LSL as
> a alias mnemonic.
> 
> Newer binutils (upstream) don't want to do that so replace it.
> 
> Signed-off-by: Vineet Gupta 
> Signed-off-by: Jiri Slaby 

Ah, that worked, thanks, now applied.

greg k-h

[PATCH v2 3/3] mm: memcontrol: add sanity checks for memcg->id.ref on get/put

[Vladimir Davydov]

Signed-off-by: Vladimir Davydov 
---
 mm/memcontrol.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 67109d556a4a..32b2f33865f9 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4033,6 +4033,7 @@ static DEFINE_IDR(mem_cgroup_idr);
 
 static void mem_cgroup_id_get_many(struct mem_cgroup *memcg, unsigned int n)
 {
+   VM_BUG_ON(atomic_read(>id.ref) <= 0);
atomic_add(n, >id.ref);
 }
 
@@ -4056,6 +4057,7 @@ static struct mem_cgroup *mem_cgroup_id_get_active(struct 
mem_cgroup *memcg)
 
 static void mem_cgroup_id_put_many(struct mem_cgroup *memcg, unsigned int n)
 {
+   VM_BUG_ON(atomic_read(>id.ref) < n);
if (atomic_sub_and_test(n, >id.ref)) {
idr_remove(_cgroup_idr, memcg->id.id);
memcg->id.id = 0;
@@ -4176,6 +4178,7 @@ static struct mem_cgroup *mem_cgroup_alloc(void)
INIT_LIST_HEAD(>cgwb_list);
 #endif
idr_replace(_cgroup_idr, memcg, memcg->id.id);
+   atomic_set(>id.ref, 1);
return memcg;
 fail:
if (memcg->id.id > 0)
@@ -4245,7 +4248,6 @@ fail:
 static int mem_cgroup_css_online(struct cgroup_subsys_state *css)
 {
/* Online state pins memcg ID, memcg ID pins CSS */
-   mem_cgroup_id_get(mem_cgroup_from_css(css));
css_get(css);
return 0;
 }
-- 
2.1.4

[PATCH v2 3/3] mm: memcontrol: add sanity checks for memcg->id.ref on get/put

[Vladimir Davydov]

Signed-off-by: Vladimir Davydov 
---
 mm/memcontrol.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 67109d556a4a..32b2f33865f9 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4033,6 +4033,7 @@ static DEFINE_IDR(mem_cgroup_idr);
 
 static void mem_cgroup_id_get_many(struct mem_cgroup *memcg, unsigned int n)
 {
+   VM_BUG_ON(atomic_read(>id.ref) <= 0);
atomic_add(n, >id.ref);
 }
 
@@ -4056,6 +4057,7 @@ static struct mem_cgroup *mem_cgroup_id_get_active(struct 
mem_cgroup *memcg)
 
 static void mem_cgroup_id_put_many(struct mem_cgroup *memcg, unsigned int n)
 {
+   VM_BUG_ON(atomic_read(>id.ref) < n);
if (atomic_sub_and_test(n, >id.ref)) {
idr_remove(_cgroup_idr, memcg->id.id);
memcg->id.id = 0;
@@ -4176,6 +4178,7 @@ static struct mem_cgroup *mem_cgroup_alloc(void)
INIT_LIST_HEAD(>cgwb_list);
 #endif
idr_replace(_cgroup_idr, memcg, memcg->id.id);
+   atomic_set(>id.ref, 1);
return memcg;
 fail:
if (memcg->id.id > 0)
@@ -4245,7 +4248,6 @@ fail:
 static int mem_cgroup_css_online(struct cgroup_subsys_state *css)
 {
/* Online state pins memcg ID, memcg ID pins CSS */
-   mem_cgroup_id_get(mem_cgroup_from_css(css));
css_get(css);
return 0;
 }
-- 
2.1.4

[PATCH] lkdtm: Mark lkdtm_rodata_do_nothing() notrace

[Michael Ellerman]

lkdtm_rodata_do_nothing() is an empty function which is generated in
order to test the non-executability of rodata.

Currently if function tracing is enabled then an mcount callsite will be
generated for lkdtm_rodata_do_nothing(), and it will appear in the list
of available functions for function tracing (available_filter_functions).

Given it's purpose purely as a test function, it seems preferable for
lkdtm_rodata_do_nothing() to be marked notrace, so it doesn't appear as
traceable.

This also avoids triggering a linker bug on powerpc:

  https://sourceware.org/bugzilla/show_bug.cgi?id=20428

When the linker sees code that needs to generate a call stub, eg. a
branch to mcount(), it assumes the section is executable and
dereferences a NULL pointer leading to a linker segfault. Marking
lkdtm_rodata_do_nothing() notrace avoids triggering the bug because the
function contains no other function calls.

Signed-off-by: Michael Ellerman 
---
 drivers/misc/lkdtm_rodata.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/lkdtm_rodata.c b/drivers/misc/lkdtm_rodata.c
index 166b1db3969f..3564477b8c2d 100644
--- a/drivers/misc/lkdtm_rodata.c
+++ b/drivers/misc/lkdtm_rodata.c
@@ -4,7 +4,7 @@
  */
 #include "lkdtm.h"
 
-void lkdtm_rodata_do_nothing(void)
+void notrace lkdtm_rodata_do_nothing(void)
 {
/* Does nothing. We just want an architecture agnostic "return". */
 }
-- 
2.7.4

[PATCH] lkdtm: Mark lkdtm_rodata_do_nothing() notrace

[Michael Ellerman]

lkdtm_rodata_do_nothing() is an empty function which is generated in
order to test the non-executability of rodata.

Currently if function tracing is enabled then an mcount callsite will be
generated for lkdtm_rodata_do_nothing(), and it will appear in the list
of available functions for function tracing (available_filter_functions).

Given it's purpose purely as a test function, it seems preferable for
lkdtm_rodata_do_nothing() to be marked notrace, so it doesn't appear as
traceable.

This also avoids triggering a linker bug on powerpc:

  https://sourceware.org/bugzilla/show_bug.cgi?id=20428

When the linker sees code that needs to generate a call stub, eg. a
branch to mcount(), it assumes the section is executable and
dereferences a NULL pointer leading to a linker segfault. Marking
lkdtm_rodata_do_nothing() notrace avoids triggering the bug because the
function contains no other function calls.

Signed-off-by: Michael Ellerman 
---
 drivers/misc/lkdtm_rodata.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/lkdtm_rodata.c b/drivers/misc/lkdtm_rodata.c
index 166b1db3969f..3564477b8c2d 100644
--- a/drivers/misc/lkdtm_rodata.c
+++ b/drivers/misc/lkdtm_rodata.c
@@ -4,7 +4,7 @@
  */
 #include "lkdtm.h"
 
-void lkdtm_rodata_do_nothing(void)
+void notrace lkdtm_rodata_do_nothing(void)
 {
/* Does nothing. We just want an architecture agnostic "return". */
 }
-- 
2.7.4

Re: [kernel-hardening] Re: Linker segfault on powerpc when CONFIG_LKDTM=y (was Re: [kernel-hardening] [PATCH 3/5] lkdtm: add function for testing .rodata section)

[Michael Ellerman]

Kees Cook  writes:
> On Mon, Aug 1, 2016 at 8:12 PM, Michael Ellerman  wrote:
>> Kees Cook  writes:
>>> On Mon, Aug 1, 2016 at 5:37 AM, Michael Ellerman  
>>> wrote:

   scripts/link-vmlinux.sh: line 52: 36260 Segmentation fault  (core 
 dumped) ${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} -T ${lds} 
 ${KBUILD_VMLINUX_INIT} --start-group ${KBUILD_VMLINUX_MAIN} --end-group 
 ${1}

 Haven't had a chance to debug it further.
...
>> Interestingly I *can't* reproduce with the Ubuntu x86->ppc cross
>> (5.4.0-6ubuntu1~16.04.1).
>
> Oh, weird. Well, that does explains my lack of hitting the problem,
> though: that's the cross compiler I was using. :P

Actually that was a false negative.

The trick is you have to have LKDTM=y *and* FUNCTION_TRACER=y.

It is a linker bug:

  https://sourceware.org/bugzilla/show_bug.cgi?id=20428

Which Alan has already fixed.

But we need to workaround existing linkers that are out there.

We can do that by marking lkdtm_rodata_do_nothing() notrace, which I
think makes sense for all arches actually.

So I'll send you a patch to do that.

cheers

Re: [kernel-hardening] Re: Linker segfault on powerpc when CONFIG_LKDTM=y (was Re: [kernel-hardening] [PATCH 3/5] lkdtm: add function for testing .rodata section)

[Michael Ellerman]

Kees Cook  writes:
> On Mon, Aug 1, 2016 at 8:12 PM, Michael Ellerman  wrote:
>> Kees Cook  writes:
>>> On Mon, Aug 1, 2016 at 5:37 AM, Michael Ellerman  
>>> wrote:

   scripts/link-vmlinux.sh: line 52: 36260 Segmentation fault  (core 
 dumped) ${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} -T ${lds} 
 ${KBUILD_VMLINUX_INIT} --start-group ${KBUILD_VMLINUX_MAIN} --end-group 
 ${1}

 Haven't had a chance to debug it further.
...
>> Interestingly I *can't* reproduce with the Ubuntu x86->ppc cross
>> (5.4.0-6ubuntu1~16.04.1).
>
> Oh, weird. Well, that does explains my lack of hitting the problem,
> though: that's the cross compiler I was using. :P

Actually that was a false negative.

The trick is you have to have LKDTM=y *and* FUNCTION_TRACER=y.

It is a linker bug:

  https://sourceware.org/bugzilla/show_bug.cgi?id=20428

Which Alan has already fixed.

But we need to workaround existing linkers that are out there.

We can do that by marking lkdtm_rodata_do_nothing() notrace, which I
think makes sense for all arches actually.

So I'll send you a patch to do that.

cheers

[GIT] Networking

[David Miller]

1) Fix several cases of missing of_node_put() calls in various networking
   drivers.  From Peter Chen.

2) Don't try to remove unconfigured VLANs in qed driver, from Yuval Mintz.

3) Unbalanced locking in TIPC error handling, from Wei Yongjun.

4) Fix lockups in CPDMA driver, from Grygorii Strashko.

5) More MACSEC refcount et al. fixes, from Sabrina Dubroca.

6) Fix MAC address setting in r8169 during runtime suspend, from
   Chun-Hao Lin.

7) Various printf format specifier fixes, from Heinrich Schuchardt.

Please pull, thanks a lot!

The following changes since commit 797cee982eef9195736afc5e7f3b8f613c41d19a:

  Merge branch 'stable-4.8' of git://git.infradead.org/users/pcmoore/audit 
(2016-07-29 17:54:17 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 

for you to fetch changes up to 1d2c2024dcb7aeb2555db4bfd7f991d247ba0508:

  qed: Fail driver load in 100g MSI mode. (2016-08-01 22:13:59 -0700)


Alexander Stein (1):
  phy/micrel: Change phy_id_mask for KSZ8721

Chun-Hao Lin (4):
  r8169: fix kernel log spam when set or get hardware wol setting.
  r8169: add checking driver's runtime pm status in 
rtl8169_get_ethtool_stats()
  r8169: fix nic may not work after changing mac address.
  8139too: fix system hang when there is a tx timeout event.

Colin Ian King (1):
  net: tulip: fix spelling mistake: "attemping" -> "attempting"

David S. Miller (5):
  Merge branch 'qed-fixes'
  Merge branch 'cpsw-fixes'
  Merge branch 'macsec-fixes'
  Merge branch 'r8169-fixes'
  Merge branch 'net-of_node_put'

Florian Fainelli (1):
  net: dsa: bcm_sf2: Unwind errors in correct order

Grygorii Strashko (4):
  net: ethernet: ti: cpdma: fix lockup in cpdma_ctlr_destroy()
  drivers: net: cpsw: fix wrong regs access in cpsw_remove
  drivers: net: cpsw: use of_platform_depopulate()
  ARM: OMAP2+: omap_device: fix crash on omap_device removal

Hariprasad Shenai (1):
  cxgb4/cxgb4vf: Fixes regression in perf when tx vlan offload is disabled

Peter Chen (15):
  ethernet: altera: add missing of_node_put
  ethernet: apm: xgene: add missing of_node_put after calling 
of_parse_phandle
  ethernet: arc: emac_main: add missing of_node_put after calling 
of_parse_phandle
  ethernet: aurora: nb8800: add missing of_node_put after calling 
of_parse_phandle
  ethernet: cavium: octeon: add missing of_node_put after calling 
of_parse_phandle
  ethernet: hisilicon: hns: hns_dsaf_mac: add missing of_node_put after 
calling of_parse_phandle
  ethernet: hisilicon: hns: hns_dsaf_main: add missing of_node_put after 
calling of_parse_phandle
  ethernet: marvell: mvneta: add missing of_node_put after calling 
of_parse_phandle
  ethernet: marvell: mvpp2: add missing of_node_put after calling 
of_parse_phandle
  ethernet: marvell: pxa168_eth: add missing of_node_put after calling 
of_parse_phandle
  ethernet: renesas: ravb_main: add missing of_node_put after calling 
of_parse_phandle
  ethernet: renesas: sh_eth: add missing of_node_put after calling 
of_parse_phandle
  ethernet: stmicro: stmmac: dwmac-socfpga: add missing of_node_put after 
calling of_parse_phandle
  ethernet: stmicro: stmmac: add missing of_node_put after calling 
of_parse_phandle
  ethernet: ti: davinci_emac: add missing of_node_put after calling 
of_parse_phandle

Sabrina Dubroca (3):
  macsec: fix reference counting on RXSC in macsec_handle_frame
  macsec: RXSAs don't need to hold a reference on RXSCs
  macsec: fix negative refcnt on parent link

Soheil Hassas Yeganeh (1):
  tcp: consider recv buf for the initial window scale

Sudarsana Reddy Kalluru (1):
  qed: Fail driver load in 100g MSI mode.

Wei Yongjun (4):
  tipc: fix imbalance read_unlock_bh in __tipc_nl_add_monitor()
  drivers: net: phy: xgene: Remove redundant dev_err call in 
xgene_mdio_probe()
  net: ipv6: use list_move instead of list_del/list_add
  qed: Fix error return code in qed_resc_alloc()

Xin Long (4):
  sctp: fix the issue sctp requeue auth chunk incorrectly
  sctp: allow delivering notifications after receiving SHUTDOWN
  sctp: allow receiving msg when TCP-style sk is in CLOSED state
  sctp: change to use TCP_CLOSE_WAIT as SCTP_SS_CLOSING

Yuval Mintz (6):
  qede: Don't try removing unconfigured vlans
  qed: Fix removal of spoof checking for VFs
  qed: Don't over-do producer cleanup for Rx
  qede: Reset statistics on explicit down
  qed: Correct min bandwidth for 100g
  qed: Prevent over-usage of vlan credits by PF

xypron.g...@gmx.de (13):
  net: caif: use correct format specifier
  net: ethernet: ax88796: avoid null pointer dereference
  net: amd-xgbe: use correct format specifier
  net: bcm63xx: avoid possible null pointer dereference
  net: bna: use correct type 

[GIT] Networking

[David Miller]

1) Fix several cases of missing of_node_put() calls in various networking
   drivers.  From Peter Chen.

2) Don't try to remove unconfigured VLANs in qed driver, from Yuval Mintz.

3) Unbalanced locking in TIPC error handling, from Wei Yongjun.

4) Fix lockups in CPDMA driver, from Grygorii Strashko.

5) More MACSEC refcount et al. fixes, from Sabrina Dubroca.

6) Fix MAC address setting in r8169 during runtime suspend, from
   Chun-Hao Lin.

7) Various printf format specifier fixes, from Heinrich Schuchardt.

Please pull, thanks a lot!

The following changes since commit 797cee982eef9195736afc5e7f3b8f613c41d19a:

  Merge branch 'stable-4.8' of git://git.infradead.org/users/pcmoore/audit 
(2016-07-29 17:54:17 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 

for you to fetch changes up to 1d2c2024dcb7aeb2555db4bfd7f991d247ba0508:

  qed: Fail driver load in 100g MSI mode. (2016-08-01 22:13:59 -0700)


Alexander Stein (1):
  phy/micrel: Change phy_id_mask for KSZ8721

Chun-Hao Lin (4):
  r8169: fix kernel log spam when set or get hardware wol setting.
  r8169: add checking driver's runtime pm status in 
rtl8169_get_ethtool_stats()
  r8169: fix nic may not work after changing mac address.
  8139too: fix system hang when there is a tx timeout event.

Colin Ian King (1):
  net: tulip: fix spelling mistake: "attemping" -> "attempting"

David S. Miller (5):
  Merge branch 'qed-fixes'
  Merge branch 'cpsw-fixes'
  Merge branch 'macsec-fixes'
  Merge branch 'r8169-fixes'
  Merge branch 'net-of_node_put'

Florian Fainelli (1):
  net: dsa: bcm_sf2: Unwind errors in correct order

Grygorii Strashko (4):
  net: ethernet: ti: cpdma: fix lockup in cpdma_ctlr_destroy()
  drivers: net: cpsw: fix wrong regs access in cpsw_remove
  drivers: net: cpsw: use of_platform_depopulate()
  ARM: OMAP2+: omap_device: fix crash on omap_device removal

Hariprasad Shenai (1):
  cxgb4/cxgb4vf: Fixes regression in perf when tx vlan offload is disabled

Peter Chen (15):
  ethernet: altera: add missing of_node_put
  ethernet: apm: xgene: add missing of_node_put after calling 
of_parse_phandle
  ethernet: arc: emac_main: add missing of_node_put after calling 
of_parse_phandle
  ethernet: aurora: nb8800: add missing of_node_put after calling 
of_parse_phandle
  ethernet: cavium: octeon: add missing of_node_put after calling 
of_parse_phandle
  ethernet: hisilicon: hns: hns_dsaf_mac: add missing of_node_put after 
calling of_parse_phandle
  ethernet: hisilicon: hns: hns_dsaf_main: add missing of_node_put after 
calling of_parse_phandle
  ethernet: marvell: mvneta: add missing of_node_put after calling 
of_parse_phandle
  ethernet: marvell: mvpp2: add missing of_node_put after calling 
of_parse_phandle
  ethernet: marvell: pxa168_eth: add missing of_node_put after calling 
of_parse_phandle
  ethernet: renesas: ravb_main: add missing of_node_put after calling 
of_parse_phandle
  ethernet: renesas: sh_eth: add missing of_node_put after calling 
of_parse_phandle
  ethernet: stmicro: stmmac: dwmac-socfpga: add missing of_node_put after 
calling of_parse_phandle
  ethernet: stmicro: stmmac: add missing of_node_put after calling 
of_parse_phandle
  ethernet: ti: davinci_emac: add missing of_node_put after calling 
of_parse_phandle

Sabrina Dubroca (3):
  macsec: fix reference counting on RXSC in macsec_handle_frame
  macsec: RXSAs don't need to hold a reference on RXSCs
  macsec: fix negative refcnt on parent link

Soheil Hassas Yeganeh (1):
  tcp: consider recv buf for the initial window scale

Sudarsana Reddy Kalluru (1):
  qed: Fail driver load in 100g MSI mode.

Wei Yongjun (4):
  tipc: fix imbalance read_unlock_bh in __tipc_nl_add_monitor()
  drivers: net: phy: xgene: Remove redundant dev_err call in 
xgene_mdio_probe()
  net: ipv6: use list_move instead of list_del/list_add
  qed: Fix error return code in qed_resc_alloc()

Xin Long (4):
  sctp: fix the issue sctp requeue auth chunk incorrectly
  sctp: allow delivering notifications after receiving SHUTDOWN
  sctp: allow receiving msg when TCP-style sk is in CLOSED state
  sctp: change to use TCP_CLOSE_WAIT as SCTP_SS_CLOSING

Yuval Mintz (6):
  qede: Don't try removing unconfigured vlans
  qed: Fix removal of spoof checking for VFs
  qed: Don't over-do producer cleanup for Rx
  qede: Reset statistics on explicit down
  qed: Correct min bandwidth for 100g
  qed: Prevent over-usage of vlan credits by PF

xypron.g...@gmx.de (13):
  net: caif: use correct format specifier
  net: ethernet: ax88796: avoid null pointer dereference
  net: amd-xgbe: use correct format specifier
  net: bcm63xx: avoid possible null pointer dereference
  net: bna: use correct type 

Re: [PATCH 1/5] bfa: mark symbols static where possible

[kbuild test robot]

Hi Arnd,

[auto build test ERROR on scsi/for-next]
[also build test ERROR on v4.7 next-20160802]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Arnd-Bergmann/bfa-fix-W-1-build-warnings/20160803-122019
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

Note: the linux-review/Arnd-Bergmann/bfa-fix-W-1-build-warnings/20160803-122019 
HEAD 6b97e29875c21d79abdc2be27ed0d7edb05dff6a builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/scsi/bfa/bfad.c: In function 'bfad_drv_uninit':
>> drivers/scsi/bfa/bfad.c:888:2: error: implicit declaration of function 
>> 'bfa_isr_disable' [-Werror=implicit-function-declaration]
 bfa_isr_disable(>bfa);
 ^
   cc1: some warnings being treated as errors

vim +/bfa_isr_disable +888 drivers/scsi/bfa/bfad.c

a36c61f90 Krishna Gudipati 2010-09-15  882  init_completion(>comp);
f7f73812e Maggie Zhang 2010-12-09  883  bfa_iocfc_stop(>bfa);
a36c61f90 Krishna Gudipati 2010-09-15  884  
spin_unlock_irqrestore(>bfad_lock, flags);
e67143243 Krishna Gudipati 2010-03-03  885  
wait_for_completion(>comp);
e67143243 Krishna Gudipati 2010-03-03  886  
7725ccfda Jing Huang   2009-09-23  887  del_timer_sync(>hal_tmo);
7725ccfda Jing Huang   2009-09-23 @888  bfa_isr_disable(>bfa);
7725ccfda Jing Huang   2009-09-23  889  bfa_detach(>bfa);
7725ccfda Jing Huang   2009-09-23  890  bfad_remove_intr(bfad);
7725ccfda Jing Huang   2009-09-23  891  bfad_hal_mem_release(bfad);

:: The code at line 888 was first introduced by commit
:: 7725ccfda59715ecf8f99e3b520a0b84cc2ea79e [SCSI] bfa: Brocade BFA FC SCSI 
driver

:: TO: Jing Huang <hua...@brocade.com>
:: CC: James Bottomley <james.bottom...@suse.de>

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


.config.gz
Description: Binary data

Re: [PATCH 1/5] bfa: mark symbols static where possible

[kbuild test robot]

Hi Arnd,

[auto build test ERROR on scsi/for-next]
[also build test ERROR on v4.7 next-20160802]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Arnd-Bergmann/bfa-fix-W-1-build-warnings/20160803-122019
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

Note: the linux-review/Arnd-Bergmann/bfa-fix-W-1-build-warnings/20160803-122019 
HEAD 6b97e29875c21d79abdc2be27ed0d7edb05dff6a builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/scsi/bfa/bfad.c: In function 'bfad_drv_uninit':
>> drivers/scsi/bfa/bfad.c:888:2: error: implicit declaration of function 
>> 'bfa_isr_disable' [-Werror=implicit-function-declaration]
 bfa_isr_disable(>bfa);
 ^
   cc1: some warnings being treated as errors

vim +/bfa_isr_disable +888 drivers/scsi/bfa/bfad.c

a36c61f90 Krishna Gudipati 2010-09-15  882  init_completion(>comp);
f7f73812e Maggie Zhang 2010-12-09  883  bfa_iocfc_stop(>bfa);
a36c61f90 Krishna Gudipati 2010-09-15  884  
spin_unlock_irqrestore(>bfad_lock, flags);
e67143243 Krishna Gudipati 2010-03-03  885  
wait_for_completion(>comp);
e67143243 Krishna Gudipati 2010-03-03  886  
7725ccfda Jing Huang   2009-09-23  887  del_timer_sync(>hal_tmo);
7725ccfda Jing Huang   2009-09-23 @888  bfa_isr_disable(>bfa);
7725ccfda Jing Huang   2009-09-23  889  bfa_detach(>bfa);
7725ccfda Jing Huang   2009-09-23  890  bfad_remove_intr(bfad);
7725ccfda Jing Huang   2009-09-23  891  bfad_hal_mem_release(bfad);

:: The code at line 888 was first introduced by commit
:: 7725ccfda59715ecf8f99e3b520a0b84cc2ea79e [SCSI] bfa: Brocade BFA FC SCSI 
driver

:: TO: Jing Huang 
:: CC: James Bottomley 

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


.config.gz
Description: Binary data

Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?

[Michael S. Tsirkin]

On Thu, Mar 03, 2016 at 11:05:43AM -0800, H. Peter Anvin wrote:
> On March 3, 2016 10:35:50 AM PST, "Michael S. Tsirkin"  
> wrote:
> >On Thu, Mar 03, 2016 at 04:34:53PM +0100, Peter Zijlstra wrote:
> >> On Thu, Mar 03, 2016 at 04:27:39PM +0100, Ingo Molnar wrote:
> >> > 
> >> > * Dexuan Cui  wrote:
> >> > 
> >> > > Hi,
> >> > > My understanding about arch/x86/include/asm/barrier.h is:
> >obviously Linux
> >> > > more likes {L,S,M}FENCE -- Locked ADD is only used in x86_32
> >platforms that
> >> > > don't support XMM2.
> >> > > 
> >> > > However, it looks people say Locked Add is much faster than the
> >FENCE
> >> > > instructions, even on modern Intel CPUs like Haswell, e.g.,
> >please see
> >> > > the three sources:
> >> > > 
> >> > > " 11.5.1 Locked Instructions as Memory Barriers
> >> > > Optimization
> >> > > Use locked instructions to implement Store/Store and Store/Load
> >barriers.
> >> > > "
> >> > > http://support.amd.com/TechDocs/47414_15h_sw_opt_guide.pdf
> >> > > 
> >> > > "lock addl %(rsp), 0 is a better solution for StoreLoad barrier
> >":
> >> > > http://shipilev.net/blog/2014/on-the-fence-with-dependencies/
> >> > > 
> >> > > "...locked instruction are more efficient barriers...":
> >> > >
> >http://www.pvk.ca/Blog/2014/10/19/performance-optimisation-~-writing-an-essay/
> >> > > 
> >> > > I also found that FreeBSD prefers Locked Add.
> >> > > 
> >> > > So, I'm curious why Linux prefers MFENCE.
> >> > > I guess I may be missing something.
> >> > > 
> >> > > I tried to google the question, but didn't find an answer.
> >> > 
> >> > It's being worked on, see this thread on lkml from a few weeks ago:
> >> > 
> >> >C Jan 13 Michael S. Tsir| [PATCH v3 0/4] x86: faster
> >mb()+documentation tweaks
> >> >C Jan 13 Michael S. Tsir| ├─>[PATCH v3 1/4] x86: add cc
> >clobber for addl
> >> >C Jan 13 Michael S. Tsir| ├─>[PATCH v3 2/4] x86: drop a
> >comment left over from X86_OOSTORE
> >> >C Jan 13 Michael S. Tsir| ├─>[PATCH v3 3/4] x86: tweak the
> >comment about use of wmb for IO
> >> >C Jan 13 Michael S. Tsir| ├─>[PATCH v3 4/4] x86: drop mfence
> >in favor of lock+addl
> >> > 
> >> > The 4th patch changes MFENCE to a LOCK ADDL locked instruction.
> >> 
> >> Lots of additional chatter here:
> >> 
> >>   lkml.kernel.org/r/20160112150032-mutt-send-email-...@redhat.com
> >> 
> >> And some useful bits here:
> >> 
> >>   lkml.kernel.org/r/56957d54.5000...@zytor.com
> >> 
> >> latest version here:
> >> 
> >>   lkml.kernel.org/r/1453921746-16178-1-git-send-email-...@redhat.com
> >
> >It's ready as far as I am concerned.
> >Basically we are just waiting for ack from hpa.
> 
> And I'm still discussing this with the hardware people.  It seems we
> can do this for *most* things, but not all; the question is where
> exactly we need to do something different.

I'm guessing there's still no update?

There's a decent chance that without documentation a bunch of current
uses are actually broken. See for example
http://marc.info/?l=linux-kernel=145400059304553=2
which going by the manual is fixing smp_mb misuse for clflush - or maybe not?

> -- 
> Sent from my Android device with K-9 Mail. Please excuse brevity and 
> formatting.

Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?

[Michael S. Tsirkin]

On Thu, Mar 03, 2016 at 11:05:43AM -0800, H. Peter Anvin wrote:
> On March 3, 2016 10:35:50 AM PST, "Michael S. Tsirkin"  
> wrote:
> >On Thu, Mar 03, 2016 at 04:34:53PM +0100, Peter Zijlstra wrote:
> >> On Thu, Mar 03, 2016 at 04:27:39PM +0100, Ingo Molnar wrote:
> >> > 
> >> > * Dexuan Cui  wrote:
> >> > 
> >> > > Hi,
> >> > > My understanding about arch/x86/include/asm/barrier.h is:
> >obviously Linux
> >> > > more likes {L,S,M}FENCE -- Locked ADD is only used in x86_32
> >platforms that
> >> > > don't support XMM2.
> >> > > 
> >> > > However, it looks people say Locked Add is much faster than the
> >FENCE
> >> > > instructions, even on modern Intel CPUs like Haswell, e.g.,
> >please see
> >> > > the three sources:
> >> > > 
> >> > > " 11.5.1 Locked Instructions as Memory Barriers
> >> > > Optimization
> >> > > Use locked instructions to implement Store/Store and Store/Load
> >barriers.
> >> > > "
> >> > > http://support.amd.com/TechDocs/47414_15h_sw_opt_guide.pdf
> >> > > 
> >> > > "lock addl %(rsp), 0 is a better solution for StoreLoad barrier
> >":
> >> > > http://shipilev.net/blog/2014/on-the-fence-with-dependencies/
> >> > > 
> >> > > "...locked instruction are more efficient barriers...":
> >> > >
> >http://www.pvk.ca/Blog/2014/10/19/performance-optimisation-~-writing-an-essay/
> >> > > 
> >> > > I also found that FreeBSD prefers Locked Add.
> >> > > 
> >> > > So, I'm curious why Linux prefers MFENCE.
> >> > > I guess I may be missing something.
> >> > > 
> >> > > I tried to google the question, but didn't find an answer.
> >> > 
> >> > It's being worked on, see this thread on lkml from a few weeks ago:
> >> > 
> >> >C Jan 13 Michael S. Tsir| [PATCH v3 0/4] x86: faster
> >mb()+documentation tweaks
> >> >C Jan 13 Michael S. Tsir| ├─>[PATCH v3 1/4] x86: add cc
> >clobber for addl
> >> >C Jan 13 Michael S. Tsir| ├─>[PATCH v3 2/4] x86: drop a
> >comment left over from X86_OOSTORE
> >> >C Jan 13 Michael S. Tsir| ├─>[PATCH v3 3/4] x86: tweak the
> >comment about use of wmb for IO
> >> >C Jan 13 Michael S. Tsir| ├─>[PATCH v3 4/4] x86: drop mfence
> >in favor of lock+addl
> >> > 
> >> > The 4th patch changes MFENCE to a LOCK ADDL locked instruction.
> >> 
> >> Lots of additional chatter here:
> >> 
> >>   lkml.kernel.org/r/20160112150032-mutt-send-email-...@redhat.com
> >> 
> >> And some useful bits here:
> >> 
> >>   lkml.kernel.org/r/56957d54.5000...@zytor.com
> >> 
> >> latest version here:
> >> 
> >>   lkml.kernel.org/r/1453921746-16178-1-git-send-email-...@redhat.com
> >
> >It's ready as far as I am concerned.
> >Basically we are just waiting for ack from hpa.
> 
> And I'm still discussing this with the hardware people.  It seems we
> can do this for *most* things, but not all; the question is where
> exactly we need to do something different.

I'm guessing there's still no update?

There's a decent chance that without documentation a bunch of current
uses are actually broken. See for example
http://marc.info/?l=linux-kernel=145400059304553=2
which going by the manual is fixing smp_mb misuse for clflush - or maybe not?

> -- 
> Sent from my Android device with K-9 Mail. Please excuse brevity and 
> formatting.

Re: [PATCH] phy: fix the bug when remove the phy driver

[Florian Fainelli]

On August 2, 2016 9:22:53 PM MST, Ding Tianhong  wrote:
>On 2016/8/3 10:41, Florian Fainelli wrote:
>> On August 2, 2016 6:21:52 PM MST, Ding Tianhong
> wrote:
>>> On 2016/8/3 0:42, Florian Fainelli wrote:
 Le 02/08/2016 à 06:00, Ding Tianhong a écrit :
> The nic in my board use the phy dev from marvell, and
> the system will load the marvell phy driver automatically,
> but when I remove the phy drivers, the system immediately panic:
>
> localhost login: [ 2582.052465] Unable to handle kernel NULL
>pointer
>>> dereference at virtual address 00c0
> [ 2582.061429] pgd = 81226000
> [ 2582.065277] [00c0] *pgd=003f7f893003,
>>> *pud=003f7f894003, *pmd=003f7f895003, *pte=00606d000707
> [ 2582.076681] Internal error: Oops: 9606 [#1] SMP
> [ 2582.082049] Modules linked in: sr_mod(E) cdrom(E) ses(E)
>>> enclosure(E) shpchp(E) crc32_arm64(E) aes_ce_blk(E) ablk_helper(E)
>>> cryptd(E) aes_ce_cipher(E) ghash_ce(E) sha2_ce(E) sha1_ce(E)
>>> usb_storage(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E)
>[last
>>> unloaded: marvell]
> [ 2582.109226] CPU: 21 PID: 1514 Comm: kworker/21:1 Tainted: G
> 
>>> E   4.1.27-vhulk3.6.5.aarch64 #1
> [ 2582.119415] Hardware name: Huawei Taishan 2180 /BC11SPCC, BIOS
>>> 1.31 06/23/2016
> [ 2582.127346] Workqueue: events_power_efficient phy_state_machine
> [ 2582.133796] task: 803f6f41bac0 ti: 803f6eca4000
>task.ti:
>>> 803f6eca4000
> [ 2582.141910] PC is at phy_state_machine+0x3c/0x438
> [ 2582.147081] LR is at phy_state_machine+0x34/0x438
> [ 2582.152173] pc : [] lr : []
>>> pstate: 6145
> [ 2582.160189] sp : 803f6eca7d30
> [ 2582.163825] x29: 803f6eca7d30 x28: 
> [ 2582.169689] x27: 805fdfd0aa00 x26: 0008
> [ 2582.175482] x25:  x24: 8112c57c
> [ 2582.181391] x23: 805f4fc8a800 x22: 805fdfd0f700
> [ 2582.187241] x21: 805f4fc8abf8 x20: 805f4fc8a770
> [ 2582.193035] x19: 805f4fc8ab70 x18: 0007
> [ 2582.198914] x17: 000e x16: 0001
> [ 2582.204710] x15: 0007 x14: 000e
> [ 2582.210584] x13: 0200 x12: 5556
> [ 2582.216373] x11: 1c00 x10: 
> [ 2582.222166] x9 : 80a36880 x8 : 803f6f41c060
> [ 2582.227994] x7 : 00010008b39b x6 : 8101e690
> [ 2582.233788] x5 :  x4 : 0080
> [ 2582.239612] x3 :  x2 : 
> [ 2582.245404] x1 :  x0 : 
> [ 2582.265813]
> [ 2582.282971] Process kworker/21:1 (pid: 1514, stack limit =
>>> 0x803f6eca4020)
> [ 2582.307284] Stack: (0x803f6eca7d30 to 0x803f6eca8000)
> [ 2582.331183] 7d20:  
>>> 803f6eca7d70 800db3b8
> [ 2582.354788] 7d40: 803f6e696000 805f4fc8ab70
>>> 805fdfd0aa00 805fdfd0f700
> [ 2582.378341] 7d60:  8112c57c
>>> 803f6eca7dc0 800db7d4
> [ 2582.403700] 7d80: 803f6e696000 803f6e696030
>>> 805fdfd0aa18 805fdfd0aa00
> [ 2582.428385] 7da0: 803f6eca4000 8112c57c
>>>  0008
> [ 2582.451222] 7dc0: 803f6eca7e20 800e1d0c
>>> 805f4fc15000 8115f188
> [ 2582.474577] 7de0: 80d1cf88 803f6e696000
>>> 800db690 
> [ 2582.497281] 7e00:  
>>>  
> [ 2582.522992] 7e20:  80083dd0
>>> 800e1c10 805f4fc15000
> [ 2582.546945] 7e40:  
>>>  
> [ 2582.568550] 7e60:  800ee33c
>>> 803f6e696000 805f
> [ 2582.589157] 7e80:  803f6eca7e88
>>> 803f6eca7e88 
> [ 2582.609767] 7ea0:  803f6eca7ea8
>>> 803f6eca7ea8 cb88537fdc8ba31b
> [ 2582.633228] 7ec0:  
>>>  
> [ 2582.655386] 7ee0:  
>>>  
> [ 2582.674223] 7f00:  
>>>  
> [ 2582.692994] 7f20:  
>>>  
> [ 2582.711765] 7f40:  
>>>  
> [ 2582.730809] 7f60:  
>>>  
> [ 2582.748601] 7f80:  
>>>  
> [ 2582.769388] 7fa0:  
>>>  

Re: [PATCH] phy: fix the bug when remove the phy driver

[Florian Fainelli]

On August 2, 2016 9:22:53 PM MST, Ding Tianhong  wrote:
>On 2016/8/3 10:41, Florian Fainelli wrote:
>> On August 2, 2016 6:21:52 PM MST, Ding Tianhong
> wrote:
>>> On 2016/8/3 0:42, Florian Fainelli wrote:
 Le 02/08/2016 à 06:00, Ding Tianhong a écrit :
> The nic in my board use the phy dev from marvell, and
> the system will load the marvell phy driver automatically,
> but when I remove the phy drivers, the system immediately panic:
>
> localhost login: [ 2582.052465] Unable to handle kernel NULL
>pointer
>>> dereference at virtual address 00c0
> [ 2582.061429] pgd = 81226000
> [ 2582.065277] [00c0] *pgd=003f7f893003,
>>> *pud=003f7f894003, *pmd=003f7f895003, *pte=00606d000707
> [ 2582.076681] Internal error: Oops: 9606 [#1] SMP
> [ 2582.082049] Modules linked in: sr_mod(E) cdrom(E) ses(E)
>>> enclosure(E) shpchp(E) crc32_arm64(E) aes_ce_blk(E) ablk_helper(E)
>>> cryptd(E) aes_ce_cipher(E) ghash_ce(E) sha2_ce(E) sha1_ce(E)
>>> usb_storage(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E)
>[last
>>> unloaded: marvell]
> [ 2582.109226] CPU: 21 PID: 1514 Comm: kworker/21:1 Tainted: G
> 
>>> E   4.1.27-vhulk3.6.5.aarch64 #1
> [ 2582.119415] Hardware name: Huawei Taishan 2180 /BC11SPCC, BIOS
>>> 1.31 06/23/2016
> [ 2582.127346] Workqueue: events_power_efficient phy_state_machine
> [ 2582.133796] task: 803f6f41bac0 ti: 803f6eca4000
>task.ti:
>>> 803f6eca4000
> [ 2582.141910] PC is at phy_state_machine+0x3c/0x438
> [ 2582.147081] LR is at phy_state_machine+0x34/0x438
> [ 2582.152173] pc : [] lr : []
>>> pstate: 6145
> [ 2582.160189] sp : 803f6eca7d30
> [ 2582.163825] x29: 803f6eca7d30 x28: 
> [ 2582.169689] x27: 805fdfd0aa00 x26: 0008
> [ 2582.175482] x25:  x24: 8112c57c
> [ 2582.181391] x23: 805f4fc8a800 x22: 805fdfd0f700
> [ 2582.187241] x21: 805f4fc8abf8 x20: 805f4fc8a770
> [ 2582.193035] x19: 805f4fc8ab70 x18: 0007
> [ 2582.198914] x17: 000e x16: 0001
> [ 2582.204710] x15: 0007 x14: 000e
> [ 2582.210584] x13: 0200 x12: 5556
> [ 2582.216373] x11: 1c00 x10: 
> [ 2582.222166] x9 : 80a36880 x8 : 803f6f41c060
> [ 2582.227994] x7 : 00010008b39b x6 : 8101e690
> [ 2582.233788] x5 :  x4 : 0080
> [ 2582.239612] x3 :  x2 : 
> [ 2582.245404] x1 :  x0 : 
> [ 2582.265813]
> [ 2582.282971] Process kworker/21:1 (pid: 1514, stack limit =
>>> 0x803f6eca4020)
> [ 2582.307284] Stack: (0x803f6eca7d30 to 0x803f6eca8000)
> [ 2582.331183] 7d20:  
>>> 803f6eca7d70 800db3b8
> [ 2582.354788] 7d40: 803f6e696000 805f4fc8ab70
>>> 805fdfd0aa00 805fdfd0f700
> [ 2582.378341] 7d60:  8112c57c
>>> 803f6eca7dc0 800db7d4
> [ 2582.403700] 7d80: 803f6e696000 803f6e696030
>>> 805fdfd0aa18 805fdfd0aa00
> [ 2582.428385] 7da0: 803f6eca4000 8112c57c
>>>  0008
> [ 2582.451222] 7dc0: 803f6eca7e20 800e1d0c
>>> 805f4fc15000 8115f188
> [ 2582.474577] 7de0: 80d1cf88 803f6e696000
>>> 800db690 
> [ 2582.497281] 7e00:  
>>>  
> [ 2582.522992] 7e20:  80083dd0
>>> 800e1c10 805f4fc15000
> [ 2582.546945] 7e40:  
>>>  
> [ 2582.568550] 7e60:  800ee33c
>>> 803f6e696000 805f
> [ 2582.589157] 7e80:  803f6eca7e88
>>> 803f6eca7e88 
> [ 2582.609767] 7ea0:  803f6eca7ea8
>>> 803f6eca7ea8 cb88537fdc8ba31b
> [ 2582.633228] 7ec0:  
>>>  
> [ 2582.655386] 7ee0:  
>>>  
> [ 2582.674223] 7f00:  
>>>  
> [ 2582.692994] 7f20:  
>>>  
> [ 2582.711765] 7f40:  
>>>  
> [ 2582.730809] 7f60:  
>>>  
> [ 2582.748601] 7f80:  
>>>  
> [ 2582.769388] 7fa0:  
>>>  
> [ 2582.786756] 7fc0:  

Re: [PATCH] phy: fix the bug when remove the phy driver

[Ding Tianhong]

On 2016/8/3 10:41, Florian Fainelli wrote:
> On August 2, 2016 6:21:52 PM MST, Ding Tianhong  
> wrote:
>> On 2016/8/3 0:42, Florian Fainelli wrote:
>>> Le 02/08/2016 à 06:00, Ding Tianhong a écrit :
 The nic in my board use the phy dev from marvell, and
 the system will load the marvell phy driver automatically,
 but when I remove the phy drivers, the system immediately panic:

 localhost login: [ 2582.052465] Unable to handle kernel NULL pointer
>> dereference at virtual address 00c0
 [ 2582.061429] pgd = 81226000
 [ 2582.065277] [00c0] *pgd=003f7f893003,
>> *pud=003f7f894003, *pmd=003f7f895003, *pte=00606d000707
 [ 2582.076681] Internal error: Oops: 9606 [#1] SMP
 [ 2582.082049] Modules linked in: sr_mod(E) cdrom(E) ses(E)
>> enclosure(E) shpchp(E) crc32_arm64(E) aes_ce_blk(E) ablk_helper(E)
>> cryptd(E) aes_ce_cipher(E) ghash_ce(E) sha2_ce(E) sha1_ce(E)
>> usb_storage(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) [last
>> unloaded: marvell]
 [ 2582.109226] CPU: 21 PID: 1514 Comm: kworker/21:1 Tainted: G  
>> E   4.1.27-vhulk3.6.5.aarch64 #1
 [ 2582.119415] Hardware name: Huawei Taishan 2180 /BC11SPCC, BIOS
>> 1.31 06/23/2016
 [ 2582.127346] Workqueue: events_power_efficient phy_state_machine
 [ 2582.133796] task: 803f6f41bac0 ti: 803f6eca4000 task.ti:
>> 803f6eca4000
 [ 2582.141910] PC is at phy_state_machine+0x3c/0x438
 [ 2582.147081] LR is at phy_state_machine+0x34/0x438
 [ 2582.152173] pc : [] lr : []
>> pstate: 6145
 [ 2582.160189] sp : 803f6eca7d30
 [ 2582.163825] x29: 803f6eca7d30 x28: 
 [ 2582.169689] x27: 805fdfd0aa00 x26: 0008
 [ 2582.175482] x25:  x24: 8112c57c
 [ 2582.181391] x23: 805f4fc8a800 x22: 805fdfd0f700
 [ 2582.187241] x21: 805f4fc8abf8 x20: 805f4fc8a770
 [ 2582.193035] x19: 805f4fc8ab70 x18: 0007
 [ 2582.198914] x17: 000e x16: 0001
 [ 2582.204710] x15: 0007 x14: 000e
 [ 2582.210584] x13: 0200 x12: 5556
 [ 2582.216373] x11: 1c00 x10: 
 [ 2582.222166] x9 : 80a36880 x8 : 803f6f41c060
 [ 2582.227994] x7 : 00010008b39b x6 : 8101e690
 [ 2582.233788] x5 :  x4 : 0080
 [ 2582.239612] x3 :  x2 : 
 [ 2582.245404] x1 :  x0 : 
 [ 2582.265813]
 [ 2582.282971] Process kworker/21:1 (pid: 1514, stack limit =
>> 0x803f6eca4020)
 [ 2582.307284] Stack: (0x803f6eca7d30 to 0x803f6eca8000)
 [ 2582.331183] 7d20:  
>> 803f6eca7d70 800db3b8
 [ 2582.354788] 7d40: 803f6e696000 805f4fc8ab70
>> 805fdfd0aa00 805fdfd0f700
 [ 2582.378341] 7d60:  8112c57c
>> 803f6eca7dc0 800db7d4
 [ 2582.403700] 7d80: 803f6e696000 803f6e696030
>> 805fdfd0aa18 805fdfd0aa00
 [ 2582.428385] 7da0: 803f6eca4000 8112c57c
>>  0008
 [ 2582.451222] 7dc0: 803f6eca7e20 800e1d0c
>> 805f4fc15000 8115f188
 [ 2582.474577] 7de0: 80d1cf88 803f6e696000
>> 800db690 
 [ 2582.497281] 7e00:  
>>  
 [ 2582.522992] 7e20:  80083dd0
>> 800e1c10 805f4fc15000
 [ 2582.546945] 7e40:  
>>  
 [ 2582.568550] 7e60:  800ee33c
>> 803f6e696000 805f
 [ 2582.589157] 7e80:  803f6eca7e88
>> 803f6eca7e88 
 [ 2582.609767] 7ea0:  803f6eca7ea8
>> 803f6eca7ea8 cb88537fdc8ba31b
 [ 2582.633228] 7ec0:  
>>  
 [ 2582.655386] 7ee0:  
>>  
 [ 2582.674223] 7f00:  
>>  
 [ 2582.692994] 7f20:  
>>  
 [ 2582.711765] 7f40:  
>>  
 [ 2582.730809] 7f60:  
>>  
 [ 2582.748601] 7f80:  
>>  
 [ 2582.769388] 7fa0:  
>>  
 [ 2582.786756] 7fc0:  0005
>>  
 [ 2582.804134] 7fe0:  
>> 

Re: [PATCH 2/2] soc: nxp: Add a RCPM driver

[Chenhui Zhao]

On Mon, Aug 1, 2016 at 8:25 PM, Arnd Bergmann  wrote:
> On Monday, August 1, 2016 5:49:03 PM CEST Chenhui Zhao wrote:
>> The NXP's QorIQ Processors based on ARM Core have a RCPM module
>> (Run Control and Power Management), which performs all device-level
>> tasks associated with power management.
>>
>> This patch mainly implements the wakeup sources configuration before
>> entering LPM20, a low power state of device-level. The devices can be
>> waked up by specified sources, such as Flextimer, GPIO and so on.
>>
>> Signed-off-by: Chenhui Zhao 
>
> Adding irqchip maintainers to cc, as this wakeup handling is normally
> part of the irq controller.
>
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* So far there are not more than two registers */
>> +#define RCPM_IPPDEXPCR0  0x140
>> +#define RCPM_IPPDEXPCR1  0x144
>> +#define RCPM_IPPDEXPCR(x)(RCPM_IPPDEXPCR0 + 4 * x)
>> +#define RCPM_WAKEUP_CELL_MAX_SIZE2
>> +
>> +/* it reprents the number of the registers RCPM_IPPDEXPCR */
>> +static unsigned int rcpm_wakeup_cells;
>> +static void __iomem *rcpm_reg_base;
>> +static u32 ippdexpcr[RCPM_WAKEUP_CELL_MAX_SIZE];
>
> Can you make these local to the context of whoever
> calls into the driver?
>
>
>> +static void rcpm_wakeup_fixup(struct device *dev, void *data)
>> +{
>> + struct device_node *node = dev ? dev->of_node : NULL;
>> + u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1];
>> + int ret;
>> + int i;
>> +
>> + if (!dev || !node || !device_may_wakeup(dev))
>> + return;
>> +
>> + /*
>> +  * Get the values in the "rcpm-wakeup" property.
>> +  * Refer to Documentation/devicetree/bindings/soc/fsl/rcpm.txt
>> +  */
>> + ret = of_property_read_u32_array(node, "rcpm-wakeup",c
>> +  value, rcpm_wakeup_cells + 1);
>
> My first impression is that you are trying to do something
> in a platform specific way that should be handled by common
> code here.
>
> You are parsing rcpm_wakeup_cells once for the global node,
> but you don't check whether the device that has the rcpm-wakeup
> node actually refers to this instance, and that would require
> an incompatible change if we ever get an implementation that
> has multiple such nodes.
>
> Arnd

The code is specific to the QorIQ platform.

For a given QorIQ SoC, the value of the "fsl,#rcpm-wakeup-cells"
property would not change. Anyway, your suggestion is better getting
the rcpm node from the "rcpm-wakeup" property.

Thanks,
Chenhui

Re: [PATCH] phy: fix the bug when remove the phy driver

[Ding Tianhong]

On 2016/8/3 10:41, Florian Fainelli wrote:
> On August 2, 2016 6:21:52 PM MST, Ding Tianhong  
> wrote:
>> On 2016/8/3 0:42, Florian Fainelli wrote:
>>> Le 02/08/2016 à 06:00, Ding Tianhong a écrit :
 The nic in my board use the phy dev from marvell, and
 the system will load the marvell phy driver automatically,
 but when I remove the phy drivers, the system immediately panic:

 localhost login: [ 2582.052465] Unable to handle kernel NULL pointer
>> dereference at virtual address 00c0
 [ 2582.061429] pgd = 81226000
 [ 2582.065277] [00c0] *pgd=003f7f893003,
>> *pud=003f7f894003, *pmd=003f7f895003, *pte=00606d000707
 [ 2582.076681] Internal error: Oops: 9606 [#1] SMP
 [ 2582.082049] Modules linked in: sr_mod(E) cdrom(E) ses(E)
>> enclosure(E) shpchp(E) crc32_arm64(E) aes_ce_blk(E) ablk_helper(E)
>> cryptd(E) aes_ce_cipher(E) ghash_ce(E) sha2_ce(E) sha1_ce(E)
>> usb_storage(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) [last
>> unloaded: marvell]
 [ 2582.109226] CPU: 21 PID: 1514 Comm: kworker/21:1 Tainted: G  
>> E   4.1.27-vhulk3.6.5.aarch64 #1
 [ 2582.119415] Hardware name: Huawei Taishan 2180 /BC11SPCC, BIOS
>> 1.31 06/23/2016
 [ 2582.127346] Workqueue: events_power_efficient phy_state_machine
 [ 2582.133796] task: 803f6f41bac0 ti: 803f6eca4000 task.ti:
>> 803f6eca4000
 [ 2582.141910] PC is at phy_state_machine+0x3c/0x438
 [ 2582.147081] LR is at phy_state_machine+0x34/0x438
 [ 2582.152173] pc : [] lr : []
>> pstate: 6145
 [ 2582.160189] sp : 803f6eca7d30
 [ 2582.163825] x29: 803f6eca7d30 x28: 
 [ 2582.169689] x27: 805fdfd0aa00 x26: 0008
 [ 2582.175482] x25:  x24: 8112c57c
 [ 2582.181391] x23: 805f4fc8a800 x22: 805fdfd0f700
 [ 2582.187241] x21: 805f4fc8abf8 x20: 805f4fc8a770
 [ 2582.193035] x19: 805f4fc8ab70 x18: 0007
 [ 2582.198914] x17: 000e x16: 0001
 [ 2582.204710] x15: 0007 x14: 000e
 [ 2582.210584] x13: 0200 x12: 5556
 [ 2582.216373] x11: 1c00 x10: 
 [ 2582.222166] x9 : 80a36880 x8 : 803f6f41c060
 [ 2582.227994] x7 : 00010008b39b x6 : 8101e690
 [ 2582.233788] x5 :  x4 : 0080
 [ 2582.239612] x3 :  x2 : 
 [ 2582.245404] x1 :  x0 : 
 [ 2582.265813]
 [ 2582.282971] Process kworker/21:1 (pid: 1514, stack limit =
>> 0x803f6eca4020)
 [ 2582.307284] Stack: (0x803f6eca7d30 to 0x803f6eca8000)
 [ 2582.331183] 7d20:  
>> 803f6eca7d70 800db3b8
 [ 2582.354788] 7d40: 803f6e696000 805f4fc8ab70
>> 805fdfd0aa00 805fdfd0f700
 [ 2582.378341] 7d60:  8112c57c
>> 803f6eca7dc0 800db7d4
 [ 2582.403700] 7d80: 803f6e696000 803f6e696030
>> 805fdfd0aa18 805fdfd0aa00
 [ 2582.428385] 7da0: 803f6eca4000 8112c57c
>>  0008
 [ 2582.451222] 7dc0: 803f6eca7e20 800e1d0c
>> 805f4fc15000 8115f188
 [ 2582.474577] 7de0: 80d1cf88 803f6e696000
>> 800db690 
 [ 2582.497281] 7e00:  
>>  
 [ 2582.522992] 7e20:  80083dd0
>> 800e1c10 805f4fc15000
 [ 2582.546945] 7e40:  
>>  
 [ 2582.568550] 7e60:  800ee33c
>> 803f6e696000 805f
 [ 2582.589157] 7e80:  803f6eca7e88
>> 803f6eca7e88 
 [ 2582.609767] 7ea0:  803f6eca7ea8
>> 803f6eca7ea8 cb88537fdc8ba31b
 [ 2582.633228] 7ec0:  
>>  
 [ 2582.655386] 7ee0:  
>>  
 [ 2582.674223] 7f00:  
>>  
 [ 2582.692994] 7f20:  
>>  
 [ 2582.711765] 7f40:  
>>  
 [ 2582.730809] 7f60:  
>>  
 [ 2582.748601] 7f80:  
>>  
 [ 2582.769388] 7fa0:  
>>  
 [ 2582.786756] 7fc0:  0005
>>  
 [ 2582.804134] 7fe0:  
>>  
 

Re: [PATCH 2/2] soc: nxp: Add a RCPM driver

[Chenhui Zhao]

On Mon, Aug 1, 2016 at 8:25 PM, Arnd Bergmann  wrote:
> On Monday, August 1, 2016 5:49:03 PM CEST Chenhui Zhao wrote:
>> The NXP's QorIQ Processors based on ARM Core have a RCPM module
>> (Run Control and Power Management), which performs all device-level
>> tasks associated with power management.
>>
>> This patch mainly implements the wakeup sources configuration before
>> entering LPM20, a low power state of device-level. The devices can be
>> waked up by specified sources, such as Flextimer, GPIO and so on.
>>
>> Signed-off-by: Chenhui Zhao 
>
> Adding irqchip maintainers to cc, as this wakeup handling is normally
> part of the irq controller.
>
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* So far there are not more than two registers */
>> +#define RCPM_IPPDEXPCR0  0x140
>> +#define RCPM_IPPDEXPCR1  0x144
>> +#define RCPM_IPPDEXPCR(x)(RCPM_IPPDEXPCR0 + 4 * x)
>> +#define RCPM_WAKEUP_CELL_MAX_SIZE2
>> +
>> +/* it reprents the number of the registers RCPM_IPPDEXPCR */
>> +static unsigned int rcpm_wakeup_cells;
>> +static void __iomem *rcpm_reg_base;
>> +static u32 ippdexpcr[RCPM_WAKEUP_CELL_MAX_SIZE];
>
> Can you make these local to the context of whoever
> calls into the driver?
>
>
>> +static void rcpm_wakeup_fixup(struct device *dev, void *data)
>> +{
>> + struct device_node *node = dev ? dev->of_node : NULL;
>> + u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1];
>> + int ret;
>> + int i;
>> +
>> + if (!dev || !node || !device_may_wakeup(dev))
>> + return;
>> +
>> + /*
>> +  * Get the values in the "rcpm-wakeup" property.
>> +  * Refer to Documentation/devicetree/bindings/soc/fsl/rcpm.txt
>> +  */
>> + ret = of_property_read_u32_array(node, "rcpm-wakeup",c
>> +  value, rcpm_wakeup_cells + 1);
>
> My first impression is that you are trying to do something
> in a platform specific way that should be handled by common
> code here.
>
> You are parsing rcpm_wakeup_cells once for the global node,
> but you don't check whether the device that has the rcpm-wakeup
> node actually refers to this instance, and that would require
> an incompatible change if we ever get an implementation that
> has multiple such nodes.
>
> Arnd

The code is specific to the QorIQ platform.

For a given QorIQ SoC, the value of the "fsl,#rcpm-wakeup-cells"
property would not change. Anyway, your suggestion is better getting
the rcpm node from the "rcpm-wakeup" property.

Thanks,
Chenhui

Re: [PATCH] uprobe: Add uprobe_pre/post_sstep_notifier to NOKPROBE_SYMBOL

[Pratyush Anand]

Hi Masami,

On 03/08/2016:12:45:24 AM, Masami Hiramatsu wrote:
> On Tue,  2 Aug 2016 12:14:06 +0530
> Pratyush Anand  wrote:
> 
> > uprobe_pre_sstep_notifier and uprobe_post_sstep_notifier are called from
> > debug exception handler, so blacklist them for kprobing.
> 
> Actually, these exception notifers are kicked only if the debug exception
> is not related to kprobes (at least on x86). In that case, we don't have
> to take care about that. Or, would you hit any problem on it?

Well, I have faced issue on ARM64. So, if I have a kprobe instrumented at these
functions and then if I hit a uprobe then kernel goes into an infinite loop of
"Unexpected kernel single-step exception at EL1".

On x86 I have not tested, but I see that all functions except
arch_uprobe_exception_notify() in the call stack of
uprobe_pre/post_sstep_notifier() are blacklisted for kprobe. So, I am unable to
understand that why arch_uprobe_exception_notify() and
uprobe_pre/post_sstep_notifier() are not blacklisted.

> 
> IOW, where do we have to prohibit kprobes are, the code path from where 
> right after the breakpoint (debug) exception is occurred, to where right
> before the kprobe is handled. After that, it should be safe.

Hu...My understanding was that if a function a() is not good to be kprobed
then we can not kprobe any function called by a() as well. Thanks for the
clarification. So, if I go with your definition then, something is still wrong 
on
ARM64 which is causing issue when I kprobe uprobe_pre/post_sstep_notifier().

~Pratyush

> 
> Thank you,
> 
> 
> > 
> > Signed-off-by: Pratyush Anand 
> > ---
> >  kernel/events/uprobes.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> > index b7a525ab2083..206e594cb65e 100644
> > --- a/kernel/events/uprobes.c
> > +++ b/kernel/events/uprobes.c
> > @@ -37,6 +37,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  
> > @@ -1997,6 +1998,7 @@ int uprobe_pre_sstep_notifier(struct pt_regs *regs)
> > set_thread_flag(TIF_UPROBE);
> > return 1;
> >  }
> > +NOKPROBE_SYMBOL(uprobe_pre_sstep_notifier);
> >  
> >  /*
> >   * uprobe_post_sstep_notifier gets called in interrupt context as part of 
> > notifier
> > @@ -2014,6 +2016,7 @@ int uprobe_post_sstep_notifier(struct pt_regs *regs)
> > set_thread_flag(TIF_UPROBE);
> > return 1;
> >  }
> > +NOKPROBE_SYMBOL(uprobe_post_sstep_notifier);
> >  
> >  static struct notifier_block uprobe_exception_nb = {
> > .notifier_call  = arch_uprobe_exception_notify,
> > -- 
> > 2.5.5
> > 
> 
> 
> -- 
> Masami Hiramatsu 

Re: [PATCH] uprobe: Add uprobe_pre/post_sstep_notifier to NOKPROBE_SYMBOL

[Pratyush Anand]

Hi Masami,

On 03/08/2016:12:45:24 AM, Masami Hiramatsu wrote:
> On Tue,  2 Aug 2016 12:14:06 +0530
> Pratyush Anand  wrote:
> 
> > uprobe_pre_sstep_notifier and uprobe_post_sstep_notifier are called from
> > debug exception handler, so blacklist them for kprobing.
> 
> Actually, these exception notifers are kicked only if the debug exception
> is not related to kprobes (at least on x86). In that case, we don't have
> to take care about that. Or, would you hit any problem on it?

Well, I have faced issue on ARM64. So, if I have a kprobe instrumented at these
functions and then if I hit a uprobe then kernel goes into an infinite loop of
"Unexpected kernel single-step exception at EL1".

On x86 I have not tested, but I see that all functions except
arch_uprobe_exception_notify() in the call stack of
uprobe_pre/post_sstep_notifier() are blacklisted for kprobe. So, I am unable to
understand that why arch_uprobe_exception_notify() and
uprobe_pre/post_sstep_notifier() are not blacklisted.

> 
> IOW, where do we have to prohibit kprobes are, the code path from where 
> right after the breakpoint (debug) exception is occurred, to where right
> before the kprobe is handled. After that, it should be safe.

Hu...My understanding was that if a function a() is not good to be kprobed
then we can not kprobe any function called by a() as well. Thanks for the
clarification. So, if I go with your definition then, something is still wrong 
on
ARM64 which is causing issue when I kprobe uprobe_pre/post_sstep_notifier().

~Pratyush

> 
> Thank you,
> 
> 
> > 
> > Signed-off-by: Pratyush Anand 
> > ---
> >  kernel/events/uprobes.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> > index b7a525ab2083..206e594cb65e 100644
> > --- a/kernel/events/uprobes.c
> > +++ b/kernel/events/uprobes.c
> > @@ -37,6 +37,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  
> > @@ -1997,6 +1998,7 @@ int uprobe_pre_sstep_notifier(struct pt_regs *regs)
> > set_thread_flag(TIF_UPROBE);
> > return 1;
> >  }
> > +NOKPROBE_SYMBOL(uprobe_pre_sstep_notifier);
> >  
> >  /*
> >   * uprobe_post_sstep_notifier gets called in interrupt context as part of 
> > notifier
> > @@ -2014,6 +2016,7 @@ int uprobe_post_sstep_notifier(struct pt_regs *regs)
> > set_thread_flag(TIF_UPROBE);
> > return 1;
> >  }
> > +NOKPROBE_SYMBOL(uprobe_post_sstep_notifier);
> >  
> >  static struct notifier_block uprobe_exception_nb = {
> > .notifier_call  = arch_uprobe_exception_notify,
> > -- 
> > 2.5.5
> > 
> 
> 
> -- 
> Masami Hiramatsu 

[v9.2 PATCH 3/6] phy: Add USB Type-C PHY driver for rk3399

[Chris Zhong]

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
Type-C PHY is designed to support the USB3 and DP applications. The
PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and
HBR2 data rates. Hence, create 2 PHY deivces, the phy[0] for DP,
and phy[1] for USB3.

Signed-off-by: Chris Zhong 
Signed-off-by: Kever Yang 

---

Changes in v9.2:
- the new_mode should be int not u8
- move mutex_lock(>lock); to earlier place. in
  rockchip_usb3_phy_power_off

Changes in v9.1:
- better mutex lock for phy mode and flip

Changes in v9:
- split the Type-C PHY into two PHYs: USB3 and DP

Changes in v8:
- set the default cable id to EXTCON_USB_HOST
- optimization Error log

Changes in v7:
- support new API of extcon

Changes in v6:
- delete the support of PIN_ASSIGN_A/B
- set the default mode to MODE_DFP_USB
- disable DP PLL at USB3 only mode

Changes in v5:
- support get property from extcon
- remove PIN ASSIGN A/B support

Changes in v4:
- select EXTCON
- use phy framework to control the USB3 and DP function
- rename PIN_MAP_ to PIN_ASSIGN_

Changes in v3:
- remove the phy framework(Kishon Vijay Abraham I)
- add parentheses around the macro
- use a single space between type and name
- add spaces after opening and before closing braces.
- use u16 for register value
- remove type-c phy header file
- CodingStyle optimization
- use some cable extcon to get type-c port information
- add a extcon to notify Display Port

Changes in v2:
- select RESET_CONTROLLER
- alphabetic order
- modify some spelling mistakes
- make mode cleaner
- use bool for enable/disable
- check all of the return value
- return a better err number
- use more readx_poll_timeout()
- clk_disable_unprepare(tcphy->clk_ref);
- remove unuse functions, rockchip_typec_phy_power_on/off
- remove unnecessary typecast from void *
- use dts node to distinguish between phys.

Changes in v1:
- update the licence note
- init core clock to 50MHz
- use extcon API
- remove unused global
- add some comments for magic num
- change usleep_range(1000, 2000) tousleep_range(1000, 1050)
- remove __func__ from dev_err
- return err number when get clk failed
- remove ADDR_ADJ define
- use devm_clk_get(>dev, "tcpdcore")

 drivers/phy/Kconfig  |9 +
 drivers/phy/Makefile |1 +
 drivers/phy/phy-rockchip-typec.c | 1002 ++
 3 files changed, 1012 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-typec.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 26566db..83706a5 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -351,6 +351,15 @@ config PHY_ROCKCHIP_DP
help
  Enable this to support the Rockchip Display Port PHY.
 
+config PHY_ROCKCHIP_TYPEC
+   tristate "Rockchip TYPEC PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select EXTCON
+   select GENERIC_PHY
+   select RESET_CONTROLLER
+   help
+ Enable this to support the Rockchip USB TYPEC PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 24596a9..91fa413 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)   += 
phy-qcom-apq8064-sata.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
 obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
 obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
+obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-typec.c b/drivers/phy/phy-rockchip-typec.c
new file mode 100644
index 000..b09699b
--- /dev/null
+++ b/drivers/phy/phy-rockchip-typec.c
@@ -0,0 +1,1002 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong 
+ * Kever Yang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define CMN_SSM_BANDGAP(0x21 << 2)
+#define CMN_SSM_BIAS   (0x22 << 2)
+#define 

[v9.2 PATCH 3/6] phy: Add USB Type-C PHY driver for rk3399

[Chris Zhong]

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
Type-C PHY is designed to support the USB3 and DP applications. The
PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and
HBR2 data rates. Hence, create 2 PHY deivces, the phy[0] for DP,
and phy[1] for USB3.

Signed-off-by: Chris Zhong 
Signed-off-by: Kever Yang 

---

Changes in v9.2:
- the new_mode should be int not u8
- move mutex_lock(>lock); to earlier place. in
  rockchip_usb3_phy_power_off

Changes in v9.1:
- better mutex lock for phy mode and flip

Changes in v9:
- split the Type-C PHY into two PHYs: USB3 and DP

Changes in v8:
- set the default cable id to EXTCON_USB_HOST
- optimization Error log

Changes in v7:
- support new API of extcon

Changes in v6:
- delete the support of PIN_ASSIGN_A/B
- set the default mode to MODE_DFP_USB
- disable DP PLL at USB3 only mode

Changes in v5:
- support get property from extcon
- remove PIN ASSIGN A/B support

Changes in v4:
- select EXTCON
- use phy framework to control the USB3 and DP function
- rename PIN_MAP_ to PIN_ASSIGN_

Changes in v3:
- remove the phy framework(Kishon Vijay Abraham I)
- add parentheses around the macro
- use a single space between type and name
- add spaces after opening and before closing braces.
- use u16 for register value
- remove type-c phy header file
- CodingStyle optimization
- use some cable extcon to get type-c port information
- add a extcon to notify Display Port

Changes in v2:
- select RESET_CONTROLLER
- alphabetic order
- modify some spelling mistakes
- make mode cleaner
- use bool for enable/disable
- check all of the return value
- return a better err number
- use more readx_poll_timeout()
- clk_disable_unprepare(tcphy->clk_ref);
- remove unuse functions, rockchip_typec_phy_power_on/off
- remove unnecessary typecast from void *
- use dts node to distinguish between phys.

Changes in v1:
- update the licence note
- init core clock to 50MHz
- use extcon API
- remove unused global
- add some comments for magic num
- change usleep_range(1000, 2000) tousleep_range(1000, 1050)
- remove __func__ from dev_err
- return err number when get clk failed
- remove ADDR_ADJ define
- use devm_clk_get(>dev, "tcpdcore")

 drivers/phy/Kconfig  |9 +
 drivers/phy/Makefile |1 +
 drivers/phy/phy-rockchip-typec.c | 1002 ++
 3 files changed, 1012 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-typec.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 26566db..83706a5 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -351,6 +351,15 @@ config PHY_ROCKCHIP_DP
help
  Enable this to support the Rockchip Display Port PHY.
 
+config PHY_ROCKCHIP_TYPEC
+   tristate "Rockchip TYPEC PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select EXTCON
+   select GENERIC_PHY
+   select RESET_CONTROLLER
+   help
+ Enable this to support the Rockchip USB TYPEC PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 24596a9..91fa413 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)   += 
phy-qcom-apq8064-sata.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
 obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
 obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
+obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-typec.c b/drivers/phy/phy-rockchip-typec.c
new file mode 100644
index 000..b09699b
--- /dev/null
+++ b/drivers/phy/phy-rockchip-typec.c
@@ -0,0 +1,1002 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong 
+ * Kever Yang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define CMN_SSM_BANDGAP(0x21 << 2)
+#define CMN_SSM_BIAS   (0x22 << 2)
+#define CMN_PLLSM0_PLLEN   (0x29 << 2)
+#define CMN_PLLSM0_PLLPRE  (0x2a << 2)

Re: [PATCH -next v2] virtio: fix possible memory leak in virtqueue_add()

[Michael S. Tsirkin]

On Tue, Aug 02, 2016 at 02:16:31PM +, Wei Yongjun wrote:
> 'desc' is malloced in virtqueue_add() and should be freed before
> leaving from the error handling cases, otherwise it will cause
> memory leak.
> 
> Signed-off-by: Wei Yongjun 

Appliecd except I moved this to before END_USE - seems
cleaner as alloc is caller after START_USE.

> ---
>  drivers/virtio/virtio_ring.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index 114a0c8..e4be912 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -328,6 +328,8 @@ static inline int virtqueue_add(struct virtqueue *_vq,
>   if (out_sgs)
>   vq->notify(>vq);
>   END_USE(vq);
> + if (indirect)
> + kfree(desc);
>   return -ENOSPC;
>   }

Re: [PATCH -next v2] virtio: fix possible memory leak in virtqueue_add()

[Michael S. Tsirkin]

On Tue, Aug 02, 2016 at 02:16:31PM +, Wei Yongjun wrote:
> 'desc' is malloced in virtqueue_add() and should be freed before
> leaving from the error handling cases, otherwise it will cause
> memory leak.
> 
> Signed-off-by: Wei Yongjun 

Appliecd except I moved this to before END_USE - seems
cleaner as alloc is caller after START_USE.

> ---
>  drivers/virtio/virtio_ring.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index 114a0c8..e4be912 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -328,6 +328,8 @@ static inline int virtqueue_add(struct virtqueue *_vq,
>   if (out_sgs)
>   vq->notify(>vq);
>   END_USE(vq);
> + if (indirect)
> + kfree(desc);
>   return -ENOSPC;
>   }

[PATCH] virtio: fix error handling for debug builds

[Michael S. Tsirkin]

On error, virtqueue_add calls START_USE but not
END_USE. Thankfully that's normally empty anyway,
but might not be when debugging. Fix it up.

Signed-off-by: Michael S. Tsirkin 
---
 drivers/virtio/virtio_ring.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 5ed228d..e383ecd 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -428,6 +428,7 @@ unmap_release:
if (indirect)
kfree(desc);
 
+   END_USE(vq);
return -EIO;
 }
 
-- 
MST

[PATCH] virtio: fix error handling for debug builds

[Michael S. Tsirkin]

On error, virtqueue_add calls START_USE but not
END_USE. Thankfully that's normally empty anyway,
but might not be when debugging. Fix it up.

Signed-off-by: Michael S. Tsirkin 
---
 drivers/virtio/virtio_ring.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 5ed228d..e383ecd 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -428,6 +428,7 @@ unmap_release:
if (indirect)
kfree(desc);
 
+   END_USE(vq);
return -EIO;
 }
 
-- 
MST

Re: [PATCH] uprobe: Add uprobe_pre/post_sstep_notifier to NOKPROBE_SYMBOL

[Pratyush Anand]

Hi Oleg,

On 02/08/2016:10:30:35 PM, Oleg Nesterov wrote:
> On 08/02, Pratyush Anand wrote:
> >
> > uprobe_pre_sstep_notifier and uprobe_post_sstep_notifier are called from
> > debug exception handler, so blacklist them for kprobing.
> 
> Let me add kprobes maintainers, I am a bit confused...
> 
> > @@ -1997,6 +1998,7 @@ int uprobe_pre_sstep_notifier(struct pt_regs *regs)
> > set_thread_flag(TIF_UPROBE);
> > return 1;
> >  }
> > +NOKPROBE_SYMBOL(uprobe_pre_sstep_notifier);
> >
> >  /*
> >   * uprobe_post_sstep_notifier gets called in interrupt context as part of 
> > notifier
> > @@ -2014,6 +2016,7 @@ int uprobe_post_sstep_notifier(struct pt_regs *regs)
> > set_thread_flag(TIF_UPROBE);
> > return 1;
> >  }
> > +NOKPROBE_SYMBOL(uprobe_post_sstep_notifier);
> 
> but if we need to blacklist uprobe_pre/post_sstep_notifier then we
> also need to blacklist their caller, arch_uprobe_exception_notify() ?

I think yes, in ARM64 I have done that. However, arm64 does not use notifier
method, so arch_uprobe_exception_notify() is just a dummy function for it.

> 
> and every .notifier_call used in register_die_notifier() ?

I tried to look into x86 notify path related to 
uprobe_pre/post_sstep_notifier().
I see that calling sequence is like do_int3()-> notify_die() ->
atomic_notifier_call_chain() -> __atomic_notifier_call_chain() ->
notifier_call_chain() -> arch_uprobe_exception_notify().

In this sequence, every function is blacklisted for kprobe except
arch_uprobe_exception_notify(). So, I am unable to understand, if
notifier_call_chain() is not safe for kprobe then how can it be safe for a
function it calls.

~Pratyush

Re: [PATCH] uprobe: Add uprobe_pre/post_sstep_notifier to NOKPROBE_SYMBOL

[Pratyush Anand]

Hi Oleg,

On 02/08/2016:10:30:35 PM, Oleg Nesterov wrote:
> On 08/02, Pratyush Anand wrote:
> >
> > uprobe_pre_sstep_notifier and uprobe_post_sstep_notifier are called from
> > debug exception handler, so blacklist them for kprobing.
> 
> Let me add kprobes maintainers, I am a bit confused...
> 
> > @@ -1997,6 +1998,7 @@ int uprobe_pre_sstep_notifier(struct pt_regs *regs)
> > set_thread_flag(TIF_UPROBE);
> > return 1;
> >  }
> > +NOKPROBE_SYMBOL(uprobe_pre_sstep_notifier);
> >
> >  /*
> >   * uprobe_post_sstep_notifier gets called in interrupt context as part of 
> > notifier
> > @@ -2014,6 +2016,7 @@ int uprobe_post_sstep_notifier(struct pt_regs *regs)
> > set_thread_flag(TIF_UPROBE);
> > return 1;
> >  }
> > +NOKPROBE_SYMBOL(uprobe_post_sstep_notifier);
> 
> but if we need to blacklist uprobe_pre/post_sstep_notifier then we
> also need to blacklist their caller, arch_uprobe_exception_notify() ?

I think yes, in ARM64 I have done that. However, arm64 does not use notifier
method, so arch_uprobe_exception_notify() is just a dummy function for it.

> 
> and every .notifier_call used in register_die_notifier() ?

I tried to look into x86 notify path related to 
uprobe_pre/post_sstep_notifier().
I see that calling sequence is like do_int3()-> notify_die() ->
atomic_notifier_call_chain() -> __atomic_notifier_call_chain() ->
notifier_call_chain() -> arch_uprobe_exception_notify().

In this sequence, every function is blacklisted for kprobe except
arch_uprobe_exception_notify(). So, I am unable to understand, if
notifier_call_chain() is not safe for kprobe then how can it be safe for a
function it calls.

~Pratyush

Re: [PATCH] Support resetting WARN*_ONCE

[kbuild test robot]

Hi Andi,

[auto build test ERROR on asm-generic/master]
[also build test ERROR on v4.7 next-20160802]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andi-Kleen/Support-resetting-WARN-_ONCE/20160803-112312
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git 
master
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   kernel/panic.c: In function 'clear_warn_once_set':
>> kernel/panic.c:557:9: error: '__start_once' undeclared (first use in this 
>> function)
 memset(__start_once, 0, __end_once - __start_once);
^
   kernel/panic.c:557:9: note: each undeclared identifier is reported only once 
for each function it appears in
>> kernel/panic.c:557:26: error: '__end_once' undeclared (first use in this 
>> function)
 memset(__start_once, 0, __end_once - __start_once);
 ^

vim +/__start_once +557 kernel/panic.c

   551  #endif
   552  
   553  /* Support resetting WARN*_ONCE state */
   554  
   555  static int clear_warn_once_set(void *data, u64 val)
   556  {
 > 557  memset(__start_once, 0, __end_once - __start_once);
   558  return 0;
   559  }
   560  

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


.config.gz
Description: Binary data

Re: [PATCH] Support resetting WARN*_ONCE

[kbuild test robot]

Hi Andi,

[auto build test ERROR on asm-generic/master]
[also build test ERROR on v4.7 next-20160802]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andi-Kleen/Support-resetting-WARN-_ONCE/20160803-112312
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git 
master
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   kernel/panic.c: In function 'clear_warn_once_set':
>> kernel/panic.c:557:9: error: '__start_once' undeclared (first use in this 
>> function)
 memset(__start_once, 0, __end_once - __start_once);
^
   kernel/panic.c:557:9: note: each undeclared identifier is reported only once 
for each function it appears in
>> kernel/panic.c:557:26: error: '__end_once' undeclared (first use in this 
>> function)
 memset(__start_once, 0, __end_once - __start_once);
 ^

vim +/__start_once +557 kernel/panic.c

   551  #endif
   552  
   553  /* Support resetting WARN*_ONCE state */
   554  
   555  static int clear_warn_once_set(void *data, u64 val)
   556  {
 > 557  memset(__start_once, 0, __end_once - __start_once);
   558  return 0;
   559  }
   560  

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


.config.gz
Description: Binary data

Re: [PATCH stable 4.6+] radix-tree: account nodes to memcg only if explicitly requested

[Greg KH]

On Tue, Aug 02, 2016 at 03:45:34PM +0300, Vladimir Davydov wrote:
> Radix trees may be used not only for storing page cache pages, so
> unconditionally accounting radix tree nodes to the current memory cgroup
> is bad: if a radix tree node is used for storing data shared among
> different cgroups we risk pinning dead memory cgroups forever. So let's
> only account radix tree nodes if it was explicitly requested by passing
> __GFP_ACCOUNT to INIT_RADIX_TREE. Currently, we only want to account
> page cache entries, so mark mapping->page_tree so.
> 
> Signed-off-by: Vladimir Davydov 
> Acked-by: Johannes Weiner 
> Acked-by: Michal Hocko 
> Cc:   [4.6+]
> ---
>  fs/inode.c   |  2 +-
>  lib/radix-tree.c | 14 ++
>  2 files changed, 11 insertions(+), 5 deletions(-)

Is this patch in Linus's tree already?

confused,

greg k-h

Re: [PATCH stable 4.6+] radix-tree: account nodes to memcg only if explicitly requested

[Greg KH]

On Tue, Aug 02, 2016 at 03:45:34PM +0300, Vladimir Davydov wrote:
> Radix trees may be used not only for storing page cache pages, so
> unconditionally accounting radix tree nodes to the current memory cgroup
> is bad: if a radix tree node is used for storing data shared among
> different cgroups we risk pinning dead memory cgroups forever. So let's
> only account radix tree nodes if it was explicitly requested by passing
> __GFP_ACCOUNT to INIT_RADIX_TREE. Currently, we only want to account
> page cache entries, so mark mapping->page_tree so.
> 
> Signed-off-by: Vladimir Davydov 
> Acked-by: Johannes Weiner 
> Acked-by: Michal Hocko 
> Cc:   [4.6+]
> ---
>  fs/inode.c   |  2 +-
>  lib/radix-tree.c | 14 ++
>  2 files changed, 11 insertions(+), 5 deletions(-)

Is this patch in Linus's tree already?

confused,

greg k-h

[PATCH v6 0/2] Input: SiS 9200 family I2C touchscreen controller driver

[mika.penttila]

Hi,

Here are the v6 patches for SiS 9200 I2C multitouch controller.
Cleanups, fixes and simplifications from the last review are included.

Rebased to 4.7.

Thanks,
Mika

[PATCH v6 1/2] Input: Driver for SiS-9200 family I2C touchscreen controller
[PATCH v6 2/2] Input: SiS 9200 documentation parts

[PATCH v6 0/2] Input: SiS 9200 family I2C touchscreen controller driver

[mika.penttila]

Hi,

Here are the v6 patches for SiS 9200 I2C multitouch controller.
Cleanups, fixes and simplifications from the last review are included.

Rebased to 4.7.

Thanks,
Mika

[PATCH v6 1/2] Input: Driver for SiS-9200 family I2C touchscreen controller
[PATCH v6 2/2] Input: SiS 9200 documentation parts

Re: [PATCH RESEND v4] locking/pvqspinlock: Fix double hash race

[Waiman Long]

On 07/27/2016 07:30 AM, Wanpeng Li wrote:

From: Wanpeng Li

When the lock holder vCPU is racing with the queue head vCPU:

lock holder vCPU queue head vCPU
===

node->locked = 1;
  READ_ONCE(node->locked)
...   pv_wait_head_or_lock():
SPIN_THRESHOLD loop;
pv_hash();
lock->locked = _Q_SLOW_VAL;
node->state  = vcpu_hashed;
pv_kick_node():
   cmpxchg(node->state,
  vcpu_halted, vcpu_hashed);
   lock->locked = _Q_SLOW_VAL;
   pv_hash();

With preemption at the right moment, it is possible that both the
lock holder and queue head vCPUs can be racing to set node->state
which can result in hash entry race. Making sure the state is never
set to vcpu_halted will prevent this racing from happening.

This patch fix it by setting vcpu_hashed after we did all hash thing.

Reviewed-by: Davidlohr Bueso
Reviewed-by: Pan Xinhui
Cc: Peter Zijlstra (Intel)
Cc: Ingo Molnar
Cc: Waiman Long
Cc: Davidlohr Bueso
Signed-off-by: Wanpeng Li
---
v3 ->  v4:
  * update patch subject
  * add code comments
v2 ->  v3:
  * fix typo in patch description
v1 ->  v2:
  * adjust patch description

  kernel/locking/qspinlock_paravirt.h | 23 ++-
  1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/kernel/locking/qspinlock_paravirt.h 
b/kernel/locking/qspinlock_paravirt.h
index 21ede57..ca96db4 100644
--- a/kernel/locking/qspinlock_paravirt.h
+++ b/kernel/locking/qspinlock_paravirt.h
@@ -450,7 +450,28 @@ pv_wait_head_or_lock(struct qspinlock *lock, struct 
mcs_spinlock *node)
goto gotlock;
}
}
-   WRITE_ONCE(pn->state, vcpu_halted);
+   /*
+* lock holder vCPU queue head vCPU
+*  ---
+* node->locked = 1;
+*  READ_ONCE(node->locked)
+*...   pv_wait_head_or_lock():
+*SPIN_THRESHOLD loop;
+*pv_hash();
+*lock->locked = _Q_SLOW_VAL;
+*node->state  = vcpu_hashed;
+* pv_kick_node():
+*   cmpxchg(node->state,
+*  vcpu_halted, vcpu_hashed);
+*   lock->locked = _Q_SLOW_VAL;
+*   pv_hash();
+*
+* With preemption at the right moment, it is possible that 
both the
+* lock holder and queue head vCPUs can be racing to set 
node->state.
+* Making sure the state is never set to vcpu_halted will 
prevent this
+* racing from happening.
+*/
+   WRITE_ONCE(pn->state, vcpu_hashed);
qstat_inc(qstat_pv_wait_head, true);
qstat_inc(qstat_pv_wait_again, waitcnt);
pv_wait(>locked, _Q_SLOW_VAL);


Acked-by: Waiman Long 

Cheers,
Longman

Re: [PATCH RESEND v4] locking/pvqspinlock: Fix double hash race

[Waiman Long]

On 07/27/2016 07:30 AM, Wanpeng Li wrote:

From: Wanpeng Li

When the lock holder vCPU is racing with the queue head vCPU:

lock holder vCPU queue head vCPU
===

node->locked = 1;
  READ_ONCE(node->locked)
...   pv_wait_head_or_lock():
SPIN_THRESHOLD loop;
pv_hash();
lock->locked = _Q_SLOW_VAL;
node->state  = vcpu_hashed;
pv_kick_node():
   cmpxchg(node->state,
  vcpu_halted, vcpu_hashed);
   lock->locked = _Q_SLOW_VAL;
   pv_hash();

With preemption at the right moment, it is possible that both the
lock holder and queue head vCPUs can be racing to set node->state
which can result in hash entry race. Making sure the state is never
set to vcpu_halted will prevent this racing from happening.

This patch fix it by setting vcpu_hashed after we did all hash thing.

Reviewed-by: Davidlohr Bueso
Reviewed-by: Pan Xinhui
Cc: Peter Zijlstra (Intel)
Cc: Ingo Molnar
Cc: Waiman Long
Cc: Davidlohr Bueso
Signed-off-by: Wanpeng Li
---
v3 ->  v4:
  * update patch subject
  * add code comments
v2 ->  v3:
  * fix typo in patch description
v1 ->  v2:
  * adjust patch description

  kernel/locking/qspinlock_paravirt.h | 23 ++-
  1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/kernel/locking/qspinlock_paravirt.h 
b/kernel/locking/qspinlock_paravirt.h
index 21ede57..ca96db4 100644
--- a/kernel/locking/qspinlock_paravirt.h
+++ b/kernel/locking/qspinlock_paravirt.h
@@ -450,7 +450,28 @@ pv_wait_head_or_lock(struct qspinlock *lock, struct 
mcs_spinlock *node)
goto gotlock;
}
}
-   WRITE_ONCE(pn->state, vcpu_halted);
+   /*
+* lock holder vCPU queue head vCPU
+*  ---
+* node->locked = 1;
+*  READ_ONCE(node->locked)
+*...   pv_wait_head_or_lock():
+*SPIN_THRESHOLD loop;
+*pv_hash();
+*lock->locked = _Q_SLOW_VAL;
+*node->state  = vcpu_hashed;
+* pv_kick_node():
+*   cmpxchg(node->state,
+*  vcpu_halted, vcpu_hashed);
+*   lock->locked = _Q_SLOW_VAL;
+*   pv_hash();
+*
+* With preemption at the right moment, it is possible that 
both the
+* lock holder and queue head vCPUs can be racing to set 
node->state.
+* Making sure the state is never set to vcpu_halted will 
prevent this
+* racing from happening.
+*/
+   WRITE_ONCE(pn->state, vcpu_hashed);
qstat_inc(qstat_pv_wait_head, true);
qstat_inc(qstat_pv_wait_again, waitcnt);
pv_wait(>locked, _Q_SLOW_VAL);


Acked-by: Waiman Long 

Cheers,
Longman

linux-next: Tree for Aug 3

[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 20160802:

My fixes tree is empty again.

Non-merge commits (relative to Linus' tree): 1166
 1375 files changed, 45683 insertions(+), 12773 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 241 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 (c8d0267efdb4 Merge tag 'pci-v4.8-changes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci)
Merging fixes/master (77a87824ed67 clocksource/drivers/clps_711x: fixup for 
"ARM: clps711x:)
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 (bad60e6f259a Merge tag 'powerpc-4.8-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging net/master (1d2c2024dcb7 qed: Fail driver load in 100g MSI mode.)
Merging ipsec/master (6916fb3b10b3 xfrm: Ignore socket policies when rebuilding 
hash tables)
Merging netfilter/master (43dcff349f09 net: qlcnic: avoid superfluous 
assignement)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git)
Merging mac80211/master (4e3f21bc7bfb mac80211: fix check for buffered 
powersave frames with txq)
Merging sound-current/for-linus (9b51fe3efe4c ALSA: hda - On-board speaker 
fixup on ACER Veriton)
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 (8cf740ae85df crypto: marvell - Don't copy IV 
vectors from the _process op for ciphers)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (ce7585f3c4d7 vfio/pci: Allo

[PATCH 2/2] KVM: lapic: don't recalculate apic map table twice when enabling LAPIC

[Wanpeng Li]

From: Wanpeng Li 

APIC map table is recalculated during reset APIC ID to the initial value
when enabling LAPIC. This patch move the recalculate_apic_map() to the 
next branch since we don't need to recalculate apic map twice in current
codes.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/lapic.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 0120a58..d676f4b 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1760,9 +1760,10 @@ void kvm_lapic_set_base(struct kvm_vcpu *vcpu, u64 value)
if (value & MSR_IA32_APICBASE_ENABLE) {
kvm_apic_set_xapic_id(apic, vcpu->vcpu_id);
static_key_slow_dec_deferred(_hw_disabled);
-   } else
+   } else {
static_key_slow_inc(_hw_disabled.key);
-   recalculate_apic_map(vcpu->kvm);
+   recalculate_apic_map(vcpu->kvm);
+   }
}
 
if ((old_value ^ value) & X2APIC_ENABLE) {
-- 
1.9.1

[PATCH 1/2] KVM: lapic: fix access preemption timer stuff even if kernel_irqchip=off

[Wanpeng Li]

From: Wanpeng Li 

BUG: unable to handle kernel NULL pointer dereference at 008c
IP: [] kvm_lapic_hv_timer_in_use+0x10/0x20 [kvm]
PGD 0 
Oops:  [#1] SMP
Call Trace:
 kvm_arch_vcpu_load+0x86/0x260 [kvm]
 vcpu_load+0x46/0x60 [kvm]
 kvm_vcpu_ioctl+0x79/0x7c0 [kvm]
 ? __lock_is_held+0x54/0x70
 do_vfs_ioctl+0x96/0x6a0
 ? __fget_light+0x2a/0x90
 SyS_ioctl+0x79/0x90
 do_syscall_64+0x7c/0x1e0
 entry_SYSCALL64_slow_path+0x25/0x25
RIP  [] kvm_lapic_hv_timer_in_use+0x10/0x20 [kvm]
 RSP 
CR2: 008c
---[ end trace a55fb79d2b3b4ee8 ]---

This can be reproduced steadily by kernel_irqchip=off.

We should not access preemption timer stuff if lapic is emulated in userspace.
This patch fix it by avoiding access preemption timer stuff when 
kernel_irqchip=off.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Yunhong Jiang 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/lapic.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 6895fd2..0120a58 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1348,6 +1348,9 @@ static void start_sw_tscdeadline(struct kvm_lapic *apic)
 
 bool kvm_lapic_hv_timer_in_use(struct kvm_vcpu *vcpu)
 {
+   if (!lapic_in_kernel(vcpu))
+   return false;
+
return vcpu->arch.apic->lapic_timer.hv_timer_in_use;
 }
 EXPORT_SYMBOL_GPL(kvm_lapic_hv_timer_in_use);
-- 
1.9.1

linux-next: Tree for Aug 3

[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 20160802:

My fixes tree is empty again.

Non-merge commits (relative to Linus' tree): 1166
 1375 files changed, 45683 insertions(+), 12773 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 241 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 (c8d0267efdb4 Merge tag 'pci-v4.8-changes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci)
Merging fixes/master (77a87824ed67 clocksource/drivers/clps_711x: fixup for 
"ARM: clps711x:)
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 (bad60e6f259a Merge tag 'powerpc-4.8-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging net/master (1d2c2024dcb7 qed: Fail driver load in 100g MSI mode.)
Merging ipsec/master (6916fb3b10b3 xfrm: Ignore socket policies when rebuilding 
hash tables)
Merging netfilter/master (43dcff349f09 net: qlcnic: avoid superfluous 
assignement)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git)
Merging mac80211/master (4e3f21bc7bfb mac80211: fix check for buffered 
powersave frames with txq)
Merging sound-current/for-linus (9b51fe3efe4c ALSA: hda - On-board speaker 
fixup on ACER Veriton)
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 (8cf740ae85df crypto: marvell - Don't copy IV 
vectors from the _process op for ciphers)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (ce7585f3c4d7 vfio/pci: Allo

[PATCH 2/2] KVM: lapic: don't recalculate apic map table twice when enabling LAPIC

[Wanpeng Li]

From: Wanpeng Li 

APIC map table is recalculated during reset APIC ID to the initial value
when enabling LAPIC. This patch move the recalculate_apic_map() to the 
next branch since we don't need to recalculate apic map twice in current
codes.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/lapic.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 0120a58..d676f4b 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1760,9 +1760,10 @@ void kvm_lapic_set_base(struct kvm_vcpu *vcpu, u64 value)
if (value & MSR_IA32_APICBASE_ENABLE) {
kvm_apic_set_xapic_id(apic, vcpu->vcpu_id);
static_key_slow_dec_deferred(_hw_disabled);
-   } else
+   } else {
static_key_slow_inc(_hw_disabled.key);
-   recalculate_apic_map(vcpu->kvm);
+   recalculate_apic_map(vcpu->kvm);
+   }
}
 
if ((old_value ^ value) & X2APIC_ENABLE) {
-- 
1.9.1

[PATCH 1/2] KVM: lapic: fix access preemption timer stuff even if kernel_irqchip=off

[Wanpeng Li]

From: Wanpeng Li 

BUG: unable to handle kernel NULL pointer dereference at 008c
IP: [] kvm_lapic_hv_timer_in_use+0x10/0x20 [kvm]
PGD 0 
Oops:  [#1] SMP
Call Trace:
 kvm_arch_vcpu_load+0x86/0x260 [kvm]
 vcpu_load+0x46/0x60 [kvm]
 kvm_vcpu_ioctl+0x79/0x7c0 [kvm]
 ? __lock_is_held+0x54/0x70
 do_vfs_ioctl+0x96/0x6a0
 ? __fget_light+0x2a/0x90
 SyS_ioctl+0x79/0x90
 do_syscall_64+0x7c/0x1e0
 entry_SYSCALL64_slow_path+0x25/0x25
RIP  [] kvm_lapic_hv_timer_in_use+0x10/0x20 [kvm]
 RSP 
CR2: 008c
---[ end trace a55fb79d2b3b4ee8 ]---

This can be reproduced steadily by kernel_irqchip=off.

We should not access preemption timer stuff if lapic is emulated in userspace.
This patch fix it by avoiding access preemption timer stuff when 
kernel_irqchip=off.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Yunhong Jiang 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/lapic.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 6895fd2..0120a58 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1348,6 +1348,9 @@ static void start_sw_tscdeadline(struct kvm_lapic *apic)
 
 bool kvm_lapic_hv_timer_in_use(struct kvm_vcpu *vcpu)
 {
+   if (!lapic_in_kernel(vcpu))
+   return false;
+
return vcpu->arch.apic->lapic_timer.hv_timer_in_use;
 }
 EXPORT_SYMBOL_GPL(kvm_lapic_hv_timer_in_use);
-- 
1.9.1

Re: [GIT PULL] KVM changes for 4.8 merge window

[Michael Ellerman]

Paolo Bonzini  writes:
...
> - arch/powerpc: what a mess.  For the idle_book3s.S conflict, the KVM
> tree is the right one; everything else is trivial.  In this case I am
> not quite sure what went wrong.  The commit that is causing the mess
> (fd7bacbca47a, "KVM: PPC: Book3S HV: Fix TB corruption in guest exit
> path on HMI interrupt", 2016-05-15) touches both arch/powerpc/kernel/
> and arch/powerpc/kvm/.  It's large, but at 396 insertions/5 deletions
> I guessed that it wasn't really possible to split it and that the 5
> deletions wouldn't conflict.  That wasn't the case.

In fact I think the problem is that this patch shouldn't have gone via the KVM
tree at all.

If you look at the diffstat, it doesn't touch anything in generic KVM, but lots
of arch code:

 arch/powerpc/include/asm/hmi.h  |  45 
 arch/powerpc/include/asm/paca.h |   6 +++
 arch/powerpc/kernel/Makefile|   2 +-
 arch/powerpc/kernel/exceptions-64s.S|   4 +-
 arch/powerpc/kernel/hmi.c   |  56 +
 arch/powerpc/kernel/idle_power7.S   |   5 ++-
 arch/powerpc/kernel/traps.c |   5 +++
 arch/powerpc/kvm/book3s_hv.c|  37 +
 arch/powerpc/kvm/book3s_hv_ras.c| 176 
++
 arch/powerpc/kvm/book3s_hv_rmhandlers.S |  65 -


Presumably Paul wanted it in his kvm-ppc tree so it would be tested with the
rest of the KVM stuff, but we should have done that with a topic branch in the
powerpc tree, that we both merged.

cheers

Re: [GIT PULL] KVM changes for 4.8 merge window

[Michael Ellerman]

Paolo Bonzini  writes:
...
> - arch/powerpc: what a mess.  For the idle_book3s.S conflict, the KVM
> tree is the right one; everything else is trivial.  In this case I am
> not quite sure what went wrong.  The commit that is causing the mess
> (fd7bacbca47a, "KVM: PPC: Book3S HV: Fix TB corruption in guest exit
> path on HMI interrupt", 2016-05-15) touches both arch/powerpc/kernel/
> and arch/powerpc/kvm/.  It's large, but at 396 insertions/5 deletions
> I guessed that it wasn't really possible to split it and that the 5
> deletions wouldn't conflict.  That wasn't the case.

In fact I think the problem is that this patch shouldn't have gone via the KVM
tree at all.

If you look at the diffstat, it doesn't touch anything in generic KVM, but lots
of arch code:

 arch/powerpc/include/asm/hmi.h  |  45 
 arch/powerpc/include/asm/paca.h |   6 +++
 arch/powerpc/kernel/Makefile|   2 +-
 arch/powerpc/kernel/exceptions-64s.S|   4 +-
 arch/powerpc/kernel/hmi.c   |  56 +
 arch/powerpc/kernel/idle_power7.S   |   5 ++-
 arch/powerpc/kernel/traps.c |   5 +++
 arch/powerpc/kvm/book3s_hv.c|  37 +
 arch/powerpc/kvm/book3s_hv_ras.c| 176 
++
 arch/powerpc/kvm/book3s_hv_rmhandlers.S |  65 -


Presumably Paul wanted it in his kvm-ppc tree so it would be tested with the
rest of the KVM stuff, but we should have done that with a topic branch in the
powerpc tree, that we both merged.

cheers

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

[Alan Curry]

Al Viro wrote:
> 
> Which just might mean that we have *three* issues here -
>   (1) buggered __copy_to_user_inatomic() (and friends) on some sparcs
>   (2) your ssl-only corruption
>   (3) Alan's x86_64 corruption on plain TCP read - no ssl *or* sparc
> anywhere, and no multi-segment recvmsg().  Which would strongly argue in
> favour of some kind of copy_page_to_iter() breakage triggered when handling
> a fragmented skb, as in (1).  Except that I don't see anything similar in
> x86_64 uaccess primitives...
> 

I think I've solved (3) at least...

Using the twin weapons of printk and stubbornness, I have built a working
theory of the bug. I haven't traced it all the way through, so my explanation
may be partly wrong. I do have a patch that eliminates the symptom in all my
tests though. Here's what happens:

A corrupted packet somehow arrives in skb_copy_and_csum_datagram_msg().
During downloads at reasonably high speed, about 0.1% of my incoming
packets are bad. Probably because the access point is that suspicious
Comcast thing.

skb_copy_and_csum_datagram_msg() does this:

if (skb_copy_and_csum_datagram(skb, hlen, >msg_iter,
   chunk, ))
goto fault;
if (csum_fold(csum))
goto csum_error;

skb_copy_and_csum_datagram() copies the bad data, computes the checksum,
and *advances the iterator*. The checksum is bad, so it goes to
csum_error, which returns without indicating success to userspace, but the
bad data is in the userspace buffer, and since the iterator has advanced,
the proper data doesn't get written to the proper place when it arrives in a
retransmission. The same iterator is still used because we're still in the
same syscall (I guess - this is one of the parts I didn't check out).

My ugly patch fixes this in the most obvious way: make a local copy of
msg->msg_iter before the call to skb_copy_and_csum_datagram(), and copy it
back if the checksum is bad, just before "goto csum_error;". (I wonder if the
other failure exits from this function might need to do the same thing.)

You can probably reproduce this problem if you deliberately inject some
bad TCP checksums into a stream. Just make sure the receiving machine is
in a blocking read() on the socket when the bad packet arrives. You may
need to resend the offending packet afterward with the checksum corrected.

diff --git a/net/core/datagram.c b/net/core/datagram.c
index b7de71f..574d4bf 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -730,6 +730,7 @@ int skb_copy_and_csum_datagram_msg(struct sk_buff *skb,
 {
__wsum csum;
int chunk = skb->len - hlen;
+   struct iov_iter save_iter;
 
if (!chunk)
return 0;
@@ -741,11 +742,14 @@ int skb_copy_and_csum_datagram_msg(struct sk_buff *skb,
goto fault;
} else {
csum = csum_partial(skb->data, hlen, skb->csum);
+   memcpy(_iter, >msg_iter, sizeof save_iter);
if (skb_copy_and_csum_datagram(skb, hlen, >msg_iter,
   chunk, ))
goto fault;
-   if (csum_fold(csum))
+   if (csum_fold(csum)) {
+   memcpy(>msg_iter, _iter, sizeof save_iter);
goto csum_error;
+   }
if (unlikely(skb->ip_summed == CHECKSUM_COMPLETE))
netdev_rx_csum_fault(skb->dev);
}

-- 
Alan Curry

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

[Alan Curry]

Al Viro wrote:
> 
> Which just might mean that we have *three* issues here -
>   (1) buggered __copy_to_user_inatomic() (and friends) on some sparcs
>   (2) your ssl-only corruption
>   (3) Alan's x86_64 corruption on plain TCP read - no ssl *or* sparc
> anywhere, and no multi-segment recvmsg().  Which would strongly argue in
> favour of some kind of copy_page_to_iter() breakage triggered when handling
> a fragmented skb, as in (1).  Except that I don't see anything similar in
> x86_64 uaccess primitives...
> 

I think I've solved (3) at least...

Using the twin weapons of printk and stubbornness, I have built a working
theory of the bug. I haven't traced it all the way through, so my explanation
may be partly wrong. I do have a patch that eliminates the symptom in all my
tests though. Here's what happens:

A corrupted packet somehow arrives in skb_copy_and_csum_datagram_msg().
During downloads at reasonably high speed, about 0.1% of my incoming
packets are bad. Probably because the access point is that suspicious
Comcast thing.

skb_copy_and_csum_datagram_msg() does this:

if (skb_copy_and_csum_datagram(skb, hlen, >msg_iter,
   chunk, ))
goto fault;
if (csum_fold(csum))
goto csum_error;

skb_copy_and_csum_datagram() copies the bad data, computes the checksum,
and *advances the iterator*. The checksum is bad, so it goes to
csum_error, which returns without indicating success to userspace, but the
bad data is in the userspace buffer, and since the iterator has advanced,
the proper data doesn't get written to the proper place when it arrives in a
retransmission. The same iterator is still used because we're still in the
same syscall (I guess - this is one of the parts I didn't check out).

My ugly patch fixes this in the most obvious way: make a local copy of
msg->msg_iter before the call to skb_copy_and_csum_datagram(), and copy it
back if the checksum is bad, just before "goto csum_error;". (I wonder if the
other failure exits from this function might need to do the same thing.)

You can probably reproduce this problem if you deliberately inject some
bad TCP checksums into a stream. Just make sure the receiving machine is
in a blocking read() on the socket when the bad packet arrives. You may
need to resend the offending packet afterward with the checksum corrected.

diff --git a/net/core/datagram.c b/net/core/datagram.c
index b7de71f..574d4bf 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -730,6 +730,7 @@ int skb_copy_and_csum_datagram_msg(struct sk_buff *skb,
 {
__wsum csum;
int chunk = skb->len - hlen;
+   struct iov_iter save_iter;
 
if (!chunk)
return 0;
@@ -741,11 +742,14 @@ int skb_copy_and_csum_datagram_msg(struct sk_buff *skb,
goto fault;
} else {
csum = csum_partial(skb->data, hlen, skb->csum);
+   memcpy(_iter, >msg_iter, sizeof save_iter);
if (skb_copy_and_csum_datagram(skb, hlen, >msg_iter,
   chunk, ))
goto fault;
-   if (csum_fold(csum))
+   if (csum_fold(csum)) {
+   memcpy(>msg_iter, _iter, sizeof save_iter);
goto csum_error;
+   }
if (unlikely(skb->ip_summed == CHECKSUM_COMPLETE))
netdev_rx_csum_fault(skb->dev);
}

-- 
Alan Curry

Re: perf test BPF failing on f24: fix

[Wangnan (F)]

On 2016/8/3 10:41, Wangnan (F) wrote:



On 2016/8/3 3:51, Arnaldo Carvalho de Melo wrote:

Hi Wang,

Something changed and a function used in a perf test for BPF is
not anymore appearing on vmlinux, albeit still available on
/proc/kallsyms:

# readelf -wi /lib/modules/4.7.0+/build/vmlinux | grep -w sys_epoll_wait
#

But:

[root@jouet ~]# grep -i sys_epoll_wait /proc/kallsyms
bd295b50 T SyS_epoll_wait
bd295b50 T sys_epoll_wait
[root@jouet ~]#

I noticed that it is some sort of aliasing so I checked the other
variant:

[root@jouet ~]# readelf -wi /lib/modules/4.7.0+/build/vmlinux | grep 
-w SyS_epoll_wait
 <2bc9b85>   DW_AT_name: (indirect string, offset: 
0xe7524): SyS_epoll_wait

[root@jouet ~]#


I also see no sys_epoll_wait in output of 'readelf -wi', but I can't
reproduce the whole problem.


Trying to use perf probe also produces the same resuls I notice when
running the perf test that is failing:

[root@jouet ~]# perf probe sys_epoll_wait
Failed to find debug information for address bd295b50
Probe point 'sys_epoll_wait' not found.
   Error: Failed to add events.


For me:

# uname -r
4.7.0

# perf probe -v sys_epoll_wait
probe-definition(0): sys_epoll_wait
symbol:sys_epoll_wait file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Looking at the vmlinux_path (8 entries long)
Using /lib/modules/4.7.0/build/vmlinux for symbols
Open Debuginfo file: /lib/modules/4.7.0/build/vmlinux
Try to find probe point from debuginfo.
Symbol sys_epoll_wait address found : 81281240
Matched function: SyS_epoll_wait
found inline addr: 0x81281240
Probe point found: SyS_epoll_wait+0
found inline addr: 0x812813a7
Probe point found: SyS_epoll_pwait+135
found inline addr: 0x8128157a
Probe point found: compat_SyS_epoll_pwait+154
Found 3 probe_trace_events.
Opening /sys/kernel/debug/tracing//kprobe_events write=1
Writing event: p:probe/sys_epoll_wait _text+2626112
Writing event: p:probe/sys_epoll_wait_1 _text+2626471
Writing event: p:probe/sys_epoll_wait_2 _text+2626938
Added new events:
  probe:sys_epoll_wait (on sys_epoll_wait)
  probe:sys_epoll_wait_1 (on sys_epoll_wait)
  probe:sys_epoll_wait_2 (on sys_epoll_wait)

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

perf record -e probe:sys_epoll_wait_2 -aR sleep 1


I'll try different kernel version and kconfig.



Still unable reproduce. I tried tip/core/core, which is '4.7.0+'.
I also turns off CONFIG_DEBUG_INFO. In this case, testcase
BPF prologue fails as expected, and basic BPF test is okay.

After removing vmlinux, with kallsyms information
'perf probe sys_epoll_wait' sets only 1 kprobe, but it still
works.

I think there is a bug in your vmlinux. Could you please
do a bisect to find which commit causes this problem?

Thank you.

Re: perf test BPF failing on f24: fix

[Wangnan (F)]

On 2016/8/3 10:41, Wangnan (F) wrote:



On 2016/8/3 3:51, Arnaldo Carvalho de Melo wrote:

Hi Wang,

Something changed and a function used in a perf test for BPF is
not anymore appearing on vmlinux, albeit still available on
/proc/kallsyms:

# readelf -wi /lib/modules/4.7.0+/build/vmlinux | grep -w sys_epoll_wait
#

But:

[root@jouet ~]# grep -i sys_epoll_wait /proc/kallsyms
bd295b50 T SyS_epoll_wait
bd295b50 T sys_epoll_wait
[root@jouet ~]#

I noticed that it is some sort of aliasing so I checked the other
variant:

[root@jouet ~]# readelf -wi /lib/modules/4.7.0+/build/vmlinux | grep 
-w SyS_epoll_wait
 <2bc9b85>   DW_AT_name: (indirect string, offset: 
0xe7524): SyS_epoll_wait

[root@jouet ~]#


I also see no sys_epoll_wait in output of 'readelf -wi', but I can't
reproduce the whole problem.


Trying to use perf probe also produces the same resuls I notice when
running the perf test that is failing:

[root@jouet ~]# perf probe sys_epoll_wait
Failed to find debug information for address bd295b50
Probe point 'sys_epoll_wait' not found.
   Error: Failed to add events.


For me:

# uname -r
4.7.0

# perf probe -v sys_epoll_wait
probe-definition(0): sys_epoll_wait
symbol:sys_epoll_wait file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Looking at the vmlinux_path (8 entries long)
Using /lib/modules/4.7.0/build/vmlinux for symbols
Open Debuginfo file: /lib/modules/4.7.0/build/vmlinux
Try to find probe point from debuginfo.
Symbol sys_epoll_wait address found : 81281240
Matched function: SyS_epoll_wait
found inline addr: 0x81281240
Probe point found: SyS_epoll_wait+0
found inline addr: 0x812813a7
Probe point found: SyS_epoll_pwait+135
found inline addr: 0x8128157a
Probe point found: compat_SyS_epoll_pwait+154
Found 3 probe_trace_events.
Opening /sys/kernel/debug/tracing//kprobe_events write=1
Writing event: p:probe/sys_epoll_wait _text+2626112
Writing event: p:probe/sys_epoll_wait_1 _text+2626471
Writing event: p:probe/sys_epoll_wait_2 _text+2626938
Added new events:
  probe:sys_epoll_wait (on sys_epoll_wait)
  probe:sys_epoll_wait_1 (on sys_epoll_wait)
  probe:sys_epoll_wait_2 (on sys_epoll_wait)

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

perf record -e probe:sys_epoll_wait_2 -aR sleep 1


I'll try different kernel version and kconfig.



Still unable reproduce. I tried tip/core/core, which is '4.7.0+'.
I also turns off CONFIG_DEBUG_INFO. In this case, testcase
BPF prologue fails as expected, and basic BPF test is okay.

After removing vmlinux, with kallsyms information
'perf probe sys_epoll_wait' sets only 1 kprobe, but it still
works.

I think there is a bug in your vmlinux. Could you please
do a bisect to find which commit causes this problem?

Thank you.

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

[Steven Rostedt]

On Tue, 2 Aug 2016 22:31:25 -0500
Josh Poimboeuf  wrote:


> Yeah, we do need to add a parameter to ftrace_push_return_trace().  But
> callers which don't implement it could just pass zero like they do with
> 'fp'.
> 

Right, if zero is passed in, then just ignore it.

Bed time!

-- Steve

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

[Steven Rostedt]

On Tue, 2 Aug 2016 22:31:25 -0500
Josh Poimboeuf  wrote:


> Yeah, we do need to add a parameter to ftrace_push_return_trace().  But
> callers which don't implement it could just pass zero like they do with
> 'fp'.
> 

Right, if zero is passed in, then just ignore it.

Bed time!

-- Steve

RE: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl

[Yangbo Lu]

Hi Uffe,


> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Wednesday, August 03, 2016 5:41 AM
> To: Yangbo Lu; Michael Ellerman; Arnd Bergmann; Ulf Hansson
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; linux-kernel@vger.kernel.org; Xiaobo Xie
> Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to
> include/linux/fsl
> 
> On Tue, 2016-08-02 at 05:57 +, Yangbo Lu wrote:
> > Hi Scott,
> >
> > >
> > > -Original Message-
> > > From: Scott Wood [mailto:o...@buserror.net]
> > > Sent: Wednesday, July 27, 2016 8:38 AM
> > > To: Yangbo Lu; Michael Ellerman; Arnd Bergmann; Ulf Hansson
> > > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linuxppc-
> > > d...@lists.ozlabs.org; linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to
> > > include/linux/fsl
> > >
> > > On Mon, 2016-07-25 at 06:12 +, Yangbo Lu wrote:
> > > >
> > > > Hi Scott,
> > > >
> > > >
> > > > >
> > > > >
> > > > > -Original Message-
> > > > > From: Scott Wood [mailto:o...@buserror.net]
> > > > > Sent: Friday, July 22, 2016 12:45 AM
> > > > > To: Michael Ellerman; Arnd Bergmann
> > > > > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> > > > > linuxppc- d...@lists.ozlabs.org; linux-kernel@vger.kernel.org;
> > > > > Yangbo Lu
> > > > > Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to
> > > > > include/linux/fsl
> > > > >
> > > > > On Thu, 2016-07-21 at 20:26 +1000, Michael Ellerman wrote:
> > > > > >
> > > > > >
> > > > > > Quoting Scott Wood (2016-07-21 04:31:48)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, 2016-07-20 at 13:24 +0200, Arnd Bergmann wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Saturday, July 16, 2016 9:50:21 PM CEST Scott Wood wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > From: yangbo lu 
> > > > > > > > >
> > > > > > > > > Move mpc85xx.h to include/linux/fsl and rename it to
> > > > > > > > > svr.h as a common header file.  This SVR numberspace is
> > > > > > > > > used on some ARM chips as well as PPC, and even to check
> > > > > > > > > for a PPC SVR multi-arch drivers would otherwise need to
> > > > > > > > > ifdef the header inclusion and all references to the SVR
> symbols.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Yangbo Lu 
> > > > > > > > > Acked-by: Wolfram Sang 
> > > > > > > > > Acked-by: Stephen Boyd 
> > > > > > > > > Acked-by: Joerg Roedel 
> > > > > > > > > [scottwood: update description]
> > > > > > > > > Signed-off-by: Scott Wood 
> > > > > > > > >
> > > > > > > > As discussed before, please don't introduce yet another
> > > > > > > > vendor specific way to match a SoC ID from a device driver.
> > > > > > > >
> > > > > > > > I've posted a patch for an extension to the soc_device
> > > > > > > > infrastructure to allow comparing the running SoC to a
> > > > > > > > table of devices, use that instead.
> > > > > > > As I asked before, in which relevant maintainership capacity
> > > > > > > are you NACKing this?
> > > > > > I'll nack the powerpc part until you guys can agree.
> > > > > OK, I've pulled these patches out.
> > > > >
> > > > > For the MMC issue I suggest using ifdef CONFIG_PPC and
> > > > > mfspr(SPRN_SVR) like the clock driver does[1] and we can revisit
> > > > > the issue if/when we need to do something similar on an ARM chip.
> > > > [Lu Yangbo-B47093] I remembered that Uffe had opposed us to
> > > > introduce
> > > > non- generic header files(like '#include ') in mmc
> > > > driver initially. So I think it will not be accepted to use ifdef
> > > > CONFIG_PPC and mfspr(SPRN_SVR)...
> > > > And this method still couldn’t get SVR of ARM chip now.
> > > Right, as I said we'll have to revisit the issue if/when we have the
> > > same problem on an ARM chip.  That also applies if the PPC ifdef is
> > > still getting NACKed from the MMC side.
> > [Lu Yangbo-B47093] It's not clear for me about your idea :( Do you
> > mean we can still use this method, or not ?
> > I think Uffe had opposed to use ifdef CONFIG_PPC and mfspr(SPRN_SVR).
> > Is there any solution to resolve ?
> > :)
> 
> As I said, I'm OK with using the SPR.  It's up to you to find out whether
> it's still unacceptable with the MMC maintainers given all the discussion
> (it would be the quickest way to get the workaround enabled), or just go
> with the method below.

[Lu Yangbo-B47093] As you know, this patchset(as below) has been discussed for 
more than one year.
What I want is just to add a fix for an specific soc revision.

Yangbo Lu (7):
  Documentation: DT: update Freescale DCFG compatible
  ARM64: dts: ls2080a: add device configuration node
  soc: fsl: add GUTS driver for QorIQ platforms
  dt: move guts devicetree doc out of powerpc 

RE: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl

[Yangbo Lu]

Hi Uffe,


> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Wednesday, August 03, 2016 5:41 AM
> To: Yangbo Lu; Michael Ellerman; Arnd Bergmann; Ulf Hansson
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; linux-kernel@vger.kernel.org; Xiaobo Xie
> Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to
> include/linux/fsl
> 
> On Tue, 2016-08-02 at 05:57 +, Yangbo Lu wrote:
> > Hi Scott,
> >
> > >
> > > -Original Message-
> > > From: Scott Wood [mailto:o...@buserror.net]
> > > Sent: Wednesday, July 27, 2016 8:38 AM
> > > To: Yangbo Lu; Michael Ellerman; Arnd Bergmann; Ulf Hansson
> > > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linuxppc-
> > > d...@lists.ozlabs.org; linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to
> > > include/linux/fsl
> > >
> > > On Mon, 2016-07-25 at 06:12 +, Yangbo Lu wrote:
> > > >
> > > > Hi Scott,
> > > >
> > > >
> > > > >
> > > > >
> > > > > -Original Message-
> > > > > From: Scott Wood [mailto:o...@buserror.net]
> > > > > Sent: Friday, July 22, 2016 12:45 AM
> > > > > To: Michael Ellerman; Arnd Bergmann
> > > > > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> > > > > linuxppc- d...@lists.ozlabs.org; linux-kernel@vger.kernel.org;
> > > > > Yangbo Lu
> > > > > Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to
> > > > > include/linux/fsl
> > > > >
> > > > > On Thu, 2016-07-21 at 20:26 +1000, Michael Ellerman wrote:
> > > > > >
> > > > > >
> > > > > > Quoting Scott Wood (2016-07-21 04:31:48)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, 2016-07-20 at 13:24 +0200, Arnd Bergmann wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Saturday, July 16, 2016 9:50:21 PM CEST Scott Wood wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > From: yangbo lu 
> > > > > > > > >
> > > > > > > > > Move mpc85xx.h to include/linux/fsl and rename it to
> > > > > > > > > svr.h as a common header file.  This SVR numberspace is
> > > > > > > > > used on some ARM chips as well as PPC, and even to check
> > > > > > > > > for a PPC SVR multi-arch drivers would otherwise need to
> > > > > > > > > ifdef the header inclusion and all references to the SVR
> symbols.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Yangbo Lu 
> > > > > > > > > Acked-by: Wolfram Sang 
> > > > > > > > > Acked-by: Stephen Boyd 
> > > > > > > > > Acked-by: Joerg Roedel 
> > > > > > > > > [scottwood: update description]
> > > > > > > > > Signed-off-by: Scott Wood 
> > > > > > > > >
> > > > > > > > As discussed before, please don't introduce yet another
> > > > > > > > vendor specific way to match a SoC ID from a device driver.
> > > > > > > >
> > > > > > > > I've posted a patch for an extension to the soc_device
> > > > > > > > infrastructure to allow comparing the running SoC to a
> > > > > > > > table of devices, use that instead.
> > > > > > > As I asked before, in which relevant maintainership capacity
> > > > > > > are you NACKing this?
> > > > > > I'll nack the powerpc part until you guys can agree.
> > > > > OK, I've pulled these patches out.
> > > > >
> > > > > For the MMC issue I suggest using ifdef CONFIG_PPC and
> > > > > mfspr(SPRN_SVR) like the clock driver does[1] and we can revisit
> > > > > the issue if/when we need to do something similar on an ARM chip.
> > > > [Lu Yangbo-B47093] I remembered that Uffe had opposed us to
> > > > introduce
> > > > non- generic header files(like '#include ') in mmc
> > > > driver initially. So I think it will not be accepted to use ifdef
> > > > CONFIG_PPC and mfspr(SPRN_SVR)...
> > > > And this method still couldn’t get SVR of ARM chip now.
> > > Right, as I said we'll have to revisit the issue if/when we have the
> > > same problem on an ARM chip.  That also applies if the PPC ifdef is
> > > still getting NACKed from the MMC side.
> > [Lu Yangbo-B47093] It's not clear for me about your idea :( Do you
> > mean we can still use this method, or not ?
> > I think Uffe had opposed to use ifdef CONFIG_PPC and mfspr(SPRN_SVR).
> > Is there any solution to resolve ?
> > :)
> 
> As I said, I'm OK with using the SPR.  It's up to you to find out whether
> it's still unacceptable with the MMC maintainers given all the discussion
> (it would be the quickest way to get the workaround enabled), or just go
> with the method below.

[Lu Yangbo-B47093] As you know, this patchset(as below) has been discussed for 
more than one year.
What I want is just to add a fix for an specific soc revision.

Yangbo Lu (7):
  Documentation: DT: update Freescale DCFG compatible
  ARM64: dts: ls2080a: add device configuration node
  soc: fsl: add GUTS driver for QorIQ platforms
  dt: move guts devicetree doc out of powerpc directory
  powerpc/fsl: move mpc85xx.h to include/linux/fsl
  MAINTAINERS: add entry for Freescale SoC drivers
  mmc: 

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

[Steven Rostedt]

On Tue, 2 Aug 2016 22:12:33 -0500
Josh Poimboeuf  wrote:


> Sounds good.  I was thinking I could also add a similar define to
> indicate whether an arch passes the return address stack pointer to
> ftrace_push_return_trace().  HAVE_FUNCTION_GRAPH_RET_ADDR_PTR?
> 

If you are making this function global, might as well make all pass
that pointer when you do the conversion. I don't think we need a define
to differentiate it.

-- Steve

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

[Steven Rostedt]

On Tue, 2 Aug 2016 22:12:33 -0500
Josh Poimboeuf  wrote:


> Sounds good.  I was thinking I could also add a similar define to
> indicate whether an arch passes the return address stack pointer to
> ftrace_push_return_trace().  HAVE_FUNCTION_GRAPH_RET_ADDR_PTR?
> 

If you are making this function global, might as well make all pass
that pointer when you do the conversion. I don't think we need a define
to differentiate it.

-- Steve

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

[Josh Poimboeuf]

On Tue, Aug 02, 2016 at 11:21:04PM -0400, Steven Rostedt wrote:
> On Tue, 2 Aug 2016 23:18:57 -0400
> Steven Rostedt  wrote:
> 
> > On Tue, 2 Aug 2016 22:12:33 -0500
> > Josh Poimboeuf  wrote:
> > 
> > 
> > > Sounds good.  I was thinking I could also add a similar define to
> > > indicate whether an arch passes the return address stack pointer to
> > > ftrace_push_return_trace().  HAVE_FUNCTION_GRAPH_RET_ADDR_PTR?
> > >   
> > 
> > If you are making this function global, might as well make all pass
> > that pointer when you do the conversion. I don't think we need a define
> > to differentiate it.
> > 
> 
> Bah, I was thinking of your ftrace_graph_ret_addr() function. /me needs
> to go to bed.
> 
> Anyway, if we have to add a parameter, we probably need to update all
> the callers anyway. We do need to add a parameter for this, right?

Yeah, we do need to add a parameter to ftrace_push_return_trace().  But
callers which don't implement it could just pass zero like they do with
'fp'.

-- 
Josh

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

[Josh Poimboeuf]

On Tue, Aug 02, 2016 at 11:21:04PM -0400, Steven Rostedt wrote:
> On Tue, 2 Aug 2016 23:18:57 -0400
> Steven Rostedt  wrote:
> 
> > On Tue, 2 Aug 2016 22:12:33 -0500
> > Josh Poimboeuf  wrote:
> > 
> > 
> > > Sounds good.  I was thinking I could also add a similar define to
> > > indicate whether an arch passes the return address stack pointer to
> > > ftrace_push_return_trace().  HAVE_FUNCTION_GRAPH_RET_ADDR_PTR?
> > >   
> > 
> > If you are making this function global, might as well make all pass
> > that pointer when you do the conversion. I don't think we need a define
> > to differentiate it.
> > 
> 
> Bah, I was thinking of your ftrace_graph_ret_addr() function. /me needs
> to go to bed.
> 
> Anyway, if we have to add a parameter, we probably need to update all
> the callers anyway. We do need to add a parameter for this, right?

Yeah, we do need to add a parameter to ftrace_push_return_trace().  But
callers which don't implement it could just pass zero like they do with
'fp'.

-- 
Josh

Re: [PATCH 2/2] soc: nxp: Add a RCPM driver

[Chenhui Zhao]

On Mon, Aug 1, 2016 at 9:22 PM, Marc Zyngier  wrote:
>
> On 01/08/16 10:49, Chenhui Zhao wrote:
> > The NXP's QorIQ Processors based on ARM Core have a RCPM module
> > (Run Control and Power Management), which performs all device-level
> > tasks associated with power management.
> >
> > This patch mainly implements the wakeup sources configuration before
> > entering LPM20, a low power state of device-level. The devices can be
> > waked up by specified sources, such as Flextimer, GPIO and so on.
> >
> > Signed-off-by: Chenhui Zhao 
> > ---
> >  drivers/soc/fsl/Makefile |   1 +
> >  drivers/soc/fsl/pm/Makefile  |   1 +
> >  drivers/soc/fsl/pm/ls-rcpm.c | 144 
> > +++
> >  3 files changed, 146 insertions(+)
> >  create mode 100644 drivers/soc/fsl/pm/Makefile
> >  create mode 100644 drivers/soc/fsl/pm/ls-rcpm.c
> >
> > diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> > index 203307f..b5adbaf 100644
> > --- a/drivers/soc/fsl/Makefile
> > +++ b/drivers/soc/fsl/Makefile
> > @@ -4,3 +4,4 @@
> >
> >  obj-$(CONFIG_QUICC_ENGINE)   += qe/
> >  obj-$(CONFIG_CPM)+= qe/
> > +obj-$(CONFIG_SUSPEND)+= pm/
> > diff --git a/drivers/soc/fsl/pm/Makefile b/drivers/soc/fsl/pm/Makefile
> > new file mode 100644
> > index 000..e275d63
> > --- /dev/null
> > +++ b/drivers/soc/fsl/pm/Makefile
> > @@ -0,0 +1 @@
> > +obj-$(CONFIG_ARCH_LAYERSCAPE) += ls-rcpm.o
> > diff --git a/drivers/soc/fsl/pm/ls-rcpm.c b/drivers/soc/fsl/pm/ls-rcpm.c
> > new file mode 100644
> > index 000..c5f2b97
> > --- /dev/null
> > +++ b/drivers/soc/fsl/pm/ls-rcpm.c
> > @@ -0,0 +1,144 @@
> > +/*
> > + * Run Control and Power Management (RCPM) driver
> > + *
> > + * Copyright 2016 Freescale Semiconductor, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + */
> > +#define pr_fmt(fmt) "RCPM: %s: " fmt, __func__
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* So far there are not more than two registers */
> > +#define RCPM_IPPDEXPCR0  0x140
> > +#define RCPM_IPPDEXPCR1  0x144
> > +#define RCPM_IPPDEXPCR(x)(RCPM_IPPDEXPCR0 + 4 * x)
> > +#define RCPM_WAKEUP_CELL_MAX_SIZE2
> > +
> > +/* it reprents the number of the registers RCPM_IPPDEXPCR */
> > +static unsigned int rcpm_wakeup_cells;
> > +static void __iomem *rcpm_reg_base;
> > +static u32 ippdexpcr[RCPM_WAKEUP_CELL_MAX_SIZE];
> > +
> > +static inline void rcpm_reg_write(u32 offset, u32 value)
> > +{
> > + iowrite32be(value, rcpm_reg_base + offset);
> > +}
> > +
> > +static inline u32 rcpm_reg_read(u32 offset)
> > +{
> > + return ioread32be(rcpm_reg_base + offset);
> > +}
> > +
> > +static void rcpm_wakeup_fixup(struct device *dev, void *data)
> > +{
> > + struct device_node *node = dev ? dev->of_node : NULL;
> > + u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1];
> > + int ret;
> > + int i;
> > +
> > + if (!dev || !node || !device_may_wakeup(dev))
> > + return;
> > +
> > + /*
> > +  * Get the values in the "rcpm-wakeup" property.
> > +  * Refer to Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > +  */
> > + ret = of_property_read_u32_array(node, "rcpm-wakeup",
> > +  value, rcpm_wakeup_cells + 1);
> > + if (ret)
> > + return;
> > +
> > + pr_debug("wakeup source: the device %s\n", node->full_name);
>
> This looks absolutely dreadful. You are parsing every node for each
> device, and apply a set-in-stone configuration.
>
> The normal way to handle this is by making this device an interrupt
> controller, and honour the irq_set_wake API. This has already been done
> on other FSL/NXP hardware (see the iMX GPC stuff).
>
> Thanks,
>
> M.

The RCPM IP block is really not an interrupt controller, instead it is
related to power management. The code in this patch is to set the bits
in the IPPDEXPCR register. Setting these bits can make the
corresponding IP block alive during the period of sleep, so that the
IP blocks working as wakeup sources can wake the device. The
"rcpm-wakeup" property records the bit mask which should be set when
the IP block is working as wakeup source. The bit definition may be
different for each QorIQ SoC. The operation is specific to QorIQ
platform, so put the code in drivers/soc/fsl/pm/.

Thanks,
Chenhui

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

[Josh Poimboeuf]

On Tue, Aug 02, 2016 at 11:18:57PM -0400, Steven Rostedt wrote:
> On Tue, 2 Aug 2016 22:12:33 -0500
> Josh Poimboeuf  wrote:
> 
> 
> > Sounds good.  I was thinking I could also add a similar define to
> > indicate whether an arch passes the return address stack pointer to
> > ftrace_push_return_trace().  HAVE_FUNCTION_GRAPH_RET_ADDR_PTR?
> > 
> 
> If you are making this function global, might as well make all pass
> that pointer when you do the conversion. I don't think we need a define
> to differentiate it.

In theory, I like the idea.  But from what I can tell, it looks like a
few arches would require some assembly changes: s390, powerpc, and
sparc.  I can probably handle s390 and power, but sparc is a whole
different story...

-- 
Josh

Re: [PATCH 2/2] soc: nxp: Add a RCPM driver

[Chenhui Zhao]

On Mon, Aug 1, 2016 at 9:22 PM, Marc Zyngier  wrote:
>
> On 01/08/16 10:49, Chenhui Zhao wrote:
> > The NXP's QorIQ Processors based on ARM Core have a RCPM module
> > (Run Control and Power Management), which performs all device-level
> > tasks associated with power management.
> >
> > This patch mainly implements the wakeup sources configuration before
> > entering LPM20, a low power state of device-level. The devices can be
> > waked up by specified sources, such as Flextimer, GPIO and so on.
> >
> > Signed-off-by: Chenhui Zhao 
> > ---
> >  drivers/soc/fsl/Makefile |   1 +
> >  drivers/soc/fsl/pm/Makefile  |   1 +
> >  drivers/soc/fsl/pm/ls-rcpm.c | 144 
> > +++
> >  3 files changed, 146 insertions(+)
> >  create mode 100644 drivers/soc/fsl/pm/Makefile
> >  create mode 100644 drivers/soc/fsl/pm/ls-rcpm.c
> >
> > diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> > index 203307f..b5adbaf 100644
> > --- a/drivers/soc/fsl/Makefile
> > +++ b/drivers/soc/fsl/Makefile
> > @@ -4,3 +4,4 @@
> >
> >  obj-$(CONFIG_QUICC_ENGINE)   += qe/
> >  obj-$(CONFIG_CPM)+= qe/
> > +obj-$(CONFIG_SUSPEND)+= pm/
> > diff --git a/drivers/soc/fsl/pm/Makefile b/drivers/soc/fsl/pm/Makefile
> > new file mode 100644
> > index 000..e275d63
> > --- /dev/null
> > +++ b/drivers/soc/fsl/pm/Makefile
> > @@ -0,0 +1 @@
> > +obj-$(CONFIG_ARCH_LAYERSCAPE) += ls-rcpm.o
> > diff --git a/drivers/soc/fsl/pm/ls-rcpm.c b/drivers/soc/fsl/pm/ls-rcpm.c
> > new file mode 100644
> > index 000..c5f2b97
> > --- /dev/null
> > +++ b/drivers/soc/fsl/pm/ls-rcpm.c
> > @@ -0,0 +1,144 @@
> > +/*
> > + * Run Control and Power Management (RCPM) driver
> > + *
> > + * Copyright 2016 Freescale Semiconductor, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + */
> > +#define pr_fmt(fmt) "RCPM: %s: " fmt, __func__
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* So far there are not more than two registers */
> > +#define RCPM_IPPDEXPCR0  0x140
> > +#define RCPM_IPPDEXPCR1  0x144
> > +#define RCPM_IPPDEXPCR(x)(RCPM_IPPDEXPCR0 + 4 * x)
> > +#define RCPM_WAKEUP_CELL_MAX_SIZE2
> > +
> > +/* it reprents the number of the registers RCPM_IPPDEXPCR */
> > +static unsigned int rcpm_wakeup_cells;
> > +static void __iomem *rcpm_reg_base;
> > +static u32 ippdexpcr[RCPM_WAKEUP_CELL_MAX_SIZE];
> > +
> > +static inline void rcpm_reg_write(u32 offset, u32 value)
> > +{
> > + iowrite32be(value, rcpm_reg_base + offset);
> > +}
> > +
> > +static inline u32 rcpm_reg_read(u32 offset)
> > +{
> > + return ioread32be(rcpm_reg_base + offset);
> > +}
> > +
> > +static void rcpm_wakeup_fixup(struct device *dev, void *data)
> > +{
> > + struct device_node *node = dev ? dev->of_node : NULL;
> > + u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1];
> > + int ret;
> > + int i;
> > +
> > + if (!dev || !node || !device_may_wakeup(dev))
> > + return;
> > +
> > + /*
> > +  * Get the values in the "rcpm-wakeup" property.
> > +  * Refer to Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > +  */
> > + ret = of_property_read_u32_array(node, "rcpm-wakeup",
> > +  value, rcpm_wakeup_cells + 1);
> > + if (ret)
> > + return;
> > +
> > + pr_debug("wakeup source: the device %s\n", node->full_name);
>
> This looks absolutely dreadful. You are parsing every node for each
> device, and apply a set-in-stone configuration.
>
> The normal way to handle this is by making this device an interrupt
> controller, and honour the irq_set_wake API. This has already been done
> on other FSL/NXP hardware (see the iMX GPC stuff).
>
> Thanks,
>
> M.

The RCPM IP block is really not an interrupt controller, instead it is
related to power management. The code in this patch is to set the bits
in the IPPDEXPCR register. Setting these bits can make the
corresponding IP block alive during the period of sleep, so that the
IP blocks working as wakeup sources can wake the device. The
"rcpm-wakeup" property records the bit mask which should be set when
the IP block is working as wakeup source. The bit definition may be
different for each QorIQ SoC. The operation is specific to QorIQ
platform, so put the code in drivers/soc/fsl/pm/.

Thanks,
Chenhui

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

[Josh Poimboeuf]

On Tue, Aug 02, 2016 at 11:18:57PM -0400, Steven Rostedt wrote:
> On Tue, 2 Aug 2016 22:12:33 -0500
> Josh Poimboeuf  wrote:
> 
> 
> > Sounds good.  I was thinking I could also add a similar define to
> > indicate whether an arch passes the return address stack pointer to
> > ftrace_push_return_trace().  HAVE_FUNCTION_GRAPH_RET_ADDR_PTR?
> > 
> 
> If you are making this function global, might as well make all pass
> that pointer when you do the conversion. I don't think we need a define
> to differentiate it.

In theory, I like the idea.  But from what I can tell, it looks like a
few arches would require some assembly changes: s390, powerpc, and
sparc.  I can probably handle s390 and power, but sparc is a whole
different story...

-- 
Josh

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

[Michael Ellerman]

"Luis R. Rodriguez"  writes:

> Are linux-next builds being tested for powerpc with allyesconfig and
> allmodconfig ?

Yes, every single version:

  http://kisskb.ellerman.id.au/kisskb/target/2659/

> I have some changes I'm making and while debugging my
> build issues I decided to give a clean build a shot and see linux-next
> next-20160729 up to next-20160729 all have build failures without my
> changes. I get:
>
> /opt/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
> drivers/built-in.o: .opd is not a regular array of opd entries
>   MODPOST vmlinux.o
>   GEN .version
>   CHK include/generated/compile.h
>   UPD include/generated/compile.h
>   CC  init/version.o
>   LD  init/built-in.o
> /opt/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
> drivers/built-in.o: .opd is not a regular array of opd entries
> drivers/built-in.o: In function `.ipw2100_up':
> ipw2100.c:(.text+0x1ff9c90): relocation truncated to fit:
> R_PPC64_REL24 (stub) against symbol `.round_jiffies_relative' defined
> in .text section in kernel/built-in.o

And yes this is a known problem, there have been attempts to fix it, but
none that quite got working.

In fact it's our bug #1 :)

  https://github.com/linuxppc/linux/issues/1


Please use allmodconfig, which should build in general. Or one of our
other defconfigs, eg. ppc64/ppc64le defconfig.

cheers

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

[Michael Ellerman]

"Luis R. Rodriguez"  writes:

> Are linux-next builds being tested for powerpc with allyesconfig and
> allmodconfig ?

Yes, every single version:

  http://kisskb.ellerman.id.au/kisskb/target/2659/

> I have some changes I'm making and while debugging my
> build issues I decided to give a clean build a shot and see linux-next
> next-20160729 up to next-20160729 all have build failures without my
> changes. I get:
>
> /opt/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
> drivers/built-in.o: .opd is not a regular array of opd entries
>   MODPOST vmlinux.o
>   GEN .version
>   CHK include/generated/compile.h
>   UPD include/generated/compile.h
>   CC  init/version.o
>   LD  init/built-in.o
> /opt/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
> drivers/built-in.o: .opd is not a regular array of opd entries
> drivers/built-in.o: In function `.ipw2100_up':
> ipw2100.c:(.text+0x1ff9c90): relocation truncated to fit:
> R_PPC64_REL24 (stub) against symbol `.round_jiffies_relative' defined
> in .text section in kernel/built-in.o

And yes this is a known problem, there have been attempts to fix it, but
none that quite got working.

In fact it's our bug #1 :)

  https://github.com/linuxppc/linux/issues/1


Please use allmodconfig, which should build in general. Or one of our
other defconfigs, eg. ppc64/ppc64le defconfig.

cheers

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

[Steven Rostedt]

On Tue, 2 Aug 2016 23:18:57 -0400
Steven Rostedt  wrote:

> On Tue, 2 Aug 2016 22:12:33 -0500
> Josh Poimboeuf  wrote:
> 
> 
> > Sounds good.  I was thinking I could also add a similar define to
> > indicate whether an arch passes the return address stack pointer to
> > ftrace_push_return_trace().  HAVE_FUNCTION_GRAPH_RET_ADDR_PTR?
> >   
> 
> If you are making this function global, might as well make all pass
> that pointer when you do the conversion. I don't think we need a define
> to differentiate it.
> 

Bah, I was thinking of your ftrace_graph_ret_addr() function. /me needs
to go to bed.

Anyway, if we have to add a parameter, we probably need to update all
the callers anyway. We do need to add a parameter for this, right?

-- Steve

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

[Steven Rostedt]

On Tue, 2 Aug 2016 23:18:57 -0400
Steven Rostedt  wrote:

> On Tue, 2 Aug 2016 22:12:33 -0500
> Josh Poimboeuf  wrote:
> 
> 
> > Sounds good.  I was thinking I could also add a similar define to
> > indicate whether an arch passes the return address stack pointer to
> > ftrace_push_return_trace().  HAVE_FUNCTION_GRAPH_RET_ADDR_PTR?
> >   
> 
> If you are making this function global, might as well make all pass
> that pointer when you do the conversion. I don't think we need a define
> to differentiate it.
> 

Bah, I was thinking of your ftrace_graph_ret_addr() function. /me needs
to go to bed.

Anyway, if we have to add a parameter, we probably need to update all
the callers anyway. We do need to add a parameter for this, right?

-- Steve

[git pull] drm zpos property support

[Dave Airlie]

Hi Linus,

This tree was waiting on some media stuff I hadn't had time to get a 
stable branchpoint off, so I just waited until it was all in your tree
first, it's been around a bit on the list and shouldn't affect anything
outside adding the generic API and moving some ARM drivers to using it.

Dave.

The following changes since commit dfd2e9ab6a7db56a5f5bb55f71485a92613c8e11:

  drm/i915: Check PSR setup time vs. vblank length (2016-08-03 07:06:41 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-for-v4.8-zpos

for you to fetch changes up to 586efded6b8beb932e9a356f351b0c681503358f:

  Merge branch 'generic-zpos-v8' of 
http://git.linaro.org/people/benjamin.gaignard/kernel into drm-next (2016-08-03 
08:40:24 +1000)


Benjamin Gaignard (3):
  Merge remote-tracking branch 'media_tree/vsp1' into generic-zpos-v8
  drm: sti: use generic zpos for plane
  drm: rcar: use generic code for managing zpos plane property

Dave Airlie (1):
  Merge branch 'generic-zpos-v8' of 
http://git.linaro.org/people/benjamin.gaignard/kernel into drm-next

Marek Szyprowski (2):
  drm: add generic zpos property
  drm/exynos: use generic code for managing zpos plane property

 Documentation/gpu/kms-properties.csv  |   1 +
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_atomic.c  |   4 +
 drivers/gpu/drm/drm_atomic_helper.c   |   7 +
 drivers/gpu/drm/drm_blend.c   | 238 ++
 drivers/gpu/drm/drm_crtc_internal.h   |   4 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   2 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  67 ++---
 drivers/gpu/drm/exynos/exynos_mixer.c |   6 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c|   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |   1 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_plane.c   |   9 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.h   |   2 -
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c |  14 +-
 drivers/gpu/drm/sti/sti_cursor.c  |   4 +-
 drivers/gpu/drm/sti/sti_gdp.c |   4 +-
 drivers/gpu/drm/sti/sti_hqvdp.c   |   4 +-
 drivers/gpu/drm/sti/sti_mixer.c   |   9 +-
 drivers/gpu/drm/sti/sti_plane.c   |  78 --
 drivers/gpu/drm/sti/sti_plane.h   |   7 +-
 include/drm/drm_crtc.h|  20 +++
 22 files changed, 334 insertions(+), 156 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_blend.c

[git pull] drm zpos property support

[Dave Airlie]

Hi Linus,

This tree was waiting on some media stuff I hadn't had time to get a 
stable branchpoint off, so I just waited until it was all in your tree
first, it's been around a bit on the list and shouldn't affect anything
outside adding the generic API and moving some ARM drivers to using it.

Dave.

The following changes since commit dfd2e9ab6a7db56a5f5bb55f71485a92613c8e11:

  drm/i915: Check PSR setup time vs. vblank length (2016-08-03 07:06:41 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-for-v4.8-zpos

for you to fetch changes up to 586efded6b8beb932e9a356f351b0c681503358f:

  Merge branch 'generic-zpos-v8' of 
http://git.linaro.org/people/benjamin.gaignard/kernel into drm-next (2016-08-03 
08:40:24 +1000)


Benjamin Gaignard (3):
  Merge remote-tracking branch 'media_tree/vsp1' into generic-zpos-v8
  drm: sti: use generic zpos for plane
  drm: rcar: use generic code for managing zpos plane property

Dave Airlie (1):
  Merge branch 'generic-zpos-v8' of 
http://git.linaro.org/people/benjamin.gaignard/kernel into drm-next

Marek Szyprowski (2):
  drm: add generic zpos property
  drm/exynos: use generic code for managing zpos plane property

 Documentation/gpu/kms-properties.csv  |   1 +
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_atomic.c  |   4 +
 drivers/gpu/drm/drm_atomic_helper.c   |   7 +
 drivers/gpu/drm/drm_blend.c   | 238 ++
 drivers/gpu/drm/drm_crtc_internal.h   |   4 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   2 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  67 ++---
 drivers/gpu/drm/exynos/exynos_mixer.c |   6 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c|   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |   1 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_plane.c   |   9 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.h   |   2 -
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c |  14 +-
 drivers/gpu/drm/sti/sti_cursor.c  |   4 +-
 drivers/gpu/drm/sti/sti_gdp.c |   4 +-
 drivers/gpu/drm/sti/sti_hqvdp.c   |   4 +-
 drivers/gpu/drm/sti/sti_mixer.c   |   9 +-
 drivers/gpu/drm/sti/sti_plane.c   |  78 --
 drivers/gpu/drm/sti/sti_plane.h   |   7 +-
 include/drm/drm_crtc.h|  20 +++
 22 files changed, 334 insertions(+), 156 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_blend.c

Re: [v9.1 PATCH 3/6] phy: Add USB Type-C PHY driver for rk3399

[Guenter Roeck]

On Tue, Aug 2, 2016 at 7:03 PM, Chris Zhong  wrote:
> Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
> Type-C PHY is designed to support the USB3 and DP applications. The
> PHY basically has two main components: USB3 and DisplyPort. USB3
> operates in SuperSpeed mode and the DP can operate at RBR, HBR and
> HBR2 data rates. Hence, create 2 PHY deivces, the phy[0] for DP,
> and phy[1] for USB3.
>
> Signed-off-by: Chris Zhong 
> Signed-off-by: Kever Yang 
>
> ---
>
> Changes in v9.1:
> - better mutex lock for phy mode and flip
>
> Changes in v9:
> - split the Type-C PHY into two PHYs: USB3 and DP
>
> Changes in v8:
> - set the default cable id to EXTCON_USB_HOST
> - optimization Error log
>
> Changes in v7:
> - support new API of extcon
>
> Changes in v6:
> - delete the support of PIN_ASSIGN_A/B
> - set the default mode to MODE_DFP_USB
> - disable DP PLL at USB3 only mode
>
> Changes in v5:
> - support get property from extcon
> - remove PIN ASSIGN A/B support
>
> Changes in v4:
> - select EXTCON
> - use phy framework to control the USB3 and DP function
> - rename PIN_MAP_ to PIN_ASSIGN_
>
> Changes in v3:
> - remove the phy framework(Kishon Vijay Abraham I)
> - add parentheses around the macro
> - use a single space between type and name
> - add spaces after opening and before closing braces.
> - use u16 for register value
> - remove type-c phy header file
> - CodingStyle optimization
> - use some cable extcon to get type-c port information
> - add a extcon to notify Display Port
>
> Changes in v2:
> - select RESET_CONTROLLER
> - alphabetic order
> - modify some spelling mistakes
> - make mode cleaner
> - use bool for enable/disable
> - check all of the return value
> - return a better err number
> - use more readx_poll_timeout()
> - clk_disable_unprepare(tcphy->clk_ref);
> - remove unuse functions, rockchip_typec_phy_power_on/off
> - remove unnecessary typecast from void *
> - use dts node to distinguish between phys.
>
> Changes in v1:
> - update the licence note
> - init core clock to 50MHz
> - use extcon API
> - remove unused global
> - add some comments for magic num
> - change usleep_range(1000, 2000) tousleep_range(1000, 1050)
> - remove __func__ from dev_err
> - return err number when get clk failed
> - remove ADDR_ADJ define
> - use devm_clk_get(>dev, "tcpdcore")
>
>  drivers/phy/Kconfig  |9 +
>  drivers/phy/Makefile |1 +
>  drivers/phy/phy-rockchip-typec.c | 1004 
> ++
>  3 files changed, 1014 insertions(+)
>  create mode 100644 drivers/phy/phy-rockchip-typec.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 26566db..83706a5 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -351,6 +351,15 @@ config PHY_ROCKCHIP_DP
> help
>   Enable this to support the Rockchip Display Port PHY.
>
> +config PHY_ROCKCHIP_TYPEC
> +   tristate "Rockchip TYPEC PHY Driver"
> +   depends on ARCH_ROCKCHIP && OF
> +   select EXTCON
> +   select GENERIC_PHY
> +   select RESET_CONTROLLER
> +   help
> + Enable this to support the Rockchip USB TYPEC PHY.
> +
>  config PHY_ST_SPEAR1310_MIPHY
> tristate "ST SPEAR1310-MIPHY driver"
> select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 24596a9..91fa413 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -39,6 +39,7 @@ obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)   += 
> phy-qcom-apq8064-sata.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
>  obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
>  obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
> +obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
>  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
>  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-typec.c 
> b/drivers/phy/phy-rockchip-typec.c
> new file mode 100644
> index 000..27a1663
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-typec.c
> @@ -0,0 +1,1004 @@
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Chris Zhong 
> + * Kever Yang 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> 

Re: [v9.1 PATCH 3/6] phy: Add USB Type-C PHY driver for rk3399

[Guenter Roeck]

On Tue, Aug 2, 2016 at 7:03 PM, Chris Zhong  wrote:
> Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
> Type-C PHY is designed to support the USB3 and DP applications. The
> PHY basically has two main components: USB3 and DisplyPort. USB3
> operates in SuperSpeed mode and the DP can operate at RBR, HBR and
> HBR2 data rates. Hence, create 2 PHY deivces, the phy[0] for DP,
> and phy[1] for USB3.
>
> Signed-off-by: Chris Zhong 
> Signed-off-by: Kever Yang 
>
> ---
>
> Changes in v9.1:
> - better mutex lock for phy mode and flip
>
> Changes in v9:
> - split the Type-C PHY into two PHYs: USB3 and DP
>
> Changes in v8:
> - set the default cable id to EXTCON_USB_HOST
> - optimization Error log
>
> Changes in v7:
> - support new API of extcon
>
> Changes in v6:
> - delete the support of PIN_ASSIGN_A/B
> - set the default mode to MODE_DFP_USB
> - disable DP PLL at USB3 only mode
>
> Changes in v5:
> - support get property from extcon
> - remove PIN ASSIGN A/B support
>
> Changes in v4:
> - select EXTCON
> - use phy framework to control the USB3 and DP function
> - rename PIN_MAP_ to PIN_ASSIGN_
>
> Changes in v3:
> - remove the phy framework(Kishon Vijay Abraham I)
> - add parentheses around the macro
> - use a single space between type and name
> - add spaces after opening and before closing braces.
> - use u16 for register value
> - remove type-c phy header file
> - CodingStyle optimization
> - use some cable extcon to get type-c port information
> - add a extcon to notify Display Port
>
> Changes in v2:
> - select RESET_CONTROLLER
> - alphabetic order
> - modify some spelling mistakes
> - make mode cleaner
> - use bool for enable/disable
> - check all of the return value
> - return a better err number
> - use more readx_poll_timeout()
> - clk_disable_unprepare(tcphy->clk_ref);
> - remove unuse functions, rockchip_typec_phy_power_on/off
> - remove unnecessary typecast from void *
> - use dts node to distinguish between phys.
>
> Changes in v1:
> - update the licence note
> - init core clock to 50MHz
> - use extcon API
> - remove unused global
> - add some comments for magic num
> - change usleep_range(1000, 2000) tousleep_range(1000, 1050)
> - remove __func__ from dev_err
> - return err number when get clk failed
> - remove ADDR_ADJ define
> - use devm_clk_get(>dev, "tcpdcore")
>
>  drivers/phy/Kconfig  |9 +
>  drivers/phy/Makefile |1 +
>  drivers/phy/phy-rockchip-typec.c | 1004 
> ++
>  3 files changed, 1014 insertions(+)
>  create mode 100644 drivers/phy/phy-rockchip-typec.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 26566db..83706a5 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -351,6 +351,15 @@ config PHY_ROCKCHIP_DP
> help
>   Enable this to support the Rockchip Display Port PHY.
>
> +config PHY_ROCKCHIP_TYPEC
> +   tristate "Rockchip TYPEC PHY Driver"
> +   depends on ARCH_ROCKCHIP && OF
> +   select EXTCON
> +   select GENERIC_PHY
> +   select RESET_CONTROLLER
> +   help
> + Enable this to support the Rockchip USB TYPEC PHY.
> +
>  config PHY_ST_SPEAR1310_MIPHY
> tristate "ST SPEAR1310-MIPHY driver"
> select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 24596a9..91fa413 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -39,6 +39,7 @@ obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)   += 
> phy-qcom-apq8064-sata.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
>  obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
>  obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
> +obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
>  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
>  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-typec.c 
> b/drivers/phy/phy-rockchip-typec.c
> new file mode 100644
> index 000..27a1663
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-typec.c
> @@ -0,0 +1,1004 @@
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Chris Zhong 
> + * Kever Yang 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> 

Re: [PATCH v4 1/2] Documentation: kdump: remind user of nr_cpus

[Baoquan He]

Hi Wenjian,

On 08/03/16 at 10:31am, Zhou Wenjian wrote:
> v3->v4: update the description of bring up SMP dump-capture kernel
> v2->v3: add description of nr_cpus.
> v1->v2: change nr_cpus to maxcpus
> 
> nr_cpus can help to save memory. So we should remind user of it.
> 
> Signed-off-by: Zhou Wenjian 

The change log can be put in cover-letter if you are posting a patchset,
or put it below the three dashes where it will be discarded
automatically when maintainer apply your patch to his/her branch.

Next time please CC akpm too, he helps to pick up these kexec related
patches.

Except for this, I am fine with this patchset. Ack it again.

Acked-by: Baoquan He 

Thanks
Baoquan

> ---
>  Documentation/kdump/kdump.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index 88ff63d..b474060 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -393,6 +393,8 @@ Notes on loading the dump-capture kernel:
>  * We generally don' have to bring up a SMP kernel just to capture the
>dump. Hence generally it is useful either to build a UP dump-capture
>kernel or specify maxcpus=1 option while loading dump-capture kernel.
> +  Note, though maxcpus always works, we should replace it by nr_cpus to
> +  save memory if supported by the current ARCH, such as x86.
>  
>  * For s390x there are two kdump modes: If a ELF header is specified with
>the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
> -- 
> 1.8.3.1
> 
> 
> 
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v4 1/2] Documentation: kdump: remind user of nr_cpus

[Baoquan He]

Hi Wenjian,

On 08/03/16 at 10:31am, Zhou Wenjian wrote:
> v3->v4: update the description of bring up SMP dump-capture kernel
> v2->v3: add description of nr_cpus.
> v1->v2: change nr_cpus to maxcpus
> 
> nr_cpus can help to save memory. So we should remind user of it.
> 
> Signed-off-by: Zhou Wenjian 

The change log can be put in cover-letter if you are posting a patchset,
or put it below the three dashes where it will be discarded
automatically when maintainer apply your patch to his/her branch.

Next time please CC akpm too, he helps to pick up these kexec related
patches.

Except for this, I am fine with this patchset. Ack it again.

Acked-by: Baoquan He 

Thanks
Baoquan

> ---
>  Documentation/kdump/kdump.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index 88ff63d..b474060 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -393,6 +393,8 @@ Notes on loading the dump-capture kernel:
>  * We generally don' have to bring up a SMP kernel just to capture the
>dump. Hence generally it is useful either to build a UP dump-capture
>kernel or specify maxcpus=1 option while loading dump-capture kernel.
> +  Note, though maxcpus always works, we should replace it by nr_cpus to
> +  save memory if supported by the current ARCH, such as x86.
>  
>  * For s390x there are two kdump modes: If a ELF header is specified with
>the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
> -- 
> 1.8.3.1
> 
> 
> 
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

[Josh Poimboeuf]

On Tue, Aug 02, 2016 at 10:59:36PM -0400, Steven Rostedt wrote:
> On Tue, 2 Aug 2016 21:50:12 -0500
> Josh Poimboeuf  wrote:
> 
> 
> > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> > index 1e814ae..fc508a7 100644
> > --- a/include/linux/ftrace.h
> > +++ b/include/linux/ftrace.h
> > @@ -795,7 +795,9 @@ struct ftrace_ret_stack {
> > unsigned long func;
> > unsigned long long calltime;
> > unsigned long long subtime;
> > +#if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && 
> > !defined(CC_USING_FENTRY)
> 
> We need to make a new defined in ftrace.h:
> 
> #if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && !defined(CC_USING_FENTRY)
> # define HAVE_FUNCTION_GRAPH_FP_TEST
> #endif
> 
> And use that instead of this && complexity.
> 
> Or better yet, get rid of the CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST define
> and only have HAVE_FUNCTION_GRAPH_FP_TEST defined in the asm/ftrace.h
> in each arch. Then, x86 could just do;
> 
> #ifndef CC_USING_FENTRY
> # define HAVE_FUNCTION_GRAPH_FP_TEST
> #endif

Sounds good.  I was thinking I could also add a similar define to
indicate whether an arch passes the return address stack pointer to
ftrace_push_return_trace().  HAVE_FUNCTION_GRAPH_RET_ADDR_PTR?

-- 
Josh

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

[Josh Poimboeuf]

On Tue, Aug 02, 2016 at 10:59:36PM -0400, Steven Rostedt wrote:
> On Tue, 2 Aug 2016 21:50:12 -0500
> Josh Poimboeuf  wrote:
> 
> 
> > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> > index 1e814ae..fc508a7 100644
> > --- a/include/linux/ftrace.h
> > +++ b/include/linux/ftrace.h
> > @@ -795,7 +795,9 @@ struct ftrace_ret_stack {
> > unsigned long func;
> > unsigned long long calltime;
> > unsigned long long subtime;
> > +#if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && 
> > !defined(CC_USING_FENTRY)
> 
> We need to make a new defined in ftrace.h:
> 
> #if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && !defined(CC_USING_FENTRY)
> # define HAVE_FUNCTION_GRAPH_FP_TEST
> #endif
> 
> And use that instead of this && complexity.
> 
> Or better yet, get rid of the CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST define
> and only have HAVE_FUNCTION_GRAPH_FP_TEST defined in the asm/ftrace.h
> in each arch. Then, x86 could just do;
> 
> #ifndef CC_USING_FENTRY
> # define HAVE_FUNCTION_GRAPH_FP_TEST
> #endif

Sounds good.  I was thinking I could also add a similar define to
indicate whether an arch passes the return address stack pointer to
ftrace_push_return_trace().  HAVE_FUNCTION_GRAPH_RET_ADDR_PTR?

-- 
Josh

Private Message

[J. O'Neill Solicitors]

I once again try to notify you as my earlier letter was returned undelivered. 
In the said letter, you were bequeathed by late Client. Kindly get in touch
J. O'Neill
Sole Principal

Private Message

[J. O'Neill Solicitors]

I once again try to notify you as my earlier letter was returned undelivered. 
In the said letter, you were bequeathed by late Client. Kindly get in touch
J. O'Neill
Sole Principal

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

[Steven Rostedt]

On Tue, 2 Aug 2016 21:50:12 -0500
Josh Poimboeuf  wrote:


> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index 1e814ae..fc508a7 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -795,7 +795,9 @@ struct ftrace_ret_stack {
>   unsigned long func;
>   unsigned long long calltime;
>   unsigned long long subtime;
> +#if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && !defined(CC_USING_FENTRY)

We need to make a new defined in ftrace.h:

#if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && !defined(CC_USING_FENTRY)
# define HAVE_FUNCTION_GRAPH_FP_TEST
#endif

And use that instead of this && complexity.

Or better yet, get rid of the CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST define
and only have HAVE_FUNCTION_GRAPH_FP_TEST defined in the asm/ftrace.h
in each arch. Then, x86 could just do;

#ifndef CC_USING_FENTRY
# define HAVE_FUNCTION_GRAPH_FP_TEST
#endif


-- Steve

>   unsigned long fp;
> +#endif
>  };
>  
>  /*
> diff --git a/kernel/trace/trace_functions_graph.c 
> b/kernel/trace/trace_functions_graph.c
> index 9caa9b2..86b2719 100644
> --- a/kernel/trace/trace_functions_graph.c
> +++ b/kernel/trace/trace_functions_graph.c
> @@ -171,7 +171,9 @@ ftrace_push_return_trace(unsigned long ret, unsigned long 
> func, int *depth,
>   current->ret_stack[index].func = func;
>   current->ret_stack[index].calltime = calltime;
>   current->ret_stack[index].subtime = 0;
> +#if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && !defined(CC_USING_FENTRY)
>   current->ret_stack[index].fp = frame_pointer;
> +#endif
>   *depth = current->curr_ret_stack;
>  
>   return 0;

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

[Steven Rostedt]

On Tue, 2 Aug 2016 21:50:12 -0500
Josh Poimboeuf  wrote:


> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index 1e814ae..fc508a7 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -795,7 +795,9 @@ struct ftrace_ret_stack {
>   unsigned long func;
>   unsigned long long calltime;
>   unsigned long long subtime;
> +#if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && !defined(CC_USING_FENTRY)

We need to make a new defined in ftrace.h:

#if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && !defined(CC_USING_FENTRY)
# define HAVE_FUNCTION_GRAPH_FP_TEST
#endif

And use that instead of this && complexity.

Or better yet, get rid of the CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST define
and only have HAVE_FUNCTION_GRAPH_FP_TEST defined in the asm/ftrace.h
in each arch. Then, x86 could just do;

#ifndef CC_USING_FENTRY
# define HAVE_FUNCTION_GRAPH_FP_TEST
#endif


-- Steve

>   unsigned long fp;
> +#endif
>  };
>  
>  /*
> diff --git a/kernel/trace/trace_functions_graph.c 
> b/kernel/trace/trace_functions_graph.c
> index 9caa9b2..86b2719 100644
> --- a/kernel/trace/trace_functions_graph.c
> +++ b/kernel/trace/trace_functions_graph.c
> @@ -171,7 +171,9 @@ ftrace_push_return_trace(unsigned long ret, unsigned long 
> func, int *depth,
>   current->ret_stack[index].func = func;
>   current->ret_stack[index].calltime = calltime;
>   current->ret_stack[index].subtime = 0;
> +#if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && !defined(CC_USING_FENTRY)
>   current->ret_stack[index].fp = frame_pointer;
> +#endif
>   *depth = current->curr_ret_stack;
>  
>   return 0;

Re: perf test BPF failing on f24: fix

[Alexei Starovoitov]

On Tue, Aug 02, 2016 at 11:15:34PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Aug 02, 2016 at 02:03:33PM -0700, Alexei Starovoitov escreveu:
> > On Tue, Aug 02, 2016 at 04:51:02PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Hi Wang,
> > > 
> > >   Something changed and a function used in a perf test for BPF is
> > > not anymore appearing on vmlinux, albeit still available on
> > > /proc/kallsyms:
> > > 
> > > # readelf -wi /lib/modules/4.7.0+/build/vmlinux | grep -w sys_epoll_wait
> > > #
> > > 
> > > But:
> > > 
> > > [root@jouet ~]# grep -i sys_epoll_wait /proc/kallsyms 
> > > bd295b50 T SyS_epoll_wait
> > > bd295b50 T sys_epoll_wait
> > > [root@jouet ~]#
> > > 
> > > I noticed that it is some sort of aliasing so I checked the other
> > > variant:
> > > 
> > > [root@jouet ~]# readelf -wi /lib/modules/4.7.0+/build/vmlinux | grep -w 
> > > SyS_epoll_wait
> > > <2bc9b85>   DW_AT_name: (indirect string, offset: 0xe7524): 
> > > SyS_epoll_wait
> > > [root@jouet ~]# 
> > > 
> > > Trying to use perf probe also produces the same resuls I notice when
> > > running the perf test that is failing:
> > > 
> > > [root@jouet ~]# perf probe sys_epoll_wait
> > > Failed to find debug information for address bd295b50
> > > Probe point 'sys_epoll_wait' not found.
> > >   Error: Failed to add events.
> > > [root@jouet ~]# perf probe SyS_epoll_wait
> > > Added new events:
> > >   probe:SyS_epoll_wait (on SyS_epoll_wait)
> > >   probe:SyS_epoll_wait_1 (on SyS_epoll_wait)
> > >   probe:SyS_epoll_wait_2 (on SyS_epoll_wait)
> > 
> > that change will break all sorts of scripts that relying on syscalls to 
> > start
> > with sys_
> 
> Is there a promise that internal kernel functions will not change names?
>
> > I guess we can workaround in user space, but what was the motivation to
> > disable kprobe attach on sys_* while it's still in kallsyms?
> 
> Was it disabled? What I noticed whas that the sys_epoll_wait wasn't
> present in the DWARF info present in the vmlinux file, which would be
> good for others to confirm, which I'll check on other machines here at
> home, tomorrow.

as far as I can see sys_ and SyS_ both present in kallsyms,
so kprobe infra should recognize both,
the question is why perf decided to ingore sys_ version?

Re: perf test BPF failing on f24: fix

[Alexei Starovoitov]

On Tue, Aug 02, 2016 at 11:15:34PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Aug 02, 2016 at 02:03:33PM -0700, Alexei Starovoitov escreveu:
> > On Tue, Aug 02, 2016 at 04:51:02PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Hi Wang,
> > > 
> > >   Something changed and a function used in a perf test for BPF is
> > > not anymore appearing on vmlinux, albeit still available on
> > > /proc/kallsyms:
> > > 
> > > # readelf -wi /lib/modules/4.7.0+/build/vmlinux | grep -w sys_epoll_wait
> > > #
> > > 
> > > But:
> > > 
> > > [root@jouet ~]# grep -i sys_epoll_wait /proc/kallsyms 
> > > bd295b50 T SyS_epoll_wait
> > > bd295b50 T sys_epoll_wait
> > > [root@jouet ~]#
> > > 
> > > I noticed that it is some sort of aliasing so I checked the other
> > > variant:
> > > 
> > > [root@jouet ~]# readelf -wi /lib/modules/4.7.0+/build/vmlinux | grep -w 
> > > SyS_epoll_wait
> > > <2bc9b85>   DW_AT_name: (indirect string, offset: 0xe7524): 
> > > SyS_epoll_wait
> > > [root@jouet ~]# 
> > > 
> > > Trying to use perf probe also produces the same resuls I notice when
> > > running the perf test that is failing:
> > > 
> > > [root@jouet ~]# perf probe sys_epoll_wait
> > > Failed to find debug information for address bd295b50
> > > Probe point 'sys_epoll_wait' not found.
> > >   Error: Failed to add events.
> > > [root@jouet ~]# perf probe SyS_epoll_wait
> > > Added new events:
> > >   probe:SyS_epoll_wait (on SyS_epoll_wait)
> > >   probe:SyS_epoll_wait_1 (on SyS_epoll_wait)
> > >   probe:SyS_epoll_wait_2 (on SyS_epoll_wait)
> > 
> > that change will break all sorts of scripts that relying on syscalls to 
> > start
> > with sys_
> 
> Is there a promise that internal kernel functions will not change names?
>
> > I guess we can workaround in user space, but what was the motivation to
> > disable kprobe attach on sys_* while it's still in kallsyms?
> 
> Was it disabled? What I noticed whas that the sys_epoll_wait wasn't
> present in the DWARF info present in the vmlinux file, which would be
> good for others to confirm, which I'll check on other machines here at
> home, tomorrow.

as far as I can see sys_ and SyS_ both present in kallsyms,
so kprobe infra should recognize both,
the question is why perf decided to ingore sys_ version?

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

[Guenter Roeck]

Hi,

I see the following crash when running a qemu arm 'kzm' runtime test with the 
current mainline.

Failed to create /dev/root: -14

[ followed by panic ]

A complete log file is at [1].

Bisect points to commit e6978e4bf1 ("ARM: save and reset the address limit when 
entering
an exception"). Some additional debugging shows lots of similar error returns 
from
strncpy_from_user(). For the error case resulting in the crash, the call chain
is as follows.

sys_mknod
  sys_mknodat()
user_path_create()
  getname()
getname_flags()
  strncpy_from_user()

Reverting the patch fixes the problem.

I don't see the problem with any other qemu arm test.

It looks like the kernel runs in exception context. My gut feeling is that qemu 
may be
to blame, but I am not really sure.

Any idea how to track this down ?

Thanks,
Guenter


---
[1] http://kerneltests.org/builders/qemu-arm-master/builds/615

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

[Guenter Roeck]

Hi,

I see the following crash when running a qemu arm 'kzm' runtime test with the 
current mainline.

Failed to create /dev/root: -14

[ followed by panic ]

A complete log file is at [1].

Bisect points to commit e6978e4bf1 ("ARM: save and reset the address limit when 
entering
an exception"). Some additional debugging shows lots of similar error returns 
from
strncpy_from_user(). For the error case resulting in the crash, the call chain
is as follows.

sys_mknod
  sys_mknodat()
user_path_create()
  getname()
getname_flags()
  strncpy_from_user()

Reverting the patch fixes the problem.

I don't see the problem with any other qemu arm test.

It looks like the kernel runs in exception context. My gut feeling is that qemu 
may be
to blame, but I am not really sure.

Any idea how to track this down ?

Thanks,
Guenter


---
[1] http://kerneltests.org/builders/qemu-arm-master/builds/615

Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template

[Masashi Honma]

On 2016年08月02日 16:27, Johannes Berg wrote:

This explicitly configures *HT capability* though - that's even the
name of the parameter. If you enable HT40 in the capability, the
resulting BSS might still not actually *use* 40 MHz bandwidth, as
required by overlapping BSS detection.


OK, I see.

HT Capabilities element = Defined by hardware and software spec of the 
node. So it does not be modified after boot.


HT Operation element = Defined by surrounding environment and 
configuration of the node. So it could be modified after boot.


So, if the node supports HT40, HT Capabilities shows HT40 is capable.
Now, I understand why you rejected this patch.

But now, when disable_ht=1, no HT Capabilities element in beacon even 
though the node supports HT.


My trailing patch could solve the issue.

Masashi Honma.

Re: [GIT PULL] KVM changes for 4.8 merge window

[Martin Schwidefsky]

On Tue, 2 Aug 2016 16:17:39 -0400
Linus Torvalds  wrote:

> On Tue, Aug 2, 2016 at 2:42 PM, Linus Torvalds
>  wrote:
> >
> > No, I don't use the merge from linux-next directly. I just re-generate
> > the merge myself, and if the pull request then includes a merge
> > resolution (either as just a verbal description, or a patch or by
> > having a separate "merged" test-branch), I will compare my merge with
> > that one.
> 
> Ok, the KVM merge was indeed the most painful one this merge window so
> far. Which isn't saying all that much, since this merge window has so
> far been pretty good (knock wood).
> 
> Let's see if I got everything right. I did pick up the fixup patch
> from Sudip and made it part of the merge, so that hopefully it's all
> complete and also bisectable.
> 
> Please do check it out. And let's hope the KVM people have learnt
> their lesson and we won't have these messy merges in the future.

I included my try to fixup the expected merge conflict between the
KVM tree and the s390 tree at the end of the first please-merge email
for s390. Dunno if you have noticed this, the merge result looks good
to me.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

[ANNOUNCE]: SCST 3.2 pre-release freeze

[Vladislav Bolkhovitin]

Hi All,

I'm glad to announce SCST 3.2 pre-release code freeze in the SCST SVN branch 
3.2.x.

You can get it by command:

$ svn co https://scst.svn.sourceforge.net/svnroot/scst/branches/3.2.x

It is going to be released after few weeks of testing, if no significant issues 
found.

SCST is alternative SCSI target stack for Linux. SCST allows creation of 
sophisticated storage devices, which can provide advanced functionality, like 
replication, thin provisioning, deduplication, high availability, automatic 
backup, etc. Majority of recently developed SAN appliances, especially higher 
end ones, are SCST based. It might well be that your favorite storage appliance 
running SCST in the firmware.

More info about SCST and its modules you can find on: 
http://scst.sourceforge.net

Thanks to all who made it happen, especially to SanDisk/WDC for the great 
support!

Vlad

Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template

[Masashi Honma]

On 2016年08月02日 16:27, Johannes Berg wrote:

This explicitly configures *HT capability* though - that's even the
name of the parameter. If you enable HT40 in the capability, the
resulting BSS might still not actually *use* 40 MHz bandwidth, as
required by overlapping BSS detection.


OK, I see.

HT Capabilities element = Defined by hardware and software spec of the 
node. So it does not be modified after boot.


HT Operation element = Defined by surrounding environment and 
configuration of the node. So it could be modified after boot.


So, if the node supports HT40, HT Capabilities shows HT40 is capable.
Now, I understand why you rejected this patch.

But now, when disable_ht=1, no HT Capabilities element in beacon even 
though the node supports HT.


My trailing patch could solve the issue.

Masashi Honma.

Re: [GIT PULL] KVM changes for 4.8 merge window

[Martin Schwidefsky]

On Tue, 2 Aug 2016 16:17:39 -0400
Linus Torvalds  wrote:

> On Tue, Aug 2, 2016 at 2:42 PM, Linus Torvalds
>  wrote:
> >
> > No, I don't use the merge from linux-next directly. I just re-generate
> > the merge myself, and if the pull request then includes a merge
> > resolution (either as just a verbal description, or a patch or by
> > having a separate "merged" test-branch), I will compare my merge with
> > that one.
> 
> Ok, the KVM merge was indeed the most painful one this merge window so
> far. Which isn't saying all that much, since this merge window has so
> far been pretty good (knock wood).
> 
> Let's see if I got everything right. I did pick up the fixup patch
> from Sudip and made it part of the merge, so that hopefully it's all
> complete and also bisectable.
> 
> Please do check it out. And let's hope the KVM people have learnt
> their lesson and we won't have these messy merges in the future.

I included my try to fixup the expected merge conflict between the
KVM tree and the s390 tree at the end of the first please-merge email
for s390. Dunno if you have noticed this, the merge result looks good
to me.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

[ANNOUNCE]: SCST 3.2 pre-release freeze

[Vladislav Bolkhovitin]

Hi All,

I'm glad to announce SCST 3.2 pre-release code freeze in the SCST SVN branch 
3.2.x.

You can get it by command:

$ svn co https://scst.svn.sourceforge.net/svnroot/scst/branches/3.2.x

It is going to be released after few weeks of testing, if no significant issues 
found.

SCST is alternative SCSI target stack for Linux. SCST allows creation of 
sophisticated storage devices, which can provide advanced functionality, like 
replication, thin provisioning, deduplication, high availability, automatic 
backup, etc. Majority of recently developed SAN appliances, especially higher 
end ones, are SCST based. It might well be that your favorite storage appliance 
running SCST in the firmware.

More info about SCST and its modules you can find on: 
http://scst.sourceforge.net

Thanks to all who made it happen, especially to SanDisk/WDC for the great 
support!

Vlad

Re: [PATCH] perf/core: Add a tracepoint for perf sampling

[Brendan Gregg]

On Fri, Jul 29, 2016 at 8:34 PM, Wangnan (F)  wrote:
>
>
> On 2016/7/30 2:05, Brendan Gregg wrote:
>>
>> On Tue, Jul 19, 2016 at 4:20 PM, Brendan Gregg  wrote:
>>>
>>> When perf is performing hrtimer-based sampling, this tracepoint can be
>>> used
>>> by BPF to run additional logic on each sample. For example, BPF can fetch
>>> stack traces and frequency count them in kernel context, for an efficient
>>> profiler.
>>
>> Any comments on this patch? Thanks,
>>
>> Brendan
>
>
> Sorry for the late.
>
> I think it is a useful feature. Could you please provide an example
> to show how to use it in perf?

Yes, the following example samples at 999 Hertz, and emits the
instruction pointer only when it is within a custom address range, as
checked by BPF. Eg:

# ./perf record -e bpf-output/no-inherit,name=evt/ \
-e ./sampleip_range.c/map:channel.event=evt/ \
-a ./perf record -F 999 -e cpu-clock -N -a -o /dev/null sleep 5
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.000 MB /dev/null ]
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.134 MB perf.data (222 samples) ]

# ./perf script -F comm,pid,time,bpf-output
'bpf-output' not valid for hardware events. Ignoring.
'bpf-output' not valid for unknown events. Ignoring.
'bpf-output' not valid for unknown events. Ignoring.
  dd  6501  3058.117379:
  BPF output: : 3c 4c 21 81 ff ff ff ff  regs);
if (regs.ip >= RANGE_START && regs.ip < RANGE_END) {
perf_event_output(ctx, , get_smp_processor_id(),
   , sizeof(regs.ip));
}
return 0;
}

char _license[] SEC("license") = "GPL";
int _version SEC("version") = LINUX_VERSION_CODE;
/* END ***/

>
> If I understand correctly, I can have a BPF script run 99 times per
> second using
>
>   # perf -e cpu-clock/freq=99/ -e mybpf.c ...
>
> And in mybpf.c, attach a BPF script on the new tracepoint. Right?
>
> Also, since we already have timer:hrtimer_expire_entry, please provide
> some further information about why we need a new tracepoint.

timer:hrtimer_expire_entry fires for much more than just the perf
timer. The perf:perf_hrtimer tracepoint also has registers and perf
context as arguments, which can be used for profiling programs.

Thanks for the comments,

Brendan

Re: [PATCH] perf/core: Add a tracepoint for perf sampling

[Brendan Gregg]

On Fri, Jul 29, 2016 at 8:34 PM, Wangnan (F)  wrote:
>
>
> On 2016/7/30 2:05, Brendan Gregg wrote:
>>
>> On Tue, Jul 19, 2016 at 4:20 PM, Brendan Gregg  wrote:
>>>
>>> When perf is performing hrtimer-based sampling, this tracepoint can be
>>> used
>>> by BPF to run additional logic on each sample. For example, BPF can fetch
>>> stack traces and frequency count them in kernel context, for an efficient
>>> profiler.
>>
>> Any comments on this patch? Thanks,
>>
>> Brendan
>
>
> Sorry for the late.
>
> I think it is a useful feature. Could you please provide an example
> to show how to use it in perf?

Yes, the following example samples at 999 Hertz, and emits the
instruction pointer only when it is within a custom address range, as
checked by BPF. Eg:

# ./perf record -e bpf-output/no-inherit,name=evt/ \
-e ./sampleip_range.c/map:channel.event=evt/ \
-a ./perf record -F 999 -e cpu-clock -N -a -o /dev/null sleep 5
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.000 MB /dev/null ]
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.134 MB perf.data (222 samples) ]

# ./perf script -F comm,pid,time,bpf-output
'bpf-output' not valid for hardware events. Ignoring.
'bpf-output' not valid for unknown events. Ignoring.
'bpf-output' not valid for unknown events. Ignoring.
  dd  6501  3058.117379:
  BPF output: : 3c 4c 21 81 ff ff ff ff  
#include 

#define SEC(NAME) __attribute__((section(NAME), used))

/*
 * Edit the following to match the instruction address range you want to
 * sample. Eg, look in /proc/kallsyms. The addresses will change for each
 * kernel version and build.
 */
#define RANGE_START  0x81214b90
#define RANGE_END0x81214cd0

struct bpf_map_def {
unsigned int type;
unsigned int key_size;
unsigned int value_size;
unsigned int max_entries;
};

static int (*probe_read)(void *dst, int size, void *src) =
(void *)BPF_FUNC_probe_read;
static int (*get_smp_processor_id)(void) =
(void *)BPF_FUNC_get_smp_processor_id;
static int (*perf_event_output)(void *, struct bpf_map_def *, int, void *,
unsigned long) = (void *)BPF_FUNC_perf_event_output;

struct bpf_map_def SEC("maps") channel = {
.type = BPF_MAP_TYPE_PERF_EVENT_ARRAY,
.key_size = sizeof(int),
.value_size = sizeof(u32),
.max_entries = __NR_CPUS__,
};

/* from /sys/kernel/debug/tracing/events/perf/perf_hrtimer/format */
struct perf_hrtimer_args {
unsigned long long pad;
struct pt_regs *regs;
struct perf_event *event;
};
SEC("perf:perf_hrtimer")
int func(struct perf_hrtimer_args *ctx)
{
struct pt_regs regs = {};
probe_read(, sizeof(regs), ctx->regs);
if (regs.ip >= RANGE_START && regs.ip < RANGE_END) {
perf_event_output(ctx, , get_smp_processor_id(),
   , sizeof(regs.ip));
}
return 0;
}

char _license[] SEC("license") = "GPL";
int _version SEC("version") = LINUX_VERSION_CODE;
/* END ***/

>
> If I understand correctly, I can have a BPF script run 99 times per
> second using
>
>   # perf -e cpu-clock/freq=99/ -e mybpf.c ...
>
> And in mybpf.c, attach a BPF script on the new tracepoint. Right?
>
> Also, since we already have timer:hrtimer_expire_entry, please provide
> some further information about why we need a new tracepoint.

timer:hrtimer_expire_entry fires for much more than just the perf
timer. The perf:perf_hrtimer tracepoint also has registers and perf
context as arguments, which can be used for profiling programs.

Thanks for the comments,

Brendan

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

[Josh Poimboeuf]

On Tue, Aug 02, 2016 at 10:30:11PM -0400, Steven Rostedt wrote:
> On Tue, 2 Aug 2016 20:56:56 -0500
> Josh Poimboeuf  wrote:
> 
> > It's not specific to NMIs.  The problem is that dump_trace() is starting
> > from the frame pointed to by a pt_regs, rather than the current frame.
> > Instead of starting with the current frame, the first 10 functions on
> > the stack are skipped by the unwinder, but they're *not* skipped on the
> > ret_stack.  So it starts out out-of-sync.
> 
> OK, I see what you mean. If we do a dumpstack from interrupt passing in
> the pt_regs of the kernel thread that was interrupted, even though
> functions up to the interrupt was called and traced, which will show up
> in the dump stack that shouldn't.
> 
> OK, you convinced me. Add the extra pointer, then we will have 4 longs
> and 2 long longs in ftrace_ret_stack. That's not that bad.

Hm, since 'fp' is only used for mcount, I guess we could avoid
allocating it for fentry?  That would save a long when a modern compiler
is used.  Like:

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 1e814ae..fc508a7 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -795,7 +795,9 @@ struct ftrace_ret_stack {
unsigned long func;
unsigned long long calltime;
unsigned long long subtime;
+#if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && !defined(CC_USING_FENTRY)
unsigned long fp;
+#endif
 };
 
 /*
diff --git a/kernel/trace/trace_functions_graph.c 
b/kernel/trace/trace_functions_graph.c
index 9caa9b2..86b2719 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -171,7 +171,9 @@ ftrace_push_return_trace(unsigned long ret, unsigned long 
func, int *depth,
current->ret_stack[index].func = func;
current->ret_stack[index].calltime = calltime;
current->ret_stack[index].subtime = 0;
+#if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && !defined(CC_USING_FENTRY)
current->ret_stack[index].fp = frame_pointer;
+#endif
*depth = current->curr_ret_stack;
 
return 0;

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

[Josh Poimboeuf]

On Tue, Aug 02, 2016 at 10:30:11PM -0400, Steven Rostedt wrote:
> On Tue, 2 Aug 2016 20:56:56 -0500
> Josh Poimboeuf  wrote:
> 
> > It's not specific to NMIs.  The problem is that dump_trace() is starting
> > from the frame pointed to by a pt_regs, rather than the current frame.
> > Instead of starting with the current frame, the first 10 functions on
> > the stack are skipped by the unwinder, but they're *not* skipped on the
> > ret_stack.  So it starts out out-of-sync.
> 
> OK, I see what you mean. If we do a dumpstack from interrupt passing in
> the pt_regs of the kernel thread that was interrupted, even though
> functions up to the interrupt was called and traced, which will show up
> in the dump stack that shouldn't.
> 
> OK, you convinced me. Add the extra pointer, then we will have 4 longs
> and 2 long longs in ftrace_ret_stack. That's not that bad.

Hm, since 'fp' is only used for mcount, I guess we could avoid
allocating it for fentry?  That would save a long when a modern compiler
is used.  Like:

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 1e814ae..fc508a7 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -795,7 +795,9 @@ struct ftrace_ret_stack {
unsigned long func;
unsigned long long calltime;
unsigned long long subtime;
+#if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && !defined(CC_USING_FENTRY)
unsigned long fp;
+#endif
 };
 
 /*
diff --git a/kernel/trace/trace_functions_graph.c 
b/kernel/trace/trace_functions_graph.c
index 9caa9b2..86b2719 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -171,7 +171,9 @@ ftrace_push_return_trace(unsigned long ret, unsigned long 
func, int *depth,
current->ret_stack[index].func = func;
current->ret_stack[index].calltime = calltime;
current->ret_stack[index].subtime = 0;
+#if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && !defined(CC_USING_FENTRY)
current->ret_stack[index].fp = frame_pointer;
+#endif
*depth = current->curr_ret_stack;
 
return 0;

[PATCH v2 2/3] samples/bpf: Add a sampling BPF example

[Brendan Gregg]

This example samples the instruction pointer at a timed interval, and
frequency counts it in a BPF map. It is an example of summarizing sampled
data in-kernel for passing to user space. It uses the perf:perf_hrtimer
tracepoint with perf_events sampling.

Example output:

Sampling at 99 Hertz for 5 seconds. Ctrl-C also ends.
ADDRKSYM COUNT
0x81257088  __fsnotify_parent1
0x7f20b792d9b0  (user)   1
0x8121469e  __vfs_read   1
0x81214afd  rw_verify_area   1
0x8123327e  __fget_light 1
0x7fc0965a6e2c  (user)   1
0x81233c04  __fdget_pos  1
0x81378528  common_file_perm 1
0x404d90(user)   1
0x81214c13  vfs_read 1
[...]
0x813d9e97  copy_user_enhanced_fast_string   3
0x817e310c  _raw_spin_lock_irqsave   4
0x817e31a0  entry_SYSCALL_64_fastpath4
0x814fb96c  extract_crng 6
0x813d9e95  copy_user_enhanced_fast_string   7
0x814fb8a3  _extract_crng7
0x817e2d55  _raw_spin_unlock_irqrestore  1399
0x8105fb46  native_safe_halt 2190

It also has basic options:

USAGE: sampleip [-F freq] [duration]
   -F freq# sample frequency (Hertz), default 99
   duration   # sampling duration (seconds), default 5

Signed-off-by: Brendan Gregg 
Cc: Alexei Starovoitov 
Cc: Wang Nan 
---
 samples/bpf/Makefile|   4 +
 samples/bpf/sampleip_kern.c |  48 +++
 samples/bpf/sampleip_user.c | 189 
 3 files changed, 241 insertions(+)
 create mode 100644 samples/bpf/sampleip_kern.c
 create mode 100644 samples/bpf/sampleip_user.c

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 90ebf7d..dc88a1e 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -24,6 +24,7 @@ hostprogs-y += test_overhead
 hostprogs-y += test_cgrp2_array_pin
 hostprogs-y += xdp1
 hostprogs-y += xdp2
+hostprogs-y += sampleip
 
 test_verifier-objs := test_verifier.o libbpf.o
 test_maps-objs := test_maps.o libbpf.o
@@ -49,6 +50,7 @@ test_cgrp2_array_pin-objs := libbpf.o test_cgrp2_array_pin.o
 xdp1-objs := bpf_load.o libbpf.o xdp1_user.o
 # reuse xdp1 source intentionally
 xdp2-objs := bpf_load.o libbpf.o xdp1_user.o
+sampleip-objs := bpf_load.o libbpf.o sampleip_user.o
 
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
@@ -74,6 +76,7 @@ always += parse_varlen.o parse_simple.o parse_ldabs.o
 always += test_cgrp2_tc_kern.o
 always += xdp1_kern.o
 always += xdp2_kern.o
+always += sampleip_kern.o
 
 HOSTCFLAGS += -I$(objtree)/usr/include
 
@@ -97,6 +100,7 @@ HOSTLOADLIBES_map_perf_test += -lelf -lrt
 HOSTLOADLIBES_test_overhead += -lelf -lrt
 HOSTLOADLIBES_xdp1 += -lelf
 HOSTLOADLIBES_xdp2 += -lelf
+HOSTLOADLIBES_sampleip += -lelf
 
 # Allows pointing LLC/CLANG to a LLVM backend with bpf support, redefine on 
cmdline:
 #  make samples/bpf/ LLC=~/git/llvm/build/bin/llc 
CLANG=~/git/llvm/build/bin/clang
diff --git a/samples/bpf/sampleip_kern.c b/samples/bpf/sampleip_kern.c
new file mode 100644
index 000..afec3fe
--- /dev/null
+++ b/samples/bpf/sampleip_kern.c
@@ -0,0 +1,48 @@
+/* Copyright 2016 Netflix, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include "bpf_helpers.h"
+
+#define MAX_IPS8192
+
+#define _(P) ({typeof(P) val; bpf_probe_read(, sizeof(val), ); val;})
+
+struct bpf_map_def SEC("maps") ip_map = {
+   .type = BPF_MAP_TYPE_HASH,
+   .key_size = sizeof(u64),
+   .value_size = sizeof(u32),
+   .max_entries = MAX_IPS,
+};
+
+/* from /sys/kernel/debug/tracing/events/perf/perf_hrtimer/format */
+struct perf_hrtimer_args {
+   unsigned long long pad;
+   struct pt_regs *regs;
+   struct perf_event *event;
+};
+SEC("tracepoint/perf/perf_hrtimer")
+int do_sample(struct perf_hrtimer_args *args)
+{
+   struct pt_regs *regs;
+   u64 ip;
+   u32 *value, init_val = 1;
+
+   regs = _(args->regs);
+   ip = _(regs->ip);
+   value = bpf_map_lookup_elem(_map, );
+   if (value)
+   *value += 1;
+   else
+   /* E2BIG not tested for this example only */
+   bpf_map_update_elem(_map, , _val, BPF_ANY);
+
+   return 0;
+}
+char _license[] SEC("license") = "GPL";
+u32 _version SEC("version") = LINUX_VERSION_CODE;
diff --git a/samples/bpf/sampleip_user.c b/samples/bpf/sampleip_user.c
new file mode 100644
index 000..da0727d
--- /dev/null
+++ 

[PATCH v2 2/3] samples/bpf: Add a sampling BPF example

[Brendan Gregg]

This example samples the instruction pointer at a timed interval, and
frequency counts it in a BPF map. It is an example of summarizing sampled
data in-kernel for passing to user space. It uses the perf:perf_hrtimer
tracepoint with perf_events sampling.

Example output:

Sampling at 99 Hertz for 5 seconds. Ctrl-C also ends.
ADDRKSYM COUNT
0x81257088  __fsnotify_parent1
0x7f20b792d9b0  (user)   1
0x8121469e  __vfs_read   1
0x81214afd  rw_verify_area   1
0x8123327e  __fget_light 1
0x7fc0965a6e2c  (user)   1
0x81233c04  __fdget_pos  1
0x81378528  common_file_perm 1
0x404d90(user)   1
0x81214c13  vfs_read 1
[...]
0x813d9e97  copy_user_enhanced_fast_string   3
0x817e310c  _raw_spin_lock_irqsave   4
0x817e31a0  entry_SYSCALL_64_fastpath4
0x814fb96c  extract_crng 6
0x813d9e95  copy_user_enhanced_fast_string   7
0x814fb8a3  _extract_crng7
0x817e2d55  _raw_spin_unlock_irqrestore  1399
0x8105fb46  native_safe_halt 2190

It also has basic options:

USAGE: sampleip [-F freq] [duration]
   -F freq# sample frequency (Hertz), default 99
   duration   # sampling duration (seconds), default 5

Signed-off-by: Brendan Gregg 
Cc: Alexei Starovoitov 
Cc: Wang Nan 
---
 samples/bpf/Makefile|   4 +
 samples/bpf/sampleip_kern.c |  48 +++
 samples/bpf/sampleip_user.c | 189 
 3 files changed, 241 insertions(+)
 create mode 100644 samples/bpf/sampleip_kern.c
 create mode 100644 samples/bpf/sampleip_user.c

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 90ebf7d..dc88a1e 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -24,6 +24,7 @@ hostprogs-y += test_overhead
 hostprogs-y += test_cgrp2_array_pin
 hostprogs-y += xdp1
 hostprogs-y += xdp2
+hostprogs-y += sampleip
 
 test_verifier-objs := test_verifier.o libbpf.o
 test_maps-objs := test_maps.o libbpf.o
@@ -49,6 +50,7 @@ test_cgrp2_array_pin-objs := libbpf.o test_cgrp2_array_pin.o
 xdp1-objs := bpf_load.o libbpf.o xdp1_user.o
 # reuse xdp1 source intentionally
 xdp2-objs := bpf_load.o libbpf.o xdp1_user.o
+sampleip-objs := bpf_load.o libbpf.o sampleip_user.o
 
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
@@ -74,6 +76,7 @@ always += parse_varlen.o parse_simple.o parse_ldabs.o
 always += test_cgrp2_tc_kern.o
 always += xdp1_kern.o
 always += xdp2_kern.o
+always += sampleip_kern.o
 
 HOSTCFLAGS += -I$(objtree)/usr/include
 
@@ -97,6 +100,7 @@ HOSTLOADLIBES_map_perf_test += -lelf -lrt
 HOSTLOADLIBES_test_overhead += -lelf -lrt
 HOSTLOADLIBES_xdp1 += -lelf
 HOSTLOADLIBES_xdp2 += -lelf
+HOSTLOADLIBES_sampleip += -lelf
 
 # Allows pointing LLC/CLANG to a LLVM backend with bpf support, redefine on 
cmdline:
 #  make samples/bpf/ LLC=~/git/llvm/build/bin/llc 
CLANG=~/git/llvm/build/bin/clang
diff --git a/samples/bpf/sampleip_kern.c b/samples/bpf/sampleip_kern.c
new file mode 100644
index 000..afec3fe
--- /dev/null
+++ b/samples/bpf/sampleip_kern.c
@@ -0,0 +1,48 @@
+/* Copyright 2016 Netflix, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include "bpf_helpers.h"
+
+#define MAX_IPS8192
+
+#define _(P) ({typeof(P) val; bpf_probe_read(, sizeof(val), ); val;})
+
+struct bpf_map_def SEC("maps") ip_map = {
+   .type = BPF_MAP_TYPE_HASH,
+   .key_size = sizeof(u64),
+   .value_size = sizeof(u32),
+   .max_entries = MAX_IPS,
+};
+
+/* from /sys/kernel/debug/tracing/events/perf/perf_hrtimer/format */
+struct perf_hrtimer_args {
+   unsigned long long pad;
+   struct pt_regs *regs;
+   struct perf_event *event;
+};
+SEC("tracepoint/perf/perf_hrtimer")
+int do_sample(struct perf_hrtimer_args *args)
+{
+   struct pt_regs *regs;
+   u64 ip;
+   u32 *value, init_val = 1;
+
+   regs = _(args->regs);
+   ip = _(regs->ip);
+   value = bpf_map_lookup_elem(_map, );
+   if (value)
+   *value += 1;
+   else
+   /* E2BIG not tested for this example only */
+   bpf_map_update_elem(_map, , _val, BPF_ANY);
+
+   return 0;
+}
+char _license[] SEC("license") = "GPL";
+u32 _version SEC("version") = LINUX_VERSION_CODE;
diff --git a/samples/bpf/sampleip_user.c b/samples/bpf/sampleip_user.c
new file mode 100644
index 000..da0727d
--- /dev/null
+++ b/samples/bpf/sampleip_user.c
@@ -0,0 +1,189 @@
+/*
+ * sampleip: sample instruction