summaryrefslogtreecommitdiffstats
path: root/fs/userfaultfd.c
diff options
context:
space:
mode:
authorJosef Bacik <josef@toxicpanda.com>2021-11-18 16:33:14 -0500
committerDavid Sterba <dsterba@suse.com>2022-01-03 15:09:46 +0100
commit950575c023aabfeac506cae02917c32eae1f553e (patch)
tree2a1d27e91cdfc69dfc39ad3a02afe97af0c5dc37 /fs/userfaultfd.c
parent83f1b68002c208329412cf9f998c90b3326828d2 (diff)
downloadlinux-950575c023aabfeac506cae02917c32eae1f553e.tar.gz
linux-950575c023aabfeac506cae02917c32eae1f553e.tar.bz2
linux-950575c023aabfeac506cae02917c32eae1f553e.zip
btrfs: only use ->max_extent_size if it is set in the bitmap
While adding self tests for my space index change I was hitting a problem where the space indexed tree wasn't returning the expected ->max_extent_size. This is because we will skip searching any entry that doesn't have ->bytes >= the amount of bytes we want. However we'll still set the max_extent_size based on that entry. The problem is if we don't search the bitmap we won't have ->max_extent_size set properly, so we can't really trust it. This doesn't really result in a problem per-se, it can just result in us not finding contiguous area that may exist. Fix the max_extent_size helper to return ->bytes if ->max_extent_size isn't set, and add a big comment explaining why we're doing this. Signed-off-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'fs/userfaultfd.c')
0 files changed, 0 insertions, 0 deletions