[RFC] mm: Generalize notify_page_fault()

2019-05-29 Thread Anshuman Khandual
Similar notify_page_fault() definitions are being used by architectures
duplicating much of the same code. This attempts to unify them into a
single implementation, generalize it and then move it to a common place.
kprobes_built_in() can detect CONFIG_KPROBES, hence notify_page_fault()
must not be wrapped again within CONFIG_KPROBES. Trap number argument can
now contain upto an 'unsigned int' accommodating all possible platforms.

Signed-off-by: Anshuman Khandual 

Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-i...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Matthew Wilcox 
Cc: Mark Rutland 
Cc: Christophe Leroy 
Cc: Stephen Rothwell 
Cc: Andrey Konovalov 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Yoshinori Sato 
Cc: "David S. Miller" 
---
Boot tested on arm64 and build tested on some others.

 arch/arm/mm/fault.c  | 22 --
 arch/arm64/mm/fault.c| 22 --
 arch/ia64/mm/fault.c | 22 --
 arch/powerpc/mm/fault.c  | 23 ++-
 arch/s390/mm/fault.c | 16 +---
 arch/sh/mm/fault.c   | 14 --
 arch/sparc/mm/fault_64.c | 16 +---
 include/linux/mm.h   |  1 +
 mm/memory.c  | 14 ++
 9 files changed, 19 insertions(+), 131 deletions(-)

diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 58f69fa..1bc3b18 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -30,28 +30,6 @@
 
 #ifdef CONFIG_MMU
 
-#ifdef CONFIG_KPROBES
-static inline int notify_page_fault(struct pt_regs *regs, unsigned int fsr)
-{
-   int ret = 0;
-
-   if (!user_mode(regs)) {
-   /* kprobe_running() needs smp_processor_id() */
-   preempt_disable();
-   if (kprobe_running() && kprobe_fault_handler(regs, fsr))
-   ret = 1;
-   preempt_enable();
-   }
-
-   return ret;
-}
-#else
-static inline int notify_page_fault(struct pt_regs *regs, unsigned int fsr)
-{
-   return 0;
-}
-#endif
-
 /*
  * This is useful to dump out the page tables associated with
  * 'addr' in mm 'mm'.
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index a30818e..152f1f1 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -70,28 +70,6 @@ static inline const struct fault_info 
*esr_to_debug_fault_info(unsigned int esr)
return debug_fault_info + DBG_ESR_EVT(esr);
 }
 
-#ifdef CONFIG_KPROBES
-static inline int notify_page_fault(struct pt_regs *regs, unsigned int esr)
-{
-   int ret = 0;
-
-   /* kprobe_running() needs smp_processor_id() */
-   if (!user_mode(regs)) {
-   preempt_disable();
-   if (kprobe_running() && kprobe_fault_handler(regs, esr))
-   ret = 1;
-   preempt_enable();
-   }
-
-   return ret;
-}
-#else
-static inline int notify_page_fault(struct pt_regs *regs, unsigned int esr)
-{
-   return 0;
-}
-#endif
-
 static void data_abort_decode(unsigned int esr)
 {
pr_alert("Data abort info:\n");
diff --git a/arch/ia64/mm/fault.c b/arch/ia64/mm/fault.c
index 5baeb02..64283d2 100644
--- a/arch/ia64/mm/fault.c
+++ b/arch/ia64/mm/fault.c
@@ -21,28 +21,6 @@
 
 extern int die(char *, struct pt_regs *, long);
 
-#ifdef CONFIG_KPROBES
-static inline int notify_page_fault(struct pt_regs *regs, int trap)
-{
-   int ret = 0;
-
-   if (!user_mode(regs)) {
-   /* kprobe_running() needs smp_processor_id() */
-   preempt_disable();
-   if (kprobe_running() && kprobe_fault_handler(regs, trap))
-   ret = 1;
-   preempt_enable();
-   }
-
-   return ret;
-}
-#else
-static inline int notify_page_fault(struct pt_regs *regs, int trap)
-{
-   return 0;
-}
-#endif
-
 /*
  * Return TRUE if ADDRESS points at a page in the kernel's mapped segment
  * (inside region 5, on ia64) and that page is present.
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index b5d3578..5a0d71f 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -46,26 +46,6 @@
 #include 
 #include 
 
-static inline bool notify_page_fault(struct pt_regs *regs)
-{
-   bool ret = false;
-
-#ifdef CONFIG_KPROBES
-   /* kprobe_running() needs smp_processor_id() */
-   if (!user_mode(regs)) {
-   preempt_disable();
-   if (kprobe_running() && kprobe_fault_handler(regs, 11))
-   ret = true;
-   preempt_enable();
-   }
-#endif /* CONFIG_KPROBES */
-
-   if (unlikely(debugger_fault_handler(regs)))
-   ret = true;
-
-   return ret;
-}
-
 /*
  * Check whether the instruction inst is a store using
 

[PATCH V1] i2c: busses: tegra: Add suspend-resume support

2019-05-29 Thread Bitan Biswas
Post suspend I2C registers have power on reset values. Before any
transfer initialize I2C registers to prevent I2C transfer timeout
and implement suspend and resume callbacks needed. Fix below errors
post suspend:

1) Tegra I2C transfer timeout during jetson tx2 resume:

[   27.520613] pca953x 1-0074: calling pca953x_resume+0x0/0x1b0 @ 2939, parent: 
i2c-1
[   27.633623] tegra-i2c 316.i2c: i2c transfer timed out
[   27.639162] pca953x 1-0074: Unable to sync registers 0x3-0x5. -110
[   27.645336] pca953x 1-0074: Failed to sync GPIO dir registers: -110
[   27.651596] PM: dpm_run_callback(): pca953x_resume+0x0/0x1b0 returns -110
[   27.658375] pca953x 1-0074: pca953x_resume+0x0/0x1b0 returned -110 after 
127152 usecs
[   27.666194] PM: Device 1-0074 failed to resume: error -110

2) Tegra I2C transfer timeout error on jetson Xavier post resume.

Signed-off-by: Bitan Biswas 
---
 drivers/i2c/busses/i2c-tegra.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index ebaa78d..f6a377f 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -1687,9 +1687,33 @@ static int tegra_i2c_remove(struct platform_device *pdev)
 }
 
 #ifdef CONFIG_PM_SLEEP
+static int tegra_i2c_suspend(struct device *dev)
+{
+   struct tegra_i2c_dev *i2c_dev = dev_get_drvdata(dev);
+
+   i2c_mark_adapter_suspended(_dev->adapter);
+
+   return 0;
+}
+
+static int tegra_i2c_resume(struct device *dev)
+{
+   struct tegra_i2c_dev *i2c_dev = dev_get_drvdata(dev);
+   int ret;
+
+   i2c_lock_bus(_dev->adapter, I2C_LOCK_ROOT_ADAPTER);
+   ret = tegra_i2c_init(i2c_dev, false);
+   i2c_unlock_bus(_dev->adapter, I2C_LOCK_ROOT_ADAPTER);
+   if (!ret)
+   i2c_mark_adapter_resumed(_dev->adapter);
+
+   return ret;
+}
+
 static const struct dev_pm_ops tegra_i2c_pm = {
SET_RUNTIME_PM_OPS(tegra_i2c_runtime_suspend, tegra_i2c_runtime_resume,
   NULL)
+   SET_SYSTEM_SLEEP_PM_OPS(tegra_i2c_suspend, tegra_i2c_resume)
 };
 #define TEGRA_I2C_PM   (_i2c_pm)
 #else
-- 
2.7.4



Re: [PATCH] riscv: Fix udelay in RV32.

2019-05-29 Thread Christoph Hellwig
On Tue, May 28, 2019 at 05:26:49PM +0800, Nick Hu wrote:
> In RV32, udelay would delay the wrong cycle.
> When it shifts right "UDELAY_SHITFT" bits, it
> either delays 0 cycle or 1 cycle. It only works
> correctly in RV64. Because the 'ucycles' always
> needs to be 64 bits variable.

Please use up all your ~72 chars per line in the commit log.

> diff --git a/arch/riscv/lib/delay.c b/arch/riscv/lib/delay.c
> index dce8ae24c6d3..da847f49fb74 100644
> --- a/arch/riscv/lib/delay.c
> +++ b/arch/riscv/lib/delay.c
> @@ -88,7 +88,7 @@ EXPORT_SYMBOL(__delay);
>  
>  void udelay(unsigned long usecs)
>  {
> - unsigned long ucycles = usecs * lpj_fine * UDELAY_MULT;
> + unsigned long long ucycles = (unsigned long long)usecs * lpj_fine * 
> UDELAY_MULT;

And this creates a way too long line.  Pleaase use u64 instead of
unsigned long long to clarify the intention while also fixing the long
lines.


[PATCH 3/3] arm64: defconfig: Select CONFIG_CLK_IMX8MN by default

2019-05-29 Thread Anson . Huang
From: Anson Huang 

Enable CONFIG_CLK_IMX8MN to support i.MX8MN clock driver.

Signed-off-by: Anson Huang 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 8d4f25c..aef797c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -654,6 +654,7 @@ CONFIG_COMMON_CLK_CS2000_CP=y
 CONFIG_COMMON_CLK_S2MPS11=y
 CONFIG_CLK_QORIQ=y
 CONFIG_COMMON_CLK_PWM=y
+CONFIG_CLK_IMX8MN=y
 CONFIG_CLK_IMX8MM=y
 CONFIG_CLK_IMX8MQ=y
 CONFIG_CLK_IMX8QXP=y
-- 
2.7.4



[PATCH 1/3] dt-bindings: imx: Add clock binding doc for i.MX8MN

2019-05-29 Thread Anson . Huang
From: Anson Huang 

Add the clock binding doc for i.MX8MN.

Signed-off-by: Anson Huang 
---
 .../devicetree/bindings/clock/imx8mn-clock.txt |  29 +++
 include/dt-bindings/clock/imx8mn-clock.h   | 215 +
 2 files changed, 244 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/imx8mn-clock.txt
 create mode 100644 include/dt-bindings/clock/imx8mn-clock.h

diff --git a/Documentation/devicetree/bindings/clock/imx8mn-clock.txt 
b/Documentation/devicetree/bindings/clock/imx8mn-clock.txt
new file mode 100644
index 000..d83db5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx8mn-clock.txt
@@ -0,0 +1,29 @@
+* Clock bindings for NXP i.MX8M Nano
+
+Required properties:
+- compatible: Should be "fsl,imx8mn-ccm"
+- reg: Address and length of the register set
+- #clock-cells: Should be <1>
+- clocks: list of clock specifiers, must contain an entry for each required
+  entry in clock-names
+- clock-names: should include the following entries:
+- "osc_32k"
+- "osc_24m"
+- "clk_ext1"
+- "clk_ext2"
+- "clk_ext3"
+- "clk_ext4"
+
+clk: clock-controller@3038 {
+   compatible = "fsl,imx8mn-ccm";
+   reg = <0x0 0x3038 0x0 0x1>;
+   #clock-cells = <1>;
+   clocks = <_32k>, <_24m>, <_ext1>, <_ext2>,
+<_ext3>, <_ext4>;
+   clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
+ "clk_ext3", "clk_ext4";
+};
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mn-clock.h
+for the full list of i.MX8M Nano clock IDs.
diff --git a/include/dt-bindings/clock/imx8mn-clock.h 
b/include/dt-bindings/clock/imx8mn-clock.h
new file mode 100644
index 000..5255b1c
--- /dev/null
+++ b/include/dt-bindings/clock/imx8mn-clock.h
@@ -0,0 +1,215 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2018-2019 NXP
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_IMX8MN_H
+#define __DT_BINDINGS_CLOCK_IMX8MN_H
+
+#define IMX8MN_CLK_DUMMY   0
+#define IMX8MN_CLK_32K 1
+#define IMX8MN_CLK_24M 2
+#define IMX8MN_OSC_HDMI_CLK3
+#define IMX8MN_CLK_EXT14
+#define IMX8MN_CLK_EXT25
+#define IMX8MN_CLK_EXT36
+#define IMX8MN_CLK_EXT47
+#define IMX8MN_AUDIO_PLL1_REF_SEL  8
+#define IMX8MN_AUDIO_PLL2_REF_SEL  9
+#define IMX8MN_VIDEO_PLL1_REF_SEL  10
+#define IMX8MN_DRAM_PLL_REF_SEL11
+#define IMX8MN_GPU_PLL_REF_SEL 12
+#define IMX8MN_VPU_PLL_REF_SEL 13
+#define IMX8MN_ARM_PLL_REF_SEL 14
+#define IMX8MN_SYS_PLL1_REF_SEL15
+#define IMX8MN_SYS_PLL2_REF_SEL16
+#define IMX8MN_SYS_PLL3_REF_SEL17
+#define IMX8MN_AUDIO_PLL1  18
+#define IMX8MN_AUDIO_PLL2  19
+#define IMX8MN_VIDEO_PLL1  20
+#define IMX8MN_DRAM_PLL21
+#define IMX8MN_GPU_PLL 22
+#define IMX8MN_VPU_PLL 23
+#define IMX8MN_ARM_PLL 24
+#define IMX8MN_SYS_PLL125
+#define IMX8MN_SYS_PLL226
+#define IMX8MN_SYS_PLL327
+#define IMX8MN_AUDIO_PLL1_BYPASS   28
+#define IMX8MN_AUDIO_PLL2_BYPASS   29
+#define IMX8MN_VIDEO_PLL1_BYPASS   30
+#define IMX8MN_DRAM_PLL_BYPASS 31
+#define IMX8MN_GPU_PLL_BYPASS  32
+#define IMX8MN_VPU_PLL_BYPASS  33
+#define IMX8MN_ARM_PLL_BYPASS  34
+#define IMX8MN_SYS_PLL1_BYPASS 35
+#define IMX8MN_SYS_PLL2_BYPASS 36
+#define IMX8MN_SYS_PLL3_BYPASS 37
+#define IMX8MN_AUDIO_PLL1_OUT  38
+#define IMX8MN_AUDIO_PLL2_OUT  39
+#define IMX8MN_VIDEO_PLL1_OUT  40
+#define IMX8MN_DRAM_PLL_OUT41
+#define IMX8MN_GPU_PLL_OUT 42
+#define IMX8MN_VPU_PLL_OUT 43
+#define IMX8MN_ARM_PLL_OUT 44
+#define IMX8MN_SYS_PLL1_OUT45
+#define IMX8MN_SYS_PLL2_OUT46
+#define IMX8MN_SYS_PLL3_OUT47
+#define IMX8MN_SYS_PLL1_40M48
+#define IMX8MN_SYS_PLL1_80M49
+#define IMX8MN_SYS_PLL1_100M   50
+#define IMX8MN_SYS_PLL1_133M   51
+#define IMX8MN_SYS_PLL1_160M   52
+#define IMX8MN_SYS_PLL1_200M   53
+#define IMX8MN_SYS_PLL1_266M   54
+#define IMX8MN_SYS_PLL1_400M   55

Re: [PATCH] PCI: endpoint: Add DMA to Linux PCI EP Framework

2019-05-29 Thread Kishon Vijay Abraham I
+Vinod Koul

Hi,

On 30/05/19 4:07 AM, Alan Mikhak wrote:
> On Mon, May 27, 2019 at 2:09 AM Gustavo Pimentel
>  wrote:
>>
>> On Fri, May 24, 2019 at 20:42:43, Alan Mikhak 
>> wrote:
>>
>> Hi Alan,
>>
>>> On Fri, May 24, 2019 at 1:59 AM Gustavo Pimentel
>>>  wrote:

 Hi Alan,

 This patch implementation is very HW implementation dependent and
 requires the DMA to exposed through PCIe BARs, which aren't always the
 case. Besides, you are defining some control bits on
 include/linux/pci-epc.h that may not have any meaning to other types of
 DMA.

 I don't think this was what Kishon had in mind when he developed the
 pcitest, but let see what Kishon was to say about it.

 I've developed a DMA driver for DWC PCI using Linux Kernel DMAengine API
 and which I submitted some days ago.
 By having a DMA driver which implemented using DMAengine API, means the
 pcitest can use the DMAengine client API, which will be completely
 generic to any other DMA implementation.

right, my initial thought process was to use only dmaengine APIs in
pci-epf-test so that the system DMA or DMA within the PCIe controller can be
used transparently. But can we register DMA within the PCIe controller to the
DMA subsystem? AFAIK only system DMA should register with the DMA subsystem.
(ADMA in SDHCI doesn't use dmaengine). Vinod Koul can confirm.

If DMA within the PCIe controller cannot be registered in DMA subsystem, we
should use something like what Alan has done in this patch with dma_read ops.
The dma_read ops implementation in the EP controller can either use dmaengine
APIs or use the DMA within the PCIe controller.

I'll review the patch separately.

Thanks
Kishon


[PATCH 2/3] clk: imx: Add support for i.MX8MN clock driver

2019-05-29 Thread Anson . Huang
From: Anson Huang 

This patch adds i.MX8MN clock driver support.

Signed-off-by: Anson Huang 
---
 drivers/clk/imx/Kconfig  |   6 +
 drivers/clk/imx/Makefile |   1 +
 drivers/clk/imx/clk-imx8mn.c | 609 +++
 3 files changed, 616 insertions(+)
 create mode 100644 drivers/clk/imx/clk-imx8mn.c

diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig
index 0eaf418..1ac0c79 100644
--- a/drivers/clk/imx/Kconfig
+++ b/drivers/clk/imx/Kconfig
@@ -14,6 +14,12 @@ config CLK_IMX8MM
help
Build the driver for i.MX8MM CCM Clock Driver
 
+config CLK_IMX8MN
+   bool "IMX8MN CCM Clock Driver"
+   depends on ARCH_MXC && ARM64
+   help
+   Build the driver for i.MX8MN CCM Clock Driver
+
 config CLK_IMX8MQ
bool "IMX8MQ CCM Clock Driver"
depends on ARCH_MXC && ARM64
diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile
index 05641c6..70a55cd 100644
--- a/drivers/clk/imx/Makefile
+++ b/drivers/clk/imx/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_MXC_CLK_SCU) += \
clk-scu.o \
clk-lpcg-scu.o
 
+obj-$(CONFIG_CLK_IMX8MN) += clk-imx8mn.o
 obj-$(CONFIG_CLK_IMX8MM) += clk-imx8mm.o
 obj-$(CONFIG_CLK_IMX8MQ) += clk-imx8mq.o
 obj-$(CONFIG_CLK_IMX8QXP) += clk-imx8qxp.o clk-imx8qxp-lpcg.o
diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
new file mode 100644
index 000..c38dcd3
--- /dev/null
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -0,0 +1,609 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018-2019 NXP.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+static u32 share_count_sai2;
+static u32 share_count_sai3;
+static u32 share_count_sai5;
+static u32 share_count_sai6;
+static u32 share_count_sai7;
+static u32 share_count_disp;
+static u32 share_count_pdm;
+static u32 share_count_nand;
+
+enum {
+   ARM_PLL,
+   GPU_PLL,
+   VPU_PLL,
+   SYS_PLL1,
+   SYS_PLL2,
+   SYS_PLL3,
+   DRAM_PLL,
+   AUDIO_PLL1,
+   AUDIO_PLL2,
+   VIDEO_PLL2,
+   NR_PLLS,
+};
+
+#define PLL_1416X_RATE(_rate, _m, _p, _s)  \
+   {   \
+   .rate   =   (_rate),\
+   .mdiv   =   (_m),   \
+   .pdiv   =   (_p),   \
+   .sdiv   =   (_s),   \
+   }
+
+#define PLL_1443X_RATE(_rate, _m, _p, _s, _k)  \
+   {   \
+   .rate   =   (_rate),\
+   .mdiv   =   (_m),   \
+   .pdiv   =   (_p),   \
+   .sdiv   =   (_s),   \
+   .kdiv   =   (_k),   \
+   }
+
+static const struct imx_pll14xx_rate_table imx8mn_pll1416x_tbl[] = {
+   PLL_1416X_RATE(18U, 225, 3, 0),
+   PLL_1416X_RATE(16U, 200, 3, 0),
+   PLL_1416X_RATE(12U, 300, 3, 1),
+   PLL_1416X_RATE(10U, 250, 3, 1),
+   PLL_1416X_RATE(8U,  200, 3, 1),
+   PLL_1416X_RATE(75000U,  250, 2, 2),
+   PLL_1416X_RATE(7U,  350, 3, 2),
+   PLL_1416X_RATE(6U,  300, 3, 2),
+};
+
+static const struct imx_pll14xx_rate_table imx8mn_audiopll_tbl[] = {
+   PLL_1443X_RATE(786432000U, 655, 5, 2, 23593),
+   PLL_1443X_RATE(722534400U, 301, 5, 1, 3670),
+};
+
+static const struct imx_pll14xx_rate_table imx8mn_videopll_tbl[] = {
+   PLL_1443X_RATE(65000U, 325, 3, 2, 0),
+   PLL_1443X_RATE(59400U, 198, 2, 2, 0),
+};
+
+static const struct imx_pll14xx_rate_table imx8mn_drampll_tbl[] = {
+   PLL_1443X_RATE(65000U, 325, 3, 2, 0),
+};
+
+static struct imx_pll14xx_clk imx8mn_audio_pll __initdata = {
+   .type = PLL_1443X,
+   .rate_table = imx8mn_audiopll_tbl,
+};
+
+static struct imx_pll14xx_clk imx8mn_video_pll __initdata = {
+   .type = PLL_1443X,
+   .rate_table = imx8mn_videopll_tbl,
+};
+
+static struct imx_pll14xx_clk imx8mn_dram_pll __initdata = {
+   .type = PLL_1443X,
+   .rate_table = imx8mn_drampll_tbl,
+};
+
+static struct imx_pll14xx_clk imx8mn_arm_pll __initdata = {
+   .type = PLL_1416X,
+   .rate_table = imx8mn_pll1416x_tbl,
+};
+
+static struct imx_pll14xx_clk imx8mn_gpu_pll __initdata = {
+   .type = PLL_1416X,
+   .rate_table = imx8mn_pll1416x_tbl,
+};
+
+static struct imx_pll14xx_clk imx8mn_vpu_pll __initdata = {
+   .type = PLL_1416X,
+   .rate_table = imx8mn_pll1416x_tbl,
+};
+
+static struct imx_pll14xx_clk imx8mn_sys_pll __initdata = {
+   .type = PLL_1416X,
+   .rate_table = imx8mn_pll1416x_tbl,
+};
+
+static const char *pll_ref_sels[] = { 

Re: [PATCH] kernel/sys.c: fix possible spectre-v1 in do_prlimit()

2019-05-29 Thread Dianzhang Chen
Though syscall `getrlimit` , it seems not works after check_prlimit_permission.

And the speculation windows are large, as said[1]:
>> Can the speculation proceed past the task_lock()?  Or is the policy to
>> ignore such happy happenstances even if they are available?
>
> Locks are not in the way of speculation. Speculation has almost no limits
> except serializing instructions. At least they respect the magic AND
> limitation in array_index_nospec().

[1] https://do-db2.lkml.org/lkml/2018/5/15/1056

On Wed, May 29, 2019 at 8:18 PM Cyrill Gorcunov  wrote:
>
> On Wed, May 29, 2019 at 10:39:52AM +0800, Dianzhang Chen wrote:
> > Hi,
> >
> > Although when detect it is misprediction and drop the execution, but
> > it can not drop all the effects of speculative execution, like the
> > cache state. During the speculative execution, the:
> >
> >
> > rlim = tsk->signal->rlim + resource;// use resource as index
> >
> > ...
> >
> > *old_rlim = *rlim;
> >
> >
> > may read some secret data into cache.
> >
> > and then the attacker can use side-channel attack to find out what the
> > secret data is.
>
> This code works after check_prlimit_permission call, which means you already
> should have a permission granted. And you implies that misprediction gonna
> be that deep which involves a number of 
> calls/read/writes/jumps/locks-rb-wb-flushes
> and a bunch or other instructions, moreover all conditions are "mispredicted".
> This is very bold and actually unproved claim!
>
> Note that I pointed the patch is fine in cleanup context but seriously I
> don't see how this all can be exploitable in sense of spectre.


RE: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

2019-05-29 Thread Xing, Cedric
> From: Christopherson, Sean J
> Sent: Tuesday, May 28, 2019 2:41 PM
> 
> On Tue, May 28, 2019 at 01:48:02PM -0700, Andy Lutomirski wrote:
> > On Tue, May 28, 2019 at 1:24 PM Sean Christopherson
> >  wrote:
> > >
> > > Actually, I think we do have everything we need from an LSM perspective.
> > > LSMs just need to understand that sgx_enclave_load() with a NULL vma
> > > implies a transition from RW.  For example, SELinux would interpret
> > > sgx_enclave_load(NULL, RX) as requiring FILE__EXECMOD.
> >
> > You lost me here.  What operation triggers this callback?  And
> > wouldn't sgx_enclave_load(NULL, RX) sometimes be a transition from RO
> > or just some fresh executable zero bytes?
> 
> An explicit ioctl() after EACCEPTCOPY to update the allowed permissions.
> For all intents and purposes, the EAUG'd page must start RW.  Maybe a better 
> way to phrase
> it is that at some point the page must be writable to have any value 
> whatsover.
> EACCEPTCOPY explicitly requires the page to be at least RW.  EACCEPT 
> technically doesn't
> require RW, but a RO or RX zero page is useless.  Userspace could still 
> EACCEPT with RO or
> RX, but SGX would assume a minimum of RW for the purposes of the LSM check.

Why is an explicit ioctl() necessary after EACCEPTCOPY? Or why is mprotect() 
not sufficient?

I tend to agree on Andy's MAXPERM model where MAXPERM never changes once 
established.

> 
> > > As Cedric mentioned earlier, the host process doesn't necessarily
> > > know which pages will end up RW vs RX, i.e. sgx_enclave_load(NULL,
> > > RX) already has to be invoked at runtime, and when that happens, the
> > > kernel can take the opportunity to change the VMAs from MAY_RW to MAY_RX.
> > >
> > > For simplicity in the kernel and clarity in userspace, it makes
> > > sense to require an explicit ioctl() to add the to-be-EAUG'd range.
> > > That just leaves us wanting an ioctl() to set the post-EACCEPT{COPY} 
> > > permissions.
> > >
> > > E.g.:
> > >
> > > ioctl(_ADD_REGION, { NULL }) /* NULL == EAUG, MAY_RW */
> > >
> > > mprotect(addr, size, RW);
> > > ...
> > >
> > > EACCEPTCOPY -> EAUG /* page fault handler */
> > >
> > > ioctl(_ACTIVATE_REGION, { addr, size, RX}) /* MAY_RX */
> > >
> > > mprotect(addr, size, RX);
> >
> > In the maxperm model, this mprotect() will fail unless MAXPERM
> > contains RX, which could only happen if MAXPERM=RWX.  So, regardless
> > of how it's actually mapped to SELinux policy, MAXPERM=RWX is
> > functionally like EXECMOD and actual RWX PTEs are functionally like
> > EXECMEM.
> 
> Yep, same idea, except in the proposed flow ACTIVATE_REGION.


> 
> > > ...
> > >
> > > And making ACTIVATE_REGION a single-shot per page eliminates the
> > > need for the MAXPERMS concept (see below).
> > >
> > > > If we keep only one MAXPERM, wouldn't this be the current behavior
> > > > of mmap()/mprotect()?
> > > >
> > > > To be a bit more clear, system admin sets MAXPERM upper bound in
> > > > the form of FILE__{READ|WRITE|EXECUTE|EXECMOD} of
> > > > /dev/sgx/enclave. Then for a process/enclave, if what it requires
> > > > falls below what's allowed on /dev/sgx/enclave, then everything
> > > > will just work. Otherwise, it fails in the form of -EPERM returned
> > > > from mmap()/mprotect(). Please note that MAXPERM here applies to
> > > > "runtime" permissions, while "initial" permissions are taken care
> > > > of by security_enclave_{load|init}. "initial" permissions could be
> > > > more permissive than "runtime" permissions, e.g., RX is still
> > > > required for initial code pages even though system admins could disable 
> > > > dynamically
> loaded code pages by *not* giving FILE__{EXECUTE|EXECMOD}. Therefore, the 
> "initial"
> > > > mapping would still have to be done by the driver (to bypass LSM),
> > > > either via a new ioctl or as part of IOC_EINIT.
> > >
> > > Aha!
> > >
> > > Starting with Cedric's assertion that initial permissions can be
> > > taken directly from SECINFO:
> > >
> > >   - Initial permissions for *EADD* pages are explicitly handled via
> > > sgx_enclave_load() with the exact SECINFO permissions.
> > >
> > >   - Initial permissions for *EAUG* are unconditionally RW.  EACCEPTCOPY
> > > requires the target EPC page to be RW, and EACCEPT with RO is useless.
> > >
> > >   - Runtime permissions break down as follows:
> > >   R   - N/A, subset of RW (EAUG)
> > >   W   - N/A, subset of RW (EAUG) and x86 paging can't do W
> > >   X   - N/A, subset of RX (x86 paging can't do XO)
> >
> > Sure it can!  You just have a hypervisor that maps a PA bit to EPT
> > no-read.  Then you can use that PA bit to suppress read.  Also, Linux
> > already abuses PKRU to simulate XO, although that won't work for
> > enclaves.
> 
> Heh, I intentionally said "x86 paging" to rule out EPT :-)  I'm pretty sure 
> it's a moot
> point though, I have a hard time believing an LSM will allow RW->X and not 
> RW->RX.
> 
> > >   RW  - Handled by EAUG LSM hook 

linux-next: build warning after merge of the userns tree

2019-05-29 Thread Stephen Rothwell
Hi Eric,

After merging the userns tree, today's linux-next build (i386 defconfig)
produced this warning:

arch/x86/mm/fault.c: In function 'do_sigbus':
arch/x86/mm/fault.c:1017:22: warning: unused variable 'tsk' [-Wunused-variable]
  struct task_struct *tsk = current;
  ^~~

Introduced by commit

  351b6825b3a9 ("signal: Explicitly call force_sig_fault on current")

The remaining used of "tsk" are protected by CONFIG_MEMORY_FAILURE.

-- 
Cheers,
Stephen Rothwell


pgpH4vUiJFgyi.pgp
Description: OpenPGP digital signature


Re: [PATCH v3 1/8] dt-bindings: soc: Add Aspeed XDMA engine binding documentation

2019-05-29 Thread Andrew Jeffery



On Thu, 30 May 2019, at 03:40, Eddie James wrote:
> Document the bindings.
> 
> Signed-off-by: Eddie James 
> ---
>  .../devicetree/bindings/soc/aspeed/xdma.txt| 23 
> ++
>  1 file changed, 23 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/aspeed/xdma.txt
> 
> diff --git a/Documentation/devicetree/bindings/soc/aspeed/xdma.txt 
> b/Documentation/devicetree/bindings/soc/aspeed/xdma.txt
> new file mode 100644
> index 000..85e82ea
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/aspeed/xdma.txt
> @@ -0,0 +1,23 @@
> +* Device tree bindings for the Aspeed XDMA Engine
> +
> +The XDMA Engine embedded in the AST2500 SOC can perform automatic DMA
> +operations over PCI between the AST2500 (acting as a BMC) and a host 
> processor.
> +
> +Required properties:
> +
> + - compatible"aspeed,ast2500-xdma"
> + - reg   contains the offset and length of the memory 
> region
> + assigned to the XDMA registers
> + - resetsreset specifier for the syscon reset associated with
> + the XDMA engine
> + - interruptsthe interrupt associated with the XDMA engine 
> on this
> + platform

The indentation is quite distracting. If you rev the series can you fix it?

Otherwise,

Reviewed-by: Andrew Jeffery 

> +
> +Example:
> +
> +xdma@1e6e7000 {
> +compatible = "aspeed,ast2500-xdma";
> +reg = <0x1e6e7000 0x100>;
> +resets = < ASPEED_RESET_XDMA>;
> +interrupts = <6>;
> +};
> -- 
> 1.8.3.1
> 
>


Re: [PATCH] mm/slab_common.c: fix possible spectre-v1 in kmalloc_slab()

2019-05-29 Thread Dianzhang Chen
thanks, i think your suggestion is ok.
in my previous method is easy to understand for spectre  logic,
but your suggestion is more sense to use of array_index_nospec.



On Thu, May 30, 2019 at 3:48 AM Matthew Wilcox  wrote:
>
> On Wed, May 29, 2019 at 08:37:28PM +0800, Dianzhang Chen wrote:
> > The `size` in kmalloc_slab() is indirectly controlled by userspace via 
> > syscall: poll(defined in fs/select.c), hence leading to a potential 
> > exploitation of the Spectre variant 1 vulnerability.
> > The `size` can be controlled from: poll -> do_sys_poll -> kmalloc -> 
> > __kmalloc -> kmalloc_slab.
> >
> > Fix this by sanitizing `size` before using it to index size_index.
>
> I think it makes more sense to sanitize size in size_index_elem(),
> don't you?
>
>  static inline unsigned int size_index_elem(unsigned int bytes)
>  {
> -   return (bytes - 1) / 8;
> +   return array_index_nospec((bytes - 1) / 8, ARRAY_SIZE(size_index));
>  }
>
> (untested)


Re: [PATCH] mm/slab_common.c: fix possible spectre-v1 in kmalloc_slab()

2019-05-29 Thread Dianzhang Chen
It is possible that a CPU mis-predicts the conditional branch, and
speculatively loads size_index[size_index_elem(size)], even if size >192.
Although this value will subsequently be discarded,
but it can not drop all the effects of speculative execution,
such as the presence or absence of data in caches. Such effects may
form side-channels which can be
observed to extract secret information.


As for "why this particular path a needs special treatment while other
size branches are ok",
i think the other size branches need to treatment as well at first place,
but in code `index = fls(size - 1)` the function `fls` will make the
index at specific range,
so it can not use `kmalloc_caches[kmalloc_type(flags)][index]` to load
arbitury data.
But, still it may load some date that it shouldn't, if necessary, i
think can add array_index_nospec as well.



On Thu, May 30, 2019 at 1:49 AM Michal Hocko  wrote:
>
> On Thu 30-05-19 00:39:53, Dianzhang Chen wrote:
> > It's come from `192+1`.
> >
> >
> > The more code fragment is:
> >
> >
> > if (size <= 192) {
> >
> > if (!size)
> >
> > return ZERO_SIZE_PTR;
> >
> > size = array_index_nospec(size, 193);
> >
> > index = size_index[size_index_elem(size)];
> >
> > }
>
> OK I see, I could have looked into the code, my bad. But I am still not
> sure what is the potential exploit scenario and why this particular path
> a needs special treatment while other size branches are ok. Could you be
> more specific please?
> --
> Michal Hocko
> SUSE Labs


Re: [PATCH net-next] ethtool: copy reglen to userspace

2019-05-29 Thread David Miller
From: Vivien Didelot 
Date: Tue, 28 May 2019 16:58:48 -0400

> ethtool_get_regs() allocates a buffer of size reglen obtained from
> ops->get_regs_len(), thus only this value must be used when copying
> the buffer back to userspace. Also no need to check regbuf twice.
> 
> Signed-off-by: Vivien Didelot 

Hmmm, can't regs.len be modified by the driver potentially?


[PATCH] mm/kconfig: Fix neighboring typos

2019-05-29 Thread Kees Cook
This fixes a couple typos I noticed in the slab Kconfig:

sacrifies -> sacrifices
accellerate -> accelerate

Seeing as no other instances of these typos are found elsewhere in the
kernel and that I originally added one of the two, I can only assume
working on slab must have caused damage to the spelling centers of
my brain.

Signed-off-by: Kees Cook 
---
 init/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 4592bf7997c0..2dfb3d7f8079 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1750,7 +1750,7 @@ config SLAB_FREELIST_HARDENED
help
  Many kernel heap attacks try to target slab cache metadata and
  other infrastructure. This options makes minor performance
- sacrifies to harden the kernel slab allocator against common
+ sacrifices to harden the kernel slab allocator against common
  freelist exploit methods.
 
 config SLUB_CPU_PARTIAL
@@ -1758,7 +1758,7 @@ config SLUB_CPU_PARTIAL
depends on SLUB && SMP
bool "SLUB per cpu partial cache"
help
- Per cpu partial caches accellerate objects allocation and freeing
+ Per cpu partial caches accelerate objects allocation and freeing
  that is local to a processor at the price of more indeterminism
  in the latency of the free. On overflow these caches will be cleared
  which requires the taking of locks that may cause latency spikes.
-- 
2.17.1


-- 
Kees Cook


[PATCH 5.1 016/405] kvm: svm/avic: fix off-by-one in checking host APIC ID

2019-05-29 Thread Greg Kroah-Hartman
From: Suthikulpanit, Suravee 

commit c9bcd3e3335d0a29d89fabd2c385e1b989e6f1b0 upstream.

Current logic does not allow VCPU to be loaded onto CPU with
APIC ID 255. This should be allowed since the host physical APIC ID
field in the AVIC Physical APIC table entry is an 8-bit value,
and APIC ID 255 is valid in system with x2APIC enabled.
Instead, do not allow VCPU load if the host APIC ID cannot be
represented by an 8-bit value.

Also, use the more appropriate AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK
instead of AVIC_MAX_PHYSICAL_ID_COUNT.

Signed-off-by: Suravee Suthikulpanit 
Cc: sta...@vger.kernel.org
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kvm/svm.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2024,7 +2024,11 @@ static void avic_vcpu_load(struct kvm_vc
if (!kvm_vcpu_apicv_active(vcpu))
return;
 
-   if (WARN_ON(h_physical_id >= AVIC_MAX_PHYSICAL_ID_COUNT))
+   /*
+* Since the host physical APIC id is 8 bits,
+* we can support host APIC ID upto 255.
+*/
+   if (WARN_ON(h_physical_id > 
AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK))
return;
 
entry = READ_ONCE(*(svm->avic_physical_id_cache));




[PATCH 5.1 018/405] libnvdimm/pmem: Bypass CONFIG_HARDENED_USERCOPY overhead

2019-05-29 Thread Greg Kroah-Hartman
From: Dan Williams 

commit 52f476a323f9efc959be1c890d0cdcf12e1582e0 upstream.

Jeff discovered that performance improves from ~375K iops to ~519K iops
on a simple psync-write fio workload when moving the location of 'struct
page' from the default PMEM location to DRAM. This result is surprising
because the expectation is that 'struct page' for dax is only needed for
third party references to dax mappings. For example, a dax-mapped buffer
passed to another system call for direct-I/O requires 'struct page' for
sending the request down the driver stack and pinning the page. There is
no usage of 'struct page' for first party access to a file via
read(2)/write(2) and friends.

However, this "no page needed" expectation is violated by
CONFIG_HARDENED_USERCOPY and the check_copy_size() performed in
copy_from_iter_full_nocache() and copy_to_iter_mcsafe(). The
check_heap_object() helper routine assumes the buffer is backed by a
slab allocator (DRAM) page and applies some checks.  Those checks are
invalid, dax pages do not originate from the slab, and redundant,
dax_iomap_actor() has already validated that the I/O is within bounds.
Specifically that routine validates that the logical file offset is
within bounds of the file, then it does a sector-to-pfn translation
which validates that the physical mapping is within bounds of the block
device.

Bypass additional hardened usercopy overhead and call the 'no check'
versions of the copy_{to,from}_iter operations directly.

Fixes: 0aed55af8834 ("x86, uaccess: introduce copy_from_iter_flushcache...")
Cc: 
Cc: Jeff Moyer 
Cc: Ingo Molnar 
Cc: Christoph Hellwig 
Cc: Al Viro 
Cc: Thomas Gleixner 
Cc: Matthew Wilcox 
Reported-and-tested-by: Jeff Smits 
Acked-by: Kees Cook 
Acked-by: Jan Kara 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/nvdimm/pmem.c |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -281,16 +281,22 @@ static long pmem_dax_direct_access(struc
return __pmem_direct_access(pmem, pgoff, nr_pages, kaddr, pfn);
 }
 
+/*
+ * Use the 'no check' versions of copy_from_iter_flushcache() and
+ * copy_to_iter_mcsafe() to bypass HARDENED_USERCOPY overhead. Bounds
+ * checking, both file offset and device offset, is handled by
+ * dax_iomap_actor()
+ */
 static size_t pmem_copy_from_iter(struct dax_device *dax_dev, pgoff_t pgoff,
void *addr, size_t bytes, struct iov_iter *i)
 {
-   return copy_from_iter_flushcache(addr, bytes, i);
+   return _copy_from_iter_flushcache(addr, bytes, i);
 }
 
 static size_t pmem_copy_to_iter(struct dax_device *dax_dev, pgoff_t pgoff,
void *addr, size_t bytes, struct iov_iter *i)
 {
-   return copy_to_iter_mcsafe(addr, bytes, i);
+   return _copy_to_iter_mcsafe(addr, bytes, i);
 }
 
 static const struct dax_operations pmem_dax_ops = {




[PATCH 5.1 002/405] ext4: do not delete unlinked inode from orphan list on failed truncate

2019-05-29 Thread Greg Kroah-Hartman
From: Jan Kara 

commit ee0ed02ca93ef1ecf8963ad96638795d55af2c14 upstream.

It is possible that unlinked inode enters ext4_setattr() (e.g. if
somebody calls ftruncate(2) on unlinked but still open file). In such
case we should not delete the inode from the orphan list if truncate
fails. Note that this is mostly a theoretical concern as filesystem is
corrupted if we reach this path anyway but let's be consistent in our
orphan handling.

Reviewed-by: Ira Weiny 
Signed-off-by: Jan Kara 
Signed-off-by: Theodore Ts'o 
Cc: sta...@kernel.org
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ext4/inode.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5619,7 +5619,7 @@ int ext4_setattr(struct dentry *dentry,
up_write(_I(inode)->i_data_sem);
ext4_journal_stop(handle);
if (error) {
-   if (orphan)
+   if (orphan && inode->i_nlink)
ext4_orphan_del(NULL, inode);
goto err_out;
}




[PATCH 5.1 014/405] dax: Arrange for dax_supported check to span multiple devices

2019-05-29 Thread Greg Kroah-Hartman
From: Dan Williams 

commit 7bf7eac8d648057519adb6fce1e31458c902212c upstream.

Pankaj reports that starting with commit ad428cdb525a "dax: Check the
end of the block-device capacity with dax_direct_access()" device-mapper
no longer allows dax operation. This results from the stricter checks in
__bdev_dax_supported() that validate that the start and end of a
block-device map to the same 'pagemap' instance.

Teach the dax-core and device-mapper to validate the 'pagemap' on a
per-target basis. This is accomplished by refactoring the
bdev_dax_supported() internals into generic_fsdax_supported() which
takes a sector range to validate. Consequently generic_fsdax_supported()
is suitable to be used in a device-mapper ->iterate_devices() callback.
A new ->dax_supported() operation is added to allow composite devices to
split and route upper-level bdev_dax_supported() requests.

Fixes: ad428cdb525a ("dax: Check the end of the block-device...")
Cc: 
Cc: Ira Weiny 
Cc: Dave Jiang 
Cc: Keith Busch 
Cc: Matthew Wilcox 
Cc: Vishal Verma 
Cc: Heiko Carstens 
Cc: Martin Schwidefsky 
Reviewed-by: Jan Kara 
Reported-by: Pankaj Gupta 
Reviewed-by: Pankaj Gupta 
Tested-by: Pankaj Gupta 
Tested-by: Vaibhav Jain 
Reviewed-by: Mike Snitzer 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/dax/super.c  |   88 +++
 drivers/md/dm-table.c|   17 +---
 drivers/md/dm.c  |   20 +
 drivers/md/dm.h  |1 
 drivers/nvdimm/pmem.c|1 
 drivers/s390/block/dcssblk.c |1 
 include/linux/dax.h  |   26 
 7 files changed, 117 insertions(+), 37 deletions(-)

--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -73,22 +73,12 @@ struct dax_device *fs_dax_get_by_bdev(st
 EXPORT_SYMBOL_GPL(fs_dax_get_by_bdev);
 #endif
 
-/**
- * __bdev_dax_supported() - Check if the device supports dax for filesystem
- * @bdev: block device to check
- * @blocksize: The block size of the device
- *
- * This is a library function for filesystems to check if the block device
- * can be mounted with dax option.
- *
- * Return: true if supported, false if unsupported
- */
-bool __bdev_dax_supported(struct block_device *bdev, int blocksize)
+bool __generic_fsdax_supported(struct dax_device *dax_dev,
+   struct block_device *bdev, int blocksize, sector_t start,
+   sector_t sectors)
 {
-   struct dax_device *dax_dev;
bool dax_enabled = false;
pgoff_t pgoff, pgoff_end;
-   struct request_queue *q;
char buf[BDEVNAME_SIZE];
void *kaddr, *end_kaddr;
pfn_t pfn, end_pfn;
@@ -102,21 +92,14 @@ bool __bdev_dax_supported(struct block_d
return false;
}
 
-   q = bdev_get_queue(bdev);
-   if (!q || !blk_queue_dax(q)) {
-   pr_debug("%s: error: request queue doesn't support dax\n",
-   bdevname(bdev, buf));
-   return false;
-   }
-
-   err = bdev_dax_pgoff(bdev, 0, PAGE_SIZE, );
+   err = bdev_dax_pgoff(bdev, start, PAGE_SIZE, );
if (err) {
pr_debug("%s: error: unaligned partition for dax\n",
bdevname(bdev, buf));
return false;
}
 
-   last_page = PFN_DOWN(i_size_read(bdev->bd_inode) - 1) * 8;
+   last_page = PFN_DOWN((start + sectors - 1) * 512) * PAGE_SIZE / 512;
err = bdev_dax_pgoff(bdev, last_page, PAGE_SIZE, _end);
if (err) {
pr_debug("%s: error: unaligned partition for dax\n",
@@ -124,20 +107,11 @@ bool __bdev_dax_supported(struct block_d
return false;
}
 
-   dax_dev = dax_get_by_host(bdev->bd_disk->disk_name);
-   if (!dax_dev) {
-   pr_debug("%s: error: device does not support dax\n",
-   bdevname(bdev, buf));
-   return false;
-   }
-
id = dax_read_lock();
len = dax_direct_access(dax_dev, pgoff, 1, , );
len2 = dax_direct_access(dax_dev, pgoff_end, 1, _kaddr, _pfn);
dax_read_unlock(id);
 
-   put_dax(dax_dev);
-
if (len < 1 || len2 < 1) {
pr_debug("%s: error: dax access failed (%ld)\n",
bdevname(bdev, buf), len < 1 ? len : len2);
@@ -178,6 +152,49 @@ bool __bdev_dax_supported(struct block_d
}
return true;
 }
+EXPORT_SYMBOL_GPL(__generic_fsdax_supported);
+
+/**
+ * __bdev_dax_supported() - Check if the device supports dax for filesystem
+ * @bdev: block device to check
+ * @blocksize: The block size of the device
+ *
+ * This is a library function for filesystems to check if the block device
+ * can be mounted with dax option.
+ *
+ * Return: true if supported, false if unsupported
+ */
+bool __bdev_dax_supported(struct block_device *bdev, int blocksize)
+{
+   struct dax_device *dax_dev;
+   struct request_queue *q;
+   char 

[PATCH 5.1 001/405] x86: Hide the int3_emulate_call/jmp functions from UML

2019-05-29 Thread Greg Kroah-Hartman
From: Steven Rostedt (VMware) 

commit 693713cbdb3a4bda5a8a678c31f06560bbb14657 upstream.

User Mode Linux does not have access to the ip or sp fields of the pt_regs,
and accessing them causes UML to fail to build. Hide the int3_emulate_jmp()
and int3_emulate_call() instructions from UML, as it doesn't need them
anyway.

Reported-by: kbuild test robot 
Signed-off-by: Steven Rostedt (VMware) 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/text-patching.h |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/arch/x86/include/asm/text-patching.h
+++ b/arch/x86/include/asm/text-patching.h
@@ -39,6 +39,7 @@ extern int poke_int3_handler(struct pt_r
 extern void *text_poke_bp(void *addr, const void *opcode, size_t len, void 
*handler);
 extern int after_bootmem;
 
+#ifndef CONFIG_UML_X86
 static inline void int3_emulate_jmp(struct pt_regs *regs, unsigned long ip)
 {
regs->ip = ip;
@@ -65,6 +66,7 @@ static inline void int3_emulate_call(str
int3_emulate_push(regs, regs->ip - INT3_INSN_SIZE + CALL_INSN_SIZE);
int3_emulate_jmp(regs, func);
 }
-#endif
+#endif /* CONFIG_X86_64 */
+#endif /* !CONFIG_UML_X86 */
 
 #endif /* _ASM_X86_TEXT_PATCHING_H */




[PATCH 5.1 011/405] mmc: sdhci-iproc: cygnus: Set NO_HISPD bit to fix HS50 data hold time problem

2019-05-29 Thread Greg Kroah-Hartman
From: Trac Hoang 

commit b7dfa695afc40d5396ed84b9f25aa3754de23e39 upstream.

The iproc host eMMC/SD controller hold time does not meet the
specification in the HS50 mode. This problem can be mitigated
by disabling the HISPD bit; thus forcing the controller output
data to be driven on the falling clock edges rather than the
rising clock edges.

This change applies only to the Cygnus platform.

Stable tag (v4.12+) chosen to assist stable kernel maintainers so that
the change does not produce merge conflicts backporting to older kernel
versions. In reality, the timing bug existed since the driver was first
introduced but there is no need for this driver to be supported in kernel
versions that old.

Cc: sta...@vger.kernel.org # v4.12+
Signed-off-by: Trac Hoang 
Signed-off-by: Scott Branden 
Acked-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mmc/host/sdhci-iproc.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/mmc/host/sdhci-iproc.c
+++ b/drivers/mmc/host/sdhci-iproc.c
@@ -196,7 +196,8 @@ static const struct sdhci_ops sdhci_ipro
 };
 
 static const struct sdhci_pltfm_data sdhci_iproc_cygnus_pltfm_data = {
-   .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
+   .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
+ SDHCI_QUIRK_NO_HISPD_BIT,
.quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN | SDHCI_QUIRK2_HOST_OFF_CARD_ON,
.ops = _iproc_32only_ops,
 };




[PATCH 5.1 028/405] btrfs: sysfs: Fix error path kobject memory leak

2019-05-29 Thread Greg Kroah-Hartman
From: Tobin C. Harding 

commit 450ff8348808a89cc27436771aa05c2b90c0eef1 upstream.

If a call to kobject_init_and_add() fails we must call kobject_put()
otherwise we leak memory.

Calling kobject_put() when kobject_init_and_add() fails drops the
refcount back to 0 and calls the ktype release method (which in turn
calls the percpu destroy and kfree).

Add call to kobject_put() in the error path of call to
kobject_init_and_add().

Cc: sta...@vger.kernel.org # v4.4+
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Tobin C. Harding 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/btrfs/extent-tree.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3981,8 +3981,7 @@ static int create_space_info(struct btrf
info->space_info_kobj, "%s",
alloc_name(space_info->flags));
if (ret) {
-   percpu_counter_destroy(_info->total_bytes_pinned);
-   kfree(space_info);
+   kobject_put(_info->kobj);
return ret;
}
 




RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog device node

2019-05-29 Thread Chuanhua Han


> -Original Message-
> From: Rob Herring 
> Sent: 2019年5月24日 20:29
> To: Chuanhua Han 
> Cc: Leo Li ; Shawn Guo ;
> mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Ying Zhang
> 
> Subject: Re: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog device node
> 
> Caution: EXT Email
> 
> On Fri, May 24, 2019 at 4:48 AM Chuanhua Han 
> wrote:
> >
> > Hi, Rob Herring
> >
> > > -Original Message-
> > > From: Leo Li
> > > Sent: 2019年5月22日 14:50
> 
> 
> > > > > > > > > > - wdog0: watchdog@23c {
> > > > > > > > > > - compatible = "fsl,ls1028a-wdt",
> > > > > "fsl,imx21-wdt";
> > > > > > > > > > - reg = <0x0 0x23c 0x0 0x1>;
> > > > > > > > > > - interrupts =  > > > > > > IRQ_TYPE_LEVEL_HIGH>;
> > > > > > > > > > - clocks = < 4 1>;
> > > > > > > > > > - big-endian;
> > > > > > > > > > - status = "disabled";
> > > > > > > > > > + cluster1_core0_watchdog: wdt@c00 {
> > > > > > > > >
> > > > > > > > > Keep 'watchdog' as the node name,
> > > > > > > > Thanks for your replay
> > > > > > > > Do you mean replace the ‘wdt’ with ‘watchdog’?
> > > > > > > > and keep nodes sort in unit-address.
> > > > > > > > What does this mean?
> > > > > > >
> > > > > > > That means order the nodes by the addresses (e.g. c00,
> > > > > > > c01)
> > > > > > The current order is correct(The first is c00, then c00).
> > > > >
> > > > > But they are added after gpio@232 and before sata@320.
> > > > I changed and made the second version of the patch, but I found
> > > > the following error when I executed ./scripts/checkpatch.pl
> > > > xxx.patch to check the patch:
> > > >
> > > > WARNING: DT compatible string vendor "arm" appears un-documented
> > > > -- check ./Documentation/devicetree/bindings/vendor-prefixes.txt
> > > > #43: FILE: arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi:351:
> > > > + compatible = "arm,sp805", "arm,primecell";
> > > >
> > > > However, there is no vendor-prefixes.txt file in the
> > > > ./Documentation/devicetree/bindings/ directory, only vendor-
> > > > prefixes.yaml.
> > > > Moreover, there are ‘arm’ vendors in vendor-prefixes.yaml.
> > >
> > > Added Rob Herring to the thread.
> > >
> > > > Request help,thanks
> > How can I solve this patch check error? Ask for help, thank you!
> 
> Ignore it. A fix to checkpatch.pl is pending.
OK, the second version has been sent. Checking with checkpatch.pl is no problem.
> 
> Rob


[PATCH 5.1 012/405] mmc: sdhci-iproc: Set NO_HISPD bit to fix HS50 data hold time problem

2019-05-29 Thread Greg Kroah-Hartman
From: Trac Hoang 

commit ec0970e0a1b2c807c908d459641a9f9a1be3e130 upstream.

The iproc host eMMC/SD controller hold time does not meet the
specification in the HS50 mode.  This problem can be mitigated
by disabling the HISPD bit; thus forcing the controller output
data to be driven on the falling clock edges rather than the
rising clock edges.

Stable tag (v4.12+) chosen to assist stable kernel maintainers so that
the change does not produce merge conflicts backporting to older kernel
versions. In reality, the timing bug existed since the driver was first
introduced but there is no need for this driver to be supported in kernel
versions that old.

Cc: sta...@vger.kernel.org # v4.12+
Signed-off-by: Trac Hoang 
Signed-off-by: Scott Branden 
Acked-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mmc/host/sdhci-iproc.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/mmc/host/sdhci-iproc.c
+++ b/drivers/mmc/host/sdhci-iproc.c
@@ -220,7 +220,8 @@ static const struct sdhci_iproc_data ipr
 
 static const struct sdhci_pltfm_data sdhci_iproc_pltfm_data = {
.quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
- SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12,
+ SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 |
+ SDHCI_QUIRK_NO_HISPD_BIT,
.quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN,
.ops = _iproc_ops,
 };




[PATCH 5.1 021/405] arm64/iommu: handle non-remapped addresses in ->mmap and ->get_sgtable

2019-05-29 Thread Greg Kroah-Hartman
From: Christoph Hellwig 

commit a98d9ae937d256ed679a935fc82d9deaa710d98e upstream.

DMA allocations that can't sleep may return non-remapped addresses, but
we do not properly handle them in the mmap and get_sgtable methods.
Resolve non-vmalloc addresses using virt_to_page to handle this corner
case.

Cc: 
Acked-by: Catalin Marinas 
Reviewed-by: Robin Murphy 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/mm/dma-mapping.c |   10 ++
 1 file changed, 10 insertions(+)

--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -249,6 +249,11 @@ static int __iommu_mmap_attrs(struct dev
if (dma_mmap_from_dev_coherent(dev, vma, cpu_addr, size, ))
return ret;
 
+   if (!is_vmalloc_addr(cpu_addr)) {
+   unsigned long pfn = page_to_pfn(virt_to_page(cpu_addr));
+   return __swiotlb_mmap_pfn(vma, pfn, size);
+   }
+
if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
/*
 * DMA_ATTR_FORCE_CONTIGUOUS allocations are always remapped,
@@ -272,6 +277,11 @@ static int __iommu_get_sgtable(struct de
unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
struct vm_struct *area = find_vm_area(cpu_addr);
 
+   if (!is_vmalloc_addr(cpu_addr)) {
+   struct page *page = virt_to_page(cpu_addr);
+   return __swiotlb_get_sgtable_page(sgt, page, size);
+   }
+
if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
/*
 * DMA_ATTR_FORCE_CONTIGUOUS allocations are always remapped,




[PATCH 5.1 024/405] btrfs: Check the compression level before getting a workspace

2019-05-29 Thread Greg Kroah-Hartman
From: Johnny Chang 

commit 2b90883c561ddcc641741c2e4df1f702a4f2acb8 upstream.

When a file's compression property is set as zlib or zstd but leave
the compression mount option not be set, that means btrfs will try
to compress the file with default compression level. But in
btrfs_compress_pages(), it calls get_workspace() with level = 0.
This will return a workspace with a wrong compression level.
For zlib, the compression level in the workspace will be 0
(that means "store only"). And for zstd, the compression in the
workspace will be 1, not the default level 3.

How to reproduce:
  mkfs -t btrfs /dev/sdb
  mount /dev/sdb /mnt/
  mkdir /mnt/zlib
  btrfs property set /mnt/zlib/ compression zlib
  dd if=/dev/zero of=/mnt/zlib/compression-friendly-file-10M bs=1M count=10
  sync
  btrfs-debugfs -f /mnt/zlib/compression-friendly-file-10M

btrfs-debugfs output:
* before:
  ...
  (258 9961472): ram 524288 disk 1106247680 disk_size 524288
  file: ... extents 20 disk size 10485760 logical size 10485760 ratio 1.00

* after:
 ...
 (258 10354688): ram 131072 disk 14217216 disk_size 4096
 file: ... extents 80 disk size 327680 logical size 10485760 ratio 32.00

The steps for zstd are similar, but need to put a debugging message to
show the level of the return workspace in zstd_get_workspace().

This commit adds a check of the compression level before getting a
workspace by set_level().

CC: sta...@vger.kernel.org # 5.1+
Signed-off-by: Johnny Chang 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/btrfs/compression.c |1 +
 1 file changed, 1 insertion(+)

--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/compression.c
@@ -1009,6 +1009,7 @@ int btrfs_compress_pages(unsigned int ty
struct list_head *workspace;
int ret;
 
+   level = btrfs_compress_op[type]->set_level(level);
workspace = get_workspace(type, level);
ret = btrfs_compress_op[type]->compress_pages(workspace, mapping,
  start, pages,




[PATCH 5.1 022/405] gfs2: Fix sign extension bug in gfs2_update_stats

2019-05-29 Thread Greg Kroah-Hartman
From: Andreas Gruenbacher 

commit 5a5ec83d6ac974b12085cd99b196795f14079037 upstream.

Commit 4d207133e9c3 changed the types of the statistic values in struct
gfs2_lkstats from s64 to u64.  Because of that, what should be a signed
value in gfs2_update_stats turned into an unsigned value.  When shifted
right, we end up with a large positive value instead of a small negative
value, which results in an incorrect variance estimate.

Fixes: 4d207133e9c3 ("gfs2: Make statistics unsigned, suitable for use with 
do_div()")
Signed-off-by: Andreas Gruenbacher 
Cc: sta...@vger.kernel.org # v4.4+
Signed-off-by: Greg Kroah-Hartman 

---
 fs/gfs2/lock_dlm.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

--- a/fs/gfs2/lock_dlm.c
+++ b/fs/gfs2/lock_dlm.c
@@ -31,9 +31,10 @@
  * @delta is the difference between the current rtt sample and the
  * running average srtt. We add 1/8 of that to the srtt in order to
  * update the current srtt estimate. The variance estimate is a bit
- * more complicated. We subtract the abs value of the @delta from
- * the current variance estimate and add 1/4 of that to the running
- * total.
+ * more complicated. We subtract the current variance estimate from
+ * the abs value of the @delta and add 1/4 of that to the running
+ * total.  That's equivalent to 3/4 of the current variance
+ * estimate plus 1/4 of the abs of @delta.
  *
  * Note that the index points at the array entry containing the smoothed
  * mean value, and the variance is always in the following entry
@@ -49,7 +50,7 @@ static inline void gfs2_update_stats(str
s64 delta = sample - s->stats[index];
s->stats[index] += (delta >> 3);
index++;
-   s->stats[index] += ((abs(delta) - s->stats[index]) >> 2);
+   s->stats[index] += (s64)(abs(delta) - s->stats[index]) >> 2;
 }
 
 /**




[PATCH 5.1 019/405] arm64/kernel: kaslr: reduce module randomization range to 2 GB

2019-05-29 Thread Greg Kroah-Hartman
From: Ard Biesheuvel 

commit b2eed9b58811283d00fa861944cb75797d4e52a7 upstream.

The following commit

  7290d5809571 ("module: use relative references for __ksymtab entries")

updated the ksymtab handling of some KASLR capable architectures
so that ksymtab entries are emitted as pairs of 32-bit relative
references. This reduces the size of the entries, but more
importantly, it gets rid of statically assigned absolute
addresses, which require fixing up at boot time if the kernel
is self relocating (which takes a 24 byte RELA entry for each
member of the ksymtab struct).

Since ksymtab entries are always part of the same module as the
symbol they export, it was assumed at the time that a 32-bit
relative reference is always sufficient to capture the offset
between a ksymtab entry and its target symbol.

Unfortunately, this is not always true: in the case of per-CPU
variables, a per-CPU variable's base address (which usually differs
from the actual address of any of its per-CPU copies) is allocated
in the vicinity of the ..data.percpu section in the core kernel
(i.e., in the per-CPU reserved region which follows the section
containing the core kernel's statically allocated per-CPU variables).

Since we randomize the module space over a 4 GB window covering
the core kernel (based on the -/+ 4 GB range of an ADRP/ADD pair),
we may end up putting the core kernel out of the -/+ 2 GB range of
32-bit relative references of module ksymtab entries that refer to
per-CPU variables.

So reduce the module randomization range a bit further. We lose
1 bit of randomization this way, but this is something we can
tolerate.

Cc:  # v4.19+
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/kernel/kaslr.c  |6 +++---
 arch/arm64/kernel/module.c |2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

--- a/arch/arm64/kernel/kaslr.c
+++ b/arch/arm64/kernel/kaslr.c
@@ -145,15 +145,15 @@ u64 __init kaslr_early_init(u64 dt_phys)
 
if (IS_ENABLED(CONFIG_RANDOMIZE_MODULE_REGION_FULL)) {
/*
-* Randomize the module region over a 4 GB window covering the
+* Randomize the module region over a 2 GB window covering the
 * kernel. This reduces the risk of modules leaking information
 * about the address of the kernel itself, but results in
 * branches between modules and the core kernel that are
 * resolved via PLTs. (Branches between modules will be
 * resolved normally.)
 */
-   module_range = SZ_4G - (u64)(_end - _stext);
-   module_alloc_base = max((u64)_end + offset - SZ_4G,
+   module_range = SZ_2G - (u64)(_end - _stext);
+   module_alloc_base = max((u64)_end + offset - SZ_2G,
(u64)MODULES_VADDR);
} else {
/*
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -56,7 +56,7 @@ void *module_alloc(unsigned long size)
 * can simply omit this fallback in that case.
 */
p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
-   module_alloc_base + SZ_4G, GFP_KERNEL,
+   module_alloc_base + SZ_2G, GFP_KERNEL,
PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
__builtin_return_address(0));
 




[PATCH 5.1 027/405] Btrfs: fix race between ranged fsync and writeback of adjacent ranges

2019-05-29 Thread Greg Kroah-Hartman
From: Filipe Manana 

commit 0c713cbab6200b0ab6473b50435e450a6e1de85d upstream.

When we do a full fsync (the bit BTRFS_INODE_NEEDS_FULL_SYNC is set in the
inode) that happens to be ranged, which happens during a msync() or writes
for files opened with O_SYNC for example, we can end up with a corrupt log,
due to different file extent items representing ranges that overlap with
each other, or hit some assertion failures.

When doing a ranged fsync we only flush delalloc and wait for ordered
exents within that range. If while we are logging items from our inode
ordered extents for adjacent ranges complete, we end up in a race that can
make us insert the file extent items that overlap with others we logged
previously and the assertion failures.

For example, if tree-log.c:copy_items() receives a leaf that has the
following file extents items, all with a length of 4K and therefore there
is an implicit hole in the range 68K to 72K - 1:

  (257 EXTENT_ITEM 64K), (257 EXTENT_ITEM 72K), (257 EXTENT_ITEM 76K), ...

It copies them to the log tree. However due to the need to detect implicit
holes, it may release the path, in order to look at the previous leaf to
detect an implicit hole, and then later it will search again in the tree
for the first file extent item key, with the goal of locking again the
leaf (which might have changed due to concurrent changes to other inodes).

However when it locks again the leaf containing the first key, the key
corresponding to the extent at offset 72K may not be there anymore since
there is an ordered extent for that range that is finishing (that is,
somewhere in the middle of btrfs_finish_ordered_io()), and it just
removed the file extent item but has not yet replaced it with a new file
extent item, so the part of copy_items() that does hole detection will
decide that there is a hole in the range starting from 68K to 76K - 1,
and therefore insert a file extent item to represent that hole, having
a key offset of 68K. After that we now have a log tree with 2 different
extent items that have overlapping ranges:

 1) The file extent item copied before copy_items() released the path,
which has a key offset of 72K and a length of 4K, representing the
file range 72K to 76K - 1.

 2) And a file extent item representing a hole that has a key offset of
68K and a length of 8K, representing the range 68K to 76K - 1. This
item was inserted after releasing the path, and overlaps with the
extent item inserted before.

The overlapping extent items can cause all sorts of unpredictable and
incorrect behaviour, either when replayed or if a fast (non full) fsync
happens later, which can trigger a BUG_ON() when calling
btrfs_set_item_key_safe() through __btrfs_drop_extents(), producing a
trace like the following:

  [61666.783269] [ cut here ]
  [61666.783943] kernel BUG at fs/btrfs/ctree.c:3182!
  [61666.784644] invalid opcode:  [#1] PREEMPT SMP
  (...)
  [61666.786253] task: 880117b88c40 task.stack: c90008168000
  [61666.786253] RIP: 0010:btrfs_set_item_key_safe+0x7c/0xd2 [btrfs]
  [61666.786253] RSP: 0018:c9000816b958 EFLAGS: 00010246
  [61666.786253] RAX:  RBX: 000f RCX: 
0003
  [61666.786253] RDX:  RSI: c9000816ba4f RDI: 
c9000816b937
  [61666.786253] RBP: c9000816b998 R08: 88011dae2428 R09: 
1000
  [61666.786253] R10: 1600 R11: 6db6db6db6db6db7 R12: 
88011dae2418
  [61666.786253] R13: c9000816ba4f R14: 8801e10c4118 R15: 
8801e715c000
  [61666.786253] FS:  7f6060a18700() GS:88023f5c() 
knlGS:
  [61666.786253] CS:  0010 DS:  ES:  CR0: 80050033
  [61666.786253] CR2: 7f6060a28000 CR3: 000213e69000 CR4: 
06e0
  [61666.786253] Call Trace:
  [61666.786253]  __btrfs_drop_extents+0x5e3/0xaad [btrfs]
  [61666.786253]  ? time_hardirqs_on+0x9/0x14
  [61666.786253]  btrfs_log_changed_extents+0x294/0x4e0 [btrfs]
  [61666.786253]  ? release_extent_buffer+0x38/0xb4 [btrfs]
  [61666.786253]  btrfs_log_inode+0xb6e/0xcdc [btrfs]
  [61666.786253]  ? lock_acquire+0x131/0x1c5
  [61666.786253]  ? btrfs_log_inode_parent+0xee/0x659 [btrfs]
  [61666.786253]  ? arch_local_irq_save+0x9/0xc
  [61666.786253]  ? btrfs_log_inode_parent+0x1f5/0x659 [btrfs]
  [61666.786253]  btrfs_log_inode_parent+0x223/0x659 [btrfs]
  [61666.786253]  ? arch_local_irq_save+0x9/0xc
  [61666.786253]  ? lockref_get_not_zero+0x2c/0x34
  [61666.786253]  ? rcu_read_unlock+0x3e/0x5d
  [61666.786253]  btrfs_log_dentry_safe+0x60/0x7b [btrfs]
  [61666.786253]  btrfs_sync_file+0x317/0x42c [btrfs]
  [61666.786253]  vfs_fsync_range+0x8c/0x9e
  [61666.786253]  SyS_msync+0x13c/0x1c9
  [61666.786253]  entry_SYSCALL_64_fastpath+0x18/0xad

A sample of a corrupt log tree leaf with overlapping extents I got from
running btrfs/072:

  item 14 key (295 108 200704) itemoff 2599 itemsize 53
  extent data disk 

[PATCH 5.1 025/405] Btrfs: do not abort transaction at btrfs_update_root() after failure to COW path

2019-05-29 Thread Greg Kroah-Hartman
From: Filipe Manana 

commit 72bd2323ec87722c115a5906bc6a1b31d11e8f54 upstream.

Currently when we fail to COW a path at btrfs_update_root() we end up
always aborting the transaction. However all the current callers of
btrfs_update_root() are able to deal with errors returned from it, many do
end up aborting the transaction themselves (directly or not, such as the
transaction commit path), other BUG_ON() or just gracefully cancel whatever
they were doing.

When syncing the fsync log, we call btrfs_update_root() through
tree-log.c:update_log_root(), and if it returns an -ENOSPC error, the log
sync code does not abort the transaction, instead it gracefully handles
the error and returns -EAGAIN to the fsync handler, so that it falls back
to a transaction commit. Any other error different from -ENOSPC, makes the
log sync code abort the transaction.

So remove the transaction abort from btrfs_update_log() when we fail to
COW a path to update the root item, so that if an -ENOSPC failure happens
we avoid aborting the current transaction and have a chance of the fsync
succeeding after falling back to a transaction commit.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203413
Fixes: 79787eaab46121 ("btrfs: replace many BUG_ONs with proper error handling")
Cc: sta...@vger.kernel.org # 4.4+
Signed-off-by: Filipe Manana 
Reviewed-by: Anand Jain 
Signed-off-by: David Sterba 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/btrfs/root-tree.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/fs/btrfs/root-tree.c
+++ b/fs/btrfs/root-tree.c
@@ -132,10 +132,8 @@ int btrfs_update_root(struct btrfs_trans
return -ENOMEM;
 
ret = btrfs_search_slot(trans, root, key, path, 0, 1);
-   if (ret < 0) {
-   btrfs_abort_transaction(trans, ret);
+   if (ret < 0)
goto out;
-   }
 
if (ret != 0) {
btrfs_print_leaf(path->nodes[0]);




[PATCH 5.1 015/405] kvm: Check irqchip mode before assign irqfd

2019-05-29 Thread Greg Kroah-Hartman
From: Peter Xu 

commit 654f1f13ea56b92bacade8ce2725aea0457f91c0 upstream.

When assigning kvm irqfd we didn't check the irqchip mode but we allow
KVM_IRQFD to succeed with all the irqchip modes.  However it does not
make much sense to create irqfd even without the kernel chips.  Let's
provide a arch-dependent helper to check whether a specific irqfd is
allowed by the arch.  At least for x86, it should make sense to check:

- when irqchip mode is NONE, all irqfds should be disallowed, and,

- when irqchip mode is SPLIT, irqfds that are with resamplefd should
  be disallowed.

For either of the case, previously we'll silently ignore the irq or
the irq ack event if the irqchip mode is incorrect.  However that can
cause misterious guest behaviors and it can be hard to triage.  Let's
fail KVM_IRQFD even earlier to detect these incorrect configurations.

CC: Paolo Bonzini 
CC: Radim Krčmář 
CC: Alex Williamson 
CC: Eduardo Habkost 
Signed-off-by: Peter Xu 
Cc: sta...@vger.kernel.org
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kvm/irq.c |7 +++
 arch/x86/kvm/irq.h |1 +
 virt/kvm/eventfd.c |9 +
 3 files changed, 17 insertions(+)

--- a/arch/x86/kvm/irq.c
+++ b/arch/x86/kvm/irq.c
@@ -172,3 +172,10 @@ void __kvm_migrate_timers(struct kvm_vcp
__kvm_migrate_apic_timer(vcpu);
__kvm_migrate_pit_timer(vcpu);
 }
+
+bool kvm_arch_irqfd_allowed(struct kvm *kvm, struct kvm_irqfd *args)
+{
+   bool resample = args->flags & KVM_IRQFD_FLAG_RESAMPLE;
+
+   return resample ? irqchip_kernel(kvm) : irqchip_in_kernel(kvm);
+}
--- a/arch/x86/kvm/irq.h
+++ b/arch/x86/kvm/irq.h
@@ -114,6 +114,7 @@ static inline int irqchip_in_kernel(stru
return mode != KVM_IRQCHIP_NONE;
 }
 
+bool kvm_arch_irqfd_allowed(struct kvm *kvm, struct kvm_irqfd *args);
 void kvm_inject_pending_timer_irqs(struct kvm_vcpu *vcpu);
 void kvm_inject_apic_timer_irqs(struct kvm_vcpu *vcpu);
 void kvm_apic_nmi_wd_deliver(struct kvm_vcpu *vcpu);
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -44,6 +44,12 @@
 
 static struct workqueue_struct *irqfd_cleanup_wq;
 
+bool __attribute__((weak))
+kvm_arch_irqfd_allowed(struct kvm *kvm, struct kvm_irqfd *args)
+{
+   return true;
+}
+
 static void
 irqfd_inject(struct work_struct *work)
 {
@@ -297,6 +303,9 @@ kvm_irqfd_assign(struct kvm *kvm, struct
if (!kvm_arch_intc_initialized(kvm))
return -EAGAIN;
 
+   if (!kvm_arch_irqfd_allowed(kvm, args))
+   return -EINVAL;
+
irqfd = kzalloc(sizeof(*irqfd), GFP_KERNEL_ACCOUNT);
if (!irqfd)
return -ENOMEM;




[PATCH 5.1 003/405] ext4: wait for outstanding dio during truncate in nojournal mode

2019-05-29 Thread Greg Kroah-Hartman
From: Jan Kara 

commit 82a25b027ca48d7ef197295846b352345853dfa8 upstream.

We didn't wait for outstanding direct IO during truncate in nojournal
mode (as we skip orphan handling in that case). This can lead to fs
corruption or stale data exposure if truncate ends up freeing blocks
and these get reallocated before direct IO finishes. Fix the condition
determining whether the wait is necessary.

CC: sta...@vger.kernel.org
Fixes: 1c9114f9c0f1 ("ext4: serialize unlocked dio reads with truncate")
Reviewed-by: Ira Weiny 
Signed-off-by: Jan Kara 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ext4/inode.c |   21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5624,20 +5624,17 @@ int ext4_setattr(struct dentry *dentry,
goto err_out;
}
}
-   if (!shrink)
+   if (!shrink) {
pagecache_isize_extended(inode, oldsize, inode->i_size);
-
-   /*
-* Blocks are going to be removed from the inode. Wait
-* for dio in flight.  Temporarily disable
-* dioread_nolock to prevent livelock.
-*/
-   if (orphan) {
-   if (!ext4_should_journal_data(inode)) {
-   inode_dio_wait(inode);
-   } else
-   ext4_wait_for_tail_page_commit(inode);
+   } else {
+   /*
+* Blocks are going to be removed from the inode. Wait
+* for dio in flight.
+*/
+   inode_dio_wait(inode);
}
+   if (orphan && ext4_should_journal_data(inode))
+   ext4_wait_for_tail_page_commit(inode);
down_write(_I(inode)->i_mmap_sem);
 
rc = ext4_break_layouts(inode);




[PATCH 5.1 029/405] btrfs: sysfs: dont leak memory when failing add fsid

2019-05-29 Thread Greg Kroah-Hartman
From: Tobin C. Harding 

commit e32773357d5cc271b1d23550b3ed026eb5c2a468 upstream.

A failed call to kobject_init_and_add() must be followed by a call to
kobject_put().  Currently in the error path when adding fs_devices we
are missing this call.  This could be fixed by calling
btrfs_sysfs_remove_fsid() if btrfs_sysfs_add_fsid() returns an error or
by adding a call to kobject_put() directly in btrfs_sysfs_add_fsid().
Here we choose the second option because it prevents the slightly
unusual error path handling requirements of kobject from leaking out
into btrfs functions.

Add a call to kobject_put() in the error path of kobject_add_and_init().
This causes the release method to be called if kobject_init_and_add()
fails.  open_tree() is the function that calls btrfs_sysfs_add_fsid()
and the error code in this function is already written with the
assumption that the release method is called during the error path of
open_tree() (as seen by the call to btrfs_sysfs_remove_fsid() under the
fail_fsdev_sysfs label).

Cc: sta...@vger.kernel.org # v4.4+
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Tobin C. Harding 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/btrfs/sysfs.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/fs/btrfs/sysfs.c
+++ b/fs/btrfs/sysfs.c
@@ -825,7 +825,12 @@ int btrfs_sysfs_add_fsid(struct btrfs_fs
fs_devs->fsid_kobj.kset = btrfs_kset;
error = kobject_init_and_add(_devs->fsid_kobj,
_ktype, parent, "%pU", fs_devs->fsid);
-   return error;
+   if (error) {
+   kobject_put(_devs->fsid_kobj);
+   return error;
+   }
+
+   return 0;
 }
 
 int btrfs_sysfs_add_mounted(struct btrfs_fs_info *fs_info)




[PATCH 5.1 039/405] bpf: devmap: fix use-after-free Read in __dev_map_entry_free

2019-05-29 Thread Greg Kroah-Hartman
From: Eric Dumazet 

commit 2baae3545327632167c0180e9ca1d467416f1919 upstream.

synchronize_rcu() is fine when the rcu callbacks only need
to free memory (kfree_rcu() or direct kfree() call rcu call backs)

__dev_map_entry_free() is a bit more complex, so we need to make
sure that call queued __dev_map_entry_free() callbacks have completed.

sysbot report:

BUG: KASAN: use-after-free in dev_map_flush_old kernel/bpf/devmap.c:365
[inline]
BUG: KASAN: use-after-free in __dev_map_entry_free+0x2a8/0x300
kernel/bpf/devmap.c:379
Read of size 8 at addr 8801b8da38c8 by task ksoftirqd/1/18

CPU: 1 PID: 18 Comm: ksoftirqd/1 Not tainted 4.17.0+ #39
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
  print_address_description+0x6c/0x20b mm/kasan/report.c:256
  kasan_report_error mm/kasan/report.c:354 [inline]
  kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
  dev_map_flush_old kernel/bpf/devmap.c:365 [inline]
  __dev_map_entry_free+0x2a8/0x300 kernel/bpf/devmap.c:379
  __rcu_reclaim kernel/rcu/rcu.h:178 [inline]
  rcu_do_batch kernel/rcu/tree.c:2558 [inline]
  invoke_rcu_callbacks kernel/rcu/tree.c:2818 [inline]
  __rcu_process_callbacks kernel/rcu/tree.c:2785 [inline]
  rcu_process_callbacks+0xe9d/0x1760 kernel/rcu/tree.c:2802
  __do_softirq+0x2e0/0xaf5 kernel/softirq.c:284
  run_ksoftirqd+0x86/0x100 kernel/softirq.c:645
  smpboot_thread_fn+0x417/0x870 kernel/smpboot.c:164
  kthread+0x345/0x410 kernel/kthread.c:240
  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412

Allocated by task 6675:
  save_stack+0x43/0xd0 mm/kasan/kasan.c:448
  set_track mm/kasan/kasan.c:460 [inline]
  kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
  kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620
  kmalloc include/linux/slab.h:513 [inline]
  kzalloc include/linux/slab.h:706 [inline]
  dev_map_alloc+0x208/0x7f0 kernel/bpf/devmap.c:102
  find_and_alloc_map kernel/bpf/syscall.c:129 [inline]
  map_create+0x393/0x1010 kernel/bpf/syscall.c:453
  __do_sys_bpf kernel/bpf/syscall.c:2351 [inline]
  __se_sys_bpf kernel/bpf/syscall.c:2328 [inline]
  __x64_sys_bpf+0x303/0x510 kernel/bpf/syscall.c:2328
  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:290
  entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 26:
  save_stack+0x43/0xd0 mm/kasan/kasan.c:448
  set_track mm/kasan/kasan.c:460 [inline]
  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
  __cache_free mm/slab.c:3498 [inline]
  kfree+0xd9/0x260 mm/slab.c:3813
  dev_map_free+0x4fa/0x670 kernel/bpf/devmap.c:191
  bpf_map_free_deferred+0xba/0xf0 kernel/bpf/syscall.c:262
  process_one_work+0xc64/0x1b70 kernel/workqueue.c:2153
  worker_thread+0x181/0x13a0 kernel/workqueue.c:2296
  kthread+0x345/0x410 kernel/kthread.c:240
  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412

The buggy address belongs to the object at 8801b8da37c0
  which belongs to the cache kmalloc-512 of size 512
The buggy address is located 264 bytes inside of
  512-byte region [8801b8da37c0, 8801b8da39c0)
The buggy address belongs to the page:
page:ea0006e368c0 count:1 mapcount:0 mapping:8801da800940
index:0x8801b8da3540
flags: 0x2fffc000100(slab)
raw: 02fffc000100 ea0007217b88 ea0006e30cc8 8801da800940
raw: 8801b8da3540 8801b8da3040 00010004 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
  8801b8da3780: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
  8801b8da3800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> 8801b8da3880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
   ^
  8801b8da3900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  8801b8da3980: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc

Fixes: 546ac1ffb70d ("bpf: add devmap, a map for storing net device references")
Signed-off-by: Eric Dumazet 
Reported-by: syzbot+457d3e2ffbcf31aee...@syzkaller.appspotmail.com
Acked-by: Toke Høiland-Jørgensen 
Acked-by: Jesper Dangaard Brouer 
Signed-off-by: Daniel Borkmann 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/bpf/devmap.c |3 +++
 1 file changed, 3 insertions(+)

--- a/kernel/bpf/devmap.c
+++ b/kernel/bpf/devmap.c
@@ -164,6 +164,9 @@ static void dev_map_free(struct bpf_map
bpf_clear_redirect_map(map);
synchronize_rcu();
 
+   /* Make sure prior __dev_map_entry_free() have completed. */
+   rcu_barrier();
+
/* To ensure all pending flush operations have completed wait for flush
 * bitmap to indicate all flush_needed bits to be zero on _all_ cpus.
 * Because the above synchronize_rcu() ensures the map is disconnected




[PATCH 5.1 044/405] Revert "btrfs: Honour FITRIM range constraints during free space trim"

2019-05-29 Thread Greg Kroah-Hartman
From: David Sterba 

This reverts commit eb432217d775a90c061681c0dfa3c7abfba75123.

There is currently no corresponding patch in master due to additional
changes that would be significantly different from plain revert in the
respective stable branch.

The range argument was not handled correctly and could cause trim to
overlap allocated areas or reach beyond the end of the device. The
address space that fitrim normally operates on is in logical
coordinates, while the discards are done on the physical device extents.
This distinction cannot be made with the current ioctl interface and
caused the confusion.

The bug depends on the layout of block groups and does not always
happen. The whole-fs trim (run by default by the fstrim tool) is not
affected.

Signed-off-by: David Sterba 
Signed-off-by: Greg Kroah-Hartman 
---
 fs/btrfs/extent-tree.c |   25 ++---
 1 file changed, 6 insertions(+), 19 deletions(-)

--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -11314,9 +11314,9 @@ int btrfs_error_unpin_extent_range(struc
  * held back allocations.
  */
 static int btrfs_trim_free_extents(struct btrfs_device *device,
-  struct fstrim_range *range, u64 *trimmed)
+  u64 minlen, u64 *trimmed)
 {
-   u64 start = range->start, len = 0;
+   u64 start = 0, len = 0;
int ret;
 
*trimmed = 0;
@@ -11359,8 +11359,8 @@ static int btrfs_trim_free_extents(struc
if (!trans)
up_read(_info->commit_root_sem);
 
-   ret = find_free_dev_extent_start(trans, device, range->minlen,
-start, , );
+   ret = find_free_dev_extent_start(trans, device, minlen, start,
+, );
if (trans) {
up_read(_info->commit_root_sem);
btrfs_put_transaction(trans);
@@ -11373,16 +11373,6 @@ static int btrfs_trim_free_extents(struc
break;
}
 
-   /* If we are out of the passed range break */
-   if (start > range->start + range->len - 1) {
-   mutex_unlock(_info->chunk_mutex);
-   ret = 0;
-   break;
-   }
-
-   start = max(range->start, start);
-   len = min(range->len, len);
-
ret = btrfs_issue_discard(device->bdev, start, len, );
mutex_unlock(_info->chunk_mutex);
 
@@ -11392,10 +11382,6 @@ static int btrfs_trim_free_extents(struc
start += len;
*trimmed += bytes;
 
-   /* We've trimmed enough */
-   if (*trimmed >= range->len)
-   break;
-
if (fatal_signal_pending(current)) {
ret = -ERESTARTSYS;
break;
@@ -11479,7 +11465,8 @@ int btrfs_trim_fs(struct btrfs_fs_info *
mutex_lock(_info->fs_devices->device_list_mutex);
devices = _info->fs_devices->devices;
list_for_each_entry(device, devices, dev_list) {
-   ret = btrfs_trim_free_extents(device, range, _trimmed);
+   ret = btrfs_trim_free_extents(device, range->minlen,
+ _trimmed);
if (ret) {
dev_failed++;
dev_ret = ret;




[PATCH 5.1 023/405] btrfs: dont double unlock on error in btrfs_punch_hole

2019-05-29 Thread Greg Kroah-Hartman
From: Josef Bacik 

commit 8fca955057b9c58467d1b231e43f19c4cf26ae8c upstream.

If we have an error writing out a delalloc range in
btrfs_punch_hole_lock_range we'll unlock the inode and then goto
out_only_mutex, where we will again unlock the inode.  This is bad,
don't do this.

Fixes: f27451f22996 ("Btrfs: add support for fallocate's zero range operation")
CC: sta...@vger.kernel.org # 4.19+
Reviewed-by: Filipe Manana 
Signed-off-by: Josef Bacik 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/btrfs/file.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -2546,10 +2546,8 @@ static int btrfs_punch_hole(struct inode
 
ret = btrfs_punch_hole_lock_range(inode, lockstart, lockend,
  _state);
-   if (ret) {
-   inode_unlock(inode);
+   if (ret)
goto out_only_mutex;
-   }
 
path = btrfs_alloc_path();
if (!path) {




[PATCH 5.1 009/405] crypto: hash - fix incorrect HASH_MAX_DESCSIZE

2019-05-29 Thread Greg Kroah-Hartman
From: Eric Biggers 

commit e1354400b25da645c4764ed6844d12f1582c3b66 upstream.

The "hmac(sha3-224-generic)" algorithm has a descsize of 368 bytes,
which is greater than HASH_MAX_DESCSIZE (360) which is only enough for
sha3-224-generic.  The check in shash_prepare_alg() doesn't catch this
because the HMAC template doesn't set descsize on the algorithms, but
rather sets it on each individual HMAC transform.

This causes a stack buffer overflow when SHASH_DESC_ON_STACK() is used
with hmac(sha3-224-generic).

Fix it by increasing HASH_MAX_DESCSIZE to the real maximum.  Also add a
sanity check to hmac_init().

This was detected by the improved crypto self-tests in v5.2, by loading
the tcrypt module with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y enabled.  I
didn't notice this bug when I ran the self-tests by requesting the
algorithms via AF_ALG (i.e., not using tcrypt), probably because the
stack layout differs in the two cases and that made a difference here.

KASAN report:

BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:359 
[inline]
BUG: KASAN: stack-out-of-bounds in shash_default_import+0x52/0x80 
crypto/shash.c:223
Write of size 360 at addr 8880651defc8 by task insmod/3689

CPU: 2 PID: 3689 Comm: insmod Tainted: GE 
5.1.0-10741-g35c99ffa20edd #11
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 
04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x86/0xc5 lib/dump_stack.c:113
 print_address_description+0x7f/0x260 mm/kasan/report.c:188
 __kasan_report+0x144/0x187 mm/kasan/report.c:317
 kasan_report+0x12/0x20 mm/kasan/common.c:614
 check_memory_region_inline mm/kasan/generic.c:185 [inline]
 check_memory_region+0x137/0x190 mm/kasan/generic.c:191
 memcpy+0x37/0x50 mm/kasan/common.c:125
 memcpy include/linux/string.h:359 [inline]
 shash_default_import+0x52/0x80 crypto/shash.c:223
 crypto_shash_import include/crypto/hash.h:880 [inline]
 hmac_import+0x184/0x240 crypto/hmac.c:102
 hmac_init+0x96/0xc0 crypto/hmac.c:107
 crypto_shash_init include/crypto/hash.h:902 [inline]
 shash_digest_unaligned+0x9f/0xf0 crypto/shash.c:194
 crypto_shash_digest+0xe9/0x1b0 crypto/shash.c:211
 generate_random_hash_testvec.constprop.11+0x1ec/0x5b0 crypto/testmgr.c:1331
 test_hash_vs_generic_impl+0x3f7/0x5c0 crypto/testmgr.c:1420
 __alg_test_hash+0x26d/0x340 crypto/testmgr.c:1502
 alg_test_hash+0x22e/0x330 crypto/testmgr.c:1552
 alg_test.part.7+0x132/0x610 crypto/testmgr.c:4931
 alg_test+0x1f/0x40 crypto/testmgr.c:4952

Fixes: b68a7ec1e9a3 ("crypto: hash - Remove VLA usage")
Reported-by: Corentin Labbe 
Cc:  # v4.20+
Cc: Kees Cook 
Signed-off-by: Eric Biggers 
Reviewed-by: Kees Cook 
Tested-by: Corentin Labbe 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 

---
 crypto/hmac.c |2 ++
 include/crypto/hash.h |8 +++-
 2 files changed, 9 insertions(+), 1 deletion(-)

--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -168,6 +168,8 @@ static int hmac_init_tfm(struct crypto_t
 
parent->descsize = sizeof(struct shash_desc) +
   crypto_shash_descsize(hash);
+   if (WARN_ON(parent->descsize > HASH_MAX_DESCSIZE))
+   return -EINVAL;
 
ctx->hash = hash;
return 0;
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -152,7 +152,13 @@ struct shash_desc {
 };
 
 #define HASH_MAX_DIGESTSIZE 64
-#define HASH_MAX_DESCSIZE  360
+
+/*
+ * Worst case is hmac(sha3-224-generic).  Its context is a nested 'shash_desc'
+ * containing a 'struct sha3_state'.
+ */
+#define HASH_MAX_DESCSIZE  (sizeof(struct shash_desc) + 360)
+
 #define HASH_MAX_STATESIZE 512
 
 #define SHASH_DESC_ON_STACK(shash, ctx)  \




[PATCH 5.1 032/405] ovl: relax WARN_ON() for overlapping layers use case

2019-05-29 Thread Greg Kroah-Hartman
From: Amir Goldstein 

commit acf3062a7e1ccf67c6f7e7c28671a6708fde63b0 upstream.

This nasty little syzbot repro:
https://syzkaller.appspot.com/x/repro.syz?x=12c7a94f40

Creates overlay mounts where the same directory is both in upper and lower
layers. Simplified example:

  mkdir foo work
  mount -t overlay none foo -o"lowerdir=.,upperdir=foo,workdir=work"

The repro runs several threads in parallel that attempt to chdir into foo
and attempt to symlink/rename/exec/mkdir the file bar.

The repro hits a WARN_ON() I placed in ovl_instantiate(), which suggests
that an overlay inode already exists in cache and is hashed by the pointer
of the real upper dentry that ovl_create_real() has just created. At the
point of the WARN_ON(), for overlay dir inode lock is held and upper dir
inode lock, so at first, I did not see how this was possible.

On a closer look, I see that after ovl_create_real(), because of the
overlapping upper and lower layers, a lookup by another thread can find the
file foo/bar that was just created in upper layer, at overlay path
foo/foo/bar and hash the an overlay inode with the new real dentry as lower
dentry. This is possible because the overlay directory foo/foo is not
locked and the upper dentry foo/bar is in dcache, so ovl_lookup() can find
it without taking upper dir inode shared lock.

Overlapping layers is considered a wrong setup which would result in
unexpected behavior, but it shouldn't crash the kernel and it shouldn't
trigger WARN_ON() either, so relax this WARN_ON() and leave a pr_warn()
instead to cover all cases of failure to get an overlay inode.

The error returned from failure to insert new inode to cache with
inode_insert5() was changed to -EEXIST, to distinguish from the error
-ENOMEM returned on failure to get/allocate inode with iget5_locked().

Reported-by: syzbot+9c69c282adc4edd2b...@syzkaller.appspotmail.com
Fixes: 01b39dcc9568 ("ovl: use inode_insert5() to hash a newly...")
Signed-off-by: Amir Goldstein 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/overlayfs/dir.c   |2 +-
 fs/overlayfs/inode.c |3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -260,7 +260,7 @@ static int ovl_instantiate(struct dentry
 * hashed directory inode aliases.
 */
inode = ovl_get_inode(dentry->d_sb, );
-   if (WARN_ON(IS_ERR(inode)))
+   if (IS_ERR(inode))
return PTR_ERR(inode);
} else {
WARN_ON(ovl_inode_real(inode) != d_inode(newdentry));
--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
@@ -832,7 +832,7 @@ struct inode *ovl_get_inode(struct super
int fsid = bylower ? oip->lowerpath->layer->fsid : 0;
bool is_dir, metacopy = false;
unsigned long ino = 0;
-   int err = -ENOMEM;
+   int err = oip->newinode ? -EEXIST : -ENOMEM;
 
if (!realinode)
realinode = d_inode(lowerdentry);
@@ -917,6 +917,7 @@ out:
return inode;
 
 out_err:
+   pr_warn_ratelimited("overlayfs: failed to get inode (%i)\n", err);
inode = ERR_PTR(err);
goto out;
 }




[PATCH 5.1 005/405] x86/kvm/pmu: Set AMDs virt PMU version to 1

2019-05-29 Thread Greg Kroah-Hartman
From: Borislav Petkov 

commit a80c4ec10ed9632c44c829452dc40a0443ff4e85 upstream.

After commit:

  672ff6cff80c ("KVM: x86: Raise #GP when guest vCPU do not support PMU")

my AMD guests started #GPing like this:

  general protection fault:  [#1] PREEMPT SMP
  CPU: 1 PID: 4355 Comm: bash Not tainted 5.1.0-rc6+ #3
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 
04/01/2014
  RIP: 0010:x86_perf_event_update+0x3b/0xa0

with Code: pointing to RDPMC. It is RDPMC because the guest has the
hardware watchdog CONFIG_HARDLOCKUP_DETECTOR_PERF enabled which uses
perf. Instrumenting kvm_pmu_rdpmc() some, showed that it fails due to:

  if (!pmu->version)
return 1;

which the above commit added. Since AMD's PMU leaves the version at 0,
that causes the #GP injection into the guest.

Set pmu->version arbitrarily to 1 and move it above the non-applicable
struct kvm_pmu members.

Signed-off-by: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Janakarajan Natarajan 
Cc: k...@vger.kernel.org
Cc: Liran Alon 
Cc: Mihai Carabas 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: "Radim Krčmář" 
Cc: Thomas Gleixner 
Cc: Tom Lendacky 
Cc: x...@kernel.org
Cc: sta...@vger.kernel.org
Fixes: 672ff6cff80c ("KVM: x86: Raise #GP when guest vCPU do not support PMU")
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kvm/pmu_amd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kvm/pmu_amd.c
+++ b/arch/x86/kvm/pmu_amd.c
@@ -269,10 +269,10 @@ static void amd_pmu_refresh(struct kvm_v
 
pmu->counter_bitmask[KVM_PMC_GP] = ((u64)1 << 48) - 1;
pmu->reserved_bits = 0x0020ull;
+   pmu->version = 1;
/* not applicable to AMD; but clean them to prevent any fall out */
pmu->counter_bitmask[KVM_PMC_FIXED] = 0;
pmu->nr_arch_fixed_counters = 0;
-   pmu->version = 0;
pmu->global_status = 0;
 }
 




[PATCH 5.1 038/405] ssb: Fix possible NULL pointer dereference in ssb_host_pcmcia_exit

2019-05-29 Thread Greg Kroah-Hartman
From: YueHaibing 

commit b2c01aab9646ed8ffb7c549afe55d5349c482425 upstream.

Syzkaller report this:

kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN PTI
CPU: 0 PID: 4492 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 
04/01/2014
RIP: 0010:sysfs_remove_file_ns+0x27/0x70 fs/sysfs/file.c:468
Code: 00 00 00 41 54 55 48 89 fd 53 49 89 d4 48 89 f3 e8 ee 76 9c ff 48 8d 7d 
30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 2d 48 89 
da 48 b8 00 00 00 00 00 fc ff df 48 8b 6d
RSP: 0018:8881e9d9fc00 EFLAGS: 00010206
RAX: dc00 RBX: 900367e0 RCX: 81a95952
RDX: 0006 RSI: c90001405000 RDI: 0030
RBP:  R08: fbfff1fa22ed R09: fbfff1fa22ed
R10: 0001 R11: fbfff1fa22ec R12: 
R13: c1abdac0 R14: 11103d3b3f8b R15: 
FS:  7fe409dc1700() GS:8881f120() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 001b2d721000 CR3: 0001e98b6005 CR4: 007606f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
PKRU: 5554
Call Trace:
 sysfs_remove_file include/linux/sysfs.h:519 [inline]
 driver_remove_file+0x40/0x50 drivers/base/driver.c:122
 pcmcia_remove_newid_file drivers/pcmcia/ds.c:163 [inline]
 pcmcia_unregister_driver+0x7d/0x2b0 drivers/pcmcia/ds.c:209
 ssb_modexit+0xa/0x1b [ssb]
 __do_sys_delete_module kernel/module.c:1018 [inline]
 __se_sys_delete_module kernel/module.c:961 [inline]
 __x64_sys_delete_module+0x3dc/0x5e0 kernel/module.c:961
 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462e99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 
c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:7fe409dc0c58 EFLAGS: 0246 ORIG_RAX: 00b0
RAX: ffda RBX: 0073bf00 RCX: 00462e99
RDX:  RSI:  RDI: 20c0
RBP: 0002 R08:  R09: 
R10:  R11: 0246 R12: 7fe409dc16bc
R13: 004bccaa R14: 006f6bc8 R15: 
Modules linked in: ssb(-) 3c59x nvme_core macvlan tap pata_hpt3x3 rt2x00pci 
null_blk tsc40 pm_notifier_error_inject notifier_error_inject mdio cdc_wdm 
nf_reject_ipv4 ath9k_common ath9k_hw ath pppox ppp_generic slhc ehci_platform 
wl12xx wlcore tps6507x_ts ioc4 nf_synproxy_core ide_gd_mod ax25 can_dev iwlwifi 
can_raw atm tm2_touchkey can_gw can sundance adp5588_keys rt2800mmio rt2800lib 
rt2x00mmio rt2x00lib eeprom_93cx6 pn533 lru_cache elants_i2c ip_set nfnetlink 
gameport tipc hampshire nhc_ipv6 nhc_hop nhc_udp nhc_fragment nhc_routing 
nhc_mobility nhc_dest 6lowpan silead brcmutil nfc mt76_usb mt76 mac80211 
iptable_security iptable_raw iptable_mangle iptable_nat nf_nat_ipv4 nf_nat 
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti 
ip_gre sit hsr veth vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon vcan 
bridge stp llc ip6_gre ip6_tunnel tunnel6 tun joydev mousedev serio_raw 
ide_pci_generic piix floppy ide_core sch_fq_codel ip_tables x_tables ipv6
 [last unloaded: 3c59x]
Dumping ftrace buffer:
   (ftrace buffer empty)
---[ end trace 3913cbf8011e1c05 ]---

In ssb_modinit, it does not fail SSB init when ssb_host_pcmcia_init failed,
however in ssb_modexit, ssb_host_pcmcia_exit calls pcmcia_unregister_driver
unconditionally, which may tigger a NULL pointer dereference issue as above.

Reported-by: Hulk Robot 
Fixes: 399500da18f7 ("ssb: pick PCMCIA host code support from b43 driver")
Signed-off-by: YueHaibing 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/ssb/bridge_pcmcia_80211.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/ssb/bridge_pcmcia_80211.c
+++ b/drivers/ssb/bridge_pcmcia_80211.c
@@ -113,16 +113,21 @@ static struct pcmcia_driver ssb_host_pcm
.resume = ssb_host_pcmcia_resume,
 };
 
+static int pcmcia_init_failed;
+
 /*
  * These are not module init/exit functions!
  * The module_pcmcia_driver() helper cannot be used here.
  */
 int ssb_host_pcmcia_init(void)
 {
-   return pcmcia_register_driver(_host_pcmcia_driver);
+   pcmcia_init_failed = pcmcia_register_driver(_host_pcmcia_driver);
+
+   return pcmcia_init_failed;
 }
 
 void ssb_host_pcmcia_exit(void)
 {
-   pcmcia_unregister_driver(_host_pcmcia_driver);
+   if (!pcmcia_init_failed)
+   pcmcia_unregister_driver(_host_pcmcia_driver);
 }




[PATCH 5.1 030/405] fbdev: fix divide error in fb_var_to_videomode

2019-05-29 Thread Greg Kroah-Hartman
From: Shile Zhang 

commit cf84807f6dd0be5214378e66460cfc9187f532f9 upstream.

To fix following divide-by-zero error found by Syzkaller:

  divide error:  [#1] SMP PTI
  CPU: 7 PID: 8447 Comm: test Kdump: loaded Not tainted 4.19.24-8.al7.x86_64 #1
  Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 
rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
  RIP: 0010:fb_var_to_videomode+0xae/0xc0
  Code: 04 44 03 46 78 03 4e 7c 44 03 46 68 03 4e 70 89 ce d1 ee 69 c0 e8 03 00 
00 f6 c2 01 0f 45 ce 83 e2 02 8d 34 09 0f 45 ce 31 d2 <41> f7 f0 31 d2 f7 f1 89 
47 08 f3 c3 66 0f 1f 44 00 00 0f 1f 44 00
  RSP: 0018:b7e189347bf0 EFLAGS: 00010246
  RAX: e1692410 RBX: b7e189347d60 RCX: 
  RDX:  RSI:  RDI: b7e189347c10
  RBP: 99972a091c00 R08:  R09: 
  R10:  R11:  R12: 0100
  R13: 0001 R14: 7ffd66baf6d0 R15: 
  FS:  7f2054d11740() GS:99972fbc() knlGS:
  CS:  0010 DS:  ES:  CR0: 80050033
  CR2: 7f205481fd20 CR3: 0004288a0001 CR4: 001606a0
  Call Trace:
   fb_set_var+0x257/0x390
   ? lookup_fast+0xbb/0x2b0
   ? fb_open+0xc0/0x140
   ? chrdev_open+0xa6/0x1a0
   do_fb_ioctl+0x445/0x5a0
   do_vfs_ioctl+0x92/0x5f0
   ? __alloc_fd+0x3d/0x160
   ksys_ioctl+0x60/0x90
   __x64_sys_ioctl+0x16/0x20
   do_syscall_64+0x5b/0x190
   entry_SYSCALL_64_after_hwframe+0x44/0xa9
  RIP: 0033:0x7f20548258d7
  Code: 44 00 00 48 8b 05 b9 15 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff 
c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 
c3 48 8b 0d 89 15 2d 00 f7 d8 64 89 01 48

It can be triggered easily with following test code:

  #include 
  #include 
  #include 
  int main(void)
  {
  struct fb_var_screeninfo var = {.activate = 0x100, .pixclock = 60};
  int fd = open("/dev/fb0", O_RDWR);
  if (fd < 0)
  return 1;

  if (ioctl(fd, FBIOPUT_VSCREENINFO, ))
  return 1;

  return 0;
  }

Signed-off-by: Shile Zhang 
Cc: Fredrik Noring 
Cc: Daniel Vetter 
Reviewed-by: Mukesh Ojha 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/video/fbdev/core/modedb.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -935,6 +935,9 @@ void fb_var_to_videomode(struct fb_video
if (var->vmode & FB_VMODE_DOUBLE)
vtotal *= 2;
 
+   if (!htotal || !vtotal)
+   return;
+
hfreq = pixclock/htotal;
mode->refresh = hfreq/vtotal;
 }




[PATCH 5.1 031/405] arm64: errata: Add workaround for Cortex-A76 erratum #1463225

2019-05-29 Thread Greg Kroah-Hartman
From: Will Deacon 

commit 969f5ea627570e91c9d54403287ee3ed657f58fe upstream.

Revisions of the Cortex-A76 CPU prior to r4p0 are affected by an erratum
that can prevent interrupts from being taken when single-stepping.

This patch implements a software workaround to prevent userspace from
effectively being able to disable interrupts.

Cc: 
Cc: Marc Zyngier 
Cc: Catalin Marinas 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman 


---
 Documentation/arm64/silicon-errata.txt |1 
 arch/arm64/Kconfig |   18 
 arch/arm64/include/asm/cpucaps.h   |3 +-
 arch/arm64/kernel/cpu_errata.c |   24 +
 arch/arm64/kernel/syscall.c|   31 +++
 arch/arm64/mm/fault.c  |   37 +++--
 6 files changed, 111 insertions(+), 3 deletions(-)

--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -61,6 +61,7 @@ stable kernels.
 | ARM| Cortex-A76  | #1188873| ARM64_ERRATUM_1188873   
|
 | ARM| Cortex-A76  | #1165522| ARM64_ERRATUM_1165522   
|
 | ARM| Cortex-A76  | #1286807| ARM64_ERRATUM_1286807   
|
+| ARM| Cortex-A76  | #1463225| ARM64_ERRATUM_1463225   
|
 | ARM| MMU-500 | #841119,#826419 | N/A 
|
 || | | 
|
 | Cavium | ThunderX ITS| #22375, #24313  | CAVIUM_ERRATUM_22375
|
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -517,6 +517,24 @@ config ARM64_ERRATUM_1286807
 
  If unsure, say Y.
 
+config ARM64_ERRATUM_1463225
+   bool "Cortex-A76: Software Step might prevent interrupt recognition"
+   default y
+   help
+ This option adds a workaround for Arm Cortex-A76 erratum 1463225.
+
+ On the affected Cortex-A76 cores (r0p0 to r3p1), software stepping
+ of a system call instruction (SVC) can prevent recognition of
+ subsequent interrupts when software stepping is disabled in the
+ exception handler of the system call and either kernel debugging
+ is enabled or VHE is in use.
+
+ Work around the erratum by triggering a dummy step exception
+ when handling a system call from a task that is being stepped
+ in a VHE configuration of the kernel.
+
+ If unsure, say Y.
+
 config CAVIUM_ERRATUM_22375
bool "Cavium erratum 22375, 24313"
default y
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -61,7 +61,8 @@
 #define ARM64_HAS_GENERIC_AUTH_ARCH40
 #define ARM64_HAS_GENERIC_AUTH_IMP_DEF 41
 #define ARM64_HAS_IRQ_PRIO_MASKING 42
+#define ARM64_WORKAROUND_1463225   43
 
-#define ARM64_NCAPS43
+#define ARM64_NCAPS44
 
 #endif /* __ASM_CPUCAPS_H */
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -464,6 +464,22 @@ out_printmsg:
 }
 #endif /* CONFIG_ARM64_SSBD */
 
+#ifdef CONFIG_ARM64_ERRATUM_1463225
+DEFINE_PER_CPU(int, __in_cortex_a76_erratum_1463225_wa);
+
+static bool
+has_cortex_a76_erratum_1463225(const struct arm64_cpu_capabilities *entry,
+  int scope)
+{
+   u32 midr = read_cpuid_id();
+   /* Cortex-A76 r0p0 - r3p1 */
+   struct midr_range range = MIDR_RANGE(MIDR_CORTEX_A76, 0, 0, 3, 1);
+
+   WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible());
+   return is_midr_in_range(midr, ) && is_kernel_in_hyp_mode();
+}
+#endif
+
 static void __maybe_unused
 cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities *__unused)
 {
@@ -739,6 +755,14 @@ const struct arm64_cpu_capabilities arm6
ERRATA_MIDR_RANGE(MIDR_CORTEX_A76, 0, 0, 2, 0),
},
 #endif
+#ifdef CONFIG_ARM64_ERRATUM_1463225
+   {
+   .desc = "ARM erratum 1463225",
+   .capability = ARM64_WORKAROUND_1463225,
+   .type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,
+   .matches = has_cortex_a76_erratum_1463225,
+   },
+#endif
{
}
 };
--- a/arch/arm64/kernel/syscall.c
+++ b/arch/arm64/kernel/syscall.c
@@ -8,6 +8,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -60,6 +61,35 @@ static inline bool has_syscall_work(unsi
 int syscall_trace_enter(struct pt_regs *regs);
 void syscall_trace_exit(struct pt_regs *regs);
 
+#ifdef CONFIG_ARM64_ERRATUM_1463225
+DECLARE_PER_CPU(int, __in_cortex_a76_erratum_1463225_wa);
+
+static void cortex_a76_erratum_1463225_svc_handler(void)
+{
+   u32 reg, val;
+
+   if (!unlikely(test_thread_flag(TIF_SINGLESTEP)))
+   return;
+
+   if (!unlikely(this_cpu_has_cap(ARM64_WORKAROUND_1463225)))
+   return;
+
+   

[PATCH 5.1 054/405] tools/bpf: fix perf build error with uClibc (seen on ARC)

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit ca31ca8247e2d3807ff5fa1d1760616a2292001c ]

When build perf for ARC recently, there was a build failure due to lack
of __NR_bpf.

| Auto-detecting system features:
|
| ... get_cpuid: [ OFF ]
| ...   bpf: [ on  ]
|
| #  error __NR_bpf not defined. libbpf does not support your arch.
^
| bpf.c: In function 'sys_bpf':
| bpf.c:66:17: error: '__NR_bpf' undeclared (first use in this function)
|  return syscall(__NR_bpf, cmd, attr, size);
| ^~~~
| sys_bpf

Signed-off-by: Vineet Gupta 
Acked-by: Yonghong Song 
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Sasha Levin 
---
 tools/lib/bpf/bpf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 9cd015574e838..d82edadf75893 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -46,6 +46,8 @@
 #  define __NR_bpf 349
 # elif defined(__s390__)
 #  define __NR_bpf 351
+# elif defined(__arc__)
+#  define __NR_bpf 280
 # else
 #  error __NR_bpf not defined. libbpf does not support your arch.
 # endif
-- 
2.20.1





[PATCH 5.1 041/405] at76c50x-usb: Dont register led_trigger if usb_register_driver failed

2019-05-29 Thread Greg Kroah-Hartman
From: YueHaibing 

commit 09ac2694b0475f96be895848687ebcbba97eeecf upstream.

Syzkaller report this:

[ 1213.468581] BUG: unable to handle kernel paging request at fbfff83bf338
[ 1213.469530] #PF error: [normal kernel read fault]
[ 1213.469530] PGD 237fe4067 P4D 237fe4067 PUD 237e60067 PMD 1c868b067 PTE 0
[ 1213.473514] Oops:  [#1] SMP KASAN PTI
[ 1213.473514] CPU: 0 PID: 6321 Comm: syz-executor.0 Tainted: G C   
 5.1.0-rc3+ #8
[ 1213.473514] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1ubuntu1 04/01/2014
[ 1213.473514] RIP: 0010:strcmp+0x31/0xa0
[ 1213.473514] Code: 00 00 00 00 fc ff df 55 53 48 83 ec 08 eb 0a 84 db 48 89 
ef 74 5a 4c 89 e6 48 89 f8 48 89 fa 48 8d 6f 01 48 c1 e8 03 83 e2 07 <42> 0f b6 
04 28 38 d0 7f 04 84 c0 75 50 48 89 f0 48 89 f2 0f b6 5d
[ 1213.473514] RSP: 0018:8881f2b7f950 EFLAGS: 00010246
[ 1213.473514] RAX: 183bf338 RBX: 8881ea6f7240 RCX: 825350c6
[ 1213.473514] RDX:  RSI: c1ee19c0 RDI: c1df99c0
[ 1213.473514] RBP: c1df99c1 R08: 0001 R09: 0004
[ 1213.473514] R10:  R11: 8881de353f00 R12: 8881ee727900
[ 1213.473514] R13: dc00 R14: 0001 R15: c1eeaaf0
[ 1213.473514] FS:  7fa66fa01700() GS:8881f720() 
knlGS:
[ 1213.473514] CS:  0010 DS:  ES:  CR0: 80050033
[ 1213.473514] CR2: fbfff83bf338 CR3: 0001ebb9e005 CR4: 007606f0
[ 1213.473514] DR0:  DR1:  DR2: 
[ 1213.473514] DR3:  DR6: fffe0ff0 DR7: 0400
[ 1213.473514] PKRU: 5554
[ 1213.473514] Call Trace:
[ 1213.473514]  led_trigger_register+0x112/0x3f0
[ 1213.473514]  led_trigger_register_simple+0x7a/0x110
[ 1213.473514]  ? 0xc1c1
[ 1213.473514]  at76_mod_init+0x77/0x1000 [at76c50x_usb]
[ 1213.473514]  do_one_initcall+0xbc/0x47d
[ 1213.473514]  ? perf_trace_initcall_level+0x3a0/0x3a0
[ 1213.473514]  ? kasan_unpoison_shadow+0x30/0x40
[ 1213.473514]  ? kasan_unpoison_shadow+0x30/0x40
[ 1213.473514]  do_init_module+0x1b5/0x547
[ 1213.473514]  load_module+0x6405/0x8c10
[ 1213.473514]  ? module_frob_arch_sections+0x20/0x20
[ 1213.473514]  ? kernel_read_file+0x1e6/0x5d0
[ 1213.473514]  ? find_held_lock+0x32/0x1c0
[ 1213.473514]  ? cap_capable+0x1ae/0x210
[ 1213.473514]  ? __do_sys_finit_module+0x162/0x190
[ 1213.473514]  __do_sys_finit_module+0x162/0x190
[ 1213.473514]  ? __ia32_sys_init_module+0xa0/0xa0
[ 1213.473514]  ? __mutex_unlock_slowpath+0xdc/0x690
[ 1213.473514]  ? wait_for_completion+0x370/0x370
[ 1213.473514]  ? vfs_write+0x204/0x4a0
[ 1213.473514]  ? do_syscall_64+0x18/0x450
[ 1213.473514]  do_syscall_64+0x9f/0x450
[ 1213.473514]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 1213.473514] RIP: 0033:0x462e99
[ 1213.473514] Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
[ 1213.473514] RSP: 002b:7fa66fa00c58 EFLAGS: 0246 ORIG_RAX: 
0139
[ 1213.473514] RAX: ffda RBX: 0073bf00 RCX: 00462e99
[ 1213.473514] RDX:  RSI: 2300 RDI: 0003
[ 1213.473514] RBP: 7fa66fa00c70 R08:  R09: 
[ 1213.473514] R10:  R11: 0246 R12: 7fa66fa016bc
[ 1213.473514] R13: 004bcefa R14: 006f6fb0 R15: 0004

If usb_register failed, no need to call led_trigger_register_simple.

Reported-by: Hulk Robot 
Fixes: 1264b951463a ("at76c50x-usb: add driver")
Signed-off-by: YueHaibing 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/atmel/at76c50x-usb.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/atmel/at76c50x-usb.c
+++ b/drivers/net/wireless/atmel/at76c50x-usb.c
@@ -2585,8 +2585,8 @@ static int __init at76_mod_init(void)
if (result < 0)
printk(KERN_ERR DRIVER_NAME
   ": usb_register failed (status %d)\n", result);
-
-   led_trigger_register_simple("at76_usb-tx", _tx);
+   else
+   led_trigger_register_simple("at76_usb-tx", _tx);
return result;
 }
 




[PATCH 5.1 034/405] media: cpia2: Fix use-after-free in cpia2_exit

2019-05-29 Thread Greg Kroah-Hartman
From: YueHaibing 

commit dea37a97265588da604c6ba80160a287b72c7bfd upstream.

Syzkaller report this:

BUG: KASAN: use-after-free in sysfs_remove_file_ns+0x5f/0x70 fs/sysfs/file.c:468
Read of size 8 at addr 8881f59a6b70 by task syz-executor.0/8363

CPU: 0 PID: 8363 Comm: syz-executor.0 Not tainted 5.0.0-rc8+ #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 
04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xfa/0x1ce lib/dump_stack.c:113
 print_address_description+0x65/0x270 mm/kasan/report.c:187
 kasan_report+0x149/0x18d mm/kasan/report.c:317
 sysfs_remove_file_ns+0x5f/0x70 fs/sysfs/file.c:468
 sysfs_remove_file include/linux/sysfs.h:519 [inline]
 driver_remove_file+0x40/0x50 drivers/base/driver.c:122
 usb_remove_newid_files drivers/usb/core/driver.c:212 [inline]
 usb_deregister+0x12a/0x3b0 drivers/usb/core/driver.c:1005
 cpia2_exit+0xa/0x16 [cpia2]
 __do_sys_delete_module kernel/module.c:1018 [inline]
 __se_sys_delete_module kernel/module.c:961 [inline]
 __x64_sys_delete_module+0x3dc/0x5e0 kernel/module.c:961
 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462e99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 
c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:7f86f3754c58 EFLAGS: 0246 ORIG_RAX: 00b0
RAX: ffda RBX: 0073bf00 RCX: 00462e99
RDX:  RSI:  RDI: 2300
RBP: 0002 R08:  R09: 
R10:  R11: 0246 R12: 7f86f37556bc
R13: 004bcca9 R14: 006f6b48 R15: 

Allocated by task 8363:
 set_track mm/kasan/common.c:85 [inline]
 __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:495
 kmalloc include/linux/slab.h:545 [inline]
 kzalloc include/linux/slab.h:740 [inline]
 bus_add_driver+0xc0/0x610 drivers/base/bus.c:651
 driver_register+0x1bb/0x3f0 drivers/base/driver.c:170
 usb_register_driver+0x267/0x520 drivers/usb/core/driver.c:965
 0xc1b4817c
 do_one_initcall+0xfa/0x5ca init/main.c:887
 do_init_module+0x204/0x5f6 kernel/module.c:3460
 load_module+0x66b2/0x8570 kernel/module.c:3808
 __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 8363:
 set_track mm/kasan/common.c:85 [inline]
 __kasan_slab_free+0x130/0x180 mm/kasan/common.c:457
 slab_free_hook mm/slub.c:1430 [inline]
 slab_free_freelist_hook mm/slub.c:1457 [inline]
 slab_free mm/slub.c:3005 [inline]
 kfree+0xe1/0x270 mm/slub.c:3957
 kobject_cleanup lib/kobject.c:662 [inline]
 kobject_release lib/kobject.c:691 [inline]
 kref_put include/linux/kref.h:67 [inline]
 kobject_put+0x146/0x240 lib/kobject.c:708
 bus_remove_driver+0x10e/0x220 drivers/base/bus.c:732
 driver_unregister+0x6c/0xa0 drivers/base/driver.c:197
 usb_register_driver+0x341/0x520 drivers/usb/core/driver.c:980
 0xc1b4817c
 do_one_initcall+0xfa/0x5ca init/main.c:887
 do_init_module+0x204/0x5f6 kernel/module.c:3460
 load_module+0x66b2/0x8570 kernel/module.c:3808
 __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy address belongs to the object at 8881f59a6b40
 which belongs to the cache kmalloc-256 of size 256
The buggy address is located 48 bytes inside of
 256-byte region [8881f59a6b40, 8881f59a6c40)
The buggy address belongs to the page:
page:ea0007d66980 count:1 mapcount:0 mapping:8881f6c02e00 index:0x0
flags: 0x2fffc000200(slab)
raw: 02fffc000200 dead0100 dead0200 8881f6c02e00
raw:  800c000c 0001 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 8881f59a6a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 8881f59a6a80: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
>8881f59a6b00: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
 ^
 8881f59a6b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 8881f59a6c00: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc

cpia2_init does not check return value of cpia2_init, if it failed
in usb_register_driver, there is already cleanup using driver_unregister.
No need call cpia2_usb_cleanup on module exit.

Reported-by: Hulk Robot 
Signed-off-by: YueHaibing 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/usb/cpia2/cpia2_v4l.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/media/usb/cpia2/cpia2_v4l.c
+++ b/drivers/media/usb/cpia2/cpia2_v4l.c
@@ -1240,8 +1240,7 @@ static int __init 

[PATCH 5.1 062/405] blk-mq: grab .q_usage_counter when queuing request from plug code path

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit e87eb301bee183d82bb3d04bd71b6660889a2588 ]

Just like aio/io_uring, we need to grab 2 refcount for queuing one
request, one is for submission, another is for completion.

If the request isn't queued from plug code path, the refcount grabbed
in generic_make_request() serves for submission. In theroy, this
refcount should have been released after the sumission(async run queue)
is done. blk_freeze_queue() works with blk_sync_queue() together
for avoiding race between cleanup queue and IO submission, given async
run queue activities are canceled because hctx->run_work is scheduled with
the refcount held, so it is fine to not hold the refcount when
running the run queue work function for dispatch IO.

However, if request is staggered into plug list, and finally queued
from plug code path, the refcount in submission side is actually missed.
And we may start to run queue after queue is removed because the queue's
kobject refcount isn't guaranteed to be grabbed in flushing plug list
context, then kernel oops is triggered, see the following race:

blk_mq_flush_plug_list():
blk_mq_sched_insert_requests()
insert requests to sw queue or scheduler queue
blk_mq_run_hw_queue

Because of concurrent run queue, all requests inserted above may be
completed before calling the above blk_mq_run_hw_queue. Then queue can
be freed during the above blk_mq_run_hw_queue().

Fixes the issue by grab .q_usage_counter before calling
blk_mq_sched_insert_requests() in blk_mq_flush_plug_list(). This way is
safe because the queue is absolutely alive before inserting request.

Cc: Dongli Zhang 
Cc: James Smart 
Cc: linux-s...@vger.kernel.org,
Cc: Martin K . Petersen ,
Cc: Christoph Hellwig ,
Cc: James E . J . Bottomley ,
Reviewed-by: Bart Van Assche 
Tested-by: James Smart 
Signed-off-by: Ming Lei 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 block/blk-mq-sched.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
index aa6bc5c026438..c59babca6857a 100644
--- a/block/blk-mq-sched.c
+++ b/block/blk-mq-sched.c
@@ -413,6 +413,14 @@ void blk_mq_sched_insert_requests(struct blk_mq_hw_ctx 
*hctx,
  struct list_head *list, bool run_queue_async)
 {
struct elevator_queue *e;
+   struct request_queue *q = hctx->queue;
+
+   /*
+* blk_mq_sched_insert_requests() is called from flush plug
+* context only, and hold one usage counter to prevent queue
+* from being released.
+*/
+   percpu_ref_get(>q_usage_counter);
 
e = hctx->queue->elevator;
if (e && e->type->ops.insert_requests)
@@ -426,12 +434,14 @@ void blk_mq_sched_insert_requests(struct blk_mq_hw_ctx 
*hctx,
if (!hctx->dispatch_busy && !e && !run_queue_async) {
blk_mq_try_issue_list_directly(hctx, list);
if (list_empty(list))
-   return;
+   goto out;
}
blk_mq_insert_requests(hctx, ctx, list);
}
 
blk_mq_run_hw_queue(hctx, run_queue_async);
+ out:
+   percpu_ref_put(>q_usage_counter);
 }
 
 static void blk_mq_sched_free_tags(struct blk_mq_tag_set *set,
-- 
2.20.1





[PATCH 5.1 035/405] media: serial_ir: Fix use-after-free in serial_ir_init_module

2019-05-29 Thread Greg Kroah-Hartman
From: YueHaibing 

commit 56cd26b618855c9af48c8301aa6754ced8dd0beb upstream.

Syzkaller report this:

BUG: KASAN: use-after-free in sysfs_remove_file_ns+0x5f/0x70 fs/sysfs/file.c:468
Read of size 8 at addr 8881dc7ae030 by task syz-executor.0/6249

CPU: 1 PID: 6249 Comm: syz-executor.0 Not tainted 5.0.0-rc8+ #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 
04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xfa/0x1ce lib/dump_stack.c:113
 print_address_description+0x65/0x270 mm/kasan/report.c:187
 kasan_report+0x149/0x18d mm/kasan/report.c:317
 ? 0xc1728000
 sysfs_remove_file_ns+0x5f/0x70 fs/sysfs/file.c:468
 sysfs_remove_file include/linux/sysfs.h:519 [inline]
 driver_remove_file+0x40/0x50 drivers/base/driver.c:122
 remove_bind_files drivers/base/bus.c:585 [inline]
 bus_remove_driver+0x186/0x220 drivers/base/bus.c:725
 driver_unregister+0x6c/0xa0 drivers/base/driver.c:197
 serial_ir_init_module+0x169/0x1000 [serial_ir]
 do_one_initcall+0xfa/0x5ca init/main.c:887
 do_init_module+0x204/0x5f6 kernel/module.c:3460
 load_module+0x66b2/0x8570 kernel/module.c:3808
 __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462e99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 
c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:7f9450132c58 EFLAGS: 0246 ORIG_RAX: 0139
RAX: ffda RBX: 0073bf00 RCX: 00462e99
RDX:  RSI: 2100 RDI: 0003
RBP: 7f9450132c70 R08:  R09: 
R10:  R11: 0246 R12: 7f94501336bc
R13: 004bcefa R14: 006f6fb0 R15: 0004

Allocated by task 6249:
 set_track mm/kasan/common.c:85 [inline]
 __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:495
 kmalloc include/linux/slab.h:545 [inline]
 kzalloc include/linux/slab.h:740 [inline]
 bus_add_driver+0xc0/0x610 drivers/base/bus.c:651
 driver_register+0x1bb/0x3f0 drivers/base/driver.c:170
 serial_ir_init_module+0xe8/0x1000 [serial_ir]
 do_one_initcall+0xfa/0x5ca init/main.c:887
 do_init_module+0x204/0x5f6 kernel/module.c:3460
 load_module+0x66b2/0x8570 kernel/module.c:3808
 __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 6249:
 set_track mm/kasan/common.c:85 [inline]
 __kasan_slab_free+0x130/0x180 mm/kasan/common.c:457
 slab_free_hook mm/slub.c:1430 [inline]
 slab_free_freelist_hook mm/slub.c:1457 [inline]
 slab_free mm/slub.c:3005 [inline]
 kfree+0xe1/0x270 mm/slub.c:3957
 kobject_cleanup lib/kobject.c:662 [inline]
 kobject_release lib/kobject.c:691 [inline]
 kref_put include/linux/kref.h:67 [inline]
 kobject_put+0x146/0x240 lib/kobject.c:708
 bus_remove_driver+0x10e/0x220 drivers/base/bus.c:732
 driver_unregister+0x6c/0xa0 drivers/base/driver.c:197
 serial_ir_init_module+0x14c/0x1000 [serial_ir]
 do_one_initcall+0xfa/0x5ca init/main.c:887
 do_init_module+0x204/0x5f6 kernel/module.c:3460
 load_module+0x66b2/0x8570 kernel/module.c:3808
 __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy address belongs to the object at 8881dc7ae000
 which belongs to the cache kmalloc-256 of size 256
The buggy address is located 48 bytes inside of
 256-byte region [8881dc7ae000, 8881dc7ae100)
The buggy address belongs to the page:
page:ea000771eb80 count:1 mapcount:0 mapping:8881f6c02e00 index:0x0
flags: 0x2fffc000200(slab)
raw: 02fffc000200 ea0007d14800 00040002 8881f6c02e00
raw:  800c000c 0001 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 8881dc7adf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 8881dc7adf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>8881dc7ae000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ^
 8881dc7ae080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 8881dc7ae100: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00

There are already cleanup handlings in serial_ir_init error path,
no need to call serial_ir_exit do it again in serial_ir_init_module,
otherwise will trigger a use-after-free issue.

Fixes: fa5dc29c1fcc ("[media] lirc_serial: move out of staging and rename to 
serial_ir")

Reported-by: Hulk Robot 
Signed-off-by: YueHaibing 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/rc/serial_ir.c |9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

--- 

[PATCH 5.1 036/405] media: vb2: add waiting_in_dqbuf flag

2019-05-29 Thread Greg Kroah-Hartman
From: Hans Verkuil 

commit d65842f7126aa1a87fb44b7c9980c12630ed4f33 upstream.

Calling VIDIOC_DQBUF can release the core serialization lock pointed to
by vb2_queue->lock if it has to wait for a new buffer to arrive.

However, if userspace dup()ped the video device filehandle, then it is
possible to read or call DQBUF from two filehandles at the same time.

It is also possible to call REQBUFS from one filehandle while the other
is waiting for a buffer. This will remove all the buffers and reallocate
new ones. Removing all the buffers isn't the problem here (that's already
handled correctly by DQBUF), but the reallocating part is: DQBUF isn't
aware that the buffers have changed.

This is fixed by setting a flag whenever the lock is released while waiting
for a buffer to arrive. And checking the flag where needed so we can return
-EBUSY.

Signed-off-by: Hans Verkuil 
Reported-by: Syzbot 
Reviewed-by: Tomasz Figa 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/common/videobuf2/videobuf2-core.c |   22 ++
 include/media/videobuf2-core.h  |1 +
 2 files changed, 23 insertions(+)

--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -672,6 +672,11 @@ int vb2_core_reqbufs(struct vb2_queue *q
return -EBUSY;
}
 
+   if (q->waiting_in_dqbuf && *count) {
+   dprintk(1, "another dup()ped fd is waiting for a buffer\n");
+   return -EBUSY;
+   }
+
if (*count == 0 || q->num_buffers != 0 ||
(q->memory != VB2_MEMORY_UNKNOWN && q->memory != memory)) {
/*
@@ -807,6 +812,10 @@ int vb2_core_create_bufs(struct vb2_queu
}
 
if (!q->num_buffers) {
+   if (q->waiting_in_dqbuf && *count) {
+   dprintk(1, "another dup()ped fd is waiting for a 
buffer\n");
+   return -EBUSY;
+   }
memset(q->alloc_devs, 0, sizeof(q->alloc_devs));
q->memory = memory;
q->waiting_for_buffers = !q->is_output;
@@ -1659,6 +1668,11 @@ static int __vb2_wait_for_done_vb(struct
for (;;) {
int ret;
 
+   if (q->waiting_in_dqbuf) {
+   dprintk(1, "another dup()ped fd is waiting for a 
buffer\n");
+   return -EBUSY;
+   }
+
if (!q->streaming) {
dprintk(1, "streaming off, will not wait for 
buffers\n");
return -EINVAL;
@@ -1686,6 +1700,7 @@ static int __vb2_wait_for_done_vb(struct
return -EAGAIN;
}
 
+   q->waiting_in_dqbuf = 1;
/*
 * We are streaming and blocking, wait for another buffer to
 * become ready or for streamoff. Driver's lock is released to
@@ -1706,6 +1721,7 @@ static int __vb2_wait_for_done_vb(struct
 * the locks or return an error if one occurred.
 */
call_void_qop(q, wait_finish, q);
+   q->waiting_in_dqbuf = 0;
if (ret) {
dprintk(1, "sleep was interrupted\n");
return ret;
@@ -2585,6 +2601,12 @@ static size_t __vb2_perform_fileio(struc
if (!data)
return -EINVAL;
 
+   if (q->waiting_in_dqbuf) {
+   dprintk(3, "another dup()ped fd is %s\n",
+   read ? "reading" : "writing");
+   return -EBUSY;
+   }
+
/*
 * Initialize emulator on first call.
 */
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -595,6 +595,7 @@ struct vb2_queue {
unsigned intstart_streaming_called:1;
unsigned interror:1;
unsigned intwaiting_for_buffers:1;
+   unsigned intwaiting_in_dqbuf:1;
unsigned intis_multiplanar:1;
unsigned intis_output:1;
unsigned intcopy_timestamp:1;




[PATCH 5.1 060/405] ice: Preserve VLAN Rx stripping settings

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit e80e76db6c5bbc7a8f8512f3dc630a2170745b0b ]

When Tx insertion is set, we are not accounting for the state of Rx
stripping.  This causes Rx stripping to be enabled any time Tx
insertion is changed, even when it's supposed to be disabled.

Signed-off-by: Tony Nguyen 
Signed-off-by: Anirudh Venkataramanan 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/intel/ice/ice_lib.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c 
b/drivers/net/ethernet/intel/ice/ice_lib.c
index fa61203bee269..b710545cf7d1a 100644
--- a/drivers/net/ethernet/intel/ice/ice_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_lib.c
@@ -1848,6 +1848,10 @@ int ice_vsi_manage_vlan_insertion(struct ice_vsi *vsi)
 */
ctxt->info.vlan_flags = ICE_AQ_VSI_VLAN_MODE_ALL;
 
+   /* Preserve existing VLAN strip setting */
+   ctxt->info.vlan_flags |= (vsi->info.vlan_flags &
+ ICE_AQ_VSI_VLAN_EMOD_M);
+
ctxt->info.valid_sections = cpu_to_le16(ICE_AQ_VSI_PROP_VLAN_VALID);
 
status = ice_update_vsi(hw, vsi->idx, ctxt, NULL);
-- 
2.20.1





[PATCH 5.1 056/405] libbpf: fix invalid munmap call

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 0e6741f092979535d159d5a851f12c88bfb7cb9a ]

When unmapping the AF_XDP memory regions used for the rings, an
invalid address was passed to the munmap() calls. Instead of passing
the beginning of the memory region, the descriptor region was passed
to munmap.

When the userspace application tried to tear down an AF_XDP socket,
the operation failed and the application would still have a reference
to socket it wished to get rid of.

Reported-by: William Tu 
Fixes: 1cad07884239 ("libbpf: add support for using AF_XDP sockets")
Signed-off-by: Björn Töpel 
Tested-by: William Tu 
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Sasha Levin 
---
 tools/lib/bpf/xsk.c | 77 +++--
 1 file changed, 40 insertions(+), 37 deletions(-)

diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
index 8d0078b65486f..af5f310ecca1c 100644
--- a/tools/lib/bpf/xsk.c
+++ b/tools/lib/bpf/xsk.c
@@ -248,8 +248,7 @@ int xsk_umem__create(struct xsk_umem **umem_ptr, void 
*umem_area, __u64 size,
return 0;
 
 out_mmap:
-   munmap(umem->fill,
-  off.fr.desc + umem->config.fill_size * sizeof(__u64));
+   munmap(map, off.fr.desc + umem->config.fill_size * sizeof(__u64));
 out_socket:
close(umem->fd);
 out_umem_alloc:
@@ -523,11 +522,11 @@ int xsk_socket__create(struct xsk_socket **xsk_ptr, const 
char *ifname,
   struct xsk_ring_cons *rx, struct xsk_ring_prod *tx,
   const struct xsk_socket_config *usr_config)
 {
+   void *rx_map = NULL, *tx_map = NULL;
struct sockaddr_xdp sxdp = {};
struct xdp_mmap_offsets off;
struct xsk_socket *xsk;
socklen_t optlen;
-   void *map;
int err;
 
if (!umem || !xsk_ptr || !rx || !tx)
@@ -593,40 +592,40 @@ int xsk_socket__create(struct xsk_socket **xsk_ptr, const 
char *ifname,
}
 
if (rx) {
-   map = xsk_mmap(NULL, off.rx.desc +
-  xsk->config.rx_size * sizeof(struct xdp_desc),
-  PROT_READ | PROT_WRITE,
-  MAP_SHARED | MAP_POPULATE,
-  xsk->fd, XDP_PGOFF_RX_RING);
-   if (map == MAP_FAILED) {
+   rx_map = xsk_mmap(NULL, off.rx.desc +
+ xsk->config.rx_size * sizeof(struct xdp_desc),
+ PROT_READ | PROT_WRITE,
+ MAP_SHARED | MAP_POPULATE,
+ xsk->fd, XDP_PGOFF_RX_RING);
+   if (rx_map == MAP_FAILED) {
err = -errno;
goto out_socket;
}
 
rx->mask = xsk->config.rx_size - 1;
rx->size = xsk->config.rx_size;
-   rx->producer = map + off.rx.producer;
-   rx->consumer = map + off.rx.consumer;
-   rx->ring = map + off.rx.desc;
+   rx->producer = rx_map + off.rx.producer;
+   rx->consumer = rx_map + off.rx.consumer;
+   rx->ring = rx_map + off.rx.desc;
}
xsk->rx = rx;
 
if (tx) {
-   map = xsk_mmap(NULL, off.tx.desc +
-  xsk->config.tx_size * sizeof(struct xdp_desc),
-  PROT_READ | PROT_WRITE,
-  MAP_SHARED | MAP_POPULATE,
-  xsk->fd, XDP_PGOFF_TX_RING);
-   if (map == MAP_FAILED) {
+   tx_map = xsk_mmap(NULL, off.tx.desc +
+ xsk->config.tx_size * sizeof(struct xdp_desc),
+ PROT_READ | PROT_WRITE,
+ MAP_SHARED | MAP_POPULATE,
+ xsk->fd, XDP_PGOFF_TX_RING);
+   if (tx_map == MAP_FAILED) {
err = -errno;
goto out_mmap_rx;
}
 
tx->mask = xsk->config.tx_size - 1;
tx->size = xsk->config.tx_size;
-   tx->producer = map + off.tx.producer;
-   tx->consumer = map + off.tx.consumer;
-   tx->ring = map + off.tx.desc;
+   tx->producer = tx_map + off.tx.producer;
+   tx->consumer = tx_map + off.tx.consumer;
+   tx->ring = tx_map + off.tx.desc;
tx->cached_cons = xsk->config.tx_size;
}
xsk->tx = tx;
@@ -653,13 +652,11 @@ int xsk_socket__create(struct xsk_socket **xsk_ptr, const 
char *ifname,
 
 out_mmap_tx:
if (tx)
-   munmap(xsk->tx,
-  off.tx.desc +
+   munmap(tx_map, off.tx.desc +
   xsk->config.tx_size * sizeof(struct xdp_desc));
 out_mmap_rx:
if (rx)
-   munmap(xsk->rx,
-  off.rx.desc +
+   munmap(rx_map, off.rx.desc +
   xsk->config.rx_size 

[PATCH 5.1 058/405] bpftool: exclude bash-completion/bpftool from .gitignore pattern

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit a7d006714724de4334c5e3548701b33f7b12ca96 ]

tools/bpf/bpftool/.gitignore has the "bpftool" pattern, which is
intended to ignore the following build artifact:

  tools/bpf/bpftool/bpftool

However, the .gitignore entry is effective not only for the current
directory, but also for any sub-directories.

So, from the point of .gitignore grammar, the following check-in file
is also considered to be ignored:

  tools/bpf/bpftool/bash-completion/bpftool

As the manual gitignore(5) says "Files already tracked by Git are not
affected", this is not a problem as far as Git is concerned.

However, Git is not the only program that parses .gitignore because
.gitignore is useful to distinguish build artifacts from source files.

For example, tar(1) supports the --exclude-vcs-ignore option. As of
writing, this option does not work perfectly, but it intends to create
a tarball excluding files specified by .gitignore.

So, I believe it is better to fix this issue.

You can fix it by prefixing the pattern with a slash; the leading slash
means the specified pattern is relative to the current directory.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Quentin Monnet 
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Sasha Levin 
---
 tools/bpf/bpftool/.gitignore | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/bpf/bpftool/.gitignore b/tools/bpf/bpftool/.gitignore
index 67167e44b7266..8248b8dd89d4b 100644
--- a/tools/bpf/bpftool/.gitignore
+++ b/tools/bpf/bpftool/.gitignore
@@ -1,5 +1,5 @@
 *.d
-bpftool
+/bpftool
 bpftool*.8
 bpf-helpers.*
 FEATURE-DUMP.bpftool
-- 
2.20.1





[PATCH 5.1 037/405] media: vivid: use vfree() instead of kfree() for dev->bitmap_cap

2019-05-29 Thread Greg Kroah-Hartman
From: Alexander Potapenko 

commit dad7e270ba712ba1c99cd2d91018af607a06 upstream.

syzkaller reported crashes on kfree() called from
vivid_vid_cap_s_selection(). This looks like a simple typo, as
dev->bitmap_cap is allocated with vzalloc() throughout the file.

Fixes: ef834f7836ec0 ("[media] vivid: add the video capture and output
parts")

Signed-off-by: Alexander Potapenko 
Reported-by: Syzbot 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/platform/vivid/vivid-vid-cap.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/platform/vivid/vivid-vid-cap.c
+++ b/drivers/media/platform/vivid/vivid-vid-cap.c
@@ -1007,7 +1007,7 @@ int vivid_vid_cap_s_selection(struct fil
v4l2_rect_map_inside(>r, >fmt_cap_rect);
if (dev->bitmap_cap && (compose->width != s->r.width ||
compose->height != s->r.height)) {
-   kfree(dev->bitmap_cap);
+   vfree(dev->bitmap_cap);
dev->bitmap_cap = NULL;
}
*compose = s->r;




[PATCH 5.1 057/405] selftests/bpf: set RLIMIT_MEMLOCK properly for test_libbpf_open.c

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 6cea33701eb024bc6c920ab83940ee22afd29139 ]

Test test_libbpf.sh failed on my development server with failure
  -bash-4.4$ sudo ./test_libbpf.sh
  [0] libbpf: Error in bpf_object__probe_name():Operation not permitted(1).
  Couldn't load basic 'r0 = 0' BPF program.
  test_libbpf: failed at file test_l4lb.o
  selftests: test_libbpf [FAILED]
  -bash-4.4$

The reason is because my machine has 64KB locked memory by default which
is not enough for this program to get locked memory.
Similar to other bpf selftests, let us increase RLIMIT_MEMLOCK
to infinity, which fixed the issue.

Signed-off-by: Yonghong Song 
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Sasha Levin 
---
 tools/testing/selftests/bpf/test_libbpf_open.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/testing/selftests/bpf/test_libbpf_open.c 
b/tools/testing/selftests/bpf/test_libbpf_open.c
index 65cbd30704b5a..9e9db202d218a 100644
--- a/tools/testing/selftests/bpf/test_libbpf_open.c
+++ b/tools/testing/selftests/bpf/test_libbpf_open.c
@@ -11,6 +11,8 @@ static const char *__doc__ =
 #include 
 #include 
 
+#include "bpf_rlimit.h"
+
 static const struct option long_options[] = {
{"help",no_argument,NULL, 'h' },
{"debug",   no_argument,NULL, 'D' },
-- 
2.20.1





Re: [RFC PATCH v3] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver

2019-05-29 Thread Chris Chiu
On Thu, May 30, 2019 at 2:22 AM Larry Finger  wrote:
>
> On 5/29/19 12:03 AM, Chris Chiu wrote:
> > We have 3 laptops which connect the wifi by the same RTL8723BU.
> > The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
> > They have the same problem with the in-kernel rtl8xxxu driver, the
> > iperf (as a client to an ethernet-connected server) gets ~1Mbps.
> > Nevertheless, the signal strength is reported as around -40dBm,
> > which is quite good. From the wireshark capture, the tx rate for each
> > data and qos data packet is only 1Mbps. Compare to the driver from
> > https://github.com/lwfinger/rtl8723bu, the same iperf test gets ~12
> > Mbps or more. The signal strength is reported similarly around
> > -40dBm. That's why we want to improve.
>
> The driver at GitHub was written by Realtek. I only published it in a 
> prominent
> location, and fix it for kernel API changes. I would say "the Realtek driver 
> at
> https://...;, and every mention of "Larry's driver" should say "Realtek's
> driver". That attribution is more correct.

Thanks. I'll modify this in next revision.

> >
> > After reading the source code of the rtl8xxxu driver and Larry's, the
> > major difference is that Larry's driver has a watchdog which will keep
> > monitoring the signal quality and updating the rate mask just like the
> > rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
> > And this kind of watchdog also exists in rtlwifi driver of some specific
> > chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
> > the same member function named dm_watchdog and will invoke the
> > corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
> > mask.
> >
> > With this commit, the tx rate of each data and qos data packet will
> > be 39Mbps (MCS4) with the 0xF0 as the tx rate mask. The 20th bit
> > to 23th bit means MCS4 to MCS7. It means that the firmware still picks
> > the lowest rate from the rate mask and explains why the tx rate of
> > data and qos data is always lowest 1Mbps because the default rate mask
> > passed is always 0xFFF ranges from the basic CCK rate, OFDM rate,
> > and MCS rate. However, with Larry's driver, the tx rate observed from
> > wireshark under the same condition is almost 65Mbps or 72Mbps.
> >
> > I believe the firmware of RTL8723BU may need fix. And I think we
> > can still bring in the dm_watchdog as rtlwifi to improve from the
> > driver side. Please leave precious comments for my commits and
> > suggest what I can do better. Or suggest if there's any better idea
> > to fix this. Thanks.
> >
> > Signed-off-by: Chris Chiu 
>
> I have not tested this patch, but I plan to soon.
>
> Larry
>
>


[PATCH 5.1 064/405] net: ena: gcc 8: fix compilation warning

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit f913308879bc6ae437ce64d878c7b05643ddea44 ]

GCC 8 contains a number of new warnings as well as enhancements to existing
checkers. The warning - Wstringop-truncation - warns for calls to bounded
string manipulation functions such as strncat, strncpy, and stpncpy that
may either truncate the copied string or leave the destination unchanged.

In our case the destination string length (32 bytes) is much shorter than
the source string (64 bytes) which causes this warning to show up. In
general the destination has to be at least a byte larger than the length
of the source string with strncpy for this warning not to showup.

This can be easily fixed by using strlcpy instead which already does the
truncation to the string. Documentation for this function can be
found here:

https://elixir.bootlin.com/linux/latest/source/lib/string.c#L141

Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network 
Adapters (ENA)")
Signed-off-by: Sameeh Jubran 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/amazon/ena/ena_netdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c 
b/drivers/net/ethernet/amazon/ena/ena_netdev.c
index a6eacf2099c30..41c1c9acb3246 100644
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@ -2292,7 +2292,7 @@ static void ena_config_host_info(struct ena_com_dev 
*ena_dev,
host_info->bdf = (pdev->bus->number << 8) | pdev->devfn;
host_info->os_type = ENA_ADMIN_OS_LINUX;
host_info->kernel_ver = LINUX_VERSION_CODE;
-   strncpy(host_info->kernel_ver_str, utsname()->version,
+   strlcpy(host_info->kernel_ver_str, utsname()->version,
sizeof(host_info->kernel_ver_str) - 1);
host_info->os_dist = 0;
strncpy(host_info->os_dist_str, utsname()->release,
-- 
2.20.1





[PATCH 5.1 066/405] hv_netvsc: fix race that may miss tx queue wakeup

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 93aa4792c3908eac87ddd368ee0fe0564148232b ]

When the ring buffer is almost full due to RX completion messages, a
TX packet may reach the "low watermark" and cause the queue stopped.
If the TX completion arrives earlier than queue stopping, the wakeup
may be missed.

This patch moves the check for the last pending packet to cover both
EAGAIN and success cases, so the queue will be reliably waked up when
necessary.

Reported-and-tested-by: Stephan Klein 
Signed-off-by: Haiyang Zhang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/hyperv/netvsc.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index e0dce373cdd9d..3d4a166a49d58 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -875,12 +875,6 @@ static inline int netvsc_send_pkt(
} else if (ret == -EAGAIN) {
netif_tx_stop_queue(txq);
ndev_ctx->eth_stats.stop_queue++;
-   if (atomic_read(>queue_sends) < 1 &&
-   !net_device->tx_disable) {
-   netif_tx_wake_queue(txq);
-   ndev_ctx->eth_stats.wake_queue++;
-   ret = -ENOSPC;
-   }
} else {
netdev_err(ndev,
   "Unable to send packet pages %u len %u, ret %d\n",
@@ -888,6 +882,15 @@ static inline int netvsc_send_pkt(
   ret);
}
 
+   if (netif_tx_queue_stopped(txq) &&
+   atomic_read(>queue_sends) < 1 &&
+   !net_device->tx_disable) {
+   netif_tx_wake_queue(txq);
+   ndev_ctx->eth_stats.wake_queue++;
+   if (ret == -EAGAIN)
+   ret = -ENOSPC;
+   }
+
return ret;
 }
 
-- 
2.20.1





[PATCH 5.1 063/405] dmaengine: tegra210-dma: free dma controller in remove()

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit f030e419501cb95e961e9ed35c493b5d46a04eca ]

Following kernel panic is seen during DMA driver unload->load sequence
==
Unable to handle kernel paging request at virtual address ff8001198880
Internal error: Oops: 8607 [#1] PREEMPT SMP
CPU: 0 PID: 5907 Comm: HwBinder:4123_1 Tainted: G C 4.9.128-tegra-g065839f
Hardware name: galen (DT)
task: ffc3590d1a80 task.stack: ffc3d0678000
PC is at 0xff8001198880
LR is at of_dma_request_slave_channel+0xd8/0x1f8
pc : [] lr : [] pstate: 60400045
sp : ffc3d067b710
x29: ffc3d067b710 x28: 002f
x27: ff800949e000 x26: ff800949e750
x25: ff800949e000 x24: ffbefe817d84
x23: ff8009f77cb0 x22: 0028
x21: ffc3ffda49c8 x20: 0029
x19: 0001 x18: 
x17:  x16: ff80082b66a0
x15: ff8009e78250 x14: 000a
x13: 0038 x12: 0101010101010101
x11: 0030 x10: 0101010101010101
x9 : fffc x8 : 7f7f7f7f7f7f7f7f
x7 : 62ff726b6b64622c x6 : 8064
x5 : 6400 x4 : ffbefe817c44
x3 : ffc3ffda3e08 x2 : ff8001198880
x1 : ffc3d48323c0 x0 : ffc3d067b788

Process HwBinder:4123_1 (pid: 5907, stack limit = 0xffc3d0678028)
Call trace:
[] 0xff8001198880
[] dma_request_chan+0x50/0x1f0
[] dma_request_slave_channel+0x28/0x40
[] tegra_alt_pcm_open+0x114/0x170
[] soc_pcm_open+0x10c/0x878
[] snd_pcm_open_substream+0xc0/0x170
[] snd_pcm_open+0xc4/0x240
[] snd_pcm_playback_open+0x58/0x80
[] snd_open+0xb4/0x178
[] chrdev_open+0xb8/0x1d0
[] do_dentry_open+0x214/0x318
[] vfs_open+0x58/0x88
[] do_last+0x450/0xde0
[] path_openat+0xa8/0x368
[] do_filp_open+0x8c/0x110
[] do_sys_open+0x164/0x220
[] compat_SyS_openat+0x3c/0x50
[] el0_svc_naked+0x34/0x38
---[ end trace 67e6d544e65b5145 ]---
Kernel panic - not syncing: Fatal exception
==

In device probe(), of_dma_controller_register() registers DMA controller.
But when driver is removed, this is not freed. During driver reload this
results in data abort and kernel panic. Add of_dma_controller_free() in
driver remove path to fix the issue.

Fixes: f46b195799b5 ("dmaengine: tegra-adma: Add support for Tegra210 ADMA")
Signed-off-by: Sameer Pujar 
Reviewed-by: Jon Hunter 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/dma/tegra210-adma.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index 5ec0dd97b3971..9aa35a7f13692 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -787,6 +787,7 @@ static int tegra_adma_remove(struct platform_device *pdev)
struct tegra_adma *tdma = platform_get_drvdata(pdev);
int i;
 
+   of_dma_controller_free(pdev->dev.of_node);
dma_async_device_unregister(>dma_dev);
 
for (i = 0; i < tdma->nr_channels; ++i)
-- 
2.20.1





[PATCH 5.1 065/405] net: ena: fix: set freed objects to NULL to avoid failing future allocations

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 8ee8ee7fe87bf64738ab4e31be036a7165608b27 ]

In some cases when a queue related allocation fails, successful past
allocations are freed but the pointer that pointed to them is not
set to NULL. This is a problem for 2 reasons:
1. This is generally a bad practice since this pointer might be
accidentally accessed in the future.
2. Future allocations using the same pointer check if the pointer
is NULL and fail if it is not.

Fixed this by setting such pointers to NULL in the allocation of
queue related objects.

Also refactored the code of ena_setup_tx_resources() to goto-style
error handling to avoid code duplication of resource freeing.

Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network 
Adapters (ENA)")
Signed-off-by: Arthur Kiyanovski 
Signed-off-by: Sameeh Jubran 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/amazon/ena/ena_netdev.c | 25 
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c 
b/drivers/net/ethernet/amazon/ena/ena_netdev.c
index 41c1c9acb3246..9b03d7e404f83 100644
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@ -224,28 +224,23 @@ static int ena_setup_tx_resources(struct ena_adapter 
*adapter, int qid)
if (!tx_ring->tx_buffer_info) {
tx_ring->tx_buffer_info = vzalloc(size);
if (!tx_ring->tx_buffer_info)
-   return -ENOMEM;
+   goto err_tx_buffer_info;
}
 
size = sizeof(u16) * tx_ring->ring_size;
tx_ring->free_tx_ids = vzalloc_node(size, node);
if (!tx_ring->free_tx_ids) {
tx_ring->free_tx_ids = vzalloc(size);
-   if (!tx_ring->free_tx_ids) {
-   vfree(tx_ring->tx_buffer_info);
-   return -ENOMEM;
-   }
+   if (!tx_ring->free_tx_ids)
+   goto err_free_tx_ids;
}
 
size = tx_ring->tx_max_header_size;
tx_ring->push_buf_intermediate_buf = vzalloc_node(size, node);
if (!tx_ring->push_buf_intermediate_buf) {
tx_ring->push_buf_intermediate_buf = vzalloc(size);
-   if (!tx_ring->push_buf_intermediate_buf) {
-   vfree(tx_ring->tx_buffer_info);
-   vfree(tx_ring->free_tx_ids);
-   return -ENOMEM;
-   }
+   if (!tx_ring->push_buf_intermediate_buf)
+   goto err_push_buf_intermediate_buf;
}
 
/* Req id ring for TX out of order completions */
@@ -259,6 +254,15 @@ static int ena_setup_tx_resources(struct ena_adapter 
*adapter, int qid)
tx_ring->next_to_clean = 0;
tx_ring->cpu = ena_irq->cpu;
return 0;
+
+err_push_buf_intermediate_buf:
+   vfree(tx_ring->free_tx_ids);
+   tx_ring->free_tx_ids = NULL;
+err_free_tx_ids:
+   vfree(tx_ring->tx_buffer_info);
+   tx_ring->tx_buffer_info = NULL;
+err_tx_buffer_info:
+   return -ENOMEM;
 }
 
 /* ena_free_tx_resources - Free I/O Tx Resources per Queue
@@ -378,6 +382,7 @@ static int ena_setup_rx_resources(struct ena_adapter 
*adapter,
rx_ring->free_rx_ids = vzalloc(size);
if (!rx_ring->free_rx_ids) {
vfree(rx_ring->rx_buffer_info);
+   rx_ring->rx_buffer_info = NULL;
return -ENOMEM;
}
}
-- 
2.20.1





[PATCH 5.1 067/405] Bluetooth: Ignore CC events not matching the last HCI command

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit f80c5dad7b6467b884c445ffea45985793b4b2d0 ]

This commit makes the kernel not send the next queued HCI command until
a command complete arrives for the last HCI command sent to the
controller. This change avoids a problem with some buggy controllers
(seen on two SKUs of QCA9377) that send an extra command complete event
for the previous command after the kernel had already sent a new HCI
command to the controller.

The problem was reproduced when starting an active scanning procedure,
where an extra command complete event arrives for the LE_SET_RANDOM_ADDR
command. When this happends the kernel ends up not processing the
command complete for the following commmand, LE_SET_SCAN_PARAM, and
ultimately behaving as if a passive scanning procedure was being
performed, when in fact controller is performing an active scanning
procedure. This makes it impossible to discover BLE devices as no device
found events are sent to userspace.

This problem is reproducible on 100% of the attempts on the affected
controllers. The extra command complete event can be seen at timestamp
27.420131 on the btmon logs bellow.

Bluetooth monitor ver 5.50
= Note: Linux version 5.0.0+ (x86_64)  0.352340
= Note: Bluetooth subsystem version 2.22   0.352343
= New Index: 80:C5:F2:8F:87:84 (Primary,USB,hci0)   [hci0] 0.352344
= Open Index: 80:C5:F2:8F:87:84 [hci0] 0.352345
= Index Info: 80:C5:F2:8F:87:84 (Qualcomm)  [hci0] 0.352346
@ MGMT Open: bluetoothd (privileged) version 1.14 {0x0001} 0.352347
@ MGMT Open: btmon (privileged) version 1.14  {0x0002} 0.352366
@ MGMT Open: btmgmt (privileged) version 1.14{0x0003} 27.302164
@ MGMT Command: Start Discovery (0x0023) plen 1   {0x0003} [hci0] 27.302310
Address type: 0x06
  LE Public
  LE Random
< HCI Command: LE Set Random Address (0x08|0x0005) plen 6   #1 [hci0] 27.302496
Address: 15:60:F2:91:B2:24 (Non-Resolvable)
> HCI Event: Command Complete (0x0e) plen 4 #2 [hci0] 27.419117
  LE Set Random Address (0x08|0x0005) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7  #3 [hci0] 27.419244
Type: Active (0x01)
Interval: 11.250 msec (0x0012)
Window: 11.250 msec (0x0012)
Own address type: Random (0x01)
Filter policy: Accept all advertisement (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #4 [hci0] 27.420131
  LE Set Random Address (0x08|0x0005) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2  #5 [hci0] 27.420259
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #6 [hci0] 27.420969
  LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Success (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #7 [hci0] 27.421983
  LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
@ MGMT Event: Command Complete (0x0001) plen 4{0x0003} [hci0] 27.422059
  Start Discovery (0x0023) plen 1
Status: Success (0x00)
Address type: 0x06
  LE Public
  LE Random
@ MGMT Event: Discovering (0x0013) plen 2 {0x0003} [hci0] 27.422067
Address type: 0x06
  LE Public
  LE Random
Discovery: Enabled (0x01)
@ MGMT Event: Discovering (0x0013) plen 2 {0x0002} [hci0] 27.422067
Address type: 0x06
  LE Public
  LE Random
Discovery: Enabled (0x01)
@ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 27.422067
Address type: 0x06
  LE Public
  LE Random
Discovery: Enabled (0x01)

Signed-off-by: João Paulo Rechi Vita 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 include/net/bluetooth/hci.h |  1 +
 net/bluetooth/hci_core.c|  5 +
 net/bluetooth/hci_event.c   | 12 
 net/bluetooth/hci_request.c |  5 +
 net/bluetooth/hci_request.h |  1 +
 5 files changed, 24 insertions(+)

diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index fbba43e9bef5b..9a5330eed7944 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -282,6 +282,7 @@ enum {
HCI_FORCE_BREDR_SMP,
HCI_FORCE_STATIC_ADDR,
HCI_LL_RPA_RESOLUTION,
+   HCI_CMD_PENDING,
 
__HCI_NUM_FLAGS,
 };
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index d6b2540ba7f8b..f275c99056507 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -4383,6 +4383,9 @@ void hci_req_cmd_complete(struct hci_dev *hdev, u16 
opcode, u8 status,
return;
}
 
+   /* If we reach this point this event matches the last command sent */
+   

[PATCH 5.1 068/405] pinctrl: zte: fix leaked of_node references

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 02d15f0d80720545f1f4922a1550ea4aaad4e152 ]

The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.

Detected by coccinelle with the following warnings:
./drivers/pinctrl/zte/pinctrl-zx.c:415:2-8: ERROR: missing of_node_put; 
acquired a node pointer with refcount incremented on line 407, but without a 
corresponding object release within this function.
./drivers/pinctrl/zte/pinctrl-zx.c:422:2-8: ERROR: missing of_node_put; 
acquired a node pointer with refcount incremented on line 407, but without a 
corresponding object release within this function.
./drivers/pinctrl/zte/pinctrl-zx.c:436:2-8: ERROR: missing of_node_put; 
acquired a node pointer with refcount incremented on line 407, but without a 
corresponding object release within this function.
./drivers/pinctrl/zte/pinctrl-zx.c:444:2-8: ERROR: missing of_node_put; 
acquired a node pointer with refcount incremented on line 407, but without a 
corresponding object release within this function.
./drivers/pinctrl/zte/pinctrl-zx.c:448:1-7: ERROR: missing of_node_put; 
acquired a node pointer with refcount incremented on line 407, but without a 
corresponding object release within this function.

Signed-off-by: Wen Yang 
Cc: Linus Walleij 
Cc: Jun Nie 
Cc: Linus Walleij 
Cc: linux-g...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Shawn Guo 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
---
 drivers/pinctrl/zte/pinctrl-zx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/zte/pinctrl-zx.c b/drivers/pinctrl/zte/pinctrl-zx.c
index caa44dd2880a8..3cb69309912ba 100644
--- a/drivers/pinctrl/zte/pinctrl-zx.c
+++ b/drivers/pinctrl/zte/pinctrl-zx.c
@@ -411,6 +411,7 @@ int zx_pinctrl_init(struct platform_device *pdev,
}
 
zpctl->aux_base = of_iomap(np, 0);
+   of_node_put(np);
if (!zpctl->aux_base)
return -ENOMEM;
 
-- 
2.20.1





[PATCH 5.1 079/405] spi: pxa2xx: fix SCR (divisor) calculation

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 29f2133717c527f492933b0622a4aafe0b3cbe9e ]

Calculate the divisor for the SCR (Serial Clock Rate), avoiding
that the SSP transmission rate can be greater than the device rate.

When the division between the SSP clock and the device rate generates
a reminder, we have to increment by one the divisor.
In this way the resulting SSP clock will never be greater than the
device SPI max frequency.

For example, with:

 - ssp_clk  = 50 MHz
 - dev freq = 15 MHz

without this patch the SSP clock will be greater than 15 MHz:

 - 25 MHz for PXA25x_SSP and CE4100_SSP
 - 16,56 MHz for the others

Instead, with this patch, we have in both case an SSP clock of 12.5MHz,
so the max rate of the SPI device clock is respected.

Signed-off-by: Flavio Suligoi 
Reviewed-by: Jarkko Nikula 
Reviewed-by: Jarkko Nikula 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 drivers/spi/spi-pxa2xx.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index b6ddba833d021..d2076f2f468f0 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -884,10 +884,14 @@ static unsigned int ssp_get_clk_div(struct driver_data 
*drv_data, int rate)
 
rate = min_t(int, ssp_clk, rate);
 
+   /*
+* Calculate the divisor for the SCR (Serial Clock Rate), avoiding
+* that the SSP transmission rate can be greater than the device rate
+*/
if (ssp->type == PXA25x_SSP || ssp->type == CE4100_SSP)
-   return (ssp_clk / (2 * rate) - 1) & 0xff;
+   return (DIV_ROUND_UP(ssp_clk, 2 * rate) - 1) & 0xff;
else
-   return (ssp_clk / rate - 1) & 0xfff;
+   return (DIV_ROUND_UP(ssp_clk, rate) - 1)  & 0xfff;
 }
 
 static unsigned int pxa2xx_ssp_get_clk_div(struct driver_data *drv_data,
-- 
2.20.1





[PATCH 5.1 072/405] usb: gadget: f_fs: dont free buffer prematurely

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 73103c7f958b99561555c3bd1bc1a0809e0b7d61 ]

The following kernel panic happens due to the io_data buffer gets deallocated
before the async io is completed. Add a check for the case where io_data buffer
should be deallocated by ffs_user_copy_worker.

[   41.663334] BUG: unable to handle kernel NULL pointer dereference at 
0048
[   41.672099] #PF error: [normal kernel read fault]
[   41.677356] PGD 20c974067 P4D 20c974067 PUD 20c973067 PMD 0
[   41.683687] Oops:  [#1] PREEMPT SMP
[   41.687976] CPU: 1 PID: 7 Comm: kworker/u8:0 Tainted: G U
5.0.0-quilt-2e5dc0ac-00790-gd8c79f2-dirty #2
[   41.705309] Workqueue: adb ffs_user_copy_worker
[   41.705316] RIP: 0010:__vunmap+0x2a/0xc0
[   41.705318] Code: 0f 1f 44 00 00 48 85 ff 0f 84 87 00 00 00 55 f7 c7 ff 0f 
00 00 48 89 e5 41 55 41 89 f5 41 54 53 48 89 fb 75 71 e8 56 d7 ff ff <4c> 8b 60 
48 4d 85 e4 74 76 48 89 df e8 25 ff ff ff 45 85 ed 74 46
[   41.705320] RSP: 0018:bc3a40053df0 EFLAGS: 00010286
[   41.705322] RAX:  RBX: bc3a406f1000 RCX: 
[   41.705323] RDX: 0001 RSI: 0001 RDI: 
[   41.705324] RBP: bc3a40053e08 R08: 0001fb79 R09: 0037
[   41.705325] R10: bc3a40053b68 R11: bc3a40053cad R12: fff2
[   41.705326] R13: 0001 R14:  R15: 
[   41.705328] FS:  () GS:9e2977a8() 
knlGS:
[   41.705329] CS:  0010 DS:  ES:  CR0: 80050033
[   41.705330] CR2: 0048 CR3: 00020c994000 CR4: 003406e0
[   41.705331] Call Trace:
[   41.705338]  vfree+0x50/0xb0
[   41.705341]  ffs_user_copy_worker+0xe9/0x1c0
[   41.705344]  process_one_work+0x19f/0x3e0
[   41.705348]  worker_thread+0x3f/0x3b0
[   41.829766]  kthread+0x12b/0x150
[   41.833371]  ? process_one_work+0x3e0/0x3e0
[   41.838045]  ? kthread_create_worker_on_cpu+0x70/0x70
[   41.843695]  ret_from_fork+0x3a/0x50
[   41.847689] Modules linked in: hci_uart bluetooth ecdh_generic rfkill_gpio 
dwc3_pci dwc3 snd_usb_audio mei_me tpm_crb snd_usbmidi_lib xhci_pci xhci_hcd 
mei tpm snd_hwdep cfg80211 snd_soc_skl snd_soc_skl_ipc snd_soc_sst_ipc 
snd_soc_sst_dsp snd_hda_ext_core snd_hda_core videobuf2_dma_sg crlmodule
[   41.876880] CR2: 0048
[   41.880584] ---[ end trace 2bc4addff0f2e673 ]---
[   41.891346] RIP: 0010:__vunmap+0x2a/0xc0
[   41.895734] Code: 0f 1f 44 00 00 48 85 ff 0f 84 87 00 00 00 55 f7 c7 ff 0f 
00 00 48 89 e5 41 55 41 89 f5 41 54 53 48 89 fb 75 71 e8 56 d7 ff ff <4c> 8b 60 
48 4d 85 e4 74 76 48 89 df e8 25 ff ff ff 45 85 ed 74 46
[   41.916740] RSP: 0018:bc3a40053df0 EFLAGS: 00010286
[   41.922583] RAX:  RBX: bc3a406f1000 RCX: 
[   41.930563] RDX: 0001 RSI: 0001 RDI: 
[   41.938540] RBP: bc3a40053e08 R08: 0001fb79 R09: 0037
[   41.946520] R10: bc3a40053b68 R11: bc3a40053cad R12: fff2
[   41.954502] R13: 0001 R14:  R15: 
[   41.962482] FS:  () GS:9e2977a8() 
knlGS:
[   41.971536] CS:  0010 DS:  ES:  CR0: 80050033
[   41.977960] CR2: 0048 CR3: 00020c994000 CR4: 003406e0
[   41.985930] Kernel panic - not syncing: Fatal exception
[   41.991817] Kernel Offset: 0x1600 from 0x8100 (relocation 
range: 0x8000-0xbfff)
[   42.009525] Rebooting in 10 seconds..
[   52.014376] ACPI MEMORY or I/O RESET_REG.

Fixes: 772a7a724f69 ("usb: gadget: f_fs: Allow scatter-gather buffers")
Signed-off-by: Fei Yang 
Reviewed-by: Manu Gautam 
Tested-by: John Stultz 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/gadget/function/f_fs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 20413c276c616..47be961f1bf3f 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1133,7 +1133,8 @@ static ssize_t ffs_epfile_io(struct file *file, struct 
ffs_io_data *io_data)
 error_mutex:
mutex_unlock(>mutex);
 error:
-   ffs_free_buffer(io_data);
+   if (ret != -EIOCBQUEUED) /* don't free if there is iocb queued */
+   ffs_free_buffer(io_data);
return ret;
 }
 
-- 
2.20.1





[PATCH 5.1 069/405] ASoC: Intel: kbl_da7219_max98357a: Map BTN_0 to KEY_PLAYPAUSE

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 16ec5dfe0327ddcf279957bffe4c8fe527088c63 ]

On kbl_rt5663_max98927, commit 38a5882e4292
("ASoC: Intel: kbl_rt5663_max98927: Map BTN_0 to KEY_PLAYPAUSE")
This key pair mapping to play/pause when playing Youtube

The Android 3.5mm Headset jack specification mentions that BTN_0 should
be mapped to KEY_MEDIA, but this is less logical than KEY_PLAYPAUSE,
which has much broader userspace support.

For example, the Chrome OS userspace now supports KEY_PLAYPAUSE to toggle
play/pause of videos and audio, but does not handle KEY_MEDIA.

Furthermore, Android itself now supports KEY_PLAYPAUSE equivalently, as the
new USB headset spec requires KEY_PLAYPAUSE for BTN_0.
https://source.android.com/devices/accessories/headset/usb-headset-spec

The same fix is required on Chrome kbl_da7219_max98357a.

Signed-off-by: Mac Chiang 
Reviewed-by: Benson Leung 
Acked-by: Pierre-Louis Bossart 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/intel/boards/kbl_da7219_max98357a.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/intel/boards/kbl_da7219_max98357a.c 
b/sound/soc/intel/boards/kbl_da7219_max98357a.c
index 38f6ab74709d0..07491a0f8fb8b 100644
--- a/sound/soc/intel/boards/kbl_da7219_max98357a.c
+++ b/sound/soc/intel/boards/kbl_da7219_max98357a.c
@@ -188,7 +188,7 @@ static int kabylake_da7219_codec_init(struct 
snd_soc_pcm_runtime *rtd)
 
jack = >kabylake_headset;
 
-   snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_MEDIA);
+   snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOLUMEUP);
snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEDOWN);
snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOICECOMMAND);
-- 
2.20.1





[PATCH 5.1 073/405] ASoC: hdmi-codec: unlock the device on startup errors

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 30180e8436046344b12813dc954b2e01dfdcd22d ]

If the hdmi codec startup fails, it should clear the current_substream
pointer to free the device. This is properly done for the audio_startup()
callback but for snd_pcm_hw_constraint_eld().

Make sure the pointer cleared if an error is reported.

Signed-off-by: Jerome Brunet 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/codecs/hdmi-codec.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index 35df73e42cbc5..fb2f0ac1f16f3 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -439,8 +439,12 @@ static int hdmi_codec_startup(struct snd_pcm_substream 
*substream,
if (!ret) {
ret = snd_pcm_hw_constraint_eld(substream->runtime,
hcp->eld);
-   if (ret)
+   if (ret) {
+   mutex_lock(>current_stream_lock);
+   hcp->current_stream = NULL;
+   mutex_unlock(>current_stream_lock);
return ret;
+   }
}
/* Select chmap supported */
hdmi_codec_eld_chmap(hcp);
-- 
2.20.1





[PATCH 5.1 046/405] cxgb4: Fix error path in cxgb4_init_module

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit a3147770bea76c8dbad73eca3a24c2118da5e719 ]

BUG: unable to handle kernel paging request at a016a270
PGD 3270067 P4D 3270067 PUD 3271063 PMD 230bbd067 PTE 0
Oops:  [#1
CPU: 0 PID: 6134 Comm: modprobe Not tainted 5.1.0+ #33
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
RIP: 0010:atomic_notifier_chain_register+0x24/0x60
Code: 1f 80 00 00 00 00 55 48 89 e5 41 54 49 89 f4 53 48 89 fb e8 ae b4 38 01 
48 8b 53 38 48 8d 4b 38 48 85 d2 74 20 45 8b 44 24 10 <44> 3b 42 10 7e 08 eb 13 
44 39 42 10 7c 0d 48 8d 4a 08 48 8b 52 08
RSP: 0018:c9e2bc60 EFLAGS: 00010086
RAX: 0292 RBX: 83467240 RCX: 83467278
RDX: a016a260 RSI: 83752140 RDI: 83467240
RBP: c9e2bc70 R08:  R09: 0001
R10:  R11: 014fa61f R12: a01c8260
R13: 888231091e00 R14:  R15: c9e2be78
FS:  7fbd8d7cd540() GS:888237a0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: a016a270 CR3: 00022c7e3000 CR4: 06f0
Call Trace:
 register_inet6addr_notifier+0x13/0x20
 cxgb4_init_module+0x6c/0x1000 [cxgb4
 ? 0xa01d7000
 do_one_initcall+0x6c/0x3cc
 ? do_init_module+0x22/0x1f1
 ? rcu_read_lock_sched_held+0x97/0xb0
 ? kmem_cache_alloc_trace+0x325/0x3b0
 do_init_module+0x5b/0x1f1
 load_module+0x1db1/0x2690
 ? m_show+0x1d0/0x1d0
 __do_sys_finit_module+0xc5/0xd0
 __x64_sys_finit_module+0x15/0x20
 do_syscall_64+0x6b/0x1d0
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

If pci_register_driver fails, register inet6addr_notifier is
pointless. This patch fix the error path in cxgb4_init_module.

Fixes: b5a02f503caa ("cxgb4 : Update ipv6 address handling api")
Signed-off-by: YueHaibing 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 89179e3166878..4bc0c357cb8ea 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -6161,15 +6161,24 @@ static int __init cxgb4_init_module(void)
 
ret = pci_register_driver(_driver);
if (ret < 0)
-   debugfs_remove(cxgb4_debugfs_root);
+   goto err_pci;
 
 #if IS_ENABLED(CONFIG_IPV6)
if (!inet6addr_registered) {
-   register_inet6addr_notifier(_inet6addr_notifier);
-   inet6addr_registered = true;
+   ret = register_inet6addr_notifier(_inet6addr_notifier);
+   if (ret)
+   pci_unregister_driver(_driver);
+   else
+   inet6addr_registered = true;
}
 #endif
 
+   if (ret == 0)
+   return ret;
+
+err_pci:
+   debugfs_remove(cxgb4_debugfs_root);
+
return ret;
 }
 
-- 
2.20.1





[PATCH 5.1 080/405] net/mlx5: E-Switch, Use atomic rep state to serialize state change

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 6f4e02193c9a9ea54dd3151cf97489fa787cd0e6 ]

When the state of rep was introduced, it was also designed to prevent
duplicate unloading of the same rep. Considering the following two
flows when an eswitch manager is at switchdev mode with n VF reps loaded.

+--++
| cpu-0| cpu-1  |
|  |    |
| mlx5_ib_remove   | mlx5_eswitch_disable_sriov |
|  mlx5_ib_unregister_vport_reps   |  esw_offloads_cleanup  |
|   mlx5_eswitch_unregister_vport_reps |   esw_offloads_unload_all_reps |
|__unload_reps_all_vport   |__unload_reps_all_vport |
+--++

These two flows will try to unload the same rep. Per original design,
once one flow unloads the rep, the state moves to REGISTERED. The 2nd
flow will no longer needs to do the unload and bails out. However, as
read and write of the state is not atomic, when 1st flow is doing the
unload, the state is still LOADED, 2nd flow is able to do the same
unload action. Kernel crash will happen.

To solve this, driver should do atomic test-and-set for the state. So
that only one flow can change the rep state from LOADED to REGISTERED,
and proceed to do the actual unloading.

Since the state is changing to atomic type, all other read/write should
be atomic action as well.

Fixes: f121e0ea9586 (net/mlx5: E-Switch, Add state to eswitch vport 
representors)
Signed-off-by: Bodong Wang 
Reviewed-by: Parav Pandit 
Reviewed-by: Vu Pham 
Signed-off-by: Saeed Mahameed 
Signed-off-by: Sasha Levin 
---
 .../mellanox/mlx5/core/eswitch_offloads.c | 36 +--
 include/linux/mlx5/eswitch.h  |  2 +-
 2 files changed, 18 insertions(+), 20 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c 
b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 9b2d78ee22b88..d2d8da133082c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -363,7 +363,7 @@ static int esw_set_global_vlan_pop(struct mlx5_eswitch 
*esw, u8 val)
esw_debug(esw->dev, "%s applying global %s policy\n", __func__, val ? 
"pop" : "none");
for (vf_vport = 1; vf_vport < esw->enabled_vports; vf_vport++) {
rep = >offloads.vport_reps[vf_vport];
-   if (rep->rep_if[REP_ETH].state != REP_LOADED)
+   if (atomic_read(>rep_if[REP_ETH].state) != REP_LOADED)
continue;
 
err = __mlx5_eswitch_set_vport_vlan(esw, rep->vport, 0, 0, val);
@@ -1306,7 +1306,8 @@ int esw_offloads_init_reps(struct mlx5_eswitch *esw)
ether_addr_copy(rep->hw_id, hw_id);
 
for (rep_type = 0; rep_type < NUM_REP_TYPES; rep_type++)
-   rep->rep_if[rep_type].state = REP_UNREGISTERED;
+   atomic_set(>rep_if[rep_type].state,
+  REP_UNREGISTERED);
}
 
return 0;
@@ -1315,11 +1316,9 @@ int esw_offloads_init_reps(struct mlx5_eswitch *esw)
 static void __esw_offloads_unload_rep(struct mlx5_eswitch *esw,
  struct mlx5_eswitch_rep *rep, u8 rep_type)
 {
-   if (rep->rep_if[rep_type].state != REP_LOADED)
-   return;
-
-   rep->rep_if[rep_type].unload(rep);
-   rep->rep_if[rep_type].state = REP_REGISTERED;
+   if (atomic_cmpxchg(>rep_if[rep_type].state,
+  REP_LOADED, REP_REGISTERED) == REP_LOADED)
+   rep->rep_if[rep_type].unload(rep);
 }
 
 static void __unload_reps_special_vport(struct mlx5_eswitch *esw, u8 rep_type)
@@ -1380,16 +1379,15 @@ static int __esw_offloads_load_rep(struct mlx5_eswitch 
*esw,
 {
int err = 0;
 
-   if (rep->rep_if[rep_type].state != REP_REGISTERED)
-   return 0;
-
-   err = rep->rep_if[rep_type].load(esw->dev, rep);
-   if (err)
-   return err;
-
-   rep->rep_if[rep_type].state = REP_LOADED;
+   if (atomic_cmpxchg(>rep_if[rep_type].state,
+  REP_REGISTERED, REP_LOADED) == REP_REGISTERED) {
+   err = rep->rep_if[rep_type].load(esw->dev, rep);
+   if (err)
+   atomic_set(>rep_if[rep_type].state,
+  REP_REGISTERED);
+   }
 
-   return 0;
+   return err;
 }
 
 static int __load_reps_special_vport(struct mlx5_eswitch *esw, u8 rep_type)
@@ -2076,7 +2074,7 @@ void mlx5_eswitch_register_vport_reps(struct mlx5_eswitch 
*esw,
rep_if->get_proto_dev = __rep_if->get_proto_dev;
rep_if->priv = __rep_if->priv;
 
-   rep_if->state = REP_REGISTERED;
+   atomic_set(_if->state, 

[PATCH 5.1 075/405] powerpc/boot: Fix missing check of lseek() return value

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 5d085ec04a000fefb5182d3b03ee46ca96d8389b ]

This is detected by Coverity scan: CID: 1440481

Signed-off-by: Bo YU 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/boot/addnote.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/addnote.c b/arch/powerpc/boot/addnote.c
index 9d9f6f334d3cc..3da3e2b1b51bc 100644
--- a/arch/powerpc/boot/addnote.c
+++ b/arch/powerpc/boot/addnote.c
@@ -223,7 +223,11 @@ main(int ac, char **av)
PUT_16(E_PHNUM, np + 2);
 
/* write back */
-   lseek(fd, (long) 0, SEEK_SET);
+   i = lseek(fd, (long) 0, SEEK_SET);
+   if (i < 0) {
+   perror("lseek");
+   exit(1);
+   }
i = write(fd, buf, n);
if (i < 0) {
perror("write");
-- 
2.20.1





[PATCH 5.1 042/405] acct_on(): dont mess with freeze protection

2019-05-29 Thread Greg Kroah-Hartman
From: Al Viro 

commit 9419a3191dcb27f24478d288abaab697228d28e6 upstream.

What happens there is that we are replacing file->path.mnt of
a file we'd just opened with a clone and we need the write
count contribution to be transferred from original mount to
new one.  That's it.  We do *NOT* want any kind of freeze
protection for the duration of switchover.

IOW, we should just use __mnt_{want,drop}_write() for that
switchover; no need to bother with mnt_{want,drop}_write()
there.

Tested-by: Amir Goldstein 
Reported-by: syzbot+2a73a6ea9507b7112...@syzkaller.appspotmail.com
Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/internal.h |2 --
 include/linux/mount.h |2 ++
 kernel/acct.c |4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

--- a/fs/internal.h
+++ b/fs/internal.h
@@ -89,9 +89,7 @@ extern int sb_prepare_remount_readonly(s
 
 extern void __init mnt_init(void);
 
-extern int __mnt_want_write(struct vfsmount *);
 extern int __mnt_want_write_file(struct file *);
-extern void __mnt_drop_write(struct vfsmount *);
 extern void __mnt_drop_write_file(struct file *);
 
 /*
--- a/include/linux/mount.h
+++ b/include/linux/mount.h
@@ -87,6 +87,8 @@ extern bool mnt_may_suid(struct vfsmount
 
 struct path;
 extern struct vfsmount *clone_private_mount(const struct path *path);
+extern int __mnt_want_write(struct vfsmount *);
+extern void __mnt_drop_write(struct vfsmount *);
 
 struct file_system_type;
 extern struct vfsmount *fc_mount(struct fs_context *fc);
--- a/kernel/acct.c
+++ b/kernel/acct.c
@@ -227,7 +227,7 @@ static int acct_on(struct filename *path
filp_close(file, NULL);
return PTR_ERR(internal);
}
-   err = mnt_want_write(internal);
+   err = __mnt_want_write(internal);
if (err) {
mntput(internal);
kfree(acct);
@@ -252,7 +252,7 @@ static int acct_on(struct filename *path
old = xchg(>bacct, >pin);
mutex_unlock(>lock);
pin_kill(old);
-   mnt_drop_write(mnt);
+   __mnt_drop_write(mnt);
mntput(mnt);
return 0;
 }




[PATCH 5.1 071/405] usb: dwc3: move synchronize_irq() out of the spinlock protected block

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 41a91c606e7d2b74358a944525267cc451c271e8 ]

dwc3_gadget_suspend() is called under dwc->lock spinlock. In such context
calling synchronize_irq() is not allowed. Move the problematic call out
of the protected block to fix the following kernel BUG during system
suspend:

BUG: sleeping function called from invalid context at kernel/irq/manage.c:112
in_atomic(): 1, irqs_disabled(): 128, pid: 1601, name: rtcwake
6 locks held by rtcwake/1601:
 #0: f70ac2a2 (sb_writers#7){.+.+}, at: vfs_write+0x130/0x16c
 #1: b5fe1270 (>mutex){+.+.}, at: kernfs_fop_write+0xc0/0x1e4
 #2: 7e597705 (kn->count#60){.+.+}, at: kernfs_fop_write+0xc8/0x1e4
 #3: 8b3527d0 (system_transition_mutex){+.+.}, at: pm_suspend+0xc4/0xc04
 #4: fc7f1c42 (>mutex){}, at: __device_suspend+0xd8/0x74c
 #5: 4b36507e (&(>lock)->rlock){}, at: dwc3_gadget_suspend+0x24/0x3c
irq event stamp: 11252
hardirqs last  enabled at (11251): [] 
_raw_spin_unlock_irqrestore+0x6c/0x74
hardirqs last disabled at (11252): [] _raw_spin_lock_irqsave+0x1c/0x5c
softirqs last  enabled at (9744): [] __do_softirq+0x3a4/0x66c
softirqs last disabled at (9737): [] irq_exit+0x140/0x168
Preemption disabled at:
[<>]   (null)
CPU: 7 PID: 1601 Comm: rtcwake Not tainted
5.0.0-rc3-next-20190122-00039-ga3f4ee4f8a52 #5252
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x90/0xc8)
[] (dump_stack) from [] (___might_sleep+0x22c/0x2c8)
[] (___might_sleep) from [] (synchronize_irq+0x28/0x84)
[] (synchronize_irq) from [] (dwc3_gadget_suspend+0x34/0x3c)
[] (dwc3_gadget_suspend) from [] 
(dwc3_suspend_common+0x154/0x410)
[] (dwc3_suspend_common) from [] (dwc3_suspend+0x14/0x2c)
[] (dwc3_suspend) from [] (platform_pm_suspend+0x2c/0x54)
[] (platform_pm_suspend) from [] 
(dpm_run_callback+0xa4/0x3dc)
[] (dpm_run_callback) from [] (__device_suspend+0x134/0x74c)
[] (__device_suspend) from [] (dpm_suspend+0x174/0x588)
[] (dpm_suspend) from [] 
(suspend_devices_and_enter+0xc0/0xe74)
[] (suspend_devices_and_enter) from [] 
(pm_suspend+0x770/0xc04)
[] (pm_suspend) from [] (state_store+0x6c/0xcc)
[] (state_store) from [] (kobj_attr_store+0x14/0x20)
[] (kobj_attr_store) from [] (sysfs_kf_write+0x4c/0x50)
[] (sysfs_kf_write) from [] (kernfs_fop_write+0xfc/0x1e4)
[] (kernfs_fop_write) from [] (__vfs_write+0x2c/0x160)
[] (__vfs_write) from [] (vfs_write+0xa4/0x16c)
[] (vfs_write) from [] (ksys_write+0x40/0x8c)
[] (ksys_write) from [] (ret_fast_syscall+0x0/0x28)
Exception stack(0xed55ffa8 to 0xed55fff0)
...

Fixes: 01c10880d242 ("usb: dwc3: gadget: synchronize_irq dwc irq in suspend")
Signed-off-by: Marek Szyprowski 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/dwc3/core.c   | 2 ++
 drivers/usb/dwc3/gadget.c | 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index f944cea4056bc..72110a8c49d68 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1600,6 +1600,7 @@ static int dwc3_suspend_common(struct dwc3 *dwc, 
pm_message_t msg)
spin_lock_irqsave(>lock, flags);
dwc3_gadget_suspend(dwc);
spin_unlock_irqrestore(>lock, flags);
+   synchronize_irq(dwc->irq_gadget);
dwc3_core_exit(dwc);
break;
case DWC3_GCTL_PRTCAP_HOST:
@@ -1632,6 +1633,7 @@ static int dwc3_suspend_common(struct dwc3 *dwc, 
pm_message_t msg)
spin_lock_irqsave(>lock, flags);
dwc3_gadget_suspend(dwc);
spin_unlock_irqrestore(>lock, flags);
+   synchronize_irq(dwc->irq_gadget);
}
 
dwc3_otg_exit(dwc);
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index e293400cc6e95..2bb0ff9608d30 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -3384,8 +3384,6 @@ int dwc3_gadget_suspend(struct dwc3 *dwc)
dwc3_disconnect_gadget(dwc);
__dwc3_gadget_stop(dwc);
 
-   synchronize_irq(dwc->irq_gadget);
-
return 0;
 }
 
-- 
2.20.1





[PATCH 5.1 078/405] ASoC: imx: fix fiq dependencies

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit ea751227c813ab833609afecfeedaf0aa26f327e ]

During randconfig builds, I occasionally run into an invalid configuration
of the freescale FIQ sound support:

WARNING: unmet direct dependencies detected for SND_SOC_IMX_PCM_FIQ
  Depends on [m]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_IMX_SOC 
[=m]
  Selected by [y]:
  - SND_SOC_FSL_SPDIF [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && 
SND_IMX_SOC [=m]!=n && (MXC_TZIC [=n] || MXC_AVIC [=y])

sound/soc/fsl/imx-ssi.o: In function `imx_ssi_remove':
imx-ssi.c:(.text+0x28): undefined reference to `imx_pcm_fiq_exit'
sound/soc/fsl/imx-ssi.o: In function `imx_ssi_probe':
imx-ssi.c:(.text+0xa64): undefined reference to `imx_pcm_fiq_init'

The Kconfig warning is a result of the symbol being defined inside of
the "if SND_IMX_SOC" block, and is otherwise harmless. The link error
is more tricky and happens with SND_SOC_IMX_SSI=y, which may or may not
imply FIQ support. However, if SND_SOC_FSL_SSI is set to =m at the same
time, that selects SND_SOC_IMX_PCM_FIQ as a loadable module dependency,
which then causes a link failure from imx-ssi.

The solution here is to make SND_SOC_IMX_PCM_FIQ built-in whenever
one of its potential users is built-in.

Fixes: ff40260f79dc ("ASoC: fsl: refine DMA/FIQ dependencies")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/Kconfig | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 7b1d9970be8b3..1f65cf555ebe0 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -182,16 +182,17 @@ config SND_MPC52xx_SOC_EFIKA
 
 endif # SND_POWERPC_SOC
 
+config SND_SOC_IMX_PCM_FIQ
+   tristate
+   default y if SND_SOC_IMX_SSI=y && (SND_SOC_FSL_SSI=m || 
SND_SOC_FSL_SPDIF=m) && (MXC_TZIC || MXC_AVIC)
+   select FIQ
+
 if SND_IMX_SOC
 
 config SND_SOC_IMX_SSI
tristate
select SND_SOC_FSL_UTILS
 
-config SND_SOC_IMX_PCM_FIQ
-   tristate
-   select FIQ
-
 comment "SoC Audio support for Freescale i.MX boards:"
 
 config SND_MXC_SOC_WM1133_EV1
-- 
2.20.1





[PATCH 5.1 040/405] batman-adv: mcast: fix multicast tt/tvlv worker locking

2019-05-29 Thread Greg Kroah-Hartman
From: Linus Lüssing 

commit a3c7cd0cdf1107f891aff847ad481e34df727055 upstream.

Syzbot has reported some issues with the locking assumptions made for
the multicast tt/tvlv worker: It was able to trigger the WARN_ON() in
batadv_mcast_mla_tt_retract() and batadv_mcast_mla_tt_add().
While hard/not reproduceable for us so far it seems that the
delayed_work_pending() we use might not be quite safe from reordering.

Therefore this patch adds an explicit, new spinlock to protect the
update of the mla_list and flags in bat_priv and then removes the
WARN_ON(delayed_work_pending()).

Reported-by: syzbot+83f2d54ec6b7e417e...@syzkaller.appspotmail.com
Reported-by: syzbot+050927a651272b145...@syzkaller.appspotmail.com
Reported-by: syzbot+979ffc89b87309b1b...@syzkaller.appspotmail.com
Reported-by: syzbot+f9f3f388440283da2...@syzkaller.appspotmail.com
Fixes: cbebd363b2e9 ("batman-adv: Use own timer for multicast TT and TVLV 
updates")
Signed-off-by: Linus Lüssing 
Signed-off-by: Sven Eckelmann 
Signed-off-by: Simon Wunderlich 
Signed-off-by: Greg Kroah-Hartman 

---
 net/batman-adv/main.c  |1 +
 net/batman-adv/multicast.c |   11 +++
 net/batman-adv/types.h |5 +
 3 files changed, 9 insertions(+), 8 deletions(-)

--- a/net/batman-adv/main.c
+++ b/net/batman-adv/main.c
@@ -161,6 +161,7 @@ int batadv_mesh_init(struct net_device *
spin_lock_init(_priv->tt.commit_lock);
spin_lock_init(_priv->gw.list_lock);
 #ifdef CONFIG_BATMAN_ADV_MCAST
+   spin_lock_init(_priv->mcast.mla_lock);
spin_lock_init(_priv->mcast.want_lists_lock);
 #endif
spin_lock_init(_priv->tvlv.container_list_lock);
--- a/net/batman-adv/multicast.c
+++ b/net/batman-adv/multicast.c
@@ -325,8 +325,6 @@ static void batadv_mcast_mla_list_free(s
  * translation table except the ones listed in the given mcast_list.
  *
  * If mcast_list is NULL then all are retracted.
- *
- * Do not call outside of the mcast worker! (or cancel mcast worker first)
  */
 static void batadv_mcast_mla_tt_retract(struct batadv_priv *bat_priv,
struct hlist_head *mcast_list)
@@ -334,8 +332,6 @@ static void batadv_mcast_mla_tt_retract(
struct batadv_hw_addr *mcast_entry;
struct hlist_node *tmp;
 
-   WARN_ON(delayed_work_pending(_priv->mcast.work));
-
hlist_for_each_entry_safe(mcast_entry, tmp, _priv->mcast.mla_list,
  list) {
if (mcast_list &&
@@ -359,8 +355,6 @@ static void batadv_mcast_mla_tt_retract(
  *
  * Adds multicast listener announcements from the given mcast_list to the
  * translation table if they have not been added yet.
- *
- * Do not call outside of the mcast worker! (or cancel mcast worker first)
  */
 static void batadv_mcast_mla_tt_add(struct batadv_priv *bat_priv,
struct hlist_head *mcast_list)
@@ -368,8 +362,6 @@ static void batadv_mcast_mla_tt_add(stru
struct batadv_hw_addr *mcast_entry;
struct hlist_node *tmp;
 
-   WARN_ON(delayed_work_pending(_priv->mcast.work));
-
if (!mcast_list)
return;
 
@@ -658,7 +650,10 @@ static void batadv_mcast_mla_update(stru
priv_mcast = container_of(delayed_work, struct batadv_priv_mcast, work);
bat_priv = container_of(priv_mcast, struct batadv_priv, mcast);
 
+   spin_lock(_priv->mcast.mla_lock);
__batadv_mcast_mla_update(bat_priv);
+   spin_unlock(_priv->mcast.mla_lock);
+
batadv_mcast_start_timer(bat_priv);
 }
 
--- a/net/batman-adv/types.h
+++ b/net/batman-adv/types.h
@@ -1224,6 +1224,11 @@ struct batadv_priv_mcast {
unsigned char bridged:1;
 
/**
+* @mla_lock: a lock protecting mla_list and mla_flags
+*/
+   spinlock_t mla_lock;
+
+   /**
 * @num_want_all_unsnoopables: number of nodes wanting unsnoopable IP
 *  traffic
 */




[PATCH 5.1 077/405] spi: atmel-quadspi: fix crash while suspending

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit e5c27498a0403b270620b1a8a0a66e3efc222fb6 ]

atmel_qspi objects are kept in spi_controller objects, so, first get
pointer to spi_controller object and then get atmel_qspi object from
spi_controller object.

Fixes: 2d30ac5ed633 ("mtd: spi-nor: atmel-quadspi: Use spi-mem interface for 
atmel-quadspi driver")
Signed-off-by: Claudiu Beznea 
Reviewed-by: Tudor Ambarus 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 drivers/spi/atmel-quadspi.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
index fffc21cd5f793..b3173ebddaded 100644
--- a/drivers/spi/atmel-quadspi.c
+++ b/drivers/spi/atmel-quadspi.c
@@ -570,7 +570,8 @@ static int atmel_qspi_remove(struct platform_device *pdev)
 
 static int __maybe_unused atmel_qspi_suspend(struct device *dev)
 {
-   struct atmel_qspi *aq = dev_get_drvdata(dev);
+   struct spi_controller *ctrl = dev_get_drvdata(dev);
+   struct atmel_qspi *aq = spi_controller_get_devdata(ctrl);
 
clk_disable_unprepare(aq->qspick);
clk_disable_unprepare(aq->pclk);
@@ -580,7 +581,8 @@ static int __maybe_unused atmel_qspi_suspend(struct device 
*dev)
 
 static int __maybe_unused atmel_qspi_resume(struct device *dev)
 {
-   struct atmel_qspi *aq = dev_get_drvdata(dev);
+   struct spi_controller *ctrl = dev_get_drvdata(dev);
+   struct atmel_qspi *aq = spi_controller_get_devdata(ctrl);
 
clk_prepare_enable(aq->pclk);
clk_prepare_enable(aq->qspick);
-- 
2.20.1





[PATCH 5.1 074/405] powerpc/perf: Return accordingly on invalid chip-id in

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit a913e5e8b43be1d3897a141ce61c1ec071cad89c ]

Nest hardware counter memory resides in a per-chip reserve-memory.
During nest_imc_event_init(), chip-id of the event-cpu is considered to
calculate the base memory addresss for that cpu. Return, proper error
condition if the chip_id calculated is invalid.

Reported-by: Dan Carpenter 
Fixes: 885dcd709ba91 ("powerpc/perf: Add nest IMC PMU support")
Reviewed-by: Madhavan Srinivasan 
Signed-off-by: Anju T Sudhakar 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/perf/imc-pmu.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index b1c37cc3fa98b..6159e9edddfd0 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -487,6 +487,11 @@ static int nest_imc_event_init(struct perf_event *event)
 * Get the base memory addresss for this cpu.
 */
chip_id = cpu_to_chip_id(event->cpu);
+
+   /* Return, if chip_id is not valid */
+   if (chip_id < 0)
+   return -ENODEV;
+
pcni = pmu->mem_info;
do {
if (pcni->id == chip_id) {
-- 
2.20.1





[PATCH 5.1 103/405] s390/kexec_file: Fix detection of text segment in ELF loader

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 729829d775c9a5217abc784b2f16087d79c4eec8 ]

To register data for the next kernel (command line, oldmem_base, etc.) the
current kernel needs to find the ELF segment that contains head.S. This is
currently done by checking ifor 'phdr->p_paddr == 0'. This works fine for
the current kernel build but in theory the first few pages could be
skipped. Make the detection more robust by checking if the entry point lies
within the segment.

Signed-off-by: Philipp Rudo 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Sasha Levin 
---
 arch/s390/kernel/kexec_elf.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/s390/kernel/kexec_elf.c b/arch/s390/kernel/kexec_elf.c
index 5a286b012043b..602e7cc26d118 100644
--- a/arch/s390/kernel/kexec_elf.c
+++ b/arch/s390/kernel/kexec_elf.c
@@ -19,10 +19,15 @@ static int kexec_file_add_elf_kernel(struct kimage *image,
struct kexec_buf buf;
const Elf_Ehdr *ehdr;
const Elf_Phdr *phdr;
+   Elf_Addr entry;
int i, ret;
 
ehdr = (Elf_Ehdr *)kernel;
buf.image = image;
+   if (image->type == KEXEC_TYPE_CRASH)
+   entry = STARTUP_KDUMP_OFFSET;
+   else
+   entry = ehdr->e_entry;
 
phdr = (void *)ehdr + ehdr->e_phoff;
for (i = 0; i < ehdr->e_phnum; i++, phdr++) {
@@ -35,7 +40,7 @@ static int kexec_file_add_elf_kernel(struct kimage *image,
buf.mem = ALIGN(phdr->p_paddr, phdr->p_align);
buf.memsz = phdr->p_memsz;
 
-   if (phdr->p_paddr == 0) {
+   if (entry - phdr->p_paddr < phdr->p_memsz) {
data->kernel_buf = buf.buffer;
data->memsz += STARTUP_NORMAL_OFFSET;
 
-- 
2.20.1





[PATCH 5.1 105/405] sched/nohz: Run NOHZ idle load balancer on HK_FLAG_MISC CPUs

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 9b019acb72e4b5741d88e8936d6f200ed44b66b2 ]

The NOHZ idle balancer runs on the lowest idle CPU. This can
interfere with isolated CPUs, so confine it to HK_FLAG_MISC
housekeeping CPUs.

HK_FLAG_SCHED is not used for this because it is not set anywhere
at the moment. This could be folded into HK_FLAG_SCHED once that
option is fixed.

The problem was observed with increased jitter on an application
running on CPU0, caused by NOHZ idle load balancing being run on
CPU1 (an SMT sibling).

Signed-off-by: Nicholas Piggin 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Frederic Weisbecker 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20190412042613.28930-1-npig...@gmail.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 kernel/sched/fair.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 35f3ea3750844..232491e3ed0db 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -9551,22 +9551,26 @@ static inline int on_null_domain(struct rq *rq)
  * - When one of the busy CPUs notice that there may be an idle rebalancing
  *   needed, they will kick the idle load balancer, which then does idle
  *   load balancing for all the idle CPUs.
+ * - HK_FLAG_MISC CPUs are used for this task, because HK_FLAG_SCHED not set
+ *   anywhere yet.
  */
 
 static inline int find_new_ilb(void)
 {
-   int ilb = cpumask_first(nohz.idle_cpus_mask);
+   int ilb;
 
-   if (ilb < nr_cpu_ids && idle_cpu(ilb))
-   return ilb;
+   for_each_cpu_and(ilb, nohz.idle_cpus_mask,
+ housekeeping_cpumask(HK_FLAG_MISC)) {
+   if (idle_cpu(ilb))
+   return ilb;
+   }
 
return nr_cpu_ids;
 }
 
 /*
- * Kick a CPU to do the nohz balancing, if it is time for it. We pick the
- * nohz_load_balancer CPU (if there is one) otherwise fallback to any idle
- * CPU (if there is one).
+ * Kick a CPU to do the nohz balancing, if it is time for it. We pick any
+ * idle CPU in the HK_FLAG_MISC housekeeping set (if there is one).
  */
 static void kick_ilb(unsigned int flags)
 {
-- 
2.20.1





[PATCH 5.1 048/405] NFS: make nfs_match_client killable

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 950a578c6128c2886e295b9c7ecb0b6b22fcc92b ]

Actually we don't do anything with return value from
nfs_wait_client_init_complete in nfs_match_client, as a
consequence if we get a fatal signal and client is not
fully initialised, we'll loop to "again" label

This has been proven to cause soft lockups on some scenarios
(no-carrier but configured network interfaces)

Signed-off-by: Roberto Bergantinos Corpas 
Reviewed-by: Benjamin Coddington 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/client.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index 90d71fda65cec..350cfa561e0e8 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -284,6 +284,7 @@ static struct nfs_client *nfs_match_client(const struct 
nfs_client_initdata *dat
struct nfs_client *clp;
const struct sockaddr *sap = data->addr;
struct nfs_net *nn = net_generic(data->net, nfs_net_id);
+   int error;
 
 again:
list_for_each_entry(clp, >nfs_client_list, cl_share_link) {
@@ -296,8 +297,10 @@ static struct nfs_client *nfs_match_client(const struct 
nfs_client_initdata *dat
if (clp->cl_cons_state > NFS_CS_READY) {
refcount_inc(>cl_count);
spin_unlock(>nfs_client_lock);
-   nfs_wait_client_init_complete(clp);
+   error = nfs_wait_client_init_complete(clp);
nfs_put_client(clp);
+   if (error < 0)
+   return ERR_PTR(error);
spin_lock(>nfs_client_lock);
goto again;
}
@@ -407,6 +410,8 @@ struct nfs_client *nfs_get_client(const struct 
nfs_client_initdata *cl_init)
clp = nfs_match_client(cl_init);
if (clp) {
spin_unlock(>nfs_client_lock);
+   if (IS_ERR(clp))
+   return clp;
if (new)
new->rpc_ops->free_client(new);
return nfs_found_client(cl_init, clp);
-- 
2.20.1





RE: [EXT] Re: Issue: regmap: use debugfs even when no device

2019-05-29 Thread Andy Duan
From: Mark Brown  Sent: Wednesday, May 29, 2019 7:16 PM
> To: Andy Duan 
> Cc: da...@lechnology.com; raf...@kernel.org; Robby Cai
> ; gre...@linuxfoundation.org; linux-kernel
> 
> Subject: Re: [EXT] Re: Issue: regmap: use debugfs even when no device
> 
> On Wed, May 29, 2019 at 01:33:46AM +, Andy Duan wrote:
> 
> > Correct, regmap without device also has issue when power if off,
> > because regmap doesn't implement runtime pm for the device, but maybe
> > device driver implement the runtime pm for the device.
> 
> > So regmap how to manage the clock and power when access registers by
> debugfs ?
> 
> Like I say the basic recommendation is to use a cache.

Got it, thanks. 


[PATCH 5.1 047/405] afs: Fix getting the afs.fid xattr

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit a2f611a3dc317d8ea1c98ad6c54b911cf7f93193 ]

The AFS3 FID is three 32-bit unsigned numbers and is represented as three
up-to-8-hex-digit numbers separated by colons to the afs.fid xattr.
However, with the advent of support for YFS, the FID is now a 64-bit volume
number, a 96-bit vnode/inode number and a 32-bit uniquifier (as before).
Whilst the sprintf in afs_xattr_get_fid() has been partially updated (it
currently ignores the upper 32 bits of the 96-bit vnode number), the size
of the stack-based buffer has not been increased to match, thereby allowing
stack corruption to occur.

Fix this by increasing the buffer size appropriately and conditionally
including the upper part of the vnode number if it is non-zero.  The latter
requires the lower part to be zero-padded if the upper part is non-zero.

Fixes: 3b6492df4153 ("afs: Increase to 64-bit volume ID and 96-bit vnode ID for 
YFS")
Signed-off-by: David Howells 
Signed-off-by: Sasha Levin 
---
 fs/afs/xattr.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/fs/afs/xattr.c b/fs/afs/xattr.c
index a2cdf25573e24..706801c6c4c4c 100644
--- a/fs/afs/xattr.c
+++ b/fs/afs/xattr.c
@@ -69,11 +69,20 @@ static int afs_xattr_get_fid(const struct xattr_handler 
*handler,
 void *buffer, size_t size)
 {
struct afs_vnode *vnode = AFS_FS_I(inode);
-   char text[8 + 1 + 8 + 1 + 8 + 1];
+   char text[16 + 1 + 24 + 1 + 8 + 1];
size_t len;
 
-   len = sprintf(text, "%llx:%llx:%x",
- vnode->fid.vid, vnode->fid.vnode, vnode->fid.unique);
+   /* The volume ID is 64-bit, the vnode ID is 96-bit and the
+* uniquifier is 32-bit.
+*/
+   len = sprintf(text, "%llx:", vnode->fid.vid);
+   if (vnode->fid.vnode_hi)
+   len += sprintf(text + len, "%x%016llx",
+  vnode->fid.vnode_hi, vnode->fid.vnode);
+   else
+   len += sprintf(text + len, "%llx", vnode->fid.vnode);
+   len += sprintf(text + len, ":%x", vnode->fid.unique);
+
if (size == 0)
return len;
if (len > size)
-- 
2.20.1





[PATCH 5.1 089/405] powerpc/watchdog: Use hrtimers for per-CPU heartbeat

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 7ae3f6e130e8dc6188b59e3b4ebc2f16e9c8d053 ]

Using a jiffies timer creates a dependency on the tick_do_timer_cpu
incrementing jiffies. If that CPU has locked up and jiffies is not
incrementing, the watchdog heartbeat timer for all CPUs stops and
creates false positives and confusing warnings on local CPUs, and
also causes the SMP detector to stop, so the root cause is never
detected.

Fix this by using hrtimer based timers for the watchdog heartbeat,
like the generic kernel hardlockup detector.

Cc: Gautham R. Shenoy 
Reported-by: Ravikumar Bangoria 
Signed-off-by: Nicholas Piggin 
Tested-by: Ravi Bangoria 
Reported-by: Ravi Bangoria 
Reviewed-by: Gautham R. Shenoy 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/watchdog.c | 81 +-
 1 file changed, 40 insertions(+), 41 deletions(-)

diff --git a/arch/powerpc/kernel/watchdog.c b/arch/powerpc/kernel/watchdog.c
index 3c6ab22a0c4e3..af3c15a1d41eb 100644
--- a/arch/powerpc/kernel/watchdog.c
+++ b/arch/powerpc/kernel/watchdog.c
@@ -77,7 +77,7 @@ static u64 wd_smp_panic_timeout_tb __read_mostly; /* panic 
other CPUs */
 
 static u64 wd_timer_period_ms __read_mostly;  /* interval between heartbeat */
 
-static DEFINE_PER_CPU(struct timer_list, wd_timer);
+static DEFINE_PER_CPU(struct hrtimer, wd_hrtimer);
 static DEFINE_PER_CPU(u64, wd_timer_tb);
 
 /* SMP checker bits */
@@ -293,21 +293,21 @@ void soft_nmi_interrupt(struct pt_regs *regs)
nmi_exit();
 }
 
-static void wd_timer_reset(unsigned int cpu, struct timer_list *t)
-{
-   t->expires = jiffies + msecs_to_jiffies(wd_timer_period_ms);
-   if (wd_timer_period_ms > 1000)
-   t->expires = __round_jiffies_up(t->expires, cpu);
-   add_timer_on(t, cpu);
-}
-
-static void wd_timer_fn(struct timer_list *t)
+static enum hrtimer_restart watchdog_timer_fn(struct hrtimer *hrtimer)
 {
int cpu = smp_processor_id();
 
+   if (!(watchdog_enabled & NMI_WATCHDOG_ENABLED))
+   return HRTIMER_NORESTART;
+
+   if (!cpumask_test_cpu(cpu, _cpumask))
+   return HRTIMER_NORESTART;
+
watchdog_timer_interrupt(cpu);
 
-   wd_timer_reset(cpu, t);
+   hrtimer_forward_now(hrtimer, ms_to_ktime(wd_timer_period_ms));
+
+   return HRTIMER_RESTART;
 }
 
 void arch_touch_nmi_watchdog(void)
@@ -323,37 +323,22 @@ void arch_touch_nmi_watchdog(void)
 }
 EXPORT_SYMBOL(arch_touch_nmi_watchdog);
 
-static void start_watchdog_timer_on(unsigned int cpu)
-{
-   struct timer_list *t = per_cpu_ptr(_timer, cpu);
-
-   per_cpu(wd_timer_tb, cpu) = get_tb();
-
-   timer_setup(t, wd_timer_fn, TIMER_PINNED);
-   wd_timer_reset(cpu, t);
-}
-
-static void stop_watchdog_timer_on(unsigned int cpu)
-{
-   struct timer_list *t = per_cpu_ptr(_timer, cpu);
-
-   del_timer_sync(t);
-}
-
-static int start_wd_on_cpu(unsigned int cpu)
+static void start_watchdog(void *arg)
 {
+   struct hrtimer *hrtimer = this_cpu_ptr(_hrtimer);
+   int cpu = smp_processor_id();
unsigned long flags;
 
if (cpumask_test_cpu(cpu, _cpus_enabled)) {
WARN_ON(1);
-   return 0;
+   return;
}
 
if (!(watchdog_enabled & NMI_WATCHDOG_ENABLED))
-   return 0;
+   return;
 
if (!cpumask_test_cpu(cpu, _cpumask))
-   return 0;
+   return;
 
wd_smp_lock();
cpumask_set_cpu(cpu, _cpus_enabled);
@@ -363,27 +348,40 @@ static int start_wd_on_cpu(unsigned int cpu)
}
wd_smp_unlock();
 
-   start_watchdog_timer_on(cpu);
+   *this_cpu_ptr(_timer_tb) = get_tb();
 
-   return 0;
+   hrtimer_init(hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+   hrtimer->function = watchdog_timer_fn;
+   hrtimer_start(hrtimer, ms_to_ktime(wd_timer_period_ms),
+ HRTIMER_MODE_REL_PINNED);
 }
 
-static int stop_wd_on_cpu(unsigned int cpu)
+static int start_watchdog_on_cpu(unsigned int cpu)
 {
+   return smp_call_function_single(cpu, start_watchdog, NULL, true);
+}
+
+static void stop_watchdog(void *arg)
+{
+   struct hrtimer *hrtimer = this_cpu_ptr(_hrtimer);
+   int cpu = smp_processor_id();
unsigned long flags;
 
if (!cpumask_test_cpu(cpu, _cpus_enabled))
-   return 0; /* Can happen in CPU unplug case */
+   return; /* Can happen in CPU unplug case */
 
-   stop_watchdog_timer_on(cpu);
+   hrtimer_cancel(hrtimer);
 
wd_smp_lock();
cpumask_clear_cpu(cpu, _cpus_enabled);
wd_smp_unlock();
 
wd_smp_clear_cpu_pending(cpu, get_tb());
+}
 
-   return 0;
+static int stop_watchdog_on_cpu(unsigned int cpu)
+{
+   return smp_call_function_single(cpu, stop_watchdog, NULL, true);
 }
 
 static void watchdog_calc_timeouts(void)
@@ -402,7 +400,7 @@ void watchdog_nmi_stop(void)
int cpu;
 
for_each_cpu(cpu, _cpus_enabled)
- 

[PATCH 5.1 082/405] ACPI / property: fix handling of data_nodes in acpi_get_next_subnode()

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 23583f7795025e3c783b680d906509366b0906ad ]

When the DSDT tables expose devices with subdevices and a set of
hierarchical _DSD properties, the data returned by
acpi_get_next_subnode() is incorrect, with the results suggesting a bad
pointer assignment. The parser works fine with device_nodes or
data_nodes, but not with a combination of the two.

The problem is traced to an invalid pointer used when jumping from
handling device_nodes to data nodes. The existing code looks for data
nodes below the last subdevice found instead of the common root. Fix
by forcing the acpi_device pointer to be derived from the same fwnode
for the two types of subnodes.

This same problem of handling device and data nodes was already fixed
in a similar way by 'commit bf4703fdd166 ("ACPI / property: fix data
node parsing in acpi_get_next_subnode()")' but broken later by 'commit
34055190b19 ("ACPI / property: Add fwnode_get_next_child_node()")', so
this should probably go to linux-stable all the way to 4.12

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin 
---
 drivers/acpi/property.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 77abe0ec40431..bd533f68b1dec 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -1031,6 +1031,14 @@ struct fwnode_handle *acpi_get_next_subnode(const struct 
fwnode_handle *fwnode,
const struct acpi_data_node *data = to_acpi_data_node(fwnode);
struct acpi_data_node *dn;
 
+   /*
+* We can have a combination of device and data nodes, e.g. with
+* hierarchical _DSD properties. Make sure the adev pointer is
+* restored before going through data nodes, otherwise we will
+* be looking for data_nodes below the last device found instead
+* of the common fwnode shared by device_nodes and data_nodes.
+*/
+   adev = to_acpi_device_node(fwnode);
if (adev)
head = >data.subnodes;
else if (data)
-- 
2.20.1





[PATCH 5.1 102/405] scsi: qedi: Abort ep termination if offload not scheduled

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit f848bfd8e167210a29374e8a678892bed591684f ]

Sometimes during connection recovery when there is a failure to resolve
ARP, and offload connection was not issued, driver tries to flush pending
offload connection work which was not queued up.

kernel: WARNING: CPU: 19 PID: 10110 at kernel/workqueue.c:3030 
__flush_work.isra.34+0x19c/0x1b0
kernel: CPU: 19 PID: 10110 Comm: iscsid Tainted: G W 5.1.0-rc4 #11
kernel: Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 2.9.1 12/04/2018
kernel: RIP: 0010:__flush_work.isra.34+0x19c/0x1b0
kernel: Code: 8b fb 66 0f 1f 44 00 00 31 c0 eb ab 48 89 ef c6 07 00 0f 1f 40 00 
fb 66 0f 1f 44 00 00 31 c0 eb 96 e8 08 16 fe ff 0f 0b eb 8d <0f> 0b 31 c0 eb 87 
0f 1f 40 00 66 2e 0f 1
f 84 00 00 00 00 00 0f 1f
kernel: RSP: 0018:a6b4054dba68 EFLAGS: 00010246
kernel: RAX:  RBX: 91df21c36fc0 RCX: 
kernel: RDX: 0001 RSI:  RDI: 91df21c36fc0
kernel: RBP: 91df21c36ef0 R08:  R09: 
kernel: R10: 0038 R11: a6b4054dbd60 R12: c05e72c0
kernel: R13: 91db10280820 R14: 0048 R15: 
kernel: FS:  7f5d83cc1740() GS:91df2f84() 
knlGS:
kernel: CS:  0010 DS:  ES:  CR0: 80050033
kernel: CR2: 01cc5000 CR3: 000465450002 CR4: 001606e0
kernel: Call Trace:
kernel: ? try_to_del_timer_sync+0x4d/0x80
kernel: qedi_ep_disconnect+0x3b/0x410 [qedi]
kernel: ? 0xc083c000
kernel: ? klist_iter_exit+0x14/0x20
kernel: ? class_find_device+0x93/0xf0
kernel: iscsi_if_ep_disconnect.isra.18+0x58/0x70 [scsi_transport_iscsi]
kernel: iscsi_if_recv_msg+0x10e2/0x1510 [scsi_transport_iscsi]
kernel: ? copyout+0x22/0x30
kernel: ? _copy_to_iter+0xa0/0x430
kernel: ? _cond_resched+0x15/0x30
kernel: ? __kmalloc_node_track_caller+0x1f9/0x270
kernel: iscsi_if_rx+0xa5/0x1e0 [scsi_transport_iscsi]
kernel: netlink_unicast+0x17f/0x230
kernel: netlink_sendmsg+0x2d2/0x3d0
kernel: sock_sendmsg+0x36/0x50
kernel: ___sys_sendmsg+0x280/0x2a0
kernel: ? timerqueue_add+0x54/0x80
kernel: ? enqueue_hrtimer+0x38/0x90
kernel: ? hrtimer_start_range_ns+0x19f/0x2c0
kernel: __sys_sendmsg+0x58/0xa0
kernel: do_syscall_64+0x5b/0x180
kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Manish Rangankar 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/qedi/qedi_iscsi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/qedi/qedi_iscsi.c b/drivers/scsi/qedi/qedi_iscsi.c
index 6d6d6013e35b8..bf371e7b957d0 100644
--- a/drivers/scsi/qedi/qedi_iscsi.c
+++ b/drivers/scsi/qedi/qedi_iscsi.c
@@ -1000,6 +1000,9 @@ static void qedi_ep_disconnect(struct iscsi_endpoint *ep)
qedi_ep = ep->dd_data;
qedi = qedi_ep->qedi;
 
+   if (qedi_ep->state == EP_STATE_OFLDCONN_START)
+   goto ep_exit_recover;
+
flush_work(_ep->offload_work);
 
if (qedi_ep->conn) {
-- 
2.20.1





[PATCH 5.1 090/405] cpufreq: Fix kobject memleak

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 4ebe36c94aed95de71a8ce6a6762226d31c938ee ]

Currently the error return path from kobject_init_and_add() is not
followed by a call to kobject_put() - which means we are leaking the
kobject.

Fix it by adding a call to kobject_put() in the error path of
kobject_init_and_add().

Signed-off-by: Viresh Kumar 
Reviewed-by: Tobin C. Harding 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin 
---
 drivers/cpufreq/cpufreq.c  | 1 +
 drivers/cpufreq/cpufreq_governor.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index e10922709d139..bbf79544d0ad8 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1098,6 +1098,7 @@ static struct cpufreq_policy 
*cpufreq_policy_alloc(unsigned int cpu)
   cpufreq_global_kobject, "policy%u", cpu);
if (ret) {
pr_err("%s: failed to init policy->kobj: %d\n", __func__, ret);
+   kobject_put(>kobj);
goto err_free_real_cpus;
}
 
diff --git a/drivers/cpufreq/cpufreq_governor.c 
b/drivers/cpufreq/cpufreq_governor.c
index ffa9adeaba31b..9d1d9bf02710b 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -459,6 +459,8 @@ int cpufreq_dbs_governor_init(struct cpufreq_policy *policy)
/* Failure, so roll back. */
pr_err("initialization failed (dbs_data kobject init error %d)\n", ret);
 
+   kobject_put(_data->attr_set.kobj);
+
policy->governor_data = NULL;
 
if (!have_governor_per_policy())
-- 
2.20.1





[PATCH 5.1 101/405] rtc: stm32: manage the get_irq probe defer case

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit cf612c5949aca2bd81a1e28688957c8149ea2693 ]

Manage the -EPROBE_DEFER error case for the wake IRQ.

Signed-off-by: Fabien Dessenne 
Acked-by: Amelie Delaunay 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin 
---
 drivers/rtc/rtc-stm32.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/rtc-stm32.c b/drivers/rtc/rtc-stm32.c
index c5908cfea2340..8e6c9b3bcc29a 100644
--- a/drivers/rtc/rtc-stm32.c
+++ b/drivers/rtc/rtc-stm32.c
@@ -788,11 +788,14 @@ static int stm32_rtc_probe(struct platform_device *pdev)
ret = device_init_wakeup(>dev, true);
if (rtc->data->has_wakeirq) {
rtc->wakeirq_alarm = platform_get_irq(pdev, 1);
-   if (rtc->wakeirq_alarm <= 0)
-   ret = rtc->wakeirq_alarm;
-   else
+   if (rtc->wakeirq_alarm > 0) {
ret = dev_pm_set_dedicated_wake_irq(>dev,
rtc->wakeirq_alarm);
+   } else {
+   ret = rtc->wakeirq_alarm;
+   if (rtc->wakeirq_alarm == -EPROBE_DEFER)
+   goto err;
+   }
}
if (ret)
dev_warn(>dev, "alarm can't wake up the system: %d", ret);
-- 
2.20.1





[PATCH 5.1 113/405] net: hns3: use atomic_t replace u32 for arqs count

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 30780a8b1677e7409b32ae52a9a84f7d41ae6b43 ]

Since irq handler and mailbox task will both update arq's count,
so arq's count should use atomic_t instead of u32, otherwise
its value may go wrong finally.

Fixes: 07a0556a3a73 ("net: hns3: Changes to support ARQ(Asynchronous Receive 
Queue)")
Signed-off-by: Huazhong Tan 
Signed-off-by: Peng Li 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h  | 2 +-
 drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 2 +-
 drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c | 7 ---
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h 
b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
index 299b277bc7ae9..589b7ee32bff8 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
@@ -107,7 +107,7 @@ struct hclgevf_mbx_arq_ring {
struct hclgevf_dev *hdev;
u32 head;
u32 tail;
-   u32 count;
+   atomic_t count;
u16 msg_q[HCLGE_MBX_MAX_ARQ_MSG_NUM][HCLGE_MBX_MAX_ARQ_MSG_SIZE];
 };
 
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
index 9441b453d38df..9a0a501908aec 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
@@ -327,7 +327,7 @@ int hclgevf_cmd_init(struct hclgevf_dev *hdev)
hdev->arq.hdev = hdev;
hdev->arq.head = 0;
hdev->arq.tail = 0;
-   hdev->arq.count = 0;
+   atomic_set(>arq.count, 0);
hdev->hw.cmq.csq.next_to_clean = 0;
hdev->hw.cmq.csq.next_to_use = 0;
hdev->hw.cmq.crq.next_to_clean = 0;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c
index 7dc3c9f79169f..4f2c77283cb43 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c
@@ -208,7 +208,8 @@ void hclgevf_mbx_handler(struct hclgevf_dev *hdev)
/* we will drop the async msg if we find ARQ as full
 * and continue with next message
 */
-   if (hdev->arq.count >= HCLGE_MBX_MAX_ARQ_MSG_NUM) {
+   if (atomic_read(>arq.count) >=
+   HCLGE_MBX_MAX_ARQ_MSG_NUM) {
dev_warn(>pdev->dev,
 "Async Q full, dropping msg(%d)\n",
 req->msg[1]);
@@ -220,7 +221,7 @@ void hclgevf_mbx_handler(struct hclgevf_dev *hdev)
memcpy(_q[0], req->msg,
   HCLGE_MBX_MAX_ARQ_MSG_SIZE * sizeof(u16));
hclge_mbx_tail_ptr_move_arq(hdev->arq);
-   hdev->arq.count++;
+   atomic_inc(>arq.count);
 
hclgevf_mbx_task_schedule(hdev);
 
@@ -308,7 +309,7 @@ void hclgevf_mbx_async_handler(struct hclgevf_dev *hdev)
}
 
hclge_mbx_head_ptr_move_arq(hdev->arq);
-   hdev->arq.count--;
+   atomic_dec(>arq.count);
msg_q = hdev->arq.msg_q[hdev->arq.head];
}
 }
-- 
2.20.1





[PATCH 5.1 115/405] mac80211/cfg80211: update bss channel on channel switch

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 5dc8cdce1d722c733f8c7af14c5fb595cfedbfa8 ]

FullMAC STAs have no way to update bss channel after CSA channel switch
completion. As a result, user-space tools may provide inconsistent
channel info. For instance, consider the following two commands:
$ sudo iw dev wlan0 link
$ sudo iw dev wlan0 info
The latter command gets channel info from the hardware, so most probably
its output will be correct. However the former command gets channel info
from scan cache, so its output will contain outdated channel info.
In fact, current bss channel info will not be updated until the
next [re-]connect.

Note that mac80211 STAs have a workaround for this, but it requires
access to internal cfg80211 data, see ieee80211_chswitch_work:

/* XXX: shouldn't really modify cfg80211-owned data! */
ifmgd->associated->channel = sdata->csa_chandef.chan;

This patch suggests to convert mac80211 workaround into cfg80211 behavior
and to update current bss channel in cfg80211_ch_switch_notify.

Signed-off-by: Sergey Matyukevich 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
---
 net/mac80211/mlme.c| 3 ---
 net/wireless/nl80211.c | 5 +
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 2dbcf5d5512ef..b7a9fe3d5fcb7 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1188,9 +1188,6 @@ static void ieee80211_chswitch_work(struct work_struct 
*work)
goto out;
}
 
-   /* XXX: shouldn't really modify cfg80211-owned data! */
-   ifmgd->associated->channel = sdata->csa_chandef.chan;
-
ifmgd->csa_waiting_bcn = true;
 
ieee80211_sta_reset_beacon_monitor(sdata);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 47e30a58566c2..d2a7459a5da43 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -15727,6 +15727,11 @@ void cfg80211_ch_switch_notify(struct net_device *dev,
 
wdev->chandef = *chandef;
wdev->preset_chandef = *chandef;
+
+   if (wdev->iftype == NL80211_IFTYPE_STATION &&
+   !WARN_ON(!wdev->current_bss))
+   wdev->current_bss->pub.channel = chandef->chan;
+
nl80211_ch_switch_notify(rdev, dev, chandef, GFP_KERNEL,
 NL80211_CMD_CH_SWITCH_NOTIFY, 0);
 }
-- 
2.20.1





[PATCH 5.1 108/405] net: hns3: fix pause configure fail problem

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit fba2efdae8b4f998f66a2ff4c9f0575e1c4bbc40 ]

When configure pause, current implementation returns directly
after setup PFC without setup BP, which is not sufficient.

So this patch fixes it, only return while setting PFC failed.

Fixes: 44e59e375bf7 ("net: hns3: do not return GE PFC setting err when 
initializing")
Signed-off-by: Huazhong Tan 
Signed-off-by: Peng Li 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
index aafc69f4bfdd6..a7bbb6d3091a6 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
@@ -1331,8 +1331,11 @@ int hclge_pause_setup_hw(struct hclge_dev *hdev, bool 
init)
ret = hclge_pfc_setup_hw(hdev);
if (init && ret == -EOPNOTSUPP)
dev_warn(>pdev->dev, "GE MAC does not support pfc\n");
-   else
+   else if (ret) {
+   dev_err(>pdev->dev, "config pfc failed! ret = %d\n",
+   ret);
return ret;
+   }
 
return hclge_tm_bp_setup(hdev);
 }
-- 
2.20.1





[PATCH 5.1 119/405] regulator: core: Actually put the gpiod after use

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 78927aa40bc82f32de07323ddc1c9de07ac68180 ]

I went to great lengths to hand over the management of the GPIO
descriptors to the regulator core, and some stray rebased
oneliner in the old patch must have been assuming the devices
were still doing devres management of it.

We handed the management over to the regulator core, so of
course the regulator core shall issue gpiod_put() when done.

Sorry for the descriptor leak.

Fixes: 541d052d7215 ("regulator: core: Only support passing enable GPIO 
descriptors")
Signed-off-by: Linus Walleij 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 drivers/regulator/core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 968dcd9d7a070..6da41207e479a 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2256,6 +2256,7 @@ static void regulator_ena_gpio_free(struct regulator_dev 
*rdev)
if (pin->gpiod == rdev->ena_pin->gpiod) {
if (pin->request_count <= 1) {
pin->request_count = 0;
+   gpiod_put(pin->gpiod);
list_del(>list);
kfree(pin);
rdev->ena_pin = NULL;
-- 
2.20.1





[PATCH 5.1 116/405] drm: prefix header search paths with $(srctree)/

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 43068cb7ba1f6ceb1523e947c84002b2a61fd6d4 ]

Currently, the Kbuild core manipulates header search paths in a crazy
way [1].

To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consistent, and finally get rid of the gross hacks.

Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
("kbuild: do not drop -I without parameter").

[1]: https://patchwork.kernel.org/patch/9632347/

Signed-off-by: Masahiro Yamada 
Reviewed-by: Sam Ravnborg 
Reviewed-by: James Qian Wang (Arm Technology China) 
Acked-by: Liviu Dudau 
Signed-off-by: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/1553859161-2628-1-git-send-email-yamada.masah...@socionext.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
 drivers/gpu/drm/arm/display/komeda/Makefile | 4 ++--
 drivers/gpu/drm/i915/gvt/Makefile   | 2 +-
 drivers/gpu/drm/msm/Makefile| 6 +++---
 drivers/gpu/drm/nouveau/Kbuild  | 8 
 5 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 466da5954a682..62bf9da25e4b3 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -23,7 +23,7 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-FULL_AMD_PATH=$(src)/..
+FULL_AMD_PATH=$(srctree)/$(src)/..
 DISPLAY_FOLDER_NAME=display
 FULL_AMD_DISPLAY_PATH = $(FULL_AMD_PATH)/$(DISPLAY_FOLDER_NAME)
 
diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile 
b/drivers/gpu/drm/arm/display/komeda/Makefile
index 1b875e5dc0f6f..a72e30c0e03d3 100644
--- a/drivers/gpu/drm/arm/display/komeda/Makefile
+++ b/drivers/gpu/drm/arm/display/komeda/Makefile
@@ -1,8 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0
 
 ccflags-y := \
-   -I$(src)/../include \
-   -I$(src)
+   -I $(srctree)/$(src)/../include \
+   -I $(srctree)/$(src)
 
 komeda-y := \
komeda_drv.o \
diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
b/drivers/gpu/drm/i915/gvt/Makefile
index 271fb46d4dd0d..ea8324abc784a 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -5,5 +5,5 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o 
trace_points.o firmware.o \
execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o 
debugfs.o \
fb_decoder.o dmabuf.o page_track.o
 
-ccflags-y  += -I$(src) -I$(src)/$(GVT_DIR)
+ccflags-y  += -I $(srctree)/$(src) -I 
$(srctree)/$(src)/$(GVT_DIR)/
 i915-y += $(addprefix $(GVT_DIR)/, 
$(GVT_SOURCE))
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 56a70c74af4ed..b7b1ebdc81902 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
-ccflags-y := -Idrivers/gpu/drm/msm
-ccflags-y += -Idrivers/gpu/drm/msm/disp/dpu1
-ccflags-$(CONFIG_DRM_MSM_DSI) += -Idrivers/gpu/drm/msm/dsi
+ccflags-y := -I $(srctree)/$(src)
+ccflags-y += -I $(srctree)/$(src)/disp/dpu1
+ccflags-$(CONFIG_DRM_MSM_DSI) += -I $(srctree)/$(src)/dsi
 
 msm-y := \
adreno/adreno_device.o \
diff --git a/drivers/gpu/drm/nouveau/Kbuild b/drivers/gpu/drm/nouveau/Kbuild
index 581404e6544d4..378c5dd692b0b 100644
--- a/drivers/gpu/drm/nouveau/Kbuild
+++ b/drivers/gpu/drm/nouveau/Kbuild
@@ -1,7 +1,7 @@
-ccflags-y += -I$(src)/include
-ccflags-y += -I$(src)/include/nvkm
-ccflags-y += -I$(src)/nvkm
-ccflags-y += -I$(src)
+ccflags-y += -I $(srctree)/$(src)/include
+ccflags-y += -I $(srctree)/$(src)/include/nvkm
+ccflags-y += -I $(srctree)/$(src)/nvkm
+ccflags-y += -I $(srctree)/$(src)
 
 # NVKM - HW resource manager
 #- code also used by various userspace tools/tests
-- 
2.20.1





linux-next: build warning after merge of the akpm-current tree

2019-05-29 Thread Stephen Rothwell
Hi all,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

net/tipc/sysctl.c:42:12: warning: 'one' defined but not used [-Wunused-variable]
 static int one = 1;
^~~
net/tipc/sysctl.c:41:12: warning: 'zero' defined but not used 
[-Wunused-variable]
 static int zero;
^~~~

Introduced by commit

  6a33853c5773 ("proc/sysctl: add shared variables for range check")

-- 
Cheers,
Stephen Rothwell


pgpzBtms8ZaMe.pgp
Description: OpenPGP digital signature


[PATCH 5.1 093/405] scsi: qla2xxx: Avoid that lockdep complains about unsafe locking in tcm_qla2xxx_close_session()

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit d4023db71108375e4194e92730ba0d32d7f07813 ]

This patch avoids that lockdep reports the following warning:

=
WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
5.1.0-rc1-dbg+ #11 Tainted: GW
-
rmdir/1478 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
e7ac4607 (&(>k_lock)->rlock){+.+.}, at: klist_next+0x43/0x1d0

and this task is already holding:
cf0baf5e (&(>tgt.sess_lock)->rlock){-...}, at: 
tcm_qla2xxx_close_session+0x57/0xb0 [tcm_qla2xxx]
which would create a new lock dependency:
 (&(>tgt.sess_lock)->rlock){-...} -> (&(>k_lock)->rlock){+.+.}

but this new dependency connects a HARDIRQ-irq-safe lock:
 (&(>tgt.sess_lock)->rlock){-...}

... which became HARDIRQ-irq-safe at:
  lock_acquire+0xe3/0x200
  _raw_spin_lock_irqsave+0x3d/0x60
  qla2x00_fcport_event_handler+0x1f3d/0x22b0 [qla2xxx]
  qla2x00_async_login_sp_done+0x1dc/0x1f0 [qla2xxx]
  qla24xx_process_response_queue+0xa37/0x10e0 [qla2xxx]
  qla24xx_msix_rsp_q+0x79/0xf0 [qla2xxx]
  __handle_irq_event_percpu+0x79/0x3c0
  handle_irq_event_percpu+0x70/0xf0
  handle_irq_event+0x5a/0x8b
  handle_edge_irq+0x12c/0x310
  handle_irq+0x192/0x20a
  do_IRQ+0x73/0x160
  ret_from_intr+0x0/0x1d
  default_idle+0x23/0x1f0
  arch_cpu_idle+0x15/0x20
  default_idle_call+0x35/0x40
  do_idle+0x2bb/0x2e0
  cpu_startup_entry+0x1d/0x20
  start_secondary+0x24d/0x2d0
  secondary_startup_64+0xa4/0xb0

to a HARDIRQ-irq-unsafe lock:
 (&(>k_lock)->rlock){+.+.}

... which became HARDIRQ-irq-unsafe at:
...
  lock_acquire+0xe3/0x200
  _raw_spin_lock+0x32/0x50
  klist_add_tail+0x33/0xb0
  device_add+0x7f4/0xb60
  device_create_groups_vargs+0x11c/0x150
  device_create_with_groups+0x89/0xb0
  vtconsole_class_init+0xb2/0x124
  do_one_initcall+0xc5/0x3ce
  kernel_init_freeable+0x295/0x32e
  kernel_init+0x11/0x11b
  ret_from_fork+0x3a/0x50

other info that might help us debug this:

 Possible interrupt unsafe locking scenario:

   CPU0CPU1
   
  lock(&(>k_lock)->rlock);
   local_irq_disable();
   lock(&(>tgt.sess_lock)->rlock);
   lock(&(>k_lock)->rlock);
  
lock(&(>tgt.sess_lock)->rlock);

 *** DEADLOCK ***

4 locks held by rmdir/1478:
 #0: 2c7f1ba4 (sb_writers#10){.+.+}, at: mnt_want_write+0x32/0x70
 #1: c85eb147 (_group_class[depth - 1]#2/1){+.+.}, at: 
do_rmdir+0x217/0x2d0
 #2: 2b164d6f (>s_type->i_mutex_key#13){}, at: 
vfs_rmdir+0x7e/0x1d0
 #3: cf0baf5e (&(>tgt.sess_lock)->rlock){-...}, at: 
tcm_qla2xxx_close_session+0x57/0xb0 [tcm_qla2xxx]

the dependencies between HARDIRQ-irq-safe lock and the holding lock:
-> (&(>tgt.sess_lock)->rlock){-...} ops: 127 {
   IN-HARDIRQ-W at:
lock_acquire+0xe3/0x200
_raw_spin_lock_irqsave+0x3d/0x60
qla2x00_fcport_event_handler+0x1f3d/0x22b0 [qla2xxx]
qla2x00_async_login_sp_done+0x1dc/0x1f0 [qla2xxx]
qla24xx_process_response_queue+0xa37/0x10e0 [qla2xxx]
qla24xx_msix_rsp_q+0x79/0xf0 [qla2xxx]
__handle_irq_event_percpu+0x79/0x3c0
handle_irq_event_percpu+0x70/0xf0
handle_irq_event+0x5a/0x8b
handle_edge_irq+0x12c/0x310
handle_irq+0x192/0x20a
do_IRQ+0x73/0x160
ret_from_intr+0x0/0x1d
default_idle+0x23/0x1f0
arch_cpu_idle+0x15/0x20
default_idle_call+0x35/0x40
do_idle+0x2bb/0x2e0
cpu_startup_entry+0x1d/0x20
start_secondary+0x24d/0x2d0
secondary_startup_64+0xa4/0xb0
   INITIAL USE at:
   lock_acquire+0xe3/0x200
   _raw_spin_lock_irqsave+0x3d/0x60
   qla2x00_loop_resync+0xb3d/0x2690 [qla2xxx]
   qla2x00_do_dpc+0xcee/0xf30 [qla2xxx]
   kthread+0x1d2/0x1f0
   ret_from_fork+0x3a/0x50
 }
 ... key  at: [] __key.62804+0x0/0xfff7e900 
[qla2xxx]
 ... acquired at:
   __lock_acquire+0x11ed/0x1b60
   lock_acquire+0xe3/0x200
   _raw_spin_lock_irqsave+0x3d/0x60
   klist_next+0x43/0x1d0
   device_for_each_child+0x96/0x110
   scsi_target_block+0x3c/0x40 [scsi_mod]
   fc_remote_port_delete+0xe7/0x1c0 [scsi_transport_fc]
   qla2x00_mark_device_lost+0x4d3/0x500 [qla2xxx]
   qlt_unreg_sess+0x104/0x2c0 [qla2xxx]
   tcm_qla2xxx_close_session+0xa2/0xb0 [tcm_qla2xxx]
   target_shutdown_sessions+0x17b/0x190 [target_core_mod]
   core_tpg_del_initiator_node_acl+0xf3/0x1f0 [target_core_mod]
   target_fabric_nacl_base_release+0x25/0x30 [target_core_mod]
   config_item_release+0x9f/0x120 [configfs]
   config_item_put+0x29/0x2b [configfs]
   configfs_rmdir+0x3d2/0x520 

[PATCH 5.1 061/405] blk-mq: split blk_mq_alloc_and_init_hctx into two parts

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 7c6c5b7c9186e3fb5b10afb8e5f710ae661144c6 ]

Split blk_mq_alloc_and_init_hctx into two parts, and one is
blk_mq_alloc_hctx() for allocating all hctx resources, another
is blk_mq_init_hctx() for initializing hctx, which serves as
counter-part of blk_mq_exit_hctx().

Cc: Dongli Zhang 
Cc: James Smart 
Cc: Bart Van Assche 
Cc: linux-s...@vger.kernel.org
Cc: Martin K . Petersen 
Cc: Christoph Hellwig 
Cc: James E . J . Bottomley 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Christoph Hellwig 
Tested-by: James Smart 
Signed-off-by: Ming Lei 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 block/blk-mq.c | 139 ++---
 1 file changed, 75 insertions(+), 64 deletions(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index b0e5e67e20a28..8a41cc5974fe1 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2284,15 +2284,65 @@ static void blk_mq_exit_hw_queues(struct request_queue 
*q,
}
 }
 
+static int blk_mq_hw_ctx_size(struct blk_mq_tag_set *tag_set)
+{
+   int hw_ctx_size = sizeof(struct blk_mq_hw_ctx);
+
+   BUILD_BUG_ON(ALIGN(offsetof(struct blk_mq_hw_ctx, srcu),
+  __alignof__(struct blk_mq_hw_ctx)) !=
+sizeof(struct blk_mq_hw_ctx));
+
+   if (tag_set->flags & BLK_MQ_F_BLOCKING)
+   hw_ctx_size += sizeof(struct srcu_struct);
+
+   return hw_ctx_size;
+}
+
 static int blk_mq_init_hctx(struct request_queue *q,
struct blk_mq_tag_set *set,
struct blk_mq_hw_ctx *hctx, unsigned hctx_idx)
 {
-   int node;
+   hctx->queue_num = hctx_idx;
+
+   cpuhp_state_add_instance_nocalls(CPUHP_BLK_MQ_DEAD, >cpuhp_dead);
+
+   hctx->tags = set->tags[hctx_idx];
+
+   if (set->ops->init_hctx &&
+   set->ops->init_hctx(hctx, set->driver_data, hctx_idx))
+   goto unregister_cpu_notifier;
 
-   node = hctx->numa_node;
+   if (blk_mq_init_request(set, hctx->fq->flush_rq, hctx_idx,
+   hctx->numa_node))
+   goto exit_hctx;
+   return 0;
+
+ exit_hctx:
+   if (set->ops->exit_hctx)
+   set->ops->exit_hctx(hctx, hctx_idx);
+ unregister_cpu_notifier:
+   blk_mq_remove_cpuhp(hctx);
+   return -1;
+}
+
+static struct blk_mq_hw_ctx *
+blk_mq_alloc_hctx(struct request_queue *q, struct blk_mq_tag_set *set,
+   int node)
+{
+   struct blk_mq_hw_ctx *hctx;
+   gfp_t gfp = GFP_NOIO | __GFP_NOWARN | __GFP_NORETRY;
+
+   hctx = kzalloc_node(blk_mq_hw_ctx_size(set), gfp, node);
+   if (!hctx)
+   goto fail_alloc_hctx;
+
+   if (!zalloc_cpumask_var_node(>cpumask, gfp, node))
+   goto free_hctx;
+
+   atomic_set(>nr_active, 0);
if (node == NUMA_NO_NODE)
-   node = hctx->numa_node = set->numa_node;
+   node = set->numa_node;
+   hctx->numa_node = node;
 
INIT_DELAYED_WORK(>run_work, blk_mq_run_work_fn);
spin_lock_init(>lock);
@@ -2300,58 +2350,45 @@ static int blk_mq_init_hctx(struct request_queue *q,
hctx->queue = q;
hctx->flags = set->flags & ~BLK_MQ_F_TAG_SHARED;
 
-   cpuhp_state_add_instance_nocalls(CPUHP_BLK_MQ_DEAD, >cpuhp_dead);
-
-   hctx->tags = set->tags[hctx_idx];
-
/*
 * Allocate space for all possible cpus to avoid allocation at
 * runtime
 */
hctx->ctxs = kmalloc_array_node(nr_cpu_ids, sizeof(void *),
-   GFP_NOIO | __GFP_NOWARN | __GFP_NORETRY, node);
+   gfp, node);
if (!hctx->ctxs)
-   goto unregister_cpu_notifier;
+   goto free_cpumask;
 
if (sbitmap_init_node(>ctx_map, nr_cpu_ids, ilog2(8),
-   GFP_NOIO | __GFP_NOWARN | __GFP_NORETRY, node))
+   gfp, node))
goto free_ctxs;
-
hctx->nr_ctx = 0;
 
spin_lock_init(>dispatch_wait_lock);
init_waitqueue_func_entry(>dispatch_wait, blk_mq_dispatch_wake);
INIT_LIST_HEAD(>dispatch_wait.entry);
 
-   if (set->ops->init_hctx &&
-   set->ops->init_hctx(hctx, set->driver_data, hctx_idx))
-   goto free_bitmap;
-
hctx->fq = blk_alloc_flush_queue(q, hctx->numa_node, set->cmd_size,
-   GFP_NOIO | __GFP_NOWARN | __GFP_NORETRY);
+   gfp);
if (!hctx->fq)
-   goto exit_hctx;
-
-   if (blk_mq_init_request(set, hctx->fq->flush_rq, hctx_idx, node))
-   goto free_fq;
+   goto free_bitmap;
 
if (hctx->flags & BLK_MQ_F_BLOCKING)
init_srcu_struct(hctx->srcu);
+   blk_mq_hctx_kobj_init(hctx);
 
-   return 0;
+   return hctx;
 
- free_fq:
-   blk_free_flush_queue(hctx->fq);
- exit_hctx:
-   if (set->ops->exit_hctx)
-   set->ops->exit_hctx(hctx, hctx_idx);
  free_bitmap:
sbitmap_free(>ctx_map);
 

[PATCH 5.1 125/405] nvme: set 0 capacity if namespace block size exceeds PAGE_SIZE

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 01fa017484ad98fccdeaab32db0077c574b6bd6f ]

If our target exposed a namespace with a block size that is greater
than PAGE_SIZE, set 0 capacity on the namespace as we do not support it.

This issue encountered when the nvmet namespace was backed by a tempfile.

Signed-off-by: Sagi Grimberg 
Reviewed-by: Keith Busch 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/host/core.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 2c43e12b70afc..8782d86a8ca38 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1591,6 +1591,10 @@ static void nvme_update_disk_info(struct gendisk *disk,
sector_t capacity = le64_to_cpup(>nsze) << (ns->lba_shift - 9);
unsigned short bs = 1 << ns->lba_shift;
 
+   if (ns->lba_shift > PAGE_SHIFT) {
+   /* unsupported block size, set capacity to 0 later */
+   bs = (1 << 9);
+   }
blk_mq_freeze_queue(disk->queue);
blk_integrity_unregister(disk);
 
@@ -1601,7 +1605,8 @@ static void nvme_update_disk_info(struct gendisk *disk,
if (ns->ms && !ns->ext &&
(ns->ctrl->ops->flags & NVME_F_METADATA_SUPPORTED))
nvme_init_integrity(disk, ns->ms, ns->pi_type);
-   if (ns->ms && !nvme_ns_has_pi(ns) && !blk_get_integrity(disk))
+   if ((ns->ms && !nvme_ns_has_pi(ns) && !blk_get_integrity(disk)) ||
+   ns->lba_shift > PAGE_SHIFT)
capacity = 0;
 
set_capacity(disk, capacity);
-- 
2.20.1





[PATCH 5.1 124/405] net: cw1200: fix a NULL pointer dereference

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 0ed2a005347400500a39ea7c7318f1fea57fb3ca ]

In case create_singlethread_workqueue fails, the fix free the
hardware and returns NULL to avoid NULL pointer dereference.

Signed-off-by: Kangjie Lu 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/st/cw1200/main.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/wireless/st/cw1200/main.c 
b/drivers/net/wireless/st/cw1200/main.c
index 90dc979f260b6..c1608f0bf6d01 100644
--- a/drivers/net/wireless/st/cw1200/main.c
+++ b/drivers/net/wireless/st/cw1200/main.c
@@ -345,6 +345,11 @@ static struct ieee80211_hw *cw1200_init_common(const u8 
*macaddr,
mutex_init(>wsm_cmd_mux);
mutex_init(>conf_mutex);
priv->workqueue = create_singlethread_workqueue("cw1200_wq");
+   if (!priv->workqueue) {
+   ieee80211_free_hw(hw);
+   return NULL;
+   }
+
sema_init(>scan.lock, 1);
INIT_WORK(>scan.work, cw1200_scan_work);
INIT_DELAYED_WORK(>scan.probe_work, cw1200_probe_work);
-- 
2.20.1





[PATCH 5.1 114/405] dmaengine: pl330: _stop: clear interrupt status

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 2da254cc7908105a60a6bb219d18e8dced03dcb9 ]

This patch kill instructs the DMAC to immediately terminate
execution of a thread. and then clear the interrupt status,
at last, stop generating interrupts for DMA_SEV. to guarantee
the next dma start is clean. otherwise, one interrupt maybe leave
to next start and make some mistake.

we can reporduce the problem as follows:

DMASEV: modify the event-interrupt resource, and if the INTEN sets
function as interrupt, the DMAC will set irq HIGH to
generate interrupt. write INTCLR to clear interrupt.

DMA EXECUTING INSTRUCTS DMA TERMINATE
|   |
|   |
   ..._stop
|   |
|   spin_lock_irqsave
 DMASEV |
|   |
|   mask INTEN
|   |
|DMAKILL
|   |
|   spin_unlock_irqrestore

in above case, a interrupt was left, and if we unmask INTEN, the DMAC
will set irq HIGH to generate interrupt.

to fix this, do as follows:

DMA EXECUTING INSTRUCTS DMA TERMINATE
|   |
|   |
   ..._stop
|   |
|   spin_lock_irqsave
 DMASEV |
|   |
|DMAKILL
|   |
|  clear INTCLR
|   mask INTEN
|   |
|   spin_unlock_irqrestore

Signed-off-by: Sugar Zhang 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/dma/pl330.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index eec79fdf27a5b..56695ffb5d377 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -966,6 +966,7 @@ static void _stop(struct pl330_thread *thrd)
 {
void __iomem *regs = thrd->dmac->base;
u8 insn[6] = {0, 0, 0, 0, 0, 0};
+   u32 inten = readl(regs + INTEN);
 
if (_state(thrd) == PL330_STATE_FAULT_COMPLETING)
UNTIL(thrd, PL330_STATE_FAULTING | PL330_STATE_KILLING);
@@ -978,10 +979,13 @@ static void _stop(struct pl330_thread *thrd)
 
_emit_KILL(0, insn);
 
-   /* Stop generating interrupts for SEV */
-   writel(readl(regs + INTEN) & ~(1 << thrd->ev), regs + INTEN);
-
_execute_DBGINSN(thrd, insn, is_manager(thrd));
+
+   /* clear the event */
+   if (inten & (1 << thrd->ev))
+   writel(1 << thrd->ev, regs + INTCLR);
+   /* Stop generating interrupts for SEV */
+   writel(inten & ~(1 << thrd->ev), regs + INTEN);
 }
 
 /* Start doing req 'idx' of thread 'thrd' */
-- 
2.20.1





[PATCH 5.1 106/405] net: ethernet: ti: cpsw: fix allmulti cfg in dual_mac mode

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 06095f34f8a0a2c4c83a19514c272699edd5f80b ]

Now CPSW ALE will set/clean Host port bit in Unregistered Multicast Flood
Mask (UNREG_MCAST_FLOOD_MASK) for every VLAN without checking if this port
belongs to VLAN or not when ALLMULTI mode flag is set for nedev. This is
working in non dual_mac mode, but in dual_mac - it causes
enabling/disabling ALLMULTI flag for both ports.

Hence fix it by adding additional parameter to cpsw_ale_set_allmulti() to
specify ALE port number for which ALLMULTI has to be enabled and check if
port belongs to VLAN before modifying UNREG_MCAST_FLOOD_MASK.

Signed-off-by: Grygorii Strashko 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/ti/cpsw.c | 12 +---
 drivers/net/ethernet/ti/cpsw_ale.c | 19 ++-
 drivers/net/ethernet/ti/cpsw_ale.h |  3 +--
 3 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index a591583d120e1..dd12b73a88530 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -800,12 +800,17 @@ static int cpsw_purge_all_mc(struct net_device *ndev, 
const u8 *addr, int num)
 
 static void cpsw_ndo_set_rx_mode(struct net_device *ndev)
 {
-   struct cpsw_common *cpsw = ndev_to_cpsw(ndev);
+   struct cpsw_priv *priv = netdev_priv(ndev);
+   struct cpsw_common *cpsw = priv->cpsw;
+   int slave_port = -1;
+
+   if (cpsw->data.dual_emac)
+   slave_port = priv->emac_port + 1;
 
if (ndev->flags & IFF_PROMISC) {
/* Enable promiscuous mode */
cpsw_set_promiscious(ndev, true);
-   cpsw_ale_set_allmulti(cpsw->ale, IFF_ALLMULTI);
+   cpsw_ale_set_allmulti(cpsw->ale, IFF_ALLMULTI, slave_port);
return;
} else {
/* Disable promiscuous mode */
@@ -813,7 +818,8 @@ static void cpsw_ndo_set_rx_mode(struct net_device *ndev)
}
 
/* Restore allmulti on vlans if necessary */
-   cpsw_ale_set_allmulti(cpsw->ale, ndev->flags & IFF_ALLMULTI);
+   cpsw_ale_set_allmulti(cpsw->ale,
+ ndev->flags & IFF_ALLMULTI, slave_port);
 
/* add/remove mcast address either for real netdev or for vlan */
__hw_addr_ref_sync_dev(>mc, ndev, cpsw_add_mc_addr,
diff --git a/drivers/net/ethernet/ti/cpsw_ale.c 
b/drivers/net/ethernet/ti/cpsw_ale.c
index 798c989d5d934..b3d9591b4824a 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.c
+++ b/drivers/net/ethernet/ti/cpsw_ale.c
@@ -482,24 +482,25 @@ int cpsw_ale_del_vlan(struct cpsw_ale *ale, u16 vid, int 
port_mask)
 }
 EXPORT_SYMBOL_GPL(cpsw_ale_del_vlan);
 
-void cpsw_ale_set_allmulti(struct cpsw_ale *ale, int allmulti)
+void cpsw_ale_set_allmulti(struct cpsw_ale *ale, int allmulti, int port)
 {
u32 ale_entry[ALE_ENTRY_WORDS];
-   int type, idx;
int unreg_mcast = 0;
-
-   /* Only bother doing the work if the setting is actually changing */
-   if (ale->allmulti == allmulti)
-   return;
-
-   /* Remember the new setting to check against next time */
-   ale->allmulti = allmulti;
+   int type, idx;
 
for (idx = 0; idx < ale->params.ale_entries; idx++) {
+   int vlan_members;
+
cpsw_ale_read(ale, idx, ale_entry);
type = cpsw_ale_get_entry_type(ale_entry);
if (type != ALE_TYPE_VLAN)
continue;
+   vlan_members =
+   cpsw_ale_get_vlan_member_list(ale_entry,
+ ale->vlan_field_bits);
+
+   if (port != -1 && !(vlan_members & BIT(port)))
+   continue;
 
unreg_mcast =
cpsw_ale_get_vlan_unreg_mcast(ale_entry,
diff --git a/drivers/net/ethernet/ti/cpsw_ale.h 
b/drivers/net/ethernet/ti/cpsw_ale.h
index cd07a3e96d576..1fe196d8a5e42 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.h
+++ b/drivers/net/ethernet/ti/cpsw_ale.h
@@ -37,7 +37,6 @@ struct cpsw_ale {
struct cpsw_ale_params  params;
struct timer_list   timer;
unsigned long   ageout;
-   int allmulti;
u32 version;
/* These bits are different on NetCP NU Switch ALE */
u32 port_mask_bits;
@@ -116,7 +115,7 @@ int cpsw_ale_del_mcast(struct cpsw_ale *ale, const u8 
*addr, int port_mask,
 int cpsw_ale_add_vlan(struct cpsw_ale *ale, u16 vid, int port, int untag,
int reg_mcast, int unreg_mcast);
 int cpsw_ale_del_vlan(struct cpsw_ale *ale, u16 vid, int port);
-void cpsw_ale_set_allmulti(struct cpsw_ale *ale, int allmulti);
+void cpsw_ale_set_allmulti(struct cpsw_ale *ale, int allmulti, int port);
 
 int cpsw_ale_control_get(struct cpsw_ale *ale, int port, int control);
 int cpsw_ale_control_set(struct cpsw_ale *ale, int port,
-- 

[PATCH 5.1 104/405] ALSA: hda: fix unregister device twice on ASoC driver

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 4d95c51776b2edb4d4ebcea00b6e5a1fe538ce66 ]

snd_hda_codec_device_new() is used by both legacy HDA and ASoC
driver. However, we will call snd_hdac_device_unregister() in
snd_hdac_ext_bus_device_remove() for ASoC device. This patch uses
the type flag in hdac_device struct to determine is it a ASoC device
or legacy HDA device and call snd_hdac_device_unregister() in
snd_hda_codec_dev_free() only if it is a legacy HDA device.

Signed-off-by: Bard liao 
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin 
---
 sound/pci/hda/hda_codec.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 701a69d856f5f..b20eb7fc83eb2 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -832,7 +832,13 @@ static int snd_hda_codec_dev_free(struct snd_device 
*device)
struct hda_codec *codec = device->device_data;
 
codec->in_freeing = 1;
-   snd_hdac_device_unregister(>core);
+   /*
+* snd_hda_codec_device_new() is used by legacy HDA and ASoC driver.
+* We can't unregister ASoC device since it will be unregistered in
+* snd_hdac_ext_bus_device_remove().
+*/
+   if (codec->core.type == HDA_DEV_LEGACY)
+   snd_hdac_device_unregister(>core);
codec_display_power(codec, false);
put_device(hda_codec_dev(codec));
return 0;
-- 
2.20.1





[PATCH 5.1 111/405] s390: qeth: address type mismatch warning

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 46b83629dede262315aa82179d105581f11763b6 ]

clang produces a harmless warning for each use for the qeth_adp_supported
macro:

drivers/s390/net/qeth_l2_main.c:559:31: warning: implicit conversion from 
enumeration type 'enum qeth_ipa_setadp_cmd' to
  different enumeration type 'enum qeth_ipa_funcs' [-Wenum-conversion]
if (qeth_adp_supported(card, IPA_SETADP_SET_PROMISC_MODE))
~^~~~
drivers/s390/net/qeth_core.h:179:41: note: expanded from macro 
'qeth_adp_supported'
qeth_is_ipa_supported(>options.adp, f)
~  ^

Add a version of this macro that uses the correct types, and
remove the unused qeth_adp_enabled() macro that has the same
problem.

Reviewed-by: Nathan Chancellor 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Julian Wiedmann 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/s390/net/qeth_core.h | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/s390/net/qeth_core.h b/drivers/s390/net/qeth_core.h
index c851cf6e01c43..d603dfea97ab2 100644
--- a/drivers/s390/net/qeth_core.h
+++ b/drivers/s390/net/qeth_core.h
@@ -163,6 +163,12 @@ struct qeth_vnicc_info {
bool rx_bcast_enabled;
 };
 
+static inline int qeth_is_adp_supported(struct qeth_ipa_info *ipa,
+   enum qeth_ipa_setadp_cmd func)
+{
+   return (ipa->supported_funcs & func);
+}
+
 static inline int qeth_is_ipa_supported(struct qeth_ipa_info *ipa,
enum qeth_ipa_funcs func)
 {
@@ -176,9 +182,7 @@ static inline int qeth_is_ipa_enabled(struct qeth_ipa_info 
*ipa,
 }
 
 #define qeth_adp_supported(c, f) \
-   qeth_is_ipa_supported(>options.adp, f)
-#define qeth_adp_enabled(c, f) \
-   qeth_is_ipa_enabled(>options.adp, f)
+   qeth_is_adp_supported(>options.adp, f)
 #define qeth_is_supported(c, f) \
qeth_is_ipa_supported(>options.ipa4, f)
 #define qeth_is_enabled(c, f) \
-- 
2.20.1





[PATCH 5.1 112/405] arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result value

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 84ff7a09c371bc7417eabfda19bf7f113ec917b6 ]

Rather embarrassingly, our futex() FUTEX_WAKE_OP implementation doesn't
explicitly set the return value on the non-faulting path and instead
leaves it holding the result of the underlying atomic operation. This
means that any FUTEX_WAKE_OP atomic operation which computes a non-zero
value will be reported as having failed. Regrettably, I wrote the buggy
code back in 2011 and it was upstreamed as part of the initial arm64
support in 2012.

The reasons we appear to get away with this are:

  1. FUTEX_WAKE_OP is rarely used and therefore doesn't appear to get
 exercised by futex() test applications

  2. If the result of the atomic operation is zero, the system call
 behaves correctly

  3. Prior to version 2.25, the only operation used by GLIBC set the
 futex to zero, and therefore worked as expected. From 2.25 onwards,
 FUTEX_WAKE_OP is not used by GLIBC at all.

Fix the implementation by ensuring that the return value is either 0
to indicate that the atomic operation completed successfully, or -EFAULT
if we encountered a fault when accessing the user mapping.

Cc: 
Fixes: 6170a97460db ("arm64: Atomic operations")
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin 
---
 arch/arm64/include/asm/futex.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/futex.h b/arch/arm64/include/asm/futex.h
index 6fb2214333a24..2d78ea6932b7b 100644
--- a/arch/arm64/include/asm/futex.h
+++ b/arch/arm64/include/asm/futex.h
@@ -58,7 +58,7 @@ do {  
\
 static inline int
 arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *_uaddr)
 {
-   int oldval = 0, ret, tmp;
+   int oldval, ret, tmp;
u32 __user *uaddr = __uaccess_mask_ptr(_uaddr);
 
pagefault_disable();
-- 
2.20.1





[PATCH 5.1 110/405] net: phy: improve genphy_soft_reset

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 8c90b795e90f7753d23c18e8b95dd71b4a18c5d9 ]

PHY's behave differently when being reset. Some reset registers to
defaults, some don't. Some trigger an autoneg restart, some don't.

So let's also set the autoneg restart bit when resetting. Then PHY
behavior should be more consistent. Clearing BMCR_ISOLATE serves the
same purpose and is borrowed from genphy_restart_aneg.

BMCR holds the speed / duplex settings in fixed mode. Therefore
we may have an issue if a soft reset resets BMCR to its default.
So better call genphy_setup_forced() afterwards in fixed mode.
We've seen no related complaint in the last >10 yrs, so let's
treat it as an improvement.

Signed-off-by: Heiner Kallweit 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/phy/phy_device.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index cd5966b0db571..f6a6cc5bf118d 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1829,13 +1829,25 @@ EXPORT_SYMBOL(genphy_read_status);
  */
 int genphy_soft_reset(struct phy_device *phydev)
 {
+   u16 res = BMCR_RESET;
int ret;
 
-   ret = phy_set_bits(phydev, MII_BMCR, BMCR_RESET);
+   if (phydev->autoneg == AUTONEG_ENABLE)
+   res |= BMCR_ANRESTART;
+
+   ret = phy_modify(phydev, MII_BMCR, BMCR_ISOLATE, res);
if (ret < 0)
return ret;
 
-   return phy_poll_reset(phydev);
+   ret = phy_poll_reset(phydev);
+   if (ret)
+   return ret;
+
+   /* BMCR may be reset to defaults */
+   if (phydev->autoneg == AUTONEG_DISABLE)
+   ret = genphy_setup_forced(phydev);
+
+   return ret;
 }
 EXPORT_SYMBOL(genphy_soft_reset);
 
-- 
2.20.1





[PATCH 5.1 109/405] net: hns3: fix for TX clean num when cleaning TX BD

2019-05-29 Thread Greg Kroah-Hartman
[ Upstream commit 63380a1ae4ced8aef67659ff9547c69ef8b9613a ]

hns3_desc_unused() returns how many BD have been cleaned, but new
buffer has not been attached to them. The register of
HNS3_RING_RX_RING_FBDNUM_REG returns how many BD need allocating new
buffer to or need to cleaned. So the remaining BD need to be clean
is HNS3_RING_RX_RING_FBDNUM_REG - hns3_desc_unused().

Also, new buffer can not attach to the pending BD when the last BD is
not handled, because memcpy has not been done on the first pending BD.

This patch fixes by subtracting the pending BD num from unused_count
after 'HNS3_RING_RX_RING_FBDNUM_REG - unused_count' is used to calculate
the BD bum need to be clean.

Fixes: e55970950556 ("net: hns3: Add handling of GRO Pkts not fully RX'ed in 
NAPI poll")
Signed-off-by: Yunsheng Lin 
Signed-off-by: Peng Li 
Signed-off-by: Huazhong Tan 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 162cb9afa0e70..0208efe282775 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2705,7 +2705,7 @@ int hns3_clean_rx_ring(
 #define RCB_NOF_ALLOC_RX_BUFF_ONCE 16
struct net_device *netdev = ring->tqp->handle->kinfo.netdev;
int recv_pkts, recv_bds, clean_count, err;
-   int unused_count = hns3_desc_unused(ring) - ring->pending_buf;
+   int unused_count = hns3_desc_unused(ring);
struct sk_buff *skb = ring->skb;
int num;
 
@@ -2714,6 +2714,7 @@ int hns3_clean_rx_ring(
 
recv_pkts = 0, recv_bds = 0, clean_count = 0;
num -= unused_count;
+   unused_count -= ring->pending_buf;
 
while (recv_pkts < budget && recv_bds < num) {
/* Reuse or realloc buffers */
-- 
2.20.1





  1   2   3   4   5   6   7   8   9   10   >