1. 07 2月, 2019 2 次提交
    • M
      dm: don't use bio_trim() afterall · fa8db494
      Mike Snitzer 提交于
      bio_trim() has an early return, which makes it _not_ idempotent, if the
      offset is 0 and the bio's bi_size already matches the requested size.
      Prior to DM, all users of bio_trim() were fine with this.  But DM has
      exposed the fact that bio_trim()'s early return is incompatible with a
      cloned bio whose integrity payload must be trimmed via
      bio_integrity_trim().
      
      Fix this by reverting DM back to doing the equivalent of bio_trim() but
      in an idempotent manner (so bio_integrity_trim is always performed).
      
      Follow-on work is needed to assess what benefit bio_trim()'s early
      return is providing to its existing callers.
      Reported-by: NMilan Broz <gmazyland@gmail.com>
      Fixes: 57c36519 ("dm: fix clone_bio() to trigger blk_recount_segments()")
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      fa8db494
    • M
      dm: add memory barrier before waitqueue_active · 645efa84
      Mikulas Patocka 提交于
      Block core changes to switch bio-based IO accounting to be percpu had a
      side-effect of altering DM core to now rely on calling waitqueue_active
      (in both bio-based and request-based) to check if another task is in
      dm_wait_for_completion().
      
      A memory barrier is needed before calling waitqueue_active().  DM core
      doesn't piggyback on a preceding memory barrier so it must explicitly
      use its own.
      
      For more details on why using waitqueue_active() without a preceding
      barrier is unsafe, please see the comment before the waitqueue_active()
      definition in include/linux/wait.h.
      
      Add the missing memory barrier by switching to using wq_has_sleeper().
      
      Fixes: 6f757231 ("dm: remove the pending IO accounting")
      Fixes: c4576aed ("dm: fix request-based dm's use of dm_wait_for_completion")
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      645efa84
  2. 06 2月, 2019 1 次提交
  3. 02 2月, 2019 1 次提交
    • Q
      efi/arm64: Fix debugfs crash by adding a terminator for ptdump marker · 74c953ca
      Qian Cai 提交于
      When reading 'efi_page_tables' debugfs triggers an out-of-bounds access here:
      
        arch/arm64/mm/dump.c: 282
        if (addr >= st->marker[1].start_address) {
      
      called from:
      
        arch/arm64/mm/dump.c: 331
        note_page(st, addr, 2, pud_val(pud));
      
      because st->marker++ is is called after "UEFI runtime end" which is the
      last element in addr_marker[]. Therefore, add a terminator like the one
      for kernel_page_tables, so it can be skipped to print out non-existent
      markers.
      
      Here's the KASAN bug report:
      
        # cat /sys/kernel/debug/efi_page_tables
        ---[ UEFI runtime start ]---
        0x0000000020000000-0x0000000020010000          64K PTE       RW NX SHD AF ...
        0x0000000020200000-0x0000000021340000       17664K PTE       RW NX SHD AF ...
        ...
        0x0000000021920000-0x0000000021950000         192K PTE       RW x  SHD AF ...
        0x0000000021950000-0x00000000219a0000         320K PTE       RW NX SHD AF ...
        ---[ UEFI runtime end ]---
        ---[ (null) ]---
        ---[ (null) ]---
      
         BUG: KASAN: global-out-of-bounds in note_page+0x1f0/0xac0
         Read of size 8 at addr ffff2000123f2ac0 by task read_all/42464
         Call trace:
          dump_backtrace+0x0/0x298
          show_stack+0x24/0x30
          dump_stack+0xb0/0xdc
          print_address_description+0x64/0x2b0
          kasan_report+0x150/0x1a4
          __asan_report_load8_noabort+0x30/0x3c
          note_page+0x1f0/0xac0
          walk_pgd+0xb4/0x244
          ptdump_walk_pgd+0xec/0x140
          ptdump_show+0x40/0x50
          seq_read+0x3f8/0xad0
          full_proxy_read+0x9c/0xc0
          __vfs_read+0xfc/0x4c8
          vfs_read+0xec/0x208
          ksys_read+0xd0/0x15c
          __arm64_sys_read+0x84/0x94
          el0_svc_handler+0x258/0x304
          el0_svc+0x8/0xc
      
        The buggy address belongs to the variable:
         __compound_literal.0+0x20/0x800
      
        Memory state around the buggy address:
         ffff2000123f2980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         ffff2000123f2a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
        >ffff2000123f2a80: fa fa fa fa 00 00 00 00 fa fa fa fa 00 00 00 00
                                                  ^
         ffff2000123f2b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         ffff2000123f2b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
      
      [ ardb: fix up whitespace ]
      [ mingo: fix up some moar ]
      Signed-off-by: NQian Cai <cai@lca.pw>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Fixes: 9d80448a ("efi/arm64: Add debugfs node to dump UEFI runtime page tables")
      Link: http://lkml.kernel.org/r/20190202095017.13799-2-ard.biesheuvel@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      74c953ca
  4. 01 2月, 2019 3 次提交
  5. 31 1月, 2019 3 次提交
    • J
      ide: ensure atapi sense request aren't preempted · 9a6d5488
      Jens Axboe 提交于
      There's an issue with how sense requests are handled in IDE. If ide-cd
      encounters an error, it queues a sense request. With how IDE request
      handling is done, this is the next request we need to handle. But it's
      impossible to guarantee this, as another request could come in between
      the sense being queued, and ->queue_rq() being run and handling it. If
      that request ALSO fails, then we attempt to doubly queue the single
      sense request we have.
      
      Since we only support one active request at the time, defer request
      processing when a sense request is queued.
      
      Fixes: 60033520 "ide: convert to blk-mq"
      Reported-by: NHe Zhe <zhe.he@windriver.com>
      Tested-by: NHe Zhe <zhe.he@windriver.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      9a6d5488
    • D
      cpuidle: poll_state: Fix default time limit · 1617971c
      Doug Smythies 提交于
      The default time is declared in units of microsecnds,
      but is used as nanoseconds, resulting in significant
      accounting errors for idle state 0 time when all idle
      states deeper than 0 are disabled.
      
      Under these unusual conditions, we don't really care
      about the poll time limit anyhow.
      
      Fixes: 800fb34a ("cpuidle: poll_state: Disregard disable idle states")
      Signed-off-by: NDoug Smythies <dsmythies@telus.net>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1617971c
    • V
      PM-runtime: Fix deadlock with ktime_get() · 15efb47d
      Vincent Guittot 提交于
      A deadlock has been seen when swicthing clocksources which use
      PM-runtime.  The call path is:
      
      change_clocksource
          ...
          write_seqcount_begin
          ...
          timekeeping_update
              ...
              sh_cmt_clocksource_enable
                  ...
                  rpm_resume
                      pm_runtime_mark_last_busy
                          ktime_get
                              do
                                  read_seqcount_begin
                              while read_seqcount_retry
          ....
          write_seqcount_end
      
      Although we should be safe because we haven't yet changed the
      clocksource at that time, we can't do that because of seqcount
      protection.
      
      Use ktime_get_mono_fast_ns() instead which is lock safe for such
      cases.
      
      With ktime_get_mono_fast_ns, the timestamp is not guaranteed to be
      monotonic across an update and as a result can goes backward.
      According to update_fast_timekeeper() description: "In the worst
      case, this can result is a slightly wrong timestamp (a few
      nanoseconds)". For PM-runtime autosuspend, this means only that
      the suspend decision may be slightly suboptimal.
      
      Fixes: 8234f673 ("PM-runtime: Switch autosuspend over to using hrtimers")
      Reported-by: NBiju Das <biju.das@bp.renesas.com>
      Signed-off-by: NVincent Guittot <vincent.guittot@linaro.org>
      Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      15efb47d
  6. 30 1月, 2019 5 次提交
    • Y
      IB/uverbs: Fix OOPs in uverbs_user_mmap_disassociate · 7b21b69a
      Yishai Hadas 提交于
      The vma->vm_mm can become impossible to get before rdma_umap_close() is
      called, in this case we must not try to get an mm that is already
      undergoing process exit. In this case there is no need to wait for
      anything as the VMA will be destroyed by another thread soon and is
      already effectively 'unreachable' by userspace.
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       PGD 800000012bc50067 P4D 800000012bc50067 PUD 129db5067 PMD 0
       Oops: 0000 [#1] SMP PTI
       CPU: 1 PID: 2050 Comm: bash Tainted: G        W  OE 4.20.0-rc6+ #3
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       RIP: 0010:__rb_erase_color+0xb9/0x280
       Code: 84 17 01 00 00 48 3b 68 10 0f 84 15 01 00 00 48 89
                     58 08 48 89 de 48 89 ef 4c 89 e3 e8 90 84 22 00 e9 60 ff ff ff 48 8b 5d
                     10 <f6> 03 01 0f 84 9c 00 00 00 48 8b 43 10 48 85 c0 74 09 f6 00 01 0f
       RSP: 0018:ffffbecfc090bab8 EFLAGS: 00010246
       RAX: ffff97616346cf30 RBX: 0000000000000000 RCX: 0000000000000101
       RDX: 0000000000000000 RSI: ffff97623b6ca828 RDI: ffff97621ef10828
       RBP: ffff97621ef10828 R08: ffff97621ef10828 R09: 0000000000000000
       R10: 0000000000000000 R11: 0000000000000000 R12: ffff97623b6ca838
       R13: ffffffffbb3fef50 R14: ffff97623b6ca828 R15: 0000000000000000
       FS:  00007f7a5c31d740(0000) GS:ffff97623bb00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 000000011255a000 CR4: 00000000000006e0
       Call Trace:
        unlink_file_vma+0x3b/0x50
        free_pgtables+0xa1/0x110
        exit_mmap+0xca/0x1a0
        ? mlx5_ib_dealloc_pd+0x28/0x30 [mlx5_ib]
        mmput+0x54/0x140
        uverbs_user_mmap_disassociate+0xcc/0x160 [ib_uverbs]
        uverbs_destroy_ufile_hw+0xf7/0x120 [ib_uverbs]
        ib_uverbs_remove_one+0xea/0x240 [ib_uverbs]
        ib_unregister_device+0xfb/0x200 [ib_core]
        mlx5_ib_remove+0x51/0xe0 [mlx5_ib]
        mlx5_remove_device+0xc1/0xd0 [mlx5_core]
        mlx5_unregister_device+0x3d/0xb0 [mlx5_core]
        remove_one+0x2a/0x90 [mlx5_core]
        pci_device_remove+0x3b/0xc0
        device_release_driver_internal+0x16d/0x240
        unbind_store+0xb2/0x100
        kernfs_fop_write+0x102/0x180
        __vfs_write+0x36/0x1a0
        ? __alloc_fd+0xa9/0x170
        ? set_close_on_exec+0x49/0x70
        vfs_write+0xad/0x1a0
        ksys_write+0x52/0xc0
        do_syscall_64+0x5b/0x180
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Cc: <stable@vger.kernel.org> # 4.19
      Fixes: 5f9794dc ("RDMA/ucontext: Add a core API for mmaping driver IO memory")
      Signed-off-by: NYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      7b21b69a
    • Y
      net: b44: replace dev_kfree_skb_xxx by dev_consume_skb_xxx for drop profiles · 0f0ed828
      Yang Wei 提交于
      The skb should be freed by dev_consume_skb_any() in b44_start_xmit()
      when bounce_skb is used. The skb is be replaced by bounce_skb, so the
      original skb should be consumed(not drop).
      
      dev_consume_skb_irq() should be called in b44_tx() when skb xmit
      done. It makes drop profiles(dropwatch, perf) more friendly.
      Signed-off-by: NYang Wei <yang.wei9@zte.com.cn>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0f0ed828
    • Y
      net: caif: call dev_consume_skb_any when skb xmit done · e339f863
      Yang Wei 提交于
      The skb shouled be consumed when xmit done, it makes drop profiles
      (dropwatch, perf) more friendly.
      dev_kfree_skb_irq()/kfree_skb() shouled be replaced by
      dev_consume_skb_any(), it makes code cleaner.
      Signed-off-by: NYang Wei <yang.wei9@zte.com.cn>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e339f863
    • Y
      net: 8139cp: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles · 896cebc0
      Yang Wei 提交于
      dev_consume_skb_irq() should be called in cp_tx() when skb xmit
      done. It makes drop profiles(dropwatch, perf) more friendly.
      Signed-off-by: NYang Wei <yang.wei9@zte.com.cn>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      896cebc0
    • H
      net: macb: Apply RXUBR workaround only to versions with errata · e501070e
      Harini Katakam 提交于
      The interrupt handler contains a workaround for RX hang applicable
      to Zynq and AT91RM9200 only. Subsequent versions do not need this
      workaround. This workaround unnecessarily resets RX whenever RX used
      bit read is observed, which can be often under heavy traffic. There
      is no other action performed on RX UBR interrupt. Hence introduce a
      CAPS mask; enable this interrupt and workaround only on affected
      versions.
      Signed-off-by: NHarini Katakam <harini.katakam@xilinx.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e501070e
  7. 29 1月, 2019 21 次提交
    • V
      HID: debug: fix the ring buffer implementation · 13054abb
      Vladis Dronov 提交于
      Ring buffer implementation in hid_debug_event() and hid_debug_events_read()
      is strange allowing lost or corrupted data. After commit 717adfda
      ("HID: debug: check length before copy_to_user()") it is possible to enter
      an infinite loop in hid_debug_events_read() by providing 0 as count, this
      locks up a system. Fix this by rewriting the ring buffer implementation
      with kfifo and simplify the code.
      
      This fixes CVE-2019-3819.
      
      v2: fix an execution logic and add a comment
      v3: use __set_current_state() instead of set_current_state()
      
      Link: https://bugzilla.redhat.com/show_bug.cgi?id=1669187
      Cc: stable@vger.kernel.org # v4.18+
      Fixes: cd667ce2 ("HID: use debugfs for events/reports dumping")
      Fixes: 717adfda ("HID: debug: check length before copy_to_user()")
      Signed-off-by: NVladis Dronov <vdronov@redhat.com>
      Reviewed-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      13054abb
    • S
      platform/x86: Fix unmet dependency warning for SAMSUNG_Q10 · 0ee4b5f8
      Sinan Kaya 提交于
      Add BACKLIGHT_LCD_SUPPORT for SAMSUNG_Q10 to fix the
      warning: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE.
      
      SAMSUNG_Q10 selects BACKLIGHT_CLASS_DEVICE but BACKLIGHT_CLASS_DEVICE
      depends on BACKLIGHT_LCD_SUPPORT.
      
      Copy BACKLIGHT_LCD_SUPPORT dependency into SAMSUNG_Q10 to fix:
      
      WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE
        Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n]
        Selected by [y]:
        - SAMSUNG_Q10 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI [=y]
      Signed-off-by: NSinan Kaya <okaya@kernel.org>
      Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0ee4b5f8
    • S
      platform/x86: Fix unmet dependency warning for ACPI_CMPC · d58bf90a
      Sinan Kaya 提交于
      Add BACKLIGHT_LCD_SUPPORT for ACPI_CMPC to fix the
      warning: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE.
      
      ACPI_CMPC selects BACKLIGHT_CLASS_DEVICE but BACKLIGHT_CLASS_DEVICE
      depends on BACKLIGHT_LCD_SUPPORT.
      
      Copy BACKLIGHT_LCD_SUPPORT dependency into ACPI_CMPC to fix
      
      WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE
        Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n]
        Selected by [y]:
        - ACPI_CMPC [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI [=y] && INPUT [=y] && (RFKILL [=n] || RFKILL [=n]=n)
      Signed-off-by: NSinan Kaya <okaya@kernel.org>
      Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d58bf90a
    • S
      mfd: Fix unmet dependency warning for MFD_TPS68470 · 9baddb61
      Sinan Kaya 提交于
      After commit 5d32a665 ("PCI/ACPI: Allow ACPI to be built without
      CONFIG_PCI set") dependencies on CONFIG_PCI that previously were
      satisfied implicitly through dependencies on CONFIG_ACPI have to be
      specified directly.
      
      WARNING: unmet direct dependencies detected for I2C_DESIGNWARE_PLATFORM
        Depends on [n]: I2C [=y] && HAS_IOMEM [=y] && (ACPI [=y] && COMMON_CLK [=n] || !ACPI [=y])
        Selected by [y]:
        - MFD_TPS68470 [=y] && HAS_IOMEM [=y] && ACPI [=y] && I2C [=y]=y
      
      MFD_TPS68470 is an ACPI only device and selects I2C_DESIGNWARE_PLATFORM.
      
      I2C_DESIGNWARE_PLATFORM does not have any configuration today for ACPI
      support without CONFIG_PCI set.
      
      For sake of a quick fix this introduces a new mandatory dependency to
      the driver which may survive without it. Otherwise we need to revisit
      the driver architecture to address this properly.
      
      Fixes: 5d32a665 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
      Signed-off-by: NSinan Kaya <okaya@kernel.org>
      Acked-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9baddb61
    • Y
      net: ti: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles · b3379a42
      Yang Wei 提交于
      dev_consume_skb_irq() should be called in cpmac_end_xmit() when
      xmit done. It makes drop profiles more friendly.
      Signed-off-by: NYang Wei <yang.wei9@zte.com.cn>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b3379a42
    • Y
      net: apple: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles · 10009115
      Yang Wei 提交于
      dev_consume_skb_irq() should be called in bmac_txdma_intr() when
      xmit done. It makes drop profiles more friendly.
      Signed-off-by: NYang Wei <yang.wei9@zte.com.cn>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      10009115
    • AlbinYang's avatar
      net: amd8111e: replace dev_kfree_skb_irq by dev_consume_skb_irq · 3afa73dd
      AlbinYang 提交于
      dev_consume_skb_irq() should be called in amd8111e_tx() when xmit
      done. It makes drop profiles more friendly.
      Signed-off-by: NYang Wei <yang.wei9@zte.com.cn>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3afa73dd
    • AlbinYang's avatar
      net: alteon: replace dev_kfree_skb_irq by dev_consume_skb_irq · f48af114
      AlbinYang 提交于
      dev_consume_skb_irq() should be called in ace_tx_int() when xmit
      done. It makes drop profiles more friendly.
      Signed-off-by: NYang Wei <yang.wei9@zte.com.cn>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f48af114
    • J
      vhost: fix OOB in get_rx_bufs() · b46a0bf7
      Jason Wang 提交于
      After batched used ring updating was introduced in commit e2b3b35e
      ("vhost_net: batch used ring update in rx"). We tend to batch heads in
      vq->heads for more than one packet. But the quota passed to
      get_rx_bufs() was not correctly limited, which can result a OOB write
      in vq->heads.
      
              headcount = get_rx_bufs(vq, vq->heads + nvq->done_idx,
                          vhost_len, &in, vq_log, &log,
                          likely(mergeable) ? UIO_MAXIOV : 1);
      
      UIO_MAXIOV was still used which is wrong since we could have batched
      used in vq->heads, this will cause OOB if the next buffer needs more
      than 960 (1024 (UIO_MAXIOV) - 64 (VHOST_NET_BATCH)) heads after we've
      batched 64 (VHOST_NET_BATCH) heads:
      Acked-by: NStefan Hajnoczi <stefanha@redhat.com>
      
      =============================================================================
      BUG kmalloc-8k (Tainted: G    B            ): Redzone overwritten
      -----------------------------------------------------------------------------
      
      INFO: 0x00000000fd93b7a2-0x00000000f0713384. First byte 0xa9 instead of 0xcc
      INFO: Allocated in alloc_pd+0x22/0x60 age=3933677 cpu=2 pid=2674
          kmem_cache_alloc_trace+0xbb/0x140
          alloc_pd+0x22/0x60
          gen8_ppgtt_create+0x11d/0x5f0
          i915_ppgtt_create+0x16/0x80
          i915_gem_create_context+0x248/0x390
          i915_gem_context_create_ioctl+0x4b/0xe0
          drm_ioctl_kernel+0xa5/0xf0
          drm_ioctl+0x2ed/0x3a0
          do_vfs_ioctl+0x9f/0x620
          ksys_ioctl+0x6b/0x80
          __x64_sys_ioctl+0x11/0x20
          do_syscall_64+0x43/0xf0
          entry_SYSCALL_64_after_hwframe+0x44/0xa9
      INFO: Slab 0x00000000d13e87af objects=3 used=3 fp=0x          (null) flags=0x200000000010201
      INFO: Object 0x0000000003278802 @offset=17064 fp=0x00000000e2e6652b
      
      Fixing this by allocating UIO_MAXIOV + VHOST_NET_BATCH iovs for
      vhost-net. This is done through set the limitation through
      vhost_dev_init(), then set_owner can allocate the number of iov in a
      per device manner.
      
      This fixes CVE-2018-16880.
      
      Fixes: e2b3b35e ("vhost_net: batch used ring update in rx")
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b46a0bf7
    • D
      scsi: 53c700: pass correct "dev" to dma_alloc_attrs() · 8437fcf1
      Dan Carpenter 提交于
      The "hostdata->dev" pointer is NULL here.  We set "hostdata->dev = dev;"
      later in the function and we also use "hostdata->dev" when we call
      dma_free_attrs() in NCR_700_release().
      
      This bug predates git version control.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      8437fcf1
    • D
      scsi: bnx2fc: Fix error handling in probe() · b2d3492f
      Dan Carpenter 提交于
      There are two issues here.  First if cmgr->hba is not set early enough then
      it leads to a NULL dereference.  Second if we don't completely initialize
      cmgr->io_bdt_pool[] then we end up dereferencing uninitialized pointers.
      
      Fixes: 853e2bd2 ("[SCSI] bnx2fc: Broadcom FCoE offload driver")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      b2d3492f
    • D
      scsi: scsi_debug: fix write_same with virtual_gb problem · 40d07b52
      Douglas Gilbert 提交于
      The WRITE SAME(10) and (16) implementations didn't take account of the
      buffer wrap required when the virtual_gb parameter is greater than 0.
      
      Fix that and rename the fake_store() function to lba2fake_store() to lessen
      confusion with the global fake_storep pointer. Bump version date.
      Signed-off-by: NDouglas Gilbert <dgilbert@interlog.com>
      Reported-by: NBart Van Assche <bvanassche@acm.org>
      Tested by: Bart Van Assche <bvanassche@acm.org>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      40d07b52
    • M
      scsi: libfc: free skb when receiving invalid flogi resp · 5d8fc4a9
      Ming Lu 提交于
      The issue to be fixed in this commit is when libfc found it received a
      invalid FLOGI response from FC switch, it would return without freeing the
      fc frame, which is just the skb data. This would cause memory leak if FC
      switch keeps sending invalid FLOGI responses.
      
      This fix is just to make it execute `fc_frame_free(fp)` before returning
      from function `fc_lport_flogi_resp`.
      Signed-off-by: NMing Lu <ming.lu@citrix.com>
      Reviewed-by: NHannes Reinecke <hare@suse.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      5d8fc4a9
    • S
      scsi: zfcp: fix sysfs block queue limit output for max_segment_size · b6319569
      Steffen Maier 提交于
      Since v2.6.35 commit 68322984 ("[SCSI] zfcp: Report scatter-gather
      limits to SCSI and block layer"), zfcp set dma_parms.max_segment_size ==
      PAGE_SIZE (but without using the setter dma_set_max_seg_size()) and
      scsi_host_template.dma_boundary == PAGE_SIZE - 1.
      
      v5.0-rc1 commit 50c2e910 ("scsi: introduce a max_segment_size
      host_template parameters") introduced a new field
      scsi_host_template.max_segment_size. If an LLDD such as zfcp does not set
      it, scsi_host_alloc() uses BLK_MAX_SEGMENT_SIZE = 65536 for
      Scsi_Host.max_segment_size. __scsi_init_queue() announced the minimum of
      Scsi_Host.max_segment_size and dma_parms.max_segment_size to the block
      layer. For zfcp: min(65536, 4096) == 4096 which was still good.
      
      v5.0 commit a8cf59a6 ("scsi: communicate max segment size to the DMA
      mapping code") announces Scsi_Host.max_segment_size to the block layer and
      overwrites dma_parms.max_segment_size with Scsi_Host.max_segment_size.  For
      zfcp dma_parms.max_segment_size == Scsi_Host.max_segment_size == 65536
      which is also reflected in block queue limits.
      
      $ cd /sys/bus/ccw/drivers/zfcp
      $ cd 0.0.3c40/host5/rport-5:0-4/target5:0:4/5:0:4:10/block/sdi/queue
      $ cat max_segment_size
      65536
      
      Zfcp I/O still works because dma_boundary implicitly still keeps the
      effective max segment size <= PAGE_SIZE.  However, dma_boundary does not
      seem visible to user space, but max_segment_size is visible and shows a
      misleading wrong value.  Fix it and inherit the stable tag of a8cf59a6.
      
      Devices on our bus ccw support DMA but no DMA mapping. Of multiple device
      types on the ccw bus, only zfcp needs dma_parms for SCSI limits.  So, leave
      dma_parms setup in zfcp and do not move it to the bus.
      Signed-off-by: NSteffen Maier <maier@linux.ibm.com>
      Fixes: 50c2e910 ("scsi: introduce a max_segment_size host_template parameters")
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      b6319569
    • A
      md/raid5: fix 'out of memory' during raid cache recovery · 483cbbed
      Alexei Naberezhnov 提交于
      This fixes the case when md array assembly fails because of raid cache recovery
      unable to allocate a stripe, despite attempts to replay stripes and increase
      cache size. This happens because stripes released by r5c_recovery_replay_stripes
      and raid5_set_cache_size don't become available for allocation immediately.
      Released stripes first are placed on conf->released_stripes list and require
      md thread to merge them on conf->inactive_list before they can be allocated.
      
      Patch allows final allocation attempt during cache recovery to wait for
      new stripes to become availabe for allocation.
      
      Cc: linux-raid@vger.kernel.org
      Cc: Shaohua Li <shli@kernel.org>
      Cc: linux-stable <stable@vger.kernel.org> # 4.10+
      Fixes: b4c625c6 ("md/r5cache: r5cache recovery: part 1")
      Signed-off-by: NAlexei Naberezhnov <anaberezhnov@fb.com>
      Signed-off-by: NSong Liu <songliubraving@fb.com>
      483cbbed
    • M
      qed: Fix stack out of bounds bug · ffb057f9
      Manish Chopra 提交于
      KASAN reported following bug in qed_init_qm_get_idx_from_flags
      due to inappropriate casting of "pq_flags". Fix the type of "pq_flags".
      
      [  196.624707] BUG: KASAN: stack-out-of-bounds in qed_init_qm_get_idx_from_flags+0x1a4/0x1b8 [qed]
      [  196.624712] Read of size 8 at addr ffff809b00bc7360 by task kworker/0:9/1712
      [  196.624714]
      [  196.624720] CPU: 0 PID: 1712 Comm: kworker/0:9 Not tainted 4.18.0-60.el8.aarch64+debug #1
      [  196.624723] Hardware name: To be filled by O.E.M. Saber/Saber, BIOS 0ACKL024 09/26/2018
      [  196.624733] Workqueue: events work_for_cpu_fn
      [  196.624738] Call trace:
      [  196.624742]  dump_backtrace+0x0/0x2f8
      [  196.624745]  show_stack+0x24/0x30
      [  196.624749]  dump_stack+0xe0/0x11c
      [  196.624755]  print_address_description+0x68/0x260
      [  196.624759]  kasan_report+0x178/0x340
      [  196.624762]  __asan_report_load_n_noabort+0x38/0x48
      [  196.624786]  qed_init_qm_get_idx_from_flags+0x1a4/0x1b8 [qed]
      [  196.624808]  qed_init_qm_info+0xec0/0x2200 [qed]
      [  196.624830]  qed_resc_alloc+0x284/0x7e8 [qed]
      [  196.624853]  qed_slowpath_start+0x6cc/0x1ae8 [qed]
      [  196.624864]  __qede_probe.isra.10+0x1cc/0x12c0 [qede]
      [  196.624874]  qede_probe+0x78/0xf0 [qede]
      [  196.624879]  local_pci_probe+0xc4/0x180
      [  196.624882]  work_for_cpu_fn+0x54/0x98
      [  196.624885]  process_one_work+0x758/0x1900
      [  196.624888]  worker_thread+0x4e0/0xd18
      [  196.624892]  kthread+0x2c8/0x350
      [  196.624897]  ret_from_fork+0x10/0x18
      [  196.624899]
      [  196.624902] Allocated by task 2:
      [  196.624906]  kasan_kmalloc.part.1+0x40/0x108
      [  196.624909]  kasan_kmalloc+0xb4/0xc8
      [  196.624913]  kasan_slab_alloc+0x14/0x20
      [  196.624916]  kmem_cache_alloc_node+0x1dc/0x480
      [  196.624921]  copy_process.isra.1.part.2+0x1d8/0x4a98
      [  196.624924]  _do_fork+0x150/0xfa0
      [  196.624926]  kernel_thread+0x48/0x58
      [  196.624930]  kthreadd+0x3a4/0x5a0
      [  196.624932]  ret_from_fork+0x10/0x18
      [  196.624934]
      [  196.624937] Freed by task 0:
      [  196.624938] (stack is not available)
      [  196.624940]
      [  196.624943] The buggy address belongs to the object at ffff809b00bc0000
      [  196.624943]  which belongs to the cache thread_stack of size 32768
      [  196.624946] The buggy address is located 29536 bytes inside of
      [  196.624946]  32768-byte region [ffff809b00bc0000, ffff809b00bc8000)
      [  196.624948] The buggy address belongs to the page:
      [  196.624952] page:ffff7fe026c02e00 count:1 mapcount:0 mapping:ffff809b4001c000 index:0x0 compound_mapcount: 0
      [  196.624960] flags: 0xfffff8000008100(slab|head)
      [  196.624967] raw: 0fffff8000008100 dead000000000100 dead000000000200 ffff809b4001c000
      [  196.624970] raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000
      [  196.624973] page dumped because: kasan: bad access detected
      [  196.624974]
      [  196.624976] Memory state around the buggy address:
      [  196.624980]  ffff809b00bc7200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  196.624983]  ffff809b00bc7280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  196.624985] >ffff809b00bc7300: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f2 f2 f2
      [  196.624988]                                                        ^
      [  196.624990]  ffff809b00bc7380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  196.624993]  ffff809b00bc7400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  196.624995] ==================================================================
      Signed-off-by: NManish Chopra <manishc@marvell.com>
      Signed-off-by: NAriel Elior <aelior@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ffb057f9
    • M
      qed: Fix system crash in ll2 xmit · 7c81626a
      Manish Chopra 提交于
      Cache number of fragments in the skb locally as in case
      of linear skb (with zero fragments), tx completion
      (or freeing of skb) may happen before driver tries
      to get number of frgaments from the skb which could
      lead to stale access to an already freed skb.
      Signed-off-by: NManish Chopra <manishc@marvell.com>
      Signed-off-by: NAriel Elior <aelior@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c81626a
    • M
      qed: Fix VF probe failure while FLR · 327852ec
      Manish Chopra 提交于
      VFs may hit VF-PF channel timeout while probing, as in some
      cases it was observed that VF FLR and VF "acquire" message
      transaction (i.e first message from VF to PF in VF's probe flow)
      could occur simultaneously which could lead VF to fail sending
      "acquire" message to PF as VF is marked disabled from HW perspective
      due to FLR, which will result into channel timeout and VF probe failure.
      
      In such cases, try retrying VF "acquire" message so that in later
      attempts it could be successful to pass message to PF after the VF
      FLR is completed and can be probed successfully.
      Signed-off-by: NManish Chopra <manishc@marvell.com>
      Signed-off-by: NAriel Elior <aelior@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      327852ec
    • M
      qed: Fix LACP pdu drops for VFs · ff929696
      Manish Chopra 提交于
      VF is always configured to drop control frames
      (with reserved mac addresses) but to work LACP
      on the VFs, it would require LACP control frames
      to be forwarded or transmitted successfully.
      
      This patch fixes this in such a way that trusted VFs
      (marked through ndo_set_vf_trust) would be allowed to
      pass the control frames such as LACP pdus.
      Signed-off-by: NManish Chopra <manishc@marvell.com>
      Signed-off-by: NAriel Elior <aelior@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ff929696
    • M
      qed: Fix bug in tx promiscuous mode settings · 9e71a15d
      Manish Chopra 提交于
      When running tx switched traffic between VNICs
      created via a bridge(to which VFs are added),
      adapter drops the unicast packets in tx flow due to
      VNIC's ucast mac being unknown to it. But VF interfaces
      being in promiscuous mode should have caused adapter
      to accept all the unknown ucast packets. Later, it
      was found that driver doesn't really configure tx
      promiscuous mode settings to accept all unknown unicast macs.
      
      This patch fixes tx promiscuous mode settings to accept all
      unknown/unmatched unicast macs and works out the scenario.
      Signed-off-by: NManish Chopra <manishc@marvell.com>
      Signed-off-by: NAriel Elior <aelior@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9e71a15d
    • AlbinYang's avatar
      net: i825xx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles · ca899324
      AlbinYang 提交于
      dev_consume_skb_irq() should be called in i596_interrupt() when skb
      xmit done. It makes drop profiles(dropwatch, perf) more friendly.
      Signed-off-by: AlbinYang's avatarYang Wei <albin_yang@163.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ca899324
  8. 28 1月, 2019 4 次提交
新手
引导
客服 返回
顶部