If you want to negate the meaning of the flag, then you have to write it
yourself. I, as non-developer of crypto code, can prove that on given path
the input data are read only once --- but I can't prove that on all paths
and all possible chaining modes of algorithms the data are read once,
because I don't know about all of them.
Huh? Inverting it would give exactly the same result as your current
patch. If you're not confident with it inverted, then I can't see
how you could be confident about the patch as it is.
If you don't set the bit when it should be set => you get slight
performance drop (problem 1)
You set the bit when it shouldn't be set => you get data corruption
(problem 2)
Problem 1 is acceptable, problem 2 is not.
So if I forgot some code path when the bit should be set, I created
problem 1, but I am sure that I didn't create problem 2.
If you invert the meaning of the bit, you risk creating problem 2. And you
need more review (by someone who understands what all structures are being
created in crypto code).
Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
