On Fri, 26 Jun 2020 at 12:00, Herbert Xu herbert@gondor.apana.org.au wrote:
On Tue, Jun 23, 2020 at 10:02:17AM -0700, Eric Biggers wrote:
The source code for the two failing AF_ALG tests is here:
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/crypt... https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/crypt...
They use read() and write(), not send() and recv().
af_alg02 uses read() to read from a "salsa20" request socket without writing anything to it. It is expected that this returns 0, i.e. that behaves like encrypting an empty message.
Since we are on this subject, LTP af_alg02 test case fails on stable 4.9 and stable 4.4 This is not a regression because the test case has been failing from the beginning.
Is this test case expected to fail on stable 4.9 and 4.4 ? or any chance to fix this on these older branches ?
Test output: af_alg02.c:52: BROK: Timed out while reading from request socket.
ref: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.228-191... https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.228-191...
- Naresh
On Tue, Jun 30, 2020 at 02:18:11PM +0530, Naresh Kamboju wrote:
Since we are on this subject, LTP af_alg02 test case fails on stable 4.9 and stable 4.4 This is not a regression because the test case has been failing from the beginning.
Is this test case expected to fail on stable 4.9 and 4.4 ? or any chance to fix this on these older branches ?
Test output: af_alg02.c:52: BROK: Timed out while reading from request socket.
ref: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.228-191... https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.228-191...
Actually this test really is broken. Even though empty requests are legal, they should never be done with no write(2) at all. Because this fundamentally breaks the use of a blocking read(2) to wait for more data.
Granted this has been broken since 2017 but I'm not going to reintroduce this just because of a broken test case.
So please either remove af_alg02 or fix it by adding a control message through sendmsg(2).
Thanks,
---8<--- Some user-space programs rely on crypto requests that have no control metadata. This broke when a check was added to require the presence of control metadata with the ctx->init flag.
This patch fixes the regression by setting ctx->init as long as one sendmsg(2) has been made, with or without a control message.
Reported-by: Sachin Sant sachinp@linux.vnet.ibm.com Reported-by: Naresh Kamboju naresh.kamboju@linaro.org Fixes: f3c802a1f300 ("crypto: algif_aead - Only wake up when...") Signed-off-by: Herbert Xu herbert@gondor.apana.org.au
diff --git a/crypto/af_alg.c b/crypto/af_alg.c index 9fcb91ea10c41..5882ed46f1adb 100644 --- a/crypto/af_alg.c +++ b/crypto/af_alg.c @@ -851,6 +851,7 @@ int af_alg_sendmsg(struct socket *sock, struct msghdr *msg, size_t size, err = -EINVAL; goto unlock; } + ctx->init = true;
if (init) { ctx->enc = enc; @@ -858,7 +859,6 @@ int af_alg_sendmsg(struct socket *sock, struct msghdr *msg, size_t size, memcpy(ctx->iv, con.iv->iv, ivsize);
ctx->aead_assoclen = con.aead_assoclen; - ctx->init = true; }
while (size) {
On Thu, Jul 02, 2020 at 01:32:21PM +1000, Herbert Xu wrote:
On Tue, Jun 30, 2020 at 02:18:11PM +0530, Naresh Kamboju wrote:
Since we are on this subject, LTP af_alg02 test case fails on stable 4.9 and stable 4.4 This is not a regression because the test case has been failing from the beginning.
Is this test case expected to fail on stable 4.9 and 4.4 ? or any chance to fix this on these older branches ?
Test output: af_alg02.c:52: BROK: Timed out while reading from request socket.
ref: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.228-191... https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.228-191...
Actually this test really is broken.
FWIW the patch "umh: fix processed error when UMH_WAIT_PROC is used" was dropped from linux-next for now as it was missing checking for signals. I'll be open coding iall checks for each UMH_WAIT_PROC callers next. Its not clear if this was the issue with this test case, but figured I'd let you know.
Luis
linux-stable-mirror@lists.linaro.org