Re: [RFC] why do we need smp_rmb/smp_wmb pair in fd_install()/expand_fdtable()?

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

 



On Thu, Aug 08, 2024 at 04:35:05AM +0100, Al Viro wrote:
> On Wed, Aug 07, 2024 at 08:06:31PM -0700, Linus Torvalds wrote:

> > But release/acquire is the RightThing(tm), and the fact that alpha
> > based its ordering on the bad old model is not really our problem.
> 
> alpha would have fuckloads of full barriers simply from all those READ_ONCE()
> in rcu reads...
> 
> smp_rmb() is on the side that is much hotter - fd_install() vs. up to what, 25 calls
> of expand_fdtable() per files_struct instance history in the worst possible case?
> With rather big memcpy() done by those calls, at that...

BTW, an alternative would be to have LSB of ->fdt (or ->fd, if we try to
eliminate that extra dereference) for ->resize_in_progress.  Then no barrier
is needed for ordering of those.  Would cost an extra &~1 on ->fdt fetches,
though...




[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