1. 25 12月, 2019 5 次提交
    • A
      s390/qeth: vnicc Fix init to default · d1b9ae18
      Alexandra Winter 提交于
      During vnicc_init wanted_char should be compared to cur_char and not
      to QETH_VNICC_DEFAULT. Without this patch there is no way to enforce
      the default values as desired values.
      
      Note, that it is expected, that a card comes online with default values.
      This patch was tested with private card firmware.
      
      Fixes: caa1f0b1 ("s390/qeth: add VNICC enable/disable support")
      Signed-off-by: NAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d1b9ae18
    • A
      s390/qeth: Fix vnicc_is_in_use if rx_bcast not set · e8a66d80
      Alexandra Winter 提交于
      Symptom: After vnicc/rx_bcast has been manually set to 0,
      	bridge_* sysfs parameters can still be set or written.
      Only occurs on HiperSockets, as OSA doesn't support changing rx_bcast.
      
      Vnic characteristics and bridgeport settings are mutually exclusive.
      rx_bcast defaults to 1, so manually setting it to 0 should disable
      bridge_* parameters.
      
      Instead it makes sense here to check the supported mask. If the card
      does not support vnicc at all, bridge commands are always allowed.
      
      Fixes: caa1f0b1 ("s390/qeth: add VNICC enable/disable support")
      Signed-off-by: NAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e8a66d80
    • A
      s390/qeth: fix false reporting of VNIC CHAR config failure · 68c57bfd
      Alexandra Winter 提交于
      Symptom: Error message "Configuring the VNIC characteristics failed"
      in dmesg whenever an OSA interface on z15 is set online.
      
      The VNIC characteristics get re-programmed when setting a L2 device
      online. This follows the selected 'wanted' characteristics - with the
      exception that the INVISIBLE characteristic unconditionally gets
      switched off.
      
      For devices that don't support INVISIBLE (ie. OSA), the resulting
      IO failure raises a noisy error message
      ("Configuring the VNIC characteristics failed").
      For IQD, INVISIBLE is off by default anyways.
      
      So don't unnecessarily special-case the INVISIBLE characteristic, and
      thereby suppress the misleading error message on OSA devices.
      
      Fixes: caa1f0b1 ("s390/qeth: add VNICC enable/disable support")
      Signed-off-by: NAlexandra Winter <wintera@linux.ibm.com>
      Reviewed-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      68c57bfd
    • 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 6 次提交
  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. 30 11月, 2019 1 次提交
    • H
      s390/zcrypt: handle new reply code FILTERED_BY_HYPERVISOR · 6733775a
      Harald Freudenberger 提交于
      This patch introduces support for a new architectured reply
      code 0x8B indicating that a hypervisor layer (if any) has
      rejected an ap message.
      
      Linux may run as a guest on top of a hypervisor like zVM
      or KVM. So the crypto hardware seen by the ap bus may be
      restricted by the hypervisor for example only a subset like
      only clear key crypto requests may be supported. Other
      requests will be filtered out - rejected by the hypervisor.
      The new reply code 0x8B will appear in such cases and needs
      to get recognized by the ap bus and zcrypt device driver zoo.
      Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      6733775a
  6. 21 11月, 2019 2 次提交
  7. 16 11月, 2019 1 次提交
  8. 15 11月, 2019 11 次提交
  9. 14 11月, 2019 1 次提交
  10. 12 11月, 2019 2 次提交
  11. 01 11月, 2019 7 次提交