What's the implication of this for Panfrost? (I.e. which patch/es in the series are pending on this change)
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. > > Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com> > Cc: Samuel Pitoiset <samuel.pitoi...@gmail.com> > Cc: Nicolai Hähnle <nicolai.haeh...@amd.com> > --- > src/util/hash_table.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/src/util/hash_table.c b/src/util/hash_table.c > index f58575de558f..e691f8baa9c1 100644 > --- a/src/util/hash_table.c > +++ b/src/util/hash_table.c > @@ -667,7 +667,6 @@ _mesa_hash_table_u64_clear(struct hash_table_u64 *ht, > struct hash_entry entry; > > /* Create a fake entry for the delete function. */ > - entry.hash = table->key_hash_function(table->deleted_key); > entry.key = table->deleted_key; > entry.data = ht->deleted_key_data; > > @@ -682,7 +681,6 @@ _mesa_hash_table_u64_clear(struct hash_table_u64 *ht, > struct hash_entry entry; > > /* Create a fake entry for the delete function. */ > - entry.hash = table->key_hash_function(uint_key(FREED_KEY_VALUE)); > entry.key = uint_key(FREED_KEY_VALUE); > entry.data = ht->freed_key_data; > > -- > 2.20.1 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
