linux-toradex.git/drivers/s390, branch v4.20

virtio/s390: fix race in ccw_io_helper()

2018-12-06T19:22:35+00:00

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:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788432

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
too.

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: Halil Pasic 
Reported-by: Colin Ian King 
Cc: stable@vger.kernel.org
Message-Id: <20180925121309.58524-3-pasic@linux.ibm.com>
Signed-off-by: Cornelia Huck 
Signed-off-by: Michael S. Tsirkin

virtio/s390: avoid race on vcdev->config

2018-12-06T19:22:34+00:00

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: Halil Pasic 
Cc: stable@vger.kernel.org
Message-Id: <20180925121309.58524-2-pasic@linux.ibm.com>
Signed-off-by: Cornelia Huck 
Signed-off-by: Michael S. Tsirkin

Merge tag 's390-4.20-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux

2018-11-29T18:10:42+00:00

Pull s390 updates from Martin Schwidefsky:

 - Add two missing kfree calls on error paths in the vfio-ccw code

 - Make sure that all data structures of a mediated vfio-ccw device are
   initialized before registering it

 - Fix a sparse warning in vfio-ccw

 - A followup patch for the pgtable_bytes accounting, the page table
   downgrade for compat processes missed a mm_dec_nr_pmds()

 - Reject sampling requests in the PMU init function of the CPU
   measurement counter facility

 - With the vfio AP driver an AP queue needs to be reset on every device
   probe as the alternative driver could have modified the device state

* tag 's390-4.20-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/mm: correct pgtable_bytes on page table downgrade
  s390/zcrypt: reinit ap queue state machine during device probe
  s390/cpum_cf: Reject request for sampling in event initialization
  s390/cio: Fix cleanup when unsupported IDA format is used
  s390/cio: Fix cleanup of pfn_array alloc failure
  vfio: ccw: Register mediated device once all structures are initialized
  s390/cio: make vfio_ccw_io_region static

s390/qeth: fix length check in SNMP processing

2018-11-28T19:16:54+00:00

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: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Julian Wiedmann 
Reviewed-by: Ursula Braun 
Signed-off-by: David S. Miller

s390/zcrypt: reinit ap queue state machine during device probe

2018-11-27T09:43:35+00:00

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: 7e0bdbe5c21c ("s390/zcrypt: AP bus support for alternate driver(s)")
Cc: stable@vger.kernel.org # 4.19+
Signed-off-by: Harald Freudenberger 
Reviewd-by: Tony Krowiak 
Reviewd-by: Martin Schwidefsky 
Signed-off-by: Martin Schwidefsky

s390/ism: clear dmbe_mask bit before SMC IRQ handling

2018-11-14T22:21:20+00:00

SMC-D stress workload showed connection stalls. Since the firmware
decides to skip raising an interrupt if the SBA DMBE mask bit is
still set, this SBA DMBE mask bit should be cleared before the
IRQ handling in the SMC code runs. Otherwise there are small windows
possible with missing interrupts for incoming data.
SMC-D currently does not care about the old value of the SBA DMBE
mask.

Acked-by: Sebastian Ott 
Signed-off-by: Ursula Braun 
Signed-off-by: David S. Miller

s390/cio: Fix cleanup when unsupported IDA format is used

2018-11-13T10:45:17+00:00

Direct returns from within a loop are rude, but it doesn't mean it gets
to avoid releasing the memory acquired beforehand.

Signed-off-by: Eric Farman 
Message-Id: <20181109023937.96105-3-farman@linux.ibm.com>
Reviewed-by: Farhan Ali 
Reviewed-by: Pierre Morel 
Acked-by: Halil Pasic 
Signed-off-by: Cornelia Huck

s390/cio: Fix cleanup of pfn_array alloc failure

2018-11-13T10:45:17+00:00

If pfn_array_alloc fails somehow, we need to release the pfn_array_table
that was malloc'd earlier.

Signed-off-by: Eric Farman 
Message-Id: <20181109023937.96105-2-farman@linux.ibm.com>
Acked-by: Halil Pasic 
Signed-off-by: Cornelia Huck

vfio: ccw: Register mediated device once all structures are initialized

2018-11-13T10:45:17+00:00

Let's register the mediated device when all the data structures
which could be used are initialized.

Signed-off-by: Pierre Morel 
Reviewed-by: Eric Farman 
Message-Id: <1540487720-11634-3-git-send-email-pmorel@linux.ibm.com>
Acked-by: Halil Pasic 
Signed-off-by: Cornelia Huck

s390/cio: make vfio_ccw_io_region static

2018-11-13T10:45:17+00:00

Fix the following sparse warning:
drivers/s390/cio/vfio_ccw_drv.c:25:19: warning: symbol 'vfio_ccw_io_region'
was not declared. Should it be static?

Signed-off-by: Sebastian Ott 
Message-Id: 
Signed-off-by: Cornelia Huck