Take a look at fs/file.c:expand_fdtable() and fs/file.c:fd_install() In the end of the former: copy_fdtable(new_fdt, cur_fdt); rcu_assign_pointer(files->fdt, new_fdt); if (cur_fdt != &files->fdtab) call_rcu(&cur_fdt->rcu, free_fdtable_rcu); /* coupled with smp_rmb() in fd_install() */ smp_wmb(); return 1; the only caller (expand_files()) has expanded = expand_fdtable(files, nr); files->resize_in_progress = false; OTOH, in fd_install() there's this: if (unlikely(files->resize_in_progress)) { rcu_read_unlock_sched(); spin_lock(&files->file_lock); fdt = files_fdtable(files); WARN_ON(fdt->fd[fd] != NULL); rcu_assign_pointer(fdt->fd[fd], file); spin_unlock(&files->file_lock); return; } /* coupled with smp_wmb() in expand_fdtable() */ smp_rmb(); fdt = rcu_dereference_sched(files->fdt); What's the problem with droping both barriers and turning that into expanded = expand_fdtable(files, nr); smp_store_release(&files->resize_in_progress, false); and if (unlikely(smp_load_acquire(&files->resize_in_progress))) { .... return; } fdt = rcu_dereference_sched(files->fdt); resp.? Anyone who sees ->resize_in_progress being false will see all stores prior to setting ->fdt on the expand size... That went into the tree in 8a81252b774b "fs/file.c: don't acquire files->file_lock in fd_install()". I don't remember that having been discussed back then, but it had been 7 years ago... <check the thread on lore> Nobody asked, AFAICS. Is there any problem with going that way? Because I'm pretty sure that it's would be cheaper to use store_release/load_acquire instead of paying for smp_rmb() on the fd_install() side... Am I missing something subtle here?