On 6/15/20 12:53 AM, Miklos Szeredi wrote: > On Sat, Jun 13, 2020 at 9:12 PM Mike Kravetz <mike.kravetz@xxxxxxxxxx> wrote: >> On 6/12/20 11:53 PM, Amir Goldstein wrote: >>> >>> The simplest thing for you to do in order to shush syzbot is what procfs does: >>> /* >>> * procfs isn't actually a stacking filesystem; however, there is >>> * too much magic going on inside it to permit stacking things on >>> * top of it >>> */ >>> s->s_stack_depth = FILESYSTEM_MAX_STACK_DEPTH; >>> >>> Currently, the only in-tree stacking fs are overlayfs and ecryptfs, but there >>> are some out of tree implementations as well (shiftfs). >>> So you may only take that option if you do not care about the combination >>> of hugetlbfs with any of the above. >>> >>> overlayfs support of mmap is not as good as one might hope. >>> overlayfs.rst says: >>> "If a file residing on a lower layer is opened for read-only and then >>> memory mapped with MAP_SHARED, then subsequent changes to >>> the file are not reflected in the memory mapping." >>> >>> So if I were you, I wouldn't go trying to fix overlayfs-huguetlb interop... >> >> Thanks again, >> >> I'll look at something as simple as s_stack_depth. > > Agree. Apologies again for in the incorrect information about writing to lower filesystem. Stacking ecryptfs on hugetlbfs does not work either. Here is what happens when trying to create a new file. [ 1188.863425] ecryptfs_write_metadata_to_contents: Error attempting to write header information to lower file; rc = [-22] [ 1188.865469] ecryptfs_write_metadata: Error writing metadata out to lower file; rc = [-22] [ 1188.867022] Error writing headers; rc = [-22] I like Amir's idea of just setting s_stack_depth in hugetlbfs to prevent stacking. >From 0fbed66b37c18919ea7edd47b113c97644f49362 Mon Sep 17 00:00:00 2001 From: Mike Kravetz <mike.kravetz@xxxxxxxxxx> Date: Mon, 15 Jun 2020 14:37:52 -0700 Subject: [PATCH] hugetlbfs: prevent filesystem stacking of hugetlbfs syzbot found issues with having hugetlbfs on a union/overlay as reported in [1]. Due to the limitations (no write) and special functionality of hugetlbfs, it does not work well in filesystem stacking. There are no know use cases for hugetlbfs stacking. Rather than making modifications to get hugetlbfs working in such environments, simply prevent stacking. [1] https://lore.kernel.org/linux-mm/000000000000b4684e05a2968ca6@xxxxxxxxxx/ Reported-by: syzbot+d6ec23007e951dadf3de@xxxxxxxxxxxxxxxxxxxxxxxxx Suggested-by: Amir Goldstein <amir73il@xxxxxxxxx> Signed-off-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx> --- fs/hugetlbfs/inode.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 991c60c7ffe0..f32759c8e84d 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -1313,6 +1313,12 @@ hugetlbfs_fill_super(struct super_block *sb, struct fs_context *fc) sb->s_magic = HUGETLBFS_MAGIC; sb->s_op = &hugetlbfs_ops; sb->s_time_gran = 1; + + /* + * Due to the special and limited functionality of hugetlbfs, it does + * not work well as a stacking filesystem. + */ + sb->s_stack_depth = FILESYSTEM_MAX_STACK_DEPTH; sb->s_root = d_make_root(hugetlbfs_get_root(sb, ctx)); if (!sb->s_root) goto out_free; -- 2.25.4
