Thanks Matthew for the comments!!
On 12/2/2021 6:57 PM, Matthew Wilcox wrote:
> On Thu, Dec 02, 2021 at 04:20:53PM +0530, Charan Teja Reddy wrote:
>> +static int shmem_fadvise_willneed(struct address_space *mapping,
>> + pgoff_t start, pgoff_t long end)
>> +{
>> + XA_STATE(xas, &mapping->i_pages, start);
>> + struct page *page;
>> +
>> + rcu_read_lock();
>> + page = xas_find(&xas, end);
>> + rcu_read_unlock();
>> +
>> + while (page) {
>> + if (xa_is_value(page)) {
>> + page = shmem_read_mapping_page(mapping, xas.xa_index);
>> + if (!IS_ERR(page))
>> + put_page(page);
>> + }
>> +
>> + if (need_resched()) {
>> + xas_pause(&xas);
>> + cond_resched();
>> + }
>> +
>> + rcu_read_lock();
>> + page = xas_next_entry(&xas, end);
>> + rcu_read_unlock();
>> + }
>> +
>> + return 0;
>> +}
>
> What part of the XArray documentation led you to believe that this is a
> safe thing to do? Because it needs to be rewritten immediately!
The above code changes made from my understanding of both the
Documentation and the implementation of xa_for_each(). The Locking
section of the document[1] says that xa_for_each() takes the rcu lock
thus can be used without any explicit locking and the "Advanced API"
section says that users need to take xa_lock/rcu lock as no locking done
for you.
Further I have looked at the xa_for_each() implementation details,
where, it is taking the rcu_lock just across xas_find() in both
xa_find() and xa_find_after() which made me to think that it just needs
to take the rcu lock just across the xas_find().
But a comment from you saying that this implementation is wrong making
me to think that I lack very trivial understanding about xarray usage.
[1] https://www.kernel.org/doc/html/latest/core-api/xarray.html
>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project
