1. 09 6月, 2019 40 次提交
    • S
      x86/ftrace: Do not call function graph from dynamic trampolines · 6fa953c9
      Steven Rostedt (VMware) 提交于
      [ Upstream commit d2a68c4effd821f0871d20368f76b609349c8a3b ]
      
      Since commit 79922b80 ("ftrace: Optimize function graph to be
      called directly"), dynamic trampolines should not be calling the
      function graph tracer at the end. If they do, it could cause the function
      graph tracer to trace functions that it filtered out.
      
      Right now it does not cause a problem because there's a test to check if
      the function graph tracer is attached to the same function as the
      function tracer, which for now is true. But the function graph tracer is
      undergoing changes that can make this no longer true which will cause
      the function graph tracer to trace other functions.
      
       For example:
      
       # cd /sys/kernel/tracing/
       # echo do_IRQ > set_ftrace_filter
       # mkdir instances/foo
       # echo ip_rcv > instances/foo/set_ftrace_filter
       # echo function_graph > current_tracer
       # echo function > instances/foo/current_tracer
      
      Would cause the function graph tracer to trace both do_IRQ and ip_rcv,
      if the current tests change.
      
      As the current tests prevent this from being a problem, this code does
      not need to be backported. But it does make the code cleaner.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6fa953c9
    • T
      binder: fix race between munmap() and direct reclaim · 9d57cfd4
      Todd Kjos 提交于
      commit 5cec2d2e5839f9c0fec319c523a911e0a7fd299f upstream.
      
      An munmap() on a binder device causes binder_vma_close() to be called
      which clears the alloc->vma pointer.
      
      If direct reclaim causes binder_alloc_free_page() to be called, there
      is a race where alloc->vma is read into a local vma pointer and then
      used later after the mm->mmap_sem is acquired. This can result in
      calling zap_page_range() with an invalid vma which manifests as a
      use-after-free in zap_page_range().
      
      The fix is to check alloc->vma after acquiring the mmap_sem (which we
      were acquiring anyway) and skip zap_page_range() if it has changed
      to NULL.
      
      Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: NTodd Kjos <tkjos@google.com>
      Reviewed-by: NJoel Fernandes (Google) <joel@joelfernandes.org>
      Cc: stable <stable@vger.kernel.org> # 4.19
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d57cfd4
    • T
      Revert "binder: fix handling of misaligned binder object" · 137c838f
      Todd Kjos 提交于
      This reverts commit 6bf7d3c5.
      
      The commit message is for a different patch. Reverting and then adding
      the same patch back with the correct commit message.
      Reported-by: NBen Hutchings <ben.hutchings@codethink.co.uk>
      Cc: stable <stable@vger.kernel.org> # 4.19
      Signed-off-by: NTodd Kjos <tkjos@google.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      137c838f
    • G
      Revert "x86/build: Move _etext to actual end of .text" · 385dab29
      Greg Kroah-Hartman 提交于
      This reverts commit 392bef709659abea614abfe53cf228e7a59876a4.
      
      It seems to cause lots of problems when using the gold linker, and no
      one really needs this at the moment, so just revert it from the stable
      trees.
      
      Cc: Sami Tolvanen <samitolvanen@google.com>
      Reported-by: NKees Cook <keescook@chromium.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Reported-by: NAlec Ari <neotheuser@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      385dab29
    • M
      include/linux/module.h: copy __init/__exit attrs to init/cleanup_module · 9468870f
      Miguel Ojeda 提交于
      commit a6e60d84989fa0e91db7f236eda40453b0e44afa upstream.
      
      The upcoming GCC 9 release extends the -Wmissing-attributes warnings
      (enabled by -Wall) to C and aliases: it warns when particular function
      attributes are missing in the aliases but not in their target.
      
      In particular, it triggers for all the init/cleanup_module
      aliases in the kernel (defined by the module_init/exit macros),
      ending up being very noisy.
      
      These aliases point to the __init/__exit functions of a module,
      which are defined as __cold (among other attributes). However,
      the aliases themselves do not have the __cold attribute.
      
      Since the compiler behaves differently when compiling a __cold
      function as well as when compiling paths leading to calls
      to __cold functions, the warning is trying to point out
      the possibly-forgotten attribute in the alias.
      
      In order to keep the warning enabled, we decided to silence
      this case. Ideally, we would mark the aliases directly
      as __init/__exit. However, there are currently around 132 modules
      in the kernel which are missing __init/__exit in their init/cleanup
      functions (either because they are missing, or for other reasons,
      e.g. the functions being called from somewhere else); and
      a section mismatch is a hard error.
      
      A conservative alternative was to mark the aliases as __cold only.
      However, since we would like to eventually enforce __init/__exit
      to be always marked,  we chose to use the new __copy function
      attribute (introduced by GCC 9 as well to deal with this).
      With it, we copy the attributes used by the target functions
      into the aliases. This way, functions that were not marked
      as __init/__exit won't have their aliases marked either,
      and therefore there won't be a section mismatch.
      
      Note that the warning would go away marking either the extern
      declaration, the definition, or both. However, we only mark
      the definition of the alias, since we do not want callers
      (which only see the declaration) to be compiled as if the function
      was __cold (and therefore the paths leading to those calls
      would be assumed to be unlikely).
      
      Link: https://lore.kernel.org/lkml/20190123173707.GA16603@gmail.com/
      Link: https://lore.kernel.org/lkml/20190206175627.GA20399@gmail.com/Suggested-by: NMartin Sebor <msebor@gcc.gnu.org>
      Acked-by: NJessica Yu <jeyu@kernel.org>
      Signed-off-by: NMiguel Ojeda <miguel.ojeda.sandonis@gmail.com>
      Signed-off-by: NStefan Agner <stefan@agner.ch>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9468870f
    • M
      Compiler Attributes: add support for __copy (gcc >= 9) · 2a0f719d
      Miguel Ojeda 提交于
      commit c0d9782f5b6d7157635ae2fd782a4b27d55a6013 upstream.
      
      From the GCC manual:
      
        copy
        copy(function)
      
          The copy attribute applies the set of attributes with which function
          has been declared to the declaration of the function to which
          the attribute is applied. The attribute is designed for libraries
          that define aliases or function resolvers that are expected
          to specify the same set of attributes as their targets. The copy
          attribute can be used with functions, variables, or types. However,
          the kind of symbol to which the attribute is applied (either
          function or variable) must match the kind of symbol to which
          the argument refers. The copy attribute copies only syntactic and
          semantic attributes but not attributes that affect a symbol’s
          linkage or visibility such as alias, visibility, or weak.
          The deprecated attribute is also not copied.
      
        https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
      
      The upcoming GCC 9 release extends the -Wmissing-attributes warnings
      (enabled by -Wall) to C and aliases: it warns when particular function
      attributes are missing in the aliases but not in their target, e.g.:
      
          void __cold f(void) {}
          void __alias("f") g(void);
      
      diagnoses:
      
          warning: 'g' specifies less restrictive attribute than
          its target 'f': 'cold' [-Wmissing-attributes]
      
      Using __copy(f) we can copy the __cold attribute from f to g:
      
          void __cold f(void) {}
          void __copy(f) __alias("f") g(void);
      
      This attribute is most useful to deal with situations where an alias
      is declared but we don't know the exact attributes the target has.
      
      For instance, in the kernel, the widely used module_init/exit macros
      define the init/cleanup_module aliases, but those cannot be marked
      always as __init/__exit since some modules do not have their
      functions marked as such.
      Suggested-by: NMartin Sebor <msebor@gcc.gnu.org>
      Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: NMiguel Ojeda <miguel.ojeda.sandonis@gmail.com>
      Signed-off-by: NStefan Agner <stefan@agner.ch>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a0f719d
    • D
      drm/lease: Make sure implicit planes are leased · 390a0fd3
      Daniel Vetter 提交于
      commit 204f640da6914844b3270b41b29c84f6e3b74083 upstream.
      
      If userspace doesn't enable universal planes, then we automatically
      add the primary and cursor planes. But for universal userspace there's
      no such check (and maybe we only want to give the lessee one plane,
      maybe not even the primary one), hence we need to check for the
      implied plane.
      
      v2: don't forget setcrtc ioctl.
      
      v3: Still allow disabling of the crtc in SETCRTC.
      
      Cc: stable@vger.kernel.org
      Cc: Keith Packard <keithp@keithp.com>
      Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190228144910.26488-6-daniel.vetter@ffwll.chSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      390a0fd3
    • V
      drm/rockchip: shutdown drm subsystem on shutdown · 699f0e9d
      Vicente Bergas 提交于
      commit b8f9d7f37b6af829c34c49d1a4f73ce6ed58e403 upstream.
      
      As explained by Robin Murphy:
      > the IOMMU shutdown disables paging, so if the VOP is still
      > scanning out then that will result in whatever IOVAs it was using now going
      > straight out onto the bus as physical addresses.
      
      We had a more radical approach before in commit
      7f3ef5dedb14 ("drm/rockchip: Allow driver to be shutdown on reboot/kexec")
      but that resulted in new warnings and oopses on shutdown on rk3399
      chromeos devices.
      
      So second try is resurrecting Vicentes shutdown change which should
      achieve the same result but in a less drastic way.
      
      Fixes: 63238173b2fa ("Revert "drm/rockchip: Allow driver to be shutdown on reboot/kexec"")
      Cc: Jeffy Chen <jeffy.chen@rock-chips.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Brian Norris <briannorris@chromium.org>
      Cc: Doug Anderson <dianders@chromium.org>
      Cc: stable@vger.kernel.org
      Suggested-by: NJeffyChen <jeffy.chen@rock-chips.com>
      Suggested-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NVicente Bergas <vicencb@gmail.com>
      [adapted commit message to explain the history]
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Tested-by: NBrian Norris <briannorris@chromium.org>
      Tested-by: NDouglas Anderson <dianders@chromium.org>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190402113753.10118-1-heiko@sntech.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      699f0e9d
    • J
      drm/sun4i: Fix sun8i HDMI PHY configuration for > 148.5 MHz · 1ca81150
      Jernej Skrabec 提交于
      commit 831adffb3b7b8df4c8e20b7b00843129fb87a166 upstream.
      
      Vendor provided documentation says that EMP bits should be set to 3 for
      pixel clocks greater than 148.5 MHz.
      
      Fix that.
      
      Cc: stable@vger.kernel.org # 4.17+
      Fixes: 4f86e817 ("drm/sun4i: Add support for H3 HDMI PHY variant")
      Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net>
      Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190514204337.11068-3-jernej.skrabec@siol.netSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ca81150
    • J
      drm/sun4i: Fix sun8i HDMI PHY clock initialization · 1f137220
      Jernej Skrabec 提交于
      commit 8a943c6021ba8b95a36c842327e468df1fddd4a7 upstream.
      
      Current code initializes HDMI PHY clock driver before reset line is
      deasserted and clocks enabled. Because of that, initial readout of
      clock divider is incorrect (0 instead of 2). This causes any clock
      rate with divider 1 (register value 0) to be set incorrectly.
      
      Fix this by moving initialization of HDMI PHY clock driver after reset
      line is deasserted and clocks enabled.
      
      Cc: stable@vger.kernel.org # 4.17+
      Fixes: 4f86e817 ("drm/sun4i: Add support for H3 HDMI PHY variant")
      Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net>
      Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190514204337.11068-2-jernej.skrabec@siol.netSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f137220
    • T
      drm/vmwgfx: Don't send drm sysfs hotplug events on initial master set · 3a20515c
      Thomas Hellstrom 提交于
      commit 63cb44441826e842b7285575b96db631cc9f2505 upstream.
      
      This may confuse user-space clients like plymouth that opens a drm
      file descriptor as a result of a hotplug event and then generates a
      new event...
      
      Cc: <stable@vger.kernel.org>
      Fixes: 5ea17348 ("drm/vmwgfx: Send a hotplug event at master_set")
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: NDeepak Rawat <drawat@vmware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a20515c
    • D
      drm/tegra: gem: Fix CPU-cache maintenance for BO's allocated using get_pages() · 1715a463
      Dmitry Osipenko 提交于
      commit 61b51fb51c01a519a249d28ec55c6513a13be5a3 upstream.
      
      The allocated pages need to be invalidated in CPU caches. On ARM32 the
      DMA_BIDIRECTIONAL flag only ensures that data is written-back to DRAM and
      the data stays in CPU cache lines. While the DMA_FROM_DEVICE flag ensures
      that the corresponding CPU cache lines are getting invalidated and nothing
      more, that's exactly what is needed for a newly allocated pages.
      
      This fixes randomly failing rendercheck tests on Tegra30 using the
      Opentegra driver for tests that use small-sized pixmaps (10x10 and less,
      i.e. 1-2 memory pages) because apparently CPU reads out stale data from
      caches and/or that data is getting evicted to DRAM at the time of HW job
      execution.
      
      Fixes: bd43c9f0 ("drm/tegra: gem: Map pages via the DMA API")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1715a463
    • K
      gcc-plugins: Fix build failures under Darwin host · 132137d1
      Kees Cook 提交于
      commit 7210e060155b9cf557fb13128353c3e494fa5ed3 upstream.
      
      The gcc-common.h file did not take into account certain macros that
      might have already been defined in the build environment. This updates
      the header to avoid redefining the macros, as seen on a Darwin host
      using gcc 4.9.2:
      
       HOSTCXX -fPIC scripts/gcc-plugins/arm_ssp_per_task_plugin.o - due to: scripts/gcc-plugins/gcc-common.h
      In file included from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:0:
      scripts/gcc-plugins/gcc-common.h:153:0: warning: "__unused" redefined
      ^
      In file included from /usr/include/stdio.h:64:0,
                      from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/system.h:40,
                      from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/gcc-plugin.h:28,
                      from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/plugin.h:23,
                      from scripts/gcc-plugins/gcc-common.h:9,
                      from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:
      /usr/include/sys/cdefs.h:161:0: note: this is the location of the previous definition
      ^
      Reported-and-tested-by: N"H. Nikolaus Schaller" <hns@goldelico.com>
      Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries")
      Cc: stable@vger.kernel.org
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      132137d1
    • B
      Revert "lockd: Show pid of lockd for remote locks" · 87304193
      Benjamin Coddington 提交于
      commit 141731d15d6eb2fd9aaefbf9b935ce86ae243074 upstream.
      
      This reverts most of commit b8eee0e90f97 ("lockd: Show pid of lockd for
      remote locks"), which caused remote locks to not be differentiated between
      remote processes for NLM.
      
      We retain the fixup for setting the client's fl_pid to a negative value.
      
      Fixes: b8eee0e90f97 ("lockd: Show pid of lockd for remote locks")
      Cc: stable@vger.kernel.org
      Signed-off-by: NBenjamin Coddington <bcodding@redhat.com>
      Reviewed-by: NXueWei Zhang <xueweiz@google.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      87304193
    • R
      CIFS: cifs_read_allocate_pages: don't iterate through whole page array on ENOMEM · 297a2510
      Roberto Bergantinos Corpas 提交于
      commit 31fad7d41e73731f05b8053d17078638cf850fa6 upstream.
      
       In cifs_read_allocate_pages, in case of ENOMEM, we go through
      whole rdata->pages array but we have failed the allocation before
      nr_pages, therefore we may end up calling put_page with NULL
      pointer, causing oops
      Signed-off-by: NRoberto Bergantinos Corpas <rbergant@redhat.com>
      Acked-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      297a2510
    • C
      cifs: fix memory leak of pneg_inbuf on -EOPNOTSUPP ioctl case · 32d57c0c
      Colin Ian King 提交于
      commit 210782038b54ec8e9059a3c12d6f6ae173efa3a9 upstream.
      
      Currently in the case where SMB2_ioctl returns the -EOPNOTSUPP error
      there is a memory leak of pneg_inbuf. Fix this by returning via
      the out_free_inbuf exit path that will perform the relevant kfree.
      
      Addresses-Coverity: ("Resource leak")
      Fixes: 969ae8e8d4ee ("cifs: Accept validate negotiate if server return NT_STATUS_NOT_SUPPORTED")
      CC: Stable <stable@vger.kernel.org> # v5.1+
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      32d57c0c
    • T
      staging: wlan-ng: fix adapter initialization failure · f6a39f87
      Tim Collier 提交于
      commit a67fedd788182764dc8ed59037c604b7e60349f1 upstream.
      
      Commit e895f00a ("Staging: wlan-ng: hfa384x_usb.c Fixed too long
      code line warnings.") moved the retrieval of the transfer buffer from
      the URB from the top of function hfa384x_usbin_callback to a point
      after reposting of the URB via a call to submit_rx_urb. The reposting
      of the URB allocates a new transfer buffer so the new buffer is
      retrieved instead of the buffer containing the response passed into
      the callback. This results in failure to initialize the adapter with
      an error reported in the system log (something like "CTLX[1] error:
      state(Request failed)").
      
      This change moves the retrieval to just before the point where the URB
      is reposted so that the correct transfer buffer is retrieved and
      initialization of the device succeeds.
      Signed-off-by: NTim Collier <osdevtc@gmail.com>
      Fixes: e895f00a ("Staging: wlan-ng: hfa384x_usb.c Fixed too long code line warnings.")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f6a39f87
    • D
      staging: vc04_services: prevent integer overflow in create_pagelist() · 27a4b6c8
      Dan Carpenter 提交于
      commit ca641bae6da977d638458e78cd1487b6160a2718 upstream.
      
      The create_pagelist() "count" parameter comes from the user in
      vchiq_ioctl() and it could overflow.  If you look at how create_page()
      is called in vchiq_prepare_bulk_data(), then the "size" variable is an
      int so it doesn't make sense to allow negatives or larger than INT_MAX.
      
      I don't know this code terribly well, but I believe that typical values
      of "count" are typically quite low and I don't think this check will
      affect normal valid uses at all.
      
      The "pagelist_size" calculation can also overflow on 32 bit systems, but
      not on 64 bit systems.  I have added an integer overflow check for that
      as well.
      
      The Raspberry PI doesn't offer the same level of memory protection that
      x86 does so these sorts of bugs are probably not super critical to fix.
      
      Fixes: 71bad7f0 ("staging: add bcm2708 vchiq driver")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      27a4b6c8
    • G
      serial: sh-sci: disable DMA for uart_console · 3078e80b
      George G. Davis 提交于
      commit 099506cbbc79c0bd52b19cb6b930f256dabc3950 upstream.
      
      As noted in commit 84b40e3b ("serial: 8250: omap: Disable DMA for
      console UART"), UART console lines use low-level PIO only access functions
      which will conflict with use of the line when DMA is enabled, e.g. when
      the console line is also used for systemd messages. So disable DMA
      support for UART console lines.
      Reported-by: NMichael Rodin <mrodin@de.adit-jv.com>
      Link: https://patchwork.kernel.org/patch/10929511/Tested-by: NEugeniu Rosca <erosca@de.adit-jv.com>
      Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
      Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Cc: stable@vger.kernel.org
      Signed-off-by: NGeorge G. Davis <george_davis@mentor.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3078e80b
    • G
      vt/fbcon: deinitialize resources in visual_init() after failed memory allocation · ff818b44
      Grzegorz Halat 提交于
      commit a1ad1cc9704f64c169261a76e1aee1cf1ae51832 upstream.
      
      After memory allocation failure vc_allocate() doesn't clean up data
      which has been initialized in visual_init(). In case of fbcon this
      leads to divide-by-0 in fbcon_init() on next open of the same tty.
      
      memory allocation in vc_allocate() may fail here:
      1097:     vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_KERNEL);
      
      on next open() fbcon_init() skips vc_font.data initialization:
      1088:     if (!p->fontdata) {
      
      division by zero in fbcon_init() happens here:
      1149:     new_cols /= vc->vc_font.width;
      
      Additional check is needed in fbcon_deinit() to prevent
      usage of uninitialized vc_screenbuf:
      
      1251:        if (vc->vc_hi_font_mask && vc->vc_screenbuf)
      1252:                set_vc_hi_font(vc, false);
      
      Crash:
      
       #6 [ffffc90001eafa60] divide_error at ffffffff81a00be4
          [exception RIP: fbcon_init+463]
          RIP: ffffffff814b860f  RSP: ffffc90001eafb18  RFLAGS: 00010246
      ...
       #7 [ffffc90001eafb60] visual_init at ffffffff8154c36e
       #8 [ffffc90001eafb80] vc_allocate at ffffffff8154f53c
       #9 [ffffc90001eafbc8] con_install at ffffffff8154f624
      ...
      Signed-off-by: NGrzegorz Halat <ghalat@redhat.com>
      Reviewed-by: NOleksandr Natalenko <oleksandr@redhat.com>
      Acked-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ff818b44
    • R
      evm: check hash algorithm passed to init_desc() · 6e322a9e
      Roberto Sassu 提交于
      commit 221be106d75c1b511973301542f47d6000d0b63e upstream.
      
      This patch prevents memory access beyond the evm_tfm array by checking the
      validity of the index (hash algorithm) passed to init_desc(). The hash
      algorithm can be arbitrarily set if the security.ima xattr type is not
      EVM_XATTR_HMAC.
      
      Fixes: 5feeb611 ("evm: Allow non-SHA1 digital signatures")
      Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e322a9e
    • R
      ima: show rules with IMA_INMASK correctly · f85b87a9
      Roberto Sassu 提交于
      commit 8cdc23a3d9ec0944000ad43bad588e36afdc38cd upstream.
      
      Show the '^' character when a policy rule has flag IMA_INMASK.
      
      Fixes: 80eae209 ("IMA: allow reading back the current IMA policy")
      Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f85b87a9
    • J
      doc: Cope with Sphinx logging deprecations · 21158982
      Jonathan Corbet 提交于
      commit 096ea522e84ea68f8e6c41e5e7294731a81e29bc upstream.
      
      Recent versions of sphinx will emit messages like:
      
        Documentation/sphinx/kerneldoc.py:103:
           RemovedInSphinx20Warning: app.warning() is now deprecated.
           Use sphinx.util.logging instead.
      
      Switch to sphinx.util.logging to make this unsightly message go away.
      Alas, that interface was only added in version 1.6, so we have to add a
      version check to keep things working with older sphinxes.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      21158982
    • J
      doc: Cope with the deprecation of AutoReporter · c0742228
      Jonathan Corbet 提交于
      commit 2404dad1f67f8917e30fc22a85e0dbcc85b99955 upstream.
      
      AutoReporter is going away; recent versions of sphinx emit a warning like:
      
        Documentation/sphinx/kerneldoc.py:125:
            RemovedInSphinx20Warning: AutodocReporter is now deprecated.
            Use sphinx.util.docutils.switch_source_input() instead.
      
      Make the switch.  But switch_source_input() only showed up in 1.7, so we
      have to do ugly version checks to keep things working in older versions.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0742228
    • J
      docs: Fix conf.py for Sphinx 2.0 · 301b18ed
      Jonathan Corbet 提交于
      commit 3bc8088464712fdcb078eefb68837ccfcc413c88 upstream.
      
      Our version check in Documentation/conf.py never envisioned a world where
      Sphinx moved beyond 1.x.  Now that the unthinkable has happened, fix our
      version check to handle higher version numbers correctly.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      301b18ed
    • C
      arm64: Fix the arm64_personality() syscall wrapper redirection · 87195343
      Catalin Marinas 提交于
      commit 00377277166bac6939d8f72b429301369acaf2d8 upstream.
      
      Following commit 4378a7d4 ("arm64: implement syscall wrappers"), the
      syscall function names gained the '__arm64_' prefix. Ensure that we
      have the correct #define for redirecting a default syscall through a
      wrapper.
      
      Fixes: 4378a7d4 ("arm64: implement syscall wrappers")
      Cc: <stable@vger.kernel.org> # 4.19.x-
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      87195343
    • Z
      kernel/signal.c: trace_signal_deliver when signal_group_exit · 6f8d2627
      Zhenliang Wei 提交于
      commit 98af37d624ed8c83f1953b1b6b2f6866011fc064 upstream.
      
      In the fixes commit, removing SIGKILL from each thread signal mask and
      executing "goto fatal" directly will skip the call to
      "trace_signal_deliver".  At this point, the delivery tracking of the
      SIGKILL signal will be inaccurate.
      
      Therefore, we need to add trace_signal_deliver before "goto fatal" after
      executing sigdelset.
      
      Note: SEND_SIG_NOINFO matches the fact that SIGKILL doesn't have any info.
      
      Link: http://lkml.kernel.org/r/20190425025812.91424-1-weizhenliang@huawei.com
      Fixes: cf43a757fd4944 ("signal: Restore the stop PTRACE_EVENT_EXIT")
      Signed-off-by: NZhenliang Wei <weizhenliang@huawei.com>
      Reviewed-by: NChristian Brauner <christian@brauner.io>
      Reviewed-by: NOleg Nesterov <oleg@redhat.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Ivan Delalande <colona@arista.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Deepa Dinamani <deepa.kernel@gmail.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f8d2627
    • J
      memcg: make it work on sparse non-0-node systems · 8b057ad8
      Jiri Slaby 提交于
      commit 3e8589963773a5c23e2f1fe4bcad0e9a90b7f471 upstream.
      
      We have a single node system with node 0 disabled:
        Scanning NUMA topology in Northbridge 24
        Number of physical nodes 2
        Skipping disabled node 0
        Node 1 MemBase 0000000000000000 Limit 00000000fbff0000
        NODE_DATA(1) allocated [mem 0xfbfda000-0xfbfeffff]
      
      This causes crashes in memcg when system boots:
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
        #PF error: [normal kernel read fault]
      ...
        RIP: 0010:list_lru_add+0x94/0x170
      ...
        Call Trace:
         d_lru_add+0x44/0x50
         dput.part.34+0xfc/0x110
         __fput+0x108/0x230
         task_work_run+0x9f/0xc0
         exit_to_usermode_loop+0xf5/0x100
      
      It is reproducible as far as 4.12.  I did not try older kernels.  You have
      to have a new enough systemd, e.g.  241 (the reason is unknown -- was not
      investigated).  Cannot be reproduced with systemd 234.
      
      The system crashes because the size of lru array is never updated in
      memcg_update_all_list_lrus and the reads are past the zero-sized array,
      causing dereferences of random memory.
      
      The root cause are list_lru_memcg_aware checks in the list_lru code.  The
      test in list_lru_memcg_aware is broken: it assumes node 0 is always
      present, but it is not true on some systems as can be seen above.
      
      So fix this by avoiding checks on node 0.  Remember the memcg-awareness by
      a bool flag in struct list_lru.
      
      Link: http://lkml.kernel.org/r/20190522091940.3615-1-jslaby@suse.cz
      Fixes: 60d3fd32 ("list_lru: introduce per-memcg lists")
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Suggested-by: NVladimir Davydov <vdavydov.dev@gmail.com>
      Acked-by: NVladimir Davydov <vdavydov.dev@gmail.com>
      Reviewed-by: NShakeel Butt <shakeelb@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8b057ad8
    • J
      tty: max310x: Fix external crystal register setup · 4e29e2ec
      Joe Burmeister 提交于
      commit 5d24f455c182d5116dd5db8e1dc501115ecc9c2c upstream.
      
      The datasheet states:
      
        Bit 4: ClockEnSet the ClockEn bit high to enable an external clocking
      (crystal or clock generator at XIN). Set the ClockEn bit to 0 to disable
      clocking
        Bit 1: CrystalEnSet the CrystalEn bit high to enable the crystal
      oscillator. When using an external clock source at XIN, CrystalEn must
      be set low.
      
      The bit 4, MAX310X_CLKSRC_EXTCLK_BIT, should be set and was not.
      
      This was required to make the MAX3107 with an external crystal on our
      board able to send or receive data.
      Signed-off-by: NJoe Burmeister <joe.burmeister@devtank.co.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e29e2ec
    • J
      tty: serial: msm_serial: Fix XON/XOFF · a071517b
      Jorge Ramirez-Ortiz 提交于
      commit 61c0e37950b88bad590056286c1d766b1f167f4e upstream.
      
      When the tty layer requests the uart to throttle, the current code
      executing in msm_serial will trigger "Bad mode in Error Handler" and
      generate an invalid stack frame in pstore before rebooting (that is if
      pstore is indeed configured: otherwise the user shall just notice a
      reboot with no further information dumped to the console).
      
      This patch replaces the PIO byte accessor with the word accessor
      already used in PIO mode.
      
      Fixes: 68252424 ("tty: serial: msm: Support big-endian CPUs")
      Cc: stable@vger.kernel.org
      Signed-off-by: NJorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
      Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
      Reviewed-by: NStephen Boyd <swboyd@chromium.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a071517b
    • M
      i2c: synquacer: fix synquacer_i2c_doxfer() return value · bb032904
      Masahisa Kojima 提交于
      commit ff9378904d9d7a3fcb8406604e089e535e357b1d upstream.
      
      master_xfer should return the number of messages successfully
      processed.
      
      Fixes: 0d676a6c ("i2c: add support for Socionext SynQuacer I2C controller")
      Cc: <stable@vger.kernel.org> # v4.19+
      Signed-off-by: NOkamoto Satoru <okamoto.satoru@socionext.com>
      Signed-off-by: NMasahisa Kojima <masahisa.kojima@linaro.org>
      Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bb032904
    • V
      i2c: mlxcpld: Fix wrong initialization order in probe · d2d8f640
      Vadim Pasternak 提交于
      commit 13067ef73f337336e3149f5bb9f3fd05fe7f87a0 upstream.
      
      Fix wrong order in probing routine initialization - field `base_addr'
      is used before it's initialized. Move assignment of 'priv->base_addr`
      to the beginning, prior the call to mlxcpld_i2c_read_comm().
      Wrong order caused the first read of capability register to be executed
      at wrong offset 0x0 instead of 0x2000. By chance it was a "good
      garbage" at 0x0 offset.
      
      Fixes: 313ce648 ("i2c: mlxcpld: Add support for extended transaction length for i2c-mlxcpld")
      Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2d8f640
    • L
      drm/nouveau/i2c: Disable i2c bus access after ->fini() · 88ad86b8
      Lyude Paul 提交于
      commit 342406e4fbba9a174125fbfe6aeac3d64ef90f76 upstream.
      
      For a while, we've had the problem of i2c bus access not grabbing
      a runtime PM ref when it's being used in userspace by i2c-dev, resulting
      in nouveau spamming the kernel log with errors if anything attempts to
      access the i2c bus while the GPU is in runtime suspend. An example:
      
      [  130.078386] nouveau 0000:01:00.0: i2c: aux 000d: begin idle timeout ffffffff
      
      Since the GPU is in runtime suspend, the MMIO region that the i2c bus is
      on isn't accessible. On x86, the standard behavior for accessing an
      unavailable MMIO region is to just return ~0.
      
      Except, that turned out to be a lie. While computers with a clean
      concious will return ~0 in this scenario, some machines will actually
      completely hang a CPU on certian bad MMIO accesses. This was witnessed
      with someone's Lenovo ThinkPad P50, where sensors-detect attempting to
      access the i2c bus while the GPU was suspended would result in a CPU
      hang:
      
        CPU: 5 PID: 12438 Comm: sensors-detect Not tainted 5.0.0-0.rc4.git3.1.fc30.x86_64 #1
        Hardware name: LENOVO 20EQS64N17/20EQS64N17, BIOS N1EET74W (1.47 ) 11/21/2017
        RIP: 0010:ioread32+0x2b/0x30
        Code: 81 ff ff ff 03 00 77 20 48 81 ff 00 00 01 00 76 05 0f b7 d7 ed c3
        48 c7 c6 e1 0c 36 96 e8 2d ff ff ff b8 ff ff ff ff c3 8b 07 <c3> 0f 1f
        40 00 49 89 f0 48 81 fe ff ff 03 00 76 04 40 88 3e c3 48
        RSP: 0018:ffffaac3c5007b48 EFLAGS: 00000292 ORIG_RAX: ffffffffffffff13
        RAX: 0000000001111000 RBX: 0000000001111000 RCX: 0000043017a97186
        RDX: 0000000000000aaa RSI: 0000000000000005 RDI: ffffaac3c400e4e4
        RBP: ffff9e6443902c00 R08: ffffaac3c400e4e4 R09: ffffaac3c5007be7
        R10: 0000000000000004 R11: 0000000000000001 R12: ffff9e6445dd0000
        R13: 000000000000e4e4 R14: 00000000000003c4 R15: 0000000000000000
        FS:  00007f253155a740(0000) GS:ffff9e644f600000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00005630d1500358 CR3: 0000000417c44006 CR4: 00000000003606e0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        Call Trace:
         g94_i2c_aux_xfer+0x326/0x850 [nouveau]
         nvkm_i2c_aux_i2c_xfer+0x9e/0x140 [nouveau]
         __i2c_transfer+0x14b/0x620
         i2c_smbus_xfer_emulated+0x159/0x680
         ? _raw_spin_unlock_irqrestore+0x1/0x60
         ? rt_mutex_slowlock.constprop.0+0x13d/0x1e0
         ? __lock_is_held+0x59/0xa0
         __i2c_smbus_xfer+0x138/0x5a0
         i2c_smbus_xfer+0x4f/0x80
         i2cdev_ioctl_smbus+0x162/0x2d0 [i2c_dev]
         i2cdev_ioctl+0x1db/0x2c0 [i2c_dev]
         do_vfs_ioctl+0x408/0x750
         ksys_ioctl+0x5e/0x90
         __x64_sys_ioctl+0x16/0x20
         do_syscall_64+0x60/0x1e0
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
        RIP: 0033:0x7f25317f546b
        Code: 0f 1e fa 48 8b 05 1d da 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff
        ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01
        f0 ff ff 73 01 c3 48 8b 0d ed d9 0c 00 f7 d8 64 89 01 48
        RSP: 002b:00007ffc88caab68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
        RAX: ffffffffffffffda RBX: 00005630d0fe7260 RCX: 00007f25317f546b
        RDX: 00005630d1598e80 RSI: 0000000000000720 RDI: 0000000000000003
        RBP: 00005630d155b968 R08: 0000000000000001 R09: 00005630d15a1da0
        R10: 0000000000000070 R11: 0000000000000246 R12: 00005630d1598e80
        R13: 00005630d12f3d28 R14: 0000000000000720 R15: 00005630d12f3ce0
        watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [sensors-detect:12438]
      
      Yikes! While I wanted to try to make it so that accessing an i2c bus on
      nouveau would wake up the GPU as needed, airlied pointed out that pretty
      much any usecase for userspace accessing an i2c bus on a GPU (mainly for
      the DDC brightness control that some displays have) is going to only be
      useful while there's at least one display enabled on the GPU anyway, and
      the GPU never sleeps while there's displays running.
      
      Since teaching the i2c bus to wake up the GPU on userspace accesses is a
      good deal more difficult than it might seem, mostly due to the fact that
      we have to use the i2c bus during runtime resume of the GPU, we instead
      opt for the easiest solution: don't let userspace access i2c busses on
      the GPU at all while it's in runtime suspend.
      
      Changes since v1:
      * Also disable i2c busses that run over DP AUX
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88ad86b8
    • T
      KVM: s390: Do not report unusabled IDs via KVM_CAP_MAX_VCPU_ID · 6a2fbec7
      Thomas Huth 提交于
      commit a86cb413f4bf273a9d341a3ab2c2ca44e12eb317 upstream.
      
      KVM_CAP_MAX_VCPU_ID is currently always reporting KVM_MAX_VCPU_ID on all
      architectures. However, on s390x, the amount of usable CPUs is determined
      during runtime - it is depending on the features of the machine the code
      is running on. Since we are using the vcpu_id as an index into the SCA
      structures that are defined by the hardware (see e.g. the sca_add_vcpu()
      function), it is not only the amount of CPUs that is limited by the hard-
      ware, but also the range of IDs that we can use.
      Thus KVM_CAP_MAX_VCPU_ID must be determined during runtime on s390x, too.
      So the handling of KVM_CAP_MAX_VCPU_ID has to be moved from the common
      code into the architecture specific code, and on s390x we have to return
      the same value here as for KVM_CAP_MAX_VCPUS.
      This problem has been discovered with the kvm_create_max_vcpus selftest.
      With this change applied, the selftest now passes on s390x, too.
      Reviewed-by: NAndrew Jones <drjones@redhat.com>
      Reviewed-by: NCornelia Huck <cohuck@redhat.com>
      Reviewed-by: NDavid Hildenbrand <david@redhat.com>
      Signed-off-by: NThomas Huth <thuth@redhat.com>
      Message-Id: <20190523164309.13345-9-thuth@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      6a2fbec7
    • H
      ALSA: hda/realtek - Improve the headset mic for Acer Aspire laptops · 3834630e
      Hui Wang 提交于
      commit 9cb40eb184c4220d244a532bd940c6345ad9dbd9 upstream.
      
      We met another Acer Aspire laptop which has the problem on the
      headset-mic, the Pin 0x19 is not set the corret configuration for a
      mic and the pin presence can't be detected too after plugging a
      headset. Kailang suggested that we should set the coeff to enable the
      mic and apply the ALC269_FIXUP_LIFEBOOK_EXTMIC. After doing that,
      both headset-mic presence and headset-mic work well.
      
      The existing ALC255_FIXUP_ACER_MIC_NO_PRESENCE set the headset-mic
      jack to be a phantom jack. Now since the jack can support presence
      unsol event, let us imporve it to set the jack to be a normal jack.
      
      https://bugs.launchpad.net/bugs/1821269
      Fixes: 5824ce8d ("ALSA: hda/realtek - Add support for Acer Aspire E5-475 headset mic")
      Cc: Chris Chiu <chiu@endlessm.com>
      CC: Daniel Drake <drake@endlessm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NKailang Yang <kailang@realtek.com>
      Signed-off-by: NHui Wang <hui.wang@canonical.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3834630e
    • K
      ALSA: hda/realtek - Set default power save node to 0 · 9cfd6c36
      Kailang Yang 提交于
      commit 317d9313925cd8388304286c0d3c8dda7f060a2d upstream.
      
      I measured power consumption between power_save_node=1 and power_save_node=0.
      It's almost the same.
      Codec will enter to runtime suspend and suspend.
      That pin also will enter to D3. Don't need to enter to D3 by single pin.
      So, Disable power_save_node as default. It will avoid more issues.
      Windows Driver also has not this option at runtime PM.
      Signed-off-by: NKailang Yang <kailang@realtek.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9cfd6c36
    • T
      ALSA: line6: Assure canceling delayed work at disconnection · eb2eeec9
      Takashi Iwai 提交于
      commit 0b074ab7fc0d575247b9cc9f93bb7e007ca38840 upstream.
      
      The current code performs the cancel of a delayed work at the late
      stage of disconnection procedure, which may lead to the access to the
      already cleared state.
      
      This patch assures to call cancel_delayed_work_sync() at the beginning
      of the disconnection procedure for avoiding that race.  The delayed
      work object is now assigned in the common line6 object instead of its
      derivative, so that we can call cancel_delayed_work_sync().
      
      Along with the change, the startup function is called via the new
      callback instead.  This will make it easier to port other LINE6
      drivers to use the delayed work for startup in later patches.
      
      Reported-by: syzbot+5255458d5e0a2b10bbb9@syzkaller.appspotmail.com
      Fixes: 7f84ff68be05 ("ALSA: line6: toneport: Fix broken usage of timer for delayed execution")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eb2eeec9
    • R
      powerpc/perf: Fix MMCRA corruption by bhrb_filter · ca221cf9
      Ravi Bangoria 提交于
      commit 3202e35ec1c8fc19cea24253ff83edf702a60a02 upstream.
      
      Consider a scenario where user creates two events:
      
        1st event:
          attr.sample_type |= PERF_SAMPLE_BRANCH_STACK;
          attr.branch_sample_type = PERF_SAMPLE_BRANCH_ANY;
          fd = perf_event_open(attr, 0, 1, -1, 0);
      
        This sets cpuhw->bhrb_filter to 0 and returns valid fd.
      
        2nd event:
          attr.sample_type |= PERF_SAMPLE_BRANCH_STACK;
          attr.branch_sample_type = PERF_SAMPLE_BRANCH_CALL;
          fd = perf_event_open(attr, 0, 1, -1, 0);
      
        It overrides cpuhw->bhrb_filter to -1 and returns with error.
      
      Now if power_pmu_enable() gets called by any path other than
      power_pmu_add(), ppmu->config_bhrb(-1) will set MMCRA to -1.
      
      Fixes: 3925f46b ("powerpc/perf: Enable branch stack sampling framework")
      Cc: stable@vger.kernel.org # v3.10+
      Signed-off-by: NRavi Bangoria <ravi.bangoria@linux.ibm.com>
      Reviewed-by: NMadhavan Srinivasan <maddy@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ca221cf9
    • C
      KVM: PPC: Book3S HV: XIVE: Do not clear IRQ data of passthrough interrupts · 55a94d81
      Cédric Le Goater 提交于
      commit ef9740204051d0e00f5402fe96cf3a43ddd2bbbf upstream.
      
      The passthrough interrupts are defined at the host level and their IRQ
      data should not be cleared unless specifically deconfigured (shutdown)
      by the host. They differ from the IPI interrupts which are allocated
      by the XIVE KVM device and reserved to the guest usage only.
      
      This fixes a host crash when destroying a VM in which a PCI adapter
      was passed-through. In this case, the interrupt is cleared and freed
      by the KVM device and then shutdown by vfio at the host level.
      
      [ 1007.360265] BUG: Kernel NULL pointer dereference at 0x00000d00
      [ 1007.360285] Faulting instruction address: 0xc00000000009da34
      [ 1007.360296] Oops: Kernel access of bad area, sig: 7 [#1]
      [ 1007.360303] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
      [ 1007.360314] Modules linked in: vhost_net vhost iptable_mangle ipt_MASQUERADE iptable_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 tun bridge stp llc kvm_hv kvm xt_tcpudp iptable_filter squashfs fuse binfmt_misc vmx_crypto ib_iser rdma_cm iw_cm ib_cm libiscsi scsi_transport_iscsi nfsd ip_tables x_tables autofs4 btrfs zstd_decompress zstd_compress lzo_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq multipath mlx5_ib ib_uverbs ib_core crc32c_vpmsum mlx5_core
      [ 1007.360425] CPU: 9 PID: 15576 Comm: CPU 18/KVM Kdump: loaded Not tainted 5.1.0-gad7e7d0ef #4
      [ 1007.360454] NIP:  c00000000009da34 LR: c00000000009e50c CTR: c00000000009e5d0
      [ 1007.360482] REGS: c000007f24ccf330 TRAP: 0300   Not tainted  (5.1.0-gad7e7d0ef)
      [ 1007.360500] MSR:  900000000280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 24002484  XER: 00000000
      [ 1007.360532] CFAR: c00000000009da10 DAR: 0000000000000d00 DSISR: 00080000 IRQMASK: 1
      [ 1007.360532] GPR00: c00000000009e62c c000007f24ccf5c0 c000000001510600 c000007fe7f947c0
      [ 1007.360532] GPR04: 0000000000000d00 0000000000000000 0000000000000000 c000005eff02d200
      [ 1007.360532] GPR08: 0000000000400000 0000000000000000 0000000000000000 fffffffffffffffd
      [ 1007.360532] GPR12: c00000000009e5d0 c000007fffff7b00 0000000000000031 000000012c345718
      [ 1007.360532] GPR16: 0000000000000000 0000000000000008 0000000000418004 0000000000040100
      [ 1007.360532] GPR20: 0000000000000000 0000000008430000 00000000003c0000 0000000000000027
      [ 1007.360532] GPR24: 00000000000000ff 0000000000000000 00000000000000ff c000007faa90d98c
      [ 1007.360532] GPR28: c000007faa90da40 00000000000fe040 ffffffffffffffff c000007fe7f947c0
      [ 1007.360689] NIP [c00000000009da34] xive_esb_read+0x34/0x120
      [ 1007.360706] LR [c00000000009e50c] xive_do_source_set_mask.part.0+0x2c/0x50
      [ 1007.360732] Call Trace:
      [ 1007.360738] [c000007f24ccf5c0] [c000000000a6383c] snooze_loop+0x15c/0x270 (unreliable)
      [ 1007.360775] [c000007f24ccf5f0] [c00000000009e62c] xive_irq_shutdown+0x5c/0xe0
      [ 1007.360795] [c000007f24ccf630] [c00000000019e4a0] irq_shutdown+0x60/0xe0
      [ 1007.360813] [c000007f24ccf660] [c000000000198c44] __free_irq+0x3a4/0x420
      [ 1007.360831] [c000007f24ccf700] [c000000000198dc8] free_irq+0x78/0xe0
      [ 1007.360849] [c000007f24ccf730] [c00000000096c5a8] vfio_msi_set_vector_signal+0xa8/0x350
      [ 1007.360878] [c000007f24ccf7f0] [c00000000096c938] vfio_msi_set_block+0xe8/0x1e0
      [ 1007.360899] [c000007f24ccf850] [c00000000096cae0] vfio_msi_disable+0xb0/0x110
      [ 1007.360912] [c000007f24ccf8a0] [c00000000096cd04] vfio_pci_set_msi_trigger+0x1c4/0x3d0
      [ 1007.360922] [c000007f24ccf910] [c00000000096d910] vfio_pci_set_irqs_ioctl+0xa0/0x170
      [ 1007.360941] [c000007f24ccf930] [c00000000096b400] vfio_pci_disable+0x80/0x5e0
      [ 1007.360963] [c000007f24ccfa10] [c00000000096b9bc] vfio_pci_release+0x5c/0x90
      [ 1007.360991] [c000007f24ccfa40] [c000000000963a9c] vfio_device_fops_release+0x3c/0x70
      [ 1007.361012] [c000007f24ccfa70] [c0000000003b5668] __fput+0xc8/0x2b0
      [ 1007.361040] [c000007f24ccfac0] [c0000000001409b0] task_work_run+0x140/0x1b0
      [ 1007.361059] [c000007f24ccfb20] [c000000000118f8c] do_exit+0x3ac/0xd00
      [ 1007.361076] [c000007f24ccfc00] [c0000000001199b0] do_group_exit+0x60/0x100
      [ 1007.361094] [c000007f24ccfc40] [c00000000012b514] get_signal+0x1a4/0x8f0
      [ 1007.361112] [c000007f24ccfd30] [c000000000021cc8] do_notify_resume+0x1a8/0x430
      [ 1007.361141] [c000007f24ccfe20] [c00000000000e444] ret_from_except_lite+0x70/0x74
      [ 1007.361159] Instruction dump:
      [ 1007.361175] 38422c00 e9230000 712a0004 41820010 548a2036 7d442378 78840020 71290020
      [ 1007.361194] 4082004c e9230010 7c892214 7c0004ac <e9240000> 0c090000 4c00012c 792a0022
      
      Cc: stable@vger.kernel.org # v4.12+
      Fixes: 5af50993 ("KVM: PPC: Book3S HV: Native usage of the XIVE interrupt controller")
      Signed-off-by: NCédric Le Goater <clg@kaod.org>
      Signed-off-by: NGreg Kurz <groug@kaod.org>
      Signed-off-by: NPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      55a94d81
    • H
      s390/crypto: fix possible sleep during spinlock aquired · badbe1ab
      Harald Freudenberger 提交于
      commit 1c2c7029c008922d4d48902cc386250502e73d51 upstream.
      
      This patch fixes a complain about possible sleep during
      spinlock aquired
      "BUG: sleeping function called from invalid context at
      include/crypto/algapi.h:426"
      for the ctr(aes) and ctr(des) s390 specific ciphers.
      
      Instead of using a spinlock this patch introduces a mutex
      which is save to be held in sleeping context. Please note
      a deadlock is not possible as mutex_trylock() is used.
      Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
      Reported-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      badbe1ab