On 28 August 2018 at 01:08, Megha Dey <megha.dey@xxxxxxxxxxxxxxx> wrote: > On Wed, 2018-08-22 at 14:20 +0800, Herbert Xu wrote: >> On Tue, Aug 21, 2018 at 02:43:56PM +0200, Ard Biesheuvel wrote: >> > >> > I agree. The code is obviously broken in a way that would have been >> > noticed if it were in wide use, and it is too complicated for mere >> > mortals to fix or maintain. I suggest we simply remove it for now, and >> > if anyone wants to reintroduce it, we can review the code *and* the >> > justification for the approach from scratch (in which case we should >> > consider factoring out the algo agnostics plumbing in a way that >> > allows it to be reused by other architectures as well) >> >> I agree too. Could one of you guys send me a patch to remove >> them? >> > > Hi, > > We are working on a fix to solve these corner cases. > Great. thanks. But it would also be helpful if you could try and answer the questions raised by Eric: - in which cases does this driver result in a speedup? - how should we tune the flush delay to prevent pathological performance regressions? - is it still safe in the post-Spectre era of computing to aggregate hash input from different sources (which may be different users altogether) and process them as a single source of input?
