1. 23 5月, 2019 9 次提交
  2. 22 5月, 2019 4 次提交
    • M
      dm: make sure to obey max_io_len_target_boundary · 51b86f9a
      Michael Lass 提交于
      Commit 61697a6a ("dm: eliminate 'split_discard_bios' flag from DM
      target interface") incorrectly removed code from
      __send_changing_extent_only() that is required to impose a per-target IO
      boundary on IO that exceeds max_io_len_target_boundary().  Otherwise
      "special" IO (e.g. DISCARD, WRITE SAME, WRITE ZEROES) can write beyond
      where allowed.
      
      Fix this by restoring the max_io_len_target_boundary() limit in
      __send_changing_extent_only()
      
      Fixes: 61697a6a ("dm: eliminate 'split_discard_bios' flag from DM target interface")
      Cc: stable@vger.kernel.org # 5.1+
      Signed-off-by: NMichael Lass <bevan@bi-co.net>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      51b86f9a
    • K
      usbnet: fix kernel crash after disconnect · ad70411a
      Kloetzke Jan 提交于
      When disconnecting cdc_ncm the kernel sporadically crashes shortly
      after the disconnect:
      
        [   57.868812] Unable to handle kernel NULL pointer dereference at virtual address 00000000
        ...
        [   58.006653] PC is at 0x0
        [   58.009202] LR is at call_timer_fn+0xec/0x1b4
        [   58.013567] pc : [<0000000000000000>] lr : [<ffffff80080f5130>] pstate: 00000145
        [   58.020976] sp : ffffff8008003da0
        [   58.024295] x29: ffffff8008003da0 x28: 0000000000000001
        [   58.029618] x27: 000000000000000a x26: 0000000000000100
        [   58.034941] x25: 0000000000000000 x24: ffffff8008003e68
        [   58.040263] x23: 0000000000000000 x22: 0000000000000000
        [   58.045587] x21: 0000000000000000 x20: ffffffc68fac1808
        [   58.050910] x19: 0000000000000100 x18: 0000000000000000
        [   58.056232] x17: 0000007f885aff8c x16: 0000007f883a9f10
        [   58.061556] x15: 0000000000000001 x14: 000000000000006e
        [   58.066878] x13: 0000000000000000 x12: 00000000000000ba
        [   58.072201] x11: ffffffc69ff1db30 x10: 0000000000000020
        [   58.077524] x9 : 8000100008001000 x8 : 0000000000000001
        [   58.082847] x7 : 0000000000000800 x6 : ffffff8008003e70
        [   58.088169] x5 : ffffffc69ff17a28 x4 : 00000000ffff138b
        [   58.093492] x3 : 0000000000000000 x2 : 0000000000000000
        [   58.098814] x1 : 0000000000000000 x0 : 0000000000000000
        ...
        [   58.205800] [<          (null)>]           (null)
        [   58.210521] [<ffffff80080f5298>] expire_timers+0xa0/0x14c
        [   58.215937] [<ffffff80080f542c>] run_timer_softirq+0xe8/0x128
        [   58.221702] [<ffffff8008081120>] __do_softirq+0x298/0x348
        [   58.227118] [<ffffff80080a6304>] irq_exit+0x74/0xbc
        [   58.232009] [<ffffff80080e17dc>] __handle_domain_irq+0x78/0xac
        [   58.237857] [<ffffff8008080cf4>] gic_handle_irq+0x80/0xac
        ...
      
      The crash happens roughly 125..130ms after the disconnect. This
      correlates with the 'delay' timer that is started on certain USB tx/rx
      errors in the URB completion handler.
      
      The problem is a race of usbnet_stop() with usbnet_start_xmit(). In
      usbnet_stop() we call usbnet_terminate_urbs() to cancel all URBs in
      flight. This only makes sense if no new URBs are submitted
      concurrently, though. But the usbnet_start_xmit() can run at the same
      time on another CPU which almost unconditionally submits an URB. The
      error callback of the new URB will then schedule the timer after it was
      already stopped.
      
      The fix adds a check if the tx queue is stopped after the tx list lock
      has been taken. This should reliably prevent the submission of new URBs
      while usbnet_terminate_urbs() does its job. The same thing is done on
      the rx side even though it might be safe due to other flags that are
      checked there.
      Signed-off-by: NJan Klötzke <Jan.Kloetzke@preh.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ad70411a
    • R
      net: phylink: ensure inband AN works correctly · 406cb0c4
      Russell King 提交于
      Do not update the link interface mode while the link is down to avoid
      spurious link interface changes.
      
      Always call mac_config if we have a PHY to propagate the pause mode
      settings to the MAC.
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      406cb0c4
    • B
      usbnet: ipheth: fix racing condition · 94d250fa
      Bernd Eckstein 提交于
      Fix a racing condition in ipheth.c that can lead to slow performance.
      
      Bug: In ipheth_tx(), netif_wake_queue() may be called on the callback
      ipheth_sndbulk_callback(), _before_ netif_stop_queue() is called.
      When this happens, the queue is stopped longer than it needs to be,
      thus reducing network performance.
      
      Fix: Move netif_stop_queue() in front of usb_submit_urb(). Now the order
      is always correct. In case, usb_submit_urb() fails, the queue is woken up
      again as callback will not fire.
      
      Testing: This racing condition is usually not noticeable, as it has to
      occur very frequently to slowdown the network. The callback from the USB
      is usually triggered slow enough, so the situation does not appear.
      However, on a Ubuntu Linux on VMWare Workstation, running on Windows 10,
      the we loose the race quite often and the following speedup can be noticed:
      
      Without this patch: Download:  4.10 Mbit/s, Upload:  4.01 Mbit/s
      With this patch:    Download: 36.23 Mbit/s, Upload: 17.61 Mbit/s
      Signed-off-by: NOliver Zweigle <Oliver.Zweigle@faro.com>
      Signed-off-by: NBernd Eckstein <3ernd.Eckstein@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      94d250fa
  3. 21 5月, 2019 26 次提交
  4. 19 5月, 2019 1 次提交
    • V
      mlxsw: core: Prevent reading unsupported slave address from SFP EEPROM · f1436c80
      Vadim Pasternak 提交于
      Prevent reading unsupported slave address from SFP EEPROM by testing
      Diagnostic Monitoring Type byte in EEPROM. Read only page zero of
      EEPROM, in case this byte is zero.
      
      If some SFP transceiver does not support Digital Optical Monitoring
      (DOM), reading SFP EEPROM slave address 0x51 could return an error.
      Availability of DOM support is verified by reading from zero page
      Diagnostic Monitoring Type byte describing how diagnostic monitoring is
      implemented by transceiver. If bit 6 of this byte is set, it indicates
      that digital diagnostic monitoring has been implemented. Otherwise it is
      not and transceiver could fail to reply to transaction for slave address
      0x51 [1010001X (A2h)], which is used to access measurements page.
      
      Such issue has been observed when reading cable MCP2M00-xxxx,
      MCP7F00-xxxx, and few others.
      
      Fixes: 2ea10903 ("mlxsw: spectrum: Add support for access cable info via ethtool")
      Fixes: 4400081b ("mlxsw: spectrum: Fix EEPROM access in case of SFP/SFP+")
      Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f1436c80