Derrick Stolee <stolee@xxxxxxxxx> writes: > I was thinking that having a mitigation for 2.19 is best, and then we > can focus as part of the 2.20 cycle how we can properly avoid this > cost, especially when 32 is a valid option. > ... > ... to > take a 'hasheq' approach [2] like Peff suggested [3]. Since that > requires auditing all callers of hashcmp to see if hasheq is > appropriate, it is not a good solution for 2.19 but (in my opinion) > should be evaluated as part of the 2.20 cycle. Thanks for thoughtful comments. I think it makes sense to go with the "tell compiler hashcmp() currently is only about 20-byte array" for now, as it is trivial to see why it cannot break things. During 2.20 cycle, we may find out that hasheq() abstraction performs better than hashcmp() with multiple lengths, and end up doing that "audit and replace to use hasheq()". But as you said, it probably isnot a good idea to rush it in this cycle.
