Re: [PATCH 2/3] thermal: Add Mediatek thermal driver for mt2701.

[dawei chien]

Dear Keerthy,

On Mon, 2016-07-11 at 16:56 +0800, dawei chien wrote:
> Dear Keerthy,
> 
> On Thu, 2016-07-07 at 17:24 +0530, Keerthy wrote:
> > Hi Dawei Chien,
> > 
> > 
> > On Thursday 07 July 2016 02:36 PM, Dawei Chien wrote:
> > > This patch adds support for mt2701 chip to mtk_thermal.c,
> > > and integrate both mt8173 and mt2701 on the same driver.
> > > MT8173 has four banks and five sensors, and MT2701 has
> > > only one bank and three sensors.
> > >
> > > Signed-off-by: Dawei Chien 
> > > ---
> > >   drivers/thermal/mtk_thermal.c |  258 
> > > ++---
> > >   1 file changed, 165 insertions(+), 93 deletions(-)
> > >
> > > diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> > > index 262ab0a..860f2e2 100644
> > > --- a/drivers/thermal/mtk_thermal.c
> > > +++ b/drivers/thermal/mtk_thermal.c
> > > @@ -2,6 +2,7 @@
> > >* Copyright (c) 2015 MediaTek Inc.
> > >* Author: Hanyi Wu 
> > >* Sascha Hauer 
> > > + * Dawei Chien 
> > >*
> > >* This program is free software; you can redistribute it and/or modify
> > >* it under the terms of the GNU General Public License version 2 as
> > > @@ -21,6 +22,7 @@
> > >   #include 
> > >   #include 
> > >   #include 
> > > +#include 
> > >   #include 
> > >   #include 
> > >   #include 
> > > @@ -88,6 +90,7 @@
> > >   #define TEMP_ADCVALIDMASK_VALID_HIGHBIT(5)
> > >   #define TEMP_ADCVALIDMASK_VALID_POS(bit)(bit)
> > >
> > > +/* MT8173 thermal sensors */
> > >   #define MT8173_TS1  0
> > >   #define MT8173_TS2  1
> > >   #define MT8173_TS3  2
> > > @@ -97,35 +100,62 @@
> > >   /* AUXADC channel 11 is used for the temperature sensors */
> > >   #define MT8173_TEMP_AUXADC_CHANNEL  11
> > >
> > > -/* The total number of temperature sensors in the MT8173 */
> > > -#define MT8173_NUM_SENSORS   5
> > > -
> > > -/* The number of banks in the MT8173 */
> > > -#define MT8173_NUM_ZONES 4
> > > -
> > > -/* The number of sensing points per bank */
> > > -#define MT8173_NUM_SENSORS_PER_ZONE  4
> > > -
> > >   /* Layout of the fuses providing the calibration data */
> > > -#define MT8173_CALIB_BUF0_VALID  BIT(0)
> > > -#define MT8173_CALIB_BUF1_ADC_GE(x)  (((x) >> 22) & 0x3ff)
> > > -#define MT8173_CALIB_BUF0_VTS_TS1(x) (((x) >> 17) & 0x1ff)
> > > -#define MT8173_CALIB_BUF0_VTS_TS2(x) (((x) >> 8) & 0x1ff)
> > > -#define MT8173_CALIB_BUF1_VTS_TS3(x) (((x) >> 0) & 0x1ff)
> > > -#define MT8173_CALIB_BUF2_VTS_TS4(x) (((x) >> 23) & 0x1ff)
> > > -#define MT8173_CALIB_BUF2_VTS_TSABB(x)   (((x) >> 14) & 0x1ff)
> > > -#define MT8173_CALIB_BUF0_DEGC_CALI(x)   (((x) >> 1) & 0x3f)
> > > -#define MT8173_CALIB_BUF0_O_SLOPE(x) (((x) >> 26) & 0x3f)
> > > +#define CALIB_BUF0_VALID BIT(0)
> > > +#define CALIB_BUF1_ADC_GE(x) (((x) >> 22) & 0x3ff)
> > > +#define CALIB_BUF0_VTS_TS1(x)(((x) >> 17) & 0x1ff)
> > > +#define CALIB_BUF0_VTS_TS2(x)(((x) >> 8) & 0x1ff)
> > > +#define CALIB_BUF1_VTS_TS3(x)(((x) >> 0) & 0x1ff)
> > > +#define CALIB_BUF2_VTS_TS4(x)(((x) >> 23) & 0x1ff)
> > > +#define CALIB_BUF2_VTS_TS5(x)(((x) >> 14) & 0x1ff)
> > > +#define CALIB_BUF0_DEGC_CALI(x)  (((x) >> 1) & 0x3f)
> > > +#define CALIB_BUF0_O_SLOPE(x)(((x) >> 26) & 0x3f)
> > > +
> > 
> > IMHO the above changes from defining CALIB_BUF1_ADC_GE(x) to 
> > CALIB_BUF0_O_SLOPE(x) can be avoided. We are just renaming the same 
> > defines to a generic name. Instead the macro starting with MT8173 can 
> > only be used wherever needed commonly both by 8173 instance and for
> > 2701 instance.
> > 
> 
> I would have a try to keep MT8173 original one and add some comment for
> the macro starting on next version.

Just confirm again,
we don't need change common macro name, and just need to add comment for
MT8173/MT2701, right?

> > > +#define NVMEM_TS10
> > > +#define NVMEM_TS21
> > > +#define NVMEM_TS32
> > > +#define NVMEM_TS43
> > > +#define NVMEM_TS54
> > > +
> 
> Does these need to keep the old one
> MT8173_TS1/MT8173_TS2/MT8173_TS3/MT8173_TS4/MT8173_TSABB

MT8173 has 5 sensors, so it need 5 address for calibration data.
And MT2701 has three sensors, so it need 3 address for that.

Do you think we need either keep the original one or rename for these.

> 
> 
> > > +/* MT2701 thermal sensors */
> > > +#define MT2701_TS1   0
> > > +#define MT2701_TS2   1
> > > +#define MT2701_TSABB 2
> > > +
> > > +/* AUXADC channel 11 is used for the temperature sensors */
> > > +#define MT2701_TEMP_AUXADC_CHANNEL   11
> > >
> > >   #define THERMAL_NAME"mtk-thermal"
> > >
> > > +/* Maximum support banks */
> > > +#define MAX_NUM_BANK 5
> > 
> > Why is this 5?
> > Commit message states: MT8173 has four banks and five sensors, and 
> > MT2701 has only one bank and 

Re: [PATCH 2/3] thermal: Add Mediatek thermal driver for mt2701.

[dawei chien]

Dear Keerthy,

On Mon, 2016-07-11 at 16:56 +0800, dawei chien wrote:
> Dear Keerthy,
> 
> On Thu, 2016-07-07 at 17:24 +0530, Keerthy wrote:
> > Hi Dawei Chien,
> > 
> > 
> > On Thursday 07 July 2016 02:36 PM, Dawei Chien wrote:
> > > This patch adds support for mt2701 chip to mtk_thermal.c,
> > > and integrate both mt8173 and mt2701 on the same driver.
> > > MT8173 has four banks and five sensors, and MT2701 has
> > > only one bank and three sensors.
> > >
> > > Signed-off-by: Dawei Chien 
> > > ---
> > >   drivers/thermal/mtk_thermal.c |  258 
> > > ++---
> > >   1 file changed, 165 insertions(+), 93 deletions(-)
> > >
> > > diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> > > index 262ab0a..860f2e2 100644
> > > --- a/drivers/thermal/mtk_thermal.c
> > > +++ b/drivers/thermal/mtk_thermal.c
> > > @@ -2,6 +2,7 @@
> > >* Copyright (c) 2015 MediaTek Inc.
> > >* Author: Hanyi Wu 
> > >* Sascha Hauer 
> > > + * Dawei Chien 
> > >*
> > >* This program is free software; you can redistribute it and/or modify
> > >* it under the terms of the GNU General Public License version 2 as
> > > @@ -21,6 +22,7 @@
> > >   #include 
> > >   #include 
> > >   #include 
> > > +#include 
> > >   #include 
> > >   #include 
> > >   #include 
> > > @@ -88,6 +90,7 @@
> > >   #define TEMP_ADCVALIDMASK_VALID_HIGHBIT(5)
> > >   #define TEMP_ADCVALIDMASK_VALID_POS(bit)(bit)
> > >
> > > +/* MT8173 thermal sensors */
> > >   #define MT8173_TS1  0
> > >   #define MT8173_TS2  1
> > >   #define MT8173_TS3  2
> > > @@ -97,35 +100,62 @@
> > >   /* AUXADC channel 11 is used for the temperature sensors */
> > >   #define MT8173_TEMP_AUXADC_CHANNEL  11
> > >
> > > -/* The total number of temperature sensors in the MT8173 */
> > > -#define MT8173_NUM_SENSORS   5
> > > -
> > > -/* The number of banks in the MT8173 */
> > > -#define MT8173_NUM_ZONES 4
> > > -
> > > -/* The number of sensing points per bank */
> > > -#define MT8173_NUM_SENSORS_PER_ZONE  4
> > > -
> > >   /* Layout of the fuses providing the calibration data */
> > > -#define MT8173_CALIB_BUF0_VALID  BIT(0)
> > > -#define MT8173_CALIB_BUF1_ADC_GE(x)  (((x) >> 22) & 0x3ff)
> > > -#define MT8173_CALIB_BUF0_VTS_TS1(x) (((x) >> 17) & 0x1ff)
> > > -#define MT8173_CALIB_BUF0_VTS_TS2(x) (((x) >> 8) & 0x1ff)
> > > -#define MT8173_CALIB_BUF1_VTS_TS3(x) (((x) >> 0) & 0x1ff)
> > > -#define MT8173_CALIB_BUF2_VTS_TS4(x) (((x) >> 23) & 0x1ff)
> > > -#define MT8173_CALIB_BUF2_VTS_TSABB(x)   (((x) >> 14) & 0x1ff)
> > > -#define MT8173_CALIB_BUF0_DEGC_CALI(x)   (((x) >> 1) & 0x3f)
> > > -#define MT8173_CALIB_BUF0_O_SLOPE(x) (((x) >> 26) & 0x3f)
> > > +#define CALIB_BUF0_VALID BIT(0)
> > > +#define CALIB_BUF1_ADC_GE(x) (((x) >> 22) & 0x3ff)
> > > +#define CALIB_BUF0_VTS_TS1(x)(((x) >> 17) & 0x1ff)
> > > +#define CALIB_BUF0_VTS_TS2(x)(((x) >> 8) & 0x1ff)
> > > +#define CALIB_BUF1_VTS_TS3(x)(((x) >> 0) & 0x1ff)
> > > +#define CALIB_BUF2_VTS_TS4(x)(((x) >> 23) & 0x1ff)
> > > +#define CALIB_BUF2_VTS_TS5(x)(((x) >> 14) & 0x1ff)
> > > +#define CALIB_BUF0_DEGC_CALI(x)  (((x) >> 1) & 0x3f)
> > > +#define CALIB_BUF0_O_SLOPE(x)(((x) >> 26) & 0x3f)
> > > +
> > 
> > IMHO the above changes from defining CALIB_BUF1_ADC_GE(x) to 
> > CALIB_BUF0_O_SLOPE(x) can be avoided. We are just renaming the same 
> > defines to a generic name. Instead the macro starting with MT8173 can 
> > only be used wherever needed commonly both by 8173 instance and for
> > 2701 instance.
> > 
> 
> I would have a try to keep MT8173 original one and add some comment for
> the macro starting on next version.

Just confirm again,
we don't need change common macro name, and just need to add comment for
MT8173/MT2701, right?

> > > +#define NVMEM_TS10
> > > +#define NVMEM_TS21
> > > +#define NVMEM_TS32
> > > +#define NVMEM_TS43
> > > +#define NVMEM_TS54
> > > +
> 
> Does these need to keep the old one
> MT8173_TS1/MT8173_TS2/MT8173_TS3/MT8173_TS4/MT8173_TSABB

MT8173 has 5 sensors, so it need 5 address for calibration data.
And MT2701 has three sensors, so it need 3 address for that.

Do you think we need either keep the original one or rename for these.

> 
> 
> > > +/* MT2701 thermal sensors */
> > > +#define MT2701_TS1   0
> > > +#define MT2701_TS2   1
> > > +#define MT2701_TSABB 2
> > > +
> > > +/* AUXADC channel 11 is used for the temperature sensors */
> > > +#define MT2701_TEMP_AUXADC_CHANNEL   11
> > >
> > >   #define THERMAL_NAME"mtk-thermal"
> > >
> > > +/* Maximum support banks */
> > > +#define MAX_NUM_BANK 5
> > 
> > Why is this 5?
> > Commit message states: MT8173 has four banks and five sensors, and 
> > MT2701 has only one bank and three sensors. Am i missing something here?
> > 
> 
> This is my miss, it should be 4, but it line 

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

[James Liao]

On Wed, 2016-08-03 at 13:46 +0800, James Liao wrote:
> 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 

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

[James Liao]

On Wed, 2016-08-03 at 13:46 +0800, James Liao wrote:
> 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
> 

Re: [Letux-kernel] [PATCH v2] musb: omap2430: do not assume balanced enable()/disable()

[Andreas Kemnade]

On Fri, 5 Aug 2016 23:21:35 -0700
Tony Lindgren  wrote:

> * Andreas Kemnade  [160805 08:35]:
> > I repeat the subject line of the patch:
> > [PATCH v2] musb: omap2430: do not assume balanced enable()/disable()
> > It is *not* fix charging.
> > 
> > So you mean that the phy should magically know at which refcounter
> > it should power on and off if power on/off is not called in the
> > balanced way?
> 
> No, I mean we need to figure out why things can be called in
> unbalanced way. With your patch I end up with unbalanced calls
> leaving the phy on after all the modules have been removed :)
> 
Well, causing trouble when modules are removed was not the intention.
I was just happy to have things working a bit again.
The phy is powered on/off via
musb_platform_enable()/musb_platform_disable().

Calls to musb_platform_enable() occur at only 1 place.
musb_platform_disable() is called at 4 places.

about balancing:
There is musb_start() and musb_stop(). They are called from
musb_gadget_start/stop()
These call musb_platform_enable() and musb_platform_disable().
Looks ok.

There is musb_suspend() and musb_resume():

musb_suspend() calls musb_platform_disable()
musb_resume() calls musb_plaform_enable() via musb_start()
looks balanced but why don't we use musb_stop() in musb_suspend()?

Now the odd things:
musb_platform_disable() in musb_remove() called upon module removal
musb_platform_disable() in musb_init_controller() called from
musb_probe()

This looks clearly unbalanced.


> > Maybe the phy-twl4030 uses the phy layer wrong. 
> > Now the relevant part of power on/off in phy-twl4030 is done via
> > struct phy_ops.power_off/power_on (*not* via pm_runtime). Maybe
> > that is wrong and more parts should be moved to the pm_runtime
> > stuff (which is also present). 
> 
> We should use phy power_off/power_on for the USB related parts.
> The parts needed by other components, like VBUS detection, should
> be handled by PM runtime. We should get phy-twl4030-usb and the
> charger driver working also when no musb modules are loaded.
> 
> > Then the phy subsystem has its own power refcounter in struct
> > phy.power_count. It it handled via phy_power_off()/phy_power_on().
> > And that is called from musb/omap2430.c 
> > But that is another story. 
> 
> Yes that's what the USB driver is expected to do. But obviously
> there are issues remaining also in the phy-twl4030-usb.c driver.
> And it seems that we should have some OTG parts always enabled
> when VBUS is detected when twl4030-charger is configured?
> 
Seems so. I am writing a patch for it.

> > > If there are MUSB specific PM runtime issues then let's fix
> > > those separately.
> > > 
> > And that exactly tries my patch to do. For that task it does not
> > even use the PM runtime system. Again please read the subject line
> > of the patch. Maybe it unveils some other pm issues in musb
> > which should first be fixed in a complete patch series.
> 
> Certainly that needs to be fixed, but let's do it in a way where
> things work for other test cases also. Care to describe how to
> to reproduce the issue you're seeing? It seems that you are
> seeing devices not being enmerated leading to the charger not
> working? Is this with built in MUSB and phy modules?
> 
Both as modules. I added some debug output to the driver/phy/phy-core.c
and have seen the phy->power_count sticking at -1 or 0. 
g_ether is also loaded.
Gadget stops for me (device not showing up at the other side) at 4.7rc4.
But I remember Nikolaus having the situation on the same type of device
that it was important on which side you replug the usb cable
(probably causing some timing differences) with 4.7rc1.

Regards,
Andreas


pgpz33vMleAJR.pgp
Description: OpenPGP digital signature

Re: [Letux-kernel] [PATCH v2] musb: omap2430: do not assume balanced enable()/disable()

[Andreas Kemnade]

On Fri, 5 Aug 2016 23:21:35 -0700
Tony Lindgren  wrote:

> * Andreas Kemnade  [160805 08:35]:
> > I repeat the subject line of the patch:
> > [PATCH v2] musb: omap2430: do not assume balanced enable()/disable()
> > It is *not* fix charging.
> > 
> > So you mean that the phy should magically know at which refcounter
> > it should power on and off if power on/off is not called in the
> > balanced way?
> 
> No, I mean we need to figure out why things can be called in
> unbalanced way. With your patch I end up with unbalanced calls
> leaving the phy on after all the modules have been removed :)
> 
Well, causing trouble when modules are removed was not the intention.
I was just happy to have things working a bit again.
The phy is powered on/off via
musb_platform_enable()/musb_platform_disable().

Calls to musb_platform_enable() occur at only 1 place.
musb_platform_disable() is called at 4 places.

about balancing:
There is musb_start() and musb_stop(). They are called from
musb_gadget_start/stop()
These call musb_platform_enable() and musb_platform_disable().
Looks ok.

There is musb_suspend() and musb_resume():

musb_suspend() calls musb_platform_disable()
musb_resume() calls musb_plaform_enable() via musb_start()
looks balanced but why don't we use musb_stop() in musb_suspend()?

Now the odd things:
musb_platform_disable() in musb_remove() called upon module removal
musb_platform_disable() in musb_init_controller() called from
musb_probe()

This looks clearly unbalanced.


> > Maybe the phy-twl4030 uses the phy layer wrong. 
> > Now the relevant part of power on/off in phy-twl4030 is done via
> > struct phy_ops.power_off/power_on (*not* via pm_runtime). Maybe
> > that is wrong and more parts should be moved to the pm_runtime
> > stuff (which is also present). 
> 
> We should use phy power_off/power_on for the USB related parts.
> The parts needed by other components, like VBUS detection, should
> be handled by PM runtime. We should get phy-twl4030-usb and the
> charger driver working also when no musb modules are loaded.
> 
> > Then the phy subsystem has its own power refcounter in struct
> > phy.power_count. It it handled via phy_power_off()/phy_power_on().
> > And that is called from musb/omap2430.c 
> > But that is another story. 
> 
> Yes that's what the USB driver is expected to do. But obviously
> there are issues remaining also in the phy-twl4030-usb.c driver.
> And it seems that we should have some OTG parts always enabled
> when VBUS is detected when twl4030-charger is configured?
> 
Seems so. I am writing a patch for it.

> > > If there are MUSB specific PM runtime issues then let's fix
> > > those separately.
> > > 
> > And that exactly tries my patch to do. For that task it does not
> > even use the PM runtime system. Again please read the subject line
> > of the patch. Maybe it unveils some other pm issues in musb
> > which should first be fixed in a complete patch series.
> 
> Certainly that needs to be fixed, but let's do it in a way where
> things work for other test cases also. Care to describe how to
> to reproduce the issue you're seeing? It seems that you are
> seeing devices not being enmerated leading to the charger not
> working? Is this with built in MUSB and phy modules?
> 
Both as modules. I added some debug output to the driver/phy/phy-core.c
and have seen the phy->power_count sticking at -1 or 0. 
g_ether is also loaded.
Gadget stops for me (device not showing up at the other side) at 4.7rc4.
But I remember Nikolaus having the situation on the same type of device
that it was important on which side you replug the usb cable
(probably causing some timing differences) with 4.7rc1.

Regards,
Andreas


pgpz33vMleAJR.pgp
Description: OpenPGP digital signature

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

[Mika Penttilä]

On 08/08/2016 09:40 PM, Thomas Garnier wrote:
> Default implementation expects 6 pages maximum are needed for low page
> allocations. If KASLR memory randomization is enabled, the worse case
> of e820 layout would require 12 pages (no large pages). It is due to the
> PUD level randomization and the variable e820 memory layout.
> 
> This bug was found while doing extensive testing of KASLR memory
> randomization on different type of hardware.
> 
> Signed-off-by: Thomas Garnier 
> ---
> Based on next-20160805
> ---
>  arch/x86/mm/init.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index 6209289..3a27e6a 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -130,6 +130,14 @@ void  __init early_alloc_pgt_buf(void)
>   unsigned long tables = INIT_PGT_BUF_SIZE;
>   phys_addr_t base;
>  
> + /*
> +  * Depending on the machine e860 memory layout and the PUD alignement.
> +  * We may need twice more pages when KASLR memoy randomization is
> +  * enabled.
> +  */
> + if (IS_ENABLED(CONFIG_RANDOMIZE_MEMORY))
> + tables *= 2;
> +
>   base = __pa(extend_brk(tables, PAGE_SIZE));
>  
>   pgt_buf_start = base >> PAGE_SHIFT;
> 

You should increase the reserve also :
RESERVE_BRK(early_pgt_alloc, INIT_PGT_BUF_SIZE);


--Mika

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

[Mika Penttilä]

On 08/08/2016 09:40 PM, Thomas Garnier wrote:
> Default implementation expects 6 pages maximum are needed for low page
> allocations. If KASLR memory randomization is enabled, the worse case
> of e820 layout would require 12 pages (no large pages). It is due to the
> PUD level randomization and the variable e820 memory layout.
> 
> This bug was found while doing extensive testing of KASLR memory
> randomization on different type of hardware.
> 
> Signed-off-by: Thomas Garnier 
> ---
> Based on next-20160805
> ---
>  arch/x86/mm/init.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index 6209289..3a27e6a 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -130,6 +130,14 @@ void  __init early_alloc_pgt_buf(void)
>   unsigned long tables = INIT_PGT_BUF_SIZE;
>   phys_addr_t base;
>  
> + /*
> +  * Depending on the machine e860 memory layout and the PUD alignement.
> +  * We may need twice more pages when KASLR memoy randomization is
> +  * enabled.
> +  */
> + if (IS_ENABLED(CONFIG_RANDOMIZE_MEMORY))
> + tables *= 2;
> +
>   base = __pa(extend_brk(tables, PAGE_SIZE));
>  
>   pgt_buf_start = base >> PAGE_SHIFT;
> 

You should increase the reserve also :
RESERVE_BRK(early_pgt_alloc, INIT_PGT_BUF_SIZE);


--Mika

[PATCH] cgroup: add tracepoints for basic operations

[Tejun Heo]

>From 471f89b317a21a78dacaee85957984b9f11e79e4 Mon Sep 17 00:00:00 2001
From: Tejun Heo 
Date: Tue, 9 Aug 2016 01:11:13 -0400

Debugging what goes wrong with cgroup setup can get hairy.  Add
tracepoints for cgroup hierarchy mount, cgroup creation/destruction
and task migration operations for better visibility.

Signed-off-by: Tejun Heo 
---
This patchset is on top of

  v4.8-rc1 29b4817d4018df78086157ea3a55c1d9424a7cfc
+ [PATCHSET] kernfs, cgroup: make kernfs_path*() and cgroup_path*() behave in 
strlcpy() style
  http://lkml.kernel.org/r/1470720204-4605-1-git-send-email...@kernel.org

and also available in the following git branch.

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git review-tracepoints

Thanks.

 include/trace/events/cgroup.h | 163 ++
 kernel/cgroup.c   |  25 +++
 2 files changed, 188 insertions(+)
 create mode 100644 include/trace/events/cgroup.h

diff --git a/include/trace/events/cgroup.h b/include/trace/events/cgroup.h
new file mode 100644
index 000..ab68640
--- /dev/null
+++ b/include/trace/events/cgroup.h
@@ -0,0 +1,163 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM cgroup
+
+#if !defined(_TRACE_CGROUP_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_CGROUP_H
+
+#include 
+#include 
+
+DECLARE_EVENT_CLASS(cgroup_root,
+
+   TP_PROTO(struct cgroup_root *root),
+
+   TP_ARGS(root),
+
+   TP_STRUCT__entry(
+   __field(int,root)
+   __field(u16,ss_mask )
+   __string(   name,   root->name  )
+   ),
+
+   TP_fast_assign(
+   __entry->root = root->hierarchy_id;
+   __entry->ss_mask = root->subsys_mask;
+   __assign_str(name, root->name);
+   ),
+
+   TP_printk("root=%d ss_mask=%#x name=%s",
+ __entry->root, __entry->ss_mask, __get_str(name))
+);
+
+DEFINE_EVENT(cgroup_root, cgroup_setup_root,
+
+   TP_PROTO(struct cgroup_root *root),
+
+   TP_ARGS(root)
+);
+
+DEFINE_EVENT(cgroup_root, cgroup_destroy_root,
+
+   TP_PROTO(struct cgroup_root *root),
+
+   TP_ARGS(root)
+);
+
+DEFINE_EVENT(cgroup_root, cgroup_remount,
+
+   TP_PROTO(struct cgroup_root *root),
+
+   TP_ARGS(root)
+);
+
+DECLARE_EVENT_CLASS(cgroup,
+
+   TP_PROTO(struct cgroup *cgrp),
+
+   TP_ARGS(cgrp),
+
+   TP_STRUCT__entry(
+   __field(int,root)
+   __field(int,id  )
+   __field(int,level   )
+   __dynamic_array(char,   path,
+   cgrp->kn ? cgroup_path(cgrp, NULL, 0) + 1
+: strlen("(null)"))
+   ),
+
+   TP_fast_assign(
+   __entry->root = cgrp->root->hierarchy_id;
+   __entry->id = cgrp->id;
+   __entry->level = cgrp->level;
+   if (cgrp->kn)
+   cgroup_path(cgrp, __get_dynamic_array(path),
+   __get_dynamic_array_len(path));
+   else
+   __assign_str(path, "(null)");
+   ),
+
+   TP_printk("root=%d id=%d level=%d path=%s",
+ __entry->root, __entry->id, __entry->level, __get_str(path))
+);
+
+DEFINE_EVENT(cgroup, cgroup_mkdir,
+
+   TP_PROTO(struct cgroup *cgroup),
+
+   TP_ARGS(cgroup)
+);
+
+DEFINE_EVENT(cgroup, cgroup_rmdir,
+
+   TP_PROTO(struct cgroup *cgroup),
+
+   TP_ARGS(cgroup)
+);
+
+DEFINE_EVENT(cgroup, cgroup_release,
+
+   TP_PROTO(struct cgroup *cgroup),
+
+   TP_ARGS(cgroup)
+);
+
+DEFINE_EVENT(cgroup, cgroup_rename,
+
+   TP_PROTO(struct cgroup *cgroup),
+
+   TP_ARGS(cgroup)
+);
+
+DECLARE_EVENT_CLASS(cgroup_migrate,
+
+   TP_PROTO(struct cgroup *dst_cgrp, struct task_struct *task, bool 
threadgroup),
+
+   TP_ARGS(dst_cgrp, task, threadgroup),
+
+   TP_STRUCT__entry(
+   __field(int,dst_root)
+   __field(int,dst_id  )
+   __field(int,dst_level   )
+   __dynamic_array(char,   dst_path,
+   dst_cgrp->kn ? cgroup_path(dst_cgrp, NULL, 0) + 
1
+: strlen("(null)"))
+   __field(int,pid )
+   __string(   comm,   task->comm  )
+   ),
+
+   TP_fast_assign(
+   __entry->dst_root = dst_cgrp->root->hierarchy_id;
+   __entry->dst_id = dst_cgrp->id;
+   __entry->dst_level = dst_cgrp->level;
+   if (dst_cgrp->kn)
+   

[PATCH] cgroup: add tracepoints for basic operations

[Tejun Heo]

>From 471f89b317a21a78dacaee85957984b9f11e79e4 Mon Sep 17 00:00:00 2001
From: Tejun Heo 
Date: Tue, 9 Aug 2016 01:11:13 -0400

Debugging what goes wrong with cgroup setup can get hairy.  Add
tracepoints for cgroup hierarchy mount, cgroup creation/destruction
and task migration operations for better visibility.

Signed-off-by: Tejun Heo 
---
This patchset is on top of

  v4.8-rc1 29b4817d4018df78086157ea3a55c1d9424a7cfc
+ [PATCHSET] kernfs, cgroup: make kernfs_path*() and cgroup_path*() behave in 
strlcpy() style
  http://lkml.kernel.org/r/1470720204-4605-1-git-send-email...@kernel.org

and also available in the following git branch.

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git review-tracepoints

Thanks.

 include/trace/events/cgroup.h | 163 ++
 kernel/cgroup.c   |  25 +++
 2 files changed, 188 insertions(+)
 create mode 100644 include/trace/events/cgroup.h

diff --git a/include/trace/events/cgroup.h b/include/trace/events/cgroup.h
new file mode 100644
index 000..ab68640
--- /dev/null
+++ b/include/trace/events/cgroup.h
@@ -0,0 +1,163 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM cgroup
+
+#if !defined(_TRACE_CGROUP_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_CGROUP_H
+
+#include 
+#include 
+
+DECLARE_EVENT_CLASS(cgroup_root,
+
+   TP_PROTO(struct cgroup_root *root),
+
+   TP_ARGS(root),
+
+   TP_STRUCT__entry(
+   __field(int,root)
+   __field(u16,ss_mask )
+   __string(   name,   root->name  )
+   ),
+
+   TP_fast_assign(
+   __entry->root = root->hierarchy_id;
+   __entry->ss_mask = root->subsys_mask;
+   __assign_str(name, root->name);
+   ),
+
+   TP_printk("root=%d ss_mask=%#x name=%s",
+ __entry->root, __entry->ss_mask, __get_str(name))
+);
+
+DEFINE_EVENT(cgroup_root, cgroup_setup_root,
+
+   TP_PROTO(struct cgroup_root *root),
+
+   TP_ARGS(root)
+);
+
+DEFINE_EVENT(cgroup_root, cgroup_destroy_root,
+
+   TP_PROTO(struct cgroup_root *root),
+
+   TP_ARGS(root)
+);
+
+DEFINE_EVENT(cgroup_root, cgroup_remount,
+
+   TP_PROTO(struct cgroup_root *root),
+
+   TP_ARGS(root)
+);
+
+DECLARE_EVENT_CLASS(cgroup,
+
+   TP_PROTO(struct cgroup *cgrp),
+
+   TP_ARGS(cgrp),
+
+   TP_STRUCT__entry(
+   __field(int,root)
+   __field(int,id  )
+   __field(int,level   )
+   __dynamic_array(char,   path,
+   cgrp->kn ? cgroup_path(cgrp, NULL, 0) + 1
+: strlen("(null)"))
+   ),
+
+   TP_fast_assign(
+   __entry->root = cgrp->root->hierarchy_id;
+   __entry->id = cgrp->id;
+   __entry->level = cgrp->level;
+   if (cgrp->kn)
+   cgroup_path(cgrp, __get_dynamic_array(path),
+   __get_dynamic_array_len(path));
+   else
+   __assign_str(path, "(null)");
+   ),
+
+   TP_printk("root=%d id=%d level=%d path=%s",
+ __entry->root, __entry->id, __entry->level, __get_str(path))
+);
+
+DEFINE_EVENT(cgroup, cgroup_mkdir,
+
+   TP_PROTO(struct cgroup *cgroup),
+
+   TP_ARGS(cgroup)
+);
+
+DEFINE_EVENT(cgroup, cgroup_rmdir,
+
+   TP_PROTO(struct cgroup *cgroup),
+
+   TP_ARGS(cgroup)
+);
+
+DEFINE_EVENT(cgroup, cgroup_release,
+
+   TP_PROTO(struct cgroup *cgroup),
+
+   TP_ARGS(cgroup)
+);
+
+DEFINE_EVENT(cgroup, cgroup_rename,
+
+   TP_PROTO(struct cgroup *cgroup),
+
+   TP_ARGS(cgroup)
+);
+
+DECLARE_EVENT_CLASS(cgroup_migrate,
+
+   TP_PROTO(struct cgroup *dst_cgrp, struct task_struct *task, bool 
threadgroup),
+
+   TP_ARGS(dst_cgrp, task, threadgroup),
+
+   TP_STRUCT__entry(
+   __field(int,dst_root)
+   __field(int,dst_id  )
+   __field(int,dst_level   )
+   __dynamic_array(char,   dst_path,
+   dst_cgrp->kn ? cgroup_path(dst_cgrp, NULL, 0) + 
1
+: strlen("(null)"))
+   __field(int,pid )
+   __string(   comm,   task->comm  )
+   ),
+
+   TP_fast_assign(
+   __entry->dst_root = dst_cgrp->root->hierarchy_id;
+   __entry->dst_id = dst_cgrp->id;
+   __entry->dst_level = dst_cgrp->level;
+   if (dst_cgrp->kn)
+   cgroup_path(dst_cgrp, __get_dynamic_array(dst_path),

Re: [Letux-kernel] [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput

[H. Nikolaus Schaller]

Hi Andrey,

> Am 09.08.2016 um 01:49 schrieb Andrey Utkin :
> 
> On Mon, Aug 08, 2016 at 11:26:38PM +0200, H. Nikolaus Schaller wrote:
>> Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff".
>> I hope someone knows what it means.
>> 
>> BR and thanks,
>> Nikolaus
>> 
>> root@letux:~# poweroff
>> 
>> Broadcast message from root@letux (pts/0) (Mon Aug  8 21:19:21 2016):
>> 
>> The system is going down for system halt NOW!
>> 
>> xinit: unexpected signal 15
>> [info] Using makefile-style concurrent boot in runlevel 0.
>> [] Stopping ISC DHCP server: dhcpd failed!
>> [] Stopping bluetooth: /usr/sbin/bluetoothd. ok 
>> [] Stopping automount ok 
>> [] Not running dhcpcd because /etc/network/interfaces ... failed!
>> [] defines some interfaces that will use a DHCP client ... failed!
>> [] Shutting down ALSA...done.
>> [] Asking all remaining processes to terminate...done.
>> [] All processes ended within 1 seconds...done.
>> [] Stopping enhanced syslogd: rsyslogd. ok 
>> [] Deconfiguring network interfaces...SIOCDELRT: No such process
>> Device "usb0" does not exist.
>> Cannot find device "usb0"
>> done.
>> [info] Saving the system clock.
>> [info] Hardware Clock updated to Mon Aug  8 21:19:30 UTC 2016.
>> [] Unmounting temporary filesystems...done.
>> [] Deactivating swap...done.
>> [] Unmounting local filesystems...done.
>> [  613.196751] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
>> [info] Will now halt.
>> [  615.348870] wlan0: deauthenticating from 00:12:bf:7d:ce:e6 by local 
>> choice (Reason: 3=DEAUTH_LEAVING)
>> [  615.589721] Unable to handle kernel NULL pointer dereference at virtual 
>> address 0a2a
>> [  615.598249] pgd = ec3a4000
>> [  615.601220] [0a2a] *pgd=ab60f835, *pte=, *ppte=
>> [  615.607868] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>> [  615.613551] Modules linked in: hci_uart bnep bluetooth autofs4 usb_f_ecm 
>> usb_f_rndis u_ether libcomposite configfs ipv6 cdc_ether usbnet cdc_acm arc4 
>> wl18xx wlcore mac80211 omapdrm cfg80211 drm_kms_helper cfbfillrect 
>> syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea 
>> snd_soc_omap_hdmi_audio panel_mipi_debug drm dwc3 connector_hdmi 
>> encoder_tpd12s015 w2cbw003_bluetooth snd_soc_omap_abe_twl6040 
>> snd_soc_twl6040 wwan_on_off leds_gpio omapdss pwm_omap_dmtimer pwm_bl 
>> ehci_omap wlcore_sdio dwc3_omap leds_is31fl319x snd_soc_ts3a225e 
>> gpio_twl6040 bq27xxx_battery_i2c tsc2007 bq27xxx_battery leds_tca6507 
>> crtouch_mt bq2429x_charger twl6040_vibra ina2xx palmas_pwrbutton 
>> palmas_gpadc as5013 tca8418_keypad usb3503 bma150 bmg160_i2c bno055 
>> bmg160_core input_polldev snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_omap 
>> snd_pcm_dmaengine [last unloaded: g_ether]
>> [  615.694303] CPU: 0 PID: 3788 Comm: halt Tainted: GB   W   
>> 4.8.0-rc1-letux+ #655
>> [  615.702727] Hardware name: Generic OMAP5 (Flattened Device Tree)
>> [  615.709052] task: eb2564c0 task.stack: ec456000
>> [  615.713913] PC is at wlcore_op_get_expected_throughput+0x14/0x20 [wlcore]
>> [  615.721357] LR is at sta_set_sinfo+0xc18/0x1110 [mac80211]
>> [  615.727145] pc : []lr : []psr: a00f0013
>> [  615.727145] sp : ec457c48  ip :   fp : 400f0013
>> [  615.739237] r10: ec414620  r9 : eb604b30  r8 : eb604c90
>> [  615.744735] r7 : c0b02554  r6 : bf4815c4  r5 : bf4de03c  r4 : ec823400
>> [  615.751613] r3 :   r2 :   r1 : 00c8  r0 : 03e8
>> [  615.758492] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
>> none
>> [  615.766008] Control: 10c5387d  Table: ac3a406a  DAC: 0051
>> [  615.772062] Process halt (pid: 3788, stack limit = 0xec456218)
>> [  615.778208] Stack: (0xec457c48 to 0xec458000)
>> [  615.782806] 7c40:   0001  bf40d540 c0a76630 
>> eb604f3c bf40d540
>> [  615.791434] 7c60: ec414620   eb604a8c eb604c90  
>> 0001 eb604800
>> [  615.800049] 7c80: ec823400 ec45a600 ec45a600 ec414b2c 0001 ec414b94 
>>  bf40d540
>> [  615.808682] 7ca0:  0003 ec457cb0 ec414b94 ec457cb8 bf40d75c 
>> eb604808 eb604808
>> [  615.817308] 7cc0:  ec45a600  ec414620 ec45ac50 ec457d1e 
>> 00c0 0003
>> [  615.825940] 7ce0:  bf4629e8 0001 ec457d1e ec45a600 ec457d60 
>> ec457d1e 0001
>> [  615.834563] 7d00: bf38707c bf386c94 0003 bf4680cc ec457d1e  
>> ec45a67c 00c0
>> [  615.843178] 7d20: 1200 e6ce7dbf efbeadde 1200 e6ce7dbf 0003 
>> 0001 ec892bd4
>> [  615.851801] 7d40: ec45a000 c0b02554 ec4142a0 bf38707c bf386c94 0003 
>>  bf352b58
>> [  615.860428] 7d60: ec892bd4   0003 ec45a648 ec45a608 
>> ec414000 ec414000
>> [  615.869051] 7d80: ec414000 ec45a000 0003 bf3590c0  0003 
>>  ec45a000
>> [  615.877674] 7da0: ec414000 ec45a648 ec45a608 ec414000 ec414000 0009 
>> 

Re: [Letux-kernel] [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput

[H. Nikolaus Schaller]

Hi Andrey,

> Am 09.08.2016 um 01:49 schrieb Andrey Utkin :
> 
> On Mon, Aug 08, 2016 at 11:26:38PM +0200, H. Nikolaus Schaller wrote:
>> Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff".
>> I hope someone knows what it means.
>> 
>> BR and thanks,
>> Nikolaus
>> 
>> root@letux:~# poweroff
>> 
>> Broadcast message from root@letux (pts/0) (Mon Aug  8 21:19:21 2016):
>> 
>> The system is going down for system halt NOW!
>> 
>> xinit: unexpected signal 15
>> [info] Using makefile-style concurrent boot in runlevel 0.
>> [] Stopping ISC DHCP server: dhcpd failed!
>> [] Stopping bluetooth: /usr/sbin/bluetoothd. ok 
>> [] Stopping automount ok 
>> [] Not running dhcpcd because /etc/network/interfaces ... failed!
>> [] defines some interfaces that will use a DHCP client ... failed!
>> [] Shutting down ALSA...done.
>> [] Asking all remaining processes to terminate...done.
>> [] All processes ended within 1 seconds...done.
>> [] Stopping enhanced syslogd: rsyslogd. ok 
>> [] Deconfiguring network interfaces...SIOCDELRT: No such process
>> Device "usb0" does not exist.
>> Cannot find device "usb0"
>> done.
>> [info] Saving the system clock.
>> [info] Hardware Clock updated to Mon Aug  8 21:19:30 UTC 2016.
>> [] Unmounting temporary filesystems...done.
>> [] Deactivating swap...done.
>> [] Unmounting local filesystems...done.
>> [  613.196751] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
>> [info] Will now halt.
>> [  615.348870] wlan0: deauthenticating from 00:12:bf:7d:ce:e6 by local 
>> choice (Reason: 3=DEAUTH_LEAVING)
>> [  615.589721] Unable to handle kernel NULL pointer dereference at virtual 
>> address 0a2a
>> [  615.598249] pgd = ec3a4000
>> [  615.601220] [0a2a] *pgd=ab60f835, *pte=, *ppte=
>> [  615.607868] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>> [  615.613551] Modules linked in: hci_uart bnep bluetooth autofs4 usb_f_ecm 
>> usb_f_rndis u_ether libcomposite configfs ipv6 cdc_ether usbnet cdc_acm arc4 
>> wl18xx wlcore mac80211 omapdrm cfg80211 drm_kms_helper cfbfillrect 
>> syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea 
>> snd_soc_omap_hdmi_audio panel_mipi_debug drm dwc3 connector_hdmi 
>> encoder_tpd12s015 w2cbw003_bluetooth snd_soc_omap_abe_twl6040 
>> snd_soc_twl6040 wwan_on_off leds_gpio omapdss pwm_omap_dmtimer pwm_bl 
>> ehci_omap wlcore_sdio dwc3_omap leds_is31fl319x snd_soc_ts3a225e 
>> gpio_twl6040 bq27xxx_battery_i2c tsc2007 bq27xxx_battery leds_tca6507 
>> crtouch_mt bq2429x_charger twl6040_vibra ina2xx palmas_pwrbutton 
>> palmas_gpadc as5013 tca8418_keypad usb3503 bma150 bmg160_i2c bno055 
>> bmg160_core input_polldev snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_omap 
>> snd_pcm_dmaengine [last unloaded: g_ether]
>> [  615.694303] CPU: 0 PID: 3788 Comm: halt Tainted: GB   W   
>> 4.8.0-rc1-letux+ #655
>> [  615.702727] Hardware name: Generic OMAP5 (Flattened Device Tree)
>> [  615.709052] task: eb2564c0 task.stack: ec456000
>> [  615.713913] PC is at wlcore_op_get_expected_throughput+0x14/0x20 [wlcore]
>> [  615.721357] LR is at sta_set_sinfo+0xc18/0x1110 [mac80211]
>> [  615.727145] pc : []lr : []psr: a00f0013
>> [  615.727145] sp : ec457c48  ip :   fp : 400f0013
>> [  615.739237] r10: ec414620  r9 : eb604b30  r8 : eb604c90
>> [  615.744735] r7 : c0b02554  r6 : bf4815c4  r5 : bf4de03c  r4 : ec823400
>> [  615.751613] r3 :   r2 :   r1 : 00c8  r0 : 03e8
>> [  615.758492] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
>> none
>> [  615.766008] Control: 10c5387d  Table: ac3a406a  DAC: 0051
>> [  615.772062] Process halt (pid: 3788, stack limit = 0xec456218)
>> [  615.778208] Stack: (0xec457c48 to 0xec458000)
>> [  615.782806] 7c40:   0001  bf40d540 c0a76630 
>> eb604f3c bf40d540
>> [  615.791434] 7c60: ec414620   eb604a8c eb604c90  
>> 0001 eb604800
>> [  615.800049] 7c80: ec823400 ec45a600 ec45a600 ec414b2c 0001 ec414b94 
>>  bf40d540
>> [  615.808682] 7ca0:  0003 ec457cb0 ec414b94 ec457cb8 bf40d75c 
>> eb604808 eb604808
>> [  615.817308] 7cc0:  ec45a600  ec414620 ec45ac50 ec457d1e 
>> 00c0 0003
>> [  615.825940] 7ce0:  bf4629e8 0001 ec457d1e ec45a600 ec457d60 
>> ec457d1e 0001
>> [  615.834563] 7d00: bf38707c bf386c94 0003 bf4680cc ec457d1e  
>> ec45a67c 00c0
>> [  615.843178] 7d20: 1200 e6ce7dbf efbeadde 1200 e6ce7dbf 0003 
>> 0001 ec892bd4
>> [  615.851801] 7d40: ec45a000 c0b02554 ec4142a0 bf38707c bf386c94 0003 
>>  bf352b58
>> [  615.860428] 7d60: ec892bd4   0003 ec45a648 ec45a608 
>> ec414000 ec414000
>> [  615.869051] 7d80: ec414000 ec45a000 0003 bf3590c0  0003 
>>  ec45a000
>> [  615.877674] 7da0: ec414000 ec45a648 ec45a608 ec414000 ec414000 0009 
>> ec96cc0c 
>> [  

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

I thought I should dequeue this, some of these could have made -rc1 if I'd 
had less illness. This contains a bunch of amdgpu fixes, and some i915
regression fixes.

It also contains some fixes for an older regression with some EDID 
changes and some 6bpc panels.

Then there are the lockdep, cirrus and rcar-du regression fixes from this 
window.

Dave.

The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-4.8-rc2

for you to fetch changes up to 36e9d08b58f44c3a02974c405ccaaa6ecfaf05b8:

  drm/cirrus: Fix NULL pointer dereference when registering the fbdev 
(2016-08-09 13:01:47 +1000)


Alex Deucher (2):
  drm/amdgpu/gmc7: add missing mullins case
  drm/amdgpu/ci: add mullins to default case for smc ucode

Boris Brezillon (1):
  drm/cirrus: Fix NULL pointer dereference when registering the fbdev

Chris Wilson (1):
  drm/i915/fbdev: Check for the framebuffer before use

Daniel Vetter (1):
  drm: Paper over locking inversion after registration rework

Dave Airlie (2):
  Merge tag 'drm-intel-next-fixes-2016-08-05' of 
git://anongit.freedesktop.org/drm-intel into drm-next
  Merge branch 'drm-next-4.8' of git://people.freedesktop.org/~agd5f/linux 
into drm-next

Eric Huang (1):
  drm/amd/amdgpu: change pptable output format from ASCII to binary

Huang Rui (5):
  drm/amdgpu: update golden setting of iceland
  drm/amdgpu: update golden setting of carrizo
  drm/amdgpu: update golden setting of polaris11
  drm/amdgpu: update golden setting of stoney
  drm/amdgpu: update golden setting of polaris10

Laurent Pinchart (1):
  drm: rcar-du: Link HDMI encoder with bridge

Mario Kleiner (3):
  drm/edid: Add 6 bpc quirk for display AEO model 0.
  drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink 
capability is unknown"
  drm/edid: Set 8 bpc color depth for displays with "DFP 1.x compliant 
TMDS".

Michel Dänzer (1):
  drm/ttm: Wait for a BO to become idle before unbinding it from GTT

Ville Syrjälä (2):
  drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on 
SKL
  drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB

 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c|  7 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |  4 ++--
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 12 
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c |  1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c |  8 
 drivers/gpu/drm/cirrus/cirrus_main.c  | 13 +++--
 drivers/gpu/drm/drm_crtc.c|  8 +++-
 drivers/gpu/drm/drm_edid.c| 22 ++
 drivers/gpu/drm/i915/intel_display.c  | 30 ++
 drivers/gpu/drm/i915/intel_fbdev.c| 25 +++--
 drivers/gpu/drm/i915/intel_pm.c   |  3 ++-
 drivers/gpu/drm/nouveau/nouveau_bo.c  |  4 ++--
 drivers/gpu/drm/radeon/radeon_ttm.c   |  4 ++--
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c |  1 +
 drivers/gpu/drm/ttm/ttm_bo.c  |  3 ++-
 drivers/gpu/drm/ttm/ttm_bo_util.c | 10 +-
 include/drm/ttm/ttm_bo_driver.h   |  3 ++-
 18 files changed, 95 insertions(+), 64 deletions(-)

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

I thought I should dequeue this, some of these could have made -rc1 if I'd 
had less illness. This contains a bunch of amdgpu fixes, and some i915
regression fixes.

It also contains some fixes for an older regression with some EDID 
changes and some 6bpc panels.

Then there are the lockdep, cirrus and rcar-du regression fixes from this 
window.

Dave.

The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-4.8-rc2

for you to fetch changes up to 36e9d08b58f44c3a02974c405ccaaa6ecfaf05b8:

  drm/cirrus: Fix NULL pointer dereference when registering the fbdev 
(2016-08-09 13:01:47 +1000)


Alex Deucher (2):
  drm/amdgpu/gmc7: add missing mullins case
  drm/amdgpu/ci: add mullins to default case for smc ucode

Boris Brezillon (1):
  drm/cirrus: Fix NULL pointer dereference when registering the fbdev

Chris Wilson (1):
  drm/i915/fbdev: Check for the framebuffer before use

Daniel Vetter (1):
  drm: Paper over locking inversion after registration rework

Dave Airlie (2):
  Merge tag 'drm-intel-next-fixes-2016-08-05' of 
git://anongit.freedesktop.org/drm-intel into drm-next
  Merge branch 'drm-next-4.8' of git://people.freedesktop.org/~agd5f/linux 
into drm-next

Eric Huang (1):
  drm/amd/amdgpu: change pptable output format from ASCII to binary

Huang Rui (5):
  drm/amdgpu: update golden setting of iceland
  drm/amdgpu: update golden setting of carrizo
  drm/amdgpu: update golden setting of polaris11
  drm/amdgpu: update golden setting of stoney
  drm/amdgpu: update golden setting of polaris10

Laurent Pinchart (1):
  drm: rcar-du: Link HDMI encoder with bridge

Mario Kleiner (3):
  drm/edid: Add 6 bpc quirk for display AEO model 0.
  drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink 
capability is unknown"
  drm/edid: Set 8 bpc color depth for displays with "DFP 1.x compliant 
TMDS".

Michel Dänzer (1):
  drm/ttm: Wait for a BO to become idle before unbinding it from GTT

Ville Syrjälä (2):
  drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on 
SKL
  drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB

 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c|  7 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |  4 ++--
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 12 
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c |  1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c |  8 
 drivers/gpu/drm/cirrus/cirrus_main.c  | 13 +++--
 drivers/gpu/drm/drm_crtc.c|  8 +++-
 drivers/gpu/drm/drm_edid.c| 22 ++
 drivers/gpu/drm/i915/intel_display.c  | 30 ++
 drivers/gpu/drm/i915/intel_fbdev.c| 25 +++--
 drivers/gpu/drm/i915/intel_pm.c   |  3 ++-
 drivers/gpu/drm/nouveau/nouveau_bo.c  |  4 ++--
 drivers/gpu/drm/radeon/radeon_ttm.c   |  4 ++--
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c |  1 +
 drivers/gpu/drm/ttm/ttm_bo.c  |  3 ++-
 drivers/gpu/drm/ttm/ttm_bo_util.c | 10 +-
 include/drm/ttm/ttm_bo_driver.h   |  3 ++-
 18 files changed, 95 insertions(+), 64 deletions(-)

[PATCH 1/4] kernfs: add dummy implementation of kernfs_path_from_node()

[Tejun Heo]

The dummy version of kernfs_path_from_node() was missing.  This
currently doesn't break anything.  Let's add it for consistency and to
ease adding wrappers around it.

Signed-off-by: Tejun Heo 
Cc: Greg Kroah-Hartman 
---
 include/linux/kernfs.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
index 96356ef..325954f 100644
--- a/include/linux/kernfs.h
+++ b/include/linux/kernfs.h
@@ -344,6 +344,11 @@ static inline int kernfs_name(struct kernfs_node *kn, char 
*buf, size_t buflen)
 static inline size_t kernfs_path_len(struct kernfs_node *kn)
 { return 0; }
 
+static inline int kernfs_path_from_node(struct kernfs_node *root_kn,
+   struct kernfs_node *kn,
+   char *buf, size_t buflen);
+{ return -ENOSYS; }
+
 static inline char *kernfs_path(struct kernfs_node *kn, char *buf,
size_t buflen)
 { return NULL; }
-- 
2.7.4

[PATCH 4/4] cgroup: make cgroup_path() and friends behave in the style of strlcpy()

[Tejun Heo]

cgroup_path() and friends used to format the path from the end and
thus the resulting path usually didn't start at the start of the
passed in buffer.  Also, when the buffer was too small, the partial
result was truncated from the head rather than tail and there was no
way to tell how long the full path would be.  These make the functions
less robust and more awkward to use.

With recent updates to kernfs_path(), cgroup_path() and friends can be
made to behave in strlcpy() style.

* cgroup_path(), cgroup_path_ns[_locked]() and task_cgroup_path() now
  always return the length of the full path.  If buffer is too small,
  it contains nul terminated truncated output.

* All users updated accordingly.

Signed-off-by: Tejun Heo 
Cc: Serge Hallyn 
Cc: Greg Kroah-Hartman 
---
 include/linux/blk-cgroup.h | 11 +--
 include/linux/cgroup.h | 16 +---
 kernel/cgroup.c| 48 +-
 kernel/cpuset.c| 12 ++--
 4 files changed, 34 insertions(+), 53 deletions(-)

diff --git a/include/linux/blk-cgroup.h b/include/linux/blk-cgroup.h
index 10648e3..4e8c215 100644
--- a/include/linux/blk-cgroup.h
+++ b/include/linux/blk-cgroup.h
@@ -343,16 +343,7 @@ static inline struct blkcg *cpd_to_blkcg(struct 
blkcg_policy_data *cpd)
  */
 static inline int blkg_path(struct blkcg_gq *blkg, char *buf, int buflen)
 {
-   char *p;
-
-   p = cgroup_path(blkg->blkcg->css.cgroup, buf, buflen);
-   if (!p) {
-   strncpy(buf, "", buflen);
-   return -ENAMETOOLONG;
-   }
-
-   memmove(buf, p, buf + buflen - p);
-   return 0;
+   return cgroup_path(blkg->blkcg->css.cgroup, buf, buflen);
 }
 
 /**
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 5a9abde..6df3636 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -97,7 +97,7 @@ int cgroup_add_legacy_cftypes(struct cgroup_subsys *ss, 
struct cftype *cfts);
 int cgroup_rm_cftypes(struct cftype *cfts);
 void cgroup_file_notify(struct cgroup_file *cfile);
 
-char *task_cgroup_path(struct task_struct *task, char *buf, size_t buflen);
+int task_cgroup_path(struct task_struct *task, char *buf, size_t buflen);
 int cgroupstats_build(struct cgroupstats *stats, struct dentry *dentry);
 int proc_cgroup_show(struct seq_file *m, struct pid_namespace *ns,
 struct pid *pid, struct task_struct *tsk);
@@ -538,15 +538,9 @@ static inline int cgroup_name(struct cgroup *cgrp, char 
*buf, size_t buflen)
return kernfs_name(cgrp->kn, buf, buflen);
 }
 
-static inline char * __must_check cgroup_path(struct cgroup *cgrp, char *buf,
- size_t buflen)
+static inline int cgroup_path(struct cgroup *cgrp, char *buf, size_t buflen)
 {
-   int ret;
-
-   ret = kernfs_path(cgrp->kn, buf, buflen);
-   if (ret < 0 || ret >= buflen)
-   return NULL;
-   return buf;
+   return kernfs_path(cgrp->kn, buf, buflen);
 }
 
 static inline void pr_cont_cgroup_name(struct cgroup *cgrp)
@@ -639,8 +633,8 @@ struct cgroup_namespace *copy_cgroup_ns(unsigned long flags,
struct user_namespace *user_ns,
struct cgroup_namespace *old_ns);
 
-char *cgroup_path_ns(struct cgroup *cgrp, char *buf, size_t buflen,
-struct cgroup_namespace *ns);
+int cgroup_path_ns(struct cgroup *cgrp, char *buf, size_t buflen,
+  struct cgroup_namespace *ns);
 
 #else /* !CONFIG_CGROUPS */
 
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index d1c51b7..3861161 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2315,22 +2315,18 @@ static struct file_system_type cgroup2_fs_type = {
.fs_flags = FS_USERNS_MOUNT,
 };
 
-static char *cgroup_path_ns_locked(struct cgroup *cgrp, char *buf, size_t 
buflen,
-  struct cgroup_namespace *ns)
+static int cgroup_path_ns_locked(struct cgroup *cgrp, char *buf, size_t buflen,
+struct cgroup_namespace *ns)
 {
struct cgroup *root = cset_cgroup_from_root(ns->root_cset, cgrp->root);
-   int ret;
 
-   ret = kernfs_path_from_node(cgrp->kn, root->kn, buf, buflen);
-   if (ret < 0 || ret >= buflen)
-   return NULL;
-   return buf;
+   return kernfs_path_from_node(cgrp->kn, root->kn, buf, buflen);
 }
 
-char *cgroup_path_ns(struct cgroup *cgrp, char *buf, size_t buflen,
-struct cgroup_namespace *ns)
+int cgroup_path_ns(struct cgroup *cgrp, char *buf, size_t buflen,
+  struct cgroup_namespace *ns)
 {
-   char *ret;
+   int ret;
 
mutex_lock(_mutex);
spin_lock_irq(_set_lock);
@@ -2357,12 +2353,12 @@ EXPORT_SYMBOL_GPL(cgroup_path_ns);
  *
  * Return value is the same as kernfs_path().
  */
-char *task_cgroup_path(struct 

[PATCH 1/4] kernfs: add dummy implementation of kernfs_path_from_node()

[Tejun Heo]

The dummy version of kernfs_path_from_node() was missing.  This
currently doesn't break anything.  Let's add it for consistency and to
ease adding wrappers around it.

Signed-off-by: Tejun Heo 
Cc: Greg Kroah-Hartman 
---
 include/linux/kernfs.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
index 96356ef..325954f 100644
--- a/include/linux/kernfs.h
+++ b/include/linux/kernfs.h
@@ -344,6 +344,11 @@ static inline int kernfs_name(struct kernfs_node *kn, char 
*buf, size_t buflen)
 static inline size_t kernfs_path_len(struct kernfs_node *kn)
 { return 0; }
 
+static inline int kernfs_path_from_node(struct kernfs_node *root_kn,
+   struct kernfs_node *kn,
+   char *buf, size_t buflen);
+{ return -ENOSYS; }
+
 static inline char *kernfs_path(struct kernfs_node *kn, char *buf,
size_t buflen)
 { return NULL; }
-- 
2.7.4

[PATCH 4/4] cgroup: make cgroup_path() and friends behave in the style of strlcpy()

[Tejun Heo]

cgroup_path() and friends used to format the path from the end and
thus the resulting path usually didn't start at the start of the
passed in buffer.  Also, when the buffer was too small, the partial
result was truncated from the head rather than tail and there was no
way to tell how long the full path would be.  These make the functions
less robust and more awkward to use.

With recent updates to kernfs_path(), cgroup_path() and friends can be
made to behave in strlcpy() style.

* cgroup_path(), cgroup_path_ns[_locked]() and task_cgroup_path() now
  always return the length of the full path.  If buffer is too small,
  it contains nul terminated truncated output.

* All users updated accordingly.

Signed-off-by: Tejun Heo 
Cc: Serge Hallyn 
Cc: Greg Kroah-Hartman 
---
 include/linux/blk-cgroup.h | 11 +--
 include/linux/cgroup.h | 16 +---
 kernel/cgroup.c| 48 +-
 kernel/cpuset.c| 12 ++--
 4 files changed, 34 insertions(+), 53 deletions(-)

diff --git a/include/linux/blk-cgroup.h b/include/linux/blk-cgroup.h
index 10648e3..4e8c215 100644
--- a/include/linux/blk-cgroup.h
+++ b/include/linux/blk-cgroup.h
@@ -343,16 +343,7 @@ static inline struct blkcg *cpd_to_blkcg(struct 
blkcg_policy_data *cpd)
  */
 static inline int blkg_path(struct blkcg_gq *blkg, char *buf, int buflen)
 {
-   char *p;
-
-   p = cgroup_path(blkg->blkcg->css.cgroup, buf, buflen);
-   if (!p) {
-   strncpy(buf, "", buflen);
-   return -ENAMETOOLONG;
-   }
-
-   memmove(buf, p, buf + buflen - p);
-   return 0;
+   return cgroup_path(blkg->blkcg->css.cgroup, buf, buflen);
 }
 
 /**
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 5a9abde..6df3636 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -97,7 +97,7 @@ int cgroup_add_legacy_cftypes(struct cgroup_subsys *ss, 
struct cftype *cfts);
 int cgroup_rm_cftypes(struct cftype *cfts);
 void cgroup_file_notify(struct cgroup_file *cfile);
 
-char *task_cgroup_path(struct task_struct *task, char *buf, size_t buflen);
+int task_cgroup_path(struct task_struct *task, char *buf, size_t buflen);
 int cgroupstats_build(struct cgroupstats *stats, struct dentry *dentry);
 int proc_cgroup_show(struct seq_file *m, struct pid_namespace *ns,
 struct pid *pid, struct task_struct *tsk);
@@ -538,15 +538,9 @@ static inline int cgroup_name(struct cgroup *cgrp, char 
*buf, size_t buflen)
return kernfs_name(cgrp->kn, buf, buflen);
 }
 
-static inline char * __must_check cgroup_path(struct cgroup *cgrp, char *buf,
- size_t buflen)
+static inline int cgroup_path(struct cgroup *cgrp, char *buf, size_t buflen)
 {
-   int ret;
-
-   ret = kernfs_path(cgrp->kn, buf, buflen);
-   if (ret < 0 || ret >= buflen)
-   return NULL;
-   return buf;
+   return kernfs_path(cgrp->kn, buf, buflen);
 }
 
 static inline void pr_cont_cgroup_name(struct cgroup *cgrp)
@@ -639,8 +633,8 @@ struct cgroup_namespace *copy_cgroup_ns(unsigned long flags,
struct user_namespace *user_ns,
struct cgroup_namespace *old_ns);
 
-char *cgroup_path_ns(struct cgroup *cgrp, char *buf, size_t buflen,
-struct cgroup_namespace *ns);
+int cgroup_path_ns(struct cgroup *cgrp, char *buf, size_t buflen,
+  struct cgroup_namespace *ns);
 
 #else /* !CONFIG_CGROUPS */
 
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index d1c51b7..3861161 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2315,22 +2315,18 @@ static struct file_system_type cgroup2_fs_type = {
.fs_flags = FS_USERNS_MOUNT,
 };
 
-static char *cgroup_path_ns_locked(struct cgroup *cgrp, char *buf, size_t 
buflen,
-  struct cgroup_namespace *ns)
+static int cgroup_path_ns_locked(struct cgroup *cgrp, char *buf, size_t buflen,
+struct cgroup_namespace *ns)
 {
struct cgroup *root = cset_cgroup_from_root(ns->root_cset, cgrp->root);
-   int ret;
 
-   ret = kernfs_path_from_node(cgrp->kn, root->kn, buf, buflen);
-   if (ret < 0 || ret >= buflen)
-   return NULL;
-   return buf;
+   return kernfs_path_from_node(cgrp->kn, root->kn, buf, buflen);
 }
 
-char *cgroup_path_ns(struct cgroup *cgrp, char *buf, size_t buflen,
-struct cgroup_namespace *ns)
+int cgroup_path_ns(struct cgroup *cgrp, char *buf, size_t buflen,
+  struct cgroup_namespace *ns)
 {
-   char *ret;
+   int ret;
 
mutex_lock(_mutex);
spin_lock_irq(_set_lock);
@@ -2357,12 +2353,12 @@ EXPORT_SYMBOL_GPL(cgroup_path_ns);
  *
  * Return value is the same as kernfs_path().
  */
-char *task_cgroup_path(struct task_struct *task, char *buf, size_t buflen)
+int task_cgroup_path(struct 

[PATCH 2/4] kernfs: make kernfs_path*() behave in the style of strlcpy()

[Tejun Heo]

kernfs_path*() functions always return the length of the full path but
the path content is undefined if the length is larger than the
provided buffer.  This makes its behavior different from strlcpy() and
requires error handling in all its users even when they don't care
about truncation.  In addition, the implementation can actully be
simplified by making it behave properly in strlcpy() style.

* Update kernfs_path_from_node_locked() to always fill up the buffer
  with path.  If the buffer is not large enough, the output is
  truncated and terminated.

* kernfs_path() no longer needs error handling.  Make it a simple
  inline wrapper around kernfs_path_from_node().

* sysfs_warn_dup()'s use of kernfs_path() doesn't need error handling.
  Updated accordingly.

* cgroup_path()'s use of kernfs_path() updated to retain the old
  behavior.

Signed-off-by: Tejun Heo 
Cc: Serge Hallyn 
Cc: Greg Kroah-Hartman 
---
 fs/kernfs/dir.c| 61 ++
 fs/sysfs/dir.c |  6 ++---
 include/linux/cgroup.h |  7 +-
 include/linux/kernfs.h | 21 -
 4 files changed, 42 insertions(+), 53 deletions(-)

diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index e57174d..09242aa 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -110,8 +110,9 @@ static struct kernfs_node *kernfs_common_ancestor(struct 
kernfs_node *a,
  * kn_to:   /n1/n2/n3 [depth=3]
  * result:  /../..
  *
- * return value: length of the string.  If greater than buflen,
- * then contents of buf are undefined.  On error, -1 is returned.
+ * Returns the length of the full path.  If the full length is equal to or
+ * greater than @buflen, @buf contains the truncated path with the trailing
+ * '\0'.  On error, -errno is returned.
  */
 static int kernfs_path_from_node_locked(struct kernfs_node *kn_to,
struct kernfs_node *kn_from,
@@ -119,9 +120,8 @@ static int kernfs_path_from_node_locked(struct kernfs_node 
*kn_to,
 {
struct kernfs_node *kn, *common;
const char parent_str[] = "/..";
-   size_t depth_from, depth_to, len = 0, nlen = 0;
-   char *p;
-   int i;
+   size_t depth_from, depth_to, len = 0;
+   int i, j;
 
if (!kn_from)
kn_from = kernfs_root(kn_to)->kn;
@@ -131,7 +131,7 @@ static int kernfs_path_from_node_locked(struct kernfs_node 
*kn_to,
 
common = kernfs_common_ancestor(kn_from, kn_to);
if (WARN_ON(!common))
-   return -1;
+   return -EINVAL;
 
depth_to = kernfs_depth(common, kn_to);
depth_from = kernfs_depth(common, kn_from);
@@ -144,22 +144,16 @@ static int kernfs_path_from_node_locked(struct 
kernfs_node *kn_to,
   len < buflen ? buflen - len : 0);
 
/* Calculate how many bytes we need for the rest */
-   for (kn = kn_to; kn != common; kn = kn->parent)
-   nlen += strlen(kn->name) + 1;
-
-   if (len + nlen >= buflen)
-   return len + nlen;
-
-   p = buf + len + nlen;
-   *p = '\0';
-   for (kn = kn_to; kn != common; kn = kn->parent) {
-   size_t tmp = strlen(kn->name);
-   p -= tmp;
-   memcpy(p, kn->name, tmp);
-   *(--p) = '/';
+   for (i = depth_to - 1; i >= 0; i--) {
+   for (kn = kn_to, j = 0; j < i; j++)
+   kn = kn->parent;
+   len += strlcpy(buf + len, "/",
+  len < buflen ? buflen - len : 0);
+   len += strlcpy(buf + len, kn->name,
+  len < buflen ? buflen - len : 0);
}
 
-   return len + nlen;
+   return len;
 }
 
 /**
@@ -220,8 +214,9 @@ size_t kernfs_path_len(struct kernfs_node *kn)
  * path (which includes '..'s) as needed to reach from @from to @to is
  * returned.
  *
- * If @buf isn't long enough, the return value will be greater than @buflen
- * and @buf contents are undefined.
+ * Returns the length of the full path.  If the full length is equal to or
+ * greater than @buflen, @buf contains the truncated path with the trailing
+ * '\0'.  On error, -errno is returned.
  */
 int kernfs_path_from_node(struct kernfs_node *to, struct kernfs_node *from,
  char *buf, size_t buflen)
@@ -237,28 +232,6 @@ int kernfs_path_from_node(struct kernfs_node *to, struct 
kernfs_node *from,
 EXPORT_SYMBOL_GPL(kernfs_path_from_node);
 
 /**
- * kernfs_path - build full path of a given node
- * @kn: kernfs_node of interest
- * @buf: buffer to copy @kn's name into
- * @buflen: size of @buf
- *
- * Builds and returns the full path of @kn in @buf of @buflen bytes.  The
- * path is built from the end of @buf so the returned pointer usually
- * doesn't match @buf.  If @buf isn't long enough, @buf is nul terminated
- * and %NULL is returned.
- */
-char *kernfs_path(struct 

[PATCH 3/4] kernfs: remove kernfs_path_len()

[Tejun Heo]

It doesn't have any in-kernel user and the same result can be obtained
from kernfs_path(@kn, NULL, 0).  Remove it.

Signed-off-by: Tejun Heo 
Cc: Serge Hallyn 
Cc: Greg Kroah-Hartman 
---
 fs/kernfs/dir.c| 23 ---
 include/linux/kernfs.h |  4 
 2 files changed, 27 deletions(-)

diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index 09242aa..6e7fd37 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -180,29 +180,6 @@ int kernfs_name(struct kernfs_node *kn, char *buf, size_t 
buflen)
 }
 
 /**
- * kernfs_path_len - determine the length of the full path of a given node
- * @kn: kernfs_node of interest
- *
- * The returned length doesn't include the space for the terminating '\0'.
- */
-size_t kernfs_path_len(struct kernfs_node *kn)
-{
-   size_t len = 0;
-   unsigned long flags;
-
-   spin_lock_irqsave(_rename_lock, flags);
-
-   do {
-   len += strlen(kn->name) + 1;
-   kn = kn->parent;
-   } while (kn && kn->parent);
-
-   spin_unlock_irqrestore(_rename_lock, flags);
-
-   return len;
-}
-
-/**
  * kernfs_path_from_node - build path of node @to relative to @from.
  * @from: parent kernfs_node relative to which we need to build the path
  * @to: kernfs_node of interest
diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
index 64358d2..a410c75 100644
--- a/include/linux/kernfs.h
+++ b/include/linux/kernfs.h
@@ -269,7 +269,6 @@ static inline bool kernfs_ns_enabled(struct kernfs_node *kn)
 }
 
 int kernfs_name(struct kernfs_node *kn, char *buf, size_t buflen);
-size_t kernfs_path_len(struct kernfs_node *kn);
 int kernfs_path_from_node(struct kernfs_node *root_kn, struct kernfs_node *kn,
  char *buf, size_t buflen);
 void pr_cont_kernfs_name(struct kernfs_node *kn);
@@ -340,9 +339,6 @@ static inline bool kernfs_ns_enabled(struct kernfs_node *kn)
 static inline int kernfs_name(struct kernfs_node *kn, char *buf, size_t buflen)
 { return -ENOSYS; }
 
-static inline size_t kernfs_path_len(struct kernfs_node *kn)
-{ return 0; }
-
 static inline int kernfs_path_from_node(struct kernfs_node *root_kn,
struct kernfs_node *kn,
char *buf, size_t buflen);
-- 
2.7.4

[PATCHSET] kernfs, cgroup: make kernfs_path*() and cgroup_path*() behave in strlcpy() style

[Tejun Heo]

kernfs path formatting functions always return the length of full path
but the content of the output buffer is undefined when the length is
longer than the provided buffer.  Most cgroup path formatting
functions return the start of the output or NULL on errors including
overflow.  These inconsistent and rather peculiar behaviors developed
over time and make these functions unnecessarily difficult to use.
This patchset updates the formatting functions so that they all behave
in the style of strlcpy().

Greg, these changes are used by cgroup tracepoint additions and
shouldn't affect other users much.  Would it be okay to route these
through the cgroup tree?

 0001-kernfs-add-dummy-implementation-of-kernfs_path_from_.patch
 0002-kernfs-make-kernfs_path-behave-in-the-style-of-strlc.patch
 0003-kernfs-remove-kernfs_path_len.patch
 0004-cgroup-make-cgroup_path-and-friends-behave-in-the-st.patch

The patches are also available in the following git branch.

 git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git 
review-kernfs_path-strlcpy

diffstat follows.  Thanks.

 fs/kernfs/dir.c|   84 +
 fs/sysfs/dir.c |6 +--
 include/linux/blk-cgroup.h |   11 -
 include/linux/cgroup.h |9 ++--
 include/linux/kernfs.h |   28 ++-
 kernel/cgroup.c|   48 +++--
 kernel/cpuset.c|   12 +++---
 7 files changed, 73 insertions(+), 125 deletions(-)

--
tejun

[PATCH 2/4] kernfs: make kernfs_path*() behave in the style of strlcpy()

[Tejun Heo]

kernfs_path*() functions always return the length of the full path but
the path content is undefined if the length is larger than the
provided buffer.  This makes its behavior different from strlcpy() and
requires error handling in all its users even when they don't care
about truncation.  In addition, the implementation can actully be
simplified by making it behave properly in strlcpy() style.

* Update kernfs_path_from_node_locked() to always fill up the buffer
  with path.  If the buffer is not large enough, the output is
  truncated and terminated.

* kernfs_path() no longer needs error handling.  Make it a simple
  inline wrapper around kernfs_path_from_node().

* sysfs_warn_dup()'s use of kernfs_path() doesn't need error handling.
  Updated accordingly.

* cgroup_path()'s use of kernfs_path() updated to retain the old
  behavior.

Signed-off-by: Tejun Heo 
Cc: Serge Hallyn 
Cc: Greg Kroah-Hartman 
---
 fs/kernfs/dir.c| 61 ++
 fs/sysfs/dir.c |  6 ++---
 include/linux/cgroup.h |  7 +-
 include/linux/kernfs.h | 21 -
 4 files changed, 42 insertions(+), 53 deletions(-)

diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index e57174d..09242aa 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -110,8 +110,9 @@ static struct kernfs_node *kernfs_common_ancestor(struct 
kernfs_node *a,
  * kn_to:   /n1/n2/n3 [depth=3]
  * result:  /../..
  *
- * return value: length of the string.  If greater than buflen,
- * then contents of buf are undefined.  On error, -1 is returned.
+ * Returns the length of the full path.  If the full length is equal to or
+ * greater than @buflen, @buf contains the truncated path with the trailing
+ * '\0'.  On error, -errno is returned.
  */
 static int kernfs_path_from_node_locked(struct kernfs_node *kn_to,
struct kernfs_node *kn_from,
@@ -119,9 +120,8 @@ static int kernfs_path_from_node_locked(struct kernfs_node 
*kn_to,
 {
struct kernfs_node *kn, *common;
const char parent_str[] = "/..";
-   size_t depth_from, depth_to, len = 0, nlen = 0;
-   char *p;
-   int i;
+   size_t depth_from, depth_to, len = 0;
+   int i, j;
 
if (!kn_from)
kn_from = kernfs_root(kn_to)->kn;
@@ -131,7 +131,7 @@ static int kernfs_path_from_node_locked(struct kernfs_node 
*kn_to,
 
common = kernfs_common_ancestor(kn_from, kn_to);
if (WARN_ON(!common))
-   return -1;
+   return -EINVAL;
 
depth_to = kernfs_depth(common, kn_to);
depth_from = kernfs_depth(common, kn_from);
@@ -144,22 +144,16 @@ static int kernfs_path_from_node_locked(struct 
kernfs_node *kn_to,
   len < buflen ? buflen - len : 0);
 
/* Calculate how many bytes we need for the rest */
-   for (kn = kn_to; kn != common; kn = kn->parent)
-   nlen += strlen(kn->name) + 1;
-
-   if (len + nlen >= buflen)
-   return len + nlen;
-
-   p = buf + len + nlen;
-   *p = '\0';
-   for (kn = kn_to; kn != common; kn = kn->parent) {
-   size_t tmp = strlen(kn->name);
-   p -= tmp;
-   memcpy(p, kn->name, tmp);
-   *(--p) = '/';
+   for (i = depth_to - 1; i >= 0; i--) {
+   for (kn = kn_to, j = 0; j < i; j++)
+   kn = kn->parent;
+   len += strlcpy(buf + len, "/",
+  len < buflen ? buflen - len : 0);
+   len += strlcpy(buf + len, kn->name,
+  len < buflen ? buflen - len : 0);
}
 
-   return len + nlen;
+   return len;
 }
 
 /**
@@ -220,8 +214,9 @@ size_t kernfs_path_len(struct kernfs_node *kn)
  * path (which includes '..'s) as needed to reach from @from to @to is
  * returned.
  *
- * If @buf isn't long enough, the return value will be greater than @buflen
- * and @buf contents are undefined.
+ * Returns the length of the full path.  If the full length is equal to or
+ * greater than @buflen, @buf contains the truncated path with the trailing
+ * '\0'.  On error, -errno is returned.
  */
 int kernfs_path_from_node(struct kernfs_node *to, struct kernfs_node *from,
  char *buf, size_t buflen)
@@ -237,28 +232,6 @@ int kernfs_path_from_node(struct kernfs_node *to, struct 
kernfs_node *from,
 EXPORT_SYMBOL_GPL(kernfs_path_from_node);
 
 /**
- * kernfs_path - build full path of a given node
- * @kn: kernfs_node of interest
- * @buf: buffer to copy @kn's name into
- * @buflen: size of @buf
- *
- * Builds and returns the full path of @kn in @buf of @buflen bytes.  The
- * path is built from the end of @buf so the returned pointer usually
- * doesn't match @buf.  If @buf isn't long enough, @buf is nul terminated
- * and %NULL is returned.
- */
-char *kernfs_path(struct kernfs_node *kn, char *buf, size_t buflen)
-{
-   int ret;
-
-   ret = 

[PATCH 3/4] kernfs: remove kernfs_path_len()

[Tejun Heo]

It doesn't have any in-kernel user and the same result can be obtained
from kernfs_path(@kn, NULL, 0).  Remove it.

Signed-off-by: Tejun Heo 
Cc: Serge Hallyn 
Cc: Greg Kroah-Hartman 
---
 fs/kernfs/dir.c| 23 ---
 include/linux/kernfs.h |  4 
 2 files changed, 27 deletions(-)

diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index 09242aa..6e7fd37 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -180,29 +180,6 @@ int kernfs_name(struct kernfs_node *kn, char *buf, size_t 
buflen)
 }
 
 /**
- * kernfs_path_len - determine the length of the full path of a given node
- * @kn: kernfs_node of interest
- *
- * The returned length doesn't include the space for the terminating '\0'.
- */
-size_t kernfs_path_len(struct kernfs_node *kn)
-{
-   size_t len = 0;
-   unsigned long flags;
-
-   spin_lock_irqsave(_rename_lock, flags);
-
-   do {
-   len += strlen(kn->name) + 1;
-   kn = kn->parent;
-   } while (kn && kn->parent);
-
-   spin_unlock_irqrestore(_rename_lock, flags);
-
-   return len;
-}
-
-/**
  * kernfs_path_from_node - build path of node @to relative to @from.
  * @from: parent kernfs_node relative to which we need to build the path
  * @to: kernfs_node of interest
diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
index 64358d2..a410c75 100644
--- a/include/linux/kernfs.h
+++ b/include/linux/kernfs.h
@@ -269,7 +269,6 @@ static inline bool kernfs_ns_enabled(struct kernfs_node *kn)
 }
 
 int kernfs_name(struct kernfs_node *kn, char *buf, size_t buflen);
-size_t kernfs_path_len(struct kernfs_node *kn);
 int kernfs_path_from_node(struct kernfs_node *root_kn, struct kernfs_node *kn,
  char *buf, size_t buflen);
 void pr_cont_kernfs_name(struct kernfs_node *kn);
@@ -340,9 +339,6 @@ static inline bool kernfs_ns_enabled(struct kernfs_node *kn)
 static inline int kernfs_name(struct kernfs_node *kn, char *buf, size_t buflen)
 { return -ENOSYS; }
 
-static inline size_t kernfs_path_len(struct kernfs_node *kn)
-{ return 0; }
-
 static inline int kernfs_path_from_node(struct kernfs_node *root_kn,
struct kernfs_node *kn,
char *buf, size_t buflen);
-- 
2.7.4

[PATCHSET] kernfs, cgroup: make kernfs_path*() and cgroup_path*() behave in strlcpy() style

[Tejun Heo]

kernfs path formatting functions always return the length of full path
but the content of the output buffer is undefined when the length is
longer than the provided buffer.  Most cgroup path formatting
functions return the start of the output or NULL on errors including
overflow.  These inconsistent and rather peculiar behaviors developed
over time and make these functions unnecessarily difficult to use.
This patchset updates the formatting functions so that they all behave
in the style of strlcpy().

Greg, these changes are used by cgroup tracepoint additions and
shouldn't affect other users much.  Would it be okay to route these
through the cgroup tree?

 0001-kernfs-add-dummy-implementation-of-kernfs_path_from_.patch
 0002-kernfs-make-kernfs_path-behave-in-the-style-of-strlc.patch
 0003-kernfs-remove-kernfs_path_len.patch
 0004-cgroup-make-cgroup_path-and-friends-behave-in-the-st.patch

The patches are also available in the following git branch.

 git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git 
review-kernfs_path-strlcpy

diffstat follows.  Thanks.

 fs/kernfs/dir.c|   84 +
 fs/sysfs/dir.c |6 +--
 include/linux/blk-cgroup.h |   11 -
 include/linux/cgroup.h |9 ++--
 include/linux/kernfs.h |   28 ++-
 kernel/cgroup.c|   48 +++--
 kernel/cpuset.c|   12 +++---
 7 files changed, 73 insertions(+), 125 deletions(-)

--
tejun

Re: [PATCH 0/7] ima: carry the measurement list across kexec

[Balbir Singh]

On 04/08/16 22:24, Mimi Zohar wrote:
> The TPM PCRs are only reset on a hard reboot.  In order to validate a
> TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list
> of the running kernel must be saved and then restored on the subsequent
> boot.
> 
> The existing securityfs binary_runtime_measurements file conveniently
> provides a serialized format of the IMA measurement list. This patch
> set serializes the measurement list in this format and restores it.
> 
> This patch set pre-req's Thiago Bauermann's "kexec_file: Add buffer
> hand-over for the next kernel" patch set* for actually carrying the
> serialized measurement list across the kexec.
> 
> Mimi
> 

Hi, Mimi

I am trying to convince myself of the security of the solution. I asked
Thiago as well, but may be I am be lagging behind in understanding.

We trust the kernel to hand over PCR values of the old kernel (which
cannot be validated) to the IMA subsystem in the new kernel for storage.
I guess the idea is for ima_add_boot_aggregate to do the right thing?
How do we validate what the old kernel is giving us? Why do we care for
the old measurement list? Is it still of significance in the new kernel?


Balbir Singh.

Re: [PATCH 0/7] ima: carry the measurement list across kexec

[Balbir Singh]

On 04/08/16 22:24, Mimi Zohar wrote:
> The TPM PCRs are only reset on a hard reboot.  In order to validate a
> TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list
> of the running kernel must be saved and then restored on the subsequent
> boot.
> 
> The existing securityfs binary_runtime_measurements file conveniently
> provides a serialized format of the IMA measurement list. This patch
> set serializes the measurement list in this format and restores it.
> 
> This patch set pre-req's Thiago Bauermann's "kexec_file: Add buffer
> hand-over for the next kernel" patch set* for actually carrying the
> serialized measurement list across the kexec.
> 
> Mimi
> 

Hi, Mimi

I am trying to convince myself of the security of the solution. I asked
Thiago as well, but may be I am be lagging behind in understanding.

We trust the kernel to hand over PCR values of the old kernel (which
cannot be validated) to the IMA subsystem in the new kernel for storage.
I guess the idea is for ima_add_boot_aggregate to do the right thing?
How do we validate what the old kernel is giving us? Why do we care for
the old measurement list? Is it still of significance in the new kernel?


Balbir Singh.

Re: [PATCH 02/10] docs: sphinxify coccinelle.txt and add it to dev-tools

[Julia Lawall]

Acked-by: Julia Lawall 

On Mon, 8 Aug 2016, Jonathan Corbet wrote:

> No textual changes have been made, but the formatting has obviously been
> tweaked.
>
> Cc: Michal Marek 
> Cc: Gilles Muller 
> Cc: Nicolas Palix 
> Cc: Julia Lawall 
> Signed-off-by: Jonathan Corbet 
> ---
>  .../{coccinelle.txt => dev-tools/coccinelle.rst}   | 359 
> +++--
>  Documentation/dev-tools/tools.rst  |   1 +
>  MAINTAINERS|   2 +-
>  3 files changed, 192 insertions(+), 170 deletions(-)
>  rename Documentation/{coccinelle.txt => dev-tools/coccinelle.rst} (56%)
>
> diff --git a/Documentation/coccinelle.txt 
> b/Documentation/dev-tools/coccinelle.rst
> similarity index 56%
> rename from Documentation/coccinelle.txt
> rename to Documentation/dev-tools/coccinelle.rst
> index 01fb1da..4a64b4c 100644
> --- a/Documentation/coccinelle.txt
> +++ b/Documentation/dev-tools/coccinelle.rst
> @@ -1,10 +1,18 @@
> -Copyright 2010 Nicolas Palix 
> -Copyright 2010 Julia Lawall 
> -Copyright 2010 Gilles Muller 
> +.. Copyright 2010 Nicolas Palix 
> +.. Copyright 2010 Julia Lawall 
> +.. Copyright 2010 Gilles Muller 
>
> +.. highlight:: none
>
> - Getting Coccinelle
> -
> +Coccinelle
> +==
> +
> +Coccinelle is a tool for pattern matching and text transformation that has
> +many uses in kernel development, including the application of complex,
> +tree-wide patches and detection of problematic programming patterns.
> +
> +Getting Coccinelle
> +---
>
>  The semantic patches included in the kernel use features and options
>  which are provided by Coccinelle version 1.0.0-rc11 and above.
> @@ -22,24 +30,23 @@ of many distributions, e.g. :
>   - NetBSD
>   - FreeBSD
>
> -
>  You can get the latest version released from the Coccinelle homepage at
>  http://coccinelle.lip6.fr/
>
>  Information and tips about Coccinelle are also provided on the wiki
>  pages at http://cocci.ekstranet.diku.dk/wiki/doku.php
>
> -Once you have it, run the following command:
> +Once you have it, run the following command::
>
>   ./configure
>  make
>
> -as a regular user, and install it with
> +as a regular user, and install it with::
>
>  sudo make install
>
> - Supplemental documentation
> -
> +Supplemental documentation
> +---
>
>  For supplemental documentation refer to the wiki:
>
> @@ -47,49 +54,52 @@ https://bottest.wiki.kernel.org/coccicheck
>
>  The wiki documentation always refers to the linux-next version of the script.
>
> - Using Coccinelle on the Linux kernel
> -~~
> +Using Coccinelle on the Linux kernel
> +
>
>  A Coccinelle-specific target is defined in the top level
> -Makefile. This target is named 'coccicheck' and calls the 'coccicheck'
> -front-end in the 'scripts' directory.
> +Makefile. This target is named ``coccicheck`` and calls the ``coccicheck``
> +front-end in the ``scripts`` directory.
>
> -Four basic modes are defined: patch, report, context, and org. The mode to
> -use is specified by setting the MODE variable with 'MODE='.
> +Four basic modes are defined: ``patch``, ``report``, ``context``, and
> +``org``. The mode to use is specified by setting the MODE variable with
> +``MODE=``.
>
> -'patch' proposes a fix, when possible.
> +- ``patch`` proposes a fix, when possible.
>
> -'report' generates a list in the following format:
> +- ``report`` generates a list in the following format:
>file:line:column-column: message
>
> -'context' highlights lines of interest and their context in a
> -diff-like style.Lines of interest are indicated with '-'.
> +- ``context`` highlights lines of interest and their context in a
> +  diff-like style.Lines of interest are indicated with ``-``.
>
> -'org' generates a report in the Org mode format of Emacs.
> +- ``org`` generates a report in the Org mode format of Emacs.
>
>  Note that not all semantic patches implement all modes. For easy use
>  of Coccinelle, the default mode is "report".
>
>  Two other modes provide some common combinations of these modes.
>
> -'chain' tries the previous modes in the order above until one succeeds.
> +- ``chain`` tries the previous modes in the order above until one succeeds.
> +
> +- ``rep+ctxt`` runs successively the report mode and the context mode.
> +  It should be used with the C option (described later)
> +  which checks the code on a file basis.
>
> -'rep+ctxt' runs successively the report mode and the context mode.
> -It should be used with the C option (described later)
> -which checks the code on a file basis.
> +Examples
> +
>
> -Examples:
> - To 

Re: [PATCH 02/10] docs: sphinxify coccinelle.txt and add it to dev-tools

[Julia Lawall]

Acked-by: Julia Lawall 

On Mon, 8 Aug 2016, Jonathan Corbet wrote:

> No textual changes have been made, but the formatting has obviously been
> tweaked.
>
> Cc: Michal Marek 
> Cc: Gilles Muller 
> Cc: Nicolas Palix 
> Cc: Julia Lawall 
> Signed-off-by: Jonathan Corbet 
> ---
>  .../{coccinelle.txt => dev-tools/coccinelle.rst}   | 359 
> +++--
>  Documentation/dev-tools/tools.rst  |   1 +
>  MAINTAINERS|   2 +-
>  3 files changed, 192 insertions(+), 170 deletions(-)
>  rename Documentation/{coccinelle.txt => dev-tools/coccinelle.rst} (56%)
>
> diff --git a/Documentation/coccinelle.txt 
> b/Documentation/dev-tools/coccinelle.rst
> similarity index 56%
> rename from Documentation/coccinelle.txt
> rename to Documentation/dev-tools/coccinelle.rst
> index 01fb1da..4a64b4c 100644
> --- a/Documentation/coccinelle.txt
> +++ b/Documentation/dev-tools/coccinelle.rst
> @@ -1,10 +1,18 @@
> -Copyright 2010 Nicolas Palix 
> -Copyright 2010 Julia Lawall 
> -Copyright 2010 Gilles Muller 
> +.. Copyright 2010 Nicolas Palix 
> +.. Copyright 2010 Julia Lawall 
> +.. Copyright 2010 Gilles Muller 
>
> +.. highlight:: none
>
> - Getting Coccinelle
> -
> +Coccinelle
> +==
> +
> +Coccinelle is a tool for pattern matching and text transformation that has
> +many uses in kernel development, including the application of complex,
> +tree-wide patches and detection of problematic programming patterns.
> +
> +Getting Coccinelle
> +---
>
>  The semantic patches included in the kernel use features and options
>  which are provided by Coccinelle version 1.0.0-rc11 and above.
> @@ -22,24 +30,23 @@ of many distributions, e.g. :
>   - NetBSD
>   - FreeBSD
>
> -
>  You can get the latest version released from the Coccinelle homepage at
>  http://coccinelle.lip6.fr/
>
>  Information and tips about Coccinelle are also provided on the wiki
>  pages at http://cocci.ekstranet.diku.dk/wiki/doku.php
>
> -Once you have it, run the following command:
> +Once you have it, run the following command::
>
>   ./configure
>  make
>
> -as a regular user, and install it with
> +as a regular user, and install it with::
>
>  sudo make install
>
> - Supplemental documentation
> -
> +Supplemental documentation
> +---
>
>  For supplemental documentation refer to the wiki:
>
> @@ -47,49 +54,52 @@ https://bottest.wiki.kernel.org/coccicheck
>
>  The wiki documentation always refers to the linux-next version of the script.
>
> - Using Coccinelle on the Linux kernel
> -~~
> +Using Coccinelle on the Linux kernel
> +
>
>  A Coccinelle-specific target is defined in the top level
> -Makefile. This target is named 'coccicheck' and calls the 'coccicheck'
> -front-end in the 'scripts' directory.
> +Makefile. This target is named ``coccicheck`` and calls the ``coccicheck``
> +front-end in the ``scripts`` directory.
>
> -Four basic modes are defined: patch, report, context, and org. The mode to
> -use is specified by setting the MODE variable with 'MODE='.
> +Four basic modes are defined: ``patch``, ``report``, ``context``, and
> +``org``. The mode to use is specified by setting the MODE variable with
> +``MODE=``.
>
> -'patch' proposes a fix, when possible.
> +- ``patch`` proposes a fix, when possible.
>
> -'report' generates a list in the following format:
> +- ``report`` generates a list in the following format:
>file:line:column-column: message
>
> -'context' highlights lines of interest and their context in a
> -diff-like style.Lines of interest are indicated with '-'.
> +- ``context`` highlights lines of interest and their context in a
> +  diff-like style.Lines of interest are indicated with ``-``.
>
> -'org' generates a report in the Org mode format of Emacs.
> +- ``org`` generates a report in the Org mode format of Emacs.
>
>  Note that not all semantic patches implement all modes. For easy use
>  of Coccinelle, the default mode is "report".
>
>  Two other modes provide some common combinations of these modes.
>
> -'chain' tries the previous modes in the order above until one succeeds.
> +- ``chain`` tries the previous modes in the order above until one succeeds.
> +
> +- ``rep+ctxt`` runs successively the report mode and the context mode.
> +  It should be used with the C option (described later)
> +  which checks the code on a file basis.
>
> -'rep+ctxt' runs successively the report mode and the context mode.
> -It should be used with the C option (described later)
> -which checks the code on a file basis.
> +Examples
> +
>
> -Examples:
> - To make a report for every semantic patch, run the following command:
> +To make a report for every semantic patch, run the following command::
>
>   make coccicheck MODE=report
>
> - To produce patches, run:
> +To 

Re: perf: WARNING: kernel/events/core.c:4893 perf_mmap_close

[Alexander Shishkin]

Vince Weaver  writes:

> Hello
>
> running the perf_fuzzer on Haswell, this is a new warning I don't think 
> I've seen before.
>
> It works out to be this code here:
>
> /* this has to be the last one */
> rb_free_aux(rb);
> WARN_ON_ONCE(atomic_read(>aux_refcount));
>
> mutex_unlock(>mmap_mutex);

Awesome, I'll have a look. Can you tell it it was messing around with
intel_bts driver from the fuzzer log?

Thanks,
--
Alex

Re: perf: WARNING: kernel/events/core.c:4893 perf_mmap_close

[Alexander Shishkin]

Vince Weaver  writes:

> Hello
>
> running the perf_fuzzer on Haswell, this is a new warning I don't think 
> I've seen before.
>
> It works out to be this code here:
>
> /* this has to be the last one */
> rb_free_aux(rb);
> WARN_ON_ONCE(atomic_read(>aux_refcount));
>
> mutex_unlock(>mmap_mutex);

Awesome, I'll have a look. Can you tell it it was messing around with
intel_bts driver from the fuzzer log?

Thanks,
--
Alex

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

[Guenter Roeck]

On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.6.6 release.
There are 96 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Aug 10 18:02:27 UTC 2016.
Anything received after that time might be too late.



Build results:
total: 148 pass: 146 fail: 2
Failed builds:
unicore32:defconfig
unicore32:allnoconfig

Qemu test results:
total: 107 pass: 103 fail: 4
Failed tests:
mips:malta_defconfig:nosmp
mips64:malta_defconfig:nosmp
mipsel:malta_defconfig:nosmp
mipsel64:malta_defconfig:nosmp

The unicore32 build error is still not fixed in mainline.

mips:

Building mips:malta_defconfig:nosmp ... failed

Error log:
drivers/built-in.o: In function `gic_shared_irq_domain_map.isra.0':
irq-mips-gic.c:(.text+0x1d58): undefined reference to `smp_num_siblings'
irq-mips-gic.c:(.text+0x1d5c): undefined reference to `smp_num_siblings'
irq-mips-gic.c:(.text+0x1de0): undefined reference to `smp_num_siblings'
irq-mips-gic.c:(.text+0x1de8): undefined reference to `smp_num_siblings'

Only seen with non-SMP builds. Tricky one, required bisect.

# bad: [0353fa20cb40ea75a7e3b7293b533bde4fa013e9] Linux 4.6.6-rc1
# good: [bed4c611a3b80fae04d75b9f85fcaf174bac1b06] Linux 4.6.5
git bisect start 'HEAD' 'v4.6.5'
# good: [8d3b41c18cff2db7ccea71243b945a33610b8cb5] cgroup: remove redundant 
cleanup in css_create
git bisect good 
8d3b41c18cff2db7ccea71243b945a33610b8cb583c9f9e994f5c963fc652a52befc120699dcc591
# good: [3a255979bc75ffcc263928045df4b5f46df8a8ca] sched/fair: Fix 
effective_load() to consistently use smoothed load
git bisect good 3a255979bc75ffcc263928045df4b5f46df8a8ca
# bad: [6eafb1f777de375b52c8a83d262da2885a28579a] posix_cpu_timer: Exit early 
when process has been reaped
git bisect bad 6eafb1f777de375b52c8a83d262da2885a28579a
# bad: [83c9f9e994f5c963fc652a52befc120699dcc591] irqchip/mips-gic: Map to VPs 
using HW VPNum
git bisect bad 83c9f9e994f5c963fc652a52befc120699dcc591
# good: [3a1e9944db1570f9b654b7a187f13898e5c59529] can: fix handling of 
unmodifiable configuration options fix
git bisect good 3a1e9944db1570f9b654b7a187f13898e5c59529
# good: [f06b9b8071ae6e383931795e2a459d6abc0bc7bd] RDS: fix rds_tcp_init() 
error path
git bisect good f06b9b8071ae6e383931795e2a459d6abc0bc7bd
# first bad commit: [83c9f9e994f5c963fc652a52befc120699dcc591] 
irqchip/mips-gic: Map to VPs using HW VPNum

Reverting 83c9f9e994f5c963fc652a52befc120699dcc591 fixes the problem.
Its description suggests that it fixes a real bug, though, so copying Paul for 
input.

Guenter

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

[Guenter Roeck]

On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.6.6 release.
There are 96 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Aug 10 18:02:27 UTC 2016.
Anything received after that time might be too late.



Build results:
total: 148 pass: 146 fail: 2
Failed builds:
unicore32:defconfig
unicore32:allnoconfig

Qemu test results:
total: 107 pass: 103 fail: 4
Failed tests:
mips:malta_defconfig:nosmp
mips64:malta_defconfig:nosmp
mipsel:malta_defconfig:nosmp
mipsel64:malta_defconfig:nosmp

The unicore32 build error is still not fixed in mainline.

mips:

Building mips:malta_defconfig:nosmp ... failed

Error log:
drivers/built-in.o: In function `gic_shared_irq_domain_map.isra.0':
irq-mips-gic.c:(.text+0x1d58): undefined reference to `smp_num_siblings'
irq-mips-gic.c:(.text+0x1d5c): undefined reference to `smp_num_siblings'
irq-mips-gic.c:(.text+0x1de0): undefined reference to `smp_num_siblings'
irq-mips-gic.c:(.text+0x1de8): undefined reference to `smp_num_siblings'

Only seen with non-SMP builds. Tricky one, required bisect.

# bad: [0353fa20cb40ea75a7e3b7293b533bde4fa013e9] Linux 4.6.6-rc1
# good: [bed4c611a3b80fae04d75b9f85fcaf174bac1b06] Linux 4.6.5
git bisect start 'HEAD' 'v4.6.5'
# good: [8d3b41c18cff2db7ccea71243b945a33610b8cb5] cgroup: remove redundant 
cleanup in css_create
git bisect good 
8d3b41c18cff2db7ccea71243b945a33610b8cb583c9f9e994f5c963fc652a52befc120699dcc591
# good: [3a255979bc75ffcc263928045df4b5f46df8a8ca] sched/fair: Fix 
effective_load() to consistently use smoothed load
git bisect good 3a255979bc75ffcc263928045df4b5f46df8a8ca
# bad: [6eafb1f777de375b52c8a83d262da2885a28579a] posix_cpu_timer: Exit early 
when process has been reaped
git bisect bad 6eafb1f777de375b52c8a83d262da2885a28579a
# bad: [83c9f9e994f5c963fc652a52befc120699dcc591] irqchip/mips-gic: Map to VPs 
using HW VPNum
git bisect bad 83c9f9e994f5c963fc652a52befc120699dcc591
# good: [3a1e9944db1570f9b654b7a187f13898e5c59529] can: fix handling of 
unmodifiable configuration options fix
git bisect good 3a1e9944db1570f9b654b7a187f13898e5c59529
# good: [f06b9b8071ae6e383931795e2a459d6abc0bc7bd] RDS: fix rds_tcp_init() 
error path
git bisect good f06b9b8071ae6e383931795e2a459d6abc0bc7bd
# first bad commit: [83c9f9e994f5c963fc652a52befc120699dcc591] 
irqchip/mips-gic: Map to VPs using HW VPNum

Reverting 83c9f9e994f5c963fc652a52befc120699dcc591 fixes the problem.
Its description suggests that it fixes a real bug, though, so copying Paul for 
input.

Guenter

Re: [PATCH v2 3/4] perf/core: introduce PMU_EV_CAP_READ_ACTIVE_PKG

[David Carrillo-Cisneros]

Hi Nilay,

Sounds good, I will post an updated version.

Thanks,
David

On Mon, Aug 8, 2016 at 9:12 AM, Nilay Vaish  wrote:
> On 7 August 2016 at 15:10, David Carrillo-Cisneros  wrote:
>> Hi Nilay,
>>
  static int perf_event_read(struct perf_event *event, bool group)
  {
 -   int ret = 0;
 +   int ret = 0, cpu_to_read;

 -   /*
 -* If event is enabled and currently active on a CPU, update the
 -* value in the event structure:
 -*/
 -   if (event->state == PERF_EVENT_STATE_ACTIVE) {
 +   cpu_to_read = find_cpu_to_read(event);
 +
 +   if (cpu_to_read >= 0) {
 struct perf_read_data data = {
 .event = event,
 .group = group,
 .ret = 0,
 };
 -   ret = smp_call_function_single(event->oncpu,
 +   ret = smp_call_function_single(cpu_to_read,
__perf_event_read, ,
 1);
 ret = ret ? : data.ret;
 } else if (event->state == PERF_EVENT_STATE_INACTIVE) {

>>>
>>> I would like to suggest a small change to this patch.  I think the check on
>>> PERF_EVENT_STATE_ACTIVE should be retained in the perf_event_read()
>>> function.  The new function should assume that the event is active.  I find
>>> this more readable since the next check in function perf_event_read() is on
>>> PERF_EVENT_STATE_INACTIVE.
>>
>> Two oncoming flags that Intel CQM/CMT will use are meant to allow read
>> even if event is inactive. This makes sense in CQM/CMT because the hw
>> RMID is always reserved. I am ok with keeping the check for
>> STATE_ACTIVE until those flags are actually introduced, tough.
>
>
> Hello David
>
> Lets go with checking PERF_EVENT_STATE_ACTIVE in perf_event_read() for
> the time being.  With the new version of the patch that you posted, I
> find that checking PERF_EVENT_STATE_ACTIVE in find_cpu_to_read() makes
> you introduce another if statement for checking STATE_INACTIVE.
>
> If your CQM/CMT patches later need the code structure you have now, I
> would also support it.  But as of now, I think, it is better to check
> STATE_ACTIVE in perf_event_read().
>
>
> Thanks
> Nilay

Re: [PATCH v2 3/4] perf/core: introduce PMU_EV_CAP_READ_ACTIVE_PKG

[David Carrillo-Cisneros]

Hi Nilay,

Sounds good, I will post an updated version.

Thanks,
David

On Mon, Aug 8, 2016 at 9:12 AM, Nilay Vaish  wrote:
> On 7 August 2016 at 15:10, David Carrillo-Cisneros  wrote:
>> Hi Nilay,
>>
  static int perf_event_read(struct perf_event *event, bool group)
  {
 -   int ret = 0;
 +   int ret = 0, cpu_to_read;

 -   /*
 -* If event is enabled and currently active on a CPU, update the
 -* value in the event structure:
 -*/
 -   if (event->state == PERF_EVENT_STATE_ACTIVE) {
 +   cpu_to_read = find_cpu_to_read(event);
 +
 +   if (cpu_to_read >= 0) {
 struct perf_read_data data = {
 .event = event,
 .group = group,
 .ret = 0,
 };
 -   ret = smp_call_function_single(event->oncpu,
 +   ret = smp_call_function_single(cpu_to_read,
__perf_event_read, ,
 1);
 ret = ret ? : data.ret;
 } else if (event->state == PERF_EVENT_STATE_INACTIVE) {

>>>
>>> I would like to suggest a small change to this patch.  I think the check on
>>> PERF_EVENT_STATE_ACTIVE should be retained in the perf_event_read()
>>> function.  The new function should assume that the event is active.  I find
>>> this more readable since the next check in function perf_event_read() is on
>>> PERF_EVENT_STATE_INACTIVE.
>>
>> Two oncoming flags that Intel CQM/CMT will use are meant to allow read
>> even if event is inactive. This makes sense in CQM/CMT because the hw
>> RMID is always reserved. I am ok with keeping the check for
>> STATE_ACTIVE until those flags are actually introduced, tough.
>
>
> Hello David
>
> Lets go with checking PERF_EVENT_STATE_ACTIVE in perf_event_read() for
> the time being.  With the new version of the patch that you posted, I
> find that checking PERF_EVENT_STATE_ACTIVE in find_cpu_to_read() makes
> you introduce another if statement for checking STATE_INACTIVE.
>
> If your CQM/CMT patches later need the code structure you have now, I
> would also support it.  But as of now, I think, it is better to check
> STATE_ACTIVE in perf_event_read().
>
>
> Thanks
> Nilay

[PATCH 1/1] usb: misc: usbtest: add fix for driver hang

[Lu Baolu]

In sg_timeout(), req->status is set to "-ETIMEDOUT" before calling
into usb_sg_cancel(). usb_sg_cancel() will do nothing and return
directly if req->status has been set to a non-zero value. This will
cause driver hang as soon as transfer time out is triggered.

In my test case, below system log shows when port reset happens after
urb being submitted.

[55099.746213] usb 2-3: USB disconnect, device number 2
[55321.955451] INFO: task kworker/6:0:59 blocked for more than 120 seconds.
[55321.955463]   Not tainted 4.7.0-rc6+ #19
[55321.955466] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[55321.955472] kworker/6:0 D 88045ad3bbf8 059  2 0x
[55321.955489] Workqueue: usb_hub_wq hub_event
[55321.955493]  88045ad3bbf8 88040030 88045ad30f40 
88045ad3bbd0
[55321.955499]  88045ad3c000 8804590920fc 88045ad30f40 

[55321.955505]  880459092100 88045ad3bc10 817b5925 
8804590920f8
[55321.955511] Call Trace:
[55321.955521]  [] schedule+0x35/0x80
[55321.955527]  [] schedule_preempt_disabled+0xe/0x10
[55321.955533]  [] __mutex_lock_slowpath+0x95/0x110
[55321.955538]  [] mutex_lock+0x1f/0x2f
[55321.955544]  [] usb_disconnect+0x53/0x270
[55321.90]  [] hub_port_connect+0x71/0x900
[55321.96]  [] ? hub_port_reset+0x3de/0x630
[55321.955562]  [] hub_event+0x63e/0xb20
[55321.955569]  [] ? put_prev_entity+0x35/0x730
[55321.955577]  [] process_one_work+0x153/0x3f0
[55321.955583]  [] worker_thread+0x12b/0x4b0
[55321.955590]  [] ? rescuer_thread+0x340/0x340
[55321.955595]  [] kthread+0xc9/0xe0
[55321.955601]  [] ret_from_fork+0x1f/0x40
[55321.955606]  [] ? kthread_park+0x60/0x60
[55321.955638] INFO: task testusb:3011 blocked for more than 120 seconds.
[55321.955643]   Not tainted 4.7.0-rc6+ #19
[55321.955647] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[55321.955651] testusb D 880449a079f8 0  3011   2367 0x
[55321.955657]  880449a079f8 0002 88045754cc40 
815b91b9
[55321.955663]  880449a08000 7fff 880449a07cb0 
88045754cc40
[55321.955668]   880449a07a10 817b5925 
880449a07cb8
[55321.955673] Call Trace:
[55321.955680]  [] ? usb_hcd_submit_urb+0xa9/0xba0
[55321.955685]  [] schedule+0x35/0x80
[55321.955691]  [] schedule_timeout+0x231/0x2d0
[55321.955698]  [] ? __alloc_pages_nodemask+0x112/0x2b0
[55321.955703]  [] wait_for_completion+0xa4/0x110
[55321.955709]  [] ? wake_up_q+0x80/0x80
[55321.955713]  [] usb_sg_wait+0x138/0x190
[55321.955722]  [] perform_sglist+0xef/0x180 [usbtest]
[55321.955728]  [] ? usbtest_resume+0x10/0x10 [usbtest]
[55321.955734]  [] usbtest_do_ioctl+0x898/0x1520 [usbtest]
[55321.955740]  [] ? usb_hcd_reset_endpoint+0x25/0x60
[55321.955745]  [] ? usb_enable_endpoint+0x85/0x90
[55321.955751]  [] usbtest_ioctl+0x123/0x26e [usbtest]
[55321.955756]  [] ? filemap_map_pages+0x295/0x310
[55321.955763]  [] ? proc_ioctl+0x48/0x210
[55321.955769]  [] proc_ioctl+0x130/0x210
[55321.955776]  [] usbdev_do_ioctl+0x50a/0x1170
[55321.955782]  [] usbdev_ioctl+0xe/0x20
[55321.955789]  [] do_vfs_ioctl+0x96/0x590
[55321.955794]  [] ? putname+0x53/0x60
[55321.955800]  [] SyS_ioctl+0x79/0x90
[55321.955806]  [] entry_SYSCALL_64_fastpath+0x1e/0xa

This patch fixes this driver hang. It should be back-ported to stable
kernel with version after v3.15.

Cc: sta...@vger.kernel.org
Cc: Alan Stern 
Signed-off-by: Lu Baolu 
---
 drivers/usb/misc/usbtest.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 6b978f0..6c6586d 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -585,7 +585,6 @@ static void sg_timeout(unsigned long _req)
 {
struct usb_sg_request   *req = (struct usb_sg_request *) _req;
 
-   req->status = -ETIMEDOUT;
usb_sg_cancel(req);
 }
 
-- 
2.1.4

[PATCH 1/1] usb: misc: usbtest: add fix for driver hang

[Lu Baolu]

In sg_timeout(), req->status is set to "-ETIMEDOUT" before calling
into usb_sg_cancel(). usb_sg_cancel() will do nothing and return
directly if req->status has been set to a non-zero value. This will
cause driver hang as soon as transfer time out is triggered.

In my test case, below system log shows when port reset happens after
urb being submitted.

[55099.746213] usb 2-3: USB disconnect, device number 2
[55321.955451] INFO: task kworker/6:0:59 blocked for more than 120 seconds.
[55321.955463]   Not tainted 4.7.0-rc6+ #19
[55321.955466] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[55321.955472] kworker/6:0 D 88045ad3bbf8 059  2 0x
[55321.955489] Workqueue: usb_hub_wq hub_event
[55321.955493]  88045ad3bbf8 88040030 88045ad30f40 
88045ad3bbd0
[55321.955499]  88045ad3c000 8804590920fc 88045ad30f40 

[55321.955505]  880459092100 88045ad3bc10 817b5925 
8804590920f8
[55321.955511] Call Trace:
[55321.955521]  [] schedule+0x35/0x80
[55321.955527]  [] schedule_preempt_disabled+0xe/0x10
[55321.955533]  [] __mutex_lock_slowpath+0x95/0x110
[55321.955538]  [] mutex_lock+0x1f/0x2f
[55321.955544]  [] usb_disconnect+0x53/0x270
[55321.90]  [] hub_port_connect+0x71/0x900
[55321.96]  [] ? hub_port_reset+0x3de/0x630
[55321.955562]  [] hub_event+0x63e/0xb20
[55321.955569]  [] ? put_prev_entity+0x35/0x730
[55321.955577]  [] process_one_work+0x153/0x3f0
[55321.955583]  [] worker_thread+0x12b/0x4b0
[55321.955590]  [] ? rescuer_thread+0x340/0x340
[55321.955595]  [] kthread+0xc9/0xe0
[55321.955601]  [] ret_from_fork+0x1f/0x40
[55321.955606]  [] ? kthread_park+0x60/0x60
[55321.955638] INFO: task testusb:3011 blocked for more than 120 seconds.
[55321.955643]   Not tainted 4.7.0-rc6+ #19
[55321.955647] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[55321.955651] testusb D 880449a079f8 0  3011   2367 0x
[55321.955657]  880449a079f8 0002 88045754cc40 
815b91b9
[55321.955663]  880449a08000 7fff 880449a07cb0 
88045754cc40
[55321.955668]   880449a07a10 817b5925 
880449a07cb8
[55321.955673] Call Trace:
[55321.955680]  [] ? usb_hcd_submit_urb+0xa9/0xba0
[55321.955685]  [] schedule+0x35/0x80
[55321.955691]  [] schedule_timeout+0x231/0x2d0
[55321.955698]  [] ? __alloc_pages_nodemask+0x112/0x2b0
[55321.955703]  [] wait_for_completion+0xa4/0x110
[55321.955709]  [] ? wake_up_q+0x80/0x80
[55321.955713]  [] usb_sg_wait+0x138/0x190
[55321.955722]  [] perform_sglist+0xef/0x180 [usbtest]
[55321.955728]  [] ? usbtest_resume+0x10/0x10 [usbtest]
[55321.955734]  [] usbtest_do_ioctl+0x898/0x1520 [usbtest]
[55321.955740]  [] ? usb_hcd_reset_endpoint+0x25/0x60
[55321.955745]  [] ? usb_enable_endpoint+0x85/0x90
[55321.955751]  [] usbtest_ioctl+0x123/0x26e [usbtest]
[55321.955756]  [] ? filemap_map_pages+0x295/0x310
[55321.955763]  [] ? proc_ioctl+0x48/0x210
[55321.955769]  [] proc_ioctl+0x130/0x210
[55321.955776]  [] usbdev_do_ioctl+0x50a/0x1170
[55321.955782]  [] usbdev_ioctl+0xe/0x20
[55321.955789]  [] do_vfs_ioctl+0x96/0x590
[55321.955794]  [] ? putname+0x53/0x60
[55321.955800]  [] SyS_ioctl+0x79/0x90
[55321.955806]  [] entry_SYSCALL_64_fastpath+0x1e/0xa

This patch fixes this driver hang. It should be back-ported to stable
kernel with version after v3.15.

Cc: sta...@vger.kernel.org
Cc: Alan Stern 
Signed-off-by: Lu Baolu 
---
 drivers/usb/misc/usbtest.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 6b978f0..6c6586d 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -585,7 +585,6 @@ static void sg_timeout(unsigned long _req)
 {
struct usb_sg_request   *req = (struct usb_sg_request *) _req;
 
-   req->status = -ETIMEDOUT;
usb_sg_cancel(req);
 }
 
-- 
2.1.4

Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing RFXE bit in HID1

[Borislav Petkov]

On Tue, Aug 09, 2016 at 04:31:19AM +, york sun wrote:
> Yes, for most SoCs RFXE remains cleared. Uncorrectable errors are 
> handled by EDAC.

And how is mpc85_xxx EDAC handling them?

mpc85xx_mc_check() only reports them.

And now to get to my original question: is it *enough* to report
uncorrectable errors on those platforms or do they need more
sophisticated error handling in order to disable data corruption?

-- 
Regards/Gruss,
Boris.

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

Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing RFXE bit in HID1

[Borislav Petkov]

On Tue, Aug 09, 2016 at 04:31:19AM +, york sun wrote:
> Yes, for most SoCs RFXE remains cleared. Uncorrectable errors are 
> handled by EDAC.

And how is mpc85_xxx EDAC handling them?

mpc85xx_mc_check() only reports them.

And now to get to my original question: is it *enough* to report
uncorrectable errors on those platforms or do they need more
sophisticated error handling in order to disable data corruption?

-- 
Regards/Gruss,
Boris.

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

HELLO

[George Oloni]

Hello,

I hope this Message finds you well.

To start with my name is George Oloni. I am seeking for your cooperation to 
invest in your Country.

Please kindly respond to this message as to enable me to gives you More Details 
about my investment proposal.

Warm Regards
Mr. George Oloni

HELLO

[George Oloni]

Hello,

I hope this Message finds you well.

To start with my name is George Oloni. I am seeking for your cooperation to 
invest in your Country.

Please kindly respond to this message as to enable me to gives you More Details 
about my investment proposal.

Warm Regards
Mr. George Oloni

Re: [PATCH v6 RESEND 4/7] perf config: Use combined {fore,back}ground colors value instead of each two color

[Taeung Song]

Hi, Arnaldo :)

On 08/09/2016 03:58 AM, Arnaldo Carvalho de Melo wrote:

Em Tue, Aug 02, 2016 at 06:20:46PM +0900, Taeung Song escreveu:

To easily set default config values into actual variables for 'colors' config,
it would be better that actual variables for each 'colors' config
also have only one value like 'default_config_item' type.

If we use combined {fore,back}ground colors values in ui_browser_colorset,
it smoothly work to initialize default config values for 'colors' config
by 'colors_config_items' array that contains default values for it at 
util/config.c.
because both actual variable and config item of 'colors_config_items'
are equal in the number of values (as just one).

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Wang Nan 
Signed-off-by: Taeung Song 
---
 tools/perf/ui/browser.c | 53 +++--
 1 file changed, 25 insertions(+), 28 deletions(-)

diff --git a/tools/perf/ui/browser.c b/tools/perf/ui/browser.c
index 3eb3edb..31e2028 100644
--- a/tools/perf/ui/browser.c
+++ b/tools/perf/ui/browser.c
@@ -503,61 +503,53 @@ unsigned int ui_browser__list_head_refresh(struct 
ui_browser *browser)
 }

 static struct ui_browser_colorset {
-   const char *name, *fg, *bg;
+   const char *name, *colors;
int colorset;
 } ui_browser__colorsets[] = {
{
.colorset = HE_COLORSET_TOP,
.name = "top",
-   .fg   = "red",
-   .bg   = "default",
+   .colors   = "red, default",
},
{
.colorset = HE_COLORSET_MEDIUM,
.name = "medium",
-   .fg   = "green",
-   .bg   = "default",
+   .colors   = "green, default",
},
{
.colorset = HE_COLORSET_NORMAL,
.name = "normal",
-   .fg   = "default",
-   .bg   = "default",
+   .colors   = "default, default",
},
{
.colorset = HE_COLORSET_SELECTED,
.name = "selected",
-   .fg   = "black",
-   .bg   = "yellow",
+   .colors   = "black, yellow",
},
{
.colorset = HE_COLORSET_JUMP_ARROWS,
.name = "jump_arrows",
-   .fg   = "blue",
-   .bg   = "default",
+   .colors   = "blue, default",
},
{
.colorset = HE_COLORSET_ADDR,
.name = "addr",
-   .fg   = "magenta",
-   .bg   = "default",
+   .colors   = "magenta, default",
},
{
.colorset = HE_COLORSET_ROOT,
.name = "root",
-   .fg   = "white",
-   .bg   = "blue",
+   .colors   = "white, blue",
},
{
.name = NULL,
}
 };

-
 static int ui_browser__color_config(const char *var, const char *value,
void *data __maybe_unused)
 {
-   char *fg = NULL, *bg;
+   char *colors;
int i;

/* same dir for all commands */
@@ -570,22 +562,18 @@ static int ui_browser__color_config(const char *var, 
const char *value,
if (strcmp(ui_browser__colorsets[i].name, name) != 0)
continue;

-   fg = strdup(value);
-   if (fg == NULL)
-   break;
+   if (strstr(value, ",") == NULL)
+   return -1;

-   bg = strchr(fg, ',');
-   if (bg == NULL)
+   colors = strdup(value);
+   if (colors == NULL)
break;
+   ui_browser__colorsets[i].colors = colors;

-   *bg = '\0';
-   while (isspace(*++bg));
-   ui_browser__colorsets[i].bg = bg;
-   ui_browser__colorsets[i].fg = fg;
return 0;
}

-   free(fg);
+   free(colors);
return -1;
 }

@@ -743,8 +731,17 @@ void ui_browser__init(void)
perf_config(ui_browser__color_config, NULL);

while (ui_browser__colorsets[i].name) {
+   char *colors, *fg, *bg;
struct ui_browser_colorset *c = _browser__colorsets[i++];
-   sltt_set_color(c->colorset, c->name, c->fg, c->bg);
+
+   colors = strdup(c->colors);
+   if (fg == NULL)


Huh? At this point fb is not even initialized


Sorry for my mistake.
I'll change 'fg' to 'colors' to handle a exception
of strdup().

Thanks,
Taeung



+   break;
+   fg = strtok(colors, ",");
+   bg = strtok(NULL, ",");
+   bg = ltrim(bg);
+   sltt_set_color(c->colorset, 

Re: [PATCH v6 RESEND 4/7] perf config: Use combined {fore,back}ground colors value instead of each two color

[Taeung Song]

Hi, Arnaldo :)

On 08/09/2016 03:58 AM, Arnaldo Carvalho de Melo wrote:

Em Tue, Aug 02, 2016 at 06:20:46PM +0900, Taeung Song escreveu:

To easily set default config values into actual variables for 'colors' config,
it would be better that actual variables for each 'colors' config
also have only one value like 'default_config_item' type.

If we use combined {fore,back}ground colors values in ui_browser_colorset,
it smoothly work to initialize default config values for 'colors' config
by 'colors_config_items' array that contains default values for it at 
util/config.c.
because both actual variable and config item of 'colors_config_items'
are equal in the number of values (as just one).

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Wang Nan 
Signed-off-by: Taeung Song 
---
 tools/perf/ui/browser.c | 53 +++--
 1 file changed, 25 insertions(+), 28 deletions(-)

diff --git a/tools/perf/ui/browser.c b/tools/perf/ui/browser.c
index 3eb3edb..31e2028 100644
--- a/tools/perf/ui/browser.c
+++ b/tools/perf/ui/browser.c
@@ -503,61 +503,53 @@ unsigned int ui_browser__list_head_refresh(struct 
ui_browser *browser)
 }

 static struct ui_browser_colorset {
-   const char *name, *fg, *bg;
+   const char *name, *colors;
int colorset;
 } ui_browser__colorsets[] = {
{
.colorset = HE_COLORSET_TOP,
.name = "top",
-   .fg   = "red",
-   .bg   = "default",
+   .colors   = "red, default",
},
{
.colorset = HE_COLORSET_MEDIUM,
.name = "medium",
-   .fg   = "green",
-   .bg   = "default",
+   .colors   = "green, default",
},
{
.colorset = HE_COLORSET_NORMAL,
.name = "normal",
-   .fg   = "default",
-   .bg   = "default",
+   .colors   = "default, default",
},
{
.colorset = HE_COLORSET_SELECTED,
.name = "selected",
-   .fg   = "black",
-   .bg   = "yellow",
+   .colors   = "black, yellow",
},
{
.colorset = HE_COLORSET_JUMP_ARROWS,
.name = "jump_arrows",
-   .fg   = "blue",
-   .bg   = "default",
+   .colors   = "blue, default",
},
{
.colorset = HE_COLORSET_ADDR,
.name = "addr",
-   .fg   = "magenta",
-   .bg   = "default",
+   .colors   = "magenta, default",
},
{
.colorset = HE_COLORSET_ROOT,
.name = "root",
-   .fg   = "white",
-   .bg   = "blue",
+   .colors   = "white, blue",
},
{
.name = NULL,
}
 };

-
 static int ui_browser__color_config(const char *var, const char *value,
void *data __maybe_unused)
 {
-   char *fg = NULL, *bg;
+   char *colors;
int i;

/* same dir for all commands */
@@ -570,22 +562,18 @@ static int ui_browser__color_config(const char *var, 
const char *value,
if (strcmp(ui_browser__colorsets[i].name, name) != 0)
continue;

-   fg = strdup(value);
-   if (fg == NULL)
-   break;
+   if (strstr(value, ",") == NULL)
+   return -1;

-   bg = strchr(fg, ',');
-   if (bg == NULL)
+   colors = strdup(value);
+   if (colors == NULL)
break;
+   ui_browser__colorsets[i].colors = colors;

-   *bg = '\0';
-   while (isspace(*++bg));
-   ui_browser__colorsets[i].bg = bg;
-   ui_browser__colorsets[i].fg = fg;
return 0;
}

-   free(fg);
+   free(colors);
return -1;
 }

@@ -743,8 +731,17 @@ void ui_browser__init(void)
perf_config(ui_browser__color_config, NULL);

while (ui_browser__colorsets[i].name) {
+   char *colors, *fg, *bg;
struct ui_browser_colorset *c = _browser__colorsets[i++];
-   sltt_set_color(c->colorset, c->name, c->fg, c->bg);
+
+   colors = strdup(c->colors);
+   if (fg == NULL)


Huh? At this point fb is not even initialized


Sorry for my mistake.
I'll change 'fg' to 'colors' to handle a exception
of strdup().

Thanks,
Taeung



+   break;
+   fg = strtok(colors, ",");
+   bg = strtok(NULL, ",");
+   bg = ltrim(bg);
+   sltt_set_color(c->colorset, c->name, fg, bg);
+   free(colors);
}

annotate_browser__init();
--
2.5.0

Клиентские базы Email: bawupecoda-3...@yopmail.com Skype: prodawez389 Запросите подробности сейчас Если интересно Благодарим за быстрый ответ!

[128]

Соберем для Вас по интернет базу данных 
потенциальных клиентов для Вашего Бизнеса!
В базе будут все контактные данные необходимые 
для массовой продажи Ваших товаров и услуг.
По Вашему запросу пришлем пример и подробную информацию.
Если интересно запросите подробности сейчас 
Email: bawupecoda-3...@yopmail.com
Skype: prodawez389
Благодарим за быстрый ответ!

Клиентские базы Email: bawupecoda-3...@yopmail.com Skype: prodawez389 Запросите подробности сейчас Если интересно Благодарим за быстрый ответ!

[128]

Соберем для Вас по интернет базу данных 
потенциальных клиентов для Вашего Бизнеса!
В базе будут все контактные данные необходимые 
для массовой продажи Ваших товаров и услуг.
По Вашему запросу пришлем пример и подробную информацию.
Если интересно запросите подробности сейчас 
Email: bawupecoda-3...@yopmail.com
Skype: prodawez389
Благодарим за быстрый ответ!

Re: Filesystem slow write performance

[Babu Moger]

I wasn't able to repro this with mainline. Sorry for the noise.

On 8/6/2016 1:49 PM, Babu Moger wrote:

Hi,

Seeing some terrible write performance with ext3/4 writes.  Reads are 
fine.


I have a created loop device and mounted as ext3(tried ext4 also).

Here is iostat output. await time is pretty high most of the time.

Device: rrqm/s   wrqm/s r/s w/s   rsec/s   wsec/s 
avgrq-sz avgqu-sz   await  svctm  %util
loop0 0.00 0.000.00  133.00 0.00 1064.00 
8.00   124.14  835.61   7.52 100.00
dm-0  0.00 0.000.00  132.00 0.00 1056.00 
8.00 1.007.52   7.52  99.20


Device: rrqm/s   wrqm/s r/s w/s   rsec/s   wsec/s 
avgrq-sz avgqu-sz   await  svctm  %util
loop0 0.00 0.000.00   94.00 0.00 752.00 
8.00   124.18  901.02  10.64 100.00
dm-0  0.00 0.000.00   92.00 0.00 736.00 
8.00 1.02   11.09  10.87 100.00


Device: rrqm/s   wrqm/s r/s w/s   rsec/s   wsec/s 
avgrq-sz avgqu-sz   await  svctm  %util
loop0 0.00 0.000.00  132.00 0.00 1056.00 
8.00   124.56 1329.30   7.58 100.00
dm-0  0.00 0.000.00  141.00 0.00 1128.00 
8.00 1.087.72   7.06  99.60


Tags output
[root@build-t7 0]# cat tags
nr_tags=128, reserved_tags=0, bits_per_word=5
nr_free=128, nr_reserved=0
active_queues=0

Here is the output of  "echo w > /proc/sysrq-trigger" when the problem 
happens.


Aug  3 12:18:55 build-t7 kernel: kworker/u512:0  D 
009defd4 0 6  2 0x0600
Aug  3 12:18:55 build-t7 kernel: Workqueue: writeback 
bdi_writeback_workfn (flush-7:0)

Aug  3 12:18:55 build-t7 kernel: Call Trace:
Aug  3 12:18:55 build-t7 kernel: [009dc9e4] schedule+0x24/0xa0
Aug  3 12:18:55 build-t7 kernel: [009defd4] 
schedule_timeout+0x134/0x220
Aug  3 12:18:55 build-t7 kernel: [009dc044] 
io_schedule_timeout+0x84/0x100

Aug  3 12:18:55 build-t7 kernel: [006be64c] bt_get+0x10c/0x1e0
Aug  3 12:18:55 build-t7 kernel: [006be7f4] 
blk_mq_get_tag+0x74/0xe0
Aug  3 12:18:55 build-t7 kernel: [006ba570] 
__blk_mq_alloc_request+0x10/0x180
Aug  3 12:18:55 build-t7 kernel: [006bb9f4] 
blk_mq_map_request+0x1d4/0x260
Aug  3 12:18:55 build-t7 kernel: [006bbd40] 
blk_sq_make_request+0x60/0x300
Aug  3 12:18:55 build-t7 kernel: [006afa58] 
generic_make_request+0x78/0xe0

Aug  3 12:18:55 build-t7 kernel: [006afb44] submit_bio+0x84/0x160
Aug  3 12:18:55 build-t7 kernel: [005f7cb4] 
_submit_bh+0x174/0x200

Aug  3 12:18:55 build-t7 kernel: [005f7d54] submit_bh+0x14/0x40
Aug  3 12:18:55 build-t7 kernel: [005fc248] 
__block_write_full_page.clone.0+0x2c8/0x500
Aug  3 12:18:55 build-t7 kernel: [005fc620] 
block_write_full_page+0xa0/0xe0
Aug  3 12:18:55 build-t7 kernel: [100e7d94] 
ext3_writeback_writepage+0x134/0x200 [ext3]

Aug  3 12:18:55 build-t7 kernel: [00562798] __writepage+0x18/0x60

Aug  3 12:18:55 build-t7 kernel: loop0   D 
009deff4 0 15632  2 0x01000400

Aug  3 12:18:55 build-t7 kernel: Call Trace:
Aug  3 12:18:55 build-t7 kernel: [009dc9e4] schedule+0x24/0xa0
Aug  3 12:18:55 build-t7 kernel: [009deff4] 
schedule_timeout+0x154/0x220
Aug  3 12:18:55 build-t7 kernel: [009dc044] 
io_schedule_timeout+0x84/0x100

Aug  3 12:18:55 build-t7 kernel: [009dcdbc] bit_wait_io+0x3c/0x80
Aug  3 12:18:55 build-t7 kernel: [009dd1c4] 
__wait_on_bit+0x84/0x100
Aug  3 12:18:55 build-t7 kernel: [0055719c] 
wait_on_page_bit+0x7c/0xa0
Aug  3 12:18:55 build-t7 kernel: [005586a8] 
filemap_fdatawait_range+0xc8/0x140
Aug  3 12:18:55 build-t7 kernel: [005587fc] 
filemap_write_and_wait_range+0x3c/0x80
Aug  3 12:18:55 build-t7 kernel: [00558a58] 
__generic_file_write_iter+0xb8/0x140
Aug  3 12:18:55 build-t7 kernel: [00558bac] 
generic_file_write_iter+0xcc/0x1e0

Aug  3 12:18:55 build-t7 kernel: [007ca000] lo_rw_aio+0x180/0x240
Aug  3 12:18:55 build-t7 kernel: [007ca260] 
do_req_filebacked+0x1a0/0x1c0
Aug  3 12:18:55 build-t7 kernel: [007ca2b4] 
loop_queue_work+0x34/0x80
Aug  3 12:18:55 build-t7 kernel: [00491944] 
kthread_worker_fn+0x44/0x180

Aug  3 12:18:55 build-t7 kernel: [00491c4c] kthread+0xac/0xe0
Aug  3 12:18:55 build-t7 kernel: [00406184] 
ret_from_fork+0x1c/0x2c


Aug  3 12:18:55 build-t7 kernel: livecd-creator  D 
009deff4 0 15627   2676 0x308000103000400

Aug  3 12:18:55 build-t7 kernel: Call Trace:
Aug  3 12:18:55 build-t7 kernel: [009dc9e4] schedule+0x24/0xa0
Aug  3 12:18:55 build-t7 kernel: [009deff4] 
schedule_timeout+0x154/0x220
Aug  3 12:18:55 build-t7 kernel: [009dc044] 
io_schedule_timeout+0x84/0x100

Aug  3 12:18:55 build-t7 kernel: [009dcdbc] bit_wait_io+0x3c/0x80
Aug  3 12:18:55 build-t7 kernel: [009dd1c4] 

Re: Filesystem slow write performance

[Babu Moger]

I wasn't able to repro this with mainline. Sorry for the noise.

On 8/6/2016 1:49 PM, Babu Moger wrote:

Hi,

Seeing some terrible write performance with ext3/4 writes.  Reads are 
fine.


I have a created loop device and mounted as ext3(tried ext4 also).

Here is iostat output. await time is pretty high most of the time.

Device: rrqm/s   wrqm/s r/s w/s   rsec/s   wsec/s 
avgrq-sz avgqu-sz   await  svctm  %util
loop0 0.00 0.000.00  133.00 0.00 1064.00 
8.00   124.14  835.61   7.52 100.00
dm-0  0.00 0.000.00  132.00 0.00 1056.00 
8.00 1.007.52   7.52  99.20


Device: rrqm/s   wrqm/s r/s w/s   rsec/s   wsec/s 
avgrq-sz avgqu-sz   await  svctm  %util
loop0 0.00 0.000.00   94.00 0.00 752.00 
8.00   124.18  901.02  10.64 100.00
dm-0  0.00 0.000.00   92.00 0.00 736.00 
8.00 1.02   11.09  10.87 100.00


Device: rrqm/s   wrqm/s r/s w/s   rsec/s   wsec/s 
avgrq-sz avgqu-sz   await  svctm  %util
loop0 0.00 0.000.00  132.00 0.00 1056.00 
8.00   124.56 1329.30   7.58 100.00
dm-0  0.00 0.000.00  141.00 0.00 1128.00 
8.00 1.087.72   7.06  99.60


Tags output
[root@build-t7 0]# cat tags
nr_tags=128, reserved_tags=0, bits_per_word=5
nr_free=128, nr_reserved=0
active_queues=0

Here is the output of  "echo w > /proc/sysrq-trigger" when the problem 
happens.


Aug  3 12:18:55 build-t7 kernel: kworker/u512:0  D 
009defd4 0 6  2 0x0600
Aug  3 12:18:55 build-t7 kernel: Workqueue: writeback 
bdi_writeback_workfn (flush-7:0)

Aug  3 12:18:55 build-t7 kernel: Call Trace:
Aug  3 12:18:55 build-t7 kernel: [009dc9e4] schedule+0x24/0xa0
Aug  3 12:18:55 build-t7 kernel: [009defd4] 
schedule_timeout+0x134/0x220
Aug  3 12:18:55 build-t7 kernel: [009dc044] 
io_schedule_timeout+0x84/0x100

Aug  3 12:18:55 build-t7 kernel: [006be64c] bt_get+0x10c/0x1e0
Aug  3 12:18:55 build-t7 kernel: [006be7f4] 
blk_mq_get_tag+0x74/0xe0
Aug  3 12:18:55 build-t7 kernel: [006ba570] 
__blk_mq_alloc_request+0x10/0x180
Aug  3 12:18:55 build-t7 kernel: [006bb9f4] 
blk_mq_map_request+0x1d4/0x260
Aug  3 12:18:55 build-t7 kernel: [006bbd40] 
blk_sq_make_request+0x60/0x300
Aug  3 12:18:55 build-t7 kernel: [006afa58] 
generic_make_request+0x78/0xe0

Aug  3 12:18:55 build-t7 kernel: [006afb44] submit_bio+0x84/0x160
Aug  3 12:18:55 build-t7 kernel: [005f7cb4] 
_submit_bh+0x174/0x200

Aug  3 12:18:55 build-t7 kernel: [005f7d54] submit_bh+0x14/0x40
Aug  3 12:18:55 build-t7 kernel: [005fc248] 
__block_write_full_page.clone.0+0x2c8/0x500
Aug  3 12:18:55 build-t7 kernel: [005fc620] 
block_write_full_page+0xa0/0xe0
Aug  3 12:18:55 build-t7 kernel: [100e7d94] 
ext3_writeback_writepage+0x134/0x200 [ext3]

Aug  3 12:18:55 build-t7 kernel: [00562798] __writepage+0x18/0x60

Aug  3 12:18:55 build-t7 kernel: loop0   D 
009deff4 0 15632  2 0x01000400

Aug  3 12:18:55 build-t7 kernel: Call Trace:
Aug  3 12:18:55 build-t7 kernel: [009dc9e4] schedule+0x24/0xa0
Aug  3 12:18:55 build-t7 kernel: [009deff4] 
schedule_timeout+0x154/0x220
Aug  3 12:18:55 build-t7 kernel: [009dc044] 
io_schedule_timeout+0x84/0x100

Aug  3 12:18:55 build-t7 kernel: [009dcdbc] bit_wait_io+0x3c/0x80
Aug  3 12:18:55 build-t7 kernel: [009dd1c4] 
__wait_on_bit+0x84/0x100
Aug  3 12:18:55 build-t7 kernel: [0055719c] 
wait_on_page_bit+0x7c/0xa0
Aug  3 12:18:55 build-t7 kernel: [005586a8] 
filemap_fdatawait_range+0xc8/0x140
Aug  3 12:18:55 build-t7 kernel: [005587fc] 
filemap_write_and_wait_range+0x3c/0x80
Aug  3 12:18:55 build-t7 kernel: [00558a58] 
__generic_file_write_iter+0xb8/0x140
Aug  3 12:18:55 build-t7 kernel: [00558bac] 
generic_file_write_iter+0xcc/0x1e0

Aug  3 12:18:55 build-t7 kernel: [007ca000] lo_rw_aio+0x180/0x240
Aug  3 12:18:55 build-t7 kernel: [007ca260] 
do_req_filebacked+0x1a0/0x1c0
Aug  3 12:18:55 build-t7 kernel: [007ca2b4] 
loop_queue_work+0x34/0x80
Aug  3 12:18:55 build-t7 kernel: [00491944] 
kthread_worker_fn+0x44/0x180

Aug  3 12:18:55 build-t7 kernel: [00491c4c] kthread+0xac/0xe0
Aug  3 12:18:55 build-t7 kernel: [00406184] 
ret_from_fork+0x1c/0x2c


Aug  3 12:18:55 build-t7 kernel: livecd-creator  D 
009deff4 0 15627   2676 0x308000103000400

Aug  3 12:18:55 build-t7 kernel: Call Trace:
Aug  3 12:18:55 build-t7 kernel: [009dc9e4] schedule+0x24/0xa0
Aug  3 12:18:55 build-t7 kernel: [009deff4] 
schedule_timeout+0x154/0x220
Aug  3 12:18:55 build-t7 kernel: [009dc044] 
io_schedule_timeout+0x84/0x100

Aug  3 12:18:55 build-t7 kernel: [009dcdbc] bit_wait_io+0x3c/0x80
Aug  3 12:18:55 build-t7 kernel: [009dd1c4] 

Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons

[John Stultz]

On Mon, Aug 8, 2016 at 2:31 AM, Jon Hunter  wrote:
>
> On 06/08/16 00:45, John Stultz wrote:
>> On Mon, Aug 1, 2016 at 3:26 AM, Jon Hunter  wrote:
>>> Hi John,
>>>
>>> On 30/07/16 05:39, John Stultz wrote:
 Hey Jon,
   So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
 noticed the power/volume buttons stopped working.

 I did a manual rebased bisection and chased it down to your commit
 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ").

 Reverting that patch makes things work again, so I wanted to see if
 there was any debugging info I could provide to try to help narrow
 down the problem here. (Sorry, I'd tinker myself with it some and try
 to debug the issue, but after burning my friday night on this, I'm
 eager to get away from the keyboard for the weekend).
>>>
>>> Before this commit bad IRQ type settings in device-tree were not getting
>>> reported and so failures to set the IRQ type were going unnoticed. It's
>>> most likely a bad IRQ type settings somewhere.
>>>
>>> As Thomas mentioned hopefully dmesg will shed a bit more light.
>>>
>>> Otherwise it can be worth looking at the ->irq_set_type() function for
>>> the irqchips in the path of the interrupt requested to see if any are
>>> failing. Looking at the nexus7 (assuming qcom variant), it looks like
>>> there are 3 irqchips in the path (pm8921 --> apq8064-pinctrl --> gic).
>>> The pm8xxx_irq_set_type() could return a failure when setting up the IRQ
>>> type and could be worth checking. It does not look like the set_type for
>>> the apq8064-pinctrl should ever fail (apart from calling BUG() which
>>> would be obvious). The gic can also return a failure for setting the
>>> type, but I did not see anything at first glance that looks incorrect in
>>> the dts.
>>>
>>> If we can narrow down irqchip, then hopefully it will be clearer.
>>
>> The pm_8xxx_irq_set_type doesn't seem to be failing as far as I can see..
>>
>> Looking at the patch that seems to cause the trouble, I narrowed it
>> down to just the following chunk:
>>
>> @@ -614,7 +615,11 @@ unsigned int irq_create_fwspec_mapping(struct
>> irq_fwspec *fwspec)
>>  * it now and return the interrupt number.
>>  */
>> if (irq_get_trigger_type(virq) == IRQ_TYPE_NONE) {
>> -   irq_set_irq_type(virq, type);
>> +   irq_data = irq_get_irq_data(virq);
>> +   if (!irq_data)
>> +   return 0;
>> +
>> +   irqd_set_trigger_type(irq_data, type);
>> return virq;
>> }
>>
>> If I revert just that, it works again.
>>
>> I was worried we were hitting an early failure from !irq_data, but it
>> seems there's some subtle difference between irqd_set_trigger_type and
>> irq_set_type that makes the former break for me.
>
> Thanks this is good info and at the same time odd.
>
> I am guessing that it is failing above because the irq_data is not found
> for the irq?

So actually no. We usually call irqd_set_trigger_type() but something
still doesn't work.

Interestingly, just adding irq_set_irq_type(virq, type); to the top of
that block (leaving the rest of the code) also works.

> What is odd, is that the above sequence is only executed if a irq
> mapping exists and so really, AFAICT this should not happen. Ie. the irq
> descriptor should have been allocated for the mapping to exist. We
> should probably warn if this happens.
>
> Without reverting the above, can you add a print to show the
> domain->name, hwirq and virq information if !irq_data? That will confirm
> the domain for us.

So I put some printk info in (in either case since I'm never seeing
the !irq_data case happen):

[1.514217] JDB: virq: 93  hwirq: 74 domain name: msmgpio
[1.838342] JDB: virq: 25  hwirq: 6 domain name: msmgpio

Which is odd, looking at:

shell@flo:/ $ cat /proc/interrupts
   CPU0   CPU1   CPU2   CPU3
 16:   1159   1138   1332   1574 GIC-0  18 Edge
  gp_timer
 25:  0  0  0  0   msmgpio   6 Edge
  ekth3500
111:  6  0  0  0 GIC-0  51 Edge
  qcom_rpm_ack
112:  0  0  0  0 GIC-0  53 Edge
  qcom_rpm_err
113:  0  0  0  0 GIC-0  54 Edge
  qcom_rpm_wakeup
114: 48  0  0  0 GIC-0 132 Edge
  msm_otg, ci_hdrc_msm
115:796  0  0  0 GIC-0 130 Level bam_dma
116:  0  0  0  0 GIC-0 128 Level bam_dma
117:  0  0  0  0 GIC-0 127 Level bam_dma
118:   2627  0  0  0 GIC-0 136 Level
  mmci-pl18x (cmd)
119: 54  0  0  0 GIC-0 226 Level i2c_qup
120:   

Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons

[John Stultz]

On Mon, Aug 8, 2016 at 2:31 AM, Jon Hunter  wrote:
>
> On 06/08/16 00:45, John Stultz wrote:
>> On Mon, Aug 1, 2016 at 3:26 AM, Jon Hunter  wrote:
>>> Hi John,
>>>
>>> On 30/07/16 05:39, John Stultz wrote:
 Hey Jon,
   So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
 noticed the power/volume buttons stopped working.

 I did a manual rebased bisection and chased it down to your commit
 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ").

 Reverting that patch makes things work again, so I wanted to see if
 there was any debugging info I could provide to try to help narrow
 down the problem here. (Sorry, I'd tinker myself with it some and try
 to debug the issue, but after burning my friday night on this, I'm
 eager to get away from the keyboard for the weekend).
>>>
>>> Before this commit bad IRQ type settings in device-tree were not getting
>>> reported and so failures to set the IRQ type were going unnoticed. It's
>>> most likely a bad IRQ type settings somewhere.
>>>
>>> As Thomas mentioned hopefully dmesg will shed a bit more light.
>>>
>>> Otherwise it can be worth looking at the ->irq_set_type() function for
>>> the irqchips in the path of the interrupt requested to see if any are
>>> failing. Looking at the nexus7 (assuming qcom variant), it looks like
>>> there are 3 irqchips in the path (pm8921 --> apq8064-pinctrl --> gic).
>>> The pm8xxx_irq_set_type() could return a failure when setting up the IRQ
>>> type and could be worth checking. It does not look like the set_type for
>>> the apq8064-pinctrl should ever fail (apart from calling BUG() which
>>> would be obvious). The gic can also return a failure for setting the
>>> type, but I did not see anything at first glance that looks incorrect in
>>> the dts.
>>>
>>> If we can narrow down irqchip, then hopefully it will be clearer.
>>
>> The pm_8xxx_irq_set_type doesn't seem to be failing as far as I can see..
>>
>> Looking at the patch that seems to cause the trouble, I narrowed it
>> down to just the following chunk:
>>
>> @@ -614,7 +615,11 @@ unsigned int irq_create_fwspec_mapping(struct
>> irq_fwspec *fwspec)
>>  * it now and return the interrupt number.
>>  */
>> if (irq_get_trigger_type(virq) == IRQ_TYPE_NONE) {
>> -   irq_set_irq_type(virq, type);
>> +   irq_data = irq_get_irq_data(virq);
>> +   if (!irq_data)
>> +   return 0;
>> +
>> +   irqd_set_trigger_type(irq_data, type);
>> return virq;
>> }
>>
>> If I revert just that, it works again.
>>
>> I was worried we were hitting an early failure from !irq_data, but it
>> seems there's some subtle difference between irqd_set_trigger_type and
>> irq_set_type that makes the former break for me.
>
> Thanks this is good info and at the same time odd.
>
> I am guessing that it is failing above because the irq_data is not found
> for the irq?

So actually no. We usually call irqd_set_trigger_type() but something
still doesn't work.

Interestingly, just adding irq_set_irq_type(virq, type); to the top of
that block (leaving the rest of the code) also works.

> What is odd, is that the above sequence is only executed if a irq
> mapping exists and so really, AFAICT this should not happen. Ie. the irq
> descriptor should have been allocated for the mapping to exist. We
> should probably warn if this happens.
>
> Without reverting the above, can you add a print to show the
> domain->name, hwirq and virq information if !irq_data? That will confirm
> the domain for us.

So I put some printk info in (in either case since I'm never seeing
the !irq_data case happen):

[1.514217] JDB: virq: 93  hwirq: 74 domain name: msmgpio
[1.838342] JDB: virq: 25  hwirq: 6 domain name: msmgpio

Which is odd, looking at:

shell@flo:/ $ cat /proc/interrupts
   CPU0   CPU1   CPU2   CPU3
 16:   1159   1138   1332   1574 GIC-0  18 Edge
  gp_timer
 25:  0  0  0  0   msmgpio   6 Edge
  ekth3500
111:  6  0  0  0 GIC-0  51 Edge
  qcom_rpm_ack
112:  0  0  0  0 GIC-0  53 Edge
  qcom_rpm_err
113:  0  0  0  0 GIC-0  54 Edge
  qcom_rpm_wakeup
114: 48  0  0  0 GIC-0 132 Edge
  msm_otg, ci_hdrc_msm
115:796  0  0  0 GIC-0 130 Level bam_dma
116:  0  0  0  0 GIC-0 128 Level bam_dma
117:  0  0  0  0 GIC-0 127 Level bam_dma
118:   2627  0  0  0 GIC-0 136 Level
  mmci-pl18x (cmd)
119: 54  0  0  0 GIC-0 226 Level i2c_qup
120: 21  0  0  0 

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

[Guenter Roeck]

On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.4.17 release.
There are 68 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Aug 10 18:01:56 UTC 2016.
Anything received after that time might be too late.



Build results:
total: 148 pass: 146 fail: 2
Failed builds:
arm:allmodconfig
arm64:allmodconfig

Qemu test results:
total: 101 pass: 99 fail: 2
Failed tests:
arm64:smp:defconfig
arm64:nosmp:defconfig

Common build error:

drivers/i2c/busses/i2c-qup.c: In function 'qup_i2c_read_one':
drivers/i2c/busses/i2c-qup.c:438:2: error: 'idx' undeclared

Culprit: ae5451257fc2 ("i2c: qup: Fix wrong value of index variable")

Guenter

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

[Guenter Roeck]

On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.4.17 release.
There are 68 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Aug 10 18:01:56 UTC 2016.
Anything received after that time might be too late.



Build results:
total: 148 pass: 146 fail: 2
Failed builds:
arm:allmodconfig
arm64:allmodconfig

Qemu test results:
total: 101 pass: 99 fail: 2
Failed tests:
arm64:smp:defconfig
arm64:nosmp:defconfig

Common build error:

drivers/i2c/busses/i2c-qup.c: In function 'qup_i2c_read_one':
drivers/i2c/busses/i2c-qup.c:438:2: error: 'idx' undeclared

Culprit: ae5451257fc2 ("i2c: qup: Fix wrong value of index variable")

Guenter

Re: [PATCH 3.14 00/21] 3.14.75-stable review

[Guenter Roeck]

On 08/08/2016 12:09 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.14.75 release.
There are 21 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Aug 10 18:01:28 UTC 2016.
Anything received after that time might be too late.



Build results:
total: 131 pass: 131 fail: 0
Qemu test results:
total: 89 pass: 89 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 3.14 00/21] 3.14.75-stable review

[Guenter Roeck]

On 08/08/2016 12:09 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.14.75 release.
There are 21 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Aug 10 18:01:28 UTC 2016.
Anything received after that time might be too late.



Build results:
total: 131 pass: 131 fail: 0
Qemu test results:
total: 89 pass: 89 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

[H. Peter Anvin]

On August 8, 2016 9:01:42 PM PDT, Borislav Petkov  wrote:
>On Mon, Aug 08, 2016 at 11:40:07AM -0700, Thomas Garnier wrote:
>> Default implementation expects 6 pages maximum are needed for low
>page
>> allocations. If KASLR memory randomization is enabled, the worse case
>> of e820 layout would require 12 pages (no large pages). It is due to
>the
>> PUD level randomization and the variable e820 memory layout.
>
>Can't this number of required pages be computed based on the
>randomization offset or somesuch instead of maxing it out by default on
>every machine which enables CONFIG_RANDOMIZE_MEMORY?
>
>> This bug was found while doing extensive testing of KASLR memory
>> randomization on different type of hardware.
>> 
>> Signed-off-by: Thomas Garnier 
>> ---
>> Based on next-20160805
>> ---
>>  arch/x86/mm/init.c | 8 
>>  1 file changed, 8 insertions(+)
>> 
>> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
>> index 6209289..3a27e6a 100644
>> --- a/arch/x86/mm/init.c
>> +++ b/arch/x86/mm/init.c
>> @@ -130,6 +130,14 @@ void  __init early_alloc_pgt_buf(void)
>>  unsigned long tables = INIT_PGT_BUF_SIZE;
>>  phys_addr_t base;
>>  
>> +/*
>> + * Depending on the machine e860 memory layout and the PUD
>alignement.
>
>   e820   alignment
>
>> + * We may need twice more pages when KASLR memoy randomization is
>
> memory
>
>> + * enabled.
>> + */
>> +if (IS_ENABLED(CONFIG_RANDOMIZE_MEMORY))
>> +tables *= 2;
>> +
>>  base = __pa(extend_brk(tables, PAGE_SIZE));
>>  
>>  pgt_buf_start = base >> PAGE_SHIFT;
>> -- 
>> 2.8.0.rc3.226.g39d4020
>> 

Upping the brk by a few pages is not a big deal.  Unused brk gets reclaimed at 
init release time.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

[H. Peter Anvin]

On August 8, 2016 9:01:42 PM PDT, Borislav Petkov  wrote:
>On Mon, Aug 08, 2016 at 11:40:07AM -0700, Thomas Garnier wrote:
>> Default implementation expects 6 pages maximum are needed for low
>page
>> allocations. If KASLR memory randomization is enabled, the worse case
>> of e820 layout would require 12 pages (no large pages). It is due to
>the
>> PUD level randomization and the variable e820 memory layout.
>
>Can't this number of required pages be computed based on the
>randomization offset or somesuch instead of maxing it out by default on
>every machine which enables CONFIG_RANDOMIZE_MEMORY?
>
>> This bug was found while doing extensive testing of KASLR memory
>> randomization on different type of hardware.
>> 
>> Signed-off-by: Thomas Garnier 
>> ---
>> Based on next-20160805
>> ---
>>  arch/x86/mm/init.c | 8 
>>  1 file changed, 8 insertions(+)
>> 
>> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
>> index 6209289..3a27e6a 100644
>> --- a/arch/x86/mm/init.c
>> +++ b/arch/x86/mm/init.c
>> @@ -130,6 +130,14 @@ void  __init early_alloc_pgt_buf(void)
>>  unsigned long tables = INIT_PGT_BUF_SIZE;
>>  phys_addr_t base;
>>  
>> +/*
>> + * Depending on the machine e860 memory layout and the PUD
>alignement.
>
>   e820   alignment
>
>> + * We may need twice more pages when KASLR memoy randomization is
>
> memory
>
>> + * enabled.
>> + */
>> +if (IS_ENABLED(CONFIG_RANDOMIZE_MEMORY))
>> +tables *= 2;
>> +
>>  base = __pa(extend_brk(tables, PAGE_SIZE));
>>  
>>  pgt_buf_start = base >> PAGE_SHIFT;
>> -- 
>> 2.8.0.rc3.226.g39d4020
>> 

Upping the brk by a few pages is not a big deal.  Unused brk gets reclaimed at 
init release time.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

[Borislav Petkov]

On Mon, Aug 08, 2016 at 11:40:07AM -0700, Thomas Garnier wrote:
> Default implementation expects 6 pages maximum are needed for low page
> allocations. If KASLR memory randomization is enabled, the worse case
> of e820 layout would require 12 pages (no large pages). It is due to the
> PUD level randomization and the variable e820 memory layout.

Can't this number of required pages be computed based on the
randomization offset or somesuch instead of maxing it out by default on
every machine which enables CONFIG_RANDOMIZE_MEMORY?

> This bug was found while doing extensive testing of KASLR memory
> randomization on different type of hardware.
> 
> Signed-off-by: Thomas Garnier 
> ---
> Based on next-20160805
> ---
>  arch/x86/mm/init.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index 6209289..3a27e6a 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -130,6 +130,14 @@ void  __init early_alloc_pgt_buf(void)
>   unsigned long tables = INIT_PGT_BUF_SIZE;
>   phys_addr_t base;
>  
> + /*
> +  * Depending on the machine e860 memory layout and the PUD alignement.

e820   alignment

> +  * We may need twice more pages when KASLR memoy randomization is

  memory

> +  * enabled.
> +  */
> + if (IS_ENABLED(CONFIG_RANDOMIZE_MEMORY))
> + tables *= 2;
> +
>   base = __pa(extend_brk(tables, PAGE_SIZE));
>  
>   pgt_buf_start = base >> PAGE_SHIFT;
> -- 
> 2.8.0.rc3.226.g39d4020
> 

-- 
Regards/Gruss,
Boris.

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

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

[Borislav Petkov]

On Mon, Aug 08, 2016 at 11:40:07AM -0700, Thomas Garnier wrote:
> Default implementation expects 6 pages maximum are needed for low page
> allocations. If KASLR memory randomization is enabled, the worse case
> of e820 layout would require 12 pages (no large pages). It is due to the
> PUD level randomization and the variable e820 memory layout.

Can't this number of required pages be computed based on the
randomization offset or somesuch instead of maxing it out by default on
every machine which enables CONFIG_RANDOMIZE_MEMORY?

> This bug was found while doing extensive testing of KASLR memory
> randomization on different type of hardware.
> 
> Signed-off-by: Thomas Garnier 
> ---
> Based on next-20160805
> ---
>  arch/x86/mm/init.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index 6209289..3a27e6a 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -130,6 +130,14 @@ void  __init early_alloc_pgt_buf(void)
>   unsigned long tables = INIT_PGT_BUF_SIZE;
>   phys_addr_t base;
>  
> + /*
> +  * Depending on the machine e860 memory layout and the PUD alignement.

e820   alignment

> +  * We may need twice more pages when KASLR memoy randomization is

  memory

> +  * enabled.
> +  */
> + if (IS_ENABLED(CONFIG_RANDOMIZE_MEMORY))
> + tables *= 2;
> +
>   base = __pa(extend_brk(tables, PAGE_SIZE));
>  
>   pgt_buf_start = base >> PAGE_SHIFT;
> -- 
> 2.8.0.rc3.226.g39d4020
> 

-- 
Regards/Gruss,
Boris.

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

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [PATCH 1/5] sched,time: Count actually elapsed irq & softirq time

[Wanpeng Li]

Hi Rik,
2016-07-13 22:50 GMT+08:00 Frederic Weisbecker :
> From: Rik van Riel 
>
> Currently, if there was any irq or softirq time during 'ticks'
> jiffies, the entire period will be accounted as irq or softirq
> time.
>
> This is inaccurate if only a subset of the time was actually spent
> handling irqs, and could conceivably mis-count all of the ticks during
> a period as irq time, when there was some irq and some softirq time.
>
> This can actually happen when irqtime_account_process_tick is called
> from account_idle_ticks, which can pass a larger number of ticks down
> all at once.
>
> Fix this by changing irqtime_account_hi_update, irqtime_account_si_update,
> and steal_account_process_ticks to work with cputime_t time units, and
> return the amount of time spent in each mode.

Do we need to minus st cputime from idle cputime in
account_idle_ticks() when noirqtime is true? I try to add this logic
w/ noirqtime and idle=poll boot parameter for a full dynticks guest,
however, there is no difference, where I miss?

Regards,
Wanpeng Li

Re: [PATCH 1/5] sched,time: Count actually elapsed irq & softirq time

[Wanpeng Li]

Hi Rik,
2016-07-13 22:50 GMT+08:00 Frederic Weisbecker :
> From: Rik van Riel 
>
> Currently, if there was any irq or softirq time during 'ticks'
> jiffies, the entire period will be accounted as irq or softirq
> time.
>
> This is inaccurate if only a subset of the time was actually spent
> handling irqs, and could conceivably mis-count all of the ticks during
> a period as irq time, when there was some irq and some softirq time.
>
> This can actually happen when irqtime_account_process_tick is called
> from account_idle_ticks, which can pass a larger number of ticks down
> all at once.
>
> Fix this by changing irqtime_account_hi_update, irqtime_account_si_update,
> and steal_account_process_ticks to work with cputime_t time units, and
> return the amount of time spent in each mode.

Do we need to minus st cputime from idle cputime in
account_idle_ticks() when noirqtime is true? I try to add this logic
w/ noirqtime and idle=poll boot parameter for a full dynticks guest,
however, there is no difference, where I miss?

Regards,
Wanpeng Li

linux-next: Tree for Aug 9

[Stephen Rothwell]

Hi all,

Changes since 20160808:

Linus' tree lost the build failure (this was actually an rdma tree
problem).

The sound-asoc tree lost its build failure.

Non-merge commits (relative to Linus' tree): 978
 965 files changed, 27099 insertions(+), 7759 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 (574673c231a5 printk: Remove unnecessary #ifdef 
CONFIG_PRINTK)
Merging fixes/master (04c1926cb1e1 Disable the Soft RoCE driver)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (bc921f821d60 ARC: Call trace_hardirqs_on() before 
enabling irqs)
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 (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (1fe323aa1b23 sctp: use event->chunk when it's valid)
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 (4d0bd46a4d55 Revert "wext: Fix 32 bit iwpriv 
compatibility issue with 64 bit Kernel")
Merging sound-current/for-linus (59ec4b57bcae ALSA: hda - Fix headset mic 
detection problem for two dell machines)
Merging pci-current/for-linus (29b4817d4018 Linux 4.8-rc1)
Merging driver-core.current/driver-core-linus (29b4817d4018 Linux 4.8-rc1)
Merging tty.current/tty-linus (29b4817d4018 Linux 4.8-rc1)
Merging usb.current/usb-linus (29b4817d4018 Linux 4.8-rc1)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (647024a7df36 USB: serial: fix memleak in 
driver-registration error path)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (29b4817d4018 Linux 4.8-rc1)
Merging char-misc.current/char-misc-linus (29b4817d4018 Linux 4.8-rc1)
Merging input-current/for-linus (22fe874f3803 Input: silead - remove some dead 
code)
Merging crypto-current/master (2fdea258fde0 crypto: caam - defer 
aead_set_sh_desc in case of zero authsize)
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 (c8952a707556 vfio/pci: Fix NULL pointer oops in 
error interrupt setup handling)
Merging kselftest-fixes/fixes (f80eb4289491 selftests/exec: Makefile is a 
run-time dependency, add it to the install list)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e bac

linux-next: Tree for Aug 9

[Stephen Rothwell]

Hi all,

Changes since 20160808:

Linus' tree lost the build failure (this was actually an rdma tree
problem).

The sound-asoc tree lost its build failure.

Non-merge commits (relative to Linus' tree): 978
 965 files changed, 27099 insertions(+), 7759 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 (574673c231a5 printk: Remove unnecessary #ifdef 
CONFIG_PRINTK)
Merging fixes/master (04c1926cb1e1 Disable the Soft RoCE driver)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (bc921f821d60 ARC: Call trace_hardirqs_on() before 
enabling irqs)
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 (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (1fe323aa1b23 sctp: use event->chunk when it's valid)
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 (4d0bd46a4d55 Revert "wext: Fix 32 bit iwpriv 
compatibility issue with 64 bit Kernel")
Merging sound-current/for-linus (59ec4b57bcae ALSA: hda - Fix headset mic 
detection problem for two dell machines)
Merging pci-current/for-linus (29b4817d4018 Linux 4.8-rc1)
Merging driver-core.current/driver-core-linus (29b4817d4018 Linux 4.8-rc1)
Merging tty.current/tty-linus (29b4817d4018 Linux 4.8-rc1)
Merging usb.current/usb-linus (29b4817d4018 Linux 4.8-rc1)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (647024a7df36 USB: serial: fix memleak in 
driver-registration error path)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (29b4817d4018 Linux 4.8-rc1)
Merging char-misc.current/char-misc-linus (29b4817d4018 Linux 4.8-rc1)
Merging input-current/for-linus (22fe874f3803 Input: silead - remove some dead 
code)
Merging crypto-current/master (2fdea258fde0 crypto: caam - defer 
aead_set_sh_desc in case of zero authsize)
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 (c8952a707556 vfio/pci: Fix NULL pointer oops in 
error interrupt setup handling)
Merging kselftest-fixes/fixes (f80eb4289491 selftests/exec: Makefile is a 
run-time dependency, add it to the install list)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e bac

Re: [PATCH] drm/cirrus: Fix NULL pointer dereference when registering the fbdev

[Eric W. Biederman]

Boris Brezillon  writes:

> cirrus_modeset_init() is initializing/registering the emulated fbdev
> and, since commit c61b93fe51b1 ("drm/atomic: Fix remaining places where
> !funcs->best_encoder is valid"), DRM internals can access/test some of
> the fields in mode_config->funcs as part of the fbdev registration
> process.
> Make sure dev->mode_config.funcs is properly set to avoid dereferencing
> a NULL pointer.

That fixes the issues I am seeing.

Tested-by: "Eric W. Biederman" 

> Signed-off-by: Boris Brezillon 
> Fixes: c61b93fe51b1 ("drm/atomic: Fix remaining places where 
> !funcs->best_encoder is valid")
> ---
> Hi Dave,
>
> As discussed on IRC, I'm sending this patch in a proper format. That's
> probably better to wait for Eric's feeback before applying it though.

It is weird I didn't see either of your email messages directly only
through lkml.  Weird.

> Regards,
>
> Boris
> ---
>  drivers/gpu/drm/cirrus/cirrus_main.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
> b/drivers/gpu/drm/cirrus/cirrus_main.c
> index 80446e2d3ab6..76bcb43e7c06 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_main.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_main.c
> @@ -185,14 +185,23 @@ int cirrus_driver_load(struct drm_device *dev, unsigned 
> long flags)
>   goto out;
>   }
>  
> + /*
> +  * cirrus_modeset_init() is initializing/registering the emulated fbdev
> +  * and DRM internals can access/test some of the fields in
> +  * mode_config->funcs as part of the fbdev registration process.
> +  * Make sure dev->mode_config.funcs is properly set to avoid
> +  * dereferencing a NULL pointer.
> +  * FIXME: mode_config.funcs assignment should probably be done in
> +  * cirrus_modeset_init() (that's a common pattern seen in other DRM
> +  * drivers).
> +  */
> + dev->mode_config.funcs = _mode_funcs;
>   r = cirrus_modeset_init(cdev);
>   if (r) {
>   dev_err(>pdev->dev, "Fatal error during modeset init: 
> %d\n", r);
>   goto out;
>   }
>  
> - dev->mode_config.funcs = (void *)_mode_funcs;
> -
>   return 0;
>  out:
>   cirrus_driver_unload(dev);

Re: [PATCH] drm/cirrus: Fix NULL pointer dereference when registering the fbdev

[Eric W. Biederman]

Boris Brezillon  writes:

> cirrus_modeset_init() is initializing/registering the emulated fbdev
> and, since commit c61b93fe51b1 ("drm/atomic: Fix remaining places where
> !funcs->best_encoder is valid"), DRM internals can access/test some of
> the fields in mode_config->funcs as part of the fbdev registration
> process.
> Make sure dev->mode_config.funcs is properly set to avoid dereferencing
> a NULL pointer.

That fixes the issues I am seeing.

Tested-by: "Eric W. Biederman" 

> Signed-off-by: Boris Brezillon 
> Fixes: c61b93fe51b1 ("drm/atomic: Fix remaining places where 
> !funcs->best_encoder is valid")
> ---
> Hi Dave,
>
> As discussed on IRC, I'm sending this patch in a proper format. That's
> probably better to wait for Eric's feeback before applying it though.

It is weird I didn't see either of your email messages directly only
through lkml.  Weird.

> Regards,
>
> Boris
> ---
>  drivers/gpu/drm/cirrus/cirrus_main.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
> b/drivers/gpu/drm/cirrus/cirrus_main.c
> index 80446e2d3ab6..76bcb43e7c06 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_main.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_main.c
> @@ -185,14 +185,23 @@ int cirrus_driver_load(struct drm_device *dev, unsigned 
> long flags)
>   goto out;
>   }
>  
> + /*
> +  * cirrus_modeset_init() is initializing/registering the emulated fbdev
> +  * and DRM internals can access/test some of the fields in
> +  * mode_config->funcs as part of the fbdev registration process.
> +  * Make sure dev->mode_config.funcs is properly set to avoid
> +  * dereferencing a NULL pointer.
> +  * FIXME: mode_config.funcs assignment should probably be done in
> +  * cirrus_modeset_init() (that's a common pattern seen in other DRM
> +  * drivers).
> +  */
> + dev->mode_config.funcs = _mode_funcs;
>   r = cirrus_modeset_init(cdev);
>   if (r) {
>   dev_err(>pdev->dev, "Fatal error during modeset init: 
> %d\n", r);
>   goto out;
>   }
>  
> - dev->mode_config.funcs = (void *)_mode_funcs;
> -
>   return 0;
>  out:
>   cirrus_driver_unload(dev);

Re: [PATCH v4 0/5] vfs: Use dlock list for SB's s_inodes list

[Waiman Long]

On 07/27/2016 11:12 AM, Christoph Lameter wrote:

On Mon, 25 Jul 2016, Tejun Heo wrote:


I don't get it.  What's the harm of using percpu memory here?  Other
percpu data structures have remote access too.  They're to a lower
degree but I don't see a clear demarcation line and making addtions
per-cpu seems to have significant benefits here.  If there's a better
way of splitting the list and locking, sure, let's try that but short
of that I don't see anything wrong with doing this per-cpu.

For the regular global declarations we have separate areas for "SHARED"
per cpu data like this. See DECLARE_PER_CPU_SHARED* and friends.

Even if you align a percpu_alloc() there is still the possibility that
other percpu variables defined after this will suffer from aliasing.
The aligning causes space to be wasted for performance critical areas
where you want to minimize cache line usage. The variables cannot be
packed as densely as before. I think allocations like this need to be
separate. Simply allocate an array of these structs using

kcalloc(nr_cpu_ids, sizeof(my_struct), GFP_KERNEL)?

Why bother with percpu_alloc() if its not per cpu data?

Well if we do not care about that detail that much then lets continue going 
down this patch.



I think that make sense. The various lists don't really need to be in 
the percpu area. Allocated as an array may increase contention a bit 
when multiple CPUs try to access the list heads that happen to be in the 
same cacheline. However, it can speed up dlock list iterations as less 
cachelines need to be traversed. I will make the change to allocate the 
head array using kcalloc instead of using the percpu_alloc.


Thanks for the suggestion.

Cheers,
Longman

Re: [PATCH v4 0/5] vfs: Use dlock list for SB's s_inodes list

[Waiman Long]

On 07/27/2016 11:12 AM, Christoph Lameter wrote:

On Mon, 25 Jul 2016, Tejun Heo wrote:


I don't get it.  What's the harm of using percpu memory here?  Other
percpu data structures have remote access too.  They're to a lower
degree but I don't see a clear demarcation line and making addtions
per-cpu seems to have significant benefits here.  If there's a better
way of splitting the list and locking, sure, let's try that but short
of that I don't see anything wrong with doing this per-cpu.

For the regular global declarations we have separate areas for "SHARED"
per cpu data like this. See DECLARE_PER_CPU_SHARED* and friends.

Even if you align a percpu_alloc() there is still the possibility that
other percpu variables defined after this will suffer from aliasing.
The aligning causes space to be wasted for performance critical areas
where you want to minimize cache line usage. The variables cannot be
packed as densely as before. I think allocations like this need to be
separate. Simply allocate an array of these structs using

kcalloc(nr_cpu_ids, sizeof(my_struct), GFP_KERNEL)?

Why bother with percpu_alloc() if its not per cpu data?

Well if we do not care about that detail that much then lets continue going 
down this patch.



I think that make sense. The various lists don't really need to be in 
the percpu area. Allocated as an array may increase contention a bit 
when multiple CPUs try to access the list heads that happen to be in the 
same cacheline. However, it can speed up dlock list iterations as less 
cachelines need to be traversed. I will make the change to allocate the 
head array using kcalloc instead of using the percpu_alloc.


Thanks for the suggestion.

Cheers,
Longman

Re: [PATCH V5 1/3] x86/ioapic: Support hot-removal of IOAPICs present during boot

[Rui Wang]

On Tuesday, Aug 9, 2016 4:23 AM, Bjorn Helgaas wrote:
> On Sun, Jun 26, 2016 at 11:44:57AM +0800, Rui Wang wrote:
> > v5: Remove #ifdef CONFIG_X86 from setup-bus.c, making it neutral to
> archs.
> > v4: Add comments explaining when to call acpi_ioapic_add().
> > v3: Previous versions break mips. This version fixes it.
> >
> > IOAPICs present during system boot aren't added to ioapic_list, thus
> > are unable to be hot-removed. Fix it by calling
> > acpi_ioapic_add() during root bus enumeration.
> >
> > Signed-off-by: Rui Wang 
> 
> Hi Rui,
> 
> Where are we at with this?  If there's anything that still needs to be merged,
> can you rebase it to v4.8-rc1 and post a new, complete, series?
> 
Hi Bjorn,

Yes. These patches are needed for IOAPIC hotplug to work.

So Thomas & Rafael, any advice?

Thanks
Rui

Re: [PATCH V5 1/3] x86/ioapic: Support hot-removal of IOAPICs present during boot

[Rui Wang]

On Tuesday, Aug 9, 2016 4:23 AM, Bjorn Helgaas wrote:
> On Sun, Jun 26, 2016 at 11:44:57AM +0800, Rui Wang wrote:
> > v5: Remove #ifdef CONFIG_X86 from setup-bus.c, making it neutral to
> archs.
> > v4: Add comments explaining when to call acpi_ioapic_add().
> > v3: Previous versions break mips. This version fixes it.
> >
> > IOAPICs present during system boot aren't added to ioapic_list, thus
> > are unable to be hot-removed. Fix it by calling
> > acpi_ioapic_add() during root bus enumeration.
> >
> > Signed-off-by: Rui Wang 
> 
> Hi Rui,
> 
> Where are we at with this?  If there's anything that still needs to be merged,
> can you rebase it to v4.8-rc1 and post a new, complete, series?
> 
Hi Bjorn,

Yes. These patches are needed for IOAPIC hotplug to work.

So Thomas & Rafael, any advice?

Thanks
Rui

[PATCH] nvme/quirk: Add a delay before checking device ready for memblaze device

[Wenbo Wang]

Add a delay before checking device ready for memblaze device


Signed-off-by: Wenbo Wang 
---
 drivers/nvme/host/pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index c82282f..ab90e5f 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2154,6 +2154,8 @@ static const struct pci_device_id nvme_id_table[] = {
.driver_data = NVME_QUIRK_IDENTIFY_CNS, },
{ PCI_DEVICE(0x1c58, 0x0003),   /* HGST adapter */
.driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
+   { PCI_DEVICE(0x1c5f, 0x0540),   /* Memblaze Pblaze4 adapter */
+   .driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
{ PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_EXPRESS, 0xff) },
{ PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2001) },
{ 0, }
--
1.8.3.1

[PATCH] nvme/quirk: Add a delay before checking device ready for memblaze device

[Wenbo Wang]

Add a delay before checking device ready for memblaze device


Signed-off-by: Wenbo Wang 
---
 drivers/nvme/host/pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index c82282f..ab90e5f 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2154,6 +2154,8 @@ static const struct pci_device_id nvme_id_table[] = {
.driver_data = NVME_QUIRK_IDENTIFY_CNS, },
{ PCI_DEVICE(0x1c58, 0x0003),   /* HGST adapter */
.driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
+   { PCI_DEVICE(0x1c5f, 0x0540),   /* Memblaze Pblaze4 adapter */
+   .driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
{ PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_EXPRESS, 0xff) },
{ PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2001) },
{ 0, }
--
1.8.3.1

Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing RFXE bit in HID1

[Borislav Petkov]

On Mon, Aug 08, 2016 at 03:39:44PM +, york sun wrote:
> RFXE is cleared by default. So for most SoCs, this is not even a concern 
> at all. But for e500v1, when RIO or PCI are used, this bit is set 
> specifically to catch an error by machine check (see commit 4e0e3435). 
> This is not the uncorrectable error from DDR. We will be better off to 
> let this error happen.

So I'm reading this: "With this bit set, EDAC driver can't get the
interrupt in case of uncorrectable error. So this bit is cleared in
favor of EDAC."

AFAIU, it means, RFXE bit remains clear so EDAC will get the interrupt
for the uncorrectable error (UE). So on those !e500v1 systems, EDAC be
handling those UEs.

Am I close?

If so, can EDAC handle the UE?

-- 
Regards/Gruss,
Boris.

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

Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing RFXE bit in HID1

[Borislav Petkov]

On Mon, Aug 08, 2016 at 03:39:44PM +, york sun wrote:
> RFXE is cleared by default. So for most SoCs, this is not even a concern 
> at all. But for e500v1, when RIO or PCI are used, this bit is set 
> specifically to catch an error by machine check (see commit 4e0e3435). 
> This is not the uncorrectable error from DDR. We will be better off to 
> let this error happen.

So I'm reading this: "With this bit set, EDAC driver can't get the
interrupt in case of uncorrectable error. So this bit is cleared in
favor of EDAC."

AFAIU, it means, RFXE bit remains clear so EDAC will get the interrupt
for the uncorrectable error (UE). So on those !e500v1 systems, EDAC be
handling those UEs.

Am I close?

If so, can EDAC handle the UE?

-- 
Regards/Gruss,
Boris.

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

[RESEND PATCH] usb: hub: change CLEAR_FEATURE to SET_FEATURE

[Yonglong Wu]

From: Yonglong Wu 

According to USB30 specification, the Function Remote Wakeup field can be
modified by the SetFeature() requests. SetFeature() is recommended to use.

Signed-off-by: Yonglong Wu 
---
 drivers/usb/core/hub.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bee1351..a6f5095 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3111,7 +3111,7 @@ static int usb_disable_remote_wakeup(struct usb_device 
*udev)
USB_CTRL_SET_TIMEOUT);
else
return usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
-   USB_REQ_CLEAR_FEATURE, USB_RECIP_INTERFACE,
+   USB_REQ_SET_FEATURE, USB_RECIP_INTERFACE,
USB_INTRF_FUNC_SUSPEND, 0, NULL, 0,
USB_CTRL_SET_TIMEOUT);
 }
-- 
1.7.9.5

[RESEND PATCH] usb: hub: change CLEAR_FEATURE to SET_FEATURE

[Yonglong Wu]

From: Yonglong Wu 

According to USB30 specification, the Function Remote Wakeup field can be
modified by the SetFeature() requests. SetFeature() is recommended to use.

Signed-off-by: Yonglong Wu 
---
 drivers/usb/core/hub.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bee1351..a6f5095 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3111,7 +3111,7 @@ static int usb_disable_remote_wakeup(struct usb_device 
*udev)
USB_CTRL_SET_TIMEOUT);
else
return usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
-   USB_REQ_CLEAR_FEATURE, USB_RECIP_INTERFACE,
+   USB_REQ_SET_FEATURE, USB_RECIP_INTERFACE,
USB_INTRF_FUNC_SUSPEND, 0, NULL, 0,
USB_CTRL_SET_TIMEOUT);
 }
-- 
1.7.9.5

[PATCH] usb: hub: change CLEAR_FEATURE to SET_FEATURE

[Yonglong Wu]

From: Yonglong Wu 

According to USB30 specification, the Function Remote Wakeup field can be
modified by the SetFeature() requests. SetFeature() is recommended to use.

Change-Id: Ie744b95f12d7d21d9519e77ed706c8cc33fa
Signed-off-by: Yonglong Wu 
---
 drivers/usb/core/hub.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bee1351..a6f5095 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3111,7 +3111,7 @@ static int usb_disable_remote_wakeup(struct usb_device 
*udev)
USB_CTRL_SET_TIMEOUT);
else
return usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
-   USB_REQ_CLEAR_FEATURE, USB_RECIP_INTERFACE,
+   USB_REQ_SET_FEATURE, USB_RECIP_INTERFACE,
USB_INTRF_FUNC_SUSPEND, 0, NULL, 0,
USB_CTRL_SET_TIMEOUT);
 }
-- 
1.7.9.5

Re: [PATCH 1/3] ASoC: sst-haswell-pcm: don't use snd_soc_pcm_set_drvdata()

[Kuninori Morimoto]

Hi Mark

> > snd_soc_pcm_set_drvdata() will set driver data to rtd->dev,
> > but driver data of rtd->dev is already used as "rtd" on
> > soc_post_component_init().
> 
> This doesn't apply against current code, please check and resend.

Thanks.
It seems current your branch already has same patch.
Thus, This [1/3] is not needed now.

commit c999675b04c146aa57f6e853a3746de979427fad
Author: Ben Zhang 
Date:   Thu Jul 7 18:54:56 2016 -0700

ASoC: Intel: Fix conflicting pcm dev drvdata on haswell

soc-core sets the snd_soc_pcm_runtime->dev drvdata to
snd_soc_pcm_runtime in soc_post_component_init, and access
it in places like codec_reg_show.

hsw_pcm_open overwrites the drvdata to point to hsw_pcm_data,
confusing soc-core, and causing crashes when cat
/sys/devices/pci:00/INT3438:00/.../System PCM/codec_reg

This patch removes the set in hsw_pcm_open since it's no longer
used. commit 7ff9d6714a5c ("ASoC: Intel: Split hsw_pcm_data for
playback and capture") already removed all calls to
snd_soc_pcm_get_drvdata(rtd).

Signed-off-by: Ben Zhang 
Signed-off-by: Mark Brown 

[PATCH] usb: hub: change CLEAR_FEATURE to SET_FEATURE

[Yonglong Wu]

From: Yonglong Wu 

According to USB30 specification, the Function Remote Wakeup field can be
modified by the SetFeature() requests. SetFeature() is recommended to use.

Change-Id: Ie744b95f12d7d21d9519e77ed706c8cc33fa
Signed-off-by: Yonglong Wu 
---
 drivers/usb/core/hub.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bee1351..a6f5095 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3111,7 +3111,7 @@ static int usb_disable_remote_wakeup(struct usb_device 
*udev)
USB_CTRL_SET_TIMEOUT);
else
return usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
-   USB_REQ_CLEAR_FEATURE, USB_RECIP_INTERFACE,
+   USB_REQ_SET_FEATURE, USB_RECIP_INTERFACE,
USB_INTRF_FUNC_SUSPEND, 0, NULL, 0,
USB_CTRL_SET_TIMEOUT);
 }
-- 
1.7.9.5

Re: [PATCH 1/3] ASoC: sst-haswell-pcm: don't use snd_soc_pcm_set_drvdata()

[Kuninori Morimoto]

Hi Mark

> > snd_soc_pcm_set_drvdata() will set driver data to rtd->dev,
> > but driver data of rtd->dev is already used as "rtd" on
> > soc_post_component_init().
> 
> This doesn't apply against current code, please check and resend.

Thanks.
It seems current your branch already has same patch.
Thus, This [1/3] is not needed now.

commit c999675b04c146aa57f6e853a3746de979427fad
Author: Ben Zhang 
Date:   Thu Jul 7 18:54:56 2016 -0700

ASoC: Intel: Fix conflicting pcm dev drvdata on haswell

soc-core sets the snd_soc_pcm_runtime->dev drvdata to
snd_soc_pcm_runtime in soc_post_component_init, and access
it in places like codec_reg_show.

hsw_pcm_open overwrites the drvdata to point to hsw_pcm_data,
confusing soc-core, and causing crashes when cat
/sys/devices/pci:00/INT3438:00/.../System PCM/codec_reg

This patch removes the set in hsw_pcm_open since it's no longer
used. commit 7ff9d6714a5c ("ASoC: Intel: Split hsw_pcm_data for
playback and capture") already removed all calls to
snd_soc_pcm_get_drvdata(rtd).

Signed-off-by: Ben Zhang 
Signed-off-by: Mark Brown 

[PATCH] cpuset: make sure new tasks conform to the current config of the cpuset

[Zefan Li]

A new task inherits cpus_allowed and mems_allowed masks from its parent,
but if someone changes cpuset's config by writing to cpuset.cpus/cpuset.mems
before this new task is inserted into the cgroup's task list, the new task
won't be updated accordingly.

Signed-off-by: Zefan Li 
---
 kernel/cpuset.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index c7fd277..c27e533 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -2069,6 +2069,20 @@ static void cpuset_bind(struct cgroup_subsys_state 
*root_css)
mutex_unlock(_mutex);
 }
 
+/*
+ * Make sure the new task conform to the current state of its parent,
+ * which could have been changed by cpuset just after it inherits the
+ * state from the parent and before it sits on the cgroup's task list.
+ */
+void cpuset_fork(struct task_struct *task)
+{
+   if (task_css_is_root(task, cpuset_cgrp_id))
+   return;
+
+   set_cpus_allowed_ptr(task, >cpus_allowed);
+   task->mems_allowed = current->mems_allowed;
+}
+
 struct cgroup_subsys cpuset_cgrp_subsys = {
.css_alloc  = cpuset_css_alloc,
.css_online = cpuset_css_online,
@@ -2079,6 +2093,7 @@ struct cgroup_subsys cpuset_cgrp_subsys = {
.attach = cpuset_attach,
.post_attach= cpuset_post_attach,
.bind   = cpuset_bind,
+   .fork   = cpuset_fork,
.legacy_cftypes = files,
.early_init = true,
 };
-- 
1.8.2.2

[PATCH] cpuset: make sure new tasks conform to the current config of the cpuset

[Zefan Li]

A new task inherits cpus_allowed and mems_allowed masks from its parent,
but if someone changes cpuset's config by writing to cpuset.cpus/cpuset.mems
before this new task is inserted into the cgroup's task list, the new task
won't be updated accordingly.

Signed-off-by: Zefan Li 
---
 kernel/cpuset.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index c7fd277..c27e533 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -2069,6 +2069,20 @@ static void cpuset_bind(struct cgroup_subsys_state 
*root_css)
mutex_unlock(_mutex);
 }
 
+/*
+ * Make sure the new task conform to the current state of its parent,
+ * which could have been changed by cpuset just after it inherits the
+ * state from the parent and before it sits on the cgroup's task list.
+ */
+void cpuset_fork(struct task_struct *task)
+{
+   if (task_css_is_root(task, cpuset_cgrp_id))
+   return;
+
+   set_cpus_allowed_ptr(task, >cpus_allowed);
+   task->mems_allowed = current->mems_allowed;
+}
+
 struct cgroup_subsys cpuset_cgrp_subsys = {
.css_alloc  = cpuset_css_alloc,
.css_online = cpuset_css_online,
@@ -2079,6 +2093,7 @@ struct cgroup_subsys cpuset_cgrp_subsys = {
.attach = cpuset_attach,
.post_attach= cpuset_post_attach,
.bind   = cpuset_bind,
+   .fork   = cpuset_fork,
.legacy_cftypes = files,
.early_init = true,
 };
-- 
1.8.2.2

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

[Benjamin Poirier]

On 2016/08/08 09:26, Andreas Werner wrote:
[...]
> > > +
> > > + if (cf->can_dlc > 0)
> > > + data[0] = be32_to_cpup((__be32 *)(cf->data));
> > > + if (cf->can_dlc > 3)
> > > + data[1] = be32_to_cpup((__be32 *)(cf->data + 4));
> > > +
> > > + writel(id, _buf->can_id);
> > > + writel(cf->can_dlc, _buf->length);
> > > +
> > > + if (!(cf->can_id & CAN_RTR_FLAG)) {
> > > + writel(data[0], _buf->data[0]);
> > > + writel(data[1], _buf->data[1]);
> > > +
> > > + stats->tx_bytes += cf->can_dlc;
> > > + }
> > > +
> > > + /* be sure everything is written to the
> > > +  * device before acknowledge the data.
> > > +  */
> > > + mmiowb();
> > > +
> > > + /* trigger the transmission */
> > > + men_z192_ack_tx_pkg(priv, 1);
> > > +
> > > + stats->tx_packets++;
> > > +
> > > + kfree_skb(skb);
> > 
> > What prevents the skb data to be freed/reused before the device has
> > accessed it?

I'm sorry, I hadn't realized that all of the data (all 8 bytes of it!)
is written directly to the device. I was thinking about ethernet devices
that dma packet data.

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

[Benjamin Poirier]

On 2016/08/08 09:26, Andreas Werner wrote:
[...]
> > > +
> > > + if (cf->can_dlc > 0)
> > > + data[0] = be32_to_cpup((__be32 *)(cf->data));
> > > + if (cf->can_dlc > 3)
> > > + data[1] = be32_to_cpup((__be32 *)(cf->data + 4));
> > > +
> > > + writel(id, _buf->can_id);
> > > + writel(cf->can_dlc, _buf->length);
> > > +
> > > + if (!(cf->can_id & CAN_RTR_FLAG)) {
> > > + writel(data[0], _buf->data[0]);
> > > + writel(data[1], _buf->data[1]);
> > > +
> > > + stats->tx_bytes += cf->can_dlc;
> > > + }
> > > +
> > > + /* be sure everything is written to the
> > > +  * device before acknowledge the data.
> > > +  */
> > > + mmiowb();
> > > +
> > > + /* trigger the transmission */
> > > + men_z192_ack_tx_pkg(priv, 1);
> > > +
> > > + stats->tx_packets++;
> > > +
> > > + kfree_skb(skb);
> > 
> > What prevents the skb data to be freed/reused before the device has
> > accessed it?

I'm sorry, I hadn't realized that all of the data (all 8 bytes of it!)
is written directly to the device. I was thinking about ethernet devices
that dma packet data.

Re: [lkp] [fs] 45ec18d5c7: BUG: KASAN: user-memory-access on address 00007f90291c7ec0

[Ye Xiaolong]

On 08/08, valdis.kletni...@vt.edu wrote:
>On Tue, 09 Aug 2016 09:17:58 +0800, Ye Xiaolong said:
>> On 08/08, valdis.kletni...@vt.edu wrote:
>> > In other words - how did this patch get into a tree that 0day listens to?
>>
>> 0Day has a service to automatically capture every patchset sent to LKML
>
>Something's wrong then.  Nick has proven to be such a maintainer time-sink
>that he's not allowed to post to LKML - or any other list on vger.kernel.org.
>
>So how did he get past that and get 0day to see it?

We'll add a blacklist for it, Thanks.

Re: [lkp] [fs] 45ec18d5c7: BUG: KASAN: user-memory-access on address 00007f90291c7ec0

[Ye Xiaolong]

On 08/08, valdis.kletni...@vt.edu wrote:
>On Tue, 09 Aug 2016 09:17:58 +0800, Ye Xiaolong said:
>> On 08/08, valdis.kletni...@vt.edu wrote:
>> > In other words - how did this patch get into a tree that 0day listens to?
>>
>> 0Day has a service to automatically capture every patchset sent to LKML
>
>Something's wrong then.  Nick has proven to be such a maintainer time-sink
>that he's not allowed to post to LKML - or any other list on vger.kernel.org.
>
>So how did he get past that and get 0day to see it?

We'll add a blacklist for it, Thanks.

Re: [lkp] [fs] 45ec18d5c7: BUG: KASAN: user-memory-access on address 00007f90291c7ec0

[Ye Xiaolong]

On 08/09, Al Viro wrote:
>On Tue, Aug 09, 2016 at 09:17:58AM +0800, Ye Xiaolong wrote:
>> On 08/08, valdis.kletni...@vt.edu wrote:
>> >On Sun, 07 Aug 2016 22:02:42 +0800, kernel test robot said:
>> >
>> >> FYI, we noticed the following commit:
>> >>
>> >> https://github.com/0day-ci/linux
>> >> Nicholas-Krause/fs-Fix-kmemleak-leak-warning-in-getname_flags-about-working-on-unitialized-memory/20160804-055054
>> >> commit 45ec18d5c713bccb9807782f0dca29b92ba99784 ("fs:Fix kmemleak leak 
>> >> warning in getname_flags about working on unitialized memory")
>> >
>> >The real question here is why the 0day system was even bothering to try
>> >compiling and booting a patch from somebody who has a long record of failing
>> >to do so with patches before submission.  Actually looking at the patch
>> >in question shows that little or no thought or testing was done (hint:
>> >look at it, and wonder in amazement why there's a dump_stack() call where
>> >it is)
>> >
>> >In other words - how did this patch get into a tree that 0day listens to?
>> 
>> 0Day has a service to automatically capture every patchset sent to LKML, and 
>> convert
>> email patchset to git branches by applying them on top of different
>> trees heuristically.
>
>*raised eyebrows*
>
>I really hope they are doing both builds and testing in a heavily isolated
>environments, then.  Because you've just described an attack vector it's
>vulnerable to...

Yes, they are doing test in a heavily isolated environments with chroot,
no suid and isolated network.

Re: [lkp] [fs] 45ec18d5c7: BUG: KASAN: user-memory-access on address 00007f90291c7ec0

[Ye Xiaolong]

On 08/09, Al Viro wrote:
>On Tue, Aug 09, 2016 at 09:17:58AM +0800, Ye Xiaolong wrote:
>> On 08/08, valdis.kletni...@vt.edu wrote:
>> >On Sun, 07 Aug 2016 22:02:42 +0800, kernel test robot said:
>> >
>> >> FYI, we noticed the following commit:
>> >>
>> >> https://github.com/0day-ci/linux
>> >> Nicholas-Krause/fs-Fix-kmemleak-leak-warning-in-getname_flags-about-working-on-unitialized-memory/20160804-055054
>> >> commit 45ec18d5c713bccb9807782f0dca29b92ba99784 ("fs:Fix kmemleak leak 
>> >> warning in getname_flags about working on unitialized memory")
>> >
>> >The real question here is why the 0day system was even bothering to try
>> >compiling and booting a patch from somebody who has a long record of failing
>> >to do so with patches before submission.  Actually looking at the patch
>> >in question shows that little or no thought or testing was done (hint:
>> >look at it, and wonder in amazement why there's a dump_stack() call where
>> >it is)
>> >
>> >In other words - how did this patch get into a tree that 0day listens to?
>> 
>> 0Day has a service to automatically capture every patchset sent to LKML, and 
>> convert
>> email patchset to git branches by applying them on top of different
>> trees heuristically.
>
>*raised eyebrows*
>
>I really hope they are doing both builds and testing in a heavily isolated
>environments, then.  Because you've just described an attack vector it's
>vulnerable to...

Yes, they are doing test in a heavily isolated environments with chroot,
no suid and isolated network.

[PATCH] seq/proc: Modify seq_put_decimal_[u]ll to take a const char *, not char

[Joe Perches]

Allow some seq_puts removals by taking a string instead of a single char.

Signed-off-by: Joe Perches 
---

On top of Alexey's patch, this would also save a couple percent CPU

 fs/proc/array.c  | 178 ++-
 fs/proc/stat.c   |  49 +++--
 fs/seq_file.c|  57 +++
 include/linux/seq_file.h |   4 +-
 4 files changed, 153 insertions(+), 135 deletions(-)

diff --git a/fs/proc/array.c b/fs/proc/array.c
index 5e7d252..d25b446 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -188,33 +188,26 @@ static inline void task_state(struct seq_file *m, struct 
pid_namespace *ns,
 
seq_printf(m, "State:\t%s", get_task_state(p));
 
-   seq_puts(m, "\nTgid:\t");
-   seq_put_decimal_ull(m, 0, tgid);
-   seq_puts(m, "\nNgid:\t");
-   seq_put_decimal_ull(m, 0, ngid);
-   seq_puts(m, "\nPid:\t");
-   seq_put_decimal_ull(m, 0, pid_nr_ns(pid, ns));
-   seq_puts(m, "\nPPid:\t");
-   seq_put_decimal_ull(m, 0, ppid);
-   seq_puts(m, "\nTracerPid:\t");
-   seq_put_decimal_ull(m, 0, tpid);
-   seq_puts(m, "\nUid:");
-   seq_put_decimal_ull(m, '\t', from_kuid_munged(user_ns, cred->uid));
-   seq_put_decimal_ull(m, '\t', from_kuid_munged(user_ns, cred->euid));
-   seq_put_decimal_ull(m, '\t', from_kuid_munged(user_ns, cred->suid));
-   seq_put_decimal_ull(m, '\t', from_kuid_munged(user_ns, cred->fsuid));
-   seq_puts(m, "\nGid:");
-   seq_put_decimal_ull(m, '\t', from_kgid_munged(user_ns, cred->gid));
-   seq_put_decimal_ull(m, '\t', from_kgid_munged(user_ns, cred->egid));
-   seq_put_decimal_ull(m, '\t', from_kgid_munged(user_ns, cred->sgid));
-   seq_put_decimal_ull(m, '\t', from_kgid_munged(user_ns, cred->fsgid));
-   seq_puts(m, "\nFDSize:\t");
-   seq_put_decimal_ull(m, 0, max_fds);
+   seq_put_decimal_ull(m, "\nTgid:\t", tgid);
+   seq_put_decimal_ull(m, "\nNgid:\t", ngid);
+   seq_put_decimal_ull(m, "\nPid:\t", pid_nr_ns(pid, ns));
+   seq_put_decimal_ull(m, "\nPPid:\t", ppid);
+   seq_put_decimal_ull(m, "\nTracerPid:\t", tpid);
+   seq_put_decimal_ull(m, "\nUid:\t", from_kuid_munged(user_ns, 
cred->uid));
+   seq_put_decimal_ull(m, "\t", from_kuid_munged(user_ns, cred->euid));
+   seq_put_decimal_ull(m, "\t", from_kuid_munged(user_ns, cred->suid));
+   seq_put_decimal_ull(m, "\t", from_kuid_munged(user_ns, cred->fsuid));
+   seq_put_decimal_ull(m, "\nGid:\t", from_kgid_munged(user_ns, 
cred->gid));
+   seq_put_decimal_ull(m, "\t", from_kgid_munged(user_ns, cred->egid));
+   seq_put_decimal_ull(m, "\t", from_kgid_munged(user_ns, cred->sgid));
+   seq_put_decimal_ull(m, "\t", from_kgid_munged(user_ns, cred->fsgid));
+   seq_put_decimal_ull(m, "\nFDSize:\t", max_fds);
 
seq_puts(m, "\nGroups:\t");
group_info = cred->group_info;
for (g = 0; g < group_info->ngroups; g++)
-   seq_put_decimal_ull(m, g ? ' ' : 0, from_kgid_munged(user_ns, 
GROUP_AT(group_info, g)));
+   seq_put_decimal_ull(m, g ? " " : "",
+   from_kgid_munged(user_ns, 
GROUP_AT(group_info, g)));
put_cred(cred);
/* Trailing space shouldn't have been added in the first place. */
seq_putc(m, ' ');
@@ -222,16 +215,16 @@ static inline void task_state(struct seq_file *m, struct 
pid_namespace *ns,
 #ifdef CONFIG_PID_NS
seq_puts(m, "\nNStgid:");
for (g = ns->level; g <= pid->level; g++)
-   seq_put_decimal_ull(m, '\t', task_tgid_nr_ns(p, 
pid->numbers[g].ns));
+   seq_put_decimal_ull(m, "\t", task_tgid_nr_ns(p, 
pid->numbers[g].ns));
seq_puts(m, "\nNSpid:");
for (g = ns->level; g <= pid->level; g++)
-   seq_put_decimal_ull(m, '\t', task_pid_nr_ns(p, 
pid->numbers[g].ns));
+   seq_put_decimal_ull(m, "\t", task_pid_nr_ns(p, 
pid->numbers[g].ns));
seq_puts(m, "\nNSpgid:");
for (g = ns->level; g <= pid->level; g++)
-   seq_put_decimal_ull(m, '\t', task_pgrp_nr_ns(p, 
pid->numbers[g].ns));
+   seq_put_decimal_ull(m, "\t", task_pgrp_nr_ns(p, 
pid->numbers[g].ns));
seq_puts(m, "\nNSsid:");
for (g = ns->level; g <= pid->level; g++)
-   seq_put_decimal_ull(m, '\t', task_session_nr_ns(p, 
pid->numbers[g].ns));
+   seq_put_decimal_ull(m, "\t", task_session_nr_ns(p, 
pid->numbers[g].ns));
 #endif
seq_putc(m, '\n');
 }
@@ -300,11 +293,9 @@ static inline void task_sig(struct seq_file *m, struct 
task_struct *p)
unlock_task_sighand(p, );
}
 
-   seq_puts(m, "Threads:\t");
-   seq_put_decimal_ull(m, 0, num_threads);
-   seq_puts(m, "\nSigQ:\t");
-   seq_put_decimal_ull(m, 0, qsize);
-   seq_put_decimal_ull(m, '/', qlim);
+   seq_put_decimal_ull(m, "Threads:\t", num_threads);
+   seq_put_decimal_ull(m, "\nSigQ:\t", 

[PATCH] seq/proc: Modify seq_put_decimal_[u]ll to take a const char *, not char

[Joe Perches]

Allow some seq_puts removals by taking a string instead of a single char.

Signed-off-by: Joe Perches 
---

On top of Alexey's patch, this would also save a couple percent CPU

 fs/proc/array.c  | 178 ++-
 fs/proc/stat.c   |  49 +++--
 fs/seq_file.c|  57 +++
 include/linux/seq_file.h |   4 +-
 4 files changed, 153 insertions(+), 135 deletions(-)

diff --git a/fs/proc/array.c b/fs/proc/array.c
index 5e7d252..d25b446 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -188,33 +188,26 @@ static inline void task_state(struct seq_file *m, struct 
pid_namespace *ns,
 
seq_printf(m, "State:\t%s", get_task_state(p));
 
-   seq_puts(m, "\nTgid:\t");
-   seq_put_decimal_ull(m, 0, tgid);
-   seq_puts(m, "\nNgid:\t");
-   seq_put_decimal_ull(m, 0, ngid);
-   seq_puts(m, "\nPid:\t");
-   seq_put_decimal_ull(m, 0, pid_nr_ns(pid, ns));
-   seq_puts(m, "\nPPid:\t");
-   seq_put_decimal_ull(m, 0, ppid);
-   seq_puts(m, "\nTracerPid:\t");
-   seq_put_decimal_ull(m, 0, tpid);
-   seq_puts(m, "\nUid:");
-   seq_put_decimal_ull(m, '\t', from_kuid_munged(user_ns, cred->uid));
-   seq_put_decimal_ull(m, '\t', from_kuid_munged(user_ns, cred->euid));
-   seq_put_decimal_ull(m, '\t', from_kuid_munged(user_ns, cred->suid));
-   seq_put_decimal_ull(m, '\t', from_kuid_munged(user_ns, cred->fsuid));
-   seq_puts(m, "\nGid:");
-   seq_put_decimal_ull(m, '\t', from_kgid_munged(user_ns, cred->gid));
-   seq_put_decimal_ull(m, '\t', from_kgid_munged(user_ns, cred->egid));
-   seq_put_decimal_ull(m, '\t', from_kgid_munged(user_ns, cred->sgid));
-   seq_put_decimal_ull(m, '\t', from_kgid_munged(user_ns, cred->fsgid));
-   seq_puts(m, "\nFDSize:\t");
-   seq_put_decimal_ull(m, 0, max_fds);
+   seq_put_decimal_ull(m, "\nTgid:\t", tgid);
+   seq_put_decimal_ull(m, "\nNgid:\t", ngid);
+   seq_put_decimal_ull(m, "\nPid:\t", pid_nr_ns(pid, ns));
+   seq_put_decimal_ull(m, "\nPPid:\t", ppid);
+   seq_put_decimal_ull(m, "\nTracerPid:\t", tpid);
+   seq_put_decimal_ull(m, "\nUid:\t", from_kuid_munged(user_ns, 
cred->uid));
+   seq_put_decimal_ull(m, "\t", from_kuid_munged(user_ns, cred->euid));
+   seq_put_decimal_ull(m, "\t", from_kuid_munged(user_ns, cred->suid));
+   seq_put_decimal_ull(m, "\t", from_kuid_munged(user_ns, cred->fsuid));
+   seq_put_decimal_ull(m, "\nGid:\t", from_kgid_munged(user_ns, 
cred->gid));
+   seq_put_decimal_ull(m, "\t", from_kgid_munged(user_ns, cred->egid));
+   seq_put_decimal_ull(m, "\t", from_kgid_munged(user_ns, cred->sgid));
+   seq_put_decimal_ull(m, "\t", from_kgid_munged(user_ns, cred->fsgid));
+   seq_put_decimal_ull(m, "\nFDSize:\t", max_fds);
 
seq_puts(m, "\nGroups:\t");
group_info = cred->group_info;
for (g = 0; g < group_info->ngroups; g++)
-   seq_put_decimal_ull(m, g ? ' ' : 0, from_kgid_munged(user_ns, 
GROUP_AT(group_info, g)));
+   seq_put_decimal_ull(m, g ? " " : "",
+   from_kgid_munged(user_ns, 
GROUP_AT(group_info, g)));
put_cred(cred);
/* Trailing space shouldn't have been added in the first place. */
seq_putc(m, ' ');
@@ -222,16 +215,16 @@ static inline void task_state(struct seq_file *m, struct 
pid_namespace *ns,
 #ifdef CONFIG_PID_NS
seq_puts(m, "\nNStgid:");
for (g = ns->level; g <= pid->level; g++)
-   seq_put_decimal_ull(m, '\t', task_tgid_nr_ns(p, 
pid->numbers[g].ns));
+   seq_put_decimal_ull(m, "\t", task_tgid_nr_ns(p, 
pid->numbers[g].ns));
seq_puts(m, "\nNSpid:");
for (g = ns->level; g <= pid->level; g++)
-   seq_put_decimal_ull(m, '\t', task_pid_nr_ns(p, 
pid->numbers[g].ns));
+   seq_put_decimal_ull(m, "\t", task_pid_nr_ns(p, 
pid->numbers[g].ns));
seq_puts(m, "\nNSpgid:");
for (g = ns->level; g <= pid->level; g++)
-   seq_put_decimal_ull(m, '\t', task_pgrp_nr_ns(p, 
pid->numbers[g].ns));
+   seq_put_decimal_ull(m, "\t", task_pgrp_nr_ns(p, 
pid->numbers[g].ns));
seq_puts(m, "\nNSsid:");
for (g = ns->level; g <= pid->level; g++)
-   seq_put_decimal_ull(m, '\t', task_session_nr_ns(p, 
pid->numbers[g].ns));
+   seq_put_decimal_ull(m, "\t", task_session_nr_ns(p, 
pid->numbers[g].ns));
 #endif
seq_putc(m, '\n');
 }
@@ -300,11 +293,9 @@ static inline void task_sig(struct seq_file *m, struct 
task_struct *p)
unlock_task_sighand(p, );
}
 
-   seq_puts(m, "Threads:\t");
-   seq_put_decimal_ull(m, 0, num_threads);
-   seq_puts(m, "\nSigQ:\t");
-   seq_put_decimal_ull(m, 0, qsize);
-   seq_put_decimal_ull(m, '/', qlim);
+   seq_put_decimal_ull(m, "Threads:\t", num_threads);
+   seq_put_decimal_ull(m, "\nSigQ:\t", qsize);
+   

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

[Dave Airlie]

On 8 August 2016 at 19:40, Daniel Vetter  wrote:
> On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote:
>> Hello there,
>>
>> Recent versions of gcc say this:
>>
>> include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
>> requires 37 bits to represent, but ‘int’ only has 32 bits
>> [-Wshift-overflow=]
>>
>> Source code is
>>
>> #define   INTEL_BSM_MASK (0x << 20)
>>
>> Maybe something like
>>
>> #define   INTEL_BSM_MASK (0xUL<< 20)
>>
>> might be better.
>
> Yup. Care to bake this into a patch (with s-o-b and everything per
> Documentation/SubmittingPatches) so I can apply it?

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

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

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

Dave.

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

[Dave Airlie]

On 8 August 2016 at 19:40, Daniel Vetter  wrote:
> On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote:
>> Hello there,
>>
>> Recent versions of gcc say this:
>>
>> include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
>> requires 37 bits to represent, but ‘int’ only has 32 bits
>> [-Wshift-overflow=]
>>
>> Source code is
>>
>> #define   INTEL_BSM_MASK (0x << 20)
>>
>> Maybe something like
>>
>> #define   INTEL_BSM_MASK (0xUL<< 20)
>>
>> might be better.
>
> Yup. Care to bake this into a patch (with s-o-b and everything per
> Documentation/SubmittingPatches) so I can apply it?

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

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

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

Dave.

RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

[Li, Liang Z]

> Subject: Re: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast 
> (de)inflating
> & fast live migration
> 
> On 08/07/2016 11:35 PM, Liang Li wrote:
> > Dave Hansen suggested a new scheme to encode the data structure,
> > because of additional complexity, it's not implemented in v3.
> 
> FWIW, I don't think it takes any additional complexity here, at least in the
> guest implementation side.  The thing I suggested would just mean explicitly
> calling out that there was a single bitmap instead of implying it in the ABI.
> 
> Do you think the scheme I suggested is the way to go?

Yes, I think so.  And I will do that in the later version. In this V3, I just 
want to solve the 
issue caused by a large page bitmap in v2.

Liang

RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

[Li, Liang Z]

> Subject: Re: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast 
> (de)inflating
> & fast live migration
> 
> On 08/07/2016 11:35 PM, Liang Li wrote:
> > Dave Hansen suggested a new scheme to encode the data structure,
> > because of additional complexity, it's not implemented in v3.
> 
> FWIW, I don't think it takes any additional complexity here, at least in the
> guest implementation side.  The thing I suggested would just mean explicitly
> calling out that there was a single bitmap instead of implying it in the ABI.
> 
> Do you think the scheme I suggested is the way to go?

Yes, I think so.  And I will do that in the later version. In this V3, I just 
want to solve the 
issue caused by a large page bitmap in v2.

Liang

[PATCH v3] perf probe: Support signedness casting

[Naohiro Aota]

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

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

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

E.g. without this:

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

With this:

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

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

Signed-off-by: Naohiro Aota 
---
 tools/perf/Documentation/perf-probe.txt | 10 +-
 tools/perf/util/probe-finder.c  | 15 ---
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/tools/perf/Documentation/perf-probe.txt 
b/tools/perf/Documentation/perf-probe.txt
index 736da44..b303bcd 100644
--- a/tools/perf/Documentation/perf-probe.txt
+++ b/tools/perf/Documentation/perf-probe.txt
@@ -176,10 +176,18 @@ Each probe argument follows below syntax.
 
 'NAME' specifies the name of this argument (optional). You can use the name of 
local variable, local data structure member (e.g. var->field, var.field2), 
local array with fixed index (e.g. array[1], var->array[0], var->pointer[2]), 
or kprobe-tracer argument format (e.g. $retval, %ax, etc). Note that the name 
of this argument will be set as the last member name if you specify a local 
data structure member (e.g. field2 for 'var->field1.field2'.)
 '$vars' and '$params' special arguments are also available for NAME, '$vars' 
is expanded to the local variables (including function parameters) which can 
access at given probe point. '$params' is expanded to only the function 
parameters.
-'TYPE' casts the type of this argument (optional). If omitted, perf probe 
automatically set the type based on debuginfo. You can specify 'string' type 
only for the local variable or structure member which is an array of or a 
pointer to 'char' or 'unsigned char' type.
+'TYPE' casts the type of this argument (optional). If omitted, perf probe 
automatically set the type based on debuginfo. Currently, basic types 
(u8/u16/u32/u64/s8/s16/s32/s64), signedness casting (u/s), "string" and 
bitfield are supported. (see TYPES for detail)
 
 On x86 systems %REG is always the short form of the register: for example %AX. 
%RAX or %EAX is not valid.
 
+TYPES
+-
+Basic types (u8/u16/u32/u64/s8/s16/s32/s64) are integer types. Prefix 's' and 
'u' means those types are signed and unsigned respectively. Traced arguments 
are shown in decimal (signed) or hex (unsigned). You can also use 's' or 'u' to 
specify only signedness and leave its size auto-detected by perf probe.
+String type is a special type, which fetches a "null-terminated" string from 
kernel space. This means it will fail and store NULL if the string container 
has been paged out. You can specify 'string' type only for the local variable 
or structure member which is an array of or a pointer to 'char' or 'unsigned 
char' type.
+Bitfield is another special type, which takes 3 parameters, bit-width, 
bit-offset, and container-size (usually 32). The syntax is;
+
+ b@/
+
 LINE SYNTAX
 ---
 Line range is described by following syntax.
diff --git a/tools/perf/util/probe-finder.c 

[PATCH v3] perf probe: Support signedness casting

[Naohiro Aota]

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

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

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

E.g. without this:

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

With this:

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

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

Signed-off-by: Naohiro Aota 
---
 tools/perf/Documentation/perf-probe.txt | 10 +-
 tools/perf/util/probe-finder.c  | 15 ---
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/tools/perf/Documentation/perf-probe.txt 
b/tools/perf/Documentation/perf-probe.txt
index 736da44..b303bcd 100644
--- a/tools/perf/Documentation/perf-probe.txt
+++ b/tools/perf/Documentation/perf-probe.txt
@@ -176,10 +176,18 @@ Each probe argument follows below syntax.
 
 'NAME' specifies the name of this argument (optional). You can use the name of 
local variable, local data structure member (e.g. var->field, var.field2), 
local array with fixed index (e.g. array[1], var->array[0], var->pointer[2]), 
or kprobe-tracer argument format (e.g. $retval, %ax, etc). Note that the name 
of this argument will be set as the last member name if you specify a local 
data structure member (e.g. field2 for 'var->field1.field2'.)
 '$vars' and '$params' special arguments are also available for NAME, '$vars' 
is expanded to the local variables (including function parameters) which can 
access at given probe point. '$params' is expanded to only the function 
parameters.
-'TYPE' casts the type of this argument (optional). If omitted, perf probe 
automatically set the type based on debuginfo. You can specify 'string' type 
only for the local variable or structure member which is an array of or a 
pointer to 'char' or 'unsigned char' type.
+'TYPE' casts the type of this argument (optional). If omitted, perf probe 
automatically set the type based on debuginfo. Currently, basic types 
(u8/u16/u32/u64/s8/s16/s32/s64), signedness casting (u/s), "string" and 
bitfield are supported. (see TYPES for detail)
 
 On x86 systems %REG is always the short form of the register: for example %AX. 
%RAX or %EAX is not valid.
 
+TYPES
+-
+Basic types (u8/u16/u32/u64/s8/s16/s32/s64) are integer types. Prefix 's' and 
'u' means those types are signed and unsigned respectively. Traced arguments 
are shown in decimal (signed) or hex (unsigned). You can also use 's' or 'u' to 
specify only signedness and leave its size auto-detected by perf probe.
+String type is a special type, which fetches a "null-terminated" string from 
kernel space. This means it will fail and store NULL if the string container 
has been paged out. You can specify 'string' type only for the local variable 
or structure member which is an array of or a pointer to 'char' or 'unsigned 
char' type.
+Bitfield is another special type, which takes 3 parameters, bit-width, 
bit-offset, and container-size (usually 32). The syntax is;
+
+ b@/
+
 LINE SYNTAX
 ---
 Line range is described by following syntax.
diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index 

Re: 4.7.0-rc7 ext4 error in dx_probe

[Darrick J. Wong]

On Tue, Aug 09, 2016 at 12:13:01AM +0300, Török Edwin wrote:
> On 2016-08-08 19:55, Darrick J. Wong wrote:
> > On Mon, Aug 08, 2016 at 12:08:18PM -0400, Theodore Ts'o wrote:
> >> On Sun, Aug 07, 2016 at 11:28:10PM -0700, Darrick J. Wong wrote:
> >>>
> >>> I have one lingering concern -- is it a bug that two processes could be
> >>> computing the checksum of a buffer simultaneously?  I would have thought 
> >>> ext4
> >>> would serialize that kind of buffer_head access...
> >>
> >> Do we know how this is happening?  We've always depended on the VFS to
> >> provide this exclusion.  The only way we should be modifying the
> >> buffer_head at the same time if two CPU's are trying to modify the
> >> directory at the same time, and that should _never_ be happening, even
> >> with the new directory parallism code, unless the file system has
> >> given permission and intends to do its own fine-grained locking.
> > 
> > It's a combination of two things, I think.  The first is that the
> > checksum calculation routine (temporarily) set the checksum field to
> > zero during the computation, which of course is a no-no.  The patch
> > fixes that problem and should go in.
> 
> Thanks a lot for the patch.
> I wrote a small testcase (see below) that triggers the problem quite soon on
> my box with kernel 4.7.0, and seems to have survived so far with kernel
> 4.7.0+patch.
> When it failed it printed something like "readdir: Bad message".
> 
> The drop caches part is quite important for triggering the bug, and might
> explain why this bug was hard to reproduce: IIUC this race condition can
> happen only if 2+ threads/processes try to access the same directory, and the
> directory's inode is not in the cache (i.e. was never cached, or got kicked
> out of the cache).

Could you formulate this into an xfstest, please?  It would be very useful to
have this as a regression test.

(Or attach a Signed-off-by and I'll take care of it eventually.)

--D
> 
> 
> /*
>  $ gcc trigger.c -o trigger -pthread
>  $ ./trigger
> */
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #define FILES 10
> #define THREADS 16
> #define LOOPS 1000
> 
> static void die(const char *msg)
> {
>   perror(msg);
>   exit(EXIT_FAILURE);
> }
> 
> static void* list(void* arg)
> {
>   for(int i=0;i   DIR *d = opendir(".");
>   if (!d) {
>   die("opendir");
>   }
>   errno = 0;
>   while(readdir(d)) {}
>   if (errno) {
>   die("readdir");
>   }
>   closedir(d);
>   FILE *f = fopen("/proc/sys/vm/drop_caches", "w");
>   if (f) {
>   fputs("3", f);
>   fclose(f);
>   }
>   }
>   return NULL;
> }
> 
> int main()
> {
>   pthread_t t[THREADS];
> 
>   if(mkdir("ext4test", 0755) < 0 && errno != EEXIST)
>   die("mkdir");
>   if(chdir("ext4test") < 0)
>   die("chdir");
>   for (unsigned i=0;i < FILES;i++) {
>   char name[16];
>   snprintf(name, sizeof(name), "%d", i); 
>   int fd = open(name, O_WRONLY|O_CREAT, 0600);
>   if (fd < 0)
>   die("open");
>   close(fd);
>   }
>   for (unsigned i=0;i < sizeof(t)/sizeof(t[0]); i++) {
>   pthread_create([i], NULL,list, NULL);
>   }
>   for (unsigned i=0;i < sizeof(t)/sizeof(t[0]); i++) {
>   pthread_join(t[i], NULL);
>   }
>   return 0;
> }
> 
> 
> 
> -- 
> Edwin Török | Co-founder and Lead Developer
> 
> Skylable open-source object storage: reliable, fast, secure
> http://www.skylable.com

Re: 4.7.0-rc7 ext4 error in dx_probe

[Darrick J. Wong]

On Tue, Aug 09, 2016 at 12:13:01AM +0300, Török Edwin wrote:
> On 2016-08-08 19:55, Darrick J. Wong wrote:
> > On Mon, Aug 08, 2016 at 12:08:18PM -0400, Theodore Ts'o wrote:
> >> On Sun, Aug 07, 2016 at 11:28:10PM -0700, Darrick J. Wong wrote:
> >>>
> >>> I have one lingering concern -- is it a bug that two processes could be
> >>> computing the checksum of a buffer simultaneously?  I would have thought 
> >>> ext4
> >>> would serialize that kind of buffer_head access...
> >>
> >> Do we know how this is happening?  We've always depended on the VFS to
> >> provide this exclusion.  The only way we should be modifying the
> >> buffer_head at the same time if two CPU's are trying to modify the
> >> directory at the same time, and that should _never_ be happening, even
> >> with the new directory parallism code, unless the file system has
> >> given permission and intends to do its own fine-grained locking.
> > 
> > It's a combination of two things, I think.  The first is that the
> > checksum calculation routine (temporarily) set the checksum field to
> > zero during the computation, which of course is a no-no.  The patch
> > fixes that problem and should go in.
> 
> Thanks a lot for the patch.
> I wrote a small testcase (see below) that triggers the problem quite soon on
> my box with kernel 4.7.0, and seems to have survived so far with kernel
> 4.7.0+patch.
> When it failed it printed something like "readdir: Bad message".
> 
> The drop caches part is quite important for triggering the bug, and might
> explain why this bug was hard to reproduce: IIUC this race condition can
> happen only if 2+ threads/processes try to access the same directory, and the
> directory's inode is not in the cache (i.e. was never cached, or got kicked
> out of the cache).

Could you formulate this into an xfstest, please?  It would be very useful to
have this as a regression test.

(Or attach a Signed-off-by and I'll take care of it eventually.)

--D
> 
> 
> /*
>  $ gcc trigger.c -o trigger -pthread
>  $ ./trigger
> */
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #define FILES 10
> #define THREADS 16
> #define LOOPS 1000
> 
> static void die(const char *msg)
> {
>   perror(msg);
>   exit(EXIT_FAILURE);
> }
> 
> static void* list(void* arg)
> {
>   for(int i=0;i   DIR *d = opendir(".");
>   if (!d) {
>   die("opendir");
>   }
>   errno = 0;
>   while(readdir(d)) {}
>   if (errno) {
>   die("readdir");
>   }
>   closedir(d);
>   FILE *f = fopen("/proc/sys/vm/drop_caches", "w");
>   if (f) {
>   fputs("3", f);
>   fclose(f);
>   }
>   }
>   return NULL;
> }
> 
> int main()
> {
>   pthread_t t[THREADS];
> 
>   if(mkdir("ext4test", 0755) < 0 && errno != EEXIST)
>   die("mkdir");
>   if(chdir("ext4test") < 0)
>   die("chdir");
>   for (unsigned i=0;i < FILES;i++) {
>   char name[16];
>   snprintf(name, sizeof(name), "%d", i); 
>   int fd = open(name, O_WRONLY|O_CREAT, 0600);
>   if (fd < 0)
>   die("open");
>   close(fd);
>   }
>   for (unsigned i=0;i < sizeof(t)/sizeof(t[0]); i++) {
>   pthread_create([i], NULL,list, NULL);
>   }
>   for (unsigned i=0;i < sizeof(t)/sizeof(t[0]); i++) {
>   pthread_join(t[i], NULL);
>   }
>   return 0;
> }
> 
> 
> 
> -- 
> Edwin Török | Co-founder and Lead Developer
> 
> Skylable open-source object storage: reliable, fast, secure
> http://www.skylable.com

Re: [PATCH v2] drm/bridge: analogix_dp: Ensure the panel is properly prepared/unprepared

[Yakir Yang]

+ Archit


On 08/09/2016 02:53 AM, Sean Paul wrote:

Instead of just preparing the panel on bind, actually prepare/unprepare
during modeset/disable. The panel must be prepared in order to read hpd
status and edid, so we need to keep state around the prepares in order
to ensure we don't accidentally turn the panel off at the wrong time.

Signed-off-by: Sean Paul 


Reviewed-by: Yakir Yang 

And I also tested this patch on RK3399 Kevin board, panel works rightly, so:
Tested-by: Yakir Yang 

Also add Archit into CC list, guess this patch should go through his 
drm_bridge's tree.


Thanks,
- Yakir


---

Changes in v2:
  - Added panel_is_modeset state/lock to avoid racing detect with modeset 
(marcheu)
  - Added prepare/unprepare in .get_modes (yakir)

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 101 ++---
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   3 +
  2 files changed, 93 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 32715da..47c449a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -923,11 +923,63 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
analogix_dp_start_video(dp);
  }
  
+/*

+ * This function is a bit of a catch-all for panel preparation, hopefully
+ * simplifying the logic of functions that need to prepare/unprepare the panel
+ * below.
+ *
+ * If @prepare is true, this function will prepare the panel. Conversely, if it
+ * is false, the panel will be unprepared.
+ *
+ * If @is_modeset_prepare is true, the function will disregard the current 
state
+ * of the panel and either prepare/unprepare the panel based on @prepare. Once
+ * it finishes, it will update dp->panel_is_modeset to reflect the current 
state
+ * of the panel.
+ */
+static int analogix_dp_prepare_panel(struct analogix_dp_device *dp,
+bool prepare, bool is_modeset_prepare)
+{
+   int ret = 0;
+
+   if (!dp->plat_data->panel)
+   return 0;
+
+   mutex_lock(>panel_lock);
+
+   /*
+* Exit early if this is a temporary prepare/unprepare and we're already
+* modeset (since we neither want to prepare twice or unprepare early).
+*/
+   if (dp->panel_is_modeset && !is_modeset_prepare)
+   goto out;
+
+   if (prepare)
+   ret = drm_panel_prepare(dp->plat_data->panel);
+   else
+   ret = drm_panel_unprepare(dp->plat_data->panel);
+
+   if (ret)
+   goto out;
+
+   if (is_modeset_prepare)
+   dp->panel_is_modeset = prepare;
+
+out:
+   mutex_unlock(>panel_lock);
+   return ret;
+}
+
  int analogix_dp_get_modes(struct drm_connector *connector)
  {
struct analogix_dp_device *dp = to_dp(connector);
struct edid *edid = (struct edid *)dp->edid;
-   int num_modes = 0;
+   int ret, num_modes = 0;
+
+   ret = analogix_dp_prepare_panel(dp, true, false);
+   if (ret) {
+   DRM_ERROR("Failed to prepare panel (%d)\n", ret);
+   return 0;
+   }
  
  	if (analogix_dp_handle_edid(dp) == 0) {

drm_mode_connector_update_edid_property(>connector, edid);
@@ -940,6 +992,10 @@ int analogix_dp_get_modes(struct drm_connector *connector)
if (dp->plat_data->get_modes)
num_modes += dp->plat_data->get_modes(dp->plat_data, connector);
  
+	ret = analogix_dp_prepare_panel(dp, false, false);

+   if (ret)
+   DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
+
return num_modes;
  }
  
@@ -960,11 +1016,23 @@ enum drm_connector_status

  analogix_dp_detect(struct drm_connector *connector, bool force)
  {
struct analogix_dp_device *dp = to_dp(connector);
+   enum drm_connector_status status = connector_status_disconnected;
+   int ret;
  
-	if (analogix_dp_detect_hpd(dp))

+   ret = analogix_dp_prepare_panel(dp, true, false);
+   if (ret) {
+   DRM_ERROR("Failed to prepare panel (%d)\n", ret);
return connector_status_disconnected;
+   }
+
+   if (!analogix_dp_detect_hpd(dp))
+   status = connector_status_connected;
  
-	return connector_status_connected;

+   ret = analogix_dp_prepare_panel(dp, false, false);
+   if (ret)
+   DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
+
+   return status;
  }
  
  static void analogix_dp_connector_destroy(struct drm_connector *connector)

@@ -1035,6 +1103,16 @@ static int analogix_dp_bridge_attach(struct drm_bridge 
*bridge)
return 0;
  }
  
+static void analogix_dp_bridge_pre_enable(struct drm_bridge *bridge)

+{
+   struct analogix_dp_device *dp = bridge->driver_private;
+   int ret;
+
+   ret = 

Re: [PATCH v2] drm/bridge: analogix_dp: Ensure the panel is properly prepared/unprepared

[Yakir Yang]

+ Archit


On 08/09/2016 02:53 AM, Sean Paul wrote:

Instead of just preparing the panel on bind, actually prepare/unprepare
during modeset/disable. The panel must be prepared in order to read hpd
status and edid, so we need to keep state around the prepares in order
to ensure we don't accidentally turn the panel off at the wrong time.

Signed-off-by: Sean Paul 


Reviewed-by: Yakir Yang 

And I also tested this patch on RK3399 Kevin board, panel works rightly, so:
Tested-by: Yakir Yang 

Also add Archit into CC list, guess this patch should go through his 
drm_bridge's tree.


Thanks,
- Yakir


---

Changes in v2:
  - Added panel_is_modeset state/lock to avoid racing detect with modeset 
(marcheu)
  - Added prepare/unprepare in .get_modes (yakir)

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 101 ++---
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   3 +
  2 files changed, 93 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 32715da..47c449a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -923,11 +923,63 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
analogix_dp_start_video(dp);
  }
  
+/*

+ * This function is a bit of a catch-all for panel preparation, hopefully
+ * simplifying the logic of functions that need to prepare/unprepare the panel
+ * below.
+ *
+ * If @prepare is true, this function will prepare the panel. Conversely, if it
+ * is false, the panel will be unprepared.
+ *
+ * If @is_modeset_prepare is true, the function will disregard the current 
state
+ * of the panel and either prepare/unprepare the panel based on @prepare. Once
+ * it finishes, it will update dp->panel_is_modeset to reflect the current 
state
+ * of the panel.
+ */
+static int analogix_dp_prepare_panel(struct analogix_dp_device *dp,
+bool prepare, bool is_modeset_prepare)
+{
+   int ret = 0;
+
+   if (!dp->plat_data->panel)
+   return 0;
+
+   mutex_lock(>panel_lock);
+
+   /*
+* Exit early if this is a temporary prepare/unprepare and we're already
+* modeset (since we neither want to prepare twice or unprepare early).
+*/
+   if (dp->panel_is_modeset && !is_modeset_prepare)
+   goto out;
+
+   if (prepare)
+   ret = drm_panel_prepare(dp->plat_data->panel);
+   else
+   ret = drm_panel_unprepare(dp->plat_data->panel);
+
+   if (ret)
+   goto out;
+
+   if (is_modeset_prepare)
+   dp->panel_is_modeset = prepare;
+
+out:
+   mutex_unlock(>panel_lock);
+   return ret;
+}
+
  int analogix_dp_get_modes(struct drm_connector *connector)
  {
struct analogix_dp_device *dp = to_dp(connector);
struct edid *edid = (struct edid *)dp->edid;
-   int num_modes = 0;
+   int ret, num_modes = 0;
+
+   ret = analogix_dp_prepare_panel(dp, true, false);
+   if (ret) {
+   DRM_ERROR("Failed to prepare panel (%d)\n", ret);
+   return 0;
+   }
  
  	if (analogix_dp_handle_edid(dp) == 0) {

drm_mode_connector_update_edid_property(>connector, edid);
@@ -940,6 +992,10 @@ int analogix_dp_get_modes(struct drm_connector *connector)
if (dp->plat_data->get_modes)
num_modes += dp->plat_data->get_modes(dp->plat_data, connector);
  
+	ret = analogix_dp_prepare_panel(dp, false, false);

+   if (ret)
+   DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
+
return num_modes;
  }
  
@@ -960,11 +1016,23 @@ enum drm_connector_status

  analogix_dp_detect(struct drm_connector *connector, bool force)
  {
struct analogix_dp_device *dp = to_dp(connector);
+   enum drm_connector_status status = connector_status_disconnected;
+   int ret;
  
-	if (analogix_dp_detect_hpd(dp))

+   ret = analogix_dp_prepare_panel(dp, true, false);
+   if (ret) {
+   DRM_ERROR("Failed to prepare panel (%d)\n", ret);
return connector_status_disconnected;
+   }
+
+   if (!analogix_dp_detect_hpd(dp))
+   status = connector_status_connected;
  
-	return connector_status_connected;

+   ret = analogix_dp_prepare_panel(dp, false, false);
+   if (ret)
+   DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
+
+   return status;
  }
  
  static void analogix_dp_connector_destroy(struct drm_connector *connector)

@@ -1035,6 +1103,16 @@ static int analogix_dp_bridge_attach(struct drm_bridge 
*bridge)
return 0;
  }
  
+static void analogix_dp_bridge_pre_enable(struct drm_bridge *bridge)

+{
+   struct analogix_dp_device *dp = bridge->driver_private;
+   int ret;
+
+   ret = analogix_dp_prepare_panel(dp, true, true);
+   if (ret)
+   

Build and qemu test results for v4.8-rc1

[Guenter Roeck]

Build results:
total: 148 pass: 142 fail: 6
Failed builds:
h8300:allnoconfig
h8300:edosk2674_defconfig
h8300:h8300h-sim_defconfig
h8300:h8s-sim_defconfig
unicore32:defconfig
unicore32:allnoconfig

Qemu test results:
total: 107 pass: 104 fail: 3
Failed tests:
arm:kzm:imx_v6_v7_defconfig
powerpc:nosmp:ppc64_e5500_defconfig
powerpc:smp:ppc64_e5500_defconfig

===
h8300:

arch/h8300/include/asm/io.h:9:15: error: unknown type name ‘u8’
arch/h8300/include/asm/io.h:9:58: error: expected ‘;’, ‘,’ or ‘)’ before ‘*’ 
token
[and many more similar errors]

Fixed with [1]

---
unicore32:

mm/gup.c: In function ‘check_vma_flags’:
mm/gup.c:458: error: too many arguments to function ‘arch_vma_access_permitted’
mm/gup.c: In function ‘vma_permits_fault’:
gup.c:642: error: too many arguments to function ‘arch_vma_access_permitted’

Fixed with [2]

---
qemu arm:kzm:imx_v6_v7_defconfig:

Failed to create /dev/root: -14
...
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

See [3]

---
qemu powerpc:nosmp:qemu_ppc64_e5500_defconfig:
qemu powerpc:smp:qemu_ppc64_e5500_defconfig:

./arch/powerpc/include/asm/cputhreads.h: In function 'get_tensr':
./arch/powerpc/include/asm/cputhreads.h:101:2: error: implicit declaration of 
function 'cpu_has_feature'

Fixed with [4]


---
[1] https://patchwork.kernel.org/patch/9166177/
[2] https://patchwork.kernel.org/patch/8631791/
[3] https://lkml.org/lkml/2016/8/2/2085
[4] https://patchwork.kernel.org/patch/9266131/

Build and qemu test results for v4.8-rc1

[Guenter Roeck]

Build results:
total: 148 pass: 142 fail: 6
Failed builds:
h8300:allnoconfig
h8300:edosk2674_defconfig
h8300:h8300h-sim_defconfig
h8300:h8s-sim_defconfig
unicore32:defconfig
unicore32:allnoconfig

Qemu test results:
total: 107 pass: 104 fail: 3
Failed tests:
arm:kzm:imx_v6_v7_defconfig
powerpc:nosmp:ppc64_e5500_defconfig
powerpc:smp:ppc64_e5500_defconfig

===
h8300:

arch/h8300/include/asm/io.h:9:15: error: unknown type name ‘u8’
arch/h8300/include/asm/io.h:9:58: error: expected ‘;’, ‘,’ or ‘)’ before ‘*’ 
token
[and many more similar errors]

Fixed with [1]

---
unicore32:

mm/gup.c: In function ‘check_vma_flags’:
mm/gup.c:458: error: too many arguments to function ‘arch_vma_access_permitted’
mm/gup.c: In function ‘vma_permits_fault’:
gup.c:642: error: too many arguments to function ‘arch_vma_access_permitted’

Fixed with [2]

---
qemu arm:kzm:imx_v6_v7_defconfig:

Failed to create /dev/root: -14
...
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

See [3]

---
qemu powerpc:nosmp:qemu_ppc64_e5500_defconfig:
qemu powerpc:smp:qemu_ppc64_e5500_defconfig:

./arch/powerpc/include/asm/cputhreads.h: In function 'get_tensr':
./arch/powerpc/include/asm/cputhreads.h:101:2: error: implicit declaration of 
function 'cpu_has_feature'

Fixed with [4]


---
[1] https://patchwork.kernel.org/patch/9166177/
[2] https://patchwork.kernel.org/patch/8631791/
[3] https://lkml.org/lkml/2016/8/2/2085
[4] https://patchwork.kernel.org/patch/9266131/

Re: [lkp] [fs] 45ec18d5c7: BUG: KASAN: user-memory-access on address 00007f90291c7ec0

[Valdis . Kletnieks]

On Tue, 09 Aug 2016 09:17:58 +0800, Ye Xiaolong said:
> On 08/08, valdis.kletni...@vt.edu wrote:
> > In other words - how did this patch get into a tree that 0day listens to?
>
> 0Day has a service to automatically capture every patchset sent to LKML

Something's wrong then.  Nick has proven to be such a maintainer time-sink
that he's not allowed to post to LKML - or any other list on vger.kernel.org.

So how did he get past that and get 0day to see it?


pgpTMNuwSGZuj.pgp
Description: PGP signature

Re: [lkp] [fs] 45ec18d5c7: BUG: KASAN: user-memory-access on address 00007f90291c7ec0

[Valdis . Kletnieks]

On Tue, 09 Aug 2016 09:17:58 +0800, Ye Xiaolong said:
> On 08/08, valdis.kletni...@vt.edu wrote:
> > In other words - how did this patch get into a tree that 0day listens to?
>
> 0Day has a service to automatically capture every patchset sent to LKML

Something's wrong then.  Nick has proven to be such a maintainer time-sink
that he's not allowed to post to LKML - or any other list on vger.kernel.org.

So how did he get past that and get 0day to see it?


pgpTMNuwSGZuj.pgp
Description: PGP signature