Re: [PATCH v2] mm: shmem: implement POSIX_FADV_[WILL|DONT]NEED for shmem

[Charan Teja Kalla]

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