1. 20 Feb, 2019 1 commit
    • Harald Freudenberger's avatar
      s390/zcrypt: fix specification exception on z196 during ap probe · 4bbf187b
      Harald Freudenberger authored
      commit 8f9aca0c upstream.
      The older machines don't have the QCI instruction available.
      With support for up to 256 crypto cards the probing of each
      card has been extended to check card ids from 0 up to 255.
      For machines with QCI support there is a filter limiting the
      range of probed cards. The older machines (z196 and older)
      don't have this filter and so since support for 256 cards is
      in the driver all cards are probed. However, these machines
      also require to have the card id fit into 6 bits. Exceeding
      this limit results in a specification exception which happens
      on every kernel startup even when there is no crypto configured
      and used at all.
      This fix limits the range of probed crypto cards to 64 if
      there is no QCI instruction available to obey to the older
      ap architecture and so fixes the specification exceptions
      on z196 machines.
      Cc: stable@vger.kernel.org # v4.17+
      Fixes: af4a7227 ("s390/zcrypt: Support up to 256 crypto adapters.")
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 12 Feb, 2019 2 commits
    • Harald Freudenberger's avatar
      s390/zcrypt: improve special ap message cmd handling · b7c51057
      Harald Freudenberger authored
      [ Upstream commit be534791 ]
      There exist very few ap messages which need to have the 'special' flag
      enabled. This flag tells the firmware layer to do some pre- and maybe
      postprocessing. However, it may happen that this special flag is
      enabled but the firmware is unable to deal with this kind of message
      and thus returns with reply code 0x41. For example older firmware may
      not know the newest messages triggered by the zcrypt device driver and
      thus react with reject and the named reply code. Unfortunately this
      reply code is not known to the zcrypt error routines and thus default
      behavior is to switch the ap queue offline.
      This patch now makes the ap error routine aware of the reply code and
      so userspace is informed about the bad processing result but the queue
      is not switched to offline state any more.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Julian Wiedmann's avatar
      s390/qeth: utilize virtual MAC for Layer2 OSD devices · 25ad9c5e
      Julian Wiedmann authored
      [ Upstream commit b144b99f ]
      By default, READ MAC on a Layer2 OSD device returns the adapter's
      burnt-in MAC address. Given the default scenario of many virtual devices
      on the same adapter, qeth can't make any use of this address and
      therefore skips the READ MAC call for this device type.
      But in some configurations, the READ MAC command for a Layer2 OSD device
      actually returns a pre-provisioned, virtual MAC address. So enable the
      READ MAC code to detect this situation, and let the L2 subdriver
      call READ MAC for OSD devices.
      This also removes the QETH_LAYER2_MAC_READ flag, which protects L2
      devices against calling READ MAC multiple times. Instead protect the
      whole call to qeth_l2_request_initial_mac().
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
  3. 31 Jan, 2019 1 commit
    • Gerald Schaefer's avatar
      s390/smp: fix CPU hotplug deadlock with CPU rescan · 90814f0a
      Gerald Schaefer authored
      commit b7cb707c upstream.
      smp_rescan_cpus() is called without the device_hotplug_lock, which can lead
      to a dedlock when a new CPU is found and immediately set online by a udev
      This was observed on an older kernel version, where the cpu_hotplug_begin()
      loop was still present, and it resulted in hanging chcpu and systemd-udev
      processes. This specific deadlock will not show on current kernels. However,
      there may be other possible deadlocks, and since smp_rescan_cpus() can still
      trigger a CPU hotplug operation, the device_hotplug_lock should be held.
      For reference, this was the deadlock with the old cpu_hotplug_begin() loop:
              chcpu (rescan)                       systemd-udevd
       echo 1 > /sys/../rescan
       -> smp_rescan_cpus()
       -> (*) get_online_cpus()
          (increases refcount)
       -> smp_add_present_cpu()
          (new CPU found)
       -> register_cpu()
       -> device_add()
       -> udev "add" event triggered -----------> udev rule sets CPU online
                                               -> echo 1 > /sys/.../online
                                               -> lock_device_hotplug_sysfs()
                                                  (this is missing in rescan path)
                                               -> device_online()
                                               -> (**) device_lock(new CPU dev)
                                               -> cpu_up()
                                               -> cpu_hotplug_begin()
                                                  (loops until refcount == 0)
                                                  -> deadlock with (*)
       -> bus_probe_device()
       -> device_attach()
       -> device_lock(new CPU dev)
          -> deadlock with (**)
      Fix this by taking the device_hotplug_lock in the CPU rescan path.
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. 22 Jan, 2019 1 commit
  5. 13 Jan, 2019 1 commit
    • Steffen Maier's avatar
      scsi: zfcp: fix posting too many status read buffers leading to adapter shutdown · eed234bc
      Steffen Maier authored
      commit 60a161b7 upstream.
      Suppose adapter (open) recovery is between opened QDIO queues and before
      (the end of) initial posting of status read buffers (SRBs). This time
      window can be seconds long due to FSF_PROT_HOST_CONNECTION_INITIALIZING
      causing by design looping with exponential increase sleeps in the function
      performing exchange config data during recovery
      [zfcp_erp_adapter_strat_fsf_xconf()]. Recovery triggered by local link up.
      Suppose an event occurs for which the FCP channel would send an unsolicited
      notification to zfcp by means of a previously posted SRB.  We saw it with
      local cable pull (link down) in multi-initiator zoning with multiple
      NPIV-enabled subchannels of the same shared FCP channel.
      As soon as zfcp_erp_adapter_strategy_open_fsf() starts posting the initial
      status read buffers from within the adapter's ERP thread, the channel does
      send an unsolicited notification.
      Since v2.6.27 commit d26ab06e ("[SCSI] zfcp: receiving an unsolicted
      status can lead to I/O stall"), zfcp_fsf_status_read_handler() schedules
      adapter->stat_work to re-fill the just consumed SRB from a work item.
      Now the ERP thread and the work item post SRBs in parallel.  Both contexts
      call the helper function zfcp_status_read_refill().  The tracking of
      missing (to be posted / re-filled) SRBs is not thread-safe due to separate
      atomic_read() and atomic_dec(), in order to depend on posting
      success. Hence, both contexts can see
      atomic_read(&adapter->stat_miss) == 1. One of the two contexts posts
      one too many SRB. Zfcp gets QDIO_ERROR_SLSB_STATE on the output queue
      (trace tag "qdireq1") leading to zfcp_erp_adapter_shutdown() in
      An obvious and seemingly clean fix would be to schedule stat_work from the
      ERP thread and wait for it to finish. This would serialize all SRB
      re-fills. However, we already have another work item wait on the ERP
      thread: adapter->scan_work runs zfcp_fc_scan_ports() which calls
      zfcp_fc_eval_gpn_ft(). The latter calls zfcp_erp_wait() to wait for all the
      open port recoveries during zfcp auto port scan, but in fact it waits for
      any pending recovery including an adapter recovery. This approach leads to
      a deadlock.  [see also v3.19 commit 18f87a67 ("zfcp: auto port scan
      resiliency"); v2.6.37 commit d3e1088d
      ("[SCSI] zfcp: No ERP escalation on gpn_ft eval");
      v2.6.28 commit fca55b6f
      ("[SCSI] zfcp: fix deadlock between wq triggered port scan and ERP")
      fixing v2.6.27 commit c57a39a4
      ("[SCSI] zfcp: wait until adapter is finished with ERP during auto-port");
      v2.6.27 commit cc8c2829
      ("[SCSI] zfcp: Automatically attach remote ports")]
      Instead make the accounting of missing SRBs atomic for parallel execution
      in both the ERP thread and adapter->stat_work.
      Signed-off-by: default avatarSteffen Maier <maier@linux.ibm.com>
      Fixes: d26ab06e ("[SCSI] zfcp: receiving an unsolicted status can lead to I/O stall")
      Cc: <stable@vger.kernel.org> #2.6.27+
      Reviewed-by: default avatarJens Remus <jremus@linux.ibm.com>
      Signed-off-by: Martin K. Petersen's avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. 06 Dec, 2018 2 commits
    • Halil Pasic's avatar
      virtio/s390: fix race in ccw_io_helper() · 78b1a52e
      Halil Pasic authored
      While ccw_io_helper() seems like intended to be exclusive in a sense that
      it is supposed to facilitate I/O for at most one thread at any given
      time, there is actually nothing ensuring that threads won't pile up at
      vcdev->wait_q. If they do, all threads get woken up and see the status
      that belongs to some other request than their own. This can lead to bugs.
      For an example see:
      This race normally does not cause any problems. The operations provided
      by struct virtio_config_ops are usually invoked in a well defined
      sequence, normally don't fail, and are normally used quite infrequent
      Yet, if some of the these operations are directly triggered via sysfs
      attributes, like in the case described by the referenced bug, userspace
      is given an opportunity to force races by increasing the frequency of the
      given operations.
      Let us fix the problem by ensuring, that for each device, we finish
      processing the previous request before starting with a new one.
      Signed-off-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Reported-by: default avatarColin Ian King <colin.king@canonical.com>
      Cc: stable@vger.kernel.org
      Message-Id: <20180925121309.58524-3-pasic@linux.ibm.com>
      Signed-off-by: Cornelia Huck's avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
    • Halil Pasic's avatar
      virtio/s390: avoid race on vcdev->config · 2448a299
      Halil Pasic authored
      Currently we have a race on vcdev->config in virtio_ccw_get_config() and
      in virtio_ccw_set_config().
      This normally does not cause problems, as these are usually infrequent
      operations. However, for some devices writing to/reading from the config
      space can be triggered through sysfs attributes. For these, userspace can
      force the race by increasing the frequency.
      Signed-off-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Cc: stable@vger.kernel.org
      Message-Id: <20180925121309.58524-2-pasic@linux.ibm.com>
      Signed-off-by: Cornelia Huck's avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
  7. 28 Nov, 2018 1 commit
    • Julian Wiedmann's avatar
      s390/qeth: fix length check in SNMP processing · 9a764c1e
      Julian Wiedmann authored
      The response for a SNMP request can consist of multiple parts, which
      the cmd callback stages into a kernel buffer until all parts have been
      received. If the callback detects that the staging buffer provides
      insufficient space, it bails out with error.
      This processing is buggy for the first part of the response - while it
      initially checks for a length of 'data_len', it later copies an
      additional amount of 'offsetof(struct qeth_snmp_cmd, data)' bytes.
      Fix the calculation of 'data_len' for the first part of the response.
      This also nicely cleans up the memcpy code.
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Reviewed-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  8. 27 Nov, 2018 1 commit
    • Harald Freudenberger's avatar
      s390/zcrypt: reinit ap queue state machine during device probe · 104f708f
      Harald Freudenberger authored
      Until the vfio-ap driver came into live there was a well known
      agreement about the way how ap devices are initialized and their
      states when the driver's probe function is called.
      However, the vfio device driver when receiving an ap queue device does
      additional resets thereby removing the registration for interrupts for
      the ap device done by the ap bus core code. So when later the vfio
      driver releases the device and one of the default zcrypt drivers takes
      care of the device the interrupt registration needs to get
      renewed. The current code does no renew and result is that requests
      send into such a queue will never see a reply processed - the
      application hangs.
      This patch adds a function which resets the aq queue state machine for
      the ap queue device and triggers the walk through the initial states
      (which are reset and registration for interrupts). This function is
      now called before the driver's probe function is invoked.
      When the association between driver and device is released, the
      driver's remove function is called. The current implementation calls a
      ap queue function ap_queue_remove(). This invokation has been moved to
      the ap bus function to make the probe / remove pair for ap bus and
      drivers more symmetric.
      Fixes: 7e0bdbe5 ("s390/zcrypt: AP bus support for alternate driver(s)")
      Cc: stable@vger.kernel.org # 4.19+
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Reviewd-by: default avatarTony Krowiak <akrowiak@linux.ibm.com>
      Reviewd-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
  9. 14 Nov, 2018 1 commit
  10. 13 Nov, 2018 4 commits
  11. 03 Nov, 2018 6 commits
  12. 31 Oct, 2018 1 commit
  13. 22 Oct, 2018 1 commit
    • Harald Freudenberger's avatar
      s390/pkey: move pckmo subfunction available checks away from module init · f822ad2c
      Harald Freudenberger authored
      The init of the pkey module currently fails if the pckmo instruction
      or the subfunctions are not available.  However, customers may
      restrict their LPAR to switch off exactly these functions and work
      with secure key only. So it is a valid case to have the pkey module
      active and use it for secure key to protected key transfer only.
      This patch moves the pckmo subfunction check from the pkey module init
      function into the internal function where the pckmo instruction is
      called. So now only on invocation of the pckmo instruction the check
      for the required subfunction is done. If not available EOPNOTSUPP is
      returned to the caller.
      The check for having the pckmo instruction available is still done
      during module init. This instruction came in with MSA 3 together with
      the basic set of kmc instructions needed to work with protected keys.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Reviewed-by: Ingo Franzki's avatarIngo Franzki <ifranzki@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
  14. 19 Oct, 2018 1 commit
  15. 15 Oct, 2018 1 commit
  16. 12 Oct, 2018 4 commits
  17. 10 Oct, 2018 6 commits
  18. 09 Oct, 2018 5 commits