1. 07 12月, 2020 3 次提交
  2. 02 12月, 2020 6 次提交
  3. 21 11月, 2020 4 次提交
    • J
      s390/qeth: fix tear down of async TX buffers · 7ed10e16
      Julian Wiedmann 提交于
      When qeth_iqd_tx_complete() detects that a TX buffer requires additional
      async completion via QAOB, it might fail to replace the queue entry's
      metadata (and ends up triggering recovery).
      
      Assume now that the device gets torn down, overruling the recovery.
      If the QAOB notification then arrives before the tear down has
      sufficiently progressed, the buffer state is changed to
      QETH_QDIO_BUF_HANDLED_DELAYED by qeth_qdio_handle_aob().
      
      The tear down code calls qeth_drain_output_queue(), where
      qeth_cleanup_handled_pending() will then attempt to replace such a
      buffer _again_. If it succeeds this time, the buffer ends up dangling in
      its replacement's ->next_pending list ... where it will never be freed,
      since there's no further call to qeth_cleanup_handled_pending().
      
      But the second attempt isn't actually needed, we can simply leave the
      buffer on the queue and re-use it after a potential recovery has
      completed. The qeth_clear_output_buffer() in qeth_drain_output_queue()
      will ensure that it's in a clean state again.
      
      Fixes: 72861ae7 ("qeth: recovery through asynchronous delivery")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      7ed10e16
    • J
      s390/qeth: fix af_iucv notification race · 8908f36d
      Julian Wiedmann 提交于
      The two expected notification sequences are
      1. TX_NOTIFY_PENDING with a subsequent TX_NOTIFY_DELAYED_*, when
         our TX completion code first observed the pending TX and the QAOB
         then completes at a later time; or
      2. TX_NOTIFY_OK, when qeth_qdio_handle_aob() picked up the QAOB
         completion before our TX completion code even noticed that the TX
         was pending.
      
      But as qeth_iqd_tx_complete() and qeth_qdio_handle_aob() can run
      concurrently, we may end up with a race that results in a sequence of
      TX_NOTIFY_DELAYED_* followed by TX_NOTIFY_PENDING. Which would confuse
      the af_iucv code in its tracking of pending transmits.
      
      Rework the notification code, so that qeth_qdio_handle_aob() defers its
      notification if the TX completion code is still active.
      
      Fixes: b3332930 ("qeth: add support for af_iucv HiperSockets transport")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      8908f36d
    • J
      s390/qeth: make af_iucv TX notification call more robust · 34c7f50f
      Julian Wiedmann 提交于
      Calling into socket code is ugly already, at least check whether we are
      dealing with the expected sk_family. Only looking at skb->protocol is
      bound to cause troubles (consider eg. af_packet).
      
      Fixes: b3332930 ("qeth: add support for af_iucv HiperSockets transport")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      34c7f50f
    • A
      s390/qeth: Remove pnso workaround · 0d0e2b53
      Alexandra Winter 提交于
      Remove workaround that supported early hardware implementations
      of PNSO OC3. Rely on the 'enarf' feature bit instead.
      
      Fixes: fa115adf ("s390/qeth: Detect PNSO OC3 capability")
      Signed-off-by: NAlexandra Winter <wintera@linux.ibm.com>
      Reviewed-by: NJulian Wiedmann <jwi@linux.ibm.com>
      [jwi: use logical instead of bit-wise AND]
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      0d0e2b53
  4. 19 11月, 2020 8 次提交
  5. 16 11月, 2020 1 次提交
    • S
      s390/dasd: fix null pointer dereference for ERP requests · 6f117cb8
      Stefan Haberland 提交于
      When requeueing all requests on the device request queue to the blocklayer
      we might get to an ERP (error recovery) request that is a copy of an
      original CQR.
      
      Those requests do not have blocklayer request information or a pointer to
      the dasd_queue set. When trying to access those data it will lead to a
      null pointer dereference in dasd_requeue_all_requests().
      
      Fix by checking if the request is an ERP request that can simply be
      ignored. The blocklayer request will be requeued by the original CQR that
      is on the device queue right behind the ERP request.
      
      Fixes: 9487cfd3 ("s390/dasd: fix handling of internal requests")
      Cc: <stable@vger.kernel.org> #4.16
      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>
      6f117cb8
  6. 03 11月, 2020 2 次提交
    • H
      s390/pkey: fix paes selftest failure with paes and pkey static build · 5b35047e
      Harald Freudenberger 提交于
      When both the paes and the pkey kernel module are statically build
      into the kernel, the paes cipher selftests run before the pkey
      kernel module is initialized. So a static variable set in the pkey
      init function and used in the pkey_clr2protkey function is not
      initialized when the paes cipher's selftests request to call pckmo for
      transforming a clear key value into a protected key.
      
      This patch moves the initial setup of the static variable into
      the function pck_clr2protkey. So it's possible, to use the function
      for transforming a clear to a protected key even before the pkey
      init function has been called and the paes selftests may run
      successful.
      Reported-by: NAlexander Egorenkov <Alexander.Egorenkov@ibm.com>
      Cc: <stable@vger.kernel.org> # 4.20
      Fixes: f822ad2c ("s390/pkey: move pckmo subfunction available checks away from module init")
      Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>
      5b35047e
    • H
      s390/ap: fix ap devices reference counting · 29c2680f
      Harald Freudenberger 提交于
      With the last rework of the AP bus scan function one get_device() is
      missing causing the reference counter to be one instance too
      low. Together with binding/unbinding device drivers to an ap device it
      may end up in an segfault because the ap device is freed but a device
      driver still assumes it's pointer to the ap device is valid:
      
      Unable to handle kernel pointer dereference in virtual kernel address space
      Failing address: 6b6b6b6b6b6b6000 TEID: 6b6b6b6b6b6b6803
      Fault in home space mode while using kernel ASCE.
      Krnl PSW : 0404e00180000000 000000001472f3b6 (klist_next+0x7e/0x180)
                 R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
      Call Trace:
       [<000000001472f3b6>] klist_next+0x7e/0x180
      ([<000000001472f36a>] klist_next+0x32/0x180)
       [<00000000147c14de>] bus_for_each_dev+0x66/0xb8
       [<0000000014aab0d4>] ap_scan_adapter+0xcc/0x6c0
       [<0000000014aab74a>] ap_scan_bus+0x82/0x140
       [<0000000013f3b654>] process_one_work+0x27c/0x478
       [<0000000013f3b8b6>] worker_thread+0x66/0x368
       [<0000000013f44e32>] kthread+0x17a/0x1a0
       [<0000000014af23e4>] ret_from_fork+0x24/0x2c
      Kernel panic - not syncing: Fatal exception: panic_on_oops
      
      Fixed by adjusting the reference count with get_device() on the right
      place. Also now the device drivers don't need to adjust the ap
      device's reference counting any more. This is now done in the ap bus
      probe and remove functions.
      Reported-by: NMarc Hartmayer <mhartmay@linux.ibm.com>
      Fixes: 4f2fcccd ("s390/ap: add card/queue deconfig state")
      Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>
      29c2680f
  7. 27 10月, 2020 1 次提交
    • K
      s390/ism: fix incorrect system EID · 1dc0d1cf
      Karsten Graul 提交于
      The system EID that is defined by the ISM driver is not correct. Using
      an incorrect system EID allows to communicate with remote Linux systems
      that use the same incorrect system EID, but when it comes to
      interoperability with other operating systems then the system EIDs do
      never match which prevents SMC-Dv2 communication.
      Using the correct system EID fixes this problem.
      
      Fixes: 201091eb ("net/smc: introduce System Enterprise ID (SEID)")
      Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      1dc0d1cf
  8. 17 10月, 2020 1 次提交
    • D
      mm/memory_hotplug: prepare passing flags to add_memory() and friends · b6117199
      David Hildenbrand 提交于
      We soon want to pass flags, e.g., to mark added System RAM resources.
      mergeable.  Prepare for that.
      
      This patch is based on a similar patch by Oscar Salvador:
      
      https://lkml.kernel.org/r/20190625075227.15193-3-osalvador@suse.deSigned-off-by: NDavid Hildenbrand <david@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Reviewed-by: Juergen Gross <jgross@suse.com> # Xen related part
      Reviewed-by: NPankaj Gupta <pankaj.gupta.linux@gmail.com>
      Acked-by: NWei Liu <wei.liu@kernel.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Jason Gunthorpe <jgg@ziepe.ca>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Vishal Verma <vishal.l.verma@intel.com>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: Wei Liu <wei.liu@kernel.org>
      Cc: Heiko Carstens <hca@linux.ibm.com>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: David Hildenbrand <david@redhat.com>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Stefano Stabellini <sstabellini@kernel.org>
      Cc: "Oliver O'Halloran" <oohall@gmail.com>
      Cc: Pingfan Liu <kernelfans@gmail.com>
      Cc: Nathan Lynch <nathanl@linux.ibm.com>
      Cc: Libor Pechacek <lpechacek@suse.cz>
      Cc: Anton Blanchard <anton@ozlabs.org>
      Cc: Leonardo Bras <leobras.c@gmail.com>
      Cc: Ard Biesheuvel <ardb@kernel.org>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Julien Grall <julien@xen.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Roger Pau Monné <roger.pau@citrix.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richardw.yang@linux.intel.com>
      Link: https://lkml.kernel.org/r/20200911103459.10306-5-david@redhat.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b6117199
  9. 10 10月, 2020 1 次提交
  10. 08 10月, 2020 9 次提交
    • H
      s390/zcrypt: Introduce Failure Injection feature · 27c4f673
      Harald Freudenberger 提交于
      Introduce a way to specify additional debug flags with an crpyto
      request to be able to trigger certain failures within the zcrypt
      device drivers and/or ap core code.
      
      This failure injection possibility is only enabled with a kernel debug
      build CONFIG_ZCRYPT_DEBUG) and should never be available on a regular
      kernel running in production environment.
      
      Details:
      
      * The ioctl(ICARSAMODEXPO) get's a struct ica_rsa_modexpo. If the
        leftmost bit of the 32 bit unsigned int inputdatalength field is
        set, the uppermost 16 bits are separated and used as debug flag
        value. The process is checked to have the CAP_SYS_ADMIN capability
        enabled or EPERM is returned.
      
      * The ioctl(ICARSACRT) get's a struct ica_rsa_modexpo_crt. If the
        leftmost bit of the 32 bit unsigned int inputdatalength field is set,
        the uppermost 16 bits are separated and used als debug flag
        value. The process is checked to have the CAP_SYS_ADMIN capability
        enabled or EPERM is returned.
      
      * The ioctl(ZSECSENDCPRB) used to send CCA CPRBs get's a struct
        ica_xcRB. If the leftmost bit of the 32 bit unsigned int status
        field is set, the uppermost 16 bits of this field are used as debug
        flag value. The process is checked to have the CAP_SYS_ADMIN
        capability enabled or EPERM is returned.
      
      * The ioctl(ZSENDEP11CPRB) used to send EP11 CPRBs get's a struct
        ep11_urb. If the leftmost bit of the 64 bit unsigned int req_len
        field is set, the uppermost 16 bits of this field are used as debug
        flag value. The process is checked to have the CAP_SYS_ADMIN
        capability enabled or EPERM is returned.
      
      So it is possible to send an additional 16 bit value to the zcrypt API
      to be used to carry a failure injection command which may trigger
      special behavior within the zcrypt API and layers below. This 16 bit
      value is for the rest of the test referred as 'fi command' for Failure
      Injection.
      
      The lower 8 bits of the fi command construct a numerical argument in
      the range of 1-255 and is the 'fi action' to be performed with the
      request or the resulting reply:
      
      * 0x00 (all requests): No failure injection action but flags may be
        provided which may affect the processing of the request or reply.
      * 0x01 (only CCA CPRBs): The CPRB's agent_ID field is set to
        'FF'. This results in an reply code 0x90 (Transport-Protocol
        Failure).
      * 0x02 (only CCA CPRBs): After the APQN to send to has been chosen,
        the domain field within the CPRB is overwritten with value 99 to
        enforce an reply with RY 0x8A.
      * 0x03 (all requests): At NQAP invocation the invalid qid value 0xFF00
        is used causing an response code of 0x01 (AP queue not valid).
      
      The upper 8 bits of the fi command may carry bit flags which may
      influence the processing of an request or response:
      
      * 0x01: No retry. If this bit is set, the usual loop in the zcrypt API
        which retries an CPRB up to 10 times when the lower layers return
        with EAGAIN is abandoned after the first attempt to send the CPRB.
      * 0x02: Toggle special. Toggles the special bit on this request. This
        should result in an reply code RY~0x41 and result in an ioctl
        failure with errno EINVAL.
      
      This failure injection possibilities may get some further extensions
      in the future. As of now this is a starting point for Continuous Test
      and Integration to trigger some failures and watch for the reaction of
      the ap bus and zcrypt device driver code.
      Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      27c4f673
    • H
      s390/zcrypt: move ap_msg param one level up the call chain · 3730f530
      Harald Freudenberger 提交于
      Move the creating and disposal of the struct ap_message one
      level up the call chain. The ap message was constructed in the
      calling functions in msgtype50 and msgtype6 but only for the
      ica rsa messages. For CCA and EP11 CPRBs the ap message struct
      is created in the zcrypt api functions.
      
      This patch moves the construction of the ap message struct into
      the functions zcrypt_rsa_modexpo and zcrypt_rsa_crt. So now all
      the 4 zcrypt api functions zcrypt_rsa_modexpo, zcrypt_rsa_crt,
      zcrypt_send_cprb and zcrypt_send_ep11_cprb appear and act
      similar.
      
      There are no functional changes coming with this patch.
      However, the availability of the ap_message struct has
      advantages which will be needed by a follow up patch.
      Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      3730f530
    • H
      s390/ap/zcrypt: revisit ap and zcrypt error handling · e0332629
      Harald Freudenberger 提交于
      Revisit the ap queue error handling: Based on discussions and
      evaluatios with the firmware folk here is now a rework of the response
      code handling for all the AP instructions. The idea is to distinguish
      between failures because of some kind of invalid request where a retry
      does not make any sense and a failure where another attempt to send
      the very same request may succeed. The first case is handled by
      returning EINVAL to the userspace application. The second case results
      in retries within the zcrypt API controlled by a per message retry
      counter.
      
      Revisit the zcrpyt error handling: Similar here, based on discussions
      with the firmware people here comes a rework of the handling of all
      the reply codes.  Main point here is that there are only very few
      cases left, where a zcrypt device queue is switched to offline. It
      should never be the case that an AP reply message is 'unknown' to the
      device driver as it indicates a total mismatch between device driver
      and crypto card firmware. In all other cases, the code distinguishes
      between failure because of invalid message (see above - EINVAL) or
      failures of the infrastructure (see above - EAGAIN).
      Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      e0332629
    • H
      s390/ap: Support AP card SCLP config and deconfig operations · 5caa2af9
      Harald Freudenberger 提交于
      Support SCLP AP adapter config and deconfig operations:
      The sysfs deconfig attribute /sys/devices/ap/cardxx/deconfig
      for each AP card is now read-write. Writing in a '1' triggers
      a synchronous SCLP request to configure the adapter, writing
      in a '0' sends a synchronous SCLP deconfigure request.
      Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      5caa2af9
    • H
      s390/sclp: Add support for SCLP AP adapter config/deconfig · 0671cc10
      Harald Freudenberger 提交于
      Add support for AP bus adapter config and deconfig to the sclp
      core code. The code is statically build into the kernel when
      ZCRYPT is configured either as module or with static support.
      
      This is the base functionality for having configure/deconfigure
      support in the AP bus and card code. Another patch will exploit
      this soon.
      Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
      Suggested-by: NPierre Morel <pmorel@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      0671cc10
    • H
      s390/ap: add card/queue deconfig state · 4f2fcccd
      Harald Freudenberger 提交于
      This patch adds a new config state to the ap card and queue
      devices. This state reflects the response code
      0x03 "AP deconfigured" on TQAP invocation and is tracked with
      every ap bus scan.
      
      Together with this new state now a card/queue device which
      is 'deconfigured' is not disposed any more. However, for backward
      compatibility the online state now needs to take this state into
      account. So a card/queue is offline when the device is not configured.
      Furthermore a device can't get switched from offline to online state
      when not configured.
      
      The config state is shown in sysfs at
        /sys/devices/ap/cardxx/config
      for the card and
        /sys/devices/ap/cardxx/xx.yyyy/config
      for each queue within each card.
      It is a read-only attribute reflecting the negation of the
      'AP deconfig' state as it is noted in the AP documents.
      Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      4f2fcccd
    • H
      s390/ap: add error response code field for ap queue devices · 2ea2a609
      Harald Freudenberger 提交于
      On AP instruction failures the last response code is now
      kept in the struct ap_queue. There is also a new sysfs
      attribute showing this field (enabled only on debug kernels).
      
      Also slight rework of the AP_DBF macros to get some more
      content into one debug feature message line.
      Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      2ea2a609
    • H
      s390/ap: split ap queue state machine state from device state · 0b641cbd
      Harald Freudenberger 提交于
      The state machine for each ap queue covered a mixture of
      device states and state machine (firmware queue state) states.
      
      This patch splits the device states and the state machine
      states into two different enums and variables. The major
      state is the device state with currently these values:
      
        AP_DEV_STATE_UNINITIATED - fresh and virgin, not touched
        AP_DEV_STATE_OPERATING   - queue dev is working normal
        AP_DEV_STATE_SHUTDOWN	   - remove/unbind/shutdown in progress
        AP_DEV_STATE_ERROR	   - device is in error state
      
      only when the device state is > UNINITIATED the state machine
      is run. The state machine represents the states of the firmware
      queue:
      
        AP_SM_STATE_RESET_START - starting point, reset (RAPQ) ap queue
        AP_SM_STATE_RESET_WAIT  - reset triggered, waiting to be finished
      			    if irqs enabled, set up irq (AQIC)
        AP_SM_STATE_SETIRQ_WAIT - enable irq triggered, waiting to be
      			    finished, then go to IDLE
        AP_SM_STATE_IDLE	  - queue is operational but empty
        AP_SM_STATE_WORKING	  - queue is operational, requests are stored
      			    and replies may wait for getting fetched
        AP_SM_STATE_QUEUE_FULL  - firmware queue is full, so only replies
      			    can get fetched
      
      For debugging each ap queue shows a sysfs attribute 'states' which
      displays the device and state machine state and is only available
      when the kernel is build with CONFIG_ZCRYPT_DEBUG enabled.
      Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      0b641cbd
    • H
      s390/zcrypt: introduce msg tracking in zcrypt functions · 91ffc519
      Harald Freudenberger 提交于
      Introduce a new internal struct zcrypt_track with an retry counter
      field and a last return code field. Fill and update these fields at
      certain points during processing of an request/reply. This tracking
      info is then used to
      - avoid trying to resend the message forever. Now each message is
        tried to be send TRACK_AGAIN_MAX (currently 10) times and then the
        ioctl returns to userspace with errno EAGAIN.
      - avoid trying to resend the message on the very same card/domain. If
        possible (more than one APQN with same quality) don't use the very
        same qid as the previous attempt when again scheduling the request.
        This is done by adding penalty weight values when the dispatching
        takes place. There is a penalty TRACK_AGAIN_CARD_WEIGHT_PENALTY for
        using the same card as previously and another penalty define
        TRACK_AGAIN_QUEUE_WEIGHT_PENALTY to be considered when the same qid
        as the previous sent attempt is calculated. Both values make it
        harder to choose the very same card/domain but not impossible. For
        example when only one APQN is available a resend can only address the
        very same APQN.
      
      There are some more ideas for the future to extend the use of this
      tracking information. For example the last response code at NQAP and
      DQAP could be stored there, giving the possibility to extended tracing
      and debugging about requests failing to get processed properly.
      Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      91ffc519
  11. 03 10月, 2020 4 次提交