1. 04 Jan, 2020 32 commits
  2. 21 Dec, 2019 8 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.9.207 · 5b7a2c7d
      Greg Kroah-Hartman authored
      5b7a2c7d
    • Aaro Koskinen's avatar
      net: stmmac: don't stop NAPI processing when dropping a packet · 33457946
      Aaro Koskinen authored
      commit 07b39753 upstream.
      
      Currently, if we drop a packet, we exit from NAPI loop before the budget
      is consumed. In some situations this will make the RX processing stall
      e.g. when flood pinging the system with oversized packets, as the
      errorneous packets are not dropped efficiently.
      
      If we drop a packet, we should just continue to the next one as long as
      the budget allows.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [acj: backport v4.9 -stable
      -adjust context]
      Signed-off-by: default avatarAviraj CJ <acj@cisco.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33457946
    • Aaro Koskinen's avatar
      net: stmmac: use correct DMA buffer size in the RX descriptor · 7e3efae8
      Aaro Koskinen authored
      commit 583e6361 upstream.
      
      We always program the maximum DMA buffer size into the receive descriptor,
      although the allocated size may be less. E.g. with the default MTU size
      we allocate only 1536 bytes. If somebody sends us a bigger frame, then
      memory may get corrupted.
      
      Fix by using exact buffer sizes.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [acj: backport to v4.9 -stable :
      - adjust context
      - skipped the section modifying non-existent functions in dwxgmac2_descs.c and
      hwif.h ]
      Signed-off-by: default avatarAviraj CJ <acj@cisco.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7e3efae8
    • Mathias Nyman's avatar
      xhci: fix USB3 device initiated resume race with roothub autosuspend · d93f4bce
      Mathias Nyman authored
      commit 057d476f upstream.
      
      A race in xhci USB3 remote wake handling may force device back to suspend
      after it initiated resume siganaling, causing a missed resume event or warm
      reset of device.
      
      When a USB3 link completes resume signaling and goes to enabled (UO)
      state a interrupt is issued and the interrupt handler will clear the
      bus_state->port_remote_wakeup resume flag, allowing bus suspend.
      
      If the USB3 roothub thread just finished reading port status before
      the interrupt, finding ports still in suspended (U3) state, but hasn't
      yet started suspending the hub, then the xhci interrupt handler will clear
      the flag that prevented roothub suspend and allow bus to suspend, forcing
      all port links back to suspended (U3) state.
      
      Example case:
      usb_runtime_suspend() # because all ports still show suspended U3
        usb_suspend_both()
          hub_suspend();   # successful as hub->wakeup_bits not set yet
      ==> INTERRUPT
      xhci_irq()
        handle_port_status()
          clear bus_state->port_remote_wakeup
          usb_wakeup_notification()
            sets hub->wakeup_bits;
              kick_hub_wq()
      <== END INTERRUPT
            hcd_bus_suspend()
              xhci_bus_suspend() # success as port_remote_wakeup bits cleared
      
      Fix this by increasing roothub usage count during port resume to prevent
      roothub autosuspend, and by making sure bus_state->port_remote_wakeup
      flag is only cleared after resume completion is visible, i.e.
      after xhci roothub returned U0 or other non-U3 link state link on a
      get port status request.
      
      Issue rootcaused by Chiasheng Lee
      
      Cc: <stable@vger.kernel.org>
      Cc: Lee, Hou-hsun <hou-hsun.lee@intel.com>
      Reported-by: default avatarLee, Chiasheng <chiasheng.lee@intel.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Link: https://lore.kernel.org/r/20191211142007.8847-3-mathias.nyman@linux.intel.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      d93f4bce
    • Alex Deucher's avatar
      drm/radeon: fix r1xx/r2xx register checker for POT textures · 76829059
      Alex Deucher authored
      commit 008037d4 upstream.
      
      Shift and mask were reversed.  Noticed by chance.
      Tested-by: default avatarMeelis Roos <mroos@linux.ee>
      Reviewed-by: default avatarMichel Dänzer <mdaenzer@redhat.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      76829059
    • Bart Van Assche's avatar
      scsi: iscsi: Fix a potential deadlock in the timeout handler · ebb8c240
      Bart Van Assche authored
      commit 5480e299 upstream.
      
      Some time ago the block layer was modified such that timeout handlers are
      called from thread context instead of interrupt context. Make it safe to
      run the iSCSI timeout handler in thread context. This patch fixes the
      following lockdep complaint:
      
      ================================
      WARNING: inconsistent lock state
      5.5.1-dbg+ #11 Not tainted
      --------------------------------
      inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
      kworker/7:1H/206 [HC0[0]:SC0[0]:HE1:SE1] takes:
      ffff88802d9827e8 (&(&session->frwd_lock)->rlock){+.?.}, at: iscsi_eh_cmd_timed_out+0xa6/0x6d0 [libiscsi]
      {IN-SOFTIRQ-W} state was registered at:
        lock_acquire+0x106/0x240
        _raw_spin_lock+0x38/0x50
        iscsi_check_transport_timeouts+0x3e/0x210 [libiscsi]
        call_timer_fn+0x132/0x470
        __run_timers.part.0+0x39f/0x5b0
        run_timer_softirq+0x63/0xc0
        __do_softirq+0x12d/0x5fd
        irq_exit+0xb3/0x110
        smp_apic_timer_interrupt+0x131/0x3d0
        apic_timer_interrupt+0xf/0x20
        default_idle+0x31/0x230
        arch_cpu_idle+0x13/0x20
        default_idle_call+0x53/0x60
        do_idle+0x38a/0x3f0
        cpu_startup_entry+0x24/0x30
        start_secondary+0x222/0x290
        secondary_startup_64+0xa4/0xb0
      irq event stamp: 1383705
      hardirqs last  enabled at (1383705): [<ffffffff81aace5c>] _raw_spin_unlock_irq+0x2c/0x50
      hardirqs last disabled at (1383704): [<ffffffff81aacb98>] _raw_spin_lock_irq+0x18/0x50
      softirqs last  enabled at (1383690): [<ffffffffa0e2efea>] iscsi_queuecommand+0x76a/0xa20 [libiscsi]
      softirqs last disabled at (1383682): [<ffffffffa0e2e998>] iscsi_queuecommand+0x118/0xa20 [libiscsi]
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&(&session->frwd_lock)->rlock);
        <Interrupt>
          lock(&(&session->frwd_lock)->rlock);
      
       *** DEADLOCK ***
      
      2 locks held by kworker/7:1H/206:
       #0: ffff8880d57bf928 ((wq_completion)kblockd){+.+.}, at: process_one_work+0x472/0xab0
       #1: ffff88802b9c7de8 ((work_completion)(&q->timeout_work)){+.+.}, at: process_one_work+0x476/0xab0
      
      stack backtrace:
      CPU: 7 PID: 206 Comm: kworker/7:1H Not tainted 5.5.1-dbg+ #11
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      Workqueue: kblockd blk_mq_timeout_work
      Call Trace:
       dump_stack+0xa5/0xe6
       print_usage_bug.cold+0x232/0x23b
       mark_lock+0x8dc/0xa70
       __lock_acquire+0xcea/0x2af0
       lock_acquire+0x106/0x240
       _raw_spin_lock+0x38/0x50
       iscsi_eh_cmd_timed_out+0xa6/0x6d0 [libiscsi]
       scsi_times_out+0xf4/0x440 [scsi_mod]
       scsi_timeout+0x1d/0x20 [scsi_mod]
       blk_mq_check_expired+0x365/0x3a0
       bt_iter+0xd6/0xf0
       blk_mq_queue_tag_busy_iter+0x3de/0x650
       blk_mq_timeout_work+0x1af/0x380
       process_one_work+0x56d/0xab0
       worker_thread+0x7a/0x5d0
       kthread+0x1bc/0x210
       ret_from_fork+0x24/0x30
      
      Fixes: 287922eb ("block: defer timeouts to a workqueue")
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Lee Duncan <lduncan@suse.com>
      Cc: Chris Leech <cleech@redhat.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191209173457.187370-1-bvanassche@acm.orgSigned-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Reviewed-by: default avatarLee Duncan <lduncan@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ebb8c240
    • Hou Tao's avatar
      dm btree: increase rebalance threshold in __rebalance2() · e861c9bc
      Hou Tao authored
      commit 474e5595 upstream.
      
      We got the following warnings from thin_check during thin-pool setup:
      
        $ thin_check /dev/vdb
        examining superblock
        examining devices tree
          missing devices: [1, 84]
            too few entries in btree_node: 41, expected at least 42 (block 138, max_entries = 126)
        examining mapping tree
      
      The phenomenon is the number of entries in one node of details_info tree is
      less than (max_entries / 3). And it can be easily reproduced by the following
      procedures:
      
        $ new a thin pool
        $ presume the max entries of details_info tree is 126
        $ new 127 thin devices (e.g. 1~127) to make the root node being full
          and then split
        $ remove the first 43 (e.g. 1~43) thin devices to make the children
          reblance repeatedly
        $ stop the thin pool
        $ thin_check
      
      The root cause is that the B-tree removal procedure in __rebalance2()
      doesn't guarantee the invariance: the minimal number of entries in
      non-root node should be >= (max_entries / 3).
      
      Simply fix the problem by increasing the rebalance threshold to
      make sure the number of entries in each child will be greater
      than or equal to (max_entries / 3 + 1), so no matter which
      child is used for removal, the number will still be valid.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHou Tao <houtao1@huawei.com>
      Acked-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e861c9bc
    • Navid Emamdoost's avatar
      dma-buf: Fix memory leak in sync_file_merge() · bdca5750
      Navid Emamdoost authored
      commit 6645d42d upstream.
      
      In the implementation of sync_file_merge() the allocated sync_file is
      leaked if number of fences overflows. Release sync_file by goto err.
      
      Fixes: a02b9dc9 ("dma-buf/sync_file: refactor fence storage in struct sync_file")
      Signed-off-by: default avatarNavid Emamdoost <navid.emamdoost@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191122220957.30427-1-navid.emamdoost@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bdca5750