Re: [PATCH] fuse: fix panic in __readahead_batch()

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

 



On Tue, Nov 03, 2020 at 09:43:49PM +0900, Wonhyuk Yang wrote:
> @@ -906,6 +906,12 @@ static inline unsigned int __readahead_batch(struct readahead_control *rac,
>  	xas_set(&xas, rac->_index);
>  	rcu_read_lock();
>  	xas_for_each(&xas, page, rac->_index + rac->_nr_pages - 1) {
> +		if (xas_retry(&xas, page))
> +			continue;
> +
> +		if (!xa_is_value(page))
> +			continue;

By the way, this isn't right.  You meant 'if (xa_is_value(page))'.
It wouldn't cause a bug because it would simply cause all the pages to be
skipped, and so they get brought uptodate by ->readpage.  That's slower,
but if you're testing with fuse, I don't know that you'd notice!

Also, we can't see value entries here.  Readahead inserts the pages into
the page cache locked, and all paths to remove pages from the cache need
to acquire the page lock.

The reason we can see a retry entry here is that we did a readahead of a
single page at index 0.  Between that page being inserted and the lookup,
another page was removed from the file (maybe the file was truncated
down) and this caused the node to be removed, and the pointer to the
page got moved into the root of the tree.  The pointer in the node was
replaced with a retry entry, indicating that the page is still valid,
it just isn't here any more.  And so we retry the lookup.



[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