Re: [PATCH 6/9] XArray: internal node is a xa_node when it is bigger than XA_ZERO_ENTRY

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

 



On Mon, Mar 30, 2020 at 06:49:03AM -0700, Matthew Wilcox wrote:
>On Mon, Mar 30, 2020 at 01:45:19PM +0000, Wei Yang wrote:
>> On Mon, Mar 30, 2020 at 05:50:06AM -0700, Matthew Wilcox wrote:
>> >On Mon, Mar 30, 2020 at 12:36:40PM +0000, Wei Yang wrote:
>> >> As the comment mentioned, we reserved several ranges of internal node
>> >> for tree maintenance, 0-62, 256, 257. This means a node bigger than
>> >> XA_ZERO_ENTRY is a normal node.
>> >> 
>> >> The checked on XA_ZERO_ENTRY seems to be more meaningful.
>> >
>> >257-1023 are also reserved, they just aren't used yet.  XA_ZERO_ENTRY
>> >is not guaranteed to be the largest reserved entry.
>> 
>> Then why we choose 4096?
>
>Because 4096 is the smallest page size supported by Linux, so we're
>guaranteed that anything less than 4096 is not a valid pointer.

I found this in xarray.rst:

  Normal pointers may be stored in the XArray directly.  They must be 4-byte
  aligned, which is true for any pointer returned from kmalloc() and
  alloc_page().  It isn't true for arbitrary user-space pointers,
  nor for function pointers.  You can store pointers to statically allocated
  objects, as long as those objects have an alignment of at least 4.

So the document here is not correct?

-- 
Wei Yang
Help you, Help me



[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