1. 08 May, 2019 40 commits
    • Ondrej Mosnacek's avatar
      selinux: never allow relabeling on context mounts · 869d1e45
      Ondrej Mosnacek authored
      commit a83d6dda upstream.
      
      In the SECURITY_FS_USE_MNTPOINT case we never want to allow relabeling
      files/directories, so we should never set the SBLABEL_MNT flag. The
      'special handling' in selinux_is_sblabel_mnt() is only intended for when
      the behavior is set to SECURITY_FS_USE_GENFS.
      
      While there, make the logic in selinux_is_sblabel_mnt() more explicit
      and add a BUILD_BUG_ON() to make sure that introducing a new
      SECURITY_FS_USE_* forces a review of the logic.
      
      Fixes: d5f3a5f6 ("selinux: add security in-core xattr support for pstore and debugfs")
      Signed-off-by: default avatarOndrej Mosnacek <omosnace@redhat.com>
      Reviewed-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      869d1e45
    • Anson Huang's avatar
      Input: snvs_pwrkey - initialize necessary driver data before enabling IRQ · 4fe90144
      Anson Huang authored
      commit bf2a7ca3 upstream.
      
      SNVS IRQ is requested before necessary driver data initialized,
      if there is a pending IRQ during driver probe phase, kernel
      NULL pointer panic will occur in IRQ handler. To avoid such
      scenario, just initialize necessary driver data before enabling
      IRQ. This patch is inspired by NXP's internal kernel tree.
      
      Fixes: d3dc6e23 ("input: keyboard: imx: add snvs power key driver")
      Signed-off-by: default avatarAnson Huang <Anson.Huang@nxp.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4fe90144
    • Bart Van Assche's avatar
      scsi: RDMA/srpt: Fix a credit leak for aborted commands · ea3a2341
      Bart Van Assche authored
      commit 40ca8757 upstream.
      
      Make sure that the next time a response is sent to the initiator that the
      credit it had allocated for the aborted request gets freed.
      
      Cc: Doug Ledford <dledford@redhat.com>
      Cc: Jason Gunthorpe <jgg@ziepe.ca>
      Cc: Nicholas Bellinger <nab@linux-iscsi.org>
      Cc: Mike Christie <mchristi@redhat.com>
      Cc: Hannes Reinecke <hare@suse.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Fixes: 131e6abc ("target: Add TFO->abort_task for aborted task resources release") # v3.15
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ea3a2341
    • Jeremy Fertic's avatar
      staging: iio: adt7316: fix the dac write calculation · 17b600cc
      Jeremy Fertic authored
      commit 78accaea upstream.
      
      The lsb calculation is not masking the correct bits from the user input.
      Subtract 1 from (1 << offset) to correctly set up the mask to be applied
      to user input.
      
      The lsb register stores its value starting at the bit 7 position.
      adt7316_store_DAC() currently assumes the value is at the other end of the
      register. Shift the lsb value before storing it in a new variable lsb_reg,
      and write this variable to the lsb register.
      
      Fixes: 35f6b6b8 ("staging: iio: new ADT7316/7/8 and ADT7516/7/9 driver")
      Signed-off-by: default avatarJeremy Fertic <jeremyfertic@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      17b600cc
    • Jeremy Fertic's avatar
      staging: iio: adt7316: fix the dac read calculation · 8c5a4013
      Jeremy Fertic authored
      commit 45130fb0 upstream.
      
      The calculation of the current dac value is using the wrong bits of the
      dac lsb register. Create two macros to shift the lsb register value into
      lsb position, depending on whether the dac is 10 or 12 bit. Initialize
      data to 0 so, with an 8 bit dac, the msb register value can be bitwise
      ORed with data.
      
      Fixes: 35f6b6b8 ("staging: iio: new ADT7316/7/8 and ADT7516/7/9 driver")
      Signed-off-by: default avatarJeremy Fertic <jeremyfertic@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8c5a4013
    • Jeremy Fertic's avatar
      staging: iio: adt7316: allow adt751x to use internal vref for all dacs · 8ea81e9c
      Jeremy Fertic authored
      commit 10bfe7cc upstream.
      
      With adt7516/7/9, internal vref is available for dacs a and b, dacs c and
      d, or all dacs. The driver doesn't currently support internal vref for all
      dacs. Change the else if to an if so both bits are checked rather than
      just one or the other.
      Signed-off-by: default avatarJeremy Fertic <jeremyfertic@gmail.com>
      Fixes: 35f6b6b8 ("staging: iio: new ADT7316/7/8 and ADT7516/7/9 driver")
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ea81e9c
    • Kim Phillips's avatar
      perf/x86/amd: Update generic hardware cache events for Family 17h · fdeec03e
      Kim Phillips authored
      commit 0e3b74e2 upstream.
      
      Add a new amd_hw_cache_event_ids_f17h assignment structure set
      for AMD families 17h and above, since a lot has changed.  Specifically:
      
      L1 Data Cache
      
      The data cache access counter remains the same on Family 17h.
      
      For DC misses, PMCx041's definition changes with Family 17h,
      so instead we use the L2 cache accesses from L1 data cache
      misses counter (PMCx060,umask=0xc8).
      
      For DC hardware prefetch events, Family 17h breaks compatibility
      for PMCx067 "Data Prefetcher", so instead, we use PMCx05a "Hardware
      Prefetch DC Fills."
      
      L1 Instruction Cache
      
      PMCs 0x80 and 0x81 (32-byte IC fetches and misses) are backward
      compatible on Family 17h.
      
      For prefetches, we remove the erroneous PMCx04B assignment which
      counts how many software data cache prefetch load instructions were
      dispatched.
      
      LL - Last Level Cache
      
      Removing PMCs 7D, 7E, and 7F assignments, as they do not exist
      on Family 17h, where the last level cache is L3.  L3 counters
      can be accessed using the existing AMD Uncore driver.
      
      Data TLB
      
      On Intel machines, data TLB accesses ("dTLB-loads") are assigned
      to counters that count load/store instructions retired.  This
      is inconsistent with instruction TLB accesses, where Intel
      implementations report iTLB misses that hit in the STLB.
      
      Ideally, dTLB-loads would count higher level dTLB misses that hit
      in lower level TLBs, and dTLB-load-misses would report those
      that also missed in those lower-level TLBs, therefore causing
      a page table walk.  That would be consistent with instruction
      TLB operation, remove the redundancy between dTLB-loads and
      L1-dcache-loads, and prevent perf from producing artificially
      low percentage ratios, i.e. the "0.01%" below:
      
              42,550,869      L1-dcache-loads
              41,591,860      dTLB-loads
                   4,802      dTLB-load-misses          #    0.01% of all dTLB cache hits
               7,283,682      L1-dcache-stores
               7,912,392      dTLB-stores
                     310      dTLB-store-misses
      
      On AMD Families prior to 17h, the "Data Cache Accesses" counter is
      used, which is slightly better than load/store instructions retired,
      but still counts in terms of individual load/store operations
      instead of TLB operations.
      
      So, for AMD Families 17h and higher, this patch assigns "dTLB-loads"
      to a counter for L1 dTLB misses that hit in the L2 dTLB, and
      "dTLB-load-misses" to a counter for L1 DTLB misses that caused
      L2 DTLB misses and therefore also caused page table walks.  This
      results in a much more accurate view of data TLB performance:
      
              60,961,781      L1-dcache-loads
                   4,601      dTLB-loads
                     963      dTLB-load-misses          #   20.93% of all dTLB cache hits
      
      Note that for all AMD families, data loads and stores are combined
      in a single accesses counter, so no 'L1-dcache-stores' are reported
      separately, and stores are counted with loads in 'L1-dcache-loads'.
      
      Also note that the "% of all dTLB cache hits" string is misleading
      because (a) "dTLB cache": although TLBs can be considered caches for
      page tables, in this context, it can be misinterpreted as data cache
      hits because the figures are similar (at least on Intel), and (b) not
      all those loads (technically accesses) technically "hit" at that
      hardware level.  "% of all dTLB accesses" would be more clear/accurate.
      
      Instruction TLB
      
      On Intel machines, 'iTLB-loads' measure iTLB misses that hit in the
      STLB, and 'iTLB-load-misses' measure iTLB misses that also missed in
      the STLB and completed a page table walk.
      
      For AMD Family 17h and above, for 'iTLB-loads' we replace the
      erroneous instruction cache fetches counter with PMCx084
      "L1 ITLB Miss, L2 ITLB Hit".
      
      For 'iTLB-load-misses' we still use PMCx085 "L1 ITLB Miss,
      L2 ITLB Miss", but set a 0xff umask because without it the event
      does not get counted.
      
      Branch Predictor (BPU)
      
      PMCs 0xc2 and 0xc3 continue to be valid across all AMD Families.
      
      Node Level Events
      
      Family 17h does not have a PMCx0e9 counter, and corresponding counters
      have not been made available publicly, so for now, we mark them as
      unsupported for Families 17h and above.
      
      Reference:
      
        "Open-Source Register Reference For AMD Family 17h Processors Models 00h-2Fh"
        Released 7/17/2018, Publication #56255, Revision 3.03:
        https://www.amd.com/system/files/TechDocs/56255_OSRR.pdf
      
      [ mingo: tidied up the line breaks. ]
      Signed-off-by: default avatarKim Phillips <kim.phillips@amd.com>
      Cc: <stable@vger.kernel.org> # v4.9+
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Liška <mliska@suse.cz>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Pu Wen <puwen@hygon.cn>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thomas Lendacky <Thomas.Lendacky@amd.com>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-perf-users@vger.kernel.org
      Fixes: e40ed154 ("perf/x86: Add perf support for AMD family-17h processors")
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fdeec03e
    • Arnd Bergmann's avatar
      ARM: iop: don't use using 64-bit DMA masks · 3025f7bc
      Arnd Bergmann authored
      [ Upstream commit 2125801c ]
      
      clang warns about statically defined DMA masks from the DMA_BIT_MASK
      macro with length 64:
      
       arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
       static u64 iop13xx_adma_dmamask = DMA_BIT_MASK(64);
                                        ^~~~~~~~~~~~~~~~
       include/linux/dma-mapping.h:141:54: note: expanded from macro 'DMA_BIT_MASK'
       #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
                                                            ^ ~~~
      
      The ones in iop shouldn't really be 64 bit masks, so changing them
      to what the driver can support avoids the warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3025f7bc
    • Arnd Bergmann's avatar
      ARM: orion: don't use using 64-bit DMA masks · dfe6268c
      Arnd Bergmann authored
      [ Upstream commit cd92d74d ]
      
      clang warns about statically defined DMA masks from the DMA_BIT_MASK
      macro with length 64:
      
      arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
                      .coherent_dma_mask      = DMA_BIT_MASK(64),
                                                ^~~~~~~~~~~~~~~~
      include/linux/dma-mapping.h:141:54: note: expanded from macro 'DMA_BIT_MASK'
       #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
      
      The ones in orion shouldn't really be 64 bit masks, so changing them
      to what the driver can support avoids the warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dfe6268c
    • Guenter Roeck's avatar
      xsysace: Fix error handling in ace_setup · 71f8374f
      Guenter Roeck authored
      [ Upstream commit 47b16820 ]
      
      If xace hardware reports a bad version number, the error handling code
      in ace_setup() calls put_disk(), followed by queue cleanup. However, since
      the disk data structure has the queue pointer set, put_disk() also
      cleans and releases the queue. This results in blk_cleanup_queue()
      accessing an already released data structure, which in turn may result
      in a crash such as the following.
      
      [   10.681671] BUG: Kernel NULL pointer dereference at 0x00000040
      [   10.681826] Faulting instruction address: 0xc0431480
      [   10.682072] Oops: Kernel access of bad area, sig: 11 [#1]
      [   10.682251] BE PAGE_SIZE=4K PREEMPT Xilinx Virtex440
      [   10.682387] Modules linked in:
      [   10.682528] CPU: 0 PID: 1 Comm: swapper Tainted: G        W         5.0.0-rc6-next-20190218+ #2
      [   10.682733] NIP:  c0431480 LR: c043147c CTR: c0422ad8
      [   10.682863] REGS: cf82fbe0 TRAP: 0300   Tainted: G        W          (5.0.0-rc6-next-20190218+)
      [   10.683065] MSR:  00029000 <CE,EE,ME>  CR: 22000222  XER: 00000000
      [   10.683236] DEAR: 00000040 ESR: 00000000
      [   10.683236] GPR00: c043147c cf82fc90 cf82ccc0 00000000 00000000 00000000 00000002 00000000
      [   10.683236] GPR08: 00000000 00000000 c04310bc 00000000 22000222 00000000 c0002c54 00000000
      [   10.683236] GPR16: 00000000 00000001 c09aa39c c09021b0 c09021dc 00000007 c0a68c08 00000000
      [   10.683236] GPR24: 00000001 ced6d400 ced6dcf0 c0815d9c 00000000 00000000 00000000 cedf0800
      [   10.684331] NIP [c0431480] blk_mq_run_hw_queue+0x28/0x114
      [   10.684473] LR [c043147c] blk_mq_run_hw_queue+0x24/0x114
      [   10.684602] Call Trace:
      [   10.684671] [cf82fc90] [c043147c] blk_mq_run_hw_queue+0x24/0x114 (unreliable)
      [   10.684854] [cf82fcc0] [c04315bc] blk_mq_run_hw_queues+0x50/0x7c
      [   10.685002] [cf82fce0] [c0422b24] blk_set_queue_dying+0x30/0x68
      [   10.685154] [cf82fcf0] [c0423ec0] blk_cleanup_queue+0x34/0x14c
      [   10.685306] [cf82fd10] [c054d73c] ace_probe+0x3dc/0x508
      [   10.685445] [cf82fd50] [c052d740] platform_drv_probe+0x4c/0xb8
      [   10.685592] [cf82fd70] [c052abb0] really_probe+0x20c/0x32c
      [   10.685728] [cf82fda0] [c052ae58] driver_probe_device+0x68/0x464
      [   10.685877] [cf82fdc0] [c052b500] device_driver_attach+0xb4/0xe4
      [   10.686024] [cf82fde0] [c052b5dc] __driver_attach+0xac/0xfc
      [   10.686161] [cf82fe00] [c0528428] bus_for_each_dev+0x80/0xc0
      [   10.686314] [cf82fe30] [c0529b3c] bus_add_driver+0x144/0x234
      [   10.686457] [cf82fe50] [c052c46c] driver_register+0x88/0x15c
      [   10.686610] [cf82fe60] [c09de288] ace_init+0x4c/0xac
      [   10.686742] [cf82fe80] [c0002730] do_one_initcall+0xac/0x330
      [   10.686888] [cf82fee0] [c09aafd0] kernel_init_freeable+0x34c/0x478
      [   10.687043] [cf82ff30] [c0002c6c] kernel_init+0x18/0x114
      [   10.687188] [cf82ff40] [c000f2f0] ret_from_kernel_thread+0x14/0x1c
      [   10.687349] Instruction dump:
      [   10.687435] 3863ffd4 4bfffd70 9421ffd0 7c0802a6 93c10028 7c9e2378 93e1002c 38810008
      [   10.687637] 7c7f1b78 90010034 4bfffc25 813f008c <81290040> 75290100 4182002c 80810008
      [   10.688056] ---[ end trace 13c9ff51d41b9d40 ]---
      
      Fix the problem by setting the disk queue pointer to NULL before calling
      put_disk(). A more comprehensive fix might be to rearrange the code
      to check the hardware version before initializing data structures,
      but I don't know if this would have undesirable side effects, and
      it would increase the complexity of backporting the fix to older kernels.
      
      Fixes: 74489a91 ("Add support for Xilinx SystemACE CompactFlash interface")
      Acked-by: default avatarMichal Simek <michal.simek@xilinx.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      71f8374f
    • Randy Dunlap's avatar
      sh: fix multiple function definition build errors · fb85c7b2
      Randy Dunlap authored
      [ Upstream commit acaf892e ]
      
      Many of the sh CPU-types have their own plat_irq_setup() and
      arch_init_clk_ops() functions, so these same (empty) functions in
      arch/sh/boards/of-generic.c are not needed and cause build errors.
      
      If there is some case where these empty functions are needed, they can
      be retained by marking them as "__weak" while at the same time making
      builds that do not need them succeed.
      
      Fixes these build errors:
      
      arch/sh/boards/of-generic.o: In function `plat_irq_setup':
      (.init.text+0x134): multiple definition of `plat_irq_setup'
      arch/sh/kernel/cpu/sh2/setup-sh7619.o:(.init.text+0x30): first defined here
      arch/sh/boards/of-generic.o: In function `arch_init_clk_ops':
      (.init.text+0x118): multiple definition of `arch_init_clk_ops'
      arch/sh/kernel/cpu/sh2/clock-sh7619.o:(.init.text+0x0): first defined here
      
      Link: http://lkml.kernel.org/r/9ee4e0c5-f100-86a2-bd4d-1d3287ceab31@infradead.orgSigned-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.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 avatarSasha Levin <sashal@kernel.org>
      fb85c7b2
    • Mike Kravetz's avatar
      hugetlbfs: fix memory leak for resv_map · d57e4ae3
      Mike Kravetz authored
      [ Upstream commit 58b6e5e8 ]
      
      When mknod is used to create a block special file in hugetlbfs, it will
      allocate an inode and kmalloc a 'struct resv_map' via resv_map_alloc().
      inode->i_mapping->private_data will point the newly allocated resv_map.
      However, when the device special file is opened bd_acquire() will set
      inode->i_mapping to bd_inode->i_mapping.  Thus the pointer to the
      allocated resv_map is lost and the structure is leaked.
      
      Programs to reproduce:
              mount -t hugetlbfs nodev hugetlbfs
              mknod hugetlbfs/dev b 0 0
              exec 30<> hugetlbfs/dev
              umount hugetlbfs/
      
      resv_map structures are only needed for inodes which can have associated
      page allocations.  To fix the leak, only allocate resv_map for those
      inodes which could possibly be associated with page allocations.
      
      Link: http://lkml.kernel.org/r/20190401213101.16476-1-mike.kravetz@oracle.comSigned-off-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Reported-by: default avatarYufen Yu <yuyufen@huawei.com>
      Suggested-by: default avatarYufen Yu <yuyufen@huawei.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d57e4ae3
    • Yonglong Liu's avatar
      net: hns: Fix WARNING when remove HNS driver with SMMU enabled · 2332a9a6
      Yonglong Liu authored
      [ Upstream commit 8601a99d ]
      
      When enable SMMU, remove HNS driver will cause a WARNING:
      
      [  141.924177] WARNING: CPU: 36 PID: 2708 at drivers/iommu/dma-iommu.c:443 __iommu_dma_unmap+0xc0/0xc8
      [  141.954673] Modules linked in: hns_enet_drv(-)
      [  141.963615] CPU: 36 PID: 2708 Comm: rmmod Tainted: G        W         5.0.0-rc1-28723-gb729c57de95c-dirty #32
      [  141.983593] Hardware name: Huawei D05/D05, BIOS Hisilicon D05 UEFI Nemo 1.8 RC0 08/31/2017
      [  142.000244] pstate: 60000005 (nZCv daif -PAN -UAO)
      [  142.009886] pc : __iommu_dma_unmap+0xc0/0xc8
      [  142.018476] lr : __iommu_dma_unmap+0xc0/0xc8
      [  142.027066] sp : ffff000013533b90
      [  142.033728] x29: ffff000013533b90 x28: ffff8013e6983600
      [  142.044420] x27: 0000000000000000 x26: 0000000000000000
      [  142.055113] x25: 0000000056000000 x24: 0000000000000015
      [  142.065806] x23: 0000000000000028 x22: ffff8013e66eee68
      [  142.076499] x21: ffff8013db919800 x20: 0000ffffefbff000
      [  142.087192] x19: 0000000000001000 x18: 0000000000000007
      [  142.097885] x17: 000000000000000e x16: 0000000000000001
      [  142.108578] x15: 0000000000000019 x14: 363139343a70616d
      [  142.119270] x13: 6e75656761705f67 x12: 0000000000000000
      [  142.129963] x11: 00000000ffffffff x10: 0000000000000006
      [  142.140656] x9 : 1346c1aa88093500 x8 : ffff0000114de4e0
      [  142.151349] x7 : 6662666578303d72 x6 : ffff0000105ffec8
      [  142.162042] x5 : 0000000000000000 x4 : 0000000000000000
      [  142.172734] x3 : 00000000ffffffff x2 : ffff0000114de500
      [  142.183427] x1 : 0000000000000000 x0 : 0000000000000035
      [  142.194120] Call trace:
      [  142.199030]  __iommu_dma_unmap+0xc0/0xc8
      [  142.206920]  iommu_dma_unmap_page+0x20/0x28
      [  142.215335]  __iommu_unmap_page+0x40/0x60
      [  142.223399]  hnae_unmap_buffer+0x110/0x134
      [  142.231639]  hnae_free_desc+0x6c/0x10c
      [  142.239177]  hnae_fini_ring+0x14/0x34
      [  142.246540]  hnae_fini_queue+0x2c/0x40
      [  142.254080]  hnae_put_handle+0x38/0xcc
      [  142.261619]  hns_nic_dev_remove+0x54/0xfc [hns_enet_drv]
      [  142.272312]  platform_drv_remove+0x24/0x64
      [  142.280552]  device_release_driver_internal+0x17c/0x20c
      [  142.291070]  driver_detach+0x4c/0x90
      [  142.298259]  bus_remove_driver+0x5c/0xd8
      [  142.306148]  driver_unregister+0x2c/0x54
      [  142.314037]  platform_driver_unregister+0x10/0x18
      [  142.323505]  hns_nic_dev_driver_exit+0x14/0xf0c [hns_enet_drv]
      [  142.335248]  __arm64_sys_delete_module+0x214/0x25c
      [  142.344891]  el0_svc_common+0xb0/0x10c
      [  142.352430]  el0_svc_handler+0x24/0x80
      [  142.359968]  el0_svc+0x8/0x7c0
      [  142.366104] ---[ end trace 60ad1cd58e63c407 ]---
      
      The tx ring buffer map when xmit and unmap when xmit done. So in
      hnae_init_ring() did not map tx ring buffer, but in hnae_fini_ring()
      have a unmap operation for tx ring buffer, which is already unmapped
      when xmit done, than cause this WARNING.
      
      The hnae_alloc_buffers() is called in hnae_init_ring(),
      so the hnae_free_buffers() should be in hnae_fini_ring(), not in
      hnae_free_desc().
      
      In hnae_fini_ring(), adds a check is_rx_ring() as in hnae_init_ring().
      When the ring buffer is tx ring, adds a piece of code to ensure that
      the tx ring is unmap.
      Signed-off-by: default avatarYonglong Liu <liuyonglong@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2332a9a6
    • Yonglong Liu's avatar
      net: hns: Use NAPI_POLL_WEIGHT for hns driver · 0d146f68
      Yonglong Liu authored
      [ Upstream commit acb1ce15 ]
      
      When the HNS driver loaded, always have an error print:
      "netif_napi_add() called with weight 256"
      
      This is because the kernel checks the NAPI polling weights
      requested by drivers and it prints an error message if a driver
      requests a weight bigger than 64.
      
      So use NAPI_POLL_WEIGHT to fix it.
      Signed-off-by: default avatarYonglong Liu <liuyonglong@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0d146f68
    • Liubin Shu's avatar
      net: hns: fix KASAN: use-after-free in hns_nic_net_xmit_hw() · b36a29e5
      Liubin Shu authored
      [ Upstream commit 3a39a12a ]
      
      This patch is trying to fix the issue due to:
      [27237.844750] BUG: KASAN: use-after-free in hns_nic_net_xmit_hw+0x708/0xa18[hns_enet_drv]
      
      After hnae_queue_xmit() in hns_nic_net_xmit_hw(), can be
      interrupted by interruptions, and than call hns_nic_tx_poll_one()
      to handle the new packets, and free the skb. So, when turn back to
      hns_nic_net_xmit_hw(), calling skb->len will cause use-after-free.
      
      This patch update tx ring statistics in hns_nic_tx_poll_one() to
      fix the bug.
      Signed-off-by: default avatarLiubin Shu <shuliubin@huawei.com>
      Signed-off-by: default avatarZhen Lei <thunder.leizhen@huawei.com>
      Signed-off-by: default avatarYonglong Liu <liuyonglong@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b36a29e5
    • Michael Kelley's avatar
      scsi: storvsc: Fix calculation of sub-channel count · 9cdaf16e
      Michael Kelley authored
      [ Upstream commit 382e06d1 ]
      
      When the number of sub-channels offered by Hyper-V is >= the number of CPUs
      in the VM, calculate the correct number of sub-channels.  The current code
      produces one too many.
      
      This scenario arises only when the number of CPUs is artificially
      restricted (for example, with maxcpus=<n> on the kernel boot line), because
      Hyper-V normally offers a sub-channel count < number of CPUs.  While the
      current code doesn't break, the extra sub-channel is unbalanced across the
      CPUs (for example, a total of 5 channels on a VM with 4 CPUs).
      Signed-off-by: default avatarMichael Kelley <mikelley@microsoft.com>
      Reviewed-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Reviewed-by: default avatarLong Li <longli@microsoft.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9cdaf16e
    • Xose Vazquez Perez's avatar
      scsi: core: add new RDAC LENOVO/DE_Series device · 7a4973dd
      Xose Vazquez Perez authored
      [ Upstream commit 1cb1d2c6 ]
      
      Blacklist "Universal Xport" LUN. It's used for in-band storage array
      management.  Also add model to the rdac dh family.
      
      Cc: Martin Wilck <mwilck@suse.com>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: NetApp RDAC team <ng-eseries-upstream-maintainers@netapp.com>
      Cc: Christophe Varoqui <christophe.varoqui@opensvc.com>
      Cc: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Cc: SCSI ML <linux-scsi@vger.kernel.org>
      Cc: DM ML <dm-devel@redhat.com>
      Signed-off-by: default avatarXose Vazquez Perez <xose.vazquez@gmail.com>
      Reviewed-by: default avatarMartin Wilck <mwilck@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7a4973dd
    • Louis Taylor's avatar
      vfio/pci: use correct format characters · 53ffab7d
      Louis Taylor authored
      [ Upstream commit 426b046b ]
      
      When compiling with -Wformat, clang emits the following warnings:
      
      drivers/vfio/pci/vfio_pci.c:1601:5: warning: format specifies type
            'unsigned short' but the argument has type 'unsigned int' [-Wformat]
                                      vendor, device, subvendor, subdevice,
                                      ^~~~~~
      
      drivers/vfio/pci/vfio_pci.c:1601:13: warning: format specifies type
            'unsigned short' but the argument has type 'unsigned int' [-Wformat]
                                      vendor, device, subvendor, subdevice,
                                              ^~~~~~
      
      drivers/vfio/pci/vfio_pci.c:1601:21: warning: format specifies type
            'unsigned short' but the argument has type 'unsigned int' [-Wformat]
                                      vendor, device, subvendor, subdevice,
                                                      ^~~~~~~~~
      
      drivers/vfio/pci/vfio_pci.c:1601:32: warning: format specifies type
            'unsigned short' but the argument has type 'unsigned int' [-Wformat]
                                      vendor, device, subvendor, subdevice,
                                                                 ^~~~~~~~~
      
      drivers/vfio/pci/vfio_pci.c:1605:5: warning: format specifies type
            'unsigned short' but the argument has type 'unsigned int' [-Wformat]
                                      vendor, device, subvendor, subdevice,
                                      ^~~~~~
      
      drivers/vfio/pci/vfio_pci.c:1605:13: warning: format specifies type
            'unsigned short' but the argument has type 'unsigned int' [-Wformat]
                                      vendor, device, subvendor, subdevice,
                                              ^~~~~~
      
      drivers/vfio/pci/vfio_pci.c:1605:21: warning: format specifies type
            'unsigned short' but the argument has type 'unsigned int' [-Wformat]
                                      vendor, device, subvendor, subdevice,
                                                      ^~~~~~~~~
      
      drivers/vfio/pci/vfio_pci.c:1605:32: warning: format specifies type
            'unsigned short' but the argument has type 'unsigned int' [-Wformat]
                                      vendor, device, subvendor, subdevice,
                                                                 ^~~~~~~~~
      The types of these arguments are unconditionally defined, so this patch
      updates the format character to the correct ones for unsigned ints.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/378Signed-off-by: default avatarLouis Taylor <louis@kragniz.eu>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      53ffab7d
    • Alexandre Belloni's avatar
      rtc: da9063: set uie_unsupported when relevant · 92700e02
      Alexandre Belloni authored
      [ Upstream commit 882c5e55 ]
      
      The DA9063AD doesn't support alarms on any seconds and its granularity is
      the minute. Set uie_unsupported in that case.
      Reported-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Reported-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Tested-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Acked-by: default avatarSteve Twiss <stwiss.opensource@diasemi.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      92700e02
    • Al Viro's avatar
      debugfs: fix use-after-free on symlink traversal · 1ef8447a
      Al Viro authored
      [ Upstream commit 93b919da ]
      
      symlink body shouldn't be freed without an RCU delay.  Switch debugfs to
      ->destroy_inode() and use of call_rcu(); free both the inode and symlink
      body in the callback.  Similar to solution for bpf, only here it's even
      more obvious that ->evict_inode() can be dropped.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1ef8447a
    • Al Viro's avatar
      jffs2: fix use-after-free on symlink traversal · ff250f4c
      Al Viro authored
      [ Upstream commit 4fdcfab5 ]
      
      free the symlink body after the same RCU delay we have for freeing the
      struct inode itself, so that traversal during RCU pathwalk wouldn't step
      into freed memory.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ff250f4c
    • Aaro Koskinen's avatar
      net: stmmac: don't log oversized frames · dc498ade
      Aaro Koskinen authored
      [ Upstream commit 057a0c56 ]
      
      This is log is harmful as it can trigger multiple times per packet. Delete
      it.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dc498ade
    • Aaro Koskinen's avatar
      net: stmmac: fix dropping of multi-descriptor RX frames · 0eb5f935
      Aaro Koskinen authored
      [ Upstream commit 8ac0c24f ]
      
      Packets without the last descriptor set should be dropped early. If we
      receive a frame larger than the DMA buffer, the HW will continue using the
      next descriptor. Driver mistakes these as individual frames, and sometimes
      a truncated frame (without the LD set) may look like a valid packet.
      
      This fixes a strange issue where the system replies to 4098-byte ping
      although the MTU/DMA buffer size is set to 4096, and yet at the same
      time it's logging an oversized packet.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0eb5f935
    • Aaro Koskinen's avatar
      net: stmmac: don't overwrite discard_frame status · 2207295c
      Aaro Koskinen authored
      [ Upstream commit 1b746ce8 ]
      
      If we have error bits set, the discard_frame status will get overwritten
      by checksum bit checks, which might set the status back to good one.
      Fix by checking the COE status only if the frame is good.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2207295c
    • Konstantin Khorenko's avatar
      bonding: show full hw address in sysfs for slave entries · 2e89db5d
      Konstantin Khorenko authored
      [ Upstream commit 18bebc6d ]
      
      Bond expects ethernet hwaddr for its slave, but it can be longer than 6
      bytes - infiniband interface for example.
      
       # cat /sys/devices/<skipped>/net/ib0/address
       80:00:02:08:fe:80:00:00:00:00:00:00:7c:fe:90:03:00:be:5d:e1
      
       # cat /sys/devices/<skipped>/net/ib0/bonding_slave/perm_hwaddr
       80:00:02:08:fe:80
      
      So print full hwaddr in sysfs "bonding_slave/perm_hwaddr" as well.
      Signed-off-by: default avatarKonstantin Khorenko <khorenko@virtuozzo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2e89db5d
    • Omri Kahalon's avatar
      net/mlx5: E-Switch, Fix esw manager vport indication for more vport commands · aa075d3d
      Omri Kahalon authored
      [ Upstream commit eca4a928 ]
      
      Traditionally, the PF (Physical Function) which resides on vport 0 was
      the E-switch manager. Since the ECPF (Embedded CPU Physical Function),
      which resides on vport 0xfffe, was introduced as the E-Switch manager,
      the assumption that the E-switch manager is on vport 0 is incorrect.
      
      Since the eswitch code already uses the actual vport value, all we
      need is to always set other_vport=1.
      Signed-off-by: default avatarOmri Kahalon <omrik@mellanox.com>
      Reviewed-by: default avatarMax Gurtovoy <maxg@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      aa075d3d
    • Arvind Sankar's avatar
      igb: Fix WARN_ONCE on runtime suspend · c40fc015
      Arvind Sankar authored
      [ Upstream commit dabb8338 ]
      
      The runtime_suspend device callbacks are not supposed to save
      configuration state or change the power state. Commit fb29f76cc566
      ("igb: Fix an issue that PME is not enabled during runtime suspend")
      changed the driver to not save configuration state during runtime
      suspend, however the driver callback still put the device into a
      low-power state. This causes a warning in the pci pm core and results in
      pci_pm_runtime_suspend not calling pci_save_state or pci_finish_runtime_suspend.
      
      Fix this by not changing the power state either, leaving that to pci pm
      core, and make the same change for suspend callback as well.
      
      Also move a couple of defines into the appropriate header file instead
      of inline in the .c file.
      
      Fixes: fb29f76cc566 ("igb: Fix an issue that PME is not enabled during runtime suspend")
      Signed-off-by: default avatarArvind Sankar <niveditas98@gmail.com>
      Reviewed-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c40fc015
    • Sven Eckelmann's avatar
      batman-adv: Reduce tt_global hash refcnt only for removed entry · 8223fbcd
      Sven Eckelmann authored
      [ Upstream commit f131a568 ]
      
      The batadv_hash_remove is a function which searches the hashtable for an
      entry using a needle, a hashtable bucket selection function and a compare
      function. It will lock the bucket list and delete an entry when the compare
      function matches it with the needle. It returns the pointer to the
      hlist_node which matches or NULL when no entry matches the needle.
      
      The batadv_tt_global_free is not itself protected in anyway to avoid that
      any other function is modifying the hashtable between the search for the
      entry and the call to batadv_hash_remove. It can therefore happen that the
      entry either doesn't exist anymore or an entry was deleted which is not the
      same object as the needle. In such an situation, the reference counter (for
      the reference stored in the hashtable) must not be reduced for the needle.
      Instead the reference counter of the actually removed entry has to be
      reduced.
      
      Otherwise the reference counter will underflow and the object might be
      freed before all its references were dropped. The kref helpers reported
      this problem as:
      
        refcount_t: underflow; use-after-free.
      
      Fixes: 7683fdc1 ("batman-adv: protect the local and the global trans-tables with rcu")
      Reported-by: default avatarMartin Weinelt <martin@linuxlounge.net>
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Acked-by: default avatarAntonio Quartulli <a@unstable.cc>
      Signed-off-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8223fbcd
    • Sven Eckelmann's avatar
      batman-adv: Reduce tt_local hash refcnt only for removed entry · 33a5be31
      Sven Eckelmann authored
      [ Upstream commit 3d65b9ac ]
      
      The batadv_hash_remove is a function which searches the hashtable for an
      entry using a needle, a hashtable bucket selection function and a compare
      function. It will lock the bucket list and delete an entry when the compare
      function matches it with the needle. It returns the pointer to the
      hlist_node which matches or NULL when no entry matches the needle.
      
      The batadv_tt_local_remove is not itself protected in anyway to avoid that
      any other function is modifying the hashtable between the search for the
      entry and the call to batadv_hash_remove. It can therefore happen that the
      entry either doesn't exist anymore or an entry was deleted which is not the
      same object as the needle. In such an situation, the reference counter (for
      the reference stored in the hashtable) must not be reduced for the needle.
      Instead the reference counter of the actually removed entry has to be
      reduced.
      
      Otherwise the reference counter will underflow and the object might be
      freed before all its references were dropped. The kref helpers reported
      this problem as:
      
        refcount_t: underflow; use-after-free.
      
      Fixes: ef72706a ("batman-adv: protect tt_local_entry from concurrent delete events")
      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>
      33a5be31
    • Sven Eckelmann's avatar
      batman-adv: Reduce claim hash refcnt only for removed entry · 3b3ea9ff
      Sven Eckelmann authored
      [ Upstream commit 4ba104f4 ]
      
      The batadv_hash_remove is a function which searches the hashtable for an
      entry using a needle, a hashtable bucket selection function and a compare
      function. It will lock the bucket list and delete an entry when the compare
      function matches it with the needle. It returns the pointer to the
      hlist_node which matches or NULL when no entry matches the needle.
      
      The batadv_bla_del_claim is not itself protected in anyway to avoid that
      any other function is modifying the hashtable between the search for the
      entry and the call to batadv_hash_remove. It can therefore happen that the
      entry either doesn't exist anymore or an entry was deleted which is not the
      same object as the needle. In such an situation, the reference counter (for
      the reference stored in the hashtable) must not be reduced for the needle.
      Instead the reference counter of the actually removed entry has to be
      reduced.
      
      Otherwise the reference counter will underflow and the object might be
      freed before all its references were dropped. The kref helpers reported
      this problem as:
      
        refcount_t: underflow; use-after-free.
      
      Fixes: 23721387 ("batman-adv: add basic bridge loop avoidance code")
      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>
      3b3ea9ff
    • Geert Uytterhoeven's avatar
      rtc: sh: Fix invalid alarm warning for non-enabled alarm · 214122d6
      Geert Uytterhoeven authored
      [ Upstream commit 15d82d22 ]
      
      When no alarm has been programmed on RSK-RZA1, an error message is
      printed during boot:
      
          rtc rtc0: invalid alarm value: 2019-03-14T255:255:255
      
      sh_rtc_read_alarm_value() returns 0xff when querying a hardware alarm
      field that is not enabled.  __rtc_read_alarm() validates the received
      alarm values, and fills in missing fields when needed.
      While 0xff is handled fine for the year, month, and day fields, and
      corrected as considered being out-of-range, this is not the case for the
      hour, minute, and second fields, where -1 is expected for missing
      fields.
      
      Fix this by returning -1 instead, as this value is handled fine for all
      fields.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      214122d6
    • He, Bo's avatar
      HID: debug: fix race condition with between rdesc_show() and device removal · ee3d9abe
      He, Bo authored
      [ Upstream commit cef0d494 ]
      
      There is a race condition that could happen if hid_debug_rdesc_show()
      is running while hdev is in the process of going away (device removal,
      system suspend, etc) which could result in NULL pointer dereference:
      
      	 BUG: unable to handle kernel paging request at 0000000783316040
      	 CPU: 1 PID: 1512 Comm: getevent Tainted: G     U     O 4.19.20-quilt-2e5dc0ac-00029-gc455a447dd55 #1
      	 RIP: 0010:hid_dump_device+0x9b/0x160
      	 Call Trace:
      	  hid_debug_rdesc_show+0x72/0x1d0
      	  seq_read+0xe0/0x410
      	  full_proxy_read+0x5f/0x90
      	  __vfs_read+0x3a/0x170
      	  vfs_read+0xa0/0x150
      	  ksys_read+0x58/0xc0
      	  __x64_sys_read+0x1a/0x20
      	  do_syscall_64+0x55/0x110
      	  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Grab driver_input_lock to make sure the input device exists throughout the
      whole process of dumping the rdesc.
      
      [jkosina@suse.cz: update changelog a bit]
      Signed-off-by: default avatarhe, bo <bo.he@intel.com>
      Signed-off-by: default avatar"Zhang, Jun" <jun.zhang@intel.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ee3d9abe
    • Kangjie Lu's avatar
      HID: logitech: check the return value of create_singlethread_workqueue · 72bbf78c
      Kangjie Lu authored
      [ Upstream commit 6c44b15e ]
      
      create_singlethread_workqueue may fail and return NULL. The fix checks if it is
      NULL to avoid NULL pointer dereference.  Also, the fix moves the call of
      create_singlethread_workqueue earlier to avoid resource-release issues.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      72bbf78c
    • Yufen Yu's avatar
      nvme-loop: init nvmet_ctrl fatal_err_work when allocate · 87b622f9
      Yufen Yu authored
      [ Upstream commit d11de63f ]
      
      After commit 4d43d395 (workqueue: Try to catch flush_work() without
      INIT_WORK()), it can cause warning when delete nvme-loop device, trace
      like:
      
      [   76.601272] Call Trace:
      [   76.601646]  ? del_timer+0x72/0xa0
      [   76.602156]  __cancel_work_timer+0x1ae/0x270
      [   76.602791]  cancel_work_sync+0x14/0x20
      [   76.603407]  nvmet_ctrl_free+0x1b7/0x2f0 [nvmet]
      [   76.604091]  ? free_percpu+0x168/0x300
      [   76.604652]  nvmet_sq_destroy+0x106/0x240 [nvmet]
      [   76.605346]  nvme_loop_destroy_admin_queue+0x30/0x60 [nvme_loop]
      [   76.606220]  nvme_loop_shutdown_ctrl+0xc3/0xf0 [nvme_loop]
      [   76.607026]  nvme_loop_delete_ctrl_host+0x19/0x30 [nvme_loop]
      [   76.607871]  nvme_do_delete_ctrl+0x75/0xb0
      [   76.608477]  nvme_sysfs_delete+0x7d/0xc0
      [   76.609057]  dev_attr_store+0x24/0x40
      [   76.609603]  sysfs_kf_write+0x4c/0x60
      [   76.610144]  kernfs_fop_write+0x19a/0x260
      [   76.610742]  __vfs_write+0x1c/0x60
      [   76.611246]  vfs_write+0xfa/0x280
      [   76.611739]  ksys_write+0x6e/0x120
      [   76.612238]  __x64_sys_write+0x1e/0x30
      [   76.612787]  do_syscall_64+0xbf/0x3a0
      [   76.613329]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      We fix it by moving fatal_err_work init to nvmet_alloc_ctrl(), which may
      more reasonable.
      Signed-off-by: default avatarYufen Yu <yuyufen@huawei.com>
      Reviewed-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Reviewed-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      87b622f9
    • Alan Stern's avatar
      USB: core: Fix bug caused by duplicate interface PM usage counter · 3c65c766
      Alan Stern authored
      commit c2b71462 upstream.
      
      The syzkaller fuzzer reported a bug in the USB hub driver which turned
      out to be caused by a negative runtime-PM usage counter.  This allowed
      a hub to be runtime suspended at a time when the driver did not expect
      it.  The symptom is a WARNING issued because the hub's status URB is
      submitted while it is already active:
      
      	URB 0000000031fb463e submitted while active
      	WARNING: CPU: 0 PID: 2917 at drivers/usb/core/urb.c:363
      
      The negative runtime-PM usage count was caused by an unfortunate
      design decision made when runtime PM was first implemented for USB.
      At that time, USB class drivers were allowed to unbind from their
      interfaces without balancing the usage counter (i.e., leaving it with
      a positive count).  The core code would take care of setting the
      counter back to 0 before allowing another driver to bind to the
      interface.
      
      Later on when runtime PM was implemented for the entire kernel, the
      opposite decision was made: Drivers were required to balance their
      runtime-PM get and put calls.  In order to maintain backward
      compatibility, however, the USB subsystem adapted to the new
      implementation by keeping an independent usage counter for each
      interface and using it to automatically adjust the normal usage
      counter back to 0 whenever a driver was unbound.
      
      This approach involves duplicating information, but what is worse, it
      doesn't work properly in cases where a USB class driver delays
      decrementing the usage counter until after the driver's disconnect()
      routine has returned and the counter has been adjusted back to 0.
      Doing so would cause the usage counter to become negative.  There's
      even a warning about this in the USB power management documentation!
      
      As it happens, this is exactly what the hub driver does.  The
      kick_hub_wq() routine increments the runtime-PM usage counter, and the
      corresponding decrement is carried out by hub_event() in the context
      of the hub_wq work-queue thread.  This work routine may sometimes run
      after the driver has been unbound from its interface, and when it does
      it causes the usage counter to go negative.
      
      It is not possible for hub_disconnect() to wait for a pending
      hub_event() call to finish, because hub_disconnect() is called with
      the device lock held and hub_event() acquires that lock.  The only
      feasible fix is to reverse the original design decision: remove the
      duplicate interface-specific usage counter and require USB drivers to
      balance their runtime PM gets and puts.  As far as I know, all
      existing drivers currently do this.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: syzbot+7634edaea4d0b341c625@syzkaller.appspotmail.com
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c65c766
    • Alan Stern's avatar
      USB: core: Fix unterminated string returned by usb_string() · 7bbbb95a
      Alan Stern authored
      commit c01c348e upstream.
      
      Some drivers (such as the vub300 MMC driver) expect usb_string() to
      return a properly NUL-terminated string, even when an error occurs.
      (In fact, vub300's probe routine doesn't bother to check the return
      code from usb_string().)  When the driver goes on to use an
      unterminated string, it leads to kernel errors such as
      stack-out-of-bounds, as found by the syzkaller USB fuzzer.
      
      An out-of-range string index argument is not at all unlikely, given
      that some devices don't provide string descriptors and therefore list
      0 as the value for their string indexes.  This patch makes
      usb_string() return a properly terminated empty string along with the
      -EINVAL error code when an out-of-range index is encountered.
      
      And since a USB string index is a single-byte value, indexes >= 256
      are just as invalid as values of 0 or below.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: syzbot+b75b85111c10b8d680f1@syzkaller.appspotmail.com
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7bbbb95a
    • Malte Leip's avatar
      usb: usbip: fix isoc packet num validation in get_pipe · 616ba129
      Malte Leip authored
      commit c409ca3b upstream.
      
      Change the validation of number_of_packets in get_pipe to compare the
      number of packets to a fixed maximum number of packets allowed, set to
      be 1024. This number was chosen due to it being used by other drivers as
      well, for example drivers/usb/host/uhci-q.c
      
      Background/reason:
      The get_pipe function in stub_rx.c validates the number of packets in
      isochronous mode and aborts with an error if that number is too large,
      in order to prevent malicious input from possibly triggering large
      memory allocations. This was previously done by checking whether
      pdu->u.cmd_submit.number_of_packets is bigger than the number of packets
      that would be needed for pdu->u.cmd_submit.transfer_buffer_length bytes
      if all except possibly the last packet had maximum length, given by
      usb_endpoint_maxp(epd) *  usb_endpoint_maxp_mult(epd). This leads to an
      error if URBs with packets shorter than the maximum possible length are
      submitted, which is allowed according to
      Documentation/driver-api/usb/URB.rst and occurs for example with the
      snd-usb-audio driver.
      
      Fixes: c6688ef9 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input")
      Signed-off-by: default avatarMalte Leip <malte@leip.net>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      616ba129
    • Alan Stern's avatar
      USB: w1 ds2490: Fix bug caused by improper use of altsetting array · 6f6bbb66
      Alan Stern authored
      commit c114944d upstream.
      
      The syzkaller USB fuzzer spotted a slab-out-of-bounds bug in the
      ds2490 driver.  This bug is caused by improper use of the altsetting
      array in the usb_interface structure (the array's entries are not
      always stored in numerical order), combined with a naive assumption
      that all interfaces probed by the driver will have the expected number
      of altsettings.
      
      The bug can be fixed by replacing references to the possibly
      non-existent intf->altsetting[alt] entry with the guaranteed-to-exist
      intf->cur_altsetting entry.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: syzbot+d65f673b847a1a96cdba@syzkaller.appspotmail.com
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f6bbb66
    • Alan Stern's avatar
      USB: yurex: Fix protection fault after device removal · 965cc840
      Alan Stern authored
      commit ef61eb43 upstream.
      
      The syzkaller USB fuzzer found a general-protection-fault bug in the
      yurex driver.  The fault occurs when a device has been unplugged; the
      driver's interrupt-URB handler logs an error message referring to the
      device by name, after the device has been unregistered and its name
      deallocated.
      
      This problem is caused by the fact that the interrupt URB isn't
      cancelled until the driver's private data structure is released, which
      can happen long after the device is gone.  The cure is to make sure
      that the interrupt URB is killed before yurex_disconnect() returns;
      this is exactly the sort of thing that usb_poison_urb() was meant for.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: syzbot+2eb9121678bdb36e6d57@syzkaller.appspotmail.com
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      965cc840
    • Arnd Bergmann's avatar
      caif: reduce stack size with KASAN · ff5ca554
      Arnd Bergmann authored
      commit ce628966 upstream.
      
      When CONFIG_KASAN is set, we can use relatively large amounts of kernel
      stack space:
      
      net/caif/cfctrl.c:555:1: warning: the frame size of 1600 bytes is larger than 1280 bytes [-Wframe-larger-than=]
      
      This adds convenience wrappers around cfpkt_extr_head(), which is responsible
      for most of the stack growth. With those wrapper functions, gcc apparently
      starts reusing the stack slots for each instance, thus avoiding the
      problem.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ff5ca554