1. 13 Dec, 2018 40 commits
    • Pan Bian's avatar
      iommu/vt-d: Use memunmap to free memremap · 91da119b
      Pan Bian authored
      [ Upstream commit 829383e183728dec7ed9150b949cd6de64127809 ]
      
      memunmap() should be used to free the return of memremap(), not
      iounmap().
      
      Fixes: dfddb969 ('iommu/vt-d: Switch from ioremap_cache to memremap')
      Signed-off-by: default avatarPan Bian <bianpan2016@163.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      91da119b
    • Vincent Chen's avatar
      net: faraday: ftmac100: remove netif_running(netdev) check before disabling interrupts · 5b1c8d0b
      Vincent Chen authored
      [ Upstream commit 426a593e641ebf0d9288f0a2fcab644a86820220 ]
      
      In the original ftmac100_interrupt(), the interrupts are only disabled when
      the condition "netif_running(netdev)" is true. However, this condition
      causes kerenl hang in the following case. When the user requests to
      disable the network device, kernel will clear the bit __LINK_STATE_START
      from the dev->state and then call the driver's ndo_stop function. Network
      device interrupts are not blocked during this process. If an interrupt
      occurs between clearing __LINK_STATE_START and stopping network device,
      kernel cannot disable the interrupts due to the condition
      "netif_running(netdev)" in the ISR. Hence, kernel will hang due to the
      continuous interruption of the network device.
      
      In order to solve the above problem, the interrupts of the network device
      should always be disabled in the ISR without being restricted by the
      condition "netif_running(netdev)".
      
      [V2]
      Remove unnecessary curly braces.
      Signed-off-by: default avatarVincent Chen <vincentc@andestech.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5b1c8d0b
    • Aya Levin's avatar
      net/mlx4: Fix UBSAN warning of signed integer overflow · dd3fa93c
      Aya Levin authored
      [ Upstream commit a463146e67c848cbab5ce706d6528281b7cded08 ]
      
      UBSAN: Undefined behavior in
      drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:626:29
      signed integer overflow: 1802201963 + 1802201963 cannot be represented
      in type 'int'
      
      The union of res_reserved and res_port_rsvd[MLX4_MAX_PORTS] monitors
      granting of reserved resources. The grant operation is calculated and
      protected, thus both members of the union cannot be negative.  Changed
      type of res_reserved and of res_port_rsvd[MLX4_MAX_PORTS] from signed
      int to unsigned int, allowing large value.
      
      Fixes: 5a0d0a61 ("mlx4: Structures and init/teardown for VF resource quotas")
      Signed-off-by: default avatarAya Levin <ayal@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dd3fa93c
    • Tariq Toukan's avatar
      net/mlx4_core: Fix uninitialized variable compilation warning · ebf371aa
      Tariq Toukan authored
      [ Upstream commit 3ea7e7ea53c9f6ee41cb69a29c375fe9dd9a56a7 ]
      
      Initialize the uid variable to zero to avoid the compilation warning.
      
      Fixes: 7a89399f ("net/mlx4: Add mlx4_bitmap zone allocator")
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ebf371aa
    • Jack Morgenstein's avatar
      net/mlx4_core: Zero out lkey field in SW2HW_MPT fw command · 3adf0b7f
      Jack Morgenstein authored
      [ Upstream commit bd85fbc2038a1bbe84990b23ff69b6fc81a32b2c ]
      
      When re-registering a user mr, the mpt information for the
      existing mr when running SRIOV is obtained via the QUERY_MPT
      fw command. The returned information includes the mpt's lkey.
      
      This retrieved mpt information is used to move the mpt back
      to hardware ownership in the rereg flow (via the SW2HW_MPT
      fw command when running SRIOV).
      
      The fw API spec states that for SW2HW_MPT, the lkey field
      must be zero. Any ConnectX-3 PF driver which checks for strict spec
      adherence will return failure for SW2HW_MPT if the lkey field is not
      zero (although the fw in practice ignores this field for SW2HW_MPT).
      
      Thus, in order to conform to the fw API spec, set the lkey field to zero
      before invoking SW2HW_MPT when running SRIOV.
      
      Fixes: e630664c ("mlx4_core: Add helper functions to support MR re-registration")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3adf0b7f
    • Denis Bolotin's avatar
      qed: Fix reading wrong value in loop condition · 93940a27
      Denis Bolotin authored
      [ Upstream commit ed4eac20dcffdad47709422e0cb925981b056668 ]
      
      The value of "sb_index" is written by the hardware. Reading its value and
      writing it to "index" must finish before checking the loop condition.
      Signed-off-by: default avatarDenis Bolotin <denis.bolotin@cavium.com>
      Signed-off-by: default avatarMichal Kalderon <michal.kalderon@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      93940a27
    • Denis Bolotin's avatar
      qed: Fix PTT leak in qed_drain() · 30d5a7c1
      Denis Bolotin authored
      [ Upstream commit 9aaa4e8ba12972d674caeefbc5f88d83235dd697 ]
      
      Release PTT before entering error flow.
      Signed-off-by: default avatarDenis Bolotin <denis.bolotin@cavium.com>
      Signed-off-by: default avatarMichal Kalderon <michal.kalderon@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      30d5a7c1
    • Sudarsana Reddy Kalluru's avatar
      bnx2x: Assign unique DMAE channel number for FW DMAE transactions. · 61d221fc
      Sudarsana Reddy Kalluru authored
      [ Upstream commit 77e461d14ed141253573eeeb4d34eccc51e38328 ]
      
      Driver assigns DMAE channel 0 for FW as part of START_RAMROD command. FW
      uses this channel for DMAE operations (e.g., TIME_SYNC implementation).
      Driver also uses the same channel 0 for DMAE operations for some of the PFs
      (e.g., PF0 on Port0). This could lead to concurrent access to the DMAE
      channel by FW and driver which is not legal. Hence need to assign unique
      DMAE id for FW.
      Currently following DMAE channels are used by the clients,
        MFW - OCBB/OCSD functionality uses DMAE channel 14/15
        Driver 0-3 and 8-11 (for PF dmae operations)
               4 and 12 (for stats requests)
      Assigning unique dmae_id '13' to the FW.
      
      Changes from previous version:
      ------------------------------
      v2: Incorporated the review comments.
      Signed-off-by: default avatarSudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
      Signed-off-by: default avatarMichal Kalderon <Michal.Kalderon@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      61d221fc
    • Sven Eckelmann's avatar
      batman-adv: Expand merged fragment buffer for full packet · 497b7ca0
      Sven Eckelmann authored
      [ Upstream commit d7d8bbb40a5b1f682ee6589e212934f4c6b8ad60 ]
      
      The complete size ("total_size") of the fragmented packet is stored in the
      fragment header and in the size of the fragment chain. When the fragments
      are ready for merge, the skbuff's tail of the first fragment is expanded to
      have enough room after the data pointer for at least total_size. This means
      that it gets expanded by total_size - first_skb->len.
      
      But this is ignoring the fact that after expanding the buffer, the fragment
      header is pulled by from this buffer. Assuming that the tailroom of the
      buffer was already 0, the buffer after the data pointer of the skbuff is
      now only total_size - len(fragment_header) large. When the merge function
      is then processing the remaining fragments, the code to copy the data over
      to the merged skbuff will cause an skb_over_panic when it tries to actually
      put enough data to fill the total_size bytes of the packet.
      
      The size of the skb_pull must therefore also be taken into account when the
      buffer's tailroom is expanded.
      
      Fixes: 610bfc6b ("batman-adv: Receive fragmented packets and merge")
      Reported-by: default avatarMartin Weinelt <martin@darmstadt.freifunk.net>
      Co-authored-by: default avatarLinus Lüssing <linus.luessing@c0d3.blue>
      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>
      497b7ca0
    • Fabrizio Castro's avatar
      can: rcar_can: Fix erroneous registration · 0cd96c4f
      Fabrizio Castro authored
      [ Upstream commit 68c8d209cd4337da4fa04c672f0b62bb735969bc ]
      
      Assigning 2 to "renesas,can-clock-select" tricks the driver into
      registering the CAN interface, even though we don't want that.
      This patch improves one of the checks to prevent that from happening.
      
      Fixes: 862e2b6a ("can: rcar_can: support all input clocks")
      Signed-off-by: default avatarFabrizio Castro <fabrizio.castro@bp.renesas.com>
      Signed-off-by: default avatarChris Paterson <Chris.Paterson2@renesas.com>
      Reviewed-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0cd96c4f
    • Geert Uytterhoeven's avatar
      iommu/ipmmu-vmsa: Fix crash on early domain free · 0ebb9269
      Geert Uytterhoeven authored
      [ Upstream commit e5b78f2e349eef5d4fca5dc1cf5a3b4b2cc27abd ]
      
      If iommu_ops.add_device() fails, iommu_ops.domain_free() is still
      called, leading to a crash, as the domain was only partially
      initialized:
      
          ipmmu-vmsa e67b0000.mmu: Cannot accommodate DMA translation for IOMMU page tables
          sata_rcar ee300000.sata: Unable to initialize IPMMU context
          iommu: Failed to add device ee300000.sata to group 0: -22
          Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038
          ...
          Call trace:
           ipmmu_domain_free+0x1c/0xa0
           iommu_group_release+0x48/0x68
           kobject_put+0x74/0xe8
           kobject_del.part.0+0x3c/0x50
           kobject_put+0x60/0xe8
           iommu_group_get_for_dev+0xa8/0x1f0
           ipmmu_add_device+0x1c/0x40
           of_iommu_configure+0x118/0x190
      
      Fix this by checking if the domain's context already exists, before
      trying to destroy it.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Fixes: d25a2a16 ('iommu: Add driver for Renesas VMSA-compatible IPMMU')
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0ebb9269
    • Lu Baolu's avatar
      iommu/vt-d: Fix NULL pointer dereference in prq_event_thread() · 96915a2f
      Lu Baolu authored
      [ Upstream commit 19ed3e2dd8549c1a34914e8dad01b64e7837645a ]
      
      When handling page request without pasid event, go to "no_pasid"
      branch instead of "bad_req". Otherwise, a NULL pointer deference
      will happen there.
      
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
      Cc: Sohil Mehta <sohil.mehta@intel.com>
      Signed-off-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Fixes: a222a7f0 'iommu/vt-d: Implement page request handling'
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      96915a2f
    • Arnd Bergmann's avatar
      usb: gadget: dummy: fix nonsensical comparisons · 43daa3c4
      Arnd Bergmann authored
      commit 7661ca09 upstream.
      
      gcc-8 points out two comparisons that are clearly bogus
      and almost certainly not what the author intended to write:
      
      drivers/usb/gadget/udc/dummy_hcd.c: In function 'set_link_state_by_speed':
      drivers/usb/gadget/udc/dummy_hcd.c:379:31: error: bitwise comparison always evaluates to false [-Werror=tautological-compare]
               USB_PORT_STAT_ENABLE) == 1 &&
                                     ^~
      drivers/usb/gadget/udc/dummy_hcd.c:381:25: error: bitwise comparison always evaluates to false [-Werror=tautological-compare]
            USB_SS_PORT_LS_U0) == 1 &&
                               ^~
      
      I looked at the code for a bit and came up with a change that makes
      it look like what the author probably meant here. This makes it
      look reasonable to me and to gcc, shutting up the warning.
      
      It does of course change behavior as the two conditions are actually
      evaluated rather than being hardcoded to false, and I have made no
      attempt at verifying that the changed logic makes sense in the context
      of a USB HCD, so that part needs to be reviewed carefully.
      
      Fixes: 1cd8fd28 ("usb: gadget: dummy_hcd: add SuperSpeed support")
      Cc: Tatyana Brokhman <tlinder@codeaurora.org>
      Cc: Felipe Balbi <balbi@kernel.org>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43daa3c4
    • Simon Guo's avatar
      mm: mlock: avoid increase mm->locked_vm on mlock() when already mlock2(,MLOCK_ONFAULT) · af70fc34
      Simon Guo authored
      commit b155b4fd upstream.
      
      When one vma was with flag VM_LOCKED|VM_LOCKONFAULT (by invoking
      mlock2(,MLOCK_ONFAULT)), it can again be populated with mlock() with
      VM_LOCKED flag only.
      
      There is a hole in mlock_fixup() which increase mm->locked_vm twice even
      the two operations are on the same vma and both with VM_LOCKED flags.
      
      The issue can be reproduced by following code:
      
        mlock2(p, 1024 * 64, MLOCK_ONFAULT); //VM_LOCKED|VM_LOCKONFAULT
        mlock(p, 1024 * 64);  //VM_LOCKED
      
      Then check the increase VmLck field in /proc/pid/status(to 128k).
      
      When vma is set with different vm_flags, and the new vm_flags is with
      VM_LOCKED, it is not necessarily be a "new locked" vma.  This patch
      corrects this bug by prevent mm->locked_vm from increment when old
      vm_flags is already VM_LOCKED.
      
      Link: http://lkml.kernel.org/r/1472554781-9835-3-git-send-email-wei.guo.simon@gmail.comSigned-off-by: default avatarSimon Guo <wei.guo.simon@gmail.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Alexey Klimov <klimov.linux@gmail.com>
      Cc: Eric B Munson <emunson@akamai.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Simon Guo <wei.guo.simon@gmail.com>
      Cc: Thierry Reding <treding@nvidia.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Rafael David Tinoco <rafael.tinoco@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af70fc34
    • Pavel Tikhomirov's avatar
      mm: cleancache: fix corruption on missed inode invalidation · 78b572c9
      Pavel Tikhomirov authored
      commit 6ff38bd40230af35e446239396e5fc8ebd6a5248 upstream.
      
      If all pages are deleted from the mapping by memory reclaim and also
      moved to the cleancache:
      
      __delete_from_page_cache
        (no shadow case)
        unaccount_page_cache_page
          cleancache_put_page
        page_cache_delete
          mapping->nrpages -= nr
          (nrpages becomes 0)
      
      We don't clean the cleancache for an inode after final file truncation
      (removal).
      
      truncate_inode_pages_final
        check (nrpages || nrexceptional) is false
          no truncate_inode_pages
            no cleancache_invalidate_inode(mapping)
      
      These way when reading the new file created with same inode we may get
      these trash leftover pages from cleancache and see wrong data instead of
      the contents of the new file.
      
      Fix it by always doing truncate_inode_pages which is already ready for
      nrpages == 0 && nrexceptional == 0 case and just invalidates inode.
      
      [akpm@linux-foundation.org: add comment, per Jan]
      Link: http://lkml.kernel.org/r/20181112095734.17979-1-ptikhomirov@virtuozzo.com
      Fixes: commit 91b0abe3 ("mm + fs: store shadow entries in page cache")
      Signed-off-by: default avatarPavel Tikhomirov <ptikhomirov@virtuozzo.com>
      Reviewed-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Reviewed-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      78b572c9
    • Alexey Brodkin's avatar
      arc: [devboards] Add support of NFSv3 ACL · 4d0afb8b
      Alexey Brodkin authored
      commit 6b04114f6fae5e84d33404c2970b1949c032546e upstream.
      
      By default NFSv3 doesn't support ACL (Access Control Lists)
      which might be quite convenient to have so that
      mounted NFS behaves exactly as any other local file-system.
      
      In particular missing support of ACL makes umask useless.
      This among other thigs fixes Glibc's "nptl/tst-umask1".
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Cc: Cupertino Miranda <cmiranda@synopsys.com>
      Cc: stable@vger.kernel.org	#4.14+
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d0afb8b
    • Kevin Hilman's avatar
      ARC: change defconfig defaults to ARCv2 · d473a00b
      Kevin Hilman authored
      commit b7cc40c32a8bfa6f2581a71747f6a7d491fe43ba upstream.
      
      Change the default defconfig (used with 'make defconfig') to the ARCv2
      nsim_hs_defconfig, and also switch the default Kconfig ISA selection to
      ARCv2.
      
      This allows several default defconfigs (e.g. make defconfig, make
      allnoconfig, make tinyconfig) to all work with ARCv2 by default.
      
      Note since we change default architecture from ARCompact to ARCv2
      it's required to explicitly mention architecture type in ARCompact
      defconfigs otherwise ARCv2 will be implied and binaries will be
      generated for ARCv2.
      
      Cc: <stable@vger.kernel.org> # 4.4.x
      Signed-off-by: default avatarKevin Hilman <khilman@baylibre.com>
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d473a00b
    • Filipe Manana's avatar
      Btrfs: fix use-after-free when dumping free space · f43cae2c
      Filipe Manana authored
      commit 9084cb6a24bf5838a665af92ded1af8363f9e563 upstream.
      
      We were iterating a block group's free space cache rbtree without locking
      first the lock that protects it (the free_space_ctl->free_space_offset
      rbtree is protected by the free_space_ctl->tree_lock spinlock).
      
      KASAN reported an use-after-free problem when iterating such a rbtree due
      to a concurrent rbtree delete:
      
      [ 9520.359168] ==================================================================
      [ 9520.359656] BUG: KASAN: use-after-free in rb_next+0x13/0x90
      [ 9520.359949] Read of size 8 at addr ffff8800b7ada500 by task btrfs-transacti/1721
      [ 9520.360357]
      [ 9520.360530] CPU: 4 PID: 1721 Comm: btrfs-transacti Tainted: G             L    4.19.0-rc8-nbor #555
      [ 9520.360990] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      [ 9520.362682] Call Trace:
      [ 9520.362887]  dump_stack+0xa4/0xf5
      [ 9520.363146]  print_address_description+0x78/0x280
      [ 9520.363412]  kasan_report+0x263/0x390
      [ 9520.363650]  ? rb_next+0x13/0x90
      [ 9520.363873]  __asan_load8+0x54/0x90
      [ 9520.364102]  rb_next+0x13/0x90
      [ 9520.364380]  btrfs_dump_free_space+0x146/0x160 [btrfs]
      [ 9520.364697]  dump_space_info+0x2cd/0x310 [btrfs]
      [ 9520.364997]  btrfs_reserve_extent+0x1ee/0x1f0 [btrfs]
      [ 9520.365310]  __btrfs_prealloc_file_range+0x1cc/0x620 [btrfs]
      [ 9520.365646]  ? btrfs_update_time+0x180/0x180 [btrfs]
      [ 9520.365923]  ? _raw_spin_unlock+0x27/0x40
      [ 9520.366204]  ? btrfs_alloc_data_chunk_ondemand+0x2c0/0x5c0 [btrfs]
      [ 9520.366549]  btrfs_prealloc_file_range_trans+0x23/0x30 [btrfs]
      [ 9520.366880]  cache_save_setup+0x42e/0x580 [btrfs]
      [ 9520.367220]  ? btrfs_check_data_free_space+0xd0/0xd0 [btrfs]
      [ 9520.367518]  ? lock_downgrade+0x2f0/0x2f0
      [ 9520.367799]  ? btrfs_write_dirty_block_groups+0x11f/0x6e0 [btrfs]
      [ 9520.368104]  ? kasan_check_read+0x11/0x20
      [ 9520.368349]  ? do_raw_spin_unlock+0xa8/0x140
      [ 9520.368638]  btrfs_write_dirty_block_groups+0x2af/0x6e0 [btrfs]
      [ 9520.368978]  ? btrfs_start_dirty_block_groups+0x870/0x870 [btrfs]
      [ 9520.369282]  ? do_raw_spin_unlock+0xa8/0x140
      [ 9520.369534]  ? _raw_spin_unlock+0x27/0x40
      [ 9520.369811]  ? btrfs_run_delayed_refs+0x1b8/0x230 [btrfs]
      [ 9520.370137]  commit_cowonly_roots+0x4b9/0x610 [btrfs]
      [ 9520.370560]  ? commit_fs_roots+0x350/0x350 [btrfs]
      [ 9520.370926]  ? btrfs_run_delayed_refs+0x1b8/0x230 [btrfs]
      [ 9520.371285]  btrfs_commit_transaction+0x5e5/0x10e0 [btrfs]
      [ 9520.371612]  ? btrfs_apply_pending_changes+0x90/0x90 [btrfs]
      [ 9520.371943]  ? start_transaction+0x168/0x6c0 [btrfs]
      [ 9520.372257]  transaction_kthread+0x21c/0x240 [btrfs]
      [ 9520.372537]  kthread+0x1d2/0x1f0
      [ 9520.372793]  ? btrfs_cleanup_transaction+0xb50/0xb50 [btrfs]
      [ 9520.373090]  ? kthread_park+0xb0/0xb0
      [ 9520.373329]  ret_from_fork+0x3a/0x50
      [ 9520.373567]
      [ 9520.373738] Allocated by task 1804:
      [ 9520.373974]  kasan_kmalloc+0xff/0x180
      [ 9520.374208]  kasan_slab_alloc+0x11/0x20
      [ 9520.374447]  kmem_cache_alloc+0xfc/0x2d0
      [ 9520.374731]  __btrfs_add_free_space+0x40/0x580 [btrfs]
      [ 9520.375044]  unpin_extent_range+0x4f7/0x7a0 [btrfs]
      [ 9520.375383]  btrfs_finish_extent_commit+0x15f/0x4d0 [btrfs]
      [ 9520.375707]  btrfs_commit_transaction+0xb06/0x10e0 [btrfs]
      [ 9520.376027]  btrfs_alloc_data_chunk_ondemand+0x237/0x5c0 [btrfs]
      [ 9520.376365]  btrfs_check_data_free_space+0x81/0xd0 [btrfs]
      [ 9520.376689]  btrfs_delalloc_reserve_space+0x25/0x80 [btrfs]
      [ 9520.377018]  btrfs_direct_IO+0x42e/0x6d0 [btrfs]
      [ 9520.377284]  generic_file_direct_write+0x11e/0x220
      [ 9520.377587]  btrfs_file_write_iter+0x472/0xac0 [btrfs]
      [ 9520.377875]  aio_write+0x25c/0x360
      [ 9520.378106]  io_submit_one+0xaa0/0xdc0
      [ 9520.378343]  __se_sys_io_submit+0xfa/0x2f0
      [ 9520.378589]  __x64_sys_io_submit+0x43/0x50
      [ 9520.378840]  do_syscall_64+0x7d/0x240
      [ 9520.379081]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [ 9520.379387]
      [ 9520.379557] Freed by task 1802:
      [ 9520.379782]  __kasan_slab_free+0x173/0x260
      [ 9520.380028]  kasan_slab_free+0xe/0x10
      [ 9520.380262]  kmem_cache_free+0xc1/0x2c0
      [ 9520.380544]  btrfs_find_space_for_alloc+0x4cd/0x4e0 [btrfs]
      [ 9520.380866]  find_free_extent+0xa99/0x17e0 [btrfs]
      [ 9520.381166]  btrfs_reserve_extent+0xd5/0x1f0 [btrfs]
      [ 9520.381474]  btrfs_get_blocks_direct+0x60b/0xbd0 [btrfs]
      [ 9520.381761]  __blockdev_direct_IO+0x10ee/0x58a1
      [ 9520.382059]  btrfs_direct_IO+0x25a/0x6d0 [btrfs]
      [ 9520.382321]  generic_file_direct_write+0x11e/0x220
      [ 9520.382623]  btrfs_file_write_iter+0x472/0xac0 [btrfs]
      [ 9520.382904]  aio_write+0x25c/0x360
      [ 9520.383172]  io_submit_one+0xaa0/0xdc0
      [ 9520.383416]  __se_sys_io_submit+0xfa/0x2f0
      [ 9520.383678]  __x64_sys_io_submit+0x43/0x50
      [ 9520.383927]  do_syscall_64+0x7d/0x240
      [ 9520.384165]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [ 9520.384439]
      [ 9520.384610] The buggy address belongs to the object at ffff8800b7ada500
                      which belongs to the cache btrfs_free_space of size 72
      [ 9520.385175] The buggy address is located 0 bytes inside of
                      72-byte region [ffff8800b7ada500, ffff8800b7ada548)
      [ 9520.385691] The buggy address belongs to the page:
      [ 9520.385957] page:ffffea0002deb680 count:1 mapcount:0 mapping:ffff880108a1d700 index:0x0 compound_mapcount: 0
      [ 9520.388030] flags: 0x8100(slab|head)
      [ 9520.388281] raw: 0000000000008100 ffffea0002deb608 ffffea0002728808 ffff880108a1d700
      [ 9520.388722] raw: 0000000000000000 0000000000130013 00000001ffffffff 0000000000000000
      [ 9520.389169] page dumped because: kasan: bad access detected
      [ 9520.389473]
      [ 9520.389658] Memory state around the buggy address:
      [ 9520.389943]  ffff8800b7ada400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [ 9520.390368]  ffff8800b7ada480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [ 9520.390796] >ffff8800b7ada500: fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc
      [ 9520.391223]                    ^
      [ 9520.391461]  ffff8800b7ada580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [ 9520.391885]  ffff8800b7ada600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [ 9520.392313] ==================================================================
      [ 9520.392772] BTRFS critical (device vdc): entry offset 2258497536, bytes 131072, bitmap no
      [ 9520.393247] BUG: unable to handle kernel NULL pointer dereference at 0000000000000011
      [ 9520.393705] PGD 800000010dbab067 P4D 800000010dbab067 PUD 107551067 PMD 0
      [ 9520.394059] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [ 9520.394378] CPU: 4 PID: 1721 Comm: btrfs-transacti Tainted: G    B        L    4.19.0-rc8-nbor #555
      [ 9520.394858] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      [ 9520.395350] RIP: 0010:rb_next+0x3c/0x90
      [ 9520.396461] RSP: 0018:ffff8801074ff780 EFLAGS: 00010292
      [ 9520.396762] RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffffffff81b5ac4c
      [ 9520.397115] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 0000000000000011
      [ 9520.397468] RBP: ffff8801074ff7a0 R08: ffffed0021d64ccc R09: ffffed0021d64ccc
      [ 9520.397821] R10: 0000000000000001 R11: ffffed0021d64ccb R12: ffff8800b91e0000
      [ 9520.398188] R13: ffff8800a3ceba48 R14: ffff8800b627bf80 R15: 0000000000020000
      [ 9520.398555] FS:  0000000000000000(0000) GS:ffff88010eb00000(0000) knlGS:0000000000000000
      [ 9520.399007] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 9520.399335] CR2: 0000000000000011 CR3: 0000000106b52000 CR4: 00000000000006a0
      [ 9520.399679] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 9520.400023] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [ 9520.400400] Call Trace:
      [ 9520.400648]  btrfs_dump_free_space+0x146/0x160 [btrfs]
      [ 9520.400974]  dump_space_info+0x2cd/0x310 [btrfs]
      [ 9520.401287]  btrfs_reserve_extent+0x1ee/0x1f0 [btrfs]
      [ 9520.401609]  __btrfs_prealloc_file_range+0x1cc/0x620 [btrfs]
      [ 9520.401952]  ? btrfs_update_time+0x180/0x180 [btrfs]
      [ 9520.402232]  ? _raw_spin_unlock+0x27/0x40
      [ 9520.402522]  ? btrfs_alloc_data_chunk_ondemand+0x2c0/0x5c0 [btrfs]
      [ 9520.402882]  btrfs_prealloc_file_range_trans+0x23/0x30 [btrfs]
      [ 9520.403261]  cache_save_setup+0x42e/0x580 [btrfs]
      [ 9520.403570]  ? btrfs_check_data_free_space+0xd0/0xd0 [btrfs]
      [ 9520.403871]  ? lock_downgrade+0x2f0/0x2f0
      [ 9520.404161]  ? btrfs_write_dirty_block_groups+0x11f/0x6e0 [btrfs]
      [ 9520.404481]  ? kasan_check_read+0x11/0x20
      [ 9520.404732]  ? do_raw_spin_unlock+0xa8/0x140
      [ 9520.405026]  btrfs_write_dirty_block_groups+0x2af/0x6e0 [btrfs]
      [ 9520.405375]  ? btrfs_start_dirty_block_groups+0x870/0x870 [btrfs]
      [ 9520.405694]  ? do_raw_spin_unlock+0xa8/0x140
      [ 9520.405958]  ? _raw_spin_unlock+0x27/0x40
      [ 9520.406243]  ? btrfs_run_delayed_refs+0x1b8/0x230 [btrfs]
      [ 9520.406574]  commit_cowonly_roots+0x4b9/0x610 [btrfs]
      [ 9520.406899]  ? commit_fs_roots+0x350/0x350 [btrfs]
      [ 9520.407253]  ? btrfs_run_delayed_refs+0x1b8/0x230 [btrfs]
      [ 9520.407589]  btrfs_commit_transaction+0x5e5/0x10e0 [btrfs]
      [ 9520.407925]  ? btrfs_apply_pending_changes+0x90/0x90 [btrfs]
      [ 9520.408262]  ? start_transaction+0x168/0x6c0 [btrfs]
      [ 9520.408582]  transaction_kthread+0x21c/0x240 [btrfs]
      [ 9520.408870]  kthread+0x1d2/0x1f0
      [ 9520.409138]  ? btrfs_cleanup_transaction+0xb50/0xb50 [btrfs]
      [ 9520.409440]  ? kthread_park+0xb0/0xb0
      [ 9520.409682]  ret_from_fork+0x3a/0x50
      [ 9520.410508] Dumping ftrace buffer:
      [ 9520.410764]    (ftrace buffer empty)
      [ 9520.411007] CR2: 0000000000000011
      [ 9520.411297] ---[ end trace 01a0863445cf360a ]---
      [ 9520.411568] RIP: 0010:rb_next+0x3c/0x90
      [ 9520.412644] RSP: 0018:ffff8801074ff780 EFLAGS: 00010292
      [ 9520.412932] RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffffffff81b5ac4c
      [ 9520.413274] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 0000000000000011
      [ 9520.413616] RBP: ffff8801074ff7a0 R08: ffffed0021d64ccc R09: ffffed0021d64ccc
      [ 9520.414007] R10: 0000000000000001 R11: ffffed0021d64ccb R12: ffff8800b91e0000
      [ 9520.414349] R13: ffff8800a3ceba48 R14: ffff8800b627bf80 R15: 0000000000020000
      [ 9520.416074] FS:  0000000000000000(0000) GS:ffff88010eb00000(0000) knlGS:0000000000000000
      [ 9520.416536] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 9520.416848] CR2: 0000000000000011 CR3: 0000000106b52000 CR4: 00000000000006a0
      [ 9520.418477] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 9520.418846] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [ 9520.419204] Kernel panic - not syncing: Fatal exception
      [ 9520.419666] Dumping ftrace buffer:
      [ 9520.419930]    (ftrace buffer empty)
      [ 9520.420168] Kernel Offset: disabled
      [ 9520.420406] ---[ end Kernel panic - not syncing: Fatal exception ]---
      
      Fix this by acquiring the respective lock before iterating the rbtree.
      Reported-by: default avatarNikolay Borisov <nborisov@suse.com>
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Cc: Nikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f43cae2c
    • Nikolay Borisov's avatar
      btrfs: Always try all copies when reading extent buffers · 8732a2f4
      Nikolay Borisov authored
      commit f8397d69daef06d358430d3054662fb597e37c00 upstream.
      
      When a metadata read is served the endio routine btree_readpage_end_io_hook
      is called which eventually runs the tree-checker. If tree-checker fails
      to validate the read eb then it sets EXTENT_BUFFER_CORRUPT flag. This
      leads to btree_read_extent_buffer_pages wrongly assuming that all
      available copies of this extent buffer are wrong and failing prematurely.
      Fix this modify btree_read_extent_buffer_pages to read all copies of
      the data.
      
      This failure was exhibitted in xfstests btrfs/124 which would
      spuriously fail its balance operations. The reason was that when balance
      was run following re-introduction of the missing raid1 disk
      __btrfs_map_block would map the read request to stripe 0, which
      corresponded to devid 2 (the disk which is being removed in the test):
      
          item 2 key (FIRST_CHUNK_TREE CHUNK_ITEM 3553624064) itemoff 15975 itemsize 112
      	length 1073741824 owner 2 stripe_len 65536 type DATA|RAID1
      	io_align 65536 io_width 65536 sector_size 4096
      	num_stripes 2 sub_stripes 1
      		stripe 0 devid 2 offset 2156920832
      		dev_uuid 8466c350-ed0c-4c3b-b17d-6379b445d5c8
      		stripe 1 devid 1 offset 3553624064
      		dev_uuid 1265d8db-5596-477e-af03-df08eb38d2ca
      
      This caused read requests for a checksum item that to be routed to the
      stale disk which triggered the aforementioned logic involving
      EXTENT_BUFFER_CORRUPT flag. This then triggered cascading failures of
      the balance operation.
      
      Fixes: a826d6dc ("Btrfs: check items for correctness as we search")
      CC: stable@vger.kernel.org # 4.4+
      Suggested-by: default avatarQu Wenruo <wqu@suse.com>
      Reviewed-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8732a2f4
    • Adam Wong's avatar
      Input: elan_i2c - add support for ELAN0621 touchpad · da74d33b
      Adam Wong authored
      commit bf87ade0dd7f8cf19dac4d3161d5e86abe0c062b upstream.
      
      Added the ability to detect the ELAN0621 touchpad found in some Lenovo
      laptops.
      Signed-off-by: default avatarAdam Wong <adam@adamwong.me>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      da74d33b
    • Noah Westervelt's avatar
      Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15ARR · 47c89da2
      Noah Westervelt authored
      commit ad33429cd02565c28404bb16ae7a4c2bdfda6626 upstream.
      
      Add ELAN061E to the ACPI table to support Elan touchpad found in Lenovo
      IdeaPad 330-15ARR.
      Signed-off-by: default avatarNoah Westervelt <nwestervelt@outlook.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      47c89da2
    • Patrick Gaskin's avatar
      Input: elan_i2c - add ELAN0620 to the ACPI table · 38c63d52
      Patrick Gaskin authored
      commit 3ed64da3b790be7c63601e8ca6341b7dff74a660 upstream.
      
      Add ELAN0620 to the ACPI table to support the elan touchpad in
      the Lenovo IdeaPad 130-15IKB.
      Signed-off-by: default avatarPatrick Gaskin <patrick@pgaskin.net>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      38c63d52
    • Christian Hoff's avatar
      Input: matrix_keypad - check for errors from of_get_named_gpio() · deae2217
      Christian Hoff authored
      commit d55bda1b3e7c5a87f10da54fdda866a9a9cef30b upstream.
      
      "of_get_named_gpio()" returns a negative error value if it fails
      and drivers should check for this. This missing check was now
      added to the matrix_keypad driver.
      
      In my case "of_get_named_gpio()" returned -EPROBE_DEFER because
      the referenced GPIOs belong to an I/O expander, which was not yet
      probed at the point in time when the matrix_keypad driver was
      loading. Because the driver did not check for errors from the
      "of_get_named_gpio()" routine, it was assuming that "-EPROBE_DEFER"
      is actually a GPIO number and continued as usual, which led to further
      errors like this later on:
      
      WARNING: CPU: 3 PID: 167 at drivers/gpio/gpiolib.c:114
      gpio_to_desc+0xc8/0xd0
      invalid GPIO -517
      
      Note that the "GPIO number" -517 in the error message above is
      actually "-EPROBE_DEFER".
      
      As part of the patch a misleading error message "no platform data defined"
      was also removed. This does not lead to information loss because the other
      error paths in matrix_keypad_parse_dt() already print an error.
      Signed-off-by: default avatarChristian Hoff <christian_hoff@gmx.net>
      Suggested-by: default avatarSebastian Reichel <sre@kernel.org>
      Reviewed-by: default avatarSebastian Reichel <sre@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      deae2217
    • Cameron Gutman's avatar
      Input: xpad - quirk all PDP Xbox One gamepads · f8414669
      Cameron Gutman authored
      commit a6754fae1e66e9a40fed406290d7ca3f2b4d227c upstream.
      
      Since we continue to find tons of new variants [0,1,2,3,4,5,6] that
      need the PDP quirk, let's just quirk all devices from PDP.
      
      [0]: https://github.com/paroj/xpad/pull/104
      [1]: https://github.com/paroj/xpad/pull/105
      [2]: https://github.com/paroj/xpad/pull/108
      [3]: https://github.com/paroj/xpad/pull/109
      [4]: https://github.com/paroj/xpad/pull/112
      [5]: https://github.com/paroj/xpad/pull/115
      [6]: https://github.com/paroj/xpad/pull/116
      
      Fixes: e5c9c6a8 ("Input: xpad - add support for PDP Xbox One controllers")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarCameron Gutman <aicommander@gmail.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f8414669
    • Wei Yongjun's avatar
      leds: leds-gpio: Fix return value check in create_gpio_led() · 0c4da5d2
      Wei Yongjun authored
      commit 2d88a331 upstream.
      
      In case of error, the function gpio_to_desc() returns NULL
      pointer not ERR_PTR(). The IS_ERR() test in the return value
      check should be replaced with NULL test.
      Signed-off-by: default avatarWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Signed-off-by: default avatarJacek Anaszewski <j.anaszewski@samsung.com>
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c4da5d2
    • Milo Kim's avatar
      leds: turn off the LED and wait for completion on unregistering LED class device · 5e946ed3
      Milo Kim authored
      commit d1aa577f upstream.
      
      Workqueue, 'set_brightness_work' is used for scheduling brightness control.
      This workqueue is canceled when the LED class device is unregistered.
      Currently, LED subsystem handles like below.
      
        cancel_work_sync(&led_cdev->set_brightness_work)
        led_set_brightness(led_cdev, LED_OFF)
      
      However, this could be a problem.
      Workqueue is going to be canceled but LED device needs to be off.
      The worst case is null pointer access due to scheduling a workqueue.
      
      LED module is loaded.
        LED driver private data is allocated by using devm_zalloc().
      
      LED module is unloaded.
        led_classdev_unregister() is called.
          cancel_work_sync()
            led_set_brightness(led_cdev, LED_OFF)
              schedule_work() if LED driver uses brightness_set_blocking()
              In the meantime, driver private data will be freed.
      
              ..scheduling..
      
              brightness_set_blocking() callback is invoked.
                For the brightness control, LED driver tries to access private
                data but resource is removed!
      
      To avoid this problem, LED subsystem should turn off the brightness first
      and wait for completion.
      
        led_set_brightness(led_cdev, LED_OFF)
        flush_work(&led_cdev->set_brightness_work)
      
      It guarantees that LED driver turns off the brightness prior to
      resource management.
      
      Cc: linux-leds@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarMilo Kim <milo.kim@ti.com>
      Signed-off-by: default avatarJacek Anaszewski <j.anaszewski@samsung.com>
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e946ed3
    • Markus Hofstaetter's avatar
      leds: call led_pwm_set() in leds-pwm to enforce default LED_OFF · c5cc3e03
      Markus Hofstaetter authored
      commit f1670336 upstream.
      
      Some PWMs are disabled by default or the default pin setting
      does not match the LED_OFF state (e.g., active-low leds).
      Hence, the driver may end up reporting 0 brightness, but
      the leds are actually on using full brightness, because
      it never enforces its default configuration.
      So enforce it by calling led_pwm_set() after successfully
      registering the device.
      
      Tested on a Phytec phyFLEX i.MX6Q board based on kernel
      v3.19.5.
      Signed-off-by: default avatarMarkus Hofstaetter <markus.hofstaetter@ait.ac.at>
      Tested-by: default avatarMarkus Hofstaetter <markus.hofstaetter@ait.ac.at>
      Signed-off-by: default avatarJacek Anaszewski <j.anaszewski@samsung.com>
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5cc3e03
    • Laura Abbott's avatar
      kgdboc: Fix warning with module build · 5403677a
      Laura Abbott authored
      commit 1cd25cbb2fedbc777f3a8c3cb1ba69b645aeaa64 upstream.
      
      After 2dd453168643 ("kgdboc: Fix restrict error"), kgdboc_option_setup is
      now only used when built in, resulting in a warning when compiled as a
      module:
      
      drivers/tty/serial/kgdboc.c:134:12: warning: 'kgdboc_option_setup' defined but not used [-Wunused-function]
       static int kgdboc_option_setup(char *opt)
                  ^~~~~~~~~~~~~~~~~~~
      
      Move the function under the appropriate ifdef for builtin only.
      
      Fixes: 2dd453168643 ("kgdboc: Fix restrict error")
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarLaura Abbott <labbott@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5403677a
    • Laura Abbott's avatar
      kgdboc: Fix restrict error · fa8d814a
      Laura Abbott authored
      commit 2dd453168643d9475028cd867c57e65956a0f7f9 upstream.
      
      There's an error when compiled with restrict:
      
      drivers/tty/serial/kgdboc.c: In function ‘configure_kgdboc’:
      drivers/tty/serial/kgdboc.c:137:2: error: ‘strcpy’ source argument is the same
      as destination [-Werror=restrict]
        strcpy(config, opt);
        ^~~~~~~~~~~~~~~~~~~
      
      As the error implies, this is from trying to use config as both source and
      destination. Drop the call to the function where config is the argument
      since nothing else happens in the function.
      Signed-off-by: default avatarLaura Abbott <labbott@redhat.com>
      Reviewed-by: default avatarDaniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fa8d814a
    • Kees Cook's avatar
      scsi: csiostor: Avoid content leaks and casts · 81ff3e2f
      Kees Cook authored
      commit 42c335f7 upstream.
      
      When copying attributes, the len argument was padded out and the
      resulting memcpy() would copy beyond the end of the source buffer.
      Avoid this, and use size_t for val_len to avoid all the casts.
      Similarly, avoid source buffer casts and use void *.
      
      Additionally enforces val_len can be represented by u16 and that the DMA
      buffer was not overflowed. Fixes the size of mfa, which is not
      FC_FDMI_PORT_ATTR_MAXFRAMESIZE_LEN (but it will be padded up to 4). This
      was noticed by the future CONFIG_FORTIFY_SOURCE checks.
      
      Cc: Daniel Micay <danielmicay@gmail.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarVarun Prakash <varun@chelsio.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      81ff3e2f
    • Takashi Iwai's avatar
      ALSA: trident: Suppress gcc string warning · 0d980b7e
      Takashi Iwai authored
      commit d6b340d7cb33c816ef4abe8143764ec5ab14a5cc upstream.
      
      The meddlesome gcc warns about the possible shortname string in
      trident driver code:
        sound/pci/trident/trident.c: In function ‘snd_trident_probe’:
        sound/pci/trident/trident.c:126:2: warning: ‘strcat’ accessing 17 or more bytes at offsets 36 and 20 may overlap 1 byte at offset 36 [-Wrestrict]
        strcat(card->shortname, card->driver);
      
      It happens since gcc calculates the possible string size from
      card->driver, but this can't be true since we did set the string just
      before that, and they are much shorter.
      
      For shutting it up, use the exactly same string set to card->driver
      for strcat() to card->shortname, too.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0d980b7e
    • Martin Wilck's avatar
      scsi: scsi_devinfo: cleanly zero-pad devinfo strings · 225849e9
      Martin Wilck authored
      commit 81df022b upstream.
      
      Cleanly fill memory for "vendor" and "model" with 0-bytes for the
      "compatible" case rather than adding only a single 0 byte.  This
      simplifies the devinfo code a a bit, and avoids mistakes in other places
      of the code (not in current upstream, but we had one such mistake in the
      SUSE kernel).
      
      [mkp: applied by hand and added braces]
      Signed-off-by: default avatarMartin Wilck <mwilck@suse.com>
      Reviewed-by: default avatarBart Van Assche <bart.vanassche@wdc.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      225849e9
    • Sam Bobroff's avatar
      drm/ast: Fix incorrect free on ioregs · 3e68cbae
      Sam Bobroff authored
      commit dc25ab067645eabd037f1a23d49a666f9e0b8c68 upstream.
      
      If the platform has no IO space, ioregs is placed next to the already
      allocated regs. In this case, it should not be separately freed.
      
      This prevents a kernel warning from __vunmap "Trying to vfree()
      nonexistent vm area" when unloading the driver.
      
      Fixes: 0dd68309 ("drm/ast: Try to use MMIO registers when PIO isn't supported")
      Signed-off-by: default avatarSam Bobroff <sbobroff@linux.ibm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e68cbae
    • Dmitry V. Levin's avatar
      mips: fix mips_get_syscall_arg o32 check · fb68afd2
      Dmitry V. Levin authored
      commit c50cbd85cd7027d32ac5945bb60217936b4f7eaf upstream.
      
      When checking for TIF_32BIT_REGS flag, mips_get_syscall_arg() should
      use the task specified as its argument instead of the current task.
      
      This potentially affects all syscall_get_arguments() users
      who specify tasks different from the current.
      
      Fixes: c0ff3c53 ("MIPS: Enable HAVE_ARCH_TRACEHOOK.")
      Signed-off-by: default avatarDmitry V. Levin <ldv@altlinux.org>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21185/
      Cc: Elvira Khabirova <lineprinter@altlinux.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # v3.13+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fb68afd2
    • Mathias Kresin's avatar
      MIPS: ralink: Fix mt7620 nd_sd pinmux · c18ce9df
      Mathias Kresin authored
      commit 7d35baa4e9ec4b717bc0e58a39cdb6a1c50f5465 upstream.
      
      In case the nd_sd group is set to the sd-card function, Pins 45 + 46 are
      configured as GPIOs. If they are blocked by the sd function, they can't
      be used as GPIOs.
      Reported-by: default avatarKristian Evensen <kristian.evensen@gmail.com>
      Signed-off-by: default avatarMathias Kresin <dev@kresin.me>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: f576fb6a ("MIPS: ralink: cleanup the soc specific pinmux data")
      Patchwork: https://patchwork.linux-mips.org/patch/21220/
      Cc: John Crispin <john@phrozen.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # v3.18+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c18ce9df
    • Andrea Parri's avatar
      uprobes: Fix handle_swbp() vs. unregister() + register() race once more · c9271209
      Andrea Parri authored
      commit 09d3f015d1e1b4fee7e9bbdcf54201d239393391 upstream.
      
      Commit:
      
        142b18dd ("uprobes: Fix handle_swbp() vs unregister() + register() race")
      
      added the UPROBE_COPY_INSN flag, and corresponding smp_wmb() and smp_rmb()
      memory barriers, to ensure that handle_swbp() uses fully-initialized
      uprobes only.
      
      However, the smp_rmb() is mis-placed: this barrier should be placed
      after handle_swbp() has tested for the flag, thus guaranteeing that
      (program-order) subsequent loads from the uprobe can see the initial
      stores performed by prepare_uprobe().
      
      Move the smp_rmb() accordingly.  Also amend the comments associated
      to the two memory barriers to indicate their actual locations.
      Signed-off-by: default avatarAndrea Parri <andrea.parri@amarulasolutions.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: stable@kernel.org
      Fixes: 142b18dd ("uprobes: Fix handle_swbp() vs unregister() + register() race")
      Link: http://lkml.kernel.org/r/20181122161031.15179-1-andrea.parri@amarulasolutions.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c9271209
    • Sagi Grimberg's avatar
      iser: set sector for ambiguous mr status errors · def70991
      Sagi Grimberg authored
      commit 24c3456c8d5ee6fc1933ca40f7b4406130682668 upstream.
      
      If for some reason we failed to query the mr status, we need to make sure
      to provide sufficient information for an ambiguous error (guard error on
      sector 0).
      
      Fixes: 0a7a08ad ("IB/iser: Implement check_protection")
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      def70991
    • Arnd Bergmann's avatar
      kdb: use memmove instead of overlapping memcpy · e1885163
      Arnd Bergmann authored
      commit 2cf2f0d5b91fd1b06a6ae260462fc7945ea84add upstream.
      
      gcc discovered that the memcpy() arguments in kdbnearsym() overlap, so
      we should really use memmove(), which is defined to handle that correctly:
      
      In function 'memcpy',
          inlined from 'kdbnearsym' at /git/arm-soc/kernel/debug/kdb/kdb_support.c:132:4:
      /git/arm-soc/include/linux/string.h:353:9: error: '__builtin_memcpy' accessing 792 bytes at offsets 0 and 8 overlaps 784 bytes at offset 8 [-Werror=restrict]
        return __builtin_memcpy(p, q, size);
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e1885163
    • Arnd Bergmann's avatar
      staging: rts5208: fix gcc-8 logic error warning · e6b59ae2
      Arnd Bergmann authored
      commit 58930cce upstream.
      
      As gcc-8 points out, the bit mask check makes no sense here:
      
      drivers/staging/rts5208/sd.c: In function 'ext_sd_send_cmd_get_rsp':
      drivers/staging/rts5208/sd.c:4130:25: error: bitwise comparison always evaluates to true [-Werror=tautological-compare]
      
      However, the code is even more bogus, as we have already
      checked for the SD_RSP_TYPE_R0 case earlier in the function
      and returned success. As seen in the mmc/sd driver core,
      SD_RSP_TYPE_R0 means "no response" anyway, so checking for
      a particular response would not help either.
      
      This just removes the nonsensical code to get rid of the
      warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e6b59ae2
    • Arnd Bergmann's avatar
      scsi: bfa: convert to strlcpy/strlcat · a7118a1c
      Arnd Bergmann authored
      commit 8c5a50e8 upstream.
      
      The bfa driver has a number of real issues with string termination
      that gcc-8 now points out:
      
      drivers/scsi/bfa/bfad_bsg.c: In function 'bfad_iocmd_port_get_attr':
      drivers/scsi/bfa/bfad_bsg.c:320:9: error: argument to 'sizeof' in 'strncpy' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c: In function 'bfa_fcs_fabric_psymb_init':
      drivers/scsi/bfa/bfa_fcs.c:775:9: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c:781:9: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c:788:9: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c:801:10: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c:808:10: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c: In function 'bfa_fcs_fabric_nsymb_init':
      drivers/scsi/bfa/bfa_fcs.c:837:10: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c:844:10: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c:852:10: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c: In function 'bfa_fcs_fabric_psymb_init':
      drivers/scsi/bfa/bfa_fcs.c:778:2: error: 'strncat' output may be truncated copying 10 bytes from a string of length 63 [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs.c:784:2: error: 'strncat' output may be truncated copying 30 bytes from a string of length 63 [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs.c:803:3: error: 'strncat' output may be truncated copying 44 bytes from a string of length 63 [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs.c:811:3: error: 'strncat' output may be truncated copying 16 bytes from a string of length 63 [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs.c: In function 'bfa_fcs_fabric_nsymb_init':
      drivers/scsi/bfa/bfa_fcs.c:840:2: error: 'strncat' output may be truncated copying 10 bytes from a string of length 63 [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs.c:847:2: error: 'strncat' output may be truncated copying 30 bytes from a string of length 63 [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs_lport.c: In function 'bfa_fcs_fdmi_get_hbaattr':
      drivers/scsi/bfa/bfa_fcs_lport.c:2657:10: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs_lport.c:2659:11: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs_lport.c: In function 'bfa_fcs_lport_ms_gmal_response':
      drivers/scsi/bfa/bfa_fcs_lport.c:3232:5: error: 'strncpy' output may be truncated copying 16 bytes from a string of length 247 [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs_lport.c: In function 'bfa_fcs_lport_ns_send_rspn_id':
      drivers/scsi/bfa/bfa_fcs_lport.c:4670:3: error: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs_lport.c:4682:3: error: 'strncat' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs_lport.c: In function 'bfa_fcs_lport_ns_util_send_rspn_id':
      drivers/scsi/bfa/bfa_fcs_lport.c:5206:3: error: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs_lport.c:5215:3: error: 'strncat' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs_lport.c: In function 'bfa_fcs_fdmi_get_portattr':
      drivers/scsi/bfa/bfa_fcs_lport.c:2751:2: error: 'strncpy' specified bound 128 equals destination size [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcbuild.c: In function 'fc_rspnid_build':
      drivers/scsi/bfa/bfa_fcbuild.c:1254:2: error: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcbuild.c:1253:25: note: length computed here
      drivers/scsi/bfa/bfa_fcbuild.c: In function 'fc_rsnn_nn_build':
      drivers/scsi/bfa/bfa_fcbuild.c:1275:2: error: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
      
      In most cases, this can be addressed by correctly calling strlcpy and
      strlcat instead of strncpy/strncat, with the size of the destination
      buffer as the last argument.
      
      For consistency, I'm changing the other callers of strncpy() in this
      driver the same way.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Acked-by: default avatarSudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7118a1c