summaryrefslogtreecommitdiffstats
path: root/drivers/Kconfig
diff options
context:
space:
mode:
authorDan Williams <dan.j.williams@intel.com>2018-10-06 19:56:11 +0200
committerDan Williams <dan.j.williams@intel.com>2018-10-08 20:38:44 +0200
commitd7782145e1ad537df4ce74e58c50f1f732a1462d (patch)
tree01a1ab21e985318b68f8405ce1c04ec6eeca5331 /drivers/Kconfig
parentLinux 4.19-rc6 (diff)
downloadlinux-d7782145e1ad537df4ce74e58c50f1f732a1462d.tar.xz
linux-d7782145e1ad537df4ce74e58c50f1f732a1462d.zip
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>
Diffstat (limited to 'drivers/Kconfig')
0 files changed, 0 insertions, 0 deletions