Re: [PATCH 8/8] xarray: Don't clear marks in xas_store()

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

 



On 2/5/20 8:28 PM, Matthew Wilcox wrote:
On Wed, Feb 05, 2020 at 07:48:57PM -0800, John Hubbard wrote:
You can then set entries using xa_store() and get entries
using xa_load().  xa_store will overwrite any entry with the
new entry and return the previous entry stored at that index.  You can
use xa_erase(), instead of calling xa_store() with a
``NULL`` entry followed by xas_init_marks().  There is no difference between
an entry that has never been stored to and one that has been erased. Those,
in turn, are the same as an entry that has had ``NULL`` stored to it and
also had its marks erased via xas_init_marks().

There's a fundamental misunderstanding here.  If you store a NULL, the
marks go away.  There is no such thing as a marked NULL entry.  If you
observe such a thing, it can only exist through some kind of permitted
RCU race, and the entry must be ignored.  If you're holding the xa_lock,
there is no way to observe a NULL entry with a search mark set.


aha, the key point. Thanks for explaining it.

thanks,
--
John Hubbard
NVIDIA


What Jan is trying to do is allow code that knows what it's doing
the ability to say "Skip clearing the marks for performance reasons.
The marks are already clear."

I'm still mulling over the patches from Jan.  There's something I don't
like about them, but I can't articulate it in a useful way yet.  I'm on
board with the general principle, and obviously the xas_for_each_marked()
bug needs to be fixed.




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

  Powered by Linux