On Sat, Jan 24, 2026 at 05:31:04PM -0800, Eric Biggers wrote:
> > + found = rhashtable_lookup_get_insert_fast(&fsverity_info_hash,
> > + &vi->rhash_head, fsverity_info_hash_params);
> > + if (found) {
> > + fsverity_free_info(vi);
> > + if (IS_ERR(found))
> > + err = PTR_ERR(found);
> > + }
>
> Is there any explanation for why it's safe to use the *_fast variants of
> these functions?
_fast is the default mode of operation of rhashtable, I have no idea
why the authors came up with the naming. The _fast postfixed versions
just add the required RCU critical sections over ther otherwise fully
internally locked rhashtable operations. I've expanded the commit
message a bit to make this hopefully more clear.
> This looks incorrect. The memory barrier is needed after reading the
> flag, not before. (See how smp_load_acquire() works.)
>
> Also, it's needed only for verity inodes.
>
> Maybe do:
>
> if (IS_ENABLED(CONFIG_FS_VERITY) && IS_VERITY(inode)) {
> /*
> * This pairs with the try_cmpxchg in set_mask_bits()
> * used to set the S_VERITY bit in i_flags.
> */
> smp_mb();
> return true;
> }
> return false;
Thanks, I've fixed this up.
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
