linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Wei Yang <richard.weiyang@gmail.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/9] XArray: internal node is a xa_node when it is bigger than XA_ZERO_ENTRY
Date: Mon, 30 Mar 2020 14:13:50 +0000	[thread overview]
Message-ID: <20200330141350.ey77odenrbvixotb@master> (raw)
In-Reply-To: <20200330134903.GB22483@bombadil.infradead.org>

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

  reply	other threads:[~2020-03-30 14:13 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-30 12:36 [PATCH 0/9] XArray: several cleanups Wei Yang
2020-03-30 12:36 ` [PATCH 1/9] XArray: fix comment on Zero/Retry entry Wei Yang
2020-03-30 12:46   ` Matthew Wilcox
2020-03-30 13:42     ` Wei Yang
2020-03-30 12:36 ` [PATCH 2/9] XArray: simplify the calculation of shift Wei Yang
2020-03-30 13:20   ` Matthew Wilcox
2020-03-30 14:07     ` Wei Yang
2020-03-30 12:36 ` [PATCH 3/9] XArray: handle a NULL head by itself Wei Yang
2020-03-30 12:36 ` [PATCH 4/9] XArray: don't expect to have more nr_values than count Wei Yang
2020-03-30 12:36 ` [PATCH 5/9] XArray: entry in last level is not expected to be a node Wei Yang
2020-03-30 12:48   ` Matthew Wilcox
2020-03-30 14:15     ` Wei Yang
2020-03-30 14:28       ` Matthew Wilcox
2020-03-30 22:10         ` Wei Yang
2020-03-31 13:42         ` Wei Yang
2020-03-31 16:42           ` Matthew Wilcox
2020-03-31 22:04             ` Wei Yang
2020-03-31 23:59               ` Matthew Wilcox
2020-04-01 22:10                 ` Wei Yang
2020-04-01 22:20                   ` Matthew Wilcox
2020-04-02 12:36                     ` Wei Yang
2020-04-03 22:39                     ` Wei Yang
2020-04-04 15:37                       ` Matthew Wilcox
2020-04-05 11:07                     ` Wei Yang
2020-04-05 21:56                       ` Matthew Wilcox
2020-04-06  1:14                         ` Wei Yang
2020-04-06  1:24     ` Wei Yang
2020-04-11 13:56       ` Wei Yang
2020-04-28 21:24     ` Wei Yang
2020-03-30 12:36 ` [PATCH 6/9] XArray: internal node is a xa_node when it is bigger than XA_ZERO_ENTRY Wei Yang
2020-03-30 12:50   ` Matthew Wilcox
2020-03-30 13:45     ` Wei Yang
2020-03-30 13:49       ` Matthew Wilcox
2020-03-30 14:13         ` Wei Yang [this message]
2020-03-30 14:27           ` Matthew Wilcox
2020-03-30 22:20             ` Wei Yang
2020-03-31  0:06               ` Matthew Wilcox
2020-03-31 13:40                 ` Wei Yang
2020-03-30 12:36 ` [PATCH 7/9] XArray: the NULL xa_node condition is handled in xas_top Wei Yang
2020-03-30 12:36 ` [PATCH 8/9] XArray: take xas_error() handling for clearer logic Wei Yang
2020-03-30 12:36 ` [PATCH 9/9] XArray: adjust xa_offset till it gets the correct node Wei Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200330141350.ey77odenrbvixotb@master \
    --to=richard.weiyang@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).