Re: [PATCH v2 0/3] perf/buildid-cache: Add --list and --purge-all options

[Masami Hiramatsu]

On Tue, 17 Apr 2018 09:43:43 +0530
Ravi Bangoria  wrote:

> First patch is a trivial error message fix. Second and third
> adds new options --list and --purge-all to 'buildid-cache'
> subcommand.
> 
> v2 changes:
>  - [PATCH v2 2/3] Display optput of 'perf buildid-cache -l' same as
>'perf buildid-list'.
>  - [PATCH v2 2/3] Other minor changes as suggested by Jiri.
> 
> v1 can be found at:
>   https://lkml.org/lkml/2018/4/9/295

All patches in this series looks good to me.

Acked-by: Masami Hiramatsu 

Thanks,

> 
> Ravi Bangoria (3):
>   tools/parse-options: Add '\n' at the end of error messages
>   perf/buildid-cache: Support --list option
>   perf/buildid-cache: Support --purge-all option
> 
>  tools/lib/subcmd/parse-options.c|  6 +-
>  tools/perf/Documentation/perf-buildid-cache.txt |  7 ++-
>  tools/perf/builtin-buildid-cache.c  | 77 
> -
>  3 files changed, 83 insertions(+), 7 deletions(-)
> 
> -- 
> 2.14.3
> 


-- 
Masami Hiramatsu 

Re: [PATCH v2 0/3] perf/buildid-cache: Add --list and --purge-all options

[Masami Hiramatsu]

On Tue, 17 Apr 2018 09:43:43 +0530
Ravi Bangoria  wrote:

> First patch is a trivial error message fix. Second and third
> adds new options --list and --purge-all to 'buildid-cache'
> subcommand.
> 
> v2 changes:
>  - [PATCH v2 2/3] Display optput of 'perf buildid-cache -l' same as
>'perf buildid-list'.
>  - [PATCH v2 2/3] Other minor changes as suggested by Jiri.
> 
> v1 can be found at:
>   https://lkml.org/lkml/2018/4/9/295

All patches in this series looks good to me.

Acked-by: Masami Hiramatsu 

Thanks,

> 
> Ravi Bangoria (3):
>   tools/parse-options: Add '\n' at the end of error messages
>   perf/buildid-cache: Support --list option
>   perf/buildid-cache: Support --purge-all option
> 
>  tools/lib/subcmd/parse-options.c|  6 +-
>  tools/perf/Documentation/perf-buildid-cache.txt |  7 ++-
>  tools/perf/builtin-buildid-cache.c  | 77 
> -
>  3 files changed, 83 insertions(+), 7 deletions(-)
> 
> -- 
> 2.14.3
> 


-- 
Masami Hiramatsu 

Re: [PATCH 3/3] perf/buildid-cache: Support --purge-all option

[Masami Hiramatsu]

On Mon, 16 Apr 2018 12:30:17 +0200
Jiri Olsa  wrote:

> On Mon, Apr 16, 2018 at 03:10:40PM +0530, Ravi Bangoria wrote:
> > Hi Masami,
> > 
> > On 04/16/2018 02:57 PM, Masami Hiramatsu wrote:
> > > On Mon,  9 Apr 2018 16:36:33 +0530
> > > Ravi Bangoria  wrote:
> > >
> > >> User can remove files from cache using --remove/--purge options
> > >> but both needs list of files as an argument. It's not convenient
> > >> when you want to flush out entire cache. Add an option to purge
> > >> all files from cache.
> > >>
> > >> Ex,
> > >>   # perf buildid-cache -l
> > >> /tmp/a.out (8a86ef73e44067bca52cc3f6cd3e5446c783391c)
> > >> /tmp/a.out.1 (ebe71fdcf4b366518cc154d570a33cd461a51c36)
> > >>   # perf buildid-cache -P -v
> > >> Removing /tmp/a.out (8a86ef73e44067bca52cc3f6cd3e5446c783391c): Ok
> > >> Removing /tmp/a.out.1 (ebe71fdcf4b366518cc154d570a33cd461a51c36): Ok
> > >> Purged all: Ok
> > > Hmm, for purging all caches will be done by
> > >
> > > $ rm -rf ~/.debug
> > >
> > > Are there any difference?
> > 
> > No logical difference if you know it's ~/.debug where it goes. :)
> > I also used to do rm -rf earlier.
> > 
> > This option is for a perf users. But I'm fine if it's not really needed.
> > Will drop it.
> 
> I'd keep it.. as you said it could be configured at some other dir

Sounds reasonable. :)

Thanks,

> 
> jirka


-- 
Masami Hiramatsu 

Re: [PATCH 3/3] perf/buildid-cache: Support --purge-all option

[Masami Hiramatsu]

On Mon, 16 Apr 2018 12:30:17 +0200
Jiri Olsa  wrote:

> On Mon, Apr 16, 2018 at 03:10:40PM +0530, Ravi Bangoria wrote:
> > Hi Masami,
> > 
> > On 04/16/2018 02:57 PM, Masami Hiramatsu wrote:
> > > On Mon,  9 Apr 2018 16:36:33 +0530
> > > Ravi Bangoria  wrote:
> > >
> > >> User can remove files from cache using --remove/--purge options
> > >> but both needs list of files as an argument. It's not convenient
> > >> when you want to flush out entire cache. Add an option to purge
> > >> all files from cache.
> > >>
> > >> Ex,
> > >>   # perf buildid-cache -l
> > >> /tmp/a.out (8a86ef73e44067bca52cc3f6cd3e5446c783391c)
> > >> /tmp/a.out.1 (ebe71fdcf4b366518cc154d570a33cd461a51c36)
> > >>   # perf buildid-cache -P -v
> > >> Removing /tmp/a.out (8a86ef73e44067bca52cc3f6cd3e5446c783391c): Ok
> > >> Removing /tmp/a.out.1 (ebe71fdcf4b366518cc154d570a33cd461a51c36): Ok
> > >> Purged all: Ok
> > > Hmm, for purging all caches will be done by
> > >
> > > $ rm -rf ~/.debug
> > >
> > > Are there any difference?
> > 
> > No logical difference if you know it's ~/.debug where it goes. :)
> > I also used to do rm -rf earlier.
> > 
> > This option is for a perf users. But I'm fine if it's not really needed.
> > Will drop it.
> 
> I'd keep it.. as you said it could be configured at some other dir

Sounds reasonable. :)

Thanks,

> 
> jirka


-- 
Masami Hiramatsu 

Re: [PATCH v6 07/11] ARM: sun9i: smp: Rename clusters's power-off

[Mylène Josserand]

Hello,

On Tue, 17 Apr 2018 11:21:02 +0300
Sergei Shtylyov  wrote:

> Hello!
> 
> On 4/17/2018 12:50 AM, Mylène Josserand wrote:
> 
> > To prepare the support for sun8i-a83t, rename the variable name  
> 
> s/variable/macro/ maybe? Also "rename the ... name" sounds tautological...

Thank you for the correction.

Best regards,

Mylène

-- 
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

> 
> > that handles the power-off of clusters because it is different from
> > sun9i-a80 to sun8i-a83t.
> > 
> > The power off register for clusters are different from a80 and a83t.
> > 
> > Signed-off-by: Mylène Josserand 
> > Acked-by: Maxime Ripard 
> > Reviewed-by: Chen-Yu Tsai 
> > ---
> >   arch/arm/mach-sunxi/mc_smp.c | 6 +++---
> >   1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
> > index 727968d6a3e5..03f021d0c73e 100644
> > --- a/arch/arm/mach-sunxi/mc_smp.c
> > +++ b/arch/arm/mach-sunxi/mc_smp.c
> > @@ -60,7 +60,7 @@
> >   #define PRCM_CPU_PO_RST_CTRL_CORE(n)  BIT(n)
> >   #define PRCM_CPU_PO_RST_CTRL_CORE_ALL 0xf
> >   #define PRCM_PWROFF_GATING_REG(c) (0x100 + 0x4 * (c))
> > -#define PRCM_PWROFF_GATING_REG_CLUSTER BIT(4)
> > +#define PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I   BIT(4)
> >   #define PRCM_PWROFF_GATING_REG_CORE(n)BIT(n)
> >   #define PRCM_PWR_SWITCH_REG(c, cpu)   (0x140 + 0x10 * (c) + 0x4 * 
> > (cpu))
> >   #define PRCM_CPU_SOFT_ENTRY_REG   0x164
> > @@ -255,7 +255,7 @@ static int sunxi_cluster_powerup(unsigned int cluster)
> >   
> > /* clear cluster power gate */
> > reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
> > -   reg &= ~PRCM_PWROFF_GATING_REG_CLUSTER;
> > +   reg &= ~PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I;
> > writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
> > udelay(20);
> >   
> > @@ -452,7 +452,7 @@ static int sunxi_cluster_powerdown(unsigned int cluster)
> > /* gate cluster power */
> > pr_debug("%s: gate cluster power\n", __func__);
> > reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
> > -   reg |= PRCM_PWROFF_GATING_REG_CLUSTER;
> > +   reg |= PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I;
> > writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
> > udelay(20);
> > 
> 
> MBR, Sergei

Re: [PATCH v6 07/11] ARM: sun9i: smp: Rename clusters's power-off

[Mylène Josserand]

Hello,

On Tue, 17 Apr 2018 11:21:02 +0300
Sergei Shtylyov  wrote:

> Hello!
> 
> On 4/17/2018 12:50 AM, Mylène Josserand wrote:
> 
> > To prepare the support for sun8i-a83t, rename the variable name  
> 
> s/variable/macro/ maybe? Also "rename the ... name" sounds tautological...

Thank you for the correction.

Best regards,

Mylène

-- 
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

> 
> > that handles the power-off of clusters because it is different from
> > sun9i-a80 to sun8i-a83t.
> > 
> > The power off register for clusters are different from a80 and a83t.
> > 
> > Signed-off-by: Mylène Josserand 
> > Acked-by: Maxime Ripard 
> > Reviewed-by: Chen-Yu Tsai 
> > ---
> >   arch/arm/mach-sunxi/mc_smp.c | 6 +++---
> >   1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
> > index 727968d6a3e5..03f021d0c73e 100644
> > --- a/arch/arm/mach-sunxi/mc_smp.c
> > +++ b/arch/arm/mach-sunxi/mc_smp.c
> > @@ -60,7 +60,7 @@
> >   #define PRCM_CPU_PO_RST_CTRL_CORE(n)  BIT(n)
> >   #define PRCM_CPU_PO_RST_CTRL_CORE_ALL 0xf
> >   #define PRCM_PWROFF_GATING_REG(c) (0x100 + 0x4 * (c))
> > -#define PRCM_PWROFF_GATING_REG_CLUSTER BIT(4)
> > +#define PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I   BIT(4)
> >   #define PRCM_PWROFF_GATING_REG_CORE(n)BIT(n)
> >   #define PRCM_PWR_SWITCH_REG(c, cpu)   (0x140 + 0x10 * (c) + 0x4 * 
> > (cpu))
> >   #define PRCM_CPU_SOFT_ENTRY_REG   0x164
> > @@ -255,7 +255,7 @@ static int sunxi_cluster_powerup(unsigned int cluster)
> >   
> > /* clear cluster power gate */
> > reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
> > -   reg &= ~PRCM_PWROFF_GATING_REG_CLUSTER;
> > +   reg &= ~PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I;
> > writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
> > udelay(20);
> >   
> > @@ -452,7 +452,7 @@ static int sunxi_cluster_powerdown(unsigned int cluster)
> > /* gate cluster power */
> > pr_debug("%s: gate cluster power\n", __func__);
> > reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
> > -   reg |= PRCM_PWROFF_GATING_REG_CLUSTER;
> > +   reg |= PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I;
> > writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
> > udelay(20);
> > 
> 
> MBR, Sergei

Re: [PATCH v6 00/11] Sunxi: Add SMP support on A83T

[Mylène Josserand]

Hello Ondrej,

On Tue, 17 Apr 2018 04:15:00 +0200
Ondřej Jirman  wrote:

> Hello Mylène,
> 
> Please also add this:
> 
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index ce53ceaf4cc5..d9c8ecf88ec6 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -51,7 +51,7 @@ config MACH_SUN9I
>  config ARCH_SUNXI_MC_SMP
> bool
> depends on SMP
> -   default MACH_SUN9I
> + default MACH_SUN9I || MACH_SUN8I
> select ARM_CCI400_PORT_CTRL
> select ARM_CPU_SUSPEND
> 
> Because otherwise when I'm building kernel just for sun8i and I don't have 
> sun9i
> enabled, this new SMP code for A83T (which is sun8i) will not be built.
> 

True, I forgot to add this, thanks!

Best regards,

Mylène

-- 
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


> thank you,
>   Ondrej
> 
> On Mon, Apr 16, 2018 at 11:50:21PM +0200, Mylène Josserand wrote:
> > Hello everyone,
> > 
> > This is a V6 of my series that adds SMP support for Allwinner sun8i-a83t.
> > Based on sunxi's tree, sunxi/for-next branch.
> > Depends on a patch from Doug Berger that allows to include the "cpu-type"
> > header on assembly files:
> > 6c7dd080ba4b ("ARM: Allow this header to be included by assembly files")
> > 
> > This new series refactors the shmobile code to use the function introduced
> > in this series: "secure_cntvoff_init".
> > Geert Uytterhoeven and Simon Horman, could you review and test this series
> > on Renesas boards? Thank you very much!
> > 
> > If you have any remarks/questions, let me know.
> > Thank you in advance,
> > Mylène
> > 
> > Changes since v5:
> > - Remove my patch 01 and use the patch of Doug Berger to be able to
> > include the cpu-type header on assembly files.
> > - Rename smp_init_cntvoff function into secure_cntvoff_init according
> > to Marc Zyngier's review.
> > - According to Chen-Yu and Maxime's reviews, remove the patch that was
> > moving structures. Instead of using an index to retrieve which
> > architecture we are having, use a global variable.
> > - Merge the 2 patches that move assembly code from C to assembly file.
> > - Use a sun8i field instead of sun9i to know on which architecture we
> > are using because many modifications/additions of the code are for
> > sun8i-a83t.
> > - Rework the patch "add is_sun8i field" to add only this field in this
> > patch. The part of the patch that was starting to handle the differences
> > between sun8i-a83t and sun9i-a80 is merged in the patch that adds the
> > support of sun8i-a83t.
> > - Add a new patch that refactor the shmobile code to use the new 
> > function
> > secure_cntvoff_init introduced in this series.
> > 
> > Changes since v4:
> > - Rebased my series according to new Chen-Yu series:
> >"ARM: sunxi: Clean and improvements for multi-cluster SMP"
> >https://lkml.org/lkml/2018/3/8/886
> > - Updated my series according to Marc Zyngier's reviews to add CNTVOFF
> > initialization's function into ARM's common part. Thanks to that, other
> > platforms such as Renesa can use this function.
> > - For boot CPU, create a new machine to handle the CNTVOFF 
> > initialization
> > using "init_early" callback.
> > Changes since v3:
> > - Take into account Maxime's reviews:
> > - split the first patch into 4 new patches: add sun9i device tree
> > parsing, rename some variables, add a83t support and finally,
> > add hotplug support.
> > - Move the code of previous patch 07 (to disable CPU0 disabling)
> > into hotplug support patch (see patch 04)
> > - Remove the patch that added PRCM register because it is already
> > available. Because of that, update the device tree parsing to use
> > "sun8i-a83t-r-ccu".
> > - Use a variable to know which SoC we currently have
> > - Take into account Chen-Yu's reviews: create two iounmap functions
> > to release the resources of the device tree parsing.
> > - Take into account Marc's review: Update the code to initialize CNTVOFF
> > register. As there is already assembly code in the driver, I decided
> > to create an assembly file not to mix assembly and C code.
> > For that, I create 3 new patches: move the current assembly code that
> > handles the cluster cache enabling into a file, move the cpu_resume 
> > entry
> > in this file and finally, add a new assembly entry to initialize the 
> > timer
> > offset for boot CPU and secondary CPUs.
> > 
> > Changes since v2:
> > - Rebased my modifications according to new Chen Yu's patch series
> > that adds SMP support for sun9i-a80 (without MCPM).
> > - Split the device-tree patches into 3 patches for CPUCFG, R_CPUCFG
> > and PRCM registers for more visibility.
> > - The hotplug of CPU0 is currently not working (even after 

Re: [PATCH v6 00/11] Sunxi: Add SMP support on A83T

[Mylène Josserand]

Hello Ondrej,

On Tue, 17 Apr 2018 04:15:00 +0200
Ondřej Jirman  wrote:

> Hello Mylène,
> 
> Please also add this:
> 
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index ce53ceaf4cc5..d9c8ecf88ec6 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -51,7 +51,7 @@ config MACH_SUN9I
>  config ARCH_SUNXI_MC_SMP
> bool
> depends on SMP
> -   default MACH_SUN9I
> + default MACH_SUN9I || MACH_SUN8I
> select ARM_CCI400_PORT_CTRL
> select ARM_CPU_SUSPEND
> 
> Because otherwise when I'm building kernel just for sun8i and I don't have 
> sun9i
> enabled, this new SMP code for A83T (which is sun8i) will not be built.
> 

True, I forgot to add this, thanks!

Best regards,

Mylène

-- 
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


> thank you,
>   Ondrej
> 
> On Mon, Apr 16, 2018 at 11:50:21PM +0200, Mylène Josserand wrote:
> > Hello everyone,
> > 
> > This is a V6 of my series that adds SMP support for Allwinner sun8i-a83t.
> > Based on sunxi's tree, sunxi/for-next branch.
> > Depends on a patch from Doug Berger that allows to include the "cpu-type"
> > header on assembly files:
> > 6c7dd080ba4b ("ARM: Allow this header to be included by assembly files")
> > 
> > This new series refactors the shmobile code to use the function introduced
> > in this series: "secure_cntvoff_init".
> > Geert Uytterhoeven and Simon Horman, could you review and test this series
> > on Renesas boards? Thank you very much!
> > 
> > If you have any remarks/questions, let me know.
> > Thank you in advance,
> > Mylène
> > 
> > Changes since v5:
> > - Remove my patch 01 and use the patch of Doug Berger to be able to
> > include the cpu-type header on assembly files.
> > - Rename smp_init_cntvoff function into secure_cntvoff_init according
> > to Marc Zyngier's review.
> > - According to Chen-Yu and Maxime's reviews, remove the patch that was
> > moving structures. Instead of using an index to retrieve which
> > architecture we are having, use a global variable.
> > - Merge the 2 patches that move assembly code from C to assembly file.
> > - Use a sun8i field instead of sun9i to know on which architecture we
> > are using because many modifications/additions of the code are for
> > sun8i-a83t.
> > - Rework the patch "add is_sun8i field" to add only this field in this
> > patch. The part of the patch that was starting to handle the differences
> > between sun8i-a83t and sun9i-a80 is merged in the patch that adds the
> > support of sun8i-a83t.
> > - Add a new patch that refactor the shmobile code to use the new 
> > function
> > secure_cntvoff_init introduced in this series.
> > 
> > Changes since v4:
> > - Rebased my series according to new Chen-Yu series:
> >"ARM: sunxi: Clean and improvements for multi-cluster SMP"
> >https://lkml.org/lkml/2018/3/8/886
> > - Updated my series according to Marc Zyngier's reviews to add CNTVOFF
> > initialization's function into ARM's common part. Thanks to that, other
> > platforms such as Renesa can use this function.
> > - For boot CPU, create a new machine to handle the CNTVOFF 
> > initialization
> > using "init_early" callback.
> > Changes since v3:
> > - Take into account Maxime's reviews:
> > - split the first patch into 4 new patches: add sun9i device tree
> > parsing, rename some variables, add a83t support and finally,
> > add hotplug support.
> > - Move the code of previous patch 07 (to disable CPU0 disabling)
> > into hotplug support patch (see patch 04)
> > - Remove the patch that added PRCM register because it is already
> > available. Because of that, update the device tree parsing to use
> > "sun8i-a83t-r-ccu".
> > - Use a variable to know which SoC we currently have
> > - Take into account Chen-Yu's reviews: create two iounmap functions
> > to release the resources of the device tree parsing.
> > - Take into account Marc's review: Update the code to initialize CNTVOFF
> > register. As there is already assembly code in the driver, I decided
> > to create an assembly file not to mix assembly and C code.
> > For that, I create 3 new patches: move the current assembly code that
> > handles the cluster cache enabling into a file, move the cpu_resume 
> > entry
> > in this file and finally, add a new assembly entry to initialize the 
> > timer
> > offset for boot CPU and secondary CPUs.
> > 
> > Changes since v2:
> > - Rebased my modifications according to new Chen Yu's patch series
> > that adds SMP support for sun9i-a80 (without MCPM).
> > - Split the device-tree patches into 3 patches for CPUCFG, R_CPUCFG
> > and PRCM registers for more visibility.
> > - The hotplug of CPU0 is currently not working (even after trying what
> > Allwinner's 

Re: cpu stopper threads and load balancing leads to deadlock

[Mike Galbraith]

On Tue, 2018-04-17 at 15:21 +0100, Matt Fleming wrote:
> Hi guys,
> 
> We've seen a bug in one of our SLE kernels where the cpu stopper
> thread ("migration/15") is entering idle balance. This then triggers
> active load balance.
> 
> At the same time, a task on another CPU triggers a page fault and NUMA
> balancing kicks in to try and migrate the task closer to the NUMA node
> for that page (we're inside stop_two_cpus()). This faulting task is
> spinning in try_to_wake_up() (inside smp_cond_load_acquire(>on_cpu,
> !VAL)), waiting for "migration/15" to context switch.
> 
> Unfortunately, because "migration/15" is doing active load balance
> it's spinning waiting for the NUMA-page-faulting CPU's stopper lock,
> which is already held (since it's inside stop_two_cpus()).
> 
> Deadlock ensues.
> 
> This seems like a situation that should be prohibited, but I cannot
> find any code to prevent it. Is it OK for stopper threads to load
> balance? Is there something that should prevent this situation from
> happening?

I don't see anything to stop the deadlock either, would exclude stop
class from playing idle balancer entirely, though I suppose you could
check for caller being stop class in need_active_balance().  I don't
think any RT class playing idle balancer is particularly wonderful.

-Mike

Re: cpu stopper threads and load balancing leads to deadlock

[Mike Galbraith]

On Tue, 2018-04-17 at 15:21 +0100, Matt Fleming wrote:
> Hi guys,
> 
> We've seen a bug in one of our SLE kernels where the cpu stopper
> thread ("migration/15") is entering idle balance. This then triggers
> active load balance.
> 
> At the same time, a task on another CPU triggers a page fault and NUMA
> balancing kicks in to try and migrate the task closer to the NUMA node
> for that page (we're inside stop_two_cpus()). This faulting task is
> spinning in try_to_wake_up() (inside smp_cond_load_acquire(>on_cpu,
> !VAL)), waiting for "migration/15" to context switch.
> 
> Unfortunately, because "migration/15" is doing active load balance
> it's spinning waiting for the NUMA-page-faulting CPU's stopper lock,
> which is already held (since it's inside stop_two_cpus()).
> 
> Deadlock ensues.
> 
> This seems like a situation that should be prohibited, but I cannot
> find any code to prevent it. Is it OK for stopper threads to load
> balance? Is there something that should prevent this situation from
> happening?

I don't see anything to stop the deadlock either, would exclude stop
class from playing idle balancer entirely, though I suppose you could
check for caller being stop class in need_active_balance().  I don't
think any RT class playing idle balancer is particularly wonderful.

-Mike

Re: [PATCH v2] usb: chipidea: Hook into mux framework to toggle usb switch

[yossim]

On 2018-04-17 17:11, Peter Rosin wrote:

On 2018-04-17 15:52, Yossi Mansharoff wrote:

On the db410c 96boards platform we have a TC7USB40MU on the board
to mux the D+/D- lines coming from the controller between a micro
usb "device" port and a USB hub for "host" roles[1]. During a
role switch, we need to toggle this mux to forward the D+/D-
lines to either the port or the hub. Add the necessary code to do
the role switch in chipidea core via the generic mux framework.
Board configurations like on db410c are expected to change roles
via the sysfs API described in
Documentation/ABI/testing/sysfs-platform-chipidea-usb2.


Ok, so this is v2. Please describe what is different from v1.
I have told you before that this information helps.

[1] 
https://github.com/96boards/documentation/raw/master/ConsumerEdition/DragonBoard-410c/HardwareDocs/Schematics_DragonBoard.pdf


This link returns 404 for me.

Cheers,
Peter



Hi,
This patch was split apart from the original patch into two patches
one for chipidea and the other for bindings.
this patch has no other changes two the code.

I will update the link.

thanks
Yossi

Re: [PATCH v2] usb: chipidea: Hook into mux framework to toggle usb switch

[yossim]

On 2018-04-17 17:11, Peter Rosin wrote:

On 2018-04-17 15:52, Yossi Mansharoff wrote:

On the db410c 96boards platform we have a TC7USB40MU on the board
to mux the D+/D- lines coming from the controller between a micro
usb "device" port and a USB hub for "host" roles[1]. During a
role switch, we need to toggle this mux to forward the D+/D-
lines to either the port or the hub. Add the necessary code to do
the role switch in chipidea core via the generic mux framework.
Board configurations like on db410c are expected to change roles
via the sysfs API described in
Documentation/ABI/testing/sysfs-platform-chipidea-usb2.


Ok, so this is v2. Please describe what is different from v1.
I have told you before that this information helps.

[1] 
https://github.com/96boards/documentation/raw/master/ConsumerEdition/DragonBoard-410c/HardwareDocs/Schematics_DragonBoard.pdf


This link returns 404 for me.

Cheers,
Peter



Hi,
This patch was split apart from the original patch into two patches
one for chipidea and the other for bindings.
this patch has no other changes two the code.

I will update the link.

thanks
Yossi

Re: [PATCH v6 09/11] ARM: sun8i: smp: Add support for A83T

[Mylène Josserand]

Hello Maxime,

On Tue, 17 Apr 2018 13:20:38 +0200
Maxime Ripard  wrote:

> On Mon, Apr 16, 2018 at 11:50:30PM +0200, Mylène Josserand wrote:
> > @@ -535,8 +599,12 @@ static int sunxi_mc_smp_cpu_kill(unsigned int l_cpu)
> > return !ret;
> >  }
> >  
> > -static bool sunxi_mc_smp_cpu_can_disable(unsigned int __unused)
> > +static bool sunxi_mc_smp_cpu_can_disable(unsigned int cpu)
> >  {
> > +   /* CPU0 hotplug not handled for sun8i-a83t */
> > +   if (is_sun8i)
> > +   if (cpu == 0)
> > +   return false;
> > return true;  
> 
> I think Chen-Yu told you how to implement the hotplug in the previous
> iteration, did you have time to test it?

Not yet, I will have a look this evening.

Best regards,

-- 
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

Re: [PATCH v6 09/11] ARM: sun8i: smp: Add support for A83T

[Mylène Josserand]

Hello Maxime,

On Tue, 17 Apr 2018 13:20:38 +0200
Maxime Ripard  wrote:

> On Mon, Apr 16, 2018 at 11:50:30PM +0200, Mylène Josserand wrote:
> > @@ -535,8 +599,12 @@ static int sunxi_mc_smp_cpu_kill(unsigned int l_cpu)
> > return !ret;
> >  }
> >  
> > -static bool sunxi_mc_smp_cpu_can_disable(unsigned int __unused)
> > +static bool sunxi_mc_smp_cpu_can_disable(unsigned int cpu)
> >  {
> > +   /* CPU0 hotplug not handled for sun8i-a83t */
> > +   if (is_sun8i)
> > +   if (cpu == 0)
> > +   return false;
> > return true;  
> 
> I think Chen-Yu told you how to implement the hotplug in the previous
> iteration, did you have time to test it?

Not yet, I will have a look this evening.

Best regards,

-- 
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[PATCH RESENT v4] dell_rbu: make firmware payload memory uncachable

[Takashi Iwai]

From: Stuart Hayes 

The dell_rbu driver takes firmware update payloads and puts them in memory so
the system BIOS can find them after a reboot.  This sometimes fails (though
rarely), because the memory containing the payload is in the CPU cache but
never gets written back to main memory before the system is rebooted (CPU
cache contents are lost on reboot).

With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.

Signed-off-by: Stuart Hayes 
Reviewed-by: Takashi Iwai 
Signed-off-by: Takashi Iwai 
---
v2 Added include, removed extra parentheses
v3 Corrected formatting and include line
v4 Moved set_memory_uc() outside the while loop so that the memory is
   definitely allocated before it is set to uncachable

Andrew, could you pick up this orphan one?  Thanks!

diff --git a/drivers/firmware/dell_rbu.c b/drivers/firmware/dell_rbu.c
index 2f452f1f7c8a..53f27a6e2d76 100644
--- a/drivers/firmware/dell_rbu.c
+++ b/drivers/firmware/dell_rbu.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_AUTHOR("Abhay Salunke ");
 MODULE_DESCRIPTION("Driver for updating BIOS image on DELL systems");
@@ -181,6 +182,11 @@ static int create_packet(void *data, size_t length)
packet_data_temp_buf = NULL;
}
}
+   /*
+* set to uncachable or it may never get written back before reboot
+*/
+   set_memory_uc((unsigned long)packet_data_temp_buf, 1 << ordernum);
+
spin_lock(_data.lock);
 
newpacket->data = packet_data_temp_buf;
@@ -349,6 +355,8 @@ static void packet_empty_list(void)
 * to make sure there are no stale RBU packets left in memory
 */
memset(newpacket->data, 0, rbu_data.packetsize);
+   set_memory_wb((unsigned long)newpacket->data,
+   1 << newpacket->ordernum);
free_pages((unsigned long) newpacket->data,
newpacket->ordernum);
kfree(newpacket);

[PATCH RESENT v4] dell_rbu: make firmware payload memory uncachable

[Takashi Iwai]

From: Stuart Hayes 

The dell_rbu driver takes firmware update payloads and puts them in memory so
the system BIOS can find them after a reboot.  This sometimes fails (though
rarely), because the memory containing the payload is in the CPU cache but
never gets written back to main memory before the system is rebooted (CPU
cache contents are lost on reboot).

With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.

Signed-off-by: Stuart Hayes 
Reviewed-by: Takashi Iwai 
Signed-off-by: Takashi Iwai 
---
v2 Added include, removed extra parentheses
v3 Corrected formatting and include line
v4 Moved set_memory_uc() outside the while loop so that the memory is
   definitely allocated before it is set to uncachable

Andrew, could you pick up this orphan one?  Thanks!

diff --git a/drivers/firmware/dell_rbu.c b/drivers/firmware/dell_rbu.c
index 2f452f1f7c8a..53f27a6e2d76 100644
--- a/drivers/firmware/dell_rbu.c
+++ b/drivers/firmware/dell_rbu.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_AUTHOR("Abhay Salunke ");
 MODULE_DESCRIPTION("Driver for updating BIOS image on DELL systems");
@@ -181,6 +182,11 @@ static int create_packet(void *data, size_t length)
packet_data_temp_buf = NULL;
}
}
+   /*
+* set to uncachable or it may never get written back before reboot
+*/
+   set_memory_uc((unsigned long)packet_data_temp_buf, 1 << ordernum);
+
spin_lock(_data.lock);
 
newpacket->data = packet_data_temp_buf;
@@ -349,6 +355,8 @@ static void packet_empty_list(void)
 * to make sure there are no stale RBU packets left in memory
 */
memset(newpacket->data, 0, rbu_data.packetsize);
+   set_memory_wb((unsigned long)newpacket->data,
+   1 << newpacket->ordernum);
free_pages((unsigned long) newpacket->data,
newpacket->ordernum);
kfree(newpacket);

Re: [PATCH] gpu: drm: i915: Change return type to vm_fault_t

[Jani Nikula]

On Tue, 17 Apr 2018, Souptick Joarder  wrote:
> On 17-Apr-2018 9:45 PM, "Matthew Wilcox"  wrote:
>>
>> On Tue, Apr 17, 2018 at 09:14:32PM +0530, Souptick Joarder wrote:
>> > Not exactly. The plan for these patches is to introduce new vm_fault_t
> type
>> > in vm_operations_struct fault handlers. It's now available in 4.17-rc1.
> We will
>> > push all the required drivers/filesystem changes through different
> maintainers
>> > to linus tree. Once everything is converted into vm_fault_t type then
> Changing
>> > it from a signed to an unsigned int causes GCC to warn about an
> assignment
>> > from an incompatible type -- int foo(void) is incompatible with
>> > unsigned int foo(void).
>> >
>> > Please refer 1c8f422059ae ("mm: change return type to vm_fault_t") in
> 4.17-rc1.
>>
>> I think this patch would be clearer if you did
>>
>> -   int ret;
>> +   int err;
>> +   vm_fault_t ret;
>>
>> Then it would be clearer to the maintainer that you're splitting apart the
>> VM_FAULT and errno codes.
>>
>> Sorry for not catching this during initial review.
>
> Ok, I will make required changes and send v2. Sorry, even I missed this :)

I'm afraid Daniel is closer to the truth. My bad, sorry for the noise.

BR,
Jani.



>>
>> > On Tue, Apr 17, 2018 at 8:59 PM, Jani Nikula
>> >  wrote:
>> > > On Tue, 17 Apr 2018, Souptick Joarder  wrote:
>> > >> Use new return type vm_fault_t for fault handler. For
>> > >> now, this is just documenting that the function returns
>> > >> a VM_FAULT value rather than an errno. Once all instances
>> > >> are converted, vm_fault_t will become a distinct type.
>> > >>
>> > >> Reference id -> 1c8f422059ae ("mm: change return type to
>> > >> vm_fault_t")
>> > >>
>> > >> Signed-off-by: Souptick Joarder 
>> > >> ---
>> > >>  drivers/gpu/drm/i915/i915_drv.h |  3 ++-
>> > >>  drivers/gpu/drm/i915/i915_gem.c | 15 ---
>> > >>  2 files changed, 10 insertions(+), 8 deletions(-)
>> > >>
>> > >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
>> > >> index a42deeb..95b0d50 100644
>> > >> --- a/drivers/gpu/drm/i915/i915_drv.h
>> > >> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> > >> @@ -51,6 +51,7 @@
>> > >>  #include 
>> > >>  #include 
>> > >>  #include 
>> > >> +#include 
>> > >>
>> > >>  #include "i915_params.h"
>> > >>  #include "i915_reg.h"
>> > >> @@ -3363,7 +3364,7 @@ int i915_gem_wait_for_idle(struct
> drm_i915_private *dev_priv,
>> > >>  unsigned int flags);
>> > >>  int __must_check i915_gem_suspend(struct drm_i915_private
> *dev_priv);
>> > >>  void i915_gem_resume(struct drm_i915_private *dev_priv);
>> > >> -int i915_gem_fault(struct vm_fault *vmf);
>> > >> +vm_fault_t i915_gem_fault(struct vm_fault *vmf);
>> > >>  int i915_gem_object_wait(struct drm_i915_gem_object *obj,
>> > >>unsigned int flags,
>> > >>long timeout,
>> > >> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
>> > >> index dd89abd..bdac690 100644
>> > >> --- a/drivers/gpu/drm/i915/i915_gem.c
>> > >> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> > >> @@ -1882,7 +1882,7 @@ int i915_gem_mmap_gtt_version(void)
>> > >>   * The current feature set supported by i915_gem_fault() and thus
> GTT mmaps
>> > >>   * is exposed via I915_PARAM_MMAP_GTT_VERSION (see
> i915_gem_mmap_gtt_version).
>> > >>   */
>> > >> -int i915_gem_fault(struct vm_fault *vmf)
>> > >> +vm_fault_t i915_gem_fault(struct vm_fault *vmf)
>> > >>  {
>> > >>  #define MIN_CHUNK_PAGES ((1 << 20) >> PAGE_SHIFT) /* 1 MiB */
>> > >>   struct vm_area_struct *area = vmf->vma;
>> > >> @@ -1895,6 +1895,7 @@ int i915_gem_fault(struct vm_fault *vmf)
>> > >>   pgoff_t page_offset;
>> > >>   unsigned int flags;
>> > >>   int ret;
>> > >> + vm_fault_t retval;
>> > >
>> > > What's the point of changing the name? An unnecessary change.
>> > >
>> > > BR,
>> > > Jani.
>> > >
>> > >>
>> > >>   /* We don't use vmf->pgoff since that has the fake offset */
>> > >>   page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
>> > >> @@ -2000,7 +2001,7 @@ int i915_gem_fault(struct vm_fault *vmf)
>> > >>* and so needs to be reported.
>> > >>*/
>> > >>   if (!i915_terminally_wedged(_priv->gpu_error)) {
>> > >> - ret = VM_FAULT_SIGBUS;
>> > >> + retval = VM_FAULT_SIGBUS;
>> > >>   break;
>> > >>   }
>> > >>   case -EAGAIN:
>> > >> @@ -2017,21 +2018,21 @@ int i915_gem_fault(struct vm_fault *vmf)
>> > >>* EBUSY is ok: this just means that another thread
>> > >>* already did the job.
>> > >>*/
>> > >> - ret = VM_FAULT_NOPAGE;
>> > >> + retval = VM_FAULT_NOPAGE;
>> > >>   break;
>> > >>   case -ENOMEM:

Re: [PATCH] gpu: drm: i915: Change return type to vm_fault_t

[Jani Nikula]

On Tue, 17 Apr 2018, Souptick Joarder  wrote:
> On 17-Apr-2018 9:45 PM, "Matthew Wilcox"  wrote:
>>
>> On Tue, Apr 17, 2018 at 09:14:32PM +0530, Souptick Joarder wrote:
>> > Not exactly. The plan for these patches is to introduce new vm_fault_t
> type
>> > in vm_operations_struct fault handlers. It's now available in 4.17-rc1.
> We will
>> > push all the required drivers/filesystem changes through different
> maintainers
>> > to linus tree. Once everything is converted into vm_fault_t type then
> Changing
>> > it from a signed to an unsigned int causes GCC to warn about an
> assignment
>> > from an incompatible type -- int foo(void) is incompatible with
>> > unsigned int foo(void).
>> >
>> > Please refer 1c8f422059ae ("mm: change return type to vm_fault_t") in
> 4.17-rc1.
>>
>> I think this patch would be clearer if you did
>>
>> -   int ret;
>> +   int err;
>> +   vm_fault_t ret;
>>
>> Then it would be clearer to the maintainer that you're splitting apart the
>> VM_FAULT and errno codes.
>>
>> Sorry for not catching this during initial review.
>
> Ok, I will make required changes and send v2. Sorry, even I missed this :)

I'm afraid Daniel is closer to the truth. My bad, sorry for the noise.

BR,
Jani.



>>
>> > On Tue, Apr 17, 2018 at 8:59 PM, Jani Nikula
>> >  wrote:
>> > > On Tue, 17 Apr 2018, Souptick Joarder  wrote:
>> > >> Use new return type vm_fault_t for fault handler. For
>> > >> now, this is just documenting that the function returns
>> > >> a VM_FAULT value rather than an errno. Once all instances
>> > >> are converted, vm_fault_t will become a distinct type.
>> > >>
>> > >> Reference id -> 1c8f422059ae ("mm: change return type to
>> > >> vm_fault_t")
>> > >>
>> > >> Signed-off-by: Souptick Joarder 
>> > >> ---
>> > >>  drivers/gpu/drm/i915/i915_drv.h |  3 ++-
>> > >>  drivers/gpu/drm/i915/i915_gem.c | 15 ---
>> > >>  2 files changed, 10 insertions(+), 8 deletions(-)
>> > >>
>> > >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
>> > >> index a42deeb..95b0d50 100644
>> > >> --- a/drivers/gpu/drm/i915/i915_drv.h
>> > >> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> > >> @@ -51,6 +51,7 @@
>> > >>  #include 
>> > >>  #include 
>> > >>  #include 
>> > >> +#include 
>> > >>
>> > >>  #include "i915_params.h"
>> > >>  #include "i915_reg.h"
>> > >> @@ -3363,7 +3364,7 @@ int i915_gem_wait_for_idle(struct
> drm_i915_private *dev_priv,
>> > >>  unsigned int flags);
>> > >>  int __must_check i915_gem_suspend(struct drm_i915_private
> *dev_priv);
>> > >>  void i915_gem_resume(struct drm_i915_private *dev_priv);
>> > >> -int i915_gem_fault(struct vm_fault *vmf);
>> > >> +vm_fault_t i915_gem_fault(struct vm_fault *vmf);
>> > >>  int i915_gem_object_wait(struct drm_i915_gem_object *obj,
>> > >>unsigned int flags,
>> > >>long timeout,
>> > >> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
>> > >> index dd89abd..bdac690 100644
>> > >> --- a/drivers/gpu/drm/i915/i915_gem.c
>> > >> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> > >> @@ -1882,7 +1882,7 @@ int i915_gem_mmap_gtt_version(void)
>> > >>   * The current feature set supported by i915_gem_fault() and thus
> GTT mmaps
>> > >>   * is exposed via I915_PARAM_MMAP_GTT_VERSION (see
> i915_gem_mmap_gtt_version).
>> > >>   */
>> > >> -int i915_gem_fault(struct vm_fault *vmf)
>> > >> +vm_fault_t i915_gem_fault(struct vm_fault *vmf)
>> > >>  {
>> > >>  #define MIN_CHUNK_PAGES ((1 << 20) >> PAGE_SHIFT) /* 1 MiB */
>> > >>   struct vm_area_struct *area = vmf->vma;
>> > >> @@ -1895,6 +1895,7 @@ int i915_gem_fault(struct vm_fault *vmf)
>> > >>   pgoff_t page_offset;
>> > >>   unsigned int flags;
>> > >>   int ret;
>> > >> + vm_fault_t retval;
>> > >
>> > > What's the point of changing the name? An unnecessary change.
>> > >
>> > > BR,
>> > > Jani.
>> > >
>> > >>
>> > >>   /* We don't use vmf->pgoff since that has the fake offset */
>> > >>   page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
>> > >> @@ -2000,7 +2001,7 @@ int i915_gem_fault(struct vm_fault *vmf)
>> > >>* and so needs to be reported.
>> > >>*/
>> > >>   if (!i915_terminally_wedged(_priv->gpu_error)) {
>> > >> - ret = VM_FAULT_SIGBUS;
>> > >> + retval = VM_FAULT_SIGBUS;
>> > >>   break;
>> > >>   }
>> > >>   case -EAGAIN:
>> > >> @@ -2017,21 +2018,21 @@ int i915_gem_fault(struct vm_fault *vmf)
>> > >>* EBUSY is ok: this just means that another thread
>> > >>* already did the job.
>> > >>*/
>> > >> - ret = VM_FAULT_NOPAGE;
>> > >> + retval = VM_FAULT_NOPAGE;
>> > >>   break;
>> > >>   case -ENOMEM:
>> > >> - ret = VM_FAULT_OOM;
>> > >> + retval = VM_FAULT_OOM;
>> > >>   break;

Re: [PATCH v6 6/7] remoteproc/davinci: use the reset framework

[Sekhar Nori]

On Tuesday 17 April 2018 11:00 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> Switch to using the reset framework instead of handcoded reset routines
> we used so far.
> 
> Signed-off-by: Bartosz Golaszewski 

Looks good!

Reviewed-by: Sekhar Nori 

This depends on DaVinci gaining common clock / reset framework support
though. I am guessing remoteproc maintainers will have to be reminded
when its safe to apply.

Thanks,
Sekhar

Re: [PATCH v6 6/7] remoteproc/davinci: use the reset framework

[Sekhar Nori]

On Tuesday 17 April 2018 11:00 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> Switch to using the reset framework instead of handcoded reset routines
> we used so far.
> 
> Signed-off-by: Bartosz Golaszewski 

Looks good!

Reviewed-by: Sekhar Nori 

This depends on DaVinci gaining common clock / reset framework support
though. I am guessing remoteproc maintainers will have to be reminded
when its safe to apply.

Thanks,
Sekhar

[PATCH 2/2] qxl: keep separate release_bo pointer

[Gerd Hoffmann]

qxl expects that list_first_entry(release->bos) returns the first
element qxl added to the list.  ttm_eu_reserve_buffers() may reorder
the list though.

Add a release_bo field to struct qxl_release and use that instead.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_drv.h |  1 +
 drivers/gpu/drm/qxl/qxl_cmd.c |  6 ++
 drivers/gpu/drm/qxl/qxl_release.c | 12 ++--
 3 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 00a1a66b05..864b456080 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -167,6 +167,7 @@ struct qxl_release {
 
int id;
int type;
+   struct qxl_bo *release_bo;
uint32_t release_offset;
uint32_t surface_release_id;
struct ww_acquire_ctx ticket;
diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
index c0fb52c6d4..01665b98c5 100644
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -179,10 +179,9 @@ qxl_push_command_ring_release(struct qxl_device *qdev, 
struct qxl_release *relea
  uint32_t type, bool interruptible)
 {
struct qxl_command cmd;
-   struct qxl_bo_list *entry = list_first_entry(>bos, struct 
qxl_bo_list, tv.head);
 
cmd.type = type;
-   cmd.data = qxl_bo_physical_address(qdev, to_qxl_bo(entry->tv.bo), 
release->release_offset);
+   cmd.data = qxl_bo_physical_address(qdev, release->release_bo, 
release->release_offset);
 
return qxl_ring_push(qdev->command_ring, , interruptible);
 }
@@ -192,10 +191,9 @@ qxl_push_cursor_ring_release(struct qxl_device *qdev, 
struct qxl_release *releas
 uint32_t type, bool interruptible)
 {
struct qxl_command cmd;
-   struct qxl_bo_list *entry = list_first_entry(>bos, struct 
qxl_bo_list, tv.head);
 
cmd.type = type;
-   cmd.data = qxl_bo_physical_address(qdev, to_qxl_bo(entry->tv.bo), 
release->release_offset);
+   cmd.data = qxl_bo_physical_address(qdev, release->release_bo, 
release->release_offset);
 
return qxl_ring_push(qdev->cursor_ring, , interruptible);
 }
diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index a0b4244d28..7cb2145772 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -173,6 +173,7 @@ qxl_release_free_list(struct qxl_release *release)
list_del(>tv.head);
kfree(entry);
}
+   release->release_bo = NULL;
 }
 
 void
@@ -296,7 +297,6 @@ int qxl_alloc_surface_release_reserved(struct qxl_device 
*qdev,
 {
if (surface_cmd_type == QXL_SURFACE_CMD_DESTROY && create_rel) {
int idr_ret;
-   struct qxl_bo_list *entry = list_first_entry(_rel->bos, 
struct qxl_bo_list, tv.head);
struct qxl_bo *bo;
union qxl_release_info *info;
 
@@ -304,8 +304,9 @@ int qxl_alloc_surface_release_reserved(struct qxl_device 
*qdev,
idr_ret = qxl_release_alloc(qdev, QXL_RELEASE_SURFACE_CMD, 
release);
if (idr_ret < 0)
return idr_ret;
-   bo = to_qxl_bo(entry->tv.bo);
+   bo = create_rel->release_bo;
 
+   (*release)->release_bo = bo;
(*release)->release_offset = create_rel->release_offset + 64;
 
qxl_release_list_add(*release, bo);
@@ -365,6 +366,7 @@ int qxl_alloc_release_reserved(struct qxl_device *qdev, 
unsigned long size,
 
bo = qxl_bo_ref(qdev->current_release_bo[cur_idx]);
 
+   (*release)->release_bo = bo;
(*release)->release_offset = qdev->current_release_bo_offset[cur_idx] * 
release_size_per_bo[cur_idx];
qdev->current_release_bo_offset[cur_idx]++;
 
@@ -408,8 +410,7 @@ union qxl_release_info *qxl_release_map(struct qxl_device 
*qdev,
 {
void *ptr;
union qxl_release_info *info;
-   struct qxl_bo_list *entry = list_first_entry(>bos, struct 
qxl_bo_list, tv.head);
-   struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
+   struct qxl_bo *bo = release->release_bo;
 
ptr = qxl_bo_kmap_atomic_page(qdev, bo, release->release_offset & 
PAGE_MASK);
if (!ptr)
@@ -422,8 +423,7 @@ void qxl_release_unmap(struct qxl_device *qdev,
   struct qxl_release *release,
   union qxl_release_info *info)
 {
-   struct qxl_bo_list *entry = list_first_entry(>bos, struct 
qxl_bo_list, tv.head);
-   struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
+   struct qxl_bo *bo = release->release_bo;
void *ptr;
 
ptr = ((void *)info) - (release->release_offset & ~PAGE_MASK);
-- 
2.9.3

[PATCH 1/2] qxl: fix qxl_release_{map,unmap}

[Gerd Hoffmann]

s/PAGE_SIZE/PAGE_MASK/

Luckily release_offset is never larger than PAGE_SIZE, so the bug has no
bad side effects and managed to stay unnoticed for years that way ...

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_ioctl.c   | 4 ++--
 drivers/gpu/drm/qxl/qxl_release.c | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index e238a1a2ec..6cc9f3367f 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -182,9 +182,9 @@ static int qxl_process_single_command(struct qxl_device 
*qdev,
goto out_free_reloc;
 
/* TODO copy slow path code from i915 */
-   fb_cmd = qxl_bo_kmap_atomic_page(qdev, cmd_bo, (release->release_offset 
& PAGE_SIZE));
+   fb_cmd = qxl_bo_kmap_atomic_page(qdev, cmd_bo, (release->release_offset 
& PAGE_MASK));
unwritten = __copy_from_user_inatomic_nocache
-   (fb_cmd + sizeof(union qxl_release_info) + 
(release->release_offset & ~PAGE_SIZE),
+   (fb_cmd + sizeof(union qxl_release_info) + 
(release->release_offset & ~PAGE_MASK),
 u64_to_user_ptr(cmd->command), cmd->command_size);
 
{
diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index 5d84a66fed..a0b4244d28 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -411,10 +411,10 @@ union qxl_release_info *qxl_release_map(struct qxl_device 
*qdev,
struct qxl_bo_list *entry = list_first_entry(>bos, struct 
qxl_bo_list, tv.head);
struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
 
-   ptr = qxl_bo_kmap_atomic_page(qdev, bo, release->release_offset & 
PAGE_SIZE);
+   ptr = qxl_bo_kmap_atomic_page(qdev, bo, release->release_offset & 
PAGE_MASK);
if (!ptr)
return NULL;
-   info = ptr + (release->release_offset & ~PAGE_SIZE);
+   info = ptr + (release->release_offset & ~PAGE_MASK);
return info;
 }
 
@@ -426,7 +426,7 @@ void qxl_release_unmap(struct qxl_device *qdev,
struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
void *ptr;
 
-   ptr = ((void *)info) - (release->release_offset & ~PAGE_SIZE);
+   ptr = ((void *)info) - (release->release_offset & ~PAGE_MASK);
qxl_bo_kunmap_atomic_page(qdev, bo, ptr);
 }
 
-- 
2.9.3

[PATCH 2/2] qxl: keep separate release_bo pointer

[Gerd Hoffmann]

qxl expects that list_first_entry(release->bos) returns the first
element qxl added to the list.  ttm_eu_reserve_buffers() may reorder
the list though.

Add a release_bo field to struct qxl_release and use that instead.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_drv.h |  1 +
 drivers/gpu/drm/qxl/qxl_cmd.c |  6 ++
 drivers/gpu/drm/qxl/qxl_release.c | 12 ++--
 3 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 00a1a66b05..864b456080 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -167,6 +167,7 @@ struct qxl_release {
 
int id;
int type;
+   struct qxl_bo *release_bo;
uint32_t release_offset;
uint32_t surface_release_id;
struct ww_acquire_ctx ticket;
diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
index c0fb52c6d4..01665b98c5 100644
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -179,10 +179,9 @@ qxl_push_command_ring_release(struct qxl_device *qdev, 
struct qxl_release *relea
  uint32_t type, bool interruptible)
 {
struct qxl_command cmd;
-   struct qxl_bo_list *entry = list_first_entry(>bos, struct 
qxl_bo_list, tv.head);
 
cmd.type = type;
-   cmd.data = qxl_bo_physical_address(qdev, to_qxl_bo(entry->tv.bo), 
release->release_offset);
+   cmd.data = qxl_bo_physical_address(qdev, release->release_bo, 
release->release_offset);
 
return qxl_ring_push(qdev->command_ring, , interruptible);
 }
@@ -192,10 +191,9 @@ qxl_push_cursor_ring_release(struct qxl_device *qdev, 
struct qxl_release *releas
 uint32_t type, bool interruptible)
 {
struct qxl_command cmd;
-   struct qxl_bo_list *entry = list_first_entry(>bos, struct 
qxl_bo_list, tv.head);
 
cmd.type = type;
-   cmd.data = qxl_bo_physical_address(qdev, to_qxl_bo(entry->tv.bo), 
release->release_offset);
+   cmd.data = qxl_bo_physical_address(qdev, release->release_bo, 
release->release_offset);
 
return qxl_ring_push(qdev->cursor_ring, , interruptible);
 }
diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index a0b4244d28..7cb2145772 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -173,6 +173,7 @@ qxl_release_free_list(struct qxl_release *release)
list_del(>tv.head);
kfree(entry);
}
+   release->release_bo = NULL;
 }
 
 void
@@ -296,7 +297,6 @@ int qxl_alloc_surface_release_reserved(struct qxl_device 
*qdev,
 {
if (surface_cmd_type == QXL_SURFACE_CMD_DESTROY && create_rel) {
int idr_ret;
-   struct qxl_bo_list *entry = list_first_entry(_rel->bos, 
struct qxl_bo_list, tv.head);
struct qxl_bo *bo;
union qxl_release_info *info;
 
@@ -304,8 +304,9 @@ int qxl_alloc_surface_release_reserved(struct qxl_device 
*qdev,
idr_ret = qxl_release_alloc(qdev, QXL_RELEASE_SURFACE_CMD, 
release);
if (idr_ret < 0)
return idr_ret;
-   bo = to_qxl_bo(entry->tv.bo);
+   bo = create_rel->release_bo;
 
+   (*release)->release_bo = bo;
(*release)->release_offset = create_rel->release_offset + 64;
 
qxl_release_list_add(*release, bo);
@@ -365,6 +366,7 @@ int qxl_alloc_release_reserved(struct qxl_device *qdev, 
unsigned long size,
 
bo = qxl_bo_ref(qdev->current_release_bo[cur_idx]);
 
+   (*release)->release_bo = bo;
(*release)->release_offset = qdev->current_release_bo_offset[cur_idx] * 
release_size_per_bo[cur_idx];
qdev->current_release_bo_offset[cur_idx]++;
 
@@ -408,8 +410,7 @@ union qxl_release_info *qxl_release_map(struct qxl_device 
*qdev,
 {
void *ptr;
union qxl_release_info *info;
-   struct qxl_bo_list *entry = list_first_entry(>bos, struct 
qxl_bo_list, tv.head);
-   struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
+   struct qxl_bo *bo = release->release_bo;
 
ptr = qxl_bo_kmap_atomic_page(qdev, bo, release->release_offset & 
PAGE_MASK);
if (!ptr)
@@ -422,8 +423,7 @@ void qxl_release_unmap(struct qxl_device *qdev,
   struct qxl_release *release,
   union qxl_release_info *info)
 {
-   struct qxl_bo_list *entry = list_first_entry(>bos, struct 
qxl_bo_list, tv.head);
-   struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
+   struct qxl_bo *bo = release->release_bo;
void *ptr;
 
ptr = ((void *)info) - (release->release_offset & ~PAGE_MASK);
-- 
2.9.3

[PATCH 1/2] qxl: fix qxl_release_{map,unmap}

[Gerd Hoffmann]

s/PAGE_SIZE/PAGE_MASK/

Luckily release_offset is never larger than PAGE_SIZE, so the bug has no
bad side effects and managed to stay unnoticed for years that way ...

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_ioctl.c   | 4 ++--
 drivers/gpu/drm/qxl/qxl_release.c | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index e238a1a2ec..6cc9f3367f 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -182,9 +182,9 @@ static int qxl_process_single_command(struct qxl_device 
*qdev,
goto out_free_reloc;
 
/* TODO copy slow path code from i915 */
-   fb_cmd = qxl_bo_kmap_atomic_page(qdev, cmd_bo, (release->release_offset 
& PAGE_SIZE));
+   fb_cmd = qxl_bo_kmap_atomic_page(qdev, cmd_bo, (release->release_offset 
& PAGE_MASK));
unwritten = __copy_from_user_inatomic_nocache
-   (fb_cmd + sizeof(union qxl_release_info) + 
(release->release_offset & ~PAGE_SIZE),
+   (fb_cmd + sizeof(union qxl_release_info) + 
(release->release_offset & ~PAGE_MASK),
 u64_to_user_ptr(cmd->command), cmd->command_size);
 
{
diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index 5d84a66fed..a0b4244d28 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -411,10 +411,10 @@ union qxl_release_info *qxl_release_map(struct qxl_device 
*qdev,
struct qxl_bo_list *entry = list_first_entry(>bos, struct 
qxl_bo_list, tv.head);
struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
 
-   ptr = qxl_bo_kmap_atomic_page(qdev, bo, release->release_offset & 
PAGE_SIZE);
+   ptr = qxl_bo_kmap_atomic_page(qdev, bo, release->release_offset & 
PAGE_MASK);
if (!ptr)
return NULL;
-   info = ptr + (release->release_offset & ~PAGE_SIZE);
+   info = ptr + (release->release_offset & ~PAGE_MASK);
return info;
 }
 
@@ -426,7 +426,7 @@ void qxl_release_unmap(struct qxl_device *qdev,
struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
void *ptr;
 
-   ptr = ((void *)info) - (release->release_offset & ~PAGE_SIZE);
+   ptr = ((void *)info) - (release->release_offset & ~PAGE_MASK);
qxl_bo_kunmap_atomic_page(qdev, bo, ptr);
 }
 
-- 
2.9.3

Re: [PATCH 5/5] dmaengine: sprd: Add 'device_config' and 'device_prep_slave_sg' interfaces

[Baolin Wang]

On 17 April 2018 at 18:45, Lars-Peter Clausen  wrote:
> On 04/10/2018 09:46 AM, Baolin Wang wrote:
> [...]
>> +static int sprd_dma_slave_config(struct dma_chan *chan,
>> +  struct dma_slave_config *config)
>> +{
>> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
>> + struct sprd_dma_config *slave_cfg =
>> + container_of(config, struct sprd_dma_config, config);
>> +
>
> Please do not overload standard API with custom semantics. This makes the
> driver incompatible to the API and negates the whole idea of having a common
> API. E.g. this will crash when somebody passes a normal dma_slave_config
> struct to this function.
>

Yes, we have discussed with Vinod how to use 'dma_slave_config' to
reach our requirements. Thanks for your comments.

-- 
Baolin.wang
Best Regards

Re: [PATCH 5/5] dmaengine: sprd: Add 'device_config' and 'device_prep_slave_sg' interfaces

[Baolin Wang]

On 17 April 2018 at 18:45, Lars-Peter Clausen  wrote:
> On 04/10/2018 09:46 AM, Baolin Wang wrote:
> [...]
>> +static int sprd_dma_slave_config(struct dma_chan *chan,
>> +  struct dma_slave_config *config)
>> +{
>> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
>> + struct sprd_dma_config *slave_cfg =
>> + container_of(config, struct sprd_dma_config, config);
>> +
>
> Please do not overload standard API with custom semantics. This makes the
> driver incompatible to the API and negates the whole idea of having a common
> API. E.g. this will crash when somebody passes a normal dma_slave_config
> struct to this function.
>

Yes, we have discussed with Vinod how to use 'dma_slave_config' to
reach our requirements. Thanks for your comments.

-- 
Baolin.wang
Best Regards

Re: [PATCH v6 5/7] remoteproc/davinci: use octal permissions for module_param()

[Sekhar Nori]

On Tuesday 17 April 2018 11:00 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> Checkpatch recommends to use octal perms instead of S_IRUGO.
> 
> Signed-off-by: Bartosz Golaszewski 

Reviewed-by: Sekhar Nori 

Thanks,
Sekhar

Re: [PATCH v6 5/7] remoteproc/davinci: use octal permissions for module_param()

[Sekhar Nori]

On Tuesday 17 April 2018 11:00 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> Checkpatch recommends to use octal perms instead of S_IRUGO.
> 
> Signed-off-by: Bartosz Golaszewski 

Reviewed-by: Sekhar Nori 

Thanks,
Sekhar

Re: [PATCH v6 4/7] remoteproc/davinci: prepare and unprepare the clock where needed

[Sekhar Nori]

On Tuesday 17 April 2018 11:00 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> We're currently switching the platform to using the common clock
> framework. We need to explicitly prepare and unprepare the rproc
> clock.
> 
> Signed-off-by: Bartosz Golaszewski 
> Acked-by: Suman Anna 
> Reviewed-by: David Lechner 

Reviewed-by: Sekhar Nori 

This should be safe to apply to v4.17-rc1 as well (for inclusion in v4.18).

Bartosz, I noticed that CONFIG_REMOTEPROC and the DA8XX driver is not
enabled in davinci_all_defconfig. Can you please send a patch enabling
that too?

Thanks,
Sekhar

Re: [PATCH v6 4/7] remoteproc/davinci: prepare and unprepare the clock where needed

[Sekhar Nori]

On Tuesday 17 April 2018 11:00 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> We're currently switching the platform to using the common clock
> framework. We need to explicitly prepare and unprepare the rproc
> clock.
> 
> Signed-off-by: Bartosz Golaszewski 
> Acked-by: Suman Anna 
> Reviewed-by: David Lechner 

Reviewed-by: Sekhar Nori 

This should be safe to apply to v4.17-rc1 as well (for inclusion in v4.18).

Bartosz, I noticed that CONFIG_REMOTEPROC and the DA8XX driver is not
enabled in davinci_all_defconfig. Can you please send a patch enabling
that too?

Thanks,
Sekhar

Re: [PATCH 4.15 00/53] 4.15.18-stable review

[Naresh Kamboju]

On 17 April 2018 at 21:28, Greg Kroah-Hartman
 wrote:
> 
> NOTE, this is the last expected 4.15.y release.  After this one, the
> tree is end-of-life.  Please move to 4.16.y at this point in time.
> 
>
> This is the start of the stable review cycle for the 4.15.18 release.
> There are 53 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 Thu Apr 19 15:57:06 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.18-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

kselftest: BPF tests test_xdp_meta.sh and test_xdp_redirect.sh were being
skipped with "Could not run test without the ip {xdp,xdpgeneric} support",
which got added into iproute2 4.11 and now being run and reported failed
on stable-rc-4.15.18-rc1 and also on linux-mainline kernel 4.17.

We have an open bug to investigate this failure.
LKFT: mainline: BPF: test_xdp_redirect.sh and test_xdp_meta.sh skipped -
Could not run test without the ip xdpgeneric support
https://bugs.linaro.org/show_bug.cgi?id=3630

Summary


kernel: 4.15.18-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.15.y
git commit: ae8929dc5a7d09feab66e3131a04a1ed88d8d284
git describe: v4.15.17-54-gae8929dc5a7d
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.15-oe/build/v4.15.17-54-gae8929dc5a7d

No Regressions (compared to build v4.15.17)



Boards, architectures and test suites:
-

dragonboard-410c - arm64
* boot - fail: 2, pass: 20
* kselftest - skip: 20, fail: 2, pass: 43
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 134, pass: 1016
* ltp-timers-tests - pass: 13

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 17, fail: 2, pass: 46
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 135, pass: 1015
* ltp-timers-tests - pass: 13

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 18, fail: 2, pass: 45
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 134, pass: 1016
* ltp-timers-tests - pass: 13

qemu_x86_64
* boot - pass: 22
* kselftest - skip: 23, fail: 2, pass: 55
* kselftest-vsyscall-mode-native - skip: 23, fail: 2, pass: 55
* kselftest-vsyscall-mode-none - skip: 23, fail: 2, pass: 55
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, 

Re: [PATCH 4.15 00/53] 4.15.18-stable review

[Naresh Kamboju]

On 17 April 2018 at 21:28, Greg Kroah-Hartman
 wrote:
> 
> NOTE, this is the last expected 4.15.y release.  After this one, the
> tree is end-of-life.  Please move to 4.16.y at this point in time.
> 
>
> This is the start of the stable review cycle for the 4.15.18 release.
> There are 53 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 Thu Apr 19 15:57:06 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.18-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

kselftest: BPF tests test_xdp_meta.sh and test_xdp_redirect.sh were being
skipped with "Could not run test without the ip {xdp,xdpgeneric} support",
which got added into iproute2 4.11 and now being run and reported failed
on stable-rc-4.15.18-rc1 and also on linux-mainline kernel 4.17.

We have an open bug to investigate this failure.
LKFT: mainline: BPF: test_xdp_redirect.sh and test_xdp_meta.sh skipped -
Could not run test without the ip xdpgeneric support
https://bugs.linaro.org/show_bug.cgi?id=3630

Summary


kernel: 4.15.18-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.15.y
git commit: ae8929dc5a7d09feab66e3131a04a1ed88d8d284
git describe: v4.15.17-54-gae8929dc5a7d
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.15-oe/build/v4.15.17-54-gae8929dc5a7d

No Regressions (compared to build v4.15.17)



Boards, architectures and test suites:
-

dragonboard-410c - arm64
* boot - fail: 2, pass: 20
* kselftest - skip: 20, fail: 2, pass: 43
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 134, pass: 1016
* ltp-timers-tests - pass: 13

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 17, fail: 2, pass: 46
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 135, pass: 1015
* ltp-timers-tests - pass: 13

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 18, fail: 2, pass: 45
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 134, pass: 1016
* ltp-timers-tests - pass: 13

qemu_x86_64
* boot - pass: 22
* kselftest - skip: 23, fail: 2, pass: 55
* kselftest-vsyscall-mode-native - skip: 23, fail: 2, pass: 55
* kselftest-vsyscall-mode-none - skip: 23, fail: 2, pass: 55
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* 

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

[David Rientjes]

On Wed, 18 Apr 2018, Tetsuo Handa wrote:

> > Commit 97b1255cb27c is referencing MMF_OOM_SKIP already being set by 
> > exit_mmap().  The only thing this patch changes is where that is done: 
> > before or after free_pgtables().  We can certainly move it to before 
> > free_pgtables() at the risk of subsequent (and eventually unnecessary) oom 
> > kills.  It's not exactly the point of this patch.
> > 
> > I have thousands of real-world examples where additional processes were 
> > oom killed while the original victim was in free_pgtables().  That's why 
> > we've moved the MMF_OOM_SKIP to after free_pgtables().
> 
> "we have moved"? No, not yet. Your patch is about to move it.
> 

I'm referring to our own kernel, we have thousands of real-world examples 
where additional processes have been oom killed where the original victim 
is in free_pgtables().  It actually happens about 10-15% of the time in 
automated testing where you create a 128MB memcg, fork a canary, and then 
fork a >128MB memory hog.  10-15% of the time both processes get oom 
killed: the memory hog first (higher rss), the canary second.  The pgtable 
stat is unchanged between oom kills.

> My question is: is it guaranteed that 
> munlock_vma_pages_all()/unmap_vmas()/free_pgtables()
> by exit_mmap() are never blocked for memory allocation. Note that exit_mmap() 
> tries to unmap
> all pages while the OOM reaper tries to unmap only safe pages. If there is 
> possibility that
> munlock_vma_pages_all()/unmap_vmas()/free_pgtables() by exit_mmap() are 
> blocked for memory
> allocation, your patch will introduce an OOM livelock.
> 

If munlock_vma_pages_all(), unmap_vmas(), or free_pgtables() require 
memory to make forward progress, then we have bigger problems :)

I just ran a query of real-world oom kill logs that I have.  In 33,773,705 
oom kills, I have no evidence of a thread failing to exit after reaching 
exit_mmap().

You may recall from my support of your patch to emit the stack trace when 
the oom reaper fails, in https://marc.info/?l=linux-mm=152157881518627, 
that I have logs of 28,222,058 occurrences of the oom reaper where it 
successfully frees memory and the victim exits.

If you'd like to pursue the possibility that exit_mmap() blocks before 
freeing memory that we have somehow been lucky to miss in 33 million 
occurrences, I'd appreciate the test case.

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

[David Rientjes]

On Wed, 18 Apr 2018, Tetsuo Handa wrote:

> > Commit 97b1255cb27c is referencing MMF_OOM_SKIP already being set by 
> > exit_mmap().  The only thing this patch changes is where that is done: 
> > before or after free_pgtables().  We can certainly move it to before 
> > free_pgtables() at the risk of subsequent (and eventually unnecessary) oom 
> > kills.  It's not exactly the point of this patch.
> > 
> > I have thousands of real-world examples where additional processes were 
> > oom killed while the original victim was in free_pgtables().  That's why 
> > we've moved the MMF_OOM_SKIP to after free_pgtables().
> 
> "we have moved"? No, not yet. Your patch is about to move it.
> 

I'm referring to our own kernel, we have thousands of real-world examples 
where additional processes have been oom killed where the original victim 
is in free_pgtables().  It actually happens about 10-15% of the time in 
automated testing where you create a 128MB memcg, fork a canary, and then 
fork a >128MB memory hog.  10-15% of the time both processes get oom 
killed: the memory hog first (higher rss), the canary second.  The pgtable 
stat is unchanged between oom kills.

> My question is: is it guaranteed that 
> munlock_vma_pages_all()/unmap_vmas()/free_pgtables()
> by exit_mmap() are never blocked for memory allocation. Note that exit_mmap() 
> tries to unmap
> all pages while the OOM reaper tries to unmap only safe pages. If there is 
> possibility that
> munlock_vma_pages_all()/unmap_vmas()/free_pgtables() by exit_mmap() are 
> blocked for memory
> allocation, your patch will introduce an OOM livelock.
> 

If munlock_vma_pages_all(), unmap_vmas(), or free_pgtables() require 
memory to make forward progress, then we have bigger problems :)

I just ran a query of real-world oom kill logs that I have.  In 33,773,705 
oom kills, I have no evidence of a thread failing to exit after reaching 
exit_mmap().

You may recall from my support of your patch to emit the stack trace when 
the oom reaper fails, in https://marc.info/?l=linux-mm=152157881518627, 
that I have logs of 28,222,058 occurrences of the oom reaper where it 
successfully frees memory and the victim exits.

If you'd like to pursue the possibility that exit_mmap() blocks before 
freeing memory that we have somehow been lucky to miss in 33 million 
occurrences, I'd appreciate the test case.

Re: [PATCH 4.16 00/68] 4.16.3-stable review

[Naresh Kamboju]

On 17 April 2018 at 21:27, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.16.3 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 Thu Apr 19 15:57:33 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.3-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.16.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

kselftest: BPF tests test_xdp_meta.sh and test_xdp_redirect.sh were being
skipped with "Could not run test without the ip {xdp,xdpgeneric} support",
which got added into iproute2 4.11 and now being run and reported failed
on stable-rc-4.16.3-rc1 and also on linux-mainline kernel 4.16 to 4.17.

We have an open bug to investigate this failure.
LKFT: mainline: BPF: test_xdp_redirect.sh and test_xdp_meta.sh skipped -
Could not run test without the ip xdpgeneric support
https://bugs.linaro.org/show_bug.cgi?id=3630

Summary


kernel: 4.16.3-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.16.y
git commit: 8485fd17d21b5d9a07b276f1c35c90a5ed529a36
git describe: v4.16.2-69-g8485fd17d21b
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.16-oe/build/v4.16.2-69-g8485fd17d21b

No regressions (compared to build v4.16.2)


Boards, architectures and test suites:
-

dragonboard-410c - arm64
* boot - fail: 1, pass: 19
* kselftest - skip: 20, fail: 2, pass: 43
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 133, pass: 1017
* ltp-timers-tests - pass: 13

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 17, fail: 2, pass: 46
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 134, pass: 1016
* ltp-timers-tests - pass: 13

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 18, fail: 2, pass: 45
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 133, pass: 1017
* ltp-timers-tests - pass: 13

qemu_x86_64
* boot - pass: 22
* kselftest - skip: 23, fail: 2, pass: 55
* kselftest-vsyscall-mode-native - skip: 23, fail: 2, pass: 55
* kselftest-vsyscall-mode-none - skip: 23, fail: 2, pass: 55
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 147, pass: 1003
* ltp-timers-tests - pass: 13

x15 - arm
* boot - pass: 20
* kselftest - skip: 21, fail: 3, pass: 38
* libhugetlbfs - skip: 1, pass: 87
* 

Re: [PATCH 4.16 00/68] 4.16.3-stable review

[Naresh Kamboju]

On 17 April 2018 at 21:27, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.16.3 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 Thu Apr 19 15:57:33 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.3-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.16.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

kselftest: BPF tests test_xdp_meta.sh and test_xdp_redirect.sh were being
skipped with "Could not run test without the ip {xdp,xdpgeneric} support",
which got added into iproute2 4.11 and now being run and reported failed
on stable-rc-4.16.3-rc1 and also on linux-mainline kernel 4.16 to 4.17.

We have an open bug to investigate this failure.
LKFT: mainline: BPF: test_xdp_redirect.sh and test_xdp_meta.sh skipped -
Could not run test without the ip xdpgeneric support
https://bugs.linaro.org/show_bug.cgi?id=3630

Summary


kernel: 4.16.3-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.16.y
git commit: 8485fd17d21b5d9a07b276f1c35c90a5ed529a36
git describe: v4.16.2-69-g8485fd17d21b
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.16-oe/build/v4.16.2-69-g8485fd17d21b

No regressions (compared to build v4.16.2)


Boards, architectures and test suites:
-

dragonboard-410c - arm64
* boot - fail: 1, pass: 19
* kselftest - skip: 20, fail: 2, pass: 43
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 133, pass: 1017
* ltp-timers-tests - pass: 13

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 17, fail: 2, pass: 46
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 134, pass: 1016
* ltp-timers-tests - pass: 13

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 18, fail: 2, pass: 45
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 133, pass: 1017
* ltp-timers-tests - pass: 13

qemu_x86_64
* boot - pass: 22
* kselftest - skip: 23, fail: 2, pass: 55
* kselftest-vsyscall-mode-native - skip: 23, fail: 2, pass: 55
* kselftest-vsyscall-mode-none - skip: 23, fail: 2, pass: 55
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 147, pass: 1003
* ltp-timers-tests - pass: 13

x15 - arm
* boot - pass: 20
* kselftest - skip: 21, fail: 3, pass: 38
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2

RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Bharat Bhushan]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Tuesday, April 17, 2018 10:23 PM
> To: Nipun Gupta ; robh...@kernel.org;
> frowand.l...@gmail.com
> Cc: will.dea...@arm.com; mark.rutl...@arm.com; catalin.mari...@arm.com;
> h...@lst.de; gre...@linuxfoundation.org; j...@8bytes.org;
> m.szyprow...@samsung.com; shawn...@kernel.org; bhelg...@google.com;
> io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linuxppc-
> d...@lists.ozlabs.org; linux-...@vger.kernel.org; Bharat Bhushan
> ; stuyo...@gmail.com; Laurentiu Tudor
> ; Leo Li 
> Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for
> other devices too
> 
> On 17/04/18 11:21, Nipun Gupta wrote:
> > iommu-map property is also used by devices with fsl-mc. This patch
> > moves the of_pci_map_rid to generic location, so that it can be used
> > by other busses too.

Nipun, please clarify that only function name is changed and rest of body is 
same.

> >
> > Signed-off-by: Nipun Gupta 
> > ---
> >   drivers/iommu/of_iommu.c | 106
> > +--
> 
> Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU?

Yes, this will be a problem with MSI 

> I guess you
> don't want fsl-mc to have to depend on PCI, but this looks like a step in the
> wrong direction.
> 
> I'm not entirely sure where of_map_rid() fits best, but from a quick look 
> around
> the least-worst option might be drivers/of/of_address.c, unless Rob and Frank
> have a better idea of where generic DT-based ID translation routines could 
> live?

drivers/of/address.c may be proper place to move until someone have better idea.

Thanks
-Bharat

> 
> >   drivers/of/irq.c |   6 +--
> >   drivers/pci/of.c | 101 
> > 
> >   include/linux/of_iommu.h |  11 +
> >   include/linux/of_pci.h   |  10 -
> >   5 files changed, 117 insertions(+), 117 deletions(-)
> >
> > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index
> > 5c36a8b..4e7712f 100644
> > --- a/drivers/iommu/of_iommu.c
> > +++ b/drivers/iommu/of_iommu.c
> > @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
> > return ops->of_xlate(dev, iommu_spec);
> >   }
> >
> > +/**
> > + * of_map_rid - Translate a requester ID through a downstream mapping.
> > + * @np: root complex device node.
> > + * @rid: device requester ID to map.
> > + * @map_name: property name of the map to use.
> > + * @map_mask_name: optional property name of the mask to use.
> > + * @target: optional pointer to a target device node.
> > + * @id_out: optional pointer to receive the translated ID.
> > + *
> > + * Given a device requester ID, look up the appropriate
> > +implementation-defined
> > + * platform ID and/or the target device which receives transactions
> > +on that
> > + * ID, as per the "iommu-map" and "msi-map" bindings. Either of
> > +@target or
> > + * @id_out may be NULL if only the other is required. If @target
> > +points to
> > + * a non-NULL device node pointer, only entries targeting that node
> > +will be
> > + * matched; if it points to a NULL value, it will receive the device
> > +node of
> > + * the first matching target phandle, with a reference held.
> > + *
> > + * Return: 0 on success or a standard error code on failure.
> > + */
> > +int of_map_rid(struct device_node *np, u32 rid,
> > +  const char *map_name, const char *map_mask_name,
> > +  struct device_node **target, u32 *id_out) {
> > +   u32 map_mask, masked_rid;
> > +   int map_len;
> > +   const __be32 *map = NULL;
> > +
> > +   if (!np || !map_name || (!target && !id_out))
> > +   return -EINVAL;
> > +
> > +   map = of_get_property(np, map_name, _len);
> > +   if (!map) {
> > +   if (target)
> > +   return -ENODEV;
> > +   /* Otherwise, no map implies no translation */
> > +   *id_out = rid;
> > +   return 0;
> > +   }
> > +
> > +   if (!map_len || map_len % (4 * sizeof(*map))) {
> > +   pr_err("%pOF: Error: Bad %s length: %d\n", np,
> > +   map_name, map_len);
> > +   return -EINVAL;
> > +   }
> > +
> > +   /* The default is to select all bits. */
> > +   map_mask = 0x;
> > +
> > +   /*
> > +* Can be overridden by "{iommu,msi}-map-mask" property.
> > +*/
> > +   if (map_mask_name)
> > +   of_property_read_u32(np, map_mask_name, _mask);
> > +
> > +   masked_rid = map_mask & rid;
> > +   for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> > +   struct device_node *phandle_node;
> > +   u32 rid_base = be32_to_cpup(map + 0);
> > +   u32 phandle = be32_to_cpup(map + 1);
> > +   u32 out_base = be32_to_cpup(map + 2);
> > +   

RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Bharat Bhushan]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Tuesday, April 17, 2018 10:23 PM
> To: Nipun Gupta ; robh...@kernel.org;
> frowand.l...@gmail.com
> Cc: will.dea...@arm.com; mark.rutl...@arm.com; catalin.mari...@arm.com;
> h...@lst.de; gre...@linuxfoundation.org; j...@8bytes.org;
> m.szyprow...@samsung.com; shawn...@kernel.org; bhelg...@google.com;
> io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linuxppc-
> d...@lists.ozlabs.org; linux-...@vger.kernel.org; Bharat Bhushan
> ; stuyo...@gmail.com; Laurentiu Tudor
> ; Leo Li 
> Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for
> other devices too
> 
> On 17/04/18 11:21, Nipun Gupta wrote:
> > iommu-map property is also used by devices with fsl-mc. This patch
> > moves the of_pci_map_rid to generic location, so that it can be used
> > by other busses too.

Nipun, please clarify that only function name is changed and rest of body is 
same.

> >
> > Signed-off-by: Nipun Gupta 
> > ---
> >   drivers/iommu/of_iommu.c | 106
> > +--
> 
> Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU?

Yes, this will be a problem with MSI 

> I guess you
> don't want fsl-mc to have to depend on PCI, but this looks like a step in the
> wrong direction.
> 
> I'm not entirely sure where of_map_rid() fits best, but from a quick look 
> around
> the least-worst option might be drivers/of/of_address.c, unless Rob and Frank
> have a better idea of where generic DT-based ID translation routines could 
> live?

drivers/of/address.c may be proper place to move until someone have better idea.

Thanks
-Bharat

> 
> >   drivers/of/irq.c |   6 +--
> >   drivers/pci/of.c | 101 
> > 
> >   include/linux/of_iommu.h |  11 +
> >   include/linux/of_pci.h   |  10 -
> >   5 files changed, 117 insertions(+), 117 deletions(-)
> >
> > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index
> > 5c36a8b..4e7712f 100644
> > --- a/drivers/iommu/of_iommu.c
> > +++ b/drivers/iommu/of_iommu.c
> > @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
> > return ops->of_xlate(dev, iommu_spec);
> >   }
> >
> > +/**
> > + * of_map_rid - Translate a requester ID through a downstream mapping.
> > + * @np: root complex device node.
> > + * @rid: device requester ID to map.
> > + * @map_name: property name of the map to use.
> > + * @map_mask_name: optional property name of the mask to use.
> > + * @target: optional pointer to a target device node.
> > + * @id_out: optional pointer to receive the translated ID.
> > + *
> > + * Given a device requester ID, look up the appropriate
> > +implementation-defined
> > + * platform ID and/or the target device which receives transactions
> > +on that
> > + * ID, as per the "iommu-map" and "msi-map" bindings. Either of
> > +@target or
> > + * @id_out may be NULL if only the other is required. If @target
> > +points to
> > + * a non-NULL device node pointer, only entries targeting that node
> > +will be
> > + * matched; if it points to a NULL value, it will receive the device
> > +node of
> > + * the first matching target phandle, with a reference held.
> > + *
> > + * Return: 0 on success or a standard error code on failure.
> > + */
> > +int of_map_rid(struct device_node *np, u32 rid,
> > +  const char *map_name, const char *map_mask_name,
> > +  struct device_node **target, u32 *id_out) {
> > +   u32 map_mask, masked_rid;
> > +   int map_len;
> > +   const __be32 *map = NULL;
> > +
> > +   if (!np || !map_name || (!target && !id_out))
> > +   return -EINVAL;
> > +
> > +   map = of_get_property(np, map_name, _len);
> > +   if (!map) {
> > +   if (target)
> > +   return -ENODEV;
> > +   /* Otherwise, no map implies no translation */
> > +   *id_out = rid;
> > +   return 0;
> > +   }
> > +
> > +   if (!map_len || map_len % (4 * sizeof(*map))) {
> > +   pr_err("%pOF: Error: Bad %s length: %d\n", np,
> > +   map_name, map_len);
> > +   return -EINVAL;
> > +   }
> > +
> > +   /* The default is to select all bits. */
> > +   map_mask = 0x;
> > +
> > +   /*
> > +* Can be overridden by "{iommu,msi}-map-mask" property.
> > +*/
> > +   if (map_mask_name)
> > +   of_property_read_u32(np, map_mask_name, _mask);
> > +
> > +   masked_rid = map_mask & rid;
> > +   for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> > +   struct device_node *phandle_node;
> > +   u32 rid_base = be32_to_cpup(map + 0);
> > +   u32 phandle = be32_to_cpup(map + 1);
> > +   u32 out_base = be32_to_cpup(map + 2);
> > +   u32 rid_len = be32_to_cpup(map + 3);
> > +
> > +   if (rid_base & ~map_mask) {
> > +   

Re: [PATCH v6 3/7] remoteproc/davinci: add the missing retval check for clk_enable()

[Sekhar Nori]

On Tuesday 17 April 2018 11:00 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> The davinci platform is being switched to using the common clock
> framework, where clk_enable() can fail. Add the return value check.
> 
> Signed-off-by: Bartosz Golaszewski 
> Acked-by: Suman Anna 
> Reviewed-by: David Lechner 

Reviewed-by: Sekhar Nori 

This should be safe to apply to v4.17-rc1 and should be queued by Ohad /
Bjorn.

Thanks,
Sekhar

Re: [PATCH v6 3/7] remoteproc/davinci: add the missing retval check for clk_enable()

[Sekhar Nori]

On Tuesday 17 April 2018 11:00 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> The davinci platform is being switched to using the common clock
> framework, where clk_enable() can fail. Add the return value check.
> 
> Signed-off-by: Bartosz Golaszewski 
> Acked-by: Suman Anna 
> Reviewed-by: David Lechner 

Reviewed-by: Sekhar Nori 

This should be safe to apply to v4.17-rc1 and should be queued by Ohad /
Bjorn.

Thanks,
Sekhar

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

[Tetsuo Handa]

David Rientjes wrote:
> On Wed, 18 Apr 2018, Tetsuo Handa wrote:
> > > Fix this by reusing MMF_UNSTABLE to specify that an mm should not be
> > > reaped.  This prevents the concurrent munlock_vma_pages_range() and
> > > unmap_page_range().  The oom reaper will simply not operate on an mm that
> > > has the bit set and leave the unmapping to exit_mmap().
> > 
> > This change assumes that 
> > munlock_vma_pages_all()/unmap_vmas()/free_pgtables()
> > are never blocked for memory allocation. Is that guaranteed? For example,
> > i_mmap_lock_write() from unmap_single_vma() from unmap_vmas() is never 
> > blocked
> > for memory allocation? Commit 97b1255cb27c551d ("mm,oom_reaper: check for
> > MMF_OOM_SKIP before complaining") was waiting for i_mmap_lock_write() from
> > unlink_file_vma() from free_pgtables(). Is it really guaranteed that 
> > somebody
> > else who is holding that lock is never waiting for memory allocation?
> > 
> 
> Commit 97b1255cb27c is referencing MMF_OOM_SKIP already being set by 
> exit_mmap().  The only thing this patch changes is where that is done: 
> before or after free_pgtables().  We can certainly move it to before 
> free_pgtables() at the risk of subsequent (and eventually unnecessary) oom 
> kills.  It's not exactly the point of this patch.
> 
> I have thousands of real-world examples where additional processes were 
> oom killed while the original victim was in free_pgtables().  That's why 
> we've moved the MMF_OOM_SKIP to after free_pgtables().

"we have moved"? No, not yet. Your patch is about to move it.

My question is: is it guaranteed that 
munlock_vma_pages_all()/unmap_vmas()/free_pgtables()
by exit_mmap() are never blocked for memory allocation. Note that exit_mmap() 
tries to unmap
all pages while the OOM reaper tries to unmap only safe pages. If there is 
possibility that
munlock_vma_pages_all()/unmap_vmas()/free_pgtables() by exit_mmap() are blocked 
for memory
allocation, your patch will introduce an OOM livelock.

> I'm not sure how 
> likely your scenario is in the real world, but if it poses a problem then 
> I believe it should be fixed by eventually deferring previous victims as a 
> change to oom_evaluate_task(), not exit_mmap().  If you'd like me to fix 
> that, please send along your test case that triggers it and I will send a 
> patch.
> 

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

[Tetsuo Handa]

David Rientjes wrote:
> On Wed, 18 Apr 2018, Tetsuo Handa wrote:
> > > Fix this by reusing MMF_UNSTABLE to specify that an mm should not be
> > > reaped.  This prevents the concurrent munlock_vma_pages_range() and
> > > unmap_page_range().  The oom reaper will simply not operate on an mm that
> > > has the bit set and leave the unmapping to exit_mmap().
> > 
> > This change assumes that 
> > munlock_vma_pages_all()/unmap_vmas()/free_pgtables()
> > are never blocked for memory allocation. Is that guaranteed? For example,
> > i_mmap_lock_write() from unmap_single_vma() from unmap_vmas() is never 
> > blocked
> > for memory allocation? Commit 97b1255cb27c551d ("mm,oom_reaper: check for
> > MMF_OOM_SKIP before complaining") was waiting for i_mmap_lock_write() from
> > unlink_file_vma() from free_pgtables(). Is it really guaranteed that 
> > somebody
> > else who is holding that lock is never waiting for memory allocation?
> > 
> 
> Commit 97b1255cb27c is referencing MMF_OOM_SKIP already being set by 
> exit_mmap().  The only thing this patch changes is where that is done: 
> before or after free_pgtables().  We can certainly move it to before 
> free_pgtables() at the risk of subsequent (and eventually unnecessary) oom 
> kills.  It's not exactly the point of this patch.
> 
> I have thousands of real-world examples where additional processes were 
> oom killed while the original victim was in free_pgtables().  That's why 
> we've moved the MMF_OOM_SKIP to after free_pgtables().

"we have moved"? No, not yet. Your patch is about to move it.

My question is: is it guaranteed that 
munlock_vma_pages_all()/unmap_vmas()/free_pgtables()
by exit_mmap() are never blocked for memory allocation. Note that exit_mmap() 
tries to unmap
all pages while the OOM reaper tries to unmap only safe pages. If there is 
possibility that
munlock_vma_pages_all()/unmap_vmas()/free_pgtables() by exit_mmap() are blocked 
for memory
allocation, your patch will introduce an OOM livelock.

> I'm not sure how 
> likely your scenario is in the real world, but if it poses a problem then 
> I believe it should be fixed by eventually deferring previous victims as a 
> change to oom_evaluate_task(), not exit_mmap().  If you'd like me to fix 
> that, please send along your test case that triggers it and I will send a 
> patch.
> 

Re: [PATCH 0/3] intel-iommu: fix mapping PSI missing for iommu_map()

[Peter Xu]

On Wed, Apr 18, 2018 at 12:41:27PM +0800, Peter Xu wrote:
> (PSI stands for: Page Selective Invalidations)
> 
> Intel IOMMU has the caching mode to ease emulation of the device.
> When that bit is set, we need to send PSIs even for newly mapped
> pages.  However current driver is not fully obey the rule.  E.g.,
> iommu_map() API will only do the mapping but it never sent the PSIs
> before.  That can be problematic to emulated IOMMU devices since
> they'll never be able to build up the shadow page tables if without
> such information.  This patchset tries to fix the problem.
> 
> Patch 1 is a tracing enhancement that helped me to triage the problem.
> It might even be useful in the future.
> 
> Patch 2 generalized a helper to notify the MAP PSIs.
> 
> Patch 3 fixes the real problem by making sure every domain mapping
> will trigger the MAP PSI notifications.
> 
> Without the patchset, nested device assignment (assign one device
> firstly to L1 guest, then to L2 guest) won't work for QEMU.  After
> applying the patchset, it works.
> 
> Please review.  Thanks.
> 
> Peter Xu (3):
>   intel-iommu: add some traces for PSIs
>   intel-iommu: generalize __mapping_notify_one()
>   intel-iommu: fix iotlb psi missing for mappings
> 
>  drivers/iommu/dmar.c|  3 ++
>  drivers/iommu/intel-iommu.c | 68 
> -
>  2 files changed, 52 insertions(+), 19 deletions(-)

Adding CC to Alexander Witte and Jintack.

-- 
Peter Xu

Re: [PATCH 0/3] intel-iommu: fix mapping PSI missing for iommu_map()

[Peter Xu]

On Wed, Apr 18, 2018 at 12:41:27PM +0800, Peter Xu wrote:
> (PSI stands for: Page Selective Invalidations)
> 
> Intel IOMMU has the caching mode to ease emulation of the device.
> When that bit is set, we need to send PSIs even for newly mapped
> pages.  However current driver is not fully obey the rule.  E.g.,
> iommu_map() API will only do the mapping but it never sent the PSIs
> before.  That can be problematic to emulated IOMMU devices since
> they'll never be able to build up the shadow page tables if without
> such information.  This patchset tries to fix the problem.
> 
> Patch 1 is a tracing enhancement that helped me to triage the problem.
> It might even be useful in the future.
> 
> Patch 2 generalized a helper to notify the MAP PSIs.
> 
> Patch 3 fixes the real problem by making sure every domain mapping
> will trigger the MAP PSI notifications.
> 
> Without the patchset, nested device assignment (assign one device
> firstly to L1 guest, then to L2 guest) won't work for QEMU.  After
> applying the patchset, it works.
> 
> Please review.  Thanks.
> 
> Peter Xu (3):
>   intel-iommu: add some traces for PSIs
>   intel-iommu: generalize __mapping_notify_one()
>   intel-iommu: fix iotlb psi missing for mappings
> 
>  drivers/iommu/dmar.c|  3 ++
>  drivers/iommu/intel-iommu.c | 68 
> -
>  2 files changed, 52 insertions(+), 19 deletions(-)

Adding CC to Alexander Witte and Jintack.

-- 
Peter Xu

Re: [PATCH net-next] net: introduce a new tracepoint for tcp_rcv_space_adjust

[Yafang Shao]

On Wed, Apr 18, 2018 at 7:44 AM, Alexei Starovoitov
 wrote:
> On Mon, Apr 16, 2018 at 08:43:31AM -0700, Eric Dumazet wrote:
>>
>>
>> On 04/16/2018 08:33 AM, Yafang Shao wrote:
>> > tcp_rcv_space_adjust is called every time data is copied to user space,
>> > introducing a tcp tracepoint for which could show us when the packet is
>> > copied to user.
>> > This could help us figure out whether there's latency in user process.
>> >
>> > When a tcp packet arrives, tcp_rcv_established() will be called and with
>> > the existed tracepoint tcp_probe we could get the time when this packet
>> > arrives.
>> > Then this packet will be copied to user, and tcp_rcv_space_adjust will
>> > be called and with this new introduced tracepoint we could get the time
>> > when this packet is copied to user.
>> >
>> > arrives time : user process time=> latency caused by user
>> > tcp_probe  tcp_rcv_space_adjust
>> >
>> > Hence in the prink message, sk is printed as a key to connect these two
>> > tracepoints.
>> >
>>
>> socket pointer is not a key.
>>
>> TCP sockets can be reused pretty fast after free.
>>
>> I suggest you go for cookie instead, this is an unique 64bit identifier.
>> ( sock_gen_cookie() for details )
>
> I think would be even better if the stack would do this sock_gen_cookie()
> on its own in some way that user cannnot infere the order.
> In many cases we wanted to use socket cookie, but since it's not inited
> by default it's kinda useless.
> Turning this tracepoint on just to get cookie would be an ugly workaround.
>

Could we init it in sk_alloc() ?
Then in other code paths, for example sock_getsockopt or tracepoints,
we only read the value through a new inline function named
sock_read_cookie().


Thanks
Yafang

Re: [PATCH net-next] net: introduce a new tracepoint for tcp_rcv_space_adjust

[Yafang Shao]

On Wed, Apr 18, 2018 at 7:44 AM, Alexei Starovoitov
 wrote:
> On Mon, Apr 16, 2018 at 08:43:31AM -0700, Eric Dumazet wrote:
>>
>>
>> On 04/16/2018 08:33 AM, Yafang Shao wrote:
>> > tcp_rcv_space_adjust is called every time data is copied to user space,
>> > introducing a tcp tracepoint for which could show us when the packet is
>> > copied to user.
>> > This could help us figure out whether there's latency in user process.
>> >
>> > When a tcp packet arrives, tcp_rcv_established() will be called and with
>> > the existed tracepoint tcp_probe we could get the time when this packet
>> > arrives.
>> > Then this packet will be copied to user, and tcp_rcv_space_adjust will
>> > be called and with this new introduced tracepoint we could get the time
>> > when this packet is copied to user.
>> >
>> > arrives time : user process time=> latency caused by user
>> > tcp_probe  tcp_rcv_space_adjust
>> >
>> > Hence in the prink message, sk is printed as a key to connect these two
>> > tracepoints.
>> >
>>
>> socket pointer is not a key.
>>
>> TCP sockets can be reused pretty fast after free.
>>
>> I suggest you go for cookie instead, this is an unique 64bit identifier.
>> ( sock_gen_cookie() for details )
>
> I think would be even better if the stack would do this sock_gen_cookie()
> on its own in some way that user cannnot infere the order.
> In many cases we wanted to use socket cookie, but since it's not inited
> by default it's kinda useless.
> Turning this tracepoint on just to get cookie would be an ugly workaround.
>

Could we init it in sk_alloc() ?
Then in other code paths, for example sock_getsockopt or tracepoints,
we only read the value through a new inline function named
sock_read_cookie().


Thanks
Yafang

[PATCH 1/3] intel-iommu: add some traces for PSIs

[Peter Xu]

It is helpful to debug and triage PSI notification missings.

Signed-off-by: Peter Xu 
---
 drivers/iommu/dmar.c| 3 +++
 drivers/iommu/intel-iommu.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 9a7ffd13c7f0..62ae26c3f7b7 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -1325,6 +1325,9 @@ void qi_flush_iotlb(struct intel_iommu *iommu, u16 did, 
u64 addr,
struct qi_desc desc;
int ih = 0;
 
+   pr_debug("%s: iommu %d did %u addr 0x%llx order %u type %llx\n",
+__func__, iommu->seq_id, did, addr, size_order, type);
+
if (cap_write_drain(iommu->cap))
dw = 1;
 
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 582fd01cb7d1..a64da83e867c 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1396,6 +1396,9 @@ static void __iommu_flush_iotlb(struct intel_iommu 
*iommu, u16 did,
u64 val = 0, val_iva = 0;
unsigned long flag;
 
+   pr_debug("%s: iommu %d did %u addr 0x%llx order %u type %llx\n",
+__func__, iommu->seq_id, did, addr, size_order, type);
+
switch (type) {
case DMA_TLB_GLOBAL_FLUSH:
/* global flush doesn't need set IVA_REG */
-- 
2.14.3

[PATCH 1/3] intel-iommu: add some traces for PSIs

[Peter Xu]

It is helpful to debug and triage PSI notification missings.

Signed-off-by: Peter Xu 
---
 drivers/iommu/dmar.c| 3 +++
 drivers/iommu/intel-iommu.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 9a7ffd13c7f0..62ae26c3f7b7 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -1325,6 +1325,9 @@ void qi_flush_iotlb(struct intel_iommu *iommu, u16 did, 
u64 addr,
struct qi_desc desc;
int ih = 0;
 
+   pr_debug("%s: iommu %d did %u addr 0x%llx order %u type %llx\n",
+__func__, iommu->seq_id, did, addr, size_order, type);
+
if (cap_write_drain(iommu->cap))
dw = 1;
 
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 582fd01cb7d1..a64da83e867c 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1396,6 +1396,9 @@ static void __iommu_flush_iotlb(struct intel_iommu 
*iommu, u16 did,
u64 val = 0, val_iva = 0;
unsigned long flag;
 
+   pr_debug("%s: iommu %d did %u addr 0x%llx order %u type %llx\n",
+__func__, iommu->seq_id, did, addr, size_order, type);
+
switch (type) {
case DMA_TLB_GLOBAL_FLUSH:
/* global flush doesn't need set IVA_REG */
-- 
2.14.3

[PATCH 3/3] intel-iommu: fix iotlb psi missing for mappings

[Peter Xu]

When caching mode is enabled for IOMMU, we should send explicit IOTLB
PSIs even for newly created mappings.  However these events are missing
for all intel_iommu_map() callers, e.g., iommu_map().  One direct user
is the vfio-pci driver.

To make sure we'll send the PSIs always when necessary, this patch
firstly introduced domain_mapping() helper for page mappings, then fixed
the problem by generalizing the explicit map IOTLB PSI logic into that
new helper. With that, we let iommu_domain_identity_map() to use the
simplified version to avoid sending the notifications, while for all the
rest of cases we send the notifications always.

For VM case, we send the PSIs to all the backend IOMMUs for the domain.

This patch allows the nested device assignment to work with QEMU (assign
device firstly to L1 guest, then assign it again to L2 guest).

Signed-off-by: Peter Xu 
---
 drivers/iommu/intel-iommu.c | 43 ++-
 1 file changed, 34 insertions(+), 9 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index bf111e60857c..eb0f0911342f 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2353,18 +2353,47 @@ static int __domain_mapping(struct dmar_domain *domain, 
unsigned long iov_pfn,
return 0;
 }
 
+static int domain_mapping(struct dmar_domain *domain, unsigned long iov_pfn,
+ struct scatterlist *sg, unsigned long phys_pfn,
+ unsigned long nr_pages, int prot)
+{
+   int ret;
+   struct intel_iommu *iommu;
+
+   /* Do the real mapping first */
+   ret = __domain_mapping(domain, iov_pfn, sg, phys_pfn, nr_pages, prot);
+   if (ret)
+   return ret;
+
+   /* Notify about the new mapping */
+   if (domain_type_is_vm(domain)) {
+  /* VM typed domains can have more than one IOMMUs */
+  int iommu_id;
+  for_each_domain_iommu(iommu_id, domain) {
+  iommu = g_iommus[iommu_id];
+  __mapping_notify_one(iommu, domain, iov_pfn, nr_pages);
+  }
+   } else {
+  /* General domains only have one IOMMU */
+  iommu = domain_get_iommu(domain);
+  __mapping_notify_one(iommu, domain, iov_pfn, nr_pages);
+   }
+
+   return 0;
+}
+
 static inline int domain_sg_mapping(struct dmar_domain *domain, unsigned long 
iov_pfn,
struct scatterlist *sg, unsigned long 
nr_pages,
int prot)
 {
-   return __domain_mapping(domain, iov_pfn, sg, 0, nr_pages, prot);
+   return domain_mapping(domain, iov_pfn, sg, 0, nr_pages, prot);
 }
 
 static inline int domain_pfn_mapping(struct dmar_domain *domain, unsigned long 
iov_pfn,
 unsigned long phys_pfn, unsigned long 
nr_pages,
 int prot)
 {
-   return __domain_mapping(domain, iov_pfn, NULL, phys_pfn, nr_pages, 
prot);
+   return domain_mapping(domain, iov_pfn, NULL, phys_pfn, nr_pages, prot);
 }
 
 static void domain_context_clear_one(struct intel_iommu *iommu, u8 bus, u8 
devfn)
@@ -2669,9 +2698,9 @@ static int iommu_domain_identity_map(struct dmar_domain 
*domain,
 */
dma_pte_clear_range(domain, first_vpfn, last_vpfn);
 
-   return domain_pfn_mapping(domain, first_vpfn, first_vpfn,
- last_vpfn - first_vpfn + 1,
- DMA_PTE_READ|DMA_PTE_WRITE);
+   return __domain_mapping(domain, first_vpfn, NULL,
+   first_vpfn, last_vpfn - first_vpfn + 1,
+   DMA_PTE_READ|DMA_PTE_WRITE);
 }
 
 static int domain_prepare_identity_map(struct device *dev,
@@ -3638,8 +3667,6 @@ static dma_addr_t __intel_map_single(struct device *dev, 
phys_addr_t paddr,
if (ret)
goto error;
 
-   __mapping_notify_one(iommu, domain, mm_to_dma_pfn(iova_pfn), size);
-
start_paddr = (phys_addr_t)iova_pfn << PAGE_SHIFT;
start_paddr += paddr & ~PAGE_MASK;
return start_paddr;
@@ -3857,8 +3884,6 @@ static int intel_map_sg(struct device *dev, struct 
scatterlist *sglist, int nele
return 0;
}
 
-   __mapping_notify_one(iommu, domain, start_vpfn, size);
-
return nelems;
 }
 
-- 
2.14.3

[PATCH 3/3] intel-iommu: fix iotlb psi missing for mappings

[Peter Xu]

When caching mode is enabled for IOMMU, we should send explicit IOTLB
PSIs even for newly created mappings.  However these events are missing
for all intel_iommu_map() callers, e.g., iommu_map().  One direct user
is the vfio-pci driver.

To make sure we'll send the PSIs always when necessary, this patch
firstly introduced domain_mapping() helper for page mappings, then fixed
the problem by generalizing the explicit map IOTLB PSI logic into that
new helper. With that, we let iommu_domain_identity_map() to use the
simplified version to avoid sending the notifications, while for all the
rest of cases we send the notifications always.

For VM case, we send the PSIs to all the backend IOMMUs for the domain.

This patch allows the nested device assignment to work with QEMU (assign
device firstly to L1 guest, then assign it again to L2 guest).

Signed-off-by: Peter Xu 
---
 drivers/iommu/intel-iommu.c | 43 ++-
 1 file changed, 34 insertions(+), 9 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index bf111e60857c..eb0f0911342f 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2353,18 +2353,47 @@ static int __domain_mapping(struct dmar_domain *domain, 
unsigned long iov_pfn,
return 0;
 }
 
+static int domain_mapping(struct dmar_domain *domain, unsigned long iov_pfn,
+ struct scatterlist *sg, unsigned long phys_pfn,
+ unsigned long nr_pages, int prot)
+{
+   int ret;
+   struct intel_iommu *iommu;
+
+   /* Do the real mapping first */
+   ret = __domain_mapping(domain, iov_pfn, sg, phys_pfn, nr_pages, prot);
+   if (ret)
+   return ret;
+
+   /* Notify about the new mapping */
+   if (domain_type_is_vm(domain)) {
+  /* VM typed domains can have more than one IOMMUs */
+  int iommu_id;
+  for_each_domain_iommu(iommu_id, domain) {
+  iommu = g_iommus[iommu_id];
+  __mapping_notify_one(iommu, domain, iov_pfn, nr_pages);
+  }
+   } else {
+  /* General domains only have one IOMMU */
+  iommu = domain_get_iommu(domain);
+  __mapping_notify_one(iommu, domain, iov_pfn, nr_pages);
+   }
+
+   return 0;
+}
+
 static inline int domain_sg_mapping(struct dmar_domain *domain, unsigned long 
iov_pfn,
struct scatterlist *sg, unsigned long 
nr_pages,
int prot)
 {
-   return __domain_mapping(domain, iov_pfn, sg, 0, nr_pages, prot);
+   return domain_mapping(domain, iov_pfn, sg, 0, nr_pages, prot);
 }
 
 static inline int domain_pfn_mapping(struct dmar_domain *domain, unsigned long 
iov_pfn,
 unsigned long phys_pfn, unsigned long 
nr_pages,
 int prot)
 {
-   return __domain_mapping(domain, iov_pfn, NULL, phys_pfn, nr_pages, 
prot);
+   return domain_mapping(domain, iov_pfn, NULL, phys_pfn, nr_pages, prot);
 }
 
 static void domain_context_clear_one(struct intel_iommu *iommu, u8 bus, u8 
devfn)
@@ -2669,9 +2698,9 @@ static int iommu_domain_identity_map(struct dmar_domain 
*domain,
 */
dma_pte_clear_range(domain, first_vpfn, last_vpfn);
 
-   return domain_pfn_mapping(domain, first_vpfn, first_vpfn,
- last_vpfn - first_vpfn + 1,
- DMA_PTE_READ|DMA_PTE_WRITE);
+   return __domain_mapping(domain, first_vpfn, NULL,
+   first_vpfn, last_vpfn - first_vpfn + 1,
+   DMA_PTE_READ|DMA_PTE_WRITE);
 }
 
 static int domain_prepare_identity_map(struct device *dev,
@@ -3638,8 +3667,6 @@ static dma_addr_t __intel_map_single(struct device *dev, 
phys_addr_t paddr,
if (ret)
goto error;
 
-   __mapping_notify_one(iommu, domain, mm_to_dma_pfn(iova_pfn), size);
-
start_paddr = (phys_addr_t)iova_pfn << PAGE_SHIFT;
start_paddr += paddr & ~PAGE_MASK;
return start_paddr;
@@ -3857,8 +3884,6 @@ static int intel_map_sg(struct device *dev, struct 
scatterlist *sglist, int nele
return 0;
}
 
-   __mapping_notify_one(iommu, domain, start_vpfn, size);
-
return nelems;
 }
 
-- 
2.14.3

[PATCH 2/3] intel-iommu: generalize __mapping_notify_one()

[Peter Xu]

Generalize this new helper to notify one newly created mapping on one
single IOMMU.  We can further leverage this helper in the next patch.

Signed-off-by: Peter Xu 
---
 drivers/iommu/intel-iommu.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index a64da83e867c..bf111e60857c 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1607,6 +1607,18 @@ static void iommu_flush_iotlb_psi(struct intel_iommu 
*iommu,
iommu_flush_dev_iotlb(domain, addr, mask);
 }
 
+/* Notification for newly created mappings */
+static inline void __mapping_notify_one(struct intel_iommu *iommu,
+   struct dmar_domain *domain,
+   unsigned long pfn, unsigned int pages)
+{
+   /* It's a non-present to present mapping. Only flush if caching mode */
+   if (cap_caching_mode(iommu->cap))
+   iommu_flush_iotlb_psi(iommu, domain, pfn, pages, 0, 1);
+   else
+   iommu_flush_write_buffer(iommu);
+}
+
 static void iommu_flush_iova(struct iova_domain *iovad)
 {
struct dmar_domain *domain;
@@ -3626,13 +3638,7 @@ static dma_addr_t __intel_map_single(struct device *dev, 
phys_addr_t paddr,
if (ret)
goto error;
 
-   /* it's a non-present to present mapping. Only flush if caching mode */
-   if (cap_caching_mode(iommu->cap))
-   iommu_flush_iotlb_psi(iommu, domain,
- mm_to_dma_pfn(iova_pfn),
- size, 0, 1);
-   else
-   iommu_flush_write_buffer(iommu);
+   __mapping_notify_one(iommu, domain, mm_to_dma_pfn(iova_pfn), size);
 
start_paddr = (phys_addr_t)iova_pfn << PAGE_SHIFT;
start_paddr += paddr & ~PAGE_MASK;
@@ -3851,11 +3857,7 @@ static int intel_map_sg(struct device *dev, struct 
scatterlist *sglist, int nele
return 0;
}
 
-   /* it's a non-present to present mapping. Only flush if caching mode */
-   if (cap_caching_mode(iommu->cap))
-   iommu_flush_iotlb_psi(iommu, domain, start_vpfn, size, 0, 1);
-   else
-   iommu_flush_write_buffer(iommu);
+   __mapping_notify_one(iommu, domain, start_vpfn, size);
 
return nelems;
 }
-- 
2.14.3

[PATCH 2/3] intel-iommu: generalize __mapping_notify_one()

[Peter Xu]

Generalize this new helper to notify one newly created mapping on one
single IOMMU.  We can further leverage this helper in the next patch.

Signed-off-by: Peter Xu 
---
 drivers/iommu/intel-iommu.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index a64da83e867c..bf111e60857c 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1607,6 +1607,18 @@ static void iommu_flush_iotlb_psi(struct intel_iommu 
*iommu,
iommu_flush_dev_iotlb(domain, addr, mask);
 }
 
+/* Notification for newly created mappings */
+static inline void __mapping_notify_one(struct intel_iommu *iommu,
+   struct dmar_domain *domain,
+   unsigned long pfn, unsigned int pages)
+{
+   /* It's a non-present to present mapping. Only flush if caching mode */
+   if (cap_caching_mode(iommu->cap))
+   iommu_flush_iotlb_psi(iommu, domain, pfn, pages, 0, 1);
+   else
+   iommu_flush_write_buffer(iommu);
+}
+
 static void iommu_flush_iova(struct iova_domain *iovad)
 {
struct dmar_domain *domain;
@@ -3626,13 +3638,7 @@ static dma_addr_t __intel_map_single(struct device *dev, 
phys_addr_t paddr,
if (ret)
goto error;
 
-   /* it's a non-present to present mapping. Only flush if caching mode */
-   if (cap_caching_mode(iommu->cap))
-   iommu_flush_iotlb_psi(iommu, domain,
- mm_to_dma_pfn(iova_pfn),
- size, 0, 1);
-   else
-   iommu_flush_write_buffer(iommu);
+   __mapping_notify_one(iommu, domain, mm_to_dma_pfn(iova_pfn), size);
 
start_paddr = (phys_addr_t)iova_pfn << PAGE_SHIFT;
start_paddr += paddr & ~PAGE_MASK;
@@ -3851,11 +3857,7 @@ static int intel_map_sg(struct device *dev, struct 
scatterlist *sglist, int nele
return 0;
}
 
-   /* it's a non-present to present mapping. Only flush if caching mode */
-   if (cap_caching_mode(iommu->cap))
-   iommu_flush_iotlb_psi(iommu, domain, start_vpfn, size, 0, 1);
-   else
-   iommu_flush_write_buffer(iommu);
+   __mapping_notify_one(iommu, domain, start_vpfn, size);
 
return nelems;
 }
-- 
2.14.3

[PATCH 0/3] intel-iommu: fix mapping PSI missing for iommu_map()

[Peter Xu]

(PSI stands for: Page Selective Invalidations)

Intel IOMMU has the caching mode to ease emulation of the device.
When that bit is set, we need to send PSIs even for newly mapped
pages.  However current driver is not fully obey the rule.  E.g.,
iommu_map() API will only do the mapping but it never sent the PSIs
before.  That can be problematic to emulated IOMMU devices since
they'll never be able to build up the shadow page tables if without
such information.  This patchset tries to fix the problem.

Patch 1 is a tracing enhancement that helped me to triage the problem.
It might even be useful in the future.

Patch 2 generalized a helper to notify the MAP PSIs.

Patch 3 fixes the real problem by making sure every domain mapping
will trigger the MAP PSI notifications.

Without the patchset, nested device assignment (assign one device
firstly to L1 guest, then to L2 guest) won't work for QEMU.  After
applying the patchset, it works.

Please review.  Thanks.

Peter Xu (3):
  intel-iommu: add some traces for PSIs
  intel-iommu: generalize __mapping_notify_one()
  intel-iommu: fix iotlb psi missing for mappings

 drivers/iommu/dmar.c|  3 ++
 drivers/iommu/intel-iommu.c | 68 -
 2 files changed, 52 insertions(+), 19 deletions(-)

-- 
2.14.3

[PATCH 0/3] intel-iommu: fix mapping PSI missing for iommu_map()

[Peter Xu]

(PSI stands for: Page Selective Invalidations)

Intel IOMMU has the caching mode to ease emulation of the device.
When that bit is set, we need to send PSIs even for newly mapped
pages.  However current driver is not fully obey the rule.  E.g.,
iommu_map() API will only do the mapping but it never sent the PSIs
before.  That can be problematic to emulated IOMMU devices since
they'll never be able to build up the shadow page tables if without
such information.  This patchset tries to fix the problem.

Patch 1 is a tracing enhancement that helped me to triage the problem.
It might even be useful in the future.

Patch 2 generalized a helper to notify the MAP PSIs.

Patch 3 fixes the real problem by making sure every domain mapping
will trigger the MAP PSI notifications.

Without the patchset, nested device assignment (assign one device
firstly to L1 guest, then to L2 guest) won't work for QEMU.  After
applying the patchset, it works.

Please review.  Thanks.

Peter Xu (3):
  intel-iommu: add some traces for PSIs
  intel-iommu: generalize __mapping_notify_one()
  intel-iommu: fix iotlb psi missing for mappings

 drivers/iommu/dmar.c|  3 ++
 drivers/iommu/intel-iommu.c | 68 -
 2 files changed, 52 insertions(+), 19 deletions(-)

-- 
2.14.3

Re: [PATCH/RFC] crypto: Add platform dependencies for CRYPTO_DEV_CCREE

[Gilad Ben-Yossef]

Hi Geert,

On Tue, Apr 17, 2018 at 9:14 PM, Geert Uytterhoeven
 wrote:
> The ARM TrustZone CryptoCell is found on ARM SoCs only.  Hence make it
> depend on ARM or ARM64, unless compile-testing.
>

Actually it is not. Despite what the name suggest, CryptoCell is
designed by Arm but is
not in fact limited to Arm cores. I think the only requirement is
ability to provide an AMBA bus
interface. Kudos to our marketing department to make that so clear and
so on... :-)

There are in fact licensees of this IP which use it with other (Linux
running) architectures, perhaps
thanks to the fact that the design originated in an outside company
(Discretix) which was bought by Arm.

Therefore, NAK on the specific patch. However, if there is some build
issue with a none Arm
architecture I of course very interested to hear about it.

Many thanks,
Gilad





-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH/RFC] crypto: Add platform dependencies for CRYPTO_DEV_CCREE

[Gilad Ben-Yossef]

Hi Geert,

On Tue, Apr 17, 2018 at 9:14 PM, Geert Uytterhoeven
 wrote:
> The ARM TrustZone CryptoCell is found on ARM SoCs only.  Hence make it
> depend on ARM or ARM64, unless compile-testing.
>

Actually it is not. Despite what the name suggest, CryptoCell is
designed by Arm but is
not in fact limited to Arm cores. I think the only requirement is
ability to provide an AMBA bus
interface. Kudos to our marketing department to make that so clear and
so on... :-)

There are in fact licensees of this IP which use it with other (Linux
running) architectures, perhaps
thanks to the fact that the design originated in an outside company
(Discretix) which was bought by Arm.

Therefore, NAK on the specific patch. However, if there is some build
issue with a none Arm
architecture I of course very interested to hear about it.

Many thanks,
Gilad





-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create

[David Rientjes]

On Tue, 17 Apr 2018, Matthew Wilcox wrote:

> Not arguing against this patch.  But how many places do we want to use
> GFP_NOWAIT without __GFP_NOWARN?  Not many, and the few which do do this
> seem like they simply haven't added it yet.  Maybe this would be a good idea?
> 
> -#define GFP_NOWAIT  (__GFP_KSWAPD_RECLAIM)
> +#define GFP_NOWAIT  (__GFP_KSWAPD_RECLAIM | __GFP_NOWARN)
> 

I don't think that's a good idea, slab allocators use GFP_NOWAIT during 
init, for example, followed up with a BUG_ON() if it fails.  With an 
implicit __GFP_NOWARN we wouldn't be able to see the state of memory when 
it crashes (likely memory that wasn't freed to the allocator).  I think 
whether the allocation failure should trigger a warning is up to the 
caller.

Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create

[David Rientjes]

On Tue, 17 Apr 2018, Matthew Wilcox wrote:

> Not arguing against this patch.  But how many places do we want to use
> GFP_NOWAIT without __GFP_NOWARN?  Not many, and the few which do do this
> seem like they simply haven't added it yet.  Maybe this would be a good idea?
> 
> -#define GFP_NOWAIT  (__GFP_KSWAPD_RECLAIM)
> +#define GFP_NOWAIT  (__GFP_KSWAPD_RECLAIM | __GFP_NOWARN)
> 

I don't think that's a good idea, slab allocators use GFP_NOWAIT during 
init, for example, followed up with a BUG_ON() if it fails.  With an 
implicit __GFP_NOWARN we wouldn't be able to see the state of memory when 
it crashes (likely memory that wasn't freed to the allocator).  I think 
whether the allocation failure should trigger a warning is up to the 
caller.

Re: [PATCH] f2fs: set deadline to drop expired inmem pages

[Jaegeuk Kim]

On 04/17, Chao Yu wrote:
> On 2018/4/17 14:44, Chao Yu wrote:
> > On 2018/4/17 4:16, Jaegeuk Kim wrote:
> >> On 04/13, Chao Yu wrote:
> >>> On 2018/4/13 12:05, Jaegeuk Kim wrote:
>  On 04/13, Chao Yu wrote:
> > On 2018/4/13 9:04, Jaegeuk Kim wrote:
> >> On 04/10, Chao Yu wrote:
> >>> Hi Jaegeuk,
> >>>
> >>> On 2018/4/8 16:13, Chao Yu wrote:
>  f2fs doesn't allow abuse on atomic write class interface, so except
>  limiting in-mem pages' total memory usage capacity, we need to limit
>  start-commit time as well, otherwise we may run into infinite loop
>  during foreground GC because target blocks in victim segment are
>  belong to atomic opened file for long time.
> 
>  Now, we will check the condition with f2fs_balance_fs_bg in
>  background threads, once if user doesn't commit data exceeding 30
>  seconds, we will drop all cached data, so I expect it can keep our
>  system running safely to prevent Dos attack.
> >>>
> >>> Is it worth to add this patch to avoid abuse on atomic write 
> >>> interface by user?
> >>
> >> Hmm, hope to see a real problem first in this case.
> >
> > I think this can be a more critical security leak instead of a 
> > potential issue
> > which we can wait for someone reporting that can be too late.
> >
> > For example, user can simply write a huge file whose data spread in all 
> > f2fs
> > segments, once user open that file as atomic, foreground GC will suffer
> > deadloop, causing denying any further service of f2fs.
> 
>  How can you guarantee it won't happen within 30sec? If you want to avoid 
>  that,
> >>>
> >>> Now the value is smaller than generic hang task threshold in order to 
> >>> avoid
> >>> foreground GC helding gc_mutex too long, we can tune that parameter?
> >>>
>  you have to take a look at foreground gc.
> >>>
> >>> What do you mean? let GC moves blocks of atomic write opened file?
> >>
> >> I thought that we first need to detect when foreground GC is stuck by such 
> >> the
> >> huge number of atomic writes. Then, we need to do something like dropping 
> >> all
> >> the atomic writes.
> > 
> > Yup, that will be reasonable. :)
> 
> If we drop all atomic writes, for those atomic write who act very normal, it
> will case them losing all cached data without any hint like error return 
> value.
> So should we just:
> 
> - drop expired inmem pages.
> - or set FI_DROP_ATOMIC flag, return -EIO during atomic_commit, and reset the 
> flag.

Like FI_ATOMIC_REVOKE_REQUEST in atomic_commit?

> 
> Thanks,
> 
> > 
> > Thanks,
> > 
> >>
> >>>
> >>> Thanks,
> >>>
> 
> >
> > Thanks,
> >
> >>
> >>> Thanks,
> >>
> >> .
> >>
> 
>  .
> 
> >>
> >> .
> >>
> > 
> > 
> > .
> > 

Re: [PATCH] f2fs: set deadline to drop expired inmem pages

[Jaegeuk Kim]

On 04/17, Chao Yu wrote:
> On 2018/4/17 14:44, Chao Yu wrote:
> > On 2018/4/17 4:16, Jaegeuk Kim wrote:
> >> On 04/13, Chao Yu wrote:
> >>> On 2018/4/13 12:05, Jaegeuk Kim wrote:
>  On 04/13, Chao Yu wrote:
> > On 2018/4/13 9:04, Jaegeuk Kim wrote:
> >> On 04/10, Chao Yu wrote:
> >>> Hi Jaegeuk,
> >>>
> >>> On 2018/4/8 16:13, Chao Yu wrote:
>  f2fs doesn't allow abuse on atomic write class interface, so except
>  limiting in-mem pages' total memory usage capacity, we need to limit
>  start-commit time as well, otherwise we may run into infinite loop
>  during foreground GC because target blocks in victim segment are
>  belong to atomic opened file for long time.
> 
>  Now, we will check the condition with f2fs_balance_fs_bg in
>  background threads, once if user doesn't commit data exceeding 30
>  seconds, we will drop all cached data, so I expect it can keep our
>  system running safely to prevent Dos attack.
> >>>
> >>> Is it worth to add this patch to avoid abuse on atomic write 
> >>> interface by user?
> >>
> >> Hmm, hope to see a real problem first in this case.
> >
> > I think this can be a more critical security leak instead of a 
> > potential issue
> > which we can wait for someone reporting that can be too late.
> >
> > For example, user can simply write a huge file whose data spread in all 
> > f2fs
> > segments, once user open that file as atomic, foreground GC will suffer
> > deadloop, causing denying any further service of f2fs.
> 
>  How can you guarantee it won't happen within 30sec? If you want to avoid 
>  that,
> >>>
> >>> Now the value is smaller than generic hang task threshold in order to 
> >>> avoid
> >>> foreground GC helding gc_mutex too long, we can tune that parameter?
> >>>
>  you have to take a look at foreground gc.
> >>>
> >>> What do you mean? let GC moves blocks of atomic write opened file?
> >>
> >> I thought that we first need to detect when foreground GC is stuck by such 
> >> the
> >> huge number of atomic writes. Then, we need to do something like dropping 
> >> all
> >> the atomic writes.
> > 
> > Yup, that will be reasonable. :)
> 
> If we drop all atomic writes, for those atomic write who act very normal, it
> will case them losing all cached data without any hint like error return 
> value.
> So should we just:
> 
> - drop expired inmem pages.
> - or set FI_DROP_ATOMIC flag, return -EIO during atomic_commit, and reset the 
> flag.

Like FI_ATOMIC_REVOKE_REQUEST in atomic_commit?

> 
> Thanks,
> 
> > 
> > Thanks,
> > 
> >>
> >>>
> >>> Thanks,
> >>>
> 
> >
> > Thanks,
> >
> >>
> >>> Thanks,
> >>
> >> .
> >>
> 
>  .
> 
> >>
> >> .
> >>
> > 
> > 
> > .
> > 

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

[David Rientjes]

On Wed, 18 Apr 2018, Tetsuo Handa wrote:

> > Fix this by reusing MMF_UNSTABLE to specify that an mm should not be
> > reaped.  This prevents the concurrent munlock_vma_pages_range() and
> > unmap_page_range().  The oom reaper will simply not operate on an mm that
> > has the bit set and leave the unmapping to exit_mmap().
> 
> This change assumes that munlock_vma_pages_all()/unmap_vmas()/free_pgtables()
> are never blocked for memory allocation. Is that guaranteed? For example,
> i_mmap_lock_write() from unmap_single_vma() from unmap_vmas() is never blocked
> for memory allocation? Commit 97b1255cb27c551d ("mm,oom_reaper: check for
> MMF_OOM_SKIP before complaining") was waiting for i_mmap_lock_write() from
> unlink_file_vma() from free_pgtables(). Is it really guaranteed that somebody
> else who is holding that lock is never waiting for memory allocation?
> 

Commit 97b1255cb27c is referencing MMF_OOM_SKIP already being set by 
exit_mmap().  The only thing this patch changes is where that is done: 
before or after free_pgtables().  We can certainly move it to before 
free_pgtables() at the risk of subsequent (and eventually unnecessary) oom 
kills.  It's not exactly the point of this patch.

I have thousands of real-world examples where additional processes were 
oom killed while the original victim was in free_pgtables().  That's why 
we've moved the MMF_OOM_SKIP to after free_pgtables().  I'm not sure how 
likely your scenario is in the real world, but if it poses a problem then 
I believe it should be fixed by eventually deferring previous victims as a 
change to oom_evaluate_task(), not exit_mmap().  If you'd like me to fix 
that, please send along your test case that triggers it and I will send a 
patch.

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

[David Rientjes]

On Wed, 18 Apr 2018, Tetsuo Handa wrote:

> > Fix this by reusing MMF_UNSTABLE to specify that an mm should not be
> > reaped.  This prevents the concurrent munlock_vma_pages_range() and
> > unmap_page_range().  The oom reaper will simply not operate on an mm that
> > has the bit set and leave the unmapping to exit_mmap().
> 
> This change assumes that munlock_vma_pages_all()/unmap_vmas()/free_pgtables()
> are never blocked for memory allocation. Is that guaranteed? For example,
> i_mmap_lock_write() from unmap_single_vma() from unmap_vmas() is never blocked
> for memory allocation? Commit 97b1255cb27c551d ("mm,oom_reaper: check for
> MMF_OOM_SKIP before complaining") was waiting for i_mmap_lock_write() from
> unlink_file_vma() from free_pgtables(). Is it really guaranteed that somebody
> else who is holding that lock is never waiting for memory allocation?
> 

Commit 97b1255cb27c is referencing MMF_OOM_SKIP already being set by 
exit_mmap().  The only thing this patch changes is where that is done: 
before or after free_pgtables().  We can certainly move it to before 
free_pgtables() at the risk of subsequent (and eventually unnecessary) oom 
kills.  It's not exactly the point of this patch.

I have thousands of real-world examples where additional processes were 
oom killed while the original victim was in free_pgtables().  That's why 
we've moved the MMF_OOM_SKIP to after free_pgtables().  I'm not sure how 
likely your scenario is in the real world, but if it poses a problem then 
I believe it should be fixed by eventually deferring previous victims as a 
change to oom_evaluate_task(), not exit_mmap().  If you'd like me to fix 
that, please send along your test case that triggers it and I will send a 
patch.

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

[Tetsuo Handa]

David Rientjes wrote:
> Fix this by reusing MMF_UNSTABLE to specify that an mm should not be
> reaped.  This prevents the concurrent munlock_vma_pages_range() and
> unmap_page_range().  The oom reaper will simply not operate on an mm that
> has the bit set and leave the unmapping to exit_mmap().

This change assumes that munlock_vma_pages_all()/unmap_vmas()/free_pgtables()
are never blocked for memory allocation. Is that guaranteed? For example,
i_mmap_lock_write() from unmap_single_vma() from unmap_vmas() is never blocked
for memory allocation? Commit 97b1255cb27c551d ("mm,oom_reaper: check for
MMF_OOM_SKIP before complaining") was waiting for i_mmap_lock_write() from
unlink_file_vma() from free_pgtables(). Is it really guaranteed that somebody
else who is holding that lock is never waiting for memory allocation?

Re: [PATCH v5] ARM: dts: tpc: Device tree description of the iMX6Q TPC board

[Shawn Guo]

On Tue, Apr 10, 2018 at 10:32:09PM +0200, Lukasz Majewski wrote:
> This commit adds device tree description of Kieback & Peter GmbH
> iMX6Q TPC board.
> 
> Signed-off-by: Lukasz Majewski 
> Reviewed-by: Fabio Estevam 
> 
> ---
> Changes for v5:
> - Use 'interpolation-steps' to fill the brightness level table
> - Remove not needed status = "okay" properties
> - Replace goodix_ts -> touchscreen
> - Replace sgtl5000 -> audio-codec
> 
> This patch depends on PWM backlight intepolation work:
> https://patchwork.kernel.org/patch/10330775/
> https://patchwork.kernel.org/patch/10330777/
> 
> Changes for v4:
> - Remove not needed bus-format-override = "rgb565";
>   property
> 
> Changes for v3:
> - Provide proper compatible for RTC DTS node
> - Remove wrong comment style for beeper
> - Add proper SPDX entries for DTS files
> - Add vendor prefix to a separate patch
> 
> Changes for v2:
> - SPDX license identifiers used
> - Separate regulators
> - Proper beeper driver
> - Use of the lcd panel (with compatible) instead of timings provided in
>   device tree
> - Add IRQ types (like IRQ_TYPE_EDGE_FALLING) and GPIO active levels (like
>   GPIO_ACTIVE_HIGH)
> - Remove not needed nodes
> - Make W=1 dtbs compilation with no errors
> ---
>  arch/arm/boot/dts/Makefile |   1 +
>  arch/arm/boot/dts/imx6q-kp-tpc.dts |  22 ++
>  arch/arm/boot/dts/imx6q-kp.dtsi| 432 
> +
>  3 files changed, 455 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6q-kp-tpc.dts
>  create mode 100644 arch/arm/boot/dts/imx6q-kp.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index ade7a38543dc..c148c4cf28f2 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -459,6 +459,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>   imx6q-icore-ofcap10.dtb \
>   imx6q-icore-ofcap12.dtb \
>   imx6q-icore-rqs.dtb \
> + imx6q-kp-tpc.dtb \
>   imx6q-marsboard.dtb \
>   imx6q-mccmon6.dtb \
>   imx6q-nitrogen6x.dtb \
> diff --git a/arch/arm/boot/dts/imx6q-kp-tpc.dts 
> b/arch/arm/boot/dts/imx6q-kp-tpc.dts
> new file mode 100644
> index ..c3dea0ec54ac
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-kp-tpc.dts
> @@ -0,0 +1,22 @@
> +//SPDX-License-Identifier: (GPL-2.0+ OR MIT)

There should be a space after //.

> +/*
> + * Copyright 2018
> + * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
> + */
> +
> +/dts-v1/;
> +
> +#include "imx6q-kp.dtsi"
> +
> +/ {
> + model = "Freescale i.MX6 Qwuad K+P TPC Board";
> + compatible = "kiebackpeter,imx6q-tpc", "fsl,imx6q";
> +
> + memory@1000 {
> + reg = <0x1000 0x4000>;
> + };
> +};
> +
> +_di0_disp0 {
> + remote-endpoint = <_display_in>;
> +};
> diff --git a/arch/arm/boot/dts/imx6q-kp.dtsi b/arch/arm/boot/dts/imx6q-kp.dtsi
> new file mode 100644
> index ..174d044cf8bf
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-kp.dtsi
> @@ -0,0 +1,432 @@
> +//SPDX-License-Identifier: (GPL-2.0+ OR MIT)

Ditto

> +/*
> + * Copyright 2018
> + * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
> + */
> +
> +/dts-v1/;
> +
> +#include "imx6q.dtsi"
> +
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + backlight_lcd: backlight-lcd {
> + compatible = "pwm-backlight";
> + pwms = < 0 500>;
> + brightness-levels = <0 255>;
> + num-interpolated-steps = <255>;
> + default-brightness-level = <250>;
> + };
> +
> + beeper {
> + compatible = "pwm-beeper";
> + pwms = < 0 50>;
> + };
> +
> + lcd_display: disp0 {

s/disp0/display

> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "rgb24";
> + pinctrl-names = "default";
> + pinctrl-0 = <_ipu1>;
> +
> + port@0 {
> + reg = <0>;
> +
> + lcd_display_in: endpoint {
> + remote-endpoint = <_di0_disp0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + lcd_display_out: endpoint {
> + remote-endpoint = <_panel_in>;
> + };
> + };
> + };
> +
> + lcd_panel: lcd-panel {
> + compatible = "auo,g070vvn01";
> + backlight = <_lcd>;
> + power-supply = <_display>;
> +
> + port {
> + lcd_panel_in: endpoint {
> + remote-endpoint = <_display_out>;
> + };
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + green {
> + label = "led1";
> + gpios = < 16 GPIO_ACTIVE_HIGH>;
> + 

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

[Tetsuo Handa]

David Rientjes wrote:
> Fix this by reusing MMF_UNSTABLE to specify that an mm should not be
> reaped.  This prevents the concurrent munlock_vma_pages_range() and
> unmap_page_range().  The oom reaper will simply not operate on an mm that
> has the bit set and leave the unmapping to exit_mmap().

This change assumes that munlock_vma_pages_all()/unmap_vmas()/free_pgtables()
are never blocked for memory allocation. Is that guaranteed? For example,
i_mmap_lock_write() from unmap_single_vma() from unmap_vmas() is never blocked
for memory allocation? Commit 97b1255cb27c551d ("mm,oom_reaper: check for
MMF_OOM_SKIP before complaining") was waiting for i_mmap_lock_write() from
unlink_file_vma() from free_pgtables(). Is it really guaranteed that somebody
else who is holding that lock is never waiting for memory allocation?

Re: [PATCH v5] ARM: dts: tpc: Device tree description of the iMX6Q TPC board

[Shawn Guo]

On Tue, Apr 10, 2018 at 10:32:09PM +0200, Lukasz Majewski wrote:
> This commit adds device tree description of Kieback & Peter GmbH
> iMX6Q TPC board.
> 
> Signed-off-by: Lukasz Majewski 
> Reviewed-by: Fabio Estevam 
> 
> ---
> Changes for v5:
> - Use 'interpolation-steps' to fill the brightness level table
> - Remove not needed status = "okay" properties
> - Replace goodix_ts -> touchscreen
> - Replace sgtl5000 -> audio-codec
> 
> This patch depends on PWM backlight intepolation work:
> https://patchwork.kernel.org/patch/10330775/
> https://patchwork.kernel.org/patch/10330777/
> 
> Changes for v4:
> - Remove not needed bus-format-override = "rgb565";
>   property
> 
> Changes for v3:
> - Provide proper compatible for RTC DTS node
> - Remove wrong comment style for beeper
> - Add proper SPDX entries for DTS files
> - Add vendor prefix to a separate patch
> 
> Changes for v2:
> - SPDX license identifiers used
> - Separate regulators
> - Proper beeper driver
> - Use of the lcd panel (with compatible) instead of timings provided in
>   device tree
> - Add IRQ types (like IRQ_TYPE_EDGE_FALLING) and GPIO active levels (like
>   GPIO_ACTIVE_HIGH)
> - Remove not needed nodes
> - Make W=1 dtbs compilation with no errors
> ---
>  arch/arm/boot/dts/Makefile |   1 +
>  arch/arm/boot/dts/imx6q-kp-tpc.dts |  22 ++
>  arch/arm/boot/dts/imx6q-kp.dtsi| 432 
> +
>  3 files changed, 455 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6q-kp-tpc.dts
>  create mode 100644 arch/arm/boot/dts/imx6q-kp.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index ade7a38543dc..c148c4cf28f2 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -459,6 +459,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>   imx6q-icore-ofcap10.dtb \
>   imx6q-icore-ofcap12.dtb \
>   imx6q-icore-rqs.dtb \
> + imx6q-kp-tpc.dtb \
>   imx6q-marsboard.dtb \
>   imx6q-mccmon6.dtb \
>   imx6q-nitrogen6x.dtb \
> diff --git a/arch/arm/boot/dts/imx6q-kp-tpc.dts 
> b/arch/arm/boot/dts/imx6q-kp-tpc.dts
> new file mode 100644
> index ..c3dea0ec54ac
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-kp-tpc.dts
> @@ -0,0 +1,22 @@
> +//SPDX-License-Identifier: (GPL-2.0+ OR MIT)

There should be a space after //.

> +/*
> + * Copyright 2018
> + * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
> + */
> +
> +/dts-v1/;
> +
> +#include "imx6q-kp.dtsi"
> +
> +/ {
> + model = "Freescale i.MX6 Qwuad K+P TPC Board";
> + compatible = "kiebackpeter,imx6q-tpc", "fsl,imx6q";
> +
> + memory@1000 {
> + reg = <0x1000 0x4000>;
> + };
> +};
> +
> +_di0_disp0 {
> + remote-endpoint = <_display_in>;
> +};
> diff --git a/arch/arm/boot/dts/imx6q-kp.dtsi b/arch/arm/boot/dts/imx6q-kp.dtsi
> new file mode 100644
> index ..174d044cf8bf
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-kp.dtsi
> @@ -0,0 +1,432 @@
> +//SPDX-License-Identifier: (GPL-2.0+ OR MIT)

Ditto

> +/*
> + * Copyright 2018
> + * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
> + */
> +
> +/dts-v1/;
> +
> +#include "imx6q.dtsi"
> +
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + backlight_lcd: backlight-lcd {
> + compatible = "pwm-backlight";
> + pwms = < 0 500>;
> + brightness-levels = <0 255>;
> + num-interpolated-steps = <255>;
> + default-brightness-level = <250>;
> + };
> +
> + beeper {
> + compatible = "pwm-beeper";
> + pwms = < 0 50>;
> + };
> +
> + lcd_display: disp0 {

s/disp0/display

> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "rgb24";
> + pinctrl-names = "default";
> + pinctrl-0 = <_ipu1>;
> +
> + port@0 {
> + reg = <0>;
> +
> + lcd_display_in: endpoint {
> + remote-endpoint = <_di0_disp0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + lcd_display_out: endpoint {
> + remote-endpoint = <_panel_in>;
> + };
> + };
> + };
> +
> + lcd_panel: lcd-panel {
> + compatible = "auo,g070vvn01";
> + backlight = <_lcd>;
> + power-supply = <_display>;
> +
> + port {
> + lcd_panel_in: endpoint {
> + remote-endpoint = <_display_out>;
> + };
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + green {
> + label = "led1";
> + gpios = < 16 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "gpio";
> +

Re: [PATCH] regulator: Fix return type of of_map_mode()

[Doug Anderson]

Hi,

On Tue, Apr 17, 2018 at 10:48 AM, Javier Martinez Canillas
 wrote:
>>> Let's fix the return type of all of the current of_map_mode()
>>> functions.  While we're at it, we'll remove one pointless "inline".
>>
>> Ah, I see...  the thing here is that the mode is always an unsigned int
>> since it's a bitmask - this goes out beying the use in of_map_mode() and
>> into all the other APIs.  We only actually use 4 bits currently so I
>> think there's no problem switching to int but it seems we should
>> probably do that consistently throughout the API so that things don't
>> get missed later on.
>
> Maybe another option could be to add a REGULATOR_MODE_INVALID with
> value 0x0, and fix the drivers that are returning -EINVAL to return
> that instead?
>
> In of_get_regulation_constraints() we could check for that and
> propagate -EINVAL.

I like this idea.  Posted at
.  Note that there's no
actual error to propagate since of_get_regulation_constraints() just
prints the error and continues on its merry way.

-Doug

Re: [PATCH] regulator: Fix return type of of_map_mode()

[Doug Anderson]

Hi,

On Tue, Apr 17, 2018 at 10:48 AM, Javier Martinez Canillas
 wrote:
>>> Let's fix the return type of all of the current of_map_mode()
>>> functions.  While we're at it, we'll remove one pointless "inline".
>>
>> Ah, I see...  the thing here is that the mode is always an unsigned int
>> since it's a bitmask - this goes out beying the use in of_map_mode() and
>> into all the other APIs.  We only actually use 4 bits currently so I
>> think there's no problem switching to int but it seems we should
>> probably do that consistently throughout the API so that things don't
>> get missed later on.
>
> Maybe another option could be to add a REGULATOR_MODE_INVALID with
> value 0x0, and fix the drivers that are returning -EINVAL to return
> that instead?
>
> In of_get_regulation_constraints() we could check for that and
> propagate -EINVAL.

I like this idea.  Posted at
.  Note that there's no
actual error to propagate since of_get_regulation_constraints() just
prints the error and continues on its merry way.

-Doug

linux-next: build failure after merge of the arm-current tree

[Stephen Rothwell]

Hi Russell,

After merging the arm-current tree, today's linux-next build
(lots of configs) failed like this:

/bin/sh: 1: arithmetic expression: expecting primary: " "
(lots of these)

Caused by commit

  fe680ca02c1e ("ARM: replace unnecessary perl with sed and the shell $(( )) 
operator")

(pointed out by Michael Ellerman)

Our /bin/sh is dash not bash ...

-- 
Cheers,
Stephen Rothwell


pgpUk4rkqtoMu.pgp
Description: OpenPGP digital signature

linux-next: build failure after merge of the arm-current tree

[Stephen Rothwell]

Hi Russell,

After merging the arm-current tree, today's linux-next build
(lots of configs) failed like this:

/bin/sh: 1: arithmetic expression: expecting primary: " "
(lots of these)

Caused by commit

  fe680ca02c1e ("ARM: replace unnecessary perl with sed and the shell $(( )) 
operator")

(pointed out by Michael Ellerman)

Our /bin/sh is dash not bash ...

-- 
Cheers,
Stephen Rothwell


pgpUk4rkqtoMu.pgp
Description: OpenPGP digital signature

[PATCH v2] regulator: Don't return or expect -errno from of_map_mode()

[Douglas Anderson]

In of_get_regulation_constraints() we were taking the result of
of_map_mode() (an unsigned int) and assigning it to an int.  We were
then checking whether this value was -EINVAL.  Some implementers of
of_map_mode() were returning -EINVAL (even though the return type of
their function needed to be unsigned int) because they needed to to
signal an error back to of_get_regulation_constraints().

In general in the regulator framework the mode is always referred to
as an unsigned int.  While we could fix this to be a signed int (the
highest value we store in there right now is 0x8), it's actually
pretty clean to just define the regulator mode 0x0 (the lack of any
bits set) as an invalid mode.  Let's do that.

Suggested-by: Javier Martinez Canillas 
Fixes: 5e5e3a42c653 ("regulator: of: Add support for parsing initial and 
suspend modes")
Signed-off-by: Douglas Anderson 
---

Changes in v2:
- Use Javier's suggestion of defining 0x0 as invalid

 drivers/regulator/cpcap-regulator.c |  2 +-
 drivers/regulator/of_regulator.c| 15 +--
 drivers/regulator/twl-regulator.c   |  2 +-
 include/linux/regulator/consumer.h  |  1 +
 4 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/cpcap-regulator.c 
b/drivers/regulator/cpcap-regulator.c
index f541b80f1b54..bd910fe123d9 100644
--- a/drivers/regulator/cpcap-regulator.c
+++ b/drivers/regulator/cpcap-regulator.c
@@ -222,7 +222,7 @@ static unsigned int cpcap_map_mode(unsigned int mode)
case CPCAP_BIT_AUDIO_LOW_PWR:
return REGULATOR_MODE_STANDBY;
default:
-   return -EINVAL;
+   return REGULATOR_MODE_INVALID;
}
 }
 
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index f47264fa1940..22c02b7a338b 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -124,11 +124,12 @@ static void of_get_regulation_constraints(struct 
device_node *np,
 
if (!of_property_read_u32(np, "regulator-initial-mode", )) {
if (desc && desc->of_map_mode) {
-   ret = desc->of_map_mode(pval);
-   if (ret == -EINVAL)
+   unsigned int mode = desc->of_map_mode(pval);
+
+   if (mode == REGULATOR_MODE_INVALID)
pr_err("%s: invalid mode %u\n", np->name, pval);
else
-   constraints->initial_mode = ret;
+   constraints->initial_mode = mode;
} else {
pr_warn("%s: mapping for mode %d not defined\n",
np->name, pval);
@@ -163,12 +164,14 @@ static void of_get_regulation_constraints(struct 
device_node *np,
if (!of_property_read_u32(suspend_np, "regulator-mode",
  )) {
if (desc && desc->of_map_mode) {
-   ret = desc->of_map_mode(pval);
-   if (ret == -EINVAL)
+   unsigned int mode = desc->of_map_mode(pval);
+
+   mode = desc->of_map_mode(pval);
+   if (mode == REGULATOR_MODE_INVALID)
pr_err("%s: invalid mode %u\n",
   np->name, pval);
else
-   suspend_state->mode = ret;
+   suspend_state->mode = mode;
} else {
pr_warn("%s: mapping for mode %d not defined\n",
np->name, pval);
diff --git a/drivers/regulator/twl-regulator.c 
b/drivers/regulator/twl-regulator.c
index a4456db5849d..884c7505ed91 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -274,7 +274,7 @@ static inline unsigned int twl4030reg_map_mode(unsigned int 
mode)
case RES_STATE_SLEEP:
return REGULATOR_MODE_STANDBY;
default:
-   return -EINVAL;
+   return REGULATOR_MODE_INVALID;
}
 }
 
diff --git a/include/linux/regulator/consumer.h 
b/include/linux/regulator/consumer.h
index df176d7c2b87..25602afd4844 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -80,6 +80,7 @@ struct regmap;
  * These modes can be OR'ed together to make up a mask of valid register modes.
  */
 
+#define REGULATOR_MODE_INVALID 0x0
 #define REGULATOR_MODE_FAST0x1
 #define REGULATOR_MODE_NORMAL  0x2
 #define REGULATOR_MODE_IDLE0x4
-- 
2.17.0.484.g0c8726318c-goog

[PATCH v2] regulator: Don't return or expect -errno from of_map_mode()

[Douglas Anderson]

In of_get_regulation_constraints() we were taking the result of
of_map_mode() (an unsigned int) and assigning it to an int.  We were
then checking whether this value was -EINVAL.  Some implementers of
of_map_mode() were returning -EINVAL (even though the return type of
their function needed to be unsigned int) because they needed to to
signal an error back to of_get_regulation_constraints().

In general in the regulator framework the mode is always referred to
as an unsigned int.  While we could fix this to be a signed int (the
highest value we store in there right now is 0x8), it's actually
pretty clean to just define the regulator mode 0x0 (the lack of any
bits set) as an invalid mode.  Let's do that.

Suggested-by: Javier Martinez Canillas 
Fixes: 5e5e3a42c653 ("regulator: of: Add support for parsing initial and 
suspend modes")
Signed-off-by: Douglas Anderson 
---

Changes in v2:
- Use Javier's suggestion of defining 0x0 as invalid

 drivers/regulator/cpcap-regulator.c |  2 +-
 drivers/regulator/of_regulator.c| 15 +--
 drivers/regulator/twl-regulator.c   |  2 +-
 include/linux/regulator/consumer.h  |  1 +
 4 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/cpcap-regulator.c 
b/drivers/regulator/cpcap-regulator.c
index f541b80f1b54..bd910fe123d9 100644
--- a/drivers/regulator/cpcap-regulator.c
+++ b/drivers/regulator/cpcap-regulator.c
@@ -222,7 +222,7 @@ static unsigned int cpcap_map_mode(unsigned int mode)
case CPCAP_BIT_AUDIO_LOW_PWR:
return REGULATOR_MODE_STANDBY;
default:
-   return -EINVAL;
+   return REGULATOR_MODE_INVALID;
}
 }
 
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index f47264fa1940..22c02b7a338b 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -124,11 +124,12 @@ static void of_get_regulation_constraints(struct 
device_node *np,
 
if (!of_property_read_u32(np, "regulator-initial-mode", )) {
if (desc && desc->of_map_mode) {
-   ret = desc->of_map_mode(pval);
-   if (ret == -EINVAL)
+   unsigned int mode = desc->of_map_mode(pval);
+
+   if (mode == REGULATOR_MODE_INVALID)
pr_err("%s: invalid mode %u\n", np->name, pval);
else
-   constraints->initial_mode = ret;
+   constraints->initial_mode = mode;
} else {
pr_warn("%s: mapping for mode %d not defined\n",
np->name, pval);
@@ -163,12 +164,14 @@ static void of_get_regulation_constraints(struct 
device_node *np,
if (!of_property_read_u32(suspend_np, "regulator-mode",
  )) {
if (desc && desc->of_map_mode) {
-   ret = desc->of_map_mode(pval);
-   if (ret == -EINVAL)
+   unsigned int mode = desc->of_map_mode(pval);
+
+   mode = desc->of_map_mode(pval);
+   if (mode == REGULATOR_MODE_INVALID)
pr_err("%s: invalid mode %u\n",
   np->name, pval);
else
-   suspend_state->mode = ret;
+   suspend_state->mode = mode;
} else {
pr_warn("%s: mapping for mode %d not defined\n",
np->name, pval);
diff --git a/drivers/regulator/twl-regulator.c 
b/drivers/regulator/twl-regulator.c
index a4456db5849d..884c7505ed91 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -274,7 +274,7 @@ static inline unsigned int twl4030reg_map_mode(unsigned int 
mode)
case RES_STATE_SLEEP:
return REGULATOR_MODE_STANDBY;
default:
-   return -EINVAL;
+   return REGULATOR_MODE_INVALID;
}
 }
 
diff --git a/include/linux/regulator/consumer.h 
b/include/linux/regulator/consumer.h
index df176d7c2b87..25602afd4844 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -80,6 +80,7 @@ struct regmap;
  * These modes can be OR'ed together to make up a mask of valid register modes.
  */
 
+#define REGULATOR_MODE_INVALID 0x0
 #define REGULATOR_MODE_FAST0x1
 #define REGULATOR_MODE_NORMAL  0x2
 #define REGULATOR_MODE_IDLE0x4
-- 
2.17.0.484.g0c8726318c-goog

[PATCH] prctl: fix compat handling for prctl

[Li Bin]

The member auxv in prctl_mm_map structure which be shared with
userspace is pointer type, but the kernel supporting COMPAT didn't
handle it. This patch fix the compat handling for prctl syscall.

Signed-off-by: Li Bin 
---
 kernel/sys.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/kernel/sys.c b/kernel/sys.c
index ad69218..03b9731 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1968,6 +1968,25 @@ static int validate_prctl_map(struct prctl_mm_map 
*prctl_map)
return error;
 }
 
+#ifdef CONFIG_COMPAT
+struct compat_prctl_mm_map {
+   __u64   start_code; /* code section bounds */
+   __u64   end_code;
+   __u64   start_data; /* data section bounds */
+   __u64   end_data;
+   __u64   start_brk;  /* heap for brk() syscall */
+   __u64   brk;
+   __u64   start_stack;/* stack starts at */
+   __u64   arg_start;  /* command line arguments bounds */
+   __u64   arg_end;
+   __u64   env_start;  /* environment variables bounds */
+   __u64   env_end;
+   compat_uptr_t   auxv;   /* auxiliary vector */
+   __u32   auxv_size;  /* vector size */
+   __u32   exe_fd; /* /proc/$pid/exe link file */
+};
+#endif
+
 #ifdef CONFIG_CHECKPOINT_RESTORE
 static int prctl_set_mm_map(int opt, const void __user *addr, unsigned long 
data_size)
 {
@@ -1986,6 +2005,28 @@ static int prctl_set_mm_map(int opt, const void __user 
*addr, unsigned long data
if (data_size != sizeof(prctl_map))
return -EINVAL;
 
+#ifdef CONFIG_COMPAT
+   if (is_compat_task()) {
+   struct compat_prctl_mm_map prctl_map32;
+   if (copy_from_user(_map32, addr, sizeof(prctl_map32)))
+   return -EFAULT;
+
+   prctl_map.start_code = prctl_map32.start_code;
+   prctl_map.end_code = prctl_map32.end_code;
+   prctl_map.start_data = prctl_map32.start_data;
+   prctl_map.end_data = prctl_map32.end_data;
+   prctl_map.start_brk = prctl_map32.start_brk;
+   prctl_map.brk = prctl_map32.brk;
+   prctl_map.start_stack = prctl_map32.start_stack;
+   prctl_map.arg_start = prctl_map32.arg_start;
+   prctl_map.arg_end = prctl_map32.arg_end;
+   prctl_map.env_start = prctl_map32.env_start;
+   prctl_map.env_end = prctl_map32.env_end;
+   prctl_map.auxv = compat_ptr(prctl_map32.auxv);
+   prctl_map.auxv_size = prctl_map32.auxv_size;
+   prctl_map.exe_fd = prctl_map32.exe_fd;
+   } else
+#endif
if (copy_from_user(_map, addr, sizeof(prctl_map)))
return -EFAULT;
 
-- 
1.7.12.4

[PATCH] prctl: fix compat handling for prctl

[Li Bin]

The member auxv in prctl_mm_map structure which be shared with
userspace is pointer type, but the kernel supporting COMPAT didn't
handle it. This patch fix the compat handling for prctl syscall.

Signed-off-by: Li Bin 
---
 kernel/sys.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/kernel/sys.c b/kernel/sys.c
index ad69218..03b9731 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1968,6 +1968,25 @@ static int validate_prctl_map(struct prctl_mm_map 
*prctl_map)
return error;
 }
 
+#ifdef CONFIG_COMPAT
+struct compat_prctl_mm_map {
+   __u64   start_code; /* code section bounds */
+   __u64   end_code;
+   __u64   start_data; /* data section bounds */
+   __u64   end_data;
+   __u64   start_brk;  /* heap for brk() syscall */
+   __u64   brk;
+   __u64   start_stack;/* stack starts at */
+   __u64   arg_start;  /* command line arguments bounds */
+   __u64   arg_end;
+   __u64   env_start;  /* environment variables bounds */
+   __u64   env_end;
+   compat_uptr_t   auxv;   /* auxiliary vector */
+   __u32   auxv_size;  /* vector size */
+   __u32   exe_fd; /* /proc/$pid/exe link file */
+};
+#endif
+
 #ifdef CONFIG_CHECKPOINT_RESTORE
 static int prctl_set_mm_map(int opt, const void __user *addr, unsigned long 
data_size)
 {
@@ -1986,6 +2005,28 @@ static int prctl_set_mm_map(int opt, const void __user 
*addr, unsigned long data
if (data_size != sizeof(prctl_map))
return -EINVAL;
 
+#ifdef CONFIG_COMPAT
+   if (is_compat_task()) {
+   struct compat_prctl_mm_map prctl_map32;
+   if (copy_from_user(_map32, addr, sizeof(prctl_map32)))
+   return -EFAULT;
+
+   prctl_map.start_code = prctl_map32.start_code;
+   prctl_map.end_code = prctl_map32.end_code;
+   prctl_map.start_data = prctl_map32.start_data;
+   prctl_map.end_data = prctl_map32.end_data;
+   prctl_map.start_brk = prctl_map32.start_brk;
+   prctl_map.brk = prctl_map32.brk;
+   prctl_map.start_stack = prctl_map32.start_stack;
+   prctl_map.arg_start = prctl_map32.arg_start;
+   prctl_map.arg_end = prctl_map32.arg_end;
+   prctl_map.env_start = prctl_map32.env_start;
+   prctl_map.env_end = prctl_map32.env_end;
+   prctl_map.auxv = compat_ptr(prctl_map32.auxv);
+   prctl_map.auxv_size = prctl_map32.auxv_size;
+   prctl_map.exe_fd = prctl_map32.exe_fd;
+   } else
+#endif
if (copy_from_user(_map, addr, sizeof(prctl_map)))
return -EFAULT;
 
-- 
1.7.12.4

Re: [PATCH] KVM: X86: Allow userspace to define the microcode version

[Wanpeng Li]

2018-04-18 4:24 GMT+08:00 Eduardo Habkost :
> On Tue, Apr 17, 2018 at 06:40:58PM +0800, Wanpeng Li wrote:
>> Cc Eduardo,
>> 2018-02-26 20:41 GMT+08:00 Paolo Bonzini :
>> > On 26/02/2018 13:22, Borislav Petkov wrote:
>> >> On Mon, Feb 26, 2018 at 01:18:07PM +0100, Paolo Bonzini wrote:
>>  In this context, "host-initiated" write means written by KVM userspace
>>  with ioctl(KVM_SET_MSR).  It generally happens only on VM startup, reset
>>  or live migration.
>> >>>
>> >>> To be clear, the target of the write is still the vCPU's emulated MSR.
>> >>
>> >> So how am I to imagine this as a user:
>> >>
>> >> qemu-system-x86_64 --microcode-revision=0xdeadbeef...
>> >
>> > More like "-cpu foo,ucode_rev=0xdeadbeef".  But in practice what would
>> > happen is one of the following:
>> >
>> > 1) "-cpu host" sets ucode_rev to the same value of the host, everyone
>> > else leaves it to zero as is now.
>>
>> Hi Paolo,
>>
>> Do you mean the host admin to get the ucode_rev from the host and set
>> to -cpu host, ucode_rev=xx or qemu get the ucode_rev directly by
>> rdmsr?
>
> QEMU setting ucode_rev automatically using the host value when
> using "-cpu host" (with no need for explicit ucode_rev option)
> makes sense to me.

QEMU can't get the host value by rdmsr MSR_IA32_UCODE_REV directly
since rdmsr will #GP when ring !=0, any idea?

Regards,
Wanpeng Li

Re: [PATCH] KVM: X86: Allow userspace to define the microcode version

[Wanpeng Li]

2018-04-18 4:24 GMT+08:00 Eduardo Habkost :
> On Tue, Apr 17, 2018 at 06:40:58PM +0800, Wanpeng Li wrote:
>> Cc Eduardo,
>> 2018-02-26 20:41 GMT+08:00 Paolo Bonzini :
>> > On 26/02/2018 13:22, Borislav Petkov wrote:
>> >> On Mon, Feb 26, 2018 at 01:18:07PM +0100, Paolo Bonzini wrote:
>>  In this context, "host-initiated" write means written by KVM userspace
>>  with ioctl(KVM_SET_MSR).  It generally happens only on VM startup, reset
>>  or live migration.
>> >>>
>> >>> To be clear, the target of the write is still the vCPU's emulated MSR.
>> >>
>> >> So how am I to imagine this as a user:
>> >>
>> >> qemu-system-x86_64 --microcode-revision=0xdeadbeef...
>> >
>> > More like "-cpu foo,ucode_rev=0xdeadbeef".  But in practice what would
>> > happen is one of the following:
>> >
>> > 1) "-cpu host" sets ucode_rev to the same value of the host, everyone
>> > else leaves it to zero as is now.
>>
>> Hi Paolo,
>>
>> Do you mean the host admin to get the ucode_rev from the host and set
>> to -cpu host, ucode_rev=xx or qemu get the ucode_rev directly by
>> rdmsr?
>
> QEMU setting ucode_rev automatically using the host value when
> using "-cpu host" (with no need for explicit ucode_rev option)
> makes sense to me.

QEMU can't get the host value by rdmsr MSR_IA32_UCODE_REV directly
since rdmsr will #GP when ring !=0, any idea?

Regards,
Wanpeng Li

Re: [PATCH 0/4] ARM: imx: use device properties for at24 eeprom

[Shawn Guo]

On Wed, Apr 04, 2018 at 03:16:23PM +0200, Bartosz Golaszewski wrote:
> We want to work towards phasing out the at24_platform_data structure.
> There are few users and its contents can be represented using generic
> device properties. Using device properties only will allow us to
> significantly simplify the at24 configuration code.
> 
> This series converts all users of at24_platform_data to using generic
> device properties or - as is the case with PATCH 1/4 - drops the
> platform data entirely since it's not needed.
> 
> Bartosz Golaszewski (4):
>   ARM: imx: vpr200: drop at24_platform_data
>   ARM: imx: pcm043: use device properties for at24 eeprom
>   ARM: imx: pca100: use device properties for at24 eeprom
>   ARM: imx: pcm037: use device properties for at24 eeprom

Applied all, thanks.

Re: [PATCH 0/4] ARM: imx: use device properties for at24 eeprom

[Shawn Guo]

On Wed, Apr 04, 2018 at 03:16:23PM +0200, Bartosz Golaszewski wrote:
> We want to work towards phasing out the at24_platform_data structure.
> There are few users and its contents can be represented using generic
> device properties. Using device properties only will allow us to
> significantly simplify the at24 configuration code.
> 
> This series converts all users of at24_platform_data to using generic
> device properties or - as is the case with PATCH 1/4 - drops the
> platform data entirely since it's not needed.
> 
> Bartosz Golaszewski (4):
>   ARM: imx: vpr200: drop at24_platform_data
>   ARM: imx: pcm043: use device properties for at24 eeprom
>   ARM: imx: pca100: use device properties for at24 eeprom
>   ARM: imx: pcm037: use device properties for at24 eeprom

Applied all, thanks.

[PATCH 14/24] x86/speculation: Move firmware_restrict_branch_speculation_*() from C to CPP

[Youquan Song]

From: Ingo Molnar 

(cherry picked from commit d72f4e29e6d84b7ec02ae93088aa459ac70e733b)

firmware_restrict_branch_speculation_*() recently started using
preempt_enable()/disable(), but those are relatively high level
primitives and cause build failures on some 32-bit builds.

Since we want to keep  low level, convert
them to macros to avoid header hell...

Cc: David Woodhouse 
Cc: Thomas Gleixner 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: arjan.van.de@intel.com
Cc: b...@alien8.de
Cc: dave.han...@intel.com
Cc: jmatt...@google.com
Cc: karah...@amazon.de
Cc: k...@vger.kernel.org
Cc: pbonz...@redhat.com
Cc: rkrc...@redhat.com
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Youquan Song  [v4.4 backport]
---
 arch/x86/include/asm/nospec-branch.h | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/nospec-branch.h 
b/arch/x86/include/asm/nospec-branch.h
index 27582aa..4675f65 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -214,20 +214,22 @@ static inline void 
indirect_branch_prediction_barrier(void)
 /*
  * With retpoline, we must use IBRS to restrict branch prediction
  * before calling into firmware.
+ *
+ * (Implemented as CPP macros due to header hell.)
  */
-static inline void firmware_restrict_branch_speculation_start(void)
-{
-   preempt_disable();
-   alternative_msr_write(MSR_IA32_SPEC_CTRL, SPEC_CTRL_IBRS,
- X86_FEATURE_USE_IBRS_FW);
-}
+#define firmware_restrict_branch_speculation_start()   \
+do {   \
+   preempt_disable();  \
+   alternative_msr_write(MSR_IA32_SPEC_CTRL, SPEC_CTRL_IBRS,   \
+ X86_FEATURE_USE_IBRS_FW); \
+} while (0)
 
-static inline void firmware_restrict_branch_speculation_end(void)
-{
-   alternative_msr_write(MSR_IA32_SPEC_CTRL, 0,
- X86_FEATURE_USE_IBRS_FW);
-   preempt_enable();
-}
+#define firmware_restrict_branch_speculation_end() \
+do {   \
+   alternative_msr_write(MSR_IA32_SPEC_CTRL, 0,\
+ X86_FEATURE_USE_IBRS_FW); \
+   preempt_enable();   \
+} while (0)
 
 #endif /* __ASSEMBLY__ */
 
-- 
1.8.3.1

[PATCH 14/24] x86/speculation: Move firmware_restrict_branch_speculation_*() from C to CPP

[Youquan Song]

From: Ingo Molnar 

(cherry picked from commit d72f4e29e6d84b7ec02ae93088aa459ac70e733b)

firmware_restrict_branch_speculation_*() recently started using
preempt_enable()/disable(), but those are relatively high level
primitives and cause build failures on some 32-bit builds.

Since we want to keep  low level, convert
them to macros to avoid header hell...

Cc: David Woodhouse 
Cc: Thomas Gleixner 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: arjan.van.de@intel.com
Cc: b...@alien8.de
Cc: dave.han...@intel.com
Cc: jmatt...@google.com
Cc: karah...@amazon.de
Cc: k...@vger.kernel.org
Cc: pbonz...@redhat.com
Cc: rkrc...@redhat.com
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Youquan Song  [v4.4 backport]
---
 arch/x86/include/asm/nospec-branch.h | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/nospec-branch.h 
b/arch/x86/include/asm/nospec-branch.h
index 27582aa..4675f65 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -214,20 +214,22 @@ static inline void 
indirect_branch_prediction_barrier(void)
 /*
  * With retpoline, we must use IBRS to restrict branch prediction
  * before calling into firmware.
+ *
+ * (Implemented as CPP macros due to header hell.)
  */
-static inline void firmware_restrict_branch_speculation_start(void)
-{
-   preempt_disable();
-   alternative_msr_write(MSR_IA32_SPEC_CTRL, SPEC_CTRL_IBRS,
- X86_FEATURE_USE_IBRS_FW);
-}
+#define firmware_restrict_branch_speculation_start()   \
+do {   \
+   preempt_disable();  \
+   alternative_msr_write(MSR_IA32_SPEC_CTRL, SPEC_CTRL_IBRS,   \
+ X86_FEATURE_USE_IBRS_FW); \
+} while (0)
 
-static inline void firmware_restrict_branch_speculation_end(void)
-{
-   alternative_msr_write(MSR_IA32_SPEC_CTRL, 0,
- X86_FEATURE_USE_IBRS_FW);
-   preempt_enable();
-}
+#define firmware_restrict_branch_speculation_end() \
+do {   \
+   alternative_msr_write(MSR_IA32_SPEC_CTRL, 0,\
+ X86_FEATURE_USE_IBRS_FW); \
+   preempt_enable();   \
+} while (0)
 
 #endif /* __ASSEMBLY__ */
 
-- 
1.8.3.1

Re: [PATCH 00/20] staging: lustre: convert to rhashtable

[NeilBrown]

On Tue, Apr 17 2018, James Simmons wrote:

>> libcfs in lustre has a resizeable hashtable.
>> Linux already has a resizeable hashtable, rhashtable, which is better
>> is most metrics. See https://lwn.net/Articles/751374/ in a few days
>> for an introduction to rhashtable.
>
> Thansk for starting this work. I was think about cleaning the libcfs
> hash but your port to rhashtables is way better. How did you gather
> metrics to see that rhashtable was better than libcfs hash?

Code inspection and reputation.  It is hard to beat inlined lockless
code for lookups.  And rhashtable is heavily used in the network
subsystem and they are very focused on latency there.  I'm not sure that
insertion is as fast as it can be (I have some thoughts on that) but I'm
sure lookup will be better.
I haven't done any performance testing myself, only correctness.

>  
>> This series converts lustre to use rhashtable.  This affects several
>> different tables, and each is different is various ways.
>> 
>> There are two outstanding issues.  One is that a bug in rhashtable
>> means that we cannot enable auto-shrinking in one of the tables.  That
>> is documented as appropriate and should be fixed soon.
>> 
>> The other is that rhashtable has an atomic_t which counts the elements
>> in a hash table.  At least one table in lustre went to some trouble to
>> avoid any table-wide atomics, so that could lead to a regression.
>> I'm hoping that rhashtable can be enhanced with the option of a
>> per-cpu counter, or similar.
>> 
>
> This doesn't sound quite ready to land just yet. This will have to do some
> soak testing and a larger scope of test to make sure no new regressions
> happen. Believe me I did work to make lustre work better on tickless 
> systems, which I'm preparing for the linux client, and small changes could 
> break things in interesting ways. I will port the rhashtable change to the 
> Intel developement branch and get people more familar with the hash code
> to look at it.

Whether it is "ready" or not probably depends on perspective and
priorities.  As I see it, getting lustre cleaned up and out of staging
is a fairly high priority, and it will require a lot of code change.
It is inevitable that regressions will slip in (some already have) and
it is important to keep testing (the test suite is of great benefit, but
is only part of the story of course).  But to test the code, it needs to
land.  Testing the code in Intel's devel branch and then porting it
across doesn't really prove much.  For testing to be meaningful, it
needs to be tested in a branch that up-to-date with mainline and on
track to be merged into mainline.

I have no particular desire to rush this in, but I don't see any
particular benefit in delaying it either.

I guess I see staging as implicitly a 'devel' branch.  You seem to be
treating it a bit like a 'stable' branch - is that right?

As mentioned, I think there is room for improvement in rhashtable.
- making the atomic counter optional
- replacing the separate spinlocks with bit-locks in the hash-chain head
  so that the lock and chain are in the same cache line
- for the common case of inserting in an empty chain, a single atomic
  cmpxchg() should be sufficient
I think we have a better chance of being heard if we have "skin in the
game" and have upstream code that would use this.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

[Anshuman Khandual]

On 04/15/2018 05:41 PM, Christoph Hellwig wrote:
> On Fri, Apr 06, 2018 at 06:37:18PM +1000, Benjamin Herrenschmidt wrote:
 implemented as DMA API which the virtio core understands. There is no
 need for an IOMMU to be involved for the device representation in this
 case IMHO.
>>>
>>> This whole virtio translation issue is a mess.  I think we need to
>>> switch it to the dma API, and then quirk the legacy case to always
>>> use the direct mapping inside the dma API.
>>
>> Fine with using a dma API always on the Linux side, but we do want to
>> special case virtio still at the arch and qemu side to have a "direct
>> mapping" mode. Not sure how (special flags on PCI devices) to avoid
>> actually going through an emulated IOMMU on the qemu side, because that
>> slows things down, esp. with vhost.
>>
>> IE, we can't I think just treat it the same as a physical device.
> 
> We should have treated it like a physical device from the start, but
> that device has unfortunately sailed.
> 
> But yes, we'll need a per-device quirk that says 'don't attach an
> iommu'.

How about doing it per platform basis as suggested in this RFC through
an arch specific callback. Because all the virtio devices in the given
platform would require and exercise this option (to avail bounce buffer
mechanism for secure guests as an example). So the flag basically is a
platform specific one not a device specific one.

Re: [PATCH 00/20] staging: lustre: convert to rhashtable

[NeilBrown]

On Tue, Apr 17 2018, James Simmons wrote:

>> libcfs in lustre has a resizeable hashtable.
>> Linux already has a resizeable hashtable, rhashtable, which is better
>> is most metrics. See https://lwn.net/Articles/751374/ in a few days
>> for an introduction to rhashtable.
>
> Thansk for starting this work. I was think about cleaning the libcfs
> hash but your port to rhashtables is way better. How did you gather
> metrics to see that rhashtable was better than libcfs hash?

Code inspection and reputation.  It is hard to beat inlined lockless
code for lookups.  And rhashtable is heavily used in the network
subsystem and they are very focused on latency there.  I'm not sure that
insertion is as fast as it can be (I have some thoughts on that) but I'm
sure lookup will be better.
I haven't done any performance testing myself, only correctness.

>  
>> This series converts lustre to use rhashtable.  This affects several
>> different tables, and each is different is various ways.
>> 
>> There are two outstanding issues.  One is that a bug in rhashtable
>> means that we cannot enable auto-shrinking in one of the tables.  That
>> is documented as appropriate and should be fixed soon.
>> 
>> The other is that rhashtable has an atomic_t which counts the elements
>> in a hash table.  At least one table in lustre went to some trouble to
>> avoid any table-wide atomics, so that could lead to a regression.
>> I'm hoping that rhashtable can be enhanced with the option of a
>> per-cpu counter, or similar.
>> 
>
> This doesn't sound quite ready to land just yet. This will have to do some
> soak testing and a larger scope of test to make sure no new regressions
> happen. Believe me I did work to make lustre work better on tickless 
> systems, which I'm preparing for the linux client, and small changes could 
> break things in interesting ways. I will port the rhashtable change to the 
> Intel developement branch and get people more familar with the hash code
> to look at it.

Whether it is "ready" or not probably depends on perspective and
priorities.  As I see it, getting lustre cleaned up and out of staging
is a fairly high priority, and it will require a lot of code change.
It is inevitable that regressions will slip in (some already have) and
it is important to keep testing (the test suite is of great benefit, but
is only part of the story of course).  But to test the code, it needs to
land.  Testing the code in Intel's devel branch and then porting it
across doesn't really prove much.  For testing to be meaningful, it
needs to be tested in a branch that up-to-date with mainline and on
track to be merged into mainline.

I have no particular desire to rush this in, but I don't see any
particular benefit in delaying it either.

I guess I see staging as implicitly a 'devel' branch.  You seem to be
treating it a bit like a 'stable' branch - is that right?

As mentioned, I think there is room for improvement in rhashtable.
- making the atomic counter optional
- replacing the separate spinlocks with bit-locks in the hash-chain head
  so that the lock and chain are in the same cache line
- for the common case of inserting in an empty chain, a single atomic
  cmpxchg() should be sufficient
I think we have a better chance of being heard if we have "skin in the
game" and have upstream code that would use this.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

[Anshuman Khandual]

On 04/15/2018 05:41 PM, Christoph Hellwig wrote:
> On Fri, Apr 06, 2018 at 06:37:18PM +1000, Benjamin Herrenschmidt wrote:
 implemented as DMA API which the virtio core understands. There is no
 need for an IOMMU to be involved for the device representation in this
 case IMHO.
>>>
>>> This whole virtio translation issue is a mess.  I think we need to
>>> switch it to the dma API, and then quirk the legacy case to always
>>> use the direct mapping inside the dma API.
>>
>> Fine with using a dma API always on the Linux side, but we do want to
>> special case virtio still at the arch and qemu side to have a "direct
>> mapping" mode. Not sure how (special flags on PCI devices) to avoid
>> actually going through an emulated IOMMU on the qemu side, because that
>> slows things down, esp. with vhost.
>>
>> IE, we can't I think just treat it the same as a physical device.
> 
> We should have treated it like a physical device from the start, but
> that device has unfortunately sailed.
> 
> But yes, we'll need a per-device quirk that says 'don't attach an
> iommu'.

How about doing it per platform basis as suggested in this RFC through
an arch specific callback. Because all the virtio devices in the given
platform would require and exercise this option (to avail bounce buffer
mechanism for secure guests as an example). So the flag basically is a
platform specific one not a device specific one.

Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create

[Matthew Wilcox]

On Wed, Apr 18, 2018 at 11:29:12AM +0900, Minchan Kim wrote:
> If there are heavy memory pressure, page allocation with __GFP_NOWAIT
> fails easily although it's order-0 request.
> I got below warning 9 times for normal boot.
> 
> [   17.072747] c0 0  : page allocation failure: order:0, 
> mode:0x220(GFP_NOWAIT|__GFP_NOTRACK)
> 
> Let's not make user scared.
>  
> - cw = kmalloc(sizeof(*cw), GFP_NOWAIT);
> + cw = kmalloc(sizeof(*cw), GFP_NOWAIT | __GFP_NOWARN);
>   if (!cw)

Not arguing against this patch.  But how many places do we want to use
GFP_NOWAIT without __GFP_NOWARN?  Not many, and the few which do do this
seem like they simply haven't added it yet.  Maybe this would be a good idea?

-#define GFP_NOWAIT  (__GFP_KSWAPD_RECLAIM)
+#define GFP_NOWAIT  (__GFP_KSWAPD_RECLAIM | __GFP_NOWARN)

Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create

[Matthew Wilcox]

On Wed, Apr 18, 2018 at 11:29:12AM +0900, Minchan Kim wrote:
> If there are heavy memory pressure, page allocation with __GFP_NOWAIT
> fails easily although it's order-0 request.
> I got below warning 9 times for normal boot.
> 
> [   17.072747] c0 0  : page allocation failure: order:0, 
> mode:0x220(GFP_NOWAIT|__GFP_NOTRACK)
> 
> Let's not make user scared.
>  
> - cw = kmalloc(sizeof(*cw), GFP_NOWAIT);
> + cw = kmalloc(sizeof(*cw), GFP_NOWAIT | __GFP_NOWARN);
>   if (!cw)

Not arguing against this patch.  But how many places do we want to use
GFP_NOWAIT without __GFP_NOWARN?  Not many, and the few which do do this
seem like they simply haven't added it yet.  Maybe this would be a good idea?

-#define GFP_NOWAIT  (__GFP_KSWAPD_RECLAIM)
+#define GFP_NOWAIT  (__GFP_KSWAPD_RECLAIM | __GFP_NOWARN)

Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create

[David Rientjes]

On Wed, 18 Apr 2018, Minchan Kim wrote:

> If there are heavy memory pressure, page allocation with __GFP_NOWAIT
> fails easily although it's order-0 request.
> I got below warning 9 times for normal boot.
> 
> [   17.072747] c0 0  : page allocation failure: order:0, 
> mode:0x220(GFP_NOWAIT|__GFP_NOTRACK)
> < snip >
> [   17.072789] c0 0  Call trace:
> [   17.072803] c0 0  [] dump_backtrace+0x0/0x4
> [   17.072813] c0 0  [] dump_stack+0xa4/0xc0
> [   17.072822] c0 0  [] warn_alloc+0xd4/0x15c
> [   17.072829] c0 0  [] 
> __alloc_pages_nodemask+0xf88/0x10fc
> [   17.072838] c0 0  [] alloc_slab_page+0x40/0x18c
> [   17.072843] c0 0  [] new_slab+0x2b8/0x2e0
> [   17.072849] c0 0  [] ___slab_alloc+0x25c/0x464
> [   17.072858] c0 0  [] __kmalloc+0x394/0x498
> [   17.072865] c0 0  [] memcg_kmem_get_cache+0x114/0x2b8
> [   17.072870] c0 0  [] kmem_cache_alloc+0x98/0x3e8
> [   17.072878] c0 0  [] mmap_region+0x3bc/0x8c0
> [   17.072884] c0 0  [] do_mmap+0x40c/0x43c
> [   17.072890] c0 0  [] vm_mmap_pgoff+0x15c/0x1e4
> [   17.072898] c0 0  [] sys_mmap+0xb0/0xc8
> [   17.072904] c0 0  [] el0_svc_naked+0x24/0x28
> [   17.072908] c0 0  Mem-Info:
> [   17.072920] c0 0  active_anon:17124 inactive_anon:193 isolated_anon:0
> [   17.072920] c0 0   active_file:7898 inactive_file:712955 
> isolated_file:55
> [   17.072920] c0 0   unevictable:0 dirty:27 writeback:18 unstable:0
> [   17.072920] c0 0   slab_reclaimable:12250 slab_unreclaimable:23334
> [   17.072920] c0 0   mapped:19310 shmem:212 pagetables:816 bounce:0
> [   17.072920] c0 0   free:36561 free_pcp:1205 free_cma:35615
> [   17.072933] c0 0  Node 0 active_anon:68496kB inactive_anon:772kB 
> active_file:31592kB inactive_file:2851820kB unevictable:0kB 
> isolated(anon):0kB isolated(file):220kB mapped:77240kB dirty:108kB 
> writeback:72kB shmem:848kB writeback_tmp:0kB unstable:0kB all_unreclaimable? 
> no
> [   17.072945] c0 0  DMA free:142188kB min:3056kB low:3820kB high:4584kB 
> active_anon:10052kB inactive_anon:12kB active_file:312kB 
> inactive_file:1412620kB unevictable:0kB writepending:0kB present:1781412kB 
> managed:1604728kB mlocked:0kB slab_reclaimable:3592kB 
> slab_unreclaimable:876kB kernel_stack:400kB pagetables:52kB bounce:0kB 
> free_pcp:1436kB local_pcp:124kB free_cma:142492kB
> [   17.072949] c0 0  lowmem_reserve[]: 0 1842 1842
> [   17.072966] c0 0  Normal free:4056kB min:4172kB low:5212kB high:6252kB 
> active_anon:58376kB inactive_anon:760kB active_file:31348kB 
> inactive_file:1439040kB unevictable:0kB writepending:180kB present:2000636kB 
> managed:1923688kB mlocked:0kB slab_reclaimable:45408kB 
> slab_unreclaimable:92460kB kernel_stack:9680kB pagetables:3212kB bounce:0kB 
> free_pcp:3392kB local_pcp:688kB free_cma:0kB
> [   17.072971] c0 0  lowmem_reserve[]: 0 0 0
> [   17.072982] c0 0  DMA: 0*4kB 0*8kB 1*16kB (C) 0*32kB 0*64kB 0*128kB 
> 1*256kB (C) 1*512kB (C) 0*1024kB 1*2048kB (C) 34*4096kB (C) = 142096kB
> [   17.073024] c0 0  Normal: 228*4kB (UMEH) 172*8kB (UMH) 23*16kB (UH) 
> 24*32kB (H) 5*64kB (H) 1*128kB (H) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 
> = 3872kB
> [   17.073069] c0 0  721350 total pagecache pages
> [   17.073073] c0 0  0 pages in swap cache
> [   17.073078] c0 0  Swap cache stats: add 0, delete 0, find 0/0
> [   17.073081] c0 0  Free swap  = 0kB
> [   17.073085] c0 0  Total swap = 0kB
> [   17.073089] c0 0  945512 pages RAM
> [   17.073093] c0 0  0 pages HighMem/MovableOnly
> [   17.073097] c0 0  63408 pages reserved
> [   17.073100] c0 0  51200 pages cma reserved
> 
> Let's not make user scared.
> 
> Cc: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: Vladimir Davydov 
> Signed-off-by: Minchan Kim 

Acked-by: David Rientjes 

Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create

[David Rientjes]

On Wed, 18 Apr 2018, Minchan Kim wrote:

> If there are heavy memory pressure, page allocation with __GFP_NOWAIT
> fails easily although it's order-0 request.
> I got below warning 9 times for normal boot.
> 
> [   17.072747] c0 0  : page allocation failure: order:0, 
> mode:0x220(GFP_NOWAIT|__GFP_NOTRACK)
> < snip >
> [   17.072789] c0 0  Call trace:
> [   17.072803] c0 0  [] dump_backtrace+0x0/0x4
> [   17.072813] c0 0  [] dump_stack+0xa4/0xc0
> [   17.072822] c0 0  [] warn_alloc+0xd4/0x15c
> [   17.072829] c0 0  [] 
> __alloc_pages_nodemask+0xf88/0x10fc
> [   17.072838] c0 0  [] alloc_slab_page+0x40/0x18c
> [   17.072843] c0 0  [] new_slab+0x2b8/0x2e0
> [   17.072849] c0 0  [] ___slab_alloc+0x25c/0x464
> [   17.072858] c0 0  [] __kmalloc+0x394/0x498
> [   17.072865] c0 0  [] memcg_kmem_get_cache+0x114/0x2b8
> [   17.072870] c0 0  [] kmem_cache_alloc+0x98/0x3e8
> [   17.072878] c0 0  [] mmap_region+0x3bc/0x8c0
> [   17.072884] c0 0  [] do_mmap+0x40c/0x43c
> [   17.072890] c0 0  [] vm_mmap_pgoff+0x15c/0x1e4
> [   17.072898] c0 0  [] sys_mmap+0xb0/0xc8
> [   17.072904] c0 0  [] el0_svc_naked+0x24/0x28
> [   17.072908] c0 0  Mem-Info:
> [   17.072920] c0 0  active_anon:17124 inactive_anon:193 isolated_anon:0
> [   17.072920] c0 0   active_file:7898 inactive_file:712955 
> isolated_file:55
> [   17.072920] c0 0   unevictable:0 dirty:27 writeback:18 unstable:0
> [   17.072920] c0 0   slab_reclaimable:12250 slab_unreclaimable:23334
> [   17.072920] c0 0   mapped:19310 shmem:212 pagetables:816 bounce:0
> [   17.072920] c0 0   free:36561 free_pcp:1205 free_cma:35615
> [   17.072933] c0 0  Node 0 active_anon:68496kB inactive_anon:772kB 
> active_file:31592kB inactive_file:2851820kB unevictable:0kB 
> isolated(anon):0kB isolated(file):220kB mapped:77240kB dirty:108kB 
> writeback:72kB shmem:848kB writeback_tmp:0kB unstable:0kB all_unreclaimable? 
> no
> [   17.072945] c0 0  DMA free:142188kB min:3056kB low:3820kB high:4584kB 
> active_anon:10052kB inactive_anon:12kB active_file:312kB 
> inactive_file:1412620kB unevictable:0kB writepending:0kB present:1781412kB 
> managed:1604728kB mlocked:0kB slab_reclaimable:3592kB 
> slab_unreclaimable:876kB kernel_stack:400kB pagetables:52kB bounce:0kB 
> free_pcp:1436kB local_pcp:124kB free_cma:142492kB
> [   17.072949] c0 0  lowmem_reserve[]: 0 1842 1842
> [   17.072966] c0 0  Normal free:4056kB min:4172kB low:5212kB high:6252kB 
> active_anon:58376kB inactive_anon:760kB active_file:31348kB 
> inactive_file:1439040kB unevictable:0kB writepending:180kB present:2000636kB 
> managed:1923688kB mlocked:0kB slab_reclaimable:45408kB 
> slab_unreclaimable:92460kB kernel_stack:9680kB pagetables:3212kB bounce:0kB 
> free_pcp:3392kB local_pcp:688kB free_cma:0kB
> [   17.072971] c0 0  lowmem_reserve[]: 0 0 0
> [   17.072982] c0 0  DMA: 0*4kB 0*8kB 1*16kB (C) 0*32kB 0*64kB 0*128kB 
> 1*256kB (C) 1*512kB (C) 0*1024kB 1*2048kB (C) 34*4096kB (C) = 142096kB
> [   17.073024] c0 0  Normal: 228*4kB (UMEH) 172*8kB (UMH) 23*16kB (UH) 
> 24*32kB (H) 5*64kB (H) 1*128kB (H) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 
> = 3872kB
> [   17.073069] c0 0  721350 total pagecache pages
> [   17.073073] c0 0  0 pages in swap cache
> [   17.073078] c0 0  Swap cache stats: add 0, delete 0, find 0/0
> [   17.073081] c0 0  Free swap  = 0kB
> [   17.073085] c0 0  Total swap = 0kB
> [   17.073089] c0 0  945512 pages RAM
> [   17.073093] c0 0  0 pages HighMem/MovableOnly
> [   17.073097] c0 0  63408 pages reserved
> [   17.073100] c0 0  51200 pages cma reserved
> 
> Let's not make user scared.
> 
> Cc: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: Vladimir Davydov 
> Signed-off-by: Minchan Kim 

Acked-by: David Rientjes 

Re: [PATCH v4] ARM: dts: imx6q-icore-ofcap12: Switch LVDS timings from panel-simple

[Shawn Guo]

On Mon, Mar 26, 2018 at 01:35:53PM +0530, Jagan Teki wrote:
> Switch to use koe_tx31d200vm0baa LVDS timings from
> panel-simple instead hard coding the same in dts.
> 
> Signed-off-by: Jagan Teki 

Applied both, thanks.

Re: [PATCH v4] ARM: dts: imx6q-icore-ofcap12: Switch LVDS timings from panel-simple

[Shawn Guo]

On Mon, Mar 26, 2018 at 01:35:53PM +0530, Jagan Teki wrote:
> Switch to use koe_tx31d200vm0baa LVDS timings from
> panel-simple instead hard coding the same in dts.
> 
> Signed-off-by: Jagan Teki 

Applied both, thanks.

[patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

[David Rientjes]

Since exit_mmap() is done without the protection of mm->mmap_sem, it is
possible for the oom reaper to concurrently operate on an mm until
MMF_OOM_SKIP is set.

This allows munlock_vma_pages_all() to concurrently run while the oom
reaper is operating on a vma.  Since munlock_vma_pages_range() depends on
clearing VM_LOCKED from vm_flags before actually doing the munlock to
determine if any other vmas are locking the same memory, the check for
VM_LOCKED in the oom reaper is racy.

This is especially noticeable on architectures such as powerpc where
clearing a huge pmd requires serialize_against_pte_lookup().  If the pmd
is zapped by the oom reaper during follow_page_mask() after the check for
pmd_none() is bypassed, this ends up deferencing a NULL ptl.

Fix this by reusing MMF_UNSTABLE to specify that an mm should not be
reaped.  This prevents the concurrent munlock_vma_pages_range() and
unmap_page_range().  The oom reaper will simply not operate on an mm that
has the bit set and leave the unmapping to exit_mmap().

Fixes: 212925802454 ("mm: oom: let oom_reap_task and exit_mmap run 
concurrently")
Cc: sta...@vger.kernel.org [4.14+]
Signed-off-by: David Rientjes 
---
 v2:
  - oom reaper only sets MMF_OOM_SKIP if MMF_UNSTABLE was never set (either
by itself or by exit_mmap(), per Tetsuo
  - s/kick_all_cpus_sync/serialize_against_pte_lookup/ in changelog as more
isolated way of forcing cpus as non-idle on power

 mm/mmap.c | 38 --
 mm/oom_kill.c | 28 +---
 2 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -3015,6 +3015,25 @@ void exit_mmap(struct mm_struct *mm)
/* mm's last user has gone, and its about to be pulled down */
mmu_notifier_release(mm);
 
+   if (unlikely(mm_is_oom_victim(mm))) {
+   /*
+* Wait for oom_reap_task() to stop working on this mm.  Because
+* MMF_UNSTABLE is already set before calling down_read(),
+* oom_reap_task() will not run on this mm after up_write().
+* oom_reap_task() also depends on a stable VM_LOCKED flag to
+* indicate it should not unmap during munlock_vma_pages_all().
+*
+* mm_is_oom_victim() cannot be set from under us because
+* victim->mm is already set to NULL under task_lock before
+* calling mmput() and victim->signal->oom_mm is set by the oom
+* killer only if victim->mm is non-NULL while holding
+* task_lock().
+*/
+   set_bit(MMF_UNSTABLE, >flags);
+   down_write(>mmap_sem);
+   up_write(>mmap_sem);
+   }
+
if (mm->locked_vm) {
vma = mm->mmap;
while (vma) {
@@ -3036,26 +3055,9 @@ void exit_mmap(struct mm_struct *mm)
/* update_hiwater_rss(mm) here? but nobody should be looking */
/* Use -1 here to ensure all VMAs in the mm are unmapped */
unmap_vmas(, vma, 0, -1);
-
-   if (unlikely(mm_is_oom_victim(mm))) {
-   /*
-* Wait for oom_reap_task() to stop working on this
-* mm. Because MMF_OOM_SKIP is already set before
-* calling down_read(), oom_reap_task() will not run
-* on this "mm" post up_write().
-*
-* mm_is_oom_victim() cannot be set from under us
-* either because victim->mm is already set to NULL
-* under task_lock before calling mmput and oom_mm is
-* set not NULL by the OOM killer only if victim->mm
-* is found not NULL while holding the task_lock.
-*/
-   set_bit(MMF_OOM_SKIP, >flags);
-   down_write(>mmap_sem);
-   up_write(>mmap_sem);
-   }
free_pgtables(, vma, FIRST_USER_ADDRESS, USER_PGTABLES_CEILING);
tlb_finish_mmu(, 0, -1);
+   set_bit(MMF_OOM_SKIP, >flags);
 
/*
 * Walk the list again, actually closing and freeing it,
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -521,12 +521,17 @@ static bool __oom_reap_task_mm(struct task_struct *tsk, 
struct mm_struct *mm)
}
 
/*
-* MMF_OOM_SKIP is set by exit_mmap when the OOM reaper can't
-* work on the mm anymore. The check for MMF_OOM_SKIP must run
+* Tell all users of get_user/copy_from_user etc... that the content
+* is no longer stable. No barriers really needed because unmapping
+* should imply barriers already and the reader would hit a page fault
+* if it stumbled over reaped memory.
+*
+* MMF_UNSTABLE is also set by exit_mmap when the OOM reaper shouldn't
+* work on the mm anymore. The check for MMF_OOM_UNSTABLE must run
 * 

[patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

[David Rientjes]

Since exit_mmap() is done without the protection of mm->mmap_sem, it is
possible for the oom reaper to concurrently operate on an mm until
MMF_OOM_SKIP is set.

This allows munlock_vma_pages_all() to concurrently run while the oom
reaper is operating on a vma.  Since munlock_vma_pages_range() depends on
clearing VM_LOCKED from vm_flags before actually doing the munlock to
determine if any other vmas are locking the same memory, the check for
VM_LOCKED in the oom reaper is racy.

This is especially noticeable on architectures such as powerpc where
clearing a huge pmd requires serialize_against_pte_lookup().  If the pmd
is zapped by the oom reaper during follow_page_mask() after the check for
pmd_none() is bypassed, this ends up deferencing a NULL ptl.

Fix this by reusing MMF_UNSTABLE to specify that an mm should not be
reaped.  This prevents the concurrent munlock_vma_pages_range() and
unmap_page_range().  The oom reaper will simply not operate on an mm that
has the bit set and leave the unmapping to exit_mmap().

Fixes: 212925802454 ("mm: oom: let oom_reap_task and exit_mmap run 
concurrently")
Cc: sta...@vger.kernel.org [4.14+]
Signed-off-by: David Rientjes 
---
 v2:
  - oom reaper only sets MMF_OOM_SKIP if MMF_UNSTABLE was never set (either
by itself or by exit_mmap(), per Tetsuo
  - s/kick_all_cpus_sync/serialize_against_pte_lookup/ in changelog as more
isolated way of forcing cpus as non-idle on power

 mm/mmap.c | 38 --
 mm/oom_kill.c | 28 +---
 2 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -3015,6 +3015,25 @@ void exit_mmap(struct mm_struct *mm)
/* mm's last user has gone, and its about to be pulled down */
mmu_notifier_release(mm);
 
+   if (unlikely(mm_is_oom_victim(mm))) {
+   /*
+* Wait for oom_reap_task() to stop working on this mm.  Because
+* MMF_UNSTABLE is already set before calling down_read(),
+* oom_reap_task() will not run on this mm after up_write().
+* oom_reap_task() also depends on a stable VM_LOCKED flag to
+* indicate it should not unmap during munlock_vma_pages_all().
+*
+* mm_is_oom_victim() cannot be set from under us because
+* victim->mm is already set to NULL under task_lock before
+* calling mmput() and victim->signal->oom_mm is set by the oom
+* killer only if victim->mm is non-NULL while holding
+* task_lock().
+*/
+   set_bit(MMF_UNSTABLE, >flags);
+   down_write(>mmap_sem);
+   up_write(>mmap_sem);
+   }
+
if (mm->locked_vm) {
vma = mm->mmap;
while (vma) {
@@ -3036,26 +3055,9 @@ void exit_mmap(struct mm_struct *mm)
/* update_hiwater_rss(mm) here? but nobody should be looking */
/* Use -1 here to ensure all VMAs in the mm are unmapped */
unmap_vmas(, vma, 0, -1);
-
-   if (unlikely(mm_is_oom_victim(mm))) {
-   /*
-* Wait for oom_reap_task() to stop working on this
-* mm. Because MMF_OOM_SKIP is already set before
-* calling down_read(), oom_reap_task() will not run
-* on this "mm" post up_write().
-*
-* mm_is_oom_victim() cannot be set from under us
-* either because victim->mm is already set to NULL
-* under task_lock before calling mmput and oom_mm is
-* set not NULL by the OOM killer only if victim->mm
-* is found not NULL while holding the task_lock.
-*/
-   set_bit(MMF_OOM_SKIP, >flags);
-   down_write(>mmap_sem);
-   up_write(>mmap_sem);
-   }
free_pgtables(, vma, FIRST_USER_ADDRESS, USER_PGTABLES_CEILING);
tlb_finish_mmu(, 0, -1);
+   set_bit(MMF_OOM_SKIP, >flags);
 
/*
 * Walk the list again, actually closing and freeing it,
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -521,12 +521,17 @@ static bool __oom_reap_task_mm(struct task_struct *tsk, 
struct mm_struct *mm)
}
 
/*
-* MMF_OOM_SKIP is set by exit_mmap when the OOM reaper can't
-* work on the mm anymore. The check for MMF_OOM_SKIP must run
+* Tell all users of get_user/copy_from_user etc... that the content
+* is no longer stable. No barriers really needed because unmapping
+* should imply barriers already and the reader would hit a page fault
+* if it stumbled over reaped memory.
+*
+* MMF_UNSTABLE is also set by exit_mmap when the OOM reaper shouldn't
+* work on the mm anymore. The check for MMF_OOM_UNSTABLE must run
 * under mmap_sem for 

Re: [patch] mm, oom: fix concurrent munlock and oom reaper unmap

[David Rientjes]

On Wed, 18 Apr 2018, Tetsuo Handa wrote:

> > Since exit_mmap() is done without the protection of mm->mmap_sem, it is
> > possible for the oom reaper to concurrently operate on an mm until
> > MMF_OOM_SKIP is set.
> > 
> > This allows munlock_vma_pages_all() to concurrently run while the oom
> > reaper is operating on a vma.  Since munlock_vma_pages_range() depends on
> > clearing VM_LOCKED from vm_flags before actually doing the munlock to
> > determine if any other vmas are locking the same memory, the check for
> > VM_LOCKED in the oom reaper is racy.
> > 
> > This is especially noticeable on architectures such as powerpc where
> > clearing a huge pmd requires kick_all_cpus_sync().  If the pmd is zapped
> > by the oom reaper during follow_page_mask() after the check for pmd_none()
> > is bypassed, this ends up deferencing a NULL ptl.
> 
> I don't know whether the explanation above is correct.
> Did you actually see a crash caused by this race?
> 

Yes, it's trivially reproducible on power by simply mlocking a ton of 
memory and triggering oom kill.

> > Fix this by reusing MMF_UNSTABLE to specify that an mm should not be
> > reaped.  This prevents the concurrent munlock_vma_pages_range() and
> > unmap_page_range().  The oom reaper will simply not operate on an mm that
> > has the bit set and leave the unmapping to exit_mmap().
> 
> But this patch is setting MMF_OOM_SKIP without reaping any memory as soon as
> MMF_UNSTABLE is set, which is the situation described in 212925802454:
> 

Oh, you're referring to __oom_reap_task_mm() returning true because of 
MMF_UNSTABLE and then setting MMF_OOM_SKIP itself?  Yes, that is dumb.  We 
could change __oom_reap_task_mm() to only set MMF_OOM_SKIP if MMF_UNSTABLE 
hasn't been set.  I'll send a v2, which I needed to do anyway to do 
s/kick_all_cpus_sync/serialize_against_pte_lookup/ in the changelog (power 
only does it for the needed cpus).

Re: [patch] mm, oom: fix concurrent munlock and oom reaper unmap

[David Rientjes]

On Wed, 18 Apr 2018, Tetsuo Handa wrote:

> > Since exit_mmap() is done without the protection of mm->mmap_sem, it is
> > possible for the oom reaper to concurrently operate on an mm until
> > MMF_OOM_SKIP is set.
> > 
> > This allows munlock_vma_pages_all() to concurrently run while the oom
> > reaper is operating on a vma.  Since munlock_vma_pages_range() depends on
> > clearing VM_LOCKED from vm_flags before actually doing the munlock to
> > determine if any other vmas are locking the same memory, the check for
> > VM_LOCKED in the oom reaper is racy.
> > 
> > This is especially noticeable on architectures such as powerpc where
> > clearing a huge pmd requires kick_all_cpus_sync().  If the pmd is zapped
> > by the oom reaper during follow_page_mask() after the check for pmd_none()
> > is bypassed, this ends up deferencing a NULL ptl.
> 
> I don't know whether the explanation above is correct.
> Did you actually see a crash caused by this race?
> 

Yes, it's trivially reproducible on power by simply mlocking a ton of 
memory and triggering oom kill.

> > Fix this by reusing MMF_UNSTABLE to specify that an mm should not be
> > reaped.  This prevents the concurrent munlock_vma_pages_range() and
> > unmap_page_range().  The oom reaper will simply not operate on an mm that
> > has the bit set and leave the unmapping to exit_mmap().
> 
> But this patch is setting MMF_OOM_SKIP without reaping any memory as soon as
> MMF_UNSTABLE is set, which is the situation described in 212925802454:
> 

Oh, you're referring to __oom_reap_task_mm() returning true because of 
MMF_UNSTABLE and then setting MMF_OOM_SKIP itself?  Yes, that is dumb.  We 
could change __oom_reap_task_mm() to only set MMF_OOM_SKIP if MMF_UNSTABLE 
hasn't been set.  I'll send a v2, which I needed to do anyway to do 
s/kick_all_cpus_sync/serialize_against_pte_lookup/ in the changelog (power 
only does it for the needed cpus).

Re: [PATCH 3/6] staging: lustre: remove include/linux/libcfs/linux/linux-cpu.h

[NeilBrown]

On Mon, Apr 16 2018, James Simmons wrote:

>> This include file contains definitions used when CONFIG_SMP
>> is in effect.  Other includes contain corresponding definitions
>> for when it isn't.
>> This can be hard to follow, so move the definitions to the one place.
>> 
>> As HAVE_LIBCFS_CPT is defined precisely when CONFIG_SMP, we discard
>> that macro and just use CONFIG_SMP when needed.
>
> Nak. The lustre SMP is broken and needed to badly be reworked. I have it 
> ready and can push it. I was waiting to see if I had to rebase it once
> the rc1 stuff but since their is a push to get everything out their I will
> push it.
>

Great - thanks for posting those.  I might wait until they land in
Greg's tree, then see if I there is anything else I want to add.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH 3/6] staging: lustre: remove include/linux/libcfs/linux/linux-cpu.h

[NeilBrown]

On Mon, Apr 16 2018, James Simmons wrote:

>> This include file contains definitions used when CONFIG_SMP
>> is in effect.  Other includes contain corresponding definitions
>> for when it isn't.
>> This can be hard to follow, so move the definitions to the one place.
>> 
>> As HAVE_LIBCFS_CPT is defined precisely when CONFIG_SMP, we discard
>> that macro and just use CONFIG_SMP when needed.
>
> Nak. The lustre SMP is broken and needed to badly be reworked. I have it 
> ready and can push it. I was waiting to see if I had to rebase it once
> the rc1 stuff but since their is a push to get everything out their I will
> push it.
>

Great - thanks for posting those.  I might wait until they land in
Greg's tree, then see if I there is anything else I want to add.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH] PCI: Add PCIe to pcie_print_link_status() messages

[Jakub Kicinski]

On Fri, 13 Apr 2018 11:16:38 -0700, Jakub Kicinski wrote:
> Currently the pcie_print_link_status() will print PCIe bandwidth
> and link width information but does not mention it is pertaining
> to the PCIe.  Since this and related functions are used exclusively
> by networking drivers today users may get confused into thinking
> that it's the NIC bandwidth that is being talked about.  Insert a
> "PCIe" into the messages.
> 
> Signed-off-by: Jakub Kicinski 

Hi Bjorn!

Could this small change still make it into 4.17 or are you planning to
apply it in 4.18 cycle?  IMHO the message clarification may be worth
considering for 4.17..

>  drivers/pci/pci.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index aa86e904f93c..73a0a4993f6a 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -5273,11 +5273,11 @@ void pcie_print_link_status(struct pci_dev *dev)
>   bw_avail = pcie_bandwidth_available(dev, _dev, , );
>  
>   if (bw_avail >= bw_cap)
> - pci_info(dev, "%u.%03u Gb/s available bandwidth (%s x%d 
> link)\n",
> + pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth (%s x%d 
> link)\n",
>bw_cap / 1000, bw_cap % 1000,
>PCIE_SPEED2STR(speed_cap), width_cap);
>   else
> - pci_info(dev, "%u.%03u Gb/s available bandwidth, limited by %s 
> x%d link at %s (capable of %u.%03u Gb/s with %s x%d link)\n",
> + pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth, limited 
> by %s x%d link at %s (capable of %u.%03u Gb/s with %s x%d link)\n",
>bw_avail / 1000, bw_avail % 1000,
>PCIE_SPEED2STR(speed), width,
>limiting_dev ? pci_name(limiting_dev) : "",

Re: [PATCH] PCI: Add PCIe to pcie_print_link_status() messages

[Jakub Kicinski]

On Fri, 13 Apr 2018 11:16:38 -0700, Jakub Kicinski wrote:
> Currently the pcie_print_link_status() will print PCIe bandwidth
> and link width information but does not mention it is pertaining
> to the PCIe.  Since this and related functions are used exclusively
> by networking drivers today users may get confused into thinking
> that it's the NIC bandwidth that is being talked about.  Insert a
> "PCIe" into the messages.
> 
> Signed-off-by: Jakub Kicinski 

Hi Bjorn!

Could this small change still make it into 4.17 or are you planning to
apply it in 4.18 cycle?  IMHO the message clarification may be worth
considering for 4.17..

>  drivers/pci/pci.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index aa86e904f93c..73a0a4993f6a 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -5273,11 +5273,11 @@ void pcie_print_link_status(struct pci_dev *dev)
>   bw_avail = pcie_bandwidth_available(dev, _dev, , );
>  
>   if (bw_avail >= bw_cap)
> - pci_info(dev, "%u.%03u Gb/s available bandwidth (%s x%d 
> link)\n",
> + pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth (%s x%d 
> link)\n",
>bw_cap / 1000, bw_cap % 1000,
>PCIE_SPEED2STR(speed_cap), width_cap);
>   else
> - pci_info(dev, "%u.%03u Gb/s available bandwidth, limited by %s 
> x%d link at %s (capable of %u.%03u Gb/s with %s x%d link)\n",
> + pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth, limited 
> by %s x%d link at %s (capable of %u.%03u Gb/s with %s x%d link)\n",
>bw_avail / 1000, bw_avail % 1000,
>PCIE_SPEED2STR(speed), width,
>limiting_dev ? pci_name(limiting_dev) : "",

Re: [PATCH v2] clk: imx: Set CLK_SET_RATE_GATE for gate and divider clocks

[Shawn Guo]

On Wed, Apr 11, 2018 at 05:03:29PM +0300, Abel Vesa wrote:
> From: Shawn Guo 
> 
> Add flag CLK_SET_RATE_GATE for i.MX gate and divider clocks on which the
> client drivers usually make clk_set_rate() call, so that the call will fail
> when clock is still on instead of standing the risk of running into glitch
> issue. Rate cannot be changed when the clock is enabled due to the glitchy
> multiplexers.
> 
> Signed-off-by: Shawn Guo 
> [initial patch from imx internal repo]
> Signed-off-by: Abel Vesa 
> [carried over from 3.14 and also applied the flag to newer functions]
> ---
> 
> Changes since v1:
>  - changed ownership as per initial patch

IIRC, the patch was created on vendor kernel long time ago to work
around a specific glitchy multiplexer issue seen on particular SoC.
I'm not sure it's good for the upstream kernel today.

Shawn

Re: [PATCH v2] clk: imx: Set CLK_SET_RATE_GATE for gate and divider clocks

[Shawn Guo]

On Wed, Apr 11, 2018 at 05:03:29PM +0300, Abel Vesa wrote:
> From: Shawn Guo 
> 
> Add flag CLK_SET_RATE_GATE for i.MX gate and divider clocks on which the
> client drivers usually make clk_set_rate() call, so that the call will fail
> when clock is still on instead of standing the risk of running into glitch
> issue. Rate cannot be changed when the clock is enabled due to the glitchy
> multiplexers.
> 
> Signed-off-by: Shawn Guo 
> [initial patch from imx internal repo]
> Signed-off-by: Abel Vesa 
> [carried over from 3.14 and also applied the flag to newer functions]
> ---
> 
> Changes since v1:
>  - changed ownership as per initial patch

IIRC, the patch was created on vendor kernel long time ago to work
around a specific glitchy multiplexer issue seen on particular SoC.
I'm not sure it's good for the upstream kernel today.

Shawn