lkml.org 
[lkml]   [2023]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH net-next] crypto: af_alg/hash: Fix recvmsg() after sendmsg(MSG_MORE)
Date
Herbert Xu <herbert@gondor.apana.org.au> wrote:

> Anyway, why did you remove the condition on hash_free_result?
> We free the result if it's not needed, not to clear the previous
> hash. So by doing it uncondtionally you will simply end up
> freeing and reallocating the result for no good reason.

The free here:

if (!continuing) {
if ((msg->msg_flags & MSG_MORE))
hash_free_result(sk, ctx);

only happens in the following case:

send(hashfd, "", 0, 0);
send(hashfd, "", 0, MSG_MORE); <--- by this

and the patch changes how this case works if no data is given. In Linus's
tree, it will create a result, init the crypto and finalise it in
hash_sendmsg(); with this patch that case is then handled by hash_recvmsg().
If you consider the following sequence:

send(hashfd, "", 0, 0);
send(hashfd, "", 0, 0);
send(hashfd, "", 0, 0);
send(hashfd, "", 0, 0);

Upstream, the first one will create a result and then each of them will init
and finalise a hash, whereas with my patch, the first one will release any
outstanding result and then none of them will do any crypto ops.

However, as, with my patch hash_sendmsg() no longer calculated a result, it
has to clear the result pointer because the logic inside hash_recvmsg() relies
on the result pointer to indicate that there is a result.

Instead, hash_recvmsg() concocts the result - something it has to be able to
do anyway in case someone calls recvmsg() without first supplying data.

David

\
 
 \ /
  Last update: 2023-06-19 18:48    [W:0.105 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site