Stable Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH 4.19 00/74] 4.19.65-stable review
@ 2019-08-05 13:02 Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 01/74] ARM: riscpc: fix DMA Greg Kroah-Hartman
                   ` (78 more replies)
  0 siblings, 79 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, torvalds, akpm, linux, shuah, patches,
	ben.hutchings, lkft-triage, stable

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

Responses should be made by Wed 07 Aug 2019 12:47:58 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.65-rc1.gz
or in the git tree and branch at:
	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 4.19.65-rc1

Suganath Prabu <suganath-prabu.subramani@broadcom.com>
    scsi: mpt3sas: Use 63-bit DMA addressing on SAS35 HBA

Andy Lutomirski <luto@kernel.org>
    x86/vdso: Prevent segfaults due to hoisted vclock reads

Linus Torvalds <torvalds@linux-foundation.org>
    gcc-9: properly declare the {pv,hv}clock_page storage

Josh Poimboeuf <jpoimboe@redhat.com>
    objtool: Support GCC 9 cold subfunction naming scheme

Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
    ARC: enable uboot support unconditionally

Jean Delvare <jdelvare@suse.de>
    eeprom: at24: make spd world-readable again

Xiaolin Zhang <xiaolin.zhang@intel.com>
    drm/i915/gvt: fix incorrect cache entry for guest page mapping

John Fleck <john.fleck@intel.com>
    IB/hfi1: Check for error on call to alloc_rsm_map_table

Yishai Hadas <yishaih@mellanox.com>
    IB/mlx5: Fix RSS Toeplitz setup to be aligned with the HW specification

Yishai Hadas <yishaih@mellanox.com>
    IB/mlx5: Fix clean_mr() to work in the expected order

Yishai Hadas <yishaih@mellanox.com>
    IB/mlx5: Move MRs to a kernel PD when freeing them to the MR cache

Yishai Hadas <yishaih@mellanox.com>
    IB/mlx5: Use direct mkey destroy command upon UMR unreg failure

Yishai Hadas <yishaih@mellanox.com>
    IB/mlx5: Fix unreg_umr to ignore the mkey state

Juergen Gross <jgross@suse.com>
    xen/swiotlb: fix condition for calling xen_destroy_contiguous_region()

Munehisa Kamata <kamatam@amazon.com>
    nbd: replace kill_bdev() with __invalidate_device() again

Will Deacon <will@kernel.org>
    arm64: cpufeature: Fix feature comparison for CTR_EL0.{CWG,ERG}

Will Deacon <will@kernel.org>
    arm64: compat: Allow single-byte watchpoints on all addresses

Will Deacon <will@kernel.org>
    drivers/perf: arm_pmu: Fix failure path in PM notifier

Helge Deller <deller@gmx.de>
    parisc: Fix build of compressed kernel even with debug enabled

Chris Down <chris@chrisdown.name>
    cgroup: kselftest: relax fs_spec checks

Stefan Haberland <sth@linux.ibm.com>
    s390/dasd: fix endless loop after read unit address configuration

Yang Shi <yang.shi@linux.alibaba.com>
    mm: vmscan: check if mem cgroup is disabled or not before calling memcg slab shrinker

Samuel Thibault <samuel.thibault@ens-lyon.org>
    ALSA: hda: Fix 1-minute detection delay when i915 module is not available

Ondrej Mosnacek <omosnace@redhat.com>
    selinux: fix memory leak in policydb_init()

Marco Felsch <m.felsch@pengutronix.de>
    mtd: rawnand: micron: handle on-die "ECC-off" devices correctly

Gustavo A. R. Silva <gustavo@embeddedor.com>
    IB/hfi1: Fix Spectre v1 vulnerability

Michael Wu <michael.wu@vatics.com>
    gpiolib: fix incorrect IRQ requesting of an active-low lineevent

Joe Perches <joe@perches.com>
    mmc: meson-mx-sdio: Fix misuse of GENMASK macro

Douglas Anderson <dianders@chromium.org>
    mmc: dw_mmc: Fix occasional hang after tuning on eMMC

Filipe Manana <fdmanana@suse.com>
    Btrfs: fix race leading to fs corruption after transaction abort

Filipe Manana <fdmanana@suse.com>
    Btrfs: fix incremental send failure after deduplication

Masahiro Yamada <yamada.masahiro@socionext.com>
    kbuild: initialize CLANG_FLAGS correctly in the top Makefile

M. Vefa Bicakci <m.v.b@runbox.com>
    kconfig: Clear "written" flag to avoid data loss

Yongxin Liu <yongxin.liu@windriver.com>
    drm/nouveau: fix memory leak in nouveau_conn_reset()

Zhenzhong Duan <zhenzhong.duan@oracle.com>
    x86, boot: Remove multiple copy of static function sanitize_boot_params()

Josh Poimboeuf <jpoimboe@redhat.com>
    x86/paravirt: Fix callee-saved function ELF sizes

Josh Poimboeuf <jpoimboe@redhat.com>
    x86/kvm: Don't call kvm_spurious_fault() from .fixup

Zhenzhong Duan <zhenzhong.duan@oracle.com>
    xen/pv: Fix a boot up hang revealed by int3 self test

Petr Machata <petrm@mellanox.com>
    mlxsw: spectrum_dcb: Configure DSCP map as the last rule is removed

Kees Cook <keescook@chromium.org>
    ipc/mqueue.c: only perform resource calculation if user valid

Dan Carpenter <dan.carpenter@oracle.com>
    drivers/rapidio/devices/rio_mport_cdev.c: NUL terminate some strings

Mikko Rapeli <mikko.rapeli@iki.fi>
    uapi linux/coda_psdev.h: move upc_req definition from uapi to kernel side headers

Sam Protsenko <semen.protsenko@linaro.org>
    coda: fix build using bare-metal toolchain

Zhouyang Jia <jiazhouyang09@gmail.com>
    coda: add error handling for fget

Peter Rosin <peda@axentia.se>
    lib/test_string.c: avoid masking memset16/32/64 failures

Kees Cook <keescook@chromium.org>
    lib/test_overflow.c: avoid tainting the kernel and fix wrap size

Doug Berger <opendmb@gmail.com>
    mm/cma.c: fail if fixed declaration can't be honored

Arnd Bergmann <arnd@arndb.de>
    x86: math-emu: Hide clang warnings for 16-bit overflow

Qian Cai <cai@lca.pw>
    x86/apic: Silence -Wtype-limits compiler warnings

Benjamin Poirier <bpoirier@suse.com>
    be2net: Signal that the device cannot transmit during reconfiguration

Arnd Bergmann <arnd@arndb.de>
    ACPI: fix false-positive -Wuninitialized warning

Arnd Bergmann <arnd@arndb.de>
    x86: kvm: avoid constant-conversion warning

Ravi Bangoria <ravi.bangoria@linux.ibm.com>
    perf version: Fix segfault due to missing OPT_END()

Benjamin Block <bblock@linux.ibm.com>
    scsi: zfcp: fix GCC compiler warning emitted with -Wmaybe-uninitialized

Arnd Bergmann <arnd@arndb.de>
    ACPI: blacklist: fix clang warning for unused DMI table

Jeff Layton <jlayton@kernel.org>
    ceph: return -ERANGE if virtual xattr value didn't fit in buffer

Andrea Parri <andrea.parri@amarulasolutions.com>
    ceph: fix improper use of smp_mb__before_atomic()

Ronnie Sahlberg <lsahlber@redhat.com>
    cifs: Fix a race condition with cifs_echo_request

Qu Wenruo <wqu@suse.com>
    btrfs: qgroup: Don't hold qgroup_ioctl_lock in btrfs_qgroup_inherit()

David Sterba <dsterba@suse.com>
    btrfs: fix minimum number of chunk errors for DUP

Chunyan Zhang <zhang.chunyan@linaro.org>
    clk: sprd: Add check for return value of sprd_clk_regmap_init()

Russell King <rmk+kernel@armlinux.org.uk>
    fs/adfs: super: fix use-after-free bug

JC Kuo <jckuo@nvidia.com>
    clk: tegra210: fix PLLU and PLLU_OUT1

Geert Uytterhoeven <geert+renesas@glider.be>
    dmaengine: rcar-dmac: Reject zero-length slave DMA requests

Petr Cvek <petrcvekcz@gmail.com>
    MIPS: lantiq: Fix bitfield masking

Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
    firmware/psci: psci_checker: Park kthreads before stopping them

Prarit Bhargava <prarit@redhat.com>
    kernel/module.c: Only return -EEXIST for modules that have finished loading

Helen Koike <helen.koike@collabora.com>
    arm64: dts: rockchip: fix isp iommu clocks and power domain

Dmitry Osipenko <digetx@gmail.com>
    dmaengine: tegra-apb: Error out if DMA_PREP_INTERRUPT flag is unset

Cheng Jian <cj.chengjian@huawei.com>
    ftrace: Enable trampoline when rec count returns back to one

Douglas Anderson <dianders@chromium.org>
    ARM: dts: rockchip: Mark that the rk3288 timer might stop in suspend

Douglas Anderson <dianders@chromium.org>
    ARM: dts: rockchip: Make rk3288-veyron-mickey's emmc work again

Douglas Anderson <dianders@chromium.org>
    ARM: dts: rockchip: Make rk3288-veyron-minnie run at hs200

Russell King <rmk+kernel@armlinux.org.uk>
    ARM: riscpc: fix DMA


-------------

Diffstat:

 Makefile                                           |  7 +-
 arch/arc/Kconfig                                   | 13 ----
 arch/arc/configs/nps_defconfig                     |  1 -
 arch/arc/configs/vdk_hs38_defconfig                |  1 -
 arch/arc/configs/vdk_hs38_smp_defconfig            |  2 -
 arch/arc/kernel/head.S                             |  2 -
 arch/arc/kernel/setup.c                            |  2 -
 arch/arm/boot/dts/rk3288-veyron-mickey.dts         |  4 --
 arch/arm/boot/dts/rk3288-veyron-minnie.dts         |  4 --
 arch/arm/boot/dts/rk3288.dtsi                      |  1 +
 arch/arm/mach-rpc/dma.c                            |  5 +-
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           |  8 +--
 arch/arm64/include/asm/cpufeature.h                |  7 +-
 arch/arm64/kernel/cpufeature.c                     |  8 ++-
 arch/arm64/kernel/hw_breakpoint.c                  |  7 +-
 arch/mips/lantiq/irq.c                             |  5 +-
 arch/parisc/boot/compressed/vmlinux.lds.S          |  4 +-
 arch/x86/boot/compressed/misc.c                    |  1 +
 arch/x86/boot/compressed/misc.h                    |  1 -
 arch/x86/entry/entry_64.S                          |  1 -
 arch/x86/entry/vdso/vclock_gettime.c               | 19 ++++--
 arch/x86/include/asm/apic.h                        |  2 +-
 arch/x86/include/asm/kvm_host.h                    | 34 +++++-----
 arch/x86/include/asm/paravirt.h                    |  1 +
 arch/x86/include/asm/traps.h                       |  2 +-
 arch/x86/kernel/apic/apic.c                        |  2 +-
 arch/x86/kernel/kvm.c                              |  1 +
 arch/x86/kvm/mmu.c                                 |  6 +-
 arch/x86/math-emu/fpu_emu.h                        |  2 +-
 arch/x86/math-emu/reg_constant.c                   |  2 +-
 arch/x86/xen/enlighten_pv.c                        |  2 +-
 arch/x86/xen/xen-asm_64.S                          |  1 -
 drivers/acpi/blacklist.c                           |  4 ++
 drivers/block/nbd.c                                |  2 +-
 drivers/clk/sprd/sc9860-clk.c                      |  5 +-
 drivers/clk/tegra/clk-tegra210.c                   |  8 +--
 drivers/dma/sh/rcar-dmac.c                         |  2 +-
 drivers/dma/tegra20-apb-dma.c                      | 12 +++-
 drivers/firmware/psci_checker.c                    | 10 +--
 drivers/gpio/gpiolib.c                             |  6 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c                   | 12 ++++
 drivers/gpu/drm/nouveau/nouveau_connector.c        |  2 +-
 drivers/infiniband/hw/hfi1/chip.c                  | 11 +++-
 drivers/infiniband/hw/hfi1/verbs.c                 |  2 +
 drivers/infiniband/hw/mlx5/mlx5_ib.h               |  1 +
 drivers/infiniband/hw/mlx5/mr.c                    | 23 ++++---
 drivers/infiniband/hw/mlx5/qp.c                    | 13 ++--
 drivers/misc/eeprom/at24.c                         |  2 +-
 drivers/mmc/host/dw_mmc.c                          |  3 +-
 drivers/mmc/host/meson-mx-sdio.c                   |  2 +-
 drivers/mtd/nand/raw/nand_micron.c                 | 14 +++-
 drivers/net/ethernet/emulex/benet/be_main.c        |  6 +-
 drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c | 16 ++---
 drivers/perf/arm_pmu.c                             |  2 +-
 drivers/rapidio/devices/rio_mport_cdev.c           |  2 +
 drivers/s390/block/dasd_alias.c                    | 22 +++++--
 drivers/s390/scsi/zfcp_erp.c                       |  7 ++
 drivers/scsi/mpt3sas/mpt3sas_base.c                | 12 ++--
 drivers/xen/swiotlb-xen.c                          |  4 +-
 fs/adfs/super.c                                    |  5 +-
 fs/btrfs/qgroup.c                                  | 24 ++++++-
 fs/btrfs/send.c                                    | 77 +++++-----------------
 fs/btrfs/transaction.c                             | 10 +++
 fs/btrfs/volumes.c                                 |  3 +-
 fs/ceph/super.h                                    |  7 +-
 fs/ceph/xattr.c                                    | 14 ++--
 fs/cifs/connect.c                                  |  8 +--
 fs/coda/psdev.c                                    |  5 +-
 include/linux/acpi.h                               |  5 +-
 include/linux/coda.h                               |  3 +-
 include/linux/coda_psdev.h                         | 11 ++++
 include/uapi/linux/coda_psdev.h                    | 13 ----
 ipc/mqueue.c                                       | 19 +++---
 kernel/module.c                                    |  6 +-
 kernel/trace/ftrace.c                              | 28 ++++----
 lib/test_overflow.c                                | 11 ++--
 lib/test_string.c                                  |  6 +-
 mm/cma.c                                           | 13 ++++
 mm/vmscan.c                                        |  9 ++-
 scripts/kconfig/confdata.c                         |  4 ++
 security/selinux/ss/policydb.c                     |  6 +-
 sound/hda/hdac_i915.c                              | 10 +--
 tools/objtool/elf.c                                |  2 +-
 tools/perf/builtin-version.c                       |  1 +
 tools/testing/selftests/cgroup/cgroup_util.c       |  3 +-
 85 files changed, 385 insertions(+), 281 deletions(-)



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 01/74] ARM: riscpc: fix DMA
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 02/74] ARM: dts: rockchip: Make rk3288-veyron-minnie run at hs200 Greg Kroah-Hartman
                   ` (77 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Russell King, Sasha Levin

[ Upstream commit ffd9a1ba9fdb7f2bd1d1ad9b9243d34e96756ba2 ]

DMA got broken a while back in two different ways:
1) a change in the behaviour of disable_irq() to wait for the interrupt
   to finish executing causes us to deadlock at the end of DMA.
2) a change to avoid modifying the scatterlist left the first transfer
   uninitialised.

DMA is only used with expansion cards, so has gone unnoticed.

Fixes: fa4e99899932 ("[ARM] dma: RiscPC: don't modify DMA SG entries")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/arm/mach-rpc/dma.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-rpc/dma.c b/arch/arm/mach-rpc/dma.c
index fb48f3141fb4d..c4c96661eb89a 100644
--- a/arch/arm/mach-rpc/dma.c
+++ b/arch/arm/mach-rpc/dma.c
@@ -131,7 +131,7 @@ static irqreturn_t iomd_dma_handle(int irq, void *dev_id)
 	} while (1);
 
 	idma->state = ~DMA_ST_AB;
-	disable_irq(irq);
+	disable_irq_nosync(irq);
 
 	return IRQ_HANDLED;
 }
@@ -174,6 +174,9 @@ static void iomd_enable_dma(unsigned int chan, dma_t *dma)
 				DMA_FROM_DEVICE : DMA_TO_DEVICE);
 		}
 
+		idma->dma_addr = idma->dma.sg->dma_address;
+		idma->dma_len = idma->dma.sg->length;
+
 		iomd_writeb(DMA_CR_C, dma_base + CR);
 		idma->state = DMA_ST_AB;
 	}
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 02/74] ARM: dts: rockchip: Make rk3288-veyron-minnie run at hs200
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 01/74] ARM: riscpc: fix DMA Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 14:41   ` Pavel Machek
  2019-08-05 13:02 ` [PATCH 4.19 03/74] ARM: dts: rockchip: Make rk3288-veyron-mickeys emmc work again Greg Kroah-Hartman
                   ` (76 subsequent siblings)
  78 siblings, 1 reply; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Douglas Anderson, Heiko Stuebner,
	Sasha Levin

[ Upstream commit 1c0479023412ab7834f2e98b796eb0d8c627cd62 ]

As some point hs200 was failing on rk3288-veyron-minnie.  See commit
984926781122 ("ARM: dts: rockchip: temporarily remove emmc hs200 speed
from rk3288 minnie").  Although I didn't track down exactly when it
started working, it seems to work OK now, so let's turn it back on.

To test this, I booted from SD card and then used this script to
stress the enumeration process after fixing a memory leak [1]:
  cd /sys/bus/platform/drivers/dwmmc_rockchip
  for i in $(seq 1 3000); do
    echo "========================" $i
    echo ff0f0000.dwmmc > unbind
    sleep .5
    echo ff0f0000.dwmmc > bind
    while true; do
      if [ -e /dev/mmcblk2 ]; then
        break;
      fi
      sleep .1
    done
  done

It worked fine.

[1] https://lkml.kernel.org/r/20190503233526.226272-1-dianders@chromium.org

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/arm/boot/dts/rk3288-veyron-minnie.dts | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
index f95d0c5fcf712..6e8946052c78b 100644
--- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
@@ -90,10 +90,6 @@
 	pwm-off-delay-ms = <200>;
 };
 
-&emmc {
-	/delete-property/mmc-hs200-1_8v;
-};
-
 &gpio_keys {
 	pinctrl-0 = <&pwr_key_l &ap_lid_int_l &volum_down_l &volum_up_l>;
 
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 03/74] ARM: dts: rockchip: Make rk3288-veyron-mickeys emmc work again
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 01/74] ARM: riscpc: fix DMA Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 02/74] ARM: dts: rockchip: Make rk3288-veyron-minnie run at hs200 Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 14:45   ` Pavel Machek
  2019-08-05 13:02 ` [PATCH 4.19 04/74] ARM: dts: rockchip: Mark that the rk3288 timer might stop in suspend Greg Kroah-Hartman
                   ` (75 subsequent siblings)
  78 siblings, 1 reply; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Douglas Anderson, Heiko Stuebner,
	Sasha Levin

[ Upstream commit 99fa066710f75f18f4d9a5bc5f6a711968a581d5 ]

When I try to boot rk3288-veyron-mickey I totally fail to make the
eMMC work.  Specifically my logs (on Chrome OS 4.19):

  mmc_host mmc1: card is non-removable.
  mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
  mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
  mmc1: switch to bus width 8 failed
  mmc1: switch to bus width 4 failed
  mmc1: new high speed MMC card at address 0001
  mmcblk1: mmc1:0001 HAG2e 14.7 GiB
  mmcblk1boot0: mmc1:0001 HAG2e partition 1 4.00 MiB
  mmcblk1boot1: mmc1:0001 HAG2e partition 2 4.00 MiB
  mmcblk1rpmb: mmc1:0001 HAG2e partition 3 4.00 MiB, chardev (243:0)
  mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
  mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
  mmc1: switch to bus width 8 failed
  mmc1: switch to bus width 4 failed
  mmc1: tried to HW reset card, got error -110
  mmcblk1: error -110 requesting status
  mmcblk1: recovery failed!
  print_req_error: I/O error, dev mmcblk1, sector 0
  ...

When I remove the '/delete-property/mmc-hs200-1_8v' then everything is
hunky dory.

That line comes from the original submission of the mickey dts
upstream, so presumably at the time the HS200 was failing and just
enumerating things as a high speed device was fine.  ...or maybe it's
just that some mickey devices work when enumerating at "high speed",
just not mine?

In any case, hs200 seems good now.  Let's turn it on.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/arm/boot/dts/rk3288-veyron-mickey.dts | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288-veyron-mickey.dts b/arch/arm/boot/dts/rk3288-veyron-mickey.dts
index 1e0158acf895d..a593d0a998fc8 100644
--- a/arch/arm/boot/dts/rk3288-veyron-mickey.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-mickey.dts
@@ -124,10 +124,6 @@
 	};
 };
 
-&emmc {
-	/delete-property/mmc-hs200-1_8v;
-};
-
 &i2c2 {
 	status = "disabled";
 };
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 04/74] ARM: dts: rockchip: Mark that the rk3288 timer might stop in suspend
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (2 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 03/74] ARM: dts: rockchip: Make rk3288-veyron-mickeys emmc work again Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 14:47   ` Pavel Machek
  2019-08-05 13:02 ` [PATCH 4.19 05/74] ftrace: Enable trampoline when rec count returns back to one Greg Kroah-Hartman
                   ` (74 subsequent siblings)
  78 siblings, 1 reply; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Douglas Anderson, Heiko Stuebner,
	Sasha Levin

[ Upstream commit 8ef1ba39a9fa53d2205e633bc9b21840a275908e ]

This is similar to commit e6186820a745 ("arm64: dts: rockchip: Arch
counter doesn't tick in system suspend").  Specifically on the rk3288
it can be seen that the timer stops ticking in suspend if we end up
running through the "osc_disable" path in rk3288_slp_mode_set().  In
that path the 24 MHz clock will turn off and the timer stops.

To test this, I ran this on a Chrome OS filesystem:
  before=$(date); \
  suspend_stress_test -c1 --suspend_min=30 --suspend_max=31; \
  echo ${before}; date

...and I found that unless I plug in a device that requests USB wakeup
to be active that the two calls to "date" would show that fewer than
30 seconds passed.

NOTE: deep suspend (where the 24 MHz clock gets disabled) isn't
supported yet on upstream Linux so this was tested on a downstream
kernel.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/arm/boot/dts/rk3288.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index c706adf4aed2f..440d6783faca5 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -227,6 +227,7 @@
 			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
 			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
 		clock-frequency = <24000000>;
+		arm,no-tick-in-suspend;
 	};
 
 	timer: timer@ff810000 {
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 05/74] ftrace: Enable trampoline when rec count returns back to one
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (3 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 04/74] ARM: dts: rockchip: Mark that the rk3288 timer might stop in suspend Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 06/74] dmaengine: tegra-apb: Error out if DMA_PREP_INTERRUPT flag is unset Greg Kroah-Hartman
                   ` (73 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Cheng Jian, Steven Rostedt (VMware),
	Sasha Levin

[ Upstream commit a124692b698b00026a58d89831ceda2331b2e1d0 ]

Custom trampolines can only be enabled if there is only a single ops
attached to it. If there's only a single callback registered to a function,
and the ops has a trampoline registered for it, then we can call the
trampoline directly. This is very useful for improving the performance of
ftrace and livepatch.

If more than one callback is registered to a function, the general
trampoline is used, and the custom trampoline is not restored back to the
direct call even if all the other callbacks were unregistered and we are
back to one callback for the function.

To fix this, set FTRACE_FL_TRAMP flag if rec count is decremented
to one, and the ops that left has a trampoline.

Testing After this patch :

insmod livepatch_unshare_files.ko
cat /sys/kernel/debug/tracing/enabled_functions

	unshare_files (1) R I	tramp: 0xffffffffc0000000(klp_ftrace_handler+0x0/0xa0) ->ftrace_ops_assist_func+0x0/0xf0

echo unshare_files > /sys/kernel/debug/tracing/set_ftrace_filter
echo function > /sys/kernel/debug/tracing/current_tracer
cat /sys/kernel/debug/tracing/enabled_functions

	unshare_files (2) R I ->ftrace_ops_list_func+0x0/0x150

echo nop > /sys/kernel/debug/tracing/current_tracer
cat /sys/kernel/debug/tracing/enabled_functions

	unshare_files (1) R I	tramp: 0xffffffffc0000000(klp_ftrace_handler+0x0/0xa0) ->ftrace_ops_assist_func+0x0/0xf0

Link: http://lkml.kernel.org/r/1556969979-111047-1-git-send-email-cj.chengjian@huawei.com

Signed-off-by: Cheng Jian <cj.chengjian@huawei.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 kernel/trace/ftrace.c | 28 +++++++++++++++-------------
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 118ecce143866..d9dd709b3c12f 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -1647,6 +1647,11 @@ static bool test_rec_ops_needs_regs(struct dyn_ftrace *rec)
 	return  keep_regs;
 }
 
+static struct ftrace_ops *
+ftrace_find_tramp_ops_any(struct dyn_ftrace *rec);
+static struct ftrace_ops *
+ftrace_find_tramp_ops_next(struct dyn_ftrace *rec, struct ftrace_ops *ops);
+
 static bool __ftrace_hash_rec_update(struct ftrace_ops *ops,
 				     int filter_hash,
 				     bool inc)
@@ -1775,15 +1780,17 @@ static bool __ftrace_hash_rec_update(struct ftrace_ops *ops,
 			}
 
 			/*
-			 * If the rec had TRAMP enabled, then it needs to
-			 * be cleared. As TRAMP can only be enabled iff
-			 * there is only a single ops attached to it.
-			 * In otherwords, always disable it on decrementing.
-			 * In the future, we may set it if rec count is
-			 * decremented to one, and the ops that is left
-			 * has a trampoline.
+			 * The TRAMP needs to be set only if rec count
+			 * is decremented to one, and the ops that is
+			 * left has a trampoline. As TRAMP can only be
+			 * enabled if there is only a single ops attached
+			 * to it.
 			 */
-			rec->flags &= ~FTRACE_FL_TRAMP;
+			if (ftrace_rec_count(rec) == 1 &&
+			    ftrace_find_tramp_ops_any(rec))
+				rec->flags |= FTRACE_FL_TRAMP;
+			else
+				rec->flags &= ~FTRACE_FL_TRAMP;
 
 			/*
 			 * flags will be cleared in ftrace_check_record()
@@ -1976,11 +1983,6 @@ static void print_ip_ins(const char *fmt, const unsigned char *p)
 		printk(KERN_CONT "%s%02x", i ? ":" : "", p[i]);
 }
 
-static struct ftrace_ops *
-ftrace_find_tramp_ops_any(struct dyn_ftrace *rec);
-static struct ftrace_ops *
-ftrace_find_tramp_ops_next(struct dyn_ftrace *rec, struct ftrace_ops *ops);
-
 enum ftrace_bug_type ftrace_bug_type;
 const void *ftrace_expected;
 
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 06/74] dmaengine: tegra-apb: Error out if DMA_PREP_INTERRUPT flag is unset
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (4 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 05/74] ftrace: Enable trampoline when rec count returns back to one Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 07/74] arm64: dts: rockchip: fix isp iommu clocks and power domain Greg Kroah-Hartman
                   ` (72 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Dmitry Osipenko, Jon Hunter,
	Vinod Koul, Sasha Levin

[ Upstream commit dc161064beb83c668e0f85766b92b1e7ed186e58 ]

Apparently driver was never tested with DMA_PREP_INTERRUPT flag being
unset since it completely disables interrupt handling instead of skipping
the callbacks invocations, hence putting channel into unusable state.

The flag is always set by all of kernel drivers that use APB DMA, so let's
error out in otherwise case for consistency. It won't be difficult to
support that case properly if ever will be needed.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/dma/tegra20-apb-dma.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index 8219ab88a507c..fb23993430d31 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -981,8 +981,12 @@ static struct dma_async_tx_descriptor *tegra_dma_prep_slave_sg(
 		csr |= tdc->slave_id << TEGRA_APBDMA_CSR_REQ_SEL_SHIFT;
 	}
 
-	if (flags & DMA_PREP_INTERRUPT)
+	if (flags & DMA_PREP_INTERRUPT) {
 		csr |= TEGRA_APBDMA_CSR_IE_EOC;
+	} else {
+		WARN_ON_ONCE(1);
+		return NULL;
+	}
 
 	apb_seq |= TEGRA_APBDMA_APBSEQ_WRAP_WORD_1;
 
@@ -1124,8 +1128,12 @@ static struct dma_async_tx_descriptor *tegra_dma_prep_dma_cyclic(
 		csr |= tdc->slave_id << TEGRA_APBDMA_CSR_REQ_SEL_SHIFT;
 	}
 
-	if (flags & DMA_PREP_INTERRUPT)
+	if (flags & DMA_PREP_INTERRUPT) {
 		csr |= TEGRA_APBDMA_CSR_IE_EOC;
+	} else {
+		WARN_ON_ONCE(1);
+		return NULL;
+	}
 
 	apb_seq |= TEGRA_APBDMA_APBSEQ_WRAP_WORD_1;
 
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 07/74] arm64: dts: rockchip: fix isp iommu clocks and power domain
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (5 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 06/74] dmaengine: tegra-apb: Error out if DMA_PREP_INTERRUPT flag is unset Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 08/74] kernel/module.c: Only return -EEXIST for modules that have finished loading Greg Kroah-Hartman
                   ` (71 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Helen Koike, Manivannan Sadhasivam,
	Heiko Stuebner, Sasha Levin

[ Upstream commit c432a29d3fc9ee928caeca2f5cf68b3aebfa6817 ]

isp iommu requires wrapper variants of the clocks.
noc variants are always on and using the wrapper variants will activate
{A,H}CLK_ISP{0,1} due to the hierarchy.

Tested using the pending isp patch set (which is not upstream
yet). Without this patch, streaming from the isp stalls.

Also add the respective power domain and remove the "disabled" status.

Refer:
 RK3399 TRM v1.4 Fig. 2-4 RK3399 Clock Architecture Diagram
 RK3399 TRM v1.4 Fig. 8-1 RK3399 Power Domain Partition

Signed-off-by: Helen Koike <helen.koike@collabora.com>
Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index df7e62d9a6708..cea44a7c7cf99 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1643,11 +1643,11 @@
 		reg = <0x0 0xff914000 0x0 0x100>, <0x0 0xff915000 0x0 0x100>;
 		interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH 0>;
 		interrupt-names = "isp0_mmu";
-		clocks = <&cru ACLK_ISP0_NOC>, <&cru HCLK_ISP0_NOC>;
+		clocks = <&cru ACLK_ISP0_WRAPPER>, <&cru HCLK_ISP0_WRAPPER>;
 		clock-names = "aclk", "iface";
 		#iommu-cells = <0>;
+		power-domains = <&power RK3399_PD_ISP0>;
 		rockchip,disable-mmu-reset;
-		status = "disabled";
 	};
 
 	isp1_mmu: iommu@ff924000 {
@@ -1655,11 +1655,11 @@
 		reg = <0x0 0xff924000 0x0 0x100>, <0x0 0xff925000 0x0 0x100>;
 		interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH 0>;
 		interrupt-names = "isp1_mmu";
-		clocks = <&cru ACLK_ISP1_NOC>, <&cru HCLK_ISP1_NOC>;
+		clocks = <&cru ACLK_ISP1_WRAPPER>, <&cru HCLK_ISP1_WRAPPER>;
 		clock-names = "aclk", "iface";
 		#iommu-cells = <0>;
+		power-domains = <&power RK3399_PD_ISP1>;
 		rockchip,disable-mmu-reset;
-		status = "disabled";
 	};
 
 	hdmi_sound: hdmi-sound {
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 08/74] kernel/module.c: Only return -EEXIST for modules that have finished loading
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (6 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 07/74] arm64: dts: rockchip: fix isp iommu clocks and power domain Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 09/74] firmware/psci: psci_checker: Park kthreads before stopping them Greg Kroah-Hartman
                   ` (70 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Prarit Bhargava, Barret Rhoden,
	David Arcari, Jessica Yu, Heiko Carstens, Sasha Levin

[ Upstream commit 6e6de3dee51a439f76eb73c22ae2ffd2c9384712 ]

Microsoft HyperV disables the X86_FEATURE_SMCA bit on AMD systems, and
linux guests boot with repeated errors:

amd64_edac_mod: Unknown symbol amd_unregister_ecc_decoder (err -2)
amd64_edac_mod: Unknown symbol amd_register_ecc_decoder (err -2)
amd64_edac_mod: Unknown symbol amd_report_gart_errors (err -2)
amd64_edac_mod: Unknown symbol amd_unregister_ecc_decoder (err -2)
amd64_edac_mod: Unknown symbol amd_register_ecc_decoder (err -2)
amd64_edac_mod: Unknown symbol amd_report_gart_errors (err -2)

The warnings occur because the module code erroneously returns -EEXIST
for modules that have failed to load and are in the process of being
removed from the module list.

module amd64_edac_mod has a dependency on module edac_mce_amd.  Using
modules.dep, systemd will load edac_mce_amd for every request of
amd64_edac_mod.  When the edac_mce_amd module loads, the module has
state MODULE_STATE_UNFORMED and once the module load fails and the state
becomes MODULE_STATE_GOING.  Another request for edac_mce_amd module
executes and add_unformed_module() will erroneously return -EEXIST even
though the previous instance of edac_mce_amd has MODULE_STATE_GOING.
Upon receiving -EEXIST, systemd attempts to load amd64_edac_mod, which
fails because of unknown symbols from edac_mce_amd.

add_unformed_module() must wait to return for any case other than
MODULE_STATE_LIVE to prevent a race between multiple loads of
dependent modules.

Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Barret Rhoden <brho@google.com>
Cc: David Arcari <darcari@redhat.com>
Cc: Jessica Yu <jeyu@kernel.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Jessica Yu <jeyu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 kernel/module.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index b8f37376856bd..3fda10c549a25 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3388,8 +3388,7 @@ static bool finished_loading(const char *name)
 	sched_annotate_sleep();
 	mutex_lock(&module_mutex);
 	mod = find_module_all(name, strlen(name), true);
-	ret = !mod || mod->state == MODULE_STATE_LIVE
-		|| mod->state == MODULE_STATE_GOING;
+	ret = !mod || mod->state == MODULE_STATE_LIVE;
 	mutex_unlock(&module_mutex);
 
 	return ret;
@@ -3559,8 +3558,7 @@ again:
 	mutex_lock(&module_mutex);
 	old = find_module_all(mod->name, strlen(mod->name), true);
 	if (old != NULL) {
-		if (old->state == MODULE_STATE_COMING
-		    || old->state == MODULE_STATE_UNFORMED) {
+		if (old->state != MODULE_STATE_LIVE) {
 			/* Wait in case it fails to load. */
 			mutex_unlock(&module_mutex);
 			err = wait_event_interruptible(module_wq,
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 09/74] firmware/psci: psci_checker: Park kthreads before stopping them
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (7 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 08/74] kernel/module.c: Only return -EEXIST for modules that have finished loading Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 10/74] MIPS: lantiq: Fix bitfield masking Greg Kroah-Hartman
                   ` (69 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Jean-Philippe Brucker, Sudeep Holla,
	Lorenzo Pieralisi, Olof Johansson, Sasha Levin

[ Upstream commit 92e074acf6f7694e96204265eb18ac113f546e80 ]

Since commit 85f1abe0019f ("kthread, sched/wait: Fix kthread_parkme()
completion issue"), kthreads that are bound to a CPU must be parked
before being stopped. At the moment the PSCI checker calls
kthread_stop() directly on the suspend kthread, which triggers the
following warning:

[    6.068288] WARNING: CPU: 1 PID: 1 at kernel/kthread.c:398 __kthread_bind_mask+0x20/0x78
               ...
[    6.190151] Call trace:
[    6.192566]  __kthread_bind_mask+0x20/0x78
[    6.196615]  kthread_unpark+0x74/0x80
[    6.200235]  kthread_stop+0x44/0x1d8
[    6.203769]  psci_checker+0x3bc/0x484
[    6.207389]  do_one_initcall+0x48/0x260
[    6.211180]  kernel_init_freeable+0x2c8/0x368
[    6.215488]  kernel_init+0x10/0x100
[    6.218935]  ret_from_fork+0x10/0x1c
[    6.222467] ---[ end trace e05e22863d043cd3 ]---

kthread_unpark() tries to bind the thread to its CPU and aborts with a
WARN() if the thread wasn't in TASK_PARKED state. Park the kthreads
before stopping them.

Fixes: 85f1abe0019f ("kthread, sched/wait: Fix kthread_parkme() completion issue")
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/firmware/psci_checker.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/psci_checker.c b/drivers/firmware/psci_checker.c
index 3469436579622..cbd53cb1b2d47 100644
--- a/drivers/firmware/psci_checker.c
+++ b/drivers/firmware/psci_checker.c
@@ -366,16 +366,16 @@ static int suspend_test_thread(void *arg)
 	for (;;) {
 		/* Needs to be set first to avoid missing a wakeup. */
 		set_current_state(TASK_INTERRUPTIBLE);
-		if (kthread_should_stop()) {
-			__set_current_state(TASK_RUNNING);
+		if (kthread_should_park())
 			break;
-		}
 		schedule();
 	}
 
 	pr_info("CPU %d suspend test results: success %d, shallow states %d, errors %d\n",
 		cpu, nb_suspend, nb_shallow_sleep, nb_err);
 
+	kthread_parkme();
+
 	return nb_err;
 }
 
@@ -440,8 +440,10 @@ static int suspend_tests(void)
 
 
 	/* Stop and destroy all threads, get return status. */
-	for (i = 0; i < nb_threads; ++i)
+	for (i = 0; i < nb_threads; ++i) {
+		err += kthread_park(threads[i]);
 		err += kthread_stop(threads[i]);
+	}
  out:
 	cpuidle_resume_and_unlock();
 	kfree(threads);
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 10/74] MIPS: lantiq: Fix bitfield masking
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (8 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 09/74] firmware/psci: psci_checker: Park kthreads before stopping them Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 11/74] dmaengine: rcar-dmac: Reject zero-length slave DMA requests Greg Kroah-Hartman
                   ` (68 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Petr Cvek, Paul Burton, hauke, john,
	linux-mips, openwrt-devel, pakahmar, Sasha Levin

[ Upstream commit ba1bc0fcdeaf3bf583c1517bd2e3e29cf223c969 ]

The modification of EXIN register doesn't clean the bitfield before
the writing of a new value. After a few modifications the bitfield would
accumulate only '1's.

Signed-off-by: Petr Cvek <petrcvekcz@gmail.com>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: hauke@hauke-m.de
Cc: john@phrozen.org
Cc: linux-mips@vger.kernel.org
Cc: openwrt-devel@lists.openwrt.org
Cc: pakahmar@hotmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/mips/lantiq/irq.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/mips/lantiq/irq.c b/arch/mips/lantiq/irq.c
index c4ef1c31e0c4f..37caeadb2964c 100644
--- a/arch/mips/lantiq/irq.c
+++ b/arch/mips/lantiq/irq.c
@@ -156,8 +156,9 @@ static int ltq_eiu_settype(struct irq_data *d, unsigned int type)
 			if (edge)
 				irq_set_handler(d->hwirq, handle_edge_irq);
 
-			ltq_eiu_w32(ltq_eiu_r32(LTQ_EIU_EXIN_C) |
-				(val << (i * 4)), LTQ_EIU_EXIN_C);
+			ltq_eiu_w32((ltq_eiu_r32(LTQ_EIU_EXIN_C) &
+				    (~(7 << (i * 4)))) | (val << (i * 4)),
+				    LTQ_EIU_EXIN_C);
 		}
 	}
 
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 11/74] dmaengine: rcar-dmac: Reject zero-length slave DMA requests
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (9 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 10/74] MIPS: lantiq: Fix bitfield masking Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 12/74] clk: tegra210: fix PLLU and PLLU_OUT1 Greg Kroah-Hartman
                   ` (67 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Eugeniu Rosca, Geert Uytterhoeven,
	Vinod Koul, Sasha Levin, Yoshihiro Shimoda

[ Upstream commit 78efb76ab4dfb8f74f290ae743f34162cd627f19 ]

While the .device_prep_slave_sg() callback rejects empty scatterlists,
it still accepts single-entry scatterlists with a zero-length segment.
These may happen if a driver calls dmaengine_prep_slave_single() with a
zero len parameter.  The corresponding DMA request will never complete,
leading to messages like:

    rcar-dmac e7300000.dma-controller: Channel Address Error happen

and DMA timeouts.

Although requesting a zero-length DMA request is a driver bug, rejecting
it early eases debugging.  Note that the .device_prep_dma_memcpy()
callback already rejects requests to copy zero bytes.

Reported-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Analyzed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/dma/sh/rcar-dmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index 0b05a1e08d213..041ce864097e4 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -1164,7 +1164,7 @@ rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 	struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
 
 	/* Someone calling slave DMA on a generic channel? */
-	if (rchan->mid_rid < 0 || !sg_len) {
+	if (rchan->mid_rid < 0 || !sg_len || !sg_dma_len(sgl)) {
 		dev_warn(chan->device->dev,
 			 "%s: bad parameter: len=%d, id=%d\n",
 			 __func__, sg_len, rchan->mid_rid);
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 12/74] clk: tegra210: fix PLLU and PLLU_OUT1
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (10 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 11/74] dmaengine: rcar-dmac: Reject zero-length slave DMA requests Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 13/74] fs/adfs: super: fix use-after-free bug Greg Kroah-Hartman
                   ` (66 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, JC Kuo, Peter De Schrijver,
	Stephen Boyd, Sasha Levin

[ Upstream commit 0d34dfbf3023cf119b83f6470692c0b10c832495 ]

Full-speed and low-speed USB devices do not work with Tegra210
platforms because of incorrect PLLU/PLLU_OUT1 clock settings.

When full-speed device is connected:
[   14.059886] usb 1-3: new full-speed USB device number 2 using tegra-xusb
[   14.196295] usb 1-3: device descriptor read/64, error -71
[   14.436311] usb 1-3: device descriptor read/64, error -71
[   14.675749] usb 1-3: new full-speed USB device number 3 using tegra-xusb
[   14.812335] usb 1-3: device descriptor read/64, error -71
[   15.052316] usb 1-3: device descriptor read/64, error -71
[   15.164799] usb usb1-port3: attempt power cycle

When low-speed device is connected:
[   37.610949] usb usb1-port3: Cannot enable. Maybe the USB cable is bad?
[   38.557376] usb usb1-port3: Cannot enable. Maybe the USB cable is bad?
[   38.564977] usb usb1-port3: attempt power cycle

This commit fixes the issue by:
 1. initializing PLLU_OUT1 before initializing XUSB_FS_SRC clock
    because PLLU_OUT1 is parent of XUSB_FS_SRC.
 2. changing PLLU post-divider to /2 (DIVP=1) according to Technical
    Reference Manual.

Fixes: e745f992cf4b ("clk: tegra: Rework pll_u")
Signed-off-by: JC Kuo <jckuo@nvidia.com>
Acked-By: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/clk/tegra/clk-tegra210.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
index 9eb1cb14fce11..4e1bc23c98655 100644
--- a/drivers/clk/tegra/clk-tegra210.c
+++ b/drivers/clk/tegra/clk-tegra210.c
@@ -2214,9 +2214,9 @@ static struct div_nmp pllu_nmp = {
 };
 
 static struct tegra_clk_pll_freq_table pll_u_freq_table[] = {
-	{ 12000000, 480000000, 40, 1, 0, 0 },
-	{ 13000000, 480000000, 36, 1, 0, 0 }, /* actual: 468.0 MHz */
-	{ 38400000, 480000000, 25, 2, 0, 0 },
+	{ 12000000, 480000000, 40, 1, 1, 0 },
+	{ 13000000, 480000000, 36, 1, 1, 0 }, /* actual: 468.0 MHz */
+	{ 38400000, 480000000, 25, 2, 1, 0 },
 	{        0,         0,  0, 0, 0, 0 },
 };
 
@@ -3343,6 +3343,7 @@ static struct tegra_clk_init_table init_table[] __initdata = {
 	{ TEGRA210_CLK_DFLL_REF, TEGRA210_CLK_PLL_P, 51000000, 1 },
 	{ TEGRA210_CLK_SBC4, TEGRA210_CLK_PLL_P, 12000000, 1 },
 	{ TEGRA210_CLK_PLL_RE_VCO, TEGRA210_CLK_CLK_MAX, 672000000, 1 },
+	{ TEGRA210_CLK_PLL_U_OUT1, TEGRA210_CLK_CLK_MAX, 48000000, 1 },
 	{ TEGRA210_CLK_XUSB_GATE, TEGRA210_CLK_CLK_MAX, 0, 1 },
 	{ TEGRA210_CLK_XUSB_SS_SRC, TEGRA210_CLK_PLL_U_480M, 120000000, 0 },
 	{ TEGRA210_CLK_XUSB_FS_SRC, TEGRA210_CLK_PLL_U_48M, 48000000, 0 },
@@ -3367,7 +3368,6 @@ static struct tegra_clk_init_table init_table[] __initdata = {
 	{ TEGRA210_CLK_PLL_DP, TEGRA210_CLK_CLK_MAX, 270000000, 0 },
 	{ TEGRA210_CLK_SOC_THERM, TEGRA210_CLK_PLL_P, 51000000, 0 },
 	{ TEGRA210_CLK_CCLK_G, TEGRA210_CLK_CLK_MAX, 0, 1 },
-	{ TEGRA210_CLK_PLL_U_OUT1, TEGRA210_CLK_CLK_MAX, 48000000, 1 },
 	{ TEGRA210_CLK_PLL_U_OUT2, TEGRA210_CLK_CLK_MAX, 60000000, 1 },
 	/* This MUST be the last entry. */
 	{ TEGRA210_CLK_CLK_MAX, TEGRA210_CLK_CLK_MAX, 0, 0 },
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 13/74] fs/adfs: super: fix use-after-free bug
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (11 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 12/74] clk: tegra210: fix PLLU and PLLU_OUT1 Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 14/74] clk: sprd: Add check for return value of sprd_clk_regmap_init() Greg Kroah-Hartman
                   ` (65 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Russell King, Al Viro, Sasha Levin

[ Upstream commit 5808b14a1f52554de612fee85ef517199855e310 ]

Fix a use-after-free bug during filesystem initialisation, where we
access the disc record (which is stored in a buffer) after we have
released the buffer.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 fs/adfs/super.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/adfs/super.c b/fs/adfs/super.c
index 7e099a7a4eb1e..4dc15b2634894 100644
--- a/fs/adfs/super.c
+++ b/fs/adfs/super.c
@@ -369,6 +369,7 @@ static int adfs_fill_super(struct super_block *sb, void *data, int silent)
 	struct buffer_head *bh;
 	struct object_info root_obj;
 	unsigned char *b_data;
+	unsigned int blocksize;
 	struct adfs_sb_info *asb;
 	struct inode *root;
 	int ret = -EINVAL;
@@ -420,8 +421,10 @@ static int adfs_fill_super(struct super_block *sb, void *data, int silent)
 		goto error_free_bh;
 	}
 
+	blocksize = 1 << dr->log2secsize;
 	brelse(bh);
-	if (sb_set_blocksize(sb, 1 << dr->log2secsize)) {
+
+	if (sb_set_blocksize(sb, blocksize)) {
 		bh = sb_bread(sb, ADFS_DISCRECORD / sb->s_blocksize);
 		if (!bh) {
 			adfs_error(sb, "couldn't read superblock on "
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 14/74] clk: sprd: Add check for return value of sprd_clk_regmap_init()
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (12 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 13/74] fs/adfs: super: fix use-after-free bug Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 15/74] btrfs: fix minimum number of chunk errors for DUP Greg Kroah-Hartman
                   ` (64 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Chunyan Zhang, Baolin Wang,
	Stephen Boyd, Sasha Levin

[ Upstream commit c974c48deeb969c5e4250e4f06af91edd84b1f10 ]

sprd_clk_regmap_init() doesn't always return success, adding check
for its return value should make the code more strong.

Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
Reviewed-by: Baolin Wang <baolin.wang@linaro.org>
[sboyd@kernel.org: Add a missing int ret]
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/clk/sprd/sc9860-clk.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/sprd/sc9860-clk.c b/drivers/clk/sprd/sc9860-clk.c
index 9980ab55271ba..f76305b4bc8df 100644
--- a/drivers/clk/sprd/sc9860-clk.c
+++ b/drivers/clk/sprd/sc9860-clk.c
@@ -2023,6 +2023,7 @@ static int sc9860_clk_probe(struct platform_device *pdev)
 {
 	const struct of_device_id *match;
 	const struct sprd_clk_desc *desc;
+	int ret;
 
 	match = of_match_node(sprd_sc9860_clk_ids, pdev->dev.of_node);
 	if (!match) {
@@ -2031,7 +2032,9 @@ static int sc9860_clk_probe(struct platform_device *pdev)
 	}
 
 	desc = match->data;
-	sprd_clk_regmap_init(pdev, desc);
+	ret = sprd_clk_regmap_init(pdev, desc);
+	if (ret)
+		return ret;
 
 	return sprd_clk_probe(&pdev->dev, desc->hw_clks);
 }
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 15/74] btrfs: fix minimum number of chunk errors for DUP
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (13 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 14/74] clk: sprd: Add check for return value of sprd_clk_regmap_init() Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 16/74] btrfs: qgroup: Dont hold qgroup_ioctl_lock in btrfs_qgroup_inherit() Greg Kroah-Hartman
                   ` (63 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Qu Wenruo, David Sterba, Sasha Levin

[ Upstream commit 0ee5f8ae082e1f675a2fb6db601c31ac9958a134 ]

The list of profiles in btrfs_chunk_max_errors lists DUP as a profile
DUP able to tolerate 1 device missing. Though this profile is special
with 2 copies, it still needs the device, unlike the others.

Looking at the history of changes, thre's no clear reason why DUP is
there, functions were refactored and blocks of code merged to one
helper.

d20983b40e828 Btrfs: fix writing data into the seed filesystem
  - factor code to a helper

de11cc12df173 Btrfs: don't pre-allocate btrfs bio
  - unrelated change, DUP still in the list with max errors 1

a236aed14ccb0 Btrfs: Deal with failed writes in mirrored configurations
  - introduced the max errors, leaves DUP and RAID1 in the same group

Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 fs/btrfs/volumes.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 2fd000308be76..6e008bd5c8cd1 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -5040,8 +5040,7 @@ static inline int btrfs_chunk_max_errors(struct map_lookup *map)
 
 	if (map->type & (BTRFS_BLOCK_GROUP_RAID1 |
 			 BTRFS_BLOCK_GROUP_RAID10 |
-			 BTRFS_BLOCK_GROUP_RAID5 |
-			 BTRFS_BLOCK_GROUP_DUP)) {
+			 BTRFS_BLOCK_GROUP_RAID5)) {
 		max_errors = 1;
 	} else if (map->type & BTRFS_BLOCK_GROUP_RAID6) {
 		max_errors = 2;
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 16/74] btrfs: qgroup: Dont hold qgroup_ioctl_lock in btrfs_qgroup_inherit()
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (14 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 15/74] btrfs: fix minimum number of chunk errors for DUP Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 17/74] cifs: Fix a race condition with cifs_echo_request Greg Kroah-Hartman
                   ` (62 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Nikolay Borisov, Qu Wenruo,
	David Sterba, Sasha Levin

[ Upstream commit e88439debd0a7f969b3ddba6f147152cd0732676 ]

[BUG]
Lockdep will report the following circular locking dependency:

  WARNING: possible circular locking dependency detected
  5.2.0-rc2-custom #24 Tainted: G           O
  ------------------------------------------------------
  btrfs/8631 is trying to acquire lock:
  000000002536438c (&fs_info->qgroup_ioctl_lock#2){+.+.}, at: btrfs_qgroup_inherit+0x40/0x620 [btrfs]

  but task is already holding lock:
  000000003d52cc23 (&fs_info->tree_log_mutex){+.+.}, at: create_pending_snapshot+0x8b6/0xe60 [btrfs]

  which lock already depends on the new lock.

  the existing dependency chain (in reverse order) is:

  -> #2 (&fs_info->tree_log_mutex){+.+.}:
         __mutex_lock+0x76/0x940
         mutex_lock_nested+0x1b/0x20
         btrfs_commit_transaction+0x475/0xa00 [btrfs]
         btrfs_commit_super+0x71/0x80 [btrfs]
         close_ctree+0x2bd/0x320 [btrfs]
         btrfs_put_super+0x15/0x20 [btrfs]
         generic_shutdown_super+0x72/0x110
         kill_anon_super+0x18/0x30
         btrfs_kill_super+0x16/0xa0 [btrfs]
         deactivate_locked_super+0x3a/0x80
         deactivate_super+0x51/0x60
         cleanup_mnt+0x3f/0x80
         __cleanup_mnt+0x12/0x20
         task_work_run+0x94/0xb0
         exit_to_usermode_loop+0xd8/0xe0
         do_syscall_64+0x210/0x240
         entry_SYSCALL_64_after_hwframe+0x49/0xbe

  -> #1 (&fs_info->reloc_mutex){+.+.}:
         __mutex_lock+0x76/0x940
         mutex_lock_nested+0x1b/0x20
         btrfs_commit_transaction+0x40d/0xa00 [btrfs]
         btrfs_quota_enable+0x2da/0x730 [btrfs]
         btrfs_ioctl+0x2691/0x2b40 [btrfs]
         do_vfs_ioctl+0xa9/0x6d0
         ksys_ioctl+0x67/0x90
         __x64_sys_ioctl+0x1a/0x20
         do_syscall_64+0x65/0x240
         entry_SYSCALL_64_after_hwframe+0x49/0xbe

  -> #0 (&fs_info->qgroup_ioctl_lock#2){+.+.}:
         lock_acquire+0xa7/0x190
         __mutex_lock+0x76/0x940
         mutex_lock_nested+0x1b/0x20
         btrfs_qgroup_inherit+0x40/0x620 [btrfs]
         create_pending_snapshot+0x9d7/0xe60 [btrfs]
         create_pending_snapshots+0x94/0xb0 [btrfs]
         btrfs_commit_transaction+0x415/0xa00 [btrfs]
         btrfs_mksubvol+0x496/0x4e0 [btrfs]
         btrfs_ioctl_snap_create_transid+0x174/0x180 [btrfs]
         btrfs_ioctl_snap_create_v2+0x11c/0x180 [btrfs]
         btrfs_ioctl+0xa90/0x2b40 [btrfs]
         do_vfs_ioctl+0xa9/0x6d0
         ksys_ioctl+0x67/0x90
         __x64_sys_ioctl+0x1a/0x20
         do_syscall_64+0x65/0x240
         entry_SYSCALL_64_after_hwframe+0x49/0xbe

  other info that might help us debug this:

  Chain exists of:
    &fs_info->qgroup_ioctl_lock#2 --> &fs_info->reloc_mutex --> &fs_info->tree_log_mutex

   Possible unsafe locking scenario:

         CPU0                    CPU1
         ----                    ----
    lock(&fs_info->tree_log_mutex);
                                 lock(&fs_info->reloc_mutex);
                                 lock(&fs_info->tree_log_mutex);
    lock(&fs_info->qgroup_ioctl_lock#2);

   *** DEADLOCK ***

  6 locks held by btrfs/8631:
   #0: 00000000ed8f23f6 (sb_writers#12){.+.+}, at: mnt_want_write_file+0x28/0x60
   #1: 000000009fb1597a (&type->i_mutex_dir_key#10/1){+.+.}, at: btrfs_mksubvol+0x70/0x4e0 [btrfs]
   #2: 0000000088c5ad88 (&fs_info->subvol_sem){++++}, at: btrfs_mksubvol+0x128/0x4e0 [btrfs]
   #3: 000000009606fc3e (sb_internal#2){.+.+}, at: start_transaction+0x37a/0x520 [btrfs]
   #4: 00000000f82bbdf5 (&fs_info->reloc_mutex){+.+.}, at: btrfs_commit_transaction+0x40d/0xa00 [btrfs]
   #5: 000000003d52cc23 (&fs_info->tree_log_mutex){+.+.}, at: create_pending_snapshot+0x8b6/0xe60 [btrfs]

[CAUSE]
Due to the delayed subvolume creation, we need to call
btrfs_qgroup_inherit() inside commit transaction code, with a lot of
other mutex hold.
This hell of lock chain can lead to above problem.

[FIX]
On the other hand, we don't really need to hold qgroup_ioctl_lock if
we're in the context of create_pending_snapshot().
As in that context, we're the only one being able to modify qgroup.

All other qgroup functions which needs qgroup_ioctl_lock are either
holding a transaction handle, or will start a new transaction:
  Functions will start a new transaction():
  * btrfs_quota_enable()
  * btrfs_quota_disable()
  Functions hold a transaction handler:
  * btrfs_add_qgroup_relation()
  * btrfs_del_qgroup_relation()
  * btrfs_create_qgroup()
  * btrfs_remove_qgroup()
  * btrfs_limit_qgroup()
  * btrfs_qgroup_inherit() call inside create_subvol()

So we have a higher level protection provided by transaction, thus we
don't need to always hold qgroup_ioctl_lock in btrfs_qgroup_inherit().

Only the btrfs_qgroup_inherit() call in create_subvol() needs to hold
qgroup_ioctl_lock, while the btrfs_qgroup_inherit() call in
create_pending_snapshot() is already protected by transaction.

So the fix is to detect the context by checking
trans->transaction->state.
If we're at TRANS_STATE_COMMIT_DOING, then we're in commit transaction
context and no need to get the mutex.

Reported-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 fs/btrfs/qgroup.c | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
index e46e83e876001..734866ab51941 100644
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -2249,6 +2249,7 @@ int btrfs_qgroup_inherit(struct btrfs_trans_handle *trans, u64 srcid,
 	int ret = 0;
 	int i;
 	u64 *i_qgroups;
+	bool committing = false;
 	struct btrfs_fs_info *fs_info = trans->fs_info;
 	struct btrfs_root *quota_root;
 	struct btrfs_qgroup *srcgroup;
@@ -2256,7 +2257,25 @@ int btrfs_qgroup_inherit(struct btrfs_trans_handle *trans, u64 srcid,
 	u32 level_size = 0;
 	u64 nums;
 
-	mutex_lock(&fs_info->qgroup_ioctl_lock);
+	/*
+	 * There are only two callers of this function.
+	 *
+	 * One in create_subvol() in the ioctl context, which needs to hold
+	 * the qgroup_ioctl_lock.
+	 *
+	 * The other one in create_pending_snapshot() where no other qgroup
+	 * code can modify the fs as they all need to either start a new trans
+	 * or hold a trans handler, thus we don't need to hold
+	 * qgroup_ioctl_lock.
+	 * This would avoid long and complex lock chain and make lockdep happy.
+	 */
+	spin_lock(&fs_info->trans_lock);
+	if (trans->transaction->state == TRANS_STATE_COMMIT_DOING)
+		committing = true;
+	spin_unlock(&fs_info->trans_lock);
+
+	if (!committing)
+		mutex_lock(&fs_info->qgroup_ioctl_lock);
 	if (!test_bit(BTRFS_FS_QUOTA_ENABLED, &fs_info->flags))
 		goto out;
 
@@ -2420,7 +2439,8 @@ int btrfs_qgroup_inherit(struct btrfs_trans_handle *trans, u64 srcid,
 unlock:
 	spin_unlock(&fs_info->qgroup_lock);
 out:
-	mutex_unlock(&fs_info->qgroup_ioctl_lock);
+	if (!committing)
+		mutex_unlock(&fs_info->qgroup_ioctl_lock);
 	return ret;
 }
 
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 17/74] cifs: Fix a race condition with cifs_echo_request
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (15 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 16/74] btrfs: qgroup: Dont hold qgroup_ioctl_lock in btrfs_qgroup_inherit() Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 18/74] ceph: fix improper use of smp_mb__before_atomic() Greg Kroah-Hartman
                   ` (61 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Ronnie Sahlberg, Pavel Shilovsky,
	Steve French, Sasha Levin

[ Upstream commit f2caf901c1b7ce65f9e6aef4217e3241039db768 ]

There is a race condition with how we send (or supress and don't send)
smb echos that will cause the client to incorrectly think the
server is unresponsive and thus needs to be reconnected.

Summary of the race condition:
 1) Daisy chaining scheduling creates a gap.
 2) If traffic comes unfortunate shortly after
    the last echo, the planned echo is suppressed.
 3) Due to the gap, the next echo transmission is delayed
    until after the timeout, which is set hard to twice
    the echo interval.

This is fixed by changing the timeouts from 2 to three times the echo interval.

Detailed description of the bug: https://lutz.donnerhacke.de/eng/Blog/Groundhog-Day-with-SMB-remount

Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 fs/cifs/connect.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index f31339db45fdb..c53a2e86ed544 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -563,10 +563,10 @@ static bool
 server_unresponsive(struct TCP_Server_Info *server)
 {
 	/*
-	 * We need to wait 2 echo intervals to make sure we handle such
+	 * We need to wait 3 echo intervals to make sure we handle such
 	 * situations right:
 	 * 1s  client sends a normal SMB request
-	 * 2s  client gets a response
+	 * 3s  client gets a response
 	 * 30s echo workqueue job pops, and decides we got a response recently
 	 *     and don't need to send another
 	 * ...
@@ -575,9 +575,9 @@ server_unresponsive(struct TCP_Server_Info *server)
 	 */
 	if ((server->tcpStatus == CifsGood ||
 	    server->tcpStatus == CifsNeedNegotiate) &&
-	    time_after(jiffies, server->lstrp + 2 * server->echo_interval)) {
+	    time_after(jiffies, server->lstrp + 3 * server->echo_interval)) {
 		cifs_dbg(VFS, "Server %s has not responded in %lu seconds. Reconnecting...\n",
-			 server->hostname, (2 * server->echo_interval) / HZ);
+			 server->hostname, (3 * server->echo_interval) / HZ);
 		cifs_reconnect(server);
 		wake_up(&server->response_q);
 		return true;
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 18/74] ceph: fix improper use of smp_mb__before_atomic()
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (16 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 17/74] cifs: Fix a race condition with cifs_echo_request Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 19/74] ceph: return -ERANGE if virtual xattr value didnt fit in buffer Greg Kroah-Hartman
                   ` (60 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Paul E. McKenney, Peter Zijlstra,
	Andrea Parri, Yan, Zheng, Ilya Dryomov, Sasha Levin

[ Upstream commit 749607731e26dfb2558118038c40e9c0c80d23b5 ]

This barrier only applies to the read-modify-write operations; in
particular, it does not apply to the atomic64_set() primitive.

Replace the barrier with an smp_mb().

Fixes: fdd4e15838e59 ("ceph: rework dcache readdir")
Reported-by: "Paul E. McKenney" <paulmck@linux.ibm.com>
Reported-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Andrea Parri <andrea.parri@amarulasolutions.com>
Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 fs/ceph/super.h | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/ceph/super.h b/fs/ceph/super.h
index 582e28fd1b7bf..d8579a56e5dc2 100644
--- a/fs/ceph/super.h
+++ b/fs/ceph/super.h
@@ -526,7 +526,12 @@ static inline void __ceph_dir_set_complete(struct ceph_inode_info *ci,
 					   long long release_count,
 					   long long ordered_count)
 {
-	smp_mb__before_atomic();
+	/*
+	 * Makes sure operations that setup readdir cache (update page
+	 * cache and i_size) are strongly ordered w.r.t. the following
+	 * atomic64_set() operations.
+	 */
+	smp_mb();
 	atomic64_set(&ci->i_complete_seq[0], release_count);
 	atomic64_set(&ci->i_complete_seq[1], ordered_count);
 }
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 19/74] ceph: return -ERANGE if virtual xattr value didnt fit in buffer
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (17 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 18/74] ceph: fix improper use of smp_mb__before_atomic() Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 20/74] ACPI: blacklist: fix clang warning for unused DMI table Greg Kroah-Hartman
                   ` (59 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Jeff Layton, Yan, Zheng,
	Ilya Dryomov, Sasha Levin

[ Upstream commit 3b421018f48c482bdc9650f894aa1747cf90e51d ]

The getxattr manpage states that we should return ERANGE if the
destination buffer size is too small to hold the value.
ceph_vxattrcb_layout does this internally, but we should be doing
this for all vxattrs.

Fix the only caller of getxattr_cb to check the returned size
against the buffer length and return -ERANGE if it doesn't fit.
Drop the same check in ceph_vxattrcb_layout and just rely on the
caller to handle it.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
Acked-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 fs/ceph/xattr.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/fs/ceph/xattr.c b/fs/ceph/xattr.c
index 5cc8b94f82069..0a2d4898ee163 100644
--- a/fs/ceph/xattr.c
+++ b/fs/ceph/xattr.c
@@ -79,7 +79,7 @@ static size_t ceph_vxattrcb_layout(struct ceph_inode_info *ci, char *val,
 	const char *ns_field = " pool_namespace=";
 	char buf[128];
 	size_t len, total_len = 0;
-	int ret;
+	ssize_t ret;
 
 	pool_ns = ceph_try_get_string(ci->i_layout.pool_ns);
 
@@ -103,11 +103,8 @@ static size_t ceph_vxattrcb_layout(struct ceph_inode_info *ci, char *val,
 	if (pool_ns)
 		total_len += strlen(ns_field) + pool_ns->len;
 
-	if (!size) {
-		ret = total_len;
-	} else if (total_len > size) {
-		ret = -ERANGE;
-	} else {
+	ret = total_len;
+	if (size >= total_len) {
 		memcpy(val, buf, len);
 		ret = len;
 		if (pool_name) {
@@ -817,8 +814,11 @@ ssize_t __ceph_getxattr(struct inode *inode, const char *name, void *value,
 		if (err)
 			return err;
 		err = -ENODATA;
-		if (!(vxattr->exists_cb && !vxattr->exists_cb(ci)))
+		if (!(vxattr->exists_cb && !vxattr->exists_cb(ci))) {
 			err = vxattr->getxattr_cb(ci, value, size);
+			if (size && size < err)
+				err = -ERANGE;
+		}
 		return err;
 	}
 
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 20/74] ACPI: blacklist: fix clang warning for unused DMI table
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (18 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 19/74] ceph: return -ERANGE if virtual xattr value didnt fit in buffer Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 21/74] scsi: zfcp: fix GCC compiler warning emitted with -Wmaybe-uninitialized Greg Kroah-Hartman
                   ` (58 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Nathan Chancellor,
	Rafael J. Wysocki, Sasha Levin

[ Upstream commit b80d6a42bdc97bdb6139107d6034222e9843c6e2 ]

When CONFIG_DMI is disabled, we only have a tentative declaration,
which causes a warning from clang:

drivers/acpi/blacklist.c:20:35: error: tentative array definition assumed to have one element [-Werror]
static const struct dmi_system_id acpi_rev_dmi_table[] __initconst;

As the variable is not actually used here, hide it entirely
in an #ifdef to shut up the warning.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/acpi/blacklist.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
index 995c4d8922b12..761f0c19a4512 100644
--- a/drivers/acpi/blacklist.c
+++ b/drivers/acpi/blacklist.c
@@ -30,7 +30,9 @@
 
 #include "internal.h"
 
+#ifdef CONFIG_DMI
 static const struct dmi_system_id acpi_rev_dmi_table[] __initconst;
+#endif
 
 /*
  * POLICY: If *anything* doesn't work, put it on the blacklist.
@@ -74,7 +76,9 @@ int __init acpi_blacklisted(void)
 	}
 
 	(void)early_acpi_osi_init();
+#ifdef CONFIG_DMI
 	dmi_check_system(acpi_rev_dmi_table);
+#endif
 
 	return blacklisted;
 }
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 21/74] scsi: zfcp: fix GCC compiler warning emitted with -Wmaybe-uninitialized
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (19 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 20/74] ACPI: blacklist: fix clang warning for unused DMI table Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 22/74] perf version: Fix segfault due to missing OPT_END() Greg Kroah-Hartman
                   ` (57 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Benjamin Block, Jens Remus,
	Steffen Maier, Martin K. Petersen, Sasha Levin

[ Upstream commit 484647088826f2f651acbda6bcf9536b8a466703 ]

GCC v9 emits this warning:
      CC      drivers/s390/scsi/zfcp_erp.o
    drivers/s390/scsi/zfcp_erp.c: In function 'zfcp_erp_action_enqueue':
    drivers/s390/scsi/zfcp_erp.c:217:26: warning: 'erp_action' may be used uninitialized in this function [-Wmaybe-uninitialized]
      217 |  struct zfcp_erp_action *erp_action;
          |                          ^~~~~~~~~~

This is a possible false positive case, as also documented in the GCC
documentations:
    https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmaybe-uninitialized

The actual code-sequence is like this:
    Various callers can invoke the function below with the argument "want"
    being one of:
    ZFCP_ERP_ACTION_REOPEN_ADAPTER,
    ZFCP_ERP_ACTION_REOPEN_PORT_FORCED,
    ZFCP_ERP_ACTION_REOPEN_PORT, or
    ZFCP_ERP_ACTION_REOPEN_LUN.

    zfcp_erp_action_enqueue(want, ...)
        ...
        need = zfcp_erp_required_act(want, ...)
            need = want
            ...
            maybe: need = ZFCP_ERP_ACTION_REOPEN_PORT
            maybe: need = ZFCP_ERP_ACTION_REOPEN_ADAPTER
            ...
            return need
        ...
        zfcp_erp_setup_act(need, ...)
            struct zfcp_erp_action *erp_action; // <== line 217
            ...
            switch(need) {
            case ZFCP_ERP_ACTION_REOPEN_LUN:
                    ...
                    erp_action = &zfcp_sdev->erp_action;
                    WARN_ON_ONCE(erp_action->port != port); // <== access
                    ...
                    break;
            case ZFCP_ERP_ACTION_REOPEN_PORT:
            case ZFCP_ERP_ACTION_REOPEN_PORT_FORCED:
                    ...
                    erp_action = &port->erp_action;
                    WARN_ON_ONCE(erp_action->port != port); // <== access
                    ...
                    break;
            case ZFCP_ERP_ACTION_REOPEN_ADAPTER:
                    ...
                    erp_action = &adapter->erp_action;
                    WARN_ON_ONCE(erp_action->port != NULL); // <== access
                    ...
                    break;
            }
            ...
            WARN_ON_ONCE(erp_action->adapter != adapter); // <== access

When zfcp_erp_setup_act() is called, 'need' will never be anything else
than one of the 4 possible enumeration-names that are used in the
switch-case, and 'erp_action' is initialized for every one of them, before
it is used. Thus the warning is a false positive, as documented.

We introduce the extra if{} in the beginning to create an extra code-flow,
so the compiler can be convinced that the switch-case will never see any
other value.

BUG_ON()/BUG() is intentionally not used to not crash anything, should
this ever happen anyway - right now it's impossible, as argued above; and
it doesn't introduce a 'default:' switch-case to retain warnings should
'enum zfcp_erp_act_type' ever be extended and no explicit case be
introduced. See also v5.0 commit 399b6c8bc9f7 ("scsi: zfcp: drop old
default switch case which might paper over missing case").

Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/s390/scsi/zfcp_erp.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/s390/scsi/zfcp_erp.c b/drivers/s390/scsi/zfcp_erp.c
index ebdbc457003fe..332701db7379d 100644
--- a/drivers/s390/scsi/zfcp_erp.c
+++ b/drivers/s390/scsi/zfcp_erp.c
@@ -11,6 +11,7 @@
 #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
 
 #include <linux/kthread.h>
+#include <linux/bug.h>
 #include "zfcp_ext.h"
 #include "zfcp_reqlist.h"
 
@@ -238,6 +239,12 @@ static struct zfcp_erp_action *zfcp_erp_setup_act(int need, u32 act_status,
 	struct zfcp_erp_action *erp_action;
 	struct zfcp_scsi_dev *zfcp_sdev;
 
+	if (WARN_ON_ONCE(need != ZFCP_ERP_ACTION_REOPEN_LUN &&
+			 need != ZFCP_ERP_ACTION_REOPEN_PORT &&
+			 need != ZFCP_ERP_ACTION_REOPEN_PORT_FORCED &&
+			 need != ZFCP_ERP_ACTION_REOPEN_ADAPTER))
+		return NULL;
+
 	switch (need) {
 	case ZFCP_ERP_ACTION_REOPEN_LUN:
 		zfcp_sdev = sdev_to_zfcp(sdev);
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 22/74] perf version: Fix segfault due to missing OPT_END()
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (20 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 21/74] scsi: zfcp: fix GCC compiler warning emitted with -Wmaybe-uninitialized Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 23/74] x86: kvm: avoid constant-conversion warning Greg Kroah-Hartman
                   ` (56 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Ravi Bangoria, Kamalesh Babulal,
	Mamatha Inamdar, Jiri Olsa, Arnaldo Carvalho de Melo,
	Sasha Levin

[ Upstream commit 916c31fff946fae0e05862f9b2435fdb29fd5090 ]

'perf version' on powerpc segfaults when used with non-supported
option:
  # perf version -a
  Segmentation fault (core dumped)

Fix this.

Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Tested-by: Mamatha Inamdar <mamatha4@linux.vnet.ibm.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/20190611030109.20228-1-ravi.bangoria@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 tools/perf/builtin-version.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/builtin-version.c b/tools/perf/builtin-version.c
index 50df168be326d..b02c961046403 100644
--- a/tools/perf/builtin-version.c
+++ b/tools/perf/builtin-version.c
@@ -19,6 +19,7 @@ static struct version version;
 static struct option version_options[] = {
 	OPT_BOOLEAN(0, "build-options", &version.build_options,
 		    "display the build options"),
+	OPT_END(),
 };
 
 static const char * const version_usage[] = {
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 23/74] x86: kvm: avoid constant-conversion warning
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (21 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 22/74] perf version: Fix segfault due to missing OPT_END() Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 24/74] ACPI: fix false-positive -Wuninitialized warning Greg Kroah-Hartman
                   ` (55 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Paolo Bonzini, Sasha Levin

[ Upstream commit a6a6d3b1f867d34ba5bd61aa7bb056b48ca67cff ]

clang finds a contruct suspicious that converts an unsigned
character to a signed integer and back, causing an overflow:

arch/x86/kvm/mmu.c:4605:39: error: implicit conversion from 'int' to 'u8' (aka 'unsigned char') changes value from -205 to 51 [-Werror,-Wconstant-conversion]
                u8 wf = (pfec & PFERR_WRITE_MASK) ? ~w : 0;
                   ~~                               ^~
arch/x86/kvm/mmu.c:4607:38: error: implicit conversion from 'int' to 'u8' (aka 'unsigned char') changes value from -241 to 15 [-Werror,-Wconstant-conversion]
                u8 uf = (pfec & PFERR_USER_MASK) ? ~u : 0;
                   ~~                              ^~
arch/x86/kvm/mmu.c:4609:39: error: implicit conversion from 'int' to 'u8' (aka 'unsigned char') changes value from -171 to 85 [-Werror,-Wconstant-conversion]
                u8 ff = (pfec & PFERR_FETCH_MASK) ? ~x : 0;
                   ~~                               ^~

Add an explicit cast to tell clang that everything works as
intended here.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://github.com/ClangBuiltLinux/linux/issues/95
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/x86/kvm/mmu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index e0f982e35c96b..cdc0c460950f3 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4532,11 +4532,11 @@ static void update_permission_bitmask(struct kvm_vcpu *vcpu,
 		 */
 
 		/* Faults from writes to non-writable pages */
-		u8 wf = (pfec & PFERR_WRITE_MASK) ? ~w : 0;
+		u8 wf = (pfec & PFERR_WRITE_MASK) ? (u8)~w : 0;
 		/* Faults from user mode accesses to supervisor pages */
-		u8 uf = (pfec & PFERR_USER_MASK) ? ~u : 0;
+		u8 uf = (pfec & PFERR_USER_MASK) ? (u8)~u : 0;
 		/* Faults from fetches of non-executable pages*/
-		u8 ff = (pfec & PFERR_FETCH_MASK) ? ~x : 0;
+		u8 ff = (pfec & PFERR_FETCH_MASK) ? (u8)~x : 0;
 		/* Faults from kernel mode fetches of user pages */
 		u8 smepf = 0;
 		/* Faults from kernel mode accesses of user pages */
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 24/74] ACPI: fix false-positive -Wuninitialized warning
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (22 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 23/74] x86: kvm: avoid constant-conversion warning Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 25/74] be2net: Signal that the device cannot transmit during reconfiguration Greg Kroah-Hartman
                   ` (54 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Andy Shevchenko,
	Nathan Chancellor, Rafael J. Wysocki, Sasha Levin

[ Upstream commit dfd6f9ad36368b8dbd5f5a2b2f0a4705ae69a323 ]

clang gets confused by an uninitialized variable in what looks
to it like a never executed code path:

arch/x86/kernel/acpi/boot.c:618:13: error: variable 'polarity' is uninitialized when used here [-Werror,-Wuninitialized]
        polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
                   ^~~~~~~~
arch/x86/kernel/acpi/boot.c:606:32: note: initialize the variable 'polarity' to silence this warning
        int rc, irq, trigger, polarity;
                                      ^
                                       = 0
arch/x86/kernel/acpi/boot.c:617:12: error: variable 'trigger' is uninitialized when used here [-Werror,-Wuninitialized]
        trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
                  ^~~~~~~
arch/x86/kernel/acpi/boot.c:606:22: note: initialize the variable 'trigger' to silence this warning
        int rc, irq, trigger, polarity;
                            ^
                             = 0

This is unfortunately a design decision in clang and won't be fixed.

Changing the acpi_get_override_irq() macro to an inline function
reliably avoids the issue.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 include/linux/acpi.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index de8d3d3fa6512..b4d23b3a2ef2d 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -326,7 +326,10 @@ void acpi_set_irq_model(enum acpi_irq_model_id model,
 #ifdef CONFIG_X86_IO_APIC
 extern int acpi_get_override_irq(u32 gsi, int *trigger, int *polarity);
 #else
-#define acpi_get_override_irq(gsi, trigger, polarity) (-1)
+static inline int acpi_get_override_irq(u32 gsi, int *trigger, int *polarity)
+{
+	return -1;
+}
 #endif
 /*
  * This function undoes the effect of one call to acpi_register_gsi().
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 25/74] be2net: Signal that the device cannot transmit during reconfiguration
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (23 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 24/74] ACPI: fix false-positive -Wuninitialized warning Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 26/74] x86/apic: Silence -Wtype-limits compiler warnings Greg Kroah-Hartman
                   ` (53 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Benjamin Poirier, David S. Miller,
	Sasha Levin

[ Upstream commit 7429c6c0d9cb086d8e79f0d2a48ae14851d2115e ]

While changing the number of interrupt channels, be2net stops adapter
operation (including netif_tx_disable()) but it doesn't signal that it
cannot transmit. This may lead dev_watchdog() to falsely trigger during
that time.

Add the missing call to netif_carrier_off(), following the pattern used in
many other drivers. netif_carrier_on() is already taken care of in
be_open().

Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/net/ethernet/emulex/benet/be_main.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index bff74752cef16..3fe6a28027fe1 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -4700,8 +4700,12 @@ int be_update_queues(struct be_adapter *adapter)
 	struct net_device *netdev = adapter->netdev;
 	int status;
 
-	if (netif_running(netdev))
+	if (netif_running(netdev)) {
+		/* device cannot transmit now, avoid dev_watchdog timeouts */
+		netif_carrier_off(netdev);
+
 		be_close(netdev);
+	}
 
 	be_cancel_worker(adapter);
 
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 26/74] x86/apic: Silence -Wtype-limits compiler warnings
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (24 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 25/74] be2net: Signal that the device cannot transmit during reconfiguration Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 27/74] x86: math-emu: Hide clang warnings for 16-bit overflow Greg Kroah-Hartman
                   ` (52 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Qian Cai, Thomas Gleixner, Sasha Levin

[ Upstream commit ec6335586953b0df32f83ef696002063090c7aef ]

There are many compiler warnings like this,

In file included from ./arch/x86/include/asm/smp.h:13,
                 from ./arch/x86/include/asm/mmzone_64.h:11,
                 from ./arch/x86/include/asm/mmzone.h:5,
                 from ./include/linux/mmzone.h:969,
                 from ./include/linux/gfp.h:6,
                 from ./include/linux/mm.h:10,
                 from arch/x86/kernel/apic/io_apic.c:34:
arch/x86/kernel/apic/io_apic.c: In function 'check_timer':
./arch/x86/include/asm/apic.h:37:11: warning: comparison of unsigned
expression >= 0 is always true [-Wtype-limits]
   if ((v) <= apic_verbosity) \
           ^~
arch/x86/kernel/apic/io_apic.c:2160:2: note: in expansion of macro
'apic_printk'
  apic_printk(APIC_QUIET, KERN_INFO "..TIMER: vector=0x%02X "
  ^~~~~~~~~~~
./arch/x86/include/asm/apic.h:37:11: warning: comparison of unsigned
expression >= 0 is always true [-Wtype-limits]
   if ((v) <= apic_verbosity) \
           ^~
arch/x86/kernel/apic/io_apic.c:2207:4: note: in expansion of macro
'apic_printk'
    apic_printk(APIC_QUIET, KERN_ERR "..MP-BIOS bug: "
    ^~~~~~~~~~~

APIC_QUIET is 0, so silence them by making apic_verbosity type int.

Signed-off-by: Qian Cai <cai@lca.pw>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/1562621805-24789-1-git-send-email-cai@lca.pw
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/x86/include/asm/apic.h | 2 +-
 arch/x86/kernel/apic/apic.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 130e81e10fc7c..050368db9d357 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -48,7 +48,7 @@ static inline void generic_apic_probe(void)
 
 #ifdef CONFIG_X86_LOCAL_APIC
 
-extern unsigned int apic_verbosity;
+extern int apic_verbosity;
 extern int local_apic_timer_c2_ok;
 
 extern int disable_apic;
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 02020f2e00809..272a12865b2aa 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -181,7 +181,7 @@ EXPORT_SYMBOL_GPL(local_apic_timer_c2_ok);
 /*
  * Debug level, exported for io_apic.c
  */
-unsigned int apic_verbosity;
+int apic_verbosity;
 
 int pic_mode;
 
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 27/74] x86: math-emu: Hide clang warnings for 16-bit overflow
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (25 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 26/74] x86/apic: Silence -Wtype-limits compiler warnings Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 28/74] mm/cma.c: fail if fixed declaration cant be honored Greg Kroah-Hartman
                   ` (51 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Thomas Gleixner, Sasha Levin

[ Upstream commit 29e7e9664aec17b94a9c8c5a75f8d216a206aa3a ]

clang warns about a few parts of the math-emu implementation
where a 16-bit integer becomes negative during assignment:

arch/x86/math-emu/poly_tan.c:88:35: error: implicit conversion from 'int' to 'short' changes value from 49216 to -16320 [-Werror,-Wconstant-conversion]
                                      (0x41 + EXTENDED_Ebias) | SIGN_Negative);
                                      ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
arch/x86/math-emu/fpu_emu.h:180:58: note: expanded from macro 'setexponent16'
 #define setexponent16(x,y)  { (*(short *)&((x)->exp)) = (y); }
                                                      ~  ^
arch/x86/math-emu/reg_constant.c:37:32: error: implicit conversion from 'int' to 'short' changes value from 49085 to -16451 [-Werror,-Wconstant-conversion]
FPU_REG const CONST_PI2extra = MAKE_REG(NEG, -66,
                               ^~~~~~~~~~~~~~~~~~
arch/x86/math-emu/reg_constant.c:21:25: note: expanded from macro 'MAKE_REG'
                ((EXTENDED_Ebias+(e)) | ((SIGN_##s != 0)*0x8000)) }
                 ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/math-emu/reg_constant.c:48:28: error: implicit conversion from 'int' to 'short' changes value from 65535 to -1 [-Werror,-Wconstant-conversion]
FPU_REG const CONST_QNaN = MAKE_REG(NEG, EXP_OVER, 0x00000000, 0xC0000000);
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/math-emu/reg_constant.c:21:25: note: expanded from macro 'MAKE_REG'
                ((EXTENDED_Ebias+(e)) | ((SIGN_##s != 0)*0x8000)) }
                 ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~

The code is correct as is, so add a typecast to shut up the warnings.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20190712090816.350668-1-arnd@arndb.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/x86/math-emu/fpu_emu.h      | 2 +-
 arch/x86/math-emu/reg_constant.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/math-emu/fpu_emu.h b/arch/x86/math-emu/fpu_emu.h
index a5a41ec580721..0c122226ca56f 100644
--- a/arch/x86/math-emu/fpu_emu.h
+++ b/arch/x86/math-emu/fpu_emu.h
@@ -177,7 +177,7 @@ static inline void reg_copy(FPU_REG const *x, FPU_REG *y)
 #define setexponentpos(x,y) { (*(short *)&((x)->exp)) = \
   ((y) + EXTENDED_Ebias) & 0x7fff; }
 #define exponent16(x)         (*(short *)&((x)->exp))
-#define setexponent16(x,y)  { (*(short *)&((x)->exp)) = (y); }
+#define setexponent16(x,y)  { (*(short *)&((x)->exp)) = (u16)(y); }
 #define addexponent(x,y)    { (*(short *)&((x)->exp)) += (y); }
 #define stdexp(x)           { (*(short *)&((x)->exp)) += EXTENDED_Ebias; }
 
diff --git a/arch/x86/math-emu/reg_constant.c b/arch/x86/math-emu/reg_constant.c
index 8dc9095bab224..742619e94bdf2 100644
--- a/arch/x86/math-emu/reg_constant.c
+++ b/arch/x86/math-emu/reg_constant.c
@@ -18,7 +18,7 @@
 #include "control_w.h"
 
 #define MAKE_REG(s, e, l, h) { l, h, \
-		((EXTENDED_Ebias+(e)) | ((SIGN_##s != 0)*0x8000)) }
+		(u16)((EXTENDED_Ebias+(e)) | ((SIGN_##s != 0)*0x8000)) }
 
 FPU_REG const CONST_1 = MAKE_REG(POS, 0, 0x00000000, 0x80000000);
 #if 0
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 28/74] mm/cma.c: fail if fixed declaration cant be honored
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (26 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 27/74] x86: math-emu: Hide clang warnings for 16-bit overflow Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 29/74] lib/test_overflow.c: avoid tainting the kernel and fix wrap size Greg Kroah-Hartman
                   ` (50 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Doug Berger, Michal Nazarewicz,
	Yue Hu, Mike Rapoport, Laura Abbott, Peng Fan, Thomas Gleixner,
	Marek Szyprowski, Andrey Konovalov, Andrew Morton,
	Linus Torvalds, Sasha Levin

[ Upstream commit c633324e311243586675e732249339685e5d6faa ]

The description of cma_declare_contiguous() indicates that if the
'fixed' argument is true the reserved contiguous area must be exactly at
the address of the 'base' argument.

However, the function currently allows the 'base', 'size', and 'limit'
arguments to be silently adjusted to meet alignment constraints.  This
commit enforces the documented behavior through explicit checks that
return an error if the region does not fit within a specified region.

Link: http://lkml.kernel.org/r/1561422051-16142-1-git-send-email-opendmb@gmail.com
Fixes: 5ea3b1b2f8ad ("cma: add placement specifier for "cma=" kernel parameter")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Cc: Yue Hu <huyue2@yulong.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 mm/cma.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/mm/cma.c b/mm/cma.c
index 476dfe13a701f..4c2864270a39b 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -282,6 +282,12 @@ int __init cma_declare_contiguous(phys_addr_t base,
 	 */
 	alignment = max(alignment,  (phys_addr_t)PAGE_SIZE <<
 			  max_t(unsigned long, MAX_ORDER - 1, pageblock_order));
+	if (fixed && base & (alignment - 1)) {
+		ret = -EINVAL;
+		pr_err("Region at %pa must be aligned to %pa bytes\n",
+			&base, &alignment);
+		goto err;
+	}
 	base = ALIGN(base, alignment);
 	size = ALIGN(size, alignment);
 	limit &= ~(alignment - 1);
@@ -312,6 +318,13 @@ int __init cma_declare_contiguous(phys_addr_t base,
 	if (limit == 0 || limit > memblock_end)
 		limit = memblock_end;
 
+	if (base + size > limit) {
+		ret = -EINVAL;
+		pr_err("Size (%pa) of region at %pa exceeds limit (%pa)\n",
+			&size, &base, &limit);
+		goto err;
+	}
+
 	/* Reserve memory */
 	if (fixed) {
 		if (memblock_is_region_reserved(base, size) ||
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 29/74] lib/test_overflow.c: avoid tainting the kernel and fix wrap size
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (27 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 28/74] mm/cma.c: fail if fixed declaration cant be honored Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 30/74] lib/test_string.c: avoid masking memset16/32/64 failures Greg Kroah-Hartman
                   ` (49 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Kees Cook, Randy Dunlap,
	Rasmus Villemoes, Joe Perches, Andrew Morton, Linus Torvalds,
	Sasha Levin

[ Upstream commit 8e060c21ae2c265a2b596e9e7f9f97ec274151a4 ]

This adds __GFP_NOWARN to the kmalloc()-portions of the overflow test to
avoid tainting the kernel.  Additionally fixes up the math on wrap size
to be architecture and page size agnostic.

Link: http://lkml.kernel.org/r/201905282012.0A8767E24@keescook
Fixes: ca90800a91ba ("test_overflow: Add memory allocation overflow tests")
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 lib/test_overflow.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/lib/test_overflow.c b/lib/test_overflow.c
index fc680562d8b69..7a4b6f6c5473c 100644
--- a/lib/test_overflow.c
+++ b/lib/test_overflow.c
@@ -486,16 +486,17 @@ static int __init test_overflow_shift(void)
  * Deal with the various forms of allocator arguments. See comments above
  * the DEFINE_TEST_ALLOC() instances for mapping of the "bits".
  */
-#define alloc010(alloc, arg, sz) alloc(sz, GFP_KERNEL)
-#define alloc011(alloc, arg, sz) alloc(sz, GFP_KERNEL, NUMA_NO_NODE)
+#define alloc_GFP		 (GFP_KERNEL | __GFP_NOWARN)
+#define alloc010(alloc, arg, sz) alloc(sz, alloc_GFP)
+#define alloc011(alloc, arg, sz) alloc(sz, alloc_GFP, NUMA_NO_NODE)
 #define alloc000(alloc, arg, sz) alloc(sz)
 #define alloc001(alloc, arg, sz) alloc(sz, NUMA_NO_NODE)
-#define alloc110(alloc, arg, sz) alloc(arg, sz, GFP_KERNEL)
+#define alloc110(alloc, arg, sz) alloc(arg, sz, alloc_GFP)
 #define free0(free, arg, ptr)	 free(ptr)
 #define free1(free, arg, ptr)	 free(arg, ptr)
 
-/* Wrap around to 8K */
-#define TEST_SIZE		(9 << PAGE_SHIFT)
+/* Wrap around to 16K */
+#define TEST_SIZE		(5 * 4096)
 
 #define DEFINE_TEST_ALLOC(func, free_func, want_arg, want_gfp, want_node)\
 static int __init test_ ## func (void *arg)				\
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 30/74] lib/test_string.c: avoid masking memset16/32/64 failures
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (28 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 29/74] lib/test_overflow.c: avoid tainting the kernel and fix wrap size Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 31/74] coda: add error handling for fget Greg Kroah-Hartman
                   ` (48 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Peter Rosin, Andrew Morton,
	Linus Torvalds, Sasha Levin

[ Upstream commit 33d6e0ff68af74be0c846c8e042e84a9a1a0561e ]

If a memsetXX implementation is completely broken and fails in the first
iteration, when i, j, and k are all zero, the failure is masked as zero
is returned.  Failing in the first iteration is perhaps the most likely
failure, so this makes the tests pretty much useless.  Avoid the
situation by always setting a random unused bit in the result on
failure.

Link: http://lkml.kernel.org/r/20190506124634.6807-3-peda@axentia.se
Fixes: 03270c13c5ff ("lib/string.c: add testcases for memset16/32/64")
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 lib/test_string.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/test_string.c b/lib/test_string.c
index 0fcdb82dca866..98a787e7a1fd6 100644
--- a/lib/test_string.c
+++ b/lib/test_string.c
@@ -35,7 +35,7 @@ static __init int memset16_selftest(void)
 fail:
 	kfree(p);
 	if (i < 256)
-		return (i << 24) | (j << 16) | k;
+		return (i << 24) | (j << 16) | k | 0x8000;
 	return 0;
 }
 
@@ -71,7 +71,7 @@ static __init int memset32_selftest(void)
 fail:
 	kfree(p);
 	if (i < 256)
-		return (i << 24) | (j << 16) | k;
+		return (i << 24) | (j << 16) | k | 0x8000;
 	return 0;
 }
 
@@ -107,7 +107,7 @@ static __init int memset64_selftest(void)
 fail:
 	kfree(p);
 	if (i < 256)
-		return (i << 24) | (j << 16) | k;
+		return (i << 24) | (j << 16) | k | 0x8000;
 	return 0;
 }
 
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 31/74] coda: add error handling for fget
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (29 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 30/74] lib/test_string.c: avoid masking memset16/32/64 failures Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 32/74] coda: fix build using bare-metal toolchain Greg Kroah-Hartman
                   ` (47 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Zhouyang Jia, Jan Harkes,
	Arnd Bergmann, Colin Ian King, Dan Carpenter, David Howells,
	Fabian Frederick, Mikko Rapeli, Sam Protsenko, Yann Droneaud,
	Andrew Morton, Linus Torvalds, Sasha Levin

[ Upstream commit 02551c23bcd85f0c68a8259c7b953d49d44f86af ]

When fget fails, the lack of error-handling code may cause unexpected
results.

This patch adds error-handling code after calling fget.

Link: http://lkml.kernel.org/r/2514ec03df9c33b86e56748513267a80dd8004d9.1558117389.git.jaharkes@cs.cmu.edu
Signed-off-by: Zhouyang Jia <jiazhouyang09@gmail.com>
Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Fabian Frederick <fabf@skynet.be>
Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
Cc: Sam Protsenko <semen.protsenko@linaro.org>
Cc: Yann Droneaud <ydroneaud@opteya.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 fs/coda/psdev.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/coda/psdev.c b/fs/coda/psdev.c
index c5234c21b5394..55824cba32453 100644
--- a/fs/coda/psdev.c
+++ b/fs/coda/psdev.c
@@ -187,8 +187,11 @@ static ssize_t coda_psdev_write(struct file *file, const char __user *buf,
 	if (req->uc_opcode == CODA_OPEN_BY_FD) {
 		struct coda_open_by_fd_out *outp =
 			(struct coda_open_by_fd_out *)req->uc_data;
-		if (!outp->oh.result)
+		if (!outp->oh.result) {
 			outp->fh = fget(outp->fd);
+			if (!outp->fh)
+				return -EBADF;
+		}
 	}
 
         wake_up(&req->uc_sleep);
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 32/74] coda: fix build using bare-metal toolchain
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (30 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 31/74] coda: add error handling for fget Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 33/74] uapi linux/coda_psdev.h: move upc_req definition from uapi to kernel side headers Greg Kroah-Hartman
                   ` (46 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Sam Protsenko, Jan Harkes,
	Arnd Bergmann, Colin Ian King, Dan Carpenter, David Howells,
	Fabian Frederick, Mikko Rapeli, Yann Droneaud, Zhouyang Jia,
	Andrew Morton, Linus Torvalds, Sasha Levin

[ Upstream commit b2a57e334086602be56b74958d9f29b955cd157f ]

The kernel is self-contained project and can be built with bare-metal
toolchain.  But bare-metal toolchain doesn't define __linux__.  Because
of this u_quad_t type is not defined when using bare-metal toolchain and
codafs build fails.  This patch fixes it by defining u_quad_t type
unconditionally.

Link: http://lkml.kernel.org/r/3cbb40b0a57b6f9923a9d67b53473c0b691a3eaa.1558117389.git.jaharkes@cs.cmu.edu
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Fabian Frederick <fabf@skynet.be>
Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
Cc: Yann Droneaud <ydroneaud@opteya.com>
Cc: Zhouyang Jia <jiazhouyang09@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 include/linux/coda.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/linux/coda.h b/include/linux/coda.h
index d30209b9cef81..0ca0c83fdb1c4 100644
--- a/include/linux/coda.h
+++ b/include/linux/coda.h
@@ -58,8 +58,7 @@ Mellon the rights to redistribute these changes without encumbrance.
 #ifndef _CODA_HEADER_
 #define _CODA_HEADER_
 
-#if defined(__linux__)
 typedef unsigned long long u_quad_t;
-#endif
+
 #include <uapi/linux/coda.h>
 #endif 
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 33/74] uapi linux/coda_psdev.h: move upc_req definition from uapi to kernel side headers
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (31 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 32/74] coda: fix build using bare-metal toolchain Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 34/74] drivers/rapidio/devices/rio_mport_cdev.c: NUL terminate some strings Greg Kroah-Hartman
                   ` (45 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Mikko Rapeli, Jan Harkes,
	Arnd Bergmann, Colin Ian King, Dan Carpenter, David Howells,
	Fabian Frederick, Sam Protsenko, Yann Droneaud, Zhouyang Jia,
	Andrew Morton, Linus Torvalds, Sasha Levin

[ Upstream commit f90fb3c7e2c13ae829db2274b88b845a75038b8a ]

Only users of upc_req in kernel side fs/coda/psdev.c and
fs/coda/upcall.c already include linux/coda_psdev.h.

Suggested by Jan Harkes <jaharkes@cs.cmu.edu> in
  https://lore.kernel.org/lkml/20150531111913.GA23377@cs.cmu.edu/

Fixes these include/uapi/linux/coda_psdev.h compilation errors in userspace:

  linux/coda_psdev.h:12:19: error: field `uc_chain' has incomplete type
  struct list_head    uc_chain;
                   ^
  linux/coda_psdev.h:13:2: error: unknown type name `caddr_t'
  caddr_t             uc_data;
  ^
  linux/coda_psdev.h:14:2: error: unknown type name `u_short'
  u_short             uc_flags;
  ^
  linux/coda_psdev.h:15:2: error: unknown type name `u_short'
  u_short             uc_inSize;  /* Size is at most 5000 bytes */
  ^
  linux/coda_psdev.h:16:2: error: unknown type name `u_short'
  u_short             uc_outSize;
  ^
  linux/coda_psdev.h:17:2: error: unknown type name `u_short'
  u_short             uc_opcode;  /* copied from data to save lookup */
  ^
  linux/coda_psdev.h:19:2: error: unknown type name `wait_queue_head_t'
  wait_queue_head_t   uc_sleep;   /* process' wait queue */
  ^

Link: http://lkml.kernel.org/r/9f99f5ce6a0563d5266e6cf7aa9585aac2cae971.1558117389.git.jaharkes@cs.cmu.edu
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Fabian Frederick <fabf@skynet.be>
Cc: Sam Protsenko <semen.protsenko@linaro.org>
Cc: Yann Droneaud <ydroneaud@opteya.com>
Cc: Zhouyang Jia <jiazhouyang09@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 include/linux/coda_psdev.h      | 11 +++++++++++
 include/uapi/linux/coda_psdev.h | 13 -------------
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/include/linux/coda_psdev.h b/include/linux/coda_psdev.h
index 15170954aa2b3..57d2b2faf6a3e 100644
--- a/include/linux/coda_psdev.h
+++ b/include/linux/coda_psdev.h
@@ -19,6 +19,17 @@ struct venus_comm {
 	struct mutex	    vc_mutex;
 };
 
+/* messages between coda filesystem in kernel and Venus */
+struct upc_req {
+	struct list_head	uc_chain;
+	caddr_t			uc_data;
+	u_short			uc_flags;
+	u_short			uc_inSize;  /* Size is at most 5000 bytes */
+	u_short			uc_outSize;
+	u_short			uc_opcode;  /* copied from data to save lookup */
+	int			uc_unique;
+	wait_queue_head_t	uc_sleep;   /* process' wait queue */
+};
 
 static inline struct venus_comm *coda_vcp(struct super_block *sb)
 {
diff --git a/include/uapi/linux/coda_psdev.h b/include/uapi/linux/coda_psdev.h
index aa6623efd2dd0..d50d51a57fe4e 100644
--- a/include/uapi/linux/coda_psdev.h
+++ b/include/uapi/linux/coda_psdev.h
@@ -7,19 +7,6 @@
 #define CODA_PSDEV_MAJOR 67
 #define MAX_CODADEVS  5	   /* how many do we allow */
 
-
-/* messages between coda filesystem in kernel and Venus */
-struct upc_req {
-	struct list_head    uc_chain;
-	caddr_t	            uc_data;
-	u_short	            uc_flags;
-	u_short             uc_inSize;  /* Size is at most 5000 bytes */
-	u_short	            uc_outSize;
-	u_short	            uc_opcode;  /* copied from data to save lookup */
-	int		    uc_unique;
-	wait_queue_head_t   uc_sleep;   /* process' wait queue */
-};
-
 #define CODA_REQ_ASYNC  0x1
 #define CODA_REQ_READ   0x2
 #define CODA_REQ_WRITE  0x4
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 34/74] drivers/rapidio/devices/rio_mport_cdev.c: NUL terminate some strings
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (32 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 33/74] uapi linux/coda_psdev.h: move upc_req definition from uapi to kernel side headers Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 35/74] ipc/mqueue.c: only perform resource calculation if user valid Greg Kroah-Hartman
                   ` (44 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Alexandre Bounine,
	Ira Weiny, Andrew Morton, Linus Torvalds, Sasha Levin

[ Upstream commit 156e0b1a8112b76e351684ac948c59757037ac36 ]

The dev_info.name[] array has space for RIO_MAX_DEVNAME_SZ + 1
characters.  But the problem here is that we don't ensure that the user
put a NUL terminator on the end of the string.  It could lead to an out
of bounds read.

Link: http://lkml.kernel.org/r/20190529110601.GB19119@mwanda
Fixes: e8de370188d0 ("rapidio: add mport char device driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Alexandre Bounine <alex.bou9@gmail.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/rapidio/devices/rio_mport_cdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/rapidio/devices/rio_mport_cdev.c b/drivers/rapidio/devices/rio_mport_cdev.c
index cbe467ff1aba9..fa0bbda4b3f2e 100644
--- a/drivers/rapidio/devices/rio_mport_cdev.c
+++ b/drivers/rapidio/devices/rio_mport_cdev.c
@@ -1688,6 +1688,7 @@ static int rio_mport_add_riodev(struct mport_cdev_priv *priv,
 
 	if (copy_from_user(&dev_info, arg, sizeof(dev_info)))
 		return -EFAULT;
+	dev_info.name[sizeof(dev_info.name) - 1] = '\0';
 
 	rmcd_debug(RDEV, "name:%s ct:0x%x did:0x%x hc:0x%x", dev_info.name,
 		   dev_info.comptag, dev_info.destid, dev_info.hopcount);
@@ -1819,6 +1820,7 @@ static int rio_mport_del_riodev(struct mport_cdev_priv *priv, void __user *arg)
 
 	if (copy_from_user(&dev_info, arg, sizeof(dev_info)))
 		return -EFAULT;
+	dev_info.name[sizeof(dev_info.name) - 1] = '\0';
 
 	mport = priv->md->mport;
 
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 35/74] ipc/mqueue.c: only perform resource calculation if user valid
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (33 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 34/74] drivers/rapidio/devices/rio_mport_cdev.c: NUL terminate some strings Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 36/74] mlxsw: spectrum_dcb: Configure DSCP map as the last rule is removed Greg Kroah-Hartman
                   ` (43 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Kees Cook, Andreas Christoforou,
	Eric W. Biederman, Al Viro, Arnd Bergmann, Davidlohr Bueso,
	Manfred Spraul, Andrew Morton, Linus Torvalds, Sasha Levin

[ Upstream commit a318f12ed8843cfac53198390c74a565c632f417 ]

Andreas Christoforou reported:

  UBSAN: Undefined behaviour in ipc/mqueue.c:414:49 signed integer overflow:
  9 * 2305843009213693951 cannot be represented in type 'long int'
  ...
  Call Trace:
    mqueue_evict_inode+0x8e7/0xa10 ipc/mqueue.c:414
    evict+0x472/0x8c0 fs/inode.c:558
    iput_final fs/inode.c:1547 [inline]
    iput+0x51d/0x8c0 fs/inode.c:1573
    mqueue_get_inode+0x8eb/0x1070 ipc/mqueue.c:320
    mqueue_create_attr+0x198/0x440 ipc/mqueue.c:459
    vfs_mkobj+0x39e/0x580 fs/namei.c:2892
    prepare_open ipc/mqueue.c:731 [inline]
    do_mq_open+0x6da/0x8e0 ipc/mqueue.c:771

Which could be triggered by:

        struct mq_attr attr = {
                .mq_flags = 0,
                .mq_maxmsg = 9,
                .mq_msgsize = 0x1fffffffffffffff,
                .mq_curmsgs = 0,
        };

        if (mq_open("/testing", 0x40, 3, &attr) == (mqd_t) -1)
                perror("mq_open");

mqueue_get_inode() was correctly rejecting the giant mq_msgsize, and
preparing to return -EINVAL.  During the cleanup, it calls
mqueue_evict_inode() which performed resource usage tracking math for
updating "user", before checking if there was a valid "user" at all
(which would indicate that the calculations would be sane).  Instead,
delay this check to after seeing a valid "user".

The overflow was real, but the results went unused, so while the flaw is
harmless, it's noisy for kernel fuzzers, so just fix it by moving the
calculation under the non-NULL "user" where it actually gets used.

Link: http://lkml.kernel.org/r/201906072207.ECB65450@keescook
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Andreas Christoforou <andreaschristofo@gmail.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 ipc/mqueue.c | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index bce7af1546d9c..de4070d5472f2 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -389,7 +389,6 @@ static void mqueue_evict_inode(struct inode *inode)
 {
 	struct mqueue_inode_info *info;
 	struct user_struct *user;
-	unsigned long mq_bytes, mq_treesize;
 	struct ipc_namespace *ipc_ns;
 	struct msg_msg *msg, *nmsg;
 	LIST_HEAD(tmp_msg);
@@ -412,16 +411,18 @@ static void mqueue_evict_inode(struct inode *inode)
 		free_msg(msg);
 	}
 
-	/* Total amount of bytes accounted for the mqueue */
-	mq_treesize = info->attr.mq_maxmsg * sizeof(struct msg_msg) +
-		min_t(unsigned int, info->attr.mq_maxmsg, MQ_PRIO_MAX) *
-		sizeof(struct posix_msg_tree_node);
-
-	mq_bytes = mq_treesize + (info->attr.mq_maxmsg *
-				  info->attr.mq_msgsize);
-
 	user = info->user;
 	if (user) {
+		unsigned long mq_bytes, mq_treesize;
+
+		/* Total amount of bytes accounted for the mqueue */
+		mq_treesize = info->attr.mq_maxmsg * sizeof(struct msg_msg) +
+			min_t(unsigned int, info->attr.mq_maxmsg, MQ_PRIO_MAX) *
+			sizeof(struct posix_msg_tree_node);
+
+		mq_bytes = mq_treesize + (info->attr.mq_maxmsg *
+					  info->attr.mq_msgsize);
+
 		spin_lock(&mq_lock);
 		user->mq_bytes -= mq_bytes;
 		/*
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 36/74] mlxsw: spectrum_dcb: Configure DSCP map as the last rule is removed
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (34 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 35/74] ipc/mqueue.c: only perform resource calculation if user valid Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 37/74] xen/pv: Fix a boot up hang revealed by int3 self test Greg Kroah-Hartman
                   ` (42 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Petr Machata, Alex Veber,
	Ido Schimmel, David S. Miller, Sasha Levin

[ Upstream commit dedfde2fe1c4ccf27179fcb234e2112d065c39bb ]

Spectrum systems use DSCP rewrite map to update DSCP field in egressing
packets to correspond to priority that the packet has. Whether rewriting
will take place is determined at the point when the packet ingresses the
switch: if the port is in Trust L3 mode, packet priority is determined from
the DSCP map at the port, and DSCP rewrite will happen. If the port is in
Trust L2 mode, 802.1p is used for packet prioritization, and no DSCP
rewrite will happen.

The driver determines the port trust mode based on whether any DSCP
prioritization rules are in effect at given port. If there are any, trust
level is L3, otherwise it's L2. When the last DSCP rule is removed, the
port is switched to trust L2. Under that scenario, if DSCP of a packet
should be rewritten, it should be rewritten to 0.

However, when switching to Trust L2, the driver neglects to also update the
DSCP rewrite map. The last DSCP rule thus remains in effect, and packets
egressing through this port, if they have the right priority, will have
their DSCP set according to this rule.

Fix by first configuring the rewrite map, and only then switching to trust
L2 and bailing out.

Fixes: b2b1dab6884e ("mlxsw: spectrum: Support ieee_setapp, ieee_delapp")
Signed-off-by: Petr Machata <petrm@mellanox.com>
Reported-by: Alex Veber <alexve@mellanox.com>
Tested-by: Alex Veber <alexve@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 .../net/ethernet/mellanox/mlxsw/spectrum_dcb.c   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c
index b25048c6c7618..21296fa7f7fbf 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c
@@ -408,14 +408,6 @@ static int mlxsw_sp_port_dcb_app_update(struct mlxsw_sp_port *mlxsw_sp_port)
 	have_dscp = mlxsw_sp_port_dcb_app_prio_dscp_map(mlxsw_sp_port,
 							&prio_map);
 
-	if (!have_dscp) {
-		err = mlxsw_sp_port_dcb_toggle_trust(mlxsw_sp_port,
-					MLXSW_REG_QPTS_TRUST_STATE_PCP);
-		if (err)
-			netdev_err(mlxsw_sp_port->dev, "Couldn't switch to trust L2\n");
-		return err;
-	}
-
 	mlxsw_sp_port_dcb_app_dscp_prio_map(mlxsw_sp_port, default_prio,
 					    &dscp_map);
 	err = mlxsw_sp_port_dcb_app_update_qpdpm(mlxsw_sp_port,
@@ -432,6 +424,14 @@ static int mlxsw_sp_port_dcb_app_update(struct mlxsw_sp_port *mlxsw_sp_port)
 		return err;
 	}
 
+	if (!have_dscp) {
+		err = mlxsw_sp_port_dcb_toggle_trust(mlxsw_sp_port,
+					MLXSW_REG_QPTS_TRUST_STATE_PCP);
+		if (err)
+			netdev_err(mlxsw_sp_port->dev, "Couldn't switch to trust L2\n");
+		return err;
+	}
+
 	err = mlxsw_sp_port_dcb_toggle_trust(mlxsw_sp_port,
 					     MLXSW_REG_QPTS_TRUST_STATE_DSCP);
 	if (err) {
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 37/74] xen/pv: Fix a boot up hang revealed by int3 self test
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (35 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 36/74] mlxsw: spectrum_dcb: Configure DSCP map as the last rule is removed Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 38/74] x86/kvm: Dont call kvm_spurious_fault() from .fixup Greg Kroah-Hartman
                   ` (41 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Zhenzhong Duan, Juergen Gross,
	Boris Ostrovsky, Stefano Stabellini, Andy Lutomirski,
	Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Andrew Cooper, Sasha Levin

[ Upstream commit b23e5844dfe78a80ba672793187d3f52e4b528d7 ]

Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
selftest") is used to ensure there is a gap setup in int3 exception stack
which could be used for inserting call return address.

This gap is missed in XEN PV int3 exception entry path, then below panic
triggered:

[    0.772876] general protection fault: 0000 [#1] SMP NOPTI
[    0.772886] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.2.0+ #11
[    0.772893] RIP: e030:int3_magic+0x0/0x7
[    0.772905] RSP: 3507:ffffffff82203e98 EFLAGS: 00000246
[    0.773334] Call Trace:
[    0.773334]  alternative_instructions+0x3d/0x12e
[    0.773334]  check_bugs+0x7c9/0x887
[    0.773334]  ? __get_locked_pte+0x178/0x1f0
[    0.773334]  start_kernel+0x4ff/0x535
[    0.773334]  ? set_init_arg+0x55/0x55
[    0.773334]  xen_start_kernel+0x571/0x57a

For 64bit PV guests, Xen's ABI enters the kernel with using SYSRET, with
%rcx/%r11 on the stack. To convert back to "normal" looking exceptions,
the xen thunks do 'xen_*: pop %rcx; pop %r11; jmp *'.

E.g. Extracting 'xen_pv_trap xenint3' we have:
xen_xenint3:
 pop %rcx;
 pop %r11;
 jmp xenint3

As xenint3 and int3 entry code are same except xenint3 doesn't generate
a gap, we can fix it by using int3 and drop useless xenint3.

Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/x86/entry/entry_64.S    | 1 -
 arch/x86/include/asm/traps.h | 2 +-
 arch/x86/xen/enlighten_pv.c  | 2 +-
 arch/x86/xen/xen-asm_64.S    | 1 -
 4 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 206df099950ea..e7572a209fbe7 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1196,7 +1196,6 @@ idtentry stack_segment		do_stack_segment	has_error_code=1
 #ifdef CONFIG_XEN
 idtentry xennmi			do_nmi			has_error_code=0
 idtentry xendebug		do_debug		has_error_code=0
-idtentry xenint3		do_int3			has_error_code=0
 #endif
 
 idtentry general_protection	do_general_protection	has_error_code=1
diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
index afbc87206886e..b771bb3d159bc 100644
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -40,7 +40,7 @@ asmlinkage void simd_coprocessor_error(void);
 asmlinkage void xen_divide_error(void);
 asmlinkage void xen_xennmi(void);
 asmlinkage void xen_xendebug(void);
-asmlinkage void xen_xenint3(void);
+asmlinkage void xen_int3(void);
 asmlinkage void xen_overflow(void);
 asmlinkage void xen_bounds(void);
 asmlinkage void xen_invalid_op(void);
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 782f98b332f05..1730a26ff6abc 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -597,12 +597,12 @@ struct trap_array_entry {
 
 static struct trap_array_entry trap_array[] = {
 	{ debug,                       xen_xendebug,                    true },
-	{ int3,                        xen_xenint3,                     true },
 	{ double_fault,                xen_double_fault,                true },
 #ifdef CONFIG_X86_MCE
 	{ machine_check,               xen_machine_check,               true },
 #endif
 	{ nmi,                         xen_xennmi,                      true },
+	{ int3,                        xen_int3,                        false },
 	{ overflow,                    xen_overflow,                    false },
 #ifdef CONFIG_IA32_EMULATION
 	{ entry_INT80_compat,          xen_entry_INT80_compat,          false },
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index 417b339e5c8e1..3a6feed76dfc1 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -30,7 +30,6 @@ xen_pv_trap divide_error
 xen_pv_trap debug
 xen_pv_trap xendebug
 xen_pv_trap int3
-xen_pv_trap xenint3
 xen_pv_trap xennmi
 xen_pv_trap overflow
 xen_pv_trap bounds
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 38/74] x86/kvm: Dont call kvm_spurious_fault() from .fixup
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (36 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 37/74] xen/pv: Fix a boot up hang revealed by int3 self test Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 39/74] x86/paravirt: Fix callee-saved function ELF sizes Greg Kroah-Hartman
                   ` (40 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Josh Poimboeuf, Thomas Gleixner,
	Paolo Bonzini, Peter Zijlstra (Intel),
	Sasha Levin

[ Upstream commit 3901336ed9887b075531bffaeef7742ba614058b ]

After making a change to improve objtool's sibling call detection, it
started showing the following warning:

  arch/x86/kvm/vmx/nested.o: warning: objtool: .fixup+0x15: sibling call from callable instruction with modified stack frame

The problem is the ____kvm_handle_fault_on_reboot() macro.  It does a
fake call by pushing a fake RIP and doing a jump.  That tricks the
unwinder into printing the function which triggered the exception,
rather than the .fixup code.

Instead of the hack to make it look like the original function made the
call, just change the macro so that the original function actually does
make the call.  This allows removal of the hack, and also makes objtool
happy.

I triggered a vmx instruction exception and verified that the stack
trace is still sane:

  kernel BUG at arch/x86/kvm/x86.c:358!
  invalid opcode: 0000 [#1] SMP PTI
  CPU: 28 PID: 4096 Comm: qemu-kvm Not tainted 5.2.0+ #16
  Hardware name: Lenovo THINKSYSTEM SD530 -[7X2106Z000]-/-[7X2106Z000]-, BIOS -[TEE113Z-1.00]- 07/17/2017
  RIP: 0010:kvm_spurious_fault+0x5/0x10
  Code: 00 00 00 00 00 8b 44 24 10 89 d2 45 89 c9 48 89 44 24 10 8b 44 24 08 48 89 44 24 08 e9 d4 40 22 00 0f 1f 40 00 0f 1f 44 00 00 <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 55 49 89 fd 41
  RSP: 0018:ffffbf91c683bd00 EFLAGS: 00010246
  RAX: 000061f040000000 RBX: ffff9e159c77bba0 RCX: ffff9e15a5c87000
  RDX: 0000000665c87000 RSI: ffff9e15a5c87000 RDI: ffff9e159c77bba0
  RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9e15a5c87000
  R10: 0000000000000000 R11: fffff8f2d99721c0 R12: ffff9e159c77bba0
  R13: ffffbf91c671d960 R14: ffff9e159c778000 R15: 0000000000000000
  FS:  00007fa341cbe700(0000) GS:ffff9e15b7400000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007fdd38356804 CR3: 00000006759de003 CR4: 00000000007606e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  PKRU: 55555554
  Call Trace:
   loaded_vmcs_init+0x4f/0xe0
   alloc_loaded_vmcs+0x38/0xd0
   vmx_create_vcpu+0xf7/0x600
   kvm_vm_ioctl+0x5e9/0x980
   ? __switch_to_asm+0x40/0x70
   ? __switch_to_asm+0x34/0x70
   ? __switch_to_asm+0x40/0x70
   ? __switch_to_asm+0x34/0x70
   ? free_one_page+0x13f/0x4e0
   do_vfs_ioctl+0xa4/0x630
   ksys_ioctl+0x60/0x90
   __x64_sys_ioctl+0x16/0x20
   do_syscall_64+0x55/0x1c0
   entry_SYSCALL_64_after_hwframe+0x44/0xa9
  RIP: 0033:0x7fa349b1ee5b

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/64a9b64d127e87b6920a97afde8e96ea76f6524e.1563413318.git.jpoimboe@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/x86/include/asm/kvm_host.h | 34 ++++++++++++++++++---------------
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 7014dba23d20c..2877e1fbadd86 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1427,25 +1427,29 @@ enum {
 #define kvm_arch_vcpu_memslots_id(vcpu) ((vcpu)->arch.hflags & HF_SMM_MASK ? 1 : 0)
 #define kvm_memslots_for_spte_role(kvm, role) __kvm_memslots(kvm, (role).smm)
 
+asmlinkage void __noreturn kvm_spurious_fault(void);
+
 /*
  * Hardware virtualization extension instructions may fault if a
  * reboot turns off virtualization while processes are running.
- * Trap the fault and ignore the instruction if that happens.
+ * Usually after catching the fault we just panic; during reboot
+ * instead the instruction is ignored.
  */
-asmlinkage void kvm_spurious_fault(void);
-
-#define ____kvm_handle_fault_on_reboot(insn, cleanup_insn)	\
-	"666: " insn "\n\t" \
-	"668: \n\t"                           \
-	".pushsection .fixup, \"ax\" \n" \
-	"667: \n\t" \
-	cleanup_insn "\n\t"		      \
-	"cmpb $0, kvm_rebooting \n\t"	      \
-	"jne 668b \n\t"      		      \
-	__ASM_SIZE(push) " $666b \n\t"	      \
-	"jmp kvm_spurious_fault \n\t"	      \
-	".popsection \n\t" \
-	_ASM_EXTABLE(666b, 667b)
+#define ____kvm_handle_fault_on_reboot(insn, cleanup_insn)		\
+	"666: \n\t"							\
+	insn "\n\t"							\
+	"jmp	668f \n\t"						\
+	"667: \n\t"							\
+	"call	kvm_spurious_fault \n\t"				\
+	"668: \n\t"							\
+	".pushsection .fixup, \"ax\" \n\t"				\
+	"700: \n\t"							\
+	cleanup_insn "\n\t"						\
+	"cmpb	$0, kvm_rebooting\n\t"					\
+	"je	667b \n\t"						\
+	"jmp	668b \n\t"						\
+	".popsection \n\t"						\
+	_ASM_EXTABLE(666b, 700b)
 
 #define __kvm_handle_fault_on_reboot(insn)		\
 	____kvm_handle_fault_on_reboot(insn, "")
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 39/74] x86/paravirt: Fix callee-saved function ELF sizes
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (37 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 38/74] x86/kvm: Dont call kvm_spurious_fault() from .fixup Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 40/74] x86, boot: Remove multiple copy of static function sanitize_boot_params() Greg Kroah-Hartman
                   ` (39 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Josh Poimboeuf, Thomas Gleixner,
	Juergen Gross, Peter Zijlstra (Intel),
	Sasha Levin

[ Upstream commit 083db6764821996526970e42d09c1ab2f4155dd4 ]

The __raw_callee_save_*() functions have an ELF symbol size of zero,
which confuses objtool and other tools.

Fixes a bunch of warnings like the following:

  arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_pte_val() is missing an ELF size annotation
  arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_pgd_val() is missing an ELF size annotation
  arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_make_pte() is missing an ELF size annotation
  arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_make_pgd() is missing an ELF size annotation

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/afa6d49bb07497ca62e4fc3b27a2d0cece545b4e.1563413318.git.jpoimboe@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/x86/include/asm/paravirt.h | 1 +
 arch/x86/kernel/kvm.c           | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index e375d4266b53e..a04677038872c 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -768,6 +768,7 @@ static __always_inline bool pv_vcpu_is_preempted(long cpu)
 	    PV_RESTORE_ALL_CALLER_REGS					\
 	    FRAME_END							\
 	    "ret;"							\
+	    ".size " PV_THUNK_NAME(func) ", .-" PV_THUNK_NAME(func) ";"	\
 	    ".popsection")
 
 /* Get a reference to a callee-save function */
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 7f89d609095ac..cee45d46e67dc 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -830,6 +830,7 @@ asm(
 "cmpb	$0, " __stringify(KVM_STEAL_TIME_preempted) "+steal_time(%rax);"
 "setne	%al;"
 "ret;"
+".size __raw_callee_save___kvm_vcpu_is_preempted, .-__raw_callee_save___kvm_vcpu_is_preempted;"
 ".popsection");
 
 #endif
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 40/74] x86, boot: Remove multiple copy of static function sanitize_boot_params()
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (38 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 39/74] x86/paravirt: Fix callee-saved function ELF sizes Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 41/74] drm/nouveau: fix memory leak in nouveau_conn_reset() Greg Kroah-Hartman
                   ` (38 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Zhenzhong Duan, Thomas Gleixner, Sasha Levin

[ Upstream commit 8c5477e8046ca139bac250386c08453da37ec1ae ]

Kernel build warns:
 'sanitize_boot_params' defined but not used [-Wunused-function]

at below files:
  arch/x86/boot/compressed/cmdline.c
  arch/x86/boot/compressed/error.c
  arch/x86/boot/compressed/early_serial_console.c
  arch/x86/boot/compressed/acpi.c

That's becausethey each include misc.h which includes a definition of
sanitize_boot_params() via bootparam_utils.h.

Remove the inclusion from misc.h and have the c file including
bootparam_utils.h directly.

Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/1563283092-1189-1-git-send-email-zhenzhong.duan@oracle.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/x86/boot/compressed/misc.c | 1 +
 arch/x86/boot/compressed/misc.h | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 8dd1d5ccae580..0387d7a96c842 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -17,6 +17,7 @@
 #include "pgtable.h"
 #include "../string.h"
 #include "../voffset.h"
+#include <asm/bootparam_utils.h>
 
 /*
  * WARNING!!
diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
index a423bdb426862..47fd18db6b3bf 100644
--- a/arch/x86/boot/compressed/misc.h
+++ b/arch/x86/boot/compressed/misc.h
@@ -22,7 +22,6 @@
 #include <asm/page.h>
 #include <asm/boot.h>
 #include <asm/bootparam.h>
-#include <asm/bootparam_utils.h>
 
 #define BOOT_BOOT_H
 #include "../ctype.h"
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 41/74] drm/nouveau: fix memory leak in nouveau_conn_reset()
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (39 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 40/74] x86, boot: Remove multiple copy of static function sanitize_boot_params() Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 42/74] kconfig: Clear "written" flag to avoid data loss Greg Kroah-Hartman
                   ` (37 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Yongxin Liu, Ben Skeggs, Sasha Levin

[ Upstream commit 09b90e2fe35faeace2488234e2a7728f2ea8ba26 ]

In nouveau_conn_reset(), if connector->state is true,
__drm_atomic_helper_connector_destroy_state() will be called,
but the memory pointed by asyc isn't freed. Memory leak happens
in the following function __drm_atomic_helper_connector_reset(),
where newly allocated asyc->state will be assigned to connector->state.

So using nouveau_conn_atomic_destroy_state() instead of
__drm_atomic_helper_connector_destroy_state to free the "old" asyc.

Here the is the log showing memory leak.

unreferenced object 0xffff8c5480483c80 (size 192):
  comm "kworker/0:2", pid 188, jiffies 4294695279 (age 53.179s)
  hex dump (first 32 bytes):
    00 f0 ba 7b 54 8c ff ff 00 00 00 00 00 00 00 00  ...{T...........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<000000005005c0d0>] kmem_cache_alloc_trace+0x195/0x2c0
    [<00000000a122baed>] nouveau_conn_reset+0x25/0xc0 [nouveau]
    [<000000004fd189a2>] nouveau_connector_create+0x3a7/0x610 [nouveau]
    [<00000000c73343a8>] nv50_display_create+0x343/0x980 [nouveau]
    [<000000002e2b03c3>] nouveau_display_create+0x51f/0x660 [nouveau]
    [<00000000c924699b>] nouveau_drm_device_init+0x182/0x7f0 [nouveau]
    [<00000000cc029436>] nouveau_drm_probe+0x20c/0x2c0 [nouveau]
    [<000000007e961c3e>] local_pci_probe+0x47/0xa0
    [<00000000da14d569>] work_for_cpu_fn+0x1a/0x30
    [<0000000028da4805>] process_one_work+0x27c/0x660
    [<000000001d415b04>] worker_thread+0x22b/0x3f0
    [<0000000003b69f1f>] kthread+0x12f/0x150
    [<00000000c94c29b7>] ret_from_fork+0x3a/0x50

Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 247f72cc4d10a..fb0094fc55834 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -251,7 +251,7 @@ nouveau_conn_reset(struct drm_connector *connector)
 		return;
 
 	if (connector->state)
-		__drm_atomic_helper_connector_destroy_state(connector->state);
+		nouveau_conn_atomic_destroy_state(connector, connector->state);
 	__drm_atomic_helper_connector_reset(connector, &asyc->state);
 	asyc->dither.mode = DITHERING_MODE_AUTO;
 	asyc->dither.depth = DITHERING_DEPTH_AUTO;
-- 
2.20.1




^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 42/74] kconfig: Clear "written" flag to avoid data loss
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (40 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 41/74] drm/nouveau: fix memory leak in nouveau_conn_reset() Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 43/74] kbuild: initialize CLANG_FLAGS correctly in the top Makefile Greg Kroah-Hartman
                   ` (36 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, M. Vefa Bicakci, Masahiro Yamada

From: M. Vefa Bicakci <m.v.b@runbox.com>

commit 0c5b6c28ed68becb692b43eae5e44d5aa7e160ce upstream.

Prior to this commit, starting nconfig, xconfig or gconfig, and saving
the .config file more than once caused data loss, where a .config file
that contained only comments would be written to disk starting from the
second save operation.

This bug manifests itself because the SYMBOL_WRITTEN flag is never
cleared after the first call to conf_write, and subsequent calls to
conf_write then skip all of the configuration symbols due to the
SYMBOL_WRITTEN flag being set.

This commit resolves this issue by clearing the SYMBOL_WRITTEN flag
from all symbols before conf_write returns.

Fixes: 8e2442a5f86e ("kconfig: fix missing choice values in auto.conf")
Cc: linux-stable <stable@vger.kernel.org> # 4.19+
Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 scripts/kconfig/confdata.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -784,6 +784,7 @@ int conf_write(const char *name)
 	const char *str;
 	char dirname[PATH_MAX+1], tmpname[PATH_MAX+22], newname[PATH_MAX+8];
 	char *env;
+	int i;
 
 	dirname[0] = 0;
 	if (name && name[0]) {
@@ -860,6 +861,9 @@ next:
 	}
 	fclose(out);
 
+	for_all_symbols(i, sym)
+		sym->flags &= ~SYMBOL_WRITTEN;
+
 	if (*tmpname) {
 		strcat(dirname, basename);
 		strcat(dirname, ".old");



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 43/74] kbuild: initialize CLANG_FLAGS correctly in the top Makefile
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (41 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 42/74] kconfig: Clear "written" flag to avoid data loss Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 44/74] Btrfs: fix incremental send failure after deduplication Greg Kroah-Hartman
                   ` (35 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Masahiro Yamada, Nathan Chancellor,
	Nick Desaulniers

From: Masahiro Yamada <yamada.masahiro@socionext.com>

commit 5241ab4cf42d3a93b933b55d3d53f43049081fa1 upstream.

CLANG_FLAGS is initialized by the following line:

  CLANG_FLAGS     := --target=$(notdir $(CROSS_COMPILE:%-=%))

..., which is run only when CROSS_COMPILE is set.

Some build targets (bindeb-pkg etc.) recurse to the top Makefile.

When you build the kernel with Clang but without CROSS_COMPILE,
the same compiler flags such as -no-integrated-as are accumulated
into CLANG_FLAGS.

If you run 'make CC=clang' and then 'make CC=clang bindeb-pkg',
Kbuild will recompile everything needlessly due to the build command
change.

Fix this by correctly initializing CLANG_FLAGS.

Fixes: 238bcbc4e07f ("kbuild: consolidate Clang compiler flags")
Cc: <stable@vger.kernel.org> # v5.0+
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 Makefile |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/Makefile
+++ b/Makefile
@@ -430,6 +430,7 @@ KBUILD_CFLAGS_MODULE  := -DMODULE
 KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds
 KBUILD_LDFLAGS :=
 GCC_PLUGINS_CFLAGS :=
+CLANG_FLAGS :=
 
 export ARCH SRCARCH CONFIG_SHELL HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE AS LD CC
 export CPP AR NM STRIP OBJCOPY OBJDUMP KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS
@@ -482,7 +483,7 @@ endif
 
 ifeq ($(cc-name),clang)
 ifneq ($(CROSS_COMPILE),)
-CLANG_FLAGS	:= --target=$(notdir $(CROSS_COMPILE:%-=%))
+CLANG_FLAGS	+= --target=$(notdir $(CROSS_COMPILE:%-=%))
 GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
 CLANG_FLAGS	+= --prefix=$(GCC_TOOLCHAIN_DIR)
 GCC_TOOLCHAIN	:= $(realpath $(GCC_TOOLCHAIN_DIR)/..)



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 44/74] Btrfs: fix incremental send failure after deduplication
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (42 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 43/74] kbuild: initialize CLANG_FLAGS correctly in the top Makefile Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 45/74] Btrfs: fix race leading to fs corruption after transaction abort Greg Kroah-Hartman
                   ` (34 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Filipe Manana, David Sterba

From: Filipe Manana <fdmanana@suse.com>

commit b4f9a1a87a48c255bb90d8a6c3d555a1abb88130 upstream.

When doing an incremental send operation we can fail if we previously did
deduplication operations against a file that exists in both snapshots. In
that case we will fail the send operation with -EIO and print a message
to dmesg/syslog like the following:

  BTRFS error (device sdc): Send: inconsistent snapshot, found updated \
  extent for inode 257 without updated inode item, send root is 258, \
  parent root is 257

This requires that we deduplicate to the same file in both snapshots for
the same amount of times on each snapshot. The issue happens because a
deduplication only updates the iversion of an inode and does not update
any other field of the inode, therefore if we deduplicate the file on
each snapshot for the same amount of time, the inode will have the same
iversion value (stored as the "sequence" field on the inode item) on both
snapshots, therefore it will be seen as unchanged between in the send
snapshot while there are new/updated/deleted extent items when comparing
to the parent snapshot. This makes the send operation return -EIO and
print an error message.

Example reproducer:

  $ mkfs.btrfs -f /dev/sdb
  $ mount /dev/sdb /mnt

  # Create our first file. The first half of the file has several 64Kb
  # extents while the second half as a single 512Kb extent.
  $ xfs_io -f -s -c "pwrite -S 0xb8 -b 64K 0 512K" /mnt/foo
  $ xfs_io -c "pwrite -S 0xb8 512K 512K" /mnt/foo

  # Create the base snapshot and the parent send stream from it.
  $ btrfs subvolume snapshot -r /mnt /mnt/mysnap1
  $ btrfs send -f /tmp/1.snap /mnt/mysnap1

  # Create our second file, that has exactly the same data as the first
  # file.
  $ xfs_io -f -c "pwrite -S 0xb8 0 1M" /mnt/bar

  # Create the second snapshot, used for the incremental send, before
  # doing the file deduplication.
  $ btrfs subvolume snapshot -r /mnt /mnt/mysnap2

  # Now before creating the incremental send stream:
  #
  # 1) Deduplicate into a subrange of file foo in snapshot mysnap1. This
  #    will drop several extent items and add a new one, also updating
  #    the inode's iversion (sequence field in inode item) by 1, but not
  #    any other field of the inode;
  #
  # 2) Deduplicate into a different subrange of file foo in snapshot
  #    mysnap2. This will replace an extent item with a new one, also
  #    updating the inode's iversion by 1 but not any other field of the
  #    inode.
  #
  # After these two deduplication operations, the inode items, for file
  # foo, are identical in both snapshots, but we have different extent
  # items for this inode in both snapshots. We want to check this doesn't
  # cause send to fail with an error or produce an incorrect stream.

  $ xfs_io -r -c "dedupe /mnt/bar 0 0 512K" /mnt/mysnap1/foo
  $ xfs_io -r -c "dedupe /mnt/bar 512K 512K 512K" /mnt/mysnap2/foo

  # Create the incremental send stream.
  $ btrfs send -p /mnt/mysnap1 -f /tmp/2.snap /mnt/mysnap2
  ERROR: send ioctl failed with -5: Input/output error

This issue started happening back in 2015 when deduplication was updated
to not update the inode's ctime and mtime and update only the iversion.
Back then we would hit a BUG_ON() in send, but later in 2016 send was
updated to return -EIO and print the error message instead of doing the
BUG_ON().

A test case for fstests follows soon.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203933
Fixes: 1c919a5e13702c ("btrfs: don't update mtime/ctime on deduped inodes")
CC: stable@vger.kernel.org # 4.4+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/btrfs/send.c |   77 ++++++++++----------------------------------------------
 1 file changed, 15 insertions(+), 62 deletions(-)

--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -6272,68 +6272,21 @@ static int changed_extent(struct send_ct
 {
 	int ret = 0;
 
-	if (sctx->cur_ino != sctx->cmp_key->objectid) {
-
-		if (result == BTRFS_COMPARE_TREE_CHANGED) {
-			struct extent_buffer *leaf_l;
-			struct extent_buffer *leaf_r;
-			struct btrfs_file_extent_item *ei_l;
-			struct btrfs_file_extent_item *ei_r;
-
-			leaf_l = sctx->left_path->nodes[0];
-			leaf_r = sctx->right_path->nodes[0];
-			ei_l = btrfs_item_ptr(leaf_l,
-					      sctx->left_path->slots[0],
-					      struct btrfs_file_extent_item);
-			ei_r = btrfs_item_ptr(leaf_r,
-					      sctx->right_path->slots[0],
-					      struct btrfs_file_extent_item);
-
-			/*
-			 * We may have found an extent item that has changed
-			 * only its disk_bytenr field and the corresponding
-			 * inode item was not updated. This case happens due to
-			 * very specific timings during relocation when a leaf
-			 * that contains file extent items is COWed while
-			 * relocation is ongoing and its in the stage where it
-			 * updates data pointers. So when this happens we can
-			 * safely ignore it since we know it's the same extent,
-			 * but just at different logical and physical locations
-			 * (when an extent is fully replaced with a new one, we
-			 * know the generation number must have changed too,
-			 * since snapshot creation implies committing the current
-			 * transaction, and the inode item must have been updated
-			 * as well).
-			 * This replacement of the disk_bytenr happens at
-			 * relocation.c:replace_file_extents() through
-			 * relocation.c:btrfs_reloc_cow_block().
-			 */
-			if (btrfs_file_extent_generation(leaf_l, ei_l) ==
-			    btrfs_file_extent_generation(leaf_r, ei_r) &&
-			    btrfs_file_extent_ram_bytes(leaf_l, ei_l) ==
-			    btrfs_file_extent_ram_bytes(leaf_r, ei_r) &&
-			    btrfs_file_extent_compression(leaf_l, ei_l) ==
-			    btrfs_file_extent_compression(leaf_r, ei_r) &&
-			    btrfs_file_extent_encryption(leaf_l, ei_l) ==
-			    btrfs_file_extent_encryption(leaf_r, ei_r) &&
-			    btrfs_file_extent_other_encoding(leaf_l, ei_l) ==
-			    btrfs_file_extent_other_encoding(leaf_r, ei_r) &&
-			    btrfs_file_extent_type(leaf_l, ei_l) ==
-			    btrfs_file_extent_type(leaf_r, ei_r) &&
-			    btrfs_file_extent_disk_bytenr(leaf_l, ei_l) !=
-			    btrfs_file_extent_disk_bytenr(leaf_r, ei_r) &&
-			    btrfs_file_extent_disk_num_bytes(leaf_l, ei_l) ==
-			    btrfs_file_extent_disk_num_bytes(leaf_r, ei_r) &&
-			    btrfs_file_extent_offset(leaf_l, ei_l) ==
-			    btrfs_file_extent_offset(leaf_r, ei_r) &&
-			    btrfs_file_extent_num_bytes(leaf_l, ei_l) ==
-			    btrfs_file_extent_num_bytes(leaf_r, ei_r))
-				return 0;
-		}
-
-		inconsistent_snapshot_error(sctx, result, "extent");
-		return -EIO;
-	}
+	/*
+	 * We have found an extent item that changed without the inode item
+	 * having changed. This can happen either after relocation (where the
+	 * disk_bytenr of an extent item is replaced at
+	 * relocation.c:replace_file_extents()) or after deduplication into a
+	 * file in both the parent and send snapshots (where an extent item can
+	 * get modified or replaced with a new one). Note that deduplication
+	 * updates the inode item, but it only changes the iversion (sequence
+	 * field in the inode item) of the inode, so if a file is deduplicated
+	 * the same amount of times in both the parent and send snapshots, its
+	 * iversion becames the same in both snapshots, whence the inode item is
+	 * the same on both snapshots.
+	 */
+	if (sctx->cur_ino != sctx->cmp_key->objectid)
+		return 0;
 
 	if (!sctx->cur_inode_new_gen && !sctx->cur_inode_deleted) {
 		if (result != BTRFS_COMPARE_TREE_DELETED)



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 45/74] Btrfs: fix race leading to fs corruption after transaction abort
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (43 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 44/74] Btrfs: fix incremental send failure after deduplication Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-05 13:02 ` [PATCH 4.19 46/74] mmc: dw_mmc: Fix occasional hang after tuning on eMMC Greg Kroah-Hartman
                   ` (33 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Josef Bacik, Filipe Manana, David Sterba

From: Filipe Manana <fdmanana@suse.com>

commit cb2d3daddbfb6318d170e79aac1f7d5e4d49f0d7 upstream.

When one transaction is finishing its commit, it is possible for another
transaction to start and enter its initial commit phase as well. If the
first ends up getting aborted, we have a small time window where the second
transaction commit does not notice that the previous transaction aborted
and ends up committing, writing a superblock that points to btrees that
reference extent buffers (nodes and leafs) that were not persisted to disk.
The consequence is that after mounting the filesystem again, we will be
unable to load some btree nodes/leafs, either because the content on disk
is either garbage (or just zeroes) or corresponds to the old content of a
previouly COWed or deleted node/leaf, resulting in the well known error
messages "parent transid verify failed on ...".
The following sequence diagram illustrates how this can happen.

        CPU 1                                           CPU 2

 <at transaction N>

 btrfs_commit_transaction()
   (...)
   --> sets transaction state to
       TRANS_STATE_UNBLOCKED
   --> sets fs_info->running_transaction
       to NULL

                                                    (...)
                                                    btrfs_start_transaction()
                                                      start_transaction()
                                                        wait_current_trans()
                                                          --> returns immediately
                                                              because
                                                              fs_info->running_transaction
                                                              is NULL
                                                        join_transaction()
                                                          --> creates transaction N + 1
                                                          --> sets
                                                              fs_info->running_transaction
                                                              to transaction N + 1
                                                          --> adds transaction N + 1 to
                                                              the fs_info->trans_list list
                                                        --> returns transaction handle
                                                            pointing to the new
                                                            transaction N + 1
                                                    (...)

                                                    btrfs_sync_file()
                                                      btrfs_start_transaction()
                                                        --> returns handle to
                                                            transaction N + 1
                                                      (...)

   btrfs_write_and_wait_transaction()
     --> writeback of some extent
         buffer fails, returns an
	 error
   btrfs_handle_fs_error()
     --> sets BTRFS_FS_STATE_ERROR in
         fs_info->fs_state
   --> jumps to label "scrub_continue"
   cleanup_transaction()
     btrfs_abort_transaction(N)
       --> sets BTRFS_FS_STATE_TRANS_ABORTED
           flag in fs_info->fs_state
       --> sets aborted field in the
           transaction and transaction
	   handle structures, for
           transaction N only
     --> removes transaction from the
         list fs_info->trans_list
                                                      btrfs_commit_transaction(N + 1)
                                                        --> transaction N + 1 was not
							    aborted, so it proceeds
                                                        (...)
                                                        --> sets the transaction's state
                                                            to TRANS_STATE_COMMIT_START
                                                        --> does not find the previous
                                                            transaction (N) in the
                                                            fs_info->trans_list, so it
                                                            doesn't know that transaction
                                                            was aborted, and the commit
                                                            of transaction N + 1 proceeds
                                                        (...)
                                                        --> sets transaction N + 1 state
                                                            to TRANS_STATE_UNBLOCKED
                                                        btrfs_write_and_wait_transaction()
                                                          --> succeeds writing all extent
                                                              buffers created in the
                                                              transaction N + 1
                                                        write_all_supers()
                                                           --> succeeds
                                                           --> we now have a superblock on
                                                               disk that points to trees
                                                               that refer to at least one
                                                               extent buffer that was
                                                               never persisted

So fix this by updating the transaction commit path to check if the flag
BTRFS_FS_STATE_TRANS_ABORTED is set on fs_info->fs_state if after setting
the transaction to the TRANS_STATE_COMMIT_START we do not find any previous
transaction in the fs_info->trans_list. If the flag is set, just fail the
transaction commit with -EROFS, as we do in other places. The exact error
code for the previous transaction abort was already logged and reported.

Fixes: 49b25e0540904b ("btrfs: enhance transaction abort infrastructure")
CC: stable@vger.kernel.org # 4.4+
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/btrfs/transaction.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -2027,6 +2027,16 @@ int btrfs_commit_transaction(struct btrf
 		}
 	} else {
 		spin_unlock(&fs_info->trans_lock);
+		/*
+		 * The previous transaction was aborted and was already removed
+		 * from the list of transactions at fs_info->trans_list. So we
+		 * abort to prevent writing a new superblock that reflects a
+		 * corrupt state (pointing to trees with unwritten nodes/leafs).
+		 */
+		if (test_bit(BTRFS_FS_STATE_TRANS_ABORTED, &fs_info->fs_state)) {
+			ret = -EROFS;
+			goto cleanup_transaction;
+		}
 	}
 
 	extwriter_counter_dec(cur_trans, trans->type);



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 46/74] mmc: dw_mmc: Fix occasional hang after tuning on eMMC
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (44 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 45/74] Btrfs: fix race leading to fs corruption after transaction abort Greg Kroah-Hartman
@ 2019-08-05 13:02 ` Greg Kroah-Hartman
  2019-08-06 22:31   ` Pavel Machek
  2019-08-05 13:03 ` [PATCH 4.19 47/74] mmc: meson-mx-sdio: Fix misuse of GENMASK macro Greg Kroah-Hartman
                   ` (32 subsequent siblings)
  78 siblings, 1 reply; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Douglas Anderson, Marek Szyprowski,
	Alim Akhtar, Enric Balletbo i Serra, Ulf Hansson

From: Douglas Anderson <dianders@chromium.org>

commit ba2d139b02ba684c6c101de42fed782d6cd2b997 upstream.

In commit 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after
response errors.") we fixed a tuning-induced hang that I saw when
stress testing tuning on certain SD cards.  I won't re-hash that whole
commit, but the summary is that as a normal part of tuning you need to
deal with transfer errors and there were cases where these transfer
errors was putting my system into a bad state causing all future
transfers to fail.  That commit fixed handling of the transfer errors
for me.

In downstream Chrome OS my fix landed and had the same behavior for
all SD/MMC commands.  However, it looks like when the commit landed
upstream we limited it to only SD tuning commands.  Presumably this
was to try to get around problems that Alim Akhtar reported on exynos
[1].

Unfortunately while stress testing reboots (and suspend/resume) on
some rk3288-based Chromebooks I found the same problem on the eMMC on
some of my Chromebooks (the ones with Hynix eMMC).  Since the eMMC
tuning command is different (MMC_SEND_TUNING_BLOCK_HS200
vs. MMC_SEND_TUNING_BLOCK) we were basically getting back into the
same situation.

I'm hoping that whatever problems exynos was having in the past are
somehow magically fixed now and we can make the behavior the same for
all commands.

[1] https://lkml.kernel.org/r/CAGOxZ53WfNbaMe0_AM0qBqU47kAfgmPBVZC8K8Y-_J3mDMqW4A@mail.gmail.com

Fixes: 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after response errors.")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Alim Akhtar <alim.akhtar@gmail.com>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mmc/host/dw_mmc.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2038,8 +2038,7 @@ static void dw_mci_tasklet_func(unsigned
 				 * delayed. Allowing the transfer to take place
 				 * avoids races and keeps things simple.
 				 */
-				if ((err != -ETIMEDOUT) &&
-				    (cmd->opcode == MMC_SEND_TUNING_BLOCK)) {
+				if (err != -ETIMEDOUT) {
 					state = STATE_SENDING_DATA;
 					continue;
 				}



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 47/74] mmc: meson-mx-sdio: Fix misuse of GENMASK macro
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (45 preceding siblings ...)
  2019-08-05 13:02 ` [PATCH 4.19 46/74] mmc: dw_mmc: Fix occasional hang after tuning on eMMC Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 48/74] gpiolib: fix incorrect IRQ requesting of an active-low lineevent Greg Kroah-Hartman
                   ` (31 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Joe Perches, Neil Armstrong, Ulf Hansson

From: Joe Perches <joe@perches.com>

commit 665e985c2f41bebc3e6cee7e04c36a44afbc58f7 upstream.

Arguments are supposed to be ordered high then low.

Signed-off-by: Joe Perches <joe@perches.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Fixes: ed80a13bb4c4 ("mmc: meson-mx-sdio: Add a driver for the Amlogic
Meson8 and Meson8b SoCs")
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mmc/host/meson-mx-sdio.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/mmc/host/meson-mx-sdio.c
+++ b/drivers/mmc/host/meson-mx-sdio.c
@@ -76,7 +76,7 @@
 	#define MESON_MX_SDIO_IRQC_IF_CONFIG_MASK		GENMASK(7, 6)
 	#define MESON_MX_SDIO_IRQC_FORCE_DATA_CLK		BIT(8)
 	#define MESON_MX_SDIO_IRQC_FORCE_DATA_CMD		BIT(9)
-	#define MESON_MX_SDIO_IRQC_FORCE_DATA_DAT_MASK		GENMASK(10, 13)
+	#define MESON_MX_SDIO_IRQC_FORCE_DATA_DAT_MASK		GENMASK(13, 10)
 	#define MESON_MX_SDIO_IRQC_SOFT_RESET			BIT(15)
 	#define MESON_MX_SDIO_IRQC_FORCE_HALT			BIT(30)
 	#define MESON_MX_SDIO_IRQC_HALT_HOLE			BIT(31)



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 48/74] gpiolib: fix incorrect IRQ requesting of an active-low lineevent
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (46 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 47/74] mmc: meson-mx-sdio: Fix misuse of GENMASK macro Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 49/74] IB/hfi1: Fix Spectre v1 vulnerability Greg Kroah-Hartman
                   ` (30 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Michael Wu, Bartosz Golaszewski

From: Michael Wu <michael.wu@vatics.com>

commit 223ecaf140b1dd1c1d2a1a1d96281efc5c906984 upstream.

When a pin is active-low, logical trigger edge should be inverted to match
the same interrupt opportunity.

For example, a button pushed triggers falling edge in ACTIVE_HIGH case; in
ACTIVE_LOW case, the button pushed triggers rising edge. For user space the
IRQ requesting doesn't need to do any modification except to configuring
GPIOHANDLE_REQUEST_ACTIVE_LOW.

For example, we want to catch the event when the button is pushed. The
button on the original board drives level to be low when it is pushed, and
drives level to be high when it is released.

In user space we can do:

	req.handleflags = GPIOHANDLE_REQUEST_INPUT;
	req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE;

	while (1) {
		read(fd, &dat, sizeof(dat));
		if (dat.id == GPIOEVENT_EVENT_FALLING_EDGE)
			printf("button pushed\n");
	}

Run the same logic on another board which the polarity of the button is
inverted; it drives level to be high when pushed, and level to be low when
released. For this inversion we add flag GPIOHANDLE_REQUEST_ACTIVE_LOW:

	req.handleflags = GPIOHANDLE_REQUEST_INPUT |
		GPIOHANDLE_REQUEST_ACTIVE_LOW;
	req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE;

At the result, there are no any events caught when the button is pushed.
By the way, button releasing will emit a "falling" event. The timing of
"falling" catching is not expected.

Cc: stable@vger.kernel.org
Signed-off-by: Michael Wu <michael.wu@vatics.com>
Tested-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpio/gpiolib.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -946,9 +946,11 @@ static int lineevent_create(struct gpio_
 	}
 
 	if (eflags & GPIOEVENT_REQUEST_RISING_EDGE)
-		irqflags |= IRQF_TRIGGER_RISING;
+		irqflags |= test_bit(FLAG_ACTIVE_LOW, &desc->flags) ?
+			IRQF_TRIGGER_FALLING : IRQF_TRIGGER_RISING;
 	if (eflags & GPIOEVENT_REQUEST_FALLING_EDGE)
-		irqflags |= IRQF_TRIGGER_FALLING;
+		irqflags |= test_bit(FLAG_ACTIVE_LOW, &desc->flags) ?
+			IRQF_TRIGGER_RISING : IRQF_TRIGGER_FALLING;
 	irqflags |= IRQF_ONESHOT;
 	irqflags |= IRQF_SHARED;
 



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 49/74] IB/hfi1: Fix Spectre v1 vulnerability
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (47 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 48/74] gpiolib: fix incorrect IRQ requesting of an active-low lineevent Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 50/74] mtd: rawnand: micron: handle on-die "ECC-off" devices correctly Greg Kroah-Hartman
                   ` (29 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Gustavo A. R. Silva, Doug Ledford

From: Gustavo A. R. Silva <gustavo@embeddedor.com>

commit 6497d0a9c53df6e98b25e2b79f2295d7caa47b6e upstream.

sl is controlled by user-space, hence leading to a potential
exploitation of the Spectre variant 1 vulnerability.

Fix this by sanitizing sl before using it to index ibp->sl_to_sc.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20190731175428.GA16736@embeddedor
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/hw/hfi1/verbs.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/infiniband/hw/hfi1/verbs.c
+++ b/drivers/infiniband/hw/hfi1/verbs.c
@@ -54,6 +54,7 @@
 #include <linux/mm.h>
 #include <linux/vmalloc.h>
 #include <rdma/opa_addr.h>
+#include <linux/nospec.h>
 
 #include "hfi.h"
 #include "common.h"
@@ -1596,6 +1597,7 @@ static int hfi1_check_ah(struct ib_devic
 	sl = rdma_ah_get_sl(ah_attr);
 	if (sl >= ARRAY_SIZE(ibp->sl_to_sc))
 		return -EINVAL;
+	sl = array_index_nospec(sl, ARRAY_SIZE(ibp->sl_to_sc));
 
 	sc5 = ibp->sl_to_sc[sl];
 	if (sc_to_vlt(dd, sc5) > num_vls && sc_to_vlt(dd, sc5) != 0xf)



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 50/74] mtd: rawnand: micron: handle on-die "ECC-off" devices correctly
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (48 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 49/74] IB/hfi1: Fix Spectre v1 vulnerability Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 51/74] selinux: fix memory leak in policydb_init() Greg Kroah-Hartman
                   ` (28 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Marco Felsch, Boris Brezillon, Miquel Raynal

From: Marco Felsch <m.felsch@pengutronix.de>

commit 8493b2a06fc5b77ef5c579dc32b12761f7b7a84c upstream.

Some devices are not supposed to support on-die ECC but experience
shows that internal ECC machinery can actually be enabled through the
"SET FEATURE (EFh)" command, even if a read of the "READ ID Parameter
Tables" returns that it is not.

Currently, the driver checks the "READ ID Parameter" field directly
after having enabled the feature. If the check fails it returns
immediately but leaves the ECC on. When using buggy chips like
MT29F2G08ABAGA and MT29F2G08ABBGA, all future read/program cycles will
go through the on-die ECC, confusing the host controller which is
supposed to be the one handling correction.

To address this in a common way we need to turn off the on-die ECC
directly after reading the "READ ID Parameter" and before checking the
"ECC status".

Cc: stable@vger.kernel.org
Fixes: dbc44edbf833 ("mtd: rawnand: micron: Fix on-die ECC detection logic")
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mtd/nand/raw/nand_micron.c |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

--- a/drivers/mtd/nand/raw/nand_micron.c
+++ b/drivers/mtd/nand/raw/nand_micron.c
@@ -400,6 +400,14 @@ static int micron_supports_on_die_ecc(st
 	    (chip->id.data[4] & MICRON_ID_INTERNAL_ECC_MASK) != 0x2)
 		return MICRON_ON_DIE_UNSUPPORTED;
 
+	/*
+	 * It seems that there are devices which do not support ECC officially.
+	 * At least the MT29F2G08ABAGA / MT29F2G08ABBGA devices supports
+	 * enabling the ECC feature but don't reflect that to the READ_ID table.
+	 * So we have to guarantee that we disable the ECC feature directly
+	 * after we did the READ_ID table command. Later we can evaluate the
+	 * ECC_ENABLE support.
+	 */
 	ret = micron_nand_on_die_ecc_setup(chip, true);
 	if (ret)
 		return MICRON_ON_DIE_UNSUPPORTED;
@@ -408,13 +416,13 @@ static int micron_supports_on_die_ecc(st
 	if (ret)
 		return MICRON_ON_DIE_UNSUPPORTED;
 
-	if (!(id[4] & MICRON_ID_ECC_ENABLED))
-		return MICRON_ON_DIE_UNSUPPORTED;
-
 	ret = micron_nand_on_die_ecc_setup(chip, false);
 	if (ret)
 		return MICRON_ON_DIE_UNSUPPORTED;
 
+	if (!(id[4] & MICRON_ID_ECC_ENABLED))
+		return MICRON_ON_DIE_UNSUPPORTED;
+
 	ret = nand_readid_op(chip, 0, id, sizeof(id));
 	if (ret)
 		return MICRON_ON_DIE_UNSUPPORTED;



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 51/74] selinux: fix memory leak in policydb_init()
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (49 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 50/74] mtd: rawnand: micron: handle on-die "ECC-off" devices correctly Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 52/74] ALSA: hda: Fix 1-minute detection delay when i915 module is not available Greg Kroah-Hartman
                   ` (27 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, syzbot+fee3a14d4cdf92646287,
	Ondrej Mosnacek, Paul Moore

From: Ondrej Mosnacek <omosnace@redhat.com>

commit 45385237f65aeee73641f1ef737d7273905a233f upstream.

Since roles_init() adds some entries to the role hash table, we need to
destroy also its keys/values on error, otherwise we get a memory leak in
the error path.

Cc: <stable@vger.kernel.org>
Reported-by: syzbot+fee3a14d4cdf92646287@syzkaller.appspotmail.com
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 security/selinux/ss/policydb.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -275,6 +275,8 @@ static int rangetr_cmp(struct hashtab *h
 	return v;
 }
 
+static int (*destroy_f[SYM_NUM]) (void *key, void *datum, void *datap);
+
 /*
  * Initialize a policy database structure.
  */
@@ -322,8 +324,10 @@ static int policydb_init(struct policydb
 out:
 	hashtab_destroy(p->filename_trans);
 	hashtab_destroy(p->range_tr);
-	for (i = 0; i < SYM_NUM; i++)
+	for (i = 0; i < SYM_NUM; i++) {
+		hashtab_map(p->symtab[i].table, destroy_f[i], NULL);
 		hashtab_destroy(p->symtab[i].table);
+	}
 	return rc;
 }
 



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 52/74] ALSA: hda: Fix 1-minute detection delay when i915 module is not available
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (50 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 51/74] selinux: fix memory leak in policydb_init() Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 53/74] mm: vmscan: check if mem cgroup is disabled or not before calling memcg slab shrinker Greg Kroah-Hartman
                   ` (26 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Samuel Thibault, Takashi Iwai

From: Samuel Thibault <samuel.thibault@ens-lyon.org>

commit 74bf71ed792ab0f64631cc65ccdb54c356c36d45 upstream.

Distribution installation images such as Debian include different sets
of modules which can be downloaded dynamically.  Such images may notably
include the hda sound modules but not the i915 DRM module, even if the
latter was enabled at build time, as reported on
https://bugs.debian.org/931507

In such a case hdac_i915 would be linked in and try to load the i915
module, fail since it is not there, but still wait for a whole minute
before giving up binding with it.

This fixes such as case by only waiting for the binding if the module
was properly loaded (or module support is disabled, in which case i915
is already compiled-in anyway).

Fixes: f9b54e1961c7 ("ALSA: hda/i915: Allow delayed i915 audio component binding")
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/hda/hdac_i915.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -143,10 +143,12 @@ int snd_hdac_i915_init(struct hdac_bus *
 	if (!acomp)
 		return -ENODEV;
 	if (!acomp->ops) {
-		request_module("i915");
-		/* 60s timeout */
-		wait_for_completion_timeout(&bind_complete,
-					    msecs_to_jiffies(60 * 1000));
+		if (!IS_ENABLED(CONFIG_MODULES) ||
+		    !request_module("i915")) {
+			/* 60s timeout */
+			wait_for_completion_timeout(&bind_complete,
+						   msecs_to_jiffies(60 * 1000));
+		}
 	}
 	if (!acomp->ops) {
 		dev_info(bus->dev, "couldn't bind with audio component\n");



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 53/74] mm: vmscan: check if mem cgroup is disabled or not before calling memcg slab shrinker
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (51 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 52/74] ALSA: hda: Fix 1-minute detection delay when i915 module is not available Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 54/74] s390/dasd: fix endless loop after read unit address configuration Greg Kroah-Hartman
                   ` (25 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Yang Shi, Shakeel Butt, Kirill Tkhai,
	Michal Hocko, Jan Hadrava, Vladimir Davydov, Johannes Weiner,
	Roman Gushchin, Hugh Dickins, Qian Cai, Kirill A. Shutemov,
	Andrew Morton, Linus Torvalds

From: Yang Shi <yang.shi@linux.alibaba.com>

commit fa1e512fac717f34e7c12d7a384c46e90a647392 upstream.

Shakeel Butt reported premature oom on kernel with
"cgroup_disable=memory" since mem_cgroup_is_root() returns false even
though memcg is actually NULL.  The drop_caches is also broken.

It is because commit aeed1d325d42 ("mm/vmscan.c: generalize
shrink_slab() calls in shrink_node()") removed the !memcg check before
!mem_cgroup_is_root().  And, surprisingly root memcg is allocated even
though memory cgroup is disabled by kernel boot parameter.

Add mem_cgroup_disabled() check to make reclaimer work as expected.

Link: http://lkml.kernel.org/r/1563385526-20805-1-git-send-email-yang.shi@linux.alibaba.com
Fixes: aeed1d325d42 ("mm/vmscan.c: generalize shrink_slab() calls in shrink_node()")
Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>
Reported-by: Shakeel Butt <shakeelb@google.com>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Reviewed-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Jan Hadrava <had@kam.mff.cuni.cz>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Qian Cai <cai@lca.pw>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: <stable@vger.kernel.org>	[4.19+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 mm/vmscan.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -670,7 +670,14 @@ static unsigned long shrink_slab(gfp_t g
 	unsigned long ret, freed = 0;
 	struct shrinker *shrinker;
 
-	if (!mem_cgroup_is_root(memcg))
+	/*
+	 * The root memcg might be allocated even though memcg is disabled
+	 * via "cgroup_disable=memory" boot parameter.  This could make
+	 * mem_cgroup_is_root() return false, then just run memcg slab
+	 * shrink, but skip global shrink.  This may result in premature
+	 * oom.
+	 */
+	if (!mem_cgroup_disabled() && !mem_cgroup_is_root(memcg))
 		return shrink_slab_memcg(gfp_mask, nid, memcg, priority);
 
 	if (!down_read_trylock(&shrinker_rwsem))



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 54/74] s390/dasd: fix endless loop after read unit address configuration
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (52 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 53/74] mm: vmscan: check if mem cgroup is disabled or not before calling memcg slab shrinker Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 55/74] cgroup: kselftest: relax fs_spec checks Greg Kroah-Hartman
                   ` (24 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Stefan Haberland, Jan Hoeppner, Jens Axboe

From: Stefan Haberland <sth@linux.ibm.com>

commit 41995342b40c418a47603e1321256d2c4a2ed0fb upstream.

After getting a storage server event that causes the DASD device driver
to update its unit address configuration during a device shutdown there is
the possibility of an endless loop in the device driver.

In the system log there will be ongoing DASD error messages with RC: -19.

The reason is that the loop starting the ruac request only terminates when
the retry counter is decreased to 0. But in the sleep_on function there are
early exit paths that do not decrease the retry counter.

Prevent an endless loop by handling those cases separately.

Remove the unnecessary do..while loop since the sleep_on function takes
care of retries by itself.

Fixes: 8e09f21574ea ("[S390] dasd: add hyper PAV support to DASD device driver, part 1")
Cc: stable@vger.kernel.org # 2.6.25+
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/s390/block/dasd_alias.c |   22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

--- a/drivers/s390/block/dasd_alias.c
+++ b/drivers/s390/block/dasd_alias.c
@@ -383,6 +383,20 @@ suborder_not_supported(struct dasd_ccw_r
 	char msg_format;
 	char msg_no;
 
+	/*
+	 * intrc values ENODEV, ENOLINK and EPERM
+	 * will be optained from sleep_on to indicate that no
+	 * IO operation can be started
+	 */
+	if (cqr->intrc == -ENODEV)
+		return 1;
+
+	if (cqr->intrc == -ENOLINK)
+		return 1;
+
+	if (cqr->intrc == -EPERM)
+		return 1;
+
 	sense = dasd_get_sense(&cqr->irb);
 	if (!sense)
 		return 0;
@@ -447,12 +461,8 @@ static int read_unit_address_configurati
 	lcu->flags &= ~NEED_UAC_UPDATE;
 	spin_unlock_irqrestore(&lcu->lock, flags);
 
-	do {
-		rc = dasd_sleep_on(cqr);
-		if (rc && suborder_not_supported(cqr))
-			return -EOPNOTSUPP;
-	} while (rc && (cqr->retries > 0));
-	if (rc) {
+	rc = dasd_sleep_on(cqr);
+	if (rc && !suborder_not_supported(cqr)) {
 		spin_lock_irqsave(&lcu->lock, flags);
 		lcu->flags |= NEED_UAC_UPDATE;
 		spin_unlock_irqrestore(&lcu->lock, flags);



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 55/74] cgroup: kselftest: relax fs_spec checks
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (53 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 54/74] s390/dasd: fix endless loop after read unit address configuration Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 56/74] parisc: Fix build of compressed kernel even with debug enabled Greg Kroah-Hartman
                   ` (23 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Chris Down, Johannes Weiner,
	Tejun Heo, Roman Gushchin, Andrew Morton, Linus Torvalds

From: Chris Down <chris@chrisdown.name>

commit b59b1baab789eacdde809135542e3d4f256f6878 upstream.

On my laptop most memcg kselftests were being skipped because it claimed
cgroup v2 hierarchy wasn't mounted, but this isn't correct.  Instead, it
seems current systemd HEAD mounts it with the name "cgroup2" instead of
"cgroup":

    % grep cgroup /proc/mounts
    cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate 0 0

I can't think of a reason to need to check fs_spec explicitly
since it's arbitrary, so we can just rely on fs_vfstype.

After these changes, `make TARGETS=cgroup kselftest` actually runs the
cgroup v2 tests in more cases.

Link: http://lkml.kernel.org/r/20190723210737.GA487@chrisdown.name
Signed-off-by: Chris Down <chris@chrisdown.name>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 tools/testing/selftests/cgroup/cgroup_util.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/tools/testing/selftests/cgroup/cgroup_util.c
+++ b/tools/testing/selftests/cgroup/cgroup_util.c
@@ -181,8 +181,7 @@ int cg_find_unified_root(char *root, siz
 		strtok(NULL, delim);
 		strtok(NULL, delim);
 
-		if (strcmp(fs, "cgroup") == 0 &&
-		    strcmp(type, "cgroup2") == 0) {
+		if (strcmp(type, "cgroup2") == 0) {
 			strncpy(root, mount, len);
 			return 0;
 		}



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 56/74] parisc: Fix build of compressed kernel even with debug enabled
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (54 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 55/74] cgroup: kselftest: relax fs_spec checks Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 57/74] drivers/perf: arm_pmu: Fix failure path in PM notifier Greg Kroah-Hartman
                   ` (22 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Sven Schnelle, Helge Deller

From: Helge Deller <deller@gmx.de>

commit 3fe6c873af2f2247544debdbe51ec29f690a2ccf upstream.

With debug info enabled (CONFIG_DEBUG_INFO=y) the resulting vmlinux may get
that huge that we need to increase the start addresss for the decompression
text section otherwise one will face a linker error.

Reported-by: Sven Schnelle <svens@stackframe.org>
Tested-by: Sven Schnelle <svens@stackframe.org>
Cc: stable@vger.kernel.org # v4.14+
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/parisc/boot/compressed/vmlinux.lds.S |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/parisc/boot/compressed/vmlinux.lds.S
+++ b/arch/parisc/boot/compressed/vmlinux.lds.S
@@ -42,8 +42,8 @@ SECTIONS
 #endif
 	_startcode_end = .;
 
-	/* bootloader code and data starts behind area of extracted kernel */
-	. = (SZ_end - SZparisc_kernel_start + KERNEL_BINARY_TEXT_START);
+	/* bootloader code and data starts at least behind area of extracted kernel */
+	. = MAX(ABSOLUTE(.), (SZ_end - SZparisc_kernel_start + KERNEL_BINARY_TEXT_START));
 
 	/* align on next page boundary */
 	. = ALIGN(4096);



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 57/74] drivers/perf: arm_pmu: Fix failure path in PM notifier
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (55 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 56/74] parisc: Fix build of compressed kernel even with debug enabled Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 58/74] arm64: compat: Allow single-byte watchpoints on all addresses Greg Kroah-Hartman
                   ` (21 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Anders Roxell, Lorenzo Pieralisi,
	Will Deacon

From: Will Deacon <will@kernel.org>

commit 0d7fd70f26039bd4b33444ca47f0e69ce3ae0354 upstream.

Handling of the CPU_PM_ENTER_FAILED transition in the Arm PMU PM
notifier code incorrectly skips restoration of the counters. Fix the
logic so that CPU_PM_ENTER_FAILED follows the same path as CPU_PM_EXIT.

Cc: <stable@vger.kernel.org>
Fixes: da4e4f18afe0f372 ("drivers/perf: arm_pmu: implement CPU_PM notifier")
Reported-by: Anders Roxell <anders.roxell@linaro.org>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/perf/arm_pmu.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -730,8 +730,8 @@ static int cpu_pm_pmu_notify(struct noti
 		cpu_pm_pmu_setup(armpmu, cmd);
 		break;
 	case CPU_PM_EXIT:
-		cpu_pm_pmu_setup(armpmu, cmd);
 	case CPU_PM_ENTER_FAILED:
+		cpu_pm_pmu_setup(armpmu, cmd);
 		armpmu->start(armpmu);
 		break;
 	default:



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 58/74] arm64: compat: Allow single-byte watchpoints on all addresses
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (56 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 57/74] drivers/perf: arm_pmu: Fix failure path in PM notifier Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 59/74] arm64: cpufeature: Fix feature comparison for CTR_EL0.{CWG,ERG} Greg Kroah-Hartman
                   ` (20 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Will Deacon

From: Will Deacon <will@kernel.org>

commit 849adec41203ac5837c40c2d7e08490ffdef3c2c upstream.

Commit d968d2b801d8 ("ARM: 7497/1: hw_breakpoint: allow single-byte
watchpoints on all addresses") changed the validation requirements for
hardware watchpoints on arch/arm/. Update our compat layer to implement
the same relaxation.

Cc: <stable@vger.kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm64/kernel/hw_breakpoint.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -547,13 +547,14 @@ int hw_breakpoint_arch_parse(struct perf
 			/* Aligned */
 			break;
 		case 1:
-			/* Allow single byte watchpoint. */
-			if (hw->ctrl.len == ARM_BREAKPOINT_LEN_1)
-				break;
 		case 2:
 			/* Allow halfword watchpoints and breakpoints. */
 			if (hw->ctrl.len == ARM_BREAKPOINT_LEN_2)
 				break;
+		case 3:
+			/* Allow single byte watchpoint. */
+			if (hw->ctrl.len == ARM_BREAKPOINT_LEN_1)
+				break;
 		default:
 			return -EINVAL;
 		}



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 59/74] arm64: cpufeature: Fix feature comparison for CTR_EL0.{CWG,ERG}
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (57 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 58/74] arm64: compat: Allow single-byte watchpoints on all addresses Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 60/74] nbd: replace kill_bdev() with __invalidate_device() again Greg Kroah-Hartman
                   ` (19 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Suzuki K Poulose, Mark Rutland,
	Will Deacon, Catalin Marinas

From: Will Deacon <will@kernel.org>

commit 147b9635e6347104b91f48ca9dca61eb0fbf2a54 upstream.

If CTR_EL0.{CWG,ERG} are 0b0000 then they must be interpreted to have
their architecturally maximum values, which defeats the use of
FTR_HIGHER_SAFE when sanitising CPU ID registers on heterogeneous
machines.

Introduce FTR_HIGHER_OR_ZERO_SAFE so that these fields effectively
saturate at zero.

Fixes: 3c739b571084 ("arm64: Keep track of CPU feature registers")
Cc: <stable@vger.kernel.org> # 4.4.x-
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm64/include/asm/cpufeature.h |    7 ++++---
 arch/arm64/kernel/cpufeature.c      |    8 ++++++--
 2 files changed, 10 insertions(+), 5 deletions(-)

--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -45,9 +45,10 @@
  */
 
 enum ftr_type {
-	FTR_EXACT,	/* Use a predefined safe value */
-	FTR_LOWER_SAFE,	/* Smaller value is safe */
-	FTR_HIGHER_SAFE,/* Bigger value is safe */
+	FTR_EXACT,			/* Use a predefined safe value */
+	FTR_LOWER_SAFE,			/* Smaller value is safe */
+	FTR_HIGHER_SAFE,		/* Bigger value is safe */
+	FTR_HIGHER_OR_ZERO_SAFE,	/* Bigger value is safe, but 0 is biggest */
 };
 
 #define FTR_STRICT	true	/* SANITY check strict matching required */
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -206,8 +206,8 @@ static const struct arm64_ftr_bits ftr_c
 	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, 31, 1, 1), /* RES1 */
 	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_DIC_SHIFT, 1, 1),
 	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_IDC_SHIFT, 1, 1),
-	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_SAFE, CTR_CWG_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_SAFE, CTR_ERG_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, CTR_CWG_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, CTR_ERG_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_DMINLINE_SHIFT, 4, 1),
 	/*
 	 * Linux can handle differing I-cache policies. Userspace JITs will
@@ -449,6 +449,10 @@ static s64 arm64_ftr_safe_value(const st
 	case FTR_LOWER_SAFE:
 		ret = new < cur ? new : cur;
 		break;
+	case FTR_HIGHER_OR_ZERO_SAFE:
+		if (!cur || !new)
+			break;
+		/* Fallthrough */
 	case FTR_HIGHER_SAFE:
 		ret = new > cur ? new : cur;
 		break;



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 60/74] nbd: replace kill_bdev() with __invalidate_device() again
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (58 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 59/74] arm64: cpufeature: Fix feature comparison for CTR_EL0.{CWG,ERG} Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 61/74] xen/swiotlb: fix condition for calling xen_destroy_contiguous_region() Greg Kroah-Hartman
                   ` (18 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, linux-block, Ratna Manoj Bolla, nbd,
	David Woodhouse, Josef Bacik, Munehisa Kamata, Jens Axboe

From: Munehisa Kamata <kamatam@amazon.com>

commit 2b5c8f0063e4b263cf2de82029798183cf85c320 upstream.

Commit abbbdf12497d ("replace kill_bdev() with __invalidate_device()")
once did this, but 29eaadc03649 ("nbd: stop using the bdev everywhere")
resurrected kill_bdev() and it has been there since then. So buffer_head
mappings still get killed on a server disconnection, and we can still
hit the BUG_ON on a filesystem on the top of the nbd device.

  EXT4-fs (nbd0): mounted filesystem with ordered data mode. Opts: (null)
  block nbd0: Receive control failed (result -32)
  block nbd0: shutting down sockets
  print_req_error: I/O error, dev nbd0, sector 66264 flags 3000
  EXT4-fs warning (device nbd0): htree_dirblock_to_tree:979: inode #2: lblock 0: comm ls: error -5 reading directory block
  print_req_error: I/O error, dev nbd0, sector 2264 flags 3000
  EXT4-fs error (device nbd0): __ext4_get_inode_loc:4690: inode #2: block 283: comm ls: unable to read itable block
  EXT4-fs error (device nbd0) in ext4_reserve_inode_write:5894: IO failure
  ------------[ cut here ]------------
  kernel BUG at fs/buffer.c:3057!
  invalid opcode: 0000 [#1] SMP PTI
  CPU: 7 PID: 40045 Comm: jbd2/nbd0-8 Not tainted 5.1.0-rc3+ #4
  Hardware name: Amazon EC2 m5.12xlarge/, BIOS 1.0 10/16/2017
  RIP: 0010:submit_bh_wbc+0x18b/0x190
  ...
  Call Trace:
   jbd2_write_superblock+0xf1/0x230 [jbd2]
   ? account_entity_enqueue+0xc5/0xf0
   jbd2_journal_update_sb_log_tail+0x94/0xe0 [jbd2]
   jbd2_journal_commit_transaction+0x12f/0x1d20 [jbd2]
   ? __switch_to_asm+0x40/0x70
   ...
   ? lock_timer_base+0x67/0x80
   kjournald2+0x121/0x360 [jbd2]
   ? remove_wait_queue+0x60/0x60
   kthread+0xf8/0x130
   ? commit_timeout+0x10/0x10 [jbd2]
   ? kthread_bind+0x10/0x10
   ret_from_fork+0x35/0x40

With __invalidate_device(), I no longer hit the BUG_ON with sync or
unmount on the disconnected device.

Fixes: 29eaadc03649 ("nbd: stop using the bdev everywhere")
Cc: linux-block@vger.kernel.org
Cc: Ratna Manoj Bolla <manoj.br@gmail.com>
Cc: nbd@other.debian.org
Cc: stable@vger.kernel.org
Cc: David Woodhouse <dwmw@amazon.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Munehisa Kamata <kamatam@amazon.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/block/nbd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -1218,7 +1218,7 @@ static void nbd_clear_sock_ioctl(struct
 				 struct block_device *bdev)
 {
 	sock_shutdown(nbd);
-	kill_bdev(bdev);
+	__invalidate_device(bdev, true);
 	nbd_bdev_reset(bdev);
 	if (test_and_clear_bit(NBD_HAS_CONFIG_REF,
 			       &nbd->config->runtime_flags))



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 61/74] xen/swiotlb: fix condition for calling xen_destroy_contiguous_region()
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (59 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 60/74] nbd: replace kill_bdev() with __invalidate_device() again Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 62/74] IB/mlx5: Fix unreg_umr to ignore the mkey state Greg Kroah-Hartman
                   ` (17 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Juergen Gross, Boris Ostrovsky,
	Jan Beulich, Konrad Rzeszutek Wilk

From: Juergen Gross <jgross@suse.com>

commit 50f6393f9654c561df4cdcf8e6cfba7260143601 upstream.

The condition in xen_swiotlb_free_coherent() for deciding whether to
call xen_destroy_contiguous_region() is wrong: in case the region to
be freed is not contiguous calling xen_destroy_contiguous_region() is
the wrong thing to do: it would result in inconsistent mappings of
multiple PFNs to the same MFN. This will lead to various strange
crashes or data corruption.

Instead of calling xen_destroy_contiguous_region() in that case a
warning should be issued as that situation should never occur.

Cc: stable@vger.kernel.org
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/xen/swiotlb-xen.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -357,8 +357,8 @@ xen_swiotlb_free_coherent(struct device
 	/* Convert the size to actually allocated. */
 	size = 1UL << (order + XEN_PAGE_SHIFT);
 
-	if (((dev_addr + size - 1 <= dma_mask)) ||
-	    range_straddles_page_boundary(phys, size))
+	if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
+		     range_straddles_page_boundary(phys, size)))
 		xen_destroy_contiguous_region(phys, order);
 
 	xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 62/74] IB/mlx5: Fix unreg_umr to ignore the mkey state
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (60 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 61/74] xen/swiotlb: fix condition for calling xen_destroy_contiguous_region() Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 63/74] IB/mlx5: Use direct mkey destroy command upon UMR unreg failure Greg Kroah-Hartman
                   ` (16 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Yishai Hadas, Artemy Kovalyov,
	Leon Romanovsky, Jason Gunthorpe

From: Yishai Hadas <yishaih@mellanox.com>

commit 6a053953739d23694474a5f9c81d1a30093da81a upstream.

Fix unreg_umr to ignore the mkey state and do not fail if was freed.  This
prevents a case that a user space application already changed the mkey
state to free and then the UMR operation will fail leaving the mkey in an
inappropriate state.

Link: https://lore.kernel.org/r/20190723065733.4899-3-leon@kernel.org
Cc: <stable@vger.kernel.org> # 3.19
Fixes: 968e78dd9644 ("IB/mlx5: Enhance UMR support to allow partial page table update")
Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/hw/mlx5/mlx5_ib.h |    1 +
 drivers/infiniband/hw/mlx5/mr.c      |    4 ++--
 drivers/infiniband/hw/mlx5/qp.c      |   12 ++++++++----
 3 files changed, 11 insertions(+), 6 deletions(-)

--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@ -467,6 +467,7 @@ struct mlx5_umr_wr {
 	u64				length;
 	int				access_flags;
 	u32				mkey;
+	u8				ignore_free_state:1;
 };
 
 static inline const struct mlx5_umr_wr *umr_wr(const struct ib_send_wr *wr)
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1407,10 +1407,10 @@ static int unreg_umr(struct mlx5_ib_dev
 	if (mdev->state == MLX5_DEVICE_STATE_INTERNAL_ERROR)
 		return 0;
 
-	umrwr.wr.send_flags = MLX5_IB_SEND_UMR_DISABLE_MR |
-			      MLX5_IB_SEND_UMR_FAIL_IF_FREE;
+	umrwr.wr.send_flags = MLX5_IB_SEND_UMR_DISABLE_MR;
 	umrwr.wr.opcode = MLX5_IB_WR_UMR;
 	umrwr.mkey = mr->mmkey.key;
+	umrwr.ignore_free_state = 1;
 
 	return mlx5_ib_post_send_wait(dev, &umrwr);
 }
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -3717,10 +3717,14 @@ static int set_reg_umr_segment(struct ml
 
 	memset(umr, 0, sizeof(*umr));
 
-	if (wr->send_flags & MLX5_IB_SEND_UMR_FAIL_IF_FREE)
-		umr->flags = MLX5_UMR_CHECK_FREE; /* fail if free */
-	else
-		umr->flags = MLX5_UMR_CHECK_NOT_FREE; /* fail if not free */
+	if (!umrwr->ignore_free_state) {
+		if (wr->send_flags & MLX5_IB_SEND_UMR_FAIL_IF_FREE)
+			 /* fail if free */
+			umr->flags = MLX5_UMR_CHECK_FREE;
+		else
+			/* fail if not free */
+			umr->flags = MLX5_UMR_CHECK_NOT_FREE;
+	}
 
 	umr->xlt_octowords = cpu_to_be16(get_xlt_octo(umrwr->xlt_size));
 	if (wr->send_flags & MLX5_IB_SEND_UMR_UPDATE_XLT) {



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 63/74] IB/mlx5: Use direct mkey destroy command upon UMR unreg failure
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (61 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 62/74] IB/mlx5: Fix unreg_umr to ignore the mkey state Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 64/74] IB/mlx5: Move MRs to a kernel PD when freeing them to the MR cache Greg Kroah-Hartman
                   ` (15 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Yishai Hadas, Artemy Kovalyov,
	Leon Romanovsky, Jason Gunthorpe

From: Yishai Hadas <yishaih@mellanox.com>

commit afd1417404fba6dbfa6c0a8e5763bd348da682e4 upstream.

Use a direct firmware command to destroy the mkey in case the unreg UMR
operation has failed.

This prevents a case that a mkey will leak out from the cache post a
failure to be destroyed by a UMR WR.

In case the MR cache limit didn't reach a call to add another entry to the
cache instead of the destroyed one is issued.

In addition, replaced a warn message to WARN_ON() as this flow is fatal
and can't happen unless some bug around.

Link: https://lore.kernel.org/r/20190723065733.4899-4-leon@kernel.org
Cc: <stable@vger.kernel.org> # 4.10
Fixes: 49780d42dfc9 ("IB/mlx5: Expose MR cache for mlx5_ib")
Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/hw/mlx5/mr.c |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -548,13 +548,16 @@ void mlx5_mr_cache_free(struct mlx5_ib_d
 		return;
 
 	c = order2idx(dev, mr->order);
-	if (c < 0 || c >= MAX_MR_CACHE_ENTRIES) {
-		mlx5_ib_warn(dev, "order %d, cache index %d\n", mr->order, c);
-		return;
-	}
+	WARN_ON(c < 0 || c >= MAX_MR_CACHE_ENTRIES);
 
-	if (unreg_umr(dev, mr))
+	if (unreg_umr(dev, mr)) {
+		mr->allocated_from_cache = false;
+		destroy_mkey(dev, mr);
+		ent = &cache->ent[c];
+		if (ent->cur < ent->limit)
+			queue_work(cache->wq, &ent->work);
 		return;
+	}
 
 	ent = &cache->ent[c];
 	spin_lock_irq(&ent->lock);



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 64/74] IB/mlx5: Move MRs to a kernel PD when freeing them to the MR cache
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (62 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 63/74] IB/mlx5: Use direct mkey destroy command upon UMR unreg failure Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 65/74] IB/mlx5: Fix clean_mr() to work in the expected order Greg Kroah-Hartman
                   ` (14 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Yishai Hadas, Artemy Kovalyov,
	Leon Romanovsky, Jason Gunthorpe

From: Yishai Hadas <yishaih@mellanox.com>

commit 9ec4483a3f0f71a228a5933bc040441322bfb090 upstream.

Fix unreg_umr to move the MR to a kernel owned PD (i.e. the UMR PD) which
can't be accessed by userspace.

This ensures that nothing can continue to access the MR once it has been
placed in the kernels cache for reuse.

MRs in the cache continue to have their HW state, including DMA tables,
present. Even though the MR has been invalidated, changing the PD provides
an additional layer of protection against use of the MR.

Link: https://lore.kernel.org/r/20190723065733.4899-5-leon@kernel.org
Cc: <stable@vger.kernel.org> # 3.10
Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/hw/mlx5/mr.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1410,8 +1410,10 @@ static int unreg_umr(struct mlx5_ib_dev
 	if (mdev->state == MLX5_DEVICE_STATE_INTERNAL_ERROR)
 		return 0;
 
-	umrwr.wr.send_flags = MLX5_IB_SEND_UMR_DISABLE_MR;
+	umrwr.wr.send_flags = MLX5_IB_SEND_UMR_DISABLE_MR |
+			      MLX5_IB_SEND_UMR_UPDATE_PD_ACCESS;
 	umrwr.wr.opcode = MLX5_IB_WR_UMR;
+	umrwr.pd = dev->umrc.pd;
 	umrwr.mkey = mr->mmkey.key;
 	umrwr.ignore_free_state = 1;
 



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 65/74] IB/mlx5: Fix clean_mr() to work in the expected order
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (63 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 64/74] IB/mlx5: Move MRs to a kernel PD when freeing them to the MR cache Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 66/74] IB/mlx5: Fix RSS Toeplitz setup to be aligned with the HW specification Greg Kroah-Hartman
                   ` (13 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Yishai Hadas, Artemy Kovalyov,
	Leon Romanovsky, Jason Gunthorpe

From: Yishai Hadas <yishaih@mellanox.com>

commit b9332dad987018745a0c0bb718d12dacfa760489 upstream.

Any dma map underlying the MR should only be freed once the MR is fenced
at the hardware.

As of the above we first destroy the MKEY and just after that can safely
call to dma_unmap_single().

Link: https://lore.kernel.org/r/20190723065733.4899-6-leon@kernel.org
Cc: <stable@vger.kernel.org> # 4.3
Fixes: 8a187ee52b04 ("IB/mlx5: Support the new memory registration API")
Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/hw/mlx5/mr.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1620,10 +1620,10 @@ static void clean_mr(struct mlx5_ib_dev
 		mr->sig = NULL;
 	}
 
-	mlx5_free_priv_descs(mr);
-
-	if (!allocated_from_cache)
+	if (!allocated_from_cache) {
 		destroy_mkey(dev, mr);
+		mlx5_free_priv_descs(mr);
+	}
 }
 
 static void dereg_mr(struct mlx5_ib_dev *dev, struct mlx5_ib_mr *mr)



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 66/74] IB/mlx5: Fix RSS Toeplitz setup to be aligned with the HW specification
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (64 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 65/74] IB/mlx5: Fix clean_mr() to work in the expected order Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 67/74] IB/hfi1: Check for error on call to alloc_rsm_map_table Greg Kroah-Hartman
                   ` (12 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Yishai Hadas, Alex Vainman,
	Leon Romanovsky, Jason Gunthorpe

From: Yishai Hadas <yishaih@mellanox.com>

commit b7165bd0d6cbb93732559be6ea8774653b204480 upstream.

The specification for the Toeplitz function doesn't require to set the key
explicitly to be symmetric. In case a symmetric functionality is required
a symmetric key can be simply used.

Wrongly forcing the algorithm to symmetric causes the wrong packet
distribution and a performance degradation.

Link: https://lore.kernel.org/r/20190723065733.4899-7-leon@kernel.org
Cc: <stable@vger.kernel.org> # 4.7
Fixes: 28d6137008b2 ("IB/mlx5: Add RSS QP support")
Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
Reviewed-by: Alex Vainman <alexv@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/hw/mlx5/qp.c |    1 -
 1 file changed, 1 deletion(-)

--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -1501,7 +1501,6 @@ static int create_rss_raw_qp_tir(struct
 		}
 
 		MLX5_SET(tirc, tirc, rx_hash_fn, MLX5_RX_HASH_FN_TOEPLITZ);
-		MLX5_SET(tirc, tirc, rx_hash_symmetric, 1);
 		memcpy(rss_key, ucmd.rx_hash_key, len);
 		break;
 	}



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 67/74] IB/hfi1: Check for error on call to alloc_rsm_map_table
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (65 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 66/74] IB/mlx5: Fix RSS Toeplitz setup to be aligned with the HW specification Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 68/74] drm/i915/gvt: fix incorrect cache entry for guest page mapping Greg Kroah-Hartman
                   ` (11 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Mike Marciniszyn, John Fleck,
	Jason Gunthorpe

From: John Fleck <john.fleck@intel.com>

commit cd48a82087231fdba0e77521102386c6ed0168d6 upstream.

The call to alloc_rsm_map_table does not check if the kmalloc fails.
Check for a NULL on alloc, and bail if it fails.

Fixes: 372cc85a13c9 ("IB/hfi1: Extract RSM map table init from QOS")
Link: https://lore.kernel.org/r/20190715164521.74174.27047.stgit@awfm-01.aw.intel.com
Cc: <stable@vger.kernel.org>
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: John Fleck <john.fleck@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/hw/hfi1/chip.c |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

--- a/drivers/infiniband/hw/hfi1/chip.c
+++ b/drivers/infiniband/hw/hfi1/chip.c
@@ -14586,7 +14586,7 @@ void hfi1_deinit_vnic_rsm(struct hfi1_de
 		clear_rcvctrl(dd, RCV_CTRL_RCV_RSM_ENABLE_SMASK);
 }
 
-static void init_rxe(struct hfi1_devdata *dd)
+static int init_rxe(struct hfi1_devdata *dd)
 {
 	struct rsm_map_table *rmt;
 	u64 val;
@@ -14595,6 +14595,9 @@ static void init_rxe(struct hfi1_devdata
 	write_csr(dd, RCV_ERR_MASK, ~0ull);
 
 	rmt = alloc_rsm_map_table(dd);
+	if (!rmt)
+		return -ENOMEM;
+
 	/* set up QOS, including the QPN map table */
 	init_qos(dd, rmt);
 	init_user_fecn_handling(dd, rmt);
@@ -14621,6 +14624,7 @@ static void init_rxe(struct hfi1_devdata
 	val |= ((4ull & RCV_BYPASS_HDR_SIZE_MASK) <<
 		RCV_BYPASS_HDR_SIZE_SHIFT);
 	write_csr(dd, RCV_BYPASS, val);
+	return 0;
 }
 
 static void init_other(struct hfi1_devdata *dd)
@@ -15163,7 +15167,10 @@ struct hfi1_devdata *hfi1_init_dd(struct
 		goto bail_cleanup;
 
 	/* set initial RXE CSRs */
-	init_rxe(dd);
+	ret = init_rxe(dd);
+	if (ret)
+		goto bail_cleanup;
+
 	/* set initial TXE CSRs */
 	init_txe(dd);
 	/* set initial non-RXE, non-TXE CSRs */



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 68/74] drm/i915/gvt: fix incorrect cache entry for guest page mapping
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (66 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 67/74] IB/hfi1: Check for error on call to alloc_rsm_map_table Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 69/74] eeprom: at24: make spd world-readable again Greg Kroah-Hartman
                   ` (10 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Zhenyu Wang, Xiaolin Zhang

From: Xiaolin Zhang <xiaolin.zhang@intel.com>

commit 7366aeb77cd840f3edea02c65065d40affaa7f45 upstream.

GPU hang observed during the guest OCL conformance test which is caused
by THP GTT feature used durning the test.

It was observed the same GFN with different size (4K and 2M) requested
from the guest in GVT. So during the guest page dma map stage, it is
required to unmap first with orginal size and then remap again with
requested size.

Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support")
Cc: stable@vger.kernel.org
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Xiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/i915/gvt/kvmgt.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1748,6 +1748,18 @@ int kvmgt_dma_map_guest_page(unsigned lo
 		ret = __gvt_cache_add(info->vgpu, gfn, *dma_addr, size);
 		if (ret)
 			goto err_unmap;
+	} else if (entry->size != size) {
+		/* the same gfn with different size: unmap and re-map */
+		gvt_dma_unmap_page(vgpu, gfn, entry->dma_addr, entry->size);
+		__gvt_cache_remove_entry(vgpu, entry);
+
+		ret = gvt_dma_map_page(vgpu, gfn, dma_addr, size);
+		if (ret)
+			goto err_unlock;
+
+		ret = __gvt_cache_add(info->vgpu, gfn, *dma_addr, size);
+		if (ret)
+			goto err_unmap;
 	} else {
 		kref_get(&entry->ref);
 		*dma_addr = entry->dma_addr;



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 69/74] eeprom: at24: make spd world-readable again
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (67 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 68/74] drm/i915/gvt: fix incorrect cache entry for guest page mapping Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 70/74] ARC: enable uboot support unconditionally Greg Kroah-Hartman
                   ` (9 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Jean Delvare, Andrew Lunn,
	Srinivas Kandagatla, Bartosz Golaszewski, Arnd Bergmann,
	Bartosz Golaszewski

From: Jean Delvare <jdelvare@suse.de>

commit 25e5ef302c24a6fead369c0cfe88c073d7b97ca8 upstream.

The integration of the at24 driver into the nvmem framework broke the
world-readability of spd EEPROMs. Fix it.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: stable@vger.kernel.org
Fixes: 57d155506dd5 ("eeprom: at24: extend driver to plug into the NVMEM framework")
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
[Bartosz: backported to v4.19.y]
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/misc/eeprom/at24.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -724,7 +724,7 @@ static int at24_probe(struct i2c_client
 	nvmem_config.name = dev_name(dev);
 	nvmem_config.dev = dev;
 	nvmem_config.read_only = !writable;
-	nvmem_config.root_only = true;
+	nvmem_config.root_only = !(pdata.flags & AT24_FLAG_IRUGO);
 	nvmem_config.owner = THIS_MODULE;
 	nvmem_config.compat = true;
 	nvmem_config.base_dev = dev;



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 70/74] ARC: enable uboot support unconditionally
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (68 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 69/74] eeprom: at24: make spd world-readable again Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 71/74] objtool: Support GCC 9 cold subfunction naming scheme Greg Kroah-Hartman
                   ` (8 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Corentin LABBE, Eugeniy Paltsev,
	Vineet Gupta

From: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>

commit 493a2f812446e92bcb1e69a77381b4d39808d730 upstream.

After reworking U-boot args handling code and adding paranoid
arguments check we can eliminate CONFIG_ARC_UBOOT_SUPPORT and
enable uboot support unconditionally.

For JTAG case we can assume that core registers will come up
reset value of 0 or in worst case we rely on user passing
'-on=clear_regs' to Metaware debugger.

Cc: stable@vger.kernel.org
Tested-by: Corentin LABBE <clabbe@baylibre.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arc/Kconfig                        |   13 -------------
 arch/arc/configs/nps_defconfig          |    1 -
 arch/arc/configs/vdk_hs38_defconfig     |    1 -
 arch/arc/configs/vdk_hs38_smp_defconfig |    2 --
 arch/arc/kernel/head.S                  |    2 --
 arch/arc/kernel/setup.c                 |    2 --
 6 files changed, 21 deletions(-)

--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -199,7 +199,6 @@ config NR_CPUS
 
 config ARC_SMP_HALT_ON_RESET
 	bool "Enable Halt-on-reset boot mode"
-	default y if ARC_UBOOT_SUPPORT
 	help
 	  In SMP configuration cores can be configured as Halt-on-reset
 	  or they could all start at same time. For Halt-on-reset, non
@@ -539,18 +538,6 @@ config ARC_DBG_TLB_PARANOIA
 
 endif
 
-config ARC_UBOOT_SUPPORT
-	bool "Support uboot arg Handling"
-	default n
-	help
-	  ARC Linux by default checks for uboot provided args as pointers to
-	  external cmdline or DTB. This however breaks in absence of uboot,
-	  when booting from Metaware debugger directly, as the registers are
-	  not zeroed out on reset by mdb and/or ARCv2 based cores. The bogus
-	  registers look like uboot args to kernel which then chokes.
-	  So only enable the uboot arg checking/processing if users are sure
-	  of uboot being in play.
-
 config ARC_BUILTIN_DTB_NAME
 	string "Built in DTB"
 	help
--- a/arch/arc/configs/nps_defconfig
+++ b/arch/arc/configs/nps_defconfig
@@ -31,7 +31,6 @@ CONFIG_ARC_CACHE_LINE_SHIFT=5
 # CONFIG_ARC_HAS_LLSC is not set
 CONFIG_ARC_KVADDR_SIZE=402
 CONFIG_ARC_EMUL_UNALIGNED=y
-CONFIG_ARC_UBOOT_SUPPORT=y
 CONFIG_PREEMPT=y
 CONFIG_NET=y
 CONFIG_UNIX=y
--- a/arch/arc/configs/vdk_hs38_defconfig
+++ b/arch/arc/configs/vdk_hs38_defconfig
@@ -13,7 +13,6 @@ CONFIG_PARTITION_ADVANCED=y
 CONFIG_ARC_PLAT_AXS10X=y
 CONFIG_AXS103=y
 CONFIG_ISA_ARCV2=y
-CONFIG_ARC_UBOOT_SUPPORT=y
 CONFIG_ARC_BUILTIN_DTB_NAME="vdk_hs38"
 CONFIG_PREEMPT=y
 CONFIG_NET=y
--- a/arch/arc/configs/vdk_hs38_smp_defconfig
+++ b/arch/arc/configs/vdk_hs38_smp_defconfig
@@ -15,8 +15,6 @@ CONFIG_AXS103=y
 CONFIG_ISA_ARCV2=y
 CONFIG_SMP=y
 # CONFIG_ARC_TIMERS_64BIT is not set
-# CONFIG_ARC_SMP_HALT_ON_RESET is not set
-CONFIG_ARC_UBOOT_SUPPORT=y
 CONFIG_ARC_BUILTIN_DTB_NAME="vdk_hs38_smp"
 CONFIG_PREEMPT=y
 CONFIG_NET=y
--- a/arch/arc/kernel/head.S
+++ b/arch/arc/kernel/head.S
@@ -100,7 +100,6 @@ ENTRY(stext)
 	st.ab   0, [r5, 4]
 1:
 
-#ifdef CONFIG_ARC_UBOOT_SUPPORT
 	; Uboot - kernel ABI
 	;    r0 = [0] No uboot interaction, [1] cmdline in r2, [2] DTB in r2
 	;    r1 = magic number (always zero as of now)
@@ -109,7 +108,6 @@ ENTRY(stext)
 	st	r0, [@uboot_tag]
 	st      r1, [@uboot_magic]
 	st	r2, [@uboot_arg]
-#endif
 
 	; setup "current" tsk and optionally cache it in dedicated r25
 	mov	r9, @init_task
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -493,7 +493,6 @@ void __init handle_uboot_args(void)
 	bool use_embedded_dtb = true;
 	bool append_cmdline = false;
 
-#ifdef CONFIG_ARC_UBOOT_SUPPORT
 	/* check that we know this tag */
 	if (uboot_tag != UBOOT_TAG_NONE &&
 	    uboot_tag != UBOOT_TAG_CMDLINE &&
@@ -525,7 +524,6 @@ void __init handle_uboot_args(void)
 		append_cmdline = true;
 
 ignore_uboot_args:
-#endif
 
 	if (use_embedded_dtb) {
 		machine_desc = setup_machine_fdt(__dtb_start);



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 71/74] objtool: Support GCC 9 cold subfunction naming scheme
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (69 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 70/74] ARC: enable uboot support unconditionally Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 72/74] gcc-9: properly declare the {pv,hv}clock_page storage Greg Kroah-Hartman
                   ` (7 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Peter Zijlstra (Intel),
	Josh Poimboeuf, Thomas Gleixner

From: Josh Poimboeuf <jpoimboe@redhat.com>

commit bcb6fb5da77c2a228adf07cc9cb1a0c2aa2001c6 upstream.

Starting with GCC 8, a lot of unlikely code was moved out of line to
"cold" subfunctions in .text.unlikely.

For example, the unlikely bits of:

  irq_do_set_affinity()

are moved out to the following subfunction:

  irq_do_set_affinity.cold.49()

Starting with GCC 9, the numbered suffix has been removed.  So in the
above example, the cold subfunction is instead:

  irq_do_set_affinity.cold()

Tweak the objtool subfunction detection logic so that it detects both
GCC 8 and GCC 9 naming schemes.

Reported-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/015e9544b1f188d36a7f02fa31e9e95629aa5f50.1541040800.git.jpoimboe@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 tools/objtool/elf.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -305,7 +305,7 @@ static int read_symbols(struct elf *elf)
 			if (sym->type != STT_FUNC)
 				continue;
 			sym->pfunc = sym->cfunc = sym;
-			coldstr = strstr(sym->name, ".cold.");
+			coldstr = strstr(sym->name, ".cold");
 			if (!coldstr)
 				continue;
 



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 72/74] gcc-9: properly declare the {pv,hv}clock_page storage
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (70 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 71/74] objtool: Support GCC 9 cold subfunction naming scheme Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 73/74] x86/vdso: Prevent segfaults due to hoisted vclock reads Greg Kroah-Hartman
                   ` (6 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Linus Torvalds

From: Linus Torvalds <torvalds@linux-foundation.org>

commit 459e3a21535ae3c7a9a123650e54f5c882b8fcbf upstream.

The pvlock_page and hvclock_page variables are (as the name implies)
addresses to pages, created by the linker script.

But we declared them as just "extern u8" variables, which _works_, but
now that gcc does some more bounds checking, it causes warnings like

    warning: array subscript 1 is outside array bounds of ‘u8[1]’

when we then access more than one byte from those variables.

Fix this by simply making the declaration of the variables match
reality, which makes the compiler happy too.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/entry/vdso/vclock_gettime.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -29,12 +29,12 @@ extern int __vdso_gettimeofday(struct ti
 extern time_t __vdso_time(time_t *t);
 
 #ifdef CONFIG_PARAVIRT_CLOCK
-extern u8 pvclock_page
+extern u8 pvclock_page[PAGE_SIZE]
 	__attribute__((visibility("hidden")));
 #endif
 
 #ifdef CONFIG_HYPERV_TSCPAGE
-extern u8 hvclock_page
+extern u8 hvclock_page[PAGE_SIZE]
 	__attribute__((visibility("hidden")));
 #endif
 



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 73/74] x86/vdso: Prevent segfaults due to hoisted vclock reads
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (71 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 72/74] gcc-9: properly declare the {pv,hv}clock_page storage Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 13:03 ` [PATCH 4.19 74/74] scsi: mpt3sas: Use 63-bit DMA addressing on SAS35 HBA Greg Kroah-Hartman
                   ` (5 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, x86, Borislav Petkov, Duncan Roe,
	Andy Lutomirski, Linus Torvalds

From: Andy Lutomirski <luto@kernel.org>

commit ff17bbe0bb405ad8b36e55815d381841f9fdeebc upstream.

GCC 5.5.0 sometimes cleverly hoists reads of the pvclock and/or hvclock
pages before the vclock mode checks.  This creates a path through
vclock_gettime() in which no vclock is enabled at all (due to disabled
TSC on old CPUs, for example) but the pvclock or hvclock page
nevertheless read.  This will segfault on bare metal.

This fixes commit 459e3a21535a ("gcc-9: properly declare the
{pv,hv}clock_page storage") in the sense that, before that commit, GCC
didn't seem to generate the offending code.  There was nothing wrong
with that commit per se, and -stable maintainers should backport this to
all supported kernels regardless of whether the offending commit was
present, since the same crash could just as easily be triggered by the
phase of the moon.

On GCC 9.1.1, this doesn't seem to affect the generated code at all, so
I'm not too concerned about performance regressions from this fix.

Cc: stable@vger.kernel.org
Cc: x86@kernel.org
Cc: Borislav Petkov <bp@alien8.de>
Reported-by: Duncan Roe <duncan_roe@optusnet.com.au>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/entry/vdso/vclock_gettime.c |   15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -191,13 +191,24 @@ notrace static inline u64 vgetsns(int *m
 
 	if (gtod->vclock_mode == VCLOCK_TSC)
 		cycles = vread_tsc();
+
+	/*
+	 * For any memory-mapped vclock type, we need to make sure that gcc
+	 * doesn't cleverly hoist a load before the mode check.  Otherwise we
+	 * might end up touching the memory-mapped page even if the vclock in
+	 * question isn't enabled, which will segfault.  Hence the barriers.
+	 */
 #ifdef CONFIG_PARAVIRT_CLOCK
-	else if (gtod->vclock_mode == VCLOCK_PVCLOCK)
+	else if (gtod->vclock_mode == VCLOCK_PVCLOCK) {
+		barrier();
 		cycles = vread_pvclock(mode);
+	}
 #endif
 #ifdef CONFIG_HYPERV_TSCPAGE
-	else if (gtod->vclock_mode == VCLOCK_HVCLOCK)
+	else if (gtod->vclock_mode == VCLOCK_HVCLOCK) {
+		barrier();
 		cycles = vread_hvclock(mode);
+	}
 #endif
 	else
 		return 0;



^ permalink raw reply	[flat|nested] 88+ messages in thread

* [PATCH 4.19 74/74] scsi: mpt3sas: Use 63-bit DMA addressing on SAS35 HBA
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (72 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 73/74] x86/vdso: Prevent segfaults due to hoisted vclock reads Greg Kroah-Hartman
@ 2019-08-05 13:03 ` Greg Kroah-Hartman
  2019-08-05 18:35 ` [PATCH 4.19 00/74] 4.19.65-stable review kernelci.org bot
                   ` (4 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-05 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Suganath Prabu, Christoph Hellwig,
	Martin K. Petersen

From: Suganath Prabu <suganath-prabu.subramani@broadcom.com>

commit df9a606184bfdb5ae3ca9d226184e9489f5c24f7 upstream.

Although SAS3 & SAS3.5 IT HBA controllers support 64-bit DMA addressing, as
per hardware design, if DMA-able range contains all 64-bits
set (0xFFFFFFFF-FFFFFFFF) then it results in a firmware fault.

E.g. SGE's start address is 0xFFFFFFFF-FFFF000 and data length is 0x1000
bytes. when HBA tries to DMA the data at 0xFFFFFFFF-FFFFFFFF location then
HBA will fault the firmware.

Driver will set 63-bit DMA mask to ensure the above address will not be
used.

Cc: <stable@vger.kernel.org> # 4.19.63
Signed-off-by: Suganath Prabu <suganath-prabu.subramani@broadcom.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/scsi/mpt3sas/mpt3sas_base.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -2565,12 +2565,14 @@ _base_config_dma_addressing(struct MPT3S
 {
 	struct sysinfo s;
 	u64 consistent_dma_mask;
+	/* Set 63 bit DMA mask for all SAS3 and SAS35 controllers */
+	int dma_mask = (ioc->hba_mpi_version_belonged > MPI2_VERSION) ? 63 : 64;
 
 	if (ioc->is_mcpu_endpoint)
 		goto try_32bit;
 
 	if (ioc->dma_mask)
-		consistent_dma_mask = DMA_BIT_MASK(64);
+		consistent_dma_mask = DMA_BIT_MASK(dma_mask);
 	else
 		consistent_dma_mask = DMA_BIT_MASK(32);
 
@@ -2578,11 +2580,11 @@ _base_config_dma_addressing(struct MPT3S
 		const uint64_t required_mask =
 		    dma_get_required_mask(&pdev->dev);
 		if ((required_mask > DMA_BIT_MASK(32)) &&
-		    !pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) &&
+		    !pci_set_dma_mask(pdev, DMA_BIT_MASK(dma_mask)) &&
 		    !pci_set_consistent_dma_mask(pdev, consistent_dma_mask)) {
 			ioc->base_add_sg_single = &_base_add_sg_single_64;
 			ioc->sge_size = sizeof(Mpi2SGESimple64_t);
-			ioc->dma_mask = 64;
+			ioc->dma_mask = dma_mask;
 			goto out;
 		}
 	}
@@ -2609,7 +2611,7 @@ static int
 _base_change_consistent_dma_mask(struct MPT3SAS_ADAPTER *ioc,
 				      struct pci_dev *pdev)
 {
-	if (pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64))) {
+	if (pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(ioc->dma_mask))) {
 		if (pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32)))
 			return -ENODEV;
 	}
@@ -4545,7 +4547,7 @@ _base_allocate_memory_pools(struct MPT3S
 		total_sz += sz;
 	} while (ioc->rdpq_array_enable && (++i < ioc->reply_queue_count));
 
-	if (ioc->dma_mask == 64) {
+	if (ioc->dma_mask > 32) {
 		if (_base_change_consistent_dma_mask(ioc, ioc->pdev) != 0) {
 			pr_warn(MPT3SAS_FMT
 			    "no suitable consistent DMA mask for %s\n",



^ permalink raw reply	[flat|nested] 88+ messages in thread

* Re: [PATCH 4.19 02/74] ARM: dts: rockchip: Make rk3288-veyron-minnie run at hs200
  2019-08-05 13:02 ` [PATCH 4.19 02/74] ARM: dts: rockchip: Make rk3288-veyron-minnie run at hs200 Greg Kroah-Hartman
@ 2019-08-05 14:41   ` Pavel Machek
  2019-08-07  2:26     ` Sasha Levin
  0 siblings, 1 reply; 88+ messages in thread
From: Pavel Machek @ 2019-08-05 14:41 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: linux-kernel, stable, Douglas Anderson, Heiko Stuebner, Sasha Levin

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

Hi!

> [ Upstream commit 1c0479023412ab7834f2e98b796eb0d8c627cd62 ]
> 
> As some point hs200 was failing on rk3288-veyron-minnie.  See commit
> 984926781122 ("ARM: dts: rockchip: temporarily remove emmc hs200 speed
> from rk3288 minnie").  Although I didn't track down exactly when it
> started working, it seems to work OK now, so let's turn it back on.
> 
> To test this, I booted from SD card and then used this script to
> stress the enumeration process after fixing a memory leak [1]:
>   cd /sys/bus/platform/drivers/dwmmc_rockchip
>   for i in $(seq 1 3000); do
>     echo "========================" $i
>     echo ff0f0000.dwmmc > unbind
>     sleep .5
>     echo ff0f0000.dwmmc > bind
>     while true; do
>       if [ -e /dev/mmcblk2 ]; then
>         break;
>       fi
>       sleep .1
>     done
>   done
> 
> It worked fine.

This may not be suitable for stable. So... hs200 started working in
mainline sometime. That does not mean it was fixed in all the various
stable trees, too.

How was this tested in respective -stable releases?

> [1] https://lkml.kernel.org/r/20190503233526.226272-1-dianders@chromium.org
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> Signed-off-by: Sasha Levin <sashal@kernel.org>

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 88+ messages in thread

* Re: [PATCH 4.19 03/74] ARM: dts: rockchip: Make rk3288-veyron-mickeys emmc work again
  2019-08-05 13:02 ` [PATCH 4.19 03/74] ARM: dts: rockchip: Make rk3288-veyron-mickeys emmc work again Greg Kroah-Hartman
@ 2019-08-05 14:45   ` Pavel Machek
  2019-08-13  0:01     ` Doug Anderson
  0 siblings, 1 reply; 88+ messages in thread
From: Pavel Machek @ 2019-08-05 14:45 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: linux-kernel, stable, Douglas Anderson, Heiko Stuebner, Sasha Levin

[-- Attachment #1: Type: text/plain, Size: 2609 bytes --]

On Mon 2019-08-05 15:02:16, Greg Kroah-Hartman wrote:
> [ Upstream commit 99fa066710f75f18f4d9a5bc5f6a711968a581d5 ]
> 
> When I try to boot rk3288-veyron-mickey I totally fail to make the
> eMMC work.  Specifically my logs (on Chrome OS 4.19):
> 
>   mmc_host mmc1: card is non-removable.
>   mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
>   mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
>   mmc1: switch to bus width 8 failed
>   mmc1: switch to bus width 4 failed
>   mmc1: new high speed MMC card at address 0001
>   mmcblk1: mmc1:0001 HAG2e 14.7 GiB
>   mmcblk1boot0: mmc1:0001 HAG2e partition 1 4.00 MiB
>   mmcblk1boot1: mmc1:0001 HAG2e partition 2 4.00 MiB
>   mmcblk1rpmb: mmc1:0001 HAG2e partition 3 4.00 MiB, chardev (243:0)
>   mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
>   mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
>   mmc1: switch to bus width 8 failed
>   mmc1: switch to bus width 4 failed
>   mmc1: tried to HW reset card, got error -110
>   mmcblk1: error -110 requesting status
>   mmcblk1: recovery failed!
>   print_req_error: I/O error, dev mmcblk1, sector 0
>   ...
> 
> When I remove the '/delete-property/mmc-hs200-1_8v' then everything is
> hunky dory.
> 
> That line comes from the original submission of the mickey dts
> upstream, so presumably at the time the HS200 was failing and just
> enumerating things as a high speed device was fine.  ...or maybe it's
> just that some mickey devices work when enumerating at "high speed",
> just not mine?
> 
> In any case, hs200 seems good now.  Let's turn it on.

Ok, so this was tested in v4.19; good. But AFAICT it is queued to
4.14, too... which may not be good idea unless it was tested there...?

Plus.. if this fixes stuff, that there are other configurations in the
dts that do not work. Should they be disabled or something?

									Pavel

> diff --git a/arch/arm/boot/dts/rk3288-veyron-mickey.dts b/arch/arm/boot/dts/rk3288-veyron-mickey.dts
> index 1e0158acf895d..a593d0a998fc8 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-mickey.dts
> +++ b/arch/arm/boot/dts/rk3288-veyron-mickey.dts
> @@ -124,10 +124,6 @@
>  	};
>  };
>  
> -&emmc {
> -	/delete-property/mmc-hs200-1_8v;
> -};
> -
>  &i2c2 {
>  	status = "disabled";
>  };

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 88+ messages in thread

* Re: [PATCH 4.19 04/74] ARM: dts: rockchip: Mark that the rk3288 timer might stop in suspend
  2019-08-05 13:02 ` [PATCH 4.19 04/74] ARM: dts: rockchip: Mark that the rk3288 timer might stop in suspend Greg Kroah-Hartman
@ 2019-08-05 14:47   ` Pavel Machek
  2019-08-13  0:04     ` Doug Anderson
  0 siblings, 1 reply; 88+ messages in thread
From: Pavel Machek @ 2019-08-05 14:47 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: linux-kernel, stable, Douglas Anderson, Heiko Stuebner, Sasha Levin

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

On Mon 2019-08-05 15:02:17, Greg Kroah-Hartman wrote:
> [ Upstream commit 8ef1ba39a9fa53d2205e633bc9b21840a275908e ]
> 
> This is similar to commit e6186820a745 ("arm64: dts: rockchip: Arch
> counter doesn't tick in system suspend").  Specifically on the rk3288
> it can be seen that the timer stops ticking in suspend if we end up
> running through the "osc_disable" path in rk3288_slp_mode_set().  In
> that path the 24 MHz clock will turn off and the timer stops.
> 
> To test this, I ran this on a Chrome OS filesystem:
>   before=$(date); \
>   suspend_stress_test -c1 --suspend_min=30 --suspend_max=31; \
>   echo ${before}; date
> 
> ...and I found that unless I plug in a device that requests USB wakeup
> to be active that the two calls to "date" would show that fewer than
> 30 seconds passed.
> 
> NOTE: deep suspend (where the 24 MHz clock gets disabled) isn't
> supported yet on upstream Linux so this was tested on a downstream
> kernel.

I guess this does no harm, but deep sleep is unlikely to be suppored
in the stable kernels, so ... is it good idea there?

Thanks,
								Pavel

> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -227,6 +227,7 @@
>  			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>  			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>  		clock-frequency = <24000000>;
> +		arm,no-tick-in-suspend;
>  	};
>  
>  	timer: timer@ff810000 {

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 88+ messages in thread

* Re: [PATCH 4.19 00/74] 4.19.65-stable review
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (73 preceding siblings ...)
  2019-08-05 13:03 ` [PATCH 4.19 74/74] scsi: mpt3sas: Use 63-bit DMA addressing on SAS35 HBA Greg Kroah-Hartman
@ 2019-08-05 18:35 ` kernelci.org bot
  2019-08-06  0:56 ` shuah
                   ` (3 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: kernelci.org bot @ 2019-08-05 18:35 UTC (permalink / raw)
  To: Greg Kroah-Hartman, linux-kernel
  Cc: Greg Kroah-Hartman, torvalds, akpm, linux, shuah, patches,
	ben.hutchings, lkft-triage, stable

stable-rc/linux-4.19.y boot: 65 boots: 1 failed, 64 passed (v4.19.64-75-g27e5d9acda64)

Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.64-75-g27e5d9acda64/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.64-75-g27e5d9acda64/

Tree: stable-rc
Branch: linux-4.19.y
Git Describe: v4.19.64-75-g27e5d9acda64
Git Commit: 27e5d9acda64f19f64a7db74e3bff765c11248bf
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 34 unique boards, 17 SoC families, 12 builds out of 206

Boot Regressions Detected:

arm:

    multi_v7_defconfig:
        gcc-8:
          exynos5250-snow:
              lab-collabora: new failure (last pass: v4.19.64)

Boot Failure Detected:

arm:
    multi_v7_defconfig:
        gcc-8:
            exynos5250-snow: 1 failed lab

---
For more info write to <info@kernelci.org>

^ permalink raw reply	[flat|nested] 88+ messages in thread

* Re: [PATCH 4.19 00/74] 4.19.65-stable review
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (74 preceding siblings ...)
  2019-08-05 18:35 ` [PATCH 4.19 00/74] 4.19.65-stable review kernelci.org bot
@ 2019-08-06  0:56 ` shuah
  2019-08-06  5:45 ` Naresh Kamboju
                   ` (2 subsequent siblings)
  78 siblings, 0 replies; 88+ messages in thread
From: shuah @ 2019-08-06  0:56 UTC (permalink / raw)
  To: Greg Kroah-Hartman, linux-kernel
  Cc: torvalds, akpm, linux, patches, ben.hutchings, lkft-triage,
	stable, shuah

On 8/5/19 7:02 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.65 release.
> There are 74 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed 07 Aug 2019 12:47:58 PM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
> 	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.65-rc1.gz
> or in the git tree and branch at:
> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah


^ permalink raw reply	[flat|nested] 88+ messages in thread

* Re: [PATCH 4.19 00/74] 4.19.65-stable review
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (75 preceding siblings ...)
  2019-08-06  0:56 ` shuah
@ 2019-08-06  5:45 ` Naresh Kamboju
  2019-08-06 15:49 ` Guenter Roeck
  2019-08-06 18:30 ` Jon Hunter
  78 siblings, 0 replies; 88+ messages in thread
From: Naresh Kamboju @ 2019-08-06  5:45 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
	Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable

On Mon, 5 Aug 2019 at 18:39, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.19.65 release.
> There are 74 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed 07 Aug 2019 12:47:58 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>         https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.65-rc1.gz
> or in the git tree and branch at:
>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

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

Summary
------------------------------------------------------------------------

kernel: 4.19.65-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: e2fa6c5f11d562e4b6d9d0eaf3f9adea96e72032
git describe: v4.19.64-75-ge2fa6c5f11d5
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.64-75-ge2fa6c5f11d5


No regressions (compared to build v4.19.64)

No fixes (compared to build v4.19.64)


Ran 25240 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-fs-tests
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests
* ssuite
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org

^ permalink raw reply	[flat|nested] 88+ messages in thread

* Re: [PATCH 4.19 00/74] 4.19.65-stable review
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (76 preceding siblings ...)
  2019-08-06  5:45 ` Naresh Kamboju
@ 2019-08-06 15:49 ` Guenter Roeck
  2019-08-06 18:30 ` Jon Hunter
  78 siblings, 0 replies; 88+ messages in thread
From: Guenter Roeck @ 2019-08-06 15:49 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
	lkft-triage, stable

On Mon, Aug 05, 2019 at 03:02:13PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.65 release.
> There are 74 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed 07 Aug 2019 12:47:58 PM UTC.
> Anything received after that time might be too late.
> 

Build results:
	total: 156 pass: 156 fail: 0
Qemu test results:
	total: 364 pass: 364 fail: 0

Guenter

^ permalink raw reply	[flat|nested] 88+ messages in thread

* Re: [PATCH 4.19 00/74] 4.19.65-stable review
  2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
                   ` (77 preceding siblings ...)
  2019-08-06 15:49 ` Guenter Roeck
@ 2019-08-06 18:30 ` Jon Hunter
  78 siblings, 0 replies; 88+ messages in thread
From: Jon Hunter @ 2019-08-06 18:30 UTC (permalink / raw)
  To: Greg Kroah-Hartman, linux-kernel
  Cc: torvalds, akpm, linux, shuah, patches, ben.hutchings,
	lkft-triage, stable, linux-tegra


On 05/08/2019 14:02, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.65 release.
> There are 74 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed 07 Aug 2019 12:47:58 PM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
> 	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.65-rc1.gz
> or in the git tree and branch at:
> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

All tests passing for Tegra ...

Test results for stable-v4.19:
    12 builds:	12 pass, 0 fail
    22 boots:	22 pass, 0 fail
    32 tests:	32 pass, 0 fail

Linux version:	4.19.65-rc1-ge2fa6c5f11d5
Boards tested:	tegra124-jetson-tk1, tegra186-p2771-0000,
                tegra194-p2972-0000, tegra20-ventana,
                tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

-- 
nvpublic

^ permalink raw reply	[flat|nested] 88+ messages in thread

* Re: [PATCH 4.19 46/74] mmc: dw_mmc: Fix occasional hang after tuning on eMMC
  2019-08-05 13:02 ` [PATCH 4.19 46/74] mmc: dw_mmc: Fix occasional hang after tuning on eMMC Greg Kroah-Hartman
@ 2019-08-06 22:31   ` Pavel Machek
  2019-08-06 22:48     ` Sasha Levin
  0 siblings, 1 reply; 88+ messages in thread
From: Pavel Machek @ 2019-08-06 22:31 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: linux-kernel, stable, Douglas Anderson, Marek Szyprowski,
	Alim Akhtar, Enric Balletbo i Serra, Ulf Hansson

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

Hi!

> I'm hoping that whatever problems exynos was having in the past are
> somehow magically fixed now and we can make the behavior the same for
> all commands.

Dunno. Maybe they are in mainline, but are they fixed in all the
stable releases this is being applied to?

Best regards,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 88+ messages in thread

* Re: [PATCH 4.19 46/74] mmc: dw_mmc: Fix occasional hang after tuning on eMMC
  2019-08-06 22:31   ` Pavel Machek
@ 2019-08-06 22:48     ` Sasha Levin
  0 siblings, 0 replies; 88+ messages in thread
From: Sasha Levin @ 2019-08-06 22:48 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Greg Kroah-Hartman, linux-kernel, stable, Douglas Anderson,
	Marek Szyprowski, Alim Akhtar, Enric Balletbo i Serra,
	Ulf Hansson

On Wed, Aug 07, 2019 at 12:31:39AM +0200, Pavel Machek wrote:
>Hi!
>
>> I'm hoping that whatever problems exynos was having in the past are
>> somehow magically fixed now and we can make the behavior the same for
>> all commands.
>
>Dunno. Maybe they are in mainline, but are they fixed in all the
>stable releases this is being applied to?

Are they not? If they're broken, then no one is using them now anyways.

If anyone tries, and it's still broken, we'll at least have a chance to
get it fixed.

--
Thanks,
Sasha

^ permalink raw reply	[flat|nested] 88+ messages in thread

* Re: [PATCH 4.19 02/74] ARM: dts: rockchip: Make rk3288-veyron-minnie run at hs200
  2019-08-05 14:41   ` Pavel Machek
@ 2019-08-07  2:26     ` Sasha Levin
  0 siblings, 0 replies; 88+ messages in thread
From: Sasha Levin @ 2019-08-07  2:26 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Greg Kroah-Hartman, linux-kernel, stable, Douglas Anderson,
	Heiko Stuebner

On Mon, Aug 05, 2019 at 04:41:12PM +0200, Pavel Machek wrote:
>Hi!
>
>> [ Upstream commit 1c0479023412ab7834f2e98b796eb0d8c627cd62 ]
>>
>> As some point hs200 was failing on rk3288-veyron-minnie.  See commit
>> 984926781122 ("ARM: dts: rockchip: temporarily remove emmc hs200 speed
>> from rk3288 minnie").  Although I didn't track down exactly when it
>> started working, it seems to work OK now, so let's turn it back on.
>>
>> To test this, I booted from SD card and then used this script to
>> stress the enumeration process after fixing a memory leak [1]:
>>   cd /sys/bus/platform/drivers/dwmmc_rockchip
>>   for i in $(seq 1 3000); do
>>     echo "========================" $i
>>     echo ff0f0000.dwmmc > unbind
>>     sleep .5
>>     echo ff0f0000.dwmmc > bind
>>     while true; do
>>       if [ -e /dev/mmcblk2 ]; then
>>         break;
>>       fi
>>       sleep .1
>>     done
>>   done
>>
>> It worked fine.
>
>This may not be suitable for stable. So... hs200 started working in
>mainline sometime. That does not mean it was fixed in all the various
>stable trees, too.
>
>How was this tested in respective -stable releases?

If you know of any other patches required on older stable kernels to
make this work I'll be more than happy to take them...

--
Thanks,
Sasha

^ permalink raw reply	[flat|nested] 88+ messages in thread

* Re: [PATCH 4.19 03/74] ARM: dts: rockchip: Make rk3288-veyron-mickeys emmc work again
  2019-08-05 14:45   ` Pavel Machek
@ 2019-08-13  0:01     ` Doug Anderson
  0 siblings, 0 replies; 88+ messages in thread
From: Doug Anderson @ 2019-08-13  0:01 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Greg Kroah-Hartman, LKML, # 4.0+, Heiko Stuebner, Sasha Levin

Hi,

On Mon, Aug 5, 2019 at 7:45 AM Pavel Machek <pavel@denx.de> wrote:
>
> On Mon 2019-08-05 15:02:16, Greg Kroah-Hartman wrote:
> > [ Upstream commit 99fa066710f75f18f4d9a5bc5f6a711968a581d5 ]
> >
> > When I try to boot rk3288-veyron-mickey I totally fail to make the
> > eMMC work.  Specifically my logs (on Chrome OS 4.19):
> >
> >   mmc_host mmc1: card is non-removable.
> >   mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
> >   mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
> >   mmc1: switch to bus width 8 failed
> >   mmc1: switch to bus width 4 failed
> >   mmc1: new high speed MMC card at address 0001
> >   mmcblk1: mmc1:0001 HAG2e 14.7 GiB
> >   mmcblk1boot0: mmc1:0001 HAG2e partition 1 4.00 MiB
> >   mmcblk1boot1: mmc1:0001 HAG2e partition 2 4.00 MiB
> >   mmcblk1rpmb: mmc1:0001 HAG2e partition 3 4.00 MiB, chardev (243:0)
> >   mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
> >   mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
> >   mmc1: switch to bus width 8 failed
> >   mmc1: switch to bus width 4 failed
> >   mmc1: tried to HW reset card, got error -110
> >   mmcblk1: error -110 requesting status
> >   mmcblk1: recovery failed!
> >   print_req_error: I/O error, dev mmcblk1, sector 0
> >   ...
> >
> > When I remove the '/delete-property/mmc-hs200-1_8v' then everything is
> > hunky dory.
> >
> > That line comes from the original submission of the mickey dts
> > upstream, so presumably at the time the HS200 was failing and just
> > enumerating things as a high speed device was fine.  ...or maybe it's
> > just that some mickey devices work when enumerating at "high speed",
> > just not mine?
> >
> > In any case, hs200 seems good now.  Let's turn it on.
>
> Ok, so this was tested in v4.19; good. But AFAICT it is queued to
> 4.14, too... which may not be good idea unless it was tested there...?
>
> Plus.. if this fixes stuff, that there are other configurations in the
> dts that do not work. Should they be disabled or something?

In general I don't have a good answer for you, but:

* The fact that nobody noticed that things were pretty broken here
implies that probably nobody is regularly testing mickey on upstream
and presumably nobody is testing mickey on stable, so likely it
doesn't matter a whole lot.

* The original mickey dts was from "Thu Dec 3 16:55:40 2015 +0100"
based upon kernel 4.4.  That means there were 10 kernel revisions
between it at 4.14.  If I had to guess without testing, I'd guess that
4.14 is still better off with this patch than without.

-Doug

^ permalink raw reply	[flat|nested] 88+ messages in thread

* Re: [PATCH 4.19 04/74] ARM: dts: rockchip: Mark that the rk3288 timer might stop in suspend
  2019-08-05 14:47   ` Pavel Machek
@ 2019-08-13  0:04     ` Doug Anderson
  0 siblings, 0 replies; 88+ messages in thread
From: Doug Anderson @ 2019-08-13  0:04 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Greg Kroah-Hartman, LKML, # 4.0+, Heiko Stuebner, Sasha Levin

Hi,

On Mon, Aug 5, 2019 at 7:47 AM Pavel Machek <pavel@denx.de> wrote:
>
> On Mon 2019-08-05 15:02:17, Greg Kroah-Hartman wrote:
> > [ Upstream commit 8ef1ba39a9fa53d2205e633bc9b21840a275908e ]
> >
> > This is similar to commit e6186820a745 ("arm64: dts: rockchip: Arch
> > counter doesn't tick in system suspend").  Specifically on the rk3288
> > it can be seen that the timer stops ticking in suspend if we end up
> > running through the "osc_disable" path in rk3288_slp_mode_set().  In
> > that path the 24 MHz clock will turn off and the timer stops.
> >
> > To test this, I ran this on a Chrome OS filesystem:
> >   before=$(date); \
> >   suspend_stress_test -c1 --suspend_min=30 --suspend_max=31; \
> >   echo ${before}; date
> >
> > ...and I found that unless I plug in a device that requests USB wakeup
> > to be active that the two calls to "date" would show that fewer than
> > 30 seconds passed.
> >
> > NOTE: deep suspend (where the 24 MHz clock gets disabled) isn't
> > supported yet on upstream Linux so this was tested on a downstream
> > kernel.
>
> I guess this does no harm, but deep sleep is unlikely to be suppored
> in the stable kernels, so ... is it good idea there?

People do merge stable kernels into local trees which have extra
patches (which might enable deep sleep).  Chrome OS is an example of
this.  If the patch does no harm then merging it seems nice.

That being said: we already have this in the Chrome OS tree, so unless
someone else is also mering stable into their tree and trying to
support rk3288 with deep sleep, this patch is unlikely to matter.
...so if everyone doesn't want it then it won't bother me.

-Doug

^ permalink raw reply	[flat|nested] 88+ messages in thread

end of thread, back to index

Thread overview: 88+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-05 13:02 [PATCH 4.19 00/74] 4.19.65-stable review Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 01/74] ARM: riscpc: fix DMA Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 02/74] ARM: dts: rockchip: Make rk3288-veyron-minnie run at hs200 Greg Kroah-Hartman
2019-08-05 14:41   ` Pavel Machek
2019-08-07  2:26     ` Sasha Levin
2019-08-05 13:02 ` [PATCH 4.19 03/74] ARM: dts: rockchip: Make rk3288-veyron-mickeys emmc work again Greg Kroah-Hartman
2019-08-05 14:45   ` Pavel Machek
2019-08-13  0:01     ` Doug Anderson
2019-08-05 13:02 ` [PATCH 4.19 04/74] ARM: dts: rockchip: Mark that the rk3288 timer might stop in suspend Greg Kroah-Hartman
2019-08-05 14:47   ` Pavel Machek
2019-08-13  0:04     ` Doug Anderson
2019-08-05 13:02 ` [PATCH 4.19 05/74] ftrace: Enable trampoline when rec count returns back to one Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 06/74] dmaengine: tegra-apb: Error out if DMA_PREP_INTERRUPT flag is unset Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 07/74] arm64: dts: rockchip: fix isp iommu clocks and power domain Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 08/74] kernel/module.c: Only return -EEXIST for modules that have finished loading Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 09/74] firmware/psci: psci_checker: Park kthreads before stopping them Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 10/74] MIPS: lantiq: Fix bitfield masking Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 11/74] dmaengine: rcar-dmac: Reject zero-length slave DMA requests Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 12/74] clk: tegra210: fix PLLU and PLLU_OUT1 Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 13/74] fs/adfs: super: fix use-after-free bug Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 14/74] clk: sprd: Add check for return value of sprd_clk_regmap_init() Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 15/74] btrfs: fix minimum number of chunk errors for DUP Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 16/74] btrfs: qgroup: Dont hold qgroup_ioctl_lock in btrfs_qgroup_inherit() Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 17/74] cifs: Fix a race condition with cifs_echo_request Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 18/74] ceph: fix improper use of smp_mb__before_atomic() Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 19/74] ceph: return -ERANGE if virtual xattr value didnt fit in buffer Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 20/74] ACPI: blacklist: fix clang warning for unused DMI table Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 21/74] scsi: zfcp: fix GCC compiler warning emitted with -Wmaybe-uninitialized Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 22/74] perf version: Fix segfault due to missing OPT_END() Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 23/74] x86: kvm: avoid constant-conversion warning Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 24/74] ACPI: fix false-positive -Wuninitialized warning Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 25/74] be2net: Signal that the device cannot transmit during reconfiguration Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 26/74] x86/apic: Silence -Wtype-limits compiler warnings Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 27/74] x86: math-emu: Hide clang warnings for 16-bit overflow Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 28/74] mm/cma.c: fail if fixed declaration cant be honored Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 29/74] lib/test_overflow.c: avoid tainting the kernel and fix wrap size Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 30/74] lib/test_string.c: avoid masking memset16/32/64 failures Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 31/74] coda: add error handling for fget Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 32/74] coda: fix build using bare-metal toolchain Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 33/74] uapi linux/coda_psdev.h: move upc_req definition from uapi to kernel side headers Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 34/74] drivers/rapidio/devices/rio_mport_cdev.c: NUL terminate some strings Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 35/74] ipc/mqueue.c: only perform resource calculation if user valid Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 36/74] mlxsw: spectrum_dcb: Configure DSCP map as the last rule is removed Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 37/74] xen/pv: Fix a boot up hang revealed by int3 self test Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 38/74] x86/kvm: Dont call kvm_spurious_fault() from .fixup Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 39/74] x86/paravirt: Fix callee-saved function ELF sizes Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 40/74] x86, boot: Remove multiple copy of static function sanitize_boot_params() Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 41/74] drm/nouveau: fix memory leak in nouveau_conn_reset() Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 42/74] kconfig: Clear "written" flag to avoid data loss Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 43/74] kbuild: initialize CLANG_FLAGS correctly in the top Makefile Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 44/74] Btrfs: fix incremental send failure after deduplication Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 45/74] Btrfs: fix race leading to fs corruption after transaction abort Greg Kroah-Hartman
2019-08-05 13:02 ` [PATCH 4.19 46/74] mmc: dw_mmc: Fix occasional hang after tuning on eMMC Greg Kroah-Hartman
2019-08-06 22:31   ` Pavel Machek
2019-08-06 22:48     ` Sasha Levin
2019-08-05 13:03 ` [PATCH 4.19 47/74] mmc: meson-mx-sdio: Fix misuse of GENMASK macro Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 48/74] gpiolib: fix incorrect IRQ requesting of an active-low lineevent Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 49/74] IB/hfi1: Fix Spectre v1 vulnerability Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 50/74] mtd: rawnand: micron: handle on-die "ECC-off" devices correctly Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 51/74] selinux: fix memory leak in policydb_init() Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 52/74] ALSA: hda: Fix 1-minute detection delay when i915 module is not available Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 53/74] mm: vmscan: check if mem cgroup is disabled or not before calling memcg slab shrinker Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 54/74] s390/dasd: fix endless loop after read unit address configuration Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 55/74] cgroup: kselftest: relax fs_spec checks Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 56/74] parisc: Fix build of compressed kernel even with debug enabled Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 57/74] drivers/perf: arm_pmu: Fix failure path in PM notifier Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 58/74] arm64: compat: Allow single-byte watchpoints on all addresses Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 59/74] arm64: cpufeature: Fix feature comparison for CTR_EL0.{CWG,ERG} Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 60/74] nbd: replace kill_bdev() with __invalidate_device() again Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 61/74] xen/swiotlb: fix condition for calling xen_destroy_contiguous_region() Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 62/74] IB/mlx5: Fix unreg_umr to ignore the mkey state Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 63/74] IB/mlx5: Use direct mkey destroy command upon UMR unreg failure Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 64/74] IB/mlx5: Move MRs to a kernel PD when freeing them to the MR cache Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 65/74] IB/mlx5: Fix clean_mr() to work in the expected order Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 66/74] IB/mlx5: Fix RSS Toeplitz setup to be aligned with the HW specification Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 67/74] IB/hfi1: Check for error on call to alloc_rsm_map_table Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 68/74] drm/i915/gvt: fix incorrect cache entry for guest page mapping Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 69/74] eeprom: at24: make spd world-readable again Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 70/74] ARC: enable uboot support unconditionally Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 71/74] objtool: Support GCC 9 cold subfunction naming scheme Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 72/74] gcc-9: properly declare the {pv,hv}clock_page storage Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 73/74] x86/vdso: Prevent segfaults due to hoisted vclock reads Greg Kroah-Hartman
2019-08-05 13:03 ` [PATCH 4.19 74/74] scsi: mpt3sas: Use 63-bit DMA addressing on SAS35 HBA Greg Kroah-Hartman
2019-08-05 18:35 ` [PATCH 4.19 00/74] 4.19.65-stable review kernelci.org bot
2019-08-06  0:56 ` shuah
2019-08-06  5:45 ` Naresh Kamboju
2019-08-06 15:49 ` Guenter Roeck
2019-08-06 18:30 ` Jon Hunter

Stable Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/stable/0 stable/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 stable stable/ https://lore.kernel.org/stable \
		stable@vger.kernel.org stable@archiver.kernel.org
	public-inbox-index stable

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.stable


AGPL code for this site: git clone https://public-inbox.org/ public-inbox