Re: [PATCH] fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 6 Aug 2024 at 09:32, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > So I think smp_wmb() and smp_rmb() would be sufficient. I also find it
> > clearer in this case.
>
> It's not the question of sufficiency; it's whether anything cheaper can be
> had.

I'd avoid smp_rmb(), since that can be very expensive, but
"smp_load_acquire()" is about as cheap as it comes. As is
"smp_store_release()" and "smp_wmb()".

So if it's mostly about just ordering with max_fds, I'd suggest just
doing the store of the bigger max_fds value with a smp_store_release()
(which guarantees that any previous stores of the bitmap pointers etc
have been done first and are visible), and then before accessing the
arrays, do the load of the max_fds thing with a "smp_load_acquire()",
and it should all be good.

But the array pointers themselves also need the same
smp_store_release() when updating, just to guarantee that the newly
copied contents are ordered. Which implies having to read those too
with smp_load_acquire(), regardless of the max_fds value read.

But on x86, smp_store_release/smp_load_acquire is completely free. And
on other architectures it's generally one of the cheapest possible
ordering constraints. So I doubt it's a performance issue even outside
of x86, and avoiding a double indirection is probably a win.

            Linus




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux