Dan Williams d7782145e1 filesystem-dax: Fix dax_layout_busy_page() livelock
In the presence of multi-order entries the typical
pagevec_lookup_entries() pattern may loop forever:

	while (index < end && pagevec_lookup_entries(&pvec, mapping, index,
				min(end - index, (pgoff_t)PAGEVEC_SIZE),
				indices)) {
		...
		for (i = 0; i < pagevec_count(&pvec); i++) {
			index = indices[i];
			...
		}
		index++; /* BUG */
	}

The loop updates 'index' for each index found and then increments to the
next possible page to continue the lookup. However, if the last entry in
the pagevec is multi-order then the next possible page index is more
than 1 page away. Fix this locally for the filesystem-dax case by
checking for dax-multi-order entries. Going forward new users of
multi-order entries need to be similarly careful, or we need a generic
way to report the page increment in the radix iterator.

Fixes: 5fac7408d828 ("mm, fs, dax: handle layout changes to pinned dax...")
Cc: <stable@vger.kernel.org>
Cc: Ross Zwisler <zwisler@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-10-08 11:38:44 -07:00
..
2018-09-06 09:04:45 -07:00
2018-06-11 10:16:13 -07:00
2018-08-21 23:54:17 -04:00
2018-08-22 13:29:39 -07:00
2018-08-21 18:47:36 -07:00
2018-08-15 22:40:03 -07:00
2018-08-17 16:20:28 -07:00
2018-08-15 22:47:23 -07:00
2018-08-18 11:44:53 -07:00
2018-05-22 14:27:52 -04:00
2018-09-14 19:25:28 -10:00
2018-08-17 16:20:27 -07:00
2018-09-20 22:01:12 +02:00
2018-05-22 14:27:52 -04:00
2018-08-18 11:44:53 -07:00
2018-08-21 18:19:09 -07:00
2018-07-03 16:44:45 -04:00
2018-08-14 10:23:25 -07:00
2018-06-05 19:23:26 +02:00
2018-08-21 18:19:09 -07:00
2018-05-03 16:11:37 -06:00
2018-08-21 18:19:09 -07:00
2018-08-21 18:19:09 -07:00
2018-07-18 15:44:40 +02:00
2018-08-21 18:15:47 -07:00
2018-06-11 08:22:34 -07:00
2018-08-21 18:19:09 -07:00
2018-02-15 15:34:42 -05:00
2018-08-21 18:19:09 -07:00
2018-04-04 12:44:02 -07:00