Re: [patch 14/24] x86/speculation: Unify conditional spectre v2 print functions

2018-11-21 Thread Ingo Molnar


* Thomas Gleixner  wrote:

> There is no point in having two functions and a conditional at the call
> site.
> 
> Signed-off-by: Thomas Gleixner 

patches 1-14:

  Reviewed-by: Ingo Molnar 

15-24 look good to me too, modulo the (mostly trivial) feedback I gave.

Thanks,

Ingo


Re: [patch 14/24] x86/speculation: Unify conditional spectre v2 print functions

2018-11-21 Thread Ingo Molnar


* Thomas Gleixner  wrote:

> There is no point in having two functions and a conditional at the call
> site.
> 
> Signed-off-by: Thomas Gleixner 

patches 1-14:

  Reviewed-by: Ingo Molnar 

15-24 look good to me too, modulo the (mostly trivial) feedback I gave.

Thanks,

Ingo


Re: [patch 16/24] x86/speculation: Prepare for per task indirect branch speculation control

2018-11-21 Thread Ingo Molnar


* Thomas Gleixner  wrote:

> From: Tim Chen 
> 
> To avoid the overhead of STIBP always on, it's necessary to allow per task
> control of STIBP.
> 
> Add a new task flag TIF_SPEC_IB and evaluate it during context switch if
> SMT is active and flag evaluation is enabled by the speculation control
> code. Add the conditional evaluation to x86_virt_spec_ctrl() as well so the
> guest/host switch works properly.
> 
> This has no effect because TIF_SPEC_IB cannot be set yet and the static key
> which controls evaluation is off. Preparatory patch for adding the control
> code.
> 
> [ tglx: Simplify the context switch logic and make the TIF evaluation
>   depend on SMP=y and on the static key controlling the conditional
>   update. Rename it to TIF_SPEC_IB because it controls both STIBP and
>   IBPB ]
> 
> Signed-off-by: Tim Chen 
> Signed-off-by: Thomas Gleixner 
> 
> ---
>  arch/x86/include/asm/msr-index.h   |5 +++--
>  arch/x86/include/asm/spec-ctrl.h   |   12 
>  arch/x86/include/asm/thread_info.h |5 -
>  arch/x86/kernel/cpu/bugs.c |4 
>  arch/x86/kernel/process.c  |   24 ++--
>  5 files changed, 45 insertions(+), 5 deletions(-)
> 
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -41,9 +41,10 @@
>  
>  #define MSR_IA32_SPEC_CTRL   0x0048 /* Speculation Control */
>  #define SPEC_CTRL_IBRS   (1 << 0)   /* Indirect Branch 
> Restricted Speculation */
> -#define SPEC_CTRL_STIBP  (1 << 1)   /* Single Thread 
> Indirect Branch Predictors */
> +#define SPEC_CTRL_STIBP_SHIFT1  /* Single Thread 
> Indirect Branch Predictor (STIBP) bit */
> +#define SPEC_CTRL_STIBP  (1 << SPEC_CTRL_STIBP_SHIFT)
> /* STIBP mask */
>  #define SPEC_CTRL_SSBD_SHIFT 2  /* Speculative Store Bypass 
> Disable bit */
> -#define SPEC_CTRL_SSBD   (1 << SPEC_CTRL_SSBD_SHIFT)   
> /* Speculative Store Bypass Disable */
> +#define SPEC_CTRL_SSBD   (1 << SPEC_CTRL_SSBD_SHIFT) 
> /* Speculative Store Bypass Disable */
>  
>  #define MSR_IA32_PRED_CMD0x0049 /* Prediction Command */
>  #define PRED_CMD_IBPB(1 << 0)   /* Indirect Branch 
> Prediction Barrier */
> --- a/arch/x86/include/asm/spec-ctrl.h
> +++ b/arch/x86/include/asm/spec-ctrl.h
> @@ -53,12 +53,24 @@ static inline u64 ssbd_tif_to_spec_ctrl(
>   return (tifn & _TIF_SSBD) >> (TIF_SSBD - SPEC_CTRL_SSBD_SHIFT);
>  }
>  
> +static inline u64 stibp_tif_to_spec_ctrl(u64 tifn)
> +{
> + BUILD_BUG_ON(TIF_SPEC_IB < SPEC_CTRL_STIBP_SHIFT);
> + return (tifn & _TIF_SPEC_IB) >> (TIF_SPEC_IB - SPEC_CTRL_STIBP_SHIFT);
> +}
> +
>  static inline unsigned long ssbd_spec_ctrl_to_tif(u64 spec_ctrl)
>  {
>   BUILD_BUG_ON(TIF_SSBD < SPEC_CTRL_SSBD_SHIFT);
>   return (spec_ctrl & SPEC_CTRL_SSBD) << (TIF_SSBD - 
> SPEC_CTRL_SSBD_SHIFT);
>  }
>  
> +static inline unsigned long stibp_spec_ctrl_to_tif(u64 spec_ctrl)
> +{
> + BUILD_BUG_ON(TIF_SPEC_IB < SPEC_CTRL_STIBP_SHIFT);
> + return (spec_ctrl & SPEC_CTRL_STIBP) << (TIF_SPEC_IB - 
> SPEC_CTRL_STIBP_SHIFT);
> +}
> +
>  static inline u64 ssbd_tif_to_amd_ls_cfg(u64 tifn)
>  {
>   return (tifn & _TIF_SSBD) ? x86_amd_ls_cfg_ssbd_mask : 0ULL;
> --- a/arch/x86/include/asm/thread_info.h
> +++ b/arch/x86/include/asm/thread_info.h
> @@ -83,6 +83,7 @@ struct thread_info {
>  #define TIF_SYSCALL_EMU  6   /* syscall emulation active */
>  #define TIF_SYSCALL_AUDIT7   /* syscall auditing active */
>  #define TIF_SECCOMP  8   /* secure computing */
> +#define TIF_SPEC_IB  9   /* Indirect branch speculation 
> mitigation */
>  #define TIF_USER_RETURN_NOTIFY   11  /* notify kernel of userspace 
> return */
>  #define TIF_UPROBE   12  /* breakpointed or singlestepping */
>  #define TIF_PATCH_PENDING13  /* pending live patching update */
> @@ -110,6 +111,7 @@ struct thread_info {
>  #define _TIF_SYSCALL_EMU (1 << TIF_SYSCALL_EMU)
>  #define _TIF_SYSCALL_AUDIT   (1 << TIF_SYSCALL_AUDIT)
>  #define _TIF_SECCOMP (1 << TIF_SECCOMP)
> +#define _TIF_SPEC_IB (1 << TIF_SPEC_IB)
>  #define _TIF_USER_RETURN_NOTIFY  (1 << TIF_USER_RETURN_NOTIFY)
>  #define _TIF_UPROBE  (1 << TIF_UPROBE)
>  #define _TIF_PATCH_PENDING   (1 << TIF_PATCH_PENDING)
> @@ -146,7 +148,8 @@ struct thread_info {
>  
>  /* flags to check in __switch_to() */
>  #define _TIF_WORK_CTXSW  
> \
> - (_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP|_TIF_SSBD)
> + (_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP| \
> +  _TIF_SSBD|_TIF_SPEC_IB)
>  
>  #define _TIF_WORK_CTXSW_PREV (_TIF_WORK_CTXSW|_TIF_USER_RETURN_NOTIFY)
>  #define _TIF_WORK_CTXSW_NEXT (_TIF_WORK_CTXSW)
> --- 

Re: [patch 16/24] x86/speculation: Prepare for per task indirect branch speculation control

2018-11-21 Thread Ingo Molnar


* Thomas Gleixner  wrote:

> From: Tim Chen 
> 
> To avoid the overhead of STIBP always on, it's necessary to allow per task
> control of STIBP.
> 
> Add a new task flag TIF_SPEC_IB and evaluate it during context switch if
> SMT is active and flag evaluation is enabled by the speculation control
> code. Add the conditional evaluation to x86_virt_spec_ctrl() as well so the
> guest/host switch works properly.
> 
> This has no effect because TIF_SPEC_IB cannot be set yet and the static key
> which controls evaluation is off. Preparatory patch for adding the control
> code.
> 
> [ tglx: Simplify the context switch logic and make the TIF evaluation
>   depend on SMP=y and on the static key controlling the conditional
>   update. Rename it to TIF_SPEC_IB because it controls both STIBP and
>   IBPB ]
> 
> Signed-off-by: Tim Chen 
> Signed-off-by: Thomas Gleixner 
> 
> ---
>  arch/x86/include/asm/msr-index.h   |5 +++--
>  arch/x86/include/asm/spec-ctrl.h   |   12 
>  arch/x86/include/asm/thread_info.h |5 -
>  arch/x86/kernel/cpu/bugs.c |4 
>  arch/x86/kernel/process.c  |   24 ++--
>  5 files changed, 45 insertions(+), 5 deletions(-)
> 
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -41,9 +41,10 @@
>  
>  #define MSR_IA32_SPEC_CTRL   0x0048 /* Speculation Control */
>  #define SPEC_CTRL_IBRS   (1 << 0)   /* Indirect Branch 
> Restricted Speculation */
> -#define SPEC_CTRL_STIBP  (1 << 1)   /* Single Thread 
> Indirect Branch Predictors */
> +#define SPEC_CTRL_STIBP_SHIFT1  /* Single Thread 
> Indirect Branch Predictor (STIBP) bit */
> +#define SPEC_CTRL_STIBP  (1 << SPEC_CTRL_STIBP_SHIFT)
> /* STIBP mask */
>  #define SPEC_CTRL_SSBD_SHIFT 2  /* Speculative Store Bypass 
> Disable bit */
> -#define SPEC_CTRL_SSBD   (1 << SPEC_CTRL_SSBD_SHIFT)   
> /* Speculative Store Bypass Disable */
> +#define SPEC_CTRL_SSBD   (1 << SPEC_CTRL_SSBD_SHIFT) 
> /* Speculative Store Bypass Disable */
>  
>  #define MSR_IA32_PRED_CMD0x0049 /* Prediction Command */
>  #define PRED_CMD_IBPB(1 << 0)   /* Indirect Branch 
> Prediction Barrier */
> --- a/arch/x86/include/asm/spec-ctrl.h
> +++ b/arch/x86/include/asm/spec-ctrl.h
> @@ -53,12 +53,24 @@ static inline u64 ssbd_tif_to_spec_ctrl(
>   return (tifn & _TIF_SSBD) >> (TIF_SSBD - SPEC_CTRL_SSBD_SHIFT);
>  }
>  
> +static inline u64 stibp_tif_to_spec_ctrl(u64 tifn)
> +{
> + BUILD_BUG_ON(TIF_SPEC_IB < SPEC_CTRL_STIBP_SHIFT);
> + return (tifn & _TIF_SPEC_IB) >> (TIF_SPEC_IB - SPEC_CTRL_STIBP_SHIFT);
> +}
> +
>  static inline unsigned long ssbd_spec_ctrl_to_tif(u64 spec_ctrl)
>  {
>   BUILD_BUG_ON(TIF_SSBD < SPEC_CTRL_SSBD_SHIFT);
>   return (spec_ctrl & SPEC_CTRL_SSBD) << (TIF_SSBD - 
> SPEC_CTRL_SSBD_SHIFT);
>  }
>  
> +static inline unsigned long stibp_spec_ctrl_to_tif(u64 spec_ctrl)
> +{
> + BUILD_BUG_ON(TIF_SPEC_IB < SPEC_CTRL_STIBP_SHIFT);
> + return (spec_ctrl & SPEC_CTRL_STIBP) << (TIF_SPEC_IB - 
> SPEC_CTRL_STIBP_SHIFT);
> +}
> +
>  static inline u64 ssbd_tif_to_amd_ls_cfg(u64 tifn)
>  {
>   return (tifn & _TIF_SSBD) ? x86_amd_ls_cfg_ssbd_mask : 0ULL;
> --- a/arch/x86/include/asm/thread_info.h
> +++ b/arch/x86/include/asm/thread_info.h
> @@ -83,6 +83,7 @@ struct thread_info {
>  #define TIF_SYSCALL_EMU  6   /* syscall emulation active */
>  #define TIF_SYSCALL_AUDIT7   /* syscall auditing active */
>  #define TIF_SECCOMP  8   /* secure computing */
> +#define TIF_SPEC_IB  9   /* Indirect branch speculation 
> mitigation */
>  #define TIF_USER_RETURN_NOTIFY   11  /* notify kernel of userspace 
> return */
>  #define TIF_UPROBE   12  /* breakpointed or singlestepping */
>  #define TIF_PATCH_PENDING13  /* pending live patching update */
> @@ -110,6 +111,7 @@ struct thread_info {
>  #define _TIF_SYSCALL_EMU (1 << TIF_SYSCALL_EMU)
>  #define _TIF_SYSCALL_AUDIT   (1 << TIF_SYSCALL_AUDIT)
>  #define _TIF_SECCOMP (1 << TIF_SECCOMP)
> +#define _TIF_SPEC_IB (1 << TIF_SPEC_IB)
>  #define _TIF_USER_RETURN_NOTIFY  (1 << TIF_USER_RETURN_NOTIFY)
>  #define _TIF_UPROBE  (1 << TIF_UPROBE)
>  #define _TIF_PATCH_PENDING   (1 << TIF_PATCH_PENDING)
> @@ -146,7 +148,8 @@ struct thread_info {
>  
>  /* flags to check in __switch_to() */
>  #define _TIF_WORK_CTXSW  
> \
> - (_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP|_TIF_SSBD)
> + (_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP| \
> +  _TIF_SSBD|_TIF_SPEC_IB)
>  
>  #define _TIF_WORK_CTXSW_PREV (_TIF_WORK_CTXSW|_TIF_USER_RETURN_NOTIFY)
>  #define _TIF_WORK_CTXSW_NEXT (_TIF_WORK_CTXSW)
> --- 

[PATCH] iio: adc: meson-saradc: check for devm_kasprintf failure

2018-11-21 Thread Nicholas Mc Guire
devm_kasprintf() may return NULL on failure of internal allocation thus 
the assignments to  init.name  are not safe if not checked. On error
meson_sar_adc_clk_init() returns negative values so -ENOMEM in the
(unlikely) failure case of devm_kasprintf() should be fine here.

Signed-off-by: Nicholas Mc Guire 
Fixes: 3adbf3427330 ("iio: adc: add a driver for the SAR ADC found in Amlogic 
Meson SoCs")
---

Problem located with an experimental coccinelle script

Patch was compile tested with: multi_v7_defconfig (implies ARCH_MESON=y &
MESON_SARADC=y)

Patch is against 4.20-rc3 (localversion-next is next-20181122)

 drivers/iio/adc/meson_saradc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index 028ccd2..672a5de 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -589,6 +589,9 @@ static int meson_sar_adc_clk_init(struct iio_dev *indio_dev,
 
init.name = devm_kasprintf(_dev->dev, GFP_KERNEL, "%pOF#adc_div",
   indio_dev->dev.of_node);
+   if (!init.name)
+   return -ENOMEM;
+
init.flags = 0;
init.ops = _divider_ops;
clk_parents[0] = __clk_get_name(priv->clkin);
@@ -608,6 +611,9 @@ static int meson_sar_adc_clk_init(struct iio_dev *indio_dev,
 
init.name = devm_kasprintf(_dev->dev, GFP_KERNEL, "%pOF#adc_en",
   indio_dev->dev.of_node);
+   if (!init.name)
+   return -ENOMEM;
+
init.flags = CLK_SET_RATE_PARENT;
init.ops = _gate_ops;
clk_parents[0] = __clk_get_name(priv->adc_div_clk);
-- 
2.1.4



[PATCH] iio: adc: meson-saradc: check for devm_kasprintf failure

2018-11-21 Thread Nicholas Mc Guire
devm_kasprintf() may return NULL on failure of internal allocation thus 
the assignments to  init.name  are not safe if not checked. On error
meson_sar_adc_clk_init() returns negative values so -ENOMEM in the
(unlikely) failure case of devm_kasprintf() should be fine here.

Signed-off-by: Nicholas Mc Guire 
Fixes: 3adbf3427330 ("iio: adc: add a driver for the SAR ADC found in Amlogic 
Meson SoCs")
---

Problem located with an experimental coccinelle script

Patch was compile tested with: multi_v7_defconfig (implies ARCH_MESON=y &
MESON_SARADC=y)

Patch is against 4.20-rc3 (localversion-next is next-20181122)

 drivers/iio/adc/meson_saradc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index 028ccd2..672a5de 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -589,6 +589,9 @@ static int meson_sar_adc_clk_init(struct iio_dev *indio_dev,
 
init.name = devm_kasprintf(_dev->dev, GFP_KERNEL, "%pOF#adc_div",
   indio_dev->dev.of_node);
+   if (!init.name)
+   return -ENOMEM;
+
init.flags = 0;
init.ops = _divider_ops;
clk_parents[0] = __clk_get_name(priv->clkin);
@@ -608,6 +611,9 @@ static int meson_sar_adc_clk_init(struct iio_dev *indio_dev,
 
init.name = devm_kasprintf(_dev->dev, GFP_KERNEL, "%pOF#adc_en",
   indio_dev->dev.of_node);
+   if (!init.name)
+   return -ENOMEM;
+
init.flags = CLK_SET_RATE_PARENT;
init.ops = _gate_ops;
clk_parents[0] = __clk_get_name(priv->adc_div_clk);
-- 
2.1.4



[PATCH v10 3/3] clk: qcom: Add lpass clock controller driver for SDM845

2018-11-21 Thread Taniya Das
Add support for the lpass clock controller found on SDM845 based devices.
This would allow lpass peripheral loader drivers to control the clocks to
bring the subsystem out of reset.
LPASS clocks present on the global clock controller would be registered
with the clock framework based on the protected-clock flag. Also do not
gate these clocks if they are left unused, as the lpass clocks require
the global clock controller lpass clocks to be enabled before they are
accessed. Mark the GCC lpass clocks as CRITICAL, for the LPASS clock
access.

Signed-off-by: Taniya Das 
---
 drivers/clk/qcom/Kconfig  |   9 ++
 drivers/clk/qcom/Makefile |   1 +
 drivers/clk/qcom/gcc-sdm845.c |  30 +++
 drivers/clk/qcom/lpasscc-sdm845.c | 179 ++
 4 files changed, 219 insertions(+)
 create mode 100644 drivers/clk/qcom/lpasscc-sdm845.c

diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index a611531..23adc4c 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -293,6 +293,15 @@ config SDM_DISPCC_845
  Say Y if you want to support display devices and functionality such as
  splash screen.

+config SDM_LPASSCC_845
+   tristate "SDM845 Low Power Audio Subsystem (LPAAS) Clock Controller"
+   depends on COMMON_CLK_QCOM
+   select SDM_GCC_845
+   help
+ Support for the LPASS clock controller on SDM845 devices.
+ Say Y if you want to use the LPASS branch clocks of the LPASS clock
+ controller to reset the LPASS subsystem.
+
 config SPMI_PMIC_CLKDIV
tristate "SPMI PMIC clkdiv Support"
depends on (COMMON_CLK_QCOM && SPMI) || COMPILE_TEST
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 981882e..3d530b1 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SDM_CAMCC_845) += camcc-sdm845.o
 obj-$(CONFIG_SDM_DISPCC_845) += dispcc-sdm845.o
 obj-$(CONFIG_SDM_GCC_660) += gcc-sdm660.o
 obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o
+obj-$(CONFIG_SDM_LPASSCC_845) += lpasscc-sdm845.o
 obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o
 obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
 obj-$(CONFIG_KPSS_XCC) += kpss-xcc.o
diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
index f133b7f..ba8ff99 100644
--- a/drivers/clk/qcom/gcc-sdm845.c
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -3153,6 +3153,34 @@ enum {
},
 };

+static struct clk_branch gcc_lpass_q6_axi_clk = {
+   .halt_reg = 0x47000,
+   .halt_check = BRANCH_HALT,
+   .clkr = {
+   .enable_reg = 0x47000,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "gcc_lpass_q6_axi_clk",
+   .flags = CLK_IS_CRITICAL,
+   .ops = _branch2_ops,
+   },
+   },
+};
+
+static struct clk_branch gcc_lpass_sway_clk = {
+   .halt_reg = 0x47008,
+   .halt_check = BRANCH_HALT,
+   .clkr = {
+   .enable_reg = 0x47008,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "gcc_lpass_sway_clk",
+   .flags = CLK_IS_CRITICAL,
+   .ops = _branch2_ops,
+   },
+   },
+};
+
 static struct gdsc pcie_0_gdsc = {
.gdscr = 0x6b004,
.pd = {
@@ -3453,6 +3481,8 @@ enum {
[GCC_QSPI_CORE_CLK_SRC] = _qspi_core_clk_src.clkr,
[GCC_QSPI_CORE_CLK] = _qspi_core_clk.clkr,
[GCC_QSPI_CNOC_PERIPH_AHB_CLK] = _qspi_cnoc_periph_ahb_clk.clkr,
+   [GCC_LPASS_Q6_AXI_CLK] = _lpass_q6_axi_clk.clkr,
+   [GCC_LPASS_SWAY_CLK] = _lpass_sway_clk.clkr,
 };

 static const struct qcom_reset_map gcc_sdm845_resets[] = {
diff --git a/drivers/clk/qcom/lpasscc-sdm845.c 
b/drivers/clk/qcom/lpasscc-sdm845.c
new file mode 100644
index 000..9c63542
--- /dev/null
+++ b/drivers/clk/qcom/lpasscc-sdm845.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "clk-regmap.h"
+#include "clk-branch.h"
+#include "common.h"
+
+static struct clk_branch lpass_q6ss_ahbm_aon_clk = {
+   .halt_reg = 0x12000,
+   .halt_check = BRANCH_VOTED,
+   .clkr = {
+   .enable_reg = 0x12000,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "lpass_q6ss_ahbm_aon_clk",
+   .ops = _branch2_ops,
+   },
+   },
+};
+
+static struct clk_branch lpass_q6ss_ahbs_aon_clk = {
+   .halt_reg = 0x1f000,
+   .halt_check = BRANCH_VOTED,
+   .clkr = {
+   .enable_reg = 0x1f000,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = 

[PATCH v10 0/3] Add support for LPASS clock controller for SDM845

2018-11-21 Thread Taniya Das
 [v10]
  * Separate change to add  protected-clocks list in GCC binding.
  * Remove the clock support 'LPASS_AUDIO_WRAPPER_AON_CLK' as it is always ON
  clock.
  * Add few comments for module description and match table.

 [v9]
  * Update GCC documentation binding with the protected-clocks list.
  * Update the GCC code to add the GCC lpass clocks.
  * This depends on the acceptance of
  https://lore.kernel.org/lkml/20181105194011.43770-1-swb...@chromium.org/

 [v8]
  * Add CLK_IS_CRITICAL for GCC lpass clocks for lpass clocks access to go
  through always.

 [v7]
  * Cleanup header file inclusions.
  * Move the comments along with the flags.
  * Update the commit with details for CLK_IGNORE_UNUSED.

 [v6]
  * Update the logic to register the lpass clocks when the device tree property
   is not present.
  * Add the CLK_IGNORE_UNUSED flag for the lpass clocks to not gate the clocks
   at late_init.

 [v5]
  * Address the comments in device tree binding to update the reg-names,
update the unit address in lpass clock node example and also
add reg property for the gcc clock node.
  * Update the lpass driver to take care of the reg-names.

 [v4]
  * Update the description in GCC Documentation binding for
  'qcom,lpass-protected'.
  * Remove 'qcom,lpass-protected' from LPASS Documentation binding.
  * Update KConfig to use Low Power Audio Subsystem.
  * Add module_exit() and also update return value for
devm_ioremap_resource failure.

 [v3]
  * Add a device tree property to identify lpass protected GCC clocks.
  * Update the GCC driver code to register the lpass clocks when the flag is
   defined.
  * Add comment for clocks using the BRANCH_HALT_SKIP flag.
  * Use platform APIs instead of of_address_to_resource.
  * Replace devm_ioremap with devm_ioremap_resource.
  * Use fixed index for 'lpass_cc' & 'lpass_qdsp6ss' in probe.

 [v2]
  * Make gcc_lpass_sway_clk static.
  * Remove using child nodes and use reg-names to differentiate various
domains of LPASS CC.

Add support for the lpass clock controller found on SDM845 based devices.
This would allow lpass peripheral loader drivers to control the clocks to
bring the subsystem out of reset.

Taniya Das (3):
  dt-bindings: clock: Update GCC bindings for protected-clocks
  dt-bindings: clock: Introduce QCOM LPASS clock bindings
  clk: qcom: Add lpass clock controller driver for SDM845

 .../devicetree/bindings/clock/qcom,gcc.txt |  16 ++
 .../devicetree/bindings/clock/qcom,lpasscc.txt |  26 +++
 drivers/clk/qcom/Kconfig   |   9 ++
 drivers/clk/qcom/Makefile  |   1 +
 drivers/clk/qcom/gcc-sdm845.c  |  30 
 drivers/clk/qcom/lpasscc-sdm845.c  | 179 +
 include/dt-bindings/clock/qcom,gcc-sdm845.h|   2 +
 include/dt-bindings/clock/qcom,lpass-sdm845.h  |  15 ++
 8 files changed, 278 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,lpasscc.txt
 create mode 100644 drivers/clk/qcom/lpasscc-sdm845.c
 create mode 100644 include/dt-bindings/clock/qcom,lpass-sdm845.h

--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the  Linux Foundation.



[PATCH v10 1/3] dt-bindings: clock: Update GCC bindings for protected-clocks

2018-11-21 Thread Taniya Das
Add protected-clocks list which could used to specify the clocks to be
bypassed on certain devices.

Signed-off-by: Taniya Das 
---
 Documentation/devicetree/bindings/clock/qcom,gcc.txt | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt 
b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index 52d9345..5e37de9 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -35,6 +35,8 @@ be part of GCC and hence the TSENS properties can also be
 part of the GCC/clock-controller node.
 For more details on the TSENS properties please refer
 Documentation/devicetree/bindings/thermal/qcom-tsens.txt
+- protected-clocks : Protected clock specifier list as per common clock
+ binding.

 Example:
clock-controller@90 {
@@ -55,3 +57,15 @@ Example of GCC with TSENS properties:
#reset-cells = <1>;
#thermal-sensor-cells = <1>;
};
+
+Example of GCC with protected-clocks properties:
+   clock-controller@10 {
+   compatible = "qcom,gcc-sdm845";
+   reg = <0x10 0x1f>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   #power-domain-cells = <1>;
+   protected-clocks = ,
+  ,
+  ;
+   };
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the  Linux Foundation.



[PATCH v10 0/3] Add support for LPASS clock controller for SDM845

2018-11-21 Thread Taniya Das
 [v10]
  * Separate change to add  protected-clocks list in GCC binding.
  * Remove the clock support 'LPASS_AUDIO_WRAPPER_AON_CLK' as it is always ON
  clock.
  * Add few comments for module description and match table.

 [v9]
  * Update GCC documentation binding with the protected-clocks list.
  * Update the GCC code to add the GCC lpass clocks.
  * This depends on the acceptance of
  https://lore.kernel.org/lkml/20181105194011.43770-1-swb...@chromium.org/

 [v8]
  * Add CLK_IS_CRITICAL for GCC lpass clocks for lpass clocks access to go
  through always.

 [v7]
  * Cleanup header file inclusions.
  * Move the comments along with the flags.
  * Update the commit with details for CLK_IGNORE_UNUSED.

 [v6]
  * Update the logic to register the lpass clocks when the device tree property
   is not present.
  * Add the CLK_IGNORE_UNUSED flag for the lpass clocks to not gate the clocks
   at late_init.

 [v5]
  * Address the comments in device tree binding to update the reg-names,
update the unit address in lpass clock node example and also
add reg property for the gcc clock node.
  * Update the lpass driver to take care of the reg-names.

 [v4]
  * Update the description in GCC Documentation binding for
  'qcom,lpass-protected'.
  * Remove 'qcom,lpass-protected' from LPASS Documentation binding.
  * Update KConfig to use Low Power Audio Subsystem.
  * Add module_exit() and also update return value for
devm_ioremap_resource failure.

 [v3]
  * Add a device tree property to identify lpass protected GCC clocks.
  * Update the GCC driver code to register the lpass clocks when the flag is
   defined.
  * Add comment for clocks using the BRANCH_HALT_SKIP flag.
  * Use platform APIs instead of of_address_to_resource.
  * Replace devm_ioremap with devm_ioremap_resource.
  * Use fixed index for 'lpass_cc' & 'lpass_qdsp6ss' in probe.

 [v2]
  * Make gcc_lpass_sway_clk static.
  * Remove using child nodes and use reg-names to differentiate various
domains of LPASS CC.

Add support for the lpass clock controller found on SDM845 based devices.
This would allow lpass peripheral loader drivers to control the clocks to
bring the subsystem out of reset.

Taniya Das (3):
  dt-bindings: clock: Update GCC bindings for protected-clocks
  dt-bindings: clock: Introduce QCOM LPASS clock bindings
  clk: qcom: Add lpass clock controller driver for SDM845

 .../devicetree/bindings/clock/qcom,gcc.txt |  16 ++
 .../devicetree/bindings/clock/qcom,lpasscc.txt |  26 +++
 drivers/clk/qcom/Kconfig   |   9 ++
 drivers/clk/qcom/Makefile  |   1 +
 drivers/clk/qcom/gcc-sdm845.c  |  30 
 drivers/clk/qcom/lpasscc-sdm845.c  | 179 +
 include/dt-bindings/clock/qcom,gcc-sdm845.h|   2 +
 include/dt-bindings/clock/qcom,lpass-sdm845.h  |  15 ++
 8 files changed, 278 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,lpasscc.txt
 create mode 100644 drivers/clk/qcom/lpasscc-sdm845.c
 create mode 100644 include/dt-bindings/clock/qcom,lpass-sdm845.h

--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the  Linux Foundation.



[PATCH v10 1/3] dt-bindings: clock: Update GCC bindings for protected-clocks

2018-11-21 Thread Taniya Das
Add protected-clocks list which could used to specify the clocks to be
bypassed on certain devices.

Signed-off-by: Taniya Das 
---
 Documentation/devicetree/bindings/clock/qcom,gcc.txt | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt 
b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index 52d9345..5e37de9 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -35,6 +35,8 @@ be part of GCC and hence the TSENS properties can also be
 part of the GCC/clock-controller node.
 For more details on the TSENS properties please refer
 Documentation/devicetree/bindings/thermal/qcom-tsens.txt
+- protected-clocks : Protected clock specifier list as per common clock
+ binding.

 Example:
clock-controller@90 {
@@ -55,3 +57,15 @@ Example of GCC with TSENS properties:
#reset-cells = <1>;
#thermal-sensor-cells = <1>;
};
+
+Example of GCC with protected-clocks properties:
+   clock-controller@10 {
+   compatible = "qcom,gcc-sdm845";
+   reg = <0x10 0x1f>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   #power-domain-cells = <1>;
+   protected-clocks = ,
+  ,
+  ;
+   };
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the  Linux Foundation.



[PATCH v10 3/3] clk: qcom: Add lpass clock controller driver for SDM845

2018-11-21 Thread Taniya Das
Add support for the lpass clock controller found on SDM845 based devices.
This would allow lpass peripheral loader drivers to control the clocks to
bring the subsystem out of reset.
LPASS clocks present on the global clock controller would be registered
with the clock framework based on the protected-clock flag. Also do not
gate these clocks if they are left unused, as the lpass clocks require
the global clock controller lpass clocks to be enabled before they are
accessed. Mark the GCC lpass clocks as CRITICAL, for the LPASS clock
access.

Signed-off-by: Taniya Das 
---
 drivers/clk/qcom/Kconfig  |   9 ++
 drivers/clk/qcom/Makefile |   1 +
 drivers/clk/qcom/gcc-sdm845.c |  30 +++
 drivers/clk/qcom/lpasscc-sdm845.c | 179 ++
 4 files changed, 219 insertions(+)
 create mode 100644 drivers/clk/qcom/lpasscc-sdm845.c

diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index a611531..23adc4c 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -293,6 +293,15 @@ config SDM_DISPCC_845
  Say Y if you want to support display devices and functionality such as
  splash screen.

+config SDM_LPASSCC_845
+   tristate "SDM845 Low Power Audio Subsystem (LPAAS) Clock Controller"
+   depends on COMMON_CLK_QCOM
+   select SDM_GCC_845
+   help
+ Support for the LPASS clock controller on SDM845 devices.
+ Say Y if you want to use the LPASS branch clocks of the LPASS clock
+ controller to reset the LPASS subsystem.
+
 config SPMI_PMIC_CLKDIV
tristate "SPMI PMIC clkdiv Support"
depends on (COMMON_CLK_QCOM && SPMI) || COMPILE_TEST
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 981882e..3d530b1 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SDM_CAMCC_845) += camcc-sdm845.o
 obj-$(CONFIG_SDM_DISPCC_845) += dispcc-sdm845.o
 obj-$(CONFIG_SDM_GCC_660) += gcc-sdm660.o
 obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o
+obj-$(CONFIG_SDM_LPASSCC_845) += lpasscc-sdm845.o
 obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o
 obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
 obj-$(CONFIG_KPSS_XCC) += kpss-xcc.o
diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
index f133b7f..ba8ff99 100644
--- a/drivers/clk/qcom/gcc-sdm845.c
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -3153,6 +3153,34 @@ enum {
},
 };

+static struct clk_branch gcc_lpass_q6_axi_clk = {
+   .halt_reg = 0x47000,
+   .halt_check = BRANCH_HALT,
+   .clkr = {
+   .enable_reg = 0x47000,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "gcc_lpass_q6_axi_clk",
+   .flags = CLK_IS_CRITICAL,
+   .ops = _branch2_ops,
+   },
+   },
+};
+
+static struct clk_branch gcc_lpass_sway_clk = {
+   .halt_reg = 0x47008,
+   .halt_check = BRANCH_HALT,
+   .clkr = {
+   .enable_reg = 0x47008,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "gcc_lpass_sway_clk",
+   .flags = CLK_IS_CRITICAL,
+   .ops = _branch2_ops,
+   },
+   },
+};
+
 static struct gdsc pcie_0_gdsc = {
.gdscr = 0x6b004,
.pd = {
@@ -3453,6 +3481,8 @@ enum {
[GCC_QSPI_CORE_CLK_SRC] = _qspi_core_clk_src.clkr,
[GCC_QSPI_CORE_CLK] = _qspi_core_clk.clkr,
[GCC_QSPI_CNOC_PERIPH_AHB_CLK] = _qspi_cnoc_periph_ahb_clk.clkr,
+   [GCC_LPASS_Q6_AXI_CLK] = _lpass_q6_axi_clk.clkr,
+   [GCC_LPASS_SWAY_CLK] = _lpass_sway_clk.clkr,
 };

 static const struct qcom_reset_map gcc_sdm845_resets[] = {
diff --git a/drivers/clk/qcom/lpasscc-sdm845.c 
b/drivers/clk/qcom/lpasscc-sdm845.c
new file mode 100644
index 000..9c63542
--- /dev/null
+++ b/drivers/clk/qcom/lpasscc-sdm845.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "clk-regmap.h"
+#include "clk-branch.h"
+#include "common.h"
+
+static struct clk_branch lpass_q6ss_ahbm_aon_clk = {
+   .halt_reg = 0x12000,
+   .halt_check = BRANCH_VOTED,
+   .clkr = {
+   .enable_reg = 0x12000,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "lpass_q6ss_ahbm_aon_clk",
+   .ops = _branch2_ops,
+   },
+   },
+};
+
+static struct clk_branch lpass_q6ss_ahbs_aon_clk = {
+   .halt_reg = 0x1f000,
+   .halt_check = BRANCH_VOTED,
+   .clkr = {
+   .enable_reg = 0x1f000,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = 

[PATCH v10 2/3] dt-bindings: clock: Introduce QCOM LPASS clock bindings

2018-11-21 Thread Taniya Das
Add device tree bindings for Low Power Audio subsystem clock controller for
Qualcomm Technology Inc's SDM845 SoCs.

Signed-off-by: Taniya Das 
---
 .../devicetree/bindings/clock/qcom,gcc.txt |  4 +++-
 .../devicetree/bindings/clock/qcom,lpasscc.txt | 26 ++
 include/dt-bindings/clock/qcom,gcc-sdm845.h|  2 ++
 include/dt-bindings/clock/qcom,lpass-sdm845.h  | 15 +
 4 files changed, 46 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,lpasscc.txt
 create mode 100644 include/dt-bindings/clock/qcom,lpass-sdm845.h

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt 
b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index 5e37de9..8661c3c 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -67,5 +67,7 @@ Example of GCC with protected-clocks properties:
#power-domain-cells = <1>;
protected-clocks = ,
   ,
-  ;
+  ,
+  ,
+  ;
};
diff --git a/Documentation/devicetree/bindings/clock/qcom,lpasscc.txt 
b/Documentation/devicetree/bindings/clock/qcom,lpasscc.txt
new file mode 100644
index 000..b9e9787
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,lpasscc.txt
@@ -0,0 +1,26 @@
+Qualcomm LPASS Clock Controller Binding
+---
+
+Required properties :
+- compatible   : shall contain "qcom,sdm845-lpasscc"
+- #clock-cells : from common clock binding, shall contain 1.
+- reg  : shall contain base register address and size,
+ in the order
+   Index-0 maps to LPASS_CC register region
+   Index-1 maps to LPASS_QDSP6SS register region
+
+Optional properties :
+- reg-names: register names of LPASS domain
+"cc", "qdsp6ss".
+
+Example:
+
+The below node has to be defined in the cases where the LPASS peripheral loader
+would bring the subsystem out of reset.
+
+   lpasscc: clock-controller@17014000 {
+   compatible = "qcom,sdm845-lpasscc";
+   reg = <0x17014000 0x1f004>, <0x1730 0x200>;
+   reg-names = "cc", "qdsp6ss";
+   #clock-cells = <1>;
+   };
diff --git a/include/dt-bindings/clock/qcom,gcc-sdm845.h 
b/include/dt-bindings/clock/qcom,gcc-sdm845.h
index b8eae5a..968fa65 100644
--- a/include/dt-bindings/clock/qcom,gcc-sdm845.h
+++ b/include/dt-bindings/clock/qcom,gcc-sdm845.h
@@ -197,6 +197,8 @@
 #define GCC_QSPI_CORE_CLK_SRC  187
 #define GCC_QSPI_CORE_CLK  188
 #define GCC_QSPI_CNOC_PERIPH_AHB_CLK   189
+#define GCC_LPASS_Q6_AXI_CLK   190
+#define GCC_LPASS_SWAY_CLK 191

 /* GCC Resets */
 #define GCC_MMSS_BCR   0
diff --git a/include/dt-bindings/clock/qcom,lpass-sdm845.h 
b/include/dt-bindings/clock/qcom,lpass-sdm845.h
new file mode 100644
index 000..6590508
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,lpass-sdm845.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _DT_BINDINGS_CLK_SDM_LPASS_SDM845_H
+#define _DT_BINDINGS_CLK_SDM_LPASS_SDM845_H
+
+#define LPASS_Q6SS_AHBM_AON_CLK0
+#define LPASS_Q6SS_AHBS_AON_CLK1
+#define LPASS_QDSP6SS_XO_CLK   2
+#define LPASS_QDSP6SS_SLEEP_CLK3
+#define LPASS_QDSP6SS_CORE_CLK 4
+
+#endif
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the  Linux Foundation.



[PATCH v10 2/3] dt-bindings: clock: Introduce QCOM LPASS clock bindings

2018-11-21 Thread Taniya Das
Add device tree bindings for Low Power Audio subsystem clock controller for
Qualcomm Technology Inc's SDM845 SoCs.

Signed-off-by: Taniya Das 
---
 .../devicetree/bindings/clock/qcom,gcc.txt |  4 +++-
 .../devicetree/bindings/clock/qcom,lpasscc.txt | 26 ++
 include/dt-bindings/clock/qcom,gcc-sdm845.h|  2 ++
 include/dt-bindings/clock/qcom,lpass-sdm845.h  | 15 +
 4 files changed, 46 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,lpasscc.txt
 create mode 100644 include/dt-bindings/clock/qcom,lpass-sdm845.h

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt 
b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index 5e37de9..8661c3c 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -67,5 +67,7 @@ Example of GCC with protected-clocks properties:
#power-domain-cells = <1>;
protected-clocks = ,
   ,
-  ;
+  ,
+  ,
+  ;
};
diff --git a/Documentation/devicetree/bindings/clock/qcom,lpasscc.txt 
b/Documentation/devicetree/bindings/clock/qcom,lpasscc.txt
new file mode 100644
index 000..b9e9787
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,lpasscc.txt
@@ -0,0 +1,26 @@
+Qualcomm LPASS Clock Controller Binding
+---
+
+Required properties :
+- compatible   : shall contain "qcom,sdm845-lpasscc"
+- #clock-cells : from common clock binding, shall contain 1.
+- reg  : shall contain base register address and size,
+ in the order
+   Index-0 maps to LPASS_CC register region
+   Index-1 maps to LPASS_QDSP6SS register region
+
+Optional properties :
+- reg-names: register names of LPASS domain
+"cc", "qdsp6ss".
+
+Example:
+
+The below node has to be defined in the cases where the LPASS peripheral loader
+would bring the subsystem out of reset.
+
+   lpasscc: clock-controller@17014000 {
+   compatible = "qcom,sdm845-lpasscc";
+   reg = <0x17014000 0x1f004>, <0x1730 0x200>;
+   reg-names = "cc", "qdsp6ss";
+   #clock-cells = <1>;
+   };
diff --git a/include/dt-bindings/clock/qcom,gcc-sdm845.h 
b/include/dt-bindings/clock/qcom,gcc-sdm845.h
index b8eae5a..968fa65 100644
--- a/include/dt-bindings/clock/qcom,gcc-sdm845.h
+++ b/include/dt-bindings/clock/qcom,gcc-sdm845.h
@@ -197,6 +197,8 @@
 #define GCC_QSPI_CORE_CLK_SRC  187
 #define GCC_QSPI_CORE_CLK  188
 #define GCC_QSPI_CNOC_PERIPH_AHB_CLK   189
+#define GCC_LPASS_Q6_AXI_CLK   190
+#define GCC_LPASS_SWAY_CLK 191

 /* GCC Resets */
 #define GCC_MMSS_BCR   0
diff --git a/include/dt-bindings/clock/qcom,lpass-sdm845.h 
b/include/dt-bindings/clock/qcom,lpass-sdm845.h
new file mode 100644
index 000..6590508
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,lpass-sdm845.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _DT_BINDINGS_CLK_SDM_LPASS_SDM845_H
+#define _DT_BINDINGS_CLK_SDM_LPASS_SDM845_H
+
+#define LPASS_Q6SS_AHBM_AON_CLK0
+#define LPASS_Q6SS_AHBS_AON_CLK1
+#define LPASS_QDSP6SS_XO_CLK   2
+#define LPASS_QDSP6SS_SLEEP_CLK3
+#define LPASS_QDSP6SS_CORE_CLK 4
+
+#endif
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the  Linux Foundation.



[PATCH] soc/tegra: Fix terminating condition

2018-11-21 Thread Nathan Chancellor
Clang warns:

drivers/soc/tegra/common.c:27:16: error: address of array
'match->compatible' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
while (match->compatible) {
~  ~~~^~
1 error generated.

Whoops, we have an infinite loop and QEMU no longer boots...

https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/160242918

Check that the first character of the string isn't null so that the loop
properly terminates.

Fixes: c57eff9503a5 ("soc/tegra: refactor soc_is_tegra()")
Signed-off-by: Nathan Chancellor 
---
 drivers/soc/tegra/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/tegra/common.c b/drivers/soc/tegra/common.c
index 8a538b968fe9..54627ca957e8 100644
--- a/drivers/soc/tegra/common.c
+++ b/drivers/soc/tegra/common.c
@@ -24,7 +24,7 @@ bool soc_is_tegra(void)
 {
const struct of_device_id *match = tegra_machine_match;
 
-   while (match->compatible) {
+   while (match->compatible[0]) {
if (of_machine_is_compatible(match->compatible))
return true;
 
-- 
2.20.0.rc1



[PATCH] soc/tegra: Fix terminating condition

2018-11-21 Thread Nathan Chancellor
Clang warns:

drivers/soc/tegra/common.c:27:16: error: address of array
'match->compatible' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
while (match->compatible) {
~  ~~~^~
1 error generated.

Whoops, we have an infinite loop and QEMU no longer boots...

https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/160242918

Check that the first character of the string isn't null so that the loop
properly terminates.

Fixes: c57eff9503a5 ("soc/tegra: refactor soc_is_tegra()")
Signed-off-by: Nathan Chancellor 
---
 drivers/soc/tegra/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/tegra/common.c b/drivers/soc/tegra/common.c
index 8a538b968fe9..54627ca957e8 100644
--- a/drivers/soc/tegra/common.c
+++ b/drivers/soc/tegra/common.c
@@ -24,7 +24,7 @@ bool soc_is_tegra(void)
 {
const struct of_device_id *match = tegra_machine_match;
 
-   while (match->compatible) {
+   while (match->compatible[0]) {
if (of_machine_is_compatible(match->compatible))
return true;
 
-- 
2.20.0.rc1



Re: [PATCH v9 1/2] dt-bindings: clock: Introduce QCOM LPASS clock bindings

2018-11-21 Thread Taniya Das

Hello Rob,

On 11/13/2018 5:49 AM, Rob Herring wrote:

On Sat, Nov 10, 2018 at 07:14:15AM +0530, Taniya Das wrote:

Add device tree bindings for Low Power Audio subsystem clock controller for
Qualcomm Technology Inc's SDM845 SoCs.

Signed-off-by: Taniya Das 
---
  .../devicetree/bindings/clock/qcom,gcc.txt | 16 +


Seems like a separate change?



Sure, would spilt it in the next patch.


  .../devicetree/bindings/clock/qcom,lpasscc.txt | 26 ++
  include/dt-bindings/clock/qcom,gcc-sdm845.h|  2 ++
  include/dt-bindings/clock/qcom,lpass-sdm845.h  | 16 +
  4 files changed, 60 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/clock/qcom,lpasscc.txt
  create mode 100644 include/dt-bindings/clock/qcom,lpass-sdm845.h

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt 
b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index 52d9345..8661c3c 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -35,6 +35,8 @@ be part of GCC and hence the TSENS properties can also be
  part of the GCC/clock-controller node.
  For more details on the TSENS properties please refer
  Documentation/devicetree/bindings/thermal/qcom-tsens.txt
+- protected-clocks : Protected clock specifier list as per common clock
+ binding.

  Example:
clock-controller@90 {
@@ -55,3 +57,17 @@ Example of GCC with TSENS properties:
#reset-cells = <1>;
#thermal-sensor-cells = <1>;
};
+
+Example of GCC with protected-clocks properties:
+   clock-controller@10 {
+   compatible = "qcom,gcc-sdm845";
+   reg = <0x10 0x1f>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   #power-domain-cells = <1>;
+   protected-clocks = ,
+  ,
+  ,
+  ,
+  ;
+   };
diff --git a/Documentation/devicetree/bindings/clock/qcom,lpasscc.txt 
b/Documentation/devicetree/bindings/clock/qcom,lpasscc.txt
new file mode 100644
index 000..b9e9787
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,lpasscc.txt
@@ -0,0 +1,26 @@
+Qualcomm LPASS Clock Controller Binding
+---
+
+Required properties :
+- compatible   : shall contain "qcom,sdm845-lpasscc"
+- #clock-cells : from common clock binding, shall contain 1.
+- reg  : shall contain base register address and size,
+ in the order
+   Index-0 maps to LPASS_CC register region
+   Index-1 maps to LPASS_QDSP6SS register region


No input clocks?



There are no input clocks required.


+
+Optional properties :
+- reg-names: register names of LPASS domain
+"cc", "qdsp6ss".
+
+Example:
+
+The below node has to be defined in the cases where the LPASS peripheral loader
+would bring the subsystem out of reset.
+
+   lpasscc: clock-controller@17014000 {
+   compatible = "qcom,sdm845-lpasscc";
+   reg = <0x17014000 0x1f004>, <0x1730 0x200>;
+   reg-names = "cc", "qdsp6ss";
+   #clock-cells = <1>;
+   };
diff --git a/include/dt-bindings/clock/qcom,gcc-sdm845.h 
b/include/dt-bindings/clock/qcom,gcc-sdm845.h
index b8eae5a..968fa65 100644
--- a/include/dt-bindings/clock/qcom,gcc-sdm845.h
+++ b/include/dt-bindings/clock/qcom,gcc-sdm845.h
@@ -197,6 +197,8 @@
  #define GCC_QSPI_CORE_CLK_SRC 187
  #define GCC_QSPI_CORE_CLK 188
  #define GCC_QSPI_CNOC_PERIPH_AHB_CLK  189
+#define GCC_LPASS_Q6_AXI_CLK   190
+#define GCC_LPASS_SWAY_CLK 191

  /* GCC Resets */
  #define GCC_MMSS_BCR  0
diff --git a/include/dt-bindings/clock/qcom,lpass-sdm845.h 
b/include/dt-bindings/clock/qcom,lpass-sdm845.h
new file mode 100644
index 000..015968e
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,lpass-sdm845.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _DT_BINDINGS_CLK_SDM_LPASS_SDM845_H
+#define _DT_BINDINGS_CLK_SDM_LPASS_SDM845_H
+
+#define LPASS_AUDIO_WRAPPER_AON_CLK0
+#define LPASS_Q6SS_AHBM_AON_CLK1
+#define LPASS_Q6SS_AHBS_AON_CLK2
+#define LPASS_QDSP6SS_XO_CLK   3
+#define LPASS_QDSP6SS_SLEEP_CLK4
+#define LPASS_QDSP6SS_CORE_CLK 5
+
+#endif
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code 

Re: [PATCH v9 1/2] dt-bindings: clock: Introduce QCOM LPASS clock bindings

2018-11-21 Thread Taniya Das

Hello Rob,

On 11/13/2018 5:49 AM, Rob Herring wrote:

On Sat, Nov 10, 2018 at 07:14:15AM +0530, Taniya Das wrote:

Add device tree bindings for Low Power Audio subsystem clock controller for
Qualcomm Technology Inc's SDM845 SoCs.

Signed-off-by: Taniya Das 
---
  .../devicetree/bindings/clock/qcom,gcc.txt | 16 +


Seems like a separate change?



Sure, would spilt it in the next patch.


  .../devicetree/bindings/clock/qcom,lpasscc.txt | 26 ++
  include/dt-bindings/clock/qcom,gcc-sdm845.h|  2 ++
  include/dt-bindings/clock/qcom,lpass-sdm845.h  | 16 +
  4 files changed, 60 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/clock/qcom,lpasscc.txt
  create mode 100644 include/dt-bindings/clock/qcom,lpass-sdm845.h

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt 
b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index 52d9345..8661c3c 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -35,6 +35,8 @@ be part of GCC and hence the TSENS properties can also be
  part of the GCC/clock-controller node.
  For more details on the TSENS properties please refer
  Documentation/devicetree/bindings/thermal/qcom-tsens.txt
+- protected-clocks : Protected clock specifier list as per common clock
+ binding.

  Example:
clock-controller@90 {
@@ -55,3 +57,17 @@ Example of GCC with TSENS properties:
#reset-cells = <1>;
#thermal-sensor-cells = <1>;
};
+
+Example of GCC with protected-clocks properties:
+   clock-controller@10 {
+   compatible = "qcom,gcc-sdm845";
+   reg = <0x10 0x1f>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   #power-domain-cells = <1>;
+   protected-clocks = ,
+  ,
+  ,
+  ,
+  ;
+   };
diff --git a/Documentation/devicetree/bindings/clock/qcom,lpasscc.txt 
b/Documentation/devicetree/bindings/clock/qcom,lpasscc.txt
new file mode 100644
index 000..b9e9787
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,lpasscc.txt
@@ -0,0 +1,26 @@
+Qualcomm LPASS Clock Controller Binding
+---
+
+Required properties :
+- compatible   : shall contain "qcom,sdm845-lpasscc"
+- #clock-cells : from common clock binding, shall contain 1.
+- reg  : shall contain base register address and size,
+ in the order
+   Index-0 maps to LPASS_CC register region
+   Index-1 maps to LPASS_QDSP6SS register region


No input clocks?



There are no input clocks required.


+
+Optional properties :
+- reg-names: register names of LPASS domain
+"cc", "qdsp6ss".
+
+Example:
+
+The below node has to be defined in the cases where the LPASS peripheral loader
+would bring the subsystem out of reset.
+
+   lpasscc: clock-controller@17014000 {
+   compatible = "qcom,sdm845-lpasscc";
+   reg = <0x17014000 0x1f004>, <0x1730 0x200>;
+   reg-names = "cc", "qdsp6ss";
+   #clock-cells = <1>;
+   };
diff --git a/include/dt-bindings/clock/qcom,gcc-sdm845.h 
b/include/dt-bindings/clock/qcom,gcc-sdm845.h
index b8eae5a..968fa65 100644
--- a/include/dt-bindings/clock/qcom,gcc-sdm845.h
+++ b/include/dt-bindings/clock/qcom,gcc-sdm845.h
@@ -197,6 +197,8 @@
  #define GCC_QSPI_CORE_CLK_SRC 187
  #define GCC_QSPI_CORE_CLK 188
  #define GCC_QSPI_CNOC_PERIPH_AHB_CLK  189
+#define GCC_LPASS_Q6_AXI_CLK   190
+#define GCC_LPASS_SWAY_CLK 191

  /* GCC Resets */
  #define GCC_MMSS_BCR  0
diff --git a/include/dt-bindings/clock/qcom,lpass-sdm845.h 
b/include/dt-bindings/clock/qcom,lpass-sdm845.h
new file mode 100644
index 000..015968e
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,lpass-sdm845.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _DT_BINDINGS_CLK_SDM_LPASS_SDM845_H
+#define _DT_BINDINGS_CLK_SDM_LPASS_SDM845_H
+
+#define LPASS_AUDIO_WRAPPER_AON_CLK0
+#define LPASS_Q6SS_AHBM_AON_CLK1
+#define LPASS_Q6SS_AHBS_AON_CLK2
+#define LPASS_QDSP6SS_XO_CLK   3
+#define LPASS_QDSP6SS_SLEEP_CLK4
+#define LPASS_QDSP6SS_CORE_CLK 5
+
+#endif
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code 

Re: [patch 17/24] x86/speculation: Move IBPB control out of switch_mm()

2018-11-21 Thread Ingo Molnar


* Thomas Gleixner  wrote:

> IBPB control is currently in switch_mm() to avoid issuing IBPB when
> switching between tasks of the same process.
> 
> But that's not covering the case of sandboxed tasks which get the
> TIF_SPEC_IB flag set via seccomp. There the barrier is required when the
> potentially malicious task is switched out because the task which is
> switched in might have it not set and would still be attackable.
> 
> For tasks which mark themself with TIF_SPEC_IB via the prctl, the barrier
> needs to be when the tasks switches in because the previous one might be an
> attacker.

s/themself
 /themselves
> 
> Move the code out of switch_mm() and evaluate the TIF bit in
> switch_to(). Make it an inline function so it can be used both in 32bit and
> 64bit code.

s/32bit
 /32-bit

s/64bit
 /64-bit

> 
> This loses the optimization of switching back to the same process, but
> that's wrong in the context of seccomp anyway as it does not protect tasks
> of the same process against each other.
> 
> This could be optimized by keeping track of the last user task per cpu and
> avoiding the barrier when the task is immediately scheduled back and the
> thread inbetween was a kernel thread. It's dubious whether that'd be worth
> the extra load/store and conditional operations. Keep it optimized for the
> common case where the TIF bit is not set.

s/cpu/CPU

> 
> Signed-off-by: Thomas Gleixner 
> ---
>  arch/x86/include/asm/nospec-branch.h |2 +
>  arch/x86/include/asm/spec-ctrl.h |   46 
> +++
>  arch/x86/include/asm/tlbflush.h  |2 -
>  arch/x86/kernel/cpu/bugs.c   |   16 +++-
>  arch/x86/kernel/process_32.c |   11 ++--
>  arch/x86/kernel/process_64.c |   11 ++--
>  arch/x86/mm/tlb.c|   39 -
>  7 files changed, 81 insertions(+), 46 deletions(-)
> 
> --- a/arch/x86/include/asm/nospec-branch.h
> +++ b/arch/x86/include/asm/nospec-branch.h
> @@ -312,6 +312,8 @@ do {  
> \
>  } while (0)
>  
>  DECLARE_STATIC_KEY_FALSE(switch_to_cond_stibp);
> +DECLARE_STATIC_KEY_FALSE(switch_to_cond_ibpb);
> +DECLARE_STATIC_KEY_FALSE(switch_to_always_ibpb);
>  
>  #endif /* __ASSEMBLY__ */
>  
> --- a/arch/x86/include/asm/spec-ctrl.h
> +++ b/arch/x86/include/asm/spec-ctrl.h
> @@ -76,6 +76,52 @@ static inline u64 ssbd_tif_to_amd_ls_cfg
>   return (tifn & _TIF_SSBD) ? x86_amd_ls_cfg_ssbd_mask : 0ULL;
>  }
>  
> +/**
> + * switch_to_ibpb - Issue IBPB on task switch
> + * @next:Pointer to the next task
> + * @prev_tif:Threadinfo flags of the previous task
> + * @next_tif:Threadinfo flags of the next task
> + *
> + * IBPB flushes the branch predictor, which stops Spectre-v2 attacks
> + * between user space tasks. Depending on the mode the flush is made
> + * conditional.
> + */
> +static inline void switch_to_ibpb(struct task_struct *next,
> +   unsigned long prev_tif,
> +   unsigned long next_tif)
> +{
> + if (static_branch_unlikely(_to_always_ibpb)) {
> + /* Only flush when switching to a user task. */
> + if (next->mm)
> + indirect_branch_prediction_barrier();
> + }
> +
> + if (static_branch_unlikely(_to_cond_ibpb)) {
> + /*
> +  * Both tasks' threadinfo flags are checked for TIF_SPEC_IB.
> +  *
> +  * For an outgoing sandboxed task which has TIF_SPEC_IB set
> +  * via seccomp this is needed because it might be malicious
> +  * and the next user task switching in might not have it
> +  * set.
> +  *
> +  * For an incoming task which has set TIF_SPEC_IB itself
> +  * via prctl() this is needed because the previous user
> +  * task might be malicious and have the flag unset.
> +  *
> +  * This could be optimized by keeping track of the last
> +  * user task per cpu and avoiding the barrier when the task
> +  * is immediately scheduled back and the thread inbetween
> +  * was a kernel thread. It's dubious whether that'd be
> +  * worth the extra load/store and conditional operations.
> +  * Keep it optimized for the common case where the TIF bit
> +  * is not set.
> +  */
> + if ((prev_tif | next_tif) & _TIF_SPEC_IB)
> + indirect_branch_prediction_barrier();

s/cpu/CPU

> +
> + switch (mode) {
> + case SPECTRE_V2_APP2APP_STRICT:
> + static_branch_enable(_to_always_ibpb);
> + break;
> + default:
> + break;
> + }
> +
> + pr_info("mitigation: Enabling %s Indirect Branch Prediction 
> Barrier\n",
> +

Re: [patch 17/24] x86/speculation: Move IBPB control out of switch_mm()

2018-11-21 Thread Ingo Molnar


* Thomas Gleixner  wrote:

> IBPB control is currently in switch_mm() to avoid issuing IBPB when
> switching between tasks of the same process.
> 
> But that's not covering the case of sandboxed tasks which get the
> TIF_SPEC_IB flag set via seccomp. There the barrier is required when the
> potentially malicious task is switched out because the task which is
> switched in might have it not set and would still be attackable.
> 
> For tasks which mark themself with TIF_SPEC_IB via the prctl, the barrier
> needs to be when the tasks switches in because the previous one might be an
> attacker.

s/themself
 /themselves
> 
> Move the code out of switch_mm() and evaluate the TIF bit in
> switch_to(). Make it an inline function so it can be used both in 32bit and
> 64bit code.

s/32bit
 /32-bit

s/64bit
 /64-bit

> 
> This loses the optimization of switching back to the same process, but
> that's wrong in the context of seccomp anyway as it does not protect tasks
> of the same process against each other.
> 
> This could be optimized by keeping track of the last user task per cpu and
> avoiding the barrier when the task is immediately scheduled back and the
> thread inbetween was a kernel thread. It's dubious whether that'd be worth
> the extra load/store and conditional operations. Keep it optimized for the
> common case where the TIF bit is not set.

s/cpu/CPU

> 
> Signed-off-by: Thomas Gleixner 
> ---
>  arch/x86/include/asm/nospec-branch.h |2 +
>  arch/x86/include/asm/spec-ctrl.h |   46 
> +++
>  arch/x86/include/asm/tlbflush.h  |2 -
>  arch/x86/kernel/cpu/bugs.c   |   16 +++-
>  arch/x86/kernel/process_32.c |   11 ++--
>  arch/x86/kernel/process_64.c |   11 ++--
>  arch/x86/mm/tlb.c|   39 -
>  7 files changed, 81 insertions(+), 46 deletions(-)
> 
> --- a/arch/x86/include/asm/nospec-branch.h
> +++ b/arch/x86/include/asm/nospec-branch.h
> @@ -312,6 +312,8 @@ do {  
> \
>  } while (0)
>  
>  DECLARE_STATIC_KEY_FALSE(switch_to_cond_stibp);
> +DECLARE_STATIC_KEY_FALSE(switch_to_cond_ibpb);
> +DECLARE_STATIC_KEY_FALSE(switch_to_always_ibpb);
>  
>  #endif /* __ASSEMBLY__ */
>  
> --- a/arch/x86/include/asm/spec-ctrl.h
> +++ b/arch/x86/include/asm/spec-ctrl.h
> @@ -76,6 +76,52 @@ static inline u64 ssbd_tif_to_amd_ls_cfg
>   return (tifn & _TIF_SSBD) ? x86_amd_ls_cfg_ssbd_mask : 0ULL;
>  }
>  
> +/**
> + * switch_to_ibpb - Issue IBPB on task switch
> + * @next:Pointer to the next task
> + * @prev_tif:Threadinfo flags of the previous task
> + * @next_tif:Threadinfo flags of the next task
> + *
> + * IBPB flushes the branch predictor, which stops Spectre-v2 attacks
> + * between user space tasks. Depending on the mode the flush is made
> + * conditional.
> + */
> +static inline void switch_to_ibpb(struct task_struct *next,
> +   unsigned long prev_tif,
> +   unsigned long next_tif)
> +{
> + if (static_branch_unlikely(_to_always_ibpb)) {
> + /* Only flush when switching to a user task. */
> + if (next->mm)
> + indirect_branch_prediction_barrier();
> + }
> +
> + if (static_branch_unlikely(_to_cond_ibpb)) {
> + /*
> +  * Both tasks' threadinfo flags are checked for TIF_SPEC_IB.
> +  *
> +  * For an outgoing sandboxed task which has TIF_SPEC_IB set
> +  * via seccomp this is needed because it might be malicious
> +  * and the next user task switching in might not have it
> +  * set.
> +  *
> +  * For an incoming task which has set TIF_SPEC_IB itself
> +  * via prctl() this is needed because the previous user
> +  * task might be malicious and have the flag unset.
> +  *
> +  * This could be optimized by keeping track of the last
> +  * user task per cpu and avoiding the barrier when the task
> +  * is immediately scheduled back and the thread inbetween
> +  * was a kernel thread. It's dubious whether that'd be
> +  * worth the extra load/store and conditional operations.
> +  * Keep it optimized for the common case where the TIF bit
> +  * is not set.
> +  */
> + if ((prev_tif | next_tif) & _TIF_SPEC_IB)
> + indirect_branch_prediction_barrier();

s/cpu/CPU

> +
> + switch (mode) {
> + case SPECTRE_V2_APP2APP_STRICT:
> + static_branch_enable(_to_always_ibpb);
> + break;
> + default:
> + break;
> + }
> +
> + pr_info("mitigation: Enabling %s Indirect Branch Prediction 
> Barrier\n",
> +

Re: [PATCH v9 2/2] clk: qcom: Add lpass clock controller driver for SDM845

2018-11-21 Thread Taniya Das

Hello Stephen,

On 11/22/2018 12:37 AM, Stephen Boyd wrote:

Quoting Taniya Das (2018-11-09 17:44:16)

diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
index f133b7f..ba8ff99 100644
--- a/drivers/clk/qcom/gcc-sdm845.c
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -3153,6 +3153,34 @@ enum {
 },
  };

+static struct clk_branch gcc_lpass_q6_axi_clk = {
+   .halt_reg = 0x47000,
+   .halt_check = BRANCH_HALT,
+   .clkr = {
+   .enable_reg = 0x47000,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "gcc_lpass_q6_axi_clk",
+   .flags = CLK_IS_CRITICAL,
+   .ops = _branch2_ops,
+   },
+   },
+};
+
+static struct clk_branch gcc_lpass_sway_clk = {
+   .halt_reg = 0x47008,
+   .halt_check = BRANCH_HALT,
+   .clkr = {
+   .enable_reg = 0x47008,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "gcc_lpass_sway_clk",
+   .flags = CLK_IS_CRITICAL,
+   .ops = _branch2_ops,
+   },
+   },
+};
+
  static struct gdsc pcie_0_gdsc = {
 .gdscr = 0x6b004,
 .pd = {
@@ -3453,6 +3481,8 @@ enum {
 [GCC_QSPI_CORE_CLK_SRC] = _qspi_core_clk_src.clkr,
 [GCC_QSPI_CORE_CLK] = _qspi_core_clk.clkr,
 [GCC_QSPI_CNOC_PERIPH_AHB_CLK] = _qspi_cnoc_periph_ahb_clk.clkr,
+   [GCC_LPASS_Q6_AXI_CLK] = _lpass_q6_axi_clk.clkr,
+   [GCC_LPASS_SWAY_CLK] = _lpass_sway_clk.clkr,


Sigh, more coordination with sdm845 mtp problems here due to the
clks being protected by firmware. I guess I can just merge this and the
mtp dts bits will land in Andy's tree during the same merge window? Or I
may need to take the dts bits for this into clk tree so that the broken
time is only between two commits.


  };

  static const struct qcom_reset_map gcc_sdm845_resets[] = {
diff --git a/drivers/clk/qcom/lpasscc-sdm845.c 
b/drivers/clk/qcom/lpasscc-sdm845.c
new file mode 100644
index 000..2ef7f2a
--- /dev/null
+++ b/drivers/clk/qcom/lpasscc-sdm845.c
@@ -0,0 +1,192 @@

[...]

+
+static const struct of_device_id lpass_cc_sdm845_match_table[] = {
+   { .compatible = "qcom,sdm845-lpasscc" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, lpass_cc_sdm845_match_table);


Move this down to the before the driver structure please.



Would do it in the next patch.


+
+static int lpass_cc_sdm845_probe(struct platform_device *pdev)
+{
+   const struct qcom_cc_desc *desc;
+   int ret;
+
+   lpass_regmap_config.name = "cc";
+   desc = _cc_sdm845_desc;
+
+   ret = lpass_clocks_sdm845_probe(pdev, 0, desc);
+   if (ret)
+   return ret;
+
+   lpass_regmap_config.name = "qdsp6ss";
+   desc = _qdsp6ss_sdm845_desc;
+
+   return lpass_clocks_sdm845_probe(pdev, 1, desc);
+}
+
+static struct platform_driver lpass_cc_sdm845_driver = {
+   .probe  = lpass_cc_sdm845_probe,
+   .driver = {
+   .name   = "sdm845-lpasscc",
+   .of_match_table = lpass_cc_sdm845_match_table,
+   },
+};
+
+static int __init lpass_cc_sdm845_init(void)
+{
+   return platform_driver_register(_cc_sdm845_driver);
+}
+subsys_initcall(lpass_cc_sdm845_init);
+
+static void __exit lpass_cc_sdm845_exit(void)
+{
+   platform_driver_unregister(_cc_sdm845_driver);
+}
+module_exit(lpass_cc_sdm845_exit);
+
+MODULE_LICENSE("GPL v2");


MODULE_DESCRIPTION?


Would add it in the next patch.

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--


Re: [PATCH v9 2/2] clk: qcom: Add lpass clock controller driver for SDM845

2018-11-21 Thread Taniya Das

Hello Stephen,

On 11/22/2018 12:37 AM, Stephen Boyd wrote:

Quoting Taniya Das (2018-11-09 17:44:16)

diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
index f133b7f..ba8ff99 100644
--- a/drivers/clk/qcom/gcc-sdm845.c
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -3153,6 +3153,34 @@ enum {
 },
  };

+static struct clk_branch gcc_lpass_q6_axi_clk = {
+   .halt_reg = 0x47000,
+   .halt_check = BRANCH_HALT,
+   .clkr = {
+   .enable_reg = 0x47000,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "gcc_lpass_q6_axi_clk",
+   .flags = CLK_IS_CRITICAL,
+   .ops = _branch2_ops,
+   },
+   },
+};
+
+static struct clk_branch gcc_lpass_sway_clk = {
+   .halt_reg = 0x47008,
+   .halt_check = BRANCH_HALT,
+   .clkr = {
+   .enable_reg = 0x47008,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "gcc_lpass_sway_clk",
+   .flags = CLK_IS_CRITICAL,
+   .ops = _branch2_ops,
+   },
+   },
+};
+
  static struct gdsc pcie_0_gdsc = {
 .gdscr = 0x6b004,
 .pd = {
@@ -3453,6 +3481,8 @@ enum {
 [GCC_QSPI_CORE_CLK_SRC] = _qspi_core_clk_src.clkr,
 [GCC_QSPI_CORE_CLK] = _qspi_core_clk.clkr,
 [GCC_QSPI_CNOC_PERIPH_AHB_CLK] = _qspi_cnoc_periph_ahb_clk.clkr,
+   [GCC_LPASS_Q6_AXI_CLK] = _lpass_q6_axi_clk.clkr,
+   [GCC_LPASS_SWAY_CLK] = _lpass_sway_clk.clkr,


Sigh, more coordination with sdm845 mtp problems here due to the
clks being protected by firmware. I guess I can just merge this and the
mtp dts bits will land in Andy's tree during the same merge window? Or I
may need to take the dts bits for this into clk tree so that the broken
time is only between two commits.


  };

  static const struct qcom_reset_map gcc_sdm845_resets[] = {
diff --git a/drivers/clk/qcom/lpasscc-sdm845.c 
b/drivers/clk/qcom/lpasscc-sdm845.c
new file mode 100644
index 000..2ef7f2a
--- /dev/null
+++ b/drivers/clk/qcom/lpasscc-sdm845.c
@@ -0,0 +1,192 @@

[...]

+
+static const struct of_device_id lpass_cc_sdm845_match_table[] = {
+   { .compatible = "qcom,sdm845-lpasscc" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, lpass_cc_sdm845_match_table);


Move this down to the before the driver structure please.



Would do it in the next patch.


+
+static int lpass_cc_sdm845_probe(struct platform_device *pdev)
+{
+   const struct qcom_cc_desc *desc;
+   int ret;
+
+   lpass_regmap_config.name = "cc";
+   desc = _cc_sdm845_desc;
+
+   ret = lpass_clocks_sdm845_probe(pdev, 0, desc);
+   if (ret)
+   return ret;
+
+   lpass_regmap_config.name = "qdsp6ss";
+   desc = _qdsp6ss_sdm845_desc;
+
+   return lpass_clocks_sdm845_probe(pdev, 1, desc);
+}
+
+static struct platform_driver lpass_cc_sdm845_driver = {
+   .probe  = lpass_cc_sdm845_probe,
+   .driver = {
+   .name   = "sdm845-lpasscc",
+   .of_match_table = lpass_cc_sdm845_match_table,
+   },
+};
+
+static int __init lpass_cc_sdm845_init(void)
+{
+   return platform_driver_register(_cc_sdm845_driver);
+}
+subsys_initcall(lpass_cc_sdm845_init);
+
+static void __exit lpass_cc_sdm845_exit(void)
+{
+   platform_driver_unregister(_cc_sdm845_driver);
+}
+module_exit(lpass_cc_sdm845_exit);
+
+MODULE_LICENSE("GPL v2");


MODULE_DESCRIPTION?


Would add it in the next patch.

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--


Re: [PATCH] mm/gup: finish consolidating error handling

2018-11-21 Thread John Hubbard
On 11/21/18 2:44 PM, Andrew Morton wrote:
> On Wed, 21 Nov 2018 00:14:02 -0800 john.hubb...@gmail.com wrote:
> 
>> Commit df06b37ffe5a4 ("mm/gup: cache dev_pagemap while pinning pages")
>> attempted to operate on each page that get_user_pages had retrieved. In
>> order to do that, it created a common exit point from the routine.
>> However, one case was missed, which this patch fixes up.
>>
>> Also, there was still an unnecessary shadow declaration (with a
>> different type) of the "ret" variable, which this patch removes.
>>
> 
> What is the bug which this supposedly fixes and what is that bug's
> user-visible impact?
> 

Keith's description of the situation is:

  This also fixes a potentially leaked dev_pagemap reference count if a
  failure occurs when an iteration crosses a vma boundary. I don't think
  it's normal to have different vma's on a users mapped zone device memory,
  but good to fix anyway.

I actually thought that this code:

/* first iteration or cross vma bound */
if (!vma || start >= vma->vm_end) {
vma = find_extend_vma(mm, start);
if (!vma && in_gate_area(mm, start)) {
ret = get_gate_page(mm, start & PAGE_MASK,
gup_flags, ,
pages ? [i] : NULL);
if (ret)
goto out;

...dealt with the "you're trying to pin the gate page, as part of this call",
rather than the generic case of crossing a vma boundary. (I think there's a fine
point that I must be overlooking.) But it's still a valid case, either way.

-- 
thanks,
John Hubbard
NVIDIA


Re: [PATCH] mm/gup: finish consolidating error handling

2018-11-21 Thread John Hubbard
On 11/21/18 2:44 PM, Andrew Morton wrote:
> On Wed, 21 Nov 2018 00:14:02 -0800 john.hubb...@gmail.com wrote:
> 
>> Commit df06b37ffe5a4 ("mm/gup: cache dev_pagemap while pinning pages")
>> attempted to operate on each page that get_user_pages had retrieved. In
>> order to do that, it created a common exit point from the routine.
>> However, one case was missed, which this patch fixes up.
>>
>> Also, there was still an unnecessary shadow declaration (with a
>> different type) of the "ret" variable, which this patch removes.
>>
> 
> What is the bug which this supposedly fixes and what is that bug's
> user-visible impact?
> 

Keith's description of the situation is:

  This also fixes a potentially leaked dev_pagemap reference count if a
  failure occurs when an iteration crosses a vma boundary. I don't think
  it's normal to have different vma's on a users mapped zone device memory,
  but good to fix anyway.

I actually thought that this code:

/* first iteration or cross vma bound */
if (!vma || start >= vma->vm_end) {
vma = find_extend_vma(mm, start);
if (!vma && in_gate_area(mm, start)) {
ret = get_gate_page(mm, start & PAGE_MASK,
gup_flags, ,
pages ? [i] : NULL);
if (ret)
goto out;

...dealt with the "you're trying to pin the gate page, as part of this call",
rather than the generic case of crossing a vma boundary. (I think there's a fine
point that I must be overlooking.) But it's still a valid case, either way.

-- 
thanks,
John Hubbard
NVIDIA


Re: [PATCH v1 2/2] signal: add procfd_signal() syscall

2018-11-21 Thread Serge E. Hallyn
On Mon, Nov 19, 2018 at 03:39:54PM -0700, Tycho Andersen wrote:
> On Mon, Nov 19, 2018 at 11:32:39AM +0100, Christian Brauner wrote:
> >
> > +/**
> > + *  sys_procfd_signal - send a signal to a process through a process file
> > + *  descriptor
> > + *  @fd: the file descriptor of the process
> > + *  @sig: signal to be sent
> > + *  @info: the signal info
> > + *  @flags: future flags to be passed
> > + */
> > +SYSCALL_DEFINE4(procfd_signal, int, fd, int, sig, siginfo_t __user *, info,
> > +   int, flags)
> > +{
> 
> Can I just register an objection here that I think using a syscall
> just for this is silly?
> 
> My understanding is that the concern is that some code might do:
> 
> unknown_fd = recv_fd();
> ioctl(unknown_fd, SOME_IOCTL, NULL); // where SOME_IOCTL == PROC_FD_KILL
> // whoops, unknown_fd was a procfd and we killed a task!

This could just be my own mental model, but for something like "kill a
task", an ioctl just seems wrong.  Syscall seems more natural.

I'd ack either method.

-serge


Re: [PATCH v1 2/2] signal: add procfd_signal() syscall

2018-11-21 Thread Serge E. Hallyn
On Mon, Nov 19, 2018 at 03:39:54PM -0700, Tycho Andersen wrote:
> On Mon, Nov 19, 2018 at 11:32:39AM +0100, Christian Brauner wrote:
> >
> > +/**
> > + *  sys_procfd_signal - send a signal to a process through a process file
> > + *  descriptor
> > + *  @fd: the file descriptor of the process
> > + *  @sig: signal to be sent
> > + *  @info: the signal info
> > + *  @flags: future flags to be passed
> > + */
> > +SYSCALL_DEFINE4(procfd_signal, int, fd, int, sig, siginfo_t __user *, info,
> > +   int, flags)
> > +{
> 
> Can I just register an objection here that I think using a syscall
> just for this is silly?
> 
> My understanding is that the concern is that some code might do:
> 
> unknown_fd = recv_fd();
> ioctl(unknown_fd, SOME_IOCTL, NULL); // where SOME_IOCTL == PROC_FD_KILL
> // whoops, unknown_fd was a procfd and we killed a task!

This could just be my own mental model, but for something like "kill a
task", an ioctl just seems wrong.  Syscall seems more natural.

I'd ack either method.

-serge


[RESEND PATCH] include: Add lantiq.h in include/linux/

2018-11-21 Thread Songjun Wu
In some existing lantiq driver, the C codes include lantiq_soc.h
header file directly.

./arch/mips/include/asm/mach-lantiq/falcon/lantiq_soc.h
./arch/mips/include/asm/mach-lantiq/xway/lantiq_soc.h

Those drivers need to be extended to support more platform.
lantiq.h is added in include/linux/ to make it
globally available and provides some wrapper codes.

Signed-off-by: Songjun Wu 
---

 include/linux/lantiq.h | 23 +++
 1 file changed, 23 insertions(+)
 create mode 100644 include/linux/lantiq.h

diff --git a/include/linux/lantiq.h b/include/linux/lantiq.h
new file mode 100644
index ..67921169d84d
--- /dev/null
+++ b/include/linux/lantiq.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __LINUX_LANTIQ_H
+#define __LINUX_LANTIQ_H
+
+#ifdef CONFIG_LANTIQ
+#include 
+#else
+
+#ifndef LTQ_EARLY_ASC
+#define LTQ_EARLY_ASC 0
+#endif
+
+#ifndef CPHYSADDR
+#define CPHYSADDR(a) 0
+#endif
+
+static inline struct clk *clk_get_fpi(void)
+{
+   return NULL;
+}
+#endif /* CONFIG_LANTIQ */
+#endif /* __LINUX_LANTIQ_H */
-- 
2.11.0



[RESEND PATCH] include: Add lantiq.h in include/linux/

2018-11-21 Thread Songjun Wu
In some existing lantiq driver, the C codes include lantiq_soc.h
header file directly.

./arch/mips/include/asm/mach-lantiq/falcon/lantiq_soc.h
./arch/mips/include/asm/mach-lantiq/xway/lantiq_soc.h

Those drivers need to be extended to support more platform.
lantiq.h is added in include/linux/ to make it
globally available and provides some wrapper codes.

Signed-off-by: Songjun Wu 
---

 include/linux/lantiq.h | 23 +++
 1 file changed, 23 insertions(+)
 create mode 100644 include/linux/lantiq.h

diff --git a/include/linux/lantiq.h b/include/linux/lantiq.h
new file mode 100644
index ..67921169d84d
--- /dev/null
+++ b/include/linux/lantiq.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __LINUX_LANTIQ_H
+#define __LINUX_LANTIQ_H
+
+#ifdef CONFIG_LANTIQ
+#include 
+#else
+
+#ifndef LTQ_EARLY_ASC
+#define LTQ_EARLY_ASC 0
+#endif
+
+#ifndef CPHYSADDR
+#define CPHYSADDR(a) 0
+#endif
+
+static inline struct clk *clk_get_fpi(void)
+{
+   return NULL;
+}
+#endif /* CONFIG_LANTIQ */
+#endif /* __LINUX_LANTIQ_H */
-- 
2.11.0



Re: [patch 18/24] x86/speculation: Avoid __switch_to_xtra() calls

2018-11-21 Thread Ingo Molnar


* Tim Chen  wrote:

> On 11/21/2018 12:14 PM, Thomas Gleixner wrote:
> 
> > +* Avoid __switch_to_xtra() invocation when conditional stpib is
> 
> s/stpib/stibp

and:

  s/stibp/STIBP

to make it consistent throughout the patchset.

Thanks,

Ingo


Re: [patch 18/24] x86/speculation: Avoid __switch_to_xtra() calls

2018-11-21 Thread Ingo Molnar


* Tim Chen  wrote:

> On 11/21/2018 12:14 PM, Thomas Gleixner wrote:
> 
> > +* Avoid __switch_to_xtra() invocation when conditional stpib is
> 
> s/stpib/stibp

and:

  s/stibp/STIBP

to make it consistent throughout the patchset.

Thanks,

Ingo


Re: [patch 20/24] x86/speculation: Split out TIF update

2018-11-21 Thread Ingo Molnar


* Thomas Gleixner  wrote:

> The update of the TIF_SSBD flag and the conditional speculation control MSR
> update is done in the ssb_prctl_set() function directly. The upcoming prctl
> support for controlling indirect branch speculation via STIBP needs the
> same mechanism.
> 
> Split the code out and make it reusable.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  arch/x86/kernel/cpu/bugs.c |   31 +++
>  1 file changed, 19 insertions(+), 12 deletions(-)
> 
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -703,10 +703,25 @@ static void ssb_select_mitigation(void)
>  #undef pr_fmt
>  #define pr_fmt(fmt) "Speculation prctl: " fmt
>  
> -static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
> +static void task_update_spec_tif(struct task_struct *tsk, int tifbit, bool 
> on)
>  {
>   bool update;
>  
> + if (on)
> + update = !test_and_set_tsk_thread_flag(tsk, tifbit);
> + else
> + update = test_and_clear_tsk_thread_flag(tsk, tifbit);
> +
> + /*
> +  * If being set on non-current task, delay setting the CPU
> +  * mitigation until it is scheduled next.
> +  */
> + if (tsk == current && update)
> + speculation_ctrl_update_current();

Had to read this twice, because the comment and the code are both correct 
but deal with the inverse case. This might have helped:

/*
 * Immediately update the speculation MSRs on the current task,
 * but for non-current tasks delay setting the CPU mitigation 
 * until it is scheduled next.
 */
if (tsk == current && update)
speculation_ctrl_update_current();

But can the target task ever be non-current here? I don't think so: the 
two callers are prctl and seccomp, and both are passing in the current 
task pointer.

If so then it would be nice to rename all these task variable names from 
'task' to 'curr' or such, to make this property apparent.

Then we can also remove the condition and the comment, and update 
unconditionally, and maybe add:

WARN_ON_ONCE(curr != current);

... or so?

Thanks,

Ingo


Re: [patch 20/24] x86/speculation: Split out TIF update

2018-11-21 Thread Ingo Molnar


* Thomas Gleixner  wrote:

> The update of the TIF_SSBD flag and the conditional speculation control MSR
> update is done in the ssb_prctl_set() function directly. The upcoming prctl
> support for controlling indirect branch speculation via STIBP needs the
> same mechanism.
> 
> Split the code out and make it reusable.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  arch/x86/kernel/cpu/bugs.c |   31 +++
>  1 file changed, 19 insertions(+), 12 deletions(-)
> 
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -703,10 +703,25 @@ static void ssb_select_mitigation(void)
>  #undef pr_fmt
>  #define pr_fmt(fmt) "Speculation prctl: " fmt
>  
> -static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
> +static void task_update_spec_tif(struct task_struct *tsk, int tifbit, bool 
> on)
>  {
>   bool update;
>  
> + if (on)
> + update = !test_and_set_tsk_thread_flag(tsk, tifbit);
> + else
> + update = test_and_clear_tsk_thread_flag(tsk, tifbit);
> +
> + /*
> +  * If being set on non-current task, delay setting the CPU
> +  * mitigation until it is scheduled next.
> +  */
> + if (tsk == current && update)
> + speculation_ctrl_update_current();

Had to read this twice, because the comment and the code are both correct 
but deal with the inverse case. This might have helped:

/*
 * Immediately update the speculation MSRs on the current task,
 * but for non-current tasks delay setting the CPU mitigation 
 * until it is scheduled next.
 */
if (tsk == current && update)
speculation_ctrl_update_current();

But can the target task ever be non-current here? I don't think so: the 
two callers are prctl and seccomp, and both are passing in the current 
task pointer.

If so then it would be nice to rename all these task variable names from 
'task' to 'curr' or such, to make this property apparent.

Then we can also remove the condition and the comment, and update 
unconditionally, and maybe add:

WARN_ON_ONCE(curr != current);

... or so?

Thanks,

Ingo


Re: [patch 17/24] x86/speculation: Move IBPB control out of switch_mm()

2018-11-21 Thread Jiri Kosina
On Wed, 21 Nov 2018, Andi Kleen wrote:

> > +* This could be optimized by keeping track of the last
> > +* user task per cpu and avoiding the barrier when the task
> > +* is immediately scheduled back and the thread inbetween
> > +* was a kernel thread. It's dubious whether that'd be
> > +* worth the extra load/store and conditional operations.
> > +* Keep it optimized for the common case where the TIF bit
> > +* is not set.
> > +*/
> 
> The optimization was there before and you removed it?
> 
> It's quite important for switching to idle and back. With your variant short 
> IOs
> that do short idle waits will be badly impacted. 

The question is what scenario to optimize for.

Either you penalize everybody in the default prctl+seccomp setup 
(irrespective of it's TIF flag value), as you have the extra overhead on 
each and every switch_to() (to check exactly for this back-to-back 
scheduling), or you penalize only those tasks that are penalized anyway by 
the IBPB flush.

I think the latter (which is what this patch implements) makes more sense. 

Thanks,

-- 
Jiri Kosina
SUSE Labs



Re: [patch 17/24] x86/speculation: Move IBPB control out of switch_mm()

2018-11-21 Thread Jiri Kosina
On Wed, 21 Nov 2018, Andi Kleen wrote:

> > +* This could be optimized by keeping track of the last
> > +* user task per cpu and avoiding the barrier when the task
> > +* is immediately scheduled back and the thread inbetween
> > +* was a kernel thread. It's dubious whether that'd be
> > +* worth the extra load/store and conditional operations.
> > +* Keep it optimized for the common case where the TIF bit
> > +* is not set.
> > +*/
> 
> The optimization was there before and you removed it?
> 
> It's quite important for switching to idle and back. With your variant short 
> IOs
> that do short idle waits will be badly impacted. 

The question is what scenario to optimize for.

Either you penalize everybody in the default prctl+seccomp setup 
(irrespective of it's TIF flag value), as you have the extra overhead on 
each and every switch_to() (to check exactly for this back-to-back 
scheduling), or you penalize only those tasks that are penalized anyway by 
the IBPB flush.

I think the latter (which is what this patch implements) makes more sense. 

Thanks,

-- 
Jiri Kosina
SUSE Labs



Re: [PATCH v1 2/2] signal: add procfd_signal() syscall

2018-11-21 Thread Serge E. Hallyn
On Tue, Nov 20, 2018 at 08:23:43AM +1100, Aleksa Sarai wrote:
> On 2018-11-20, Aleksa Sarai  wrote:
> > On 2018-11-19, Christian Brauner  wrote:
> > > On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> > > > On 2018-11-19, Christian Brauner  wrote:
> > > > > + if (info) {
> > > > > + ret = __copy_siginfo_from_user(sig, , info);
> > > > > + if (unlikely(ret))
> > > > > + goto err;
> > > > > + /*
> > > > > +  * Not even root can pretend to send signals from the 
> > > > > kernel.
> > > > > +  * Nor can they impersonate a kill()/tgkill(), which 
> > > > > adds
> > > > > +  * source info.
> > > > > +  */
> > > > > + ret = -EPERM;
> > > > > + if ((kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL) &&
> > > > > + (task_pid(current) != pid))
> > > > > + goto err;
> > > > > + } else {
> > > > > + prepare_kill_siginfo(sig, );
> > > > > + }
> > > > 
> > > > I wonder whether we should also have a pidns restriction here, since
> > > > currently it isn't possible for a container process using a pidns to
> > > > signal processes outside its pidns. AFAICS, this isn't done through an
> > > > explicit check -- it's a side-effect of processes in a pidns not being
> > > > able to address non-descendant-pidns processes.
> > > > 
> > > > But maybe it's reasonable to allow sending a procfd to a different pidns
> > > > and the same operations working on it? If we extend the procfd API to
> > > 
> > > No, I don't think so. I really don't want any fancy semantics in here.
> > > Fancy doesn't get merged and fancy is hard to maintain. So we should do
> > > something like:
> > > 
> > > if (proc_pid_ns() != current_pid_ns)
> > >   return EINVAL
> > 
> > This isn't quite sufficient. The key thing is that you have to be in an
> > *ancestor* (or same) pidns, not the *same* pidns. Ideally you can re-use
> > the check already in pidns_get_parent, and expose it. It would be
> > something as trivial as:
> > 
> > bool pidns_is_descendant(struct pid_namespace *ns,
> >  struct pid_namespace *ancestor)
> > {
> > for (;;) {
> > if (!ns)
> > return false;
> > if (ns == ancestor)
> > break;
> > ns = ns->parent;
> > }
> > return true;
> > }
> > 
> > And you can rewrite pidns_get_parent to use it. So you would instead be
> > doing:
> > 
> > if (pidns_is_descendant(proc_pid_ns, task_active_pid_ns(current)))
> > return -EPERM;
> 
> Scratch the last bit, -EPERM is wrong here. I would argue that -EINVAL
> is *somewhat* wrong because arguable the more semantically consistent
> error (with kill(2)) would be -ESRCH -- but then you're mixing the "pid
> is dead" and "pid is not visible to you" cases. I'm not sure what the
> right errno would be here (I'm sure some of the LKML greybeards will
> have a better clue.) :P

Actually I like EXDEV for this.  ERMOTE also works.


Re: [PATCH] ARM: dts: imx: Add dummy PHYs for HSIC-only USB controllers

2018-11-21 Thread Schrempf Frieder
On 22.11.18 07:48, PETER CHEN wrote:
>   
>>
>> On Thu, Oct 18, 2018 at 09:45:04AM +0200, Frieder Schrempf wrote:
>>> Some SOCs in the i.MX6 family have a USB host controller that is only
>>> capable of the HSIC interface and has no on-board PHY.
>>>
>>> To be able to use these controllers, we need to add "usb-nop-xceiv"
>>> dummy PHYs.
>>>
>>> Signed-off-by: Frieder Schrempf 
>>
>> @Peter, looks good to you?
>>
>> Shawn
>>
>>> ---
>>>   arch/arm/boot/dts/imx6qdl.dtsi | 14 ++
>>> arch/arm/boot/dts/imx6sl.dtsi  |  7 +++
>>> arch/arm/boot/dts/imx6sx.dtsi  |  6 ++
>>>   3 files changed, 27 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi
>>> b/arch/arm/boot/dts/imx6qdl.dtsi index 61d2d26..d3404d1 100644
>>> --- a/arch/arm/boot/dts/imx6qdl.dtsi
>>> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
>>> @@ -139,6 +139,16 @@
>>> interrupts = <0 94 IRQ_TYPE_LEVEL_HIGH>;
>>> };
>>>
>>> +   usbphynop1: usbphynop1 {
>>> +   compatible = "usb-nop-xceiv";
>>> +   #phy-cells = <0>;
>>> +   };
>>> +
> 
> Why #phy-cells property is needed? Others are ok for me.

 From Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt:

Required properties:
- compatible: should be usb-nop-xceiv
- #phy-cells: Must be 0

> 
> Peter
> 
>>> +   usbphynop2: usbphynop2 {
>>> +   compatible = "usb-nop-xceiv";
>>> +   #phy-cells = <0>;
>>> +   };
>>> +
>>> soc {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> @@ -981,6 +991,8 @@
>>> reg = <0x02184400 0x200>;
>>> interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>;
>>> clocks = < IMX6QDL_CLK_USBOH3>;
>>> +   fsl,usbphy = <>;
>>> +   phy_type = "hsic";
>>> fsl,usbmisc = < 2>;
>>> dr_mode = "host";
>>> ahb-burst-config = <0x0>;
>>> @@ -994,6 +1006,8 @@
>>> reg = <0x02184600 0x200>;
>>> interrupts = <0 42 IRQ_TYPE_LEVEL_HIGH>;
>>> clocks = < IMX6QDL_CLK_USBOH3>;
>>> +   fsl,usbphy = <>;
>>> +   phy_type = "hsic";
>>> fsl,usbmisc = < 3>;
>>> dr_mode = "host";
>>> ahb-burst-config = <0x0>;
>>> diff --git a/arch/arm/boot/dts/imx6sl.dtsi
>>> b/arch/arm/boot/dts/imx6sl.dtsi index 7a4f5da..81edcdc 100644
>>> --- a/arch/arm/boot/dts/imx6sl.dtsi
>>> +++ b/arch/arm/boot/dts/imx6sl.dtsi
>>> @@ -110,6 +110,11 @@
>>> interrupts = <0 94 IRQ_TYPE_LEVEL_HIGH>;
>>> };
>>>
>>> +   usbphynop1: usbphynop1 {
>>> +   compatible = "usb-nop-xceiv";
>>> +   #phy-cells = <0>;
>>> +   };
>>> +
>>> soc {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> @@ -815,6 +820,8 @@
>>> reg = <0x02184400 0x200>;
>>> interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>;
>>> clocks = < IMX6SL_CLK_USBOH3>;
>>> +   fsl,usbphy = <>;
>>> +   phy_type = "hsic";
>>> fsl,usbmisc = < 2>;
>>> dr_mode = "host";
>>> ahb-burst-config = <0x0>;
>>> diff --git a/arch/arm/boot/dts/imx6sx.dtsi
>>> b/arch/arm/boot/dts/imx6sx.dtsi index 844caa3..07ed417 100644
>>> --- a/arch/arm/boot/dts/imx6sx.dtsi
>>> +++ b/arch/arm/boot/dts/imx6sx.dtsi
>>> @@ -159,6 +159,11 @@
>>> interrupts = ;
>>> };
>>>
>>> +   usbphynop1: usbphynop1 {
>>> +   compatible = "usb-nop-xceiv";
>>> +   #phy-cells = <0>;
>>> +   };
>>> +
>>> soc {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> @@ -877,6 +882,7 @@
>>> reg = <0x02184400 0x200>;
>>> interrupts = ;
>>> clocks = < IMX6SX_CLK_USBOH3>;
>>> +   fsl,usbphy = <>;
>>> fsl,usbmisc = < 2>;
>>> phy_type = "hsic";
>>> fsl,anatop = <>;
>>> --
>>> 2.7.4
>>>

Re: [PATCH v1 2/2] signal: add procfd_signal() syscall

2018-11-21 Thread Serge E. Hallyn
On Tue, Nov 20, 2018 at 08:23:43AM +1100, Aleksa Sarai wrote:
> On 2018-11-20, Aleksa Sarai  wrote:
> > On 2018-11-19, Christian Brauner  wrote:
> > > On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> > > > On 2018-11-19, Christian Brauner  wrote:
> > > > > + if (info) {
> > > > > + ret = __copy_siginfo_from_user(sig, , info);
> > > > > + if (unlikely(ret))
> > > > > + goto err;
> > > > > + /*
> > > > > +  * Not even root can pretend to send signals from the 
> > > > > kernel.
> > > > > +  * Nor can they impersonate a kill()/tgkill(), which 
> > > > > adds
> > > > > +  * source info.
> > > > > +  */
> > > > > + ret = -EPERM;
> > > > > + if ((kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL) &&
> > > > > + (task_pid(current) != pid))
> > > > > + goto err;
> > > > > + } else {
> > > > > + prepare_kill_siginfo(sig, );
> > > > > + }
> > > > 
> > > > I wonder whether we should also have a pidns restriction here, since
> > > > currently it isn't possible for a container process using a pidns to
> > > > signal processes outside its pidns. AFAICS, this isn't done through an
> > > > explicit check -- it's a side-effect of processes in a pidns not being
> > > > able to address non-descendant-pidns processes.
> > > > 
> > > > But maybe it's reasonable to allow sending a procfd to a different pidns
> > > > and the same operations working on it? If we extend the procfd API to
> > > 
> > > No, I don't think so. I really don't want any fancy semantics in here.
> > > Fancy doesn't get merged and fancy is hard to maintain. So we should do
> > > something like:
> > > 
> > > if (proc_pid_ns() != current_pid_ns)
> > >   return EINVAL
> > 
> > This isn't quite sufficient. The key thing is that you have to be in an
> > *ancestor* (or same) pidns, not the *same* pidns. Ideally you can re-use
> > the check already in pidns_get_parent, and expose it. It would be
> > something as trivial as:
> > 
> > bool pidns_is_descendant(struct pid_namespace *ns,
> >  struct pid_namespace *ancestor)
> > {
> > for (;;) {
> > if (!ns)
> > return false;
> > if (ns == ancestor)
> > break;
> > ns = ns->parent;
> > }
> > return true;
> > }
> > 
> > And you can rewrite pidns_get_parent to use it. So you would instead be
> > doing:
> > 
> > if (pidns_is_descendant(proc_pid_ns, task_active_pid_ns(current)))
> > return -EPERM;
> 
> Scratch the last bit, -EPERM is wrong here. I would argue that -EINVAL
> is *somewhat* wrong because arguable the more semantically consistent
> error (with kill(2)) would be -ESRCH -- but then you're mixing the "pid
> is dead" and "pid is not visible to you" cases. I'm not sure what the
> right errno would be here (I'm sure some of the LKML greybeards will
> have a better clue.) :P

Actually I like EXDEV for this.  ERMOTE also works.


Re: [PATCH] ARM: dts: imx: Add dummy PHYs for HSIC-only USB controllers

2018-11-21 Thread Schrempf Frieder
On 22.11.18 07:48, PETER CHEN wrote:
>   
>>
>> On Thu, Oct 18, 2018 at 09:45:04AM +0200, Frieder Schrempf wrote:
>>> Some SOCs in the i.MX6 family have a USB host controller that is only
>>> capable of the HSIC interface and has no on-board PHY.
>>>
>>> To be able to use these controllers, we need to add "usb-nop-xceiv"
>>> dummy PHYs.
>>>
>>> Signed-off-by: Frieder Schrempf 
>>
>> @Peter, looks good to you?
>>
>> Shawn
>>
>>> ---
>>>   arch/arm/boot/dts/imx6qdl.dtsi | 14 ++
>>> arch/arm/boot/dts/imx6sl.dtsi  |  7 +++
>>> arch/arm/boot/dts/imx6sx.dtsi  |  6 ++
>>>   3 files changed, 27 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi
>>> b/arch/arm/boot/dts/imx6qdl.dtsi index 61d2d26..d3404d1 100644
>>> --- a/arch/arm/boot/dts/imx6qdl.dtsi
>>> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
>>> @@ -139,6 +139,16 @@
>>> interrupts = <0 94 IRQ_TYPE_LEVEL_HIGH>;
>>> };
>>>
>>> +   usbphynop1: usbphynop1 {
>>> +   compatible = "usb-nop-xceiv";
>>> +   #phy-cells = <0>;
>>> +   };
>>> +
> 
> Why #phy-cells property is needed? Others are ok for me.

 From Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt:

Required properties:
- compatible: should be usb-nop-xceiv
- #phy-cells: Must be 0

> 
> Peter
> 
>>> +   usbphynop2: usbphynop2 {
>>> +   compatible = "usb-nop-xceiv";
>>> +   #phy-cells = <0>;
>>> +   };
>>> +
>>> soc {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> @@ -981,6 +991,8 @@
>>> reg = <0x02184400 0x200>;
>>> interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>;
>>> clocks = < IMX6QDL_CLK_USBOH3>;
>>> +   fsl,usbphy = <>;
>>> +   phy_type = "hsic";
>>> fsl,usbmisc = < 2>;
>>> dr_mode = "host";
>>> ahb-burst-config = <0x0>;
>>> @@ -994,6 +1006,8 @@
>>> reg = <0x02184600 0x200>;
>>> interrupts = <0 42 IRQ_TYPE_LEVEL_HIGH>;
>>> clocks = < IMX6QDL_CLK_USBOH3>;
>>> +   fsl,usbphy = <>;
>>> +   phy_type = "hsic";
>>> fsl,usbmisc = < 3>;
>>> dr_mode = "host";
>>> ahb-burst-config = <0x0>;
>>> diff --git a/arch/arm/boot/dts/imx6sl.dtsi
>>> b/arch/arm/boot/dts/imx6sl.dtsi index 7a4f5da..81edcdc 100644
>>> --- a/arch/arm/boot/dts/imx6sl.dtsi
>>> +++ b/arch/arm/boot/dts/imx6sl.dtsi
>>> @@ -110,6 +110,11 @@
>>> interrupts = <0 94 IRQ_TYPE_LEVEL_HIGH>;
>>> };
>>>
>>> +   usbphynop1: usbphynop1 {
>>> +   compatible = "usb-nop-xceiv";
>>> +   #phy-cells = <0>;
>>> +   };
>>> +
>>> soc {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> @@ -815,6 +820,8 @@
>>> reg = <0x02184400 0x200>;
>>> interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>;
>>> clocks = < IMX6SL_CLK_USBOH3>;
>>> +   fsl,usbphy = <>;
>>> +   phy_type = "hsic";
>>> fsl,usbmisc = < 2>;
>>> dr_mode = "host";
>>> ahb-burst-config = <0x0>;
>>> diff --git a/arch/arm/boot/dts/imx6sx.dtsi
>>> b/arch/arm/boot/dts/imx6sx.dtsi index 844caa3..07ed417 100644
>>> --- a/arch/arm/boot/dts/imx6sx.dtsi
>>> +++ b/arch/arm/boot/dts/imx6sx.dtsi
>>> @@ -159,6 +159,11 @@
>>> interrupts = ;
>>> };
>>>
>>> +   usbphynop1: usbphynop1 {
>>> +   compatible = "usb-nop-xceiv";
>>> +   #phy-cells = <0>;
>>> +   };
>>> +
>>> soc {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> @@ -877,6 +882,7 @@
>>> reg = <0x02184400 0x200>;
>>> interrupts = ;
>>> clocks = < IMX6SX_CLK_USBOH3>;
>>> +   fsl,usbphy = <>;
>>> fsl,usbmisc = < 2>;
>>> phy_type = "hsic";
>>> fsl,anatop = <>;
>>> --
>>> 2.7.4
>>>

Re: WARN_ON after gic_reserve_range

2018-11-21 Thread Richter, Robert
On 20.11.18 17:37:37, Marc Zyngier wrote:
> On 20/11/2018 17:30, John Garry wrote:
> > I see it also:
> >
> > [0.00] Booting Linux on physical CPU 0x01 [0x410fd082]
> > [0.00] Linux version 4.20.0-rc3
> > (johnpgarry@johnpgarry-ThinkCentre-M93p) (gcc version 7.3.1 20180425
> > [linaro-7.3-2018.05-rc1 revision
> > 38aec9a676236eaa42ca03ccb3a6c1dd0182c29f] (Linaro GCC 7.3-2018.05-rc1))
> > #971 SMP PREEMPT Tue Nov 20 17:15:03 GMT 2018
> > [0.00] efi: Getting EFI parameters from FDT:
> > [0.00] efi: EFI v2.60 by EDK II
> > [0.00] efi:  SMBIOS=0x3f05  SMBIOS 3.0=0x39b0
> > ACPI=0x39bd  ACPI 2.0=
> >
> > ...
> >
> >
> > [0.00] ITS@0x0408c600: allocated 65536 Virtual CPUs
> > @1fb9d8 (flat, esz 8, psz 4K, shr 1)
> > [0.00] ITS@0x0408c600: allocated 512 Interrupt
> > Collections @1fbb977000 (flat, esz 8, psz 4K, shr 1)
> > [0.00] WARNING: CPU: 0 PID: 0 at
> > drivers/irqchip/irq-gic-v3-its.c:1696 its_init+0x360/0x5f4
> > [0.00] Modules linked in:
> > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.20.0-rc3 #971
> > [0.00] pstate: 0085 (nzcv daIf -PAN -UAO)
> > [0.00] pc : its_init+0x360/0x5f4
> > [0.00] lr : its_init+0x35c/0x5f4
> > [0.00] sp : 09183ca0
> > [0.00] x29: 09183ca0 x28: 7dfffe67b3e4
> > [0.00] x27: 0001 x26: 801fbb928000
> > [0.00] x25: 09325360 x24: 0918c8c8
> > [0.00] x23: 801fbb802100 x22: 0918c8c8
> > [0.00] x21: 09189000 x20: 091b8000
> > [0.00] x19: 09325000 x18: 
> > [0.00] x17: 01f4d3b5 x16: 
> > [0.00] x15: 091896c8 x14: 801fbb97389b
> > [0.00] x13: 801fbb97389a x12: 2074707572726574
> > [0.00] x11: 09183a00 x10: 09183a00
> > [0.00] x9 : 7e007eeed400 x8 : 801fbbb6
> > [0.00] x7 : a2a2a2a2a2a2a2a2 x6 : 801ff2d1c000
> > [0.00] x5 : 7e00 x4 : 0918c8c8
> > [0.00] x3 : 801fbbb5 x2 : 
> > [0.00] x1 : 0001 x0 : ffed
> > [0.00] Call trace:
> > [0.00]  its_init+0x360/0x5f4
> > [0.00]  gic_init_bases+0x2d4/0x2f4
> > [0.00]  gic_acpi_init+0x154/0x278
> > [0.00]  acpi_match_madt+0x44/0x78
> > [0.00]  acpi_table_parse_entries_array+0x13c/0x214
> > [0.00]  acpi_table_parse_entries+0x40/0x60
> > [0.00]  acpi_table_parse_madt+0x24/0x2c
> > [0.00]  __acpi_probe_device_table+0x80/0xdc
> > [0.00]  irqchip_init+0x30/0x38
> > [0.00]  init_IRQ+0xfc/0x130
> > [0.00]  start_kernel+0x288/0x418
> > [0.00] ---[ end trace c841ef100bdd09a6 ]---
> 
> Yes, anyone with GICv3 and EFI will see this.

My late its_init implementation might fix this, though it does not fix
4.20.

-Robert


Re: WARN_ON after gic_reserve_range

2018-11-21 Thread Richter, Robert
On 20.11.18 17:37:37, Marc Zyngier wrote:
> On 20/11/2018 17:30, John Garry wrote:
> > I see it also:
> >
> > [0.00] Booting Linux on physical CPU 0x01 [0x410fd082]
> > [0.00] Linux version 4.20.0-rc3
> > (johnpgarry@johnpgarry-ThinkCentre-M93p) (gcc version 7.3.1 20180425
> > [linaro-7.3-2018.05-rc1 revision
> > 38aec9a676236eaa42ca03ccb3a6c1dd0182c29f] (Linaro GCC 7.3-2018.05-rc1))
> > #971 SMP PREEMPT Tue Nov 20 17:15:03 GMT 2018
> > [0.00] efi: Getting EFI parameters from FDT:
> > [0.00] efi: EFI v2.60 by EDK II
> > [0.00] efi:  SMBIOS=0x3f05  SMBIOS 3.0=0x39b0
> > ACPI=0x39bd  ACPI 2.0=
> >
> > ...
> >
> >
> > [0.00] ITS@0x0408c600: allocated 65536 Virtual CPUs
> > @1fb9d8 (flat, esz 8, psz 4K, shr 1)
> > [0.00] ITS@0x0408c600: allocated 512 Interrupt
> > Collections @1fbb977000 (flat, esz 8, psz 4K, shr 1)
> > [0.00] WARNING: CPU: 0 PID: 0 at
> > drivers/irqchip/irq-gic-v3-its.c:1696 its_init+0x360/0x5f4
> > [0.00] Modules linked in:
> > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.20.0-rc3 #971
> > [0.00] pstate: 0085 (nzcv daIf -PAN -UAO)
> > [0.00] pc : its_init+0x360/0x5f4
> > [0.00] lr : its_init+0x35c/0x5f4
> > [0.00] sp : 09183ca0
> > [0.00] x29: 09183ca0 x28: 7dfffe67b3e4
> > [0.00] x27: 0001 x26: 801fbb928000
> > [0.00] x25: 09325360 x24: 0918c8c8
> > [0.00] x23: 801fbb802100 x22: 0918c8c8
> > [0.00] x21: 09189000 x20: 091b8000
> > [0.00] x19: 09325000 x18: 
> > [0.00] x17: 01f4d3b5 x16: 
> > [0.00] x15: 091896c8 x14: 801fbb97389b
> > [0.00] x13: 801fbb97389a x12: 2074707572726574
> > [0.00] x11: 09183a00 x10: 09183a00
> > [0.00] x9 : 7e007eeed400 x8 : 801fbbb6
> > [0.00] x7 : a2a2a2a2a2a2a2a2 x6 : 801ff2d1c000
> > [0.00] x5 : 7e00 x4 : 0918c8c8
> > [0.00] x3 : 801fbbb5 x2 : 
> > [0.00] x1 : 0001 x0 : ffed
> > [0.00] Call trace:
> > [0.00]  its_init+0x360/0x5f4
> > [0.00]  gic_init_bases+0x2d4/0x2f4
> > [0.00]  gic_acpi_init+0x154/0x278
> > [0.00]  acpi_match_madt+0x44/0x78
> > [0.00]  acpi_table_parse_entries_array+0x13c/0x214
> > [0.00]  acpi_table_parse_entries+0x40/0x60
> > [0.00]  acpi_table_parse_madt+0x24/0x2c
> > [0.00]  __acpi_probe_device_table+0x80/0xdc
> > [0.00]  irqchip_init+0x30/0x38
> > [0.00]  init_IRQ+0xfc/0x130
> > [0.00]  start_kernel+0x288/0x418
> > [0.00] ---[ end trace c841ef100bdd09a6 ]---
> 
> Yes, anyone with GICv3 and EFI will see this.

My late its_init implementation might fix this, though it does not fix
4.20.

-Robert


Re: [patch 21/24] x86/speculation: Prepare arch_smt_update() for PRCTL mode

2018-11-21 Thread Ingo Molnar


* Thomas Gleixner  wrote:

> The upcoming fine grained per task STIBP control needs to be updated on CPU
> hotplug as well.
> 
> Split out the code which controls the strict mode so the prctl control code
> can be added later.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  arch/x86/kernel/cpu/bugs.c |   46 
> -
>  1 file changed, 25 insertions(+), 21 deletions(-)
> 
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -531,40 +531,44 @@ static void __init spectre_v2_select_mit
>   arch_smt_update();
>  }
>  
> -static bool stibp_needed(void)
> +static void update_stibp_msr(void *info)
>  {
> - /* Enhanced IBRS makes using STIBP unnecessary. */
> - if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
> - return false;
> -
> - /* Check for strict app2app mitigation mode */
> - return spectre_v2_app2app == SPECTRE_V2_APP2APP_STRICT;
> + wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
>  }


Does Sparse or other tooling warn about unused function parameters? If 
yes then it might make sense to mark it __used?

>  
> -static void update_stibp_msr(void *info)
> +/* Update x86_spec_ctrl_base in case SMT state changed. */
> +static void update_stibp_strict(void)
>  {
> - wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
> + u64 mask = x86_spec_ctrl_base & ~SPEC_CTRL_STIBP;
> +
> + if (sched_smt_active())
> + mask |= SPEC_CTRL_STIBP;
> +
> + if (mask == x86_spec_ctrl_base)
> + return;
> +
> + pr_info("Spectre v2 cross-process SMT mitigation: %s STIBP\n",
> + mask & SPEC_CTRL_STIBP ? "Enabling" : "Disabling");
> + x86_spec_ctrl_base = mask;
> + on_each_cpu(update_stibp_msr, NULL, 1);
>  }
>  
>  void arch_smt_update(void)
>  {
> - u64 mask;
> -
> - if (!stibp_needed())
> + /* Enhanced IBRS makes using STIBP unnecessary. No update required. */
> + if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
>   return;
>  
>   mutex_lock(_ctrl_mutex);
>  
> - mask = x86_spec_ctrl_base & ~SPEC_CTRL_STIBP;
> - if (sched_smt_active())
> - mask |= SPEC_CTRL_STIBP;
> -
> - if (mask != x86_spec_ctrl_base) {
> - pr_info("Spectre v2 cross-process SMT mitigation: %s STIBP\n",
> - mask & SPEC_CTRL_STIBP ? "Enabling" : "Disabling");
> - x86_spec_ctrl_base = mask;
> - on_each_cpu(update_stibp_msr, NULL, 1);
> + switch (spectre_v2_app2app) {
> + case SPECTRE_V2_APP2APP_NONE:
> + break;
> + case SPECTRE_V2_APP2APP_STRICT:
> + update_stibp_strict();
> + break;
>   }

So I'm wondering, shouldn't firmware_restrict_branch_speculation_start()/_end()
also enable/disable STIBP? It already enabled/disables IBRS.

Thanks,

Ingo


Re: [patch 21/24] x86/speculation: Prepare arch_smt_update() for PRCTL mode

2018-11-21 Thread Ingo Molnar


* Thomas Gleixner  wrote:

> The upcoming fine grained per task STIBP control needs to be updated on CPU
> hotplug as well.
> 
> Split out the code which controls the strict mode so the prctl control code
> can be added later.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  arch/x86/kernel/cpu/bugs.c |   46 
> -
>  1 file changed, 25 insertions(+), 21 deletions(-)
> 
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -531,40 +531,44 @@ static void __init spectre_v2_select_mit
>   arch_smt_update();
>  }
>  
> -static bool stibp_needed(void)
> +static void update_stibp_msr(void *info)
>  {
> - /* Enhanced IBRS makes using STIBP unnecessary. */
> - if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
> - return false;
> -
> - /* Check for strict app2app mitigation mode */
> - return spectre_v2_app2app == SPECTRE_V2_APP2APP_STRICT;
> + wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
>  }


Does Sparse or other tooling warn about unused function parameters? If 
yes then it might make sense to mark it __used?

>  
> -static void update_stibp_msr(void *info)
> +/* Update x86_spec_ctrl_base in case SMT state changed. */
> +static void update_stibp_strict(void)
>  {
> - wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
> + u64 mask = x86_spec_ctrl_base & ~SPEC_CTRL_STIBP;
> +
> + if (sched_smt_active())
> + mask |= SPEC_CTRL_STIBP;
> +
> + if (mask == x86_spec_ctrl_base)
> + return;
> +
> + pr_info("Spectre v2 cross-process SMT mitigation: %s STIBP\n",
> + mask & SPEC_CTRL_STIBP ? "Enabling" : "Disabling");
> + x86_spec_ctrl_base = mask;
> + on_each_cpu(update_stibp_msr, NULL, 1);
>  }
>  
>  void arch_smt_update(void)
>  {
> - u64 mask;
> -
> - if (!stibp_needed())
> + /* Enhanced IBRS makes using STIBP unnecessary. No update required. */
> + if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
>   return;
>  
>   mutex_lock(_ctrl_mutex);
>  
> - mask = x86_spec_ctrl_base & ~SPEC_CTRL_STIBP;
> - if (sched_smt_active())
> - mask |= SPEC_CTRL_STIBP;
> -
> - if (mask != x86_spec_ctrl_base) {
> - pr_info("Spectre v2 cross-process SMT mitigation: %s STIBP\n",
> - mask & SPEC_CTRL_STIBP ? "Enabling" : "Disabling");
> - x86_spec_ctrl_base = mask;
> - on_each_cpu(update_stibp_msr, NULL, 1);
> + switch (spectre_v2_app2app) {
> + case SPECTRE_V2_APP2APP_NONE:
> + break;
> + case SPECTRE_V2_APP2APP_STRICT:
> + update_stibp_strict();
> + break;
>   }

So I'm wondering, shouldn't firmware_restrict_branch_speculation_start()/_end()
also enable/disable STIBP? It already enabled/disables IBRS.

Thanks,

Ingo


Re: [PATCH] arm64: dts: qcom: sdm845-mtp: Mark protected gcc clocks

2018-11-21 Thread Bjorn Andersson
On Wed 21 Nov 01:01 PST 2018, Stephen Boyd wrote:

> Quoting Bjorn Andersson (2018-11-05 21:50:13)
> > As of v4.20-rc1 probing the GCC driver on a SDM845 device with the
> > standard security implementation causes an access violation and an
> > immediate system restart. Use the protected-clocks property to mark the
> > offending clocks protected for the MTP, in order to allow it to boot.
> > 
> > Cc: Stephen Boyd 
> > Signed-off-by: Bjorn Andersson 
> > ---
> > 
> > This depends on the acceptance of
> > https://lore.kernel.org/lkml/20181105194011.43770-1-swb...@chromium.org/
> 
> Do you need me to merge this into clk-fixes so that Andy can send this
> up for v4.20 final? I thought you may have other boot blocking issues so
> this wouldn't be a critical fix.
> 

We resolved the gpio-related issues, so iirc this is the only other item
preventing the MTP from booting. So yes please.

Unless you enable USB support, because configuring the first USB
controller in host currently crashes the device - I've not yet found the
cause for this though.

Regards,
Bjorn


Re: [PATCH] arm64: dts: qcom: sdm845-mtp: Mark protected gcc clocks

2018-11-21 Thread Bjorn Andersson
On Wed 21 Nov 01:01 PST 2018, Stephen Boyd wrote:

> Quoting Bjorn Andersson (2018-11-05 21:50:13)
> > As of v4.20-rc1 probing the GCC driver on a SDM845 device with the
> > standard security implementation causes an access violation and an
> > immediate system restart. Use the protected-clocks property to mark the
> > offending clocks protected for the MTP, in order to allow it to boot.
> > 
> > Cc: Stephen Boyd 
> > Signed-off-by: Bjorn Andersson 
> > ---
> > 
> > This depends on the acceptance of
> > https://lore.kernel.org/lkml/20181105194011.43770-1-swb...@chromium.org/
> 
> Do you need me to merge this into clk-fixes so that Andy can send this
> up for v4.20 final? I thought you may have other boot blocking issues so
> this wouldn't be a critical fix.
> 

We resolved the gpio-related issues, so iirc this is the only other item
preventing the MTP from booting. So yes please.

Unless you enable USB support, because configuring the first USB
controller in host currently crashes the device - I've not yet found the
cause for this though.

Regards,
Bjorn


[PATCH] drivers/memstick/host/jmb38x_ms: fixes incorrect error handling

2018-11-21 Thread Pan Bian
kfree() is incorrectly used to free the memory chunk allocated by
memstick_alloc_host(). Instead, memstick_free_host() should be used.

Fixes: 60fdd931d577("memstick: add support for JMicron jmb38x ...")
Signed-off-by: Pan Bian 
---
 drivers/memstick/host/jmb38x_ms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/memstick/host/jmb38x_ms.c 
b/drivers/memstick/host/jmb38x_ms.c
index bcdca9f..637409c 100644
--- a/drivers/memstick/host/jmb38x_ms.c
+++ b/drivers/memstick/host/jmb38x_ms.c
@@ -907,7 +907,7 @@ static struct memstick_host *jmb38x_ms_alloc_host(struct 
jmb38x_ms *jm, int cnt)
 
iounmap(host->addr);
 err_out_free:
-   kfree(msh);
+   memstick_free_host(msh);
return NULL;
 }
 
-- 
2.7.4




[PATCH] drivers/memstick/host/jmb38x_ms: fixes incorrect error handling

2018-11-21 Thread Pan Bian
kfree() is incorrectly used to free the memory chunk allocated by
memstick_alloc_host(). Instead, memstick_free_host() should be used.

Fixes: 60fdd931d577("memstick: add support for JMicron jmb38x ...")
Signed-off-by: Pan Bian 
---
 drivers/memstick/host/jmb38x_ms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/memstick/host/jmb38x_ms.c 
b/drivers/memstick/host/jmb38x_ms.c
index bcdca9f..637409c 100644
--- a/drivers/memstick/host/jmb38x_ms.c
+++ b/drivers/memstick/host/jmb38x_ms.c
@@ -907,7 +907,7 @@ static struct memstick_host *jmb38x_ms_alloc_host(struct 
jmb38x_ms *jm, int cnt)
 
iounmap(host->addr);
 err_out_free:
-   kfree(msh);
+   memstick_free_host(msh);
return NULL;
 }
 
-- 
2.7.4




Re: [patch 24/24] x86/speculation: Add seccomp Spectre v2 app to app protection mode

2018-11-21 Thread Ingo Molnar


* Thomas Gleixner  wrote:

> From: Jiri Kosina 
> 
> If 'prctl' mode of app2app protection from spectre v2 is selected on the
> kernel command-line, STIBP and IBPB are applied on tasks which restrict
> their indirect branch speculation via prctl.
> 
> SECCOMP enables the SSBD mitigation for sandboxed tasks already, so it
> makes sense to prevent spectre v2 application to application attacks as
> well.
> 
> The mitigation guide documents how STIPB works:
> 
>Setting bit 1 (STIBP) of the IA32_SPEC_CTRL MSR on a logical processor
>prevents the predicted targets of indirect branches on any logical
>processor of that core from being controlled by software that executes
>(or executed previously) on another logical processor of the same core.
> 
> Ergo setting STIBP protects the task itself from being attacked from a task
> running on a different hyper-thread and protects the tasks running on
> different hyper-threads from being attacked.
> 
> IBPB is issued when the task switches out, so malicious sandbox code cannot
> mistrain the branch predictor for the next user space task on the same
> logical processor.
> 
> Signed-off-by: Jiri Kosina 
> Signed-off-by: Thomas Gleixner 
> 
> ---
>  Documentation/admin-guide/kernel-parameters.txt |7 +-
>  arch/x86/include/asm/nospec-branch.h|1 
>  arch/x86/kernel/cpu/bugs.c  |   27 
> +++-
>  3 files changed, 29 insertions(+), 6 deletions(-)
> 
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4228,10 +4228,15 @@
> by spectre_v2=off
>   auto- Kernel selects the mitigation depending on
> the available CPU features and vulnerability.
> -   Default is prctl.
>   prctl   - Indirect branch speculation is enabled, but
> mitigation can be enabled via prctl per 
> thread.
> The mitigation control state is inherited on 
> fork.
> + seccomp - Same as "prctl" above, but all seccomp threads
> +   will enable the mitigation unless they 
> explicitly
> +   opt out.
> +
> + Default mitigation:
> + If CONFIG_SECCOMP=y "seccomp", otherwise "prctl"
>  
>   Not specifying this option is equivalent to
>   spectre_v2_app2app=auto.
> --- a/arch/x86/include/asm/nospec-branch.h
> +++ b/arch/x86/include/asm/nospec-branch.h
> @@ -233,6 +233,7 @@ enum spectre_v2_app2app_mitigation {
>   SPECTRE_V2_APP2APP_NONE,
>   SPECTRE_V2_APP2APP_STRICT,
>   SPECTRE_V2_APP2APP_PRCTL,
> + SPECTRE_V2_APP2APP_SECCOMP,
>  };
>  
>  /* The Speculative Store Bypass disable variants */
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -256,12 +256,14 @@ enum spectre_v2_app2app_cmd {
>   SPECTRE_V2_APP2APP_CMD_AUTO,
>   SPECTRE_V2_APP2APP_CMD_FORCE,
>   SPECTRE_V2_APP2APP_CMD_PRCTL,
> + SPECTRE_V2_APP2APP_CMD_SECCOMP,
>  };
>  
>  static const char *spectre_v2_app2app_strings[] = {
>   [SPECTRE_V2_APP2APP_NONE]   = "App-App Vulnerable",
> - [SPECTRE_V2_APP2APP_STRICT] = "App-App Mitigation: STIBP 
> protection",
> - [SPECTRE_V2_APP2APP_PRCTL]  = "App-App Mitigation: STIBP via prctl",
> + [SPECTRE_V2_APP2APP_STRICT] = "App-App Mitigation: forced 
> protection",
> + [SPECTRE_V2_APP2APP_PRCTL]  = "App-App Mitigation: prctl opt-in",
> + [SPECTRE_V2_APP2APP_SECCOMP]= "App-App Mitigation: seccomp and 
> prctl opt-in",

This description is not accurate: it's not a 'seccomp and prctl opt-in', 
the seccomp functionality is opt-out, the prctl is opt-in.

So something like:

> + [SPECTRE_V2_APP2APP_SECCOMP]= "App-App Mitigation: seccomp by 
> default and prctl opt-in",

or so?

>  void arch_seccomp_spec_mitigate(struct task_struct *task)
>  {
>   if (ssb_mode == SPEC_STORE_BYPASS_SECCOMP)
>   ssb_prctl_set(task, PR_SPEC_FORCE_DISABLE);
> + if (spectre_v2_app2app == SPECTRE_V2_APP2APP_SECCOMP)
> + indir_branch_prctl_set(task, PR_SPEC_FORCE_DISABLE);
>  }
>  #endif

Hm, so isn't arch_seccomp_spec_mitigate() called right before untrusted 
seccomp code is executed? So why are we disabling the mitigation here?

> + case SPECTRE_V2_APP2APP_SECCOMP:
> + return ", STIBP: seccomp and prctl opt-in";
> + case SPECTRE_V2_APP2APP_SECCOMP:
> + return ", IBPB: seccomp and prctl opt-in";

Same feedback wrt. potentially confusing use of 'opt-in' here, while 
seccomp is more like an opt-out mechanism.

Thanks,

Ingo


Re: [patch 24/24] x86/speculation: Add seccomp Spectre v2 app to app protection mode

2018-11-21 Thread Ingo Molnar


* Thomas Gleixner  wrote:

> From: Jiri Kosina 
> 
> If 'prctl' mode of app2app protection from spectre v2 is selected on the
> kernel command-line, STIBP and IBPB are applied on tasks which restrict
> their indirect branch speculation via prctl.
> 
> SECCOMP enables the SSBD mitigation for sandboxed tasks already, so it
> makes sense to prevent spectre v2 application to application attacks as
> well.
> 
> The mitigation guide documents how STIPB works:
> 
>Setting bit 1 (STIBP) of the IA32_SPEC_CTRL MSR on a logical processor
>prevents the predicted targets of indirect branches on any logical
>processor of that core from being controlled by software that executes
>(or executed previously) on another logical processor of the same core.
> 
> Ergo setting STIBP protects the task itself from being attacked from a task
> running on a different hyper-thread and protects the tasks running on
> different hyper-threads from being attacked.
> 
> IBPB is issued when the task switches out, so malicious sandbox code cannot
> mistrain the branch predictor for the next user space task on the same
> logical processor.
> 
> Signed-off-by: Jiri Kosina 
> Signed-off-by: Thomas Gleixner 
> 
> ---
>  Documentation/admin-guide/kernel-parameters.txt |7 +-
>  arch/x86/include/asm/nospec-branch.h|1 
>  arch/x86/kernel/cpu/bugs.c  |   27 
> +++-
>  3 files changed, 29 insertions(+), 6 deletions(-)
> 
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4228,10 +4228,15 @@
> by spectre_v2=off
>   auto- Kernel selects the mitigation depending on
> the available CPU features and vulnerability.
> -   Default is prctl.
>   prctl   - Indirect branch speculation is enabled, but
> mitigation can be enabled via prctl per 
> thread.
> The mitigation control state is inherited on 
> fork.
> + seccomp - Same as "prctl" above, but all seccomp threads
> +   will enable the mitigation unless they 
> explicitly
> +   opt out.
> +
> + Default mitigation:
> + If CONFIG_SECCOMP=y "seccomp", otherwise "prctl"
>  
>   Not specifying this option is equivalent to
>   spectre_v2_app2app=auto.
> --- a/arch/x86/include/asm/nospec-branch.h
> +++ b/arch/x86/include/asm/nospec-branch.h
> @@ -233,6 +233,7 @@ enum spectre_v2_app2app_mitigation {
>   SPECTRE_V2_APP2APP_NONE,
>   SPECTRE_V2_APP2APP_STRICT,
>   SPECTRE_V2_APP2APP_PRCTL,
> + SPECTRE_V2_APP2APP_SECCOMP,
>  };
>  
>  /* The Speculative Store Bypass disable variants */
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -256,12 +256,14 @@ enum spectre_v2_app2app_cmd {
>   SPECTRE_V2_APP2APP_CMD_AUTO,
>   SPECTRE_V2_APP2APP_CMD_FORCE,
>   SPECTRE_V2_APP2APP_CMD_PRCTL,
> + SPECTRE_V2_APP2APP_CMD_SECCOMP,
>  };
>  
>  static const char *spectre_v2_app2app_strings[] = {
>   [SPECTRE_V2_APP2APP_NONE]   = "App-App Vulnerable",
> - [SPECTRE_V2_APP2APP_STRICT] = "App-App Mitigation: STIBP 
> protection",
> - [SPECTRE_V2_APP2APP_PRCTL]  = "App-App Mitigation: STIBP via prctl",
> + [SPECTRE_V2_APP2APP_STRICT] = "App-App Mitigation: forced 
> protection",
> + [SPECTRE_V2_APP2APP_PRCTL]  = "App-App Mitigation: prctl opt-in",
> + [SPECTRE_V2_APP2APP_SECCOMP]= "App-App Mitigation: seccomp and 
> prctl opt-in",

This description is not accurate: it's not a 'seccomp and prctl opt-in', 
the seccomp functionality is opt-out, the prctl is opt-in.

So something like:

> + [SPECTRE_V2_APP2APP_SECCOMP]= "App-App Mitigation: seccomp by 
> default and prctl opt-in",

or so?

>  void arch_seccomp_spec_mitigate(struct task_struct *task)
>  {
>   if (ssb_mode == SPEC_STORE_BYPASS_SECCOMP)
>   ssb_prctl_set(task, PR_SPEC_FORCE_DISABLE);
> + if (spectre_v2_app2app == SPECTRE_V2_APP2APP_SECCOMP)
> + indir_branch_prctl_set(task, PR_SPEC_FORCE_DISABLE);
>  }
>  #endif

Hm, so isn't arch_seccomp_spec_mitigate() called right before untrusted 
seccomp code is executed? So why are we disabling the mitigation here?

> + case SPECTRE_V2_APP2APP_SECCOMP:
> + return ", STIBP: seccomp and prctl opt-in";
> + case SPECTRE_V2_APP2APP_SECCOMP:
> + return ", IBPB: seccomp and prctl opt-in";

Same feedback wrt. potentially confusing use of 'opt-in' here, while 
seccomp is more like an opt-out mechanism.

Thanks,

Ingo


Re: [PATCH] clk: qcom: Move to menuconfig and reduce lines

2018-11-21 Thread Bjorn Andersson
On Wed 21 Nov 13:01 PST 2018, Stephen Boyd wrote:

> We duplicate the 'depends on' in almost every Kconfig here, and it's
> getting out of hand now that we have tens of options for various SoC
> drivers here. Let's clean it up a little by making a menuconfig for a
> submenu and adding an if wrapper around the driver section.
> 
> Cc: Taniya Das 
> Signed-off-by: Stephen Boyd 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  drivers/clk/qcom/Kconfig | 39 +--
>  1 file changed, 5 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index a611531df115..1977f40f4bec 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -9,16 +9,17 @@ config QCOM_GDSC
>  config QCOM_RPMCC
>   bool
>  
> -config COMMON_CLK_QCOM
> +menuconfig COMMON_CLK_QCOM
>   tristate "Support for Qualcomm's clock controllers"
>   depends on OF
>   depends on ARCH_QCOM || COMPILE_TEST
>   select REGMAP_MMIO
>   select RESET_CONTROLLER
>  
> +if COMMON_CLK_QCOM
> +
>  config QCOM_A53PLL
>   tristate "MSM8916 A53 PLL"
> - depends on COMMON_CLK_QCOM
>   default ARCH_QCOM
>   help
> Support for the A53 PLL on MSM8916 devices. It provides
> @@ -28,7 +29,6 @@ config QCOM_A53PLL
>  
>  config QCOM_CLK_APCS_MSM8916
>   tristate "MSM8916 APCS Clock Controller"
> - depends on COMMON_CLK_QCOM
>   depends on QCOM_APCS_IPC || COMPILE_TEST
>   default ARCH_QCOM
>   help
> @@ -39,7 +39,6 @@ config QCOM_CLK_APCS_MSM8916
>  
>  config QCOM_CLK_RPM
>   tristate "RPM based Clock Controller"
> - depends on COMMON_CLK_QCOM && MFD_QCOM_RPM
>   select QCOM_RPMCC
>   help
> The RPM (Resource Power Manager) is a dedicated hardware engine for
> @@ -52,7 +51,6 @@ config QCOM_CLK_RPM
>  
>  config QCOM_CLK_SMD_RPM
>   tristate "RPM over SMD based Clock Controller"
> - depends on COMMON_CLK_QCOM && QCOM_SMD_RPM
>   select QCOM_RPMCC
>   help
> The RPM (Resource Power Manager) is a dedicated hardware engine for
> @@ -65,7 +63,6 @@ config QCOM_CLK_SMD_RPM
>  
>  config QCOM_CLK_RPMH
>   tristate "RPMh Clock Driver"
> - depends on COMMON_CLK_QCOM && QCOM_RPMH
>   help
>RPMh manages shared resources on some Qualcomm Technologies, Inc.
>SoCs. It accepts requests from other hardware subsystems via RSC.
> @@ -75,7 +72,6 @@ config QCOM_CLK_RPMH
>  config APQ_GCC_8084
>   tristate "APQ8084 Global Clock Controller"
>   select QCOM_GDSC
> - depends on COMMON_CLK_QCOM
>   help
> Support for the global clock controller on apq8084 devices.
> Say Y if you want to use peripheral devices such as UART, SPI,
> @@ -85,7 +81,6 @@ config APQ_MMCC_8084
>   tristate "APQ8084 Multimedia Clock Controller"
>   select APQ_GCC_8084
>   select QCOM_GDSC
> - depends on COMMON_CLK_QCOM
>   help
> Support for the multimedia clock controller on apq8084 devices.
> Say Y if you want to support multimedia devices such as display,
> @@ -93,7 +88,6 @@ config APQ_MMCC_8084
>  
>  config IPQ_GCC_4019
>   tristate "IPQ4019 Global Clock Controller"
> - depends on COMMON_CLK_QCOM
>   help
> Support for the global clock controller on ipq4019 devices.
> Say Y if you want to use peripheral devices such as UART, SPI,
> @@ -101,7 +95,6 @@ config IPQ_GCC_4019
>  
>  config IPQ_GCC_806X
>   tristate "IPQ806x Global Clock Controller"
> - depends on COMMON_CLK_QCOM
>   help
> Support for the global clock controller on ipq806x devices.
> Say Y if you want to use peripheral devices such as UART, SPI,
> @@ -110,7 +103,6 @@ config IPQ_GCC_806X
>  config IPQ_LCC_806X
>   tristate "IPQ806x LPASS Clock Controller"
>   select IPQ_GCC_806X
> - depends on COMMON_CLK_QCOM
>   help
> Support for the LPASS clock controller on ipq806x devices.
> Say Y if you want to use audio devices such as i2s, pcm,
> @@ -118,7 +110,6 @@ config IPQ_LCC_806X
>  
>  config IPQ_GCC_8074
>   tristate "IPQ8074 Global Clock Controller"
> - depends on COMMON_CLK_QCOM
>   help
> Support for global clock controller on ipq8074 devices.
> Say Y if you want to use peripheral devices such as UART, SPI,
> @@ -127,7 +118,6 @@ config IPQ_GCC_8074
>  
>  config MSM_GCC_8660
>   tristate "MSM8660 Global Clock Controller"
> - depends on COMMON_CLK_QCOM
>   help
> Support for the global clock controller on msm8660 devices.
> Say Y if you want to use peripheral devices such as UART, SPI,
> @@ -136,7 +126,6 @@ config MSM_GCC_8660
>  config MSM_GCC_8916
>   tristate "MSM8916 Global Clock Controller"
>   select QCOM_GDSC
> - depends on COMMON_CLK_QCOM
>   help
> Support for the global clock controller on msm8916 devices.
> Say Y if you want to use devices such as UART, SPI i2c, 

Re: [PATCH] clk: qcom: Move to menuconfig and reduce lines

2018-11-21 Thread Bjorn Andersson
On Wed 21 Nov 13:01 PST 2018, Stephen Boyd wrote:

> We duplicate the 'depends on' in almost every Kconfig here, and it's
> getting out of hand now that we have tens of options for various SoC
> drivers here. Let's clean it up a little by making a menuconfig for a
> submenu and adding an if wrapper around the driver section.
> 
> Cc: Taniya Das 
> Signed-off-by: Stephen Boyd 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  drivers/clk/qcom/Kconfig | 39 +--
>  1 file changed, 5 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index a611531df115..1977f40f4bec 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -9,16 +9,17 @@ config QCOM_GDSC
>  config QCOM_RPMCC
>   bool
>  
> -config COMMON_CLK_QCOM
> +menuconfig COMMON_CLK_QCOM
>   tristate "Support for Qualcomm's clock controllers"
>   depends on OF
>   depends on ARCH_QCOM || COMPILE_TEST
>   select REGMAP_MMIO
>   select RESET_CONTROLLER
>  
> +if COMMON_CLK_QCOM
> +
>  config QCOM_A53PLL
>   tristate "MSM8916 A53 PLL"
> - depends on COMMON_CLK_QCOM
>   default ARCH_QCOM
>   help
> Support for the A53 PLL on MSM8916 devices. It provides
> @@ -28,7 +29,6 @@ config QCOM_A53PLL
>  
>  config QCOM_CLK_APCS_MSM8916
>   tristate "MSM8916 APCS Clock Controller"
> - depends on COMMON_CLK_QCOM
>   depends on QCOM_APCS_IPC || COMPILE_TEST
>   default ARCH_QCOM
>   help
> @@ -39,7 +39,6 @@ config QCOM_CLK_APCS_MSM8916
>  
>  config QCOM_CLK_RPM
>   tristate "RPM based Clock Controller"
> - depends on COMMON_CLK_QCOM && MFD_QCOM_RPM
>   select QCOM_RPMCC
>   help
> The RPM (Resource Power Manager) is a dedicated hardware engine for
> @@ -52,7 +51,6 @@ config QCOM_CLK_RPM
>  
>  config QCOM_CLK_SMD_RPM
>   tristate "RPM over SMD based Clock Controller"
> - depends on COMMON_CLK_QCOM && QCOM_SMD_RPM
>   select QCOM_RPMCC
>   help
> The RPM (Resource Power Manager) is a dedicated hardware engine for
> @@ -65,7 +63,6 @@ config QCOM_CLK_SMD_RPM
>  
>  config QCOM_CLK_RPMH
>   tristate "RPMh Clock Driver"
> - depends on COMMON_CLK_QCOM && QCOM_RPMH
>   help
>RPMh manages shared resources on some Qualcomm Technologies, Inc.
>SoCs. It accepts requests from other hardware subsystems via RSC.
> @@ -75,7 +72,6 @@ config QCOM_CLK_RPMH
>  config APQ_GCC_8084
>   tristate "APQ8084 Global Clock Controller"
>   select QCOM_GDSC
> - depends on COMMON_CLK_QCOM
>   help
> Support for the global clock controller on apq8084 devices.
> Say Y if you want to use peripheral devices such as UART, SPI,
> @@ -85,7 +81,6 @@ config APQ_MMCC_8084
>   tristate "APQ8084 Multimedia Clock Controller"
>   select APQ_GCC_8084
>   select QCOM_GDSC
> - depends on COMMON_CLK_QCOM
>   help
> Support for the multimedia clock controller on apq8084 devices.
> Say Y if you want to support multimedia devices such as display,
> @@ -93,7 +88,6 @@ config APQ_MMCC_8084
>  
>  config IPQ_GCC_4019
>   tristate "IPQ4019 Global Clock Controller"
> - depends on COMMON_CLK_QCOM
>   help
> Support for the global clock controller on ipq4019 devices.
> Say Y if you want to use peripheral devices such as UART, SPI,
> @@ -101,7 +95,6 @@ config IPQ_GCC_4019
>  
>  config IPQ_GCC_806X
>   tristate "IPQ806x Global Clock Controller"
> - depends on COMMON_CLK_QCOM
>   help
> Support for the global clock controller on ipq806x devices.
> Say Y if you want to use peripheral devices such as UART, SPI,
> @@ -110,7 +103,6 @@ config IPQ_GCC_806X
>  config IPQ_LCC_806X
>   tristate "IPQ806x LPASS Clock Controller"
>   select IPQ_GCC_806X
> - depends on COMMON_CLK_QCOM
>   help
> Support for the LPASS clock controller on ipq806x devices.
> Say Y if you want to use audio devices such as i2s, pcm,
> @@ -118,7 +110,6 @@ config IPQ_LCC_806X
>  
>  config IPQ_GCC_8074
>   tristate "IPQ8074 Global Clock Controller"
> - depends on COMMON_CLK_QCOM
>   help
> Support for global clock controller on ipq8074 devices.
> Say Y if you want to use peripheral devices such as UART, SPI,
> @@ -127,7 +118,6 @@ config IPQ_GCC_8074
>  
>  config MSM_GCC_8660
>   tristate "MSM8660 Global Clock Controller"
> - depends on COMMON_CLK_QCOM
>   help
> Support for the global clock controller on msm8660 devices.
> Say Y if you want to use peripheral devices such as UART, SPI,
> @@ -136,7 +126,6 @@ config MSM_GCC_8660
>  config MSM_GCC_8916
>   tristate "MSM8916 Global Clock Controller"
>   select QCOM_GDSC
> - depends on COMMON_CLK_QCOM
>   help
> Support for the global clock controller on msm8916 devices.
> Say Y if you want to use devices such as UART, SPI i2c, 

Re: [PATCH v5 3/5] arm64: dts: qcom: sdm845: add UFS controller

2018-11-21 Thread Bjorn Andersson
On Fri 26 Oct 10:35 PDT 2018, Evan Green wrote:
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index b72bdb0a31a5..9c72edb678ec 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -808,6 +808,73 @@
>   };
>   };
>  
> + ufshc1: ufshc@1d84000 {

There's only one ufshc and one ufsphy, so no need to include the index.

[..]
> + resets = < GCC_UFS_PHY_BCR>;
> + reset-names = "rst";

I have this as well, but this is not used by the upstream driver nor is
it mentioned in the dt-binding.

> +
> + status = "disabled";
> + };
> +
> + ufsphy1: phy@1d87000 {

With reservation for the "reset" issue:

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn


Re: [PATCH v5 3/5] arm64: dts: qcom: sdm845: add UFS controller

2018-11-21 Thread Bjorn Andersson
On Fri 26 Oct 10:35 PDT 2018, Evan Green wrote:
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index b72bdb0a31a5..9c72edb678ec 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -808,6 +808,73 @@
>   };
>   };
>  
> + ufshc1: ufshc@1d84000 {

There's only one ufshc and one ufsphy, so no need to include the index.

[..]
> + resets = < GCC_UFS_PHY_BCR>;
> + reset-names = "rst";

I have this as well, but this is not used by the upstream driver nor is
it mentioned in the dt-binding.

> +
> + status = "disabled";
> + };
> +
> + ufsphy1: phy@1d87000 {

With reservation for the "reset" issue:

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn


Re: [patch 23/24] x86/speculation: Enable PRCTL mode for spectre_v2_app2app

2018-11-21 Thread Ingo Molnar


* Thomas Gleixner  wrote:

> Now that all prerequisites are in place:
> 
>  - Add the prctl command line option
> 
>  - Default the 'auto' mode to 'prctl'
> 
>  - When SMT state changes, update the static key which controls the
>conditional STIBP evaluation on context switch.
> 
>  - At init update the static key which controls the conditional IBPB
>evaluation on context switch.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  Documentation/admin-guide/kernel-parameters.txt |5 ++
>  arch/x86/kernel/cpu/bugs.c  |   46 
> +---
>  2 files changed, 45 insertions(+), 6 deletions(-)
> 
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4246,7 +4246,10 @@
> by spectre_v2=off
>   auto- Kernel selects the mitigation depending on
> the available CPU features and vulnerability.
> -   Default is off.
> +   Default is prctl.
> + prctl   - Indirect branch speculation is enabled, but
> +   mitigation can be enabled via prctl per 
> thread.
> +   The mitigation control state is inherited on 
> fork.

Please change the order of the last two entries, i.e. make 'auto' the 
last one. This is the pattern we use in other places plus we refer to 
'prctl' before we document it.

>  static const struct {
> @@ -270,6 +272,7 @@ static const struct {
>   { "auto",   SPECTRE_V2_APP2APP_CMD_AUTO,false },
>   { "off",SPECTRE_V2_APP2APP_CMD_NONE,false },
>   { "on", SPECTRE_V2_APP2APP_CMD_FORCE,   true  },
> + { "prctl",  SPECTRE_V2_APP2APP_CMD_PRCTL,   false },

Might make sense to order them in a consistent fashion as well.

> + /*
> +  * If STIBP is not available or SMT is not possible clear the STIPB
> +  * mode.
> +  */
> + if (!smt_possible || !boot_cpu_has(X86_FEATURE_STIBP))
> + mode = SPECTRE_V2_APP2APP_NONE;

Another nit: please match order of the comments to how the condition is 
written in the code.

> +/* Update the static key controlling the evaluation of TIF_SPEC_IB */
> +static void update_indir_branch_cond(void)
> +{
> + if (!IS_ENABLED(CONFIG_SMP))
> + return;
> +
> + if (sched_smt_active())
> + static_branch_enable(_to_cond_stibp);
> + else
> + static_branch_disable(_to_cond_stibp);

So in the !SMP case sched_smt_active() is already doing the right thing:

  static inline bool sched_smt_active(void) { return false; }

I.e. couldn't we just remove the extra CONFIG_SMP condition?
This would simplify the code with some very minor expense on !SMP.

Thanks,

Ingo


Re: [patch 23/24] x86/speculation: Enable PRCTL mode for spectre_v2_app2app

2018-11-21 Thread Ingo Molnar


* Thomas Gleixner  wrote:

> Now that all prerequisites are in place:
> 
>  - Add the prctl command line option
> 
>  - Default the 'auto' mode to 'prctl'
> 
>  - When SMT state changes, update the static key which controls the
>conditional STIBP evaluation on context switch.
> 
>  - At init update the static key which controls the conditional IBPB
>evaluation on context switch.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  Documentation/admin-guide/kernel-parameters.txt |5 ++
>  arch/x86/kernel/cpu/bugs.c  |   46 
> +---
>  2 files changed, 45 insertions(+), 6 deletions(-)
> 
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4246,7 +4246,10 @@
> by spectre_v2=off
>   auto- Kernel selects the mitigation depending on
> the available CPU features and vulnerability.
> -   Default is off.
> +   Default is prctl.
> + prctl   - Indirect branch speculation is enabled, but
> +   mitigation can be enabled via prctl per 
> thread.
> +   The mitigation control state is inherited on 
> fork.

Please change the order of the last two entries, i.e. make 'auto' the 
last one. This is the pattern we use in other places plus we refer to 
'prctl' before we document it.

>  static const struct {
> @@ -270,6 +272,7 @@ static const struct {
>   { "auto",   SPECTRE_V2_APP2APP_CMD_AUTO,false },
>   { "off",SPECTRE_V2_APP2APP_CMD_NONE,false },
>   { "on", SPECTRE_V2_APP2APP_CMD_FORCE,   true  },
> + { "prctl",  SPECTRE_V2_APP2APP_CMD_PRCTL,   false },

Might make sense to order them in a consistent fashion as well.

> + /*
> +  * If STIBP is not available or SMT is not possible clear the STIPB
> +  * mode.
> +  */
> + if (!smt_possible || !boot_cpu_has(X86_FEATURE_STIBP))
> + mode = SPECTRE_V2_APP2APP_NONE;

Another nit: please match order of the comments to how the condition is 
written in the code.

> +/* Update the static key controlling the evaluation of TIF_SPEC_IB */
> +static void update_indir_branch_cond(void)
> +{
> + if (!IS_ENABLED(CONFIG_SMP))
> + return;
> +
> + if (sched_smt_active())
> + static_branch_enable(_to_cond_stibp);
> + else
> + static_branch_disable(_to_cond_stibp);

So in the !SMP case sched_smt_active() is already doing the right thing:

  static inline bool sched_smt_active(void) { return false; }

I.e. couldn't we just remove the extra CONFIG_SMP condition?
This would simplify the code with some very minor expense on !SMP.

Thanks,

Ingo


[tip:perf/core] perf pmu: Move *_cpuid_str() weak functions to header.c

2018-11-21 Thread tip-bot for Kan Liang
Commit-ID:  f4a0742b3cc1d03b2ff448017b8c714a77e5a261
Gitweb: https://git.kernel.org/tip/f4a0742b3cc1d03b2ff448017b8c714a77e5a261
Author: Kan Liang 
AuthorDate: Wed, 21 Nov 2018 08:49:39 -0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:39:59 -0300

perf pmu: Move *_cpuid_str() weak functions to header.c

The weak functions, strcmp_cpuid_str() and get_cpuid_str(), are defined
in pmu.c.

Most of the cpuid related functions, including *_cpuid_str()'s
declaration and platform specific definition, are in header.c/h.

To make the declaration and definition of all cpuid related functions in
a consistent place, move the weak functions to header.c.

There is no functional change.

Suggested-by: Jiri Olsa 
Signed-off-by: Kan Liang 
Link: http://lkml.kernel.org/r/20181121164939.13482-1-kan.li...@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/header.c | 39 +++
 tools/perf/util/pmu.c| 39 ---
 2 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 4fd45be95a43..e31f52845e77 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -987,6 +987,45 @@ static int write_group_desc(struct feat_fd *ff,
return 0;
 }
 
+/*
+ * Return the CPU id as a raw string.
+ *
+ * Each architecture should provide a more precise id string that
+ * can be use to match the architecture's "mapfile".
+ */
+char * __weak get_cpuid_str(struct perf_pmu *pmu __maybe_unused)
+{
+   return NULL;
+}
+
+/* Return zero when the cpuid from the mapfile.csv matches the
+ * cpuid string generated on this platform.
+ * Otherwise return non-zero.
+ */
+int __weak strcmp_cpuid_str(const char *mapcpuid, const char *cpuid)
+{
+   regex_t re;
+   regmatch_t pmatch[1];
+   int match;
+
+   if (regcomp(, mapcpuid, REG_EXTENDED) != 0) {
+   /* Warn unable to generate match particular string. */
+   pr_info("Invalid regular expression %s\n", mapcpuid);
+   return 1;
+   }
+
+   match = !regexec(, cpuid, 1, pmatch, 0);
+   regfree();
+   if (match) {
+   size_t match_len = (pmatch[0].rm_eo - pmatch[0].rm_so);
+
+   /* Verify the entire string matched. */
+   if (match_len == strlen(cpuid))
+   return 0;
+   }
+   return 1;
+}
+
 /*
  * default get_cpuid(): nothing gets recorded
  * actual implementation must be in arch/$(SRCARCH)/util/header.c
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index c660625d7d4b..11a234740632 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -655,45 +655,6 @@ static int is_arm_pmu_core(const char *name)
return 0;
 }
 
-/*
- * Return the CPU id as a raw string.
- *
- * Each architecture should provide a more precise id string that
- * can be use to match the architecture's "mapfile".
- */
-char * __weak get_cpuid_str(struct perf_pmu *pmu __maybe_unused)
-{
-   return NULL;
-}
-
-/* Return zero when the cpuid from the mapfile.csv matches the
- * cpuid string generated on this platform.
- * Otherwise return non-zero.
- */
-int __weak strcmp_cpuid_str(const char *mapcpuid, const char *cpuid)
-{
-   regex_t re;
-   regmatch_t pmatch[1];
-   int match;
-
-   if (regcomp(, mapcpuid, REG_EXTENDED) != 0) {
-   /* Warn unable to generate match particular string. */
-   pr_info("Invalid regular expression %s\n", mapcpuid);
-   return 1;
-   }
-
-   match = !regexec(, cpuid, 1, pmatch, 0);
-   regfree();
-   if (match) {
-   size_t match_len = (pmatch[0].rm_eo - pmatch[0].rm_so);
-
-   /* Verify the entire string matched. */
-   if (match_len == strlen(cpuid))
-   return 0;
-   }
-   return 1;
-}
-
 static char *perf_pmu__getcpuid(struct perf_pmu *pmu)
 {
char *cpuid;


[tip:perf/core] perf pmu: Move *_cpuid_str() weak functions to header.c

2018-11-21 Thread tip-bot for Kan Liang
Commit-ID:  f4a0742b3cc1d03b2ff448017b8c714a77e5a261
Gitweb: https://git.kernel.org/tip/f4a0742b3cc1d03b2ff448017b8c714a77e5a261
Author: Kan Liang 
AuthorDate: Wed, 21 Nov 2018 08:49:39 -0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:39:59 -0300

perf pmu: Move *_cpuid_str() weak functions to header.c

The weak functions, strcmp_cpuid_str() and get_cpuid_str(), are defined
in pmu.c.

Most of the cpuid related functions, including *_cpuid_str()'s
declaration and platform specific definition, are in header.c/h.

To make the declaration and definition of all cpuid related functions in
a consistent place, move the weak functions to header.c.

There is no functional change.

Suggested-by: Jiri Olsa 
Signed-off-by: Kan Liang 
Link: http://lkml.kernel.org/r/20181121164939.13482-1-kan.li...@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/header.c | 39 +++
 tools/perf/util/pmu.c| 39 ---
 2 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 4fd45be95a43..e31f52845e77 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -987,6 +987,45 @@ static int write_group_desc(struct feat_fd *ff,
return 0;
 }
 
+/*
+ * Return the CPU id as a raw string.
+ *
+ * Each architecture should provide a more precise id string that
+ * can be use to match the architecture's "mapfile".
+ */
+char * __weak get_cpuid_str(struct perf_pmu *pmu __maybe_unused)
+{
+   return NULL;
+}
+
+/* Return zero when the cpuid from the mapfile.csv matches the
+ * cpuid string generated on this platform.
+ * Otherwise return non-zero.
+ */
+int __weak strcmp_cpuid_str(const char *mapcpuid, const char *cpuid)
+{
+   regex_t re;
+   regmatch_t pmatch[1];
+   int match;
+
+   if (regcomp(, mapcpuid, REG_EXTENDED) != 0) {
+   /* Warn unable to generate match particular string. */
+   pr_info("Invalid regular expression %s\n", mapcpuid);
+   return 1;
+   }
+
+   match = !regexec(, cpuid, 1, pmatch, 0);
+   regfree();
+   if (match) {
+   size_t match_len = (pmatch[0].rm_eo - pmatch[0].rm_so);
+
+   /* Verify the entire string matched. */
+   if (match_len == strlen(cpuid))
+   return 0;
+   }
+   return 1;
+}
+
 /*
  * default get_cpuid(): nothing gets recorded
  * actual implementation must be in arch/$(SRCARCH)/util/header.c
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index c660625d7d4b..11a234740632 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -655,45 +655,6 @@ static int is_arm_pmu_core(const char *name)
return 0;
 }
 
-/*
- * Return the CPU id as a raw string.
- *
- * Each architecture should provide a more precise id string that
- * can be use to match the architecture's "mapfile".
- */
-char * __weak get_cpuid_str(struct perf_pmu *pmu __maybe_unused)
-{
-   return NULL;
-}
-
-/* Return zero when the cpuid from the mapfile.csv matches the
- * cpuid string generated on this platform.
- * Otherwise return non-zero.
- */
-int __weak strcmp_cpuid_str(const char *mapcpuid, const char *cpuid)
-{
-   regex_t re;
-   regmatch_t pmatch[1];
-   int match;
-
-   if (regcomp(, mapcpuid, REG_EXTENDED) != 0) {
-   /* Warn unable to generate match particular string. */
-   pr_info("Invalid regular expression %s\n", mapcpuid);
-   return 1;
-   }
-
-   match = !regexec(, cpuid, 1, pmatch, 0);
-   regfree();
-   if (match) {
-   size_t match_len = (pmatch[0].rm_eo - pmatch[0].rm_so);
-
-   /* Verify the entire string matched. */
-   if (match_len == strlen(cpuid))
-   return 0;
-   }
-   return 1;
-}
-
 static char *perf_pmu__getcpuid(struct perf_pmu *pmu)
 {
char *cpuid;


[tip:perf/core] perf symbols: Fix slowness due to -ffunction-section

2018-11-21 Thread tip-bot for Eric Saint-Etienne
Commit-ID:  1e6285699b3034e6f4d1f091edd46d717580bf7c
Gitweb: https://git.kernel.org/tip/1e6285699b3034e6f4d1f091edd46d717580bf7c
Author: Eric Saint-Etienne 
AuthorDate: Wed, 21 Nov 2018 09:51:19 -0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:39:59 -0300

perf symbols: Fix slowness due to -ffunction-section

Perf can take minutes to parse an image when -ffunction-section is used.
This is especially true with the kernel image when it is compiled this
way, which is the arm64 default since the patcheset "Enable deadcode
elimination at link time".

Perf organize maps using a rbtree. Whenever perf finds a new symbols, it
first searches this rbtree for the map it belongs to, by strcmp()'aring
section names.  When it finds the map with the right name, it uses it to
add the symbol. With a usual image there aren't so many maps but when
using -ffunction-section there's basically one map per function.  With
the kernel image that's north of 40,000 maps. For most symbols perf has
to parses the entire rbtree to eventually create a new map and add it.
Consequently perf spends most of the time browsing a rbtree that keeps
getting larger.

This performance fix introduces a secondary rbtree that indexes maps
based on the section name.

Signed-off-by: Eric Saint-Etienne 
Reviewed-by: Dave Kleikamp 
Reviewed-by: David Aldridge 
Reviewed-by: Rob Gardner 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1542822679-25591-1-git-send-email-eric.saint.etie...@oracle.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/map.c| 27 +++
 tools/perf/util/map.h|  2 ++
 tools/perf/util/symbol.c | 15 +--
 3 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 354e54550d2b..781eed8e3265 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -21,6 +21,7 @@
 #include "unwind.h"
 
 static void __maps__insert(struct maps *maps, struct map *map);
+static void __maps__insert_name(struct maps *maps, struct map *map);
 
 static inline int is_anon_memory(const char *filename, u32 flags)
 {
@@ -496,6 +497,7 @@ u64 map__objdump_2mem(struct map *map, u64 ip)
 static void maps__init(struct maps *maps)
 {
maps->entries = RB_ROOT;
+   maps->names = RB_ROOT;
init_rwsem(>lock);
 }
 
@@ -664,6 +666,7 @@ size_t map_groups__fprintf(struct map_groups *mg, FILE *fp)
 static void __map_groups__insert(struct map_groups *mg, struct map *map)
 {
__maps__insert(>maps, map);
+   __maps__insert_name(>maps, map);
map->groups = mg;
 }
 
@@ -824,10 +827,34 @@ static void __maps__insert(struct maps *maps, struct map 
*map)
map__get(map);
 }
 
+static void __maps__insert_name(struct maps *maps, struct map *map)
+{
+   struct rb_node **p = >names.rb_node;
+   struct rb_node *parent = NULL;
+   struct map *m;
+   int rc;
+
+   while (*p != NULL) {
+   parent = *p;
+   m = rb_entry(parent, struct map, rb_node_name);
+   rc = strcmp(m->dso->short_name, map->dso->short_name);
+   if (rc < 0)
+   p = &(*p)->rb_left;
+   else if (rc  > 0)
+   p = &(*p)->rb_right;
+   else
+   return;
+   }
+   rb_link_node(>rb_node_name, parent, p);
+   rb_insert_color(>rb_node_name, >names);
+   map__get(map);
+}
+
 void maps__insert(struct maps *maps, struct map *map)
 {
down_write(>lock);
__maps__insert(maps, map);
+   __maps__insert_name(maps, map);
up_write(>lock);
 }
 
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index e0f327b51e66..5c792c90fc4c 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -25,6 +25,7 @@ struct map {
struct rb_node  rb_node;
struct list_head node;
};
+   struct rb_node  rb_node_name;
u64 start;
u64 end;
boolerange_warned;
@@ -57,6 +58,7 @@ struct kmap {
 
 struct maps {
struct rb_root   entries;
+   struct rb_root   names;
struct rw_semaphore lock;
 };
 
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index d188b7588152..dcce74bae6de 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1680,11 +1680,22 @@ struct map *map_groups__find_by_name(struct map_groups 
*mg, const char *name)
 {
struct maps *maps = >maps;
struct map *map;
+   struct rb_node *node;
 
down_read(>lock);
 
-   for (map = maps__first(maps); map; map = map__next(map)) {
-   if (map->dso && strcmp(map->dso->short_name, name) == 0)
+   for (node = maps->names.rb_node; node; ) {
+   int rc;
+
+   map = rb_entry(node, struct map, rb_node_name);
+
+  

[tip:perf/core] perf symbols: Fix slowness due to -ffunction-section

2018-11-21 Thread tip-bot for Eric Saint-Etienne
Commit-ID:  1e6285699b3034e6f4d1f091edd46d717580bf7c
Gitweb: https://git.kernel.org/tip/1e6285699b3034e6f4d1f091edd46d717580bf7c
Author: Eric Saint-Etienne 
AuthorDate: Wed, 21 Nov 2018 09:51:19 -0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:39:59 -0300

perf symbols: Fix slowness due to -ffunction-section

Perf can take minutes to parse an image when -ffunction-section is used.
This is especially true with the kernel image when it is compiled this
way, which is the arm64 default since the patcheset "Enable deadcode
elimination at link time".

Perf organize maps using a rbtree. Whenever perf finds a new symbols, it
first searches this rbtree for the map it belongs to, by strcmp()'aring
section names.  When it finds the map with the right name, it uses it to
add the symbol. With a usual image there aren't so many maps but when
using -ffunction-section there's basically one map per function.  With
the kernel image that's north of 40,000 maps. For most symbols perf has
to parses the entire rbtree to eventually create a new map and add it.
Consequently perf spends most of the time browsing a rbtree that keeps
getting larger.

This performance fix introduces a secondary rbtree that indexes maps
based on the section name.

Signed-off-by: Eric Saint-Etienne 
Reviewed-by: Dave Kleikamp 
Reviewed-by: David Aldridge 
Reviewed-by: Rob Gardner 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1542822679-25591-1-git-send-email-eric.saint.etie...@oracle.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/map.c| 27 +++
 tools/perf/util/map.h|  2 ++
 tools/perf/util/symbol.c | 15 +--
 3 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 354e54550d2b..781eed8e3265 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -21,6 +21,7 @@
 #include "unwind.h"
 
 static void __maps__insert(struct maps *maps, struct map *map);
+static void __maps__insert_name(struct maps *maps, struct map *map);
 
 static inline int is_anon_memory(const char *filename, u32 flags)
 {
@@ -496,6 +497,7 @@ u64 map__objdump_2mem(struct map *map, u64 ip)
 static void maps__init(struct maps *maps)
 {
maps->entries = RB_ROOT;
+   maps->names = RB_ROOT;
init_rwsem(>lock);
 }
 
@@ -664,6 +666,7 @@ size_t map_groups__fprintf(struct map_groups *mg, FILE *fp)
 static void __map_groups__insert(struct map_groups *mg, struct map *map)
 {
__maps__insert(>maps, map);
+   __maps__insert_name(>maps, map);
map->groups = mg;
 }
 
@@ -824,10 +827,34 @@ static void __maps__insert(struct maps *maps, struct map 
*map)
map__get(map);
 }
 
+static void __maps__insert_name(struct maps *maps, struct map *map)
+{
+   struct rb_node **p = >names.rb_node;
+   struct rb_node *parent = NULL;
+   struct map *m;
+   int rc;
+
+   while (*p != NULL) {
+   parent = *p;
+   m = rb_entry(parent, struct map, rb_node_name);
+   rc = strcmp(m->dso->short_name, map->dso->short_name);
+   if (rc < 0)
+   p = &(*p)->rb_left;
+   else if (rc  > 0)
+   p = &(*p)->rb_right;
+   else
+   return;
+   }
+   rb_link_node(>rb_node_name, parent, p);
+   rb_insert_color(>rb_node_name, >names);
+   map__get(map);
+}
+
 void maps__insert(struct maps *maps, struct map *map)
 {
down_write(>lock);
__maps__insert(maps, map);
+   __maps__insert_name(maps, map);
up_write(>lock);
 }
 
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index e0f327b51e66..5c792c90fc4c 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -25,6 +25,7 @@ struct map {
struct rb_node  rb_node;
struct list_head node;
};
+   struct rb_node  rb_node_name;
u64 start;
u64 end;
boolerange_warned;
@@ -57,6 +58,7 @@ struct kmap {
 
 struct maps {
struct rb_root   entries;
+   struct rb_root   names;
struct rw_semaphore lock;
 };
 
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index d188b7588152..dcce74bae6de 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1680,11 +1680,22 @@ struct map *map_groups__find_by_name(struct map_groups 
*mg, const char *name)
 {
struct maps *maps = >maps;
struct map *map;
+   struct rb_node *node;
 
down_read(>lock);
 
-   for (map = maps__first(maps); map; map = map__next(map)) {
-   if (map->dso && strcmp(map->dso->short_name, name) == 0)
+   for (node = maps->names.rb_node; node; ) {
+   int rc;
+
+   map = rb_entry(node, struct map, rb_node_name);
+
+  

[tip:perf/core] perf jvmti: Separate jvmti cmlr check

2018-11-21 Thread tip-bot for Jiri Olsa
Commit-ID:  dd1d0044dd1c1bf84a9b3e1f24e43347b26b96a0
Gitweb: https://git.kernel.org/tip/dd1d0044dd1c1bf84a9b3e1f24e43347b26b96a0
Author: Jiri Olsa 
AuthorDate: Wed, 21 Nov 2018 16:43:41 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:39:58 -0300

perf jvmti: Separate jvmti cmlr check

The Compiled Method Load Record (cmlr) is JDK specific interface to
access JVM stack info. This makes the jvmti agent code not compile under
another jdk, which does not support that.

Separating jvmti cmlr check into special feature check, and adding
HAVE_JVMTI_CMLR macro to indicate that.

Mark cmlr code in jvmti/libjvmti.c with HAVE_JVMTI_CMLR, so we can
compile it on system without cmlr support.

This change makes the jvmti compile with java-1.8.0-ibm package. It's
without the line numbers support, but the rest works.

Adding NO_JVMTI_CMLR compile variable for testing.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Ben Gainey 
Cc: Gustavo Luiz Duarte 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/r/20181121154341.21521-1-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/feature/Makefile  |  4 
 tools/build/feature/test-jvmti-cmlr.c | 11 +++
 tools/build/feature/test-jvmti.c  |  1 -
 tools/perf/Makefile.config|  7 +++
 tools/perf/Makefile.perf  |  3 +++
 tools/perf/jvmti/libjvmti.c   | 12 
 6 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 325087a0429c..38c22e122cb0 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -55,6 +55,7 @@ FILES=  \
  test-sdt.bin   \
  test-cxx.bin   \
  test-jvmti.bin\
+ test-jvmti-cmlr.bin   \
  test-sched_getcpu.bin \
  test-setns.bin\
  test-libopencsd.bin   \
@@ -267,6 +268,9 @@ $(OUTPUT)test-cxx.bin:
 $(OUTPUT)test-jvmti.bin:
$(BUILD)
 
+$(OUTPUT)test-jvmti-cmlr.bin:
+   $(BUILD)
+
 $(OUTPUT)test-llvm.bin:
$(BUILDXX) -std=gnu++11 \
-I$(shell $(LLVM_CONFIG) --includedir)  \
diff --git a/tools/build/feature/test-jvmti-cmlr.c 
b/tools/build/feature/test-jvmti-cmlr.c
new file mode 100644
index ..c27b5b71a0f6
--- /dev/null
+++ b/tools/build/feature/test-jvmti-cmlr.c
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
+#include 
+#include 
+
+int main(void)
+{
+   jvmtiCompiledMethodLoadInlineRecord rec __attribute__((unused));
+   jvmtiCompiledMethodLoadRecordHeader hdr __attribute__((unused));
+   PCStackInfo p   __attribute__((unused));
+   return 0;
+}
diff --git a/tools/build/feature/test-jvmti.c b/tools/build/feature/test-jvmti.c
index 5cf31192f204..799916d2e3e3 100644
--- a/tools/build/feature/test-jvmti.c
+++ b/tools/build/feature/test-jvmti.c
@@ -1,6 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
-#include 
 
 int main(void)
 {
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 376d1f78be04..e110010e7faa 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -855,6 +855,13 @@ ifndef NO_JVMTI
   $(call feature_check,jvmti)
   ifeq ($(feature-jvmti), 1)
 $(call detected_var,JDIR)
+ifndef NO_JVMTI_CMLR
+  FEATURE_CHECK_CFLAGS-jvmti-cmlr := $(FEATURE_CHECK_CFLAGS-jvmti)
+  $(call feature_check,jvmti-cmlr)
+  ifeq ($(feature-jvmti-cmlr), 1)
+CFLAGS += -DHAVE_JVMTI_CMLR
+  endif
+endif # NO_JVMTI_CMLR
   else
 $(warning No openjdk development package found, please install JDK 
package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel)
 NO_JVMTI := 1
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index d95655489f7e..239e7b3270f4 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -95,6 +95,9 @@ include ../scripts/utilities.mak
 #
 # Define NO_JVMTI if you do not want jvmti agent built
 #
+# Define NO_JVMTI_CMLR (debug only) if you do not want to process CMLR
+# data for java source lines.
+#
 # Define LIBCLANGLLVM if you DO want builtin clang and llvm support.
 # When selected, pass LLVM_CONFIG=/path/to/llvm-config to `make' if
 # llvm-config is not in $PATH.
diff --git a/tools/perf/jvmti/libjvmti.c b/tools/perf/jvmti/libjvmti.c
index 6add3e982614..aea7b1fe85aa 100644
--- a/tools/perf/jvmti/libjvmti.c
+++ b/tools/perf/jvmti/libjvmti.c
@@ -6,7 +6,9 @@
 #include 
 #include 
 #include 
+#ifdef HAVE_JVMTI_CMLR
 #include 
+#endif
 #include 
 
 #include "jvmti_agent.h"
@@ -27,6 +29,7 @@ static void print_error(jvmtiEnv *jvmti, const char *msg, 
jvmtiError ret)
}
 }
 
+#ifdef 

[tip:perf/core] perf jvmti: Separate jvmti cmlr check

2018-11-21 Thread tip-bot for Jiri Olsa
Commit-ID:  dd1d0044dd1c1bf84a9b3e1f24e43347b26b96a0
Gitweb: https://git.kernel.org/tip/dd1d0044dd1c1bf84a9b3e1f24e43347b26b96a0
Author: Jiri Olsa 
AuthorDate: Wed, 21 Nov 2018 16:43:41 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:39:58 -0300

perf jvmti: Separate jvmti cmlr check

The Compiled Method Load Record (cmlr) is JDK specific interface to
access JVM stack info. This makes the jvmti agent code not compile under
another jdk, which does not support that.

Separating jvmti cmlr check into special feature check, and adding
HAVE_JVMTI_CMLR macro to indicate that.

Mark cmlr code in jvmti/libjvmti.c with HAVE_JVMTI_CMLR, so we can
compile it on system without cmlr support.

This change makes the jvmti compile with java-1.8.0-ibm package. It's
without the line numbers support, but the rest works.

Adding NO_JVMTI_CMLR compile variable for testing.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Ben Gainey 
Cc: Gustavo Luiz Duarte 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/r/20181121154341.21521-1-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/feature/Makefile  |  4 
 tools/build/feature/test-jvmti-cmlr.c | 11 +++
 tools/build/feature/test-jvmti.c  |  1 -
 tools/perf/Makefile.config|  7 +++
 tools/perf/Makefile.perf  |  3 +++
 tools/perf/jvmti/libjvmti.c   | 12 
 6 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 325087a0429c..38c22e122cb0 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -55,6 +55,7 @@ FILES=  \
  test-sdt.bin   \
  test-cxx.bin   \
  test-jvmti.bin\
+ test-jvmti-cmlr.bin   \
  test-sched_getcpu.bin \
  test-setns.bin\
  test-libopencsd.bin   \
@@ -267,6 +268,9 @@ $(OUTPUT)test-cxx.bin:
 $(OUTPUT)test-jvmti.bin:
$(BUILD)
 
+$(OUTPUT)test-jvmti-cmlr.bin:
+   $(BUILD)
+
 $(OUTPUT)test-llvm.bin:
$(BUILDXX) -std=gnu++11 \
-I$(shell $(LLVM_CONFIG) --includedir)  \
diff --git a/tools/build/feature/test-jvmti-cmlr.c 
b/tools/build/feature/test-jvmti-cmlr.c
new file mode 100644
index ..c27b5b71a0f6
--- /dev/null
+++ b/tools/build/feature/test-jvmti-cmlr.c
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
+#include 
+#include 
+
+int main(void)
+{
+   jvmtiCompiledMethodLoadInlineRecord rec __attribute__((unused));
+   jvmtiCompiledMethodLoadRecordHeader hdr __attribute__((unused));
+   PCStackInfo p   __attribute__((unused));
+   return 0;
+}
diff --git a/tools/build/feature/test-jvmti.c b/tools/build/feature/test-jvmti.c
index 5cf31192f204..799916d2e3e3 100644
--- a/tools/build/feature/test-jvmti.c
+++ b/tools/build/feature/test-jvmti.c
@@ -1,6 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
-#include 
 
 int main(void)
 {
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 376d1f78be04..e110010e7faa 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -855,6 +855,13 @@ ifndef NO_JVMTI
   $(call feature_check,jvmti)
   ifeq ($(feature-jvmti), 1)
 $(call detected_var,JDIR)
+ifndef NO_JVMTI_CMLR
+  FEATURE_CHECK_CFLAGS-jvmti-cmlr := $(FEATURE_CHECK_CFLAGS-jvmti)
+  $(call feature_check,jvmti-cmlr)
+  ifeq ($(feature-jvmti-cmlr), 1)
+CFLAGS += -DHAVE_JVMTI_CMLR
+  endif
+endif # NO_JVMTI_CMLR
   else
 $(warning No openjdk development package found, please install JDK 
package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel)
 NO_JVMTI := 1
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index d95655489f7e..239e7b3270f4 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -95,6 +95,9 @@ include ../scripts/utilities.mak
 #
 # Define NO_JVMTI if you do not want jvmti agent built
 #
+# Define NO_JVMTI_CMLR (debug only) if you do not want to process CMLR
+# data for java source lines.
+#
 # Define LIBCLANGLLVM if you DO want builtin clang and llvm support.
 # When selected, pass LLVM_CONFIG=/path/to/llvm-config to `make' if
 # llvm-config is not in $PATH.
diff --git a/tools/perf/jvmti/libjvmti.c b/tools/perf/jvmti/libjvmti.c
index 6add3e982614..aea7b1fe85aa 100644
--- a/tools/perf/jvmti/libjvmti.c
+++ b/tools/perf/jvmti/libjvmti.c
@@ -6,7 +6,9 @@
 #include 
 #include 
 #include 
+#ifdef HAVE_JVMTI_CMLR
 #include 
+#endif
 #include 
 
 #include "jvmti_agent.h"
@@ -27,6 +29,7 @@ static void print_error(jvmtiEnv *jvmti, const char *msg, 
jvmtiError ret)
}
 }
 
+#ifdef 

Re: [PATCH 4.19 00/42] 4.19.4-stable review

2018-11-21 Thread Harsh Shandilya
On 22 November 2018 12:35:36 AM IST, Greg Kroah-Hartman 
 wrote:
>This is the start of the stable review cycle for the 4.19.4 release.
>There are 42 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 Fri Nov 23 18:31:31 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.19.4-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.19.y
>and the diffstat can be found below.
>
>thanks,
>
>greg k-h
Built and booted on the Lenovo IdeaPad 330-15ARR, no dmesg regressions.
-- 
Harsh Shandilya
PRJKT Development LLC


Re: [PATCH 4.19 00/42] 4.19.4-stable review

2018-11-21 Thread Harsh Shandilya
On 22 November 2018 12:35:36 AM IST, Greg Kroah-Hartman 
 wrote:
>This is the start of the stable review cycle for the 4.19.4 release.
>There are 42 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 Fri Nov 23 18:31:31 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.19.4-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.19.y
>and the diffstat can be found below.
>
>thanks,
>
>greg k-h
Built and booted on the Lenovo IdeaPad 330-15ARR, no dmesg regressions.
-- 
Harsh Shandilya
PRJKT Development LLC


[tip:perf/core] perf vendor events: Add stepping in CPUID string for x86

2018-11-21 Thread tip-bot for Kan Liang
Commit-ID:  3b54411a4485c9f1d50f003810ecfceca82a09ae
Gitweb: https://git.kernel.org/tip/3b54411a4485c9f1d50f003810ecfceca82a09ae
Author: Kan Liang 
AuthorDate: Wed, 14 Nov 2018 13:24:15 -0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:39:57 -0300

perf vendor events: Add stepping in CPUID string for x86

The perf tools cannot find the proper event list for the Cascadelake
server.  Because the Cascadelake server and the Skylake server have the
same CPU model number, which are used by the perf tools to find the
event list.

The stepping for Skylake server is up to 4.

The stepping for Cascadelake server starts from 5.

The stepping can be used to distinguish between them.

The stepping is added in get_cpuid_str().

The stepping information for Skylake server is updated in mapfile.csv.

A x86 specific strcmp_cpuid_cmp() function is added to handle two CPUID
formats in mapfile.csv, "vendor-family-model-stepping" and
"vendor-family-model":

- If a cpuid-regular-expression from the mapfile.csv using the new
  stepping format, a cpuid-string generated on the machine must include
  stepping. Otherwise, it is a mismatch.

- If the cpuid-regular-expression using the old non-stepping format,
  the stepping in the cpuid-string will be ignored.

The script, using environment string "PERF_CPUID" without stepping on
Skylake server, will be broken. If so, users must fix their scripts.

Committer notes:

Fixed this build error on centos:6 and debian:7:

  arch/x86/util/header.c: In function 'is_full_cpuid':
  arch/x86/util/header.c:82:39: error: declaration of 'cpuid' shadows a global 
declaration [-Werror=shadow]
  arch/x86/util/header.c:12:1: error: shadowed declaration is here 
[-Werror=shadow]
  arch/x86/util/header.c: In function 'strcmp_cpuid_str':
  arch/x86/util/header.c:98:56: error: declaration of 'cpuid' shadows a global 
declaration [-Werror=shadow]
  arch/x86/util/header.c:12:1: error: shadowed declaration is here 
[-Werror=shadow]
  cc1: all warnings being treated as errors

Signed-off-by: Kan Liang 
Reviewed-by: Jiri Olsa 
Cc: Andi Kleen 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20181114212416.15665-1-kan.li...@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/x86/util/header.c  | 66 +-
 tools/perf/pmu-events/arch/x86/mapfile.csv |  2 +-
 tools/perf/util/pmu.c  |  2 +-
 3 files changed, 67 insertions(+), 3 deletions(-)

diff --git a/tools/perf/arch/x86/util/header.c 
b/tools/perf/arch/x86/util/header.c
index fb0d71afee8b..af9a9f2600be 100644
--- a/tools/perf/arch/x86/util/header.c
+++ b/tools/perf/arch/x86/util/header.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../../util/header.h"
 
@@ -70,9 +71,72 @@ get_cpuid_str(struct perf_pmu *pmu __maybe_unused)
 {
char *buf = malloc(128);
 
-   if (buf && __get_cpuid(buf, 128, "%s-%u-%X$") < 0) {
+   if (buf && __get_cpuid(buf, 128, "%s-%u-%X-%X$") < 0) {
free(buf);
return NULL;
}
return buf;
 }
+
+/* Full CPUID format for x86 is vendor-family-model-stepping */
+static bool is_full_cpuid(const char *id)
+{
+   const char *tmp = id;
+   int count = 0;
+
+   while ((tmp = strchr(tmp, '-')) != NULL) {
+   count++;
+   tmp++;
+   }
+
+   if (count == 3)
+   return true;
+
+   return false;
+}
+
+int strcmp_cpuid_str(const char *mapcpuid, const char *id)
+{
+   regex_t re;
+   regmatch_t pmatch[1];
+   int match;
+   bool full_mapcpuid = is_full_cpuid(mapcpuid);
+   bool full_cpuid = is_full_cpuid(id);
+
+   /*
+* Full CPUID format is required to identify a platform.
+* Error out if the cpuid string is incomplete.
+*/
+   if (full_mapcpuid && !full_cpuid) {
+   pr_info("Invalid CPUID %s. Full CPUID is required, "
+   "vendor-family-model-stepping\n", id);
+   return 1;
+   }
+
+   if (regcomp(, mapcpuid, REG_EXTENDED) != 0) {
+   /* Warn unable to generate match particular string. */
+   pr_info("Invalid regular expression %s\n", mapcpuid);
+   return 1;
+   }
+
+   match = !regexec(, id, 1, pmatch, 0);
+   regfree();
+   if (match) {
+   size_t match_len = (pmatch[0].rm_eo - pmatch[0].rm_so);
+   size_t cpuid_len;
+
+   /* If the full CPUID format isn't required,
+* ignoring the stepping.
+*/
+   if (!full_mapcpuid && full_cpuid)
+   cpuid_len = strrchr(id, '-') - id;
+   else
+   cpuid_len = strlen(id);
+
+   /* Verify the entire string matched. */
+   if (match_len == cpuid_len)
+   return 0;
+   }
+
+   return 1;
+}
diff --git 

[tip:perf/core] perf vendor events: Add stepping in CPUID string for x86

2018-11-21 Thread tip-bot for Kan Liang
Commit-ID:  3b54411a4485c9f1d50f003810ecfceca82a09ae
Gitweb: https://git.kernel.org/tip/3b54411a4485c9f1d50f003810ecfceca82a09ae
Author: Kan Liang 
AuthorDate: Wed, 14 Nov 2018 13:24:15 -0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:39:57 -0300

perf vendor events: Add stepping in CPUID string for x86

The perf tools cannot find the proper event list for the Cascadelake
server.  Because the Cascadelake server and the Skylake server have the
same CPU model number, which are used by the perf tools to find the
event list.

The stepping for Skylake server is up to 4.

The stepping for Cascadelake server starts from 5.

The stepping can be used to distinguish between them.

The stepping is added in get_cpuid_str().

The stepping information for Skylake server is updated in mapfile.csv.

A x86 specific strcmp_cpuid_cmp() function is added to handle two CPUID
formats in mapfile.csv, "vendor-family-model-stepping" and
"vendor-family-model":

- If a cpuid-regular-expression from the mapfile.csv using the new
  stepping format, a cpuid-string generated on the machine must include
  stepping. Otherwise, it is a mismatch.

- If the cpuid-regular-expression using the old non-stepping format,
  the stepping in the cpuid-string will be ignored.

The script, using environment string "PERF_CPUID" without stepping on
Skylake server, will be broken. If so, users must fix their scripts.

Committer notes:

Fixed this build error on centos:6 and debian:7:

  arch/x86/util/header.c: In function 'is_full_cpuid':
  arch/x86/util/header.c:82:39: error: declaration of 'cpuid' shadows a global 
declaration [-Werror=shadow]
  arch/x86/util/header.c:12:1: error: shadowed declaration is here 
[-Werror=shadow]
  arch/x86/util/header.c: In function 'strcmp_cpuid_str':
  arch/x86/util/header.c:98:56: error: declaration of 'cpuid' shadows a global 
declaration [-Werror=shadow]
  arch/x86/util/header.c:12:1: error: shadowed declaration is here 
[-Werror=shadow]
  cc1: all warnings being treated as errors

Signed-off-by: Kan Liang 
Reviewed-by: Jiri Olsa 
Cc: Andi Kleen 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20181114212416.15665-1-kan.li...@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/x86/util/header.c  | 66 +-
 tools/perf/pmu-events/arch/x86/mapfile.csv |  2 +-
 tools/perf/util/pmu.c  |  2 +-
 3 files changed, 67 insertions(+), 3 deletions(-)

diff --git a/tools/perf/arch/x86/util/header.c 
b/tools/perf/arch/x86/util/header.c
index fb0d71afee8b..af9a9f2600be 100644
--- a/tools/perf/arch/x86/util/header.c
+++ b/tools/perf/arch/x86/util/header.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../../util/header.h"
 
@@ -70,9 +71,72 @@ get_cpuid_str(struct perf_pmu *pmu __maybe_unused)
 {
char *buf = malloc(128);
 
-   if (buf && __get_cpuid(buf, 128, "%s-%u-%X$") < 0) {
+   if (buf && __get_cpuid(buf, 128, "%s-%u-%X-%X$") < 0) {
free(buf);
return NULL;
}
return buf;
 }
+
+/* Full CPUID format for x86 is vendor-family-model-stepping */
+static bool is_full_cpuid(const char *id)
+{
+   const char *tmp = id;
+   int count = 0;
+
+   while ((tmp = strchr(tmp, '-')) != NULL) {
+   count++;
+   tmp++;
+   }
+
+   if (count == 3)
+   return true;
+
+   return false;
+}
+
+int strcmp_cpuid_str(const char *mapcpuid, const char *id)
+{
+   regex_t re;
+   regmatch_t pmatch[1];
+   int match;
+   bool full_mapcpuid = is_full_cpuid(mapcpuid);
+   bool full_cpuid = is_full_cpuid(id);
+
+   /*
+* Full CPUID format is required to identify a platform.
+* Error out if the cpuid string is incomplete.
+*/
+   if (full_mapcpuid && !full_cpuid) {
+   pr_info("Invalid CPUID %s. Full CPUID is required, "
+   "vendor-family-model-stepping\n", id);
+   return 1;
+   }
+
+   if (regcomp(, mapcpuid, REG_EXTENDED) != 0) {
+   /* Warn unable to generate match particular string. */
+   pr_info("Invalid regular expression %s\n", mapcpuid);
+   return 1;
+   }
+
+   match = !regexec(, id, 1, pmatch, 0);
+   regfree();
+   if (match) {
+   size_t match_len = (pmatch[0].rm_eo - pmatch[0].rm_so);
+   size_t cpuid_len;
+
+   /* If the full CPUID format isn't required,
+* ignoring the stepping.
+*/
+   if (!full_mapcpuid && full_cpuid)
+   cpuid_len = strrchr(id, '-') - id;
+   else
+   cpuid_len = strlen(id);
+
+   /* Verify the entire string matched. */
+   if (match_len == cpuid_len)
+   return 0;
+   }
+
+   return 1;
+}
diff --git 

[tip:perf/core] perf pmu: Suppress potential format-truncation warning

2018-11-21 Thread tip-bot for Ben Hutchings
Commit-ID:  11a64a05dc649815670b1be9fe63d205cb076401
Gitweb: https://git.kernel.org/tip/11a64a05dc649815670b1be9fe63d205cb076401
Author: Ben Hutchings 
AuthorDate: Sun, 11 Nov 2018 18:45:24 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:39:56 -0300

perf pmu: Suppress potential format-truncation warning

Depending on which functions are inlined in util/pmu.c, the snprintf()
calls in perf_pmu__parse_{scale,unit,per_pkg,snapshot}() might trigger a
warning:

  util/pmu.c: In function 'pmu_aliases':
  util/pmu.c:178:31: error: '%s' directive output may be truncated writing up 
to 255 bytes into a region of size between 0 and 4095 
[-Werror=format-truncation=]
snprintf(path, PATH_MAX, "%s/%s.unit", dir, name);
   ^~

I found this when trying to build perf from Linux 3.16 with gcc 8.
However I can reproduce the problem in mainline if I force
__perf_pmu__new_alias() to be inlined.

Suppress this by using scnprintf() as has been done elsewhere in perf.

Signed-off-by: Ben Hutchings 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/r/2018184524.fux4taownc6nd...@decadent.org.uk
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/pmu.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 7e49baad304d..7348eea0248f 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -145,7 +145,7 @@ static int perf_pmu__parse_scale(struct perf_pmu_alias 
*alias, char *dir, char *
int fd, ret = -1;
char path[PATH_MAX];
 
-   snprintf(path, PATH_MAX, "%s/%s.scale", dir, name);
+   scnprintf(path, PATH_MAX, "%s/%s.scale", dir, name);
 
fd = open(path, O_RDONLY);
if (fd == -1)
@@ -175,7 +175,7 @@ static int perf_pmu__parse_unit(struct perf_pmu_alias 
*alias, char *dir, char *n
ssize_t sret;
int fd;
 
-   snprintf(path, PATH_MAX, "%s/%s.unit", dir, name);
+   scnprintf(path, PATH_MAX, "%s/%s.unit", dir, name);
 
fd = open(path, O_RDONLY);
if (fd == -1)
@@ -205,7 +205,7 @@ perf_pmu__parse_per_pkg(struct perf_pmu_alias *alias, char 
*dir, char *name)
char path[PATH_MAX];
int fd;
 
-   snprintf(path, PATH_MAX, "%s/%s.per-pkg", dir, name);
+   scnprintf(path, PATH_MAX, "%s/%s.per-pkg", dir, name);
 
fd = open(path, O_RDONLY);
if (fd == -1)
@@ -223,7 +223,7 @@ static int perf_pmu__parse_snapshot(struct perf_pmu_alias 
*alias,
char path[PATH_MAX];
int fd;
 
-   snprintf(path, PATH_MAX, "%s/%s.snapshot", dir, name);
+   scnprintf(path, PATH_MAX, "%s/%s.snapshot", dir, name);
 
fd = open(path, O_RDONLY);
if (fd == -1)


[tip:perf/core] perf tools: Add Hygon Dhyana support

2018-11-21 Thread tip-bot for Pu Wen
Commit-ID:  4787eff3fa88f62fede6ed7afa06477ae6bf984d
Gitweb: https://git.kernel.org/tip/4787eff3fa88f62fede6ed7afa06477ae6bf984d
Author: Pu Wen 
AuthorDate: Mon, 12 Nov 2018 15:40:51 +0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:39:56 -0300

perf tools: Add Hygon Dhyana support

The tool perf is useful for the performance analysis on the Hygon Dhyana
platform. But right now there is no Hygon support for it to analyze the
KVM guest os data. So add Hygon Dhyana support to it by checking vendor
string to share the code path of AMD.

Signed-off-by: Pu Wen 
Acked-by: Borislav Petkov 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1542008451-31735-1-git-send-email-pu...@hygon.cn
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/x86/util/kvm-stat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/arch/x86/util/kvm-stat.c 
b/tools/perf/arch/x86/util/kvm-stat.c
index b32409a0e546..081353d7b095 100644
--- a/tools/perf/arch/x86/util/kvm-stat.c
+++ b/tools/perf/arch/x86/util/kvm-stat.c
@@ -156,7 +156,7 @@ int cpu_isa_init(struct perf_kvm_stat *kvm, const char 
*cpuid)
if (strstr(cpuid, "Intel")) {
kvm->exit_reasons = vmx_exit_reasons;
kvm->exit_reasons_isa = "VMX";
-   } else if (strstr(cpuid, "AMD")) {
+   } else if (strstr(cpuid, "AMD") || strstr(cpuid, "Hygon")) {
kvm->exit_reasons = svm_exit_reasons;
kvm->exit_reasons_isa = "SVM";
} else


[tip:perf/core] perf stat: Use perf_evsel__is_clocki() for clock events

2018-11-21 Thread tip-bot for Ravi Bangoria
Commit-ID:  eb08d006054e7e374592068919e32579988602d4
Gitweb: https://git.kernel.org/tip/eb08d006054e7e374592068919e32579988602d4
Author: Ravi Bangoria 
AuthorDate: Thu, 15 Nov 2018 15:25:32 +0530
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:39:57 -0300

perf stat: Use perf_evsel__is_clocki() for clock events

We already have function to check if a given event is either
SW_CPU_CLOCK or SW_TASK_CLOCK. Utilize it.

Signed-off-by: Ravi Bangoria 
Acked-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Anton Blanchard 
Cc: Jin Yao 
Cc: Namhyung Kim 
Cc: Thomas Richter 
Cc: yuzhouj...@didichuxing.com
Link: 
http://lkml.kernel.org/r/20181115095533.16930-1-ravi.bango...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/stat-shadow.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 8ad32763cfff..f0a8cec55c47 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -212,8 +212,7 @@ void perf_stat__update_shadow_stats(struct perf_evsel 
*counter, u64 count,
 
count *= counter->scale;
 
-   if (perf_evsel__match(counter, SOFTWARE, SW_TASK_CLOCK) ||
-   perf_evsel__match(counter, SOFTWARE, SW_CPU_CLOCK))
+   if (perf_evsel__is_clock(counter))
update_runtime_stat(st, STAT_NSECS, 0, cpu, count);
else if (perf_evsel__match(counter, HARDWARE, HW_CPU_CYCLES))
update_runtime_stat(st, STAT_CYCLES, ctx, cpu, count);


[tip:perf/core] perf pmu: Suppress potential format-truncation warning

2018-11-21 Thread tip-bot for Ben Hutchings
Commit-ID:  11a64a05dc649815670b1be9fe63d205cb076401
Gitweb: https://git.kernel.org/tip/11a64a05dc649815670b1be9fe63d205cb076401
Author: Ben Hutchings 
AuthorDate: Sun, 11 Nov 2018 18:45:24 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:39:56 -0300

perf pmu: Suppress potential format-truncation warning

Depending on which functions are inlined in util/pmu.c, the snprintf()
calls in perf_pmu__parse_{scale,unit,per_pkg,snapshot}() might trigger a
warning:

  util/pmu.c: In function 'pmu_aliases':
  util/pmu.c:178:31: error: '%s' directive output may be truncated writing up 
to 255 bytes into a region of size between 0 and 4095 
[-Werror=format-truncation=]
snprintf(path, PATH_MAX, "%s/%s.unit", dir, name);
   ^~

I found this when trying to build perf from Linux 3.16 with gcc 8.
However I can reproduce the problem in mainline if I force
__perf_pmu__new_alias() to be inlined.

Suppress this by using scnprintf() as has been done elsewhere in perf.

Signed-off-by: Ben Hutchings 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/r/2018184524.fux4taownc6nd...@decadent.org.uk
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/pmu.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 7e49baad304d..7348eea0248f 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -145,7 +145,7 @@ static int perf_pmu__parse_scale(struct perf_pmu_alias 
*alias, char *dir, char *
int fd, ret = -1;
char path[PATH_MAX];
 
-   snprintf(path, PATH_MAX, "%s/%s.scale", dir, name);
+   scnprintf(path, PATH_MAX, "%s/%s.scale", dir, name);
 
fd = open(path, O_RDONLY);
if (fd == -1)
@@ -175,7 +175,7 @@ static int perf_pmu__parse_unit(struct perf_pmu_alias 
*alias, char *dir, char *n
ssize_t sret;
int fd;
 
-   snprintf(path, PATH_MAX, "%s/%s.unit", dir, name);
+   scnprintf(path, PATH_MAX, "%s/%s.unit", dir, name);
 
fd = open(path, O_RDONLY);
if (fd == -1)
@@ -205,7 +205,7 @@ perf_pmu__parse_per_pkg(struct perf_pmu_alias *alias, char 
*dir, char *name)
char path[PATH_MAX];
int fd;
 
-   snprintf(path, PATH_MAX, "%s/%s.per-pkg", dir, name);
+   scnprintf(path, PATH_MAX, "%s/%s.per-pkg", dir, name);
 
fd = open(path, O_RDONLY);
if (fd == -1)
@@ -223,7 +223,7 @@ static int perf_pmu__parse_snapshot(struct perf_pmu_alias 
*alias,
char path[PATH_MAX];
int fd;
 
-   snprintf(path, PATH_MAX, "%s/%s.snapshot", dir, name);
+   scnprintf(path, PATH_MAX, "%s/%s.snapshot", dir, name);
 
fd = open(path, O_RDONLY);
if (fd == -1)


[tip:perf/core] perf tools: Add Hygon Dhyana support

2018-11-21 Thread tip-bot for Pu Wen
Commit-ID:  4787eff3fa88f62fede6ed7afa06477ae6bf984d
Gitweb: https://git.kernel.org/tip/4787eff3fa88f62fede6ed7afa06477ae6bf984d
Author: Pu Wen 
AuthorDate: Mon, 12 Nov 2018 15:40:51 +0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:39:56 -0300

perf tools: Add Hygon Dhyana support

The tool perf is useful for the performance analysis on the Hygon Dhyana
platform. But right now there is no Hygon support for it to analyze the
KVM guest os data. So add Hygon Dhyana support to it by checking vendor
string to share the code path of AMD.

Signed-off-by: Pu Wen 
Acked-by: Borislav Petkov 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1542008451-31735-1-git-send-email-pu...@hygon.cn
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/x86/util/kvm-stat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/arch/x86/util/kvm-stat.c 
b/tools/perf/arch/x86/util/kvm-stat.c
index b32409a0e546..081353d7b095 100644
--- a/tools/perf/arch/x86/util/kvm-stat.c
+++ b/tools/perf/arch/x86/util/kvm-stat.c
@@ -156,7 +156,7 @@ int cpu_isa_init(struct perf_kvm_stat *kvm, const char 
*cpuid)
if (strstr(cpuid, "Intel")) {
kvm->exit_reasons = vmx_exit_reasons;
kvm->exit_reasons_isa = "VMX";
-   } else if (strstr(cpuid, "AMD")) {
+   } else if (strstr(cpuid, "AMD") || strstr(cpuid, "Hygon")) {
kvm->exit_reasons = svm_exit_reasons;
kvm->exit_reasons_isa = "SVM";
} else


[tip:perf/core] perf stat: Use perf_evsel__is_clocki() for clock events

2018-11-21 Thread tip-bot for Ravi Bangoria
Commit-ID:  eb08d006054e7e374592068919e32579988602d4
Gitweb: https://git.kernel.org/tip/eb08d006054e7e374592068919e32579988602d4
Author: Ravi Bangoria 
AuthorDate: Thu, 15 Nov 2018 15:25:32 +0530
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:39:57 -0300

perf stat: Use perf_evsel__is_clocki() for clock events

We already have function to check if a given event is either
SW_CPU_CLOCK or SW_TASK_CLOCK. Utilize it.

Signed-off-by: Ravi Bangoria 
Acked-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Anton Blanchard 
Cc: Jin Yao 
Cc: Namhyung Kim 
Cc: Thomas Richter 
Cc: yuzhouj...@didichuxing.com
Link: 
http://lkml.kernel.org/r/20181115095533.16930-1-ravi.bango...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/stat-shadow.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 8ad32763cfff..f0a8cec55c47 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -212,8 +212,7 @@ void perf_stat__update_shadow_stats(struct perf_evsel 
*counter, u64 count,
 
count *= counter->scale;
 
-   if (perf_evsel__match(counter, SOFTWARE, SW_TASK_CLOCK) ||
-   perf_evsel__match(counter, SOFTWARE, SW_CPU_CLOCK))
+   if (perf_evsel__is_clock(counter))
update_runtime_stat(st, STAT_NSECS, 0, cpu, count);
else if (perf_evsel__match(counter, HARDWARE, HW_CPU_CYCLES))
update_runtime_stat(st, STAT_CYCLES, ctx, cpu, count);


[tip:perf/core] perf bench: Add epoll_ctl(2) benchmark

2018-11-21 Thread tip-bot for Davidlohr Bueso
Commit-ID:  231457ec707475c71d4e538a3253f1ed9e294cf0
Gitweb: https://git.kernel.org/tip/231457ec707475c71d4e538a3253f1ed9e294cf0
Author: Davidlohr Bueso 
AuthorDate: Tue, 6 Nov 2018 07:22:26 -0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:39:55 -0300

perf bench: Add epoll_ctl(2) benchmark

Benchmark the various operations allowed for epoll_ctl(2).  The idea is
to concurrently stress a single epoll instance doing add/mod/del
operations.

Committer testing:

  # perf bench epoll ctl
  # Running 'epoll/ctl' benchmark:
  Run summary [PID 20344]: 4 threads doing epoll_ctl ops 64 file-descriptors 
for 8 secs.

  [thread  0] fdmap: 0x21a46b0 ... 0x21a47ac [ add: 1680960 ops; mod: 1680960 
ops; del: 1680960 ops ]
  [thread  1] fdmap: 0x21a4960 ... 0x21a4a5c [ add: 1685440 ops; mod: 1685440 
ops; del: 1685440 ops ]
  [thread  2] fdmap: 0x21a4c10 ... 0x21a4d0c [ add: 1674368 ops; mod: 1674368 
ops; del: 1674368 ops ]
  [thread  3] fdmap: 0x21a4ec0 ... 0x21a4fbc [ add: 1677568 ops; mod: 1677568 
ops; del: 1677568 ops ]

  Averaged 1679584 ADD operations (+- 0.14%)
  Averaged 1679584 MOD operations (+- 0.14%)
  Averaged 1679584 DEL operations (+- 0.14%)
  #

Lets measure those calls with 'perf trace' to get a glympse at what this
benchmark is doing in terms of syscalls:

  # perf trace -m32768 -s perf bench epoll ctl
  # Running 'epoll/ctl' benchmark:
  Run summary [PID 20405]: 4 threads doing epoll_ctl ops 64 file-descriptors 
for 8 secs.

  [thread  0] fdmap: 0x21764e0 ... 0x21765dc [ add: 1100480 ops; mod: 1100480 
ops; del: 1100480 ops ]
  [thread  1] fdmap: 0x2176790 ... 0x217688c [ add: 1250176 ops; mod: 1250176 
ops; del: 1250176 ops ]
  [thread  2] fdmap: 0x2176a40 ... 0x2176b3c [ add: 1022464 ops; mod: 1022464 
ops; del: 1022464 ops ]
  [thread  3] fdmap: 0x2176cf0 ... 0x2176dec [ add: 705472 ops; mod: 705472 
ops; del: 705472 ops ]

  Averaged 1019648 ADD operations (+- 11.27%)
  Averaged 1019648 MOD operations (+- 11.27%)
  Averaged 1019648 DEL operations (+- 11.27%)

  Summary of events:

  epoll-ctl (20405), 1264 events, 0.0%

   syscallcallstotal   min   avg   max  stddev
   (msec)(msec)(msec)(msec)(%)
   ---  - - - - --
   eventfd2 256 9.514 0.001 0.037 5.243 68.00%
   clone  4 1.245 0.204 0.311 0.531 24.13%
   mprotect  66 0.345 0.002 0.005 0.021  7.43%
   openat45 0.313 0.004 0.007 0.073 21.93%
   mmap  88 0.302 0.002 0.003 0.013  5.02%
   futex  4 0.160 0.002 0.040 0.140 83.43%
   sched_setaffinity  4 0.124 0.005 0.031 0.070 49.39%
   read  44 0.103 0.001 0.002 0.013 15.54%
   fstat 40 0.052 0.001 0.001 0.003  5.43%
   close 39 0.039 0.001 0.001 0.001  1.48%
   stat   9 0.034 0.003 0.004 0.006  7.30%
   access 3 0.023 0.007 0.008 0.008  4.25%
   open   2 0.021 0.008 0.011 0.013 22.60%
   getdents   4 0.019 0.001 0.005 0.009 37.15%
   write  2 0.013 0.004 0.007 0.009 38.48%
   munmap 1 0.010 0.010 0.010 0.010  0.00%
   brk3 0.006 0.001 0.002 0.003 26.34%
   rt_sigprocmask 2 0.004 0.001 0.002 0.003 43.95%
   rt_sigaction   3 0.004 0.001 0.001 0.002 16.07%
   prlimit64  3 0.004 0.001 0.001 0.001  5.39%
   prctl  1 0.003 0.003 0.003 0.003  0.00%
   epoll_create   1 0.003 0.003 0.003 0.003  0.00%
   lseek  2 0.002 0.001 0.001 0.001 11.42%
   sched_getaffinity1 0.002 0.002 0.002 0.002  0.00%
   arch_prctl 1 0.002 0.002 0.002 0.002  0.00%
   set_tid_address1 0.001 0.001 0.001 0.001  0.00%
   getpid 1 0.001 0.001 0.001 0.001  0.00%
   set_robust_list1 0.001 0.001 0.001 0.001  0.00%
   execve 1 0.000 0.000 0.000 0.000  0.00%

 epoll-ctl (20406), 1245480 events, 14.6%

   syscallcallstotal   min   avg   max  stddev
   (msec)(msec)(msec)(msec)(%)
   ---  - - - - --
   epoll_ctl 619511  1034.927 0.001 0.002 6.691  0.67%
   

[tip:perf/core] perf bench: Add epoll_ctl(2) benchmark

2018-11-21 Thread tip-bot for Davidlohr Bueso
Commit-ID:  231457ec707475c71d4e538a3253f1ed9e294cf0
Gitweb: https://git.kernel.org/tip/231457ec707475c71d4e538a3253f1ed9e294cf0
Author: Davidlohr Bueso 
AuthorDate: Tue, 6 Nov 2018 07:22:26 -0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:39:55 -0300

perf bench: Add epoll_ctl(2) benchmark

Benchmark the various operations allowed for epoll_ctl(2).  The idea is
to concurrently stress a single epoll instance doing add/mod/del
operations.

Committer testing:

  # perf bench epoll ctl
  # Running 'epoll/ctl' benchmark:
  Run summary [PID 20344]: 4 threads doing epoll_ctl ops 64 file-descriptors 
for 8 secs.

  [thread  0] fdmap: 0x21a46b0 ... 0x21a47ac [ add: 1680960 ops; mod: 1680960 
ops; del: 1680960 ops ]
  [thread  1] fdmap: 0x21a4960 ... 0x21a4a5c [ add: 1685440 ops; mod: 1685440 
ops; del: 1685440 ops ]
  [thread  2] fdmap: 0x21a4c10 ... 0x21a4d0c [ add: 1674368 ops; mod: 1674368 
ops; del: 1674368 ops ]
  [thread  3] fdmap: 0x21a4ec0 ... 0x21a4fbc [ add: 1677568 ops; mod: 1677568 
ops; del: 1677568 ops ]

  Averaged 1679584 ADD operations (+- 0.14%)
  Averaged 1679584 MOD operations (+- 0.14%)
  Averaged 1679584 DEL operations (+- 0.14%)
  #

Lets measure those calls with 'perf trace' to get a glympse at what this
benchmark is doing in terms of syscalls:

  # perf trace -m32768 -s perf bench epoll ctl
  # Running 'epoll/ctl' benchmark:
  Run summary [PID 20405]: 4 threads doing epoll_ctl ops 64 file-descriptors 
for 8 secs.

  [thread  0] fdmap: 0x21764e0 ... 0x21765dc [ add: 1100480 ops; mod: 1100480 
ops; del: 1100480 ops ]
  [thread  1] fdmap: 0x2176790 ... 0x217688c [ add: 1250176 ops; mod: 1250176 
ops; del: 1250176 ops ]
  [thread  2] fdmap: 0x2176a40 ... 0x2176b3c [ add: 1022464 ops; mod: 1022464 
ops; del: 1022464 ops ]
  [thread  3] fdmap: 0x2176cf0 ... 0x2176dec [ add: 705472 ops; mod: 705472 
ops; del: 705472 ops ]

  Averaged 1019648 ADD operations (+- 11.27%)
  Averaged 1019648 MOD operations (+- 11.27%)
  Averaged 1019648 DEL operations (+- 11.27%)

  Summary of events:

  epoll-ctl (20405), 1264 events, 0.0%

   syscallcallstotal   min   avg   max  stddev
   (msec)(msec)(msec)(msec)(%)
   ---  - - - - --
   eventfd2 256 9.514 0.001 0.037 5.243 68.00%
   clone  4 1.245 0.204 0.311 0.531 24.13%
   mprotect  66 0.345 0.002 0.005 0.021  7.43%
   openat45 0.313 0.004 0.007 0.073 21.93%
   mmap  88 0.302 0.002 0.003 0.013  5.02%
   futex  4 0.160 0.002 0.040 0.140 83.43%
   sched_setaffinity  4 0.124 0.005 0.031 0.070 49.39%
   read  44 0.103 0.001 0.002 0.013 15.54%
   fstat 40 0.052 0.001 0.001 0.003  5.43%
   close 39 0.039 0.001 0.001 0.001  1.48%
   stat   9 0.034 0.003 0.004 0.006  7.30%
   access 3 0.023 0.007 0.008 0.008  4.25%
   open   2 0.021 0.008 0.011 0.013 22.60%
   getdents   4 0.019 0.001 0.005 0.009 37.15%
   write  2 0.013 0.004 0.007 0.009 38.48%
   munmap 1 0.010 0.010 0.010 0.010  0.00%
   brk3 0.006 0.001 0.002 0.003 26.34%
   rt_sigprocmask 2 0.004 0.001 0.002 0.003 43.95%
   rt_sigaction   3 0.004 0.001 0.001 0.002 16.07%
   prlimit64  3 0.004 0.001 0.001 0.001  5.39%
   prctl  1 0.003 0.003 0.003 0.003  0.00%
   epoll_create   1 0.003 0.003 0.003 0.003  0.00%
   lseek  2 0.002 0.001 0.001 0.001 11.42%
   sched_getaffinity1 0.002 0.002 0.002 0.002  0.00%
   arch_prctl 1 0.002 0.002 0.002 0.002  0.00%
   set_tid_address1 0.001 0.001 0.001 0.001  0.00%
   getpid 1 0.001 0.001 0.001 0.001  0.00%
   set_robust_list1 0.001 0.001 0.001 0.001  0.00%
   execve 1 0.000 0.000 0.000 0.000  0.00%

 epoll-ctl (20406), 1245480 events, 14.6%

   syscallcallstotal   min   avg   max  stddev
   (msec)(msec)(msec)(msec)(%)
   ---  - - - - --
   epoll_ctl 619511  1034.927 0.001 0.002 6.691  0.67%
   

[tip:perf/core] tools build feature: Check if eventfd() is available

2018-11-21 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  11c6cbe706f218a8dc7e1f962f12b3a52ddd33a9
Gitweb: https://git.kernel.org/tip/11c6cbe706f218a8dc7e1f962f12b3a52ddd33a9
Author: Arnaldo Carvalho de Melo 
AuthorDate: Wed, 21 Nov 2018 17:42:00 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:25:44 -0300

tools build feature: Check if eventfd() is available

A new 'perf bench epoll' will use this, and to disable it for older
systems, add a feature test for this API.

This is just a simple program that if successfully compiled, means that
the feature is present, at least at the library level, in a build that
sets the output directory to /tmp/build/perf (using O=/tmp/build/perf),
we end up with:

  $ ls -la /tmp/build/perf/feature/test-eventfd*
  -rwxrwxr-x. 1 acme acme 8176 Nov 21 15:58 
/tmp/build/perf/feature/test-eventfd.bin
  -rw-rw-r--. 1 acme acme  588 Nov 21 15:58 
/tmp/build/perf/feature/test-eventfd.d
  -rw-rw-r--. 1 acme acme0 Nov 21 15:58 
/tmp/build/perf/feature/test-eventfd.make.output
  $ ldd /tmp/build/perf/feature/test-eventfd.bin
  linux-vdso.so.1 (0x7fff3bf3f000)
  libc.so.6 => /lib64/libc.so.6 (0x7fa984061000)
  /lib64/ld-linux-x86-64.so.2 (0x7fa984417000)
  $ grep eventfd -A 2 -B 2 /tmp/build/perf/FEATURE-DUMP
  feature-dwarf=1
  feature-dwarf_getlocations=1
  feature-eventfd=1
  feature-fortify-source=1
  feature-sync-compare-and-swap=1
  $

The main thing here is that in the end we'll have -DHAVE_EVENTFD in
CFLAGS, and then the 'perf bench' entry needing that API can be
selectively pruned.

Cc: Adrian Hunter 
Cc: Andrew Morton 
Cc: David Ahern 
Cc: Davidlohr Bueso 
Cc: Jason Baron 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-wkeldwob7dpx6jvtuzl81...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/Makefile.feature   | 1 +
 tools/build/feature/Makefile   | 4 
 tools/build/feature/test-all.c | 5 +
 tools/build/feature/test-eventfd.c | 9 +
 tools/perf/Makefile.config | 5 -
 5 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index d74bb9414d7c..8a123834a2a3 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -31,6 +31,7 @@ FEATURE_TESTS_BASIC :=  \
 backtrace   \
 dwarf   \
 dwarf_getlocations  \
+eventfd \
 fortify-source  \
 sync-compare-and-swap   \
 get_current_dir_name\
diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 304b984f11b9..325087a0429c 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -5,6 +5,7 @@ FILES=  \
  test-bionic.bin\
  test-dwarf.bin \
  test-dwarf_getlocations.bin\
+ test-eventfd.bin   \
  test-fortify-source.bin\
  test-sync-compare-and-swap.bin \
  test-get_current_dir_name.bin  \
@@ -102,6 +103,9 @@ $(OUTPUT)test-bionic.bin:
 $(OUTPUT)test-libelf.bin:
$(BUILD) -lelf
 
+$(OUTPUT)test-eventfd.bin:
+   $(BUILD)
+
 $(OUTPUT)test-get_current_dir_name.bin:
$(BUILD)
 
diff --git a/tools/build/feature/test-all.c b/tools/build/feature/test-all.c
index 56722bfe6bdd..58f01b950195 100644
--- a/tools/build/feature/test-all.c
+++ b/tools/build/feature/test-all.c
@@ -50,6 +50,10 @@
 # include "test-dwarf_getlocations.c"
 #undef main
 
+#define main main_test_eventfd
+# include "test-eventfd.c"
+#undef main
+
 #define main main_test_libelf_getphdrnum
 # include "test-libelf-getphdrnum.c"
 #undef main
@@ -182,6 +186,7 @@ int main(int argc, char *argv[])
main_test_glibc();
main_test_dwarf();
main_test_dwarf_getlocations();
+   main_test_eventfd();
main_test_libelf_getphdrnum();
main_test_libelf_gelf_getnote();
main_test_libelf_getshdrstrndx();
diff --git a/tools/build/feature/test-eventfd.c 
b/tools/build/feature/test-eventfd.c
new file mode 100644
index ..f4de7ef00ccb
--- /dev/null
+++ b/tools/build/feature/test-eventfd.c
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018, Red Hat Inc, Arnaldo Carvalho de Melo 
+
+#include 
+
+int main(void)
+{
+   return eventfd(0, EFD_NONBLOCK);
+}
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index a0e8c23f9125..376d1f78be04 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -299,11 +299,14 @@ ifndef NO_BIONIC
   endif
 endif
 
+ifeq ($(feature-eventfd), 1)
+  CFLAGS += -DHAVE_EVENTFD
+endif
+
 ifeq ($(feature-get_current_dir_name), 1)
   CFLAGS += -DHAVE_GET_CURRENT_DIR_NAME
 endif
 
-
 ifdef NO_LIBELF
   

[tip:perf/core] tools build feature: Check if eventfd() is available

2018-11-21 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  11c6cbe706f218a8dc7e1f962f12b3a52ddd33a9
Gitweb: https://git.kernel.org/tip/11c6cbe706f218a8dc7e1f962f12b3a52ddd33a9
Author: Arnaldo Carvalho de Melo 
AuthorDate: Wed, 21 Nov 2018 17:42:00 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:25:44 -0300

tools build feature: Check if eventfd() is available

A new 'perf bench epoll' will use this, and to disable it for older
systems, add a feature test for this API.

This is just a simple program that if successfully compiled, means that
the feature is present, at least at the library level, in a build that
sets the output directory to /tmp/build/perf (using O=/tmp/build/perf),
we end up with:

  $ ls -la /tmp/build/perf/feature/test-eventfd*
  -rwxrwxr-x. 1 acme acme 8176 Nov 21 15:58 
/tmp/build/perf/feature/test-eventfd.bin
  -rw-rw-r--. 1 acme acme  588 Nov 21 15:58 
/tmp/build/perf/feature/test-eventfd.d
  -rw-rw-r--. 1 acme acme0 Nov 21 15:58 
/tmp/build/perf/feature/test-eventfd.make.output
  $ ldd /tmp/build/perf/feature/test-eventfd.bin
  linux-vdso.so.1 (0x7fff3bf3f000)
  libc.so.6 => /lib64/libc.so.6 (0x7fa984061000)
  /lib64/ld-linux-x86-64.so.2 (0x7fa984417000)
  $ grep eventfd -A 2 -B 2 /tmp/build/perf/FEATURE-DUMP
  feature-dwarf=1
  feature-dwarf_getlocations=1
  feature-eventfd=1
  feature-fortify-source=1
  feature-sync-compare-and-swap=1
  $

The main thing here is that in the end we'll have -DHAVE_EVENTFD in
CFLAGS, and then the 'perf bench' entry needing that API can be
selectively pruned.

Cc: Adrian Hunter 
Cc: Andrew Morton 
Cc: David Ahern 
Cc: Davidlohr Bueso 
Cc: Jason Baron 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-wkeldwob7dpx6jvtuzl81...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/Makefile.feature   | 1 +
 tools/build/feature/Makefile   | 4 
 tools/build/feature/test-all.c | 5 +
 tools/build/feature/test-eventfd.c | 9 +
 tools/perf/Makefile.config | 5 -
 5 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index d74bb9414d7c..8a123834a2a3 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -31,6 +31,7 @@ FEATURE_TESTS_BASIC :=  \
 backtrace   \
 dwarf   \
 dwarf_getlocations  \
+eventfd \
 fortify-source  \
 sync-compare-and-swap   \
 get_current_dir_name\
diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 304b984f11b9..325087a0429c 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -5,6 +5,7 @@ FILES=  \
  test-bionic.bin\
  test-dwarf.bin \
  test-dwarf_getlocations.bin\
+ test-eventfd.bin   \
  test-fortify-source.bin\
  test-sync-compare-and-swap.bin \
  test-get_current_dir_name.bin  \
@@ -102,6 +103,9 @@ $(OUTPUT)test-bionic.bin:
 $(OUTPUT)test-libelf.bin:
$(BUILD) -lelf
 
+$(OUTPUT)test-eventfd.bin:
+   $(BUILD)
+
 $(OUTPUT)test-get_current_dir_name.bin:
$(BUILD)
 
diff --git a/tools/build/feature/test-all.c b/tools/build/feature/test-all.c
index 56722bfe6bdd..58f01b950195 100644
--- a/tools/build/feature/test-all.c
+++ b/tools/build/feature/test-all.c
@@ -50,6 +50,10 @@
 # include "test-dwarf_getlocations.c"
 #undef main
 
+#define main main_test_eventfd
+# include "test-eventfd.c"
+#undef main
+
 #define main main_test_libelf_getphdrnum
 # include "test-libelf-getphdrnum.c"
 #undef main
@@ -182,6 +186,7 @@ int main(int argc, char *argv[])
main_test_glibc();
main_test_dwarf();
main_test_dwarf_getlocations();
+   main_test_eventfd();
main_test_libelf_getphdrnum();
main_test_libelf_gelf_getnote();
main_test_libelf_getshdrstrndx();
diff --git a/tools/build/feature/test-eventfd.c 
b/tools/build/feature/test-eventfd.c
new file mode 100644
index ..f4de7ef00ccb
--- /dev/null
+++ b/tools/build/feature/test-eventfd.c
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018, Red Hat Inc, Arnaldo Carvalho de Melo 
+
+#include 
+
+int main(void)
+{
+   return eventfd(0, EFD_NONBLOCK);
+}
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index a0e8c23f9125..376d1f78be04 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -299,11 +299,14 @@ ifndef NO_BIONIC
   endif
 endif
 
+ifeq ($(feature-eventfd), 1)
+  CFLAGS += -DHAVE_EVENTFD
+endif
+
 ifeq ($(feature-get_current_dir_name), 1)
   CFLAGS += -DHAVE_GET_CURRENT_DIR_NAME
 endif
 
-
 ifdef NO_LIBELF
   

[tip:perf/core] perf bench: Add epoll parallel epoll_wait benchmark

2018-11-21 Thread tip-bot for Davidlohr Bueso
Commit-ID:  121dd9ea0116de3e79a4903a84018190c595e2b6
Gitweb: https://git.kernel.org/tip/121dd9ea0116de3e79a4903a84018190c595e2b6
Author: Davidlohr Bueso 
AuthorDate: Tue, 6 Nov 2018 07:22:25 -0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:38:47 -0300

perf bench: Add epoll parallel epoll_wait benchmark

This program benchmarks concurrent epoll_wait(2) for file descriptors
that are monitored with with EPOLLIN along various semantics, by a
single epoll instance. Such conditions can be found when using
single/combined or multiple queuing when load balancing.

Each thread has a number of private, nonblocking file descriptors,
referred to as fdmap. A writer thread will constantly be writing to the
fdmaps of all threads, minimizing each threads's chances of epoll_wait
not finding any ready read events and blocking as this is not what we
want to stress. Full details in the start of the C file.

Committer testing:

  # perf bench
  Usage:
perf bench []   []

# List of all available benchmark collections:

 sched: Scheduler and IPC benchmarks
   mem: Memory access benchmarks
  numa: NUMA scheduling and MM benchmarks
 futex: Futex stressing benchmarks
 epoll: Epoll stressing benchmarks
   all: All benchmarks

  # perf bench epoll

# List of available benchmarks for collection 'epoll':

  wait: Benchmark epoll concurrent epoll_waits
   all: Run all futex benchmarks

  # perf bench epoll wait
  # Running 'epoll/wait' benchmark:
  Run summary [PID 19295]: 3 threads monitoring on 64 file-descriptors for 8 
secs.

  [thread  0] fdmap: 0xdaa650 ... 0xdaa74c [ 328241 ops/sec ]
  [thread  1] fdmap: 0xdaa900 ... 0xdaa9fc [ 351695 ops/sec ]
  [thread  2] fdmap: 0xdaabb0 ... 0xdaacac [ 381423 ops/sec ]

  Averaged 353786 operations/sec (+- 4.35%), total secs = 8
  #

Committer notes:

Fix the build on debian:experimental-x-mips, debian:experimental-x-mipsel
and others:

CC   /tmp/build/perf/bench/epoll-wait.o
  bench/epoll-wait.c: In function 'writerfn':
  bench/epoll-wait.c:399:12: error: format '%ld' expects argument of type 'long 
int', but argument 2 has type 'size_t' {aka 'unsigned int'} [-Werror=format=]
printinfo("exiting writer-thread (total full-loops: %ld)\n", iter);
  ^  
  bench/epoll-wait.c:86:31: note: in definition of macro 'printinfo'
do { if (__verbose) { printf(fmt, ## arg); fflush(stdout); } } while (0)
 ^~~
  cc1: all warnings being treated as errors

Signed-off-by: Davidlohr Bueso 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Andrew Morton 
Cc: Davidlohr Bueso 
Cc: Jason Baron  
Link: http://lkml.kernel.org/r/20181106152226.20883-2-d...@stgolabs.net
Link: http://lkml.kernel.org/r/20181106182349.thdkpvshkna5vd7o@linux-r8p5>
[ Applied above fixup as per Davidlohr's request ]
[ Use inttypes.h to print rlim_t fields, fixing the build on Alpine Linux / 
musl libc ]
[ Check if eventfd() is available, i.e. if HAVE_EVENTFD is defined ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-bench.txt |   7 +
 tools/perf/bench/Build  |   2 +
 tools/perf/bench/bench.h|   2 +
 tools/perf/bench/epoll-wait.c   | 540 
 tools/perf/builtin-bench.c  |  12 +
 5 files changed, 563 insertions(+)

diff --git a/tools/perf/Documentation/perf-bench.txt 
b/tools/perf/Documentation/perf-bench.txt
index 34750fc32714..3a6b2e73b2e8 100644
--- a/tools/perf/Documentation/perf-bench.txt
+++ b/tools/perf/Documentation/perf-bench.txt
@@ -58,6 +58,9 @@ SUBSYSTEM
 'futex'::
Futex stressing benchmarks.
 
+'epoll'::
+   Eventpoll (epoll) stressing benchmarks.
+
 'all'::
All benchmark subsystems.
 
@@ -203,6 +206,10 @@ Suite for evaluating requeue calls.
 *lock-pi*::
 Suite for evaluating futex lock_pi calls.
 
+SUITES FOR 'epoll'
+~~
+*wait*::
+Suite for evaluating concurrent epoll_wait calls.
 
 SEE ALSO
 
diff --git a/tools/perf/bench/Build b/tools/perf/bench/Build
index eafce1a130a1..2bb79b542d53 100644
--- a/tools/perf/bench/Build
+++ b/tools/perf/bench/Build
@@ -7,6 +7,8 @@ perf-y += futex-wake-parallel.o
 perf-y += futex-requeue.o
 perf-y += futex-lock-pi.o
 
+perf-y += epoll-wait.o
+
 perf-$(CONFIG_X86_64) += mem-memcpy-x86-64-lib.o
 perf-$(CONFIG_X86_64) += mem-memcpy-x86-64-asm.o
 perf-$(CONFIG_X86_64) += mem-memset-x86-64-asm.o
diff --git a/tools/perf/bench/bench.h b/tools/perf/bench/bench.h
index 8299c76046cd..6e1f091ced96 100644
--- a/tools/perf/bench/bench.h
+++ b/tools/perf/bench/bench.h
@@ -38,6 +38,8 @@ int bench_futex_requeue(int argc, const char **argv);
 /* pi futexes */
 int bench_futex_lock_pi(int argc, const char **argv);
 
+int bench_epoll_wait(int argc, const char **argv);
+
 #define BENCH_FORMAT_DEFAULT_STR   "default"
 #define 

[tip:perf/core] perf bench: Add epoll parallel epoll_wait benchmark

2018-11-21 Thread tip-bot for Davidlohr Bueso
Commit-ID:  121dd9ea0116de3e79a4903a84018190c595e2b6
Gitweb: https://git.kernel.org/tip/121dd9ea0116de3e79a4903a84018190c595e2b6
Author: Davidlohr Bueso 
AuthorDate: Tue, 6 Nov 2018 07:22:25 -0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 22:38:47 -0300

perf bench: Add epoll parallel epoll_wait benchmark

This program benchmarks concurrent epoll_wait(2) for file descriptors
that are monitored with with EPOLLIN along various semantics, by a
single epoll instance. Such conditions can be found when using
single/combined or multiple queuing when load balancing.

Each thread has a number of private, nonblocking file descriptors,
referred to as fdmap. A writer thread will constantly be writing to the
fdmaps of all threads, minimizing each threads's chances of epoll_wait
not finding any ready read events and blocking as this is not what we
want to stress. Full details in the start of the C file.

Committer testing:

  # perf bench
  Usage:
perf bench []   []

# List of all available benchmark collections:

 sched: Scheduler and IPC benchmarks
   mem: Memory access benchmarks
  numa: NUMA scheduling and MM benchmarks
 futex: Futex stressing benchmarks
 epoll: Epoll stressing benchmarks
   all: All benchmarks

  # perf bench epoll

# List of available benchmarks for collection 'epoll':

  wait: Benchmark epoll concurrent epoll_waits
   all: Run all futex benchmarks

  # perf bench epoll wait
  # Running 'epoll/wait' benchmark:
  Run summary [PID 19295]: 3 threads monitoring on 64 file-descriptors for 8 
secs.

  [thread  0] fdmap: 0xdaa650 ... 0xdaa74c [ 328241 ops/sec ]
  [thread  1] fdmap: 0xdaa900 ... 0xdaa9fc [ 351695 ops/sec ]
  [thread  2] fdmap: 0xdaabb0 ... 0xdaacac [ 381423 ops/sec ]

  Averaged 353786 operations/sec (+- 4.35%), total secs = 8
  #

Committer notes:

Fix the build on debian:experimental-x-mips, debian:experimental-x-mipsel
and others:

CC   /tmp/build/perf/bench/epoll-wait.o
  bench/epoll-wait.c: In function 'writerfn':
  bench/epoll-wait.c:399:12: error: format '%ld' expects argument of type 'long 
int', but argument 2 has type 'size_t' {aka 'unsigned int'} [-Werror=format=]
printinfo("exiting writer-thread (total full-loops: %ld)\n", iter);
  ^  
  bench/epoll-wait.c:86:31: note: in definition of macro 'printinfo'
do { if (__verbose) { printf(fmt, ## arg); fflush(stdout); } } while (0)
 ^~~
  cc1: all warnings being treated as errors

Signed-off-by: Davidlohr Bueso 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Andrew Morton 
Cc: Davidlohr Bueso 
Cc: Jason Baron  
Link: http://lkml.kernel.org/r/20181106152226.20883-2-d...@stgolabs.net
Link: http://lkml.kernel.org/r/20181106182349.thdkpvshkna5vd7o@linux-r8p5>
[ Applied above fixup as per Davidlohr's request ]
[ Use inttypes.h to print rlim_t fields, fixing the build on Alpine Linux / 
musl libc ]
[ Check if eventfd() is available, i.e. if HAVE_EVENTFD is defined ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-bench.txt |   7 +
 tools/perf/bench/Build  |   2 +
 tools/perf/bench/bench.h|   2 +
 tools/perf/bench/epoll-wait.c   | 540 
 tools/perf/builtin-bench.c  |  12 +
 5 files changed, 563 insertions(+)

diff --git a/tools/perf/Documentation/perf-bench.txt 
b/tools/perf/Documentation/perf-bench.txt
index 34750fc32714..3a6b2e73b2e8 100644
--- a/tools/perf/Documentation/perf-bench.txt
+++ b/tools/perf/Documentation/perf-bench.txt
@@ -58,6 +58,9 @@ SUBSYSTEM
 'futex'::
Futex stressing benchmarks.
 
+'epoll'::
+   Eventpoll (epoll) stressing benchmarks.
+
 'all'::
All benchmark subsystems.
 
@@ -203,6 +206,10 @@ Suite for evaluating requeue calls.
 *lock-pi*::
 Suite for evaluating futex lock_pi calls.
 
+SUITES FOR 'epoll'
+~~
+*wait*::
+Suite for evaluating concurrent epoll_wait calls.
 
 SEE ALSO
 
diff --git a/tools/perf/bench/Build b/tools/perf/bench/Build
index eafce1a130a1..2bb79b542d53 100644
--- a/tools/perf/bench/Build
+++ b/tools/perf/bench/Build
@@ -7,6 +7,8 @@ perf-y += futex-wake-parallel.o
 perf-y += futex-requeue.o
 perf-y += futex-lock-pi.o
 
+perf-y += epoll-wait.o
+
 perf-$(CONFIG_X86_64) += mem-memcpy-x86-64-lib.o
 perf-$(CONFIG_X86_64) += mem-memcpy-x86-64-asm.o
 perf-$(CONFIG_X86_64) += mem-memset-x86-64-asm.o
diff --git a/tools/perf/bench/bench.h b/tools/perf/bench/bench.h
index 8299c76046cd..6e1f091ced96 100644
--- a/tools/perf/bench/bench.h
+++ b/tools/perf/bench/bench.h
@@ -38,6 +38,8 @@ int bench_futex_requeue(int argc, const char **argv);
 /* pi futexes */
 int bench_futex_lock_pi(int argc, const char **argv);
 
+int bench_epoll_wait(int argc, const char **argv);
+
 #define BENCH_FORMAT_DEFAULT_STR   "default"
 #define 

Re: [PATCH v2 1/3] thermal: tegra: continue if sensor register fails

2018-11-21 Thread Wei Ni



On 21/11/2018 8:51 PM, Daniel Lezcano wrote:
> On 21/11/2018 11:23, Wei Ni wrote:
>>
>>
>> On 21/11/2018 4:55 PM, Daniel Lezcano wrote:
>>> On 13/11/2018 11:06, Wei Ni wrote:
 Don't bail when a sensor fails to register with the
 thermal zone and allow other sensors to register.
 This allows other sensors to register with thermal
 framework even if one sensor fails registration.
>>>
>>> I'm not sure if ignoring the error is really safe. Can you describe the
>>> real situation you want to overcome ? How do you differentiate critical
>>> sensors ?
>>
>> The driver will always try to register 4 thermal zones, including cpu,
>> gpu, mem and pll, but if the dts file doesn't set the corresponding
>> sensors, then the register will be failed.
>> Normally, the dts file will set all 4 sensors, but there may have some
>> platform doesn't support them all. So we post this patch.
> 
> Ignoring errors is not the way to go to support different platforms. Fix
> the DT.

The issue isn't in DT file. The Tegra soc thermal include 4 sensors:
cpu, gpu, mem, pll. But in some platforms, for example, we may only need
to support 2 sensors, such as cpu and gpu, so we only configure these
two senors in DT file. But the driver will always try to register 4
sensors, cpu/gpu/mem/pll, so mem and pll will be registered failed. So
in this case we need to ignoring the failure, and continue to enable the
driver.

> 
> 
>> BTW, what do you mean "critical sensors"? We will set critical trip temp
>> for all sensors.
> 
> I meant sensor for thermal zone getting really high temperature.

We doesn't have the critical sensors. We set the critical trip temp for
all registered sensors. And these trip temp is set to the Tegra
hardware. So it mean if the temperature reached the critical trip point,
then the system will be shutdown directly.

> 
> 
 Signed-off-by: Wei Ni 
 ---
  drivers/thermal/tegra/soctherm.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

 diff --git a/drivers/thermal/tegra/soctherm.c 
 b/drivers/thermal/tegra/soctherm.c
 index ed28110a3535..a824d2e63af3 100644
 --- a/drivers/thermal/tegra/soctherm.c
 +++ b/drivers/thermal/tegra/soctherm.c
 @@ -1370,9 +1370,9 @@ static int tegra_soctherm_probe(struct 
 platform_device *pdev)
 _of_thermal_ops);
if (IS_ERR(z)) {
err = PTR_ERR(z);
 -  dev_err(>dev, "failed to register sensor: %d\n",
 -  err);
 -  goto disable_clocks;
 +  dev_warn(>dev, "failed to register sensor %s: 
 %d\n",
 +   soc->ttgs[i]->name, err);
 +  continue;
}
  
zone->tz = z;
 @@ -1434,6 +1434,8 @@ static int __maybe_unused soctherm_resume(struct 
 device *dev)
struct thermal_zone_device *tz;
  
tz = tegra->thermctl_tzs[soc->ttgs[i]->id];
 +  if (!tz)
 +  continue;
err = tegra_soctherm_set_hwtrips(dev, soc->ttgs[i], tz);
if (err) {
dev_err(>dev,

>>>
>>>
> 
> 


Re: [PATCH v2 1/3] thermal: tegra: continue if sensor register fails

2018-11-21 Thread Wei Ni



On 21/11/2018 8:51 PM, Daniel Lezcano wrote:
> On 21/11/2018 11:23, Wei Ni wrote:
>>
>>
>> On 21/11/2018 4:55 PM, Daniel Lezcano wrote:
>>> On 13/11/2018 11:06, Wei Ni wrote:
 Don't bail when a sensor fails to register with the
 thermal zone and allow other sensors to register.
 This allows other sensors to register with thermal
 framework even if one sensor fails registration.
>>>
>>> I'm not sure if ignoring the error is really safe. Can you describe the
>>> real situation you want to overcome ? How do you differentiate critical
>>> sensors ?
>>
>> The driver will always try to register 4 thermal zones, including cpu,
>> gpu, mem and pll, but if the dts file doesn't set the corresponding
>> sensors, then the register will be failed.
>> Normally, the dts file will set all 4 sensors, but there may have some
>> platform doesn't support them all. So we post this patch.
> 
> Ignoring errors is not the way to go to support different platforms. Fix
> the DT.

The issue isn't in DT file. The Tegra soc thermal include 4 sensors:
cpu, gpu, mem, pll. But in some platforms, for example, we may only need
to support 2 sensors, such as cpu and gpu, so we only configure these
two senors in DT file. But the driver will always try to register 4
sensors, cpu/gpu/mem/pll, so mem and pll will be registered failed. So
in this case we need to ignoring the failure, and continue to enable the
driver.

> 
> 
>> BTW, what do you mean "critical sensors"? We will set critical trip temp
>> for all sensors.
> 
> I meant sensor for thermal zone getting really high temperature.

We doesn't have the critical sensors. We set the critical trip temp for
all registered sensors. And these trip temp is set to the Tegra
hardware. So it mean if the temperature reached the critical trip point,
then the system will be shutdown directly.

> 
> 
 Signed-off-by: Wei Ni 
 ---
  drivers/thermal/tegra/soctherm.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

 diff --git a/drivers/thermal/tegra/soctherm.c 
 b/drivers/thermal/tegra/soctherm.c
 index ed28110a3535..a824d2e63af3 100644
 --- a/drivers/thermal/tegra/soctherm.c
 +++ b/drivers/thermal/tegra/soctherm.c
 @@ -1370,9 +1370,9 @@ static int tegra_soctherm_probe(struct 
 platform_device *pdev)
 _of_thermal_ops);
if (IS_ERR(z)) {
err = PTR_ERR(z);
 -  dev_err(>dev, "failed to register sensor: %d\n",
 -  err);
 -  goto disable_clocks;
 +  dev_warn(>dev, "failed to register sensor %s: 
 %d\n",
 +   soc->ttgs[i]->name, err);
 +  continue;
}
  
zone->tz = z;
 @@ -1434,6 +1434,8 @@ static int __maybe_unused soctherm_resume(struct 
 device *dev)
struct thermal_zone_device *tz;
  
tz = tegra->thermctl_tzs[soc->ttgs[i]->id];
 +  if (!tz)
 +  continue;
err = tegra_soctherm_set_hwtrips(dev, soc->ttgs[i], tz);
if (err) {
dev_err(>dev,

>>>
>>>
> 
> 


[tip:perf/core] perf bench: Move HAVE_PTHREAD_ATTR_SETAFFINITY_NP into bench.h

2018-11-21 Thread tip-bot for Davidlohr Bueso
Commit-ID:  d47d77c3f008d3cf02c6ce92ef4f6e32ca270351
Gitweb: https://git.kernel.org/tip/d47d77c3f008d3cf02c6ce92ef4f6e32ca270351
Author: Davidlohr Bueso 
AuthorDate: Fri, 9 Nov 2018 13:07:19 -0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 12:00:32 -0300

perf bench: Move HAVE_PTHREAD_ATTR_SETAFFINITY_NP into bench.h

Both futex and epoll need this call, and can cause build failure on
systems that don't have it pthread_attr_setaffinity_np().

Signed-off-by: Davidlohr Bueso 
Reported-by: Arnaldo Carvalho de Melo 
Cc: Andrew Morton 
Cc: Davidlohr Bueso 
Cc: Jason Baron 
Link: http://lkml.kernel.org/r/20181109210719.pr7ohayuwqmfp2wl@linux-r8p5
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/bench/bench.h | 11 +++
 tools/perf/bench/futex.h | 12 
 2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/tools/perf/bench/bench.h b/tools/perf/bench/bench.h
index 6c9fcd757f31..8299c76046cd 100644
--- a/tools/perf/bench/bench.h
+++ b/tools/perf/bench/bench.h
@@ -48,4 +48,15 @@ int bench_futex_lock_pi(int argc, const char **argv);
 extern int bench_format;
 extern unsigned int bench_repeat;
 
+#ifndef HAVE_PTHREAD_ATTR_SETAFFINITY_NP
+#include 
+#include 
+static inline int pthread_attr_setaffinity_np(pthread_attr_t *attr 
__maybe_unused,
+ size_t cpusetsize __maybe_unused,
+ cpu_set_t *cpuset __maybe_unused)
+{
+   return 0;
+}
+#endif
+
 #endif
diff --git a/tools/perf/bench/futex.h b/tools/perf/bench/futex.h
index db4853f209c7..31b53cc7d5bc 100644
--- a/tools/perf/bench/futex.h
+++ b/tools/perf/bench/futex.h
@@ -86,16 +86,4 @@ futex_cmp_requeue(u_int32_t *uaddr, u_int32_t val, u_int32_t 
*uaddr2, int nr_wak
return futex(uaddr, FUTEX_CMP_REQUEUE, nr_wake, nr_requeue, uaddr2,
 val, opflags);
 }
-
-#ifndef HAVE_PTHREAD_ATTR_SETAFFINITY_NP
-#include 
-#include 
-static inline int pthread_attr_setaffinity_np(pthread_attr_t *attr 
__maybe_unused,
- size_t cpusetsize __maybe_unused,
- cpu_set_t *cpuset __maybe_unused)
-{
-   return 0;
-}
-#endif
-
 #endif /* _FUTEX_H */


Re: [patch 22/24] x86/speculation: Create PRCTL interface to restrict indirect branch speculation

2018-11-21 Thread Ingo Molnar


* Thomas Gleixner  wrote:

> From: Tim Chen 
> 
> Add the PR_SPEC_INDIR_BRANCH option for the PR_GET_SPECULATION_CTRL and
> PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
> indirect branch speculation via STIBP.
> 
> Invocations:
>  Check indirect branch speculation status with
>  - prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, 0, 0, 0);
> 
>  Enable indirect branch speculation with
>  - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, PR_SPEC_ENABLE, 0, 0);
> 
>  Disable indirect branch speculation with
>  - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, PR_SPEC_DISABLE, 0, 
> 0);
> 
>  Force disable indirect branch speculation with
>  - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, 
> PR_SPEC_FORCE_DISABLE, 0, 0);
> 
> See Documentation/userspace-api/spec_ctrl.rst.
> 
> Signed-off-by: Tim Chen 
> Signed-off-by: Thomas Gleixner 

Please either de-capitalize the title to 'prctl()', or use PR_SPEC_PRCTL 
or PR_SET/GET_SPECULATION_CTRL - there's no such thing as 'PRCTL' 
interface - the interface is called prctl() and the speculation control 
ABIs have their own names.

This applies to the next patch as well.

> --- a/include/uapi/linux/prctl.h
> +++ b/include/uapi/linux/prctl.h
> @@ -212,6 +212,7 @@ struct prctl_mm_map {
>  #define PR_SET_SPECULATION_CTRL  53
>  /* Speculation control variants */
>  # define PR_SPEC_STORE_BYPASS0
> +# define PR_SPEC_INDIR_BRANCH1
>  /* Return and control values for PR_SET/GET_SPECULATION_CTRL */
>  # define PR_SPEC_NOT_AFFECTED0
>  # define PR_SPEC_PRCTL   (1UL << 0)
> --- a/tools/include/uapi/linux/prctl.h
> +++ b/tools/include/uapi/linux/prctl.h
> @@ -212,6 +212,7 @@ struct prctl_mm_map {
>  #define PR_SET_SPECULATION_CTRL  53
>  /* Speculation control variants */
>  # define PR_SPEC_STORE_BYPASS0
> +# define PR_SPEC_INDIR_BRANCH1
>  /* Return and control values for PR_SET/GET_SPECULATION_CTRL */
>  # define PR_SPEC_NOT_AFFECTED0
>  # define PR_SPEC_PRCTL   (1UL << 0)

Please de-abbreviate the new ABI: PR_SPEC_INDIRECT_BRANCH?

Thanks,

Ingo


[tip:perf/core] perf bench: Move HAVE_PTHREAD_ATTR_SETAFFINITY_NP into bench.h

2018-11-21 Thread tip-bot for Davidlohr Bueso
Commit-ID:  d47d77c3f008d3cf02c6ce92ef4f6e32ca270351
Gitweb: https://git.kernel.org/tip/d47d77c3f008d3cf02c6ce92ef4f6e32ca270351
Author: Davidlohr Bueso 
AuthorDate: Fri, 9 Nov 2018 13:07:19 -0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 12:00:32 -0300

perf bench: Move HAVE_PTHREAD_ATTR_SETAFFINITY_NP into bench.h

Both futex and epoll need this call, and can cause build failure on
systems that don't have it pthread_attr_setaffinity_np().

Signed-off-by: Davidlohr Bueso 
Reported-by: Arnaldo Carvalho de Melo 
Cc: Andrew Morton 
Cc: Davidlohr Bueso 
Cc: Jason Baron 
Link: http://lkml.kernel.org/r/20181109210719.pr7ohayuwqmfp2wl@linux-r8p5
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/bench/bench.h | 11 +++
 tools/perf/bench/futex.h | 12 
 2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/tools/perf/bench/bench.h b/tools/perf/bench/bench.h
index 6c9fcd757f31..8299c76046cd 100644
--- a/tools/perf/bench/bench.h
+++ b/tools/perf/bench/bench.h
@@ -48,4 +48,15 @@ int bench_futex_lock_pi(int argc, const char **argv);
 extern int bench_format;
 extern unsigned int bench_repeat;
 
+#ifndef HAVE_PTHREAD_ATTR_SETAFFINITY_NP
+#include 
+#include 
+static inline int pthread_attr_setaffinity_np(pthread_attr_t *attr 
__maybe_unused,
+ size_t cpusetsize __maybe_unused,
+ cpu_set_t *cpuset __maybe_unused)
+{
+   return 0;
+}
+#endif
+
 #endif
diff --git a/tools/perf/bench/futex.h b/tools/perf/bench/futex.h
index db4853f209c7..31b53cc7d5bc 100644
--- a/tools/perf/bench/futex.h
+++ b/tools/perf/bench/futex.h
@@ -86,16 +86,4 @@ futex_cmp_requeue(u_int32_t *uaddr, u_int32_t val, u_int32_t 
*uaddr2, int nr_wak
return futex(uaddr, FUTEX_CMP_REQUEUE, nr_wake, nr_requeue, uaddr2,
 val, opflags);
 }
-
-#ifndef HAVE_PTHREAD_ATTR_SETAFFINITY_NP
-#include 
-#include 
-static inline int pthread_attr_setaffinity_np(pthread_attr_t *attr 
__maybe_unused,
- size_t cpusetsize __maybe_unused,
- cpu_set_t *cpuset __maybe_unused)
-{
-   return 0;
-}
-#endif
-
 #endif /* _FUTEX_H */


Re: [patch 22/24] x86/speculation: Create PRCTL interface to restrict indirect branch speculation

2018-11-21 Thread Ingo Molnar


* Thomas Gleixner  wrote:

> From: Tim Chen 
> 
> Add the PR_SPEC_INDIR_BRANCH option for the PR_GET_SPECULATION_CTRL and
> PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
> indirect branch speculation via STIBP.
> 
> Invocations:
>  Check indirect branch speculation status with
>  - prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, 0, 0, 0);
> 
>  Enable indirect branch speculation with
>  - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, PR_SPEC_ENABLE, 0, 0);
> 
>  Disable indirect branch speculation with
>  - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, PR_SPEC_DISABLE, 0, 
> 0);
> 
>  Force disable indirect branch speculation with
>  - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, 
> PR_SPEC_FORCE_DISABLE, 0, 0);
> 
> See Documentation/userspace-api/spec_ctrl.rst.
> 
> Signed-off-by: Tim Chen 
> Signed-off-by: Thomas Gleixner 

Please either de-capitalize the title to 'prctl()', or use PR_SPEC_PRCTL 
or PR_SET/GET_SPECULATION_CTRL - there's no such thing as 'PRCTL' 
interface - the interface is called prctl() and the speculation control 
ABIs have their own names.

This applies to the next patch as well.

> --- a/include/uapi/linux/prctl.h
> +++ b/include/uapi/linux/prctl.h
> @@ -212,6 +212,7 @@ struct prctl_mm_map {
>  #define PR_SET_SPECULATION_CTRL  53
>  /* Speculation control variants */
>  # define PR_SPEC_STORE_BYPASS0
> +# define PR_SPEC_INDIR_BRANCH1
>  /* Return and control values for PR_SET/GET_SPECULATION_CTRL */
>  # define PR_SPEC_NOT_AFFECTED0
>  # define PR_SPEC_PRCTL   (1UL << 0)
> --- a/tools/include/uapi/linux/prctl.h
> +++ b/tools/include/uapi/linux/prctl.h
> @@ -212,6 +212,7 @@ struct prctl_mm_map {
>  #define PR_SET_SPECULATION_CTRL  53
>  /* Speculation control variants */
>  # define PR_SPEC_STORE_BYPASS0
> +# define PR_SPEC_INDIR_BRANCH1
>  /* Return and control values for PR_SET/GET_SPECULATION_CTRL */
>  # define PR_SPEC_NOT_AFFECTED0
>  # define PR_SPEC_PRCTL   (1UL << 0)

Please de-abbreviate the new ABI: PR_SPEC_INDIRECT_BRANCH?

Thanks,

Ingo


[RFC PATCH] panic: Add options to dump system info when panic happens

2018-11-21 Thread Feng Tang
Kernel panic issues are always painful to debug, partially
because of it's not easy to get enough information of the
context when panic happens.

And we have ramoops and kdump for that, while this commit
tries to a easier way to show the system info by adding a
cmdline parameter, referring some idea from sysrq handler.

Signed-off-by: Feng Tang 
Cc: Thomas Gleixner 
Cc: John Stultz 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
---
This patch is frequently used by us when debugging panic and system
stability bugs, and does help much. And the options could be expanded
more to cover other info like the ftrace, signal etc.

 Documentation/admin-guide/kernel-parameters.txt |  7 +++
 kernel/panic.c  | 26 +
 2 files changed, 33 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 81d1d5a..8d349a8 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3081,6 +3081,13 @@
timeout < 0: reboot immediately
Format: 
 
+   panic_dump= Bitmask for dumping system info when panic happens.
+   User can chose combination of the following bits:
+   bit 0: dump all tasks info
+   bit 1: dump system memory info
+   bit 2: dump timer info
+   bit 3: dump locks info if CONFIG_LOCKDEP is on
+
panic_on_warn   panic() instead of WARN().  Useful to cause kdump
on a WARN().
 
diff --git a/kernel/panic.c b/kernel/panic.c
index f6d549a..8320d04 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -45,6 +45,12 @@ int panic_on_warn __read_mostly;
 int panic_timeout = CONFIG_PANIC_TIMEOUT;
 EXPORT_SYMBOL_GPL(panic_timeout);
 
+#define PANIC_DUMP_TASK_INFO   0x0001
+#define PANIC_DUMP_MEM_INFO0x0002
+#define PANIC_DUMP_TIMER_INFO  0x0004
+#define PANIC_DUMP_LOCK_INFO   0x0008
+static unsigned long panic_dump;
+
 ATOMIC_NOTIFIER_HEAD(panic_notifier_list);
 
 EXPORT_SYMBOL(panic_notifier_list);
@@ -124,6 +130,23 @@ void nmi_panic(struct pt_regs *regs, const char *msg)
 }
 EXPORT_SYMBOL(nmi_panic);
 
+static void panic_dump_sys_info(void)
+{
+   if (panic_dump & PANIC_DUMP_TASK_INFO)
+   show_state();
+
+   if (panic_dump & PANIC_DUMP_MEM_INFO)
+   show_mem(0, NULL);
+
+   if (panic_dump & PANIC_DUMP_TIMER_INFO)
+   sysrq_timer_list_show();
+
+#ifdef COFNIG_LOCKDEP
+   if (panic_dump & PANIC_DUMP_LOCK_INFO)
+   debug_show_all_locks();
+#endif
+}
+
 /**
  * panic - halt the system
  * @fmt: The text string to print
@@ -250,6 +273,8 @@ void panic(const char *fmt, ...)
debug_locks_off();
console_flush_on_panic();
 
+   panic_dump_sys_info();
+
if (!panic_blink)
panic_blink = no_blink;
 
@@ -654,6 +679,7 @@ void refcount_error_report(struct pt_regs *regs, const char 
*err)
 #endif
 
 core_param(panic, panic_timeout, int, 0644);
+core_param(panic_dump, panic_dump, ulong, 0644);
 core_param(pause_on_oops, pause_on_oops, int, 0644);
 core_param(panic_on_warn, panic_on_warn, int, 0644);
 core_param(crash_kexec_post_notifiers, crash_kexec_post_notifiers, bool, 0644);
-- 
2.7.4



[tip:perf/core] perf script: Share code and output format for uregs and iregs output

2018-11-21 Thread tip-bot for Milian Wolff
Commit-ID:  9add8fe8e6f63db47e40e65173530dcb68cd7a07
Gitweb: https://git.kernel.org/tip/9add8fe8e6f63db47e40e65173530dcb68cd7a07
Author: Milian Wolff 
AuthorDate: Wed, 7 Nov 2018 23:34:37 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 12:00:32 -0300

perf script: Share code and output format for uregs and iregs output

The iregs output was missing the newline at end as well as the leading
ABI output. This made it hard to compare the iregs and uregs values.
Instead, use a single function to output the register values and use it
for both, iregs and uregs, to ensure the output is consistent.

Before:

  perf  7049 [-01]  1343.354347:  1 cycles:ppp:
a7bc21ce perf_event_exec+0x18e 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7ead3 setup_new_exec+0xf3 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7cd7be5 load_elf_binary+0x395 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7e540 search_binary_handler+0x80 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7f1aa __do_execve_file.isra.13+0x58a 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7f561 do_execve+0x21 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7f596 __x64_sys_execve+0x26 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7a041cb do_syscall_64+0x5b 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a840008c entry_SYSCALL_64+0x7c 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
AX:0x8000BX:0x0CX:0x0DX:0x7SI:0xfDI:0x286
BP:0x95bc8213a460SP:0xacbf0ba97d18IP:0xa7bc21cd 
FLAGS:0x28eCS:0x10SS:0x18R8:0x2R9:0x21440   R10:0x33816fb3b8c   
R11:0x1   R12:0x95bc8213a460   R13:0x95bc8213a400   
R14:0x95bc8213a400   R15:0x1  ABI:2AX:0xffda
BX:0xCX:0x7f84ad85798bDX:0x560209699d50
SI:0x7ffe2c7a6820DI:0x7ffe2c7a8c9bBP:0x7ffe2c7a20d0
SP:0x7ffe2c7a2058IP:0x7f84ad85798b FLAGS:0x206CS:0x33SS:0x2b
R8:0x7ffe2c7a2030R9:0x7f84ae55f010   R10:0x8   R11:0x206   
R12:0x   R13:0x   R14:0x   
R15:0x

  perf  7049 [-01]  1343.354363:  1 cycles:ppp:
...

After:

  perf  7049 [-01]  1343.354347:  1 cycles:ppp:
a7bc21ce perf_event_exec+0x18e 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7ead3 setup_new_exec+0xf3 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7cd7be5 load_elf_binary+0x395 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7e540 search_binary_handler+0x80 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7f1aa __do_execve_file.isra.13+0x58a 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7f561 do_execve+0x21 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7f596 __x64_sys_execve+0x26 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7a041cb do_syscall_64+0x5b 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a840008c entry_SYSCALL_64+0x7c 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
ABI:2AX:0x8000BX:0x0CX:0x0DX:0x7SI:0xfDI:0x286  
  BP:0x95bc8213a460SP:0xacbf0ba97d18IP:0xa7bc21cd 
FLAGS:0x28eCS:0x10SS:0x18R8:0x2R9:0x21440   R10:0x33816fb3b8c   
R11:0x1   R12:0x95bc8213a460   R13:0x95bc8213a400   
R14:0x95bc8213a400   R15:0x1
ABI:2AX:0xffdaBX:0x
CX:0x7f84ad85798bDX:0x560209699d50SI:0x7ffe2c7a6820
DI:0x7ffe2c7a8c9bBP:0x7ffe2c7a20d0SP:0x7ffe2c7a2058
IP:0x7f84ad85798b FLAGS:0x206CS:0x33SS:0x2bR8:0x7ffe2c7a2030
R9:0x7f84ae55f010   R10:0x8   R11:0x206   R12:0x   
R13:0x   R14:0x   R15:0x

  perf  7049 [-01]  1343.354363:  1 cycles:ppp:
...

Signed-off-by: Milian Wolff 
Acked-by: Jiri Olsa 
Link: http://lkml.kernel.org/r/20181107223437.9071-1-milian.wo...@kdab.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-script.c | 40 +---
 1 file changed, 17 insertions(+), 23 deletions(-)

diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 

[tip:perf/core] perf bpf: Reduce the hardcoded .max_entries for pid_maps

2018-11-21 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  0f7c2de5dd3f5c0ed9603e4ccfb6a3ddc55f46df
Gitweb: https://git.kernel.org/tip/0f7c2de5dd3f5c0ed9603e4ccfb6a3ddc55f46df
Author: Arnaldo Carvalho de Melo 
AuthorDate: Wed, 7 Nov 2018 14:49:27 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 12:00:32 -0300

perf bpf: Reduce the hardcoded .max_entries for pid_maps

While working on augmented syscalls I got into this error:

  # trace -vv --filter-pids 2469,1663 -e 
tools/perf/examples/bpf/augmented_raw_syscalls.c sleep 1
  
  libbpf: map 0 is "__augmented_syscalls__"
  libbpf: map 1 is "__bpf_stdout__"
  libbpf: map 2 is "pids_filtered"
  libbpf: map 3 is "syscalls"
  libbpf: collecting relocating info for: '.text'
  libbpf: relo for 13 value 84 name 133
  libbpf: relocation: insn_idx=3
  libbpf: relocation: find map 3 (pids_filtered) for insn 3
  libbpf: collecting relocating info for: 'raw_syscalls:sys_enter'
  libbpf: relo for 8 value 0 name 0
  libbpf: relocation: insn_idx=1
  libbpf: relo for 8 value 0 name 0
  libbpf: relocation: insn_idx=3
  libbpf: relo for 9 value 28 name 178
  libbpf: relocation: insn_idx=36
  libbpf: relocation: find map 1 (__augmented_syscalls__) for insn 36
  libbpf: collecting relocating info for: 'raw_syscalls:sys_exit'
  libbpf: relo for 8 value 0 name 0
  libbpf: relocation: insn_idx=0
  libbpf: relo for 8 value 0 name 0
  libbpf: relocation: insn_idx=2
  bpf: config program 'raw_syscalls:sys_enter'
  bpf: config program 'raw_syscalls:sys_exit'
  libbpf: create map __bpf_stdout__: fd=3
  libbpf: create map __augmented_syscalls__: fd=4
  libbpf: create map syscalls: fd=5
  libbpf: create map pids_filtered: fd=6
  libbpf: added 13 insn from .text to prog raw_syscalls:sys_enter
  libbpf: added 13 insn from .text to prog raw_syscalls:sys_exit
  libbpf: load bpf program failed: Operation not permitted
  libbpf: failed to load program 'raw_syscalls:sys_exit'
  libbpf: failed to load object 
'tools/perf/examples/bpf/augmented_raw_syscalls.c'
  bpf: load objects failed: err=-4009: (Incorrect kernel version)
  event syntax error: 'tools/perf/examples/bpf/augmented_raw_syscalls.c'
   \___ Failed to load program for unknown reason

  (add -v to see detail)
  Run 'perf list' for a list of valid events

   Usage: perf trace [] []
  or: perf trace [] --  []
  or: perf trace record [] []
  or: perf trace record [] --  []

  -e, --eventevent/syscall selector. use 'perf list' to list 
available events

If I then try to use strace (perf trace'ing 'perf trace' needs some more work
before its possible) to get a bit more info I get:

  # strace -e bpf trace --filter-pids 2469,1663 -e 
tools/perf/examples/bpf/augmented_raw_syscalls.c sleep 1
  bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_PERF_EVENT_ARRAY, key_size=4, 
value_size=4, max_entries=4, map_flags=0, inner_map_fd=0, 
map_name="__bpf_stdout__", map_ifindex=0}, 72) = 3
  bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_PERF_EVENT_ARRAY, key_size=4, 
value_size=4, max_entries=4, map_flags=0, inner_map_fd=0, 
map_name="__augmented_sys", map_ifindex=0}, 72) = 4
  bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_ARRAY, key_size=4, value_size=1, 
max_entries=500, map_flags=0, inner_map_fd=0, map_name="syscalls", 
map_ifindex=0}, 72) = 5
  bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_HASH, key_size=4, value_size=1, 
max_entries=512, map_flags=0, inner_map_fd=0, map_name="pids_filtered", 
map_ifindex=0}, 72) = 6
  bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_TRACEPOINT, insn_cnt=57, 
insns=0x1223f50, license="GPL", log_level=0, log_size=0, log_buf=NULL, 
kern_version=KERNEL_VERSION(4, 18, 10), prog_flags=0, prog_name="sys_enter", 
prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS}, 72) = 7
  bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_TRACEPOINT, insn_cnt=18, 
insns=0x1224120, license="GPL", log_level=0, log_size=0, log_buf=NULL, 
kern_version=KERNEL_VERSION(4, 18, 10), prog_flags=0, prog_name="sys_exit", 
prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS}, 72) = -1 EPERM 
(Operation not permitted)
  bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_TRACEPOINT, insn_cnt=18, 
insns=0x1224120, license="GPL", log_level=1, log_size=262144, log_buf="", 
kern_version=KERNEL_VERSION(4, 18, 10), prog_flags=0, prog_name="sys_exit", 
prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS}, 72) = -1 EPERM 
(Operation not permitted)
  bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_KPROBE, insn_cnt=18, 
insns=0x1224120, license="GPL", log_level=0, log_size=0, log_buf=NULL, 
kern_version=KERNEL_VERSION(4, 18, 10), prog_flags=0, prog_name="sys_exit", 
prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS}, 72) = -1 EPERM 
(Operation not permitted)
  event syntax error: 'tools/perf/examples/bpf/augmented_raw_syscalls.c'
   \___ Failed to load program for unknown reason
  
  #

I managed to create the maps, etc, but then installing the "sys_exit" hook into
the "raw_syscalls:sys_exit" tracepoint somehow 

[RFC PATCH] panic: Add options to dump system info when panic happens

2018-11-21 Thread Feng Tang
Kernel panic issues are always painful to debug, partially
because of it's not easy to get enough information of the
context when panic happens.

And we have ramoops and kdump for that, while this commit
tries to a easier way to show the system info by adding a
cmdline parameter, referring some idea from sysrq handler.

Signed-off-by: Feng Tang 
Cc: Thomas Gleixner 
Cc: John Stultz 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
---
This patch is frequently used by us when debugging panic and system
stability bugs, and does help much. And the options could be expanded
more to cover other info like the ftrace, signal etc.

 Documentation/admin-guide/kernel-parameters.txt |  7 +++
 kernel/panic.c  | 26 +
 2 files changed, 33 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 81d1d5a..8d349a8 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3081,6 +3081,13 @@
timeout < 0: reboot immediately
Format: 
 
+   panic_dump= Bitmask for dumping system info when panic happens.
+   User can chose combination of the following bits:
+   bit 0: dump all tasks info
+   bit 1: dump system memory info
+   bit 2: dump timer info
+   bit 3: dump locks info if CONFIG_LOCKDEP is on
+
panic_on_warn   panic() instead of WARN().  Useful to cause kdump
on a WARN().
 
diff --git a/kernel/panic.c b/kernel/panic.c
index f6d549a..8320d04 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -45,6 +45,12 @@ int panic_on_warn __read_mostly;
 int panic_timeout = CONFIG_PANIC_TIMEOUT;
 EXPORT_SYMBOL_GPL(panic_timeout);
 
+#define PANIC_DUMP_TASK_INFO   0x0001
+#define PANIC_DUMP_MEM_INFO0x0002
+#define PANIC_DUMP_TIMER_INFO  0x0004
+#define PANIC_DUMP_LOCK_INFO   0x0008
+static unsigned long panic_dump;
+
 ATOMIC_NOTIFIER_HEAD(panic_notifier_list);
 
 EXPORT_SYMBOL(panic_notifier_list);
@@ -124,6 +130,23 @@ void nmi_panic(struct pt_regs *regs, const char *msg)
 }
 EXPORT_SYMBOL(nmi_panic);
 
+static void panic_dump_sys_info(void)
+{
+   if (panic_dump & PANIC_DUMP_TASK_INFO)
+   show_state();
+
+   if (panic_dump & PANIC_DUMP_MEM_INFO)
+   show_mem(0, NULL);
+
+   if (panic_dump & PANIC_DUMP_TIMER_INFO)
+   sysrq_timer_list_show();
+
+#ifdef COFNIG_LOCKDEP
+   if (panic_dump & PANIC_DUMP_LOCK_INFO)
+   debug_show_all_locks();
+#endif
+}
+
 /**
  * panic - halt the system
  * @fmt: The text string to print
@@ -250,6 +273,8 @@ void panic(const char *fmt, ...)
debug_locks_off();
console_flush_on_panic();
 
+   panic_dump_sys_info();
+
if (!panic_blink)
panic_blink = no_blink;
 
@@ -654,6 +679,7 @@ void refcount_error_report(struct pt_regs *regs, const char 
*err)
 #endif
 
 core_param(panic, panic_timeout, int, 0644);
+core_param(panic_dump, panic_dump, ulong, 0644);
 core_param(pause_on_oops, pause_on_oops, int, 0644);
 core_param(panic_on_warn, panic_on_warn, int, 0644);
 core_param(crash_kexec_post_notifiers, crash_kexec_post_notifiers, bool, 0644);
-- 
2.7.4



[tip:perf/core] perf script: Share code and output format for uregs and iregs output

2018-11-21 Thread tip-bot for Milian Wolff
Commit-ID:  9add8fe8e6f63db47e40e65173530dcb68cd7a07
Gitweb: https://git.kernel.org/tip/9add8fe8e6f63db47e40e65173530dcb68cd7a07
Author: Milian Wolff 
AuthorDate: Wed, 7 Nov 2018 23:34:37 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 12:00:32 -0300

perf script: Share code and output format for uregs and iregs output

The iregs output was missing the newline at end as well as the leading
ABI output. This made it hard to compare the iregs and uregs values.
Instead, use a single function to output the register values and use it
for both, iregs and uregs, to ensure the output is consistent.

Before:

  perf  7049 [-01]  1343.354347:  1 cycles:ppp:
a7bc21ce perf_event_exec+0x18e 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7ead3 setup_new_exec+0xf3 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7cd7be5 load_elf_binary+0x395 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7e540 search_binary_handler+0x80 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7f1aa __do_execve_file.isra.13+0x58a 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7f561 do_execve+0x21 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7f596 __x64_sys_execve+0x26 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7a041cb do_syscall_64+0x5b 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a840008c entry_SYSCALL_64+0x7c 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
AX:0x8000BX:0x0CX:0x0DX:0x7SI:0xfDI:0x286
BP:0x95bc8213a460SP:0xacbf0ba97d18IP:0xa7bc21cd 
FLAGS:0x28eCS:0x10SS:0x18R8:0x2R9:0x21440   R10:0x33816fb3b8c   
R11:0x1   R12:0x95bc8213a460   R13:0x95bc8213a400   
R14:0x95bc8213a400   R15:0x1  ABI:2AX:0xffda
BX:0xCX:0x7f84ad85798bDX:0x560209699d50
SI:0x7ffe2c7a6820DI:0x7ffe2c7a8c9bBP:0x7ffe2c7a20d0
SP:0x7ffe2c7a2058IP:0x7f84ad85798b FLAGS:0x206CS:0x33SS:0x2b
R8:0x7ffe2c7a2030R9:0x7f84ae55f010   R10:0x8   R11:0x206   
R12:0x   R13:0x   R14:0x   
R15:0x

  perf  7049 [-01]  1343.354363:  1 cycles:ppp:
...

After:

  perf  7049 [-01]  1343.354347:  1 cycles:ppp:
a7bc21ce perf_event_exec+0x18e 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7ead3 setup_new_exec+0xf3 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7cd7be5 load_elf_binary+0x395 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7e540 search_binary_handler+0x80 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7f1aa __do_execve_file.isra.13+0x58a 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7f561 do_execve+0x21 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7c7f596 __x64_sys_execve+0x26 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a7a041cb do_syscall_64+0x5b 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
a840008c entry_SYSCALL_64+0x7c 
(/lib/modules/4.20.0-rc1perf-devel-05115-gc0bc98f76e39-dirty/build/vmlinux)
ABI:2AX:0x8000BX:0x0CX:0x0DX:0x7SI:0xfDI:0x286  
  BP:0x95bc8213a460SP:0xacbf0ba97d18IP:0xa7bc21cd 
FLAGS:0x28eCS:0x10SS:0x18R8:0x2R9:0x21440   R10:0x33816fb3b8c   
R11:0x1   R12:0x95bc8213a460   R13:0x95bc8213a400   
R14:0x95bc8213a400   R15:0x1
ABI:2AX:0xffdaBX:0x
CX:0x7f84ad85798bDX:0x560209699d50SI:0x7ffe2c7a6820
DI:0x7ffe2c7a8c9bBP:0x7ffe2c7a20d0SP:0x7ffe2c7a2058
IP:0x7f84ad85798b FLAGS:0x206CS:0x33SS:0x2bR8:0x7ffe2c7a2030
R9:0x7f84ae55f010   R10:0x8   R11:0x206   R12:0x   
R13:0x   R14:0x   R15:0x

  perf  7049 [-01]  1343.354363:  1 cycles:ppp:
...

Signed-off-by: Milian Wolff 
Acked-by: Jiri Olsa 
Link: http://lkml.kernel.org/r/20181107223437.9071-1-milian.wo...@kdab.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-script.c | 40 +---
 1 file changed, 17 insertions(+), 23 deletions(-)

diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 

[tip:perf/core] perf bpf: Reduce the hardcoded .max_entries for pid_maps

2018-11-21 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  0f7c2de5dd3f5c0ed9603e4ccfb6a3ddc55f46df
Gitweb: https://git.kernel.org/tip/0f7c2de5dd3f5c0ed9603e4ccfb6a3ddc55f46df
Author: Arnaldo Carvalho de Melo 
AuthorDate: Wed, 7 Nov 2018 14:49:27 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 12:00:32 -0300

perf bpf: Reduce the hardcoded .max_entries for pid_maps

While working on augmented syscalls I got into this error:

  # trace -vv --filter-pids 2469,1663 -e 
tools/perf/examples/bpf/augmented_raw_syscalls.c sleep 1
  
  libbpf: map 0 is "__augmented_syscalls__"
  libbpf: map 1 is "__bpf_stdout__"
  libbpf: map 2 is "pids_filtered"
  libbpf: map 3 is "syscalls"
  libbpf: collecting relocating info for: '.text'
  libbpf: relo for 13 value 84 name 133
  libbpf: relocation: insn_idx=3
  libbpf: relocation: find map 3 (pids_filtered) for insn 3
  libbpf: collecting relocating info for: 'raw_syscalls:sys_enter'
  libbpf: relo for 8 value 0 name 0
  libbpf: relocation: insn_idx=1
  libbpf: relo for 8 value 0 name 0
  libbpf: relocation: insn_idx=3
  libbpf: relo for 9 value 28 name 178
  libbpf: relocation: insn_idx=36
  libbpf: relocation: find map 1 (__augmented_syscalls__) for insn 36
  libbpf: collecting relocating info for: 'raw_syscalls:sys_exit'
  libbpf: relo for 8 value 0 name 0
  libbpf: relocation: insn_idx=0
  libbpf: relo for 8 value 0 name 0
  libbpf: relocation: insn_idx=2
  bpf: config program 'raw_syscalls:sys_enter'
  bpf: config program 'raw_syscalls:sys_exit'
  libbpf: create map __bpf_stdout__: fd=3
  libbpf: create map __augmented_syscalls__: fd=4
  libbpf: create map syscalls: fd=5
  libbpf: create map pids_filtered: fd=6
  libbpf: added 13 insn from .text to prog raw_syscalls:sys_enter
  libbpf: added 13 insn from .text to prog raw_syscalls:sys_exit
  libbpf: load bpf program failed: Operation not permitted
  libbpf: failed to load program 'raw_syscalls:sys_exit'
  libbpf: failed to load object 
'tools/perf/examples/bpf/augmented_raw_syscalls.c'
  bpf: load objects failed: err=-4009: (Incorrect kernel version)
  event syntax error: 'tools/perf/examples/bpf/augmented_raw_syscalls.c'
   \___ Failed to load program for unknown reason

  (add -v to see detail)
  Run 'perf list' for a list of valid events

   Usage: perf trace [] []
  or: perf trace [] --  []
  or: perf trace record [] []
  or: perf trace record [] --  []

  -e, --eventevent/syscall selector. use 'perf list' to list 
available events

If I then try to use strace (perf trace'ing 'perf trace' needs some more work
before its possible) to get a bit more info I get:

  # strace -e bpf trace --filter-pids 2469,1663 -e 
tools/perf/examples/bpf/augmented_raw_syscalls.c sleep 1
  bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_PERF_EVENT_ARRAY, key_size=4, 
value_size=4, max_entries=4, map_flags=0, inner_map_fd=0, 
map_name="__bpf_stdout__", map_ifindex=0}, 72) = 3
  bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_PERF_EVENT_ARRAY, key_size=4, 
value_size=4, max_entries=4, map_flags=0, inner_map_fd=0, 
map_name="__augmented_sys", map_ifindex=0}, 72) = 4
  bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_ARRAY, key_size=4, value_size=1, 
max_entries=500, map_flags=0, inner_map_fd=0, map_name="syscalls", 
map_ifindex=0}, 72) = 5
  bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_HASH, key_size=4, value_size=1, 
max_entries=512, map_flags=0, inner_map_fd=0, map_name="pids_filtered", 
map_ifindex=0}, 72) = 6
  bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_TRACEPOINT, insn_cnt=57, 
insns=0x1223f50, license="GPL", log_level=0, log_size=0, log_buf=NULL, 
kern_version=KERNEL_VERSION(4, 18, 10), prog_flags=0, prog_name="sys_enter", 
prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS}, 72) = 7
  bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_TRACEPOINT, insn_cnt=18, 
insns=0x1224120, license="GPL", log_level=0, log_size=0, log_buf=NULL, 
kern_version=KERNEL_VERSION(4, 18, 10), prog_flags=0, prog_name="sys_exit", 
prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS}, 72) = -1 EPERM 
(Operation not permitted)
  bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_TRACEPOINT, insn_cnt=18, 
insns=0x1224120, license="GPL", log_level=1, log_size=262144, log_buf="", 
kern_version=KERNEL_VERSION(4, 18, 10), prog_flags=0, prog_name="sys_exit", 
prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS}, 72) = -1 EPERM 
(Operation not permitted)
  bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_KPROBE, insn_cnt=18, 
insns=0x1224120, license="GPL", log_level=0, log_size=0, log_buf=NULL, 
kern_version=KERNEL_VERSION(4, 18, 10), prog_flags=0, prog_name="sys_exit", 
prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS}, 72) = -1 EPERM 
(Operation not permitted)
  event syntax error: 'tools/perf/examples/bpf/augmented_raw_syscalls.c'
   \___ Failed to load program for unknown reason
  
  #

I managed to create the maps, etc, but then installing the "sys_exit" hook into
the "raw_syscalls:sys_exit" tracepoint somehow 

[tip:perf/core] perf script: Add newline after uregs output

2018-11-21 Thread tip-bot for Milian Wolff
Commit-ID:  b07d16f7e9e4cf2562f61b5f68a4b0831fe5ef14
Gitweb: https://git.kernel.org/tip/b07d16f7e9e4cf2562f61b5f68a4b0831fe5ef14
Author: Milian Wolff 
AuthorDate: Wed, 7 Nov 2018 10:37:05 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 12:00:31 -0300

perf script: Add newline after uregs output

This change makes it much easier to easily distinguish between
consecutive samples by keeping the empty line between them, like we see
when we do not enable uregs output.

Before:

  cpp-inlining 28298 [-01] 54837.342780:3068085 cycles:pp:
  77c96709 __hypot_finite+0xa9 (/usr/lib/libm-2.28.so)
  ...
   ABI:2AX:0x0BX:0x40f56cf6CX:0x294a3ae7...
  cpp-inlining 28298 [-01] 54837.344493:2881929 cycles:pp:
  77c96696 __hypot_finite+0x36 (/usr/lib/libm-2.28.so)
  ...
   ABI:2AX:0x40d440c7BX:0x40d440c7CX:0x4d45e5da...

After:

  cpp-inlining 28298 [-01] 54837.342780:3068085 cycles:pp:
  77c96709 __hypot_finite+0xa9 (/usr/lib/libm-2.28.so)
  ...
   ABI:2AX:0x0BX:0x40f56cf6CX:0x294a3ae7...

  cpp-inlining 28298 [-01] 54837.344493:2881929 cycles:pp:
  77c96696 __hypot_finite+0x36 (/usr/lib/libm-2.28.so)
  ...
   ABI:2AX:0x40d440c7BX:0x40d440c7CX:0x4d45e5da...

Signed-off-by: Milian Wolff 
Cc: Jiri Olsa 
Link: http://lkml.kernel.org/r/20181107093705.16346-1-milian.wo...@kdab.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-script.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index b5bc85bd0bbe..daf73832743e 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -603,6 +603,8 @@ static int perf_sample__fprintf_uregs(struct perf_sample 
*sample,
printed += fprintf(fp, "%5s:0x%"PRIx64" ", perf_reg_name(r), 
val);
}
 
+   fprintf(fp, "\n");
+
return printed;
 }
 


[tip:perf/core] perf script: Add newline after uregs output

2018-11-21 Thread tip-bot for Milian Wolff
Commit-ID:  b07d16f7e9e4cf2562f61b5f68a4b0831fe5ef14
Gitweb: https://git.kernel.org/tip/b07d16f7e9e4cf2562f61b5f68a4b0831fe5ef14
Author: Milian Wolff 
AuthorDate: Wed, 7 Nov 2018 10:37:05 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 12:00:31 -0300

perf script: Add newline after uregs output

This change makes it much easier to easily distinguish between
consecutive samples by keeping the empty line between them, like we see
when we do not enable uregs output.

Before:

  cpp-inlining 28298 [-01] 54837.342780:3068085 cycles:pp:
  77c96709 __hypot_finite+0xa9 (/usr/lib/libm-2.28.so)
  ...
   ABI:2AX:0x0BX:0x40f56cf6CX:0x294a3ae7...
  cpp-inlining 28298 [-01] 54837.344493:2881929 cycles:pp:
  77c96696 __hypot_finite+0x36 (/usr/lib/libm-2.28.so)
  ...
   ABI:2AX:0x40d440c7BX:0x40d440c7CX:0x4d45e5da...

After:

  cpp-inlining 28298 [-01] 54837.342780:3068085 cycles:pp:
  77c96709 __hypot_finite+0xa9 (/usr/lib/libm-2.28.so)
  ...
   ABI:2AX:0x0BX:0x40f56cf6CX:0x294a3ae7...

  cpp-inlining 28298 [-01] 54837.344493:2881929 cycles:pp:
  77c96696 __hypot_finite+0x36 (/usr/lib/libm-2.28.so)
  ...
   ABI:2AX:0x40d440c7BX:0x40d440c7CX:0x4d45e5da...

Signed-off-by: Milian Wolff 
Cc: Jiri Olsa 
Link: http://lkml.kernel.org/r/20181107093705.16346-1-milian.wo...@kdab.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-script.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index b5bc85bd0bbe..daf73832743e 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -603,6 +603,8 @@ static int perf_sample__fprintf_uregs(struct perf_sample 
*sample,
printed += fprintf(fp, "%5s:0x%"PRIx64" ", perf_reg_name(r), 
val);
}
 
+   fprintf(fp, "\n");
+
return printed;
 }
 


Re: [PATCH v5 5/5] arm64: dts: qcom: sdm845: Add USB PHY lane two

2018-11-21 Thread Bjorn Andersson
On Fri 26 Oct 10:35 PDT 2018, Evan Green wrote:

> Add the second lane registers for the USB PHY, now that the
> QMP phy bindings have been updated. This way the driver can stop
> reaching beyond its register region to get at the second lane.
> 
> Signed-off-by: Evan Green 
> Reviewed-by: Douglas Anderson 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
> 
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
>  - Removed erroneous fixup for USB UniPro PHY, which is not dual lane (Doug)
> 
> Changes in v2: None
> 
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 9c72edb678ec..ff2db36ec4fa 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -1188,10 +1188,12 @@
>< GCC_USB3_PHY_PRIM_BCR>;
>   reset-names = "phy", "common";
>  
> - usb_1_ssphy: lane@88e9200 {
> + usb_1_ssphy: lanes@88e9200 {
>   reg = <0x88e9200 0x128>,
> <0x88e9400 0x200>,
> <0x88e9c00 0x218>,
> +   <0x88e9600 0x128>,
> +   <0x88e9800 0x200>,
> <0x88e9a00 0x100>;
>   #phy-cells = <0>;
>   clocks = < GCC_USB3_PRIM_PHY_PIPE_CLK>;
> -- 
> 2.16.4
> 


Re: [PATCH v5 5/5] arm64: dts: qcom: sdm845: Add USB PHY lane two

2018-11-21 Thread Bjorn Andersson
On Fri 26 Oct 10:35 PDT 2018, Evan Green wrote:

> Add the second lane registers for the USB PHY, now that the
> QMP phy bindings have been updated. This way the driver can stop
> reaching beyond its register region to get at the second lane.
> 
> Signed-off-by: Evan Green 
> Reviewed-by: Douglas Anderson 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
> 
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
>  - Removed erroneous fixup for USB UniPro PHY, which is not dual lane (Doug)
> 
> Changes in v2: None
> 
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 9c72edb678ec..ff2db36ec4fa 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -1188,10 +1188,12 @@
>< GCC_USB3_PHY_PRIM_BCR>;
>   reset-names = "phy", "common";
>  
> - usb_1_ssphy: lane@88e9200 {
> + usb_1_ssphy: lanes@88e9200 {
>   reg = <0x88e9200 0x128>,
> <0x88e9400 0x200>,
> <0x88e9c00 0x218>,
> +   <0x88e9600 0x128>,
> +   <0x88e9800 0x200>,
> <0x88e9a00 0x100>;
>   #phy-cells = <0>;
>   clocks = < GCC_USB3_PRIM_PHY_PIPE_CLK>;
> -- 
> 2.16.4
> 


[tip:perf/core] Revert "perf augmented_syscalls: Drop 'write', 'poll' for testing without self pid filter"

2018-11-21 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  4aa792de0b136edbde777d3d69c6fe8cdd8cda72
Gitweb: https://git.kernel.org/tip/4aa792de0b136edbde777d3d69c6fe8cdd8cda72
Author: Arnaldo Carvalho de Melo 
AuthorDate: Wed, 7 Nov 2018 10:54:06 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 12:00:31 -0300

Revert "perf augmented_syscalls: Drop 'write', 'poll' for testing without self 
pid filter"

Now that we have the "filtered_pids" logic in place, no need to do this
rough filter to avoid the feedback loop from 'perf trace's own syscalls,
revert it.

This reverts commit 7ed71f124284359676b6496ae7db724fee9da753.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-88vh02cnkam0vv5f9vp02...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/examples/bpf/augmented_raw_syscalls.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/tools/perf/examples/bpf/augmented_raw_syscalls.c 
b/tools/perf/examples/bpf/augmented_raw_syscalls.c
index 3f26e705b86c..74ce7574073d 100644
--- a/tools/perf/examples/bpf/augmented_raw_syscalls.c
+++ b/tools/perf/examples/bpf/augmented_raw_syscalls.c
@@ -44,9 +44,7 @@ struct augmented_filename {
charvalue[256];
 };
 
-#define SYS_WRITE 1
 #define SYS_OPEN 2
-#define SYS_POLL 7
 #define SYS_OPENAT 257
 
 pid_filter(pids_filtered);
@@ -106,8 +104,6 @@ int sys_enter(struct syscall_enter_args *args)
 *   after the ctx memory access to prevent their down stream 
merging.
 */
switch (augmented_args.args.syscall_nr) {
-   case SYS_WRITE:
-   case SYS_POLL:   return 0;
case SYS_OPEN:   filename_arg = (const void *)args->args[0];
__asm__ __volatile__("": : :"memory");
 break;


[tip:perf/core] perf augmented_syscalls: Remove example hardcoded set of filtered pids

2018-11-21 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  e312747b49d382584aaa62398952832765e28f74
Gitweb: https://git.kernel.org/tip/e312747b49d382584aaa62398952832765e28f74
Author: Arnaldo Carvalho de Melo 
AuthorDate: Wed, 7 Nov 2018 10:09:41 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 12:00:31 -0300

perf augmented_syscalls: Remove example hardcoded set of filtered pids

Now that 'perf trace' fills in that "filtered_pids" BPF map, remove the
set of filtered pids used as an example to test that feature.

That feature works like this:

Starting a system wide 'strace' like 'perf trace' augmented session we
noticed that lots of events take place for a pid, which ends up being
the feedback loop of perf trace's syscalls being processed by the
'gnome-terminal' process:

  # perf trace -e tools/perf/examples/bpf/augmented_raw_syscalls.c
 0.391 ( 0.002 ms): gnome-terminal/2469 read(fd: 17, buf: 
0x564b79f750bc, count: 8176) = 453
 0.394 ( 0.001 ms): gnome-terminal/2469 read(fd: 17, buf: 
0x564b79f75280, count: 7724) = -1 EAGAIN Resource temporarily unavailable
 0.438 ( 0.001 ms): gnome-terminal/2469 read(fd: 4, 
buf: 0x7fffc696aeb0, count: 16) = 8
 0.519 ( 0.001 ms): gnome-terminal/2469 read(fd: 17, buf: 
0x564b79f75280, count: 7724) = 114
 0.522 ( 0.001 ms): gnome-terminal/2469 read(fd: 17, buf: 
0x564b79f752f1, count: 7611) = -1 EAGAIN Resource temporarily unavailable
  ^C

So we can use --filter-pids to get rid of that one, and in this case what is
being used to implement that functionality is that "filtered_pids" BPF map that
the tools/perf/examples/bpf/augmented_raw_syscalls.c created and that 'perf 
trace'
bpf loader noticed and created a "struct bpf_map" associated that then got 
populated
by 'perf trace':

  # perf trace --filter-pids 2469 -e 
tools/perf/examples/bpf/augmented_raw_syscalls.c
 0.020 ( 0.002 ms): gnome-shell/1663 epoll_pwait(epfd: 
12, events: 0x7ffd8f3ef960, maxevents: 32, sigsetsize: 
8) = 1
 0.025 ( 0.002 ms): gnome-shell/1663 read(fd: 24, buf: 
0x560c01bb8240, count: 8112) = 48
 0.029 ( 0.001 ms): gnome-shell/1663 read(fd: 24, buf: 
0x560c01bb8258, count: 8088) = -1 EAGAIN Resource temporarily unavailable
 0.032 ( 0.001 ms): gnome-shell/1663 read(fd: 24, buf: 
0x560c01bb8240, count: 8112) = -1 EAGAIN Resource temporarily unavailable
 0.040 ( 0.003 ms): gnome-shell/1663 recvmsg(fd: 46, msg: 
0x7ffd8f3ef950) = -1 EAGAIN Resource temporarily unavailable
21.529 ( 0.002 ms): gnome-shell/1663 epoll_pwait(epfd: 
5, events: 0x7ffd8f3ef960, maxevents: 32, sigsetsize: 
8) = 1
21.533 ( 0.004 ms): gnome-shell/1663 recvmsg(fd: 82, msg: 
0x7ffd8f3ef7b0, flags: DONTWAIT|CMSG_CLOEXEC) = 236
21.581 ( 0.006 ms): gnome-shell/1663 ioctl(fd: 8, cmd: 
DRM_I915_GEM_BUSY, arg: 0x7ffd8f3ef060) = 0
21.605 ( 0.020 ms): gnome-shell/1663 ioctl(fd: 8, cmd: 
DRM_I915_GEM_CREATE, arg: 0x7ffd8f3eeea0) = 0
21.626 ( 0.119 ms): gnome-shell/1663 ioctl(fd: 8, cmd: 
DRM_I915_GEM_SET_DOMAIN, arg: 0x7ffd8f3eee94) = 0
21.746 ( 0.081 ms): gnome-shell/1663 ioctl(fd: 8, cmd: 
DRM_I915_GEM_PWRITE, arg: 0x7ffd8f3eeea0) = 0
  ^C

Oops, yet another gnome process that is involved with the output that
'perf trace' generates, lets filter that out too:

  # perf trace --filter-pids 2469,1663 -e 
tools/perf/examples/bpf/augmented_raw_syscalls.c
 ? ( ): wpa_supplicant/1366  ... [continued]: select()) = 0 
Timeout
 0.006 ( 0.002 ms): wpa_supplicant/1366 clock_gettime(which_clock: 
BOOTTIME, tp: 0x7fffe5b1e430) = 0
 0.011 ( 0.001 ms): wpa_supplicant/1366 clock_gettime(which_clock: 
BOOTTIME, tp: 0x7fffe5b1e3e0) = 0
 0.014 ( 0.001 ms): wpa_supplicant/1366 clock_gettime(which_clock: 
BOOTTIME, tp: 0x7fffe5b1e430) = 0
 ? ( ): gmain/1791  ... [continued]: poll()) = 0 Timeout
 0.017 ( ): wpa_supplicant/1366 select(n: 6, inp: 0x55646fed3ad0, 
outp: 0x55646fed3b60, exp: 0x55646fed3bf0, tvp: 0x7fffe5b1e4a0) ...
   157.879 ( 0.019 ms): gmain/1791 inotify_add_watch(fd: 8, 
pathname: , mask: 16789454) = -1 ENOENT No such file or directory
 ? ( ): cupsd/1001  ... [continued]: epoll_pwait()) = 0
 ? ( ): gsd-color/1908  ... [continued]: poll()) = 0 Timeout
   499.615 ( ): cupsd/1001 epoll_pwait(epfd: 4, 
events: 0x557a21166500, maxevents: 4096, timeout: 1000, sigsetsize: 8) ...
   586.593 ( 0.004 ms): gsd-color/1908 recvmsg(fd: 3, msg: 
0x7ffdef34e800) = -1 EAGAIN Resource temporarily unavailable
 ? ( ): fwupd/2230  ... [continued]: poll()) = 0 Timeout
 ? ( ): rtkit-daemon/906  ... [continued]: poll()) = 0 Timeout
 ? ( ): rtkit-daemon/907  ... [continued]: poll()) = 1
   724.603 ( 0.007 ms): rtkit-daemon/907 read(fd: 6, buf: 
0x7f05ff768d08, count: 8) = 8
 ? ( ): ssh/5461  ... [continued]: select()) = 1
   810.431 ( 0.002 ms): ssh/5461 clock_gettime(which_clock: BOOTTIME, tp: 
0x7ffd7f39f870) = 0
   ^C

Several syscall exit events for 

[tip:perf/core] Revert "perf augmented_syscalls: Drop 'write', 'poll' for testing without self pid filter"

2018-11-21 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  4aa792de0b136edbde777d3d69c6fe8cdd8cda72
Gitweb: https://git.kernel.org/tip/4aa792de0b136edbde777d3d69c6fe8cdd8cda72
Author: Arnaldo Carvalho de Melo 
AuthorDate: Wed, 7 Nov 2018 10:54:06 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 12:00:31 -0300

Revert "perf augmented_syscalls: Drop 'write', 'poll' for testing without self 
pid filter"

Now that we have the "filtered_pids" logic in place, no need to do this
rough filter to avoid the feedback loop from 'perf trace's own syscalls,
revert it.

This reverts commit 7ed71f124284359676b6496ae7db724fee9da753.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-88vh02cnkam0vv5f9vp02...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/examples/bpf/augmented_raw_syscalls.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/tools/perf/examples/bpf/augmented_raw_syscalls.c 
b/tools/perf/examples/bpf/augmented_raw_syscalls.c
index 3f26e705b86c..74ce7574073d 100644
--- a/tools/perf/examples/bpf/augmented_raw_syscalls.c
+++ b/tools/perf/examples/bpf/augmented_raw_syscalls.c
@@ -44,9 +44,7 @@ struct augmented_filename {
charvalue[256];
 };
 
-#define SYS_WRITE 1
 #define SYS_OPEN 2
-#define SYS_POLL 7
 #define SYS_OPENAT 257
 
 pid_filter(pids_filtered);
@@ -106,8 +104,6 @@ int sys_enter(struct syscall_enter_args *args)
 *   after the ctx memory access to prevent their down stream 
merging.
 */
switch (augmented_args.args.syscall_nr) {
-   case SYS_WRITE:
-   case SYS_POLL:   return 0;
case SYS_OPEN:   filename_arg = (const void *)args->args[0];
__asm__ __volatile__("": : :"memory");
 break;


[tip:perf/core] perf augmented_syscalls: Remove example hardcoded set of filtered pids

2018-11-21 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  e312747b49d382584aaa62398952832765e28f74
Gitweb: https://git.kernel.org/tip/e312747b49d382584aaa62398952832765e28f74
Author: Arnaldo Carvalho de Melo 
AuthorDate: Wed, 7 Nov 2018 10:09:41 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 12:00:31 -0300

perf augmented_syscalls: Remove example hardcoded set of filtered pids

Now that 'perf trace' fills in that "filtered_pids" BPF map, remove the
set of filtered pids used as an example to test that feature.

That feature works like this:

Starting a system wide 'strace' like 'perf trace' augmented session we
noticed that lots of events take place for a pid, which ends up being
the feedback loop of perf trace's syscalls being processed by the
'gnome-terminal' process:

  # perf trace -e tools/perf/examples/bpf/augmented_raw_syscalls.c
 0.391 ( 0.002 ms): gnome-terminal/2469 read(fd: 17, buf: 
0x564b79f750bc, count: 8176) = 453
 0.394 ( 0.001 ms): gnome-terminal/2469 read(fd: 17, buf: 
0x564b79f75280, count: 7724) = -1 EAGAIN Resource temporarily unavailable
 0.438 ( 0.001 ms): gnome-terminal/2469 read(fd: 4, 
buf: 0x7fffc696aeb0, count: 16) = 8
 0.519 ( 0.001 ms): gnome-terminal/2469 read(fd: 17, buf: 
0x564b79f75280, count: 7724) = 114
 0.522 ( 0.001 ms): gnome-terminal/2469 read(fd: 17, buf: 
0x564b79f752f1, count: 7611) = -1 EAGAIN Resource temporarily unavailable
  ^C

So we can use --filter-pids to get rid of that one, and in this case what is
being used to implement that functionality is that "filtered_pids" BPF map that
the tools/perf/examples/bpf/augmented_raw_syscalls.c created and that 'perf 
trace'
bpf loader noticed and created a "struct bpf_map" associated that then got 
populated
by 'perf trace':

  # perf trace --filter-pids 2469 -e 
tools/perf/examples/bpf/augmented_raw_syscalls.c
 0.020 ( 0.002 ms): gnome-shell/1663 epoll_pwait(epfd: 
12, events: 0x7ffd8f3ef960, maxevents: 32, sigsetsize: 
8) = 1
 0.025 ( 0.002 ms): gnome-shell/1663 read(fd: 24, buf: 
0x560c01bb8240, count: 8112) = 48
 0.029 ( 0.001 ms): gnome-shell/1663 read(fd: 24, buf: 
0x560c01bb8258, count: 8088) = -1 EAGAIN Resource temporarily unavailable
 0.032 ( 0.001 ms): gnome-shell/1663 read(fd: 24, buf: 
0x560c01bb8240, count: 8112) = -1 EAGAIN Resource temporarily unavailable
 0.040 ( 0.003 ms): gnome-shell/1663 recvmsg(fd: 46, msg: 
0x7ffd8f3ef950) = -1 EAGAIN Resource temporarily unavailable
21.529 ( 0.002 ms): gnome-shell/1663 epoll_pwait(epfd: 
5, events: 0x7ffd8f3ef960, maxevents: 32, sigsetsize: 
8) = 1
21.533 ( 0.004 ms): gnome-shell/1663 recvmsg(fd: 82, msg: 
0x7ffd8f3ef7b0, flags: DONTWAIT|CMSG_CLOEXEC) = 236
21.581 ( 0.006 ms): gnome-shell/1663 ioctl(fd: 8, cmd: 
DRM_I915_GEM_BUSY, arg: 0x7ffd8f3ef060) = 0
21.605 ( 0.020 ms): gnome-shell/1663 ioctl(fd: 8, cmd: 
DRM_I915_GEM_CREATE, arg: 0x7ffd8f3eeea0) = 0
21.626 ( 0.119 ms): gnome-shell/1663 ioctl(fd: 8, cmd: 
DRM_I915_GEM_SET_DOMAIN, arg: 0x7ffd8f3eee94) = 0
21.746 ( 0.081 ms): gnome-shell/1663 ioctl(fd: 8, cmd: 
DRM_I915_GEM_PWRITE, arg: 0x7ffd8f3eeea0) = 0
  ^C

Oops, yet another gnome process that is involved with the output that
'perf trace' generates, lets filter that out too:

  # perf trace --filter-pids 2469,1663 -e 
tools/perf/examples/bpf/augmented_raw_syscalls.c
 ? ( ): wpa_supplicant/1366  ... [continued]: select()) = 0 
Timeout
 0.006 ( 0.002 ms): wpa_supplicant/1366 clock_gettime(which_clock: 
BOOTTIME, tp: 0x7fffe5b1e430) = 0
 0.011 ( 0.001 ms): wpa_supplicant/1366 clock_gettime(which_clock: 
BOOTTIME, tp: 0x7fffe5b1e3e0) = 0
 0.014 ( 0.001 ms): wpa_supplicant/1366 clock_gettime(which_clock: 
BOOTTIME, tp: 0x7fffe5b1e430) = 0
 ? ( ): gmain/1791  ... [continued]: poll()) = 0 Timeout
 0.017 ( ): wpa_supplicant/1366 select(n: 6, inp: 0x55646fed3ad0, 
outp: 0x55646fed3b60, exp: 0x55646fed3bf0, tvp: 0x7fffe5b1e4a0) ...
   157.879 ( 0.019 ms): gmain/1791 inotify_add_watch(fd: 8, 
pathname: , mask: 16789454) = -1 ENOENT No such file or directory
 ? ( ): cupsd/1001  ... [continued]: epoll_pwait()) = 0
 ? ( ): gsd-color/1908  ... [continued]: poll()) = 0 Timeout
   499.615 ( ): cupsd/1001 epoll_pwait(epfd: 4, 
events: 0x557a21166500, maxevents: 4096, timeout: 1000, sigsetsize: 8) ...
   586.593 ( 0.004 ms): gsd-color/1908 recvmsg(fd: 3, msg: 
0x7ffdef34e800) = -1 EAGAIN Resource temporarily unavailable
 ? ( ): fwupd/2230  ... [continued]: poll()) = 0 Timeout
 ? ( ): rtkit-daemon/906  ... [continued]: poll()) = 0 Timeout
 ? ( ): rtkit-daemon/907  ... [continued]: poll()) = 1
   724.603 ( 0.007 ms): rtkit-daemon/907 read(fd: 6, buf: 
0x7f05ff768d08, count: 8) = 8
 ? ( ): ssh/5461  ... [continued]: select()) = 1
   810.431 ( 0.002 ms): ssh/5461 clock_gettime(which_clock: BOOTTIME, tp: 
0x7ffd7f39f870) = 0
   ^C

Several syscall exit events for 

Re: [PATCH linux-next v1 2/4] clk: renesas: Add binding document for AVB Counter Clock

2018-11-21 Thread Jiada Wang

Hi Stephen


On 2018/11/04 12:14, Stephen Boyd wrote:

Quoting Jiada Wang (2018-10-31 05:00:49)

On 2018/10/30 3:29, Stephen Boyd wrote:

Quoting jiada_w...@mentor.com (2018-10-25 00:23:47)

+Required Properties:
+  - compatible: Must be "renesas,clk-avb"
+  - reg: Base address and length of the memory resource used by the AVB
+  - #clock-cells: Must be 1
+
+Example
+---
+
+   clk_avb: avb-clock@ec5a011c {
+   compatible = "renesas,clk-avb";
+   reg = <0 0xec5a011c 0 0x24>;

This is an odd register offset. Is this just one clk inside of a larger
clk controller?


Yes, avb_counter clock is part of Audio Clock Generator reg: <0
0xec5a 0 0x140>,
but "adg" has already been declared in R-Car GEN2/GEN3 SoC .dtsi file,
with reg: <0 0xec5a 0 0x100>,
which leaves <0 0xec5a0100 0 0x140> currently not used by any module.


So why can't we expand the register size in the dts file and update the
audio clock generator driver to register this avb clock too? Presumably
the mapping is large enough to cover the clk registers already so it is
more of a formality to expand the register size than a requirement.

I am working on ver2 to expend register size to cover <0 0xec5a0100 0 0x140>
in audio clock generator (ADG) driver, but as provider of newly added 
"AVB_COUNTER" clock,

ADG driver also uses these clocks if necessary, so it keeps itself BUSY,
and cause ADG driver can't be unloaded.
my question is, is such use case allowed? (clock provider is also client 
of clocks).



Thanks,
Jiada



Re: [PATCH linux-next v1 2/4] clk: renesas: Add binding document for AVB Counter Clock

2018-11-21 Thread Jiada Wang

Hi Stephen


On 2018/11/04 12:14, Stephen Boyd wrote:

Quoting Jiada Wang (2018-10-31 05:00:49)

On 2018/10/30 3:29, Stephen Boyd wrote:

Quoting jiada_w...@mentor.com (2018-10-25 00:23:47)

+Required Properties:
+  - compatible: Must be "renesas,clk-avb"
+  - reg: Base address and length of the memory resource used by the AVB
+  - #clock-cells: Must be 1
+
+Example
+---
+
+   clk_avb: avb-clock@ec5a011c {
+   compatible = "renesas,clk-avb";
+   reg = <0 0xec5a011c 0 0x24>;

This is an odd register offset. Is this just one clk inside of a larger
clk controller?


Yes, avb_counter clock is part of Audio Clock Generator reg: <0
0xec5a 0 0x140>,
but "adg" has already been declared in R-Car GEN2/GEN3 SoC .dtsi file,
with reg: <0 0xec5a 0 0x100>,
which leaves <0 0xec5a0100 0 0x140> currently not used by any module.


So why can't we expand the register size in the dts file and update the
audio clock generator driver to register this avb clock too? Presumably
the mapping is large enough to cover the clk registers already so it is
more of a formality to expand the register size than a requirement.

I am working on ver2 to expend register size to cover <0 0xec5a0100 0 0x140>
in audio clock generator (ADG) driver, but as provider of newly added 
"AVB_COUNTER" clock,

ADG driver also uses these clocks if necessary, so it keeps itself BUSY,
and cause ADG driver can't be unloaded.
my question is, is such use case allowed? (clock provider is also client 
of clocks).



Thanks,
Jiada



[tip:perf/core] perf trace: Fill in BPF "filtered_pids" map when present

2018-11-21 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  a9964c432bccb9222b6ac671324f73d629ff7ac9
Gitweb: https://git.kernel.org/tip/a9964c432bccb9222b6ac671324f73d629ff7ac9
Author: Arnaldo Carvalho de Melo 
AuthorDate: Wed, 7 Nov 2018 10:08:00 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 12:00:31 -0300

perf trace: Fill in BPF "filtered_pids" map when present

This makes the augmented_syscalls support the --filter-pids and
auto-filtered feedback loop pids just like when working without BPF,
i.e. with just raw_syscalls:sys_{enter,exit} and tracepoint filters.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-zc5n453sxxm0tz1zfwwel...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c | 61 --
 1 file changed, 48 insertions(+), 13 deletions(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index c423a78b5ecd..8e3c3f74a3a4 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -2567,9 +2567,27 @@ out_enomem:
goto out;
 }
 
+static int bpf_map__set_filter_pids(struct bpf_map *map __maybe_unused,
+   size_t npids __maybe_unused, pid_t *pids 
__maybe_unused)
+{
+   int err = 0;
+#ifdef HAVE_LIBBPF_SUPPORT
+   bool value = true;
+   int map_fd = bpf_map__fd(map);
+   size_t i;
+
+   for (i = 0; i < npids; ++i) {
+   err = bpf_map_update_elem(map_fd, [i], , BPF_ANY);
+   if (err)
+   break;
+   }
+#endif
+   return err;
+}
+
 static int trace__set_filter_loop_pids(struct trace *trace)
 {
-   unsigned int nr = 1;
+   unsigned int nr = 1, err;
pid_t pids[32] = {
getpid(),
};
@@ -2588,7 +2606,34 @@ static int trace__set_filter_loop_pids(struct trace 
*trace)
thread = parent;
}
 
-   return perf_evlist__set_tp_filter_pids(trace->evlist, nr, pids);
+   err = perf_evlist__set_tp_filter_pids(trace->evlist, nr, pids);
+   if (!err && trace->filter_pids.map)
+   err = bpf_map__set_filter_pids(trace->filter_pids.map, nr, 
pids);
+
+   return err;
+}
+
+static int trace__set_filter_pids(struct trace *trace)
+{
+   int err = 0;
+   /*
+* Better not use !target__has_task() here because we need to cover the
+* case where no threads were specified in the command line, but a
+* workload was, and in that case we will fill in the thread_map when
+* we fork the workload in perf_evlist__prepare_workload.
+*/
+   if (trace->filter_pids.nr > 0) {
+   err = perf_evlist__set_tp_filter_pids(trace->evlist, 
trace->filter_pids.nr,
+ 
trace->filter_pids.entries);
+   if (!err && trace->filter_pids.map) {
+   err = bpf_map__set_filter_pids(trace->filter_pids.map, 
trace->filter_pids.nr,
+  
trace->filter_pids.entries);
+   }
+   } else if (thread_map__pid(trace->evlist->threads, 0) == -1) {
+   err = trace__set_filter_loop_pids(trace);
+   }
+
+   return err;
 }
 
 static int trace__run(struct trace *trace, int argc, const char **argv)
@@ -2697,17 +2742,7 @@ static int trace__run(struct trace *trace, int argc, 
const char **argv)
goto out_error_open;
}
 
-   /*
-* Better not use !target__has_task() here because we need to cover the
-* case where no threads were specified in the command line, but a
-* workload was, and in that case we will fill in the thread_map when
-* we fork the workload in perf_evlist__prepare_workload.
-*/
-   if (trace->filter_pids.nr > 0)
-   err = perf_evlist__set_tp_filter_pids(evlist, 
trace->filter_pids.nr, trace->filter_pids.entries);
-   else if (thread_map__pid(evlist->threads, 0) == -1)
-   err = trace__set_filter_loop_pids(trace);
-
+   err = trace__set_filter_pids(trace);
if (err < 0)
goto out_error_mem;
 


[tip:perf/core] perf trace: Fill in BPF "filtered_pids" map when present

2018-11-21 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  a9964c432bccb9222b6ac671324f73d629ff7ac9
Gitweb: https://git.kernel.org/tip/a9964c432bccb9222b6ac671324f73d629ff7ac9
Author: Arnaldo Carvalho de Melo 
AuthorDate: Wed, 7 Nov 2018 10:08:00 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Nov 2018 12:00:31 -0300

perf trace: Fill in BPF "filtered_pids" map when present

This makes the augmented_syscalls support the --filter-pids and
auto-filtered feedback loop pids just like when working without BPF,
i.e. with just raw_syscalls:sys_{enter,exit} and tracepoint filters.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-zc5n453sxxm0tz1zfwwel...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c | 61 --
 1 file changed, 48 insertions(+), 13 deletions(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index c423a78b5ecd..8e3c3f74a3a4 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -2567,9 +2567,27 @@ out_enomem:
goto out;
 }
 
+static int bpf_map__set_filter_pids(struct bpf_map *map __maybe_unused,
+   size_t npids __maybe_unused, pid_t *pids 
__maybe_unused)
+{
+   int err = 0;
+#ifdef HAVE_LIBBPF_SUPPORT
+   bool value = true;
+   int map_fd = bpf_map__fd(map);
+   size_t i;
+
+   for (i = 0; i < npids; ++i) {
+   err = bpf_map_update_elem(map_fd, [i], , BPF_ANY);
+   if (err)
+   break;
+   }
+#endif
+   return err;
+}
+
 static int trace__set_filter_loop_pids(struct trace *trace)
 {
-   unsigned int nr = 1;
+   unsigned int nr = 1, err;
pid_t pids[32] = {
getpid(),
};
@@ -2588,7 +2606,34 @@ static int trace__set_filter_loop_pids(struct trace 
*trace)
thread = parent;
}
 
-   return perf_evlist__set_tp_filter_pids(trace->evlist, nr, pids);
+   err = perf_evlist__set_tp_filter_pids(trace->evlist, nr, pids);
+   if (!err && trace->filter_pids.map)
+   err = bpf_map__set_filter_pids(trace->filter_pids.map, nr, 
pids);
+
+   return err;
+}
+
+static int trace__set_filter_pids(struct trace *trace)
+{
+   int err = 0;
+   /*
+* Better not use !target__has_task() here because we need to cover the
+* case where no threads were specified in the command line, but a
+* workload was, and in that case we will fill in the thread_map when
+* we fork the workload in perf_evlist__prepare_workload.
+*/
+   if (trace->filter_pids.nr > 0) {
+   err = perf_evlist__set_tp_filter_pids(trace->evlist, 
trace->filter_pids.nr,
+ 
trace->filter_pids.entries);
+   if (!err && trace->filter_pids.map) {
+   err = bpf_map__set_filter_pids(trace->filter_pids.map, 
trace->filter_pids.nr,
+  
trace->filter_pids.entries);
+   }
+   } else if (thread_map__pid(trace->evlist->threads, 0) == -1) {
+   err = trace__set_filter_loop_pids(trace);
+   }
+
+   return err;
 }
 
 static int trace__run(struct trace *trace, int argc, const char **argv)
@@ -2697,17 +2742,7 @@ static int trace__run(struct trace *trace, int argc, 
const char **argv)
goto out_error_open;
}
 
-   /*
-* Better not use !target__has_task() here because we need to cover the
-* case where no threads were specified in the command line, but a
-* workload was, and in that case we will fill in the thread_map when
-* we fork the workload in perf_evlist__prepare_workload.
-*/
-   if (trace->filter_pids.nr > 0)
-   err = perf_evlist__set_tp_filter_pids(evlist, 
trace->filter_pids.nr, trace->filter_pids.entries);
-   else if (thread_map__pid(evlist->threads, 0) == -1)
-   err = trace__set_filter_loop_pids(trace);
-
+   err = trace__set_filter_pids(trace);
if (err < 0)
goto out_error_mem;
 


  1   2   3   4   5   6   7   8   9   10   >