1. 29 1月, 2021 5 次提交
  2. 08 1月, 2021 3 次提交
    • J
      s390/qeth: fix L2 header access in qeth_l3_osa_features_check() · f9c48453
      Julian Wiedmann 提交于
      ip_finish_output_gso() may call .ndo_features_check() even before the
      skb has a L2 header. This conflicts with qeth_get_ip_version()'s attempt
      to inspect the L2 header via vlan_eth_hdr().
      
      Switch to vlan_get_protocol(), as already used further down in the
      common qeth_features_check() path.
      
      Fixes: f13ade19 ("s390/qeth: run non-offload L3 traffic over common xmit path")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      f9c48453
    • J
      s390/qeth: fix locking for discipline setup / removal · b41b554c
      Julian Wiedmann 提交于
      Due to insufficient locking, qeth_core_set_online() and
      qeth_dev_layer2_store() can run in parallel, both attempting to load &
      setup the discipline (and stepping on each other toes along the way).
      A similar race can also occur between qeth_core_remove_device() and
      qeth_dev_layer2_store().
      
      Access to .discipline is meant to be protected by the discipline_mutex,
      so add/expand the locking in qeth_core_remove_device() and
      qeth_core_set_online().
      Adjust the locking in qeth_l*_remove_device() accordingly, as it's now
      handled by the callers in a consistent manner.
      
      Based on an initial patch by Ursula Braun.
      
      Fixes: 9dc48ccc ("qeth: serialize sysfs-triggered device configurations")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Reviewed-by: NAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      b41b554c
    • J
      s390/qeth: fix deadlock during recovery · 0b9902c1
      Julian Wiedmann 提交于
      When qeth_dev_layer2_store() - holding the discipline_mutex - waits
      inside qeth_l*_remove_device() for a qeth_do_reset() thread to complete,
      we can hit a deadlock if qeth_do_reset() concurrently calls
      qeth_set_online() and thus tries to aquire the discipline_mutex.
      
      Move the discipline_mutex locking outside of qeth_set_online() and
      qeth_set_offline(), and turn the discipline into a parameter so that
      callers understand the dependency.
      
      To fix the deadlock, we can now relax the locking:
      As already established, qeth_l*_remove_device() waits for
      qeth_do_reset() to complete. So qeth_do_reset() itself is under no risk
      of having card->discipline ripped out while it's running, and thus
      doesn't need to take the discipline_mutex.
      
      Fixes: 9dc48ccc ("qeth: serialize sysfs-triggered device configurations")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Reviewed-by: NAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      0b9902c1
  3. 18 12月, 2020 4 次提交
    • S
      s390/dasd: fix list corruption of lcu list · 53a7f655
      Stefan Haberland 提交于
      In dasd_alias_disconnect_device_from_lcu the device is removed from any
      list on the LCU. Afterwards the LCU is removed from the lcu list if it
      does not contain devices any longer.
      
      The lcu->lock protects the lcu from parallel updates. But to cancel all
      workers and wait for completion the lcu->lock has to be unlocked.
      
      If two devices are removed in parallel and both are removed from the LCU
      the first device that takes the lcu->lock again will delete the LCU because
      it is already empty but the second device also tries to free the LCU which
      leads to a list corruption of the lcu list.
      
      Fix by removing the device right before the lcu is checked without
      unlocking the lcu->lock in between.
      
      Fixes: 8e09f215 ("[S390] dasd: add hyper PAV support to DASD device driver, part 1")
      Cc: stable@vger.kernel.org
      Signed-off-by: NStefan Haberland <sth@linux.ibm.com>
      Reviewed-by: NJan Hoeppner <hoeppner@linux.ibm.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      53a7f655
    • S
      s390/dasd: fix list corruption of pavgroup group list · 0ede91f8
      Stefan Haberland 提交于
      dasd_alias_add_device() moves devices to the active_devices list in case
      of a scheduled LCU update regardless if they have previously been in a
      pavgroup or not.
      
      Example: device A and B are in the same pavgroup.
      
      Device A has already been in a pavgroup and the private->pavgroup pointer
      is set and points to a valid pavgroup. While going through dasd_add_device
      it is moved from the pavgroup to the active_devices list.
      
      In parallel device B might be removed from the same pavgroup in
      remove_device_from_lcu() which in turn checks if the group is empty
      and deletes it accordingly because device A has already been removed from
      there.
      
      When now device A enters remove_device_from_lcu() it is tried to remove it
      from the pavgroup again because the pavgroup pointer is still set and again
      the empty group will be cleaned up which leads to a list corruption.
      
      Fix by setting private->pavgroup to NULL in dasd_add_device.
      
      If the device has been the last device on the pavgroup an empty pavgroup
      remains but this will be cleaned up by the scheduled lcu_update which
      iterates over all existing pavgroups.
      
      Fixes: 8e09f215 ("[S390] dasd: add hyper PAV support to DASD device driver, part 1")
      Cc: stable@vger.kernel.org
      Signed-off-by: NStefan Haberland <sth@linux.ibm.com>
      Reviewed-by: NJan Hoeppner <hoeppner@linux.ibm.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      0ede91f8
    • S
      s390/dasd: prevent inconsistent LCU device data · a29ea016
      Stefan Haberland 提交于
      Prevent _lcu_update from adding a device to a pavgroup if the LCU still
      requires an update. The data is not reliable any longer and in parallel
      devices might have been moved on the lists already.
      This might lead to list corruptions or invalid PAV grouping.
      Only add devices to a pavgroup if the LCU is up to date. Additional steps
      are taken by the scheduled lcu update.
      
      Fixes: 8e09f215 ("[S390] dasd: add hyper PAV support to DASD device driver, part 1")
      Cc: stable@vger.kernel.org
      Signed-off-by: NStefan Haberland <sth@linux.ibm.com>
      Reviewed-by: NJan Hoeppner <hoeppner@linux.ibm.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      a29ea016
    • S
      s390/dasd: fix hanging device offline processing · 658a337a
      Stefan Haberland 提交于
      For an LCU update a read unit address configuration IO is required.
      This is started using sleep_on(), which has early exit paths in case the
      device is not usable for IO. For example when it is in offline processing.
      
      In those cases the LCU update should fail and not be retried.
      Therefore lcu_update_work checks if EOPNOTSUPP is returned or not.
      
      Commit 41995342 ("s390/dasd: fix endless loop after read unit address configuration")
      accidentally removed the EOPNOTSUPP return code from
      read_unit_address_configuration(), which in turn might lead to an endless
      loop of the LCU update in offline processing.
      
      Fix by returning EOPNOTSUPP again if the device is not able to perform the
      request.
      
      Fixes: 41995342 ("s390/dasd: fix endless loop after read unit address configuration")
      Cc: stable@vger.kernel.org #5.3
      Signed-off-by: NStefan Haberland <sth@linux.ibm.com>
      Reviewed-by: NJan Hoeppner <hoeppner@linux.ibm.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      658a337a
  4. 16 12月, 2020 2 次提交
  5. 10 12月, 2020 1 次提交
  6. 07 12月, 2020 6 次提交
  7. 05 12月, 2020 1 次提交
  8. 04 12月, 2020 1 次提交
  9. 03 12月, 2020 10 次提交
  10. 02 12月, 2020 7 次提交