From: Charan Teja Kalla <charante@codeaurora.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Charan Teja Reddy <quic_charante@quicinc.com>,
hughd@google.com, akpm@linux-foundation.org, vbabka@suse.cz,
rientjes@google.com, david@redhat.com, mhocko@suse.com,
surenb@google.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm: shmem: implement POSIX_FADV_[WILL|DONT]NEED for shmem
Date: Fri, 3 Dec 2021 17:25:40 +0530 [thread overview]
Message-ID: <04ca54ad-0e03-84b1-bf5c-131a582137d4@codeaurora.org> (raw)
In-Reply-To: <YajsJSejHlx8n11U@casper.infradead.org>
()
On 12/2/2021 9:24 PM, Matthew Wilcox wrote:
> Would this change to the documentation have prevented you from making
> this mistake?
>
> The advanced API is based around the xa_state. This is an opaque data
> structure which you declare on the stack using the XA_STATE()
> macro. This macro initialises the xa_state ready to start walking
> around the XArray. It is used as a cursor to maintain the position
> in the XArray and let you compose various operations together without
> -having to restart from the top every time.
> +having to restart from the top every time. The contents of the xa_state
> +are protected by the rcu_read_lock() or the xas_lock(). If you need to
> +drop whichever of those locks is protecting your state and tree, you must
> +call xas_pause() so that future calls do not rely on the parts of the
> +state which were left unprotected.
Yes, this looks much clear to me.
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2021-12-03 11:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-02 10:50 Charan Teja Reddy
2021-12-02 13:27 ` Matthew Wilcox
2021-12-02 15:29 ` Charan Teja Kalla
2021-12-02 15:54 ` Matthew Wilcox
2021-12-03 11:55 ` Charan Teja Kalla [this message]
2021-12-02 14:59 ` Matthew Wilcox
2021-12-03 13:02 ` Charan Teja Kalla
2021-12-02 17:54 ` Shakeel Butt
2021-12-06 7:29 ` Charan Teja Kalla
2022-01-05 15:17 ` Charan Teja Kalla
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=04ca54ad-0e03-84b1-bf5c-131a582137d4@codeaurora.org \
--to=charante@codeaurora.org \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=quic_charante@quicinc.com \
--cc=rientjes@google.com \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--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