s390/zcrypt: Fix zcrypt suspend/resume behavior
authorIngo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com>
Mon, 25 Jul 2016 12:52:28 +0000 (14:52 +0200)
committerMartin Schwidefsky <schwidefsky@de.ibm.com>
Sun, 31 Jul 2016 09:27:58 +0000 (05:27 -0400)
commitd6d86c57d77d466df2096b134e5f54463d3f0fb8
treee228aa3826f9e587db7c2d5f88e0e6f36da78477
parent4475aeb8b77db34dea96b09900ba0cb245b6fb42
s390/zcrypt: Fix zcrypt suspend/resume behavior

The device suspend call triggers all ap devices to fetch potentially
available response messages from the queues. Therefore the
corresponding zcrypt device, that is allocated asynchronously after
ap device probing, needs to be fully prepared. This race condition
could lead to uninitialized response buffers while trying to read
from the queues.

Introduce a new callback within the ap layer to get noticed when a
zcrypt device is fully prepared. Additional checks prevent reading
from devices that are not fully prepared.

Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
drivers/s390/crypto/ap_bus.c
drivers/s390/crypto/ap_bus.h
drivers/s390/crypto/zcrypt_cex2a.c
drivers/s390/crypto/zcrypt_cex4.c
drivers/s390/crypto/zcrypt_pcixcc.c
This page took 0.026846 seconds and 5 git commands to generate.