On 06/22/2018 01:03 PM, Timur Tabi wrote:
Perhaps it's because you implemented the 'wait' functionality in this
driver? Before the patch there wasn't any sort of wait check so we would
bail out if there wasn't any data even if the caller requested that we
wait for randomness to be available.
No, my tests showed the race condition (or at least something that looks
like a race condition) even without the 'wait' feature. I added support
for 'wait' only recently, but I've been working with the crypto people
for a month on everything else.
Looks like I was wrong.
I created some new tests to reproduce the problem, but I can't reproduce
it any more. I can only assume that what I saw as a race condition back
then was something else entirely.
So all of the spinlock code needs to go. It looks like at this point,
if Vinod can add support for QCOM8160 to his patches, the only thing I
can contribute is support for 'wait'.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
