ACK: [SRU][Bionic][PATCH 0/5] Fixes for LP1799184 [v2]

[Stefan Bader]

On 07.11.18 14:11, Frank Heimes wrote:
> I can leave some reasons I am aware of here - but if this should not be
> sufficient I may reached out to our Partner and ask there for a statement, too.
> 
> This functionality is used in a closed solution that was heavily tested before GA.
> This testing of course incl. the kernel, hence testing was done on 4.4 (testing
> of kernel and req. user-space tools, partly close to kernel).
> Since the solution is closed it's not simply possible to do updates or kernel
> upgrades at any time.
> But using the HWE kernel would force one into a strict update pattern that not
> necessarily fits to the general solution update and release cycle.
> And even if HWE is used the entire test on kernel 4.4 would need to be redone on
> HWE again - which would req. a bigger repeating effort.
> So due to the stability of the 4.4 (GA) kernel and the through testing, it's
> desired to add the functionality of this SRU this the default kernel,
> rather than moving one via the 4 needed upgrades of HWE kernel.sequence.

Ok, I guess that sounds reasonable. So given there has been a lot of testing on
this and due to things being limited to architectural code which has reasonable
chance of catching regressions in that HW environment, I think we can accept the
risk here.

Acked-by: Stefan Bader <stefan.bader at canonical.com>
> 
> 
> 
> 
> On Wed, Nov 7, 2018 at 1:51 PM Stefan Bader <stefan.bader at canonical.com
> <mailto:stefan.bader at canonical.com>> wrote:
> 
>     On 02.11.18 20:29, Frank Heimes wrote:
>     > BugLink: http://bugs.launchpad.net/bugs/1799184
>     >
>     > == SRU Justification ==
>     >
>     > 'APQN tags in the zcrypt device driver are required to support deterministic
>     > driver binding'
>     > With the introduction of KVM hw crypto virtualization (on s390x) the driver
>     > bound to an AP queue device is no longer unique determined.
>     > Therefore a deterministic hot plugging semantics of AP queues that may be
>     bound
>     > to multiple drivers is needed.
>     > With the three listed commits here it will be possible to configure an AP
>     queue
>     > (APQN) as being bound to a particular driver even if the associate hw gets
>     > intermittently lost and reconnected.
>     >
>     > == Fix ==
>     >
>     > ac2b96f351d7d222 ("s390/zcrypt: code beautify")
>     > 7e0bdbe5c21cb831 ("s390/zcrypt: AP bus support for alternate driver(s)")
>     > 3d8f60d38e249f98 ("s390/zcrypt: hex string mask improvements for apmask
>     and aqmask")
>     >
>     > pre-reqs:
>     > 2c957a8ad45 ("s390/zcrypt: remove unused functions and declarations")
>     > 4a07750ba8f3f ("s390/zcrypt: Show load of cards and queues in sysfs")
>     >
>     > == Regression Potential ==
>     >
>     > Llow. because:
>     > - There are quite some changes, but everything is limited to s390/zcrypt,
>     means:
>     >    arch/s390/include/uapi/asm/*
>     >    and
>     >    drivers/s390/crypto/*
>     > - So everything is s390x specific.
>     > - And larger parts of the changes are beautifications.
>     > - It's all upstream accepted in 4.19
>     > - The code is already successfully test, integrated and running in cosmic.
> 
>     The main question remains why support for a new feature has to be pulled into a
>     stable/released kernel version and is not done via HWE kernels. I would at least
>     like to see some effort being made to come up with good reasons.
> 
>     -Stefan
> 
>     >
>     > == Test Case ==
>     >
>     > On an LPAR that has access to an CryptoExpress card,
>     > execute the 'lszcrypt --verbose'
>     > and check availability of: 
>     > /sys/bus/ap/apmask
>     > General test and verification was btw. also done by IBM.
>     > Please notice that the code already landed in cosmic.
>     >
>     >
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20181107/6ec96c26/attachment.sig>