1. 31 May, 2019 40 commits
    • Arnd Bergmann's avatar
      spi: export tracepoint symbols to modules · ed49bb0d
      Arnd Bergmann authored
      [ Upstream commit ca1438dc ]
      
      The newly added tracepoints in the spi-mxs driver cause a link
      error when the driver is a loadable module:
      
      ERROR: "__tracepoint_spi_transfer_stop" [drivers/spi/spi-mxs.ko] undefined!
      ERROR: "__tracepoint_spi_transfer_start" [drivers/spi/spi-mxs.ko] undefined!
      
      I'm not quite sure where to put the export statements, but
      directly after the inclusion of the header seems as good as
      any other place.
      
      Fixes: f3fdea3a ("spi: mxs: add tracing to custom .transfer_one_message callback")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ed49bb0d
    • Aditya Pakki's avatar
      thunderbolt: Fix to check for kmemdup failure · d82c47c5
      Aditya Pakki authored
      [ Upstream commit 2cc12751 ]
      
      Memory allocated via kmemdup might fail and return a NULL pointer.
      This patch adds a check on the return value of kmemdup and passes the
      error upstream.
      Signed-off-by: default avatarAditya Pakki <pakki001@umn.edu>
      Reviewed-by: default avatarMukesh Ojha <mojha@codeaurora.org>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d82c47c5
    • Aditya Pakki's avatar
      thunderbolt: Fix to check return value of ida_simple_get · 7f1a6aba
      Aditya Pakki authored
      [ Upstream commit 9aabb685 ]
      
      In enumerate_services, ida_simple_get on failure can return an error and
      leaks memory. The patch ensures that the dev_set_name is set on non
      failure cases, and releases memory during failure.
      Signed-off-by: default avatarAditya Pakki <pakki001@umn.edu>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7f1a6aba
    • Rouven Czerwinski's avatar
      hwrng: omap - Set default quality · 86c326d7
      Rouven Czerwinski authored
      [ Upstream commit 62f95ae8 ]
      
      Newer combinations of the glibc, kernel and openssh can result in long initial
      startup times on OMAP devices:
      
      [    6.671425] systemd-rc-once[102]: Creating ED25519 key; this may take some time ...
      [  142.652491] systemd-rc-once[102]: Creating ED25519 key; done.
      
      due to the blocking getrandom(2) system call:
      
      [  142.610335] random: crng init done
      
      Set the quality level for the omap hwrng driver allowing the kernel to use the
      hwrng as an entropy source at boot.
      Signed-off-by: default avatarRouven Czerwinski <r.czerwinski@pengutronix.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      86c326d7
    • George Hilliard's avatar
      staging: mt7621-mmc: Check for nonzero number of scatterlist entries · 94fbe6c9
      George Hilliard authored
      [ Upstream commit d4223e06 ]
      
      The buffer descriptor setup loop is correct only if it is setting up at
      least one bd struct.  Besides, there is an error if dma_map_sg() returns
      0, which is possible and must be handled.
      
      Additionally, remove the BUG_ON() checking sglen, which is unnecessary
      because we configure DMA with that constraint during init.
      Signed-off-by: default avatarGeorge Hilliard <thirtythreeforty@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      94fbe6c9
    • Saeed Mahameed's avatar
      net/mlx5e: Fix compilation warning in en_tc.c · 5a27284c
      Saeed Mahameed authored
      [ Upstream commit ee576ec1 ]
      
      Amazingly a mlx5e_tc function is being called from the eswitch layer,
      which is by itself very terrible! The function was declared locally in
      eswitch_offloads.c so it could be used there, which caused the following
      compilation warning, fix that.
      
      drivers/.../mlx5/core/en_tc.c:3242:6: [-Werror=missing-prototypes]
      error: no previous prototype for ‘mlx5e_tc_clean_fdb_peer_flows’
      
      Fixes: 04de7dda ("net/mlx5e: Infrastructure for duplicated offloading of TC flows")
      Reviewed-by: default avatarRoi Dayan <roid@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5a27284c
    • Pu Wen's avatar
      x86/CPU/hygon: Fix phys_proc_id calculation logic for multi-die processors · 0729d591
      Pu Wen authored
      [ Upstream commit e0ceeae7 ]
      
      The Hygon family 18h multi-die processor platform supports 1, 2 or
      4-Dies per socket. The topology looks like this:
      
        System View (with 1-Die 2-Socket):
                   |------------|
                 ------       -----
         SOCKET0 | D0 |       | D1 |  SOCKET1
                 ------       -----
      
        System View (with 2-Die 2-socket):
                   --------------------
                   |     -------------|------
                   |     |            |     |
                 ------------       ------------
         SOCKET0 | D1 -- D0 |       | D3 -- D2 | SOCKET1
                 ------------       ------------
      
        System View (with 4-Die 2-Socket) :
                   --------------------
                   |     -------------|------
                   |     |            |     |
                 ------------       ------------
                 | D1 -- D0 |       | D7 -- D6 |
                 | |  \/ |  |       | |  \/ |  |
         SOCKET0 | |  /\ |  |       | |  /\ |  | SOCKET1
                 | D2 -- D3 |       | D4 -- D5 |
                 ------------       ------------
                   |     |            |     |
                   ------|------------|     |
                         --------------------
      
      Currently
      
        phys_proc_id = initial_apicid >> bits
      
      calculates the physical processor ID from the initial_apicid by shifting
      *bits*.
      
      However, this does not work for 1-Die and 2-Die 2-socket systems.
      
      According to document [1] section 2.1.11.1, the bits is the value of
      CPUID_Fn80000008_ECX[12:15]. The possible values are 4, 5 or 6 which
      mean:
      
        4 - 1 die
        5 - 2 dies
        6 - 3/4 dies.
      
      Hygon programs the initial ApicId the same way as AMD. The ApicId is
      read from CPUID_Fn00000001_EBX (see section 2.1.11.1 of referrence [1])
      and the definition is as below (see section 2.1.10.2.1.3 of [1]):
      
            -------------------------------------------------
        Bit |     6     |   5  4  |    3   |    2   1   0   |
            |-----------|---------|--------|----------------|
        IDs | Socket ID | Node ID | CCX ID | Core/Thread ID |
            -------------------------------------------------
      
      So for 3/4-Die configurations, the bits variable is 6, which is the same
      as the ApicID definition field.
      
      For 1-Die and 2-Die configurations, bits is 4 or 5, which will cause the
      right shifted result to not be exactly the value of socket ID.
      
      However, the socket ID should be obtained from ApicId[6]. To fix the
      problem and match the ApicID field definition, set the shift bits to 6
      for all Hygon family 18h multi-die CPUs.
      
      Because AMD doesn't have 2-Socket systems with 1-Die/2-Die processors
      (see reference [2]), this doesn't need to be changed on the AMD side but
      only for Hygon.
      
      References:
      [1] https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf
      [2] https://www.amd.com/en/products/specifications/processors
      
       [bp: heavily massage commit message. ]
      Signed-off-by: default avatarPu Wen <puwen@hygon.cn>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thomas Lendacky <Thomas.Lendacky@amd.com>
      Cc: Yazen Ghannam <yazen.ghannam@amd.com>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/1553355740-19999-1-git-send-email-puwen@hygon.cnSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      0729d591
    • Sameer Pujar's avatar
      dmaengine: tegra210-adma: use devm_clk_*() helpers · 55d1773e
      Sameer Pujar authored
      [ Upstream commit f6ed6491 ]
      
      adma driver is using pm_clk_*() interface for managing clock resources.
      With this it is observed that clocks remain ON always. This happens on
      Tegra devices which use BPMP co-processor to manage clock resources,
      where clocks are enabled during prepare phase. This is necessary because
      clocks to BPMP are always blocking. When pm_clk_*() interface is used on
      such Tegra devices, clock prepare count is not balanced till remove call
      happens for the driver and hence clocks are seen ON always. Thus this
      patch replaces pm_clk_*() with devm_clk_*() framework.
      Suggested-by: default avatarMohan Kumar D <mkumard@nvidia.com>
      Reviewed-by: default avatarJonathan Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarSameer Pujar <spujar@nvidia.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      55d1773e
    • Linus Lüssing's avatar
      batman-adv: allow updating DAT entry timeouts on incoming ARP Replies · d08c911b
      Linus Lüssing authored
      [ Upstream commit 099e6cc1 ]
      
      Currently incoming ARP Replies, for example via a DHT-PUT message, do
      not update the timeout for an already existing DAT entry. These ARP
      Replies are dropped instead.
      
      This however defeats the purpose of the DHCPACK snooping, for instance.
      Right now, a DAT entry in the DHT will be purged every five minutes,
      likely leading to a mesh-wide ARP Request broadcast after this timeout.
      Which then recreates the entry. The idea of the DHCPACK snooping is to
      be able to update an entry before a timeout happens, to avoid ARP Request
      flooding.
      
      This patch fixes this issue by updating a DAT entry on incoming
      ARP Replies even if a matching DAT entry already exists. While still
      filtering the ARP Reply towards the soft-interface, to avoid duplicate
      messages on the client device side.
      Signed-off-by: default avatarLinus Lüssing <linus.luessing@c0d3.blue>
      Acked-by: default avatarAntonio Quartulli <a@unstable.cc>
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d08c911b
    • Arnd Bergmann's avatar
      selinux: avoid uninitialized variable warning · dbc55f8f
      Arnd Bergmann authored
      [ Upstream commit 98bbbb76 ]
      
      clang correctly points out a code path that would lead
      to an uninitialized variable use:
      
      security/selinux/netlabel.c:310:6: error: variable 'addr' is used uninitialized whenever 'if' condition is false
            [-Werror,-Wsometimes-uninitialized]
              if (ip_hdr(skb)->version == 4) {
                  ^~~~~~~~~~~~~~~~~~~~~~~~~
      security/selinux/netlabel.c:322:40: note: uninitialized use occurs here
              rc = netlbl_conn_setattr(ep->base.sk, addr, &secattr);
                                                    ^~~~
      security/selinux/netlabel.c:310:2: note: remove the 'if' if its condition is always true
              if (ip_hdr(skb)->version == 4) {
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      security/selinux/netlabel.c:291:23: note: initialize the variable 'addr' to silence this warning
              struct sockaddr *addr;
                                   ^
                                    = NULL
      
      This is probably harmless since we should not see ipv6 packets
      of CONFIG_IPV6 is disabled, but it's better to rearrange the code
      so this cannot happen.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      [PM: removed old patchwork link, fixed checkpatch.pl style errors]
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dbc55f8f
    • Dave Ertman's avatar
      ice: Prevent unintended multiple chain resets · d060bb09
      Dave Ertman authored
      [ Upstream commit 2ebd4428 ]
      
      In the current implementation of ice_reset_subtask, if multiple reset
      types are set in the pf->state, the most intrusive one is meant to be
      performed only, but the bits requesting the other types are not being
      cleared. This would lead to another reset being performed the next time
      the service task is scheduled.
      
      Change the flow of ice_reset_subtask so that all reset request bits in
      pf->state are cleared, and we still perform the most intrusive of the
      resets requested.
      Signed-off-by: default avatarDave Ertman <david.m.ertman@intel.com>
      Signed-off-by: default avatarAnirudh Venkataramanan <anirudh.venkataramanan@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d060bb09
    • Dafna Hirschfeld's avatar
      media: vicodec: bugfix - call v4l2_m2m_buf_copy_metadata also if decoding fails · 3f0fe090
      Dafna Hirschfeld authored
      [ Upstream commit 8eead25c ]
      
      The function 'v4l2_m2m_buf_copy_metadata' should
      be called even if decoding/encoding ends with
      status VB2_BUF_STATE_ERROR, so that the metadata
      is copied from the source buffer to the dest buffer.
      Signed-off-by: default avatarDafna Hirschfeld <dafna3@gmail.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3f0fe090
    • Arnd Bergmann's avatar
      scsi: lpfc: avoid uninitialized variable warning · 614ed19a
      Arnd Bergmann authored
      [ Upstream commit faf5a744 ]
      
      clang -Wuninitialized incorrectly sees a variable being used without
      initialization:
      
      drivers/scsi/lpfc/lpfc_nvme.c:2102:37: error: variable 'localport' is uninitialized when used here
            [-Werror,-Wuninitialized]
                      lport = (struct lpfc_nvme_lport *)localport->private;
                                                        ^~~~~~~~~
      drivers/scsi/lpfc/lpfc_nvme.c:2059:38: note: initialize the variable 'localport' to silence this warning
              struct nvme_fc_local_port *localport;
                                                  ^
                                                   = NULL
      1 error generated.
      
      This is clearly in dead code, as the condition leading up to it is always
      false when CONFIG_NVME_FC is disabled, and the variable is always
      initialized when nvme_fc_register_localport() got called successfully.
      
      Change the preprocessor conditional to the equivalent C construct, which
      makes the code more readable and gets rid of the warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarJames Smart <james.smart@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      614ed19a
    • Arnd Bergmann's avatar
      scsi: qla4xxx: avoid freeing unallocated dma memory · 890ea842
      Arnd Bergmann authored
      [ Upstream commit 608f729c ]
      
      Clang -Wuninitialized notices that on is_qla40XX we never allocate any DMA
      memory in get_fw_boot_info() but attempt to free it anyway:
      
      drivers/scsi/qla4xxx/ql4_os.c:5915:7: error: variable 'buf_dma' is used uninitialized whenever 'if' condition is false
            [-Werror,-Wsometimes-uninitialized]
                      if (!(val & 0x07)) {
                          ^~~~~~~~~~~~~
      drivers/scsi/qla4xxx/ql4_os.c:5985:47: note: uninitialized use occurs here
              dma_free_coherent(&ha->pdev->dev, size, buf, buf_dma);
                                                           ^~~~~~~
      drivers/scsi/qla4xxx/ql4_os.c:5915:3: note: remove the 'if' if its condition is always true
                      if (!(val & 0x07)) {
                      ^~~~~~~~~~~~~~~~~~~
      drivers/scsi/qla4xxx/ql4_os.c:5885:20: note: initialize the variable 'buf_dma' to silence this warning
              dma_addr_t buf_dma;
                                ^
                                 = 0
      
      Skip the call to dma_free_coherent() here.
      
      Fixes: 2a991c21 ("[SCSI] qla4xxx: Boot from SAN support for open-iscsi")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      890ea842
    • Anirudh Venkataramanan's avatar
      ice: Fix for adaptive interrupt moderation · 08cce74e
      Anirudh Venkataramanan authored
      [ Upstream commit 64a59d05 ]
      
      commit 63f545ed ("ice: Add support for adaptive interrupt moderation")
      was meant to add support for adaptive interrupt moderation but there was
      an error on my part while formatting the patch, and thus only part of the
      patch ended up being submitted.
      
      This patch rectifies the error by adding the rest of the code.
      
      Fixes: 63f545ed ("ice: Add support for adaptive interrupt moderation")
      Signed-off-by: default avatarAnirudh Venkataramanan <anirudh.venkataramanan@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      08cce74e
    • Tony Lindgren's avatar
      usb: core: Add PM runtime calls to usb_hcd_platform_shutdown · d43589f9
      Tony Lindgren authored
      [ Upstream commit 8ead7e81 ]
      
      If ohci-platform is runtime suspended, we can currently get an "imprecise
      external abort" on reboot with ohci-platform loaded when PM runtime
      is implemented for the SoC.
      
      Let's fix this by adding PM runtime support to usb_hcd_platform_shutdown.
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d43589f9
    • Ludovic Barre's avatar
      spi: stm32-qspi: add spi_master_put in release function · 30a120c1
      Ludovic Barre authored
      [ Upstream commit a88eceb1 ]
      
      This patch adds spi_master_put in release function
      to drop the controller's refcount.
      Signed-off-by: default avatarLudovic Barre <ludovic.barre@st.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      30a120c1
    • Leon Romanovsky's avatar
      RDMA/rxe: Fix slab-out-bounds access which lead to kernel crash later · 8063559d
      Leon Romanovsky authored
      [ Upstream commit a4b7013d ]
      
      BUG: KASAN: slab-out-of-bounds in rxe_mem_init_user+0x6c1/0x740 [rdma_rxe]
      Read of size 8 at addr ffff88805c01a608 by task ib_send_bw/573
      
      CPU: 24 PID: 573 Comm: ib_send_bw Not tainted 5.0.0-rc5+ #189
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014
      Call Trace:
       rxe_mem_init_user+0x6c1/0x740 [rdma_rxe]
       rxe_reg_user_mr+0x9b/0x110 [rdma_rxe]
       ib_uverbs_reg_mr+0x428/0x9c0 [ib_uverbs]
       ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2b0/0x410 [ib_uverbs]
       ib_uverbs_run_method+0x79c/0x1da0 [ib_uverbs]
       rxe_mem_init_user+0x6c1/0x740 [rdma_rxe]
       rxe_reg_user_mr+0x9b/0x110 [rdma_rxe]
       ib_uverbs_reg_mr+0x428/0x9c0 [ib_uverbs]
       ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2b0/0x410 [ib_uverbs]
       ib_uverbs_run_method+0x79c/0x1da0 [ib_uverbs]
       ib_uverbs_cmd_verbs+0x5f2/0xf20 [ib_uverbs]
       ib_uverbs_ioctl+0x202/0x310 [ib_uverbs]
       do_vfs_ioctl+0x193/0x1440
       ksys_ioctl+0x3a/0x70
       __x64_sys_ioctl+0x6f/0xb0
       do_syscall_64+0x13f/0x570
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Allocated by task 573:
       __kasan_kmalloc.constprop.5+0xc1/0xd0
       __kmalloc+0x161/0x310
       rxe_mem_alloc+0x52/0x470 [rdma_rxe]
       rxe_mem_init_user+0x113/0x740 [rdma_rxe]
       rxe_reg_user_mr+0x9b/0x110 [rdma_rxe]
       ib_uverbs_reg_mr+0x428/0x9c0 [ib_uverbs]
       ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2b0/0x410 [ib_uverbs]
       ib_uverbs_run_method+0x79c/0x1da0 [ib_uverbs]
       ib_uverbs_cmd_verbs+0x5f2/0xf20 [ib_uverbs]
       ib_uverbs_ioctl+0x202/0x310 [ib_uverbs]
       do_vfs_ioctl+0x193/0x1440
       ksys_ioctl+0x3a/0x70
       __x64_sys_ioctl+0x6f/0xb0
       do_syscall_64+0x13f/0x570
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 0:
       __kasan_slab_free+0x12e/0x180
       kfree+0x10a/0x2c0
       rcu_process_callbacks+0xa77/0x1260
       __do_softirq+0x2ad/0xacb
      
      Test scenario:
       ib_send_bw -x 1 -d rxe0 -a &
       ib_send_bw -x 1 -d rxe0 -a localhost
      
      Fixes: 8700e3e7 ("Soft RoCE driver")
      Reported-by: default avatarParav Pandit <parav@mellanox.com>
      Reviewed-by: default avatarZhu Yanjun <yanjun.zhu@oracle.com>
      Tested-by: default avatarZhu Yanjun <yanjun.zhu@oracle.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8063559d
    • Kangjie Lu's avatar
      x86/platform/uv: Fix missing checks of kcalloc() return values · 6937a052
      Kangjie Lu authored
      [ Upstream commit 76646085 ]
      
      Handle potential errors returned from kcalloc().
      
       [ bp: rewrite commit message. ]
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andrew Banman <abanman@hpe.com>
      Cc: Andy Shevchenko <andy@infradead.org>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Darren Hart <dvhart@infradead.org>
      Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Mike Travis <mike.travis@hpe.com>
      Cc: Nicolai Stange <nstange@suse.de>
      Cc: pakki001@umn.edu
      Cc: platform-driver-x86@vger.kernel.org
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Varsha Rao <rvarsha016@gmail.com>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20190325202924.4624-1-kjlu@umn.eduSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      6937a052
    • Neeraj Upadhyay's avatar
      rcu: Do a single rhp->func read in rcu_head_after_call_rcu() · e8cfc326
      Neeraj Upadhyay authored
      [ Upstream commit b699cce1 ]
      
      The rcu_head_after_call_rcu() function reads the rhp->func pointer twice,
      which can result in a false-positive WARN_ON_ONCE() if the callback
      were passed to call_rcu() between the two reads.  Although racing
      rcu_head_after_call_rcu() with call_rcu() is to be a dubious use case
      (the return value is not reliable in that case), intermittent and
      irreproducible warnings are also quite dubious.  This commit therefore
      uses a single READ_ONCE() to pick up the value of rhp->func once, then
      tests that value twice, thus guaranteeing consistent processing within
      rcu_head_after_call_rcu()().
      
      Neverthless, racing rcu_head_after_call_rcu() with call_rcu() is still
      a dubious use case.
      Signed-off-by: default avatarNeeraj Upadhyay <neeraju@codeaurora.org>
      [ paulmck: Add blank line after declaration per checkpatch.pl. ]
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.ibm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e8cfc326
    • Paul E. McKenney's avatar
      rcuperf: Fix cleanup path for invalid perf_type strings · f618b46f
      Paul E. McKenney authored
      [ Upstream commit ad092c02 ]
      
      If the specified rcuperf.perf_type is not in the rcu_perf_init()
      function's perf_ops[] array, rcuperf prints some console messages and
      then invokes rcu_perf_cleanup() to set state so that a future torture
      test can run.  However, rcu_perf_cleanup() also attempts to end the
      test that didn't actually start, and in doing so relies on the value
      of cur_ops, a value that is not particularly relevant in this case.
      This can result in confusing output or even follow-on failures due to
      attempts to use facilities that have not been properly initialized.
      
      This commit therefore sets the value of cur_ops to NULL in this case and
      inserts a check near the beginning of rcu_perf_cleanup(), thus avoiding
      relying on an irrelevant cur_ops value.
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.ibm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f618b46f
    • Yazen Ghannam's avatar
      x86/mce: Handle varying MCA bank counts · 776613c5
      Yazen Ghannam authored
      [ Upstream commit 006c0770 ]
      
      Linux reads MCG_CAP[Count] to find the number of MCA banks visible to a
      CPU. Currently, this number is the same for all CPUs and a warning is
      shown if there is a difference. The number of banks is overwritten with
      the MCG_CAP[Count] value of each following CPU that boots.
      
      According to the Intel SDM and AMD APM, the MCG_CAP[Count] value gives
      the number of banks that are available to a "processor implementation".
      The AMD BKDGs/PPRs further clarify that this value is per core. This
      value has historically been the same for every core in the system, but
      that is not an architectural requirement.
      
      Future AMD systems may have different MCG_CAP[Count] values per core,
      so the assumption that all CPUs will have the same MCG_CAP[Count] value
      will no longer be valid.
      
      Also, the first CPU to boot will allocate the struct mce_banks[] array
      using the number of banks based on its MCG_CAP[Count] value. The machine
      check handler and other functions use the global number of banks to
      iterate and index into the mce_banks[] array. So it's possible to use an
      out-of-bounds index on an asymmetric system where a following CPU sees a
      MCG_CAP[Count] value greater than its predecessors.
      
      Thus, allocate the mce_banks[] array to the maximum number of banks.
      This will avoid the potential out-of-bounds index since the value of
      mca_cfg.banks is capped to MAX_NR_BANKS.
      
      Set the value of mca_cfg.banks equal to the max of the previous value
      and the value for the current CPU. This way mca_cfg.banks will always
      represent the max number of banks detected on any CPU in the system.
      
      This will ensure that all CPUs will access all the banks that are
      visible to them. A CPU that can access fewer than the max number of
      banks will find the registers of the extra banks to be read-as-zero.
      
      Furthermore, print the resulting number of MCA banks in use. Do this in
      mcheck_late_init() so that the final value is printed after all CPUs
      have been initialized.
      
      Finally, get bank count from target CPU when doing injection with mce-inject
      module.
      
       [ bp: Remove out-of-bounds example, passify and cleanup commit message. ]
      Signed-off-by: default avatarYazen Ghannam <yazen.ghannam@amd.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: Pu Wen <puwen@hygon.cn>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vishal Verma <vishal.l.verma@intel.com>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20180727214009.78289-1-Yazen.Ghannam@amd.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      776613c5
    • Paul E. McKenney's avatar
      rcutorture: Fix cleanup path for invalid torture_type strings · f55e548f
      Paul E. McKenney authored
      [ Upstream commit b813afae ]
      
      If the specified rcutorture.torture_type is not in the rcu_torture_init()
      function's torture_ops[] array, rcutorture prints some console messages
      and then invokes rcu_torture_cleanup() to set state so that a future
      torture test can run.  However, rcu_torture_cleanup() also attempts to
      end the test that didn't actually start, and in doing so relies on the
      value of cur_ops, a value that is not particularly relevant in this case.
      This can result in confusing output or even follow-on failures due to
      attempts to use facilities that have not been properly initialized.
      
      This commit therefore sets the value of cur_ops to NULL in this case
      and inserts a check near the beginning of rcu_torture_cleanup(),
      thus avoiding relying on an irrelevant cur_ops value.
      Reported-by: default avatarkernel test robot <rong.a.chen@intel.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.ibm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f55e548f
    • Tony Luck's avatar
      x86/mce: Fix machine_check_poll() tests for error types · 34315916
      Tony Luck authored
      [ Upstream commit f19501aa ]
      
      There has been a lurking "TBD" in the machine check poll routine ever
      since it was first split out from the machine check handler. The
      potential issue is that the poll routine may have just begun a read from
      the STATUS register in a machine check bank when the hardware logs an
      error in that bank and signals a machine check.
      
      That race used to be pretty small back when machine checks were
      broadcast, but the addition of local machine check means that the poll
      code could continue running and clear the error from the bank before the
      local machine check handler on another CPU gets around to reading it.
      
      Fix the code to be sure to only process errors that need to be processed
      in the poll code, leaving other logged errors alone for the machine
      check handler to find and process.
      
       [ bp: Massage a bit and flip the "== 0" check to the usual !(..) test. ]
      
      Fixes: b79109c3 ("x86, mce: separate correct machine check poller and fatal exception handler")
      Fixes: ed7290d0 ("x86, mce: implement new status bits")
      Reported-by: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86-ml <x86@kernel.org>
      Cc: Yazen Ghannam <Yazen.Ghannam@amd.com>
      Link: https://lkml.kernel.org/r/20190312170938.GA23035@agluck-deskSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      34315916
    • Leon Romanovsky's avatar
      overflow: Fix -Wtype-limits compilation warnings · a3d4afff
      Leon Romanovsky authored
      [ Upstream commit dc7fe518 ]
      
      Attempt to use check_shl_overflow() with inputs of unsigned type
      produces the following compilation warnings.
      
      drivers/infiniband/hw/mlx5/qp.c: In function _set_user_rq_size_:
      ./include/linux/overflow.h:230:6: warning: comparison of unsigned
      expression >= 0 is always true [-Wtype-limits]
         _s >= 0 && _s < 8 * sizeof(*d) ? _s : 0;  \
            ^~
      drivers/infiniband/hw/mlx5/qp.c:5820:6: note: in expansion of macro _check_shl_overflow_
        if (check_shl_overflow(rwq->wqe_count, rwq->wqe_shift,
      &rwq->buf_size))
            ^~~~~~~~~~~~~~~~~~
      ./include/linux/overflow.h:232:26: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
        (_to_shift != _s || *_d < 0 || _a < 0 ||   \
                                ^
      drivers/infiniband/hw/mlx5/qp.c:5820:6: note: in expansion of macro _check_shl_overflow_
        if (check_shl_overflow(rwq->wqe_count, rwq->wqe_shift, &rwq->buf_size))
            ^~~~~~~~~~~~~~~~~~
      ./include/linux/overflow.h:232:36: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
        (_to_shift != _s || *_d < 0 || _a < 0 ||   \
                                          ^
      drivers/infiniband/hw/mlx5/qp.c:5820:6: note: in expansion of macro _check_shl_overflow_
        if (check_shl_overflow(rwq->wqe_count, rwq->wqe_shift,&rwq->buf_size))
            ^~~~~~~~~~~~~~~~~~
      
      Fixes: 0c668477 ("overflow.h: Add arithmetic shift helper")
      Reviewed-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a3d4afff
    • George Hilliard's avatar
      staging: mt7621-mmc: Initialize completions a single time during probe · a36c3c66
      George Hilliard authored
      [ Upstream commit 7ca8c2c8 ]
      
      The module was initializing completions whenever it was going to wait on
      them, and not when the completion was allocated.  This is incorrect
      according to the completion docs:
      
          Calling init_completion() on the same completion object twice is
          most likely a bug [...]
      
      Re-initialization is also unnecessary because the module never uses
      complete_all().  Fix this by only ever initializing the completion a
      single time, and log if the completions are not consumed as intended
      (this is not a fatal problem, but should not go unnoticed).
      Signed-off-by: default avatarGeorge Hilliard <thirtythreeforty@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a36c3c66
    • Kangjie Lu's avatar
      tty: ipwireless: fix missing checks for ioremap · a04b2936
      Kangjie Lu authored
      [ Upstream commit 1bbb1c31 ]
      
      ipw->attr_memory and ipw->common_memory are assigned with the
      return value of ioremap. ioremap may fail, but no checks
      are enforced. The fix inserts the checks to avoid potential
      NULL pointer dereferences.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a04b2936
    • Pankaj Gupta's avatar
      virtio_console: initialize vtermno value for ports · ddbc7bfa
      Pankaj Gupta authored
      [ Upstream commit 4b0a2c5f ]
      
      For regular serial ports we do not initialize value of vtermno
      variable. A garbage value is assigned for non console ports.
      The value can be observed as a random integer with [1].
      
      [1] vim /sys/kernel/debug/virtio-ports/vport*p*
      
      This patch initialize the value of vtermno for console serial
      ports to '1' and regular serial ports are initiaized to '0'.
      
      Reported-by: siliu@redhat.com
      Signed-off-by: default avatarPankaj Gupta <pagupta@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ddbc7bfa
    • Thierry Escande's avatar
      misc: fastrpc: Fix a possible double free · aaf5aa44
      Thierry Escande authored
      [ Upstream commit b49f6d83 ]
      
      This patch fixes the error exit path of fastrpc_init_create_process().
      If the DMA allocation or the DSP invoke fails the fastrpc_map was freed
      but not removed from the mapping list leading to a double free once the
      mapping list is emptied in fastrpc_device_release().
      
      [srinivas kandagatla]: Cleaned up error path labels and reset init mem
      to NULL after free
      Fixes: d73f71c7("misc: fastrpc: Add support for create remote init process")
      Signed-off-by: default avatarThierry Escande <thierry.escande@linaro.org>
      Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      aaf5aa44
    • Srinivas Kandagatla's avatar
      misc: fastrpc: make sure memory read and writes are visible · 8b29b2bf
      Srinivas Kandagatla authored
      [ Upstream commit 415a0729 ]
      
      dma_alloc_coherent buffers could have writes queued in store buffers so
      commit them before sending buffer to DSP using correct dma barriers.
      Same with vice-versa.
      
      Fixes: c68cfb71 ("misc: fastrpc: Add support for context Invoke method")
      Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8b29b2bf
    • Srinivas Kandagatla's avatar
      misc: fastrpc: consider address offset before sending to DSP · 954edc46
      Srinivas Kandagatla authored
      [ Upstream commit 80f3afd7 ]
      
      While passing address phy address to DSP, take care of the offset
      calculated from virtual address vma.
      
      Fixes: c68cfb71 ("misc: fastrpc: Add support for context Invoke method")
      Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      954edc46
    • Chad Dupuis's avatar
      scsi: qedf: Add missing return in qedf_post_io_req() in the fcport offload check · 9b1ce019
      Chad Dupuis authored
      [ Upstream commit c5e06ba2 ]
      
      Fixes the following crash as the return was missing from the check if an
      fcport is offloaded. If we hit this code we continue to try to post an
      invalid task which can lead to the crash:
      
      [30259.616411] [0000:61:00.3]:[qedf_post_io_req:989]:3: Session not offloaded yet.
      [30259.616413] [0000:61:00.3]:[qedf_upload_connection:1340]:3: Uploading connection port_id=490020.
      [30259.623769] BUG: unable to handle kernel NULL pointer dereference at 0000000000000198
      [30259.631645] IP: [<ffffffffc035b1ed>] qedf_init_task.isra.16+0x3d/0x450 [qedf]
      [30259.638816] PGD 0
      [30259.640841] Oops: 0000 [#1] SMP
      [30259.644098] Modules linked in: fuse xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables devlink ip6table_filter ip6_tables iptable_filter vfat fat ib_isert iscsi_target_mod ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib ib_ucm ib_umad dm_service_time skx_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel rpcrdma sunrpc rdma_ucm ib_uverbs lrw gf128mul ib_iser rdma_cm iw_cm ib_cm libiscsi scsi_transport_iscsi qedr(OE) glue_helper ablk_helper cryptd ib_core dm_round_robin joydev pcspkr ipmi_ssif ses enclosure ipmi_si ipmi_devintf ipmi_msghandler mei_me
      [30259.715529]  mei sg hpilo hpwdt shpchp wmi lpc_ich acpi_power_meter dm_multipath ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic uas usb_storage mgag200 qedf(OE) i2c_algo_bit libfcoe drm_kms_helper libfc syscopyarea sysfillrect scsi_transport_fc qede(OE) sysimgblt fb_sys_fops ptp ttm pps_core drm qed(OE) smartpqi crct10dif_pclmul crct10dif_common crc32c_intel i2c_core scsi_transport_sas scsi_tgt dm_mirror dm_region_hash dm_log dm_mod
      [30259.754237] CPU: 9 PID: 977 Comm: kdmwork-253:7 Kdump: loaded Tainted: G        W  OE  ------------   3.10.0-862.el7.x86_64 #1
      [30259.765664] Hardware name: HPE Synergy 480 Gen10/Synergy 480 Gen10 Compute Module, BIOS I42 04/04/2018
      [30259.775000] task: ffff8c801efd0000 ti: ffff8c801efd8000 task.ti: ffff8c801efd8000
      [30259.782505] RIP: 0010:[<ffffffffc035b1ed>]  [<ffffffffc035b1ed>] qedf_init_task.isra.16+0x3d/0x450 [qedf]
      [30259.792116] RSP: 0018:ffff8c801efdbbb0  EFLAGS: 00010046
      [30259.797444] RAX: 0000000000000000 RBX: ffffa7f1450948d8 RCX: ffff8c7fe5bc40c8
      [30259.804600] RDX: ffff8c800715b300 RSI: ffffa7f1450948d8 RDI: ffff8c80169c2480
      [30259.811755] RBP: ffff8c801efdbc30 R08: 00000000000000ae R09: ffff8c800a314540
      [30259.818911] R10: ffff8c7fe5bc40c8 R11: ffff8c801efdb8ae R12: 0000000000000000
      [30259.826068] R13: ffff8c800715b300 R14: ffff8c80169c2480 R15: ffff8c8005da28e0
      [30259.833223] FS:  0000000000000000(0000) GS:ffff8c803f840000(0000) knlGS:0000000000000000
      [30259.841338] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [30259.847100] CR2: 0000000000000198 CR3: 000000081242e000 CR4: 00000000007607e0
      [30259.854256] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [30259.861412] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [30259.868568] PKRU: 00000000
      [30259.871278] Call Trace:
      [30259.873737]  [<ffffffffc035c948>] qedf_post_io_req+0x148/0x680 [qedf]
      [30259.880201]  [<ffffffffc035d070>] qedf_queuecommand+0x1f0/0x240 [qedf]
      [30259.886749]  [<ffffffffa329b050>] scsi_dispatch_cmd+0xb0/0x240
      [30259.892600]  [<ffffffffa32a45bc>] scsi_request_fn+0x4cc/0x680
      [30259.898364]  [<ffffffffa3118ad9>] __blk_run_queue+0x39/0x50
      [30259.903954]  [<ffffffffa3114393>] __elv_add_request+0xd3/0x260
      [30259.909805]  [<ffffffffa311baf0>] blk_insert_cloned_request+0xf0/0x1b0
      [30259.916358]  [<ffffffffc010b622>] map_request+0x142/0x220 [dm_mod]
      [30259.922560]  [<ffffffffc010b716>] map_tio_request+0x16/0x40 [dm_mod]
      [30259.928932]  [<ffffffffa2ebb1f5>] kthread_worker_fn+0x85/0x180
      [30259.934782]  [<ffffffffa2ebb170>] ? kthread_stop+0xf0/0xf0
      [30259.940284]  [<ffffffffa2ebae31>] kthread+0xd1/0xe0
      [30259.945176]  [<ffffffffa2ebad60>] ? insert_kthread_work+0x40/0x40
      [30259.951290]  [<ffffffffa351f61d>] ret_from_fork_nospec_begin+0x7/0x21
      [30259.957750]  [<ffffffffa2ebad60>] ? insert_kthread_work+0x40/0x40
      [30259.963860] Code: fe 41 55 49 89 d5 41 54 53 48 89 f3 48 83 ec 58 4c 8b 67 28 4c 8b 4e 18 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 4c 8b 7e 58 <49> 8b 84 24 98 01 00 00 48 8b 00 f6 80 31 01 00 00 10 0f 85 0b
      [30259.983372] RIP  [<ffffffffc035b1ed>] qedf_init_task.isra.16+0x3d/0x450 [qedf]
      [30259.990630]  RSP <ffff8c801efdbbb0>
      [30259.994127] CR2: 0000000000000198
      Signed-off-by: default avatarChad Dupuis <cdupuis@marvell.com>
      Signed-off-by: default avatarSaurav Kashyap <skashyap@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9b1ce019
    • Artemy Kovalyov's avatar
      IB/mlx5: Compare only index part of a memory window rkey · 1a2fdf1c
      Artemy Kovalyov authored
      [ Upstream commit d623dfd2 ]
      
      The InfiniBand Architecture Specification section 10.6.7.2.4 TYPE 2 MEMORY
      WINDOWS says that if the CI supports the Base Memory Management Extensions
      defined in this specification, the R_Key format for a Type 2 Memory Window
      must consist of:
      
      * 24 bit index in the most significant bits of the R_Key, which is owned
        by the CI, and
      * 8 bit key in the least significant bits of the R_Key, which is owned by
        the Consumer.
      
      This means that the kernel should compare only the index part of a R_Key
      to determine equality with another R_Key.
      
      Fixes: db570d7d ("IB/mlx5: Add ODP support to MW")
      Signed-off-by: default avatarArtemy Kovalyov <artemyko@mellanox.com>
      Signed-off-by: default avatarMoni Shoua <monis@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1a2fdf1c
    • Thomas Gleixner's avatar
      timekeeping: Force upper bound for setting CLOCK_REALTIME · 5e04fcba
      Thomas Gleixner authored
      [ Upstream commit 7a8e61f8 ]
      
      Several people reported testing failures after setting CLOCK_REALTIME close
      to the limits of the kernel internal representation in nanoseconds,
      i.e. year 2262.
      
      The failures are exposed in subsequent operations, i.e. when arming timers
      or when the advancing CLOCK_MONOTONIC makes the calculation of
      CLOCK_REALTIME overflow into negative space.
      
      Now people start to paper over the underlying problem by clamping
      calculations to the valid range, but that's just wrong because such
      workarounds will prevent detection of real issues as well.
      
      It is reasonable to force an upper bound for the various methods of setting
      CLOCK_REALTIME. Year 2262 is the absolute upper bound. Assume a maximum
      uptime of 30 years which is plenty enough even for esoteric embedded
      systems. That results in an upper bound of year 2232 for setting the time.
      
      Once that limit is reached in reality this limit is only a small part of
      the problem space. But until then this stops people from trying to paper
      over the problem at the wrong places.
      Reported-by: default avatarXiongfeng Wang <wangxiongfeng2@huawei.com>
      Reported-by: default avatarHongbo Yao <yaohongbo@huawei.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Stephen Boyd <sboyd@kernel.org>
      Cc: Miroslav Lichvar <mlichvar@redhat.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1903231125480.2157@nanos.tec.linutronix.deSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      5e04fcba
    • Laurent Pinchart's avatar
      drm: rcar-du: lvds: Fix post-DLL divider calculation · 6eb883c4
      Laurent Pinchart authored
      [ Upstream commit 167e5354 ]
      
      The PLL parameters are computed by looping over the range of acceptable
      M, N and E values, and selecting the combination that produces the
      output frequency closest to the target. The internal frequency
      constraints are taken into account by restricting the tested values for
      the PLL parameters, reducing the search space. The target frequency,
      however, is only taken into account when computing the post-PLL divider,
      which can result in a 0 value for the divider when the PLL output
      frequency being tested is lower than half of the target frequency.
      Subsequent loops will produce a better set of PLL parameters, but for
      some of the iterations this can result in a division by 0.
      
      Fix it by clamping the divider value. We could instead restrict the E
      values being tested in the inner loop, but that would require additional
      calculation that would likely be less efficient as the E parameter can
      only take three different values.
      
      Fixes: c25c0136 ("drm: rcar-du: lvds: D3/E3 support")
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Reviewed-by: default avatarKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6eb883c4
    • Laurent Pinchart's avatar
      drm: rcar-du: lvds: Set LVEN and LVRES bits together on D3 · 7beeeb71
      Laurent Pinchart authored
      [ Upstream commit 00d082cc ]
      
      On the D3 SoC the LVDS PHY must be enabled in the same register write
      that enables the LVDS output. Skip writing the LVEN bit independently
      on that platform, it will be set by the write that sets LVRES.
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Reviewed-by: default avatarJacopo Mondi <jacopo+renesas@jmondi.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7beeeb71
    • Aditya Pakki's avatar
      thunderbolt: Fix to check the return value of kmemdup · fffcfb22
      Aditya Pakki authored
      [ Upstream commit fd21b79e ]
      
      uuid in add_switch is allocted via kmemdup which can fail. The patch
      logs the error and cleans up the allocated memory for switch.
      Signed-off-by: default avatarAditya Pakki <pakki001@umn.edu>
      Reviewed-by: default avatarMukesh Ojha <mojha@codeaurora.org>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fffcfb22
    • Kangjie Lu's avatar
      thunderbolt: property: Fix a missing check of kzalloc · f0cc2ffb
      Kangjie Lu authored
      [ Upstream commit 6183d5a5 ]
      
      No check is enforced for the return value of kzalloc,
      which may lead to NULL-pointer dereference.
      
      The patch fixes this issue.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Reviewed-by: default avatarMukesh Ojha <mojha@codeaurora.org>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f0cc2ffb
    • Alexandre Courbot's avatar
      media: mtk-vcodec: fix access to incorrect planes member · d1d090c4
      Alexandre Courbot authored
      [ Upstream commit 52fafc58 ]
      
      Commit 0650a914 ("media: mtk-vcodec: Correct return type for mem2mem
      buffer helpers") fixed the return types for mem2mem buffer helper
      functions by changing a few local variables from vb2_buffer to
      vb2_v4l2_buffer. However, it left a few accesses to vb2_buffer::planes
      as-is, accidentally turning them into accesses to
      vb2_v4l2_buffer::planes and resulting in values being read from/written
      to the wrong place.
      
      Fix this by inserting vb2_buf into these accesses so they mimic their
      original behavior.
      
      Fixes: 0650a914 ("media: mtk-vcodec: Correct return type for mem2mem buffer helpers")
      Signed-off-by: default avatarAlexandre Courbot <acourbot@chromium.org>
      Reviewed-by: default avatarEzequiel Garcia <ezequiel@collabora.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d1d090c4
    • Ard Biesheuvel's avatar
      efifb: Omit memory map check on legacy boot · 44f212eb
      Ard Biesheuvel authored
      [ Upstream commit c2999c28 ]
      
      Since the following commit:
      
        38ac0287 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB")
      
      efifb_probe() checks its memory range via efi_mem_desc_lookup(),
      and this leads to a spurious error message:
      
         EFI_MEMMAP is not enabled
      
      at every boot on KVM.  This is quite annoying since the error message
      appears even if you set "quiet" boot option.
      
      Since this happens on legacy boot, which strangely enough exposes
      a EFI framebuffer via screen_info, let's double check that we are
      doing an EFI boot before attempting to access the EFI memory map.
      Reported-by: default avatarTakashi Iwai <tiwai@suse.de>
      Tested-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20190328193429.21373-3-ard.biesheuvel@linaro.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      44f212eb