indirect branch lookup should have barriers for either both mask and table or neither?

Looking at the arm and aarch64 emit_indirect_branch_lookup() they both have synchronization to handle a concurrently updated hash mask, but nothing when loading the lookuptable address. update_lookuptable_tls() uses a store-release when updating the mask -- but not the lookuptable. I'm not understanding that. Since these tables are all private anyway (-shard_{bb,trace}_ibt_tables are false by default) it doesn't matter in default runs?? But if they're private why don't we avoid the barrier for the mask under those options? Shouldn't we either have barriers for both the mask and table or for neither?