1. 11 Oct, 2019 40 commits
    • Mathieu Desnoyers's avatar
      sched/membarrier: Fix private expedited registration check · 6cb7aa1b
      Mathieu Desnoyers authored
      [ Upstream commit fc0d7738 ]
      
      Fix a logic flaw in the way membarrier_register_private_expedited()
      handles ready state checks for private expedited sync core and private
      expedited registrations.
      
      If a private expedited membarrier registration is first performed, and
      then a private expedited sync_core registration is performed, the ready
      state check will skip the second registration when it really should not.
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Kirill Tkhai <tkhai@yandex.ru>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Paul E. McKenney <paulmck@linux.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/20190919173705.2181-2-mathieu.desnoyers@efficios.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6cb7aa1b
    • Mathieu Desnoyers's avatar
      sched/membarrier: Call sync_core only before usermode for same mm · e250f2b6
      Mathieu Desnoyers authored
      [ Upstream commit 2840cf02 ]
      
      When the prev and next task's mm change, switch_mm() provides the core
      serializing guarantees before returning to usermode. The only case
      where an explicit core serialization is needed is when the scheduler
      keeps the same mm for prev and next.
      Suggested-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Kirill Tkhai <tkhai@yandex.ru>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul E. McKenney <paulmck@linux.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/20190919173705.2181-4-mathieu.desnoyers@efficios.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e250f2b6
    • Nathan Chancellor's avatar
      libnvdimm/nfit_test: Fix acpi_handle redefinition · 9f33b178
      Nathan Chancellor authored
      [ Upstream commit 59f08896 ]
      
      After commit 62974fc3 ("libnvdimm: Enable unit test infrastructure
      compile checks"), clang warns:
      
      In file included from
      ../drivers/nvdimm/../../tools/testing/nvdimm/test/iomap.c:15:
      ../drivers/nvdimm/../../tools/testing/nvdimm/test/nfit_test.h:206:15:
      warning: redefinition of typedef 'acpi_handle' is a C11 feature
      [-Wtypedef-redefinition]
      typedef void *acpi_handle;
                    ^
      ../include/acpi/actypes.h:424:15: note: previous definition is here
      typedef void *acpi_handle;      /* Actually a ptr to a NS Node */
                    ^
      1 warning generated.
      
      The include chain:
      
      iomap.c ->
          linux/acpi.h ->
              acpi/acpi.h ->
                  acpi/actypes.h
          nfit_test.h
      
      Avoid this by including linux/acpi.h in nfit_test.h, which allows us to
      remove both the typedef and the forward declaration of acpi_object.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/660Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Reviewed-by: default avatarIra Weiny <ira.weiny@intel.com>
      Link: https://lore.kernel.org/r/20190918042148.77553-1-natechancellor@gmail.comSigned-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9f33b178
    • zhengbin's avatar
      fuse: fix memleak in cuse_channel_open · 7b4f541f
      zhengbin authored
      [ Upstream commit 9ad09b19 ]
      
      If cuse_send_init fails, need to fuse_conn_put cc->fc.
      
      cuse_channel_open->fuse_conn_init->refcount_set(&fc->count, 1)
                       ->fuse_dev_alloc->fuse_conn_get
                       ->fuse_dev_free->fuse_conn_put
      
      Fixes: cc080e9e ("fuse: introduce per-instance fuse_dev structure")
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarzhengbin <zhengbin13@huawei.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7b4f541f
    • Aneesh Kumar K.V's avatar
      libnvdimm/region: Initialize bad block for volatile namespaces · 2e93d24a
      Aneesh Kumar K.V authored
      [ Upstream commit c42adf87 ]
      
      We do check for a bad block during namespace init and that use
      region bad block list. We need to initialize the bad block
      for volatile regions for this to work. We also observe a lockdep
      warning as below because the lock is not initialized correctly
      since we skip bad block init for volatile regions.
      
       INFO: trying to register non-static key.
       the code is fine but needs lockdep annotation.
       turning off the locking correctness validator.
       CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc1-15699-g3dee241c937e #149
       Call Trace:
       [c0000000f95cb250] [c00000000147dd84] dump_stack+0xe8/0x164 (unreliable)
       [c0000000f95cb2a0] [c00000000022ccd8] register_lock_class+0x308/0xa60
       [c0000000f95cb3a0] [c000000000229cc0] __lock_acquire+0x170/0x1ff0
       [c0000000f95cb4c0] [c00000000022c740] lock_acquire+0x220/0x270
       [c0000000f95cb580] [c000000000a93230] badblocks_check+0xc0/0x290
       [c0000000f95cb5f0] [c000000000d97540] nd_pfn_validate+0x5c0/0x7f0
       [c0000000f95cb6d0] [c000000000d98300] nd_dax_probe+0xd0/0x1f0
       [c0000000f95cb760] [c000000000d9b66c] nd_pmem_probe+0x10c/0x160
       [c0000000f95cb790] [c000000000d7f5ec] nvdimm_bus_probe+0x10c/0x240
       [c0000000f95cb820] [c000000000d0f844] really_probe+0x254/0x4e0
       [c0000000f95cb8b0] [c000000000d0fdfc] driver_probe_device+0x16c/0x1e0
       [c0000000f95cb930] [c000000000d10238] device_driver_attach+0x68/0xa0
       [c0000000f95cb970] [c000000000d1040c] __driver_attach+0x19c/0x1c0
       [c0000000f95cb9f0] [c000000000d0c4c4] bus_for_each_dev+0x94/0x130
       [c0000000f95cba50] [c000000000d0f014] driver_attach+0x34/0x50
       [c0000000f95cba70] [c000000000d0e208] bus_add_driver+0x178/0x2f0
       [c0000000f95cbb00] [c000000000d117c8] driver_register+0x108/0x170
       [c0000000f95cbb70] [c000000000d7edb0] __nd_driver_register+0xe0/0x100
       [c0000000f95cbbd0] [c000000001a6baa4] nd_pmem_driver_init+0x34/0x48
       [c0000000f95cbbf0] [c0000000000106f4] do_one_initcall+0x1d4/0x4b0
       [c0000000f95cbcd0] [c0000000019f499c] kernel_init_freeable+0x544/0x65c
       [c0000000f95cbdb0] [c000000000010d6c] kernel_init+0x2c/0x180
       [c0000000f95cbe20] [c00000000000b954] ret_from_kernel_thread+0x5c/0x68
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      Link: https://lore.kernel.org/r/20190919083355.26340-1-aneesh.kumar@linux.ibm.comSigned-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2e93d24a
    • Stefan Mavrodiev's avatar
      thermal_hwmon: Sanitize thermal_zone type · 9025adf3
      Stefan Mavrodiev authored
      [ Upstream commit 8c7aa184 ]
      
      When calling thermal_add_hwmon_sysfs(), the device type is sanitized by
      replacing '-' with '_'. However tz->type remains unsanitized. Thus
      calling thermal_hwmon_lookup_by_type() returns no device. And if there is
      no device, thermal_remove_hwmon_sysfs() fails with "hwmon device lookup
      failed!".
      
      The result is unregisted hwmon devices in the sysfs.
      
      Fixes: 409ef0ba ("thermal_hwmon: Sanitize attribute name passed to hwmon")
      Signed-off-by: default avatarStefan Mavrodiev <stefan@olimex.com>
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9025adf3
    • Ido Schimmel's avatar
      thermal: Fix use-after-free when unregistering thermal zone device · c01a9dbe
      Ido Schimmel authored
      [ Upstream commit 1851799e ]
      
      thermal_zone_device_unregister() cancels the delayed work that polls the
      thermal zone, but it does not wait for it to finish. This is racy with
      respect to the freeing of the thermal zone device, which can result in a
      use-after-free [1].
      
      Fix this by waiting for the delayed work to finish before freeing the
      thermal zone device. Note that thermal_zone_device_set_polling() is
      never invoked from an atomic context, so it is safe to call
      cancel_delayed_work_sync() that can block.
      
      [1]
      [  +0.002221] ==================================================================
      [  +0.000064] BUG: KASAN: use-after-free in __mutex_lock+0x1076/0x11c0
      [  +0.000016] Read of size 8 at addr ffff8881e48e0450 by task kworker/1:0/17
      
      [  +0.000023] CPU: 1 PID: 17 Comm: kworker/1:0 Not tainted 5.2.0-rc6-custom-02495-g8e73ca3be4af #1701
      [  +0.000010] Hardware name: Mellanox Technologies Ltd. MSN2100-CB2FO/SA001017, BIOS 5.6.5 06/07/2016
      [  +0.000016] Workqueue: events_freezable_power_ thermal_zone_device_check
      [  +0.000012] Call Trace:
      [  +0.000021]  dump_stack+0xa9/0x10e
      [  +0.000020]  print_address_description.cold.2+0x9/0x25e
      [  +0.000018]  __kasan_report.cold.3+0x78/0x9d
      [  +0.000016]  kasan_report+0xe/0x20
      [  +0.000016]  __mutex_lock+0x1076/0x11c0
      [  +0.000014]  step_wise_throttle+0x72/0x150
      [  +0.000018]  handle_thermal_trip+0x167/0x760
      [  +0.000019]  thermal_zone_device_update+0x19e/0x5f0
      [  +0.000019]  process_one_work+0x969/0x16f0
      [  +0.000017]  worker_thread+0x91/0xc40
      [  +0.000014]  kthread+0x33d/0x400
      [  +0.000015]  ret_from_fork+0x3a/0x50
      
      [  +0.000020] Allocated by task 1:
      [  +0.000015]  save_stack+0x19/0x80
      [  +0.000015]  __kasan_kmalloc.constprop.4+0xc1/0xd0
      [  +0.000014]  kmem_cache_alloc_trace+0x152/0x320
      [  +0.000015]  thermal_zone_device_register+0x1b4/0x13a0
      [  +0.000015]  mlxsw_thermal_init+0xc92/0x23d0
      [  +0.000014]  __mlxsw_core_bus_device_register+0x659/0x11b0
      [  +0.000013]  mlxsw_core_bus_device_register+0x3d/0x90
      [  +0.000013]  mlxsw_pci_probe+0x355/0x4b0
      [  +0.000014]  local_pci_probe+0xc3/0x150
      [  +0.000013]  pci_device_probe+0x280/0x410
      [  +0.000013]  really_probe+0x26a/0xbb0
      [  +0.000013]  driver_probe_device+0x208/0x2e0
      [  +0.000013]  device_driver_attach+0xfe/0x140
      [  +0.000013]  __driver_attach+0x110/0x310
      [  +0.000013]  bus_for_each_dev+0x14b/0x1d0
      [  +0.000013]  driver_register+0x1c0/0x400
      [  +0.000015]  mlxsw_sp_module_init+0x5d/0xd3
      [  +0.000014]  do_one_initcall+0x239/0x4dd
      [  +0.000013]  kernel_init_freeable+0x42b/0x4e8
      [  +0.000012]  kernel_init+0x11/0x18b
      [  +0.000013]  ret_from_fork+0x3a/0x50
      
      [  +0.000015] Freed by task 581:
      [  +0.000013]  save_stack+0x19/0x80
      [  +0.000014]  __kasan_slab_free+0x125/0x170
      [  +0.000013]  kfree+0xf3/0x310
      [  +0.000013]  thermal_release+0xc7/0xf0
      [  +0.000014]  device_release+0x77/0x200
      [  +0.000014]  kobject_put+0x1a8/0x4c0
      [  +0.000014]  device_unregister+0x38/0xc0
      [  +0.000014]  thermal_zone_device_unregister+0x54e/0x6a0
      [  +0.000014]  mlxsw_thermal_fini+0x184/0x35a
      [  +0.000014]  mlxsw_core_bus_device_unregister+0x10a/0x640
      [  +0.000013]  mlxsw_devlink_core_bus_device_reload+0x92/0x210
      [  +0.000015]  devlink_nl_cmd_reload+0x113/0x1f0
      [  +0.000014]  genl_family_rcv_msg+0x700/0xee0
      [  +0.000013]  genl_rcv_msg+0xca/0x170
      [  +0.000013]  netlink_rcv_skb+0x137/0x3a0
      [  +0.000012]  genl_rcv+0x29/0x40
      [  +0.000013]  netlink_unicast+0x49b/0x660
      [  +0.000013]  netlink_sendmsg+0x755/0xc90
      [  +0.000013]  __sys_sendto+0x3de/0x430
      [  +0.000013]  __x64_sys_sendto+0xe2/0x1b0
      [  +0.000013]  do_syscall_64+0xa4/0x4d0
      [  +0.000013]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      [  +0.000017] The buggy address belongs to the object at ffff8881e48e0008
                     which belongs to the cache kmalloc-2k of size 2048
      [  +0.000012] The buggy address is located 1096 bytes inside of
                     2048-byte region [ffff8881e48e0008, ffff8881e48e0808)
      [  +0.000007] The buggy address belongs to the page:
      [  +0.000012] page:ffffea0007923800 refcount:1 mapcount:0 mapping:ffff88823680d0c0 index:0x0 compound_mapcount: 0
      [  +0.000020] flags: 0x200000000010200(slab|head)
      [  +0.000019] raw: 0200000000010200 ffffea0007682008 ffffea00076ab808 ffff88823680d0c0
      [  +0.000016] raw: 0000000000000000 00000000000d000d 00000001ffffffff 0000000000000000
      [  +0.000007] page dumped because: kasan: bad access detected
      
      [  +0.000012] Memory state around the buggy address:
      [  +0.000012]  ffff8881e48e0300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  +0.000012]  ffff8881e48e0380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  +0.000012] >ffff8881e48e0400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  +0.000008]                                                  ^
      [  +0.000012]  ffff8881e48e0480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  +0.000012]  ffff8881e48e0500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  +0.000007] ==================================================================
      
      Fixes: b1569e99 ("ACPI: move thermal trip handling to generic thermal layer")
      Reported-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c01a9dbe
    • Sanjay R Mehta's avatar
      ntb: point to right memory window index · 55ebeb4e
      Sanjay R Mehta authored
      [ Upstream commit ae89339b ]
      
      second parameter of ntb_peer_mw_get_addr is pointing to wrong memory
      window index by passing "peer gidx" instead of "local gidx".
      
      For ex, "local gidx" value is '0' and "peer gidx" value is '1', then
      
      on peer side ntb_mw_set_trans() api is used as below with gidx pointing to
      local side gidx which is '0', so memroy window '0' is chosen and XLAT '0'
      will be programmed by peer side.
      
          ntb_mw_set_trans(perf->ntb, peer->pidx, peer->gidx, peer->inbuf_xlat,
                          peer->inbuf_size);
      
      Now, on local side ntb_peer_mw_get_addr() is been used as below with gidx
      pointing to "peer gidx" which is '1', so pointing to memory window '1'
      instead of memory window '0'.
      
          ntb_peer_mw_get_addr(perf->ntb,  peer->gidx, &phys_addr,
                              &peer->outbuf_size);
      
      So this patch pass "local gidx" as parameter to ntb_peer_mw_get_addr().
      Signed-off-by: default avatarSanjay R Mehta <sanju.mehta@amd.com>
      Signed-off-by: default avatarJon Mason <jdmason@kudzu.us>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      55ebeb4e
    • Arvind Sankar's avatar
      x86/purgatory: Disable the stackleak GCC plugin for the purgatory · 9dabade5
      Arvind Sankar authored
      [ Upstream commit ca14c996 ]
      
      Since commit:
      
        b059f801 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS")
      
      kexec breaks if GCC_PLUGIN_STACKLEAK=y is enabled, as the purgatory
      contains undefined references to stackleak_track_stack.
      
      Attempting to load a kexec kernel results in this failure:
      
        kexec: Undefined symbol: stackleak_track_stack
        kexec-bzImage64: Loading purgatory failed
      
      Fix this by disabling the stackleak plugin for the purgatory.
      Signed-off-by: default avatarArvind Sankar <nivedita@alum.mit.edu>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: b059f801 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS")
      Link: https://lkml.kernel.org/r/20190923171753.GA2252517@rani.riverdale.lanSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9dabade5
    • Fabrice Gasnier's avatar
      pwm: stm32-lp: Add check in case requested period cannot be achieved · 65348659
      Fabrice Gasnier authored
      [ Upstream commit c91e3234 ]
      
      LPTimer can use a 32KHz clock for counting. It depends on clock tree
      configuration. In such a case, PWM output frequency range is limited.
      Although unlikely, nothing prevents user from requesting a PWM frequency
      above counting clock (32KHz for instance):
      - This causes (prd - 1) = 0xffff to be written in ARR register later in
      the apply() routine.
      This results in badly configured PWM period (and also duty_cycle).
      Add a check to report an error is such a case.
      Signed-off-by: default avatarFabrice Gasnier <fabrice.gasnier@st.com>
      Reviewed-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarThierry Reding <thierry.reding@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      65348659
    • Trond Myklebust's avatar
      pNFS: Ensure we do clear the return-on-close layout stateid on fatal errors · 19b1c70e
      Trond Myklebust authored
      [ Upstream commit 9c47b18c ]
      
      IF the server rejected our layout return with a state error such as
      NFS4ERR_BAD_STATEID, or even a stale inode error, then we do want
      to clear out all the remaining layout segments and mark that stateid
      as invalid.
      
      Fixes: 1c5bd76d ("pNFS: Enable layoutreturn operation for...")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      19b1c70e
    • Trek's avatar
      drm/amdgpu: Check for valid number of registers to read · 1c70ae6a
      Trek authored
      [ Upstream commit 73d8e6c7 ]
      
      Do not try to allocate any amount of memory requested by the user.
      Instead limit it to 128 registers. Actually the longest series of
      consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
      mmGB_MACROTILE_MODE0-15 (0x2644-0x2673).
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111273Signed-off-by: default avatarTrek <trek00@inbox.ru>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1c70ae6a
    • Felix Kuehling's avatar
      drm/amdgpu: Fix KFD-related kernel oops on Hawaii · e0af3b19
      Felix Kuehling authored
      [ Upstream commit dcafbd50 ]
      
      Hawaii needs to flush caches explicitly, submitting an IB in a user
      VMID from kernel mode. There is no s_fence in this case.
      
      Fixes: eb3961a5 ("drm/amdgpu: remove fence context from the job")
      Signed-off-by: default avatarFelix Kuehling <Felix.Kuehling@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e0af3b19
    • Florian Westphal's avatar
      netfilter: nf_tables: allow lookups in dynamic sets · f7ace7f2
      Florian Westphal authored
      [ Upstream commit acab7131 ]
      
      This un-breaks lookups in sets that have the 'dynamic' flag set.
      Given this active example configuration:
      
      table filter {
        set set1 {
          type ipv4_addr
          size 64
          flags dynamic,timeout
          timeout 1m
        }
      
        chain input {
           type filter hook input priority 0; policy accept;
        }
      }
      
      ... this works:
      nft add rule ip filter input add @set1 { ip saddr }
      
      -> whenever rule is triggered, the source ip address is inserted
      into the set (if it did not exist).
      
      This won't work:
      nft add rule ip filter input ip saddr @set1 counter
      Error: Could not process rule: Operation not supported
      
      In other words, we can add entries to the set, but then can't make
      matching decision based on that set.
      
      That is just wrong -- all set backends support lookups (else they would
      not be very useful).
      The failure comes from an explicit rejection in nft_lookup.c.
      
      Looking at the history, it seems like NFT_SET_EVAL used to mean
      'set contains expressions' (aka. "is a meter"), for instance something like
      
       nft add rule ip filter input meter example { ip saddr limit rate 10/second }
       or
       nft add rule ip filter input meter example { ip saddr counter }
      
      The actual meaning of NFT_SET_EVAL however, is
      'set can be updated from the packet path'.
      
      'meters' and packet-path insertions into sets, such as
      'add @set { ip saddr }' use exactly the same kernel code (nft_dynset.c)
      and thus require a set backend that provides the ->update() function.
      
      The only set that provides this also is the only one that has the
      NFT_SET_EVAL feature flag.
      
      Removing the wrong check makes the above example work.
      While at it, also fix the flag check during set instantiation to
      allow supported combinations only.
      
      Fixes: 8aeff920 ("netfilter: nf_tables: add stateful object reference to set elements")
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f7ace7f2
    • Ryan Chen's avatar
      watchdog: aspeed: Add support for AST2600 · f217883b
      Ryan Chen authored
      [ Upstream commit b3528b48 ]
      
      The ast2600 can be supported by the same code as the ast2500.
      Signed-off-by: default avatarRyan Chen <ryan_chen@aspeedtech.com>
      Signed-off-by: default avatarJoel Stanley <joel@jms.id.au>
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Link: https://lore.kernel.org/r/20190819051738.17370-3-joel@jms.id.auSigned-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarWim Van Sebroeck <wim@linux-watchdog.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f217883b
    • Erqi Chen's avatar
      ceph: reconnect connection if session hang in opening state · 520c2a64
      Erqi Chen authored
      [ Upstream commit 71a228bc ]
      
      If client mds session is evicted in CEPH_MDS_SESSION_OPENING state,
      mds won't send session msg to client, and delayed_work skip
      CEPH_MDS_SESSION_OPENING state session, the session hang forever.
      
      Allow ceph_con_keepalive to reconnect a session in OPENING to avoid
      session hang. Also, ensure that we skip sessions in RESTARTING and
      REJECTED states since those states can't be resurrected by issuing
      a keepalive.
      
      Link: https://tracker.ceph.com/issues/41551
      Signed-off-by: Erqi Chen chenerqi@gmail.com
      Reviewed-by: default avatar"Yan, Zheng" <zyan@redhat.com>
      Signed-off-by: default avatarJeff Layton <jlayton@kernel.org>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      520c2a64
    • Luis Henriques's avatar
      ceph: fix directories inode i_blkbits initialization · 0275113f
      Luis Henriques authored
      [ Upstream commit 75067034 ]
      
      When filling an inode with info from the MDS, i_blkbits is being
      initialized using fl_stripe_unit, which contains the stripe unit in
      bytes.  Unfortunately, this doesn't make sense for directories as they
      have fl_stripe_unit set to '0'.  This means that i_blkbits will be set
      to 0xff, causing an UBSAN undefined behaviour in i_blocksize():
      
        UBSAN: Undefined behaviour in ./include/linux/fs.h:731:12
        shift exponent 255 is too large for 32-bit type 'int'
      
      Fix this by initializing i_blkbits to CEPH_BLOCK_SHIFT if fl_stripe_unit
      is zero.
      Signed-off-by: default avatarLuis Henriques <lhenriques@suse.com>
      Reviewed-by: default avatarJeff Layton <jlayton@kernel.org>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0275113f
    • Igor Druzhinin's avatar
      xen/pci: reserve MCFG areas earlier · 2bc2a90a
      Igor Druzhinin authored
      [ Upstream commit a4098bc6 ]
      
      If MCFG area is not reserved in E820, Xen by default will defer its usage
      until Dom0 registers it explicitly after ACPI parser recognizes it as
      a reserved resource in DSDT. Having it reserved in E820 is not
      mandatory according to "PCI Firmware Specification, rev 3.2" (par. 4.1.2)
      and firmware is free to keep a hole in E820 in that place. Xen doesn't know
      what exactly is inside this hole since it lacks full ACPI view of the
      platform therefore it's potentially harmful to access MCFG region
      without additional checks as some machines are known to provide
      inconsistent information on the size of the region.
      
      Now xen_mcfg_late() runs after acpi_init() which is too late as some basic
      PCI enumeration starts exactly there as well. Trying to register a device
      prior to MCFG reservation causes multiple problems with PCIe extended
      capability initializations in Xen (e.g. SR-IOV VF BAR sizing). There are
      no convenient hooks for us to subscribe to so register MCFG areas earlier
      upon the first invocation of xen_add_device(). It should be safe to do once
      since all the boot time buses must have their MCFG areas in MCFG table
      already and we don't support PCI bus hot-plug.
      Signed-off-by: default avatarIgor Druzhinin <igor.druzhinin@citrix.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2bc2a90a
    • Chengguang Xu's avatar
      9p: avoid attaching writeback_fid on mmap with type PRIVATE · 18dd2b05
      Chengguang Xu authored
      [ Upstream commit c87a37eb ]
      
      Currently on mmap cache policy, we always attach writeback_fid
      whether mmap type is SHARED or PRIVATE. However, in the use case
      of kata-container which combines 9p(Guest OS) with overlayfs(Host OS),
      this behavior will trigger overlayfs' copy-up when excute command
      inside container.
      
      Link: http://lkml.kernel.org/r/20190820100325.10313-1-cgxu519@zoho.com.cnSigned-off-by: default avatarChengguang Xu <cgxu519@zoho.com.cn>
      Signed-off-by: default avatarDominique Martinet <dominique.martinet@cea.fr>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      18dd2b05
    • Lu Shuaibing's avatar
      9p: Transport error uninitialized · 07f3596c
      Lu Shuaibing authored
      [ Upstream commit 0ce772fe ]
      
      The p9_tag_alloc() does not initialize the transport error t_err field.
      The struct p9_req_t *req is allocated and stored in a struct p9_client
      variable. The field t_err is never initialized before p9_conn_cancel()
      checks its value.
      
      KUMSAN(KernelUninitializedMemorySantizer, a new error detection tool)
      reports this bug.
      
      ==================================================================
      BUG: KUMSAN: use of uninitialized memory in p9_conn_cancel+0x2d9/0x3b0
      Read of size 4 at addr ffff88805f9b600c by task kworker/1:2/1216
      
      CPU: 1 PID: 1216 Comm: kworker/1:2 Not tainted 5.2.0-rc4+ #28
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      Workqueue: events p9_write_work
      Call Trace:
       dump_stack+0x75/0xae
       __kumsan_report+0x17c/0x3e6
       kumsan_report+0xe/0x20
       p9_conn_cancel+0x2d9/0x3b0
       p9_write_work+0x183/0x4a0
       process_one_work+0x4d1/0x8c0
       worker_thread+0x6e/0x780
       kthread+0x1ca/0x1f0
       ret_from_fork+0x35/0x40
      
      Allocated by task 1979:
       save_stack+0x19/0x80
       __kumsan_kmalloc.constprop.3+0xbc/0x120
       kmem_cache_alloc+0xa7/0x170
       p9_client_prepare_req.part.9+0x3b/0x380
       p9_client_rpc+0x15e/0x880
       p9_client_create+0x3d0/0xac0
       v9fs_session_init+0x192/0xc80
       v9fs_mount+0x67/0x470
       legacy_get_tree+0x70/0xd0
       vfs_get_tree+0x4a/0x1c0
       do_mount+0xba9/0xf90
       ksys_mount+0xa8/0x120
       __x64_sys_mount+0x62/0x70
       do_syscall_64+0x6d/0x1e0
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Freed by task 0:
      (stack is not available)
      
      The buggy address belongs to the object at ffff88805f9b6008
       which belongs to the cache p9_req_t of size 144
      The buggy address is located 4 bytes inside of
       144-byte region [ffff88805f9b6008, ffff88805f9b6098)
      The buggy address belongs to the page:
      page:ffffea00017e6d80 refcount:1 mapcount:0 mapping:ffff888068b63740 index:0xffff88805f9b7d90 compound_mapcount: 0
      flags: 0x100000000010200(slab|head)
      raw: 0100000000010200 ffff888068b66450 ffff888068b66450 ffff888068b63740
      raw: ffff88805f9b7d90 0000000000100001 00000001ffffffff 0000000000000000
      page dumped because: kumsan: bad access detected
      ==================================================================
      
      Link: http://lkml.kernel.org/r/20190613070854.10434-1-shuaibinglu@126.comSigned-off-by: default avatarLu Shuaibing <shuaibinglu@126.com>
      [dominique.martinet@cea.fr: grouped the added init with the others]
      Signed-off-by: default avatarDominique Martinet <dominique.martinet@cea.fr>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      07f3596c
    • Jia-Ju Bai's avatar
      fs: nfs: Fix possible null-pointer dereferences in encode_attrs() · 448deb13
      Jia-Ju Bai authored
      [ Upstream commit e2751463 ]
      
      In encode_attrs(), there is an if statement on line 1145 to check
      whether label is NULL:
          if (label && (attrmask[2] & FATTR4_WORD2_SECURITY_LABEL))
      
      When label is NULL, it is used on lines 1178-1181:
          *p++ = cpu_to_be32(label->lfs);
          *p++ = cpu_to_be32(label->pi);
          *p++ = cpu_to_be32(label->len);
          p = xdr_encode_opaque_fixed(p, label->label, label->len);
      
      To fix these bugs, label is checked before being used.
      
      These bugs are found by a static analysis tool STCheck written by us.
      Signed-off-by: default avatarJia-Ju Bai <baijiaju1990@gmail.com>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      448deb13
    • Sascha Hauer's avatar
      ima: fix freeing ongoing ahash_request · 4753e7a8
      Sascha Hauer authored
      [ Upstream commit 4ece3125 ]
      
      integrity_kernel_read() can fail in which case we forward to call
      ahash_request_free() on a currently running request. We have to wait
      for its completion before we can free the request.
      
      This was observed by interrupting a "find / -type f -xdev -print0 | xargs -0
      cat 1>/dev/null" with ctrl-c on an IMA enabled filesystem.
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4753e7a8
    • Sascha Hauer's avatar
      ima: always return negative code for error · b69c3085
      Sascha Hauer authored
      [ Upstream commit f5e10401 ]
      
      integrity_kernel_read() returns the number of bytes read. If this is
      a short read then this positive value is returned from
      ima_calc_file_hash_atfm(). Currently this is only indirectly called from
      ima_calc_file_hash() and this function only tests for the return value
      being zero or nonzero and also doesn't forward the return value.
      Nevertheless there's no point in returning a positive value as an error,
      so translate a short read into -EINVAL.
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b69c3085
    • Will Deacon's avatar
      arm64: cpufeature: Detect SSBS and advertise to userspace · 6df3c66d
      Will Deacon authored
      commit d71be2b6 upstream.
      
      Armv8.5 introduces a new PSTATE bit known as Speculative Store Bypass
      Safe (SSBS) which can be used as a mitigation against Spectre variant 4.
      
      Additionally, a CPU may provide instructions to manipulate PSTATE.SSBS
      directly, so that userspace can toggle the SSBS control without trapping
      to the kernel.
      
      This patch probes for the existence of SSBS and advertise the new instructions
      to userspace if they exist.
      Reviewed-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6df3c66d
    • Johannes Berg's avatar
      cfg80211: initialize on-stack chandefs · 3a0e6733
      Johannes Berg authored
      commit f43e5210 upstream.
      
      In a few places we don't properly initialize on-stack chandefs,
      resulting in EDMG data to be non-zero, which broke things.
      
      Additionally, in a few places we rely on the driver to init the
      data completely, but perhaps we shouldn't as non-EDMG drivers
      may not initialize the EDMG data, also initialize it there.
      
      Cc: stable@vger.kernel.org
      Fixes: 2a38075c ("nl80211: Add support for EDMG channels")
      Reported-by: default avatarDmitry Osipenko <digetx@gmail.com>
      Tested-by: default avatarDmitry Osipenko <digetx@gmail.com>
      Link: https://lore.kernel.org/r/1569239475-I2dcce394ecf873376c386a78f31c2ec8b538fa25@changeidSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a0e6733
    • Vasily Gorbik's avatar
      s390/cio: avoid calling strlen on null pointer · 16c75eb1
      Vasily Gorbik authored
      commit ea298e6e upstream.
      
      Fix the following kasan finding:
      BUG: KASAN: global-out-of-bounds in ccwgroup_create_dev+0x850/0x1140
      Read of size 1 at addr 0000000000000000 by task systemd-udevd.r/561
      
      CPU: 30 PID: 561 Comm: systemd-udevd.r Tainted: G    B
      Hardware name: IBM 3906 M04 704 (LPAR)
      Call Trace:
      ([<0000000231b3db7e>] show_stack+0x14e/0x1a8)
       [<0000000233826410>] dump_stack+0x1d0/0x218
       [<000000023216fac4>] print_address_description+0x64/0x380
       [<000000023216f5a8>] __kasan_report+0x138/0x168
       [<00000002331b8378>] ccwgroup_create_dev+0x850/0x1140
       [<00000002332b618a>] group_store+0x3a/0x50
       [<00000002323ac706>] kernfs_fop_write+0x246/0x3b8
       [<00000002321d409a>] vfs_write+0x132/0x450
       [<00000002321d47da>] ksys_write+0x122/0x208
       [<0000000233877102>] system_call+0x2a6/0x2c8
      
      Triggered by:
      openat(AT_FDCWD, "/sys/bus/ccwgroup/drivers/qeth/group",
      		O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 16
      write(16, "0.0.bd00,0.0.bd01,0.0.bd02", 26) = 26
      
      The problem is that __get_next_id in ccwgroup_create_dev might set "buf"
      buffer pointer to NULL and explicit check for that is required.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarSebastian Ott <sebott@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16c75eb1
    • Johan Hovold's avatar
      ieee802154: atusb: fix use-after-free at disconnect · 3f41e88f
      Johan Hovold authored
      commit 7fd25e6f upstream.
      
      The disconnect callback was accessing the hardware-descriptor private
      data after having having freed it.
      
      Fixes: 7490b008 ("ieee802154: add support for atusb transceiver")
      Cc: stable <stable@vger.kernel.org>     # 4.2
      Cc: Alexander Aring <alex.aring@gmail.com>
      Reported-by: syzbot+f4509a9138a1472e7e80@syzkaller.appspotmail.com
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarStefan Schmidt <stefan@datenfreihafen.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3f41e88f
    • Juergen Gross's avatar
      xen/xenbus: fix self-deadlock after killing user process · 975859bb
      Juergen Gross authored
      commit a8fabb38 upstream.
      
      In case a user process using xenbus has open transactions and is killed
      e.g. via ctrl-C the following cleanup of the allocated resources might
      result in a deadlock due to trying to end a transaction in the xenbus
      worker thread:
      
      [ 2551.474706] INFO: task xenbus:37 blocked for more than 120 seconds.
      [ 2551.492215]       Tainted: P           OE     5.0.0-29-generic #5
      [ 2551.510263] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 2551.528585] xenbus          D    0    37      2 0x80000080
      [ 2551.528590] Call Trace:
      [ 2551.528603]  __schedule+0x2c0/0x870
      [ 2551.528606]  ? _cond_resched+0x19/0x40
      [ 2551.528632]  schedule+0x2c/0x70
      [ 2551.528637]  xs_talkv+0x1ec/0x2b0
      [ 2551.528642]  ? wait_woken+0x80/0x80
      [ 2551.528645]  xs_single+0x53/0x80
      [ 2551.528648]  xenbus_transaction_end+0x3b/0x70
      [ 2551.528651]  xenbus_file_free+0x5a/0x160
      [ 2551.528654]  xenbus_dev_queue_reply+0xc4/0x220
      [ 2551.528657]  xenbus_thread+0x7de/0x880
      [ 2551.528660]  ? wait_woken+0x80/0x80
      [ 2551.528665]  kthread+0x121/0x140
      [ 2551.528667]  ? xb_read+0x1d0/0x1d0
      [ 2551.528670]  ? kthread_park+0x90/0x90
      [ 2551.528673]  ret_from_fork+0x35/0x40
      
      Fix this by doing the cleanup via a workqueue instead.
      Reported-by: default avatarJames Dingwall <james@dingwall.me.uk>
      Fixes: fd8aa909 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses")
      Cc: <stable@vger.kernel.org> # 4.11
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      975859bb
    • Wanpeng Li's avatar
      Revert "locking/pvqspinlock: Don't wait if vCPU is preempted" · e409b81d
      Wanpeng Li authored
      commit 89340d09 upstream.
      
      This patch reverts commit 75437bb3 (locking/pvqspinlock: Don't
      wait if vCPU is preempted).  A large performance regression was caused
      by this commit.  on over-subscription scenarios.
      
      The test was run on a Xeon Skylake box, 2 sockets, 40 cores, 80 threads,
      with three VMs of 80 vCPUs each.  The score of ebizzy -M is reduced from
      13000-14000 records/s to 1700-1800 records/s:
      
                Host                Guest                score
      
      vanilla w/o kvm optimizations     upstream    1700-1800 records/s
      vanilla w/o kvm optimizations     revert      13000-14000 records/s
      vanilla w/ kvm optimizations      upstream    4500-5000 records/s
      vanilla w/ kvm optimizations      revert      14000-15500 records/s
      
      Exit from aggressive wait-early mechanism can result in premature yield
      and extra scheduling latency.
      
      Actually, only 6% of wait_early events are caused by vcpu_is_preempted()
      being true.  However, when one vCPU voluntarily releases its vCPU, all
      the subsequently waiters in the queue will do the same and the cascading
      effect leads to bad performance.
      
      kvm optimizations:
      [1] commit d73eb57b (KVM: Boost vCPUs that are delivering interrupts)
      [2] commit 266e85a5 (KVM: X86: Boost queue head vCPU to mitigate lock waiter preemption)
      
      Tested-by: loobinliu@tencent.com
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Waiman Long <longman@redhat.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: loobinliu@tencent.com
      Cc: stable@vger.kernel.org
      Fixes: 75437bb3 (locking/pvqspinlock: Don't wait if vCPU is preempted)
      Signed-off-by: default avatarWanpeng Li <wanpengli@tencent.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e409b81d
    • Russell King's avatar
      mmc: sdhci-of-esdhc: set DMA snooping based on DMA coherence · 7ed2867c
      Russell King authored
      commit 121bd08b upstream.
      
      We must not unconditionally set the DMA snoop bit; if the DMA API is
      assuming that the device is not DMA coherent, and the device snoops the
      CPU caches, the device can see stale cache lines brought in by
      speculative prefetch.
      
      This leads to the device seeing stale data, potentially resulting in
      corrupted data transfers.  Commonly, this results in a descriptor fetch
      error such as:
      
      mmc0: ADMA error
      mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
      mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00002202
      mmc0: sdhci: Blk size:  0x00000008 | Blk cnt:  0x00000001
      mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000013
      mmc0: sdhci: Present:   0x01f50008 | Host ctl: 0x00000038
      mmc0: sdhci: Power:     0x00000003 | Blk gap:  0x00000000
      mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x000040d8
      mmc0: sdhci: Timeout:   0x00000003 | Int stat: 0x00000001
      mmc0: sdhci: Int enab:  0x037f108f | Sig enab: 0x037f108b
      mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00002202
      mmc0: sdhci: Caps:      0x35fa0000 | Caps_1:   0x0000af00
      mmc0: sdhci: Cmd:       0x0000333a | Max curr: 0x00000000
      mmc0: sdhci: Resp[0]:   0x00000920 | Resp[1]:  0x001d8a33
      mmc0: sdhci: Resp[2]:   0x325b5900 | Resp[3]:  0x3f400e00
      mmc0: sdhci: Host ctl2: 0x00000000
      mmc0: sdhci: ADMA Err:  0x00000009 | ADMA Ptr: 0x000000236d43820c
      mmc0: sdhci: ============================================
      mmc0: error -5 whilst initialising SD card
      
      but can lead to other errors, and potentially direct the SDHCI
      controller to read/write data to other memory locations (e.g. if a valid
      descriptor is visible to the device in a stale cache line.)
      
      Fix this by ensuring that the DMA snoop bit corresponds with the
      behaviour of the DMA API.  Since the driver currently only supports DT,
      use of_dma_is_coherent().  Note that device_get_dma_attr() can not be
      used as that risks re-introducing this bug if/when the driver is
      converted to ACPI.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7ed2867c
    • Russell King's avatar
      mmc: sdhci: improve ADMA error reporting · 4509a19d
      Russell King authored
      commit d1c536e3 upstream.
      
      ADMA errors are potentially data corrupting events; although we print
      the register state, we do not usefully print the ADMA descriptors.
      Worse than that, we print them by referencing their virtual address
      which is meaningless when the register state gives us the DMA address
      of the failing descriptor.
      
      Print the ADMA descriptors giving their DMA addresses rather than their
      virtual addresses, and print them using SDHCI_DUMP() rather than DBG().
      
      We also do not show the correct value of the interrupt status register;
      the register dump shows the current value, after we have cleared the
      pending interrupts we are going to service.  What is more useful is to
      print the interrupts that _were_ pending at the time the ADMA error was
      encountered.  Fix that too.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4509a19d
    • Xiaolin Zhang's avatar
      drm/i915/gvt: update vgpu workload head pointer correctly · 873f49d6
      Xiaolin Zhang authored
      commit 0a3242bd upstream.
      
      when creating a vGPU workload, the guest context head pointer should
      be updated correctly by comparing with the exsiting workload in the
      guest worklod queue including the current running context.
      
      in some situation, there is a running context A and then received 2 new
      vGPU workload context B and A. in the new workload context A, it's head
      pointer should be updated with the running context A's tail.
      
      v2: walk through guest workload list in backward way.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarXiaolin Zhang <xiaolin.zhang@intel.com>
      Reviewed-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      873f49d6
    • Lyude Paul's avatar
      drm/nouveau/kms/nv50-: Don't create MSTMs for eDP connectors · 198bc704
      Lyude Paul authored
      commit 698c1aa9 upstream.
      
      On the ThinkPad P71, we have one eDP connector exposed along with 5 DP
      connectors, resulting in a total of 11 TMDS encoders. Since the GPU on
      this system is also capable of MST, we create an additional 4 fake MST
      encoders for each DP port. Unfortunately, we also do this for the eDP
      port as well, resulting in:
      
        1 eDP port: +1 TMDS encoder
                    +4 DPMST encoders
        5 DP ports: +2 TMDS encoders
                    +4 DPMST encoders
      	      *5 ports
      	      == 35 encoders
      
      Which breaks things, since DRM has a hard coded limit of 32 encoders.
      So, fix this by not creating MSTMs for any eDP connectors. This brings
      us down to 31 encoders, although we can do better.
      
      This fixes driver probing for nouveau on the ThinkPad P71.
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      198bc704
    • Sean Paul's avatar
      drm/msm/dsi: Fix return value check for clk_get_parent · 7a85c867
      Sean Paul authored
      commit 5fb9b797 upstream.
      
      clk_get_parent returns an error pointer upon failure, not NULL. So the
      checks as they exist won't catch a failure. This patch changes the
      checks and the return values to properly handle an error pointer.
      
      Fixes: c4d8cfe5 ("drm/msm/dsi: add implementation for helper functions")
      Cc: Sibi Sankar <sibis@codeaurora.org>
      Cc: Sean Paul <seanpaul@chromium.org>
      Cc: Rob Clark <robdclark@chromium.org>
      Cc: <stable@vger.kernel.org> # v4.19+
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarRob Clark <robdclark@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7a85c867
    • Tomi Valkeinen's avatar
      drm/omap: fix max fclk divider for omap36xx · 0e45633f
      Tomi Valkeinen authored
      commit e2c4ed14 upstream.
      
      The OMAP36xx and AM/DM37x TRMs say that the maximum divider for DSS fclk
      (in CM_CLKSEL_DSS) is 32. Experimentation shows that this is not
      correct, and using divider of 32 breaks DSS with a flood or underflows
      and sync losts. Dividers up to 31 seem to work fine.
      
      There is another patch to the DT files to limit the divider correctly,
      but as the DSS driver also needs to know the maximum divider to be able
      to iteratively find good rates, we also need to do the fix in the DSS
      driver.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Adam Ford <aford173@gmail.com>
      Cc: stable@vger.kernel.org
      Link: https://patchwork.freedesktop.org/patch/msgid/20191002122542.8449-1-tomi.valkeinen@ti.comTested-by: default avatarAdam Ford <aford173@gmail.com>
      Reviewed-by: default avatarJyri Sarha <jsarha@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0e45633f
    • Srikar Dronamraju's avatar
      perf stat: Fix a segmentation fault when using repeat forever · 90ac4028
      Srikar Dronamraju authored
      commit 443f2d5b upstream.
      
      Observe a segmentation fault when 'perf stat' is asked to repeat forever
      with the interval option.
      
      Without fix:
      
        # perf stat -r 0 -I 5000 -e cycles -a sleep 10
        #           time             counts unit events
             5.000211692  3,13,89,82,34,157      cycles
            10.000380119  1,53,98,52,22,294      cycles
            10.040467280       17,16,79,265      cycles
        Segmentation fault
      
      This problem was only observed when we use forever option aka -r 0 and
      works with limited repeats. Calling print_counter with ts being set to
      NULL, is not a correct option when interval is set. Hence avoid
      print_counter(NULL,..)  if interval is set.
      
      With fix:
      
        # perf stat -r 0 -I 5000 -e cycles -a sleep 10
         #           time             counts unit events
             5.019866622  3,15,14,43,08,697      cycles
            10.039865756  3,15,16,31,95,261      cycles
            10.059950628     1,26,05,47,158      cycles
             5.009902655  3,14,52,62,33,932      cycles
            10.019880228  3,14,52,22,89,154      cycles
            10.030543876       66,90,18,333      cycles
             5.009848281  3,14,51,98,25,437      cycles
            10.029854402  3,15,14,93,04,918      cycles
             5.009834177  3,14,51,95,92,316      cycles
      
      Committer notes:
      
      Did the 'git bisect' to find the cset introducing the problem to add the
      Fixes tag below, and at that time the problem reproduced as:
      
        (gdb) run stat -r0 -I500 sleep 1
        <SNIP>
        Program received signal SIGSEGV, Segmentation fault.
        print_interval (prefix=prefix@entry=0x7fffffffc8d0 "", ts=ts@entry=0x0) at builtin-stat.c:866
        866		sprintf(prefix, "%6lu.%09lu%s", ts->tv_sec, ts->tv_nsec, csv_sep);
        (gdb) bt
        #0  print_interval (prefix=prefix@entry=0x7fffffffc8d0 "", ts=ts@entry=0x0) at builtin-stat.c:866
        #1  0x000000000041860a in print_counters (ts=ts@entry=0x0, argc=argc@entry=2, argv=argv@entry=0x7fffffffd640) at builtin-stat.c:938
        #2  0x0000000000419a7f in cmd_stat (argc=2, argv=0x7fffffffd640, prefix=<optimized out>) at builtin-stat.c:1411
        #3  0x000000000045c65a in run_builtin (p=p@entry=0x6291b8 <commands+216>, argc=argc@entry=5, argv=argv@entry=0x7fffffffd640) at perf.c:370
        #4  0x000000000045c893 in handle_internal_command (argc=5, argv=0x7fffffffd640) at perf.c:429
        #5  0x000000000045c8f1 in run_argv (argcp=argcp@entry=0x7fffffffd4ac, argv=argv@entry=0x7fffffffd4a0) at perf.c:473
        #6  0x000000000045cac9 in main (argc=<optimized out>, argv=<optimized out>) at perf.c:588
        (gdb)
      
      Mostly the same as just before this patch:
      
        Program received signal SIGSEGV, Segmentation fault.
        0x00000000005874a7 in print_interval (config=0xa1f2a0 <stat_config>, evlist=0xbc9b90, prefix=0x7fffffffd1c0 "`", ts=0x0) at util/stat-display.c:964
        964		sprintf(prefix, "%6lu.%09lu%s", ts->tv_sec, ts->tv_nsec, config->csv_sep);
        (gdb) bt
        #0  0x00000000005874a7 in print_interval (config=0xa1f2a0 <stat_config>, evlist=0xbc9b90, prefix=0x7fffffffd1c0 "`", ts=0x0) at util/stat-display.c:964
        #1  0x0000000000588047 in perf_evlist__print_counters (evlist=0xbc9b90, config=0xa1f2a0 <stat_config>, _target=0xa1f0c0 <target>, ts=0x0, argc=2, argv=0x7fffffffd670)
            at util/stat-display.c:1172
        #2  0x000000000045390f in print_counters (ts=0x0, argc=2, argv=0x7fffffffd670) at builtin-stat.c:656
        #3  0x0000000000456bb5 in cmd_stat (argc=2, argv=0x7fffffffd670) at builtin-stat.c:1960
        #4  0x00000000004dd2e0 in run_builtin (p=0xa30e00 <commands+288>, argc=5, argv=0x7fffffffd670) at perf.c:310
        #5  0x00000000004dd54d in handle_internal_command (argc=5, argv=0x7fffffffd670) at perf.c:362
        #6  0x00000000004dd694 in run_argv (argcp=0x7fffffffd4cc, argv=0x7fffffffd4c0) at perf.c:406
        #7  0x00000000004dda11 in main (argc=5, argv=0x7fffffffd670) at perf.c:531
        (gdb)
      
      Fixes: d4f63a47 ("perf stat: Introduce print_counters function")
      Signed-off-by: default avatarSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Acked-by: default avatarJiri Olsa <jolsa@kernel.org>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Tested-by: default avatarRavi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org # v4.2+
      Link: http://lore.kernel.org/lkml/20190904094738.9558-3-srikar@linux.vnet.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      90ac4028
    • Rasmus Villemoes's avatar
      watchdog: imx2_wdt: fix min() calculation in imx2_wdt_set_timeout · 22f28afd
      Rasmus Villemoes authored
      commit 144783a8 upstream.
      
      Converting from ms to s requires dividing by 1000, not multiplying. So
      this is currently taking the smaller of new_timeout and 1.28e8,
      i.e. effectively new_timeout.
      
      The driver knows what it set max_hw_heartbeat_ms to, so use that
      value instead of doing a division at run-time.
      
      FWIW, this can easily be tested by booting into a busybox shell and
      doing "watchdog -t 5 -T 130 /dev/watchdog" - without this patch, the
      watchdog fires after 130&127 == 2 seconds.
      
      Fixes: b07e228e "watchdog: imx2_wdt: Fix set_timeout for big timeout values"
      Cc: stable@vger.kernel.org # 5.2 plus anything the above got backported to
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Link: https://lore.kernel.org/r/20190812131356.23039-1-linux@rasmusvillemoes.dkSigned-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarWim Van Sebroeck <wim@linux-watchdog.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22f28afd
    • Sumit Saxena's avatar
      PCI: Restore Resizable BAR size bits correctly for 1MB BARs · e7cf8cc7
      Sumit Saxena authored
      commit d2182b2d upstream.
      
      In a Resizable BAR Control Register, bits 13:8 control the size of the BAR.
      The encoded values of these bits are as follows (see PCIe r5.0, sec
      7.8.6.3):
      
        Value    BAR size
           0     1 MB (2^20 bytes)
           1     2 MB (2^21 bytes)
           2     4 MB (2^22 bytes)
         ...
          43     8 EB (2^63 bytes)
      
      Previously we incorrectly set the BAR size bits for a 1 MB BAR to 0x1f
      instead of 0, so devices that support that size, e.g., new megaraid_sas and
      mpt3sas adapters, fail to initialize during resume from S3 sleep.
      
      Correctly calculate the BAR size bits for Resizable BAR control registers.
      
      Link: https://lore.kernel.org/r/20190725192552.24295-1-sumit.saxena@broadcom.com
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203939
      Fixes: d3252ace ("PCI: Restore resized BAR state on resume")
      Signed-off-by: default avatarSumit Saxena <sumit.saxena@broadcom.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Cc: stable@vger.kernel.org	# v4.19+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e7cf8cc7
    • Jon Derrick's avatar
      PCI: vmd: Fix shadow offsets to reflect spec changes · 956ce989
      Jon Derrick authored
      commit a1a30170 upstream.
      
      The shadow offset scratchpad was moved to 0x2000-0x2010. Update the
      location to get the correct shadow offset.
      
      Fixes: 6788958e ("PCI: vmd: Assign membar addresses from shadow registers")
      Signed-off-by: default avatarJon Derrick <jonathan.derrick@intel.com>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: stable@vger.kernel.org # v5.2+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      956ce989
    • Li RongQing's avatar
      timer: Read jiffies once when forwarding base clk · 06f25021
      Li RongQing authored
      commit e430d802 upstream.
      
      The timer delayed for more than 3 seconds warning was triggered during
      testing.
      
        Workqueue: events_unbound sched_tick_remote
        RIP: 0010:sched_tick_remote+0xee/0x100
        ...
        Call Trace:
         process_one_work+0x18c/0x3a0
         worker_thread+0x30/0x380
         kthread+0x113/0x130
         ret_from_fork+0x22/0x40
      
      The reason is that the code in collect_expired_timers() uses jiffies
      unprotected:
      
          if (next_event > jiffies)
              base->clk = jiffies;
      
      As the compiler is allowed to reload the value base->clk can advance
      between the check and the store and in the worst case advance farther than
      next event. That causes the timer expiry to be delayed until the wheel
      pointer wraps around.
      
      Convert the code to use READ_ONCE()
      
      Fixes: 23696838 ("timers: Optimize collect_expired_timers() for NOHZ")
      Signed-off-by: default avatarLi RongQing <lirongqing@baidu.com>
      Signed-off-by: default avatarLiang ZhiCheng <liangzhicheng@baidu.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/1568894687-14499-1-git-send-email-lirongqing@baidu.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06f25021