1. 06 Aug, 2019 20 commits
    • Arnd Bergmann's avatar
      ACPI: blacklist: fix clang warning for unused DMI table · d5568763
      Arnd Bergmann authored
      [ Upstream commit b80d6a42 ]
      
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d5568763
    • Jeff Layton's avatar
      ceph: return -ERANGE if virtual xattr value didn't fit in buffer · c47e2552
      Jeff Layton authored
      [ Upstream commit 3b421018 ]
      
      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: default avatarJeff Layton <jlayton@kernel.org>
      Reviewed-by: default avatar"Yan, Zheng" <zyan@redhat.com>
      Acked-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c47e2552
    • Andrea Parri's avatar
      ceph: fix improper use of smp_mb__before_atomic() · b39c377e
      Andrea Parri authored
      [ Upstream commit 74960773 ]
      
      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: fdd4e158 ("ceph: rework dcache readdir")
      Reported-by: default avatar"Paul E. McKenney" <paulmck@linux.ibm.com>
      Reported-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarAndrea Parri <andrea.parri@amarulasolutions.com>
      Reviewed-by: default avatar"Yan, Zheng" <zyan@redhat.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b39c377e
    • Ronnie Sahlberg's avatar
      cifs: Fix a race condition with cifs_echo_request · d29fbf67
      Ronnie Sahlberg authored
      [ Upstream commit f2caf901 ]
      
      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-remountSigned-off-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Reviewed-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d29fbf67
    • Qu Wenruo's avatar
      btrfs: qgroup: Don't hold qgroup_ioctl_lock in btrfs_qgroup_inherit() · f96c70fa
      Qu Wenruo authored
      [ Upstream commit e88439de ]
      
      [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: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f96c70fa
    • David Sterba's avatar
      btrfs: fix minimum number of chunk errors for DUP · d9245dab
      David Sterba authored
      [ Upstream commit 0ee5f8ae ]
      
      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.
      
      d20983b4 Btrfs: fix writing data into the seed filesystem
        - factor code to a helper
      
      de11cc12 Btrfs: don't pre-allocate btrfs bio
        - unrelated change, DUP still in the list with max errors 1
      
      a236aed1 Btrfs: Deal with failed writes in mirrored configurations
        - introduced the max errors, leaves DUP and RAID1 in the same group
      Reviewed-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d9245dab
    • Chunyan Zhang's avatar
      clk: sprd: Add check for return value of sprd_clk_regmap_init() · e7fcc587
      Chunyan Zhang authored
      [ Upstream commit c974c48d ]
      
      sprd_clk_regmap_init() doesn't always return success, adding check
      for its return value should make the code more strong.
      Signed-off-by: default avatarChunyan Zhang <zhang.chunyan@linaro.org>
      Reviewed-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      [sboyd@kernel.org: Add a missing int ret]
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e7fcc587
    • Russell King's avatar
      fs/adfs: super: fix use-after-free bug · a093208b
      Russell King authored
      [ Upstream commit 5808b14a ]
      
      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: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a093208b
    • JC Kuo's avatar
      clk: tegra210: fix PLLU and PLLU_OUT1 · 85d854b4
      JC Kuo authored
      [ Upstream commit 0d34dfbf ]
      
      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: e745f992 ("clk: tegra: Rework pll_u")
      Signed-off-by: default avatarJC Kuo <jckuo@nvidia.com>
      Acked-By: default avatarPeter De Schrijver <pdeschrijver@nvidia.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      85d854b4
    • Geert Uytterhoeven's avatar
      dmaengine: rcar-dmac: Reject zero-length slave DMA requests · cf0fcc7f
      Geert Uytterhoeven authored
      [ Upstream commit 78efb76a ]
      
      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: default avatarEugeniu Rosca <erosca@de.adit-jv.com>
      Analyzed-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cf0fcc7f
    • Petr Cvek's avatar
      MIPS: lantiq: Fix bitfield masking · a3524486
      Petr Cvek authored
      [ Upstream commit ba1bc0fc ]
      
      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: default avatarPetr Cvek <petrcvekcz@gmail.com>
      Signed-off-by: default avatarPaul 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: default avatarSasha Levin <sashal@kernel.org>
      a3524486
    • Jean-Philippe Brucker's avatar
      firmware/psci: psci_checker: Park kthreads before stopping them · cdee3f53
      Jean-Philippe Brucker authored
      [ Upstream commit 92e074ac ]
      
      Since commit 85f1abe0 ("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: 85f1abe0 ("kthread, sched/wait: Fix kthread_parkme() completion issue")
      Signed-off-by: default avatarJean-Philippe Brucker <jean-philippe.brucker@arm.com>
      Reviewed-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Acked-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cdee3f53
    • Prarit Bhargava's avatar
      kernel/module.c: Only return -EEXIST for modules that have finished loading · 09ec6c67
      Prarit Bhargava authored
      [ Upstream commit 6e6de3de ]
      
      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: default avatarPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: default avatarBarret 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: default avatarJessica Yu <jeyu@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      09ec6c67
    • Helen Koike's avatar
      arm64: dts: rockchip: fix isp iommu clocks and power domain · fd53e45a
      Helen Koike authored
      [ Upstream commit c432a29d ]
      
      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: default avatarHelen Koike <helen.koike@collabora.com>
      Tested-by: default avatarManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fd53e45a
    • Dmitry Osipenko's avatar
      dmaengine: tegra-apb: Error out if DMA_PREP_INTERRUPT flag is unset · d8388cbd
      Dmitry Osipenko authored
      [ Upstream commit dc161064 ]
      
      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: default avatarDmitry Osipenko <digetx@gmail.com>
      Acked-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d8388cbd
    • Cheng Jian's avatar
      ftrace: Enable trampoline when rec count returns back to one · f486088d
      Cheng Jian authored
      [ Upstream commit a124692b ]
      
      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.comSigned-off-by: default avatarCheng Jian <cj.chengjian@huawei.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f486088d
    • Douglas Anderson's avatar
      ARM: dts: rockchip: Mark that the rk3288 timer might stop in suspend · ea26b427
      Douglas Anderson authored
      [ Upstream commit 8ef1ba39 ]
      
      This is similar to commit e6186820 ("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: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ea26b427
    • Douglas Anderson's avatar
      ARM: dts: rockchip: Make rk3288-veyron-mickey's emmc work again · 22befe67
      Douglas Anderson authored
      [ Upstream commit 99fa0667 ]
      
      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: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      22befe67
    • Douglas Anderson's avatar
      ARM: dts: rockchip: Make rk3288-veyron-minnie run at hs200 · 8c5a33d3
      Douglas Anderson authored
      [ Upstream commit 1c047902 ]
      
      As some point hs200 was failing on rk3288-veyron-minnie.  See commit
      98492678 ("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.orgSigned-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8c5a33d3
    • Russell King's avatar
      ARM: riscpc: fix DMA · 3c1d1bad
      Russell King authored
      [ Upstream commit ffd9a1ba ]
      
      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: fa4e9989 ("[ARM] dma: RiscPC: don't modify DMA SG entries")
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3c1d1bad
  2. 04 Aug, 2019 20 commits