To be clear, Panfrost relies on stuffing (bogus) magic numbers into u64 keys and u64 values. Is this going to break on us? That is, when you mention this is a bug, who's buggy here? (Panfrost or hash_table_u64 or both?)
On Mon, Aug 05, 2019 at 09:10:00AM -0700, Caio Marcelo de Oliveira Filho wrote: > On Mon, Aug 05, 2019 at 05:18:32PM +0200, Tomeu Vizoso wrote: > > Some hash functions (eg. key_u64_hash) will attempt to dereference the > > key, causing an invalid access when passed DELETED_KEY_VALUE (0x1) or > > FREED_KEY_VALUE (0x0). > > > > The entry.hash field isn't needed by the delete_function, so just stop > > populating it. > > delete_function is a callback, so it is up to the caller whether it > makes use it or not. We also would have to add a comment somewhere > about this exception. > > Seems to me this is a bug of not calling hash correctly when > `sizeof(void *) != 8`. To fix we should do like in > hash_table_u64_search() and create a temporary local struct > hash_key_u64 in that case. > > > Caio _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
