05 Mar, 2020

2 commits

  • commit 6f3846f0955308b6d1b219419da42b8de2c08845 upstream.

    When getting or setting VNICC parameters, the error code EOPNOTSUPP
    should have precedence over EBUSY.

    EBUSY is used because vnicc feature and bridgeport feature are mutually
    exclusive, which is a temporary condition.
    Whereas EOPNOTSUPP indicates that the HW does not support all or parts of
    the vnicc feature.
    This issue causes the vnicc sysfs params to show 'blocked by bridgeport'
    for HW that does not support VNICC at all.

    Fixes: caa1f0b10d18 ("s390/qeth: add VNICC enable/disable support")
    Signed-off-by: Alexandra Winter
    Signed-off-by: Julian Wiedmann
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Alexandra Winter
     
  • [ Upstream commit fcd98d4002539f1e381916fc1b6648938c1eac76 ]

    The internal statistic counters for the total number of
    requests processed per card and per queue used integers. So they do
    wrap after a rather huge amount of crypto requests processed. This
    patch introduces uint64 counters which should hold much longer but
    still may wrap. The sysfs attributes request_count for card and queue
    also used only %ld and now display the counter value with %llu.

    This is not a security relevant fix. The int overflow which happened
    is not in any way exploitable as a security breach.

    Signed-off-by: Harald Freudenberger
    Signed-off-by: Vasily Gorbik
    Signed-off-by: Sasha Levin

    Harald Freudenberger
     

20 Feb, 2020

1 commit

  • commit aab73d278d49c718b722ff5052e16c9cddf144d4 upstream.

    The pkey ioctl call PKEY_SEC2PROTK updates a struct pkey_protkey
    on return. The protected key is stored in, the protected key type
    is stored in but the len information was not updated. This patch
    now fixes this and so the len field gets an update to refrect
    the actual size of the protected key value returned.

    Fixes: efc598e6c8a9 ("s390/zcrypt: move cca misc functions to new code file")
    Cc: Stable
    Signed-off-by: Harald Freudenberger
    Reported-by: Christian Rund
    Suggested-by: Ingo Franzki
    Signed-off-by: Vasily Gorbik
    Signed-off-by: Greg Kroah-Hartman

    Harald Freudenberger
     

06 Feb, 2020

1 commit

  • [ Upstream commit 0c874cd04292c7ee22d70eefc341fa2648f41f46 ]

    This patch moves the reset invocation of an ap device when
    fresh detected from the ap bus to the probe() function of
    the driver responsible for this device.

    The virtualisation of ap devices makes it necessary to
    remove unconditioned resets on fresh appearing apqn devices.
    It may be that such a device is already enabled for guest
    usage. So there may be a race condition between host ap bus
    and guest ap bus doing the reset. This patch moves the
    reset from the ap bus to the zcrypt drivers. So if there
    is no zcrypt driver bound to an ap device - for example
    the ap device is bound to the vfio device driver - the
    ap device is untouched passed to the vfio device driver.

    Signed-off-by: Harald Freudenberger
    Signed-off-by: Vasily Gorbik
    Signed-off-by: Sasha Levin

    Harald Freudenberger
     

26 Jan, 2020

2 commits

  • [ Upstream commit f9e50b02a99c3ebbaa30690e8d5be28a5c2624eb ]

    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 b91d9e67e50b ("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: 405548959cc7 ("s390/qeth: add support for dynamically allocated cmds")
    Signed-off-by: Julian Wiedmann
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin

    Julian Wiedmann
     
  • commit f9cac4fd8878929c6ebff0bd272317905d77c38a upstream.

    Fixes: f2bbc96e7cfad ("s390/pkey: add CCA AES cipher key support")
    Reported-by: Markus Elfring
    Reported-by: Christian Borntraeger
    Signed-off-by: Heiko Carstens
    Signed-off-by: Vasily Gorbik
    Signed-off-by: Greg Kroah-Hartman

    Heiko Carstens
     

23 Jan, 2020

1 commit

  • commit 94dd3bada53ee77b80d0aeee5571eeb83654d156 upstream.

    Regression tests showed that the CCA cipher key function which
    generates an CCA cipher key with given clear key value does not work
    correctly. At parsing the reply CPRB two limits are wrong calculated
    resulting in rejecting the reply as invalid with s390dbf message
    "_ip_cprb_helper reply with invalid or unknown key block".

    Fixes: f2bbc96e7cfa ("s390/pkey: add CCA AES cipher key support")
    Cc: Stable
    Signed-off-by: Harald Freudenberger
    Signed-off-by: Vasily Gorbik
    Signed-off-by: Greg Kroah-Hartman

    Harald Freudenberger
     

18 Jan, 2020

6 commits

  • [ Upstream commit 5b6c7b55cfe26224b0f41b1c226d3534c542787f ]

    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: b333293058aa ("qeth: add support for af_iucv HiperSockets transport")
    Signed-off-by: Julian Wiedmann
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin

    Julian Wiedmann
     
  • commit 0b698c838e84149b690c7e979f78cccb6f8aa4b9 upstream.

    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: 742d4d40831d ("s390/qeth: convert remaining legacy cmd callbacks")
    Signed-off-by: Julian Wiedmann
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Julian Wiedmann
     
  • commit d1b9ae1864fc3c000e0eb4af8482d78c63e0915a upstream.

    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: caa1f0b10d18 ("s390/qeth: add VNICC enable/disable support")
    Signed-off-by: Alexandra Winter
    Signed-off-by: Julian Wiedmann
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Alexandra Winter
     
  • commit e8a66d800471e2df7f0b484e2e46898b21d1fa82 upstream.

    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: caa1f0b10d18 ("s390/qeth: add VNICC enable/disable support")
    Signed-off-by: Alexandra Winter
    Signed-off-by: Julian Wiedmann
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Alexandra Winter
     
  • commit 68c57bfd52836e31bff33e5e1fc64029749d2c35 upstream.

    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: caa1f0b10d18 ("s390/qeth: add VNICC enable/disable support")
    Signed-off-by: Alexandra Winter
    Reviewed-by: Julian Wiedmann
    Signed-off-by: Julian Wiedmann
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Alexandra Winter
     
  • commit 8b5026bc16938920e4780b9094c3bf20e1e0939d upstream.

    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: 4a71df50047f ("qeth: new qeth device driver")
    Signed-off-by: Julian Wiedmann
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Julian Wiedmann
     

12 Jan, 2020

5 commits

  • [ Upstream commit 39bdbf3e648d801596498a5a625fbc9fc1c0002f ]

    ENOTSUPP is not uapi, use EOPNOTSUPP instead.

    Fixes: d66cb37e9664 ("qeth: Add new priority queueing options")
    Signed-off-by: Julian Wiedmann
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin

    Julian Wiedmann
     
  • [ Upstream commit 0f399305cd31e5c813086eaa264f7f47e205c10e ]

    When managing the promiscuous mode during an RX modeset, qeth caches the
    current HW state to avoid repeated programming of the same state on each
    modeset.

    But while tearing down a device, we forget to clear the cached state. So
    when the device is later set online again, the initial RX modeset
    doesn't program the promiscuous mode since we believe it is already
    enabled.
    Fix this by clearing the cached state in the tear-down path.

    Note that for the SBP variant of promiscuous mode, this accidentally
    works right now because we unconditionally restore the SBP role while
    re-initializing.

    Fixes: 4a71df50047f ("qeth: new qeth device driver")
    Signed-off-by: Julian Wiedmann
    Reviewed-by: Alexandra Winter
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin

    Julian Wiedmann
     
  • [ Upstream commit 2e3d7fa5d29b7ab649fdf8f9533ae0c0888a7fac ]

    Along with z/VM NICs, there's additional device types that only support
    a specific transport mode (eg. external-bridged IQD).
    Identify the corresponding error code, and raise a fitting error message
    so that the user knows to adjust their device configuration.

    On top of that also fix the subsequent error path, so that the rejected
    cmd doesn't need to wait for a timeout but gets cancelled straight away.

    Fixes: 4a71df50047f ("qeth: new qeth device driver")
    Signed-off-by: Julian Wiedmann
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin

    Julian Wiedmann
     
  • [ Upstream commit 00b39f698a4f1ee897227cace2e3937fc4412270 ]

    If for whatever reason the dasd_eckd_check_characteristics() function
    exits after at least some paths have their configuration data
    allocated those data is never freed again. In the error case the
    device->private pointer is set to NULL and dasd_eckd_uncheck_device()
    will exit without freeing the path data because of this NULL pointer.

    Fix by calling dasd_eckd_clear_conf_data() for error cases.

    Also use dasd_eckd_clear_conf_data() in dasd_eckd_uncheck_device()
    to avoid code duplication.

    Reported-by: Qian Cai
    Reviewed-by: Jan Hoeppner
    Signed-off-by: Stefan Haberland
    Signed-off-by: Jens Axboe
    Signed-off-by: Sasha Levin

    Stefan Haberland
     
  • [ Upstream commit dd4b3c83b9efac10d48a94c61372119fc555a077 ]

    The max data count (mdc) is an unsigned 16-bit integer value as per AR
    documentation and is received via ccw_device_get_mdc() for a specific
    path mask from the CIO layer. The function itself also always returns a
    positive mdc value or 0 in case mdc isn't supported or couldn't be
    determined.

    Though, the comment for this function describes a negative return value
    to indicate failures.

    As a result, the DASD device driver interprets the return value of
    ccw_device_get_mdc() incorrectly. The error case is essentially a dead
    code path.

    To fix this behaviour, check explicitly for a return value of 0 and
    change the comment for ccw_device_get_mdc() accordingly.

    This fix merely enables the error code path in the DASD functions
    get_fcx_max_data() and verify_fcx_max_data(). The actual functionality
    stays the same and is still correct.

    Reviewed-by: Cornelia Huck
    Signed-off-by: Jan Höppner
    Acked-by: Peter Oberparleiter
    Reviewed-by: Stefan Haberland
    Signed-off-by: Stefan Haberland
    Signed-off-by: Jens Axboe
    Signed-off-by: Sasha Levin

    Jan Höppner
     

05 Jan, 2020

1 commit

  • [ Upstream commit 6733775a92eacd612ac88afa0fd922e4ffeb2bc7 ]

    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: Harald Freudenberger
    Signed-off-by: Vasily Gorbik
    Signed-off-by: Sasha Levin

    Harald Freudenberger
     

18 Dec, 2019

1 commit

  • commit 100843f176109af94600e500da0428e21030ca7f upstream.

    While v2.6.26 commit b75db73159cc ("[SCSI] zfcp: Add qtcb dump to hba debug
    trace") is right that we don't want to flood the (payload) trace ring
    buffer, we don't trace successful FCP command responses by default. So we
    can include the channel log for problem determination with failed responses
    of any FSF request type.

    Fixes: b75db73159cc ("[SCSI] zfcp: Add qtcb dump to hba debug trace")
    Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
    Cc: #2.6.38+
    Link: https://lore.kernel.org/r/e37597b5c4ae123aaa85fd86c23a9f71e994e4a9.1572018132.git.bblock@linux.ibm.com
    Reviewed-by: Benjamin Block
    Signed-off-by: Steffen Maier
    Signed-off-by: Benjamin Block
    Signed-off-by: Martin K. Petersen
    Signed-off-by: Greg Kroah-Hartman

    Steffen Maier
     

21 Nov, 2019

2 commits

  • When propagating IO errors back to userspace, one error path in
    qeth_irq() currently returns '1' instead of a proper errno.

    Fixes: 54daaca7024d ("s390/qeth: cancel cmd on early error")
    Signed-off-by: Julian Wiedmann
    Signed-off-by: David S. Miller

    Julian Wiedmann
     
  • The L2 bridgeport code uses the coarse 'conf_mutex' for guarding access
    to its configuration state.
    This can result in a deadlock when qeth_l2_stop_card() - called under the
    conf_mutex - blocks on flush_workqueue() to wait for the completion of
    pending bridgeport workers. Such workers would also need to aquire
    the conf_mutex, stalling indefinitely.

    Introduce a lock that specifically guards the bridgeport configuration,
    so that the workers no longer need the conf_mutex.
    Wrapping qeth_l2_promisc_to_bridge() in this fine-grained lock then also
    fixes a theoretical race against a concurrent qeth_bridge_port_role_store()
    operation.

    Fixes: c0a2e4d10d93 ("s390/qeth: conclude all event processing before offlining a card")
    Signed-off-by: Julian Wiedmann
    Reviewed-by: Alexandra Winter
    Signed-off-by: David S. Miller

    Julian Wiedmann
     

22 Oct, 2019

1 commit

  • If a process is interrupted while accessing the crypto device and the
    global ap_perms_mutex is contented, release() could return early and
    fail to free related resources.

    Fixes: 00fab2350e6b ("s390/zcrypt: multiple zcrypt device nodes support")
    Cc: # 4.19
    Cc: Harald Freudenberger
    Signed-off-by: Johan Hovold
    Signed-off-by: Heiko Carstens
    Signed-off-by: Vasily Gorbik

    Johan Hovold
     

20 Oct, 2019

1 commit

  • Pull networking fixes from David Miller:
    "I was battling a cold after some recent trips, so quite a bit piled up
    meanwhile, sorry about that.

    Highlights:

    1) Fix fd leak in various bpf selftests, from Brian Vazquez.

    2) Fix crash in xsk when device doesn't support some methods, from
    Magnus Karlsson.

    3) Fix various leaks and use-after-free in rxrpc, from David Howells.

    4) Fix several SKB leaks due to confusion of who owns an SKB and who
    should release it in the llc code. From Eric Biggers.

    5) Kill a bunc of KCSAN warnings in TCP, from Eric Dumazet.

    6) Jumbo packets don't work after resume on r8169, as the BIOS resets
    the chip into non-jumbo mode during suspend. From Heiner Kallweit.

    7) Corrupt L2 header during MPLS push, from Davide Caratti.

    8) Prevent possible infinite loop in tc_ctl_action, from Eric
    Dumazet.

    9) Get register bits right in bcmgenet driver, based upon chip
    version. From Florian Fainelli.

    10) Fix mutex problems in microchip DSA driver, from Marek Vasut.

    11) Cure race between route lookup and invalidation in ipv4, from Wei
    Wang.

    12) Fix performance regression due to false sharing in 'net'
    structure, from Eric Dumazet"

    * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (145 commits)
    net: reorder 'struct net' fields to avoid false sharing
    net: dsa: fix switch tree list
    net: ethernet: dwmac-sun8i: show message only when switching to promisc
    net: aquantia: add an error handling in aq_nic_set_multicast_list
    net: netem: correct the parent's backlog when corrupted packet was dropped
    net: netem: fix error path for corrupted GSO frames
    macb: propagate errors when getting optional clocks
    xen/netback: fix error path of xenvif_connect_data()
    net: hns3: fix mis-counting IRQ vector numbers issue
    net: usb: lan78xx: Connect PHY before registering MAC
    vsock/virtio: discard packets if credit is not respected
    vsock/virtio: send a credit update when buffer size is changed
    mlxsw: spectrum_trap: Push Ethernet header before reporting trap
    net: ensure correct skb->tstamp in various fragmenters
    net: bcmgenet: reset 40nm EPHY on energy detect
    net: bcmgenet: soft reset 40nm EPHYs before MAC init
    net: phy: bcm7xxx: define soft_reset for 40nm EPHY
    net: bcmgenet: don't set phydev->link from MAC
    net: Update address for MediaTek ethernet driver in MAINTAINERS
    ipv4: fix race condition between route lookup and invalidation
    ...

    Linus Torvalds
     

16 Oct, 2019

1 commit

  • Pull SCSI fixes from James Bottomley:
    "Five changes, two in drivers (qla2xxx, zfcp), one to MAINTAINERS
    (qla2xxx) and two in the core.

    The last two are mostly about removing incorrect messages from the
    kernel log: the resid message is definitely wrong and the sync cache
    on protected drive problem is arguably wrong"

    * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
    scsi: MAINTAINERS: Update qla2xxx driver
    scsi: zfcp: fix reaction on bit error threshold notification
    scsi: core: save/restore command resid for error handling
    scsi: qla2xxx: Remove WARN_ON_ONCE in qla2x00_status_cont_entry()
    scsi: sd: Ignore a failure to sync cache due to lack of authorization

    Linus Torvalds
     

10 Oct, 2019

3 commits

  • Commit 37db8985b211 ("s390/cio: add basic protected virtualization
    support") breaks virtio-ccw devices with VIRTIO_F_IOMMU_PLATFORM for non
    Protected Virtualization (PV) guests. The problem is that the dma_mask
    of the ccw device, which is used by virtio core, gets changed from 64 to
    31 bit, because some of the DMA allocations do require 31 bit
    addressable memory. For PV the only drawback is that some of the virtio
    structures must end up in ZONE_DMA because we have the bounce the
    buffers mapped via DMA API anyway.

    But for non PV guests we have a problem: because of the 31 bit mask
    guests bigger than 2G are likely to try bouncing buffers. The swiotlb
    however is only initialized for PV guests, because we don't want to
    bounce anything for non PV guests. The first such map kills the guest.

    Since the DMA API won't allow us to specify for each allocation whether
    we need memory from ZONE_DMA (31 bit addressable) or any DMA capable
    memory will do, let us use coherent_dma_mask (which is used for
    allocations) to force allocating form ZONE_DMA while changing dma_mask
    to DMA_BIT_MASK(64) so that at least the streaming API will regard
    the whole memory DMA capable.

    Signed-off-by: Halil Pasic
    Reported-by: Marc Hartmayer
    Suggested-by: Robin Murphy
    Fixes: 37db8985b211 ("s390/cio: add basic protected virtualization support")
    Link: https://lore.kernel.org/lkml/20190930153803.7958-1-pasic@linux.ibm.com
    Reviewed-by: Christoph Hellwig
    Reviewed-by: Cornelia Huck
    Signed-off-by: Christian Borntraeger
    Signed-off-by: Vasily Gorbik

    Halil Pasic
     
  • Without this patch, a command bit in the supported commands mask is only
    ever set to unsupported during set online. If a command is ever marked as
    unsupported (e.g. because of error during qeth_l2_vnicc_query_cmds),
    subsequent successful initialization (offline/online) would not bring it
    back.

    Fixes: caa1f0b10d18 ("s390/qeth: add VNICC enable/disable support")
    Signed-off-by: Alexandra Winter
    Signed-off-by: Julian Wiedmann
    Signed-off-by: Jakub Kicinski

    Alexandra Winter
     
  • Smatch discovered the use of uninitialized variable sup_cmds
    in error paths.

    Fixes: caa1f0b10d18 ("s390/qeth: add VNICC enable/disable support")
    Signed-off-by: Alexandra Winter
    Signed-off-by: Julian Wiedmann
    Signed-off-by: Jakub Kicinski

    Alexandra Winter
     

05 Oct, 2019

2 commits

  • Pull s390 fixes from Vasily Gorbik:

    - defconfig updates

    - Fix build errors with CC_OPTIMIZE_FOR_SIZE due to usage of "i"
    constraint for function arguments. Two kvm changes acked-by Christian
    Borntraeger.

    - Fix -Wunused-but-set-variable warnings in mm code.

    - Avoid a constant misuse in qdio.

    - Handle a case when cpumf is temporarily unavailable.

    * tag 's390-5.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
    KVM: s390: mark __insn32_query() as __always_inline
    KVM: s390: fix __insn32_query() inline assembly
    s390: update defconfigs
    s390/pci: mark function(s) __always_inline
    s390/mm: mark function(s) __always_inline
    s390/jump_label: mark function(s) __always_inline
    s390/cpu_mf: mark function(s) __always_inline
    s390/atomic,bitops: mark function(s) __always_inline
    s390/mm: fix -Wunused-but-set-variable warnings
    s390: mark __cpacf_query() as __always_inline
    s390/qdio: clarify size of the QIB parm area
    s390/cpumf: Fix indentation in sampling device driver
    s390/cpumsf: Check for CPU Measurement sampling
    s390/cpumf: Use consistant debug print format

    Linus Torvalds
     
  • Pull block fixes from Jens Axboe:

    - Mandate timespec64 for the io_uring timeout ABI (Arnd)

    - Set of NVMe changes via Sagi:
    - controller removal race fix from Balbir
    - quirk additions from Gabriel and Jian-Hong
    - nvme-pci power state save fix from Mario
    - Add 64bit user commands (for 64bit registers) from Marta
    - nvme-rdma/nvme-tcp fixes from Max, Mark and Me
    - Minor cleanups and nits from James, Dan and John

    - Two s390 dasd fixes (Jan, Stefan)

    - Have loop change block size in DIO mode (Martijn)

    - paride pg header ifdef guard (Masahiro)

    - Two blk-mq queue scheduler tweaks, fixing an ordering issue on zoned
    devices and suboptimal performance on others (Ming)

    * tag 'for-linus-2019-10-03' of git://git.kernel.dk/linux-block: (22 commits)
    block: sed-opal: fix sparse warning: convert __be64 data
    block: sed-opal: fix sparse warning: obsolete array init.
    block: pg: add header include guard
    Revert "s390/dasd: Add discard support for ESE volumes"
    s390/dasd: Fix error handling during online processing
    io_uring: use __kernel_timespec in timeout ABI
    loop: change queue block size to match when using DIO
    blk-mq: apply normal plugging for HDD
    blk-mq: honor IO scheduler for multiqueue devices
    nvme-rdma: fix possible use-after-free in connect timeout
    nvme: Move ctrl sqsize to generic space
    nvme: Add ctrl attributes for queue_count and sqsize
    nvme: allow 64-bit results in passthru commands
    nvme: Add quirk for Kingston NVME SSD running FW E8FK11.T
    nvmet-tcp: remove superflous check on request sgl
    Added QUIRKs for ADATA XPG SX8200 Pro 512GB
    nvme-rdma: Fix max_hw_sectors calculation
    nvme: fix an error code in nvme_init_subsystem()
    nvme-pci: Save PCI state before putting drive into deepest state
    nvme-tcp: fix wrong stop condition in io_work
    ...

    Linus Torvalds
     

04 Oct, 2019

1 commit

  • On excessive bit errors for the FCP channel ingress fibre path, the channel
    notifies us. Previously, we only emitted a kernel message and a trace
    record. Since performance can become suboptimal with I/O timeouts due to
    bit errors, we now stop using an FCP device by default on channel
    notification so multipath on top can timely failover to other paths. A new
    module parameter zfcp.ber_stop can be used to get zfcp old behavior.

    User explanation of new kernel message:

    * Description:
    * The FCP channel reported that its bit error threshold has been exceeded.
    * These errors might result from a problem with the physical components
    * of the local fibre link into the FCP channel.
    * The problem might be damage or malfunction of the cable or
    * cable connection between the FCP channel and
    * the adjacent fabric switch port or the point-to-point peer.
    * Find details about the errors in the HBA trace for the FCP device.
    * The zfcp device driver closed down the FCP device
    * to limit the performance impact from possible I/O command timeouts.
    * User action:
    * Check for problems on the local fibre link, ensure that fibre optics are
    * clean and functional, and all cables are properly plugged.
    * After the repair action, you can manually recover the FCP device by
    * writing "0" into its "failed" sysfs attribute.
    * If recovery through sysfs is not possible, set the CHPID of the device
    * offline and back online on the service element.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: #2.6.30+
    Link: https://lore.kernel.org/r/20191001104949.42810-1-maier@linux.ibm.com
    Reviewed-by: Jens Remus
    Reviewed-by: Benjamin Block
    Signed-off-by: Steffen Maier
    Signed-off-by: Martin K. Petersen

    Steffen Maier
     

01 Oct, 2019

3 commits

  • This reverts commit 7e64db1597fe114b83fe17d0ba96c6aa5fca419a.

    The thin provisioning feature introduces an IOCTL and the discard support
    to allow userspace tools and filesystems to release unused and previously
    allocated space respectively.

    During some internal performance improvements and further tests, the
    release of allocated space revealed some issues that may lead to data
    corruption in some configurations when filesystems are mounted with
    discard support enabled.

    While we're working on a fix and trying to clarify the situation,
    this commit reverts the discard support for ESE volumes to prevent
    potential data corruption.

    Cc: # 5.3
    Signed-off-by: Stefan Haberland
    Signed-off-by: Jens Axboe

    Stefan Haberland
     
  • It is possible that the CCW commands for reading volume and extent pool
    information are not supported, either by the storage server (for
    dedicated DASDs) or by z/VM (for virtual devices, such as MDISKs).

    As a command reject will occur in such a case, the current error
    handling leads to a failing online processing and thus the DASD can't be
    used at all.

    Since the data being read is not essential for an fully operational
    DASD, the error handling can be removed. Information about the failing
    command is sent to the s390dbf debug feature.

    Fixes: c729696bcf8b ("s390/dasd: Recognise data for ESE volumes")
    Cc: # 5.3
    Reported-by: Frank Heimes
    Signed-off-by: Jan Höppner
    Signed-off-by: Stefan Haberland
    Signed-off-by: Jens Axboe

    Jan Höppner
     
  • The QIB parm area is 128 bytes long. Current code consistently misuses
    an _entirely unrelated_ QDIO constant, merely because it has the same
    value. Stop doing so.

    Signed-off-by: Julian Wiedmann
    Reviewed-by: Benjamin Block
    Reviewed-by: Jens Remus
    Signed-off-by: Vasily Gorbik

    Julian Wiedmann
     

27 Sep, 2019

1 commit

  • Pull more s390 updates from Vasily Gorbik:

    - Fix three kasan findings

    - Add PERF_EVENT_IOC_PERIOD ioctl support

    - Add Crypto Express7S support and extend sysfs attributes for pkey

    - Minor common I/O layer documentation corrections

    * tag 's390-5.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
    s390/cio: exclude subchannels with no parent from pseudo check
    s390/cio: avoid calling strlen on null pointer
    s390/topology: avoid firing events before kobjs are created
    s390/cpumf: Remove mixed white space
    s390/cpum_sf: Support ioctl PERF_EVENT_IOC_PERIOD
    s390/zcrypt: CEX7S exploitation support
    s390/cio: fix intparm documentation
    s390/pkey: Add sysfs attributes to emit AES CIPHER key blobs

    Linus Torvalds
     

24 Sep, 2019

2 commits

  • ccw console is created early in start_kernel and used before css is
    initialized or ccw console subchannel is registered. Until then console
    subchannel does not have a parent. For that reason assume subchannels
    with no parent are not pseudo subchannels. This fixes the following
    kasan finding:

    BUG: KASAN: global-out-of-bounds in sch_is_pseudo_sch+0x8e/0x98
    Read of size 8 at addr 00000000000005e8 by task swapper/0/0

    CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.0-rc8-07370-g6ac43dd12538 #2
    Hardware name: IBM 2964 NC9 702 (z/VM 6.4.0)
    Call Trace:
    ([] show_stack+0x14e/0x1e0)
    [] dump_stack+0x1a4/0x1f8
    [] print_address_description+0x64/0x3c8
    [] __kasan_report+0x14e/0x180
    [] sch_is_pseudo_sch+0x8e/0x98
    [] cio_enable_subchannel+0x1d0/0x510
    [] ccw_device_recognition+0x12c/0x188
    [] ccw_device_enable_console+0x138/0x340
    [] con3215_init+0x25e/0x300
    [] console_init+0x68a/0x9b8
    [] start_kernel+0x4fe/0x728
    [] startup_continue+0x70/0xd0

    Cc: stable@vger.kernel.org
    Reviewed-by: Sebastian Ott
    Signed-off-by: Vasily Gorbik

    Vasily Gorbik
     
  • Fix the following kasan finding:
    BUG: KASAN: global-out-of-bounds in ccwgroup_create_dev+0x850/0x1140
    Read of size 1 at addr 0000000000000000 by task systemd-udevd.r/561

    CPU: 30 PID: 561 Comm: systemd-udevd.r Tainted: G B
    Hardware name: IBM 3906 M04 704 (LPAR)
    Call Trace:
    ([] show_stack+0x14e/0x1a8)
    [] dump_stack+0x1d0/0x218
    [] print_address_description+0x64/0x380
    [] __kasan_report+0x138/0x168
    [] ccwgroup_create_dev+0x850/0x1140
    [] group_store+0x3a/0x50
    [] kernfs_fop_write+0x246/0x3b8
    [] vfs_write+0x132/0x450
    [] ksys_write+0x122/0x208
    [] system_call+0x2a6/0x2c8

    Triggered by:
    openat(AT_FDCWD, "/sys/bus/ccwgroup/drivers/qeth/group",
    O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 16
    write(16, "0.0.bd00,0.0.bd01,0.0.bd02", 26) = 26

    The problem is that __get_next_id in ccwgroup_create_dev might set "buf"
    buffer pointer to NULL and explicit check for that is required.

    Cc: stable@vger.kernel.org
    Reviewed-by: Sebastian Ott
    Signed-off-by: Vasily Gorbik

    Vasily Gorbik
     

19 Sep, 2019

3 commits

  • This patch adds CEX7 exploitation support for the AP bus code,
    the zcrypt device driver zoo and the vfio device driver.

    Signed-off-by: Harald Freudenberger
    Reviewed-by: Ingo Franzki
    Signed-off-by: Vasily Gorbik

    Harald Freudenberger
     
  • The common I/O layer is maintaining an "intparm" inspired by
    the hardware intparm for driver usage. This "intparm" is not
    only applicaple for ssch, but also for hsch/csch. The kerneldoc
    states that it is only updated for hsch/csch if no prior request
    is pending; however, this is not what the code does (whether
    that would actually desireable is a different issue.)

    Let's at least fix the kerneldoc for now.

    Fixes: b2ffd8e9a76e ("[S390] cio: Add docbook comments.")
    Signed-off-by: Cornelia Huck
    Signed-off-by: Sebastian Ott
    Signed-off-by: Vasily Gorbik

    Cornelia Huck
     
  • Now that the pkey kernel module also supports CCA AES CIPHER keys:
    Add binary read-only sysfs attributes for the pkey module
    that can be used to read random CCA AES CIPHER secure keys from,
    similar to the already existing sysfs attributes for AES DATA and
    random protected keys. Keys are read from these attributes using
    a cat-like interface.

    A typical use case for those keys is to encrypt a swap device
    using the paes cipher. During processing of /etc/crypttab, the
    CCA random AES CIPHER secure key to encrypt the swap device is
    read from one of the attributes.

    The following attributes are added:
    ccacipher/ccacipher_aes_128
    ccacipher/ccacipher_aes_192
    ccacipher/ccacipher_aes_256
    ccacipher/ccacipher_aes_128_xts
    ccacipher/ccacipher_aes_256_xts
    Each attribute emits a secure key blob for the corresponding
    key size and cipher mode.

    Signed-off-by: Ingo Franzki
    Reviewed-by: Harald Freudenberger
    Signed-off-by: Vasily Gorbik

    Ingo Franzki