| Message ID | 1561666403-11046-1-git-send-email-frank.heimes@canonical.com |
|---|---|
| Headers | show |
| Series | Fix wrong dispatching for control domain CPRBs (LP: 1832624) | expand |
On 27.06.19 22:13, frank.heimes@canonical.com wrote: > Buglink: https://bugs.launchpad.net/bugs/1832624 > > The cherry-pick [Patch 1/2] is for disco, the backport [Patch 2/2] for bionic. > > SRU Justification: > > [Impact] > > * Unable to maintain control-only crypto domains > > * The communication to control-only domains does not work in any way. > > * And depending on the setup (lowest numerical domain is control-only) the TKE does not see the crypto card at all. > > [Fix] > > * 7379e652797c0b9b5f6caea1576f2dff9ce6a708 7379e65 "s390/zcrypt: Fix wrong dispatching for control domain CPRBs" > > * Backport: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832624/+attachment/5271392/+files/s390-zcrypt-Fix-wrong-dispatching-for-control-domain.patch > > [Test Case] > > * Configure a control-only domain to the activation profile of LPAR A > > * Configure a control-and-usage domain to the activation profile of LPAR B > > * Try to communicate to LPAR A with the control-only domain (e.g. trying to read or set master key) > > [Regression Potential] > > * The regression potential can be considered as moderate since this is purely s390x specific > > * and again limited to CryptoExpress adapter cards. > > * It only occurs if crypto domains are configured as control-only or better control-only in combination with control-and-usage. > > * The majority of configurations is control-and-usage, since this offers more flexibility and covers more use cases. > > > [Other Info] > > * Problem was found during tests at IBM and is a so called 'preventive fix' > > * The given patch is supposed to fix this issue and became upstream accepted with kernel 5.2-rc3. > > * It applies cleanly to disco master-next while cherry-picking. > > * But needs the the backport (from comment #3) for bionic's master-next kernel 4.15. > > * Once we have the target kernel 5.2 in Eoan, it will be there, too. > > > Harald Freudenberger (1): > From: Harald Freudenberger <freude@linux.ibm.com> > > arch/s390/include/asm/ap.h | 4 ++-- > drivers/s390/crypto/ap_bus.c | 26 ++++++++++++++++++++++---- > drivers/s390/crypto/ap_bus.h | 3 +++ > drivers/s390/crypto/zcrypt_api.c | 17 ++++++++++++++--- > 4 files changed, 41 insertions(+), 9 deletions(-) > In that case I would have sent the patches as [SRU D][PATCH 1/1] ... (cherry-pick) [SRU B][PATCH 1/1] ... (backport) Also I think the subject of the cherry pick got too many "s390/zcrypt" in it (reminder for us to fix up when applying). And the bug report should have been nominated for Disco and Bionic (I have done that now). Acked-by: Stefan Bader <stefan.bader@canonical.com>
On 6/27/19 10:13 PM, frank.heimes@canonical.com wrote: > Buglink: https://bugs.launchpad.net/bugs/1832624 > > The cherry-pick [Patch 1/2] is for disco, the backport [Patch 2/2] for bionic. > > SRU Justification: > > [Impact] > > * Unable to maintain control-only crypto domains > > * The communication to control-only domains does not work in any way. > > * And depending on the setup (lowest numerical domain is control-only) the TKE does not see the crypto card at all. > > [Fix] > > * 7379e652797c0b9b5f6caea1576f2dff9ce6a708 7379e65 "s390/zcrypt: Fix wrong dispatching for control domain CPRBs" > > * Backport: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832624/+attachment/5271392/+files/s390-zcrypt-Fix-wrong-dispatching-for-control-domain.patch > > [Test Case] > > * Configure a control-only domain to the activation profile of LPAR A > > * Configure a control-and-usage domain to the activation profile of LPAR B > > * Try to communicate to LPAR A with the control-only domain (e.g. trying to read or set master key) > > [Regression Potential] > > * The regression potential can be considered as moderate since this is purely s390x specific > > * and again limited to CryptoExpress adapter cards. > > * It only occurs if crypto domains are configured as control-only or better control-only in combination with control-and-usage. > > * The majority of configurations is control-and-usage, since this offers more flexibility and covers more use cases. > > > [Other Info] > > * Problem was found during tests at IBM and is a so called 'preventive fix' > > * The given patch is supposed to fix this issue and became upstream accepted with kernel 5.2-rc3. > > * It applies cleanly to disco master-next while cherry-picking. > > * But needs the the backport (from comment #3) for bionic's master-next kernel 4.15. > > * Once we have the target kernel 5.2 in Eoan, it will be there, too. > > > Harald Freudenberger (1): > From: Harald Freudenberger <freude@linux.ibm.com> > > arch/s390/include/asm/ap.h | 4 ++-- > drivers/s390/crypto/ap_bus.c | 26 ++++++++++++++++++++++---- > drivers/s390/crypto/ap_bus.h | 3 +++ > drivers/s390/crypto/zcrypt_api.c | 17 ++++++++++++++--- > 4 files changed, 41 insertions(+), 9 deletions(-) > Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Thank you, Kleber
On 6/27/19 10:13 PM, frank.heimes@canonical.com wrote: > Buglink: https://bugs.launchpad.net/bugs/1832624 > > The cherry-pick [Patch 1/2] is for disco, the backport [Patch 2/2] for bionic. > > SRU Justification: > > [Impact] > > * Unable to maintain control-only crypto domains > > * The communication to control-only domains does not work in any way. > > * And depending on the setup (lowest numerical domain is control-only) the TKE does not see the crypto card at all. > > [Fix] > > * 7379e652797c0b9b5f6caea1576f2dff9ce6a708 7379e65 "s390/zcrypt: Fix wrong dispatching for control domain CPRBs" > > * Backport: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832624/+attachment/5271392/+files/s390-zcrypt-Fix-wrong-dispatching-for-control-domain.patch > > [Test Case] > > * Configure a control-only domain to the activation profile of LPAR A > > * Configure a control-and-usage domain to the activation profile of LPAR B > > * Try to communicate to LPAR A with the control-only domain (e.g. trying to read or set master key) > > [Regression Potential] > > * The regression potential can be considered as moderate since this is purely s390x specific > > * and again limited to CryptoExpress adapter cards. > > * It only occurs if crypto domains are configured as control-only or better control-only in combination with control-and-usage. > > * The majority of configurations is control-and-usage, since this offers more flexibility and covers more use cases. > > > [Other Info] > > * Problem was found during tests at IBM and is a so called 'preventive fix' > > * The given patch is supposed to fix this issue and became upstream accepted with kernel 5.2-rc3. > > * It applies cleanly to disco master-next while cherry-picking. > > * But needs the the backport (from comment #3) for bionic's master-next kernel 4.15. > > * Once we have the target kernel 5.2 in Eoan, it will be there, too. > > > Harald Freudenberger (1): > From: Harald Freudenberger <freude@linux.ibm.com> > > arch/s390/include/asm/ap.h | 4 ++-- > drivers/s390/crypto/ap_bus.c | 26 ++++++++++++++++++++++---- > drivers/s390/crypto/ap_bus.h | 3 +++ > drivers/s390/crypto/zcrypt_api.c | 17 ++++++++++++++--- > 4 files changed, 41 insertions(+), 9 deletions(-) > Applied to {bionic,disco}/master-next branch. As Stefan mentioned, patch 1/2 had too many "s390/zcrypt:" in the subject, and also patch 2/2 had a "(backport)" string at the end of the original subject. Please keep the original subject untouched, as we need to manually remove the changes. If additional info needs to be added to the patch, it can be added between square brackets "[]" or as annotation to the patch, both are automatically removed by git when applying the patch. Thanks, Kleber
Buglink: https://bugs.launchpad.net/bugs/1832624 The cherry-pick [Patch 1/2] is for disco, the backport [Patch 2/2] for bionic. SRU Justification: [Impact] * Unable to maintain control-only crypto domains * The communication to control-only domains does not work in any way. * And depending on the setup (lowest numerical domain is control-only) the TKE does not see the crypto card at all. [Fix] * 7379e652797c0b9b5f6caea1576f2dff9ce6a708 7379e65 "s390/zcrypt: Fix wrong dispatching for control domain CPRBs" * Backport: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832624/+attachment/5271392/+files/s390-zcrypt-Fix-wrong-dispatching-for-control-domain.patch [Test Case] * Configure a control-only domain to the activation profile of LPAR A * Configure a control-and-usage domain to the activation profile of LPAR B * Try to communicate to LPAR A with the control-only domain (e.g. trying to read or set master key) [Regression Potential] * The regression potential can be considered as moderate since this is purely s390x specific * and again limited to CryptoExpress adapter cards. * It only occurs if crypto domains are configured as control-only or better control-only in combination with control-and-usage. * The majority of configurations is control-and-usage, since this offers more flexibility and covers more use cases. [Other Info] * Problem was found during tests at IBM and is a so called 'preventive fix' * The given patch is supposed to fix this issue and became upstream accepted with kernel 5.2-rc3. * It applies cleanly to disco master-next while cherry-picking. * But needs the the backport (from comment #3) for bionic's master-next kernel 4.15. * Once we have the target kernel 5.2 in Eoan, it will be there, too. Harald Freudenberger (1): From: Harald Freudenberger <freude@linux.ibm.com> arch/s390/include/asm/ap.h | 4 ++-- drivers/s390/crypto/ap_bus.c | 26 ++++++++++++++++++++++---- drivers/s390/crypto/ap_bus.h | 3 +++ drivers/s390/crypto/zcrypt_api.c | 17 ++++++++++++++--- 4 files changed, 41 insertions(+), 9 deletions(-)