Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 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