BMC/Intel-BMC/linux.git/drivers/s390/cio, branch dev-4.17

s390/qdio: don't release memory in qdio_setup_irq()

2018-05-15T05:40:38+00:00

Calling qdio_release_memory() on error is just plain wrong. It frees the main qdio_irq struct, when following code still uses it. Also, no other error path in qdio_establish() does this. So trust callers to clean up via qdio_free() if some step of the QDIO initialization fails. Fixes: 779e6e1c724d ("[S390] qdio: new qdio driver.") Cc: #v2.6.27+ Signed-off-by: Julian Wiedmann Signed-off-by: Martin Schwidefsky

s390/qdio: fix access to uninitialized qdio_q fields

2018-05-15T05:40:36+00:00

Ever since CQ/QAOB support was added, calling qdio_free() straight after qdio_alloc() results in qdio_release_memory() accessing uninitialized memory (ie. q->u.out.use_cq and q->u.out.aobs). Followed by a kmem_cache_free() on the random AOB addresses. For older kernels that don't have 6e30c549f6ca, the same applies if qdio_establish() fails in the DEV_STATE_ONLINE check. While initializing q->u.out.use_cq would be enough to fix this particular bug, the more future-proof change is to just zero-alloc the whole struct. Fixes: 104ea556ee7f ("qdio: support asynchronous delivery of storage blocks") Cc: #v3.2+ Signed-off-by: Julian Wiedmann Signed-off-by: Martin Schwidefsky

vfio: ccw: fix cleanup if cp_prefetch fails

2018-04-27T05:23:20+00:00

If the translation of a channel program fails, we may end up attempting to clean up (free, unpin) stuff that never got translated (and allocated, pinned) in the first place. By adjusting the lengths of the chains accordingly (so the element that failed, and all subsequent elements are excluded) cleanup activities based on false assumptions can be avoided. Let's make sure cp_free works properly after cp_prefetch returns with an error by setting ch_len of a ccw chain to the number of the translated CCWs on that chain. Cc: stable@vger.kernel.org #v4.12+ Acked-by: Pierre Morel Reviewed-by: Dong Jia Shi Signed-off-by: Halil Pasic Signed-off-by: Dong Jia Shi Message-Id: <20180423110113.59385-2-bjsdjshi@linux.vnet.ibm.com> [CH: fixed typos] Signed-off-by: Cornelia Huck Signed-off-by: Martin Schwidefsky

vfio: ccw: process ssch with interrupts disabled

2018-04-23T05:57:17+00:00

When we call ssch, an interrupt might already be pending once we return from the START SUBCHANNEL instruction. Therefore we need to make sure interrupts are disabled while holding the subchannel lock until after we're done with our processing. Cc: stable@vger.kernel.org #v4.12+ Reviewed-by: Dong Jia Shi Acked-by: Halil Pasic Acked-by: Pierre Morel Signed-off-by: Cornelia Huck Signed-off-by: Martin Schwidefsky

s390/cio: update chpid descriptor after resource accessibility event

2018-04-23T05:57:16+00:00

Channel path descriptors have been seen as something stable (as long as the chpid is configured). Recent tests have shown that the descriptor can also be altered when the link state of a channel path changes. Thus it is necessary to update the descriptor during handling of resource accessibility events. Cc: Signed-off-by: Sebastian Ott Reviewed-by: Peter Oberparleiter Signed-off-by: Martin Schwidefsky

s390: assume diag308 set always works

2018-04-10T05:38:59+00:00

diag308 set has been available for many machine generations, and alternative reipl code paths has not been exercised and seems to be broken without noticing for a while now. So, cleaning up all obsolete reipl methods except currently used ones, assuming that diag308 set always works. Also removing not longer needed reset callbacks. Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Martin Schwidefsky

s390/ipl: rely on diag308 store to get ipl info

2018-04-10T05:38:59+00:00

For both ccw and fcp boot retrieve ipl info from ipl block received via diag308 store. Old scsi ipl parm block handling and cio_get_iplinfo are removed. Ipl type is deducted from ipl block (if valid). Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Martin Schwidefsky

s390/qdio: lock device while installing IRQ handler

2018-04-10T05:38:58+00:00

During setup, qdio takes control of the presented ccw device and replaces the device's IRQ handler with its own. To avoid any interference with conccurent activity on the device, this should be done while holding the device's lock. Signed-off-by: Julian Wiedmann Reviewed-by: Benjamin Block Signed-off-by: Martin Schwidefsky

s390/qdio: clear intparm during shutdown

2018-04-10T05:38:58+00:00

During shutdown, qdio returns its ccw device back to control by the upper-layer driver. But there is a remote chance that by the time where the IRQ handler gets switched back, the interrupt for the preceding ccw_device_{clear,halt} hasn't been presented yet. Upper-layer drivers would then need to handle this IRQ - and since the IO is issued with an intparm, it could very well be confused with whatever intparm mechanism the driver uses itself (eg intparm == request address). So when switching over the IRQ handler, also clear the intparm and have upper-layer drivers deal with any such delayed interrupt as if it was unsolicited. Suggested-by: Sebastian Ott Signed-off-by: Julian Wiedmann Signed-off-by: Martin Schwidefsky

s390/ccwgroup: require at least one ccw device

2018-04-10T05:38:57+00:00

ccwgroup_create_dev() derives the gdev's device name from gdev->cdev[0], so make sure that this reference is valid. For robustness only, all current ccwgroup drivers get this right. Signed-off-by: Julian Wiedmann Acked-by: Sebastian Ott Signed-off-by: Martin Schwidefsky