1. 25 12月, 2019 3 次提交
    • J
      s390/qeth: fix initialization on old HW · 0b698c83
      Julian Wiedmann 提交于
      I stumbled over an old OSA model that claims to support DIAG_ASSIST,
      but then rejects the cmd to query its DIAG capabilities.
      
      In the old code this was ok, as the returned raw error code was > 0.
      Now that we translate the raw codes to errnos, the "rc < 0" causes us
      to fail the initialization of the device.
      
      The fix is trivial: don't bail out when the DIAG query fails. Such an
      error is not critical, we can still use the device (with a slightly
      reduced set of features).
      
      Fixes: 742d4d40 ("s390/qeth: convert remaining legacy cmd callbacks")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b698c83
    • J
      s390/qeth: lock the card while changing its hsuid · 5b6c7b55
      Julian Wiedmann 提交于
      qeth_l3_dev_hsuid_store() initially checks the card state, but doesn't
      take the conf_mutex to ensure that the card stays in this state while
      being reconfigured.
      
      Rework the code to take this lock, and drop a redundant state check in a
      helper function.
      
      Fixes: b3332930 ("qeth: add support for af_iucv HiperSockets transport")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b6c7b55
    • J
      s390/qeth: fix qdio teardown after early init error · 8b5026bc
      Julian Wiedmann 提交于
      qeth_l?_set_online() goes through a number of initialization steps, and
      on any error uses qeth_l?_stop_card() to tear down the residual state.
      
      The first initialization step is qeth_core_hardsetup_card(). When this
      fails after having established a QDIO context on the device
      (ie. somewhere after qeth_mpc_initialize()), qeth_l?_stop_card() doesn't
      shut down this QDIO context again (since the card state hasn't
      progressed from DOWN at this stage).
      
      Even worse, we then call qdio_free() as final teardown step to free the
      QDIO data structures - while some of them are still hooked into wider
      QDIO infrastructure such as the IRQ list. This is inevitably followed by
      use-after-frees and other nastyness.
      
      Fix this by unconditionally calling qeth_qdio_clear_card() to shut down
      the QDIO context, and also to halt/clear any pending activity on the
      various IO channels.
      Remove the naive attempt at handling the teardown in
      qeth_mpc_initialize(), it clearly doesn't suffice and we're handling it
      properly now in the wider teardown code.
      
      Fixes: 4a71df50 ("qeth: new qeth device driver")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b5026bc
  2. 21 12月, 2019 1 次提交
  3. 10 12月, 2019 1 次提交
  4. 06 12月, 2019 3 次提交
    • J
      s390/qeth: fix dangling IO buffers after halt/clear · f9e50b02
      Julian Wiedmann 提交于
      The cio layer's intparm logic does not align itself well with how qeth
      manages cmd IOs. When an active IO gets terminated via halt/clear, the
      corresponding IRQ's intparm does not reflect the cmd buffer but rather
      the intparm that was passed to ccw_device_halt() / ccw_device_clear().
      This behaviour was recently clarified in
      commit b91d9e67 ("s390/cio: fix intparm documentation").
      
      As a result, qeth_irq() currently doesn't cancel a cmd that was
      terminated via halt/clear. This primarily causes us to leak
      card->read_cmd after the qeth device is removed, since our IO path still
      holds a refcount for this cmd.
      
      For qeth this means that we need to keep track of which IO is pending on
      a device ('active_cmd'), and use this as the intparm when calling
      halt/clear. Otherwise qeth_irq() can't match the subsequent IRQ to its
      cmd buffer.
      Since we now keep track of the _expected_ intparm, we can also detect
      any mismatch; this would constitute a bug somewhere in the lower layers.
      In this case cancel the active cmd - we effectively "lost" the IRQ and
      should not expect any further notification for this IO.
      
      Fixes: 40554895 ("s390/qeth: add support for dynamically allocated cmds")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f9e50b02
    • J
      s390/qeth: ensure linear access to packet headers · f677fcb9
      Julian Wiedmann 提交于
      When the RX path builds non-linear skbs, the packet headers can
      currently spill over into page fragments. Depending on the packet type
      and what fields we need to access in the headers, this could cause us
      to go past the end of skb->data.
      
      So for non-linear packets, copy precisely the length of the necessary
      headers ('linear_len') into skb->data.
      And don't copy more, upper-level protocols will peel whatever additional
      packet headers they need.
      
      Fixes: 4a71df50 ("qeth: new qeth device driver")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f677fcb9
    • J
      s390/qeth: guard against runt packets · 5b55633f
      Julian Wiedmann 提交于
      Depending on a packet's type, the RX path needs to access fields in the
      packet headers and thus requires a minimum packet length.
      Enforce this length when building the skb.
      
      On the other hand a single runt packet is no reason to drop the whole
      RX buffer. So just skip it, and continue processing on the next packet.
      
      Fixes: 4a71df50 ("qeth: new qeth device driver")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b55633f
  5. 21 11月, 2019 1 次提交
  6. 15 11月, 2019 5 次提交
  7. 01 11月, 2019 5 次提交
  8. 01 10月, 2019 1 次提交
  9. 25 8月, 2019 6 次提交
  10. 21 8月, 2019 6 次提交
  11. 14 8月, 2019 1 次提交
    • J
      s390/qeth: serialize cmd reply with concurrent timeout · 072f7940
      Julian Wiedmann 提交于
      Callbacks for a cmd reply run outside the protection of card->lock, to
      allow for additional cmds to be issued & enqueued in parallel.
      
      When qeth_send_control_data() bails out for a cmd without having
      received a reply (eg. due to timeout), its callback may concurrently be
      processing a reply that just arrived. In this case, the callback
      potentially accesses a stale reply->reply_param area that eg. was
      on-stack and has already been released.
      
      To avoid this race, add some locking so that qeth_send_control_data()
      can (1) wait for a concurrently running callback, and (2) zap any
      pending callback that still wants to run.
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      072f7940
  12. 23 7月, 2019 1 次提交
  13. 28 6月, 2019 6 次提交